Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
16 mai 2017

htmlpdflatexmanmd




abrt-auto-reporting

abrt-auto-reporting

Affiche ou modifie les valeurs d'option de reporting automatique

   Lit la configuration depuis abrt.conf et sauve les changements dans le même fichier. Les changements prennent effet immédiatement.

enabled | yes | 1 | on | disabled | no | 0 | off Active le reporting automatique. charge un uReport qui a été généré pour un problème détecté immédiatement après la phase de detection.

Description uReport

   ABRT supporte les uReports pour 4 types de crashs: les crashes des programmes C/C++ qui résultent en un coredump, les exceptions Python, Java et les oops kernel.

  Chaque uReport contient généralement une ou plusieurs stack trace qui décrivent la pile d'appel du programme au moment du crash et ne contient aucun contenu de variable.

  Tout uReport contient également l'identification du système d'exploitation, versions des packages RDM, et si le programme tournait en root.

  Il y a également des éléments spécifique à chaque type de crash:

        C/C++: les chemins de l'exécutable et le signal délivré au programme
        Python Le type d'exception
        oops List des modules kernel chargés, flags et texte complet du oops.
^
16 mai 2017

htmlpdflatexmanmd




abrt-cli

abrt-cli

Gérer les reports abrt

OPTIONS

-a, --authenticate Active l'authentification PolKit pour pouvoir travailler avec les problèmes système
-v, --verbose mode verbeux
-b, --bare Affiche seulement un compteur de problèmes sans messages
--detailed Affiche un rapport détaillé
-n, --not-reported Liste seulement les problèmes non-reportés
--size SIZE Largeur de texte en octet. Au delà, le texte est abrégé
--since NUM Sélectionne seulement les problèmes détectés après la date donnée
-u, --unsafe Ignore les vérifications de sécurité pour pouvoir afficher tous les problèmes
--until NUM Sélectionne seulement les problèmes détectés avant la date donnée
^
16 mai 2017

htmlpdflatexmanmd




abrt-configuration

abrt-configuration

Serveur dbus pour la configuration de lecture/écriture ABRT

OPTIONS

   ce programme permet à d'autres programmes de lire/écrire la configuration ABRT via D-Bus. Normalement, il est démarré par les service dbus à la demande, et terminé après un timeout. Le serveur écoute sur com.redhat.problem.configuration et exporte la configuration comme objet D-Bus. Les objets sont créés depuis les fichiers XML dans /usr/share/problems/config/interfaces.

Exemple de fichier XML de configuration:
‹node name="/com/redhat/problems/configuration/ccpp"›
    ‹annotation name="com.redhat.problems.ConfFile" value="/etc/abrt/plugins/CCpp.conf" /›
    ‹annotation name="com.redhat.problems.DefaultConfFile" value="/usr/share/abrt/conf.d/plugins/CCpp.conf" /›
    
    ‹interface name="com.redhat.problems.configuration.ccpp"›
        ‹property name="MakeCompatCore" type="b" access="readwrite"/›
        ‹property name="SaveBinaryImage" type="b" access="readwrite"/›
        ‹property name="VerboseLog" type="i" access="readwrite"/›
        ‹property name="DebuginfoLocation" type="s" access="readwrite"/›
    ‹/interface›
‹/node›

OPTIONS

-v mode verbeux
-t NUM Quitte après num secondes d'inactivité
^
16 mai 2017

htmlpdflatexmanmd




abrt-dbus

abrt-dbus

Serveur dbus pour requêter les données des problèmes

   abrt-dbus permet à d'autres programmes d'opérer sur les répertoires de données de problème via D-Bus. Normalement, ce programme est démarré par dbus à la demande, et terminé après un timeout

OPTIONS

-v mode verbeux
-t NUM Quitte après num secondes d'inactivité
^
16 mai 2017

htmlpdflatexmanmd




abrt-oops.conf

abrt-oops.conf

Fichier de configuration pour l'extracteur Oops du kernel

OPTIONS

DropNotReportableOopses (bool). Afficher seulement les oops reportable. Défaut: no.
OnlyFatalMCOE (bool) Affiche seulement les MCE fatals. Défaut: yes.
^
16 mai 2017

htmlpdflatexmanmd




abrt-server

abrt-server

Socket unix pour ABRT

   abrt-server est exécuté par le service abrtd pour gérer les connexions socket. Toute application dans le système est capable d'invoquer la création d'un nouveau répertoire problem en suivant le protocole de communication

OPTIONS

-u UID UID à utiliser
-s Log dans les logs système
-p Ajoute le nom du programme dans les logs
-v mode verbeux
^
16 mai 2017

htmlpdflatexmanmd




abrt-watch-log

abrt-watch-log

Lit le fichier log et lance une commande quand il grossis ou est remplacé

OPTIONS

-F STR Ne pas lancer le programme si les STR ne sont pas trouvés
-v, --verbose mode verbeux
-s Log dans syslog
FILE Fichier à surveiller
PROG Programme à lancer
ARGS Arguments pour le programme
^
16 mai 2017

htmlpdflatexmanmd




abrt.conf

abrt.conf

Fichier de configuration pour abrt

OPTIONS

DumpLocation = dir Répertoire où stocker les coredumps et tous les fichiers qui sont nécessaires pour le reporting. Défaut: /var/spool/abrt
MaxCrashReportSize = num Espace disque en Mo que abrt utilise pour tous les dumps. Défaut: 1000
WatchCrashdumpArchiveDir = dir Répertoire de supervision et appel abrt-handle-uploud dans les fichiers qui apparaissent ici. Utilisé pour décompresser les uploads via ftp, scp, etc.
DeleteUploaded = yes/no Supprime une archive crashdump uploadée une fois qu'elle a été décompressée. Défaut: no
DebugLevel = 0-100 Autorise abrt à détecter les problèmes dans abrt lui-meme. Défaut: 0
AutoreportingEvent = report_uReport Nom de l'évènement qui est lancé automatiquement après la détection d'un problème. L'évènement devrait exécuter une analyse rapide et quitter avec un code 70 si le problème est connu. Défaut: report_uReport
AutoreportingEnabled = bool ACtive/désactive le lancement automatique de AutoreportingEvent
ShortenedReporting = bool Active le reporting GUI raccourci quand le reporting est interrompu après que AutoreportingEvent soit terminé. Défaut: yes
ExploreChroots = bool Active diverses fonctionnalité d'exploration des répertoires racine des processus s'ils diffèrent de /. Désactivé par défaut parce qu'un utilisateur peut l'utiliser pour voler des données
^
16 mai 2017

htmlpdflatexmanmd




abrtd

abrtd

Service de reporting de bug automatique

   abrtd est un service qui regarge les applications crashée. Quand un crash se produit, il collecte les données (fichier core, ligne de commande de l'application, etc.) et effectue une action en fonction du type d'application qui a planté et en accord avec la configuration. Il y a des plugins pour diverses actions: par exemple reporter le crash dans bugzilla, par mail, ou le transférer via FTP ou SCP.

OPTIONS

-v mode verbeux
-d Ne pas lancer en tâche de fond et log sur stderr
-s Log dans le log système même avec -d
-t NUM Quitte après num secondes d'inactivité
-p Ajoute les noms des programmes dans les logs

Variables d'environnement

ABRT_EVENT_NICE abrtd se lance avec une valeur de nice incrémenté par 10 pour ne pas prendre trop de ressource. Cette variable ajuste cet incrément.
^
29 août 2015

htmlpdflatexmanmd




acl

acl

Listes de contrôle d'accès

   Tout objet peut être considéré comme étant associé avec une ACL qui gouverne l'accès discrétionnaire de cet objet. Cette ACL est référée à une ACL d'accès. En plus, un répertoire peut avoir une ACL associée qui gouverne l'ACL initial pour les objets créés dans ce répertoire. Cette ACL est référé à l'ACL par défaut.

   Une ACL consiste d'un jeu d'entrées d'ACL. Une entrée ACL spécifie les permissions d'accès sur l'objet associé pour un utilisateur ou groupe individuel comme une combinaison de permissions de lecture, écriture et de recherche/exécution.

   Une entrée d'ACL contient un type de tag d'entrée, une qualifiant de tag d'entrée, et un jeu de permissions. On utilise le terme qualifier pour dénoter le qualifieur de tag d'entrée d'une entrée d'ACL.

   Le qualifieur dénote l'identifiant d'un utilisateur ou un groupe, pour les entrées avec les types de tag d'ACL_USER ou ACL_GROUP, respectivement. Les entrées avec des types de tag autre que ACL_USER ou ACL_GROUP n'ont pas de qualifieur définis.

   Les types de tag d'entrée suivant sont définis

ACL_USER_OBJ dénote les droits d'accès pour le propriétaire du fichier
ACL_USER dénote les droits d'accès pour les utilisateurs identifiés par le qualifieur de l'entrée
ACL_GROUP_OBJ dénote les droits d'accès pour le groupe du fichier
ACL_GROUP dénote les droits d'accès pour les groupes identifiés par le qualifieur de l'entrée
ACL_MASK dénote les droits d'accès maximum qui peuvent être donnés par les entrées de type ACL_USER, ACL_GROUP_OBJ ou ACL_GROUP.
ACL_OTHER dénote les droits d'accès pour les processus qui ne matchent aucune autre entrée dans l'acl.

   Quand un accès est vérifié, les entrées ACL_USER_OBJ et ACL_USER sont testés avec le user ID effectif. L'ID de groupe effectif, et les IDs de groupe supplémentaire sont testé avec les entrées ACL_GROUP_OBJ et ACL_GROUP.

   Une ACL valide contient exactement une entrée avec chaque types de tag ACL_USER_OBJ, ACL_GROUP_OBJ, et ACL_OTHER. Les entrées avec les types de tag ACL_USER et ACL_GROUP peuvent apparaître 0 ou plusieurs fois dans une ACL. Dans une ACL qui contient des entrée de type de tag ACL_USER ou ACL_GROUP doivent contenir exactement une entrée de type de tag ACL_MASK. Si une ACL ne contient pas d'entrées de type de tag ACL_USER ou ACL_GROUP, l'entrée ACL_MASK est optionnel.

   Tous les qualifier d'UID doivent être unique dans les entrées du type de tag ACL_USER, et tous les GID doivent être unique dans les entrée de type de tag ACL_GROUP.

   La fonction acl_get_file() retourne une ACL avec 0 entrées d'ACL comme ACL par défaut d'un répertoire, si le répertoire n'est pas associé avec une ACL par défaut. La fonction acl_set_file() accepte également une ACL avec 0 entrées d'ACL comme ACL par défaut pour les répertoires, dénotant que le répertoire ne devrait pas être associé avec une ACL par défaut. C'est équivalement à utiliser la fonction acl_delete_def_file().
   [SECTION] name="Correspondance entre les entrées d'ACL et les bits de permission de fichier" table="paragraphes" imbrication="0"

   Il y a une correspondance entre les permissions du propriétaire du fichier, groupe, et autres et les entrées d'ACL: les permissions du propriétaire correspondent aux permissions de l'entrée ACL_USER_OBJ. Si l'ACL a une entrée ACL_MASK, les permissions du groupe correspondent aux permission de l'entrée ACL_MASK. Sinon, si l'ACL n'a pas d'entrée ACL_MASK, les permissions du groupe correspondent aux permissions de l'entrée ACL_GROUP_OBJ. Les permissions des autres correspondent aux permission de l'entrée ACL_OTHER_OBJ.

   Les permissions du propriétaire, du groupe, et des autres match toujours les permissions de l'entrée d'ACL correspondante. Les modification des bits de permission de fichier résultent en la modification des entrées d'ACL correspondantes, et les modification des entrées d'ACL résultent en la modification des bits de permission de fichier.

Création d'objet et ACL par défaut

   L'ACL d'accès à un objet fichier est initialisé quand l'objet est créé avec une des fonctions creat(), mkdir(), mknod(), mkfifo() ou open(). Si une ACL par défaut est associée avec un répertoire, le paramètre mode des fonctions créant les objets fichier et l'ACL par défaut du répertoire sont utilisés pour déterminer l'ACL du nouvel objet:

1. Le nouvel objet hérite de l'ACL par défaut du répertoire correspondant comme son ACL d'accès
2. Les entrées d'ACL correspondant aux bits de permission de fichier sont modifiés pour qu'elles ne contiennent pas de permission qui ne sont pas contenus dans les permissions spécifiées par le paramètre mode.

   Si aucune ACL par défaut n'est associé avec un répertoire, le paramètre mode sont utilisés pour déterminer l'ACL du nouvel objet:

1. Le nouvel objet se voit assigner une ACL d'accès contenant des entrées de type de tag ACL_USER_OBJ, ACL_GROUP_OBJ, et ACL_OTHER. Les permission de ces entrées sont définie aux permissions spécifiées par le masque de création de fichier.
2. Les entrées d'ACL d'accès correspondant au bits de permission de fichier sont modifié pour qu'ils ne contiennent pas de permission qui ne soient pas contenus dans les permissions spécifiées par le paramètre mode.

Algorithme de vérification d'accès

   Un processus peut demander un accès en lecture, écriture ou exécution/recherche sur un objet fichier protégé par une ACL. L'algorithme de vérification d'accès détermine si l'accès à l'objet est autorisé.

1. Si le User ID effectif du processus correspond au User ID du propriétaire du fichier, alors

        - Si l'entrée ACL_USER_OBJ contient les permissions demandées, l'accès est donné,
        - Sinon l'accès est refusé

2. Sinon si le User ID effectif du processus correspond au qualifier d'une entrée de type ACL_USER, alors

        - Si l'entrée ACL_USER correspondant et l'entrée ACL_MASK contiennent les permissions requises, l'accès est donné
        - Sinon l'accès est refusé

3. Sinon si le GID effectif d'un ID de groupe supplémentaire du processus correspond au groupe du fichier ou le qualifier d'une entrée du type ACL_GROUP, alord

        - Si l'ACL contient une entrée ACL_MASK, alors

                . Si l'entrée ACL_MASK et une des entrées ACL_GROUP_OBJ ou ACL_GROUP correspondant contient les permissions requises, l'accès est donné
                . Sinon l'accès est refusé

        - Sinon (noter qu'il ne peut pas y avoir d'entrée ACL_GROUP sans entrée ACL_MASK)

                . Si l'entrée ACL_GROUP_OBJ contient les permissions requises, l'accès est donné,
                . Sinon l'accès est refusé

4. Sinon si l'entrée ACL_OTHER contient les permissions requises, l'accès est donné
5. Sinon l'accès est refusé.

Forme de texte d'ACL

   Une forme de texte long et cours pour représenter les ACL sont définis. Dans les 2 formes, les entrées d'ACL sont représenté en 3 champs séparés: le type de tag de l'entrée de l'ACL, le qualifier de l'entrée de l'ACL, et les permissions d'accès discrétionnaires. Le premier champ contient un des mots clé de type de tag suivant:

user Une entrée ACL user spécifie que l'accès est donné soit au propriétaire du fichier (type de tag d'entrée ACL_USER_OBJ) ou un utilisateur spécifique (type de tag d'entrée ACL_USER).
group Une entrée ACL group spécifie que l'accès est donné soit au groupe du fichier (type de tag d'entrée ACL_GROUP_OBJ), ou un groupe spécifique (type de tag d'entrée ACL_GROUP).
mask Une entrée ACL mask spécifie l'accès maximum qui peut être donné à toute entrée d'ACL excepté l'entrée utilisateur pour le propriétaire du fichier et l'entrée other (type de tag d'entrée ACL_MASK).
other Une entrée ACL other spécifie l'accès donné à tout processus qui ne correspond à aucune entrée d'ACL user et group (type de tag d'entrée ACL_OTHER).

   Le second champ contient l'identifiant d'utilisateur ou de groupe associé avec l'entrée d'ACL pour les entrées de type de tag ACL_USER ou ACL_GROUP, et est vide pour toutes les autres entrées. Un identifiant d'utilisateur peut être un nom d'utilisateur ou un UID. Un identifiant de groupe peut être un nom de groupe ou un ID.

   Le troisième champ contient les permissions d'accès discrétionnaires. Les permission de lire, écrire, et recherche/exécution sont représentés par les caractères r,w et y, respectivement. Chacun de ces caractères est remplacé par le caractère '-' pour indiquer qu'une permission est absente. En convertissant de la forme texte en représentation interne, les permissions absente n'ont pas besoin d'être spécifiés.

   Les espaces blanc sont autorisé au début et à la fin de chaque entrée d'ACL, et immédiatement avant et après un séparateur de champ.

Forme de texte long

   La forme de texte long contient une entrée d'ACL par ligne. En plus, un '#' peut commencer un commentaire qui s'étend jusqu'à la fin de la ligne. Si une entrée d'ACL ACL_USER, ACL_GROUP_OBJ ou ACL_GROUP contient des permissions qui ne sont pas contenus dans ACL_MASK, l'entrée est suivie par un '#', la chaîne 'effective', et les permissions d'accès effectif définis par cette entrée.

Exemple:
user::rw-
user:lisa:rw- #effective:r--
group::r--
group:toolies:rw- #effective:r--
mask::r--
other::r--

Forme de texte court

   La forme de texte court est une séquence d'entrées d'ACL séparés par des virgules, et est utilisant comme entrée. Les commantaires ne sont pas supportés. Les mots clé de type de tag d'entrée peuvent apparaître soit sous le forme complète, soit sous forme d'une seule lettre. Les abréviations sont pour user (u), group (g), mask (m) et other (o). Les permission peuvent contenir au moins un caractère de chaque dans n'importe quel ordre.

Exemple:
u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--
g:toolies:rw,u:lisa:rw,u::wr,g::r,o::r,m::r

   Dans les systèmes qui supportent les ACL, les utilitaires de fichier ls, cp et mv changent leur comportement de la manière suivante:

- Pour les fichier qui ont une ACL par défaut ou une ACL d'accès qui contient plus que les 3 entrées requise, ls -l affiche un signe + après la chaîne de permissions.
- Si le flag -p est spécifié, l'utilisataire cp préserve également les ACL. Si ce n'est pas possible, une alerte est produite.
- mv préserve toujours les ACL. Si ce n'est pas possible, une alerte est produite.
^
11 novembre 2011

htmlpdflatexmanmd




acpi

acpi

Affiche le statut de la batterie et d'autres informations ACPI, depuis /proc et /sys

OPTIONS

-b, --battery Information sur la batterie
-a, --ac-adapter Information sur l'adapteur de courant
-t, --thermal Information de température
-c, --cooling Information de refroidissement
-V, --everything Tous les périphériques
-s, --show-empty Affiche les périphériques non-opérationnels
-i, --details Informations détaillées
-f, --fahrenheit Températures exprimées en ° F
-k, --kelvin Températures exprimées en ° K
-p, --proc Utilise l'ancienne interface /proc. par défaut, utilise le nouveau /sys
-d, --directory Chemin vers les infos ACPI (défaut : /proc/acpi ou /sys/class)
^
11 novembre 2011

htmlpdflatexmanmd




acpid

acpid

Notifier les programmes utilisateurs des évènements ACPI

   acpid est conçus pour notifier les programmes utilisateurs des évènements ACPI. acpid devrait être démarré durant le boot. Il va ouvrir le fichier d'event (/proc/acpi/event) et tenter de lire toutes les lignes qui représentent les events ACPI. S'il n'existe pas, acpid tente de se connecter au kernel linux via la couche d'entrée et netlink. Quand un event ACPI est reçu d'une de ces sources, acpid examine une liste de règles, et exécute les règles qui matchent l'event. Il ignore tous les events ACPI entrant si un fichier /var/lock/acpid existe.

   Les règles sont définies par de simples fichiers de configuration (dans /etc/acpi/events par défaut), et parcoure tous les fichiers réguliers. Les lignes blanches, ou commençant par un '#' sont ignorés. Chaque ligne a 3 tokens: la clé, un signe '=' et la valeur. La clé peut avoir 63 caractères, et est sensible à la casse. La valeur d'event est une expression régulière.

   La valeur de l'action est une ligne de commande, qui sera invoqué via /bin/sh quand un event match la règle. La ligne de commande peut contenir des caractères spéciaux et seront préservés. Le seul caractère spécial dans la valeur action est '%'. La chaîne %e remplace le texte de l'event. %% sera remplacé par %.

   Cette fonctionnalité permet à plusieurs règles d'être définies pour le même event. Pour forcer acpid à recharger les règles de configuration, lui envoyer un SIGHUP.

   En plus des fichiers de règles, acpid accepte également des connections sur un socket UNIX (/var/run/acpid.socket par défaut). Une fois connecté, acpid envoie le texte de tous les events ACPI au client. acpid ne ferme pas le socket client excepté dans le cas d'un SIGHUP ou quand acpid se termine.

   acpid log toutes ses activités dans sysylog.

OPTIONS

-c, --confdir Répertoire contenant les fichiers de règle. (défaut /etc/acpi/events)
-C, --clientmax Nombre max de connections socket non-root (défaut 256)
-d, --debug Mode debug
-e, --eventfile Fichier d'event lu par acpid (défaut /proc/acpi/event)
-n, --netlink force acpid à utiliser l'interface netlink du kernel pour les events ACPI
-f, --foreground Ne se daemonise pas
-l, --logevents log les informations de tous les events et actions
-L, --lockfile Fichier lock (défaut : /var/lock/acpid)
-g, --socketgroup Change le groupe propriétaire du socket où acpid publie les events
-m, --socketmode change les permissions du socket UNIX (défaut 0666)
-s, --socketfile Nom du socket à utiliser (défaut : /var/run/acpid.socket)
-S, --nosoket N'ouvre pas de socket UNIX
-p, --pidfile Fichier pid (défaut /var/run/acpid.pid)

Exemples

Éteindre le système si vous appuyez sur le bouton power:
event=button/power
action=/etc/acpi/power.sh "%e"
ce script contenant:
/sbin/shutdown -h now "Power button pressed"
^
11 novembre 2011

htmlpdflatexmanmd




acpi_listen

acpi_listen

Écouteur d'évènement ACPI

   Simple utilitaire qui se connecte à acpid et écoute les events. Quand un event se produit, acpi_listen l'affiche sur stdout.

OPTIONS

-c, --count events Nombre d'events max à recevoir avant de quitter
-s, --socketfile filename Change le nom de socket de domaine UNIX qu'acpid ouvre. Défaut : /var/run/acpid.socket
-t, --time seconds Écoute pendant la période spécifiée, et quitte
^
03 novembre 2011

htmlpdflatexmanmd




add-shell

add-shell

Ajoute des interpréteurs à la liste des interpréteurs initiaux valables

   Copie /etc/shells dans /etc/shells.tmp, ajoute les interpréteurs de commande à ce fichier, puis copie ce fichier temporaire dans /etc/shells. Le chemin complet de l’interpréteur doit être fournis.

^
11 février 2014

htmlpdflatexmanmd




addpart

addpart

Informe le kernel Linux d'une nouvelle partition. Cette commande ne manipule pas les partitions du disque

OPTIONS

device Spécifie le périphérique disque
partition Spécifie le numéro de partition
start Spécifie le début de la partition (en secteurs de 512 octets)
length Spécifie la longueur de la partition (en secteurs de 512 octets)
^
29 octobre 2011

htmlpdflatexmanmd




adduser

adduser, addgroup

Ajoute un utilisateur ou un groupe au système, en fonction des options fournies en ligne de commandes ou du fichier /etc/adduser.conf

   Sans les options --system ou --group, ajoute un utilisateur normal. Par défaut, chaque utilisateur se voit attribuer un groupe avec son nom propre. adduser crée un répertoire personnel en fonction de DHOME, GROUPHOMES et LETTERHOMES.

   Si le fichier /usr/local/sbin/adduser.local existe, il est exécuté une fois que l'utilisateur ait été configuré, de façon à réaliser des opérations propres au système. Les paramètres passés à adduser.local sont:

  nom_utilisateur uid gid répertoire_personnel

   La variable d'environnement VERBOSE est positionnée comme suit:

0 si --quiet est spécifié
1 si --quiet et --debug ne sont pas spécifiés
2 si --debug est spécifié

   Par défaut, les utilisateurs systèmes sont placés dans le groupe nogroup. Une répertoire personnel est créé avec les même règles que pour les utilisateurs normaux. Le nouvel utilisateur aura /bin/false comme interpréteur de commande (sans --shell spécifié), et aura un compte désactivé. Les fichiers squelette ne sont pas copiés.

OPTIONS

--conf utilise le fichier spécifié plutôt que /etc/adduser.conf
--disabled-login N'utilise pas passwd pour fixer le mot de passe.
--disabled-password idem, mais les connexion sont toujours possibles.
--force-badname Par défaut, les utilisateurs et les groupes sont comparés à l'expression rationnelle NAME_REGEX. Force à ne réaliser qu'une faible vérification du nom
--gecos Fixe le champ gecos
--gid Force le GID du groupe
--group avec --system, un groupe système est créé avec le même nom que le compte système. sans --system, un groupe avec le nom fournis est créé.
--home Définit le répertoire personnel
--shell Spécifie le shell par défaut
--ingroup ajoute le nouvel utilisateur au groupe spécifié exisitant
--no-create-home Ne créé pas le répertoire personnel
--quiet mode silencieux
--debug Mode debug
--system crée un utilisateur ou un groupe système
--uid Force l'UID de l'utilisateur
--firstuid Force la limite inférieur des UID (remplace FIRST_UID)
--lastuid Force la limite supérieur des UID (remplace LAST_UID)
--add_extra_groups Ajoute le user aux groupes spécifiés

Valeurs de retours

0 l'utilisateur existe
1 La création à échoué
^
29 octobre 2011

htmlpdflatexmanmd




adduser.conf

adduser.conf

Fichier de configuration pour adduser et addgroup

DSHELL Interpréteur de commande principal (défaut /bin/bash)
DHOME Répertoire personnel initial (défaut : /home)
GROUPHOMES à yes, les répertoires personnels sont sous la forme /home/[nomgroupe]/utilisateur (défaut no)
LETTERHOMES à yes, les répertoires personnel créés seront sous la forme /home/u/utilisateur (défaut no)
SKEL Répertoire contenant les fichiers de configuration des utilisateurs à copier dans le home/ (défaut /etc/skel)
FIRST_SYSTEM_UID
LAST_SYSTEM_UID Plage d'UID pour les comptes systèmes (défaut 100 - 999)
FIRST_UID
LAST_UID Plage d'UID pour les comptes réguliers (défaut 1000 - 29999)
FIRST_SYSTEM_GID
LAST_SYSTEM_GID Plage de GID pour les groupes systèmes (défaut 100 - 999)
FIRST_GID
LAST_GID Plage de GID pour les groupes réguliers (défaut 1000 - 29999)
USERGROUPS à yes, chaque utilisateur se verra attribuer son propre groupe. à no, chaque utilisateur sera placé dans le group dont le GID est USERS_GID. (défaut yes)
USERS_GID ce GID est donné à tous les utilisateurs si USERGROUPS est à no (défaut 100).
DIR_MODE permission sur les répertoires créés (défaut 0755)
SETGID_HOME à yes, les répertoires personnels des utilisateurs qui possèdent leur propre groupe auront le bit setgid positionné (défaut no).
QUOTAUSER non vide, les quotas des nouveaux utilisateurs sont les même que ceux de cet utilisateur.(défaut vide)
NAME_REGEX Expression rationnelle de validation des noms des utilisateurs et groupes. (défaut ^[a-z][-a-z0-9]*$)
SKEL_IGNORE_REGEX les fichiers dans /etc/skel/ sont comparés à cette expréssion rationnelle et ne sont pas copiés quand ils correspondent.
ADD_EXTRA_GROUPS autre que 0, les nouveaux groupes système sont ajoutés aux groupes de la liste EXTRA_GROUPS (défaut 0)
EXTRA_GROUPS liste des groupes additionnels auxquels sont ajoutés les utilisateurs non-système. (défaut dialout cdrom floppy audio video plugdev users games).

Vérification des noms

   adduser et addgroup forcent la conformité à la norme IEEE std 1003.1-2001 qui ne permet que les caractères suivant dans les noms de groupes et d'utilisateur: lettres, chiffres, _, points, arobases, -. Le nom peut commencer par un '-'. Le '$' est autorisé à la fin des noms d'utilisateurs (pour samba).
^
28 mai 2017

htmlpdflatexmanmd




AIDE

AIDE

Advanced Intrusion Detection Environment

   AIDE est un vérificateur d'intégrité de fichier.

Commandes

--check, -C Vérifie les inconsistances de la base de donnée.
--init, -i Initialise la base de données
--update, -u Vérifie la base de données, et met à jours la base non-interactivement.
--compare, -E Compare 2 bases. Elles doivent être définis dans un fichier de configuration avec database=[url] et database_new=[url]
--config-check, -D Vérifie la configuration est s'arrête

Paramètres

-c, --config= Fichier de configuration. Défaut: ./aide.conf.
-l, --limit=REGEX Limite la commande aux entrées correspondant à l'expression.
-B, --before="configparameters" paramètre gérés avant de lire le fichier de configuration
-A, --after="configparameters" Paramètres gérés après avoir lu le fichier de configuration
-V, --verbose=verbosity_level Verbosite de aide (0-255) Défaut: 5
-r, --report=reporter Url où envoyer la sortie.

Diagnostique

   Normalement, le code de sortie est 0 si aucune erreur n'est survenue. Excepté pour --check, --compare, et --update, les codes de sortie sont:

1 Nouveaux fichiers detecté
2 fichiers supprimés
4 Fichiers modifiés
14 Erreur d'ecriture
15 argument invalide
16 Fonction non-implémentée
17 erreur de coniguration
18 Erreur d'E/S
19 Erreur de version
^
28 mai 2017

htmlpdflatexmanmd




aide-attributes

aide-attributes

Décoder et comparer des numéro d'attributs encodés en hexa

   aide-attributes décode les numéro d'attribut en noms d'attributs ou affiche les différences entre 2 numéro d'attribut. Ce script est utile pour décoder les numéros d'attributs affichés dans la base.

Exemples

Décoder le numéro c3d:
› aide-attributes c3d
filename
perm
uid
gid
size
bount
lnkcount

Afficher les différences entre 2 numéros d'attribut
aide-attributes c3d fbd
+ctime
+mtime
+inode
^
28 mai 2017

htmlpdflatexmanmd




aide.conf

aide.conf

Fichier de configuration aide

Configuration

database url depuis laquelle la base est lue.
database_out url où écrire la nouvelle base
database_new url où trouver d'autres base pour --compare
database_attrs Attributs des fichiers de base qui sont ajouté au rapport final en mode verbeux l2+.
database_add_metadata (bool) Ajoute la version AIDE et la date de la génération de la base en commentaire du fichier de base.
verbose Verbosité des messages (0-255)
report_url url où écrire la sortie. Peut être spécifié plusieurs fois
report_base16 (bool) encode en base16 les checksum dans les rapport au lieu de base64
report_detailed_init (bool) Ajoute les fichiers (verbole ›=2) et leurs détails (verbose ›=7) dans le mode initialisation.
report_quiet (bool) supprime la sortie de rapport si aucune différence dans la base n'a été trouvée
gzip_dbout (boo) compresse la sortie de la base.
root_prefix Préfixe en enlever de chaque nom de fichier dans le système de fichier avant d'appliquer les règles et l'écriture en base.
acl_no_symlink_follow (boo) suit les liens symboliques
warn_dead_symlinks (bool) Alerte sur les liens morts
grouped (bool) groupe les fichiers dans le rapport par fichiers ajoutés, supprimés ou changés
summarize_changes (bool) créé un sommaire dans les sections des fichiers ajoutés, supprimés, ou changés.

           Le format général est YlZbpugamcinCAXSE:

                Y Type de fichier (f,d,l,c,b,p ou s, ! si le type a changé, et ? sinon)
                Z = indique que la taille a changé, ‹ reporte une taille réduite, et › une taille augmentée
                Les autres lettres sont affichées si l'attribut associé a été changé, ou un '.' pour aucun changement, '+' si l'attribut a été ajouté, '-' s'il a été supprimé, ':' s'il est ignoré ou ' ' si l'attribut n'a pas été vérifié. Exception: (1) un fichier nouvellement créé remplace chaque lettre avec '+', (2) un fichier supprimé remplace chaque lettre avec '-'. L'attribut associé avec chaque lettre:

                        l le nom du lien a changé
                        b Le compteur de block a changé
                        p Les permissions ont changé
                        u l'uid a changé
                        g le gid a changé
                        a La date d'accès a changé
                        m La date de modification a changé
                        c La date de changement a changé
                        i L'inode a changé
                        C Un ou plusieurs checksum a changé
                        A L'acl a changé
                        X les attributs étendus ont changés
                        S Les attributs SELinux ont changé
                        E Les attributs de fichier dans le fs ext2 ont changé

report_ignore_added_attrs Liste d'attributs dont l'ajout est ignoré du rapport final
report_ignore_removed_attrs Liste d'attributs dont la suppression est ignoré du rapport final
report_ignore_e2fsattrs Liste sans délimiteur d'attributs de fichier ext2 qui sont ignorés dans le rapport final. voir chattr. 0 = ignore tous les attributs.
config_version Valeur affichée dans le rapport et dans la base.
Group definitions Si le paramètre n'est pas un des précédents paramètres, il est considéré comme une définition de groupe. La valeur est considérée comme une expression.

Sélections

   AIDE supporte 3 type de lignes de sélection:

        Expression régulière ‹regex› ‹group›
        Sélection négative !‹regex›
        Sélection d'égalité =‹regex› ‹group›

           Chaque expression régulière doit commencer par '/'. Un '^' implicite est ajouté à chaque expression.

Sélection restreinte

   Ces lignes sont des lignes de sélection mais peuvent être restreint à des types de fichier. Les types suivants sont supportés:

        f fichier régulier
        d répertoire
        l lien symbolique
        c fichier caractère
        b Fichier block
        p FIFO
        s Socket UNIX

           Les types sont séparés par un ','. La syntaxe est la suivante:

        sélection restreinte normale
        ‹regex› ‹file types› ‹group›
        Selection inversée
        !‹regex› ‹file types›
        Sélection égale
        =‹regex› ‹file types› ‹group›

Exemples

N'ajoute que les répertoire et fichier dans la base:
/ d,f R
Ajouter tout sauf les répertoires
^/run d
/run R
Utiliser une règle spécifique pour les répertoires
/run d R-m-c-i
/run R

Macro

@@define VAR val Définis une variable
@@undef VAR supprime une variable
@@ifdef VAR, @@ifndef VAR Déclaration conditionnelle
@@ifhost hostname, @@ifnhost hostname Déclaration conditionnelle
@@{VAR} Substitution de variable
@@else Définis une partie else d'une déclaration if
@@endif Termine une déclaration if
@@include VAR Inclus de fichier dans la configuration

URL

   Les url peuvent être:

stdout
stderr
stdin
file://filename
fd:number

Groupe par défaut

p permissions
ftype type de fichier
i inode
l nom du lien
u utilisateur
g groupe
s taille
b compteur de block
m mtime
a atime
c ctime
S vérifier si la taille grandis
I ignore le noms de fichier changés
ANF autorise de nouveaux fichiers
ARF autorise les fichiers supprimés
md5
sha1
sha256
sha512
rmd160
tiger
haval
crc32
gost
whirlpool checksums
acl liste de contrôle d'accès
selinux Attributs SELinux
xattrs Attributs étendus
e2fsattrs attributs de fichier dans un fs ext2
R p+ftype+i+l+n+u+g+s+m+c+md5+X
L p+ftype+i+l+n+u+g+X
E groupe vide
X acl+selinux+xattrs+e2fsattrs
p+ftype+l+u+g+i+n+S+X
^
28 mai 2017

htmlpdflatexmanmd




aideinit

aideinit

Créer une nouvelle base AIDE

   aideinit initialise une base AIDE à l'emplacement database_out.

OPTIONS

-y, --yes écrase le fichier database_out
-f, --force Force l'écrasement de la base avec une nouvelle
-c, --config Fichier de configuration alternatif
-o, --output Fichier de sortie alternatif
-d, --database Fichier de base alternatif
-b, --background Lance en tâche de fond.
^
30 août 2015

htmlpdflatexmanmd




alien

alien

Convertit ou installe un paquet binaire alien

   alien est un programme qui convertit les formats de fichier Red Hat rpm, Debian deb, Stampede slp, Slackware tgz, et Solaris pkg. Il supporte également les paquet LSB.

   alien ne devrait pas être utilisé pour remplacer des paquets systèmes important et essentiels. Beaucoup de ces programmes sont définis différemment entre les différentes distributions et ne sont pas interchangeable.

Notes sur les formats

rpm Pour convertir depuis et vers le format rpm, le gestionnaire de paquet Red-Hat doit être installé
lsb À la différence d'autres formats de paquet, alien peut manipuler les dépendances des paquets lsb si le paquet de destination le supporte.
deb Pour convertir vers (mais pas depuis) le format deb, les paquets gcc, make, debhelper, dpkg-dev et dpkg doivent être installés.
tgz En convertissant depuis le format tgz, alien génère simpement un paquet de sortie qui a les même fichiers que l'archive.
pkg Pour manipuler les paquets au format Solaris, les outils pkginfo et pkgtrans sont nécessaires

OPTIONS

-d, --to-deb crée des paquets debian.
-r, --to-rpm crée des paquets rpm
-t, --to-tgz Créé des paquets tgz
--to-slp Créé des paquets slp
-p, --to-pkg Créé des paquets solaris
-i, --install Install automatiquement chaque paquet généré, et supprime le fichier une fois installé.
-g, --generate Génère un répertoire temporaire pour construire un paquet, mais ne créé par le paquet.
-s, --single Tente de convertir les scripts qui servent lors de l'installation et de la suppression du paquet
--patch=patch Spécifie le patch à utilisé au lieu de regarder automatiquement dans /var/lib/alien. N'a d'effet que sur un paquet debian
--anypatch Est moins strict sur les fichiers patch utilisés. Tente d'utiliser un fichier patch depuis une ancienne version du paquet.
--nopatch N'utilise aucun patch
--description=desc Spécifie une description pour le paquet. N'a d'effet que pour le format tgz
--version=version Spécifie une version pour le paquet. N'a d'ennet que pour le format tgz
-T, --test Test le paquet généré. Supporté pour les paquets debian, et si lintian est installé.
-k, --keep-version Par défaut, alien ajoute un numéro de version mineur à chaque paquet qu'il convertit. Cette option l'en empêche.
--bump=number Au lieu d'incrémenter le numéro de version de 1, incrément par le nombre donné
--fixperms paquet debian: assainis les propriétaires de fichier et les permissions.
--target=architecture Force l'architecture du paquet généré à la chaîne donnée
-v, --verbose Affiche chaque commande qu'alien lance dans le traitement
--veryverbose génère beaucoups d'informations sur le traitement

Exemples

Convertit un paquet Red-Hat en paquet Debian
alien --to-deb package.rpm
Convertit un paquet Debian en paquet Red-Hat
alien --to-rpm package.deb
Convertit un paquet Red-Hat en paquet Debian et l'installe
alien -i package.rpm
Créé 9 nouveaux paquets. Quand c'est fait, foo bar et baz sont disponible dans 4 formats:
alien --to-deb --to-rpm --to-tgz --to-slp foo.deb bar.rpm baz.tgz

Variables d'environnement

RPMBUILDOPT Options à passer à rpm quand il construit le paquet
RPMINSTALLOPT Options à passer à rpm quand il construit le paquet
EMAIL alien assume que c'est votre adresse email, qui est incluse dans les paquets Debian
^
22 mai 2010

htmlpdflatexmanmd




anacron

anacron

Planification des tâches sur des systèmes non-permanents

   Anacron peut être utilisé pour exécuter des commande périodiquement, avec une fréquence spécifiée en jours. À la différence de cron, il n'assume pas que la machine fonctionne en continu.

  Quand il est exécuté, Anacron lis une liste de jobs depuis un fichier de configuration, normalement /etc/anacrontab. chaque entrée est spécifié une période en jours, un délai en minutes, un id unique, et une commande.

  Pour chaque tâche, Anacron vérifie si elle a été exécutée dans les n derniers jours, où n est la période spécifiée pour ce job. Sinon, anacron lance la commande, après avoir attendu le nombre de minute spécifié dans le paramètre de délai.

  Une fois toutes les tâches exécutées, anacron se termine. Si une tache génère une sortie sur la sortie standard ou l'erreur standard, la sortie est mailé à l'utilisateur lançant la commande (généralement root) ou à l'utilisateur contenu dans MAILTO si définie.

OPTIONS

-f force l'exécution des tâches, ignorant le temps spécifié.
-u Update uniquement le temps à la date courante, mais ne lance rien.
-s Sérialise l'exécution des tâche : ne lance une tâche que lorsque la précédente s'est terminée.
-n  Lance les tâches maintenant, ignorant les délais. Cette options implique -s
-d Ne place pas en tâche de fond
-q supprime les message sur l'erreur standard. Seulement applicable avec -d
-t spécifie le fichier anacrontab (défaut /etc/anacrontab)
-T Test le fichier de configuration. retourne 1 s'il y'a une erreur.
-S utilise le dossier spécifié pour stocker les dates d'exécution.
^
22 mai 2010

htmlpdflatexmanmd




anacrontab

anacrontab

Installer/Désinstaller des tâches anacron

le format de ce fichier est:
période délais job-identifier commande

période est spécifié en jours. Période peut également prendre la valeur @monthly
délai est spécifié en minutes
job-identifier peut contenir n'importe quel caractère non-blanc hormis '/'. Il est utilisé pour identifier la tâche dans les messages Anacron.

^
24 mars 2017

htmlpdflatexmanmd




ANSI-INCITS_359-2004

ANSI-INCITS_359-2004

Le modèle de contrôle d'accès basé sur des rôles

Scope

   Ce standard consiste de 2 parties - le modèle de référence RBAC, et la spécification fonctionnelle système et administrative de RBAC.

   Le modèle de référence RBAC définis un jeu d'éléments de base RBAC (par exemple, des utilisateurs, des rôles, des permissions, opérations et objets) et les relations comme les types et fonctions qui sont incluses dans ce standard. Le modèle de référence RBAC sert 2 buts. D'abord, il référence le périmètre des fonctionnalités RBAC qui sont incluses dans le standard. Il identifie le jeu minimum de fonctionnalités inclus dans tous les système RBAC, les aspects de la hiérarchie de rôle, de relations de contraintes statiques, et de relations de contraintes dynamiques. Ensuite, le modèle de référence fournis un langage précis et consistant, en termes de jeux d'éléments et de fonctions à utiliser pour la définition de spécification fonctionnelles.

   Le système RBAC et la spécification fonctionnelle système et administrative RBAC spécifient les fonctionnalités qui sont requises d'un système RBAC. Ces fonctionnalités remplissent 3 catégories, les opérations administratives, les revues administratives, et la fonctionnalité de niveau système. Les opérations administratives définissent les fonctions en terme d'interface administrative et un jeu associé de sémantiques qui fournissent la capacité de créer, supprime et maintenir des éléments RBAC et des relations (ex, pour créer et supprimer des assignements de rôle utilisateur). Les fonctionnalités de revue administratives définissent des fonction en terme d'interface administratives et un jeu associé de sémantiques qui fournissent la capacité d'effectuer des opérations de requêtes sur des éléments et des relations RBAC. La fonctionnalité niveau système définie les fonctionnalité pour la création de sessions utilisateurs pour inclure l'activation/désactivation de rôles, les contraintes forcées dans l'activation de rôle, et pour le calcul d'une décision d'accès.

Conformité

   Toutes les fonctionnalités RBAC ne sont pas appropriées pour toutes les applications. Ce standard fournis une méthode de packaging de fonctionnalité via la sélection de composants fonctionnels et optionnels dans un composant, commençant avec un jeu cœur des fonctionnalité RBAC qui doivent être inclus dans tous les packages.

Conformité

   Pour ce conformer à ce standard, un système RBAC doit être conforme avec tout le jeu core des spécification fonctionnelles RBAC dans la clause 6.1. La conformité d'un système RBAC à d'autres spécification fonctionnelles pour un composant particulier et options, trouvés dans les clauses 6.2 à 6.4, est optionnel et dépendent des exigences fonctionnelles d'une application particulière.

Termes et définitions

Composant réfère à un des blocks majeurs des fonctionnalités RBAC.
Objets Peut être une ressource système sujet à contrôle d'accès, tel qu'un fichier, une imprimante, etc.
Opérations image exécutable d'un programme, qui à l'invocation exécute une fonction pour l'utilisateur.
Permissions Approbation pour effectuer une opération dans un ou plusieurs objets Protégés par RBAC.
role job d'un humain. bien que le concept d'utilisateur peut être étendus pour inclure des machines, réseaux, etc., la définition est limitée à une personne dans ce document.

Le modèle de référence RBAC

   Il est définis en terme de 4 composants: le cœur RBAC, La hiérarchie RBAC, séparation statique des privilèges, et séparation dynamique des privilèges. Le cœur RBAC définis une collection minimum d'éléments RBAC, de jeux d'éléments, et des relations pour achever le système RBAC. Cela inclus l'assignement de rôle utilisateur et les relations d'assignement permission/rôle, considérés comme fondammental dans un système RBAC. De plus, le cœur RBAC introduit le concept d'activation de rôle comme faisant partie d'une session utilisateur. Le cœur RBAC est requis dans tout système RBAC, mais les autres composants sont indépendants des autres et peuvent être implémentés séparémments.

   La hiérarchie RBAC ajoute les relations pour supporter les hiérarchies de rôle. Une hiérarchie est mathématiquement un ordre partiel définissant une relation d'apparentée entre les rôles, où les rôles séniors acquièrent les permissions de leurs juniors et les rôles juniors acquièrent les utilisateurs de leurs sénior. De plus, la hiérarchie RBAC va au-delà du simple assignement utilisateur et permission en introduisant le concept de jeu de rôles d'utilisateurs autorisé et de permissions autorisées. La séparation statique des relations de privilège ajoute des relations exclusives avec les rôles en respect des assignements utilisateur. À cause de potentiels inconsistances d'un hiérarchie de rôle, le modèle de relation SSD définis les relations sur la présence et l'absence des hiérarchies de rôle. La séparation dynamique des relations de privilèges définis les relations exclusives en respect des rôles qui sont activés, faisant partie de la session utilisateur.

   Chaque composant est définis par les sous-composants suivants:

- Un jeu de jeux d'éléments de base
- Un jeu de relations RBAC impliquant ces éléments (contenant des sous-jeu de produits cartésiens dénotant une assignement valide)
- Un jeu de fonction de mappage, qui maintiennent des instances de membre d'un éléments, définis pour une instance donnée depuis un autre jeu d'élément.

   Il est important de notser que le modèle de référence RBAC définis une taxonomie des fonctionnalités RBAC qui peuvent être composés en un nombre de package de foncionnalités. Au lieu de tenter de définir un jeu complet de fonctionnalité RBAC, ce modèle de concentre à produire un jeu standard de termes pour définir les foncitonnalités les plus saillantes comme représenté dans les modèles existants et implémenté dans les produits commerciaux.

cœur RBAC

   Le cœur RBAC inclus les jeux de 5 éléments de données de base appelés des utilisateurs (USERS), des rôles (ROLES), des objets (OBS), des opérations (OPS), et des permissions (PRMS). Le modèle RBAC dans son ensemble est fondamentalement définis en terme d'utilisateurs individuels étant assignés aux rôles et de permissions étant assignés aux rôles. Ainsi, un rôle est un moyen de nommer des relations many-to-many entre des individus et des permissions. De plus, le modèle du cœur RBAC inclus un jeu de sessions (SESSIONS) où chaque session est un mappage entre un utilisateur et un sous-jeu activé de rôle qui sont assignés à l'utilisateur.

   Un utilisateur est définis comme une personne. Bien que le concept d'un utilisateur peut être étendus pour inclure des machines, réseaux, ou des agents autonomes intelligents, la définition est limitée à une personne dans ce document pour des raisons de simplicité. Un rôle est une fonction (job) dans le contexte de l'organisation avec des sémantiques associées avec l'autorité et la responsabilité conférée à l'utilisateur assigné au rôle. Les permissions sont une approbation pour effectuer une opération sur un ou plusieurs objets protégés par RBAC. Une opération est une image exécutable d'une programme, qui à l'invocation exécute certaines fonctions pour l'utilisateur. Les types d'opérations et objets que RBAC contrôle sont dépendant du type de systèmes dans lequel il est implémenté. Par exemple, dans un système de fichier, les opérations peuvent inclure lire, écrire, et exécuter; dans une base de données, les opérations peuvent inclure insert, delete, append, et update.

   Le but de tout mécanisme de contrôle d'accès est de protéger les ressources système. Consistant avec les anciens modèles de contrôle d'accès un objet est une entité qui contient ou reçois des informations. Pour un système qui implémente RBAC, les objets peuvent représenter des conteneurs d'informations (par exemple des fichiers, répertoires, un système d'exploitation, colonnes/lignes/tables/views dans une base de données), ou des objets qui représentent des ressources systèmes exhaustives, tels qu'une imprimante, espace disque, et cycles CPU. Le jeu d'objets couvert par RBAC inclus tous les objets listés dans les permissions qui sont assignés aux rôles.

   Le centre de RBAC est le concept de relation de rôle, autour duquel un rôle est une construction sémantique pour formuler des stratégies. La figure ci-dessous illustre les relations d''assignement utilisateur (UA) et d'assignement de permission (PA). Les flèches indiquent une relation many-to-many (ex: un utilisateur peut être assigné à un ou plusieurs rôles, et un rôle peut être assigné à un ou plusieurs utilisateurs. Cet arrangement fournis une grande flexibilité et granularité d'assignement des permissions aux rôles et des utilisateurs aux rôles. Sans cela il y a un risque qu'un utilisateur puisse obtenir plus d'accès aux ressources que nécessaire à cause du contrôle limité sur le type d'accès qui peut être associé avec les utilisateurs et les ressources. Les utilisateurs peuvent souhaiter lister les répertoires et modifier les fichiers existants, par exemple, sans créer de nouveaux fichiers, ou ils peuvent souhaiter ajouter des enregistrements à un fichier sant modifier d'enregistrements existants. Tout augmentation dans la flexibilité du contrôle d'accès aux ressources renforce également l'application du principe de moins de privilège.

Core RBAC
   Chaque session est un mappage d'un utilisateur à possiblement plusieurs rôles. Un utilisateur établis une session durant laquelle l'utilisateur active des sous-jeux de rôles auquel il est assigné. La fonction session_roles nous donne les rôle activés par la session et la fonction session_users nous donne l'utilisateur qui est associé avec une session. Les permissions disponibles à l'utilisateur sont les permissions assignées aux rôle qui sont actuellement actifs au travers de toutes les sessions utilisateur.

Hiérarchie RBAC

   Ce modèle introduit des hiérarchies de rôle (RH), communément inclus comme un aspect clé des modèles RBAC. Les hiérarchies sont un moyen naturel de structurer les rôles pour refléter les lignes d'autorité et de responsabilité d'une organisation.

   Les hiérarchies de rôle définissent une relation d'héritage avec les rôles. L'héritage a été décrit en terme de permission, par exemple, r1 hérite du rôle r2 si tous les privilèges de r2 sont également privilèges de r1. Pour certaines distribution de RBAC les permissions de rôle ne sont pas gérés centralement, bien que ces hiérarchies de rôle le soient. Pour ces systèmes, les hiérarchies de rôle sont gérés en terme de relations de contention utilisateur. Les rôle r1 contient le rôle r2 si tous les utilisateurs autorisés pour r1 sont également autorisés pour r2. Noter, cependant, que la contention d'utilisateur implique qu'un utilisateur de r1 ais (au moins) tous les privilèges de r2, alors que l'héritage de permissions pour r1 et r2 n'impliquent rient sur l'assignement de l'utilisateur.

hierarchical RBAC
   Ce standard reconnaît 2 types de hiérarchies de rôle - les hiérarchies de rôle générales et les hiérarchies de rôle limitées. Les hiérarchies de rôle générales fournissent un support pour un ordre arbitraire partiel pour servir de hiérarchie de rôle, pour inclure le concept d'héritage multiple des permissions et de membership via les rôles. Les hiérarchies de rôle limitées imposent des restrictions résultant en une structure plus simple (par exemple, un rôle peut avoir un ou plusieurs ascendants immédiats, mais est restreints à un seul descendant immédiat).

Hiérarchies de rôle générales

   Les hiérarchies de rôle générales supportent le concept d'héritage multiple, qui fournis la capacité d'hériter les permissions de 2 ou plusieurs rôles source et d'hériter des utilisateurs membre de 2 ou plusieurs rôles sources. l'héritage multiple fournis 2 propriétés de hiérarchie importantes. La première est la capacité de composer un rôle depuis plusieurs rôles subordonnés (avec moins de permissions) en définissant des rôles et relations qui sont caractéristiques de l'organisation et de structures métier, que ces rôle représentent. Ensuite, l'héritage multiple fournis un traitement uniforme des relations d'assignement utilisateur/rôle et des relations d'héritage rôle/rôle.

   Les rôle dans une hiérarchie de rôle limitée sont restreints à un simple descendant immédiat. Bien que les hiérarchies de rôle limités ne supportent pas l'héritage multiple, elles ne fournissent pas d'avantage administratif claire sur Core RBAC.

   Une hiérarchie de rôle générale peut être représenté en diagramme de Hasse. Les nœuds dans le graphique représent les rôles de la hiérarchie et il y a un ligne direct entre r1 et r2 si r1 est un descendant immédiat de r2.

Contraintes RBAC

   Les contraintes RBAC ajoute les relations de séparation des privilèges au modèle RBAC. Ces relation sont utilisées pour forcer un conflit d'interêt des stratégies que les organisations peuvent employer pour empêcher les utilisateurs d'excéder un niveau raisonnable d'autorité pour leur positions.

   Le conflit d'interêt dans un système basé sur les rôles peut se produire comme résultat d'un gain d'autorisation pour des permissions associés avec les rôles en conflit. Pour empêcher cette forme de conflit, la séparation de privilèges statique force les contraintes dans l'assignement des utilisateurs aux rôles. Les contraintes statiques peuvent prendre un variété de formes différentes.

   Les contraintes statiques définies dans ce modèle sont limitées à ces relations qui placent des restrictions dans les jeux de rôle et en particulier dans leur capacité à former les UA. Cela signifie que si un utilisateur est assigné à un rôle, l'utilisateur se voit refuser l'appartenance d'un second rôle. Une stratégie SSD peut être centralement spécifiée et imposée uniformément dans des rôles spécifiques.

   Les modèles RBAC ont définis des relations SSD en respect aux contraintes dans les assignements user-role sur des paires de rôles. Bien que dans le monde réel des stratégies SSD existent, cette définition est trop restrictive sous 2 aspects. D'abord, la taille du jeu de rôles dans le SSD et ensuit la combinaison des rôles dans le jeu pour lequel l'assignement utilisateur est restreint. Dans ce modèle, SSD est définis avec 2 arguments. Un jeu de rôle qui inclus 2 ou plusieurs rôles et une cardinalité supérieur à un indiquent une combinaison de rôle qui constiturait une violation de la stratégie SSD. Par exemple, une organisation peut exiger qu'aucun utilisateur ne puisse être assigné à 3 des 4 rôles qui représentent la fonction d'achat.

   Comme illustr ci-dessous, les relations SSD peuvent exister dans la hiérarchie RBAC. En appliquant des relations SSD dans la présence d'une hiérarchie de rôle, une attention particulière doit être appliquée pour s'assurer que l'héritage utilisateur n'amoindri pas les stratégies SSD. Ainsi, les hiérarchies de rôle ont été définis pour inclure l'héritage des contraintes SSD. Pour adresser cette inconsistance potentielle, SSD est définis dans les utilisateurs autorisés des rôles qui ont une relation SSD.

   Les relations SSD réduisent le nombre de permissions potentielles qui peuvent être faites à un utilisateur en plaçant des contraintes dans les utilisateurs qui peuvent être assignés à un jeu de rôles. Les relations de séparation de privilège dynamique (DSD), comme les relations SSD, sont prévues pour limiter les permissions qui sont disponibles à un utilisateur. Cependant, les relations DSD diffèrent des relations SSD par le contexte dans lequel ces limitations sont imposées. Les relations SSD définissent et placent les contraintes dans l'espace de permission total de l'utilisateur. Ce modèle définis les propriétés DSD qui limitent la capacité des permissions sur une espace de permission utilisateur en plaçant des contraintes dans les rôles qui peuvent être activés avec ou au travers d'une session utilisateur. Les propriétés DSD fournissent un support étendu pour le principe du moins de privilège dans cela que chaque utilisateur a différents niveaux de permissions à des moments différents, en fonction du rôle effectué. Ces propriétés s'assurent que les permissions ne persistent pas au-dela du temps requis pour la performance du privilège. Cet aspect du moins de privilège est sous réferré à une révocation en temps utile de privilège. La révocation dynamique des permissions peut être un problème plus complexe sans les facilités de la séparation dynamique de privilèges, et a été largement ignoré dans le passé.

   Ce modèle fournis la capacité de forcer une stratégie spécifique à une organisation de séparation dynamique des privilèges (DSD). Les relations SSD fournissent la capacité d'adresser de potentiels conflits d'interêt au moment où un utilisateur est assigné à un rôle. DSD permet à un utilisateur d'être autorisé pour 2 ou plusieurs rôles qui ne créent pas de conflit lorsqu'ils agissent indépendamment, mais produit un problème de stratégie quand activé simultanément. Par exemple, un utilisateur peut être autorisé pour les rôles de caissier et de contrôleur de caisse, RBAC exige que l'utilisateur abandonne le rôle de caissier et fermet son tirroir caisse avant de passer contrôleur. Tant que ce même utilisateur n'est pas autorisé à assumer ces 2 rôles simultanément, un conflit d'interêt ne peut pas se produire.

Dynamic Separation of Duty Relations

Système RBAC et spécification fonctionnelle administrative

   La spécification fonctionnelle RBAC spécifie les opérations administratives pour la création et la maintenance de jeux d'éléments et de relations RBAC; les fonctions administratives pour effectuer les requêtes administratives; et les fonctions système pour créer et gérer les attributs RBAC dans les sessions utilisateur et prendre les décisions de contrôle d'accès. Les fonctions sont définies avec une précision suffisante pour répondre aux besoins de conformité de test et d'assurance, tout en fournissant aux développeurs la capacité d'incorporer des fonctionnalités additionnelles pour répondre aux besoins des utilisateurs.

Commandes administratives pour Core RBAC

AddUser Cette commande créé un nouvel utilisateur RBAC. La commande est valide seulement si le nouvel utilisateur n'est pas déjà membre du jeu de données USERS. Ce jeu USERS est mis à jours. Le nouvel utilisateur ne possède pas de session au moment de sa création.
DeleteUser Cette commande supprime un utilisateur existant de la base RBAC. La commande est valide si et seulement si l'utilisateur à supprimer est un membre du jeu de données USERS. Les jeux de données USER et UA et la fonction assigned_users sont mis à jours. C'est une décision d'implémentation de savoir comment procéder avec les sessions possédés par l'utilisation à supprimer.
AddRole Cette commande crée un nouveau rôle. La commande est valide si et seulement si le nouveau rôle n'est pas déjà membre du jeu de données ROLES. Le jeu ROLES et les fonctions assigned_users et assigned_permissions sont mis à jours. Initialement, aucun utilisateur ou permission n'est assigné au nouveau rôle.
DeleteRole Cette commande supprime un rôle existant de la base RBAC. La commande est valide si et seulement si le rôle est membre du jeu de données ROLES. C'est une décision d'implémentation de décidé de la manière de procéder avec les sessions dans le rôle à supprimer sont actifs.
AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et que l'utilisateur n'est pas déjà assigné au rôle. Le jeu de données UA et la fonction assigned_users sont mis à jours pour refléter l'assignement.
DeassignUser Cette commande supprime l'assignement d'un utilisareur à un rôle. Cette commande est valide si et seulement si le rôle est un des rôles actif de l'utilisateur.
GrantPermission Cette commande octroie à un rôle la permission d'effectuer une opération sur un objet à un rôle. La commande peut être implémentée pour octroyer les permissions à un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès à l'objet en question.
RevokePermission Cette commande révoque la permission d'effectuer une opération sur un objet depuis le jeu de permissions assignés à un rôle. La commande peut être implémentée pour révoquer les permissions d'un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès de l'objet en question.

Fonctions système pour Core RBAC

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire et un jeu de rôle actif. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et que le jeu de rôle actif est un sous-jeu des rôles assignés à cet utilisateur.
DeleteSession(user,session) Cette fonction supprime une session données avec un utilisateur. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'utilisateur est un membre du jeu de données USERS, et la session est possédée par l'utilisateur donné.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et l'identifiant de session est membre du jeu de données SESSIONS, et le rôle est assigné à l'utilisateur, et la session est possédée par l'utilisateur.
DropActiveRole Cette fonction supprime un rôle du jeu de rôle actif d'une session possédé par un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, l'identifiant de session est un membre du jeu de données SESSION, la session est possédées par l'utilisateur, et le rôle est un rôle actif de cette session.
CheckAccess Cette fonction retourne une valeur booléenne indiquant si le sujet d'une session données est autorisée ou non à effectuer l'opération données sur l'objet donné. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'objet est un membre du jeu de données OBJS, et l'opération est un membre du jeu de données OPS. Le sujet de la session a la permission d'effectuer l'opération sur cet objet si et seulement si cette permission est assignée à (au moins) un des rôles actifs de la session. Une implémentation peut utiliser les groupes qui correspondent aux rôle actifs du sujet et leur permission comme enregistré dans la liste de contrôle d'accés de l'objet.

Fonctions d'examen pour Core RBAC

AssignedUsers Cette fonction retourne le je d'utilisateurs assignés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
AssignedRoles Cette fonciton retourne le je de rôles assignés à l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS.

Fonctions d'examen avancé pour Core RBAC

RolePermissions Cette fonction retourne le jeu de permissions (op,obj) octroyés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne les permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
SessionRoles Cette fonction retourne les rôles actifs associés avec une session. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
SessionPermissions Cette fonction retourne les permissions de la session, par ex., les permission assignées à ses rôles actifs. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
RolesOperationsOnObject Cette fonction retourne le jeu d'opérations d'un rôle donné autorisé sur un objet donné. Cette fonction est valide seulement si le rôle est un membre du jeu de données OBJS
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur donné est autorisé à effectuer sur un objet donné, obtenu soit directement ou via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles générales

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle. La commande est valide si et seulement si les 2 rôles sont membres du jeu de données ROLES.
DeleteInheritance Cette commande supprime une relation d'héritage immédiat existante. Cette commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.
AddAscendant Cette commande créé un nouveau rôle r_asc, et l'insert dans la hiérarchie de rôle comme ascendant immédiat du rôle existant r_desc. La commande est valide si et seulement si r_asc n'est pas membre du jeu de données ROLES, et r_desc est un membre du jeu de données ROLES.
AddDescendant Cette commande créé un nouveau rôle r_desc, et l'insert dans la hiérarchie de rôle comme descendant immédiat du rôle existant r_asc. La commande est valide si et seulement si r_desc n'est pas membre du jeu de données ROLES, et r_asc est un membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôles générales

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire, et un jeu donné de rôles actifs. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, et le jeu de rôle actif est un sous-jeu autorisé pour cet utilisateur. Noter que si un rôle est actif pour une session, ses descendants ne sont pas nécessairement actifs pour cette session. Dans une implémentation RBAC, les rôles actifs d'une session peuvent être les groupes qui représentent ces rôles.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, l'utilisateur est autorisé pour ce rôle, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les hiérarchies de rôles générales

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valides. Cette section définis les fonctions suivantes:

AuthorizedUsers Cette fonction retourne le jeu d'utilisateurs autorisés pour un rôle donné, par ex., les utilisateurs qui sont assignés à un rôle qui hérite du rôle donné. La fonction est valide si et seulement si le rôle donné est un membre du jeu de données ROLES.
AuthorizedRoles Cette fonction retourne le jeu de rôles autorisés pour un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS.

Fonction d'examen avancé pour les hiérarchies de rôles générales

   Cette section redéfinis les fonction RolePermissions et UserPermissions de la section "Fonctions d'examen avancé pour Core RBAC". toutes les autres fonction de cette section sont valides.

RolePermissions Cette fonction retourne le jeu de permission(ob,obj) octroyé à ou hérité par un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne le jeu de permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
RoleOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un rôle donné est autorisé à effectuer sur un objet donné. Le jeu contient toutes les opérations octroyées directement à ce rôle ou hérité par ce rôle depuis un autre rôle. La fonction est valide seulement si le rôle est un membre du jeu de données ROLES, et l'objet est un membre de jeu de données OBJS.
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur est autorisé à effectuer sur un objet donné. Le jeu consiste de toutes les opérations obtenues par l'utilisateur directement, ou via ses rôle autorisés. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales". Toutes les autres fonctions de cette section restent valides

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiate entre les rôles existants r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonction d'examen pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonction d'examen avancé pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen avancé pour les hiérarchies de rôles générales" sont valides

Relations SSD

   La propriété de séparation des privilèges statique, tel que définis dans ce modèle, utilise une collection SSD de paires d'un jeu de rôle et un cardinalité associée. Cette section définis le nouveau type de données SSD, qui dans un implémentation peut être le jeu de noms utilisé pour identifier les paires dans la collection.

Commandes administratives pour les relations SSD

   Cette section redéfinis la fonction AssignUser de la section "Commandes administratives pour Core RBAC", et définis un nouveau jeu de fonctions spécifiques. Les autres fonction de cette section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après assignement.
CreateSsdSet Cette commande créé un jeu SSD de rôle et définis la cardinalité n de ses sous-jeu qui ne peuvent pas avoir d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rôle dans le jeu SSD sont membres du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la containte SSD pour le nouveau rôle est satisfait.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le rôle SSD existe, le rôle à ajouté est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD, et la contrainte SSD est satisfaite après l'ajout du rôle dans le jeu de rôle SSD.
DeleteSsdRoleMember Cette commande supprime un jeu de rôle SSD complètement. La commande est valide si et seulement si le jeu de rôle SSD existe.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, et la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle SSD, et la contrainte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD

   Toutes les fonctions de la section "Fonctions système pour Core RBAC" sont valides

Fonctions d'examen pour SSD

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, les fonctions suivantes sont définis:

SsdRoleSets Cette fonction retourne la liste des jeux de rôle SSD.
SsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle SSD. La fonction est valide si et seulement si le jeu de rôle existe.
SsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle SSD. La foncion est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour SSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valide.

Commandes administratives pour SSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions AssignUser et AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales", et les fonctions CreateSsdSet, AddSsdRoleMember, SetSsdSetCardinality de la section "Commandes administratives pour les relations SSD". Les autres fonctions de ces 2 section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, et le rôle est un membre du jeu de données ROLES, et l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après l'assignement.
AddInheritance Cette commande établis une nouvelle relation d'héritage entre les rôles existants r_asc, et r_desc. La commande est valide si et seulement si les rôles sont membres du jeu de données ROLES, r_asc n'est pas un ascendant direct de r_desc, _desc n'hérite pas de r_asc, et les contraintes SSD sont satisfaites après avoir établis l'héritage.
CreateSsdSet Cette commande créé un jeu SSD de rôle et les jeux de cardinalité associés n de ses sous-jeux qui n'ont pas d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rrôles dans le jeu SSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la contrainte SSD pour le nouveau jeu de rôle est satisfaite.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le jeu de rôle SSD existe, et le rôe à ajouter est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôles SSD, et la containte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonctions d'examens pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les hiérarchies de rôles générales" et "Fonctions d'examen avancé pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour SSD avec les hiérarchies de rôle limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour SSD avec les hiérarchies de rôle générales". Toutes les autres fonctions de cette section sont valides.

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES, r_asc n'a pas de descendants, et r_desc n'hérite pas de r_asc.
[SECTION] name="Fonctions système pour SSD avec les hiérarchies de rôle limitées" table="paragraphes" imbrication="0"
Toutes les fonctions de la section "Fonctions système pour SSD avec les hiérarchies de rôle générales" sont valides.

Fonctions d'examens pour SSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Fonctions système pour les hiérarchies de rôles générales" et "Fonctions d'examen pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle limitées

   Toutes les foncions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides.

Commandes administratives pour les relations DSD

   Toutes les fonctions de la section "Commandes administratives pour Core RBAC" sont valide. Cette section définis les fonctions supplémentaires suivantes:

CreateDsdSet Cette commande créé un jeu DSD de rôle et définis une cardinalité n associée. La contrainte DSD stipule que le jeu de rôle DSD ne peut pas contenir n rôle ou plus, actifs simultanément dans la même session. La commande est valide si et seulement si le nom du jeu DSD n'est pas déjà utilisé, tous les rôles dans le jeu DSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle DSD, et la contrainte DSD pour le nouveau rôle est satisfaite.
AddDsdRoleMember Cette commande ajeute un rôle à un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à ajouter est membre du jeu de données ROLES, mais non membre du jeu de rôle DSD, et la contrainte DSD est satisfaite après l'ajout du rôle dans le jeu de rôle DSD.
DeleteDsdRoleMember Cette commande supprime un rôle depuis un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à supprimer est un membre du jeu de rôle DSD, et la cardinalité associée avec le jeu de rôle DSD est inférieur au nombre d'éléments du jeu de rôle DSD.
DeleteDsdSet Cette commande supprime un jeu de rôle DSD complètement. Cette commande est valide si et seulement si le jeu de rôle DSD existe.
SetDsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle DSD donné. La commande est valide si et seulement si le jeu de rôle DSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle DSD, et la contrainte DSD est satisfaite après avoir définis la nouvelle cardinalité.
[SECTION] name="Fonctions système pour les relations DSD" table="paragraphes" imbrication="0"
Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle assigné pour le propriétaire de la session, le jeu de rôle actif de la session est un sous-jeu des rôles assignés au propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est assigné à cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD

   Toutes les fonction de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, cette section définis de nouvelles fonctions:

DsdRoleSets Cette fonction retourne la liste de tous les jeux de rôle DSD
DsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.
DsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour les relations DSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valides.

Commandes administratives pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles générales" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle autorisés pour le propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est autorisé pour cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les relations DSD" et "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles limitées" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides
^
21 mars 2017

htmlpdflatexmanmd




aoe-discover

aoe-discover

Découvrir les périphériques aoe

   Cette commande indique au pilote aoe de découvrir les périphériques AoE sur le réseaux. Toutes les interfaces sont sondées. Il est préférable de lancer aoe-discover après aoe-interfaces.

^
21 mars 2017

htmlpdflatexmanmd




aoe-flush

aoe-flush

Supprimer les périphériques déconnectés du pilote aoe

   Cette commande indique au pilote aoe de supprimer les périphériques du système. Normalement, le pilote mémorise tous les périphérique jusqu'à déchargement du pilote. Il est possible de spécifier le périphérique à oublier.

OPTIONS

-a Indique d'oublier tous les périphériques non utilisés.
^
21 mars 2017

htmlpdflatexmanmd




aoe-interfaces

aoe-interfaces

Restreint le pilote aoe aux interfaces réseaux spécifiés

   Cette commande indique au pilote aoe d'ignorer le trafic AoE sur toutes les interfaces à l'exception des interfaces spécifiées. C'est similaire à l'option aoe_iflist.

OPTIONS

-c Efface la liste des interfaces, et utilise toutes les interfaces
^
21 mars 2017

htmlpdflatexmanmd




aoe-mkdevs

aoe-mkdevs, aoe-mkshelf

Créer les fichiers de périphérique aoe

   Ces commandes sont dépréciées en faveur de udev

^
21 mars 2017

htmlpdflatexmanmd




aoe-revalidate

aoe-revalidate

revalide la taille disque d'un périphérique aoe

   Cette commande demande au pilote aoe de revalider la taille disque d'un périphérique aoe ouvert.

^
21 mars 2017

htmlpdflatexmanmd




aoe-sancheck

aoe-sancheck

Vérifie les capacités des stockages réseau

   Cette commande collecte des informations sur les interfaces locales et sonde le réseaux à la recherche de périphérique AoE, et valide les chemins pour chaque périphérique. Il n'utilise pas le pilote aoe, donc le module n'est pas nécessaire pour utiliser cette commande.

Arguments

Device Nom du périphérique sous la forme eX.Y.
Macs Nombre d'adresse MAC détectés pour ce périphérique
Payload nombre d'octets de données que le périphérique peut manipuler en une seule requête AoE.
Local Interfaces Liste des interfaces réseaux depuis lesquelles le périphérique est visible.
^
21 mars 2017

htmlpdflatexmanmd




aoe-stat

aoe-stat

Affiche des statistiques aoe

   Ce script collecte des informations sur les périphériques AoE depuis sysfs

^
21 mars 2017

htmlpdflatexmanmd




aoe-version

aoe-version

Affiche la version des logiciels liés à AoE

   Ce script collecte des informations sur le logiciel AoE installé et en cours de fonctionnement.

^
21 mars 2017

htmlpdflatexmanmd




aoecfg

aoecfg

Manipuler la configuration AoE

   aoecfg envoie des commandes de configuration AoE qui contrôle la récupération, paramètre conditionnel et inconditionnel des chaîne de configuration AoE. Vi que la configuration se produit avant que l'adresse MAC de la cible soit connu, le paquet est broadcasté. Les cibles AoE avec le shelf:slot correspondant répond. le shelf:slot par défaut est 0xffff:Oxff, qui retourne les chaînes de configuration de toutes les cibles visibles dans l'interface par défaut, eth0.

OPTIONS

-c cmd Spécifie la commande de configuration AoE. Défaut: read.

        read lit la configuration serveur
        test Répond seulement si la chaîne spécifiée matche exactement la configuration du serveur
        prefix Répond seulement si la chaîne spécifiée est un préfixe de chaîne de configuration du serveur
        set Si la chaîne de configuration serveur courante est vide, définis la chaîne de configuration serveur. Si la chaîne n'est pas vide, retourne une réponse avec le flag E mis et Error à 4.
        fset Force à définir la chaîne de configuration serveur.

-s cfgstr Spécifie la chaîne de configuration
-t timeout Spécifie le timeout en secondes.
shelf slot indiqtue le shelf et solt utilisé dans le requête. Défaut: broadcast
netif Spécifie l'interface réseau à utiliser. Défaut: eth0
^
21 mars 2017

htmlpdflatexmanmd




aoeping

aoeping

simple communication avec les périphériques AoE

   aoeping effectue une communication avec un périphérique AoE. Il crée et reçoit les paquets aoe directement, en utilisant des sockets réseaux raw.

Arguments

shelf Adresse majeur du périphérique AoE
slot Adresse mineur du périphérique AoE
netif Nom de l'interface réseaux à utiliser

OPTIONS

-i Émet une commande "identify device" après avoir reçu la réponse Config Query du périphérique.
-I idem à -i, met la sortie est plus compréhensible
-v mode verbeux
-s ‹number› Délai en secondes d'attente d'une réponse
-S Indique le nom d'une commande SMART à envoyer au disque (read_data, offline_immediate, read_log, write_log, enable, disable, return_status)
-t ‹number› tag initial du premier tag dans les commandes ATA.
^
01 février 2014

htmlpdflatexmanmd




apropos

apropos

Outils de recherche de noms et descriptions de pages de man

OPTIONS

-d, --debug Mode debug
-v, --verbose mode verbeux
-r, --regex Interprète chaque mot clé comme expression régulière
-w, --wildcard Interprète chaque mot clé comme motif contenant des wilcard style shell.
-e, --exact Chaque mot clé doit correspondre exactement
-a, --and Affiche uniquement les éléments qui matchent tous les mots clé
-l, --long Ne tronque pas la sortie.
-s list, --sections list, --section list Recherche uniquement dans ces sections
-m system[,...], --systems=system[,...] Permet d'accéder à des page de manuel d'autres OS.
-M path, --manpath=path Spécifie un jeu de chemin de man alternatifs au lieu de lire $MANPATH
-L locale, --locale=locale Remplace l'appel setlocale(3)
-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath

Variables d'environnement

SYSTEM Si le système a accès à des pages de manuel d'autres OS, permet de les inclure
MANPATH Chemin de recherche pour les pages de manuel
MANWIDTH Longueur de ligne (défaut: 80)
POSIXLY_CORRECT Si définis, interprète chaque mot clé comme expression régulière
^
15 mars 2010

htmlpdflatexmanmd




apt

apt

Gestion des paquets Debian

   Les distributions Gnu/Linux offrent une palette de logiciels divers. Afin de gérer tout ces logiciels, un système de centralisation a été mis en place. Actuellement Debian maintient 30 000 paquets environ.

Fonctionnement des Releases

   4 versions de Debian sont disponible : Experimental, unstable, testing et stable. Chacune correspondant à un stade du développement. Un logiciel peut donc exister dans plusieurs releases, mais dans des versions différentes.

   Les paquets Experimental sont des logiciels en cours de développements, non finalisés. Le statut unstable est plus courant, utilisé pour les nouveaux logiciel ou nouvelles versions. Après de nombreux tests, si le paquet n'a pas de bogues critique, il passe dans la branche testing. Puis après de long mois de tests, si le logiciel est considéré comme très fiable, il passe dans la branche stable.

   Il est donc évident que la branche la plus sûr est la stable, mais les versions des logiciels ne sont pas à jours à cause du temps nécessaire aux tests. La branche testing semble être un bon compromis mais elle pose un problème: les dépendances. En effet, pour qu'un paquet puisse passer de unstable à testing, toutes ses dépendances doivent le suivre dans cette branche en même temps, ce qui est impossible tant que certaines subissent des mises à jours régulières.

Paquet Debian

   Sous Debian, chaque logiciel est fournis sous forme de paquet de type deb. Ces paquets contiennent tous les fichiers nécessaires à l'installation, la configuration et la suppression du logiciel. Ces paquets sont manipulés à l'aide d'un outil: dpkg.

   Afin de centraliser ces logiciels, on utilise des serveurs de dépôts, généralement accessibles depuis internet. Ils permettent de télécharger et installer des logiciels, ou de les mettre à jour. il existe donc des dépôts officiels, mais chacun est libre de créer son propre serveur "non-officiel" et de maintenir ses logiciels. De nombreux logiciels libres sont maintenus par leur développeurs, sur leurs propre serveur de dépôt.

   Ces dépôts existent sous d'autres formes, par exemple sur un cd-rom (utilisé pour l'installation de Debian). le problème étant que les paquet ne peuvent pas être mis à jours à moins de regraver des cd-roms avec les paquets à jours. Il permettent néanmoins d'installer des logiciels sur des ordinateurs qui ne sont pas reliés à internet. Vous pouvez également maintenir un dépôt miroir - complet ou partiel - des dépôts officiels.

   Debian possède un mécanisme de gestion de ces dépôts. il permet de télécharger depuis ces serveurs de dépôt la liste des programmes maintenus ainsi que leurs versions. l'installation se fera ainsi aussi simplement qu'un “aptitude install logiciel” pour que le système télécharge le paquet et l'installe automatiquement. plusieurs outils et fichiers sont utilisés pour cela : apt-get et aptitude permettent d'installer, supprimer ou mettre à jours des logiciels.

   /etc/apt/sources.list est le fichier qui liste les serveurs de dépôt auprès desquels seront téléchargés les paquets. dpkg est un utilitaire pour manipuler les paquets deb.
^
15 mars 2010

htmlpdflatexmanmd




apt-get

apt-get

Gestionnaire de paquet debian

update Permet de resynchroniser un fichier répertoriant les paquets disponibles et sa source.
upgrade Permet d'installer les versions les plus récentes de tous les paquets présents sur le système.
dselect-upgrade Utilisé conjointement avec dselect. Suit les modifications faites par dselect dans le champ statut des paquets disponibles, et effectue les actions nécessaires à la réalisation de cet état.
dist-upgrade Effectue la fonction upgrade en y ajoutant une gestion intelligente des changements de dépendances dans les nouvelles versions des paquets. Essaye quand c'est possible de mettre à niveau les paquets les plus importants au dépends des moins important.
install Permet d'installer des paquets. un '-' pour supprimer, et "+" pour installer. on peut aussi spécifier une version pas "=version", et une distri: "/distri". les motifs fonctionnent avec ".", " ?" ou "*", ou encore "^" ou "$".
remove identique à install mais permet de supprimer des paquets
source récupère des paquets sources. si l'option --compile est spécifiée, le paquet est compilé en un binaire .deb avec dpkg-buildpackage. si --download-only est spécifié, le source n'est pas décompacté. on peut récupérer une version particulière avec "=version"
build-dep installe ou supprime des paquets dans le but de satisfaire les dépendances de construction d'un paquet source.
check outil de diagnostic; met à jour le cache des paquets et cherche des dépendances défectueuses.
clean nettoie le référentiel local des paquets récupérés. Supprime tout, excepté le fichier lock situé dans /var/cache/apt/archives et /var/cache/apt/archives/partial.
autoclean idem à clean, mais ne supprime que les paquets qui ne peuvent plus être téléchargés et qui sont grandement inutiles

OPTIONS

   Toutes les options peuvent être mises dans le fichier de configuration. On peut annuler le fichier de configuration avec -f-, --no-f, -f=no ou d'autres variantes.

-d, --download-only récupération seule (APT::Set::Download-Only)
-f, --fix-broken Essaye de réparer un système dont les dépendances sont défectueuses (APT::Get::Fix-Broken)
-m, --ignore-missing, --fix-missing Ignore les paquet manquants ; si des paquets ne peuvent être récupérés, ou après récupération, ne satisferons pas au contrôle d'intégrité, cette commande met ces paquets de côté et gère le résultat. (APT::Get::Fix-Missing)
--no-download pas de récupération. Le mieux est d'utiliser cette options avec --ignore-missing pour forcer apt à n'utiliser que les .deb qu'il a déjà récupéré. (APT::Get::Download)
-q, --quiet Mode silencieux ; cette commande produit une sortie destiné à l'enregistrement dans un journal en omettant les indicateurs de progression. On peut utiliser "q=#" pour choisir le niveau de silence. -qq ne DOIT pas être utilisé sans -d, --print-uris ou -s. (quiet)
-s, --simulate, --just-print, --dry-run, --recon, --no-act Simule les actions. Les crochets encadrent les paquets défectueux et crochet sans rien indique les dommages sans conséquence.(APT::Get::Simulate).
-y, --yes, --assume-yes répond automatiquement aux questions par "oui" (APT::Get:Assume-Yes)
-u, --show-upgraded affiche les paquets mis à niveau ; affiche une liste des paquets à mettre à niveau. (APT::Get::Show-Upgraded)
-V, --verbose-version Affiche les versions complètes des paquets installés ou mis à niveau.(APT::Get::Show-Versions)
-b, --compile, --build compile un paquet source (APT::Get::Compile)
--ignore-hold Ignore le "hold" placé" sur un paquet. Peut être utile avec dist-upgrade pour annuler un grand nombre de "hold" indésirable (APT::Get::Ignore-Hold)
--no-upgrade Aucune mise à niveau. Utilisé avec install, empêche les paquets listés sur la ligne de commande d'être mis à niveau (APT::Get::Upgrade)
--force-yes Forcer l'acceptation. Peut détruire le système ! (APT::Get::force-yes)
--print-uris Au lieu d'aller chercher les paquets à installer, leur uri sont affichées.(APT::Get::Print-URIs)
--purge Permet de supprimer tout ce qui peut être supprimé (APT::Get::Purge)
--reinstall Réinstalle les paquets déjà installés avec leur version la plus récente (APT::Get::ReInstall)
--list-cleanup activé par défaut : --no-list-cleanup pour la désactiver. gère automatiquement le contenu de /var/lib/apt/lists afin d'assurer que les fichiers obsolètes soient effacés. (APT::Get::List-Cleanup)
-t, --target-release, --default-release Contrôle l'entrée par défaut pour les question de distribution. Une étiquette (pin) par défaut dont la priorité vaut 990 est crée en utilisant la chaîne spécifiée. Le fichier de préférence peut annuler cette décision. ex : -t'2.1*' ou -t unstable. (APT::Default-release)
--trivial-only ne réalise que les opérations triviales (répond à non a toutes les questions) (APT::Get::Trivial-Only)
--no-remove Empêche la suppression de paquets. (APT::Get::Remove)
--only-source la commande source acceptera seulement des noms de paquets source comme argument, et non les nom de paquets binaires correspondant. (APT::Get::Only-Source)
--diff-only, --tar-only Ne récupère que le fichier diff ou tar d'une archive source.(APT::Get::Diff-Only et APT::Get::Tary-Only)
--arch-only Ne traiter que les dépendances de construction pour telle architecture (APT::Get::Arch-Only)
--allow-unauthenticated Ignore le fait que les paquets ne peuvent pas être authentifiés (APT::Get::AllowUnauthenticated)
-v, --version version du programme
-c, --config-file fichier de configuration.
-o, --option donne une option de configuration. ex : -o Foo::Bar=bar

Fichiers

/etc/apt/sources.list Liste les emplacements où aller chercher les paquets (Dir::Etc::SourceList)
/etc/apt/apt.conf Fichier de configuration (Dir::Etc::Main)
/etc/apt/apt.conf.d/ Éléments du fichier de configuration (Dir::Etc::Parts)
/etc/apt/preferences Fichier des préférences. C'est dans ce fichier qu'on peut faire de l'étiquetage (pining) c'est à dire choisir d'obtenir des paquets d'une source distincte ou d'une distribution différente. (Dir::Etc::Preferences)
/var/cache/apt/archives/ Zone de stockage pour les paquets récupérés (Dir::Cache::Archives)
/var/cache/apt/archives/partial/ Zone de stockage pour les paquets en transit (Dir::Cache::Archives)
/var/lib/apt/lists/partial/ Zone de stockage pour les informations d'état des paquets en transit (Dir::State::Lists)
^
15 mars 2010

htmlpdflatexmanmd




apt-proxy

apt-proxy

Mise en place d'un proxy de dépôts

   Apt-proxy est un mandataire écrit en python pour apt-get. Il communique via HTTP avec les clients et via HTTP, FTP et rsync vers les serveurs. Il est utile pour limiter la consommation de bande passante Internet utilisé pour les mises à jours par exemple. le fichier de configuration par défaut est /etc/apt-proxy/apt-proxy-v2.conf (modifiable avec l'option -c ou --config-file=)

configuration

   il est divisé en plusieurs sections, chacune définissant une ressource. La section DEFAULT s'applique à toutes les sections.

[DEFAULT]

address Adresse IP sur laquelle apt-proxy sera à l'écoute des requêtes, s'il y'a plusieurs adresses, séparez-les par un espace.
port Port TCP pour l'écoute des requêtes
min_refresh_delay les fichiers Packages et les autres fichiers de contrôle ne seront pas rafraîchis tant qu'ils n'auront pas dépassé cet âge (off pour désactiver)
timeout Délai d'attente d'E/S maximale pour les transferts (défaut 30s)
cache_dir répertoire de cache (défaut : /var/cache/apt-proxy)
cleanup_freq période entre les tentatives de nettoyage : suppression des fichier › max_age, analyse des répertoires de cache, mise à jour des tables internes, etc (off pour désactiver)
max_age age maximal des fichiers avant leur effacement du cache (off pour désactiver)
max_versions nombre maximum de version d'un paquet debian à conserver (par distribution) (off pour désactiver)
passive_ftp pour utiliser le ftp passif utiliser on, pour un actif : off (défaut : on)
http_proxy [username:passwrd@host:port] pour utiliser un proxy
dynamic_backends apt-proxy ajoutera les dorsaux HTTP dynamiquement, s'ils ne sont pas définit mettre à off pour restreindre les dorsaux disponibles à ceux listés dans le fichier de configuration (défaut : on)
disable_pipelining utiliser la canalisation HTTP pour récupérer plusieurs fichiers en une fois. laisser désactivé pour le moment.
bandwidth_limit = valeur limite la bande passante à valeur octets pas seconde lors du téléchargement sur un serveur. ne s'applique qu'à http et rsync (défaut : pas de limite)

[RESSOURCES]

timeout Supplanter le temps global d’expiration
backends = protocole ://serveur/répertoire [...] Une liste d’une ou plusieurs URL des serveurs hébergeant les paquets debian.

        Protocole protocole à utiliser parmi http, ftp et rsync
        Serveur nom d’hôte du miroir à contacter
        Répertoire nom du répertoire où ajouter des demandes pour ce serveur

passive_ftp Supplanter la configuration globale de passive_ftp
bandwidth_limit Spécifie une limite de bande passante pour les téléchargements utilisant cette ressource
http_proxy [nom d’utilisateur:mot de passe@]nom d’hôte:port
min_refresh_delay Surcharge la variable globale « min_refresh_delay » pour cette dorsale.

[CLIENTS]

pour que les clients puissent se connecter au proxy, ils devrons mettre dans /etc/apt/sources.list: si vous avez la section debian comme ceci:
[debian]
backends = http://ftp.fr.debian.org/debian
alors un client utilisera:
deb http://serveur:9999/debian/ lenny main

apt-proxy-import

   permet d'importer les paquets dans le cache d'apt-proxy

        -v, --verbose mode verbeux
        -q, --quiet mode silencieux
        -r, --recursive mode récursif
        -c, --config-file= fichier de configuration d'apt-proxy

        importer depuis le cache apt
        apt-proxy-import /var/cache/apt/archives
        importer depuis le cache apt-move
        apt-proxy-import -r /var/cache/apt-move
       
exemple de fichier de configuration /etc/apt-proxy/apt-proxy-v2.conf
[DEFAULT]
address = 192.168.0.1
    
port = 9999
min_refresh_delay = 1h
complete_clientless_downloads = 1
debug = all:4 db:0
timeout = 15
cache_dir = /var/cache/apt-proxy
cleanup_freq = 1d
max_age = 120d
max_versions = 3
[debian]
timeout = 30
backends = http://ftp.fr.debian.org/debian
http://volatile.debian.org/debian-volatile
min_refresh_delay = 1d
    
[security]
;;Debian security archive
backends = http://security.debian.org
http://security.debian.org/debian-security
min_refresh_delay = 1m
    
[ubuntu]
;;Ubuntu archive
backends = http://archive.ubuntu.com/ubuntu
min_refresh_delay = 15m
    
[ubuntu-security]
;;Ubuntu security updates
backends = http://security.ubuntu.com/ubuntu
min_refresh_delay = 1m

^
15 mars 2010

htmlpdflatexmanmd




apt.conf

apt.conf

apt.conf est le principal fichier de configuration de la collection d'outils APT

   Chaque outil lit la config désigné par APT_CONFIG, puis lit les fichiers situés dans Dir::Etc::Parts ainsi que le principal fichier de config indiqué par Dir::Etc::main. Puis applique les options de la ligne de commande.

   Le fichier de configuration est construit comme un arbre d'options organisées en groupes fonctionnels.

        // indique un commentaire ainsi que /bin /boot /dev /etc /home /lib /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /@System.solv /tmp /usr /var articles/ html/ man/ md/ pdf/ sql/ temp/ temp-new-pc/ tex/ threads/
        ; le point-virgule est obligatoire


        On peut déclarer un nouveau champ d´action avec des accolades, comme suit:
APT {
    Get {
        Assume-Yes "true";
        Fix-Broken "true";
    };
};
    
ou
    
DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure —apt";};

Le groupe APT

   Ce groupe d'options contrôle le comportement global d'APT et contient également des options communes à tous les outils.

Architecture Architecture du système
Default-Release Indique la distribution à utiliser par défaut. Exemple : stable, testing, 4.0, 5.0.
Ignore-Hold ignore les paquets gelés.
Clean-Installed la fonction autoclean supprime du cache tout paquet qui ne peut plus être récupéré.
Immediate-Configure Désactive la configuration immédiate. option dangereuse !
Force-LoopBreak autorise APT à supprimer temporairement un paquet essentiel pour mettre fin à une boucle Conflicts / Conflicts ou Conflics / Pre-Depends entre 2 paquets essentiels. Options dangereuse !!
Cache-Limit APT utilise un fichier de cache chargé en mémoire avec map pour ranger les information sur les paquets disponibles. Fixe la taille mémoire allouée pour le chargement du cache.
Build-Essential définit les paquets qui sont considérés comme faisant partie des dépendance essentielles pour la construction de paquets.
Get Sous section qui contrôle apt-get
Cache sous-section qui contrôle apt-cache
CDROM sous-section qui contrôle apt-cdrom

Le groupe ACQUIRE

   Ce groupe d'options contrôle le téléchargement des paquets et les gestionnaires d'URI

PDIffs Essaye de télécharger les fichiers différentiels appelées PDiffs au lieux de télécharger le paquet entièrement. Par défaut à true.
Queue-Mode Mode de file d'attente ; peut prendre les valeurs host ou access. Cela détermine comment APT parallélise les connexions sortantes. Host signifie qu'une connexion par cible sera initié, access signifie qu'une connexion par type d'URI sera initié.
Retries Nombre d'essais à effectuer
Source-Symlinks Utilise les liens symboliques pour les archives sources. A true (défaut) crée un lien vers les archives sources au lieu de les copier
http http::Proxy est le mandataire http à utiliser par défaut : http://[[user][:pass]@]host[:port]/. On peut spécifier un mandataire par hôte distant http::Proxy::‹host›. Le mot clé DIRECT indique alors de n'utiliser aucun mandataire pour l'hôte. Définie, la variable d'environnement http_proxy annule et remplace toutes les options de mandataire HTTP.

   3 options de configuration sont fournies pour le contrôle des caches.

        No-Cache signifie que le mandataire ne doit jamais utiliser les réponses qu'il a stockés ;
        Max-Age sert pour les fichiers d'index : demande au cache de les mettre à jour au delà d'une période spécifiée en seconde. Debian met à jour quotidiennement.
        No-Store sert pour les fichiers d'archive et demande au cache de ne jamais garder la requête.
        timeout positionne le compteur de temps mort (timeout).

   Une options permet de contrôler la profondeur du tube pour le cas où le serveur distant n'est pas conforme à la RFC ou est bogué. Acquire::http::Pipeline-Depth a une valeur compris entre 0 et 5. Indique le nombre de requêtes en attente qui peuvent être émises. utiliser 0 si non conforme a là RFC.

https identique à http.

        CaInfo spécifie le fichier contenant les informations sur les certificats.
        Verify-Peer (bool) précise si le certificat d'hôte du serveur doit être confronté aux certificats.
        Verify-Host (bool) précise s'il faut vérifier le nom d'hôte du serveur
        SslKey détermine quelles clé privée doit être utilisée pour l'authentification du client
        SslForceVersion permet de spécifier la version de SSL : 'TLSv1' ou 'SSLv3' chacune de ces options peut être spécifié pour un hôte particulier en utilisant ‹hôte›::option

ftp ftp::Proxy est le mandataire FTP à utiliser par défaut : ftp://[[user][:pass]@]host[:port]/. On peut spécifier un mandataire par hôte distant avec la syntaxe : ftp::Proxy::‹host›. Le mot clé DIRECT indique alors de n'utiliser aucun mandataire pour l'hôte. Définie, la variable d'environnement ftp_proxy annule et remplace toutes les options de mandataire HTTP.options semblables a http
cdrom la seule options pour les uri de cdrom est le point de montage : cdrom::Mount : "/cdrom/"::Mount "foo" ;
gpgv URI gpgv

Comment APT appel DPKG

options liste d'options à passer à dpkg. doivent être déclarés en utilisant la notation de liste et chaque élément de la liste est passé comme un seul argument.
Pre-Invoke, Post-Invoke liste de commande shell à exécuter avant ou après l'appel de dpkg Pre-Install-Pkgs : Liste de commandes shell à exécuter avant d'appeler dpkg. utilise /bin/sh. On peut utiliser une 2eme version de ce protocole avec DPkg::Tools::Options::cmd::Version à 2. cmd est une commande passée à Pre-Install-Pkgs
Run-Directory APT se place dans ce répertoire avant d'appeler dpkg. / par défaut
Build-Options Ces options sont passées à dpkg-buildpackage lors de la compilation des paquets

Options PERIODIC et ARCHIVE

   les groupes d'options APT::Periodic et APT::Archive configurent les comportements périodiques réalisés par /etc/cron.daily/apt, lancé quotidiennement.

APT::Periodic Permet de configurer la fréquence d'exécutions des tâches apt lancées automatiquement.
APT::Archive Les options de la section APT::Archive permettent de contrôler la taille du cache de paquets.
^
15 mars 2010

htmlpdflatexmanmd




aptitude

aptitude

gestionnaire de paquet debian évolué

   Aptitude est un utilitaire qui s'appuie sur apt-get et dpkg. Il possède de nombreuses options et un mode interactif. C'est l'utilitaire le plus complet pour gérer les logiciels.

Commandes

Install installe un ou plusieurs paquets. les caractères tilde et point d'interrogation peuvent être utilisés.

        - pour installer une version spécifique ajouter "=‹version›".
        - pour choisir un paquet d'une archive précise spécifier par "/‹archive›"
        - les attributs de surcharge permettent de forcer une actions:

                ‹paquet›+ installer le paquet
                ‹paquet›+M Installer le paquet et le marquer comme installé.
                ‹paquet›- Supprimer le paquet
                ‹paquet›_ Purger le paquet avec tous ses fichiers de configuration
                ‹paquet›= Marque le paquet comme étant à conserver : annule toute action d'installation, de mise a jour automatique dans le futur
                ‹paquet›: Garde le paquet à sa version actuelle : annule toute action d'installation, de mise a jour ou de suppression
                ‹paquet›&m Marque le paquet comme ayant été installé automatiquement.

        cas particulier: install sans argument résout les commandes en suspend ou différées.
        Note: Si vous confirmez l'install, puis annulez pendant l'install en cour, il faudra les supprimer pour annuler complètement l'installation.

remove, purge, hold, unhold, keep, reinstall identiques à install avec les options, mais s'applique a tous les paquets spécifiés.
hold et keep la différence est que hold ignorera safe-upgrade ou full-upgrade pour les paquets spécifiés. keep annule toutes actions sur le paquet, pour dévérouiller, utiliser unhold
markauto, unmarkauto indique que les paquets ont été marqués comme installés automatiquement, ou à la main.
build-depends, build-dep satisfait les "build-dependency" d'un paquet. avec le paramètre --arch-only, seul les build-dependency dépendant de l'architecture seront satisfait.
forbid-version empêche la mise a jour vers une version précise d'un paquet. ex : aptitude forbid-version vim=1.2.3.broken-4
update identique à apt-get update
safe-upgrade met à jour, les paquets ne seront pas supprimés à moins qu'ils soient inutilisés. Des paquets non installés peuvent être installés a moins que l'option --no-new-installs soit spécifié.
full-upgrade met à jour, supprime ou installe les paquets si nécessaire. Moins conservative que safe-upgrade
keep-all annule toutes les actions prévues sur des paquets.
forget-new Ignore les nouveaux paquets ("f" en mode interactif)
search rechercher des paquets. le premier caractère indique l'état courant du paquet:

        p non installé
        c désinstallé mais les fichiers de configuration existent toujours
        i paquet installé
        v paquet virtuel
        le 2eme caractère indique l'action prévu:
        i à installer
        d à supprimer
        p à purger
        A a été installé automatiquement

show Afficher des informations détaillées sur un ou plusieurs paquets. l'option -v ou -vv affiche les informations sur toutes les versions du paquets

        - pour afficher les informations d'une version particulière, suffixer par =‹version›
        - pour afficher les informations sur une version d'une archive particulière, suffixer par /‹archive›

add-user-tag, remove-user-tag ajoute un tag user ou le supprime. Les tags user sont des chaînes arbitraire associés à un paquet. Ils peuvent être utilisés avec le terme de recherche ?user-tag(‹tag›) qui permet de sélectionner tous les paquet qui ont ce tag.
why, why-not explique la raison particulière associé avec un paquet qui devrait ou ne devrait pas être installé sur le système. Cherche les paquets qui dépendent ou sont en conflit avec ce paquet
clean Supprime tous les paquets .deb téléchargés et enregistrés dans le répertoire cache (/var/cache/apt/archives)
autoclean supprime tous les paquets .deb téléchargés dans le cache et qui n'est plus proposé au téléchargement
changelog télécharge et affiche le journal des modifications pour chaque paquet source ou binaire. on peut spécifier =‹version› et /‹archive›
download télécharge le .deb dans le dossier courant. on peut spécifier =‹version› et /‹archive›
extract-cache-subset copie le dossier de configuration (/etc/apt) dans le dossier spécifié. Si aucun paquet n'est spécifié, copie la base entière, sinon, seul les entrées correspondant au paquets spécifiés seront copiés.

OPTIONS

   Ces options permettent de modifier le comportement des commandes aptitude.

--add-user-tag ‹tag› ajoute un tag user
--add-user-tag-to ‹tag›,‹pattern› idem avec correspondance de motif
--allow-new-upgrades en mode safe resolver, permet au résolveur de dépendance d'installer les mises a jour pour les paquets sans regarder la valeur de Aptitude::Safe-Resolver::No-new-Upgrades.
--allow-new-installs permet à safe-upgrade d'installer les nouveaux paquet (ou Aptitude::Always-Use-Safe-Resolver a true), permet au résolveur de dépendance d'installer des nouveaux paquets. cette option ne tient pas compte de Aptitude::Safe-Resolver::No-New-Installs.
--allow-untrusted Installe les paquets depuis des sources non-sûres sans demander confirmation.
--disable-columns aptitude search ne formate pas sa sortie correspond à Aptitude::CmdLine::Disable-Columns.
-D, --show-deps pour les commandes qui vont installer ou supprimer des paquets (install, full-upgrade, etc), montre une brève explication. correspond à l'option : Aptitude::CmdLine::Show-Deps.
-d, --download-only N´installe ni ne supprime aucun paquet. Télécharge simplement les paquets nécessaires dans le cache. Directive du fichier de configuration : Aptitude::CmdLine::Download-Only.
-F ‹format›, --display-format ‹format› Définit le format qui sera utilisé pour afficher les résultats de la commande search. Par exemple, « %p %V %v » affichera le nom du paquet, numéro de la version installée, les versions disponibles. Directive du fichier de configuration : Aptitude::CmdLine::Package-Display-Format.
-f Essaye de résoudre les dépendances des paquets cassés, même si cela implique d´ignorer des actions demandées sur la ligne de commande. Directive du fichier de configuration : Aptitude::CmdLine::Fix-Broken.
--full-resolver Quand un problème de dépendance est rencontré, utilise le mode "full" du résolveur au lieu du mode "safe". Permet de force le full même si Aptitude::Always-Use-Safe-Resolver est true.
-h, --help Affiche un court message d´aide. Identique à l´action help.
--no-new-installs safe-upgrade n'installe pas de nouveau paquets. Quand --safe-resolver est utilisé ou Aptitude::Always-Use-Safe-Resolver a true, interdit au résolver l'installation de nouveaux paquets. Ne tient pas compte de Aptitude::Safe-Resolver::No-New-Installs. Correspond à Aptitude::CmdLine::Safe-Upgrade::No-New-Installs.
--no-new-upgrades --safe-resolver ou Aptitude::Always-Use-Safe-Resolver. Autorise le resolver à installer de nouveaux paquets. Ne tient pas compte de Aptitude::Safe-Resolver::No-New-Installs.
-O ‹ordre›, --sort ‹ordre› spécifie l'ordre de sortie de search. Par exemple : « installsize » pour ‹ordre›
-o ‹clef›=‹valeur› Définit une option du fichier de configuration à la volée. Utilisez par exemple -o Aptitude::Log=/tmp/mes-logs afin de consigner (logs) les événements d´aptitude dans le fichier /tmp/mes-logs.
-P, --prompt demande toujours avant de télécharger, installer ou supprimer un paquet. Directive du fichier de configuration : Aptitude::CmdLine::Always-Prompt.
--purge-unused Purge les paquets dont aucun autre paquet installé ne dépend. Cela revient à -o Aptitude::Purge-Unused=true
-q[=‹n›], --quiet[=‹n›] Enlève tous les indicateurs d´avancement et rend ainsi la sortie journalisable. Cette option peut être passée plusieurs fois pour rendre le programme de plus en plus silencieux, mais contrairement à apt-get, aptitude n´ajoute pas implicitement -y quand -q est passée plus d´une fois. Le paramètre optionnel =‹n› peut être utilisé pour configurer directement le taux de silence (par exemple, pour surcharger un paramétrage dans /etc/apt/apt.conf) ; le programme agit alors comme si -q lui avait été passée exactement ‹n› fois.
-R, --without-recommends Ne gère pas les recommandations de dépendances lors de l´installation de nouveaux paquets (prioritaire sur les réglages de /etc/apt/apt.conf et /.aptitude/config). Les paquets installés précédemment pour ces même raisons de recommandation ne seront pas supprimés. Correspond à Apt::Install-Recommends et Aptitude::Keep-Recommends.
-r, --with-recommends Traite les suggestions ou les recommandations en tant que dépendances lors de l´installation des nouveaux paquets. (Prioritaire sur les réglages de /etc/apt.conf et /.aptitude/config).Correspond à Apt::Install-Recommends
--remove-user-tag ‹tag› supprime le tag user
--remove-user-tag-from ‹tag›,‹pattern› supprime la tag user de tous les paquet correspondant à ‹pattern›
-s, --simulate Affiche la liste des actions qui seraient réalisées, mais ne les lance pas réellement. Il n´est pas nécessaire d´avoir les privilèges d´administration. Directive du fichier de configuration : Aptitude::Simulate.
--safe-resolver en cas de problème de dépendance, utilise le mode "safe" du resolver. Correspond à Aptitude::Always-Use-Safe-Resolver to true.
--schedule-only Pour les commandes qui modifient l´état des paquets, programme les actions à faire pour plus tard, mais ne les fait pas. Vous pouvez exécuter les actions programmées en lançant aptitude install sans paramètre. Cela revient à faire la sélection correspondante en mode visuel, puis à quitter aptitude normalement. Par exemple, aptitude --schedule-only install evolution va programmer l´installation future du paquet evolution.
-t ‹version›, --target-release ‹version› Définit la version à partir de laquelle les paquets devront être installés. Par exemple, « aptitude -t expérimental ... » installera les paquets de la distribution expérimentale, si rien d´autre n´est précisé. Pour les actions de la ligne de commandes « changelog », « download » et « show », cela revient à suffixer /‹version› au nom de chaque paquet cité sur la ligne de commandes. Pour les autres commandes, cela modifiera la version installée par défaut selon les règles décrites dans apt_preferences(5). Directive du fichier de configuration : APT::Default-Release.
-V, --show-versions Indique quelle version du paquet sera installée. Directive du fichier de configuration : Aptitude::CmdLine::Show-Versions.
-v, --verbose Force quelques commandes à afficher des informations supplémentaires. Directive du fichier de configuration : Aptitude::CmdLine::Verbose. --version Affiche la version et quelques informations sur l´environnement de compilation d´aptitude.
--visual-preview Lance l´interface visuelle et affiche l´écran d´accueil, plutôt que d´afficher l´habituelle invite de commande en ligne.
-W, --show-why affiche quels paquets installés manuellement requièrent des paquets installés automatiquement. Combiné avec -v ou une valeur autre que 0 pour Aptitude::CmdLine::Verbose, affiche la chaine complète des dépendances. décrit également pourquoi un paquet va être supprimé.
-w ‹largeur›, --width ‹largeur› Définit la largeur utilisée pour l´affichage du résultat de la commande search. Directive du fichier de configuration : Aptitude::CmdLine::Package-Display-Width
-y, --assume-yes Répond « oui » à toute question de type oui/non. N´affecte pas les réponses aux questions particulièrement dangereuses, A priorité sur -P. Directive du fichier de configuration : Aptitude::CmdLine::Assume-Yes.
-Z Affiche l´espace disque qui sera utilisé ou libéré par chacun des paquets à installer, mettre à jour ou supprimer. Directive du fichier de configuration : Aptitude::CmdLine::Show-Size-Changes.
-i Affiche l´écran de téléchargement au démarrage du programme
-S ‹nom-fichier› Charge les informations supplémentaires à partir de ‹nom-fichier› plutôt qu´à partir du fichier standard.
-u Lance la mise à jour de la liste des paquets dès le démarrage du programme.

Variables d'environnement

HOME Répertoire personnel de l'utilisateur
PAGER Pager à utiliser
TMP Quand TMPDIR n´est pas paramétrée,utilise ce répertoire
TMPDIR Spécifie un répertoire pour les fichiers temporaires

Fichiers

$HOME/.aptitude s'il existe, aptitude stock son fichier de configuration dans $HOME/.aptitude/config. Sinon, il recherchera le répertoire personnel de l´utilisateur courant, grâce à getpwuid(2) pour y placer son fichier de configuration.
/var/lib/aptitude/pkgstates Le fichier dans lequel sont stockés les états des paquets et flags des paquets
/etc/apt/apt.conf
/etc/apt/apt.conf.d/
/.aptitude/config Fichiers de configuration pour aptitude. /.aptitude/config est prioritaire à /etc/apt/apt.conf. voir apt.conf(5)
^
15 mars 2010

htmlpdflatexmanmd




apt_preferences

apt_preferences

fichier de contrôle des préférences pour APT

On peut définir le dépôt par défaut par:
apt-get install -t testing paquet
ou
APT::Default-Release "stable" ;

   Quand une distribution par défaut a été indiquée, APT utilise l'algorithme suivant pour déterminer la priorité des versions d'un paquet:

une priorité égale à 100 est affectée à la version déjà installée (si elle existe)
une priorité égale à 500 est affectée aux versions qui ne sont pas installées et qui n'appartiennent pas à la distribution par défaut.
une priorité égale à 990 est affectée aux versions qui ne sont pas installées et qui appartiennent à la distribution par défaut.

   Quand aucune distribution par défaut n'a été indiquée, APT affecte simplement une priorité égale à 100 à toute version installée d'un paquet et une priorité égale à 500 à tout version non installée.

   Puis APT applique les règles suivantes pour déterminer la version du paquet qu'il faut installer (elles sont listées par ordre de priorité):

- Ne jamais revenir en arrière, sauf si la priorité d'une version disponible dépasse 1000.« Revenir en arrière » signifie installer une version moins récente que la version installée. Il faut noter qu'aucune des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent être définies que dans le fichier des préférences. Notez aussi qu'il est risqué de revenir en arrière.
- Installer la version qui possède la priorité la plus haute.
- Quand deux (ou plus) versions ont la même priorité, installer la version la plus récente
- Quand deux (ou plus) versions ont la même priorité et le même numéro de version, mais soit les paquets diffèrent par certaines méta-données, soit l'option —reinstall a été donnée, installer la version qui n'est pas installée.

   Le fichier des préférences permet à l'administrateur système de contrôler l'affectation des priorités. Ce fichier est constitué d'une ou plusieurs entrées séparées par des lignes blanches. Ces entrées peuvent avoir deux formes, une forme particulière et une forme générale.

- La forme particulière affecte une priorité (Pin-Priority) à un paquet précis, à une version précise ou à un intervalle spécifiant plusieurs versions. Par exemple, l'entrée suivante affecte une priorité haute à toutes les versions du paquet perl dont le numéro de version commence par 5.8.
Package: perl
Pin: version 5.8*
Pin-Priority: 1001

   - La forme générale affecte une priorité à toutes les versions d'un paquet dans une distribution donnée (c'est-à-dire, à toutes les versions d'un paquet qui sont listées dans un fichier Release), ou à toutes les versions d'un paquet provenant d'un site internet identifié par un nom complètement qualifié.

Cette forme générale des entrées du fichier des préférences s'applique seulement aux groupes de paquets. Par exemple, l'entrée suivante affecte une priorité haute à toutes les versions disponibles dans le site local.
Package:    *
Pin: origin ""
Pin-Priority: 999

L'entrée suivante affecte une priorité basse à toutes les versions d'un paquet appartenant à toute distribution dont le nom d'« Archive » est unstable.
Package:    *
Pin: release a=unstable
Pin-Priority: 50

L'entrée suivante affecte une priorité haute à toutes les versions d'un paquet appartenant à toute distribution dont le nom d'« Archive » est stable et dont le numéro de « Version » est 3.0.
Package:    *
Pin: release a=stable, v=3.0
Pin-Priority: 500

Priorités

P › 1000 Cette priorité entraîne l'installation du paquet même s'il s'agit d'un retour en arrière.
990 ‹ P ‹=1000 La version sera installée, même si elle n'appartient pas à la distribution par défaut ; mais elle ne sera pas installée si la version installée est plus récente.
500 ‹ P ‹=990 La version sera installée, sauf s'il existe une version appartenant à la distribution par défaut ou si la version installée est plus récente.
100 ‹ P ‹=500 La version sera installée, sauf s'il existe une version appartenant à une autre distribution ou si la version installée est plus récente.
0 ‹ P ‹=100 La version sera installée si aucune version du paquet n'est installée.
P ‹ 0 Cette priorité empêche l'installation de la version.

   Détermination de la version des paquets et des propriétés des distributions

   Chaque source listée dans sources.list doit fournir les fichiers Packages et Release qui décrivent les paquets disponibles à cet endroit

   Le fichier package doit se trouver dans .../dists/dist-name/component/arch. Il consiste en entrées composées de lignes, une pour chaque paquet disponible. Seules 2 lignes des entrées sont pertinentes pour la détermination des priorités:

la ligne Package donne le nom du paquet
la ligne Version donne le numéro de version du paquet

   Le fichier Release se trouve normalement dans le répertoire .../dist/dist-name Il consiste en une seule entrée composée de plusieurs lignes qui s'applique a tous les paquets situés dans les répertoires sous le répertoire parent

la ligne Archive nomme l'archive à laquelle appartiennent tous les paquets situés dans les répertoires.
Pin: release a=stable

La ligne Version indique la version de la distribution.
Pin: release v=3.0
Pin: release a=stable, v=3.0
Pin: release 3.0

La ligne Component nomme un composant qui indique le type de licence associée aux paquets situés dans les répertoires sous le fichier Release.
Pin: release c=main

La ligne Origin nomme l'origine des paquets situés dans les répertoires sous le fichier Release.
Pin: release o=Debian

La ligne Label indique un label pour les paquets qui se trouvent dans les répertoires sous le fichier Release.
Pin: release l=Debian

   Tous les fichiers Packages et Release récupérés dans des sources listées par le fichier sources.list sont conservés dans le répertoire /var/lib/apt/lists ou dans le fichier spécifié par la variable Dir::State::Lists dans le fichier apt.conf.
^
25 octobre 2016

htmlpdflatexmanmd




ar

ar

Créer, modifier, et extraire des archives

   Le contenu original, les permissions, dates, propriétaire et groupe sont préservés dans l'archive, et peuvent être restaurés à l'extraction.

OPTIONS

d Supprimer des modules de l'archive. avec v, ar liste chaque module supprimé
m Déplacer des membres dans une archive
p Affiche les membres spécifiés de l'archive. Avec v, affiche le nom du membre en copiant son contenu sur stdout
q Ajoute les membres à la fin de l'archive, sans vérifier le remplacement.
r Insert les fichiers dans l'archive. Les membres précedemment existants sont supprimés si leur nom correspond.
s Ajoute un index à l'archive, ou met à jours un index existant.
t Affiche un tableau du contenu de l'archive.
x Extrait des membres de l'archive
p Affiche les membres spécifiés de l'archive. avec v, affiche le nom du membre en copiant son contenu sur stdout. Un modifier peut être spécifié après cette option:

        a Ajoute les nouveaux fichiers après un membre existant dans l'archive
        b Ajoute les nouveaux fichiers avant un membre existant dans l'archive
        c Créer l'archive si elle n'existe pas
        D Opère en mode déterministique. En ajoutant les fichiers et l'index d'archive, utilise 0 pour les UID, GID, timestamps et utilise des permissions consistantes pour tous les fichiers.
        f Tronque les noms dans l'archive.
        i Insert les nouveaux fichiers avant un membre existant dans l'archive.
        N Utilise le paramètre count, utilisé s'il y a plusieurs entrées dans l'archive avec le même nom.
        o Préserve les dates originales lors de l'extraction
        P Utilise le chemin complet pour la correspondance des noms dans l'archive
        s Écrit un index d'objet dans l'archive, ou met à jours un index existant même si aucun changement n'est fait dans l'archive.
        S Ne pas générer de table de symboles.
        T Rend l'archive spécifié légère. Permet d'insérer seulement les fichiers listés qui sont plus récents que des membres existants.
        U Ne pas opérer en mode déterministique. Inverse de D. Mode par défaut
        v Affiche des informations additionnelles sur les opérations.
        V Affiche le numéro de version de ar

--plugin charge le plugin spécifié pour ajouter le support pour d'autres formats de fichier.
--target spécifie que les membres de l'archive sont dans un format de code objet différent du format par défaut du système.
@file Lit les options de ligne de commande depuis le fichier spécifié Le fichier lui-même peut contenir des options @file additionnels.
^
14 juillet 2010

htmlpdflatexmanmd




arch

arch

Afficher le nom hardware de la machine

   arch affiche le nom hardware de la machine, est équivalent à uname -m

^
17 mars 2010

htmlpdflatexmanmd




arp

arp

Manipuler et afficher la table arp ipv4 du noyau

Modes

arp sans mode affiche le contenu de la table arp, il est possible de limiter l'affichage en spécifiant le type d'adresse physique, le nom de l'interface ou l'adresse de l'hôte.
arp -d address va supprimer l'entrée dans la table arp
arp -s address hw_addr est utilisé pour ajouter une entrée dans la table. Pour spécifier des entrée pour une ou plusieurs interfaces, utiliser -Ds address ifname

OPTIONS

-v, --verbose mode verbeux
-n, --numeric affiche les adresses numériques au lieu des noms
-H type, --hw-type type spécifie quelle classe d'entrée arp doit vérifier.
-a utilise le format de sortie BSD
-D, --use permet de spécifier une interface au lieu de hw_addr. c'est la meilleur option pour spécifier un proxy arp.
-i If, --device If sélectionne une interface
-f filename, --file filname similaire à l'option -s, seulement cette fois les données sont prise depuis le fichier spécifié. généralement /etc/ethers (défaut)

Exemples

Répondre aux requêtes arp sur eth0 pour 10.0.0.2 avec l'adresse MAC de eth1
arp -i eth0 -Ds 10.0.0.2 eth1 pub
Supprimer une entrée de la table
arp -i eth1 -d 10.0.0.1
^
18 mars 2016

htmlpdflatexmanmd




arpaname

arpaname

Traduit les adresses IP en noms ARPA correspondants

   traduit les adresse IP (v4 et v6) en noms IN-ADDR.ARPA ou IP6.ARPA correspondants

^
07 mai 2016

htmlpdflatexmanmd




arpd

arpd

Service arp

OPTIONS

-l Dump la base arpd sur la sortie standard et quitte
-f file Lit et charge la base arpd depuis le fichier spécifié. son format est similaire à celle fournie par l'option -l
-b database L'emplacement du fichier de la base de données (défaut: /var/lib/arpd/arpd.db)
-a number arpd n'écoute pas seulement de manière passive les packets arp sur l'interface, et envoie également des requêtes en broadcast. number est le nombre de requêtes à faire avant de considérer une destination morte.
-k Supprime l'envoie de requêtes broadcast par le kernel. N'a de sens qu'avec -a
time spécifie le timeout du cache. Quand une résolution échoue, arpd supprime les futures tentatives de résolution pour cette période. N'a de sens qu'avec -k.(défaut: 60secondes)
-p time Temps d'attente en secondes entre les tentatives de polling dans la table arp du kernel. time peut être un nombre à virgule flottante. (défaut: 30)
-R rate Taux maximum de broadcast envoyés par arpd par seconde (défaut: 1)
-B number Nombre de broadcast envoyés par arpd (défaut: 3). Avec -R, s'assure que le nombre de requêtes arp qui sont broadcastés n'excèdent pas B+R*T dans un intervalle de temps T.
‹interfaces› Liste d'interfaces réseaux à regarder.

Signaux

SIGINT, SIGTERM arpd se termine après avois synchronisé sa base et restaurés les paramètres sysctl.
SIGHUP arpd synchronise sa base sur disque
SIGUSR1 Envoie des statistiques à syslog

Notes

   Pour que arpd soit capable de servir de resolver arp, le kernel doit être compilé avec l'option CONFIG_ARPD.

Exemples

Démarre arpd pour collecter des arp gratuitous, mais sans utiliser la fonctionnalité du kernel
arpd -b /var/tmp/arpd.db
Voir les résultat après un certain temps
killall arpd ; arpd -l -b /var/tmp/arpd.db
Activer le helper du kernel, laissans le kernel comme rôle de premier plan
arpd -b /var/tmp/arpd.db -a 1 eth0 eth1
Remplace complètement la résolution du kernel sur les interfaces eth0 et eth0
arpd -b /var/tmp/arpd.db -a 3 -k eth0 eth1
^
22 mai 2010

htmlpdflatexmanmd




at

at, atq, atrm, batch

Exécute des commandes à un instant définis

   at et batch lisent les commandes sur l'entrée standard ou un fichier spécifié, et sont exécutées à un instant définis, en utilisant /bin/sh.

at exécute les commandes à un instant spécifié
atq liste les jobs en attente de l'utilisateur. Si l'utilisateur est root, affiche tous les jobs. Le format de sortie est un job par ligne (job, numéro, date, heure, queue et user).
atrm Supprime des jobs, spécifié par leur numéro.
batch exécute des commandes quand les niveaux de charge système le permettent ; quand la charge moyenne est en dessous de 1.5, ou la valeur spécifié dans l'invocation de atd.

   at permet des spécifications de temps complexe, étendant le standard POSIX.2. Il accepte le temps sous la forme HH:MM pour lancer un job à une heure spécifique de la journée. Vous pouvez aussi spécifier midnight, noon ou teatime (4pm). Vous pouvez spécifier l'heure du jour avec le préfixe AM ou PM. Vous pouvez spécifier le jour en donnant une date sous la forme month day et optionnellement year, ou en donnant une date sous la forme MMDDYY ou MM/DD/YY ou MM.DD.YY. La spécification d'une date DOIT suivre la spécification de l'heure du jour. Vous pouvez aussi donner le temps comme now + count time-units, où time-units peut être minutes, hours, days ou weeks et vous pouvez dire à at de lancer le job aujourd'hui en suffixant le temps avec today et demain par tomorrow.

   Pour at et batch les commandes sont lues depuis l'entrée standard ou le fichier spécifié avec l'option -f. Le répertoire de travail (excepté pour les variables TERM, DISPLAY et _) et le umask sont retenus depuis l'heure d'invocation. Un at - ou batch - invoqué depuis un shell su(1) retient le userid courant. L'utilisateur recevra un email de la sortie standard et l'erreur standard de ses commandes. Le mail sera envoyé en utilisant /usr/lib/sendmail.

   Le superuser peut utiliser ces commandes dans tous les cas, pour les autres, la permission d'utiliser at est déterminé par les fichiers /etc/at.allow et /etc/at.deny

   si /etc/at.allow existe, seul les noms d'utilisateurs mentionnés sont autorisés à utiliser at. Si /etc/at.allow et /etc/at.deny exsitent, tous les noms d'utilisateur non mentionnés est autorisé à utiliser at. Si aucun des 2 fichiers n'existe, seul root peut utiliser at. Si /etc/at.deny est vide, tous les utilisateurs peuvent utiliser at.

OPTIONS

-q queue Utiliser la queue spécifiée. Une désignation de queue consiste d'une simple lettre de a à z et A à Z. la queue a est le défaut pour at et b est le défaut pour batch. Les queues avec des lettres supérieurs augmente le niveau de nice. La queue spécial "=" est réservée pour les jobs en cours d'exécution.

           Si un job est envoyé à une queue désigné avec une lettre majuscule, le job est traité s'il était envoyé à batch au moment du job. Une fois le temps atteint, les règles de traitement des jobs s'appliquent. Si une queue spécifique est donné à atq, il affiche uniquement les jobs en attente dans cette queue.

-m Envoie un mail à l'utilisateur quand le job est terminé, même s'il n'y a pas de sortie.
-f file Lit les jobs depuis le fichier spécifié
-t time lance le job au temps spécifié, donné au format [[CC]YY]MMDDhhmm[.ss]
-l est un alias pour atq
-d est un alias pour atrm
-v Affiche l'heure 'exécution du job avant de le lire, affiché au format "Thu Feb 20 14:50:00 1997"
-c cat les jobs listé sur la ligne de commande sur la sortie standard.

Exemples

lancer un job dans à 16h dans 3 jours:
at 4pm + 3 days
lancer un job à 10heures le 31 juillet:
at 10am Jul 31
lancer un job à 1 heure du matin demain:
at 1am tomorrow
^
11 février 2014

htmlpdflatexmanmd




at.allow

at.allow, at.deny

Détermine qui peut soumettre des jobs via at ou batch

   Détermine qui est autorisé à exécuter des commandes at et batch sur un système. Le format est une liste de noms d'utilisateurs, un par ligne.

  Si /etc/at.allow existe, seules les utilisateurs listés sont autorisés. S'il n'existe pas, /etc/at.deny est vérifié.

^
22 mai 2010

htmlpdflatexmanmd




atd

atd

Lance les jobs mis en queue par at

OPTIONS

-l Spécifie un facteur de limite de charge, au delà duquel les jobs ne seront pas lancés, (1.5 par défaut). Pour un système SMP avec n CPU, vous définirez probablement supérieur à n-1
-b spécifie l'intervalle minimum en secondes entre le début de 2 jobs batch (60 par défaut).
^
19 juillet 2010

htmlpdflatexmanmd




atftp

atftp

client tftp

   atftp peut être utilisé interactivement ou en mode batch pour récupérer des fichiers depuis des serveurs tftp. Il supporte toutes les fonctionnalités de base des RFC1350, RFC2347, RFC2348 et RFC2349. supporte également l'implémentation multicast de la RFC2090 et mtftp définie dans la spécification PXE.

OPTIONS

-g, --get Requète pour lire un fichier
--mget Requète pour un fichier auprès d'un serveur mfftp
-p, --put Requète pour écrire un fichier
-l, --local-file Spécifier le fichier coté client pour les options -g et -p
-r, --remote-file Spécifier le fichier coté serveur pour les options -g et -p
--tftp-timeout ‹value› Nombre de seconde pour le timeout. défaut : 5 secondes
--option ‹"name value"› Définir une option. exemple : --option blksize 1428 configure la taille de block
--mtftp ‹"name value"› définir une option mtftp. exemple : --mtftp client-port 76 définit le port coté client à utiliser.
--no-source-port-checking Ne vérifie pas le port (utile pour les NAT)
--verbose Mode verbeux
-h, --help affiche un sommaire des commandes
^
19 juillet 2010

htmlpdflatexmanmd




atftpd

atftpd

Serveur tftp

   Par défaut, il est démarré par inetd, mais peut être lancé comme démon autonome. Ce serveur est multi-thread et supporte toutes les options décrites dans la RFC2347, RFC2348, RFC2349 et RFC2090. Il supporte également le mtftp comme définit dans la spécification PXE.

OPTIONS

-t, --tftpd-timeout ‹value› Nombre de secondes d'inactivité avant que le serveur se termine. N'a de signification que si le serveur est lancé par inetd. 300 secondes par défaut.
-r, --retry-timeout ‹value› Nombre de secondes à attendre pour une réponse avant de retransmettre un packet. 5 secondes par défaut. Peut être écrasé par l'option timeout du client.
-m, --maxthread ‹value› Nombre maximum de threads permis. 100 par défaut.
-v, --verbose[=value] Augmente ou définis le niveau de log. Sans argument, la valeur est de 1. le défaut est LOG_NOTICE. les valeurs vont de 0 à 7.
--trace Si verbose est à 7, sort des informations de débuggage pour chaque paquet envoyé ou reçu.
--no-timeout désactive le timeout de la RFC2349.
--no-tsize désactive tsize de la RFC2349
--no-blksize désactive blksize de la RFC2348
--no-multicast désactive multicast de la RFC2090
--logfile ‹logfile› spécifier le fichier de log.
--pidfile Spécifier le pid du server
--daemon Lance en démon
--no-fork quand --daemon est spécifié l'empêche de se mettre en tâche de fond.
--user ‹user[.group]› Par défaut le serveur change d'intentité à nobody.nogroup.
--group ‹group› Permet de changer le group
--port ‹number› Spécifie le port d'écoute
--bind-address ‹IP address› Par défaut le serveur écoute sur toutes les interfaces.
--mcast-ttl TTL à utiliser pour le multicast. 1 par défaut.
--mcast-addr Spécifie la page IP à utiliser pour le transfert multicast. défaut : 239.255.0.0-255
--mcast-port Port udp à utiliser pour le transfert multicast
--pcre-test ‹file› Test un fichier. En utilisant cette option, le serveur ne démarrera pas mais va juste lire le fichier et afficher la substitution.
--mtftp ‹file› Démarre un thread serveur mtftp pour chaque entrée valide dans le fichier spécifié. Voir la spécification PXE.
--mtftp-port ‹port› port d'écoute du serveur mtftp
--no-source-port-checking Empêche la vérification du port (utilie pour les NAT) Ne fonctionne que pour transfert non-multicast
--mcast-switch-client Cette option permet au serveur de traiter le prochain client multicast le plus tôt possible une fois qu'il a terminé avec le client courant.
path Répertoire racine utilisé par le serveur. défaut /tftpboot.

Statistiques

   Le serveur collecte quelques statistiques. Il calcule la charge système, le temps entre les connexions et quelques statistiques sur les threads, comme le nombre de fichiers envoyés, reçus, annulations etc... Pour voir ces statistiques dans les logs, définir --verbose=6 ou +.

Sécurité

   TFTP par lui-même n'a aucun mécanisme de sécurité. Il n'y a pas d'authentification d'utilisateur et les clients tftp peuvent accéder à tous les fichiers. Une petite sécurité peut être mise en place avec atftpd libwarp. Ajoute les entrées dans /etc/hosts.allow et /etc/hosts.deny. le démon qui utilise ces fichiers est in.tftpd

PCRE

   Le serveur atftpd fournis une manière pour remplacer dynamiquement un nom de fichier requis par un nouveau basé sur une expression régulière perl. Les paires pattern/remplacement sont lu depuis un fichier. Une fois la réceptions d'une requête de lecture, le serveur ouvre le fichier demandé. S'il échoue, il va chercher un fichier de remplacement basé sur le contenu du fichier pattern.

exemple de fichier de configuration (/etc/default/atftpd):
OPTIONS="--daemon --user tftp --group tftp --bind-address 10.20.30.1 --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 10 --logfile /var/log/atftpd.log --verbose=6 /var/lib/tftpboot"
^
05 septembre 2015

htmlpdflatexmanmd




attr

attr

Attributs étendus

   Les attributs étendus sont des paires nom:valeur associés de manière permanente avec les fichiers et les répertoires, similaire aux chaînes d'environnement associés avec un processus. Un attribut peut être définis ou non-définis. S'il est définis, sa valeur peut être vide ou non-vide

   Les attributs étendus sont des extensions aux attributs normaux qui sont associés avec tous les inodes dans le système de fichier. Ils sont souvent utilisé pour fournir des fonctionnalités additionnels au système de fichier, par exemple, des fonctionnalités de sécurité additionnels tels que les ACL.

   Les utilisateurs avec un accès en recherche sur un fichier ou répertoire peut récupérer une liste de noms d'attributs définis pour ce fichier ou répertoire.

   Les attributs étendus sont accedés comme des objets atomique. Lire récupère toute la valeur d'un attribut et le stocke dans un tampon. Écrire remplace une valeur précédente avec une nouvelle valeur.

   L'espace consommé par les attributs étendus sont comptés dans le quota disque.

   Actuellement, le support pour les attributs étendus est implémenté dans les systèmes de fichier ext2, ext3, ext4, XFS, JFS et reiserfs.

Espaces de nom d'attribut étendus

   Les noms d'attribut sont des chaînes terminés par un 0. Le nom d'attribut est toujours spécifié sous la forme pleinement qualifié namespace.attribute. par exemple user.mime_type, trusted.md5sum, system.posix_acl_access, ou security.selinux.

   Le mécanisme d'espace de nom est utilisé pour définir les différentes classes d'attribut étendus. Ces différentes classe existent pour de nombreuses raisons, par exemple les permissions et capabilities requises pour manipuler les attributs étendus d'un espace de nom peut différer d'un autre.

   Actuellement les classes d'attribut étendus security, system, trusted, et user sont définis comme décris ci-dessous. D'autres classes pourront être ajoutés dans le future.

Attributs de sécurité étendus

   L'espace de nom d'attribut de sécurité est utilisé par les module de sécurité du kernel, tels que SELinux. Les permissions d'accès en lecture et écriture aux attributs de sécurité dépend de la stratégie implémenté pour chaque attribut de sécurité par le module de sécurité. Quand aucun module de sécurité n'est chargé, tous les processus ont un accès en lecture aux attributs de sécurité étendu, et l'accès en écriture est limitée aux processus qui ont la capability CAP_SYS_ADMIN.

Attributs système étendu

   Les attributs système étendus sont utilisés par le kernel pour stocker des objets système tels que des listes de contrôle d'accès et des capabilities. Les permissions d'accès en lecture et écriture au attributs système dépendent de la stratégie implémenté pour chaque attribut système implémenté par le système de fichier dans le kernel.

Attributs étendus de confiance

   Les attributs étendus de confiance sont visibles et accessible seulement aux processus qui ont la capability CAP_SYS_ADMIN. Les attributs dans cette classe sont utilisés pour implémenter des mécanismes dans l'espace utilisateur qui conserve des informations dans des attributs étendus que des processus ordinaire ne devraient pas avoir accès.

Attributs utilisateur étendus

   Les attributs utilisateur étendus peuvent être assignés aux fichier et répertoires pour stocker des informations additionnelles tels que le type mime, jeu de caractère ou encodage d'un fichier. Les permissions d'accès pour les attributs utilisateur sont définis par les bits de permission de fichier.

   Les bits de permission de fichier des fichiers régulier sont interprétés différemment des bits de permission de fichier des fichier spéciaux et des liens symboliques. Pour les fichier régulier et les répertoires les bits de permission de fichier définissent l'accès au contenu des fichiers, alors que pour les fichiers spéciaux de périphériques ils définissent l'accès au périphérique décris par le fichier spécial. Les permissions de fichier des liens symboliques ne sont pas utilisé pour la vérification d'accès. Ces différences permettent aux utilisateurs de consommer des ressources système d'une manière non contrôlable par les quotas disques pour les fichier spéciaux et les répertoires.

   Pour cette raison, les attributs utilisateur étendus sont seulement permis pour les fichier régulier et les répertoire, let l'accès aux attributs utilisateurs étendus est restreint au propriétaire et aux utilisateurs avec les capabilities appropriés pour les répertoire avec le sticky bit mis.

Différences de système de fichiers

   Le kernel et le système de fichiers peuvent placer des limites sur le nombre et la taille maximum d'attributs étendus qui peuvent être associés avec un fichier. Certains système de fichier comme ext2/3 et reiserfs exigent que le système de fichier soit monté avec l'option de montage user_xattr pour que les attributs étendus soient utilisés.

   Dans les implémentations ext2/3/4 courante, chaque attribut étendu doit être contenu dans un seul block du système de fichier.

   Dans les implémentations reiserfs et XFS, il n'y a pas de limite pratique sur le nombre ou la taille d'attributs étendus associé avec un fichier, et les algorithmes utilisé pour stocker les informations d'attribut sur le disque sont scalaires.

   Dans l'implémentation du système de fichier JFS, les noms peuvent avoir jusqu'à 255 octets et des valeurs jusqu'à 64Ko.

Notes

   Vu que les systèmes de fichier sur lequel les attributs étendus sont stockés peuvent également être utilisés dans les architecture avec un ordre d'octets différent et une taille de mot différent, le stockage des valeurs d'attribut doivent faire d'objet d'une attention particulière.
^
08 février 2015

htmlpdflatexmanmd




attrd_updater

attrd_updater

Outil de mise à jour des attributs de nœud du cluster

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux
-n, --name=value Le nom de l'attribut

Commandes

-U, --update=value Met à jours la valeur de l'attribut dans attrd. Met à jours également la configuration du cluster
-Q, --query Lis la valeur de l'attribut depuis attrd
-D, --delete Supprime la valeur dans attrd.
-R, --refresh Force le service atrd à renvoyer toutes les valeurs courants à CIB.

Options additionnelles

-l, --lifetime=value Durée de vie de l'attribut du nœud (forever ou reboot)
-d, --delay=value Temps d'attente en seconde pour que d'autres changements se produisent
-s, --set=value Jeu d'attributs dans lequel placer la valeur.
^
31 mai 2017

htmlpdflatexmanmd




audispd

audispd

Multiplexeur d'évènement

   audispd doit être démarré par auditd pour obtenir les évènements, qu'il distribut aux programmes enfants qui souhaitent analyser les évènements en temps réel. Quand auditd reçoit SIGTERM ou SIGHUP, il passe ce signal au dispatcher également, qui en retour le passe aux processus enfant.

   Les programmes enfant installent un fichier de configuration dans un répertoire, /etc/audisp/plugins.d/. Les noms de fichier ne doivent pas avoir plus d'un '.' dans le nom sinon ils sont traités comme copie de sauvegarde et ignorés. Les options sont:

OPTIONS

active (bool)
direction Dicté par le plugin. (in, out)
path Chemin complet du plugin. Dans le cas des plugins internes, c'est juste le nom.
type Indique commment le plugin est lancé (builtin, always). builtin devrait toujours être spécifié pour les plugins internes, sinon always.
args Permet de passer des arguments au programme enfant. Il y a une limite de 2 arguments
format binary ou string. binary passe les données tel que audispd les a reçu. string est plus adapté au parsing
^
02 juin 2017

htmlpdflatexmanmd




audispd.conf

audispd.conf

Fichier de configuration du dispatcher d'évènement d'audit

q_depth Valeur numérique indiquand la taille de queue interne du dispatcher. Défaut: 80
overflow_action Détermine la réaction du service au débordement de sa file d'attente. ignore, syslog, suspend, single et halt
priority_boost Nombre non-négatif qui indique la priorité qu'il doit utiliser. Ce boost est ajouté au boost fournis par auditd. Défaut: 4. 0 = aucun changement
max_restarts Nombre non-négatif indiquant le nombre maximum de tentative de redémarrer un plugin crashé. Défaut: 10
name_format Contrôle le format des noms de nœud insérés dans le flux d'évènements. none, hostname, fqd, numeric, et user
name Chaîne identifiant la machine si name_format = user

^
02 juin 2017

htmlpdflatexmanmd




audit.rules

audit.rules

Jeu de règles chargés dans le système d'audit

   Le fichier audit.rules est un fichier contenant des règles d'audit chargés par auditd au démarrage. auditctl est utilisé pour cette opération. Les régles d'audit sont de 3 type: control, file, et syscall

contrôle

   Les commandes de contrôle configurent le système d'audit. Ces commande incluent typiquement la suppression de toutes les règles, définir la taille de file backlog, définir le mode d'erreur, etc.

Système de fichier

   Ces régles sont parfois appelées des watchs. Ces règles sont utilisée pour auditer les accès à des fichiers particuliers. La syntaxe suit généralement ce format: -w path-to-file -p permissions -k keyname où les permissions sont une des suivantes: r,w,x,a

appels système

   Ces règles sont chargées dans un moteur qui intercepte chaque syscall que tous les programmes font dans le système. Noter que cela impacte les performances.

  Le kernel a 4 règles: task, exit, user et exclude.

task Cette liste est vérifie seulement durantles syscall fork ou clone. Rarement utilisé en pratique.
exit Est l'endroit où tous les syscall et requêtes d'audit système sont évalués
user Utilisé pour filtrer (supprimer) certains évènements qui viennent du userspace.
exclude Utilisé pour exclure certains évènements. Le champ msgtype est utilisé pour indiquer au kernel les types de message à ne pas enregistrer.

   Les règles syscall prenne la forme générale:-a action,list -S syscall -F field=value -k keyname

-a indique d'ajouter une règle à la fin de la liste.
action et list sont séparés par une virgule. les listes valides sont task, exit, user et exclude, les actions valide sont always ou never (créer un évènement)
La suite de la règle est normalement -S, qui peut être soit un nom ou un numéro de syscall.
L'option -F affine le matche. Voir auditctl pour une liste complète de champ.

Notes

En faisant une investigation, on commence normalement avec aureport pour avoir une idée de ce qui se passe dans le système. Ce rapport indique principalement les évènements hardcodés par le système d'audits tels que les login/logout, authentifications, anomalies système, etc.
aureport --start this-week
Ensuit, pour obtenir une seconde vue des règles chargées:
aureport --start this-week --key --summary
Cela donne une liste ordonnée des clés associées avec les règles Si par exemple, une règle syscall sur un échec d'ouverture d'un fichier avec EPERM, avec une clé nommée access:
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
On peut isoler ces erreurs avec auseurch et envoyer le résultat à aureport.
ausearch --start this-week -k access --raw | aureport --file --summary
Supposons que l'on souhaite voir quels utilisateurs se sont vu refuser l'accès:
ausearch --start this-week -k access --raw | aureport --user --summary
Pour afficher beaucoups d'accès échoués à un fichier particulier, on peut lancer un rapport pour voir qui le fait:
ausearch --start this-week -k access -f /path-to/file --raw | aureport --user -i
Ce rapport donne les tentatives d'accès par personne. Pour voir un évènement particulier, regarder la date et l'heure. Assumant que l'évènement est le 822 à 2:30 le 09/01*2009.
ausearch --start 09/01/2009 02:30 -a 822 -i --just-one
Sélectionne le premier évènement de ce jour.

Exemples

La règle suivante montre comment auditer les erreurs d'accès aux fichiers à cause de problèmes de permission. Noter que ça demande 2 règles pour chaque architecture:
-a always,exit -F arch=b32 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b32 -S open -S openat -F exit=-EPERM -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
^
29 mai 2017

htmlpdflatexmanmd




auditctl

auditctl

Utilitaire de contrôle du système d'audit Linux

Options de configuration

-b backlog Définis le nombre max de tampon d'audit permit (défaut: 64). Si tous les tampons sont pleins, le flag d'erreur est consulté par le kernel.
--backlog_wait_time wait_time Définis de temps (défault: 60*Hz) que le kernel attend lorsque backlog_limit est atteind avant de mettre plus d'évènements d'audit en queue à transférer à auditd. Doit être supérieur ou égal à 0 et inférieur à 10 fois la valeur par défaut.
-c Continue à charger les règles malgré les erreurs. Génère un sommaire du résultat du chargement des règles
-D Supprime toutes les règles et watchs
-e [0..2] Définis le flag enable. 0 = désactivé, 1 = activé, 2 = bloqué en l'état actuel.
-f [0..2] Défpinis le mode failure. 0 = silencieux, 1 = printk, 2 = panic. Permet de déterminer comment le kernel gère les erreurs critiques.
-i Ignore les erreurs en lisant les règles depuis un fichier.
--loginuid-immutable Rend les loginuid inchangeables une fois définis.
-q mount-point.subtree Si vous avez un watch répertoire existant, et un montage déplacé ou bindé ailleurs dans le subtree rechargé, il faut indiquer au kernel que le subtree mounté est équivalent au répertoire regardé. Si le subtree est déjà monté au moment où le watch est émis, le subtree est automatiquement taggé pour surveilance.
-r rate Définis la limite des message par seconde. (0=pas de limite). Si ce taux est atteind, le flag failure est consulté
-R file Lit les règles dans un fichier.
-t Déclence les subtrees après une commande mount

Options de status

-l Liste toutes les règles, 1 par ligne. 2+ options peuvent être passées à cette commande. -k liste les règles qui matche une clé, ou -i pour interpreter a0 à a3 pour aider à déterminer les valeurs d'argument syscall.
-m text Envoie un message userspace dans le système d'audit. Ne peut être fait qu'avec la capability CAP_AUDIT_WRITE.
-s Reporte le status du sous-système d'audit

Options de règle

-a [list,action|action,list] Ajoute une règle à la fin de la liste avec l'action spécifié. Les champs peuvent être dans n'importe quel ordre. Les noms de liste valides, puis d'actions sont:

        task Ajoute une règle à la liste par tâche. Utilisée seulement quand une tâche est créée ( fork() ou clone() )
        exit Ajoute une règle à la liste de sortie syscall. Utilisée à la sortie d'un appel système pour déterminer si un évènement d'audit devrait être créé
        user Ajoute une règle à a liste de filtre de message utilisateur. Utilisé par le kernel pour filtrer les évènements venant du userspace avant de les relayer à service d'audit.
        exclude Ajoute une règle à la liste de filtre d'exclusion de type d'évènement. Cette liste est utilisée pour filtrer les évènement que l'on ne veut pas voir.

        never Aucun enregistrement d'audit n'est généré.
        always Alloue un contexte d'audit.

-A list,action Ajoute une règle au début de la liste
-C [f=f | f!=f] Construit une règle de comparaison inter-champ. Peut être spécifié plusieurs fois. Les 2 opérateurs supportés sont equel et not equal. Les champs valides sont: auid, uid, euid, suid, fsuid, obj_uid; and gid, egid, sgid, fsgid, obj_gid
-d list,action Supprime une règle de la liste. La règle est supprimée seulement si les noms syscall matchent exactement.
-F [n=v | n!=v | n‹v | n›v | n‹=v | n›=v | n&v | n&=v] Construit un champs de règle: nom, opération, valeur. Peut être spécifié jusqu'à 64 fois. Chaque équation est combinée l'une avec l'autre pour déclencher un enregistrement d'audit. Il y a 8 opérateurs supportés: égal, non égal, inférieur à, supérieur à, inférieur ou égal à, supérieur ou égal à, mask de bit ou test de bit. Les champs qui prennent un uid peuvent utiliser le nom de l'utilisateur. Les champs valides sont:

        a0, a1, a2, a3 Les 4 arguments d'un syscall. Noter que les arguments chaîne ne sont pas supportés.
        arch Architecture CPU du syscall (uname -m)
        auid ID original de l'utilisateur. raccourci de audit uid, parfois appelé loginuid
        devmajor Numéro majeur de périphérique
        devminor Numéro mineur de périphérique
        dir Chemin complet d'un répertoire à regarder
        egid gid effectif
        euid uid effectif
        exe Chemin absolu de l'application à laquelle cette règle s'applique. Uniquement dans une liste exit
        exit Valeur de sortie d'un syscall
        fsgid GID du système de fichier.
        fsuid UID du système de fichier
        filetype Type du fichier cible (file, dir, socket, link, character, block, ou fifo)
        gid id du groupe
        inode Numéro d'inode
        key Autre manière de définir une clé filtre. voir -k
        msgtype Utiliser pour matcher le type d'enregistrement de l'évènement. devrait être utilisé dans les listes d'exclusion ou utilisateur
        obj_uid UID de l'objet
        obj_gid GID de l'objet
        obj_user Utilisateur SELinux de la ressource
        obj_role Type SELinux de la ressource
        obj_type Type SELinux de la ressource
        obj_lev_low niveau inférieur SELinux de la ressource
        obj_lev_high Niveau supérieur SELinux de la ressource
        path Chemin complet du fichier à regarder. Ne peut être utiliser que dans la liste exit
        perm Filtre de permissions pour les opérations de fichier. Voir -p Uniquement dans la liste exit
        pers Numéro de personnalité OS
        pid ID de processus
        ppid ID du processus parent
        subj_user Utilisateur SELinux du programme
        subj_role role SELinux du programme
        subj_type Type SELinux du programme
        subj_sen Sensibilité SELinux du programme
        subj_clr Autorisation SELinux du programme
        sgid gid sauvé.
        success Si la valeur de sortie est ›=0, c'est true/yes (1), sinon false/no (0)
        suid UID sauvé
        uid id de l'utilisateur

-k key Définis une clé filtre dans une règle d'audite. C'est une chaîne arbitraire (max 31 octets) qui peut identifier de manière unique les enregistrements d'audit produits par une règle. Peut être spécifié plusieurs fois
-p [r|w|x|a] Décrit les types d'accès sur lesquels se déclence un watch de système de fichier.
-S [Syscall name or number|all] Si le syscall doné est fait par un programme, démarre un enregistrement d'audit. Peut être spécifié plusieurs fois
-w path Insert un watch pour un objet système de fichier au chemin spécifié.
-W path Suppmire un watch pour l'objet système de fichier.

Performances

Les règles syscall sont évaluées pour chaque syscall pour chaque programme. Avec 10 règles syscall, chaque programe dans le système est retardé durant un syscall jusqu'à ce que le système d'audit évalu chaque règle, ce qui peut impacter fortement les performances. Tenter de combiner autant de filtre, action, clé, et champs que possible sont identiques. Par exemple:
auditctl -a always,exit -S openat -F success=0
auditctl -a always,exit -S truncate -F success=0
peuvent être reécris en une seule règle:
auditctl -a always,exit -S openat -S truncate -F success=0
Également, tenter d'utiliser l'audit de système de fichier améliore les performances. Par exemple, pour capturer toutes les ouvertures échouées, mais seulement les fichiers dans /etc:
auditctl -a always,exit -S openat -S truncate -F dir=/etc -F success=0
Cela améliore les performances vu que le kernel n'évalue pas chaque syscall. C'est géré par le code d'audit de système de fichier.

Exemples

Voir tous les syscalls faits par un programme spécifique
auditctl -a always,exit -S all -F pid=1005
Vois les fichiers ouverts par un utilisateur spécifique
auditctl -a always,exit -S openat -F auid=510
Voir les appels openat échoués
auditctl -a always,exit -S openat -F success=0
Regarder les changements d'un fichier (2 manières exprimées)
auditctl -w /etc/shadow -p wa
auditctl -a always,exit -F path=/etc/shadow -F perm=wa
Regarder les changements, récursivement dans un répertoire (2 manières exprimées)
auditctl -w /etc/ -p wa
auditctl -a always,exit -F dir=/etc/ -F perm=wa
Voir si un admin accède aux fichier des autres utilisateurs:
auditctl -a always,exit -F dir=/home/ -F uid=0 -C auid!=obj_uid
^
29 mai 2017

htmlpdflatexmanmd




auditd

auditd

Service d'audit Linux

   auditd est le composant userspace du système d'audit Linux. Il est responsable de l'écriture des enregistrements d'audit sur disque.

OPTIONS

-F Ne lance pas en tâche de fond
-l Autorise à suivre les liens symboliques pour les fichiers de configuration
-n  ne fork pas
-s=ENABLE_STATE Indique si auditd devrait changer la valeur courante du flag enabled du kernel (disable, enable ou nochange).

Signaux

SIGHUP reconfigure auditd
SIGTERM Stop l'audit, écrit un évènement d'arrêt, et quitte
SIGUSR1 rotation automatique des logs
SIGUSR2 tente de relancer le logging

Fichiers

/etc/audit/auditd.conf Fichier de configuration pour auditd
/etc/audit/audit.rules Règles d'audit à charger au démarrage
/etc/audit/rules.d/ Jeux de règles individuels à compiler par augenrules

Notes

   Le paramètre de boot audit=1 devrait être ajouté pour s'assurer que tous les processus qui sont lancés avant le service auditd soient marqués comme auditable par le kernel. Noter que faire cela rend quelques processus impossible à auditer.

  auditd peut reçevoir des évènements depuis d'autres services auditd via le plugin audisp-remote. auditd peut être liés avec tcp_wrappers pour contrôler quelles machines peuvent s'y connecter.
^
02 juin 2017

htmlpdflatexmanmd




auditd.conf

auditd.conf

Fichier de configuration du service d'audit

local_events (bool) Spécifie si les évènements locaux sont inclus. Défaut: yes.
log_file Spécifie le chemin complet du fichier de log où les enregistrements d'audit sont stockés
write_logs [bool) Détermine si les logs sont stockés sur disque. Défaut: yes.
log_format Format des logs stockés sur disque: raw et enriched. enriched résoud les uid, gid, syscall, architecture, et adresse socket.
log_group Spécifie le groupe du fichier de log. Défaut: root
priority_boost Nombre non-négatif qui indique la priorité. Défaut 4.
flush none ne fait rien de spécial pour vides les enregistrements sur disque. incremental utilise freq pour déterminer la fréquence, incremental_async est similaire, mais de manière asynchrone pour de meilleurs performances. data conserve les données du disque synchronisés en permanence. sync conserve les données et les métadonnées pleinement synchronisés. Défaut: incremental_async
freq Nombre non-négatif indiquant le nombre d'enregistrement à écrire avant de les vider sur disque.
num_lgos Spécifie le nombre de fichiers de logs à conserver. ‹ 2, la rotation de logs n'est pas effectuée. Doit être inférieur à 1000.
disp_qos Contrôle si la communication est bloquante/sans perte ou non-bloquante/avec perte entre auditd et le dispatcher. Il y a un tampon de 128K entre les 2, ce qui est suffisant dans la plupart des cas. (lossy ou lossless). Défaut: lossy
dispatcher Spécifie le dispatcher.
name_format Contrôle comment insérer les noms de nœud dans le flux d'évènements d'audit. none, hostname, fqd, numeric, et user. Défaut: none
name Nom à utiliser lorsque name_format = user
max_log_file Spécifie la taille max des fichiers de log. Une fois cette limite atteinte, il déclence une action de configuration
max_log_file_action Indique au système quelle action prendre quand le système a détecté que la limite de taille du fichier de log est atteinte.
action_mail_acct Adresse email ou alias. /usr/lib/sendmail doit exister dans la machine
space_left Valeur numérique, en Mo, indiquant quand effectuer une action lorsque l'espace disque vient à manquer
space_left_action Indique quelle action prendre quand l'espace disque restant est inférieur à space_left. (ignore, syslog, rotate, email, exec, suspend, single, ou halt)
admin_space_left Identique à space_left. Est considéré comme la dernière change de faire quelque chose avant de ne plus avoir d'espace disque.
admin_space_left_action Indique quelle action prendre quand l'espace disque restant est inférieur à admin_space_left
disk_full_action Indique quelle action prendre quand le système a détecté que la partition qui maintient les logs est pleine. (ignore, syslog, rotate, exec, suspend, single, et halt)
disk_error_action Indique quelle action prendre quand une erreur disque est détectée en écrivant des évènements d'audit sur disque.
tcp_listen_port Port tpc d'écoute des enregistrements d'audit des systèmes distants.
tcp_listen_queue Valeur numérique qui indique combien de connexions en cours sont permises. Défaut: 5
tcp_max_per_addr Valeur numérique indiquant combien de connection concurrentes de la même IP sont permises. Défaut: 1 (max 1024)
use_libwrap (bool) Utilise tcp_wrappers pour définir les machines autorisées à se connecter
tcp_client_ports 1 ou 2 valeurs numérique. Indique les ports clients permis pour les connexions entrante. Spécifier 1-1023 pour autoriser les port privilégiés
tcp_client_max_idle Délai en secondes d'inactivité d'un client avant que la connexion soit terminées. Défaut: 0 = désactive la vérification
enable_krb5 (bool) Utilise kerberos pour l'authentification et le chiffrement
krb5_principal Principal du serveur. Défaut: auditd.
krb5_key_file Emplacement de la clé du principal du client. Cette clé doit être possédée par root, en mode 0400. Défaut: /etc/audit/audit.key
distribute_network (bool) À yes, les évènements provenant du réseau sont distribués au dispatcher pour traitement. Défaut: no

Notes

- Dans un environneent CAPP, Le chemin d'audit est si important que l'accès aux ressources système doit être refusé si un chemin d'audit ne peut être créé. Dans cet environnement, il est suggéré que /var/log/audit soit dans sa propre partition.
- Le paramètre flush devrait être sync ou data
- space_left doit être être une valeur qui donne suffisamment de temps à un administrateur de réagir et de récupérer de l'espace disque. Cela peut impliquer aureport -t et le déplacement des anciens logs. Il est recommandé que space_left_action soit email.
- admin_space_left doit être l'espace disque nécessaire pour les actions administratives à enregistrer.
- disk_full_action est déclenchée quand il n'y a plus de place. Tous les accès devraient être terminés vu qu'il n'y a plus de capacité d'audit. Peut être définis à single ou halt
- disk_error_action devrait être syslog, sigle ou halt en fonction de la stratégie locale
- Spécifie ue seul port client permis peut poser problème pour le client souhaitant redémarrer le sous-système d'audit, vu qu'il n'est pas capable de recréer une connexion avec les même adresses d'hôte et ports tant que la connection est à l'état TIME_WAIT.
^
29 mai 2017

htmlpdflatexmanmd




augenrules

augenrules

Script qui fusionne les fichiers de règle d'audit

   augenrules est un script qui fusionne tous les composants de règle d'audit dans /etc/audit/rules.d dans un fichier /etc/audit/audit.rules. Les fichiers de règle doivent se terminer par .rules pour être traités. Les fichiers sont concaténés dans l'ordre. Le fichier généré est copié dans /etc/audit/audit.rules seulement s'il diffère.

- La dernière directive -D traitée sans option, si presente, et toujours émise comme première ligne du fichier résultant.
- La dernière directive -h traitée, si présente, est toujours émise comme seconde ligne du fichier résultant.
- La dernière directive -f traitée, si présente, est toujours émise comme 3ème ligne
- La dernière directive -e traitée, si présente, est toujours émise comme dernière ligne.

OPTIONS

--check Teste si les règles ont changées et doivent être mises à jours sans écrases les règles d'audit
--load Charge les anciennes et les nouvelles règles dans le kernel
^
31 mai 2017

htmlpdflatexmanmd




aulast

aulast

Programme similaire à last

   aulast affiche une liste des dernières connexions utilisateurs, similairement au programme last et lastb. Il recherche dans le logs d'audit et affiche une liste de tous les utilisateurs connectés/déconnectés.

OPTIONS

--bad Affiche les mauvais logins
--extract Écrit les enregistrement brut pour créer le rapport affiché dans un fichier aulast.log dans le répertoire courant
-f‹file› Lit les logs d'audit depuis le fichier spécifié
--proof Affiche les numéros de série d'évènement d'audit utilisés pour déterminer la ligne précédente du rapport.
--stdin Prend les enregistrements depuis stdin. Les évènement doivent être au format brut
--tty Limite le rapport à l'activité du tty
--user‹name› Limite de rapport à l'utilisateur spécifique

Exemples

Voir les logins de ce mois
ausearch --start this-month --raw | aulast --stdin
^
29 mai 2017

htmlpdflatexmanmd




aulastlog

aulastlog

Programme similaire à lastlog

   aulastlog est un programme qui afiche le dernier login pour tous les utilisateurs de la machine locale.

OPTIONS

-u, --user Affiche l'enregistrement lastlog pour l'utilisateur avec le login spécifié uniquement
--stdin Utilise stdin comme source des enregistrement d'audit. Les évènements doivent être au format raw
^
31 mai 2017

htmlpdflatexmanmd




aureport

aureport

Outil de rapports des logs d'audit

   aureport produit un sommaire des logs d'audit système.

OPTIONS

-au, --auth Affiche les tentative d'authentification
-a, --avc Affiche les messages avc
--comm afficher les commandes lancées
-cr, --crypto Affiche les évènements crypto
-f, --file Affiche les fichiers et sockets af_unix
--failed Ne sélectionne que les évènements échoués.
-h, --host Afficher les hôtes
-i, --interpret Interprète les entités numérique en texte.
-if, --input file | directory Utilise le fichier donné au lieu des logs
--input-logs Utilise l'emplacement des logs depuis auditd.conf comme entrées.
--integrité Affiche les évènements d'intégrité
-k, --key Affiche les clés des règles d'audit
-l, --login Affiche les logins
-m, --mods Affche les modifications de compte
-ma, --mac Affiche les évènements MAC
-n, --anomaly Affiche les évènement anormaux
--node node-name Ne sélectionne que les évènements venant du nœud spécifié
-nc, --no-config N'inclus pas les évènements CONFIG_CHANGE
-p, --pid Affiche les processus
-r, --response AFfiche les réponse aux évènements anormaux
-s, --syscall Affiche les syscall
--success Affiche seulement les évènements réussis
--summary Lance un sommaire qui donne un total des éléments du rapport principal
-t, --log Affiche un rapport du début et fin pour chaque log
--tty AFfiche les touches tty
-te, --end [end-date] [end-time] Recherche les évènement avant cette date/heure. mots clés permis: now, recent, today, yesterday, this-week, wwek-ago, this-month, this-year.
-tm, --terminal Affiche les terminaux
-ts, --start [start-date] [start-time] Affiche les évènements après cette date/heure. Les mots clé de -te sont permis.
-u, --user Affiche les utilisateurs
--virt Affiche les évènement de virtualisation
-x, --executable Affiche les exécutables
^
31 mai 2017

htmlpdflatexmanmd




ausearch

ausearch

Outil de requête de logs d'audit

OPTIONS

-a, --event audit-event-id Recherche un évènement basé sur l'id doné. Les messages commencent toujours par msg=audit(1116360555.329:2401771, l'id étant le nombre après le ':'.
--arch CPU Recherche les évènements basé sur une architecture CPU.
-c, --comm comm-name Recherche un évènement basé sur le nom de l'exécutable.
--debug Affiche les évènements mal-formés sur stderr
--checkpoint checkpoint-file checkpoint la sortie entre les invocation successive de ausearch de manière à ce que seuls les évènements qui n'ont pas été sortie sont affichés dans les invocations suivantes
-e, --exit exit-code-or-errno Recherche un évènement basé sur le code de sortie syscall donné
-f, --file filename Recherche un évènement basé sur le nom de fichier donné, ou socket af_unix
-ga, --gid-all all-group-id Recherche en évènement avec le gid ou gid effectif spécifié
-ge, --gid-effective effective-group-id Recherche en évènement avec le gid effectif spécifié
-gi, --gid group-id Recherche en évènement avec le gid spécifié
-hn, --host hostname Recherche en évènement avec le nom d'hôte spécifié
-i, --interpret Interprète les entités numériques en texte.
-if, --input filename | directory Utilise le fichier ou répertoire au lieu des logs
--input-logs Utilise l'emplacement des logs spécifié dans auditd.conf pour la recherche
--just-one Stop une fois le première évènement correspondant trouvé
-k, --key key-string Recherche en évènement basé sur la clé donnée
-l, --line-buffered Vide la sortie sur chaque ligne.
-m, --message message-type | comma-sep-message-type-list Recherche un évènement correspondant au type de message spécifié.
-n, --node node-name Recherche les évènements venant du ou des nœuds spécifiés.
-o, --object SE-Linux-context-string Recherche des évènements venant avec le tcontext donné
-p, --pid process-id Recherche un évènement avec le PID de processus donné
-pp, --ppid parent-process-id Recherche un évènement ayant le PID de processus parent donné
-r, --raw Sortie non formatée
-sc, --syscall syscall-name-or-value Recherche un évènement correspondant au syscall donné
-se, --context SE-Linux-context-string Recherche un évènement avec les scontext ou tcontext donné
--session Login-Session-ID Recherche un évènement avec l'ID de session donné
-su, --subject SE-Linux-context-string Recherche un évènement avec le scontext donné
-sv, --success success-value Recherche un évènement avec la valeur de succès donné (yes ou no)
-te, --end [end-date] [end-time] Recherche les évènement avant cette date/heure. mots clés permis: now, recent, today, yesterday, this-week, wwek-ago, this-month, this-year.
-ts, --start [start-date] [start-time] Affiche les évènements après cette date/heure. Les mots clé de -te sont permis.
-tm, --terminal terminal Recherche un évènement correspondant à la valeur terminal donnée
-ua, --uid-all all-user-id Recherche un évènement avec l'UID ou UID effectif donné
-ue, --uid-effective effective-user-id Recherche un évènement avec l'UID effectif donné
-ui, --uid user-id Recherche un évènement avec l'UID donné
-ul, --loginuid login-id Recherche un évènement avec le login id donné
-uu, --uuid guest-uuid Recherche un évènement avec l'uuid invité donné
-vm, --vm-name guest-name Recherche un évènement avec le nom de l'invité donné
-w, --word Chaîne de recherche à matcher
-x, --executable executable Recherche un évènement correspondant à l'exécutable donné

Codes de sortie

0 succès
1 Rien n'est trouvé, erreur d'argument, erreur d'accès fichier mineur
10 données checkpoint invalide
11 Erreur de traitement de checkpoint
12 Évènement checkpoint non trouvé dans le fichier de log
^
02 juin 2017

htmlpdflatexmanmd




ausearch-expression

ausearch-expression

Format d'expression de recherche d'audit

Structure lexicale

   Les espaces blancs sont ignorés. Les éléments suivants sont reconnus:

Ponctuation
( ) \
opérateurs logiques
! && ||
Opérateurs de comparaison
‹ ‹= == › ›= !== i= i!= r= r!=
expressions régulières

Syntaxe

field comparison-operator value
field est une chaîne qui spécifie le premier champ avec ce nom dans l'enregistrement, ou \ suivi d'une chaîne, qui spécifie un champ virtuel avec le nom spécifié.
operator Spécifie la comparaison à effectuer
r= r!= chaîne brute du champ (tel que stocké), et la compare à la valeur.
i= i!= Chaîne interprétée du champs
‹ ‹= == › ›= !== Opérateurs d'évaluation
\regexp string-or-regexp Dans ce cas spécial, l'enregistrement d'audit est pris comme une chaîne, et matché avec regexp-or-string, qui est une expression régulière étendue,.

   Si E1 et E2 sont des expressions valides, alors ! E1, E1 && E2, et E1 || E2 sont des expressions valides également. Noter que ! field op value est interprétée comme !(field op value), et non pas (!field) op value.

Champs virtuels

\timestamp Valeur d'horodatage de l'évènement courant. Value doit avoir le format ts:‹seconds›.‹milli›.
\record_type La valeur est le type d'enregistrement courant.
^
31 mai 2017

htmlpdflatexmanmd




ausyscall

ausyscall

Mappage des noms en numéro syscall

   ausyscall affiche le mappage des noms syscall en numéro et inversement pour l'architecture donnée. Il peut être utilisé pour vérifier les numéros syscall dans une plateforme pour optimiser les règles.

Supposons une règle auditctl:
-a always, exit -S open -F exit=-EPERM -k fail-open
Pour vérifier que les programmes 32 et 64 bits sont audités, lancer
ausyscall i386 open
et
ausyscall x86_64 open
Et regarder les numéros retournés. S'ils sont différents, il faut écrire 2 règles pour obtenir une couverture complète:
-a always,exit -F arch=b32 -S open -F exit=-EPERM -k fail-open
-a always,exit -F arch=b64 -S open -F exit=-EPERM -k fail-open

OPTIONS

--dump Affiche tous les syscalls pour l'architecture donnée
--exact Match exact (au lieu de partiel) du nom syscall
^
24 janvier 2015

htmlpdflatexmanmd




auth.conf

auth.conf

Fichier d'authentification pour libvirt

Description

   Ce fichier peut être spécifié de plusieurs manières différentes, il est recherché dans cet ordre:

- Le fichier peut être spécifié par la variable d'environnement $LIBVIRT_AUTH_FILE
- le fichier spécifié dans la partie transport dans l'URI (ex: authfile=/some/file)
- le fichier situé dans $XDG_CONFIG_HOME/libvirt/auth.conf
- le fichier /etc/libvirt/auth.conf

   Ce fichier utilise la syntaxe traditionnelle '.ini'. Il y a 2 types de groupes qui peuvent être présent dans la configuration. D'abord il y a un ou plusieurs jeu d'accréditifs, qui fournissent les accréditations d'authentification. Les clés dans le groupe peuvent être:

username Nom de login utilisateur. Pas utile pour libvirtd avec sasl.
authname Nom d'autorisation, utilisé par sasl
password Le mot de passe
realm Le domaine sasl.

Chaque jeu d'accréditifs a un nom, qui fait partie d'un nom du groupe. La syntaxe générale est:
[credentials-$NAME]
credname1=value1
credname2=value2

Par exemple, pour définir 3 jeux d'accréditifs utilisé pour les machines de test, de production et de développement:
[credentials-test]
authname=fred
password=123456

[credentials-prod]
authname=bar
password=letmein

[credentials-dev]
username=joe
password=hello

Le second jeu de groupes fournis un mappage d'accréditifs à des services machine spécifiques. Les noms de groupes incluent le type de service et l'hôte:
[auth-$SERVICE-$HOSTNAME]
credentials=$CREDENTIALS

Par exemple, en suivant l'exemple précédent, on peut lister certaines machines:
[auth-libvirt-test1.example.com]
credentials=test

[auth-libvirt-test2.example.com]
credentials=test

[auth-libvirt-demo3.example.com]
credentials=test

[auth-libvirt-prod1.example.com]
credentials=prod

[auth-esx-dev1.example.com]
credentials=dev

   Les types de service suivant sont reconnus par libvirt:

libvirt Utilisé pour les connexions à un serveur libvirtd, qui est configuré avec SASL
ssh Utilisé pour les connexions à des serveur Phyp sur ssh
esx Utilisé pour les connexions à un serveur ESX ou VirtualCenter
xen Utilisé pour les connexions à un serveur Xen Enterprise en utilisant XenAPI

   Les applications utilisant libvirt sont libre d'utiliser le même fichier de configuration pour stocker d'autres accréditifs. Par exemple, il peut être utilisé pour stocker des accréditifs VNC ou SPICE.
^
20 mai 2016

htmlpdflatexmanmd




auto.master

auto.master

map maître pour l'automonteur

   La map auto.master est consulté pour définir les points d'auto-montage quand automount est lancé. Chaque ligne décris un point de montage et réfère à une map autofs décrivant les systèmes de fichier à monter sous le point de montage.

   L'emplacement par défaut est /etc/auto.master. Si le nom de la map maître n'a pas de chemin, la configuration NSS sera consultée. L'accès aux montage dans le map sont gouvernés par une clé. Pour les mappages direct, le point de montage spécifié est '/-' et la clé utilisé est le chemin comple du point de montage. La map directe peut avoir plusieurs entrée dans la map maître. L'accès aux map indirectes est faite avec '/mount-point/key' où mount-point est une des entrées listées dans la map maître. La clé est un répertoire et est matché avec les entrées dans la map donnée dans l'entrée et est matché avec les entrées dans la map donnée dans l'entrée.

Additionnellement, une map peut être incluse depuis sa source comme si elle était présente dans la map maître en incluant une ligne sous la forme:
+[maptype[,format]:]map [options]
et automount traite la map en accord avec la spécification décrite ci-dessous pour les entrées de map. Les entrées de map indirecte doivent être uniques dans la map maître pour que les entrées suivante ou sous-jacentes d'un montage indirect soient ignorés par automount.

Format

   Les entrées de map maître ont 3 champs séparés par des espaces. Le premier champs est le point de montage, et le second est le nom de la map à consulter. Le 3ème champ contient les options à appliquer à toutes les entrées dans la map.

Le format d'une entrée de map maître est:
mount-point [map-type[,format]:]map [options]
où:

mount-point Est l'emplacement de base pour monter le système. Pour les map indirectes ce répertoire sera créé et supprimé quand il est monté/démonté par autofs.
map-type Type de map utilisé pour le point de montage. Les types de map valides sont:

        file La map est un fichier texte
        program La map est un programme exécutable, qui reçoit un clé et retourne une entrée
        yp La map est une base NIS
        nisplus La map est une base NIS+
        hesiod La map est une base hesiod dont les entrées filsys sont utilisées pour les maps
        ldap ou ldaps La map est stockée dans un annuaire ldap.
        multi Permet de spécifier plusieurs map séparés par "--". Ces maps sont recherchées dans l'ordre pour résoudre les clé. Le contenu du répertoire est inclus à la map maître. Le nom du fichier à inclure doit être terminé par .autofs.

format Le format des données de map (sun, hesiod, amd). Défaut: sun
map Nom de la map à utiliser.
options Options passées à mount. Les options commençant par '-' sont passées à automount. Le format sun supporte les options suivantes:

        -Dvariable=value Substitution de variable
        -strict Traite les erreurs de montage comme fatal.
        [no]browse permet de pré-créer les répertoires de montage pour les map indirecte pour que les clé de map puissent être vu dans le répertoire sans être montés. Peut induire des problèmes de performance.
        nobind Peut être utilisé soit dans l'entrée de map maître ou dans les entrées individuelles, pour empecher les montages de systèmes NFS locaux.
        symlink Les montages utilisent un lien au lieu du montage (map indirect uniquement)
        -r, --random-multimount-selection Active l'utilisation de la sélection aléatoire en choisissant un hôte dans la liste des serveurs répliqués.
        -w, --use-weight-only Utilise seulement les poids pour la sélection de serveur, quand plus d'un serveur est spécifié dans l'entrée de map.
        -t, --timeout ‹seconds› timeout pour les entrées de map.
        -n, --negative-timeout ‹seconds› Définis le timeout pour les recherches de clé échouée en cache.

Map intégrée -hosts

   Si "-hosts" est donnée comme map, l'accès à une clé sous ce point de montage correspondant au hostname autorise l'accès aux exports de cet hôte. Les map hosts ne peuvent pas être mis à jours dynamiquement et nécessitent un signal HUP pour vérifier les mises à jours. Par exemple, avec une entrée dans la map maître "/net -hosts" accédant à /net/myserver" monte les exports de myserver dans les répertoires sous /net/myserver.

   Note: les montages fait depuis une map hôte vont être montés avec les options "nosuid,nodev,intr" sauf si définis explicitement dans l'entrée de map maître.

Maps LDAP

   Si le type de map ldap est spécifié le nom de la map est sous la forme [//servername/]dn, où servername est le nom d'un serveur ldap, et dn est le nom distinct d'une sous-arborescence de recherche. l'ancien style est également supporté (ldap:server:name:mapname). Alternativement, le type peut être obtenu depuis la configuration NSS, auquel cas le nom de la map seule doit être donnée.

   Si aucun schema n'est donné dans la configuration autofs, alors autofs vérifie chaque schéma communément utilisé pour une entrée valide et si une est trouvée elle sera utilisée pour les recherches suivantes. Il y a 3 type de schemas communément utilisé:

nisMap Les entrées dans le schéma nisMap sont des objets nisObject dans le subtree spécifié. où l'attribut cn est la clé (la clé wildcard est "/"), et l'attribut nisMapEntry contient les informations utilisées par l'auto-monteur.
automountMap Ce schémat a 2 variantes qui diffèrent dans l'attribut utilisé pour la clé de map. Les entrées dans le schéma automountMap sont des objets automount dans le subtree spécifié, où cn et automountKey est la clé, et automountInformation contient les informations utilisées par l'automounter.
amdMap Le schéma amdMap contient les attributs amdmapName, amdmapKey et amdmapValue.

Authentification LDAP, connexions chiffrées et certifiées

   Les binds ldap authentifiés avec des connexions TLS peuvent être utilisé avec les valeurs appropriés dans le fichier de configuration auofs et en configurant le client LDAP avec les paramètres appropriés. L'emplacement par défaut est /etc/autofs_ldap_auth.conf. Si ce fichier existe il est utilisé pour établir TLS et/ou l'authentification.

Exemple de configuration /etc/autofs_ldap_auth.conf
‹?xml version="1.0" ?›
‹autofs_ldap_sasl_conf
    usetls="yes"
    tlsrequired="no"
    authrequired="no"
    authtype="DIGEST-MD5"
    user="xyz"
    secret="abc"
/›

   Si le chiffrement TLS est utilisé, l'emplacement du certificat CA doit être définis dans la configuration du client LDAP. Si la connexion avec certificat est utilisé, le certificat et la clé privée doivent également être configurés dans le client LDAP.

   Dans OpenLDAP, c'est configuré dans ldap.conf, ou dans une configuration par utilisateur. Par exemple on peut utiliser la configuration système pour les certificats d'autorité, et définir le certificat client par utilisateur.

Exemples

/- auto.data
/home /etc/auto.home
/mnt yp:mnt.map

   Cela va auto-générer 2 points de montage pour /home et /mnt et installer les déclencheurs de montage direct pour chaque entrée dans la map de montage directe auto.data. Les accès à /home seront consultés dans la map auto.home, et les accès à /mnt seront consultés dans mnt.map. tous les accès aux chemins dans auto.data seront montés quand ils sont accédés et NSS sera utilisé pour localiser la source de la map auto.data
^
20 mai 2016

htmlpdflatexmanmd




autodir

autodir

Gérer les répertoires personnels

   autodir est une commande pour organiser les répertoires personnels, généralement pour les comptes utilisateur depuis une base centralisée comme ldap. Il a également une fonctionnalité de sauvegarde transparente.

OPTIONS

-d DIR Spécifie le répertoire de base; le point de montage pour le système de fichier autofs. S'il n'existe pas, il sera créé. Doit être un chemin absolu
-t SECONDS temp d'expiration pour les répertoires virtuels. S'il est inactif durant ce délai, il est démonté
-m MODULE Module à utiliser avec autodir. Doit être un chemin absolu
Ne termine pas le processus de sauvegarde, attend qu'il se termine
-N Ne termine pas le processus de sauvegarde, mais n'attend pas qu'il se termine
-o SUBOPTS Options à passer au module. ces options sont similaires aux options passées à mount avec -o
-f ne lance pas en tâche de fond et log tous les message sur la console
-l FILE Chemin complet d'un fichier dans lequel autodir écris sont pid
-v mode verbeux
-b PROG Spécifie le programme à utiliser pour les sauvegardes, ainsi que ses options. Doit être un chemin absolu.
-w SECONDS Quand un répertoire virtuel n'est pas utilisé, il est démonté, puis une sauvegarde est immédiatement démarrée. Cette option spécifie d'attendre avant de démarrer la sauvegarde. Non spécifié, démarre immédiatement.
-p NUMBER Priorité du processus de sauvegarde. Défaut: 30 (1-40)
-c NUMBER Restreint le nombre de processus de sauvegarde simultanné. Défaut: 150
^
20 mai 2016

htmlpdflatexmanmd




autofs

autofs

Format des maps d'automontage

   Les maps d'auto-montage sont FILE, NIS, NISPLUS ou LDAP référencés par la map maître auto.master. Ces maps décrivent comment les systèmes de fichiers sous le point de montage de la map sont montés. Cette documentation décris le format sun; si un autre format, autre que amd, est spécifié, cette documentation ne s'applique pas.

Format SUN

key [-options] location
key Pour les montages indirectes c'est la partie du nom de chemin entre le point de montage et le chemin dans le systèmes de fichier quand il est monté. Généralement on peut penser que la clé est un sous-répertoire sour le point de montage. Pour les montages direct, c'est le chemin complet de chaque point de montage. Cette map est toujours associée avec le point de montage /- dans la map maître.
options 0 ou plusieurs options peuvent être données. Les options peuvent également être données dans le fichier auto.master auquel cas les valeurs sont cumulées. Les options sont une liste d'options séparée par une ','.

        -fstype= utilisé pour spécifier un type de système de fichier si le système de fichier n'est pas le type NFS. Cette option est traitée par l'auto-monteur, et non par la commande mount.
        -strict Utilisé pour traiter les erreurs en montant les systèmes de fichier comme fatal, c'est important quand plusieurs systèmes de fichiers devraient être montés. Si l'option est données, aucun système de fichier n'est monté si au moins un système de fichier ne peut être monté.
        -use-weight-only Utilisé pour faire le poid du seul facteur dans le choix du serveur lorsque plusieurs serveurs sont présents dans une entrée de map.
        -no-use-weight-only Peut être utilisée pour inverser l'option si présent dans l'entrée de map maître.

   L'emplacement spécifie d'où le système de fichier est monté. Dans la plupart des cas ce sera un volume NFS et la notation courante est host:pathname. Si le système à monté commence avec un / (comme les entreés /dev ou les partages smbfs), un : doivent être préfixé (exemple: :/dev/sda1).

Exemples

Maps indirectes:
kernel -ro,soft,intr ftp.kernel.org:/pub/linux
boot -fstype=ext2 :/dev/hda1
windoze -fstype=smbfs ://windoze/c
removable -fstype=ext2 :/dev/hdd
cd -fstype=iso9660,ro :/dev/hdc
floppy -fstype=auto :/dev/fd0
server -rw,hard,intr / -ro myserver.me.org:/ /usr myserver.me.org:/usr /home myserver.me.org:/home

   Sur la première ligne, on a un montage NFS du répertoire ftp.kernel.org. C'est monté en lecture seule. La seconde ligne monte un volume ext2 depuis un volume local. La 3ème ligne créé un partage exporté depuis une machine Window$ disponible pour l'auto-montage. Le reste devrait être compréhensible. Le dernière entrée est un example d'un multi-map.

Dans un automontage sur un système de fichier sans permissions d'accès (ex: vfat), les utilisateurs ne peuvent pas écrire sur ce système de fichier parce qu'il est monté en root. On peut résoudre cela en passant l'option gid=‹gid›:
floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0

Maps directs:
/nfs/apps/mozilla bogus:/usr/local/moxill
/nfs/data/budgets tiger:/usr/local/budgets
/tst/sbin bogus:/usr/sbin

Fonctionnalités

Substitution de clé Un caractère '&' dans l'emplacement est étendu à la valeur du champ clé qui matche la ligne
Clé wildcart '*' dénote une entrée wildcard. Cette entrée est consultée si la clé spécifiée n'existe pas dans la map. Une telle entrée ressemble à: * server:/export/home/&
Substitution de variable Les variables spéciales suivantes seront substituées dans le champs emplacement d'une entrée de map si préfixé avec un $.:

        ARCH uname -m
        CPU Type de processeur
        HOST uname -n
        OSNAME uname -s
        OSREL uname -r
        OSVERS uname -v
        USER Login de l'utilisateur
        UID UID de l'utilisateur
        GROUP Nom du groupe
        GID GID du groupe
        HOME Répertoire home de l'utilisateur
        SHOST Hostname non fqdn

   Si un program map est utilisé avec ces variables d'environnement, elles seront préfixées avec "AUTOFS_" pour empêcher certains programmes comme python de charger et d'exécuter du code arbitraire depuis un répertoire utilisateur.

Maps exécutables Une map peut être marquée exécutable. Un program map est appelé avec la clé en argument. Il ne retourne rien en cas d'erreur, ou un code d'erreur, ou une ou plusieurs lignes d'une entrée de map.
Montages multiple Une map multi-mount peut être utilisée pour nommer plusieurs systèmes de fichiers à monter, sous la forme: key [ -options ] [[/] location [/relative-mount-point [ -options ] location...]....
Serveurs répliqués Un emplacement de montage peut spécifier plusieurs hôtes, potentiellement avec un chemin d'export différent pour le même système de fichier. Historiquement, cet emplacements sont lecture seul et fournissent le même système de fichier répliqué:

Plusieurs hôtes, même chemin:
‹path› host1,host2,hostn:/path/path
Plusieurs hôtes, certains avec le même chemin, d'autres noms:
‹path› host1,host2:/blah host3:/some/other/path
Plusieurs hôtes répliqués, différents chemins:
‹path› host1:/path/pathA host2:/path/pathB
Avec un poid, même chemin:
‹path› host1(5),host2(6),host3(1):/path/path
Avec un poid, chemins différents:
‹path› host1(3):/path/pathA host2(5):/path/pathB
Une variation qui fonctionne également:
‹path› host1(3),host:/blah

Format AMD

key location-list
key Chemin. peut être '*'.
location-list emplacement des points de montages (syntaxe: location[ location[ ... ]] [|| location[ location[ ... ]]). || permet de spécifier d'autres emplacements à tester si l'emplacement n'est pas disponible.

   un emplacement de montage consiste d'une liste optionnellement séparée par ':', suivi par une liste séparée par ':' de paires option:=valeur. Le sélecteur qui peut être utilisé retourne une valeur ou un booléen. Ceux qui retournent une valeur peuvent être utilisé avec les opérateurs de comparaison == et != et ceux qui retoure un résultat booléen peuvent être inversés avec !.

   Pour un emplacement soit sélectionné, tous ses sélecteurs doivent s'évaluer à true. De plus, certains sélecteurs ne prennent pas d'argument et d'autre, optionnelement 2 arguments. Les sélecteurs sans arguments sont:

        arch Architecture de la machine
        karch Architecture du kernel
        os Nom de l'os
        osver Version de l'os
        full_os nom comple de l'os
        vendor Nom du vendeur de l'os
        byte Endianness du matériel
        cluster Nom du cluster local (a une valeur qui ne peut être définis que dans la configuration)
        autodir Chemin de base où sont effectués les montages externes si nécessaire.
        domain Nom de domaine local
        host Nom de l'hôte
        hostd Nom complet de l'hôte
        UID UID de l'utilisateur
        gid GID de l'utilisateur
        key Valeur de la clé à rechercher
        map Valeur du nom de la map pour rechercher key
        path Chemin complet du montage
        dollar le caractère '$'

   Les sélecteurs qui prennent un argument sont:

        in_network(network), network(network), netnumber(network), wire(network) Ces sélecteurs sont similaires. L'argument est une adresse ou un nom de réseau. La fonction compare cet argument avec chaque interface et retourne true si le réseau appartient au réseau.
        xhost(hostname) Compare hostname à ${host} et s'il match, tente de rechercher le nom canonique de hostname et le compare à {host}.
        exists(filename) vrai si filename existe
        true() Évalue à vrai
        false() Évalue à faux

   Les sélecteurs qui prennent jusqu'à 2 arguments:

        netgrp(netgroup[,hostname]) Retourne vrai si hostname est un membre du netgroup spécifié. Si hostname n'est pas spécifié, ${host} est utilisé
        netgrpd(netgroup[,hostname]) Identique, mais le hostname fqdn est utilisé au lieu de ${host}

   Les options qui peuvent être utilisées sont:

        type Type de système de fichier à monter (auto, link, linkx, host, lofs, ext2-4, xfs, nfs, nfsl, cdfs).
        maptype Spécifie le type de source de map (file, nis, nisplus, exec, ldap, hesiod).
        fs Spécifie le système de fichier local. Dépendant du type.
        rhost L'hôte distant pour les requêtes réseau
        rfs Chemin du système de fichier de l'hôte distant
        dev Doit résoudre le système de fichier local
        sublink spécifie un sous-répertoire dans l'emplacement de montage pour laquelle cette entrée va pointer
        pref Spécifie un préfixe à ajouter à la clé de recherche avant de rechercher l'entrée de map
        opts Spécifie les options de montage à utiliser par mount. '-' pour ignorer.
        addopts Options de montage additionnels
        remopts Spécifie les options de montage au lieu de opts quand l'emplacement de montage est sur le réseau

Fonctionnalités

key Matching La clé à rechercher est construit en ajoutant le préfixe s'il y a un. Le chemin relatif résultant est matché en essayant d'abord la chaîne elle-même. S'il n'y a pas de match, le dernier composant le la clé est remplacée avec le caractère '*'. Le processus continue jusqu'à ce qu'un match soit trouvé.
Macro Usage De nombreuses valeurs d'options sont définies comme variables correspondant au nom de l'option durant la recherche d'entrée de map. Elles peuvent être utilisé dans d'autres valeurs d'option (attention à l'ordre de ces options)

Exemples

Supposont une entrée de map maître:
/test file,amd:/etc/amd.test
Et la map suivante /etc/amd.test:
/defaults type:=nfs;rhost:=bilbo
apps rfs:=/autofs
util rhost:=zeus;rfs:=/work/util
local rfs:=/shared;sublink:=local

   Dans la première ligne on a un montage distant NFS du répertoire exporté /autofs depuis l'hôte bilbo qui sera monté dans /test/apps. Un autre montage pour le répertoire exporté /work/util depuis l'hôte zeus. Il sera monté dans /test/utils.

  Finallement on a un exemple de l'utilisation de l'option sublink, où filbo:/shared sera monté dans un chemin externe au répertoire d'automontage (sous le répertoire donné par l'option auto_dir) et le chemin /test/local.
^
20 mai 2016

htmlpdflatexmanmd




autofs_ldap_auth.conf

autofs_ldap_auth.conf

Configuration ldap pour autofs

   Les binds ldap authentifiés avec des connexions TLS peuvent être utilisé avec les valeurs appropriés dans le fichier de configuration autofs et en configurant le client LDAP avec les paramètres appropriés. L'emplacement par défaut est /etc/autofs_ldap_auth.conf. Si ce fichier existe il est utilisé pour établir TLS et/ou l'authentification.

Exemple de configuration /etc/autofs_ldap_auth.conf
‹?xml version="1.0" ?›
‹autofs_ldap_sasl_conf
    usetls="yes"
    tlsrequired="no"
    authrequired="no"
    authtype="DIGEST-MD5"
    user="xyz"
    secret="abc"
/›
Exemple de configuration /etc/autofs_ldap_auth.conf
‹?xml version="1.0" ?›
‹autofs_ldap_sasl_conf
    usetls="yes"
    tlsrequired="no"
    authrequired="no"
    authtype="DIGEST-MD5"
    user="xyz"
    secret="abc"
/›

   Si le chiffrement TLS est utilisé, l'emplacement du certificat CA doit être définis dans la configuration du client LDAP. Si la connexion avec certificat est utilisé, le certificat et la clé privée doivent également être configurés dans le client LDAP.

   Ce fichier contient un simple élément XML, comme affiché dans l'exemple, avec de nombreux attributs

OPTIONS

usetls="yes"|"no" Utilise ou non tls pour les connexions
tlsrequired="yes"|"no" Impose tls pour les connexions
authrequired="yes"|"no"|"autodetect"|"simple" spécifie le mode d'authentification au serveur ldap
authtype="GSSAPI"|"LOGIN"|"PLAIN"|"ANONYMOUS"|"DIGEST-MD5|EXTERNAL" Spécifie le mécanisme d'authentification préferré. Si EXTERNAL est utilisé, 2 options sont requis: external_cert et external_key pour spécifier le certificat client et sa clé privée.
user="‹username›" Nom de l'utilisateur
secret="‹password›" Mot de passe de l'utilisateur
encoded_secret="‹base64 encoded password›" Mot de passe encodé en base64
clientprinc="‹GSSAPI client principal›" Détermine de principale pour l'authentification GSSAPI
credentialcache="‹external credential cache path›" Cache d'accréditifs pour le mécanisme GSSAPI
^
20 mai 2016

htmlpdflatexmanmd




automount

automount

Gestion des points de montage autofs

   Le programme automount est utilisé pour gérer les points de montage pour autofs. automount fonctionne en lisant la map auto.master et définis les points de montage pour chaque entrée dans le master leur permettant d'être automatiquement montés quand ils sont accédés. Les systèmes de fichier sont automatiquement démontés après une certaine période d'inactivité.

OPTIONS

-p, --pid-file Écrit de pid dans le fichier spécifié
-t ‹seconds›, --timeout ‹seconds› Définir le timeout minimum global, en secondes, avant que les répertoires soient démontés. Défaut: 10minutes. 0 désactive le démontage.
 -n ‹seconds›, --negative-timeout ‹seconds› Définis le timeout par défaut pour les recherches de clé échouée en cache. Défaut: 60secondes
-v, --verbose Active le logging des messages de status et de progression
-d, --debug Idem à -v avec les messages de debug
-Dvariable=value, --define variable=value Définis une variable de substitution globale.
-f, --foreground Ne lance pas en tâche de fond et log sur stderr au lieu de syslog
-r, --random-multimount-selection Active l'utilisation de sélection aléatoire en choisissant un hôte depuis une liste de serveurs répliqués
-m, --dumpmaps [‹map type› ‹map name›] Sans paramètres, liste les informations sur les maps configuré, puis quitte. Si une option est données, suivie par 2 paramètres, "‹map type› ‹map name›", les paires clé-valeur sont lus et affichés sur stdout. Si la map est une map ldap et qu'il y a plus d'une mappe dans différentes bases dns seule la première map rencontrée est listée.
-O, --global-options Permet la spécification d'options de montage global utilisé pour toutes les entrées de map maître. Ces options remplacent ou sont ajoutées aux options données à une entrée de map maître en fonction du paramètre APPPEND_OPTIONS
-l, --set-log-priority priority path [path,...] Définis la priorité de log du service
-C, --dont-check-daemon Ne vérifie par si le service est déjà en cours de fonctionnement
-F, --force Force le démontage d'un montage existant au démarrage.

Arguments

   automount prend un argument optionnel, le nom de la map maître

signaux

USR1 Démonte tous les systèmes de fichier gérés non-utilisé et continue ses opérations
TERM Démonte tous les systèmes de fichier gérés non-utilisés et quitte
USR2 Démonte tous les systèmes de fichier et quitte

Notes

   Si un répertoire de point de montage autofs est occupé quand le service reçoit un signal pour quitter, il ne quitte pas, sauf avec USR2. Si des automontages sont trouvés déjà montés au démarrage, il sont récupérés sauf s'il ne sont plus présents dans la map auquel cas il doivent être démontés manuellement.
^
29 mai 2017

htmlpdflatexmanmd




autrace

autrace

Programme similaire à strace

   autrace est un programme qui ajoute des règles d'audit pour tracer une processus, similairement à strace. Il exécute ainsi le programme en lui passant les arguments. Les informations d'audit résultant sont au format de log d'audit si auditd fonctionne ou syslog. Cette commande supprime toutes les règles d'audit avant d'exécuter le programme cible et après d'avoir exécuté. C'est une précaution, il ne se lance pas si les règles ne sont pas supprimées avec auditctl avant.

OPTIONS

-r Limite les appels système collectés à celles nécessaire pour l'analise d'utilisation de ressource.

Exemples

Exemple de session
autrace /bin/ls /tmp
ausearch --start recent -p 2442 -i
ou le mode d'utilisation de ressource
autrace -r /bin/ls
ausearch --start recent -p 2450 --raw | aureport --file --summary
ausearch --start recent -p 2450 --raw | aureport --host --summary
^
31 mai 2017

htmlpdflatexmanmd




auvirt

auvirt

Affiche les évènements lié aux machines virtuelles

   auvirt affiche une liste de sessions invité trouvés dans les logs d'audit. Si un invité est spécifié, seul les évènement liés à cet invité sont considérés. Pour chaque invité, il affiche un enregistrement avec le nom de domaine, l'utilisateur qui a démarré l'invité, la date à laquelle l'invité a été démarré/stoppé.

OPTIONS

--all-events Sortie plus détaillée
--debug Mode debug
-f, --file Lit les enregistrements depuis le fichier spécifié
--proof Ajoute après chaque évènement, une ligne contenant tous les identifiants des enregistrements d'audit utilisés pour calculer l'évènement. Chaque identifiant consiste du temps UNIX, millisecondes, et le numéro de série
--show-uuid Affiche l'UUID de l'invité dans chaque enregistrement
--stdin Lit les enregistrements depuis d'entrée standard
--summary AFfiche un sommaire des évènements trouvés.
-te, --end [end-date] [end-time] Recherche les évènement avant cette date/heure. mots clés permis: now, recent, today, yesterday, this-week, wwek-ago, this-month, this-year.
-ts, --start [start-date] [start-time] Affiche les évènements après cette date/heure. Les mots clé de -te sont permis.
-u, --uuid N'affiche que les évènement liés à l'invité spécifié par son uuid
-v, --vm N'affiche que les évènement liés à l'invité spécifié par son nom

Exemples

Affiche tous les enregistrements dans ce mois pour un invité
auvirt --start this-month --vm GuestVmName --all-events
^
12 janvier 2012

htmlpdflatexmanmd




awk

awk, mawk, nawk

Interpréteur de langage AWK

   awk est un interpréteur pour le langage de programmation awk. Ce langage est utile pour manipuler des fichiers de données, traitement et recherche de texte, et pour prototyper et expérimenter des algorithmes.

  Un programme awk est une séquence de paires pattern action et de définitions de fonction. Les programmes cour sont entrés sur la ligne de commande entre ' ' pour éviter une interprétation par le shell. Les programmes plus longs peuvent être lus depuis un fichier. Les données sont lues depuis une liste de fichiers sur la ligne de commande ou depuis l'entrée standard quand la liste est vide. L'entrée est scindée en enregistrements comme déterminé par la variable de séparation d'enregistrement, RS. Initialement, RS = "\n". Chaque enregistrement est comparé avec chaque motif et s'il y'a correspondance, l'action est exécutée.

OPTIONS

-F value Définis le séparateur de champ, FS
-f file Lit depuis le fichier au lieu de la ligne de commande. Peut-être spécifié plusieurs fois.
-v var=value Assigne une valeur à une variable
-- Indique la fin des options de manière non-ambiguë
mawk fournis:
-W version Version de mawk puis quitte
-W dump Écrit en listing style assembleur la représentation interne du programme sur stdout puis quitte.
-W interactive Définis les écritures sans mise en tampon sur stdout et les lignes mise en tampon lues depuis stdin. Les enregistrements depuis stdin sont lus sans regarder RS.
-W exec file Le programme est lu depuis le fichier.
-W sprintf=num Ajuste la taille du tampon sprintf de mawk au nombre d'octets spécifiés.
-W posix_space force mawk à ne pas considérer '\n' comme étant un espace.

Le langage AWK

   Un programme awk est une séquence de paires motif action et de définitions de fonctions.

        Un motif peut être
        BEGIN
        END
        expression
        expression, expression

   motif ou action peut être omis (mais pas les 2). Si action est omis, il est implicitement print. Si le motif est omis, il est simplement matché. BEGIN et END nécessitent une action.

  Les déclarations sont terminées par une nouvelle ligne, ';' ou les deux. Les groupes de déclarations tels que les actions ou les boucles sont délimité par , comme en C. La dernière déclaration dans un block ne nécessite pas de terminaison. Les lignes blanches ne signifient rien; une déclaration vide est terminée par un ';'. Les déclarations longues peuvent continuer sur une ou plusieurs lignes avec \. Une déclaration peut être scindée sans un \ après un ',', [, &&, ||, do, else, la parenthèse droite d'un if, while ou for, ou d'une définition de fonction. Un commentaire commence avec # et s'étend jusqu'à la fin de la ligne.

Les déclarations suivantes contrôlent le flux d'un programme dans les blocks:
if ( expr ) statement
if ( expr ) statement else statement
while ( expr ) statement
do statement while ( expr )
for ( opt_expr ; opt_expr ; opt_expr ) statement
for ( var in array ) statement
continue
break

Types de données, conversions et comparaisons

   Il y'a 2 types de données de bases, les chaînes et les nombres. Les constantes numériques peuvent être entier, décimal, ou en notation scientifique. Tous les nombres sont représentés en interne et tous sont calculés en virgule flottante. Donc 0.2e2 == 20 est vrai, et true vaut 1.0

  Les chaînes sont placées entre guillemets. Elles peuvent être continuées sur une nouvelle ligne en échappant newline. Les caractères échappés suivant sont reconnus:

        \\ \
        \" "
        \a alert, ascii 7
        \b backspace, ascii 8
        \t tab, ascii 9
        \n newline, ascii 10
        \v vertical tab, ascii 11
        \f formfeed, ascii 13
        \r carriage return, ascii 13
        \ddd 1, 2, ou 3 chiffre octal pour le code ascii
        \xhh 1 ou 2 chiffres hexa pour le code ascii

   Il y'a réellement 3 types de données; le troisième est de type "nombre et chaîne" qui a des données numériques et des chaînes en même temps. Les variables utilisateur, lorsqu'elles sont créées, sont initialisées à null, un nombre ou une chaîne qui vaut 0 ou "".

Le type d'une expression est déterminé par son contexte et une conversion de type se produit. Par exemple, pour évaluer:
y = x + 2 ; z = x "hello"

   y est de type numérique. Si x est une chaîne, elle est convertie en numérique avant le calcul. z sera de type chaîne, et la valeur de x sera convertie en chaîne si nécessaire et concaténé avec "hello". Une chaîne est convertie en numérique en utilisant le plus long préfixe numérique comme avec atof(3). Une expression numérique est convertie en chaîne en remplaçant expr avec sprintf(CONVFMT, expr), sauf si expr peut être représentée sur une machine comme un entier exact, alors il est convertit en sprintf("%d", expr). sprintf est embarqué dans awk et duplique la fonction fprints(3), et CONVFMT est une variable intégrée utilisée pour les conversions interne des nombres en chaîne et initialisé à "%.6g". Les conversions peuvent être forcées, expr "" est une chaîne et expr+0 est numérique.

   Pour évaluer, expr1 rel-op expr2, s'ils sont de type numérique ou un nombre et une chaine, la conversion est numérique; s'ils sont de type chaîne la comparaison est de type chaine; si un opérande est de type chaîne, l'opérande non-chaîne est converti et la comparaison est de type chaîne. Le résultat numérique est 1 ou 0.

  En booléen, tel que if ( expr ) statement, une expression chaîne est vrai si et seulement si elle n'est pas vide; une valeur numérique si et seulement si elle ne vaut pas 0.

Expressions régulières

   Dans le langage awk, les enregistrements, champs et chaînes sont souvent testés avec des expressions régulières. Elles sont délimitées par des "/"

  expr /r/

  Cette expression évalue à 1 si expr matche r, qui signifie qu'une sous-chaîne de expr est dans le jeu de chaîne définie par r.

  /r/ action et $0 /r/ action

  Sont identiques, et pour chaque enregistrement en entrée qui match r, action est exécuté. en fait, /r/ est une expression régulière awk qui est équivalent à ( $0 /r/ ).

  awk utilise des expressions régulières étendues comme avec egrep. Les méta caractères, par exemple, ceux qui ont une signification spéciale dans les expressions régulières sont: ^ $ . [ ] | ( ) * + ?

   Les expressions régulières sont construites comme suit:

        c match le non méta caractères
        \c match un caractère définis par la même séquence échappée utilisée dans les constantes chaînes ou le caractère littéral c if \c n'est pas une séquence échappée.
        . Mach n'importe quel caractère (incluant newline)
        ^ Match le début d'une chaîne
        $ Match la fin d'une chaîne
        [c1c2c3...] Match un caractère dans la classe c1c2c3... un intervalle de caractères est noté c1-c2.
        [^c1c2c3...] Match tout caractère non listé dans la classe

   Les expressions régulières sont construites depuis d'autres expressions régulières comme suit:

        r1r2 Match r1 suivi immédiatement par r2 (concaténation)
        r1 | r2 Match r1 ou r2 (alternation)
        regen Match r répété 0 ou plusieurs fois
        r+ Match r répété une ou plusieurs fois
        r? Match r 0 ou une fois
        (r) Match r, fournissant un groupage

   La précédence des opérateurs est: *, +, ?

Exemple

/^[_a-zA-Z][_a-zA-Z0-9]*$/ et /^[-+] ?([0-9]+\. ?|\.[0-9])[0-9]*([eE][-+] ?[0-9]+) ?$/
Sont matchés par les identifiants awk et les constantes numériques awk, respectivement. Noter que "." doit être échappé pour être reconnu comme point décimal, et que les méta caractères ne sont pas spéciaux dans les classes de caractères
BEGIN identifier = "[_a-zA-Z][_a-zA-Z0-9]*"
$0 "^" identifier
Affiche toutes les lignes qui commencent avec un identifier awk.
mawk reconnait l'expression régulière vide //, qui match la chaîne vide et est matché par une chaîne avant, après et entre chaque caractère. Par exemple
echo abc | mawk ' gsub(//, "X") ; print '
XaXbXcX

Enregistrement et champs

   Les enregistrements sont lus en une fois, et stockés dans la variable $0. L'enregistrement est splité en champs qui sont stockés dans $1, $2, ..., NF. La variable NF contient le nombre de champs et NR et FNR sont incrémentés de 1. Les champs derrière $NF sont mis à "".

  Assigner $0 recalcule les champs et NF. Assigner NF ou un champ reconstruit $0 en concaténant le $i séparé par OFS. Assigner un champ avec un index plus grand que NF augmente NF et reconstruit $0.

  Les données en entrée stockés dans les champs est de type chaîne, à moins que tout le champ est sous la forme numérique, le champ est alors de type chaîne et nombre. Par exemple:

echo 24 24E | mawk ' print($1 › 100, $1›"100", $2 › 100, $2›"100") '
0 1 1 1

Expressions et opérateurs

   La syntaxe est similaire au C. Les expressions primaires sont des constantes numériques, variables, champs, tableaux et des appels de fonction. L'identifiant pour une variable, tableau ou fonction peut être une séquence de lettres, chiffres et '_', qui ne commencent pas avec un chiffre. Les variables ne sont pas déclarées; elles existent quand elles sont référencées la première fois et sont initialisées à NULL.

  Les nouvelles expressions sont composées avec les opérateurs suivant par ordre de priorité croissant:

Assignement = += -= *= /= %= ^=
Conditionnel ? :
Ou logique ||
Et logique $$
Array membership in
Matching !
Relationnel ‹ › ‹= ›= == !=
Concaténation (pas d’opérateur explicite)
Ajout + -
Multiplication * / %
Unaire + -
Non logique !
Exponentiel ^
Incrément et décrément ++ —
Champ $

Tableaux

   awk fournis des tableaux à une dimension. Les éléments de tableau sont exprimé comme array[expr]. expr est convertit en interne en type chaîne, donc A[1] et A["1"] sont identique et l'index est "1". Les tableaux indexés par chaîne sont appelés des tableaux associatifs. Un tableau initialisé est vide; les éléments existent au premier accès. Une expression dans un tableau vaut 1 si array[expr] existe, sinon vaut 0.

Il y'a une forme de for qui boucle chaque index d'un tableau:
for ( var in array ) statement

   Définis var à chaque index de array et exécute statement. L'ordre dans lequel var traverse les indices n'est pas définis.

  La déclaration delete array[expr], cause array[expr] de ne pas exister. mawk supporte une extension, delete array, qui supprime tous les éléments d'un tableau.

  Les tableaux multi-dimensionnels sont synthétisés avec concaténation en utilisant la variable intégrée SUBSEP. array[expr1,expr2] est équivalent à array[expr1 SUBSEP expr2].

Tester des éléments multi-dimensionnels utilise un index en parenthèse, tel que:
if ( (i, j) in A ) print A[i, j]

Variables intégrées

   Les variables suivantes sont intégrées et initialisées avant l'exécution du programme.

ARGC Nombre d’arguments sur la ligne de commande
ARGV Tableau des arguments sur la ligne de commande, 0..ARGC-1
CONVFMT Format pour la conversion interne des nombres, chaînes, initialisé à "%.6g"
ENVIRON Tableau indexé par variable d’environnement. Une chaine d’environnement, var=value est stockée comme ENVIRON[var] = value
FILENAME nom du fichier d’entrée
FNR Nombre d’enregistrements dans FILENAME
FS Split les enregistrements dans des champs en tant qu’expression régulière
NF Nombre de champs dans l’enregistrement courant
NR Nombre d’enregistrement courant total dans le flux d’entrée
OFMT Format pour afficher les nombres; initialisé à "%.6g"
OFS Séparateur de champs en sortie, initialisé à " "
ORS Termine chaque enregistrement en sortie, initialisé à "\n"
RLENGTH Longueur définis par le dernier appel de la fonction intégrée match()
RS Séparateur d’enregistrement en entrée, initialisé à "\n"
RSTART Index définis par le dernier appel à match()
SUBSET Utilisé pour construire des tableaux multiples, initialisé à "\034"

Fonctions de chaînes intégrées

gsub(r,s,t) gsub(r,s) Substitutions globale, chaque match avec l’expression régulière r dans la variable t est remplacée par la chaîne s. Le nombre de remplacement est retourné. Si t est omis, $0 est utilisé. un & dans s est remplacé par la sous-chaîne matché de t.
index(s,t) Si t est une sous-chaine de s, la position où t comment est retournée, sinon 0.
length(s) Retourne la longueur de s
match(s,r) Retourne l’index du plus long match de r dans s. sans match, retourne 0. RSTART contient la valeur de retour, RLENGTH la longueur du match ou 61 si aucun match. si une chaîne vide match, RLENGTH vaut 0 et 1 est retourné sur le match est au début, et length(s)+1 si le match est à la fin.
split(s,A,r) split(s,A) s est splitté en champs par r et les champs sont chargés dans le tableau A. Le nombre de champs est retourné. si r est omis, FS est utilisé.
sprintf(format, expr-list) Retourne un chaîne construite depuis expr-list en accord avec format.
sub(r,s,t) sub(r,s) Simple substitution, identique à gsub except au moins une substitution.
substring(s,i) substr(s,i) Retourne le sous-chaîne de s, commençant à l’index i de longueur n. Si n est omis, le suffix de s, commençant à i est retourné.
tolower(s) retourne s en minuscule
toupper(s) retourne s en majuscule

Fonctions arithmétiques intégrées

atan2(y,x) arctan de y/y entre -pi et pi
cos(x) Cosinus, x en radian
exp(x) Fonction exponentielle
int(x) Retourne x tronqué à 0
log(x) Logarithme naturel
rand(x) Retourne un nombre aléatoire entre 0 et 1
sin(x) fonction sinus, x en radian
sqrt(x) Retourne la racine carré de x
srand(expr) srand() Générateur de nombre aléatoire, utilisant l’horloge si expr est omis, et retourne la valeur. mawk génère un nombre aléatoire depuis l’horloge au démarrage donc il n’y a pas de réel besoin de srand(). srand(expr) est utile pour répéter des séquences pseudo-aléatoires.

Entrée et Sortie

   Il y'a 2 déclarations de sortie, print et printf.

print expr1, expr2, ..., exprn Écrit $0 ORS sur la sortie standard, les expressions numériques sont converties en chaîne avec OFMT.
printf format, expr-list Duplique la fonction C printf. Toutes les spécifications sont reconnues avec les conversions %c, %d, %e, %E, %f, %g, %G, %i, %o, %s, %u, %x, %X et %%, et les qualifieur de conversion h et l.

   La liste des arguments de print et printf peuvent optionnellement être entre parenthèses. Les nombres sont affichés en utilisant OFMT ou "%u" pour les entiers exacts. %c avec un argument numérique affiche le caractère 8-bits correspondant. Avec un argument chaîne, affiche le premier caractère de la chaîne. La sortie de print et printf peuvent être redirigés avec ou ›› vers un fichier ou | vers une commande à la fin de la déclaration print. Les redirections accolées sont toujours de type flux ouvert. Par convention mawk associe le nom du fichier /dev/stderr avec stderr. mawk associe également "-" et /dev/sdtout avec stdin et stdout qui permet à ces flux d’être passés en fonctions.

  La fonction d’entrée getline a les variations suivantes:

getline Lit dans $0, met à jours les champs, NF, NR et FNR.
getline ‹ file Lit dans $0 depuis file, met à jours les champs et NF.
getline var Lit l’enregistrement suivant dans var, met à jours NR et FNR.
getline var ‹ file Lit le prochain enregistrement de file dans var
command | getline Pipe un enregistrement depuis command dans $0 et met à jours les champs et NF
command | getline var Pipe un enregistrement depuis command dans var
getline retourne 0 sur end-of-file, -1 sur erreur, sinon 1.

   La fonction close(expr) ferme le fichier ou le pipe associé avec expr. close retourne 0 si expr est un fichier ouvert ou une commande en pipe, -1 sinon. close est utilisé pour relire un fichier ou une commande.

  La fonction fflush(expr) vide le fichier de sortie ou le pipe associé avec expr. fflush retourne 0 si expr est un flux de sortie ouvert, sinon -1. fflush sans argument vide stdout. fflush avec un argument vide ("") vide toutes les sorties ouvertes.

  system(expr) utilise /bin/sh pour exécuter expr et retourner le code de sortie de la commande expr. Les changements sont fait dans le tableau ENVIRON ne sont pas passé à la commande exécutée avec system ou les pipes.

Fonctions utilisateurs

La syntaxe pour une fonction utilisateur est la suivante
function name( args ) statements
Le corps de la fonction peut contenir une déclaration de retour
return opt_expr
Une déclaration de retour n’est pas requise. Les appels de fonction peuvent être imbriqués ou récursifs. Les fonctions sont passées en expressions par valeur et les tableaux par référence. Les arguments supplémentaires servent de variables locales et sont initialisés à null. Par exemple,
csplit(s,A)
place chaque caractère de s dans le tableau A et retourne la longueur de s


function csplit(s, A, n, i)
    
    n = length(s)
    for( i = 1 ; i ‹= n ; i++ ) A[i] = substr(s, i, 1)
    return n

   Placer des espaces supplémentaires entre les arguments passés et les variables locales est conventionnel. Les fonctions peuvent être référencés avant qu’elles soient définies, mais le nom de la fonction et le ’(’ des arguments doivent se toucher pour éviter les confusions avec les concaténations.

Splittes les chaînes, enregistrements et fichiers

   awk utilise le même algorithme pour splitter les chaînes dans les tableaux avec split(), et les enregistrements dans les champs dans FS. mawk utilise essentiellement le même algorithme pour splitter les fichiers en enregistrement dans RS. split(expr,A,sep) fonctionne comme suit:

(1) si sep est omis, il est remplacé par FS. sep peut être une expressions régulière ou une expressions. Si c’est une expression de type non-chaîne, il est convertit en chaîne.
(2) si sep = " " (un simple espace), alors il est recherché du début à la fin de expr, et sep devient "". mawk définie en tant qu’expression régulière /[ \t\n]+/. Sinon sep est traité comme expression régulière, excepté que les méta-caractères sont ignorés pour les chaînes de longueur 1, par exemple, split(x, A, "µ") et split(x, A, /\*/) sont équivalents.
(3) Si expr n’est pas une chaîne, il est convertit en chaîne. si expr vaut "", split() retourne 0 et 1 est vide. Sinon, les matches de sep dans expr, sépare expr dans des champs qui sont stockés dans A et split() retourne le nombre de champs dans A.

   Splitter les enregistrements en champs fonctionne de la même manière excepté que les pièces sont chargées dans $1, $2, ..., $NF. Si $0 est vide, NF vaut 0 et tous les $i sont à "".

  mawk split les fichiers en enregistrements par le même algorithme, mais à la différence que RS est réellement un terminateur au lieu d’un séparateur.

  exemple, si FS = " :+" et $0 = "a ::b :" , alors NF = 3 et $1 = "a", $2 = "b" et $3 = "", mis si "a ::b :" est le contenu d’un fichier d’entrée et RS = " :+", alors il y’a 2 enregistrements "a" et "b".

  RS = " " n’est pas spécial

  si FS = "", mawk casse l’enregistrement en caractères individuels, et, similairement, split(s,A,"") place les caractères individuels de s dans A.

Enregistrements multi-lignes

   Vu que mawk interprète RS comme expression régulière, les enregistrements multi-ligne sont facile. Définir RS = "\n\n+", créé une ou plusieurs lignes blanches pour séparer les enregistrements. Si FS = " " (le défaut), alors un simple newline, via les règles plus haut, devient un espace et les simples newline sont des séparateurs de champs.

  Par exemple, si un fichier est "a b\nc\n\n", RS = "\n\n+" et FS = " ", alors il y’a un enregistrement "a b\nc" avec 3 champs "a", "b" et "c", changer FS = "\n", donne 2 champs "a b" et "c". Changer FS = "", donne un champ identique à l’enregistrement.

   Si vous voulez que les lignes avec des espaces ou tabulation soient considérés blanc, définir RS = "\n([ \t]*\n)+". Pour la compatibilité avec d’autres awk, définir RS = "" a le même effet que si les lignes blanches sont enlevées du début à la fin des fichiers et les enregistrements sont déterminé comme si RS = "\n\n+". Posix nécessite que "\n" sépare toujours les enregistrements quand RS = "" sans regarder la valeur de FS. mawk ne supporte pas cette convention, parce que définir "\n" n’est pas nécessaire.

  La plupart du temps quand vous changez RS pour les enregistrements multi-ligne, vous voulez également changer ORS à "\n\n" pour que l’espacement des enregistrements soit préservé en sortie.

Exécution de programme

   Cette section décrit l’ordre d’exécution des programmes. D’abord ARGC est définit au nombre total d’arguments passé sur la ligne de commande. ARGV[0] a le nom de l’interpréteur awk et ARGV[1] ... ARGV[ARGC-1] contiennent les arguments de la ligne de commande.

Par exemple avec
mawk -f prog v=1 A t=hello B
ARGC = 5
avec
ARGV[0] = "mawk", ARGV[1] = "v=1", ARGV[2] = "A", ARGV[3] = "t=hello" et ARGV[4] = "B".

   Ensuite, chaque block BEGIN est exécuté dans l’ordre. Si le programme consiste entièrement de blocks BEGINS, alors l’exécution se termine, sinon un flux d’entrée est ouvert et l’exécution continue. Si ARGC vaut 1, le flux d’entrée et mis à stdin, sinon les arguments de la ligne de commande sont examinés à la recherche d’un fichier.

   Les arguments se divisent en 3 ensembles: fichiers, arguments et chaînes vide "". Un assignement a le format var=string. Quand ARGV[1] est examiné comme un argument fichier possible, s’il est vide, il est ignoré ; si c’est un assignement, l’assignement à var est fait et i saute au suivant; sinon ARGV[i] est ouvert en entrée. S’il échoue à l’ouverture, l’exécution se termine avec le code d’erreur 2. Sans argument fichier, l’entrée devient stdin. getline dans une action BEGIN ouvre l’entrée. "-" comme argument fichier dénote stdin.

   Une fois un flux d’entrée ouvert, chaque enregistrement entrant est testé avec chaque pattern, et si çà matche, l’action associée est exécutée. Une expression mach si elle vaut true. Un BEGIN match avant qu’une entrée soit lue, et un END match après que toutes les entrées aient été lues. Une plage de motif, expr1,expr2, match chaque enregistrement entre le match de expr1 et le match de expr2, inclus.

   Quand la fin d’un fichier sur produit sur un flux d’entrée, les arguments restants sur la ligne de commande sont examinés à la recherche d’un fichier, et s’il y’en a un, il est ouvert, sinon le pattern END est considéré matché et toutes les actions END sont exécutées.

   Dans l’exemple, l’assignement v=1 prend place après que BEGIN ait été exécutée, et la donnée placée dans v est de type nombre et chaîne. L’entrée est ainsi lue depuis le fichier A. à la fin du fichier A, t est définis à "hello", et B est ouvert en entrée. À la fin du fichier B, les actions END sont exécutées. Le flux de programme au niveau pattern action peut être changé avec:

next Le prochain enregistrement en entrée est lu et le motif est testé pour redémarrer avec le premier pattern action
exit opt_expr Force l’exécution immédiate des actions END ou la fin du programme s’il n’y en a pas ou si exit se produit à la fin d’une action END. opt_expr définie la valeur de sortie.

Exemples

Émuler cat
print

Émuler wc
chars += length($0) +1
words += NF
END print NR, words, chars

Compter le nombre de mots uniques
BEGIN FS = "[^A-Za-z]+"
    for(i = 1 ; i ‹= NF ; i++) word[$i] = ""
END delete word[""]
    for ( i in word ) cnt++
    print cnt

Ajoute le second champs de tous les enregistrements basés sur le premier champ
$1 /credit|gain/ sum += $2
$1 /debit|loss/ sum -= $2

Trie un fichier, comparer les chaînes :
line[NR] = $0 ""
END isort(line, NR)
    for(i = 1 ; i ‹= NR ; i++) print line[i]
    
function isort( A, n, i, j, hold)
    for( i = 2 ; i ‹= n ; i++)
    hold = A[j = i]
    while ( A[j-1] › hold )
        j— ; A[j+1 = A[j]
    A[j] = hold

Problèmes de compatibilité

   nawk apporte ces extensions:

nouvelles fonctions: toupper() et tolower()
nouvelles variables: ENVIRON[] et CONVFMT
Spécifications de conversion ANSI C pour printf() et sprintf()
Options de ligne de commande: -v var=value, plusieurs fois -f et l’implémentation des options en tant qu’argument de -W.

   Posix AWK est orienté pour opérer sur les fichiers une ligne à la fois. RS peut être changé de "\n" à un autre caractère, mais c’est difficile de trouver une utilisation pour ça. Par convention, RS = "", créé une ou plusieurs lignes blanches séparant les enregistrements, permettant les enregistrements multi-lignes. Quand RS = "", "\n" est toujours un champ séparateur sans regarder FS.

   mawk permet à RS d’être une expression régulière. Quand "\n" apparait dans l’enregistrement, il est traité comme espace, et FS détermine toujours les champs.

Supprimer la ligne à un certain moment peut simplifier les programmes et peut souvent améliorer les performances. Par exemple, en réécrivant les 3 exemples plus haut:
BEGIN RS = "[^A-Za-z]+"
word[ $0 ] = ""
END delete word[ "" ]
    for(i in word ) cnt++
    print cnt

   Compte le nombre de mots uniques en faisant de chaque mot un enregistrement. Sur des fichiers de taille modérée, mawk s’exécute 2 fois plus vite.

Le programme suivant remplace chaque commentaire par un simple espace dans un fichier C
BEGIN
    RS = "/\*([^*]|\*+[^/*])*\*+/"
    ORS = " "
    getline hold
    
        print hold ; hold = $0
    END printf "%s" , hold

avec mawk, les déclarations suivantes sont équivalentes: x /a\+b/ x "a\+b" x "a\\+b"

   Les chaînes sont scanées 2 fois, une fois en tant que chaîne, et une fois en tant qu’expression régulière. Au premier scan, mawk ignore les caractères d’échappement alors que awk reconnait \c.

  Posix awk ne reconnait pas "/dev/stdout,err" ou la séquence hexa \x dans les chaînes. À la différence de l’ANSI C, mawk limite le nombre de chiffres qui suivent \x de 2 vu que l’implémentation actuelle supporte uniquement les caractères 8 bits.
^
11 février 2014

htmlpdflatexmanmd




badblocks

badblocks

Rechercher les blocks défectueux sur un périphérique

   badblocks est utilisé pour rechercher les blocks défectueux sur un périphérique (généralement une partition disque). Après les options vous devez spécifier le fichier de périphérique, et optionnellement le last-block et le first-block spécifiant le premier et le dernier block à vérifier. Si la sortie de badblocks sert à renseigner e2fsck ou mke2fs, il est important que la taille de block soit correctement spécifiée, vu que le nombre de block généré est dépendant de la taille de block utilisée par le système de fichiers. Pour cette raison, il est recommandé de ne pas utiliser badblocks directement, mais plutôt d'utiliser l'option -c de e2fsck et mke2fs.

OPTIONS

-b block-size Spécifie la taille des lbocks en octets. (défaut 1024)
-c nb_block Nombre de blocks à tester en même temps (défaut 64)
-e max_bad_block_count Nombre max de blocks défectueux avant d'annuler le test. (défaut 0)
-d Read_delay_factor Les blocks défectueux attendent entre les lectures si aucune erreur n'est rencontrée dans l'opération de lecture; le délai est calculé en fonction du temps que prend l'opération de lecture. ex, à 100, chaque lecture sera retardée par le même temps que la lecture a pris, à 200, le double.
-f Force l'exécution sur des périphériques qui sont montés.
-i input_file Lit une liste de blocks défectueux déjà connus et ne les tests pas.
-n  Utilise le mode lecture/écriture non destructif.
-o output-file Écrit la liste de blocks défectueux dans un fichier
-p num_passes Répète le scanne du disque jusqu'à ce qu'il n'y ai plus de blocks découverts dans le nombre de passse de scan consécutifs spécifié. A 0, quitte après la première passe (défaut: 0)
-s Affiche la progression du scan
-t test_pattern Spécifie le motif à lire et écrire sur les blocks de disque. Peut être soit une valeure numérique entre 0 et ULONG_MAX-1, ou le mot "random". pour -w et -n, un ou plusieurs motifs peuvent être spécifiés. pour le mode read-only, un seul motif peut être spécifié et ne peut pas être "random", il assume que ce motifs a déjà été écrit sur le disque. Si plusieurs motifs sont spécifiés, alors tous les blocks seront testé avec un motif avant de traiter le motif suivant.
-v mode verbeux
-w Mode écriture. scanne les blocks en écrivant des motifs (0xaa, 0x55, 0xff, 0x00) sur chaque block, et lit chaque block pour comparer le contenu.
-X Flag interne uniquement utilisé par e2fsck et mke2fs. Il bypass le mode exclusif in-use device safety check.
^
05 juin 2010

htmlpdflatexmanmd




base64

base64

base64 transforme des données en entrées sous une forme encodée en base 64. Cette forme utilise les caractères ASCII pour représenter les données binaires. L'encodage base64 étend les données d'environ 133% de l'original

OPTIONS

-w COLS, --wrap=COLS scinde les données en lignes de COLS caractères. défaut : 76 caractères.
-d, --decode Change le mode opératoire. l'entrée est supposé être en base64 et la sortie les données originales.
-i, --ignore-garbage durant le décodage, les newlines sont toujours acceptées. cette options ignore les octets non-reconnus, pour permettre à des données distordues d'être décodées.
^
07 juillet 2010

htmlpdflatexmanmd




basename

basename

Supprime la partie répertoire du nom spécifié

   Si un suffix est spécifié et est identique à la fin du nom, il est supprimé du nom. Note que les slashs sont supprimés automatique par basename. Ensemble, basename et dirname sont conçus de telle manière que si ls "$name" réussit, alors cd "$(dirname "$name")" ; ls "$(basename "$name")" réussira également.

Exemples

Affiche sort:
basename /usr/bin/sort
Affiche stdio:
basename include/stdio.h .h
^
03 juin 2014

htmlpdflatexmanmd




bash

bash

GNU Bourne-Again Shell

   Bash est un interpreteur de commande compatible sh qui exécute les commandes lues depuis l'entrée standard ou un fichier. Bash imcorpore également de nombreuses fonctionnalités des shells Korn et C. Toutes les options simple caractère documentés dans la description de la commande intégré set peuvent être utilisés comme option quand le shell est invoqué. En plus, bash interprète les options suivantes:

OPTIONS

-c string Les commandes sont lus depuis string. S'il y'a des arguments après string, ils sont assignés aux paramètres positionnels en commençant par $0
-i Mode interactif
-l Agit comme s'il avait été invoqué comme login shell
-r Mode shell restreins
-s Sans arguments après les options, les commandes sont lues depuis l'entrée standard
-D Une liste de toutes les chaînes précédés par $ est affiché sur la sortie standard. implique -n. Aucune commande n'est exécutée
[-+]O [shopt_option] shopt_option est une option accepté par la commande intégré shopt. Si présent, -O définis la valeur de cette option. +O la reset. Si shopt_option n'est pas fournis, les noms et leur valeurs acceptés par shopt sont affichés. Avec +O, la sortie est affichée dans un format qui peut être ré-utilisé en entrée.
-- Signal la fin des options et désactive le traitement des options qui suivent. Tout ce qui suit est traité comme noms de fichier et arguments.

   Bash interprète également des options multi-caractères. Ces options doivent apparaître sur la ligne de commande avant les options simple caractère pour être reconnus.

--debugger le profile debugger est exécuté avant que le shell démarre.
--dump-po-strings Équivalent à -D, mais la sortie est au format po GNU gettext
--dump-strings Équivalent à -D
--init-file file Éxecute les commandes depuis le fichier spécifié au lieu du fichier système /etc/bash.bashrc et le fichier personnel ~/.bashrc
--rcfile file Éxecute les commandes depuis le fichier spécifié au lieu du fichier système /etc/bash.bashrc et le fichier personnel ~/.bashrc
--login Équivalent à -l
--noediting N'utilise pas GNU readline pour lire les lignes de commandes quand le shell est interactif
--noprofile Ne lis ni /etc/profile, ni les fichiers d'initialisation personnel ~/.bash_profile, ~/.bash_login, ou ~/.profile.
--norc Ne lis pas le fichier d'initialisation /etc/bash.bashrc et le fichier d'initialisation personnel ~/.bashrc si le shell est interactif. (par défaut si le shell est invoqué en tant que sh)
--posix Force bash à être conforme posix
--restricted Mode restreins
--verbose Équivalent à -v

Arguments

   Si des arguments restent après le traitement des options, et ni -c ni -s ne sont présents, le premier argument est supposé être un nom de fichier contenant des commandes shell. Si bash est lancé de cette manière, $0 est définis au nom de ce fichier, et les paramètres positionnels sont définis avec les arguments restant. Bash lit et exécute les commandes de ce fichier puis se termine. Le code de sortie de Bash est le code de sortie de la dernière commande exécutée dans le script.

Invocation

   Un login shell est un shell dont le premier caractère de l'argument zéro est un -, ou lancé avec --login.

  Un shell interactif est un shell lancé sans arguments non-option et sans -c et dont l'entrée et la sortie standard sont connectés aux terminaux ( comme déterminé par isatty(3) ), ou lancé avec -i. PS1 est définis et $- inclus i si bash est interactif, permettant à un script shell ou un fichier de démarrage de tester cet état.

Fichiers de démarrage

   Si un des fichier existe mais ne peut pas être lu, Bash reporte une erreur. Quand Bash est invoqué, il lit et exécute /etc/profile s'il existe. Puis il lit et exécute ~/.bash_profile, ~/.bash_login, et ~/.profile, dans cet ordre. L'option --noprofile peut être utilisé pour empêcher ce mode. Quand un login shell existe, Bash lit et exécute ~/.bash_logout. Quand un shell qui n'est pas un login shell est lancé, bash lit et exécute les commandes depuis /etc/bash.bashrc et ~/.bashrc. Peut être inhibé avec --norc. --rcfile va forcer bash à lire et exécuter les commandes depuis le fichier spécifié au lieu de /etc/bash.bashrc et ~/.bashrc

   Quand bash est lancé non intéractivement, pour lancer un script shell, par exemple, il cherche la variable BASH_ENV, étend ses valeurs, et utilise la valeur étendue comme nom de fichier à exécuter.

Bash fonctionne comme cette commande au lancement, sauf que PATH n'est pas utilisé:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

sh

   Si bash est invoqué avec le nom sh, il tente de se comporter comme la version historique de sh et le standard POSIX. Invoqué comme login shell, il tente d'exécuter /etc/profile et ~/.profile, dans cet ordre. Peut être inhibé avec --noprofile. Invoqué comme shell interactif, il recherche la variable ENV, l'étend et l'utilise comme nom de fichier à exécuter. Invoqué avec le nom sh, il ne tente pas de lire d'autre fichiers. l'option --rcfile n'a pas d'effet. Invoqué en shell non interactif, il ne tente pas de lire d'autres fichiers. Il entre en mode POSIX une fois les fichiers de démarrage lancé.

   Quand bash est lancé en mode posix, comme avec l'option --posix, il suit le standard POSIX pour les fichiers de démarrage. Dans ce mode, les shells interactif étendent la variable ENV. Aucun fichier de démarrage n'est exécuté.

   Bash tente de déterminer quand il est lancé avec son entrée standard connecté à une connexion réseaux, comme lorsqu'il est exécuté par un service de shell distant, généralement rshd ou sshd. Si bash détermine qu'il est dans ce mode, il lit et exécute les commandes depuis ~/etc/bashrc et ~/.bashrc. Il ne le fera pas s'il est invoqué en sh. L'option --rcfile peut être utilisé pour forcer à lire un autre fichier, et --norc pour inhiber ce mode.

   Si le shell est lancé avec l'id utilisateur/group effectif différent de l'id utilisateur/group réel, et que l'option -p n'est pas fournis, aucun fichier de démarrage n'est lu, les fonctions shell d'héritent pas le l'environnement, les variables SHELLOPTS, BASHOPTS, CDPATH, et GLOBIGNORE sont ignorées, et l'id effectif est définis comme id réel. Si l'option -p est fournie, le démarrage est le même, mais l'id effectif n'est pas réinitialisé.

Définitions

   Les définitions suivantes sont utilisée dans le reste de ce document:

blank Un espace ou une tabulation
word Une séquence de caractères considérés comme une simple unité par le shell. Également connu comme un token
name Un word consistant uniquement de caractères alphanumérique et "_", et commençant avec un caractère alphabétique ou un "_". Également appelé un identifier
metacharacter Un caractère que, sans guillemets, sépare les mots. un des suivant: | & ; ( ) ‹ › space tab
control operator Un token qui exécute une fonction de contrôle. un des suivant: || & && ; ;; ( ) | |& ‹newline›

Mots Réservés

   Les mot réservés sont des mots qui ont une signification pour le shell:

  ! case do done elif else esac fi for function if in select then until while { } time [[ ]]

Commandes simple

   Une commande simple est une séquence d'assignement de variable optionnel, suivi par des mots et redirection, terminés par un opérateur de contrôle. Le premier mot spécifie la commande à exécuter, et est passé comme argument 0. Les autres mots sont passés en argument à la commande invoqué. La valeur de retour est sont code de sortie, ou 128+n si la commande est terminée par le signal n

Pipelines

Un pipeline est une séquence d'une ou plusieurs commandes séparés par un des opérateurs de contrôle | ou |&. Le format est:
[time [-p]] [ ! ] command [ [|||&] command2 ... ]

   La sortie standard de command est connectée via un pipe à l'entrée standard de command2. Cette connexion est effectuée avant toute redirection spécifiée par le commande. Si |& est utilisé, l'erreur standard de command est connectée à l'entrée standard de command2, est est un raccourci pour 2›&1 |. Cette redirection implicite de l'erreur standard est effectuée après toute redirection spécifiée par la commande. Chaque commande dans un pipeline est exécuté comme processus séparé.

   Le status de retour d'un pipeline est le status de sortie de la dernière commande, sauf si l'option pipefail est spécifiée. Si pipefail est activé, le status de retour du pipeline est la valeur commande qui se termine avec un status non-zéro, ou 0 si toutes les commandes ont réussit. Si le mot réservé ! précède un pipeline, de code de sortie de ce pipeline est la négation logique du status de sortie.

   Si time est spécifié, le temps système, utilisateur et d'exécution sont reportés quand le pipeline se termine. l'option -p change le format de sortie pour être conforme POSIX. En mode posix, le mot time n'est pas reconnus si le token suivant commence avec un -. La variable TIMEFORMAT peut être utilisé pour le format de temps. Quand le shell est en mode posix, time peut être suivi d'un newline. Dans ce cas, le shell affiche le temps total consommé par le shell et ses enfants.

Listes

   Une liste est une séquence d'un ou plusieurs pipelines, séparés par un ou plusieurs opérateurs ;, &, &&, ou ||, et optionnellement terminé par ;, &, ou ‹newline›.De cette liste d'opérateurs, && et || ont une précédence égale, suivi par ; et & qui ont une précédence égale. Une séquence d'une ou plusieurs newlines peut apparaître dans une liste au lieu de ; pour délimiter les commandes.

   Si une commande est terminée par l'opérateur de contrôle &, le shell exécute la commande dans un sous shell en tâche de fond. Le shell n'attend pas la fin de l'exécution de la commande et retourne le status 0. Les commandes séparées par ; sont exécutée séquenciellement; le shell attend que chaque commande se termine. Les listes AND et OR sont des séquences d'un ou plusieurs pipelines, séparés par les opérateurs de contrôle && et ||, respectivement.

Une liste AND a la forme:
command1 && command2
command2 est exécuté si command1 retourne un status de sortie de 0
Un liste OR a la forme:
command1 || command2
command2 est exécutée si command1 retourne un status de sortie autre que 0

Commandes composées

   Une commande composées est une des suivante:

(list) list est exécuté dans un environnement sous-shell. Les assignements de variable et le commandes intégrée qui affectent l'environnement du shell n'ont plus d'effet une fois la commande complétée.
{ list; } list est simplement exécuté dans l'environnement du shell courant. list doit être terminé avec un newline ou un point-virgule. Le status de retour est le code de sortie de list.
((expression)) L'expression est évaluée en accord avec les règles décrites dans Évaluation arithmétique. Si la valeur de l'expression est non-zéro, le status de retour et 0; sinon 1. C'est exactement équivalent à let "expression"
[[ expression ]] Retourne un status 0 ou 1 en fonction de l'évaluation de l'expression conditionnelle. Les expressions sont composées de primaires, décrites dans Expressions conditionnelles. le splitting des mots et l'expansion des path ne sont pas effectués. Utilisé avec [[, les opérateurs et trient lexicographiquement en utilisant les locales en cours.

   Quand les opérateurs == et != sont utilisés, la chaîne à la droite de l'opérateur est considéré être un motif et évalué en accord avec les règles décrites plus bas dans Pattern Matching. Si l'option shell nocasematch est présent, le match est effectué sans regarder la casse. La valeur de retour et 0 si la chaîne match (==) ou ne match pas (!=), sinon 1.

   Un opérateur additionnel est disponible: =~, avec la même précédence. Quand il est utilisé, la chaîne à la droite de l'opérateur est considéré comme expression régulière étendue. la valeur de retour est 0 si elle match, 1 sinon, ou 2 si la syntaxe de l'expression est incorrect. Si l'option nocasematch est présente, le match est insensible à la casse. Les sous-chaînes matchés par les sous-expressions sous parenthèses dans l'expression sont sauvée dans la variable tableau BASH_REMATCH.

Les expressions peuvent être combinés en utilisant les opérateurs suivant, listés dans l'ordre décroissant de précédence:
( expression ) Retourne la valeur de l'expression. Peut être utilisé pour forcer la précédence normal des opérateurs
! expression Vrai si l'expression est fausse
expression1 && expression2 Vrai si les 2 expressions sont vrai
expression1 || expression2 Vrai si une et une seul expression est vrai

   Les opérateurs && et || n'évaluent pas expression2 si la valeur de l'expression1 est suffisante pour déterminer la valeur de retour.

for name [ [ in [ word ... ] ] ; ] do list ; done La liste de mots suivant in est étendue, générant un liste d'éléments. la variable name est définis à chaque élément de cette liste, et list est exécuté chaque fois. Si in est omis, for exécute liste une fois pour chaque paramètres positionnels. Le status de retour est le code de sortie de la dernière commande exécutée. Si l'expansion de list résulte en une liste vide, aucune commande n'est exécutée et le code de sortie est 0.
for (( expr1 ; expr2 ; expr3 )) ; do list ; done expr1 est évalué. expr2 est ensuite évaluée en boucle tant qu'elle n'est pas évaluée à 0. À chaque itération de expr2, list est exécuté et expr3 est évalué. Si une des expression est manquante, elle est évaluée à 1.
select name [ in word ] ; do list ; done La liste de mots après in est étendue, générant une liste d'éléments. Le jeu étendu est affiché sur l'erreur standard, chacun précédé par un nombre. Si ces mots sont omis, les paramètres positionnels sont affichés. la prompt PS3 est ensuite affiché avec un line read de l'entrée standard. Si la ligne consiste d'un nombre correspondant à un des mots affiché, la valeur de name est définie à ce mot. Si la ligne est vide, les mots et le prompt sont ré-affichés. Si EOF est lu, la commande se termine. Toute autre valeur lue définis name à NULL. Le line read est placé dans REPLY. La liste est exécutée aprés chaque séléction jusqu'à un break
case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac Étend les mots, et tente de correspondre avec chaque pattern. Quand un match est trouvé, la list correspondante est exécutée. Si l'opérateur ;; est utilisé, aucun autre match n'est tenté aprés le premier match. Utiliser ;& à la place force à continuer les matchs.
if list; then list; [ elif list; then list; ] ... [ else list; ] fi list de if est exécuté. Si son code de sortie est 0, list de then est exécuté, sinon list de elif est exécuté, et si son code de sortie est 0, list de then est exécuté. Sinon list de else est exécuté.
while list-1; do list-2; done Exécute list-2 tant que la dernière commande de list-1 retourne un code 0.
until list-1; do list-2; done Identique à while mais le test est inversé ( tant que list-1 ne retourne pas 0)

Coprocesses

   Une commande shell précédée par coproc est exécutée de manière asynchrone dans un sous-shell, comme si elle avait été terminée par &. Le format est

  coproc [NAME] command [redirections]

  Cela créé un coprocessus nommé NAME. Si NAME n'est pas fournis, il est nommé COPROC. NAME ne doit pas être fournie pour une commande simple, sinon il est interprété comme le premier mot d'une commande simple. Quand le coprocessus est exécuté, le shell créé un tableau de variable nommé NAME dans le contexte du shell exécutant. La sortie standard de la commande est connectée via un pipe à un descripteur de fichier dans de shell exécutant, et ce descripteur est assigné à NAME[0].

   L'entrée standard de la commande est connectée via un pipe à un descripteur de fichier dans le shell exécutant, et ce descripteur est assigné à NAME[1]. Ce pipe est établis avant toute redirection spécifiée par la commande. Les descripteurs de fichier peuvent être utilisé comme arguments aux commandes shells est aux redirections en utilisant l'expansion de mots standard. Le process ID du shell est disponible comme valeur de la variable NAME_PID. La commande wait peut être utilisé pour attendre que le coprocessus se termine. Le status de retour d'un coprocess est le code de sortie de la commande.

Définitions des fonctions shell

   Une fonction shell est un objet qui est appelé comme une commande simple est exécute une commande composée avec un nouveau jeu de paramètres positionnels. Les fonctions shell sont déclarées

  name () compound-command [redirection]

  function name [()] compound-command [redirection]

   Cela définis une fonction nommé name. Le mot réservé function est optionnel. Si le mot function est spécifié, les parenthèses sont optionnels. Le corp de la fonction est la commande composée. Cette commande est généralement une listes de commandes entre { est }, mais peut être tout type de commande composé. Toute redirection spécifié quand une fonction est définie sont effectués quand la fonction est exécutée.

   Le status de sortie d'une définition de fonction est 0 sauf si une erreur de syntaxe de produit ou une fonction lecture seule avec le même nom existe déjà. Une fois exécuté, le code de sortie d'une fonction est le code de la dernière commande exécuté.

Commentaires

   Dans un shell non-interactif, ou un shell interactif dans lequel l'option interactive_comments de la commande shopt est activé, # et tout ce qui suit sur la ligne est un commentaire.

Quoting

   Le quoting est utilisé pour supprimer la signification spéciale de certains caractères ou mots. Chacun des méta-caractères listé dans Définitions a une signification spéciale pour le shell et doit être quoté pour qu'il ne soit pas être interprété par le shell. Quand les expansions d'historique de commande sont utilisées, le caractère d'expansion, généralement !, doit être quoté pour empêcher l'expansion de l'historique.

   Il y a 3 mécanismes de quoting: le caractère d'échappement, les guillemets simples, et les guillemets double.

  Le \ est le caractère d'échappement. Il préserve la valeur littérale du caractère suivant.

  Les caractères entre guillemets simples préservent la valeur littérale de chaque caractères.

  Les caractères entre guillemets double préservent la valeur littérale de tous les caractères, à l'exception de $, `, \, et, quand l'expansion d'historique est activé, !. Les caractères $ et ` conservent leur signification. Le \ conserve sa signification spéciale uniquement lorsqu'il est suivi par $, `, ", \ ou ‹newline.

   Les paramètres spéciaux * et @ ont une signification spéciale dans les guillemets double. Les mots sous la forme $'string' sont traités spécialement. L'extension de string, avec les caractères échappés remplacés comme spécifié par le standard ANSI C. Les caractères d'échappement, si présents, sont décodés comme suit:

        \a alert (bell)
        \b BACKSPACE
        \e Un caractère échappe
        \e Un caractère échappe
        \f form feed
        \n new line
        \r carriage return
        \t horizontal tab
        \v vertical tab
        \\ backslash
        \' single quote
        \" double quote
        \nnn Le caractère 8bits dont la valeur est nnn en octal
        \xHH Le caractère 8bits dont la valeur est HH en en hexadécimal
        \uHHHH Le caractère unicode (ISO/IEC 10646) dont la valeur est HHHH en hexadécimal
        \UHHHHHHHH Le caractère unicode (ISO/IEC 10646) dont la valeur est HHHHHHHH en hexadécimal
        \cx Le caractère control-x

Paramètres

   Un paramètre est une entité qui stocke une valeur. Il peut être un nom, un nombre, ou un des caractères spéciaux listés dans Paramètres Spéciaux. Une variable est un paramètre dénoté par un nom. Une variable a une valeur et 0 ou plusieurs attributs. Les attributs sont assignés en utilisant la commande declare. Un paramètre est définis si une valeur lui a été assignée. La chaîne null est une valeur valide. Une fois une valeur définie, unset permet de l'enlever.

Une variable peut être assignée par une déclaration sous la forme:
name=[value]

   Si value n'est pas donnée, la variable est assigné à la chaîne null. Toutes les valeurs sont soumises à l'expansion du tilde, expansion de paramètres et de variables, substitution de commande, expansion arithmétique, et suppression de quotes. Si la variable a son attribut integer défini, la valeur est évaluée comme expression arithmétique même si l'expansion $((...)) n'est pas utilisé. Le word splitting n'est pas effectué, à l'exception de $@. l'expansion de chemin n'est pas effectué. La déclaration d'assignement peut aussi apparaître comme argument des commandes alias, declare, typeset, export, readonly, et local.

   Dans le context de déclaration d'assignement d'une valeur à une variable shell ou un index de tableau, l'opérateur += peut être utilisé pour attacher ou ajouter à la valeur précédente. Pour une variable entière, La valeur est ajoutée. Pour une variable tableau, les nouvelles valeurs sont assigné au tableau en commençant par l'index maximum + 1 (pour les tableaux indexés), ou ajoutées en paires de clé additionnelles dans un tableau associatif.

Paramètres positionnels

   Un paramètre positionnel est un paramètre dénoté par un ou plusieurs chiffres, autre que 0. Ils sont assignés depuis les arguments du shell quand il est invoqué, et peuvent être ré-assignés en utilisant set. Les paramètres positionnels ne peuvent pas être assignés avec des déclaration d'assignement. Ils sont temporairement remplacés quand un fonction shell est exécutée. Quand un paramètre positionnel consistant de plus d'un chiffre est étendus, il doit être mis entre accolades.

Paramètres spéciaux

   Le shell traite de nombreux paramètres de manière spéciales, ces paramètres peuvent seulement être référencés, leur assignement n'est pas permis.

        Étend les paramètres positionnels, commençant à 1. Quand l'expansion se produit dans des guillemets doubles, il étend un simple mot avec la valeur de chaque paramètre séparés par le premier caractère de IFS, donc "$*" est équivalent à "$1c$2c..." où c est le premier caractère de IFS.
        @ Étend les paramètres positionnels, commençant à 1. Quand l'expansion se produit dans des guillemets doubles, Chaque paramètre est étendu à un mot séparé, donc"$@" est équivalent à "$1" "$2" .... Si l'expansion double-quoted se produit dans un mot, l'expansion du premier paramètre est join avec le début du mot original, et l'expansion du dernier paramètre est join à la fin du mot original.
        # Étend le nombre de paramètres positionnels en décimal
        ? Étend le status de sortie du pipeline le plus récemment exécuté
        - Étend les flags d'options courants comme spécifiés à l'invocation, par la commande set ou ceux définis par le shell lui-même.
        $ Étend le process ID du shell ou du script shell.
        ! Étend le process ID de la commande la plus récemment exécutée
        0 Étend le nom du shell ou du script
        _ Au démarrage du shell, définis le chemin absolu utilisé pour invoquer le shell ou le script à exécuter tel que passé dans l'environnement ou la liste d'arguments. Définis également le chemin complet de chaque commande exécutée et placé dans l'environnement exporté à cette commande. En vérifiant les mail, maintient le nom et le fichier mail actuellement vérifié.

Variables Shell

BASH Étend au nom complet utilisé pour invoquer cette instance de bash
BASHOPTS Liste valide d'options pour -s, séparés par de ",". Sont activés avant de lire les fichiers de démarrage
BASHPID Process ID du shell courant
BASH_ALIASES Une variable tableau associatif dont les membres correspondent à la liste interne d'aliase tel que maintenu par la commande alias.
BASH_ARGC Un tableau de variables dont les valeurs sont le nombre de paramètre dans chaque frame de la pile d'appel d'exécution du shell courant. Le nombre de paramètres de la sous-routine courante est en haut de la pile
BASH_ARGV Une variable tableau contenant tous les paramètres dans la pile d'appel du bash courant. Le paramètre final de l'appel de la dernière sous-routine est en haut de la pile.
BASH_CMDS Une variable tableau associatif dont les membres correspondent à la table de hash interne de commandes tel que maintenu par la commande hash.
BASH_COMMAND La commande actuellement exécutée ou à exécuter, sauf si le shell exécute une commande commme résultat d'un trap, dans ce cas c'est la commande exécutée au moment du trap.
BASH_EXECUTION_STRING L'argument de commande pour l'option d'invocation -c
BASH_LINENO Un tableau dont les membres sont les numéros de ligne dans les fichiers sources pour chaque membre de FUNCNAME invoqué. ${BASH_LINENO[$i]} est le numéro de ligne dans le fichier source (${BASH_SOURCE[$i+1]} où ${FUNCNAME[$i]} a été appelé (ou ${BASH_LINENO[$i-1]} si référencé dans une autre fonction.
BASH_REMATCH tableau dont les membres sont assignés par l'opérateur binaire =~ à la commande [[. variable read-only
BASH_SOURCE Tableau dont les membres sont les noms de fichier source où les nom de fonction shell correspondant dans le tableau FUNCNAME sont définis. La fonction shell ${FUNCNAME[$i]} est définis dans le fichier ${BASH_SOURCE[$i]} et appelée depuis ${BASH_SOURCE[$i+1]}
BASH_SUBSHELL Incrémenté de 1 chaque fois qu'un sous-shell ou un environnement sous-shell est généré.
BASH_VERSINFO Variable read-only dont les membres maintiennent les informations de version de cette instance de bash. les valeurs assignées sont les suivantes

        BASH_VERSINFO[0] Numéro de version majeur
        BASH_VERSINFO[1] Numéro de version mineur
        BASH_VERSINFO[2] Niveau de patch
        BASH_VERSINFO[3] Version de build
        BASH_VERSINFO[4] Status de la release
        BASH_VERSINFO[5] La valeur de MACHTYPE

BASH_VERSION Étend la chaîne décrivant la version de cette instance de bash
COMP_CWORD Un index dans ${COMP_WORDS} du mot contenant la position courante du curseur. disponible uniquement dans les fonctions shell invoqués par les completion programmables
COMP_KEY La touche (ou la touche final d'un séquence de touche) utilisé pour invoquer la fonction de completion courante.
COMP_LINE Ligne de commande courante. Disponible seulement dans les fonctions shell et les commandes externes invoqués par la completion programmable.
COMP_POINT l'index de la position du curseur courant relative au début de la commande courante. Si la position courante est à la fin de la commande courante, la valeur est égale à ${#COMP_LINE}. Disponible seulement dans les fonctions shell et les commandes externes invoqués par la completion programmable.
COMP_TYPE Définis une valeur entière correspondant au type de completion tenté qui a causé la fonction de completion à être appelée: TAB, pour une completion normale, ? pour une completion de listing après des tabs successifs, ! pour des listing alternatifs sur des completion de mot partiels, @ pour des completions de liste si le mot n'est pas modifié, ou % pour une completion de menu. Disponible seulement dans les fonctions shell et les commandes externes invoqués par la completion programmable.
COMP_WORDBREAKS Le jeu de caractères que readline traite comme séparateur de mots en effectuant la completion de mot.
COMP_WORDS Un tableau consistant de mots individuels dans la ligne de commande courante. La ligne est splité en mots comme le fait readline, en utilisant COMP_WORDBREAKS Disponible seulement dans les fonctions shell et les commandes externes invoqués par la completion programmable.
COPROC Tableau créé pour maintenir les descripteurs de fichier pour les sorties et entrée des co-processus non nommés.
DIRSTACK Un tableau contenant le contenu courant de la pile de répertoire. Les répertoires apparaissent dans la pile dans l'ordre qu'ils sont affichés par la commande dirs. pushd et popd doivent être utilisés pour ajouter ou supprimer des répertoires.
EUID Étend l'ID utilisateur effectif de l'utilisateur courant, initialisé au démarrage du shell. variable read-only
FUNCNAME Tableau contenant les noms de toutes les fonctions shell actuellement dans la pile d'appel d'exécution. L'élément d'index 0 est le nom de la fonction actuellement exécutée, l'élément d'index le plus élevé est la fonction main. Cette variable peut être utilisée avec BASH_LINENO et BASH_SOURCE. Chaque élément de FUNCNAME a des éléments correspondant dans ces 2 variables pour décrire la pile. ${FUNCNAME[$i]} a été appelé depuis le fichier ${BASH_SOURCE[$i+1]} à la ligne numéro ${BASH_LINENO[$i]}. La commande caller affiche la pile d'appel courante utilisant cette information.
GROUPS Un tableau contenant la liste de groupes dont l'utilisateur est membre.
HISTCMD Le numéro d'historique, ou index dans la liste d'historique, de la commande courante
HOSTNAME Définis automatiquement au nom de l'hôte courant
HOSTTYPE Définis automatiquement à une chaîne que décris de manière unique le type de machine sur lequel bash est exécuté.
LINENO Chaque fois que ce paramètre est référencé, le shell substitue un nombre décimal représentant le numéro de ligne séquentiel courant dans un script ou fonction. Quand ce n'est pas un script ou une fonction, la valeur substituée n'a pas de signification garantie.
MACHTYPE Définis automatiquement à une chaîne qui décris de type de système sur lequel bash est exécuté dans de format GNU standard.
MAPFILE Un tableau créé pour maintenir le texte lu par la fonction mapfile quand aucun nom de variable n'est fournis
OLDPWD Le répertoire de travail précédent
OPTARG La valeur du dernier argument traité par la commande getopts
OPTIND d'index du prochain argument à traiter par la commande getopts
OSTYPE Définis automatiquement à une chaîne qui décris le système d'exploitation sur lequel bash est exécuté
PIPESTATUS Un tableau contenant une liste de status de sortie des processus dans le pipeline le plus récemment exécuté
PPID Le process ID du shell parent. read-only
PWD Le répertoire de travail courant, définis par cd
RANDOM Chaque fois que ce paramètre est référencé, un entier entre 0 et 32767 est généré. La séquence de nombres aléatoire peut être initialisée en assignant une valeur à RANDOM.
READLINE_LINE Le contenu du tampon de ligne de readline, à utiliser avec bind -x
READLINE_POINT La position du point d'insertion dans le tampon de ligne de readline, à utiliser avec bind -x
REPLY Définis à la ligne de l'entrée lus par la commande read quand aucun argument n'est fournis
SECONDS Chaque fois que ce paramètre est référencé, le nombre de secondes depuis l'invocation du shell est retourné. Si une valeur est assigné à SECONDS, retourne le nombre de seconde depuis l'assignement plus la valeur assigné.
SHELLOPTS Une liste séparée par des virgules d'options du shell. Chaque mot dans la liste est un argument valide pour l'option -o de la commande set. Cette variable est lu avant tout fichier de démarrage.
SHLVL Incrémenté de 1 chaque fois qu'une instance de bash est lancée
UID Étend l'ID utilisateur, initialisé au démarrage du shell, read-only

   Les variables suivantes sont utilisés par le shell, Dans certain cas, bash assigne une valeur par défaut.

BASH_ENV Si ce paramètre est définis quand bash exécute un script, sa valeur est interprété comme nom de fichier contenant des commandes pour initialiser le shell, comme dans ~/.bashrc. Sa valeur est sujet à l'expansion de paramètre, substitution de commande et expansion arithmétique avant d'être interprété comme nom de fichier. PATH n'est pas utilisé pour rechercher le fichier
BASH_XTRACEFD Si définis à un entier correspondant à un descripteur de fichier valide, bash écrit les donnée générées par set -x dans ce descripteur de fichier. Ce descripteur est fermé quand BASH_XTRACEFD est ré-initialisé ou assigné à une autre valeur.
CDPATH Le chemin de recherche pour la commande cd. Liste séparé par des virgules de répertoires dans lequel le shell recherche les répertoires de destination spécifiés par la commande cd. ex ".:~:/usr"
COLUMNS Utilisé par select pour déterminer la largeur du terminal en affichant la liste de sélection. Automatiquement définis à la réception de SIGWINCH
COMPREPLY Un tableau dans lequel bash lis les completions possibles générées par un fonction shell invoqué par la completion programmable.
EMACS Si bash trouve cette variable au démarrage et qu'elle commence par "t", il assume que le shell fonctionne comme un shell Emacs et désactive l'édition de ligne.
ENV Similaire à BASH_ENV, utilisé quand le shell est invoqué en mode posix
FCEDIT L'éditeur par défaut pour la commande fc
FIGNORE Une liste séparée par des virgules de suffixes à ignorer lors des completion de nom de fichier. ex: ".o:~"
FUNCNEST Si définis à une valeur numérique supérieur à 0, définis le niveau maximum de niveau imbriqué.
GLOBIGNORE Une liste séparée par des virgules de patterns définissant le jeu de noms de fichier à ignorer par l'expansion de nom de fichier.
HISTCONTROL Une liste séparée par des virgules de valeur contrôlant la manière dont les commandes sont sauvées dans la liste d'historique. Si HISTCONTROL n'est pas définis ou n'inclus pas de valeur valide, toutes les lignes sont sauvegardées dans l'historique, sujet à HISTIGNORE. Les lignes d'une commande composée multi-ligne excepté la première ne sont pas testées et sont ajoutés dans l'historique sans regarder la valeur de HISTCONTROL. La liste peut inclure les mots clé suivant:

        ignorespace les lignes commençant par un espace ne sont pas sauvés.
        ignoredups ne sauve pas les lignes qui matche en entrée précédente dans l'historique.
        ignoreboth raccourci pour ignorespace et ignoredups
        erasedups supprime toutes les précédente lignes matchant la ligne courant avant de sauver la ligne.

HISTFILE Nom du fichier dans lequel l'historique des commandes est sauvegardé. Défaut: ~/.bash_history. Si non définis, l'historique n'est pas sauvegardé.
HISTFILESIZE Nombre maximum de lignes contenus dans le fichier d'historique.
HISTIGNORE Liste de patterns utilisés pour décider quelles lignes de commandes devraient être sauvés dans l'historique. Chaque pattern doit matcher la ligne complète. & match la ligne précédente dans l'historique. Les lignes d'une commande composée multi-ligne excepté la première ne sont pas testées
HISTSIZE Nombre de commandes à mémoriser dans l'historique de commandes. Défaut: 500
HISTTIMEFORMAT Utilisée pour formater les timestamp via strftime(3) dans le fichier d'historique.
HOME Le répertoire home de l'utilisateur courant. argument par défaut de la commande cd
HOSTFILE Contient le nom d'un fichier dans le même format que /etc/hosts qui devrait être utilisé quand le shell doit compléter un nom d'hôte. La liste peut être changé pendant l'exécution du shell. Si non définis, utilise /etc/hosts.
IFS Internal Field Separator utilisé pour séparer les mots après l'expansion et pour séparer les lignes en mots avec la commande read. Défaut: "‹space›‹tab›‹newline›"
IGNOREEOF Contrôle l'action d'un shell interactif à la réception du caractère EOF. Si définis, la valeur est le nombre de caractères EOF consécutifs qui doivent être tapés avant que bash se termine. Défaut: 10 si la variable est définis mais vide. Si elle n'existe pas, EOF signifie la fin de l'entrée du shell.
INPUTRC Nom du fichier de démarrage pour readline. Défaut: ~/.inputrc
LANG Utilisé pour déterminer la catégorie de la locale
LC_ALL Remplace LANG et tout autre variable LC_ spécifiant une catégorie de locale
LC_COLLATE Détermine l'ordre de classement utilisé lors du trie des résultat de l'expansion de nom de fichier, et détermine la méthode de plage d'expression, d'équivalence de classe, et de classement de séquences dans l'expansion de nom de fichier et de recherche de pattern.
LC_CTYPE Détermine l'interprétation des caractères et le mode de classes de caractères dans l'expansion de chemin et de pattern matching
LC_MESSAGES Détermine la locale utilisée pour traduire les chaînes entre guillemets double précédés par un $
LC_NUMERIC Détermine la locale utilisée pour formatter les nombres
LINES Utilisé par select pour déterminer la longueur de colonne pour afficher la liste de sélection. Définis automatiquement à la réception d'un SIGWINCH
MAIL Si définis à un fichier ou un répertoire et que MAILPATH n'est pas définis, bash informe l'utilisateur de l'arrivée de mails dans fichier/répertoire spécifié.
MAILCHECK Spécifie la fréquence en secondes que bash vérifis les mails. le message peut être spécifié en séparane le nom du fichier du message par un "?". quand utilisé dans le texte du message $_ étend au nom du fichier. (ex: MAILPATH='/var/mail/bfox?"You have mail":~/shell-mail?"$_ has mail!"')
OPTERR À 1, bash affiche les messages d'erreur générés par la commande getopts. OPTERR est initialisé à 1 à chaque fois que le shell est invoqué ou qu'un script shell est exécuté
PATH Les chemins de recherche pour les commandes
POSIXLY_CORRECT Si cette variable est dans l'environnement lorsque bash démarre, le shell entre en mode posix avant de lire les fichiers de démarrage.
PROMPT_COMMAND Si définis, la valeur est exécutée comme commande avant de fournir chaque prompt primaire.
PROMPT_DIRTRIM Si définis à un nombre supérieur à 0, la valeur est utilisée comme nombre de composants de répertoire à conserver en étendant la chaîne \w et \W.
PS1 La valeur de ce paramètre est étendu et utilisé comme prompt primaire. Défaut: \s-\v\$
PS2 La valeur de ce paramètre est étendu et utilisé comme prompt secondaire. Défaut:
PS3 La valeur de ce paramètre est étendu et utilisé comme prompt pour la commande select
PS4 La valeur de ce paramètre est étendu et utilisé comme PS1 et la valeur est affichée avant chaque commande que bash affiche en mode trace. Le premier caractère est répliqué plusieurs fois si nécessaire, pour indiquer plusieurs niveaux d'indirection. Défaut: +
SHELL Le chemin complet du shell est conserver dans cette variable.
TIMEFORMAT La valeur de ce paramètre est utilisé pour spécifier comment les information de temps pour les pipe, préfixeés avec le mot réservé time sont affichés. Défaut: $'\nreal\t%3lR\nuser\t%3lU\nsys%3lS'. % introduit une séquence échappée.

        %% un % littéral
        %[p][l]R Le temps passé en secondes
        %[p][l]U Le nombres de secondes CPU passé en mode utilisateur
        %[p][l]S Le nombres de secondes CPU passé en mode système
        %P Le pourcentage de CPU, calculé avec (%U + %S) / %R

           p spécifie la précision (de 0 à 3). l spécifie un format plus long sous la forme MMmSS.FFs

TMOUT Si définis à une valeur supérieure à 0, est traité comme timeout par défaut pour les commandes read et select. Dans un shell interactif, la valeur est interprétée comme nombre de secondes à attendre une entrée après avoir fournis le prompt primaire.
TMPDIR Spécifie un répertoire dans lequel bash créé les fichiers temporaires
auto_resume Contrôle comment le shell interagis avec l'utilisateur et le contrôle de job. Si la valeur est définis, une commande simple mot sans redirection est traitée comme candidat à la reprise d'un job stoppé. Il n'y a pas ambiguïté permise, si plus d'un job commence avec la chaîne tapée, le job le plus récent est sélectionné. Le nom d'un job, dans ce contexte, est la ligne de commande utilisée pour la lancer. Si définis à exact, la chaîne fournie doit matcher exactement le nom d'un job stoppé. Si définis à substring, la valeur fournie est analogue à %?. Si définis à une autre valeur, la chaîne fournie doit être préfixeé par le nom d'un job stoppé, analogue à %string.
histchars Les 2 ou 3 caractères qui contrôlent l'expansion d'historique et la tokenisation. Le premier caractère est le caractère l'expansion d'historique (généralement !). Le second est le caractère quick substitution, qui est utilisé comme raccourci pour relancer la commande précédente (généralement ^). Le 3ème caractère, optionnel, est le caractère qui indique que le reste de la ligne est un commentaire quand il est trouvé comme premier caractère d'un mot, généralement #. Il permet à la substitution d'historique de sauter les mots restants sur la ligne.

tableaux

   bash fournis des variable tableaux indexés et associatifs à une dimension. Toute variable peut être utilisée comme un tableau indexé; la commande declare déclare implicitement un tableau. Il n'y a pas de limite sur la taille d'un tableau, ni ne requière que ses membres soient indexés ou assignés en continus. Les tableaux indexés sont référencés en utilisant des entiers (incluant des expressions mathématiques). Les tableaux associatifs sont référencés en utilisant des chaînes arbitraires.

   Un tableau indexé est crée automatiquement si une variable est assignée en utilisant la syntaxe name[subscript]=value. subscript est traité comme expression arithmétique que doit évaluer un nombre. si subscript évalue un nombre inférieur à 0, il est utilisé comme offset depuis le plus grand élément du tableau (ex: -1 réfère au dernier élément du tableau).

   les tableaux indexé peuvent être créés implicitement avec declare -a, les tableaux associatifs avec declare -A. Les attributs peuvent être spécifiés en utilisant declare et readonly. Chaque attribut s'applique à tout le tableau.

   Les tableaux sont assignés en utilisant les assignements composés sous la forme name=(value1 ... valuen), où chaque valeur est sous la forme [subscript]=string. En assignant un tableau associatif, le subscript est requis. La syntaxe est accepté par la commande declare. Les éléments individuels peuvent être assignés avec name[subscript]=value

   Tout élément dans un tableau peut être référencé en utilisant ${name[subscript]}. Si subscript est @ ou *, le mot s'étend à tous les membres de name. Ces subscripts diffèrent seulement quand le mot apparaît entre guillemets double. Si le mot est entre guillemets double, ${name[*]} étend à un simple mot avec la valeur de chaque membre du tableau, et ${name[@]} étend chaque élément de name à un mot séparé. ${#name[subscript]} étend à la longueur de ${name[subscript]}. Si subscript est * ou @, l'expansion est le nombre d'éléments dans le tableau. Référence un tableau sans subscript est équivalent à référencer le tableau avec un subscript de 0.

   Un tableau est considéré définis si un subscript à été assigné. Une chaîne null est une valeur valide. unset permet de détruire un tableau. unset name[subscript] détruit l'élément du tableau. Les commandes declare, local, et readonly acceptent chacun l'option -a pour spécifier un tableau indexé, et -A pour spécifier un tableau associatif. read acceptent -a pour assigner une liste de mots lus depuis l'entrée standard dans un tableau. set et declare affichent les valeurs de tableau de manière à ce qu'ils puissent être réutilisés comme assignement.

Expansion

   L'expansion est effectuée sur la ligne de commande après qu'elle ait été splitté en mots. Il y a 7 types d'expansion: expansion d'accolades, expansion de tilde, expansion de paramètre et de variable, La substitution de commande, l'expansion arithmétique, le word splitting, et l'expansion de nom de chemin, dans l'ordre d'expansion. Sur les systèmes qui le supporte, il y a une expansion supplémentaire: la substitution de processus.

   Seul l'expansion d'accolades, le word splitting et l'expansion de nom de chemin peuvent changer le nombre de mots de l'expansion; les autres étendent un simple mot en un simple mot. Les seuls exceptions sont les expansions de $@ et ${name[@]}.

Expansion d'accolades

   L'expansion l'accolades est un mécanisme par lequel des chaînes arbitraires peuvent être générées. Il est similaire à l'expansion de chemin, mais les noms de fichiers n'ont pas besoin d'exister. Les motifs à étendre prennent la forme d'un préambule optionnel, suivi par soit une série de chaînes séparées par de virgules, soit une séquence d'expressions entre une paire d'accolades, suivi par un postscript optionnel. Le préambule est préfixeé à chaque chaîne, est le postscript est ajouté à chaque chaîne résultante.

   Les expansions d'accolades peuvent être imbriquées. Le résultat de chaque chaîne étendue n'est pas trié; l'ordre de gauche à droite est préservé. Par exemple, a{d,c,b}e s'étend à 'ade ace abe. Une séquence d'expression prend la forme {x..y[..incr]}, où x et y sont soit des entiers soit un simple caractère, et incr, un incrément optionnel, un entier. Quand des entiers sont fournis, l'expression étend à chaque nombre entre x et y, inclusif. Les entiers fournis peuvent être préfixeés avec des 0 pour forcer chaque terme à avoir la même largeur. Quand des caractères sont fournis, l'expression étend à chaque caractère lexicographiquement entre x et y, inclusif. x et y doivent être de même type. Quand l'incrément est fournis, il est utilsié comme différence entre chaque terme. l'incrément par défaut est 1 ou -1.

   l'expansion d'accolades est effectuée avant tout autre expansion, et tout caractère spécial pour d'autres expansions sont préservés dans le résultat. bash n'applique aucune interprétation syntaxique au contexte de l'expansion ou au texte entre les accolades.

mkdir /usr/local/src/bash/{old,new,dist,bugs}
chown root /usr/{ucb/{ex,edit},lib/{ex?.?*,how_ex}}

Expansion de tilde

   Si un mot commence avec un tilde non quoté, tous les caractères précédant le premier "/" non quotés ( ou tous les caractères, s'il n'y a aucun / non quoté ) sont considérés comme préfixe de tilde. Si aucun des caractères dans le préfixe de tilde ne sont quotés, les caractères dans le préfixe de tilde suivant le tilde sont traités comme un nom de login. Si le nom de login est une chaîne null, le tilde est remplacé avec la valeur du paramètre HOME. Si HOME n'est pas définis, le répertoire de l'utilisateur courant est utilisé. Sinon, le préfixe de tilde est remplacé avec le home associé avec le nom de login spécifié.

   Si le préfixe de tilde est ~+, La valeur de PWD remplace le préfixe de tilde. Si le préfixe de tilde est ~-, la valeur de OLDPWD, si définis, est substitué. Si le caractère suivant le tilde dans le préfixe de tilde consiste d'un nombre N, optionnellement préfixeé par un + ou un -, le préfixe est remplacé avec l'élément correspondant depuis la pile de répertoire, comme si c'était affiché par dirs invoqué avec le préfixe de tilde comme argument. Si les caractères suivant le tilde dans le préfixe de tilde consiste d'un nombre sans commencer par un + ou -, + est assumé.

   Si le nom de login est invalide, ou l'expansion de tildes échoue, de mot est inchangé. Chaque assignement de variable est vérifié pour des préfixe de tilde suivant immédiatement un : ou le premier =. Dans ce cas, l'expansion de tilde est aussi effectué. En conséquence, on peut utiliser des noms de fichiers avec des tildes en assignement à PATH, MAILPATH, et CDPATH, et le shell assigne la valeur étendue.

Expansion de paramètres

   Le caractère $ introduit l'expansion de paramètre, la substitution de commande, ou l'expansion arithmétique. le nom de paramètre ou symbole à étendre peut être entre accolades, qui sont optionnels mais servent à protéger la variable de l'extension depuis le caractère immédiatement après, qui peuvent être une partie du nom.

${parameter} La valeur de parameter est substitué. Les accolades sont requises quand parameter est un paramètre positionnel avec plus d'un chiffre, ou quand il est suivi par un caractère qui ne doit pas être interprété comme partie de son nom.

   Si le premier caractère de parameter est un !, un niveau d'indirection de variable est introduit. bash utilise la valeur de la variable formée depuis le reste de parameter comme nom de variable. Cette variable est ensuite étendue et cette valeur est utilisée dans le reste de la substitution au lieu de la valeur de parameter elle-même. C'est l'expansion d'indirection. Les exceptions sont les expansions de ${!prefix*} et ${!name[@]}.

   Dans chacun de ces cas, word est sujet à l'expansion du tilde, l'expansion de paramètre, la substitution de commande et l'expansion arithmétique.

${parameter:-word} Si parameter est non définis ou null, l'expansion de word est substitué. Sinon, la valeur de parameter est substitué
${parameter:=word} Si parameter est non définis ou null, l'expansion de word est assigné à parameter. la valeur de parameter est ensuite substitué. les paramètres positionnels et paramètres spéciaux ne peuvent pas être assignés de cette manière.
${parameter:?word} Si parameter est non définis ou null, l'expansion de word ( ou un message à cet effet si word n'est pas présent) est affiché sur stderr et le shell, s'il n'est pas interactif, quitte. Sinon, la valeur de parameter est substitué.
${parameter:+word} Si parameter est non définis ou null, rien n'est substitué, sinon l'expansion de word est substitué.
${parameter:offset}
${parameter:offset:length} Étend jusqu'à length caractères de parameter, en commençant au caractère spécifié par offset. Si length est omis, étend à la sous-chaîne de paramètre en commençant au caractère spécifié par offset. length et offset sont des expressions arithmétique. Si offset évalue à un nombre inférieur à 0, la valeur est utilisée comme offset depuis la fin de la valeur de paramètre. Les expressions arithmétique commenfant avec un - doivent être séparés par un espace blanc du précédent.

   Si length évalue à un nombre inférieur à 0, et parameter n'est pas @ ni un tableau, il est interprété comme offset depuis la fin de la valeur de parameter. Si parameter est un nom de tableau indexé, le résultat sont les length membres du tableau commençant avec ${parameter[offset]}. Si offset est 0 et que les paramètres positionnels sont utilisés, $0 est préfixé à la liste.

${!prefix*}
${!prefix@} Étends aux noms de variables dont les noms commencent avec prefix, séparés par le premier caractère de IFS. Quand @ est utilisé et que l'expansion apparaît dans des guillemets doubles, chaque nom de variable s'étends à un mot séparé.
${!name[@]}
${!name[*]} Si name est un tableau, étends à la liste d'indices assignés dans name. Si name n'est pas un tableau, étends à 0 si name est définis et null sinon. Quand @ est utilisé et que l'expansion apparaît dans des guillemets doubles, chaque indice d'étends à un mot séparé
${#parameter} Subsitute à la longueur en caractères de la valeur de parameter. Si parameter est * ou @, la valeur substitué est le nombre de paramètres positionnel. Si parameter est un tableau, la valeur substitué est le nombres d'éléments dans le tableau
${parameter#word}
${parameter##word} word est étendu pour produire un pattern comme dans une expansion de pathname. Is le pattern match le début de la valeur de parameter, le résultat est la valeur de parameter raccourci du pattern matchant le plus court ( # ), ou le plus long ( ## ). Si parameter est @ ou * , l'opération de suppression est appliqué à chaque paramètre positionnel, et l'expansion est la liste résultante. Si parameter est un tableau, l'opération est appliquée à chaque membre du tableau.
${parameter%word}
${parameter%%word} L'expansion est identique mais l'opération de suppression de pattern se produit en partant de la fin de parameter.
${parameter/pattern/string} pattern est étendu pour produire un un pattern comme dans l'expansion de pathname. parameter est étendu et le plus grand match de pattern est remplacé avec string. Si pattern commence avec /, tous les matches de pattern sont remplacés avec string. Normalement, seul le premier match est remplacé. Si pattern commence avec #, il doit matcher au début de la valeur étendu de paramètre, et à la fin si pattern commence avec %. Si string est null, les matchs sont supprimés. Si parameter est @ ou * , l'opération de substitution est appliquée à chaque paramètre positionnel. Si parameter est un tableau, la substitution est appliquée à chaque membre.
${parameter^pattern}
${parameter^^pattern}
${parameter,pattern}
${parameter,,pattern} Cette expansion modifie la casse des caractères alphabétique dans parameter. ^ convertis en majuscule le premier pattern qui match ( ^^ tous les patterns qui matchent), , convertis en minuscule.

Substitution de commande

   La substitution de commande permet à la sortie d'un commande de remplace de nom de commande. Il y a 2 forme

$(command)
`command`

   Bash effectue l'expansion en exécutant command et en remplaçant la substitution avec la sortie standard de la commande. La substitution de commande $(cat file) peut être remplacé par l'équivalent plus rapide $(‹ file). Quand l'ancien style ` est utilisé, le backslash garde sa signification litérale excepté quand il est suivi par $, ` ou \. Le premier ` non précédé par un \ termine la substitution de commande. En utilisant la forme $(command), tous les caractères entre les parenthèses font la commande, aucun n'est traité spécialement.

   Les substitutions de commande peuvent être imbriqués. Pour imbriquer en utilisant la forme ``, échapper les ` à l'intérieur avec des \. Si la substitution de commande apparaît dans des guillemets doubles, le word splitting et l'expansion de pathname ne sont pas effectués.

Expansion arithmétique

   L'expansion arithmétique permet l'évaluation d'une expression arithmétique et la substitution du résultat. Le format est:

        $((expression))

   L'expression est traitée comme si elle était entre guillemets double, mais un guillemet double dans les parenthèses ne sont pas traités spécialement. tous les tokens dans l'expression subissent l'expansion de paramètre, l'expansion de chaîne, la substitution de commande, et la suppression de quote. Les expressions arithmétique peuvent être imbriqués. L'évaluation est effectué en accord avec les règles listé dans Évaluation arithmétique.

Substitution de processus

   La substitution est supportée sur les systèmes qui supportent les pipes nommés (FIFO) ou la méthode de fichiers /dev/fd. Elle prend la forme ‹(list) ou ›(list). list avec sa sortie ou sa sortie connecté à un FIFO. Le nom de ce fichier est passé en argument à la commande courante en résultat de l'expansion. En utilisant ›(list), écrire dans le fichier fourni une entrée pour list. En utilisant ›(list), le fichier passé en argument devrait être lu pour obtenir la sortie de list. Quand disponible, la substitution est effectué simultanément avec l'expansion de paramètre et de variable, la substitution de commande et l'expansion arithmétique.

Découpage de mots

   Le shell traite chaque caractère de IFS comme délimiteur, et découpe le résultat d'autre expansions en mots. Si IFS n'est pas définis, sa valeur est exactement ‹space›‹tab›‹newline›, et les séquences ‹space›, ‹tab› et ‹newline› au début et à la fin du résultat de l'expansion précédente sont ignorés, et toute autre séquence de caractère de IFS sert à délimiter les mots. Si IFS a une valeur autre que son défaut, alors les séquences space et tab sont ignorés au début et à la fin du mot, tant que le caractère whitespace est dans la valeur d'IFS. Tout caractère dans IFS qui n'est pas un whitespace, délimite un champ. Une séquence de whitspace d'IFS est aussi traité comme un délimiteur. Si la valeur d'IFS est null, aucun découpage ne se produit.

   Les arguments null explicites "" et '' sont retenus. Les arguments null implicite non quotés, résultant de l'expansion de paramètre qui n'a pas de valeur, sont supprimés. Si un paramètre sans valeur est étendu dans des guillemets double, il en résulte un argument null et est retenus. Noter que si aucune expansion ne se produit, aucun découpage n'est effectué.

Expansion de chemin

   Après le word splitting, à moins que l'option -f n'ait été définis, bash scanne chaque mot pour le caractère *, ?, et [. Si un de ces caractères apparaît, alors de mot est lu comme pattern, et remplacé avec une liste triée alphabétiquement de nom de fichiers correspondant au pattern. Si aucun nom de fichier matchant n'est trouvé et que l'option nullgrob n'est pas activé, le mot reste inchangé. Si nullglob est définis, et qu'aucun match n'est trouvé, le mot est supprimé. Si l'option shell failglob est définis et qu'aucun matche n'est trouvé, un message d'erreur est affiché et la commande n'est pas exécutée. Si l'option nocaseglob est activée, le match est effectué sans regarder la casse des caractères.

   Noter qu'en utilisant des expression de plage comme [a-z], les lettres de l'autre casse peuvent être incluent en fonction de LC_COLLATE. Quand un pattern est utilisé pour l'expansion de pathname, le caractère . au début d'un nom ou suivant immédiatement un / doit être matché explicitement sauf si l'option dotglob est définis. En matchant un pathname, le / doit toujours être matché explicitement. Dans les autres cas, . n'est pas traité spécialement.

   La variable GLOBIGNORE peut être utilisé pour restreindre le jeu de noms de fichier matchant un pattern. Si elle est définie, chaque nom de fichier matchant qui match également les patterns dans GLOBIGNORE sont supprimés de la liste des matchs. GLOBIGNORE définis à une valeur null active l'option dotglob, donc tous les noms de fichiers commençant par . vont matcher. pour ignorer les noms de fichier commençant par un ., créer un pattern .* dans GLOBIGNORE, l'option dotglob est désactivé quand GLOBIGNORE est définis.

Motifs de correspondance

   Tout caractère que apparaît dans un pattern, autre que les caractères de pattern spéciaux, se matche lui-même. Le caractère NUL ne peut pas exister dans un pattern. Un '\' échappe les caractère suivant. Les caractères de pattern doivent être quotés s'ils doivent matcher littéralement. Les caractères de pattern spéciaux ont la signification suivante:

Match toutes chaîne, incluant une chaîne null. Quand l'option globstar est activée, et que * est utilisé dans l'expansion de pathname, 2 * adjacent utilisés dans un simple pattern vont matcher tous les fichiers et ou plusieurs répertoire et sous-répertoires. Si suivi par un /, 2 * adjacents vont matcher uniquement les répertoires et sous-répertoires.
? Matche un simple caractère.
[...] Matche un des caractères entre les crochets. Une paire de caractères séparés par un "-" dénote une plage; tous caractères qui se trouvent entre ces 2 caractères sont matchés. Si le premier caractère après [ est un ! ou un ^ alors tous caractères qui n'est pas dans les crochets matchent. L'ordre de trie des caractères dans une plage est déterminé par la locale courant et la valeur de LC_COLLATE, si définis. Un - peut être matché en l'incluant comme premier ou dernier caractère dans les crochets. Un ] peut être matché en l'incluant comme premier caractère.

        - Dans [ et ], les classes de caractères peuvent être spécifiés en utilisant la syntaxe [:class:], où class peut être alnum alpha ascii blank cntrl digit graph lower print punct space upper word xdigit
        - Dans [ et ], une équivalence de classe peut être spécifiée en utilisant la syntaxe [=c=], qui matche tous les caractères de la même classe que le caractère c.
        - Dans [ et ], la syntaxe [.symbol.] matche la même classe de symbole.

   Si extglob est activé, de nombreux opérateurs de correspondance de pattern étendus sont reconnus. Dans les descriptions suivante, pattern-list est une liste d'un ou plusieurs pattern séparés par un |. Les patterns composites peuvent être formés en utilisant un ou plusieurs sous-pattern:

?(pattern-list) Matche 0 ou une occurence des patterns donnés
*(pattern-list) Matche 0 ou plusieurs occurences des patterns donnés
+(pattern-list) Matche 1 ou plusieurs occurences des patterns donnés
@(pattern-list) Matche 1 des patterns donnés
!(pattern-list) Matche tout sauf un des patterns donnés

Suppression de quote

   Après les précédentes expansions, toutes les occurences non-quotés des caractères \, ' et " qui ne résultent pas d'une des précédentes expansions sont supprimés.

Redirection

   Avant qu'une commande soit exécutée, son entrée et sa sortie peuvent être redirigées en utilisant une notation interprétée par le shell. La redirection peut être également utilisée pour ouvrir et fermer des fichiers pour l'environnement d'exécution du shell courant. Les redirections sont traitées dans l'ordre qu'elles apparaissent.

   Chaque redirection qui peut être précédée par un descripteur de fichier peut, à la place, être précédée par un mot sous la forme {varname}. Dans ce cas, pour chaque opérateur de redirection excepté ›&- et ‹&-, le shell va allouer un descripteur de fichier supérieur à 10 et l'assigner à varname. Si ›&- ou ‹&- est précédé par {varname}, la valeur de varname définis le descripteur de fichier à fermer.

   Dans les descriptions suivantes, si le descripteur de fichier est omis, et que le premier caractère de l'opérateur de redirection est , la redirection réfère à l'entrée standard (descripteur de fichier 0). Si le premier caractère de l'opérateur de redirection est , la redirection réfère à la sortie standard (descripteur de fichier 1).

   Le mot suivant l'opérateur de redirection dans les descriptions suivante, sauf mention, est sujet à l'expansion d'accolades, de tilde, et de word splitting. S'il s'étend à plus d'un mot, bash reporte une erreur. Noter que l'ordre des redirections est significatif.

        par exemple, la commande
        ls › dirlist 2›&1
        Dirige la sortie standard et l'erreur standard vers le fichier dirlist, alors que la commande
        ls 2›&1 › dirlist
        dirige seulement la sortie standard vers de ficher dirlist, parce que l'erreur standard a été dupliquée depuis la sortie standard avant que la sortie standard ai été redirigée vers dirlist.

   bash gère de nombreux noms de fichiers spécialement quand ils sont utilisés dans les redirections:

        /dev/fd/fd Si fd est un entier valide, le descripteur fd set dupliqué
        /dev/stdin Le descripteur de fichier 0 est dupliqué
        /dev/stdout Le descripteur de fichier 1 est dupliqué
        /dev/stderr Le descripteur de fichier 2 est dupliqué
        /dev/tcp/host/port Si host est un nom d'hôte valide ou une adresse internet, et port est un numéro de port ou un nom de service, bash tente d'ouvrir une connexion TCP sur le socket correspondant.
        /dev/udp/host/port Si host est un nom d'hôte valide ou une adresse internet, et port est un numéro de port ou un nom de service, bash tente d'ouvrir une connexion UDP sur le socket correspondant.

   Une impossibilité d'ouvrir ou créer un fichier échoue la redirection. Les redirections utilisant les descripteurs de fichier supérieur à 9 devraient être utilisés avec précaution vu qu'ils peuvent être en conflit avec les descripteur de fichiers que le shell utilise en interne. Noter que la commande exec peut créer des redirections qui prennent effet dans le shell courant.

Redirection d'entrée

   La redirection d'entrée ouvre le fichier résultant de word en lecture sur le descripteur de fichier n, ou l'entrée standard si non spécifié. Le format général est:

[n]‹word

Redirection de sortie

   La redirection de sortie ouvre le fichier résultant de word en écriture sur le descripteur de fichier n, ou la sortie standard si non spécifié. Si le fichier n'existe pas il est créé; s'il existe ta taille est tronqué à 0. Le format général est:

[n]›word

   Si l'opérateur de redirection est , et l'option noclobber est définie, la redirection échoue si le fichier dont le nom résulte de l'expansion de word existe et est un fichier régulier. Si l'opérateur de redirection est ›|, ou et l'option noclobber n'est pas activé, la redirection est tentée même si le fichier nommé par word existe.

Ajouter à la sortie redirigée

   La redirection de la sortie de cette manière ouvre le fichier résultant de l'expansion de word à être ouvert sur le descripteur de fichier n pour ajout. Si le fichier n'existe pas il est créé. Le format général est:

[n]››word

Rediriger Stdout et Stderr

   Cette constuction permet à la sortie standard et l'erreur standard d'être redirigés vers de fichier dont le nom est l'expansion de word. Il y a 2 formes:

&›word
et
›&word
Des 2 formes, la première est préféré. C'est équivant à
›word 2›&1

Ajouter Stdout et Stderr

   Cette construction permet à la sortie standard est l'erreur standard d'être ajoutés au fichier dont le nom est l'expansion de word.

&››word
C'est équivalent à
››word 2›&1

Here Documents

   Ce type de redirection instruit de shell de lire l'entrée depuis la source courante jusqu'à ce qu'une ligne contenant seulement delimiter ( sans espace blanc après ) soit vu. Toutes les lignes lues jusqu'à ce point sont utilisés comme entrée standard pour une commande.

‹‹[-]word
here-document
delimiter

   Aucune expansion de paramètre, substitution de commande, expansion arithmétique, expansion de chemin n'est effectué dans word. Si des caractères dans word sont quotés, le delimiter est le résultat de la suppression des quote dans word et les lignes dans le here-document ne sont pas étendues. Si word est non quoté, toutes les ligne du here-document sont sujet à l'expansion de paramètre, substitution de commande et expansion arithmétique. Dans ce dernier cas, la séquence \‹newline› est ignorée, et \ doit être utilisé pour quoter les caractères \, $ et `. Si l'opérateur de redirection est ‹‹-, tous les caractères de tabulation en début de ligne sont supprimés.

Here String

   Une variante de here-document. word est étendu et fournis à la commande sur son entrée standard. le format est:

‹‹‹word

Dupliquer les descripteurs de fichier

   L'opérateur de redirection

  [n]‹&word

  est utilisé pour dupliquer les descripteurs de fichier d'entrée. Si word s'étend à un ou plusieurs chiffres, le descripteur de fichier dénoté par n devient une copie de ce descripteur de fichier. Si word évalue à -, le descripteur n est fermé. Si n n'est pas spécifié, l'entrée standard est utilisée.

   [n]›&word

  est utilisé pour dupliquer les descripteurs de fichier de sortie. Si n n'est pas spécifié, la sortie standard est utilisée. Un cas spécial, si n est omis, et word ne s'étend pas à un ou plusieurs chiffres, l'entrée standard et l'erreur standard sont redirigés comme décris précédemment.

Déplacer les descripteurs de fichier

   L'opérateur de redirection

  [n]‹&digit-

  déplace le descripteur de fichier digit au descripteur de fichier n, ou l'entrée standard si n n'est pas spécifié. digit est fermé après avoir été dupliqué à n. Similairement, l'opérateur de redirection

  [n]›&digit-

  déplace le descripteur de fichier digit au descripteur de fichier n, ou la sortie standard si n n'est pas spécifié.

Ouvrir des descripteurs de fichier en lecture-écriture

   L'opérateur de redirection

  [n]‹›word

  ouvre le fichier en lecture et écriture sur le descripteur de fichier n ou le descripteur de fichier 0 si n n'est pas spécifié. Si le fichier n'existe pas, il est créé.

Alias

   Les alias permettent à une chaîne d'être substituée pour un mot quand il est utilisé comme premier mot d'une simple commande. Le shell maintient une liste d'alias qui peuvent être définis et supprimés avec les commande alias et unalias. Le premier mot de chaque commande simple, si non quoté, est vérifié pour voir si elle a un alias. Si c'est le cas, ce mot est remplacé par le texte de l'alias. Les caractères /, $, `, et = et tout autre métacaractère shell ou caractère de quote ne doivent pas apparaître dans un nom d'alias.

   Le texte de remplacement peut contenir une entrée shell valide, incluant des métacaractères. Le premier mot du remplacement est testé pour un alias, mais un mot qui est identique à un alias qui est étendu n'est pas étendu une seconde fois. Cela signifie que l'on peut créer un alias ls à ls -F. Si le dernier caractère de la valeur de l'alias est un blanc, alors le prochain mot suivant l'alias est aussi vérifié pour l'expansion de l'alias.

   Il n'y a pas de mécanisme pour utiliser des arguments dans le texte de remplacement. Si les arguments sont nécessaires, une fonction shell devrait être utilisée. Les alias ne sont pas étendus quand le shell n'est pas interactif, sauf si l'option expand_aliases est définis.

   Bash lit toujours au moins une ligne complète d'entrée avant d'exécuter les commandes sur la ligne. Les alias sont étendus quand une commande est lue, pas quand elle est exécutée, Cependant, une définition d'alias apparaissant sur la même ligne qu'une autre commande ne prend effet qu'à la ligne suivante, Le problème est similaire avec les fonctions.

Fonctions

   Une fonction shell stocke une série de commande pour une exécution ultérieur. Quand le nom d'une fonction est utilisé comme nom de commande simple, la liste des commandes associée avec cette fonction est exécutée. Les fonctions sont exécutées dans le contexte du shell courant; aucun nouveau processus n'est créé pour les interpréter. Quand une fonction est exécutée, les arguments de cette fonction deviennent les paramètres positionnels durant son exécution. Le paramètre spécial # est mis à jour pour refléter ce changement et 0 est inchangé. Le premier élément de FUNCNAME est définis au nom de la fonction durant son exécution.

   Tous les autres aspects de l'environnement d'exécution du shell sont identiques entre une fonction et son appelant à l'exception des traps DEBUG et RETURN qui ne sont pas hérités sauf si la fonction a été donnée par l'attribut trace ou l'option -o functrace est activée. Le trap ERR n'est pas hérité sauf si -o errtrace est activé.

- Les variables locales aux fonctions peuvent être déclarées avec la commande local. Généralement, les variables et leur valeurs sont partagées entre la fonction et son appelant.
- La variable FUNCNEST, si définie à une valeur numérique supérieur à 0, définis le niveau d'imbrication de fonction maximum. Les invocations de fonction qui excèdent cette limite sont annulées.
- Si la commande return est exécutée dans une fonction, la fonction se termine et retourne à l'appelant. Toute commande associée avant le trap RETURN est exécutée avant que l'exécution se termine. Quand une fonction se termine, les valeurs des paramètres positionels et le paramètre spécial # sont restaurés aux valeurs qu'ils avaient avant l'exécution de la fonction.
- Les fonctions peuvent être récursives, La variable FUNCNEST peut être utilisée pour limiter la profondeur d'appel et restreindre le nombre d'invocation.

   Les noms et définitions de fonction peuvent être listés avec l'option -f des commandes declare ou typeset. L'option -F de declare ou typeset va lister les noms de fonction uniquement (et optionnellement le fichier source et le numéro de ligne, si extdebug est activé). Les fonctions peuvent être exportées pour que les sous-shells les aient automatiquement definies avec l'option -f de la commande export. Une définition de fonction peut être supprimée avec unset -f. Noter que les fonctions shell et le variables de même nom peuvent résulter en plusieurs entrées nommées identiquement dans l'environnement passé aux enfants du shell, cela peut poser problème.

Évaluation Arithmétique

   Le shell permet d'évaluer des expressions arithmétiques, sous certaines circonstances. L'évaluation est faite avec des entiers à largeur fixe sans vérification de débordement. Les opérateurs et leur précédence, l'associativité et les valeurs sont les même que dans le langage C. La liste suivant d'opérateurs est groupé en niveaux de précédence équivalant. Les niveaux sont listés dans l'ordre décroissant de précédence.

id++ id-- post-incrément et post-décrément de variable
++id --id pré-incrément pré-décrément de variable
- + moins et plus unaire
! ~ négation logique et au niveau des bits
**  Exponentialité
* / % multiplication, division et reste
+ - addition et soustraction
‹‹ ›› décalages de bit
‹= ›= ‹ › Comparaison
== != égalité et inégalité
& ET bit à bit
^ OU exclusif bit à bit
| OU bit à bit
&& AND logique
|| OU logique
expr?expr:expr opérateur conditionnel
= *= /= %= += -= ‹‹= ››= &= ^= |= assignements
expr1 , expr2 virgule

   Les variables shell sont des opérandes permises; l'expansion de paramètre est effectué avant que l'expression soit évalué. Dans l'expression, les variables shell peuvent aussi être référencées par mon sans utiliser la syntaxe d'expansion de paramètre. Une variable shell qui est null ou indéfinie évalue à 0 quand elle référencée par nom sans utiliser la syntaxe d'expansion de paramètre. La valeur d'une variable est évaluée comme expression arithmétique quand elle est référencée, ou quand une variable a l'attribut entier. Une valeur null évalue à 0. Une variable shell n'a pas besoin de l'attribut entier pour être utilisé dans une expression

   Les constantes commençant avec un 0 sont interprétées en octal, en celles commençant avec 0x ou 0X sont interprétés en héxadécimal. Sinon, les nombres prennent la forme [base#]n, où base est entre 2 et 64 et représente la base arithmétique, et n est un nombre de cette base. Si base est omis, utilise de système décimal. En spécifiant n, les chiffres supérieur à 9 sont représenté par les lettres minuscule, les lettres majuscules, @, et _, dans cet ordre. Si base est inférieur ou égal à 36, les lettres minuscules et majuscule peuvent être inter-changés. Les opérateurs sont évalués dans l'ordre de précédence. Les sous-expressions entre parenthèses sont évalués en premier et peuvent écraser les règles de précédence.

Expressions conditionnelles

   Les expressions conditionnelles sont utilisée par la commande composée [[ et les commandes test et [ pour tester les attributs de fichier et effectuer des comparaisons arithmétique et de chaîne. Les expressions sont formées depuis les primaires unaire ou binaire suivantes. Si un argument file d'un des primaires est de forme /dev/fd/n, le descripteur de fichier n est vérifié. Sauf mention, les primaires qui opèrent sur les fichiers suivent les liens symbolique. Quand utilisé avec [[, les opérateurs et trient lexicographiquement en utilisant la locale courante. La commande test trie en utilisant l'ordonnancement ASCII.

-a file Vrai si file existe
-b file Vrai si file existe et est un fichier spécial block
-c file Vrai si file existe et est un fichier spécial caractère
-d FILE vrai si FILE existe et est un répertoire
-e file Vrai si file existe
-f FILE vrai si FILE existe et est un fichier régulier
-g file Vrai si file existe et est set-groud-id
-h file Vrai si file existe et est un lien symbolique
-k file Vrai si file existe et son sticky bit est mis
-p file Vrai si file existe et est un pipe nommé
-r file Vrai si file existe et est accéssible en lecture
-s FILE vrai si FILE existe et a une taille supérieur à 0
-t fd Vrai si le descripteur de fichier est ouvert et réfère à un terminal
-u file Vrai si file existe et son set-user-id est mis
-w file Vrai si file existe et est accéssible en écriture
-x file Vrai si file existe et est exécutable
-G file Vrai si file existe et est possédé par l'id de groupe effectif
-L file Vrai si file existe et est un lien symbolique
-N file Vrai si file existe et a été modifié depuis le dernier accès en lecture
-O file Vrai si file existe et est possédé par l'id utilisateur effectif
-S FILE vrai si FILE existe et est un socket
file1 -ef file2 Vrai si file1 et file2 réfèrent au même numéro de device et inode
file1 -nt file2 Vrai si file1 est plus récent que file2, ou si file1 existe et non file2
file1 -ot file2 Vrai si file1 est plus ancien que file2, ou si file2 exist en non file1
-o optname Vrai si l'option shell est activée.
-v varname Vrai si la variable shell est définie
-R varname Vrai si la variable shell est définie et est une référence nommée
-Z STRING vrai si la longueur de STRING est 0
string
-n string Vrai si la longueur de string est différente de 0
string1 == string2
string1 = string2 Vrai si les chaînes sont identiques. = devrait être utilisé avec test.
string1 != string2 Vrai si les chaînes ne sont pas identiques
string1 ‹ string2 Vrai si string1 se trie avant string2 lexicographiquement
string1 › string2 Vrai di string1 se trie après string2 lexicographiquement
arg1 OP arg2 OP vaut: -eq, -ne, -lt, -le, -gt, ou -ge. Ces opérateurs arithmétique retournent vrai si arg1 est égal à, non égal à, inférieur à, inférieur ou égal à, supérieur à, supérieur ou égal à arg2, respectivement.

Expansion de commande simple

   Quand une commande simple est exécutée, le shell effectue les expansions, assignements et redirections suivantes, de gauche à droite:

        1. Les mots que le parser a marqué comme assignement de variable (ceux précédant le nom de commande) et des redirections sont sauvés pour traitement ultérieur.
        2. Les mots qui ne sont pas des assignement de variable ou des redirections sont étendus. Si des mots restent après l'expansion, le premier mot est pris comme nom de commande et les mots restants sont les arguments.
        3. Les redirections sont effectuées
        4. Le texte après le = dans chaque assignement de variable subit d'expansion de tilde, expansion de paramètres, substitution de commande, expansion arithmétique, et suppression de quote avant l'être assigné à la variable.

   S'il ne résulte aucun nom de commande, les assignements de variable affectent le shell courant. Sinon, les variables sont ajoutés à l'environnement de la commande exécutée et n'affecte pas l'environnement du shell courant.

  S'il ne résulte aucun nom de commande, les redirections sont effectuées, mais n'affectent pas l'environnement du shell courant.

Exécution de commande

   Une fois une commande découpée en mots, s'il en résulte en une simple commande et une liste optionnelle d'arguments, les actions suivantes sont effectuées.

   Si le nom de la commande ne contient pas de /, le shell tente de la localiser. S'il existe une fonction shell de ce nom, elle est invoquée. Sinon, si le nom correspond à une commande intégrée, elle est invoquée.

   Si le nom n'est ni une fonction ni un commande intégrée et ne contient pas de /, bash recherche chaque élément de PATH à la recherche d'un fichier exécutable de ce nom. Bash utilise une table de hash pour mémoriser les chemins complet des fichiers exécutable. Une recherche complète des répertoires n'est effectuée que si la commande n'est pas trouvée dans la table. Si la recherche ne donne aucun résultat, le shell recherche une fonction shell définie nommée command_not_found_handle. Si elle existe, elle est invoquée avec la commande original et ses arguments en argument, et le code de sortie de la fonction devient le code de sortie du shell. Si cette fonction n'est pas définie, le shell affiche une erreur et retourne un code de sortie de 127.

   Si la recherche a réussie, ou si le nom de commande contient un ou plusieurs /, le shell exécute le programme nommé dans un environnement séparé. L'argument 0 est le nom donnée.


   Si le programme est un fichier commençant avec #!, le reste de la première ligne spécifie un interpréteur de commande. Le shell exécute l'interpéteur spécifié.

Environnement d'exécution de commande

   Le shell a un environnement d'exécution, qui consiste en:

- Les fichier ouverts hérités par le shell à l'invocation, comme modifié par les redirections fournies à la commande exec
- Le répertoire de travail courant comme définis par cd, pushd ou popd
- Le masque de mode de création des fichiers comme définis par umask ou hérité du shell parent
- Les traps courant définis par trap
- Les paramètres shell qui sont définis par l'assignement de variable ou avec set ou hérités du shell parent
- Les fonctions shell définies durant l'exécution ou hérités du shell parent
- Les options activées à l'invocation ou définis pas set
- les options activée avec shopt
- les alias définis avec alia
- Divers process ID, incluant ceux des tâche de fond, la valeur de $$, et de PPID

   Quand une commande simple autre qu'un commande intégrée ou une fonction shell est exécutée, elle est invoquée dans un environnement d'exécution séparé qui consiste en:

- Les fichier ouverts du shell, plus toute modification et ajout spécifié par les redirections à la commande
- Le répertoire de travail courant
- Le masque de mode de création de fichier
- Les variables et fonctions shell marqué pour l'export, et les variables exportés pour la commande, passés dans l'environnement
- Les traps capturés par le shell sont réinitialisés aux valeurs hérités du shell parent, et les traps ignorés par le shell sont ignorés.

   Une commande invoquée dans un environnement séparés ne peut pas affecter l'environnement d'exécution du shell. La substitution de commande, les commandes groupées avec des parenthèses et les commande asynchrone sont invoquées dans un sous-shell qui est dupliqué depuis l'environnement du shell, excepté que les traps capturés par le shell sont réinitialisés aux valeur que le shell a hérité de son parent à l'invocation. Les commande intégrées qui sont invoquées comme partie d'un pipeline sont aussi exécutés dans un sous-shell. Les changements fait au sous-shell ne peuvent pas affecter l'environnement d'exécution du shell.

   Les sous-shell générés pour exécuter des substitutions de commande héritent de la valeur de l'option -e du shell parent. Quand il n'est pas en mode posix, bash efface l'option -e dans de tels sous-shell. Si une commande est suivie par un & et que le contrôle de job n'est pas actif, l'entrée standard par défaut pour la commande est /dev/null. Sinon, la commande hérite des descripteurs de fichier du shell appelant comme modifié par les redirections.

Environnement

   Quand un programme est invoqué il lui est donné un tableau de chaînes appelé l'environnement. C'est une liste de paire nom=valeur. Le shell fournis de nombreuses manières de manipuler l'environnement. À l'invocation, le shell scanne son propre environnement et créé un paramètre pour chaque nom trouvé, en le marquant automatiquement pour export à ses processus enfant. Les commandes exécutées héritent de l'environnement. Les commandes export et declare -x permettent d'ajouter et de supprimer des fonctions et des variables à l'environnement.L'environnement pour une commande simple ou une fonction peut être augmentée temporairement en la préfixant avec des assignements de paramètre. Ces assignements affectent uniquement l'environnement vu par la commande.

   Si l'option -k est définie, tous les assignements de paramètre sont placés dans l'environnement pour une commande, pas seulement ceux qui précèdent le nom de la commande. Quand bash invoque une commande externe, la variable _ est définie au fichier de la commande et passée à cette commande dans son environnement.

Codes de sortie

   Le statut de sortie d'une commande exécutée est la valeur retournée par l'appel système waitpid ou une fonction équivalente. Les statuts de sortie vont de 0 à 255, bien que le shell utilise les valeurs supérieur à 125 de manière spéciales. Les statuts de sortie des commandes intégrées et des commandes composées sont également limitées à cette plage. Dans certaines circonstances, le shell va utiliser des valeur spéciales pour indiquer des modes d'échec spécifiques.

   Une commande qui se termine avec un code de sortie de 0 à réussie. Un autre code indique une erreur. Quand une commande se termine sur un signal fatal N, bash utilise la valeur de 128+N comme code de sortie. Si une commande n'est pas trouvée, le processus enfant créé pour l'exécuter retourne un statut de 127. Si une commande est trouvée mais n'est pas exécutable, le code de retour est 126. Si une commande échoue à cause d'une erreur durant l'expansion ou la redirection, de code de sortie est supérieur à 0. Les commandes intégrées retournent 0 si elles réussissent. Toutes les commandes intégrées retournent 2 pour indiquer une utilisation incorrect. Bash lui-même retourne le code de sortie de la dernière commande exécutée, sauf si une erreur de syntaxe se produit, dans ce cas il se termine avec un code non-zéro.

Signaux

   Quand bash est interactif, en l'absence de traps, il ignore SIGTERM, et SIGINT est géré (donc wait est intérruptible). Dans tous les cas, bash ignore SIGQUIT. Si de contrôle de job est effectif, bash ignore SIGTTIN, SIGTTOU, et SIGTSTP.

   Les commandes non-intégrées lancées par bash ont des gestionnaires de signaux définis aux valeurs hérités par le shell de son parent. Quand le contrôle de job est effectif, les commandes asynchrone ignorent SIGINT et SIGQUIT en plus des handlers hérités. Les commandes lancées en résultat d'une substitution de commande ignorent les signaux de contrôle générés au clavier SIGTTIN, SIGTTOU, et SIGTSTP.

   Le shell quitte par défaut une fois reçu un SIGHUP. Avant de quitter, un shell interactif envoie SIGHUP a tous les jobs en cours ou stoppés. Les jobs stoppés reçoivent SIGCONT pour s'assurer qu'ils reçoivent bien SIGHUP. Pour empêcher le shell d'envoyer le signal à un job particulier, il doit être supprimé de la table des jobs avec disown ou marqué pour ne pas recevoir SIGHUP en utilisant disown -h.

   Si l'option huponexit a été mis avec shopt, bash envoie un SIGHUP à tous les jobs quand un login shell interactif se termine. Si bash attend qu'une commande se termine et reçoit un signal pour lequel un trap est définis, le trap ne l'exécutera pas tant que la commande ne s'est pas terminé. Quand bash attend une commande asynchrone via wait, la réception d'un signal pour lequel un trap a été définis va forcer wait à retourner immédiatement avec un code de sortie supérieur à 128, immédiatement après que de trap ait été exécuté.

Contrôle de job

   Le contrôle de job réfère à la capacité à sélectivement stopper (suspendre) l'exécution de processus et le continuer leur exécution ultérieurement. Le shell associe un job avec chaque pipeline. Il conserve une table de jobs actuellement exécutés, qui peut être listé avec jobs. Quand bash lance un job asynchrone (en tâche de fond), il affiche un ligne qui ressemble à:

[1] 25647

   indiquant que ce job est le job numéro 1 et le process ID du dernier processus dans le pipeline associé à ce job est 25647. Tous les processus dans un seul pipeline sont membre du même job. bash utilise l'abstraction de job comme base pour le contrôle de job.

   Pour faciliter l'implémentation de l'interface utilisateur pour contrôler les jobs, le système d'exploitation maintient la notion de current terminal process group ID. Les membres de ce groupe de processus (les processus dont le process group ID est égal au process group ID du terminal courant) reçoivent les signaux clavier tel que SIGINT. Ces processus sont dit en foreground. Les processus background sont ceux dont le process group ID diffère de celui du terminal. De tels processus sont immunisés aux signaux clavier. Seul les processus foreground sont autorisés à lire ou écrire dans le terminal, si l'utilisateur le spécifie avec stty tostop. Les processus background qui tentent de lire ou écrire quand stty tostop est effectif dans le terminal reçoivent SIGINT (SIGTTOU) par le pilote terminal du kernel, qui, à moins d'être capturé, suspend le processus.

   Si l'OS supporte le contrôle de job, bash contient de facilitées pour l'utiliser. En tapant de caractère suspend (généralement ^Z, Control-Z) pendant qu'un processus fonctionne, celui-ci est stoppé et le contrôle est retourné à bash. En tapant le caractère delayed suspend (généralement ^Y, Control-Y), le processus est stoppé quand il tente de lire l'entrée depuis le terminal. L'utilisateur peut ainsi manipuler l'état de ce job, en utilisant les commandes bg, fg et kill.

   Il y a différentes manières de faire référence à un job dans le shell. Le caractère % introduit une spécification de job (jobspec). Le job numéro n peut être référencé par %n. Un job peut aussi être référencé en utilisant un préfixe du nom utilisé pour le lancer, ou en utilisant une sous-chaîne qui apparaît dans sa ligne de commande. Par exemple, %ce fait référence au job nommé ce stoppé. Si le préfixe matche plus d'un job, bash reporte une erreur. %?ce fait référence à tout job contenant là chaîne ce dans sa ligne de commande. Si la sous-chaîne matche plus d'un job, bash reporte une erreur. Les symboles %% et %+ font référence à la notion de job courant, qui est le dernier job stoppé pendant qu'il étaie en foreground ou lancé en background. e précédent job peut être référencé en utilisant %-.

   S'il y a seulement un seul job, %+ et %- peuvent être utilisés pour faire référence à ce job. Dans la sortie se rapportant aux jobs (ex: la sortie de la commande jobs), le job courant est toujours flaggé avec un +, et le précédent job avec un -. Un simple % fait également référence au job courant.

   Nommer simplement un job peut être utilisé pour le passer en foreground: %1 est un synonyme pour fg %1, et passe le job 1 du background en foreground. Similairement, %1 & résume le job 1 en background, équivalent à bg %1.

   Le shell apprend immédiatement quand un job change de statut. Normalement, bash attend jusqu'à ce qu'il affiche un prompt avant de reporter les changements dans le statut d'un job afin de ne pas interrompre une autre sortie. Si l'option -b de la commande set est activée, bash reporte de tels changements immédiatement. Tout trap sur SIGCHLD est exécuté pour chaque enfant qui se termine.

   Si une tentative de quitter bash est faite pendant que les jobs sont stoppés, le shell affiche un warning, et, si l'option checkjobs est activé, liste les jobs et leur statuts. La commande jobs peut être ainsi utilisé pour inspecter leur statut.

Prompting

   Exécuté intéractivement, bash affiche le prompt primaire quand il est prêt à lire une commande, et le prompt secontaire quand il demande plus d'entrée pour compléter une commande. les caractères suivants peuvent être utilisés pour personnaliser ces prompt:

\a Le caractère ASCII bell (07)
\d La date au format "Jours Mois" ex: Tue May 26
\D{format} Le format est passé à strftime(3)
\e Le caractère ASCII d'échappement (033)
\h Le nom d'hôte jusqu'au premier point
\H Le nom d'hôte
\j Le nombre de jobs actuellement géré par le shell
\l Le basename du nom du périphérique terminal du shell
\n nouvelle ligne
\r retour charriot
\s Le nom du shel, le basename de $0
\t L'heure courante HH:MM:SS au format 24 heures
\T L'heure courante HH:MM:SS au format 12 heures
\@ L'heure courante HH:MM au format 12 heures
\A L'heure courante HH:MM au format 24 heures
\u Le nom de l'utilisateur courant
\v La version de bash
\V La release de bash
\w Le répertoire de travail courant, $HOME est remplacé par un tilde (valeur de PROMPT_DIRTRIM)
\W Le répertoire de travail courant, $HOME est remplacé par un tilde
\! le numéro d'historique de cette commande
\# Le numéro de commande de cette commande
\$ Is l'ID effectif est 0, un # sinon un $
\nnn Le caractère correspondant au numéro octal nnn
\\ Le caractère \
\[ Commence une séquence de caractère non imprimable, qui peut être utilisé pour embarquer une séquence de contrôle de terminal
\] La fin d'un séquence de caractères non imprimable.

   Le numéro de commande et le numéro d'historique sont généralement différent: le numéro d'historique d'une commande est sa position dans la liste d'historique, qui peut inclure des commandes restaurée depuis le fichier d'historique. Le numéro de commande est la position dans la séquence de commandes exécutées durant la session du shell courant.

READLINE

   C'est la librairie qui manipule l'entrée avec un shell interactif, sauf si l'option --noediting est donné. L'édition de ligne est aussi utilisé avec l'option -e de la commande read. Par défaut, les commandes d'édition de ligne sont similaires à celles d'emacs. Un style vi est également disponible. L'édition de ligne peut être activé avec -o emacs ou -o vi de la commande set. Pour la désactiver, +o emacs ou +o vi.

Notation

   Dans cette section le style emacs est utilisé. Les clés de contrôle sont dénotés par C-key et les clé méta sont dénotés M-key. Pour les claviers sans touche meta, utiliser la touche échappe. Les commandes Readline peuvent être donnés en arguments numériques, qui normalement agit comme un compteur de répétition. Parfois, cependant, c'est le signe de l'argument qui est significatif. En passant un argument négatif à une commande qui agit en avant, agit en arrière. Quand une commande est décrite comme killing teste, le teste supprimé est sauvé pour une récupération future (yanking). Le texte tué est sauvé dans un kill ring. Des kills consécutifs accumulent le texte en une unité, qui peut être yanké en une seule fois. Le commandes qui ne kill pas le texte séparent le portions de texte dans le kill ring.

Initialisation de Readline

   Readline est personnalisé en plaçant des commandes dans un fichier d'initialisation ( le fichier inputrc). Le nom de ce fichier est pris de la valeur de INPUTRC. Si cette variable est non définis, utilise ~/.inputrc. Quand un programme utilise la librairie Readline au démarrage, le fichier d'initialisation est lu, et le combinaisons de touche et variables sont définies. Il n'y a que quelques constructions basiques permises dans le fichier d'initialisation.

Exemple, la ligne suivante
M-Control-u: universal-argument
ou
C-Meta-u: universal-argument
Définis une combinaisons de touche pour la commande readline universal-argument

   Les noms de caractère symbolique suivant sont reconnus: RUBOUT, DEL, ESC, LFD, NEWLINE, RET, RETURN, SPC, SPACE, TAB En plus des noms de commande, Readline permet de lier de touches à une chaîne qui est insérée quand la touche est pressée (une macro).

Combinaisons de touches

   La syntaxe pour contrôler les combinaisons de touche dans le fichier inputrc est simple. Il faut le nom de la commande ou le texte d'une macro et une séquence de touches. Le nom peut être spécifié de deux manières: comme nom de touche symbolique, optionnellement préfixeé avec Meta- ou Control-, ou comme séquence de touche. En utilisant la forme keyname:function-name ou macro, par exemple:

        Control-u: universal-argument
        Meta-Rubout: backward-kill-word
        Control-o: "› output"

   Dans cet exemple, C-u est lié à la fonction universal-argument, M-DEL est lié à la fonction backward-kill-word, et C-o est une macro. (insert "› output").

   Dans la seconde forme, "keyseq".function-name ou macro, Une séquence de touche entière peut être spécifiée en plaçant la séquence entre guillemets. Certains échappements de caractère Emacs peuvent être utilisés, comme dans l'exemple suivant, mais les caractères symboliques ne sont pas reconnus.

        "\C-u": universal-argument
        "\C-x\C-r": re-read-init-file
        "\e[11~": "Function Key 1"

   Dans cet exemple, C-u est lié à la fonction universal-argument, C-x C-r est lié à la fonction re-read-init-file et ESC [ 1 1 ~ est une macro qui insert "Function Key 1". Le jeu complet de séquences d'échappement Emacs est:

        \C- control prefix
        \M- meta prefix
        \e an escape character
        \\ backslash
        \" literal "
        \' literal '

   En plus des séquence Emacs, un autre jeu d'échappement est disponible:

        \a alert (bell)
        \b BACKSPACE
        \d delete
        \f form feed
        \n NEWLINE
        \r retour charriot
        \t tabulation horizontal
        \v tabulation vertical
        \NNN La valeur 9-bits de numéro octal NNN (1 à 3 chiffres)
        \xHH La valeur 9-bits de numéro hexa HH (1 à 2 chiffres)

   En entrant le texte d'un macro, les guillemets simple ou double doivent être utilisés pour indiquer une définition de macro. Le texte non-quoté est supposé être un nom de fonction. Dans le corps d'un macro, l'échappement "\" est étendu. bash permet de modifier ces liaisons avec la commande bind. Le mode édition peut être utilisé en utilisant l'option -o de la commande set.

Variables ReadLine

   Readline a des variables que peuvent être utilisées pour personnaliser sont fonctionnement. Une variable peut être définie dans le fichier inputrc, sous la forme:

        set variable-name value

   Sauf mention, les variables readline peuvent prendre les valeurs on ou off. Les noms de variable non reconnues sont ignorés. Quand une variable est lue, les valeurs vide, null, "on" et "1" sont équivalents à On. Toutes les autres variables sont équivalentes à off. Les valeurs par défauts sont spécifiées entre parenthèses:

bell-style (audible) tente de jouer le bell du terminal, none pour le désactiver.
bind-tty-special-chars (On) Tente le lier les caractères de contrôle traités spécialement par le terminal à leur équivalent readline.
colored-stats (Off) À on, tente d'afficher les completions possibles en utilisant différentes couleurs pour indiquer le type de fichier. Les définitions de couleurs sont prises depuis la valeur LS_COLORS.
comment-begin ("#") La chaîne qui est insérée quand la commande readline insert-comment est exécutée. Cette commande est liée à M-# en mode emacs, et à # en mode vi.
completion-ignore-case (Off) À on, readline est insensible à la casse lors des completions et filename matching.
completion-prefix-display-length (0) La longueur en caractères du préfixe commun d'une liste de complétions possible qui est affiché sans modification. à une valeur supérieur à 0, les préfixes communs plus longs sont remplacés avec une ellipse quand les completions possible sont affichés.
completion-query-items (100) Détermine quand demander à l'utilisateur pour voir les completions possibles générées par la commande possible-completions.
convert-meta (On) Readline convertit les caractères avec le 8-ème bit mit en une séquence clé ASCII en supprimant ce 8-ème bit et en préfixeant du caractère échappe.
disable-completion (Off) À On, readline inhibe la completion de mots. Les completions de caractères seront insérés dans la line comme s'ils avaient été mappés à self-insert.
editing-mode (emacs) Contrôle si Readline utilise un jeu de combinaisons de touches similaire à emacs ou vi.
echo-control-characters (On) Readline répète un caractère correspondant à un signal généré depuis le clavier.
enable-keypad (Off) à on, readline tente d'activer le keypad quand il est appelé. Certains systèmes en ont besoin pour accéder aux touches fléchées.
enable-meta-key (On) readline tente d'activer une touche méta demandé par le terminal. Dans de nombreux terminaux, la touche méta est utilisée pour envoyer des caractères 8-bits.
expand-tilde (Off) à on, l'expansion de tilde est effectuée quand readline tente la completion de mot.
history-preserve-point (Off) à on, le code d'historique tente de placer un point au même emplacement dans chaque ligne d'historique récupérée avec previous-history or next-history.
history-size (0) Définis le nombre maximum d'entrées d'historique sauvegardé. À 0, toutes les entrées sont supprimées et aucune entrée n'est sauvegardée. Par défaut, le nombre d'entrée n'est pas limité.
horizontal-scroll-mode (Off) à on, ReadLine utilise une seule ligne pour l'affichage, scroll l'entrée horizontalement dans une seule ligne quand elle devient plus grande que l'écran.
input-meta (Off) À on, Readline active l'entrée 8-bits sans regardes si le terminal le supporte. le nom meta-flag est un synonyme pour cette variable.
isearch-terminators (``C-[C-J'') La chaîne de caractères qui devrait terminer une recherche incrémentale sans exécuter le caractère comme commande. Si cette variable n'a pas de valeur, les caractères ESC est C-J vont terminer une recherche incrémentale.
keymap (emacs) Définis le mappage ReadLine courant. Les jeu de keymap valide est emacs, emacs-standard, emacs-meta, emacs-ctlx, vi, vi-command et vi-insert.
keyseq-timeout (500) Spécifies la durée d'attente d'un caractère quand une séquence de touche ambigüe est lue. Si aucune entrée n'est reçue passée ce délai, readline utilise la séquence de touche. La valeur est spécifiée en millisecondes, Si non définis ou à une valeur inférieur ou égal à 0 ou à une valeur non-numérique, readline attend toujours une autre touche pour décider quelles séquence de touche compléter.
mark-directories (On) Les noms de répertoires complétés ont un / ajouté.
mark-modified-lines (Off) À on, les lignes d'historique qui ont été modifiés sont suffixés avec un (*)
mark-symlinked-directories (Off) À on, les noms complétés qui sont des liens symboliques vers des répertoires ont un / ajouté
match-hidden-files (On) ReadLine matche les noms de fichiers cachés lors de la completion.
menu-complete-display-prefix (Off) À on, la completion de menu affiche de préfixe commun de la liste de completions possible avant de cycler dans la liste.
output-meta (Off) À on, readline affiche les caractères avec le 8-ième bis mis directement plutôt que comme séquence d'échappement préfixeé par méta.
page-completions (On) ReadLine utilise un pager style more interne pour afficher un écran complet de completions possible.
print-completions-horizontally (Off) À on, ReadLine affiche les completions avec les matches triés horizontalement dans l'ordre alphabétique.
revert-all-at-newline (Off) À on, ReadLine annule tout changements dans les lignes d'historique avant de retourner quand accept-line est exécuté.
show-all-if-ambiguous (Off) À on, les mots qui ont plus d'une completion possible affichent immédiatement les matches au lieu de sonner le bell
show-all-if-unmodified (Off) À on, les mots qui on plus d'une completion possible sans completion partielle possible (les completions possible ne partagent pas de prefixe commun) affichent immédiatement les matches au lieu de sonner le bell
show-mode-in-prompt (Off) À on, ajoute un caractère au début du prompt indiquant le mode d'édition: emacs (@), vi command (:) ou vi insertion (+)
skip-completed-text (Off) À on, Altère la completion en insérant un simple matche dans la ligne. Actif seulement lors de la completion au milieu d'un mot. Si actif, readline n'insert pas de caractères de la completion qui matche les caractère après un point dans le mot à compléter.
visible-stats (Off) À on,Un caractère dénotant un type de fichier comme reporté par stat est ajouté au nom de fichier en listant les completions possibles.

Constructions conditionnelles de ReadLine

   Readline implémente une facilité similaire aux compilations comditionnel du préprocesseur C qui permet à des raccourcis et variables d'être exécutés en tant que résultat de tests. Il y a 4 directives utilisés.

$if Permet de baser les liaisons sur le mode d'édition, le terminal utilisé, ou l'application utilisant readline.

        mode Utilisé pour tester si readline est en mode vi ou emacs.
        term Utilisé pour inclure des liaisons spécifique au terminal, par exemple pour lier la sortie des séquences de touche à des fonctions du terminal. Le mot est testé avec le nom complet du terminal et la portion du nom avant le premier -.
        application Utilisé pour inclure des paramètres spécifiques à une application. Chaque programme utilisant readline définis le nom d'application. La commande suivante ajoute une séquence de touches qui quote le mot courant et le précédant dans bash:

                $if Bash
                # Quote the current or previous word
                "\C-xq": "\eb\"\ef\""
                $endif

$endif Termine une commande $if
$else Exécuté si la directive $if échoue
$include Fichier où lire des commandes et liaisons.

Recherche

   ReadLine fournis des commandes pour rechercher dans l'historique de commandes des lignes contenant une chaîne spécifiée. Il y a 2 modes de recherche: incrémentale et non incrémentale.

   Les recherches incrémentales commencent avant que l'utilisateur ait finis de taper la chaîne de recherche. À chaque caractère entré, readline affiche la prochaine entrée de l'historique correspondante. Une recherche incrémentale nécessite uniquement autant de caractères que nécessaire pour trouver l'entrée d'historique désirée. Les caractères présents dans isearch-terminators sont utilisés pour terminer une recherche incrémentale. Si cette variable n'a pas de valeur, Escape et Control-J terminent la recherche incrémentale. Contrôle-G annule une recherche incrémentale et restaure la ligne originale. Quand la recherche est terminée, l'entrée d'historique contenant la chaîne recherchée devient la ligne courante.

   Pour trouver d'autre entrées correspondantes dans la liste d'historique, utiliser Control-S ou Control-R. Toute autre séquence liée à une commande readline termine la recherche et exécuter la commande. ReadLine mémorise la dernière chaîne de recherche incrémentale. Si 2 Control-R sont tapés sans un caractère définissant une nouvelle recherche, la chaîne mémorisée est utilisée.

   Les recherches non-incrémentales lisent toute la chaîne de recherche avant de commencer la recherche.

Noms de commandes ReadLine

   La liste suivante contient les noms des commandes et leur séquence de touche par défaut. Dans les descriptions, point réfère à la position courant du curseur, et mark réfère à la position du curseur sauvée par la commande set-mark. Le texte entre le point et mark est la region

Commandes de déplacement

beginning-of-line (C-a) Se placer au début de la ligne courante
end-of-line (C-e) Se placer à la fin de la ligne
forward-char (C-f) Se déplacer d'un caractère en avant
backward-char (C-b) Se déplacer d'un caractère en arrière
forward-word (M-f) Se déplacer à la fin du prochain mot
backward-word (M-b) Se déplacer au début du mot courant ou précédent
shell-forward-word Se déplacer à la fin du prochain mot
shell-backward-word Se déplacer au début du mot courant ou précédent
clear-screen (C-l) Effacer l'écran en plaçant la ligne courant à la ligne du haut
redraw-current-line Rafraîchis la ligne courante

Commandes de manipulation d'historique

accept-line (Newline, Return) Accepte la ligne sans regarder où se situe le curseur. Si la ligne n'est pas vide, l'ajoute à la liste d'historique. Si la ligne est une ligne d'historique modifiée, restaure la ligne à son état original
previous-history (C-p) Se déplacer en arrière dans la liste d'historique
next-history (C-n) Se déplacer en avant dans la liste d'historique
beginning-of-history (M-‹) Se placer à la première ligne d'historique
end-of-history (M-›) Se placer à la fin de l'historique
reverse-search-history (C-r) Rechercher en arrière dans l'historique en commençant à la ligne courante. C'est une recherche incrémentale
forward-search-history (C-s) Rechercher en avant dans l'historique en commençant à la ligne courante. C'est une recherche incrémentale
non-incremental-reverse-search-history (M-p) Recherche en arrière dans l'historique en commençant à la ligne courant en utilisant une recherche non-incrémentale.
non-incremental-forward-search-history (M-n) Recherche en avant dans l'historique en commençant à la ligne courant en utilisant une recherche non-incrémentale.
history-search-forward Recherche en avant dans l'historique la chaîne de caractères entre le début de la ligne courante et le point. C'est une recherche non-incrémentale
history-search-backward Recherche en arrière dans l'historique la chaîne de caractères entre le début de la ligne courante et le point. C'est une recherche non-incrémentale
yank-nth-arg (M-C-y) Insert le premier argument de la commande précédente au point. Avec un argument n, insert le n-ième mot de la commande précédente. Un argument négatif commence à la fin de la commande précédente. Une fois l'argument calculé, l'argument est extrait comme si l'expansion !n avait été spécifié.
yank-last-arg (M-., M-_) Insert le dernier argument de la commande précédente. Une fois l'argument calculé, l'argument est extrait comme si l'expansion !$ avait été spécifié.
shell-expand-line (M-C-e) Étend la ligne comme le shell. Celà effectue une expansion d'alias et d'historique de la même manière que l'expansion de mot du shell.
history-expand-line (M-^) Expansion d'historique sur la ligne courante.
magic-space Expansion d'historique sur la ligne courante et insert un espace
alias-expand-line Expansion l'alias sur la ligne courante
history-and-alias-expand-line Expansion d'historique et d'alias sur la ligne courante.
insert-last-argument (M-., M-_) synonyme pour yank-last-arg
operate-and-get-next (C-o) Accepte la ligne courante et remplis la ligne suivante relativement à la ligne courante dan l'historique. Tout argument est ignoré
edit-and-execute-command (C-xC-e) Invoque un éditeur dans la ligne de commande courante, et exécute le résultat en tant que commande shell. bash tente d'invoquer VISUAL, EDITOR, et emacs dans cet ordre.

Commandes pour changer du texte

end-of-file (usually C-d) Le caractère indiquant la fin du fichier.
delete-char (C-d) Supprime le caractère au point.
backward-delete-char (Rubout) Supprime le caractère avane le curseur
forward-backward-delete-char Supprime le caractère sous le curseur
quoted-insert (C-q, C-v) Ajoute le prochain caractère tapé textuellement
tab-insert (C-v TAB) Insert un caractère tabulation
self-insert (a, b, A, 1, !, ...) Insert le caractère tapé
transpose-chars (C-t) Fait glisser le mot avant le point aprés ce point, déplaçant le point après ce mot également. Si le point est à la fin de la ligne, transpose les 2 derniers mot de la ligne.
upcase-word (M-u) Met en majuscule le mot courant, ou le précédant si l'argument est négatif
downcase-word (M-l) Met en minuscule le mot courant, ou le précédant si l'argument est négatif
capitalize-word (M-c) Capitalise le mot courant, ou le précédant si l'argument est négatif
overwrite-mode Passe en mode écarsement. Avec un argument positif explicite, switche en mode overwrite. Avec un argument négatif explicite, switche en mode insert. Chaque appel à readline() commence en mode insert. N'affecte que le mode emacs. En mode overwrite, les caractères liés à self-insert remplacent le texte au point au lieu de pousser le texte. Les caractères liés à backward-delete-char remplacent le caractère avant le point avec un espace.

Killing et Yanking

kill-line (C-k) Tue le texte depuis le point jusqu'à la fin de la ligne
backward-kill-line (C-x Rubout) Tue le teste au début de la ligne
unix-line-discard (C-u) Tue le teste depuis le point jusqu'au début de la ligne. Ce texte tué est sauvé dans le kill-ring
kill-whole-line Tue toute la ligne
kill-word (M-d) Tue le mot courant
backward-kill-word (M-Rubout) Tue le mot avant le point
shell-kill-word (M-d) Tue depuis le point jusqu'à la fin du mot courant
shell-backward-kill-word (M-Rubout) Tue le mot derrière le point
unix-word-rubout (C-w) Tue le mot derrière le point, en utilisant les espaces blanc comme délimiteur de mot. Le texte tué est sauvé dans le kill-ring
unix-filename-rubout Tue le mot derrière le point, en utilisant les espaces blanc et le slash comme délimiteur de mot. Le texte tué est sauvé dans le kill-ring
delete-horizontal-space (M-\) Supprime tous les espaces et tabulations autour du point
kill-region Tue de texte dans la region courante
copy-region-as-kill Copie de texte dans la region dans le tampon kill
copy-backward-word Copie le mot avant le point dans le tampon kill
copy-forward-word Copie le mot suivant le point dans le tampon kill
yank (C-y) déplace le haut du kill-ring dans le tampon au point
yank-pop (M-y) Rotation du kill-ring, et déplace le nouveau haut de la pile.

Arguments numérique

digit-argument (M-0, M-1, ..., M--) Ajoute ce chiffre à l'argument déjà accumulé, ou commence un nouvel argument. M-- commence un argument négatif
universal-argument Autre manière de spécifier un argument. Si cette commande est suivie par un ou plusieurs chiffres, optionnellement avec un signe moins, cet chiffres définissent un argument. Si la commande est suivi par des chiffres, exécuter de nouveau universal-argument termine l'argument, mais est ignoré. Un cas spécial, si la commande est immédiatement suivie par un caractère qui n'est ni un chiffre ni le signe moins, le compteur d'arguments pour la prochaine commande est multiplié par 4.

Conpletion

complete (TAB) Tente d'effectuer une completion sur le texte avant le point. Bash tente la completion en traitant le texte comme une variable (si le texte commence avec $), nom d'utilisateur (si le texte commence avec ~), nom d'hôte (si le texte commence avec @), ou une commande (incluant les alias et fonctions). S'il n'y a toujours aucun match, tente une completion de nom de fichier.
possible-completions (M-?) Leste les completions possible du texte avant le point
insert-completions (M-*) Insert toutes les completions du texte avant le point qui aurait été généré par possible-completion
menu-complete Similaire à complete, mais remplace le mot à completer avec un seul match dans la liste des completions possible. Une exécution répétée de menu-complete passe à l'élément suivant dans la liste des completions possible.
menu-complete-backward Identique à menu-complete mais se déplace en arrière dans la liste des completions possible.
delete-char-or-list Supprime le caractère sous le curseur s'il n'est pas au début ou à la fin de la ligne (comme delete-char). S'il est au début ou à la fin de la ligne, devient identique à possible-completions
complete-filename (M-/) Tente une completion de nom de fichier sur le texte avant le point
possible-filename-completions (C-x /) Liste les completions possible sur le texte avant le point, traité comme nom de fichier
complete-username (M-~) Tente une completion de nom d'utilisateur sur le texte avant le point.
possible-username-completions (C-x ~) Liste les completions possible sur le texte avant le point, traité comme nom d'utilisateur
complete-variable (M-$) Tente une completion de variable sur le texte avant le point.
possible-variable-completions (C-x $) Liste les completions possible sur le texte avant le point, traité comme variable
complete-hostname (M-@) Tente une completion de nom d'hôte sur le texte avant le point.
possible-hostname-completions (C-x @) Liste les completions possible sur le texte avant le point, traité comme nom d'hôte
complete-command (M-!) Tente une completion de commande sur le texte avant le point.
possible-command-completions (C-x !) Liste les completions possible sur le texte avant le point, traité comme commande
dynamic-complete-history (M-TAB) Tente une conpletion d'historique sur le texte avant le point
dabbrev-expand Tente une completion de menu sur le texte avant le point, en comparant le texte avac les lignes de l'historique
complete-into-braces (M-{) Effecture une completion de nom de fichier et insert la liste des completion possible entre accolade pour que la liste sont disponible au shell.

Macros Clavier

start-kbd-macro (C-x () Commence à sauver les caractères tapés dans la macro clavier courante
end-kbd-macro (C-x )) Stop l'enregistrement des caractère tapés dans la macro clavier courante
call-last-kbd-macro (C-x e) Re-exécute la dernière macro définie
print-last-kbd-macro () Affiche la dernière macro définie dans un format utilisable dans inputrc

Divers

re-read-init-file (C-x C-r) recharge le contenu du fichier inputrc,
abort (C-g) Annule la commande d'édition courante.
do-uppercase-version (M-a, M-b, M-x, ...) Si le caractère utilisé avec Méta est en minuscule, lance la commande qui est lié au caractère majuscule correspondant.
prefix-meta (ESC) Le prochain caractère est un caractère méta. par exempre ESC f est équivalent à Meta-f
undo (C-_, C-x C-u) undo incrémental
revert-line (M-r) Annule tout changements fait sur cette ligne
tilde-expand (M-&) Effecue une expansion de tilde sur le mot courant
set-mark (C-@, M-‹space›) Définis le mark sur le point. Si un argument est fournis, définis le mark à cette position
exchange-point-and-mark (C-x C-x) inter-change le point et le mark
character-search (C-]) Un caractère est lu et le point est déplacé à la prochaine occurrence de ce caractère.
character-search-backward (M-C-]) Un caractère est lu est le point est déplacé à la précédente occurrence de ce caractère.
skip-csi-sequence Lit suffisamment de caractère pour consommer une séquence multi-touche telle que celles définies pour des touches comme Home et End. De telles séquences commencent avec un Control Sequence Indicator (CSI), généralement ESC-[. Si la séquence est liée à \[, les touches produisant de telles séquences n'auront pas d'effet sauf explicitement liée à une commande readline, au lieu d'insérer les caractères dans le tampon d'édition.
insert-comment (M-#) Sans argument numérique, la valeur de la variable readline comment-begin est insérée au début de la ligne courante. Si un argument numérique est fournis, cette commande agit comme un switch: Si les caractères au début de la ligne ne matchent pas la valeur de comment-begin, la valeur est insérée, sinon les caractères dans comment-begin sont supprimés du début de la ligne. La valeur par défaut de comment-begin force cette commande à commenter la ligne courante.
glob-complete-word (M-g) Le mot avant le point est traité comme pattern pour l'expansion de chemin, avec un * ajouté implicitement. Ce pattern est utilisé pour générer une liste de noms de fichiers possible.
glob-expand-word (C-x *) Le mot avant le point est traité comme pattern pour l'expansion de chemin, et la liste de noms de fichiers matchant est inséré, remplaçant le mot. Si un argument numérique est fournis, un * est ajouté implicitement avant l'expansion.
glob-list-expansions (C-x g) La liste des expansions qui auraient été générés par glob-expand-word est affichée, et la ligne et redéssinée. Si un argument numérique est fournis, un * est ajouté implicitement avant l'expansion.
dump-functions Affiche toutes les fonctions et leur liaisons dans le flux de sortie de readline. Si un argument numérique est fournis, la sortie est formatée au format inputrc
dump-variables Affiche toutes les variables readline dans le flux de sortie de readline. Si un argument numérique est fournis, la sortie est formatée au format inputrc
dump-macros Affiche toutes les séquences de touche et leur valeurs dans le flux de sortie de readline. Si un argument numérique est fournis, la sortie est formatée au format inputrc
display-shell-version (C-x C-v) Affiche le version de l'instance courante.

Completion Programmable

   Quand la completion de mot et tenté par un argument d'une commande pour laquelle une spécification de completion (compspec) a été définie en utilisant la commande complete, la fonction de completion programmable est invoquée.

   Premièrement, le nom de la commande est identifiée. Si la commande est une chaîne vide, tout compspec définie avec l'option -E de la commande complete est utilisée. Si un compspec a été définis pour cette commande, le compspec est utilisé pour générer la liste de completions possible. Si la commande est un chemin complet, un compspec pour ce chemin complet et recherché en premier. Si ces recherches ne réussissent pas, tout compspec définis avec l'option -D est utilisé.

   Une fois un compspec trouvé, il est utilisé pour générer la liste de mots correspondant. Si un compspec n'est pas trouvé, la completion par défaut de bash est effectué.

   D'abord, les actions spécifiées par le compspec sont utilisés. Seul les matchs qui sont préfixeés par le mot à compléter sont retournés. Quand l'option -f ou -d est utilisé pour la completion de nom de fichier ou de nom de répertoire, la variable shell GLOBIGNORE n'est pas utilisée pour filtrer les matchs, mais la variable FIGNORE est utilisée.

   Ensuite, la chaîne spécifiée comme argument de l'option -W est considérée. La chaîne est d'abord splitté en utilisant les caractères dans IFS. Le quoting est honoré. Chaque mot est ensuite étendu en utilisant l'expansion d'accolade, l'expansion de tilde, l'expansion de paramètre et de variable, la substitution de commande, et l'expansion arithmétique. Les résultat sont splittés en utilisant les règles de Word Splitting. Les résultats de l'expansion sont préfixe-matchés avec le mot à compléter, et les mots matchés deviennent les completions possible.

   Après que ces matchs aient été générés, toute fonction ou commande shell spécifiée avec les options -F et -C est invoquée, les variables COMP_LINE, COMP_POINT, COMP_KEY et COMP_TYPE sont ajustées. Si une fonction shell est invoquée, les variables COMP_WORDS et COMP_CWORD sont également ajustées. Quand la fonction ou la commande est invoquée, le premier argument ($1) est le nom de la commande dont les arguments sont à compléter, le deuxième argument ($2) est le mot à compléter, et le troisième argument ($3) est le mot précédant le mot à compléter sur la ligne courante.

   Toute fonction spécifiée avec -F est invoquée en premier. La fonction peut utiliser toute facilité du shell, incluant le compgen, pour générer les matchs. Il dois placer les completions possible dans le tableau COMPREPLY.

   Ensuite, toute commande spécifiée avec l'option -C est invoquée dans un environnement équivalent à la substitution de commande. Elle devrait afficher une liste de completions, une par ligne, sur la sortie standard. un \ peut être utilisé pour échapper un newline, si nécessaire.

   Une fois toutes les completions possible générées, tout filtre spécifié avec l'option -X est appliqué à la liste. Le filtre est un motif comme utilisé pour l'expansion de chemin; un & dans le pattern est remplacé avec le texte du mot à compléter. Toute completion qui matche le pattern est supprimé de la liste. Un ! inverse le pattern.

   Finallement, tout préfixe et suffixe spécifié avec les options -P et -S sont ajoutés à chaque membre de la liste de completion, et le résultat est retourné au code de completion de readline.

   Si les actions précédemment appliquées ne génèrent aucun match, et que l'option -o dirnames de la commande complete est fournie, la completion de nom de répertoire est tentée. Si l'option -o plusdirs de la commande complete est fournie, la completion de nom de répertoire est tentée et tout matche est ajouté au résultat des autres actions.

   Par défaut, si un compspec est trouvé, tout ce qu'il génère est retourné au code de completion. Les completions bash par défaut ne sont pas effectués, et la completion de nom de fichier par défaut de readline est désactivée. Si l'option -o bashdefault est fournie, les completions par défaut de bash sont tentée quand le compspec ne génère aucun match. Si l'option -o default est fournie, la completion par défaut de readline est effectuée si le compspec ( et, si tenté, les completions de bash) ne génère aucun match.

   Quand un compspec indique que la completion de répertoire est désiré, les fonctions de completion programmable forcent readline à ajouter un / aux noms complétés qui sont des liens symboliques de répertoire, sujet à la valeur de mark-directory, sans regarder la variable mark-symlinked-directories.

   Il y a un support pour les completions dynamiques. C'est plus utile quand utilisé en combinaison avec une completion par défaut spécifiée avec complete -D. Il est possible pour les fonctions shell exécutées comme manipulateurs de completion d'indiquer que la completion devrait être récupérée en retournant un code de sortie 124. Si une fonction shell retourne 124, et les changements du compspec associé avec la commande dans laquelle la completion est tentée, la completion programmable redémarre du début, et tente de trouver un autre compspec pour cette commande. Cela permet à un jeu de completion d'être construit dynamiquement.

Assumons qu'il y a une librairie de compspecs, chacun conservés dans un fichier correspondant au nom de la commande, la fonction de completion par défaut suivante charge les completions dynamiquement:
_completion_loader()
{
    . "/etc/bash_completion.d/$1.sh" ›/dev/null 2›&1 && return 124
}
complete -D -F _completion_loader -o bashdefault -o default

Historique

   Quand set -o history est activé, le shell fournis un accès à l'historique de commande, la liste des commandes précédemment tapés. La valeur de HISTSIZE est utilisé comme nombre de commandes à sauvegarder. Le shell stocke chaque commande avant l'expansion de paramètre et de variables, mais après que l'expansion l'historique ait été effectué, sujet aux valeurs de HISTIGNORE et HISTCONTROL.

   Au démarrage, l'historique est initialisé depuis le fichier nommé par la variable HISTFILE (défaut: ~/.bash_history). Ce fichier est tronqué, si nécessaire, pour ne pas contenir plus de lignes que le nombre spécifié par HISTFILESIZE. Quand le fichier d'historique est lu, les lignes commençant avec le caractère de commentaire d'historique suivi immédiatement par un chiffre sont interprétés comme timestamps pour la précédente ligne d'historique. Ces timestamp sont optionnellement affichés en fonction de la valeur de HISTTIMEFORMAT. Quand un shell avec l'historique activé se termine, les dernière lignes HISTSIZE sont copiées de la liste d'historique dans HISTFILE.

   Si l'option shell histappend est activée, les lignes sont ajoutée au fichier d'historique, sinon les lignes écrasent le contenu du fichier. Si HISTFILE n'est pas définis, ou si le fichier d'historique n'est pas accessible en écriture, l'historique n'est pas sauvegardé. Si HISTTIMEFORMAT est définie, les timestamps sont écris dans le fichier d'historique, marqués avec le caractère de commentaire d'historique. Une fois l'historique sauvé, le fichier d'historique est tronqué pour contenir HISTFILESIZE lignes. Si HISTFILESIZE n'est pas définie, null, une valeur non numérique, ou une valeur inférieur à 0, le fichier d'historique n'est pas tronqué.

   Le commande fc peut être utilisée pour lister ou éditer et ré-exécuter une portion de la liste d'historique. La commande history peut être utilisée pour afficher ou modifier la liste d'historique et manipuler le fichier d'historique. En utilisant l'édition de ligne de commande, les commandes de recherche sont disponible dans chaque mode d'édition qui fournissent un accès au fichier d'historique.

   Le shell permet de contrôler quelles commandes sont sauvées dans la liste d'historique. Les variable HISTCONTROL et HISTIGNORE peuvent être définis pour déterminer ce que le shell sauvegarder dans la liste. La commande cmdhist, si activée, force le shell à tenter de sauver chaque ligne d'un commande multi-ligne dans la même entrée d'historique, en ajoutant des ; où c'est nécessaire. L'option shell lithist force le shell à sauvegarder la commande avec les newline au lieu des ;.

Expansion d'historique

   Le shell supporte l'expansion d'historique qui est similaire à l'expansion d'historique dans csh. Peut être désactivé avec set +H. L'expansion d'historique est effectuée immédiatement après qu'une ligne complète soit lue, avant que le shell la sépare en mots. Elle prend place en 2 parties. La première est pour déterminer quelle ligne de la liste d'historique utiliser durant la substitution. La secondes, les portions de cette ligne à inclure dans la courante. La ligne sélectionnée de l'historique est l'event, et les portions de cette ligne sont les mots. Divers modifieurs sont disponible pour manipuler les mots sélectionnés. La ligne est décomposée en mot de la même manière que lorsque l'entrée est lue, et de nombreux mots séparés par les méta-caractères entourés par des quotes sont considéré comme un seul mot. L'expansion d'historique est introduit par la présence du caractère d'expansion d'historique qui est ! par défaut.

   Des caractères inhibent l'expansion d'historique s'ils sont trouvés juste après le caractère d'expansion d'historique, même s'ils ne sont pas quotés: space, tab, retour charriot, et =. Si l'option extglob est activée, ( inhibe également l'expansion

   Certaine options shell peuvent être utilisées pour modifier le fonctionnement de l'expansion d'historique. Si l'option shell histverify est définie, et que readline est utilisé, les substitutions d'historique ne sont par immédiatement passées au parser. À la place, la ligne étendue est rechargée dans le tampon d'édition de readline pour d'autres modifications. Si readline est utilisé, et que l'option shell histreedit est activée, une substitution d'historique échouée sera rechargée dans le tampon d'édition de readline pour correction. L'option -p de la commande history peut être utilisée pour voir quelle expansion d'historique sera faite avant de l'utiliser. L'option -s peut être utilisée pour ajouter des commandes à la fin de la liste d'historique sans les exécuter.

   Le shell permet de contrôler les divers caractères utilisés par l'expansion d'historique. Le shell utilise le caractère de commentaire d'historique pour marquer les timestamps d'historique en écrivant le fichier d'historique.

Désignateurs d'évènement

   Un event designator est une référence à une ligne de commande dans la liste d'historique. À moins que la référence soit absolue, les events sont relatifs à la position courante dans la liste d'historique.

! Commence une substitution d'historique, avec les exceptions décrites plus haut.
!n Réfère à la ligne de commande n
!-n Réfère à la commande courante - n
!! Réfère à la commande précédente. synonyme de !-1
!string Réfère à la commande la plus récente précédent la position courante commençant avec string
!?string[?] Réfère à la commande la plus récente précédent la position courante commençant avec string, les ? peuvent être omis si string est suivi immédiatement par un newline.
^string1^string2 Substitution rapide. Répète la commande précédante en remplaçant string1 par string2. Équivalent à !!:s/string1/string2/
!# Toute la ligne de commande jusqu'à présent.

Désignateurs de mot

   Les words designator sont utilisés pour sélectionner les mots désirés depuis l'event. Un : sépare la spécification d'event du word designator. Il peut être omis si le word designator commence avec un ^, $, *, -, ou %. Les mots sont numérotés du début de la ligne, en commençant à 0. Les mots sont insérés dans la ligne courante séparés par un espace.

0 Le mot numéro 0. Pour le shell, c'est la commande.
n Le nième mot
^ Le premier argument, le mot numéro 1
$ Le dernier mot
% Le mot matché par le plus récent ?string? recherché
x-y Une plage de mots; -y est une abréviation de 0-y
Tous les mots sauf le premier (0). C'est un synonyme de 1-$.
x*  Abréviation de x-$
x- Abréviation de x-$ come x*, mais omet le dernier mot

   Si un word designator est fournis sans un event specification, la précédante commande est utilisée comme event.

Modificateurs

   Après le word designateur optionnel, il peut apparaître une séquence d'un ou plusieurs modifiers suivants, chacun précédés par un ::

h Supprime un composant restant du nom de fichier, ne laissant que le début
t Supprime tous les composant du nom de fichiers, ne laissant que la fin
r Supprime un suffixe sous la forme .xxx, laissant le basename
e Supprime tout sauf le suffixe restant.
p Affiche la nouvelle commande mais ne l'affiche pas
q Quote les mots substitués
x Quote les mots substitués, mais les sépare sur les blancs et les newline.
s/old/new/ Substitue la première occurence de old à new dans la ligne d'event. Tout délimiteur peut être utilisé à la place de /. Le délimiteur final est optionnel si c'est le dernier caractère de la ligne d'event. Si & apparaît dans new, il est remplacé par old. Un simple \ va quoter le &. Si old est null, il est définis au dernier old substitué, ou, si aucune substitution n'a eu lieu, la dernière chaîne dans la recherche !?string[?]
& Répète la précédente substitution.
g Les changements sont appliqués sur toute la ligne d'event. C'est utilisé en conjonction avec :s (ex: :gs/old/new/), ou :&. Si utilisé avec :s, tout délimiteur peut être utilisé en place de /, et le délimiteur final est optionnel si c'est le dernier caractère de la ligne d'event. Un a peut être utilisé comme synonyme de g.
G Applique de modifieur s une fois pour chaque mot dans la ligne d'event.

Commandes intégrées au shell

   Sauf mention contraire, chaque commande intégrée dans cette section acceptant des options précédés pas - acceptent -- pour signifier la fin des options. Les commandes :, true, false, et test n'acceptent pas d'options et ne traitent par -- spécialement. Les commandes exit, logout, break, continue, let, et shift acceptent et traitent les options commençant par - sans nécessiter --. Les autres commandes qui acceptent des arguments mais n'acceptent pas d'options interprètent les arguments commençant avec - comme invalide et nécessite -- pour empêcher leur interprétation.

: [arguments[ Pas d'effet; la commande ne fait rien hormis étendre les arguments et effectue les redirections spécifiées. Un code de sortie 0 est retourné.
. filename [arguments], source filename [arguments] Lis et exécute les commandes depuis filename dans l'environnement du shell courant et retourne le code de sortie de la dernière commande de filename. Si filename ne contient pas de /, PATH est utilisé pour trouver le fichier. Le fichier recherché dans PATH n'a pas besoin d'être exécutable. Quand bash n'est pas en mode posix, le répertoire courant est recherché si aucun fichier n'est trouvé dans PATH. Si l'option sourcepath de shopt est désactivé, le PATH n'est pas recherché. Retourne 0 si aucune commande n'a été exécutée, et false si filename n'a pas été trouvé ou ne peut être lu.
alias [-p] [name[=value] ...] Sans arguments ou avec l'option -p, affiche la liste des alias sur stdout. Les arguments fournis servent à définir des alias. Un espace après une valeur force le prochain mot à être vérifié pour une substitution d'alias quand l'alias est étendu. Pour chaque nom fournis sans valeur, le nom et la valeur de l'alias sont affichés. aliar retourne true à moins qu'un nom soit donné pour lequel aucun alias n'a été définis.
bg [jobspec ...] Relance chaque job suspendu spécifié en tâche de fond, comme s'il avait été spécifié avec &. Si jobspec n'est pas présent, la notion shell de job courant est utilisé. bg jobspec retourne 0 à moins qu'il soit lancé quand le contrôle de job soit désactivé ou si jobspec n'a pas été trouvé ou a été démarré sans contrôle de job.
bind [-m keymap] [-lpsvPSVX]
bind [-m keymap] [-q function] [-u function] [-r keyseq]
bind [-m keymap] -f filename
bind [-m keymap] -x keyseq:shell-command
bind [-m keymap] keyseq:function-name
bind readline-command Affiche les touches/fonctions readline courante, lie une séquence de touche à une fonction readline ou une macro, ou définis une variable readline. Chaque argument non option est une commande au format .inputrc, mais chaque liaison ou commande doit être passée comme argument séparé; par ex: '"\C-x\C-r": re-read-init-file'. Retourne 0 à moins qu'une option non reconnues soit donnée ou une erreur s'est produite. Les options, si fournies, ont la signification suivante:

        -m keymap Affecte keymap au binding suivant. Les noms de keymap acceptable sont emacs, emacs-standard, emacs-meta, emacs-ctlx, vi, vi-move, vi-command, et vi-insert. vi est équivalent à vi-command; emacs est équivalent à emacs-standard.
        -l Liste les noms de toutes les fonctions readline
        -p Affiche les noms des fonctions readline et leur liaisons au format readline
        -P Liste les noms des fonctions readline et leur liaisons
        -s Affiche les séquences de touche liées au macros et les chaînes qu'elles affichent au format readline.
        -S Liste les séquences de touche liées au macros et les chaînes qu'elles affichent
        -v Affiche les variables et leur valeurs au format readline
        -V Liste les variables et leur valeurs
        -f filename Lis les liaisons de touche depuis le fichier
        -q function Requête quels touches invoquent la fonction spécifiée
        -u function Supprime toutes les touches liées à la fonction spécifiée
        -r keyseq Supprime la liaison courant pour keyseq
        -x keyseq:shell-command Lie keyseq à la commande. Quand shell-command est exécutée, le shell définis la variable READLINE_LINE au contenu du tampon de ligne readline et la variable READLINE_POINT à l'emplacement courant du point d'insertion. Si la commande exécutée change la valeur d'une de ces 2 variables, ces nouvelles valeurs vont être reflétées dans l'état d'édition.
        -X Liste toutes les séquences liées aux commandes shell au format readline.

break [n] Sort d'une boucle for, while, until, ou select. Si n est fournis, sont de n niveau. n doit être supérieur à 1. Si n est supérieur au nombre de boucles imbriquées, sort de toutes les boucles. Retourne 0 sauf si n est inférieur à 1.
builtin shell-builtin [arguments] Exécute la commande intégrée spécifiée, et retourne son code de sortie. Utile quand une fonction à le même nom qu'une commande intégrée. Retourne false si la commande spécifiée n'est pas une commande intégrée.
caller [expr] Retourne le contexte d'un appel à une sous-routine active (une fonction ou un script exécuté avec . ou source). Sans expr, caller affiche le numéro de ligne et le nom du fichier de l'appel de la sous-routine courante. Si un entier non-négatif est fournis dans expr, caller affiche le numéro de ligne, le nom de la sous-routine, et le fichier source correspondant à la position dans la pile d'appel courante. Cette information peut être utilisée, par exemple, pour afficher un stack trace. La frame courante est la frame 0. La valeur de retour est 0 sauf si le shell n'exécute pas de sous-routine, ou expr ne correspond pas à une position valide dans la pile d'appel.
cd [-L|[-P [-e]] [-@]] [dir] Change de répertoire courant. Si dir n'est pas fournis, la valeur de la variable HOME est le défaut. Tout argument additionnel après dir est ignoré. La variable CDPATH définis le chemin de recherche pour le répertoire contenant dir. Si dir commance par /, CDPATH n'est pas utilisé.

        -P cd utilis la structure de répertoire physique en résolvant les liens symboliques en traversant les répertoires et avant de traiter les instances de .. dans dir.
        -L Suis les liens symboliques et résolvant le lien après le traitement des instances de .. dans dir. Si .. apparaît dans dir, il est traité en supprimant le composant du path précédant.
        Avec -P, si le répertoire courant ne peut être déterminer après un changement de répertoire, cd va retourner une erreur.
        -@ Présente des attributs étendus associés avec un fichier comme répertoire.
        Un argument - est convertis en OLDPWD avant de tenter de changer de répertoire.

command [-pVv] command [arg ...] Lance la commande spécifiée en supprimant la recherche de fonction shell. Seuls les commande intégrée ou les commandes trouvées dans PATH sont exécutées. Si -p est donné, la recherche de la commande est effectuée en utilisant une valeur par défaut pour PATH qui garantit de trouver tous les utilitaires standards. Si -V ou -v est founis, une description de la commande est affiché. -v affiche la commande ou le nom du fichier. -V produit une description plus verbeuse. Si -V ou -v est founis, retourne une code de sortie de 0 si la commande a été trouvée, 1 sinon. Sans ces options, si une erreur s'est produite ou commande n'est pas trouvé, retourne 127. Dans tous les autres cas, retourne le codes de sortie de la commande.
compgen [option] [word] Génère les completions possibles pour le mot en accord avec les options spécifiées, qui peuvent être toutes options acceptées par la commande complete, sauf -p et -r, et écrit les matches sur stdout. En utilisant les options -F ou -C, les divers variables shell définies par la completion programmable, si disponible, n'auront pas de valeurs utiles. Les matches sont générés de la même manière que la completion programmable. Si un mot est spécifié, seul les completions matchant ce mot sont affichés. La valeur retournée est true sauf si une option est invalide, ou qu'aucun matche n'a été généré.
complete [-abcdefgjksuv] [-o comp-option] [-DE] [-A action] [-G globpat] [-W wordlist] [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] name [name ...]
complete -pr [-DE] [name ...] Spécifie comment les arguments de chaque nom devrait être complétés. Si -p est fournis, ou sans options, les spécifications de completion existantes sont affichées dans un format ré-utilisable. L'option -r supprime une spécification de completion pour chaque nom, ou, si aucun nom n'est fournis, toutes les spécifications de completion. L'option -D indique que les options et actions restantes devraient s'appliquer à la commande de completion par défaut; c'est à dire la completion tentée sur une commande pour laquelle aucune completion n'a été définie. L'option -E indique que les options et actions restantes devraient à la commande de completion vide, c'est à dire, la completion tentée sur une ligne vide.

   Les arguments de -G, -W, -X, et les options -P et -S devraient être quotés pour les protéger des expansions avant que complete soit invoqué.

        -o comp-option Contrôle divers aspects du mode de compspec au-delà de la simple générations des completions. comp-option peut être:

                bashdefault Effectue le reste des completion bash par défaut si compspec ne génère aucun match.
                default Utilise la completion par défaut de readline si compspec ne génère aucun match.
                dirnames Effectue une completion de nom de répertoire si compspec ne génère aucun match.
                filenames Dit à readline que compspec génère les noms de fichier, pour qu'il puisse effectuer tout traitement spécifique au noms de fichier (comme ajouter un / aux noms de répertoire, quoter les caractères spéciaux, ou supprimer les espaces restant). À utiliser avec les fonctions shell.
                noquote Dit à readline de ne pas quoter les mots complétés si ils sont des noms de fichier.
                nospace Dit à readline de ne pas ajouter un espace aux mots complétés à la fin de la ligne.
                plusdirs Après que tous les matches définis par le compspec aient été générés, tente la completion de noms de répertoire et tous les matches sont ajoutés au résultat des autres actions.

        -A action L'action peut être une des suivante peut générer la liste des completions possible:

                alias Noms d'alias. Peut aussi être spécifié par -a
                arrayvar Noms de variable tableau
                binding Noms de key binding readline
                builtin Noms des commandes intégrées. Peut aussi être spécifié par -b
                command Noms de commandes. Peut aussi être spécifié par -c
                directory Noms de répertoire. Peut aussi être spécifié par -d
                disabled Noms des builtins désactivés
                enabled Noms des builtins activés
                export Noms des variables shell exportés. Peut aussi être spécifié par -e
                file Noms de fichiers. Peut aussi être spécifié par -f
                function Noms des fonctions shell
                group Noms des groupes. Peut aussi être spécifié par -g
                helptopic Helptopic tels qu'accèptés par la commande help
                hostname Noms d'hôte, pris dans le fichier HOSTFILE
                job Noms de jobs, si le contrôle de job est actif. Peut aussi être spécifié par -j
                keyword Mots réservés du shell. Peut aussi être spécifié par -k
                running Noms des jobs lancés, si le contrôle de job est actif
                service Noms des services. Peut aussi être spécifié par -s
                setopt Arguments valides pour l'option -o de la commande set.
                shopt Noms d'options shell acceptés par la commande shopt
                signal Noms des signaux
                stopped Noms des jobs stoppés, si le contrôle de job est actif.
                user Noms des utilisateurs. Peut aussi être spécifié par -u
                variable Noms des variables shell. Peut aussi être spécifisé par -v

        -C command La commande est exécutée dans un environnement sous-shell, et sa sortie est utilisée comme completion possible.
        -F function La fonction shell est exécutée dans l'environnement du shell courant. Quand la fonction est exécutée, le premier argument est le nom de la commande dons les arguments sont à compléter, le second argument est le mot à compléter, et le troisième argument est le traitement de mot du mot à compléter sur la ligne courante. Une fois terminée, les completions possible sont récupérée depuis la valeur COMPREPLY.
        -G globpat Le motif d'expanion de pathname globpat est étendus pour générer les completions possible.
        -P prefix Le préfixe est ajouté au début de chaque completion possible après que toutes les options aient été appliquées.
        -W wordlist La liste de mot est splittée en utilisant IFS, et chaque mot résultant est étendu. Les completions possible sont les membre de la liste résultante qui matche le mot à compléter.
        -X filterpat Est un motif comme utilisé pour l'expansion de pathname. Il est appliqué à la liste des completions possible généré par les options et arguments précédents, et chaque completion matchant filterpat est supprimé de la liste. si filterpat commence par un !, le motif est inversé.

           La valeur de retour est true sauf si une option est invalide, un option autre que -p ou -r est fournie sans un argument nommé, une tentative de supprimer une spécification de completion pour un nom pour lequel aucune spécification n'existe, ou une erreur s'est produite en ajoutant une spécification de completion.

compopt [-o option] [-DE] [+o option] [name] Modifie les options de completion pour chaque name en accord avec les options, ou pour la completion actuellement exécutée si aucun nom n'est spécifié. Si aucune option n'est donnée, affiche les options de completion pour chaque nom ou la completion courante. Les options sont les même que pour la commande complete. Les options -D et -E ont la même signification que pour la commande complete. La valeur de retour est vraie sauf si une option est invalide, le nom n'a pas de spécification de completion, ou une erreur s'est produite.
continue [n] Passe à l'itération suivante dans une boucle for, while, until ou select. Si n est spécifié, passe à à l'itération suivante de la n-ième boucle. n doit être supérieur à 1. Si n est supérieur au nombre de boucles imbriquées, le boucle du haut est utilisée, La valeur retournée est 0 sauf si n n'est pas égal ou supérieur à 1.
declare [-aAfFgilnrtux] [-p] [name[=value] ...]
typeset [-aAfFgilnrtux] [-p] [name[=value] ...] Déclare des variable et/ou leur donne des attributs. Su aucun nom n'est donné, affiche les valeurs des variables.

        -p affiche les attributs et valeur de chaque nom. Utilisé avec name, les options additionnelles, autre que -f et -F, sont ignorés. Utilisé sans nom, il affiche les attributs et valeurs de toutes les variables ayant les attributs spécifiés par les options additionnelles. Si aucune autre option n'est fournis avec -p, declare va afficher les attribut et valeurs de toutes les variables shell.
        -f restreins d'affichage aux fonctions shell.
        -F inhibe l'affichage des définitions de fonction; seul les noms et attributs des fonctions sont affichés. Si l'option extdebug est active, le nom du fichier source le le numéro de ligne où est définis la fonction est affiché également. Implique -f
        -g Force les variables à être crées ou modifiées dans un scope global, même quand declare est exécuté dans une fonction shell.

           Les options suivantes peuvent être utilisée pour restreindre la sortie aux variables avec les attributs spécifiées, ou pour donner des attributs aux variables:

        -a Chaque nom est une variable tableau indexé
        -A Chaque nom est une variable tableau associatif
        -f Utilise les noms de fonction uniquement
        -i La variable est traitée comme un entier
        -l Convertis tous les caractères majuscule en minuscule lorsque la variable reçoit une valeur.
        -n  Donne à chaque nom l'attribut nameref, c'est à dire une référence à une autre variable. Toutes référence et assignement au nom, excepté pour changer l'attribut -n, sont effectué sur la variable référencée par la valeur du nom. Ne peut pas être appliquée aux variables tableau.
        -r Mode lecture seule. Il n'est plus possible d'assigner de nouvelles valeurs à ces noms
        -t Donne à chaque nom l'attribut trace. les fonction tracées héritent des trap DEBUG et RETURN du shell appelant. N'a pas de signification spéciale pour les variables.
        -u Convertis tous les caractères minuscule en majuscule lorsque la variable reçoit une valeur.
        -x Exporte les noms

   Utiliser + au lieu de - désactive l'attribut, à l'exception de +a qui ne peut pas être utilisé pour détruirs une variable tableau, et +r qui ne supprime par l'attribut lecture seule. Utilisé dans une fonction, declare et typeset rendent chaque nom local, comme avec la commande local, sauf si -g est fournis. Si un nom de variable est suivis par =value, la valeur de la variable est assignée. En utilisant -a ou -A et la syntaxe d'assignement composée pour créer des variables tableaux, les attributs additionnels ne prennent effet qu'après l'assignement. La valeur de retour est 0 sauf si une option invalide est rencontrée, si une fonction est définie avec -f foo=bar, une assignation à une variable lecture seule, une assignation de valeur à une variable tableau sans utiliser l'assignation composée, un noms n'est pas valide, tenter de désactiver l'attribut lecture seul, ou afficher une fonction qui n'existe pas avec -f.

dirs [-clpv] [+n] [-n] Sans options, affiche la liste des répertoires courant mémorisés. L'affichage par défaut est sur une seule ligne. Les répertoires sont ajoutés à la liste avec la commande pushd, popd pour les supprimer. La valeur de retour est 0 sauf si une option invalide est rencontrée, ou l'index n est au-delà de la pile de répertoire.

        -c Efface la pile de répertoires
        -l produit un listing en utilisant les chemin complets.
        -p Affiche la pile de répertoire, une entrée par ligne
        -v Affiche la pile de répertoire, une entrée par ligne, en préfixeant chaque entrée avec sont index dans la pile.
        +n Affiche la n-ième entrée en comptant depuis la gauche de la liste affichée par dirs invoqué sans options, en commençant à 0
        -n  Affiche la n-ième entrée en comptant depuis la droite de la liste affichée par dirs invoqué sans options, en commençant à 0

disown [-ar] [-h] [jobspec ...] Sans options, supprime chaque jobspec de la table des jobs actifs. Si jobspec n'est pas présent et que -a et -r ne sont pas fournis, le job courant est utilisé. Si -h est donné, chaque jobspec nqest pas supprimé de la table, mais est marqué pour que SIGHUP ne soit pas envoyé au job si le shell reçoit ce signal. Si aucun jobspec n'est fournis, -a signifie de supprimer ou marquer tous les jobs et -r restreins l'opération aux jobs lancés. La valeur de retour est 0 sauf si un jobspec n'est pas un job valide.
echo [-neE] [arg ...] Affiche les arguments, séparés par des espaces, suivis par une nouvelle ligne. Le code de retour est 0 sauf si une erreur d'écriture s'est produite. echo n'interprète par --

        -n  n'ajoute pas de nouvelle ligne à la fin
        -e  Interprète les caractère échappés
        -E  Désactive l'interprétation les caractères échappés, même sur les système où ils sont interprétés par défaut. L'option shell xpg_echo peut être utilisée pour déterminer dynamiquement si echo étend les caractères échappés par défaut.

           echo interprète les séquences échappées suivantes:

        \a alerte
        \b BACKSPACE
        \c n'affiche pas la suite
        \e, \E Un caractère échappe
        \f form feed
        \n NEWLINE
        \r retour charriot
        \t tabulation horizontale
        \v taulation verticale
        \\ \
        \0nnn Le caractère 8-bits dont la valeur est nnn en octal
        \xHH Le caractère 8-bits dont la valeur est HH en hexadécimal
        \uHHHH Le caractère Unicode (ISO/IEC 10646) dont la valeur est HHHH en hexadécimal.
        \UHHHHHHHH Le caractère Unicode (ISO/IEC 10646) dont la valeur est HHHHHHHH en hexadécimal.

enable [-a] [-dnps] [-f filename] [name ...] Les commandes enable et disable. Désactiver une commande intégrée permet à une commande qui a le même nom d'être exécutée sans spécifier un pathname complet. La valeur de retour est 0 sauf si nom n'est pas une commande intégrée, ou s'il y a une erreur au chargement d'un objet partagé.

        -n  chaque nom est désactivé, sinon, chaque nom est activé.
        -f Permet de charger la nouvelle commande intégrée depuis le fichier objet partagé, sur les système qui supportent le chargement dynamique.
        -d Supprime une commande intégrée précédemment chargée avec -f.
        -p Liste les commandes intégrées. Sans autre arguments, les toutes les options actives, avec -n, affiche uniquement les commande désactivées.
        -a Liste toutes les commandes intégrées, en spécifiant si elles sont activées ou non.
        -ss La sortie est restreinte aux commandes spéciales POSIX.

eval [arg ...] Les arguments sont lus et concaténés en une commande simple. Cette commande est ensuite lue et exécutée par le shell, et son code de sortie est la valeur retournée par eval. S'il n'y a par d'argument, ou seulement un argument null, eval retourne 0.
exec [-cl] [-a name] [command [arguments]] Si la commande est spécifiée, elle remplace le shell. Aucun nouveau processus n'est créé. Les arguments deviennent les arguments de la commande. Si l'option -l est spécifiée, le shell place un tiret au début de l'argument 0 passé à la commande. C'est ce que login fait. L'option -c exécute la commande avec un environnement vide. -a passe le nom en tant qu'argument 0 à la commande. Si la commande ne peut pas être exécutée, un shell non-interactif se termine, sauf si l'option execfail est actif. Dans ce cas, exec retourne une erreur. Si la commande n'est pas spécifiée, toute redirection prend effet dans le shell courant, et retourne 0. S'il y une erreur de redirection, retourne 1.
exit [n] Le shell se termine avec le code de sortie n. Si n est omis, le code de sortie est celui de la dernière commande exécutée. Un trap sur EXIT est exécuté avant que le shell se termine.
export [-fn] [name[=word]] ...
export -p Les noms fournis sont exportés automatiquement dans l'environnement des commandes exécutées. Si l'option -f est fournis, les mons réfèrent à des fonctions. Si aucun nom n'est donné, ou si l'option -p est fournis, une liste de toutes les variables exportées est affichée. L'option -n supprime la propriété export pour chaque nom. Si un nom de variable est suivi par =word, la valeur lui est assignée. export retourne un code de sortie 0 sauf si une option invalide est rencontrée, un des noms n'est pas une variable shell valide, ou -f est fournis avec un nom qui n'est pas une fonction.
fc [-e ename] [-lnr] [first] [last]
fc -s [pat=rep] [cmd] La forme first sélectionne une plage de commandes de first à last dans la liste d'historique est l'affiche ou l'édite, et les ré-exécute. first et last peuvent être spécifiés comme chaîne (pour localiser la dernière commande commençant avec cette chaîne) ou un nombre (un index dans la liste d'historique, où un nombre négatif est utilisé depuis le numéro de commande courant) Si last n'est pas spécifié, il est définis à la commande courante (donc fc -l -10 affiche les 10 dernières commandes) et à first sinon. Si first n'est pas spécifié il est définis à la commande précédente pour l'édition, et f -16 pour l'affichage.

        -n  Supprime les numéros de commande lors de l'affichage.
        -r Inverse l'ordre des commandes
        -l Les commandes sont listées sur stdout.

           Sinon l'éditeur donné par ename est invoqué sur un fichier contenant les commandes.Si ename n'est pas spécifié, utilise dans l'ordre, FCEDIT ou EDITOR (défaut: vi). Quand l'édition est terminée, les commandes éditées sont exécutées.

  Dans la seconde forme, la commande est ré-exécutée après que chaque instance de pat ait été remplacée par rep. La commande est interprétée de la même manière que first. Un alias utle à utiliser avec ça est r="fr -s", donc en taper r cc, lance la dernière commande commençant avec cc et taper r re-exécute la dernière commande.

           Si la première forme est utilisée, la valeur de retour est 0 sauf si une option invalide est rencontrée, ou first ou last spécifient des lignes d'historique hors plage. Si l'option -e est fournis, la valeur de retour est la valeur de la dernière commande exécutée ou une erreur si une erreur s'est produite avec le fichiers de commandes temporaire. Si la seconde forme est utilisée, le code de retour est celle de la commande ré-exécutée, sauf si la commande ne spécifie pas une ligne d'historique valide.

fg [jobspec] Met jobspec en tâche courante. Si jobspec n'est pas présent, la notion shell de job courant est utilisé. La valeur de retour est celle de la commande placée en foreground, ou une erreur si le contrôle de job est désactivé ou si jobspec ne spécifie pas de job valide ou un job qui a été lancé sans contrôle de job.
getopts optstring name [args] Utilisé par les procédures shell pour parser les paramètres positionnels. optstring contient les caractères d'option à reconnaitre; si un caractère est suivi par une virgule, l'option est supposé avoir un argument, qui devrait être séparé par un espace. Les caractères , et ? ne peuvent pas être utilisés comme caractère d'option. chaque fois qu'il est invoqué, getopts place la prochaine option dans la variable chaîne name, et index le prochaine argument à traiter dans la variable OPTIND. OPTIND est initialisée à 1 chaque fois que le shell ou un script shel est invoqué. Quand une option nécessite un argument, getopts place ect argument dans la variable OPTARG. Le shell ne réinitialise pas OPTIND automatiquement.

           Quand la fin des options est rencontrée, getopts se termine avec une valeur de retour supérieur à 0. OPTIND est définis à l'index du premier argument non-option, et name est définis à ?. getopts parse normalement les paramètres positionnels, mais si plus d'un argument est donné en argument, getopts les parse à la place.

           getopts peut reporter les erreurs de 2 manières. Si le premier caractère de optstring est une virgule, une erreur silencieuse est utilisée. Dans une opération normale, les messages de diagnostique sont affichés quand une option invalide ou manquante est rencontrée. Si la variable OPTERR est à 0, aucun messages d'erreur ne sera affiché, même si le premier caractère de optstring n'est pas une virgule.

           Si une option invalide et trouvée, getopts place un ? dans name et, si non silencieux, affiche un message d'erreur et réinitialise OPTARG. Si getopts est silencieux, le caractère option trouvé est placé dans OPTARG et aucun message n'est affiché.

           Si un argument requis n'est pas trouvé, et non silencieux, un ? est placé dans name, OPTARG est réinitialisé, et un message d'erreur est affiché. Si silencieux, : est placé dans name ,t OPTARG est définis au caractère trouvé.

           getopts retourne vrai si une option, spécifiée ou non spécifiée, est trouvée. Retourne false si la fin des options est rencontrée ou une erreur s'est produite.

hash [-lr] [-p filename] [-dt] [name] Chaque fois que hash est invoqué, le chemin complet de la commande est déterminée en recherchant les répertoires dans PATH et mémorisé. Tout chemin précédemment mémorisé est supprimé. -p ne recherche pas les répertoires, name est utilisé comme chemin complet. -r oubli tous les emplacements mémorisés. -d oublie l'emplacement mémorisé pour chaque nom. -t affiche le chemin pour chaque nom fournis. -l affiche la sortie dans un format réutilisable. Le statut de retour est true sauf si name n'est pas trouvé, ou une option est invalide.
help [-dms] [pattern] Affiche des information d'aide sur les commandes intégrées. Si pattern est spécifié, donne une aide détaillée sur toutes les commandes qui matchent ce pattern; sinon affiche l'aide pour toutes les commandes intégrées. Le code de retour est 0 sauf si aucune commande ne matche pattern.

        -d Affiche une description courte de chaque pattern
        -m Affiche la description de chaque pattern dans un format style manpage
        -s Affiche uniquement le synopsis pour chaque pattern

history [n]
history -c
history -d offset
history -anrw [filename]
history -p arg [arg ...]
history -s arg [arg ...] Sans options, affiche la liste numérotée d'historique de commande. Les lignes listées avec un * ont été modifiées. Un argument de n liste uniquement les dernières n lignes. Si la variable shell HISTTIMEFORMAT est définie et non null, elle est utilisé comme chaîne de formatage pour strftime(3) pour afficher le timestamp associé avec chaque entrée d'historique affichée. Si filename est fournis, il est utilisé comme nom de fichier d'historique; sinon, la valeur de HISTFILE est utilisé.

        -c Effache la liste d'historique
        -d offset Supprime l'entrée d'historique à la position donnée
        -a Ajoute les nouvelles lignes d'historique (les lignes entrées depuis le début de la session bash courante) au fichier d'historique.
        -n  Lit les lignes d'historique pas encore lues du fichier d'historique dans la liste d'historique courante.
        -r Lit le contenu du fichier d'historique et l'ajoute à la liste d'historique courante.
        -w Écrit le liste d'historique courante dans le fichier d'historique, en écrasant le contenu du fichier d'historique
        -p Effectue une substitution d'historique sur les arguments fournis et affiche le résultat. Ne stocke pas le résultat dans la liste d'historique. Chaque argument doit être quoté pour désactiver l'expansion d'historique normal.
        -s Stocke les arguments dans la liste d'historique en une seule entrée. La dernière commande dans la liste d'historique est supprimée avant que les arguments soient ajoutés.

           Si la variable HISTTIMEFORMAT est définie, les informations de timestamp associés avec chaque entrée d'historique est écrit dans le fichier d'historique, marqués avec le caractère de commentaire d'historique. Quand le fichier d'historique est lu, les lignes commançant avec ce caractère suivis immédiatement par un chiffre sont interprétés comme timestamp pour la ligne d'historique précédente. La valeur de retour est 0 sauf si une option invalide est rencontrée, une erreur s'est produite en lisant ou écrivant dans le fichier d'historique, un offset invalide ou l'expansion d'historique fournis avec -p échoue.

jobs [-lnprs] [ jobspec ... ]
jobs -x command [ args ... ] La première forme liste les jobs actifs. Si jobspec est donné, la sortie est restreinte aux informations sur ce job. Le code de retour est 0 sauf si une option invalide est rencontrée ou un jobspec invalide est fournis.

        -l Liste les ID des processus
        -n  Affiche des informations uniquement sur les jobs qui ont changés de status depuis la dernière notification de status reçu par l'utilisateur.
        -p Liste uniquement les process ID des process group leader des jobs.
        -r Affiche uniquement les jobs lancés
        -s Affiche uniquement les jobs stoppés
        -x Remplace tout jobspec trouvé dans la commande ou les arguments avec les process group ID correspondant, et exécute la commandes, retournant son codes de sortie.

kill [-s sigspec | -n signum | -sigspec] [pid | jobspec] ...
kill -l [sigspec | exit_status] Envoie le signal sigspec ou signum aux processus nommés par pid ou jobspec. Si sigspec n'est pas présent, envoie SIGTERM. -l liste les noms des signaux. Si un des argument est donné avec -l, liste les signaux correspondant. Le code de sortie de -l est un nombre décrivant soit le numéro du signal, ou le code de sortie d'un process terminé par un signal. Retourne vrai si au moins un signal a été envoyé avec succès, ou faux si une erreur s'est produite ou une option invalide est rencontrée.
let arg [arg ...] Chaque argument est une expression arithmétique à évaluer. Si le dernier argument évalue à 0, let retourne -1; 0 sinon.
local [option] [name[=value] ...] Permet de créer des variables locales. Les options sont les mêmes que celles acceptées par declare. Sans opérandes, local affiche la liste des variables locales. Retourne 0 sauf si local est utilisé en dehors d'un fonction, un nom est invalide, ou name est une variable lecture seule.
logout Quitte le login shell
mapfile [-n count] [-O origin] [-s count] [-t] [-u fd] [-C callback] [-c quantum] [array]
readarray [-n count] [-O origin] [-s count] [-t] [-u fd] [-C callback] [-c quantum] [array] Lis les lignes depuis l'entrée standard dans le tableau indexé array, ou depuis le descripteur de fichier fd si -u est fournis. La variable MAPFILE est le tableau par défaut.

        -n  Copie au maximum count ligne. Si count vaut 0, toutes les lignes sont copiées.
        -O Commence à assigner le tableau là l'index origin. Défaut: 0
        -s Ne tient pas compte des count premières lignes lues
        -t Supprime les newline de fin de chaque ligne lues
        -u Lit les lignes depuis le descripteur de fichier fd au lieu de l'entrée standard
        -C Évalue callback chaque fois que quantum lignes sont lues.
        -c Le quantum. Spécifie le nombre de lignes lues entre chaque appel callback

           Si -C est spécifié sans -c, le quantum par défaut est 5000. Quand callback est évalué, il reçoit l'index du prochain élément du tableau à assigner et la ligne à assigner à cette élément comme argument. callback est évalué après que la ligne soit lue, mais avant l'assignation. Si l'origine n'est pas fournis, mapfile efface le tableau avant de l'assigner. mapfile retourne un succès sauf si une option invalide est rencontrée ou un argument option est fournis, le tableau est invalide ou non assignable, ou si le tableau n'est pas un tableau indexé.

popd [-n] [+n] [-n] Supprime les entrées de la pile de répertoires. Sans arguments, supprime le haut de la pile, et effectue un cd dans le nouveau répertoire top. Si la commande réussie, un dirs est effectué et le code de retour est 0. popd retourne false si une option invalide est rencontrée, la pile de répertoire est vide, une entrée de pile n'existe pas ou le changement de répertoire échoue.

        -n  Supprime le changement de répertoire lors de la suppression des répertoires dans la pile, seul la pile est manipulée.
        +n Supprime la n-ième entrée dans la liste, en comptant de gauche à droite comme affiché par dirs, en commençant à 0
        -n  Supprime la n-ième entrée dans la liste, en comptant de droite à gauche comme affiché par dirs, en commençant à 0

printf [-v var] format [arguments] Écrit les argument formatés en utilisant le format spécifié. L'option -v assigne la sortie à la variable au lieu de l'afficher sur stdout. Le format est une chaîne de caractères qui contient 3 types d'objects: Des caractères normaux qui sont simplements copiés sur la sortie, des séquences de caractères échappés, et des spécification de format, chacun affichant l'argument suivant. En plus des spécification de format de printf(1), printf interprète les extensions suivantes:

        %b Étend les séquences échappées dans l'argument correspondant, excepté que \c termine la sortie, \', \" et \? ne sont pas supprimés, et les échappement octal commençant avec \0 peuvent contenir jusqu'à 4 chiffres.
        %q Affiche l'argument correspondant dans un format réutilisable en entrée.
        %(datefmt)T Affiche la chaîne de date résultante en utilisant datefmt comme format de chaîne pour strftime(3). L'argument correspondant est un entier représentant le nombre de seconde depuis l'epoch. 2 arguments spéciaux peuvent être utilisés: -1 représente le temps courant, et -2 représente l'heure d'invocation du shell. Sans arguments, utilise -1.

           Les arguments pour des spécifieurs de format non-chaîne sont traités comme des constantes C, excepté qu'un signe + ou - est permis, et si ce caractère est un quote simple ou double, la valeur est la valeur ASCII du caractère suivant. Le format est réutilisé si nécessaire pour consommer tous les arguments. Si le format requière plus d'arguments que fournis, les spécifications restantes se comporte comme si une valeur 0 ou une chaîne null avait été fournis. La valeur de retour est 0 sauf en cas d'erreur.

pushd [-n] [+n] [-n]
pushd [-n] [dir] Ajoute un répertoire au-dessus de la pile de répertoire, ou fait tourner la pile pour que le répertoire de travail courant soit en haut de la pile. Sans arguments, échange les 2 répertoires du haut de la pile et retourne 0, sauf si la pile est vide. Si la première forme est utilisée, pushd retourne 0 sauf si cd échoue. Avec la forme suivante, pushd retourne 0 sauf si la pile est vide, en élément de la pile n'existe pas, ou le changement de répertoire échoue.

        -n  Ne change pas de répertoire, n'agit que sur la pile.
        +n Tourne la pile pour que le n-ième répertoire (en comptant de gauche à droite comme affiché par dirs) soit en haut de la pile.
        -n  Tourne la pile pour que le n-ième répertoire (en comptant de droite à gauche comme affiché par dirs) soit en haut de la pile.
        dir Ajoute le répertoire à la pile, puis effectue un cd sur ce répertoire.

pwd [-LP] Affiche le chemin absolue du répertoire de travail courant. Ce chemin est affiché sans liens symbolique si -P est fournis, ou si l'option -o physical est activée. L'option -L permet d'afficher les chemin avec des liens symboliques. Le status de retour est 0 sauf si une erreur s'est produite en lisant le répertoire courant, ou une option invalide est fournie.
read [-ers] [-a aname] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...] Une ligne est lue depuis l'entrée standard, ou depuis le descripteur de fichier fournis, et le premier mot est assignée au premier nom, le second au deuxième, etc, le dernier nom contient tous les mots restants. S'il à moins de mots que de nom, les noms en trop sont vides. IFS est utilisé pour séparer les mots en utilisant les mêmes règles que le shell pour les expansions. Le \ peut être utilisé pour supprimer toute signification spéciale du prochain caractère lu.

        -a aname Les mots sont assignés aux indices séquentiels du tableau aname, en commençant à 0. aname est ré-initialisé avant d'assigner les nouvelles valeurs. les autres noms sont ignorés.
        -d delim Le premier caractère est utilisé pour terminer la ligne d'entrée, au lieu d'une nouvelle ligne.
        -e  Si l'entrée standard vient du terminal, readline est utilisé pour obtenir la ligne. readline utilise les paramètre d'édition courants.
        -i text Si readline est utilisé pour lire la ligne, le texte est placé dans le tampon d'édition avant que l'édition commence.
        -n nchars retourne après que nchars caractères aient été lus, mais honore les délimiteurs
        -N nchars retourne après que nchars caractères aient été lus, sauf si EOF est rencontré. N'honore pas les délimiteurs.
        -p prompt Affiche le prompt sur l'erreur standard, sans newline final, avant de tenter de lire l'entrée. Le prompt est affiché uniquement si l'entrée provient du terminal.
        -r les \ n'agissent pas comme caractère d'échappement.
        -s Mode silencieux. Si l'entrée vient du terminal, les caractère ne sont pas répétés.
        -t timeout délai en seconde avant que read ne termine et retourne une erreur si l'entrée n'est pas complète. timeout peut être un nombre décimal avec une portion fractionnelle. Effectif uniquement si c'est l'entrée standard, un pipe, ou un fichier spécial; il n'a pas d'effet en lisant un fichier régulier. Si le timeout est atteind, la ligne d'entrée partielle est sauvée dans lu variable name. Si timeout est 0, retourne immédiatement, sans tenter de lire une donnée. Le statut de sortie est 0 si l'entrée est disponible sur le descripteur de fichier, Un statut de sortie de 128 pour un timeout atteind.
        -u fd Lis l'entrée depuis le descripteur donné

           Si aucun nom n'est donné, la ligne lue est assignée à la variable REPLY. Le code de retour est 0, sauf si EOF est rencontré, le timeout est atteind, une erreur lors de l'assignememt de variable ou un descripteur de fichier est invalide.

readonly [-aAf] [-p] [name[=word] ...] Les noms donnés sont marqués en lecture seule; les valeurs de ces noms ne peuvent plus être changés. Le statut de retour est 0 sauf si une option invalide est rencontrée, un des noms n'est pas une variable shell, ou -f est fournis avec une variable qui n'est pas une fonction.

        -f Les fonctions correspondantes sont également marquées.
        -a restreint les variables aux tableaux indexés
        -A Restreint es variables aux tableaux associatif. Si -a est également fournis, -A a précédence.
        -p Si aucun nom n'est fournis ou si -p est spécifié, liste toutes les variables lecture seule dans un format réutilisable.

return [n] Stop l'exécution d'une fonction et retourne la valeur spécifiée par n à son appelant. Si n est omis, retourne le status de la dernière commande exécutée. Si return est utilisé en dehors d'une fonction, mais durant l'exécution d'un script par la commande . (source), le shell stop l'exécution du script. Si n est fournis, la valeur de retour sont les 8bits de poid faible de n. Le status de retour est non-zéro si return est founis avec un argument non-numérique, ou est utilisé hors d'une fonction ou d'un script lancé par .. Toute commande associée avec le trap RETURN est exécuté avant de terminer la fonction ou le script.
set [--abefhkmnptuvxBCEHPT] [-o option-name] [arg ...]
set [+abefhkmnptuvxBCEHPT] [+o option-name] [arg ...] Sans options, le nom et la valeur de chaque variable shell sont affichés dans une format réutilisable. Les variables lecture seul ne peuvent pas être ré-initialisées. En mode posix, seul les variables shell sont listées.a sortie est triée en accord avec la locale courante. Quand des options sont spécifiées, elles définissent ou indéfinissent des attributs du shel. Tous arguments restant après le traitement des options sont traités comme valeurs pour les paramètres positionnels et sont assignés dans l'ordre, de $1, $2, ..., $n.

        -a Marque automatiquement les variables en fonctions qui sont modifiés ou créés en export.
        -b Reporte le statut des jobs de fond terminés immédiatement, et non avant le prochain prompt primaire. C'est effectif uniquement si le contrôle de job est actif.
        -e  Quitte immédiatement si un pipe (que peut consister d'une simple commande), une liste, ou une commande composée fait partie de la liste de commande immédiatement suivant un while ou until, fait partie du test suivant un if ou elif, fait partie d'une commande exécutée dans un && ou || excepté la commande suivant le && ou le || final, une commande dans un pipeline sauf le dernier, ou si la valeur de retour de la commande est inversée avec !. Si une commande composée autre qu'un sous-shell retourne un statut non-zéro à cause d'une commande échouée alors que -e était ignoré, le shell ne se termine pas. Un trap sur ERR est exécuté avant que le shell se termine. Cette option s'applique à l'environnement shell et chaque sous-environnement, et peut terminer les sous-shell avant d'exécuter toutes les commandes dans le sous-shell.

           Si une commande composée ou une fonction shell est exécutée dans un contexte où -e est ignoré, aucune commande exécutée dans la commande composée ou la fonction ne sera affectée par le paramètre -e, même si -e est définis et qu'une commande retourne un statut d'échec. Si une commande composée ou une fonction shell définie -e durant l'exécution dans un contexte où -e est ignoré, ce paramètre n'aura aucun effet tant que la commande composée ou la commande contenant l'appel de la fonction ne soit terminée.

        -f Désactive l'expansion de pathname
        -h Mémorise l'emplacement des commandes comme si elles étaient recherchées pour exécution. Activé par défaut.
        -k Tous les arguments dans la forme de déclaration d'assignement sont placés dans l'environnement pour une commande, pas seulement ceux qui précède le nom de la commande.
        -m Mode monitor. le contrôle de job est activé. Cette option est activée par défaut pour les shells interactifs sur les systèmes qui le supporte. Tous les processus sont lancés dans un groupe de processus séparés. Quand un job de fond se termine, le shell affiche un ligne contenant son code de sortie.
        -n  Lit les commandes mais ne les exécute pas. Peut être utilisé pour vérifier les erreurs de syntaxe des scripts shell. Ignorés par les shells interactifs.
        -o option-name Si option-name n'est pas fournis, les valeurs des options courantes sont affichées. si +o est fournis sans option-name, une série de commandes set pour recréer les paramètres courants est affiché sur stdous. Les options peuvent être les suivantes:

                allexport Idem à -a
                braceexpand Iden à -B
                emacs Utilise une interface d'édition de ligne de commande de style emacs. Activé par défaut quand le shell est interactif, sauf si le shell est lancé avec l'option --noediting. Affecte également l'interface d'édition pour read -e
                errexit Idem à -e
                errtrace Idem à -e
                functrace Idem à -T
                hashall Idem à -h
                histexpand Idem à -H
                history Active l'historique de commandes. Actif par défaut pour les shells interactifs.
                ignoreeof Idem à la commande shell IGNOREEOF=10
                keyword Idem à -k
                monitor Idem à -m
                noclobber Idem à -C
                noexec Idem à -n
                noglob Idem à -f
                nolog Actuellement ignoré
                notify Idem à -b
                nounset Idem à -u
                onecmd Idem à -t
                physical Idem à -P
                pipefail Si définis, la valeur de retour d'un pipeline est la valeur de la dernière commande avec un statut de sortie non-zéro, ou 0 si toutes les commandes ont réussies. Désactivé par défaut.
                posix bash passe en mode posix
                privileged Idem à -p
                verbose Idem à -v
                vi Utilise une interface d'édition de ligne de commande style vi. Affecte également l'interface d'édition utilisé pour read -e
                xtrace Idem à -x

        -P Passe en mode privilégié. Dans ce mode, les fichiers ENV et BASH_ENV ne sont pas traités, les fonctions shell n'héritent pas de l'environnement, les variables SHELLOPTS, BASHOPTS, CDPATH et GLOBIGNORE sont ignorées. Si le shell est lancé avec le user/group ID effectif différent du user/group id réel, et que l'option -p n'est pas fournie, le user id effectif est mis au user id réel. Si l'option -p est fournis au lancement, le user id effectif n'est pas réinitialisé. Désactiver cette option cause les user/group id effectifs à être définis comme user/group id réels.
        -t Quitte après avoir lu et exécuté une commande.
        -u Traite les variables et paramètres non-définis autre que les paramètres spéciaux @ et * comme des erreurs lors de l'expansion de paramètres. Si l'expansion est tenté sur un paramètre ou une variable non-définie, le shell affiche un message d'erreur, et, si non-interactif, quitte avec un code de retour non-zéro.
        -v Affiche les lignes lues
        -x Après chaque expansion d'une commande simple, d'une commande for, case, select, ou une commande for arithmétique, affiche la valeur étendue de PS4, suivi par la commande et ses arguments étendus.
        -B Le shell effectue l'expansion d'accolade. Activé par défaut.
        -C Si définis, bash n'écrase pas les fichiers existants avec , ›&, et ‹›. On peut toujours écraser les fichiers en créant des fichiers avec ›| au lieu de .
        -E  Si définis, un trap sur ERR est hérité par les fonctions, substitutions de commandes, et les commandes exécutées dans en environnement sous-shell. le trap ERR n'est normalement pas hérités dans de tels cas.
        -H Active la subsitution d'historique de commande avec !. Activé par défaut pour les shells interactifs.
        -P Si définis, le shell ne résoud pas les liens symboliques en exécutant les commandes telles que cd. Il utilise la structure de répertoire physique à la place. Par défaut, bash suit les liens.
        -T Si définis, un trap sur DEBUG et RETURN est hérité par les fonctions, substitutions de commandes, et les commandes exécutées dans en environnement sous-shell. Ces trap ne sont normalement pas hérités dans de tels cas.
        -- Si aucun argument ne suit cette option, les paramètres positionnels sont indéfinis. Sinon, les paramètres positionnels sont définis avec les arguments, même si certain d'entre eux commencent par -.
        Signal la fin des options, tous les arguments restants sont assignés aux paramètres positionnels. -x et -v sont désactivés. S'il n'y a aucun argument, les paramètres positionnels restent inchangés

           Les options sont désactivées par défaut, sauf mention. Utiliser + au lieu de - désactive l'option. Les options peuvent également être spécifiées à l'invocation du shell. Le jeu d'options courant peut être trouvé dans $-. Le code de retour est toujours vrai sauf si une option invalide est rencontrée.

shift [n] Les paramètres positionnels de n+1 ... sont renommés en $1 ... Les paramètres représentés par les nombres $# décroissant à $#-n+1 sont indéfinis. n doit être un nombre non-négatif inférieur ou égal à $#. Si n vaut 0, aucun paramètre n'est changé. Si n n'est pas donné, il est assumé 1. Si n est supérieur à $#, les paramètres positionnels ne sont pas changés. Le status de retour est supérieur à 0 si n est supésieur à $# ou inférieur à 0.
shopt [-pqsu] [-o] [optname ...] Active/désactive les paramètres contrôlant le fonctionnement du shell. Ces paramètres peuvent être ceux listés ci-dessous, ou, si -o est donné, ceux disponible avec set -o. Sans options ou avec -p, affiche la liste de tous les paramètres définissable, indiquant s'il sont actif ou non. -p affiche dans un format réutilisable.

        -s Active chaque optname
        -u Désactive chaque optname
        -q Mode silencieux. Le status de retour indique si optname est définis ou non. Si plusieurs optname sont fournis, retourne 0 si tous les optnames sont activés.
        -o Restreins les valeurs de optname à celles définis pour la commande set -o

           Si -s ou -u est utilisé sans optname, shopt affiche uniquement les options qui sont définies ou non. Sauf mention, les options de shopt sont désactivées par défaut. les options shopt sont:

        autocd Un nom de commande qui est le nom d'un repertoire est exécuté comme si elle était un argument de cd. Uniquement pour les shells interactifs.
        cdable_vars Un argument de la commande cd qui n'est pas un répertoire est assumé être le nom d'un variable contenant un répertoire.
        cdspell Les erreurs mineur dans les arguments de la commande cd sont corrigés. Il s'agit des caractères transposés, un caractère manquant, un caractère en trop. Si une correction est trouvée, le nom du fichier corrigé est affiché, et la commande est traitée. Uniquement pour les shells interactifs.
        checkhash Vérifie qu'une commande trouvée dans la table de hash existe avant de tenter de l'exécuter. Si un hash d'une commande n'est pas trouvée, une recherche normale est effectuée.
        checkjobs Liste le statut des jobs lancés et stoppés avant de quitter un shell interactif. Si un job est lancé, la sortie est différée jusqu'à un nouveau exit. Le shell rapporte toujours si des jobs sont stoppés.
        checkwinsize Vérifie toujours la taille de la fenêtre après chaque commande, et, si nécéssaire, met à jour LINES et COLUMNS.
        cmdhist Tente de sauver toutes les lignes d'un commande sur plusieurs lignes dans la même entrée d'historique.
        compat31 Bash change son comportement à la version 3.1 en respectant les arguments quotés de la commande conditionnelle [[ de l'opérateur = et les comparaisons de chaîne spécifique au locale en utilisant les opérateurs et des commandes conditionnelles [[. Les versions de bash avant 4.1 utilisent le classement l'assemblage ASCII et strcmp(3); bash 4.1 et + utilisent la séquence d'assemblage du locale et strcoll(3).
        compat32 Bash change son comportement à la version 3.2 en respectant les comparaisons de chaîne spécifique au locale en utilisant les opérateurs et de la commande conditionnelle [[.
        compat40 Bash change son comportement à la version 4.0 en respectant les comparaisons de chaîne spécifique au locale en utilisant les opérateurs et de la commande conditionnelle [[. et l'effet de l'interruption d'un liste de commande. Bash 4.0 et + interrompt la liste comme si le shell reçoit l'interruption.
        compat41 Bash, en mode posix, traite un simple quote dans une expansion de paramètre double-quoté comme un caractère spécial.
        compat42 Bash ne traite par les chaînes de remplacement dans la substitution de motif de l'expansion de mot en utilisant la suppression de quote.
        complete_fullquote Bash quote tous les métacaractères shell dans les noms de fichier et répertoire en effectuant les completions. Si non définis, bash supprime tous les métacaractères tel que $ du jeu de caractères qui seront quotés dans les noms de fichier complétés quand ces métacaractères apparaissent dans le références de variable shell dans les mot à compléter. Cela signifie que le signe dollar dans les noms de variable qui s'étendent à des repertoires ne seront pas quotés. Cependant, un signe dollar apparaissant dans les noms de fichier ne seront pas quotés. Activé par défaut.
        direxpand Remplace les noms des répertoires avec le résultat de l'expansion de mot lors des completions de pathname. Cange le contenu du tampon d'édition de readline. Non définis, bash tente de préserver ce qui a été tapé.
        dirspell Tente de corriger les noms de répertoires durant la completion de mot si le nom du répertoire initial n'existe pas.
        dotglob Inclus les noms de fichier commençant avec un . dans le résultat de l'expansion de pathname.
        execfail Un shell non-interactif ne se terminera pas s'il ne peut pas exécuter le fichier spécifié en argument de la commande exec. Un shell interactif ne qui jamais dans ce cas.
        expand_aliases Les alias sont étendus. Activé par défaut pour les shells interactifs
        extdebug Utilisé pour les débuggeurs:

                1. L'option -F de la commande declare affiche le nom du fichier source et le numéro de ligne correspondant à chaque nom de fonction fournis en argument.
                2. Si la commande lancé par le trap DEBUG retourne une valeur non-zéro, la prochaine commande est sauté et non exécutée.
                3. Si la commande lancé par le trap DEBUG retourne la valeur 2 et que le shell est exécuté dans une sous-routine (une fonction shell ou un script shell exécuté par . ou source), un appel à return est simulé.
                4. BASH_ARGC et BASH_ARGV sont mis à jours.
                5. Le tracing de fonction est activé: la substitution de commande, les fonctions shell, et les sous-shell invoqués avec ( commande ) héritent des traps DEBUG et RETURN.
                6. Le tracing d'erreur est activé: la substitution de commande, les fonctions shell, et les sous-shell invoqués avec ( commande ) héritent du trap ERR.

        extglob Les fonctionnalités de correspondance de motif étendu décrites dans Expansion de chemin sont activées
        extquote $'string' et $"string" sont effectués dans les expansion ${parameter} enfermés dans les guillemets double. Activé par défaut.
        failglob Les motif qui échouent les correspondance de nom de fichier créer une erreur d'expansion.
        force_fignore Les suffixes spécifiés par FIGNORE forcent les mots à être ignorés lors de l'expansion de mot même si les mots ignorés sont les seules completions possible. Activé par défaut.
        globasciiranges Les expressions de plage utilisés dans les expressions entre accolade de pattern matching fonctionnent comme dans la locale traditionnelle C lors des comparaisons. Donc b ne sera pas assemblé entre A et B, et les caractères ASCII minuscules et majuscule ne seront pas assemblé ensemble.
        globstar le pattern ** utilisé dans l'expansion de pathname va matcher tous les fichiers et 0 ou plusieurs répertoires et sous-répertoires. Si le pattern est suivi par un /, seul les répertoires et sous-répertoires matchent.
        gnu_errfmt Les messages d'erreurs du shell sont écrits au format des messages d'erreurs standard GNU.
        histappend La liste d'historique est ajoutée au fichier nommé par HISTFILE quand le shell quitte, au lieu d'écraser le fichier.
        histreedit Si readline est utilisé, un utilisateur a l'opportunité de ré-éditer une substitution d'historique échouée.
        histverify Si readline est utilisé, le résultat de la substitution d'historique n'est pas passé immédiatement au parser du shell. À la place, la ligne résultante est chargée dans le tampon d'édition de readline, permettant d'autres modifications.
        hostcomplete Si readline est utilisé, bash tente d'effectuer une completion de nom d'hôte quant un mot contient @. Activé par défaut.
        huponexit Tente d'envoyer SIGHUP à tous les jobs quand le login shell intéractif se termine.
        interactive_comments Permet à un mot commençant avec # de forcer ce mot et tous les caractères restant sur la ligne à être ignoré dans le shell intéractif. Activé par défaut.
        lastpipe Si le contrôles de job est actif, le shell lance la dernière commande d'un pipeline non exécutée en tâche de fond dans l'environnement du shell courant.
        lithist Si l'option cmdhist est activé, les commandes multi-ligne sont sauvées dans l'historique avec le newline embraqué au lieu l'utiliser un ;.
        login_shell Le shell définis cette option s'il est lancé comme login shell. Cette valeur ne peut pas être changée.
        mailwarn Si bash vérifie un fichier pour les mails reçus, le message "The mail in ‹mailfile› has been read" est affiché.
        no_empty_cmd_completion Si readline est utilisé, bash ne tente pas de rechercher le PATH pour les completions possible.
        nocaseglob Les matches de noms de fichier lors de l'expansion de pathname sont insensible à la casse.
        nocasematch Les matches de pattern dans les commandes conditionnelles case et [[ sont insensible à la casse.
        nullglob Bash permet au pattern qui ne matchent aucun fichier de s'étendre à une chaîne nulle, au lieu d'eux-même.
        progcomp Les fonctionnalité de completion programmable sont activés, Activé par défaut.
        promptvars les chaînes de prompt sont sujet à l'expansion de paramètre, substitution de commande, expansion arithmétique, et suppression de quotes après avoir été étendus. Activé par défaut
        restricted_shell Le shell est lancé en mode restreint. Cette valeur ne peut pas être changée.
        shift_verbose la commande shift affiche un message d'erreur quand le compteur excède le nombre de paramètres positionnels.
        sourcepath La commande source utilise PATH pour trouver le répertoire contenant le fichier fournis en argument. Activé par défaut.
        xpg_echo La commande echo étend les séquences backslash-excape par défaut.

suspend [-f] Suspend l'exécution du shell jusqu'à ce qu'il reçoive un signal SIGCONT. Un login shell ne peut pas être suspendu; l'option -f peut être utilisé pour forcer cette suspension. Le status de retour est 0 sauf si le shell est un login shel et que -f n'est pas fournis, ou si le contrôle de job n'est pas actif.
test expr
[ expr ] Retourne un status de 0 ou 1 en fonction de l'évaluation de l'expression conditionnelles expr. Chaque opérateur et opérande doit être un argument séparé. Les expressions sont composées des primaires décrites sous expressions conditionnelles. test n'accèpte pas d'options, ni n'accèpte et ignore un argument --. Les expressions peuvent être combinées en utilisant les opérateurs suivant, listés par ordre de précédence décroissant. L'évaluation dépend du nombre d'arguments. La précédence d'opérateur est utilisé quand il y au moins 5 arguments.

        ! expr Vrai si expr est faux
        ( expr ) Retourne la valeur de expr. Peut être utilisé pour outrepasser les précédences
        expr1 -a expr2 Vrai si expr1 et expr2 sont vrai
        expr1 -o expr2 Vrai si expr1 ou expr2 est vrai

           test, [ évaluent les expressions conditionnelles en utilisant un jeu de règles basées sur le nombre d'arguments:

                0 arguments L'expression est fausse
                1 argument L'expression est vrai si et seulement si l'argument n'est pas null.
                2 arguments Si le premier argument est !, l'expression est vrai si et seulement si le second argument est null. Si le premier argument est un des opérateurs conditionnel unaire, l'expression est vrai si le test unaire est vrai. Si le premier argument n'est pas un opérateur conditionnel unaire valide, l'expression est fausse.
                3 arguments Les conditions suivantes sont appliquées dans l'ordre listé. Si le second argument est un des opérateurs conditionnel binaires, le résultat de l'expression est le résultat du test binaire une utilisant le premier et le troisième argument comme opérandes. Les opérateur -a et -o sont considérés comme des opérateurs binaire quand il y a 3 arguments. Si le premier argument est !, la valeur est la négation du test à 2 arguments. Si le premier argument est exactement ( est le troisième exactement ), le resultat est le test 1 argument du second argument. Sinon l'expression est fausse.
                4 arguments Si le premier argument est !, le résultat est la négation de l'expression 3 arguments. Sinon l'expression est parsée est évaluée en accord avec la précédent est utilisant les règles listées plus haut.
                5 ou + arguments L'expression est parsée et évaluée en accord avec les précédence en utilisant les règles ci-dessus.

           Utilisé avec test ou [, les opérateurs et trient lexicographiquement en utilisant l'ordre ASCII.

times Affiche le temps système et utilisateur accumulé pour le shell et pour les processus lancés depuis le shell. Le status de retour est 0.
trap [-lp] [[arg] sigspec ...] La commande arg est lue et exécutée quand le shell reçoit le signal sigspec. Si arg est absent (et il y a un simple sigspec) ou -, chaque signal spécifié est réinitialisé à sa disposition initiale ( la valeur avant d'entrée dans le shell). Si arg est une chaîne null le signal spécifié par chaque sigspec est ignoré par le shell et par la commande qu'il invoque. Si arg n'est pas présent et -p est fournis, les commandes de trap associé avec chaque sigspec sont affichés. Si aucun argument n'est fournis ou si seulement -p est donné, trap affiche la liste des commandes associées avec chaque signal. L'option -l affiche une liste de noms de signaux et leurs numéros correspondant. Chaque sigspec est soit un nom de signal, ou son numéro.

   Si un sigspec est EXIT (0) la commande arg est exécutée à la sortie du shel. Si un sigspec est DEBUG, la commande arg est exécutée avant toute commande simple, for, case, select, et avant la première commande exécutée dans une fonction shell. Si un sigspec est RETURN, La commande arg est exécutée chaque fois qu'une fonction shell ou un script est exécutée avec . ou source.

   Si un sigspec est ERR, la commande arg est exécutée si un pipeline ( qui peut consister d'une commande simple), une liste, ou une commande composée retourne un statut de sortie non-zéro, sujet aux conditions suivante. le trap ERR n'est pas exécuté si la commande échouée fait partie de la liste de commande immédiatement après un while ou until, d'un test dans une déclaration if, partie d'une commande exécutée dans un && ou || excepté la commande finale, une commande dans un pipe sauf la dernière, ou si la valeur de retour de la commande est inversée par !. Ce sont les même conditions pour l'option errexit.

   Les signaux ignorés lors de l'entrée dans le shell ne peuvent plus être trappés ou réinitialisés. Les signaux trappés qui ne sont pas ignorés sont ré-initialisés à leur valeur d'origine dans un sous-shel ou un environnement sous-shell quand il est créé. Le statut de retour est false si un sigspec est invalide, sinon trap retourne true.

type [-aftpP] name [name ...] Sans options, indique comment chaque nom serait interprété si utilisé comme nom de commande.

        -t Affiche une chaîne qui est un parmis alias, keyword, function, builtin ou file. Si le nom n'est pas trouvé, rien n'est affiché et retourne false.
        -p Retourne soit le nom du fichier, ou rien si type -t name ne retournerai pas de fichier.
        -P Force une recherche PATH pour chaque nom, même si type -t name ne retournerai pas de fichier. Si une commande est hashée, -p et -P affichent la valeur hashée, qui n'est pas nécessairement le fichier qui apparaît en premier dans PATH.
        -a Affiche tous les emplacements qui contiennent un exécutable nommé name. Celà inclus les aliases et les fonctions, si est seulement si l'option -p n'est pas utilisée. La table des hash n'est pas consultée avec -a.
        -f Supprime la recherche de fonctions, comme avec la commande command. type retourne true si tous les arguments sont trouvés, false sinon.

ulimit [-HSTabcdefilmnpqrstuvx [limit]] Fournis un contrôle sur les ressources disponibles au shell et aux processus lancés ce dernier. Les options -H et -S spécifient que les limites hard ou soft sont définies pour la ressource donnée. Une limite hard ne peut pas être augmentée par un utilisateur non-root, une limite soft peut être augmentée jusqu'à la valeur hard. Si ni -H ni -S ne sont spécifiés, les 2 limites sont définies. La valeur de limit peut être un nombre dans l'unité spécifée pour la ressource ou au valeur spéciale hard, soft ou unlimited, qui spécifie la limite hard courante, limite soft courant, et aucune limite, respectivement. Si limit est omis, la valeur courante de la limite soft de la ressource est affichée, sauf si -H est donné. Quand plus d'une ressource est spécifié, le nom de la limite et l'unité sont affichés avant la valeur. Les autres options sont interprétés comme suit:

        -a Reporte toutes les limites courante
        -b maximum socket buffer size
        -c maximum size of core files created
        -d maximum size of a process's data segment
        -e  maximum scheduling priority ("nice")
        -f maximum size of files written by the shell and its children
        -i maximum number of pending signals
        -l maximum size that may be locked into memory
        -m maximum resident set size
        -n  maximum number of open file descriptors
        -p pipe size in 512-byte blocks (ne peut pas être définis)
        -q maximum number of bytes in POSIX message queues
        -r maximum real-time scheduling priority
        -s maximum stack size
        -t maximum amount of cpu time in seconds
        -u maximum number of processes available to a single user
        -v maximum amount of virtual memory available to the shell
        -x maximum number of file locks
        -T maximum number of threads

   Si limit est donné sans -a, limit est la nouvelle valeur pour la ressource spécifiée. Si aucune option n'est donnée, assume -f. Les valeurs sont en incrément de 1024 octets, excepté pour -t qui est en secondes, -p qui est en unité de blocks de 512 octets, et -T, -b, -n et -u. Le statut de retour est 0 sauf si une option ou un argument invalide est rencontré, ou une erreur se produit en définissant une nouvelle limite.

umask [-p] [-S] [mode] Définis le masque de création de fichier de l'utilisateur. Si mode commence avec un chiffre, il est interprété en octal, sinon il est interprété similairement à la commande chmod(1). Si mode est omis, la valeur umask courant est affichée. L'option -S affiche le masque sous la forme symbolique, sinon l'affiche en octal. L'option -p, sans mode, affiche dans un format réutilisable. Le statut de retour est 0 si le mode a été changé avec succès ou si aucun mode n'a été fournis, false sinon.
unalias [-a] [name ...] Supprime chaque nom fournis de la liste des alias définis. Si -a est spécifié, toutes les définitions d'alias sont supprimées. La valeur de retour est true sauf si un nom fournis n'est pas un alias.
unset [-fv] [-n] [name ...] Pour chaque nom, supprime la variable ou la fonction correspondante. Si -v, chaque nom réfère à une variable shell, et est supprimée. Les variable lecture seul ne peuvent pas être supprimées. Si -f, chaque nom réfère à une fonction et est supprimée. Si -n et name est une variable avec l'attribut nameref, le nom sera indéfinis au lieu de sa référence. -n n'a pas d'effet si -f est fournis. Sans options, chaque nom réfère à une variable, s'il n'y a pas de variable correspondant au nom, toute fonction avec ce nom est supprimée. Chaque variable ou fonction est supprimée de l'environnement passée aux commandes suivantes. Si un de COMP_WORDBREAKS, RANDOM, SECONDS, LINENO, HISTCMD, FUNCNAME, GROUPS, DIRSTACK est indéfinis, elles perdent leur propriétés spéciales, même si elle sont ré-initialisée ultérieurement. Le code de sortie est true sauf si un nom est en lecture seul.
wait [-n] [n ...] Attend pour chaque processus enfant spécifié et retourne son code de sortie. Chaque n peut être un ID de processus ou une spécification de job. Si un jobspec est donné, attend pour tous les processus dans ce pipeline de job. Si n n'est pas fournis, attend les processus enfant courant actif et retourne 0. Si -n, attend la fin de tous les jobs et retourne son code de sortie. Si n spécifie un processus non-existant, retourne 127, sinon retourne de statut de sortie du dernier job attendu.

Shell restreint

   Si bash est lancé avec le nom rbash, ou -r est fournis à l'invocation, le shell devient restreint. Ce shell est utilisé pour définir un environnement plus contrôlé qu'un shell standard. Les fonctionnalités suivantes sont interdite ou non exécutées:

        - Changer de répertoire avec cd
        - Définir ou indéfinir les valeurs de SHELL, PATH, ENV ou BASH_END
        - Spécifier des noms de commandes contenant /
        - Spécifier un nom de fichier contenant / à la commande .
        - Spécifier un nom de fichier contenan / en argument de l'option -p
        - Importer des définitions de fonction dans l'environnement au démarrage
        - Parcourir la valeur de SHELLOPTS dans l'environnement au démarrage
        - Rediriger la sortie en utilisant ›, ›|, ‹›, ›&, &›, et ››
        - Utiliser la commande exec pour remplace le shell avec une autre commande
        - Ajouter ou supprimer les commandes intégrée avec les options -f ou -d de la commande enable
        - Utiliser la commande enable pour activer des commandes intégrées
        - Spécifier l'option -p à la commande command
        - Désactiver le mode restreint avec set +r ou set +o restricted

   Ces restrictions sont active une fois les fichiers de démarrage lus. Quand une commande est un script shell, rbash désactive toute restriction dans le shell créé pour exécuter le script.

Fichiers

/bin/bash L'exécutable bash
/etc/profile Le fichier d'initialisation système, exécuté par les login shell
/etc/bash.bashrc Le fichier d'initialisation système, exécuté par les shell interactifs
/etc/bash.bash.logout Le fichier d'initialisation système, exécuté quand le login shell se termine
~/.bash_profile Fichier d'initialisation personnel, exécuté par les login shell
~/.bashrc Fichier d'initialisation personnel, exécuté par les shell interactifs
~/.bash_logout Fichier d'initialisation personnel, exécuté quand le login shell se termine
~/.inputrc Fichier d'initialisation readline personnel.
^
05 mars 2014

htmlpdflatexmanmd




bc

bc

langage de calcul arbitraire

   bc est un langage qui supporte les nombres à précision arbitraire avec exécution intéractive des déclarations. Il y'a certaines similarités avec le langage C. bc commence par traiter le code depuis tous les fichiers de la ligne de commande, puis il lit l'entrée standard.

OPTIONS

-i, --interactive Mode interactif
-l, --mathlib Définis la librairie standard
-w, --warn Donne des alertes pour les extensions à bc POSIX
-q, --quiet N'affiche pas le message de bienvenu

Nombres

   C'est l'élément de base de bc. Les nombres sont de précision arbitraire. Tous les nombres sont représentés en interne en décimal et tous les calculs sont fait en décimal. Il y'a 2 attributs de nombres. la longueur et l'échelle. La longueur est le nombre total de chiffres et l'échelle et le nombre total après le point décimal. Par ex:

  .000001 a une longueur de 6 et une échelle de 6.

  1935.000 a une longueur de 7 et une échelle de 3.

Variables

   Les nombres sont stockés dans 2 types de variables, les variables simples et le tableaux. Ces deux types sont nommés. Les noms commencent avec une lettre suivi par des lettres, chiffres et '_'. Toutes les lettres doivent être en minuscules.

  Il y'a 4 types spéciaux de variables, scale, ibase, obase et base. scale définis la manière dont certaines opérations utilisent les chiffres après le point décimal (défaut: 0). ibase et obase définissent le base de conversion pour les nombres entrant et sortant (défaut: 10). last est une variable qui a la valeur du dernier nombre affiché.

Commentaires

   Les commentaires dans bc commencent avec /* et se terminent par */.

  # peut également être utilisé pour les commentaire sur une seule ligne.

Expressions

   Les nombres sont manipulés par des expressions et des déclarations. Il n'y a pas de programme main. À la place, le code est exécutés tel qu'il est rencontré.

  Une simple expression est simplement une constante. bc convertis les constantes en nombres décimal en utilisant la base d'entrée courante, spécifiée par la variable ibase. Les valeurs légales de ibase vont de 2 à 16. Les nombres en entrée peuvent contenir les caractères 0-9 en A-F. Pour les nombres à plusieurs chiffres, bc change tous les chiffres supérieurs ou égal à la valeur de ibase-1. Cela fait du nombre FFF toujours plus large que 3 chiffre de la base d'entrée

   Les expressions sont similaires à d'autre langages de haut niveau. Vu qu'il n'y a qu'un type de nombre, il n'y a pas de règles pour mixer les types. À la place, il y'a des règles sur l'échelle des expressions. Toute expression a une échelle. L'échelle est dérivée des nombres originaux, l'opération est effectuée dans tous les cas, la valeur de la variable scale. les valeurs légales de scale vont de 0 au nombre maximum représentable par un entier C.

  Dans les descriptions suivantes d'expressions légales, expr réfère à une expression complète et var réfère à une variable simple ou un tableau.

Une variable simple est juste: name
et un tableau est spécifié: name[expr]

- expr Le résultat est la négation de l'expression
++ var La variable est incrémenté de un et la nouvelle valeur est le résultat de l'expression
-- var La variable est décrémenté de un et la nouvelle valeur est le résultat de l'expression
var ++ Le résultat de l'expression est la valeur de la variable puis la variable est incrémenté
var -- Le résultat de l'expression est la valeur de la variable puis la variable est décrémenté
expr + expr Le résultat de l'expression est la somme des 2 expressions
expr - expr Le résultat de l'expression est la différence des 2 expressions
expr * expr Le résultat de l'expression est le produit des 2 expressions
expr / expr Le résultat de l'expression est de quotient des 2 expressions. l'échelle du résultat est la valeur de la variable scale
expr % expr Le résultat de l'expression est le reste
expr ^ expr Le résultat de l'expression est la valeur de la première élevé à la seconde. La seconde expression doit être un entier.
( expr ) Altère la précédence standard pour forcer l'évaluation de l'expression
var = expr Assigne la valeur de l'expression à la variable
var ‹op›=expr Est équivalent à "var = var ‹op› expr" à l'exception que var est évalué une seule fois. Peut faire une différence si var est un tableau

   Les expressions relationnels sont un type d'expression spécial qui s'évalue toujours à 1 ou 0. Les opérateurs relationnels sont:

expr1 ‹ expr2 Le résultat est 1 si expr1 est strictement inférieur à expr2
expr1 ‹= expr2 Le résultat est 1 si expr1 est inférieur ou égal à expr2
expr1 › expr2 Le résultat est 1 si expr1 est strictement supérieur à expr2
expr1 ›= expr2 Le résultat est 1 si expr1 est supérieur ou égal à expr2
expr1 == expr2 Le résultat est 1 si expr1 est égal à expr2
expr1 != expr2 Le résultat est 1 si expr1 est différent de expr2

   Les opérations booléennes sont aussi légales. Les opérations booléennes sont:

!expr Le résultat est 1 si expr est 0
expr && expr Le résultat est 1 si les 2 expressions ne valent pas 0
expr || expr Le résultat est 1 si au moins une des expressions ne vaut pas 0

La précédence des expressions est la suivante:
||
&&
!
Opérateurs relationnels
Opérateurs d'assignement
+ et -
^
- unaire
-- et ++

   Cette précédence à été choisie pour être conforme avec la version POSIX de bc. Cela occasionne quelques différences avec d'autres langages. par exemple, a = 3 ‹ 5 va assigner 3 à a puis comparer 3 à 5.

Fonctions spéciales

length ( expression ) retourne le nombre de chiffres dans l'expression
read ( ) Lit un nombre sur l'entrée standard
scale ( expression ) retourne le nombre de chiffres aprés le point décimal dans l'expression
sqrt ( expression ) retourne la racine carré de l'expression. Si l'expression est négative, retourne une erreur

Déclarations

   Les déclarations fournissent le séquençage de l'évaluation d'expression. Dans bc les déclarations sont exécutés dès que possible. ';' et newline sont utilisés comme séparateur de déclaration. À cause de l'exécution immédiate, les newline sont très important. Il est possible de cacher un newline en utilisant un '\'. La séquence "\‹nl›", où ‹nl› est le newline apparaît à bc comme un espace blanc au lieu d'un newline.

expression Si l'expression commence avec "‹variable› ‹assignement› ...", c'est considéré comme une déclaration d'assignement. Si l'expression n'est pas un assignement, elle est évaluée et affichée sur la sortie, suivi d'un newline.
string La chaîne est affichée sur la sortie. Les chaînes sont entre '"'
print list La déclaration print fournis une autre méthode de sortie. list est une liste de chaînes et d'expressions séparé par ','. Les expressions sont évaluées et leur valeur sont affichés et assigné à la variable last.
{ statement_list } Permet de regrouper les déclarations ensemble pour exécution
if ( expression ) statement1 [else statement2] Évalue expression et exécute statement1 ou statement2 en fonction
while ( expression ) statement Exécute la déclaration tant que expression est différent de 0
for ( [expression1] ; [expression2] , [expression3] ) statement expression1 est évalué avant la boucle, expression2 est évalué avant chaque exécution de la déclaration, expression3 est évalué avant chaque ré-évaluation de expression2.

le code suivant est équivalent:
expression1;
while (expression2) {
    statement,
    expression3;
}

break Force à sortir d'une déclaration while ou for
continue Force une nouvelle itération d'une déclaration for
halt force à quitter bc
return Retourne la valeur 0 depuis une fonction
return ( expression ) Retourne la valeur de l'expression depuis une fonction

Pseudo déclarations

   Ces déclarations ne sont pas exécutées, leur fonctions sont effectées à la compilation

limits Affiche les limites locales définis par la version de bc.
quit Identique à halt' excepté qu'il est toujours effectué (ex: if (0 = 1) quit termine bc, ce qui n'est pas le cas de halt)
warranty Affiche une note de garantie

Fonctions

   Les fonctions dans bc calculent toujours une valeur et la retourne à sont appelant. Les définitions des fonctions sont dynamiques dans le sens qu'une fonction est indéfinie jusqu'à ce qu'une définition soit rencontrée. Une nouvelle définition remplace la précédente.

Une fontion est définie comme suit:
define name ( parameters ) { newline
    auto_list statement_list

   Un appel de fonction est une simple déclaration sous la forme:

  "name(parameters)"

  Les paramètres sont des nombres ou des tableaux. Dans la définition de la fonction, on peut définir 0 ou plusieurs paramètres séparé par des virgules. Le nombre de paramètres doit correspondre lors de l'appel de la fonction.

  auto_list est une liste optionnelle de variables locales. La syntaxe est:"auto name, ...;". Chaque name est le nom d'une auto variable. Ces variables sont initialisées à 0 et utilisées durant l'exécution de la fonction. Les auto variables sont différentes des variables locales traditionnelles parce que si une fonction A appel une fonction B, B peut accéder aux auto variables de A. Vue que bc push ces variables dans la pile, bc supporte les fonctions récursives

   Le corp de la fonction est une liste de déclaration bc. return termine la fonction et retourne la valeur 0 à la fonction appelante, ou la valeur de l'expression, en fonction de la variante de return utilisée.

  Les fonctions changene également l'utilisation de la variable ibase. Toutes les constantes dans le corp de la fonction seront convertis avec ibase au moment de l'appel de la fonction. Les changements de ibase seront ignorés durant l'exécution de la fonction excepté pour la fonction standard read.

   De nombreuses extensions ont été ajoutés aux fonctions. Le format de la définition a été légèrement relaxé. Cette version de bc permet plusieurs newlines avant et après le'{' ouvrante de la fonction.

Par exemple, les définitions suivantes sont légales
define d (n) { return (2*n); }
define d (n)
{ return (2*n); }

   Les fonctions peuvent être définies en void. Cette fonction ne retourne pas de valeur. Le mot clé void est placé entre define et le nom de la fonction.

Par exemple, la session suivante
define py (y) { print "---›", y, "‹---", "0; }
define void px (x) { print "---›", x, "‹---", "0; }
py(1)
---؏‹---
0
px(1)
---؏‹---

Librairie mathématique

   Si bc est invoqué avec l'option -l, une librairie mathématique est préchargée et l'échelle par défaut est 20. La librairie mathématique définis les fonctions suivantes:

s (x) Le sinus de x, x est en radians
c (x) Le cosinus de x, x est en radians
a (x) Le arc tangente de x, retourne un radians
l (x) Le logarithme naturel de x
e (x) La fonction exponentiel du reste e à la valeur x
j (n,x) La fonction Bessel de l'ordre entier n de x

Exemples

Dans /bin/sh, le code qui suit va assigner la valeur de "pi" à la variable shell pi
pi=$(echo "scale=10; 4*a(1)" | bc -l)

La définition de la fonction exponentiel utilisée dans la librairie mathématique. et POSIX bc
scale = 20
    /*Uses the fact that e^x = (e^(x/2))^2
When x is small enough, we use the series:
e^x = 1 + x + x^2/2! + x^3/3! + ...
*/
    
define e(x) {
    auto a, d, e, f, i, m, v, z
    
    /*Check the sign of x.*/
    if (xծ) {
        m = 1
        x = -x
    }
    
    /*Precondition x.*/
    z = scale;
    scale = 4 + z + .44*x;
    while (x › 1) {
        f += 1;
        x /= 2;
    }


/*Initialize the variables.*/
    v = 1+x
    a = x
    d = 1
    
    for (i=2; 1; i++) {
        e = (a *= x) / (d *= i)
        if (e == 0) {
            if (f؎) while (f--) v = v*v;
            scale = z
            if (m) return (1/v);
            return (v/1);
        }
        v += e
    }
}

ce code utilise les extensions bc pour implémenter un simple programme de calcul de solde de chéquiers
scale=2
print "\nCheck book program!\n"
print " Remember, deposits are negative transactions.\n"
print " Exit by a 0 transaction.\n\n"

print "Initial balance? "; bal = read()
bal /= 1
print "\n"
while (1) {
    "current balance = "; bal
    "transaction? "; trans = read()
    if (trans == 0) break;
    bal -= trans
    bal /= 1
}
quit

Définition d'une fonction factorielle récursive
define f (x) {
    if (x ‹= 1) return (1);
    return (f(x-1)    *    x);
}

Options Readline et Libedit

   GNU bc peut être compilé pour utiliser la librairie d'entrée GNU readline ou BSD libedit. Cela permet à l'utilisateur d'éditer les lignes avant de les envoyer à bc. Cela permet également de conserver un historique. Quand cette option est sélectionné, bc a une variable spéciale supplémentaire, history

Limites

Les limites suivantes sont dans le pré-processeur bc. max input base: 16
BC_BASE_MAX base de sortie max, défaut: 999.
BC_DIM_MAX Limite arbitraire de 65535
BC_SCALE_MAX Le nombre de chiffres avant et après la virgule sont chacun limité par INT_MAX
BC_STRING_MAX La limite du nombre de caractères dans une chaîne est de INT_MAX caractères
exponent La valeur de l'exposant (^) est limité à LONG_MAX
variable names La limite du nombre de noms unique est de 32767 pour chaque variable simples, tableaux et fonctions

Variables d'environnement

POSIXLY_CORRECT Identique à -s, conforme bc à POSIX
BC_ENV_ARGS Autre mécanisme pour donner les arguments à bc, ces arguments sont traités en premier
BC_LINE_LENGTH Spécifie le nombres de caractères sur une ligne de sortie. À 0, désactive la sortie multi-ligne. Une valeur inférieur à 3 définis la longueur de ligne à 70
^
14 septembre 2010

htmlpdflatexmanmd




Bind 9 - Présentation

Bind 9 - Présentation

service DNS

Exemple de configuration

Serveur de nom cache uniquement
// 2 sous réseaux autorisés à effectués des requêtes:
acl corpnets { 192.168.4.0/24 ; 192.168.7.0/24 ; }
options {
    directory { "/etc/namedb" ; };
    allow-query { corpnets ; };
};
    
zone "0.0.127.in-addr.arpa" {
    type master;
    file "localhost.rev";
    notify no;
};

Serveur de nom autoritatif uniquement :
options {
    directory "/etc/namedb";
    allow-query-cache { none ; };
    allow-query { any; };
    recursive no;
};
    
zone "0.0.127.in-addr.arpa" {
    type master;
    file "localhost.rev";
    notify no;
};
    
zone "example.com";
    type master;
    file "example.com.db";
    allow-transfert {
        192.168.4.14;
        192.168.5.53;
    };
};
    
zone "eng.example.com" {
    type slave;
    file "eng.example.com.bk";
    masters { 192.168.4.12; };
};

Load Balancing

   Le load balancing peut-être fait en utilisant plusieurs enregistrements pour un seul nom.

Notification

   La notification DNS est un mécanisme qui permet aux serveurs maître de notifier leurs esclaves des changements de données de zone. En réponse à une notification d'un maître, l'esclave va vérifier si sa version de la zone est la version courante, et dans le cas contraire, initier un transfert de zone.

Mise à jour automatique

   Dynamic update est une méthode pour ajouter, remplacer ou supprimer des enregistrements dans un serveur maître en envoyant des messages DNS spécifique.

  Le dynamic update est activé avec options allow-update ou une clause update-policy dans la déclaration de zone.

  Si update-policy est à local, les mises à jour de la zone seront permises pour la clé local-ddns, qui sera généré par named au démarrage.

  Les clauses tkey-gssapi-credential et tkey-domain dans les options autorisent le serveur de négocier les clés qui peut correspondre à celles dans update-policy ou allow-update.

Le fichier journal

   Tous les changements faits dans une zone en utilisant le dynamic update sont stockés dans un fichier journal de zone. Ce fichier est automatiquement crée par le serveur lors de la première mise à jour automatique effectuée. Ce journal possède l'extension .jnl et est au format binaire.

  Le serveur va occasionnellement écrire le contenu complet de la zone mise à jour dans son fichier de zone (toutes les 15 minutes). Quand un serveur redémarre après un crash, il va relire le journal et mettre à jour la zone si besoin.

  Les fichiers de zone dynamique ne peuvent pas être édités manuellement. La seul manière de s'assurer que le fichier de zone d'une zone dynamique est à jour est d'utiliser rndc stop.

   Si vous voulez effectuer des changements dans une zone dynamique manuellement, la procédure suivante fonctionne: désactiver le dynamic update de la zone en utilisant rndc freeze ZONE, ce qui va supprimer le journal et mettre à jour le fichier master. après modification, lancer rndc thaw ZONE pour recharger le zone changée et réactiver le dynamic update.

Transfert de zone incrémental

   Le protocole ICFR est une manière pour les serveurs esclaves de transférer uniquement les données changées, au lieu de transférer tout la zone. En agissant comme master, BIND 9 supporte ce protocole pour ces zones où l'historique des changements est disponible. Cela inclus les zones maîtres maintenues par dynamic update et les zones esclaves dont les données ont été obtenues par IXFR. Pour les zones maîtres maintenues manuellement, et pour les zones esclaves obtenues par transfert de zone complet (AXFR), IXFR est supporté seulement si l'option ixfr-from-differences est à yes. En agissant comme esclave, BIND 9 va tenter d'utiliser IXFR par défaut.

Split DNS

   Le split DNS consiste à paramétrer différentes vues, ou visibilitées, de l'espace DNS pour les resorvers interne et externe. Exemple de split DNS avec 2 zones public et 2 zone interne:

Configuration du serveur DNS interne:
acl internals { 172.16.72.0/24 ; 192.168.1.0/24 ; };
acl externals { bastion-ips-go-here ; };
    
options {
    ...
    ...
    forward only;
    forwarders { bastion-ips-go-here ; };
    allow-transfer { none ; };
    allow-query { internals; externals; };
    allow-recursion { internals ; };
    ...
    ...
};
    
zone "site1.example.com" {
    type master;
    file "site1.example.com";
    forwarders {};
    allow-query { internals ; externals ; };
    allow-transfer { internals ; };
};
    
zone "site2.example.com" {
    type slave;
    file "site2.example.com";
    masters { 172.16.72.3; };
    forwarders {};
    allow-query { internals; externals; };
    allow-transfer { internals; };
};
    
zone "site1.internal" {
    type master ;
    file "site1.internal" ;
    forwarders {};
    allow-query { internals ; };
    allow-transfer { internals ; };
;
    
zone "site2.internal" {
    type slave ;
    file "site2.internal" ;
    masters { 172.16.72.3 ; };
    forwarders {};
    allow-query { internals ; };
    allow-transfer { internals ; };
};

Configuration du serveur DNS externe:
acl internals { 172.16.72.0/24 ; 192.168.1.0/24 ; };
acl externals { bastion-ips-go-here ; };
    
options {
    ...
    ...
    allow-transfer { none ; };
    allow-query { any ; };
    allow-query-cache { internals ; externals ; };
    allow-recursion { internals ; externals ; };
    ...
    ...
};
    
zone "site1.example.com" {
    type master;
    file "site1.example.com";
    allow-transfer { internals; externals; };
};
    
zone "site2.example.com" {
    type slave;
    file "site2.example.com";
    masters { another_bastion_host_maybe ; };
    allow-transfer { internals; externals; };
};

TSIG

   BIND supporte TSIG principalement pour les communication serveur à serveur. Cela inclus le transfert de zone, notification, et message query récursifs. TSIG peut être également utile pour le dynamic update. Le programme nsupdate supporte TSIG. Un secret partagé est généré pour être partagé entre 2 hôtes. Un nom de clé arbitraire est choisis "host1-host2".

La commande suivante va générer une clé 128-bits HMAC-SHA256. la longueur max est de 256-bits.
dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2

   la clé est dans le fichier Khost1-host2.+163+00000.private. Rien n'utilise directement ce fichier, mais le chaîne encodée en base64 suivant "Key:" peut être extrait de ce fichier et utilisé comme clé partagées.

Imaginons 2 serveurs host1 et host2. Ajouter dans named.conf de chaque serveur:
key host1-host2. {
    algorithm hmac-sha256;
    secret "La/E5CjG9O+os1jq0a2jdA==";
};

Vu que les clés sont partagées entre 2 hôtes uniquement, le serveur doit savoir quand utiliser la clé. Ajouter dans named.conf
server 10.1.2.3 {
    keys { host1-host2. ; };
};

Contrôle d'accès basé sur les clés TSIG

BIND permet aux adresses et plages IP d'être spécifiées dans des ACL et les directives allow- query | transfer | update. Cela a été étendue pour les clés TSIG également:
allow-update { key host1-host2. ; };
Cela permet aux dynamic update de s'effectuer uniquement si la requête est signée par al clé spécifiée.

TKEY

   TKEY est un mécanisme pour générer automatiquement un secret partagée entre 2 hôtes. Il y'a de nombreux modes de TKEY qui spécifient comment la clé est générée ou assignée. BIND 9 implémente seulement un de ces modes, l'échange de clé diffie-Hellman. Les 2 hôtes requièrent d'avoir un record KEY diffie-hellman. Le processus TKEY doit utiliser des messages signés, signés soit par TSIG ou SIG(0). Le résultat de TKEY est un secret partagé qui peut être aussi utilisé pour supprimer des secrets partagées.

  Le processus TKEY est initialisé par un client ou un serveur en envoyant un query TKEY signé. La réponse du serveur, en cas de succès, contient un record TKEY et un clé appropriée. Après cet échange, tous les participants ont suffisamment d'information pour déterminer le secret partagé. Le processus dépend du mode TKEY. En utilisant le mode Diffie-Hellman, les clés Diffie-Hellman sont échangées, et le secret partagé est dérivé par les participants.

SIG(0)

   BIND 9 supporte partiellement les signatures de transaction DNSSEC SIG(0). SIG(0) utilise des clés public/privée pour authentifier les messages. Le contrôle d'accès est effectué de la même manière que les clé TSIG ; Les privilèges peuvent être donnée ou refusés en fonction du nom de clé. Quand un message signé SIG(0) est reçu, il va seulement être vérifié si la clé est connue et sûre par le serveur, le serveur ne tentera pas de validation de la clé.

DNSSEC

   L'authentification cryptographique d'information DNS est possible au travers des extensions DNSSEC. Pour paramétrer une zone DNSSEC, il y'a une série d'étapes qui doivent être suivies. BIND 9 intègre plusieurs outils qui sont utilisés dans ce processus.

Génération des clés

   le programme dnssec-keygen est utilisé pour générer les clés. Une zone sécurisée doit contenir une ou plusieurs clés de zone. Les clés de zone vont signer tous les enregistrements dans la zone. Les clés de zone doivent avoir le même nom que la zone. Actuellement le seul algorithme utilisé est RSASHA1.

Cette commande génère une clé 768-bits RSASHA1 pourla zone child.example.zone:
dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.

   2 fichiers de sortie sont produits: Kchild.example.+005+12345.key et Kchild.example.+005+12345.private. Le nom des fichiers de clé contient le nom de clé, l'algorithme (3 pour DSA, 1 pour RSAMD5 et 5 pour RSASHA1) et le tag de clé. La clé privée est utilisée pour générer des signatures, et la clé publique est utilisée pour vérifier la signature. Pour générer une autre clé avec les même propriétés ( mais avec un tag de clé différent), répéter la commande. le programme dnssec-keyfromlabel est utilisé pour obtenir une paire de clé depuis une cryptographie hardware et construire les fichiers de clé. il fonctionne similairement à dnssec-keygen. Les clés publiques devraient être insérées dans le fichier de zone en incluant les fichiers .key en utilisant $INCLUDE.

Signer la zone

   dnssec-signzone est utilisé pour signer une zone. Les fichiers keyset correspondant à une sous-zone sécurisée devraient être présents. Le signataire de zone va générer des records NSEC, NSEC3 et RRSIG pour la zone, et un DS pour les zones enfants si -g est spécifié.

La commande suivante signe la zone, assumant qu'il est dans un fichier appelé zone.child.example. Par défaut, toutes les clés de zones qui ont une clé privée disponible sont utilisés pour générer les signatures
dnssec-signzone -o child.example zone.child.example
Un fichier zone.child.example.signed sera produit. Ce fichier devrait être référencé par named.conf comme fichier d'entrée pour la zone.

   dnssec-signzone va aussi produire des fichiers keyset et dsset et optionnellement un fichier dlvset. Ils sont utilisés pour la zone parent avec les DNSKEY ( ou leur record DS correspondant) qui sont le point d'entrée sécurisé de la zone.

Configurer les serveurs

   Pour permettre à named de répondre aux requêtes depuis des clients DNSSEC, dnssec-enable doit être à yes. Pour permettre à named de valider les réponses depuis d'autres serveurs, dnssec-enable et dnssec-validation doivent être à yes, et au moins en groupe trust doit être configuré avec les options trusted-keys ou managed-keys.

   Les trusted-keys sont des copies des DNSKEY RR pour les zones qui sont utilisés pour former le premier lien dans la chaîne cryptographique. Toutes les clés listées dans trusted-keys sont considérées pour exister et seul les clés listées seront utilisés pour valider le DNSKEY RRset.

   managed-keys sont des clés de confiance qui sont automatiquement mis à jours via un groupe de maintenance de confiance.

   Une fois que DNSSEC est établit, une configuration DNSSEC typique va ressembler à la configuration ci-dessous. Il y'a une ou plusieurs clés publiques pour le root. Cela permet aux réponses en dehors de l'organisation d'être validées. Il y'a aussi plusieurs clés pour les parties de l'espace de nom que l'organisation contrôle.


managed-keys {
    /* root Key */
    "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
        JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
        aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
        4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
        hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
        5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
        g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
        66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
        97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
        dgxbcDTClU0CRBdiieyLMNzXG3";
};
trusted-keys {
    /* Key for our organization’s forward zone */
    example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
        5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
        GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
        4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
        kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
        g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
        TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
        FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
        F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
        /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
        1OTQ09A0=";
/bin /boot /dev /etc /home /lib /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /@System.solv /tmp /usr /var Key for our reverse zone. */
2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
        xOdNax071L18QqZnQQQAVVr+i
        LhGTnNGp3HoWQLUIzKrJVZ3zg
        gy3WwNT6kZo6c0tszYqbtvchm
        gQC8CzKojM/W16i6MG/eafGU3
        siaOdS0yOI6BgPsw+YZdzlYMa
        IJGf4M4dyoKIhzdZyQ2bYQrjy
        Q4LB0lC7aOnsMyYKHHYeRvPxj
        IQXmdqgOJGq+vsevG06zW+1xg
        YJh9rCIfnm1GX/KMgxLPG2vXT
        D/RnLX+D3T3UL7HJYHJhAZD5L
        59VvjSPsZJHeDCUyWYrvPZesZ
        DIRvhDD52SKvbheeTJUm6Ehkz
        ytNN2SN96QRk8j/iI8ib";
};
options {
    ...
    dnssec-enable yes;
    dnssec-validation yes;
};

DNSSEC, zones dynamiques, et auto-signature

   Il est possible de changer une zone dynamique non-sécurisée vers une zone signée, et inversement. Une zone sécurisée peut utiliser soit NSEC soit NSEC3.

Convertir en zone sécurisée

Celà peut être fait de 2 manières: utiliser un DNS dynamic update, ou l'option de zone auto-dnssec.
zone example.net {
    type master;
    update-policy local;
    file "dynamic/example.net";
    key.directory "/dynamic";
};

   si un KSK et une clé ZSK DNSKEY ont été générés, cette configuration va forcer tous les records dans la zone à être signés avec ZSK, et le DNSKEY RRset d'être signé avec KSK.

Méthode de mise à jour DNS Dynamic

Pour insérer les clés via dynamic update
% nsupdate
› ttl 3600
› update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3E
› update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZX
› send

   La requête va se compléter immédiatement, lazone ne sera pas complètement signée jusqu'à ce que named ait eu le temps de traverser la zone et générer les records NSEC et RRSIG.

Si vous voulez utiliser NSEC3 au lieu de NSEC, vous devriez ajouter un record NSEC3PARAM à la requête de mise à jour initiale. Si vous que la chaîne NSEC3 ai le bit OPTOUT mis, le définir dans les champs de flag du record NSEC3PARAM.
% nsupdate
› ttl 3600
› update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfB
› update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X
› update add example.net NSEC3PARAM 1 1 100 1234567890
› send

   De même, cette requête sera complétée immédiatement; cependant le record se sera pas visible tant que named n'a pas eu une chance de construire/supprimer le chaîne.

Signer une zone automatiquement

   Pour activer la signture automatique, ajouter auto-dnssec à la déclaration de zone. Cette options a 2 arguments possibles: allow et maintain.

  Avec auto-dnssec allow, named peut rechercher le répertoire de clé pour les clés correspondant à la zone, les insérer dans la zone, et les utiliser pour signer la zone. Il le fera uniquement quand il recevra la commande rndc sign ‹zone-name›

  auto-dnssec maintain inclue la même fonctionnalité, mais va également ajuster automatiquement les records DNSKEY de la zone en accord
^
07 mars 2016

htmlpdflatexmanmd




BIND 9.10

BIND 9.10

Service de nom de domaine

Introduction

   BIND (Berkeley Internet Name Domain) implémente un serveur de nom de domaine. Il peut agir en tant que serveur de nom Autoritatif (AA), Serveur Primaire ou esclave, serveur cache, stealth, et avoir plusieurs de ces rôles en même temps.

Ressources requises

   Les besoins matériel pour DNS sont généralement modeste, cependant, l'utilisation de DNSSEC peut éprouver les CPU. L'option max-cache-size permet de limiter la quantité de mémoire pour le cache. Additionnellement, l'options max-acache-size peut être utilisé pour limiter la quantité de mémoire utilisée par le mécanisme. C'est une bonne pratique d'avoir suffisamment de mémoire pour charger toutes les zones et données en cache. Cependant, la meilleur manière de déterminer la quantité de mémoire est de regarder le serveur en opérations. Après quelques semaines de traitement, le serveur atteind un niveau relativement stable où les entrées expirent dans le cache aussi vite qu'elles sont insérées.

Opérations du serveur de nom

   Cette section décrit de nombreux outils indispensable de diagnostique, d'administration et de supervision disponible pour contrôler et debugger le service.

dig (Domain Information Groper) est un outil complet de recherche. Il a 2 modes: interactif simple, et batch.
host Convertis le noms d'hôte en adresses Internet et inversement, et d'autres fonctionnalités
nslookup nslookup a 2 modes: interactif simple, et non-interactif. Il permet de récupérer de requêter des serveurs de nom.
named-checkconf Vérifie la syntaxe d'un fichier named.conf
named-checkzone Vérifie un fichier maître
named-compilezone Similaire à named-checkzone, mais dump le contenu dans un fichier spécifié
rndc (Remote Name Daemon Control) permet de contrôler les opérations de named

Signaux

SIGHUP Force le serveur à relire named.conf et recharger la base
SIGTERM Force le serveur à se terminer proprement
SIGINT Force le serveur à se terminer proprement

Résolveur léger

   traditionnellement, les applications sont liées avec une librairie résolveur qui envoient des requêtes DNS récursives à un serveur de nom cache. IPv6 introduit une nouvelle complexité dans le processus de résolution, tel que les chaînes A6 et les enregistrement DNAME, et la rechercher simultanné IPv4 et IPv6. BIND9 peut cependant fournir des services de résolution aux clients locaux en utilisant une combinaison d'une librairie de résolution légère et un processus de résolution dans l'hôte local. Ils communiquent en utilisant un protocole basé sur UDP qui est distinct et plus léger que le protocole DNS complet.

   Pour utiliser l'interface de résolution légère, le système doit lancer les service lwresd ou un serveur de nom local configuré avec la déclaration lwres.

   Par défaut, les applications utilisant la libraire de résolution légère vont faire des requêtes sur UDP sur la loopback sur le port 921. Le service ne fait que des recherches DNS, mais dans le future, pourra regarder dans hosts, NIS, etc.

   lwresd est essentiellement un serveur de nom cache uniquement. Parce qu'il doit fonctionner sur tous les hôtes, il est conçu pour fonctionner sans configuration ou avec une configuration minimale.

Éléments du fichier de configuration

   La liste suivante décris les éléments utilisé dans ce document:

acl_name Le nom d'une address_match_list comme définis par la déclaration acl
address_match_list Une liste d'un ou plusieurs ip_addr, ip_prefix, key_id ou acl_name
masters_list Une liste nommé d'un ou plusieurs ip_addr avec optionnellement key_id et/ou ip_port
domain_name Une chaîne qui est utilisée comme nom DNS
namelist Une liste d'un ou plusieurs éléments domain_name
doted_decimal Un à 4 entiers de 0 à 255 séparés par des '.'
ip4_addr Une adresse IPv4
ip6_addr Une adresse IPv6
ip_addr une ip4_addr ou ip6_addr
ip_dscp Un nombre entre 0 et 63, utilisé pour sélectionner un point de code de services différentiés (DSCP) à utiliser pour le trafique sortant dans les OS qui supportent DSCP.
ip_port Un numéro de port IP (0 à 65535)
ip_prefix Un masque de sous-réseau
key_id Une domain_name représentant le nom d'une clé partagée
key_list Une liste d'une ou plusieurs key_id
number Un nombre entien non-négatif 32bits
path_name Chemin de fichier
port_list Une liste d'un ip_port ou une plage de port
size_spec Entien non-signé 64bits
yes_or_no soit yes soit no
dialup_option yes, no, notify, notify-passive, refresh, ou passive.

Liste de correspondance d'adresses

Syntaxe:
address_match_list = address_match_list_element ; [ address_match_list_element; ... ]
address_match_list_element = [ ! ] (ip_address [/length] | key key_id | acl_name | { address_match_list } )

Commentaires

Syntaxe:
/*    ceci est un commentaire */
// ceci est un commentaire
# ceci est un commenentaire

Déclaration

acl Définis une liste d'adresse ip nommée
controls Déclare des canaux de contrôle utilisé par rndc
include Inclure un fichier
key Spécifie les information de clé pour l'authentification et l'autorisation
logging Spécifie ce que le serveur log, et où
lwres Configure named pour agir également comme résolveur léger
masters Définis une liste de serveurs maîtres.
options Contrôle les options de configuration globale au serveur
server Définis certaines options par serveur
statistics-channels Déclare des canaux de communication pour avoir accès aux statistiques de named
trusted-keys Définis les clés DNSSEC de confiance
managed-keys Liste les clé DNSSEC à conserver à jour avec rfc5011
view Définis une vue
zone définis une zone

ACL

   Les mots clés intégrés sont:

any Matche tous les hôtes
none Ne matche aucun hôte
localhost Matche les IPv4 et IPv6 de toutes les interfaces réseaux dans le système. Cette liste est dynamique
localnets Matche tous les hôtes dans un réseau IPv4 ou IPv6 pour lequel le système à une interface.

   Quand BIND 9 est construit avec GeoIP, les acl peuvent également être utilisées pour des restrictions d'accès géographique, avec un élément sous la forme geoip [db database] field value. field indique quel champ correspondre (country, region, city, continent, postal, metro, area, tz, isp, org, asnum, domain, et netspeed).

Controls


controls {
    [ inet ( ip_addr |    *    ) [ port ip_port ] allow { address_match_list } keys { key_list }; ] [ inet ...; ]
    [ unix path perm number owner number group number keys { key_list }; ] [ unix ...; ] };

   La déclaration controls déclare les canaux de contrôle à utiliser par les administrateurs système pour contrôler les opérations du serveur. Ces canaux sont utilisés par rndc. Un canal inet est un socket TCP. Le port par défaut est 953. La capacité à utiliser des commandes dans le canal est contrôlé par les clauses allow et keys. Un canal de contrôle unix est un socket unix écoutant dans le chemin spécifié.

   Si aucune déclaration controls n'est spécifiée, named en définis un sur l'interface de bouclage à l'adresse 127.0.0.1 et tente de charger une clé dans rndc.key dans $SYSCONFDIR (spécifié à la compilation). pour désactiver l'utilisation des canaux, créer une déclaration vide: controls { };

include

   Permet d'inclure d'autres fichiers de configuration

key

   La déclaration key définis une clé secrète partagée à utiliser avec TSIG ou un canal de commande. La déclaration key peut être définis globalement ou dans une déclaration view. L'algorithm spécifie l'algorithme utilisé. named supporte hmac-md5, hmac-sha1, hmac-sha224, hmac-sha384 et hmac-sha512.

logging

   La déclaration logging configure une variété d'option de logs pour le serveur. Ses canaux associent des méthodes de sortie, options de format de niveaux de sévérité avec un nom qui peut ensuite être utilisé avec la catégorie.

  Les catégories sont:

default définis les options de log pour les catégories qui n'ont pas de configuration définie.
general Tout ce qui n'est pas classifié dans des catégories sont définis ici
database Les messages liés aux bases de données utilisé en interne pour stocker les zones et données du cache
security Approbation et refus des requêtes
config traitement de fichier de configuration
resolver Résolution DNS, tel que les recherche récursives
xfer-in Transfer de zone reçus par le serveur
xfer-out Transfer de zone envoyés par le serveur
notify Le protocole NOTIFY
client traitement des demandes client
unmatched Messages que named n'est pas capable de déterminer la classe ou pour lesquels il n'y pas de vue.
network Opérations réseaux
update Mises à jour dynamique
update-security Approbation et refus de demandes de mise à jours
queries reporte les IP des client et numéro de port.
query-erros Informations sur les requêtes résultant de certaines erreurs
dispatch dispatching des packet entrants aux modules
dnssec traitement DNSSEC et TSIG
lame-servers Mauvaises configuration dans le serveurs distants, découvert par bind
delegation-only requêtes qui ont été forcés au NXDOMAIN en résultat d'une zone delegation-only
edns-disabled Requêtes qui ont été forcés à utiliser plain DNS dû à un timeoute.
RPZ Informations sur les erreurs en réponse à des stratégies de fichier de zone

query-errors

la catégorie query-errors est prévue pour un but de débuggage. au niveau de débug 1 ou +, chaque réponse avec le rcode SERVFAIL est loggé comme suit:
client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880

Qui signifie une erreur détecté à la ligne 3880 du fichier source query.c. Au debug niveau 2 et +, des informations détaillées de résolution récursive sont loggés:
fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: timed out/success [domain:example.com,
referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0, badresp:1,adberr:0,findfail:0,valfail:0]

   La première partie avent le ':' montre qu'une résolution récursive pour des enregistrements AAA de www.example.com complétés en 30.000183 secondes et le résultat final a été déterminé à la ligne 2970 du fichier source resolver.c.

   La partie suivante montre le résultat final détecté et le dernier résultat de la validation DNSSEC. Dans cet exemple, la requête a échoué parce que tous les serveurs sont down ou inateignable. La dernière partie affiche des informations de statistiques collectés pour cette tentative de résolution:

referral Le nombre de référants que le résolveur a reçu durant le processus de résolution.
restart Le nombre de cycles que le serveur a tenter les serveurs distants du domaine.
qrysent Le nombre de requêtes que le résolveur en envoyés au domaine
timeout Le nombre de timeout depuis que le résolveur a reçu la dernière réponse
lame Le nombre de serveurs lames que le résolveur a détecté soit par une réponse invalide, ou en résultat d'une recherche dans la base d'adresse de BIND9 (ADB), où les serveurs lames sont en cache.
neterr Nombre de résultats erronés que le résolveur a rencontré en envoyant des requêtes au domaine. Peut être dû au serveur inateignable et le résolveur a reçus un ICMP unreachable.
badresp Le nombre de réponses attendus (autre que lame) aux requêtes envoyées par le résolveur au domaine
adberr Erreurs en trouvant des adresses de serveur distant du domaine dans la ADB. Un cas commun est que le nom du serveur distant n'a pas d'adresse
findfail Érreurs en résolvant les adresses de serveur distant. C'est un nombre total d'erreur via le processus de résolution.
valfail Erreurs de validation DNSSEC, dans le processus de résolution.

   Au débug niveau 3 et +, les mêmes messages que le niveau 1 sont loggés pour d'autres erreurs que SERVFAIL. Noter que des réponses négatives telles que NXDOMAIN ne sont pas vus comme erreurs ici.

   Au débug niveau 4 et +, les même message que le niveau 2 sont loggés pour d'autres erreurs que SERVFAIL.

lwres


lwres {
    [ listen-on { ip_addr [port ip_port] [dscp ip_dscp] ;
    [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ view view_name; ]
    [ search { domain_name ; [ domain_name ; ... ] }; ]
    [ ndots number; ]
};

   Plusieurs déclaration lwres peuvent être configurés avec différentes propriétés. view spécifie la vue ou placer le résolveur. search est équivalent à la déclaration dans /etc/resolv.conf. Elle fournis une liste de domaine qui sont ajoutés aux noms relatifs dans les requêtes. ndots est équivalent à la déclaration dans /etc/resolv.conf, et indique le nombre de '.' minimum dans un nom de domaine relatif qui devrait résulter en un match exact avant que les éléments de search soient ajoutés

masters


masters name [port ip_port] [dscp ip_dscp] { ( masters_list |
ip_addr [port ip_port] [key key] ) ; [...] };

   Les déclarations masters permettent à un jeu commun de masters d'être facilement utilisés par plusieurs zones stub et slaves.

options

La déclaration options définis les options globales utilisées par BIND. cette déclaration peut apparaître seulement une fois dans la fichier de configuration.
options {
    [ attach-cache cache_name; ]
    [ version version_string; ]
    [ hostname hostname_string; ]
    [ server-id server_id_string; ]
    [ directory path_name; ]
    [ key-directory path_name; ]
    [ managed-keys-directory path_name; ]
    [ named-xfer path_name; ] // obsolete
    [ tkey-gssapi-keytab path_name; ]
    [ tkey-gssapi-credential principal; ]
    [ tkey-domain domainname; ]
    [ tkey-dhkey key_name key_tag; ]
    [ cache-file path_name; ] //not-used
    [ dump-file path_name; ]
    [ bindkeys-file path_name; ]
    [ secroots-file path_name; ]
    [ session-keyfile path_name; ]
    [ session-keyname key_name; ]
    [ session-keyalg algorithm_id; ]
    [ memstatistics yes_or_no; ]
    [ memstatistics-file path_name; ]
    [ pid-file path_name; ]
    [ recursing-file path_name; ]
    [ statistics-file path_name; ]
    [ zone-statistics full | terse | none; ]
    [ auth-nxdomain yes_or_no; ]
    [ deallocate-on-exit yes_or_no; ] //obsolete
    [ dialup dialup_option; ]
    [ fake-iquery yes_or_no; ]//obsolete
    [ fetch-glue yes_or_no; ] //obsolete
    [ flush-zones-on-shutdown yes_or_no; ]
    [ has-old-clients yes_or_no; ]//obsolete
    [ host-statistics yes_or_no; ]//obsolete
    [ host-statistics-max number; ]//obsolete
    [ minimal-responses yes_or_no; ]
    [ multiple-cnames yes_or_no; ] //obsolete
    [ notify yes_or_no | explicit | master-only; ]
    [ recursion yes_or_no; ]
    [ request-sit yes_or_no; ]
    [ request-nsid yes_or_no; ]
    [ rfc2308-type1 yes_or_no; ]
    [ use-id-pool yes_or_no; ] //obsolete
    [ maintain-ixfr-base yes_or_no; ] //obsolete
    [ ixfr-from-differences (yes_or_no | master | slave); ]
    [ dnssec-enable yes_or_no; ]
    [ dnssec-validation (yes_or_no | auto); ]
    [ dnssec-lookaside ( auto | no | domain trust-anchor domain ); ]
    [ dnssec-must-be-secure domain yes_or_no; ]
    [ dnssec-accept-expired yes_or_no; ]
    [ forward ( only | first ); ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ dual-stack-servers [port ip_port] [dscp ip_dscp] { ( domain_name [port ip_port] [dscp ip_dscp] | ip_addr [port ip_port] [dscp ip_dscp]) ; ... }; ]
    [ check-names ( master | slave | response ) ( warn | fail | ignore ); ]
    [ check-dup-records ( warn | fail | ignore ); ]
    [ check-mx ( warn | fail | ignore ); ]
    [ check-wildcard yes_or_no; ]
    [ check-integrity yes_or_no; ]
    [ check-mx-cname ( warn | fail | ignore ); ]
    [ check-srv-cname ( warn | fail | ignore ); ]
    [ check-sibling yes_or_no; ]
    [ check-spf ( warn | fail | ignore ); ]
    [ allow-new-zones { yes_or_no }; ]
    [ allow-notify { address_match_list }; ]
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-query-cache { address_match_list }; ]
    [ allow-query-cache-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-recursion { address_match_list }; ]
    [ allow-recursion-on { address_match_list }; ]
    [ allow-update { address_match_list }; ]
    [ allow-update-forwarding { address_match_list }; ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-update-mode ( maintain | no-resign ); ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ dnssec-secure-to-insecure yes_or_no ;]
    [ try-tcp-refresh yes_or_no; ] // obsolete
    [ allow-v6-synthesis { address_match_list }; ] // obsolete
    [ blackhole { address_match_list }; ]
    [ no-case-compress { address_match_list }; ]
    [ use-v4-udp-ports { port_list }; ]
    [ avoid-v4-udp-ports { port_list }; ]
    [ use-v6-udp-ports { port_list }; ]
    [ avoid-v6-udp-ports { port_list }; ]
    [ listen-on [ port ip_port ] [dscp ip_dscp] { address_match_list }; ]
    [ listen-on-v6 [ port ip_port] [dscp ip_dscp] { address_match_list }; ]
    [ query-source ( ( ip4_addr |    *    )
        [ port ( ip_port |    *    ) ]
        [ dscp ip_dscp] |
        [ address ( ip4_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] )
        [ dscp ip_dscp] ; ]
    [ query-source-v6 ( ( ip6_addr |    *    )
        [ port ( ip_port |    *    ) ]
        [ dscp ip_dscp] |
        [ address ( ip6_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] )
        [ dscp ip_dscp] ; ]
    [ use-queryport-pool yes_or_no; ] //obsolete
    [ queryport-pool-ports number; ] //obsolete
    [ queryport-pool-updateinterval number; ] //obsolete
    [ max-transfer-time-in number; ]
    [ max-transfer-time-out number; ]
    [ max-transfer-idle-in number; ]
    [ max-transfer-idle-out number; ]
    [ tcp-clients number; ]
    [ reserved-sockets number; ]
    [ recursive-clients number; ]
    [ serial-query-rate number; ]
    [ serial-queries number; ] //obsolete
    [ tcp-listen-queue number; ]
    [ transfer-format ( one-answer | many-answers ); ]
    [ transfers-in number; ]
    [ transfers-out number; ]
    [ transfers-per-ns number; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ notify-delay seconds ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-to-soa yes_or_no ; ]
    [ also-notify { ip_addr [port ip_port] [dscp ip_dscp] [key keyname] ; [ ip_addr [port ip_port] [dscp ip_dscp] [key keyname] ; ... ] };[ max-ixfr-log-size number; ]
    [ max-journal-size size_spec; ]
    [ coresize size_spec ; ]
    [ datasize size_spec ; ]
    [ files size_spec ; ]
    [ stacksize size_spec ; ]
    [ cleaning-interval number; ] //obsolete
    [ heartbeat-interval number; ]
    [ interface-interval number; ]
    [ statistics-interval number; ]
    [ topology { address_match_list }];
    [ sortlist { address_match_list }];
    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
    [ lame-ttl number; ]
    [ max-ncache-ttl number; ]
    [ max-cache-ttl number; ]
    [ max-zone-ttl number ; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ min-roots number; ]
    [ use-ixfr yes_or_no ; ] // obsolete
    [ provide-ixfr yes_or_no; ]
    [ request-ixfr yes_or_no; ]
    [ treat-cr-as-space yes_or_no ; ] // obsolete
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ port ip_port; ]
    [ dscp ip_dscp] ;
    [ additional-from-auth yes_or_no ; ]
    [ additional-from-cache yes_or_no ; ]
    [ random-device path_name ; ]
    [ max-cache-size size_spec ; ]
    [ match-mapped-addresses yes_or_no; ] // obsolete
    [ filter-aaaa-on-v4 ( yes_or_no | break-dnssec ); ]
    [ filter-aaaa-on-v6 ( yes_or_no | break-dnssec ); ]
    [ filter-aaaa { address_match_list }; ]
    [ dns64 ipv6-prefix {
        [ clients { address_match_list }; ]
        [ mapped { address_match_list }; ]
        [ exclude { address_match_list }; ]
        [ suffix IPv6-address; ]
        [ recursive-only yes_or_no; ]
        [ break-dnssec yes_or_no; ]
    }; ];
    [ dns64-server name ]
    [ dns64-contact name ]
    [ preferred-glue ( A | AAAA | NONE ); ]
    [ edns-udp-size number; ]
    [ max-udp-size number; ]
    [ max-rsa-exponent-size number; ]
    [ root-delegation-only [ exclude { namelist } ] ; ]
    [ querylog yes_or_no ; ]
    [ disable-algorithms domain { algorithm;
        [ algorithm; ] }; ]
    [ disable-ds-digests domain { digest_type;
        [ digest_type; ] }; ]
    [ acache-enable yes_or_no ; ]
    [ acache-cleaning-interval number; ]
    [ max-acache-size size_spec ; ]
    [ clients-per-query number ; ]
    [ max-clients-per-query number ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ empty-server name ; ]
    [ empty-contact name ; ]
    [ empty-zones-enable yes_or_no ; ]
    [ disable-empty-zone zone_name ; ]
    [ zero-no-soa-ttl yes_or_no ; ]
    [ zero-no-soa-ttl-cache yes_or_no ; ]
    [ resolver-query-timeout number ; ]
    [ deny-answer-addresses { address_match_list } [ except-from { namelist } ];]
    [ deny-answer-aliases { namelist } [ except-from { namelist } ];]
    [ prefetch number [number] ; ]
    [ rate-limit {
        [ domain domain ; ]
        [ responses-per-second [size number] [ratio fixedpoint] number ; ]
        [ referrals-per-second number ; ]
        [ nodata-per-second number ; ]
        [ nxdomains-per-second number ; ]
        [ errors-per-second number ; ]
        [ all-per-second number ; ]
        [ window number ; ]
        [ log-only yes_or_no ; ]
        [ qps-scale number ; ]
        [ ipv4-prefix-length number ; ]
        [ ipv6-prefix-length number ; ]
        [ slip number ; ]
        [ exempt-clients { address_match_list } ; ]
        [ max-table-size number ; ]
        [ min-table-size number ; ]
    } ; ]
    [ response-policy {
        zone zone_name ;
        [ policy given | disabled | passthru | drop | nxdomain | nodata | cname domain
        [ recursive-only yes_or_no ; ]
        [ max-policy-ttl number ; ] ;
        [ recursive-only yes_or_no ; ]
        [ max-policy-ttl number ; ]
        [ break-dnssec yes_or_no ; ]
        [ min-ns-dots number ; ]
        [ qname-wait-recurse yes_or_no ; ]
    } ; ]
};


attach-cache ‹string› (options,view)autorise plusieurs vues à partager une seule base de cache. Chaque vue a sa propre base de cache, mais si plusieurs vues ont la même stratégie opérationnelle pour la résolution de nom et de cacheng, ces vues peuvent partager le même cache et sauver de la mémoire et possiblement améliorer l'efficacité de résolution en utilisant cette option. L'implémentation actuelle exige que les vues partageant le même cache soient consistant avec les options suivantes: check-names, cleaning-interval, dnssec-accept-expired, dnssec-validation, max-cache-ttl, max-ncache-ttl, max-cache-size, et zero-no-soa-ttl.
directory ‹path_name› Le répertoire de travail du serveur. Tout chemins non-absolus dans le fichier de configuration sera pris comme relatif à ce répertoire.
key-directory ‹path_name› Lors de mise à jours dynamique de zone sécurisés, le répertoire où sont les fichiers de clé DNSSEC et publique/privé (ne concerne pas bind.keys, rndc.key ni session.key)
managed-keys-directory ‹path_name› Spécifie le répertoire dans lequel stocker les fichiers qui suivent les clés DNSSEC.
tkey-gssapi-keytab ‹path_name› Le fichier keytab à utiliser pour les mises à jours GSS-TSIG. Si cette option est définie et pas gssapi-credential, les mises à jours seront autorisés avec toute clé matchant un principal dans le keytab
tkey-gssapi-credential ‹principal› L'accréditif de sécurité avec lequel le serveur devrait authentifier les clés demandées par le protocole GSS-TSIG. Actuellement seul kerberos 5 est supporté, et l'accréditif est un principal kerberos que le serveur peut obtenir via le fichier de clé système définis par tkey-gssapi-keytab. Normalement ce principal est sous la forme 'DNS/server.domain'. tkey-domain doit également être définis si un keytab spécifique n'est pas définis dans tkey-gssapi-keytab
tkey-domain ‹domainname› Le domaine ajouté à tous les noms de toutes les clés partagées générées avec TKEY.
tkey-dhkey key_name key_tag; Clé Diffie-Hellman utilisée par le serveur pour générer des clés partagées avec les clients en utilisant le mode dh. Le serveur doit être capable de charger les clés publique et privée depuis les fichiers dans le répertoire de travail courant. Dans la plupart des cas, le nom de clé devrait être le nom d'hôte du serveur.
dump-file path_name Chemin du fichier où le serveur dump la base, invoqué par rndc dumpdb.
memstatistics-file path_name chemin du fichier où le serveur écrit les statistiques d'utilisation mémoire.
pid-file path_name Chemin du fichier pid où le serveur écrit sont pid.
recursing-file path_name chemin du fichier où le serveur dump les requêtes recursives, invoqué par rndc recursing.
statistics-file path_name chemin du fichier où le serveur ajoute des statistiques, invoqué par rndc stats.
bindkeys-file path_name chemin du fichier pour remplacer les clés de confiance intégrée par named.
secroots-file path_name Le chemin du fichier où le serveur dumps les security root, invoqué par rndc secroots.
session-keyfile path_name chemin du fichier dans lequel écrire un clé de session TSIG générée par named à utiliser par nsupdate -l.
session-keyname key_name Le nom de la clé à utiliser pour la clé de session TSIG. défaut: local.ddns.
session-keyalg L'algorithme à utiliser pour la clé de session TSIG. (hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512 et hmac-md5)
port ip_port port UDP/TCP d'écoute du serveur. Défaut: 53
random-device path_name Source d'entropy à utiliser par le serveur
preffered-glue ( A | AAAA | NONE ) Si spécifié, le type listé sera émis avant d'autre glue dans la section additionnelle d'une réponse.
root-delegation-only [ exclude { namelist } ] ; Active la délégation-only dans les TLD et les zones root avec une liste d'exclusion optionnelle. Si une zone delegation-only déssert également une zone enfant, il n'est pas toujours possible de déterminer si une réponse vient de la zone delegation-only ou de la zone enfant. Les enregistrements SOA NS et DNSKEY sont des enregistrements apex uniquement et une réponse correspondante qui contient ces enregistrement ou DS est traitée comme venant d'une zone enfant. les enregistrements RRSIG sont également examinés pour voir s'il y a évidence que la réponse vient de la zone enfant. Les réponse déterminée comme venant de la zone enfant ne sont pas convertis en réponse NXDOMAIN. Noter que certains TLD ne sont pas délégation-only.
disable-algorithms domain { algorithm; [ algorithm; ] }; Désactive les algorithmes DNSSEC spécifiés. Peut être spécifié plusieurs fois. Seul la déclaration match le mieux sera utilisé.
disable-ds-digests domain { digest_type; [ digest_type; ] }; Désactive le types digests DS/DLV spécifiés. Peut être spécifié plusieurs fois. Seul la déclaration match le mieux sera utilisé.
dnssec-lookaside ( auto | no | domain trust-anchor domain ); Fournis le validateur avec une méthode alternative pour valider les enregistrements DNSKEY en haut de la zone.
dnssec-must-be-secure domain yes_or_no Spécifie les hiérarchies qui doivent être ou non sécurisés (signé et validé). à no, la validation DNSSEC permet des réponses non-sûres.
dns64 ipv6-prefix { [ clients { address_match_list }; ] [ mapped { address_match_list }; ] [ exclude { address_match_list }; ] [ suffix IPv6-address; ] [ recursive-only yes_or_no; ] [ break-dnssec yes_or_no; ] }; ]; Cette directive instruit named de retourner les adresses IPv4 mappées en requêtes AAAA quand il n'y a pas de records AAAA. Prévue pour être utilisé en conjonction avec NAT64. Chaque dns64 définis un préfix DNS64.

        exclude définis une liste d'IPv6 qui seront ignorées s'il elles apparaissent dans des enregistrement AAAA du nom de domaine.
        suffix définis les bits restants des bits d'adresse IPv4.
        recursive-only à yes la synthèse dns64 ne se produit que pour les requêtes récursives.
        break-dnssec à yes, la synthèse dns64 se produit même si le résultat, si validé, crée une erreur de validation DNSSEC.

dnssec-update-mode ( maintain | no-resign ); à maintain dans une zone master qui est signée avec DNSSEC et configurée pour les mises à jours dynamiques, et si named a accès à la clé de signature privée de la zone, named signe automatiquement toutes nouveaux enregistrements ou changement et maintient les signature pour la zone en régénérant les records RRSIG quand ils approchent de la date d'expiration. À no-resign, named signe les records mais la maintenance des signatures est désactivées.
max-zone-ttl number Spécifie une valeur maximale de TTL permise. Une zone avec un TTL supérieur est rejeté. C'est utile pour DNSSEC parce qu'en régénérant une nouvelle DNSKEY, l'ancienne clé doit rester disponible jusqu'à ce que les records RRSIG aient expirés des caches. Cette option garantie que le plus grand TTL dans le zone ne sera pas supérieur.
zone-statistics full | terse | none; ] Le serveur collecte des données statistiques dans toutes les zones (full), ou des statistiques minimales (terse). les statistiques sont disponible via les canaux de statistiques, ou rndc stats
automatic-interface-scan yes_or_no Si supporté par l'OS, rescanne automatiquement les interfaces réseaux quand les adresses sont ajoutées et supprimées
allow-new-zones yes_or_no à Yes, les zones peuvent être ajoutées en temps réel, via rndc addzone ou supprimées, via rndc delzone.
auth-nxdomain yes_or_no à yes, le bit AA est toujours mis dans les réponses NXDOMAIN, même si le serveur n'est pas autoritatif. Utile pour de très vieux serveur DNS.
memstatistics yes_or_no Écris les statistiques mémoire dans le fichier spécifié par memstatistics-file en quittant.
dialup dialup_option à yes, le serveur traite toutes les zones comme si elle faisaient du transfert de zone via un lien dialup. cette option peut également être spécifiée dans une vue ou une zone. Si la zone est master, alors le serveur envoie une demande NOTIFY à tous les esclaves. Cela déclenche la vérification du numéro de série de la zone dans l'esclave. Le jeu de serveur qui reçoivent le NOTIFY peut être contrôlé par notify et also-notify. Si la zone est esclave ou stub, le serveur supprime les requêtes de refresh régulières, et les effectue seulement quand heartbeat-interval expire en plus d'envoyer des requêtes NOTIFY. à 'notify', permet d'envoyer seulement des messages NOTIFY, 'notify-passive' envoie des message NOTIFY et supprime les requêtes de refresh normales quand heartbeat-interval expire, et passive qui désactive simplement le traitement refresh normal.

dialup mode | normal refresh | heart-beat refresh | heart-beat notify
no (default)________yes_______________no_______________no____________
yes_________________no________________yes______________yes___________
notify______________yes_______________no_______________yes___________
refresh_____________no________________yes______________no____________
passive_____________no________________no_______________no____________
notify-passive______no________________no_______________yes___________

flush-zones-on-shutdown yes_or_no Quand un serveur de nom quitte du à un SIGTERM, vide ou non les écritures de zone en attente.
minimal-responses yes_or_no à yes, en générant les réponses le serveur ajoute seulement les enregistrements de l'autorité, et les sections additionnelles quand elle sont requises. Améliore les performances du serveur.
notify yes_or_no | explicit | master-only à yes, les messages DNS NOTIFY sont envoyés quand une zone est changée. Les messages sont envoyés aux serveurs listés dans les enregistrements NS de la zone, excepté le serveur maître identifié dans le champ SOA MNAME), et à tous serveurs listés dans l'option also-notify. à 'master-only', notifie sont envoyés seulement pour les zones maître. à 'explicit', notifie seulement les serveurs explicitement listés dans also-notify. Peut également être spécifié dans les déclarations de zone.
notify-to-soa yes-on-no à yes, ne vérifie pas les serveurs de nom dans le RRset NS avec les SOA MNAME. Parfois, un slave est listé dans le SOA MNAME, cette option permet de lui envoyer les messages NOTIFY
recursion yes_or_no à yes, le serveur fait le travail nécessaire pour les requêtes récursives DNS et répondre au client. Noter que à no, cela n'empêche pas les clients d'avoir les réponses dans le cache. Le caching peut se produire à cause d'opérations interne du serveur, tel que les recherche d'adresses NOTIFY.
request-nsid yes_or_no à yes, une option EDNS(0) NSID (Name Server Identifier) vide est envoyée avec toutes les requêtes aux serveurs de noms autoritatifs durant la résolution itérative. Si le serveur autoritatif retourne une options NSID dans sa réponse, son contenu est loggé dans la catégorie resolver au niveau info.
request-sit yes_or_no à yes, une option EDNS SIT (Source Identity Token) est envoyée avec la requête. Si le résolveur à précédemment échoué à parler au serveur, le SIT retourné dans la précédente transaction est envoyée. C'est utilisé par le serveur pour déterminer si le résolveur lui a parlé avant.
sit-secret yes_or_no à yes, c'est une clé secrète partagée utilisée pour générer et vérifier les options EDNS SIT dans un cluster anycast. à no, génère un secret aléatoirement au démarrage.
rfc2308-type1 yes_or_no à yes, le serveur envoie des records NS avec le SOA pour les réponses négatives.
provide-ixfr yes_or_no détermine si le serveur local, agissant comme maître, répond avec un transfert de zone incrémental. à yes, le transfert incrémental est fournis quand c'est possible.
request-ixfr yes_or_no Détermine si le serveur local, agissant comme slave, demande des transferts de zone incrémental.
additional-from-auth, additional-from-cache yes_or_no Contrôle le comportement d'un serveur autoritatif en répondant aux requêtes qui ont des données additionnelles, ou en suivant les chaînes CNAME et DNAME. Quand ces 2 options sont a yes, et qu'une requête est répondue depuis une donnée autoritative, la section data additionnelle de la réponse sera remplie en utilisant les données d'autres zones autoritatives et depuis le cache. Éviter la recherche depuis ces données additionnelles accélèrent les opérations du serveur. Ces options sont prévues pour être utilisée uniquement dans les serveurs ou vues authoritative-only, Tenter de les mettre à no sans spécifier recursion no cause le serveur à ignorer les options et logger un message d'erreur.
filter-aaaa-on-v4 yes_or_no | break-dnssec Cette option est disponible si bind9 est compilé avec --enable-filter-aaaa. Aide la transition ipv4 vers ipv6 en ne donnant pas d'adresses IPv6 aux clients DNS sauf s'ils ont des connections IPv6 Internet.
filter-aaaa-on-v6 Identique, excepté qu'il filtre les réponses AAAA aux requêtes depuis les clients ipv6 au lieu des clients IPv4. Pour filtrer toutes les réponses, définir les 2 options à yes.
ixfr-from-differences yes_or_no | master | slave À yes, si le serveur charge une nouvelle version d'une zone maître depuis son fichier de zone ou reçois une nouvelle version d'un fichier slave via un transfert de zone, il compare la nouvelle version à la précédente et calcule un jeu de différences. La différence est ainsi loggées dans le fichier journal de la zone pour que les changements puissent être transmis aux slaves comme transfert de zone incrémental. accepte également 'master' et 'slave' aux niveaux vue et option qui permet d'activer pour toutes les zones master ou slaves respectivement.
multi-master yes_or_no Devrait être activé quand il y'a plusieurs serveurs maîtres pour une zone. À yes, named ne log rien quand le numéro de série dans le maître est inférieur à ce que named à.
dnssec-enable yes_or_no Active le support DNSSEC dans named.
dnssec-validation yes_or_no Active la validation DNSSEC dans named.
dnssec-accept-expired yes_or_no Accepte les signatures expirées en vérifiant les signature DNSSEC. Définir à yes laisse named vulnérable aux attaques replay.
querylog yes_or_no Spécifie si le query logging devrait être démarré quand named démarre. Si querylog n'est pas spécifié, alors le query logging est déterminé par la présence de la catégorie de logging queries.
check-names ( master | slave | response ) ( warn | fail | ignore ); Cette option est utilisée pour restreindre le jeu de caractère et syntaxe de certains nom de domaine dans les fichiers master et/ou dans les réponse DNS reçues du réseaux. Le défaut varie en accord avec l'utilisation. Pour les zones maître, le défaut est 'fail'. Pour les zones slave, le défaut est 'warn'. Pour les réponses reçues, le défaut est 'ignore'.
check-dup-records ( warn | fail | ignore ); Vérifie les zones maître pour les enregistrements qui sont traités différemment par DNSSEC mais sémantiquement égaux en DNS plain.
check-mx ( warn | fail | ignore ); vérifie si l'enregistrement MX apparaît pour référrer à une IP.
check-wildcard yes_or_no Cette option est utilisée pour vérifier les wildcard non terminals, qui sont généralement le résultat d'une erreur de compréhension de l'algorithme de matching wildcard. Cette option affectes les zones master.
check-integrity yes_or_no Effectue des vérifications d'intégrité avant de charger une zone. Cela vérifie que les records MX et SRV réfèrent à une adresse. Pour les records MX et SRV, seuls les noms d'hôte dans la zone sont vérifiés. Pour les records NS, seuls les noms sous le top of zone sont vérifiés.
check-mx-cname ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant les enregistrement MX qui réfèrent à des CNAME.
check-srv-cname ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant les enregistrement SRV qui réfèrent à des CNAME.
check-sibling yes_or_no vérifie également si des sibling glue existent.
check-spf ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant que 2 formes de record Sender Policy Framework (records TXT commençant avec 'v=spf1' et SPF) existent ou non.
zero-no-soa-ttl yes_or_no En retournant des réponses autoritatives négatives au demandes SOA, définis le TTL de l'enregistrement SOA retourné dans la section autorité à 0.
zero-no-soa-ttl-cache yes_or_no En cachant une réponse négative d'une requête SOA définis le TTL à zero.
update-check-ksk yes_or_no à yes, vérifie le bit ksk dans chaque clé pour déterminer comment la clé devrait être utilisée en générant les RRSIGs pour une zone sécurisée. Normalement, les clés de signature de zone (c'est à dire les clés avec le bit ksk mis) sont utilisés pour signer toute la zone, alors que les clé de signature de clé (les clés avec le bit ksk mis) sont seulement utilisé pour signer le RRset DNSKEY dans la zone apex. Cependant, si cette option est à no, le bit ksk est ignoré, les ksk sont traités comme s'ils étaient des ZSK et sont utilisé pour signer toute la zone.
dnssec-dnskey-kskonly yes_or_no a yes et update-check-ksk à yes, seul les clés de signature de clé seront utilisées pour signer les RRset DNSKEY dans la zone apex. Les clés de signature de zone seront utilisées pour signer le reste de la zone, mais par le RRset DNSKEY.
dnssec-loadkeys-interval Quand une zone est configurée avec auto-dnssec maintain, sont dépôt de clé doit être vérifié périodiquement pour voir si une nouvelle clé a été ajoutée ou la métadonnée de timing d'une clé existant a été mise à jours. cette option définis la fréquence de vérification automatique, en minute. défaut: 60 (de 1 à 1440)
try-tcp-refresh yes_or_no Tente de rafraîchir la zone en utilisant TCP si les requêtes UDP échouent. pour compatibilité avec BIND8.
dnssec-secure-to-insecure yes_or_no Permet à une zone dynamique de transiter d'une zone sécure à une zone insécure en supprimant tous les records DNSKEY.

Forwarding

   Les options suivantes peuvent être utilisées pour créer un grand cache sur quelques serveurs, réduisant le trafique sur les liens vers les serveurs de nom externe. Le forwarding peut également être utilisé pour autoriser les requêtes par les serveur qui n'ont pas d'accès directe à Internet, mais souhaitent rechercher des noms exterieurs. Le forwarding se produit seulement dans le requêtes pour lequels le serveur n'est pas autoritatif et n'a pas de réponse dans son cache.

forward only | first Cette option est seulement significative si une liste de forwarders n'est pas vide. À 'first', le serveur requête les forwarders en premier, puis recherche la réponse par lui-même. À 'only', le serveur ne requête que les forwarders.
forwaders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; Spécifie les adresses IP à utiliser pour le forwarding. Peut également être configuré par domaine.

Dual-stack

   Les serveurs dual-stack sont utilisés comme serveurs de secours pour fonctionner lors de problèmes d'accessibilité du à un manque de support pour IPv4 ou IPv6 sur la machine hôte.

dual-stack-servers Spécifie les noms d'hôte ou adresses des machine avec un accès aux transport IPv4 et IPv6. Si un nom d'hôte est utilisé, le serveur doit être capable de résoudre le nom en utilisant seulement le transport qu'il a. Si la machine est dual-stackée, alors cette option n'a pas d'effet sauf si un accès à un transport a été désactivé.

Contrôle d'accès

  

allow-notify Spécifie quels hôtes sont autorisés à notifier ce serveur, un slave, ou les changements de zone en plus des zones maître. Peut également être spécifié dans une déclaration zone. Est seulement significatif pour une zone slave. Si non spécifié, traite les messages de notification seulement pour les zones maître.
allow-query Spécifie quels hôtes sont autorisés à requêter le serveur. Peut également être spécifié dans une zone.
allow-query-on Spécifie quelles adresses locales peuvent accepter les requêtes DNS. Uniquement vérifié pour les requêtes qui sont permises par allow-query. Peut être spécifié dans les déclarations de zone
allow-query-cache Spécifie quels hôtes peuvent obtenir les réponses depuis les caches. défaut: localnets; localhosts;
allow-recursion spécifie quels hôtes sont autorisés à faire de requêtes récursives sur ce serveur. défaut: localnets; localhosts;
allow-recursion-on Spécifie quelles adresses peuvent accepter des requêtes récursives
allow-update Spécifie quels hôtes sont autorisés à envoyer des mises à jours Dynamic Updates pour les zones maître.
allow-update-forwarding Spécifie quels hôtes sont autorisés à envoyer des mises à jours Dynamic Uptates aux zones esclaves à forwarder au master. défaut none, peut être any, d'autres valeurs n'ont pas de sens, vu que c'est de la responsabilité du contrôle d'accès sur serveur maître de gérer ça.
allow-transfer Spécifie quels hôtes sont autorisés à recevoir les transferts de zone du serveur. Peut également être spécifié dans les zones.
blackhole Spécifie une liste d'adresses auxquelles le serveur refusera de répondre ou d'utiliser pour résoudre une requête.
filter-aaaa Spécifie une liste d'adresses auxquelles filter-aaaa-on-v4 s'applique
no-case-compress Spécifie une liste d'adresses qui nécessite que les réponses utilisent la compression sensible à la casse. Cet ACL peut être utilisée quand named doit travailler avec des client qui ne sont pas compliant rfc1034.
resolver-query-timeout La quantité de temps que le resolver passe à tenter de répondre à une requête récursive avant d'échouer, en seconde.

Interfaces

listen-on [ port port_num ] { acl_name; } Les interfaces et ports que le serveur utilise pour répondre aux requêtes peut être spécifié ici. Il s'agit d'adresses IPv4. Plusieurs déclarations peuvent être définis.
listen-on-v6 [ port port_num ] { acl_name; } Idem pour les adresse IPv6

adresse de requête

query-source address * port *; Si le serveur ne connaît pas la réponse à une question, il va requêter d'autres serveurs de nom. Cette option spécifie l'adresse et le port utilisé pour de telles requêtes.
query-source-v6 address * port *; Idem pour ipv6

Transfert de zone

   Bind a des mécanismes en place pour faciliter les transferts de zone et définir des limites sur la quantité de charge de ce transfert dans le système.

also-notify Définis une liste d'adresses de serveurs de nom à qui envoyer également les messages NOTIFY. Cela permet de s'assurer que les copies de zone sont rapidement convergés sur les serveurs Stealth. Optionnellement un port peut être spécifié avec chaque adresse. Une clé TSIG optionnelle peut aussi être spécifié avec chaque adresse. Les listes masters peuvent être utilisées pour cela.
max-transfer-time-in termine les transferts de zone entrants durant plus longtemps que ce délai en minute. défaut 120, max 40320
max-transfer-idle-in termine les transferts de zone entrants qui ne progressent plus depuis ce délai en minute. défaut 60
max-transfer-time-out termine les transferts de zone sortants durant plus longtemps que ce délai en minute. défaut 120, max 40320
max-transfer-idle-out termine les transferts de zone sortants qui ne progressent plus depuis ce délai en minute. défaut 60
serial-query-rate Les serveurs slave vont périodiquement requêter le master pour trouver si des numéros de zone ont changés. Chacune de ces requêtes utilise une quantité de bande passante du serveur slave. Cette options définis le nombre maximum de requêtes envoyées pas secondes. défaut: 20. contrôle également le taux d'émission des messages NOTIFY pour les zone slave et master.
transfer-format Les transferts de zone peuvent être envoyés en 2 format: one-answer et many-answers. Ce dernier est plus efficace mais seulement supporté par les serveur DNS récents.
transfers-in Nombre maximum de transferts de zone entrants qui peuvent être lancés simultanément. défaut: 10. Des valeurs plus grandes peuvent accelerer la convergence des zones slaves, mais augmente la charge du système.
transfer-out Le nombre maximum de transferts de zone sortants qui peuvent être lancés simultanément. défaut: 10. Les demandes de transfert de zone au delà de cette limite seront refusés.
transfer-per-ns Le nombre maximum de transferts de zone qui peuvent être lancés simultanément depuis un serveur de nom. défaut: 2. Des valeurs plus grandes peuvent accelerer la convergence des zones slaves, mais augmente la charge du système.
transfer-source Détermine quelles adresses locales seront utilisée pour les connections IPv4 TCP utilisées pour le transfert de zone entrant sur le serveur. Détermine également l'adresse IPv4 et optionnellement le port UDP, utilisé pour les requêtes de rafraîchissement et le forward de mises à jours dynamique.
transfer-source-v6 Idem, sur ipv6
notify-source Détermine quelles adresses locale source, et optionnellement le port UDP sera utilisé pour envoyer des messages NOTIFY. Cette adresse doit apparaître dans les masters de zone des serveurs slave ou dans une clause allow-notify.
notify-source-v6 idem, sur IPv6

Liste de ports UDP

use-v4-udp-ports { range 1024 65535; }; Spécifie les port udp à utiliser pour récupérer la plage de ports éphémère.
use-v6-udp-ports { range 1024 65535; }; idem sur ipv6
avoid-v4-udp-ports {}; Permet d'excluse une plage de port
avoid-v6-udp-ports {}; Idem sur ipv6

Limites de ressource système

   Les ressources du système utilisées par le serveur peuvent être limités. la valeur 'unlimited' désactive la limite, ou utilise la valeur maximale.

coresize Taille maximum d'un core dump.
datasize quantité maximum de données mémoire que le serveur peut utiliser. C'est une limite hard.
files Nombre maximum de fichiers que le serveur peut ouvrir simultanément.
stacksize Quantité de mémoire de pile que le serveur peut utiliser.

Limites de ressources serveur

   Les options suivantes définissent les limites de la consommation de ressource du serveur forcés en interne par le serveur au lieur de l'OS

max-journal-size Définis une taille maximum pour chaque fichier journal. À l'approche de cette taille, les anciens enregistrements sont supprimés. max 2Go.
recursive-clients nombre maximum de recherches récursives simultanés que le serveur effectue à la demande des client. défaut: 1000. Chaque client récursif utilise environ 20Ko de mémoire.
tcp-clients Nombre maximum de connexions TCP simultanés que le serveur accepte. défaut: 100
reserved-sockets Nombre de descripteur de fichier réservés pour TCP, stdio, etc. Doit être suffisant pour couvrir le nombre d'interfaces utilisées par named. Défaut 512, minimum 128, et maximum = maxsockets -128
max-cache-size Quantité de mémoire à utiliser pour le cache du serveur, en octets. Quand la limite est atteinte, les enregistrement expirent prématurément.
tcp-listen-queue Profondeur de file d'écoute. défaut et minimum: 10. Si le kernel support le filtre d'acceptation 'dataready', cela contrôle également combien de connexions TCP seront mis en file dans l'espace kernel en attendant que les données soient acceptés.

Intervals de tâches périodique

heartbeat-interval Le serveur effectue des tâche de maintenance de zone pour toutes les zones marquées dialup. défaut: 60minutes.
interface-interval Le serveur scanne la liste des interfaces réseaux. défaut 60minutes
statistics-interval les statistiques du serveur sont loggés à cet interval. défaut: 60minutes

topology

Quand le serveur choisi un serveur de nom à requêter depuis une liste de serveurs de noms, il préfère celui qui est topologiquement plus proche de lui. La déclaration topologie prend une liste d'adresse, et l'interprète. La position d'une adresse dans la liste indique sa distance. Le premier élément de la liste est le plus proche.
topology {
    10/8;
    !1.2.3/24;
    { 1.2/16; 3/8; };
};

sortlist

   La réponse à une requête DNS peut consister de plusieurs RR formant un RRset. Le serveur de nom va normalement retourner les RR dans le RRset dans un ordre indéterminé. Le résolveur client devrait réarranger les RR de manière approprié, en utilisant les adresses dans le réseau local de préférence. Cependant, tous les résolveurs ne peuvent pas le faire correctement. Quand un client utilise un serveur local, le trie peut être effectué dans le serveur, basé sur l'adresse du client. Cela nécessite seulement de configurer les serveurs de nom, pas les clients.

   La déclaration sortlist prend une address_match_list et l'interprète même plus spécifiquement que la déclaration topology. Chaque déclaration doit être un address_match_list avec 1 ou 2 éléments. Le premier élément ( qui peut être uni adresse IP, un préfixe IP, un nom d'ACL ou une address_match_list imbriquée ) de chaque liste est vérifiée avec l'adresse sources de la requête jusqu'à ce qu'un match est trouvé.

   Une fois l'adresse source de la requête est matchée, si la déclaration contient seulement un élément, l'élément est placé en premier dans la réponse. Si la déclaration est une liste de 2 éléments, le second élément est traité de la même manière que dans la déclaration topology. Chaque liste a une distance assignée et l'adresse dans la réponse avec la distance minimum est placée au début de la réponse.

   Dans l'exemple suivant, les requêtes reçues depuis une des adresses de l'hôte lui-même aura une réponse d'adresse préférés sur le réseau local. Ensuite, les adresses préférées sont les adresses dans le réseaux 192.168.1/24, puis soit 192.168.2/24 soit 192.168.3/24. Les requêtes reçues depuis un hôte dans le réseaux 192.168.4/24 ou 192.168.5/24 auront d'autres adresse sur ces réseaux. Les requêtes reçues depuis un hôte dans le réseau 192.168.1/24 va préférer d'autres adresses dans le réseaux 192.168.2/24 et 192.168.3/24. Les requêtes reçues depuis un hôte dans le réseau 192.168.4/24 ou 192.168.5/24 vont seulement préférer d'autres adresse dans leur réseau respectif.


sortlist {
    // IF the local host THEN first fit on the following nets
    { localhost;
        { localnets;
            192.168.1/24;
            { 192.168.2/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.1 THEN use .1, or .2 or .3
        { 192.168.1/24;
            { 192.168.1/24;
                { 192.168.2/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.2 THEN use .2, or .1 or .3
    { 192.168.2/24;
        { 192.168.2/24;
            { 192.168.1/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.3 THEN use .3, or .1 or .2
    { 192.168.3/24;
        { 192.168.3/24;
            { 192.168.1/24; 192.168.2/24; }; }; };
    // IF .4 or .5 THEN prefer that net
    { { 192.168.4/24; 192.168.5/24; };
    };
};

rrset-order

Quand plusieurs records sont retournés dans une réponse, il peut être utile de configurer l'ordre des records placés dans la réponse. La déclaration rrset-order permet la configuration de l'ordre des records dans une réponse à plusieurs records. Un orders_spce est définis comme suit:
[class class name] [type type name] [name "domain name"] order ordering

   Si aucune classe n'est spécifiée, le défaut est ANY. Si aucun type n'est spécifié, le défaut est ANY. Si aucun nom n'est spécifié, le défaut est '*'. Les valeurs légales pour ordering sont:

fixed Les records sont retournés dans l'ordre qui ont été définis dans le fichier de zone.
random Les records sont retourné aléatoirement
cyclic Les records sont retourné en cycle round-robin.

Exemple:
rrset-order {
    class IN type A name "host.example.com" order random;
    order cyclic;
};

   Force les réponse pour les enregistrements de type A dans la classe IN ayant host.example.com comme suffixe, à toujours être retourné aléatoirement. Les autres enregistrements sont retournés de manière cyclique. Si plusieurs rrest-order sont spécifiés, ils ne sont pas combinés, le dernier s'applique.

tuning

lame-ttl Définis le ttl de mise en cache des serveur lame. 0 désactive la mise en cache. défaut 600, max 1800. Contrôle également la quantité de temps d'erreurs de validation DNSSEC qui sont mis en cache.
max-ncache-ttl Pour réduire le trafic réseau et augmenter les performances, le serveur stocke les réponses négative. Cette option définis la durée de rétention pour ces réponses dans le serveur en secondes. défaut: 10800, max 7 jours.
min-roots Nombre minimum de serveurs root requis pour une requête pour que les serveurs root soient acceptés. défaut: 2
sig-validity-interval Spécifie le nombre de jours dans le future d'expiration des signatures DNSSEC générées automatiquement en résultat à des mises à jours dynamique. Il y a un second champs optionnel qui spécifie le délai de régénération des signatures avant expiration. Le second champ est spécifié en jours si l'interval de base est supérieur à 7 jours, sinon il est spécifié en heures. l'interval de base est de 30 jours, donnant une re-signature de 7 jours et demi. Les valeurs maximum sont 10ans. 3660 jours.
sig-signing-nodes Spécifie le nombre maximum de nœuds à examiner dans chaque quantum en signant une zone avec une nouvelle DNSKEY. défaut: 100
sig-signing-signatures Spécifie un seuil de signatures qui vont terminer le traitement d'un quantum en signant une zone avec une nouvelle DNSKEY. défaut: 10.
sig-signing-type Spécifie un type RDATA privé à utiliser en génèrent des records d'état de signature. défaut: 65534. Il est prévu que ce paramètre soit supprimé une fois qu'il y aura un type standard.
min-refresh-time, max-refresh-time, min-retry-time, max-retry-time Ces options contrôlent le comportement du serveur en rafraîchissant une zone ou en retentant des transferts échoués. Généralement, les valeurs SOA pour la zone sont utilisés, mais ces valeurs sont définis par le master, donnant au serveur administrateurs de serveurs slaves peut de contrôle sur leur contenu. Ces options permettent à l'administrateur de définir un temps et tentative de refresh minimum et maximum soit par zone, par vue, ou globalement. Ces options sont valides pour les zone slaves et stub. Défaut: 300, 2419200, 500, 1209600
edns-udp-size Définis la taille de tampon UDP EDNS initial, pour contrôler la taille des paquets reçus depuis les serveurs autoritatifs en réponse aux requêtes récursives. Les valeurs valides sont 512 à 4096 (défaut). changer cette valeur est d'avoir des réponses udp à passer via des firewalls qui bloquent les paquets fragmentés et/ou bloquent les paquets DNS UDP supérieurs à 512 octets.
max-udp-size Définis la taille maximale de message UDP EDNS à envoyer en octets. Les valeurs valides sont 512 à 4096 (défaut). baisser cette valeur encourage l'utilisation de TCP.
masterfile-format Spécifie le format de fichier des fichiers de zone. Défaut: text, qui est la représentation standard, excepté pour les zone slaves, dans lequel le défaut est raw. Les autres formats sont à générer avec named-compilezone, ou dumpé par named.
clients-per-query, max-clients-per-query Définis la valeur initiale (minimal) et le nombre maximum de clients récursifs simultanément pour une requête données (‹qname,qtype,qclass›) que le serveur va accepter avant de de supprimer les clients additionnels. défaut: 10 et 100.
notify-delay Délai en secondes entre l'envoie d'un jeu de messages notify pour une zone. défaut 5
max-rsa-exponent-size Taille de l'exposant RSA maximum, en bits, qui sera accepté lors de la validation. de 35 à 4096bits.
prefetch Quand une requête est reçue pour une données cachée qui va expirer sous peut, named peut rafraîchir la donnée depuis le serveur autoritatif immédiatement, s'assurant que le cache a toujours la réponse disponible. Cette option spécifie le TTL déclencheur: quand une donnée en cache avec un TTL inférieur est rencontré durant le traitement d'une requête, elle sera rafraîchie. de 1 à 10secondes. Un second argument optionnel spécifie le TTL eligible: la plus petite valeur TTL original qui sera accepté pour un record pour être éligible au prefetching. Ce TTL doit être d'au moins 6 secondes de plus que le TTL déclencheur. défaut: 2 9.

informations de zones

   Le serveur fournis des informations de diagnostique utile au travers de zone intégrées sous le pseudo domain bind, dans la classe CHAOS. Ces zones font partie d'une vue intégrée de classe CHAOS qui est séparée de la vue par défaut de classe IN. La plupart des options de configurations globales s'appliquent à cette vue, mais certaines sont remplacées en interne: notify-recursion et allow-new-zones sont toujours à no, et rate-limit est mis pour autoriser 3 réponses par seconde. Pour désactiver ces zones, utiliser les options ci-dessous, ou cacher la vue CHAOS en définissant une vue explicite de classe CHAOS qui matche tous les clients.

version La version du serveur à reporter via une requête du nom version.bind avec le type TXT de classe CHAOS. Le défaut est le vrai numéro de version est utilisé. spécifier version none désactive le traitement des requêtes.
hostname Le nom d'hôte que le serveur devrait reporter via une requête du nom hostname.bind avec le type TXT, classe CHAOS. hostname none désactive le traitement des requêtes
server-id L'id que le serveur devrait reporter en reçevant une requête NSID (Name Server IDentifier), ou une requête de nom ID.SERVER avec le type TXT, classe CHAOS. server-id none le désactive.

Zones vide embarquées

   named a des zones embarquées vides. Ces zones devraient normalement être répondues localement et ne devraient pas être envoyées vers les serveurs root. En particulier, ces zones couvrent les espaces de nom pour les adresses des rfc1918, rfc5193, rfc5737 et rfc6598. Elles incluent l'espace de nom inversé pour les adresse locales IPv6, et les adresse de lien local, l'adresse de bouclage IPv6 et les adresses IPv6 inconnues. La liste actuelle est:

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
64.100.IN-ADDR.ARPA
65.100.IN-ADDR.ARPA
66.100.IN-ADDR.ARPA
67.100.IN-ADDR.ARPA
68.100.IN-ADDR.ARPA
69.100.IN-ADDR.ARPA
70.100.IN-ADDR.ARPA
71.100.IN-ADDR.ARPA
72.100.IN-ADDR.ARPA
73.100.IN-ADDR.ARPA
74.100.IN-ADDR.ARPA
75.100.IN-ADDR.ARPA
76.100.IN-ADDR.ARPA
77.100.IN-ADDR.ARPA
78.100.IN-ADDR.ARPA
79.100.IN-ADDR.ARPA
80.100.IN-ADDR.ARPA
81.100.IN-ADDR.ARPA
82.100.IN-ADDR.ARPA
83.100.IN-ADDR.ARPA
84.100.IN-ADDR.ARPA
85.100.IN-ADDR.ARPA
86.100.IN-ADDR.ARPA
87.100.IN-ADDR.ARPA
88.100.IN-ADDR.ARPA
89.100.IN-ADDR.ARPA
90.100.IN-ADDR.ARPA
91.100.IN-ADDR.ARPA
92.100.IN-ADDR.ARPA
93.100.IN-ADDR.ARPA
94.100.IN-ADDR.ARPA
95.100.IN-ADDR.ARPA
96.100.IN-ADDR.ARPA
97.100.IN-ADDR.ARPA
98.100.IN-ADDR.ARPA
99.100.IN-ADDR.ARPA
100.100.IN-ADDR.ARPA
101.100.IN-ADDR.ARPA
102.100.IN-ADDR.ARPA
103.100.IN-ADDR.ARPA
104.100.IN-ADDR.ARPA
105.100.IN-ADDR.ARPA
106.100.IN-ADDR.ARPA
107.100.IN-ADDR.ARPA
108.100.IN-ADDR.ARPA
109.100.IN-ADDR.ARPA
110.100.IN-ADDR.ARPA
111.100.IN-ADDR.ARPA
112.100.IN-ADDR.ARPA
113.100.IN-ADDR.ARPA
114.100.IN-ADDR.ARPA
115.100.IN-ADDR.ARPA
116.100.IN-ADDR.ARPA
117.100.IN-ADDR.ARPA
118.100.IN-ADDR.ARPA
119.100.IN-ADDR.ARPA
120.100.IN-ADDR.ARPA
121.100.IN-ADDR.ARPA
122.100.IN-ADDR.ARPA
123.100.IN-ADDR.ARPA
124.100.IN-ADDR.ARPA
125.100.IN-ADDR.ARPA
126.100.IN-ADDR.ARPA
127.100.IN-ADDR.ARPA
0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

   Les zones vides sont définissables au niveau de la vue et s'appliquent seulement aux vues de classe IN. Désactiver les zones vides sont seulement hérités depuis les options s'il n'y a pas de zones vide désactivée spécifiée au niveau de la vue. Pour remplacer la liste des zones désactivées, on peut désactiver la zone root au niveau de la vue, par exemple: disable-empty-zone ".";

empty-server spécifie que le nom de serveur va apparaître dans le record SOA retourné pour les zones vide. Si rien n'est spécifié, le nom de zone est utilisé
empty-contact Spécifie quel nom de contact appparaît dans le record SOA retourné pour les zones vides. Si rien n'est spécifié, '.' est utilisé
empty-zones-enables Active ou désactive les zones vide. Par défaut, elles sont activés.
disable-empty-zone Désactive des zones vide individuellement. Par défaut aucune n'est désactivée. Peut être spécifié plusieurs fois.

cache de section additionnel

   Le cache additionnel, également appelée acache, est un cache interne pour améliorer les performances de réponse de bind9. Quand une section de cache additionnel est activé, bind9 cache un raccourci interne vers la section additionnelle pour chaque réponse RR. Noter que acache est un mécanisme interne à bind9.

   Le cache additionnel ne change par le contenu de la réponse excepté l'ordre RRset de la section additionnelle, mais peut améliorer les performances de réponse significativement. C'est particulière efficace pour les serveurs autoritatifs pour une zone qui a de nombreuses délégations avec de nombreux glue RR.

   Pour obtenir un maximum de performances, définir additional-from-cache à no est recommandé, vu que l'implémentation actuelle de acache ne crée pas de raccourcis depuis le cache de données DNS. Un désavantage de acache est qu'il nécessite plus de mémoire. La cache de section additionnel a un effet mineur sur l'ordre RRset dans la section additionnelle. sans acache, l'ordre cyclic est effectif pour la section additionnelle aussi bien que les sections réponse et autorité. Cependant, le acache fixe l'ordre quand il est caché la première fois, et le même ordre est concervé ensuite sans regarder le rrset-order. L'effet devrait être minime vu qu'un RRset dans la section additionnelle ne contient généralement que peu de RR dans lequel l'ordre n'est pas important.

acache-enable active le acache. défaut: no.
acache-cleaning-interval en minute. Vide les entrées gelées du cache. défaut: 60
max-acache-size Taille maximale en Mo à utiliser pour le acache.

filtrage de contenu

   bind9 fournis la capacité de filtrer les réponses DNS des serveurs DNS externes contenant certains types de données dans le section réponse. Spécifiquement, il peut rejeter les adresses A ou AAAA si les adresses correspondantes matchent un liste donnée de l'option deny-answer-addresses. Il peut également rejeter les CNAME ou DNAME si le nom alias matche la liste de deny-answer-aliases. Si l'option namelist est spécifiée avec except-from, les records dont le nom requêté matche la liste seront acceptés sans regarder le filtre. De même, si le nom alias est un sous-domaine de la zone correspondancte, le filtre deny-answer-aliases ne s'applique pas; par exemple, même si example.com est spécifié pour deny-answer-aliases, www.example.com. CNAME xxx.example.com. retourné par un serveur example.com sera accepté.

deny-answer-addresses { address_match_list } [ except-from { namelist } ];] Définis les adresses ignorées et les exceptions
deny-answer-aliases { namelist } [ except-from { namelist } ]; Rejète les records CNAME ou DNAME si le nom alias matche la liste

Ré-écriture de zone de stratégie de réponse (RPZ)

   Bind9 inclus un mécanisme limité pour modifier les réponses DNS pour les demandes analogues aux blacklists DNS des anti-spams. Les réponses peuvent être changées pour refuser l'existance des domaines (NXDOMAIN), refuser l'existance d'adresses IP pour les domaines (NODATA), ou contenir d'autres adresses IP ou données.

   Les zones de stratégie de réponse sont nommés dans l'option response-policy pour la vue ou dans les options globales. Les zones de stratégie de réponse sont ordinairement des zones contenant des RRsets qui peuvent être requêtés normalement si autorisés. Il est généralement mieux de restreindre ces requête avec quelque-chose comme allow-query { localhost; };

   Une options response-policy peut supporter plusieurs zones de stratégie. Pour maximiser les performances, un arbre radix est utilisé pour rapidement identifier les zones de stratégie de réponse qui déclenchent le match de la requête actuelle. Cela impose une limite de 32 dans le nombre de zones de stratégie dans une simple response-policy. 5 déclencheurs de stratégie peuvent être encodés dans les records RPZ.

RPZ-CLIENT-IP Les records IP sont pilotés par l'adresse IP du client DNS. Ces déclencheurs sont encodés en records qui ont leur propre owner name qui sont des sous-domaines de rpz-client-ip relativisés au nom d'origine de la zone de stratégie et encode une adresse ou un block d'adresse. Les adresses IPv4 sont représentées sous la forme prefixlength.B4.B3.B2.B1.rpz-ip. Les préfixes IPv4 doivent être entre 1 et 32. Tous les 4 octets doivent être présents. B4 est la représentation décimale d'au moins un octet significatif de l'adresse IPv4 dans in-addr.arpa.

           Les adresses IPv6 sont encodés dans un format similaire: prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-ip. Chaque Wx est un chiffre hexadécimal représentant 16bits de l'adresse IPv6. Tous les mots doivent être présents, excepté les 0 consécutifs, remplacés par .zz, analogue à '::'.

QNAME Les enregistrements de stratégie QNAME sont déclenchés par les recherches de nom des requêtes et cible des enregistrement CNAME résolu pour générer la réponse. Le nom d'un QNAME est le nom de recherche relativisé à la zone de stratégie.
RPZ-IP Les déclencheurs sont des adresses IP dans un enregistrement A ou AAA dans la section ANSWER d'une réponse. Ils sont encodé comme les déclencheurs client-IP excpté comme sous-domaine rpz-ip
RPZ-NSDNAME Déclenche les correspondance de nom des serveurs autoritatfs pour les demande de nom, un parent du nom de la recherche, un CNAME pour le nom recherché, ou un parent du CNAME. Ils sont encodés comme sous-domaine de rpz-nsdname relativisé au nom d'origine RPZ. NSIP déclenche la correspondance des adresses IP dans les RRsets A et AAAA pour les domaines qui peuvent être vérifiés avec les records de stratégie NSDNAME.
RPZ-NSIP Déclencheurs encodés comme déclencheurs IP excepté comme sous-domaine rpz-nsip. Les déclencheurs NSDNAME et NSIP sont vérifiés seulement avec les noms avec au moins min-ns-dots points. La valeur par défaut est 1 pour exclure les TLD.

   Les réponses sont vérifiés avec toutes les zones de stratégie de réponse, donc 2 ou plusieurs enregistrements de stratégie peuvent être déclenchés par une réponse. Parce que les réponse DNS sont ré-écrites en accord avec au moins un record de stratégie, un simple record encodant une action (autre que les actions DISABLED) doit être choisi. Les déclencheurs ou les records qui les encodent sont choisis pour la ré-écriture dans l'ordre suivant:

- Choisis le record déclenché dans la zone qui apparaît en premier dans l'option response-policy
- Préfère CLIENT-IP à QNAME à IP à NSDNAME à NSIP dans une simple zone
- Avec les déclencheurs NSDNAME, préférer le déclencheur qui matche le nom le plus petit dans l'ordre DNSSEC
- Avec IP ou NSIP, préfère le déclencheur avec le préfixe le plus long
- Avec les déclencheurs avec la même longueur de préfixe, préfère le déclencheur IP ou NSIP qui matche la plus petite adresse IP.

   Quand le traitement d'une réponse est redémarré pour résoudre des records DNAME ou CNAME et qu'un record de stratégie n'a pas été déclenché, tous les zones de stratégie de réponse sont consultées de nouveau pour les noms DNAME ou CNAME et les adresses.

   Les jeux de record RPZ sont tout type de record DNS excepté DNAME ou DNSSEC qui encode les actions ou réponses aux recherches individuelles. N'importe quelle de ces stratégies peuvent être utilisées avec n'importe quel de ces déclencheurs. Par exemple, bien que TCP-only est communément utilisé avec les déclencheurs client-IP, il peut être utilisé avec n'importe quel déclencheur pour forcer l'utilisation de TCP pour les réponses avec les owner names dans une zone.

PASSTHRU Stratégie de liste blanche spécifiée par un CNAME dont la cible est rpz-passthru. Il impose de ne pas ré-écrire la réponse.
DROP Startégie de blacklist spécifiée par un CNAME dont la cible est rpz-drop. Détruit la réponse. Rien n'est envoyée au client DNS.
TCP-Only Stratégie spécifiée par un CNAME dont la cible est rpz-tcp-only. Il change les réponses UDP en réponses DNS tronquées qui nécessite que le client DNS retente avec TCP. Utilisé pour limiter les attaque DNS reflection.
NXDOMAIN Le domaine indéfini est encodé par un CNAME dont la cible est '.'
NODATA Le jeu vide de RR est spécifié par un CNAME dont la cible est '*.'. Il ré-écrit la réponse à NODATA ou ANCOUNT=1
Local Data Un jeu de records DNS ordinaire peut être utilisé pour répondre aux requêtes. Les recherches pour les types de records qui ne sont pas dans le jeu sont répondus avec NODATA. Une forme spécifiale est un wildcard "*.example.com".

   Toutes les action spécifiées dans les records individuels dans un zone de stratégie peuvent être remplacés avec une clause policy dans l'option response-policy. Une organisation utilisant une zone de stratégie fournie par une autre organisation peut utiliser ce mécanisme pour rediriger les domaines vers sont propre walled garden.

GIVEN Indique 'ne pas remplacer mais effectuer l'action spécifiée dans la zone.
DISABLED La stratégie ne fait rien mais log ce qui aurait été fait.
PASSTHRU, DROP, TCP-Only, NXDOMAIN, NODATA Remplace avec la stratégie par record
CNAME domain Force tous les records RPZ à agir comme s'ils étaient des records 'cname domain'

   Par défaut, les actions encodés dans une zone de stratégie de réponse sont appliqués seulement aux requêtes qui demande une récursion. Ce défaut peut être changé pour une simple zone de stratégie ou pour toutes les zones de stratégie dans une vue avec une clause recursive-only no;.Cette fonctionnalité est utile pour servir les même fichiers de zone en et hors d'un cloud rfc1918 et utilisant RPZ pour supprimer les réponses qui contiendrait des valeurs rfc1918 dans la vue.

   Également, par défaut les action RPZ sont appliquées seulement aux demandes DNS qui ne demandent pas de métadonnées DNSSEC ou quand aucun record DNSSEC n'est disponible pour le nom demandé. Cela peut être changé avec break-dnssec yes.

   Aucun enregistrement DNS n'est nécessaire pour un déclencheur QNAME ou Client-IP. Le nom ou l'adresse IP elle-même est suffisante, donc en principe le nom recherché ne doit pas être recherché récursivement. Cependant, ne pas résoudre le nom demandé peut fuiter le fait que la ré-écriture est utilisé et que ce nom est listé dans une zone de stratégie. Pour empêcher cette fuite d'information, par défaut toute récursion nécessaire pour une recherche est faite avant tout déclencheur. Vu que les domaines listés ont souvent des serveurs autoritatifs lents, ce mode peut être couteux en temps. l'option qname-wait-recurse no; change ce mode. L'option n'affecte pas les déclencheurs QNAME ou client-ip dans les zones de stratégie listées après d'autres zones contenant des déclencheurs IP, NSIP et NSDNAME, parce que la réponse serait dépendant des records RRSIG trouvés durant la résolution. Utiliser cette option peut causer des erreurs de réponse tels que SERVFAIL.

   Le TTL d'un record modifié par les stratégie RPZ sont définis depuis le TTL de l'enregistrement dans le zone de stratégie. Il est limité à la valeur maximum. max-policy-ttl change ce maximum.

Par exemple, on peu utiliser cette déclaration:
response-policy { zone "badlist"; };
et cette déclaration de zone:
zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };

Avec ce fichier de zone:
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
; QNAME policy records. There are no periods (.) after the owner names.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
*.nxdomain.domain.com CNAME . ; NXDOMAIN policy
nodata.domain.com CNAME *. ; NODATA policy
*.nodata.domain.com CNAME *. ; NODATA policy
bad.domain.com A 10.0.0.1 ; redirect to a walled garden
AAAA 2001:2::1
bzone.domain.com CNAME garden.example.com.

; do not rewrite (PASSTHRU) OK.DOMAIN.COM
ok.domain.com CNAME rpz-passthru.

; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
*.bzone.domain.com CNAME *.garden.example.com.

; IP policy records that rewrite all responses containing A records in 127/8
; except 127.0.0.1
8.0.0.0.127.rpz-ip CNAME .
32.1.0.0.127.rpz-ip CNAME rpz-passthru.

; NSDNAME and NSIP policy records
ns.domain.com.rpz-nsdname CNAME .
48.zz.2.2001.rpz-nsip CNAME .

; blacklist and whitelist some DNS clients
112.zz.2001.rpz-client-ip CNAME rpz-drop.
8.0.0.0.127.rpz-client-ip CNAME rpz-drop.

; force some DNS clients and responses in the example.com zone to TCP
16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only.
example.com CNAME rpz-tcp-only.
*.example.com CNAME rpz-tcp-only.

Limiter le taux de réponses

   Les réponses UDP excessivement identique peuvent être contrôlés en configurant un rate-limit dans une déclaration options ou view. Ce mécanisme réduit l'utilisation des serveurs autoritatifs pour amplifier les attaques DOS. Les réponses Short truncated (TC=1) peuvent être envoyées pour fournir des réponse limitées aux clients légitimes dans une plage d'adresses IP forgés. Les clients légitimes réagissent aux réponses tronquée ou supprimées en retentant avec UDP ou TCP, respectivement.

   Ce mécanisme est prévu pour les serveurs autoritatifs. Il peut être utilisé sur les serveurs récursifs mais peut ralentir les applications telles que les serveurs SMTP et les client HTTP qui recherche souvent le même domaine.

   rate-limite utilise un schéma de crédit ou un jeton. Chaque combinaison de réponse et client identique a un compte conceptuel qui apprend un nombre spécifié de crédits chaque seconde. Les réponses sont supprimées ou tronquées quand le compte est négatif. Les réponses sont suivies dans une fenêtre de temps qui est de 15 secondes par défaut, mais peut être changé avec l'option window (1 à 3600). Le compte ne peut plus être positif que sur la limite par seconde ou plus que la limite window. Quand le nombre spécifié de crédits pour une classe de réponse est 0, ces réponses ne sont plus limitées.

   Les notions de réponse identique et de client DNS pour le rate-limit ne sont pas simple. Tous les réponses à un block d'adresse sont comptés comme si c'était un seul client. Les longueurs de préfixe des blocks d'adresse sont spécifiées dans ipv4-prefix-lengh (défaut 24) et ipv6-prefix-lengh (défaut: 56).

   Tout réponse non-vide pour un nom de domaine valide (qname) et type d'enregistrement (qtype) sont identique et on une limite spécifiée par l'option responses-per-second (c à d, réponses par seconde avec seulement un simple argument et aucun modifieurs additionnels.) Le défaut est 0, qui indique qu'il ne devrait pas y avoir de limite. Les réponse vide (NODATA) sont limitées par nodata-per-second. Les demandes pour un ou tous les sous-domains indéfinis d'un domaine valide résultent en erreurs NXDOMAIN, et sont identiques sans regarder le type de recherche. Elles sont limitées par nxdomains-per-second. Cela contrôle certaines attaques en utilisant des noms aléatoire, mais peuvent être relaxés et désactivé dans les serveurs qui attendent de nombreuses réponses NXDOMAIN, tels que depuis les blacklists anti-spam. Les référants et délégations au serveur d'un domaine donné sont identique et sont limités par referrals-per-second.

   Les réponses générées depuis les wildcards locaux sont comptés et limités comme s'ils étaient pour le nom de domain parent. Cela contrôle le flooding en utilisant les noms aléatoires.

   Toutes les requêtes qui résultent en erreurs DNS autre que NXDOMAIN, tel que SERVFAIL et FORMERR, sont identique sans regarder le nom recherché (qname) ou le type de records (qtype). Cela contrôle les attaques utilisant les requêtes invalides ou distantes, sur les serveurs autoritatif cassés. Par défaut la limite sur les erreurs est la même que responses-per-second, mais peut être changé avec errors-per-seconds.

   De plus, jusqu'à 4 options responses-per-seconde (en plus de la valeur de base) peuvent être configurés, avec des paramètres additionnels pour indiquer qu'elles s'appliquent aux réponses plus grande qu'une taille donnée, ou avec un facteur d'amplification plus grand qu'une valeur donnée. Le paramètre size définis la taille de réponse DNS minimum qui va déclencher l'utilisation de cette option respones-per-second. Le paramètre ratio définis la taille de réponse / taille de requêtes DNS minimum qui sont dans la plage, à 2 décimales. Ces limites sélective sont appliquées après que d'autres limite aient été appliquées et ne s'appliquent qu'aux réponses positives.

Par exemple:
rate-limit {
    responses-per-second 10;
    responses-per-second size 1100 5;
};

Indique que les réponse devraient être limitées à 10 par seconde pour les réponses jusqu'à 1099 octets, mais seulement 5 par seconde pour les réponses plus grandes. Cette configuration:
rate-limit {
    responses-per-second 10;
    responses-per-second ratio 7.25 5;
    responses-per-second ratio 15.00 2;
};

Indiquent que les réponses devraient être limitées à 10 par seconde si le facteur d'amplification est inférieur à 7,25, 5 par seconde s'il est supérieur à 7,25, mais inférieur à 15, 2 par seconde au-delà de 15. Les tailles et ratios peuvent être utilisées ensemble, par exemple:
rate-limit {
    responses-per-second 10;
    responses-per-second size 1000 ratio 5.00 5;
    responses-per-second ratio 10.00 2;
};

   Cette configuration va limiter à 5 par seconde si le ration est au-dessus de 5 ou la taille supérieur à 1000.

   De nombreuses attaques utilisant DNS impliquent les requêtes UDP avec des adresses sources forgées. Limiter le taux empêche l'utilisation de BIND9 pour flooder un réseaux avec des réponses à des requêtes avec les adresses source forgées, mais pourrait laisser un tier bloquer les réponses aux requêtes légitimes. Il y a un mécanisme qui peut répondre à certaines requêtes légitimes d'un client dont l'adresse a été forgée dans un flood. Définir slip à 2 (son défaut) cause toute autre requête UDP à être répondue avec une réponse tronquée. La petite taille et la fréquence réduite, et le manque d'amplification des réponses les rendent moins attractive pour les attaques DOS. slip doit être entre 0 et 10. Une valeur de 0 ne tronque pas les réponses, elles sont supprimée. Une valeur de 1 cause chaque réponse à être tronquées. Certaines réponses d'erreurs telles que REFUSED ou SERVFAIL ne peuvent être remplacée avec des réponses tronquées et sont fuitées au taux slip.

   Quand le taux de recherche excède qps-scale, les valeurs responses-per-second, errors-per-second, nxdomains-per-second et all-per-second sont réduite par le ratio du taux courant à la valeur qps-scale. Cette fonctionnalité peut resserer les défense durant les ataques. Par exemple, avec qps-scale 250; responses-per-second 20; et un taux de recherche total de 1000 recherches par secondes pour toutes les recherches de tous les clients DNS incluant via TCP, alors la limite de réponses/seconde effective change à (250/1000)*20 ou 5. Les réponses envoyées via TCP ne sont pas limitées mais sont comptées pour calculer le taux de recherche par seconde.

   La clause optionnelle domain spécifie l'espace de nom auquel les limites s'appliquent. Il est possible d'utiliser différentes limites pour différents noms en spécifiant plusieurs blocks rate-limit.

   Les limiteurs de taux pour différents espaces de nom maintiennent des compteurs séparés: si, par exemple, il y a une déclaration rate-limit pour com et un autre pour example.com, les recherche correspondant à example.com ne seront pas débitée avec le limiteur de taux pour com. Si une déclaration rate-limit ne spécifie pas un domain, elle s'applique au domaine root et donc tout l'espace de nom DNS.

   Les communautés de clients DNS peuvent avoir leur propre limites en plaçant les déclaration rate-limit dans le vues. un rate-limit dans une vue remplace et ne complète pas les déclarations globales. Les clients DNS dans une vue peuvent être exemptés de limites avec la clause exempt-clients.

   Les réponses UDP de tous type peuvent être limitées avec la phrase all-per-second. Cette limite devrait être au moins 4 fois plus grand que les autres limites. La taille maximum de la table utilisée pour tracker les recherches et limiter le taux de réponses est définis avec max-table-size. Chaque entrée dans la table est entre 40 et 80 octets. La table a besoin approximativement d'autant d'entrée que le nombre de requêtes reçues par secondes. Défaut: 20000. Pour réduire le coût du démarrage à froid, min-table-size (défaut: 500) peut définir la taille minimum. Utiliser log-only yes; pour tester les paramètre de limitation sans supprimer une seul recherche.

server


server ip_addr[/prefixlen] {
    [ bogus yes_or_no ; ]
    [ provide-ixfr yes_or_no ; ]
    [ request-ixfr yes_or_no ; ]
    [ request-nsid yes_or_no ; ]
    [ request-sit yes_or_no ; ]
    [ edns yes_or_no ; ]
    [ edns-udp-size number ; ]
    [ nosit-udp-size number ; ]
    [ max-udp-size number ; ]
    [ transfers number ; ]
    [ transfer-format ( one-answer | many-answers ) ; ]]
    [ keys { string ; [ string ; [...]] } ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ query-source [ address ( ip_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] [dscp ip_dscp] ; ]
    [ query-source-v6 [ address ( ip_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] [dscp ip_dscp] ; ]
    [ use-queryport-pool yes_or_no; ] //obsolete
    [ queryport-pool-ports number; ] //obsolete
    [ queryport-pool-updateinterval number; ] //obsolete
};

   La déclaration server définis les caractéristiques à associer avec un serveur de noms distant. Si un préfixlen est spécifié, cela permet de couvrir plusieurs serveurs. La déclaration server peut se produire en haut de la configuration ou dans une déclaration view. Si une vue contient des déclarations server, les déclarations server dans la configuration globale sont ignorés pour la vue.

bogus yes_or_no Si un serveur distant donne de mauvaises données, empêche d'autres requêtes sur lui. défaut: no
provide-ixfr yes_or_no détermine si le serveur local, agissant comme maître, répond avec un transfert de zone incrémental. à yes, le transfert incrémental est fournis quand c'est possible.
request-ixfr yes_or_no Détermine si le serveur local, agissant comme slave, demande des transferts de zone incrémental.
request-nsid yes_or_no à yes, une option EDNS(0) NSID (Name Server Identifier) vide est envoyée avec toutes les requêtes aux serveurs de noms autoritatifs durant la résolution itérative. Si le serveur autoritatif retourne une options NSID dans sa réponse, son contenu est loggé dans la catégorie resolver au niveau info.
request-sit yes_or_no à yes, une option EDNS SIT (Source Identity Token) est envoyée avec le requête. Si le résolveur à précédemment échoué à parler au serveur, le SIT retourné dans la précédente transaction est envoyée. C'est utilisé par le serveur pour déterminer si le résolveur lui a parlé avant.
edns yes_or_no Détermine si le serveur local tente d'utiliser EDNS en communiquant avec le serveur distant. défaut: yes
edns-udp-size Définis la taille de tampon UDP EDNS initial, pour contrôler la taille des paquets reçus depuis les serveurs autoritatifs en réponse aux requêtes récursives. Les valeurs valides sont 512 à 4096 (défaut). changer cette valeur est d'avoir des réponses udp à passer via des firewalls qui bloquent les paquets fragmentés et/ou bloquent les paquets DNS UDP supérieurs à 512 octets.
max-udp-size Définis la taille maximale de message UDP EDNS à envoyer en octets. Les valeurs valides sont 512 à 4096 (défaut). baisser cette valeur encourage l'utilisation de TCP.
nosit-udp-size number Définis la taille maximum de réponses UDP qui seront envoyées pour les requêtes sans un token d'identité valide.
transfers number Limite le nombre de transfert de zones entrantes simultané du serveur spécifié. Non spécifié, la limite est définis en accord avec transfers-per-ns
transfer-format Les transferts de zone peuvent être envoyés en 2 format: one-answer et many-answers. Ce dernier est plus efficace mais seulement supporté par les serveur DNS récents.
keys { string ; [ string ; [...]] } Identifie une clé définie par la déclaration key, à utiliser pour une transaction TSIG en dialoguant avec le serveur distant.
transfer-source Détermine quelles adresses locales seront utilisée pour les connections IPv4 TCP utilisées pour le transfert de zone entrant sur le serveur. Détermine également l'adresse IPv4 et optionnellement le port UDP, utilisé pour les requêtes de rafraîchissement et le forward de mises à jours dynamique.
transfer-source-v6 Idem, sur ipv6
query-source address * port *; Si le serveur ne connaît pas la réponse à une question, il va requêter d'autres serveurs de nom. Cette option spécifie l'adresse et le port utilisé pour de telles requêtes.
query-source-v6 address * port *; Idem pour ipv6
[SECTION] name="statistics-channels" table="codes" imbrication="0"
statistics-channels {
 [ inet ( ip_addr | * ) [ port ip_port ]  [ allow { address_match_list } ]; ]
 [ inet ...; ] };

   Les déclaration statistics-channels déclarent des canaux de communication à utiliser par les administrateurs système pour obtenir un accès à des informations de statistiques du serveur de nom. Cette déclaration est prévue pour être flexible pour supporter plusieurs protocoles de communication dans le future, mais actuellement seul l'accès HTTP est supporté. Il nécessite que bind9 soit compilé avec libxml2 et/ou json-c. Ces déclarations sont acceptées même s'il est construit sans la librairie, mais les accès HTTP vont échouer dans erreur.

   Un canal de contrôle inet est un socket TCP en écoute au port spécifié sur l'ip spécifiée qui peut être une adresse IPv4 ou IPv6. La tentative d'ouvrir un canal de statistique est restreinds par la clause allow. Les statistiques sont disponible dans divers formats et vues en fonction de l'URI utilisée pour y accéder. Le format xml est accéssible via http://127.0.0.1:8888/ ou ‹http://127.0.0.1:8888/xml. Un fichier CSS est inclus qui peut formater les statistiques XML en tables quand il est lus dans un navigateur, et en graphique avec Google Charts API quand il est utilisé avec un navigateur javascript.

http://127.0.0.1:8888/xml/v2› schéma xml v2
http://127.0.0.1:8888/xml/v3› schéma xml v3
http://127.0.0.1:8888/xml/v3/status Sous-jeu de statistiques (uptime et dernières reconfigurations)
http://127.0.0.1:8888/xml/v3/server Statistiques serveur et résolveur
http://127.0.0.1:8888/xml/v3/zones Statistiques de zone
http://127.0.0.1:8888/xml/v3/net status réseau et socket
http://127.0.0.1:8888/xml/v3/mem statistiques mémoire
http://127.0.0.1:8888/xml/v3/tasks statistiques des tâches
http://127.0.0.1:8888/json Jeu complet de statistiques au format JSON
http://127.0.0.1:8888/json/v1/status Sous-jeu de statistiques (uptime et dernières reconfigurations) JSON
http://127.0.0.1:8888/json/v1/server Statistiques serveur et résolveur au format JSON
‹http://127.0.0.1:8888/json/v1/zones Statistiques de zone au format JSON
‹http://127.0.0.1:8888/json/v1/net status réseau et socket au format JSON
‹http://127.0.0.1:8888/json/v1/mem statistiques mémoire au format JSON
‹http://127.0.0.1:8888/json/v1/tasks statistiques des tâches au format JSON

trusted-keys


trusted-keys {
    string number number number string ;
    [ string number number number string ; [...]]
};

   La déclaration trusted-keys définis les racines de sécurité DNSSEC. Une racide de sécurité est définie quand la clé publique pour une zone non-authoritative est connue, mais ne peut pas être obtenue de manière sécurisée via DNS, soit parce que c'est une zone root DNS ou parce que sa zone parent n'est pas signée. Une fois qu'une clé a été configurée comme clé de confiance, elle est traitée comme si elle avait été validée. Le résolveur tente la validation DNSSEC sur toutes les données dans les sous-domaines d'un security root.

   Toutes les clés (et zones correspondantes) listées dans trusted-keys sont réputés exister sans regarder de quelle zone parent il s'agit. Similairement pour toutes les clés listées dans trusted-keys, elles sont utilisées pour valider le RRsed DNSKEY. Le RRset DS du parent ne sera pas utilisé.

   Cette déclaration peut contenir plusieurs clés, chacune consistant du nom de domaine de la clé, les flags, protocoles, algorithmes, et la représentation base64 de la clé. La déclaration trusted-keys peut être définis globalement, ou dans une vue. Si les 2 sont en place, elles sont additives.

managed-keys


managed-keys {
    name initial-key flags protocol algorithm key-data ;
    [ name initial-key flags protocol algorithm key-data ; [...]]
};

   la déclaration managed-keys, tout comme trusted-keys, définis les DNSSEC security roots. La différence est que managed-keys peut être conservé à jour automatiquement, sans l'intervention de l'opérateur. Cette déclaration possède un mot clé supplémentaire, initial-key, contenant la clé d'initialisation.

view


view view_name
    [class] {
    match-clients { address_match_list };
    match-destinations { address_match_list };
    match-recursive-only yes_or_no ;
    [ view_option; ...]
    [ zone_statement; ...]
};

   La déclaration view implémente le split-dns. Elle possède ses propres zones. Les zones disponible dans une vue ne sont accessible que pour cette vue. De nombreuses options de la déclaration options peuvent également être utilisées dans une déclaration vue.

zone

zone master:
zone zone_name [class] {
    type master;
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-update { address_match_list }; ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ update-policy local | { update_policy_rule [...] }; ]
    [ also-notify { ip_addr [port ip_port] [dscp ip_dscp] ;
        [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ check-mx (warn|fail|ignore) ; ]
    [ check-wildcard yes_or_no; ]
    [ check-spf ( warn | fail | ignore ); ]
    [ check-integrity yes_or_no ; ]
    [ dialup dialup_option ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ journal string ; ]
    [ max-journal-size size_spec; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ ixfr-base string ; ]
    [ ixfr-from-differences yes_or_no; ]
    [ ixfr-tmp-file string ; ]
    [ request-ixfr yes_or_no ; ]
    [ maintain-ixfr-base yes_or_no ; ]
    [ max-ixfr-log-size number ; ]
    [ max-transfer-idle-out number ; ]
    [ max-transfer-time-out number ; ]
    [ notify yes_or_no | explicit | master-only ; ]
    [ notify-delay seconds ; ]
    [ notify-to-soa yes_or_no; ]
    [ pubkey number number number string ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ zone-statistics full | terse | none; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ key-directory path_name; ]
    [ auto-dnssec allow|maintain|off; ]
    [ inline-signing yes_or_no; ]
    [ zero-no-soa-ttl yes_or_no ; ]
    [ serial-update-method increment|unixtime; ]
    [ max-zone-ttl number ; ]
};

zone slave:
zone zone_name [class] {
    type slave;
    [ allow-notify { address_match_list }; ]
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-update-forwarding { address_match_list }; ]
    [ dnssec-update-mode ( maintain | no-resign ); ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ dnssec-secure-to-insecure yes_or_no ; ]
    [ try-tcp-refresh yes_or_no; ]
    [ also-notify [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ dialup dialup_option ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ journal string ; ]
    [ max-journal-size size_spec; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ ixfr-base string ; ]
    [ ixfr-from-differences yes_or_no; ]
    [ ixfr-tmp-file string ; ]
    [ maintain-ixfr-base yes_or_no ; ]
    [ masters [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ max-ixfr-log-size number ; ]
    [ max-transfer-idle-in number ; ]
    [ max-transfer-idle-out number ; ]
    [ max-transfer-time-in number ; ]
    [ max-transfer-time-out number ; ]
    [ notify yes_or_no | explicit | master-only ; ]
    [ notify-delay seconds ; ]
    [ notify-to-soa yes_or_no; ]
    [ pubkey number number number string ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *)
        [port ip_port]
        [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ zone-statistics full | terse | none; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ key-directory path_name; ]
    [ auto-dnssec allow|maintain|off; ]
    [ inline-signing yes_or_no; ]
    [ multi-master yes_or_no ; ]
    [ zero-no-soa-ttl yes_or_no ; ]
};

zone hint
zone zone_name [class] {
    type hint;
    file string ;
    [ delegation-only yes_or_no ; ]
    [ check-names (warn|fail|ignore) ; ] // Not Implemented.
};

zone stub
zone zone_name [class] {
    type stub;
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ dialup dialup_option ; ]
    [ delegation-only yes_or_no ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ masters [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ max-transfer-idle-in number ; ]
    [ max-transfer-time-in number ; ]
    [ pubkey number number number string ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *)
        [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *)
        [port ip_port] [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ zone-statistics yes_or_no ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ multi-master yes_or_no ; ]
};

zone static-stub:
zone zone_name [class] {
    type static-stub;
    [ allow-query { address_match_list }; ]
    [ server-addresses { [ ip_addr ; ... ] }; ]
    [ server-names { [ namelist ] }; ]
    [ zone-statistics yes_or_no ; ]
};

zone forward:
zone zone_name [class] {
    type forward;
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ delegation-only yes_or_no ; ]
};

zone redirect:
zone "." [class] {
    type redirect;
    file string ;
    [ masterfile-format (text|raw|map) ; ]
    [ allow-query { address_match_list }; ]
    [ max-zone-ttl number ; ]
};

zone delegation-only:
zone zone_name [class] {
    type delegation-only;
};

zone référencée:
zone zone_name [class] {
    [ in-view string ; ]
};

types de zone

master Le serveur a une copie maître des données de la zone et est capable de fournir des réponse autoritatives pour lui.
slave une zone esclave est un réplica de la zone maître.
stub Une zone stub est similaire à une zone esclave, excepté qu'elle ne réplique que les records NS de la zone maître et non la zone entière. Les zones stub ne sont pas standard. Non recommandé.
static-stub Similaire à une zone stub, mais les données de zone sont configurés statiquement.
forward Une zone forward est une manière de configurer un forwarding par domaine. Une zone forward peut contenir des déclations forward et/ou forwarders.
hint Le jeu de serveurs de nom racine est spécifié en utilisant ce type de zone.
redirect Les zones redirect sont utilisées pour fournir des réponses aux requêtes quand la résolution normale retourne NXDOMAIN. Seul une zone redirect est supportée par vue.
delegation-only C'est utilisé pour forcer le status de delegation-only des zones d'infrastructure (COM, NET, ORG). Toute réponse reçue sans délégation implicite ou explicite dans la section authority seront traité comme NXDOMAIN. Ne s'applique pas dans l'apex de zone.

Classes

   Le nom de la zone peut optionnellement être suivi par une classe. Si une classe n'est pas spécifiée, la classe IN est assumée. La classe hesiod est nommée pour un service d'information du projet Athena du MIT. Elle est utilisée pour partager des informations sur diverses bases de données, tels que les utilisateurs, groupes, imprimantes, etc. HS est synonyme de hesiod. Un autre développement du MIT est chaosnet, un protocole LAN créé dans les années 1970.

options de zone

update-policy local | { update_policy_rule [...] }; voir plus bas
also-notify n'a de sens que si notify est actif pour cette zone. Le jeu de machines qui vont recevoir un messages DNS NOTIFY pour cette zone.
check-names ( fail | warn | ignore ) Cette option est utilisée pour restreindre le jeu de caractères et la syntaxe de certains noms de domaine dans les fichiers master et/ou les réponses DNS reçues du réseaux
database Spécifie le type de base à utiliser pour stocker les données de zone. La chaîne est interprétée comme une listed de mots séparés par un espace blank. Le premier mot identifie le type de base, et les autres mots sont passés en argument à la base à interpréter. (défaut: rbt), la base red-black-tree in-memory natif de bind9. Cette base n'a pas d'argument.
delegation-only Ce flag ne s'applique qu'aux zones forward, hint, et stub. À yes, toutes les zones sont également traitées comme si elle étaient également de type delegation-only.
forward ( only | first ) N'a de sens que si la zone a une liste forwarders. only échoue si le forwarding échoue, first, tente dans ce cas une résolution normale.
forwarders non spécifié dans une zone forward, aucun forwarding n'est fait.
journal permet d'écraser le nom de fichier du journal par défaut.
zone-statistics yes_or_no à yes, le serveur conserve des informations de statistique pour cette zone, qui peuvent être dumpé dans le statistics-file définis dans les options du serveur.
server-address dans les zone static-stub, liste d'adresses IP pour lesquelles les requêtes devraient être envoyés en résolution récursive pour la zone.
server-names dans les zone static-stub, liste les noms de domaine des serveurs de nom qui agissent comme serveurs autoritatifs.
ixfr-from-differences Noter que les choix master et slave ne sont pas disponible au niveaux des zones.
auto-dnssec ( allow | maintain | off ) Les zones configurées pour le DNS dynamique peuvent également utiliser cette option pour permettre différents niveaux de gestion de clé DNSSEC automatique. 'allow' permet aux clés d'être mises à jours et de resigner la zone quand l'utilisateur émet la commande rndc sign zonename. 'maintain' est identique, mais ajuste également automatiquement les clés DNSSEC de la zone en accord avec les métadonnées de timing de clé. 'off' désactive la fonctionnalité
serial-update-method (increment | unixtime ) Les zones configurées pour le DNS dynamique peuvent utiliser cette option pour définir la méthode de mise à jours qui sera utilisée pour le numéro de série de la zone dans le SOA.
inline-signing à yes, active la signature "bump in the wire" d'une zone, où une zone non-signée y est transférée et chargée depuis le disque et une version signée de la zone est servie, avec possiblement, un numéro de série différent. désactivé par défaut.

Stratégie de mise à jours dynamique

   BIND9 supporte 2 méthodes alternatives d'acceptation de clients pour effectuer des mises à jours dynamique dans une zone, configuré par les options allow-update et update-policy, respectivement.

   allow-update fonctionne de la même manière que dans les versions précédentes de bind. Il donne aux clients la permission de mettre à jours les enregistrements de n'importe quel nom dans la zone.

   update-policy permet un contrôle plus fin sur les mises à jours permises. Un jeu de règles est spécifié, où chaque règle autorise ou refuse l'accès pour un ou plusieurs noms à mettre à jours. Si la mise à jours dynamique nécessite que le message soit signé, l'identité du signataire peut être déterminé.

   Les règles sont spécifiées dans l'option de zone update-policy, et sont seulement significatifs pour les zones maître. Quand la déclaration update-policy est présente, allow-update ne doit pas être présent. La déclaration update-policy examine seulement le signataire du message; l'adresse sources n'est pas utilisée.

   Il y a une règle update-policy prédéfinie qui peut être activée avec la commande update-policy local. Activer cette règle génère une clé de session TSIG et la place dans un fichier (par défaut: /var/run/named/session.key, le nom de la clé local-ddns, et l'algorithm HMAC-SHA256, peut être changé avec les options session-‹xxx›), et autorise cette clé à mettre à jours la zone.

   Un client fonctionnant sur le système local, avec les permissions appropriées, peut lire ce fichier et l'utiliser pour signer les demandes de mise à jours. Cette règle est équivalente à update-policy { grant local-ddns zonesub any; };

   La commande nsupdate -l envoie des demandes de mise à jours à l'hôte local, et les signes en utilisant a clé de session.

D'autres définitions ressemblent à:
( grant | deny ) identity nametype [ name ] [ types ]

   Chaque règle autorise ou refuse les privilèges. Une fois qu'un message matche une règle, l'opération est immédiatement autorisé ou refusé et aucune autre règle n'est examinée. Une règle est matchée quand le signataire matche le champs identity, le nom matche le champ name avec le champs nametype, et le type matche les types spécifiés dans le champs type.

   Aucun signataire n'est requis pour tcp-self et 6to4-self cependant la conversion du mappage inverse / préfixe doit matcher le champ identity.

   Le champ identity spécifie un nom ou un nom wildcard. Normalement, c'est le nom d'une clé TSIG utilisée pour signer le demande de mise à jour. Quand un échange TKEY a été utilisé pour créer un secret partagé, l'identité de la clé partagée est la même que l'identité de la clé utilisée pour authentifier l'échange TKEY. TKEY est également la méthode de négociation utilisée par GSS-TSIG, qui établis une identité que est le principal Kerberos du client, tel que 'user@host.domain'. Quand le champ identity spécifie un nom wildcard, il est sujet à l'expansion DNS, donc la règle s'applique à plusieurs identités. Le champs identity doit contenir un nom fqdn.

   Pour les types de nom krb5-self, ms-self, krb5-subdomain, et ms-subdomain, le champ identity spécifie le royaume Windows ou Kerberos auquel la machine appartient.

   Le champs nametype a 13 valeurs:

name Exact match. Cette réglè est identique au contenu du champ name.
subdomain Cette règle matche quand le nom à mettre à jours est un sous-domaine au, ou identique au, contenu du champ name.
zonesub similaire, excepté qu'elle matche quand le nom à mettre à jours est un sou-domaine de la zone dans laquelle update-policy apparaît.
wildcard Le champs nom est sujet à expansion DNS, et cette règle matche quand le nom à mettre à jours est une expansion valide
self Cette règle matche quand le nom à mettre à jours matche le contenu de identity. Le champ name est ignoré mais devrait être identique à identity.
selfsub Similaire à self excepté que les sous-domaines de self sont également mis à jours.
selfwild Similaire à self excepté que seul les sous-domaines de self sont mis à jours.
ms-self Cette règle prend un principal de machine Windows (machine@REALM) et le convertit en machine.realm.
ms-subdomain Cette règle prend un principal de machine Windows (machine@REALM) et le convertit en machine.realm pour mettre à jours les sous-domaines de machine.realm.
krb5-self Cette règle prend un principal de machine Kerberos (host/machine@REALM) et le convertit en machine.realm.
krb5-subdomain Cette règle prend un principal de machine Kerberos (host/machine@REALM) et le convertit en machine.realm pour mettre à jours les sous-domaines de machine.realm.
tcp-self Autorise les mises à jours qui ont été envoyés via TCP et pour lequelles le mappage standard pour initier l'adresse IP dans in-adddr.arpa et ip6.arpa match le nom à mettre à jours. Noter qu'il est théoriquement possible de spoofer ces sessions TCP.
6to4-self Autorise le préfixe 6to4 à être mis à jours par une connexion TCP depuis le réseaux 6to4 ou depuis l'adresse IPv4 correspondante. C'est prévu pour pouvoir ajouter des RRsets NS ou DNAME.
external Cette règle autorise named à déférer la décision de l'accès à un service exterme. La méthode de communication avec le service est spécifié dans le champs identity, le format est "local:path" où path est l'emplacement d'un socket unix. Actuellement local est le seul mécanisme supporté. Les requêtes au service externe sont envoyés via le socket unix en datagrammes. Le service répond avec une valeur 4 octets contenant soit 0 soit 1.

   Dans tous les cas le champ name doit spécifier un nom fqdn. Si aucun type n'est spécifié explicitement, cette règle matche tous les types excepté RRSIG, NS, SOA, NSEC, NSEC3. Les types peuvent être spécifiés par nom, incluant "ANY" qui matche tous les types sauf NSEC et NSEC3, qui ne peuvent jamais être mis à jours.

Plusieurs vues

   Quand les vues sont utilisées, une zone peut être référencée par plus d'une d'entre-elles. Souvent, les vues contiennent différentes zones avec le même nom, permettant à différents client de reçevoir des réponses différentes pour la même requête. Parfois, plusieurs vues contiennent des zones identiques. La zone in-view fournis une manière efficace de le faire: elle permet à une vue de référencer une zone qui a été définie dans le vue précédemment définie.

Fichier de zone

   Un nom de domaine identifie un nœud. Chaque nœud a un jeu d'informations de ressources, qui peut être vide. Ce jeu de ressources associé avec un nom particulier est composé de RR séparés. L'ordre RR dans un jeu n'est pas significatif et n'a pas besoin d'être préservé par les serveurs de nom, résolveurs, ou autres parties du DNS. Cependant, trier plusieurs RR est permis dans un but d'optimisation. Les composants d'un Resource Records sont:

owner name Le nom de domaine où le RR est trouvé
type Une valeur 16bits qui spécifie le type d'enregistrement
TTL le TTL du RR. Ce champs est un entier 32bits en secondes, utilisé par les résolveurs quand ils cachent les RR.
class Une valeur 16bits qui identifie une famille de protocole ou une instance de protocole.
RDATA La donnée de ressource. Le format des données est spécifique au type.

   Les types suivants sont des RR valides:

A Une adresse IPv4 d'hôte décrite dans la rfc1035
AAAA adresse IPv6, décrite dans la rfc1886
A6 Adresse IPv6. Peut être une adresse partielle (un suffixe) et une indirection vers le nom où le reste de l'adresse peut être trouvée. Expérimental. Décrit dans la rfc2874.
AFSDB Emplacement des serveurs de base de données AFS. Expérimental. décris dans la rfc1183
APL Liste de préfixe d'adresse. Expérimental. Décrit dans la rfc3123
CERT Maintient un certificat numérique. Décris dans la rfc2538
CNAME Identifie le nom canonique d'un alias. décris dans la rfc1035
DHCID Uilisé pour identifier quel client DHCP est associé avec ce nom. Décris dans la rfc4701
DNAME Remplace le nom de domaine spécifié avec un autre nom de domaine à recherche. Alias effectivement toute une arborescence de l'espace de nom de domaine au lieu d'un simple enregistrement comme dans le cas d'un CNAME. Décris dans la rfc2672
DNSKEY Stocke une clé publique associée avec une zone DNS signée. Décrit dans la rfc 4034
DS Stocke le hash d'une clé publique associée avec une zone DNS signée. Décris dans la rfc4034
GPOS Spécifie la position globale. Remplacée par LOC
HINFO Identifie le CPU et l'OS utilisé par un hôte. Décris dans la rfc1035
IPSECKEY Fournis une méthode pour stocker un clé IPsec dans DNS. Décris dans la rfc4025
ISDN Resprésentation des adresses ISDN. Expérimental. Décris dans la rfc1183.
KEY Stocke une clé publique associée avec un nom DNS. Utilisé dans DNSSEC original, remplacé par DNSKEY dans DNSSECbis, mais reste utilisé avec SIG(0). Décris dans la rfc2535 et 2931
KX Identifie un échangeur de clé pour ce nom DNS. Décris dans la rc2230
LOC Pour stocker les informations GPS. Décris dans la rfc1876. Expérimental.
MX Identifie un échange de mail pour le domaine avec un préfixe 16-bits suivis par le nom d'hôte de l'échange de mail. Décris dans les rfc974 et 1035
NAPTR Name authority Pointer. Décris dans la rfc1706
NSAP Un point d'accès de service réseaux. Décris dans la rfc1706
NS Serveur de nom autoritatif pour le domaine. Décris dans la rfc1035
NSEC Utilisé dans DNSSECbis pour indiquer que les RR avec un owner name dans un certain interval de nom n'existent pas dans une zone et indique quels types de RR sont présent pour un nom existant. Décris dans la rfc4034
NSEC3 Identique à NSEC, mais est plus couteux pour le serveur et le client. Décris dans la rfc5155
NSEC3PARAM Utilisé dans DNSSECbis pour dire au serveur autoritatif quelles chaînes NSEC3 sont disponibles. Décris dans la rfc5155.
NXT remplacé par NSEC dans DNSSECbis. Dcéris dans la rfc2535
PTR Un pointer vers une autre partie de l'espace de nom de domaine. Décris dans la rfc1035
PX Fournis le mappage entre la rfc822 et les adresse X.400. Décris dans la rfc2163
RP Information des personnes responsable du domaine. expérimental. Décris dans la rfc1183
RRSIG Contients les données de signature DNSSECbis. Décris dans la rfrc4034
RT liaison route-through pour les hôtes qui n'ont pas leur propre aire d'adresse réseaux. Expérimental. Décris dans la rfc1183
SIG Contient les données de signature DNSSEC. Remplacé par RRSIG dans DNSSECbis. Décris dans la rfc2535 et 2931
SOA Identifie le départ de la zone d'autorité. Décris dans la rfc1035
SPF Contient le Sender Policy Framework pour un domaine de messagerie donné. Décris dans la rfc4408
SRV Information sur des services connus (remplace WKS). Décris dans la rfc2782.
SSHFP Fournis une manière sécurisée de publier des empreintes de clés ssh. Décris dans la rfc4255.
TXT enregistrement text. Décris dans la rfc1035
WKS Remplacé par SRV
X25 Représentation des adresse réseaux X.25. Expérimental. Décris dans la rfc1183

   Les classes suivante sont valides:

IN l'Internet
CH Chaosnet.
HS Hesiod

Définir les TTL

   Le TTL du champ RR est une entier 32 bits représenté en unités de secondes, et est principalement utilisés par les résolveurs quand ils cachent leur RR. Le TTL décris combien de temps un RR peut être maintenu en cache avant d'être supprimé. 3 types de TTL sont actuellement utilisés dans une zone:

SOA Le dernier champs dans le SOA est la TTL de cache négatif. Il contrôle le temps que d'autres serveurs vont maintenir en cache le no-such-domain (NXDOMAIN) pour vous. Le temps maximum est 3 heures.
$TTL La directive TTL en haut de la zone (avant le SOA) donne un TTL par défaut pour tous les RR sans jeu TTL spécifique.
RR TTLs Chaque RR peut avoir un TTL comme second champs dans le RR, qui va contrôler la durée en cache.

Mappage inverse dans IPv4

   La résolution de nom inverse est accomplie au moyen d'un domaine in-addr.arpa et d'enregistrements PTR. Les entrées dans le domaine in-addr.arpa sont créés dans l'ordre inverse. La ligne $ORIGIN sert à fournir le contexte.

Autres directives de fichier de zone

   Le format de fichier maître a été initialement définis dans la rfc1035 et a ensuite été étendu. Bien que le format de fichier maître lui-même est indépendant de la classe, tous les enregistrements dans un fichier maître doivent être de même classe. Les directives de fichier maître incluent $ORIGIN, $INCLUDE, et $TTL.

@ Utilisé dans un label ou nom, ce symbole représente l'origine courante. au début de la zone, c'est le nom de la zone.
$ORIGIN domain-name [comment] Jeux de nom de qui sont ajoutés à tout enregistrement non qualifié.
$INCLUDE filename [origin] [comment] Lit et traite le fichier comme s'il étair dans le fichier.
$TTL default-ttl [comment] Définis le TTL pour les enregistrements suivants.

Extension de fichier maître BIND


$GENERATE range lhs [ttl] [class] type rhs [comment]

   $GENERATE est utilisé pour créer une série d'enregistrement qui diffèrent uniquement des autres par un itérateur. $GENERATE peut être utilisé pour faciliter la génération de jeux d'enregistrements requis pour supporter les sous-délégations inversées /24 décrites dans la rfc2317: la délégation sans classe IN-ADDR.ARPA.


$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0

est équivalent à:
0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.

Génère un jeu d'enregistrements A et MX. Noter que MX est un chaîne entre guillemets, qui sont enlevés au traitement:
$ORIGIN EXAMPLE.
$GENERATE 1-127 HOST-$ A 1.2.3.$
$GENERATE 1-127 HOST-$ MX "0 ."

est équivalent à:
HOST-1.EXAMPLE. A 1.2.3.1
HOST-1.EXAMPLE. MX "0 ."
HOST-2.EXAMPLE. A 1.2.3.2
HOST-2.EXAMPLE. MX 0 .
HOST-3.EXAMPLE. A 1.2.3.3
HOST-3.EXAMPLE. MX 0 .
...
HOST-127.EXAMPLE. A 1.2.3.127
HOST-127.EXAMPLE. MX 0 .

Statistiques

   BIND9 maintient beaucoup de statistiques et fournis de nombreuses interfaces pour que les utilisateurs aient accès à ces statistiques. Les statistiques disponible incluent tous les compteurs qui étaient disponible dans BIND8 et ont du sens dans BIND9, plus d'autres informations. Les informations de statistiques sont catégorisés dans les sections suivantes:

Incoming Requests Le nombre de requêtes DNS entrantes pour chaque OPCODE
Incoming Queries Le nombre de demandes entrantes pour chaque type de RR
Outgoing Queries Le nombre de demandes sortantes pour chaque types de RR envoyé depuis le résolveur interne. maintenu par vue.
Name Server Statistics Compteurs de statistiques sans regarder les opérations de maintenance de zone telles que les transferts de zone.
Zone Maintenance Statistics Compteurs d'opérations de maintenances des zones telles que les tranfers de zone
Resolver Statistics Compteurs sur la résolution de noms dans le résolveur interne. Maintenu par vue.
Cache DB RRsets Nombre de RRsets par type de RR et noms non-existants stockés dans la base de cache. un ! indique un type de RRset étant non-existant (NXRRSET). Maintenu par vue.
Tocket I/O statistics Compteur de statistiques sur les événements réseaux

   Un sous-jeu de Name Server Statistics est collecté et affiché par zone pour lequel le serveur a l'autorité quand zone-statistics est à yes. Ces compteurs sont affichés avec leur noms de zone et vue. Dans certains cas le nom de la vue est omis pour la vue par défaut.

   Il y a actuellement 2 interfaces pour accéder aux statistiques. Une est en texte claire stocké dans le fichier statistics-file. L'autre est accessible à distance via un canal de statistiques.

Fichier de statistiques

Le format texte commence avec une ligne comme:
+++ Statistics Dump +++ (973798949)

Le nombre entre parenthèses est un horodatage Unix, mesuré en secondes depuis l'epoch. La suite est un jeu d'informations, qui sont catégorisés comme décris plus haut. Chaque section commence avec une ligne comme:
++ Name Server Statistics ++

   Chaque section consiste de lignes, chacune contenant la valeur de compteurs suivie par sa description contextuelle. Pour simplifier, les compteurs avec une valeur de 0 ne sont pas affichés.

Le fichier se termine avec une ligne similaire à la première (même horodatage):
— Statistics Dump — (973798949)

Compteurs

   Les tables suivantes résument les compteurs statistique que BIND9 fournis.

Name Server Statistics Counters

Requestv4 Requêtes IPv4 reçues. Note: compte également les requêtes non répondues.
Requestv6 Requêtes IPv6 reçues. Note: compte également les requêtes non répondues.
ReqEdns0 Requêtes EDNS(0) reçues
ReqBadEDNSVer Requêtes avec une version EDNS non-supportée reçues
ReqTSIG Requêtes avec TSIG reçues
ReqSIG0 Requêtes avec SIG(0) reçues
ReqBadSIG Requêtes avec une signature TSIG ou SIG(0) invalide reçues
ReqTCP Requêtes TCP reçues
AuthQryRej Requêtes autoritatives rejetées
RecQryRej Requêtes récursives rejetées
XfrRej Requêtes de tranfers de zone rejetées
UpdateRej Requêtes de mise à jour dynamique rejetées
Response Réponses envoyées
RespTruncated Réponses tronquées envoyées
RespEDNS0 Réponses avec EDNS(0) envoyés
RespTSIG Réponses avec TSIG envoyés
RespSIG0 Réponses avec SIG(0) envoyés
QrySuccess Demande résultant une réponses réussie. (réponse NOERROR avec au moins un RR)
QryAuthAns Requêtes résultant une réponse autoritative
QryNoauthAns Requêtes résultant une réponse non-autoritative
QryReferral Requêtes résultant une réponse référantes.
QryNxrrset Requêtes résultant une réponse NOERROR sans données.
QrySERVFAIL Demandes résultant un SERVAIL
QryFORMERR Demandes résultant un FORMERR
QryNXDOMAIN Demandes résultant un NXDOMAIN
QryRecursion Demande qui ont impliqué une récursion pour trouver la réponse finale
QryDuplicate Demande que le serveur à tenter en récursion mais découvert qu'une demande avec la même IP, port, queryID, nom, type et classe à déjà été traité.
QryDropped Recherches récursive pour lequelles le serveur a découvert un nombre excessif de recherches pour le même nom, classe et type. C'est le nombre de recherches supprimées dues aux options clients-per-query et max-clients-per-query
QryFailure Autres erreurs de recherche.
XfrReqDone Demande de transfert de zone complétés
UpdateReqFwd Demandes de mise à jours forwardés
UpdateRespFwd Réponses de mise à jours forwardés
UpdateFwdFail Mise à jours dynamique forwardés échoués
UpdateDone Mise à jours dynamique forwardés complétées
UpdateFail Mise à jours dynamique échouées
UpdateBadPrereq Mise à jours dynamique rejetées à cause de prérequis non respectés
RateDropped Réponses supprimées par les limites
RateSlipped Réponses tronquées par les limites
RPZRewrites Réponses de ré-écriture de policy zone.

Zone Maintenance Statistics Counters

NotifyOutv4 notifications IPv4 envoyées
NotifyOutv6 notifications IPv6 envoyées
NotifyInv4 notifications IPv4 reçues
NotifyInv6 notifications IPv6 reçues
NotifyRej Notifications entrantes rejetées
SOAOutv4 Recherches de SOA IPv4 envoyées
SOAOutv6 Recherches de SOA IPv6 envoyées
AXFRReqv4 AXFR IPv4 demandées
AXFRReqv6 AXFR IPv6 demandées
IXFRReqv4 IXFR IPv4 demandées
IXFRReqv6 IXFR IPv6 demandées
XfrSuccess Demandes de transferts de zone réussies
XfrFail Demandes de transferts de zone échouées

Resolver Statistics Counters

Queryv4 Recherches IPv4 envoyées
Queryv6 Recherches IPv6 envoyées
Responsev4 Réponses IPv4 reçues
Responsev6 Réponses IPv6 reçues
NXDOMAIN NXDOMAIN reçues
SERVFAIL SERVFAIL reçues
FORMERR FORMERR reçues
OtherError Autres erreurs reçues
EDNS0Fail Recherches EDNS(0) échouées
Mismatch Réponses non-correspondantes reçues. le DNS ID l'adresse source et/ou le port sources de la réponse ne correspond pas à ce qui était attendu. Peut indiquer une tentative de cache poisoning
Truncated Réponses tronquées reçues
Lame Lame délégations reçues
Retry Retentatives de recherche effectuées
QueryAbort Recherche annulées du à un contrôle de quotas
QuerySockFail Erreur en ouvrant des sockets. Généralement due à un limitation des descripteurs de fichier.
QueryTimeout Timeouts de recherche
GlueFetchv4 recherches d'adresse NS IPv4 invoquées
GlueFetchv6 recherches d'adresse NS IPv6 invoquées
GlueFetchv4Fail recherches d'adresse NS IPv4 échouées
GlueFetchv6Fail recherches d'adresse NS IPv4 échouées
ValAttempt Validation DNSSEC tentées
ValOk Validation DNSSEC réussie
ValNegOk Validation DNSSEC sur des informations négatives réussies
ValFail validations DNSSEC échouées
QryRTTnn Table de fréquence des RTTs de recherche.

Socket I/O Statistics Counters

‹TYPE›Open Sockets ouverts avec succès
‹TYPE›OpenFail Erreur d'ouverture de sockets
‹TYPE›Close Sockets fermés
‹TYPE›BindFail Bind de sockets échoués
‹TYPE›ConnFail Erreurs de connexions aux sockets
‹TYPE›Conn Connections établies avec succès
‹TYPE›AcceptFail Erreur d'acceptation de demandes de connexion entrantes. Non applicable à UDP
‹TYPE›Accept Connexions entrant acceptées. Non applicable à UDP
‹TYPE›SendErr Erreurs dans les opération d'envois sur socket
‹TYPE›RecvErr Erreurs d'opérations de reception sur socket

chroot and setuid

   BIND9 peut être lancé dans un environnement chroot. Il n'est pas nécessaire de compiler named statiquement, mais en fonction de l'OS, il peut être nécessaire de définir /dev/zero, /dev/random, /dev/log, et /etc/localtime.
^
11 février 2014

htmlpdflatexmanmd




biosdecode

biosdecode

Lit la mémoire BIOS et affiche des informations sur les structures

   biosdecode lit la mémoire BIOS et affiche des informations sur les structures. Actuellement, les structures connues sont:

SMBIOS (System Management BIOS) Utiliser dmidecode pour des informations plus détaillées
DMI ( Desktop Management Interface, ancienne version de SMBIOS) Utiliser dmidecode pour des informations plus détaillées.
SYSI
PNP (Plug And Play)
ACPI (Advanced Configuration and Power Interface)
BIOS32 (BIOS32 Service Directory)
PIR (PCI IRQ Routing)
32OS (BIOS32 Extension, propre à Compaq)
SNY (spécifique à Sony, non décodé)
VPD (Vital Product Data, propre à IBM)
FJKEYINF (Application Panel, propre à Fujitsu)

OPTIONS

-d, -dev-mem FILE Lit la mémoire depuis le fichier (défaut /dev/mem)
^
03 décembre 2016

htmlpdflatexmanmd




blkdiscard

blkdiscard

Supprime des secteurs sur un périphérique

OPTIONS

-o, --offset offset Décalage d'octet dans le système de fichier depuis lequel la recherche commence. Défaut: 0.
-l, --length length Nombre d'octets à rechercher peur les blocks à supprimer. Défaut: jusqu'à la fin du fs
-p, --step length Nombre d'octets à supprimer depuis le point de départ. Défaut: jusqu'à la fin du fs
-s, --secure Discard sécurisé, toutes les copies des blocks supprimés qui possiblement crééent un garbage collection doivent être également supprimés.
-z, --zeroout Remplis de zéro des données supprimées
-v, --verbose mode verbeux
^
07 octobre 2011

htmlpdflatexmanmd




blkid

blkid

Localiser/afficher les attributs des périphériques block

   Il peut déterminer le type de contenu que maintient un périphérique bloc, et également les attributs des métadata. blkid a 2 formes principales d'opérations: soit la recherche d'un périphérique avec une paire NAME=value spécifique, soit afficher les paires NAME=value pour un ou plusieurs périphériques.

OPTIONS

-c cachefile Lit depuis cachefile au lieu de lire depuis le cache par défaut (/etc/blkid.tab). pour démarrer avec un cache clean, spécifier /dev/null
-g Effectuer un nettoyage dans le cache pour supprimer les périphériques qui n'existent plus.
-l Recherche un périphérique qui correspond aux paramètres de recherche spécifié avec l'option -t. Si plusieurs périphériques correspondent, le périphérique avec la priorité la plus haute est retournée, et/ou le premier trouvé. Les types de périphériques dans l'ordre de priorité descendante sont: Device Mapper, EVMS, LVM, MD, et les périphériques block réguliers. Sans cette option, affiche tous le périphériques qui matchent.
-L label Recherche un périphérique avec le label (identique à -l -o device -t LABEL=label)
-u list Restreint les fonctions de sonde pour définir une liste de type d'utilisation. (filesystem, raid, crypto et other) Peut être préfixé avec 'no' pour spécifier les type que devraient être ignorés.
-U UUID Recherche un périphérique par son UUID
-o format Affiche la sortie de blkid en utilisant le format spécifié.

        full Affiche tous les tags (défaut)
        value Affiche la valeur des tags
        list Affiche les périphériques au format user-friendly (non supporté avec -p)
        device Affiche le nom des périphériques uniquement
        udev mode compatible avec vol_id
        export Affiche les paires key=values pour les importer facilement dans l'environnement.

-O bytes Recherche à l'offset donné (utile avec -p)
-p switch en mode bas-niveau (bypass le cache)
-s tag Pour chaque périphérique spécifié, affiche uniquement les tags qui matchent avec ceux spécifiés. Pour rafraîchir le cache, utiliser -s none sans autre options.
-S bytes Écrase la taille de fichier par périphérique
-t NAME=value Recherche les périphériques block avec les tokens nommés NAME qui ont la valeur value, et affiche les périphériques qui sont trouvés. Les valeurs communes pour NAME sont TYPE, LABEL et UUID.
-w writecachefile Écrit le fichier cache /etc/blkid.tab. ou dans le fichier spécifié.
device Affiche les tokens du périphérique spécifié. Peut être spécifié plusieurs fois. non spécifié, recherche les périphériques listés dans /proc/partitions.

Exemples

recherche pour tous les formats filesystems et others:
blkid -p -u filesystem,other /dev/sda1
Recherche les formats supportés sauf les RAID:
blkid -p -u noraid /dev/sda1
^
11 février 2014

htmlpdflatexmanmd




blockdev

blockdev

blockdev permet d'appeler les ioctls de périphérique block depuis la ligne de commande

OPTIONS

-q mode silencieux
-v mode verbeux

Commandes

--setro set read-only
--setrw set read/write
--getro get read-only. 1 si read-only, 0 sinon
--getss Affiche la taille de secteur en octets
--getbsz Affiche la taille de block en octets
--setbsz Définit la taille de block en octets
--getsize Affiche la taille du périphérique en secteur (BLKGETSIZE). préférer --getsz
--getsize64 Affiche la taille du périphérique en octets (BLKGETSIZE64)
--getsz Affiche la taille en secteurs de 512 octets (BLKGETSIZE64 / 512)
--setra Définis readehead en secteurs de 512 octets
--getra Affiche le readahead en secteurs de 512 octets
--setfra Définit le readahead du système de fichier (identique à --setra sur les kernels 2.6)
--getfra Récupère le readahead du système de fichier
--flushbufs Vide les tampons
--rereadpt Relit la table de partition
^
26 mai 2017

htmlpdflatexmanmd




bond2team

bond2team

Convertis une configuration bond en team

   bond2team est un outil pour convertir des options bonding en team. Les fichiers résultant sont sauvés dans un répertoire temporaire en utilisant le sytpe ifcfg par défaut.

OPTIONS

--master ‹interface› Spécifie le nom de l'interface ou du fichier ifcfg à convertir
--rename [interface] Permet de renommer l'interface
--ifcfg Définis la sortie au format ifcfg
--json Définis le format de sortie au style JSON
--bonding_opts 'bonding options' Spécifie les options bonding à convertir au lieu de lire le fichier ifcfg
--port ‹interface› Définis l'interface spécifié comme port team
--configdir ‹dir› Spécifie le répertoire de configuration (défaut: /etc/sysconfig/network-scripts)
--outputdir ‹dir› Définis le répertoire de sortie
--stdout Sort le résultat sur stdout au lieu d'un fichier
--debug Mode debug
--quiet mode silencieux

Exemples

Convertir bond0:
bond2team --master bond0
Convertir bond0, en le renommant en team0
bond2team --master bond0 --rename team0
Convertir les paramètres donnés
bond2team --bonding_opts 'mode=1 miimon=500 primary=eth1 primary_reselect=0' --port eth1 --port eth2 --port eth3 --port eth4
^
08 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/booleans

/etc/selinux/‹SELINUXTYPE›/booleans, booleans.local

Fichiers de configuration pour les booléens SELinux

   Le fichier booleans, si présent, contient les booléens pour supporter une distribution spécifique. booleans.local, si présent contient les booléens générés localement. Ces fichiers contiennent une liste de noms et leurs valeurs associés. Généralement ces fichiers ne sont pas présents (ils ont été dépréciés). Cependant s'il y a une application qui utilise les fonctions libselinux listés ci-dessous, ces fichiers peuvent être présents:

security_set_boolean_list(3)
security_load_booleans(3)

Format

   Ces fichiers ont le format suivant: boolean_name value
^
31 mars 2016

htmlpdflatexmanmd




bootctl

bootctl

Contrôle le firmware et le paramètre du gestionnaire de boot

   bootctl vérifie, met à jours, installe et supprime le chargeur de boot du système courant.

Commandes

status Vérifie et affiche les versions installées du chargeur et les variables de boot EFI
update Met à jours toutes les versions installées de systemd-boot, si la versions courante est plus récente que la version installée dans la partition système EFI. Cela inclus également le chargeurs EFI default/fallback dans /EFI/Boot/boot*.efi. Une entrée systemd-boot dans les variables de boot EFI est créé s'il n'y a pas d'entrée courante. L'entrée courante sera ajoutée à la fin le la liste de l'ordre de boot.
install Install systemd-boot dans la partitions système EFI. Une copie de systemd-boot sera stockée comme chargeur EFI default/fallback dans /EFI/Boot/boot*.efi. Une entrée systemd-boot dans les variables de boot EFI est créé et ajoutée en haut de la liste de l'ordre de boot.
remove Supprime toutes les versions installées de systemd-boot de la partition système EFI, et supprime systemd-boot des variables de boot EFI

OPTIONS

--path Chemin de la partition système EFI. Le défaut est /boot.
--no-variables Ne touche pas aux variables de boot EFI

Code de sortie

   En cas de succès, retourne 0.
^
11 février 2014

htmlpdflatexmanmd




bootlogd

bootlogd

Enregistre les messages de boot commande

   Il se lance en tâche de fond et copie toutes les chaînes envoyées à /dev/console dans un fichier de log. Si le fichier n'est pas accessible, il les conserve en mémoire jusqu'à ce qu'il soit disponible.

OPTIONS

-d Ne fork pas et se lance en tâche de fond
-c Tente d'écrire dans le fichier de log même s'il n'existe pas. Sans cette options, il attendra que ce fichier apparaisse avant d'écrire dedans, ce qui empêche d'écrire dans un fichier sous un point de montage.
-r S'il existe un fichier nommé logfile, il le renomme en logfile~, à moins que logfile~ existe.
-s S'assure que les données sont écrites dans le fichier après chaque ligne en appelant fdatasync(3). Celà ralentit fsck(8)
-l Fichier de log (défaut: /var/log/boot)
-p PID du processus. (défaut: aucun pid)
^
17 janvier 2012

htmlpdflatexmanmd




bsd-from

bsd-from, from

Affiche les noms des personnes qui ont envoyé des mails. Affiche l'en-tête des mails depuis la boite mail.

OPTIONS

-c Afficher uniquement un compteur de messages et quitte
-f file spécifie le fichier à examiner. L'utilisateur n'a alors pas à être spécifié. Lit depuis l'entrée standard si le nom du fichier n'est pas spécifié.
-s sender Seul les mails provenant des adresses contenant la chaîne spécifiée sont affichés.

   Si un utilisateur est spécifié, lit sa boite mail au lieu de la boite de l'émetteur de from.

Variables d'environnement

MAIL Si définis, l'emplacement de la boite mail de l'émetteur, sinon utilise /var/mail
^
17 janvier 2012

htmlpdflatexmanmd




bsd-mailx

bsd-mailx, mail, mailx, Mail

système de traitement intelligent de mails qui a une syntaxe proche de ed

OPTIONS

-a Spécifie des champs d'en-tête additionnels sur la ligne de commande, tels que "X-Loop:foo@bar" etc. Doit être entre ' ' si la chaîne contient des espaces. Peut-être spécifié plusieurs fois, les en-têtes seront concaténés.
-b bcc-addr Envoie des copies à bcc-addr
-c cc-addr Envoie des copies à une liste d'utilisateurs, séparés par une ','
-d mode debug
-E  N'envoie pas un message avec un corps vide
-f [file] Lit dans le contenu de votre boite mail (ou du fichier spécifié) pour traitement; quand vous quittez, mail écrit les messages récupérés dans ce fichier.
-I force mail à ce lancer en mode interactif, mais si l'entrée n'est pas un terminal. En particulier, le caractère ',' utilisé en envoyant un mail, est seulement disponible interactivement.
-i Ignore les signaux d'interruption tty. Utile en utilisant mail sur des lignes téléphones avec du bruit.
-N Inhibe l'affichage initial des en-têtes de message en lisant le mail ou en éditant un dossier mail.
-n  Inhibe la lecture de /etc/mail.rc au démarrage
-s subject Spécifie le sujet sur la ligne de commande
-u user Équivalent à mail -f /var/mail/user excepté qu'un lock est fait.
-v mode verbeux

Actions de démarrage

   Au démarrage, mail exécute les commandes dans le fichier de commande système, /etc/mail.rc, sauf si -n est spécifié. Ensuite, les commandes dans le fichier de commande utilisateur .mailrc sont exécutés. mail détermine ainsi si l'utilisateur demande un nouveau message à envoyer ou les messages existant dans sa boite mail.

envoyer des mails

   Pour envoyer un message à une ou plusieurs personnes, mail peut être invoqué avec les arguments qui sont les noms de destinataires. Vous pouvez ensuite taper votre message, suivit par CTRL+D.

Lire un mail

   Sans argument, mail vérifie vos mails, puis les affiches, une ligne d'en-tête pas message trouvé. Le message courant est le numéro 1 et peut être affiché en utilisant la commande print. + et - permettent de se déplacer dans les messages, ou encore en spécifiant le numéro du message.

Supprimer un mail

   Après avoir lu un mail, vous pouvez le supprimer ou répondre. La suppression n'est pas irréversible; le message peut être récupéré en donnant son numéro.

Spécifier des messages

   Des commandes telles que print et delete peuvent être donnés en liste de numéros de message comme argument pour l'appliquer à plusieurs messages en une seule fois. delete 1 2 supprime les message 1 et 2, delete 1-5 supprime les messages 1 à 5, * signifie tous les messages et $ le dernier message. top sert à afficher les premières lignes d'un message.

Répondre à un mail

   reply permet de répondre à un message. mail traite les lignes commençant par un tilde. m va placer une copie du message courant dans la réponse.

Terminer une session de traitement de mail

   Vous pouvez terminer une session mail avec la commande quit. Les messages lus vont dans mbox sauf s'ils ont été supprimés. Les messages non lus vont dans le post office

Liste de distribution système et personnel

   Il est possible de créer des listes de distribution personnelles. Peuvent être créées dans .mailrc:

  alias liste bill jfk mark toto@uubu.fr

  Cette liste peut être affichées avec la commande alias. Les listes de distribution système peuvent être créées en éditant /etc/aliases. La différence est qu'une liste personnelle spécifie les destinataires, pour les listes systèmes, l'alias est utilisé.

Mails réseaux

   mail a des options définissable dans .mailrc pour modifier son fonctionnement. (Voir plus bas)

Sommaire

   Chaque commande peut prendre des arguments. Les commandes n'ont pas besoin d'être tapées entièrement. Pour les commandes qui nécessitent une liste, si aucune liste n'est donnée, la prochaine liste qui satisfait la commande est utilisée.

- Affiche le message précédant (si un nombre est donné, va au nième message précédent)
! Exécute la commande shell.
alias Sans argument, affiche tous les alias définis. Avec un argument, créé un nouvel alias ou change un existant.
alternates Utile si vous avez des comptes sur plusieurs machines. Peut être utilisé pour informer mail que les adresses listées sont à vous. Quand vous répondez aux messages, mail ne va pas envoyer une copie du mail à toutes les adresses listées. Sans argument, le set courant de noms alternatifs est affiché.
chdir Change le répertoire de travail de l'utilisateur. Sans argument, change le répertoire de login de l'utilisateur
copy fait la même chose que save, excepté qu'elle ne marque pas les messages pour la suppressions quand vous quittez.
delete prend une liste de messages en arguments et les marque pour suppression. Ces messages ne seront pas sauvegardés dans mbox
dp supprime le message courant et affiche le message courant
edit prend une liste de messages en argument et le lance dans l'éditeur de texte pour chacun d'eux.
exit Quitte et retourne au shell
file identique à folder
folder Switch dans un nouveau fichier ou répertoire mail. Sans argument écrit les changements faits dans le fichier courant et lit dans le nouveau fichier. Certains caractères spéciaux pris en charge : # signifie le fichier précédent, % pour la boite mail système, %user pour la boite mail système de l'utilisateur, & pour le fichier mbox et +folder pour un fichier dans le répertoire.
folders Liste les noms du répertoire dans votre répertoire.
from Prend une liste de messages et affiche les en-têtes
headers Liste les headers
hold Prend une liste de messages et les marque à sauvegarder dans la boite système au lieu de mbox.
ignore Ajoute la liste des champs d'en-tête nommés à la liste des ignores. Ces champs ne sont pas affichés
inc Incorpore les nouveaux message arrivés pendant que mail est en train de lire.
mail Prend en argument les noms de login et les noms de groupes de distribution et leur envoie le mail
mbox Indique qu'une liste de messages est envoyée à mbox dans votre home quand vous quittez.
more Prend une liste de message et invoque le pager sur cette liste
next va au message suivant
preserve synonyme de hold
Print comme print mais affiche les en-têtes ignorés
print Prend une liste de messages et l'affiche
quit Termine la session, sauvegarde tous les non supprimés, ceux non sauvegardés dans la mbox
Reply Répond à l'auteur uniquement
reply Prend une liste de message et envoie un mail à l'émetteur et tous le contenu du message spécifié
respond synonyme de reply
retain Ajoute la liste des champs d'en-tête à la retained list. Seul ces champs sont affichés dans le terminal
save Prend une liste de message et un nom de fichier et attache chaque message en retour à la fin du fichier.
saveignore Les champs d'en-tête ainsi marqués sont filtré avant sauvegarde
saveretain les champs d'en-tête ainsi marqués sont les seuls sauvés avec un message
set Sans argument, affiche toutes les variables. Sinon, définis une option. Les arguments sont sous la forme option=value ou option.
shell Invoque une version interactive du shell
size Prend une liste de messages et affiche la tailles en caractères de chaque message.
source Lit les commandes depuis un fichier
top Prend une liste de message et affiche les première lignes de chaque. Le nombre de ligne est contrôlé par la variable toplines
Type Identique à Print
Type Identique à Print
unalias Prend une liste de noms définis par alias et ignore les groupes de l'utilisateur. Les noms des groupes n'ont plus de signification.
undelete Prend une liste de message et les marque à ne pas supprimer
unread Prend une liste de message et les marque non lus
unset Prend une liste d'option et annule leur valeurs ; l'inverse de set
visual Prend une liste de message et invoque l'éditeur de texte
write Similaire à save, excepté que seul le corp du message est sauvegardé
xit synonyme de exit
z mail présente les en-têtes de messages

Échappements

   Ces caractères sont utilisés pour l'écriture des messages pour effectuer les fonctions spéciales. Les tildes sont seulement reconnus en début de ligne.

bname Ajoute les noms donnés à la liste bcc mais ne fait pas apparaître les noms dans Cc:
cname Ajoute les noms donnés à la liste CC
d Lit le fichier dead.letter depuis votre home
e invoque l'éditeur de texte
Fmessages Identique à f, excepté que tous les en-têtes sont inclus
fmessages Lit les messages nommés dans le message à envoyer. Sans argument, lit le message courant
h Édite les en-têtes
Mmessages Identique à m, excepté que les en-têtes sont inclus
mmessages Lit les messages nommés dans le message à envoyer, indenté par une tabulation ou par la valeur de indentprefix. Sans argument, lit le message courant
p Affiche le message collecté, préfacés par les en-têtes
q Annule l'envoie du message, copiant le message dans dead.letter si save est mis
Rstring Utilise string comme champ répondre à
rfilename
‹filename Lit le fichier nommé dans le message
sstring La chaine nommée devient le sujet
tname Ajoute les noms donnés à la liste des destinataires
v Invoque un éditeur alternatif, définis par l'option VISUAL
wfilename Écrit le message dans le fichier nommé
x Annule le message en cours d'envoi
!command Exécute les commande shell indiquée
|command Pipe le message dans la commande comme un filtre. si la commande ne donne pas de sortie ou se termine anormalement, le message original est conservé. fmt est souvent utilisé pour justifier le message
:mail-command
_mail-command Exécute la commande mail donnée.
string Insert la chaine de texte dans le message préfixé par un
. Simule la fin de fichier sur l'entrée

Options de mail

Ces options sont contrôlées via les commandes set et unset.
append force les messages sauvés dans mbox à être ajouté à la fin au lieu du début.
ask, asksub demande le sujet de chaque message que vous envoyez
askbcc demande le champ additionnel bcc
askcc demande le champs CC
autoinc les nouveaux mail sont automatiquement incorporés quand ils arrivent
autoprint la commande delete fonctionne comme dp
debug affiche des informations de débogage
dot mail interprète un ; seul sur une ligne comme terminaison d'un message à envoyer
hold Est utilisé pour maintenir les messages dans la boite mail par défaut
ignore les signaux d'interruption depuis le terminal sont ignorés.
ignoreof mail refuse un ctrl-D à la fin d'un message
keep mail tronque votre mailbox système au lieu de la supprimer quand elle est vide
keepsave la commande save ne sauve pas dans mbox, mais les retient
metoo quand un groupe qui contient l'émetteur est étendu, celui-ci est supprimé. Cette option empêche de l'enlever
noheader Identique que -N
nosave normalement, quand un mail est annulé via ctrl-C, mail copie la lettre partielle dans dead.leter. nosave empêche cette sauvegarde
quiet supprime l'affichage de la version quand mail est invoqué
replyall Inverse le sens des commande reply et Reply
searchheaders un spécifieur de liste de message sous la forme "/x:y" va étendre tous les messages contenant la sous-chaîne 'y' dans le champs d'en-tête 'x'. si 'x' est omis, le sujet est utilisé. La forme "/to:y" étend tous les messages contenant 'y' dans "To", "Cc" ou "Bcc"
skipentry N'envoie pas de mail avec un corps vide
verbose identique à -v

Options de valeurs de chaîne

EDITOR Chemin de l'éditeur de texte à utiliser avec la commande edit et e. (défaut: /usr/bin/ex)
LISTER Chemin du listeur de répertoire à utiliser dans la commande folders (défaut: /bin/ls)
MBOX Nom du fichier mbox (défaut : mbox)
PAGER Chemin du programme à utiliser dans la commande more. (Défaut: more)
REPLYTO Si définis, est utilisé pour initialiser le champ Reply-To pour les messages sortant
SHELL Chemin du shell à utiliser dans les commandes !
TMPDIR Répertoire pour les fichiers temporaires
VISUAL Chemin de l'éditeur de texte à utiliser dans la commande visual (défaut : /usr/bin/vi)
crt Utilisé comme seuil pour déterminer la longueur d'un message avant que PAGER soit utilisé pour le lire
escape Si définis, le premier caractère de cette option donne le caractère à utiliser à la place de
folder Le nom du répertoire à utiliser pour stocker les répertoire de messages
indentprefix Chaîne utilisée par m pour indenter les messages à la place du caractère normal de tabulation (^I)
record Si définis, donne le chemin du fichier utilisé pour enregistrer les mails sortant. Sinon les mails ne sont pas sauvegardés
screen Taille de la fenêtre des en-têtes de message pour z
sendmail Chemin d'un système de livraison de mail alternatif
toplines Si définis, donne le nombre de lignes d'un message à afficher avec la commande top, normalement, les 5 première lignes

Variables d'environnement

HOME Répertoire personnel de l'utilisateur
LOGNAME Nom de l'utilisateur
USER nom de l'utilisateur
SHELL Shell courant de l'utilisateur
DEAD Emplacement du fichier dead.letter
PAGER Pager à utiliser
LISTER Chemin du listeur de répertoire à utiliser dans la commande folders
EDITOR Nom de l'éditeur par défaut
VISUAL Nom de l'éditeur par défaut
REPLYTO Si définis, est utilisé pour initialiser le champ Reply-To pour les messages sortant
MAIL Si définis, l'emplacement de la boite mail de l'émetteur, sinon utilise /var/mail
MAILRC Emplacement du fichier .mailrc
MBOX Emplacement du fichier mbox

Fichiers

/var/mail/rpc /var/mail/sylvain Dossier des mails (sauf si MAIL)
/mbox Anciens mail de l'utilisateur
/.mailrc Commandes initiales de mail. Peut être remplacé par la variable MAILRC
/tmp/R* Fichiers temporaires
/etc/mail.rc Fichier d'initialisation système
^
17 janvier 2012

htmlpdflatexmanmd




bsd-write

bsd-write, write

Envoie un message à un autre utilisateur

   Le destinataire reçoit un message sous la forme:

  Message from yourname@yourhost on yourtty at hh:mm ...

   Les autres lignes que vous entrez seront copiées sur le terminal de l'utilisateur. Si l'autre utilisateur veut répondre, il doit utiliser write également.

   Une fois finis, taper un end-of-line ou le caractère d'interruption. L'autre utilisateur va voir le message EOF, indiquant que la conversation est terminée.

   Vous pouvez empêcher les autres (sauf root) de vous écrire avec la commande mesg(1)

   Si le destinataire est loggé sur plusieurs terminaux, vous pouvez spécifier sur quel terminal écrire. Alternativement, vous pouvez laisser write sélectionner un des terminaux - il va sélectionner celui qui a le moins de temps d'inactivité.

   Le protocole traditionnel pour écrire à quelqu'un est que la chaîne '-o', soit à la fin d'une ligne ou seul sur une ligne, signifie que l'autre personne est prêt à écrire. La chaîne 'oo' veut dire que l'autre personne suppose que la conversation est terminée.

^
31 mars 2016

htmlpdflatexmanmd




busctl

busctl

Examiner et superviser le bus D-Bus

OPTIONS

--address=ADDRESS Se connecte au bus spécifié par l'adresse au lieu d'utiliser celui par défaut
--show-machine En affichant la liste des paires, affiche une colonne contenant les noms des conteneurs auxquels ils appartiennent.
--unique En affichant la liste des paires, afficher seulement les noms uniques (sous la forme :number.number)
--acquired L'opposé de --unique. Uniquement les noms connus sont affichés.
--activatable En affichant la liste des paires, affiche seulement les paires qui ne sont pas encore activés, mais peuvent être démarrés automatiquement si accédés.
--match=MATCH En affichant les messages échangés, affiche seulement le sous-jeu correspondant au match
--size= Utilisé avec la commande capture, spécifie la taille de message bus max à capturer. Défaut: 4096
--list Utilisé avec la commande tree, affiche une liste plate de chemins d'objets au lieu d'une arborescence.
-quiet Utilisé avec la commande call, supprime l'affichage du payload de réponse. Noter que cela n'empêche pas les erreurs retournées d'être affichés.
--verbose Avec les commandes call et get-property, affiche dans un format plus verbeux
--expect-reply=BOOL Utilisé avec la commande call, spécifie si busctl devrait attendre la fin du call de méthode, afficher la donnée de la réponse de la méthode, et retourne un succès ou un échec via de code de sortie du process. Défaut: yes
--auto-start=BOOL Utilisé avec la commande call, spécifi si le call de méthode devrait implicitement activer le service appelé, qui ne devrait pas être encore en cours d'exécution mais est configuré en auto-start. Défaut: yes
--allow-interactive-authorization=BOOL Utilisé avec la commande call, spécifie si les services peuvent forcer l'autorisation interactive tout en exécutant l'opération, si la stratégie de sécurité est configurée pour cela. Défaut: yes
--timeout=SECS Utilisé avec la commande call, spécifie le temps max d'attente pour la fin du call de methode. Par défaut, assume des secondes (peut être spécifié avec ms, us, s, min, h, d, w, month, y). Noter que ce timeout ne s'applique pas si --expect-reply=no est utilisé. Défaut: 25s.
--augment-creds=BOOL Contrôle si les données d'accréditifs reportées par list ou status devraient être augmenté avec les données de /proc. Activé, les données affichées peuvent être inconsistantes, vu que les données dans /proc peuvent être plus récentes que le reste des informations d'accréditifs. Défaut: yes
--user Dialogue avec le gestionnaire de service de l'utilisateur appelant, au lieu du gestionnaire de service système.
--system Dialogue avec le gestionnaire de service système.
-H, --host= Exécute l'opération à distance. Spécifie un nom d'hôte, ou un nom d'utilisateur est un nom d'hôte séparé par un @ pour s'y connecter. Le nom d'hôte peut optionnellement être suffixé par un nom de conteneur, séparé par un :, qui connecte directement au conteneur spécifique sur l'hôte spécifié. Il utilise ssh pour dialoguer avec une instance de gestionnaire de machine. Les noms de conteneur peuvent être énumérés avec machinectl -H ‹host›
-M, --machine= Exécute l'opération dans un conteneur local. Spécifie un nom de conteneur
--no-pager Ne sort pas la sortie dans un pager
--no-legend N'affiche pas la légende (en-tête et pied de page)

Commandes

list Affiche tous les paires sur le bus, par noms de service. Par défaut, affiche tous les noms.
status [SERVICE] Affiche les information de processus et d'accréditifs d'un service, un processus, ou le propriétaire du bus.
monitor [SERVICE...] Dump les message échangés. Si SERVICE est spécifié, affiche les message vers et depuis ce paire. Sinon affiche tous les messages sur le bus.
capture [SERVICE...] Similaire à monitor mais écris la sortie au format pcap.
tree [SERVICE...] Affiche une arborescence d'objet d'un ou plusieurs services. Si SERVICE est spécifié, affiche l'arborescence d'objet des services spécifiés, sinon affiche toutes les arborescences sur le bus.
introspect SERVICE OBJECT [INTERFACE] Affiche les interfaces, méthodes, propriétés et signaux de l'objet spécifié (identifié par son chemin) sur le service spécifié. Si l'argument interface est passé, la sortie est limitée aux membres de l'interface spécifiée.
call SERVICE OBJECT INTERFACE METHOD [SIGNATURE [ARGUMENT...]] Invoque une méthode et affiche la réponse. Prend un nom de service, un chemin d'objet, nom d'interface et nom de méthode. Si les paramètres doivent être passés à l'appel de la méthode, une chaîne signature est requise, suivie par les arguments, individuellement formatés comme chaîne. Pour les détails du format utilisé, voir plus bas. Pour supprimer la sortie de la donnée retournée, utiliser l'option --quiet.
get-property SERVICE OBJECT INTERFACE PROPERTY... Récupère la valeur courante d'une ou plusieurs propriétés d'objet. Plusieurs propriétés peuvent être spécifiés à la fois.
set-property SERVICE OBJECT INTERFACE PROPERTY SIGNATURE ARGUMENT... Définis la valeurs courante d'une propriété d'objet.

Format de paramètres

   Les commandes call et set-property prennent une chaîne signature suivie par une liste de paramètres formatés comme chaîne (voir la spécification D-Bus pour les chaînes de signature). Pour les types simple, chaque paramètre suivant la signature devrait simplement être la valeur du paramètre formaté comme chaîne. les valeurs booléennes peuvent être formatées en "true", "yes", "on", ou "1". Pour les tableaux, un argument numérique pour le nombre d'entrées doit être spécifié. Pour les variantes, la signature du contenu doit être spécifié, suivi par le contenu. Pour les dictionnaires et structures, le contenu doit être spécifié directement.

formater une simple chaîne "jawoll"
s jawoll
formater un tableau de chaîne avec 2 entrées:
as 3 hello world foobar
formater un tableau dictionnaire qui map les chaînes en variantes, consistant de 3 entrées. La chaîne "One" est assignée à la chaîne "Eins". "Two" à l'entier 32-bits 2, Yes est assigné comme booléen positif:
a{sv} 3 One s Eins Two u 2 Yes b true

Exemples

Les 2 commandes suivantes écrivent d'abord une propriété puis la lisent. La propriété est trouvée dans l'objet /org/freedesktop/systemd1 du service org.freedesktop.systemd1. Le nom de la propriété est "LogLevel" sur l'interface "org.freedesktop.systemd1.Manager".
busctl set-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel s debug
busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel s "debug"
Les 2 commandes suivantes lisent une propriété qui contient un tableau de chaînes, et affichent d'abords au format simple, puis au format verbeux
busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment
as 2 "LANG=en_US.UTF-8" "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
busctl get-property --verbose org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment
ARRAY "s" {
STRING "LANG=en_US.UTF-8";
STRING "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin";
};
La commande suivante invoque une méthode StartUnit sur l'interface org.freedesktop.systemd1.Manager de l'objet org/freedesktop/systemd1 du service org.freedesktop.systemd1, et lui passe 2 chaînes cups.service et replace.
busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace"
o "/org/freedesktop/systemd1/job/42684"
^
25 avril 2017

htmlpdflatexmanmd




cache_check

cache_check

réparer les métadonnées cache

OPTIONS

-q, --quiet mode silencieux
--super-block-only Ne vérifie que la présence du superbloc
--skip-mappings ne vérifie pas le mappage de block qui constitue la majeur partie des métadonnées
--skip-hints Ne vérifie pas les valeurs de stratégie des métadonnées
--skip-discards Ne vérifie pas les bits discard dans les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




cache_dump

cache_dump

dump les métadonnées cache du périphérique sur stdout

OPTIONS

-r, --repair Répare les métadonnée durant le dump
^
25 avril 2017

htmlpdflatexmanmd




cache_repair

cache_repair

Répare les métadonnées cache

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




cache_restore

cache_restore

restaure le fichier de métadonnées de cache

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
{--debug-override-metadata-version} ‹integer› spécifie la version des métadonnées. pour débuggage.
^
16 septembre 2016

htmlpdflatexmanmd




cancel

cancel

Annules des jobs d'impression

   Si aucune destination ou id n'est spécifié, le job courant sur la destination par défaut est annulée

OPTIONS

-a Annule tous les jobs sur la destination
 -E Chiffrer la connexion au serveur
-h server[:port] Spécifier le serveur
-U Spécifier un identifiant alternatif
-u Annuler les jobs possédés par l'utilisateur spécifié
-x Supprimer les fichiers de données de job en plus de l'annulation

Exemples

Annuler le job courant:
cancel
Annuler le job "myprinter-42"
cancel myprinter-42
Annuler tous les jobs
cancel -a
^
05 septembre 2015

htmlpdflatexmanmd




capsh

capsh

capability shell wrapper

   Le support et l'utilisation des capabilities Linux peuvent être explorés et contraints avec cet outil. Cet outil fournis une enveloppe pour certains types de création d'environnement de test de capabilities. Il fournis également des fonctionnalités de débuggage utile.

OPTIONS

--print Affiche les capablities en vigueur et l'état lié.
-- [args] Exécute /bin/bash avec les arguments restants.
== Exécute capsh avec les arguments restant. Utile pour tester le comportement de exec()
--caps=cap-set Définis les capabilities du processus.
--drop=cap-list Supprime les capabilities listées. Utiliser cette fonctionnalité nécessite que capsh ait CAP_SETPCAP
--inh=cap-list Définis le jeu héritable de capabilities pour le processus courant égal à ceux fournis.
--user=username Assume l'identité de l'utilisateur nommé.
--uid=id Force toutes les valeurs UID à l'id spécifié en utilisant setuid(2)
--gid=id Force toutes les valeurs GID à l'id spécifié en utilisant setgid(2)
--groups=id-list Définis les groupes supplémentaires
--keep=‹ 0|1 › En mode non pure capabilities, le kernel fournis un privilège libéral au super-user. Cependant, c'est normalement le cat quand le super-user change l'uid d'utilisateurs, puis supprime les capabilities. Dans ces situations, le kernel peut permettre au processus de conserver ses capabilities après un appel système setuid(2). Cette fonctionnalité s'appel keep-caps. Définir la valeur 2 active le keep-caps. keep-caps est toujours désactivé avec un exec().
--secbits=N
--chroot=path Exécute l'appel système chroot(2). Nécessite CAP_SHS_CHROOT.
--forkfor=sec
--killit=sig
--decode=N Fournis une manière rapide de décoder un vecteur de capability représenté sous la forme trouvée dans /proc/1/status.
--supports=xxx À mesure que le kernel évolue, des capabilities sont ajoutées. Cette options peut être utilisée pour vérifier l'existence d'une capability dans le système. un code de sortie de 0 indique que la capability est supportée.
^
15 février 2012

htmlpdflatexmanmd




card_eventmgr

card_eventmgr

Monitorer et gérer les lecteurs de carte

   Cet utilitaire est utilisé pour monitorer le statut du lecteur de carte et effectuer des actions en fonction de l’évènement.

Commandes

debug Active le mode debug
daemon Lance en tâche de fond
timeout=‹ms› Temps en ms entre 2 statuts consécutifs (défaut : 1000)
config_file=‹file› Fichier de configuration à utiliser (défaut : /etc/pam_pkcs11/card_eventmgr.conf)
^
15 février 2012

htmlpdflatexmanmd




card_eventmgr.conf

card_eventmgr.conf

Fichier de configuration pour card_eventmgr


card_eventmgr {
    daemon = false ; # lancer en tâche de fond
    debug = false ; # mode debug
    timeout = 1000 ; #polling time en ms
    # Liste des évènements et actions
    event card_insert { # carte insérée
        on_error = ignore ; # que faire en cas d’erreur (ignore=continuer, return=stopper la séquence, quit=quitter le programme)
        action = "/usr/bin/play /usr/share/sounds/warning.wav",
        "/usr/X11R6/bin/xscreensaver-command -deactivate" ; # action à exécuter
    }
    event card_remove { # carte retirée
        on_error = ignore ;
        action = "/usr/bin/play /usr/share/sounds/error.wav",
        "/usr/X11R6/bin/xscreensaver-command -lock" ;
    }
}

^
05 juin 2010

htmlpdflatexmanmd




cat

cat

Copie chaque fichier ou l'entrée standard et l'envoi sur la sortie

OPTIONS

-A, --show-all Equivalent à -vET
-b, --number-nonblank Numérote toutes les lignes non-vides en sortie, commençant à 1.
-e  Équivalent à -vE
-E, --show-ends Affiche un $ à chaque fin de ligne
-n, --number Numérote toutes les lignes, commençant à 1
-s, --sqeeze-blank Réduire les multiples lignes vide consecutives en une seule.
-t Equivalent à -vT
-T --show-tabs Affiche les caractères TAB sous la forme '^I'
-u Ignoré, pour la compatibilité POSIX
-v, --show-non-printing Affiche les caractères de contrôle excepté pour LFD et TAB en utilisant la notation '^' suivi et précède les caractères qui ont le bit haut avec 'M-'

   Sur des systèmes comme MS-DOS qui distinguent les fichiers texte des fichiers binaire, cat lit et écrire normalement en mode binaire. Cat peut s'exécuter en mode texte si une des option 'bensAE' est utilisé ou si la sortie standard est un terminal.

Exemples

Sort le contenu de f, puis l'entrée standard, puis le contenu de g
cat f - g
copie l'entrée standard sur la sortie standard
cat
Quitter ou poursuivre
ctrl+d
enregistrer l'entrée standard dans un fichier
cat › fichier
ajouter un enregistrement dns
cat ›› /etc/bind/bind.zone
^
01 février 2014

htmlpdflatexmanmd




catman

catman

Créé ou met à jours des pages de manuel pré-formatés

OPTIONS

-d, --debug Mode debug
-M path, --manpath=path Spécifie un jeu de chemin de man alternatifs au lieu de lire $MANPATH
-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath

Variables d'environnement

MANPATH Chemin de recherche pour les pages de manuel
MANSECT Liste de sections dans lesquels rechercher et dans quel ordre.
^
27 mai 2016

htmlpdflatexmanmd




cert-to-efi-hash-list

cert-to-efi-hash-list

Outils pour convertir des certificats Openssl en lists de révocation de hash de signature EFI

   cert-to-efi-hash-list prend un certificat X509 en entrée au format PEM et le convertis en fichier de liste de hash de signature EFI

OPTIONS

-g ‹guid› Utilise le guid spécifie comme propriétaire de la signature. Non spécifié, un guid avec des 0 est utilisé
-s ‹hash› Spécifie l'algorithme SHA‹hash› (256, 384, 512)
-t ‹timestamp› Durée de révocation pour le hash (0=infini)

Exemples

Produire un fichier de hash de signature EFI
cert-to-efi-hash-list PK.crt PK.esl
Pour produire un fichier avec plusieurs signatures:
cat PK1.esl PK2.esl › PK.esl
^
27 mai 2016

htmlpdflatexmanmd




cert-to-efi-sig-list

cert-to-efi-sig-list

Outil pour convertir des certificats openssl en listes de signature EFI

   cert-to-efi-sig-list prend un certificat X509 en entrée au format PEM et le convertis en fichier de liste de signature EFI contenant seulement ce certificat.

OPTIONS

-g ‹guid› Utilise le guid spécifie comme propriétaire de la signature. Non spécifié, un guid avec des 0 est utilisé

Exemples

Produire un fichier de signature EFI
cert-to-efi-sig-list PK.crt PK.esl
Pour produire un fichier avec plusieurs signatures:
cat PK1.esl PK2.esl › PK.esl
^
15 juin 2013

htmlpdflatexmanmd




cgclassify

cgclassify

Déplace un tâche dans le cgroup donné

OPTIONS

-g ‹controllers›:‹path› Définis le cgroup où placer la tâche
--sticky Avec cette option, cgred ne change pas les tâches enfant avec les droits du cgroups basé dans cgrules.conf
--cancel-sticky cgred peut automatiquement changer le pidlot et leur tâche enfant dansle bon cgroup basé sur /etc/cgrules.conf
^
15 juin 2013

htmlpdflatexmanmd




cgclear

cgclear

Décharge un système de fichier cgroup

   sans options, place toutes les tâche dans les cgroups dans le cgroup root

OPTIONS

-l, --load=‹filename› Spécifie le fihcier de config à lire. Peut être spécifié plusieurs fois
-L, --load-directory=‹directory› Spécifie le répertoire qui est recherché dans les fihciers de configuration. Peut être spécifié plusieurs fois
-e  Seul les cgroups vides sont déchargés
^
15 juin 2013

htmlpdflatexmanmd




cgconfig.conf

cgconfig.conf

Fichier de configuration utilisé par libcgroup

   Fichier de configuration utilisé par libcgroup pour définir les cgroups, leur paramètres et leur points de montage. Il consiste de sections mount, group et default.

la section mount a la forme:
mount {
    ‹controller› = ‹path›
    ...
}

   où controller est le nom du sous-système. Une hiérarchie nommée peut être spécifiée comme contrôleur avec "name=‹somename›". path, le chemin où la hiérarchie cgroup associée devrait être montée.

La section group a la forme:
group ‹name› {
    [permissions]
    ‹controller› {
        ‹param name› = ‹param value›
        ...
    }
...
}

name Nom du cgroup. le cgroup root est toujours créé automatiquement. Il peut être spécifié dans ce fichier de configuration en utilisant '.' comme nom de cgroup
permissions Les permissions du cgroup. root a toujous les permissions de faire tout avec les cgroups Ils ont la syntaxe suivante:


perm {
    task {
        uid = ‹task user›
        gid = ‹task group›
        fperm = ‹file permissions›
    }
    admin {
        uid = ‹admin name›
        gid = ‹admin group›
        dperm = ‹directory permissions›
        fperm = ‹file permissions›
    }
}

task user/group Nom de l'utilisateur et du group propriétaire du fichier tasks du cgroup
admin user/group Nom de l'utilisateur et du group propriétaire des autres fichiers du cgroup
controller Nom du sous-sytème kernel. Permet de spécifier le nom du fichier à définir et sa valeur

La section default a la forme:
default {
    perm {
        task {
            uid = ‹task user›
            gid = ‹task group›
            fperm = ‹file permissions›
        }
        admin {
            uid = ‹admin name›
            gid = ‹admin group›
            dperm = ‹directory permissions›
            fperm = ‹file permissions›
        }
    }
}

   Cette section a la même forme que la section group

Exemples

Exemple 1:
mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpu;
}

Créé la hiérarchie contrôlée par 2 sous-sytèmes. Correspond à:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

Exemple 2:
mount {
    cpu = /mnt/cgroups/cpu;
    "name=scheduler" = /mnt/cgroups/cpu;
    "name=noctrl" = /mnt/cgroups/noctrl;
}
group daemons {
    cpu {
        cpu.shares = "1000";
    }
}
group test {
    "name=noctrl" {
    }
}

Créé 2 hiérarchies. une 'scheduler' contrôlée par le sous-système cpu avec le group daemons en enfant. L'autre est nommée noctrl sans contrôleur, avec un groupe test. Correspond à:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,name=scheduler cpu /mnt/cgroups/cpu
mount -t cgroup -o none,name=noctrl none /mnt/cgroups/noctrl
mkdir /mnt/cgroups/cpu/daemons
echo 1000 › /mnt/cgroups/cpu/daemons/www/cpu.shares
mkdir /mnt/cgroups/noctrl/tests

Exemple 3:
    mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpu;
}
    
group daemons/www {
    perm {
        task {
            uid = root;
            gid = webmaster;
            fperm = 770;
        }
        admin {
            uid = root;
            gid = root;
            dperm = 775;
            fperm = 744;
        }
    }
    cpu {
        cpu.shares = "1000";
    }
}
    
group daemons/ftp {
    perm {
        task {
            uid = root;
            gid = ftpmaster;
            fperm = 774;
        }
        admin {
            uid = root;
            gid = root;
            dperm = 755;
            fperm = 700;
        }
    }
    cpu {
        cpu.shares = "500";
    }
}

Créer la hiérarchie contrôllée par 2 sous-système avec un group et 2 sous-groupes. Correspond à:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
mkdir /mnt/cgroups/cpu/daemons
mkdir /mnt/cgroups/cpu/daemons/www
chown root:root /mnt/cgroups/cpu/daemons/www/*
chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
echo 1000 › /mnt/cgroups/cpu/daemons/www/cpu.shares
mkdir /mnt/cgroups/cpu/daemons/ftp
chown root:root /mnt/cgroups/cpu/daemons/ftp/*
chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
echo 500 › /mnt/cgroups/cpu/daemons/ftp/cpu.shares

Exemple 4:
mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpuacct;
    }
    
group daemons {
    cpuacct{
    }
    cpu {
    }
}

Créé 2 hiérarchies et un group commun Correspond à:
mkdir /mnt/cgroups/cpu
mkdir /mnt/cgroups/cpuacct
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
mkdir /mnt/cgroups/cpu/daemons
mkdir /mnt/cgroups/cpuacct/daemons

Exemple 5:
mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpuacct;
}
    
group daemons {
    cpuacct{
    }
}
    
group daemons/www {
    cpu {
        cpu.shares = "1000";
    }
}
    
group daemons/ftp {
    cpu {
        cpu.shares = "500";
    }
}

Créé 2 hiérarchies avec quelqes groupes dedans. un de ces groupes est créé dans les 2 hiérarchies. Correspond à:
mkdir /mnt/cgroups/cpu
mkdir /mnt/cgroups/cpuacct
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
mkdir /mnt/cgroups/cpuacct/daemons
mkdir /mnt/cgroups/cpu/daemons
mkdir /mnt/cgroups/cpu/daemons/www
echo 1000 › /mnt/cgroups/cpu/daemons/www/cpu.shares
mkdir /mnt/cgroups/cpu/daemons/ftp
echo 500 › /mnt/cgroups/cpu/daemons/ftp/cpu.shares

Exemple 6:
mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpu;
}
    
group . {
    perm {
        task {
            uid = root;
            gid = operator;
        }
        admin {
            uid = root;
            gid = operator;
        }
    }
    cpu {
    }
}
    
group daemons {
    perm {
        task {
            uid = root;
            gid = daemonmaster;
        }
        admin {
            uid = root;
            gid = operator;
        }
    }
    cpu {
    }
}

Créé la hiérarchie contrôlée par 2 sous-sytèmes avec un groupe ayant des permissions spéciales. Correspond à:
mkdir /mnt/cgroups/cpu
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
chown root:operator /mnt/cgroups/cpu/*
chown root:operator /mnt/cgroups/cpu/tasks
mkdir /mnt/cgroups/cpu/daemons
chown root:operator /mnt/cgroups/cpu/daemons/*
chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks
^
15 juin 2013

htmlpdflatexmanmd




cgconfigparser

cgconfigparser

Définis le système de fichier de cgroup

OPTIONS

-l, --load=FILE Parse le fichier de configuration des cgroups définis le système de fichier du cgroup et monte les points de montage définis. Peut être spécifié plusieurs fois
-L, --load-directory=DIR Trouve tous les fichiers dans un répertoire et les parses dans l'ordre alphabétique. Peut être spécifié plusieurs fois
-a ‹agid›:‹auid› Définis le propriétaire par défaut des fichiers de cgroup définis. Ces utilisateurs sont autorisés à définir les paramètres du sous-système et créer des cgroups
-d, --dperm=mode Définis les permissions par défaut d'un répertoire cgroup
-f, --fperm=mode définis les permissinos par défaut des fichiers du cgroup
-s, --tperm=mode Définis les permissions par défaut du fichier tasks du cgroup
-t ‹tuid›:‹tgid› Définis le propriétaire du fichier tasks du cgroup
^
15 juin 2013

htmlpdflatexmanmd




cgcreate

cgcreate

Créer de nouveaux cgroups

OPTIONS

-a ‹agid›:‹auid› Définie le nom de l'utilisateur et du groupe propriétaire des fichiers de contrôle.
-d, --dperm=mode définisles permissions du répertoire cgroup.
-f, --fperm=mode Définis les permissions des paramètres du cgroup
-g ‹controllers›:‹path› Définis les cgroups à ajouter controllers est une liste de contrôleurs, et path le chemin relatif au cgroup dans la liste des contrôleurs donnés. Peut être spécifié plusieurs fois
-s, --tperm=mode Définis lespermissions du fichier tasks du cgroup
-t ‹tuid›:‹tgid› Définis le propriétaire et le groupe propriétaire du fichier tasks
^
15 juin 2013

htmlpdflatexmanmd




cgdelete

cgdelete

Supprime des cgroups

OPTIONS

‹controllers›:‹path› Définis le cgroup et ses enfants à supprimer
-r Supprime récursivement
^
15 juin 2013

htmlpdflatexmanmd




cgexec

cgexec

Lance la tâche dans le cgroup donné

OPTIONS

-g ‹controllers›:‹path› Définis le cgroup dans lequel la tâche va se lancer.
--sticky Avec cette option, cgred ne change pas les tâches enfant avec les droits du cgroups basé dans cgrules.conf

Exemples

lance ls dans le cgroup test1 dans tous les contrôleurs montés
cgexec -g *:test1 ls
Lance ls -l dans le cgroup test1 dans les contrôleurs cpu et memory
cgexec -g cpu,memory:test1 ls -l
lance ls -l dans le cgroup test1 dans les contrôleurs cpu et memory et le cgroup test1 dans le contrôleur swap
cgexec -g cpu,memory:test1 -g swap:test2 ls -l
^
15 juin 2013

htmlpdflatexmanmd




cgget

cgget

Affiche les paramètres des cgroups donnés

OPTIONS

‹path› Le nom du cgroup à lire.Peut être spécifié plusieurs fois
-a, --all Affiche les variables de tous les contrôleurs.
-g ‹controller› Défnis le contrôleur dont la valeur est à afficher
N'affiche pas les en-têtes
-r, --variable ‹name› Paramètre à afficher. Peut être spécifié plusieurs fois
-v, --values-only Affiche seulement les valeurs.

Exemples

cgget -r cpuset.cpus -r cpuset.mems first second
first:
cpuset.cpus=0-1
cpuset.mems=0
second:
cpuset.cpus=0
cpuset.mems=0
cgget -n -r cpuset.cpus -r cpuset.mems first second
cpuset.cpus=0-1
cpuset.mems=0
cpuset.cpus=0
cpuset.mems=0
cgget -nv -r cpuset.cpus -r cpuset.mems first second
0-1
0
0
0
cgget -n -g cpu /
cpu.rt_period_us=1000000
cpu.rt_runtime_us=950000
cpu.shares=1024
^
15 juin 2013

htmlpdflatexmanmd




cgred.conf

cgred.conf

Fichier de configuration de service cgred

   Fichier de configuration de service cgred de libcgroup. Contient des valeurs interne.

CONFIG_FILE Spécifie le fichier de configuration pour le service cgred
LOG_FILE Spécifie le fichier de log (défaut: envoie à syslog)
NODAEMON Equivalent à --nodaemon
LOG Niveau de verbosité (-v, -vv, -q ou --nolog)

^
11 juin 2013

htmlpdflatexmanmd




cgroup

cgroup

Présentation

   Les Control Groups fournissent un mécanisme pour agréger/partitionner des jeux de tâches, et tous les futures enfants, dans des groupes hiérarchiques.

   Un cgroup associe un jeu de tâches avec un jeu de paramètres pour un ou plusieurs sous-systèmes. un sous-système est un module qui utilise les facilités de groupement de tâches pour traiter ces groupes de tâche d'une manière particulière. un sous-système est typiquement un contrôleur de ressource.

   Une hiérarchie est un jeu de cgroups arrangée en arborescence, de manière à ce que chaque tâche dans le système soit dans exactement un cgroup dans la hiérarchie. Chaque hiérarchie a une instance du cgroup de système de fichier virtuel avec lui.

   Chaque tâche dans le système a un pointeur de référence vers un css_set. Un css_set contient un jeu de pointeur de référence vers des objets cgroups_subsys_state, un pour chaque cgroup enregistré dans le système.

   Un système de fichier hiérarchique de cgroup peut être monté pour le voir et le manipuler depuis l'espace utilisateur. On peut lister toutes les tâches attachées à un cgroup.

   Quand un cgroup est démonté, s'il y a des cgroups enfants, cette hiérarchie reste active. S'il n'y a pas de cgroups enfant, la hiérarchie est désactivé.

   Chaque tâche sous /proc a un fichier nommé cgroup affichant, pour chaque hiérarchie active, les noms des sous systèmes et le nom du cgroup.

   Chaque cgroup est représenté par un répertoire contenant les fichiers suivants:

tasks liste des tâches attachées au cgroup.
cgroup.procs liste des tgid dans ce cgroup.
notify_on_release Permet lorsque la dernière tâche d'un cgroup se termine et que le dernier cgroup enfant est supprimé, que le kernel lance une commande spécifiée dans le fichier release_agent
release_agent Le chemin à utiliser pour les notifications de release (existe dans le top cgroup uniquement)
cgroup.clone_children (0 ou 1) Tous les cgroups créés vont appeler post_clone pour chaque sous-système du nouveau cgroup. ce callback copie les valeurs du parent.
cgroup.event_control (0 ou 1) active l'exécution du release_agent
cpu planifie l'accès du cpu aux cgroup
cpu.shares Valeur entière de part relative du temps CPU disponible pour les tâches
cpu.rt_runtime_us Période en microsecondes contiguë la plus longue autorisé relative à rt_period_us
cpu.rt_period_us Période de temps en microsecondes de référence pour rt_runtime_us
cpuset Assigne des cpu et des nœud mémoire à des cgroups
cpuset.cpu_exclusive (0 ou 1) spécifie si des cpusets autres que celui-ci, des ses parents ou enfants peuvent partager les cpu spécifiés
cpuset.cpus Spécifie à quels CPU les tâches dans ce cgroup peuvent accéder
cpuset.mem_exclusive (0 ou 1) Spécifie si d'autre cpusets peuvent partager les nœuds de mémoire
cpuset.mem_hardwall (0 ou 1) Spécifie si les allocations au noyau de pages mémoire et données tampon sont restreintes aux nœuds mémoire spécifiés pour ce cpuset
cpuset.memory_migrate (0 ou 1) spécifie si une page en mémoire devrait migrer vers un nouveau nœud si les valeurs dans cpuset.mems changent
cpuset.memory_pressure Contient une moyenne de sollicitation de la mémoire des processus de ce cpuset. Est mis à jours lorsque memory_pressure_enabled est activé
cpuset.memory_pressure_enabled (0 ou 1) Spécifie si le système doit calculer la sollicitation mémoire (memory_pressure)
cpuset.memory_spread_page (0 ou 1) Spécifie si les tampons de système de fichier doivent être placés de manière régulières sur les nœuds mémoire alloués à ce cpuset
cpuset.memory_spread_slab (0 ou 1) Spécifie si les cache slab du noyau pour les opérations I/O doivent être placés de manière régulières sur le cpuset
cpuset.mems Spécifie les nœuds de mémoire auxquels les tâches de ce cgroup ont accès
cpuset.sched_load_balance (0 ou 1) Spécifie si le noyau va équilibrer les charges sur les CPU dans ce cpuset
cpuset.sched_relax_domain_level entier entre -1 et une valeur positive, représente la largeur de l'étendue des cpu sur laquelle le noyau va essayer d'équilibrer les charges. les valeurs sont:

        -1 Utilise la valeur par défaut du système pour l'équilibrage de charges
        0 Pas d'équilibrage de charge
        1 Équilibre immédiatement les charges sur les threads du même coeur
        2 Équilibre immédiatement les charges sur les coeurs du même chip
        3 Équilibre immédiatement les charges sur les CPU du même nœud ou la même lame
        4 Équilibre immédiatement les charges sur les CPU de même architecture NUMA
        5 Équilibre immédiatement les charges sur tous les CPU sur architecture NUMA

cpuacct Rapports automatiques sur les cpu utilisés
cpuacct.stat Rapporte le nombre de cycles CPU en unité USER_HZ pris par les tâches de ce cgroup et ses enfants dans le mode système
cpuacct.usage Rapporte le nombre de cycles CPU total en nanosecondes pris par les tâches de ce cgroup et enfants
cpuacct.usage_percpu Rapporte le nombre de cycles CPU total en nanosecondes sur chaque CPU pris par toutes les taches de ce cgroup et ses enfants
blkio Surveille et contrôle l'accès des tâches aux entrées/sorites sur des périphériques block
blkio.io_merged Rapporte le nombre de requêtes BIOS fusionnées en requêtes pour des opérations I/O
blkio.io_queued Rapporte le nombre de requêtes en file d'attente pour des opérations I/O
blkio.io_service_bytes Rapporte le nombre d'octets transférés depuis et vers des périphériques spécifiques
blkio.io_serviced Rapporte le nombre d'opérations I/O effectuées sur des périphériques spécifiques
blkio.io_service_time Rapporte le temps total pris par l'envoie de la demande et son achèvement pour les opérations I/O sur des périphériques spécifiques
blkio.io_wait_time Rapporte le temps total pour un service dans les files d'attentes des opération I/O sur des périphériques spécifiques
blkio.reset_stats Réinitialise les statistiques enregistrées
blkio.sectors Rapporte le nombre de secteurs transférés depuis/vers des périphériques spécifiques
blkio.time Rapporte le moment auquel un cgroup avait un accès I/O à des périphériques spécifiques, en ms
blkio.weight Poids relatif d'accès au block I/O (de 100 à 1000)
blkio.weight_device Poids relatif d'accès à des périphériques spécifiques au format majeur:minuer poid
blkio.avg_queue_size Rapporte la taille moyenne des files d'attente pour les opérations I/O
blkio.group_wait_time Rapporte la durée totale (en ns) q'un cgroup attendu une tranche de temps pour l'une de ses files d'attente
blkio.empty_time Rapporte la durée totale (en ns) qu'un cgroup a attendu sans requêtes en attente
blkio.idle_time Rapporte le temps totale (en ns) que le planification a passé à attendre un cgroup dans l'attente d'une meilleur requête que celles déjà dns les files d'attentes ou provenant d'autres cgroups (si CONFIG_DEBUG_BLK_CGROUP=y)
blkio.dequeue Rapporte le nombre de fois que des requêtes d'opérations I/O ont été retirés des files d'attentes par des périphériques spécifiques
net_cls repère les paquets réseau avec un ClassId
net_cls.classid valeur hexa indiquant un descripteur de contrôle du traffic
devices Autorise ou refuse l'accès aux périphériques dans un cgroup
devices.allow Spécifie à quels périphériques les tâches du cgroup peuvent accéder. Chaque entrée possède 4 champs : type (a, b ou c), majeur, mineur et accès (r, w, m : autorise à créer des fichiers de périphériques qui n'existent pas encore)
devices.deny Spécifie les périphériques que le cgroup n'a pas accès
devices.list Rapporte les périphériques pour lesquels les contrôles d'accès ont été définis pour ce cgroup
freezer suspend ou réactive les tâches dans un cgroup
freezer.state FROZEN (les tâches dans le cgroup sont suspendues), FREEZING ( le système est en train de suspendre les tâches dans le cgroup), THAWED (les tâches dans le cgroup sont réactivées)
perf_event Monitoring par cpu. (voir perf)
ns permet de grouper les processus dans des espaces de nom séparés
memory
memory.stat reporte des statistiques de mémoire:

        cache Cache de la page, inclut tmpfs (shmem), en octets
        rss caches swap et anonyme, n'inclut pas tmpfs (shmem), en octets
        mapped_file taille des fichiers mappés en mémoire, inclut tmpfs (shmem), en octets
        pgpgin nombre de pages chargées en mémoire
        pgpgout nombre de pages renvoyées de la mémoire
        swap usage swap, en octets
        active_anon caches swap et anonyme de la liste des LRU (dernier récemment utilisé) actifs, inclut tmpfs (shmem), en octets
        inactive_anon caches swap et anonyme de la liste des LRU (dernier récemment utilisé) inactifs, inclut tmpfs (shmem), en octets
        active_file mémoire sauvegardée sur fichier de la liste des LRU actifs, en octets
        inactive_file mémoire sauvegardée sur fichier de la liste des LRU inactifs, en octets
        unevictable mémoire ne pouvant pas être récupérée, en octets
        hierarchical_memory_limit limite de la mémoire pour la hiérarchie contenant le groupe de contrôle memory, en octets
        hierarchical_memsw_limit limite de la mémoire plus le swap pour la hiérarchie contenant le groupe de contrôle memory, en octets

memory.usage_in_bytes Rapporte l'utilisation mémoire total actuelle en octets
memory.memsw.usage_in_bytes Rapporte la somme de l'utilisation de la mémoire et de l'espace swap
memory.max_usage_in_bytes Rapporte le montant max e mémoire utilisée
memory.memsw.max_usage_in_bytes Rapporte la somme totale de mémoire et swap utilisé
memory.limit_in_bytes Définis la mémoire max utilisateur incluant le cache (-1 pas de limite)
memory.memsw.limit_in_bytes mémoire et swap max (-1 pas de limite)
memory.failcnt Rapporte le nombre de fois que la limite mémoire est atteinte (memory.limit_in_bytes)
memory.memsw.failcnt Rapporte le nombre de fois que la limite mémoire est atteinte (memory.memsw.limit_in_bytes)
memory.force_empty Vide la mémoire de toutes les pages utilisée lorsque défini à 0. uniquement quand aucune tâche n'est présente
memory.swappiness Définis la tendance du noyau à déloger la mémoire plutôt que de réclamer des pages depuis le cache de page (idem à /proc/sys/vm/swappiness)
memory.use_hierarchie (0 ou 1) spécifie si la mémoire utilisée devrait être prise en comptes sur une hiérarchie de cgroup, à 0, le sous-système ne récupère pas la mémoire d'une tâche enfant.

   Les nouveaux cgroups sont créé en utilisant l'appel système mkdir. les propriétés d'un cgroup sont modifiés en écrivant dans le fichier approprié dans ce cgroup.

Utiliser les cgroups

monter une hiérarchie cgroup:
mount -t tmpfs cgroup_root /sys/fs/cgroup
ajouter le sous-système cpuset:
mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
ajouter cpuset et memory:
mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
Changer de jeu de sous-systèmes:
mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1
Spécifier le release_agent de la hiérarchie:
mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" xxx /sys/fs/cgroup/rg1
Changer la valeur du release_agent:
echo "/sbin/new_release_agent" › /sys/fs/cgroup/rg1/release_agent
Attacher une tâche à un cgroup:
echo `pidof bash` › tasks
^
15 juin 2013

htmlpdflatexmanmd




cgrules.conf

cgrules.conf

Fichier de configuration de libcgroup

   Fichier de configuration de libcgroup. Définis les cgroups à traiter, contient une liste de règles qui assignent à un group/user définis un cgroup dans un sous-système ou cgroup dans un sous-système.

2 format sont possible:
‹user› ‹controllers› ‹destination›
‹user›:‹process name› ‹controllers› ‹destination›
où:

user peut être, un nom d'utilisateur, un @groupe, '*', '%' équivalent à "ditto"
process name options, un nom de processus ou un chemin vers une commande à trziter
controllers liste de contrôlleurs séparés par des ',' ou '*'
destination Chemin relatif d'une hiérarchie contrôleur ou:

        %U username
        %u UID
        %g group
        %g GID
        %p process
        %P PID

   La premère règle qui matche est exécutée

Exemples

Les processus des étudiants dans le sous-système devices appartiennent au cgroup /usergroup/students
student devices /usergroup/students
Quand les étudiants exécutent cp, les processus dans le sous-système devices appartiennent au cgroup /usergroup/students/cp
student:cpdevices /usergroup/students/cp
Les processus lancés par n'importe qui du groupe admin appartiennent au cgroup admingroup
@admin *admingroup/
Les tâche de Peter pour le contrôleur cpu appartiennent au cgroup test1.
peter cpu test1/
Les tâche de Peter pour le contrôleur memory appartiennent au cgroup test2.
% memory test2/
Tout processus appartient au cgroup default
* * default/
^
15 juin 2013

htmlpdflatexmanmd




cgrulesengd

cgrulesengd

Service qui distribue les processus aux cgroups

   Quand un process change sont uid/gid effectif, il inspecte la liste des règles depuis cgrules.conf et place le processus dans le cgroup approprié. Le fichier est lu au lancement et peut être rechargé via SIGUSR2.

OPTIONS

-f ‹path›, --logfile=‹path› Écrit les logs dans le fichier donné
-s[facility], --syslog=[facility] logging facility
-n, --nodaemon Ne lance pas en tâche de fond
-v, --verbose mode verbeux
-q, --quiet mode silencieux
-Q, --nolog Désactive les logs
-d, --debug idem à -nvvf
-u ‹user›, --socket-user=‹user›
-g ‹group›, --socket-group=‹group› Définis le propriétaire du socket cgrulesengd. Assume que cgexec tourne avec les permissions suid adéquat pour qu'il puisse écrire dans ce socket quand --sticky est utilisé
^
15 juin 2013

htmlpdflatexmanmd




cgset

cgset

Définis les paramètres des cgroups donnés

OPTIONS

‹path› Nom du cgroup à changer. Peut être spécifié plusieurs fois
-r ‹name=value› Le nom du fichier et la valeur à écrire dans ce fichier. Peut être spécifie plusieurs fois
-copy-from ‹source_cgroup_path› Définis le nom du cgroup d'où copier les paramètres
^
15 juin 2013

htmlpdflatexmanmd




cgsnapshot

cgsnapshot

Génère des fichier de configuration pour les contrôleurs donnés

OPTIONS

-b file Affiche seulement les variables depuis la blacklist (défaut: /etc/cgsnapshot_blacklist.conf) ce fichier contient toutes les variables qui devraient être ignorés
-f, --file Redirige la sortie dans le fichier
-s, --silent Ignore toutes les alertes
-t, --strict N(affiche pas les variables qui ne sont pas dans la whitelist (défaut: /etc/cgsnapshot_whitelist)
-w file Définis le fichier blacklist
controller Définis le contrôleur dont les hiérarchies seront affichés
^
31 octobre 2016

htmlpdflatexmanmd




chattr

chattr

Changer les attributs dans un système de fichier linux

OPTIONS

-R Changer les attributs récursivement dans les répertoires et leur contenu
-f Supprimer les messages d'erreur
-v version définir le numéro de version/génération du fichier
-p projet Définis le numéro de projet du fichier

Attributs

a Mis, peut seulement être ouvert en mode ajout pour l'écriture. Seul le superutilisateur ou un processus possédant la capability CAP_LINUX_IMMUTABLE peut changer cet attribut
A Mis, le atime n'est pas modifié en cas d'accès au fichier.
c Mis, Le fichier automatiquement compressé sur le disque par le kernel.
C Mis, le fichier n'est pas sujet aux mises à jours copy-on-write. N'a pas d'effet sur les répertoires mais les fichier créés dans ce répertoire aurom l'attribut No_COW mis
d Mis, le fichier n'est pas candidat pour la sauvegarde avec le programme dump
D Mis pour un répertoire qui est modifié, les changements sont écris de manière synchrone sur le disque. Équivalent à l'option de montage dirsync appliqué à un sous-jeu de fichiers
e Mis, indique que le fichier utilise des extents pour mapper les blocks sur le disque. Ne peut pas être supprimé par chattr
E Utilisé par les patchs de chiffrement expérimentaux pour indiquer que le fichier a été chifré. Ne peut pas être modifié par chattr
h Indique que le fichier stocke ses blocks en unité de taille de block du système de fichier au lieu d'unité de secteurs, et signifie que le fichier est (ou à moment l'a été) supérieur à 2To. Ne peut pas être changé par chattr
i Le fichier de peut pas être modifié, supprimé ou renommé, aucun lien ne peut être créé vers ce fichier et aucune donnée ne peut être écrite dans ce fichier. Seul root ou un processus ayant CAP_LINUX_IMMUTABLE peut changer cet attribut
I Indique qu'un répertoire est indexé en utilisant les arborescences hashé (htree). Ne peut pas être changé par chattr
j Mis, un fichier écrit toutes ses données dans le journal avant d'être écrit dans le fichier lui-même. Seul root ou un processus ayant CAP_LINUX_IMMUTABLE peut changer cet attribut
N Indique que le fichier a des données stockées en ligne, dans l'inode lui-même. Ne peut pas être changé par chattr
P Pour un répertoire, force une structure hiérarchique pour les project id. Cela signifie que les fichiers et répertoires créé dans le répertoire héritent du project id du répertoire, les opérations de renommage sont contraints pour que lorsqu'un fichier ou répertoire et déplacé dans un autre répertoire, le project id match. De plus, les liens hard vers le fichier ne peuvent être créé que si le project id match.
s Mis, guand un fichier est supprimé, ses blocks sont remplis de 0 et écris sur disque.
S Mis, quand un fichier est modifié, les changements sont écris de manière synchrone sur le disque; équivalent à l'option sync.
t Mis, un fichier n'a pas de fragment de block partiel à la fin du fichier fusionné avec d'autres fichiers. Nécessaire pour les application tels que LILO qui lit le système de fichier directement et qui ne comprend pas les fichier 'tail-merged'
T Mis, un répertoire sera en haut des hiérarchies de répertoire pour l'allocateur de block Orlov. Par exemple, c'est une très bonne idée de définir cette attribut sur /home, pour que /home/john et /home/mary soient placés dans les groupes de block séparés.
u Mis, quand un fichier est supprimé, sont contenu est sauvé. Cela permet à l'utilisateur de demander sa récupération
X Utilisé par les patchs de compression expérimentaux pour indiquer que le contenu brut d'un fichier compressé peut être accédé directement. Ne peut pas être changé par chattr
Z Utilisé par les patchs de compression expérimentaux pour indiquer qu'un fichier compressé est dirty. Ne peut pas être changé par chattr
^
14 juillet 2010

htmlpdflatexmanmd




chcon

chcon

Change le contexte de récurité SELinux des fichiers spécifiés

OPTIONS

-h, --no-dereference affecte les liens symboliques au lieu des fichiers référencés
--reference=RFILE utilise le context de sécurité de RFILE au lieu de spécifier un contexte.
-R, --recursive Opère sur les fichiers et les répertoires récursivement.
-H si -R est spécifié et qu'un argument de la ligne de commande est un lien symbolique vers un répertoire, le traverse.
-L en mode récursif, traverse tous les liens symboliqes vers un répertoire.
-P Ne traverse aucun lien symbolique. mode par défaut.
-v, --verbose Affiche un diagnostique pour chaque fichier traité.
-u USER, --user=USER Définis l'utilisateur dans le contexte de sécurité cible.
-r ROLE, --role=ROLE Définis le role dans le contexte de sécurité cible
-t TYPE, --type=TYPE Définis le type dans le contexte de sécurité cible
-l RANGE, --range=RANGE Définit la plage dans le contexte de sécurité cible
^
03 février 2016

htmlpdflatexmanmd




chcpu

chcpu

Configurer les cpu

   chcpu peut modifier l'état des cpu. il peut activer/désactiver les cpu, scanner à la recherche de nouveaux cpu, chnger le mode de dispatching de l'hyperviseur, demander et retourner des cpu à l'hyperviseur.

OPTIONS

-r, --rescan rescan pour détecter les nouveaux cpu dans le cas où le système ne les detecte pas automatiquement.
-c, --configure cpu-list Configure tous les cpu spécifiés. configurer un cpu signifie que l'hyperviseur prend un cpu du pool de cpu et l'assigne au hardware virtuel sur lequel le kernel tourne
-e, --enable cpu-list active tous les cpu listé. Un cpu doit être configuré avant.
-p, --dispatch mode définis le dispatching (polarization). n'a d'effet que si l'architecture hardware et l'hyperviseur supporte la polarisation cpu. les modes sont 'horizontal', la charge est répartie sur tous les cpus disponible; 'vertical', la charge est concentrée sur quelques cpu.
-d, --disable cpu-list Désactive tous les cpu spécifiés. Désactiver signifie que le kernel le met offline
-g, --deconfigure cpu-list Déconfigure tous les cpu spécifiés. signifie que l'hyperviseur les supprime du hardware virtuel sur lequel l'instance tourne et les retourne au pool de cpu. un cpu doit être offline avant.
^
08 mai 2017

htmlpdflatexmanmd




checkpolicy

checkpolicy

Compilateur de stratégie SELinux

   checkpolicy est un programme qui vérifie et compile une configuration de stratégie de sécurité SELinux dans une représentation binaire qui peuvent être chargée dans le kernel. Si aucun fichier d'entrée n'est spécifié, tente de lire policy.conf ou la stratégie.

OPTIONS

-b, --binary Lit un fichier de stratégie binaire existant au lieu d'un fichier policy.conf
-C, --cil Écrit un fichier de stratégie CIL au lieu d'un fichier binaire
-d, --debug Entre en mode debug une pour la stratégie chargée
-M, --mls ACtive la stratégie MLS en vérifiant et en compilant la stratégie
-o, --output filename Écrit un fichier de stratégie binaire au nom spécifié
-c policyvers Spécifie la version de la stratégie
-t, --target Spécifie la platform cible (selinux ou xen)
-U, --handle-unknown ‹action› Spécifie comment le kernel doit gérer les classes ou permissions inconnues (deny, alow ou reject)
^
03 novembre 2011

htmlpdflatexmanmd




chfn

chfn

Permet de modifier le nom complet et les informations associées à un utilisateur

   Il change le nom complet, l’office number, l’office extension et le home phone number pour un compte utilisateur. Ces informations sont affichées par finger. Un utilisateur normal peut changer ses propres informations, en fonction des restrictions dans /etc/login.defs. Ces champs ne doivent pas contenir de ’,’, excepté pour le champ other, ne doivent pas contenir de ’=’ ou de ’-’. Il est également recommandé d’éviter les caractères non US-ASCII, mais c’est surtout pour le phone number. Le champ other est utilisé pour stocker des informations de compte utilisé par d’autres applications. Sans option, chfn opère de manière interactive.

OPTIONS

-f Nom complet du compte
-r Numéro de bureau
-w téléphone du bureau
-h Téléphone personnel
-o permet de changer les portions indéfinies du champ GECOS.
^
03 novembre 2011

htmlpdflatexmanmd




chgpasswd

chgpasswd

Mettre à jour les mots de passe par lot

   Il lit une liste de paires groupe/mot de passe depuis l’entrée standard et met à jours dans les groupes existant. Chaque ligne est sous la forme :

  nom_du_groupe:password

  Par défaut, les mots de passe doivent être en texte claire, et sont cryptés par chgpasswd. L’algorithme de cryptage peut être défini pour le système avec la variable ECRYPT_METHOD dans /etc/login.defs, et peut être remplacé avec les options sur la ligne de commande.

OPTIONS

-c, --crypt-method spécifie la méthode de cryptage (DES, MD5, NONE, SHA256 et SHA512.
-e, --encrypted Indique que les mots de passe fournis sont chiffrés
-m, --md5 Permet d’utiliser md5, plutôt que DES, lorsque les mots de passe sont fournis en clair
-s, --sha-rounds Nombre de passes pour chiffrer en sha. (Entre 1000 et 999 999 999, définis par défaut dans /etc/login.defs)

   chgpasswd utilise un certain nombre de variables dans /etc/login.defs.
^
03 juillet 2010

htmlpdflatexmanmd




chgrp

chgrp

Change le groupe propriétaire de chaque fichier donné. Peut être soit un nom soit un ID.

OPTIONS

-c, --changes Décrit l'action pour chaque fichier dont le groupe change.
-f, --silent, --quiet N'affiche pas de message d'erreur sur les fichiers dont le groupe ne peut pas être changé
--dereference N'agit pas sur les liens symboliques mais sur leurs références. mode par défaut
-h, --no-dereference Agit sur les liens symboliques et non pas leur références
--preserve-root Échoue en tentant de changer le répertoire racine récursivement. sans --recursive cette options n'a pas d'effet.
--no-preserve-root Annule l'effet d'un précédent --preserve-root
--reference=REF_FILE Change le groupe de chaque fichier pour être le même que REF_FILE. si REF_FILE est un lien symbolique, utilise sa référence.
-v, --verbose Affiche un diagnostique pour chaque fichier traité.
-R, --recursive Change récursivement les répertoires et leur contenus
-H si -R est spécifié et que l'argument est un lien symbolique, le traverse.
-L si -R est spécifié, traverse tous liens symboliques vers un répertoire qui est rencontré
-P Ne traverse aucun lien symbolique. mode par défaut
^
03 juillet 2010

htmlpdflatexmanmd




chmod

chmod

Change les permissions d'accès des fichiers spécifiés. Il ne change jamais les permissions des liens symbolique. Cependant pour chaque lien symbolique listé, chmod change les permissions du fichier pointé.

OPTIONS

-c, --changes décrit l'action pour chaque fichier dont les permissions sont changées
-f, --silent, --quiet N'affiche pas de message d'erreur dans le cas ou les permissions d'un fichier ne peuvent être changées.
--preserve-root Échoue en tentant de changer récursivement le répertoire racine. sans -R cette option n'a aucun effet.
--no-preserve-root Annule l'effet d'un précédent --preserve-root
-v, --verbose Décrit l'action effectuée sur chaque fichier.
--reference=REF_FILE Change le mode de chaque fichier à REF_FILE. Si REF_FILE est un lien symbolique, utilise sa référence.
-R, --recursive Change récursivement les permissions des répertoires et leur contenus.
^
03 juillet 2010

htmlpdflatexmanmd




chown

chown

Change les user et group propriétaire

   chown change le user:group propriétaire de chaque fichier spécifiés, sous la forme [OWNER] [ : [GROUP] ]. Peuvent être spécifié par nom ou par ID.

        OWNER Change seulement l'utilisateur.
        OWNER:GROUP change l'utilisateur et le groupe
        OWNER: Change l'utilisateur spécifié et le groupe de cet utilisateur.
        :GROUP Change seulement le groupe.
        : Aucun des 2 n'est changé.

OPTIONS

-c, --changes Décrit l'action de chaque fichier dont le propriétaire est changé.
-f, --silent, --quiet N'affiche pas les messages d'erreur dont le propriétaire des fichiers spécifiés ne peut être changé.
--from=OLD_OWNER Change le propriétaire d'un fichier seulement s'il a les même attributs que OLD_OWNER.
-h, --no-dereference Agit sur les liens symboliques eux mêmes au lieu de leur référence.
--preserve-root Échoue en tentant de changer récursivement le répertoire racine. sans -R cette option n'a aucun effet.
--no-preserve-root Annule l'effet d'un précédent --preserve-root
--reference=REF_FILE Change l'utilisateur et le groupe pour correspondre à ceux de REF_FILE. Si REF_FILE est un lien symbolique, utilise sa référence.
-v, --verbose Affiche un diagnostique pour chaque fichier traité.
-R, --recursive Change récursivement les répertoires et leurs contenus.
-H Si -R est spécifié et qu'une opérande est un lien symbolique vers un répertoire, le traverse.
-L si -R est spécifié, traverse les liens symboliques vers un répertoire qui est rencontré.
-P ne traverse aucun lien symbolique
^
03 novembre 2011

htmlpdflatexmanmd




chpasswd

chpasswd

Permet de mettre à jours des mots de passe par lot

   chpasswd lit une liste de paires de noms d’utilisateurs et de mots de passe depuis l’entrée standard et utilise ces informations pour mettre à jour un groupe d’utilisateurs existants. Chaque ligne est au format suivant :

  Nom_utilisateur:mot_de_passe

   Par défaut, le mot de passe doit être fournis en texte clair, et sont cryptés par chpasswd. L’âge du mot de passe sera mis à jours, si nécessaire. Par défaut, les mots de passe sont cryptés par PAM, mais vous pouvez utiliser une méthode de cryptage différente. Excepté quand PAM est utilisée, chpasswd met d’abords à jours tous les mots de passe en mémoire, et effectue ensuite tous les changements sur disque si aucune erreur ne s’est produite. Quand PAM est utilisé, si un mot de passe ne peut pas être mis à jours, chpasswd continue et retournera un code d’erreur.

OPTIONS

-c, --crypt-method spécifie la méthode de cryptage (DES, MD5, NONE, SHA256 et SHA512.
-e, --encrypted Indique que les mots de passe fournis sont chiffrés
-m, --md5 Permet d’utiliser md5, plutôt que DES, lorsque les mots de passe sont fournis en clair
-s, --sha-rounds Nombre de passes pour chiffrer en sha. (Entre 1000 et 999 999 999, définis par défaut dans /etc/login.defs)

Fichiers

/etc/pam.d/chpasswd Configuration utilisée lorsque chpasswd utilise PAM.
^
15 juillet 2010

htmlpdflatexmanmd




chroot

chroot

Lance une commande avec un répertoire root différent

Exemple

lancer un ls lié dans /tmp/empty:
chroot /tmp/empty /ls -Rl /
^
03 novembre 2011

htmlpdflatexmanmd




chsh

chsh

Modifie l’interpréteur de commande initial de l’utilisateur

OPTIONS

-s, --shell Nom du nouvel interpréteur de commande initial

   Le nouveau shell doit être listé dans /etc/shells, sauf si c’est root qui le change. Un utilisateur avec un shell restreint ne peut pas changer son shell.
^
10 juillet 2014

htmlpdflatexmanmd




chsh.ldap

chsh.ldap

Change le login shell dans LDAP

   chsh.ldap peut être utilisé pour changer le login shell de l'utilisateur. Le changement actuel dans LDAP est effectué par nslcd et est sujet à ACL dans le serveur.

OPTIONS

-s, --shell SHELL Nom du shell. Si vide, le système sélectionne le shell par défaut.
-l, --list-shells Liste les shells trouvés dans /etc/shells
^
03 février 2016

htmlpdflatexmanmd




chvt

chvt

Change le terminal virtuel courant

   La commande chvt N passe /dev/ttyN comme terminal courant. L'écran correspondant est créé s'il n'existe pas. Pour gérer les VT non utilisés, utiliser deallocvt. La combinaison (Ctrl-)LeftAlt-FN où N est entre 1-12 a le même effet.

^
08 février 2015

htmlpdflatexmanmd




cibadmin

cibadmin

Fournis un accès direct à la configuration du cluster

OPTIONS

-v, --verbose mode verbeux

Commandes

-u, --upgrade Met à jours la configuration à la dernière syntaxe
-Q, --query Requête le contenu du CIB
-E, --erase Efface le contenu de tout le CIB
-B, --bump Augmente la valeur epock du CIB de 1
-C, --create Crée un objet dans le CIB. Échoue si l'objet existe déjà
-M, --modify Trouve l'objet dans l'arborescenc XML du CIB et le met à jours. Échoue s'il n'existe pas sauf si -c est spécifié
-P, --patch Fournis une mise à jours sous la forme d'un diff xml
-R, --replace Remplace récursivement un objet dans le CIB
-D, --delete Supprime le premier objet correspondant au critère fournis. (ex ‹op id="rsc1_op1" name="monitor"/› )
-d, --delete-all Utilisé avec --xpath, supprime tous les objets correspondant dans la configuration, pas seulement de premier.
-5, --md5-sum Calcule le hash du CIB sur le disque
-6, --md5-sum-versioned Calcule un hash du CIB versionné à la volée
-S, --sync Force le refresh du CIB sur tous les nœuds
-a, --empty Affiche un CIB vide

Options additionnelles

-f, --force
-t, --timeout=value Temps en seconde d'attente avant de déclarer l'opération échouée
-s, --sync-coll Attend que l'appel se termine avant de retourner
-l, --local La commande prend effet localement, devrait seulement être utilisé pour les requêtes
-c, --allow-create Permet à la cible d'une opération -M d'être créé s'il n'existe pas.
-n, --no-children En requêtant un objet, n'inclus par ses enfant dans le résultat retourné

Données

-X, --xml-text=value Récupère le xml depuis la chaîne fournie
-x, --xml-file=value nom du fichier xml à récupérer
-p, --xml-pipe Récupère le xml depuis stdin
-A, --xpath=value Un XPath valide à utiliser au lieu de -o
-o, --scope=value Limite le scope de l'opération à une section spécifique du CIB. ( nodes, resources, constraints, crm_config, rsc_defaults, op_defaults ou status )
-N, --node=value Envoie la commande à l'hôte spécifié

Exemples

Demander la configuration du nœud local:
cibadmin --query --local
Demander les options de configuration du cluster:
cibadmin --query --scope crm_config
Demander tous les paramètres target-role:
cibadmin --query --xpath "//nvpair[@name='target-role']"
Supprimer tous les paramètres is-managed:
cibadmin --delete-all --xpath "//nvpair[@name='is-managed']"
Supprimer la ressource nommée old:
cibadmin --delete --xml-text '‹primitive id="old"/›'
Supprimer toutes les ressources de la configuration:
cibadmin --replace --scope resources --xml-text '‹resources/›'
Remplacer toute la configuration avec le contenu de $HOME/pacemaker.xml:
cibadmin --replace --xml-file $HOME/pacemaker.xml
Remplacer la section constraints de la configuration avec le contenu de $HOME/constraints.xml:
cibadmin --replace --scope constraints --xml-file $HOME/constraints.xml
Augmenter la version de configuration pour empêcher d'anciennes configurations d'être chargées accidentellement:
cibadmin --modify --xml-text '‹cib admin_epoch="admin_epoch++"/›'
Éditer la configuration avec l'éditeur du système:
cibadmin --query › $HOME/local.xml
$EDITOR $HOME/local.xml
cibadmin --replace --xml-file $HOME/local.xml
^
07 juin 2010

htmlpdflatexmanmd




cksum

cksum

Calcul un CRC pour chaque fichier donné

   cksum calcul un CRC pour chaque fichier donné. Il affiche le CRC suivi du nombre d'octets du fichier. Typiquement utilisé pour s'assurer que les fichiers transférés n'ont pas été corrompus.

^
11 septembre 2016

htmlpdflatexmanmd




classes.conf

classes.conf

Fichier de configuration de classe pour cups

   Le fichier classes.conf définis les classes d'imprimantes locales disponibles. Il est normalement dans /etc/cups et est maintenu par cupsd. Ce fichier n'est pas prévu pour être édité ou géré manuellement.

^
06 juin 2016

htmlpdflatexmanmd




clvmd

clvmd

Service de cluster LVM

   clvmd est le service qui distribut les mises à jours de métadonnées LVM dans le cluster. Il doit être lancé sur tous les nœuds dans le cluster et affiche une erreur si un nœud du cluster n'a pas ce service.

OPTIONS

-C Seulement valide avec -d. Indique à tous les clvmd dans le cluster d'activer/désactiver le débug. Sans cette option, seule le service local est concerné.
-d [value] Définis le niveau de log de débuggage (0, désactivé, 1 envoie sur stderr, 2 envoie à syslog)
lock_uuid uuid de lock à ré-acquérir exclusivement quand clvmd est redémarré
-F Ne lance pas en tâche de fond
-I cluster_manager Sélectionne le gestionnaire de cluster à utiliser pour les locks et les communications internes. Il est possible d'avoir plusieurs gestionnaires disponible, cette option permet d'empêcher la recherche. Par défaut, auto utiliser le premier gestionnaire qui réussit, et les vérifie dans un ordre prédéfinis cman, corosync, openais. Les gestionnaires disponibles seront listés dans l'ordre via clvmd -h.
-R Indique à toutes les instance de clvmd dans le cluster de recharger leur cache de périphérique et re-lire la configuration lvm.
-S Indique à clvmd de quitter et se ré-exécuter.
-t timeout timeout pour les commandes à lancer dans le cluster. (défaut: 60 secondes)
-T start_timeout timeout de démarrage du service. Défaut: 0 (pas de délai). ignoré avec -d

Variables d'environnements

LVM_CLVMD_BINARY emplacement du binaire clvmd. Défaut: /usr/sbin/clvmd
LVM_BINARY binaire lvm2 à utiliser. Défaut: /sbin/lvm
^
26 janvier 2015

htmlpdflatexmanmd




cmap_keys

cmap_keys

Vue générale dans le CMAP

Description

   La librairie cmap est utilisée pour interagir avec la base de configuration utilisée par corosync. Il y a 3 types de clé stockés dans cmap: Mappage de valeurs stockées dans le fichier de configuration, statistiques temps réels, valeurs créées par l'utilisateur.

Clés

internal_configuration.* Données de configuration interne. Ces clés sont lecture seule. Si une configuration spécifique au sous-système est nécessaire, la clé doit être sous la forme logging.logger_subsys.SERVICE.key où SERVICE est un nom de service en majuscule et la clé est la même que dans le fichier de configuration.
nodelist.* Valeurs lues depuis le fichier de configuration. Chaque élément node dans le fichier de configuration à une position assignées commençant à 0. Donc de premier nœud a le préfixe nodelist.node.0..
runtime.blackbox.* Trigger keys. Il est recommandé d'utiliser corosync-blackbox pour trouver facilement les adresses nodeid/ring du nœud local directement de cmap.
runtime.connections.* Informations sur le nombre total de connexions actives, terminées, et sur chaque connexion IPC à un moment donné. Tous les clés sont lecture seules.
runtime.connections.ID.* Chaque connexion IPC a un ID unique. C'est sous la forme [[short_name:][PID:]internal_id. Les clés typiques sont:

        client_pid Contient le PID d'une connexion IPC
        dispatched avec le nombre de messages dispatchés
        invalid_request nombre de requête faites par IPC qui sont invalides
        name Contenant le nom court d'une connexion IPC
        overload Nombre de de requêtes qui n'ont pas été traité à cause d'une surcharge
        queue_size nombre de messages en queue d'attente d'envoie
        recv_retries nombre total de réceptions interrompues
        requests nombre de requêtes faites par IPC
        responses nombre de réponses envoyées par IPC
        send_retries nombre total d'envoies interrompues
        service_id ID du service auquel IPC est connecté

runtime.services.* statistiques pour les moteurs de service. Chaque service a son propre service_id avec un nom runtime.services.SERVICE., où SERVICE est un nom de service en minuscule.
runtime.totem.pg.mrp.srp.* Statistiques sur totem. Les clés sont lecture seule:

        commit_entered Nombre de fois qu'un processeur entre en état COMMIT
        commit_token_lost Nombre de fois qu'un processeur perd le token en état COMMIT
        consensus_timeouts Nombre de fois qu'un processeur dépasse le délai en créant un consensus sur le membership
        continuous_gather Nombre de fois qu'un processeur n'a pas été capable d'atteindre de consensus
        firewall_enabled_or_nic_failure à 1 quand le processeur n'a pas été capable d'atteindre le consensus depuis longtemps.
        gather_entered Nombre de fois qu'un processeur entre à l'état GATHER
        gather_token_lost Nombre de fois qu'un processeur perd le token en état GATHER
        mcast_retx Nombre de messages retransmis
        mcast_rx Nombre de message multicast reçus
        mcast_tx Nombre de message multicast transmis
        memb_commit_token_rx Nombre de token reçus
        memb_commit_token_tx Nombre de token émis
        memb_join_rx Nombre de message join reçus
        memb_join_tx Nombre de message join transmis
        memb_merge_detect_rx Nombre de message member merge reçus
        memb_merge_detect_tx Nombre de message member merge transmis
        orf_token_rx Nombre de tokens orf reçus
        orf_token_tx Nombre de tokens orf transmis
        recovery_entered Nombre de fois qu'un processeur entre à l'état recovery
        recovery_token_lost Nombre de fois qu'un token a été perdu à l'état recovery
        rx_msg_dropped Nombre de messages reçus qui ont été supprimés parce qu'ils n'étaient pas attendus
        token_hold_cancel_rx Nombre de token reçus contenant un message cancel
        token_hold_cancel_tx Nombre de token émis contenant un message cancel
        mtt_rx_token Mean Transmis Time du token, en ms. temps entre 2 tokens consécutifs reçus
        avg_token_workload Temps moyen en ms du temps à maintenir le token dans le processeur courant
        avg_backlog_calc Temps moyen de message non encore envoyés du processeur courant.

runtime.totem.pg.mrp.srp.members.* Contient les membres du protocole totem. Chaque membre à le format runtime.totem.pg.mrp.srp.members.NODEID.KEY œu key peut être:

        ip L'adresse IP du membre
        joint_count Nombre de fois que le processeur à joins le membership avec le processeur local.
        status Statut du processeur
        config_version Version de configuration du nœud membre.

resources.process.PID.* Préfixe créé par les applications utilisant SAM avec l'intégration CMAP. Il contient les clés suivantes:

        recovery Stratégie de récupération du processus.
        poll_period Valeur passée dans sam_initialize comme time_interval
        last_updated Dernière fois que sam a reçus un heartbeat du client
        state État du client.

uidgid.* Les informations sur les utilisateurs/groupes qui sont autorisés à faire des connexions IPC à corosync
quorum.cancel_wait_for_all Dit à votequorum d'annuler l'attente de tous les nœuds au démarrage du cluster. Peut être utilisé pour débloquer le quorum si des nœud sont éteinds.
config.reload_in_progress À 1 quand corosync.conf est rechargé, 0 sinon.
config.totemconfig_reload_in_progress Idem, mais changé après une configuration totem.

Exemples

Changer dynamiquement les permission user/group pour utiliser cororsync ipc:
corosync-cmapctl -s uidgid.uid.500 u8 1
GID est similaire:
corosync-cmapctl -s uidgid.gid.500 u8 1
Pour supprimer la permission, la supprimer:
corosync-cmapctl -d uidgid.gid.500
Ajouter/supprimer dynamiquement un nœud UDPU. On ajoute un nœud avec l'ip 10.34.38.108 et nodeid 3. On cherche une position de nœud qui n'est pas utilisée:
nodelist.local_node_pos (u32) = 1
nodelist.node.0.nodeid (u32) = 1
nodelist.node.0.ring0_addr (str) = 10.34.38.106
nodelist.node.1.nodeid (u32) = 2
nodelist.node.1.ring0_addr (str) = 10.34.38.107
Donc la position de nœud suivant sera 2:
corosync-cmapctl -s nodelist.node.2.nodeid u32 3
corosync-cmapctl -s nodelist.node.2.ring0_addr str 10.34.38.108
Toujours ajouter ring0_addr en dernier
^
16 juin 2016

htmlpdflatexmanmd




cmirrord

cmirrord

Service de log des mirroirs en cluster

   cmirrord est le service qui surveille les informations de log mirroir dans un cluster. C'est spécifique aux mirroirs basés sur DM.

   Ce service s'assure que l'infrastructure cluster fournie par le gestionnaire de cluster (CMAN), qui doit être fonctionnel pour que cmirrord puisse fonctionner. La sortie est loggée via syslog.

OPTIONS

-f, --foreground Ne lance pas en tâche de fond, log sur le terminal
^
25 mars 2016

htmlpdflatexmanmd




cmtab

cmtab

Informations sur les systèmes de fichier gérés par cryptmount

   /etc/cryptmount/cmtab contient les informations sur les systèmes gérés par cryptmount. Le format est flexible:


TARGET_NAME {
    dev=DEVICE # REQUIRED
    flags=FLAG,FLAG,...
    startsector=STARTSECTOR
    numsectors=NUMSECTORS
    loop=LOOPDEV
    dir=MOUNT_POINT
    fstype=TYPE # REQUIRED
    mountoptions=MOPT,MOPT,...
    fsckoptions=FOPT;FOPT;...
    supath=SUPATH
    bootaction=BOOTACTION
    cipher=CIPHER
    ivoffset=IVOFFSET
    keyformat=KEYMANAGER
    keyfile=KEYFILE # REQUIRED
    keyhash=KEYHASH
    keycipher=KEYCIPHER
    keymaxlen=KEYMAXLEN
    passwdretries=NUMATTEMPTS
}

   Certains champs, tels que dev et fstype sont obligatoires. De nombreux champs ont des valeurs par défaut. Un champ contenant une valeur non-numérique peut contenir une référence à une variable d'environnement:

$(HOME) Répertoire personnel de l'utilisateur
$(UID) UID de l'utilisateur
$(USERNAME) Nom de l'utilisateur
$(GID) GID du groupe primaire de l'utilisateur
$(GROUPNAME) Groupe primaire de l'utilisateur

Définitions de cibles

dev Dpfinis le nom du périphérique ou du fichier.
flags "user", "nouser", "fsck", "nofsck", "mkswap", "nomkswap", "trim", "notrim". Défaut: user,fsck,nomkswap,notrim
startsector Secteur de début du système de fichier dans le périphérique. défaut: 0
numsectors Donne la longueur totale du système de fichier en secteur. Défaut: -1
loop Permet de spécifier un périphérique loopback. Défaut: auto
dir Point de montage
fstype Type de système de fichier
mountoptions Options de montage utilisées par mount
fsckoptions options utilisées par fsck
supath Définis la variable d'environnement PATH en lançant des sous-processus en tant que root. Peut être nécessaire pour fsck et mount. Défaut: /sbin:/bin:/usr/sbin:/usr/bin
bootaction Action lors du démarrage du système (none, mount, swap ou prepare)
cipher Algorithme de chiffrement à utiliser. Défaut: aes-cbc-plain
keyformat schéma de gestion de clé utilisé pour interagir avec le keyfile. (libgcrypt, luks, openssl-compact, builtin, raw). Défaut: builtin
keyfile Nom du fichier contenant la clé à utiliser
ivoffset Offset ajouté au numéro de secteur utilisé pour construire le vecteur d'initialisation de l'algorithme de chiffrement. Défaut: 0
keyhash Algorithme de hashage à utiliser
keycipher Algorithme de chiffrement à utiliser pour sécuriser la clé de déchiffrement
keymaxlen Longueur en octet de la clé de déchiffrement
passwdretries Nombre de tentative du mot de passe

Choix du keymanager

   cryptmount supporte différentes manières de protéger l'accès à la clé associée avec chaque système de fichier chiffré. Pour la plupart des utilisateurs, le keymanager builtin fournis a bon niveau de sécurité et une bonne flexibilité. Les keymanager alternatifs offre un grand choix de schéma de hashage de mot de pass et de compatibilité avec d'autres outils de chiffrement.

builtin Ce keymanager utilise un keyfile séparé. Une fonction de dérivation de clé (PBKPF2) utilisant l'algorithme de hashage SHA1, avec chiffrement blowfish-cbc est utilisé pour protéger la clé.
libgcrypt Ce keymanager utilise un keyfile séparé. Une fonction de dérivation de clé (PBKPF2) est utilisé pour protéger la clé, avec un algorithme de hashage et de chiffrement supporté par la version installé de la librairie libgcrypt.
luks Ce keymanager fournis une compatibilité avec le format LUKS. Au lieu d'un fichier séparé, LUKS utilise un en-tête dans le système de fichier lui-même.
openssl/openssl-compat Ce keymanager utiliser un keymanager séparé qui est compatible avec le format utilisé par l'outil de chiffrement opennssl. Une fonction de dérivation de clé (PBKPF2) est utilisé pour protéger la clé, avec un algorithme de hashage et de chiffrement disponible.
password Ce keymanager dérive la clé directement depuis le mot de passe de l'utilisateur
raw Ce keymanager utilise un keyfile séparé où la clé accès est stocké directement et sans chiffrement. Ce keymanager est utile pour gérer les partitions swap chiffrés, où le keyfile peut être choisis avec /dev/random et la clé sera différente à chaque fois quelle est lue.

Sécurité

   Parce que cryptmount nécessite d'opérer avec des privilèges setuid, il est très important que son fichier de configuration soit sécurisé. Idéalement, /etc/cryptmount/cmtab devrait être géré seulement par l'administrateur système, et tous les keyfiles devraient lisibles par leur propriétaire. cryptmount effectue des vérifications de sécurité sur /etc/cryptmount/cmtab chaque fois qui est lancé, et va refuser d'opérer sauf si les conditions suivant sont rencontrées:

- cmtab doit être possédé par root
- cmtab doit être un fichier régulier
- cmtab ne doit pas être en écriture globalement
- Le répertoire contenant cmtab doit être possédé par root
- Le répertoire contenant cmtab ne doit pas être en écriture globalement
- Pour chaque cible dans @CM_SYSCONFDIR@/cmtab, tous les chemins doivent être absolus

Exemples

L'exemple suivant de @CM_SYSCONFDIR@/cmtab consiste de 5 cibles, utilisant divers algorithmes de chiffrement et stockent leur système de fichier de différentes manières, incluant une cible représentant une partition swap chiffrée:
_DEFAULTS_ {
    passwdretries=3 # allow 3 password attempts by default
}
    
basic {
    dev=/home/secretiveuser/crypt.fs
    dir=/home/secretiveuser/crypt # where to mount
    loop=auto # find free loop-device
    fstype=ext3 mountoptions=default
    cipher=aes-cbc-plain # filesystem encryption
    keyfile=/home/secretiveuser/crypt.key
    keyformat=builtin
}
    
partition {
    dev=/dev/hdb62 # use whole disk partition
    dir=/mnt/crypt62
    fstype=ext3 mountoptions=nosuid,noexec
    cipher=serpent-cbc-plain
    keyfile=@CM_SYSCONFDIR@/crypt_hdb62.key
    keyformat=openssl # use OpenSSL key-encryption
    keyhash=md5 keycipher=bf-cbc # encryption of key file
}
    
subset {
    dev=/dev/hdb63
    startsector=512 numsectors=16384 # use subset of partition
    dir=/mnt/encrypted\ subset\ of\ hdb
    fstype=reiserfs mountoptions=defaults
    cipher=twofish-cbc-plain # filesystem encryption
    keyfile=@CM_SYSCONFDIR@/crypt_hdb63.key
    keyformat=libgcrypt
    keyhash=md5 keycipher=blowfish-cbc # encryption of key file
}
    
encswap { # encrypted swap partition
    bootaction=swap
    dev=/dev/disk/by-id/scsi-SATA_ST500_ABCDEFG-part37
    startsector=16896 numsectors=1024 # use subset of partition
    fstype=swap flags=mkswap cipher=twofish-cbc-plain
    keyfile=/dev/random keymaxlen=16 keyformat=raw
}
    
luks { # partition created by cryptsetup-luks
    dev=/dev/hdb63
    dir=/mnt/luks-partition-$(USERNAME)
    keyformat=luks
    keyfile=/dev/hdb63
    fstype=ext3
}

^
07 février 2015

htmlpdflatexmanmd




collie

collie

Utilitaire en ligne de commande pour le service sheep

OPTIONS

-a, --address Spécifie l'adresse du service. Défaut: localhost
-p, --port Spécifie le port du service.
-i, --index Spécifie l'index des data objects
-s, --snapshot Spécifie un id de snapshot ou un nom de tag
-P, --prealloc Préalloue tous les data objects
-r, --raw Mode de sortie brute: omet les en-tête, sépare les champs avec un simple espace et affiche les tailles en octet décimal
-d, --delete Supprime une clé
-x, --exclusive Active le mode d'écriture exclusive
-b, --store Spécifie le backend store
-c, --copies Spécifie le niveau de redondance des données. (nombre de copies à maintenir)
-m, --mode [safe|quorum|unsafe] Contrôle le comportement quand il y a trop peu de nœuds pour la redondance configurée. safe arrête le cluster (nr_nodes ‹ nr_copies), quorum arrête le cluster (r_nodes ‹ nr_copies/2 + 1), unsafe n'arrête jamais le cluster.
-f, --force Ne demande jamais confirmation
-R, --restore Restaure le cluster

Commandes et sous-commandes

vdi create [-P|--prealloc] [-a|--address address] [-p|--port port] [-h|--help] ‹vdiname› ‹size›
Crée un image
vdi snapshot [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Créer un snapshot
vdi check [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Vérifie et répare la consistance d'une image
vdi clone [-s snapshot] [-P] [-a address] [-p port] [-h] ‹src vdi› ‹dst vdi›
Clone une image
vdi delete [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Supprime une image
vdi rollback [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Applique un snapshot au vdi courant
vdi list [-a address] [-p port] [-r] [-h] [vdiname]
Liste les images
vdi track [-i index] [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Affiche les traces d'objet dans l'image
vdi tree [-a address] [-p port] [-h]
Affiche les images en arborescence
vdi graph [-a address] [-p port] [-h]
Affiche les images au format Graphviz
vdi object [-i index] [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Affiche les informations d'objet dans l'image
vdi setattr [-d] [-x] [-a address] [-p port] [-h] ‹vdiname› ‹key› [value]
Définis un attribut VDI
vdi getattr [-a address] [-p port] [-h] ‹vdiname› ‹key›
Lis un attribut vdiname
vdi resize [-a address] [-p port] [-h] ‹vdiname› ‹new size›
Redimensionne une image
vdi read [-s snapshot] [-a address] [-p port] [-h] ‹vdiname› [‹offset› [‹len›]]
Lis les données d'une image
vdi write [-a address] [-p port] [-h] ‹vdiname› [‹offset› [‹len›]]
Écris les données dans une image
vdi backup [-s snapshot] [-F from] [-a address] [-p port] [-h] ‹vdiname›
Crée un backup incrémentale entre 2 snapshots
vdi restore [-s snapshot] [-a address] [-p port] [-h] ‹vdiname›
Restore un snapshot depuis un backup
node kill [-a address] [-p port] [-r] [-h] ‹node id›
Termine un nœud
node list [-a address] [-p port] [-r] [-h]
Liste les nœuds
node info [-a address] [-p port] [-r] [-h]
Affiche des informations sur chaque nœud
node recovery [-a address] [-p port] [-r] [-h]
Affiche les nœuds actuellement en récupération
cluster info [-a address] [-p port] [-r] [-h]
Affiche des informations sur le cluster
cluster format [-b store] [-c copies] [-m mode] [-a address] [-p port] [-h]
Créer un store sheepdog
cluster shutdown [-a address] [-p port] [-h]
Stop sheepdog
cluster recover info [-a address] [-f] [-p port] [-h]
Affiche le status de récupération
cluster recover force [-a address] [-f] [-p port] [-h]
Force la récupération du cluster immédiatement
cluster recover enable [-a address] [-f] [-p port] [-h]
Active la récupération automatique et la lance si nécessaire
cluster recover disable [-a address] [-f] [-p port] [-h]
Désactive la récupération automatique
^
21 juillet 2010

htmlpdflatexmanmd




comm

comm

Compare 2 fichiers triés, ligne par ligne, et écrit sur la sortie standard les lignes qui sont communes et les lignes qui sont uniques.

   Avant d'utiliser comm, les 2 fichiers doivent être triés. sort sans options produit toujours une sortie utilisable par comm. Sans options, comm produit une sortie à 3 colonnes. La première contient les lignes uniques du premier fichier, la deuxième les lignes unique dans le deuxième fichier et la troisième colonne contient les lignes communes au 2 fichiers. Les colonnes sont séparées par une tabulation.

OPTIONS

-1, -2, -3 Supprime l'affichage de la colonne spécifiée
--check-order Échoue avec un message d'erreur si un des fichier en entrée n'est pas trié.
--nocheck-order Ne vérifie pas si les fichiers sont triés.
--output-delimiter=STR Permet de spécifier le délimiteur entre les colonnes.
^
13 mars 2016

htmlpdflatexmanmd




config.json

config.json

Fichier de configuration de Docker

   Par défaut, La ligne de commande Docker stocke sa configuration dans un répertoire appelé .docker dans le répertoire home. Docker gère la plupart des fichiers de configuration dans ce répertoire et ne devraient pas être modifiés. Cependant, on peut modifier config.json pour contrôler certains aspects du comportement de la commande docker.

   Actuellement, on peut modifier la commande docker en utilisant les variables d'environnement ou les options de la ligne de commande. On peut également utiliser les options dans le fichier config.json. En utilisant ces mécanismes, il faut garder en tête l'ordre de précédence. Les options de la ligne de commande on priorité sur les variables d'environnement, qui ont priorité sur config.json. Le fichier config.json stocke les propriétés encodé en JSON.

HttpHeaders Spécifie un jeu d'en-têtes à inclure dans tous les messages envoyés depuis le client Docker au service. Docker ne tente pas d'interpréter cet en-tête.
psFormat Spécifie le format par défaut pour la sortie docker ps.
detachKey Spécifie la séquence de touche par défaut pour détacher un conteneur.
imagesFormat Spécifie le format par défaut pour la sortie de docker images.

Exemple

{
    "HttpHeaders": {
        "MyHeader": "MyValue"
    },
    "psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}",
    "imagesFormat": "table {{.ID}}\\t{{.Repository}}\\t{{.Tag}}\\t{{.CreatedAt}}",
    "detachKeys": "ctrl-e,e"
}

^
28 août 2015

htmlpdflatexmanmd




convertquota

convertquota

Convertit l'ancien format de quota au nouveau quota

   convertquota convertit les fichiers de quota de l'ancien format quota.user et quota.group au nouveau format aquota.user et aquota.group.

OPTIONS

-u, --user Convertit le fichier de quota utilisateur.
-g, --user Convertit le fichier de quota de groupe.
-f, --convert-format oldformat,newformat convertit le fichier de quota depuis oldformat vers newformat
-e, --convert-endian Convertit le format de fichier vfsv0 en big endian vers little endian.
^
21 mars 2017

htmlpdflatexmanmd




coraid-update

coraid-update

upload un fichier de mise à jour à une appliance CORAID

   Ce script effectue quelques vérifications avant de copier un fichier de mise à jour local à la cible AoE distant dans l'appliance CORAID.

^
31 mars 2016

htmlpdflatexmanmd




coredump.conf

coredump.conf, coredump.conf.d

Fichier de configuration de stockage de coredump

   Ces fichiers peuvent se trouver dans les emplacements suivants:

/etc/systemd/coredump.conf
/etc/systemd/coredump.conf.d/*.conf
/run/systemd/coredump.conf.d/*.conf
/usr/lib/systemd/coredump.conf.d/*.conf

   Ces fichiers configurent le comportement de systemd-coredump(8). La configuration par défaut est définie durant la compilation, donc un fichier de configuration dans /etc/systemd/ contient les entrées commentées montrant les défaut. Quand un package doit personnaliser la configuration, il peut installer des configurations dans /usr/lib/systemd/*.conf.d/. Le fichier de configuration principal est lu avant tous les autres, et a la précédence la plus faible. Les fichiers dans un sous-répertoire sont triés alphabétiquement, sans regarder dans quel sous-répertoire il réside. Pour désactiver un fichier de configuration fournis par un vendeur, la manière recommandée est de placer un lien vers /dev/null dans le répertoire /etc avec le même nom de fichier que le fichier de configuration du vendeur.

OPTIONS

Storage= Contrôle où stocker les cores. none log mais ne stocke pas de manière permanente, external (défaut) stocke les cores dans /var/lib/systemd/coredump. journal stocke les cores dans le journal et suis les rotations de journaux. both stocke les cores dans les 2 emplacements.
Compress= Contrôle la compression pour le stockage externe. défaut: yes.
ProcessSizeMax= Taille maximum en octets d'un core qui est traité. les coredump excédant cette taille sont loggé, mais le backtrace ne sera pas généré et le core ne sera pas stocké.
ExternalSizeMax=, JournalSizeMax= Taille maximum (non-compressée) en octets d'un core à sauvegarder
MaxUse=, KeepFree= Force les limites de l'espace disque pris par les coredumps stockés en externe. MaxUse s'assure que les anciens coredumps sont supprimés dès que l'espace disque utilisé par les coredump atteint cette limite (défaut: 10% de la taille totale du disque). KeepFree contrôle l'espace disque à conserver lible au minimum (défaut: 15% de l'espace disque total). Noter que l'espace disque utilisé par les coredumps peut excéder ces limits durant la compression. Les anciens coredumps sont supprimés basés sur de temps via systemd-tmpfiles(8).
^
31 mars 2016

htmlpdflatexmanmd




coredumpctl

coredumpctl

Récupère les coredump du journal

OPTIONS

--no-legend N'affiche pas les en-têtes
-1 Affiche les informations s'un simple coredump seulement, au lieu de lister tous les coredumps connus.
-F FIELD, --field=FIELD Affiche toutes les valeurs possible du champ spécifié correspondant dans les entrées coredump du journal
-o FILE, --output=FILE Écrit le core dans le fichier spécifié
-D DIR, --directory=DIR Utiliser les fichiers journaux dans le répertoire spécifié
--no-pager Ne sort pas la sortie dans un pager

Commandes

list Liste les coredumps capturés dans le journal correspondant aux caractéristiques spécifiées
info Affiche des informations détaillée sur les coredumps capturés dans le journal
dump Extrait le dernier coredump correspondant aux caractéristiques spécifiées.
gdb Invoque gdb sur le dernier coredump correspondant aux caractéristiques spécifiées.

Correspondance

PID Process ID du processus qui a dumpé le core. En entier.
COMM Nom de l'exécutable (correspond à COREDUMP_COMM=). Ne doit pas contenir de '/'
MATCH Prédicat journalctl général. Doit contenir un signe '='

Exemples

Liste tous les coredump d'un programme nommé foo
coredumpctl list foo
Invoque gdb sur le dernier coredump
coredumpctl gdb
Affiche des informations sur un processus qui a dumpé le core, correspondant au PID 6654
coredumpctl info 6654
Extrait le dernier coredump de /usr/bin/bar dans un fichier
coredumpctl -o bar.coredump dump /usr/bin/bar
^
04 juin 2010

htmlpdflatexmanmd




coreutils

coreutils

Options Communes

   Certaines options sont disponible pour tous les programmes. Elle sont décrites ici. Tout programme GNU accepte ces options.

  Normalement les options et opérandes peuvent apparaître dans n'importe quel ordre, et les programmes agissent comme si toutes les options apparaissaient avec les opérandes. Beaucoup de programmes qui acceptent les options longues, reconnaissent l'abréviation non-ambigu de ces options.Certains de ces programmes reconnaissent les options --help et --version seulement si l'option est la seule de la ligne de commande.

--help Affiche une aide sur l'utilisation du programme, et quitte.
--version Affiche la version du programme, puis quitte.
-- délimite la liste d'options. les arguments suivants, s'il y'en a, sont traités comme opérande même s'ils commence avec '-'.

Code de sortie

   Les programmes renvoient généralement 0 en cas de succès, et une valeur différente (typiquement 1) dans le cas contraire. Cependant il y'a quelques programmes qui produisent d'autres code de sortie : chroot, env, expr, nice, nohup, printenv, sort, su, test, timeout, tty.

Options de backup

   Certains programmes (cp, install, ln et mv) peuvent créer une copie des fichiers avant d'écrire les nouvelles versions. Ces options contrôlent les détails de ces backups.

-b, --backup[=METHOD] Crée un backup de chaque fichier qui va être écrasé ou supprimé. Sans cette option, les versions originales sont détruites. l'option METHOD, si non spécifiée, utilise la variable d'environnement VERSION_CONTROL, et si elle n'est pas définie, utilise 'existing' par défaut. Les valeurs valides sont :

        none
        off ne jamais faire de backup
        numbered
        t Toujours créer des backups numérotées
        existing
        nil Toujours créer desbackup numérotées des fichiers qui en ont déjà un, simple backup pour les autres.
        simple
        never Toujours créer des backups simple.

-S --suffix=SUFFIX Ajoute SUFFIX à chaque backup crée avec l'option -b. Si cette option n'est pas spécifiée, la valeur de la variable d'environnement SIMPLE_BACKUP_SUFFIX est utilisée, et si elle n'est pas définie le défaut est ' ', comme dans Emacs.

Taille de block

   Certains programmes (df, du et ls) affichent les tailles en blocks. On peut utiliser la taille de block et la méthode d'affichage. La taille de block utilisée pour l'affichage est indépendant de la taille de block des systèmes de fichiers. La taille de block par défaut est choisie en examinant les variables d'environnement. La première qui est définie détermine la taille de block.

        DF_BLOCK_SIZE Spécifie la taille de block par défaut pour df
        DU_BLOCK_SIZE Spécifie la taille de block par défaut pour du
        LS_BLOCK_SIZE Spécifie la taille de block par défaut pour ls
        BLOCK_SIZE Spécifie la taille de block par défaut pour les 3 commandes

   BLOCKSIZE Spécifie le taille de block par défaut pour toutes les valeurs qui sont normalement affichées comme block, si [XX_]BLOCK_SIZE ne sont pas définies.

  POSIXLY_CORRECT si aucune des variables ci-dessus ne sont définies, la taille de block par défaut est 512.

  Si aucune variable n'est définie, la taille de block par défaut est 1024 la plupart du temps. Pour les tailles de fichiers de ls, la taille de block par défaut est 1 octet.

  Une taille de block peut être spécifié par un nombre entier spécifiant le nombre d'octets par block, ou peut être au format 'human-readable'. Une spécification de taille de block précédée par "'" affiche les sorties avec les séparateurs de milliers. ex : --block-size="'1kB" n'affichera pas 1234000 octets, mais 1,234.

  Une taille de block peut être suivie par un multiple de la taillee. Par ex, 1M, 1MiB sont équivalent à 1048576, et 1MB vaut 1000000.

        kB KiloOctets : 10^3 = 1000
        k, KiB KibiOctets : 2^10 = 1024
        MB MegaOctets : 10^6 = 1,000,000
        M, MiB MebiOctets : 2^20 = 1,048,576
        GB GigaOctets : 10^9 = 1,000,000,000
        G, GiB GibiOctets : 2^30 = 1,073,741,824
        TB TeraOctets : 10^12 = 1,000,000,000,000
        T, TiB TebiOctets : 2^40 = 1,099,511,627,776
        PB PetaOctets : 10^15 = 1,000,000,000,000,000
        P, PiB PetaOctets : 2^50 = 1,125,899,906,842,624
        EB ExaOctets : 10^18 = 1,000,000,000,000,000,000
        E, EiB ExbiOctets : 2^60 = 1,152,921,504,606,846,976
        ZB ZettaOctets : 10^21 = 1,000,000,000,000,000,000,000
        Z, ZiB 2^70 = 1,180,591,620,717,411,303,424.
        YB YottaOctets : 10^24 = 1,000,000,000,000,000,000,000,000
        YiB 2^80 = 1,208,925,819,614,629,174,706,176

           Pour spécifier la taille par défaut, utiliser --block-size=SIZE. L'option -k est équivalent --block-size=1K. L'option -h ou --human-readable est équivalent à --block-size=human-readable. --si est équivalent à --block-size=si.

Spécification de signal

`HUP' 1 Hangup.
`INT' 2 Terminal interrupt.
`QUIT' 3 Terminal quit.
`ABRT' 6 Process abort.
`KILL' 9 Kill (cannot be caught or ignored).
`ALRM' 14 Alarm Clock.
`TERM' 15 Termination.
`BUS' Access to an undefined portion of a memory object.
`CHLD' Child process terminated, stopped, or continued.
`CONT' Continue executing, if stopped.
`FPE' Erroneous arithmetic operation.
`ILL' Illegal Instruction.
`PIPE' Write on a pipe with no one to read it.
`SEGV' Invalid memory reference.
`STOP' Stop executing (cannot be caught or ignored).
`TSTP' Terminal stop.
`TTIN' Background process attempting read.
`TTOU' Background process attempting write.
`URG' High bandwidth data is available at a socket.
`USR1' User-defined signal 1.
`USR2' User-defined signal 2.
`POLL' Pollable event.
`PROF' Profiling timer expired.
`SYS' Bad system call.
`TRAP' Trace/breakpoint trap.
`VTALRM' Virtual timer expired.
`XCPU' CPU time limit exceeded.
`XFSZ' File size limit exceeded.

chown et chgrp : ID et noms utilisateur ambigües

   Vu que les arguments OWNER et GROUP de chown et chgrp peuvent être spécifiés soit pas le nom soit pas l'ID, il y'a une ambiguitée. POSIX requière que chown et chgrp tentent d'abord de résoudre la chaîne spécifiée comme nom, et seulement s'ils échouent, ils réessayent en l'interprétant comme ID. Pour forcer un ID à être interprété comme tel, le précéder par un '+'.

exemples :
chown +42 F
chgrp +$numeric_group_id another-file
chown +0 :+0 /

Sources de données aléatoire

   Les commandes shuff, shred et sort ont parfois besoin de données aléatoires. Par défaut ces commandes utilisent un générateur pseudo-aléatoire interne, mais peut être redirigés pour utiliser une source externe avec l'option --random-source=FILE. Une erreur est reportée si FILE ne contient pas suffisamment d'octets. Par exemple, le fichier /dev/urandom peut être utilisé. Les applications qui nécessitent un haut niveau de sécurité à long terme peuvent utiliser /dev/random ou /dev/arandom.

Dossier cible

   Les commandes cp, install, ln et mv traitent la dernière opérande spécialement quand il s'agit d'un répertoire ou un lien symbolique vers un répertoire. Par exemple cp source dest est équivalent à cp source dest/source si dest est un répertoire. Parfois ce mode de fonctionnement n'est pas ce que l'on souhaite, donc pour outrepasser ce mode :

        -T, --no-target-directory Ne traite pas la dernière opérande spécialement
        -t DIRECTORY, --target-directory=DIRECTORY Utilise DIRECTORY comme répertoire de destination de tous les fichiers. Permet notamment à xarg d'être utilisé convenablement.

exemples:
ls | xargs mv -t ../d --
Cette commande ne permet pas de déplacer les fichiers commençant par '.'
find . -mindepth 1 -maxdepth 1 | xargs mv -t ../d
les 2 commandes précédantes échouent s'il n'y a aucun fichier dans le répertoire courant ou si aucun nom de fichier ne contient un blanc ou autre caractère spécial
find . -mindepth 1 -maxdepth 1 | xargs --null --no-run-if-empty mv -t ../d

Slashs

   Certains programmes comme cp et mv permettent de supprimer les slashs de chaque argument SOURCE avant de les traiter. l'option --strip-trailing-slashes autorise ce mode.

Traverser les liens

   Les options suivantes modifient la manière dont chown et chgrp traversent une hiérarchie quand l'option --recursive ou -R est spécifié. Si plus d'une options suivante est spécifiée, seule l'option final prend effet. Ces options spécifient si le traitement d'un lien symbolique vers un répertoire entraine l'opération sur le lien uniquement ou sur tous les fichiers dans ce répertoire.

  Ces options sont indépendantes de --dereference et --no-dereference, qui contrôle si on modifie un lien ou sa référence.

        -H Si --recursive ou -R est spécifié et un argument est un lien vers un répertoire, le traverser
        -L Traverse tous lien vers un répertoire qui est rencontré.
        -P Ne traverse aucun lien symbolique. (par défaut si -H, -L ou -P ne sont pas spécifiés)

Traiter '/' spécialement

   Certaines commandes peuvent opérer de manière destructive sur une hiérarchie entière. Par exemple rm -rf /. Si on veut vraiment détruire tous les fichiers d'un système, on peut utiliser --no-preserve-root, mais le mode par défaut (--preserve-option) est plus sûr. Les commandes chgrp, chmod et chown peuvent aussi être destructeur sur une hiérarchie, ils peuvent donc supporter ces options également.

Utilitaires intégrés

. : break continue eval exit export readonly return set shift times trap unset
Il s'agit d'utilitaires intégrés qui sont standardisés par POSIX. Bash en contient d'autres. Tenter de les lancer via un autre programme comme nice, générera une erreur.

Conformité des standards

   Dans certains cas, les utilitaires GNU en mode par défaut sont incompatibles avec le standard posix. Pour supprimer ces incompatibilités, définir la variable POSIXLY_CORRECT. Les utilitaires GNU sont normalement conforme avec la version POSIX de votre système. Pour les forcer à se conformer à une version POSIX différente, définir la variable d'environnement _POSIX2_VERSION à une valeur sous la forme YYYYMM spécifiant l'année et le mois où le standard à été adopté. 2 valeurs sont actuellement supportées : 199209 et 200112
^
26 janvier 2015

htmlpdflatexmanmd




corosync

corosync

Moteur de clustering Corosync

OPTIONS

-f Démarre l'application en tâche de fond
-r Set round robin realtime scheduling
-t Test la configuration et quitte
^
26 janvier 2015

htmlpdflatexmanmd




corosync-blackbox

corosync-blackbox

Dump les données à la volée depuis le corosync blackbox

Description

   corosync-blackbox pilote corosync pour écrire ses données dans un fichier et lancer qb-blackbox qui l'affiche.

Exemples

Afficher la données courante:
$ corosync-blackbox
Starting replay: head [74205] tail [0]
rec=[1] Log Message=Corosync Cluster Engine ('1.2.1'): started and ready to provide service.
[...]
rec=[2607] Log Message=Delivering MCAST message with seq a to pending delivery queue
rec=[2608] Log Message=downlist received left_list: 2
rec=[2609] Log Message=chosen downlist from node r(0) ip(192.168.100.11)
Finishing replay: records found [2609]

^
26 janvier 2015

htmlpdflatexmanmd




corosync-cfgtool

corosync-cfgtool

Outil administratif pour corosync

Description

   Outil pour afficher et configurer les paramètres actifs dans corosync

OPTIONS

-i Cherche seulement les informations sur l'adresse IP spécifiée
-s Affiche le statut des rings courants dans ce nœud. Si une interface est en faute, retourne 1, sinon 0.
-r Ré-initialise l'état du ring redondant du cluster après une faute pour réactiver l'opération de redondance.
-l Charge un service identifié par le nom du service spécifié
-u Décharge un service identifié par le nom du service spécifié
-a Affiche toutes les adresses IP d'un nœud.
-k Tue un nœud identifié par l'id de nœud
-R Dit à toutes les instances de corosync dans ce cluster de recharger corosync.conf
-H Éteins corosync proprement dans ce nœud.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-cmapctl

corosync-cmapctl

Outil d'accès à la base d'objets

Options

-b Affiche les valeurs binaires
-s key_name type value Définis une clé où type est un parmi ([i|u][8|16|32|64] | flt | dbl | str | bin) pour bin, value est le nom du fichier (ou -pour stdin)
-d key_name Supprimer une clé
-D key_prefix Supprimer plusieurs clé de même préfixe
-g key_name Récupérér une clé
-t key_name Suivre les changements de clé
-T key_prefix Suivre les changements de plusieurs clés
-p filename Charger les paramètres depuis un fichier:

           Le format du fichier est sous la forme: [^[^]]‹key_name›[ ‹type› ‹value›]. Les clé préfixée avec '^' sont supprimées, les clé préfixé avec '^^' sont supprimées par préfixe. type et value sont optionnel dans ces cas là.

^
26 janvier 2015

htmlpdflatexmanmd




corosync-cpgtool

corosync-cpgtool

Outil d'affichage des groupes et membres cpg

Options

-d Délimiter entre les champs
 -e N'échappe par les caractères non imprimables dans le nom de groupe
 -n Affiche seulement tous les noms de groupes existant.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-keygen

corosync-keygen

Génère une clé d'authentification pour corosync

Description

   Pour configurer corosync avec des techniques cryptographiques pour s'assurer de l'authenticité de la protection des données des messages, il faut générer une clé privée. corosync-keygen crée cette clé et l'écris dans /etc/corosync/authkey.

  La clé privée doit être copiée dans tous les processeurs dans le cluster. Si la clé privée n'est pas la même pour tous les nœuds, cet nœuds ne seront pas capables de se joindre à la même configuration.

Copier la clé dans un stockage sécurisé ou utiliser ssh. Puis l'installer avec la commande suivante:
install -D --group=0 --owner=0 --mode=0400 /path_to_authkey/authkey /etc/corosync/authkey
Si un message "Invalid digest" apparaît dans corosync, les clés ne sont pas consistantes entre les processeursS.

OPTIONS

-k ‹filename› Spécifie le chemin où créer la clé. défaut: /etc/corosync/authkey
-l Utilise une source de données aléatoires moins sûre, qui ne nécessite pas l'aide de l'utilisateur pour générer de l'entropy.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-notifyd

corosync-notifyd

Écoute les évènements corosync importants et les envoie sur dbus et/ou snmp

Options

-f Lance en tâche de fond
-l Log tous les évènements
-o Affiche les évènements sur stdout
-s envoie des traps snmp
-m définis d'adresse du gestionnaire snmp
-d Envoie les signaux dbus dans tous les évènements
^
26 janvier 2015

htmlpdflatexmanmd




Corosync - Présentation

Corosync - Présentation

Présentation du moteur de cluster Corosync

Description

   Le projet corosync est un projet pour implémenter un outil de développement de haute disponibilité haute performance et faible charge. Le focus majeur de la haute disponibilité dans le passé a été de masquer les erreurs hardware. Les pannes dans d'autres composants du système restaient non-résolus jusqu'à corosync. Corosync est conçu pour les applications pour répliquer leur état jusqu'à 16 processeurs. Les processeurs contiennent tous un réplica de l'état de l'application.

  Le projet corosync fournis une API de message de groupe appelé CPG, qui implément un modèle de messagerie de groupe fermé présentant des garantie de synchronisation virtuel garantie.

  Pour gérer les conditions où les processus exécutant l'échange CPG plante, on fournis le Simple Availability Manager (SAM) pour permet de redémarrer l'application.

Démarrage rapide

   Dans le répertoire conf dans les sources se trouvent de nombreux fichiers qui doivent être copiés dans le répertoire /etc/corosync. corosync devrait fonctionner avec la configuration par défaut. Corosync utilise des techniques cryptographiques pour s'assurer de l'authenticité et de la protection des messages. pour que corosync soit sécurisé, une clé privée doit être générée et partagée par tous les processeurs.

Variables d'environnement

COROSYNC_MAIN_CONFIG_FILE Spécifie le fqdn du fichier de configuration. défaut: /etc/corosync/corosync.conf
COROSYNC_TOTEM_AUTHKEY_FILE fqdn de la clé partagée utilisée pour authentifier et chiffrer les données utilisée dans le protocole Totem. Défaut: /etc/corosync/authkey

Sécurité

   Corosync chiffre tous les messages envoyés sur le réseau en utilisant le chiffrement SOBBER-128. Corosync utilise HMAC et SHA1 pour authentifier tous les messages. Corosync utilise NSS comme générateur de nombres pseudo-aléatoire. La libraire EVS utilise /dev/random.

  Si les messages de membre peuvent être capturés par des intrus, il est possible d'exécuter une attaque DOS dans le cluster. Dans ce scénario, le cluster est déjà compromis et une attaque DOS est le dernier des soucis de l'administrateur.

   La sécurité dans corosync n'offre pas de solution parfaite puisque les clés sont réutilisée. Il peut être possible pour un attaquant de capturer des packets et de déterminer la clé partagée. Dans ce scénario, le cluster est compromis. Pour des raisons de sécurité, corosync ne devrait jamais avoir le setuid ou setgid dans le système de fichier.

Composants

- La librairie cmap est utilisée pour interagir avec la base de configuration utilisée par corosync.
- La librairie cpg est utilisée pour créer des applications distribuées qui opèrent proprement durant le partitionement, fusions, et pannes du cluster.
- la librairie sam fournis un outils pour vérifier l'état de santé d'une application. Son but est de redémarrer un processus local quand il plante pour répondre à un requête d'état de santé dans un intervalle de temps configuré.
- La librairie quorum est chargé dans tous les nœuds du cluster et track le statut du quorum d'un nœud. Pour que ce service soit utile, un fournisseur de quorum doit être configuré.
- La librairie votequorum est optionnellement chargé dans tous les nœuds dans le cluster pour éviter les situations de split-brain. Il permet cela en ayant un nombre de votes assignés à chaque système dans le cluster et s'assurer que seulement lorsqu'une majorité de votes sont présents, les opérations du cluster sont autorisés à être traités.
^
26 janvier 2015

htmlpdflatexmanmd




corosync-quorumtool

corosync-quorumtool

Définis et affiche les paramètres de quorum et définis les options de vote

Options

-s Affiche le status du quorum
-m Monitor constamment le statut du quorum
-l Liste les nœuds
-v ‹votes› Change le nombre de votes pour un nœuds
‹nodeid› nodeid optionnel du nœud pour -v
-H Affiche les nodeids en hexadécimal
-i Affiche les adresses IP au lieu de résoudre leur noms
-o ‹a|n|i› Ordonne la sortie de la liste des nœuds. a pour l'adresse ip, n par nom, et i par id de nœud
^
26 janvier 2015

htmlpdflatexmanmd




corosync-xmlproc

corosync-xmlproc

Convertis corosync.xml en fichier de configuration corosync

Options

input_xml fichier xml à convertir
output_file nom du fichier de destination
^
26 janvier 2015

htmlpdflatexmanmd




corosync.conf

corosync.conf

Fichier de configuration de corosync

Description

   Le fichier de configuration consiste de directives en accolades. Les choix possibles sont:

totem {} Contient les options de configuration pour le protocole totem
logging {} Contient les options de configuration pour le logging
quorum {} Contient les options de configuration pour le quorum
nodelist {} Contient les options de configuration pour les nœuds dans le cluster
qb {} Contient les options de configuration liées à libqb

Options totem

ringnumber Spécifie le numéro pour l'interface. En utilisant le protocole ring redondant, chaque interface devrait avoir un numéro ring séparé pour identifier les membres du protocole que l'interface utilise pour le ring. doit commencer à 0.
bindnetaddr Spécifie l'adresse réseaux auquel corosync devrait se lier. Doit être une IP dans le système, ou un réseau.
broadcast Optionnel et peut être mis à yes. Permet d'utiliser le broadcast pour les communications.
mcastaddr Adresse de multicast pour corosync. Le défaut devrait fonctionner sur la plupart des réseaux. Éviter 224.x.x.x parce que c'est une adresse multicast de config.
mcastport Port UDP pour le multicast.
ttl Si le cluster fonctionne sur un réseau routé, un TTL de 1 sera trop petit.
version Spécifie la version du fichier de configuration. Actuellement la seule version valide est 2.
clear_node_high_bit Optionnel et est seulement utile quand aucun nodeid n'est spécifié. Certains client corosync nécessitent un nodeid 32-bits signé supérieur à 0, cependant corosync utilise tous les 32-bits de l'espace d'adressage IPv4 en générant un nodeid. À yes, cette options force le MSB à 0.
crypto_hash Spécifie l'algorithme d'authentification HMAC utilisé pour authentifier tous les messages. Les valeurs valides sont: none, md5, sha1, sha256, sha384 et sha512.
crypto_cipher Spécifie l'algorithme de chiffrement à utiliser pour chiffrer les messages. Les valeurs valides sont: none, aes256, aes192, aes128, et 3des.
rrp_mode Spécifie le mode de ring redondant, qui peut être: none, active, ou passive. La réplication active offre les latences les plus faibles mais est moins performant. La réplication passive peut presque doubler la vitesse du protocole totem. none spécifie que seul l'interface réseau sera utilisé pour opérer le protocole totem.
netmtu Spécifie l'unité de transmission maximum réseaux. Pour définir cette valeur au-delà de 1500, le support des jumbo frames est nécessaire sur tous les nœuds.
transport Contrôle le mécanisme de transport utilisé. Si l'interface auquel corosync est lié est une interface RDMA, le paramètre "iba" peut être spécifié. Pour éviter l'utilisation du multicast, un paramètre de transport unicast "udpu" peut être spécifié. Cela nécessite de spécifier la liste des membres dans la directive nodelist. Défaut: udp.
cluster_name Spécifie le nom du cluster et son utilisation pour la génération automatique d'adresse multicast.
config_version Spécifie la version du fichier de configuration. C'est convertit en entier non-signé 64-bits. Par défaut: 0. Permet d'éviter de joindre d'anciens nœud sans configuration à jours.
ip_version Spécifie la version d'IP à utiliser pour les communications. ipv4 ou ipv6.
token Ce timeout spécifié en millisecondes le délai au delà duquel une perte de token est déclaré. C'est le temps passé à détecter une panne d'un processeur dans la configuration courante. Réformer une nouvelle configuration prend 50 ms en plus de ce timeout.
token_coefficient Utilisé seulement quand la section nodelist est spécifiée et contient au moins 3 nœuds. Le vrai timeout de token est calculé par token + (number_of_nodes -2) * token_coefficient. Cela permet au cluster de s'agrandir sans changer manuellement le timeoute de token à chaque fois qu'un nœud est ajouté. Défaut: 650ms
token_retransmit Ce timeout spécifie, en ms, après combien de temps avant de recevoir un token le token est retransmis. Ce sera automatiquement calculé si le token est modifié. Il n'est pas recommandé d'altérer cette valeur. Défaut: 238ms.
hold Ce timeout spécifie, en ms, combien de temps le token devrait être maintenu quand le protocole est en sous-utilisation. Il n'est pas recommandé d'altérer ce paramètre. Défaut: 180ms
token_retransmits_before_loss_const Cette valeur identifie combien de token retransmis devraient être tentés avnt de former une nouvelle configuration. Si cette valeur est définie, la retransmission et le maintient sera automatiquement calculé depuis retransmits_before_loss et token. Défaut: 4 retransmissions.
join Ce timeout spécifie, en ms, combien de temps attendre les messages join dans le protocole membership.
send_join Ce timeout spécifie, en ms, une plage entre 0 et send_join d'attente avant d'envoyer un message join. Pour les configuration inférieur à 32 nœuds, ce paramètre n'est pas nécessaire. Pour les ring plus grands, ce paramètre est nécessaire pour s'assurer que l'interface n'est pas surchargée avec des messages join. Une valeur raisonnable pour les grands ring (128 nœuds) est de 80ms. Défaut: 0
consensus Ce timeout spécifie, en ms, combien de temps attendre pour que le consensus soit achevé avant de commencer un nouveau tour de configuration de membership. a valeur minimum pour le consensus doit être 1.2 * token. Ce calcul est automatique si cette option n'est pas spécifiée
merge Ce timeout spécifie, en ms, combien de temps attendre avant de vérifier une partition quand aucun trafique multicast n'a été envoyé. Si un trafique multicast est envoyé, la detection du merge se produit automatiquement en tant que fonction du protocole. Défaut: 200ms
downcheck Ce timeout spécifie, en ms, combien de temps attendre avant de vérifie qu'une interface réseaux est de nouveau disponible après une indisponibilité. Défaut: 1000ms
fail_recv_constf Cette constante spécifie combien de rotations du token sans recevoir de messages quand les message devaient être reçus peuvent se produire avant qu'une nouvelle configuration ne soit formée. Défaut: 2500 échecs de réception de message.
seqno_unchanged_const Cette constante spécifie combient de rotation du token sans trafique multicast devrait se produire avant que le timer hold soit démarré. Défaut: 30 rotations.
heartbeat_failures_allowed Mécanisme HeartBeating. Configure le mécanisme HeartBeating pour une détection d'erreur plus rapide. Garder en mémoire qu'engager ce mécanisme dans un réseau avec beaucoup de perte peut causer les déclaration de fausse perte vu que le mécanisme ne se base que sur le réseau. Défaut: 0 (désactivé)
max_network_delay Mécanisme HeartBeating. Cette constante spécifie, en ms, le délai approximatif que le réseau prend pour transporter un packet d'une machine à une autre. Cette valeur doit être définie par les ingénieurs système. Défaut: 50ms
window_size Cette constante spécifie le nombre de messages qui peuvent être envoyés en une rotation de token. Si tous les processeurs traitent de manière égale, cette valeur peut être grande (300). pour réduire la latence dans les grand ring (›=16), le défaut est un compromis de sûreté. Si un ou plusieurs processeur sont lents, window_size ne devrait pas être supérieur à 256000 / netmtu pour éviter la surchage des tampon. Défaut: 50 messages.
max_messages Cette constante spécifie le nombre maximum de messages qui peuvent être envoyés par un processeur à la réception du token. Ce paramètre est limité à 256000 / netmtu pour empêcher la saturation des tampons de transmission.
miss_count_const Définie le nombre maximum de fois à la réception d'un token qu'un message est vérifié pour retransmission avant qu'une retransmission se produise. Défaut: 5 messages.
rrp_problem_count_timeout Spécifie le temps en ms d'attente avant de décrémenter le compteur de problème de 1 pour un ring particulier pour s'assurer qu'un lien n'est pas marqué en panne. (Défaut: 2000 ms)
rrp_problem_count_threshold Spécifie le nombre de fois qu'un problème est détecté avec un lien avec de définir ce lien en faute. Une fois en faute, plus aucune donnée n'est émise sur ce lien. Également, le compteur de problème n'est plus décrémenté quand le timeout de compteur de problème expire. Un problème est détecté quand tous les tokens d'un processeur n'a pas été reçus dans le rrp_token_expired_timeout. Les rrp_problem_count_threshold * rrp_token_expired_timeout devrait être au moins à 50ms inférieur au timeout du token, ou une reconfiguration complète peut se produire. Défaut: 10 problèmes.
rrp_problem_count_mcast_threshold Spécifie le nombre de fois qu'un problème est détecté avec un multicast avant de définis le lien en faute pour un mode rrp passif. Cette variable n'est pas utilisée pour un mode rrp actif.
rrp_token_expired_timeout Spécifie le temps en ms pour incrémenter le compteur de problème pour le rrp après avoir reçu un token de tous les rings pour un processeur particulier. Cette valeur est automatiquement calculée du timeout de token et problem_count_threshold mais peut être écrasé. Défaut: 47ms
rrp_autorecovery_check_timeout Spécifie le temps en ms pour vérifier si le ring en panne peut être auto-récupéré.

Options logging

timestamp Spécifie si un horodatage est placé dans les messages de log. Défaut: off
fileline spécifique que le fichier et la ligne devrait être affichés. Défaut: off
function_name Spécifie que le nom de la fonction devrait être affiché. Défaut: off
to_stderr
to_logfile
to_syslog spécifient la sortie de logging. peut être yes ou no. Défaut: syslog et stderr
logfile si to_logfile est à yes, cette option spécifie le chemin du fichier de log.
logfile_priority Priorité du logfile pour un sous-système particulier. Ignoré si debug est on. (alert,crit, debug, emerg, err, info, notice, warning) Défaut: info.
syslog_facility Type de facilité syslog ( daemon, local0, local1, local2, local3, local4, local5, local6 et local7). Défaut: daemon
syslog_priority Log level pour le sous-système particulier ( alert, crit, debug, emerg, err, info, notice, warning ) Défaut: info
debug Active le debug. Défaut: off.

Options logger_subsys

Toutes les options de la directive logging sont valide, plus:
subsys Spécifie le nom du sous-système pour lequel le logging est spécifié. C'est le nom utilisé par un service dans l'appel log_init. Cette directive est requise.

Options quorum

provider seul corosync_votequorum est supporté.

Options nodelist

ringX_addr Spécifie l'adresse IP d'un des nœuds. X est le numéro du ring.
nodeid Requis pour IPv6, optionnel pour IPv4. valeur 32bits spécifiant l'identifiant du nœud délivré au service de cluster membership. 0 est réservé et ne doit pas être utilisé.

Options qb

ipc_type Type d'IPC à utiliser. Peut être native, shm et socket. Native signifie soit shm soit socket, en fonction de ce qui est supporté par l'OS. shm est généralement plus rapide, mais nécessite d'allouer un tampon ring dans /dev/shm.
^
26 janvier 2015

htmlpdflatexmanmd




corosync.xml

corosync.xml

version xml du fichier corosync.conf

   /etc/corosync/corosync.xml est utilisé par corosync-xmlproc pour générer un fichier de configuration valide. Ce fichier doit être un fichier xml valide, commençant avec l'élément racine corosync qui peut contenir les mêmes arguments que décris dans corosync.conf.

^
30 juin 2010

htmlpdflatexmanmd




cp

cp

Copie de fichiers

   La copie est complètement indépendante de l'original. Si 2 noms de fichiers sont donnés, copie le premier fichier dans le deuxième. Si -t est spécifié ou que le dernier fichier est un répertoire et que -T n'est pas donné, cp copie chaque fichier dans ce répertoire.

  Généralement, les fichiers sont écris comme ils sont lus, à l'exception de l'option --sparse. Par défaut cp ne copie pas les répertoires si -R, -a ou -r est spécifié, cp copie récursivement.

  En copiant un lien symbolique, cp suit le lien seulement quand il réfère à une fichier régulier existant. Par défaut cp copie le contenus des fichiers spéciaux seulement si la copie n'est pas récursive. Peut être modifié par --copy-contents

  cp refuse généralement de copier un fichier dans lui-même, sauf si --force --backup est spécifié, et réfère à un fichier régulier. cp va créer un fichier backup, soit régulier soit numéroté.

OPTIONS

-a, --archive Préserve autant que possible la structure et les attributs des fichiers originaux dans la copie (mais ne tente pas de préserver la structure interne des répertoires.) essaye de préserver le contexte de sécurité SELinux et les attributs étendus, mais ignore les erreurs. Équivalent à -dR --preserve=all sans les diagnostiques.
-b, --backup[=METHOD] Créer une sauvegarde de chaque fichier qui aurait été écrasé ou supprimé.
--copy-contents En copie récursive, copie le contenu des fichiers spéciaux comme s'ils étaient des fichiers réguliers. A généralement un effet indésirable.
-d copie les liens symbolique au lieu de copier leur référence, et préserve les liens durs entre les fichiers sources dans les copies. Équivalent à --no-dereference --preserve=links
-f, --force Si un fichier de destination ne peut pas être ouvert, force sa suppression et essaye de le réouvrir.
-H si un argument spécifie un lien symbolique, copie sa référence au lieu du lien.
-i, --interactive en copiant un fichier autre qu'un répertoire, demande avant d'écraser un fichier existant.
-l, --link Créer des liens dur au lieu de copies de fichier autre que les répertoires.
-L, --dereference Suit les liens symboliques
-n, --no-clobber N'écrase pas de fichier existant
-P, --no-dereference Copie les liens symboliques au lieu de la référence
-p, --preserve[=ATTRIBUTE_LIST] préserve les attributs spécifiés des fichiers originaux. si spécifiés, ATTRIBUTE_LIST doit être une liste séparé par des ',' :

        mode préserve les bits de mode des fichiers et les acl
        ownership préserve le user:group.
        timestamp préserve le atime et mtime quand c'est possible. généralement pas possible pour les liens symboliques.
        links préserve dans les fichiers de destination les liens entre les fichiers source correspondant.
        context préserve le contexte de sécurité SELinux.
        xattr préserve les attributs étendus
        all Préserve tous les attributs des fichiers

--no-preserve=ATTRIBUTE_LIST ne préserve par les attributs spécifiés.
--parents Forme le nom de chaque fichier de destination en ajoutant au dossier cible un '/' et le nom de chaque fichier source. ex : cp --parents a/b/c existing_dir, copie le fichier a/b/c dans existing_dir/a/b/c, créant ainsi les dossiers intermédiaires.
-R, -r, --recursive copie les répertoire récursivement.
--remove-destination supprime chaque fichier existant dans la destination avant de tenter de l'ouvrir.
--sparse=WHEN Les 'sparse files' contiennent des 'trous", une séquence d'octets à 0 qui n'occupent pas d'espace disque. L'appel système read les lit. Cela peut sauver beaucoup d'espace disque et augmenter la vitesse, vu que beaucoup de fichiers binaires contiennent beaucoup d'octets à 0 consécutif. Par défaut, cp détecte des séquences dans les fichiers source et créer le fichier de sortie étendue. WHEN peut être :

        auto Le mode par défaut : si l'entrée est 'sparse', tente de produire un fichier 'sparse', sauf si ce n'est pas un fichier régulier.
        always Pour chaque séquence suffisamment longue d'octets à zéro dans le fichier d'entrée, tente de créer un trou correspondant dans le fichier de sortie, même si le fichiers d'entrée ne semble pas être 'sparse'.
        never ne créer jamais de fichier de sortie 'sparse'. Utile pour créer un fichier à utiliser avec mkswap, vu qu'un tel fichier de doit pas avoir de trou.

--skip-trailing-slashes supprime les '/' de fin de chaque argument source.
-s, --symbolic-link Créer des lien symboliques au lieu de copies des fichier non-répertoire. Les fichiers sources doivent être absolus, à moins que le fichier de destination ne soit dans le répertoire courant.
-S SUFFIX, --suffix=SUFFIX Ajoute SUFFIX à chaque fichier backup crée avec -b
-t DIRECTORY, --target-directory=DIRECTORY Spécifie le répertoire de destination
-T, --no-target-directory ne traite pas le dernier opérande spécialement quand c'est un répertoire ou un lien symbolique.
--update Ne copie pas un fichier autre que répertoire qui a une destination existante avec un mtime identique ou plus récent.
-v, --verbose Affiche le nom de chaque fichier en cour de copie.
-x, --one-file-system Ne copie pas les fichiers qui sont sur un système de fichier différents. Les points de montage sont copiés.
^
03 février 2016

htmlpdflatexmanmd




cpuid

cpuid

Périphérique d'accès aux identifiants de CPU x86

   CPUID fournit une interface pour demander des informations concernant un CPU x86. On accède à ce périphérique en utilisant lseek(2) ou pread(2) avec le niveau CPUID approprié et en lisant des blocks de 16 octets. Des lectures plus importantes indiquent la lecture de plusieurs niveaux consécutifs.

   Les 32 bits LSB dans le fichier sont utilisés comme registre d'entrée %eax, et les 32 bits MSB comme registre d'entrée %ecx, ce dernier étant utilisé pour compter les niveaux eax, comme pour eax=4.

   Ce pilote utilise /dev/cpu/CPUNUM/cpuid, ou CPUNUM est le numéro mineur, et sur un système multiprocesseur enverra les accès au CPU numéro CPUNUM d'après la liste dans /proc/cpuinfo. Ce fichier est protégé de telle sorte que seul root ou membres du groupe root puissent y accéder.

Notes

   L'instruction CPUID peut être exéucutée directement par un programme utilisant de l'assembleur en ligne. Cependant ce périphérique fournit une méthode d'accès commode à tous les CPU sans changer l'affinité du processus.

   La plupart des informations de cpuid sont renvoyés par le noyau de façon formatée dans /proc/cpuinfo ou dans les sous-répertoires de /sys/devices/system/cpu. Un accès direct à CPUID par ce périphérique ne doit être utilisé que dans les cas exceptionnels.

   Le pilote cpuid n'est pas chargé automatiquement. Avec les noyaux modulaires il est possible de le charger avec modprobe cpuid. Il n'y a pas de prise en charge des fonctions CPUID qui nécessitent des registres d'entrée supplémentaires.
^
11 février 2015

htmlpdflatexmanmd




crmd

crmd

Service crmd

OPTIONS

dc-version = string [none] Version de Pacemaker dans le DC du cluster
cluster-infrastructure = string [heartbeat] La pile de messagerie sur lequel Pacemaker fonctionne
dc-deadtime = time [20s] Temps d'attente pour une réponse d'autres nœuds durant le démarrage
cluster-recheck-interval = time [15min] Interval pour les changements d'options, paramètres de ressources et contraintes basées sur le temps
load-threshold = percentage [80%] Quantité maximum de ressources système qui devraient être utilisé par les nœuds du cluster
node-action-limit = integer [0] Nombre de jobs maximum qui peuvent être planifiés par nœuds. Défaut: 2x cœurs.
election-timeout = time [2min] Le besoin d'ajuster cette valeur indique la présence d'un bug
shutdown-escalation = time [20min] Le besoin d'ajuster cette valeur indique la présence d'un bug
crmd-integration-timeout = time [3min] Le besoin d'ajuster cette valeur indique la présence d'un bug
crmd-finalization-timeout = time [30min] Le besoin d'ajuster cette valeur indique la présence d'un bug
crmd-transition-delay = time [0s] Activer cette option va ralentir la récupération du cluster.
^
08 février 2015

htmlpdflatexmanmd




crm_attribute

crm_attribute

Gère les attributs de nœuds et les options du cluster

OPTIONS

-q, --quiet mode silencieux
-v, --verbose mode verbeux
-n, --name=value Le nom de l'attribut

Commandes

-u, --upgrade Met à jours la valeur de l'attribut/option
-Q, --query Requête la valeur courante de l'attribut/option
-D, --delete Supprime l'attribut/option

Options additionnelles

-N, --node=value Définis un attribut pour le nœud nommé ( au lieu d'une option du cluster)
-t, --type=value Quelle partie de la configuration se trouve l'option à mettre à jours/supprimer/requêter (crm_config, rsc_defaults, op_defaults, tickets)
-l, --lifetime=value Durée de vie de l'attribut node (reboot, forever)
-z, --utilization Définis un attribut d'utilisation pour le nœud
-s, --set-name=value Le jeu d'attribut dans lequel placer la valeur.
-i, --id=valeur L'ID utilisé pour identifier l'attribut
-d, --default=value Valeur par défaut à afficher si rien n'est trouvé dans la configuration.

Exemples

Ajouter un nouvel attribut appelé location avec la valeur office pour l'hôte myhost:
crm_attribute --node myhost --name location --update office
Lire la valeur de l'attribut de nœud location pour l'hôte myhost:
crm_attribute --node myhost --name location --query
Changer la valeur de l'attribut de nœud location pour l'hôte myhost:
crm_attribute --node myhost --name location --update backoffice
Supprimer l'attribut du nœud location pour l'hôte myhost:
crm_attribute --node myhost --name location --delete
Lire la valeur de l'option du cluster cluster-delay:
crm_attribute --type crm_config --name cluster-delay --query
Lire la valeur le l'option du cluster cluster-delay, affiche seulement la valeur:
crm_attribute --type crm_config --name cluster-delay --query --quiet
^
08 février 2015

htmlpdflatexmanmd




crm_diff

crm_diff

Utilitaire pour comparer les configurations Pacemaker au format XML. Produit une sortie diff-like qui peut s'appliquer comme un patch.

OPTIONS

-v, --verbose mode verbeux
-o, --original=value Fichier xml
-O, --original-string=valeur chaine xml
-n, --new=value compare l'xml original au contenu du fichier nommé
-N, --new-string=value Compare l'xml original au contenu de la chaîne fournie
-p, --patch=value Patche l'xml original avec le contenu du fichier nommé
-c, --cib Compare/patch l'entrée en CIB
-f, --filter Supprime les différence sans importance entre les 2 entrées

Exemples

Obtenir les 2 fichiers de configuration avec cibadmin dans 2 configurations de cluster:
cibadmin --query › cib-old.xml
cibadmin --query › cib-new.xml
calculer et sauvegarder la différence entre les 2:
crm_diff --original cib-old.xml --new cib-new.xml › patch.xml
Appliquer le patche au fichier original:
crm_diff --original cib-old.xml --patch patch.xml › updated.xml
Appliquer le patche au cluster courant:
cibadmin --patch patch.xml
^
08 février 2015

htmlpdflatexmanmd




crm_error

crm_error

Outil pour afficher une description textuelle sur un code d'erreur

OPTIONS

-v, --verbose mode verbeux
^
08 février 2015

htmlpdflatexmanmd




crm_failcount

crm_failcount

Wrapper pour crm_attribute. Définis, met à jour ou supprime le compteur d'erreur pour la ressource spécifiée ou le nœud nommé.

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux
-r, --resource-id=value Ressource à mettre à jours

Commandes

-v, --upgrade Met à jours la valeur de l'attribut/option
-G, --query Requête la valeur courante de l'attribut/option
-D, --delete Supprime l'attribut/option

Options additionnelles

-N, --node=value Définis un attribut pour le nœud nommé ( au lieu du courant)
-l, --lifetime=value Durée de vie de l'attribut (reboot, forever)
-i, --id=valeur L'ID utilisé pour identifier l'attribut
^
08 février 2015

htmlpdflatexmanmd




crm_master

crm_master

Wrapper pour crm_attribute. Met à jours, définis ou supprime un score de promotion d'une ressource. Ne devrait être invoqué qu'avec un agent de ressource OCF.

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux

Commandes

-v, --upgrade Met à jour la valeur de l'attribut/option
-G, --query Requête la valeur courante de l'attribut/option
-D, --delete Supprime l'attribut/option

Options additionnelles

-N, --node=value Définis un attribut pour le nœud nommé ( au lieu du courant)
-l, --lifetime=value Durée de vie de l'attribut (reboot, forever)
-i, --id=valeur L'ID utilisé pour identifier l'attribut
^
08 février 2015

htmlpdflatexmanmd




crm_mon

crm_mon

Fournis un sommaire de l'état courant du cluster

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux

Modes

-h, --as-html=value Écrit le status du cluster dans le fichier html donné
-X, --as-xml Écrit le statut du cluster en xml sur sdtout.
-w, --web-cgi Affiche le statut du cluster comme sortie simple ligne (utilisable par nagios)
-S, --snmp-traps=value Envoie des traps snmp à cette station
-C, --snmp-community=value Spécifie la communauté snmp.

Options d'affichage

-n, --group-by-node Groupe les ressources par nœud
-r, --inactive Affiche les ressources inactives
-f, --failcounts Affiche les compteurs d'erreur
-o, --operations Affiche l'historique des opérations des ressources
-t, --timing-details Affiche l'horodatage de l'historique des opérations des ressources
-c, --tickets Affiche les tickets des clusters
-W, --watch-fencing Écoute pour les évènements de fencing.
-A, --show-node-attributes Affiche les attributs de nœud

Options additionnelles

-i, --interval=value fréquence de rafraîchissement en seconde
-1, --one-shot Affiche le status une seule fois sur la console et quitte.
-N, --disable-ncurses Désactive l'utilisation de ncurses
-d, --daemonize Lance en tâche de fond
-p, --pid-file=value Emplacement du fichier pid
-E, --external-agent=value Un programme à lancer quand les opérations de ressource prennent effet.
-e, --external-recipient=value Un conteneur pour le programme.

Exemples

Afficher le statut du cluster sur la console et les mises à jours qui se produisent:
crm_mon
Afficher le statut du cluster sur la console une seul fois:
crm_mon -1
Afficher le statut du cluster, grouper les ressources par nœud, et inclure les ressources interactives dans la liste:
crm_mon --group-by-node --inactive
Lancer crm_mon en tâche de fond et écrire dans un fichier html:
crm_mon --daemonize --as-html /path/to/file.html
Lancer crm_mon et exporter le statut en xml sur stdout, puis quitter:
crm_mon --as-xml
Lancer crm_mon en tâche de fond et envoyer les alertes snmp:
crm_mon --daemonize --snmp-traps snmptrapd.example.com
^
08 février 2015

htmlpdflatexmanmd




crm_node

crm_node

Outil d'affichage des informations de nœud bas-niveau

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux

Stack

-A, --openais Tente de se connecter seulement à un cluster basé sur OpenAIS
-H, --heartbeat Tente de se connecter seulement à un cluster basé sur Hearbeat

Commandes

-n, --name Affiche le nom utilisé par le cluster pour ce nœud
-N, --name-for-id=value Affiche le nom utilisé par le cluster pour le nœud avec l'id spécifié
-e, --epoch Affiche le temps auquel le nœud a joins le cluster
-q, --quorum Affiche un 1 si la partition a un quorum, 0 sinon
-l, --list Affiche tous les membres connus (passé et présents) de ce cluster)
-p, --partition Affiche les membre de cette partition
-i, --cluster-id Affiche l'id du nœud de ce cluster
-R, --remove=value Supprime le nœud stoppé avec le nodeid spécifie dans le cluster.

Options additionnelles

-f --force Force l'opération
^
08 février 2015

htmlpdflatexmanmd




crm_report

crm_report

Créer une archive contenant tout ce qui est nécessaire pour reporter les problèmes de cluster

OPTIONS

-v Augmente la verbosité
--features Fonctionnalités du logiciel
-f, --from time Heure de début au format "YYYY−M−D H:M:S"
-t, --to time Heure de fin (défaut: now)
-T, --cts test Test CTS ou jeu de tests à extraire
--cts-log Fichier de log maître CTS
-n, --nodes nodes Noms des nœuds pour ce cluster seulement nécessaire si le cluster n'est pas actif sur la machine courante
-l, --logfile file Fichier de log pour la collecte
-p patt Expression régulière additionnelle pour matcher les variables à supprimer (défaut: "passz.*")
-L patt Expression régulière additionnelle pour matcher dans les logs (défaut: CRIT: ERROR:)
-M Collecte seulement les logs spécifié par -l
-S, --single-node Opéraion de nœud simple, ne tente pas de démarrer de collecteur de rapports sur d'autres nœuds
-c, --cluster type Force le type de cluster (corosync,openais,heartbeat,logmaster)
-C, --corosync Force le type de cluster corosync
-u, --user user user ssh pour les nœuds du cluster (défaut: root)
--dest Fichier/répertoire de destination

Exemples

crm_report −f "2011−12−14 13:05:00" unexplained−apache−failure crm_report −f 2011−12−14 −t 2011−12−15 something−that−took−multiple−days crm_report −f 13:05:00 −t 13:12:00 brief−outage
^
08 février 2015

htmlpdflatexmanmd




crm_resource

crm_resource

Effectue des tâche liées aux ressources du cluster. Permet aux ressources d'être requêtée (définition et emplacement), modifiées, et déplacée dans le cluster.

OPTIONS

-v, --verbose mode verbeux
-q, --quiet mode silencieux
-r, --resource=value ID de la ressource

Queries

-L, --list Liste toutes les ressources du cluster
-l, --list-raw Liste les ID de toutes les ressources instantiées
-O, --list-operations Liste les opérations de ressources actives.
-o, --list-all-operations Liste toutes les opérations de ressource.
--list-standards Liste les standards supportés
--list-ocf-providers Liste tous les fournisseur OCF disponibles
--list-agents=value Liste tous les agents disponibles pour le standard nommé et/ou fournisseur
--list-ocf-altenatives=value Liste tous les fournisseurs disponibles pour l'agent OCF
--show-metadata=value Affiche les méta-données pour le class:provider:agent donné
-q, --query-xml Requête la définition d'une ressource (template étendu)
-w, --query-xml-raw Requête la définition d'une ressource (xml brut)
-W, --locate Affiche l'emplacement courante d'une ressource
-A, --stack Affiche les prérequis et dépendances d'une ressource
-a, --constraints Affiche les contraintes d'emplacement qui s'appliquent à une ressource

Commandes

-p, --set-parameter=value Définis le paramètre spécifié pour une ressource.
-g, --get-parameter=value Affiche le paramètre spécifié pour une ressource.
-d, --delete-parameter=value Supprime le paramètre spécifié pour une ressource.
-M, --move Déplace une ressource depuis son emplacement courant, en spécifiant optionnellement une destination (-N) et/ou une durée pour laquelle elle doit prendre effet (-u).
-U, --un-move Supprime toutes les contraintes crées par une commande move.

Commandes avancées

-D, --delete Supprime une ressource du CIB
-F, --fail Dis au cluster que cette ressource a échoué
-R, --refresh Rafraîchit le CIB depuis le LRM
-C, --cleanup Supprime une ressource du LRM
-P, --reprobe Re-vérifie les ressources démarrées en dehors du CRM.
--force-stop Bypasse le cluster et stop une ressource sur le nœud local
--force-start Bypasse le cluster et démarre une ressource sur le nœud local
--force-check Bypasse le cluster et vérifie l'état d'une ressource dans le nœud local

Options additionnelles

-N, --node=value uname de l'hôte
-t, --resource-type=value type de ressource (primitive, clone, group, ...)
-v, --parametr-value=value Valeur à utiliser avec -p, -g ou -d
-u, --lifetime=value durée de vie des contraintes de migration
-m, --meta modifie un attribut d'utilisation de ressource.
-s, --set-name=value ID de l'objet instance_attributes à changer
-i, --nvpair=value ID de l'objet nvpair à changer/supprimer
-f, --force

Exemples

Lister les ressources configurées
crm_resource --list
lister les agents OCF disponibles
crm_resource --list-agents ocf
lister les agents OCF disponibles du projet linux-ha:
crm_resource --list-agents ocf:heartbeat
Affiche l'emplacement courant de myResource:
crm_resource --resource myResource --locate
déplace myResource sur une autre machine:
crm_resource --resource myResource --move
déplace myResource vers une machine spécifique:
crm_resource --resource myResource --move --node altNode
Permet à myResource de revenir à son emplacement original:
crm_resource --resource myResource --un-move
Dit au cluster que myResource a échoué:
crm_resource --resource myResource --fail
Stop un myResource ( et tout ce qui dépend de lui):
crm_resource --resource myResource --set-parameter target-role --meta --parameter-value Stopped
Dit au cluster de ne pas gérer myResource:
crm_resource --resource myResource --set-parameter is-managed --meta --parameter-value false
Efface l'historique d'opération de MyResource dans aNode:
crm_resource --resource MyResource --cleanup --node aNode
^
08 février 2015

htmlpdflatexmanmd




crm_shadow

crm_shadow

Effectue un changement de configuration dans une copie shadow avant de mettre à jours le cluster actif. Définis un environnement dans lequel les outils de configuration ( cibadmin, crm_resource, etc) travaillent offline au lieu du cluster en cours, permettant de visualiser les changements et de tester les effets.

OPTIONS

-V, --verbose Augmente la verbosité
-w, --which Indique la copie shadow active
-p, --display Affiche le contenu de la copie shadow active
-E, --edit Édite le contenu de la copie shadow avec l'$EDITOR
-d, --diff Affiche les changements dans la copie shadow active
-F, --file Affiche l'emplacement de la copie shadow active

Commandes

-c, --create=value Créé la copie shadow nommée depuis la configuration du cluster actif
-e, --create-empty=value Créé la copie shadow nommée avec une configuration de cluster vide
-C, --commit=value Met à jour le contenu de la copie shadow nommée dans le cluster
-D, --delete=value Supprime le contenu de la copie shadow nommée
-r, --reset=value Recrée la copie shadow nommée depuis la configuration du cluster actif.
-s, --switch=value bascule sur la copie shadow nommée

Options additionnelles

-f, --force Force l'action
-b, --batch Ne crée par un nouveau shell
-a, --all Upload tout le CIB, uncluant le status avec --commit.

Exemples

Créer une copie shadow vide
crm_shadow --create-empty myShadow
Créer une copie shadow depuis la configuration du cluster
crm_shadow --create myShadow
Affiche la configuration shadow courante:
crm_shadow --display
supprime la configuration shadow courante:
crm_shadow --delete myShadow
Upload le configuration shadow courante dans le cluster
crm_shadow --commit myShadow
^
08 février 2015

htmlpdflatexmanmd




crm_simulate

crm_simulate

Outil pour simuler la réponse du cluster à des évènements

OPTIONS

-V, --verbose Augmente la verbosité
-q, --quiet mode silencieux

Opérations

-R, --run Détermine la réponse du cluster à une configuration et un statut donné.
-S, --simulate Simule l'exécution de transition et affiche le statut du cluster résultant
-X, --in-place Simule l'exécution de transition et stocke le résultat dans le fichier d'entrée
-s, --show-scores Affiche les scores d'allocation
-U, --show-utilization Affiche des informations d'utilisation
-P, --profile=value Lance tous les tests dans le répertoire nommé pour créer des données de profile

Évènements de cluster

-u, --node-up=value Met un nœud online
-d, --node-down Met un nœud offline
-f, --node-fail Marque un nœud en erreur
-i, --op-inject=value $rsc_$task_$interval@$node=$rc - Injecte la tâche spécifiée avant de lancer la simulation
-F, --op-fail=value $rsc_$task_$interval@$node=$rc - Échoue la tâche spécifiée durant la simulation
-t, --set-datetime=value Définis la date
-q, --quorum=value Spécifie une valeur pour le quorum
-g, --ticket-grant=value Autorise un ticket
-r, --ticket-revoke=value Révoque un ticket
-b, --ticket-standby=value Crée un ticket standby
-e, --ticket-activate=value Active un ticket

Options de sortie

-I, --save-input=value Sauvegarde la configuration dans le fichier nommé
-O, --save-output=value Sauvegarde la configuration dans le fichier nommé
-G, --save-graph=value Sauvegarde le graphe de transition (xml) dans le fichier nommé
-D, --save-dotfile=value Sauvegarde le graphe de transition (DOT) dans le fichier nommé
-a, --all-actions Affiche toutes les actions possible dans le graphe DOT.

Source de données

-L, --live-check Se connecte au CIB et utilise le contenu courant en entrée
-x, --xml-file=value Récupère le xml depuis le fichier nommé
-p, --xml-pipe Récupère le xml depuis stdin
^
08 février 2015

htmlpdflatexmanmd




crm_standby

crm_standby

Wrapper pour crm_attribute. Place un nœud en standby. les nœuds en standby ne peuvent pas héberger de ressources cluster

OPTIONS

-V, --verbose Augmente la verbosité
-q, --quiet mode silencieux

Commandes

-G, --query Requête la valeur courante de l'attribut/option
-v, --update=value Met à jour la valeur de l'attribut/option
-D, --delete Supprime l'attribut/option

Options additionnelles

-N, --node=value Définis un attribut pour le nœud nommé (au lieu du nœud courant)
-l, --lifetime=value Jusqu'à quand cela doit prendre effet. (reboot, forever)
-i, --id=value L'id utilisé pour identifier l'attribut
^
08 février 2015

htmlpdflatexmanmd




crm_ticket

crm_ticket

Effectue des tâches liées aux tickets du cluster. Permet aux attributs de ticket d'être requêtés, modifiés ou supprimés.

OPTIONS

-V, --verbose Augmente la verbosité
-q, --quiet mode silencieux
-t, --ticket=value ID de ticket

Requêtes

-l, --info Affiche les informations du ticket
-L, --details Affiche les détails du ticket
-w, --raw Affiche l'ID du ticket
-q, --query-xml Requête le xml du ticket
-c, --constraints Affiche les contraintes src_ticket qui s'appliquent au ticket

Commandes

-g, --grant Autorise un ticket à ce site de cluster
-r, --revoke Révoque un ticket du site de cluster
-s, --standby Dit au site de cluster que ce ticket est en standby
-a, --activate Dit au site de cluster que ce ticket est actif

Commandes avancées

-G, --get-attr=value Affiche l'attribut nommé pour un ticket
-S, --set-attr=value Définis l'attribut nommé pour un ticket
-D, --delete-attr=value Supprime l'attribut nommé pour un ticket
-C, --cleanup Supprime tous les états d'un ticket avec ce site de cluster

Options additionnelles

-v, --attr-value=value Valeur d'attribut à utiliser avec -S
-d, --default=value Valeur d'attribut par défaut à afficher s'il n'est pas trouvé.
-f, --force Force l'action
-n, --set-name=value ID de l'objet instance_attributes à changer
-i, --nvpair=value ID de l'objet nvpair à changer/supprimer

Exemples

Afficher les informations des tickets
crm_ticket --info
Afficher le XML de ticketA:
crm_ticket --ticket ticketA query-xml
Afficher les contraintes rsc_ticket qui s'appliquent à ticketA:
crm_ticket --ticket ticketA --constraints
Autoriser ticketA:
crm_ticket --ticket ticketA --grant
lis la valeur de l'attribut granted:
crm_ticket --ticket ticketA --get-attr granted
Définis la valeur de l'attribut standby:
crm_ticket --ticket ticketA --set-attr standby --attr-value true
Supprime l'attribut granted
crm_ticket --ticket ticketA --delete-attr granted
Efface l'historique des opération de ticketA
crm_ticket --ticket ticketA --cleanup
^
08 février 2015

htmlpdflatexmanmd




crm_verify

crm_verify

Vérifie une configuration complète.

OPTIONS

-V, --verbose Augmente la verbosité

Source de données

-L, --live-check Vérifie la configuration utilisée par le cluster en cours
-x, --xml-file=value Vérifie la configuration dans le fichier nommé
-X, --xml-text=value Vérifie la configuration dans la chaîne spécifiée
-p, --xml-pipe Vérifie la configuration depuis stdin

Options additionnelles

-S, --save-xml=value Sauvegarde le XML vérifié dans le fichier nommé.
^
22 mai 2010

htmlpdflatexmanmd




cron

cron

Utilitaire de planification de tâches

   cron est un utilitaire pour exécuter des commandes à une date et une heure spécifique. cron est démarré automatiquement depuis /etc/init.d en entrant dans un runlevel multi-users.

OPTIONS

-f Ne démonise pas cron
-l Active la compatibilité LSB des noms dans les fichiers /etc/cron.d
-L Définit le niveau de log

Notes

   Cron recherche dans /var/spool/cron/crontab (ces fichiers sont nommés d'après les comptes dans /etc/passwd). Les crontab trouvés sont chargés en mémoire. Notez que les crontab dans ce dossier ne devraient pas être modifiés, la commande crontab doit être utilisé pour accéder à ces fichiers.

  Cron lit aussi /etc/crontab, qui a un format légèrement différent. additionnellement, cron lit les fichiers dans /etc/cron.d. En général un admin ne devrait pas utiliser /etc/cron.d/, mais utiliser plutôt /etc/crontab.
^
23 mai 2017

htmlpdflatexmanmd




cronrc

cronrc

Fichier de configuration pour tigercron

Liste des champs

1. Liste d'heures
2. Liste de jours du mois
3. Liste de joures de la semaine
autres scripts à exécuter

Exemples

Vérifier les signes d'intrusion connues toutes les 8 heures:
0,8,16 * * check_known check_rootkit check_logfiles check_runprocs check_rootdir check_root
check_finddeleted est très verbeux, donc on le lance moins souvent:
1 * * check_finddeleted
Vérification système tous les jours à 1heure
1 * * check_system
Obtenir une liste de processus en écoute chaque jours à différentes heures
0,4,6,10,14,18,20 * * check_listeningprocs
Vérifier les informations utiles de comptes
2 * * check_accounts check_rhosts check_netrc check_group check_passwd check_passwdformat
Vérifie les permissions de fichiers et les mots de passe:
5 * * check_perms
Vérifie la configuration réseaux tous les lundi
3 * Mon check_inetd check_exports check_aliases check_path check_crontabs check_anonftp check_printcap check_tcpd
Vérifie les fichiers une fois par mois
2 1 *  find_files
2 3 *  check_devices
Vérifier la configuration système une fois par mois
1 2 *  check_services check_umask check_ftpusers check_embedded check_exrc
Vérifier la force des mots de passe
2 2 *  crack_run
Lancer une vérification d'intégrité chaque semaine
5 * Mon tripwire_run
5 * Mon aide_run
5 * Mon integrit_run
Pour les vérification de signature il est préférable de le lancer manuellement une fois /usr/lib/tiger/systems/$OS/$VERSION/signatures téléchargé:
5 * Mon check_signatures
^
22 mai 2010

htmlpdflatexmanmd




crontab

crontab

Installer/Désinstaller des tâches cron

   crontab est utilisé pour installer, désinstaller ou lister les tables utilisées par cron. Chaque utilisateur peut avoir son propre crontab. Ces fichier sont maintenus dans /var/spool/cron/crontab.

  Si le fichier /etc/cron.allow existe, l'utilisateur doit y être listé pour utiliser cette commande. si /etc/cron.deny existe, l'utilisateur ne doit pas y être listé pour pouvoir utiliser cette commande.

OPTIONS

-u permet de spécifier l'utilisateur, sinon crontab utilise le crontab de l'utilisateur courant
-l affiche les tâche installée
-r supprimer le crontab courant
-e  permet d'éditer le crontab courant
-i modifie l'option -r pour demander confirmation avant de supprimer

Fichiers crontab

   Certaines variable sont déjà paramètrés: SHELL vaut /bin/sh, et LOGNAME et HOME sont paramétrés avec /etc/passwd. si MAILTO est paramétré, cron peut envoyer un mail.

  Cron supporte le module pam-env, et charge l'environnement spécifié par /etc/environement et /etc/security/pam_env.conf.

le format de cron chaque ligne a 5 champs suivis par une commande, suivi par un le caractère newline ('\n')
le format de crontab Il est identique mais il inclue un champs pour spécifier l'utilisateur pour la commande.


champs___________valeurs permises
minute______________0-59
heure_______________0-23
jour du mois________1-31
mois________________1-12 ou le nom
jour de la semaine__0-7 ou le nom

- Un champs peut être un * qui signifie toutes les valeurs.
- Les plages de nombre sont permise ex: 8-11
- Les listes sont permises ex: "1,2,5,9", "0-4,8-12"
- des 'pas' peuvent être spécifié avec la plage. ex: "0-23/2" signifie 0,2,4,6,8,10,12,14,16,18,20,22.
- Le jour d'une exécution peut être spécifiée par 2 champs: jour du mois et jours de la semaine.
30 4 1,15 * 5 cette commande sera exécutée à 4h30 le 1er et le 15 de chaque mois, plus tous les vendredi
- Au lieu des 5 champs, un de ces 8 termes spécial peut être utilisé:

        @reboot Lance une fois, au démarrage
        @yearly Lance une fois par an, "0 0 1 1 *"
        @annually idem
        @monthly Lance une fois par mois "0 0 1 * *"
        @weekly Lance une fois par semaine "0 0 * * 0"
        @daily Lance une fois par jour "0 0 * * *"
        @midnight idem
        @hourly lance une fois par heure "0 * * * *"

Exemples

modifier le shell utilisé
SHELL=/bin/bash
envoyer un mail a paul
MAILTO=paul
lancer 5 minute après minuit, chaque jour
5 0 * * * $HOME/bin/daily.job ›› $HOME/tmp/out 2›&1
lancer à 14h14 le premier de chaque mois
15 14 1 * * $HOME/bin/monthly
lancer à 22h les jours de la seamine
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids ?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
^
22 mars 2016

htmlpdflatexmanmd




cryptdisks_start

cryptdisks_start, cryptdisks_stop

wrapper de cryptsetup qui parse /etc/crypttab

   cryptdisks_start est un wrapper de cryptsetup qui parse /etc/crypttab tout comme /etc/init.d/cryptdisks le fait et démarre le mappage dm-crypt qui correspond au nom spécifié.

   cryptdisks_stop est un wrapper de cryptsetup qui parse /etc/crypttab tout comme /etc/init.d/cryptdisks le fait et stop le mappage dm-crypt qui correspond au nom spécifié.

^
22 mars 2016

htmlpdflatexmanmd




cryptmount

cryptmount

Monter/démonter/configurer un système de fichier chiffré

   cryptmount permet de monter ou démonter un système de fichier chiffré dans nécessiter de privilèges root, et l'assister root dans la création de nouveau système de fichiers chiffrés. Une fois la configuration initiale du système de fichier par l'administrateur système, l'utilisateur doit seulement fournir le mot de passe de déchiffrement pour que cryptmount configure automatiquement device-mapper et les cibles loopback avant de monter le système

   cryptmount a été écris en réponse aux différences entre la nouvelle infrastructure device-mapper de linux 2.6 et l'ancien cryptoloop qui permettait aux utilisateurs standards d'accéder aux systèmes de fichiers directement via mount.

OPTIONS

-a, --all Agit sur toutes les cible disponible, ex: pour monter toutes les cibles
-m, --mount Monte la cible spécifiée. L'utilisateur devra fournir un mot de passe pour débloquer la clé de déchiffrement pour le système de fichier.
-S, --status Indique si la cible est montée ou non
-l, --list Liste toutes les cibles disponible, incluant des informations sur le système de fichier et le point de montage.
-c, --change-password Change le mot de passe qui protège la clé de déchiffrement pour un système de fichier donné.
-g, --generate-key size Génère une clé de déchiffrement opur un nouveau système de fichier, avec la taille spécifiée en octets
-e, --reuse-key existing-target Définis une clé de déchiffrement pour un nouveau système de fichier, en utilisant une clé existante pour un autre système de fichier. Uniquement disponible pour root
-f, --config-fd num Lit la configuration des cible depuis le descripteur de fichier spécifié au lieu du fichier de configuration par défaut. Uniquement disponible pour root
-m, --passwd-fd num Lit les mots de passe depuis le descripteur de fichier spécifié au lieu du terminal. Chaque mot de passe est lu une seule fois.
-p, --prepare Prépare les périphériques device-mapper et loopback nécessaire pour accéder à la cible, mais ne la monte pas. Utilisé par root pour installer un système de fichier sur un périphérique chiffré
-r, --release Relache tous les périphériques device-mapper et loopback associés avec un cible particulière. Uniquement disponible pour root.
-s, --swapon Active le paging et swaping pour la cible. Uniquement disponible pour root.
-x, --swapoff Désactive le paging et swaping pour la cible. Uniquement disponible pour root.
-k, --key-managers Liste tous les formats disponibles pour protéger les clés d'accès au système de fichier
-B, --system-boot Configure toutes les cibles marquées "bootaction". Généralement utilisé pour monter automatiquement les systèmes de fichiers chiffré. Uniquement disponible pour root.
-Q, --system-shutdown Stop toutes les cibles marquées bootaction. L'opposé de -B. Uniquement disponible pour root.
-n, --safetynet Tente de stopper toute cible mounté qui devrait normalement être arrêtée avec --unmount ou --swapoff. Uniquement disponible pour root, et prévu exclusivemeent durant l'extinction du système.

Codes de sortie

1 Option de ligne de commande non-reconnue
2 Nom de cible non-reconnue
3 Erreur en exécutant le programme helper
100 Privilèges insuffisants
101 Erreur de sécurité à l'installation

Exemple d'utilisation

   Pour pouvoir créer un nouveau système de fichier chiffré par cryptmount, utiliser le programme cryptmount-setup qui peut être utilisé par le superuser pour le configurer interactivement.

   Alternativement, une configuration manuelle permet un contrôle avancé. Avant de le faire, il faut s'assurer que le kernel supporte /dev/loop et /dev/mapper (modprobe -a loop dm-crypt).

Ensuite, supposons que l'on souhaite définir un nouveau système de fichier chiffré qui aura comme nom "opaque". Si on a une partition libre, disons /dev/hdb63, on peut donc l'utiliser directement pour stocker le système de fichier chiffré. Alternativement, si l'on souhaite stocker le système de fichier chiffré dans un fichier ordinaire, on doit créer un fichier avec par exemple:
dd if=/dev/zero of=/home/opaque.fs bs=1M count=512
Puis remplacer toutes les occurences de /dev/hdb63 avec /home/opaque.fs.

Premièrement, il faut ajouter une entrée dans /etc/cryptmount/cmtab, qui décris le chiffrement qui sera utilisé pour protéger le système de fichier lui-même et la clé d'accès, comme suit:
opaque {
dev=/dev/hdb63 dir=/home/crypt
fstype=ext2 mountoptions=defaults cipher=twofish
keyfile=/etc/cryptmount/opaque.key
keyformat=builtin
}

   Ici, on utilise l'algorithme twofish pour chiffrer le système de fichier lui-même, avec le gestionnaire de clé embarqué utilisé pour protéger la clé de déchiffrement (dans /etc/cryptmount/opaque.key) qui sera utilisé pour chiffrer le système de fichier lui-même, on peut exécuter, en root:

   Cela va générer une clé 32 octets (256bits), qui est connu pour être supportée par twofish, et la stocke dans une forme chiffrée après avoir demandé le mot de passe.

Si on exécute, en root:
cryptmount --prepare opaque
Le mot de passe sera demandé, qui va permettre à cryptmount de définir une cible device-mapper (/dev/mapper/opaque). On peut désormais utiliser les outils standard pour créer le système de fichier dans /dev/mapper/opaque:
mke2fs /dev/mapper/opaque
après avoir exécuté:
cryptmount --release opaque
mkdir /home/crypt
Le système de fichier chiffré est prêt. Généralement, les utilisateurs peuvent le monter avec:
cryptmount -m opaque
ou
cryptmount opaque
et le démontent avec
cryptmount -u opaque

   cryptmount conserve un enregistrement sur quel utilisateur a monté chaque système de fichier pour pouvoir fournir un mécanisme de blockage pour s'assurer que seul le même utilisateur (ou root) peut le démonter.

Changement de mot de passe

Une fois un système de fichier utilisé, on peut souhaiter changer le mot de passe d'accès, par exemple:
cryptmount --change-password opaque

Système de fichier chiffré avec LUKS

   cryptmount peut être utilisé pour fournir un accès simple à aux systèmes de fichier chiffrés compatibles avec LUKS.

Pour accéder à une partition LUKS existante, une entrée a besoin d'être créé dans /etc/cryptmount/cmtab. Par exemple, si la partition /dev/hdb62 est utilisé pour contenir un système de fichier ext3 LUKS, une entrée sous la forme:
LUKS {
keyformat=luks
dev=/dev/hdb62 keyfile=/dev/hdb62
dir=/home/luks-dir fstype=ext3
}

Que permet de monter via cryptmount sous /home/luks-dir en exécutant:
cryptmount LUKS
cryptmount va également permettre à un utilisateur qui connaît un des mots de passe d'accè de changer leur mot de passe via
cryptmount --change-password LUKS

   cryptmount fournis également un support basic pour créer un nouveau système de fichier chiffré LUKS, qui peut être placé dans des fichiers ordinaires aussi bien que des partitions disque, via --generate-key. Cependant, pour exploiter toutes les fonctionnalité de LUKS, tel qu'ajouter plusieurs mots de passes, il faut utiliser cryptsetup.

   Il est fortement recommandé de ne pas tenter d'utiliser le support LUKS en combinaison avec les fonctionnalités de cryptmount pour stocker plusieurs systèmes de fichiers chiffrés dans une simple partition disque ou un fichier ordinaire. Cela est dû à la supposition dans le design de cryptsetup-luks que la clé LUKS est toujours stockée au début de la partition.
^
22 mars 2016

htmlpdflatexmanmd




cryptmount-setup

cryptmount-setup

Définir un nouveau système de fichier chiffré

   cryptmount-setup aide à la configuration initiale du chiffrement d'un système de fichier, pour être géré par cryptmount. Lancé en root, il permet de créer un système de fichier de bas dans un fichier ordinaire. La taille, l'emplacement, le point de montage et le propriétaire du système de fichier peuvent être sélectionnés interactivement.

^
25 mars 2016

htmlpdflatexmanmd




cryptsetup

cryptsetup

Gérer les volumes chiffré dm-crypt et LUKS

   cryptsetup est utilisé pour définir les mappages device-mapper gérés par dm-crypt. Cela inclus les volume dm-crypt et LUKS. La différence est que LUKS utilise en en-tête de méta-données et peut ainsi offrir plus de fonctionnalités que dm-crypt. D'un autre côté, l'en-tête est visible et vulnérable.

   De plus, cryptsetup fournis un support limité des volumes historiques loopaes et pour les volumes compatibles TrueCrypt.

   Beaucoup d'informations sur les riques de l'utilisation de stockage chiffré, la gestion des problèmes et sur les aspects de sécurité peuvent être trouvés dans la FAQ Cryptsetup.

Commandes de base

open ‹device› ‹name› --type ‹device_type› Ouvre (créé un mappage avec) le nom. device_type peut être plain, luks, loopaes ou tcrypt.
close ‹name› Supprime la mappage existant et détruit la clé de la mémoire kernel
status ‹name› Reporte le status pour la mappage donné
resize ‹name› Redimentionne un mappage active

Mode Plain

   plain dm-crypt chiffre le périphérique secteur par secteur avec un simple, non-salted hash de la passphrase. aucune vérification n'est effectuée, aucune métadonnée n'est utilisée. Il n'y a pas d'opération de formattage. Quand le périphérique brut est mappé, les opérations de périphériques peuvent être utilisée sur le périphérique mappé, incluant la création du système de fichier. Les périphériques de mappage peuvent être créés dans /dev/mapper/‹name›.

Extensions LUKS

   LUKS est un standard pour le chiffrement de disque. Il ajoute une en-tête standardisé au début du périphérique, une zone de slot directement derrière l'en-tête et les données bulk ensuite. Toute ce jeu est appelé un conteneur LUKS. Le périphérique où un conteneur LUKS réside est appelé un périphérique LUKS.

   LUKS peut gérér plusieurs passphrases qui peuvent être révoqués individuellement ou changés et peuvent être néttoyés du média persistant de manière sécurisée. Les passphases sont protégées contre le brute-force et les attaques par dictionnaire par PBKDF2, qui implémente une itération de hash et un salt dans une fonction.

   Chaque passphrase, également appelée une clé, est associée avec un des 8 slots. Les opérations de clé qui ne spécifient pas un slot affectent le premier slot qui matche la passphrase fournie ou le premier slot vide si une nouvelle passphrase est ajoutée.

   Le paramètre device peut également être spécifié par un UUID LUKS au format UUID=‹uuid›. Pour spécifier un en-tête détaché, le paramètre --header peut être utilisé dans toutes les commandes LUKS et prend toujours précédence sur le paramètre positionnel device.

  Les options LUKS valides sont les suivantes:

luksFormat ‹device› [‹key file›] Initialise une partition LUKS et définis la passphrase initiale (slot 0), soit en demandant, soit via le fichier spécifié. Noter que si le 2ème argument est présent, la passphrase est prise du fichier donné, sans avoir besoin de l'option --key-file. Noter également que '-' comme nom de fichier lit la passphrase depuis l'entrée standard. cette action ne peut être utilisé que sur des périphériques LUKS qui ne sont pas mappé.
open --type luks ‹device› ‹name› Ouvre le périphérique LUKS et définis un mappage une fois la vérification de la passphrase effectuée.
luksSuspend ‹name› Suspend un périphérique actif (toutes les opérations IO seront blockés et les accès au périphérique attendent indéfiniment.
luksResume ‹name› Résume un périphérique suspendu et redemande une passphrase, si --key-file n'est pas donné
luksAddKey ‹device› [‹key file with new key›] Ajoute une nouvelle passphrase. Une passphrase doit être fournie interactivemenet ou via --key-file.
luksRemoveKey ‹device› [‹key file with passphrase to be removed›] Supprime la passphrase fournie du périphérique LUKS. La passphrase à supprimer peut être spécifiée interactivement ou via --key-file
luksChangeKey ‹device› [‹new key file›] Change une passphrase existante.
luksKillSlot ‹device› ‹key slot number› Détruit la clé du périphérique LUKS.
luksErase ‹device› Supprime tous les keyslots et rend le conteneur inaccessible. Cette opération est irréversible
luksUUID ‹device› Affiche le UUID du périphérique LUKS. Définis un nouvel UUID is --uuid est spécifié
isLuks ‹device› Retourne true, si le périphérique est un périphérique LUKS.
luksDump ‹device› Dump les informations d'en-tête d'une périphériques LUKS. Si l'options --dump-master-key est utilisé, la clé maître est dumpé au lieu du keyslot.
luksHeaderBackup ‹device› --header-backup-file ‹file› Stocke un backup binaire de l'en-tête LUKS et la zone keyslslot.
luksHeaderRestore ‹device› --header-backup-file ‹file› Restaure un backup binaire d'un en-tête LUKS.

Extensions TCRYPT

   cryptsetup supporte le mappage de TrueCrypt, tcplay ou VeraCrypt en utilisant l'API kernel Linux. Le changement de formattage d'en-tête et l'en-tête TCRYPT n'est pas supporté.

   L'extension TCRYPT nécessite l'API crypto disponible dans l'espace utilisateur. (CRYPTO_USER_API_SKCIPHER) Parce que l'en-tête TCRYPT est chiffré, il faut toujours fournir une passphrase valide.

   cryptsetup devrait reconnaître toutes les variantes d'en-tête, excepté les chaînes de chiffrement utilisant le mode de chiffrement LRW avec block de chiffrement 64-bits (blowfish en mode LRW n'est pas reconnu, c'est une limitation de l'API crypto du kernel)

   Parce que l'en-tête TCRYPT est chiffré, il faut toujours fournir une passphrase valide et un keyfile

   Pour reconnaître un périphérique VeraCrypt, utiliser l'option --veracrypt. VeraCrypt est une extension de l'en-tête TrueCrypt avec un compteur d'itération amélioré, donc le déblocage peut prendre plus de temps.

   Note: L'activation avec tcryptOpen est supporté uniquement pour les chaînes de chiffrement utilisant les modes LRW ou XTS.

   tcryptDump devrait fonctionner pour tous les périphériques TCRYPT reconnus et ne nécessite pas de privilège root.

   Pour mapper les périphériques système (avec un boot loader) utiliser l'option --tcrypt-system.

   Si vous avez un périphérique TCRYPT comme fichier image et souhaitez mapper plusieurs partitions chiffrées avec le chiffrement système, créer un mappage loopback avec les partitions en premier (losetup -P), et utiliser la partition loop comme paramètre de périphérique.

   Pour utiliser un en-tête caché, utiliser --tcrypt-hidden. Pour utiliser en-tête backup, utiliser l'option --tcypt-hidden.

open --type tcrypt ‹device› ‹name› Ouvre un périphérique TCRYPT et définis le mappage. keyfile permet de combiner le contenu du fichier avec la passphrase et peut être répétée. Noter qu'utiliser des keyfiles est compatible avec TCRYPT et est différent de la logique keyfile LUKS.
tcryptDump ‹device› Dump les informations d'en-tête. Si --dump-master-key est utilisé, la clé maître est dumpé au lieu de l'en-tête.

Divers

repair ‹device› Tente de réparer les méta-données du périphérique. Uniquement pour les périphériques LUKS
benchmark ‹options› benchmark les chiffrements et les fonction de dérivations de clé (KDF). Sans paramètres, tente de mesurer les configuration communes. Les paramètre --cipher, --key-size ou --hash doivent être spécifiés.

OPTIONS

-v, --verbose mode verbeux
--debug Mode debug
-h, --hash Spécifie le hash de la passphrase à ouvir
-c, --cipher définis le chiffrement
-y, --verify-passphrase Demande 2 fois la passphrase
-d, --keyfile lit la passphrase depuis le fichier
--keyfile-offset Saut n octets au début du fichier de clé
-l, --keyfile-size Taille de la clé en octets dans le fichier de clé
--new-keyfile-offset Saute n octets en ajoutant une nouvelle passphrase dans le fichier de clé avec luksAddKey.
--new-keyfile-size Taille de la clé en octet en ajoutant une nouvelle passphrase dans le fichier de clé avec luksAddKey.
--master-key-file Utilise la clé maître stockée dans un fichier. Pour luksFormat, cela permet de créer un en-tête LUKS avec cette clé maître.
--dump-master-key Pour luksDump, inclus la clé maître dans les informations affichées.
--use-random, --use-urandom Spécifie le générateur de nombre pseudo-aléatoire utilisé pour clé la clé de volume
-S, --key-slot Spécifie le slot de clé à utiliser. Tous les autres slots seront désactivé.
-b, --size Force la taile du périphérique en secteurs de 512 octets.
-o, --offset Décalage du début dans le périphérique en secteurs de 512 octets
-p, --skip Saut n secteurs de 512 octets dans le périphérique.
-r, --readonly Définis un mappage lecture seule
--shared Créé un mappage additionnel pour un périphérique ciphertext commun.
--i, --iter-time Nombre de temps en ms pour le traitement PBKDF2.
-q, --batch-mode mode silencieux
-t, --timeout Temps d'attente de la passphrase
-T, --tries Nombre de tentative pour l'entrée de passphrase invalide
--align-payload Aligne le payload au limites de n secteurs de 512 octets.
--uuid Utilise l'UUID fournis au lieu d'en générer un nouveau
--allow-discards Autorise l'utilisation des requêtes discards (TRIM) déconseillé pour des raisons de sécurité
--perf-same_cpu_crypt Effectue un chiffrement avec le même CPU qui gère les E/S.
--perf-submit_from_crypt_cpus Désactive les écriture offload dans un thread séparé après le chiffrement.
--test-passphrase N'active pas le périphériques, vérifie simplement la passphrase
--header Utilise un périphérique de méta-donnée séparé ou un fichier où se trouve l'en-tête LUKS
--force-password N'utilise pas la vérification du mot de passe LUKS

Codes de retour

0 L'opération s'est déroulé avec succès
1 Mauvais paramètres
2 N'a pas les permissions
3 Out of memory
4 Mauvais périphérique spécifié
5 Le périphérique existe déjà
^
24 mars 2016

htmlpdflatexmanmd




cryptsetup-reencrypt

cryptsetup-reencrypt

Outil de re-chiffrement de périphérique LUKS offline

   cryptsetup-reencrypt re-chiffre les données dans un périphérique LUKS. Durant le processus le périphérique LUKS est marqué non-disponible. Attention, il n'est pas résistant aux erreurs kernel et matériel.

OPTIONS

-v, --verbose mode verbeux
--debug Mode debug
-c, --cipher définis le chiffrement
-s, --key-size Taille de la clé en bits. Doit être un multiple de 8
-h, --hash Spécifie le hash utilisé dans le schéma de configuration de clé LUKS et de clé de volume
-i, --iter-time Nombre de ms de traitement PBKDF2 pour le nouvel en-tête LUKS
--use-random, --use-urandom Spécifie le générateur de nombre pseudo-aléatoire utilisé pour clé la clé de volume
-d, --keyfile lit la passphrase depuis le fichier
-S, --key-slot Spécifie le slot de clé à utiliser. Tous les autres slots seront désactivé.
--keyfile-offset Saut n octets au début du fichier de clé
-l, --keyfile-size Taille de la clé en octets dans le fichier de clé
--keep-key Ne change pas la clé de chiffrement, rechiffre simplement l'en-tête et les keyslots.
-T, --tries Nombre de tentative pour l'entrée de passphrase invalide
--device-size Spécifie la taille du périphérique, au lieu de la taille réelle
--reduce-device-size Agrandit les données d'offset en diminuant la taille du périphérique.
-N, --new Créé un nouvel en-tête
--decrypt Supprime le chiffrement
--use-directio Utilise direct-io pour les options d'E/S.
--use-fsync Utilise l'appel fsync après chaque block écris.
--write-log Met à jours le fichier de log après chaque block écris.
-q, --batch-mode mode silencieux

Codes de retour

0 L'opération s'est déroulé avec succès
1 Mauvais paramètres
2 N'a pas les permissions
3 Out of memory
4 Mauvais périphérique spécifié
5 Le périphérique existe déjà

Exemples

Rechiffrer /dev/sdb1 (change la clé de volume)
cryptsetup-reencrypt /dev/sdb1
Rechiffre et change le chiffrement de le mode de chiffrement
cryptsetup-reencrypt /dev/sdb1 -c aes-xts-plain64
Ajoute le chiffrement LUKS à un périphérique non-chiffré
fdisk -u /dev/sdb
cryptsetup-reencrypt /dev/sdb1 --new --reduce-device-size 4096S
Supprimer le chifffrement LUKS
cryptsetup-reencrypt /dev/sdb1 --decrypt
^
22 mars 2016

htmlpdflatexmanmd




/etc/crypttab

/etc/crypttab

informations statiques sur les systèmes de fichier chiffrés

   Ce fichier contient des informations sur les systèmes de fichiers chiffrés. crypttab est seulement lu par les programmes (cryptdisks_start et cryptdisks_stop), et non en écriture. C'est à l'administrateur système de créer et maintenir ce fichier. Chaque système de fichier est décris sur un ligne sépartée; les champs sur chaque ligne sont séparés par des espaces. L'ordre des enregistrements dans crypttab est importante parce qu'il est lu séquentiellement.

   Le premier champ, target, décris le nom du périphérique mappé. Il doit être un nom de fichier dans composant répertoire. Un périphérique mappé sera créé sous /dev/mapper/target.

   Le second champ, source-device, décris soit le périphérique block spéciale, ou le fichier qui contient les données chiffrées. Au lieu de donner le périphérique explicitement, l'UUID est supporté également.

   Le troisième champ, Key-file, décris le fichier à utiliser comme clé pour déchiffrer les données. Noter que le fichier de clé sera utilisé comme passphrase; la passphrase ne doit pas être suivie par le caractèse newline. Peut églalement être un nom de périphérique.

   Si le fichier de clé est la chaîne "none", une passphrase sera lue interactivement depuis la console. Dans ce cas, les options precheck, check, checkargs et tries peuvent être utiles.

   Le quatrième champ, options, décris les options cryptsetup associées avec le processus de chiffrement. Au minimum, le champ devrait contenir soit la chaîne luks respectivement tcrypt ou les options cipher, hash, et size. Les options sont au format key=value. Noter que les 4 champs sont obligatoires.

OPTIONS

cipher=‹cipher› Algorithme de chiffrement (ignoré pour LUKS et TCRYPT).
size=‹size› Taille de la clé de chiffrement (ignoré pour LUKS et TCRYPT)
hash=‹hash› Algorithme de hashage (ignoré pour LUKS et TCRYPT)
offset=‹offset› Offset de début (ignoré pour LUKS et TCRYPT)
skip=‹skip› Secteur du début à sauter (ignoré pour LUKS et TCRYPT)
verify Vérifie le mot de passe
readonly Le périphérique est lecture seule
discard Permet l'utilisation des requêtes discards (TRIM) pour le périphérique. déconseillé pour des raisons de sécurité.
luks Utilise le périphérique avec les extensions LUKS
tcrypt Utilese le périphérique avec les extensions TCRYPT
veracrypt Utilise l'extension VeraCrypt de TCRYPT.
swap Lance mkswap sur le périphérique créé
tmp=‹tmpfs› Lance mkfs avec le type tmpfs spécifié dans le périphérique créé. Défaut: ext4
precheck=‹precheck› Vérifie le contenu du périphérique source par un programme. Si la vérification échoue, le périphérique n'est pas créé.. cryptdisks/cryptroot recherche un programme dans /lib/cryptsetup/checks par défaut. preckeck n'est pas invoqué par les périphériques LUKS
check=‹check› Vérifie le contenu du périphérique cible par un programme. Si la vérification échoue, le périphérique n'est pas créé.. cryptdisks/cryptroot recherche un programme dans /lib/cryptsetup/checks par défaut.
checkargs=‹arguments› Donne les arguments spécifiés au programme de vérification.
tries=‹num› L'entrée de la passphrase est tentée num fois en cas d'erreur. Défaut=3. 1 ne retente pas, et 0 demande la passphrase jusqu'à ce quelle soit correct.
initramfs Processus hook initramfs traitant le périphérique root, tout périphérique avec cette option sont traités dans initramfs.
noearly Les scripts init sont invoqués 2 fois durant le processus de boot. Une fois avant lvm et raid, et une fois après.
noauto Ignore entièremenet le périphérique au processus de boot.
loud mode verbeu. Affiche une alerte si un périphérique n'existe pas.
quiet mode silencieu.
keyscript=‹path› L'exécutable utilisé avec le fichier de clé et la sortie est utilisée comme clé.
keyslot=‹slot› Slot de la clé (LUKS uniquement)
header=‹path› fichier d'en-tête détaché (ignoré pour les périphériques dm-crypt plain)
tcrypthidden Utilise l'en-tête TCRYPT caché.

checkscripts

blkid Vérifie les systèmes de fichier inconnus. Supporte un type comme argument via checkargs: "" réussis si un fs valide est trouvé, "none" réussis si aucun fs valide n'est trouvé, "ext4" (xfs, swap, crypto_LUKS, etc) réussis si un fs ext4 est trouvé.
un_blkid Vérifie les système de fichier connus.

Exemples

Périphérique d'échange chiffré:
cswap /dev/sda6 /dev/urandom cipher=aes-xts-plain64,size=256,hash=sha1,swap
Disque LUKS chiffré avec mot de passe intéractif, identifié par son UUID:
cdisk0 UUID=12345678-9abc-def012345-6789abcdef01 none luks
disque TCRYPT chiffré avec mot de passe interactif:
tdisk0 /dev/sr0 none tcrypt
Disque ext4 chiffré avec mot de passe interactif, retente 5 fois:
cdisk1 /dev/sda2 none cipher=aes-xts-plain64,size=256,hash=sha1,checkargs=ext4,tries=5
Utiliser un script de vérification spécifié, sans retentative:
cdisk2 /dev/sdc1 none cipher=aes-xts-plain64,size=256,hash=sha1,check=customscript,tries=1
Utiliser Twofish et un hash RIPEMD-160:
cdisk3 /dev/sda3 none cipher=twofish,size=256,hash=ripemd160

Variables d'environnement

CRYPTDISKS_ENABLE à yes, lance les initscripts cryptdisks au démarrage.
CRYPTDISKS_MOUNT Spécifie les points de montage qui sont montés avant d'invoquer cryptdisks. Prend les points de montage configuré dans /etc/fstab comme arguments, séparés par un espace.
CRYPTDISKS_CHECK Spécifie le checkscript par défaut à lancer avec le périphérique cible après avoir invoqué cryptdisks
CRYPTDISKS_PRECHECK Spécifie le checkscript par défaut à lancer avec le périphérique dm-crypt, avant d'invoquer cryptdisks
^
07 juin 2010

htmlpdflatexmanmd




csplit

csplit

Crée des fichiers de sortie contenant des sections de l'entrée

   Le contenu de chaque fichier de sortie est déterminé par les arguments PATTERN. Une erreur se produit si le PATTERN réfère à une ligne non existante dans le fichier d'entrée. Par défaut, csplit affiche le nombre d'octets écrit dans chaque fichier de sortie une fois qu'il l'a crée.

N Crée un fichier de sortie jusqu'à, mais ne l'incluant pas, la ligne N.
/REGEXP/[OFFSET] Créer un fichier de sortie contenant la ligne courante jusqu'à, mais n'inclant pas, la prochaine ligne contenant une correspondance de REGEXP. OFFSET est un entier, contient jusqu'à, mais n'inclus pas, la ligne correspondante moins l'OFFSET
%REGEXP%[OFFSET] Idem excepté qu'il ne crée pas de fichier de sortie, donc la section du fichier d'entrée est ignorée.
REPEAT-COUNT Répète le pattern précédent REPEAT-COUNT fois supplémentaire. Peut être un entier ou un '*'.

OPTIONS

-f PREFIX, --prefix=PREFIX Utilise PREFIX comme préfixe dans le nom de fichier
-b SUFFIX, --suffix=SUFFIX Utilise SUFFIX comme suffixe dans le nom de fichier.
-N DIGITS, --digits=DIGITS Utilise des noms de fichier contenant des nombres de DIGITS chiffres. (2 par défaut)
-k, --keep-files Ne supprime pas les fichiers de sortie quand des erreurs sont rencontrées.
-z --elide-empty-files Supprime la génération de fichier de sortie vide.
-s, -q, --silent, --quiet N'affiche pas de compteur de taille de fichiers

Exemples

Split la séquence 1..14 sur les lignes qui se terminent avec 0 ou 5
seq 14 | cpslit - '/[05]$/' '*'
^
07 mai 2016

htmlpdflatexmanmd




ctrlaltdel

ctrlaltdel

Définis la fonction de la combinaison ctrl-alt-del

   Dans le kernel linux (linux/kernel/sys.c), il y a 2 fonctions supportées pour la séquence ctrl-alt-del: un reset hard, qui reboot immédiatement la machine sans appeler sync(2) et sans autre préparation; et un reset soft, qui envoie un SIGINT au processus init. Si cette option est utilisée, init doit supporter cette fonctionnalité.

^
19 septembre 2016

htmlpdflatexmanmd




cups

cups

Système d'impression open-source

   CUPS est un logiciel pour imprimer depuis des applications. Il convertis les descriptions de page produites par les application en quelque chose qu'une imprimante peut comprendre.

Variables d'environnement

   Les commandes cups utilisent les variables d'environnement suivantes:

CUPS_ANYROOT Autorise ou non tous certificats X.509 (Y ou N)
CUPS_CACHEDIR Répertoire pour les fichiers en cache semi-persistant
CUPS_DATADIR répertoire où trouver les fichiers de données
CUPS_ENCRYPTION Niveau de chiffrement par défaut (Always, IfRequested, Never, Required)
CUPS_EXPIIREDCERTS Autoriser ou non les certificats expirés (Y ou N)
CUPS_GSSSERVICENAME Nom de service Kerberos pour l'authentification
CUPS_SERVER Hostname/IP et port du scheduler CUPS
CUPS_SERVERBIN Répertoire pour les programmes helper, filtres, backend
CUPS_SERVERROOT Répertoire racine du serveur
CUPS_STATEDIR Répertoire où trouver les fichiers statistiques
CUPS_USER Nom de l'utilisateur pour les requêtes d'impression
HOME Répertoire personnel de l'utilisateur
IPP_PORT Port par défaut pour les requêtes IPP
LOCALEDIR Emplacement des fichiers de localisation
LPDEST File d'impression par défaut (standard SystemV)
PRINTER File d'impression par défaut (standard Berkeley)
TMPDIR Spécifie un répertoire pour les fichiers temporaires

Fichiers

~/.cups/client.conf
~/.cups/lpoptions
^
14 septembre 2016

htmlpdflatexmanmd




cups-client.conf

cups-client.conf

Fichier de configuration client pour cups

   Le fichier client.conf configure le client CUPS et est normalement localisé dans /etc/cups et/ou ~/.cups.

Directives

AllowAnyRoot Yes|No Spécifie si TLS avec certificat non signés par un autorité de confiance est permis.
AllowExpiredCerts Yes|No Spécifie si TLS avec certificat expiré est permis.
Encryption IfRequested|Never|Required Spécifie le niveau de chiffrement à utiliser
GSSServiceName name Spécifie le nom de service kerberos utilisé pour l'authentification, généralement host, hppt, ou ipp.
ServerName /domain/socket
ServerName hostname-or-ip-address[:port]
ServerName hostname-or-ip-address[:port]/version=1.1 Spécifie l'adresse et optionnellement le port à utiliser pour se connecter au serveur
SSLOptions None|[AllowDH] [AllowRC4] [AllowSSL3] [DenyTLS1.0] Définis les options de chiffrement (uniquement dans /etc/cups/client.conf)
TrustOnFirstUse Yes|No Faire confiance aux nouveaux certificats TLS ou non
User name Username à utiliser pour les requêtes
ValidateCerts Yes|No Accepte ou non les certificats dont le nom commun correspond au nom d'hôte.
^
19 septembre 2016

htmlpdflatexmanmd




cups-config

cups-config

Obtenir des informations sur cups

   cups-config permet aux dévelloppeurs d'application de déterminer les options de ligne de commande nécessaire pour le compiler et le linker, ainsi que les répertoires d'installation pour les filtres, fichiers de configuration, et pilotes.

OPTIONS

--api-version Reporte la version API courante
--build Reporte le numéro de build spécifique au système
--cflags Reporte les options de compilation nécessaires
--datadir Reporte le répertoire de données CUPS par défaut
--image Avec --libs, ajoute la librairie d'imagerie CUPS à la liste des librairies
--ldflags Reporte les options de linker nécessaires
--libs Reporte les librairies nécessaires
--serverbin Reporte le répertoire de binaire cups par défaut, où les filtres et backends sont stockés
--serverroot Reporte le répertoire de configuration par défaut de cups
--static Avec --libs, reportes les librairies statiques au lieu les librairies partagées
--version Reporte le numéro de version complet de l'installation CUPS

Exemples

Afficher le version courante de cups
cups-config --version
Compiler un filtre cups simple
cc `cups-config --cflags --ldflags` -o filter filter.c `cups-config --libs`
^
14 septembre 2016

htmlpdflatexmanmd




cups-files.conf

cups-files.conf

Fichier de configuration des fichiers et répertoires pour cups

   Le fichier cups-files.conf configure les fichiers et répertoires utilisés par le scheduler cupsd. Il est normalement dans /etc/cups

Directives

AccessLog filename|stderr|syslog Définis la destination des logs. défaut: /var/log/cups/access_log
ConfigFilePerm mode Spécifie les permissions pour tous les fichiers de configuration que le scheduler écris. Défaut: 0640.
DataDir path Répertoire où trouver les fichiers de données. Défaut: /usr/share/cups
DocumentRoot directory Spécifie le répertoire root pour l'interface web. Défaut: /usr/share/doc/cups
ErrorLog filename|stderr|syslog Destination des logs d'erreur. Défaut: /var/log/cups/error_log
FatalErrors none|all -kind [ ... -kind ]|kild [ ... -kind ] Spécifie quelles erreurs sont fatales, causant le scheduler à quitter. Défaut: config. peut être none, browse, config, listen, log, permissions ou all.
FileDevice Yes|No Spécifie si le fichier pseudo-device peut être utilisé pour de nouvelles files d'impression. l'URI file:///dev/null est toujours permis
Group group-name-or-number Spécifie le nom du groupe ou son ID qui est utilisé pour exécuter les programmes externes. Défaut est lp ou nobody
LogFilePerm mode Permission de tous les fichiers de log. Défaut: 0644
PageLog filename|stderr|syslog Définis la sortie des logs de page. Défaut: /var/log/cups/page_log
RemoteRoot username Spécifie le username associé avec les accès non-authentifiés par les client se proclamant root. Défaut: remroot
RequestRoot directory Spécifie le répertoire qui contient les jobs d'impression et autres données de requêtes HTTP. Défaut: /var/spool/cups
ServerBin directory Répertoire contenant les backends, programmes CGI, filtres, helpers, notifiers, et monitors. Défaut: /usr/lib/cups ou /usr/libexec/cups
ServerKeyChain path Emplacement des certificats TLS et clés privées. Défaut: /etc/cups/ssl
ServerRoot directory Spécifie le répertoire contenant les fichiers de configuration serveur. Défaut: /etc/cups
SyncOnClose Yes|No Spécifie si le scheduler appelle fsync(2) après avoir écris les fichiers d'état et de configuration. Défaut: No
SystemGroup group-name [ ... group-name ] Spécifie les groupes à utiliser pour @SYSTEM. Défaut contient "admin", "lpadmin", "root", "sys", et/ou "system"
TempDir directory Répertoire où les fichiers temporaires sont stockés. Défaut: /var/spool/cups/tmp
User username Utilisateur ou UID utilisé pour lancer les programmes externes. Défaut: lp
^
14 septembre 2016

htmlpdflatexmanmd




cups-lpd

cups-lpd

Recevoir des jobs et reporter le status d'imprimante aux clients lpd

   cups-lpd est le service CUPS Line Printer qui supporte les systèmes clients qui utilisent le protocole LDP. Il n'agit pas comme serveur autonome mais opère en utilisant inetd ou systemd.

OPTIONS

-h server[:port] Spécifier le serveur
 -n Désactiver la recherche inverse d'adresse.
-o name=value Insert des options pour toutes les files d'impression.
^
16 septembre 2016

htmlpdflatexmanmd




cups-snmp

cups-snmp

Backend snmp pour cups

   fournis la découverte et l'identification des imprimantes réseaux en utilisant snmpv1. Utilisé pour la découverte via le scheduler, le backend liste toutes les imprimantes qui répondent à un broadcast SNMPv1 avec la communauté public.

   Dans la première forme, le backend est lancé directement par l'utilisateur pour rechercher une URI et d'autres informations sur une IP ou hostname. Cela peut être utilisé pour les programmes qui doivent configurer les files d'impression quand l'utilisateur a fournis une adresse IP, mais rien d'autre.

   Dans la seconde forme, le backend est lancé indirectement en utilisant lpinfo. La sortie fournis toutes les imprimantes détectées via SNMP sur les adresses de broadcast configurés.

   Le backend SNMP lit /etc/cups/snmp.conf, si présent, pour définir l'adresse de broadcast par défaut, community name, et niveau de logging.

^
11 septembre 2016

htmlpdflatexmanmd




cups-snmp.conf

cups-snmp.conf

Fichier de configuration snmp pour cups

   le fichier snmp.conf configure comment les backends réseau standard CUPS (http, https, ipp, ipps, lpd, snmp, et socket) accèdent aux informations des imprimantes en utilisant SNMPv1 et est normalement dans /etc/cups. Les directives Community et DebugLevel sont utilisés par tous les backends. Le reste s'applique seulement au backend SNMP

Directives

Address @IF(name)|@LOCAL|address Envoie les requêtes broadcast (pour la découverte) aux adresses spécifiées.
Community name Nom de communauté à utiliser. Défaut: public
DebugLevel number Niveau de log de 0 à 3. Défaut: 0
DeviceURI "regular expression" device-uri [... device-uri] Spécifie une ou plusieurs URI de périphériques qui devraient être utilisé pour un modèle donné. L'expression régulière est utilisée pour correspondre au model et make détecté, et l'URI doit être sous la forme "scheme://%s[:port]/[path]", où %s représente l'adresse ou le nom d'hôte détecté.
HostNameLookups on|off Spécifie si les adresses des imprimantes devraient être converties en nom d'hôte ou non.
MaxRunTime seconds Spécifie le nombre maximum de secondes que le backend SNMP scan le réseau pour les imprimantes. Défaut: 120 secondes
^
05 septembre 2016

htmlpdflatexmanmd




cupsaccept

cupsaccept, cupsreject, accept, reject

Accepter/rejeter les jobs envoyés à une destination

   cupsaccept autorise les jobs d'impression vers les destinations. cupsreject les refuse.

OPTIONS

 -E Chiffrer la connexion au serveur
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur
-r "reason" Définir une raison pour le rejet du job.
^
05 septembre 2016

htmlpdflatexmanmd




cupsaddsmb

cupsaddsmb

Exporte les imprimante vers samba pour les clients Windows

   Exporte les imprimantes vers samba. En fonction de la configuration de samba, un mot de passe peut être nécessaire. Ce programme nécessite les pilotes d'impression Windows.

Configuration Samba

cupsaddsmb utilise le support d'impression basé sur RPC dans samba pour fournir les pilotes d'impression et les fichiers PPD aux clients Windows. Pour utiliser cette fonctionnalité, samba doit être configuré pour le supporte de l'impression via CUPS et fournir un partage pour le téléchargement des pilotes:
[global]
load printers = yes
printing = cups
printcap name = cups
    
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
public = yes
guest ok = yes
writable = no
printable = yes
    
[print$]
comment = Printer Drivers
path = /etc/samba/drivers
browseable = yes
guest ok = no
read only = yes
write list = root

Le pilote de base pour Windows 2000 et supérieur et le pilote Microsoft PostScript, qui est disponible dans tous les systèmes Windows dans %WINDIR%\SYSTEM32\SPOOL\DRIVERS\W32X86\3 et %WINDIR%\SYSTEM32\SPOOL\DRIVERS\X64\3. Copier les pilotes 32bits dans /usr/share/cups/drivers/ et les pilotes 64bits dans /usr/share/cups/drivers/x64/:
ps5ui.dll
pscript.hlp
pscript.ntf
pscript5.dll

   Note: La casse est importante

OPTIONS

-H samba-server Spécifie le serveur samba par défaut
-U samba-user[%samba-password] admin/password d'impression samba
-a Exporte toutes les imprimantes connues
-h cups-server[:port] Spécifie un serveur CUPS alternatif à utiliser
-v mode verbeux
^
05 septembre 2016

htmlpdflatexmanmd




cupsctl

cupsctl

Configurer les options cupsd.conf

   cupsctl met à jours ou requête le fichier cupsd.conf.

OPTIONS

 -E Chiffrer la connexion au serveur
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur
--[no-]debug-logging Active/désactive le logging de debuggage dans le fichier error_log
--[no-]remote-admin Active/désactive l'administration à distance
--[no-]remote-any Active/désactive l'impression depuis n'importe quelle adresse
--[no-]share-printers Active/désactive le partage des imprimantes locales avec d'autres machines
--[no-]user-cancel-any Autorise ou non les utilisateurs à annuler des jobs possédés par d'autres.

Exemples

Afficher les paramètres courants
cupsctl
activer le debug
cupsctl --debug-logging
désactiver le partage d'imprimantes
cupsctl --no-share-printers
^
05 septembre 2016

htmlpdflatexmanmd




cupsd

cupsd

Planification cups

   cupsd est le planificateur pour CUPS. Il implémente un système d'impression basé sur le protocole d'impression Internet, version 2.1. Par défaut il lit sa configuration dans /etc/cups/cupsd.conf

OPTIONS

-c Fichier de configuration (défaut: /etc/cups/cupsd.conf)
-F Ne lance pas en tâche de fond
-F ne lance pas en tâche de fond et détache le processus du terminal
-l Passé à cupsd quand il est lancé par systemd
-t Test la validité du fichier de configuration.
^
19 septembre 2016

htmlpdflatexmanmd




cupsd-helper

cupsd-helper, cups-deviced, cups-driverd, cups-exec

helper pour cupsd

   cupsd-helper effectue des opération à la demande du scheduler, cupsd.

   cups-deviced lance chaque backend CUPS sans argument pour découvrir les imprimantes disponibles.

   cups-exec lance les backends, filtres, et autres programmes.

Fichiers

cups-driverd recherche les fichiers PPS et de pilotes dans les répertoires suivants:
/Library/Printers
/opt/share/ppd
/System/Library/Printers
/usr/local/share/ppd
/usr/share/cups/drv
/usr/share/cups/model
/usr/share/ppd
^
16 septembre 2016

htmlpdflatexmanmd




cupsd-logs

cupsd-logs

Fichiers de log pour cupsd (acces_log, error_log, page_log)

cupsd maintient normalement 3 fichiers de log: access_log suit les requêtes envoyées au scheduler, error_log suit les progressions et erreurs, et page_log suit les pages imprimées. Les directives de configuration dans cupsd.conf et cups-files.conf contrôlent quelles informations sont loggées et où ils sont stockés

Format de access_log

access_log liste chaque ressource HTTP accedée par un navigateur web ou un client. Chaque ligne est en version étendue du format "Common Log Format" utilisé par de nombreux serveurs Web:
host group user date-time "method resource version" status bytes
    ipp-operation ipp-status

Par exemple:
10.0.1.2 - - [01/Dec/2005:21:50:28 +0000] "POST / HTTP/1.1" 200 317
    CUPS-Get-Printers successful-ok-ignored-or-substituted-attributes
localhost - - [01/Dec/2005:21:50:32 +0000] "GET /admin HTTP/1.1"
    200 0 - -
localhost - - [01/Dec/2005:21:50:32 +0000] "POST / HTTP/1.1"
    200 157 CUPS-Get-Printers
    successful-ok-ignored-or-substituted-attributes
localhost - - [01/Dec/2005:21:50:32 +0000] "POST / HTTP/1.1"
    200 1411 CUPS-Get-Devices -
localhost - - [01/Dec/2005:21:50:32 +0000] "GET /admin HTTP/1.1"
    200 6667 - -

Champs

host est normalement une adresse IP, sauf si HostNameLookups est activé.
group Contient toujours -
user Contient le username authentifié
date-time date de la demande au format "[DD/MON/YYYY:HH:MM:SS +ZZZZ]"
method Méthode HTTP utilisée
resource Nom du fichier de la ressource demandée
version Version de la spécification HTTP utilisée par le client
status Résultat HTTP de la requêtes

        200 Opération réussie
        201 Fichier créé/modifié avec succès
        304 Le fichier demandé n'a pas changé
        400 mauvaise requête HTTP
        401 non autorisé, un authentification est requise
        403 Accès refusé
        404 Fichier ou ressource inexistante
        405 Méthode d'accès non permise
        413 Requête trop grande
        426 Upgrade vers une connexion TLS
        500 Erreur serveur
        501 Chiffrement demandé, mais non disponible
        505 Numéro de version HTTP non supporté

bytes Contient le nombre d'octets dans le requête
ipp-operation Contient soit '-' pour les requêtes non-IPP, ou le nom de l'opération IPP
ipp-dstatus Contient soit '-' pour les requêtes non-IPP ou le code de status IPP

bytes contient le nombre d'octets dans la requête. Pour les requêtes POST ce champ contient le nombre d'octets de données non-IPP qui sont reçus du client
ipp-operation Contient soit '-' pour les requêtes non-IPP ou l'opération IPP
ipp-status contient soit '-' pour les requêtes non-IPP ou le code de status IPP

Format de error_log

Le fichier error_log liste les messages du scheduler - erreurs, alertes, etc. La directive LogLevel contrôle les messages loggés:
I [20/May/1999:19:18:28 +0000] [Job 1] Queued on 'DeskJet' by 'mike'.
D [20/May/1999:19:18:28 +0000] [Job 1] argv[0]="DeskJet"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[1]="1"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[2]="mike"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[3]="myjob"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[4]="1"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[5]="media=
na_letter_8.5x11in sides=one-sided"
D [20/May/1999:19:18:28 +0000] [Job 1] argv[6]="/var/spool/cups/
d000001-001"
I [20/May/1999:19:21:02 +0000] [Job 2] Queued on 'DeskJet' by 'mike'.
I [20/May/1999:19:22:24 +0000] [Job 2] Canceled by 'mike'.

Champs

level Contient le type de message:

        A alert
        C crit
        D debug
        d debug2
        E error
        I info
        N notice
        W warn
        X emerg

date-time contient la date et heure de l'impression de la page.
message contient un message textuel.

Format de page_log

Le fichier page_log liste chaque page ou groupe de pages envoyés à une imprimante. Par défaut, chaque ligne contient les informations suivantes (peut être changé avec la directive PageLogFormat):
printer user job-id date-time page-number num-copies job-billing
    job-originating-host-name job-name media sides
    
printer user job-id date-time total num-impressions job-billing
    job-originating-host-name job-name media sides

Exemple:
DeskJet root 1 [20/May/1999:19:21:05 +0000] 1 1 acme-123
    localhost myjob na_letter_8.5x11in one-sided
DeskJet root 1 [20/May/1999:19:21:05 +0000] 2 1 acme-123
    localhost myjob na_letter_8.5x11in one-sided
    
DeskJet root 1 [20/May/1999:19:21:06 +0000] total 2 acme-123
    localhost myjob na_letter_8.5x11in one-sided

printer Contient le nom de l'imprimante
user username (IPP requesting-user-name)
job-id Numéro de job de la page imprimée
date-time Date et heure du démarrage de l'impression
page-number et num-copies contiennent le numéro de page et le nombre de copies imprimées
Les lignes contenant le mot clé "total" ont un champs num-impressions à la place qui fournis le nombre total d'impressions qui ont été imprimés pour ce job.
job-billing Contient une copie des attributs job-billing ou job-account-id fournis avec les requêtes IPP Create-Job ou Print-Job, ou '-'
job-originating-host-name Contient le hostname ou l'adresse IP du client
job-name Contient une copie de l'attribut job-name fournis avec Create-job ou Print-Job ou '-'
media Contient une copie du media ou media-col/media-size fournis avec Create-Job ou Print-Job ou '-'
sides Contient une copie de l'attribut sides fournis par Create-Job ou Print-Job ou '-'
^
11 septembre 2016

htmlpdflatexmanmd




cupsd.conf

cupsd.conf

Fichier de configuration pour cups

Directives top-level

AccessLogLevel config|actions|all Spécifie le niveau de log pour le fichier AccessLog. Le niveau "config" logs quand des imprimantes et classes sont ajoutées, supprimées, ou modifiée et quand les fichiers de configuration sont accédés ou mis à jours. 'actions' log les opérations sur les jobs d'impression.
AutoPurgeJobs Yes|No Spécifie si l'historique des jobs sont automatiquement purgés quand ils ne sont plus requis pour les quotas.
BrowseLocalProtocols all|dnssd|none Spécifie quels protocoles utiliser pour le partage d'impression. défaut: dnssd pour les systèmes supportant Bonjour.
BrowseWebIF Yes|No Spécifie si l'interface web CUPS est annoncée
Browsing Yes|No Spécifie si les imprimantes partagées sont annoncées.
Classification banner Spécifie la classification de sécurité du serveur. Toute bannière valide peut être utilisée, incluant "classified", "confidential", "secret", "topsecret", et "unclassified", ou omis pour désactiver l'impression sécuris
ClassifyOverride Yes|No Spécifie si les utilisateurs remplacent la classification (page de couverture) des jobs d'impression individuels en utilisant l'option job-sheets.
DefaultAuthType Basic|Negotiate Spécifie le type d'authentification à utiliser.
DefaultEncryption Never|IfRequested|Required Spécifie si le chiffrement est utilisé pour les demandes d'authentification.
DefaultLanguage locale Spécifie la langue par défaut à utiliser pour les textes et contenu web.
DefaultPaperSize Auto|None|sizename Spécifie la taille de papier par défaut pour les nouvelles files d'impression. Auto utilise le défaut local.
DefaultShared Yes|No Spécifie si les imprimantes locales sont partagées par défaut
DirtyCleanInterval seconds Délai de mise à jours des fichiers de configuration et d'état. 0 met à jours le plus vite possible. Défaut: 30
ErrorPolicy abort-job|retry-job|retry-this-job|stop-printer Spécifique si une tâche d'impression qui a échouée doit être annulé, retenté ultérieurement, retenté immédiatement, ou stoppe l'imprimante
FilterLimit limit Spécifie le coût maximum des filtres qui sont lancés en concurrence, qui peuvent être utilisés pour minimiser les problèmes de ressource disque, mémoire, et CPU. 0 désactive le filtre. Une impression vers une imprimante non-PostScript doit être à 200, et 100 pour une imprimante PostScript.
FilterNice nice-value valeur nice des filtres lancés pour imprimer un job. de 0 (haute priorité) à 19 (basse priorité)
GSSServiceName name Nom du service en utilisant l'authentification Kerberos. (défaut: http)
HostNameLookups On|Off|Double Spécifie la recherche inversé sur les clients.
IdleExitTimeout seconds Délai d'inactivité avant extinction. Défaut: 60. Uniquement quand cupsd est lancé à la demande.
JobKillDelay seconds Nombre de secondes d'attente avant de terminer les filtres et backends associés avec un job annulé ou en pause. Défaut: 30
JobRetryInterval seconds Spécifie l'interval entre les tentative des jobs. Généralement utilisé pour les files de fax, mais peut également être utilisé quand la stratégie est retry-job, retry-current-job. Défaut: 30
JobRetryLimit count Nombre de tentatives pour les jobs. Défaut: 5
KeepAlive Yes|No Spécifie le support de HTTP keep-alive.
KeepAliveTimeout seconds Spécifie la durée d'inactivité des connexions client
‹Limit operation|method ...› ... ‹/Limit› Spécifie les opérations IPP qui sont limitées dans une section Policy
‹LimitExcept method ...› ... ‹/LimitExcept› Spécifie les méthodes HTTP qui sont limitées dans une sectio Location
LimitRequestBody size Taille maximum des fichiers d'impression, requêtes IPP, et données HTML. Défaut: 0, désactive la limite
Lister ipv4|[ipv6]|*:port|/path/to/domain/socket Spécifie les adresses et port d'écoute du service
ListenBackLog number Nombre de connexions en attente permises. N'affecte que les serveur surchargés qui ont atteints la limite MaxClients.
‹Location /path› ... ‹/Location› Spécifie un contrôle d'accès pour l'emplacement nommé.
LogDebugHistory number Nombre de messages de debug retenus pour le logging si une erreur se produit dans un job.
LogLevel none|emerg|alert|crit|error|warn|notice|info|debug|debug2 Niveau de log pour le fichier ErrorLog
LogTimeFormat standard|usecs Format de la date dans les fichiers de log.
MaxClients number Nombre max de clients simultanné. Défaut: 100
MaxClientsPerHost number Nombre max de clients simultanné pour une seule adresse.
MaxCopies number Nombre max de copies qu'un utilisateur peut imprimer pour chaque job.
MaxHoldTime seconds Temps max qu'un job peut rester dans l'état indéfinis avant qu'il soit annulé. 0 désactive l'annulation
MaxJobs number Nombre max de jobs simultanné permis. 0 désactive la limite
MaxJobsPerPrinter number Nombre max de jobs simultanné par imprimante. 0 == MaxJobs
MaxJobsPerUser number Nombre max de jobs permis par utilisateur. 0 == MaxJobs
MaxJobTime seconds Temps max qu'un job prend à imprimer avant d'être annulé. 0 désactive.
MaxLogSize size Taille maximum des fichiers de log avant rotation. 0 désactive la rotation. Défaut 1048576
MultipleOperationTimeout seconds Délai max permis entre les fichiers dans une tâche d'impression à fichier multiple. Défaut: 300
PageLogFormat format-string Spécifie le format des lignes PageLog.

        %% Insert le caractère %
        %{name} Insert la valeur de l'attribut IPP spécifié
        %C Insert le nombre de copie de la page courante
        %P Insert le numéro de la page courante
        %T Insert la date
        %j Insert le job ID
        %p Insert le nom de l'imprimante
        %u Insert le username

PassEnv variable [ ... variable ] Passe les valiables d'environnement spécifiés aux processus enfant
‹Policy name› ... ‹/Policy› Spécifie un contrôle l'accès pour la stratégie nommée
Port number Port d'écoute
PreserveJobFiles Yes|no|seconds Spécifie si les fichiers sont préservés après impression, ou le délai avant suppression
PreserveJobHistory Yes|No|seconds Spécifie si l'historique d'un job est préservé apres impression.
ReloadTimeout seconds Délai d'attente pour la fin de job avant de redémarrer le scheduler. Défaut: 30
RIPCache size Quantité max de mémoire à utiliser en convertissant les documents en bitsmaps pour une imprimante. Défaut: 128m
ServerAdmin email-address email de l'administrateur du serveur.
ServerAlias hostname [ ... hostname ]|* Utilisé pour la validation d'en-tête HTTP Host quand les clients se connectent au scheduler depuis une interface externe. '*' expose le système à des attaques.
ServerName hostname fqdn du serveur
ServerTokens None|ProductOnly|Major|Minor|Minimal|OS|Full Spécifie quelles informations sont incluses dans l'en-tête Server des réponses HTTP.
SetEnv variable value Définie une variable d'environnement à passer aux processus enfant
SSLListen ipv4|[ipv6]|*:port Adresse d'écoute pour les connexions chiffrées
SSLOptions [AllowRC4] [AllowSSL3]|None Définis les options de chiffrement. CUPS ne supporte que TLSv1.0 et supérieur
SSLPort Port d'écoute pour les connexions chiffrées
StrictConformance Yes|No Spécifie si le scheduler exige que les client adhèrent strictement aux spécifications IPP
Timeout seconds Timeout des requêtes HTTP. Défaut: 300
WebInterface yes|No Active l'interface Web

Méthodes HTTP

GET Utilisé par un client pour télécharger des icônes, et autres ressources d'imprimante et l'accès à l'interface web CUPS
HEAD Utilisé par un client pour obtenir le type, taille, et date de modification des ressources
OPTIONS Utilisé par un client pour établir une connexion sécurisée
POST Utilisé par un client pour envoyer des requêtes IPP et des formulaires HTML depuis l'interface web
PUT Utilisé par un client pour uploader les fichiers de configuration

Opérations IPP

CUPS-Accept-Jobs Permet à une imprimante d'accepter des nouvelles tâches d'impression
CUPS-Add-Modify-Class Ajouter ou modifier une classe d'imprimante
CUPS-Add-Modify-Printer Ajouter ou modifier une imprimante
CUPS-Authenticate-Job Enlever un job en attente d'authentification
CUPS-Delete-Class Supprimer une classe d'imprimante
CUPS-Delete-Printer Supprimer une imprimante
CUPS-Get-Classes Obtenir une liste des classe d'imprimantes
CUPS-Get-Default Obtenir l'imprimante ou la classe d'imprimante par défaut du serveur
CUPS-Get-Devices Obtenir une liste de périphériques disponibles
CUPS-Get-Document Obtenir une file de document pour un job
CUPS-Get-PPD Obtenir un fichier PPD
CUPS-Get-PPDs Obtenir la liste des fichiers PPD installés
CUPS-Get-Printers Obtenir une liste d'imprimantes
CUPS-Move-Job Déplacer un job
CUPS-Reject-Jobs Empêcher une imprimante d'accepter un nouveau job
CUPS-Set-Default Définir l'imprimante ou la classe d'imprimante par défaut du serveur
Cancel-Job Annuler un job
Cancel-Jobs Annuler un ou plusieurs jobs
Cancel-My-Jobs Annuler un ou plusieurs jobs créé par l'utilisateur
Cancel-Subscription Annuler un abonnement
Close-Job Ferme un job qui est en attente pour d'autres documents
Create-Job Créer un nouveau job sans documents
Create-Job-Subscriptions Créer un abonnement pour des événements de job
Create-Printer-Subscriptions Créer un abonnement pour des événements d'imprimante
Get-Job-Attributes Obtenir des informations sur un job
Get-Jobs Obtenir une liste de jobs
Get-Notifications Obtenir une liste de notification d'événements pour un abonnement
Get-Printer-Attributes Obtenir des informations sur une imprimante ou une classe d'imprimante
Get-Subscription-Attributes Obtenir des informations sur des abonnements
Get-Subscriptions Obtenir une liste d'abonnements
Hold-Job retenir un job
Hold-New-Jobs Retenir tous les nouveaux jobs
Pause-Printer Stopper le traitement des jobs par une imprimante ou une classe d'imprimante
Pause-Printer-After-Current-Job Stopper le traitement des jobs par une imprimante ou une classe d'imprimante une fois le job courant terminé
Print-Job Créer un nouveau job avec un seul document
Purge-Jobs Annuler un ou plusieurs jobs et supprimer l'historique des jobs
Release-Held-New-Jobs Permettre aux jobs retenus d'être imprimés
Release-Job Permet d'imprimer un job
Renew-Subscription Renouveler un abonnement
Restart-Job Ré-imprimer un job, si possible
Send-Document Ajouter un document à un job
Set-Job-Attributes Changer les informations de job
Set-Printer-Attributes Changer les informations d'imprimante ou de classe d'imprimante
Validate-Job Valider les options pour un nouveau job

Chemins

/ Le chemin pour toutes les opérations get (get-prinetrs, get-jobs, etc.)
/admin Le chemin pour toutes les opérations d'administration (add-printer, delete-printer, start-printer, etc.)
/admin/conf Le chemin pour l'accès aux fichiers de configuration CUPS (cupsd.conf, client.conf, etc.)
/admin/log Le chemin pour accéder aux fichiers de log de CUPS (access_log, error_log, page_log)
/classes Le chemin pour toutes les classes d'imprimante
/classes/name La ressource pour la classe d'imprimante nommée
/jobs Le chemin pour tous les jobs (hold-job, release-job, etc.)
/jobs/id Le chemin pour le job spécifié
/printers Le chemin pour toutes les imprimantes
/printers/name Le chemin pour l'imprimante nommée
/printers/name.png Le fichier icône pour l'imprimante
/printers/name.ppd Le fichier ppd pour l'imprimante

Directives valides dans les sections Limit et Location

Allow all|none|host.domain.com|*.domain.com|ipv4‹/netmask›|[ipv6]‹/mm›|@IF(name)|@LOCAL Autorise l'accès depuis les hôtes, domaine, adresses, ou interfaces.
AuthType None|Basic|Default|Negotiate Spécifie le type d'authentification requis.
Deny all|none|host.domain.com|*.domain.com|ipv4‹/netmask›|[ipv6]‹/mm›|@IF(name)|@LOCAL Refuse l'accès
Encryption IfRequested|Never|Required spécifie le niveau de chiffrement requis pour un emplacement particulier
Order allow,deny|deny,allow Spécifie l'ordre de parsing des lignes Allow et Deny
Require group group-name [ group-name ... ]
Require user {username|@group-name} ... Spécifie qu'un utilisateur authentifié doit correspondre aux utilisateurs nommés ou membre d'un des groupes nommés. le groupe @SYSTEM correspond à la liste des groupes définis par la directive SystemGroup dans cups-files.conf. @OWNER correspond au propriétaire de la ressource
Require valid-user Spécifique que tout utilisateur authentifié est acceptable
Satisfy all|any Spécifie qu'un client peut acceder à une ressource si l'authentification (AuthType/Require) et/ou les conditions d'adresse (Allow/Deny/Order) sont satisfaits.

Directives valides dans les sections policy

JobPrivateAccess all|default
JobPrivateAccess {user|@group|@ACL|@OWNER|@SYSTEM} ... Spécifie une liste d'accès pour les valeurs privées d'un job. default liste vaut "@OWNER @SYSTEM", @ACL map les valeurs requesting-user-name-allowed ou requesting-user-name-denied de l'imprimante.
JobPrivateValues all|default|none|attribute-name[ ... attribute-name ] Spécifie la liste des valeurs de job à rendre privée. default vaut job-name, job-originating-host-name, job-originating-user-name, et phone.
SubscriptionPrivateAccess all|default
SubscriptionPrivateAccess {user|@group|@ACL|@OWNER|@SYSTEM} ... Spécifie une liste d'accès pour les valeurs privées d'un abonnement. default vaut "@OWNER @SYSTEM".
SubscriptionPrivateValues all|default|none|attribute-name [ ... attribute-name ] Spcéifie la liste des valeurs d'abonnement à rendre privée. default vaut notify-events, notify-pull-method, notify-recipient-uri, notify-subscriber-user-name, et notify-user-data
^
16 septembre 2016

htmlpdflatexmanmd




cupsenable

cupsenable, cupsdisable

Démarrer/arrêter les imprimantes et les classes

OPTIONS

 -E Chiffrer la connexion au serveur
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur
-r "reason" Définir une raison pour l'arrêt
-c Annule tous les jobs sur la destination
--hold Conserve les jobs dans l'imprimante. Utile pour permettre au job courant de se terminer avant d'effectuer une maintenace.
--release relance les jobs en attente. Utilisé après cupsdisable --hold.
^
16 septembre 2016

htmlpdflatexmanmd




cupsfilter

cupsfilter

Convertir un fichier en un autre format en utilisant les filtres cups

cupsfilter est un frontend au sous-système de filtre cups qui permet de convertir un fichier dans un format spécifique, tout comme imprimer le fichier via CUPS. Par défaut, cupsfilter génère un fichier pdf. le fichier convertis est envoyé sur la sortie standard.

OPTIONS

--list-filters Affiche les filtres utilisés sur stdout
-D Supprime le fichier d'entrée après la conversion
-U user Spécifie le username passé au filtre
-c config-file Utilise le fichier de configuration cups-files.conf spécifié
-d printer Utilise l'imprimante nommé
 -e Utilise tout filtre depuis le fichier PPD
-i mime/type Spécifie le type de fichier de destination. Le type par défaut est application/pdf.
copies Nombre de copies à passer aux filtres CUPS
-p filename.ppd Spécifie le fichier ppd à utiliser
-t title Spécifie le titre du document
-u Supprime le fichier PPD après conversion

Fichiers

/etc/cups/cups-files.conf
/etc/cups/ .convs
/etc/cups/ .types
/usr/share/cups/mime/ .convs
/usr/share/cups/mime/ .types
^
19 septembre 2016

htmlpdflatexmanmd




cupstestppd

cupstestppd

Test de conformité des fichiers ppd

   cupstestppd teste la conformité des fichiers ppd avec la spécification PostScript Printer Description version 4.3. Il peut également être utilisé pour lister les options supportées et les polices de caractères disponibles dans un fichier PPD. La première forme de cupstestppd teste un ou plusieurs fichiers ppd. La seconde forme teste le fichier ppd fournis sur l'entrée standard.

OPTIONS

-I filename Ignore toutes les alertes PCFileName
-I filters Ignore toutes les erreurs de filtre
-I profiles Ignore toutes les erreurs de profile
-R rootdir Répertoire root alternatif pour le fichiers de filtre, pre-filtre et autre fichier de vérification
-W constraints Reporte toutes les erreurs et alertes UIConstraint
-W defaults Excepté pour les options liées à la taille, reporte toutes les erreurs et alertes d'option par défaut
-W filters Reporte toutes les erreurs et alertes de filtre
-W profiles Reporte toutes les erreurs et alertes de profile
-W sizes Reporte toutes les erreurs et alertes de taille
-W translations Reporte toutes les erreurs et alertes de traduction
-W all Reporte toutes les erreurs comme alertes
-W none Reporte toutes les erreurs comme erreurs
-q N'affiche rien
-r Relâche les exigences de conformité PPD pour que les espaces blanc, caractères de contrôle, et problèmes de formatage ne soient pas traité comme erreurs
-v[v] Augmente le niveau de détails affichés

Codes de sortie

1 Erreur d'argument sur la ligne de commande ou fichie ppd manquant
2 Impossible d'ouvrir ou lire le PPD
3 Le fichier PPD contient des erreurs de format qui ne peuvent pas être ignorés
4 Le fichier PPD n'est pas conforme avec la spécification PPD

Exemples

Tester tous les fichiers PPD sous le répertoire courant et affiche les noms de chaque fichier non conforme
find . -name \*.ppd \! -exec cupstestppd -q '{}' \; -print
Tester tous les fichiers PPD sous le répertoire courant et affiche les résultat détaillés pour les fichiers non conformes
find . -name \*.ppd \! -exec cupstestppd -q '{}' \; -exec cupstestppd -v '{}' \;
^
08 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/customizable_types

/etc/selinux/‹SELINUXTYPE›/contexts/customizable_types

Fichier de configuration des types personnalisables SELinux

   Ce fichier contient une liste de types qui peuvent être personnalisés dans certaines applications. Généralement, c'est un type de contexte de fichier qui est définis sur les fichiers qui doivent être partagés dans certains domaines et où les administrateurs souhaitent gérer manuellement le type.

   L'utilisation de types personnalisables est déprécié en faveur de semanage, fcontext, etc. Cependant les application compatibles SELinux comme setfiles utilisent ces informations pour obtenir une liste de types en relation avec des fichiers qui ne devraient pas être relabélisés. Chaque ligne dans le fichier consiste d'un type qui peut être personnalisé

Exemple:
mount_loopback_t
public_content_rw_t
public_content_t
swapfile_t
sysadm_untrusted_content_t

^
09 juin 2010

htmlpdflatexmanmd




cut

cut

Écrit sur la sortie standard des parties sélectionnées de chaque ligne de chaque fichier en entrée, ou de l'entrée standard

   BYTE-LIST, CHARACTER-LIST et FIELD-LIST sont un ou plusieurs nombres ou plages.

OPTIONS

-b BYTE-LIST, --bytes=BYTE-LIST affiche seulement les positions d'octets listés. les espaces et tabulations sont considérés comme un octet.
-c CHARACTER-LIST, --characters=CHARACTER-LIST affiche seulement les positions de caractères listés. identique à -b pour le moment.
-f FIELD-LIST, --fields=FIELD-LIST Affiche seulement les champs listés. Les champs sont séparés par des tabulations par défaut.
-d INPUT_DELIM_BYTE, --delimiter=INPUT_DELIM_BYTE avec -f, utilise le premier octet de INPUT_DELIM_BYTE comme séparateur de champs.
-n  Ne coupe pas les caractères multi-octets
-s, --only-delimited Pour -f, n'affiche pas les lignes qui ne contienne pas le caractère séparateur de champs.
--output-delimiter=OUTPUT_DELIM_STRING Avec -f, sort les champs qui sont séparés par OUTPUT_DELIM_STRING.
--complement Sélectionne l'affichage complémentaire des octets, caractères ou champs sélectionnés. en d'autres terme, n'affiche pas les octets, caractères ou champs spécifiés avec les options -b, -c ou -f
^
19 octobre 2013

htmlpdflatexmanmd




Cyrus SASL

Cyrus SASL

Serveur SASL de Cyrus

Composants SASL

   Le premier composant de la librairie SASL est la couche Glue. Il s'occupe des tâches de base:

- Charger les plugins
- Gère les propriétés de sécurité nécessaires de l'application pour l'aider dans le choix du mécanisme ou pour limiter les mécanismes disponibles.
- Lister les plugins disponibles au applications
- Choisir le meilleur mécanisme dans une liste pour une authentification particulière
- Router les paquets de données d'authentification entre l'application et le mécanisme choisi
- Fournir des informations sur la négociation SASL aux applications

   Il fournis également d'autres services aux plugins et applications tels que l'encodage MIME base 64, génération de nombres aléatoires, etc. Il permet également aux mécanismes et aux applications d'accéder à types spéciaux de plugin. Auxiliary Property "auxprop" qui fournis une interface de base simple et peut retourner des propriétés sur l'utilisateur tel que le mot de passe, répertoire personnel, ou adresse mail. et Username Canonicalization, qui peut fournir des manières de canoniser un nom d'utilisateur ou effectuer d'autres tâches.

Mécanisme PLAIN et mots de passe en texte clair

auxprop Vérifie les mots de passe dans userPassword fournis par une plugin de propriété auxiliaire. Par exemple, SASL est fournis avec sasldb, qui peut être utilisé pour authentifier avec des mots de passe stockés dans /etc/sasldb2.
saslauthd Permet de vérifier des mots de passe en utilisant divers mécanismes.
courrier-IMAP authdaemond Utilisé pour contacter authdaemond pour vérifier les mots de passe.

Mécanismes à secret partagé

   Cyrus SALS fournis plusieurs méthodes d'authentification basé sur un secret partagé: CRAM-MD5 et son successeur DIGEST-MD5.

Mécanismes Kerberos

   Cyrus SASL fournis 2 mécanismes qui utilisent kerberos: Kerberos_v4 et GSSAPI qui permet d'utiliser kerberos v5.

Mécanismes OTP

   Cyrus SASL support le mécanisme OTP, similaire à CRAM-MD5 et DIGEST-MD5. Ces OTP sont stockés dans /etc/sasldb2. SASL support également OPIE.

Auxiliary Properties

   SASLv2 introduit le concept de propriétés auxiliaires. C'est la capacité de rechercher des informations liées à l'authentification ou l'authorisation depuis un répertoire durant le processus d'authentification.

Fichier de configuration par défaut

   Par défaut, Cyrus SASL lit ses options depuis /usr/lib/sasl2/App.conf (où App est le nom de l'application). Les applications peuvent redéfinir comment la librairie recherche les informations de configuration.

OPTIONS

authdaemond_path (SASL library) Chemin du socket UNIX de authdaemond (défaut: /dev/null)
auto_transition (SASL library) à yes ou noplain et utilisé avec auxprop. Transferts automatiquement les users à d'autres mécanismes quand ils font une authentification plaintext réussie. à noplain, seul les secrets non plaintext sont écris. (défaut: no)
auxprop_plugin (AuxProp Plugin) Nom(s) de(s) plugin(s) auxiliaire à utiliser. (défaut: null)
canon_user_plugin (SASL library) Nom du plugin canon_user à utiliser (défaut: INTERNAL)
keytab (GSSAPI) Emplacement du fichier keytab (défaut: /etc/krb5.keytab)
ldapdb_uri (LDAPDB plugin) liste d'URI ldap
ldapdb_id (LDAPDB plugin) id d'authentification ldap
ldapdb_mech (LDAPDB plugin) mécanisme pour l'authentification
ldapdb_pw (LDAPDB plugin) password
ldapdb_rc (LDAPDB plugin) Fichier à placer dans l'environnement LDAPRC
ldapdb_starttls (LDAPDB plugin) utiliser StartTls (try, demand).
ldapdb_canon_attr (LDAPDB plugin) attribut contenant le nom canonique de l'utilisateur
log_level (SASL library) Niveau de debug (défaut: 1 (SASL_LOG_ERR))
mech_list (SASL library) liste de mécanisme à autoriser (défaut: tous)
ntlm_server (SASL library) Liste des serveurs
ntlm_v2 (SASL library) Envoyer des réponses ntlmv2 au serveur opiekeys (OPIE) Emplacement du fichier opiekeys (défaut: /etc/opiekeys)
otp_mda (OPIE) Algorithme pour l'OTP (md4, md5, sha1) (défaut: md5)
plugin_list (SASL library) Emplacement de la liste des plugins
pwcheck_method (SASL library) liste des mécanismes utilisés pour vérifier les mots de passe, utilisé par sasl_checkpass (auxprop, saslauthd, pwcheck, authdaemond, alwaystrue). (défaut: auxprop)
reauth_timeout (DIGST-MD5) Temps en minutes de cache de l'authentification pour une réauthentification rapide. défaut: 0
saslauthd_path (SASL library) Chemin vers le répertoire saslauthd, incluant le pipe /mux
sasldb_path (sasldb plugin) Chemin du fichier sasldb (défaut: /etc/sasldb2)
sql_engine (SQL plugin) Nom du moteur SQL à utiliser (mysql, pgsql, sqlite, sqlite3). défaut: mysql
sql_hostnames (SQL plugin) liste de serveurs:ports SQL
sql_user (SQL plugin) Utilisateur SQL pour l'authentification
sql_passwd (SQL plugin) Mode de passe pour l'authentification
sql_database (SQL plugin) Nom de la base de données qui contient les propriétés auxiliaires
sql_select (SQL plugin) Déclaration SELECT à utiliser pour récupérer les propriétés
sql_insert (SQL plugin) Déclaration INSERT pour créer des propriétés
sql_update (SQL plugin) Déclaration UPDATE pour mettre à jours des propriétés
sql_usessl (SQL plugin) à yes, créé une connexion sécurisée
srp_mda (SRP) Algorithme à utiliser pour les calculs SRP (md5, sha1, rmd160).
srvtab (kerberos 4) Emplacement du fichier srvtab (défaut: /etc/srvtab)

Notes sur les options auxprop sql

%U username
%p Nom de la propriété à modifier/ajouter
%r Royaume auquel l'utilisateur appartient
%v Valeur de la propriété

Exemples

sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
Va envoyer la requête suivante pour l'utilisateur bovik et le royaume madoka.surf.org.uk:
SELECT userPassword FROM user_table WHERE username = 'bovik' and realm = 'madoka.surf.org.uk';
sql_insert: INSERT INTO user_table (username, realm, %p) VALUES ('%u', '%r', '%v')
Va générer les requêtes suivante pour l'utilisateur bovik dans le royaume madoka.surf.org.uk et le userPassword "wert":
INSERT INTO user_table (username, realm, userPassword) VALUES ('bovik', 'madoka.surf.org.uk', 'wert');

Notes sur les options LDAPDB

s'active en créant /usr/lib/sasl2/slapd.conf avec:
auxprop_plugin: slapd

Exemples

ldapdb_uri: ldap://ldap.example.com
ldapdb_id: root
ldapdb_pw: secret
ldapdb_mech: DIGEST-MD5
ldapdb_canon_attr: uid
root authcid doit avoir des privilèges de proxy authorization pour tous les comptes authorisés à s'authentifier.
ldapdb_uri: ldapi://
ldapdb_mech: EXTERNAL
Cette configuration assume que le serveur LDAP est sur le même serveurs qui utilise SASL. C'est plus rapide et sécure et n'a pas besoin de stocker de user/password. slapd.conf doit mapper ces usernames en DN ldap:
sasl-regexp uidNumber=(.*)\\+gidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(&(uidNumber=$1)(gidNumber=$2))
sasl-regexp uid=(.*),cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(uid=$1)
^
14 juillet 2010

htmlpdflatexmanmd




date

date

Affiche ou définit la date du système

   date affiche ou définit la date du système, invoqué sans format de date revient à l'invoquer avec un format par défaut que dépend de LC_TIME Normalement, date utilise les règles de temps indiqué par TZ, ou les règles par défaut du système si TZ n'est pas utilisé. Si un argument commence par +, date affiche la date courante ( ou la date spécifié par l'option --date) dans le format spécifié par l'argument, qui est similaire à la fonction strftime. Excepté pour les spécifieurs de conversion qui commence avec %, les caractères sont affichés tels quels.

Spécifieurs de conversion de temps

%H heure ('00'...'23')
%I heure ('01'...'12')
%k heure ('0'...'23')
%l heure ('1'...'12')
%M minute ('00'...'59')
%N nanosecondes (`000000000'...`999999999')
%p équivalent local à AM ou PM. vide dans beaucoup de locales
%P Idem mais en minuscule
%r heure locale sur 12 heures
%R identique à %H:%M
%s seconde depuis le 1.1.1970
%S Secondes (`00'...`60')
%T identique à %H:%M:%S
%X représentation de l'heure locale.
%z time RFC 2822. Zone en style numérique. ex: +0200. ou rien si le time zone ne peut pas être déterminé.
%:z RFC 3339. Zone en style numérique. ex: +02:00. ou rien si le time zone ne peut pas être déterminé.
%::z time zone à la plus proche seconde. ex: +02:00:00, ou rien si le time zone ne peut pas être déterminé.
%:::z time zone utilisant le précision minimal nécessaire, ou rien si le time zone ne peut pas être déterminé.
%Z abbréviation du time zone, ou rien si le time zone ne peut pas être déterminé.

Spécifieurs de conversion de date

%a Abréviation du nom du jour de la semaine
%A Nom du jour de la semaine
%b Abréviation du nom du mois
%B Nom du mois
%c Date et heure locale
%C siècle. Identique à %Y mais sans les 2 dernier chiffres.
%d Jour du mois
%D identique à %m/%d/%y
%e jour du mois, identique à %_d
%F Date au format iso 8601. identique à %Y-%m-%d
%g Année, sans le siècle.
%G Année, identique à %Y
%h identique à %b
%j jour de l'année
%m mois
%u jour de la semaine ('1'...'7') 1 correspond à lundi
%U semaine de l'année
%V semaine ISO de l'année. Si la semaine du 1er Janvier à au moins 4 jours dans la nouvelle année, c'est la semaine 1 de la nouvelle année, sinon la 53eme semaine de l'année précédente.
%w jour de la semaine ('0'...'6') 0 correspond à dimanche
%W semaine de l'année avec lundi comme premier jour de la semaine
%x date locale, identique à %d/%m/%Y
%y 2 derniers chiffres de l'année.
%Y année

Spécifieurs de conversion litéral

%% un %
%n newline
%t tabulation horizontale

Padding et autres flags

   date remplis normalement les champs par des 0

- Ne remplis pas les champs par des 0.
_ Remplis avec des espaces
0 remplis avec des 0
^ met les caractères en majuscule si possible
# oppose la casse si possible.
0 Ce chiffre permet de spécifier la largeur du champs

Régler l'heure du système

   Si un argument ne commence pas par +, date définis le temps du système. Les options --date et --set ne peuvent pas être utilisés avec cet argument. --universal peut être utilisé pour indiquer que l'heure est relative à UTC au lieu de du time zone local

MM mois
DD jour dans le mois
hh heure
mm minutes
CC 2 premiers chiffres de l'année
YY 2 derniers chiffres de l'année
ss secondes

OPTIONS

-d DATESTR, --date=DATESTR affiche la date et l'heure spécifié par DATESTR au lieu de l'heure courante. DATESTR peut être de plusieurs formes. Il contient le nom des mois, time zone, am et pm, yesterday etc...
-f DATEFILE, -file=DATEFILE utilise chaque ligne du fichier et affiche la date et l'heure comme pour -d. si DATE vaut '-', utilise l'entrée standard.
-r FILE, --reference=FILE affiche la date et l'heure du mtime du fichier spécifié.
-R, --rfc-822, --rfc-2822 Affiche la date et l'heure en utilisant le format %a, %d %b %Y %H:%M:%S%z
--rfc-3339=TIMESPEC Affiche la date en utilisant un format spécifié par la RFC 3339. Ce format est toujours utilisatable par -d et -f. TIMESPEC peut être:

        date Affiche juste la date complète, identique à %Y-%m-%d
        seconds affiche la date complète et l'heure complète séparé par un espace. Identique à %Y-%m-%d %H:%M:%S%:z
        ns idem, mais affiche les nanosecondes. identique à %Y-%m-%d %H:%M:%S.%N%:z

-s DATESTR, --date=DATESTR Définit la date et l'heure à DATESTR.
-u, --utc, --universal Utilise UTC

Exemples

affiche la date d'il y'a 2 jours:
date --date='2 days ago'
Affiche la date d'il y'a 3mois et 1 jour:
date --date='3 months 1 day'
Affiche le jour de noêl:
date --date='25 Dec' +%j
Affiche le nom du mois et le jour courant:
date '+%B %d'
afficher la date et l'heure sans remplir de 0:
date -d 1may '+%B %-d'
définis l'heure système en la reculant de 2 minutes:
date --set='+2 minutes'
Convertir une date en nombre de secondes depuis le 1/1/1970:
date --date='1970-01-01 00:02:00 +0000' +%s
^
30 juin 2010

htmlpdflatexmanmd




dd

dd

Copie de fichier et conversions

OPTIONS

if=FILE lit FILE au lieu de l'entrée standard
of=FILE Écrit dans FILE au lieu de la sortie standard. par défaut tronque aux octets '0'
ibs=BYTES Définis la taille de block en entrée (défaut 512 octets)
obs=BYTES Définis la taille de block en sortie (défaut 512 octets)
bs=BYTES Définit la taille de block en entrée et en sortie. ça force dd à lire et écrire par block.
cbs=BYTES définit la taille de block de conversion. En convertissant des enregistrements de longueur variable à des longueurs fixes (conv=block) ou inversé (conv=unblock), utilise BYTES comme longueur d'enregistrement.
skip=BLOCKS saute BLOCKS dans le fichier d'entée avant de copier
seek=BLOCKS saute BLOCKS dans le fichier de sortie avant de copier
count=BLOCKS copie BLOCKS dans le fichier d'entrée.
status=noxfer n'affiche pas le taux de transfert et les statistiques de volume quand dd se termine.
conv=CONVERSION[,CONVERSION]... Convertit le fichier comme spécifié par CONVERSION :

        ascii Convertit EBCDIC vers ASCII.
        ebcdic Convertit ASCII vers EBCDIC
        ibm Convertit ASCII vers EBCDIC alternatif
        block pour chaque ligne dans l'entrée, sort cbs octets, remplaçant un newline par un espace et en complétant avec des espaces si nécessaire.
        unblock remplace les espaces à la fin dans chaque block d'entrée de taille cbs par un newline.
        lcase Change les lettres majuscules en minuscules
        ucase Change les lettres minuscules en majuscules
        swab inverse chaque pair d'octets en entrée.
        noerror Continue même en cas d'erreurs
        nocreat ne crée pas de fichier de sorite, il doit déjà exister.
        excl échoue si le fichier de sorite existe déjà.
        notrunc Ne tronque pas le fichier de sortie
        sync complète chaque block d'entrée à la taille de ibs, en complétant avec des '0', ou des espace si block ou unblock est spécifié.
        fdatasync Synchronise les données en sortie juste avant de finir. Cela force une écrite physique.

iflag=FLAG[,FLAG]... Accède au fichier d'entrée en utilisant les flags spécifiés.
oflag=FLAG[,FLAG]... Accède au fichier de sortie en utilisant les flags spécifiés.

        append Écrit en mode ajout.
        cio Utilise le mode I/O courant pour les données. effectue effectue un I/O direct, outrepassant les requis POSIX.
        direct Utilise I/O direct pour les données, annulant le buffer cache.
        directory Échoue à moins que le fichier soit un répertoire. bcp d'OS ne permettent pas I/O sur un répertoire.
        dsync Utilise I/O synchronisé pour les données. Pour le ficheir de sortie, çà force l'écriture physique pour chaque écriture.
        sync Utilise I/O synchronisé pour les données et les métadonnées.
        nonblock Utilise I/O non-blocking
        noatime Ne met pas à jours le atime des fichiers.
        nofollow ne suit pas les liens symboliques
        nolinks échoue si le fichier à de multiples liens dures.
        binary Utilise I/O binaire, pour les plate-formes distinguant les fichier binaire des fichiers texte.
        text Utilise I/O text.
        fullblock accumule les blocks complet en entrée.

   BYTES et BLOCKS peuvent s'exprimer avec un multiplicateur : b vaut 512, c vaut 1, w vaut 2, ou n'importe quel autre multiplicateur.

  Envoyer un signal INFO (ou USR1 pour les système ne supportant pas INFO) à un processus dd en cour le force à afficher des statisques d'I/O sur l'erreur standard, puis reprend la copie.

Exemples

copie en block de 512 octets entre un disque et une cassette, mais saute le label de 4 KiB au début du disque :
disk=/dev/rdsk/c0t1d0s2
tape=/dev/rmt/0
(dd bs=4k skip=1 count=0 && dd bs=512k) ‹$disk ›$tape
(dd bs=4k seek=1 count=0 && dd bs=512k) ‹$tape ›$disk
Copier une partition de disque dur sur un autre disque dur
dd if=/dev/sda2 of=/dev/sdb2 bs=4096 conv=notrunc,noerror
Cloner un disque dur en entier
dd if=/dev/sda of=/dev/sdb conv=notrunc,noerror
Copier un grand disque sur un autre disque plus petit. La seule différence entre une grande partition et une petite partition, hormis la taille, est la table de partition. Si vous copiez sda vers sdb, un disque entier avec une seule partition, sdb étant plus petit que sda, alors vous devez faire :
dd if=/dev/sda skip=2 of=/dev/sdb seek=2 bs=4k conv=noerror
Réaliser l'image ISO d'un CD
dd if=/dev/hdc of=/home/sam/moncd.iso bs=2048 conv=notrunc
Créer une clé USB bootable
dd if=/home/uubu/insert.iso of=/dev/sdb ibs=4b obs=1b conv=notrunc,noerror
Copier seulement le MBR d'un disque dur
dd if=/dev/sda of=/home/sam/MBR.image bs=446 count=1
Ecrire par dessus toute la place libre d'une partition
dd if=/dev/urandom › fichieroccupanttoutlespacelibre

Astuces

Pour voir la mémoire vive
dd if=/proc/kcore | hexdump -C | less
Quels systèmes de fichiers sont installés
dd if=/proc/filesystems | hexdump -C | less
Tous les modules chargés
dd if=/proc/kallsyms | hexdump -C | less
Table des interruptions
dd if=/proc/interrupts | hexdump -C | less
Depuis combien de temps fonctionne le système
dd if=/proc/uptime | hexdump -C | less
Partitions et tailles en Ko
dd if=/proc/partitions | hexdump -C | less
Etat de la mémoire
dd if=/proc/meminfo | hexdump -C | less
Créer un disque de sauvegarde (dcfldd est un programme qui ajoute aux fonctionnalités de dd l'affichage d'une barre de progression)
dcfldd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror
pour réaliser un backup de root puis :
dd if=/home/sam/root.img of=/dev/sda2 (root) bs=4096 conv=notrunc,noerror
Créer un lecteur virtuel
dd if=/dev/zero of=/dev/ram7 bs=1k count=16384
puis :
mkfs.ext3 -m0 /dev/ram7 4096
Copier la mémoire RAM dans un fichier
dd if=/dev/mem of=/home/sam/mem.bin bs=1024
Lire le BIOS
dd if=/dev/mem bs=1k skip=768 count=256 2›/dev/null | strings -n 8

Utilitaires dérivés

ddrescue permet de récupérer des secteurs défectueux
sdd Utile quand la taille des blocs d'entrée est différente de celle des blocs de sortie, et réussira dans des cas où dd échoue
^
18 mars 2016

htmlpdflatexmanmd




ddns-confgen

ddns-confgen, tsig-keygen

Outil de génération de clé ddns

   tsig-keygen et ddns-confgen sont des méthodes d'invocation pour un utilitaire qui génère des clé à utiliser dans les signatures TSIG. Les clés résultante peuvent être utilisée, par exemple, pour sécuriser les mises à jours dynamiques, ou pour le canal de commande rndc.

   lancé en tant que tsig-keygen, un nom de domaine peut être spécifié sur la ligne de commande qui est utilisé comme nom pour la clé générée. Défaut: tsig-key

   Lancé en tant que ddns-confgen, la clé générée est accompagniée par un texte de configuration et des instruction qui peuvent être utilisée avec nsupdate et named pour définir DDNS, incluant un exemple de déclaration update-policy.

OPTIONS

-a algorithm Spécifie l'algorithme à utiliser pour la clé TSIG
-k keyname Spécifie le nom de clé pour la clé d'authentification ddns. Défaut: ddns-key
-q (ddns-confgen uniquement) Mode silencieux. Affiche seulement la clé.
-r randomfile Spécifie une source de données aléatoires
-s name (ddns-confgen uniquement) Génère un exemple de configuration pour autoriser les mises à jours dynamiques d'un simple hostname.
-z zone (ddns-confgen uniquement) Génère un exemple de configuration pour autoriser les mises à jours dynamiques d'une zone.
^
03 février 2016

htmlpdflatexmanmd




deallocvt

deallocvt

dé-alloue les consoles virtuelles

   La commande deallocvt dé-alloue la mémoire et les structures de données kernel pour les consoles virtuelles inutilisées. Si un ou plusieurs arguments N sont données, seul les consoles /dev/ttyN sont dé-alloués.

   Une console virtuele est inutilisée si est n'est pas la console courante, et qu'aucun processus ne l'a ouvert en lecture ou écriture, et aucun texte n'a été séléctionné dans son écran.

^
15 mars 2010

htmlpdflatexmanmd




debmirror

debmirror

Serveur de dépôt mirroir

   Un serveur mirroir, est une copie exacte d'un serveur de dépôt. Il peut être utile d'en créer si vous n'avez pas accès à Internet de manière permanente, ou pour limiter la bande passante consommées par l'installation de logiciels depuis Internet. Debmirror est un script qui permet de télécharger et maintenir un mirroir Debian. Il utilise ftp, http, hftp ou rsync.

   Debmirror effectue 3 étapes:

1. Téléchargement des paquets et des sources
2. nettoyage des fichiers inconnus
3. les paquets et sources sont scannés pour construire une liste.

OPTIONS

--mirrordir emplacement ou seront placé les paquets
--debug mode débugage
--progress, -p affiche une barre de progressions pendant le téléchargement
--verbose, -v mode verbeux
--source inclure les sources dans le miroir (défaut)
--nosource ne pas inclure les sources
--md5sums, -m utiliser md5sums pour déterminer si les fichiers sont correctes
--passive télécharge en mode passif
--host=remotehost, -h spécifie l'hôte distant (défaut : ftp.debian.org)
--user=remoteusername, -u Spécifie l'utilisateur distant, utile pour les proxys
--passwd=remoteuserpassword password de l'utilisateur
--method=ftp|hftp|http|rsync, -e Méthode pour le téléchargement des paquets
--proxy=http://user:pass@url:port/ Serveur proxy a utiliser
--timeout=seconds, -t timeout à utiliser pour les opérations réseau (défaut 300 sec)
--root=directory, -r directory Spécifier le dossier sur l'hôte distant défaut "/debian"
--dist=foo[,bar,...], -d foo spécifier la distribution (sarge, etch, lenny, sid)
--section=foo[,bar,...], -s foo Spécifier la section défaut : main,contrib,non-free,main/debian-installer
--arch=foo[,bar,...], -a foo Architecture, défaut : i386.
--postcleanup nettoie le miroir local après le mirroring et uniquement s'il n'y a pas eu d'erreur
--cleanup fait un nettoyage des fichiers et dossiers inconnus
--nocleanup ne nettoie pas le miroir local
--ignore=regex ne jamais télécharger de fichier dont les noms de fichiers correspondent à regex, peut être spécifié plusieurs fois
--exclude-deb-section=regex ne jamais télécharger de fichier dont la section correspond à regex [games, doc, oldlibs, science,...] peut être spécifié plusieurs fois
--limit-priority=regex limite le téléchargement dont la priorité correspond à regex [required, extra, optional, etc...]
--include=regex ne pas exclure les fichiers correspondant à regex peut être spécifié plusieurs fois
--skippackages ne pas re-télécharger les paquets et fichiers sources, utile si vous savez qu'ils sont à jour.
--getcontents télécharge les fichiers Contents.arch.gz
--max-batch=number télécharge jusqu'à max-batch nombre de fichiers et ignore le reste
--rsync-batch=number télécharge jusqu'à max-batch nombre de fichiers avec chaque appel rsync
--ignore-missing-release ne plante pas si un fichier Release manque.
--ignore-release-gpg ne plante pas sir Release.gpg est manquant
--dry-run mode simulation
--rsync-options=options spécifier les options rsync alternatives à utiliser
--ignore-small-errors n'indique pas les erreurs de type missing ou broken
--pdiff=use|mirror|none si Release contient des entrées pour pdiff, debmirror va tenter de mettre a jour les fichiers sources et les paquets mais ne les inclu pas dans le mirroir.

   Debmirror utilise gpgv pour vérifier les Release et Release.pgp en utilisant par défaut /.gnupg/trustedkeys.gpg. Pour ajouter les bonnes clés, il faut les importer comme ceci : gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg --export | gpg --import ou télécharger les clé depuis le serveur : gpg --keyserver keyring.debian.org --recv-keys key ID cette key ID peut être trouvée dans le message d'erreur gpgv dans debmirror

Installer un dépôt local

Un serveur web doit déjà exister (ex : apache)
Création d'un utilisateur système dédié, dans le groupe du serveur web pour que ce dernier ait les accès
adduser --system --home /var/www/mirror --gid 33 --no-create-home mirror
puis on crée un répertoire pour stocker les fichiers
mkdir /var/www/mirror
chown mirror:www-data ./mirror
chmod u+rwx,g+rxs-w,o-rwx ./mirror
Installation des programmes nécessaires (inclure un serveur http ou ftp):
aptitude install debmirror debian-keyring
les opérations suivante sont à effectuer sous l'utilisateur mirror:
su mirror
récupération des clé
gpg --keyring /usr/share/keyrings/debian-role-keys.gpg --export | gpg --import gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg --export | gpg --import gpg --no-default-keyring -a --keyring /usr/share/keyrings/debian-archive-keyring.gpg --export 55BE302B | gpg --no-default-keyring --keyring /.gnupg/trustedkeys.gpg --import -
récupération des paquets (ici on ne récupère que la section debian-security)
debmirror --verbose --arch=i386,amd64 --dist=lenny/updates --source --method=rsync --host=mirror.ens-lyon.fr --root=:debian-security --section=main,contrib,non-free,main/debian-installer -ignore-release-gpg --cleanup /var/www/mirror/debian-security/
pour les clients utiliser dans /etc/apt/sources.list
deb http://server/mirror/debian-security lenny/updates main contrib non-free
deb-src http://server/mirror/debian-security lenny/updates main contrib non-free

Exemple de fichier de lancement de debmirror
# ! /bin/sh
ARGS=" --progress \
--arch=i386,amd64 \
--dist=lenny/updates \
--source \
--method=rsync \
--host=mirror.ens-lyon.fr \
--root=:debian-security \
--section=main,contrib,non-free,main/debian-installer \
--ignore-release-gpg \
--cleanup \
/var/www/mirror/debian-security/"

debmirror $ARGS

   Attention aux droits et faire un cron pour lancer périodiquement ce script.
^
04 novembre 2016

htmlpdflatexmanmd




debugfs

debugfs

Debugger de système de fichier ext2/3/4

   debugfs est un debugger interactif de système de fichier. Il peut être utilisé pour examiner et changer l'état d'un système de fichier ext2/3/4.

OPTIONS

-w Spécifie que le système de fichier devrait être ouvert en mode lecture écriture.
-n  Désactive la vérification de checksum de métadonnées.
-c Spécifie que le système de fichier devrait être ouvert en mode catastrophique, dans lequel les bitmaps d'inode et de groupe ne sont pas lus initialement. Force l'ouverture en lecture-seule.
-i Spécifie que le périphérpique représente un fichier image ext2 créé par e2image. Vu qu'un fichier image ext2 ne contient que le superblock, descripteur de groupe de blocks, bitmaps d'allocation d'inode et de block, et la table d'inode, de nombreuses commandes ne fonctionneront pas correctement.
-d data_source_device avec -i, spécifie que data_source_device devrait être utilisé en lisant les blocks non trouvés dans le fichier image ext2.
-b blocksize Spécifie la taille de block en octet pour le système de fichier.
-s superblock Force la lecture du superblock au numéro de block spécifié au lieu d'utiliser le primaire localisé à un offset de 1024 octets.
-f cmd_file Lit les commande depuis ce fichier et les exécute, puis se termine.
-D Ouvre le périphérique en Direct I/O et bypasse le cache.
-R request Exécute la commande spécifiée, puis quitte
-z undo_file Avant d'écraser un block, l'écris dans le fichier undo spécifié.

Spécifier des fichiers

   De nombreuses commandes prennent un argument filespec pour spécifier un inode dans le système de fichier. Cet argument peut être de 2 formes, un numéro d'inode entre '‹›', ou un chemin de fichier.

Commandes

blocks filespace Affiche les blocks utilisés par l'inode filespec
bmap [ -a ] filespec logical_block [physical_block] Afiche ou définis le numéro de bock physique correspondant an numéro do block logique logical_block dans l'inode filespec. Si -a est spécifié, tente d'allouer un block si nécessaire.
cat filespec Dump le contenu de l'inode filespec sur stdout
cd filespec Change le répertoire de travail courant
chroot filespec Change le répertoire root
close [-a] Ferme de système de fichier ouvert. Si -a est spécifié, écris les changement dans le superblock et les descripteurs de groupe de block dans toutes les sauvegardes du superblock, pas seulement le principal.
clri filespec Efface le contenu de l'inode filespec
copy_inode source_inode destination_inode Copie le contenu de la structure inode dans source_inode et l'utilise pour écraser la structure inode dans destination_inode
dirsearch filespec filename Recherche dans le répertoire filespec le filename
dirty Marque le système de fichier dirty, pour que le superblock soit écris en quittant
dump_mmp [mmp_block] Affiche les valeurs de protection mmp. Si mmp_block est spécifié, vérifie et dump les valeurs MMP pour le numéro de block donné, sinon utilise le champ s_mmp_block dans le superblock pour localiser et utiliser le block MMP existant.
dx_hash [-h hash_alg] [-s hash_seed] filename Calcule le hash de répentoire de filename. L'algorithme de hashage spécifié avec -h peut être legacy, half_md4 ou tea.
dump_extents [-n] [-l] filespec Dump l'extent tree de l'inode filespec. -n affiche seulement les nœuds interieurs dans l'extent tree.
ea_get [-f outfile] filespec attr_name Récupère la valeur de l'attribut étendu attr_name dans le fichier filespec et l'écris soit sur stdout ou outfile.
ea_list filespec Liste les attributs étendus associés avec le fichier filespec sur stdout
ea_set [-f infile] filespec attr_name attr_value Définis la valeur de l'attribut étendu attr_name dans le fichier filespec à la valeur attr_value ou le lit depuis stdin
ea_rm filespec attr_names... Supprime l'attribut étendu attr_name du fichier filespec
expand_dir filespec Étend le répertoire filespec
fallocate filespec start_block [end_block] Alloue et map les blocks non initialisés dans filespec entre le block logique start_block et end_block. Si end_block n'est pas spécifié, cette fonction map tous les blocks disques libres ou la taille de fichier maximum. Les mappages existant sont laissés seuls.
feature [fs_feature] [-fs_feature] ... Définis ou efface divers fonctionnalités dans le superblock, puis affiche l'état courant des fonctionnalités.
filefrag [-dvr] filespec Affiche le nombre d'extents contigus dans filespec. Si filespec est un répertoire et -d n'est pas spécifié, filefrag affiche le nombre d'extent contigus pour chaque fichier dans le répertoire. -v affiche un listing avec tabulations, -r effectue un listing récursif.
find_free_block [count [goal]] Trouver les count premier blocks libre, en commençant à goal et l'alloue. = ffb
find_free_inode [dir [mode]] Trouver un inode libre et l'allouer. Si présent, dir spécifie le numéro d'inode du répertoire auquel il est alloué. mode spécifie les permissions du nouvel inode. == ffi
freeb block [count] Marque le numéro de block comme non alloué. Si count est présent, count blocks commençant au numéro de block seront marqués non alloués
freefrag [-c chunk_kb] Affiche la fragmentation d'espace lible dans le système de fichier. avec -c, la commande filefrag affiche le nombre de chunks libre de taille chunk_kb trouvés dans le système de fichier.
freei filespec [num] Libère l'inode filespec. Si num est spécifié, efface également l'inode num-1 après l'inode spécifié
htree_dump filespec Dump le répertoire hash-indexed filespec, affichant sa structure d'arborescence
icheck block ... Affiche un listing des inodes qui utilisent un ou plusieurs blocks spécifiés sur la ligne de commande.
inode_dump filespec Affiche le contenu de la structure de données d'inode en hexa et ASCII
imap filespec Affiche l'emplacement de la structure de données d'inode (dans la table d'inode) de l'inode filespec
init_filesys device blocksize Créé un système de fichier ext2 dans le périphérique avec la taille blocksize. Noter que cela n'initialise pas toutes les structures de données.
journal_close Ferme un journal ouvert
journal_open [-c] [-v ver] [-j ext_jnl] Ouvre le journal pour lecture et écriture. -c active le checksum journal; -v spécifie le format de checksum (2 ou 3).
journal_run Rejoue toutes les transactions dans le journal ouvert
journal_write [-b blocks] [-r revoke] [-c] file Écris une transaction dans le journal ouvert. La liste des blocks à écrire devrait être fournis dans blocks; les blocks eux-même devraient être lisible depuis file. Une liste de blocks à révoquer peut être fournie dans revoke. Par défaut, un commit est écris à la fin; -c écrit une transaction uncommited.
kill_file filespec Désalloue l'inode filespec et ses blocks. Noter que cela ne supprime pas d'entrées répertoire dans cet inode.
lcd directory Change le répertoire de travail courant
ln filespec dest_file créer un lien nomé dest_file qui est un lien dure vers filespec. Noter que cela n'ajuste pas le compteur de référence d'inode
logdump [-acsO] [-b block] [-i filespec] [-f journal_file] [output_file] Dump le contenu du journal ext3. Par défaut, dump l'inode journal comme spécifié dans le superblock. -i dump le journal depuis l'inode interne donné par filespec. -f spécifie un fichier régulier contenant les données journal. -s utilise les informations de sauvegarde dans le superblock pour localiser le journal. -a affiche le contenu te tous les blocks descripteur, -b affiche tous les enregistrement journaux référés dans le block spécifié, -c affiche le contenu de toutes les données des blocks de données sélectionnés pas -a et -b. -O affiche les anciennes entrées du journal.
ls [-l] [-c] [-d] [-p] [-r] filespec Affiche un listing des fichiers dans le répertoire filespec. le flag -c force les checksum de block répertoire à être affichés. -d liste les entrées supprimées. -l est plus verbeux. -p liste les fichier dans un format plus simple pour les scripts. -r force l'affichage du nom de fichier même s'il est chiffré.
list_deleted_inodes [limit] Liste les inodes supprimés, optionnellement limité à ceux supprimés il y a limite secondes. = lsdel
modify_inode filespec Modifie le contenu de la structure d'inode filespec. = mi
mkdir filespec Créer un répertoire
mknod filespec [p|[[c|b] major minor]] Créer un fichier spécial.
ncheck [-c] inode_num ... Prend la liste demandée de numéro d'inode, et affiche un listing de chemin vers ces inodes. -c vérifie le type de fichier dans l'entrée répertoire pour s'assurer qu'il match le type d'inode.
open [-weficD] [-b blocksize] [-s superblock] [-z undo_file] device Ouvre un système de fichier pour l'édition. -f force l'ouverture même s'il a des fonctionnalité incompatibles, -e ouvre le fs en mode exclusif, les autres options ont les même signification que les options de debugfs.
punch filespec start_blk [end_blk] Supprime les blocks dans l'inode entre start_blk et end_blk. Si end_blk est omis, cette commande fonctionne comme une commande tronquer, c'est à diste que tous les blocks depuis start_blk jusqu'à la fin du fichier seront désalloués
symlink filespec target Créer un lien symbolique
pwd Afficher le répertoire de travail courant
quit Quitter debugfs
rdump directory[...] destination Dump récursivement le ou les répertoires, et tous leur contenu dans la destination spécifiée
rm pathname unlink pathname
rmdir Supprime le répertoire filespec
setb block [count] Marque le numéro de block spécifié comme alloué. si count est spécifié, count blocks sont marqués alloués
set_block_group bgnum field value Modifie le descripteur de groupe de block bgnum pour que le champ field du descripteur de groupe de block ait la valeur value.
seti filespec [num] Marque l'inode utilisé dans le bitmap d'inode. Si num est spécifié, met num-1 inodes après l'inode spécifié.
set_inode_field filespec field value Modifie l'inode spécifié par filespec pour que le champ field ait la valeur value. La liste de champs d'inode valide peut être obtenu avec set_inode_field -l. = sif
set_mmp_value field value Modifie les données MMP. La liste des champs modifiables peut être obtenu avec set_mmp_value -l. = smmp
set_super_value field value Définis un champ du superblock. set_super_value -l pour lister les champs modifiables. = ssv
show_super_stats [-h] Liste le contenu du superblock et des descripteurs de groupe de block. -h n'affiche que le contenu du superblock. = stats
stat filespec Affiche le contenu de la structure d'inode de l'inode filespec
testb block [count] Test si le numéro de block est marqué comme alloué dans le bitmap de block.
testi filespec Test si l'inode est marqué comme alloué dans le bitmap d'inode
undel ‹inode_number› [pathname] Récupère le numéro d'inode spécifié.
unlink pathname Supprime le lien spécifié. N'ajuste pas le compteur de référence d'inode
write source_file out_file Copie le contenu du fichier source_file dans un nouveau fichier créé
zap_block [-f filespec] [-o offset] [-l length] [-p pattern] block_num Écrase le block spécifié par block_num avec des 0. -p utilise l'octet spécifié, -f block_num est relatif au début du fichier. -o et -l limitent la plage d'octets à écraser.
zap_block [-f filespec] [-b bit] block_num change les portions du block_num physique. -f, block_num est un block logique relatif au début de filespec

Variables d'environnement

DEBUGFS_PAGER debugfs pipe toujours la sortie de certaines commande dans un pager.
PAGER Pager à utiliser
^
02 janvier 2017

htmlpdflatexmanmd




default.pa

default.pa, system.pa

Script de démarrage du serveur de son PulseAudio

   Le serveur PulseAudio interprète un script de configuration au démarrage, qui est principalement utilisé pour définir le jeu de modules à charger. Quand PulseAudio se lance dans le mode par utilisateur et que ~/.config/pulse/default.pa existe, ce fichier est utilisé, sinon utilise /etc/pulse/default.pa est utilisé s'il existe. Quand PulseAudio est lancé en système, /etc/pulse/system.pa est utilisé.

   Le script devrait contenir des directives dans le langage CLI PulseAudio, tel que documenté par pulse-cli-syntax.

^
04 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/default_contexts

/etc/selinux/‹SELINUXTYPE›/contexts/default_contexts

Fichier de configuration de contextes par défaut SELinux

   Ce fichier contient des entrée pour les application de login compatible SELinux. Chaque ligne consiste des éléments suivants:

  login_process user_login_process [user_login_process] ...

login_process Consiste d'une entrée role:type[:range] qui représente le contexte du processus de login définis dans la stratégie
user_login_process Consiste d'une ou plusieurs entrées role:type[:range] qui représentent le contexte du processus login utilisateur définis dans la stratégie.

Exemple


system_r:crond_t:s0 system_r:system_crond_t:s0
system_r:local_login_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
system_r:remote_login_t:s0 user_r:user_t:s0
system_r:sshd_t:s0 user_r:user_t:s0
system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0
system_r:xdm_t:s0 user_r:user_t:s0
^
04 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/default_type

/etc/selinux/‹SELINUXTYPE›/contexts/default_type

Fichier de configuration de type par défaut SELinux

   Ce fichier contient les entrées qui permettent aux application compatibles SELinux comme newrole de sélectionner un type par défaut pour un rôle s'il n'est pas fournis. Chaque ligne dans ce fichier a le format role:type où:

role Le rôle SELinux
type Le type de domaine qui est retourné pour ce rôle

Exemple


auditadm_r:auditadm_t
user_r:user_t
^
29 octobre 2011

htmlpdflatexmanmd




deluser

deluser, delgroup

Retirer un utilisateur ou un groupe

   Retire un utilisateur ou un groupe en fonction des options dans /etc/deluser.conf et /etc/adduser.conf. Par défaut, deluser ne retire pas le répertoire personnel, sa boite aux lettre ou tout autre fichier qu'il possède.

OPTIONS

--conf utilise le fichier spécifié au lieu de /etc/deluser.conf et /etc/adduser.conf
--group Retire un groupe. opération par défaut si invoqué par delgroup
--force Permet de supprimer le compte root
--quiet mode silencieux
--system ne supprime que les comptes systèmes
--backup sauvegarde tous les fichiers du répertoire personnel et la boite aux lettres de l'utilisateur dans un fichier nommé /$utilisateur.tar.gz.
--backup-to Chemin où placer les fichiers de sauvegarde (défaut /) --backup devient implicite.
--remove-home supprime le répertoire personnel et la boite aux lettres de l'utilisateur
--remove-all-files supprime tous les fichiers du système possédé par l'utilisateur

Valeur de retour

0 opération réussie
1 le compte à supprimer n'est pas un compte système
2 l'utilisateur n'existe pas
3 le groupe n'existe pas
4 erreur interne
5 le groupe n'est pas vide
6 l'utilisateur n'appartient pas au groupe indiqué
7 impossible de retirer un utilisateur de son groupe primaire
8 perl-modules n'est pas installé
9 pour supprimer root, vous devez indiquer --force
^
29 octobre 2011

htmlpdflatexmanmd




deluser.conf

deluser.conf

Fichier de configuration pour deluser et delgroup

   Fichier de configuration pour deluser et delgroup. Ces derniers lisent également adduser.conf: les paramètres de deluser.conf peuvent surcharger adduser.conf.

REMOVE_HOME Supprime le répertoire personnel et la boite aux lettres (0 ne pas supprimer, 1 supprimer)
REMOVE_ALL_FILES Supprime tous les fichiers du système appartenant à l'utilisateur (0 ne pas supprimer, 1 supprimer). Si défini, REMOVE_HOME n'a aucun effet.
BACKUP si une des option précédente est activée, tous les fichiers sont sauvegardés avant d'être supprimés.
BACKUP_TO chemin où placer les backups.
NO_DEL_PATHS Liste d'expression rationnelles, séparées par des espaces. Chaque fichier est comparé à ces expressions, si une expression matche, le fichier n'est pas supprimé. (par défaut seul les fichiers dans /home sont supprimés)
ONLY_IF_EMPTY Ne supprime un groupe que s'il n'a plus aucun utilisateur.
EXCLUDE_FSTYPES Expression rationnelle qui décrit les systèmes de fichiers à exclure lors de la recherche des fichiers à supprimer (défaut: "(proc|sysfs|usbfs|devpts|tmpfs)")

^
18 mars 2016

htmlpdflatexmanmd




delv

delv

Utilitaire de recherche et de validation DNS

   delv (Domain Entity Lookup & Validation) est un outil pour envoyer des requêtes DNS et valider les résultats en utilisant le même résolveur et validateur interne de named.

   delv envoie à un serveur de nom spécifié toutes les requêtes nécessaires pour obtenir et valider les données demandées, incluant la requête originale, les requêtes sous-jacentes pour suivre les chaînes CNAME ou DNAME, et les requêtes pour les records DNSKEY, DS et DLV pour établir une chaîne de confiance pour la validation DNSSEC. Il n'effectue pas de résolution itérative, mais simule le comportement du serveur de nom configuré pour la validation DNSSEC et le forwarding

   Par défaut, les réponses sont validées en utilisant les ancres de confiance DNSSEC embarqués pour la zone root et pour la zone de validation ISC DNSSEC (dlv.isc.org). Les enregistrements retournés par delv sont soit validées ou non signées. Si la validation échoue, une explication de l'erreur est incluse dans la sortie.

   Sauf mention, delv tente chaque serveur listé dans /etc/resolv.conf, et si aucune adresse n'est utilisable, utilise 127.0.0.1 ou ::1. Sans arguments ni options, delv effectue une requête NS pour '.'

   La syntaxe de base est delv @server name type, où

server est le nom ou l'adresse IP d'un serveur à requêter.
name est le nom de la ressource à rechercher
type est le type de requête (ANY, A, MX, SIG, etc)

OPTIONS

-a anchor-file Spécifie un fichier depuis lequel lire les TA DNSSEC. défaut: /etc/bind.keys, qui est inclus avec bind9 et contient les TA pour la zone root et pour dlv.isc.org.
-b address Définis l'adresse IP source de la requête
-c class Définis la classe de la requête. Actuellement seul IN est supporté
-d level Niveau de débug, de 0(pas de debug) à 99
-i Mode non-secure. Désactive la validation DNSSEC
-m Debuggage de l'utilisation mémoire
-p port# Spécifie le port de destination pour la requête
-q name Définis le nom de la requête. Utile pour éviter toute ambiguïté
-t type Définis le type de requête. Utile pour éviter toute ambiguïté
-x addr Indique une requête inverse
-4 Force l'utilisation d'IPv4
-6 Force l'utilisation d'IPv6

Options de recherche

+[no]cdflag Définis le bit CD dans la requête. Utile pour les problèmes DNSSEC derrière un resoleur
+[no]class Affiche la CLASS en affichant l'enregistrement
+[no]ttl Affiche le TTL en affichant l'enregistrement
+[n]rtrace Active le logging du résolveur
-[no]mtrace Active le logging de message. Produit un dump détaillé des réponses reçues
+[no]vtrace Active le logging de validation. Affiche le processus interne du validateur
+[no]short affiche une réponse courte
+[no]comments affiche les commentaires dans la sortie
+[no]rrcomments Affiche les commentaires par enregistrement dans la sortie.
+[no]crypto Affiche les champs cryptographiques dans les enregistrements DNSSEC
+[no]trust Affiche le niveau de confiance en affichant un enregistrement.
+[no]split[=W] Split les champs base64 ou hexa long en portions de W caractères (arrondis au multiple de 4 le plus proche)
+[no]all Affiche les options (+comments, +rrcomment, +trust) comme un groupe
+[no]multiline Affiche les records comme les records SOA dans un format multi-ligne.
+[no]root[=ROOT] Indique si la validation DNSSEC est effectuée de manière conventionnelle, et spécifie le nom d'un TA.
+[no]dlv[=DLV] Effectue la validation DNSSEC, et spécifier le nom du TA DLV. Défaut: dlv.isc.org.
^
28 mars 2016

htmlpdflatexmanmd




depmod

depmod

Génère modules.dep et les fihiers de map

   Génère les fichiers modules.dep et les map. Les modules du kernel Linux peuvent fournir des services (appelés symboles) pour d’autres modules (en utilisant une des variantes EXPORT_SYMBOL dans le code). Si un second module utilise ce symbole, il dépend du premier module. depmod crée une liste de dépendances de module en lisant chaque module dans /lib/modules/version et détermine quels symboles ils exportent et quels symboles ils nécessitent. Par défaut, cette liste est écrite dans modules.dep, et une version hashée binaire modules.dep.bin dans le même répertoire. Si des noms de fichiers sont donnés sur la ligne de commande, seuls ces modules sont examinés. depmod créé également une liste de symboles fournis par module dans le fichier modules.symbols et sa version hashé binaire modules.symbols.bin

   Si une version est donnée, utilise celle donnée plutôt que la version courante du kernel. depmod génère également des fichiers map dans le répertoire de sortie utilisé par les anciennes infrastructures hotplug.

OPTIONS

-a, --all sonde tous les modules. par défaut si aucun fichier n’est donné en ligne de commande.
-A, --quick Recherche les nouveaux modules et régénère les fichiers, ou quitte si aucun nouveau module n’est trouvé
-b, --basedir Utilise le répertoire spécifié au lieu de /lib/modules/version
-C, --config Utilise le fichier ou le répertoire spécifié au lieu de /etc/depmod.conf ou /etc/depmod.d/
-e, --errsyms Combiné à -F, report les symboles nécessaire à des modules qui ne sont fournis par aucun module ni le kernel.
-E, --symvers Combiné avec -e, reporte toutes les versions de symbole fournis par les modules qui correspondent pas avec les versions de symbole fournis par le kernel dans son Module.symvers. Incompatible avec -F
-F, --filesyms Spécifie le fichier system.map produit à la compilation du kernel.
-m, --map Permet la génération des fichiers map
-n, --dry-run Envoie le modules.dep résultant et les divers fichiers map sur stdout au lieu de les écrire dans le répertoire des modules.
-P Certaines architectures préfixent les symboles avec un caractère supplémentaire, donné avec cette options
-v, --verbose Affiche tous les symboles dont chaque module dépends
^
28 mars 2016

htmlpdflatexmanmd




depmod.d

depmod.d

Configuration de depmod

   Configuration de depmod. L’ordre dans lequel les modules sont traités peut être altéré sur une base globale ou par module. Le format des fichiers sous depmod.d est simple: Une commande par ligne, les lignes blanche et les lignes commençant par # sont ignorés. ’\’ à la fin d’un ligne pour scinder une ligne longue en plusieurs

Commandes

search subdirectory... Spécifie l’ordre de traitement des sous-répertoires sous /lib/modules. La priorité est donnée du premier listé au dernier listé. Le mot clé spécial built-in réfère aux répertoires de module standard installé par le kernel. Par défaut la priorité est donné à un répertoire nommé update en utilisant cette recherche : "update built-in"
override modulename kernelversion modulesubdirectory Permet de spécifier la version d’un module à utiliser en priorité quand plusieurs modules ont le même nom. Il est possible de spécifier un kernel ou tous les kernel en utilisant ’*’, et de spécifier le sous-répertoire sous /lib/modules où le module cible est installé.
^
03 février 2016

htmlpdflatexmanmd




/dev/console

/dev/console



   Un système Linux a jusqu'à 63 consoles virtuelles (périphériques caractère avec le numéro majeur 4 et mineur 1 à 63), généralement appelés /dev/ttyn avec 1 ‹= n ‹= 63. La console courante est également adressée par /dev/console ou /dev/tty0, le périphérique caractère avec le numéro majeur 4 et mineur 0, avec le mode 0622 et le propriétaire root:tty

   Démarrer un processus sur une console peut se faire avec init, mingetty ou agetty, ou demander à openvt de démarrer un processus sur la console, ou démarre X, qui va trouver une console inutilisée, et y afficher sa sortie.

   Pour basculer d'une console à l'autre, on peut utiliser Alt+Fn ou Ctrl+Alt+Fn pour basculer sur la console n. AltGr+F permet de basculer à la console n+12, ou utiliser Alt+RightArrow ou Alt+LeftArrow, ou utiliser le programme chvt.

   La commande deallocvt va libérer la mémoire prise par le tampon d'affichage pour les consoles qui ne sont associées avec un processus.

Propriétés

   Les consoles gèrent beaucoup d'états. Les consoles simulent des terminaux VT100. Une console est réinitialisée en affichant les 2 caractères ESC c. Toutes les séquences d'échappement se trouvent dans console_codes(4).
^
07 mars 2015

htmlpdflatexmanmd




/dev/full

/dev/full

Périphérique full

   Écrire dans ce fichier échoue avec une erreur ENOSPC. Peut être utilisé pour tester comment un programme réagis aux erreurs de disque plein. Lire depuis ce fichier retourne des caractères \0

Ce fichier est généralement créé par:
mknod -m 666 /dev/full c 1 7
chown root:root /dev/full

^
03 février 2016

htmlpdflatexmanmd




/dev/hd

/dev/hd

Périphérique de disque dur MFM/IDE

   Les hd* sont des périphériques blocs permettant l'accès aux contrôleurs de disques durs MFM/IDE. Le disque maître sur le premier contrôleur IDE (numéro majeur 3) est hda, le disque esclave est hdb. Le disque maître du second contrôleur (numéro majeur 22) est hdc, et le disque esclave (hdd).

   La notation générale des périphériques blocs IDE a la forme hdX ou hdXP, dans laquelle X est une lettre indiquant le disque physique, et P un nombre représentant la partition sur ce disque physique. La première forme est utilisée pour accéder au disque dans son ensemble. Les numéros de partitions sont assignées dans l'ordre de détection, et seules les partitions non vides et non étendues reçoivent un numéro. Toutefois, les numéros de partition de 1 à 4 sont donnés aux 4 partitions indiquées dans le MBR ( partitions primaires), qu'elles soient vides ou non, et étendues ou non. Ainsi, la première partition logique sera hdX5. Les partitions de type DOS et de type BSD sont supportées. Il peut y avoir au plus 63 partitions sur un disque IDE.

   Par exemple, /dev/hda correspond au premier disque IDE du système dans son ensemble, et /dev/hdb3 correspond à la 3ème partition primaire DOS sur le second disque.

Ils sont typiquement créés ainsi:
mknod -m 660 /dev/hda b 3 0
mknod -m 660 /dev/hda1 b 3 1
mknod -m 660 /dev/hda2 b 3 2
...
mknod -m 660 /dev/hda8 b 3 8
mknod -m 660 /dev/hdb b 3 64
mknod -m 660 /dev/hdb1 b 3 65
mknod -m 660 /dev/hdb2 b 3 66
...
mknod -m 660 /dev/hdb8 b 3 72
chown root:disk /dev/hd*

^
03 février 2016

htmlpdflatexmanmd




/dev/loop

/dev/loop, /dev/loop-control

périphériques loop

   Le périphérique loop est un périphérique loop qui map ses blocks de données non pas sur un périphérique physique comme un disque dur, mais aux blocks d'un fichier régulier dans un système de fichier ou dans un autre périphérique block. Cela peut être utile par exemple pour fournir un périphérique block pour une image de système de fichier stocké dans un fichier, pour qu'il puisse être monté avec la commande mount.

On peut faire:
dd if=/dev/zero of=file.img bs=1MiB count=10
sudo losetup /dev/loop4 file.img
sudo mkfs -t ext4 /dev/loop4
sudo mkdir /myloopdev
sudo mount /dev/loop4 /myloopdev

   Un fonction tranfert peut être spécifiée pour chaque périphérique loop pour chiffrer/déchiffrer.

   Depuis Linux 3.1, le kernel fournis le périphérique /dev/loop-control, qui permet à une application de trouver dynamiquement un périphérique libre, et d'ajouter et supprimer des périphériques du système.

Le programme ci-dessous utilise le périphérique /dev/loop-control pour trouver un périphérique loop, l'ouvre, ouvre un fichie à utiliser comme stockage sous-jacent, puis l'associe avec le périphérique loop. La session shell suivante démontre l'utilisation du programme:
› dd if=/dev/zero of=file.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00609385 s, 1.7 GB/s
› sudo ./mnt_loop file.img
loopname = /dev/loop5

Programme source:
#include ‹fcntl.h›
#include ‹linux/loop.h›
#include ‹sys/ioctl.h›
#include ‹stdio.h›
#include ‹stdlib.h›
#include ‹unistd.h›

#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
                } while (0)
    
int
main(int argc, char *argv[])
{
    int loopctlfd, loopfd, backingfile;
    long devnr;
    char loopname[4096];
    
    if (argc != 2) {
        fprintf(stderr, "Usage: %s backing-file\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    
    loopctlfd = open("/dev/loop-control", O_RDWR);
    if (loopctlfd == -1)
        errExit("open: /dev/loop-control");
    
    devnr = ioctl(loopctlfd, LOOP_CTL_GET_FREE);
    if (devnr == -1)
        errExit("ioctl-LOOP_CTL_GET_FREE");
    
    sprintf(loopname, "/dev/loop%ld", devnr);
    printf("loopname = %s\n", loopname);
    
    loopfd = open(loopname, O_RDWR);
    if (loopfd == -1)
        errExit("open: loopname");
    
    backingfile = open(argv[1], O_RDWR);
    if (backingfile == -1)
        errExit("open: backing-file");
    
    if (ioctl(loopfd, LOOP_SET_FD, backingfile) == -1)
        errExit("ioctl-LOOP_SET_FD");
    
    exit(EXIT_SUCCESS);
}

^
03 février 2016

htmlpdflatexmanmd




/dev/mem

/dev/mem, /dev/kmem, /dev/port

Mémoire système, mémoire du noyau, et ports d'entrées-sorties.

   mem est un périphérique caractère représentant une image de a mémoire principale de l'ordinateur. Il peut être utilisé pour examiner et modifier la mémoire système. Les adresses dans mem sont interprétés comme des adresses physiques. Les références à des adresses inexistantes renvoient des erreurs. Éxaminer ou éditer la mémoire est susceptible de conduire à des résultats indésirables quand les bits lecture ou écriture seule sont concernés.

Il est créé par:
mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

Le fichier kmem est identique à mem sauf qu'il s'agit de la mémoire virtuelle du noyau plutôt que de la mémoire physique. Il est créé ainsi:
mknod -m 640 /dev/kmem c 1 2
chown root:kmem /dev/kmem

port est identique à mem, mais ici, ce sont les ports d'entrées-sorties qui sont représentés. Il est créé ainsi:
mknod -m 660 /dev/port c 1 4
chown root:mem /dev/port

^
07 mars 2015

htmlpdflatexmanmd




/dev/null

/dev/null, /dev/zero

Périphérique null

   Les données écrites vers ce fichier spéciaux dont supprimés. Lire depuis /dev/null retourne toujours la fin d'un fichier. Lire depuis /dev/zero retourne toujours des octets contenant 0 (caractères \0)

null et zero sont généralement créés par:
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:root /dev/null /dev/zero

^
03 février 2016

htmlpdflatexmanmd




/dev/sd

/dev/sd

Contrôleur de disques SCSI

   Les noms de ces périphériques blocs suivent la convention suivante: sdlp, ou l est une lettre indiquant le lecteur physique, et p est un nombre caractérisant la partition sur ce disque physique. Souvent le numéro de partition p, sera absent si le périphérique correspond à l'ensembre du disque.

Les disques SCSI ont un numéro majeur valant 8, et un numéro mineur de la forme (16 addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo numéro_disque) + numéro_partition, ou numéro_disque est le numéro du disque physique dans l'ordre de détection, et numéro_partition est le suivant:
partition 0 = disque entier
partitions 1-4 = partitions primaires DOS.
partitions 5-8 = partitions étendues (logiques) DOS.

   Par exemple, /dev/sda aura un majeur 8, mineur 0, et se référera à l'ensemble du premier disque SCSI. /dev/sdb3 aura un majeur 8, mineur 19, et indique la 3ème partition primaire DOS sur le second disque SCSI du système.

   Actuellement, seuls les périphériques blocs sont disponibles, les interfaces "raw" ne sont pas encore implémentés.

^
03 février 2016

htmlpdflatexmanmd




/dev/tty

/dev/tty

Terminal de contrôle

   Le fichier /dev/tty est un fichier spécial en mode caractères, avec un numéro majeur 5 et mineur 0. Il possède les permissions 0666 et appartient à root:tty. Il s'agit d'un équivalent au terminal de contrôle d'un processus, s'il en a un.

   En plus de requêtes ioctl(2) supportées par les périphériques tty, la requête ioctl(2) TIOCNOTTY est disponible, qui permet de détacher le processus appelant de son terminal de contrôle.

   Si le processus est un leader de session, alors SIGHUP et SIGCONT seront envoyés au groupe de processus au premier plan, et tous les processus de la session perdent leur terminal. Le processus tente d'ouvrir /dev/tty. S'il réussit il se détache alors du terminal avec TIOCNOTTY. Si l'ouverture échoue, il n'est évidemment pas attaché à un terminal et n'a pas besoin de se détacher.

^
03 février 2016

htmlpdflatexmanmd




/dev/ttyS

/dev/ttyS

Lignes de communication série

ttyS[0-3] sont des fichiers spéciaux de périphériques caractères utilisées pour la connexion de terminaux série. Ils sont typiquement créés de la manière suivante:
mknod -m 660 /dev/ttyS0 c 4 64 # adresse de base 0x03f8
mknod -m 660 /dev/ttyS1 c 4 65 # adresse de base 0x02f8
mknod -m 660 /dev/ttyS2 c 4 66 # adresse de base 0x03e8
mknod -m 660 /dev/ttyS3 c 4 67 # adresse de base 0x02e8
chown root:tty /dev/ttyS[0-3]

^
04 juillet 2010

htmlpdflatexmanmd




df

df

Reporte la quantité d'espace disque utilisé et disponible sur les systèmes de fichiers.sans argument, Reporte l'espace utilisé et disponible sur tous les systèmes montés.

   Normalement l'espace disque est affiché en unité de 1024 octets, mais peut être changé. Les quantités non entières sont arrondis à l'unité supérieure.

OPTIONS

-a, --all Inclue dans le listing, les systèmes de fichiers 'dummy'.
-B SIZE, --block-size=SIZE définit la taille d'unité
--total affiche un grand total de tous les arguments traités.
-h, --human-readable Ajoute une lettre à chaque taille, en puissance de 1024.
-H equivalent à --si
-i, --inodes liste les informations d'utilisation des inodes au lieu de l'utilisation de block.
-k affiche les tailles en block de 1024 octets. équivalent à --block-size=1K
-l, --local limite le listing au systèmes de fichier locaux.
--no-sync N'invoque pas l'appel système sync avant de récupérer l'utilisation de donnée. df devient plus rapide sur les système avec de nombreux disques.
-P, --portability Utilise le format de sortie POSIX. Identique au format par défaut excepté :

        1. les informations sur chaque système de fichier sont toujours affichés sur exactement une ligne.
        2. les labels dans les en-têtes sont changés pour être confirme à POSIX
        3. la taille de block par défaut et le format de sortie ne sont pas affectés par les variables d'environnement DF_BLOCK_SIZE, BLOCK_SIZE et BLOCKSIZE. Cependant, la taille de block par défaut est affectée par POSIXLY_CORRECT, qui est de 512 octets au lieu de 1024 normalement.

--si Ajoute une lettre à chaque taille, en puissance de 1000.
--sync Invoque l'appel système sync avant d'obtenir les données d'utilisation.
-t FSTYPE, --type=FSTYPE limite le listing des systèmes de fichiers de type FSTYPE. Peut être spécifié" plusieurs fois.
-T --print-type affiche chaque type de système de fichier. Les types affichés sont ceux inclus ou exclus avec -t ou -x :

        nfs Système de fichier NFS.
        4.2, ufs, efs... Fichier système local.
        hsfs, cdfs Système de fichier sur un lecteur CD-ROM.
        pcfs Système de fichier MS-DOS, généralement une disquette.

-x FSTYLE, --exclude=FSTYPE Exclue le type de système de fichier spécifié. Peut être spécifié plusieurs fois.
^
04 février 2016

htmlpdflatexmanmd




dhcrelay

dhcrelay

Agent relais DHCP

   dhcrelay fournis un moyen de relayer les requêtes DHCP et BOOTP d'un sous-réseau dans lequel il n'y a pas de serveur DHCP directement connecté, vers un ou plusieurs serveurs DHCP dans d'autres sous-réseaux. Il support DHCPv4/BOOTP et DHCPv6.

OPTIONS

-6 Lance dhcrelay comme agent DHCPv6. Incompatible avec -4
-4 Lance dhcrelay comme agent DHCPv4. Incompatible avec -6
-c COUNT Compteur de sauts maximum, en transférant les paquets. défaut: 10.
-d Ne lance pas en tâche de fond
-p PORT Écoute et transmet sur le port spécifié. Défaut 67 pour DHCPv4/BOOTP et 547 pour DHCPv6
-q mode silencieux
-pf pid-file Fichier pid alternatif
--no-pid Désactive l'écriture des fichiers pid

Options DHCPv4

-a Ajoute un champs d'option agent à chaque requête avec de la forwarder au serveur.
-A LENGTH Spécifie la taille maximum de paquet à envoyer à un serveur. Cela peut être fait pour permettre suffisamment d'espace pour l'ajout des options agent
-D Supprime les packets des serveurs s'ils contiennent des options d'information d'agent relay qui indique qu'ils ont été générés en réponse à une demande qui vient d'un relay différent.
-i ifname Écoute pour les demandes sur l'interface spécifiée. Peut être spécifié plusieurs fois
-m append|replace|forward|discard Contrôle la gestion des paquets reçus qui contiennent déjà des options agent relay. Si un tel paquet n'a pas giaddr mis dans son en-tête, le standard DHCP impose que le paquet soit supprimé. Cependant, si giaddr est mis, le relay peut manipuler la situation de 4 manières différentes: il peut ajouter son propre jeu d'options relay au paquet, remplacer le champs options existant, forwarder le paquet inchangé; ou il peut le supprimer.

Options DHCPv6

-I Force l'utilisation de l'option DHCPv6 Interface-IP. Cette option est automatiquement envoyée quand il y a 2 ou plusieurs interfaces downstream utilisé, pour éviter les ambiguïtés.
-s subscriber-id Ajoute une option avec le subscriber-id spécifiée. Pour test uniquement.
-l [address%]ifname[#index] Spécifie l'interface réseaux 'lower': l'interface sur laquelle les requêtes sont reçues des client ou depuis d'autres agents relay. Au moins une option -l doit être spécifiée et ifname est un paramètre obligatoire.
-u [address%]ifname Spécifier l'interface 'upper': L'interface sur laquelle les requêtes des clients et d'autres agents relay devraient être forwardés. Au moins une option -u doit être spécifié, et ifname est obligatoire.

   Il est possible de spécifier la même interface avec différentes adresses plus d'une fois, et même, quand le système le supporte, d'utiliser la même interface comme interface à la fois upper et lower. Cependant, dans ce cas, des boucles peuvent se créer, définir le compteur de saut maximum. L'interface de bouclage n'est pas reconnue comme interface valide.
^
18 mars 2016

htmlpdflatexmanmd




dig

dig

Utilitaire de recherche DNS

   dig est un outil flexible pour interroger les serveurs de nom DNS. Sans spécifier de serveur, dig tente chaque serveur listé dans /etc/resolv.conf. Si aucune adresse serveur n'est utilisable, dig tente une requête locale. Sans arguments ni options, dig effectue une requête NS pour ".".

   Il est possible de définir des options par utilisateur via ${HOME}/.digrc. Ce fichier est lu et toute options qui s'y trouve est appliquée avant les arguments de la ligne de commande.

   La syntaxe de base est dig @server name type, où

server est le nom ou l'adresse IP d'un serveur à requêter.
name est le nom de la ressource à rechercher
type est le type de requête (ANY, A, MX, SIG, etc)

OPTIONS

-b address Définis l'adresse IP source de la requête.
-c class Spécifie la classe de la requête (IN, HS ou CH)
-f filename Permet d'opérer en mode batch en lisant une liste de recherche à traiter dans le fichier spécifié
-k filename Clé TSIG à utiliser avec -y
-m Active le debuggage de l'utilisation mémoire
-p port# Port pour la requête.
-q name Définis le nom de la requête. utile pour distinguer le nom des autres arguments.
-t type Définis le type de la requête (A par défaut). Un transfert de zone peut être demandé avec type=AXFR, pour un transfer incrémentale utiliser ixfr=N ou N est le numéro de série.
-v affiche la version et quitte
-x addr Indique une requête inverse
-y [hmac:]name:key] Permet de signer les requêtes DNS envoyées par dig et leur réponses en utilisant TSIG. La clé est spécifiée avec -k
-4 Force l'utilisation d'IPv4
-6 Force l'utilisation d'IPv6

Options de recherche

+[no]tcp Utilise TCP pour les requêtes Défaut: utilise UDP sauf pour les requêtes AXFR et IXFR
+[no]ignore Ignore les réponses UDP tronquées au lieu de retenter avec TCP.
+domain=somename Définis la liste de recherche pour contenir le seul domaine spécifié, comme si spécifié dans la directive domain de /etc/resolv.conf, et active le traitement de la liste de recherche comme si l'option +search était donné
+[no]search Utilise la liste de recherche définie par searchlist ou domain dans /etc/resolv.conf. Cette liste n'est pas utilisée par défaut.
+[no]showsearch Effectue une cherche en affichant les résultats intermédiaires.
+[no]aaonly Définis le flag aa dans le requête
+[no]aaflag Synonyme de aaonly
+[no]adflag Définis le bit AD dans la requête.
+[no]cdflag Définis le bit CD dans la requête
+[no]cl Affiche la CLASS en affichant l'enregistrement
+[no]ttlid Affiche le TTL en affichant l'enregistrement
+[no]recurse Met le bt RD dans la requête
+[no]nssearch Tente de trouver les serveurs de noms autoritatifs pour la zone contenant le nom recherché et afficher le SOA
+[no]trace Active le tracing du chemin de délégation depuis les serveurs racine pour le nom recherché.
+[no]cmd affiche la commande initial en commentaire dans la sortie
+[no]short affiche une réponse courte
+[no]identify l'IP et le port qui fournit la réponse en utilisant +[no]short
+[no]comments affiche les commentaires dans la sortie
+[no]rrcomments Affiche les commentaires par enregistrement dans la sortie.
+[no]crypto Affiche les champs cryptographiques dans les enregistrements DNSSEC
+split=W Split les champs base64 ou hexa long en portions de W caractères (arrondis au multiple de 4 le plus proche)
+[no]stats affiche les statistics dans la sortie
+[no]qr Affiche la requête quand elle est envoyée.
+[no]question Affiche la section question d'une requête quand une réponse est retournée
+[no]answer Affiche la section réponse
+[no]authority Affiche la section authority
+[no]additional Affiche la section additional
+[no]all Affiche les flags
+time=T Définit le timeout pour une requête en secondes. défaut 5
+tries=T Définit le nombre de tentatives UDP. défaut 3
+retry=T Définit le nombre de tentatives UDP. Défaut 2. idem à +tries mais n'inclue pas la requête initiale
+ndots=D Définis le nombre de points qui doivent apparaîtrent dans name.
+bufsize=B Définis le buffer du message UDP utilisant EDNS0
+edns=# Spécifie la version EDNS à utiliser +noedns efface la version
+[no]multiline Affiche les records comme les records SOA dans un format multi-ligne.
+[no]onesoa Affiche seulement un record SOA au départ en effectuant un AXFR. Défaut: affiche au départ et à la fin.
+[no]fail Ne retente pas le serveur suivant en cas d'une réponse SERVFAIL
+[no]besteffort Tente d'afficher le contenus des messages qui sont malformés
+[no]dnssec demande les records DNSSEC en mettant le bit DNSSEC OK (DO) dans le record OPT dans la section additionnelle de la requête
+[no]sigchase Poursuit les chaînes de signature DNSSEC.
+trusted-key=#### Spécifie un fichier contenant les clés de confiance à utiliser avec +sigchase. Sinon dig regarde /etc/trusted-key.key puis trusted-key.key dans le répertoire courant.
+[no]topdown en poursuivant les chaînes de signature DNSSEC, effectue une validation top-down
+[no]nsid Inclue un EDNS name server ID request en envoyant une requête.
+[no]keepopen Conserve le socket TCP ouvert entre les requête et le réutilise
+[no]sit[=####] Envois l'option SIT.
+[no]subnet=addr/prefix Envoie une option EDNS Client Subnet avec l'adresse IP ou le préfixe réseau spécifié
+[no]expire Envoie une option EDNS Expire. Actuellement en envoyant la valeur expérimentale 65002.

Requêtes multiple

   dig permet de spécifier plusieurs requêtes sur la ligne de comande ( en plus de l'option -f). Chacune de ces requêtes peut être fournie avec son propre jeux de flags, options et options de requêtes.

   Dans ce cas, chaque argument query représente une requête individuelle. Chacune consiste d'options et flags, le nom à rechercher, le type de requête et de classe et des options de requêtes.

Un jeu global d'options de requête, qui devrait être appliqué à toutes les requêtes peut également être spécifié. Ces options de requêtes globales doivent précéder la première requête. Les options de requêtes globales (excepté +cmd) peuvent être remplacées pas des options spécifiques à la requête.
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

   Cet exemple monte comment effectuer 3 rechercher: une requête ANY pour www.isc.org, une requête inversée pour 127.0.0.1, et une requête pour les enregistrement ns de isc.org

Support IDN

   dig intègre le support IDN (Internationalized Domain Name), et peut accepter et afficher les noms de domaine non-ASCII. Pour désactiver le support IDN, définir la variable IDN_DISABLE.
^
28 juin 2010

htmlpdflatexmanmd




dircolors

dircolors

dircolors sort une séquence de commande shell pour définir les couleurs pour la sortie de ls

   Si FILE est spécifié, dircolors le lit et détermine quelles couleurs utiliser pour quels types de fichiers et extensions, sinon une base de donnée précompilée est utilisée. Pour plus de détail sur le format de ce fichier : dircolors --print-database

OPTIONS

-b, --sh, --bourne-shell sort les commandes Bourne Shell. Par défaut si SHELL ne se termine pas par csh ou tcsh
-c, --csh, --c=shell Sort les commande C shell. par défaut si SHELL se termine par csh ou tcsh
-p, --print-database affiche la base de donnée des couleurs par défaut. Cette sortie est elle-même un fichier de configuration valide.

Exemples

utilisation typique
eval "`dircolors [OPTION]... [FILE]`"
Forcer dircolor à lire un fichier /.dircolors s'il existe, vous pouvez utiliser /.bashrc
d=.dircolors
test -r $d && eval "$(dircolors $d)"

Variables d'environnement

LS_COLORS La sortie de dircolors est une commande shell qui est définie dans cette variable
^
07 juillet 2010

htmlpdflatexmanmd




dirname

dirname

Affiche la partie répertoire dans le nom spécifié

Exemples

Affiche /usr/bin
dirname /usr/bin/sort
Affiche .
dirname stdio.h
^
31 mars 2017

htmlpdflatexmanmd




diskdevstat

diskdevstat

Outil d'enregistrement d'activité de disque dur

   diskdevstat est un script systemtap pour enregistrer l'activité disque des processus et affiche les statistiques pour les opérations de lecture/écriture

OPTIONS

update interval Définis l'interval d'échantillonage
total duration Définis le temps total de mesure en secondes
display histogram Si présent, l'histogramme sera affiché en fin de mesure
^
22 mars 2016

htmlpdflatexmanmd




dm-crypt

dm-crypt

Chiffrement transparent des périphériques block

   la cible crypt de Device-Mapper fournis un chiffrement transparent des périphériques blocks utilisant l'API crypto du kernel

Paramètres

cipher Algorithme de chiffrement et un mode de génération IV optionel (ex: des, aes-cbc-essip:sha256, twofish-ecb). /proc/crypto contient les modes crypto supportés
key Clé utilisée pour le chiffrement. Encodé en hexadécimal.
keycount Mode compatibilité multi-clé. On peut définis keycount clé et les secteurs sont chiffrés en accord avec leur offset (le secteur 0 utilise key0, etc.)
iv_offset L'offset IV est un compteur de secteur qui sont ajoutés au numéro du secteur avant de créer l'IV
device_path Périphérique qui est utilisé comme backend et contient la donnée chiffrée.
offset Secteur de départ dans le périphérique où les données chiffrée commencent
#opt_params Nombre de paramètres optionnels.

Paramètres optionnels

allow_discards Block discard request passé au périphérique crypté. Défaut: ignore ces requêtes
same_cpu_crypt Effectue le chiffrement en utilisant le même cpu que l'IO qui l'a émis.
submit_from_crypt_cpus Désactive l'écriture offload dans un thread séparé après le chiffrement. L'écriture bénéficie à CFQ, mais peut dégrader les performances dans certains cas.

Scripts d'exemple

LUKS (Linux Unified Key Setup) est la manière préférée pour définir le chiffrement de disque avec dm-crypt en utilisant l'utilitaire cryptsetup
[[
#!/bin/sh
# Crée un périphérique crypto avec dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]
    
[[
#!/bin/sh
# Crée un périphérique en utilisant cryptsetup et LUKS avec le chiffrement par défaut:
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]

^
06 avril 2014

htmlpdflatexmanmd




dmesg

dmesg

Affiche ou contrôle le tampon du kernel. Par défaut, lis tous les messages du tampon

OPTION

-C, --clear Vide la tampon
-c, --read-clear Efface de tampon après l'avoir affiché
-D, --console-off Désactive l'affichage des messages sur la console
-d, --show-delta Affiche le timestamp et le temps delta passé entre les messages.
-E, --console-on Affiche les messages sur la console
-f, --facility list Restreint la sortie à la listes des facilités définis
-k, --kernel Affiche les messages du kernel
-l, --level list Restreint la sortie à la liste des level définis
-n, --console-level level Définis le niveau dont le log des messages est fait sur la console. Par exemple, -n 1 ou -n alert empêche tous les messages à l'exception des messages d'urgence (panic) sur la console. Tous les niveau d'alerte continuent d'être écris dans /proc/kmsg.
-r, --raw Affiche le tampon en brut
-s, --buffer-size size Spécifie la taille du tampon. Défaut: 16392.
-T, --ctime Affiche les timestamp en human-readable
-t, --notime n'affiche pas les timestamps du kernel
-u, --userspace Affiche les messages de l'espace utilisateur
-x, --decode Décode les numéro de level et de facilité en préfixe human-readable
^
16 juin 2016

htmlpdflatexmanmd




dmeventd

dmeventd

Service d'événements Device-mapper

   dmeventd est le service de supervision d'événements pour les périphériques dm. Les librairies peuvent s'enregistrer et gérer les actions quand des événements particuliers se produisent.

LVM plugins

Mirror Tente le gérer les erreurs disque automatiquement
Raid Tente le gérer les erreurs disque automatiquement
Snapshot Supervise la taille d'un snapshot et émet une alerte à syslog quand il excède 80%, répété à 85%, 90% et 95%.
Thin Supervise la taille d'un pool thin et émet une alerte à syslog quand il excède 80%, répété à 85%, 90% et 95%.

OPTIONS

-d, -dd, -ddd Augmente les détailles des messages de debuggage envoyés à syslog.
-F Ne lance pas en tâche de fond
-l Uniquement avec -f. Log sur stdout et stderr au lieu de syslog.
-R Remplace une instance dmeventd en cours de fonctionnement
^
25 avril 2017

htmlpdflatexmanmd




dmevent_tool

dmevent_tool

Utilitaire pour (dé)enregistrer les DSO avec dmeventd

OPTIONS

-m[r|u] Liste tous les périphériques dm actifs enregistrés (r), ou désenregistrés (u)
-a[r|u] Idem pour pour des périphériques avec UUID uniquement.
-r Enregistre un périphérique avec dmeventd
-u Désenregistre un périphérique avec dmeventd
^
18 mars 2016

htmlpdflatexmanmd




dnssec-checkds

dnssec-checkds

Vérification de consistance de délégation DNSSEC

   dnssec-checkds vérifie le validité des enregistrements DS (Delegation Signer) ou DLV (DNSSEC Lookaside Validation) pour les clés dans une zone spécifiée.

OPTIONS

-f file Lis la zone depuis ce fichier pour trouver les records DNSKEY, sinon recherche les records dans le DNS.
-l domain Vérifie le record DLV dans le domaine spécifié, au lieu de vérifier un DS dans la zone du parent.
-d dig path Spécifie un chemin du binaire dig.
-D dsfromkey path Spécifie un chemin du binaire dnssec-dsfromkey.
^
18 mars 2016

htmlpdflatexmanmd




dnssec-coverage

dnssec-coverage

Vérifie la couverture DNSKEY future pour une zone

   Vérifie que les clés DNSSEC pour une zone donnée ou un jeu de zones ont des métadonnées de timing correct pour s'assurer qu'aucune défaillance future dans la couverture DNSSEC.

   Si la zone est spécifiée, les clés trouvée dans le dépôt de clé correspondant à cette zone sont scannés, et une liste ordonnée est générée de l'événement planifié pour cette clé (publication, activation, inactivation, suppression). La liste d'événements est suivie dans l'ordre d'occurrence. Des alertes sont générées si des événements sont planifiées qui causeraient la zone d'entrer dans un état d'erreur de validation.
   Si la zone n'est pas spécifiée, toutes les clé dans le dépôt de clé seront scannées, et toutes les zones pour lesquelles il y a des clé seront analysées.

OPTIONS

-K directory Répertoire où trouver les clé.
-f file Si spécifié, la zone est lu depuis ce fichier
-l duration La durée pour la vérification de couverture DNSSEC.
-m maximum TTL Définis la valeur à utiliser comme TTL max pour la ou les zones à analyser pour déterminer s'il y a une erreur de validation possible
-d DNSKEY TTL Définis la valeur à utiliser comme DNSKEY TTL pour la ou les zones à analyser.
-r resign interval Définis la valeur à utiliser comme intervalle de re-signature pour la zone.
-k Vérifie seulement la couverture KSK
-z Vérifie seulement la couverture ZSK
-c compilezone path Spécifie un chemin du binaire named-compilezone
^
18 mars 2016

htmlpdflatexmanmd




dnssec-dsfromkey

dnssec-dsfromkey

Outil de génération de DS RR

   dnssec-dsfromkey affiche le DS RR (Delecation Signer Resource Record) comme définis dans la rfc3658 et la rfc4509, pour les clé données.

OPTIONS

-1 Utilise SHA-1 (utilise SHA-1 et SHA-256 par défaut)
-2 Utilise SHA-256
-a algorithm Séléctionne l'algorithme. peut être SHA1, SHA256, SHA-384, ou GOST
-T TTL Spécifie le TTL opur les records DS
-K directory Répertoire contenant les fichiers de clé
-f file mode fichier de zone : à la place du nom de fichier de clé, l'argument est le nom de domaine d'un fichier de zone maître, qui peut être lu depuis le fichier spécifié
-A Inclue ZSK en générant les records DS. Sans cette option, seul les clés qui ont le flag KSK mis sera convertis en record DS et affiché. Utile uniquement en mode fichier de zone.
-l domain Génère un jeu DLV (DNSSEC Lookaside Validation) au lieu d'un jeu DS. Le domaine spécifié est ajouté au nom pour chaque record dans le jeu
-s mode Keyset : à la place du nom de fichier clé, l'argument est un nom de domaine d'un fichier keyset
-c class Spécifie la classe DNS
-v level spécifie le niveau de debug

Exemples

Pour construire le SHA-256 DS RR depuis le nom de fichier Kexample.com.+003+26160 :
dnssec-dsfromkey -2 Kexample.com.+003+26160
La commande affichera
example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A
^
18 mars 2016

htmlpdflatexmanmd




dnssec-importkey

dnssec-importkey

Importe les records DNSKEY depuis des système externe pour qu'ils puissent être gérés

   Il lit un record DNSKEY publique et génère une paire de fichiers .key/.private. Le record DNSKEY peut être lu depuis un fichier .key existant, auquel cas un fichier .private sera généré, ou peut être lu depuis un autre fichier ou depuis l'entrée standard, auquel cas les fichiers .key et .private seront générés.

   Le nouveau fichier .private créé ne contient pas de donnée de clé privée, et ne peut pas être utilisée pour signer. Cependant,avoir un fichier .private rend possible les durées de publication (-P) et de suppression (-D) pour la clé, ce qui signifie que la clé publique peut être ajoutée et supprimée du DNSKEY RRset avec un événement planifié si la vrai clé privée est stockée offline.

OPTIONS

-f filename Mode fichie de zone. Au lieu d'un nom de fichier keyfile, l'argument est un nom de domaine DNS d'un fichie de zone maître, qui est lus depuis le fichier spécifié. à '-', les données de zones sont lue depuis l'entrées standard.
-K directory Répertoire où trouver les clé
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie en DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisé, sauf si elle a déjà un RRset, auquel cas le TTL existant aura précédence. à '0' ou 'none' le supprime
-v level Définis le niveau de debug
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'
^
18 mars 2016

htmlpdflatexmanmd




dnssec-keyfromlabel

dnssec-keyfromlabel

Outil de génération de clé crypto hardware DNSSEC

   dnssec-keyfromlabel génère des fichiers de paire de clé qui référence un objet clé stocké dans un module cryptographique (HSM). Le fichier de clé privée peut être utilisé pour signer une zone de donnée comme si elle était une clé de signature conventionnelle créé par dnssec-keygen, mais la clé est stockée dans le HSM.

   Le nom de la clé est spécifié sur la ligne de commande. Il doit correspondre au nom de la zone pour laquelle la clé est générée.

OPTIONS

-a algorithm Sélectionne l'algorithme cryptographique (RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256, ou ECDSAP384SHA384). Défaut: RSASHA1.
-3 Utilise un algorithme capable de gérer NSEC3 opur générer une clé DNSSEC. Défaut: NSEC3RSASHA1
engine Spécifie le hardware cryptographique à utiliser
-l label Spécifie le label pour une paire de clé crypto hardware
nametype Spécifie le type propriétaire de la clé. ZONE (pour une clé de zone DNSSEC), HOST, ou ENTITY (pour une clé associée avec un hôte), USER (pour une clé associée avec un utilisateur), ou OTHER (DNSKEY)
-C Mode compatibilité: génère des clé ancien style, dans métadonnée.
-c class Indique que le record DNS contenant la clé devrait avoir la classe spécifiée. Défaut: IN
-f flag Définis le flag spécifié dans le champ flag du record KEY/DNSKEY. Les seuls flags reconnus sont KSK et REVOKE
-G Génère une clé, mais ne la publie pas et ne signe rien avec. Incompatible avec -P et -A
-K directory Définis le répertoire dans lequel les fichiers sont écris
-k Génère des records KEY au lieu de DNSKEY
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence.
-p protocol Définis la valeur protocol pour la clé. Le protocol est un nombre entre 0 et 255. Défaut: 3 (DNSSEC). D'autres valeurs possible sont listées dans la rfc2535 et ses successeurs.
-S key Génère une clé comme successeur explicite d'une clé existante. Le nom, l'algorithme, la taille, et le type de clé doivent matcher le prédécesseur. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-t type Indique l'utilisation de la clé. AUTHCONF, NOAUTHCONF, NOAUTH, ou NOCONF. Défaut: AUTHCONF. AUTH réfèrre à la capacité d'authentifier les données, et CONF à la capacité de chiffrer les données.
-v level Définis le niveau de debug
-y Permet de générer des fichiers de clé DNSSEC même si l'ID de clé est en colision avec une clé existante, dans le cas d'une clé à révoquer.
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-i interval Définis l'interval de pré-publication pour une clé.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'

Fichiers générés

   Les fichier de clé générés sont nommés sous la forme Knnnn.+aaa+iiiii. Cette chaîne d'identification signifie:

nnnn Est le nom de la clé
aaa La représentation numérique de l'algorithme
iiiii L'identifiant de clé (ou empreinte)

   dnssec-keyfromlabel créé 2 fichiers, avec des noms basés sous la forme Knnnn.+aaa+iiiii.key et Knnnn.+aaa+iiiii.private. Le fichier .key contient un record DNS KEY qui peut être inséré dans un fichier de zone, et le fichier .private contient les champs spécifiques à l'algorithme. Ce fichier n'a pas de permission de lecture.
^
18 mars 2016

htmlpdflatexmanmd




dnssec-keygen

dnssec-keygen

Outil de génération de clé DNSSEC

   dnssec-keygen génère de clé pour DNSSEC, tel que définis dans la rfc2535 et la rfc4034. Il peut également générer des clé pour TSIG tel que définis dans la rfc2845, ou TKEY tel que définis dans la rfc2930. Le nom de la clé est spécifié sur la ligne de commande. Pour les clés DNSSEC, il doit correspondre au nom de la zone pour laquelle la clé est générée.

OPTIONS

-a algorithm Sélectionne l'algorithme cryptographique (RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256, ou ECDSAP384SHA384). Pour TSIG/TKEY, la valeur doit être DH, HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, ou HMAC-SHA512. Défaut: RSASHA1.
-b keysize Spécifie la taille de la clé.
nametype Spécifie le type propriétaire de la clé. ZONE (pour une clé de zone DNSSEC), HOST, ou ENTITY (pour une clé associée avec un hôte), USER (pour une clé associée avec un utilisateur), ou OTHER (DNSKEY)
-3 Utilise un algorithme capable de gérer NSEC3 opur générer une clé DNSSEC. Défaut: NSEC3RSASHA1
-C Mode compatibilité: génère des clé ancien style, dans métadonnée.
-c class Indique que le record DNS contenant la clé devrait avoir la classe spécifiée. Défaut: IN
engine Spécifie le hardware cryptographique à utiliser
-f flag Définis le flag spécifié dans le champ flag du record KEY/DNSKEY. Les seuls flags reconnus sont KSK et REVOKE
-G Génère une clé, mais ne la publie pas et ne signe rien avec. Incompatible avec -P et -A
-g generator En générant une clé DH, utilise ce générateur. peut être entre 2 et 5.
-K directory Définis le répertoire dans lequel les fichiers sont écris
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence.
-p protocol Définis la valeur protocol pour la clé. Le protocol est un nombre entre 0 et 255. Défaut: 3 (DNSSEC). D'autres valeurs possible sont listées dans la rfc2535 et ses successeurs.
-q Mode silencieux. Supprime la sortie non-nécessaire
-r randomdev Spécifie la source de nombre aléatoire.
-S key Génère une clé comme successeur explicite d'une clé existante. Le nom, l'algorithme, la taille, et le type de clé doivent matcher le prédécesseur. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-s strength Spécifie la valeur de force de clé. La force est un nombre entre 0 et 15, et n'a aucun but définis dans DNSSEC actuellement
-T rrtype Spécifie le type de RR à utiliser pour la clé. DNSKEY ou KEY.
-t type Indique l'utilisation de la clé. AUTHCONF, NOAUTHCONF, NOAUTH, ou NOCONF. Défaut: AUTHCONF. AUTH réfèrre à la capacité d'authentifier les données, et CONF à la capacité de chiffrer les données.
-v level Définis le niveau de debug
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-i interval Définis l'interval de pré-publication pour une clé.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'

Fichiers générés

   Les fichier de clé générés sont nommés sous la forme Knnnn.+aaa+iiiii. Cette chaîne d'identification signifie:

nnnn Est le nom de la clé
aaa La représentation numérique de l'algorithme
iiiii L'identifiant de clé (ou empreinte)

   dnssec-keyfromlabel créé 2 fichiers, avec des noms basés sous la forme Knnnn.+aaa+iiiii.key et Knnnn.+aaa+iiiii.private. Le fichier .key contient un record DNS KEY qui peut être inséré dans un fichier de zone, et le fichier .private contient les champs spécifiques à l'algorithme. Ce fichier n'a pas de permission de lecture.

Exemples

Génerer une clé DSA 768bits pour le domaine example.com
dnssec-keygen -a DSA -b 768 -n ZONE example.com
^
18 mars 2016

htmlpdflatexmanmd




dnssec-revoke

dnssec-revoke

Révoquer des clés DNSSEC. Définis le bit REVOKED dans une clé DNSSEC

OPTIONS

-K directory Répertoire où trouver les clé
-r Après écriture, supprime les fichiers keyset originaux
-v level Définis le niveau de debug
engine Spécifie le hardware cryptographique à utiliser
-f Force l'écrasement
-R Affiche le tag de clé de la clé avec le bit REVOKE mais ne révoque pas la clé
^
18 mars 2016

htmlpdflatexmanmd




dnssec-settime

dnssec-settime

Définis les métadonnées de temps pour une clé DNSSEC

   dnssec-settime lit une clé privée DNSSEC et définis les métadonnées de temps spécifié. Ces métadonnées peuvent être utilisées par dnssec-signzone pour déterminer quand une clé doit être publiée, si elle devrait être utilisée pour signer une zone, etc. Sans options de temps, affiche simplement la métadonnée de temps déjà stockées dans la clé. Quand les champs sont changés, les fichiers sont regénérés.

OPTIONS

-f Force une mise à jours pour une clé au format ancien sans métadonnée.
-K directory Répertoire où trouver les clé
-v level niveau de debug
engine Spécifie le hardware cryptographique à utiliser
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence. 0 ou none pour la supprimer
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-S predecessor key Sélectionne un clé pour laquel la clé modifiée sera un successeur explicite. Le nom, l'algorithme, la taille et le type de clé doivent correspondre. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-i interval Définis l'interval de pré-publication pour une clé.
-u Affiche les dates au format UNIX epoch
-p C/P/A/R/I/D/all Affiche une valeur de métadonnée spécifique ou toutes les valeurs. C (date de création), P (date de publication), A (date d'activation), R (Date de révocation), I (date de désactivation), D (Date de suppression).

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'
^
18 mars 2016

htmlpdflatexmanmd




dnssec-signzone

dnssec-signzone

Outil de signature de zone DNSSEC

   dnssec-signzone permet de signer une zone. Il génère des records NSEC et RRSIG et produit une version signée de la zone. Le status de sécurité de la zone signée (c'est à dire si les zones enfants sont sécurisées ou non) est déterminé par la présence ou l'absence d'un fichier keyset pour chaque zone enfant.

OPTIONS

-a Vérifie toutes les signatures générées
-c class Spécifie la classe de la zone
-C mode compatibilité : génère un fichier keyset-zonename en plus de dsset-zonename utilisé par d'anciennes versions de dnssec-signzone
-d directory Répertoire où trouver les fichier dsset- ou keyset-
-D Affiche seulement les type de record automatiquement gérés par dnssec-signzone, ex RRSIG, NSEC, NSEC3 et NSEC3PARAM.
engine Hardware cryptographique à utiliser.
-g Génère les records DS pour les zones enfant depuis le fichier dsset- ou keyset-. Les records DS existant seront supprimés.
-K directory Répertoire où trouver les clés
-k key Traite la clé spécifiée comme clé de signature de clé en ignorant les flags de clé. Peut être spécifié plusieurs fois.
-l domain Génère un set DLV en plus d'un set DS. Le domain spécifié est ajouté au nom des records.
-M maxttl Définis le TTL maximum pour la zone signée. Un TTL supérieur sera réduit à cette valeur dans la sortie.
-s start-time Spécifie la date et l'heure où les records RRSIG deviennent valides
end-time Spécifie la date et l'heure où les records RRSIG expirent.
-X extended end-time Spécifie la date à laquelle les records RRSIG pour le DNSKEY RRset expire. Utilisé dans les cas où les signature DNSKEY doivent persister plus longtemp que les signatures dans d'autres records.
-f output-file Le nom du fichier de sortie contenant la zone signée. par défaut, ajoute .signed au nom du fichier d'entrée.
-i interval Quand un zone précédemment signée est passée en entrée, les records peuvent être resignés. Spécifie le cycle d'interval relatif à l'heure courante (en secondes).
-I input-format Le format du fichier de zone en entrée. peut être text ou raw.
-j jitter En signant une zone avec une durée de vie de signature fixe, tous les records RRSIG émis à la date d'expiration de signature expire en même temps. Si la zone est signée incrémentalement, toutes les signatures expirées doivent être générées au même moment. Cette option spécifie une fenêtre qui est utilisée pour rendre la date d'expiration aléatoire.
-L serial En écrivant une zone signée au format raw ou map, définis la valeur source serial dans l'en-tête à la valeur spécifiée.
ncpus Spécifie le nombre de threads à utiliser. Défaut: 1 thread par CPU
-N soa-serial-format Format du sérial SOA. Peut être keep (ne modifie pas le sérial), increment (incrément le SOA en utilisant l'arithmétique rfc1982) et unixtime(définis le sérial au temps epoch)
-o origin La zone d'origine. Si non spécifié, le nom du fichier de zone est assumé.
-O output-format Le format du fichier de sortie contenant la zone signée. Peut être text (défaut), full (format text utilisable pour le traitement pas des scripts), map, raw, et raw=N où N spécifie la version du format. à 0, le fichier peut être lu pat toute version, à 1 le fichier ne peut être lu que pas la version 9.9.0 ou supérieur. Défaut: 1.
-p Utilise des données pseudo-aléatoire en signant la zone. C'est plus rapide mais moins sécurisé.
-P Désactive le teste de vérification de signature
-Q Supprime les signatures depuis les clés qui ne sont plus actives.
-R Supprime les signatures des clés qui ne sont plus publiées
-r randomdev Spécifie la source de random
-S Recherche dans le répertoire de clés, les clés correspondant à la zone à signer, et les inclus dans la zone si approprié.
-T ttl Spécifie le ttl à utiliser pour les nouveaux records DNSKEY importés dans la zone.
-t Affiche les statistiques une fois terminé
-u Met à jour la chaîne NSEC/NSEC3 en re-signant une zone précédemment signée. Avec cette option, une zone signée avec NSEC peut passer en NSEC3, ou une zone signée avec NSEC3 peut passer en NSEC ou en NSEC3 avec des paramètres différents.
-v level Définis le niveau de debug
-x Signe uniquement le DNSKEY RRset avec les clés key-signing, et omet les signatures des clés zone-signing
-z Ignore le flag KSK dans la clé en déterminant quoi signer. Celà force les clés avec le flag KSK de signer tous les records, pas seulement le DNSKEY RRset.
-3 salt Génère une chaîne NSEC3 avec le salt spécifié (en hexa). Un point peut être utilisé pour indiquer qu'aucun 'salt' n'est utilisé.
-H iterations En générant une chaîne NSEC3, utilise le nombre d'itérations spécifié, 10 par défaut.
-A En générant une chaîne NSEC3, met le flag OPTOUT dans tous les records NSEC3 et ne génère pas de records NSEC3 pour les délégations non sécurisées. -AA désactive le flag OPTOUT pour tous les records, utile avec l'option -u
zonefile Le fichier contenant la zone à signer key
Spécifie quelle clé doit être utilisée pour signer la zone. Sinon recherche les records DNSKEY de la zone.

Exemples

Signer la zone example.com avec la clé DSA générée par dnssec-keygen (Kexample.com.+003+17247).
dnssec-signzone -g -o example.com db.example.com Kexample.com.+003+17247
Re-signer une zone précédemment signée avec les paramètres par défaut. Assume que la clé privée est dans le répertoire courant
cp db.example.com.signed db.example.com
dnssec-signzone -o example.com db.example.com
^
18 mars 2016

htmlpdflatexmanmd




dnssec-verify

dnssec-verify

Outil de vérification de zone DNSSEC

   dnssec-verify vérifie qu'une zone est entièrement signée pour chaque algorithme trouvé dans le RRset DNSKEY pour la zone, et que les chaînes NSEC/NSEC3 sont complètes.

OPTIONS

-c class Spécifie la clé DNS de la zone
engine Hardware cryptographique à utiliser
-I input-format Format du fichier d'entrée text ou raw
-o origin Origine de la zone. Si non spécifié, le nom du fichier de zone est utilisé
-v level niveau de debug
-x Vérifie uniquement le le RRset DNSKEY est signé avec la clé de signature de clé. Dans ce flag, assume de ce RRset est signé par toutes les clé actives.
-z Ignore le flag KSK dans les clé en déterminant si la zone est correctement signée.
^
13 mars 2016

htmlpdflatexmanmd




docker

docker

Interface de gestion d'image et de conteneur

   docker a 2 fonctions distincts. Il est utilisé pour démarrer le service Docker et de lancer l'interface en ligne de commande. Docker est donc à la fois un serveur et un client. docker daemon lance le service docker. Le CLI a 30 commandes. Les commandes sont listées ci-dessous et chacun a sa propre page d'aide.

OPTIONS

--config="" Spécifie l'emplacement des fichiers de configuration du client docker. Défaut: /.docker
-D, --debug=true|false Active le mode débug. Défaut: false
-H, --host=[unix:///var/run/docker.sock]: tcp:[host]:[port][path] ou unix://[/path/to/socket] Les sockets d'écoute en mode service. Si le port tcp n'est pas spécifié, le défaut est 2375 quand --tls est off, ou 2376 qui --tls est on, ou --tlsverify est spécifié.
-l, --log-level="debug|info|warn|error|fatal" Définis le niveau de log. Défaut: info
--tls=true|false Utilise TLS; implique --tlsverify. Défaut: false
--tlscacert=/.docker/ca.pem Ne valide que les certificats signés par cette CA
--tlscert=/.docker/cert.pem Certificat à utiliser
--tlskey=/.docker/key.pem Clé TLS
--tlsverify=true|false Utilise TLS et vérifie le paire. Défaut: false

Commandes

attach Attache au conteneur en cours
build Construit une image depuis un Dockerfile
commit Créé une nouvelle image depuis les changements d'un conteneur
cp copie les fichiers/répertoires entre un conteneur et le système de fichier local.
create Créer un nouveau conteneur
diff inspect les changements dans le système de fichier d'un conteneur
events Lis les événements temps réel depuis le serveur
exec Lance une commande dans un conteneur
export Envoie le contenu d'un conteneur comme archive tar
history Affiche l'historique d'une image
images Liste les images
import Créer un nouveau système de fichier image depuis le contenu d'un tar.
info Affiche des informations du système
inspect Retourne des informations bas niveau d'un conteneur ou d'une image
kill Termine un conteneur.
load Charge une images depuis une archive tar
login Se logger à un registre Docker
logout terminer la session d'un registre Docker
logs Rapporte les logs d'un conteneur
pause Pause tous les processus dans un conteneur
port Recherche le port publique qui est natté à un port privé
ps Liste les conteneurs
pull récupère une image ou un dépôt d'un registre Docker
push envoie une image ou un dépôt d'un registre Docker
rename Renomme un conteneur
restart Redémarre un conteneur
rm Supprime un ou plusieurs conteneurs
rmi Supprime une ou plusieurs images
run Lance une commande dans un nouveau conteneur
save Sauve une image dans une archive tar
search Recherche une image dans l'index Docker
start Démarrer un conteneur
stats Affiche un flux de statistiques d'utilisation de ressource d'un ou plusieurs conteneurs
stop Stop un conteneur
tag Tag une image dans un dépôt
top Voir les processus fonctionnant dans un contenant
unpause Résume un conteneur en pause
version Affiche les informations de version de docker
wait Block jusqu'à ce que le conteneur s'arrête, et affiche son code de sortie.

Options du pilote exec

   Utiliser l'option --exec-opt permet de spécifier des options pour le pilote d'exécution. Les options suivantes sont disponibles:

native.cgroupdriver Spécifie a gestion des cgroups du conteneur. peut être cgroupfs ou systemd.
Client voir man docker-run
^
13 mars 2016

htmlpdflatexmanmd




docker-attach

docker-attach

Attache un conteneur en cours d'exécution

   docker attach permet d'attacher une conteneur en cours d'exécution en utilisant l'ID du conteneur ou son nom, soit pour voir sa sortie, soit pour contrôler son interactivité. On peut attacher le même processus plusieurs fois simultanément. Pour stopper un conteneur, utiliser CTRL-c. Cette séquence de touche envoie SIGKILL au conteneur. On peut détacher un conteneur en utilisant une séquence de touches (défaut: CTRL-p CTRL-q). On peut configurer la séquence de touche en utilisant l'option --detach-keys ou un fichier de configuration. Il est interdit de rediriger l'entrée standard d'une commande docker attach en attachant un conteneur tty (lancé avec -t).

OPTIONS

--detach-keys="" Change la séquence de touche pour détacher le conteneur. Défaut: CTRL-p CTRL-q.
--no-stdin=true|false N'attache pas STDIN. défaut: false
--sig-proxy=true|false signaux proxy reçus au processus (mode non-TTY uniquement). SIGCHLD, SIGSTOP, SIGKILL ne sont pas proxifiés.

Exemples

Atacher un conteneur:
ID=$(sudo docker run -d fedora /usr/bin/top -b)
sudo docker attach $ID
^
13 mars 2016

htmlpdflatexmanmd




docker-build

docker-build

Construire une image depuis le code source

   Cette commande lit un Dockerfile depuis le répertoire spécifié. Il a besoin également d'autres fichiers et répertoires trouvés dans le répertoire courant du service docker. Le contenu de ce répertoire sera utilisé par les commandes AD dans le Dockerfile.

   Note, cela envoie beaucoup de données au service Docker en fonction du contenu du répertoire courant. La construction est lancé par le service Docker, par par le client, donc tout le contexte doit être transféré au service. Le client affiche "Sending Build context to Docker daemon" quand le contexte est envoyé au service.

   Quand l'URL d'une archive tar ou un simple Dockerfile est donné, aucun contexte est envoyé au service. Dans ce cas, le Dockerfile à la racine de l'archive et le reste de l'archive seront utilisé comme contenu de construction. Dans un dépôt git est utilisé comme url, le dépôt est cloné localement et envoyé comme contexte.

OPTIONS

-f, --file=PATH/Dockerfile Chemin du fichier Dockerfile à utiliser.
--build-arg=variable Nom et valeur d'un buildarg. Docker les utilise comme contexte d'environnement via l'instruction RUN du dockerfile.
--force-rm=true|false Supprime les conteneurs intermédiaires, même après des constructions échouées. défaut: false
--isolation="default" spécifique le type de technologie d'isolation utilisée par les conteneurs
--no-cache=true|false Ne pas utiliser de cache pour construire l'image. Défaut: false
--pull-true|false Tente de récupérer une version plus récente de l'image. défaut: false
-q, --quiet=true|false Supprime la sortie de la construction et affiche l'ID de l'image en cas de succès. Défaut: false
--rm=true|false Supprime les conteneurs intermédiaire en cas de réussite. Défaut: true.
-t, --tag="" Noms de dépôts (et optionnellement avec tag) à appliquer à l'image résultante en cas de succès.
-m, --memory=MEMORY Limite mémoire
--memory-swap="LIMIT" Une valeur limite égale à la mémoire plus le swap. Doit être utilisé avec -m.
--shm-size="" Taille de /dev/shm. format: ‹number›‹unit›
--cpu-shares=0 Partage CPU
--cpu-period=0 Limite la période CFS
--cpu-quota=0 Lisite le quota CPU CFS
--cpuset-mems="" Nœuds mémoire autorisés.
--cpuset-cpus=CPUSET-CPUS CPU dans lesquels autoriser l'exécution
--cgroup-parent="" Chemin des cgroups sous lesquels créer le conteneur. Si le chemin n'est pas absolu, le chemin est relatif aux cgroups du processus init.
--ulimit=[] Options ulimit
-v|--volume[=[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]]

Exemples

Construire une image en utilisant un Dockerfile dans le répertoire courant:
docker build .
Construire une image et nommer cette image
docker build -t myimage .
Une meilleur approche est de nommer le répertoire, nom et tag:
docker build -t fedora/jboss:1.0
Construire une image avec une URL:
docker build github.com/scollier/purpletest
Construire une image en utilisant une URL dans un contexte tar
docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz
^
13 mars 2016

htmlpdflatexmanmd




docker-commit

docker-commit

Créer une nouvelle image depuis les changements d'un conteneur

   Crée une nouvelle image depuis un conteneur existant. La nouvelle image contient le contenu du système de fichier du conteneur, excluant tous volumes de données. Cette commande est utile pour étendre une image existante.

OPTIONS

-a, --author="" Auteur
-c, --change=[] Applique les instruction Dockerfile spécifiés. (CMD|ENTRYPOINT|ENV|EXPOSE|LABEL|ONBUILD|USER|VOLUME|WORKDIR)
-m, --message="" Message d'envoie
-p, --pause=true|false Met en pause le conteneur durant le commit. Défaut: true.

Exemples

Créer une nouvelle image depuis un conteneur existant:
docker commit -m="Added Apache to Fedora base image" -a="A D Ministrator" 98bd7fc99854 fedora/fedora_httpd:20
Appliquer les instruction Dockerfile spécifiés:
docker commit -c="ENV DEBUG true" 98bd7fc99854 debug-image
^
13 mars 2016

htmlpdflatexmanmd




docker-cp

docker-cp

Copier des fichiers/répertoires entre un conteneur et le système de fichier local

   copie le contenue de SRC_PATH vers DEST_PATH. Permet de copier le système de fichier d'un conteneur dans la machine locale et inversement. Si - est spécifié, permet d'envoyer une archive tar depuis STDIN ou vers STDOUT. Le conteneur peut être en cours d'exécution ou arrêté. docker cp assume que les chemins de conteneurs soient relatif au répertoire racine. Cette commande agit comme la commande cp -a (récursif et préservation des permissions)

   Un ':' est utilisé pour délimiter le conteneur et son chemin, par exemple: `/path/to/file:name.txt` or `./file:name.txt`. Il n'est pas possible de copier certains fichiers système tels que /proc, /sys, /dev, et les montages créé par l'utilisateur dans le conteneur.

OPTIONS

-L, --folow-link=true|false Suit les liens symboliques

Exemples

Supposons un conteneur ayant finis de produire un fichier dans son système de fichier. Il peut être sortis via:
docker cp mycontainer:tmp/foo /tmp
^
13 mars 2016

htmlpdflatexmanmd




docker-create

docker-create

Créer un nouveau conteneur

   Créér un nouveau conteneur basé sur l'image spécifiée et la prépare pour excécuter la commande spécifiée. L'ID du conteneur est affiché sur STDOUT. C'est similaire à docker run excepté que le conteneur n'est jamais démarré. Le status initial du conteneur créé avec docker create est 'created'

OPTIONS

-a, --attach=[] Attache à STDIN, STDOUT ou STDERR. En mode foreground.
--add-host=[] Ajoute un mappage host-to-IP personnalisé (host:ip). Ajoute une ligne à /etc/hosts. peut être spécifié plusieurs fois.
--blkio-weight=0 Poid IO entre 10 et 1000
--blkio-weight-device=[] Poid IO au format DEVICE_NAME:WEIGHT
--cpu-shares=0 Partage CPU
--cap-add=[] Ajouter des capabilities Linux
--cap-drop=[] Supprimer de capabilities Linux
--cgroup-parent="" Chemin des cgroups sous lesquels créer le conteneur. Si le chemin n'est pas absolu, le chemin est relatif aux cgroups du processus init.
--cidfile="" Écrit l'ID de conteneur dans le fichier
--cpu-period=0 Limite la période CFS
--cpuset-cpus=CPUSET-CPUS CPU dans lesquels autoriser l'exécution
--cpuset-mems="" Nœuds mémoire autorisés.
--cpu-quota=0 Limite le quota CPU CFS
-d, --detach=true|false Lance de conteneur en tâche de fond et affiche l'ID du conteneur. défaut: false
--detach-keys="" Change la séquence de touche pour détacher le conteneur. Défaut: CTRL-p CTRL-q.
--device=[] Un périphérique hôte pour le conteneur (ex --device=/dev/sdc:/dev/xvdc:run)
--device-read-bps=[] Limite le taux de lecture d'un périphérique ( ex --device-read-bps=/dev/sda:1mb)
--device-read-iops Limite le taux de lecture d'un périphérique (ex --device-read-iops=/dev/sda:1000)
--device-write-bps=[] Limite le taux d'écriture d'un périphérique ( ex --device-write-bps=/dev/sda:1mb)
--device-write-iops Limite le taux d'écriture d'un périphérique (ex --device-write-iops=/dev/sda:1000)
--dns-search=[] Définis les domaines de recherche DNS.
--dns-opt=[] Définis les options DNS
--dns=[] Définis les serveurs DNS
-e, --env=[] Définis des variables d'environnement.
--entrypoint="" Remplace l'ENTRYPOINT de l'image
--env-file=[] Line un fichier de variables d'environnements
--expose=[] Expose un port, une une plage de ports informant Docker que le conteneur écoute sur les ports spécifiés. Docker utilise cette information pour interconnecter les conteneurs en utilisant des liens et pour définir la redirection de port dans le système hôte.
--group-add=[] Ajoute des groupes additionnels à lancer
-h, --hostname="" nom d'hôte du conteneur
-i, --interactive=true|false Garde STDIN ouvert même s'il n'est pas attaché. défaut: false
--ip="" Définis l'adresse IPv4 de l'interface du conteneur, uniquement avec --net pour les réseaux utilisateurs
--ip6="" Définis l'adresse IPv6 de l'interface du conteneur, uniquement avec --net pour les réseaux utilisateurs
--ipc="" Créé un espace de nom IPC privé pour le conteneur
--isolation="default" spécifique le type de technologie d'isolation utilisée par les conteneurs
-l, --label=[] Définis les métadonnées du conteneur (ex: --label com.example.key=value)
--kernel-memory="" Limit la mémoire kernel. (0 = illimité)
--label-file=[] Lit un fichier de labels
--link=[] Ajoute un lien vers un autre conteneur sous la forme ‹nom ou id›:alias.
--log-driver="json-file|syslog|journald|gelf|fluentd|awslogs|splunk|none" Pilote de logging pour le conteneur. La commande docker logs ne fonctionne que pour les pilotes json-file et journald.
--log-opt=[] options spécifique au pilote de logging
-m, --memory="" Limite mémoire
--memory-reservation="" Limite soft
--memory-swap="LIMIT" Une valeur limite égale à la mémoire plus le swap. Doit être utilisé avec -m.
--mac-address="" L'adresse mac de conteneur
--name="" Assigne un nom au conteneur au format UUID long, UUID court, ou un nom.
--net="bridge" Définis le mode réseau pour le conteneur (bridge, none, container:‹name|id›, host, ‹network-name›|‹network-id›
--net-alias=[] ajoute un alias réseau pour le conteneur
--oom-kill-disable=true|false Active ou non le OOM Killer pour le conteneur
--oom-score-adj="" Ajustement OOM de l'hôte pour le conteneur (-1000 à 1000)
-P, --publish-all=true|false Publie tous les ports exposés aux ports aléatoire dans les interfaces de l'hôte. Défaut: false
-p, --publish=[] Publie le port d'un conteneur, ou une plage de port, à l'hôte (Format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort)
--pid=host Définis de mode PID pour le conteneur (host: utilise l'espace de nom PID de l'hôte, non sécurisé)
--uts=host Définis le mode UTS pour le conteneur (host: utilise l'espace de noms UTS dans le conteneur, non sécurisé)
--privileged=true|false Donne des priviléges étendus à ce conteneur. Défaut: false
--read-only=true|false Mounte le système de fichier racine du conteneur en lecture seule.
--restart="no" Stratégie de redémarrage quand le conteneur se termine. (no, on-failure[:max-retry], always, unless-stopped)
-rm=true|false Supprime automatiquement le conteneur quand il se termine. incompatible avec -d. défaut: false
--security-opt=[] Options de sécurité
--stop-signal=SIGTERM Signal pour stopper un conteneur
--shm-size="" Taille de /dev/shm. format: ‹number›‹unit›
-t, --tty=true|false Alloue un pseudo-TTY. défaut: false
--tmpfs=[] Créé un montage tmpfs
-u, --user="" Définis le username ou l'UID utilisé et optionnellement le group ou GID pour la commande spécifiée
--ulimit=[] Options ulimit
-v|--volume[=[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]] Créé un montage. avec -v /HOST-DIR:/CONTAINER-DIR, Docker monte /HOST-DIR dans l'hôte dans /CONTAINER-DIR dans le conteneur. Si HOST-DIR est omis, Docker créé un nouveau volume dans l'hôte. par défaut, les montages sont privés (non-visibles dans l'hôte). Peut être spécifié plusieurs fois.
--volume-driver="" Pilote de volume du conteneur. Ce pilote créé les volumes spécifié soit avec l'instruction VOLUME du dockerfile, ou depuis l'option -v.
--volumes-from=[] Monte les volumes depuis les conteneurs spécifiés.
-w, --workdir="" Répertoire de travail dans le conteneur
^
13 mars 2016

htmlpdflatexmanmd




docker-daemon

docker-daemon

Activer le mode service

OPTIONS

--api-cors-header="" Définis les en-têtes CORS dans l'API distante. Défaut: désactivé.
--authorization-plugin="" Définis les plugins d'autorisation à charger
-b, --bridge="" Attache les conteneurs à un bridge réseau existant
--bit="" Utiliser l'adresse en notation CIDR donnée pour la création du bridge0. Ne peut pas être utilisé avec -b
--cgroup-parent="" Définis le cgroup parent pour tous les conteneurs. Défatut: /docker pour le pilote cgroup fs, et system.slice pour le pilote cgroup systemd
--cluster-store="" URL du backend de stockage distribué
--cluster-advertise="" Spécifie la combinaison 'host:port' ou 'interface:port' que cette instance particulière devrait utiliser en s'annonçant au cluster. Le service est accessible via cette valeur.
--cluster-store-opt="" Spécifie les optins pour la magasin de clé/valeurs
--config-file="/etc/docker/daemon.json" Spécifie le fichier de configuration JSON à charger
-D, --debug=true|false Active le mode débug. Défaut: false
--default-gateway="" Adresse IPv4 de la passerelle par défaut du conteneur. Cette adresse doit faire partie du bridge, définis par --bip
--default-gateway-v6="" idem avec l'IPv6
--default-ulimit=[] Définis les ulimits pour les conteneurs
--disable-legacy-registry=true|false Ne pas contacter les registre legacy
--dns="" Forcer Docker à utiliser les serveurs DNS spécifiés
--dns-opt="" Options DNS à utiliser
--dns-search=[] Domaines DNS à utiliser
--exec-opt=[] Défins les options du pilote d'exécution.
--exe-root="" Chemin racine du pilote d'exécution Docker. Défaut: /var/run/docker
--fixed-cidr="" Sous-réseau IPv4. Ce sous-réseau doit être imbriqué dans le bridge définis par --bip
--fixed-cidr-v6="" Idem en ipv6
-G, --group="" Groupe pour assigner un socker unix spécifié pas -H. Défaut: docker
-g, --graph="" Chemin à utiliser comme racine du Docker runtime. Défaut: /var/lib/docker
-H, --host=[unix:///var/run/docker.sock] tcp://[host:port] à connecter ou unix://[/path/to/socket] ou fd://socketfd à utiliser. Peut être spécifiés plusieurs fois
--icc=true|false Autorise les communication inter-conteneur et l'hôte non-restreint. Si désactivé, les conteneurs peuvent être liés ensemble avec l'option --link. Défaut: true
--insecure-registry=[] Active la communication au registre non-sécure.
--ip="" Adresse IP par défaut à utiliser en se connectant aux ports du conteneur. Défaut: 0.0.0.0
--ip-forward=true|false Active l'IP forwarding dans l'hôte Docker. Défaut: true. Intéragit avec l'ip forwarding dans le kernel.
--ip-masq=true|false Acive l'IP masquerading pour la plage IP du bridge. Défaut: true
--iptables=true|false Active l'ajout de règles iptables par docker. Défaut: true
--ipv6=true|false Active le support d'IPv6. Défaut: false. Docker céé un bridge avec l'adresse fe80::1.
-l, --log-level="debug|info|warn|error|fatal" Niveau de log. Défaut: info
--label="[]" Labels key=valyue du service.
--log-driver="json-file|syslog|journald|gelf|fluentd|awslogs|none" Pilote pou les logs des conteneurs. Défaut: json-file.
--log-opt=[] options spécifiques au pilote de logs.
--mtu=0 Définis le mtu des conteneurs. Défaut: 0
-p, --pidfile="" Chemin à utiliser pour le fichier PID du service. Défaut: /var/run/docker.pid
--registry-mirror=‹scheme›://‹host› Àjoute un registre miroir à utiliser pour télécharger les images. peut être spécifié plusieurs fois
-s, --storage-driver="" Force Docker à utiliser le pilote de stockage spécifique.
--selinux-enabled=true|false Active le support selinux. Défaut: false. SELinux ne support pas actuellement le pilote de stockage overlay
--storage-opt=[] Définis les options du pilote de stockage.
--tls=true|false Utilise TLS
--tlscacert=/.docker/ca.pem Spécifie les certificats d'autorité
--tlscert=/.docker/cert.pem Chemin du certificat à utiliser
--tlskey=/.docker/key.pem Chemin de la clé à utiliser
--tlsverify=true|false Utilise TLS et vérifie le paire
--userland-proxy=true|false Gère l'implémentation du proxy dans l'espace utilisateur pour les communication inter-conteneur et externes. Défaut: true
--userns-remap=default|uid:gid|user:group|user|uid Active les espaces de nom utilisateur pour les conteneurs. default créé un nouvel utilisateur et groupe.

Option de pilote de stockage

   Docker utilise des backend de stockage (appelés graphdrivers) pour créer des conteneurs en écriture depuis les images. De nombreux backends utilisent des technologies de l'OS et peuvent être configurés.

   L'options --storage-opt permet de spécifier des options pour le backend. Le seul backend qui actuellement accèpte des options est devicemapper.

   Spécifiquement pour devicemapper, le défaut est un modèle loopback qui ne nécessite aucune pré-configuration, mais est inefficace. Ne pas l'utiliser en production.

   Pour utiliser au mieux devicemapper, vous devez avoir une version récente de LVM. Utiliser lvm pour créer un pool, puis utiliser --storage-opt dm.thinpooldev pour indiquer à Docker d'utiliser ce pool pour allouer des images et des conteneurs.

dm.thinpooldev Spécifie un périphérique de stockage block à utiliser pour le pool
dm.basesize Spécifie la taile à utiliser en créant le périphérique de base, qui limite la taille des images et des conteneurs. La valeur par défaut est 10G.
dm.fs Spécifie le type de système de fichier à utiliser pour le périphérique de base. (ext4 et xfs). Défaut: ext4.
dm.mkfsarg Spécifie les arguments supplémentaire mkfs à utiliser pour la création du périphérique de base
dm.mountopt Spécifie les options de montages à utiliser en montant les périphériques.
dm.use_deferred_removal Active l'utilisation de la suppression de périphérique différé si libdm et le pilote kernel supportent ce mécanisme.
dm.use_deferred_deletion Active l'utilisation de la suppression de périphérique différé pour les périphériques pool.
dm.loopdatasize Ne pas utiliser en production. spécifie la taille à utiliser en créant le fichier loopback pour le périphérique de données.
dm.loopmetadatasize Ne pas utiliser en production. Spécifie la taille à utiliser en créant le fichier loopback pour les métadonnées.
dm.blocksize Spécifie une taille de block personnalisé. Défaut: 64K
dm.blkdiscard Active l'utilisation de blkdiscard en supprimant les périphériques devicemapper. Désactivé par défaut à cause d'une latence additionnelle.
dm.override_udev_sync_check Par défaut, le backend devicemapper tente de se synchroniser avec udev pour le kernel linux. Cette option permet de désactiver cette synchronisation.

Options de stockage en cluster

   Le service utiliser libkv pour annoncer le nœud dans le cluster. Certains backend key/value supportent TLS, et les paramètres TLS client utilisées par le service peuvent être configurés avec --cluster-store-opt:

kv.cacertfile Certificats d'autorité au format PEM
kv.certfile Certificat PEM à utiliser
kv.keyfile Clé privée PEM à utiliser

Autorisation d'accès

   L'autorisation d'accès à Docker peut être étendue par des plugins d'autorisation. Il est possible d'utiliser plusieurs plugins d'autorisation en même temps, avec l'option --autorization.
^
13 mars 2016

htmlpdflatexmanmd




docker-diff

docker-diff

Inspecter les changements dans le système de fichier d'un conteneur

Exemples

docker diff 1fdfd1f54c1b
^
13 mars 2016

htmlpdflatexmanmd




docker-events

docker-events

Affiche les événements depuis le serveur

   Récupère les information du service Docker. Les informations peuvent inclure un historique et les informations temps-réel. Les événements de conteneur reportés sont: attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause. Les images Docker reportent: delete, import, pull, push, tag, untag

OPTIONS

-f, --filter=[] Valeurs de filtre fournis (ex: event=stop)
--since="" Affiche tous les événements depuis le timestamp spécifié
--until="" Affiche tous les événement jusqu'au timestamp spécifié

Exemples

Écouter les événements Docker:
dockers events
Écouter les événements depuis une date donnée:
docker events --since '2015-01-28'
Afficher tous les événements générés dans les 3 dernières minutes:
docker events --since '3m'
^
13 mars 2016

htmlpdflatexmanmd




docker-exec

docker-exec

Lance une commande dans un conteneur en cours d'exécution

   La commande lancée est seulement exécutée en tant que processus principal du conteneur, et ne sera pas redémarré si le conteneur est redémarré. Si le conteneur est en pause, docker exec attend jusqu'à ce que le conteneur soit relancé

OPTIONS

-d, --detach=true|false Lance de conteneur en tâche de fond et affiche l'ID du conteneur. défaut: false
--detach-keys="" Change la séquence de touche pour détacher le conteneur. Défaut: CTRL-p CTRL-q.
--privileged=true|false Donne des priviléges étendus à ce conteneur. Défaut: false
-t, --tty=true|false Alloue un pseudo-TTY. défaut: false
-u, --user="" Définis le username ou l'UID utilisé et optionnellement le group ou GID pour la commande spécifiée
^
13 mars 2016

htmlpdflatexmanmd




docker-export

docker-export

Exporte le contenu du système de fichier d'un conteneur dans une archive tar

OPTIONS

-o, --output="" Écrit dans un fichier au lieu de STDOUT
^
13 mars 2016

htmlpdflatexmanmd




docker-history

docker-history

Affiche l'historique d'une image

OPTIONS

-H, --human=true|false Affiche les tailles et les dates au format human readable. défaut: true
--no-trunc=true|false Ne tronque par la sortie. Défaut: false
-q, --quiet=true|false Affiche seulement l'ID numérique. Défaut: false
^
13 mars 2016

htmlpdflatexmanmd




docker-images

docker-images

Lister les images stockées dans le dépôt Docker local

   Par défaut, les images intermédiaires, utilisées durant la construction, ne sont pas listées. Une partie de la sortie, par exemple l'ID de l'image, est tronquée pour des raisons d'espace. Le titre REPOSITORY pour le premier titre peut être confus. C'est essentiellement le nom de l'image. Cependant, les tags peuvent être associés avec un nom.

OPTIONS

-a, --all=true|false Affiche toutes les images. Défaut: false
--digests=true|false Affiche les digests des images. Défaut: false
-f, --filter=[] Filtre la sortie. le filtre dangling=true trouve les images inutilisées. label=com.foo=amd64 filtre les images avec une valeur com.foo à amd64.
--format="TEMPLATE" Affiche les conteneur en utilisant le template Go. (.ID, .Repository, .Tag, .Digest, .CreatedSince, CreatedAt, .Size)
--no-trunc=true|false Ne tronque pas la sortie. Défaut: false
-q, --quiet=true|false Affiche seulement les ID. Défaut: false
^
13 mars 2016

htmlpdflatexmanmd




docker-import

docker-import

Créé une image de système vide et importe le contenu d'un tarball

OPTIONS

-c, --change=[] Applique les instructions Dockerfile spécifiés (CMD|ENTRYPOINT|ENV|EXPOSE|ONBUILD|USER|VOLUME|WORKDIR)

Exemples

Importer depuis un emplacement distant:
docker import http://example.com/exampleimage.tgz example/imagerepo
Importer depuis un fichier local:
cat exampleimage.tgz | docker import - example/imagelocal
Importer avec un message commit:
cat exampleimage.tgz | docker import --message "New image imported from tarball" - exampleimagelocal:new
Importer dan docker:
cat exampleimageV2.tgz | docker import - example/imagelocal:V-2.0
Importer depuis un répertoire local:
tar -c . | docker import - exampleimagedir
Appliquel les instruction Dockerfile spécifiés en important l'image:
tar -c . | docker import -c="ENV DEBUG true" - exampleimagedir
^
13 mars 2016

htmlpdflatexmanmd




docker-info

docker-info

Afficher des informations sur le système

Exemple

docker info
Containers: 14
    Running: 3
    Paused: 1
    Stopped: 10
Images: 52
Server Version: 1.9.0
Storage Driver: aufs
    Root Dir: /var/lib/docker/aufs
    Dirs: 80
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
    Volume: local
    Network: bridge null host
Kernel Version: 3.13.0-24-generic
Operating System: Ubuntu 14.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 2 GiB

^
13 mars 2016

htmlpdflatexmanmd




docker-inspect

docker-inspect

Affiche les informations bas-niveau d'un conteneur ou d'une image

   Affiche toutes les informations disponible dans Docker pour un conteneur ou une image donnée. Par défaut, affiche dans un table JSON. Si le conteneur et l'image ont le même nom, retourne le conteneur.

OPTIONS

-f, --format="" formatte la sortie en utilisant le template Go
-s, --size Affiche la taille totale des fichiers si le type est un conteneur.
--type="container|image" Spécifie le type.

Exemples

Afficher les informations d'une image:
docker inspect --type=image rhel7
Afficher les information d'un conteneur:
docker inspect d2cc496561d6
Afficher l'adresse IP d'une instance de conteneur:
docker inspect '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' d2cc496561d6
Lister tous les ports liés:
docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -› {{(index $conf 0).HostPort}} {{end}}' d2cc496561d6
Afficher la taille d'un conteneur:
docker inspect -s d2cc496561d6
^
13 mars 2016

htmlpdflatexmanmd




docker-kill

docker-kill

Terminer un conteneur en cours d'exécution en utilisant SIGKILL ou un signal spécifié

   Le principal processus dans chaque conteneur spécifié reçoit le signal SIGKILL our le signal spécifié.

OPTIONS

-s, --signal="KILL" Envoie le signal spécifié
^
13 mars 2016

htmlpdflatexmanmd




docker-load

docker-load

Charger une image depuis une archive tar ou STDIN

OPTIONS

-i, --input="" Lit l'archive tar au lieu de STDIN.
^
13 mars 2016

htmlpdflatexmanmd




docker-login

docker-login

S'enregistre ou se logger au registre Docker

   S'enregistrer ou se logger dans un registre Docker localisé sur le serveur spécifié. On peut spécifier une URL ou un nom d'hôte. Sans spécifier de serveur, la commande utiliser le registre Docker publique (https://registry-1.docker.io/). Pour obtenir un login/password pour ce registre, créer un compte sur Docker Hub. Nécessite l'utilisation de sudo ou d'être root, excepté lorsqu'on se connecte à un service distant. L'utilisateur est ajouté au groupe docker. Cela impacte la sécurité du système. Le groupe docker est équivalent à root.

OPTIONS

-e, --email="" Email
-p, --password="" Mot de passe
-u, --username="" Nom d'utilisateur
^
13 mars 2016

htmlpdflatexmanmd




docker-logout

docker-logout

Se déconnecter d'un registre Docker

   Se déconnecter d'un registre Docker sur le serveur spécifié. L'URL peut être spécifiée par nom d'hôte.

^
13 mars 2016

htmlpdflatexmanmd




docker-logs

docker-logs

Récupère les logs présents pour un conteneur

   Cette commande ne garantie pas le temps d'exécution quand elle est combinée avec docker run. Cette commande ne fonctionne qu'avec les pilotes de log json-file et journald.

OPTIONS

-f, --follow=true|false Suit la sortie des logs. défaut: false
--since="" Affiche les logs depuis la date spécifiée
-t, --timestamps=true|false Affiche les horodatages. défaut: false
--tail="all" Affiche le nombre de ligne spécifié, à la fin des logs. défaut: all.
^
13 mars 2016

htmlpdflatexmanmd




docker-network-connect

docker-network-connect

Connecter un conteneur à un réseau

Une fois connecté, le conteneur peut communiquer avec d'autres conteneurs dans le même réseau.
docker network connect multi-host-network container1
La commande docker run --net=‹network-name› permet de faire la même chose au démarrage du conteneur
docker run -itd --net=multi-host-network --ip 172.20.88.22 --ip6 2001:db8::8822 busybox
Si spécifié, l'adresse IP du conteneur est ré-appliqué quand un conteneur stoppé est redémarré. Si l'IP est occupé, le conteneur échoue, --ip-range permet de s'assurer de trouver une ip disponible:
docker network create --subnet 172.20.0.0/16 --ip-range 172.20.240.0/20 multi-host-network
docker network connect --ip 172.20.128.2 multi-host-network container2

^
13 mars 2016

htmlpdflatexmanmd




docker-network-create

docker-network-create

Créer un nouveau réseau

OPTIONS

--aux-address=map[] Adresses ipv4 ou ipv6 auxiliaires utilisée par le périphérique réseaux
-d, --driver=DRIVER Le pilote pour gérer le réseau ou l'overlay. Défaut: bridge
--gateway=[] passerelle IPv4 ou IPv6 pour le sous-réseaux maître
--internal Restreint l'accès externe au réseaux
--ip-range=[] Alloue une ip au conteneur dans une plage
--ipam-driver=default Pilote de gestion d'adresse ip
--ipam-opt=map[] Définis les options du pilote IPAM
-o, --opt=map[] Définis les options du pilote
--subnet=[] Sous-réseau au format CIDR qui représente un segment réseau

   Le pilote peut être bridge ou overlay, qui sont des pilotes intégrés. Un pilote tier peut également être spécifié. Sans l'option --driver, la commande créé automatiquement un bridge. En installant Docker Engine, un bridge est installé automatiquement. Ce réseau correspond au bridge docker0 sur lequel le moteur s'appuie. En lançant un nouveau conteneur avec docker run, il est automatiquement connecté à ce bridge. On ne peut pas le supprimer, mais on peut en créer de nouveaux.

   Les réseaux bridge sont des réseaux isolés sur une simple installation Engine. Pour créer un réseaux partagé avec plusieurs hôtes Docker, il faut créer un réseaux overlay. À la différence de bridge, overlay nécessite certaines conditions avant de pouvoir en créer un:

   L'accès à un magasin de clé-valeur. Engine support Consul, Etcd, et Zookeeper. Un clustre d'hôte avec une connectivité à ce store. Un Engine configuré correctement sur chaque hôte du cluster. Le service docker supporte les options suivantes pour le réseaux Docker: --cluster-store, --cluster-opt, et --cluster-advertise.

   C'est également une bonne idée, bien que non requis, d'installer Docker Swarn pour gérer le cluster. Swarn fournis une découverte sophistiquée et un gestionnaire de serveur qui peut assister l'implémentation.

Une fois les prérequis pour le réseau overlay préparé, il suffit de créer le réseau avec:
docker network create -d overlay my-multihost-network
Les noms de réseaux doivent être unique. Le service Docker tente d'identifier les conflicts de nommage mais ce n'est pas garantit.

Connecter des conteneurs

Au démarrage d'un conteneur utiliser --net pour se connecter à un réseaux. Cet exemple ajoute le conteneur busybox au réseau mynet:
docker run -itd --net=mynet busybox
Pour ajouter un conteneur à un réseau après que le conteneur soit démarré, utiliser docker network connect. Il est possible de connecter plusieurs conteneurs sur le même réseau. Une fois connectés, les conteneurs peuvent communiquer en eux.

Spécifier des options avancée

En créant un réseaux, Engine créé un sous-réseau sous le réseau par défaut. Ce sous-réseaux n'est pas une sous-division d'un réseau existant. C'est purement dans un but d'adressage ip. Il est possible de changer et de spécifier des valeurs de sous-réseau directement en utilisant l'option --subnet. sur un bridge, on peut seulement créer un simple sous-réseau:
docker network create -d bridge --subnet=192.168.0.0/16 br0
Additionnellement, on peut également spécifier les options --gateway, --ip-range, et --aux-address
network create --driver=bridge --subnet=172.28.0.0/16 --ip-range=172.28.5.0/24 --gateway=172.28.5.254 br0
Si --gateway est omis, Engine en séléctionne un dans le pool. Pour les réseaux overlay et pour les plugins réseaux qui le supporte on peut créer plusieurs sous-réseauxs
docker network create -d overlay --subnet=192.168.0.0/16 --subnet=192.170.0.0/16 --gateway=192.168.0.100 --gateway=192.170.0.100 --ip-range=192.168.1.0/24 --aux-address a=192.168.1.5 --aux-address b=192.168.1.6 --aux-address a=192.170.1.5 --aux-address b=192.170.1.6 my-multihost-network

Mode réseau interne

Par défaut, en connectant un réseau à un réseau overlay, Docker connecte également un réseau bridge pour fournir la connctivité externe. Pour créer un réseau overlay isolé, spécifier l'option --internal
^
13 mars 2016

htmlpdflatexmanmd




docker-network-disconnect

docker-network-disconnect

Déconnecter un conteneur d'un réseau

   déconnecter un conteneur d'un réseau:

OPTIONS

--force Force le conteneur à ce déconnecter du réseau
^
13 mars 2016

htmlpdflatexmanmd




docker-network-inspect

docker-network-inspect

Inspecter un réseau

Retourne des informations sur un ou plusieurs réseaux. Par défaut, cette commande affiche le résultat dans un objet JSON. par exemple, si 2 conteneurs sont connectés à un réseau bridge:
sudo docker run -itd --name=container1 busybox
f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27
sudo docker run -itd --name=container2 busybox
bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727

La commande inspect affiche les conteneurs, par id:
sudo docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "b2b1a2cba717161d984383fd68218cf70bbbd17d328496885f7c921333228b0f",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Config": [
                {
                 "Subnet": "172.17.42.1/16",
                 "Gateway": "172.17.42.1"
                }
            ]
        },
        "Containers": {
            "bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727": {
                "Name": "container2",
                "EndpointID": "0aebb8fcd2b282abe1365979536f21ee4ceaf3ed56177c628eae9f706e00e019",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            },
            "f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27": {
                "Name": "container1",
                "EndpointID": "a00676d9c91a96bbe5bcfb34f705387a33d7cc365bac1a29e4e9728df92d10ad",
                "MacAddress": "02:42:ac:11:00:01",
                "IPv4Address": "172.17.0.1/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
         "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        }
    }
]

Retourner les informations sur le réseau utilisateur:
docker network create simple-network
69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a
docker network inspect simple-network
[
    {
        "Name": "simple-network",
        "Id": "69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Config": [
                {
                 "Subnet": "172.22.0.0/16",
                 "Gateway": "172.22.0.1/16"
                }
            ]
        },
        "Containers": {},
        "Options": {}
    }
]

OPTIONS

-f, --format="" Formatte la sortie en utilisant le templace Go
^
13 mars 2016

htmlpdflatexmanmd




docker-network-ls

docker-network-ls

Lister les réseaux

   Liste tous les réseaux que le service connait. Inclus les réseaux connectés sur plusieurs hôte dans un cluster. L'option --no-trunc affiche l'id complet des réseaux. -f ou --filter filtre la sortie au format key=value. S'il y a plus d'un filtre, agit comme un filtre OR.

type

Le fitre type support 2 valeurs: builtin qui affiche les réseaux prédéfinis (bridge, none, host), et custom qui affiche les réseaux utilisateur. Le filtre suivant affiche les réseaux utilisateurs:
docker network ls --filter type=custom
Ce filtre permet de supprimer tous les réseaux utilisateurs:
docker network rm `docker network ls --filter type=custom -q`

Name

Le filtre name correspond à tout ou partie du nom d'un réseau. Le filtre suivant matche tous les réseaux avec un nom contenant la chaîne foobar:
docker network ls --filter name=foobar

ID

Le filtre id matche tout ou partie de l'ID d'un réseaux:
docker network ls --filter id=63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161

OPTIONS

-f, --filter=[] Filtre la sortie basée sur la condition fournie
--no-trunc=true|false Ne tronque pas la sortie
-q, --quiet=true|false N'affiche que les ID
^
13 mars 2016

htmlpdflatexmanmd




docker-network-rm

docker-network-rm

Supprimer un ou plusieurs

Pour supprimer un réseau, déconnecter d'abord tout conteneur attaché:
docker network rm my-network
Pour supprimer plusieurs réseaux d'un coup:
docker network rm 3695c422697f my-network

^
13 mars 2016

htmlpdflatexmanmd




docker-pause

docker-pause

Pause tous les processus dans un conteneur

   Cette commande utilise les cgroups freezer pour suspendre tous les processus dans un conteneur.

^
13 mars 2016

htmlpdflatexmanmd




docker-port

docker-port

Liste les mappages de port pour le conteneur spécifié

   Liste les mappages de port ou recherche le port publique qui est natté au port privé.

^
13 mars 2016

htmlpdflatexmanmd




docker-ps

docker-ps

Lister les conteneurs. Par défaut, ne liste que les conteneurs en cours d'exécution

OPTIONS

-a, --all=true|false Affiche tous les conteneurs. Défaut: false
-f, --filter=[] Filtre basé sur les conditions (exited=‹int›, label=‹key›, label=‹key›=‹value›, status=(created|restarting|running|paused|exited|dead), name=‹string›, id=‹ID›, before=(‹container-name›|‹container-id›), since=(‹container-name›|‹container-id›), ancestor=(‹image-name›[:tag]|‹image-id›| (image@digest)) )
--format="TEMPLATE" Formatte la sortie en utilisant le template Go
-l, --latest=true|false Affiche seulement le dernier conteneur créé. Défaut: false
-n=-1 Affiche les n derniers conteneurs créés (inclus tous les états)
--no-trunc=true|false Ne tronque pas la sortie
-q, --quiet=true|false Affiche seulement les ID. Défaut: false
-s, --size=true|false Affiche la taille de fichiers totale. Défaut: false

Exemples

Afficher tous les conteneurs:
docker ps -a
Afficher seulement les ID des conteneurs:
docker ps -a -q
Afficher seulement les ID des conteneur dont le nom est MyContainer:
docker ps -a -q --filter=name=determined_torvalds
Afficher les conteneurs avec leurs commandes:
docker ps --format "{{.ID}}: {{.Command}}"
Afficher les conteneurs avec leurs labels dans une table:
docker ps --format "table {{.ID}}\t{{.Labels}}"
Afficher les conteneurs avec leur label node dans une table:
docker ps --format 'table {{.ID}}\t{{(.Label "com.docker.swarm.node")}}'
^
13 mars 2016

htmlpdflatexmanmd




docker-pull

docker-pull

Télécharger une image ou un dépôt depuis un registre

   Cette commande récupère une images ou un dépôt depuis un registre. S'il y a plus d'une image pour un dépôt, toutse les images sont récupérée incluant les tags.

OPTIONS

-a, --all-tags=true|false Télécharge toutes les images taggées dans le dépôt. Défaut: false

Exemples

récupérer un dépôt avec plusieurs images avec tous les tags:
docker pull --all-tags fedora
Récupérer une image depuis un dépôt publique:
docker pull registry.hub.docker.com/fedora:20
^
13 mars 2016

htmlpdflatexmanmd




docker-push

docker-push

Upload une image ou un dépôt dans un registre

   Envoie une image ou un dépôt vers un registre.

Exemples

Upload une nouvelle image en spécifiant son ID et en la nommant:
docker commit c16378f943fe rhel-httpd
Puis tager l'image avec le nom d'hôte et l'IP:port du registre:
docker tag rhel-httpd registry-host:5000/myadmin/rhel-httpd
Puis envoyer l'image:
docker push registry-host:5000/myadmin/rhel-httpd
Vérifier que cela a fonctionné:
docker images
^
13 mars 2016

htmlpdflatexmanmd




docker-rename

docker-rename

Renommer un conteneur

   Cette commande n'a pas d'option

^
13 mars 2016

htmlpdflatexmanmd




docker-restart

docker-restart

Redémarrer un conteneur

OPTIONS

-t, --time=10 Nombre de secondes de tentative d'arrêt avant de tuer le conteneur. Une fois tué, il est redémarré. Défaut: 10 secondes
^
13 mars 2016

htmlpdflatexmanmd




docker-rm

docker-rm

Supprimer un ou plusieurs conteneurs

Exemple

docker rm supprime un ou plusieurs conteneurs depuis un nœud hôte. Cela ne supprime pas les images. On ne peut pas supprimer un conteneur en cours d'exécution sauf avec -f.

OPTIONS

-f, --force=true|false Force la suppression d'un conteneur en cours d'exécution (utilise SIGKILL). Défaut: false
-l, --link=true|false Supprime le lien spécifié et pas le conteneur. Défaut: false
-v, --volumes=true|false Supprime les volumes associés avec le conteneur. Défaut: false

Exemples

Supprimer un conteneur en utilisant sont ID:
docker rm abebf7571666
Supprimer un conteneur et tous ses volumes associés. Noter que si un volume a été spécifié avec un nom, il n'est pas supprimé:
docker rm -v redis
^
13 mars 2016

htmlpdflatexmanmd




docker-rmi

docker-rmi

Supprimer une ou plusieurs images

Exemple

Supprime une ou plusieurs images depuis un nœud hôte. Cela ne supprime pas les images d'un registre. On ne peut pas supprimer une image d'un conteneur en cours d'exécution sauf avec -f.

OPTIONS

-f, --force=true|false Force la suppression de l'image. Défaut: false
--no-prune=true|false Ne supprime pas les parents non-taggés. Défaut: false
^
13 mars 2016

htmlpdflatexmanmd




docker-run

docker-run

Lancer une commande dans un nouveau conteneur

   Lance un processus dans un nouveau conteneur, avec son propre système de fichier, son propre réseau, et sa propre arborescence isolée. l'image qui démarre le processus peut définir des défaut qui sont liés au processus qui sera lancé dans le conteneur, le réseau à exposer, et plus, mais docker run donne un contrôle final à l'opérateur ou d'administrateur qui a lancé le conteneur depuis l'image. Pour cette raison, docker run a plus d'options que d'autres commande docker. Si l'image n'est pas déja chargée, elle est téléchargée, et toutse les dépendences, depuis le dépot, de la même manière que docker pull.

OPTIONS

-a, --attach=[] Attache à STDIN, STDOUT ou STDERR. En mode foreground.
--add-host=[] Ajoute un mappage host-to-IP personnalisé (host:ip). Ajoute une ligne à /etc/hosts. peut être spécifié plusieurs fois.
--blkio-weight=0 Poid IO entre 10 et 1000
--blkio-weight-device=[] Poid IO au format DEVICE_NAME:WEIGHT
--cpu-shares=0 Partage CPU
--cap-add=[] Ajouter des capabilities Linux
--cap-drop=[] Supprimer de capabilities Linux
--cgroup-parent="" Chemin des cgroups sous lesquels créer le conteneur. Si le chemin n'est pas absolu, le chemin est relatif aux cgroups du processus init.
--cidfile="" Écrit l'ID de conteneur dans le fichier
--cpu-period=0 Limite la période CFS
--cpuset-cpus=CPUSET-CPUS CPU dans lesquels autoriser l'exécution
--cpuset-mems="" Nœuds mémoire autorisés.
--cpu-quota=0 Limite le quota CPU CFS
-d, --detach=true|false Lance de conteneur en tâche de fond et affiche l'ID du conteneur. défaut: false
--detach-keys="" Change la séquence de touche pour détacher le conteneur. Défaut: CTRL-p CTRL-q.
--device=[] Un périphérique hôte pour le conteneur (ex --device=/dev/sdc:/dev/xvdc:run)
--device-read-bps=[] Limite le taux de lecture d'un périphérique ( ex --device-read-bps=/dev/sda:1mb)
--device-read-iops Limite le taux de lecture d'un périphérique (ex --device-read-iops=/dev/sda:1000)
--device-write-bps=[] Limite le taux d'écriture d'un périphérique ( ex --device-write-bps=/dev/sda:1mb)
--device-write-iops Limite le taux d'écriture d'un périphérique (ex --device-write-iops=/dev/sda:1000)
--dns-search=[] Définis les domaines de recherche DNS.
--dns-opt=[] Définis les options DNS
--dns=[] Définis les serveurs DNS
-e, --env=[] Définis des variables d'environnement.
--entrypoint="" Remplace l'ENTRYPOINT de l'image
--env-file=[] Line un fichier de variables d'environnements
--expose=[] Expose un port, une une plage de ports informant Docker que le conteneur écoute sur les ports spécifiés. Docker utilise cette information pour interconnecter les conteneurs en utilisant des liens et pour définir la redirection de port dans le système hôte.
--group-add=[] Ajoute des groupes additionnels à lancer
-h, --hostname="" nom d'hôte du conteneur
-i, --interactive=true|false Garde STDIN ouvert même s'il n'est pas attaché. défaut: false
--ip="" Définis l'adresse IPv4 de l'interface du conteneur, uniquement avec --net pour les réseaux utilisateurs
--ip6="" Définis l'adresse IPv6 de l'interface du conteneur, uniquement avec --net pour les réseaux utilisateurs
--ipc="" Créé un espace de nom IPC privé pour le conteneur
--isolation="default" spécifique le type de technologie d'isolation utilisée par les conteneurs
-l, --label=[] Définis les métadonnées du conteneur (ex: --label com.example.key=value)
--kernel-memory="" Limit la mémoire kernel. (0 = illimité)
--label-file=[] Lit un fichier de labels
--link=[] Ajoute un lien vers un autre conteneur sous la forme ‹nom ou id›:alias.
--log-driver="json-file|syslog|journald|gelf|fluentd|awslogs|splunk|none" Pilote de logging pour le conteneur. La commande docker logs ne fonctionne que pour les pilotes json-file et journald.
--log-opt=[] options spécifique au pilote de logging
-m, --memory="" Limite mémoire
--memory-reservation="" Limite soft
--memory-swap="LIMIT" Une valeur limite égale à la mémoire plus le swap. Doit être utilisé avec -m.
--mac-address="" L'adresse mac de conteneur
--name="" Assigne un nom au conteneur au format UUID long, UUID court, ou un nom.
--net="bridge" Définis le mode réseau pour le conteneur (bridge, none, container:‹name|id›, host, ‹network-name›|‹network-id›
--net-alias=[] ajoute un alias réseau pour le conteneur
--oom-kill-disable=true|false Active ou non le OOM Killer pour le conteneur
--oom-score-adj="" Ajustement OOM de l'hôte pour le conteneur (-1000 à 1000)
-P, --publish-all=true|false Publie tous les ports exposés aux ports aléatoire dans les interfaces de l'hôte. Défaut: false
-p, --publish=[] Publie le port d'un conteneur, ou une plage de port, à l'hôte (Format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort)
--pid=host Définis de mode PID pour le conteneur (host: utilise l'espace de nom PID de l'hôte, non sécurisé)
--uts=host Définis le mode UTS pour le conteneur (host: utilise l'espace de noms UTS dans le conteneur, non sécurisé)
--privileged=true|false Donne des priviléges étendus à ce conteneur. Défaut: false
--read-only=true|false Mounte le système de fichier racine du conteneur en lecture seule.
--restart="no" Stratégie de redémarrage quand le conteneur se termine. (no, on-failure[:max-retry], always, unless-stopped)
-rm=true|false Supprime automatiquement le conteneur quand il se termine. incompatible avec -d. défaut: false
--security-opt=[] Options de sécurité

        "label:user:USER" Définis le label utilisateur pour le conteneur
        "label:role:ROLE" Définis le label rôle pour le conteneur
        "label:type:TYPE" Définis le label type pour le conteneur
        "label:level:LEVEL" Définis le label level pour le conteneur
        "label:disable" Désactive le confinement de label pour le conteneur

--stop-signal=SIGTERM Signal pour stopper un conteneur
--shm-size="" Taille de /dev/shm. format: ‹number›‹unit›
--sig-proxy=true|false signaux proxy reçus au processus (mode non-TTY uniquement). SIGCHLD, SIGSTOP, SIGKILL ne sont pas proxifiés. Défaut: true
--memory-swappiness="" Comportement de la memory swappiness du conteneur (0 à 100)
-t, --tty=true|false Alloue un pseudo-TTY. défaut: false
--tmpfs=[] Créé un montage tmpfs
-u, --user="" Définis le username ou l'UID utilisé et optionnellement le group ou GID pour la commande spécifiée
--ulimit=[] Options ulimit
-v|--volume[=[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]] Créé un montage. avec -v /HOST-DIR:/CONTAINER-DIR, Docker monte /HOST-DIR dans l'hôte dans /CONTAINER-DIR dans le conteneur. Si HOST-DIR est omis, Docker créé un nouveau volume dans l'hôte. par défaut, les montages sont privés (non-visibles dans l'hôte). Peut être spécifié plusieurs fois.
--volume-driver="" Pilote de volume du conteneur. Ce pilote créé les volumes spécifié soit avec l'instruction VOLUME du dockerfile, ou depuis l'option -v.
--volumes-from=[] Monte les volumes depuis les conteneurs spécifiés.
-w, --workdir="" Répertoire de travail dans le conteneur

Code de sortie

   Le code de sortie de docker run donne des information sur la raison de l'erreur du conteneur ou pourquoi il s'est terminé.

125 Si l'erreur vient du service Docker lui-même
126 Si la commande dans le conteneur ne peut être lancée
127 Si la commande dans le conteneur ne peut être trouvée
Autres code Contient le code de sortie de la commande

Exemples

Lancer un conteneur en mode lecture seule:
docker run --read-only --tmpfs /run --tmpfs /tmp -i -t fedora /bin/bash
Exposer les messages de log du conteneur dans les logs de l'hôte:
docker run -v /dev/log:/dev/log -i -t fedora /bin/bash
Attacher un ou plusieurs STDIN, STDOUT, STDERR:
docker run -a stdin -a stdout -i -t fedora /bin/bash

Lier les conteneurs

Cette section décrit comment lier les conteneur sur le réseau par défaut. La fonctionnalité link permet à plusieurs conteneurs de communiquer entre eux. Par exemple, un conteneur dont Dockerfile a exposé le port 80 peut être lancés comme suit:
docker run --name=link-test -d -i -t fedora/httpd
Un second conteneur, dans ce cas nommé linker, peut communiquer avec le conteneur httpd:
docker run -t -i --link=link-test:lt --name=linker fedora /bin/bash
Maintenant le conteneur linker et lié au conteneur link-test avec l'alias lt. Lancer la commande env dans le conteneur linker montre les valiables d'environnement:
# env
HOSTNAME=668231cb0978
TERM=xterm
LT_PORT_80_TCP=tcp://172.17.0.3:80
LT_PORT_80_TCP_PORT=80
LT_PORT_80_TCP_PROTO=tcp
LT_PORT=tcp://172.17.0.3:80
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LT_NAME=/linker/lt
SHLVL=1
HOME=/
LT_PORT_80_TCP_ADDR=172.17.0.3
_=/usr/bin/env

Mapper les ports pour une utilisation externe

Le port exposé d'une application peut être mappée sur un port hôte en utilisant le flag -p. Par exemple, le port 80 peut être mappé au port 8080:
docker run -p 8080:80 -d -i -t fedora/httpd

Créer et monter un volume

De nombreuses application nécessitent le partage de données persistantes entre de nombreux conteneurs. Docker permet de créer un Data Volume Container que d'autres conteneurs peuvent monter. Par exemple, créer un conteneur qui contient les répertoires /var/volume1 et /tmp/volume2. L'image doit contenir ces répertoires, donc des instructions mkdir sont nécessaires:
docker run --name=data -v /var/volume1 -v /tmp/volume2 -i -t fedora-data true
docker run --volumes-from=data --name=fedora-container1 -i -t fedora bash
Plusieurs --volumes-from vont monter les volumes de données. Et il est possible de monter les volumes qui vient d'un conteneur DATA dans un autre conteneur:
docker run --volumes-from=fedora-container1 --name=fedora-container2 -i -t fedora bash

Monter des volumes externes

Pour monter un répertoire hôte comme volume conteneur, spécifier le chemin absolue:
docker run -v /var/db:/data1 -i -t fedora bash
En utilisant SELinux, vérifier que l'hôte n'a pas connaissance de la stratégie SELinux du conteneur. Dans l'exemple suivant, SELinux est enforced, le répertoire /var/db n'est pas en écriture pour le conteneur. Au moment d'écrire ce man, la commande suivante doit être lancée pour que la stratégie SELinux soit attachée correctement au répertoire de l'hôte.
chcon -Rt svirt_sandbox_file_t /var/db

Utiliser un labeling de sécurité alternatif

--security-opt permet de changer le schéma de labelisation par défaut pour chaque conteneur. Par exemple, on peut spécifier un niveau NCS/MLS. Spécifier le niveaux dans la commande suivante permet de partager le même contenu entre les conteneurs:
docker run --security-opt label:level:s0:c100,c200 -i -t fedora bash
Un exemple MLS peut être:
docker run --security-opt label:level:TopSecret -i -t rhel7 bash
Pour désactiver le labeling de sécurité pour ce conteneur:
docker run --security-opt label:disable -i -t fedora bash
Pour resserrer la stratégie de sécurité sur les processus dans un conteneur:
docker run --security-opt label:type:svirt_apache_t -i -t centos bash
^
13 mars 2016

htmlpdflatexmanmd




docker-save

docker-save

Sauve une image dans une archive tar

   Produit un dépôt tar sur la sortie standard. Contient toutes les couches parent, et tous les tags + versions, ou spécifiés.

OPTIONS

-o, --output="" Écrit dans un fichier au lieu de la sortie standard

Exemples

Sauver toutes les images de dépôt fedora et sauver la dernière image fedora dans une autre archive:
docker save fedora › fedora-all.tar
docker save --output=fedora-latest.tar fedora:latest
^
13 mars 2016

htmlpdflatexmanmd




docker-search

docker-search

Rechercher des images dans Docker Hub

   Recherche des images qui correspondent au critère. La table d'images retournée affiche le nom, la description, et le nombre d'étoiles, si elle est officielle et si elle est automatisée.

OPTIONS

--automated=true|false Affiche seulement les builds automatisés. Défaut: false
--no-trunc=true|false Ne tronque pas la sortie. Défaut: false
-s, --stars=X Affiche seulement avec au moins X étoiles. Défaut: 0

Exemples

Recherche les images avec le terme fedora:
docker search -s 3 fedora
Rechercher les images automatisée:
docker search --automated -s 1 fedora
^
13 mars 2016

htmlpdflatexmanmd




docker-start

docker-start

Démarrer un ou plusieurs conteneurs

OPTIONS

-a, --attach=true|false Attache la sortie du conteneur à STDOUT et STDERR et transfert tous les signaux au processus. Défaut: false
--detach-keys="" Remplace la séquence de touche pour détacher un conteneur.
-i, --interactive=true|false Attache STDIN du conteneur. Défaut: false.
^
13 mars 2016

htmlpdflatexmanmd




docker-stats

docker-stats

Affiche des statistiques sur l'utilisation des ressources d'un conteneur

OPTIONS

-a, --all=true|false Affiche tous les conteneurs. Seul les conteneurs en cours d'exécution sont affichés par défaut. Défaut: false
--no-stream=true|false Désactive le monitoring des stats et n'affiche qu'un instantanné. Défaut: false
^
13 mars 2016

htmlpdflatexmanmd




docker-stop

docker-stop

Arrêter un conteneur en envoyant SIGTERM, puis SIGKILL

OPTIONS

-t, --time=10 Nombre de secondes à attendre pour que le conteneur se termine avec de le tuer. Défaut: 10 secondes
^
13 mars 2016

htmlpdflatexmanmd




docker-tag

docker-tag

Tag une image dans un dépôt

   Assigne un nouvel alias à une image dans un dépôt. Un alias réfère au nom de l'image inclant le tag optionnel après ':'.

OPTIONS

REGISTRY_HOST Nom d'ĥôte du dépôt si requis
USERNAME Nom d'utilisateur pour l'image
NAME Le nom de l'image
TAG Le tag à assigner

Exemple

Donner un nouvel alias à une image:
docker tag 0e5574283393 fedora/httpd:version1.0
idem pour un dépôt privée:
docker tag 0e5574283393 myregistryhost:5000/fedora/httpd:version1.0
^
13 mars 2016

htmlpdflatexmanmd




docker-top

docker-top

Afficher les processus en cours d'exécution dans un conteneur

   Les options peuvent être une des options que l'on passerai à la commande linux ps.

^
13 mars 2016

htmlpdflatexmanmd




docker-unpause

docker-unpause

Relance tous les processus dans un conteneur en pause

   Cette commande utilise les cgroups freezer pour relancer tous les processus dans un conteneur.

^
13 mars 2016

htmlpdflatexmanmd




docker-version

docker-version

Affiche les informations de version de docker

OPTIONS

-f, --format="" Formatte la sortie en utilisant le template go donné.

Exemples

Afficher la version de Docker
docker version
Afficher la version du serveur
docker version --format '{{.Server.Version}}'
Afficher tous les champs disponibles
docker versions --format '{{json .}}'
^
13 mars 2016

htmlpdflatexmanmd




docker-volume-create

docker-volume-create

Créer un nouveau volume

Créer un nouveau volume que les conteneur peuvent utiliser. Si un nom n'est pas spécifié, Docker génère un nom aléatoire. Le volume est dabord créé, puis configuré, par exemple:
docker volume create --name hello
docker run -d -v hello:/world busybox ls /world
Le montage est créé dans le répertoire /src du conteneur. Docker ne supporte pas les chemins relatifs pour les points de montages dans le conteneur.

   Plusieurs conteneurs peuvent utiliser le même volume dans la même période de temps. C'est utile si 2 conteneurs doivent accéder à des données partagées.

Options spécifiques au pilote

Certains pilotes acceptent des options pour personnaliser la création de volume, avec l'option --opt:
docker volume create --driver fake --opt tardis=blue --opt timey=wimey
Ces options sont passées directeent au pilote. Le pilote embarqué local n'accepte aucune option.

OPTIONS

-d, --driver="local" Spécifie le pilote à utiliser
--name="" Nom pour le volume
-o, --opt=[] Options spécifiques au pilote
^
13 mars 2016

htmlpdflatexmanmd




docker-volume-inspect

docker-volume-inspect

Afficher des informations sur un volume

   Retourne des informations sur un ou plusieurs volumes. Par défaut, cette commande affiche le résultant dans un tableau JSON.

OPTIONS

-f, --format="" formatte la sortie en utilisant le template Go
^
13 mars 2016

htmlpdflatexmanmd




docker-volume-ls

docker-volume-ls

Lister les volumes

   Liste tous les volumes. --filter permet de filtrer au format key=value.

OPTIONS

-f, --filter="" permet de filtrer la sortie. peut être spécifié plusieurs fois.
-q, --quiet=true|false Affiche seulement les noms des volumes
^
13 mars 2016

htmlpdflatexmanmd




docker-volume-rm

docker-volume-rm

Supprimer un volume

Supprime un ou plusieurs volumes. Il n'est pas possible de supprimer un volume utilisé par un conteneur.
docker volume rm hello

^
13 mars 2016

htmlpdflatexmanmd




docker-wait

docker-wait

Attend qu'un conteneur s'arrête, puis affiche son code de sortie

Exemple:
docker run -d fedora sleep 99
docker wait 079b83f558a2bc

^
13 mars 2016

htmlpdflatexmanmd




Dockerfile

Dockerfile

Automatiser la création d'image Docker

   Le fichier Dockerfile est un fichier de configuration qui automatise les étapes de création d'une image Docker. C'est similaire à un Makefile. Docker lit les instructions du fichier Dockerfile et automatise les étapes pour créer l'image. Pour construire une image, créer un fichier appelé Dockerfile. Utiliser ensuite docker build en utilisant le chemin du répertoire qui contient le Dockerfile comme argument.

Format

FROM image
FROM image:tag
FROM image@digest Le jeu d'instructions FROM définis l'image de base pour les instructions suivantes. Un Dockerfile valide doit avoir l'instruction FROM en premier.

        - FROM doit être la première instruction dans le Dockerfile
        - FROM peut apparaître plusieurs fois dans un Dockerfile
        - Si aucun tag n'est donné, Docker applique le tag latest, s'il n'existe pas, retourne une erreur
        - Si aucun hash n'est donné, Docker applique le tag latest, s'il n'existe pas, retourne une erreur

MAINTAINER Définis l'auteur pour les images générées. Utile pour fournir une URL ou un email
RUN ‹command›
RUN ["executable", "param1", "param2"] Éxécuter des commandes dans une nouvelle couche en haut de l'image courante et retourne le résultat.
CMD ["executable", "param1", "param2"]`
CMD ["param1", "param2"]`
CMD command param1 param2 Il devrait y avoir seulement un CMD dans un Dockerfile. Fournis des défauts pour un conteneur. Ces défauts peuvent inclure un exécutable. Si omis, un ENTRYPOINT doit être spécifié.
LABEL ‹key›=‹value› [‹key›=‹value› ...]
LABEL ‹key›[ ‹value›] Ajoute des métadonnées à une image. Un label est une paire de clé/valeur.
EXPOSE ‹port› [‹port›...] Informe Docker que le conteneur écoute sur des ports réseaux spécifiés. Docker utilise cette information pour interconnecter les conteneurs en utilisant des liens et pour définir les redirections de port dans le système hôte.
ENV ‹key› ‹value› Définis des variables d'environnement
ADD ‹src› ‹dest›
ADD ["‹src›",... "‹dest›"] Permet de copier des fichiers et répertoires
COPY ‹src› ‹dest›
COPY ["‹src›",... "‹dest›"] Permet de copier des fichiers dans le système de fichier du conteneur.
ENTRYPOINT ["executable", "param1", "param2"]`
ENTRYPOINT command param1 param2 Permet de configurer un conteneur qui peut être lancé comme un exécutable.
VOLUME ["/data"] Créé un point de montage avec le nom spécifié et le marque comme volume monté en interne.
USER daemon Définis le username ou UID à utiliser pour les commandes suivantes.
WORKDIR /path/to/workdir Définis le répertoire courant de travail.
ARG ‹name›[=‹default value›] Définis une variable que les utilisateurs peuvent passer au builder avec docker build --build-arg.
ONBUILD [INSTRUCTION] Ajoute une instruction déclencheur à une image. Le trigger est exécuté à la fin, quand l'image est utilisée comme base pour un autre build. Docker exécute le trigger dans le contexte du flux de build, comme s'il existait immédiatement après l'instruction FROM.
^
15 mars 2010

htmlpdflatexmanmd




dpkg

dpkg

Manipulation des paquets deb

   dpkg ne gère pas les dépôts, ni ne télécharge de paquet. Son rôle est de gérer les paquets deb. Cet outils est principalement utilisé par apt-get et aptitude pour installer ou supprimer des programmes. Il sert également, via dpkg-deb, à manipuler des paquets, extraire des fichiers, obtenir des informations sur un paquet ou créer un paquet. dpkg peut agir comme une interface à dpkg-deb. il lance simplement dpkg-deb s'il est lancé avec les options suivantes:

-b, --build
-c, --contents
-I, --info
-f, --field
-e, --control
-x, --extract
-X, --vextract
--fsys-tarfile

Renseignements sur les paquets

   dpkg conserve des renseignements utiles sur les paquets disponibles.

État des paquets

not-installed le paquet n'est pas installé
config-files seules les fichiers de configuration du paquet existent sur le système
half-installed l'installation du paquet a commencé mais ne s'est pas terminé
unpacked Le paquet est dépaqueté mais n'est pas configuré
half-configured Le paquet est dépaqueté et la configuration a commencé mais ne s'est pas terminée
triggers-pending Une action différée de ce paquet a été activé, il reste à l'exécuter
installed Le paquet est installé ETAT DE LA SELECTION DES PAQUETS
install Le paquet est sélectionné pour être installé
hold dpkg laisse de côté ce paquet à moins qu'il ne soit lancé avec --force-hold
deinstall Le paquet est sélectionné pour désinstallation (sauf ses fichiers de configuration)
purge Le paquet est sélectionné pour désinstallation complète DRAPEAU DES PAQUETS
reinst-required Paquet défectueux et demande une réinstallation. dpkg ne peut pas le supprimer sauf en spécifiant l'option --force-remove-reinstreq

Étapes des opérations

   lors de l'installation d'un paquet, dpkg procède comme suit:

1. extraction des fichiers de contrôle du paquet
2. si une ancienne version est déjà installé, exécution du script prerm de l'ancien paquet
3. lancement du script preinst, s'il est fournit
4. dépaquetage des nouveaux fichiers et sauvegarde des anciens de manière à pouvoir les restaurer en cas de problème.
5. Si une ancienne version existe, exécution du script postrm
6. configuration du paquet.

   Lors de la configuration d'un paquet, dpkg procède comme suit:

1. dépaquetage des fichiers de configuration et sauvegarde des ancienne
2. exécution du script postinst s'il est fourni

   Lors de la suppression d'un paquet, dpkg procède comme suit:

1. Lancement du script prerm
2. suppression des fichiers installés
3. lancement du script postrm

Actions

-i, --install installe le paquet. avec --recursive ou -R on doit indiquer un dossier
--unpack Dépaquète le paquet, mais ne configure rien. avec --recursive indiquer une répertoire.
--configure paquet -a|--pending Reconfiguration d'un paquet installé. avec -a ou --pending, tous les paquets installés mais non configurés sont configurés.
--triggers-only paquet .... -a|--pending N'exécute que les actions différées de ces paquets
-r, --remove, -P, --purge paquet -a|--pending supprime un paquet installé. Les fichiers de configuration sont les fichiers répertoriés dans le fichier de contrôle debian/conffiles. l'option -a ou --pending, tous les paquets non dépaquetés mais qui sont marqués comme devant être supprimés ou purgés dans le fichier /var/lib/dpkg/status sont supprimés ou purgés.
--update-avail, --merge-avail fichier-Paquets met à jour l'information de dpkg et de dselect sur les paquets disponibles. --merge-avail combine les information anciennes avec celles qui proviennent de fichier-Paquets. --update-avail remplace les informations anciennes par celles du fichier-Paquets. Ce fichier distribué par Debian est appelé Packages. dpkg garde son propre enregistrement des paquets disponibles dans /var/lib/dpkg/available. Ce fichier n'est utile que pour dselect, pas pour APT.
-A, --record-avail fichier-paquet met à jour l'information de dpkg et dselect sur les paquets disponibles avec les informations qui proviennent de fichier-paquet. --recursive ou -R pour indiquer un répertoire
--clear-avail Efface les renseignements existants sur les paquets disponibles.
-C, --audit Recherche les paquets qui n'ont été que partiellement installés sur le système. dpkg suggère une manière de les faire fonctionner
--get-selections [motif-nom-paquet] Obtient la liste des sélections des paquets, et l'envoie sur la sortie standard. Sans un motif, les paquets non installés (c'est à dire ceux qui ont été précédemment purgés) ne seront pas affichés.
--set-selections modifie la liste des sélections des paquets en lisant un fichier sur l'entrée standard. Le format de ce fichier doit être de la forme ‹paquet› ‹état›, où état vaut install, hold, deinstall ou purge. Les lignes vides ou les lignes de commentaires débutant par # sont autorisées.
--clear-selections Met l'état de chaque paquet non essentiel à deinstall. Il faut utiliser cette option juste avant --set-selections, pour désinstaller les paquets qui ne sont pas affichés par --set-selections.
--yet-to-unpack Recherche les paquets qui ont été sélectionnés pour l'installation, mais qui pour une raison quelconque, ne sont pas encore installés.
--print-architecture Affiche l'architecture des paquets installés
--compare-versions ver1 op ver2 Compare des numéros de version, où op est un opérateur binaire. dpkg retourne un zéro si la condition spécifiée est vérifiée. Il y a deux groupes d'opérateurs ; Pour lt le eq ne ge gt, l'absence d'une version est considérée comme inférieure à toute version ; pour lt-nl le-nl ge-nl gt-nl, l'absence d'une version est considérée comme supérieure à toute version. Les opérateurs ‹ ‹‹ ‹= = ›= ›› › ne sont fournis que pour la compatibilité avec la syntaxe du fichier de contrôle.
--command-fd ‹n› Cette action accepte une série de commandes sur le descripteur du fichier d'entrée ‹n›. Note : des options supplémentaires définies sur la ligne de commande à travers ce descripteur de fichier ne sont pas redéfinies pour les commandes suivantes qui sont exécutées pendant la même séquence.
--help Affiche un court message d'aide.
--force-help Donne des renseignements sur les options --force-quelque-chose.
-D, --debug=help donne des renseignements sur les options de débogage.
--licence, --license Affiche la licence de dpkg.
--version Affiche la version de dpkg.

Actions dpkg-deb

-b, --build répertoire archive Construit un paquet deb.
-c, --contents archive Liste le contenu d'un paquet deb.
-e, --control nom-de-fichier [répertoire] Extrait les informations de contrôle d'un paquet.
-x, --extract ‹répertoire de l'archive› Extrait et affiche les fichiers contenus dans un paquet.
-f, --field nom-de-fichier [champ de contrôle] ... Affiche le(s) champ(s) de contrôle d'un paquet.
--fsys-tarfile archive Affiche le contenu du fichier « tar » d'un paquet Debian.
-I, --info nom-de-fichier [fichier de contrôle] Affiche des renseignements sur un paquet.
dpkg-query actions Voir dpkg-query pour davantage d'explications sur les actions suivantes.
-l, --list motif-du-nom-du-paquet ... Affiche la liste des paquets qui correspondent au motif.
-s, --status nom-du-paquet ... Donne l'état du paquet indiqué.
-L, --listfiles nom-paquet ... Affiche la liste des fichiers installés qui appartiennent à paquet.
-S, --search motif-du-fichier-à-rechercher ... Recherche un fichier dans les paquets installés.
-p, --print-avail nom-du-paquet Affiche les informations trouvées dans /var/lib/dpkg/available à propos de paquet. Les utilisateurs des interfaces à APT devraient plutôt utiliser apt-cache show nom-du-paquet

OPTIONS

   Toutes les options peuvent être spécifiées sur la ligne de commande et dans le fichier de configuration de dpkg /etc/dpkg/dpkg.cfg ou les fichiers de configuration du dossier /etc/dpkg/dpkg.cfg.d/.

--abort-after=nombre Modifie le nombre d'erreurs au delà duquel dpkg s'arrête. Il est par défaut égal à 50.
-B, --auto-deconfigure Quand un paquet est supprimé, il peut arriver qu'un paquet installé dépendait du paquet supprimé. En spécifiant cette option, on obtient la déconfiguration automatique du paquet qui dépendait du paquet supprimé.
-Doctal, --debug=octal Demande de débogage.
--force-quelque-chose, --no-force-quelque-chose, --refuse-quelque-chose Forcer ou refuser (no-force et refuse signifient la même chose) de faire quelque chose. quelque-chose est une liste d'actions séparées par des virgules, décrites ci-après. --force-help affiche un message qui les décrit. Les actions marquées d'un (*) sont forcées par défaut.

        all Met en oeuvre (ou pas) toutes les options de forçage.
        downgrade(*) Installe un paquet, même si une version plus récente du paquet est déjà installée.
        configure-any Configure aussi les paquets dépaquetés mais non configurés dont dépend le paquet en question.
        hold Traite même les paquets marqués à garder (hold).
        remove-reinstreq Supprime un paquet, même défectueux et marqué comme demandant une réinstallation. Il se peut, dès lors, que des éléments du paquet restent dans le système et soient oubliés par dpkg.
        remove-essential supprime un paquet même s'il est considéré comme indispensable. Les paquets Essential comportent les commandes Unix les plus fondamentales et les enlever peut casser le système entier. Il faut utiliser cette option avec prudence.
        depends Change tous les problèmes de dépendance en avertissements.
        depends-version Ignore les versions dans les questions de dépendance.
        breaks Force l'installation, même si cela risque de casser un autre paquet.
        conflicts Installe un paquet, même s'il est en conflit avec un autre paquet. C'est dangereux car habituellement cela produit le remplacement de certains fichiers.
        confmiss Installe un fichier de configuration manquant. Cette opération est dangereuse, puisque les changements apportés au fichier ne seront pas préservés (suppression).
        confnew Quand un conffile a été modifié, toujours installer la nouvelle version et ne rien demander, sauf si l'option --force-confdef est aussi présente, auquel cas l'action par défaut est choisie.
        confold Quand un conffile a été modifié, garder l'ancienne version et ne rien demander, sauf si l'option --force-confdef est aussi présente, auquel cas l'action par défaut est choisie.
        confdef Utilise toujours l'action par défaut quand un conffile a été modifié. Quand il n'y a pas d'action par défaut, la commande s'arrête et interroge l'utilisateur, à moins que l'option --force-confnew ou l'option --force-confold n'ait été donnée, auquel cas elle se sert de ces options pour déterminer ce qu'il faut faire.
        overwrite Remplace un fichier par un fichier d'un autre paquet.
        overwrite-dir Remplace un répertoire par un répertoire d'un autre paquet.
        overwrite-diverted Remplace un fichier détourné avec une version non détournée.
        architecture Traite même les paquets d'une autre architecture
        bad-path Programmes importants non visibles par la variable PATH, ce qui va poser des problèmes.
        not-root Tente de (dés)installer même sans être root.
        bad-verify Installe un paquet même si la vérification de son authenticité a échoué.

--ignore-depends=paquet,... Ne tient pas compte de la vérification des dépendances pour les paquets spécifiés (en fait, la vérification est faite mais on ne donne rien d'autre que des avertissements).
--new, --old Sélectionne soit l'ancien format des paquet binaires, soit le nouveau. C'est une option de dpkg-deb.
--nocheck Ne pas lire ni vérifier le contenu du fichier de contrôle pendant la construction d'un paquet. C'est une option de dpkg-deb.
--no-act, --dry-run, --simulate Faire tout ce qui doit être fait, mais n'écrire aucune modification. On utilise cette option pour voir ce qui se passe sans modifier quoi que ce soit. Assurez-vous de donner l'option --no-act avant le paramètre action !
-R, --recursive Traite récursivement tous les simples fichiers qui correspondent au motif *.deb et qui se trouvent dans les répertoires et sous-répertoires spécifiés. On peut utiliser cette option avec les actions -i, -A, --install, --unpack et --avail.
-G Ne pas installer un paquet si une version plus récente de ce paquet est déjà installée. C'est un alias pour --refuse-downgrade.
--admindir=dir Modifie le répertoire d'administration par défaut, qui contient de nombreux fichiers donnant des informations au sujet de l'état des paquets installés ou non, etc. (Le répertoire par défaut étant /var/lib/dpkg)
--instdir=repertoire Change le répertoire d'installation par défaut qui indique où les paquets vont être installés. instdir est aussi le nom du répertoire indiqué à chroot avant que ne soient lancés les scripts d'installation, ce qui signifie que ces scripts voient instdir comme répertoire racine. Le répertoire par défaut est /
--root=répertoire Modifier root change instdir par répertoire et admindir par dir/var/lib/dpkg.
-O, --selected-only Traiter seulement les paquets qui sont sélectionnés pour l'installation. La sélection est réellement faite par dselect ou par dpkg quand ils manipulent les paquets. Par exemple, quand un paquet est supprimé, il est marqué comme ayant été sélectionné pour une désinstallation.
-E, --skip-same-version Ne pas installer le paquet si la même version du paquet est déjà installée.
--pre-invoke=command
--post-invoke=command Set an invoke hook command to be run via “sh -c” before or after the dpkg run
--status-fd n Envoie un état du paquet compréhensible par la machine et met à jour cette information dans le fichier de description n. Cette option peut être spécifiée plusieurs fois. L'information est généralement constituée d'un enregistrement par ligne, dans l'une des formes suivantes:

        status:paquet:status L'état du paquet a changé ; le status est tel que dans le fichier d'état (status file).
        status:paquet:erreur:message-d'erreur-complet Une erreur s'est produite. Malheureusement, lors de l'écriture il se trouve que message-d'erreur-complet peut contenir des retour à la ligne, alors que dans les locales où les traducteurs n'ont pas fait d'erreurs, chaque nouvelle ligne est suivie par au moins une espace.
        status:fichier:conffile-prompt:'real-old' 'real-new' useredited distedited Une question pour un fichier de configuration va être posée à l'utilisateur.
        traitement:stage:paquet Envoyé juste avant le début du traitement d'un stage. Les stages sont upgrade, install (les deux sont envoyés avant le dépaquetage), configure, trigproc, remove, purge.

--log=fichier Enregistre la modification de l'état, la mise à jour ou l'action sur fichier au lieu de l'habituel /var/log/dpkg.log. Si cette option est donnée plusieurs fois, le dernier fichier est utilisé. Les messages d'enregistrement sont de la forme AAAA-MM-JJ HH:MM:SS status ‹état› ‹paquet› ‹version-installée› pour les modifications d'état et les mises à jour. Pour une action, où ‹action› est install, upgrade, remove ou purge, le message est de la forme AAAA-MM-JJ HH:MM:SS ‹action› ‹paquet› ‹version-installée› ‹version-disponible›. Pour une modification de conffile, le message est de la forme AAAA-MM-JJ HH:MM:SS conffile ‹fichier› ‹décision› ou ‹décision› est soit install soit keep.
--no-debsig Ne pas tenter de vérifier la signature des paquets.
--no-triggers ne pas lancer d'actions différées (les activations seront toujours enregistrées). utilisé avec --configure paquet ou --triggers-only paquet alors le postinst du paquet sera toujours exécuté même si seule l'exécution d'une action différée est nécessaire. L'utilisation de cette option peut laisser des paquets dans les mauvais états triggers-awaited et triggers-pending. Cela peut être corrigé plus tard en exécutant dpkg --configure --pending.
--triggers Annule un précédent --no-triggers.

Fichiers

/etc/dpkg/dpkg.cfg Fichier de configuration contenant les options par défaut.
/var/log/dpkg.log Fichier journal standard. Voyez /etc/dpkg/dpkg.cfg et l'option --log.

   Les autres fichiers répertoriés ici sont dans leur répertoire par défaut, voyez l'option --admindir pour savoir changer l'emplacement de ces fichiers.

/var/lib/dpkg/available Liste des paquets disponibles.
/var/lib/dpkg/status États des paquets disponibles. Ce fichier contient des informations qui permettent de savoir si un paquet est marqué comme devant être supprimé ou pas, devant être installé ou pas, etc. Ce fichier est quotidiennement backupé dans /var/backups.

Exemples

Pour afficher les paquets liés au programme vi(1)
dpkg -l '*vi*'
Pour voir les entrées de /var/lib/dpkg/available concernant deux paquets
dpkg --print-avail elvis vim | less
Pour rechercher vous-même dans la liste des paquets
less /var/lib/dpkg/available
Pour supprimer le paquet installé elvis
dpkg -r elvis
Pour installer un paquet, vous devez d'abord le trouver dans une archive ou sur un CD. Le fichier available montre que le paquet vim se trouve dans la section editors
cd /cdrom/pool/main/v/vim ; dpkg -i vim_4.5-3.deb
Pour faire une copie locale des états de sélection des paquets
dpkg --get-selections ›myselections
Vous pourriez transférer ce fichier sur un autre ordinateur et l'installer de cette manière
dpkg --clear-selections ; dpkg --set-selections ‹myselections
^
15 mars 2010

htmlpdflatexmanmd




dpkg-deb

dpkg-deb

Outil de manipulation des archives des paquets Debian. Ce programme n'est pas appelé directement mais depuis dpkg généralement.

   dpkg-deb crée un paquet, décompresse une archive ou donne des renseignements sur les archives Debian, alors que dpkg sert à installer ou à supprimer des paquets sur le système.

Commandes

-b, --build repertoire [archive|repertoire] Créer une archive avec l'arborescence contenue dans repertoire. archive est le nom à donner à l'archive. si le 2eme argument est un répertoire, le paquet est appelé paquet_version_arch.deb ou bien paquet_version si aucun champ Architecture n'est présent dans le fichier de contrôle.
-I, --info archive [nom-fichier-control...] Donne des renseignements sur une archive de paquet binaire.
-W, --show archive Cette option donne des informations sur l'archive d'un paquet binaire
-f, --field archive [nom-du-champ-de-control...] Extrait les renseignements du fichier control de l'archive
-c, --contents archive Liste l'arborescence des fichiers d'une archive
-x, --extract archive repertoire Extraire l'arborescence des fichiers d'un paquet dans le répertoire root
-X, --vextract archive repertoire idem mais affiche la liste des fichiers à mesure qu'ils sont extraits
--fsys-tarfile archive Extrait les données de l'arborescence d'un paquet binaire et les envoie sur la sortie standard dans le format propre à tar. Permet d'extraire un fichier précis.
-e, --control archive [repertoire] Extrait les fichiers de contrôle d'une archive dans le répertoire spécifié

OPTIONS

--showformat=format Sert à spécifier le format de sortie de l'option --show (voir dpkg-query)
-zniveau_compression Indique le niveau de compression
-Ztype_compression Indique le type de compression (gzip, bzip2, lzma et none)
--new s'assure que dpkg-deb construit une archive avec le nouveau format.
--old oblige dpkg-deb à construire une archive avec l'ancien format
--nocheck Empêche les vérifications normales de dpkg-deb --build

   Pour créer le fichier control voir man deb-control
^
15 mars 2010

htmlpdflatexmanmd




dpkg-query

dpkg-query

Outil pour interroger la base de données de dpkg et afficher des informations sur les paquets connus par la base de données de dpkg

OPTIONS

-l, --list motif Affiche les paquets correspondants à motif. Sans motif, affiche tous les paquets de /var/lib/dpkg/status, sauf ceux qui ne sont pas installés (équivalent à dpkg -l)
-W, --show motif Identique à --list mais dans un format formaté.
-s, --status paquet Donne l'état du paquet (indique les fichiers de configuration)
-L, --listfiles paquet Affiche la liste des fichiers de paquet
-c, --control-path paquet [control-file] liste les chemins des fichiers de contrôle
-S, --search motif Recherche un nom de fichier dans les paquets installés (équivalent dpkg -S)
-p, --print-avail paquet Affiche les détails relatifs à paquet tels que présents dans /var/lib/dpkg/available
--admindir=dir Change l'endroit où se trouve la base de données de dpkg (défaut /var/lib/dpkg)
-f, --showformat=format sert à spécifier le format de sortie de --show

        \n nouvelle ligne
        \r retour chariot
        \t tabulation

   L'information relative à un paquet peut être indiquée en insérant des appels de variables spécifiant des champs du paquet avec la syntaxe suivante: "${field[ ;width]}". Les champs sont alignés à droite, à moins que la largeur ne soit négative, auquel cas ils sont alignés à gauche. Les champs suivants sont reconnus, mais pas nécessairement disponibles dans le fichier d'état (seuls les champs internes ou les champs conservés avec le paquet binaire le sont):

        Architecture
        Bugs
        Conffiles (interne)
        Config-Version (interne)
        Conflicts
        Breaks
        Depends
        Description
        Enhances
        Essential
        Filename (interne, lié à dselect)
        Homepage
        Installed-Size
        MD5sum (interne, lié à dselect)
        MSDOS-Filename (interne, lié à dselect)
        Maintainer
        Origin
        Package
        Pre-Depends
        Priority
        Provides
        Recommends
        Replaces
        Revision (obsolète)
        Section
        Size (interne, lié à dselect)
        Source
        Status (interne)
        Suggests
        Tag (pas dans le .deb mais dans les fichiers Packages d'APT)
        Triggers-Awaited (interne)
        Triggers-Pending (interne)
        Version

   Le format par défaut est le suivant : "${binary:Package}\t${Version}\n"
^
22 mai 2017

htmlpdflatexmanmd




dracut

dracut

Outil bas niveau pour générer une image initramfs

   Créé une image initramfs pour la version kernel spécifiée. Si la version kernel est omise, la version courante est utilisée. Si l'image n'est pas spécifié, l'emplacement par défaut est utilisée. Si vous être basculé dans un shell de récupération durant le boot, le fichier /run/initramfs/rdsosreport.txt est créé. Des informations de debuggage peuvent être ajoutés au boot en ajoutant rd.debug à la ligne de commande du kernel. /run/initramfs/rdsosreport.txt contient tous les logs et la sortie de certains outils.

Pour créer une image initramfs, la commande la plus simple est:
dracut
Si l'initramfs existe déjà, dracut affiche une erreur. Pour écraser l'image existante:
dracut --force
Pour spécifie un autre nom de fichier pour l'image
dracut foobar.img
Pour générer une image pour une version kernel spécifique:
dracut foobar.img 2.6.40-1.rc5.f20
Un raccourci pour générer l'image à l'emplacement par défaut:
dracut --kver 2.6.40-1.rc5.f20

   Pour créer des images plus petites, utiliser l'option --hostonly.

Pour voir le contenu d'une image créé:
lsinitrd | less
Pour afficher le contenu d'un fichier dans l'initramfs:
lsinitrd -f /etc/ld.so.conf
Certains modules dracut sont désactivés par défaut et doivent être activés manuellement. Les modules peuvent être ajoutés dans /etc/dracut.conf ou /etc/dracut.conf.d/myconf.conf.
dracut --att bootchart initramfs-bootchart.img
Pour voir une liste des modules dracut disponible
dracut --list-modules
Pour ajouter des modules kernel dans l'initramfs qui ne sont pas automatiquement ajoutés par dracut, utiliser l'option --add-drivers ou dans /etc/dracut.conf.
dracut --add-drivers mymod initramfs-with-mymod.img
Un initramfs généré sans le mode hostonly ne contient aucun fichiers de configuration système, donc la configuration doit être faite sur la ligne de commande kernel. Pour afficher la ligne de commande:
dracut --print-cmdline
Spécifier le périphérique root:
root=/dev/sda2
Spécifier les paramètres clavier
rd.vconsole.font=latarcyrheb-sun16 rd.vconsole.keymap=de-latin1-nodeadkeys rd.locale.LANG=de_DE.UTF-8
blacklister les modules kernel
rd.driver.blacklist=mptsas rd.driver.blacklist=nouveau
Pour accélerer le processus de démarrage il est possible de spécifier plus d'informations. Par exemple, on peut indiquer à dracut que la partition root n'est pas un volume LVM ni un raid
rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0
Injecter des fichiers personnalisés avec l'option --include
dracut --include cmdline-preset /etc/cmdline.d/mycmdline.conf initramfs-cmdline-pre.img
L'option --install permet de spécifier de nombreux fichier qui sont installés dans l'image initramfs aux même emplacement.
dracut --install 'strace fsck.ext3 ssh' initramfs-dbg.img
boot réseaux
ip=dhcp
Pour réduire la taille de l'image, il est possible d'omettre tous les modules dracut. On peut également spécifie les modules kernel et dracut exacte. Par exemple pour une image NFS:
dracut -m "nfs network base" initramfs-nfs-only.img
puis on eut réduire encore la taille avec --host-only
dracut -m "nfs network base" --host-only initramfs-nfs-host-only.img

Résolution de problèmes

   Si le processus de boot échoue, il existe de nombreuses options pour debugger la situation:

1. Supprimer "rhgb" et "quiet"
2. Ajouter 'rd.shell'
3. ajouter 'rd.shell rd.debug log_bug_len=1M'
4. /run/initramfs/rdsosreport.txt est généré et contient tous les logs et la sortie des outils important.

debugger dracut

Debugger dracut nécessite une console durant le boot. Cette section documente uen connection série pour enregistrer les messages de boot
1. Activer la console série pour le kernel et le bootloader
2. ouvrir /boot/grub2/grub.cfg, sous la ligne timeout=5, ajouter:
serial --unit=0 --speed=9600
terminal --timeout=5 serial console
3. ouvrir /boot/grub2/grub.cfg, ajouter les arguments de boot à la ligne kernel:
console-tty0 console=ttys0,9600
4. Rediriger la sortie non-interactive
exec ›/dev/kmsg 2›&1 ‹/dev/console

OPTIONS

--kver ‹kernel version› Définis la version kernel
-f, --force Écrase un initramfs existant
-a, --add ‹list of dracut modules› Ajoute des modules dracut. peut être spécifié plusieurs fois
--force-add ‹list of dracut modules› Force l'ajoute de modules dracut dans le jeu de modules par défaut. Peut être spécifié plusieurs fois
-o, --omit ‹list of dracut modules› Omet les modules dracut spécifié Peut être spécifié plusieurs fois
-m, --modules ‹list of drucat modules› Spécifie une liste de modules dracut à appeler pendant la construction de l'initramfs. Les modules sont localisé dans /usr/lib/dracut/modules.d. Peut être spécifié plusieurs fois. Cette option force dracut à n'inclure que les modules spécifiés dans la liste
-d, --drivers ‹list of kernel modules› Liste de modules kernel à inclure exclusivement dans l'initramfs, sans le suffixe .ko. Peut être spécifié plusieurs fois.
--add-drivers ‹list of kernel modules› Liste de modules kernel à ajouter à l'initramfs
--force-drivers ‹list of kernel modules› idem à add-drivers, mais s'assure que les pilotes sont chargés très tôt via modprobe
--omit-drivers ‹list of kernel modules› Liste de modules kernel à exclure de l'initramfs. peut être spécifié plusieurs fois
--filesystems ‹list of filesystems› Liste de modules de systèmes de fichier à inclure exclusivement dans l'initramfs. peut être spécifié plusieurs fois
-k, --kmoddir ‹kernel directory› Répertoire où rechercher les modules kernel.
--fwdir ‹dir›[:‹dir›...]++ Répertoires additionnels, où rechercher des firmwares. Peut être spécifié plusieurs fois
--kernel-cmdline ‹parameters› Paramètres de ligne de commande kernel par défaut
--kernel-only N'installe que les pilotes kernel et les firmwares
--no-kernel N'installe par les pilotes kernel ni les firmwares
--early-microcode Combine le microcode avec ramdisk
--no-early-microcode Ne combine pas le microcode avec ramdisk
--print-cmdline Affiche la ligne de commande kernel pour le layout disque courant
--mdadmconf Inclus /etc/mdadm.conf
--nomdadmconf N'inclus pas /etc/mdadm.conf
--lvmconf inclus /etc/lvm/lvm.conf
--nolvmconf N'inclus pas /etc/lvm/lvm.conf
--fscks [LIST] Ajoute une liste d'outils fsck, en plus de ceux spécifiés dans la configuration.
--nofscks inhibe l'installation des outils fsck
--strip strip les binaires dans l'initramfs
--nostrip ne strip pas les binaires dans l'initramfs
--prelink prelink les binaires dans l'initramfs
--noprelink ne prelink pas les binaires dans l'initramfs
--hardlink hardlink les fichiers dans l'initramfs
--nohardlink ne haldlink pas les fichiers dans l'initramfs
--prefix ‹dir› préfixe les fichiers dans l'initramfs avec le répertoire spécifié
--noprefix ne préfixe pas les fichiers dans l'initramfs
--debug Affiche des inforamtion de débuggage durant la construction
-v, --verbose mode verbeux
-q, --quiet mode silencieux
-c, --conf ‹dracut configuration file› spécifie le fichier de configuration à utiliser
--confdir ‹configuration directory› Spécifie le répertoire de configuration à utiliser
--tmpdir ‹temporary directory› Spécifie le répertoire temporaire à utiliser
--sshkey ‹sshkey file› Fichier de clé ssh utilisé avec le module ssh-client
--logfile ‹logfile› Fichier de log à utiliser
-l, --local Active le mode locale. dracut utilise les modules depuis le répertoire courant au-lieu des modules installés dans /usr/lib/dracut/modules.d.
-H, --hostonly Mode host-only: n'installe que ce qui est nécessaire pour booter l'hôte locale.
-N, --no-hostonly Désactive le mode host-only
--hostonly-cmdline Stocke les arguments de ligne de commande kernel nécessaires dans l'initramfs
--no-hostonly-cmdline Ne stocke pas les arguments de ligne de commande nécessaires dans l'initramfs
--hostonly-i18n Installe seulement le clavier nécessaire et les fonts en accord avec la configuration de l'hôte
--no-hostonly-i18n Installe tous les claviers et fonts disponibles
--persistent-policy ‹policy› Utiliser la stratégie pour adresses les disques et partitions. peut être un nom de répertoire dans /dev/disk (ex by-uuid, by-label)
--fstab Utilise /etc/fstab au lieu de /proc/self/mountinfo
--add-fstab ‹filename› Ajoute les entrées du fichier au fstab de l'initramfs
--mount "‹device› ‹mountpoint› ‹filesystem type› [‹filesystem options› [‹dump frequency› [‹fsck order›]]]" Monte de périphérique dans l'iniramfs.
--mount "‹mountpoint›" idem, mais les paramètres manquant sont déterminés en recherchant dans les montages courants
--add-device ‹device› Connecte le périphérique. Utile en mode hostonly pour le supporte du swap dans une partition lvm chiffrée.
-i, --include ‹SOURCE› ‹TARGET› Inclus les fichiers dans le répertoire source dans le répertoire cible dans l'initramfs. Peut être spécifié plusieurs fois
-I, --install ‹file list› Installe la liste de fichiers dans l'initramfs
--install-optional ‹file list› Installe la liste des fichiers dans l'initramfs, s'ils existent
--gzip Compresse l'initramfs avec gzip
--bzip2 Compresse l'initramfs avec bzip2
--lzma Compresse l'initramfs avec lwma
--xz Compresse l'initramfs avec xz
--lzo Compresse l'initramfs avec lzop
--lz4 Compresse l'initramfs avec lz4
--compress ‹compressor› Compresse l'initramfs avec le programme de compression spécifié.
--no-compress Ne compresse pas l'initramfs généré
--reproducible Crée des images reproductible
--no-reproducible Ne créé pas d'images reproductibles
--list-modules Liste les module dracut disponibles
-M, --show-modules Les les modules inclus durant la construction
--keep Conserve le répertoire temporaire pour débuggage
--printsize Affiche la taille du module installé
--profile Affiche les informations de profile du processus de construction
--ro-mnt Mount / et /usr en lecture seule
-L, --stdlog ‹level› Niveau de log, de 0 à 6.
--regenerate-all Régénère toutes les images initramfs dans l'emplacement par défaut avec les versions kernel trouvés dans le système.
--loginstall ‹DIR› Log tous les fichiers installés depuis l'hôte dans le répertoire spécifié
--uefi Créé un exécutable uefi.
--uefi-stub ‹FILE› Spécifie le stub loader UEFI, qui charge le kernel, initramfs et ligne de commande attachés. Défaut: /lib/systemd/boot/efi/linux‹EFI-MACHINE-TYPE-NAME›.efi.stub. ou /usr/lib/gummiboot/linux‹EFI-MACHINE-TYPE-NAME›.efi.stub
--kernel-image ‹FILE› Spécifie l'image kernel à inclure dans l'exécutable UEFI. Défaut: /lib/modules/‹KERNEL-VERSION›/vmlinuz ou /boot/vmlinuz-‹KERNEL-VERSION›

Fichiers

/var/log/dracut.log Fichier de log de la création de l'initramfs
/tmp/dracut.log fichier de log, si /var/log/dracut n'est pas accéssible en écriture
/etc/dracut.conf Fichier de configuration de dracut
/etc/dracut.conf.d/*.conf Fichiers de configurations de dracut
/usr/lib/dracut/dracut.conf.d/01-dist.conf /usr/lib/dracut/dracut.conf.d/02-rescue.conf /usr/lib/dracut/dracut.conf.d/50-nss-softokn.conf Fichiers de configurations de dracut
/etc/conf.d/ (initramfs) Fichiers sourcés dans l'initramfs pour définir les valeurs initiales
/etc/cmdline (initramfs) Contient des options de ligne de commande additionnelles
/etc/cmdline.d/*.conf (initramfs) Contient des options de ligne de commande additionnelles
^
22 mai 2017

htmlpdflatexmanmd




dracut.cmdline

dracut.cmdline

Options de ligne de commande kernel dracut

   Le périphérique root utilisé par le kernel est spécifié dans le fichier de configuration de boot dans la ligne de commande kernel, comme toujours. La spécification traditionnelle root=/dev/sda1 est toujours permise, mais non encouragée. Le périphérique root devrait être identifié par un label ou un uuid.

  Les paramètres "rd.*" mentionnés sans '=' sont des paramètres booléens. Si l'assignement avec '=' est manquant, '=1' est assumé.

Standard

init=‹path to real init› Spécifie le chemin du programme init à démarrer un fois l'initramfs terminé
root=‹path to blockdevice› Spécifie le périphérique à utilisé pour '/'
rootfstype=‹filesystem type› auto, si non spécifié
rootflags=‹mount options› Spécifie des options de montage additionnels pour '/'. Non spécifié, lit /etc/fstab du vrai '/'.
ro force '/' et '/usr' en lecture seule
rw force '/' et '/usr' en lecture écriture
rootfallback=‹path to blockdevice› Spécifie le périphérique block à utiliser comme périphérique root, si le root normal ne peut être trouvé
rd.auto rd.auto=1 ACtive l'auto-assemblage des périphérique spéciaux comme cryptoLUKS, dmraid, mdraid ou lvm.
rd.hostonly=0 Supprime tous ce qui est compilé dans la configuration de l'hôte. Celà permet de booter sur un changement de disque.
rd.cmdline=ask Demande à l'utilisateur des paramètres additionnels
rd.fstab=0 N'honore pas les options de montage spéciaux pour '/' dans /etc/fstab du vrai '/'
resume=‹path to resume partition› Résume depuis une partition swap
rd.skipfsck N'effectue pas de fsck pour '/' et '/usr'.

iso-scan/filename

   Utiliser iso-scan/filename avec une iso Fedora/Red Hat/CentOS fonctionne en copiant les paramètres cmdline kernel

Divers

rd.driver.blacklist=‹drivername›[,‹drivername›,...] Ne pas charger le module kernel. Peut être spécifié plusieurs fois
rd.driver.pre=‹drivername›[,‹drivername›,...] Force le chargement du module spécifié. Peut être spécifié plusieurs fois
rd.driver.post=‹drivername›[,‹drivername›,...] Force le chargement du module une fois tous les modules automatique ont été chargé. Peut être spécifié plusieurs fois
rd.retry=‹seconds› Délai pour retenter le initqueue pour configurer les périphériques. Défaut: 30s. après 2/3 du temps, les raids dégradés sont démarrés de force.
rd.timeout=‹seconds› Délai d'attente pour que les périphériques apparaissent. Défaut: 0 - indéfinis. noter que ce délai ne devrait pas dépasser rd.retry
rd.noverifyssl Accèpte les certificats auto-signés pour les téléchargements ssl
rd.ctty=‹terminal device› Spécifie le terminal de contrôle pour la console. Utile avec plusieurs console=*.

debug

rd.info AFfiche des informations supplémentaires même si 'quiet' est spécifié
rd.shell Permet d'être basculé dans un shell si le montage root échoue
ld.debug définis -x pour le shell dracut. Si systemd est actif dans l'initramfs, toute la sortie est loggée dans le journal système.
rd.memdebug=[0-3] Affiche l'utilisation mémoire, de 0 à 3
rd.break Bascule dans un shell à la fin
rd.break={cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup} Bascule dans un shell au breakpoint définis
rd.udev.info Définis le niveau de log udev à info
rd.udev.debug Définis le niveau de log udev à debug

I18N

rd.vconsole.keymap=‹keymap base file name› Table de traduction clavier chargé par loadkeys; pris depuis le répertoires de keymaps. Écris dans KEYMAP dans /etc/vconsole.conf dans l'initramfs
rd.vconsole.keymap.ext=‹list of keymap base file names› Liste de keymaps supplémentaires, écris d-ans EXT_KEYMAP dans /etc/vconsole.conf
rd.vconsole.unicode (bool) Indique le mode utf-8. Sera écrit dans UNICODE dans /etc/vconsole.conf
rd.vconsole.font=‹font base file name› Police de caractère de la console. Écris dans FONT dans /etc/vconsole.conf
rd.vconsole.font.map=‹console map base file name› Voir setfont -m.
rd.vconsole.font.unimap=‹unicode table base file name› Voir setfont -u
rd.locale.LANG=‹locale› Pris depuis l'environnement.
rd.locale.LC_ALL=‹locale› Pris depuis l'environnement

LVM

rd.lvm=0 Désactive la détection LVM
rd.lvm.vg=‹volume group name› N'active que ce groupe de volume. Peut être spécifié plusieurs fois
rd.lvm.lv=‹logical volume name› N'active que les volumes logique spécifiés. Peut être spécifié plusieurs fois
ld.lvm.conf=0 Supprime tout /etc/lvm/lvm.conf, qui pourrait exister dans l'initramfs

LUKS

ld.luks=0 Désactive la détection LUKS
rd.luks.uuid=‹luks uuid› N'active que les partitions LUKS avec l'uuid donné.
rd.luks.allow-discards=‹luks uuid› Permet l'utilisations des requêtes discards (TRIM) pour les partitions LUKS avec l'uuid donné.
rd.luks.allow-discards Permet l'utilisations des requêtes discards (TRIM) pour toutes les partitions LUKS
rd.luks.crypttab=0 Ne vérifie pas si la partition LUKS est dans /etc/crypttab

LUKS - key on removable device support

rd.luks.key=‹keypath›:‹keydev›:‹luksdev› keypath est le chemin d'une clé à rechercher. si keypath fini par .gpg, c'est une clé symétrique GPG. keydev est un périphérique sur lequel la clé réside. Peut être un périphérique, UUID ou label. luksdev indique le périphérique luks auquel s'applique la clé.

md raid

rd.md=0 Désactive la détection raid
rd.md.imsm=0 Désactive les raids imsm/ism
rd.md.ddf=0 Désactive les raids ddf
rd.md.conf=0 Ignore mdadm.conf inclus dans l'initramfs
rd.md.waitclean=1 Attends la fin des resynchro, récupération, ou reshape avant de continuer
rd.md.uuid=‹md raid uuid› N'active que le raid avec l'uuid spécifié. peut être spécifié plusieurs fois

dm raid

rd.dm=0 Désactive la détection dm raid
rd.dm.uuid=‹dm raid uuid› N'active que le raid avec l'uuid spécifié. peut être spécifié plusieurs fois

multipath

rd.multipath=0 Désactive la detection multipath

FIPS

rd.fips Active FIPS
rd.fips.skipkernel Ne vérifie pas le checksum de l'image kernel

Réseau

ip={dhcp|on|any|dhcp6|auto6} spécifie la méthode d'obtention d'une adresse ip
ip=‹interface›:{dhcp|on|any|dhcp6|auto6}[:[‹mtu›][:‹macaddr›]] idem, spécifique à une interface. peut être spécifié plusieurs fois
ip=‹client-IP›:[‹peer›]:‹gateway-IP›:‹netmask›:‹client_hostname›:‹interface›:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[‹mtu›][:‹macaddr›]] Configuration réseau explicite. Peut être spécifié plusieurs fois
ip=‹client-IP›:[‹peer›]:‹gateway-IP›:‹netmask›:‹client_hostname›:‹interface›:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[‹dns1›][:‹dns2›]] configuration réseau explicite.
ifname=‹interface›:‹MAC› Assigne le nom spécifié au périphérique réseau.
rd.route=‹net›/‹netmask›:‹gateway›[:‹interface›] Ajouter une route statique.
bootdev=‹interface› Spécifie l'interface réseau à utiliser pour les informations netroot et de routage. Requis si plusieurs lignes ip= sont utilisées
BOOTIF=‹MAC› Spécifie l'interface réseau à utiliser pour les informations netroot et de routage.
rd.bootif=0 Désactive le parsing BOOTIF, qui est fournis par PXE
nameserver=‹IP› [nameserver=‹IP› ...] Spécifie les serveurs de noms à utiliser
rd.peerdns=0 Désactive le paramètre DNS des paramètres DHCP
biosdevname=0 désactive le renommage d'interface réseau biosdevname
rd.reednet=1 active l'événement réseau sans netroot définis
vlan=‹vlanname›:‹phydevice› Définis un périphérique vlan
bond=‹bondname›[:‹bondslaves›:[:‹options›]] Définis une périphérique bond
team=‹teammaster›:‹teamslaves› Définis un périphérique team
bridge=‹bridgename›:‹ethnames› Définis un périphérique bridge

NFS

root=[‹server-ip›:]‹root-dir›[:‹nfs-options›] Monte un partage NFS. si aucun serveur n'est donné, utilise dhcp
root={dhcp|dhcp6} permet de rechercher le chemin de root via dhcp
rd.nfs.domain=‹NFSv4 domain name› Spécifie le domaine NFSv4. Écrase les paramètres dans /etc/idmap.conf
rd.net.dhcp.retry=‹cnt› Si définis, dracut tente de se connecter via dhcp, cnt fois avant d'échouer. Défaut: 1
rd.net.timeout.dhcp=‹arg› Si définis, dhclient est appelé sans "-timeout ‹arg›"
rd.net.timeout.iflink=‹seconds› Délai d'attente d'activation des liens. Défaut: 60
rd.net.timeout.ifup=‹seconds› Délai d'attente de l'état "up" des lient. Défaut: 20
rd.net.timeout.route=‹seconds› Délai d'attente d'activation des routes. Défaut: 20
rd.net.timeout.ipv6dad=‹seconds› Délai d'attente pour IPv6 DAD. Défaut: 50
rd.net.timeout.ipv6auto=‹seconds› Délai d'attente pour l'adressage ipv6 automatique. Défaut: 40
rd.net.timeout.carrier=‹seconds› Délai d'attente de reconnaissance du carrier. Défaut: 5

CIFS

root=cifs://[‹username›[:‹password›]@]‹server-ip›:‹root-dir› Définis un partage cifs
cifsuser=‹username› username cifs
cifspass=‹password› password cifs

iSCSI

root=iscsi:[‹username›:‹password›[:‹reverse›:‹password›]@][‹servername›]:[‹protocol›]:[‹port›][:[‹iscsi_iface_name›]:[‹netdev_name›]]:[‹LUN›]:‹targetname› Définis un accès iSCSI pour root
root=???
netroot=iscsi:[‹username›:‹password›[:‹reverse›:‹password›]@][‹servername›]:[‹protocol›]:[‹port›][:[‹iscsi_iface_name›]:[‹netdev_name›]]:[‹LUN›]:‹targetname› Plusieurs options netroot sont permis pour définir plusieurs disques iscsi
root=??? rd.iscsi.initiator=‹initiator› rd.iscsi.target.name=‹target name› rd.iscsi.target.ip=‹target ip›
rd.iscsi.target.port=‹target port› rd.iscsi.target.group=‹target group› rd.iscsi.username=‹username›
rd.iscsi.password=‹password› rd.iscsi.in.username=‹in username› rd.iscsi.in.password=‹in password› Spécifier manuellement tous les paramètres iscsistart.
root=??? netroot=iscsi rd.iscsi.firmware=1 Li le paramètre iscsi depuis le firmware BIOS
rd.iscsi.param=‹param› Le paramètre est passé à iscsistart. peut être spécifié plusieurs fois
rd.iscsi.ibft rd.iscsi.ibft=1 Active l'autoconfiguration iBFT pour les interfaces
rd.iscsi.waitnet=0 Désactive l'attente que toutes les interfaces soient actives avant de tenter une connection aux targets iSCSI
rd.iscsi.testroute=0 Désactive la vérification, si la route vers de target iSCSI est possible avant de tenter une connection

FCoE

fcoe=‹edd|interface|MAC›:{dcb|nodcb} Définis une connexion FCoE via l'interface spécifiée.

NBD

root=??? netroot=nbd:‹server›:‹port/exportname›[:‹fstype›[:‹mountopts›[:‹nbdopts›]]] Mounte un partage nbd.
root=dhcp dhcp root-path=nbd:‹server›:‹port/exportname›[:‹fstype›[:‹mountopts›[:‹nbdopts›]]] récupère les informations nbd via dhcp.

DASD

rd.dasd=... Même syntaxe que le paramètre du module kernel.

ZFCP

rd.zfcp=‹zfcp adaptor device bus ID›,‹WWPN›,‹FCPLUN› Peut être spécifié plusieurs fois
rd.zfcp.conf=0 ignore zfcp.conf inclus dans l'initramfs

ZNET

rd.znet=‹nettype›,‹subchannels›,‹options› Peut être spécifié plusieurs fois

Booter des images live

   dracut offre plusieurs options pour les images live.

  SquashFS Le système boot avec un fs readonly depuis le squashfs et applique un dm rw par dessus le fs readonly.

  non compressé Quand le système live est installé avec --skipconpress, le système root ext3fs.img, est étendu à l'installation et aucun squashfs n'est utilisé durant le boot.

  image writable Le système récupère une image compressée, l'extrait dans /run/initramfs/fsimg/rootfs.img, la connecte dans un périphérique loop, créé un dm writable à /dev/mapper/live-rw et le monte comme volume rw à /.

rd.writable.fsimg=1 ACtive le support de système de fichier rw.
root=live:‹url› Boot une image live récupérée depuis l'url spécifié. (http, https, ftp, terrent, tftp)
rd.live.debug=1 Active la sortie debug du processus de boot
rd.live.dir=‹path› Spécifie le répetroire dans le squashfs où ext3fs.img ou rootfs.img peuvent être trouvés. Défaut: LiveOS
rd.live.squashimg=‹filename of SquashFS image› Spécifie le fichier d'une image squash du système de fichier root. Défaut: squashfs.img
rd.live.ram=1 Copie l'image complète en RAM et l'utilise pour booter. Utile quand l'image réside sur un DVD par ex. qui doit être éjeté ensuite.
rd.live.overlay=‹devspec›:(‹pathspec›|auto)|none Permet l'utilisation d'overlay permanent.
rd.live.overlay.size=‹size MiB› Spécifie une taille d'overlay persistant. Défaut: 512
rd.live.overlay.readonly=1 Spécifie un overlay rw non persistant stacké sur un snapshot ro.
rd.live.overlay.reset=1 Spécifie qu'un overlay persistant devrait être réinitialisés au boot.
rd.live.overlay.thin=1 Active l'utilisation de snapshots thin.

Plymouth

plymouth.enable=0 Désactive plymouth complètement
rd.plymouth=0 Désactive plymouth seulement dans l'initramfs

Clés kernel

masterkey=‹kernel master key path name› Définis la clé maître
masterkeytype=‹kernel master key type› Définis le type de clé maître
evmkey=‹EVM key path name› Définis le chemin de la clé EVM
ecryptfskey=‹eCryptfs key path name› Définis le chemin de la clé eCryptfs
^
22 mai 2017

htmlpdflatexmanmd




dracut.conf

dracut.conf

Fichier de configuration pour dracut

OPTIONS

add_dracutmodules+=" ‹dracut modules› " Ajoute la liste de modules dracut
dracutmodules+=" ‹dracut modules› " Liste de modules dracut à appeler
omit_dracutmodules+=" ‹dracut modules› " Omet la liste des modules dracut
drivers+=" ‹kernel modules› " liste de modules kernel à inclure exclusivement
add_drivers+=" ‹kernel modules› " liste de module à inclure
force_drivers+=" ‹list of kernel modules› " idem à add_drivers, mais s'assure que les pilotes sont chargés très tôt via modprobe
omit_drivers+=" ‹kernel modules› " liste de modules à ne pas ajouter
filesystems+=" ‹filesystem names› " Liste de modules fs à inclure exclusivement
drivers_dir="‹kernel modules directory›" Répertoire où rechercher les modules kernel
fw_dir+=" :‹dir›[:‹dir› ...] " Répertoire additionnel où rechercher les firmwares
install_items+=" ‹file›[ ‹file› ...] " Fichiers additionnels à inclure
install_optional_items+=" ‹file›[ ‹file› ...] " fichiers additionnels à inclure s'ils existent
compress="{bzip2|lzma|xz|gzip|lzo|lz4|‹compressor [args ...]›}" compression à utiliser
do_strip="{yes|no}" strip les binaire à inclure
do_prelink="{yes|no}" prelink les binaires à inclure
hostonly="{yes|no}" mode hostonly
hostonly_cmdline="{yes|no}" Stocke les arguments de ligne de commande dans l'initramfs
i18n_install_all="{yes|no}" Installe tous les fichiers claviers et font disponible
persistent_policy="‹policy›" Stratégie pour adressesr les disques et partitions. (ex: by-uuid, by-label)
tmpdir="‹temporary directory›" répertoire temporaire à utiliser
use_fstab="{yes|no}" Utilise /etc/fstab au lieur de /proc/self/mountinfo
add_fstab+=" ‹filename› " Ajoute les entrées dans le fichier au fstab de l'initramfs
add_device+=" ‹device› " Connecte le périphérique. Utile en mode hostonly pour le supporte du swap dans une partition lvm chiffrée.
mdadmconf="{yes|no}" Inclus /etc/mdadm.conf
lvmconf="{yes|no}" Inclus /etc/lvm/lvm.conf
fscks=" ‹fsck tools› " Ajoute une liste d'outils fsck. Défaut: "umount mount /sbin/fsck /sbin/fsck.btrfs /sbin/fsck.cramfs /sbin/fsck.ext2 /sbin/fsck.ext3 /sbin/fsck.ext4 /sbin/fsck.f2fs /sbin/fsck.fat /sbin/fsck.gfs2 /sbin/fsck.hfs /sbin/fsck.hfsplus /sbin/fsck.jfs /sbin/fsck.minix /sbin/fsck.msdos /sbin/fsck.ntfs /sbin/fsck.reiserfs /sbin/fsck.vfat /sbin/fsck.xfs xfs_db xfs_check xfs_repair e2fsck jfs_fsck reiserfsck btrfsck"
nofscks="{yes|no}" N'installe pas les outils fsck
ro_mnt="{yes|no}" mount '/' et '/usr' en lecture seule
kernel_cmdline="parameters" Spécifie les paramètres de ligne de commande du kernel
kernel_only="{yes|no}" Installe seulement les drivers et firmwares
no_kernel="{yes|no}" N'instanne pas les drivers et firmwares
acpi_override="{yes|no}" Remplace la table ACPI fournis par le BIOS.
acpi_table_dir="‹dir›" Répertoire où rechercher les tables ACPI.
early_microcode="{yes|no}" combine le microcode avec ramdisk
stdloglvl="{0-6}" Niveau de log de l'erreur standard
sysloglvl="{0-6}" Niveau de log syslog
fileloglvl="{0-6}" Niveau de log fichier
logfile="‹file›" Chemin du fichier de log
show_modules="{yes|no}" Affiche le nom des modules inclus sur stdout
i18n_vars="‹variable mapping›" voir dracut/modules.d/10i18n/README
i18n_default_font="‹fontname›" Font à installer.
i18n_install_all="{yes|no}" Installe tout
reproducible="{yes|no}" Créé une image reproductible
loginstall="‹DIR›" Log tous les fichiers installés depuis l'hôte dans le répertoire spécifié
uefi_stub="‹FILE›" Spécifie le loader UEFI qui va charger le kernel, initramfs et ligne de commande.
kernel_image="‹FILE›" Spécifie l'image kernel à inclure dans l'exécutable UEFI.
^
01 octobre 2014

htmlpdflatexmanmd




draft-armijo-ldap-treedelete-02

draft-armijo-ldap-treedelete-02

Contrôle de suppression d'arborescence

   Le contrôle est inclu dans un message DelRequest comme partie du champ controls. Le controlType est 1.2.840.113556.1.4.805, la criticité peut être TRUE ou FALSE, et controlValue est absent.

   Ce contrôle permet à un client de supprimer un subtree complet. Cela peut être fait seulement si l'utilisateur authentifié a les permissions pour compléter l'opération. Le serveur doit vérifier pour voir si l'utilisateur authentifié a les permissions appropriées pour supprimer l'objet et tous ses descendants. Ce contrôle doit seulement être utilisé avec un message DelRequest. Un serveur doit ignorer le contrôle s'il est utilisé avec un autre message sauf si la criticité est spécifiée. Dans ce cas, toute l'opération doit échouer avec le resultCode unsupportedCriticaleExtension. Les serveur prenant en compte ce contrôle doivent le lister dans supportedControl dans le rootDSE.

Sémantique

   Le demande tree delete peut être traitée comme une simple transaction atomique ou comme une séquence de transaction atomique. Dans le dernier cas, tous les états visible par le client produit par l'opération sont consistant avec l'exécution d'une séquence de demande delete normale. Le serveur ne devrait pas laisser traiter les objets d'un manière qui puisse laisser les objets orphelins.

   Si une demande tree delete échoue pour une quelconque raison, il peut être retenté et, si la nouvelle tentative réussi, le résultat est le même que si la demande initiale avait réussi. Le client devrait ré-émettre le delRequest jusqu'à ce que le serveur retourne un succès.

   Si un client émet une demande pour déplacer un objet dans ( ou créer un objet dans ) ou hors du subtree, en concurrence avec l'exécution d'une demande tree delete, l'effet est indéfinis. Le serveur n'est pas obligé de bloquer de telles requêtes.

   Le serveur ne doit pas poursuivre les références stockées dans l'arborescence. Si l'information sur les référants est stocké dans cet section, ce pointeur est supprimé.

Messages d'erreur

   Quand le contrôle tree delete est invoqué, le serveur doit vérifier pour voir si l'utilisateur authentifié a les permissions appropriées pour supprimer l'objet et toutes ses descendances. Si l'utilisateur n'a pas les permissions appropriées, un insufficientAccessRights(50) est retourné.

   Le serveur doit identifier tous les objets à supprimer avant que la suppression commence. Si le serveur a un problème à identifier les objets à supprimer, il peut retourner un operationsError(1). L'opération peut être re-tentée si cette erreur est retournée. Si le serveur n'a pas autorité sur des objets dans le subtree, le serveur devrait retourner unwillingToPerform(53).

   Les implémentation de serveurs peuvent avoir d'autres restriction sur quels conteneurs peuvent ou ne peuvent pas utiliser le contrôle Tree Delete. Si vous tentez de supprimer un conteneur qui ne peut pas être supprimé du à une restriction spécifique à la plate-forme, le serveur doit retourner unwillingToPerform(53). Le contrôle Tree Delet ne devrait par être re-tenté sur ce conteneur.

   Si la limite du nombre d'objets qui peuvent être supprimés en une opération est atteinte, le serveur devrait retourner adminLimitExceeded(11). Les objets traités jusqu'à ce point de limite devraient être supprimés. la demande DelRequest avec le contrôle Tree Delete devrait être ré-émis jusqu'à ce qu'une réponse success soit retourné par le serveur.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-automounter-04

draft-bannister-dbis-automounter-04

dbis: maps d'auto-montage

   Ce document étends DBIS pour supporter les bases automount. Le schéma de base automount devrait être compatible avec NIS, mais stocké dans des entrées X.500 pour qu'ils puissent être résolus via LDAP. Une base automount contient les informations sur les points de montage du système qui sont mappés par l'automonteur.

Maps de configuration

La base automount utilise les maps de configuration standard définis dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les base automount devraient avoir la classe dbisAutomountConfig. Il est recommandé que l'entrée dbisMapConfig pour une base automount ai d'attribut dbisMapFilter définis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - -
automount- -- objectClass=automountMapObject
- - - - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant donne un exemple d'une entrée de map de configuration pour une base automount:
dn: cn=automount,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisAutomountConfig
cn: automount
dbisMapDN: cn=automount,ou=dbis,o=infra
dbisMapFilter: objectClass=automountMapObject
profileTTL: 900
description: Primary automount database

Base de données

   Une base automount contient 3 types d'entrées différentes:

- Des entrées de map master
- Des entrées de map Direct
- Des entrées de map Indirect

   Une entrée master contient les informations suivantes:

- Le chemin à monter, ou /- pour les maps directs
- Le nom de map contenant les informations de montage pour ce chemin
- Les options de montage

   Une entrée directe contient:

- Le nom complet du point de montage
- Les options de montage
- Un ou plusieurs emplacement de système de fichier

   Une entrée indirecte contient:

- La clé utilisé pour déterminer le nom de la feuille de point de montage
- Les options de montage
- Un ou plusieurs emplacement de système de fichier

   Les maps directe et indirecte peuvent également inclure des entrées d'autre maps nommées. Une entrée à montage multiple définis plusieurs points de montage pour une seule clé dans une map indirect.

   Les options de montage, les symboles de substitution et wildcard peuvent être supportés par une implémentation mais sont au-delà du scope de ce document. Ce schéma n'applique aucune restriction sur l'utilisation d'options ou de symboles spéciaux, ni ne tente de les définir. À la place, ce document recherche à décrire un schéma et une structure qui supporte toute implémentation.

ObjectClass

   Une entrée dbisMapConfig pour une base automount devrait avoir la classe dbisAutomountConfig. Une entrée de map master devrait être définie par une entrée avec la classe automountMaster, qui est un sous-classe de automountMapObject. Une map directe ou indirecte devrait être identifiée par la classe automountMapObject. Les entrées dans une map donnée doivent être des objets enfant dans le DIT de la map à laquelle elle appartient et utiliser la classe automountEntry. Il n'y a pas de telles restriction d'emplacement sur les entrées automountMapObject, qui peuvent être localisées n'importe où dans le DIT tant qu'ils sont localisé par dbisMapDN et dbisMapFilter.

   La classe automountMulti devrait être utilisée pour identifier l'objet top-level dans une entrée de montage multiple. Chaque entrée dans le montage multiple devrait être un objet enfant dans le DIT avec la classe automountEntry. Un DUA peut choisir de ne pas supporter les entrées de montage multiples.

   Une map directe ou indirecte peut inclure les entrées d'une autre map par une entrée avec la classe automountInclude, qui devrait être un objet enfant dans le DIT d'un automountMapObject ou un automountMulti.

dbisAutomountConfig

La classe dbisAutomountConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.27 NAME 'dbisAutomountConfig' DESC 'DBIS automount configuration map' SUP dbisMapConfig STRUCTURAL )

automountMapObject

La classe automountMapObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.28 NAME 'automountMapObject' DESC 'Top-level of an automount map, entries are child nodes' SUP top STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

automountMaster

La classe automountMaster est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.29 NAME 'automountMaster' DESC 'Automounter master map entry' SUP automountMapObject STRUCTURAL MUST automountUseMap MAY automountOption )

automountEntry

La classe automountEntry est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.31 NAME 'automountEntry' DESC 'Automounter direct or indirect map entry' SUP top STRUCTURAL MUST ( en $ automountLocation ) MAY ( automountOption $ description $ manager $ disableObject ) )

   Les entrées de cette classe devraient être des objets enfant dans le DIT de l'automountMapObject auquel il appartient, sauf si elles font partie d'une montage multiple auquel cas elles doivent être enfant de leur entrée automountMulti correspondante.

automountInclude

La classe automountInclude est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.32 NAME 'automountInclude' DESC 'Include another map within an automounter direct map, indirect map or multiple mount entry' SUP top STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

   Le nom de la map à inclure devrait être fournie dans l'attribut en. Les règles pour localiser une entrée automountInclude dans le DIT sont les mêmes que pour une entrée automountEntry.

Attributs

en

   Le chemin à monter, la clé utilisée dans la map indirecte, ou le nom d'une map à inclure lorsqu'utilisé avec la classe automountInclude, est stocké dans l'attribut en, qui est définis dans draft-bannister-dbis-mapping. Ce attribut doit être associé avec les entrées automountMapObject, automountMaster, automountMulti, automountEntry et automountInclude et devrait former le RDN dans tous les cas.

automountUseMap

Le nom de la map d'auto-montage à utiliser avec l'entrée de map master est stocké dans l'attribut automountUseMap qui doit être assigné à une entrée automountMaster:
attributetype ( 1.3.6.1.4.1.23780.219.2.31 NAME 'automountUseMap' DESC 'Name of automount map associated with master map entry' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

automountOption

Chaque option d'auto-montage est stocké dans un ou plusieurs attributs automountOption qui peuvent être assignés à une entrée automountMaster, automountEntry ou automountMulti:
attributetype ( 1.3.6.1.4.1.23780.219.2.32 NAME 'automountOption' DESC 'Automounter option' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Les options disponibles sont spécifique à l'implémentation. Les options d'auto-montage ne sont pas additifs, par exemple, les options d'un automountEntry, si fournis, devraient écraser les options dans une entrée automountMulti ou automountMaster. Les options d'une entrée automountMulti devraient écraser les options d'une entrée automountMaster.

automountLocation

Le serveur de fichier et le chemin sont fournis dans un ou plusieurs attributs automountLocation qui doivent être assignés à un automountEntry:
attributetype ( 1.3.6.1.4.1.23780.219.2.33 NAME 'automountLocation' DESC 'Automounter location e.g. server:path' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Le format est spécifique à l'implémentation, mais typiquement "server:path". Le composant serveur peut être optionnel mais l'option (:) et le composant chemin ne le sont pas. Certaines implémentations supportent également plusieurs serveurs séparés par des virgules, ex, serverA,serverB:path, et des options de poids, ex, serverA(2),serverB(1):path, pour spécifier une préférence pour le second serveur dans la liste.

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'entrée.

disableObject

   Une entrée peut être désactivée en définissant disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivé, mais doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrées d'auto-montage

L'exemple suivant montre des entrées automountMaster au format LDIF:
dn: en=/home,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /home
automountOption: nobrowse
automountUseMap: auto_home
description: Master entry for /home, see auto_home map
    
dn: en=/qa,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /qa
automountUseMap: qa
description: Master entry for /qa, see qa map
    
dn: en=/media,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /media
automountUseMap: media
description: Master entry for /media, see media map
    
dn: en=/-,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /-
automountUseMap: auto_direct
description: Master entry for direct maps, see auto_direct

L'exemple suivant montre des entrées de map direct:
dn: en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_direct
description: auto_direct map entries are child objects
    
dn: en=/usr/install,en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /usr/install
automountOption: ro
automountLocation: esher,kingston(1):/export/install
automountLocation: hampton(3):/usr/install
description: Mount /usr/install from three possible servers

L'exemple suivant montre des entrées de map indirect:
dn: en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_home
description: auto_home map entries are child objects
    
dn: en=fred,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: fred
automountLocation: surbiton:/export/home/&
description: /home/fred
    
dn: en=sheila,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: sheila
automountLocation: surbiton:/export/home/&
description: /home/sheila
    
dn: en=*,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en:    *
automountLocation: ditton:/export/home/&
description: Catch-all for user home directories not listed
    
dn: en=surrey_home,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountInclude
en: surrey_home
description: Include entries from surrey_home map

L'exemple suivant montre un autre entrée de map indirect:
dn: en=media,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: media
description: media map entries are child objects
    
dn: en=cdrom,en=media,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: cdrom
automountOption: fstype=hsfs
automountOption: ro
automountLocation: :/dev/sr0
description: /media/cdrom

L'exemple suivant montre une entrée à montage multiple:
dn: en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: qa
description: qa map entries are child objects
    
dn: en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMulti
en: qa_root
automountOption: ro
description: qa_root multi-mount entries are child objects
    
dn: en=/,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /
automountLocation: esher:/export/qa
description: /qa
    
dn: en=/docs,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /docs
automountLocation: surbiton:/export/qa/docs
description: /qa/docs
    
dn: en=/tmp,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /tmp
automountOption: rw
automountLocation: surbiton:/export/qa/tmp
description: /qa/tmp

Syntaxe d'attributs

Les syntaxes d'attribut suivant sont utilisés par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID - - - - - - - - - -Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.12 DN - - - - - - - -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String - - - -[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage des champs NIS

   Tous les champs qui sont requis pour générer des format de base d'auto-montage NIS existent dans ce schéma et peuvent être mappés en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

Les champs de map master sont mappés comme suit:
mount-point = en
map-name = automountUseMap
mount-option = automountOption
    
master-entry = mount-point SPACE map-name *(SPACE mount-option)

Les champs de map directe sont mappés comme suit:
mount-point = en ; from automountEntry
mount-option = automountOption ; from automountEntry
location = automountLocation ; from automountEntry
include-map = en ; from automountInclude
    
mount = mount-point *(SPACE mount-option)
     1*(SPACE location)
include = PLUS include-map
    
direct-entry = mount / include

Les champs de map indirecte sont mappés comme suit:
mount-point = en ; from automountEntry
mount-option = automountOption ; from automountEntry
location = automountLocation ; from automountEntry
multi-key = en ; from parent automountMulti
multi-option = automountOption ; from parent automountMulti
include-map = en ; from automountInclude
    
mount = mount-point *(SPACE mount-option) 1*(SPACE location)
multi-mount = multi-key *(SPACE multi-option) 1*(LF SPACE mount-point *(SPACE mount-option) 1*(SPACE location))
include = PLUS include-map
    
direct-entry = mount / multi-mount / include

Filtres de recherche communs

   Cette section fournis des exemples de filtre de recherche pour obtenir des entrées de base avec des critères communément utilisés.

   Pour simplifier les exemples, toutes les base sont assumées être définies avec une simple map de configuration. Cependant, dbis permet plusieurs entrées, donc une implémentation doit le supporter, augmentant le nombre de recherches nécessaires pour localiser toutes les entrées de base.

   Le DN de base utilisé dans les opérations de recherche décrites dans cette section provient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plus d'une.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Les noms de classe et attribut utilisés dans ces filtres de recherche peuvent être modifiés par dbisMapClass et dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration d'un domaine DBIS:
(&(objectClass=dbisAutomountConfig)(!(disableObject=TRUE)))
Les maps master sont énumérées en appliquant le dbisMapFilter comme suit:
(&(dbisMapFilter)(objectClass=automountMaster)(!(disableObject=TRUE)))
Les maps directes et indirectes sont énumérées par le filtre suivant:
(&(dbisMapFilter)(!(objectClass=automountMaster))(!(disableObject=TRUE)))
Les entrées de map sont énumérée par le filtre suivant:
(&(objectClass=automountEntry)(!(disableObject=TRUE)))

   Pour différencier entrée une entrée de map simple et une entrée à montage multiple, l'objectClass dans l'entrée parent doit être testée. Si la classe est automountMulti, alors cette entrée fait partie d'une entrée à montage multiple. Dans ce cas, le DUA devrait tester disableObject=TRUE sur l'objet automountMulti. Si cet objet est marqué désactivé, les entrées enfant devraient également être traités comme désactivés.

Les entrées à montage multiples sont énumérées par le filtre suivant:
(&(objectClass=automountMulti)(!(disableObject=TRUE)))
Pour localiser une map spécifique appelée "name", utiliser le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))
Pour lister toutes les maps à inclure par une map spécifique appelée "name", utiliser le filtre précédent pour localiser le DN de la map, puis utiliser sur tous les objets enfants:
(&(objectClass=automountInclude)(!(disableObject=TRUE)))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-custom-03

draft-bannister-dbis-custom-03

dbis: maps custom

   Ce document étend DBIS pour supporter des bases custom. Le schéma de base custom devrait être compatible avec NIS mais stocké dans des entrées X.500 pour qu'ils puissent être résolus avec LDAP. Une base custom contient des paires de clé/valeurs arbitraires.

Maps de configuration

   Une base custom utilise les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases custom devraient avoir la classe dbisCustomConfig pour identifier qu'ils sont liés à une base custom.

Il est recommandé que l'entrée dbisMapConfig pour une base custom ait l'attribut dbisMapFilter définis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - -
custom- - - - objectClass=customMapEntry
- - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant montre une entrée de map de configuration pour une base custom appelée "console":
dn: cn=cons,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisCustomConfig
cn: cons
customMapName: console
dbisMapDN: ou=console,ou=dbis,o=infra
dbisMapFilter: objectClass=customMapEntry
profileTTL: 900
description: Primary console database (custom map)

Base de données

   Une entrée de base de données custom contient les informations suivantes:

- Un nom de clé
- Une valeur

ObjectClass

   Une entrée dbisMapConfig pour une base custom devrait avoir la classe dbisCustomConfig. Les entrées de map custom devraient avoir la class customMapEntry

dbisCustomConfig

La classe dbisCustomConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.33 NAME 'dbisCustomConfig' DESC 'DBIS custom database configuration map' SUP dbisMapConfig STRUCTURAL MUST customMapName )

customMapEntry

La classe customMapEntry est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.35 NAME 'customMapEntry' DESC 'DBIS custom map entry' SUP top STRUCTURAL MUST ( en $ customMapValue ) MAY ( description $ disableObject ) )

Attributs

customMapName

Le nom de la map custom est stockée dans l'attribut customMapName qui doit être assigné à une entrée dbisCustomConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.34 NAME 'customMapName' DESC 'Name of DBIS custom map' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

en

   Chaque clé de l'entrée de map custom est stockée dans l'attribu en qui doit être associé avec des entrées customMapEntry et devrait former le RDN.

customMapValue

Chaque valeur de l'entrée est stockée dans l'attribut customMapValue qui doit être assigné à un customMapEntry:
attributetype ( 1.3.6.1.4.1.23780.219.2.35 NAME 'customMapValue' DESC 'DBIS custom map value' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'objet.

disableObject

   Une entrée peut être désactivé en définissant disableObject à TRUE. Si une entrée est désactivé, le DUA devrait se comporter comme si l'entrée n'existe pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les objets désactivé, mais doivent les marquer clairement comme tels pour éviter toute confusion.

Exemple d'entrées de map custom

L'exemple suivant montre des entrées de map custom au format ldif:
dn: ou=console,ou=custom,o=infra
objectClass: top
objectClass: organizationalUnit
ou: console
    
dn: en=kirk,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: kirk
customMapValue: 2079 ssh
    
dn: en=spock,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: spock
customMapValue: 53179 telnet

Syntaxe d'attributs

Les syntaxes suivante sont utilisées par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID- - - - - - - - - - - Value - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.26 - IA5 String - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - -

Filtres de recherche communs

   Ce section fournis des exemples de filtre de recherche pour obtenir des entrées de base avec des critère communément utilisé. Pour simplifier les exemples, toutes les bases sont assumé avoir été définis avec une seule entrée de map de configuration. Cependant, draft-bannister-dbis-mapping permet plusieurs entrées et les implémentation doivent le supporter, augmentant le nombre de recherche nécessaire pour localiser toutes les entrées.

   Le DN de base utilisé dans les opérations de recherche dans cette section vient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter que l'entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur de l'attribut de même nom de l'entrée dbisMapConfig. Les noms de classe et attributs utilisés dans ces filtres de recherche peuvent être modifiés par les attributs dbisMapClass et dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration:
(&(objectClass=dbisCustomConfig)(!(disableObject=TRUE)))
Les maps custom sont énumérés avec le dbisMapFilter comme ceci:
(&(dbisMapFilter)(!(disableObject=TRUE)))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-devices-04

draft-bannister-dbis-devices-04

dbis: devices

   Ce document étends DBIS pour supporter les bases ethers et bootparams. Les schémas de base de données devraient être compatible avec NIS, mais stockés dans les entrées X.500 pour pouvoir être résolus avec LDAP.

   Une base ethers map les adresses Ethernet 48bits à des adresses IP ou des noms d'hôte, et bootparams map les hôte aux paramètres de boot du kernel.

   Ce document décris les classes et attributs LDAP requis pour étendre les entrée hosts pour supporter les paramètres pour les map ethers et bootparams.

Maps de configuration

   Les bases ethers et bootparams utilisent les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases ethers devraient avoir la classe dbisEtherConfig, et les entrées pour les bases bootparams devraient avoir la classe dbisBootConfig.

Il est recommandé que l'entrée dbisMapConfig pour une base ethers ou bootparams ait l'attribut dbisMapFilter définis en accord avec la tables suivante:
- - - - - - - - - - - - - - - - - - - - - - -
Database- - - dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - -
ethers- - - - objectClass=ieee802Device
bootparams- - objectClass=bootableDevice
- - - - - - - - - - - - - - - - - - - - - - -

Exemple d'entrée de map de configuration

L'exemple suivant montre une entrée de map de configuration pour une base ethers
dn: cn=ethers,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisEtherConfig
cn: ethers
dbisMapDN: ou=hosts,o=infra
dbisMapDN: ou=lab,ou=hosts,o=infra
dbisMapFilter: objectClass=ieee802Device
profileTTL: 900
description: Primary ethers database

L'exemple suivant montre en entrée de map de configuration pour une base bootparams
dn: cn=bootparams,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisBootConfig
cn: bootparams
dbisMapDN: ou=hosts,o=infra
dbisMapDN: ou=lab,ou=hosts,o=infra
dbisMapFilter: objectClass=bootableDevice
profileTTL: 900
description: Primary bootparams database

Base ethers

   Une base ethers contiens les champs suivants:

- Adresse ethernet 48-bits
- Un nom d'hôte

ObjectClass

   Une entrée dbisMapConfig pour une base ethers devrait avoir la class dbisEtherConfig. Une entrée host, définie par la classe ipv4HostObject ou ipv6HostObject, peut être augmentée par la classe ieee802Device pour ajouter des informations pour la map ethers.

dbisEtherConfig

La classe dbisEtherConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.37 NAME 'dbisEtherConfig' DESC 'DBIS ethers configuration map' SUP dbisMapConfig STRUCTURAL )

ieee802Device

La classe ieee802Device est définie comme suit:
objectclass ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a 48-bit Ethernet address' SUP top AUXILIARY MAY macAddress )

   C'est une class auxiliaire et il est recommandé qu'elle soit associé avec des entrées ipv4HostObject ou ipv6HostObject. Cependant, il est préférable de conserver les adresses Ethernet dans des entrées séparée qui peuvent être associés avec des classe device à la place.

Attributs

  

macAddress

L'adresse 48-bits est stockée dans l'attribut macAddress qui peut être associé avec une entrée ieee802Device
attributetype ( 1.3.6.1.1.1.1.22 NAME ('macAddress') DESC 'MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Exemple d'entrée ieee802Device

L'exemple suivant est un exemple d'une entrée ipv4HostObject au format ldif avec une class ieee802Device:
dn: rn=kilcher,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
objectClass: ieee802Device
rn: kilcher
ipv4Address: 10.11.12.13
macAddress: 08:00:27:00:50:f2

base bootparams

   Une base bootparams contient les champs suivants:

- Un nom d'hôte
- Des paramètres de boot

   Les paramètres de boot sont interprétés par le kernel et varie d'une plate-forme à l'autre. Ce schéma ne tente pas de définir des attributs unique pour chaque paramètre.

ObjectClass

   Une entrée dbisMapConfig pour une base bootparams devrait avec la class dbisBootConfig. Une entrée host, définie par la classe ipv4HostObject ou ipv6HostObject, peut être augmentée par la classe bootableDevice pour ajouter des informations pour la map de bootparams, qui fournis des informations de configuration pour rpc.bootparamd.

dbisBootConfig

La classe dbisBootConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.38 NAME 'dbisBootConfig' DESC 'DBIS bootparams configuration map' SUP dbisMapConfig STRUCTURAL )

bootableDevice

La classe bootableDevice est définie comme suit:
objectclass ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' DESC 'A device with boot parameters' SUP top AUXILIARY MAY ( bootFile $ bootParameter ) )

   C'est une classe auxiliaire et il est recommandé qu'elle soit associée avec des entrée ipv4HostObject ou ipv6HostObject. Cependant, il est préférable de conserver les adresses Ethernet dans des entrées séparée qui peuvent être associés avec des classe device à la place.

Attributs

bootFile

Nom de l'image de boot est stocké dans l'attribut bootFile qui peut être associé avec une entrée bootableDevice:
attributetype ( 1.3.6.1.1.1.1.24 NAME 'bootFile' DESC 'Boot image name' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

bootParameter

Les paramètres de boot sont stockés comme "clé=valeur" dans l'attribut bootParameter qui peut être associé avec une entrée bootableDevice:
attributetype ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' DESC 'rpc.bootparamd parameter' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Exemple d'entrée avec bootableDevice

L'exemple suivant montre une entrée ipv4HostObject au format ldif avec une classe bootableDevice:
dn: rn=kilcher,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
objectClass: ieee802Device
objectClass: bootableDevice
rn: kilcher
ipv4Address: 10.11.12.13
macAddress: 08:00:27:00:50:f2
bootParameter: root=alaska:/export/client/root
bootParameter: domain=country.music.edu

Syntaxe d'attribut

Les syntaxes suivante sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID- - - - - - - - - - -Value- - - - - - -Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.26 -IA5 String - - - -[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage de champs NIS

   Tous les champs qui sont requis pour générer des formats de base ether et bootparams NIS existent dans ce schéma et peut être mappés aux types d'attribut en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

ethers

Les champs de base ethers NIS sont mappés comme suit:
ether-addr = macAddress
hostname = rn / en ; depending on class, see below
    
ethers-entry = ether-addr SPACE hostname

   - hostname vient de l'attribut rn si la classe ipv4HostObject ou ipv6HostObject est utilisée. Si la classe ieee802Device est associée avec un objet avec la classe device, le nom d'hôte vient de l'attribut cn.

bootparams

Les champs de base bootparams NIS sont mappés comme suit:
hostname = rn / en ; depending on class, see below
params = bootParameter *(SPACE bootParameter)
    
bootparams-entry = hostname SPACE params

   - hostname vient de l'attribut rn si la classe ipv4HostObject ou ipv6HostObject est utilisée. Si la classe bootableDevice est associée avec un objet avec la classe device, le nom d'hôte vient de l'attribut cn.

Filtres de recherche communs

   Cette section fournis des exemples de filtre de recherche ldap pour obtenir des entrées de base avec des critères communément utilisés.

Si une entrée hosts a une adresse ethernet "ether", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(objectClass=ieee802Device)(macAddress=ether))
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-hosts-06

draft-bannister-dbis-hosts-06

dbis: hosts

   Ce document étends DBIS pour supporter les hôtes, réseaux, masques de sous-réseaux, protocoles, rpc et services. Les schémas de base devraient être compatible avec NIS, mais stockés dans des entrées X.500 pour qu'ils puissent être résolus avec LDAP. Une base hosts mappe des noms d'hôte à des adresses IP, les réseaux mappent des noms réseaux à des numéros de réseaux, les netmask mappent des numéros de réseaux à des masques réseaux, les protocoles mappent des noms de protocole réseaux à des numéros de protocole réseaux, rpc mappent les noms de programmes RPC à des numéros de programme RPC et les services mappent des noms de service réseaux à des numéros de ports et protocoles.

   Toutes les bases de données décrites dans ce document utilise les maps de configuration définis dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les base de données décrites dans ce document devraient avoir les objectClass décris ci-dessous. Il est recommandé que l'entrée dbisMapConfig pour une base hosts ait l'attribut dbisMapFilter définis en accord avec la tables suivante:


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Database___Configuration Class___dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
hosts______dbisHostConfig________objectClass=ipHostObject
networks___dbisNetworkConfig_____objectClass=ipNetworkObject
protocols__dbisProtocolConfig____objectClass=ipProtocolObject
rpc________dbisRpcConfig_________objectClass=rpcObject
services___dbisServiceConfig_____objectClass=ipServiceObject

Exemple d'entrées de map de configuration

L'exemple suivante montre une entrée de map de configuraion pour une base hosts:
dn: cn=hosts,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisHostConfig
cn: hosts
dbisMapDN: cn=hosts,ou=dbis,o=infra
dbisMapFilter: objectClass=ipHostObject
profileTTL: 900
description: Primary hosts database

Base hosts

   Une base host contient les champs suivants:

- Une adresse IPv4 ou IPv6
- Un nom d'hôte canonique
- Des alias

ObjectClass

   Une entrée dbisMapConfig pour une base hosts devrait avoir l'objectClass dbisHostConfig. Une entrée host devrait être définis par une entrée LDAP avec l'objectClass ipv4HostObject ou ipv6HostObject.

dbisHostConfig

La classe dbisHostConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.15 NAME 'dbisHostConfig' DESC 'DBIS hosts configuration map' SUP dbisMapConfig STRUCTURAL )

ipHostObject

La classe ipHostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.16 NAME 'ipHostObject' DESC 'An IP address and associated host name' SUP top ABSTRACT MUST rn MAY ( authPassword $ userPassword $ description $ manager $ l $ disableObject ) )

ipv4HostObject

La classe ipv4HostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.17 NAME 'ipv4HostObject' DESC 'An IPv4 address' SUP ipHostObject STRUCTURAL MUST ipv4Address )

ipv6HostObject

La classe ipv6HostObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.18 NAME 'ipv6HostObject' DESC 'An IPv6 address' SUP ipHostObject STRUCTURAL MUST ipv6Address )

attributs

rn

   Le nom canonique pleinement qualifié de l'hôte est stocké dans l'attribut rn qui est définis dans draft-bannister-dbis-mapping. L'attribut rn doit être associé avec une entrée ipHostObject et devrait former le RDN. Si requis, des entrées alias peuvent être définis.

authPassword

   Un mot de passe chiffré peut être stocké dans l'attribut authPassword assigné à une entrée ipHostObject.

userPassword

   Pour des raisons de compatibilité, un mot de passe chiffré peut être stocké dans l'attriut userPassword

ipv4Address

L'adresse IPv4 est stocké dans l'attribut ipv4Address qui doit être associé avec une entrée ipv4HostObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.27 NAME 'ipv4Address' DESC 'An IPv4 address in dotted decimal format' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{15} )

ipv6Address

L'adresse ipv6 est stockée dans l'attribut ipv6Address qui doit être associé avec une entrée ipv6HostObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.28 NAME 'ipv6Address' DESC 'An IPv6 address [RFC2373]' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{45} )

Exemple d'entrée host

L'exemple suivant est une entrée ipv4HostObject au format LDIF:
dn: rn=picard,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
rn: picard
ipv4Address: 10.11.12.13

L'exemple suivant est une entrée ipv6HostObject:
dn: rn=picard-hive,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv6HostObject
rn: picard-hive
ipv6Address: 0:1:2:3:4:5:6:7

L'exemple suivant est une entrée alias d'hôte:
dn: rn=picard-eth0,ou=hosts,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
rn: picard-eth0
aliasedObjectName: rn=picard,ou=hosts,o=infras

Base networks

   Une base networks contient les champs suivants:

- Le nom d'un réseaux
- Le numéro de réseau IP
- Des alias

objectClass

   une entrée dbisMapConfig pour une base réseaux devait être assigné à l'objectClass dbisNetworkConfig. Une entrée network devrait être définie dans une entrée LDAP avec l'objectClass ipNetworkObject.

dbisNetworkConfig

La classe dbisNetworkConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.19 NAME 'dbisNetworkConfig' DESC 'DBIS networks configuration map' SUP dbisMapConfig STRUCTURAL )

ipNetworkObject

La classe ipNetworkObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.20 NAME 'ipNetworkObject' DESC 'An IP network entry' SUP top STRUCTURAL MUST ipNetworkNumber MAY ( en $ ipNetmaskNumber $ description $ manager $ l $ disableObject ) )

en

   Le nom du réseau est stocké dans l'attribut en. Cet attribut peut être associé avec une entrée ipNetworkObject, et si fournis, devrait former le RDN. Si besoin des entrées alias peuvent être définies.

ipNetworkNumber

L'adresse IP réseau est stocké dans l'attribut ipNetworkNumber qui doit être associé avec une entrée ipNetworkObject:
attributetype ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   Si l'attribut en n'est pas fournis, ipNetworkNumber devrait former le RDN.

ipNetmaskNumber

Le masque de réseau est stocké dans l'attribut ipNetmaskNumber qui peut être associé avec une entrée ipNetworkObject
attributetype ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Exemple d'entrée network

L'exemple suivant montre une entrée ipNetworkObject au format LDIF:
dn: en=lab,ou=networks,o=infra
objectClass: top
objectClass: ipNetworkObject
en: lab
ipNetworkNumber: 10.23.10
ipNetmaskNumber: 255.255.255.0

L'exemple suivant montre une entrée alias:
dn: en=testnet,ou=networks,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: testnet
aliasedObjectName: en=lab,ou=networks,o=infra

Base protocols

   Une base protocols contient les champs suivants:

- Le nom du protocole
- Le numéro du protocole
- Des alias

ObjectClass

   Une entrée dbisMapConfig pour une base protocols devrait avoir l'objectClass dbisProtocolConfig. Une entrée protocol devrait être définis dans une entrée avec la classe ipProtocolObject.

dbisProtocolConfig

La classe dbisProtocolConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.21 NAME 'dbisProtocolConfig' DESC 'DBIS protocols configuration map' SUP dbisMapConfig STRUCTURAL )

ipProtocolObject

La classe ipProtocolObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.22 NAME 'ipProtocolObject' DESC 'An IP protocol entry' SUP top STRUCTURAL MUST ( en $ ipProtocolNumber ) MAY ( description $ manager $ disableObject ) )

Attribut

en

   Le nom du protocole est stocké dans l'attribut en qui doit être associé avec une entrée ipProtocolObject et devrait former le RDN. Si besoin, des alias peuvent être définis.

ipProtocolNumber

Le numéro de protocole est stocké dans l'attribut ipProtocolNumber qui doit être assigné à une entrée ipProtocolObject:
attributetype ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' DESC 'IP protocol number' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Exemples d'entrée protocol

L'exemple suivant montre une entrée ipProtocolObject au format LDIF:
dn: en=ip,ou=protocols,o=infra
objectClass: top
objectClass: ipProtocolObject
en: ip
ipProtocolNumber: 0

L'exemple suivant montre une entrée alias:
dn: en=IP,ou=protocols,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: IP
aliasedObjectName: en=ip,ou=protocols,o=infra

base rpc

   Une base RPC contient les champs suivants:

- Le nom du programme RPC
- Le numéro du programme RPC
- Les alias

ObjectClass

   Une entrée dbisMapConfig pour une base rpc devrait avoir la clé dbisRpcConfig. Une entrée rpc devrait être définie dans une entrée avec la classe rpcObject.

dbisRpcConfig

La classe dbisRpcConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.23 NAME 'dbisRpcConfig' DESC 'DBIS rpc configuration map' SUP dbisMapConfig STRUCTURAL )

rpcObject

La classe rpcObject est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.24 NAME 'rpcObject' DESC 'An rpc entry [RFC1057]' SUP top STRUCTURAL MUST ( en $ rpcNumber ) MAY ( description $ manager $ disableObject ) )

en

   Le nom du programme rpc est stocké dans l'attribut en qui doit être associé avec une entrée rpcObject et devrait former le RDN. Si besoin, des entrées alias peuvent être définies.

rpcNumber

Le numéro de programme RPC est stocké dans l'attribut rpcNumber qui doit être associé avec une entrée rpcObject
attributetype ( 1.3.6.1.4.1.23780.219.2.29 NAME 'rpcNumber' DESC 'RPC program number [RFC1057]' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Exemple d'entrée RPC

L'exemple suivant montre une entrée rpcObject au format ldif:
dn: en=rpcbind,ou=rpc,o=infra
objectClass: top
objectClass: rpcObject
en: rpcbind
rpcNumber: 100000

L'exemple suivant montre une entrée alias:
dn: en=portmap,ou=protocols,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: portmap
aliasedObjectName: en=rpcbind,ou=rpc,o=infra

base services

   Une base services contient les champs suivants:

- Nom du service
- Numéro de port et nom du protocole
- alias

   Le RDN peut être constitué de l'attribut en, cependant, où une entrée ne peut pas être identifiée de manière unique dûe à la présente d'autres services qui utilisent le même nom de service et numéro de port mais avec un nom de protocole différent, un RDN multi-valué devrait être utilisé à la place.

ObjectClass

   Une entrée dbisMapConfig pour une base service devait avoir l'objectClass dbisServiceConfig. Une entrée service devrait être définie par une entrée avec la classe ipServiceObject.

dbisServiceConfig

La classe dbisServiceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.25 NAME 'dbisServiceConfig' DESC 'DBIS services configuration map' SUP dbisMapConfig STRUCTURAL )

ipServiceObject

La classe ipServiceObject est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.26 NAME 'ipServiceObject' DESC 'An IP service entry' SUP top STRUCTURAL MUST ( en $ ipServicePort $ ipProtocolName ) MAY ( description $ manager $ disableObject ) )

en

   Le nom du service est stocké dans l'attribut en qui doit être associé avec une entrée ipServiceObject et devrait former le RDN.

ipServicePort

Le numéro de port IP du service est stocké dans l'attribut ipServiceport qui doit être associé avec une entrée ipServiceObject:
attributetype ( 1.3.6.1.1.1.1.15 NAME ( 'ipServicePort' ) DESC 'IP port number' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

ipProtocolName

Le nom du protocole du service est stocké dans l'attribut ipProtocolName qui doit être associé avec une entrée ipServiceObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.30 NAME 'ipProtocolName' DESC 'IP protocol name' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

Exemples d'entrée service

L'exemple suivant montre une entrée ipServiceObject au format LDIF:
dn: en=smtp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: smtp
ipServicePort: 25
ipProtocolName: tcp

L'exemple suivant est un exemple d'une entrée alias de service:
dn: en=mail,ou=services,o=infra
objectClass: top
objectClass: alias
objectClass: extensibleObject
en: mail
aliasedObjectName: en=smtp,ou=services,o=infra

L'exemple suivant montre des entrées services multi-valués:
dn: en=rpcbind+ipProtocolName=udp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: udp
    
dn: en=rpcbind+ipProtocolName=tcp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: tcp

Attributs communs

   Ce document utilise les attributs communs suivant.

description

   L'attribut description peut être associé avec une entrée pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée pour fournir un ou plusieurs dn des individus, groupes ou systèmes qui sont responsable pour maintenir l'entrée.

l

   L'attribut l peut être associé avec une entrée pour fournir des détails de localisation.

disableObject

   Une entrée peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme pour lister les entrées désactivées, mais ils doivent être clairement marqués comme désactivés pour qu'aucune confusion ne se produise.

Syntaxe d'attributs

Les syntaxes suivante sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Syntax OID - - - - - - - - - - Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- 1.3.6.1.4.1.1466.115.121.1.15 -Directory String -[RFC4517]
- 1.3.6.1.4.1.1466.115.121.1.26 -IA5 String - - - -[RFC4517]
- 1.3.6.1.4.1.1466.115.121.1.27 -Integer - - - - - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Mappage des champs NIS

   Tous les champs qui sont requis pour générer des bases correspondante dans NIS existent dans ce schéma et peuvent être mappé aux types d'attributs en utilisant les productions ABNF décrites dans draft-bannister-dbis-netgroup.

hosts

Les champs de base hosts sont mappés comme suit:
ipaddr = ipv4Address / ipv6Address
hostname = rn
alias = rn ; dérivé, voir plus bas
    
hosts-entry = ipaddr SPACE hostname *(SPACE alias)

   Alias est dérivé de l'attribut rn utilisé avec les entrées qui référencent celle-ci via aliasedObjectName.

networks

Les champs de base networks sont mappés comme suit:
network-name = en
network-number = ipNetworkNumber
alias = en ; dérivé, voir plus bas
    
networks-entry = network-name SPACE network-number *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName.

netmasks

Les champs de base netmasks sont mappés comme suit:
network-number = ipNetworkNumber
netmask = ipNetmaskNumber
    
netmasks-entry = network-number SPACE netmask

protocols

Les champs de base protocols sont mappés comme suit:
proto-name = en
proto-number = ipProtocolNumber
alias = en ; dérivé, voir plus bas
    
protocols-entry = proto-name SPACE proto-number *(SPACE alias)

rpc

Les champs de base rpc sont mappés comme suit:
rpc-name = en
rpc-number = rpcNumber
alias = en ; dérivé, voir plus bas
    
rpc-entry = rpc-name SPACE rpc-number *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName

services

Les champs de base services sont mappés comme suit:
service-name = en
service-port = ipServicePort
service-protocol = ipProtocolName
alias = en ; dérivé, voir plus bas
    
services-entry = service-name SPACE service-port SLASH service-protocol *(SPACE alias)

   Alias est dérivé de l'attribut en utilisé avec les entrées qui référencent celle-ci via aliasedObjectName .

Filtres de recherches communs

   Cette section fournis des exemples de filtre de recherche LDAP pour obtenir les entrées de base avec des critères d'entrée communément utilisés.

   Pour simplifier les exemples, toutes les bases sont supposés avoir été définis avec seulement une entrée de map de configuration. Le DN de base utilisé dans les opérations de recherche décris dans cette section vient le l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche, le texte "dbisMapFilter" réfère à la valeur assignée dans l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Les noms d'attributs utilisé dans les filtres de recherche peuvent être modifiés par l'attribut dbisMapAttr assigné à l'entrée dbisMapConfig.

Trouver la map de configuration pour un domaine

   Pour localiser la map de configuration pour un domaine dbis donné, rechercher les entrées sous l'entrée dbisDomainObject:

Les maps d'hôte peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisHostConfig)(!(disableObject=TRUE)))
Les maps réseaux peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisNetworkConfig)(!(disableObject=TRUE)))
Les maps protocols peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisProtocolConfig)(!(disableObject=TRUE)))
Les maps rpc peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisRpcConfig)(!(disableObject=TRUE)))
Les maps services peuvent être trouvés avec le filtre de recherche suivant:
(&(objectClass=dbisServiceConfig)(!(disableObject=TRUE)))

Lister toutes les entrées

Les entrées pour une base donnée sont énumérées en appliquant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE)))

Trouver des entrées spécifiques

Une entrée hôte nommé "name", sa définition est localisé en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(rn=name))
Une entrée networks, protocols, rpc ou services nommé "name", sa définition est localisée en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))

Trouver un hôte par adresse

Une entrée d'hôte ayant une IPv4, sa définition est localisée en utilisant:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipv4Address=ipv4))
Avec une IPv6:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipv6Address=ipv6))

Trouver un réseau par adresse

Pour localiser une entrée réseau par son adresse, utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipNetworkNumber=netip))

Trouver par numéro

La définition du protocole de numéro "protonum" est localisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipProtocolNumber=protonum))
Pour localiser une entrée rpc pas son numéro de programme "rpcnum", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(rpcNumber=rpcnum))

Autres exemples

Pour trouver l'entrée service nommé "servname" et le protocole "servproto", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=servname)(ipProtocolName=servproto))
Pour trouver l'entrée de service pour le port "servport" et les protocole "servproto", utiliser:
(&(dbisMapFilter)(!(disableObject=TRUE))(ipServicePort=servport)(ipProtocolName=servproto))
^
15 juin 2015

htmlpdflatexmanmd




draft-bannister-dbis-mapping-06

draft-bannister-dbis-mapping-06

Directory-Based Information Services

   Ce document fait partie de la série de documents qui décrivent les composants dans DBIS (Directory-Based Information Services). DBIS fournis un framework pour la représentation des données lié à TCP/IP et le système UNIX dans des entrées X.500 qui ont été précédemment stockés dans NIS; pour qu'ils puissent être résolus avec le protocole LDAP.

   Le but de DBIS est d'étendre, et remplacer le protocole NIS et expérimental pour utiliser LDAP comme service d'information réseaux,.

   DBIS consiste d'un schéma LDAP, de conventions de nommage et de protocoles pour décrire son utilisation par les DUA nécessitant des informations de service réseaux. La communication client/serveur et les opérations côté serveur sont entièrement contenus dans le domaine de LDAP.

   Les aspects clé de DBIS et des amélioration par rapport à RFC2307 sont:

- le schéma est compatible avec NIS, incluant la sensibilité à la casse des noms clé.
- Standardisation des information de mappage pour augmenter la portabilité des implémentation DUA et pour réduire la duplication des informations de configuration du client.
- Fonctionnalités ajoutées pour augmenter la flexibilité dans de grands environnements:

        - les maps peuvent être jointes depuis les données localisée dans différents endroits du DIT.
        - Les groupes de DUA peuvent avoir de variations dans leur données en fonction de leur appartenance aux netgroup d'hôte.

- Conception modulaire pour permettre de séparer les parties du système à remplacer, améliorer et augmenter séparément dans le future.
- Support ajouté pour les maps d'automontage

   Ce document décris le mappage d'objets utilisés par DBIS pour localiser et transformer les informations de service stockés dans le DIT.

Databases

   Le rôle de DBIS est de fournir un framework qui fournis des informations de configuration, principalement des services de nom tel que les comptes, groupes et hôtes/réseaux, et toutes les informations traditionnellement fournies par NIS. Chaque type d'information est appelée une base de donnée, vu que c'est une collection d'entrées liées dans le DIT. Le format des entrées est spécifique à chaque type de base et n'est pas définis dans ce document. Chaque base est configurée séparément en utilisant des maps de configuration qui décrivent où localiser les entrées concernées dans le DIT. Le format des map de configuration est définie dans ce document, bien qu'il peut être étendus par d'autres documents.

Alias

   Quand une base supporte les entrées alias, ils doivent être configuré comme décris dans la rfc4512. Un DUA devrait effectuer le déréférencement d'alias dans ces bases.

Domaine: définition

   Le mappage d'objets définis les composants qui font un domaine DBIS. Un domain DBIS, est un groupement logique de services d'informations requis par une collection commune de DUA, de la même manière qui domaine NIS contient toutes les maps NIS requises pour les opérations d'un groupe de machines. Un domaine DBIS devrait être identifiié par une entrée LDAP avec l'objectClass dbisDomainObject. Les maps de configuration pour le domaine sont contenus dans les entrées qui devraient être localisés sous l'entrée dbisDomainObjet dans le DIT.

dbisDomainObject

Cette classe est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.1 NAME 'dbisDomainObject' DESC 'Defines a top-level mapping object for a DBIS domain' SUP top STRUCTURAL MUST en MAY ( profileTTL $ negativeTTL $ description $ manager ) )

Attributs de domaine

en Le nom du domain, identique au format dans un domaine NIS, qui doit être associé avec une entrée dbisDomainObject et devrait former le RDN.
profileTTL Valeur TTL par défaut pour la pertinence des données de configuration (définis dans la rfc4876) qui peut être associé avec une entrée dbisDomainObject. Les DUA devraient conserver une copie locale des données obtenues. Si profileTTL vaut 0, les DUA peuvent conserver les copies locales indéfiniment. Si profileTTL n'est pas présent, les DUA devraient se comporter comme s'il était définis à 0.
negativeTTL Identique à profileTTL, excepté pour les entrées qui n'existent pas. Les DUA devraient conserver une copie local des recherches qui n'existent pas mais ne doivent pas utiliser cette donnée après le nombre de secondes spécifiée.


attributetype ( 1.3.6.1.4.1.23780.219.2.36 NAME 'negativeTTL' DESC 'Time to live, in seconds, for missing entries' EQUALITY integerMatch ORDERING integerOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

description L'attribut description peut être associé avec une entrée dbisDomainObject pour fournir une description arbitraire de l'entrée.
manager L'attribut manager peut être associé avec une entrée dbisDomainObject pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsable de la maintenance de l'entrée.

Alias de domaine

   Si les alias noms de domaine sont requis ils doivent être configurés comme décris dans la rfc4512. Un DUA doit déréférencer les alias.

Exemple d'entrée de domaine

L'exemple suivant est une entrée dbisDomainObject:
dn: en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisDomainObject
en: sales.corp
profileTTL: 900
negativeTTL: 300
description: Sales Workforce

Maps de configuration

   Une map de configuration DBIS instruit un DUA sur l'emplacement des entrées dans le DIT pour une base particulière. Elle décris comment trouver les entrées et optionnellement quel sous-jeu de DUA devraient utiliser ces entrées (basé sur l'appartenance de netgroup). Ce document ne définis aucune map de configuration spécifique, mais un framework qui doit être suivi pour la spécification de tels maps. Les maps de configuration devraient être évaluées par un DUA dans l'ordre lexicographique de leur attribut cn. L'ordre d'évaluation de ces entrées de configuration déterminent également l'ordre dans lequel les entrées de base apparaissent si plusieurs emplacements sont trouvés. L'ordre est également important pour s'assurer que les netgroups corrects sont disponibles pou tester si la configuration est restreinte par l'appartenance à un netgroup en utilisant soit l'attribut exactNetgroup ou notNetgroup.

dbisMapConfig

Une map pour une base est optionnelle et devrait être identifiée par une ou plusieurs entrées LDAP localisées sous l'entrée dbisDomainObject dans le DIT. Le comportement du DUA si une entrée depuis une base est demandée et n'a pas de map de configuration correspondant est indéfinie. Les entrées de map de configuration assignées, ou une sous-classe:
objectclass ( 1.3.6.1.4.1.23780.219.1.2 NAME 'dbisMapConfig' DESC 'DBIS configuration map for a specific database' SUP top STRUCTURAL MUST ( cn $ dbisMapDN ) MAY ( dbisMapFilter $ dbisMapClass $ dbisMapAttr $ dbisTransAttr $ exactNetgroup $ notNetgroup $ profileTTL $ negativeTTL $ description $ manager $ disableObject ) )

   Un DUA devrait supporter plusieurs entrées de map de configuration pour une simple base. Une base devrait nécessiter au moins un objectClass additionnel assigné à sa configuration, qui est utilisé pour identifier de manière unique le type de base pour lequel les entrées appartiennent.

cn

   L'attribut cn doit être utilisé pour former le RDN d'une entrée dbisMapConfig. C'est un nom arbitraire qui n'a pas de signification spéciale dans DBIS, mais qui identifie de manière unique l'entrée dbisMapConfig. Comme vu plus haut, les entrées sont évaluées dans l'ordre lexicographique de leur attribut cn.

dbisMapDN

Un ou plusieurs DNs localisant la base de recherche des entrées de la base dans le DIT sont donnés dans l'attribut dbisMapDN qui doit être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.1 NAME 'dbisMapDN' DESC 'DN of search base for DBIS database entries' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

dbisMapFilter

Un filtre de recherche LDAP utilisé pour localiser les entrées de la base sous lequel chaque dbisMapDN est donné dans l'attribut dbisMapFilter qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.2 NAME 'dbisMapFilter' DESC 'LDAP search filter for DBIS database entries' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dbisMapClass

Les objectClass utilisés pour identifier les entrées pour une base peut être changé du défaut par l'attribut dbisMapClass qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.3 NAME 'dbisMapClass' DESC 'LDAP class mapping for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut dbisMapClass est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions utilisées qui ne sont pas définies ici sont définies dans la rfc4512.
from_class = keystring
to_class = keystring
dbisMapAttr = to_class EQUALS from_class

   Si l'attribut dbisMapClass est manquant de l'entrée dbisMapConfig, le DUA devrait continuer avec les classes par défaut pour la base. Changer cet attribut n'a pas d'effet sur le dbisMapFilter, qui doit être ajusté indépendamment.

dbisMapAttr

Les attributs utilisé pour stocker les clés et valeurs de l'entrée de la base peuvent être changés par l'attribut dbisMapAttr qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.4 NAME 'dbisMapAttr' DESC 'LDAP attribute mapping for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut dbisMapAttr est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions utilisées qui ne sont pas définies ici sont définies dans la rfc4512.
from_attr = keystring
to_attr = keystring
dbisMapAttr = to_attr EQUALS from_attr

   L'attribut utilisé dans la base est identifiée par from_attr et devrait être ré-écrit par le DUA à l'attribut to_attr. Si l'attribut dbisMapAttr est manquant de l'entrée dbisMapConfig, le DUA devrait continuer avec les attributs par défaut pour la base. Changer cet attribut n'a pas d'effet sur le dbisMapFilter ni dbisTransAttr, qui doivent être ajustés indépendamment.

dbisTransAttr

Les valeurs d'attribut utilisés par les entrées de base peuvent être transformés par l'attribut dbisTransAttr qui peut être assigné à une entrée dbisMapConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.4.1 NAME 'dbisTransAttr' DESC 'LDAP attribute transformation for DBIS database entries' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de dbisTransAttr est définie par la grammaire suivante, qui utilise la notation ABNF. Les productions qui ne sont pas définies ici sont définies dans draft-bannister-dbis-netgroup-XX:
attrname = keystring
prefix = keystring
suffix = SLASH keystring
incr = PLUS number
decr = HYPHEN number
trans = prefix / suffix / incr / decr
dbisTransAttr = attrname EQUALS trans

   La valeur de l'attribut attrname apparaissant dans les entrées de base devraient être ré-écris par le DUA tel sorte qu'il porte le nouveau préfix et/ou suffix. Alternativement, si la valeur de l'attribut est numérique, il doit être incrémenté ou décrémenté en ajoutant ou supprimant le nombre donné. Si l'attribut dbisTransAttr est manquant, le DUA devrait continuer avec les valeurs non-éditées pour la base.

exactNetgroup

   Un ou plusieurs noms netgroup identifiant les noms d'hôte des DUA qui devraient appliquer la map de configuration donnée dans l'attribut exactNetgroup qui peut être assigné à une entrée dbisMapConfig. Si l'attribut exactNetgroup est manquant, le DUA devrait appliquer cette entrée de map de configuration. Si l'attribut existe, le DUA devrait appliquer l'entrée seulement si l'hôte sur lequel il tourne est membre du netgroup donné. Si une entrée matchant est trouvée, le DUA devrait utiliser cette configuration, sinon le DUA doit ignorer cette entrée. La seule exception à ces règles est si le DUA est membre d'un netgroup identifié par l'attribut notNetgroup, qui a précédence.

noNetgroup

   Un ou plusieurs noms netgroup identifiant les noms d'hôte des DUA qui ne devraient pas appliquer la map de configuraion sont donnés dans l'attribut notNetgroup qui peut être assigné à une entrée dbisMapConfig. Cela permet aux entrées de map de configuration d'être exclus d'un groupe d'hôtes particuliers. Le DUA devrait exclure cette entrée de map de configuration si le DUA est membre du netgroup donné, même s'il est également membre d'une attribut exactNetgroup.

profileTTL

   Une valeur TTL peut être assignée à une entrée dbisMapConfig dans l'attribut profileTTL définis dans la rfc4876. Les DUA devraient considérer cet attribut comme ayant précédence au profileTTL fournis dans l'entrée dbisMapConfig, avec le scope limité à cette entrée et toutes entrées qu'elle référence. Si profileTTL est à 0, le DUA peut conserver les copies indéfiniment ou jusqu'à ce que d'autre périodes localement définies soient passées. Si profileTTL est omis de dbisMapConfig, le profileTTL par défaut fournis dans le dbisDomainObject devrait prévaloir.

negativeTTL

   Identique à profileTTL, excepté qu'il est utilisé pour les entrées qui n'existent pas.

description

   L'attribut description peut être associé avec une entrée dbisMapConfig pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée dbisMapConfig pour fournir un ou plusieurs DN des individus, groupes ou systèmes qui sont responsable pour maintenir l'entrée.

disableObject

L'attribut disableObject peut être associé avec une entrée dbisMapConfig pour désactiver ce composant de configuration, et est définis comme suit:
attributetype ( 1.3.6.1.4.1.23780.219.2.5 NAME 'disableObject' DESC 'TRUE if the entry is disabled' EQUALITY booleanMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

   Un DUA devrait ignorer les entrées qui ont l'attribut disableObject mis à TRUE.

Attributs communs

   Les attribut additionnels qui sont soit utilisés dans ce document ou requis par d'autres documents en utilisant le shéma de mappage DBIS sont définis ou référencé ci-dessous.

en (exactName)

L'attribut en peut être utilisé à la place de cn où la sensibilité à la casse est requise, et est définie comme suit:
attributetype ( 1.3.6.1.4.1.23780.219.2.6 NAME ( 'en' 'exactName' ) DESC 'Exact name by which the entity is known' EQUALITY caseExactMatch SINGLE-VALUE SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   L'attribut en est identique à l'attribut cn à l'exception qu'il est sensible à la casse et est SINGLE-VALUE.

rn (regularName)

L'attribut rn peut être utilisé à la place du cn où la casse n'est pas importante mais une seule valeur est permise:
attributetype ( 1.3.6.1.4.1.23780.219.2.7 NAME ( 'rn' 'regularName' ) DESC 'Regular name by which the entity is known' EQUALITY caseIgnoreMatch SINGLE-VALUE SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   L'attribut rn est identique à l'attribut cn à l'exception qu'il est SINGLE-VALUE.

Syntaxe d'attribut

Les syntaxes suivantes sont utilisée par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax_OID_____________________Value_____________Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.7___Boolean___________[RFC4517]
1.3.6.1.4.1.1466.115.121.1.12__DN________________[RFC4517]
1.3.6.1.4.1.1466.115.121.1.15__Directory_String__[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26__IA5_String________[RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Caches

   Il est commun pour les systèmes d'exploitation d'implémenter leur propres algorithmes de cache de service de noms, par exemple nscd, qui a sont propre TTL. Tou DUA implémentant DBIS devrait honorer le profileTTL et negativeTTL au niveau du domanie et des entrées de map de configuration qui doivent avoir précédence sur les paramètres locaux. Cela peut résulter en différents TTL pas seulement pour les base individuelles mais potentiellement pour les sous-jeux des entrées dans une simple base.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-netgroup-04

draft-bannister-dbis-netgroup-04

dbis: netgroup

   Ce document étend DBIS pour supporter les bases de données se service réseaux et groupes réseaux. Un schéma de base de netgroup devrait être compatible avec NIS mais stocké dans des entrées X.500 pour qu'ils puissent être résolus via lDA. Une base de netgroup représente des groupes d'hôtes, d'utilisateurs et de domaines.

Domaine

   Le terme "domaine" utilisé dans ce document ne réfère pas aux domaines DBIS mais aux domaines DNS.

scope

   Toutes les bases décrites dans ce document utilise les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases netgroup et netservice devraient être assignés aux objectClass dbisNetGroupConfig et dbisNetserviceConfig, respectivement.

Il est recommandé que l'entrée dbisMapConfig pour un netgroup ou une base netservice ait l'attribut dbisMapFilter mis en accord avec la table suivante:
- - - - - - - - - - - - - - - - - - - - - - - - - -
Database                        dbisMapFilter
- - - - - - - - - - - - - - - - - - - - - - - - - -
netgroup                        objectClass=netgroupObject
netservice                objectClass=netserviceDescriptor
- - - - - - - - - - - - - - - - - - - - - - - - - -

Exemple

Exemple de configuration d'une entrée de map de configuration pour une base netgroup:
dn: cn=netgroup,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisNetgroupConfig
cn: netgroup
dbisMapDN: cn=netgroup,ou=dbis,o=infra
dbisMapFilter: objectClass=netgroupObject
profileTTL: 900
description: Primary netgroup database

Exemple de configuration d'une entrée de map de configuration pour une base netservice:
dn: cn=netservice,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisNetserviceConfig
cn: netservice
dbisMapDN: cn=netservice,ou=dbis,o=infra
dbisMapFilter: objectClass=netserviceDescriptor
profileTTL: 900
description: Primary netservice database

netgroup - définition

   Une base netgroup contient les entrées qui représente les hôtes, les utilisateurs et les domaines et qui sont associés avec une nom netgroup sensible à la casse. les netgroups DBIS permettent aux groupes d'utilisateurs et aux hôtes d'être définis avec les variances de scope suivant:

- Tous les utilisateurs dans tous les hôtes d'un domaine donné
- Tous les utilisateurs dans des hôtes spécifiques
- Les utilisateurs nommés sans regarder l'hôte
- Les utilisateurs nommés dans tous les hôtes dans un domaine donné
- Les utilisateurs nommés dans des hôtes spécifiques.

objecClass

   Une entrée dbisMapConfig pour une base netgroup devrait avoir l'objectClass dbisNetgroupConfig. Un netgroup devrait être définis par une entrée LDAP avec l'objectClass netgroupObject.

dbisNetgroupConfig

dbisNetgroupConfig est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.3 NAME 'dbisNetgroupConfig' DESC 'DBIS netgroup configuration map' SUP dbisMapConfig STRUCTURAL )

netgroupObject

netgroupObject est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.4 NAME 'netgroupObject' DESC 'DBIS netgroup entry' SUP top STRUCTURAL MUST en MAY ( netgroupHost $ netgroupUser $ netgroupTriple $ exactNetgroup $ description $ manager $ disableObject ) )

en

   Le nom du netgroup est stocké dans l'attribut en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec l'entrée netgroupObject et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

netgroupHost

Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Le représentation chaîne de l'attribut netgroupHost devrait matcher la grammaire suivante, qui utilise les productions ABNF:
host = keyname-low
domain = keyname-low *(DOT keyname-low)
host-domain = host DOT domain
all-domain = ASTERISK DOT domain
    
netgroupHost = host / host-domain / all-domain

   Un DUA devrait dé-référencer les alias et convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupHost ou un filtre.

netgroupUser

Un utilisateur qui est un membre d'un netgroup est stocké dans l'attribut netgroupUser qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.9 NAME 'netgroupUser' DESC 'User who is assigned to a netgroup' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain

   Un DUA devrait convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupUser ou un filtre.

netgroupTriple

Pour compatibilité avec la rfc2307, DBIS permet aux membre des netgroup d'être exprimés sous la forme de triplets netgroup en fournissant un ou plusieurs attributs netgroupTriple qui peuvent être assignés à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.37 NAME 'netgroupTriple' DESC 'Case exact netgroup triple' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Un DUA devrait convertir les composants de nom d'hôte et de domaine en caractères minuscule avant de former un attribut netgroupTriple ou un filtre.

exactNetgroup

Les membres d'autres netgroups peuvent être hérités par ce netgroup en fournissant des noms de netgroup additionnels dans un ou plusieurs attributs exactNetgroup qui peut être assigné avec une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.10 NAME 'exactNetgroup' DESC 'Case exact netgroup name associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   Les DUA devraient valider qu'un netgroup référencé par cet attribut existe et est actif. Si le netgroup n'est pas définis, ou s'il a été désactivé avec l'attribut disableObject, il ne devrait pas être inclus dans la réponse au client.

description

   L'attribut description peut être associé avec une entrée netgroupObject pour fournir une description arbitraire de l'entrée

manager

   L'attribut manager peut être associé avec une entrée netgroupObject pour fournir un ou plusieurs DN d'individus, de groupes ou systèmes qui sont responsable de la maintenance de cette entrée.

disableObject

   Une entrée netgroup peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA se comporte comme si le netgroup n'existe pas. Le DUA peut optionnellement fournir un mécanisme séparé pour les entrées désactivées, mais elles doivent être clairement marquées comme désactivées pour qu'aucune confusion ne se produise.

Exemple d'entrée netgroup


dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

Déterminer les hôtes membres

   Un DUA devrait effectuer une recherche DNS inversée de l'adresse IP primaire de l'hôte pour déterminer le nom fqdn à utiliser pour le netgroup correspondant. Un hôte doit rencontrer un des conditions suivantes pour être considéré un memre d'un netgroup:

a) Un nom d'hôte non qualifié convertis en minuscule correspond exactement à l'attribut netgroupHost. Dans ce scénario l'attribut netgroupHost est également non qualifié.
b) Le nom d'hôte pleinement qualifié convertis en minuscule correspond exactement à l'attribut netgroupHost.
c) L'attribut netgroupHost utilise le motif all-domain, et le nom de domaine pleinement qualifié convertis en minuscule correspond à cet attribut quand le préfix est supprimé.

Déterminer les utilisateurs membres

   Un utilisateur doit rencontrer un des conditions suivantes pour être considéré un membre d'un netgroup:

a) L'attribut netgroupUser ne contient pas le ATSIGN et le nom d'utilisateur correspond exactement à l'attribut netgroupUser
b) Le nom d'utilisateur matche exactement le composant user de l'attribut netgroupUser, et le nom d'hôte non qualifié du DUA qui est obtenu comme décris précédemment et convertis en minuscule correspond exactement au composant hôte de l'attribut netgroupUser
c) Le nom d'utilisateur correspond exactement au composant utilisateur de l'attribut netgroupUser, et le nom d'hôte pleinement qualifié du DUA correspond exactement au composant domain d'hôte de l'attribut netgroupUser.
d) Le nom d'utilisateur correspond exactement au composant utilisateur de l'attribut netgroupUser qui utilise le motif all-domain et le nom de domaine pleinement qualifié du DUA correspond à cet attribut quand le préfix est supprimé.

netservice

   Une base netservice mappe les netgroups aux services et privilèges. Les netservices peuvent être utilisé pour déterminer quelles applications devraient fonctionner sur un hôte, comment ils devraient être configurés, et quelles actions les utilisateurs peuvent ou non effectuer.

La représentation chaîne d'un nom netservice pleinement qualifié devrait correspondre à la grammaire suivante, qui utilise les production ABNF:
service-name = keyname
service-descriptor = keyname *(SLASH keyname)
en = service-name COLON service-descriptor

   Le composant service-name identifie le service, et le service-descriptor est un chemin délimité par des slash qui identifie un sous-composant ou un sous-système dans le service. Une application est libre d'interpréter le nom d'un netservice de la manière qui lui convient, bien qu'il est suggéré qu'un netservice identifie soit un privilège soit une configuration qui peut être application au niveau de l'hôte ou utilisateur.

   Le service-name est représenté dans LDAP par une entrée avec l'objectClass netserviceObject. Chaque composant délimité par un slash du service-descriptor sont des objets enfants dans LDAP avec l'objectClass netserviceDescriptor.

ObjectClass

   Une entrée dbisMapConfig pour une base netservice devrait avoir l'objectClass dbisNetserviceConfig. Un netservice devrait être définis par une entrée LDAP avec l'objectClass netserviceObject.

dbisNetserviceConfig

La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )

netserviceObject

La classe netserviceObject devrait être assigné à l'entrée qui représente un service-name et est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.6 NAME 'netserviceObject' DESC 'DBIS netservice top-level entry' SUP netserviceDescriptor STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

netserviceDescriptor

La classe netserviceDescriptor devrait être assigné à chaque entrée qui représente les composants service-descriptor et est définis comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.7 NAME 'netserviceDescriptor' DESC 'DBIS netservice descriptor entry' SUP top STRUCTURAL MUST en MAY ( exactNetgroup $ exactNetservice $ description $ manager $ disableObject ) )

Attributes

en

   Le nom du netgroup est stocké dans l'attribut LDAP en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée netgroupObject et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

netgroupHost

Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
Un hôte qui est membre d'un netgroup est stocké dans l'attribut netgroupHost qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost' DESC 'Host or domain that is assigned to a netgroup' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

La représentation chaîne de l'attribut netgroupHost devrait matcher la grammaire suivante, qui utilise les productions ABNF:
host = keyname-low
domain = keyname-low *(DOT keyname-low)
host-domain = host DOT domain
all-domain = ASTERISK DOT domain
    
netgroupHost = host / host-domain / all-domain

   Un DUA devrait déréférencer tout alias et convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter l'attribut netgroupHost ou un filtre le contenant.

netgroupUser

Un utilisateur qui est membre d'un netgroup est stocké dans l'attribut netgroupUser qui peut être assigné à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.9 NAME 'netgroupUser' DESC 'User who is assigned to a netgroup' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain
La représentation chaîne de l'attribut netgroupUser devrait matcher la grammaire suivante, qui utilise les production ABNF:
user = keyname
user-host = user ATSIGN host
user-host-domain = user ATSIGN host-domain
user-all-domain = user ATSIGN all-domain
    
netgroupUser = user / user-host
netgroupUser =/ user-host-domain / user-all-domain

   Un DUA devrait convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter un attribut netgroupUser ou un filtre le contenant.

netgroupTriple

Pour compatibilité avec la rfc2307, DBIS permet également l'appartenance exprimé sous la forme de triplet netgroup en fournissant un ou plusieurs attributs netgroupTriple qui peuvent être assignés à une entrée netgroupObject:
attributetype ( 1.3.6.1.4.1.23780.219.2.37 NAME 'netgroupTriple' DESC 'Case exact netgroup triple' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Un DUA devrait convertir les composant nom d'hôte et nom de domaine en minuscule avant de traiter un attribut netgroupTriple ou un filtre le contenant.

exactNetgroup

   Les membres d'autres netgroup peuvent être hérités par ce netgroup en fournissant des noms de netgroup additionnels dans un ou plusieurs attributs exactNetgroup qui peuvent être assignés à une entrée netgroupObject:

   Le DUA devrait valider qu'un netgroup référencé par cet attribut existe et est activé. Si le netgroup n'est pas définis, ou s'il a été désactivé avec l'attribut disableObject, il ne doit pas être inclus dans la réponse au client.

manager

   L'attribut manager peut être associé avec une entrée netgroupObject pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsable de la maintenance de l'entrée.

disableObject

   Une entrée netgroup peut être désactivée en définissant l'attribut disableObject à TRUE.

Exemple d'entrée Netgroup


dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

Déterminer les hôtes membre

   Un utilisateur doit rencontrer un des conditions suivantes pour être considéré un membre d'un netgroup:

        a) L'attribut netgroupUser ne contient pas de ATSIGN et le nom d'utilisateur correspond exactement à l'attribut netgoupUser
        b) Le nom d'utilisateur correspond au composant user de l'attribut netgroupUser, et le nom d'hôte non-qualifié du DUA convertis en minuscule correspond au composant hôte de l'attribut netgroupUser.
        c) Le nom d'utilisateur correspond au composant user de netgroupUser, et le nom d'hôte pleinement qualifié du DUA convertis en minuscule correspond au composant de domaine hôte de l'attribut netgroupUser.
        d) Le nom d'utilisateur correspond au composant user de l'attribut netgroupUser, l'attribut netgroupUser utilise le motif all-domain et le nom de domaine pleinement qualifié du DUA convertis en minuscule correspond à cet attribut quand le préfix ASTERISK DOT est supprimé.

netservice

   Une base netservice mappe les netgroups à des services et privilèges. Les netservices peuvent être utilisé pour déterminer quelles applications devraient fonctionner sur un hôte, comment ils devraient être configurés, et quelles actions les utilisateurs peuvent faire ou non.

La représentation chaîne d'un nom netservice pleinement qualifié devrait suivre la grammaire suivante, qui utilise les production ABNF:
service-name = keyname
service-descriptor = keyname *(SLASH keyname)
    
en = service-name COLON service-descriptor

   Le composant service-name identifie le service, alors que le service-descriptor est un chemin délimité par les anti-slash qui identifie un sous-composant ou un sous-système dans le service. Une application est lible d'interpréter le nom d'un netservice de la manière qui lui convienne, bien qu'il soit suggéré qu'un netservice identifie soit un privilège ou une configuration qui peut être appliqué au niveau de l'hôte ou utilisateur.

   service-name est représente dans LDAP par une entrée avec l'objectClass netserviceObject. Chaque composant délimité de service-descriptor sont des objets enfants dans LDAP avec l'objetClass netserviceDescriptor.

Classes d'objet

   Une entrée dbisMapConfig pour une base netservice devrait être assignée avec l'objectClass dbisNetserviceConfig

dbisNetserviceConfig

La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )
La classe dbisNetserviceConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.5 NAME 'dbisNetserviceConfig' DESC 'DBIS netservice configuration map' SUP dbisMapConfig STRUCTURAL )

netserviceObject

La classe netserviceObject devrait être assignée à l'entrée qui représente le service-name et est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.6 NAME 'netserviceObject' DESC 'DBIS netservice top-level entry' SUP netserviceDescriptor STRUCTURAL MUST en MAY ( description $ manager $ disableObject ) )

netserviceDescriptor

La classe netserviceDescriptor devrait être assignée à chaque entrée qui représente des composants service-descriptor et est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.7 NAME 'netserviceDescriptor' DESC 'DBIS netservice descriptor entry' SUP top STRUCTURAL MUST en MAY ( exactNetgroup $ exactNetservice $ description $ manager $ disableObject ) )

Attributs

en

   Le service-name de netservice et chaque service-descriptor sont stockés dans des attributs LDAP de type en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée netserviceObject et netserviceDescriptor, et devrait former le RDN. Si requis, des entrées alias peuvent être définies.

exactNetgroup

   Les utilisateurs et les hôtes bénéficient d'un netservice s'ils sont membre d'un ou plusieurs netgroups identifiés par les attributs exactNetgroup qui peuvent être assignés à une entrée netserviceDescriptor.

exactNetservice

d'autres netservices peuvent être hérités en utilisant un ou plusieurs attributs exactNetservice qui peuvent être assignés à une entrée netserviceDescriptor:
attributetype ( 1.3.6.1.4.1.23780.219.2.11 NAME 'exactNetservice' DESC 'Case exact netservice name associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

   Chaque netservice identifié par l'attribut exactNetservice devrait être un nom netservice pleinement qualifié. Le DUA devrait valider qu'un netservice référencé par cet attribut existe et est activé. Si le netservice n'est pas définis, ou s'il n'a pas été désactivé avec l'attribut disableObject, il ne devrait pas être considéré.

description

   L'attribut description peut être associé avec une entrée netserviceObject ou netserviceDescriptor pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut etre associé avec un netserviceObject ou netserviceDescriptor pour fournir un ou plusieurs DN des individus, groupes ou systèmes qui sont responsables de la maintenance de l'object.

disableObject

   Une entrée netservice peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si l'entrée n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais doit les marquer clairement comme désactivés. L'attribut disableObject peut être définis sur soit dans l'entrée netserviceObject soit netserviceDescriptor. Si définis dans l'entrée netserviceObject, le DUA devrait traiter toutes les entrées netserviceDescriptor présents comme désactivés également.

Exemple d'entrées netservice

L'exemple suivante montre des entrées netservice au format ldif:
dn: en=ssh,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: ssh
description: Secure Shell Service
    
dn: en=login,en=ssh,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
exactNetgroup: all-hosts
exactNetservice: ftp:login
exactNetservice: web:login/anonymous
    
dn: en=ftp,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: ftp
description: FTP Service
    
dn: en=login,en=ftp,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
    
dn: en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
objectClass: netserviceObject
en: web
description: Web Service
    
dn: en=login,en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
    
dn: en=anonymous,en=login,en=web,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: anonymous

   Ces entrées exemple définissent un netservice appelé ssh:login qui est permis aux membres de du netgroup all-hosts. Si ce netservice est activé, les netservices ftp:login et web:login, également définis, seront activés automatiquement.

Attributs communs

   Des attributs additionnels qui sont soit utilisés dans ce document ou requis par d'autres documents en utilisant les netgroups sont définis ou référencés ci-dessous.

notNetgroup

Un ou plusieurs netgroups qui sont exclus d'une entrée de configuration particulière sont fournis dans les attributs notNetgroup:
attributetype ( 1.3.6.1.4.1.23780.219.2.12 NAME 'notNetgroup' DESC 'Case exact netgroup name NOT to be associated with this entry' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

Syntaxe d'attribut

Les syntaxes suivantes sont utilisées par les attributs définis dans ce document:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax OID Value Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.15 Directory String [RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notes d'implémentation

netgroups NIS

   les netgroups DBIS diffèrent des netgroups NIS et des netgroups définis dans la rfc2307, qui utilise des triplets au format: (host,user,domain), où "host" est le nom d'hôte canonique du système client demandant un service, "user" est le nom d'utilisateur qui demande un service, et "domain" est le nom de domaine du service demandé. Il les champs host, user et domain sont vides, alors le netgroup NIS s'applique à tous les hôtes, utilisateurs, ou domaines respectivement.

   L'utilisation la plus commune des netgroups NIS est pour définir des groupes d'hôte et d'utilisateurs alors que le domaine est généralement laissé vide.

   DBIS sépare le triplet en 2 attributs séparés, netgroupHost et netgroupUser, et redéfinis également le composant domaine à utiliser pour représenter tous les hôtes dans un domaine donné. Un jeu de règles de mappage peut être utilisé pour convertir la représentation chaîne de netgroup DBIS et une liste de triplets netgroup NIS. Dans la grammaire suivante, la règle commençant par t- est sélectionnée en fonction de l'information fournie dans l'attribut netgroupHost ou netgoupUser. En supprimant le t- on peut déduire le nom de la règle de correspondance:


t-host = LPAREN host COMMA COMMA RPAREN
t-host-domain = LPAREN host-domain COMMA COMMA RPAREN
t-all-domain = LPAREN COMMA COMMA domain RPAREN
t-user = LPAREN COMMA user COMMA RPAREN
t-user-host = LPAREN host COMMA user COMMA RPAREN
t-user-host-domain = LPAREN host-domain COMMA user COMMA RPAREN
t-user-all-domain = LPAREN COMMA user COMMA domain RPAREN
    
triple-any = t-host / t-host-domain / t-all-domain
triple-any =/ t-user / t-user-host / t-user-host-domain
triple-any =/ t-user-all-domain
    
triples = t-any *(SPACE t-any)

Former les entrées netgroupHost ou netgroupUser

   L'appartenance à un netgroup devrait être exprimé en termes de noms canoniques uniquement. Vu que le composant username de l'attribut netgroupUser est sensible à la casse alors que les autres composants ne le sont pas, un DUA devrait convertir les composants nom d'hôte et nom de domaine en minuscule avant de former un attribut netgroupHost ou netgroupUser ou un filtre le contenant. C'est pour s'assurer que la correspodance effectuée sur ces attributs n'échoueront pas sur le nom d'hôte ou le nom de domaine sur à une problème de casse.

Paramètres de recherche

   Cette section fournis des exemples de filtres de recherche pour obtenir des entrées de base avec les critères communément utilisés.

   Pour simplifier les exemples, on assume que toutes les base ont une seul entrée de map de configuration (dbisMapConfig). Cependant, le draft-bannister-dbis-mapping permet d'utiliser plusieurs entrées, donc pour qu'une implémentation le supporte, le nombre d'opérations de recherche nécessaire pour localiser toutes les entrées de base doit être augmenté.

   Ce document ne considère pas comment incorporer les entrées de base hosts ou passwd qui utilisent l'attribut exactNetgroup comme moyen alternatif pour spécifier les membre de netgroup.

   Le DN de base utilisé dans les opérations de recherche décris dans cette section vient de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Noter que les base netgroup et netservice utilisé dans ces filtres de recherche peuvent être modifiés par l'attribut dbisMapClass et dbisMapAttr assigné à l'entrée dbisMapConfig. Dans tous les filtres ci-dessous, les noms de domaine DNS pleinement qualifiés sont obtenus comme décris dans la section "Déterminer les hôtes membre".

Trouver la Map de configuration pour le domaine

   Pour localiser la map de configuration pour un domaine DBIS donné, recherche les entrées sous l'entrée dbisDomainObject

Les maps netgroup peuvent être trouvés avec le filtre de recherche suivant
(&(objectClass=dbisNetgroupConfig)(!(disableObject=TRUE)))
Les maps netservice avec:
(&(objectClass=dbisNetserviceConfig)(!(disableObject=TRUE)))

Lister toutes les entrées

Les netgroup et netservices sont énumérés en appliquant le dbisMapFilter comme suit:
(&(dbisMapFilter)(!(disableObject=TRUE)))

Trouver un netgroup ou netservice particulier

Is un netgroup ou netservice est connu par "nom", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))

   Si c'est un netservice et que l'entrée retournée est un netserviceDescriptor et pas un netserviceObject, alors un test additionnel devrait être effectué sur l'attribut disableObject sur le netserviceObject parent pour déterminer si le netservice est désactivé.

   En recherchant des netservice spécifiques par nom, ce filtre peut retourner plus d'un résultat, vu que l'unicité de l'espace de nom est déterminé par le chemin et non par le nom dans une entrée LDAP.

Trouver des netgroup par membership

Pour obtenir une liste de tous les netgroups qu'un utilisateur avec le nom de login "user", qui est connecté sur un hôte nommé "host" avec le domaine DNS "domain" est un membre, le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(netgroupUser=user)(netgroupUser=user@host.domain)(netgroupUser=user@\2a.domain)))

Pour obtenir une liste de tous les netgroups qu'un système nommé "host" avec le nom dns "domaine" est un membre, le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(netgroupHost=host)(netgroupHost=host.domain)(netgroupHost=\2a.domain)))

   Si l'utilisateur ou l'hôte n'est pas un membre explicite du netgroup, le membreship implicite doit être déterminé en examinant récursivement chaque attribut exactNetgroup dans le jeu de résultat. Pour empêcher les boucles infinies, un DUA ne devrait pas tester un netgroup plus d'une fois durant une opération de membership.

Membre d'un netgroup spécifique

Pour déterminer si un utilisateur avec un nom "user", qui est loggé sur un hôte nommé "host", avec un nom de domaine "domain" est un membre d'un netgroup spécifique appelé "name", le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name)(|(netgroupUser=user)(netgroupUser=user@host.domain)(netgroupUser=user@\2a.domain)))

Pour déterminer si un système nommé "host" avec le nom de domaine "domain" est un membre d'un netgroup spécifique appelé "name", le filtre de recherche suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name)(|(netgroupHost=host)(netgroupHost=host.domain)(netgroupHost=\2a.domain)))

   Si l'utilisateur ou l'hôte n'est pas un membre explicite du netgroup, un membership implicite doit être détermineé en examinant récursivement chaque attribut exactNetgroup dans le jeu de résultat.

Quels Netgroups sont activés

   parfois il est nécessaire de déterminer depuis une liste de netgroups quels sont ceux qui sont activés. Cela peut être effectués en utilisant une opération de recherche. Dans cet exemple les netgroups testés sont appelés "netgr1", "netgr2" et "netgr3".

Pour déterminer si une système nommé "host" avec le nom de domaine "domaine" est un membre d'un netgroup spécifique appelé "name", le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(|(en=netgr1)(en=netgr2)(en=netgr3)))

Trouver des netservices par membership

Pour obtenir une liste de tous les netservices qui sont assignés au netgroup appelé "netgroup", le filtre suivant peut être utilisé:
(&(dbisMapFilter)(!(disableObject=TRUE))(exactNetgroup=netgroup))

   Le nom netservice peut être dérivé du DN des entrées retournées. Par exemple, "en=anonymous,en=login,en=web,dbisMapDN" représente le netservice web:login/anonymous.

   Chaque entrée retournée peut lister des netservices additionnels assignés par l'attribut exactNetservice

   Si une entrée netservice trouvé est un netserviceDescriptor et non un netserviceObject, un test supplémentaire devrait être effectué pour l'attribut disableObject sur le netserviceObject parent pour déterminer si le netservice est désactivé.

Membre d'un netservice spécifique

   Pour déterminer si un netgroup a été assigné à un netservice spécifique, le nom netservice doit être splitté en un nom de chemin consistant de 'en=...,en=...' pour qu'une entrée spécifique avec l'objectClass netserviceDescriptor puisse être recherchée sous dbisMapDN. Si cette entrée a un attribut exactNetgroup correspondant au nom de membre désiré, une correspondance est trouvée.

   Par exemple, le netservice web:login/anonymous devient le chemin 'en=anonymous,en=login,en=web' sous dbisMapDN. Le netserviceDescriptor correspondant à ce DN contient la définition du netservice donné. L'attribut exactNetgroup associé avec cette entrée contient la liste des netgroups assignés au netservice web:login/anonymous.

De plus, le filtre de recherche suivant peut être utilisé pour localiser les netservices qui incluent en netservice appelé "netservice" dans leur définitions et qui sont assignés au netgroup nommé "netgroup":
(&(dbisMapFilter)(!(disableObject=TRUE))(exactNetservice=netservice)(exactNetgroup=netgroup))

   Si une entrée est retournée par une recherche avec ce filtre alors une correspondance a été trouvée.
^
24 juillet 2015

htmlpdflatexmanmd




draft-bannister-dbis-passwd-05

draft-bannister-dbis-passwd-05

dbis: passwd et group

   Ce document étend DBIS pour supporter les bases passwd et group. Ces schémas de base devraient être compatible avec NIS, mais stockés dans des entrées X.500 pour qu'ils puissent être résolus avec le protocole LDAP. Une base passwd représente les comptes de connexion utilisateurs sur les systèmes UNIX et dérivés et une base group représente des groupes d'utilisateurs.

   Ce document décris les maps de configuration pour les bases de données passwd et group, et les entrées de base référencée par ces maps.

Maps de configuration

   Toutes les base décrites dans ce document utilisent les maps de configuration standard définies dans draft-bannister-dbis-mapping. Additionnellement, les entrées dbisMapConfig pour les bases passwd et group devraient être assignées avec l'objectClass dbisPasswdConfig et dbisGroupConfig, respectivement.

Il est recommandé que l'entrée dbisMapConfig pour une base passwd ou group ait l'attribut dbisMapFilter définis en accord avec la table suivante:
Database______dbisMapFilter
passwd________objectClass=posixUserAccount
group_________objectClass=posixGroupAccount

Exemple d'entrées de map de configuration

L'exemple suivant donne un exemple d'entrée de map de configuration pour une base passwd:
dn: cn=passwd,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
profileTTL: 900
description: Primary passwd database

L'exemple suivant donne un exemple d'entrée de map de configuration pour une base group:
dn: cn=group,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisGroupConfig
cn: group
dbisMapDN: cn=group,ou=dbis,o=infra
dbisMapFilter: objectClass=posixGroupAccount
profileTTL: 900
description: Primary group database

base passwd

   Une base de données passwd contient les champs suivants:

- Nom d'utilisateur
- Mot de passe de l'utilisateur
- Identifiant numérique de l'utilisateur
- Identifiant numérique du groupe primaire de l'utilisateur
- description de l'utilisateur
- Chemin du répertoire personnel de l'utilisateur
- Chemin du shell de connexion de l'utilisateur.

ObjectClass

   Une entrée dbisMapConfig pour une base passwd devrait avoir l'objectClass dbisPasswdConfig. Une entrée passwd devrait être définie par une entrée LDAP avec l'objectClass posixUserAccount. Vu que c'est une classe auxiliaire, elle doit également avoir une classe structurelle assignée qui n'est pas définis dans ce document, par exemple inetOrgPerson.

dbisPasswdConfig

La classe dbispasswdConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.8 NAME 'dbisPasswdConfig' DESC 'DBIS passwd configuration map' SUP dbisMapConfig STRUCTURAL MUST dbisMapGecos MAY dbisOverlayDN )

posixUserAccount

La classe posixUserAccount est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.9 NAME 'posixUserAccount' DESC 'User account with POSIX attributes' SUP top AUXILIARY MUST ( en $ uidNumber $ gidNumber $ homeDirectory ) MAY ( authPassword $ userPassword $ loginShell $ disableObject ) )

Attributs

  

dbisMapGecos

le champ gecos maintient traditionnellement le nom complet de l'utilisateur et parfois d'autres informations descriptive sur le compte. informations qui sont mieux stockées dans des attributs nommés plus spécifiquement. Vu qu'il y a une variété de manière de stocker ces informations déjà disponibles, ce document ne définis pas de champs additionnel pour les informations gecos, mais l'attribut dbisMapGecos doit être assigné à une entrée dbisPasswdConfig et qui maintient le nom de l'attribut à utiliser pour fournir les informations gecos. Il est définis:
attributetype ( 1.3.6.1.4.1.23780.219.2.13 NAME 'dbisMapGecos' DESC 'Source attribute for gecos field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   L'objectClass posixUserAccount est auxiliaire et doit toujours être associé avec une autre classe structurelle. Une telle classe est inetOrgPerson. Si les comptes utilisateurs on la class inetOrgPerson, le displayName peut être une valeur approprié pour l'attribut dbisMapGecos.

dbisOverlayDN

Un ou plusieurs DN identifiant la base de recherche pour les entrées overlay sont stockés dans l'attribut dbisOverlayDN qui peut être assigné à une entrée dbisPasswdConfig:
attributetype ( 1.3.6.1.4.1.23780.219.2.14 NAME 'dbisOverlayDN' DESC 'DN of search base for DBIS overlay entries' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

en

   Le nom du compte utilisateur est stocké dans l'attribut en qui est définis dans draft-bannister-dbis-mapping. L'attribut en doit être associé avec une entrée posixUserAccount et devrait former le RDN.

uidNumber

L'UID est stocké dans l'attribut uidNumber qui doit être assigné à l'entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'An integer uniquely identifying a user in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

gidNumber

Le GID primaire est stocké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount:
attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'An integer uniquely identifying a group in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

homeDirectory

Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut homeDirectory qui doit être assigné à une entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

authPassword

   Le mot de passe chiffré de l'utilisateur est stocké dans l'attribut authPassword qui est définis dans la rfc3112, et qui peut être assigné à une entrée posixUserAccount.

   Bien qu'un DUA peut implémenter tout schéma de mot de passe d'authentification supporté par le DSA, il doit supporter le schéma CRYPT pour la compatibilité, qui est une implémentation de l'algorithme de chiffrement traditionnel UNIX. Cependant, il est recommandé qu'un schéma plus sécurisé soit utilisé.

   Si l'attribut authPassword a plusieurs valeurs, le DUA devrait sélectionner un mot de passe basé sur le schéma d'authentification le plus fort qu'il supporte et l'utiliser pour l'authentification. Si l'authentification échoue, le DUA ne devrait pas tenter d'utiliser d'autres valeurs. Si l'attribut n'utilise pas de schéma supporté par le DUA, alors le DUA ne devrait pas réussir l'authentification.

   Si une entrée posixUserAccount n'a pas d'attribut authPassword ou userPassword, le compte est blocké. Un DUA ne devrait pas réussir une authentification sur un compte blocké.

   Le transfert des valeurs authPassword est fortement découragé quand le service de transport sous-jacent ne peut pas garantir la confidentialité.

userPassword

   Pour des raisons de compatibilité, le mot de passe chiffré de l'utilisateur peut alternativement être stocké dans l'attribut userPassword qui peut être assigné à une entrée posixUserAccount.

   Il est prévu pour supporter les configurations existantes uniquement et ne devrait pas être utilisé pour les nouvelles entrées, qui devraient utiliser authPassword.

La représentation chaîne de l'attribut userPassword devrait matcher la grammaire suivante, spécifiée en notation ABNF:
scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
altscheme = "x-" keystring
userPassword = LCURLY scheme RCURLY cryptpass

   où "cryptpass" représente le mot de passe hashé par l'algorithme spécifié. Si le schéma est "sha", le SHA-1 du mot de passe est calculé, et le mot de passe chiffré devrait être encodé en base64.

   Bien qu'un DUA peut implémenter n'importe quel schéma supporté par le DSA, il doit supporter le schéma "crypt" pour des raisons de compatibilité. Cependant, il est recommandé qu'un schéma plus sécurisé soit utilisé.

   Si l'attribut userPassword a plus d'un seul valeur, le DUA devrait sélectionner un mot de passe basé sur le schéma d'authentification le plus fort qu'il supporte. Si l'authentification échoue, le DUA ne devrait pas tenter d'utiliser d'autres valeurs. Si l'attribut n'utilise pas de schéma supporté par le DUA, l'authentification doit échouer.

loginShell

Le chemin du répertoire personnel de l'utilisateur est stocké dans l'attribut loginShell qui peut être assigné à une entrée posixUserAccount:
attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'The path to the login shell' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   Si le loginShell est manquant, cet utilisateur ne sera pas capable de se connecter sur un hôte ou un service qui nécessite un shell unix.

disableObject

   Un compte utilisateur peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si cet utilisateur n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais elles doivent être clairement marquées désactivées pour ne pas créer de confusion.

Exemple d'entrée passwd

L'exemple suivant est un exemple d'entrée posixUserAccount au format LDIF:
dn: en=mark,ou=passwd,ou=sales,o=infra
objectClass: top
objectClass: inetOrgPerson
objectClass: posixUserAccount
cn: Mark
sn: Bannister
displayName: Bannister, Mark
en: mark
uidNumber: 101
gidNumber: 900
homeDirectory: /home/mark
loginShell: /bin/bash

groupes

   Une base group contient les détails suivants:

- Le nom du groupe
- Le mot de passe du groupe
- Un identifiant numérique pour le groupe
- La liste des membres

ObjectClass

   Une entrée dbisMapConfig pour une base group devrait avoir l'objectClass dbisGroupConfig. Une entrée group devrait être définie par une entrée avec l'objectClass posixGroupAccount.

dbisGroupConfig

La classe dbisGroupConfig est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.11 NAME 'dbisGroupConfig' DESC 'DBIS group configuration map' SUP dbisMapConfig STRUCTURAL MAY dbisOverlayDN )

posixGroupAccount

La classe posixGroupAccount est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.12 NAME 'posixGroupAccount' DESC 'Group account with POSIX attributes' SUP top STRUCTURAL MUST ( en $ gidNumber ) MAY ( authPassword $ userPassword $ exactUser $ uniqueMember $ description $ manager $ disableObject ) )

en

   Le nom du compte groupe est stocké dans l'attribut en. Cet attribut doit être associé avec une entrée posixGroupAccount et devrait former le RDN.

gidNumber

   Le GID est socké dans l'attribut gidNumber qui doit être assigné à une entrée posixGroupAccount

authPassword

   Le mot de passe chiffré du groupe est stocké dans l'attribut authPassword qui peut être assigné à une entrée posixGroupAccount. Toutes les considérations liées à l'attribut authPassword données dans la section de même nom pour la base passwd s'applique également aux entrées posixGroupAccount. Si un attribut authPassword est définis, l'utilisateur doit fournir le bon mot de passe avant que le DUA autorise la bascule dans ce groupe

userPassword

   Pour des raisons de compatibilité, le mot de passe chiffré du groupe peut alternativement être stocké dans l'attribut userPassword et peut être assigné à une entrée posixGroupAccount. Toutes les considérations liées à l'attribut userPassword données dans la section de même nom pour la base passwd s'applique également aux entrées posixGroupAccount.

exactUser

Une liste d'un ou plusieurs noms de comptes qui sont membres du groupe sont stockés dans les attributs exactUser qui peuvent être assignés à une entrée posixGroupAccount:
attributetype ( 1.3.6.1.4.1.23780.219.2.26 NAME 'exactUser' DESC 'One or more user account names' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

uniqueMember

   Pour des raisons de compatibilité, les membres du groupe peuvent alternativement être stockés dans l'attribut uniqueMember et peut être assigné à une entrée posixGroupAccount. Il est prévu pour supporter les configurations existantes uniquement et ne devrait pas être utilisé pour les nouvelles entrées. Un DUA doit supporter les 2 format.

   Les membres référés par l'attribut uniqueMember devrait être assumés avoir été présentés via la map de configuration existante, même s'ils sont présentés dans un DN de base différent. L'attribut uniqueMember n'est donc pas prévu pour référencer les utilisateurs ou groupes qui sont définis avec un schéma différent. L'attribut exactUser ne souffre pas de ce problème.

description

   L'attribut description peut être associé avec une entrée posixGroupAccount pour fournir une description arbitraire de l'entrée.

manager

   L'attribut manager peut être associé avec une entrée posixGroupAccount pour fournir un ou plusieurs DN d'individus, groupes ou systèmes qui sont responsables de la maintenance de l'entrée.

disableObject

   Un goupe peut être désactivé en définissant l'attribut disableObject à TRUE. Si une entrée est désactivée, le DUA devrait se comporter comme si le groupe n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrée groupe

L'exemple suivant est une entrée posixGroupAccount au format LDIF:
dn: en=finance,ou=group,ou=sales,o=infra
objectClass: top
objectClass: posixGroupAccount
en: finance
gidNumber: 152
exactUser: mark
exactUser: julie
exactUser: stephen
exactUser: nathan

Overlays

   Les overlays fournissent les entrées passwd et group alternatifs qui peuvent écraser l'UID, GID, Home ou shell pour les groupes d'hôtes qui partagent une map de configuration. C'est utile pour fusionner 2 domaines DBIS avec des ID qui se chevauchent en permettant une période de transition quand les hôtes et services du domaine d'origine peut continuer à utiliser leur ID et shell originaux. Un DUA devrait implémenter les overlays.

   Considérons l'exemple où UserA et UserB ont les UID 100 et 101, et le shell /bin/sh sur HostA et HostB, mais nécessitent les UID 1000 et 1001 et le shell /bin/csh sur HostC et HostD. Les 4 hôtes sont membre du même domaine DBIS. Les overlays permettent ce type de configuration. Un DUA devrait traiter les overlays après toute transformation définie dans la map de configuration.

ObjectClass

   Le DN top-level sous lequel rechercher les entrées overlay devraient être définis par l'attribut dbisOverlayDN qui est associé avec une entrée dbisPasswdConfig ou dbisGroupConfig. Les entrées overlay doivent résider sous ce DN s'ils sont utilisé par un DUA.

   Les entrées overlay pour la base passwd sont identifiées par l'objectClass dbisPasswdOverlay. Les entrées overlay pour la base group sont identifiés par l'objectClass dbisGroupOverlay.

dbisPasswdOverlay

La classe dbisPasswdOverlay est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.13 NAME 'dbisPasswdOverlay' DESC 'User account overlay entry' SUP top STRUCTURAL MUST en MAY ( uidNumber $ homeDirectory $ loginShell $ description $ disableObject ) )

dbisGroupOverlay

La classe dbisGroupOverlay est définie comme suit:
objectclass ( 1.3.6.1.4.1.23780.219.1.14 NAME 'dbisGroupOverlay' DESC 'Group account overlay entry' SUP top STRUCTURAL MUST en MAY ( gidNumber $ description $ disableObject ) )

Attributs

en

   L'attribut en doit être assigné à une entrée dbisPasswdOverlay ou dbisGroupOverlay et est utilisé pour identifier l'entrée posixUserAccount ou posixGroupAccount. Si les attributs en correspondent exactement, ou si c'est un dbisPasswdOverlay et qu'il n'y a pas de correspondance exacte mais une entrée pas défaut existe identifié par un attribut en contenant un asterisk, les attributs fournis par l'overlay devraient remplacer ceux dans l'entrée originale.

   Quand un DUA recherche une entrée posixUserAccount ou posixGroupAccount qui a une configuration d'overlay, il devrait également rechercher une entrée dbisPasswdOverlay ou dbisGroupOverlay.

   Si une entrée par défaut est trouvée (par ex: en=*), l'attribut uidNumber est ignoré s'il est assigné à l'objet dbisPasswdOverlay.

uidNumber

   Un UID alternatif à utiliser pour un compte utilisateur correspondant peut être stocké dans l'attribut uidNumber qui peut être associé avec une entrée dbisPasswdOverlay

gidNumber

   Un GID alternatif à utiliser pour un groupe correspondant peut être stocké dans l'attribut gidNumber qui peut être associé avec une entrée dbisGroupOverlay

HomeDirectory

   Un répertoire personnel alternatif à utiliser pour un compte utilisateur correspondant est stocké dans l'attribut homeDirectory qui peut être associé avec une entrée dbisPasswdOverlay.

loginShell

   Un shell de connexion alternatif à utiliser pour un compte utilisateur correspondante est stocké dans l'attribut loginShell qui peut être associé avec une entrée dbisPasswdOverlay.

description

   L'attribut description peut être associé avec une entrée dbisPasswdOverlay ou dbisGroupOverlay pour fournir une description arbitraire de l'entrée.

disableObject

   Une entrée overlay peut être désactivée en définissant l'attribut disableObject à TRUE. Si une entrée est désactivé, le DUA devrait se comporter comme si l'overlay n'existait pas. Le DUA peut optionnellement fournir un mécanisme séparé pour lister les entrées désactivées, mais ils doivent les marquer clairement comme désactivé pour éviter toute confusion.

Exemple d'entrées overlay

L'exemple suivant montre un entrée dbisPasswdOverlay au format ldif, et les entrée dbisMapConfig correspondantes. Dans cet exemple, l'utilisateur "julie" qui se log sur des hôtes qui font partie du netgroup "sales-merger" aura un UID alternatif 5001 et un shell "/bin/sh". Si "julie" se logs sur un autre hôte, elle aura son UID et loginShell normal:
dn: cn=passwd,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
notNetgroup: sales-merger
profileTTL: 900
description: Primary passwd database
    
dn: cn=passwd2,en=sales.corp,ou=domain-mappings,o=infra
objectClass: top
objectClass: dbisMapConfig
objectClass: dbisPasswdConfig
cn: passwd2
dbisMapDN: cn=passwd,ou=dbis,o=infra
dbisMapFilter: objectClass=posixUserAccount
dbisMapGecos: displayName
dbisOverlayDN: ou=passwd,ou=overlays,ou=sales-merger,o=infra
profileTTL: 900
description: Primary passwd database for Sales merger
    
dn: en=julie,ou=passwd,ou=overlays,ou=sales-merger,o=infra
objectClass: top
objectClass: dbisPasswdOverlay
en: julie
uidNumber: 5001
loginShell: /bin/sh

L'exemple suivant montre un dbisGroupOverlay qui modifie le GID pour le groupe "finance" quand il est utilisé dans une entrée de map de configuration:
dn: en=finance,ou=group,ou=overlays,ou=sales-merger,o=infra
objectClass: top
objectClass: dbisGroupOverlay
en: finance
gidNumber: 7308

Syntaxe d'attributs

Les syntaxes suivantes sont utilisée par les attributs définis dans ce document:
Syntax OID - - - - - - - - - - Value - - - - - - Reference
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1.3.6.1.4.1.1466.115.121.1.12 DN - - - - - - - - [RFC4517]
1.3.6.1.4.1.1466.115.121.1.15 Directory String -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String - - - -[RFC4517]
1.3.6.1.4.1.1466.115.121.1.27 Integer - - - - - [RFC4517]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notes d'implémentation

  

Mappage des champs compatibles NIS

   Tous les champs requis pour le format des bases NIS passwd et group existent dans ce schéma et peuvent être mappés aux types d'attribut en utilisant les production ABNF décrites dans draft-bannister-dbis-netgroup.

passwd

Les champs de la base passwd sont mappés comme suit:
user = en
password = %x78 ; lowercase "x", see below
uid = uidNumber
gid = gidNumber
gecos = dbisMapGecos ; derived, see below
homedir = homeDirectory
loginshell = loginShell
    
passwd-entry = user COLON password COLON uid COLON gid COLON gecos COLON homedir COLON loginshell

- password vaux "x" qui signifie traditionnellement que le mot de passe est stocké dans la base shadow. Cependant, c'est dûs aux permission plus stricts du fichier shadow, rendant les mots de passe plus sécurisés. LDAP n'a pas ce problème, l'attribut authPassword est associé avec l'objectClass posixUserAccount. Un implémenteur peut cependant optionnellement reporter le mot de passe chiffré dans les entrées passwd NIS, ou pas du tout. Pour des raisons de sécurité il est recommandé que les utilisateurs ne puissent pas afficher leur mot de passe chiffré à d'autres utilisateurs ou groupe.
- gecos est déterminé en recherchant l'attribut définis par l'attribut dbisMapGecos donné dans l'entrée de map de configuration.

group

Les champs de la base group sont mappés comme suit:
group = en
password = %x2a ; asterisk "*", see below
gid = gidNumber
users = exactUser ; derived, see below
    
group-entry = group COLON password COLON gid COLON users

- Pour des raisons de sécurité il est recommandé que le mot de passe soit mis à "*" et pas de authPassword.
- La liste des utilisateur est une liste séparé par des virgules d'attributs exactUser.

Filtres de recherche communs

   Cette section fournis des exemples de filtres de recherche LDAP pour obtenir des entrées de base avec des critères d'entrée communément utilisés.

   Pour simplifier les exemples, toutes les base sont assumée être définis avec seulement une entrée de map de configuration. Cependant, une implémentation doit le supporter, augmentant le nombre d'opérations nécessaires pour localiser les entrées de base dans le scope.

   Le DN de base utilisé dans les opérations de recherche décrites dans cette section viennent de l'attribut dbisMapDN assigné à l'entrée dbisMapConfig. Noter qu'une entrée dbisMapConfig peut en avoir plusieurs.

   Quand il apparaît dans les filtres de recherche ci-dessous, le texte "dbisMapFilter" réfère à la valeur assignée à l'attribut de même nom dans l'entrée dbisMapConfig correspondante. Noter que les bases passwd et group ont des entrées dbisMapConfig différentes. Les noms d'attributs utilisés dans ces filtres de recherche peuvent être modifiés par l'attribut dbisMapAttr assignés à l'entrée dbisMapConfig.

Pour localiser la map de configuration pour un domain DBIS donné, rechercher les entrées sous l'entrée dbisDomainObject:
(&(objectClass=dbisPasswdConfig)(!(disableObject=TRUE)))
(&(objectClass=dbisGroupConfig)(!(disableObject=TRUE)))
Les entrées passwd et group sont énumérées en appliquant le filtre dbisMapFilter suivant:
(&(dbisMapFilter)(!(disableObject=TRUE)))
Si une entrée passwd et group est connue pas "name", sa définition est localisée en utilisant le filtre de recherche suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(en=name))
Si une entrée passwd a l'uid "uid", sa définition est localisée en utilisant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(uidNumber=uid))
Si une entrée group a le gid "gid", sa définition est localisée en utilisant le filtre suivant:
(&(dbisMapFilter)(!(disableObject=TRUE))(gidNumber=gid))
^
15 septembre 2014

htmlpdflatexmanmd




draft-behera-ldap-password-policy-10

draft-behera-ldap-password-policy-10

Stratégie de mot de passe pour les annuaires LDAP

   La stratégie de mot de passe comme décrit dans ce document est un jeu de règles qui contrôle comment les mots de passes sont utilisés et administrés dans les annuaires basés sur LDAP. Pour améliorer la sécurité les annuaires LDAP et rendre la tâche des programmes de cracking de mot de passe plus difficile. Cet règles sont faites pour s'assurer que les utilisateurs changent leur mot de passe périodiquement, et que ces mots de passe soient soumis à des obligations, et une restriction sur la réutilisation des anciens mots de passe.

Application des stratégies de mot de passe

   La stratégie de mot de passe définie dans ce document peut être appliquée à tout attribut maintenant un mot de passe utilisateur utilisé pour les opérations de bind LDAP. Dans ce document, le terme utilisateur représente toute application LDAP cliente qui a une identité dans l'annuaire.

   Cette stratégie est typiquement appliquée à l'attribut userPassword dans le cas de la méthode d'authentification simple bind ou dans le cas d'un mot de passe basé sur une authentification SASL tel que CRAM-MD5 et DIGEST-MD5.

   La stratégie décrite dans ce document assume que l'attribut du mot de passe maintient une simple valeur. Aucune considération n'est faite pour les annuaires ou systèmes qui permettent à un utilisateur de maintenir des attributs de mot de passe multi-valués.

   Les implémentations de serveur peuvent inclure une stratégie interne où certaines identités (tels que les administrateurs d'annuaire) ne soient pas soumis à une stratégie de mot de passe. Dans ce cas, le mot de passe pour un administrateur d'annuaire n'expire jamais; le compte n'est jamais bloqué, etc.

Stratégie d'utilisation de mot de passe

   Cette section décris la stratégie utilisée quand un mot de passe est utilisée. L'objectif général de cette stratégie est de réduire au minimum la menace d'intrus une fois un mot de passe utilisé.

Stratégie de validité de mot de passe

   Ces mécanismes permettent de contrôler l'utilisation de compte indépendemment de toute stratégie d'expiration de mot de passe. La stratégie définis la période de temps absolue pour lequel un compte peut être utilisé. Cela permet à un administrateur de définir une date de début après laquelle un mot de passe devient valide, et une date de fin après laquelle le mot de passe est désactivé. Un mécanisme est également fournis pour définir la période de temps pour laquelle un compte peut rester non-utilisé avant d'être désactivé.

Limiter les mots de passe devinés

   Pour empêcher un intrus de deviner le mot de passe d'un utilisateur, un mécanisme existe pour traquer le nombre de tentative d'authentification échouées, et agir lorsque la limite est atteinte. Cette stratégie consiste de nombreuses parties:

        - Un compteur pour suivre le nombre de tentative d'authentification échouées.
        - La quantité de temps à attendre dans la première authentification échouée.
        - La quantité maximum de temps à attendre pour les échecs suivants
        - Un timeframe dans lequel la limite de tentative d'authentification échouées doit être atteinte avant qu'une action soit prise.
        - Une limite configurable de tentative d'authentification échouées.
        - L'action a prendre quand la limite est atteinte. L'action sera soit "rien", ou le compte sera bloqué.
        - Une quantité de temps durant lequel le compte est bloqué.

   Noter qu'utiliser la fonctionnalité de blocage de compte est une aide précieuse pour les attaques DOS sur les comptes utilisateurs. Cette fonctionnalité est découragée en faveur d'un délai entre les différentes tentatives. Le délai va doubler à chaque tentative, "x‹int›" pour les multiplicateurs constant, "^‹int›" pour les géométriques.

Stratégie de modification de mot de passe

   Cette section décris la stratégie appliquée quand un utilisateur modifie son mot de passe. Le focus général est de s'assurer que lorsqu'un utilisateur ajoute ou change son mot de passe, la sécurité et l'efficacité de ce mot de passe est maximisé. Dans ce document, le terme "opération de modification de mot de passe" réfère à toute opération qui est utilisée pour ajouter ou modifier un attribut de mot de passe. Souvent cela est fait en mettant à jours l'attribut du mot de passe durant une opération d'ajout ou de modification, mais peut être faite par d'autres moyens tels que les opérations étendues.

Expiration, alerte et période de grâce

   Si un mot de passe est fréquemment changé, les chances que le compte de cet utilisateur soit cassé sont minimisés. Les administrateurs de stratégie de mot de passe peuvent déployer une stratégie de mot de passe qui force les mots de passe à expirer après un temps donné, ce qui force les utilisateurs à changer leur mot de passe périodiquement.

   Il doit cependant y avoir un moyen par lequel les utilisateurs soient informés de cette nécessité de changer leur mot de passe avant d'être effectivement bloqué. Une ou les deux méthodes suivantes le gère:

        - Un message d'alerte peut être retourné à l'utilisateur quelques temps avant que son mot de passe n'expire.
        - L'utilisateur peut s'authentifier auprès de l'annuaire un certain nombre de fois après que son mot de passe ait expiré.

Historique de mot de passe

   Quand la stratégie d'expiration de mot de passe est utilisée, un mécanisme additionnel est utilisé pour empêcher les utilisateurs de ré-utiliser leur précédent mot de passe. Pour cela, un historique les mots de passe est conservé. L'administrateur peut définir le nombre de mots de passe à conserver. Les utilisateurs n'ont pas le droit d'utiliser un mot de passe présent dans cette liste.

Âge minimum de mot de passe

   Les utilisateurs peuvent outrepasser le mécanisme d'historique de mot de passe en effectuant une série de changement de mot de passe, jusqu'à ce que leur mot de passe favoris soit disponible. Pour empêcher cela, l'âge minimum d'un mot de passe peut être forcés.

Longueur minimum et qualité de mot de passe

   Pour empêcher les utilisateurs de créer ou mettre à jours les mots de passe qui sont facile à deviner, une stratégie de qualité de mot de passe peut être employée. Cette stratégie consiste de 2 mécanismes généraux - s'assurer que le mot de passe est conforme aux critères de qualité et s'assurer qu'ils ont une longueur minimale. Forcer un mot de passe à être conforme avec une stratégie peut impliquer divers choses, incluant:

        - Interdire les mots triviaux et bien connus
        - Forcer un certain nombre de chiffres à utiliser
        - Interdire les anagrammes du nom de l'utilisateur

   L'implémentation de cette stratégie rencontre les problèmes suivants:

        - Si le mot de passe à ajouter ou mettre à jours est chiffré par le client avant d'être envoyé, le serveur ne peut pas forcer cette stratégie.
        - Il n'y a pas de définition spécifique de ce que signifie une vérification de gualité. Cela peut poser problèmes dans des milieux hétérogènes.

Mots de passes définis par les utilisateurs

   Dans certains cas, il est désirable d'interdire les utilisateur d'ajouter ou modifier leur propres mots de passe. Cette stratégie rend cela possible.

Changement de mot de passe après réinitialisation

   Cette stratégie force l'utilisateur à mettre à jours son mot de passe après qu'il ait été définis pour la première fois, ou a été réinitialisé.

Modification sûre

   Vu que les annuaires sont communément utilisés, il devient fréquent que les clients se connecte à l'annuaire et laissent la connexion ouverte pour une période étendue. Cela permet à un attaquant d'effectuer des modifications sur un mot de passe utilisateur pendant que la machine de l'utilisateur est connectée. Cette stratégie force l'utilisateur à prouver son identité en spécifiant l'ancien mot de passe durant l'opération de modification de mot de passe.

Restriction de la stratégie de mot de passe

   La stratégie de mot de passe définie dans ce document peut s'appliquer à tout attribut contenant un mot de passe. Les informations d'état de stratégie de mot de passe est maintenu dans l'entrée de l'utilisateur. Un serveur doit donc s'assurer que l'attribut du mot de passe est sujet à la stratégie de mot de passe, qu'il contient une et une seule valeur de mot de passe.

ObjectClass

pwdPolicy Contient les attributs définissant une stratégie de mot de passe pour un jeu d'utilisateur.

Attributs

pwdAttribute Maintient le nom de l'attribut auquel la stratégie de mot de passe s'applique
pwdMinAge Nombre de secondes entre chaque changement de mot de passe. Si non présent, assume 0
pwdMaxAge Nombre de secondes avant qu'un mot de passe n'expire. Si vide ou 0, le mot de passe n'expire jamais.
pwdInHistory Spécifie le nombre maximum de mot de passes stoqués dans l'attribut pwdHistory
pwdCheckQuality !!! Indique comment la qualité de mot de passe est vérifié lors d'un ajout ou d'une modification. Si non présent ou 0, aucune vérification n'est faite. 1, indique que le serveur vérifie la qualité, et s'il n'est pas capable de le faire, le mot de passe est accepté. 2 vérifie la qualité, et s'il n'est pas capable de le faire, retourne une erreur.
pwdMinLengh Quand la vérification de mot de passe est actif, cet attribut maintient le nombre de caractères minimum à utiliser dans un mot de passe.
pwdMaxLengh Quand la vérification de mot de passe est actif, cet attribut maintient le nombre de caractères maximum à utiliser dans un mot de passe.
pwdExpireWarning Spécifie le nombre maximum de secondes avant qu'un mot de passe soit près d'expirer et qu'un message d'alerte soit retourné à l'utilisateur. La valeur doit être plus petite que la valeur de pwdMaxAge.
pwdGraceAuthNLimit Spécifie le nombre de fois qu'un mot de passe expiré peut être utilisé pour s'authentifier. Si non présent ou à 0, l'authentification échoue.
pwdGraceExpiry Spécifie le nombre de secondes de la validité de la période de grâce.
pwdLockout À TRUE, indique que le mot de passe ne peut plus être utilisé pour s'authentifier après le nombre de tentative spécifié dans pwdMaxFailure.
pwdLockoutDuration Maintient le nombre de secondes que le mot de passe ne peut être utilisé pour s'authentifier due à trop grand nombre d'échec. À 0,le mot de passe ne peut plus être utilisé jusqu'à un reset administratif.
pwdMaxFailure Spécifie le nombre maximum d'authentification consécutives échouées.
pwdFailureCountInterval Maintient le nombre de secondes après lesquel le compteur d'échec est purgé, même quand aucune authentification réussie ne s'est produite. Si non présent ou à 0, ne peut être ré-initialisé qu'avec une authentification réussie.
pwdMustChange À TRUE, les utilisateurs doivent changer leur mot de passe la prochaine fois qu'ils s'authentifie.
pwdAllowUserChange Indique si les utilisateurs peuvent changer leur propre mot de passe, bien que cette opération reste sujette à contrôle d'accès. Cet attribut est conçus pour être utilisé en l'absence de mécanisme de contrôle d'accès.
pwdSafeModify Spécifie si le mot de passe existant doit être envoyé avec le nouveau lors du changement de mot de passe.
pwdMinDelay Spécifie le nombre de secondes d'attente après la première tentative d'authentification échouée. Si définis, pwdMaxDelay doit l'être également.
pwdMaxDelay Délai maximum après une authentification échouée. Ce temp est spécifié en pwdMinDelay utilisé comme point de départ et est doublé à chaque tentative jusqu'à atteindre pwdMaxDelay.
pwdMaxIdle Nombre de secondes qu'un compte peut rester non-utilisé avant d'être bloqué.

   Les informations d'état de stratégie de mot de passe peuvent être maintenus pour chaque utilisateur. Ces informations sont localisées dans chaque entrée de l'utilisateur comme jeu d'attributs opérationnels. Ces attributs opérationnels sont: décris ci-dessous.

   Vu que les stratégies de mot de passe peuvent s'appliquer à de nombreux attributs utilisés pour stocker les mots de passe, chaque attribut opérationnel doit avoir une option pour spécifier à quel pwdAttribute il s'applique. L'option est définie comme suit:

  pwd-‹passwordAttribute

  où passwordAttribute est le nom court de l'attribut

  pwdChangedTime;pwd-userPassword: 20000103121520Z

Attributs Opérationnels

pwdChangedTime Spécifie la date du dernier changement de mot de passe. Utilisé par la stratégie d'expiration du mot de passe. Si non présent, le mot de passe n'expire jamais.
pwdAccountLockedTime Maintient la date à laquelle le compte utilisateur a été bloqué. Une valeur 000001010000Z signifie que le compte a été bloqué de manière permanente, et que seul un reset administratif peut débloquer le compte.
pwdFailureTime Maintient les date des derniers échec d'authentification.
pwdHistory Maintient l'historique des précédents mots de passe. Les valeurs de cet attribut sont au format (ABNF):


pwdHistory = time "#" syntaxOID "#" length "#" data
time = GeneralizedTime
syntaxOID = numericoid ; the string representation of the
        ; dotted-decimal OID that defines the
        ; syntax used to store the password.
length = number ; the number of octets in data.
data = ‹octets representing the password in the format specified by syntaxOID›.

pwdGraceUseTime Maintient les périodes de grâce après qu'un mot de passe a expiré.
pwdReset Maintient un flag pour indiquer (à TRUE) que le mot de passe a été mis à jours par un administrateur et doit être changé par l'utilisateur.
pwdPolicySubentry Pointe vers une subentry pwdPolicy effectif sur l'objet.
pwdStartTime Spécifie la date à laquelle le mot de passe devient valide pour l'authentification.
pwdEndTime Spécifie la date après laquelle le mot de passe devient invalide pour l'authentification.
pwdLastSuccess Maintient la date de la dernière authentification réussie

ObjectClass


( 1.3.6.1.4.1.42.2.27.8.2.1
    NAME 'pwdPolicy'
    SUP top
    AUXILIARY
    MUST ( pwdAttribute )
    MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
    pwdMinLength $ pwdMaxLength $ pwdExpireWarning $
    pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
    pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
    pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
    pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )

Attributs


( 1.3.6.1.4.1.42.2.27.8.1.1
    NAME 'pwdAttribute'
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
( 1.3.6.1.4.1.42.2.27.8.1.2
    NAME 'pwdMinAge'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.3
    NAME 'pwdMaxAge'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.4
    NAME 'pwdInHistory'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.5
    NAME 'pwdCheckQuality'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.6
    NAME 'pwdMinLength'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.31
    NAME 'pwdMaxLength'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.7
    NAME 'pwdExpireWarning'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.8
    NAME 'pwdGraceAuthNLimit'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.30
    NAME 'pwdGraceExpire'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.9
    NAME 'pwdLockout'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.10
    NAME 'pwdLockoutDuration'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.11
    NAME 'pwdMaxFailure'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    ORDERING integerOrderingMatch
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.12
    NAME 'pwdFailureCountInterval'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    ORDERING integerOrderingMatch
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.13
    NAME 'pwdMustChange'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.14
    NAME 'pwdAllowUserChange'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.15
    NAME 'pwdSafeModify'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.24
    NAME 'pwdMinDelay'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.25
    NAME 'pwdMaxDelay'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.26
    NAME 'pwdMaxIdle'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )

Attributs opérationnels


( 1.3.6.1.4.1.42.2.27.8.1.16
    NAME 'pwdChangedTime'
    DESC 'The time the password was last changed'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.17
    NAME 'pwdAccountLockedTime'
    DESC 'The time an user account was locked'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.19
    NAME 'pwdFailureTime'
    DESC 'The timestamps of the last consecutive authentication
    failures'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.20
    NAME 'pwdHistory'
    DESC 'The history of user s passwords'
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.21
    NAME 'pwdGraceUseTime'
    DESC 'The timestamps of the grace authentication after the
    password has expired'
    EQUALITY generalizedTimeMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.22
    NAME 'pwdReset'
    DESC 'The indication that the password has been reset'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
    SINGLE-VALUE
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.23
    NAME 'pwdPolicySubentry'
    DESC 'The pwdPolicy subentry in effect for this object'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.27
    NAME 'pwdStartTime'
    DESC 'The time the password becomes enabled'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.28
    NAME 'pwdEndTime'
    DESC 'The time the password becomes disabled'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.29
    NAME 'pwdLastSuccess'
    DESC 'The timestamp of the last successful authentication'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

Contrôles utilisés pour la stratégie de mot de passe

   Cette section détaille les contrôles utilisés lors de l'application des stratégies de mot de passe. Un contrôle de request est définie et est envoyé par un client avec une opération request pour déclencher un contrôle de réponse. Cette réponse contient diverses alertes et erreurs associés avec une stratégie de mot de passe.

Request Control

   Ce contrôle peut être envoyé avec tout message de demande LDAP pour transmettre au serveur est prêt et peut traiter le contrôle de réponse décris dans ce document. Le controlType est 1.3.6.1.4.1.42.2.27.8.5.1. Il n'y a pas de controlValue.

Response Control

   Si le client a envoyé un contrôle passwordPolicyRequest, le serveur envoie ce contrôle avec les opérations de réponses suivantes: bindResponse, modifyResponse, addResponse, compareResponse et extendedResponse, pour informer des divers conditions, et peut l'envoyer avec d'autres opérations (dans le cas de l'erreur changeAfterReset). Le controlType est 1.3.6.1.4.1.42.2.27.8.5.1 et controlValue est le BER du type:


PasswordPolicyResponseValue ::= SEQUENCE {
    warning [0] CHOICE {
        timeBeforeExpiration [0] INTEGER (0 .. maxInt),
        graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
    error [1] ENUMERATED {
        passwordExpired (0),
        accountLocked (1),
        changeAfterReset (2),
        passwordModNotAllowed (3),
        mustSupplyOldPassword (4),
        insufficientPasswordQuality (5),
        passwordTooShort (6),
        passwordTooYoung (7),
        passwordInHistory (8) } OPTIONAL }

timeBeforeExpiration spécifie le nombre de secondes avant qu'un mot de passe n'expire.
graceAuthNsRemaining spécifie le nombre restant de fois qu'un utilisateur sera autorisé à s'authentifier une fois le mot de passe expiré.
passwordExpired signifie que le mot de passe a expiré et qu'il doit être changé.
passwordModNotAllowed est définis quand un utilisateur ne peut pas changer son mot de passe.
insufficientPasswordQuality est définis quand un mot de passe ne passe pas la vérification de la qualité
passwordTooYoung Définis si l'âge du mot de passe à modifier n'est pas suffisamment ancien

Stratégie de points de décision

   La suite est une série de procédure utilisées pour effectuer des décisions de stratégie. Ces procédures sont généralement effectués par le serveur durant le traitement d'une opération.

Vérification de compte bloqué

   Un statut TRUE est retourné pour indiquer que le compte est bloqué si une de ces conditions est rencontrée:

- La valeur de pwdAccountLockedTime est 000001010000Z
- L'heure courante est antérieure à pwdStartTime
- L'heure courante est postérieure à pwdEndTime
- L'heure courante est supérieur ou égal à la valeur de pwdLastSuccess ajouté à la valeur de pwdMaxIdle
- L'heure courante est inférieure à la valeur de pwdAccountLockedTime ajouté à la valeur de pwdLockoutDuration

   Sinon un statut FALSE est retourné.

Vérification de changement de mot de passe

   Un statut TRUE est retourné pour indiquer que le mot de passe doit être changé si toutes les conditions suivantes sont rencontrées:

- L'attribut pwdMustChange est à TRUE
- l'attribut pwdReset est à TRUE

Vérification d'expiration de mot de passe

   Un statut de TRUE est retourné indiquant que le mot de passe a expiré si l'heure courante moins la valeur de pwdChangedTime est supérieur à la valeur de pwdMaxAge. Sinon, un statut de FALSE est retourné.

Vérification de AuthN Grace restant

   Si l'attribut pwdGraceExpiry est présent, et que la date courante est supérieur au temps d'expiration du mot de passe plus la valeur pwdGraceExpiry, 0 est retourné. Si l'attribut pwdGraceUseTime est présent, le nombre de valeurs dans cet attribut soustrait de la valeur de pwdGraceAuthNLimit est retourné. Un résultat positif spécifie le nombre d'authentifications de grâce restant.

Vérification de date avant expiration

   Si l'attribut pwdExpireWarning n'est pas présent un statut de 0 est retourné. Sinon, soustrait le temp stocké dans pwdChangedTime de l'heure courante pour arriver à l'âge du mot de passe. Si l'âge du mot de passe est supérieur à la valeur de pwdMaxAge, un status 0 est retourné. Soustrait la valeur de pwdExpireWarning de la valeur de pwdMaxAge pour arriver à l'âge d'alerte, la valeur de pwdMaxAge moins l'âge du mot de passe est retourné.

Vérification de blocage d'intrus

   Un statut de TRUE indiquant qu'un intrus a été détecté est retourné si les conditions suivantes sont rencontrées:

- L'attribut pwdLockout est TRUE
- Le nombre de valeurs dans pwdFailureTime qui sont plus récent que pwdFailureCountInterval est supérieur ou égal à pwdMaxFailure.

   Sinon, un statut de FALSE est retourné. Tout en effectuant cette vérification, les valeurs de pwdFailureTime qui sont maintenus par plus d'un pwdFailureCountInterval sont purgés et non comptés.

Vérification de délai d'intrusion

   Si l'attribut pwdMinDelay est 0 ou non définis, 0 est retourné. Sinon, un délai est calculé basé sur le nombre de valeurs dans l'attribut pwdFailureTime. Si la valeur calculée est supérieur à pwdMaxDelay, la valeur pwdMaxDelay est retournée. Tout en effectuant cette vérification, les valeurs de pwdFailureTime qui sont maintenus par plus d'un pwdFailureCountInterval sont purgé et non comptés.

Vérification de mot de passe trop jeune

   Si la vérification de changement de mot de passe retourne TRUE, cette vérifiction retourne FALSE, pour permettre le changement de mot de passe. Un statut de TRUE indique qu'il ne s'est pas écoulé suffisamment de temps depuis le dernier changement de mot de passe. TRUE est retourné si:

- La valeur de pwdMinAge est non-zéro et pwdChangedTime est présent
- La valeur de pwdMinAge est supérieur à l'heure courante moins la valeur de pwdChangedTime.

   Sinon, un statut de FALSE est retourné.

Points de renforcements de stratégies du serveur

   Le serveur devrait forcer l'attribut du mot de passe sujet à une stratégie de mot de passe tel que définis dans ce document, contenant une et une seule valeur. Note: Dans le cas où un seul mot de passe est stocké dans plusieurs formats est considéré comme une seule valeur de mot de passe.

   Les scénarios dans les opérations suivantes assument que le client a attaché un contrôle passwordPolicyRequest à la demande. Dans le cas où passwordPolicyRequest n'a pas été envoyé, aucun contrôle passwordPolicyResponse n'est retourné. Toutes les autres instructions restent les même.

Authentification basé sur un mot de passe

   Cette section contient les règles de stratégie utilisé pour valider un mot de passe. Les opérations qui valident les mots de passe incluent, entre autre, l'opération Bind et l'opération Compare où l'attribut à comparer contient un mot de passe. Noter que l'opération Compare n'authentifie pas un utilisateur, mais peut être utilisé par une application externe pour authentification.

Echec en cas de compte bloqué

   Si le compte est bloqué, le serveur échoue l'opération avec le code 49 invalidCredentials dans le cas d'une opération Bind, le code 5 compareFalse dans le cas d'une opération Compare, etc. Le serveur peut définir cette erreur: accountLocked (1) dans le passwordPolicyResponse dans le champ contrôle du message.

Procédures de mot de passe validé

   Si l'opération de validation indique que le mot de passe est validé, cet procédures sont suivie dans l'ordre:

- Supprime les attributs pwdFailureTime et pwdAccountLockedTime.
- Définis la valeur de pwdLastSuccess à l'heure courante

Mot de passe à changer

   Si le mot de passe doit être changé, le serveur envoie au client une réponse avec un resultCode success (0), compareTrue (6), etc. Et inclus le passwordPolicyResponse dans le champ controls du message bindResponse avec l'alerte: changeAfterReset spécifié. Pour un bind, le serveur doit interdir toutes les autres opérations fournies par cet utilisateur excepté la modification du mot de passe, bind, unbind, abandon et StartTLS.

Mot de passe expiré

   Si le mot de passe a expiré, le serveur retourne soit un succès ou un échec en fonction de l'état des authentification de grâce.

Authentification de grâce restant

   S'il reste les authentification de grâce, le serveur ajoute une nouvelle valeur avec l'heure courante dans pwdGraceUseTime. Puis il envoie au client une réponse avec un succès, et inclus le passwordPolicyResponse dans la réponse avec l'alerte graceAuthNsRemaining définis au nombre d'authentification restante.

Plus d'authentification de grâce restante

   S'il ne reste plus d'authentification de grâce, le serveur échoue l'opération, et inclus le passwordPolicyResponse dans controls avec l'erreur passwordExpired.

Alerte d'expiration

   Si la vérification d'expiration de mot de passe réussie, le serveur envoie au client une réponse avec un resultCode approprié, et inclus le message timeBeforeExpiration.

Procédures d'échec AuthN

   Si le processus d'authentification indique que le mot de passe échoue la validation du à des accréditifs invalides, ces procédures sont suivies:

Mise à jour d'état de stratégie Ajoute l'heure courant comme valeur de pwdFailureTime.
Détection d'intrusion Si la vérification d'intrus retourne TRUE, le serveur bloque le compte en définissant la valeur de pwdAccountLockedTime à l'heure courante. Une fois le compte bloqué, le serveur échoue l'opération avec l'erreur accountLocked.

Opérations de mise à jour du mot de passe

   Parce que le mot de passe est stocké dans un attribut, divers opérations peuvent être utilisées pour créer ou modifier un mot de passe. Mais certains mécanismes ont été définis ou peuvent être définis tel que la rfc3062 ( LDAP Password Modify). Tout en traitant une mise à jour d'un mot de passe, le serveur effectur les étapes suivantes:

Modification sûre Si pwdSafeModify est à TRUE et qu'il existe un mot de passe, le serveur s'assure que l'opération de mise à jour inclus le mot de passe existant de l'utilisateur. Si le mot de passe n'est pas fournis, le serveur échoue avec l'erreur mustSupplyOldPassword.
Changement après reset Si la vérification de changement de mot de passe à changer retourne true, le serveur s'assure que l'opération de mise à jours ne contient rien d'autre que la modification du mot de passe. Si d'autres modification existent, le serveur envoie un message avec le resultCode insufficientAccessRights avec l'erreur changeAfterReset.
Vérification des droits Vérifie si l'identité a les droits suffisants pour mettre à jours le mot de passe. Si l'utilisateur n'a pas les droits suffisants, le serveur retourne un resultCode insufficientAccessRights avec l'erreur passwordModNotAllowed.
Trop tôt pour la mise à jour Si la vérification d'âge minimum du mot de passe retourne true, le serveur envoie un resultCode constraintViolation avec l'erreur passwordTooYoung.
Qualité du mot de passe Vérifier la valeur de l'attribut pwdCheckQuality. Si la valeur est non zéro, le serveur:

        - S'assure que le mot de passe respecte les critères de qualité définis par le serveur. Si le serveur ne peut pas vérifier la qualité du mot de passe, la valeur de pwdCheckQuality est évalué. Si le serveur peut vérifier la qualité du mot de passe et que la vérification échoue, le serveur envoie un constraintViolation avec l'erreur insufficientPasswordQuality.
        - Vérifie la valeur de pwdMinLengh. Si la valeur est non zéro, il s'assure que le nouveau mot de passe a au moins cette longueur minimum. Si le serveur n'est pas capable de vérifier la longueur, la valeur de pwdCheckQuality est évaluée. Si le serveur peut vérifier la longueur, et qu'il échoue, retourne un constraintViolation avec l'erreur passwordTooShort.

Réutilisation invalide Si pwdInHistory est présent et sa valeur est non-zéro, le serveur vérifie si le mot de passe existe dans pwdHistory ou dans l'attribut du mot de passe. S'il est trouvé, le serveur envoie un constraintViolation avec une erreur passwordInHistory.
Mise à jours d'état de stratégie Si les étapes ont été complétés sans erreur, le serveur effectue les étapes suivantes sur l'entrée à l'heure courante:

        - Si la valeur de pwdMaxAge ou pwdMinAge est non zéro, le serveur ajoute le précédent mot de passe (s'il en existait un) à l'attribut pwdHistory. Si le nombre de valeurs dans pwdHistory excède la valeur de pwdInHistory, le serveur supprime le mot de passe le plus ancien.
        - Si la valeur dans pwdMustChange est TRUE et que la modification est effectuée par un administateur, l'attribut pwdReset est mis à TRUE. Sinon, pwdReset est supprimé de l'entrée.
        - Les attributs pwdFailureTime et pwdGraceUseTime sont supprimés de l'entrée de l'utilisateur s'ils existent.

Autres opérations

   Pour les opérations autre que bind, password update, unbind, abandon ou StartTLS, si la vérification de mot de passe à changer retourne true, le serveur envoie un insufficientAccessRights avec l'erreur changeAfterReset.

Client Policy Enforcement Points

   Ces sections illustrent les scénarios possibles pour chaque opération LDAP et définis les types de réponses qui identifient cet scénarios. Les scénarios dans les opérations suivantes assument que le client a attaché un contrôle passwordPolicyRequest au message de demande de l'opération, et peut recevoir un contrôle passwordPolicyResponse dans le message de réponse. Dans le cas où le contrôle passwordPolicyRequest n'a pas été envoyé, aucun contrôle passwordPolicyResponse n'est retourné. Toutes les autres instructions restent les même.

bind

   Pour chaque réponse bind reçus, le client vérifie le resultCode de bindResponse et recherche un contrôle passwordPolicyResponse pour déterminer si une des conditions est vrai et peut demander à l'utilisateur:

bindResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = accountLocked (1)
La limite d'échec a été atteinte et le compte est bloqué. L'utilisateur doit retenter plus tard ou contacter un administrateur.
bindResponse.resultCode = success (0), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur s'authentifie pour la première fois depuis que l'administateur a définis le mot de passe et l'utilisateur doit changer son mot de passe.
bindResponse.resultCode = success (0), passwordPolicyResponse.warning = graceAuthNsRemaining:
Le mot de passe a expiré mais il reste des authentification de grâce. L'utilisateur doit le changer.
bindResponse.resultCode = invalidCredentials (49), passwordPolicyResponse.error = passwordExpired (0):
Le mot de passe a expiré et il n'y a plus d'authentification de grâce. L'utilisateur doit contacter un administrateur pour réinitialiser son mot de passe.
bindResponse.resultCode = success (0), passwordPolicyResponse.warning = timeBeforeExpiration:
Le mot de passe de l'utilisateur va expirer dans n secondes

modify

   Si l'application ou le client chiffre le mot de passe avant de l'envoyer dans une opération de modification ( soit dans une opération modifyRequest ou un autre mécanisme de modification de mot de passe ), il devrait vérifier les valeur de pwdMinLengh, pwdCheckQuality et devrait imposer ces stratégies.

   Si l'opération medifyRequest a été utilisée pour changer le mot de passe, ou si un autre mécanisme est utilisé - tel que extendedRequest - la réponse peut contenir des informations pertinente pour la stratégie de mot de passe. Le client vérifie le resultCode de la réponse et vérifie que les conditions suivantes sont vraie et optionnellement notifie l'utilisateur des conditions.

pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = mustSupplyOldPassword (4):
L'utilisateur a tenté de changer son mot de passe sans spécifier l'ancien mot de passe et c'est requis par la stratégie.
pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur doit changer son mot de passe avant d'envoyer une autre demande LDAP
pwdModResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = passwordModNotAllowed (3):
L'utilisateur n'a pas les droit suffisants pour changer son mot de passe
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooYoung (7):
Il est trop tôt pour changer le mot de passe
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = insufficientPasswordQuality (5):
La vérification de la qualité du mot de passe a échoué
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooShort (6):
La longueur du mot de passe est trop courte
pwdModResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordInHistory (8):
Le mot de passe a déjà été utilisé, l'utilisateur doit en choisir un différent

add

   Si un mot de passe est spécifié dans un addRequest, le client vérifie le resultCode de addResponse et vérifie le contrôle passwordPolicyResponse pour déterminer si une des conditions est vrai et pour notifier l'utilisateur en conséquence:

addResponse.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = passwordModNotAllowed (3):
L'utilisateur n'a pas les droits suffisants pour ajouter son mot de passe
addResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = insufficientPasswordQuality (5):
Le mot de passe a échoué la vérification de la qualité
addResponse.resultCode = constraintViolation (19), passwordPolicyResponse.error = passwordTooShort (6):
La longueur du mot de passe est trop courte

compare

   Quand une opération compare est utilisée pour comparer un mot de passe, le client vérifie le resultCode de compareResponse et vérifie le passwordPolicyResponse pour déterminer si une des conditions suivantes est vrai et peut notifier l'utilisation en conséquence. Ces conditions assument que le résultat de la comparaison était vrai:

compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = accountLocked (1):
La limite du nombre d'échec a été atteinte et le compte a été bloqué. L'utilisateur doit retenter plus tard ou contacter un administrateur.
compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = graceAuthNsRemaining:
Le mot de passe a expiré mais il reste des authentifications de grâce. L'utilisateur doit le changer
compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = passwordExpired (0):
Le mot de passe a expiré et il ne reste plus d'authentification de grâce. L'utilisateur doit contacter un administrateur
compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = timeBeforeExpiration:
Le mot de passe de l'utilisateur va expirer dans n secondes

Autres opérations

   Pour les opérations autres que bind, unbind, abandon ou StartTLS, le client vérifie le resultCode et de contrôle pour déterminer si l'utilisateur doit changer le mot de passe immédiatement.

‹Response›.resultCode = insufficientAccessRights (50), passwordPolicyResponse.error = changeAfterReset (2):
L'utilisateur doit changer son mot de passe immédiatement

Administation des stratégies de mot de passe

   Une stratégie de mot de passe est définie pour une sous-arborescence du DIT en ajoutant une subentry dont le supérieur immédiat est la racine de la sous-arborescence, l'objectclass auxiliaire pwdPolicy. Le scope de la stratégie est définie par l'attribut SubtreeSpecification.

   Il est possible de définir des stratégies de mot de passe pour différents attributs de mot de passe dans la même entrée pwdPolicy, en spécifiant plusieurs valeurs de pwdAttribute. Les stratégies de mot de passe peuvent également être dans les subentry séparés.

   Seul une stratégie ne peut être effectif pour un attribut de mot de passe dans une entrée. Si plusieurs stratégies existent, qui se chevauchent dans un scope, le résultat est indéfinis.

   Il devrait être possible d'écraser une stratégie de mot de passe pour un utilisateur en définissant une nouvelle stratégie dans une subentry de l'entrée de l'utilisateur.

   Chaque objet qui est contrôlé par une stratégie de mot de passe annonce le subentry à utiliser pour contrôler sa stratégie dans son attribut pwdPolicySubentry. Les clients qui souhaitent examiner ou gérer une stratégie de mot de passe peuvent interroger le pwdPolicySubentry pour cet objet pour connaître le subentry pwdPolicy.

Stratégie de mot de passe et la réplication

   l'objet pwdPolicy définis la stratégie de mot de passe pour une portion du DIT et doit être répliqué dans tous les répliquas de cette sous-arborescence. Les éléments de la stratégie de mot de passe qui sont liés aux utilisateurs sont stockés dans les entrées elles-même en tant qu'attributs opérationnels. Vu que ces attributs sont sujets à modification même sur un répliqua lecture seule, leur réplication doit être considéré avec attention.

   l'attribut pwdChangedTime doit être répliqué sur tous les répliquas, pour permettre l'expiration du mot de passe. L'attribut pwdReset doit être répliqué sur tous les répliquas, pour refuser l'accès aux opérations autre que bind et modify. L'attribut pwdHistory doit être répliqué auprès des répliquas en écriture. Il n'a pas à être répliqué sur un répliqua lecture seul vu que le mot de passe ne sera jamais modifié sur ce serveur.

   Les attribut pwdAccountLockedTime, pwdFailureTime et pwdGraceUseTime devraient être répliqués sur les répliquas en écriture, rendant la stratégie de mot de passe global à tous les serveurs. Quand l'entrée utilisateur est répliquée sur un répliqua lecture-seul, ces attributs ne devraient pas être répliqués. Celà signifie que le nombre d'échec, d'authentification de grâce et de blocage sont dans chaque serveur répliqué. Par exemple, le nombre effectif de tentatives échoués sur un mot de passe utilisateur sera N x M ( où N est le nombre de serveurs et M la valeur de pwdMaxFailure ). Répliquer ces attributs à un répliqua lecture seule peut réduire le nombre de tentatives global mais peut aussi introduire certaines inconsistances dans la manière dans la stratégie est appliquée.

   Note: Il y a certaines situations où la réplication globale de ces attributs d'état peuvent être non-désirable. Par exemple, si 2 clusters de répliquas sont distants géographiquement et joins par un lien lent, et leur utilisateurs se loggent seulement sur un des 2 emplacement, il peut être préférable de ne pas propager tous les changements d'état entre les clusters. Les serveurs devraient permettre aux administrateurs de contrôler quels attributs sont répliqués au cas-par-cas.

   Les serveurs participant à une réplication multi-master devaient employer un mécanisme qui s'assure de l'unicité des valeurs en populant les attributs pwdFailureTime et pwdGraceUseTime. Pour faire ça, c'est un problème locat et peut consister en l'utilisation d'un simple source autoritative pour la génération de valeurs de temps unique, ou peut consister de l'utilisation de la partie fractionnelle des secondes pour maintenir un identifiant de répliqua.

Considérations de sécurité

   Ce document définis un jeu de règles à implémenter dans un serveur LDAP. Pour mitiger certains risques de sécurité associés avec l'utilisation de mots de passe et augmenter la difficulté de crackage de mot de passe.

- L'authentification avec un mot de passe doit suivre les recommandations de la rfc4513
- Les modifications de mot de passe devraient être se produire seulement quand la connexion est protégées pour la confidentialité et une authentification sécurisée.
- Les contrôles d'accès devraient être utilisés pour restreindre l'accès aux attribut de stratégie de mot de passe. Les attributs définis pour maintenir les information de stratégie de mot de passe devaient seulement être modifiable pas l'administrateur de mot de passe ou par une haute autorité.
- Vu qu'il est possible de définir une stratégie de mot de passe pour un utilisateur spécifique en ajoutant un subentry immédiatement sous l'entrée de l'utilisateur, les contrôles d'accès devraient être utilisés pour restreindre l'utilisation de l'objet pwdPolicy ou du subentry.
- Quand une stratégie de mot de passe à détection d'intrus est appliquée, l'annuaire LDAP est sujet aux attaques DOS. Un utilisateur malicieux peut délibérément bloquer le compte d'un utilisateur ( ou tous ) en envoyant des bind avec de faux mots de passe. Il n'y a aucun mécanisme pour parer ces attaques. Le serveur LDAP devraie logger autant d'informations qu'il peut ( tel que les adresses IP ) quand un compte est bloqué, pour être capable d'identifier l'origine de l'attaque. Refuser les accès anonymes à l'annuaire permet de réduire ce genre d'attaque. Utiliser un délai d'authentification à la place aide à éviter ces attaques DOS.
- En retournant certains codes de status ( tel que passwordPolicyResponse.error=accountLocked) permet à un attaquant DOS de savoir qu'il a réussit à bloquer le compte. Les serveurs devraient implémenter des vérifications additionnelles qui retournent le même statut quand il est détecté qu'un certain nombre de demandes d'authentification échoué s'est produit sur une simple connexion, ou depuis une adresse client.
^
10 juin 2014

htmlpdflatexmanmd




draft-chu-ldap-kdc-schema-00

draft-chu-ldap-kdc-schema-00

LDAP KDC Schema

Introduction

  

Motivations

   Kerberos et LDAP sont fréquemment utilisés séparément pour une authentification distribuée. Ils peuvent également être utilisé conjointement, mais leur base de données restent généralement séparées. Ces bases séparées implique une duplication de données et sont source de charge d'administation supplémentaire. Il est donc préférable de partager la même base de données. Un certain nombre d'implémentations Kerberos supportent déjà l'utilisation de LDAP comme stockage du KDC. Cependant, chaque implémentation utilise son propre schéma.

Terminologie

Les OID définis ci-dessous sont dérivés de TBD.OID:
KRBSYN = TBD.OID.0
KRBATTR = TBD.OID.1
KRBOC = TBD.OID.2

Attributs

   Les attributs et classes définies dans ce document sont (additionnellement, certains attributs définis dans LDAP Password Policy sont requis):

krbPrincipalName Nom canonique du principal
krbPrincipalAliases Alias du nom du principal. Vu que cet attribut est un sous-type de krbPrincipalName, une recherche sur krbPrincipalName va également rechercher les alias.
krbTicketMaxLife Maintient le maximum ticket lifetime, en secondes pour un principal.
krbTicketMaxRenewal Maintient la durée maximal de renouvellement d'un ticket
krbEncSaltTypes Maintient les combinaisons chiffrement/salt permis pour ce principal
krbRealmName Nom du domaine Kerberos
krbPrincipalRealm DN de l'entrée krbRealm
krbKeySet Maintient les clés du principal, optionnellement chiffrés avec la clé maître. l'attribut est encodé en utilisant ASN.1


        Le format de la valeur pour cet attribut est:
KrbKeySet ::= SEQUENCE {
    kvno [0] UInt32,
    mkvno [1] UInt32 OPTIONAL,
    keys [2] SEQUENCE OF KrbKey,
    ...
}
    
KrbKey ::= SEQUENCE {
    salt [0] KrbSalt OPTIONAL,
    key [1] EncryptionKey,
    s2kparams [2] OCTET STRING OPTIONAL,
    ...
}
    
KrbSalt ::= SEQUENCE {
    type [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
    
EncryptionKey ::= SEQUENCE {
    keytype [0] Int32,
    keyvalue [1] OCTET STRING
}

krbKeyVersion Stocke le numéro de version de la clé courante
krbTicketPolicy Définis les flags qu'un utilisateur peut utiliser ou demander à utiliser dans une demande de ticket


       
krb5KDCFlagsSyntax SYNTAX ::= {
    WITH SYNTAX INTEGER
        initial(0), -- require as-req
        forwardable(1),-- may issue forwardable
        proxiable(2), -- may issue proxiable
        renewable(3), -- may issue renewable
        postdate(4), -- may issue postdatable
        server(5), -- may be server
        client(6), -- may be client
        invalid(7), -- entry is invalid
        require-preauth(8), -- must use preauth
        change-pw(9), -- change password service
        require-hwauth(10), -- must use hwauth
        ok-as-delegate(11), -- as in TicketFlags
        user-to-user(12), -- may use user-to-user auth
        immutable(13) -- may not be deleted
    ID { 1.3.6.1.4.1.5322.10.0.1 }
}

krbExtraData Maintient des données arbitraires qui peuvent être utilisés par certaines implémentations. la valeur est encodée en DER ASN.1


       
ExtraData ::= SEQUENCE {
    tag [0] OCTET STRING,
    data [1] OCTET STRING
}

krbPrincNamingAttr Enregistre que attributs sont utilisés pour nommer les nouvelles créations de principal
krbPrincContainer Pointe vers un conteneur sous lequel les nouvelles entrées de principaux sont créés.
krbPwdPolicy Point vers une subentry de stratégie de mot de passe contenant la stratégie qui sera appliquée aux principaux Kerberos. Noter que pour les serveur avec le support complet des subentry, cet subentry définissent à quelles entrée elles s'applique. Donc cet attribut n'est pas nécessaire.
krbLDAPURI URI ldap que le KDC utilise pour localiser les principaux.

Classes d'objets

krbKDCInfo
krbPrincipal
krbRealm

Définition des attributs


( KRBATTR.1 NAME 'krbPrincipalName' DESC 'Canonical principal name' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( KRBATTR.2 NAME 'krbPrincipalAliases' SUP krbPrincipalName )
( KRBATTR.3 NAME 'krbTicketMaxLife' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.4 NAME 'krbTicketMaxRenewal' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.5 NAME 'krbEncSaltTypes' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( KRBATTR.6 NAME 'krbRealmName' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.7 NAME 'krbPrincipalRealm' DESC 'DN of krbRealm entry' SUP distinguishedName )
( KRBATTR.8 NAME 'krbKeyVersion' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.9 NAME 'krbKeySet' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.10 NAME 'krbTicketPolicy' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( KRBATTR.11 NAME 'krbExtraData' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
( KRBATTR.12 NAME 'krbPrincNamingAttr' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
( KRBATTR.13 NAME 'krbPrincContainer' DESC 'DN of container entry for principals' SUP distinguishedName SINGLE-VALUE )
( KRBATTR.14 NAME 'krbPwdPolicy' DESC 'DN of password policy subentry' SUP distinguishedName SINGLE-VALUE )
( KRBATTR.15 NAME 'krbLDAPURI' DESC 'LDAP search parameters for locating principals' SUP labeledURI )

Définitions des classes d'objet

( KRBOC.1 NAME 'krbKDCInfo' SUP top AUXILIARY MAY ( krbTicketMaxLife $ krbTicketMaxRenewal $ krbEncSaltTypes $ krbTicketPolicy $ krbKeySet $ krbKeyVersion ) )
( KRBOC.2 NAME 'krbPrincipal' SUP krbKDCInfo AUXILIARY MUST ( krbPrincipalName ) MAY ( krbPrincipalAliases $ krbPrincipalRealm $ krbExtraData ) )
( KRBOC.3 NAME 'krbRealm' SUP krbKDCInfo AUXILIARY MUST ( krbRealmName ) MAY ( krbPrincNamingAttr $ krbPrincContainer $ krbPwdPolicy $ krbLDAPURI ) )

Détails de l'implémentation

   Vu que le LDAP Password Policy est intimement lié à la sécurité de ce draft, l'annuaire devrait être traité en conséquence Cela signifie que pour toute authentification Kerberos déservis, une opération LDAP correspondante est également effectuée, pour permettre au mécanisme de stratégie de mot de passe d'opérer.

   Le mécanisme dessiné ici assume que les accréditifs LDAP et les accréditifs Kerberos sont unifiés (ou au moins synchronisés). Dans ce cas, pour toute requête d'authentification Kerberos entrante, le KDC peut fournir une requête ldap compare en utilisant les accréditifs connus de l'utilisateur et le contrôle ldap Password Policy. Le résultat de la requête va s'occuper de tout code d'erreur si le compte est désactivé, le mot de passe a expiré, ou divers autres échecs. Si la pré-authentification est utilisée et que la requête est invalide, un compare avec des accréditifs invalides connus peuvent être utilisés pour mettre à jours l'état de la stratégie de mot de passe.

Détails du modèle

   Un nombre d'éléments de données décris dans le modèle d'information sont délégués pour LDAP DSA pour la gestion. Les détails de leurs utilisation sont décrites ici.

principalNotUsedBefore

   Correspond à l'attribut pwdStartTime. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalNotUsedAfter

   Correspond à l'attribut pwdEndTime. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalIsDisabled

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon cet effet est contrôlé par le paramètrage de pwdStartTime à une valeur supérieur ou égale à pwdEndTime

principalNumberOfFailedAuthenticationAttempts

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon, cette valeur est obtenue en comptant le nombre de valeurs stockées dans pwdFailureTime

principalLastFailedAuthentication

   Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement. Sinon, cette valeur est obtenue en récupérant les valeur stockées dans pwdFailureTime et en sélectionnant la valeur la plus récente.

principalLastSuccessfulAuthentication

   Correspond à l'attribut pwdLastSuccess. Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalLastCredentialChangeTime

   Correspond à l'attribut pwdChangedTime Si le KDC utilise les requêtes LDAP pour opérer le mécanisme de stratégie de mot de passe, il n'a pas besoin de référencer ou manipuler cet attribut directement.

principalCreateTime

   Correspond à l'attribut createTimestamp. Le KDC n'a pas besoin de référencer ou manipuler cet attribut directement.

principalModifyTime

   Correspond à l'attribut modifyTimestamp. Le KDC n'a pas besoin de référencer ou manipuler cet attribut directement.

Détail de KeySet

   L'attribut krbKeySet est multi-valué mais il est attendu qu'il ait une seule valeur. Durant une opération de changement de mot de passe le KDC peut choisir de conserver une valeur précédente pour permettre aux clients actifs de continuer à opérer en utilisant la clé précédente. La durée de rétention de cet ancien mot de passe n'est pas spécifié ici. Noter également que le mécanisme ldap Password Policy a déja une gestion d'historique de mot de passe, donc krbKeySet ne devrait pas être utilisé pour l'historique des mots de passe.

Considérations de sécurité

   Tout ce document est conserné par l'implémentation d'un mécanisme d'authentification distribué sécurisé. Il faut bien comprendre que les divers clé utilisée ici sont des données sensible et doivent être protégés en conséquence en utilisant les ACL et autres mécanismes. Également, toutes les communications entre le KDC et le DSA doivent être protégés quand des données sensible sont référencées.

   En pratique, le KDC et le DSA sont hébergés sur un serveur hôte et communiquent via ldapi. Celà implique que l'hôte soit également sécurisé, et un canal sécurisé doit être utilisé pour la session LDAP.
^
09 juin 2014

htmlpdflatexmanmd




draft-chu-ldap-ldapi-00

draft-chu-ldap-ldapi-00

LDAP over IPC

Introduction

   Bien que LDAP soit un protocole d'accès distribué, il est courant que des clients soient déployés sur la même machine que le serveur. De nombreuses applications embarquent un client et un serveur. Dans ces déploiements intégrés, où il n'y a pas de trafic réseau, l'utilisation de TCP/IP est inutile. Les systèmes type UNIX offrent des mécanismes IPC natives qui fournissent des sémantiques orienté flux d'une session TCP, mais avec une plus grande efficacité.

   Depuis Janvier 2000, OpenLDAP fournis la possibilité d'établir des sessions LDAP au travers de sockets Unix aussi bien qu'au travers de TCP/IP. De telles sessions sont aussi sécurisée que les sessions TCP sur la boucle local,, mais elles consomment moins de ressources, sont plus rapide à établir, et fournissent une identification sécurisé du client sans nécessiter de mot de passe additionnel ou autres accréditations.

Motivations

   De nombreuses sessions LDAP consistent seulement en une ou 2 requêtes. L'initialisation et la fermeture des connections deviennent une portion significative du temps nécessaire à traiter ces sessions. Également lors de fortes charges, la contrainte de la limite 2MSL dans TCP devient problématique. Par exemple, un processeur moderne AMD64 dual-core qui fait tourner OpenLDAP peut manipuler 32000 authentification par secondes sur un réseau 100Mbps, avec une connection par requête. Connecté via une interface loopback, le taux est plus élevé, mais les connections sont complètement étranglées en moins d'une seconde à cause de tous les numéros de port utilisés et maintenus à l'état TIME_WAIT. Donc même quand le traitement de la charge TCP est insignifiante, la contrainte imposée par la RFC793 crée une limite artificielle. De telles contraintes n'existent pas avec IPC.

Spécification visible à l'utilisateur

   Le seul changement nécessaire des clients pour implémenter cette fonctionnalité est d'utiliser une URL spéciale au lieu de ldap:// pour spécifier le serveur cible. Également, le serveur a besoin d'inclure cette URL dans le liste des adresses d'écoute.

Schéma d'URL

   Le schéma d'URL ldapi: est utilisé pour dénoter une session LDAP sur IPC. La portion d'adresse de l'URL est le nom d'un socket unix, qui est géneralement un chemin complet Unix. les "/" dans le chemin doivent être encodés comme décrit dans la rfc3986. exemple: pour un socket nommé: /var/run/ldapi, l'url du serveur sera ldapi://%26var%26run%26ldapi/. Tous les autres aspects de l'URL sont conformes à la rfc4516.

   Si aucune adresse n'est spécifiée, une adresse par défaut peut être utilisée implicitement. Dans OpenLDAP, l'adresse par défaut est une constante spécifiée à la compilation.

Détails de l'implémentation

   Le transport basique utilise un socket unix orienté flux. Les sémantiques de communication dans un tel socket sont essentiellement identiques à utiliser une session TCP. À part l'établissement de la connexion, aucune considération spéciale n'est nécessaire dans le client, les librairies, ou le serveur.

Authentification Client

   Depuis leurs introduction dans BSD 4.2, les sockets Unix permettent également de passer des accréditifs d'un processus à un autre. Les systèmes moderne peuvent fournir un serveur avec un moyen plus simple.pour obtenir l'identité du client. L'implémentation d'OpenLDAP exploite plusieurs méthodes pour acquérir l'identité du client. La discussion qui suit est nécessairement spécifique à la plateforme.

- La librairie OpenLDAP fournis getpeereid() pour encapsuler tous les mécanismes utilisé pour acquérir l'identité.
- Sur FreeBSD et MacOsX, getpeereid() natif est utilisé
- Sur les systèmes Solaris modernes, getpeerucred() est utilisé
- Sur les systèmes Linux qui supportent l'option SO_PEERCRED de getsockopt() est utilisé
- Sur les systèmes qui n'ont pas ces méthodes, le passeur de descripteur est utilisé. Dans ce cas, le client doit envoyer un message contenant le descripteur comme toute première action immédiatement après la connction du socket. Le descripteur est attaché à une requête LDAP Abandon avec le message ID 0, sont le paramètre a également le message ID à 0. Cette requête est un pure no-op, et sera simplement ignoré par tout serveur n'implémentant pas ce protocole.

   Pour des raisons de sécurité, le descripteur passé doit être contrôlé. Le client crée un pipe et envoie le descripteur de pipe dans le message. Le serveur reçois de descripteur et fait un fstat() dessus pour déterminer l'identité du client. Le descripteur reçu doit être un pipe, et ses permissions doivent permettre l'accès à son propriétaire. L'uid et gid sont ainsi utilisé comme identité du client.

   Noter que ces mécanismes sont simplement utilisés pour que l'identité du client sont disponible au serveur. Le serveur n'utilise pas les informations d'identité sauf si le client fait un Bind SASL en utilisant le mécanisme EXTERNAL.

Autres Plateformes

   Il est possible d'implémenter une fonctionnalité correspondante sur les systèmes basés sur Microsoft Windows en utilisant les pipes nommés, mais il n'y a pas de demande pour celà, et l'implémentation n'a pas été écrite. Le pipe devrait être créé en mode byte-read, et le client doit spécifier l'accès SECURITY_IMPERSONATION quand il ouvre le pipe. Le serveur peut ainsi retrouver l'identité du client en utilisant la fonction GetNamePipeHandleState(). Vu que les sockets Windows ne sont pas interchangeable avec IPC, un event handler alternatif devra être fournis au lieu d'utiliser select().
^
19 mai 2014

htmlpdflatexmanmd




draft-chu-ldap-logschema-00

draft-chu-ldap-logschema-00

Schéma de log du protocol LDAP

   Pour faciliter l'administration distante et l'audit des opérations serveurs LDAP, il est désirable de fournir les logs opérationnels du serveur eux-même comme annuaire LDAP. Ces logs peuvent être également utilisés comme log de changements persistants pour supporter divers mécanismes de réplication. Ce document définis un schéma qui peut être utilisé pour représenter toutes les requêtes qui sont traitées par un serveur LDAP.

Control Syntax

   Une valeur de Control syntax représente un contrôle LDAP tel qu'utilisé par un client ou un serveur. Il consiste de l'OID numérique du contrôle, le flag de criticité, et d'un OctetString optionnel contenant la valeur du contrôle.

La notation ASN.1 est:
Control ::= SEQUENCE {
    controlType LDAPOID,
    criticality BOOLEAN DEFAULT FALSE,
    controlValue OCTET STRING OPTIONAL }

La description de syntaxe ldap est:
( LOG_SCHEMA_SYN.1 DESC 'Control' )

Types d'attributs Généraux

These attributes are common to all of the LDAP request records
( LOG_SCHEMA_AT.1 NAME 'reqDN'
DESC 'Target DN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .2 NAME 'reqStart'
DESC 'Start time of request'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .3 NAME 'reqEnd'
DESC 'End time of request'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .4 NAME 'reqType'
DESC 'Type of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .5 NAME 'reqSession'
DESC 'Session ID of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .6 NAME 'reqAuthzID'
DESC 'Authorization ID of requestor'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .7 NAME 'reqResult'
DESC 'Result code of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .8 NAME 'reqMessage'
DESC 'Error text of request'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .9 NAME 'reqReferral'
DESC 'Referrals returned for request'
SUP labeledURI )
    
( LOG_SCHEMA_AT .10 NAME 'reqControls'
DESC 'Request controls'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' )
    
( LOG_SCHEMA_AT .11 NAME 'reqRespControls'
DESC 'Response controls of request'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' )

Types d'attributs spécifiques aux requêtes

Ces attributs sont spécifiques à un simple type de requêtes ldap:
( LOG_SCHEMA_AT .12 NAME 'reqId'
DESC 'ID of Request to Abandon'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .13 NAME 'reqVersion'
DESC 'Protocol version of Bind request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .14 NAME 'reqMethod'
DESC 'Bind method of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .15 NAME 'reqAssertion'
DESC 'Compare Assertion of request'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .16 NAME 'reqMod'
DESC 'Modifications of request'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch )
    
( LOG_SCHEMA_AT .17 NAME 'reqOld'
DESC 'Old values of entry before request completed'
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
( LOG_SCHEMA_AT .18 NAME 'reqNewRDN'
DESC 'New RDN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .19 NAME 'reqDeleteOldRDN'
DESC 'Delete old RDN'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .20 NAME 'reqNewSuperior'
DESC 'New superior DN of request'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .21 NAME 'reqScope'
DESC 'Scope of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .22 NAME 'reqDerefAliases'
DESC 'Disposition of Aliases in request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .23 NAME 'reqAttrsOnly'
DESC 'Attributes and values of request'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .24 NAME 'reqFilter'
DESC 'Filter of request'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .25 NAME 'reqAttr'
DESC 'Attributes of request'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
( LOG_SCHEMA_AT .26 NAME 'reqSizeLimit'
DESC 'Size limit of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .27 NAME 'reqTimeLimit'
DESC 'Time limit of request'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .28 NAME 'reqEntries'
DESC 'Number of entries returned'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
    
( LOG_SCHEMA_AT .29 NAME 'reqData'
DESC 'Data of extended request'
EQUALITY octetStringMatch
SUBSTR octetStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE )

Classes d'objets d'audit de base

Cette classe contient les attributs communs à toutes les requêtes ldap. Les autres classe héritent toutes de cette classe:
( LOG_SCHEMA_OC .1 NAME 'auditObject' DESC 'OpenLDAP request
auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession )
MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $
reqResult $ reqMessage $ reqReferral ) )

Ces classes d'objet sont utilisées pour agréger les opérations de lecture et d'écriture sous des classes parent communs:
( LOG_SCHEMA_OC .2 NAME 'auditReadObject' DESC 'OpenLDAP read request
record' SUP auditObject STRUCTURAL MUST reqDN )
    
( LOG_SCHEMA_OC .3 NAME 'auditWriteObject' DESC 'OpenLDAP write
request record' SUP auditObject STRUCTURAL MUST reqDN )

Classes d'objets spécifiques aux requêtes

Chaque requête ldap a sa propre classe d'objet contenant tous les attributs nécessaire pour représenter une instance de cette requête:
( LOG_SCHEMA_OC .4 NAME 'auditAbandon' DESC 'Abandon operation' SUP
auditObject STRUCTURAL MUST reqId )
    
( LOG_SCHEMA_OC .5 NAME 'auditAdd' DESC 'Add operation' SUP
auditWriteObject STRUCTURAL MUST reqMod )
    
( LOG_SCHEMA_OC .6 NAME 'auditBind' DESC 'Bind operation' SUP
auditObject STRUCTURAL MUST ( reqDN $ reqMethod $ reqVersion ) )
    
( LOG_SCHEMA_OC .7 NAME 'auditCompare' DESC 'Compare operation' SUP
auditReadObject STRUCTURAL MUST reqAssertion )
    
( LOG_SCHEMA_OC .8 NAME 'auditDelete' DESC 'Delete operation' SUP
auditWriteObject STRUCTURAL MAY reqOld )
    
( LOG_SCHEMA_OC .9 NAME 'auditModify' DESC 'Modify operation' SUP
auditWriteObject STRUCTURAL MUST reqMod MAY reqOld )
    
( LOG_SCHEMA_OC .10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP
auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY
( reqNewSuperior $ reqOld ) )
( LOG_SCHEMA_OC .11 NAME 'auditSearch' DESC 'Search operation' SUP
auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $
reqAttrsonly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit
$ reqTimeLimit ) )
    
( LOG_SCHEMA_OC .12 NAME 'auditExtended' DESC 'Extended operation'
SUP auditObject STRUCTURAL MAY reqData )

Classe conteneur générique

Cette classe d'objet peut être utilisée pour l'entrée parent des enregistrements:
( LOG_SCHEMA_OC .0 NAME 'auditContainer' DESC 'AuditLog container'
SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) )

Discussion du schéma - AuditObject

   1. reqDN: le DN de l'entrée à laquelle le requête s'applique. Dans le cas d'une requête ModRDN, le reqDN donne le DN de l'entrée avant qu'elle ait été modifiée. Dans le cas d'un requête Search, le reqDN est le DN de base de la recherche. Syntaxe: DN.

   2. reqStart: la date du début de la requête sur le serveur. reqEND: la date de la fin de la requête sur le serveur. Les timestamps doivent avoir une résolution suffisante pour s'assurer que les valeur de reqStart et reqEnd sont uniques. Les serveurs devraient utiliser reqStart ou reqEnd comme RDN de l'enregistrement. Ce choix permettra de les les enregistrements dans l'ordre ascendant, bien que les 2 alternatives peuvent produire des résultats différents. Dans le cas où l'horloge du serveur ne fournir pas de temps suffisamment précis, une simple compteur peut être utilisé dans la partie fractionnelle des secondes. Syntaxe: generalizedTime.

   3. reqType: le type de la requête: abandon, add, bind, compare, delete, modify, modrdn, search ou extended{OID}. Pour les requêtes étendues, d'OID de la requête est inclue dans la chaîne. Syntaxe: DirectoryString

   4. reqSession: une valeur qui est une constante pour toutes les opérations se produisant dans une séquence bind/unbind. Syntaxe: DirectoryString

   5. reqAuthzID: L'identité d'authorisation utilisé pour effectuer la requête. Généralement la même que reqDN de la requête bind ayant le même reqSession, mais peut être altéré par divers contrôles et autres traitements. Syntaxe: DN

   6. reqResult: Le code de résultat LDAP de la requête complétée. Cette valeur peut être omise pour les requêtes qui n'ont pas de résultat définis (ex: abandon et unbind) et pour les requêtes qui ont été abandonnées. Syntaxe: Integer

   7. reqMessage: Le message d'erreur textuel accompagnant le résultat, s'il y'en a un. Syntaxe: DirectoryString

   8. reqReferral: Les référants qui ont accompagné le résultat, au format URI LDAP. Syntaxe: DirectoryString

   9. reqControls: le jeu de contrôles de requête accompagnant une requête. seqRespControls: le jeu de contrôles de réponse accompagnant le résultat de la requête. Chaque valeur représente un seul contrôle. l'ordre est préservé en utilisant l'extension de schéma X-ORDERED 'VALUES'. Syntaxe: Control

AuditContainer

   reqStart: le timestamp du premier enregistrement dans le log. reqEnd: le timestamp du dernier enregistrement dans le log. Syntaxe: generalizedTime

Abandon

   reqId: l'ID d'une requête à abandonner. Syntaxe: Integer

Bind

   reqVersion: La version du protocol du la requête. Syntaxe: Integer

  reqMethod: La méthode bind. Soit Simple, soit SASL/mécanisme. Syntaxe: DirectoryString

Compare

   reqAssertion: L'AVA de la requête. Syntaxe: DirectoryString

Rename

   reqNewRDN: Le nouveau rdn de la requête. Syntaxe: DN

  reqDeletedOldRDN: le deleteOldRDN de la requête. Syntaxe: Boolean

  reqNewSuperior: le nouveau DN supérieur de la requête. Syntaxe: DN.

Add et Modify

   reqMod: Les modifications de la requête. L'encodage est définis par la grammaire suivante (ABNF):


mod = attr ":" modop
attr = AttributeDescription from [RFC2251]
modop = add / delete / replace / increment
add = "+" sp value
delete = "-" [ sp value ]
replace = "=" [ sp value ]
increment = "#" sp value
sp = " "
value = AttributeValue from [RFC2251]

   Note que les requêtes Add utilisent uniquement le format add modop. Syntaxe: OctetString

  reqOld: Les valeurs précédente d'un attribut modifié. L'encodage est sous la forme attr ":" sp value, en utilisant la même forme que reqMod. Syntaxe: OctetString

Delete

   reqOld: le valeurs précédente d'une entrée supprimée. L'encodage est le même que plus haut. Syntaxe: OctetString
   reqScope: le scope de la recherche. base, one, sub ou subord. Syntaxe: DirectoryString

  reqDerefAliases: le paramètre derefAliases de la recherche. never, searching, finding, ou always. Syntaxe: DirectoryString

  reqAttrsOnly: le paramètre typesOnly de la requête. Syntaxe: Boolean

  reqFilter: Le filtre de la recherche. Syntaxe: DirectoryString

  reqSizeLimit: La limite de taille de la requête

  reqTimeLimit: Le limite de temps de la requête. Syntaxe: Integer

  reqAttr: Les attributs spécifiquement demandés. Syntaxe: DirectoryString

  reqEntries: Le nombre total d'entrées retournées pour cet requête. Syntaxe: Integer

Extended

   reqData: Les données accompagnant le requête. Syntaxe: OctetString

Exemples

   Dans les exemples suivants les enregistrements résident sous "cn=log" et sont nommés par leur attribut "reqStart"

dn: reqStart=20051017081049.000000Z,cn=log
objectClass: auditBind
reqStart: 20051017081049.000000Z
reqEnd: 20051017081049.000001Z
reqType: bind
reqSession: 0
reqAuthzID:
reqDN: cn=manager,dc=example,dc=com
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
    
dn: reqStart=20051017081049.000002Z,cn=log
objectClass: auditSearch
reqStart: 20051017081049.000002Z
reqEnd: 20051017081049.000003Z
reqType: search
reqSession: 0
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: dc=example,dc=com
reqResult: 0
reqScope: one
reqDerefAliases: never
reqAttrsOnly: FALSE
reqFilter: (objectClass=*)
reqSizeLimit: -1
reqTimeLimit: -1
reqEntries: 3
    
dn: reqStart=20051017081049.000004Z,cn=log
objectClass: auditObject
reqStart: 20051017081049.000004Z
reqEnd: 20051017081049.000005Z
reqType: unbind
reqSession: 0
reqAuthzID: cn=Manager,dc=example,dc=com

requête Add

Enregistrement issue de l'ajout d'une entrée dans l'annuaire:
dn: reqStart=20051017083706.000001Z,cn=log
objectClass: auditAdd
structuralObjectClass: auditAdd
reqStart: 20051017083706.000001Z
reqEnd: 20051017083706.000002Z
reqType: add
reqSession: 4
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqMod: objectClass:+ organizationalUnit
reqMod: ou:+ People
reqMod: description:+ A bunch of people will be here
reqMod: structuralObjectClass:+ organizationalUnit
reqMod: entryUUID:+ f16734aa-d334-1029-9290-cd8deceec6b0
reqMod: creatorsName:+ cn=Manager,dc=example,dc=com
reqMod: createTimestamp:+ 20051017083706Z
reqMod: entryCSN:+ 20051017083706Z#000000#00#000000
reqMod: modifiersName:+ cn=Manager,dc=example,dc=com
reqMod: modifyTimestamp:+ 20051017083706Z

   Notez que les attributs opérationnels écrits avec la requête sont inclus dans le log. Toutes les statistiques associées avec une entrée seront exposées, permettant à un client de réplication d'avoir une copie complète de l'entrée.

Requête Modify

Enregistrement issue d'une entrée modifiée dans l'annuaire
dn: reqStart=20051017083734.000010Z,cn=log
objectClass: auditModify
reqStart: 20051017083734.000010Z
reqEnd: 20051017083734.000011Z
reqType: modify
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqMod: description:-
reqMod: entryCSN:= 20051017083734Z#000003#00#000000
reqMod: modifiersName:= cn=Manager,dc=example,dc=com
reqMod: modifyTimestamp:= 20051017083734Z
reqOld: description: A bunch of people will be here

   Dans cet exemple, l'attribut description a été supprimé de l'entrée. Sa valeur original est enregistrée dans l'attribut reqOld.

Requête Rename

Enregistrement issue du renommage d'une entrée dans l'annuaire
dn: reqStart=20051017083734.000018Z,cn=log
objectClass: auditModRDN
reqStart: 20051017083734.000018Z
reqEnd: 20051017083734.000019Z
reqType: modrdn
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=People,dc=example,dc=com
reqResult: 0
reqNewRDN: ou=Populi
reqDeleteOldRDN: TRUE

Requête Delete

Enregistrement issue de la suppression d'une entrée dans l'annuaire
dn: reqStart=20051017083734.000020Z,cn=log
objectClass: auditDelete
reqStart: 20051017083734.000020Z
reqEnd: 20051017083734.000021Z
reqType: delete
reqSession: 1
reqAuthzID: cn=Manager,dc=example,dc=com
reqDN: ou=Populi,dc=example,dc=com
reqResult: 0
reqOld: ou: Populi
reqOld: objectClass: organizationalUnit
reqOld: structuralObjectClass: organizationalUnit
reqOld: entryUUID: f16734aa-d334-1029-9290-cd8deceec6b0
reqOld: creatorsName: cn=Manager,dc=example,dc=com
reqOld: createTimestamp: 20051017083706Z
reqOld: entryCSN: 20051017083734Z#000007#00#000000
reqOld: modifiersName: cn=Manager,dc=example,dc=com
reqOld: modifyTimestamp: 20051017083734Z

Notes d'usage

   Les serveurs peuvent implémenter seulement un sous-jeu de ces attributs, ou fournir des mécanismes de configuration pour réduire la plage d'opération couverte dans les logs. Les clients de réplication travaillant depuis un log complet peuvent utiliser un filtre de recherche avec les termes "(&(objectClass=AuditWriteObject)(reqResult=0))" pour filtrer les enregistrements peut utile.

Considérations IANA

En accord avec la rfc3383:
OpenLDAP_Experimental = 1.3.6.1.4.1.4203.666
LOG_SCHEMA = OpenLDAP_Experimental.11.5
LOG_SCHEMA_AT = LOG_SCHEMA.1
LOG_SCHEMA_OC = LOG_SCHEMA.2
LOG_SCHEMA_SYN = LOG_SCHEMA.3

^
12 mai 2014

htmlpdflatexmanmd




draft-chu-ldap-xordered-00

draft-chu-ldap-xordered-00

Extension de schéma X-ORDERED

   Ce document décrit un schéma pour attacher des informations ordonnées aux attributs dans un annuaire pour que l'ordre puisse être préservé et propagé aux autres applications LDAP.

   L'extension de schéma X-ORDERED est ajouté à un AttributeTypeDescription pour signifier l'utilisation de ce mécanisme d'ordonnancement. L'extension a 2 variantes. En général cette extension est uniquement compatible avec AttributeType qui a une syntaxe orienté chaîne.

   La variante VALUES est utilisée avec les attributs multi-valués pour maintenir l'ordre des valeurs. Par exemple, cette fonctionnalité est utile pour stocker des données telles que les ACL, qui doivent être évaluées dans un ordre spécifique.

   La variante SIBLINGS est utilisée avec les attributs mono-valués pour maintenir l'ordre de tous les enfants onelevel de l'entrée parent. L'ordre sera ainsi maintenu pour toutes les entrées enfants dont le RDN est de même AttributeType. Par exemple, on pourrait stocker une liste prioritisée de serveurs en tant que jeu d'entrées séparées, chaque entrée contenant les attributs séparés pour une URL, un jeu d'accréditation et divers autres paramètres.

Encodage

L'information d'ordonnancement est encodée en préfixant un index ordinal à chaque valeur, entre accolade:
d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
numericstring = 1*d
ordering-prefix = "{" numericstring "}"
value = ‹any sequence of octets›
ordered-value = ordering-prefix value

   Ils sont basés sur 0 et incrémentés de 1 à chaque valeur. Noter qu'en stockant les valeurs ordonnancées dans un annuaire, le préfixe pour généralement être omis vu qu'il sera généré automatiquement. Mais si la valeur original commence avec une séquence de caractères dans la forme d'un préfixe d'ordonnancement, le préfixe devra être fournis. Utiliser cette extension dans un attribut qui nécessite ce préfixe est une valeur de syntaxe LDAP légal de cet attribut.
   [SECTION] name="Propriété d'ordonnancement" table="paragraphes" imbrication="0"

- Quand présenté avec une AssertionValue qui n'a pas de préfixe d'ordonnancement, le préfixe dans l'AttributeValue est ignoré.
- Quand présenté avec une AssertionValue qui consiste uniquement de ce préfixe, seul le préfixe de cet AttributeValue est comparé, le reste de la valeur est ignoré
- Quand présenté avec une AssertionValue contenant le préfixe et une valeur, les 2 composants sont comparés pour déterminer le match.

   Un effet de bord de ces propriétés et que même les attributs qui normalement n'ont pas de règle de correspondance d'égalité peuvent être matchés par un préfixe d'ordonnancement.

   Le préfixe d'ordonnancement peut être également utilisé dans les requêtes de modification pour spécifier quelles valeur supprimer, et à quelle position devrait les valeurs devraient être ajoutées. Si une valeur ajoutée n'a pas de préfixe, elle est simplement ajoutée à la liste avec un préfixe automatiquement généré.

Exemple de schéma

Ce schéma est utilisé pour tous les exemples:
( EXAMPLE_AT.1 NAME 'olcDatabase'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORDERED 'SIBLINGS' )
    
( EXAMPLE_AT.2 NAME 'olcSuffix'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
X-ORDERED 'VALUES' )
    
( EXAMPLE_OC.1 NAME 'olcDatabaseConfig'
SUP top STRUCTURAL
MAY ( olcDatabase $ olcSuffix ) )

Values ordonnées

En donnant cette entrée:
dn: olcDatabase={1}bdb,cn=config
olcDatabase: {1}bdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=The Example Company
olcSuffix: {3}o=example,c=us

1. On peut effectuer les opérations Modify suivantes:
dn: olcDatabase={1}bdb,cn=config
changetype: modify
delete: olcSuffix
olcSuffix: {0}
-

Cette opération supprime le premier olcSuffix, Sans regardes sa valeur. Toutes les autres valeurs sont remotées d'un position. L'attribut olcSuffix contiendra au final:
olcSuffix: {0}o=example.com
olcSuffix: {1}o=The Example Company
olcSuffix: {2}o=example,c=us

2. En commançant depuis l'entrée originale, on pourrait fournir ce changement à la place:
delete: olcSuffix
olcSuffix: o=example.com
-

Cette oppération supprime le olcSuffix qui matche la valeur, sans regarder sont préfixe. L'attribut olcSuffix va contenir:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=The Example Company
olcSuffix: {2}o=example,c=us

3. Également, en commançant depuis l'entrée originale, on pourrait effectuer ce changement:
delete: olcSuffix
olcSuffix: {2}o=The Example Company
-

Ici, le préfixe et la valeur doivent correspondre, sinon l'opération échoue:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=example,c=us

4. Ajouter une nouvelle valeur sans préfixe l'ajoute simplement:
add: olcSuffix
olcSuffix: o=example.org
-

L'attribut résultant est:
olcSuffix: {0}dc=example,dc=com
olcSuffix: {1}o=example.com
olcSuffix: {2}o=The Example Company
olcSuffix: {3}o=example,c=us
olcSuffix: {4}o=example.org

5. Ajouter une nouvelle valeur avec un préfixe l'insert à la position spécifiée:
add: olcSuffix
olcSuffix: {0}o=example.org
-

Le résultat est:
olcSuffix: {0}o=example.org
olcSuffix: {1}dc=example,dc=com
olcSuffix: {2}o=example.com
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

6. Modifier plusieurs valeur en une opération:
add: olcSuffix
olcSuffix: {0}ou=Dis,o=example.com
olcSuffix: {0}ou=Dat,o=example,com
-
delete: olcSuffix:
olcSuffix: {2}
olcSuffix: {1}
-

Le résultat est:
olcSuffix: {0}ou=Dat,o=example,com
olcSuffix: {1}dc=example,dc=com
olcSuffix: {2}o=example.com
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

7. Si les add et delete de l'exemple précédent étaient fait dans l'ordre inversé:
opposite order:
delete: olcSuffix:
olcSuffix: {2}
olcSuffix: {1}
-
add: olcSuffix
olcSuffix: {0}ou=Dis,o=example.com
olcSuffix: {0}ou=Dat,o=example,com
-

Le résultat serait:
olcSuffix: {0}ou=Dat,o=example,com
olcSuffix: {1}ou=Dis,o=example.com
olcSuffix: {2}o=example.org
olcSuffix: {3}o=The Example Company
olcSuffix: {4}o=example,c=us

   Noter que matcher avec un préfixe d'ordonnancement peut aussi être fait dans les opération compare et dans les filtres de recherche. Par exemple, le filtre "(olcSuffix={4})" va matcher toutes les entrées avec au moins 5 valeurs olcSuffix

Siblings ordonnées

   Les règles pour le siblings ordonnées sont basiquement les même que pour les values ordonnées, excepté qu'au lieu de travailler principalement avec des opération modify, les opérations intéressantes sont add, delete et modrdn

En donnant l'entrée suivante:
dn: olcDatabase={0}config,cn=config
olcDatabase: {0}config
objectClass: olcDatabaseConfig
olcSuffix: {0}cn=config
    
dn: olcDatabase={1}bdb,cn=config
olcDatabase: {1}bdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=com

1. Ajouter une nouvelle entrée sans préfixe d'ordonnancement:
dn: olcDatabase=hdb,cn=config
changetype: add
olcDatabase: hdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=org

Le résultat sera:
dn: olcDatabase={2}hdb,cn=config
olcDatabase: {2}hdb
objectClass: olcDatabaseConfig
olcSuffix: {0}dc=example,dc=org

2. En continuant avec ces 3 entrées, on peut ajouter une autre entrée avec un préfixe d'ordonnancement
dn: olcDatabase={1}ldif,cn=config
changetype: add
olcDatabase: {1}ldif
objectClass: olcDatabaseConfig
olcSuffix: {0}o=example.com

Ce qui nous donnera 4 entrées, dont les DN sont:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}ldif,cn=config
dn: olcDatabase={2}bdb,cn=config
dn: olcDatabase={3}hdb,cn=config

3. Fournir une requête modrdn va renommer plusieurs entrées:
dn: olcDatabase={1}ldif,cn=config
changetype: modrdn
newrdn: olcDatabase={99}ldif,cn=config
deleteoldrdn: 1

Les entrées résultante seront nommées:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}hdb,cn=config
dn: olcDatabase={3}ldif,cn=config

4. Une opération delete va également renommer les entrées restantes:
dn: olcDatabase={1}bdb,cn=config
changetype: delete

Donne:
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
dn: olcDatabase={2}ldif,cn=config

^
07 août 2015

htmlpdflatexmanmd




draft-findlay-ldap-groupofentries

draft-findlay-ldap-groupofentries

ObjectClass groupOfEntries

   Une classe objet groupOfNames existe depuis le standard X.521. Il a une définition identique dans LDAP (rfc4519). La classe est utilisée pour définir des entrées contenant des attributs de DN de membres, chaque valeur pointant vers une entrée qui représente un simple membre du groupe décris, ou vers une autre entrée de type groupOfNames.

   groupOfNames est une classe structurelle, donc elle est souvent la seulement utilisé dans la définition des objets groupes.

   L'expérience a montré que la définition des groupOfNames créé des difficultés en pratique. En particulier, le fait que 'member' est un attribut mandatoire signifie qu'il n'est pas possible de créer un groupe vide ou de supprimer le dernier membre d'un groupe. Cela impose certains artifices tels que créer un groupe membre de lui-même, ou d'ajouter un faux membre quand un groupe est créé. Cela rend la gestion des groupes plus complexe et sujet à erreurs. Les groupes sont communément utilisés pour contrôler l'accès aux ressources, dont les erreurs de gestion peuvent conduire à des risques de sécurité.

   Il n'y a pas de raison apparente pour que l'attribut 'member' soit mandatoire. Ce mémo décris une nouvelle classe appelée groupOfEntries qui est équivalent à groupOfNames à l'exception de l'attribut 'member' qui est optionnel.

Définition

La classe groupOfEntries est la base d'une entrée qui représente un jeu d'objets nommés incluant des informations liées à l'objectif ou la maintenance du jeu. Elle devrait être utilisée de préférence à groupOfNames:
( 1.2.826.0.1.3458854.2.1.1.1 NAME 'groupOfEntries' SUP top STRUCTURAL MUST ( cn ) MAY ( member $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

Effets sur d'autres documents

   Ce draft déprécie l'utilisation de groupOfNames dans la rfc4519 et le remplace par la classe groupOfEntries.
^
24 septembre 2014

htmlpdflatexmanmd




draft-haripriya-dynamicgroup-02

draft-haripriya-dynamicgroup-02

Groupes dynamiques pour LDAPv3

   Ce document décris les pré-requis, les sémantiques, les éléments du schéma, et les opérations nécessaires pour une fonctionnalité de groupe dynamique dans LDAP. Un groupe dynamique est définis ici comme un objet groupe avec une liste de dn qui est dynamiquement générée en utilisant un critère de recherche LDAP. La liste des membres dynamique peut ainsi être interrogée par une opération search ou compare, et peut également être utilisée pour trouver les groupes dont un objet est membre. Cette fonctionnalité élimine une grande quantité d'effort administratif pour maintenir l'appartenance à des groupes et les opérations basées sur les rôles dans une grande entreprise.

   Le schéma décris dans ce document définis 2 classes d'objet: 'groupOfNames', et 'groupOfUniqueNames', qui maintiennent une liste statique de DN dans leur attribut member et uniqueMember, respectivement, et sont typiquement utilisés pour décrire un groupe d'objets pour diverses fonctions. Les groupes dynamique sont des groupes normaux, mais permettent de spécifier des critères à utiliser pour évaluer les membres. Cela peut également être un supplément aux groupes statiques dans LDAP pour fournir de la flexibilité.

Pré-requis

   Les pré-requis suivants devraient être en place:

1. La création et l'administration des groupes dynamique devraient être fait en utilisant des opérations LDAP normales
2. Les applications doivent être capable d'utiliser les groupes dynamique de la même manière qu'avec les groupes statiques pour lister les membres et l'évaluation des membres
3. L'interrogation des membre d'un groupe dynamique devrait être fait en utilisant des opérations LDAP normales, et devraient être consistants.

Définition et sémantique du schéma

   Les classes des groupes dynamique sont définis par le schéma suivant:

ObjectClasses

dynamicGroup Cette objet structurel est utilisé pour créer un objet de groupe dynamique. Il est dérivé de groupOfNames
dynamicGroupOfUniqueNames Cette objet structurel est utilisé pour créer un objet de groupe dynamique dont la liste des membres sont maintenus dans un attribut uniqueMember. Il est dérivé de groupOfUniqueNames
dynamicGroupAux Cette classe auxiliaire est utilisée pour convertir un objet existant en un groupe dynamique. Il est dérivé de groupOfNames
dynamicGroupOfUniqueNamesAux Cette classe auxiliaire est utilisée pour convertir un objet existant en un groupe dynamique de membres uniques. Il est dérivé de groupOfUniqueNames

Attributes

memberQueryURL Décris les membres de la liste une utilisant un LDAPURL
excludedMember Utilisé pour exclure les entrées d'un groupe dynamique.
member il est surchargé lorsqu'utilisé avec un groupe dynamique. Il est utilisé pour lister les membres statiques d'un groupe dynamique. Si la même entrée est listée dans les attributs member et excludedMember, cet attribut a précédence
uniqueMember fonctionne de manière similaire à member. Il a également précédence sur excludedMember
dgIdentity Pour fournir des résultat consistants en traitant les critères de recherche, le serveur doit utiliser une simple identité d'autorisation. Si l'autorisation de l'identité est liée, la liste des membres va varier. Cette identité peut servir pour effectuer la recherche.

format LDAPURL

la notation BNF est listée ici pour référence
ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
dn = distinguishedName
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid
exvalue = LDAPString
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")

schéma


( ‹OID.TBD› NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( ‹OID.TBD› NAME 'excludedMember' SUP distinguishedName )
( 2.5.4.31 NAME 'member' SUP distinguishedName )
( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName )
( ‹OID.TBD› NAME 'identity' SUP distinguishedName SINGLE-VALUE )
    
( ‹OID.TBD› NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))
( ‹OID.TBD› NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))

Extension x-chain

   Une nouvelle extension est définie pour utilise memberQueryURL dans les groupes dynamiques, appelé 'x-chain'. Elle ne prend pas de valeur. Si présent, le serveur doit suivre toute référence de continuation de recherche sur d'autres serveurs lors de la recherche de membres.

Multiple valeurs

   memberQueryURL peut avoir plusieurs valeurs, et dans ce cas, les membres du groupe dynamique sera l'union de ces membres calculés.

Condition des membres

Un objet O est un membre d'un groupe dynamique G si et seulement si:
(( O is a value of the 'member' or 'uniqueMember' attribute of G)
OR
(( O is selected by the membership criteria specified in the 'memberQueryURL' attribute values of G)
AND
( O is not listed in the 'excludedMember' attribute of G) ))

   Si un membre M d'un groupe dynamique G apparaît être un groupe dynamique ou statique, les membres statiques et dynamique de M ne devraient pas être considérés membre de G. M est un membre de G cependant. La dernière condition est imposée parce que:

- les membre évalués récursivement peuvent dégrader les performances du serveur
- Des boucles peuvent se produire dans des situations particulières
- L'affirmation des membres dynamique ne peut pas être optimisée si le membership récursif est permis.

dgIdentity - implication de sécurité

   Parce que cet attribut donne indirectement, mais effectivement accès à tout le monde avec les opération read ou compare sur les attributs member ou uniqueMember avec les permissions suffisantes pour obtenir un résultat DN depuis memberQueryURL, les implémentation de serveur ne devraient pas autoriser de populer cet attribut avec le DN de n'importe quel objet qui n'est pas administré par l'identité faisant le changement de cet attribut.

Opérations sur les groupes dynamiques

   Les opérations suivantes devraient exposer la fonctionnalité de groupe dynamique. Cet opérations ne nécessitent pas de changement dans l'annuaire, lorsque le sujet est un objet dynamique, et tous les membres du groupe, incluant les membres dynamiques, auront les mêmes permissions sur l'entrée cible.

Lire un objet dynamique

   Quand les attributs member d'un groupe dynamique est listé par le client en utilisant une opération de recherche, les valeurs de member retournés devraient contenir les membres statiques et dynamiques. Cette fonctionnalité ne nécessite pas de changement au protocole, et les client n'ont pas à se préoccuper des groupes dynamiques pour exploiter cette fonctionnalité. Cette fonctionnalité est utile pour les client qui déterminent les accès privilégiés à une ressource par eux-même, en lisant les membres d'un objet groupe.

   Par exemple: les client qui lisent l'attribut member d'un objet groupe dynamique et tentent de supprimer des valeurs qui sont dynamiquent peuvent reçevoir une erreur spécifiant qu'un telle valeur n'existe pas.

le groupe dynamique cn=dg1,o=myorg avec les attributs suivant:
member: cn=admin,o=myorg
excludedMember: cn=guest,ou=finance,o=myorg
excludedMember: cn=robin,ou=finance,o=myorg
memberQueryURL: ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson)
S'il y a 5 organizationalPerson sous ou=finance,o=myorg avec les noms commun bob, alice, john, robin, et guest, la sortie d'une recherche LDAP sur cn=dg1,o=myorg, avec l'attribut listé contenant 'member' sera la suivante:
dn: cn=dg1,o=myorg
member: cn=admin,o=myorg
member: cn=bob,ou=finance,o=myorg
member: cn=alice,ou=finance,o=myorg
member: cn=john,ou=finance,o=myorg

Fonctionnalité Is Member Of

   L'opération de comparaison LDAP permet de découvrir si un DN est membre d'un groupe dynamique. De même, le serveur devrait produire des résultats consistants avec différentes identités d'autorisation lorsqu'il traite cette requête, tant que ces identités ont le même accès à l'attribut member ou uniqueMember. En utilisant les données de l'exemple plus haut, une comparaison dur cn=dg1,o=myorg, pour l'AVA member=cn=bob,ou=finance,o=myorg va résulter en une réponse compareTrue.

Membres statiques

   Parce qu'un groupe dynamique surcharge la sémantique des attributs member et uniqueMember, un mécanisme est nécessaire pour récupérer les valeurs statiques trouvées dans ces attributs dans un but de gestion. Une nouvelle option d'attribut est définie, appelée 'x-static' qui devrait être spécifié uniquement avec les attributs member et uniqueMember.

Exemples

1. La valeur memberQueryURL spécifie le critère d'appartenance pour une entrée de groupe dynamique comme "toutes les entrée inetOrgPerson qui ont leur attribut title à manager, et sont sous ou=hr,o=myorg":
memberQueryURL: ldap:///ou=hr,o=myorg??sub?(&(objectclass=inetorgperson)(title=manager))?x-chain
2. Cet valeur laisse l'utilisateur spécifier le critère d'appartenance pour une entrée de groupe dynamique comme "toutes les entrées sur le serveur local, qui a soit un compte unix ou appartient au département unix, et sous le conteneur engineering":
memberQueryURL: ldap:///ou=eng,o=myorg??sub?(|(objectclass=posixaccount)(department=unix))
3. Ces valeurs laissent l'utilisateur spécifier le critère de membership comme "toutes les entrées inetOrgPerson sur le serveur local, soit sous ou=eng,o=myorg soit sous ou=support,o=myorg"
memberQueryURL: ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson)
memberQueryURL: ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson)
^
15 septembre 2014

htmlpdflatexmanmd




draft-ietf-ldapext-acl-model-08

draft-ietf-ldapext-acl-model-08

Modèle de contrôle d'accès

   La capacité d'accéder aux informations de manière sûre via le réseau est nécessaire pour un déploiement réussi. Actuellement, LDAP ne définis pas de modèle de contrôle d'accès, mais il est nécessaire pour assurer un accès sécurisé conforme, réplication et gestion via des implémentations LDAP hétérogènes. L'objectif majeur est de fournir un modèle de contrôle d'accès simple, exploitable, implémentable et sécurisé pour l'accès au contenu des annuaires LDAP tout en fournissant la flexibilité appropriée pour les besoins de l'Internet et des environnements d'entreprise. Ce document définis le modèle, le schéma, et le contrôle LDAP.

   Ce modèle ne ( et ne peut pas ) spécifie pas pleinement le fonctionnement du modèle dans un environnement distribué ( ex: propager les informations de contrôle d'accès entre les serveurs ).

   Les mécanismes de contrôle d'accès évaluent les demandes pour accéder aux ressources protégées et prend des décisions d'autoriser ou non l'accès. Pour faire ces décisions, pour une demande, un mécanisme de contrôle d'accès doit évaluer des données de stratégie. Cette stratégie décris des caractéristiques de sécurité requises par le sujet et des règles qui gouvernent l'utilisation le l'objet cible.

   Aucun mécanisme n'est définis dans ce document pour stocker les informations de contrôle d'accès. Le modèle de contrôle d'accès définis:

- Les flux de protocole LDAP existant pour les opérations ldap sont utilisés pour manipuler les informations de contrôle d'accès. Ces même flux s'appliquent quand des ACI sont transmis durant la réplication. Un jeu de permission et leur sémantique est définis. Il y a une contrôle définis, GetEffectiveRights que les clients utilisent pour gérer et administrer les contrôles d'accès des serveurs.
- Les attributs et classes pour la portabilité des informations de contrôle d'accès aux applications. Les applications ldap portables devraient seulement utiliser ce modèe d'ACI. 2 attributs de contrôle d'accès ( entryACI et subtreeACI ) sont utilisé comme entrée à l'API ldap pour que les informations de contrôle d'accès puisse être adressés uniformément et indépendamment de la manière dont ces informations sont accédés et stockés dans le serveur. Une classe subentry ( ldapACISubEntry ) et un jeu d'attributs ( supportedAccessControlSchemes, accessControlSchemes ) sont utilisés pour identifier les mécanismes de contrôle d'accès supportés par un serveur.
- Un mécanisme pour contrôler l'accès aux ACI: les attributs opérationnel entryACI et subtreeACI sont utilisés pour contrôler les accès aux ACI.

   Les serveurs peuvent supporter plusieurs mécanismes de contrôle d'accès, mais doivent être capable de supporter le mécanisme LDAP dans le DIT scopé par les rootDSE ( tout de DIT du serveur ) et devrait être capable de supporter le mécanisme ldap dans une portion arbitraire (subtree) de ce DIT.

   L'attribut accessControlSchemes dans le ldapACISubEntry indique quels mécanisme de contrôle d'accès sont effectifs pour le scope de ce subentry. L'attribut supportedAccessControlSchemes dans le rootDSE indique quels mécanismes de contrôle d'accès sont supportés par le serveur. Ces mécanismes sont effectifs dans le DIT du serveur sauf s'il sont remplacés par un mécanisme définis dans un ldapACISubEntry quelque part dans le DIT.

   Changer les valeurs de supportedAccessControlSchemes ou accessControlSchemes change les mécanismes actifs pour le scope de ces attributs. Via l'utilisation de supportedAccessControlSchemes dans le rootDSE et accessControlSchemes dans ldapACISubEntry, il est possible de lancer plusieurs mécanismes dans le même subtree ou des subtree séparés.

Attributs de mécanisme de contrôle d'accès

   2 attributs sont définis pour identifier quels mécanismes sont supportés par un serveur donné et par un subtree donné: supportedAccessControlSchemes et accessControlSchemes.

Attribut RootDSE pour les mécanismes

   Le serveur utilise supportedAccessControlSchemes dans le rootDSE pour difuser les mécanismes supportés. Cet attribut est une liste d'OID, chacun identifiant un mécanisme de contrôle d'accès supporté par le serveur. Par défaut, il y a également les mécanismes actifs dans les subtrees.


(‹OID to be assigned›
    NAME 'supportedAccessControlSchemes'
    DESC list of access control mechanisms supported by this directory server
    EQUALITY objectIdentifierMatch
    SYNTAX OID
    USAGE dSAOperation
)

Mécanisme de contrôle d'accès subentry

   Un contexte de nommage doit fournir des informations sur les mécanismes de contrôle d'accès qui sont actifs pour la portion de l'espace de nom. Cette information est contenue dans un subentry ( ldapACISubEntry ). Il peut être utilisé pour définir le scope d'un mécanisme de contrôle d'accès. Les valeurs maintenus dans le rootDSE, sont les mécanismes actifs dans les subtrees sous le root à moins d'être substitué dans un ldapACISubEntry plus bas dans l'arborescence maintenue par le serveur. Le scope de cet ldapACISubEntry est à la fin du subtree maintenu par ce serveur ou jusqu'à ce qu'un autre ldapACISubEntry soit rencontré. la classe ldapACISubEntry est définis:


( ‹OID to be assigned›
    NAME 'ldapACISubEntry'
    DESC 'LDAP ACI Subentry class'
    SUP ldapSubEntry STRUCTURAL
    MUST ( accessControlSchemes )
)

   accessControlSchemes doit être dans chaque ldapACISubEntry associé avec un contexte de nommage dont le mécanisme de contrôle d'accès est différent des contextes de nommage adjacents supportés par ce serveur. accessControlSchemes liste les valeurs qui définissent les mécanismes de contrôle d'accès effectifs pour le scope de ce subentry. Bien qu'en général cet attribut définis un seul mécanisme, il peut en contenir plusieurs.


(‹OID to be assigned›
    NAME 'accessControlSchemes'
    DESC list of access control mechanisms supported in this subtree
    EQUALITY objectIdentifierMatch
    SYNTAX OID
    USAGE dSAOperation
)

Définitions

La syntaxe et attributs pour les informations de contrôle d'accès, entryACI et subtreeACI, sont définis:
(‹OID-aci-syntax›
    DESC 'attribute syntax for LDAP access control information'
)
    
(‹OID to be assigned›
    NAME 'entryACI'
    DESC 'ldap access control information, scope of entry'
    EQUALITY directoryComponentsMatch
    SYNTAX ‹OID-aci-syntax›
    USAGE directoryOperation
)
    
(‹OID to be assigned›
    NAME 'subtreeACI'
    DESC 'ldap access control information, scope of subtree'
    EQUALITY directoryComponentsMatch
    SYNTAX ‹OID-aci-syntax›
    USAGE directoryOperation
)

   Le but de ces définitions d'attribut est de définir un format commun et d'avoir une séparation des responsabilités pour permettre à différentes personnes d'administrer des différents types d'attributs. Tout serveur LDAP devrait être capable de traduire l'attribut définis en requêtes significatives. Chaque serveur devrait être capable de comprendre l'attribut; Il ne devrait pas y avoir d'ambiguïté dans aucune partie de la syntaxe.

   Alors que le but final est d'avoir un modèle commun entre différentes implémentations de serveur LDAP, les définitions d'attribut seul n'auront pas forcement un traitement d'ACL identique entre les serveurs. Les règles d'applicabilité et de précédence pour prendre les décisions d'accès sont définis plus bas dans cette section. Les sémantiques sur la manière dont un serveur interprète da syntaxe ACI sont définis plus bas dans ce document. Additionnellement, tandis que le serveur doit reconnaître et agir sur l'attribut quand il reçoit de flux, il n'y a aucun requis pour le serveur pour stocker physiquement ces attributs sous cette forme.

   Les définitions d'attribut maintiennent une hypothèse selon laquelle le serveur de réception supporte l'héritage d'ACI dans le modèle de sécurité. Si le serveur ne supporte pas l'héritage, le serveur de réception doit étendre toute information d'héritage basé dur le flag de scope.

   Les attributs sont définis pour que les ACI puissent être adressés dans un serveur d'une manière indépendante de l'implémentation. Ces attributs sont utilisés dans les API LDAP, dans la sortie LDIF de l'ACI et en transfert d'ACI durant la réplication. Ces attributs peuvent être requêtés ou définis dans tous les objets de l'annuaire. Les définitions et notation ABNF sont donnés ci-dessous.

Représentation de chaîne UTF-8

L'encodage des chaînes LDAP des valeur de la syntaxe ACI est décrite:
ACI = rights "#" attr "#" generalSubject
    
rights = (("grant:" / "deny:") permissions) /
    ("grant:" permissions ";deny:" permissions)
    
permissions = 1*(permission)
permission = "a" / ; add
    "d" / ; delete
    "e" / ; export
    "i" / ; import
    "n" / ; renameDN
    "b" / ; browseDN
    "v" / ; view (entry level read permission)
    "t" / ; returnDN
    "r" / ; read
    "s" / ; search filter
    "p" / ; search filter (presence only)
    "w" / ; write (mod-add)
    "o" / ; obliterate (mod-del)
    "c" / ; compare
    "m" / ; make
    "u" / ; unveil (disclose on error permission)
    "g" ; getEffectiveRights
    
; les permissions r, w, o, s, p, c, m fonctionnent sur les attributes
; les permissions a, d, e, i, n, b, v, t, u, g fonctionnent sur les entrées
; les permissions pour les attributs et permissions pour les entrées ne sont jamais trouvés dans un simple ACI
    
attr = "[all]" / "[entry]" / (attribute *("," attribute))
    
attribute = AttributeDescription
    
generalSubject = context pureSubject
    
context = "authnLevel:" authnLevel ":"
    
pureSubject = anySubject / machineSubject / idBasedSubject
    
anySubject = "public:"
    
machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) /
    "dns:" partialdomainname *( "," partialdomainname )
    
partialdomainname = [ "*." ] domainname
    
idBasedSubject = thisSubject /
    oneSubject /
    setOfSubjects
    
thisSubject = "this:"
oneSubject = ( "authzId-" authzId )
setOfSubjects = ( "role:" dn ) /
    ( "group:" dn ) /
    ( "subtree:" dn )
    
authnLevel = "none" /
    "weak" /
    "limited" /
    "strong"
    
authzId = dnAuthzId / uAuthzId
    
; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
    
dn = utf8string
    
; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; syntax unspecified
; A utf8string is defined to be the UTF-8 encoding of
; one or more ISO 10646 characters.
    
ipAddress = IPv6address
    
; following is excerpted from [IPV6]
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
    
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
    
ipAddressRange = ipAddress [ HYPHEN ipAddress ] ; IPv6 address range
    
domainname = domaincomponent *( "." domaincomponent )
    
OUTER = ALPHA / DIGIT
INNER = ALPHA / DIGIT / HYPHEN
HYPHEN = %x2D
domaincomponent = OUTER [ *61( INNER ) OUTER ]

   Noter que les virgules suivant "public" et "this" existent seulement pour simplifier le parsing des chaînes. Si on tente d'ajouter un ACI avec un authz qui n'est pas supporté, le serveur doit rejeter cette valeur entryACI ou subEntryACI. Voir la section "Examples d'ACI" pour les examples de représentation de chaîne.

Représentation binaire


LDAP-Access-Control-Model
DEFINITIONS EXTENSIBILITY IMPLIED ::=
BEGIN
    
IMPORTS
    AttributeType, DistinguishedName, CONTEXT
        FROM InformationFramework; -- from [X501]
    
ACI ::= SEQUENCE {
    rights SEQUENCE {
        grant Permissions OPTIONAL,
        deny [1] Permissions OPTIONAL }
            (WITH COMPONENTS { ..., grant PRESENT } |
            WITH COMPONENTS { ..., deny PRESENT }),
            -- at least one of grant or deny must be present --
    attr CHOICE {
        all NULL,
        entry [1] NULL,
        attributes SET (1..MAX) OF AttributeTypeAndOptions },
    authnLevel ::= ENUMERATED {
        none (0),
        weak (1),
        limited (2),
        strong (3)}
    subject GeneralSubject
}


--Une représentation X.500 pour une description d'attribut LDAP
AttributeTypeAndOptions ::= SEQUENCE {
    type AttributeType,
    type-name UTF8String OPTIONAL,
options SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL
}
GeneralSubject ::= CHOICE {
    anySubject NULL,
    machineSubject [1] MachineSubject,
    idBasedSubject [2] IDBasedSubject
}
    
MachineSubject ::= CHOICE {
    ipAddress IPAddress,
    dns [1] DomainName
}
    
IPAddress ::= UTF8String
    
DomainName ::= UTF8String
    
IDBasedSubject ::= CHOICE {
    thisSubject NULL,
    oneSubject [1] OneSubject,
    setOfSubjects [2] SetOfSubjects
}
    
OneSubject ::= CHOICE {
    dn DistinguishedName,
    user UTF8String
}
    
SetOfSubjects ::= CHOICE {
    role DistinguishedName,
    group [1] DistinguishedName,
    subtree [2] DistinguishedName
}


Permissions ::= BIT STRING {
    add (0),
    delete (1),
    export (2),
    import (3),
renameDN (4),
    browseDN (5),
    viewEntry (6),
    returnDN (7),
    read (8),
    search (9),
    searchPresence (10),
    write (11),
    obliterate (12),
    compare (13),
    make (14),
    unveil (15),
    getEffectiveRights (16)
    (CONSTRAINED BY { -- at least one bit must be set -- })
}

   Les permissions read, write, obliterate, search, searchPresence, compare, make fonctionnent sur les permissions d'attributs. add, delete, export, import, renameDN, browseDN, viewEntry, returnDN, unveil, getEffectiveRights fonctionnent sur les entrées.

Les composants des attributs entryACI et subtreeACI

   Cette section définis les composants qui comprennent les attributs d'informations de contrôle d'accès, entryACI et subtreeACI. Les information dans entryACI s'appliquent seulement à l'entrée dans laquelle elle est contenue. Les informations dans subtreeACI s'appliquent à chaque entrée sous le subtree sauf si un entryACI spécifique ou un subtreeACI est rencontré. L'utilisation des ACI prescritives et le scoping via l'utilisation d'un ldapACISubEntry n'est pas décris dans ce document.

Droits d'accès et permissions

   Les droits d'accès peuvent être appliqués à tout un object ou à des attributs de l'objet. L'accès peut être donné ou refusé. Une ou les deux actions "grant" | "deny" peuvent être utilisé en créant ou mettant à jour un entryACI et subtreeACI.

Permissions que s'appliquent aux attributs:
r Read - Lire les valeurs de l'attribut
w Write - Modifier-Ajouter des valeurs
o Obliterate - Modifier-Suprimer des valeurs
s Search - Rechercher des entrées avec les attributs spécifiés
p SearchPresence - Filtres de présence uniquement
c Compare - Comparer des attributs
m Make - Créer des attributs sous une nouvelle entrée sous cette entrée

Permissions que s'appliquent aux entrées:
a Add - Ajouter une entrée sous cette entrée
d Delete - Supprimer cette entrée
e Export - Exporter l'entrée et ses subordonnées à un nouvel emplacement
i Import - Importer une entrée et ses subordonnées sous cette entrée depuis un autre emplacement
n RenameDN - Renommer un DN de l'entrée
b BrowseDN - Parcourir un DN de l'entrée
v ViewEntry - Une permission de lire au niveau de l'entrée
t ReturnDN - Permet au DN de l'entrée d'être inclus dans le résultat de l'opération.
u Unveil - Permission discloseOnError
g GetEffectiveRights - permet de lire les Permissions effectives

Attributs

   Un attribut décrit un nom d'attribut sous la forme d'un OID pour cet ‹attr›. Si l'OID réfère à un attribut non définis dans le schéma du serveur, le serveur devrait reporter une erreur. L'utilisation de "[entry]" ou "[all]" aide à focaliser sur les permissions de l'entrée ou de l'attribut facilement.

   "[entry]" signifie que les permissions s'appliquent à tout l'objet. Peut être utilisé par exemple pour supprimer ou ajouter un objet. Quand utilisé dans un subtreeACI, les permissions spécifiées s'appliquent à chaque entrée dans le subtree.

   "[all]" signifie que le jeu de permissions d'applique à tous les attributs de l'entrée. Quand utilisé dans un subtreeACI, "[all]" s'applique à tous les attributs de chaque entrée dans le subtree. Si le mot clé "[all]" et un autre attribut sont spécifiés dans une ACI, le jeu de permission de plus spécifique pour l'attribut écrase le jeu de permission le moins spécifique pour "[all]".

Sujets et authentification associé

Les sujets suivants sont définis et doivent être supportés:
- authzId
- group, définis comme DN d'une entrée groupOfNames ou groupOfUniqueNames
- role, affirme la position de l'organisation d'un sujet et le droit d'un sujet à effectuer les opérations nécessaires à cette position dans l'organisation. Cette implémentation définis comment l'association entrée un authorization id et le dn du role est faite
- subtree, définis comme DN d'un nœud non-terminal dans le DIT
- ipAddress, au format texte IPv6
- dnsName, un nom de domaine ou un nom de domaine wildcard
- public, définis comme accès publique
- this, définis comme l'utilisateur dont le nom match l'entrée accédé

   D'autres parties peuvent définir d'autres sujets. Il est de la responsabilité de ces parties de fournir la définition. Ajouter de nouveaux sujets peut inhiber d'interopérabilité.

   Un sujet peut être qualifié par le niveau d'authentification requis pour accéder à un attribut ou une entrée donnée. authnLevel définis le niveau d'authentification minimum du demandeur requis pour un ACI donné. Les niveaux d'authentification définis, dans l'ordre croissants d'authentification sont:

none Aucun nom et aucun mot de passe, ou un nom mais pas de mot de passe.
weak Les mécanismes d'authentification qui sont considéré vulnérables aux attaques passives et actives. Ex: l'authentification simple.
limited Les mécanismes d'authentification qui sont protégés contre les attaques passives mais pas les attaques actives. Ex: DIGEST-MD5
strong Les mécanismes d'authentification qui sont protégés contre les attaques passives et actives. Ex: Kerberos.

   Le authnLevel s'applique à un sujet comme suit:

- Si l'ACI est donné, authnLevel s'applique si le sujet est authentifié à ce niveau ou plus
- Si l'ACI est refusé, authnLevel s'applique à ce sujet s'il est authentifié à ce niveau et à tous les autres sujets authentifiés avec les niveaux inférieurs.

   Le niveau d'authentification est toujours spécifié dans un ACI. Pour grant, celà signifie que l'accès est donné si vous prouvez votre authentification via un mécanisme d'authentification fort, tel que la signature numérique. Pour deny, cela signifie que l'accès est refusé si vous êtes Mr. X et que vous le prouvez avec une signature numérique. Si vous n'êtes pas Mr. X votre accès n'est pas refusé seulement si vous pouvez le prouver avec une signature numérique. En d'autres termes, toute personne qui s'authentifie avec une signature numérique gagne l'accès excepté Mr. X.

   Une catégorisation recommandée des mécanismes d'authentification par niveau peut être offert séparément. Pour chaque mécanisme catégorisé dans les recommandations, les implémentations ne devraient pas assigner un niveau d'authentification supérieur, mais peuvent assigner un niveau d'authentification inférieurs. Pour les mécanismes non couverts par les recommandations, l'implémentation devrait spécifier un niveau conservateur. Les implémentations devraient fournir un moyen pour les administrateurs de désactiver et/ou abaisser le niveau d'authentification associé avec un mécanisme.

   2 sujets intéressant non explicitement inclus, mais peuvent être composés en utilisant le sujet et authnLevel associé avec un mécanisme.

anonymous authnLevel=none + anySubject(public)
authenticated authnLevel=weak + anySubject(public)

Décision de contrôle d'accès

   Le but ultime du modèle de contrôle d'accès est de définir la manière dans laquel un serveur LDAP détermine une décision de contrôle d'accès pour une opération LDAP donnée. En fait, un demandeur peut nécessiter de nombreuses permissions individuelles pour être autorisé à effectuer l'opération LDAP. Dans cette section on introduit les concepts et algorithmes qui permettent au serveur de décider si un demandeur à une permission individuelle sur un ressource individuelle. Les concepts nécessaires sont premièrement, les paramètres qui doivent être fournis dans l'ordre pour l'algorithme de décision de contrôle d'accès. pour déterminer si l'accès est permis ou non.

   Deuxièmement, on définis précisément quand un ACI donné sera impliqué dans une décision de contrôle d'accès. Troisièmement, ce modèle définis certaines règles de précédence que l'algorithme utilisant lorsqu'il a plus d'un ACI. Finalement, on peut définir l'algorithme de décision de contrôle d'accès qui va déterminer la décision d'accès.

Les paramètres de l'algorithme

   L'algorithme de décision répond à la question "est-ce que le demandeur a la permission spécifiée sur la ressource spécifée?". La ressource peut être une entrée ou un attribut dans une entrée, donc on caractérise la ressource comme ceci: targetEntry, targetAttribute OPTIONAL.

   Le demandeur est identifié principalement par son authorization ID ( qui peut être omis si le demandeur est anonyme ), mais inclus également les informations de contexte sur le demandeur pour qu'il soit représenté comme ceci: authzId OPTIONAL, ipAddress, dnsName, authnLevel.

   La permission est une des permissions définis par le modèle. Donc les paramètres de l'algorithme de décision de contrôle d'accès, que nous appelons les paramètres de décision sont:

ressource (targetEntry, targetAttribute OPTIONAL)
permission permissionParameter
requestorSubject (authzId OPTIONAL, ipAddress, dnsName, authnLevel)

   Si permissionParameter est un paramètre de niveau attribut, alors targetAttribute doit être spécifié; s'il c'est une permission de niveau entrée, targetAttribute est ignoré.

  La sortie est soit "Access Allowed" soit "Access Denied".

Règles d'applicabilité

   Les règles d'applicabilité définissent si une valeur d'ACI donné, ou des portions, s'applique à certains paramètres de décision.

Règles d'applicabilité pour le type de scope

   Ces règles détermine si un ACI spécifique d'applique à la partie targetEntry des paramètres de décision.

- Si l'ACI en question est un entryACI, alors l'ACI s'applique à la ressource si l'ACI est un attribut de l'entrée targetEntry.
- Si l'ACI en question est un subtreeACI, alors l'ACI s'applique à la ressource si targetEntry fait partie du subtree définis par l'entrée contenant l'ACI.

Règles d'applicabilité pour les permissions

- Si permissionParameter est une permission au niveau entrée, alors l'ACI en question s'applique si permissionParameter est mentionné dans la liste des permissions de l'ACI.
- Si permissionParameter est une permission au niveau attribut, alors l'ACI en question s'applique si permissionParameter est mentionné dans la liste des permissions et la liste des attributs de l'ACI s'applique à l'attribut cible par "règle d'applicabilité pour les attributs".
- Noter que pour un ACI qui contient à la fois des listes grant est deny, la liste de permission grant peut ne pas être disponible pou cette règle d'applicabilité (voir plus bas )

Règles d'applicabilité pour les attributs

   Si un attribut n'est pas spécifié comme partie de la ressource, alors cette règle ne s'applique pas. Si un attribut est spécifié, alors l'ACI en question s'applique si sa liste d'attribut est [all] ou si targetAttribute est explicitement mentionné dans la liste d'attribut de l'ACI.

   Dans le cas où targetAttribute est un type d'attribut avec des options (ex: sn;lang-en;lang-uk), il est applicable si la liste d'attribut de l'ACI mentionne une forme moins spécifique de targetAttribute. Par exemple, si la liste contient "sn;lang-en", alors la liste s'applique à l'attribut "sn;lang-en;lang-uk", mais pas l'attribut "sn".

Règles d'applicabilité pour les sujets

   Appelons la portion sujet de l'ACI en question aciSubject. Pour déterminer si aciSubject s'applique au requestorSubject ou applique les règles suivantes:

1. L'ACI en question est un ACI grant. Alors l'ACI s'applique si les portions context et pureSubject de aciSubject s'applique, comme définis dans les règles d'applicabilité pour le contexte et les règles d'applicabilité pour pureSubject.
2. L'ACI en question est un ACI deny. Il y a 3 possibilité:

        a. La partie pureSubject s'applique ( en accord avec les règles d'applicabilité pour pureSubject ). Donc l'ACI s'applique au requestorSubject.
        b. La partie pureSubject ne s'applique pas. Donc l'ACI s'applique à tout requestorSubject avec un authnLevel inférieurs au authnLevel de l'ACI.
        c. Sinon l'ACI ne s'applique pas.

3. L'ACI en question est à la fois grant est deny. Il y à 3 possibilités:

        a. aciSubject s'applique quand évalué comme ACI grant. Les permissions grant et deny de l'ACI sont dispoible pour les règles d'applicabilité pour les attributs et les permissions.
        b. aciSubject ne s'applique pas comme ACI grant mais s'applique comme ACI deny. Les permissions deny de l'ACI sont disponibles pour les règles d'applicabilité pour les attributs et les permissions.
        c. aciSubject ne s'applique pas quand évalué soit à grant ou deny. L'ACI ne s'applique pas au requestorSubject.

   Note: le mode deny avec authnLevel sert d'explication. Dans le cas où un ACI refuse d'accès à un sujet donné avec un authnLevel donné, alors naturellement il va refuser l'accès à ce subjet authentifié à un authnLevel ou supérieur. Similairement, un autre utilisateur authentifié au authnLevel ou supérieur, pour lequel la partie pureSubject ne s'applique pas, ne sera pas refusé les droits par cet ACI.

   Le cas intéressant est un utilisateur authentifié à un niveau inférieur à authnLevel. Pour un tel utilisateur l'ACM considère que cet utilisateur n'a pas été prouvé au système, à un niveau de confiance suffisant, la partie pureSubject ne s'applique pas à lui, donc par sécurité, il se verra refuser les droits.

   Donc si vous refusez l'accès à un authzId particulier avec authnLevel à "none", cet authzId aura l'accès refusé à tous les niveaux d'authentification, mais n'affectera pas d'autre demandeurs. D'une autre manière, si vous refusez l'accès à un authzId particulier avec un authnLevel "strong", celà va refuser l'accès à cet utilisateur quand il est authentifié "fort" et refusera l'accès à tout utilisateur authentifié avec des niveau d'authentification inférieurs.

Règles d'applicabilité pour pureSubject

   Si aciSubject est de type anySubject, alors il s'applique au requestorSubject.

   Si aciSubject est de type machineSubject, alors si ipAddress ou le nom dns de requestorSubject matche l'ipAddress ou la plage de nom dns dans aciSubject, alors l'ACI s'applique au requestorSubject si ce n'est pas un ACI deny ou la partie deny d'un ACI grant/deny. Un ACI grant ne s'applique jamais si le sujet est ipAddress: ou dns:. La note à la fin de "Précédence des sujets dans un scope" explique le raisonnement derrière cette règle.

Règles d'applicabilité pour le contexte

   Le contexte d'un aciSubject s'applique au requestorSubject si authnLevel du requestorSubject est supérieur ou égal au authLevel spécifié dans la partie contexte de aciSubject.

Règles d'applicabilité pour idBasedSubject

   si idBasedSubject est de type thisSubject, alors il s'applique au requestorSubject si authzId du requestorSubject est de type "dn" et est égal au DN de la ressource.

   Si idBasedSubject est de type oneSubject, alors il s'applique au requestorSubject si authzId du requestorSubject est égal au authzId spécifié dans aciSubject.

   Si idBasedSubject est de type setOfSubjects, alors il s'applique au requestorSubject si authzId du requestorSubject est définis dans le set spécifié dans aciSubject ( ex: est dans ce groupe, rôle ou subtree ). Le "Précédence des sujets dans un scope" inclus les règles pour déterminer le membership dans un setOfSubjects.

Règles de précédence

   Les règles de précédences permetten à l'algorithme de décision de contrôle d'accès de déterminer quelles valeurs d'ACI ont précédence sur les autres.

Précédence des type de scope

1. Entry
2. Subtree

Précédence de position dans le DIT

   Pour un DN sujet donné (incluant le niveau d'authentification) et un DN cible, subtreeACI plus bas dans l'arborescence prend précédence sur ceux plus haut.

Précédence de sujets dans un scope

1. ipAddress ou dns dans un ACI deny pour la partie deny d'un ACI grant/deny
2. authzId dn ( authzId-dn: ) ou authzId userid ( authzId-u: )
3. this
4. role

           Si le DN d'un rôle ou d'un groupe apparaît dans un rôle (ex: qui apparaît comme valeur de roleOccupant dans un organizationalRole), il est étendu récursivement. Pour déterminer la précédence, la collection de noms résultante de l'expansion est considéré venir d'un rôle sans regarder la source originale.

5. group

           Si le DN d'un rôle ou d'un groupe apparaît dans un groupe, il est étendu récursivement. Pour déterminer la précédence, la collection de noms résultante de l'expansion est considéré venir d'un groupe sans regarder la source originale.

6. subtree

           Les subtrees peuvent contenir les groupes et/ou des rôles. Ils peuvent être récursivement étendus. Pour déterminer la précédence, les membres des groupes ou occupants de rôles qui s'appliquent parce que le groupe ou le rôle est contenus dans un subtree sont considérés venir du subtree sans regarder la source originale.

7. public

           La précédence de idAddress et des noms dns sont traités spécialement, et dépendent du type d'ACI. Typiquement les situations sont:

                - Si une ACL dit d'autoriser sur la base de l'adresse IP mais refuse sur la base de certains autres attributs, alors, la méthode qu'on veut est "deny". ex: l'utilisateur est refusé, sans regarder où il réside.
                - Si une ACL des de refuser sur la base d'adresse IP mais autorise sur la base d'autres attributs, la méthode qu'on veut est également "deny". ex: L'utilisateur est accepté, mais pas d'où il réside.

   En plus, un grant à un ipAddress sans autre ACI applicable est très dangereux d'un point de vue sécuritaire, vu que cela donne accès a tout utilisateur qui a accès à cet ordinateur avec cette adresse donnée. Ainsi les sujets ipAddress et dns peuvent être utilisés seulement pour refuser les permissions, pas les accepter.

Spécifications de précédence d'attribut

   Les contrôles d'accès spécifiant les attributs "[all]" ont une précédence plus faible que les listes spécifiques.

Précédence de grant/deny

   Deny prend précédence sur grant.

Default

   Deny est le défaut quand il n'y a pas d'information de contrôle d'accès ou quand l'évaluation des informations de contrôle d'accès ne fournis aucun résultat qui autorise d'accès.

Algorithme de décision de contrôle d'accès

   L'algorithme prend en entrée les paramètres de décision définis plus haut et produit une décision grant ou deny. Dans le cas où on est intéressé dans le jeu de permission pour un jeu d'entrée et d'attributs (comme dans le cas de l'évaluation des droits effectifs), alors on doit appliquer l'algorithme pour chaque entrée/attribut et paire de permission qui nous intéresse. Naturellement les implémenteurs sont libre d'implémenter un algorithme qui produis la même décision sur une entrée et les valeurs d'ACI dans les DIT.

   L'algorithme a 2 phases. D'abord, toutes les valeurs d'ACI potentiellement applicable sont triés en une liste ordonnée de jeu de valeurs d'ACI de la même précédence. Puis cette liste est scannée dans l'ordre pour trouver le jeu d'ACI qui va déterminer la décision d'accès.

   Phase 1: Ordonner les valeurs d'ACI potentiellement applicables

1. Détermine toutes les valeurs entryACI et subtreeACI qui s'appliquent au targetEntry, en accord avec les règles d'applicabilité pour les type de scope.
2. Trie ces ACI en une liste de jeux d'ACI de précédence égales, en accord avec les règles de précédence du type de scope. et la précédence de position dans le DIT.
3. Détermine quelles valeurs d'ACI collectée de l'étape 1 s'appliquent au requestorSubject en utilisant les règles d'applicabilité pour les sujets. Toutes les valeurs d'ACI qui ne s'appliquent pas à ce sujet sont éliminés.
4. La liste de jeux est triée en accord avec le type de sujet depuis les règles de précédence des sujets dans un scope.
5. Maintenant on split la liste en 2 listes conservant le même ordre relatif, une liste qui réfère au permissions au niveau entrée, et l'autre au niveau attributs.
6. Chaque jeu dans la liste de niveau attribut et ensuite divisée en une liste de jeux de précédence égale en accord avec la spécification de précédence d'attribut.

   Note: à ce point on a 2 listes de jeux de valeurs d'ACI. Cette liste a été triée en accord avec les scope, la position, le sujet et ( pour la liste au niveau attribut ) les règles de spécification de précédence d'attribut.

   Phase2: Scanne les liste pour déterminer la décision d'accès:

   1. Si permissionParameter est une permission au niveau entrée ( donc le champ optionnel targetAttribute n'est pas spécifié ), scanne la liste de niveau entrée dans l'ordre. Le premier jeu dans la liste qui contient un ACI qui s'applique au permissionParameter détermine la décision d'accès si un ACI dans le jeu autorise permissionParameter et aucun autre le refuse, alors l'accès est donné, sinon l'accès est refusé.

   2. Si permissionParameter est une permission au niveau attribut, scanne la liste des jeux au niveau attribut dans l'ordre. Le premier jeu dans la liste qui contient un ACI qui s'applique au permissionParameter et s'applique à targetAttribute détermine la décision d'accès. Si un ACI dans le jeu autorise permissionParameter et aucun autre le refuse, l'accès est donné, sinon l'accès est refusé.

Exemple de précédence/héritage de décision d'accès

L'exemple dans cette section réfère à l'arborescence suivante:
___________dc=com
_____________|
____+--------+---------------+
____|________________________|
dc=tivoli__________________dc=sun
____|________________________|
_cn=ellen__________________cn=rob

   L'ACI à dc=com:

1. subtreeACI:grant:rsc#[all]#authnLevel:none:public:
2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary#authnLevel:none:public:
3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public:
4. subtreeACI:grant:rscmow#[all]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com

   L'ACI à dc=tivoli,dc=com:

6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
7. subtreeACI:deny:einad#[entry]#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com

   L'ACI à cn=ellen,dc=tivoli,dc=com:

8. entryACI:grant:wo#[all]#authnLevel:strong:authz-ID-dn:cn=ellen,dc=tivoli,dc=com
9. entryACI:deny:wo#entryACI,subtreeACI,salary#authnLevel:strong:authz-ID-dn:cn=ellen,dc=tivoli,dc=com

Exemple 1

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "w"

Phase 1: Touver tous les ACI applicables dans l'applicabilité des types de scope: {1, 2, 3, 4, 5, 6, 7, 8, 9}
Trier par précédence de type de scope et précédence de position dans le DIT: {8, 9}, {6, 7}, {1, 2, 3, 4, 5}
Détermine quels ACI sont applicable basé sur le sujet: {6, 7}, {1, 2, 3, 4, 5}
Trier par précédence de sujets dans le scope: {6, 7}, {4, 5}, {1, 2, 3}
Séparer les permissions applicables à l'entrée et ceux applicable aux attributs: Entry: {7}, {5}, {3}, Attr: {6}, {4}, {1, 2}
Trier les permissions applicable aux attributs par précédence de spécification d'attribut: Entry: {7}, {5}, {3}, Attr: {6}, {4}, {2}, {1}
Phase 2: Vu que "w" est une permission attribut, recherche dans la liste Attr l'ACI 6 dans la première sous-liste mentionnant "w" et salary (via [all]) pour définir l'accès, qui est deny.

Exemple 2

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "w"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Pour l'ACI 6 dans le premier jeu, qui matchait le sujet par la portion deny et limitée à ‹ strong, les permissions disponibles sont "mow". Donc, cet ACI applique à "w" et salary (via [all]) et l'accès est deny.

Exemple 3

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", salary)
permission: "r"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Vu que la portion grant de l'ACI 6 n'est pas active, le premier jeu qui contient un ACI qui s'applique à "r" et salary est {2}. Comme 2 deny l'accès, l'accès est refusé.

Exemple 4

subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
resource: ("cn=ellen,dc=tivoli,dc=com", cn)
permission: "r"

Phase 1: Les ACI sont ordonnés dans les jeux suivant sont les sujets matchent le sujet: Entry: {7}, {3}, Attr: {6}, {2}, {1}
Phase 2: Vu que la portion grant de l'ACI 6 n'est pas active, le premier jeu qui contient un ACI qui s'applique à "r" et cn est {1}. Vu que 1 grant l'accès, l'accès est donné.

Permissions requises pour chaque opération LDAP

   Cette section définis les permissions requises pour chaque opération LDAP. Même si ces requis sont satisfaits, le serveur peut refuser l'opération dû à d'autres considérations de sécurité spécifique à l'implémentation. Par exemple, un serveur peut refuser de modifier une entrée parce que la base où réside l'entrée est en lecture seule. Un autre exemple peut être qui le contrôle d'accès LDAP a été spécifié sur l'attribut userPassword, mais un serveur peut refuser les modifications dû à certaines gouvernances de stratégie d'accès spécifique aux mots de passe.

   Ici, on spécifie les droits requis par un utilisateur en effectuant un opération LDAP en termes de permissions LDAP spécifiés plus haut. Rappelons que les permissions "a, d, e, i, n, b, v, t, u" s'appliquent aux entrées et les permissions "r, s, p, w, o, c, m, g" s'appliquent aux attributs dans les entrées.

   Les permissions requises pour les opérations étendues LDAP et les contrôles LDAP devraient être définis avec leurs spécification. Ces requis peuvent être définis en terme de ce modèle, par exemple en nécessitant une des permissions existante sur certaines entrées ou attributs particulier. Cette version du modèle de contrôle d'accès n'offre pas de mécanisme pour étendre le jeu de permissions ou la syntaxe d'ACI pour convenir aux opérations étendues ou aux contrôles.

   Pour la suite, on assume que l'authorization ID de l'utilisateur faisant l'opération est authzId.

Opération Bind

   Ce modèle ne nécessite pas de permission pour permettre de traiter une opération bind.
Rappelons que les paramètres de l'opération search sont:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
    baseObject LDAPDN,
    scope ENUMERATED {
        baseObject (0),
        singleLevel (1),
        wholeSubtree (2) },
    derefAliases ENUMERATED {
        neverDerefAliases (0),
        derefInSearching (1),
        derefFindingBaseObj (2),
        derefAlways (3) },
    sizeLimit INTEGER (0 .. maxInt),
    timeLimit INTEGER (0 .. maxInt),
    typesOnly BOOLEAN,
    filter Filter,
    attributes AttributeDescriptionList }

   Supposons qu'un serveur traite une recherche de l'utilisateur authzId avec les paramètres comme précédent et traite l'entrée avec le dn candidateDN pour décider s'il peut le retourner ou non, alors les permissions requises par authzId qui doivent être évaluées sont les suivantes:

1. Permission "b" sur l'entrée candidateDN si l'entrée est dans le scope de recherche mais n'est pas l'entrée de base. Si cette permission n'est pas donnée alors le dn candidateDN ne doit pas être retourné ni un type d'attribut ni une valeur d'attribut de cette entrée. Note: la permission b est incluse pour permettre différents droits de découverte et de parcours à être assigné à différentes classes d'utilisateurs.
2. Permission "v" sur l'entrée candidateDN. Si cette permission n'est pas donnée alors de dn candidateDN ne doit pas être retourné, ni un type d'attribut ni une valeur d'attribut de cette entrée. La permission v est une permission de lecture au niveau de l'entrée.
3. Permission "p" ou "s" pour chaque attribut apparaissant dans un filtre de recherche de test de présence. "s" est requis sur les attributs apparaissant dans les tests de non-présence ( equalityMatch, substrings, greaterOrEqual, lessOrEqual, present, approxMatch, extensibleMatch). La déclaration plus haut couvre le cas où les attributs sont évalués dans un extensibleMatch qui apparaît dans le filtre. Dans le cas où le champ dnAttributes de l'extensibleMatch est vrai il ne requière pas de vérification d'accès aux attributs du dn vu que l'accès est donné par la permission "v".

           S'il y a un attribut dans un élément de filtre pour lequel la permission n'est pas donnée alors cet élément de filtre s'évalue à "Undefined" du three-valued-logic de X.511. Note: la motivation pour la permission "p" est que si vous avez un filtre de droits sur un attribut alors dans certains cas il pourrait être opérationnellement le même que la permission read. par ex. vous pouvez déterminer rapidement la valeur de l'attribut, et cela n'est pas forcément désirable. Par exemple, si le type de l'attribut est un entier alors avec les permissions du filtre vous pouvez rapidement déterminer la valeur en faisant une séquence de recherche en utilisant "›" et "‹". Alors qu'avec la capacité de test de présence, vous pouvez empêcher ce genre de recherche, mais vous être capable de tester la présence de cet attribut.

4. Permission "r" pour chaque attribut dans la liste d'attribut AttributeDescriptionList ( ou tous les attributs dans l'entrée candidateDN si AttributeDescriptionList est * ) dont le type et/ou la valeur sera retournée. Note: la présence d'un attribut dans une entrée n'est jamais volontaire par le serveur si l'autorisation "r" lui est accordée, si un utilisateur peut déduire la présence d'un attribut avec "s" ou la permission "p" en utilisant un test de présence sur cet attribut dans le filtre de recherche. Note: bien que "r" et "s" sont typiquement donnés aux attributs on conserve les 2 permissions vu qu'il y a des cas où le distinction est utile. Une recherche de téléphone inversée est un exemple d'accès "r" mais pas "s".
5. Permission "t" à l'entrée candidateDN. Si cette permission n'est pas donnée alors le dn candidateDN ne doit pas être retourné. Si le serveur connais un alias pour l'entrée, cet alias peut être retourné à la place. Si aucun alias n'est disponible alors l'entrée candidateDN doit être omise du résultat de recherche.
6. Disclose on error pour l'opération de recherche. S'il n'y a pas d'entrée dans le scope de recherche qui satisfait l'item 1 (voir les droit sur l'entrée candidate) et l'item 2 (permission read sur l'entrée) alors la permission "u" sur l'entrée de base doit être évaluée. Si "u" n'est pas donné alors l'opération doit échouer avec un "no such object error" et le matchedDN de LDAPResult doit être définis à "". Si "u" est donné au baseObject alors le jeu vide de résultat est retourné.

Protéger le nommage des attributs du DN

   Protéger le nommage d'attribut dans le dn d'une entrée présente un problème pour le contrôle d'accès. Le problème est que si l'accès est donné au dn d'une entrée donnée, alors via le nommage d'attribut que ce dn contient, l'accès est également donné aux valeurs d'attribut dans les autres entrées. En plus, la connaissance de l'existence les entrées parent d'une entrée donnée est également fournie par le dn de l'entrée.

Opération modify

Rappelons que les paramètres de l'opération Modify sont:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
    object LDAPDN,
    modification SEQUENCE OF SEQUENCE {
        operation ENUMERATED {
            add (0),
            delete (1),
            replace (2) },
        modification AttributeTypeAndValues } }
    
AttributeTypeAndValues ::= SEQUENCE {
    type AttributeDescription,
    vals SET OF AttributeValue }

   Les permissions requises par authzId qui doivent être évaluées sont:

1. Permissions "w" pour chaque attribut à ajouter à l'object
2. Permission "o" pour chaque attribut pour lequel une valeur est supprimée de l'objet
3. permission "o" et "w" à chaque attribut remplacé dans l'objet.

Opération Add

Rappelons que les paramètres de l'opération Add sont:
AddRequest ::= [APPLICATION 8] SEQUENCE {
    entry LDAPDN,
    attributes AttributeList }
    
AttributeList ::= SEQUENCE OF SEQUENCE {
    type AttributeDescription,
    vals SET OF AttributeValue }

1. Permission "a" au parent de l'entrée
2. Permission "m" au parent de l'entrée pour chaque attribut à ajouter à l'entrée

Opération Delete

Rappelons que les paramètres de l'opération Delete sont:
DelRequest ::= [APPLICATION 10] LDAPDN

1. Permission "d" sur l'entrée

   Note: on pourrait ajouter la permission "o" pour autoriser l'opération, mais l'expérience a montré que cette permission additionnelle n'est pas aussi utile que ça, et X.500 ne nécessite que la permission "d"

Opération Modify DN

Rappelons que les paramètres de l'opération Modify DN sont:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
    entry LDAPDN,
    newrdn RelativeLDAPDN,
    deleteoldrdn BOOLEAN,
    newSuperior [0] LDAPDN OPTIONAL }

   Les variantes de l'opération ModifyDN sont listés ci-dessous. Les combinaisons des permissions write, obliterate, import, export et renameDN sont nécessaire pour chaque variante.

1. Renommer une entrée en déplaçant le flag RDN entrée 2 valeurs d'attributs existant, sans altérer de valeur d'attribut. Les permissions nécessaires sont renameDN.
2. Renommer une entrée en ajoutant une nouvelle valeur d'attribut, les permissions nécessaires sont renameDN et write
3. Renommer une entrée en utilisant une valeur d'attribut existant et en supprimant la valeur d'attribut courante. Les permissions nécessaires sont renameDN, write et obliterate.
5. Renommer une entrée en ajoutant une nouvelle valeur d'attribut et en supprimant la valeur courante. Les permissions nécessaires sont renameDN, write et obliterate.
5. Déplacer une entrée à un nouvel endroit dans le DIT, en gardant son RDN. Les permissions nécessaires sont import et export
6. Déplacer une entrée à un nouvel endroit couplé avec 1. Les permissions nécessaires sont import, export et renameDN
7. Déplacer une entrée couplé avec 2. Les permissions nécessaires sont import, export, renameDN, et write.
8. Déplacer une entrée couplé avec 3. Les permissions nécessaires sont import, export, renameDN, et obliterate.
9. Déplacer une entrée couplé avec 4. Les permissions nécessaires sont import, export, renameDN, write et obliterate.

   Pour un cas donné, si les permissions requises sont données, alors l'opération est permise par le modèle de contrôle d'accès. Si, pour un cas donné, les permissions ne sont pas données, alors l'opération doit échouer. Si le contrôle d'accès échoue à cause d'une permission d'attribut ou sur l'entrée manquante, alors si "u" est donné à l'entrée, le code d'erreur et matchedDN peuvent être retournés. Si "u" n'est pas donné à l'entrée, alors nosuchObject doit être retourné et matchedDN définis à "". Une logique similaire s'applique si l'échec du contrôle d'accès est dûe a une permission manquante sur newSuperior.

Opération Compare

Rappelons que les paramètres de l'opération Compare sont:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
    entry LDAPDN,
    ava AttributeValueAssertion }

1. Permission "c" sur l'attribut dans l'entrée sur lequel la comparaison est faite.

Opération Abandon

Rappelons que les paramètres de l'opération Abandon sont:
AbandonRequest ::= [APPLICATION 16] MessageID

   authzId a toujours les droits d'envoyer l'opération Abandon pour une opération précédemment initiée.

Opération Extended

Rappelons que les paramètres de l'opération Exended sont:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL }

   L'accès requis pour une opération étendue est au delà du scope de ce document. L'accès requis sera normalement définis par l'implémenteur de la requête étendue.

Permissions requises pour manipuler les alias et les références

   L'utilisation d'alias et le réferrants font partie de LDAPv3. Cependant, ils ne sont pas particulièrement bien définis. Les objets et attributs alias sont définis dans la rfc2256 comme dérivé de X.500, mais ne définis pas leur sémantique. X.500 définis les sémantiques des alias avec le respect du contrôle d'accès. On définis ce principe dans LDAPv3 basé sur X.511. Les référrants sont définis dans X.500, mais ne définis par leur sémantique avec le respect des contrôles d'accès.

ACI Distribution

   Actuellement il n'y a pas de standard LDAP définissant comment distribuer les données d'annuaire entre les serveur LDAP. En conséquence ce modèle ne peut pas spécifier pleinement le fonctionnement du modèle de contrôle d'accès dans un environnement distribué. Le cas de distribution via des référants est traité plus bas. Dans le cas du chaînage ( où un serveur LDAP renvoie une requête à un autre pour le compte d'un client ) alors le fonctionnement du modèle de contrôle d'accès est spécifique à ce serveur. Similairement, la manière dont un serveur détermine si le chaînage d'une opération est permise est spécifique au serveur. Par exemple, l'implémentation peut choisir de regarder le contexte de nommage local et le contexte de nommage subordonné distant comme aire de contrôle d'accès spécifique séparé, ou peut regarder le DIT comme une aire spécifique de contrôle d'accès et d'implémenter les mécanismes pour propager les aci entre les 2 serveurs. Ceci est hors du scope de ce modèle.

Alias

   Il y a 2 choses pour protéger avec les alias: le vrai nom des objets aliasés et l'emplacement du serveur le maintenant. Si le dé-référencement d'alias est requis dans le processus de localisation d'une entrée cible, aucune permissions spécifique n'est nécessaire pour le dé-référencement de l'alias. Le contrôle d'accès est forcé sur l'objet pointé par l'alias. Si le dé-référencement d'alias résulte en un continuationReference (ex: depuis une opération de recherche), alors la permission browse est requise sur l'alias et la permission read est requise sur l'attribut.

Référants

   Si un référant doit être suivi, aucune permission spécifique n'est nécessaire pour le client ldap pour suivre le référant. Le contrôle d'accès est forcé sur l'objet référencé. Si un référant est retourné, alors browse est requis sur l'entrée et read est requis sur l'attribut contenant le référant. Si le serveur implémente un référant par défaut, il n'y a pas de permission spécial.

Contrôler l'accès aux ACI

   Les attributs entryACI et subtreeACI sont utilisé pour spécifier le contrôle pour qui a la permission de définir/changer l'ACI. Les attributs entryACI et subtreeACI sont juste un autre attribut décrit avec un jeu de droits et permissions, et des sujets comme valeur de entryACI et subtreeACI. Si la stratégie pour contrôler entryACI et subtreeACI n'est pas spécifiée pour les objets dans l'arborescence, le mode est définis par l'implémentation. Par exemple, si aucun objet dans l'arborescence ne définis l'accès pour entryACI/subtreeACI dans les attributs entryACI/subtreeACI, alors le serveur pourrai simplement affirmer que le root DN est considéré comme propriétaire des stratégies pour tous les objets.

Exemples d'ACI

   Noter que dans les exemples, la forme "OID.‹attrname›" réfère à l'OID sous la forme décimale pour l'attribut ‹attrname›. Cette notation est utilisée uniquement pour les exemples.

Définitions d'attribut

   L'exemple suivant montre l'accès requis pour contrôler l'accès aux attributs entryACI et subtreeACI. Le premier exemple montre le contrôle sur une entrée individuelle et ses attributs. Le second exemple montre le contrôle d'accès sur un subtree. Le authnLevel est définis pour être raisonnablement sécurisé.

entryACI: grant:rwo#OID.entryACI#authnLevel:limited:role:cn=aciAdmin
subtreeACI: grant:rwo#OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin

   L'exemple suivant montre un attribut subtreeACI où un groupe "cn=DeptXYZ,c=US" a les permissions read,search et compare sur l'attribut attr1. Les permissions s'appliquent à tout le subtree sous le nœud contenant l'aci.

subtreeACI: grant;rsc#OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US

   L'exemple suivant montre un attribut ACI où un rôle "cn=SysAdmins,o=Company" a les permissions browseDN, viewEntry, et returnDN pour les objets sous ce nœud. Le rôle a également les droits read, search, et compare sur l'attribut attr2 et read, search, compare, write et obliterate sur attr3.

subtreeACI: grant:bvt#[entry]#authnLevel:weak:role:cn=SysAdmins,o=Company
subtreeACI: grant:rsc#OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company
subtreeACI: grant:rscwo#OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company

Modifier les valeurs entryACI et subtreeACI

   Modify-Replace fonctionne comme définis dans l'opération ldap modify. Si la valeur d'attribut n'existe pas, il créé la valeur. Si l'attribut existe, il remplace la valeur. Si les valeurs entryACI/subtreeACI sont remplacées, toutes les valeurs entryACI/subtreeACI sont remplacées. Modifier les attributs entryACI/subtreeACI nécessite d'avoir les permissions "w" et "o" sur entryACI/subtreeACI. Les exemples dans cette section assument que vous avez les accès pour contrôler entryACI/subtreeACI.

Un subtreeACI donnée pour une entrée:
subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Effectue le changement suivant:
dn: cn=someEntry
changetype: modify
replace: subtreeACI
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
L'ACI résultante est:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
Les valeurs subtreeACI pour Dept XYZ et ABC sont perdues durant le remplacement

   Durant un ldapmodify-add, si l'ACI n'existe pas, créé l'ACI avec les valeurs spécifique entryACI/subtreeACI. Si l'ACI existe, ajoute les valeurs spécifiées à l'entryACI/subtreeACI donné.

Par exemple un ACI donné:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
Avec une modification:
dn: cn=someEntry
changetype: modify
add: subtreeACI
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Va donner un ACI multi-valué:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Pour supprimer une valeur d'ACI particulière, utiliser la syntaxe ldapmodify-delete. Un ACI donné de:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
dn: cn = some Entry
changetype: modify
delete: subtreeACI
subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
Va donner un ACI restant:
subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
Avec l'opération ldapmodify-delete, toute l'acl peut être supprimée en spécifiant:
dn: cn = some Entry
changetype: modify
delete: entryACI
dn: cn = some Entry
changetype: modify
delete: subtreeACI

   Dans ce cas, l'entrée va hériter son ACI d'autres nœuds dans l'arborescence. Similairement, si toutes les valeurs d'entryACI et subtreeACI sont supprimées, alors les informations de contrôle d'accès pour cette entrée sont définis par le modèle d'héritage.

Évaluation

   Ces exemples assument que les entrées ACI listées dans chaque exemple sont les seuls ACI qui s'appliquent à l'entrée en question. On assume cn=jsmith est membre du groupe cn=G1 et du groupe cn=G2.

Exemple 1:
dn: o=XYZ, c=US
subtreeACI: grant:r#attr2#authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: grant:w#attr2#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
cn=jsmith a les droits rw sur attr2; l'ACI est combinées parce que les sujets (groupes) ont la même précédence.
Exemple 2:
dn: o=XYZ, c=US
subtreeACI: grant:rw#OID.attr3#authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
subtreeACI: deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
cn=jsmith a l'accès read sur attr3; write est refusé puisque deny a précédence sur grant.
Exemple 3:
dn: o=XYZ, c=US
subtreeACI: grant:m#OID.attr5#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
SubtreeACI: grant:m#OID.cn#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:m#OID.sn#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
subtreeACI: grant:a#[entry]#authnLevel:weak:authzID-dn:#cn=jsmith,o=ABC,c=US
cn=jsmith a le droit make sur attr5, cn et sn, et add sur l'entrée qui lui permet de créer un nouvel objet, cn=New,oXYZ,c=US avec des valeurs pour attr5, cn et sn. Cet exemple illustre comment la permission "m" peut être utilisée pour limiter les attributs qui peuvent être créés sur une nouvelle entrée.
Exemple 4:
dn: c=US
subtreeACI: grant:m#[all]#authnLevel:weak:subtree:c=US
dn: o=XYZ, c=US
subtreeACI: grant:a#[entry]#authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
cn=jsmith a le droit make sur tous les attributs et add sur l'entrée. Il y'a suffisamment de permissions pour créer un nouvel objet, cn=New,oXYZ,c=US avec les valeurs pour n'importe quel attribut. Pour les administrateurs qui ne souhaitent par limiter les attributs qui peuvent être créés sur les nouvelles entrées, cet exemple montre comment un simple ldapACI au niveau du domaine résout le problème.
Exemple 5:
dn: dc=com,dc=demo
subtreeACI: grant:rw#description;lang-en#authnLevel:weak:authzID-dn:cn=rvh,dc=att,dc=com
subtreeACI: grant:rw#description;lang-en,description;lang-fr#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Dans cet exemple, cn=rvh,dc=att,dc=com a l'accès "rw" à la langue anglaise de l'attribut Description sur les entrée sous dc=com,dc=demo. cn=rob,dc=sun,dc=com a les droits "rw" sur les versions française et anglaise de l'attribut Description. L'exemple démontre que "Attribute Descriptions", pas seulement "Attribute Types", peut être utilisé dans le champ attr d'un ACI.

ModDN

   Il y a de nombreuses actions différentes qui peuvent se produire quand la commande modDN est utilisée. La suite illustre les permissions nécessaires pour exécuter chaque scénario. Pour tous les exemples, on assume que le rôle cn=Admins fonctionne avec l'entrée suivante:

dn: cn=personA,o=Company
cn: personA
cn: FirstName
sn: LastName
objectclass: person

Exemples 1:
Effectuer un modRDN uniquement, utilisant une valeur d'attribut existante. Dans ce cas, on effectue un modRDN et on renomme cn=personA,o=Company en cn=FirstName,o=Company. La valeur d'entryACI pour cette entrée doit donner la permission rename sur l'entrée.
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
Exemple2:
Effectuer un modRDN et ajouter une nouvelle valeur d'attribut. Dans ce cas on renomme cn=personA,o=Company en cn=newFirstName,o=Company. La valeur entryACI doit donner la permission rename sur l'entrée et w sur l'attribut cn.
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w#cn#authnLevel:weak:role:cn=Admin
Exemple 3:
Effectuer un modRDN, en utilisant un attribut existant, mais en supprimant l'ancienne valeur RDN. On renomme cn=personA,o=Company en cn=FirstName,o=Company avec le flag deleteOldRdn à true. On doit avoir les permissions de renommer l'entrée, et de supprimer une valeur cn
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:o#OID.cn#authnLevel:weak:role:cn=Admin
Exemple 4:
Effectuer un modRDN, en utilisant une nouvelle valeur d'attribut, et en supprimant l'ancienne valeur. dans ce cas on renomme cn=personA,o=Company en cn=newFirstName,o=Company avec le flag deleteOldRdn. On doit avoir les permissions de renommer l'entrée, et de supprimer et écrire l'attribut cn
entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w,o#OID.cn#authnLevel:weak:role:cn=Admin
Exemple 5:
On veut changer l'emplacement de l'entrée et conserver le même RDN. Dans ce cas, on déplace cn=personA,o=Company vers cn=personA,o=CompanyB. On doit avoir les permissions d'export sur l'entrée originale, et import dur le nouvel objet supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:e#[entry]#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 6:
On veut changer l'emplacement de l'entrée et changer la valeur RDN à une valeur existante. Dans ce cas on déplace cn=personA,o=Company vers cn=FirstName,o=CompanyB. On doit avoir les premissions rename et export sur l'objet, et import sur le nouvel objet supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 7:
Changer l'emplacement de l'entrée et changer le RDN avec une nouvelle valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=newFirstName,o=CompanyB. On doit avoir les droits rename et export sur l'entrée originale, write sur cn et import sur le nouveau supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:w#OID.cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 8:
Changer l'emplacement de l'entrée et changer de RDN avec une valeur existante, en supprimant l'ancienne valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=FirstName,o=CompanyB. On doit avoir les droits rename et export sur l'entrée originale, delete sur cn et import sur le nouveau supérieur.
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:o#cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
Exemple 9:
Changer l'emplacement de l'entrée et changer de RDN avec une nouvelle valeur d'attribut, en supprimant l'ancienne valeur. Dans ce cas, on déplace cn=personA,o=Company vers cn=newFirstName,o=CompanyB. On doit avoir les droits rename et export sur l'objet original, write et delete sur cn, et import sur le nouveau supérieur
l'entryACI de cn=personA,o=Company est:
entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
entryACI: grant:wo#OID.cn#authnLevel:weak:role:cn=Admin
et l'entryACI de o=CompanyB:
entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin

Intéraction entre les ACI

   Ces exemples montrent comment les ACI dans différentes parties de l'arborescence intéragissent. Les exemples avec divers authnLevel sont donnés dans la section suivante.

Les exemples réfèrent à ce fragment de l'arborescence:
__________dc=com
____________|
___+--------+---------------+
___|________________________|
dc=tivoli_________________dc=sun
___|________________________|
cn=ellen__________________cn=rob

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:r#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors les droits effectifs de cn=rob,dc=sun,dc=com sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com sont "rw". L'ACI au niveau de dc=tivoli,dc=com est redondante.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#[all]# authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:w#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com, et les droits "rw" sur l'uid de ce même objet. Également, cn=rob,dc=sun,dc=com a les droits "r" sur tous les attributs de cn=rob,dc=sun,dc=com
Exemple 3: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" (mais pas "w") sur tous les attributs de cn=ellen,dc=tivoli,dc=com et "rw" sur tous les attributs de cn=rob,dc=sun,dc=com.
Exemple 4: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:w#OID.sn#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur uid et "w" sur sn de cn=ellen,dc=tivoli,dc=com
Exemple 5: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À cn=rob,dc=sun,dc=com: entryACI:grant:rw#[all]#authnLevel:weak:this:
Alors cn=rob,dc=sun,dc=com a des droits "rw" sur tous les attributs de cn=rob,dc=sun,dc=com.
Exemple 6: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#uid#authnLevel:weak:subtree:dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur l'uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", dc=tivoli,dc=com est inférieur à dc=com, donc sont subtreeACI a précédence.
Exemple 7: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
À dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits "rw" sur uid de cn=ellen,dc=tivoli,dc=com. en vérifiant la permission "w", les 2 subtreeACI sont au même niveau dans l'arborescence et le type de sujet dn a précédence sur le type subtree, donc le premier aci a précédence sur le second.
Exemple 8: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
À dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=com
Alors cn=rob,dc=sun,dc=com a les droits "r" sur uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", les 2 subtreeACI sont au même niveau et ont le même type de sujet, donc deny a précédence sur grant dans le facteur de décision.
Exemple 9: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:subtree:dc=sun,dc=com
À dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:subtree:dc=com
Alors cn=rob,dc=sun,dc=com a les droits "rw" sur uid de cn=ellen,dc=tivoli,dc=com. En vérifiant la permission "w", les 2 subtreeACI sont au même niveau et ont le même type de sujet, donc la précédence d'une liste spécifique d'attributs sur [all] est le facteur de décision.

Utilisation de ipAddress dans les ACI

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI: deny:adeinbvtug#[entry]#authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: deny:rwospcm#[all]#authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: grant:rscp#[all]#authnLevel:none:public:
subtreeACI: grant:btv#[entry]#authnLevel:none:public:
Alors tout utilisateur n'a de permission s'ils se connectent depuis un réseau 10/. S'ils se connectent depuis un autre réseau, ils auront les permissions "rscp" pour tous les attributs, et "btv" pour toutes les entrées dans dc=com.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
subtreeACI: grant:rspwocm#[all]#authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
Cela n'aura pas d'effet. Alors que cela semble donner un accès total aux utilisateurs dans le réseau 10/, les règles spéciales les idAddress et dns comme sujet les rendes utiles seulement pour les ACI deny. Les effets d'un grant sur une plage réseau mal formé ou un DNS wildcardé peut être très sérieux.
Un Administrateur qui veut vraiment donner un accès total à tout le monde dans 10/ devra spécifier:
À dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:public:subtreeACI:deny:adeinbvtug#[entry]#authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,11.0.0.0-255.255.255.255
subtreeACI: grant:rspwocm#[all]#authnLevel:weak:public:
subtreeACI: deny:rspwocm#[all]#authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,11.0.0.0-255.255.255.255

Utilisation de authnLevel dans les ACI

Exemple 1: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#OID.sn#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
À dc=tivoli,dc=com: subtreeACI:grant:r#OID.sn#authnLevel:limited:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rw" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind pour cette session a utilisé une authentification forte. Si le bind a utilisé une authentification limitée, il n'a que le droit "r". Si le bind pour cette session a uilisé une authentification faible, ou aucune authentification, il n'a aucun droit.
Exemple 2: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#sn#authnLevel:limited:subtree:dc=sun,dc=com
À dc=tivoli,dc=com:subtreeACI:grant:c;deny:w#sn#authnLevel:strong:authzID-dn:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rc" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind était fort. La permission "r" vient du fait que la partie grant du premier ACI s'applique au bind limité et supérieur. La partie deny du 2ème ACI s'applique aux cas où authnLevel est inférieur à "strong", donc il a précédence sur la permission "w" dans le premier ACI.
Exemple 3: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rs#sn#authnLevel:none:public
À dc=com: subtreeACI:grant:w#sn#authnLevel:strong:subtree:cn=rob,dc=sun,dc=com
Alors cn=rob,dc=sun,dc=com a les droits effectifs "rsw" sur l'attribut sn de l'objet cn=ellen,dc=tivoli,dc=com si le bind a utilisé une authentification forte, et "rs" si le bind a utilisé une autre forme d'authentification. Le grant dans le premier ACI s'applique aux bind au niveau "none" et supérieur.
Exemple 4: Si l'ACI est le suivant:
Au root: subtreeACI:grant:ps#[all]#authnLevel:none:public:subtreeACI:grant:cr#[all]#authnLevel:weak:subtree:
Alors tout utilisateur (incluant les anonymes) ont les droits "ps" sur toutes les entrées sur le serveur, et tout utilisateur avec un ID sur le serveur dont le bind a utilisé weak ou mieux a les permissions "pscr".
Exemple 5: Si l'ACI est le suivant:
À dc=com: subtreeACI:grant:rw#[all]#authnLevel:limited:cn=ellen,dc=tivoli,dc=com
À dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:strong:cn=rob,dc=sun,dc=com
Alors si le bind était fort, cn=ellen,dc=tivoli,dc=com a les permissions "rw" sur tous les attributs de l'objet cn=ellen,dc=tivoli,dc=com, et les permissions "rw" sur tous les attributs de cn=rob,dc=sun,dc=com. Si le bind est limité, cn=ellen,dc=tivoli,dc=com n'a plus que le droit "r" sur lui-même.
C'est une conséquence de la manière dont deny est traité avec authnLevel. Vu que cn=rob,dc=sun,dc=com n'a pas "w" quand il s'authentifie en strong, tous les utilisateurs n'auront pas ce droit quand ils s'authentifient à un niveau inférieur.

Contrôle GetEffectiveRights

   Les contrôles d'aci fournissent une manière de manipuler les informations de contrôle d'accès, en conjonction avec une opération ldap. Un contrôle LDAP est définis. Ce contrôle permet de récupérer les informations de contrôle d'accès. Le contrôle est GetEffectiveRights. Son but est de permettre à un administrateur ou une application de demander au serveur les droits d'un autre utilisateur de l'annuaire. Cela permet à un administrateur de vérifier les droits d'un utilisateur, ou une application peut proposer à un utilisateur les attributs sur lequel il a des droits de modification ou de lecture.

Request Control

Ce contrôle peut être inclus uniquement dans un message ldap_search. Le controlValue est un OCTET STRING, dont la valeur est la valeur encodée BER:
GetEffectiveRightsRequest ::= SEQUENCE{
    gerSubject [0] GERSubject
}
    
GERSubject ::= SEQUENCE {
    gerOneSubject [0] OneSubject -- from 4.1.2 , OPTIONAL
    germachineSubject [1] GERMachineSubject,
    gerAuthnLEvel [2] AuthnLevel, -- from 4.1.2
}
    
GERMachineSubject ::= SEQUENCE{
    gerOneIPAddress [0] IPAddress, -- from 4.1.2
    gerOneDNSName [1] DomainName -- from 4.1.2
}

   Le getEffectiveRightsRequest spécifie un sujet, gerSubject, sur quelles informations de contrôle d'accès sont demandées. Le contrôle demande au serveur d'évaluer et retourner les droits au niveau de l'entrée possédée par le gerSubject pour chaque entrée qui est retournée dans le résultat de recherche et pour chaque attribut spécifiquement demandé. Le serveur va utiliser l'algorithme de décision d'accès pour déterminer les droits effectifs.

Response Control

Ce contrôle est inclus dans un message de réponse ldap_search. Le contrôleValue est un OCTET STRING dont la valeur est encodée BER:
GetEffectiveRightsResponse ::= {
    result ENUMERATED {
        success (0),
        operationsError (1),
        unavailableCriticalExtension (12),
        noSuchAttribute (16),
        undefinedAttributeType (17),
        invalidAttributeSyntax (21),
        insufficientRights (50),
        unavailable (52),
        unwillingToPerform (53),
        other (80)
    }
}

Les droits effectifs sont retournés avec chaque entrée retournée par le résultat de la recherhe. Le contrôle de réponse pour ldap_search est:
PartialEffectiveRightsList ::= SEQUENCE {
    entryLevelRights [0] EffectiveRights,
    attributeLevelRights [1] AttributeLevelRights
}
    
EffectiveRights ::= CHOICE {
    rights [0] Permissions -- from 4.1.2,
    noRights [1] NULL,
    errorEvaluatingRights [2] GerError
}
    
GerError ::= ENUMERATED
    {generalError(0),insufficientAccess(1)}
    
    AttributeLevelRights ::= SEQUENCE OF {
    attr [0] SEQUENCE OF Attribute,
    rights [1] EffectiveRights
}

   Pour une entrée donnée, le champ entryLevelRights du contrôle de réponse contient les droits effectifs au niveau de l'entrée qui gerSubject a sur cette entrée. Le champ attributeLevelRights contient la liste des attributs et les droits effectifs que gerSubject a pour chacun de ces attributs. La liste des attributs consiste de ceux retournés dans l'opération de recherche et les attributs explicitement demandés. Un attribut explicitement demandé dans une recherche peut ne pas être retournée parce que l'entrée n'est pas présent dans l'entrée, mais on peut être intéressé par les permissions sur cet attribut.

   Le contrôle retourne les permissions que gerSubject a sur l'entrée donnée et ses attributs. Pour déterminer si ces permissions suffisent pour permettre à gerSubject d'effectuer une opération LDAP donnée sur l'entrée, le demandeur va déterminer si ces permissions satisfont les permissions requises pour cette opération LDAP. Noter que dans le cas où les permissions ne sont pas suffisantes pour une acction, ce contrôle ne permet pas de déterminer si c'est parce que la permission n'a pas été donnée, ou si c'est à cause d'un deny explicit.

Contrôle d'accès pour le contrôle GetEffectiveRights

Exemples

Supposons que l'on a un DIT avec les entrées et contrôles d'accès suivant:
o=sun.com
objectclass: top
objectclass: organization
o: sun.com
subtreeACI: grant:rsc#[all]#authnLevel:none:public:
subtreeACI: deny:rsc#[userPassword,subtreeACI,entryACI,salary]#authnLevel:none:public:
subtreeACI: grant:bvt#[entry]#authnLevel:none:public:
subtreeACI: grant:g#[entry]#authnLevel:limited:this:
subtreeACI: grant:worsc#[all]#authnLevel:limited:this:
subtreeACI: deny: wo[entryACI, subtreeACI, salary]#this
subtreeACI: grant:rscmo,w#[all]#authnLevel:strong:group:cn=adminGroup,ou=Groups,o=sun.com
subtreeACI: grant:bvtugeinad#[entry]#authnLevel:stronggroup: cn=adminGroup,ou=Groups,o=sun.com
    
cn=admin,o=sun.com
objectclass: top
objectclass: person
cn: admin
sn: admin
userPassword: secret
salary: 10000
    
ou=Groups,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Groups
    
cn=adminGroup,ou=Groups,o=sun.com
objectclass: top
objectclass: groupOfUniqueNames
uniquemember: cn=admin,o=sun.com
    
ou=Eng,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Eng
    
cn=Joe Engineer,ou=Eng,o=sun.com
objectclass: top
objectclass: person
cn: Joe Engineer
sn: Engineer
userPassword: secret
salary: 10000
    
ou=Sales,o=sun.com
objectclass: top
objectclass: organizationalUnit
    
cn=Joe Sales,ou=Sales,o=sun.com
objectclass: top
objectclass: person
cn: Joe Sales
sn: Sales
userPassword: secret
salary: 100000000000

   La stratégie de contrôle d'accès dans ce DIT peut être décrite comme suit:

1. Les utilisateurs anonymes peuvent lire, rechercher et comparer les droits dans tout de DIT, excepté pour les attributs userPassword,subtreeACI,entryACI, et salary.
2. Tout utilisateur authentifié avec un mécanisme limité peut modifier les attributs de son entrée, excepté subtreeACI, entryACI, et salary.
3. Tous les utilisateurs peuvent lire tous les attributs dans son entrée.
4. Tout utilisateur authentifié avec un mécanisme limité peut récupérer les droits effectifs de sa propre entrée.
5. Les utilisateurs, authentifiés avec un mécanisme fort, dans le groupe cn=adminGroup,ou=Groups,o=sun.com peuent récupérer les droits effectifs dans tout de DIT.

   Quelques exemples de requêtes pour obtenir les droits effectifs et les réponses:

   Exemple 1: Supposons que l'on fait une demande, authentifié au niveau strong, en tant que cn=admin,o=sun.com, avec comme base o=sun.com, un filtre "objectclass=*", et les attributs demandés "* entryACI", avec le contrôle getEffectiveRights et le sujet est cn=Joe Sales,ou=Sales,o=sun.com, et le MachineSubject spécifiant l'ipAddress et dnsName de la machine client et le authnLevel à limité.

Le résultat de recherche et les droits effectifs que l'on verra sont:
o=sun.com
objectclass: top
objectclass: organization
o: sun.com
    
entryLevelRights: bvt
attributeLevelRights: objectclass,o:rsc,entryACI:none
---
cn=admin,o=sun.com
objectclass: top
objectclass: person
cn: admin
sn: admin
userPassword: secret
salary: 10000

entryLevelRights: bvt
attributeLevelRights: objectclass,cn,sn:rsc,userPassword,salary,entryACI:none
---
ou=Groups,o=sun.com
objectclass: top
objectclass: organizationalUnit
ou: Groups

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
ou=Eng,o=sun.com
objectclass: top
objectclass: organizationalUnit

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
cn=Joe Engineer,ou=Eng,o=sun.com
objectclass: person
cn: Joe Engineer
sn: Engineer
userPassword: secret
salary: 10000

entryLevelRights: bvt
attributeLevelRights: objectclass,cn,sn:rsc,userPassword,salary,entryACI:none
---
ou=Sales,o=sun.com
objectclass: top
objectclass: organizationalUnit

entryLevelRights: bvt
attributeLevelRights: objectclass,ou:rsc,entryACI:none
---
cn=Joe Sales,ou=Sales,o=sun.com
objectclass: person
cn: Joe Sales
sn: Sales
userPassword: secret
salary: 100000000000

entryLevelRights: bvtg
attributeLevelRights: objectclass,cn,sn,userPassword:rscow,salary,entryACI:rsc

Interaction Client-Serveur

   Le contrôle GetEffectiveRights demande les droits effectifs pour l'entrée/attribut demandé basé sur le sujet spécifié. Il y a 6 scénarios possibles qui peuvent se produire en résultat de ce contrôle:

1. Si le serveur ne supporte pas ce contrôle et que le client a spécifié la criticité, le serveur doit retourner unavailableCriticalExtension.
2. Si le serveur ne supporte pas ce contrôle et que le client n'a pas spécifié la criticité, le serveur doit ignorer le processus et traiter la recherche normalement.
3. Si le serveur supporte ce contrôle mais que pour une quelconque raison il ne peut le traiter et que le client a spécifié la criticité, le serveur devrait retourner unavailableCriticalExtension.
4. Si le serveur supporte ce contrôle mais que pour une quelconque raison il ne peut le traiter et que le client n'a pas spécifié la criticité, le serveur devrait retourner "no rights returned" et inclure "Unavailable" dans le contrôle GetEffectiveRightsResponse.
5. Si le serveur supporte ce contrôle et peut retourner les droits, il devrait inclure le contrôle GetEffectiveRightsResponse dans le message searchResult avec un code de résultat success.
6. Si la recherche échoue pour une quelconque raison, alors le serveur devrait omettre le contrôle GetEffectiveRightsResponse dans le searchResult.

   L'application cliente est assurée que les droits correct sont retournés pour le scope de l'opération de recherche si et seulement si le contrôle GetEffectiveRightsResponse retourne les droits. Si le serveur omet ce contrôle, le client devrait assumer que le contrôle a été ignoré par le serveur.

   Le contrôle GetEffectiveRightsResponse, si inclus par le serveur dans le searchResponse, devrait avoir le GetEffectiveRightsResult mis à "success" si les droits sont retournés ou à un code d'erreur approprié. Le serveur peut ne pas être en mesure de retourner un droits parce qu'il peut ne pas exister; dans ce cas, la demande de droits est ignoré avec succès.
^
02 novembre 2013

htmlpdflatexmanmd




draft-ietf-ldapext-c-api-vlv-01

draft-ietf-ldapext-c-api-vlv-01

Contrôle Virtual List View

   Ce document décrit les fonctions pour créer des contrôles de requête de listes virtuelles. Cette extension consiste de 2 contrôles LDAP: un contrôle de requête Virtual List View qui est envoyé par un client à un serveur avec une recherche LDAP et un contrôle de réponse.

La structure LDAPVirtualList est passé à la fonction ldap_create_virtuallist_control() pour créer le contrôle:
typedef struct ldapvirtuallist {
    unsigned long ldvlist_before_count ;
    unsigned long ldvlist_after_count ;
    char *ldvlist_attrvalue ;
    unsigned long ldvlist_index ;
    unsigned long ldvlist_size ;
    void *ldvlist_extradata ;
} LDAPVirtualList ;
int ldap_create_virtuallist_control(
LDAP *ld,
LDAPVirtualList *ldvlistp,
LDAPControl **ctrlp
) ;
#define LDAP_CONTROL_VLVREQUEST "2.16.840.1.113730.3.4.9"

ld Un handle de session LDAP
ldvlistp L'adresse d'une structure LDAPVirtualList dont le contenu est utilisé pour construire le contrôle
ctrlp Un paramètre de résultat qui aura l'adresse d'une structure LDAPControl qui contient le contrôle VLV créé.

   Les membres d'une structure LDAPVirtualList sont:

ldvlist_before_count Nombre d'entrées avant l'entrée cible que le client demande
ldvlist_after_count Nombre d'entrées après l'entrée cible
ldvlist_attrvalue Si non NULL, indique que le choix byValue dans VirtualListViewRequest est utilisé et correspond à l'élément assertionValue de la valeur du contrôle VirtualListViewRequest encodé en BER lui-même. Cette valeur est comparée par le serveur avec les valeurs des attributs spécifiés par la clé de trie pour déterminer l'entrée cible.
ldvlist_index Utilisé si ldvlist_attrvalue est NULL. Permet de déterminer l'entrée cible.
ldvlist_size Utilisé si ldvlist_attrvalue est NULL. Permet de déterminer l'entrée cible.
ldvlist_extradata Réservé. n'a pas d'effet sur le contrôle

Réponse


int ldap_parse_virtuallist_control(
    LDAP *ld,
    LDAPControl **ctrls,
    unsigned long *target_posp,
    unsigned long *list_sizep,
    int *errcodep
) ;
#define LDAP_CONTROL_VLVRESPONSE "2.16.840.1.113730.3.4.10"
#define LDAP_SORT_CONTROL_MISSING 0x3C /*    60    */
#define LDAP_INDEX_RANGE_ERROR 0x3D /*    61    */

ld Un handle de session LDAP
ctrls L'adresse d'un tableaux de structures LDAPControl.
target_posp l'index de l'entrée cible dans la liste
list_sizep Taille de la liste estimée par le serveur
errcodep Code de résultat VLV, devrait avoir les valeurs suivantes:


LDAP_SUCCESS (0)
LDAP_OPERATIONS_ERROR (1)
LDAP_UNWILLING_TO_PERFORM (53)
LDAP_INSUFFICIENT_ACCESS (50)
LDAP_BUSY (51)
LDAP_TIMELIMIT_EXCEEDED (3)
LDAP_ADMINLIMIT_EXCEEDED (11)
LDAP_SORT_CONTROL_MISSING (60)
LDAP_INDEX_RANGE_ERROR (61)
LDAP_OTHER (50)

^
09 octobre 2014

htmlpdflatexmanmd




draft-ietf-ldapext-ldapv3-dupent-08

draft-ietf-ldapext-ldapv3-dupent-08

Contrôle pour une représentation d'entrée dupliquée

   Ce document décrit les contrôles qui permettent aux entrées dupliquées d'être retournées dans un jeu de résultat de l'opération de recherche. Chaque entrée dupliquée représente une valeur distinct (ou une combinaison de valeurs) du jeu d'attribut multi-valué spécifié.

   Par exemple, une application peut nécessiter de produire une liste ordonnées d'entrées, triée par un attribut multi-valué, où chaque valeur d'attribut est représentée dans la liste. Le contrôle SSS permet au serveur d'ordonner les entrées du résultat de recherche basé sur les valeurs d'attribut. Mais il ne permet pas de spécifier le comportement quand un attribut contient plusieurs valeurs. Le contrôle ldap pour la représentation des résultats de recherche, comme définis dans X.511, est d'utiliser la valeur d'ordre la plus petite comme clé de tri.

   Pour produire une liste ordonnée, où chaque valeur d'un attribut multi-valué est trié dans la liste, un contrôle séparé est nécessaire qui étend suffisamment le jeu d'entrée pour représenter chaque valeur attribut avant le trie.

   Par exemple, une liste triée de tous les numéros de téléphone dans une organisation. Parce qu'une entrée peut avoir plusieurs numéros de téléphone, et la liste doit être triée par numéro de téléphone, la liste doit être capable de contenir des entrées dupliquées, chacun avec son propre numéro de téléphone unique.

   Autre exemple, une application qui a besoin d'afficher une liste ordonnée de tous les membres d'un groupe. Il utiliserai ce contrôle pour créer un jeu de résultat d'entrée groupOfNames dupliquées, chacun avec une simple, valeur unique dans son attribut member.

Contrôles

Ce contrôle est inclus dans le message searchRequest dans le champ controls du LDAPmessage. controlType est 2.16.840.1.113719.1.27.101.1 et controlValue est définis comme suit:
DuplicateEntryRequest ::= SEQUENCE {
    AttributeDescriptionList, -- from [RFC2251]
    PartialApplicationAllowed BOOLEAN DEFAULT TRUE }

AttributeDescriptionList

Le type de données AttributeDescriptionList décris une liste de 0 ou plusieurs types AttributeDescription. Les définitions, issues de la rfc2251 sont répétées ici:
AttributeDescriptionList ::= SEQUENCE OF AttributeDescription
AttributeDescription ::= LDAPString
Une valeur de AttributeDescription est basé sur le BNF suivant:
attributeDescription = AttributeType [ ";" ‹options› ]

   En traitant une requête search, un serveur examine cette liste. Si un attribut spécifié ou un sous-type d'attribut existe dans une entrée à retourner par l'opération de recherche, et que cet attribut maintient plusieurs valeurs, le serveur traite l'entrée comme si c'était de multiple, entrées dupliquées -- les attributs spécifiés maintenant une seule et unique valeur du jeu original de valeurs de cet attribut. Noter qu'il peut en résulter des entrées qui ne matchent plus le filtre de recherche.

   Spécifier un supertype d'attribut a l'effet de traiter toutes les valeurs des sous-types de cet attribut comme si c'était des valeurs de ce supertype.

   Quand des descriptions d'attribut contiennent des options de sous-typage, elle sont traitées de la même manière que décris dans la rfc2251. Les sémantiques sont indéfinies si une description d'attribut contient une option de non sous-typage, et ne devrait pas être spécifié par les clients.

   Quand 2 attributs ou plus sont spécifiés par ce contrôle, le nombre d'entrées dupliquées est la combinaison de toutes les valeurs dans chaque attribut. À cause de la complexité potentielle à desservir plusieurs attribut, les implémentations de serveur peuvent choisir de supporter un nombre limité d'attributs dans le contrôle.

   Il y a un cas spécial où il n'y a pas d'attributs spécifié, ou un description d'attribut a la valeur '*'. Dans ce cas, tous les attributs sont utilisé. Si un attribut n'est pas reconnu, cet attribut est ignoré en traitant le contrôle.

PartialApplicationAllowed

   Le champ PartialApplicationAllowed est utilisé pour spécifier si le client va permettre au serveur d'appliquer ce contrôle à un sous-jeu du jeu de résultat de recherche. À TRUE, le serveur est libre d'appliquer arbitrairement ce contrôle à aucun, n'importe lequel, ou tous les résultats de recherche ou échoue à supporter le contrôle.

   Les implémentations client utilisent le contrôle DuplicateSearchResult pour découvrir que résultats de recherche ont été affectés par ce contrôle.

Contrôles de réponse

   2 contrôles de réponse sont définis pour fournir un retour durant les résultats de recherche; DuplicateSearchResult et DuplicateEntryResponseDone.

DuplicateSearchResult est envoyé avec toutes les opérations SearchResultEntry qui contiennent des résultats de recherche qui ont été modifiés par le contrôle DuplicateEntryRequest.
DuplicateEntryResponseDone est envoyé avec l'opération SearchResultDone pour compléter les informations.

DuplicateSearchResult

   Ce contrôle est inclus dans le message SearchResultEntry d'un résultat de recherche qui maintient un entry qui a été modifiée par le contrôle DuplicateEntryRequest. Ce contrôle est absent des résultat de recherche qui ne sont pas affectés par le contrôle DuplicateEntryRequest. controlType vaut 2.16.840.1.113719.1.27.101.2. controlValue n'est pas inclus.

DuplicateEntryResponseDone

Ce contrôle est inclus dans le message searchResultDone. controlType vaut 2.16.840.1.113719.1.27.101.3, controlValue est définis comme suit:
DuplicateEntryResponseDone ::= SEQUENCE {
    resultCode, -- From [RFC2251]
    errorMessage [0] LDAPString OPTIONAL,
    attribute [1] AttributeDescription OPTIONAL }

   Un resultCode est fournis ici pour permettre au serveur de prévenir le client qu'une erreur s'est produite à cause de ce contrôle. Par exemple, une recherche qui aurait du se compléter avec succès peut échouer avec un sizeLimitExceede à cause de ce contrôle. errorMessage peut être utilisé avec une chaîne human-readable dans le cas d'un resultCode indiquant une erreur. Le champ attribute peut être définis à la valeur du premier attribut spécifié par le DuplicateEntryRequest qui à généré l'erreur. Le client doit ignorer le champ attribut si le résultat est success.

Exemple simple

Cet exemple montre l'utilisation de ce contrôle pour produire une liste de tous les numéros de téléphone dans dc=example,dc=net. Partant des 3 entrées suivantes:
dn: cn=User1,dc=example,dc=net
telephoneNumber: 555-0123
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-8854
telephoneNumber: 555-4588
telephoneNumber: 555-5884
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-9425
telephoneNumber: 555-7992
D'abord une recherche LDAP est spécifiée avec un baseDN à "dc=example,dc=net", un scope subtree, un filtre "(telephoneNumber=*)". Un contrôle DuplicateEntryRequest est attaché à la recherche, spécifiant "telephoneNumber" comme description d'attribut. Le jeu de résultat sera:
dn: cn=User1,dc=example,dc=net
telephoneNumber: 555-0123
‹no DuplicateSearchResult control sent with search result›
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-8854
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-4588
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
telephoneNumber: 555-5884
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-9425
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User3,dc=example,dc=net
telephoneNumber: 555-7992
control: 2.16.840.1.113719.1.27.101.2

   Toutes les entrées sauf la première seront accompagnées par le contrôle DuplicateSearchResult. Noter qu'il n'est pas nécessaire d'utiliser un attribut dans ce contrôle qui est spécifié dans le filtre de recherche.

Spécifier plusieurs attributs

Un exemple plus compliqué utilise plusieurs attributs. Assumant les entrées suivantes dans l'annuaire:
dn: cn=User1,dc=example,dc=net
cn: User1
givenName: User One
mail: user1@example.net
dn: cn=User2,dc=example,dc=net
cn: User2
givenName: User Two
mail: user2@example.net
mail: usertwo@example.net
Dans cet exemple, on spécifie mail et name dans la liste des attributs. En spécifiant name, tous les sous-type de name seront également considérés. Le résultat sera:
dn: cn=User1,dc=example,dc=net
cn: User1
mail: user1@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User1,dc=example,dc=net
givenName: User One
mail: user1@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
cn: User2
mail: user2@example.net
control: 2.16.840.1.113719.1.27.101.2
cn: User2
mail: usertwo@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
givenName: User Two
mail: user2@example.net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=User2,dc=example,dc=net
givenName: User Two
mail: usertwo@example.net
control: 2.16.840.1.113719.1.27.101.2

Lister les membres d'un groupOfNames

Cet exemple moutre comment les contrôles peuvent être utilisés pour retourner plusieurs entrées depuis une entrée groupOfNames. Considérant l'entrée suivante:
dn: cn=Administrators,dc=example,dc=net
cn: Administrators
member: cn=aBaker,dc=example,dc=net
member: cn=cDavis,dc=example,dc=net
member: cn=bChilds,dc=example,dc=net
member: cn=dEvans,dc=example,dc=net
un searchBase à "cn=Administrators,dc=example,dc=net", un filtre à "(objectClass=*)", un scope base et le contrôle duplicateEntryRequest avec la valeur d'attribut "member":
dn: cn=Administrators,dc=example,dc=net
member: cn=aBaker,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=cDavis,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=bChilds,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2
dn: cn=Administrators,dc=example,dc=net
member: cn=dEvans,dc=example,dc=net
control: 2.16.840.1.113719.1.27.101.2

   Cette liste peut être ainsi triée par membre et affichée dans une liste.

Relation avec d'autres contrôles

   Ce contrôle est conçus pour être utilisé avec le contrôle Server Side Sorting. En couplant ces 2 contrôles, on peut produire un jeu d'entrées triées par valeurs d'attribut, où chaque valeur d'attribut est représentée dans le jeu trié. Les implémentations de serveur doivent s'assurer que ce contrôle est traité avant de trier le résultat d'une recherche, vu que ce contrôle altère le jeu de résultat.

   Ce contrôle peut également être utilisé avec le contrôle Virtual List View. La nature de dépendance entre VLV est SSS est telle que le trie est fait en premier. À cause de cela, l'impact de ce contrôle sur le contrôle VLV est minimale.
^
27 octobre 2013

htmlpdflatexmanmd




draft-zeilenga-ldap-noop-12

draft-zeilenga-ldap-noop-12

Contrôle LDAP no-op

   Le contrôle no-op peut être utilisé pour désactiver l'effet normal d'une opération. Le contrôle peut être utilisé pour découvrir comment un serveur peut réagir à une requête update particulière sans mettre à jours l'annuaire. Le contrôle no-op est un contrôle dont controlValue est absent. Les clients doivent fournis la criticité pour empêcher toute modification. Un resultCode autre que noOperation signifie que le serveur n'est pas capable de compléter le traitement. Les serveurs devrait indiquer le support pour ce contrôle en fournissant l'OID dans supportedControl.

^
27 octobre 2013

htmlpdflatexmanmd




draft-zeilenga-ldap-relax-03

draft-zeilenga-ldap-relax-03

Contrôle relax

   Le contrôle de règle relax permet à un DUA de demander au service d'annuaire un relâchement temporaire de diverses données et règles de modèle de service. Un serveur LDAP empêche la modification de la classe d'objet structurelle d'un objet. Les modèles x.500 ne permettent pas à un objet person d'être transformés en un objet organizationalPerson. Cette approche est problématique pour plusieurs raisons. D'abord, vu que LDAP n'a pas de méthode standardisé pour effectuer 2 opérations en une seule transaction, l'état intermédiaire de l'annuaire (après le delete, avant le add) est visible aux autres clients. Ensuite, les attributs tels que entryUUID vont refléter que l'objet a été remplacé, pas transformé.

   Un serveur LDAP empêche les clients de modifier les valeurs des attributs NO-USER-MODIFICATION. Cependant, quand un administrateur restaure un objet, en repartitionnant les données entre des serveurs d'annuaire, ou en migrant d'un serveur à un autre, il peut être désirable de permettre au client d'assigner ou modifier la valeur de entryUUID.

   Ce contrôle peut être attaché aux requêtes LDAP pour mettre à jours le DIT pour demander à divers règles de données et services d'être relaxé durant l'exécution de la mise à jours. Le serveur s'assure que l'état de l'annuaire résultant reste valide.

   L'utilisation de cette extension est restreinte par acl et est principalement utilisé pour les administrateurs de l'annuaire.

Pour changer un objet organization en organizationalUnit, un client pourrait utiliser la requête suivante:
dn: o=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
delete: objectClass
objectClass: organization
-
add: objectClass
objectClass: organizationalUnit
-

   Le contrôle relax permet d'ajouter ou modifier des valeurs d'attributs marqué inactifs.

Ajouter un entryUUID:
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14

Modifier l'entryUUID:
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: entryUUID
entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
-

createTimestamp
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
createTimestamp: 20060101000000Z
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: createTimestamp
createTimestamp: 20060101000000Z
-

modifyTimestamp
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
modifyTimestamp: 20060101000000Z
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: modifyTimestamp
modifyTimestamp: 20060101000000Z
-

creatorsName et modifiersName
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: add
objectClass: organizationalUnit
ou: Unit
creatorsName: cn=Jane Doe,dc=example,net
modifiersName: cn=Jane Doe,dc=example,net
    
dn: ou=Unit,dc=example,dc=net
control: IANA-ASSIGNED-OID
changetype: modify
replace: creatorsName
creatorsName: cn=Jane Doe,dc=example,net
-
replace: modifiersName
modifiersName: cn=Jane Doe,dc=example,net
-

^
04 juillet 2010

htmlpdflatexmanmd




du

du

Reporte la quantité d'espace disque utilisé par les fichiers spécifiés et pour chaque répertoire.

   Sans argument, du reporte l'espace disque pour le répertoire courant. Normalement l'espace disque est affiché en unités de 1024 octets. Les quantité non entières sont arrondies à l'unité supérieur. Si 2 ou plusieurs liens dur pointent sur le même fichier, seul un des liens dur est compté.

OPTIONS

-a, --all Affiche les fichiers, pas seulement les répertoires.
--apparent-size affiche les tailles apparentes, au lieu de l'espace disque utilisé. il s'agit du nombre d'octets reporté par wc -c sur les fichiers réguliers, ou plus généralement, ls -l --block-size=1 ou stat --format=%s.
-b, --bytes est équivalent à --apparent-size --block-size=1
-B SIZE, --block-size=SIZE définit la taille de block.
-c, --total Affiche un grand total de tous les arguments, après que tous les argument ont été traités.
-D, --dereference-args déréference les liens symboliques qui sont sur la ligne de commande. n'affecte pas les autres liens symboliques.
--files0-from=FILE Désactive le traitement des fichiers nommés sur la ligne de commande, et traite ceux nommés dans FILE. chaque nom est terminé par un ASCII NUL.
-h, --human-readable ajoute une lettre à chaque taille. Utilise les puissances de 1024.
-H Equivalent à --dereference-args
-k affiche les tailles en blocks de 1024 octets. Équivalent à --block-size=1K
-l, --count-links compte la taille de tous les fichiers, même s'ils sont déjà apparus (liens durs)
-L, --derefence Déréférence les liens symboliques
-m équivalent à --block-size=1M
-P, --no-dereference Pour chaque lien symbolique, considère l'espace disque utilisé par le lien symbolique.
--max-depth=DEPTH Affiche le total pour chaque répertoire (et fichier si -a) qui fait moins de DEPH en dessous de la hiérarchie racine. root est au level 0 donc --max-depth=0 est équivalent à du -s
-0, --null sort un ASCII NUL à la fin de chaque ligne, au lien d'un newline. Permet à d'autres programme d'utiliser la sortie de du.
--si ajoute une lettre à chaque taille. Utilise les puissances de 1000.
-s, --summarize Affiche seulement un total pour chaque argument.
-S, --separate-dirs Normalement, dans la sortie de du sans -s, la taille d'un répertoire représente la somme de toutes les entrées dans le répertoire + le répertoire lui-même. Cette options reporte la taille dérivé de stat.st_size.
-x, --one-file-system omet les répertoires qui sont sur un système de fichier différent.
--exclude=PATTERN Omet les fichiers et répertoires correspondant à PATTERN
-X FILE, --exclude-from=FILE idem, mais les patterns sont dans FILE, un par ligne. si FILE vaut '-' utilise l'entrée standard.
--time Affiche le mtime
--time=ctime, --time=status, --time=use affiche le ctime
--time=atime, --time=access Affiche le atime
--time-style=STYLE spécifie le style d'affichage de temps. STYLE peut être :

        +FORMAT FORMAT est interprété comme un argument de date.
        full-iso affiche la date en utilisant ISO 8601. le style est équivalent à +%Y-%m-%d %H :%M :%S.%N %z
        long-iso Liste la date au format ISO 8601. est équivalent à +%Y-%m-%d %H :%M
        iso liste au format ISO 8601 pour les date anciennes. est équivalent à +%Y-%m-%d $newline%m-%d %H :%M

   On peut spécifier le style avec la variable d'environnement TIME_STYLE. par défaut utilise long-iso
^
04 novembre 2016

htmlpdflatexmanmd




dumpe2fs

dumpe2fs

Dump les informations de système de fichier ext2/3/4

OPTIONS

-b Affiche les blocks réservés comme défectueux dans le système de fichier.
-o superblock=superblock Utilise le superblock spécifié pour examiner le système de fichier.
-o blocksize=blocksize Spécifie la taille de block à utiliser pour examiner le système de fichier.
-f Force à afficher même si certains flags de système de fichier ne sont pas compris par dumpe2fs.
-g Affiche les informations de descripteur de groupe au format human-readable. Les champs affichés sont le numéro de groupe, le numéro du premier block dans le groupe; l'emplacement du superblock ou -1 si non présent, la plage de blocks utilisés par les descripteurs de groupe ou -1 si non présent; l'emplacement du bitmap de block, l'emplacement du bitmap d'inode, et la plage de blocks utilisés par la table d'inode
-h Affiche seulement les informations du superblock.
-i Affiche les données du système de fichier depuis un fichier image créé par e2image.
-x Affiche les numéros de block d'informations de groupe détaillés, en hexa
^
02 novembre 2016

htmlpdflatexmanmd




e2freefrag

e2freefrag

Affiche les informations de fragmentation de l'espace libre

   e2freefrag est utilisé pour afficher la fragmentation de l'espace libre dans les systèmes de fichier ext2/3/4. e2freefrag scanne le bitmap de block pour vérifier le nombre de blocks libres présent et contigüs et l'espace libre aligné. Le pourcentage de blocks libre contigüs de taille et d'alignement chunk_kb est affiché. Il affiche également la taille de chunk libre minimum/maximum/moyen dans le système de fichier.

OPTIONS

-c chunk_kb Si une taille de chunk est spécifiée, affiche le nombre de chunks libre de cette taille disponible en kio. La taille de chunk doit être une puissante de 2 et doit être supérieur à la taille de block du système de fichier.
^
03 novembre 2016

htmlpdflatexmanmd




e2fsck

e2fsck

Vérifier un système de fichier linux

   e2fsck est utilisé pour vérifier les systèmes de fichier. Pour ext3/4 qui utilise un journal, si le système a été éteind non proprement sans erreurs, normalement, après avoir rejoué les transactions dans le journal, le système de fichier devrait être marqué correct. Pour pour les systèmes de fichiers journalisés, e2fsck rejoue normalement le journal et quitte, sauf si le superblock indique que d'autres vérifications sont nécessaire.

   Noter qu'en général il n'est pas sûr de lancer e2fsck sur des systèmes de fichier monté. La seule exception est si l'option -n est spécifiée, et -c, -l ou -L ne sont pas spécifiés. Cependant, même s'il est sûre de le faire, le résultat affiché n'est pas valide si le système de fichier est monté. Si e2fsck demande si le système de fichier monté doit être vérifié, la seule réponse correcte est 'no'.

   Si e2fsck est lancé intéractivement (-y, -n ou -p), le programme demande à l'utilisateur de fixer chaque problème rencontré. 'y' fixe l'erreur, 'n' laisse l'erreur, et 'a' fixe le problème et tous les autres. 'Entrée' utilise la réponse par défaut, qui est affiché à la fin de la question.

OPTIONS

-a idem à -p.
-b superblock Au lieu d'utiliser le superblock normal, utilise un superblock alternatif.
-B blocksize Force à localiser le superblock à une taille de block définis, au lieu de le deviner.
-c Force à utiliser badblocks(8) pour faire un scan read-only dans le périphérique pour trouver les blocks défectueux. Si de tels blocks sont trouvé, ils sont ajoutés à l'inode de block défectueux. Spécifié 2 fois, le scan utilise en test rw non-destructeur.
-C fs Écris les informations sur les opérations dans le descripteur de fichier spécifié pour que la progression puisse être supervisée. Généralement utilisé par les programmes qui lance e2fsck.
-d mode debug
-D Optimise les répertoires dans le système de fichier, soit en les ré-indexant soit en triant et compressant les répertoires pour les petits répertoires, ou pour les systèmes de fichier utilisant des répertoires linéaires traditionnels.
-E extended_options Définis les options étendues. Les options suivantes sont supportées:

        ea_ver=extended_attribute_version Définis la version de blocks d'attributs étendus requis par e2fsck durant la vérification. (1 ou 2). Défaut: 2
        journal_only Ne fait que rejouer le journal si requis, mais n'effectue pas d'autres vérifications ou réparations.
        fragcheck Durant la passe 1, affiche un rapport détaillé des blocks non-contigus pour les fichiers dans le système de fichier
        discard Tente de supprimer les blocks libre et les blocks d'inode non utilisés après une vérification complète (utile pour les SSD et stockage sparses/thin-provisionned). Noter que cela ne se produit qu'à la passe 5 après vérification complète, et seulement si ne contient pas d'erreurs non récupérables
        nodiscard L'opposé de l'option discard
        readhahead_kb Utilise autant de Kio de mémoire pour précharger les métadonnée dans l'espoir de réduire l'exécution de e2fsck. Par défaut c'est la taille de 2 tables d'inodes de groupe de block (généralement 4mio)
        bmap2extent Convertis les fichiers à block-mapped en fichier extent-mapped
        fixes_only Fixe seulement les métadonnées endommagées; n'optimise pas les répertoires htree ni ne compresse les arborescence d'extent. Incompatible avec -D et -E bmap2extent.

-f Force la vérification même si le système de fichier semble correct
-F Vide les caches du périphérique avant de commencer.
-j external-journal Définis le journal externe pour ce système de fichier
-k Combiné avec -c, tout block défectueux dans la liste de blocks défectueux sont préservés, et les blocks trouvés par badblocks sont ajoutés à la liste.
-l filename Ajoute les numéros de block listés dans le fichier spécifié à la liste des blocks défectueux. Le format est le même que celui généré par badblocks.
-L filename Définis la liste des blocks défectueux comme étant la liste spécifié dans le fichier. Identique à -l excepté que la liste courante est effacée avant.
-n  Ouvre le système de fichier en lecture-seule, et assume 'no' à toutes les questions. Ne peut pas être spécifié avec -p ou -y
-P Répare automatiquement le système de fichier, sans intervention humaire. Si e2fsck découvre un problème qui nécessite l'administrateur, affiche une description du problème et quitte avec le code 4
-t Affiche des statistiques de temps. Peut être spécifié 2 fois.
-v mode verbeux
-y Assume 'yes' à toutes les questions
-z undo_file Avant d'écraser un block, écris son contenu dans le fichier d'undo.

Codes de sortie

0 Pas d'erreurs
1 Erreurs corrigées
2 Erreurs corrigées, le système devrait être redémarré
4 Des erreurs restent à corriger
8 Erreur opérationnel
16 Erreur d'utilisation ou de syntaxe
21 e2fsck a été annulé par l'utilisateur
128 Erreur de librairie partagée

Signaux

SIGUSR1 Force à démarrer en affichant une barre de progression ou en émettant des informations de progression.
SIGUSR2 Force à stopper l'affichage de progression
^
04 novembre 2016

htmlpdflatexmanmd




e2fsck.conf

e2fsck.conf

Fichier de configuration pour e2fsck

e2fsck.conf utilise le format INI:
[section1]
    tag1 = value_a
    tag1 = value_b
    tag2 = value_c
    
[section 2]
    tag3 = {
        subtag1 = subtag_value_a
        subtag1 = subtag_value_b
        subtag2 = subtag_value_c
    }
    tag1 = value_d
    tag2 = value_e
}

[options] Contient les paramètres de configuration générales pour e2fsck
[problems] Permet de reconfigurer la gestion des inconsistance du système de fichier
[scratch_files] Contrôle l'utilisation de fichiers scratch pour réduire la mémoire nécessaire.

[options]

allow_cancellation (bool) autorise l'annulation par l'utilisateur avec ^C, et si le système de fichier ne contient pas d'erreus, e2fsck quitte avec le code 0 au lieu de 32. Défaut: false
accept_time_fudge (bool) Permet de truquer le temps du superblock de 24 heures pour palier au problème de Windows utilisant l'heure locale au lieu du temps UTC.
broken_system_clock (bool) e2fsck assume que l'horloge système est correct. De plus, de nombreux programmes système font de même. À true, permet d'éviter les vérifications basées sur le temps.
buggy_init_scripts (bool) contrôle si e2fsck efface le flage test_fs si ext4 est disponible. Défaut: true
defer_check_on_battery (boo) Contrôle si l'interval entre les vérification de système de fichier (soit basé sur le temps ou le nombre de montage) doivent être doublés si le système fonctionne sur batterie. Défaut: true.
indexed_dir_slack_percentage Quand e2fsck repack un répentoire indexé, il réserve un pourcentage d'espace vide dans chaque leaf node pour que de nouvelles entrées puissent être ajoutées sans splitter le leaf node. Défaut: 20%
log_dir Si log_filename contient un chemin relatif, le fichier de log sera placé dans ce répertoire nommé par log_dir
log_dir_fallback Contient un répertoire alternatif à utiliser si log_dir n'est pas disponible ou non écrivable
log_dir_wait (boot) à true, si log_dir ou log_dir_fallback ne sont pas disponibles ou non écrivable, e2fsck sauve la sortie en mémoire, et un processus enfant test périodiquement pour voir si le répertoire le log devient disponible après la séquence de boot
log_filename Spécifie le nom de fichier où copier la sortie de e2fsck
max_count_problems nombre maximum de problème d'un type particulier reporté sur stdout.
readahead_mem_pct % de mémoire à tenter de lire dans les blocks de métadonnées avant le principal thread e2fsck. devrait réduire de temps de traitement.
readahead_kb Quantité de mémoire à lire dans les blocks de métadonnées en avance. 0 désactive le readhead. Généralement 4Mio
report_features (bool) à true, e2fsck affiche les fonctionnalité du système de fichier dans son reporting verbeux
report_time (bool) à true, e2fsck se lance comme avec -tt
report_verbose (boo) à true, e2fsck se lance comme avec -v

[problems]

   Chaque tag dans cette section nomme un code problème spécifié avec '0x'. La valeur du tag est une sous-section où les paramètres remplacent le traitement par défaut. Noter que des paramètres inappropriés peuvent empêcher e2fsck de fonctionner correctement. Dans chaque sous-section, les tags suivants peuvent être utilisés

description Description à afficher
preen_ok (bool) contrôle si ce problème devrait être fixé automatiquement en mode preen (-p).
max_count remplace max_count_problems pour ce problème
no_ok (bool) spécifie si le système de fichier sera marqué comme inconsistant si l'utilisateur refuse de fixer le problème.
no_default (bool) indique que la réponse par défaut pour ce problème devrait être 'no'.
preen_nomessage (bool) contrôle si la description pour ce problème devrait être supprimé quand e2fsck est lancé en mode preen (-p).
no_nomsg (bool) contrôle si la description pour ce problème devrait être supprimé quand un problème est forcé à ne pas être fixé soit à cause de l'option -n ou parce que force_no est mis.
force_no (bool) à true, ne fixe jamais un problème. Écrase l'option -y.

[scratch_files]

directory Si le répertoire nommé par cette relation existe et est accessible en écriture, e2fsck tente d'utiliser ce répertoire pour stocker les fichiers scratch au lieu d'utiliser les structures en mémoire
numdirs_threshold Définis, les structures de donnée en mémoire sont utilisées si le nombre de répertoire dans le système de fichier est inférieur à ce nombre.
dirinfo (bool) Contrôle si le répertoire de fichiers schatch est utilisé au lieu des structures de données en mémoire pour les informations de répertoire. Défaut: true
icount (bool) Contrôle si le répertoire de fichiers scratch est utilisé au lieu des structures de données en mémoire en traquant les compteurs d'inode. Défaut: true

Logging

   e2fsck a des facilités pour sauver les informations dans un répertoire pour que l'administrateur puisse visualiser sa sortie. Cela permet de capturer des informations un preen, ou de garder une trace des opérations. Cette facilité est contrôlée par log_filename, log_dir, log_dir_fallback et log_dir_wait. Le fichier dans log_filename peut contenir les expressions suivantes qui sont étendues:

%d Jour du mois
%D date courante (%Y%m%d)
%h Nom d'hôte
%H heure (00..23)
%N Nom du périphérique block contenant le système de fichier, sans le chemin.
%p pid du processus e2fsck
%s Heure en seconde depuis epoch
%S secondes (00..59)
%T Heure courante (%H%M%S)
%u Nom de l'utilisateur qui a lancé e2fsck
%U n'étend rien, mais signal que les expressions de date et heure qui suivent devraient être exprimées en UTC.
%y Année (00.99)
%Y Année sur 4 chiffre.

Exemples

Cet exemple empêche e2fsck d'annuler durant le processus de boot quand un système de fichier contient des fichiers orphelins. Cela n'est pas toujours une bonne idée, vu que les fichiers critiques qui sont nécessaire pour la sécurité du système pourraient potentiellement finir dans lost+found, et démarrer le système sans avoir de vérification administrateur peut être dangereux.
[problems]
    0x040002 = {
        preen_ok = true
        description = "@u @i %i. "
    }

L'exemple suivant force e2fsck à logger dans le répertoire /var/log/e2fsck, avec un nom de fichier qui contient le nom du périphérique, nom d'hôte, date et heure. (ex: e2fsck-sda3.server.INFO.20120314-112142). Si le répertoire contenant /var/log est localisé dans le système de fichier racine qui est initialement monté en lecture seule, la sortie est conservée en mémoire et écris une fois le système de fichier remonté en rw. Pour éviter trop de détails à écrire dans la console série (ce qui peut ralentir la séquence de boot), seulement 16 instances de chaque type de problèmes sont affichés.
[options]
    max_count_problems = 16
    log_dir = /var/log/e2fsck
    log_filename = e2fsck-%N.%h.INFO.%D-%T
    log_dir_wait = true

Notes

   Les codes problème peuvent être trouvés dans 'e2fsck/problem.h'. Utiliser 'egrep -B1 -ri "0x[0-9]{5}" e2fsck/problem.h"'
^
02 novembre 2016

htmlpdflatexmanmd




e2image

e2image

Sauvegarder les métadonnées critique d'un système de fichier ext2/3/4 dans un fichier

   e2image sauvegarde les métadonnées de système de fichier ext2/3/4 critique dans un fichier. Ce fichier est examiné par dumpe2fs et debugfs, en utilisant l'option -i. Celà permet d'assister un expert dans la récupération catastrophique des systèmes de fichier corrompus. Dans le future, e2fsck sera amélioré pour être capable d'utiliser le fichier image pour aider à récupérer un système de fichier endommagé.

   C'est une très bonne idée de créer des fichiers image de tous les systèmes de fichier dans un système et de sauver le layout de partition (qui est généré avec fdisk -l) à intervals réguliers. Au boot, et/ou chaque semaine ou autre. Li fichier image devrait être stocké dans un autre système de fichier pour s'assurer que ces données sont accessibles.

   Pour sauver de l'espace disque, e2image créé le fichier image comme fichier sparse, ou au format QCOW2. La taille d'un fichier image ext2 dépend principalement de la taille du système de fichier et du nombre d'inode utilisés. Pour un système de fichier de 10Gio avec 200000 inodes utilisé sur 1,2 millions d'inodes, le fichier image fera environ 35Mio; un système de fichier de 4Gio avec 15000 inodes utilisés sur 550000, le fichier image fera environ 3Mio. Les fichiers images sont compressibles, un fichier image de 35 Mio sera compressé à 3 ou 4 Mio.

Restaurer les métadonnées de système de fichier en utilisant un fichier image

   L'option -I de e2image permet d'installer les métadonnées stockées dans le fichier image sur le périphérique. Il peut être utilisé pour restaurer les métadonnées dans des situations d'urgence. Attention, si le système de fichier a changé depuis la sauvegarde les données seront perdues.

Fichiers image raw

   l'option -r créé un fichier image brute au lieu d'un fichier image normal. Un fichier image raw diffère d'un fichier image normal de 2 manière. D'abord, les métadonnées du système de fichier est placé dans la bonne position pour que e2fsck, dumpe2fs, debugfs, etc. puis lancer directement l'image raw. Pour minimiser la quantité d'espace disque consommée par un fichie image raw le fichier est créé comme fichier sparse. Ensuite, l'image raw inclus également des blocks indirects et les blocks répertoire, que l'image normale n'a pas.

Fichiers image qcow2

   L'option -Q créé un fichier image qcow2. ce format contient toutes les informations de l'image raw, cependant il n'est pas sparse. l'image qcow2 minimise la quantité d'espace disque en stockant les données dans un format spécial en packant les données ensemble.

Inclure des données

   Normalement, e2image inclus seulement des métadonnées de système de fichier, pas des données de fichier réguliers. L'option -a permet d'incluse toutes les données. Cela donne une image qui est utilisable pour cloner tout le système de fichier. Noter que cette option ne fonctionne seulement avec les format raw et qcow2.

Offset

   Normalement un système de fichier commence au début d'une partition et e2image est lancé dans cette partition. En travaillant avec des fichiers image, il n'y a pas d'option pour utiliser un périphérique partition, donc il est possible de spécifier l'offset du début du système de fichier directement avec l'option -o. Similairement -O spécifie l'offset qui devrait être recherché dans la destination avant d'écrire le système de fichier.

Par exemple, avec une image dd d'un disque qui contient un système de fichier ext2 dans une partition commençant à 1Mio, on peut cloner ce système de fichier avec:
e2image -aro 1048576 img /dev/sda1
On peut cloner un système de fichier dans un fichier image en laissant le premier Mio pour une table de partition:
e2image -arO 1048576 /dev/sda1 img
^
02 novembre 2016

htmlpdflatexmanmd




e2label

e2label

Changer le label d'un système de fichier ext2/3/4

   e2label affiche ou change le label d'un système de fichier. Si un label n'est pas spécifié après le périphérique, affice le label courant, sinon le change. Les labels ext2 ne peuvent pas dépasser 16 caractères, au delà e2label tronque le nom et affiche un warning.

^
01 novembre 2016

htmlpdflatexmanmd




e2undo

e2undo

Rejouer un log undo pour un système de fichier ext2/3/4

OPTIONS

-f Normalement, e2undo vérifie le superblock du système de fichier pour s'assurer que le log undo correspond. -f désactive cette vérification
-n  Mode test, n'écris rien dans le système de fichier
-o offset offset du système de fichier en octet depuis le début du périphérique.
-v Affiche les blocks qui sont rejoués.
^
02 novembre 2016

htmlpdflatexmanmd




e4crypt

e4crypt

Utilitaire de chiffrement de système de fichier ext4

Commandes

e4crypt add_key -S [ -k keyring ] [-v] [-q] [ path ... ] Demande à l'utilisateur une passphrase et l'insert dans le keyring spécifié. Si aucun keyring n'est donné, e4crypt utilise le keyring de session s'il existe ou le keyring de session utilisateur. Si un ou plusieurs répertoires sont spécifié, e4crypt tente de définir la stratégie de ces répertoires pour utiliser la clé.
e4crypt get_policy path ... Affiche la stratégie pour les répertoires spécifiés
e4crypt new_session Donne au processus invoquant un nouveau keyring de session, en supprimant l'ancien
e4crypt set_policy policy path ... Définis la stratégie pour les répertoires spécifiés. Tous les répertoires doivent être vide pour définis la stratégie. Si un répertoire a déjà une stratégie établie, e4crypt valide que la stratégie match. Un stratégie est un identifiant de clé de chiffrement consistant de 16 caractères.
^
01 novembre 2016

htmlpdflatexmanmd




e4defrag

e4defrag

Défragmenter un système de fichier ext4

   e4defrag réduit la fragmentation de fichier basé sur extent. La cible est un fichier régulier, un répertoire, ou un périphérique qui est monté en ext4.

OPTIONS

-c Récupérer le compteur de fragmentation courant et un compteur de fragmentation idéal, et calcule le score de fragmentation. Si spécifié, la défragmentation n'est pas effectuée
-v mode verbeux

Notes

   e4defrag ne supporte pas les fichier swap, les fichiers dans lost+found, et les fichiers alloués dans des blocks indirect. Quand la cible est un périphérique ou un point de montage, e4defrag de défragmente pas les fichiers dans les points de montages des autre périphériques. Il est sûre de lancer e4defrag sur un fichier activement utilisé par une autre application. Vu que le contenu des blocks du fichier sont copiés en utilisant le cache de page, cela peut améliorer les performance pour e4defrag et l'application dûs à la contention dans la mémoire système et la bande passante du disque.
^
05 juillet 2010

htmlpdflatexmanmd




echo

echo

Écrit chaque chaîne donnée sur la sortie standard, avec un espace entre chaque et une nouvelle ligne après la dernière

OPTIONS

-n  N'ajoute pas de newline à la fin
-E  désactive l'interprétation des caractères d'échappement
-e  authorise l'interprétation des caractères d'échappement suivant:

        \a alerte
        \b BACKSPACE
        \c n'affiche pas la suite
        \f form feed
        \n NEWLINE
        \r retour charriot
        \t tabulation horizontale
        \v taulation verticale
        \\ \
        \ONNN La valeur 9-bits de numéro octal NNN (0 à 3 chiffres)
        \NNN La valeur 9-bits de numéro octal NNN (1 à 3 chiffres)
        \xHH La valeur 9-bits de numéro hexa HH (1 à 2 chiffres)

   si POSIXLY_CORRECT est définit, et que le premier argument n'est pas -n, traite tous les argument comme chaine.
^
28 août 2015

htmlpdflatexmanmd




edquota

edquota

Éditer les quotas utilisateurs

   edquota est un éditeur de quota. Un ou plusieurs utilisateurs ou groupe (ou UID/GID) peuvent être spécifiés sur la ligne de commande. Pour chacun, un fichier temporaire est créé avec une représentation ASCII des quotas disques courant pour cet utilisateur ou groupe. Les quotas peuvent ainsi être modifiés, ajoutés, etc.

   Les utilisateurs sont autorisés à dépasser leur limite soft pour une période de grâce qui peut être spécifié par système de fichier. Une fois la période de grâce expirée, la limite soft est forcée comme limite hard.

   Un fois l'éditeur terminé, edquota lit le fichier temporaire et modifie les fichiers de quota binaire pour refléter les changements. L'éditeur invoqué est soit EDITOR, soit VISUAL. Seul root peut éditer les quotas.

OPTIONS

-r, --remote Édite également les quota non-locaux en utilisant rpc.rquotad sur le serveur distant. Cette option est disponible seulement si les outils de quotas ont été compilés avec le support sur RPC.
-m, --no-mixed-pathnames Actuellement, les chemins des points de montage NFS4 sont envoyés sans le dernier '/'. rpc.rquotad l'utilise pour reconnaître les montages NFS4. Cette option envoie toujours des chemin avec le dernier '/'.
-u, --user Édite les quotas utilisateur
-g, --group Édite les quotas de groupe
-p, --prototype=protoname Duplique les quotas de l'utilisateur de prototype spécifié pour chaque utilisateur spécifié. C'est le mécanisme normal utilisé pour initialiser les quotas pour les utilisateurs et les groupes.
-F, --format=format-name Éite les quotas au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-f, --filesystem filesystem Effectue les opérations spécifiée seulement pour le système de fichier spécifié.
-t, --edit-period Édite les temps de limites soft pour chaque système de fichier.
-T, --edit-times Édite le temps pour pour la softlimit. peut être 'unset' ou un nombre et une unité.
^
27 mai 2016

htmlpdflatexmanmd




efi-readvar

efi-readvar

Outil pour afficher les variables sécurisés

   Sans arguments, affiche la base de variables et étend le contenu des hash et des certificats x509. Peut être restreint à des variables spécifiques et des signatures spécifiques dans les variables. Noter que les listes de signatures EFI sont numérotées à partir de 0 et peuvent contenir un ou plusieurs entrées également numérotées à partir de 0, donc 0-0 représente la première entrée de la liste de signature 0.

OPTIONS

-v ‹var› Liste seulement le contenu de ‹var›
-s ‹list›[-‹entry›] Liste seulement la liste de signature donnée
-o ‹file› Sort les les listes de signature demandées dans le fichier

Exemples

voir toutes les variables:
efi-readvars
Voir la seconde entrée de la liste de signature 1 pour la variable db:
efi-readvars -v db -s 1-1
Voir toutes les entrées de la liste de signature 0 pour le KEK
efi-readvars -v KEK -s 0
^
27 mai 2016

htmlpdflatexmanmd




efi-updatevar

efi-updatevar

Outil de mise à jours des variables

OPTIONS

-a Ajoute une valeur à une variable au lieu de la remplacer
Utiliser la liste de signature EFI au lieu de mises à jours signées
-b «binfile› Ajoute le hash du fichier spécifié à la liste de signature
-f ‹file› Ajoute ou remplace le fichier de clé (.esl ou .auth) à ‹var›
-c ‹file› Ajoute ou remplace le certificat x509 à ‹var›
-g ‹guid› guid optionnel pour le certificat x509
-k ‹key› Fichier de clé secrète pour autoriser les mises à jours en User Mode
-d ‹list›[-‹entry›] Supprime la liste de signature spécifiée, ou simplement une entrée dans la liste

Exemples

Supposons vos propres clé PK.auth et noPK.auth, les sortir du système en mode user:
efi-updatevar -f noPK.auth PK
puis les replacer:
efi-updatevar -f PK.auth PK
Ajouter le hash de bin.efi à db en mode setup:
efi-updatevar -b bin.efi db
Ajouter une liste de signature EFI à db en mode setup:
efi-updatevar -a -e append.esl db
Ajouter votre propre clé KEK en mode user:
efi-updatevar -a -c KEK.crt -k PK.key KEK
Ajouter le certificat DB.crt à db en mode user:
efi-updatevar -a -c DB.crt -k KEK.key db
Remplacer l'ancienne clé de plateforme avec une nouvelle:
efi-updatevar -c newPK.crt -k PK.key db
Supprimer la clé privée, basculant du mode user au mode setup:
efi-updatevar -d 0 -k PK.key PK
Et place la clé privée de nouveau (en mode setup):
efi-updatevar -c PK.crt -k PK.key PK
^
31 mars 2016

htmlpdflatexmanmd




entr

entr

Lancer des commandes arbitraires quand des fichiers changent

   Une liste de fichiers fournis sur l'entrée standard et un programe est exécuté quand ils changent

OPTIONS

-c Exécute /usr/bin/clear avant d'invoquer le programme spécifié
-d Suit les répertoires des fichiers réguliers fournis en entrée et qui si un nouveau fichier est ajouté.
-p Retarde la première exécution du programme jusqu'à ce qu'un fichier soit modifié
-l Recharge un process enfant persistant.

   La première occurrence de /_ sur la ligne de commande sera remplacée avec le chemin absolu du premier fichier créé qui a été modifié. Si l'option restart est utilisée le premier fichier qui match est traité

Exemples

Reconstruire un projet si le fichier source change, limitant la sortie aux 20 premières lignes
find src/ | entr sh -c 'make | head -n 20'
Lancer et recharger automatiquement un serveur node.js
ls *.js | entr -r node app.js
Effacer l'écran et lancer une requête après que le script SQL soit mis à jours:
echo my.sql | entr -p psql -f /_
Reconstruire le projet si un fichier sources est modifié ou ajouté dans le répertoire src/
while sleep 1; do ls src/*.rb | entr -d rake; done
^
15 juillet 2010

htmlpdflatexmanmd




env

env

Lance une commande avec un environnement modifié.

   env lance une commande avec un environnement modifié. La première opérande qui ne contient pas le caractère '=' spécifie le programme à invoquer.

OPTIONS

-u NAME, --unset=NAME Supprime la variable spécifée de l'environnement.
-, -i, --ignore-environment démarre avec un environnement vide.
NAME=VALUE définir une variable
^
10 septembre 2011

htmlpdflatexmanmd




/etc/fstab

/etc/fstab

Informations statiques sur les systèmes de fichier

   Le fichier fstab contient des informations sur les divers systèmes de fichiers du système. Chaque système de fichier est décrit sur une ligne séparée, les champs sont séparés par des espaces ou des tabulations. Les lignes commençant par un '#' sont des commentaires. L'ordre des enregistrements dans fstab est important parce que fsck, mount et umount tiennent compte de cet ordre.

   Le premier champ, (fs_spec), décrit le périphérique bloc ou le système de fichier distant à monter. Pour un montage ordinaire il va maintenir un node de périphérique block (créé par mknod) pour le périphérique à monter, comme /dev/cdrom ou /dev/sdb7. Pour les montages NFS, on aura toujours ‹host›:‹dir›. Pour procfs, utiliser proc.

   Au lieu de donner le périphérique explicitement, on peut indiquer le système de fichier (ext2 ou xfs) qui est monté par son UUID ou le label du volume (cf: e2label ou xfs_admin), écrire LABEL=‹label› ou UUID=‹UUID›. Cela va rendre le système plus robuste; ajouter ou supprimer un disque SCSI change le nom du périphérique mais pas son label.

   Le second champ, (fs_file), décrit le point de montage pour le système de fichier. Pour les partitions swap, ce champ devrait être spécifié par 'none'. Si le nom du point de montage contient des espaces, ils peuvent être échappés avec '\040'.

   Le Troisième champ (fs_vfstype), décrit le type de système de fichier. Linux supporte de nombreux systèmes de fichiers, tels que adfs, affs, autofs, coda, coherent, cramfs, devfs, efs, ext2, ext3, hfs, hpfs, iso9660, jfs, minix, msdos, ncpfs, nfs, ntfs, proc, qnx4, reiserfs, romfs, smbfs, sysv, tmpfs, uff, ufs, umsdos, vfat, xenix, xfs, et d'autres. Pour lister les systèmes de fichiers supportés, consulter /proc/filesystems. Une entrée swap dénote une partition ou un fichier utilisé pour le swap. Une ligne est ignorée si l'entrée est 'ignore'. C'est utile pour montrer les partitions du disque qui ne sont actuellement pas utilisés. Une entrée none est utile pour lier ou déplacer des montages.

   Le quatrième champ, (fs_mntops), décrit les options de montage associées avec le système de fichier. Elles sont spécifiées sous la forme d'une liste séparées par une ','. Ce champ contient au moins le type de montage, plus des options additionnelles appropriées au type de système de fichier. Les options communes à tous les systèmes de fichier sont:

noauto ne pas monter quand mount -a est invoqué
user Autorise un utilisateur le monter.
owner Autorise le propriétaire du périphérique de le monter
comment Utilisé par les programmes de gestion fstab.

   Le cinquième champ (fs_freq) est utilisé par dump pour déterminer quel système de fichier a besoin d'être dumpé. Si ce champ n'est pas présent, une valeur 0 est retournée et dump assumera que le système de fichier n'a pas besoin d'être dumpé.

   Le sixième champ, (fs_passno), est utilisé pour fsck pour déterminer l'ordre dans lequel il vérifie les systèmes de fichiers au reboot. '/' devrait avoir la valeur 1, et les autres systèmes de fichiers, 2. Les systèmes de fichiers dans un lecteur seront vérifiés séquentiellement, mais des systèmes de fichiers sur des lecteurs différents seront vérifiés simultanément. Si ce champ n'est pas présent ou vaut 0, une valeur 0 est retournée et fsck assume que le système de fichier n'as pas besoin d'être vérifié.

   La manière 'propre' de lire les enregistrements de fstab est d'utiliser les routines getmntent(3)

^
14 août 2011

htmlpdflatexmanmd




/etc/group

/etc/group

Informations sur les groupes du système

   Il est sous la forme: group_name:password:GID:user_list

group_name le nom du groupe
password le mot de passe chiffré du groupe. Si ce champ est vide, aucun mot de passe n'est défini
GID L'identifiant numérique unique du groupe
user_list une liste d'utilisateurs qui sont membres de ce groupe, séparés par une virgule.

^
14 août 2011

htmlpdflatexmanmd




/etc/gshadow

/etc/gshadow

Informations cachées sur les groupes du système

   Ce fichier ne doit par être accessible en lecture par les utilisateurs normaux afin de maintenir la sécurité des mots de passe. Chaque ligne de ce fichier contient les champs suivant, séparés par ':'

nom du groupe Doit être un nom de groupe valide, qui existe sur le système.
mot de passe mot de passe chiffré du groupe. Le mot de passe du groupe est utilisé quand un utilisateur qui n'est pas membre du groupe veut avoir les permissions de ce groupe. Ce mot de passe remplace tout mot de passe définis dans /etc/group
administrateurs Liste d'utilisateurs, séparés par des ','. Les administrateurs peuvent changer le mot de passe ou les membres du groupe.
membres Liste d'utilisateurs, séparés par des ','. devrait être identique à la liste des utilisateurs dans /etc/group.

^
31 mars 2016

htmlpdflatexmanmd




/etc/incron.conf

/etc/incron.conf

Fichier de configuration pour incron

   Ce fichier contient les paramètres par défaut pour incrond.

system_table_dir Ce répertoire contient les tables système. Défaut: /etc/incron.d
user_table_dir Ce répertoire contient les tables utilisateur. Défaut: /var/spool/incron
allowed_users Ce fichier contient les utilisateurs autorisés à utiliser incron. Défaut: /etc/incron.allow
denied_users Ce fichier contient les utilisateurs non autorisés à utiliser incron. Défaut: /etc/incron.deny
lockfile_dir Ce répertoire est utilisé pour créer un lock pour éviter de lancer plusieurs instances de incrond. Défaut: /var/run
editor Nom de l'éditeur à utiliser pour éditer les tables.

^
29 octobre 2011

htmlpdflatexmanmd




/etc/login.defs

/etc/login.defs

Fichier de configuration de la suite des mots de passe cachés pour le système

OPTIONS

CHFN_RESTRICT (string) Spécifie quelles valeur dans le gecos de /etc/passwd peut être changé par des utilisateurs normaux en utilisant chfn peut être un combinaison des lettre f, r, w, h pour respectivement, le nom complet, numéro de salle, téléphone du bureau et télephone personnel. yes est équivalent à rwh et no vaut frwh. Non spécifié, seul root peut effectuer ces changements.
CONSOLE_GROUPS (string) liste de groupes à rajouter à l'utilisateur lors d'une connexion sur une conole (déterminé par CONSOLE).
CREATE_HOME (bool) indique si un répertoire personnel doit être créé par défaut pour les nouveaux utilisateurs (ne s'applique pas pour les utilisateurs systèmes)
DEFAULT_HOME (bool) Indique si la connexion est permise dans '/', s'il n'est pas possible d'accéder à son home.
ENCRYPT_METHOD (string) Définis les algorithmers de chiffrement par défaut du système pour coder les mots de passe (DES (defaut), MD5, SHA256, SHA512). remplace la variable MD5_CRYPT_ENAB. N'affecte que la génération des mots de passe des groupes.
ENV_HZ (string) définis, sera utilisé pour définir la variable d'environnement HZ lorsqu'un utilisateur se connecte. doit être précédée par 'HZ='. HZ est uniquement définis lors d'une connection avec sulogin.
ENV_PATH (string) défini, sert à définir PATH. doit être précédé par PATH= (défaut : PATH=/bin :/usr/bin)
ENV_SUBPATH (string) Définis, est utilisé pour définir PATH pour root. doit être précédé par PATH= (défaut : PATH=/sbin :/bin :/usr/sbin :/usr/bin)
ERASECHAR (nb) le caractère ERASE du terminal (010 = backspace, 0177 = DEL) peut être spécifié en octal ou en hexa.
FAIL_DELAY (nb) Délai en secondes avant qu'un essaie soit permis après un échec de connexion.
FAKE_SHELL (string) définis, login exécute cet interpréteur de commande au lieu de celui définis dans /etc/passwd.
GID_MAX
GID_MIN Plage de GID utilisé pour la création des groupes normaux
HUSHLOGIN_FILE (string) définis, ce fichier peut désactiver tous les affichages habituels durant la séquence de connexion. si le nom de l'utilisateur ou le shell sont trouvés dans le fichier, le mode silencieux est activé (ou si le fichier existe dans le répertoire personnel de l'utilisateur)
KILLCHAR (nb) le caractère KILL du terminal (025 = CTRL/U). peut être spécifié en octal ou en hexa.
LOG_OK_LOGINS (bool) Activer la journalisation des connexions réussies.
LOG_UNKFAIL_ENAB (bool) Active l'affichage des noms d'utilisateurs inconnus quand les echecs de connexions sont enregistrées.
LOGIN_RETRIES (nb) nombre max de tentatives de connexions.
LOGIN_TIMEOUT (nb) temps maximum pour la connexion
MAIL_DIR (string) Répertoire des courriels.
MAIL_FILE (string) Emplacement des boites aux lettres des utilisateurs, relatif à leur répertoire personnel.
MAX_MEMBERS_PER_GROUP (nb) Nombre max de membres par entrée de groupe. (défaut 0 : pas de limite). pour limiter les lignes à 1024 caractères, utiliser 25.
MD5_CRYPT_ENAB (bool) Indique si les mots de passe doivent être cryptés en utilisant MD5.
PASS_MAX_DAYS (nb) Nb de jour de validité d'un mot de passe. après cette periode, le mot depasse doit être changé. à -1, désactive cette restriction.
PASS_MIN_DAYS (nb) Nombre minimum de jours avant lamodification du mot de passe. (-1 désactive cette restriction)
PASS_WARN_AGE (nb) nombre de jour pendatn lequel l'utilisateur recevra un avertissement que son mot depasse arrive en fin de validité.
SHA_CRYPT_MIN_ROUNDS (nb)
SHA_CRYPT_MAX_ROUNDS (nb) Quand ENCRYPT_METHOD est à SHA256 ou SHA512, celà définis le nombre de passe SHA utilisé. (défaut : 5000) doit être entre 1000 et 999999999. Si une seule des ces 2 valeur est spécifiée, elle est utilisée. N'affecte que la génération des mots de passe des groupes.
SULOG_FILE (string) définis, les activités su sont enregistrées dans ce fichier.
SU_NAME (string) si définis, le nom de la commande à afficher en utilisant 'su -'. sinon, utilise le shell courant.
SYS_GID_MAX (nb)
SYS_GID_MIN (nb) PLage de GID pour les groupes systèmes
SYS_UID_MAX (nb)
SYS_UID_MIN (nb) Plage d'UID pour les utilisateurs systèmes.
SYSLOG_SG_ENAB (bool) Autorise le syslogdes activité sg
SYSLOG_SU_ENAB (bool) Autorise le syslog des activité su, en plus du fichier sulog.
TTYGROUP (string)
TTYPERM (string) Permissions du terminal : le tty login sera possédé par le groupe TTYGROUP, et les permissions seront à TTYPERM. Par défaut, définis au groupe primaire de l'utilisateur et les permissions à 600.
TTYTYPE_FILE (string) définis, le fichier map le ligne TTY au paramètre dd'environnement TERM. Chaque ligne du fichier est dans un format du genre 'vt100 tty01'
UID_MAX (nb)
UID_MIN (nb) Plage d'UID pour la création des utilisateurs normaux.
UMASK (nb) Masque de mode de création des fichiers (défaut 022)
USERDEL_CMD (string) Commande exécutée à la suppression d'un utilisateurs.
USERGROUPS_ENAB (bool) à yes, userdel supprime le groupe de l'utilisateur s'il ne contient pas d'autres membres, et useradd créé par défaut un groupe portant le nom de l'utilisateur.

Références croisées

chfn CHFN_RESTRICT
chgpasswd ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS
chpasswd SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS
gpasswd ENCRYPT_METHOD MAX_MEMBERS_PER_GROUP MD5_CRYPT_ENAB SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS
groupadd GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP SYS_GID_MAX SYS_GID_MIN
groupdel MAX_MEMBERS_PER_GROUP
groupmems MAX_MEMBERS_PER_GROUP
groupmod MAX_MEMBERS_PER_GROUP
grpck MAX_MEMBERS_PER_GROUP
grpconv MAX_MEMBERS_PER_GROUP
grpunconv MAX_MEMBERS_PER_GROUP
login CONSOLE_GROUPS DEFAULT_HOME ERASECHAR FAIL_DELAY FAKE_SHELL HUSH_LOGIN KILLCHAR LOGIN_RETRIES LOGIN_TIMEOUT LOG_OK_LOGINS LOG_UNKFAIL_ENAB TTYGROUP TTYPERM TTYTYPE_FILE USERGROUPS_ENAB
newgrp / sg SYSLOG_SG_ENAB
newusers ENCRYPT_METHOD GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP SYS_GID_MAX MD5_CRYPT_ENAB PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE SHA_CRYPT_MAX_ROUNDS SHA_CRYPT_MIN_ROUNDS SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK
pwck PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE
pwconv PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE
su CONSOLE_GROUPS DEFAULT_HOME ENV_PATH ENV_SUBPATH SULOG_FILE SU_NAME SYSLOG_SU_ENAB
sulogin ENV_HZ
useradd CREATE_HOME GID_MAX GID_MIN MAX_MEMBERS_PER_GROUP PASS_MAX_DAYS PASS_MIN_DAYS PASS_WARN_AGE SYS_GID_MAX SYS_GID_MIN SYS_UID_MAX SYS_UID_MIN UID_MAX UID_MIN UMASK
userdel MAIL_DIR MAIL_FILE MAX_MEMBERS_PER_GROUP
^
28 mars 2016

htmlpdflatexmanmd




/etc/modprobe.d

/etc/modprobe.d, /lib/modprobe.d, /run/modprobe.d/

Configuration pour modprobe

   Parce que la commande modprobe peut ajouter ou supprimer plus d'un module, dû aux dépendances, on a besoin d'une méthode pour spécifier quelles options sont utilisée avec ces modules. Tous les fichiers *.conf dans /etc/modprobe.d permettent de spécifier les options à utiliser pour les modules. Peut aussi être utilisés pour créer des alias pour des modules, ou pour modifier le comportement de modprobe. Noter que les noms des modules et leus alias peut utiliser '-' ou '_' de manière interchangeable.

   Le format est simple : Une commande par ligne, les lignes blanche et les lignes commençant par # sont ignorés. ’\’ à la fin d’un ligne pour scinder une ligne longue en plusieurs.

Commandes

alias wildcard modulename Permet de donner un nom alternatif pour un module (ex: alias my-mod really_long_module_name) Certains modules contiennent leur propre alias (voir modinfo) utilisé si aucun alias n’est définis.
blacklist modulename indique que tous les alias interne d’un module sont ignorés.
install modulename command... Lancer cette commande au lieu d’insérer le module normalement. Peut-être une commande Shell. Cette commande sera remplacée dans le future.
options modulename option... Permet d’ajouter des options au module spécifié
remove modulename command... Identique à install mais est utilisé avec modprobe -r
softdep modulename pre: modules... post: modules... Permet de spécifier des softs ou optionnellement des dépendances de modules. Le nom du module peut être utilisé sans ces modules optionnels, mais généralement avec des fonctionnalités manquant. Par exemple, un pilote pour un stockage HBA peut nécessiter un module à charger pour utiliser ses fonctionnalités. Les modules pre et post sont des listes de nom et/ou alias d’autres modules que modprobe va tenter d’installer ou supprimer dans l’ordre avant et après le module donné. (ex: softdep c pre: a b post: d e == modprobe a b c d e). softdep a la précédence sur les modules avec les commandes install et remove avec le même module.
^
28 mars 2016

htmlpdflatexmanmd




/etc/modules

/etc/modules

Modules du kernel à charger au démarrage

   Le fichier /etc/modules contient une liste de modules, un module par ligne suivi par des paramètres optionnels. Tout ce qui suit ’#’ est considéré comme commentaire.

^
14 août 2011

htmlpdflatexmanmd




/etc/netgroup

/etc/netgroup

Informations concernant les groupes réseaux, qui sont des associations hôte/utilisateur/domaine, utilisés pour la vérification des permissions pour les accès ou montages distants.

   Chaque ligne consiste d’un nom de groupe réseau, suivi par une liste de membres, où un membre est soit un autre netgroup, soit une association (hôte,utilisateur,domaine).

   Un de ces champs peut être vide, impliquant un "*", ou peut être "-" qui indique 'aucune valeur valide'. Une machine passerelle devrait être listée sous tous les noms d’hôtes possibles par lequel il peut être reconnus:

  gateway (server,,)(server-sn,,)(server-bb,,)

  La fonction getnetgrent devrait être utilisée pour accéder à la base netgroup.

^
14 août 2011

htmlpdflatexmanmd




/etc/passwd

/etc/passwd

Information sur les comptes utilisateurs

   Ces informations consistent en 7 champs séparés par des ':'

- Nom de connexion
- mot de passe chiffré
- identifiant numérique unique
- identifiant numérique du groupe primaire
- nom complet de l'utilisateur ou champ de commentaire
- répertoire personnel
- interpréteur de commande

- Le champ du mot de passe peut être vide. Dans ce cas, aucun mot de passe n'est nécessaire pour s'authentifier avec le compte donné. Si ce champ contient 'x', alors le mot de passe chiffré se trouve dans le fichier shadow, sinon le compte n'est pas valide.
- Le champ de commentaire est utilisé par différents utilitaires système, tels que finger.
- Le champ du répertoire de travail correspond au nom du répertoire de travail initial. login utilise cette information pour définir la valeur de la variable d'environnement HOME.
- Le champ de l'interpréteur de commande correspond au nom du shell initial à exécuter. login utilise cette information pour définir la variable d'environnement SHELL. Si ce champ est vide, /bin/sh est utilisé par défaut.

^
14 août 2011

htmlpdflatexmanmd




/etc/shadow

/etc/shadow

Informations sur les mots de passe des utilisateurs

   Ce fichier ne doit pas être accessible en lecture par les utilisateurs normaux. Chaque ligne de ce fichier contient 9 champs, séparés par un ':'

- nom de connexion de l'utilisateur
- mot de passe chiffré
- date du dernier changement de mot de passe
- âge minimum du mot de passe
- âge maximum du mot de passe
- période d'avertissement de mot de passe
- période d'inactivité de mot de passe
- date de fin de validité de compte
- champ réservé

- Si le champ du mot de passe contient une chaîne qui ne peut pas être un résultat valable de crypt(3), par exemple si elle contient les caractères '!' ou '*', alors l'utilisateur ne pourra pas utiliser son mot de passe pour se connecter. Un mot de passe commençant par '!' signifie un mot de passe bloqué.
- Le champ du dernier changement de mot passe est exprimé en jours depuis le 1 janvier 1970. La valeur 0 signifie que l'utilisateur devrait changer son mot de passe la prochaine fois qu'il se connecte. Si le champ est vide, cette fonction est considéré désactivée.
- Un âge minimum de mot de passe à 0 signifie qu'il n'y a pas d'âge minimum pour changer de mot de passe.
- Si l'âge maximum du mot de passe est vide, cela signifie que le mot de passe n'expire jamais. Si la valeur est inférieure à l'âge minimum, l'utilisateur ne peut pas changer de mot de passe.
- Le champ de période d'avertissement de mot de passe spécifie le nombre de jours pendant lequel l'utilisateur est alerté que son mot de passe va expirer. Si ce champ est vide ou vaut 0, il n'y a pas de période d'alerte.
- Le champ de période d'inactivité de mot de passe spécifie le nombre de jours après qu'un mot de passe ait expiré pendant lequel le mot de passe reste valide. Après expiration, aucune connexion n'est possible. Si ce champ est vide il n'y a pas de période d'inactivité.
- La date de fin de validité de compte est exprimé en nombre de jour depuis le 1 janvier 1970. Si ce champ est vide, cela signifie que le compte n'expire jamais.

^
06 mai 2016

htmlpdflatexmanmd




ETSI TS 101 862 (2006 01)

ETSI TS 101 862 (2006 01)

Profile de certificat qualifié

   La directive du parlement européen et du conseil dans le cadre communautaire pour les signatures électroniques (1999/93/EC) définis des exigences pour un type de certificat spécifique appelé "Qualified Certificates". Ces certificats ont une importance spécifique pour l'acceptation de signatures électroniques via la partie suivante de l'article 5 (effets légal des signatures électroniques):

   Les états membre doivent s'assurer que les signatures électroniques avancées qui sont basés sur un certificat qualifié et qui sont créés par un périphérique de création de signature sécurisé:

a) satisfont les exigences légales d'une signature en relation à une donnée sous forme électronique de la même manière qu'une signature manuscrite satisfait ces exigences pour une données sous forme papier; et
b) Sont admissible comme preuve dans les procédures judiciaires

   La directive 1999/93/EC définis un certificat qualifié dans l'article 2:

  "Qualified Certificate" signifie un certificat qui répond aux exigences prévue à l'annexe I et est fournis par un fournisseur de service de certification qui répond aux exigences prévues dans l'annexe II.

Scope

   Le présent document définis un profile pour les certificats qualifiés, basé sur les définitions techniques dans la rfc3739, qui peut être utilisé par des émetteurs de certificats qualifiés comformément aux annexes I et II de la directive de signatures électronique européenne 1999/93/EC

   Ce profile de certificat qualifié et le profile de certificat qualifié de l'IETF (rfc3739) adressent les certificats qualifié dans différents contextes et utilisent donc le terme Certificat Qualifié avec des significations légèrement différentes. Le profile IETF utilise ce terme dans un contexte universelle indépendamment des exigences légales. Le profile de ce document utilise ce terme pour décrire un certificat qualifié tel que définis par la directive 1999/93/EC.

Profile de certificat

   Ce profile est basé sur le profile de la rfc3739, qui est basé sur la rfc3280 et X.509v3.

Champ Issuer

   Le nom de l'emetteur contenu dans le champ issuer (comme définis dans la clause 3.1.1 dans la rfc3739) doit contenir un nom de pays dans l'attribut countryName. Le pays spécifié doit être le pays dans lequel l'emetteur du certificat est établis.

Déclarations de certificat qualifié

   Ce profile définis des déclarations individuels à utiliser avec l'extension qCStatements, définis dans la rfc3739.

   Quand cette extension est marquée critique, cela signifie que toute déclaration inclue dans l'extension sont considérés critique. Des déclaration suivantes sonft définis dans ce profile:

- Déclaration affirmant que les certificats sont émis comme certificats qualifiés
- Déclaration concernant les limites sur la valeur de transaction pour lequel le certificat peut être émis.
- Déclaration indiquant la durée de période de rétention durant laquelle les informations d'enregistrement sont archivés
- Déclaration affirmant que la clé privée associée avec la clé publique dans le certificat réside dans un périphérique de création de signature sécurisé

   Déclaration affirmant que les certificats sont émis comme certificats qualifiés

La déclaration définis dans cette clause contient un identifiant de la déclaration créé par la CA, statuant que ce certificat est émis comme certificat qualifié en accord avec l'annexe I et II de la directive 1999/93/EC, tel qu'implémenté dans la loi du pays où la CA est établie:
esi4-qcStatement-1 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcCompliance }
-- Cette déclaration est une déclaration par l'émetteur que ce certificat est émis comme certificat qualifié en accord avec l'annexe I et II de la Directive 1999/93/EC du parlement européen et du conseil du 13 Décembre 1999 dans un cadre communautaire pour les signatures électronique, tel qu'implémenté dans la loi du pays spécifié dans le champ issuer de ce certificat.
id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 }

   Déclaration concernant les limites sur la valeur de transaction pour lequel le certificat peut être émis

   Les limites dans la valeur de transactions, pour lequel le certificat peut être utilisé, peut être indiqué en utilisant la déclaration définie dans cette clause. Les codes sont définis dans ISO 4217. Cette déclaration optionnelle contient:

- Un identifiant pour cette déclaration
- Une valeur monétaire exprimant la limite dans la valeur de transactions


esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED BY id-etsi-qcs-QcLimitValue }
-- Cette déclaration est une déclaration par l'emetteur qui impose une limitation dans la valeur de transaction pour laquelle ce certificat peut être utilisé pour la quantité spécifiée (MonetaryValue), en accord avec la directive 1999/93/EC du parlement européen et du conseil du 13 Décembre 1999 dans un cadre communautaire pour les signatures électronique, tel qu'implémenté dans la loi du pays spécifié dans le champ issuer de ce certificat.
QcEuLimitValue ::= MonetaryValue
    
MonetaryValue::= SEQUENCE {
    currency Iso4217CurrencyCode,
    amount INTEGER,
    exponent INTEGER}
    -- value = amount addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo 10^exponent
Iso4217CurrencyCode ::= CHOICE {
    alphabetic PrintableString (SIZE (3)), -- Recommended
    numeric INTEGER (1..999) }
    -- Alphabetic or numeric currency code as defined in ISO 4217
    -- It is recommended that the Alphabetic form is used
id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 }

   Déclaration indiquant la durée de période de rétention

   La dépendance des certificats qualifiés peuvent dépendre de l'existence d'informations externes retenus par la CA. Un aspect significatif est que la directive 1999/93/EC permet des formes de nom dans les certificats, tel que les pseudonyms, qui peuvent exiger l'assistance de la CA pour une autorité d'enregistrement de nom, pour identifier la personne physique associée à l'identité en cat de dispute. Cette déclaration optionnelle contient:

- Un identifiant de cette déclaration
- Une période de rétention pour les informations matérielles pertinentes pour l'utilisation et la confiance du certificat, exprimé en nombre d'années après da date d'expiration du certificat.



esi4-qcStatement-3 QC-STATEMENT ::= { SYNTAX QcEuRetentionPeriod IDENTIFIED BY id-etsi-qcs-QcRetentionPeriod }
-- Cette déclaration est une déclaration par l'émetteur garantis que pour un certificat où cette déclaration apparaît cette information matérielle pertinente pour l'utilisation et la confiance du certificat seront archivés et peuvent être disponibles au delà de la fin de la période de validité du certificat pour le nombre d'années indiqué dans cette déclaration.
QcEuRetentionPeriod ::= INTEGER
    
id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 }

   Déclaration affirmant que la clé privée associée avec la clé publique dans le certificat réside dans un SSCD

Les autoritéd de certification affirmant émettre des certificats où la clé privée liée à la clé publique certifiée résidant dans un SSCD peuvent utiliser cette déclaration optionnelle. Cette déclaration contient un identifiant de cette déclaration, créé par la CA, statuant que la clé privée associée avec la clé publique dans le certificat est stockée dans un SSCD en accord avec l'annexe III de la directive 1999/93/EC, tel qu'implémenté dans la loi du pays où la CA est établie.
esi4-qcStatement-4 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcSSCD }
id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 }

Indication de certificat qualifié

   Les 2 techniques suivantes peuvent être utilisées pour déclarer qu'un certificat est émis comme certificat qualifié:

1) en identifiant une stratégie de certificat dans les extensions de stratégie de certificat, comme définis dans la clause 4.2.1.5 de la rfc3280, exprimant clairement que l'émetteur a émis intentionnellement le certificat comme certificat qualifié et que l'émetteur affirme être conforme avec les annexes I et II de la directive; ou
2) en incluant une extension de déclaration de certificat qualifié avec une déclaration si4-qcStatement-1 tel que définis dans la clause 5.2.1 de ce profile.

   Les certificats qualifiés conformes avec le présent document devraient inclure une stratégie en accord avec 1). Les certificats qualifiés conformes avec le présent document émis jusqu'au 30 juin 2005 devraient contenir une déclaration en accord avec 2). Ceux émis après cette date doivent contenir une déclaration en accord avec 2). Les certificats qualifiés conformes avec le présent document doivent dans tous les cas utiliser au moins une des techniques ci-dessus.

Annexe I de la directive

Pour chaque exigence dans la directive 1999/93/EC:
L'implémentation en accord avec ce profile et les standards sous-jacents

(a) une indication que le certificat est émis comme certificat qualifié:
inclusion de la stratégie de certificat définissant cette propriété et/ou une déclaration explicite définissant cette propriété tel que définis dans la clause 5.3
(b) L'identification du fournisseur de service de certification et l'état dans lequel il est établis:
L'information stockée dans le champ Issuer tel que définis dans la clause 3.1.1 de la rfc3739
(c) Le nom du signataire ou un pseudonyme, qui doit être identifié:
Tel que définis dans la clause 3.1.2 de la rfc3739
(d) Fournir un attribut spécifique du signataire si nécessaire, en fonction du but pour lequel le certificat est prévu:
Tel que définis dans les clauses 3.1.2 et 3.2.1 de la rfc3739
(e) Données de vérification de signature qui correspond à la données de création de signature sous le contrôle du signataire:
La clé publique avec les informations associées listées dans l'annexe I et II
(f) Une indication du début et de la fin de la période de validité du certificat:
La période de validité conforme aux recommandations X.509 et la rfc3280
(g) le code de l'identité du certificat:
Le numéro de série du certificat conforme aux recommandations X.509 et la rfc3280
(h) La signature électronique avancée du fournisseur de service de certification l'ayant émis:
La signature numérique de l'émetteur conforme aux recommandations X.509 et la rfc3280
(i) Les limitation du périmètre d'utilisation du certificat, si applicable:
Fournis dans l'extension de stratégies de certificat, l'extension d'utilisation de clé, et l'extension d'utilisation de clé étendue conforme aux recommandations X.509 et la rfc3280
(j) Les limites de valeur de transaction pour lesquelles le certificat peut être utilisé, si applicable:
En accord avec la clause 5.2.2

Annexe II de la directive

   L'annexe II contient les exigences pour les fournisseurs de services de certification émettant des certificats qualifiés, qui généralement n'impactent pas le format de certificat. Certaines fonctions spécifiues des certificats qualifiés, comme listé ci-dessous, peuvent cependant être utilisés pour supporter ces exigences:

Exigences dans l'annexe II de la directive 1999/93/EC:
Mécanisme supporté

l'exigences b) inclue une exigence d'un service de révocation immédiat et sécurisé:
L'extension de point de distribution de crl et l'accès aux informations de l'autorité conforme à la rfc3280 peuvent contenir les informations utilisées pour fournir et identifier ces services
L'exigence i) inclus une exigence sur la rétension des informations pour une période de temps appropriés:
La clause 5.2.3 définis une déclaration qui peut être utilisée pour communiquer la période de rétension aux tiers de confiance
L'exigence k) status que la partie pertinente des termes et conditions au regard de l'utilisation du certificat doit être disponible à la demande de tiers de confiance validant le certificat:
Une stratégie de certificat dans l'extension de stratégie de certificat peut contenir un qualifiant de type CPSurl conforme à la rfc3280, pointant vers l'emplacement où cette information peut être obtenue.
^
22 janvier 2014

htmlpdflatexmanmd




evdev

evdev

Pilote d'entrée générique pour Linux. Il gère tous les périphériques d'entrées dont Linux a un pilote. Il est recommandé que les périphériques evdev soient configurés via InputClass au lieu d'une configuration par périphérique.

Configuration

Option "ButtonMapping" "string" Liste de mappage de boutons qui correspondent dans l'ordre aux boutons physiques sur le périphérique (défaut: 1 2 3 ... 32). 0 désactive le bouton.
Option "Device" "string" Spécifie le périphérique. généralement sous la forme "/dev/input/eventX"
Option "DragLockButtons" "L1 B2 L3 B4" Simule le maintien d'un bouton appuyé, pour les personnes ne pouvant pas maintenir le bouton pendant le déplacement. Les numéros de boutons sont par paires, numéro du bouton de lock suivi par le numéro du bouton cible pour le lock.
Option "DragLockButtons" "M1" Définis le bouton de lock maître
Option "Emulate3Buttons" "boolean" Active l'émulation du 3ème bouton pour les souris qui n'en n'ont que 2. Il est émulé en appuyant sur les 2 boutons en même temps
Option "Emulate3Timeout" "integer" Timeout en millisecondes pour déterminer si les 2 boutons sont pressé simultanément ou non. (défaut: 50)
Option "EmulateWheel" "boolean" Active l'émulation de la molette.
Option "EmulateWheelButton" "integer" Spécifie le bouton à utiliser pour émuler la molette. Pendant que ce bouton est pressé, l'axe X et/ou Y du pointer agira comme la molette
Option "EmulateWheelInertia" "integer" Spécifie combien de pixels de déplacement le pointeur doit effectuer pour générer un déplacement lors de l'émulation de la molette (défaut:10)
Option "EmulateWheelTimeout" "integer" Temps en millisecondes que EmulateWheelButton doit être pressé avant que l'émulation commence. (défaut: 200)
Option "EmulateThirdButton" "boolean" Active l'émulation du 3ème bouton, généralement en utilisant le bouton 1.
Option "EmulateThirdButtonTimeout" "integer" temps en milliseconde avant que l'émulation du 3ème bouton commence (défaut: 1000)
Option "EmulateThirdButtonButton" "integer" Bouton à utiliser pour lancer l'émulation du 3ème bouton
Option "EmulateThirdButtonMoveThreshold" "integer" Déplacement maximum pour l'émulation du 3ème bouton. Au delà, l'émulation n'est pas déclenchée
Option "GrabDevice" "boolean" Force la capture sur évènements. Cela permet de s'assurer qu'aucun autre pilote ne peut initialiser ce même périphérique. Ce périphérique n'enverra plus d'event ) /dev/kbd ou /dev/input/mice. défaut: désactivé
Option "InvertX" "Bool" Inverse l'axe donné.
Option "InvertY" "Bool" Inverse l'axe donné.
Option "IgnoreRelativeAxes" "Bool" Ignore l'axe spécifié.
Option "IgnoreAbsoluteAxes" "Bool" Ignore l'axe spécifié.
Option "Calibration" "min-x max-x min-y max-y" Calibre les axes pour les périphériques qui doivent être ajustés aux coordonnées système
Option "Mode" "Relative"|"Absolute" Définis le mode de périphérique si le périphérique a des axes absolus. Les touchpad sont relatifs par défaut, absolu pour les autres
Option "SwapAxes" "Bool" Swap les axes x/y.
Option "XAxisMapping" "N1 N2" Spécifie quels boutons sont mappés au mouvement dans la direction X dans l'émulation de la molette. N1 est mappé à l'axe X négatif et N2 à l'axe X positif.
Option "YAxisMapping" "N1 N2" Spécifie quels boutons sont mappés au mouvement dans la direction Y dans l'émulation de la molette. N1 est mappé à l'axe Y négatif et N2 à l'axe Y positif.
^
24 juin 2010

htmlpdflatexmanmd




expand

expand

Convertit les tabulations en espace pour chaque fichier donné sur la sortie standard

OPTIONS

-t TAB1[,TAB2]...' , --tabs=TAB1[,TAB2]...' Si seul TAB1 est donnée, définit les espaces de tabulations (défaut est 8). Sinon, définit les tabulations aux colonnes TAB1, TAB2, ... et remplace les tabulations au delà par un seul espace.
-i, --initial Convertit uniquement les tabulations initiales (celles qui précèdent tout caractères autre que des espaces ou tabulations).
^
03 décembre 2016

htmlpdflatexmanmd




exportfs

exportfs

Maintient une table de systèmes de fichiers NFS exportés

   Un serveur NFS maintient une table de systèmes de fichiers physiquement local accessibles aux clients NFS. Chaque système de fichier dans cette table est appelée un système de fichier exporté, ou export. La commande exportfs maintient la table courante des exports pour le serveur NFS. La table d'export maître est conservée dans un fichier nommé /var/lib/nfs/etab. Ce fichier est lus par rpc.mountd quand un client envoie une requête NFS MOUNT.

   Normalement la table d'export maître est initialisée depuis /etc/exports. Cependant, il est possible de supprimer des exports dans modifier /etc/exports. exportfs et sont partenaire rpc.mountd fonction en fournissant le système de fichier virtuel nfsd qui est monté dans /proc/fs/nfsd ou /proc/fs/nfs. exportfs ne donne pas d'informations au kernel, mais les fournis à rpc.mountd via le fichier /var/lib/nfs/etab. rpc.mountd peut ainsi gérer les requêtes kernel concernant les exports.

OPTIONS

-d, --debug kind Active le debug, (all, auth, call, general et parse)
-a Exporte ou dé-exporte tous les répertoires
-o options,... Spécifie une liste d'options d'exports
-i Ignore /etc/exports. Seules les options sur la ligne de commande et les options par défauts sont utilisées
-r Ré-exporte tous les répertoires. synchronise /var/lib/nfs/etab avec /etc/exports.
-u dé-exporte un ou plusieurs répertoires
-f Si /proc/fs/nfsd ou /proc/fs/nfs est monté, vide tout la table d'export du kernel, rafraîchi les entrées pour les clients actifs et les ajoute à la table d'export du kernel.
-v mode verbeux
-s Affiche la liste d'export courante.
^
03 décembre 2016

htmlpdflatexmanmd




/etc/exports

/etc/exports, /etc/exports.d

Fichier d'exports NFS

   Le fichier /etc/exports contient une table de systèmes de fichiers physiques locaux d'un serveur NFS accessibles aux clients NFS.

Formats des noms de machine

nom d'hôte un hôte peut être spécifié soit par son nom abrégé reconnu par le resolver, son fqdn, une adresse IPv4 ou IPv6
Réseaux IP il est possible d'exporter des répertoires à tous les hôte dans un sous-réseau en spécifiant ‹address›/‹netmask›, ou le masque peut être sous la forme /255.255.255.0 ou /24.
wildcards Les noms des machines peuvent contenir des caractère '*' ou '?' ou une classe de caractère entre crochets
netgroups Les netgroups NIS peuvent être donnés sous la forme @group. Seule la partie hôte du chaque membre du netgroup est vérifié.
anonymous Spécifié par '*' et matche tous les clients.

   Si un client matche plus d'une définition, seul le premier match de la liste est considéré.

Sécurité RPCSEC_GSS

   Les chaînes "gss/krb5", "gss/krb5i" ou "gss/krb5p" peunvent être utilisés pour restreindre l'accès aux clients utilisant la sécurité rpcsec_gss. Cependant, cette syntaxe est dépréciée, utiliser l'option "sec=":

   L'option sec=, suivi par une liste de mécanismes de sécurité, restreints l'export aux clients utilisant ces mécanismes: sys (défaut = pas de sécurité cryptographique), krb5 (authentification uniquement), krb5i (protection d'intégrité), et krb5p (chiffrement). La négociation suit l'ordre listé, le mécanisme préférentiel est listé en premier.

Options Générales

secure|insecure Cette option nécessite que les requêtes viennent d'un port inférieur à IPPORT_RESERVED (1024). Activée par défaut.
rw|ro Autoriser les requêtes de lecture/écriture ou de lecture seulement.
[a]sync async permet au serveur NFS de violer le protocole NFS et de répondre aux requêtes avant tout changement sur disque. Cela améliore les performance, mais peut cause une perte de données en cas de crash.
[no_]wdelay avec async, Le serveur NFS retarde normalement une requête d'écriture sur disque s'il suspecte qu'une autre requête d'écriture liée est en cours ou va se produire bientôt. Cela permet à plusieurs requêtes d'écritures d'être committed en une opération ce qui améliore les performances. Si un serveur reçoit principalement des petites requêtes non liées, ce comportement peut cependant réduire les performance. no_wdelay permet de désactiver ce comportement.
[no]hide Normalement, si un serveur exporte 2 systèmes de fichiers donc 1 est monté dans l'autre, le client devra monter les 2 systèmes de fichier explicitement. Si monte seulement le parent, il verra un répertoire vide à l'emplacement du 2eme fs. Il est 'caché'. nohide permet de ne pas cacher ce système de fichier. Cependant, certains client NFS ne gèrent pas cette situation, par exemple, il est possible que 2 fichiers aient le même numéro d'inode.
[no]crossmnt Similaire à nohide, mais rend possible l'accès à tous les systèmes de fichier monté dans le système de fichier marqué avec crossmnt. Donc un fs enfant "B" est monté dans un parent "A" a le même effet que nohide sur B. Avec nohide les fs enfant doivent être explicitement exportés, avec crossmnt ce n'est pas nécessaire. Si un enfant d'un fichier crossmnt n'est pas explicitement exporté, il l'est implicitement avec les mêmes options que le parent, à l'exception de fsid=.
[no_]subtree_check no_subtree_check désactive la vérification de l'arborescence, qui a de légères implications de sécurité, mais peut améliorer les performances dans certaines circonstances. Pour effectuer cette vérification, le serveur doit inclure des informations sur l'emplacement du fichier dans le filehandle donné au client. Cela peut poser problème en accédant à des fichiers qui sont renommé pendant qu'un client les ouvre. La vérification du subtree est également utilisée pour s'assurer que les fichiers dans les répertoire que seul root peut accéder peuvent seulement être accedés si le fs est exporté avec no_root_squash., même si le fichier lui-même autorise un accès plus large. un fs home devrait être exporté avec no_subtree_check. Un fs principalement lecture seule ou n'a pas de renommage important de fichiers (ex: /usr, /var), et pour lesquels les sous-répertoires peuvent être exportés, devraient probablement être exporté avec subtree_check.
[in]secure_locks|[no_]auth_nlm Indique que le serveur NFS n'exige pas d'authentification pour les requêtes le lock (qui utilisent le protocole NLM) Normalement le serveur NFS exige qu'une requête lock maintienne un accréditif pour un utilisateur qui a un accès en lecture sur le fichier.
mountpoint=path|mp Permet d'exporter seulement un répertoire si a été monté avec succès. Si aucun chemin n'est donné le point d'export doit être un point de montage. Cela permet de s'assurer que le répertoire sous un point de montage ne sera jamais exporté par accident si, par exemple, le fs échoue le montage dû à une erreur disque.
fsid=num|root|uuid NFS doit être capable d'identifier chaque système de fichier qu'il exporte. Normalement il utilise un UUID ou un numéro de périphérique. Il peut être nécessaire d'identifier explicitement un système de fichier dans certains cas. root ou 0 indiquent le système de fichier identifié comme le parent de tous les autres fs exportés.
nordirplus Désactive la gestion des requêtes READDIRPLUS. NFSv3 uniquement
refer=path@host[+host][:path@host[+host]] Un client référençant le point d'export sera dirigé pour choisir depuis la liste d'emplacement alternative pour le système de fichier.
replicas=path@host[+host][:path@host[+host]] Si le client demande un emplacement alternatif pour le point d'export, il obtiendra cette liste d'alternatifs.
pnfs Active l'extension pNFS, qui permet au client de bypasser le serveur et d'effectuer les opération d'E/S directement dans les périphériques.

Mappage d'ID utilisateur

   nfsd base sont contrôle d'accès aux fichier sur le serveur sur l'uid et le gid fournis dans chaque requête RPC NFS. Le comportement normal qu'un utilisateur attend et qu'il peut accéder à ses fichier sur le serveur comme dans un serveur de fichier normal. Cela nécessite que les même uids et gids soient utilisés dans le client et le serveur. Cela n'est pas toujours vrai, ni toujours désirable.

   Très souvent, il n'est pas désirable que root sur une machine soit également traitée en root en accédant à des fichiers sur un serveur NFS. l'uid 0 est normalement mappé à un autre id: nobody. Cette méthode, le root squashing, est le mode par défaut.

   Par défaut, exportfs choisis un uid et gid à 65534 pour l'accès squashed. Ces valeurs peuvent être changées par les options anonuid et anongid. Finalement on peut mapper toutes les requêtes utilisateur à l'uid anonyme avec l'option all_squash.

[no_]root_squash Map les requête pour uid/gid 0 en uid/gid anonyme
[no_]all_squash Map tous les uid/gid un uid/gid anonyme
anonuid, anongid Définis explicitement l'uid/gid anonyme

Table d'exports Extra

   Une fois la lecture de /etc/exports, exportfs lit les fichiers dans /etc/exports.d. Seul les fichiers se terminant par .exports sont lus.

Exemple

Exporter tout le système de fichier aux machines master et trusty, avec accès rw et désactivation du squashing
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
Exporter /usr en lecture seule à tous les hôtes du domain .local.domain, et en lecture/écriture à tous les membres du netgroup trusted
/usr *.local.domain(ro) @trusted(rw)
Exporter /home/joe pour pc001, avec activation du squashing pour tous les utilisateurs, et redéfinition du compte anonyme
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
Exporter /pub en lecture seul à tous le monde
/pub *(ro,insecure,all_squash)
Exporter /srv/www en activant l'option sync à la machine "server" et aux membres de @trusted et @external
/srv/www -sync,rw server @trusted @external(ro)
Exporter /foo en IPv4 et IPv6
/foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
Utiliser les plages entre [] pour spécifier plusieurs noms d'hôte.
/build buildhost[0-9].local.domain(rw)
^
06 juillet 2010

htmlpdflatexmanmd




expr

expr

Évalue des expressions et écrit le résultat sur stdout

   expr évalue une expression et écrit le résultat sur la sortie standard. les opérandes sont soit des entiers soit des chaînes. Les chaînes ne sont pas entre guillemet pour expr, mais peut être requis pour le shell. Une opérande chaîne ne devrait pas être un parenthèse ou un opérateur de expr. Vous ne devriez pas passer d'entier négatif ou de chaîne avec un '-' final comme premier argument de expr. Cela peut être évité avec des parenthèses.

Codes de status

0 si l'expressions est ni null ni 0
1 si l'expression est null ou 0
2 si l'expression est invalide
3 si une erreur interne s'est produite.

Expressions chaîne

STRING: REGEX Effectue une correspondance de motif. Les arguments sont convertis en chaîne et le second est considéré comme une expression régulière, avec un '^' implicite devant. s'il y'a correspondance et que REGEX utilise '\(' et '\)', retourne la partie de la chaîne qui correspond. Dans l'expression régulière, '\+', '\?', et '\|' sont des opérateurs qui correspondent respectivement à une correspondance d'un ou plus, zéro ou un, et séparés.
match STRING REGEX correspondance de motif alternatif. identique au précédent.
substr STRING POSITION LENGTH retourne le sous-chaîne de STRING commençant à POSITION avec LENGH longueur. si POSITION ou LENGTH sont des valeurs négatives, retourne une chaîne null.
index STRING CHARSET retourne la première position de STRING où le premier caractère dans CHARSET a été trouvé. retourne 0 si rien n'est trouvé.
length STRING retourne la longueur de STRING
+ TOKEN Interprète TOKEN comme une chaîne, même si c'est un mot clé comme MATCH ou un opérateur comme '/'
pour que expr interprète les mots clés comme chaîne, vous devez utiliser "'"

Expressions numériques

+ -  addition et soustraction. les arguments sont convertis en entiers; une erreur se produit s'ils ne peuvent être convertis.
* / %  mulitplication, division, modulo. les arguments sont convertis en entiers ; une erreur se produit s'ils ne peuvent être convertis

Relations pour expr

retourne le premier argument s'il est non null ni zéro. sinon le deuxième argument s'il est non null ni zéro.
retourne le premier argument s'il est non null ni zéro, sinon retourne 0. N'évalue pas le deuxième argument.
‹ ‹= = == != ›= › Compare les arguments et retourne 1 si la relation est vrai, 0 sinon. == est équivalement à =.

Exemples

ajouter 1 à la variable shell foo
foo=`expr $foo + 1`
afficher la partie non-répertoire du nom de fichier stocké dans $fname
expr $fname : '.*/\[.*\]' '|' $fname
exemple montrant que \+ est un opérateur
expr aaa : 'a\+'
affiche 3
expr abc : 'a\(.\)c'
affiche b
expr index abcdef cz
affiche 3
^
31 octobre 2016

htmlpdflatexmanmd




ext4

ext4

4ème système de fichier étendu

Fonctionnalités

   Un système de fichier formatté en ext4 peut avoir certains flags de fonctionnalités embarqués:

64bits Active les systèmes de fichiers supérieurs à 2^32 blocks. Cette fonctionnalité est active automatiquement si nécessaire.
bigalloc Active l'allocation de blocks clusterisés, pour que l'unité d'allocation soit une puissance de 2 nombres de blocks. C'est à dire, chaque bit dans le bitmap d'allocation de block indique désormais si un cluster est utilisé ou non, où un cluster est par défaut composé de 16 blocks. Cette fonctionnalité peut diminuer le temps passé à allouer des blocks et réduit la fragmentation, spécialement pour les grands fichiers. La taille peut être spécifiée en utilisant mke2fs -C.
dir_index Utilise des b-trees hashés pour accélérer la recherche de nom dans les grands répertoires.
dir_nlink Autorise plus de 65000 sous-répertoires par répertoire
encrypt Chiffrement au niveau du système de fichier des blocks de données et des noms de fichier. les métadonnées d'inode (timestamps, taille de fichier, user/groupe, etc) ne sont pas chiffrés
ext_attr Active l'utilisation d'attributs étendus.
extent Permet le mappage des numéros de blocks logiques pour un inode particulier vers des blocks physique dans le périphériques de stockage à stocker en utilisant un extent tree, qui est une structure de données plus efficace que le schéma de block indirect traditionnel utilisé par ext2 et ext3. Cela diminue la charge de block de métadonnées, améliore les performances et diminue le besoin de lancer e2fsck sur le système de fichier.
extra_isize Réserve un quantité d'espace spécifique dans chaque inode pour les métadonnées étendues tels que les timestamps nanoseconde et la date de création de fichier, même si le kernel n'a pas besoin d'un tel espace. Sans cette option, le kernel réserve de l'espace quand il en a besoin. Utile quand la taille d'inode fait au moins 256 octets.
filetype Active le stockage des information de type de fichier dans le entrées de répertoire.
flex_bg Permet aux métadonnées de groupes par block (bitmaps d'allocation et tables d'inodes) d'être placés n'importe où. De plus, mke2fs plase ces métadonnées ensemble en commençant au premier groupe de block de chaque "flex_bg group". La taille du groupe flex_bg peut être spécifié avec l'option -G
has_journal Créé un journal qui s'assure de la consistance du système de fichier même entre les arrêt non-propre. Équivalent à utiliser l'option -j avec mke2fs ou tune2fs.
huge_file Permet des fichiers supérieurs à 2Tio
inline_data Permet de stocker des données dans l'inode et dans les zones d'attributs étendus.
journal_dev Active dans le superblock dans un périphérique journal externe. La taille de block pour le journal externe doit être la même que le système de fichier.
large_file Définis automatiquement quand un fichier supérieur à 2Gio est créé.
meta_bg Permet de redimensionner un système de fichiers online sans réserver explicitement de l'espace pour agrandir la taille des descripteurs de groupe de block. Également utilisé pour redimensionner des systèmes de fichier supérieurs à 2^32 blocks. Non recommandé à la création d'un système de fichier.
mmp Fournis une protection de montage multipoint. Utile dans les environnements de stockage partagés
project Fournis le support des quotas de projet. Avec cette fonctionnalité, le project ID de l'inode est géré quand le système de fichier est monté.
quota Créé des inodes quota (inode #3 pour usrquota, #4 pour grpquota) et les définis dans le superblock. Avec cette fonctionnalité, les quotas sont activés automatiquement quand le système de fichier est monté.
resize_inode indique que de l'espace a été réservé pour que la table de descripteur de groupe de block puisse être étendue en redimmensionnant un système de fichier monté. L'opération de redimensionnement online est géré par le kernel, piloté par resize2fs. Nécessite également sparse_super.
sparse_super Indique que les copies backup du superblock et les descripteurs de groupe de block sont présent seulement dans quelques groupes de block, pas tous.
sparse_super2 Indique qu'il y a seulement 2 sauvegardes de superblock et des descripteurs de groupe de block. Les groupes de block utilisés pour les sauvegardes sont stockés dans le superblock, mais typiquement, sera localisé au début du groupe de block #1, et un dans le dernier groupe de block dans le système de fichier. Version extrême de sparse_super et est conçus pour permettre qu'un plus grand pourcentage du disque ait des blocks contigus disponible pour les fichiers.
uninit_bg Indique que les descripteurs de groupe de block sont protégés en utilisant des checksums, permettant à mke2fs de créer un système de fichier sans initialiser tous les groupes de block. Accélère la création des systèmes de fichier.

Options de montage

journal_dev=devnum/journal_path=path Quand les numéros majeur/mineur du périphérique de journal externe a été changé, ces options permettent à l'utilisateur de spécifier le nouvel emplacement du journal.
norecovery|noload Ne charge pas le journal au montage. Noter que si le système de fichier n'a pas été démonté proprement, ne pas rejouer le journal peut engendrer des inconsistances dans le système de fichier.
data={journal|ordered|writeback} Spécifie le mode de journalisation. Les métadonnées sont toujours journalisés:

        journal Toutes les données sont envoyées au journal avant d'être écrit dans le système de fichier
        ordered mode par défaut. Toutes les données sont écrites dans le système de fichier avant que ses métadonnées soient envoyées au journal
        writeback L'ordre des données n'est pas préservé - les données peuvent être écrites dans le système de fichier après que ses métodonnées aient été envoyées au journal. Plus performant et garanti l'intégrité du système de fichier, mais d'anciennes données peuvent apparaître dans les fichiers après un crash et une récupération journal.

commit=nrsec Synchronise toutes les données et métadonnées chaque nrsec secondes. Défaut: 5. 0=défaut.
oldalloc|orlov Utilise l'ancien allocateur ou l'allocateur Orlov pour les nouveaux inode. Orlov est le défaut.
[no]user_xattr Active les attributs étendus
[no]acl Support pour les ACL posix
bsddf|minixdf Définis le comportement pour l'appel système statfs. minixdf retourne dans le champ f_blocks le nombre total de blocks, bsddf soustrait les blocks utilisé par ext4 et non disponible pour le stockage.
debug Affiche des informations de debuggage à chaque remontage
errors={continue|remount-ro|panic} Définis le comportement si une erreur est rencontrée
data_err=ignore|abord Affiche simplement un message d'erreur si une erreur se produit (ignore), ou annule le journal (abort)
grpid|bsdgroups et nogrpid|sysvgroups Définissent quel GID a un fichier nouvellement créé. avec grpid, il prend le GID du répertoire dans lequel il a été créé; sinon (le défaut), il prend le fsgid du processus courant, sauf si le setgid est mis, auquel cas il prend le gid du répertoire parent et obtient le setgid si c'est un répertoire lui-même.
sb=n Au lieu du block 1, utilise le block n comme superblock. Peut être utile quand le système de fichier a été endommagé.
nouid32 Désactive les UID et GID 32bits. Pour compatibilité avec les anciens kernel.
grpquota|usrquota|quota|noquota active le support des quotas
usrjquota=aquota.user|grpjquota=aquota.group|jqfmt=vfsv0 Support pour les quotas journalisés (quota version 2). jqfmt=vfsv0 active les quotas journalisés. Pour les quotas journalisés les options de montage usrjquota=aquota.user et grpjquota=aquota.group sont requis pour indiquer au système de quota quels bases de quota utiliser. Les quotas journalisés ont l'avantage que même après un crash aucune vérification de quota n'est requis.
journal_checksum Active le cheksum des transactions du journal. Permet au code de récupération dans e2fsck et le kernel de détecter les corruptions dans le kernel.
journal_async_commit Les blocks émis peuvent être écris sur le disque sans attendre les blocks descripteur.
barrier=0 / barrier=1 / barrier / nobarrier Active l'utilisation de barrières d'écriture dans le code jbd. Ces barrières forcent l'ordre sur disque correcte des commits journaux, rendant les cache d'écritures disque volatiles plus sûres, au prix d'une pénalité de performances.
inode_readahead_blks=n contrôle le nombre maximum de blocks de table d'inodes que l'algorithme readahead de table d'inode pré-lit dans le cache. La valeur doit être une puissance de 2. Défaut: 32 blocks
stripe=n Nombre de blocks de système de fichiers que mballoc tente d'utiliser pour la taille d'allocation et l'alignement. Pour les systèmes RAID5/6, c'est le nombre de disques de données * la taille de chunk dans les blocks du système de fichier.
delalloc|nodelalloc Défère l'allocation de block jusqu'au moment de l'écriture
max_batch_time=usec Temps max d'attente pour des opérations de système de fichier additionnels à batcher ensemble avec une opération d'écriture synchrone. Vu qu'une opération d'écriture synchrone force un commit puis attend que l'opération d'E/S se complète, cela ne coûte rien et peut être un gros gain de débit, on attend un peut pour voir si une autre transaction peut se greffer dans l'écriture synchrone. L'algorithme utilisé est conçus pour la vitesse disque, en mesurant la quantité de temps qu'il prend pour finir un commit.
min_batch_time=usec Temps de commit minimum. Défaut: 0ms. Augmenter ce paramètre peut améliorer des charges synchrone multi-threadés sur les disques rapide, au prix d'une latence accrue.
journal_ioprio=prio Priorité E/S (de 0 à 7, 0 étant la priorité la plus élevée) qui devrait être utilisé pour les opérations d'E/S envoyés par kjournald2 durant une opération commit. Défaut: 3, qui est légèrement supérieur à la priorité E/S par défaut.
abort simule les effets de ext4_abort().
auto_da_alloc|noauto_da_alloc De nombreuses applications cassées n'utilisent pas fsync() en remplaçant les fichiers existant via des pattern. Si auto_da_alloc est activé, ext4 détecte les pattern replace-via-rename et replace-via-truncate et force toutes allocations de blocks retardés à être alloués au prochain commit journal, dans le mode data=ordered.
noinit_itable N'initialise pas les blocks de table d'inode non-initialisés en fond. Peut être utilisé par les CD d'installation pour que le processus d'installation puisse se compléter le plus vite possible; le processus d'initialisation de table d'inode sera déférré à la prochaine fois que le système de fichier est monté
init_itable=n Le code itable attend n fois le nombre de millisecondes qu'il a pris pour remplir de 0 la table d'inode du groupe de block précédent. Celà minimise l'impact sur les performances système à l'initialisation des tables d'inode
discard/nodiscard Contrôle si ext4 devrait émettre des commandes discard/TRIM au périphérique block quand des blocks sont libérés. Utile pour des disques SSD et les LUN sparse/thinly-provisionned.
block_validity/noblock_validity Active la facilité kernel pour traquer les blocks de métadonnées du système de fichier dans les structures de données interne. Cela permet à l'allocateur multi-block et d'autres routines de rapidement localiser les extents qui peuvent chevaucher les blocks de métadonnées. Cette option est prévu pour du debugging.
dioread_lock/dioread_nolock Contrôle si ext4 devrait ou non utilise les locks de lecture DIO. Si l'option dioread_nolock est donné, alloue les extents non initialisés avant l'écriture du tampon et convertis l'extent en initialisé après que les E/S soient complétés. Cette approche permet d'éviter d'utiliser d'inode mutex, qui améliore l'évolutivité sur les stockages à haute vitesse. Cependant cela ne fonctionne pas avec les données journalisée et l'option dioread_nolock est ignorée.
max_dir_size_kb=n Limite la taille des répertoires pour que toute tentative de les étendre au-delà de cette limite en Kio génère une erreur ENOSPC. Utile dans les environnement en mémoire contrainte, où de très gros répertoires peut causer de sérieux problèmes de performances. (par exemple, s'il y a seulement 512Mo de mémoire disponible, un répertoire de 176Mo peut sérieusement monopoliser les ressources système.
i_version Active le support d'inode 64bits. Défaut: off.

Attributs de fichier

a Ajouter uniquement
A Pas de mise à jours du atime
d Pas de dump
D Mise à jours de répertoire synchrone
i immuable
S Mises à jours synchrone
u Non supprimable
j Données journalisées
e Format étendu
^
15 juillet 2010

htmlpdflatexmanmd




factor

factor

Affiche le facteur premier

   Si aucun argument n'est donné, factor lit l'entrée standard, délimité par des newline, tab, ou spaces.

^
25 mai 2017

htmlpdflatexmanmd




fail2ban-client

fail2ban-client

Configure et contrôle le service fail2ban

OPTIONS

-c ‹DIR› répertoire de configuration
-s ‹FILE› Chemin du socket
-p ‹FILE› Chemin du fichier pid
-d Dump la configuration
-i Mode interactif
-v mode verbeux
-q mode silencieux
-b Lance le serveur en tâche de fond
-f Ne lance pas le serveur en tâche de fond

Commandes

start Démarre le serveur et les jails
reload Recharge la configuration
reload ‹JAIL› Recharge le jail
stop Stoppe tous les jail et termine le serveur
status Affiche le status courant du serveur
ping Test si le serveur est en vie
set loglevel ‹LEVEL› Définis le niveau de log (CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG)
get loglevel Affiche le niveau de log
set logtarget ‹TARGET› Définis la cible des logs (STDOUT, STDERR, SYSLOG ou un fichier)
get logtarget Affiche la cible des logs
set syslogsocket auto|‹SOCKET› Définis le chemin du socket syslog
get syslogsocket Affiche le chemin du socket syslog
flushlogs Vide le logtarget si c'est un fichier et l'ouvre de nouveau. Pour la rotation de log
set dbfile ‹FILE› Définis l'emplacement du datastore persistent. None le désactive
get dbfile Affiche l'emplacement du datastore persistent
get dbpurgeage ‹SECONDS› Défpinis de délai de conservation de l'historique des bans
get dbpurgeage Affiche le délai de conservation de l'historique des bans
add ‹JAIL› ‹BACKEND› Crée le jail en utilisant le backend
start ‹JAIL› Démarre le jail
stop ‹JAIL› Stoppe le jail
status ‹JAIL› [FLAVOR] Affiche le status courant du jail
set ‹JAIL› idle on|off Définis l'état idle du jail
set ‹JAIL› addignoreip ‹IP› Ajoute l'ip à la liste ignore du jail
set ‹JAIL› delignoreip ‹IP› supprime l'ip de la liste ignore du jair
set ‹JAIL› addlogpath ‹FILE› ['tail'] Ajoute le fichier à la liste de supervision du jail, optionnellement démarrant au tail du fichier (défaut: head)
set ‹JAIL› dellogpath ‹FILE› Supprime le fichier de la liste de supervision du jail
set ‹JAIL› logencoding ‹ENCODING› Définis l'encodage des fichiers de log du jail
set ‹JAIL› addjournalmatch ‹MATCH› Ajoute le match au filtre de journal du jail
set ‹JAIL› deljournalmatch ‹MATCH› Supprime le match du fitre de journal du jail
set ‹JAIL› addfailregex ‹REGEX› Ajoute l'expression régulière qui doit matcher les erreurs pour le jail
set ‹JAIL› delfailregex ‹INDEX› Suppmire l'expression régulière du jail
set ‹JAIL› ignorecommand ‹VALUE› Définis le ignorecommande du jail
set ‹JAIL› addignoreregex ‹REGEX› Ajoute l'expression régulière qui doit matcher un motif à exclure pour le jail
set ‹JAIL› delignoreregex ‹INDEX› Supprime l'expression régulière qui doit matcher un motif à exclure du jail
set ‹JAIL› findtime ‹TIME› Définis le nombre de secondes pour lequel le filtre recherche en arrière pour le jail
set ‹JAIL› bantime ‹TIME› Définis le nombre de secondes qu'un hôte est bannis pour le jail
set ‹JAIL› datepattern ‹PATTERN› Définis le motif utilisé pour matcher les dates/heures pour le jail
set ‹JAIL› usedns ‹VALUE› Définis le mode usedns pour le jail
set ‹JAIL› banip ‹IP› Bannis manuellement une IP pour le jail
set ‹JAIL› unbanip ‹IP› Débannis manuellement une IP du jail
set ‹JAIL› maxretry ‹RETRY› Définis le nombre d'erreurs avant de bannir l'hôte pour le jail
set ‹JAIL› maxlines ‹LINES› Définis le nombre de linux à mettre en tampon pour la recherche regex pour le jail
set ‹JAIL› addaction ‹ACT›[ ‹PYTHONFILE› ‹JSONKWARGS›] Ajoute une nouvelle action pour le jail
set ‹JAIL› delaction ‹ACT› Supprime une action pour le jail
set ‹JAIL› action ‹ACT› actionstart ‹CMD› Définis la commande de démarrage de l'action pour le jail
set ‹JAIL› action ‹ACT› actionstop ‹CMD› action pour le jail
set ‹JAIL› action ‹ACT› actioncheck ‹CMD› Définis la commande de vérification de l'action pour le jail
set ‹JAIL› action ‹ACT› actionban ‹CMD› Commande ban
set ‹JAIL› action ‹ACT› actionunban ‹CMD› commande unban
set ‹JAIL› action ‹ACT› timeout ‹TIMEOUT› commande timeout, en secondes
set ‹JAIL› action ‹ACT› ‹PROPERTY› ‹VALUE› Définis une valeur/propriété pour l'action
set ‹JAIL› action ‹ACT› ‹METHOD›[ ‹JSONKWARGS›] Appel la méthode pour l'action
get ‹JAIL› logpath afiche la liste des fichiers supervisés pour le jail
get ‹JAIL› logencoding Affiche l'encodage des fichiers de logs pour le jail
get ‹JAIL› journalmatch Affiche le fitre de match journal
get ‹JAIL› ignoreip Affiche la liste des ip ignorées
get ‹JAIL› ignorecommand Affiche l'ignorecommand du jail
get ‹JAIL› failregex Affiche la liste des expressions régulières qui matche les erreurs
get ‹JAIL› ignoreregex Affiche la liste des expressions régulières d'ignore pour le jail
get ‹JAIL› findtime Affiche le temps pour la recherche en arrière du filtre pour les erreurs
get ‹JAIL› bantime Affiche le temps de bannissement d'un hôte
get ‹JAIL› datepattern Affiche le motif utilisé pour matcher les dates/heures
get ‹JAIL› usedns Affiche le paramètre usedns
get ‹JAIL› maxretry Affiche le nombre d'erreurs permises pour le jail
get ‹JAIL› maxlines Affiche le nombre de ligne en tampon
get ‹JAIL› actions Affiche la liste d'actions
get ‹JAIL› action ‹ACT› actionstart Affiche la commande start pour l'action
get ‹JAIL› action ‹ACT› actionstop affiche la commande stop pour l'action
get ‹JAIL› action ‹ACT› actioncheck Affiche la commande check pour l'action
get ‹JAIL› action ‹ACT› actionban affiche la commande ban pour l'action
get ‹JAIL› action ‹ACT› actionunban affiche la commande unban pour l'action
get ‹JAIL› action ‹ACT› timeout affiche la commande timeout pour l'action
get ‹JAIL› actionproperties ‹ACT› Affiche la liste des propriétés pour l'action
get ‹JAIL› actionmethods ‹ACT› AFfiche la liste des méthodes pour l'action
get ‹JAIL› action ‹ACT› ‹PROPERTY› Affiche la valeur de la propriété pour l'action
^
25 mai 2017

htmlpdflatexmanmd




fail2ban-regex

fail2ban-regex

Tester les options failregex de fail2ban

OPTIONS

la syntaxe est fail2ban-regex

OPTIONS

-d, --datepattern=DATEPATTERN Définis un motif utilisé pour matcher les dates/heures
-e, --encoding=ENCODING Encodage de fichier. Défaut: locale système
-r, --raw pas de résolution DNS
-L, --maxlines=MAXLINES Nombre de ligne max pour les expressions régulières multilignes
-m, --journalmatch=JOURNALMATCH matche style journalctl. "systemd-journal" uniquement
-l, --log-level=LOG-LEVEL Niveau de log pour le logger fail2ban à utiliser
-v, --verbose mode verbeux
-D, --debuggex Produit des urls debuggex.com
--print-no-missed N'affiche pas de ligne manquante
--print-no-ignored N'affiche pas les lignes ignorées
--print-all-matched Affiche toutes les lignes qui matchent
--print-all-missed Affiche toutes les lignes manquantes
--print-all-ignored Affiche toutes les lignes ignorées
-t, --log-traceback Enrichis les messages de logs avec des tracebacks compressés
--full-traceback tracebacks complet, non-compressés
^
25 mai 2017

htmlpdflatexmanmd




fail2ban-server

fail2ban-server

Service fail2ban

   Fail2Ban lit le fichier de log contenant les rapport d'authentification échoués et banni les adresses IP correspondantes en utilisant les règles firewall. fail2ban-server ne doit pas être utilisé directement, et est lancé par fail2ban-client.

OPTIONS

-b Démarre en tâche de fond
-f Ne démarre pas en tâche de fond
-s ‹FILE› Chemin du socket
-p ‹FILE› Chemin du fichier pid
-x Force l'exécution du serveur
^
25 mai 2017

htmlpdflatexmanmd




fail2ban-testcases

fail2ban-testcases

Lance les tests d'unité fail2ban

OPTIONS

-l LOG_LEVEL, --log-level=LOG_LEVEL Niveau de log durant les tests
-n, --no-network Ne lance pas le tests qui nécessitent le réseau
-t, --log-traceback Enrichis les messages de logs avec des tracebacks compressés
--full-traceback tracebacks complet, non-compressés
^
05 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/failsafe_context

/etc/selinux/‹SELINUXTYPE›/contexts/failsafe_context

Fichier de configuration de contexte par défaut

   Ce fichier permet aux applications compatible SELinux tel que PAM d'obtenir un contexte de login valide pour un administrateur si aucune entrée par défaut n'est trouvé. Le format consiste des éléments suivant:

  role:type[:range]

Exemple

unconfined_r:unconfined_t:s0
^
06 juillet 2010

htmlpdflatexmanmd




false

false

Retourner un code de sortie de 1

   false ne fait rien excepté retourner un code de sortie de 1.

^
03 novembre 2016

htmlpdflatexmanmd




fatlabel

fatlabel

Afficher ou définis le label des systèmes de fichier MS-DOS

   Si le label est omis, affiche le label courant. Le label ne peut pas dépasser 11 octets.

^
22 mai 2010

htmlpdflatexmanmd




fcron

fcron

Remplace cron et implémente des options supplémentaires

   fcron charge les fichiers fcrontab utilisateur, puis il calcul l'heure et la date de la prochaine exécution de chaque tâche, et calcul le temps qu'il doit attendre, et se met en attente. Quand il se réveille, il vérifie chaque tâche chargée et les lance si nécessaire. Quand une tâche est exécutée, fcron change son user:group pour correspondre à la tâche, l'exécute et mail la sortie à l'utilisateur.

  note: fcron attend au moins 20 secondes après qu'il a été démarré avant d'exécuter une tâche pour éviter d'utiliser trop de ressource durant le démarrage du système.

OPTIONS

-f, --foreground Ne pas même en tâche de fond, dans ce mode les message d'information sont placés sur la sortie standard en plus de syslog.
-b, --background Force l'exécution en tâche de fond.
-s, --savetime Sauvegarde fcrontab sur le disque tous les n sec (défaut 1000)
-m, --maxserial Définit le nombre maximum de tâche qui peuvent être exécutées simultanément. par défaut 1.
-q, --queuelen Définit le nombre de tâche que la file d'attente peut contenir.
-c, --configfile Spécifier le fichier de configuration à utiliser (par défaut /etc/fcron.conf)
-o, --once Exécute toutes les tâches qui doivent être lancées quand fcron est démarré, les attend, puis se termine. Définit firstsleep à 0. Peut être utile avec l'option -y et -f dans un script.
-y, --nosyslog Ne pas logger dans syslog
-l, --firstsleep Définis le délai initial en secondes avant qu'une tâche soit exécutée (défaut 20sec)
-n, --newspooldir Créer le dossier spécifié comme spool pour fcron.

Fichiers

/etc/fcron.conf Fichier de configuration pour fcron, fcrontab et fcrondyn. Contient les paths et les programmes par défaut à utiliser
/etc/fcron.allow Les utilisateurs autorisés à utiliser fcrontab et fcrondyn
/etc/fcron.deny Les utilisateurs non autorisés à utiliser fcrontab et fcrondyn
/etc/pam.d/fcron Fichier de configuration PAM
^
22 mai 2010

htmlpdflatexmanmd




fcron.conf

fcron.conf

Fichier de configuration de fcron

OPTIONS

fcrontabs=directory (/var/spool/fcron)
pidfile=file-path (/var/run/fcron.pid)
fifofile=file-path (/var/run/fcron.fifo) nécessaire pour fcrondyn pour communiquer avec fcron.
fcronallow=file-path (/etc/fcron.allow)
fcrondeny=file-path (/etc/fcron.deny)
shell=file-path (/bin/sh)
sendmail=file-path (/usr/lib/sendmail)
editor=file-path (/usr/bin/vi)
^
22 mai 2010

htmlpdflatexmanmd




fcrondyn

fcrondyn

Intéragir avec le service fcron. Il peut par exemple, lister les tâches utilisateurchargées par fcron, lancer l'une d'elles, modifier la priorité d'une tâche en cours d'exécution, envoyer un signal à une tâche, etc.

OPTIONS

-i Mode interactif
-x lancer la commande spécifié et revient immediatement.
-c spécifier le fichier de configuration (par défaut /etc/fcron.conf)

Commandes

quit, q quitter fcrondyn (pour le mode interactif)
ls [user] Afficher toutes les tâche de user
ls_lavgq [user] idem mais uniquement pour les tâche en file d'attente de charge système.
ls_serialq [user] idem mais uniquement pour les tâches en file d'attente sérialisée
ls-exeq [user] idem mais uniquement les tâche en cours d'exécution
detail jobid Afficher les détails d'une tâche jobid est fournis par ls
runnow jobid Lancer la tâche maintenant, modifie la date et heure de prochaine exécution.
run jobid idem mais no modifie pas la date et l'heure de la prochaine exécution
kill sig jobid Envoyer un signal à une tâche
renice x jobid Modifier la priorité d'une tâche

Champs utilisés par les commandes detail et ls

ID ID dela tâche
USER Utilisateur auquel appartient la tâche
PID PID de la tâche en cours
INDEX Index de la tâche dans la file d'attente séquentielle
R&Q Indique le nombre d'instances de la tâche en cours ou en attente d'exécution dans la file d'attente
OPTIONS Indique les principales options positionnées de la tâche. L pour les tâches ne s'exécutant qu'en dessous d'une charge système donnée (L pour Load average), LO si une seule instance de la tâche peut se trouver dans dans la file d'attente de charge système (LO pour Lavg Once), S pour les tâches s'exécutant séquentiellement (S pour Serial), SO pour les tâches qui ne seront exécutées séquentiellement que pour leur prochaine exécution (SO pour Serial Once), et ES pour les tâches dont plusieurs instances peuvent s'exécuter simultanément (ES pour allow the Execution of Several instances).
LAVG Trois valeurs correspondant à la charge système moyennée sur 1, 5 et 15 minutes (dans cet ordre) en dessous de laquelle la tâche sera exécutée, sinon elle sera placée en attente d'une charge système adéquate
UNTIL champ correspondant à l'option until
STRICT Champ correspondant à l'option strict. Y pour yes, N pour non.
SCHEDULE Indique la date et l'heure prévues de la prochaine exécution de la tâche. Veuillez noter que l'heure indiquée est celle du système sur lequel tourne fcron, et non celle du fuseau horaire que l'utilisateur peut éventuellement définir avec l'option timezone de fcrontab
CMD La commande à exécuter
^
22 mai 2010

htmlpdflatexmanmd




fcrontab

fcrontab

Installer-gérer les tables fcron

   fcrontab est le programme utilisé pour installer, éditer, lister et supprimer les tables utilisées par fcron. Comme fcron utilise en interne un format non lisible, l'utilisateur ne peut pas éditer directement son fcrontab. Un utilisateur peut installer un fcrontab s'il est listé dans /etc/fcron.allow et pas dans /etc/fcron.deny.

OPTIONS

-u Spécifier l'utilisateur. ne devrait être utilisé que par root.
-l Liste le fcrontab de l'utilisateur courant
-e  Éditer le fcrontab de l'utilisateur courant.
-r Supprimer le fcrontab de l'utilisateur courant.
-z Réinstaller le fcrontab de l'utilisateur courant.
-n  Ignore la version précédente de fcrontab.
-c Spécifie le fichier de configuration
-d Mode debuggage

   Chaque ligne dans un fichier crontab peut être:

- une configuration d'environnement
- une configuration d'options
- des entrées basées sur la durée totale de fonctionnement du système depuis la dernière exécution de la tâche
- des entrées basées sur un temps absolu (comme les entrées normales de crontab)
- des entrées lancées périodiquement

Configuration de l'environnement

   ils sont sous la forme: name = value. Quand fcron exécute une commande, il définit toujours USER, HOME et SHELL comme définit dans /etc/passwd. HOME et SHELL peuvent être remplacés par un paramètre dans fcrontab, mais pas USER. La variable MAILTO permet de spécifier à qui mailer les sorties.

Entrées basées sur le temps écoulé depuis le démarrage du système

Les entrées des commandes qui ont été lancées une fois toutes les n minutes sont sous la forme:
@options fréquence commande
où la fréquence est une valeur de temps sous la forme:
valeur+multiplieur[+valeur+multiplier[...]+valeur_en_minutes]
exemple:
"12h02", "3w2d5h1"
il s'gait du temps d'exécution de fcron. les multiplieurs valides sont:
mois(m), semaine(w), jours(d), heure(h) et seconde(s)

   options sert à placer une valeur de temps: il sera interprété comme @first(‹time›). Si option n'est pas spécifé, frequence est utilisé.

   Ce type d'entrée ne garantie pas de date et heure d'exécution (vu que la tâche est retardé à chaque démarrage par le temps passé depuis l'arrêt), mais peut être pratique pour des tâches dépendant du nombre de choses faites par les utilisateurs.

  Le temps restant avant la prochaine exécution est sauvegardé toutes les 1800 secondes (afin de limiter les dommages provoqués par un plantage) et lorsque fcron quitte après avoir reçu un signal SIGTERM, c.-à-d. lorsque l'on arrête le système.

Exemples

récupérer vos mails toutes les 30 minutes:
@ 30 getmails -all
Effectuer quelques tests de sécurité toutes les 48 heures de fonctionnement du système, envoyer un mail au super-utilisateur
@mailto(root),forcemail 2d /etc/security/msec/cron-sh/security.sh

Entrées basée sur une date et une heure

   Le deuxième type d'entrée d'un fichier fcrontab commence par un caractère & optionnel qui peut être immédiatement suivi par un nombre optionnel définissant la fréquence d'exécution. il possède cinq champs de date et d'heure, ainsi qu'une commande shell:

  &options min hrs jour-du-mois mois jour-de-la-semaine commande

  Noter que la commande shell peut être précédée par un nom d'utilisateur. La fréquence est interprétée de la façon suivante: lancer cette commande après x correspondances des champs date et heure.

champ____________Valeurs permises
minute______________0-59
heure_______________0-23
jour du mois________1-31
mois________________1-12 (ou leur noms)
jour de la semaine__0-7 (ou leur noms)

   un * signifie toutes les valeur. Les listes sont des valeur séparée par une virgule (1,4,8). Les intervalles sont séparés par un "-" (1-9), le pas est spécifié après un "/" (*/2), pour désactiver certaines valeur les précéder par " " (5-8 6 7)

  Si un jour de mois et un jour de semaine sont donnés, la commande sera exécutée seulement si les deux correspondent au jour et à l'heure actuels à moins que l'option dayor n'ait été positionnée.

Exemples

Lancer ma_commande tous les jours à 12:05, 12:35, 13:05, 13:35, 14:05 et 14:35
& 05,35 12-14 * * * macommande -u moi -o fichier
Récupérer les mails toutes les heures aux minutes 20, 21, 22, et 24.
20-24 23 * * * * getmail
Sauvegarder mon travail de la journée toutes les nuits à 03:45 avec une faible priorité, sauf le dimanche, envoyer la sortie par mail à jim et lancer cette tâche au démarrage si la machine était éteinte à 03:45
&nice(10),mailto(jim),bootrun 45 03 * * * 0 "save —mon travail"

Entrées lancées périodiquement

Le troisième type d'entrée fcrontab commence par le caractère "%", suivi par un mot-clef parmi une des trois différentes listes, puis par des options.
hourly , daily , monthly , weekly
Indique à fcron de lancer la commande une fois entre le début et là fin de l'intervalle de temps correspondant.
midhourly , middaily , nightly , midmonthly , midweekly
identique aux précédant, excepté que les intervalles de temps sont définis au milieu de l'intervalle.
exemple:
%nightly,mail(no) * 21-23,3-5 echo "une entrée nigthly"
mins , hours , days , mons , dow
Lance cette commande une fois durant CHAQUE intervalle de temps spécifié, ignorant les champs suivants le mot-clef dans la définition de l'intervalle de temps
Un tel mot-clef est suivi par 5 champs de date et d'heure (les mêmes champs utilisés pour une ligne basée sur un temps absolu. exemple:
%hours * 0-22 * * * echo "Ok."
note:
%mins 15 2-4 * * * echo
lancera echo tous les jours à 2:15, 3:15 ET 4:15.
%hours 15 2-4 * * * echo
lancera echo seulement UNE FOIS soit à 2:15, soit à 3:15 OU BIEN à 4:15.

Options

   Les options peuvent être positionnées soit pour chaque ligne située après la déclaration, soit pour une ligne de manière individuelle. Dans le premier cas, la configuration est faite sur une ligne complète après un point d'exclamation "!", dans le second cas, elle est faite après l'un des symboles suivants "&", "%" ou "@", suivant le type de planification. Veuillez noter qu'une déclaration d'option dans une planification écrase la déclaration globale de la même option.

   Les options sont séparées par des virgules "," et leurs arguments, s'il y en a, sont placés entre parenthèses. Les espaces ne sont pas permises. Une déclaration d'option est de la forme:

option[(arg1[,arg2][...])][,option[(arg1[...])]][...]

bootrun, b Lancer une ligne "&" au démarrage defcron si celle-ci avait du être lancée pendant l'arrêt du système.
dayand Effectuer un ET logique entre le jour de la semaine et le jour du mois.
dayor Effectuer un OU logique entre le jour de la semaine et le jour du mois.
exesev Définis si une tâche peut être exécutée plusieurs fois simultanément
first, f Temps avant la première exécution d'une tâche basée sur le temps de fonctionnement du système. Utile dans les cas suivants : vous avez plusieurs tâches à exécuter, disons, toutes les heures. En positionnant différentes valeurs first pour chaque tâche, vous évitez que celles-ci soient lancées simultanément chaque fois. Vous pouvez également la mettre à 0, ce qui est pratique lorsqu'elle est utilisée avec l'option volatile.
forcemail Envoie la sortie par mail même si celle-ci est vide.
lavg Définit les valeurs de la charge moyenne du système sur 1,5 et 15 minute (dans cet ordre) en dessous desquelles la tâche pourra être lancée. Ces valeurs ne peuvent avoir qu'une seule décimal. Mettre une valeur à 0 pour ignorer la charge moyenne correspondante.
lavg1, lavg5, lavg15 Définir le seuil des valeurs de charge moyenne du système sur 1, 5 ou 15 minutes. Définir l'une d'elles à 0 pour ignorer la charge moyenne correspondante.
lavgand Effectuer un ET logique entre les valeurs de charge moyenne du système 1, 5 et 15 minutes.
lavgonce Une tâche peut-elle être mise plusieurs fois simultanément dans la file d'attente de charge moyenne du système.
lavgor Effectuer un OU logique entre les valeurs de charge moyenne du système à 1, 5 et 15 minutes.
mail, m Envoyer la sortie par mail
mailto Spécifier l'adresse mail.
nice,n Modifier la priorité de la tâche
nolog Journaliser seulement les erreurs des tâches correspondantes
noticenotrun fcron devrait-il prévenir l'utilisateur par mail de la non exécution d'une tâche % ou d'une tâche & ? (à cause de l'arrêt du système dans les deux cas ou d'une charge moyenne trop élevée dans le second cas).
random Dans une ligne lancée périodiquement, cette option répond à la question : Cette tâche devrait-elle être lancée aussitôt que possible dans son intervalle de temps d'exécution (plus sûr), ou bien fcron doit-il définir une date et heure aléatoire d'exécution dans ce même intervalle de temps ?. Veuillez noter que si cette option est positionnée, la tâche peut ne pas être lancée si fcron n'est pas en cours d'exécution durant tout l'intervalle d'exécution. En outre, sachez qu'il peut être relativement facile pour une personne compétente de deviner l'heure de la prochaine exécution d'une tâche utilisant l'option random : il est donc préférable de ne pas baser la sécurité de quelque chose de sensible sur l'aléa de cette option. Cependant, cela ne devrait pas poser de problème pour la plupart de ses utilisations.
reset Positionner toutes les options à leur valeurs par défaut
runas Lancer avec les permissions et l'environnement de l'utilisateur spécifié (seul root peut utiliser cette option)
runfreq, r Lancer toutes le "runfreq" correspondances de date et d'heure. (cette options est ignorée dans le cas d'entrées basées sur le temps écoulé depuis le démarrage du système).
serial, s fcron fait tourner au plus 1 tâche séquentielle en même temps (càd. pour lesquelles l'option serial est définie), et autant de tâches qui sont à la fois séquentielles et dont l'exécution dépend aussi de la charge système (autrement dit pour lesquelles les options serial et lavg sont définies). Cette valeur peut être modifiée grâce à l'option -m de fcron. Cette option trouve toute son utilité dans le cas de tâches lourdes afin d'éviter une surcharge du système.
serialonce Définit si un tâche peut être mise plusieurs fois dans la file d'attente séquentielle.
stdout Si fcron s'exécute en arrière plan, permet la sortie sur stderr/stdout plutôt que par mail.
strict Lorsqu'une tâche % de la file d'attente de charge moyenne du système est à la fin de l'intervalle de temps d'exécution, doit-elle être retirée de la file d'attente (strict(true), ainsi la tâche ne sera pas exécutée), ou bien doit-elle y rester jusqu'à ce que la charge moyenne du système permette son exécution (strict(false)) ?
timezone Lancer la tâche dans le fuseau horaire fourni. timezone-name est une chaîne qui doit être valide du point de vue de la variable d'environnement TZ
until Définir le délai d'attente maximal pour les valeurs de charge système. Si le délai est dépassé, la tâche sera lancée indépendemment de la charge système. Définir until à 0 pour désactiver le délai d'attente.
volatile Activé, fcron ne retient pas le temps écoulé depuis la dernière exécution des tâches « volatiles » entre deux démarrages de fcron, et agit comme si les lignes avaient été fraîchement ajoutées à chaque démarrage de fcron. Utile lorsque fcron est lancé à partir d'un script qui tourne, par exemple, seulement pendant une connexion à Internet non permanente : l'exécution des tâches volatiles est alors basée sur le temps depuis le début de la connexion et le lancement de fcron plutôt que sur le temps absolu. Enfin, veuillez noter que cette option s'associe bien à l'option first.

Exemple de fichier fcrontab

Utiliser /bin/bash
SHELL=/bin/bash
Envoyer la sortie par mail à l'utilisateur thib, quelque soit le propriétaire de ce fcrontab.
!mailto(thib)
Définir une variable équivalente à "Salut thib et paul !" les caractères newline sont échappés avec une barre oblique inverse "\" et les guillemets servent à conserver les espaces de début et de fin de chaîne
TEXT= " Salut\
thib et\
paul ! "
On veut utiliser la file d'attente séquentielle mais pas l'option bootrun
!serial(true),b(0)
Lancer la première fois après 5 minutes de fonctionnement du système, puis toutes les heures par la suite
@first(5) 1h echo "Lancer toutes les heures"
Lancer tous les jours
@ 1d echo "fcron quotidien"
Lancer une fois dans la matinée et une fois dans l'après-midi si le système est en fonctionnement à n'importe quel moment pendant ces intervalles de temps
%hours * 8-12,14-18 * * * echo "Hé patron, je bosse aujourd'hui !"
Lancer une fois par semaine à l'heure du déjeuner
%weekly * 12-13 echo "J'ai laissé allumé mon système au moins une fois\
à l'heure du déjeuner cette semaine."
Lancer tous les samedi et dimanche à 9:05
5 9 * * sat,sun echo "Bonjour Thibault !"
Lancer tous les jours pairs du mois de mars à 18:00, sauf le 16
0 18 2-30/2 16 Mar * echo "Il est temps de se rentrer à la maison !"
La ligne précédente est équivalente à
& 0 18 2-30/2 16 Mar * echo "Il est temps de se rentrer à la maison !"
Mettre toutes les options à leur valeur par défaut et définir runfreq pour les lignes qui vont suivre
!reset,runfreq(7)
Lancer une fois toutes les 7 correspondances (grâce à la déclaration précédente), ainsi, si le système est en fonctionnement tous les jours à 10 heures,
La commande sera lancée une fois par semaine
& 0 10 * * * echo "Si vous avez vu ce message pour la dernière fois il y a 7 jours,\
c'est que cette machine a fonctionné tous les jours à 10 heures durant la dernière semaine.\
Si vous avez eu ce message il y a 8 jours, c'est que cette machine n'a pas fonctionné\
un jour à 10:00 heures depuis le dernier message, etc."
Attendre toutes les heures que la charge système moyenne sur 5 minutes soit inférieure à 0.9
@lavg5(0.9) 1h echo "La charge moyenne système est faible"
Attendre au maximum 5 heures chaque jour une baisse de la charge système
@lavgand,lavg(1,2.0,3.0),until(5h) 1d echo "La charge système vient de diminuer"
Attendre le meilleur moment pour lancer une tâche lourde
@lavgor,lavg(0.8,1.2,1.5),nice(10) 1w echo "C'est une très lourde tâche"
Lancer une fois toutes les nuits soit entre 21:00 et 23:00, soit entre 3:00 et 6:00
%nightly,lavg(1.5,2,2) * 21-23,3-6 echo "Il est temps de récupérer\
la dernière version de Mozilla !"
^
08 février 2015

htmlpdflatexmanmd




fence_legacy

fence_legacy

Helper qui présente une interface style RHCS pour les plugins stonith. Ne devrait jamais être invoqué par l'utilisateur directement

OPTIONS

-t sub_agent Sous agent
-n name Nom du nœud
-o on, off, reset, stat, hostlist
-s Commande stonith
-q mode silencieux
^
02 novembre 2016

htmlpdflatexmanmd




filefrag

filefrag

Reporter la fragmentation de fichier

OPTIONS

-B Force l'utilisation de l'ancien ioctl FIBMAP au lieu de FIEMAP
-bblocksize Utilise la taille de blocks spécifié en octets au lieu de la taille de block du système de fichier.
-e  Affiche au format étendus
-k Utilise une taille de block de 1024 octets
-s Synchronise le fichier avec de demander le mappage
-v mode verbeux
-x Affiche le mappage des attributs étendus
-X Affiche les numéro de block étendus au format hexadécimal.
^
19 octobre 2016

htmlpdflatexmanmd




find

find

Outil de recherche de fichiers

OPTIONS

-P Ne jamais suivre les liens. C'est le mode par défaut.
-L Suit les liens symboliques. cette option implique -noleaf. le prédicat -type matche toujours le type de fichier pointé par le lien
-H Ne pas suivre les liens symboliques, excepté en traitant les arguments de la ligne de commande.
-D debugopts Affiche des informations de diagnostique; peut être utile pour diagnostiquer un problème. Les options valides sont:

        exec informations liées à -exec, -execdir, -ok et -okdir
        opt informations liées à l'optimisation de l'arborescence d'expression
        rates sommaire indiquant la fréquence de réussite et d'échec de chaque prédicat
        search Navigue dans l'arborescence en mode verbeux
        stat affiche des messages quand les fichiers sont examinés avec les appels système stat et lstat.
        tree Affiche l'arborescence d'expression sous sa forme originale et optimisée

-Olevel Active l'optimisation de requête. find réordonne les tests pour accélérer l'exécution tout en préservant l'effet général, c'est à dire que les prédicats ayant des conséquences ne sont pas réordonnés relativement entre eux. Les optimisations sont formés à chaque niveau d'optimisation comme suit:

        0 Équivalent à l'optimisation 1
        1 Niveau par défaut. Les expressions sont réordonnés pour que les tests basés seulement sur les noms des fichiers (par exemple -name et -regex) sont effectués en premier
        2 Les tests -type ou -xtype sont effectués après les tests basés seulement sur les noms des fichiers, mais avant les tests qui nécessitent des informations sur l'inode. Dans de nombreux Unix récents, les types de fichiers sont retournés par readdir() et ces prédicats sont plus rapides à évaluer.
        3 L'ordre des tests est modifié pour que les tests rapides soient effectués en premier et les plus coûteux en derniers.

Expression

   La partie de la ligne de commande après la liste des points de départ est l'expression. C'est le type de spécification de requête décrivant comment les fichiers correspondent et ce que l'on fait avec ces fichiers. Une expression est composée d'une séquence d'éléments:

tests Les tests retournent vrai ou faux, généralement sur la base de propriétés d'un fichier.
actions Les actions ont des effets supplémentaire (comme afficher quelque chose) et retournent vrai ou faux.
Options globales Les options globales affectent les opérations de tests et les actions. Les options globales retournent toujours vrai.
Options positionnelles Affectent seulement les tests ou actions qui les suivent. Retournent toujours vrai.
Opérateurs Les opérateurs joignent des éléments dans l'expression.

Options positionnelles

-daystart Mesure de temp (pour -amin, -atime, -cmin, -mmin, et -mtime) depuis le début du jour au-lieu des dernières 24 heures. N'affecte que les tests qui apparaîssent ultérieurement dans la ligne de commande.
-regextype type Change la syntaxe de l'expression régulière comprises par les tests -regex et -iregex apparaîssant plus loin sur la ligne de commande. -regextype help affiche les types d'expression régulières connus.
-warn, -nowarn Active/désactive les messages d'alerte. Ces warning ne s'appliquent qu'à l'utilisation de la ligne de commande.

Options globales

-d, -depth Traite chaque contenu de répertoire avant le répertoire lui-même. -delete implique -depth
-ignore_readdir_race N'affiche pas de messages d'erreur quand find ne parvient pas à obtenir les statistiques d'un fichier.
-maxdepth levels niveau de sous-répertoires maximum à parcourir sous les points de départs. 0 signifie seulement le point de départ.
-mindepth levels N'applique pas d'action ou test aux niveaux inférieurs. 1 signifie de traiter tous les fichiers excepté au point de départ.
-mount, -xdev Ne descend pas les répertoires dans d'autres systèmes de fichier.
-noignore_readdir_race Désactive l'effet de -ignore_readdir_race
-noleaf N'optimise pas en assumant que les répertoires contenant 2 sous-répertoires de moins que leur nombre de lien dur. Cette option est nécessaire lors de recherches dans des systèmes de fichier qui ne suivent pas les conventions UNIX, tel que les systèmes de fichier CD-ROM, MS-DOS ou AFS.

Tests

+n plus grand que n
-n  plus petit que n
n exactement n
-amin n le fichier a été accédé il y a n minutes
-anewer file le dernier accès est plus récent de sa dernière modification
-atime n le fichier a été accédé il y a n*24 heures. +1 signifie un accès il y a au moins 2 jours.
-cmin n Le status du fichier a été changé il y a n minutes
-cnewer file Le status du fichier a été changé plus récemment que sa modification. Si le fichier est un lien symbolique et que l'option -H ou -L est présente, le temps du fichier pointé est toujours utilisé
-ctime n Le status du fichier a été changé il y a n*24 heure.
-empty le fichier est vide et est un fichier régulier ou un répertoire
-executable le bit de permission est mis. Prend en compte les listes de contrôles d'accès et autres permissions que -perm ignore. Utilise access(2)
-false Toujours faux
-fstype type Le fichier est sur système de fichier de type spécifié.
-gid n Le GID du fichier est n
-group name le groupe propriétaire est le nom spécifié
-ilname pattern Comme -lname, mais le match est insensible à la casse. Si -L est présent, ce test retourne faux sauf si le lien symbolique est cassé
-iname pattern comme -name, mais de match est insensible à la casse.
-inum n le fichier a le numéro d'inode n
-ipath pattern, -iwholename pattern comme -path, mais le match est insensible à la casse.
-iregex pattern comme -regex, mais le match est insensible à la casse.
-links n le fichier a n liens
-lname pattern le fichier est un lien symbolique dont le contenu match le motif. Si -L est présent, ce test retourne faux sauf si le lien symbolique est cassé
-mmin n Les données du fichier ont été modifiés il y a n minutes
-mtime n Les données du fichier ont été modifiés il y a n*24 heures.
-name pattern La base du nom de fichier ( le chemin avec les répertoires enlevés) correspond au motif.
-newer file Le fichier a été modifié plus récemment que le fichier. avec un lien symbolique et -L ou -H, utilise la cible.
-newerXY reference Réussis si l'horodatage X du fichier à considérer est plus récent que l'horodatage Y du fichier référence. Les lettres X et Y peuvent être une des lettres suivantes:

        a atime du fichier référence
        B Date de création du fichier référence
        c ctime du fichier référence
        m mtime du fichier référence
        t Référence est interprétée directement comme un temps

-nogroup Aucun groupe ne correspond au GID du fichier
-nouser Aucun utilisateur ne correspond au UID du fichier
-path pattern, -wholename pattern Le nom du fichier matche le pattern.
-perm mode Les bits de permission du fichier sont exactement le mode spécifié.
-perm -mode Tous les bits de permissions sont définis pour le fichier.
-perm /mode Un des bits de permission sont définis pour le fichier
-readable Match les fichiers accessibles en lecture. Prend en compte les listes de contrôle d'accès et d'autres permissions
-regex pattern Le nom du fichier match le motif. C'est un match sur le chemin entier
-samefile name Le fichier réfère au même inode que name. avec -L, inclus les liens symboliques
-size n[cwbkMG] Le fichier utilise n unités d'espace, arrondi. Les suffixes suivants peuvent être utilisés:

        b block de 512 octets
        c Octet
        w Mots de 2 octets
        k Kio
        M Mio
        G Gio

-true Toujours vrai
-type c Le fichier est de type c (utiliser des virgules pour spécifier plusieurs types):

        b Périphérique block
        c Périphérique caractère
        d répertoire
        p pipe nommé
        f fichier régulier
        l liens symboliques
        s socket

-uid n L'UID du fichier est n
-used n Le fichier a été accédé n jours après que son status ait été changé
-user uname Le propriétaire du fichier est uname (UID permis)
-writable Matche les fichiers accessible en écriture. Prend en compte les listes de contrôle d'accès et d'autres permissions
-xtype c Idem à -type sauf si le fichier est un lien symbolique. Pour ces liens: si -H ou -P est spécifié, vrai si le fichier est un lien vers un fichier de type c; si -L est donné, vrai si c est 'l'.
-context pattern matche le contexte de sécurité du fichier.

Actions

-delete Supprime des fichiers; vrai si la suppresion réussie.
-exec command ; Éxecute la commande. vrai si 0 est retourné. La chaîne '{}' est remplacée par le nom du fichier courant.
-exec command {} + Variante, mais la ligne de commande est construite en ajoutant chaque fichier sélectionné à la fin. Seule une instance de '{}' est permise. Retourne toujours vrai
-execdir command ;, -execdir command {} + comme -exec, mais la commande est lancée pour le sous-répertoire contenant le fichier correspondant, qui est normalement le répertoire courant. C'est une méthode plus sécurisé pour invoquer des commandes. Comme avec -exec, la forme '+' permet de traiter plusieurs fichiers à la fois.
-fls file Vrai; comme -ls mais écris dans fichier comme -fprint. le fichier de sortie est toujours créé, même si le prédicat n'est jamais matché.
-fprint file Vrai; affiche le nom du fichier dans le fichier spécifié. Si le fichier n'existe pas, il est créé. S'il existe, il est tronqué. /dev/stdout et /dev/stderr sont gérés spécialement
-fprint0 file Vrai; comme -print0 mais écrit dans le fichier comme -fprint.
-fprintf file format Vrai; comme -printf mais écrit dans le fichier comme -fprint.
-ls Vrai; liste les fichiers courants au format ls -dils sur la sortie standard. Les compteurs de block sont des blocks de 1K, saux si POSIXLY_CORRECT est définis, auquel cas les blocks de 512 octets sont utilisé
-ok command ; Comme -exec mais demande à l'utilisateur avant.
-okdir command ; comme -execdir, mais demande à l'utilisateur avant.
-print Vrai; affiche le nom du fichier sur la sortie standard, suivi d'une nouvelle ligne, à la différence de print0
-print0 Vrai; affiche le nom de fichier sur la sortie standard, suivi par un caractère null. Correspond à l'option -0 de xargs
-printf format Vrai; affiche le format sur la sortie standard. Interprète les directives '\' et '%'.

        \a alert (bell)
        \b backspace, ascii 8
        \c n'affiche pas la suite
        \f form feed
        \n nouvelle ligne
        \r retour charriot
        \t tabulation horizontale
        \v Tabulation verticale
        \0 ASCII NUL
        \\ le caractère '\'
        \nnn Le caractère 8bits dont la valeur est nnn en octal
        %% le caractère %
        %a Date de dernier accès au fichier, au format retourné par la fonction ctime
        %Ak Date de dernier accès au fichier, au format spécifié par k

                @ Secondes depuis le 1 Janvier 1970, 00:00 GMT, avec partie fractionnelle.
                H Heure (00..23)
                I Heure (01..12)
                k Heure (0..23)
                l heure (1..12)
                M minute (00..59)
                p AM ou PM local
                r Temps, 12 heures (hh:mm:ss [AP]M)
                S Secondes (00.00 .. 61.00). Il y a une partie fractionnelle
                T Heure, 24 heure (hh:mm:ss.xxxxxxxxxx)
                + Date et heure, séparé par un '+', par exemple '2010-04-23+17:45:45.0'.
                X Temps local (H:M:S). Le second champ inclus une partie fractionnelle
                Z Timezone
                a Nom de la semaine abrégée (Sun..Sat)
                A Nom complet de la semaine (Sunday..Saturday)
                b Nom du mois abrégée (Jan..Dec)
                B Nom complet du mois (January..December)
                c Date et heure locale (Sat Nov 04 12:02:33 EST 1989). Le format est le même que pour ctime(3)
                d Jour du mois (01..31)
                D date (mm/dd/yy)
                h Idem à b
                j Jour de l'année (001..366)
                m mois (01..12)
                U Numéro de la semaine avec dimanche comme premier jour de la semaine (00..53)
                w Jour de la semaine (0..6)
                W Numéro de semaine avec lundi comme premier jour de la semaine (00..53)
                x Représentation de date locale (mm/dd/yy)
                y 2 derniers chiffres de l'année (00..99)
                Y Année (1970...)

        %b quantité d'espaces utilisé par ce fichier en blocks de 512 octets.
        %c Date de dernier changement du status du fichier au format retourné par la fonction ctime
        %Ck Date de dernier changement du status du fichier au format spécifié par k
        %d Profondeur du fichier dans l'arborescence des répertoires, 0 signifiant le point de départ
        %D Numéro de périphérique sur lequel le fichier existe ( le champ st_dev de la struct stat), en décimal.
        %f Nom du fichier avec les répertoires enlevés (basename)
        %F Type de système de fichier sur lequel le fichier réside
        %g Nom du groupe du fichier
        %G GID du fichier
        %h Chemin du fichier (dirname)
        %H Point de départ sous lequel le fichier a été trouvé
        %i numéro d'inode du fichier
        %k Quantité d'espaces disque utilisé par ce fichier en blocks de 1Kio.
        %l Objet de lien symbolique (chaîne vide si le fichier n'est pas un lien symbolique)
        %m bits de permissions du fichier en octal.
        %M Permissions du fichier sous forme symbolique, comme ls.
        %n Nombre de liens dur vers le fichier
        %p Nom du fichier
        %P Nom du fichier avec le nom du point de départ sous lequel il a été trouvé supprimé
        %s Taille du fichier en octets
        %S BLOCKSIZE*st_blocks / st_size. fichier sans sparse.
        %t Date de dernière modification du fichier au format retourné par la fonction ctime
        %Tk Date de dernière modification du fichier au format k
        %u Nom propriétaire du fichier
        %U UID du propriétaire du fichier
        %y Type du fichier, comme ls -l. U=unknown type
        %Y Type de fichier, et suit les liens symboliques L=loop, N=nonexistent
        %Z Contexte de sécurité du fichier
        %{ %[ %( Réservé

-prune Vrai; si le fichier est un répertoire, ne descend pas dedans. si -depth est donné, false.
-quit Quitte immédiatement.

Opérateurs

( expr ) Forcer la précédence. Vu que les parenthèse sont spéciales, il est nécessaire des les échapper: \(...\)
! EXPR vrai si EXPR est faux
-not expr Idem à !, mais non conforme POSIX
expr1 expr2 2 expressions sur une ligne sont jointes avec un AND implicite; expr2 n'est pas évalué si expr1 est faux
expr1 -a expr2 idem
expr1 -and expr2 idem, mais non conforme POSIX
expr1 -o expr2 OU; expr2 n'est pas évalué si expr1 est vrai
expr1 -or expr2 idem, mais non conforme POSIX
expr1 , expr2 Liste, les 2 expressions sont toujours évaluées. La valeur de expr1 est ignorée; la valeur de la liste est la valeur de expr2.

Noms de fichier non-usuels

   De nombreuses actions de find résultent dans l'affichage de données qui sont sous le contrôle d'autres utilisateurs. Cela inclus les noms de fichiers, tailles, dates de modification, etc. Les noms de fichier sont potentiellement un problème vu qu'ils peuvent contenir n'importe quel caractère excepté \0 et /. Les caractères non-usuels peuvent créer des effets indésirables. (par exemple, changer les paramètres des fonctions clé de certains terminaux).

-print0, -fprint0 Affiche toujours le nom de fichier exacte, inchangé, même si la sortie va dans un terminal.
-ls, -fls Les caractères non usuels sont toujours échappés, les espaces blanc échappés, et les guillemets doubles sont affiché en style C échappé.
-printf, -fprintf Si la sortie n'est pas un terminal, elle est affichée tel quelle. Sinon, le résultat dépend des directives utilisées. %D, %F, %g, %G, %H, %Y, et %y expandent aux valeurs qui sont sous le contrôle du propriétaire du fichier, et sont affichés tel quels. %a, %b, %c, %d, %i, %k, %m, %M, %n, %s, %t, %u et %U ont des valeurs sous le contrôle du propriétaire du fichier mais qui ne peuvent pas être utilisé pour envoyer des données arbitraires au terminal, et sont donc affiché tel quels. %f, %h, %l, %p et %P sont quotés.
-print, -fprint Le quoting est géré de la même manière que pour -printf et -fprintf.
-ok et -okdir AFffiche les noms de fichier tels quels

Variables d'environnement

LANG Spécifie la locale
LC_ALL Spécifie la locale
LC_COLLATE Spécifie la locale pour la catégorie LC_COLLATE
LC_CTYPE Langage à utiliser pour déterminer le jeu de caractères
LC_MESSAGES Spécifie la locale pour la catégorie LC_MESSAGES
NLSPATH Détermine l'emplacement des catalogues de message d'internationalisation
PATH Les chemins de recherche pour les commandes
POSIXLY_CORRECT Strictement Conforme à POSIX
TZ Affecte le timezone utilisé

Exemples

Trouver les fichiers nommés core sous /tmp et les supprimer
find /tmp -name core -type f -print | xargs /bin/rm -f
Lancer file sur tous les fichiers sous le répertoire courant.
find . -type f -exec file '{}' \;
traverser le système de fichier, lister les fichiers setuid et les répertoires dans /root/suid.txt et les grands fichiers dans /root/big.txt
find / \( -perm -4000 -fprintf /root/suid.txt '%#m %u %p\n' \) , \( -size +100M -fprintf /root/big.txt '%-10s %p\n' \)
Recherche les fichiers dans le home qui ont été modifiés dans les dernière 24 heures
find $HOME -mtime 0
Rechercher les fichiers qui ont les permissions de lecture et écriture pour leur propriétaire, groupe, mais seulement en lecture pour les autres.
find . -perm 664
Rechercher les fichier en écriture pour tout le monde
find . -perm /222
find . -perm /220
find . -perm /u+w,g+w
find . -perm /u=wg=w
Rechercher les fichier en lecture pour tout le monte, ayant au moins un bit d'écriture mis, mais non exécutable
find . -perm -444 -perm /222 ! -perm /111
find . -perm -a+r -perm /a+w ! -perm /a+x
Copier le contenu de /source-dir dans /dest-dir, mais omet les fichiers et répertoires nommés .snapshot et leur contenu. Omet également les fichier ou répertoires se terminant par ~, mais pas leur contenu.
cd /source-dir; find . -name .snapshot -prune -o \( \! -name *~ -print0 \)| cpio -pmd0 /dest-dir

Codes de sortie

   find quitte avec un status de 0 si tous les fichier ont été traité avec succès, Supérieur à 0 si une erreur se produit.
^
07 octobre 2011

htmlpdflatexmanmd




findfs

findfs

Trouve un système de fichier par label ou UUID

   findfs recherche les périphériques block dans le système en recherchant un système de fichier ou une partition avec le tag spécifié. Les tags supportés sont:

Options

LABEL un label de système de fichier
UUID Un UUID de système de fichier
PARTUUID Un UUID de partition
PARTLABEL Un label de partition

   Si un système de fichier ou une partition est trouvé, le nom du périphérique sera affiché sur la sortie standard. La vue d'ensemble complète des systèmes de fichiers et des partitions peut par exemple être obtenus avec lsblk --fs, partix --show ‹disk›, blkid

Codes de retour

0 Réussite
1 Le label ou l'uuid est introuvable
3 Erreur d'utilisation, mauvais nombre d'argument ou option inconnue

Variables d'environnement

LIBBLKID_DEBUG =all Activer la sortie de débogage de libblkid
^
07 mai 2016

htmlpdflatexmanmd




findmnt

findmnt

Touver un système de fichier

   findmnt liste tous les systèmes de fichier montés ou recherche un système de fichier. La commande findmnt est capable de rechercher dans /etc/fstab, /etc/mtab, /proc/self/mountinfo. Si le périphérique ou son point de montage n'est pas donné, tous les systèmes de fichier sont affichés. Le périphérique peut être spécifié par nom de périphérique, maj:min, label ou uuid de système de fichier, ou partuuid ou partlabel de partition.

OPTIONS

-A, --all Désactive tous les filtres intégrés et affiche tous les systèmes de fichier.
-a, --ascii Utilise les caractères ascii pour formater l'arborescence
-b, --bytes Affiche les colonnes SIZE, USED et AVAIL en octet au lieu du format human-readable.
-c, --canonicalize Canonise tous les chemins affichés
-D, --df Imite la sortie de df. Équivalent à -o SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET mais sur tous les pseudo systèmes de fichier.
-d, --direction word Direction de recherche soit forward, soit backward
-e, --evaluate Convertit tous les tags (LABEL, UUID, PARTUUID ou PARTLABEL) en nom de périphérique
-F, --tab-file path Recherche dans un fichier alternatif.
-f, --first-only Affiche seulement le premier système de fichier qui correspond
-i, --invert Inverse le sens de correspondance
-k, --kernel Recherche dans /proc/self/mountinfo.
-l, --list Utilise le format de sortie en liste.
-m, --mtab Recherche dans /etc/mtab
-N, --task tid Utilise un espace de nom alternatif /proc/‹tid›/mountinfo au lieur du défaut /proc/self/mountinfo.
-n, --noheadings N'affiche pas la ligne d'en-tête
-O, --options list Limite de jeu de systèmes de fichier affiché.
-o, --output Définis les colonnes affichées.
-P, --pairs Utilise le format clé="valeur"
-p, --poll[=list] Monitor les changements dans /proc/self/mountinfo. Les actions supportées sont mount, umount, remount et move.
-R, --submounts Affiche récursivement tous les sous-montages pour les systèmes de fichier sélectionnés. Les restrictions définies par les options -t, -O, -S, -T et --direction ne sont pas appliqués aux sous-montages. N'a pas d'effet pour --mtab ou --fstab.
-r, --raw Utilise le format brut.
-S, --source spec Définis explicitement la cible du montage.
-t, --types list Limite le jeu de systèmes de fichiers affichés. Plus d'un type peut être spécifié. La liste peut être préfixé avec 'no' pour exclure les types.
-u, --notruncate ne tronque par le texte dans les colonnes.
-v, --nofsroot N'affiche pas un [/dir] dans la colonne SOURCE pour les sous-volume bind-mounts ou btrfs
-w, --timeout milliseconds Spécifie la limite maximale de temps pour lequel --poll se bloque.

Exemples

Affiche tous les systèmes de fichier NFS dans /etc/fstab
findmnt --fstab -t nfs
Affiche tous les systèmes de fichier dans /etc/fstab où le répertoire de montage est /mnt/foo. Affiche également les montages liés où /mnt/foo est une source
findmnt --fstab /mnt/foo
Affiche tous les systèmes de fichier dans /etc/fstab où le répertoire de montage est /mnt/foo
findmnt --fstab --target /mnt/foo
Affiche tous les systèmes de fichier dans /etc/fstab et convertit LABEL= et UUID= en nom de périphérique
findmnt --fstab --evaluate
Affiche seulement le point de montage œu le système de fichier avec le label "/boot" est monté.
findmnt -n --raw --evaluate --output=target LABEL=/boot
Monitor les montage, démontage, remontage et déplacement dans /mnt/foo
findmnt --poll --target /mnt/foo
Attend le démontage de /mnt/foo
findmnt --poll=umount --first-only --target /mnt/foo
Monitor les remontages en mode lecture-seule sur tous les systèmes de fichier ext3
findmnt --poll=remount -t ext3 -O ro

Variables d'environnement

LIBMOUNT_FSTAB Écrase le chemin par défaut du fichier fstab
LIBMOUNT_MTAB Écrase le chemin par défaut du fichier mtab
LIBMOUNT_DEBUG à 0xffff active la sortie de débuggage pour findmnt
^
10 janvier 2017

htmlpdflatexmanmd




firewall-applet

firewall-applet

Applet firewalld

   firewalld-applet est un applet graphique pour afficher le status de firewalld. Il ne possède pas d'option.

QSettings

   firewall-applet a des paramètres additionnels pour adapter l'apparence. QSettings est utilisé et les stocke dans ~/.config/firewall/applet.conf. Le fichier est automatiquement rechargé s'il est changé. Il y a également un fichier global /etc/firewall/applet.conf, qui contient les valeurs par défaut. les paramètres dans ce fichier sont écrasés par les paramètres dans le fichier utilisateur.

Exemple de fichier applet.conf
[General]
notifications=true
show-inactive=true

notifications active les notifications. Défaut: false
show-inactive Affiche l'applet même si firewalld ne fonctionne pas. Défaut: false
shields-up nom de la zone shields-up si shields-up est activé. Défaut: block
shelds-down Nom de la zone shields-down si shields-up a été désactivé
blink Si permis, l'icône clignote si la connection à filewalld est perdue ou si le mode panic a été activé ou désactivé. Défaut: false
blink-count Nombre de clignotement si blink est activé. Défaut: 5
^
10 janvier 2017

htmlpdflatexmanmd




firewallctl

firewallctl

Client en ligne de commande pour firewalld

   Il y a des options qui peuvent être spécifiées plusieurs fois. Le code de sortie est 0 s'il y a au moins un élément qui réussit. les erreurs ALREADY_ENABLED, NOT_ENABLED et ZONE_ALREADY_SET sont traité comme réussis.

Options générales

-v, --verbose mode verbeux
-q, --quiet N'affiche pas de messages de status

Option de status

state Vérifie si le service firewalld est actif

Option de rechargement

reload [ -c | --complete ] Recharge les règle firemall et conserve les informations d'état. La configuration permanente devient la configuration courante. -c recharge complètement le firewall, incluant les modules netfilter.

Option runtime-to-permanent

runtime-to-permanent Sauve la configuration active en tant que configuration permanente.

Options de liste

list zones [ -a | --active | -p | --permanent ] Affiche la liste des zones prédéfinies. -a n'affiche que les zones actives, -p n'affiche que les zones dans l'environnement permanent
list services [ -p | --permanent ] Affiche la liste des services prédéfinis.
list ipsets [ -p | --permanent ] Affiche la liste des ipsets prédéfinis
list helpers [ -p | --permanent ] Affiche la liste des helpers
list icmptypes [ -p | --permanent ] Affiche la liste des types icmp prédéfinis

Options d'informations

info zone ‹zone› [ -p | --permanent ] Affiche des informations sur la zone
info zones [ -a | --active | -p | --permanent ] Affiche des informations sur les zones
info service service [ -p | --permanent ] Affiche des informations sur le service spécifié
info services [ -p | --permanent ] Affiche des informations sur les services
info ipset ipset [ -p | --permanent ] Affiche des informations sur l'ipset spécifié
info ipsets [ -p | --permanent ] Affiche des informations sur les ipsets
info helper helper [ -p | --permanent ] Affiche des informations sur l'helper spécifié
info helpers [ -p | --permanent ] Affiche des informations sur les helper
info icmptype icmptype [ -p | --permanent ] Affiche des informations sur le type icmp spécifié
info icmptypes [ -p | --permanent ] Affiche des informations sur les types icmp

Options de zone

zone zone [ -p | --permanent ] add element.. [ --timeout=timeval ] Ajoute un élément ou de nombreux éléments de même type à une zone avec un timeout optionnel. Si la zone est une chaîne vide, la zone par défaut est utilisée. -p ajoute les éléments dans l'environnement permanent.
zone zone [ -p | --permanent ] remove element ... Supprime un ou plusieurs éléments d'une zone.
zone zone [ -p | --permanent ] query element ... Affiche si le ou les éléments sont activés dans la zone
zone zone [ -p | --permanent ] get { short | description } Affiche une description de la zone
zone zone [ -p | --permanent ] set { short | description } text Définis un description pour une zone
zone zone [ -p | --permanent ] list { interfaces | sources | services | ports | protocols | source-ports | rich-rules | forward-ports | icmp-blocks } Retourne la liste des éléments ajoutés pour la zone
zone zone { -p | --permanent } load-defaults Charge les paramètres de la zone par défaut ou affiche l'erreur NO_DEFAULTS

Éléments de zone

interface ‹interface› Nom d'une interface. Si l'interface est sous le contrôle de NetworkManager, elle doit d'abord être connectée.
source { address[/mask] | MAC | ipset:ipset } Une adresse ou plage d'adresse source ou une adresse MAC ou un ipset.
service ‹service› Nom d'un service
port portid[-portid]/protocol Port, plage de port ou nom de protocole
source-port portid[-portid]/protocol Port source
rich-rule 'rule' Règle en langage rich
masquerade Masquerading IPv4
forward-port port=portid[-portid]:proto=protocol[:toport=portid[-portid]][:toaddr=address[/mask]] Port forward ipv4
icmp-block icmptype block de type ICMP
icmp-block-inversion Inverse les blocks de type icmp

Options de service

service service [ -p | --permanent ] add element... Ajoute un ou plusiuers éléments à un service
service service [ -p | --permanent ] remove element... Supprime un ou plusieurs éléments d'un service
service service [ -p | --permanent ] query element... Affiche si un ou plusieurs éléments sont activés dans le service
service service [ -p | --permanent ] get { short | description } Affiche la description du service
service service [ -p | --permanent ] set { short | description } text Définis la description pour un service
service service [ -p | --permanent ] list { ports | protocols | source-ports | modules | destinations } Retourne la liste des éléments ajoutés pour un service
service service { -p | --permanent } load-defaults Charge les paramètres par défaut du service ou affiche NO_DEFAULTS

Éléments de service

port portid[-portid]/protocol Port ou plage de port / tcp|udp
protocol protocol Protocole supporté par le système
source-port portid[-portid]/protocol Port ou plage de port source / tcp|udp
module module Module netfilter
destination ipv:address[/mask] Adresse de destination. ipv=ipv4 ou ipv6

Options ipset

ipset ipset [ -p | --permanent ] add { entry entry | entries-from-file filename }... Ajoute une ou plusieurs entrées dans l'ipset
ipset ipset [ -p | --permanent ] remove { entry entry | entries-from-file filename | all }... Supprime une ou plusieurs entrées dans l'ipset
ipset ipset [ -p | --permanent ] query { entry entry | entries-from-file filename }... Affiche si la ou les entrées sont dans l'ipset
ipset ipset [ -p | --permanent ] get { short | description } Retourne la description de l'ipset
ipset ipset [ -p | --permanent ] set { short | description } text Définis la description de l'ipset
ipset ipset [ -p | --permanent ] list entries Liste les entrées ajoutées dans l'ipset
ipset ipset { -p | --permanent } load-defaults Charge les paramètres par défaut pour l'ipset ou retourne NO_DEFAULTS

Entrées ipset

ip[/cidr] Ajoute un ip ou une plage d'ip.
ip[/cidr] | fromaddr-toaddr idem en spécifiant les ip source et de destination
mac L'entrée est une adresse MAC

Options helper

helper helper -p | --permanent { add | remove } port portid[-portid]/protocol Ajoute ou supprime le port au helper.
helper helper [ -p | --permanent ] query port portid[-portid]/protocol Affiche si le port est mis dans le helper
helper helper [ -p | --permanent ] get { short | description } Affiche la description du helper
helper helper [ -p | --permanent ] get family Affiche la famille du helper
helper helper [ -p | --permanent ] get module Affiche le module netfilter du helper
helper helper -p | --permanent set { short | description } text Définis la description du helper
helper helper -p | --permanent set family Définis la famille du helper
helper helper -p | --permanent set module Définis le module helper netfilter pour le helper
helper helper [ -p | --permanent ] list ports Retourne la liste des ports ajoutés au helper
helper helper { -p | --permanent } load-defaults Charge les paramètres par défaut du helper ou retourne NO_DEFAULTS

Options icmptype

icmptype icmptype [ -p | --permanent ] { add | remove } destination { ipv4 | ipv6 } Ajoute ou supprime la destination au icmptype.
icmptype icmptype [ -p | --permanent ] query destination { ipv4 | ipv6 } Affiche si la destination est dans le icmptype
icmptype icmptype [ -p | --permanent ] get { short | description } Affiche la description du icmptype
icmptype icmptype [ -p | --permanent ] set { short | description } text Définis la description du icmptype
icmptype icmptype [ -p | --permanent ] list destinations Affiche la liste des destinations ajoutées pour l'icmptype
icmptype icmptype { -p | --permanent } load-defaults Charge le paramètres par défaut du icmptype ou affiche NO_DEFAULTS

Options new

new { -p | --permanent } zone { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute une zone permanente.
new { -p | --permanent } service { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un service permanent
new { -p | --permanent } ipset { { -n | --name } name { -t | --type } ipsettype [ { -o | --option } option[=value] ] | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un ipset permanent
new { -p | --permanent } icmptype { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un icmptype permanent

Options delete

delete { -p | --permanent } zone zone Supprime une zone permanente
delete { -p | --permanent } service service Supprime un service permanent
delete { -p | --permanent } ipset ipset Supprime un ipset permanent
delete { -p | --permanent } icmptype icmptype Supprime un ipset permanent

Options direct

direct [ -p | --permanent ] { add | remove } chain { ipv4 | ipv6 | eb } table chain Ajoute une nouvelle chaîne nommé à la table spécifiée.
direct [ -p | --permanent ] query chain { ipv4 | ipv6 | eb } table chain Affiche si un chaîne existe dans la table spécifiée
direct [ -p | --permanent ] get chains { ipv4 | ipv6 | eb } table Affiche les chaînes ajoutées à la table spécifiée
direct [ -p | --permanent ] get all-chains Récupère toutes les chaînes ajoutées à toutes les tables
direct [ -p | --permanent ] { add | remove } rule { ipv4 | ipv6 | eb } table chain priority args Ajoute ou supprime une règle à la chaîne spécifiée. La priorité est utilisée pour l'ordre des règles (0 étant la première)
direct [ -p | --permanent ] query rule { ipv4 | ipv6 | eb } table chain priority args Affiche si une règle avec la priorité et les arguments existe dans la chaîne dans la table spécifiés. Retourne 0 si vrai, 1 sinon.
direct [ -p | --permanent ] get all-rules Affiche toutes les règles ajoutées à toutes les chaînes d-ans toutes les tables
direct [ -p | --permanent ] get rules { ipv4 | ipv6 | eb } table chain Affiche les règles ajoutées à la chaîne dans la table spécifiées.
direct [ -p | --permanent ] { add | remove } passthrough { ipv4 | ipv6 | eb } args Ajoute une règle passthrough
direct [ -p | --permanent ] query passthrough { ipv4 | ipv6 | eb } args Affiche une règle passthrough
direct [ -p | --permanent ] get all-passthroughs Affiche toutes les règles passthrough
direct [ -p | --permanent ] get passthroughs { ipv4 | ipv6 | eb } Affiche les règles passthrough pour une valeur ipv
direct passthrough { ipv4 | ipv6 | eb } args Passe une commande au firewall args peut être iptables, ip6tables et ebtables.

Options Lockdown Whitelist

   Les applications locales ou services sont capable de changer la configuration firewall s'ils tournent en root (par exemple libvirt) ou sont authentifiés via PolKit. Avec cette fonctionnalité, les administrateurs peuvent bloquer la configuration du firewall pour que seuls les applications dans la lockdown whitelist soient capable de changer le firewall.

lockdown-whitelist [ -p | --permanent ] { add | remove } element... Ajoute ou supprime un ou plusieurs éléments à la liste
lockdown-whitelist [ -p | --permanent ] query element... Affiche si le ou les éléments sont membres de la liste
lockdown-whitelist [ -p | --permanent ] list { commands | contexts | uids | users } Affiche la liste des membres de la liste

Options de configuration

config set { default-zone zone | lockdown { on | off } | log-denied value | panic { on | off } } Définis une option de configuration firewalld. Les valeurs possibles sont:

        default-zone zone Définis la zone par défaut pour les connexions et les interfaces
        lockdown Active/désactive le lockdown. Noter que par défaut firewall-cmd n'est pas dans la liste.
        log-denied Si activé, les règles de logging sont ajoutées avant les règles de rejet/suppression dans les chaînes INPUT, FORWARD, et OUTPUT pour les règles par défaut. Les valeurs possibles sont all, unicast, broadcast, multicast, et off. Défaut: off.
        panic Active le mode panic. Si activé, tous les paquets entrant et sortant sont supprimés. À activer uniquement en cas de problème sérieux dans le réseau.

config list Liste les options de configuration de firewalld
config get { default-zone | lockdown | log-denied | panic } Afficher les options de configuration de firewalld

Options de paramètrage

        settings list Liste les paramètres de firewalld comme BRIDGE, CleanupOnExit, IPSet, IPSetTypes, IPv4, IPv6, IPv6_rpfilter, IndividualCalls et MinimalMark
        settings get { BRIDGE | CleanupOnExit | IPSet | IPSetTypes | IPv4 | IPv6 | IPv6_rpfilter | IndividualCalls | MinimalMark } AFficher les paramètres de firewalld:

        BRIDGE Affiche si la commutation est disponible
        CleanupOnExit Affiche si CleanupOnExit est activé
        IPSet Affiche si le support ipset est disponible
        IPSetTypes Affiche les types ipsets supportés
        IPv4 Affiche si le support IPv4 est disponible
        IPv6 Affiche si le support IPv6 est disponible
        IPv6_rpfilter Affiche si rpfilter IPv6 est activé
        IndividualCalls Retourne les paramètres d'appel individuels
        MinimalMark Retourne le paramètre de marque minimum

Codes de sortie

0 succès
11 ALREADY_ENABLED
12 NOT_ENABLED
13 COMMAND_FAILED
14 NO_IPV6_NAT
15 PANIC_MODE
16 ZONE_ALREADY_SET
17 UNKNOWN_INTERFACE
18 ZONE_CONFLICT
19 BUILTIN_CHAIN
20 EBTABLES_NO_REJECT
21 NOT_OVERLOADABLE
22 NO_DEFAULTS
23 BUILTIN_ZONE
24 BUILTIN_SERVICE
25 BUILTIN_ICMPTYPE
26 NAME_CONFLICT
27 NAME_MISMATCH
28 PARSE_ERROR
29 ACCESS_DENIED
30 UNKNOWN_SOURCE
31 RT_TO_PERM_FAILED
32 IPSET_WITH_TIMEOUT
33 BUILTIN_IPSET
34 ALREADY_SET
35 MISSING_IMPORT
36 DBUS_ERROR
37 BUILTIN_HELPER
100 INVALID_ACTION
101 INVALID_SERVICE
102 INVALID_PORT
103 INVALID_PROTOCOL
104 INVALID_INTERFACE
105 INVALID_ADDR
106 INVALID_FORWARD
107 INVALID_ICMPTYPE
108 INVALID_TABLE
109 INVALID_CHAIN
110 INVALID_TARGET
111 INVALID_IPV
112 INVALID_ZONE
113 INVALID_PROPERTY
114 INVALID_VALUE
115 INVALID_OBJECT
116 INVALID_NAME
117 INVALID_FILENAME
118 INVALID_DIRECTORY
119 INVALID_TYPE
120 INVALID_SETTING
121 INVALID_DESTINATION
122 INVALID_RULE
123 INVALID_LIMIT
124 INVALID_FAMILY
125 INVALID_LOG_LEVEL
126 INVALID_AUDIT_TYPE
127 INVALID_MARK
128 INVALID_CONTEXT
129 INVALID_COMMAND
130 INVALID_USER
131 INVALID_UID
132 INVALID_MODULE
133 INVALID_PASSTHROUGH
134 INVALID_MAC
135 INVALID_IPSET
136 INVALID_ENTRY
137 INVALID_OPTION
138 INVALID_HELPER
200 MISSING_TABLE
201 MISSING_CHAIN
202 MISSING_PORT
203 MISSING_PROTOCOL
204 MISSING_ADDR
205 MISSING_NAME
206 MISSING_SETTING
207 MISSING_FAMILY
252 NOT_RUNNING
253 NOT_AUTHORIZED
254 UNKNOWN_ERROR
^
09 janvier 2017

htmlpdflatexmanmd




firewalld

firewalld

Gestionnaire de firewall dynamique

   firewalld fournis une gestion dynamique du firewall. Il supporte IPv4 et IPv6.

OPTIONS

--debug[=level] mode debug, de 1 à 10. le debug est écris dans /var/log/firewalld
--debug-gc Affiche les informations sur les fuites du collecteur. Le collecteur se lance toutes les 10 secondes, et s'il y a des fuites, il les affiche.
--nofork ne fork pas le service
--nopid désactive l'écriture du fichier pid.

Concepts

   firewalld a une interface D-Bus pour la configuration du firewall des services et applications. Il a également un client pour l'utilisateur. Les services ou applications utilisant déjà D-Bus peuvent demander des changements au firewall directement via D-Bus.

   firewalld fournis un suppport pour les zones, des services prédéfinis et les types ICMP et a une séparation des options de configuration permanentes et en temps-réel. La configuration permanente est chargé depuis des fichiers XML dans /usr/lib/firewalld ou /etc/firewalld

   Si NetworkManager n'est pas utilisé et que firewalld est démarré après que le réseau soit déjà définis, les connexions et interfaces créées manuellement ne sont pas liées à la zone spécifiée dans le fichier ifcfg. Les interfaces sont automatiquement géré par la zone par défaut. firewalld est également notifié sur les renommages de périphériques réseaux. Tout cela s'applique également aux interfaces qui ne sont pas contrôlés par NetworkManager si NM_CONTROLED=no est mis.

   On peut ajouter ces interfaces à une zone avec firewall-cmd [--permanent] --zone=zone --add-interface=interface. S'il y a un fichier ifcfg-interface, firewalld tente de changer ZONE=zone dans ce fichier.

   Si firewalld est rechargé, il va restaurer les liaisons d'interface qui étaient en place avant de recharger pour conserver les liaisons d'interfaces stables dans le cas d'interface non contrôlés par NetworkManager. Ce mécanisme n'est pas possible dans le cas du redémarrage de firewalld.

   Il est essentiel de conserver le paramètre ZONE= dans les fichiers ifcfg consistant avec les liaisons dans firewalld dans le cas d'interfaces non controlé par NetworkManager.

Zones

   Une zone réseau ou firewall définis le niveau de confiance de l'interface utilisée pour une connexion. Il y a de nombreuses zones prédéfinies fournis par firewalld.

Services

   Un service peut être une liste de ports locaux, protocoles, et destination et additionnellement une liste de modules firewall automatiquement chargé si un service est activé. L'utilisation de services prédéfinis simplifient l'activation/désactivation des accès à un service.

Types ICMP

   ICMP est utilisé pour échanger les informations et messages d'erreur dans IP. les types ICMP peuvent être utilisé dans firewalld pour limiter l'échange de ces messages.

Configuration temps-réel

   La configuration temps-réel est la configuration active et n'est pas permanente. Une fois le service rechargé/redémarré ou après un reboot système, les paramètres temps réel sont perdus s'ils ne sont pas également dans la configuration permanente.

Configuration permanente

   Le configuration permanente est stockée dans les fichiers de configuration et est chargé au démarrage du service.

Interface directe

   L'interface directe est principalement utilisée par les services ou application pour ajouter des règles firewall spécifiques.

Répertoires

/usr/lib/firewalld Configuration par défaut, types icmp, services et zones.
/etc/firewalld Configuration système ou utilisateur.

Signaux

   SIGHUP
^
06 avril 2017

htmlpdflatexmanmd




firewalld.conf

firewalld.conf

Fichier de configuration de firewalld

   firewalld.conf est chargé par firewalld à l'initialisation. Ce fichier contient des options de configuration de base pour firewalld.

OPTIONS

DefaultZone Définis la zone par défaut pour les connection ou les interfaces si la zone n'est pas sélectionnée ou spécifiée par NetworkManager, initscripts, ou les outils en ligne de commande.
MinimalMark Pour certains paramètres de firewall, de nombreuses règles nécessaires dans différentes tables sont capable de gérer des paquets de la bonne manière. Pour celà, ces paquets sont marqués en utilisant le target MARK. Avec cette options, un block de marquage peut être réservé pour une utilisation privée; seules les marques au-delà de cette valeur sont utilisées. La valeur minimalMark par défaut est 100.
CleanupOnExit Si firewalld s'arrête, il nettoie toutes les règles firewall. Définir cette option à no ou false laisse les règles firewall intouchées. Défaut: yes, ou true.
Lockdown Activée, les changements du firewall via l'interface D-Bus sont limisées aux applications listées dans la liste lockdown. Défaut: no ou false
IPv6_rpfilter Activé, un test de filtre de chemin inverse dans un paquet pour IPv6 est effectué. Si une réponse au paquet serait envoyé via la même interface, le paquet match et est accepté, sinon il est supprimé. Pour IPv4, rp_filter est contrôllé via sysctl.
IndividualCalls Désactivé, les appels combinés -restore sont utilisé et pas les appels individuel pour appliquer les changements sur le firewall. L'utilisation d'appels individuels augmente le temps nécessaire pour appliquer les changements et pour démarrer le service, mais est bon pour le debuggage vu que les messages d'erreur sont plus spécifiques.
LogDenied Ajoute les règles de logging avant de rejeter ou supprimer dans les chaînes INPUT, FORWARD, et OUTPUT pour les règles par défaut, ainsi que le rejet et suppression final dans les zones pour le type de paquet l2 configuré. Les valeurs possible sont : all, unicast, broadcast, multicast et off. Défaut: off.
^
06 avril 2017

htmlpdflatexmanmd




firewalld.direct

firewalld.direct

Fichier de configuration direct

   Ce fichier de configuration donne un accès plus directe au firewall. Il nécessite de connaître les concepts ip(6)tables/ebtables. Un fichier de configuration direct contient des informations sur les chaînes directes permanentes

Exemple de structure de fichier de configuration directe:
‹?xml version="1.0" encoding="utf-8"?›
‹direct›
    [ ‹chain ipv="ipv4|ipv6|eb" table="table" chain="chain"/› ]
    [ ‹rule ipv="ipv4|ipv6|eb" table="table" chain="chain" priority="priority"› args ‹/rule› ]
    [ ‹passthrough ipv="ipv4|ipv6|eb"› args ‹/passthrough› ]
‹/direct›

direct Tag définissant la configuration directe
chain Définis les noms pour les chaînes additionnelles. Optionnel et peut être spécifié plusieurs fois. Une entrée chaîne a exactement 3 attributs:

        ipv="ipv4|ipv6|eb" Famille d'IP où la chaîne doit être créée
        table="table" Nom de la table où la chaîne doit être créée
        chain="chain" Nom de la chaîne, qui sera créée

rule Permet d'ajouter des règles à une chaîne intégrée ou ajoutée. Optionnel et peut être utilisé plusieurs fois. Une règle a exactement 4 attributs:

        ipv="ipv4|ipv6|eb" Famille d'IP où la règle doit être ajoutée
        table="table" Nom de la table où la règle doit être ajoutée
        chain="chain" Nom de la chaîne où la règle doit être ajoutée
        priority="priority" Priorité utilisée pour ordonner les règles. 0 signifie d'ajouter la règle en haut de la chaîne

passthrough Permet d'ajouter des règles à une chaîne intégrée ou ajoutée. Optionnel et peut être utilisé plusieurs fois. Une règle a exactement un attribut:

        ipv="ipv4|ipv6|eb" Famille d'IP où le passthrough doit être ajouté

Exemples

Blacklister les réseaux 192.168.1.0/24 et 192.168.5.0/24 en loggant et supprimant très tôt dans la table raw:
‹chain ipv="ipv4" table="raw" chain="blacklist"/›
‹rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0"›-s 192.168.1.0/24 -j blacklist‹/rule›
‹rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1"›-s 192.168.5.0/24 -j blacklist‹/rule›
‹rule ipv="ipv4" table="raw" chain="blacklist" priority="0"›-m limit --limit 1/min -j LOG --log-prefix "blacklisted: "‹/rule›
‹rule ipv="ipv4" table="raw" chain="blacklist" priority="1"›-j DROP‹/rule›
^
28 mars 2017

htmlpdflatexmanmd




firewalld.helper

firewalld.helper

Fichiers de configuration helper pour firewalld

   Un fichier de configuration helper fournis les informations d'une entrée helper pour firewalld.

Exemple de fichier de configuration helper
‹?xml version="1.0" encoding="utf-8"?›
‹helper module="nf_conntrack_module" [family="ipv4|ipv6"]›
    ‹short›short‹/short›
    ‹description›description‹/description›
    ‹port portid[-portid]" protocol="tcp|udp"/›
‹/helper›

[SECTION] name="OPTIONS" table="options" imbrication="0"
helper
tag définissant un helper

        module= Nom du module helper. Le nom commence avec nf_conntrack_
        family="ipv4|ipv6" Famille du helper. non spécifié, utilise les 2
        version= Version pour ce helper

short Courte description pour ce helper
description Description pour ce helper
port Peut être spécifié plusieurs fois

        port="string" Peut être un port ou une plage de ports.
        protocol="string" tcp ou udp

^
28 mars 2017

htmlpdflatexmanmd




firewalld.icmptype

firewalld.icmptype

Fichiers de configuration icmptype

   Un fichier de configuration icmptype fournis les informations pour un type ICMP pour firewalld.

Exemple de fichier de configuration icmptype
‹?xml version="1.0" encoding="utf-8"?›
‹icmptype›
    ‹short›My Icmptype‹/short›
    ‹description›description‹/description›
    ‹destination ipv4="yes" ipv6="yes"/›
‹/icmptype›

OPTIONS

icmptype Ce tag définis le type icmp

        version="string" Version pour cet icmptype

short Courte description pour cet icmptype
description Description pour cet icmptype
destination Spécifie si une entrée icmptype est disponible pour IPv4 et/ou IPv6.

        ipv4="bool" Indique si cet icmptype est disponible pour ipv4
        ipv6="bool" Indique si cet icmptype est disponible pour ipv6
^
28 mars 2017

htmlpdflatexmanmd




firewalld.ipset

firewalld.ipset

Fichiers de configuration ipset pour firewalld

   Un fichier de configuration ipset fournis les informations d'un jeu IP pour firewalld.

Exemple de fichier de configuration ipset
‹?xml version="1.0" encoding="utf-8"?›
‹ipset type="hash:ip"›
    ‹short›My Ipset‹/short›
    ‹description›description‹/description›
    ‹entry› 1.2.3.4‹/entry›
    ‹entry› 1.2.3.5‹/entry›
    ‹entry› 1.2.3.6‹/entry›
‹/ipset›

OPTIONS

ipset tag définissant un ipset.

        type= Type d'ipset. peut être hash:ip, hash:net, hash:mac
        version= version pour cet ipset

short Description courte pour cet ipset
description Description pour cet ipset
option Peut être spécifié plusieurs fois pour spécifier des attributs (inet, inet6, timeout:‹int›, hashsize:‹int›, maxelem:‹int›):

        name= Nom d'une option
        value valeur de l'option

entry Peut être spécifié plusieurs fois pour spécifier une entrée.
^
06 avril 2017

htmlpdflatexmanmd




firewalld.lockdown-whitelist

firewalld.lockdown-whitelist

Fichier de configuration whitelist lockdown

   Ce fichier contient les contextes selinux, commandes, utilisateurs, et ID d'utilisateurs qui sont whitelistés quand la fonctionnalité de lockdown est activée.

Exemple de fichier de lockdown:
‹?xml version="1.0" encoding="utf-8"?›
‹whitelist›
    ‹selinux context="selinuxcontext"/›
    ‹command name="commandline[*]"/›
    ‹user {name="username|id="userid"}/›
‹/whitelist›

OPTIONS

whitelist Tag définissant le lockdown-whitelist.
selinux Optionnel et peut être spécifié plusieurs fois. Une entrée selinux a exactement un attribut:

        context="string" Le context d'une application ou service en cours de fonctionnement

command Optionnel et peut être spécifié plusieurs fois. Une command a exactement un attribut:

        name="string" ligne de commande complète inclunat le chemin et les attributs.

user Optionnel et peut être spécifié plusieurs fois. Une entrée user contient exactement un attribut parmis:

        name="string" Nom de l'utilisateur
        id*"integer" id de l'utilisateur
^
06 avril 2017

htmlpdflatexmanmd




firewalld.richlanguage

firewalld.richlanguage

Documentation du langage Rich

   Avec ce langage il est possible de créer des règles firewall plus complexes de manière simple. Ce langage utilise des mots clé avec des valeurs et est une représentation abstraite des règles iptables.

   Ce langage étends les éléments de zone courantes (service, port, icmp-block, masquerade, forward-port et source-port) avec des adresses source et de destination, logging, actions et limites pour les logs et les actions.

   Ce mémo décris ce langage utilisé en ligne de commande et les interfaces D-Bus. Une règle fait partie d'une zone. Une zone peut contenir de nombreuses règles.

Structure de règle générale
rule
    [source]
    [destination]
    service|port|protocol|icmp-block|masquerade|forward-port|source-port
    [log]
    [audit]
    [accept|reject|drop|mark]

rule [family="ipv4|ipv6] Si la famille n'est pas fournie, la règle s'applique à IPv4 et IPv6.
source [not] address="address[/mask]"|mac="mac-address"|ipset="ipset" Avec l'adresse source l'origine d'une tentative de connexion peut être limitée à l'adresse source.
destination [not] address="address[/mask]" Une cible peut être limitée avec l'adresse de destination
service name="service name" Ajoute le nom du service à la règle.
port port="port value" protocol="tcp|udp" Le peut être être un numéro de port ou une plage de port. le protocole peut être tcp ou udp
protocol value="protocol value" La valeur du protocole est soit un numéro identifiant ou un nom de protocole
icmp-block name="icmptype name" Un des types icmp supporté par firewalld.
masquerade Active le masquerading dans la règle. Une source et également une destination peuvent être fournis pour limiter le masquerading pour cette zone
forward-port port="port value" protocol="tcp|udp" to-port="port value" to-addr="address" port/paquet forwarding depuis un port local vers un autre port local ou une autre machine ou un autre port sur un autre machine. Il n'est pas possible de spécifier une action ici, forward-port utilise l'action accept en interne
source-port port="port value" protocol="tcp|udp" Le port source peut être un port ou une plage de port.
log [prefix="prefix text"] [level="log level"] [limit value="rate/duration"] Log les tentatives de nouvelles connexions avec le logging kernel, par exemple syslog.
audit [limit value="rate/duration"] Utilise auditd pour le logging
accept [limit value="rate/duration"]
reject [type="reject type"] [limit value="rate/duration"]
drop [limit value="rate/duration"]
mark set="mark[/mask]" [limit value="rate/duration"] Une action peut être accept, reject, drop, ou mark
limit value="rate/duration" Limite des logs, audit et action. Un règle utilisant ce tag match jusqu'à ce que cette règle soit atteinte. La durée est en s, m, h ou d. Maximum: 2/d (2 matchs par jour)
zone_log
zone_deny
zone_allow la chaine zone_log peut être ajoutée à toutes les zones, qui contient toutes les règles de logging. Les règles reject et drop sont placées dans zone_deny et les règles accept dans zone_allow

Exemples

Autoriser les nouvelles connexions IPv4 et IPv6 pour le protocole ah
rule protocol value="ah" accept
autoriser les nouvelles connexions IPv4 et IPv6 pour le service ftp et 1 log par minute avec audit
rule service name="ftp" log limit value="1/m" audit accept
Autoriser les connexions IPv4 depuis 192.168.0.0/24 pour tftp et un log par minute en utilisant syslog
rule family="ipv4" source address="192.168.0.0/24" service name="tftp" log prefix="tftp" level="info" limit value="1/m" accept
Les nouvelles connexions de 1:2:3:4:6:: vers radius sont rejetées et loggées à un taux de 3 par minute. Les nouvelles connexions depuis les autres sources sont acceptées
rule family="ipv6" source address="1:2:3:4:6::" service name="radius" log prefix="dns" level="info" limit value="3/m" reject
rule family="ipv6" service name="radius" accept
forward les packets IPv6 reçus de 1:2:3:4:6:: sur le port 4011 avec tcp vers 1::2:3:4:7 sur le port 4012
rule family="ipv6" source address="1:2:3:4:6::" forward-port to-addr="1::2:3:4:7" to-port="4012" protocol="tcp" port="4011"
Liste blanche d'adresse source pour autoriser les connexions depuis 192.168.2.2
rule family="ipv4" source address="192.168.2.2" accept
Liste noire pour rejeter toutes les connexions depuis 192.168.2.3
rule family="ipv4" source address="192.168.2.3" reject type="icmp-admin-prohibited"
liste noire pour supprimer toutes les connexions depuis 192.168.2.4
rule family="ipv4" source address="192.168.2.4" drop
^
28 mars 2017

htmlpdflatexmanmd




firewalld.service

firewalld.service

Fichiers de configuration du service firewalld

   Un fichier de configuration de service firewalld fournis les information d'une entrée de service pour firewalld. Les options de configuration les plus importants sont les ports, modules, et adresses de destination.

Exemple de fichier de configuration montrant la structure d'un fichier de configuration de service:
‹?xml version="1.0" encoding="utf-8"?›
‹service›
    ‹short›My Service‹/short›
    ‹description›description‹/description›
    ‹port port="137" protocol="tcp"/›
    ‹protcol value="igmp"/›
    ‹module name="nf_conntrack_netbios_ns"/›
    ‹destination ipv4="224.0.0.251" ipv6="ff02::fb"/›
‹/service›

OPTIONS

service Le tag service définis le service

        version= Indique une version pour ce service

short Donne une courte description pour le service
description Indique une description pour le service
port élément utilisable plusieurs fois pour indiquer des ports

        port= port ou plage de ports
        protocol= tcp ou udp

protocol Élément pouvant être utilisé plusieurs fois puor indiquer les protocoles:

        value= Protocol supporté par le système (voir /etc/protocols)

source-port spécifie le port source. peut être spécifié plusieurs fois

module Spécifie un module netfilter. Peut être spécifié plusieurs fois

        name= Nom du module

destination Spécifie le réseau de destination.

        ipv4= adresse IPv4/masque de destination
        ipv6= adresse IPv6/masque de destination
^
15 janvier 2017

htmlpdflatexmanmd




firewalld.zone

firewalld.zone

Fichiers de configuration de zone firewalld

   Un fichier de configuration de zone contient les informations pour une zone.

Structure d'un fichier de configuration de zone
‹?xml version="1.0" encoding="utf-8"?›
‹zone [version="versionstring"] [target="ACCEPT|%%REJECT%%|DROP"]›
    [ ‹short›short description‹/short› ]
    [ ‹description›description‹/description› ]
    [ ‹interface name="string"/› ]
    [ ‹source address="address[/mask]"|mac="MAC"|ipset="ipset"/› ]
    [ ‹service name="string"/› ]
    [ ‹port port="portid[-portid]" protocol="tcp|udp"/› ]
    [ ‹protcol value="protocol"/› ]
    [ ‹icmp-block name="string"/› ]
    [ ‹icmp-block-inversion/› ]
    [ ‹masquerade/› ]
    [ ‹forward-port port="portid[-portid]" protocol="tcp|udp" [to-port="portid[-portid]"] [to-addr="ipv4address"]/› ]
    [ ‹source-port port="portid[-portid]" protocol="tcp|udp"/› ]
    [
        ‹rule [family="ipv4|ipv6"]›
        [ ‹source address="address[/mask]"|mac="MAC"|ipset="ipset" [invert="True"]/› ]
        [ ‹destination address="address[/mask]" [invert="True"]/› ]
        [
            ‹service name="string"/› |
            ‹port port="portid[-portid]" protocol="tcp|udp"/› |
            ‹protocol value="protocol"/› |
            ‹icmp-block name="icmptype"/› |
            ‹masquerade/› |
            ‹forward-port port="portid[-portid]" protocol="tcp|udp" [to-port="portid[-portid]"] [to-addr="address"]/›
        ]
        [ ‹log [prefix="prefixtext"] [level="emerg|alert|crit|err|warn|notice|info|debug"]› [‹limit value="rate/duration"/›] ‹/log› ]
        [ ‹audit› [‹limit value="rate/duration"/›] ‹/audit› ]
        [
            ‹accept› [‹limit value="rate/duration"/›] ‹/accept› |
            ‹reject [type="rejecttype"]› [‹limit value="rate/duration"/›] ‹/reject› |
            ‹drop› [‹limit value="rate/duration"/›] ‹/drop› |
            ‹mark set="mark[/mask]"› [‹limit value="rate/duration"/›] ‹/mark›
        ]
        ‹/rule›
    ]
‹/zone›

zone définis la zone. Obligatoire et ne peut exister qu'une seule fois. Ses attributs optionnels sont:

        version="string" Version de la zone
        target="ACCEPT|%%REJECT%%|DROP" Accèpte, rejète ou supprime tout paquets qui ne correspond à aucune règle.

short Description courte pour la zone
description Description complète de la zone
interface Permet de lier une interface à une zone. Peut être spécifié plusieurs fois. l'attribut name="string" spécifie le nom de l'interface.
source Permet de lier une adresse source, plage d'adresse, adresse MAC ou ipset à une zone. Peut être spécifié plusieurs fois. Les attributs sont:

        address="address[/mask]" IP ou réseau source.
        mac="MAC" Adresse MAC source
        ipset="ipset" ipset source

service Spécifie un service. Peut être spécifié plusieurs fois. l'argument name="string" spécifie un service à activer
port Port à ajouter. Peut être spécifié plusieurs fois

        port="portid[-portid]" Port ou plage de port
        protocol="tcp|udp" protocole à utiliser

protocol Spécifie un protocole supporté par le système. (voir /etc/protocols). Peut être spécifié plusieurs fois. l'argument value="string" spécifie le nom du protocol.
icmp-block l'argument name="string est le nom d'un type ICMP (firewall-cmd --list=icmptypes pour les lister)
icmp-block-inversion Inverse icmp-block
masquerade IPv4 uniquement. Active le masquerading pour la zone
forward-port IPv4 uniquement. Peut être spécifié plusieurs fois

        port="portid[-portid]" Port ou plage de ports
        protocol="tcp|udp" Protocole utilisé
        to-port="portid[-portid] Port ou plage de port de destination
        to-addr="address" adresse IPv4 de destination

source-port Spécifie un port source. Peut être spécifié plusieurs fois

        port="portid[-portid]" Port ou plage de ports
        protocol="tcp|udp" Protocole utilisé

rule Définis une règle en langage rich. peut être spécifié plusieurs fois. La structure générale est:


‹rule [family="ipv4|ipv6"]›
    [ ‹source address="address[/mask]" [invert="True"]/› ]
    [ ‹destination address="address[/mask]" [invert="True"]/› ]
    [
        ‹service name="string"/› |
        ‹port port="portid[-portid]" protocol="tcp|udp"/› |
        ‹protocol value="protocol"/› |
        ‹icmp-block name="icmptype"/› |
        ‹masquerade/› |
        ‹forward-port port="portid[-portid]" protocol="tcp|udp" [to-port="portid[-portid]"] [to-addr="address"]/› |
        ‹source-port port="portid[-portid]" protocol="tcp|udp"/› |
    ]
    [ ‹log [prefix="prefixtext"] [level="emerg|alert|crit|err|warn|notice|info|debug"]/› [‹limit value="rate/duration"/›] ‹/log› ]
    [ ‹audit› [‹limit value="rate/duration"/›] ‹/audit› ]
    [
        ‹accept› [‹limit value="rate/duration"/›] ‹/accept› |
        ‹reject [type="rejecttype"]› [‹limit value="rate/duration"/›] ‹/reject› |
        ‹drop› [‹limit value="rate/duration"/›] ‹/drop› |
        ‹mark set="mark[/mask]"› [‹limit value="rate/duration"/›] ‹/mark›
    ]

‹/rule›

La structure de règle pour les listing black ou white source:
‹rule [family="ipv4|ipv6"]›
    ‹source address="address[/mask]" [invert="True"]/›
    [ ‹log [prefix="prefixtext"] [level="emerg|alert|crit|err|warn|notice|info|debug"]/› [‹limit value="rate/duration"/›] ‹/log› ]
    [ ‹audit› [‹limit value="rate/duration"/›] ‹/audit› ]
    ‹accept› [‹limit value="rate/duration"/›] ‹/accept› |
    ‹reject [type="rejecttype"]› [‹limit value="rate/duration"/›] ‹/reject› |
    ‹drop› [‹limit value="rate/duration"/›] ‹/drop›
‹/rule›

^
15 janvier 2017

htmlpdflatexmanmd




firewalld.zones

firewalld.zones

Zones firewalld

   Une zone réseau définis le niveau de confiance des connexions réseaux. C'est une des nombreuses relations, qui signifie qu'une connexion peut seulement faire partie d'une zone, mais une zone peut être utilisé pour de nombreuses connections réseaux. La zone définis les fonctionnalités firewall qui sont activés dans cette zone:

Services prédéfinis un service est une combinaison de ports et/ou protocols. Optionnellement, des modules netfilter peuvent être ajoutés ainsi que des adresses de destination IPv4 et IPv6
Protocoles et ports Définition de ports tcp ou udp, où les ports peuvent être un simple port ou une plage de ports.
Masquerading Les adresses d'un réseau privé sont mappés et cachés derrière une adresse IP publique.
Forward ports Un forward port est soit mappé au même port dans un autre hôte ou à un autre port dans le même hôte ou un autre port dans un autre hôte.
Règles de langage rich Le langage rich étend les éléments avec des adresses source et destination additionnels, logging, actions et limites pour les logs et actions. Il peut être utilisé pour les hôtes ou listing de réseau blanc ou noir.

zones disponibles

   Il y a des zones fournies par firewalld triés en accord avec le niveau avec le niveau de confiance des zones:

drop Tous les paquets sont supprimés, sans réponse. Seul les connexions sortantes sont possibles
block Les connexions réseau entrantes sont rejetées avec un message icmp-host-prohibited pour IPv4 et icmp6-adm-prohibited pour IPv6. Seul les connexions initiées dans ce système sont possibles
public À utiliser dans les zones publiques. Ne pas faire confiance aux autres machines. Seuls les connections entrantes séléctionnées sont acceptés.
external À utiliser dans les réseaux externes avec le masquerading activé. Pas de confiance aux autres machines. Seules les connexions entrantes sélectionnées sont acceptées
dmz Pour les machines dans une zone démilitarisée publiquement accessibles avec accès limité au réseau interne. Seules les connections entrantes sélectionnées sont acceptés
work À utiliser dans les zones de travail. Fait confiance aux autres machines dans les réseaux de la machine. Seules les connexions entrantes sélectionnées sont acceptées
home À utiliser dans les réseaux personnels. Fait confiance aux autres machines du réseau. Seules les connections entrantes sélectionnées sont acceptées
internal À utiliser dans les réseaux interne. Fait confiance aux autres machines dans le réseaux non liés à la machine. Seules les connections entrantes séléctionnées sont acceptées
trusted Toutes les connections réseaux sont acceptées

Zones à utiliser

   Un réseau WIFI publique par exemple, ne doit pas être de confiance, une connexion filaire personnelle devrait être de confiance.

Configurer ou ajouter une zone

   Pour configurer ou ajouter une zone, utiliser les interfaces firewalld. Il y a un outils de configuration graphique firewall-config, un outil en ligne de commande firewall-cmd ou l'interface D-Bus. Il est également possible de copier un fichier de zone dans /usr/lib/firewalld/zones dans /etc/firewalld/zones.

   La zone est stockée dans ifcfg de la connexion avec l'option ZONE=. Si l'option est manquante ou vide, la zone par défaut est utilisée.

  Si la connexion est contrôlée par NetworkManager, on peut également utiliser nm-connection-editor pour changer la zone

  Pour l'ajout ou la modifications d'interfaces non contrôlées par NetworkManager, firewalld tente de changer le paramètres ZONE dans le fichier ifcfg, s'il existe.

  Pour les interfaces non contrôlées par NetworkManager, lors de la suppression firewalld ne tente pas de changer la ZONE dans le fichier ifcfg. Cela permet de s'assuser qu'un ifdown ne réinitialise pas les paramètres de zone.
^
07 juin 2010

htmlpdflatexmanmd




fmt

fmt

Joint les lignes d'un fichier pour produire des lignes d'un nombre donné de caractères - 75 par défaut

   Par défaut, les lignes blanches, les espaces entre les mots et l'indentation sont préservés dans la sortie; les lignes successives avec différentes indentations ne sont pas jointes; les tabulations sont étendues en entrées et introduits sur la sortie.

  fmt préfère couper les lignes à la fin d'une phrase, et essaye d'éviter de couper une ligne après le premier mot d'une phrase ou avant le dernier mot d'un phrase. Une coupe de phrase est définie soit à la fin d'un paragraphe ou un mot se terminant par '.' '?' ou '!', suivi par 2 espaces ou la fin d'une ligne, en ignorant les parenthèses ou guillemets.

OPTIONS

-C, --compare Compare chaque paire de fichier source et destination, et si la destination à un contenu identique, ainsi que le user, group et permissions, alors ne modifie pas la destination du tout.
-c, --crown-margin Préserve l'indentation des 2 premières lignes dans un paragraphe, et aligne la marge de gauche de chaque ligne suivante avec la seconde ligne.
-t, --tagged-paragraph Identique à -c, excepté que si l'indentaton de la première ligne d'un paragraphe est la même que l'indentation de la seconde, la première ligne est traitée comme un paragraphe à une ligne.
-s, --split-only Coupe les lignes uniquement, Ne joint pas les lignes courtes.
-u, --uniform-spacing Réduit l'espace entre les mots à un espace, et l'espace entre les phrases à 2 espaces.
-WIDTH, -w WIDTH, --width=WIDTH Définit le nombre de caractères par ligne (75 par défaut)
-p PREFIX, --prefix=PREFIX Seul les lignes commençant avec PREFIX sont sujet à formatage.
^
07 juin 2010

htmlpdflatexmanmd




fold

fold

Écrit chaque fichier ou l'entrée standard sur la sortie standard, en coupant les longues lignes. Par défaut il coupe les lignes plus longues que 80 colonnes.

OPTIONS

-b, --byte Compte en octets au lieu de colonnes, donc les tabulations, retour chariot et blackspace sont compté comme une seule colonne.
-s, --spaces Coupe la ligne avec un espace blanc
-w WIDTH, --width=WIDTH Définit la longueur maximale de ligne.
^
17 juillet 2010

htmlpdflatexmanmd




Format d'entrée de date

Format d'entrée de date

Syntaxe du format de date

Syntaxe générale de date

   une date est une chaîne, qui peut être vide, contenant plusieurs items séparés avec un espace blanc. Une date peut contenir:

        - date de calendrier
        - heure du jour
        - time zone
        - jour de la semaine
        - iems relatifs
        - nombres

   Quelques nombres peuvent être écris en mot:

        last vaut -1
        this vaut 0
        first, next valent 1
        third pour 3
        fourth pour 4
        fifth pour 5
        sixth pour 6
        seventh pour 7
        eighth pour 8
        ninth pour 9
        tenth pour 10
        eleventh pour 11
        twelfth pour 12

   Dans l'implémentation actuelle, seul l'Anglais est supporté pour les mots et abbréviations comme AM, DST, EST, first, january, sunday, tomorrow et year.

Date de calentrier et TimeZone

Une date de calendrier spécifie un jour de l'année. Elle est spécifiée différemment, si le mois est indiqué numériquement ou littéralement. Toutes ces chaînes spécifient la même date de calendrier:
1972-09-24
72-9-24
72-09-24
9/24/72
24 September 1972
24 Sept 72
24 Sep 72
Sep 24, 1972
24-sep-72
24sep72
L'année peut également être omise. Dans ce cas, la dernière année spécifiée est utilisée, sinon l'année courante. Exemple
9/24
sep 24

   pour les mois numérique, le format ISO 8601 YEAR-MONTH-DAY est permis. La construction MONTH/DAY/YEAR, populaire aux USA est accepté. Les mois peuvent être spécifiés par leur nom : 'January', 'February','March', 'April', 'May', 'June', 'July', 'August', 'September','October', 'November', 'December'. On peut utiliser leur abréviation (les 3 premières lettres).

Quand les mois sont spécifiés ainsi, la date de calendrier peut être spécifié comme suit
DAY MONTH YEAR
DAY MONTH
MONTH DAY YEAR
DAY-MONTH-YEAR
ou omettre l'année
MONTH DAY

Heure du jour

Quelques exemples:
20:02:00.000000
20:02
8:02pm
20:02-0500 # In EST (U.S. Eastern Standard Time).

   Plus généralement, le temps peut être donné en HOUR:MINUTE:SECOND, et optionnellement suivi par un '.' ou ',' et une fraction contenant un ou plusieurs chiffres. SECOND peut être omis. Si le temps est suivi par 'am' ou 'pm', HOUR est restreint entre 1 et 12.

  L'heure peut être suivie par un time zone exprimé par SHHMM, où S vaut '+' ou '-', HH Est le nombre d'heures de la zone, et MM est le nombre de minutes de la zone (peut être omis).

Jour de la semaine

   La mention du jour de la semaine va renvoyer la date pour atteindre ce jours de la semaine dans le future. Les jours de la semaine peuvent être écris : 'Sunday', 'Monday','Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'. Leur abréviation peut être utilisé (3 premières lettres). Un nombre peut précéder le jour de la semaine pour spécifier un jour antérieur, comme third monday. Dans ce contexte, 'last DAY' ou 'next DAY' sont aussi acceptable.

Items relatifs

Quelques exemples:
1 year
1 year ago
3 years
2 days

   il est possible d'utiliser 'fortnight' pour 14 jours, week pour 7 jours, day pour 24 heures, hour pour 60 minutes, minute ou min pour 60 secondes et second ou sec. Un suffixe 's' est accepté et ignoré. L'unité de temps peut être précédée par un multiplicateur, un nombre signé. pour spécifié un temps antérieur, ajouter ago.

  Ainsi tomorrow est équivalent à day et yesterday est équivalent à day ago. Les chaînes now et today correspondent à aucun déplacement de temps. Ils peuvent être utilisés par exemple: "10:00 today". La chaîne this à la même signification, par exemple: this thursday.

Secondes depuis the Epoch

   Si vous précédez un nombre avec '@', il représente un compteur de seconde interne. the epoch correspond au 1970-01-01 00:00:00 UTC. Il est possible de spécifier des valeurs négatives. Les systèmes 32-bits peuvent représenter le temps de 1901-12-13 20:45:52 à 2038-01-19 03:14:07 UTC. Les systèmes plus modernes utilise un compteur 64-bits.

Spécifier les règles de TimeZone

   Normalement les dates sont interprétées en utilisant les règles de time zone courant, qui sont spécifiées par la variable d'environnement TZ ou par le systéme par défaut si TZ n'est pas définie.

exemple: quelle heure est-il à New York quand il est 6:30 à Paris le 31 octobre 2004, en utilisant une date commençant par TZ="Europe/Paris":
export TZ="America/New_York"
date --date='TZ="Europe/Paris" 2004-10-31 06:30'
Sun Oct 31 01:30:00 EDT 2004
^
07 mai 2016

htmlpdflatexmanmd




free

free

Affiche la quantité de mémoire utilisée et libre dans le système

   free affiche la quantité totale de mémoire physique libre et utilisée et la mémoire swap dans le système, ainsi que les tampons utilisé par le kernel. La colonne de mémoire partagée représente soit la valeur MemShared (kernel 2.4), ou la valeur Shmem (kernels 2.6), de /proc/meminfo. La valeur est 0 si aucune entrée n'est exporté par le kernel.

OPTIONS

-b, --bytes Affiche la quantité de mémoire en octets
-k, --kilo Affiche la quantité de mémoire en Ko (défaut)
-m, --mega Affiche la quantité de mémoire en Mo
-g, --giga Affiche la quantité de mémoire en Go
--tera Affiche la quantité de mémoire en To
-h, --human Affiche tous les champs ajusté automatiquement
-c, --count count Affiche le résultat ‹count› fois. Exige l'option -s
-l, --lohi Affiche des statistiques mémoire basse et haute détaillées
-o, --old Affiche la sortie dans l'ancien format
-s, --seconds seconds Répète l'affichage tous les ‹seconds› secondes
--si Utilise les puissances de 1000 au lieu des puissances de 1024
-t, --total Affiche une ligne montrant les totaux des colonnes
^
23 mai 2016

htmlpdflatexmanmd




fsadm

fsadm

Utilitaire pour redimensionner ou vérifier le système de fichier dans un périphérique. Il tente d'utiliser la même API pour ext2/3/4, ReiserFS et XFS

OPTIONS

-e, --ext-offline Démonte les systèmes de fichier ext2/3/4 avant de redimensionner
-f, --force bypasse certaines vérifications
-n, --dry-run Affiche les commandes sans les lancer
-v, --verbose mode verbeux
-y, --yes Répond yes a toutes les questions
new_size[B|K|M|G|T|P|E] Nombre absolue de blocks de système de fichier dans le système de fichier, ou une taille absolue utilisant un suffix en puissance de 1024.

Diagnostiques

   Une fois complété avec succès, le code de status est 0. 2 indique que l'opération a été intérrompue par l'utilisateur. 3 indique que l'opération de vérification en peut pas être effectuée parce que le système de fichier est monté et ne supporte pas un fsck online. 1 indique une autre erreur.

Variables d'environnement

TMPDIR Répertoire temporaire pour les points de montage (défaut. /tmp)
DM_DEV_DIR Nom du répertoire de périphériques. Défaut: /dev.
^
01 novembre 2016

htmlpdflatexmanmd




fsck

fsck

Vérifier et réparer un système de fichier

   fsck est utilisé pour vérifier et optionnellement réparer un ou plusieurs systèmes de fichier Linux. Si aucun système de fichier n'est spécifié sur la ligne de commande, ni l'option -A, fsck vérifie les systèmes de fichier dans /etc/fstab. Équivalent à -As.

Codes de sortie

0 Pas d'erreurs
1 Erreurs du système de fichier corrigés
2 Le système devrait être redémarré
4 Des erreurs sont à corriger
8 Erreur d'opération
16 Erreur d'utilisation ou de syntaxe
32 Vérification annulée à la demande de l'utilisateur
128 Erreur de librairie partagée

OPTIONS

-l Créé un fichier lock flock(2) (/run/fsck/‹diskname›.lock) pour le périphérique.
-r [fd] Affiche des statistiques pour chaque opération complétée.
-s Sérialise les opérations fsck
-t fslist Spécifie les types de système de fichier à vérifier. Avec -A, seul les systèmes de fichier qui matchent la liste sont vérifiés.
-A Parcour /etc/fstab et tente de vérifier tous les systèmes de fichier en une passe, en respectant l'ordre du champ fs_passno.
-C [fd] Affiche une barre de progression pour les systèmes de fichier que le supporte
-M Ne pas vérifier les systèmes de fichier montés
-N Mode test, n'exécute rien
-P Avec -A, vérifie le système de fichier racine en parallèle avec d'autres système de fichier.
-R Avec -A, ne vérifie pas le système de fichier racine
-T N'affiche pas le titre au démarrage
-v mode verbeux
fs-specific-options Les options non comprises sont passés au vérificateur de système de fichier.
-a Répare automatiquement le système de fichier sans poser de question.
-n  Pour certains systèmes de fichier, évite de tenter de réparer un problème, mais affiche simplement le problème.
-r Réparation intéractive
-y Pour certains systèmes de fichier, tente toujours de détecter et réparer les corruptions automatiquement.

Variables d'environnement

FSCK_FORCE_ALL_PARALLEL Si définis, fsck tente de vérifier tous les systèmes de fichier en parallèle. Utile pour les systèmes RAID
FSCK_MAX_INST Limite le nombre de checkers en concurrence.
PATH Les chemins de recherche pour les commandes
FSTAB_FILE Enplacement du fichier fstab
LIBBLKID_DEBUG =all Activer la sortie de débogage de libblkid
LIBMOUNT_DEBUG =all Activer la sortie de débogage de libmount.
^
03 novembre 2016

htmlpdflatexmanmd




fsck.fat

fsck.fat

Vérifier et réparer un systèmes de fichier MS-DOS

   fsck.fat vérifie la consistance des systèmes de fichier MS-DOS et optionellement tente de le réparer. Les problèmes suivants peuvent être corrigés (dans l'ordre):

- FAT contient un nombre de clusters invalides. Cluster est changé à EOF
- La chaîne cluster de fichier contient une boucle. La boucle est cassée
- Bad clusters (erreurs de lecture). Les clusters sont marqués comme mauvais et sont supprimés des fichiers qui les possède.
- Les répertoires avec un grand nombre d'entrées en erreur (probablement corrompu). Le répertoire peut être supprimé
- Les fichiers . et .. dans le répertoire root. Ils sont supprimés
- Les maivais noms de ichier. Il peuvent être supprimés ou renommés
- Les répertoires avec un champ de taille non-zero. La taille est mis à 0
- Le répertoire . ne pointe pas sur le répertoire parent. Le pointeur de départ est ajusté
- Le répertoire .. ne pointe pas vers le parent du parent. Le pointeur de départ est ajusté
- Le numéro du cluster de départ d'un fichier est invalide. Le fichier est tronqué
- Le fichier contient de mauvais clusters ou vides. Le fichier est tronqué
- La chaine de cluster du fichier est supérieur que la taille indiquée. Le fichier est tronqué
- 2 ou plusieurs fichiers partagent les même clusters. Tous sauf un sont tronqués. Si le fichier tronqué est un répertoire qui a déjà été lu, la vérification recommence après l'avoir tronqué
- La chaine de cluster du fichier est plus courte que la taille du fichier. Ils sont libérés
Additionnellement, les problèmes suivant sont détectés, mais non réparés:
- Paramètres invalides dans le secteur de boot
- Absence des entrées . et .. dans les répertoires

   Quand fsck.fat vérifie un système de fichier il accumule tous les changements en mémoire et les applique seulement après que toutes les vérifications soient finies. Cela peut être désactivé avec l'option -w.

OPTIONS

-a Répare automatiquement le système de fichier. Aucune intervention n'est nécessaire. Quand plusieurs méthodes permettent de résoudre un problème, l'approche la moins destructrice est utilisée.
-A Utilise la variant Atari de MS-DOS.
-b Fait une vérification du secteur de boot en lecture seule
-c PAGE Utilise le codepage DOS spécifié pour décoder les noms de fichiers court. Défaut: 437
-e PATH Supprime le fichier spécifié. Si plus d'un fichier avec ce nom existe, le premier est supprimé. Peut être spécifié plusieurs fois.
-f Récupère les chaîne de cluster non utilisés aux fichiers. Par défaut, ils sont ajoutés dans l'espace libre excepté en mode auto (-a)
-l Liste les chemin des fichiers à traiter
-n  Mode sans opération, n'écris rien du tout dans le système de fichier
-p Idem à -a, pour compatibilité avec d'autres fsck
-r Répare interactivement.
-t Marque les cluster illisible comme mauvais
-u PATH Tente de récupérer un fichier supprimé. Il tente d'allouer une chaîne de clusters contigus non alloués commençant avec le cluster de départ du fichier supprimé. Peut être spécifié plusieurs fois.
-v mode verbeux
-V Effectue une passe de vérification. La vérification est répétée après la première passe. Le seconde passe n'affiche jamais les erreurs réparables.
-w Écris les changements immédiatement sur le disque
-y Idem -a pour compatibilité avec d'autres fsck

Codes de sortie

0 Aucune erreur non récupérable n'a été détecté
1 Des erreurs irrécupérable ont été détectés ou fsck.fat a découvert une inconsistance interne
2 Erreur d'utilisation. fsck.fat n'a pas accédé au système de fichier

Fichier

fsck0000.rec, fsck0001.rec, ... En récupérant depuis un système de fichier corrompu, fsck.fat dump les données récupérée dans des fichiers nommés fsckNNNN.rec dans le répertoire racine du système de fichier.
^
02 novembre 2016

htmlpdflatexmanmd




fsck.nfs

fsck.nfs

script fantôme qui retourne toujours un succès

   Debian a besoin de ce script quand le système de fichier racine est sur NFS: Il n'y a pas moyen de connaître si NFS est monté et on a vraiment besoin de faire un fsck -a /. Retourne toujours 0

^
03 décembre 2016

htmlpdflatexmanmd




fstrim

fstrim

Supprimer les blocks non-utilisés dans un système de fichier monté

   Cet utilitaire est utilisé pour les disques Solid-State Drives et les stocake à provisionnement léger. Lancer fstrim fréquemment, ou en utilisant mount -o discard peut réduire les effets négatifs du la durée de vie des disques SSD de mauvaise qualité. Un fréquence d'une fois par semaire est suffisante.

OPTIONS

-a, --all Trim tous les fs dans les périphériques qui supportent les opérations de suppression.
-o, --offset offset Décalage d'octet dans le système de fichier depuis lequel la recherche commence. Défaut: 0.
-l, --length length Nombre d'octets à rechercher peur les blocks à supprimer. Défaut: jusqu'à la fin du fs
-m, --minimum minimum-size Plage libre contigüe minimum à supprimer, en octets.
-v, --verbose mode verbeux

Codes des status

0 succès
1 Échec
32 Tout à échoué
64 Certains fs on réussis, d'autre non
^
16 mai 2017

htmlpdflatexmanmd




ganesha-nfsd

ganesha-nfsd

Service nfs en userspace

-L ‹logfile› Fichier de log du service (défaut: SYSLOG)
-N ‹dbg_level› Niveau de verbosité. Défaut: NIV_EVENT
-f ‹config_file› Fichier de configuration. Défaut: /etc/ganesha/ganesha.conf
-p ‹pid_file› Fichier pid. Défaut: /var/run/ganesha.pid
-F Ne lance pas en tâche de fond
-R Gère RPCSEC_GSS
-T Dump la configuration par défaut sur stdout
‹epock› Change ServerBootTime pour ServerEpoch

Signaux

SIGUSR1 Active/désactive le vidage forcé du cache de contenu de fichier
^
16 mai 2017

htmlpdflatexmanmd




ganesha.conf

ganesha.conf

Fichier de configuration pour nfs-ganesha

NFS_CORE_PARAM

NFS_Port Port utilisé par le protocole NFS. défaut: 2049
MNT_Port Port utilisé par le protocole MNT. Défaut: 0
NLM_Port Port utilisé par le protocole NLM. Défaut: 0
Bind_addr Adresse d'écoute. Défaut: 0.0.0.0
NFS_Program Numéro RPC pour NFS. Défaut: 100003
MNT_Program Numéro RPC pour MNT. Défaut: 100005
NLM_Program Numéro RPC pour NLM. Défaut: 100021
Nb_Worker Nombre de threads. Défaut: 256
Drop_IO_ERrors (NFS3), indique de supprimer au lieu de répondre aux requêtes contenant des erreurs E/S.
Drop_Inval_Errors (NFS3)indique de supprimer au lieu de répondre aux requêtes contenant des erreurs d'arguments
Drop_Delay_Errors [NFS3) indique de supprimer au lieu de répondre aux requêtes contenant des erreurs de délai
Dispatch_Max_Reqs Nombre total de requêtes à autoriser dans le dispatcher simultannément. Défaut: 5000
Dispatch_Max_Reqs_Xprt Nombre de requêtes à autoriser dans le dispatcher depuis un transport spécifique. Défaut: 512
Plugins_Dir Chemin contenant les modules. Défaut: /usr/lib64/ganesha
Enable_Fast_Stats Indique si fast stats est utilisé
Short_File_Handle (NFS3) Utilise le file handle NFS cours, pour les clients VMware.
Manage_Gids_Expiration Délai de conservation des informations obtenue par getgroups quand Manage_Gids = TRUE est utilisé dans une entrée d'export
heartbeat_freq Frequnce de heartbeat dbus, en ms. Défaut: 1000
Enable_NLM Active le supporte du protocole NLM;
Decoder_Fridge_Expiration_Dela Délai d'attente en secondes, des threads decodeur non-utilisés avant de quitter. Défaut: 600
Decoder_Fridge_Block_Timeout Délait d'attente en secondes, du decodeur fridge pour accèpter une tâche avant de quitter. Défaut: 600
Blocked_Lock_Poller_Interval Interval d'interrogation pour le thread d'interrogation de lock bloqué. Défaut: 10
NFS_Protocols Liste de versions de protocoles autorisés. Défaut: 3,4
NSM_Use_Caller_Name Utilise le nom fournis au lieu de d'adresse IP dans NSM.
Clustered Indique si ganesha fait partie d'un cluster de serveurs Ganesha.
fsid_device Utilisation de périphérique majeur/mineur pour fsid
mount_path_pseudo Utilise Pseudo (true) ou Path (false) pour les montages NFS3 et 9P
DRC_Disabled Désactive DRC
TCP_Npart Nombre de partitions dans l'arborescence pour TCP DRS. Défaut: 1
DRC_TCP_Size Nombre maximum de requête dans un DRC de transport. Défaut: 1024
DRC_TCP_Cachesz Nombne d'entrée dans le cache frontend vers un cache de requête TCP Dupliqué. Défaut: 127
DRC_TCP_Hiwat watermark haut pour le DRC d'une connexion TCP pour commencer à retirer les entrées si possible
DRC_TCP_Recycle_Npart Nombre de partitions dans l'arborescence qui maintient les DRC par connexion peut qu'ils puissent être utilisés à la reconnexion
DRC_TCP_Recycle_Expire_S Délai en secondes d'attente avant de libérer le DRC d'un client déconnecté. Défaut: 600
DRC_TCP_Checksum Utilise un checksum pour matcher les requêtes et le XID.
DRC_UDP_Npart Nombre de partitions dans l'arborescence DRC UDP
DRC_UDP_Size Nombre maximum de requêtes dans le DRC UDP
DRC_UDP_Cachesz Nombre d'entrées dans le cache frontend pour le cache de requêtes UDP dupliquées
DRC_UDP_Hiwat Watermark haut pour DRC UDP auquel commencer à retirer les entrées si possible
DRC_UDP_Checksum Utilise un checksum pour matcher les requêtes et le XID
RPC_Debug_Flags Flags de débug pour TIRPC
RPC_Max_Connections Nombre max de connexions pour TIRPC. Défaut: 1024
RPC_Idle_Timeout_S Délai idle en secondes Défaut: 300
MaxRPCSendBufferSize Taille du tampon d'envoie RPC. Défaut: 1048576
MaxRPCRecvBufferSize Taille du tampon de réception RPC. Défaut: 1048576
RPC_Ioq_ThrdMax Threads io simultanné max
RPC_GSS_Npart Partitions dans la table de cache ctx GSS
RPC_GSS_Max_Ctx Contextes GSS max dans le cache. Défaut: 16384.
RPC_GSS_Max_Gc Entrées max pour expiration en une vérification idle
Enable_TCP_keepalive Spécifie si les sockets TCP utilisent SO_KEEPALIVE
TCP_KEEPCNT Nombre max de sondes TCP avant de détruire la connexion. Défaut: 0 (utilise le défaut système)
TCP_KEEPIDLE Temps idle avant que TCP ne commence à envoyer des sondes keepalive. Défaut: 0 (utiliser de défaut système)
TCP_KEEPINTVL Temps entre que chaque sonde keepalive. Défaut: 0 (utiliser de défaut système)

NFS_IP_NAME

Index_Size 1-51 Configuration pour la table de hash pour les mappages NFS name/IP map. Défaut: 17
Expiration_Time Délai d'expiration pour les mappages ip-name. Défaut: 3600

NFS_KRB5

PrincipalName principale pour le service. Défaut: nfs
KeytabPath Emplacement du fichier keytab
CCacheDir Emplacement du cache d'accréditifs. Défaut: /var/run/ganesha
Active_krb5 Indique si kerberos5 est activé

NFSv4

Graceless Désactive la période de grâce NFS4
Lease_Lifetime Durée de vie des bails NFS4
Grace_Period Période de grâce NFS
DomainName Domaine à utiliser si nfsidmap n'est pas utilisé
IdmapConf Chemin du fichier de configuration idmapd.conf
UseGetpwnam Utilise PAM au lieu de nfsidmap
Allow_Numeric_Owners Autorise les ID numériques dans les identifiants de propriétaire et groupe NFS4
Only_Numeric_Owners N'autorise que les ID numérique dans les identifiants de propriétaire et groupe NFS4
Delegations Autorise les délégations
Deleg_Recall_Retry_Delay Délai après lequel le serveur retente un recall en cas d'erreurs
pnfs_mds Indique si c'est un serveur pNFS MDS
pnfs_ds Indique si c'est un serveur pNFS DS

EXPORT_DEFAULTS

Access_Type RW, RO, MDONLY, MDONLY_RO, NONE.
Protocols Liste de protocoles permis: 3, 4, v3, v4, NFS3, NFS4
Transports Liste de protocoles de transport permis: UDP, TCP et RDMA
Squash Type de squashing: No_Root_Squash, NoIdSquash, None désactive le squashing, Root, Root_Squash, RootSquansh squash root, All, All_Squash, AllSquash squash tous les users
Anonymous_Uid uid utilisé pour les utilisateurs squashés.
Anonymous_Gid gid utilisé pour les groupes squashés.
SecType Liste de types de sécurité RPC autorisés: none, krb5, krb5i, krb5p
PrivilegedPort à true, les connexions client doivent venir d'un port ‹ 1024.
Manage_Gids À true, la liste de groupes alternatifs dans les accréditifs AUTH_SYS sont remplacés par une recherche serveur. Celà permet de bypasser la limite des 16 groupes de AUTH_SYS
Delegations Types de délégations qui peuvent être donnés (None, Read, Write, ReadWrite, R, W, et RW)
Attr_Expiration_Time Défaut: 60
NFS_Commit Défaut: false

EXPORT

Export_id Identifiant pour l'export. Doit être unique entre 0 et 65535. à 0, Pseudo doit être '/'
Path Répertoire à exporter. Ne Doit pas être unique si Pseudo et/ou Tag sont spécifiés
Pseudo Spécifie la position dans le Pseudo système de fichier que cet export occupe. Doit être unique. peut être spécifié plusieurs fois
Tag Permet un accès alternatif pour les montages NFSv3
MaxRead Taille le lecture maximum dans cet export. Défaut: 4194304
MaxWrite Taille d'écriture maximum dans cet export. Défaut: 4194304
PrefRead Taille de lecture préférée dans cet export. Défaut: 4194304
PrefWrite Talle d'écriture préférée dans cet export. Défaut: 4194304
PrefReaddir Taille readdir préféré dans cet export. Défaut: 16384. Ces 5 options on la même plage de valeurs de 512 à 9Mio
MaxOffsetWrite Offset de fichier maximum qui peut être écrit. Défaut: 18446744073709551615
MaxOffsetRead Offset de fichier maximum que peut être lu. Défaut: 18446744073709551615

EXPORT-CLIENT

        Clients Liste les entrées des clients. Peut être @netgroup, x.x.x.x/y, hostname, IPv4|IPv6. l'utilisation de '?' ou '*' est permise
        ‹export_perms› Toutes les permissions d'export dans le section EXPORT_DEFAULTS sont permise

EXPORT-FSAL

        Name Nom du FSAL
        ‹options› Les options dépendent du FSAL.

EXPORT-FSAL-PNFS

                Stripe_Unit Défaut: 8192
                pnfs_enabled Active pnfs. Défaut: false

EXPORT-FSAL-FSAL

                Décris les paramètres FSAL stackés

LOG

Default_log_level NULL|FATAL|MAJ|CRIT|WARN|EVENT|INFO|DEBUG|MID_DEBUG|M_DBG|FULL_DEBUG|F_DBG Niveau de logs par défaut
COMPONENTS Chaque entrée est sous la forme COMPONENT = LEVEL. Les composants sont:

LOG-COMPONENTS

        ALL
        LOG
        LOG_EMERG
        MEMLEAKS, LEAKS
        FSAL
        NFSPROTO, NFS3
        NFS_V4, NFS4
        EXPORT
        FILEHANDLE, FH
        DISPATCH, DISP
        CACHE_INODE, INODE
        CACHE_INODE_LRU, INODE_LRU
        HASHTABLE, HT
        HASHTABLE_CACHE, HT_CACHE
        DUPREQ
        INIT, NFS_STARTUP
        MAIN
        IDMAPPER
        NFS_READDIR
        NFS_V4_LOCK, NFS4_LOCK
        CONFIG
        CLIENTID
        SESSIONS
        PNFS
        RW_LOCK
        NLM
        RPC
        NFS_CB
        THREAD
        NFS_V4_ACL, NFS4_ACL
        STATE
        9P
        9P_DISPATCH, 9P_DISP
        FSAL_UP
        DBUS
        NFS_MSK

LOG-FACILITY

        name file|syslog Nom du nouveau logger
        destination stdout|stderr|syslog/‹file-path› Emplacement du fichier de log
        max_level NULL|FATAL|MAJ|CRIT|WARN|EVENT|INFO|DEBUG|MID_DEBUG|M_DBG|FULL_DEBUG|F_DBG Niveau de log maximum que ce logger gère. défaut: FULL_DEBUG
        headers none|component|all Niveau de détail pour la partie en-tête du message
        enable idle|active|default Active le logger

LOG-FORMAT

        date_format ganesha|true|local|8601|ISO-8601|ISO 8601|ISO|syslog|syslog_usec|false|none|user_defined Défaut: ganesha
        time_format ganesha|true|local|8601|ISO-8601|ISO 8601|ISO|syslog|syslog_usec|false|none|user_defined Défaut: ganesha
        user_date_format Spécifie le format pour date_format user_defined
        user_time_format Spécifie le format pour time_format user_defined
        EPOCH true|false Les dates sont basé sur l'epoch
        CLIENTIP true|false Inclus l'IP du client dans les logs
        HOSTNAME true|false Inclus les noms d'hôte dans les logs
        PROGNAME true|false Inclus le nom du programme dans les logs
        PID true|false Inclus de pid dans les logs
        THREAD_NAME true|false Inclus le nom du thread dans les logs
        FILE_NAME true|false Inclus le nom du fichier dans les logs
        LINE_NUM true|false Inclus de numéro de ligne dans les logs
        FUNCTION_NAME true|false Inclus le nom de la fonction dans les logs
        COMPONENT true|false Inclus le composant dans les logs
        LEVEL true|false Inclus le niveau de log

CACHEINODE

NParts Nombre de partitions dans l'arborescence Cache_Inode. Défaut: 7
Cache_Size Taille de table de hashage par partition
Use_Getattr_Directory_Invalidation Utilise getattr pour l'invalidation de répertoire
Dir_Max_Deleted Taille max du cache par répertoire des entrées supprimées. Défaut: 65536
Dir_Max Taille max du cache dirent par répertoire. Défaut: 65536
Dir_Chunk Taille des chunks du cache dirent par répertoire. 0 = le chunking n'est pas autorisé. Défaut: 128
Entries_HWMark watermark haut pour les entrées du cache. Défaut: 100000
LRU_Run_Interval Interval de base en secondes entre les lancerment du thread cleaner LRU. Défaut: 90
Cache_FDs spécifie si le cache des fichiers ouvert est autorisé
FD_Limit_Percent % du maximum imposé par le système de descripteurs de fichier au delà duquel ganesha refuse les requêtes
FD_HWMark_Percent % du maximum imposé par le système de descripteurs de fichier au delà duquel ganesha fera plus d'effort de récupération.
FD_LWMark_Percent % du maximum imposé par le système de descripteurs de fichier en-dessous duquel ganesha ne récupère pas de descripteur de fichiers..
Reaper_Work Quantité de travail à faire à chaque passe dans des conditions normales
Biggest_Window La fenêtre la plus large en % de la limite imposée par le système sur les FD, du travail qui est fait en extrême.
Required_Progress % de progression au-delà du watermark haut requis dans une passe via le thread en extrême.
Futility_Count Nombre d'erreurs pour approcher le watermark haut avant de désactiver le cache.
Retry_Readdir Comportement quand readdir échoue. true, demande au client de retenter ultérieurement.

9P

_9P_TCP_Port
_9P_RDMA_Port
_9P_TCP_Msize
_9P_RDMA_Msize
_9P_RDMA_Backlog
_9P_RDMA_Inpool_size
_9P_RDMA_Outpool_Size

CEPH

Ceph_Conf
umask
xattr_access_rights

GPFS

link_support
symlink_support
cansettime
umask
auth_xdev_export
xattr_access_rights
Delegations
pnfs_file
fsal_trace
fsal_grace

MEM

Inode_Size
Up_Test_Interval

RGW

Ceph_Conf
name
cluster
init_args

VFS

link_support
symlink_support
cansettime
maxread
maxwrite
umask
auth_xdev_export
xattr_access_rights

XFS

link_support
symlink_support
cansettime
maxread
maxwrite
umask
auth_xdev_export
xattr_access_rights

ZFS

link_support
symlink_support
cansettime
maxread
maxwrite
umask
auth_xdev_export
xattr_access_rights

PROXY

link_support
symlink_support
cansettime
MAX_READ_WRITE_SIZE
FSAL_MAXIOSIZE
SEND_RECV_HEADER_SPACE
maxread
maxwrite
umask
auth_xdev_export
xattr_access_rights

PROXY-Remote_Server

        Retry_SleepTime
        Srv_Addr
        NFS_Service
        NFS_SendSize
        NFS_RecvSize
        MAX_READ_WRITE_SIZE
        SEND_RECV_HEADER_SPACE
        FSAL_MAXIOSIZE
        NFS_SendSize
        NFS_RecvSize
        NFS_Port
        Use_Privileged_Client_Port
        RPC_Client_Timeout
        Remote_PrincipalName
        KeytabPath
        Credential_LifeTime
        Sec_Type
        Active_krb5
        Enable_Handle_Mapping
        HandleMap_DB_Dir
        HandleMap_Tmp_Dir
        HandleMap_DB_Count
        HandleMap_HashTable_Size

GLUSTER

pnfs_mds true|false
pnfs_ds true|false
^
03 novembre 2016

htmlpdflatexmanmd




gdisk

gdisk

manipulateur de table de partition GUID interactive

   GPT fdisk est un programme pour la création et la manipulation de tables de partition. Il convertit automatiquement une table de partition MBR ou BSD en table partition GPT, ou charge une table GUID. Utilisé avec l'option -l, le programme affiche la table courante et quitte.

   gdisk opère principalement sur les en-tête GPT et les tables de partition; cependant, il peut générer un MBR de protection si requis. (Tout code de boot n'est pas perturbé). Dans ce cas, un MBR hybride créé par gptsync ou gdisk, Cela ne perturbe pas la plupart des actions ordinaires. Certaines options de récupération avancées nécessite de comprendre les distinctions entre les données principales et les sauvegardes, ainsi que les différences entre les en-têtes GPT et les tables de partition.

   Le programme gdisk emploie une interface utilisateur similaire à fdisk, mais gdisk modifie les partitions GPT. Il a également la capacité de transformer les partitions MBR et BSD en partitions GPT. Comme fdisk, gdisk ne modifie pas les structures de disque jusqu'à écrire explicitement.

   Généralement, gdisk opère sur les fichiers de périphérique disque, tel que /dev/sda ou /dev/hda. Le programme peut également opérer sur les fichiers d'image disque, qui peut être soit des copies de disque entier ou des images disques brutes utilisés par les émultateurs tels que QEMU.S Noter que seul les images raw sont pris en charge.

   Le système de partitionnement MBR utilise une combinaison d'adressage CHS et LBA. GPT supprime l'adressage CHS et utilise le mode LBA 64-bits exclusivement. Donc, les structures de données GPT, et gdisk, n'ont pas besoin de gérer les géométries CHS et tous les problèmes qu'ils crééent. Les utilisateurs de fdisk noterons que gdisk n'a pas d'options ni les limitations associées avec les géométries CHS.

   Au démarrage, gdisk tente d'identifier le type de partition utilisé sur le disque. S'il trouve une donnée GPT valide, gdisk l'utilise. S'il trouve un MBR valide ou un disklabel BSD sans donnée GPT, il tente de convertir le MBR en GPT. La conversion laisse au moins un gap dans la numérotation de partition si le MBR original utilisait des partitions logiques. Ces gap sont sans conséquence mais peuvent être éliminés avec l'option 's'. En créant une nouvelle table de partition, certaines considérations peuvent être dans l'ordre:

- Pour les disques de données, et pour les disques de boot utilisé dans les machines à base de BIOS avec GRUB, les partitions peuvent être créées dans n'importe quel ordre et de n'importe quelle taille.
- Les disques de boot pour les systèmes UEFI nécessitent un partition système EFI (0xEF00) formattée en FAT-32. La taille recommandée de cette partition est entre 100 et 300 Mio.
- Si Windows boot depuis un disque GPT, une partition de type Microsoft Reserved (0x0C01) est recommandé. Cette partition devrait faire environ 128Mio. IL suit ordinairement la partition EFI et précéder immédiatement les partitions de données de Windows.
- Certains utilitaires GPT créent un espace blanc (généralement le 128Mio) après chaque partition. Le but est de permettre aux futures utilitaires de disque d'utiliser cet espace. Un tel espace n'est pas un pré-requis des disques GPT, mais les créer peut aider de futures maintenance de disque. Il est possible d'utiliser l'option de positionnement de partition active de fdisk (en spécifiant le secteur de démarrage avec +128M) pour simplifier la création de ce gap.

OPTIONS

-l Liste la table de partition pour le périphérique spécifié et quitte

Options du menu principal

b Sauver les données de partition dans un fichier backup. Permet de sauvegarder la table de partition courante en mémoire dans un fichier disque. Le fichier résultant est un fichier binaire consistant du MBR, l'en-tête GPT principale, l'en-tête GPT de sauvegarde et une copie de la table de partition, dans cet ordre. Noter que la sauvegarde est faite des structures de données courantes en mémoire.
c Change le nom GPT d'une partition
d Supprime une partition.
i Affiche des informations détaillées
l Affiche un sommaire des types de partition.
n Créé une nouvelle partition
o Efface toutes les données de partition.
p Affiche un sommaire basique de partitions
q Quitte le programme
r Entrer dans le menu de récupération et de transformation
s Trie les entrées de partition
t Change de code de type d'une partition
v Vérifie le disque.
w Écrit les changement sur le disque
x Entre dans le menu expert

Options du menu récupération et transformation

b Reconstruit l'en-tête GPT depuis une sauvegarde.
c Charge une sauvegarde de table de partition.
d Utilise l'en-tête GPT principal et reconstruit le backup, utile si l'en-tête GPT sauvegardé a été endommagé ou détruit
e Charge la table de partition principale. Cette option recharge la table de partition principale depuis le disque
f Charge le MBR et lui construit un GPT. Utile si le GPT est corrompu ou en conflit avec le MBR.
g Convertit GPT en MBR et quitte. Détruit les structures de données GPT
h Créé un MBR hybride.
i Affiche des informations de partition détaillées
l Charge les données de partition depuis un fichier sauvegarde.
m Retourne dans le menu principal
o Affiche les données MBR protectives
p Affiche la tables de partitions
q Quitte dans sauvegarder
t Transforme des partitions BSD en GPT
v Vérifie le disque
w Écris les données sur disque
x Entre dans le menu expert

Options du menu expert

a Définis des attributs. GPT fournis des champs d'attribut 64bits qui peuvent être utilisé pour définir des fonctionnalités pour chaque partition. gdisk supporte 'system partition', 'read-only', 'hidden'.
c Change le GUID d'une partition
d Affiche la valeur d'alignement de secteur
e Déplace les structures de données GPT à la fin du disque. Utile si vous avez ajouté des disques à un raid.
f Rend aléatoire le GUID de disque et de toutes les partitions. Peut être utilisé pour après avoir cloné un disque avec un autre utilitaire.
g Change le GUID du disque.
h Recalcule les valeurs CHS dans le MBR protective ou hybride
i Affiche des informations de partition détaillées.
l Change la valeur d'alignement de secteur. Les disques avec plus de secteurs logiques par secteur physique peuvent souffrir de problèmes de performance si les partitions ne sont pas alignées
m Retourne au menu principal
n Créé un nouveau MBR protective
o Affiche les données du MBR protective
p Affiche la table de partition
q Quitte sans sauvegarder les changements
r Entre dans le menu récupération et transformation
s Redimmensionne la table de partition. La taille est de 128 entrées par défaut. Officiellement, les tables inférieur à 128 entrées (16k) ne sont pas supportés par GPT.
t Inverse 2 entrées de partitions dans la table de partitions. N'altère que leur ordre dans la table
u Réplique la table de partition courante du périphérique dans un autre périphérique.
v Vérifier le disque
z Détruit les structures de données GPT et quitte.
^
16 mai 2017

htmlpdflatexmanmd




genhomedircon

genhomedircon

Générer des entrées de configuration de contexte de fichier SELinux pour les répertoires personnels

   genhomedircon est un script qui exécute semodule pour reconstruire la stratégie SELinux active (sans la recharger) et pour créer les labels pour chaque répertoire personnel basé ser les chemins retournés par getpwent. Ce script est généralement exécuté par semanage bien que cela peut être modifié par disable-genhomedircon=true dans semanage.conf.

^
18 mars 2016

htmlpdflatexmanmd




genrandom

genrandom

Génère un fichier contenant des données aléatoires

   genrandom génère un fichier ou un jeu de fichiers contenant une quantité spécifiée de données pseudo-aléatoires qui peuvent être utilisée comme source d'entropy pour d'autres commandes sur les systèmes dans périphérique aléatoire.

OPTIONS

number Au lieu de générer un fichier, génère n fichiers (de 2 à 9), en ajoutant number au nom de fichier
size Taille du fichier en Ko à générer
filename Nom du fichier à générer
^
05 septembre 2015

htmlpdflatexmanmd




getcap

getcap

Examine les capabilities d'un fichier

   getcap affiche le nom et les capabilities de chaque fichier spécifié

OPTIONS

-r Recherche récursivement
-v Affiche toutes les entrées recherchées, même si elle nom pas de capabilities
^
10 juillet 2014

htmlpdflatexmanmd




getent.ldap

getent.ldap

Demandes d'informations LDAP

   getent.ldap peut être utilisé pour rechercher ou énumérer les informations LDAP. À la différence de getent, cette commande bypass complètement les recherches configurées dans nsswitch.conf. et requête nslcd directement. getent.ldap tente de correspondre au fonctionnement et à la sortie de getent autant que possible, cependant il y a certaines différences. Si plusieurs entrées sont trouvées dans LDAP, plusieurs valeurs sont affichées. Certaines base ont des options supplémentaires.

bases

aliases Liste ou requête les alias mail
ethers Liste ou requête les adresses ethernet
group Liste ou requête les groupes. Il recherche les groupes par group id
group.member Si l'argument est un username, retourne les groupes dont l'utilisateur est membre.
hosts Liste ou requête nom d'hôte et adresses par nom d'hôte, ipv4 ou ipv6.
hostsv4 Idem mais ne retourne que les adresses ipv4
hostsv6 Idem mais ne retourne que les adresses ipv6
netgroup Liste les triplet netgroup
netgroup.norec Idem excepté qu'aucune autre recherche n'est faite pour étendre les netgroups qui sont membre du netgroup fournis.
networks Liste les noms et adresses de réseaux
networksv4 Idem mais retourne uniquement les adresses ipv4
networksv6 Idem mais retourne uniquement les adresses ipv6
passwd Liste ou recherche le compte utilisateur
protocols Énumère la base de protocoles internet
rpc Liste ou recherche les noms qui mappe les numéro RPC
services Liste ou recherche le mappage entre les noms pour les services internet et leur numéro de port correspondant
shadow Liste ou recherche les informations étendus de compte utilisateur.
^
29 août 2015

htmlpdflatexmanmd




getfacl

getfacl

Récupère les listes de contrôle d'accès des fichiers

   Pour chaque fichier, getfacl affiche le nom du fichier, propriétaire, groupe propriétaire, et l'ACL. Si un répertoire a une ACL par défaut, getfacl affiche également l'ACL par défaut.

   Si getfacl est utilisé dans un système de fichier qui ne supporte pas les ACL, getfacl affiche les permissions d'accès définis par les bits de permissions traditionnels.

   Le format de sortie de getfacl est comme suit:

1: # file: somedir/
2: # owner: lisa
3: # group: staff
4: # flags: -s-
5: user::rwx
6: user:joe:rwx #effective:r-x
7: group::rwx #effective:r-x
8: group:cool:r-x
9: mask::r-x
10: other::r-x
11: default:user::rwx
12: default:user:joe:rwx #effective:r-x
13: default:group::r-x
14: default:mask::r-x
15: default:other::---

   Les lignes 1--3 indiquent le nom du fichier, propriétaire, et groupe propriétaire.

   La ligne 4 indique les bits de mode spéciaux.

   Les lignes 5, 7 et 10 correspondent au champs user, group et other des bits de permission de fichier. Ce sont les entrées d'ACL de base.

   Les lignes 6 et 8 sont les utilisateurs et groupes nommés.

   La ligne 9 est le masque de droits effectifs

   Les lignes 11--15 affichent l'ACL par défaut associée avec ce répertoire.

OPTIONS

-a, --access Affiche la liste de contrôle d'accès du fichier
-d, --default Affiche l'ACL par défaut
-c, --omit-header N'affiche pas la ligne d'en-tête
-e, --all-effective Affiche les commentaires de droits effectifs
-E, --no-effective N'affiche pas les commentaires de droits effectifs
-s, --skip-base Saute les fichiers qui ont seulement les entrées d'ACL de base
-R, --recursive Liste les ACL de tous les fichiers et répertoire récursivement
-L, --logical Mode logique, traverse les liens symboliques. Seulement avec -R
-P, --physical Mode physique, ne traverse pas les liens symboliques. Seulement avec -R
-t, --tabular Utilise un format de sortie alternatif.
p, --absolute-names N'enlève pas le dernier '/'.
-n, --numeric Liste les UID,GID
-- Fin des arguments de la ligne de commande
Si un paramètre est un '-', lis depuis l'entrée standard
^
05 septembre 2015

htmlpdflatexmanmd




getfattr

getfattr

Récupérer les attributs étendus des objets du système de fichier

   Pour chaque fichier, getfattr affiche le nom du fichier, et le jeu de noms d'attributs étendus (et les valeurs optionnelles) qui sont associés avec le fichier.

Le format de sortie de getfattr est comme suit:
1: # file: somedir/
2: user.name0="value0"
3: user.name1="value1"
4: user.name2="value2"
5: ...

   La ligne 1 identifie le nom du fichier pour lequel les lignes suivantes sont reportés. Les lignes restantes affichent les paire nom/valeur associés avec le fichier spécifié.

OPTIONS

name, --name=name Dump la valeur de l'attribut étendu nommé
-d, --dump Dump les valeurs de tous les attributs étendus
-e en, --encoding=en Encode les valeur après les avoir récupéré. Les valeur valides de en sont text, hex, base64. Les valeurs encodé en texte sont entre guillemets, les chaîne en hexa sont préfixé avec 0x et les chaines base64 sont préfixés avec 0s.
-h, --no-dereference Ne déréférence pas les liens symboliques.
-m pattern, --match=pattern Inclus seulement les attributs qui correspondent à l'expression régulière
--absolute-names N'enlève par le '/' restant.
--only-values Dump les attributs étendus au format brut, sans les encoder
-R, --recursive Liste les attributs de tous les fichiers et répertoires récursivement
-L, --logical Suit les liens vers les répertoires.
-P, --physical Ne suit pas les liens symboliques vers les répertoires
^
31 mai 2010

htmlpdflatexmanmd




getty

getty, agetty

Ouvre un port de terminal, demande un nom d'utilisateur et apples /bin/login.

   agetty a plusieurs fonctionnalités non standard qui sont utiles pour les lignes série et modem.

Paramètres

port Un nom de chemin relatif au répertoire /dev. Si un « - » est utilisé, agetty suppose que son entrée standard est déjà connectée à un port de terminal et que la connection à un utilisateur distant est déjà établie.
vitesse_baud,... Une liste de vitesses en baud séparées par des virgules. Chaque fois que agetty reçoit un caractère BREAK, il avance dans la liste, qui sera considérée comme une liste circulaire.
term La valeur à utiliser pour la variable d’environnement TERM. Ceci surcharge toute valeur positionnée par init(8) et qui est héritée par login et par l’interpréteur de commande.

OPTIONS

-8 Suppose que le terminal gère les caractères 8 bits, désactiver de ce fait la détection de parité.
-h Activer le contrôle de flux matériel (RTS/CTS). L’application est libre de désactiver le contrôle de flux logiciel (XON/XOFF) quand elle le juge opportun.
-i Ne pas afficher le contenu de /etc/issue (ou autre) avant d’écrire l’invite de connexion
-f Afficher le contenu du fichier spécifié au lieu de /etc/issue. L’option -i surcharge cette option.
-I Définit une chaîne initiale à envoyer au terminal ou au modem avant d’envoyer des données utiles. Ceci peut être utilisé pour initialiser un modem.
-l Appeler un programme de connexion autre que /bin/login.
-H Écrire l’hôte de connexion spécifié spécifié dans le fichier utmp. Normalement, aucun hôte de connexion n’est fourni, puisque agetty est utilisé pour les connexions matériels locales et les terminaux du système. Cependant, cette option peut être utile pour identifier les concentrateurs de terminaux et équivalent.
-m Essayer d’extraire la vitesse depuis le message de statut CONNECT produit par les modems compatibles Hayes
-n  Ne pas demander d’identifiant de connexion à l’utilisateur. Cela peut être utilisé avec l’option -l lors d’une connexion à un système non standard comme les systèmes BBS
-t Quitter si aucun nom d’utilisateur n’a pu être lu pendant la durée spécifiée en secondes.
-L Forcer la ligne à être une ligne locale sans détection des retour à la ligne. Utile lorsque que vous avez un terminal attaché dont la ligne série ne définit pas le signal de retour à la ligne.
-U Activer la détection des terminaux à caractères majuscules seuls.
-w Attendre que l’utilisateur ou le modem envoie un caractère retour à la ligne ou nouvelle ligne avant d’envoyer le fichier /etc/issue et l’invite de connexion. Cela est très utile lors de connexions avec l’option -I.

Exemples

exemple dans inittab pour une ligne série ou une console tty
/sbin/agetty 9600 ttyS1
Pour un terminal connecté directement sans détection de porteuse
/sbin/agetty -L 9600 ttyS1 vt100
Pour une ligne avec un vieux modem supportant les vitesses de 9600, 2400 et 1200 bauds.
/sbin/agetty -mt60 ttyS1 9600,2400,1200

Suites d'échappement des fichiers issue

   Le fichier issue (/etc/issue) ou le fichier défini avec l’option -f peut contenir certains codes d’échappement afin d’afficher le nom du système, la date, le temps, etc. Tous les caractères d’échappement sont formés d’un backslash (\) immédiatement suivi par l’une des lettres listées ci-dessous.

b Insérer la vitesse en bauds de la ligne actuelle.
d Insérer la date actuelle.
s Insérer le nom du système, le nom du système d’exploitation.
l Insérer le nom de la ligne tty actuelle.
m Insérer l’identifiant de l’architecture de la machine, par exemple i486.
Insérer le nom de noeud, ou nom d’hôte, de la machine.
o Insérer le nom de domaine NIS de la machine.
O Insérer le nom de domaine DNS de la machine.
r Insérer le numéro de version de l’OS, par exemple 1.1.9.
t Insérer l’heure actuelle.
u Insérer le nombre d’utilisateurs actuellement connectés.
U Isérer la chaîne « 1 user » (1 utilisateur) ou « ‹n› users » où ‹n› est le nombre d’utilisateur actuellement connectés.
v Insérer la version de l’OS, par exemple sa date de construction etc.

Exemples

Par exemple, sur mon système, le fichier /etc/issue contient
This is \n.\o (\s \m \r) \t
qui affichera
This is thingol.orcan.dk (Linux i386 1.1.9) 18:29:30

Fichiers

/var/run/utmp le fichier d’état système.
/etc/issue affiché avant l’invite de connexion.
/dev/console rapports d’anomalies (si syslog(3) n’est pas utilisé).
/etc/inittab fichier de configuration de init(8).
^
12 février 2015

htmlpdflatexmanmd




gluster

gluster

Gestionnaire gluster

Commandes

volume info [all|‹VOLNAME›] Affiche des informations sur tous les volumes, ou le volume spécifié
volume create ‹NEW-VOLNAME› [stripe ‹COUNT›] [replica ‹COUNT›] [disperse [‹COUNT›]] [redundancy ‹COUNT›] [transport ‹tcp|rdma|tcp,rdma›] ‹NEW-BRICK› ... Crée un nouveau volume.
volume delete ‹VOLNAME› Supprime le volume spécifié
volume start ‹VOLNAME› Démarre le volume spécifié
volume stop ‹VOLNAME› [force] Arrête le volume spécifié
volume rename ‹VOLNAME› ‹NEW-VOLNAME› Renomme le volume spécifié
volume set ‹VOLNAME› ‹OPTION› ‹PARAMETER› [‹OPTION› ‹PARAMETER›] ... Définis les options du volume
volume get ‹VOLNAME› ‹OPTION/all› Afficher les options du volume

Commandes de briques

volume add-brick ‹VOLNAME› ‹NEW-BRICK› ... Ajoute le brick spécifié au volume spécifié
volume remove-brick ‹VOLNAME› ‹BRICK› ... Supprime le brick spécifié
volume replace-brick ‹VOLNAME› ‹SOURCE-BRICK› ‹NEW-BRICK› commit force Remplace le brick spécifié
volume rebalance ‹VOLNAME› start Démarre la re-balance du volume spécifié
volume rebalance ‹VOLNAME› stop Stope la re-balance du volume spécifié
volume rebalance ‹VOLNAME› status Affiche le status de re-balance du volume spécifié

Commandes des logs

volume log filename ‹VOLNAME› [BRICK] ‹DIRECTORY› Répertoire de log pour le volume/brick correspondant
volume log locate ‹VOLNAME› [BRICK] Localise le répertoire de logs
volume log rotate ‹VOLNAME› [BRICK] Effectue une rotation des fichier de logs

Commandes de paires

peer probe ‹HOSTNAME› Cherche et ajoute le pair spécifié.
peer detach ‹HOSTNAME› Détache le pair spécifié
peer status Affiche le status des pairs

Commandes tier

volume tier ‹VOLNAME› attach [‹replica COUNT›] ‹NEW-BRICK›... Attache à un volume existant un tier du type spécifié en utilisant les bricks spécifiés
volume tier ‹VOLNAME› status Affiche des statistiques sur la migration des données entre les tiers chaud et froid
volume tier ‹VOLNAME› detach start Détache le tier chaud du volume. Les données sont déplacées du tier chaud vers le tier froid
volume tier ‹VOLNAME› detach commit [force] Sousmet un détachement du tier chaud du volume. Le volume revient à son état d'origine avant que le tier chaud ne soit attaché
volume tier ‹VOLNAME› detach status Afficher le status du mouvement des données
volume tier ‹VOLNAME› detach stop Arrête de détacher le tier chaud du volume

Commandes Geo-replication

volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› create [push-pem] [force] Créer une nouvelle session de geo-réplication.
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› {start|stop} [force] démarre/arrête la session de geo-replication.
volume geo-replication [‹MASTER_VOL› [‹SLAVE_HOST›::‹SLAVE_VOL›]] status [detail] Affiche le status de la session de geo-replication
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› {pause|resume} [force] Pause/relance la session de geo-replication
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› delete [reset-sync-time] Détruire une session de geo-replication. reset-sync-time réinitialise le délai de synchro.
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› config [[!]‹options› [‹value›]] voir ou définis la configuration pour la session de geo-replication

Commandes bitrot

volume bitrot ‹VOLNAME› {enable|disable} active/désactive le bitrot pour le volume
volume bitrot ‹VOLNAME› scrub-throttle {lazy|normal|aggressive} la valeur scrub-throttle est une mesure sur la rapidité du scrubs de système de fichier
volume bitrot ‹VOLNAME› scrub-frequency {daily|weekly|biweekly|monthly} Fréquence du scrubing
volume bitrot ‹VOLNAME› scrub {pause|resume|status|ondemand} paume/relance le scrub

commandes de snapshots

snapshot create ‹snapname› ‹volname› [description ‹description›] [force] Créé un snapshot d'un volume glusterfs.
snapshot restore ‹snapname› Applique un snapshot à un volume glusterfs
snapshot delete ( all | ‹snapname› | volume ‹volname› ) Supprime un snapshot
snapshot clone ‹clonename› ‹snapname› Clone un volume snapshot
snapshot list [volname] Liste les snapshots d'un volume
snapshot info [snapname | (volume ‹volname›)] Affiche des informations sur un snapshot
snapshot status [snapname | (volume ‹volname›)] Donne le status d'un snapshot
snapshot config [volname] ([snap-max-hard-limit ‹count›] [snap-max-soft-limit ‹percent›]) | ([auto-delete ‹enable|disable›]) | ([activate-on-create ‹enable|disable›]) Affiche et définis les valeurs de configuration d'un snapshot. Possède les options suivantes:

        snap-max-soft-limit ‹count› option globale.
        snap-max-soft-limit ‹percent› option globale
        auto-delete ‹enable|disable› option globale. permet de conserver snap-max-soft-limit snapshots au maximum
        activate-on-create ‹enable|disable› active le snapshot à la création

snapshot activate ‹snapname› Active le snapshot spécifié.
snapshot deactivate ‹snapname› Désactive le snapshot spécifié

Commande heal

volume heal ‹VOLNAME› déclenche l'indexe de réparation pour les fichiers qui doivent être réparés
volume heal ‹VOLNAME› [enable|disable] Active/désactive le service d'auto-réparation pour le volume
volume heal ‹VOLNAME› full Déclenche l'auto-réparation sur tous les fichiers
volume heal ‹VOLNAME› info Liste les fichiers qui doivent être réparés
volume heal ‹VOLNAME› info split-brain Liste les fichiers sont à l'état split-brain
volume heal ‹VOLNAME› statistics Affiche les statistiques
volume heal ‹VOLNAME› statistics heal-count Affiche le compteur de fichiers à réparer
volume heal ‹VOLNAME› statistics heal-count replica ‹HOSTNAME:BRICKNAME› Affiche le nombre de fichiers à réparer depuis un sous-volume réplica particulier auquel le brick ‹HOSTNAME:BRICKNAME› appartient
volume heal ‹VOLNAME› split-brain bigger-file ‹FILE› Répare le fichier qui est en état split-brain en choisissant le plus gros fichier dans le réplica
volume heal ‹VOLNAME› split-brain source-brick ‹HOSTNAME:BRICKNAME› Sélectionne ‹HOSTENAME:BRICKNAME› comme source pour tous les fichiers qui sont en split-brain dans ce réplica et les répare
volume heal ‹VOLNAME› split-brain source-brick ‹HOSTNAME:BRICKNAME› ‹FILE› Sélection le fichier à l'état split-brain comme source et complète la réparation

Autres commandes

get-state [‹daemon›] [odir ‹/path/to/output/dir/›] [file ‹filename›] Affiche l'état du service mentionné et stocke les données à l'emplacement spécifié
^
12 février 2015

htmlpdflatexmanmd




glusterd

glusterd

Service gluster

OPTIONS

-l ‹LOGFILE›, --log-file=‹LOGFILE› Fichier à utiliser pour les logs
-L ‹LOGLEVEL›, --log-level=‹LOGLEVEL› Sévérité des logs (TRACE, DEBUG, INFO, WARNING, ERROR et CRITICAL)
--debug Mode debug
-N, --no-daemon Ne lance pas en tâche de fond
^
12 février 2015

htmlpdflatexmanmd




glusterfs

glusterfs

Système de fichier clusterisé

OPTIONS

-f, --volfile=VOLUME-FILE Fichier à utiliser comme volume (défaut: /etc/glusterfs/glusterfs.vol)
-l, --log-file=LOGFILE Fichier à utiliser pour les logs
-L, --log-level=LOGLEVEL Sévérité des logs (TRACE, DEBUG, INFO, WARNING, ERROR et CRITICAL)
-s, --volfile-server=SERVER Serveur d'où vient le volume
--volfile-max-fetch-atempts=MAX-ATTEMPTS Nombre max de connexion à tenter auprès du serveur.
--acl Monte le système de fichier avec le support des ACL POSIX
--debug Mode debug
--enable-ino32=BOOL Utilise des inodes 32-bits pour les application qui ne supportent pas les inodes 64-bits
--fopen-keep-cache Ne purge pas le cache sur les fichiers ouverts
-N, --no-daemon Ne lance pas en tâche de fond
-p, --pid-file=PIDFILE Fichier pid à utiliser
--read-only Monte le système de fichier en lecture seul
--selinux Active le labeling SELinux dans les inodes
-S, --socket-file=SOCKFILE Fichier socket à utiliser pour les communications interprocess.
--volfile-id=KEY Clé du fichier volume à récupérer sur le serveur
--volfile-server-port=PORT Port du volfile
--volfile-server-transport=TRANSPORT type de transport pour le volume (défaut: tcp)
--volume-name=VOLUME-NAME Nom du volume à utiliser pour le point de montage
--worm Monte le système de fichier en mode 'worm'
--xlator-option=VOLUME-NAME.OPTION=VALUE Ajoute/remplace une options de traduction pour un volume avec la valeur spécifiée

Options fuse

--attribute-timeout=SECONDS timeout pour les inodes dans le module fuse (défaut: 1)
--background-qlen=N Longueur de file du module fuse (défaut: 64)
--congestion-threshold=N Seuil de congestion du module fuse (défaut: 48)
--direct-io-mode=BOOL Active/désactive le mode direct-io dans le module fuse.
dump-fuse=PATHR Dump le trafique fuse dans le chemin spécifié
--entry-timeout=SECONDS timeout dans le module fuse (défaut: 1)
--gid-timeout=SECONDS Définis le timeout de liste de groupe auxilaire pour le traducteur fuse. Défaut: 0
--negative-timeout=SECONDS Timeout négatif dans le module fuse (défaut: 0)
--volfile-check Active la vérification de fichier volume stricte

Exemples

Lancer un serveur avec un volume nommé foo:
glusterfsd -s localhost --volfile-id foo.server.media-disk-1 -p /var/lib/glusterd/vols/foo/run/server-media-disk-1.pid -S /tmp/‹uniqueid›.socket --brick-name /media/disk-1 -l /var/log/glusterfs/bricks/media-disk-1.log --brick-port 24009 --xlator-option foo-server.listen-port=24009
Monter un volume nommé foo sur le serveur bar avec le niveau de log DEBUG sur le point de montage /mnt/foo
glusterfs --log-level=DEBUG --volfile-id=foo --volfile-server=bar /mnt/foo
^
03 novembre 2011

htmlpdflatexmanmd




gpasswd

gpasswd

Administrer group et gshadow

   Permet d’administrer /etc/group et /etc/gshadow. Chaque groupe peut avoir des administrateurs, des membres et un mot de passe. Appelé par un administrateur de groupe.

OPTIONS

Excepté pour -A et -M, les options ne peuvent pas être combinées
-a, --add Ajoute l’utilisateur spécifié au groupe
-d, --delete Supprime l’utilisateur du groupe
-r, --remove-password Supprime le mot de passe du groupe. Seuls les membres du groupe seront autorisés à utiliser newgrp pour joindre le groupe
-R, --restrict Restreint l’accès au groupe. Seuls les membres du groupe seront autorisés à utiliser newgrp pour joindre le groupe.
-A, --administrators Définis les liste des administrateurs du groupe
-M, --members Définis la liste des membres du groupe.

   gpasswd utilise des variables de login.defs.
^
15 février 2012

htmlpdflatexmanmd




GPShell

GPShell

Interpréteur de script pour communiquer avec les cartes à puces compatibles GlobalPlatform

   Il utilise le plugin de connection PCSC pour accéder aux cartes à puces. Il peut établir un canal sécurisé avec une carte à puce, charger, instantier, supprimer et lister les applications sur les cartes supportées. Ces applications sont pratiquement toujors des applets JAVA.

Installer GPShell et GlobalPlatform

Ajouter dans /etc/apt/sources.list les entrées:
http://ppa.launchpad.net/k-o-/globalplatform/ubuntu
http://ppa.launchpad.net/k-o-/globalplatform/ubuntu
ou, pour compiler les sources:
aptitude install gcc libpcsclite-dev pkg-config zlib zlib1g-dev libcur14-openssl-dev make
wget http://heanet.dl.sourceforge.net/sourceforge/globalplatform/globalplatform-6.0.0.tar.gz
tar xfvz globalplatform-6.0.0.tar.gz
cd globalplatform-6.0.0
./configure —prefix=/usr
make
make install
cd ..
wget http://heanet.dl.sourceforge.net/sourceforge/globalplatform/gpshell-1.4.4.tar.gz
tar xfvz gpshell-1.4.4.tar.gz
cd gpshell-1.4.4
./configure —prefix=/usr
make
sudo make install
cd ..

Commandes

establish_context Établir le contexte, nécessaire avant d’établir une communication avec la carte.
card_connect -reader Connection à la carte dans le lecteur spécifié par son nom (-reader) ou son numéro (-readerNumber)
select -AID Sélectionner l’instance de l’applet
card_disconnect Déconnecter la carte
release_context Arrêter le contexte
mode_201 Sélectionne le mode OpenPlatform 2.0.1
mode_211 Sélectionne le mode globalPlatform 2.1.1
enable_trace Active le debug APDU
enable_timer Log le temps d’exécution d’une commande
open_sc -keyind x -keyver x -key xyz -mac_key xyz -enc_key xyz -kek_key xyz -security x -scp x -scpimpl x -keyDerivation x (mode_211) -scp et scpimpl ne sont pas nécessaires.
open_sc -keyind x -keyver x -mac_key xyz -enc_key xyz (mode_201)
Install -file appletFile -priv privilege -sdAID sdAID -AID AIDInPkg -pkgAID packageAID -instAID instanceAID -nvCodeLimit x -nvDataLimit x Installer une applet
install_for_load -pkgAID x -sdAID sdAID -nvCodeLimit x
load -file appletFile Charger une applet. A utiliser si la commande install ne fonctionne pas.
get_status -element e0 Liste les applets, packages et domaines de sécurité
get_status -element 20 Liste les packages
get_status -element 40 Liste les applets et les domaines de sécurité
get_status -element 80 Liste me gestionnaire de carte et les domaine fournisseur de sécurité
get_data -identifier identifier Retourne la donnée pour l’identifieur donné
put_sc_key -keyver 0 -newkeyver 2 -mac_key new_MAC_key -enc_key new_ENC_key -kek_key new_KEK_key -cur_kek current_KEK_key Ajouter un nouveau jeu de clé version 2
put_sc_key -keyver 1 -newkeyver 1 -mac_key new_MAC_key -enc_key new_ENC_key -kek_key new_KEK_key -cur_kek current_KEK_key Remplacer le jeu de clé version 1
put_dm_keys -keyver 0 -newkeyver 2 -file public_rsa_key_file -pass password -key new_receipt_generation_key Place les clés de gestion délégués en version 2 (mode_211)
put_dm_keys -keyver 0 -newkeyver 2 -file public_rsa_key_file -pass password -key new_receipt_generation_key -cur_kek current_KEK_key Place les clé de gestion délégués en version 2 (mode_201)
send_apdu -APDU x Envoyer un APDU
send_apdu -sc 0 -APDU x Envoyer un APDU sans canal sécurisé
send_apdu_nostop -APDU x Envoyer un APDU et ne stop pas en cas d’erreur

OPTIONS

-reader readerName Nom du lecteur de carte
-readerNumber x Numéro du lecteur de carte
-protocol x Protocole (0 : T=0 ; 1 : T=1)
-keyind x Index de clé
-keyver Version du jeu de clé
-newkeyver x Nouvelle version du jeu de clé
-key key Valeur de la clé en hexa
-mac_key key Clé MAC en hexa
-enc_key key Valeur de clé ENC en hexa
-kek_key key Valeur de clé KEK en hexa
-security x 0 : aucun, 1:MAC, 3:MAC+ENC
-scp x Protocol du canal sécurisé (1 SCP01, 2 SCP02)
-scpimpl x Implémentation du canal sécurisé (ne devrait pas être sopécifié implicitement)
-pass password Mot de passe pour le déchiffrement de la clé
-sc x mode canal sécurisé (0 off, 1 on)
-keyDerivation (’non’, ’visa2’, ’emvcps11’)
-AID aid ID de l’applet
-sdAID aid AID du domaine sécurisé
-pkgAID aid AID du Package
-instAID aid AID de l’instance
-nvCodeLimit x Limite de taille du code non-volatile
-nvDataLimit x Limite de taille de donnée non-volatile
-vDataLimit x Limite de taille de donnée volatile
-file file Nom du fichier
-instParam param Paramètre d’installation
-priv x Privilège (ex : 0x04 Default Selected)
-element x Type d’élément à indexer en hexa

        80 Card Manager / Card Issuer Security Domain only.
        40 Applications (and Security Domains only in GP211).
        20 Executable Load Files only.
        10 Executable Load Files and their Executable Modules only (Only GP211)

-identifier Identifieur pour le tag pour la commande get_data (en hexa, ex : 9F7F)
-APDU apdu APDU à envoyer en hexa (ex : 80CA00CF00)

Variables d'environnement

GLOBALPLATFORM_DEBUG Active le mode debug depuis la librairie GlobalPlatform
GLOBALPLATFORM_LOGFILE Définis le fichier dans lequel écrire les logs

Installer une applet java sur une carte cyberflex 64k


mode_201
enable_trace
establish_context
card_connect
select -AID a000000003000000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f
delete -AID A0000003230101
delete -AID A00000032301
delete -AID A00000000101
delete -AID A000000001
install_for_load -pkgAID A000000001 -nvCodeLimit 13500 -sdAID A000000003000000
load -file CardEdgeCflex.ijc
install_for_install -instParam 00 -priv 02 -AID A00000000101 -pkgAID A000000001 -instAID A00000000101 -nvDataLimit 12000
card_disconnect
release_context

Ensuite il reste à intialiser le code pin à "00000000":
opensc-tool -s 00:A4:04:00:06:A0:00:00:00:01:01 -s B0:2A:00:00:38:08:4D:75:73:63:6C:65:30:30:04:01:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:05:02:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:00:00:17:70:00:02:01
Utiliser la carte avec opensc:
pkcs15-init -EC -p pkcs15+onepin
^
18 octobre 2016

htmlpdflatexmanmd




grep

grep

Affiche les lignes qui contiennent une correspondance pour un motif

Options - contrôle de correspondance

-e PATTERN, --regexp=PATTERN Utilise PATTERN comme motif. Si cette option est utilisée plusieurs fois ou combinée avec -f, recherche tous les motifs donnés.
-f FILE, --file=FILE Obtient les patterns depuis le fichier, un par ligne. Si cette option est utilisée plusieurs fois ou combinée avec -e, recherche pour tous les patterns donnés. Un fichier vide ne contient aucun pattern, et ne matche rien.
-i, --ignore-case Ignore la casse.
-v, --invert-match Inverse le sens de match, pour selectionner des lignes non-matchant.
-w, --word-regexp Sélectionne uniquement les lignes contenant les matchs qui forment un mot entier. Le test est que la sous-chaîne matchant doit être soit au début de la ligne, ou précédé par un caractère non-word. Similairement, il est doit être soit à la fin de la ligne ou suivi par un caractère word. N'a pas d'effet avec -x
-x, --line-regexp Sélectionne seulement les matche qui correspondent exactement à la ligne entière.

Options - Contrôles de sortie généraux

-c, --count Supprime la sortie normale; Affiche un compteur de lignes correspondantes pour chaque fichier d'entrée. Avec -v, compte les lignes qui ne matchent pas.
--color[=WHEN], --colour[=WHEN] Mode couleur. Les couleurs sont définies par la variable d'environnement GREP_COLORS (défaut: ms=01;31:mc=01;31:sl=:cx=:fn=35:ln=32:bn=32:se=36)
-L, --files-without-match Supprime la sortie normale; affiche le nom de chaque fichier d'entrée dans lequel aucune sortie ne serait affichée.
-l, --files-with-matches Supprime la sortie normale; affiche le nom de chaque fichier d'entrée dans lequel un sortie aurait été affichée.
-m NUM, --max-count=NUM Stop la lecture d'un fichier après NUM lignes matchant.
-o, --only-matching Affiche seulement les parties matchants des lignes matchant.
-q, --quiet, --silent N'affiche rien sur stdout. Quitte avec un status 0 si un match est trouvé, même si une erreur a été détectée.
-s, --no-messages Supprime les messages d'erreur sur des fichiers non-existants ou illisibles.

Options - contrôle de préfixe de ligne

-b, --byte-offset Affiche l'offset dans le fichier d'entrée avant de sortir chaque ligne. si -o est spécifié, affiche l'offset de la partie matchant elle-même.
-H, --with-filename Affiche le nom de fichier pour chaque match. C'est le défaut quand il y a plus d'une fichier à rechercher.
-h, --no-filename Supprime l'ajoute du nom de fichier dans la sortie. C'est le défaut quand il n'y a qu'un fichier ou seulement l'entrée standard à rechercher
--label=LABEL Affiche l'entrée venant de stdin comme entrant depuis le fichier LABEL. Utile pour implémenter des outils comme zgrep (ex: gzip -cd foo.gz | grep --label=foo -H something)
-n, --line-number Préfixe chaque ligne de sortie avec le numéro de ligne dans son fichier d'entrée
-T, --initial-tab S'assure que le premier caractère du contenu de la ligne courante s'appuis sur une tabulation, pour que l'alignement des tabulation semblent normales. Utile avec les options qui préfixent leur sortie avec le contenu actuel.
-u, --unix-byte-offsets Reporte les offsets dans le style Unix.
-Z, --null Affiche un ASCII NUL au lieu du caractère qui suit normalement un nom de fichier.

Options - Contrôle de ligne de contexte

   Sans regarder comment ces options sont définies, grep n'affiche jamais une ligne donnée plus d'une fois. Si -o est spécifié, ces options n'ont pas d'effet et une alerte est donée.

-A NUM, --after-context=NUM Affiche NUM lignes supplémentaires après chaque ligne matchant
-B NUM, --before-context=NUM Affiche NUM lignes supplémentaires avant chaque ligne matchant
-C NUM, -NUM, --context=NUM Affiche NUM lignes avant et après chaque ligne matchant
--group-separator=STRING Avec -A, -B ou -C, affiche un séparateur entre les groupes de ligne
--no-group-separator Avec -A, -B ou -C, n'affiche pas de séparateur entre les groupes de ligne

   Notes sur la manière dont grep choisis le séparateur pour affiche les préfixes:

        - Les lignes matchant utilisent normalement ':' comme séparateur entre les préfixes et le contenu de la ligne courante
        - Les ligne non-matchant utilisent - à la place
        - Quand le context n'est pas spécifié, les lignes adjacentes dans l'entrée forment un groupe et sont affiche un après l'autre, alors qu'un séparateur apparaît entre les groupes non-adjacents
        - Le séparateur par défaut est --
        - Chaque groupe peut contenir de nombreuses lignes matchant quand elles sont suffisamment proches et peuvent être fusionnés en une simple zone contigüe.

Options - Sélection de fichier et de répertoire

-a, --text Traite un fichier binaire comme si c'était du texte.
--binary-files=TYPE Trait le fichier contenant des données binaire en assumant que le fichier est du type spécifié: binary, without-match, text.
-D ACTION, --devices=ACTION Si un fichier d'entrée est un périphérique, FIFO ou socket, utilise ACTION pour le traiter. Si ACTION est 'read', tous les périphériques sont lus comme si c'étaient des fichiers ordinaires. Si ACTION est 'skip', les périphérique, FIFO, et sockets sont ignorés silencieusement.
-d ACTION, --directories=ACTION Si un fichier d'entrée est un répertoire, utilise l'action pour le traiter. par défaut, ACTION est 'read', qui signifie que les répertoires sont lus comme si c'était des fichiers ordinaires. Si ACTION est 'skip', les répertoire sont ignorés silencieusement. 'recurse' lis tous les fichiers sous chaque répertoire, recursivement.
--exclude=GLOB Saute les fichiers de la ligne de commande avec un suffix de nom qui matche le glob.
--exclude-from=FILE Saute les fichiers dont les noms matchent un des patterns lus depuis le fichier spécifié.
--exclude-dir=GLOB Saute les répertoires de la ligne de commande avec un suffix qui matche le glob.
-I Traite un fichier binaire comme s'il ne contenait pas de données correspondantes. (équivalent à --binary-files=without-match)
--include=GLOB Ne recherche que les fichiers dont les noms matchent le glob.
-r, --recursive Pour chaque opérande répertoire, lit et traite tous les fichiers dans ce répertoire, récursivement. identique à --directories=recurse
-R, --dereference-recursive Pour chaque opérande répertoire, lit et traite tous les fichiers dans ce répertoire, en suivant tous les liens symboliques.

Autres options

--line-buffered Utilise le tampon de ligne sur la sortie. Peut réduire les performances
-U, --binary Traite les fichiers en binaire.
-z, --null-data Traite les données d'entrée et de sortie comme séquence de lignes, chacune terminée par un ASCII NUL au lieu d'un newline.

Variables d'environnement

LC_ALL Spécifie la locale
LC_COLLATE Spécifie la locale pour la catégorie LC_COLLATE
LANG Spécifie la locale
LC_TYPE Spécifie la locale pour la catégorie LC_CTYPE
LC_MESSAGES Spécifie la locale pour la catégorie LC_MESSAGES
LANGUAGE Contient une liste séparée par ',' de langages qui remplacent les variables LC_ALL, LC_XXX et LANG
GREP_COLORS Spécifie les couleurs et autres attributs utilisés pour colorer la sortie:

        sl= Lignes sélectionnées
        cx= Lignes de context
        rv booléen inversant la signification de sl et cx
        mt=01;31 Texte non-vide dans un ligne matchant.
        ms=01;31 Texte non vide matchant dans une ligne matchant
        mc=01;31 texte non-vide matchant dans une ligne de contexte
        fn=35 Sous-chaîne our les noms de fichier préfixant une ligne
        ln=32 Sous-chaîne pour les numéros de ligne préfixant une ligne
        bn=32 Offset préfixant une ligne
        se=36 Séparateur inséré entre les champs, entre les lignes de contexte et entre les groupes de lignes adjacentes
        ne Booléen qui empêche d'effacer la fin d'une ligne avec Erase in Line (EL) à droite chaque fois qu'un élément colorisé prend fin.

POSIXLY_CORRECT grep se conforme à POSIX
_N_GNU_nonoption_argv_flags_ Où N est l'ID de processus grep. Si le I-ième caractère de cette variable est 1, ne pas considérer la I-ème opérande de grep comme option. Un shell peut définir cette variable pour chaque commande qu'il lance, en spécifiant quels opérandes sont le résultat d'une expansion de nom de fichier. Uniquement avec POSIXLY_CORRECT

Codes de sortie

   Normalement, le code de sortie est 0 si une ligne est sélectionnée, 1 si aucune ligne n'est sélectionnée, et 2 si une erreur se produit.

Programmes grep

   grep recherche dans les fichiers nommés en entrée à la recherche de lignes contenant un match. Par défaut, grep affiche les lignes matchants. Un fichier nommé '-' signifie l'entrée standard. Si aucune entrée n'est spécifiée, grep recherche le répertoire courant. Si une options spécifie la récursion, cependant, grep recherche l'entrée standard. Il y a 4 variantes majeurs de grep, contrôlés par les options suivantes:

-G, --basic-regexp Interprète le pattern comme expression régulière basique. c'est le mode pas défaut
-E, --extended-regexp Interprète le pattern comme expression régulière étendue.
-F, --fixed-string Interprète le pattern comme une liste de chaîne fixes au lieu d'expressions régulières, séparér par des newline, un d'entre eux doit matcher.
-P, --perl-regexp Interprète le pattern comme expression régulière compatible perl.

Expressions régulières

   Une expression régulière est un pattern qui décrit un jeu de chaînes. Les expressions régulières sont construites analoguement aux expressions arithmétiques, en utilisant divers opérateurs pour combiner des expressions plus petites. Grep comprend 3 types d'expressions régulière: basique, étendue, et perl. La suite décrit les expressions régulières étendue.

Structure fondamentale

. matche un simple caractère
? L'élément précédent est optionnel et est matché une fois au plus
L'élément précédent est matché 0 ou plusieurs fois
+ L'élément précédent est matché 1 ou plusieurs fois
{N} L'élément précédent est matché N fois
{N,} L'élément précédent est matché au moins N fois
{,M} L'élément précédent est matché au plus N fois
{N,M} L'élément précédent est matché au moins N fois et au plus M fois.

Classes de caractère et expressions entre crochet

[:alnum:] Caractères alphanumériques =[0-9A-Za-z]
[:alpha:] Caractère alphabétiques [A-Za-z]
[:blank:] Caractères blancs: espace et tabulation
[:cntrl:] Caractères de contrôle
[:digit:] Chiffres [0-9]
[:graph:] Caractères graphiques: [:alnum:] et [:punct:]
[:print:] Caractères imprimables. [:alnum:], [:punct:], et espace
[:punct:] caractères de ponctuation ‘! " # $ % & ' ( ) * + , - . / : ; ‹ = › ? @ [ \ ] ^ _ ` { | } ~’
[:space:] Caractères espace
[:lower:] caractères minuscules [a-z]
[:upper:] Caractères majuscules [A-Z]
[:xdigit:] Chiffres hexadécimaux [0-9A-Fa-f]

   La plupart des méta-caractères perdent leur signification spéciale dans les expressions entre crochet.

] Termine une expression crochet si ce n'est pas le premier élément de la liste
[. Représente le symbole d'ouverture de regroupement.
.] Représente le symbole de fermeture de regroupement
[= Représente l'ouvertuse de classe équivalente
=] Représente la fermeture de classe équivalente
[: Représente le symbole d'ouverture de classe de caractère
:] Représente le symbole de fermueture de classe de caractère
- Représente la plage si ce n'est pas le premier ou le dernier caractère
^ Représente les caractères qui ne sont pas dans la liste.

Le caractère \\ et des expressions spéciales

\b Matche la chaîne vide au bord d'un mot
\B Matche la chaîne vide qui n'est pas au bord d'un mot
\‹ Matche la chaîne vide au début d'un mot
\› Matche la chaîne vide à la fin d'un mot
\w Matche un constituant d'un mot, synomyme de [_[:alnum:]]
\W Match un non-constituant de mot, synomyme de [^_[:alnum:]]
\s Matche un espace blanc, synomyme de [[:space:]]
\S Matche un non-espace, synonyme de [^[:space:]]

ancre

   ^ et $ sont des méta-caractères qui matchent respectivement la chaîne vide au début de ligne et la fin de ligne.

Références et sous-expressions

   Le back-reférence, \N, où N est un simple chiffre, matche la sous-chaîne précédemment matchée par la N-ième sous-expression entre parenthèses de l'expression régulière. Par exemple, (a)\1 matche 'aa'.

Expressions régulières basiques et étendues

   Dans les expressions régulières basiques, les méta-caractères '?', '+', ‘{’, ‘|’, ‘(’, et ‘)’ perdent leur signification spéciales, utiliser leur versions échappées \.

   egrep ne supporte pas le méta-caractère { et certaines implémentations supportent \{, les scripts portables doivent éviter { dans les pattern grep -E, et utiliser [{].

Exemples

Lister simplement les noms des fichiers qui matchent
grep -l 'main' *.c
Rechercher récursivement
grep -r 'hello' /home/gigi
Rechercher seulement dans les fichiers C
find /home/gigi -name '*.c' -print0 | xargs -0r grep -H 'hello'
Similairement
grep -rH --include='*.c' 'hello' /home/gigi
Recherche toutes les lignes matchant --cut here--
grep -e '--cut here--' *
Recherche seulement les instances de hello qui sont des mots entiers:
grep -w 'hello' *
Et ne matche pas Othello. Pour plus de contrôle, utilise \‹ et \›
grep 'hello\›' *
Afficher le contexte autour des lignes qui matchent
grep -C 2 'hello' *
Forcer grep à afficher le nom d'un fichier
grep 'eli' /etc/passwd /dev/null
ou encore
grep -H 'eli' /etc/passwd
Rechercher sur l'entrée standard et dans les fichiers
cat /etc/passwd | grep 'alain' - /etc/motd
Comment exprimer des palindromes en expressions régulières
grep -w -e '\(.\)\(.\).\2\1' file
^
29 octobre 2011

htmlpdflatexmanmd




groupadd

groupadd

Permet de créer des groupes

   Permet de créer des groupes en utilisant les valeurs spécifiées en ligne de commande, plus les valeurs par défaut du système. Il est généralement conseillé d'utiliser des noms de groupe qui respectent l'expression régulière suivante: [a-z_][a-z0-9_-]*[$]?. Sous debian, la seule contrainte est que les noms des groupes ne doivent pas commencer avec un '-', ni un ':' ou un espace blanc. Les noms des groupes sont limités à 32 caractères.

OPTIONS

-f, --force Force la commande à quitter avec un code de succès si le groupe spécifié existe déjà. utilisé avec -g, si le GID existe déjà, un autre GID est utilisé.
-g, --gid GID du groupe à créer. Doit être unique sauf si -o est spécifié
-K, --key clé=valeur Surcharge les valeur par défaut dans /etc/login.defs. Peut être spécifié plusieurs fois.
-o, --non-unique permet d'ajouter un groupe avec un GID non-unique.
-p, --password mot de passe chiffré, comme renvoyé par crypt(3). Par défaut, désactive le mot de passe.
-r, --system Créé un groupe système.

Configuration

Les variables suivantes de /etc/login.defs sont utilisées:
GID_MAX
GID_MIN
MAX_MEMBERS_PER_GROUP
SYS_GID_MAX
SYS_GID_MIN

Valeurs de retour

0 succès
2 erreur de syntaxe
3 paramètre non valable pour l’option
4 GID déjà utilisé
9 nom de groupe déjà utilisé
10 impossible de mettre à jour le fichier des groupes
^
29 octobre 2011

htmlpdflatexmanmd




groupdel

groupdel

Permet de supprimer un groupe

   Il n'est pas possible de supprimer un groupe primaire d'un utilisateur existant.

Configuration

Les variables suivantes dans /etc/login.defs sont utilisées:
MAX_MEMBERS_PER_GROUP

Valeurs de retour

0 succès
2 erreur de syntaxe
6 le groupe n'existe pas
8 impossible de supprimer le groupe primaire d'un utilisateur existant
10 impossible de mettre à jour le fichier des groupes
^
29 octobre 2011

htmlpdflatexmanmd




groupmod

groupmod

Permet de modifier un groupe existant

OPTIONS

-g, --gid Change le GID du groupe. Les fichiers appartenant à l'ancien GID doivent être changés manuellement.
-n, --new-name Change le nom du groupe
-o, --non-unique avec -g, permet de spécifier un GID non-unique.
-p, --password mot de passe chiffré, comme renvoyé par crypt(3)

Configuration

Les variables suivantes dans /etc/login.defs sont utilisées:
MAX_MEMBERS_PER_GROUP

Valeurs de retour

0 succès
2 erreur de syntaxe
3 paramètre non valable pour l'option
4 GID déjà utilisé
6 le groupe n'existe pas
9 nom de groupe déjà utilisé
10 impossible de mettre à jour le fichier des groupes
^
13 juillet 2010

htmlpdflatexmanmd




groups

groups

Affiche les noms des groupes d'un utilisateur

   groups affiche les noms des groupes primaire et supplémentaires pour chaque utilisateur donné, ou du processus courant si aucun nom n'est spécifié. est identique à id -Gn

^
03 novembre 2011

htmlpdflatexmanmd




grpck

grpck

Vérifier l’intégrité des informations sur les groupes systèmes

   Toutes les entrées dans /etc/group et /etc/gshadow sont vérifiées afin de s’assurer qu’elles ont le bon format et qu’elles contiennent des données valides. Les vérifications effectuées sont :

        - nombre correct de champs
        - unicité et validité des noms des groupes
        - GID valide (/etc/group uniquement)
        - liste valide de membres et administrateurs
        - une entrée dans /etc/group correspondant à une entrée dans /etc/gshadow

   La vérification du nombre de champs et de l’unicité du nom des groupes est fatale, et il sera demandé à l’utilisateur de supprimer la ligne. Si l’utilisateur refuse de supprimer la ligne, les autres vérifications ne sont pas effectuées.

OPTIONS

-r Mode lecture seule.
-s Trie les entrées par GID.

   Par défaut, grpck vérifie group et shadow. Il est possible de choisir l’un ou l’autre avec les paramètres group et shadow

  gpasswd utilise des variables dans login.defs

Valeurs de retour

0 succès
1 erreur de syntaxe
2 entrée de groupe ou plus est incorrecte
3 impossible d’ouvrir les fichiers group
4 impossible de verrouiller les fichiers group
5 impossible de mettre à jour les fichiers group
^
12 mars 2016

htmlpdflatexmanmd




grub-bios-setup

grub-bios-setup

Définir un périphérique de boot en utilisant GRUB

   Définis les images à booter depuis le périphérique spécifié. Ce programme est généralement invoqué par grub-install. Le périphérique donné doit être un périphérique OS (ex: /dev/sda)

OPTIONS

-a, --allow-floppy Rend le périphérique bootable également comme une disquette.
-b, --boot-image=FILE Utilise le fichier comme image de boot. Défaut: boot.ing
-c, --core-image=FILE Utilise le fichier comme image core. Défaut: core.img
-d, --directory=DIR Répertoire contenant les fichiers GRUB. Défaut=/boot/grub
-f, --force Install même si des problèmes sont détectés
-m, --device-map=FILE Utilise le fichier comme map de périphérique. Défaut: /boot/grub/device.map
--no-rs-codes N'applique pas de codes reed-solomon en embarquant core.img. Uniquement pour les cibles BIOS x86
-s, --skip-fs-probe Ne recherche pas de système de fichier dans le périphérique donné
^
12 mars 2016

htmlpdflatexmanmd




grub-editenv

grub-editenv

Éditer le block d'environnement de GRUB

OPTIONS

create Créé un fichier block vide
list Liste les variables courantes
set [NAME=VALUE ...] Définis des variables
unset [NAME=VALUE ...] Supprime des variables

Exemples

Ajouter la langue:
grub-editenv -v - set lang=fr
^
12 mars 2016

htmlpdflatexmanmd




grub-file

grub-file

Vérifie si le fichier est du type spécifié

OPTIONS

--is-i386-xen-pae-domu Vérifier si le fichier peut être booté comme kernel invité non-privilégié Xen PAE i386
--is-x86_64-xen-domu Vérifier si le fichier peut être booté comme kernel invité non-privilégié Xen x86_64
--is-x86-xen-dom0 Vérifie si le fichier peut être utilisé comme kernel invité privilégié Xen x86_64
--is-x86-multiboot Vérifie si le fichier peut être utilisé comme kernel multiboot x86_64
--is-x86-multiboot2 Vérifie si le fichier peut être utilisé comme kernel multiboot2
--is-arm-linux Vérifie si le fichier est un Linux ARM
--is-arm64-linux Vérifie si le fichier est un Linux ARM64
--is-ia64-linux Vérifie si le fichier est un Linux IA64
--is-mips-linux Vérifie si le fichier est un Linux MIPS
--is-mipsel-linux Vérifie si le fichier est un Linux MIPSEL
--is-sparc64-linux Vérifie si le fichier est un Linux SPARC64
--is-powerpc-linux Vérifie si le fichier est un Linux POWERPC
--is-x86-linux Vérifie si le fichier est un Linux
--is-x86-linux32 Vérifie si le fichier est un Linux x86 supportant le mode 32bits
--is-x86-kfreebsd Vérifie si le fichier est ur kFreeBSD x86
--is-i386-kfreebsd Vérifie si le fichier est ur kFreeBSD i386
--is-x86_64-kfreebsd Vérifie si le fichier est ur kFreeBSD x86_64
--is-x86-knetbsd Vérifie si le fichier est ur kNetBSD x86
--is-i386-knetbsd Vérifie si le fichier est ur kNetBSD i386
--is-x86_64-knetbsd Vérifie si le fichier est ur kNetBSD x86_64
--is-i386-efi Vérifie si le fichier est un fichier EFI i386
--is-x86_64-efi Vérifie si le fichier est un fichier EFI x86_64
--is-ia64-efi Vérifie si le fichier est un fichier EFI ia64
--is-arm64-efi Vérifie si le fichier est un fichier EFI ARM64
--is-arm-efi Vérifie si le fichier est un fichier EFI ARM
--is-hibernated-hiberfil Vérifie si le fichier est hiberfil.sys à l'état hibernated
--is-x86_64-xnu Vérifie si le fichier est un XNU x86_64
--is-i386-xnu Vérifie si le fichier est un XNU i386
--is-xnu-hibr Vérifie si le fichier est un XNU
--is-x86-bios-bootsector Vérifie si le fichier est un secteur de boot BIOS
^
12 mars 2016

htmlpdflatexmanmd




grub-fstest

grub-fstest

Outil de débuggage pour les pilotes de système de fichier GRUB

Commandes

blocklist FILE Affiche la liste de blocks du fichier
cat FILE Copie le fichier sur la sortie standard
cmp FILE LOCAL Compare le fichier avec le fichier local
cp FILE LOCAL Copie le fichier dans le fichier local
crc FILE Récupérer le checksum crc32 du fichier
hex FILE Affiche le contenu du fichier en hexa
ls PATH Liste les fichiers dans le chemin
xnu_uuid DEVICE Calcule l'UUID XNU du périphérique
-c, --diskcount=NUM Spécifie le nombre de fichiers d'entrées
-C, --crypto Monte les périphériques crypto
-d, --debug=STRING Définis la variable d'environnement debug
-K, --zfs-key=FILE|prompt Charge la clé crypto zfs
-n, --length=NUM Gère N octets dans le fichier de sortie
-r, --root=DEVICE_NAME Définis le périphérique root
-s, --skip=NUM Saute N octets de fichier de sortie
-u, --uncompress Décompresse les données
-v, --verbose mode verbeux
^
12 mars 2016

htmlpdflatexmanmd




grub-glue-efi

grub-glue-efi

Traite les images EFI ia32 et amd 64 et les traite en accord avec le format Apple

OPTIONS

-3, --input32=FILE Définis le fichier d'entrée pour la partie 32-bits
-6, --input64=FILE Définis le fichier d'entrée pour la partie 64-bits
-o, --output=FILE Définis le fichier de sortie. Défaut: STDOUT
^
12 mars 2016

htmlpdflatexmanmd




grub-install

grub-install

Installer grub

OPTIONS

--compress[=no,xz,gz,lzo] compresse les fichiers GRUB
-d, --directory=DIR Utiliser les images et les modules sous DIR. Défaut: /usr/lib/grub/‹platform›
--fonts=FONTS Installe les FONTS. défaut: unicode
--install-modules=MODULES Installe seulement les modules spécifiés et leur dépendances. Défaut: all
-k, --pubkey=FILE Embarque le fichier comme clé publique pour la vérification de la signature
--locale-directory=DIR Utilise les traductions sous le répertoire. Défaut: /usr/share/locale
--locales=LOCALES Installe seulement les locales. Défaut=all
--modules=MODULES Pré-charge les modules spécifiés
--themes=THEMES Installe les thèmes. Défaut: starfield
-v, --verbose mode verbeux
--allow-floppy Rend le disque bootable comme une disquette
--boot-directory=DIR Installe les images GRUB sous le répertoire DIR/grub.
--bootloader-id=ID L'ID du bootloader. Cette options est seulement disponible sous EFI et Macs
--core-compress=xz|none|auto Choisis la compression à utiliser pour l'image core
--disk-module=MODULE module disque à utiliser (biosdisk ou native). Cette option est seulement disponible sur les cible BIOS
--efi-directory=DIR Utilise DIR comme partition système EFI
--force Install même si des problèmes sont détectés
--force-extra-removable Force l'installation sur média amovible. Cette option est seulement disponible sur EFI
--force-file-id Utilise l'identifiant de fichier même si UUID est disponible
--label-bgcolor=COLOR Utilise la couleur pour le label de fond
--label-color=COLOR Utilise la couleur pour le label
--label-font=FILE utilise la font pour le label
--macppc-directory=DIR Utilise le répertoire spécifié pour l'installation MAC PPC
--no-bootsector n'installe pas le secteur de boot.
--no-nvram ne met pas à jours les variables NVRAM boot-device/Boot*. Seulement disponible sur les cibles EFI et IEEE1275.
--no-rs-codes N'applique pas de codes reed-solomon en embarquant core.img. Cette option est seulement disponible sur les cibles BIOS x86
--no-uefi-secure-boot N'installe pas d'image utilisable avec UEFI, même si le système est démarré en l'utilisant. Uniquement disponible sur EFI
--product-version=STRING Utilise la chaîne comme version
--recheck Supprime la map de périphérique si elle existe
--removable Le périphérique d'installation est amovible. Uniquement disponible sur EFI
-s, --skip-fs-probe Ne sonde pas les système de fichiers dans le périphérique spécifié
--target=TARGET Install GRUB pour le plateforme spécifiée. Défaut: i386-pc
--uefi-secure-boot Installe une image utilisabe avec UEFI. Cette option est seulement disponible sur EFI et si grub-efi-amd64-signed est installé

   Le périphérique d'installation doit être le nom d'un périphérique. grub-install copie les images GRUB dans boot/grub. Dans certaines plateformes, il peut également installer GRUB sur le secteur de boot.
^
12 mars 2016

htmlpdflatexmanmd




grub-kbdcomp

grub-kbdcomp

Génère un fichier de couche clavier au format keymaps(5) dans un format qui peut être utilisé par la commande keymap de GRUB

OPTIONS

-o, --output=FILE Sauve la sortie dans le fichier
^
12 mars 2016

htmlpdflatexmanmd




grub-macbless

grub-macbless

bénir un fichier/répertoire mac

OPTIONS

-p, --ppc Pour les macs basés sur PPC
-v, --verbose mode verbeux
-x, --x86 Pour les macs basés sur x86
^
12 mars 2016

htmlpdflatexmanmd




grub-menulst2cfg

grub-menulst2cfg

transforme un fichier menu.lst en grub.cfg

   Cette commande n'a pas d'option

^
12 mars 2016

htmlpdflatexmanmd




grub-mkconfig

grub-mkconfig

Génère un fichier de configuration GRUB

OPTIONS

-o, --output=FILE Définis le fichier de sortie. Défaut: STDOUT
^
12 mars 2016

htmlpdflatexmanmd




grub-mkdevicemap

grub-mkdevicemap

Créer un fichier de mappage de périphérique

OPTIONS

-n, --no-floppy Ne recherche pas de lecteur de disquette
-s, --probe-second-floppy Recherche le second lecteur de disquette
-m, --device-map=FILE Utilise le fichier comme map. Défaut: /boot/grub/device.map
^
12 mars 2016

htmlpdflatexmanmd




grub-mkfont

grub-mkfont

Créé des fichiers de font GRUB au format PF2

OPTIONS

-a, --force-autohint Force l'autohint
-b, --bold Convertit la font en gras
-c, --asce=NUM set font ascent
-d, --desc=NUM et font descent
-i, --index=NUM Select face index
-n, --name=NAME Définis le nom de la famille de font
--no-bitmap Ignore les bitmaps strikes au chargement
--no-hinting Désactive le hinting
-o, --output=FILE Sauve la sortie dans le fichier
-r, --range=FROM-TO[,FROM-TO] Plage de font
-s, --size=SIZE Taille de font
^
12 mars 2016

htmlpdflatexmanmd




grub-mkimage

grub-mkimage

Créer une image bootable GRUB

OPTIONS

-c, --config=FILE Fichier embarqué comme première configuration
-C, --compression=(xz|none|auto) Choisis la compression à utiliser pour le core
-d, --directory=DIR Utilise les images et les modules sous DIR. Défaut: /usr/lib/grub/‹platform›
-k, --pubkey=FILE Embarque la clé publique pour la vérifitation de signature
-m Embarque le fichier comme image memdisk. Implique -p (memdisk)/boot/grub
-n, --note Ajoute le segment note pour CHRP IEEE1275
-o, --output=FILE Sort l'image générée dans le fichier. Défaut: stdout
-O, --format=FORMAT Génère une image au format spécifié (i386-coreboot, i386-multiboot, i386-pc, i386-pc-pxe, i386-pc-eltorito, i386-efi, i386-ieee1275, i386-qemu, x86_64-efi, i386-xen, x86_64-xen, mipsel-yeeloong-flash, mipsel-fuloong2f-flash, mipsel-loongson-elf, powerpc-ieee1275, sparc64-ieee1275-raw, sparc64-ieee1275-cdcore, sparc64-ieee1275-aout, ia64-efi, mips-arc, mipsel-arc, mipsel-qemu_mips-elf, mips-qemu_mips-flash, mipsel-qemu_mips-flash, mips-qemu_mips-elf, arm-uboot, arm-efi, arm64-efi
-p, --prefix=DIR Définis le préfixe de répertoire. Défaut: /boot/grub
^
12 mars 2016

htmlpdflatexmanmd




grub-mklayout

grub-mklayout

Génère un fichier de couche clavier GRUB au format keymaps(5) dans un format qui peut être utilisé par la commande keymap

OPTIONS

-o, --output=FILE Sauve la sortie dans le fichier
^
12 mars 2016

htmlpdflatexmanmd




grub-mknetdir

grub-mknetdir

Prépare un répertoire de boot réseau GRUB

OPTIONS

--compress[=no,xz,gz,lzo] Compresse les fichiers
-d, --directory=DIR Utilise les images et les modules sous DIR. Défaut: /usr/lib/grub/‹platform›
--fonts=FONTS Installe les FONTS. défaut: unicode
--install-modules=MODULES Installe seulement les modules spécifié. Défaut: all
-k, --pubkey=FILE Embarque la clé publique pour la vérification de la signature
--locale-directory=DIR Utilise les locales sous DIR. Défaut: /usr/share/locale
--locales=LOCALES Installe seulement les locales spécifiées. Défaut: all
--modules=MODULES Précharge les modules spécifiés
--themes=THEMES Installe les thèmes spécifiés. Défaut: starfield
--core-compress=xz|none|auto Choix de la compression de l'image core
--net-directory=DIR Répertoire root du serveur TFTP
--subdir=DIR Sous-réseau relatif d'un serveur réseau
^
12 mars 2016

htmlpdflatexmanmd




grub-mkpasswd-pbkdf2

grub-mkpasswd-pbkdf2

Génère un mot de passe hashé pour GRUB

OPTIONS

-c, --iteration-count=NUM Nombre d'itération de PBKDF2
-l, --buflen=NUM Longueur du hash générés
-s, --salt=NUM Longueur du salt
^
12 mars 2016

htmlpdflatexmanmd




grub-mkrelpath

grub-mkrelpath

Créé un chemin système relatif a son root

   Transforme un nom de fichier système en nom GRUB

^
12 mars 2016

htmlpdflatexmanmd




grub-mkrescue

grub-mkrescue

Créer une image de récupération GRUB

   Génère une image bootable pour CD/USB/disquette. Les arguments autre que les options sont passé à xorriso.

OPTIONS

--compress[=no,xz,gz,lzo] Compresse les fichiers
-d, --directory=DIR Utilise les images et les modules sous DIR. Défaut: /usr/lib/grub/‹platform›
--fonts=FONTS Installe les FONTS. défaut: unicode
--install-modules=MODULES Installe seulement les modules spécifié. Défaut: all
-k, --pubkey=FILE Embarque la clé publique pour la vérification de la signature
--locale-directory=DIR Utilise les locales sous DIR. Défaut: /usr/share/locale
--locales=LOCALES Installe seulement les locales spécifiées. Défaut: all
--modules=MODULES Précharge les modules spécifiés
--themes=THEMES Installe les thèmes spécifiés. Défaut: starfield
--arcs-boot Active ARCS.
--core-compress=xz|none|auto Choix de la compression de l'image core
--label-bgcolor=COLOR Utilise la couleur comme fond de label
--label-color=COLOR Utilise la couleur pour les labels
--label-font=FILE Utilise la font spécifiée pour les labels
-o, --output=FILE Sauve la sortie dans le fichier
--product-name=STRING Utilise la chaîne spécifiée comme nom de produit
--product-version=STRING Utilise la chaîne spécifiée comme version de produit
--rom-directory=DIR Sauve les images ROM dans le répertoire
--sparc-boot Active le boot sparc
--xorriso=FILE Utilise le fichier comme xorriso
^
12 mars 2016

htmlpdflatexmanmd




grub-mkstandalone

grub-mkstandalone

Créé une image GRUB basé sur memdisk

OPTIONS

--compress[=no,xz,gz,lzo] Compresse les fichiers
-d, --directory=DIR Utilise les images et les modules sous DIR. Défaut: /usr/lib/grub/‹platform›
--fonts=FONTS Installe les FONTS. défaut: unicode
--install-modules=MODULES Installe seulement les modules spécifié. Défaut: all
-k, --pubkey=FILE Embarque la clé publique pour la vérification de la signature
--locale-directory=DIR Utilise les locales sous DIR. Défaut: /usr/share/locale
--locales=LOCALES Installe seulement les locales spécifiées. Défaut: all
--modules=MODULES Précharge les modules spécifiés
--themes=THEMES Installe les thèmes spécifiés. Défaut: starfield
--core-compress=xz|none|auto Choix de la compression de l'image core
-o, --output=FILE Sauve la sortie dans le fichier
-O, --format=FORMAT Génère une image au format spécifié (i386-coreboot, i386-multiboot, i386-pc, i386-pc-pxe, i386-pc-eltorito, i386-efi, i386-ieee1275, i386-qemu, x86_64-efi, i386-xen, x86_64-xen, mipsel-yeeloong-flash, mipsel-fuloong2f-flash, mipsel-loongson-elf, powerpc-ieee1275, sparc64-ieee1275-raw, sparc64-ieee1275-cdcore, sparc64-ieee1275-aout, ia64-efi, mips-arc, mipsel-arc, mipsel-qemu_mips-elf, mips-qemu_mips-flash, mipsel-qemu_mips-flash, mips-qemu_mips-elf, arm-uboot, arm-efi, arm64-efi
^
12 mars 2016

htmlpdflatexmanmd




grub-mount

grub-mount

Exporter des systèmes de fichier GRUB avec FUSE

OPTIONS

-C, --crypto Monter des périphériques crypto
-d, --debug=STRING Définir la variable d'environnement debug
-K, --zfs-key=FILE|prompt Charge la clé crypto zfs
-r, --root=DEVICE_NAME Définis le périphérique root
^
12 mars 2016

htmlpdflatexmanmd




grub-probe

grub-probe

Affiche des informations de périphérique pour GRUB

OPTIONS

-d, --device L'argument donné est un périphérique système, pas un chemin
-m, --device-map=FILE Utilise FILE comme map de périphérique (défaut: /boot/grub/device.map)
-t, --target=TARGET Affiche la cible disponible (abstraction, arc_hints, baremetal_hints, bios_hints, compatibility_hint, cryptodisk_uuid, device, disk, drive, efi_hints, fs, fs_label, fs_uuid, gpt_parttype, hints_string, ieee1275_hints, msdos_parttype, partmap, zero_check) défaut: fs
-v, --verbose mode verbeux
^
12 mars 2016

htmlpdflatexmanmd




grub-reboot

grub-reboot

Définis l'entrée de boot par défaut pour le prochain boot uniquement.

OPTIONS

--boot-directory=DIR Utilise le répertoire DIR/grub au lieu de /boot/grub.

   L'entrée de menu spécifiée est un nombre, un titre, ou un identifiant.
^
12 mars 2016

htmlpdflatexmanmd




grub-render-label

grub-render-label

Génère un .disk_label pour Mac

OPTIONS

-b, --bgcolor=COLOR Utilise la couleur pour le fond
-c, --color=COLOR Utilise la couleur pour le texte
-f, --font=FILE Utilise la font (PF2)
-i, --input=FILE Lis le texte depuis le fichier
-o, --output=FILE Définis le fichier de sortie. Défaut: STDOUT
-t, --text=STRING Définis le label
^
12 mars 2016

htmlpdflatexmanmd




grub-script-check

grub-script-check

Vérifie la syntaxe de grub.cfg

OPTIONS

-v, --verbose Affiche des messages d'informations
^
12 mars 2016

htmlpdflatexmanmd




grub-set-default

grub-set-default

Définis l'entrée de boot par défaut pour GRUB. Nécessite de définir GRUB_DEFAULT=saved dans /etc/default/grub

OPTIONS

--boot-directory=DIR Utilise DIR/grub au lieu de /boot/grub

   L'entrée de menu spécifiée est un nombre, un titre, ou un identifiant.
^
12 mars 2016

htmlpdflatexmanmd




grub-syslinux2cfg

grub-syslinux2cfg

Transforme une configuration syslinux en grub.cfg

OPTIONS

-c, --cwd=DIR Répertoire courant de syslinux. Défaut: le répertoire parent du fichie d'entrée
-i, --isolinux assume que l'entrée est un fichier de configuration isolinux
-o, --output=FILE Écris la sortie dans le fichier. Défaut: stdout
-p, --pxelinux Assume que le fichier d'entrée est un fichier de configuration pxelinux
-r, --root=DIR Répertoire root du disque syslinux. Défaut: /
-s, --syslinux Assume que le fichier d'entrée est un fichier de configuration syslinux
-t, --target-root=DIR Répertoire root qui sera vu à l'exécution. Défaut: /
-T, --target-cwd=DIR Répertoire courant du syslinux tel que vu à l'exécution. Défaut: le répertoire parent du fichie d'entrée
^
12 mars 2016

htmlpdflatexmanmd




grub2

grub2

multiboot bootloader

   Brièvement, un boot loader est le premier logiciel qui est lancé au démarrage de l'ordinateur. Il est responsable du chargement et de transférer le contrôle à un kernel. Le kernel, en retour, initialise le reste du système d'exploitation.

   GRUB est un boot loader très puissant, qui peut charger une grande variété de systèmes d'exploitation. GRUB est conçu pour adresser la complexité du boot d'un ordinateur personnel.

   Une des fonctionnalité les plus importantes est sa flexibilité; GRUB comprend les systèmes de fichier et les formats exécutable de kernel, ce qui permet de charger un kernel sans enregistrer sa position physique sur le disque.

   En bootant avec GRUB, vous pouvez utiliser soit une interface en ligne de commande, ou une interface. En utilisant la ligne de commande, il suffit de spécifier l'emplacement du dique et le nom de fichier du kernel manuellement. Dans l'interface par menu, il suffit de sélectionner un OS en utilisant les touches. Le menu est basé sur un fichier de configuration qui peut être préparé avant. Il est possible de basculer d'un mode à l'autre, et même éditer les entrées du menu avant de les utiliser.

Fonctionnalités

- Reconnaissante de plusieurs formats d'exécutable
- Supporte de nombreuses variantes de a.out, plus ELF. Les tables de symbole sont également chargés.
- Support de kernels non-multiboot
- Supporte de nombreux kernels 32bits qui ne sont pas multiboot compliant ( FreeBSD, NetBSD, OpenBSD, et Linux).
- Charger plusieurs modules
- Support complet du chargement de modules.
- Charger un fichier de configuration
- Support de fichiers de configuration au format texte avec des commandes de boot. Il est également possible de charger un autre fichier de configuration dynamiquement et embarque un fichier de configuration preset dans un fichier image grub. La liste des commandes sont un superset de ces lignes de commandes supportées.
- Fournis une interface par menu
- Une interface à menu avec un timeout programmable est disponible. Il n'y a pas de limite fixée sur le nombre d'entrées de boot, et l'implémentation actuelle a l'espace pour des centaines.
- Interface en ligne de commande flexible: Une interface flexible, accessible depuis le menu, est disponible pour éditer les commandes, ou écrire une nouvelle commande. Si aucun fichier de configuration n'est présent, GRUB supprime la ligne de commande.
- Suporte plusieurs systèmes de fichier: AFFS, AtheOs Fs, BeFS, BtrFS, cpio, ext2/3/4, DOS, ISO9660, JFS, Minix Fs, NTFS, ReiserFS, ROMFS, SFS, Squash4, tar, UDF, BSD UFS, XFS et ZFS.
- Décompression automatique: Peut décompresser des fichiers compressés avec gzip ou xz. Cette fonction est automatique et transparente à l'utilisateur.
- Accède aux données sur un périphérique installé
- Supporte la lecture des données depuis des disquettes ou disques dur reconnus par le BIOS
- Indépendant des translation de géometrie du disque. À la différence de nombreux boot loader, GRUB gère les géometries de disque de manière transparente.
- Detecte toute la RAM installée. GRUB peut généralement trouver toute la RAM installée sur une machine compatible PC. Il utiliser des techniques de requête du BIOS pour trouver toutes les régions mémoire.
- Support du mode LBA. GRUB détecte automatiquement si le mode LBA est accessible et l'utilise si disponible.
- Support du boot réseau
- GRUB est un bootloader basé sur le disque mais supporte également le réseau, en utilisant TFTP
- Support de terminaux distants
- Pour supporter des machines sans console, GRUB fournis un terminal distant. Seul le terminal série est implémenté actuellement.

Convention de nommage

La syntaxe de périphérique utilisée dans GRUB est un peu différent de ce qui est vu dans un OS, et il est nécessaire de spécifier un couple disque/partition. l'exemple:
(fd0)
Avant tout, GRUB exige que le nom du périphérique soit entre parenthèses. fd signifie une disquette. Le numéro 0 est le numéro du disque, qui est compté en partant de 0. Cette expression indique toute la disquette.
(hd0,msdos2)
Ici, hd signifie un disque dur. 0 indique le numéro du disque. msdos indique le type de partition, et 2 indique e numéro de partition. Les numéros de partitions sont comptés à partir de 1, et non 0. Cette expression spécifie la 2ème partition du premier disque. Dans ce cas, GRUB utilise une partition du disque, au lieu du disque entier.
(hd0,msdos5)
Cela spécifie la première partition étendue du disque dur. Noter que les numéros de partition pour les partitions étendues sont comptés à partir de 5, sans regarder le nombre de partition primaire sur le disque.
(hd1,msdos1,bsd1)
Signifie la partition a de BSD sur le premier slice du second disque.

   Noter que GRUB ne fait pas de distinction entre IDE et SCSI. Il compte simplement les numéros de disque de 0, sans regarder leur type. Normalement, un disque IDE est inférieur au numéro d'un disque SCSI, bien que ce n'est pas vrai si l'on change la séquence de boot en inversant les disque IDE et SCSI dans le BIOS.

Maintenant, pour spécifier un fichier on utilisera la syntaxe:
(hd0,msdos1)/vmlinuz
Cela spécifie le fichier nommé 'vmlinuz', trouvé sur la première partition du premier disque dur.

Installation

   Pour installer GRUB comme boot loader, il faut d'abord installer GRUB et les utilitaires sous un OS type UNIX. Une fois installé, la commande grub-install install le bootloader sur le disque.

   GRUB est fournis avec des images de boot, qui sont généralement dans /usr/lib/grub/‹cpu›-‹plateform› c'est le répertoire d'image, et le répertoire où le boot loader doit les trouver (généralement /boot) est le répertoire de boot.

   Pour installer GRUB sous un OS type Unix, invoquer le programme grub-install en root. L'utilisation est très simple. Vous devez simplement spécifier un argument au programme, où installer le boot loader. L'argument doit être un fichier de périphérique (par ex: /dev/hda). l'option --boot-directory spécifie le répertoire de boot (/boot par défaut).

Certains bios ont un bug qui exposent la première partition d'un disque usb comme disquette au lieu de l'exposer comme disque usb, il est nécessaire dans ce cas d'utiliser:
losetup /dev/loop0 /dev/sdb1
mount /dev/loop0 /mnt/usb
grub-install --boot-directory=/mnt/usb/bugbios --force --allow-floppy /dev/loop0

   Noter que grub-install est actuellement un simple script shell et le vrai travail est fait pas grub-mkimage et grub-setup.

Créer un CDROM bootable

   GRUB supporte le mode sans émulation dans la spécification El Torito. Celà signifie qu'on peut utiliser tout le CDROM depuis GRUB sans avoir à créer un fichier image disquette ou disque dur, qui peut créer des problèmes de compatibilité.

   Pour booter depuis un CD-ROM, GRUB utilise une image spéciale appelée cdboot.img, qui est concaténé avec core.img. Le core.img utilisé pour cela devrait être construit avec au moins les modules iso9660 et biosdisk. Le CDROM bootable va généralement nécessiter également un fichier de configuration grub.cfg et quelques autres modules.

Pour créer un CD de récupération GRUB simple, utiliser la commande grub-mkrescue:
grub-mkrescue -o grub.iso
Pour inclure d'autres fichiers à l'image, créer un répertoire
mkdir iso
créer un répertoire pour GRUB:
makd -p iso/boot/grub
Si souhaité, créer le fichier de configuration grub.cfg et copier les fichier et répertoires pour le disque dans iso/. Enfin, créer l'image:
grub-mkrescue -o grub.iso iso

   Le périphérique root sera définis de manière approprié en entrant le fichier de configuration, pour réferrer aux noms de fichier dans le cd sans avoir à utiliser de nom de périphérique expicit. Celà simplifie la production d'images qui fonctionnent sur les disques optiques et les périphériques de stockage USB.

Mappage entre les disques BIOS et les périphériques OS

   Si le fichier de map de périphérique existe, les utilitaires GRUB (grub-probe, grub-setup, etc) le lise pour mapper les périphériques BIOS aux périphériques OS. Ce fichier consiste de ligne sous la forme: (device) file

   device est un disque spécifié dans la syntaxe GRUB, et file est un fichier OS, qui est normalement un fichier de périphérique.

   Historiquement, le fichier de mappage de périphérique a été utilisé parce que les noms de périphérique GRUB devaient être utilisés dans le fichier de configuration, et ils étaient dérivés des numéro de lecteur du BIOS. Le mappage entre les disque BIOS et OS ne peut pas toujours être deviné correctement: par exemple GRUB obtiendra le mauvais ordre si on échange la séquence de boot entre IDE et SCSI dans le BIOS.

   Malheureusement, même les noms de périphérique OS ne sont pas toujours stable. Les versions moderne de Linux peuvent sonder les disques dans un ordre différent d'un boot à l'autre, et le préfixe (/dev/hd* vs /dev/sd*) peut changer en fonction du pilote utilisé. Cela impose d'éditer fréquemment le fichier de map.

   GRUB évite ce problème en utilisant les UUID ou les labels de système de fichier en générant grub.cfg, et il est recommandé de faire de même pour toute entrée ajoutée manuellement. Si le fichier de map n'existe pas, les utilitaires GRUB assument un map temporaire à la volée. C'est suffisant, en particulier pour les système à un seul disque.

   Cependant, le fichier de map de périphérique n'est pas entièrement obsolète, et il est utilisé pour écraser un environnement courant différent de celui du boot. Un cas courant est l'utilisation d'une partition ou d'un volume logique comme disque pour une machine virtuelle.

Installation BIOS

   Le format de la table de partition traditionnellement utilisé pour les plateformes PC BIOS est appelée le format MBR; c'est le format qui autorise jusqu'à 4 partitions primaire et des partitions logiques additionnelles. Avec ce format de table de partition il y a 2 manières d'installer GRUB: Il peut être embarqué dans la zone entre le MBR et la première partition, (généralement 31KiB, appelée la zone embarquée), ou l'image peut être installé dans un système de fichier et une liste de blocks le forme peuvent être stockés dans le premier secteur de cette partition.

   Chaque méthode a ses inconvénients. Il n'y a pas de manière de réserver de l'espace dans la zone embarquée de manière sûre, et certains logiciels propriétaire sont connus pour l'utiliser; et les systèmes sont parfois partitionnés sans laisser suffisamment d'espace avant la première partition. D'un autre coté, installer dans un système de fichier signifie que GRUB est vulnérable si ses blocks sont déplacés dans le système de fichiers tel que fsck, donc cette approche est fragile, et peut seulement être utilisée si le système /boot est sur le même disque que le BIOS boot.

   Les systèmes récents utilisent le format GPT. C'est spécifié dans EFI, mais peut également être utilisé sur les plateformes BIOS si le système le supporte. Par exemple, GRUB et GNU/Linux peuvent être utilisé dans cette configuration. Avec ce format, il est possible de réserver une partition entière pour GRUB, appelée la partition de Boot. GRUB peut ainsi être embarquée dans cette partition sant rique d'être écrasé par un autre logiciel et dans être contenu dans un système de fichier.

   En créant un BIOS Boot Partition dans un système GPT, on doit s'assurer qu'il y a au moins 31KiB d'espace disponible. Il faut également s'assurer qu'il a le type de partition correcte. En utilisant parted:

Boot

   Grub peut charger les kernels conforme au Multiboot de manière consistante mais pour certains OS, il faut utiliser une méthode spécifique.

booter un OS

   GRUB a 2 méthodes de boot distinct. Une des 2 est de charger un OS directement, et l'autre est de chaîner le loader qui va ainsi charger l'OS.

   Multiboot est le format natif supporté par GRUB. Il supporte également Linux. Cependant, DOS et Windows ont certains problèmes.

   Pour les OS qui ne supportent pas Multiboot et n'ont pas de support spécifique dans GRUB, le chain-loader doit être utilisé, ce qui implique qu'un autre loader est chargé.

La commande chainloader est utilisée pour définir ce mode. Il est normalement nécessaire de charger certains modules GRUB et définir le périphérique root de manière approprié. Pour un système Windows, une entrée peut ressembler à:
menuentry "Windows" {
    insmod chain
    insmod ntfs
    set root=(hd0,1)
    chainloader +1
}

   Sur les système avec plusieurs disques dur, une travail supplémentaire doit être fournis. Le chain-Loading est seulement supporté sur les PC BIOS et les plateformes EFI.

Boot Loopback

   Grub est capable de lire une image ( CD ou HDD) stocké dans un stockage accessible. Cependant l'OS lui-même devrait être capable de trouver son root. Cela implique généralement de lancer un programme dans l'espace utilisateur avant que le vrai root soit trouvé. GRUB peut charger une petite image faite spécialement en ram en la passant au kernel, avec les commandes kfreebsd_module, knetbsd_module_elf, kopenbsd_ramdisk, initrd, initrd16, multiboot_module, multiboot2_module, ou xnu_ramdisk, en fonction du chargeur.

Problèmes spécifiques à l'OS

   Vu que GNU/Hurd est conforme à Multiboot, il est facile à booter. Il ne faut cependant pas oublier de spécifier la partition root du kernel.

1. Spécifier le périphérique root de GRUB sur le même disque que celui de GNU/Hurd. La commande search --set=root --file /boot/gnumach.gz ou similaire peut aider.
2. Charger le kernel et les modules:
multiboot /boot/gnumach.gz root=device:hd0s1
module /hurd/ext2fs.static ext2fs --readonly --multiboot-command-line='${kernel-command-line}' --host-priv-port='${host-port}' --device-master-port='${device-port}' --exec-server-task='${exec-task}' -T typed '${root}' '$(task-create)' '$(task-resume)'
module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)'
3. Finalement, lancer la commande boot.

GNU/Linux

   Il est relativement simple à booter, parce qu'il ressemble au boot des OS conformes Multiboot.

1. Définir le périphérique root de grub au même disque que le root de Linux.
2. Charger le kernel avec la commande: linux /vmlinuz root=/dev/sda1. Si nécessaire ajouter des paramètres au kernel: linux /vmlinuz root=/dev/sda1 acpi=off
3. Si besoin d'un initrd, utiliser la commande initrd: initrd /initrd
4. Finalement lancer la commande boot.

Fichier de configuration

   GRUB est configuré en utilisant grub.cfg, généralement dans /boot/grub. Ce fichier est flexible, mais beaucoups d'utilisateurs n'ont pas besoin d'écrire tout à la main.

Configuration simple

   Le programme grub-mkconfig génère grub.cfg correctement dans la plupart des cas. Il est prévu pour mettre à jours une distribution, et découvre les kernels disponible et tente de générer des entrées.

   grub-mkconfig a quelques limitations. En ajoutant des entrées manuellement à la fin de la liste en éditant /etc/grub.d/40_custom, ou en créant /boot/grub/custom.cfg, changer l'ordre des entrées du menu ou changer les scripts dans /etc/grub.d ou changer leur nom peut rendre les changements plus complexe. Cela peut être améliorer dans le future. Il est préférable dans ce cas d'éditer directement grub.cfg et de désactiver l'utilisation automatique de grub-mkconfig du système.

   Le fichier /etc/default/grub contrôle les opération de grub-mkconfig. Il est lu par un script shell, et doit être une entrée de shell POSIX valide; normalement c'est simplement une séquence de lignes KEY=value; mais si la valeur contient des espace ou des caractères spéciaux, ils doivent être entre guillemets.

GRUB_DEFAULT Entrée du menu par défaut. Peut être un nombre (la nième entrée) dans le menu, en commançant à 0, ou le titre d'une entrée du menu, ou la chaîne spéciale "saved", qui est l'entrée sauvée par GRUB_SAVEDEFAULT, grub-set-default, ou grub-reboot. Défaut: 0
GRUB_TIMEOUT Boot sur le défaut au boot de n secondes. Défaut: 5. 0 boot immédiatement sans afficher le menu, et -1 attend indéfiniment
GRUB_HIDDEN_TIMEOUT Attend n secondes pour une touche avant d'afficher le menu. Avec GRUB_TIMEOUT à 0, le menu n'est jamais affiché sauf si une touche est pressée. Défaut: non-définis
GRUB_HIDDEN_TIMEOUT_QUIET Supprime le décompte de GRUB_HIDDEN_TIMEOUT. non définis par défaut.
GRUB_DEFAULT_BUTTON
GRUB_TIMEOUT_BUTTON
GRUB_HIDDEN_TIMEOUT_BUTTON
GRUB_BUTTON_CMOS_ADDRESS Variantes des variables correspondantes sans le suffix _BUTTON, utilisés pour supporter les boutons de mise sous tension spécifique au vendeur.
GRUB_DISTRIBUTOR Définis par les distributeurs de GRUB pour identifier leur nom. Utilisé pour générer des titre d'entrée de menu plus informatifs
GRUB_TERMINAL_INPUT Sélectionne le périphérique d'entrée du terminal. les noms dépendent de la plateform, mais peut inclure console (PC Bios et consoles EFI), serial, ofconsole (OpenFirmware Console), at_keyboard (PC AT keyboard utilisant le protocole de boot HID), ou usb_keyboard (clavier USB utilisant le protocole de boot HID). Défaut: utilise l'entrée de terminal natif de la plateforme.
GRUB_TERMINAL_OUTPUT Sélectionne le périphérique de sortie du terminal. console, serial, gfxterm, ofconsole, ou vga_text. Défaut: utilise la sortie de terminal native de la plateforme.
GRUB_TERMINAL Si définis, remplace GRUB_TERMINAL_INPUT et GRUB_TERMINAL_OUTPUT.
GRUB_SERIAL_COMMAND Une commande pour configurer le port série pour utiliser la console série. Défaut: serial
GRUB_CMDLINE_LINUX Arguments à ajouter aux entrées de menu pour le kernel Linux
GRUB_CMDLINE_LINUX_DEFAULT Sauf si GRUB_DISABLE_RECOVERY est définis, 2 entrées de menu sont générés pour chaque kernel linux: une entrée par défaut, et une entrée pour le mode récupération. Cette option liste les arguments à ajouter seulement à l'entrée par défaut, après ceux listés dans GRUB_CMDLINE_LINUX.
GRUB_DISABLE_LINUX_UUID Normalement, grub-mkconfig génère des entrées de menu qui utilisent des UUID pour identifier le système de fichie racine pour le kernel Linux en utilisant "root=UUID=...". Pour désactiver l'utilisation des UUID, définir cette option à true.
GRUB_DISABLE_RECOVERY À true, désactive la génération des entrées de menu pour le mode récupération
GRUB_VIDEO_BACKEND Si le support vidéo graphique est requis, soit parce que le terminal graphique gfxterm est utilisé ou parce que GRUB_GFXPAYLOAD_LINUX est définis, grub-mkconfig va normalement charger tous les pilotes vidéo GRUB et utiliser le plus approprié pour votre hardware. Cette option permet de forcer des paramètres spécifique. Une fois grub-install lancé, les pilotes disponible sont listés dans /boot/grub/video.lst.
GRUB_GFXMODE Définis la résolution utilisée dans le terminal graphique gfxterm. Noter que vous pouvez seulement utiliser les modes que votre carte supporte via les extensions VESA BIOS (VBE), donc pour les résolution d'écran LCD peuvent ne pas être disponible. Le défaut est auto, qui tente de sélectionner la résolution préférrée.
GRUB_BACKGROUND Définis l'image à utiliser avec le terminal graphique gfxterm. Ce fichie doit être accéssible au moment du boot et doit se terminer avec .png, .tga, .jpg, ou .jpeg. L'image sera redimensionné si besoin.
GRUB_THEME Définis un thème à utiliser avec le terminal graphique gfxterm
GRUB_GFGPAYLOAD_LINUX à text, force Linux à booter en mode text normal. à keep, préserve le mode graphique définis avec GRUB_GFXMODE.
GRUB_DISABLE_OS_PROBER Normalement, grub-mkconfig tente d'utiliser le programme os-prober, si installé, pour découvrir les autres OS installés sur le système et générer les entrées de menu appropriés pour eux. à true, désactive cette recherche.
GRUB_INIT_TUNE Joue un son dans les haut-parleurs quand GRUB démarre. Utile pour les utilisateurs ne pouvant pas voir l'écran. La valeur de cette option est passée directement à play.
GRUB_BARAM Si mis, GRUB émet une commande badram pour filtrer des régions mémoire.
GRUB_PRELOAD_MODULES Cette option peut être mis à une liste de modules GRUB séparés par des espaces. Chaque module sera chargé le plus tôt possible, au début de grub.cfg.

   Pour une personnalisation plus détaillée de la sortie de /etc/grub.d/40_custom est particulièrement utile pour ajouter des entrées particulièrement utiles pour ajouter des entréess

Ecrire des fichiers de configuration directement

   grub.cfg est écrit dans la langage de scripting intégré à GRUB, qui a une syntaxe similaire à BASH et d'autres shells.

MOTS Un mot est une séquence de caractères considérés comme une unité simple. Les mots sont séparés par des métacaractères, qui sont les suivane, plus espace, tabulation et nouvelle ligne.
{ } | & $ ; › ‹ les guillemets peuvent être utilisés pour inclure les métacaractères dans les mots.

Mots réservés

Les mots réservés ont une signification spéciale pour GRUB. Les mots suivants sont reconus:
! [[ ]] { }
case do done elif else esac fi for function
if in menuentry select then time until while

guillemets

   Les guillemets sont utilisés pour supprimés la signification spéciale de certains caractères ou mots. Il peut être utilisé pour traiter les métacaractères comme partie d'un mot. Il y a 3 mécanismes de guilemets: le caractère d'échappement, guillemets simple et guillemets double.

expansion de variables

   Le caractère '$' introduit l'expansion de variable. Le nom de la variable à étendre peut être entre crochets, qui servent optionnellement à protéger la variable à étendre des caractères qui suivent immédiatement.

   Les noms de variables normales commencent avec un caractère alphanumérique, suivi par 0 ou plusieurs caractères alphanumérique. Ces noms réfèrent aux entrées dans l'environnement GRUB.

   Les noms de variables positionnels consistent en 1 ou plusieurs chiffres. Ils représentent les paramètres passés aux appels de fonction, avec $1 représentant le premier paramètre.

   Le nom de variable spéciale ? s'étend au code de sortie de la dernière commande exécutée. Quand les noms de variable positionnels sont actifs, d'autres variables @, *, et # sont définis et s'étendent à tous les paramètres positionnels avec des guillemets nécessaire, sans guillemets, et comme compteur de paramètres, respectivement.

Commandes simple

   Une commande simple est une séquence de mots séparés par des espaces ou des tabulation et terminés par un ';' ou un newline. le premier mot spécifie la commande à exécuter. Les autres mots sont passés en argument à la commande.

   La valeur de retour d'une commande simple est sont status de sortie. Si le mot réservé ! précède la commande, la valeur de retour est un NOT du status de sortie de la commande.

Commandes composés

Une commande composée est une des suivantes:
for name in word ...; do list; done

if list; then list; [elif list; then list;] ... [else list;]fi

while cond; do list; done
until cond; do list; done

function name { command; ...}

menuentry title [--class=class ...][--users=users][--unrestricted][--hotkey=key]{command;...}

Commande embarquées

Certaines commande sont également fournis par GRUB pour effectuer des action qui ne seraient pas possible autrement.
break[n]
continue[n]
return[n]
shift[n]

Configuration manuelle Multiboot

   L'autogénération des fichiers de configuration pour les environnements multi-bot dépendent de os-prober. Il est possible de créer soi-même la configuration

Tout d'abord, créer une partition séparée pour GRUB. Certaines options ci-dessous montrent comment charger des images d'installeur d'OS depuis cette partition. Mounter cette partition dans /mnt/boot et désactiver GRUB dans tous les OS et installer manuellement le dernier GRUB compilé avec:
grub-install --boot-directory=/mnt/boot /dev/sda

Dans tous les OS installer les outils GRUB mais désactiver l'installation de GRUB dans le secteur de boot, pour avoir le menu.lst et grub.cfg disponible. Désactiver également l'utilisation d'os-prober en définissant:
GRUB_DISABLE_OS_PROBER=true

Puis écrire un grub.cfg:
menuentry "OS using grub2" {
    insmod xfs
    search --set=root --label OS1 --hint hd0,msdos8
    configfile /boot/grub/grub.cfg
}
    
menuentry "OS using grub2-legacy" {
    insmod ext2
    search --set=root --label OS2 --hint hd0,msdos6
    legacy_configfile /boot/grub/menu.lst
}
    
menuentry "Windows XP" {
    insmod ntfs
    search --set=root --label WINDOWS_XP --hint hd0,msdos1
    ntldr /ntldr
}
    
menuentry "Windows 7" {
    insmod ntfs
    search --set=root --label WINDOWS_7 --hint hd0,msdos2
    ntldr /bootmgr
}
    
menuentry "FreeBSD" {
    insmod zfs
    search --set=root --label freepool --hint hd0,msdos7
    kfreebsd /freebsd@/boot/kernel/kernel
    kfreebsd_module_elf /freebsd@/boot/kernel/opensolaris.ko
    kfreebsd_module_elf /freebsd@/boot/kernel/zfs.ko
    kfreebsd_module /freebsd@/boot/zfs/zpool.cache type=/boot/zfs/zpool.cache
    set kFreeBSD.vfs.root.mountfrom=zfs:freepool/freebsd
    set kFreeBSD.hw.psm.synaptics_support=1
}
    
menuentry "experimental GRUB" {
    search --set=root --label GRUB --hint hd0,msdos5
    multiboot /experimental/grub/i386-pc/core.img
}
    
menuentry "Fedora 16 installer" {
    search --set=root --label GRUB --hint hd0,msdos5
    linux /fedora/vmlinuz lang=en_US keymap=sg resolution=1280x800
    initrd /fedora/initrd.img
}
    
menuentry "Fedora rawhide installer" {
    search --set=root --label GRUB --hint hd0,msdos5
    linux /fedora/vmlinuz repo=ftp://mirror.switch.ch/mirror/fedora/linux/development/rawhide/x86_64 lang=en_US keymap=sg resolution=1280x800
    initrd /fedora/initrd.img
}
    
menuentry "Debian sid installer" {
    search --set=root --label GRUB --hint hd0,msdos5
    linux /debian/dists/sid/main/installer-amd64/current/images/hd-media/vmlinuz
    initrd /debian/dists/sid/main/installer-amd64/current/images/hd-media/initrd.gz
}

Embarquer un fichier de configuration dans GRUB

   GRUB supporte un fichier de configuration embarqué directement dans l'image core, pour qu'il puisse être chargé avant d'entrée dans le mode normal. C'est utile pour par exemple quand est difficile de trouver le vrai fichier de configuration ou pour débugger un problème avec le chargement de ce fichier. grub-install utilise cette fonctionnalité quand il n'utilise pas de fonction disque du bios ou en installant sur un disque différent de celui contenant /boot/grub, auquel cas il doit utiliser la commande search pour trouver /boot/grub.

   Pour embarquer un fichier de configuration, utiliser l'option -c de grub-mkimage. Le fichier est copié dans l'image core.

Une fois embarqué, le fichier de configuration est exécuté, GRUB va charger le module 'normal', qui va lire le fichier de configuration de $prefix/grub.cfg. À ce point, la variable root aura également été définis au nom du périphérique root. Par exemple, prefix peut être définis à '(hd0,1)/boot/grub' et et root peut être définis à 'hd0,1'. Donc, dans la plupart des cas, le fichier de configuration embarqué a seulement besoin des variables root et prefix, et ainsi supprimer le traitement normale de GRUB. Un exemple typique est:
search.fs_uuid 01234567-89ab-cdef-0123-456789abcdef root
set prefix=($root)/boot/grub

   Le module search_fs_uuid doit être inclus dans l'image core pour que cet exemple fonctionne.

Dans des cas plus complexe, il peut être utile pour lire d'autres fichiers de configuration directement depuis le fichier de configuration embarquée. Cela permet de lire des fichiers qui ne s'appellent pas grub.cfg ou lire des fichiers depuis un répertoire autre que celui où les modules GRUB sont installés. Pour faire cela, inclure les modules configfile et normal dans l'image core, et embarquer un fichier de configuration qui utilise la commande configfile pour charger un autre fichier. L'exemple suivant nécessite également les modules echo, search_label, et test à inclure dans l'image core:
search.fs_label grub root
if [ -e /boot/grub/example/test1.cfg ]; then
    set prefix=($root)/boot/grub
    configfile /boot/grub/example/test1.cfg
else
    if [ -e /boot/grub/example/test2.cfg ]; then
        set prefix=($root)/boot/grub
        configfile /boot/grub/example/test2.cfg
    else
        echo "Could not find an example configuration file!"
    fi
fi

   Le fichier de configuration embarqué peut ne pas contenir d'entrées de menu directement.

format du fichier de thème

   Le menu graphique GRUB supporte les thèmes qui peuvent être personnalisés. Le thème est configuré via un fichier texte qui spécifie les composant de l'interface graphique (incluant le menu de boot, la barre de progression de timeout, et les messages) ainsi que l'apparence en utilisant les couleurs, fonts, et images. Des exemples sont disponible dans docs/example_theme.txt.

Couleurs

Les couleurs peuvent être spécifié de nombreuses manières:
Style HTML #RRGGBB ou #RGB
au format RGB décimal: "128,128,255".
Avec les noms de couleur SVG 1.0 qui doivent être spécifiés en minuscule.

Fonts

   Les fonts GRUB utilisent le format de fonts bitmap PFF2. Les fonts sont spécifié avec le nom des font. Actuellement il n'y a pas de provision pour une liste de font préférentielle, ou de dériver une font d'une autre. Les fonts sont chargés avec la commande loadfont dans GRUB. Pour voir la liste des fonts chargés, exécuter lsfonts. S'il y a trop de font pour tenir dans l'écran, définir set pager=1 avant lsfonts.

Progress Bar

   Les barres de progression sont utilisées pour afficher le temps restant avant que GRUB boot sur l'entrée par défaut. Pour créer une barre de progression qui va afficher le temps restant, simplement créer un composant progress_bar avec l'id __timeout__. Celà indique à GRUB que la progress bar devrait être mis à jours si le compteur du boot automatique est intérrompu par l'utilisateur.

   Les barres de progression peuvent optionnellement avoir un texte affiché. Ce texte est contrôlé par la variable text qui contient un template printf avec le seul argument %d qui est le nombre de secondes restants. Additionnellement les valeurs spéciales “@TIMEOUT_NOTIFICATION_SHORT@”, “@TIMEOUT_NOTIFICATION_MIDDLE@”, “@TIMEOUT_NOTIFICATION_LONG@” sont remplacées avec les templates standard et traduits.

Indicateur de progression circulaire

   L'indicateur de progression circulaire fonctionne de manière similaire à la progress bar. en donnant un id de __timeout__, GRUB met à jours l'indicateur de progression circulaire pour indiquer le temps restant. pour cet indicateur, il y a 2 images utilisées: l'image au centre, et l'image de tick. L'image du centre est rendue au centre du composant, et l'image tick est utilisée pour rendre chaque marque à la circomférence de l'indicateur.

Labels

   Les labels texte peuvent être placés sur l'écran de boot. La font, couleur et alignement horizontale peuvent être spécifiés pour les labels. Si un label a l'id __timeout__, le text pour ce label est également utilisé avec un message informant l'utilisateur du nombre de secondes restant jusqu'au boot automatique. C'est utile dans le acs où vous souhaitez que le texte soit affiché au lieu d'une progress bar.

Boot Menu

   Le menu de boot où GRUB affiche les entrées de menu. C'est une liste d'éléments, où chaque élément a un titre, et un icône optionnel. L'icône est sélectionné basésur les classes spécifiée pour l'entrée du menu. Si il y a un fichier png nommé myclass.png dans grub/themes/icons, il sera affiché pour les éléments ayant cette classe. Le menu de boot peut être personnalisé de différentes manières, tels que la font et la couleur utilisé pour le titre de l'entrée de menu, et en spécifiant de boites stylisés pour le menu lui-même, et pour l'élement sélectionné.

Boites stylisées

Une de fonctionnalité les plus importantes pour personnalisés la couche est d'utiliser des boites stylisés, composés de 9 régions rectangulaires, qui sont utilisés pour dessiner les boites.
Northwest (nw)    North (n)    Northeast (ne)
West (w)    Center (c)    East (e)
Southwest (sw)    South (s)    Southeast (se)

Fichier de thème

   Le fichier de thème est un fichier texte, qui contient 2 types de déclarations, Les propriétés globales, et la construction de composant.

Les propriétés globales sont spécifiées avec le format simple:
name1: value1
name2: "valeur qui peut contenir des espaces"
name3: #88F

Liste de propriétés globles

title-text Spécifie le texte à afficher en haut de l'écran
title-font Font utilisée pour le titre
title-color Couleur du titre
message-font font à utiliser pour les messages
message-color Couleurs pour les messages
message-bg-color couleur de fond
desktop-image Image à utiliser comme fond
desktop-color Couleur pour le fond si desktop n'est pas spécifié
terminal-box Spécifie le motif de nom de fichier pour la boite stylisée.

Construction

   Une plus grande personnalisation est fournie par des composants. Une arborescence de composants forment l'interface utilisateur. Les conteneurs sont des composants qui peuvent contenir d'autres composants, et il y a toujours un composant root qui est une instance d'un conteneur caneva.

Les composant sont créés dans le fichier thème en préfixant le type de composant avec le signe +:
+ label { text="GRUB" font="aqui 11" color="#8FF" }

   Les propriétés d'un composant sont spécifiés avec "name=value", où value peut être un simple mot, un chaîne entre guillemets, ou un tuple "(ex: preferred_size=(120,80)"

Liste de composants

label Un label affiche une ligne de texte. Propriétés:

        id À "__timeout__" pour afficher le temps passé pour booter sur l'entrée par défaut.
        text Le texte à afficher
        font La font à utiliser
        color La couleur du texte
        align left, center et right
        visible À false permet de cacher le label.

image Affiche une image. Propriétés:

        file Chenin de l'image à charger

progress_bar Affiche une barre horizontale de progression. Propriétés

        id À "__timeout__" pour afficher le temps passé pour booter sur l'entrée par défaut.
        fg_color couleur de devant pour le rendu
        bg_color couleur de fond pour le rendu
        border_color La couleur de bordure pour le rendu
        text_color Couleur du texte
        bar_style La spécification de la boite stylisée pour la barre de progression.
        highlight_style La spécification de boite stylisée pour la région survolée de la barre de progression.
        highlight_overlay À true, la highlight box est affichée par dessus.
        text Le texte à afficher sur la barre de progression.
        font font à utiliser

circular_progress Affiche un indicateur de progression circulaire. L'apparence de ce composant est déterminé par 2 images. Propriétés:

        id À "__timeout__" pour afficher le temps passé pour booter sur l'entrée par défaut.
        center_bitmap Nom de l'image au centre
        tick_bitmap Nom de l'image de tick
        num_ticks Nombre de ticks qui sont créés dans un cercle complet
        ticks_disappear booléen indiquant si les ticks apparaîssent ou disparaissent progressivement.
        start_angle Position du premier tick, mesuré en "parrot" (1 parrot = 1/256 du cercle complot.)

boot_menu Affiche le menu de boot GRUB. il permet de sélectionner les éléments et de les exécuter. propriétés:

        item_font font à utiliser pour les items de menu
        selected_item_font Font à utiliser pour l'élément sélectionné
        item_color Couleur du texte
        selected_item_color Couleur du texte de l'élément séléctionné
        icon_width Largeur de l'icône
        icon_height Hauteur de l'icône
        item_height Hauteur de chaque élément du menu
        item_padding Espace en pixels à laisser de chaque côté du contenu de l'élément du menu
        item_icon_space L'espace entre un icône et le texte, en pixels
        item_spacing Espace à laisser entre les éléments du menu, en pixel
        menu_pixmap_style Motif de fichier pour la boite stylisée.
        selected_item_pixmap_style Boite stylisée pour l'élement sélectionné
        scrollbar booléen indiquant si la barre de défilement est affichée
        scrollbar_frame Motif de fichier pour le fond de la barre de défilement.
        scrollbar_thumb Motif de fichier pour la barre de défilement.
        scrollbar_thumb_overlay À true, le scrollbar thumb des bords s'affichent par dessus la scrollbar frame.
        scrollbar_slice Emplatement de la barre de défilement (west, center, east)
        scrollbar_left_pad padding à gauche, en pixel
        scrollbar_right_pad padding à droite, en pixel
        scrollbar_top_pad Padding en haut, en pixel
        scrollbar_bottom_pad padding en bas, en pixel
        visible À false permet de cacher la barre de progression

booter grub depuis le réseau

Les instructions suivantes fonctionnent seulement sur les systèmes PC BIOS où l'environnement PXE est disponible.
Pour générer une image PXE, lancer:
grub-mkimage --format=i386-pc-pxe --output=grub.pxe --prefix='(pxe)/boot/grub' pxe pxecmd

   copier grub.pxe, /boot/grub/*.mod et /boot/grub/*.lst sur le serveur TFTP, s'assurant que *.mod et *.lst sont accessibles via le chemin /boot/grub depuis les serveur TFTP. définir la configuration du serveur DHCP pour offrir grub.pxe comme fichier de boot.

   On peut également utiliser l'utilitaire grub-mknetdir pour générer une image et un répertoire GRUB, au lier de copier les fichiers manuellement.

   Une fois GRUB démarré, les fichiers sur le serveur TFTP sera accessible via le périphérique pxe.

   L'adresse ip du serveur et de la passerrelle peuvent être contrôlés en changeant le périphérique (pxe) en (pxe:server-ip) ou (pxe:server-ip:gateway-ip).

   GRUB fournis de nombreuses variables d'environnements qui peuvent être utilisée pour inspecter ou changer le comportement du périphérique PXE:

net_‹interface›_ip L'adresse IP de cette machine. Lecture seule
net_‹interface›_mac L'adresse MAC de l'interface réseau. Lecture seule
net_‹interface›_hostname Le nom d'hôte du client fournis par DHCP. Lecture seule.
net_‹interface›_domain Nom de domaine du client fournis par DHCP. Lecture seule.
net_‹interface›_rootpath Le chemin du disque root du client, fournis par DHCP. Lecture seule.
net_‹interface›_extensionspath Le chemin d'extensions de vendeur DHCP additionnels fournis par DHCP. Lecture seule
net_‹interface›_boot_file Nom du fichier de boot fournis pas DHCP. Lecture seule.
net_‹interface›_dhcp_server_name Le nom du serveur DHCP responsable pour ces paramètres de boot. Lecture seule.
net_default_ip L'adresse IP de l'interface par défaut. Lecture seule. alias de net_${net_default_interface}_ip
net_default_mac L'adresse mac de l'interface par défaut. Lecture seule. alias de net_${net_default_interface}_mac
net_default_server Le serveur par défaut. Lecture écriture

Utilitser GRUB via une ligne série

   Pour les machines sans écran/clavier, il peut être utile de contrôler via des communications série. Pour connecter une machine avec un autre via une ligne série, il faut préparer un cable série, et avoir une carte série multiport. De plus, un émulateur de terminal est également requis, tels que minicom.

Comme pour GRUB, l'instruction pour définir un terminal série et simple. Exemple:
serial --unit=0 --speed=9600
terminal_input serial; terminal_output serial

   La commande serial initialise la série, COM1. Cette commande accepte de nombreuses options. Les commandes terminal_input et terminal_output choisissent quel type de terminal utiliser.

Utiliser GRUB avec des touches de mise en route

Certains vendeurs de laptop fournissent un bouton power-on additionnel qui boot un autre OS. GRUB supporte de tels boutons avec les variables GRUB_TIMEOUT_BUTTON, GRUB_DEFAULT_BUTTON, GRUB_HIDDEN_TIMEOUT_BUTTON and GRUB_BUTTON_CMOS_ADDRESS dans default/grub. Les valeurs connue sont :
Dell XPS M1530
85:3
Asus EeePC 1005PE
84:1

Fichiers image GRUB

   GRUB consiste de nombreuses images: une variété d'image de boot pour démarrer GRUB de différentes manières, une image kernel, et un jeu de modules qui sont combinés avec l'image kernel pour former l'image core.

boot.img Sur les systèmes PC BIOS, cette image est la première partie de GRUB à démarrer. Elle est écrite dans un MBR ou sur le secteur de boot d'une partition. Parce que le secteur de boot PC fait 512 octets, la taille de cette image fait exactement 512 octets. La seule fonction de boot.img est de lire le premier secteur de l'image core depuis le disque local, et de sauter dessus. À cause de la restriction de la taille, boot.img ne peut pas comprendre la structure d'un système de fichier, donc grub-setup code en dur l'emplacement du premier secteur de l'image core dans boot.img en installant GRUB.
diskboot.img Cette image est utilisée comme premier secteur de l'image core en bootant depuis un disque dur. Elle lit le reste de l'image core en mémoire et démarre le kernel. Vu que la gestion du système de fichier n'est pas encore disponible, il encode l'emplacement de l'image core en utilisant un format de liste de blockes
cdboot.img Cette image est utilisée comme premier secteur de l'image core en bootant depuis un CD-ROM.
pxeboot.img Cette image est utilisée comme début de l'image core en bootant depuis le réseau en utilisant PXE.
lnxboot.img Cette images peut être placée comme début de l'image core pour que GRUB ressemble à un kernel liste qui peut être booté par LILO.
kernel.img Cette image contient les facilités basiques de GRUB: frameworks pour les périphériques et gestion des fichiers, variables d'environnement, mode récupération, etc. Elle est rarement utilisée directement, mais intégré dans toutes les images core.
core.img L'image core de GRUB. Elle est construite dynamiquement depuis d'image kernel et une liste arbitraire de modules par le programme grub-mkimage. Généralement, elle contient suffisamment de modules pour accéder à /boot/grub, et charger tout le reste. Le design modulaire permet à l'image core d'être conservée petite, vu que la zone disque où elle doit résider fait souvent moins de 32Ko.
*.mod Tout le reste de GRUB réside dans des modules. Ils sont souvent chargés automatiquement, ou intégrés dans l'image core s'ils sont essentiels, mais peuvent également être chargés manuellement en utilisant insmod.

Syntaxe et sémantiques de système de fichiers

   GRUB utilise une syntaxe spéciale pour spécifier les disques qui peuvent être accédés par le BIOS. À cause de la limitation des BIOS, GRUB ne peut pas distinguer les disques IDE, ESDI, SCSI, et d'autres. Vous devez connaître quel périphérique BIOS est équivalent à quel périphérique OS. Normalement, cela devrait être clair si les fichiers sont visible dans un périphérique ou en utilisant la commande search.

Comment spécifier les périphériques

La syntaxe de périphérique est la suivante:
(device[,partmap-name1part-num1[,partmap-name2part-num2[,...]]])

Les disques BIOS et EFI utilisent soit fd ou hd suivis par un chiffre, comme fd0 ou cd. AHCI, PATA, crypto, USB utilisent le nom du pilote suivi par un nombre. Memdisque et host sont limités à un disque et donc son référrés juste par le nom du pilote. RAID(md), ofdisk(ieee1275 et nand), LVM(lv), LDM et arcdisq (arc) utilisent un nom de disque intrinsèque du disque aliasé comme nand. Les conflit sont résolus en suffixant un nombre si nécessaire. Les virgules doivent être échappés:
(fd0)
(hd0)
(cd)
(ahci0)
(ata0)
(crypto0)
(usb0)
(cryptouuid/123456789abcdef0123456789abcdef0)
(mduuid/123456789abcdef0123456789abcdef0)
(lvm/system-root)
(lvmid/F1ikgD-2RES-306G-il9M-7iwa-4NKW-EbV1NV/eLGuCQ-L4Ka-XUgR-sjtJ-ffch-bajr-fCNfz5)
(md/myraid)
(md/0)
(ieee1275/disk2)
(ieee1275//pci@1f\,0/ide@d/disk@2)
(nand)
(memdisk)
(host)
(myloop)
(hostdisk//dev/sda)

   part-num représente le numéro de partition de device, commençant à 1. partname est optionnel mais est recommandé vu que le disque peut avoir de nombreux partmaps top-level. En spécifiant le 3ème et dernier composant on peut accéder aux sous-partitions.

La syntaxe (hd0) représente utilisant tout le disque, alors que la syntaxe (hd0,1) représente l'utilisation de la première partition du disque.
(hd0,msdos1)
(hd0,msdos1,msdos5)
(hd0,msdos1,bsd3)
(hd0,netbsd1)
(hd0,gpt1)
(hd0,1,3)

   En activant le support réseau (tftp) , (http) et autre sont également disponibles. Avant d'utiliser le disque réseau, il faut initialiser le réseaux. En bootant sur un cdrom, (cd) est disponible.

Comment spécifier des fichiers

   Il y a 2 manières de spécifier des fichiers, par nom de fichier absolue, et par liste de block.

   Un nom de fichier absolue a la forme (hd0,1)/boot/grub/grub.cfg. Si le nom du périphérique est omis, GRUB utilise le périphérique root implicitement.

Une liste de blocks est utilisée pour spécifier un fichie qui n'apparaît pas dans le système de fichier, comme un chainloader. La syntaxe est [offset]+length[,[offset]+length]... par exemple:
0+100,200+1,300+300

   Cela signifie que GRUB devrait lire les blocks 0 à 99, le block 200, et les blocks 300 à 599. Si l'offset est absent, GRUB assume que l'offset est 0. De même, si le nom du périphérique est absent, le périphérique root est assumé.

Interface utilisateur de GRUB

   GRUB a une interface de menu simple pour choisir une entrée depuis un fichier de configuration, et une ligne de commande. GRUB lit son fichier de configuration dès qu'il l'a chargé. S'il en trouve un, l'interface à menu est activée en utilisant les entrées trouvées dans le fichier. Avec la ligne de commande, ou si le fichier de configuration n'a pas été trouvé, GRUB passe sur l'interface en ligne de commande.

   L'interface en ligne de commande fournis un prompt similaire à un shell Unix. Chaque commande est immédiatement exécutée après qu'elle soit entrée. Les commandes sont un sous-jeu de celles disponible dans le fichier de configuration, utilisée avec la même syntaxe.

   Le mouvement du curseur et l'édition du text sur la ligne peut être fait via un sous-jeu de fonctions disponible dans le shell BASH:

C-f (flèche droite) Déplacer d'un caractère en arrière
C-b (flèche gauche) Déplace d'un caractère en avant
C-a (HOME) Déplacer au début de la ligne
C-e (END) Déplace à la fin de la ligne
C-d (DEL) Supprimer le caractère sous le curseur
C-h (BS) Supprimer le caractère à gauche du curseur
C-k Supprimer le texte de la position courant à la fin de la ligne
C-u Supprimer le texte du début de la ligne à la position du curseur
C-y Placer le texte supprimé dans le tampon au curseur
C-p, C-n (flèche du haut/bas) De déplacer dans l'historique

   En tapant des commande interactivement, si le curseur et dans ou avant le premier mot dans la ligne de commande, la touche TAB affiche un listing des commandes disponible, ou la completion des disques, partitions, et noms de fichiers.

   Noter qu'on ne peut pas utiliser la fonctionnalité de completion dans le système de fichier TFTP.

   L'interface à menu est facile à utiliser. ses commande sont raisonnablement intuitives et décrites à l'écran. Basiquement, l'interface à menu fournis une liste d'entrées de boot. Utiliser les touches fléchées pour sélectionner l'entrée, puis appuyer sur entrer pour valider le choix

   Les commandes sont disponible pour entrer une ligne de commande en appuyant sur 'c' qui opèrent exactement comme la version sans fichier de configuration de GRUB, mais permet de retourner au menu si désiré en appuyant sur échappe.

   En protégeant l'interface avec un mot de passe, tout ce que l'on peut faire est de choisir une entrée avec entrer ou appuyer sur p pour entrer un mot de passe.

Éditer une entrée de menu

   L'éditeur d'entrée de menu ressemble à l'interface à menu principale, mais les lignes dans le menu sont des commandes individuelles dans l'entrée sélectionnée au lieu des noms de l'entrée.

   Si échappe est pressé dans l'éditeur, il annule tous les changement faits sur l'entrée et retourne dans le menu principal.

   Chaque ligne dans l'entrée de menu peut être édité librement, et on peut également ajouter des lignes. Pour booter sur l'entrée éditée, utiliser Ctrl+x.

Variables d'environnement GRUB

   GRUB supporte les variables d'environnement qui sont similaires aux système UNIX

biosnum En chaînant un autre chargeur de boot, GRUB a besoin de connaître quel numéro de disque BIOS correspond au périphérique root pour qu'il puisse être enregistré correctement. Si cette variable n'est pas définie, GRUB le devine.
check_signatures Contrôle si GRUB force la signature numérique au chargement des fichiers.
chosen En exécutant une entrée du menu, GRUB définis cette variable au titre de cette entrée.
cmdpath L'emplacement depuis lequel core.img a été chargé, en chemin absolue. Définis par GRUB au démarrage.
color_highlight Cette variable contient les couleurs de terminal foreground et background, séparé par un '/'. Définir cette variable change ces couleurs. Défaut: 'black/white'
color_normal Cette variable contient les couleurs normales foreground et background, séparés par un '/'. Chaque couleur doit être un nom parmis black, blue, green, cyan, red, magenta, brown, light-gray, dark-gray, light-blue, light-green, light-cyan, light-red, light-magenta, yellow, white. défaut: white/black
debug Cette variable peut être mis pour activer le debuggage de différents composants de GRUB. Contient une liste de facilités, ou all.
default Si cette variable est définie, elle identifie une entrée du menu qui devrait être par défaut. Peut être identifier par un numéro ou un titre.
fallback Si définie, identifie une entrée de menu qui devrait être sélectionnée si l'entrée par défaut échoue.
gfxmode Si définie, indique la résolution utilisée dans le terminal graphique gfxterm. Noter qu'il n'est possible d'utiliser que les modes VESA BIOS Extensions (VBE). défaut: auto.
gfxpayload contrôle le mode vidéo dans lequel Linux démarre. Remplace l'option de boot vga=. peut être 'text' pour forcer linux à booter en mode texte normal, 'keep' pour préserver le mode graphique définis avec gfxmode, ou une des valeurs permises pour gfxmode.
gfxterm_font nom d'une font à utiliser pour le texte dans le terminal graphique gfxterm.
grub_cpu En mode normal, GRUB définis cette variable au type de CPU pour lequel GRUB a été construit.
grub_platform En mode normal, GRUB définis cette variable à la platform pour laquelle GRUB a été construit (ex: pc ou efi)
icondir Répertoire dans lequel le menu graphique GRUB devrait rechercher les icônes, après avoir recherché dans le répertoire 'icons'
lang code de langue que la commande gettext utilise pour traduire les chaînes.
locale_dir Répertoire où trouver les fichiers de traduction, généralement /boot/grub/locale. sinon, l'internationnalisation est désactivée.
menu_color_highlight Contient les couleurs foreground et background à utiliser pour les entrées de menu sélectionnés, séparés par un '/'.
menu_color_normal Contient les couleurs à utiliser pour les entrée non-sélectionnés
net_* Voir la partie réseaux
pager À 1, pause la sortie après chaque écran plein et attend une entrée clavier.
prefix L'emplacement du répertoire /boot/grub. Normalement définis par GRUB
root Nom du périphérique root
superusers liste de noms de superutilisateurs pour activer le support de l'authentification
theme Répertoire contenant un theme graphique
timeout Spécifie le temps en seconde à attendre une entrée clavier avant de booter l'entrée par défaut. 0 indique de booter immédiatement, et -1, attend indéfiniment.
timeout_style Peut être menu, countdown, ou hidden.

Block d'environnement GRUB

   Il est souvent utile de se rappeler d'un boot à l'autre. Par exemple, l'entrée par défaut peut être celle sélectionnée la dernière fois. GRUB n'implémente pas délibérément le support pour écrire des fichiers afin de minimiser les risques de corruption des systèmes de fichier. Cependant, GRUB fournis un block d'environnement qui peut être utilisé pour sauver une petite quantité d'états.

   Le block d'environnement est un fichie 1024 octets préalloués, qui vis dans /boot/grub/grubenv. Au boot, load_env charge les variables depuis ce fichier, et save_env sauve les variables dans ce fichier. grub-editenv peut être utilisé pour éditer le block d'environnement.

   Pour des raisons de sécurité, ce stockage est seulement disponible si installé sur un simple disque (ni LVM ou RAID), en utilisant un système de fihier sans checksum (pas de ZFS), et en utilisant des fonction BIOS ou EFI (pas de ATA, USB ou IEEE1275).

   grub-mkconfig utilise cette facilité pour implémenté GRUB_SAVEDEFAULT

Liste de commandes disponible

   Les commandes appartiennent à différents groupes. Quelques commandes peuvent être utilisées dans la section globale du fichier de configuration (ou menu). La plupart d'entre-elles peuvent être entrée sur la ligne de commande et peut être utilisée soit dans le menu ou spécifiquement dans les entrées du menu.

   En mode récupération, seul insmod, ls, set, et unset sont normalement disponibles.

Commandes pour le menu uniquement

   Les sémantiques utilisées pour parser le fichier de configuration sont les suivantes:

- Les fichiers doivent être au format plain-text
- Les options sont séparés par des espaces
- Tous les nombres peuvent être en décimal ou en hexadécimal.
Ces commandes peuvent être seulement être utilisés dans le menu:


menuentry title [--class=class ...][--users=users][--unrestricted][--hotkey=key]{command;...} Définie une entrée du menu nommée title. --class peut être spécifié plusieurs fois, et est utilisée par les thèmes pour afficher différentes classes en utilisant différents styles. --users donne aux utilisateurs spécifiques l'accès à l'entrée. --unrestricted donne accès à tous les utilisateurs. --hotkey associe une touche avec l'entrée, ou 'backspace, tab ou delete.
submenu title [--class=class ...][--users=users][--unrestricted][--hotkey=key]{command;...} Définis un sous-menu.

   Liste des commandes générales, utilisée dans le menu et sur la ligne de commande:

serial [--unit=unit] [--port=port] [--speed=speed] [--word=word] [--parity=parity] [--stop=stop] Initialise un périphérique série. unit est un nombre de 0 à 3. Le port série n'est pas utilisé sauf si les commandes terminal_input et terminal_output sont utilisés.
terminal_input [--append|--remove] [terminal1] [terminal2] … Sélectionne un terminal d'entrée. Sans argument, liste les terminaux actifs et disponibles. --append ajoute les terminaux nommés à la liste de terminaux actifs. --remove supprime les terminaux nommés de la liste active.
terminal_output [--append|--remove] [terminal1] [terminal2] … Identique à terminal_output, mais pour les terminaux se sortie
terminfo [-a|-u|-v] [term] Définis les capacités de votre terminal en donnant le nom d'une entrée dans la base terminfo, qui devrait correspondre à une variable d'environnement TERM dans Unix. "vt100", "vt100-color", "ieee1275", et "dumb". Les options -a (--ascii), -u (--utf8), et -v (--visual-utf8) contrôlent comment le text non-ASCII est affiché.

   Liste des commande utilisable sur la ligne de commande et dans les entrées de menu

[ Alias de test
acpi [-1|-2] [--exclude=table1,…|--load-only=table1,…] [--oemid=id] [--oemtable=table] [--oemtablerev=rev] [--oemtablecreator=creator] [--oemtablecreatorrev=rev] [--no-ebda] filename … Les systèmes BIOS modern implémentent ACPI, et définissent diverses tables qui décrivent l'interface entre un OS conforme ACPI et le firmware. Dans certains cas, les tables fournies par défaut ne fonctionnent qu'avec certains OS, et il peut être nécessaire de les remplacer. Cette commande va remplacer le Root System Description Pointer (RSDP) dans le Extended BIOS Data Area pour pointer vers de nouvelles tables. Si --no-ebda est utilisé, les nouvelles tables seront connues uniquement de GRUB, mais peut être utilisé par l'émulation EFI de GRUB.
authenticate [userlist] Vérifie l'utilisateur dans userlist ou listé dans la variable superusers.
background_color color Définis la couleurs de fond pour le terminal actif. Ne peut être changé qu'en utilisant gfxterm
background_image [[--mode ‘stretch’|‘normal’] file] Charge l'image de fond pour le terminal actif depuis le fichier spécifié. Uniquement en utilisant gfxterm
badram addr,mask[,addr,mask...] Filtrer la mémoire endommagée. La syntaxe est la même que fournie par l'utilitaire memtest86+
blocklist file Affiche une liste de block pour le fichier donné.
boot La commande boot démarre un OS ou un chain-loader qui a été chargé.
cat [--dos] file Affiche le contenu d'un fichier. Si --dos est utilisé, les CR/NL sont affiché comme simple nouvelle ligne.
chainloader [--force] file Charge le fichier comme chain-loader. --force charge le fichier même si la signature est incorrect.
clear Éfface l'écran
cmosclean byte:bit Efface la varleur d'un bit dans le CMOS.
cmosdump contents Dump le contenu du CMOS en valeurs hexadécimal.
cmostest byte:bit Test la valeur d'un bit dans le CMOS.
cmp file1 file2 Compare 2 fichiers.
configfile file Charge le fichier de configuration spécifié, puis affiche le menu.
cpuid [-l] Vérifie les fonctionnalités CPU. Cette commande est seulement disponible sur les systèmes x86. -l retourne vrai si le CPU supporte le mode long (64-bits)
crc file Affiche le checksum CRC32 du fichier
cryptomount device|-u uuid|-a|-b Définis l'accès à un périphérique chiffré. -a monte tous les périphérique chiffrés détectés. GRUB supporte les disques chiffrés en utilisant LUKS et geli.
date [[year-]month-day] [hour:minute[:second]] Sans argument, affiche l'heure et la date courante. Sinon prend la date et l'heure courante, change un élément spécifié et définis le résultat comme nouvelle date et heure.
devicetree file Charge le dtb depuis un système de fichier, pour le passer à Linux.
distrust pubkey_id Supprime la clé publique donnée du jeu de clé de GRUB. pubkey_id est les 4 derniers octets en hexa de l'id de clé GPG v4, qui est également la sortie de list_trusted. L'id de clé peut être obtenu avec gpg --fingerprint. Ces clés sont utilisées pour valider les signatures.
drivemap -l|-r|[-s] from_drive to_drive Sans option, map le lecteur from_drive au lecteur to_drive. C'est nécessaire pour chain-load certains OS, comme DOS. -s inverse le mappage, inversant 2 disques. -l liste les mappages courant. -r réinitialise tous les mappages
echo [-n] [-e] string … Affiche le texte demandé et, sauf si l'option -n est utilisée, une nouvelle ligne. -e autorise l'interprétation des caractères échappé.
eval string ... Concatène les arguments ensemble en utilisant un simple espace comme séparateur et évalue de résultat comme séquence de commandes GRUB.
export envvar Exporte la variable d'environnement envvar. Les variables exportée sont visible aux fichiers de configurations chargés avec configfile
false Ne fait rien, se termine avec un code de sortie false
gettext string Traduit la chaîne donnée dans la langue courante. La langue courant est stockée dans la variable lang.
gptsync device [partition[+/-[type]]]... Les disques utilisant une table de partition GUID ont également une table de partition MBR pour compatibilité avec le BIOS et avec d'anciens OS. Les MBR peut seulement représenter un sous-jeu limité d'entrées de partitions GPT. Cette commande popule le MBR avec les entrées de partition spécifiés sur le périphérique. Jusqu'à 3 partitions peuvent être utilisée. 'type' est un code de type de partition MBR, [+/-] rend la partition active ou non.
halt --no-apm arrête l'ordinateur. Si l'option --no-apm est spécifiée, aucun appel APM n'est effectué. Sinon, l'ordinateur est éteint en utilisant APM.
hashsum --hash hash --keep-going --uncompress --check file [--prefix dir]|file … Calcule ou vérifie les hashes des fichier. (adler32, crc64, crc32, crc32rfc1510, crc24rfc2440, md4, md5, ripemd160, sha1, sha224, sha256, sha512, sha384, tiger192, tiger, tiger2, whirlpool.
help [pattern ...] Affiche des informations sur les commandes intégrées.
initrd file Charge le ramdisk initial pour une image kernel Linux et définis les paramètres appropriés dans la zone de configuration de Linux. Peut seulement être spécifiée après la commande linux.
initrd16 file Identique, mais pour un ramdisk initiale en mode 16bits.
insmod module Charge un module GRUB
keystatus [--shift][--ctrl][--alt] Retourne true si les touches Shift, Control, ou Alt sont enfoncée, comme requis par les options. Utile dans les scripts pour permettre un certain contrôle utilisateur sur le comportement sans avoir à attendre une touche.
linux file Charge l'image Linux. Le reste de la ligne de commande est passée telle quelle au kernel.
linux16 file Idem mais charge un kernel en mode 16bits.
list_env -f file Liste toutes les variables dans le fichier block d'environnement. -f écrase l'emplacement par défaut du block d'environnement.
load_env -f file Charge toutes les variables depuis le fichier block d'environnement dans l'environnement.
loadfont file Charge les fonts spécifiées.
loopback -d device file Charge le contenu d'un fichier comme périphérique. -d pour le supprimer. ex loopback loop0 /path/to/image; ls (loop0)/
ls [arg ...] Liste des périphériques ou fichiers.
lsfonts Liste les fonts chargées
lsmod Liste les modules chargés
md5sum alias de hashsum --hash md5 arg …
module [--nounzip] file [arguments] Charge un module pour l'image kernel multiboot. Le reste de la ligne est passé comme ligne de commande du module.
multiboot [--quirk-bad-kludge] [--quirk-modules-after-kernel] file … Charge l'image kernel multiboot depuis le fichier spécifié. Le reste de la ligne est passé au kernel comme ligne de commande.
nativedisk switch d'un pilote de disque firmware à un natif.
normal [file] Entre en mode normal et affiche le menu GRUB. En mode normal, les commandes, modules de système de fichier, et modules cryptographique sont automatiquement chargés, et le parser de script GRUB est disponible. Si un fichier est donné, les commandes seront lues depuis ce fichier, sinon elles sont lues depuis $prefix/grub.cfg, s'il existe.
normal_exit sort du mode normal. Si cette instance du mode normal n'a pas été imbriqué dans un autre, retourne en mode rescue.
parttool partition commands Effectue diverses modifications des entrées de la table de partition. Chaque command est soit un booléen, auquel cas il doit être suivi avec + ou -, pour activer ou désactiver cette option, ou peut prendre une valeur sous la forme command=value.
password user clear-password Définir un utilisateur nommé user avec le mot de passe donné.
password_pbkdf2 user hashed-password Définis un utilisateur nommé user avec le mot de passe hashé. Utiliser grub-mkpasswd-pbkdf2 pour générer des hashs de mot de passe.
play file | tempo [pitch1 duration1][pitch2 duration2]... Jouer un son. Si l'argument est un nom de fichier, joue le fichier.
probe [--set var] --driver|--partmap|--fs|--fs-uuid|--label device Récupère des informations de périphérique. --set assigne le résultat à la variable var, sinon affiche l'information à l'écran.
pxe_unload Décharge l'environnement PXE.
read [var] Lit une ligne d'entrée de l'utilisateur. Si une variable var est donnée, définis cette variable d'environnement.
reboot Redémarre la machine
regexp [--set [number:]var] regexp string Test si l'expression régulière matche la chaîne.
rmmod module Supprime un module chargé
save_env [-f file] var ... Sauve les variables nommée depuis l'environnement dans le fichier block d'environnement.
search [--file|--label|--fs-uuid] [--set [var]] [--no-floppy] name Recherche des périphérique par fichier (-f, --file) label de système de fichier (-l, --label), ou UUID de système de fichier (-u, --fs-uuid). Avec --set, la variable var est définis avec le premier périphérique trouvé. La variable par défaut est root. --no-floppy empêche de recherche les périphérique disquette. les commandes search.file, search.fs_label, et search.fs_uuid sont des alias de search --file, search --label, et search --fs-uuid, respectivement.
sendkey [--num|--caps|--scroll|--insert|--pause|--left-shift|--right-shift|--sysrq|--numkey|--capskey|--scrollkey|--insertkey|--left-alt|--right-alt|--left-ctrl|--right-ctrl ‘on’|‘off’]… [no-led] keystroke Insert des touches dans le tampon clavier en bootant. certains OS ou chain-loader nécessitent que des touches particulières soient pressées pour entrer en mode safe. Jusqu'à 16 touches peuvent être fournis. Les noms des touches peuvent être:

Name   Key
escape            Escape
exclam            !
at            @
numbersign            #
dollar            $
percent            %
caret            ^
ampersand            &
asterisk            *
parenleft            (
parenright            )
minus            -
underscore            _
equal            =
plus            +
backspace            Backspace
tab            Tab
bracketleft            [
braceleft            {
bracketright            ]
braceright            }
enter            Enter
control            press and release Control
semicolon            ;
colon            :
quote            ’
doublequote            "
backquote            ‘
tilde            ~
shift            press and release left Shift
backslash            \
bar            |
comma            ,
less            ‹
period            .
greater            ›
slash            /
question            ?
rshift            press and release right Shift
alt            press and release Alt
space            space bar
capslock            Caps Lock
F1            F1
F2            F2
F3            F3
F4            F4
F5            F5
F6            F6
F7            F7
F8            F8
F9            F9
F10            F10
F11            F11
F12            F12
num1            1 (numeric keypad)
num2            2 (numeric keypad)
num3            3 (numeric keypad)
num4            4 (numeric keypad)
num5            5 (numeric keypad)
num6            6 (numeric keypad)
num7            7 (numeric keypad)
num8            8 (numeric keypad)
num9            9 (numeric keypad)
num0            0 (numeric keypad)
numperiod            . (numeric keypad)
numend            End (numeric keypad)
numdown            Down (numeric keypad)
numpgdown            Page Down (numeric keypad)
numleft            Left (numeric keypad)
numcenter            5 with Num Lock inactive (numeric keypad)
numright            Right (numeric keypad)
numhome            Home (numeric keypad)
numup            Up (numeric keypad)
numpgup            Page Up (numeric keypad)
numinsert            Insert (numeric keypad)
numdelete            Delete (numeric keypad)
numasterisk            * (numeric keypad)
numminus            - (numeric keypad)
numplus            + (numeric keypad)
numslash            / (numeric keypad)
numenter            Enter (numeric keypad)
delete            Delete
insert            Insert
home            Home
end            End
pgdown            Page Down
pgup            Page Up
down            Down
up            Up
left            Left
right            Right

set [envvar=value] Définis la variable envvar à la valeur spécifiée. Sans argument, affiche les variables d'environnement
sha1sum Alias de hashsum --hash sha1 arg …
sha256sum Alias de hashsum --hash sha256 arg …
sha512sum Alias de hashsum --hash sha512 arg …
sleep [--verbose] [--interruptible] count Attend count seconde. --interruptible permet à ESC d'intérompre. --verbose affiche un décompte.
source file Lit le fichier comme fichier de configuration, et son conteneu est incorporé directement dans le fichier source. À la différence de configfile, exécute le contenu du fichier sans changer le contexte.
test expression Évalue l'expression et retourne un code de sortie. Similaire à la commande test de bash.
true Ne fait rien, retourne true.
trust [--skip-sig] pubkey_file Lit la clé publique et l'ajoute au jeu de clé de GRUB.
unset envvar Indéfinis la variable d'environnement donnée
uppermem Cette commande n'est pas encore implémentée
verify_detached [--skip-sig] file signature_file [pubkey_file] Vérifie une signature détaché style GPG du fichier donné.
videoinfo [[WxH]xD] Liste les modes vidéo disponibles.
net_add_addr interface card address Ajoute une adresse réseau
net_add_dns server Ajoute un serveur DNS
net_add_route shortname ip[/prefix] [interface | ‘gw’ gateway] Ajoute une route
net_bootp [card] Effectue une autoconfiguration bootp
net_del_addr interface Supprime une adresse IP de l'interface
net_del_dns address Supprime un serveur DNS
net_del_route shortname Supprime une route
net_get_dhcp_option var interface number type Récupère les options DHCP
net_ipv6_autoconf [card] Effectue une autoconfiguration IPv6
net_ls_addr Liste les interfaces
net_ls_cards Liste les cartes réseaux
net_ls_dns Liste les serveurs DNS
net_ls_routes Liste les routes
net_nslookup name [server] Effectue des recherches DNS

Jeux de caractères

   GRUB utilise UTF-8 en interne. Tous les fichiers texte, incluant les configuration, sont supposés être encodés en UTF-8.

  GRUB supporte la traduction. Pour cela il faut avoir des fichiers *.mo dans $prefix/locale, charger le module gettext et définir la variable lang.

Authentification et autorisation

   Par défaut, l'interface est accessible à tout le monde avec un accès physique à la console: tout le monde peut sélectionner et éditer une entrée du menu, et tout le monde a un accès directe à un prompt shell. Pour la plupart des systèmes, c'est raisonnable vu qu'avec un accès physique il existe d'autres manière d'avoir un accès complet.

   Cependant, dans certains environnements, tels que les kiosques, il peut être approprié de bloquer le boot loader pour exiger une authentification avant d'effectuer certaines opérations.

   Les commandes password et password_pbkdf2 peuvent être utilisées pour définir les utilisateurs, chacun ayant un mot de passe associé. password définis le mot de passe en clair, ce qui exige que grub.cfg soit sécurisé; password_pbkdf2 définis le password hashé en utilisant la rfc2898, qui nécessite l'utilisation de grub-mkpasswd-pbkdf2 pour générer les hashs.

   Pour activer l'authentification, la variable superusers doit être définis à la liste des nom d'utilisateurs séparés par des espaces, ',', ';' ou '|'. Les superusers sont autorisés à utiliser la ligne de commande, éditer les entrées du menu, et exécuter une entrée du menu.

Les autres utilisateur peuvent avoir accès aux entrée de menu spécifique en donnant une liste d'utilisateurs en utilisant l'option --users de la commande menuentry. Si l'option --unrestricted est utilisée pour une entrée de menu, cette entrée n'est pas restreinte. Si l'option --users n'est pas utilisée pour une entrée de menu, seul les superusers y ont accès. Exemple:
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.biglongstring
password user1 insecure
    
menuentry "May be run by any user" --unrestricted {
    set root=(hd0,1)
    linux /vmlinuz
}
    
menuentry "Superusers only" --users "" {
    set root=(hd0,1)
    linux /vmlinuz single
}
    
menuentry "May be run by user1 or a superuser" --users user1 {
    set root=(hd0,2)
    chainloader +1
}

   Le programme grub-mkconfig n'a pas encore le support pour générer des fichiers de configuration avec l'authentification. Vous pouvez utiliser /etc/grub.d/40_custom pour ajouter une simple authentification superusers, en ajoutant set superusers= et password ou password_pbkdf2.

Utiliser des signatures numériques dans GRUB

   core.img peut optionnellement fournir la vérification de tous les fichiers lus. Ce document ne couvre pas commen s'assurer que le firmware de la plateform (ex: coreboot) valide core.img.

   Si la variable check_signatures est à 'enforce', toute tentative de core.img de charger un autre fichier implique d'invoquer verify_detached foo foo.sig. foo.sig doit contenir une signature valide pour le fichier foo.

GRUB utilise les signatures détachée type GPG, et supporte actuellement DSA et RSA. Une clé de signature peut être générée en utilisant
gpg --gen-key
Un fichier peut être signé avec
gpg --detach-sign /path/to/file

Pour une validation complète de tous les sous-composants et le kernel chargé, ils doivent tous être chargés. Cela peut être fait pas grub-mkconfig:
# Edit /dev/shm/passphrase.txt to contain your signing key's passphrase
for i in `find /boot -name "*.cfg" -or -name "*.lst" -or \
    -name "*.mod" -or -name "vmlinuz*" -or -name "initrd*" -or \
    -name "grubenv"`;
do
    gpg --batch --detach-sign --passphrase-fd 0 $i ‹ /dev/shm/passphrase.txt
done
shred /dev/shm/passphrase.txt

^
19 octobre 2013

htmlpdflatexmanmd




gsasl

gsasl

CLI pour libgsasl

OPTIONS

-c, --client Agit comme client
--client-mechanism Mécanismes supportés par le client
-s, --server Agit comme serveur
--server-mechanism Mécanismes supportés par le serveur
--connect=HOSTNAME[:SERVICE] Serveur distant.
-d, --application-data Après l'authentification lis les données de stdin et le lance dans la couche de sécurité du mécanisme puis l'affiche en base64.
--imap Utilise la procédure de login style IMAP
-m, --mechanism=STRING mécanisme à utiliser
--no-client-first Empêche le client d'envoyer les info en premier (client only)
-n, --anonymous-token=STRING Token pour l'authentification anonyme, générallement l'addresse email.(ANONYMOUS only)
-a, --authentication-id=STRING Identité du propriétaire des acréditations
-z, --authorization-id=STRING Identité de demandeur
--disable-cleartext-validate Désactive la validation cleartext, force le serveur à demander le mot de passe
--enable-cram-md5-validate Valide les challenge/réponse CRAM-MD5 intéractivement
--hostname=STRING Nom du serveur avec le service requis
-p, --password=STRING Mot de passe pour l'authentification
--passcode=NUMBER Passcode pour l'authentification (SECURID only)
--quality-of-protection=‹qop-auth | qop-int | qop-conf› Protection du payload. qop-auth: pas de protection, qop-int: protection de l'intégrité, qop-conf: confidentitalité
-r, --realm=STRING Royaume
--service=STRING Nom du service requis
--service-name=STRING Nom du serveur en cas de serveur répliqué (DIGEST-MD5 only)
-x, --maxbuf=NUMBER Taille de buffer max (DIGEST-MD5 only)
--starttls Force l'utilisation de starttls
--no-starttls désactive starttls
--no-cb Ne définis pas de chanel binding
--x509-ca-file=FILE Fichier contenant les certificats des CA
--x509-cert-file=FILE Fichier contenant le certificat du client
--x509-key-file=FILE Fichier contenant la clé privée du client
--priority Chaîne de priorité de chiffrement
-Q, --QUIET, --SILENT mode silencieux
-v, --verbose mode verbeux
^
31 mai 2010

htmlpdflatexmanmd




halt

halt, reboot, poweroff

Redémarrer, arrêter ou éteindre le système

   Ces programme permettent de redémarrer, arrêter ou éteindre le système. Appelé avec --force ou en runlevel 0 ou 6, cet outil invoque l'appel système reboot(2) et redémarre directement le système. Sinon, il appel simplement shutdown avec les arguments appropriés.

OPTIONS

-f, --force N'invoque pas shutdown.
-p, --poweroff dit à halt d'agir comme poweroff
-w, --wtmp-only n'appel pas shutdown ou reboot et écrit seulement l'enregistrement dans /var/log/wtmp
--verbose Mode verbeux
^
27 mai 2016

htmlpdflatexmanmd




hash-to-efi-sig-list

hash-to-efi-sig-list

Créer une entrée de liste de signature de hash depuis un binaire

   Produit un fichier de liste de signature EFI contenant le hash SHA256 du binaire EFI

Exemples

Créer un fichier avec le binaire HelloWorld.efi, pour la placer dans les variables db avec UpdateVar
hash-efi-sig-list HelloWorld.efi hash.esl
^
20 juin 2016

htmlpdflatexmanmd




haveged

haveged

Génération de nombres aléatoires

   haveged génère un flux imprédictible de nombres aléatoires depuis les effets indirects des événements hardware sur l'état caché (caches, prédicteurs de branche, tables de traduction mémoire, etc) en utilisant l'argorithme HAVEGE (HArdware Volatile Entropy Gathering and Expansion). L'algorithme opère en userspace, sans privilèges spéciaux.

   Linux utilise les interfaces /dev/random et /dev/urandom pour fournir des nombres aléatoire. Les mécanismes standard pour remplir /dev/random peuvent ne pas être suffisants pour répondre à la demande du système. Dans ces circonstances haveged peut être lancé comme services privilégié pour remplir /dev/random.

OPTIONS

-b nnn, --buffer=nnn Définis la taille du tampon en KW. (défaut: 128KW = 512Kio)
-d nnn, --data=nnn Définis la taille du cache de données en Ko. Défaut: 16 ou déterminé dynamiquement
-f file, --file=file Définis le fichier une utilisation non-service. Défaut: "sample"
-F, --foreground Ne lance pas en tâche de fond
-i nnn, --inst=nnn Taille du cache d'instruction en Ko. Défaut: 16 ou déterminé dynamiquement
nnn, --number=nnn Nombre d'octets écris dans le fichier de sortie.
-o ‹spec›, --onlinetest=‹spec› Spécifie les tests online à lancer ‹spec› consiste de groupes optionnels "t"ot et "c"ontinuous, chaque groupe indiquant les procédures à lancer, utilisant "a‹n›" pour indiques une procédure AIS-31 variante A, et "b" pour indiques la procédure B. Les spécification sont indépendante de l'ordre. Les tests "tot" sont lancés seulement à l'initialisation. En test continue, la séquence de test est cyclique.
-p file, --pidfile=file Définis le chemin du fichier pid. Défaut: /var/run/haveged.pid
-r n, --run=n Définis le niveau d'exécution pour le service. 0=lance en service, doit être root. 1=Affiche la configuration et se termine. ؏, écris N Kio sur la sortie. déprécié, utiliser --number
-v n, --verbose=n Diagnostique. -1 signifie tous les diagnostiques (défaut0):

        1 Affiche le sommaire build/tunning en se terminant
        2 Affiche les détails de retentatives de test online
        4 Affice le timing pour les collection
        8 Affiche a couche de boucle de collection
        16 Affiche les offsets de code de boucle de collection
        32 Affiche tous les détails de tests online terminés

-w nnn, --write=nnn Définis le write_wakeup_threshold de l'interface à nnn bits. uniquement en run level 0.

NOTES

   haveged définis l'algorithme HAVEGE pour une efficacité maximum en utilisant un hiérarchie de défauts, options de ligne de commande, informations de système de fichier virtuel, et informations cpuid si disponible. Sous certaines circonstances, l'entrée utilisateur n'est pas requise pour d'excellents résultats.

   Les tests run-time fournissent l'assurance des opérations de haveged. La suite de test est modélisée sur la spécification AIS-31 du German Common Criteria, BIS. Cette spécification est typiquement appliquée aux périphériques aléatoires, nécessitant une certification formelle. Parce qu'haveged tourne sur différentes plateformes hardware, la certification ne peut pas être un but, mais la suite de test AIS-31 fournis un moyen de valider la sortie de haveged avec les même tests opérationnels appliqués aux périphériques hardwares certifiés.

Fichiers

   Si haveged est lancé en tant que service, les fichiers suivants sont requis:

/dev/random
/proc/sys/kernel/osrelease
/proc/sys/kernel/random/poolsize
/proc/sys/kernel/random/write_wakeup_threshold

Exemples

Écrire 1,5Mo de données aléatoirs dans /tmp/random
haveged -n 1.5M -f /tmp/random
Générer un /tmp/keyfile pour le chiffrement de disque avec LUKS
haveged -n 2048 -f /tmp/keyfile
Écraser la partition /dev/sda1 avec des données aléatoires
haveged -n 0 | dd of=/dev/sda1
Générer des mots de passe ASCII aléatoires de 16 caractères
(haveged -n 1000 -f - 2›/dev/null | tr -cd '[:graph:]' | fold -w 16 && echo ) | head
Écrire un flux d'octets dans un pipe. pv mesure la vitesse d'écriture dans le pipe
haveged -n 0 | pv › /dev/null
Évaluer la vitesse de génération de 1Go de données aléatoires
haveged -n 1g -f - | dd of=/dev/null
Créer un fichier clé aléatoire contenant 65 clé aléatoire pour le programme de chiffrement aespipe
haveged -n 3705 -f - 2›/dev/null | uuencode -m - | head -n 66 | tail -n 65
Tester la qualité des données générée avec la suite de test dieharder
haveged -n 0 | dieharder -g 200 -a
Générer 16k de données, tester avec la procédure A et B avec résultats détaillés.
haveged -n 16k -o tba8ca8 -v 33
Génèrer également 16k de données avec un buffer plus grand. Le test c peut être complété
haveged -n 16k -o tba8ca8 -v 33 -b 512
^
07 juin 2010

htmlpdflatexmanmd




head

head

Affiche la première partie de chaque fichier - 10 lignes par défaut

   Si plusieurs fichiers sont spécifiés, head affiche un en-tête d'une ligne affichant le nom du fichier sous la forme :

  ==› FILE NAME ‹==

OPTIONS

-c N, --bytes=N Affiche les N premiers octets au lieu de lignes. Si N commence avec un '-', affiche tout sauf les derniers N octets de chaque fichier. N accèpte un suffixe multiplicateur.
N, --lines=N Sort les première N lignes. Identique à l'options -c
-q, --quiet, --silent N'affiche pas les en-têtes
-v, --verbose affiche toujours les en-têtes
^
18 mars 2016

htmlpdflatexmanmd




host

host

Utilitaire pour effectuer des recherches DNS

   host est un utilitaire simple pour effectuer des recherches DNS. Il est normalement utilisé pour convertir des noms en IP et vice versa.

OPTIONS

-a Equivalent à l'option -v pour une requête ANY
-C tente d'afficher les records SOA pour la zone
-c Spécifie la classe de la requête.
-v, -d mode verbeux
-l mode liste, effectue un transfert de zone. affiche les records NS, PTR A/AAAA
-i les recherches inversées IPv6 doivent utiliser le domaine IP6.INT au lieu de IP6.ARPA
-N Définis le nombre de point qui est considéré comme absolu dans le nom. Si non spécifié, utilise l'option ndots dans /etc/resolv.conf
-R indique combien de fois host va répéter une requête
-r effectue des requêtes non-recursives
-T Utilise TCP pour les requêtes
-4 utilise IPv4 uniquement
-6 utilise IPv6 uniquement
-t type de la requête
-W délai maximum d'attente d'une réponse
-w attend indéfiniment la réponse.
-s n'envoie pas la requête au serveur suivant si le premier répond par un SERVFAIL
-m Définis les flags de debuggage d'utilisation mémoire record, usage et trace
^
11 février 2012

htmlpdflatexmanmd




host.conf

host.conf

Fichier de configuration du resolveur. Il doit contenir une paire clé/valeur par ligne.

Mots clés

order Spécifie comment les recherches de l'hôte doivent être exécutée. (valeur : bind, hosts, et nis)
trim Doit être suivi par une liste de domaines, séparés par ';' ou ',' et un point de terminaison. la librairie resolv+ utilise le nom de domaine donné depuis la fin d'un nom d'hôte résolu via DNS. Utilisé avec les hôtes et domaines locaux. N'affecte pas les noms d'hôte récupérés via NIS. Peut être spécifié plusieurs fois.
multi on|off à on, resolv+ retourne toutes les adresses valides pour un hôte qui apparaît dans /etc/hosts au lieu du premier.
nospoof on|ff à on, resolv+ tente d'empêcher le spoofing de nom d'hôte pour améliorer la sécurité de rlogin et rsh.
spoofalert on|off à on et avec nospoof à on, resolv+ log les erreurs dans syslog
spoof off|nowarn|warn à off, les adresse spoofée sont permises sans logger les erreurs. à warn, resolv+ empêche le spoofing de nom d'hôte et log les erreurs, à nowarn, empêche le spoofing mais ne log rien.
reorder on|off à on, resolv+ tente de réordonner les adresses d'hôte pour que les adresses locales soient listée en premier.

Environnement

   Ces variables permettent de remplacer les valeurs de /etc/host.conf

RESOLV_HOST_CONF pointe vers le fichier à lire au lieu de /etc/host.conf
RESOLV_SERV_ORDER Remplace la commande order
RESOLV_SPOOF_CHECK Remplace les commandes nospoof, spoofalert et spoof de la même manière que la commande spoof
RESOLV_MULTI Remplace la commande multi
RESOLV_REODER Remplace la commande reorder
RESOLV_ADD_TRIM_DOMAINS Une liste de domaines, séparés par ';' , ':' ou ',', qui sont ajouté à la liste des domaines.
RESOLV_OVERRIDE_TRIM_DOMAINS Une liste de domaines, séparés par ';' , ':' ou ',', qui remplacent la liste des domaines de la commande trim+
^
22 juin 2016

htmlpdflatexmanmd




hostapd

hostapd

Authentificateur IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS

   hostapd est un service en userspace pour les points d'accès et les serveurs d'authentification. Il implémente la gestion de point d'accès, IEEE 802.1X/WPA/WPA2/EAP et RADIUS.

  hostapd est conçu pour être un service qui agit comme backend contrôlant l'authentification. hostapd support les programmes frontend séparé.

OPTIONS

-d, -dd Mode debug
-B Lance en tâche de fond
-P ‹PID› Spécifie le fichier pid du process
-K Inclus les données de clé dans les messages de debuggage
-t Inclus l'horodatage dans les messages de debuggage
^
22 juin 2016

htmlpdflatexmanmd




hostapd_cli

hostapd_cli

Interface de gestion pour hostapd

OPTIONS

-p‹path› Chemin où trouver les sockets de contrôle. Défaut: /var/run/hostapd
-i‹ifname› Interface d'écoute. Défaut: la première interface trouvée dans le chemin des sockets
-a‹path› Lance en mode service en exécutant le fichie d'action spécifié basé sur les événements de hostapd
-B Lance en tâche de fond
-G‹ping interval›

Commandes

mib Récupère les variables MIB (dot1x, dot11, radius)
sta ‹addr› Récupère les variables MIB pour une station
all_sta Récupère les variables MIB pour toutes les stations
new_sta ‹addr› Ajoute une nouvelle station
deauthenticate ‹addr› Désauthentifie une station
disassociate ‹addr› Désassocie une station
sa_query ‹addr› Envoie un SA Query à une station
wps_pin ‹uuid› ‹pin› [timeout] [addr] Ajoute un WPS Enrollee PIN
wps_check_pin ‹PIN› Verify le checksum du PIN
wps_pbc indique un bouton poussé pour initier PBC
wps_cancel Annule une opération WPS en attente
wps_nfc_tag_read ‹hexdump› Reporte le tag NFC avec donnée WPS
wps_nfc_config_token ‹WPS/NDEF› Génère le token de configuratio NFC
wps_nfc_token ‹WPS/NDEF/enable/disable› Gère le token de mot de passe NFC
wps_ap_pin ‹cmd› [params..] Active/désactive AP PIN
wps_config ‹SSID› ‹auth› ‹encr› ‹key› Configure AP
wps_get_status Affiche le status WPS courant
get_config Affiche la configuration actuelle
interface [ifname] Affiche/sélectionne l'interface
level ‹debug level› Change le niveau de débug
quit Quitter hostapd_cli
^
14 juillet 2010

htmlpdflatexmanmd




hostid

hostid

Affiche l'id de l'hôte

   hostid affiche l'identifiant numérique de l'hôte courant. Sur ce système, cette valeur est proche de l'adresse Internet du système, mais ce n'est pas toujours le cas

^
03 novembre 2011

htmlpdflatexmanmd




hostname

hostname, domainname, ypdomainname, nisdomainname, dnsdomainname

Affiche le nom d’hôte ou le domaine du système

hostname affiche ou définis le nom d’hôte
domainname Affiche ou définis le domaine NIS du système
ypdomainname Affiche ou définis le domaine NIS du système
nisdomainname Affiche ou définis le domaine NIS du système
dnsdomainname affiche le domaine dns du système

Afficher le nom

   Sans argument, ces commandes affiche le nom d’hôte ou le domaine du système

Définir le nom

   Appelé avec un argument ou avec l’option --file, ces commandes définissent le nom d’hote ou le domaine du système. Noter que ce n’est effectif que jusqu’au reboot du système.

  Le nom d’hôte est généralement définis une fois au démarrage du système dans /etc/init.d/hostname.sh (normalement lit le fichier /etc/hostname)

OPTIONS

-a, --alias Affiche le nom alias de l’hôte. dépréciée
-b, --boot toujours définir le nom d’hôte. S’il n’est pas spécifié, utilise localhost
-d, --domain Affiche le domaine DNS
-F, --file Le le nom d’hôte depuis le fichier spécifié
-f, --fqdn, --long Affiche le fqdn.
-A, --all-fqdns Affiche tous les fqdn de la machine.
-i, --ip-address Affiche les addresses réseau de l’hôte. Ne fonctionne que si le nom peut être résolu
-I, --all-ip-addresses Affiche toutes les adresses réseau de l’hôte
-s, --short Affiche le nom court
-v, --verbose mode verbeux
-y, --yp, --nis Affiche le domaine NIS

Fichiers

/etc/hostname Contient le nom d'hôte de la machine
^
31 mars 2016

htmlpdflatexmanmd




hostnamectl

hostnamectl

Contrôle le nom d'hôte système

   Cet outil distingue 3 types de noms d'hôtes: le nom "haut niveau", qui peut inclure des caractères spéciaux (ex : Lennart’s Laptop), le nom d’hôte statique, qui est utilisé pour initialiser le nom d’hôte kernel (ex : Lennarts-laptop), et le nom d’hôte transitoire qui peut être assigné temporairement dût à la configuration réseau

OPTIONS

--no-asp-password Ne demande pas d’authentification pour les opérations privilégiées
--static (/etc/hostname)
--transient (/proc/sys/kernel/hostname)
--pretty (/etc/machine-info)
-H, --hostname exécute l’opération a distance. Utilise SSH pour dialoguer.
-M, --machine= Exécute l'opération dans un conteneur local.

Commandes

status Affiche les informations de nom d'hôte système actuel.
set-hostname [NAME] Définis le nom d’hôte
set-icon-name [NAME] Définis l’icône système, utilisé par certaines applications graphique.
set-chassis [TYPE] Définis le type de chassis, utilisé par certaines applications graphique (desktop,laptop, server, tablet, handset, watch, embedded, vm et container)
set-deployment ENVIRONMENT Définis la description d'environnement de déploiement. suggéré: development, integration, staging, production.
set-location LOCATION Définis l'emplacement pour le système. peut être "Berlin, Germany", ou "Left Rack, 2nd Shelf"
^
26 janvier 2014

htmlpdflatexmanmd




iceauth

iceauth

iceauth est utilisé pour éditer et afficher les informations d'autorisation utilisés pour se connecter avec ICE. Ce programme est généralement utilisé pour extraire les informations d'une machine et les fusionner avec une autre.

OPTIONS

-f authfile Spécifie le nom du fichier à utiliser
-q mode silencieux. N'affiche pas de messages de status non sollicité.
-v Augmente la verbosité
-i Ignore les locks sur les fichiers d'autorisation
-b Tente de casser tout lock sur le fichier avant de le traiter
-u Affiche les instructions de base

Commandes

info Informations décrivant le fichier d'autorisation
list [ protocol_name ] [ protocol_data ] [ netid ] [ authname ] Liste les entrées dans le fichier d'autorité.
add protocol_name protocol_data netid authname authdata Ajoute une entrée dans le fichier l'autorité
remove [ protocol_name ] [ protocol_data ] [ netid ] [ authname ] Supprime une entrée dans le fichier l'autorité
extract filename [ protocol_name ] [ protocol_data ] [ netid ] [ authname ] Extrait les entrées du fichier dans un fichier de destination
merge filename1 [ filename2 ] [ filename3 ] ... Fusionne les entrées d'autres fichiers dans le fichier d'autorité
exit Ecrit les modifications et quitte
quit Quitte en ignorant les modifications
? Liste les commandes disponibles
source source filename Lit et exécute les commandes depuis le fichier
^
13 juillet 2010

htmlpdflatexmanmd




id

id

id affiche des informations sur l'utilisateur donné, ou l'utilisateur qui lance id si aucun argument n'est spécifié.

   Par défaut, id affiche le real user ID, real group ID, l'effective user ID s'il est différent, l'effective group ID s'il est différent et les ID de groupes supplémentaires.

OPTIONS

-g, --group Affiche seulement le group ID
-G, --groups Affiche seulement le group ID et les groupes supplémentaires.
-n, --name Affiche l'utilisateur ou le groupe au lieu des ID. s'utilise avec -u, -g ou -G.
-r, --real Affiche le real user ID et ou le real group ID au lieu de l'effectif. s'utilise avec -u, -g ou -G.
-u, --user Affiche seulement l'ID de l'utilisateur
-Z, --context Affiche seulement le contexte de sécurité de l'utilisateur courant, si SELinux est activé.
^
05 décembre 2016

htmlpdflatexmanmd




idmapd.conf

idmapd.conf

Fichier de configuration pour libnfsidmap

   Le fichier de configuration idmapd.conf consiste de nombreuses sections.

[General]

Verbosity Niveau de verbosité. défaut: 0
Domain Nom de domain local NFSv4
Local-Realms Liste de royaumes kerberos qui peuvent être considérés équivalent au nom de royaume local.

[Mapping]

Nobody-User Nom d'utilisateur local utilisé quand un mappage ne peut pas être trouvé
Nobody-Group Nom du groupe local utilisé quand un mappage ne pas être trouvé

[Translation]

Method Liste ordonnée de méthodes de mappage à utiliser entre les noms NFSv4 et les ID locaux. (nsswitch, umich_ldap, static)
GSS-Methods Liste ordonnée de méthodes de mappage à utiliser entre les noms authentifiés GSS et les ID locaux. Défaut: identique à Method

[Static]

   La méthode de traduction static liste les noms GSS-Autheticated en noms d'utilisateurs locaux. les entrées sont sous la forme: principal@REALM = localusername

[UMICH_SCHEMA]

LDAP_server Nom du serveur LDAP
LDAP_base Base de recherche
LDAP_people_base Base de recherche pour les comptes utilisateurs
LDAP_group_base Base de recherche pour les groupes
LDAP_canonicalize_namo Indique si les nom sont canonisés. Défaut: true
LDAP_use_ssl Active le chiffrement de la communication
LDAP_ca_cert Emplacement du certificat CA
NFSv4_person_objectclass ObjectClass pour les comptes utilisateurs. Defaut: NFSv4RemotePerson
NFSv4_name_attr Nom de l'attribut pour les noms des utilisateurs nfsv4. Défaut: NFSv4Name
NFSv4_uid_attr Nom de l'attribut maintenant l'UID. Défaut: uidNumber
GSS_principal_attr Nom de l'attribut pour les principaux GSSAPI. Défaut: GSSAuthName
NFSv4_acctname_attr Nom de l'attribut utilisé pour les noms de compte. Défaut: uid
NFSv4_group_objectclass objectClass pour les groupes. Défaut: NFSv4RemoteGroup
NFSv4_gid_attr Attribut pour le GID. Défaut: gidNumber
NFSv4_group_attr Atribut pour les noms des groupes NFSv4. Défaut: NFSv4Name
LDAP_use_memberof_for_groups à true, utilise le 'memberof' du compte pour trouver les groupes et obtenir les GID
NFSv4_member_attr Indique l'attribut à rechercher pour l'option LDAP_use_memberof_for_groups. Défaut: memberUid
NFSv4_grouplist_filter Filtre de recherche optionnel pour déterminer le groupe membership.
LDAP_timeout_seconds Délai pour les requêtes LDAP. Défaut: 4
^
17 mars 2010

htmlpdflatexmanmd




ifconfig

ifconfig

Utilitaire de configuration des interfaces réseaux

   Sans argument, affiche simplement l'état des interfaces définies. Si une interface est données, affiche l'état de l'interface.

-a Affiche toutes les interfaces, y compris celles inactives

   Si le premier argument après le nom de l'interface est reconnu comme étant un nom de famille d'adresse, cette famille est utilisée pour décoder et afficher toutes les adresses protocolaires (inet, ax25, ddp et ipx)

OPTIONS

up active l'interface
down arrête le fonctionnement du pilote de cette interface
[-]arp valide ou invalide l'utilisation du protocole ARP sur cette interface
[-]promisc valide ou invalide le mode promiscuous.
[-]allmulti valide ou invalide le fonctionnement de l'interface en mode all-multicast
metric définit la métrique de l'interface
mtu définit le MTU de l'interface
netmask Définit le masque de sous-réseau pour l'interface.
add adr/lg_prefix ajoute une adresse IPv6 à une interfaces
del adr/lg_prefix supprime une adresse IPv6 d'une interface
tunnel aa.bb.cc.dd crée un tunnel périphérique SIT (ipv6 dans ipv4) en mode tunnel jusqu'à la destination
irq Définit la ligne d'interruption utilisée par ce périphérique
io_addr définit l'adresse de début dans l'espace d'entrée-sortie I/O
mem_start Définit l'adresse de début de mémoire partagée pour ce périphérique
media type Définis le port physique de medium utilisé pour ce périphérique (10base2 10baseT AUI auto)
[-]broadcast [adr] définis l'adresse broadcast.
[-]pointopoint [adr] valide le mode point-to-point d'une interface. adr est l'adresse de l'autre bout.
hw classe adresse Définis l'adresse matérielle de l'interface (ether, ax25, ARCnet et Netcron)
multicast Positionne l'indicateur multicast sur l'interface
^
13 février 2012

htmlpdflatexmanmd




ifdhandler

ifdhandler

Utilitaire de gestion des modules au format ifdhandler

OPTIONS

-r Index du lecteur de carte à utiliser
-F Tâche de fond
-H spécifie qu’il s’agit d’un lecteur hotplug
-p force le polling device event si les évènement sont supportés
-s Envoie les messages de debug et d’erreur à syslogd
-d mode debug (peut être spécifié plusieurs fois)
-i Affiche la liste des pilotes et protocoles disponibles
^
13 février 2012

htmlpdflatexmanmd




ifdproxy

ifdproxy

Utilitaire pour l'accès au lecteur de carte distant

OPTIONS

-d mode debug
-F Ne lance pas en tâche de fond

Commandes

server [-dF] Lance le mode serveur
export [-dF] name device address:port Exporte le lecteur de carte vers une machine distante
list [-dF] address:port Liste les périphériques sur la machine distante, ou tous les périphériques si aucune adresse n’est spécifiée
^
17 mars 2010

htmlpdflatexmanmd




ifup

ifup, ifdown

Active/désactive une interface réseau. Peuvent être utilisés pour configurer / dé-configurer les interfaces réseaux basé sur des définitions d'interface dans le fichier /etc/network/interfaces

OPTIONS

-a, --all affecte toutes les interfaces marquée auto, dans l'ordre où ils apparaissent dans le fichier interfaces.
--force Force la configuration ou la déconfiguration de l'interface
-i FILE, --interfaces=FILE Lit le fichier spécifié au lieu de /etc/network/interfaces
-n, --no-act mode simulation, n'active aucune interface
--allow=CLASS seules les interfaces listées dans un "allow class" sont activé ou désactivées.
--no-mapping ne lance aucun mapping.
-v, --verbose mode verbeux

Exemples

Activer eth0
ifup eth0
Activer l'interface eth0 comme interface logique home
ifup eth0=home

   note: le fichier /var/run/network/ifstate donne l'état des interfaces réseaux.
^
13 mars 2010

htmlpdflatexmanmd




inadyn

inadyn

Inadyn est un client DNS dynamique. Il vérifie si l’adresse public a changé et met à jour le serveur dns dynamique.

OPTIONS

--username, -u nom d’utilisateur
--password, -p mot de passe
--alias, -a nom d’hôte, peut apparaitre plusieurs fois.
--input file fichier d’options, par défaut /etc/inadyn.conf
--ip_server_name local-url. Défaut : checkip.dyndns.org /
--dyndns_server_name le serveur qui reçoit la requête de mise à jour DNS.
--dyndns_server_url URL relative au serveur Dyndns root. Ex: /some_script.php?hostname=
--dyndns_system Type de service Dyndns. Devrait être une des valeurs suivante:

        www.dyndns.org dyndns@dyndns.org ou statdns@dyndns.org ou customdns@dyndns.org.
        www.freedns.afraid.org default@freedns.afraid.org
        www.zoneedit.com default@zoneedit.com
        www.no-ip.com default@no-ip.com
        generic DNS system custom@http_svr_basic_auth

--proxy_server [name[:port]] le nom du server proxy http
--update_period délay de vérification de l’IP en ms (défaut 1min, max 10jours)
--update_period_sec délay de vérification de l’IP en secondes (défaut 1min, max 10jours)
--forced_update_period délay pour forcer la mise a jour même si l’IP n’est pas changée (en sec)
--log_file fichier de log
--background lancer en tache de fond, sortie vers le fichier de log ou syslog
--verbose mode verbeux, de 0 à 5
--iterations nombre de mises a jour DNS, 0 par défaut, qui signifie infini.
--syslog force les logs dans syslog
--change_persona uid[:gid] après initialisation, passe sur l’utilisateur:groupe

Exemple

vous pouvez spécifier les options directement dans la commande, ou les placer dans une fichier de config (par défaut /etc/inadyn.conf) :
username user
password password
alias uubu.dyndns.org
dyndns_system dyndns@dyndns.org
update_period_sec 60
log_file /var/log/inadyn.log
change_persona 1002:1002
background
verbose 5
^
31 mars 2016

htmlpdflatexmanmd




incrond

incrond

Service cron inotify

   incrond est un service qui supervise les événements du système de fichier et exécute des commandes définies dans les tables système et utilisateur. Son utilisation est similaire à crond

   incrond utilise 2 catégories de tables incrontab(5). Les tables système sont généralement localisées dans /etc/incron.d et sont maintenus en dehord de incron. Ces tabbles fonctionne avec les privilèges root et tout fichier et lu et les commandes exécutés par root

   Les tables utilisateur sont localisées dans /var/spool/incron par défaut et ont des noms basés sur les comptes utilisateur. Ces tables utilisent les droits d'accès de l'utilisateur.

   Si une table est changé incrond réagit immédiatement et recharge la table.

   Il y a 2 fichiers déterminant si un utilisateur est autorisé à utiliser incron, /etc/incron.allow et /etc/incron.deny.

   Le service lui-même n'est actuellement pas protégé contre le bouclage. Si une commande est exécuté dû à un événement qui déclenche le même événement, il boucle indéfiniment, sauf si un masque contenant IN_NO_LOOP est spécifié.

OPTIONS

-n, --foreground ne lance pas en tâche de fond
-k, --kill Termine une instance en cours
-f, --configfile=‹file› Emplacement du fichier de configuration. Défaut: /etc/incron.conf
^
31 mars 2016

htmlpdflatexmanmd




incrontab

incrontab

Manipulateur de table pour incrond

   incrontab est un manipulateur de table pour incron. Il créé, supprime, modifie et liste les tables utilisateurs. Chaque utilisateur, incluant les utilisateurs systèmes ont une table incron qui ne peut pas être manipulée directement. Seul root peut le faire, mais ce n'est pas recommandé. Tous les messages d'information de ce programme sont affichés sur l'erreur standard

OPTIONS

-u, --user Remplace l'utilisateur courant (réel) avec celui donné.
-l, --list Affiche la table courante sur la sortie standard
-r, --remove Supprime la table courante sans confirmation
-e, --edit Exécute un éditeur pour éditer la table courante
-t, --types Affiche la liste de types d'événements supportés sur la sortie standard
-d, --reload Recharge la table courante dans incrond
-f, --config= Emplacement du fichier de configuration. Défaut: /etc/incron.conf
^
01 février 2014

htmlpdflatexmanmd




info

info

Lire des documents au format info (texinfo)

OPTIONS

-k, --apropos=STRING Cherche la chaîne spécifiée dans tous les indices de tous les manuels
-d, --directory=DIR Ajoute DIR dans INFOPATH
--dribble=FILENAME Mémorise les touches utilisateur dans le fichier spécifié
-f, --file=FILENAME Fichier info à lire
--index-search=STRING Va au nœud pointé par l'index STRING
-n, --node=NODENAME Spécifie le nœud dans le premier fichier info lu
-o, --output=FILENAME Sort le nœud sélectionné dans le fichier
-R, --raw-escapes Affiche les échappements ANSI brut (par défaut)
--no-raw-escapes Affiche les échappements ANSI littéralement
--restore=FILENAME Lit les clé initiales depuis le fichier
-O, --show-options, --usage Va au nœud des options de ligne de commande
--subnodes Sort les éléments de menu récursivement
--vi-keys Utilise les key bindings style vi et less
-w, --where, --location Emplacement physique du fichier info

Exemples

Afficher le menu supérieur
info
Afficher le manuel général de info
info info
afficher le manuel spécifique à ce programme info
info info-stnd
Commencer au nœud emacs depuis le répertoire supérieur
info emacs
Commencer au nœud buffer du manuel emacs
info emacs buffers
Commencer au nœud avec les options de ligne de commande de emacs
info --show-options emacs
dump tout le manuel
info --subnodes -o out.txt emacs
Afficher le fichier, ./foo.info, qui n'est pas dans le répertoire de recherche
info -f ./foo.info
^
31 mai 2010

htmlpdflatexmanmd




init

init

Parent de tous les processus. Son rôle principal est de créer des processus depuis un script stocké dans /etc/inittab. L'ID du processus init est toujour 1

runlevels

   un runlevel est une configuration du système qui permet de sélectionner un groupe de processus. Il existe 8 runlevel. le runlevel peut être changé avec telinit qui envoie le signal approprié à init. Les runlevels S, 0, et 6 sont réservés. Le runlevel S est utilisé pour initialiser le système au boot. Les runlevels S et 1 sont des modes simple utilisateur. Runlevel 0 est utilisé pour arrêter le système, runlevel 6 est utilisé pour rebooter le système. Après avoir booté au travers du runlevel S, le système entre dans un mode multi-utilisateurs (2 à 5). Les runlevels 7-9 dont aussi valides, bien qu'ils ne soient pas documentés.

Boot

Après qu'init ai été invoqué en tant que dernière étape de la séquence de boot du kernel, il cherche le fichier /etc/inittab pour voir s'il y'a une entrée de type initdefault, qui détermine le runlevel initial du système. S'il n'est pas spécifié, le runlevel doit être entré dans la console système.
En mode simple utilisateur, /sbin/sulogin est invoqué sur /dev/console
En entrant en mode simple utilisateur, init initialise les réglages des consoles stty.
En entrant en mode multi-utilisateur pour la première fois, init effectue les entrées boot et bootwait pour permettre aux systèmes de fichiers d'être montés avant que les utilisateurs puissent se logger. Ensuite toutes les entrées correspondant au runlevel sont traitées.
En démarrant un nouveau processus, init vérifie d'abord si le fichier /etc/initscript existe. Si c'est le cas, il utilise ce script pour démarrer le processus.
Chaque fois qu'un enfant se termine, init enregistre la raison dans /var/run/utmp et /var/log/wtmp

Changer les runlevels

   Une fois tous les processus lancés, init attend qu'un de ses processus meurt, un signal powerfail, ou jusqu'à ce qu'il soit signalé par telinit de changer de runlevel. Quand une de ces 3 conditions se produit, il ré-examine /etc/inittab.

  Si init n'est pas en mode simple utilisateur et reçoit un signal POWERFAIL (SIGPWR), il lit le fichier /etc/powerstatus, et lance une commande basée sur le contenu de ce fichier. L'utilisation de SIGPWR et /etc/powerstatus n'est pas conseillé.

  Quand init change de runlevel, il envoie un SIGTERM à tous les processus qui ne sont pas définis dans le nouveau runlevel. Puis il attend 5 secondes avant de forcer ces processus avec SIGKILL. Noter que init assume que tous ces processus (et leur descendant) restent dans le même groupe de processus qu'init a crée pour eux. Si un de ces processus change de groupe, il ne recevra pas ces signaux.

Variables d'environnement

PATH /bin :/usr/bin :/sbin :/usr/sbin
INIT_VERSION la version d'init
RUNLEVEL Le runlevel système courant
PREVLEVEL Le runlevel système précédant
CONSOLE La console système. S'il n'est pas définit par init, sera /dev/console par défaut.

Flags

   Il est possible de passer des flags à init depuis le bootloader (ex : grub). Init accepte les flags suivant:

-s,S, single boot en mode simple utilisateur. Dans ce mode /etc/inittab est examiné et les scripts rc sont généralement lancés avant que le shell du mode simple utilisateur ne soit démarré.
1-5 Permet de spécifier le runlevel sur lequel booter.
-b, emergency Boot directement en mode simple utilisateur sans lancer de script de démarrage.
-a, auto LILO ajoute 'auto' à la ligne de commande si le kernel est booté avec la ligne de commande par défaut (sans l'intervention de l'utilisateur). init définit alors la variable AUTOBOOT à yes.
-z permet d'étendre un peu la ligne de commande, et donc prenne un peu plus d'espace dans la pile. Init peut ainsi manipuler la ligne de commande pour que ps(1) affiche le runlevel courant.

Interface

   init écoute les messages sur un fifo dans /dev/initctl. Telinit l'utilise pour communiquer avec init.

Signaux

   init réagit à certains signaux:

SIGHUP a le même effet que telinit q
SIGUSR1 init ferme et ré-ouvre son fifo /dev/initctl. utile pour les scripts de boot quand /dev est remonté.
SIGINT Généralement le kernel envoie ce signal à init quand ctrl+alt+del est pressé. Il active l'action ctrlaltdel.
SIGWINCH le kernel envoie ce signal quand la touche KeyboardSignal est pressée. Active l'action kbrequest
^
31 mai 2010

htmlpdflatexmanmd




initscript

initscript

Script qui exécute les commandes inittab

   Quand ce script existe, init l'utilise pour exécuter les commandes depuis inittab. Ce script peut être utilisé pour définis différentes choses comme ulimit et umask par défaut pour tous les utilisateurs.

Exemples


# Set umask to safe level, and enable core dumps.
umask 022
ulimit -c 2097151
PATH=/bin :/sbin :/usr/bin :/usr/sbin
export PATH
    
# Increase the hard file descriptor limit for all processes
# to 8192. The soft limit is still 1024, but any unprivileged
# process can increase its soft limit up to the hard limit
# with "ulimit -Sn xxx" (needs a 2.2.13 or later Linux kernel).
ulimit -Hn 8192
    
# Execute the program.
eval exec "$4"

^
31 mai 2010

htmlpdflatexmanmd




inittab

inittab

Fichier de configuration de init

Une entrée de runlevel a le format suivant:
id:runlevels:action:process

id séquence unique de 1 à 4 caractères qui identifie l'entrée dans inittab.
runlevels liste les runlevels pour lesquels l'action spécifiée doit être exécutée
action décrit l'action à exécuter
process spécifie le processus à exécuter. S'il commence avec un '+', init ne créera pas de utmp et wtmp pour ce processus. nécessaire pour les getty qui insistent pour faire leur propre utmp/wtmp. c'est aussi un bug historique.

   Le champ runlevels peut contenir plusieurs caractères pour différents runlevels. Les actions valides sont:

respawn Le processus sera redémarré s'il est terminé (ex getty)
wait Le processus sera démarré une fois en entrant dans le runlevel et init attendra qu'il se termine
once Le processus sera exécuté une fois en entrant dans le runlevel.
boot Le processus sera exécuté au boot Le champs runlevel est ignoré
bootwait Le processus sera exécuté durant le boot, init attendra qu'il se termine(ex : /etc/rc). Le runlevel est ignoré.
off Ne fait rien ondemand Sera exécuté quand le runlevel est appelé, cependant aucun changement de level ne sera exécuté.(les runlevels ondemand sont a, b, et c)
initdefault spécifie le runlevel par défaut après le boot. Le champs process est ignoré
sysinit Le processus sera exécuté durant le boot. Il sera exécuté avant une entrée boot ou bootwait. Le runlevel est ignoré.
powerwait Le processus est exécuté quand le courant s'affaiblit.
powerfail comme powerwait, excepté qu'init n'attend pas que le processus se termine
powerokwait Le processus sera exécuté une fois qu'init est informé que le courant est revenu
powerfailnow Le processus sera exécuté quand la batterie est vide et le courant s'arrête.
ctrlaltdel Le processus sera exécuté quand init recevra le signal SIGINT. généralement en pressant ctrl+alt+del
kbrequest Le processus sera exécuté quand init reçoit un signal depuis une combinaison de touches spécial.

Exemple simple


id:1:initdefault :
rc ::bootwait :/etc/rc
1:1:respawn :/etc/getty 9600 tty1
2:1:respawn :/etc/getty 9600 tty2
3:1:respawn :/etc/getty 9600 tty3
4:1:respawn :/etc/getty 9600 tty4

   Il exécute /etc/rc durant le boot et lance getty sur tty1 à tty4

Exemple plus élaboré


id:2:initdefault :
    
# script d'initialisation/configuration au moment du boot
si ::sysinit :/etc/init.d/rcS
    
# quoi faire en mode simpleutilisateur
:S:wait :/sbin/sulogin
    
# /etc/init.d execute les scripts S et K pendant le changement de runlevel
l0:0:wait :/etc/init.d/rc 0
l1:1:wait :/etc/init.d/rc 1
l2:2:wait :/etc/init.d/rc 2
l3:3:wait :/etc/init.d/rc 3
l4:4:wait :/etc/init.d/rc 4
l5:5:wait :/etc/init.d/rc 5
l6:6:wait :/etc/init.d/rc 6
    
# quoi faire si ctrl+alt+del sont pressés
ca ::ctrlaltdel :/sbin/shutdown -t1 -h now
    
# Runlevel 2,3 : getty sur les consoles virtuelles
# Runlevel 3 : getty sur le terminal (ttyS0) et le modem (ttyS1)
1:23:respawn :/sbin/getty tty1 VC linux
2:23:respawn :/sbin/getty tty2 VC linux
3:23:respawn :/sbin/getty tty3 VC linux
4:23:respawn :/sbin/getty tty4 VC linux
S0:3:respawn :/sbin/getty -L 9600 ttyS0 vt320
S1:3:respawn :/sbin/mgetty -x0 -D ttyS1

^
31 mars 2016

htmlpdflatexmanmd




inosync

inosync

Service de synchronisation de répertoire basé sur les notifications

   script python s'appuyant sur rsync pour synchroniser automatiquement des répertoires

OPTIONS

-c FILE Fichier de configuration
-d lance en tâche de fond
-p N'appel pas rsync
-v mode verbeux

Configuration


# Répertoire à surveiller:
wpath = "/var/www/"
    
# liste d'exclusion pour rsync
rexcludes = [
    "/localhost",
]
    
# Chemin distant:
rpath = "/var/www/"
    
# Emplacements distants au format rsync
rnodes = [
    "a.mirror.com:" + rpath,
    "b.mirror.com:" + rpath,
    "c.mirror.com:" + rpath,
]
    
# Limite de vitesse rsync en Ko/s, 0 = pas de limite
#rspeed = 0
    
# Masque d'événements:
#emask = [
#\t"IN_CLOSE_WRITE",
#\t"IN_CREATE",
#\t"IN_DELETE",
#\t"IN_MOVED_FROM",
#\t"IN_MOVED_TO",
#]
    
# Délai d'événement, réduit de traffic
#edelay = 10
    
# Ficher de log rsync
#logfile = /var/log/inosync.log
    
# Chemin du binaire rsync
#rsync = "/usr/bin/rsync"

^
31 mars 2016

htmlpdflatexmanmd




inoticoming

inoticoming

Déclencher des actions quand des fichiers entrent dans un répertoire

   inoticoming est un service qui recherche un répertoire avec le framework inotify de linux et déclenche des actions une fois que les fichiers avec des noms spécifiques y sont placés.

OPTIONS

--foreground Ne pas forker
--logfile filename Log dans le fichier spécifié au lieu de syslog
--pid-file filename Écris le pid de l'instance dans le fichier spécifié
--initialsearch Effectue une recherche initiale dans le répertoire

ACTIONS

--prefix string Déclenche l'action si le nom de fichier commence avec la chaîne spécifiée
--suffix string Déclenche l'action si le nom de fichier se termine avec la chaîne spécifiée
--chdir directory Change de répertoire avant d'exécuter la commande spécifiée
--stdout-to-log Redirige la sortie de la commande dans le fichier de log
--stderr-to-log Redirige l'erreur standard dans le fichier de log

Exemples

Appeler reprepro pour chaque fichier .changes. {} sera remplacé avec le nom de fichier.
inoticoming --logfile logs/ilog --pid-file pid $INCOMINGDIR --suffix .changes --stderr-to-log reprepro -s -b $REPREPROBASEDIR --waitforlock 1000 processincoming rulename {} \;
^
31 mars 2016

htmlpdflatexmanmd




inotify

inotify

Surveillance des événements des systèmes de fichier

   inotify est contrôlé par un jeu de 3 appels système et d’un fichier I/O normal retourné sur un descripteur de fichier.

inotify_init(2) Créé une instance inotify et renvoie un descripteur de fichier se référant à cette instance inotify. inotify_init1(2) est similaire mais offre un argument flags qui fournis des fonctionnalités supplémentaires.
inotify_add_watch(2) Manipule la liste de surveillance associée à une instance inotify. Chaque élément indique le chemin d'un fichier ou d'un répertoire avec un ensemble d'événements à surveiller.
inotify_rm_watch(2) Retire un élément d'une liste de surveillance inotify

Pour déterminer quels événements ont lieu, une application lit le descripteur de fichier inotify avec read(2). Chaque lecture réussie renvoie un tampon contenant une ou plusieurs structures suivantes:
struct inotify_event {
    int wd; /*Descripteur de surveillance*/
    uint32_t mask; /*Masque d'événements*/
    uint32_t cookie; /*Cookie unique d'association des événements (pour rename(2))*/
    uint32_t len; /*Taille du champ name*/
    char name[]; /*Nom optionnel terminé par un nul*/
};

wd identifie l'élément de surveillance
mask contient des bits décrivant l'événement
cookie entier unique qui relie les événements. Utilisé uniquement pour les événements de renommage
len Compte tous les octets de name, incluant les caractères nuls.

Événements inotify

IN_ACCESS accès au fichier
IN_ATTRIB Modification des métadonnées, ex les permissions, horodatages, attributs étendus, compteur de liens, UID ou GID.
IN_CLOSE_WRITE Fichier ouvert en écriture fermé
IN_CLOSE_NOWRITE Fichier non ouvert en écriture fermé
IN_CREATE Fichier ou répertoire créé dans le répertoire surveillé
IN_DELETE Fichier ou répertoire supprimé dans le répertoire surveillé
IN_DELETE_SELF Fichier ou répertoire surveillé supprimé ( ou déplacé dans un autre système de fichier)
IN_MODIFY Fichier modifié
IN_MOVE_SELF Fichier ou répertoire surveillé déplacé
IN_MOVED_FROM Généré pour le répertoire contenant l'ancien nom quand un fichier est renommé
IN_MOVED_TO Généré pour le répertoire contenant le nouveau nom quand un fichier est renommé
IN_OPEN Fichier ouvert
IN_MOVE Équivalent à IN_MOVED_FROM | IN_MOVED_TO
IN_CLOSE Équivalent à IN_CLOSE_WRITE | IN_CLOSE_NOWRITE
IN_DONT_FOLLOW e pas déréférencer pathname s'il s'agit d'un lien symbolique
IN_EXCL_UNLINK Ne génère pas d'événements pour certaines entrées après leur suppression du répertoire surveillé
IN_MASK_ADD Ajouter des événements au masque de surveillance de ce fichier s'il existe déjà (au lieu de remplacer le masque)
IN_ONESHOT Surveiller pathname jusqu'au premier événement, puis le supprimer de la liste de surveillance
IN_ONLYDIR Ne surveiller pathname que si c'est un répertoire
IN_IGNORED Le surveillant a été retiré explicitement au automatiquement
IN_ISDIR Le sujet de cet événement est un répertoire
IN_Q_OVERFLOW File des événements surchargé
IN_UNMOUNT Le système de fichiers contenant l'objet surveillé a été démonté
^
31 mars 2016

htmlpdflatexmanmd




inotifywait

inotifywait

Attend les changements de fichiers en utilisant inotify

   Il peut soit quitter une fois l'événement produit, ou s'exécuter en continue et afficher les événements qui se produisent. inotifywait affiche des diagnostiques sur l'erreur standard et les informations d'événement sur la sortie standard. La sortie de l'événement peut être configuré, mais par défaut, il consiste de lignes sous la forme suivante:

watched_filename EVENT_NAMES event_filename
watched_filename est le nom du fichier dans lequel l'événement se produit, si le fichier est un répertoire, un '/' final est affiché
EVENT_NAMES sont les noms des événements inotify qui se produisent
event_filename est affiché seulement quand l'événement se produit sur un répertoire, et dans ce cas le nom du fichier dans le répertoire qui à causé l'événement est affiché

OPTIONS

@‹file› Exclus le fichier spécifié dans le répertoire surveillé
--fromfile ‹file› Lit les noms de fichier à surveiller ou exclure depuis un fichier, un fichier par ligne. '@' comme préfixe exclus de fichier, si le fichier spécifié est '-', les fichiers sont lus depuis l'entrée standard
-m, --monitor Au lieu de quitter une fois un événement reçu, s'exécute indéfiniment
-d, --deamon Idem à -m, est s'exécute en tâche de fond en loggant dans un fichier spécifié avec --outfile. Implique --syslog
-o, --outfile ‹file› Sort les événements dans le fichier au lieu de stdout
-s, --syslog Affiche les erreurs dans syslog au lieu de stderr
-r, --recursive Surveille tous les sous-répertoires dans tous les répertoires passés en argument
-q, --quiet Si spécifié une seule fois, le programme sera moins verbeu. 2 fois, le programme n'affiche rien, exepté en cas d'erreur fatal.
--exclude ‹pattern› Ne traite pas les événements des fichiers dont le nom matche le regex spécifié, sensible à la casse
--excludei ‹pattern› idem, insensible à la casse
-t ‹seconds›, --timeout ‹seconds› Quitte si un événement approprié ne s'est pas produit dans les ‹seconds›. à 0, attend indéfiniment.
‹event›, --event ‹event› Écoute des événements spécifiques uniquement.
-c, --csv Sort au format CSV
--timefmt ‹fmt› Défini un format de date accepté par strftime(3) à utiliser avec %T de l'option --format
--format ‹fmt› Format personnalisé, les caractères de conversions suivants sont supportés:

        %w Nom du fichier surveillé
        %f Dans un répertoire, le nom du fichier ayant causé l'événement
        %e Événements qui se sont produits, séparés pas des ','
        %Xe Idem, séparé par le caractère ‹X›
        %T Date courante

Code de sortie

0 succès
1 Erreur d'exécution du programme
2 Option -t utilisé et aucun événement ne s'est produit

Événements

access accès au fichier
attrib Modification des métadonnées, ex les permissions, horodatages, attributs étendus, compteur de liens, UID ou GID.
close_write Fichier ouvert en écriture fermé
close_nowrite Fichier non ouvert en écriture fermé
create Fichier ou répertoire créé dans le répertoire surveillé
delete Fichier ou répertoire supprimé dans le répertoire surveillé
delete_self Fichier ou répertoire surveillé supprimé ( ou déplacé dans un autre système de fichier)
modify Fichier modifié
move_self Fichier ou répertoire surveillé déplacé
moved_from Généré pour le répertoire contenant l'ancien nom quand un fichier est renommé
moved_to Généré pour le répertoire contenant le nouveau nom quand un fichier est renommé
open Fichier ouvert
move Équivalent à moved_from | moved_to
close Équivalent à close_write | close_nowrite
unmount Le système de fichiers contenant l'objet surveillé a été démonté

Exemples

Attend un accès à un fichier dans le répertoire test:
inotifywait test
Script shell pour attendre efficacement pour des log https et agir en consequence:
#!/bin/sh
while inotifywait -e modify /var/log/messages; do
if tail -n1 /var/log/messages | grep httpd; then
kdialog --msgbox "Apache needs love!"
fi
done
Personnaliser le format de sortie:
inotifywait -m -r --format '%:e %f' ~/test
^
31 mars 2016

htmlpdflatexmanmd




inotifywatch

inotifywatch

Affiche des statistiques d'accès au système de fichier en utilisant inotify

   inotifywatch écoute les événements des systèmes de fichiers en utilisant inotify, et affiche un compteur d'événements reçus pour chaque fichier ou répertoire. Certaines informations s'affiche sur l'erreur standard

OPTIONS

-v, --verbose mode verbeux
@‹file› Exclus le fichier spécifié dans le répertoire surveillé
--fromfile ‹file› Lit les noms de fichier à surveiller ou exclure depuis un fichier, un fichier par ligne. '@' comme préfixe exclus de fichier, si le fichier spécifié est '-', les fichiers sont lus depuis l'entrée standard
-z, --zero Affiche les lignes et colonnes même s'il n'y a pas d'élément
--exclude ‹pattern› Ne traite pas les événements des fichiers dont le nom matche le regex spécifié, sensible à la casse
--excludei ‹pattern› idem, insensible à la casse
-r, --recursive Surveille tous les sous-répertoires dans tous les répertoires passés en argument
-t ‹seconds›, --timeout ‹seconds› Quitte si un événement approprié ne s'est pas produit dans les ‹seconds›. à 0, attend indéfiniment.
‹event›, --event ‹event› Écoute des événements spécifiques uniquement.
-a ‹event›, --ascending ‹event› Trie ascendant de la sortie par compteur de l'événement spécifié
-d ‹event›, --descending ‹event› Trie descendant de la sortie par compteur de l'événement spécifié

Code de sortie

0 succès
1 Erreur d'exécution du programme

Événements

access accès au fichier
attrib Modification des métadonnées, ex les permissions, horodatages, attributs étendus, compteur de liens, UID ou GID.
close_write Fichier ouvert en écriture fermé
close_nowrite Fichier non ouvert en écriture fermé
create Fichier ou répertoire créé dans le répertoire surveillé
delete Fichier ou répertoire supprimé dans le répertoire surveillé
delete_self Fichier ou répertoire surveillé supprimé ( ou déplacé dans un autre système de fichier)
modify Fichier modifié
move_self Fichier ou répertoire surveillé déplacé
moved_from Généré pour le répertoire contenant l'ancien nom quand un fichier est renommé
moved_to Généré pour le répertoire contenant le nouveau nom quand un fichier est renommé
open Fichier ouvert
move Équivalent à moved_from | moved_to
close Équivalent à close_write | close_nowrite
unmount Le système de fichiers contenant l'objet surveillé a été démonté

Exemples

Surveiller ~/.beagle pendant 60 secondes:
inotifywatch -v -e access -e modify -t 60 -r ~/.beagle
^
28 mars 2016

htmlpdflatexmanmd




insmod

insmod

Insert un module dans le kernel linux

   insmod est un programme simple pour insérer un module dans le kernel. La plupart des utilisateurs utilisent modprobe, qui est plus simple à utiliser.

^
31 mai 2010

htmlpdflatexmanmd




insserv

insserv

Autorise un script init installé en lisant l'en-tête et calcule les dépendances.

Exemple


### BEGIN INIT INFO
# Provides : boot_facility_1 [ boot_facility_2 ...]
# Required-Start : boot_facility_1 [ boot_facility_2 ...]
# Required-Stop : boot_facility_1 [ boot_facility_2 ...]
# Should-Start : boot_facility_1 [ boot_facility_2 ...]
# Should-Stop : boot_facility_1 [ boot_facility_2 ...]
# X-Start-Before : boot_facility_1 [ boot_facility_2 ...]
# X-Stop-After : boot_facility_1 [ boot_facility_2 ...]
# Default-Start : run_level_1 [ run_level_2 ...]
# Default-Stop : run_level_1 [ run_level_2 ...]
# X-Interactive : true
# Short-Description : single_line_description
# Description : multiline_description
### END INIT INFO

insserv scanne /etc/insserv.conf et le contenu de /etc/insserv.conf.d/. exemple:
# All local filesystems are mounted
# (done during boot phase)
$local_fs boot
    
# Low level networking
$network network route
    
# Named is operational
$named named
    
# All remote filesystems are mounted
# (in some cases /usr may be remote).
$remote_fs $local_fs nfs
    
# System logger is operational
$syslog syslog
    
# All network daemons are running
$netdaemons portmap inetd
    
# Services which need to be interactive
‹interactive› boot.crypto

OPTIONS

-v, --verbose mode verbeux
-c ‹config›, --config ‹config› Spécifier le chemin vers insserv.conf et insserv.conf.d
-o ‹path›, --override ‹path› l'en-tête trouvé dans ce chemin va remplacer l'en-tête existant dans les scripts.
-p ‹path›, --path ‹path› spécifier le dossier init.d
-n, --dryrun ne pas mettre à jourslesliens
-r, --remove supprime les scripts listés de tous les runlevels
-d, --default utilise les runlevels par défaut dans les scripts.
-f, --force ignore si un service requis est manquant

[[/]path/to/init.d/] chemin relatif ou absolue vers le dossier des scripts.Défaut : /etc/init.d
[[/]path/to/init.d/]script ... Liste des scripts qui doivent être ajoutés aux runlevels
[[/]path/to/init.d/]script[,start=‹lvl1,lvl2,...›] Liste des scripts qui doivent être ajoutés aux runlevels spécifiés
-r [[/]path/to/init.d/]script ... Liste de scripts qui devraient être supprimés des runlevels

Fichiers

/etc/insserv.conf Fichier de configuration
/etc/insserv.conf.d/ dossier contenant les fichiers de configurations
/etc/insserv/overrides/ Chemin pour remplacer les en-têtes des scripts
/etc/init.d/ le dossier contenant les script init
/etc/init.d/.depend.boot
/etc/init.d/.depend.start
/etc/init.d/.depend.stop Les fichiers de dépendances produits par insserv avec l'aide de startpar
^
30 juin 2010

htmlpdflatexmanmd




install

install

Copie de fichiers tout en définissant les bits de mode et, si possible, le user et group

   Si 2 noms de fichiers sont spécifiés, copie le premier dans le deuxième.

  Si -t est donné, ou le dernier fichier est un répertoire et -T est donné, copie chaque source dans ce répertoire.

  Si -d est spécifié, crée chaque répertoire et les dossiers parents manquant. Les parents sont créer avec le mode u=rwx,gorx.

  install est similaire à cp mais permet de contrôler les attributs des fichiers de destination. install ne préserve jamais les attributs étendus.

OPTIONS

-b, --backup[=METHOD] Créer une sauvegarde de chaque fichier qui aurait été écrasé ou supprimé.
-D crée les répertoires parents manquant de destination, puis copie la source dans la destination.
-d, --directory Crée les répertoires manquant, donnant les attributs par défaut.
-g GROUP, --group=GROUP Définit le groupe des fichiers installés
-m MODE, --mode=MODE Définit les bits de mode pour les fichiers installés. Peut être spécifié en octal, ou un mode symbolique comme avec chmod.
-o OWNER, --owner=OWNER Définit le propriétaire des fichiers installés.
--preserve-context Préserve le contexte de sécurité SELinux des fichiers.
--preserve-timestamp Défini le atime et le mtime de chaque fichier installé pour correspondre aux fichiers originaux.
-S SUFFIX, --suffix=SUFFIX ajoute un suffixe à chaque ficher de backup crée avec -b
-t DIRECTORY, --target-directory=DIRECTORY spécifie le répertoire de destination.
-T, --no-target-directory Ne traite pas la dernière opérande spécialement quand c'est un répertoire ou un lien symbolique.
-v, --verbose Affiche le nom de chaque fichier avant de la copier.
-Z CONTEXT, --context=CONTEXT Définit le contexte de sécurité SELinux à utiliser pour les fichiers crées.
^
17 mars 2010

htmlpdflatexmanmd




interfaces

interfaces

Fichier de configuration pour ifup et ifdown. Il contient les informations de configuration pour les interfaces réseau

   Les lignes commençant par "#" sont ignorées. Une ligne peut être étendue sur plusieurs en utilisant un "\" à la fin de la ligne. Ce fichier consiste d'une ou plusieurs "iface", "mapping", "auto" et "allow-".

   Les lignes commençant par le mot "auto" sont utilisées pour identifier les interfaces physiques à configurer quand ifup est lancé avec l'option -a (cette options est utilisée par le système au démarrage). Le nom de l'interface physique doit suivre le mot "auto" sur la même ligne.

   Les lignes commençant avec "allow-" sont utilisées pour identifier les interfaces qui devraient être activées automatiquement par divers sous-systèmes. Cela peut-être fait avec une commande du type "ifup --allow=hotplug eth0 eth1", qui va activer uniquement eth0 et eth1 s'ils sont listés dans une ligne "allow-hotplug". Noter que "allow-auto" est synonyme de "auto".

   Les lignes commençant pas "mapping" sont utilisés pour déterminer comment le nom d'interface logique est choisis pour une interface physique. chaque mapping doit contenir une définition script.

   ifup utilise le nom de l'interface physique comme nom logique, à moins qu'un suffix du type =LOGICAL soit spécifié.

   La définition des interfaces logique commence avec une ligne consistant du mot "iface", suivi du nom de l'interface logique. Le nom de l'interface est suivi du nom de famille d'adresse que l'interface utilise. cela sera "inet" pour TCP/IP, ipx pour les réseau ipx et inet6 pour les réseaux ipv6. La suite est le nom de la méthode pour configurer l'interface.

   Des options additionnelles peuvent être utilisées sur les lignes suivante. ces options dépendent de la méthode et de la famille. Par exemple, le paquet wireless-tools ajoute des options préfixés avec "wireless" qui peuvent-être utilisées pour configurer l'interface en utilisant iwconfig.

IFACE options

   Ces options sont disponible pour toutes les familles et méthodes. Chacune peuvent être indiqué plusieurs fois et sont exécutés dans l'ordre qu'elle apparaissent. (pour s'assurer qu'une commande ne plante jamais, suffixer par "|| true"

pre-up command Lance la commande avant de configurer l'interface.
up comand
post-up command Lance la commande après avoir configuré l'interface
down command
pre-down command Lance la commande avant de dé-configurer l'interface.
post-down Lance la commande après avoir dé-configuré l'interface.

   Il existe pour chacune des options mentionnées, un dossier /etc/network/if-‹option›.d/. Les scripts qui s'y trouvent sont lancés en utilisant run-parts après que l'option ait été traitée.

  Toutes ces commandes ont accès aux variables d'environnement suivante:

IFACE Nom phyique de l'interface
LOGICAL Nom logique de l'interface
ADDRFAM famille de l'interface
METHOD Méthode de l'interface
MODE Démarre si lancé depuis ifup, arrête si lancé depuis ifdown
PHASE Comme pour MODE, mais plus précis, distingue pre-up, post-up, pre-down et post-down.
VERBOSITY indique si --verbose est utilisé.
PATH le path de recherche de commande: /usr/local/sbin :/usr/local/bin :/usr/sbin :/usr/bin :/sbin :/bin

Famille d'adresse inet

la méthode loopback Cette méthode est utilisé pour définir une interface de bouclage ipv4. N'a pas d'options
Methode static Cette méthode est utilisée pour définir les interfaces ethernet avec des adresses ipv4 définie statiquement dans /etc/network/interfaces

Options

address adresse IP
netmask masque de sous-réseau
broadcast adresse de broadcast
network adresse du réseau
metric métrique pour la route par défaut
gateway passerelle par défaut
pointopoint adresse de "l'autre bout"
media dépendant du pilote.
hwaddress classe et adresse physique. classe peut être ether, ax25, ARCnet ou netrom.
mtu taille MTU

La méthode manual Cette méthode peut être utilisé pour définir des interfaces sans configuration par défaut. N'a pas d'options
La méthode dhcp Cette méthode peut être utilisée pour obtenir une adresse et une configuration via DHCP.

Options

hostname nom d'hôte
leasetime lease time en seconde
vendor Vendor Class Identifier
Client identifiant client
hwaddress classe et adresse physique.

La méthode bootp Cette méthode peut être utilisée pour obtenir une ip via bootp

Options

bootfile fichier à utiliser
server adresse du serveur
hwaddr utilise l'adresse comme adresse physique

la méthode ppp Cette méthode est utilisé pour configurer des interfaces ppp (utilise pon/poff)

Options

provider utilise ce nom comme provider

la méthode wvdial méthode utilise wvdial pour configurer une interface ppp.
La méthode ipv4all cette méthode utilise avahi-autoipd pour configurer une interface avec une adresse ipv4 APIPA (famille 169.254.0.0/16). N'a pas d'options

Famille d'adresse inet6

La méthode loopback Cette méthode peut être utilisée pour définir l'interface de bouclage ipv6. N'a pas d'options
La méthode static Utilisé pour définir statiquement l'interface.

Options

address adresse de l'interface
netmask masque de sous-réseaux
gateway passerelle par défaut
media dépendant du pilote
hwaddress classe et adresse physique. Classe peut être ether, ARCnet ou netrom
mtu taille MTU

La méthode manual Cette méthode est utilisé pour définir des interfaces pour lesquelles aucune configuration n'est faite. N'a pas d'options
La méthode v4tunnel Cette méthode peut être utilisée pour créer un tunnel IPv6-over-IPv4. Il requière la commande ip du paquet iproute.

Options

address adresse de l'interface
netmask masque de sous-réseaux
endpoint adresse du bout du tunnel (ipv4)
local adresse local du tunnel (ipv4)
gateway passerelle par défaut
ttl réglage ttl

Exemples

interface loopback:
auto lo
iface lo inet loopback
configuration basique d'une carte ethernet:
auto eth0
iface eth0 inet static
address 192.168.0.42
network 192.168.0.0
netmask 255.255.255.0
gateway 192.168.0.1
configuration plus complexe, avec mise a jour de la table de routage:
auto eth0
iface eth0 inet static
address 192.168.1.42
network 192.168.1.0
netmask 255.255.255.128
broadcast 192.168.1.0
up route add -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
up route add default gw 192.168.1.200
down route del default gw 192.168.1.200
down route del -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2
configuration une carte ethernet avec 2 interfaces:
auto eth0 eth0:1
iface eth0 inet static
address 192.168.0.100
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
iface eth0:1 inet static
address 192.168.0.200
network 192.168.0.0
netmask 255.255.255.0
^
31 mai 2010

htmlpdflatexmanmd




invoke-rc.d

invoke-rc.d

Exécute des scripts dans /etc/init.d dans le style des services SystemV

   Les actions standard sont: start, stop, force-stop, restart, reload, force-reload et status. D'autres actions sont acceptées, mais peuvent causer des problèmes avec policy-rc.d, des alertes sont générées si la couche de politiques est active. Tous les autres paramètres sont passés aux scripts init invoqués.

OPTIONS

--quiet mode silencieux
--force essaye de lancer le scipt sans regarder les règles et les erreurs.
--try-anyway essaye de lancer un script si une erreur non-fatale est détéctée.
--disclose-deny retourne le code de status 101 au lieu de 0 si l'action du script est refusé par les rêgles.
--query Retourne un des code status 100-106. Ne lance pas le script, et implique --disclose-deny et --no-fallback
--no-fallback Ignores any fallback action requests by the policy layer.

Codes de status

0 aucune erreur ne s'est produit
1 - 99 réservé au script init.d, indique généralement une erreur.
100 nom de script init inconnu. le script n'a pas été enregistré correctement avec update-rc.d ou que le script n'existe pas.
101 action non permise
102 erreur du script init ou de règles.
103 erreur de syntaxe
104 le script aurait pu se lancer mais l'option --query a été spécifié
105 mode incertain. Ne peut pas déterminer l'action, et --query est spécifié.
106 les rêgles refusent l'action, and supplied an allowed fallback action to be used instead.

Fichiers

/etc/init.d/ scripts init System V
/usr/sbin/policy-rc.d Init script policy layer helper
/etc/runlevel.conf configuration des runlevel file-rc (si le package file-rc est utilisé).
/etc/rc‹x›.d/ configuration des runlevel System V (si le package sysv-rc n'est pas utilisé).
^
05 juillet 2015

htmlpdflatexmanmd




ip

ip

Affichage-manipulation des routes, périphériques, stratégies de routage et tunnels

OPTIONS

-b, -batch filename Lit les commandes depuis le fichier fournis, ou l'entrée standard.
-force Ne termine pas ip sur une erreur en mode batch
-s, -stats, -statistics Affiche plus d'informations. Peut apparaître plusieurs fois
-l, -loops count Boucle maximum de tentatives ip addr flush. défaut: 10. 0 boucle jusqu'à la suppression
-f, -family family Spécifie la famille de protocole à utiliser (inet, inet6, bridge, ipx, dnet ou link).
-4 Raccourci pour -family inet
-6 Raccourci pour -family inet6
-B Raccourci pour -family bridge
-D Raccourci pour -family decnet
-I Raccourci pour -family ipx
-0 Raccourci pour -family link
-o, -oneline Affiche chaque enregistrement sur une ligne
-r, -resolve Utilise le resolver pour afficher les noms DNS.

Commandes

address adresse dans un périphériques
addrlabel Configuration de label pour la sélection d'adresse
l2tp Tunnel éthernet sur IP (L2TPv3)
link Périphériques réseaux
monitor Lire les messages netlink
mroute Entrée de cache de routage multicast
mrule Règle dans la base de stratégie de routage multicast
neighbour Gérer les entrées de cache ARP et NDISC
netns Gérer les espaces de noms réseaux
ntable Gérer les opération de cache
route Gérer les entrée de table de routage
rule Règles dans la base de stratégie de routage
tcp_metrics/tcpmetrics Gérer les métriques TCP
tunnel Tunnel sur IP
tuntap Gérer les périphériques TUN/TAP
xfrm Gérer les périphériques IPSec
^
15 juin 2015

htmlpdflatexmanmd




ip-address

ip-address

Gestion des adresses de protocole

Commandes

ip address add Ajouter une nouvelle adresse de protocole

        dev NAME Le nom du périphérique
        local ADDRESS L'adresse de l'interface. Le format de l'adresse dépend du protocole (IP ou IPv6), et peut être suivi du masque
        peer ADDRESS L'adresse de l'autre nœud dans une interface point à point.
        broadcast ADDRESS L'adresse de broadcast de l'interface. Peut être '+' et '-'. Dans ce cas, il est dérivé en définissant/réinitialisant les bits du préfixe de l'interface.
        label NAME Chaque adresse peut être taggée avec un label. Pour des raison de compatibilité, cette chaîne doit coïncider avec le nom du périphérique ou doit être préfixé avec le nom du périphérique suivi par une virgule.
        scope SCOPE Le scope de l'aire où cette adresse est valide. Les scopes sont listés dans /etc/iproute2/rt_scopes, dont ceux qui sont prédéfinis sont:

                global L'adresse est valide globalement
                site (ipv6) l'adresse est locale au site
                link l'adresse est un lien local
                host L'adresse est valide seulement dans cet hôte

ip address delete Supprime une adresse de protocole. Les argument sont les même que pour ip address add
ip address show Affiche les adresses de protocole

        dev NAME Le nom du périphérique
        scope SCOPE Liste seulement les adresses dans ce scope
        to PREFIX List seulement les adresses correspondant à ce préfixe
        label PATTERN Liste seulement les adresses avec les labels qui correspondent au pattern
        up Liste seulement les interfaces up
        dynamic
        permanent (ipv6) liste seulement les adresses installées par une configuration sans état ou permanent.
        tentative (ipv6) Liste seulement les adresses qui n'ont pas passé la détection d'adresse dupliquée
        deprecated (ipv6) Liste seulement les adresses dépréciées
        dadfailed (ipv6) Liste seulement les adresses qui ont échouées la détection d'adresse dupliqueé
        temporary (ipv6) Liste seulement les adresses temporaires
        primary
        secondary (ipv6) Liste seulement les adresses primaires ou secondaires

ip address flush Vide les adresses de protocole sélectionnés par certains critères. Cette commande à les même argument que show. La différence est qu'elle ne se lance pas sans arguments.

Exemples

Afficher les adresses assignées à l'interface eth0
ip address show dev eth0
Ajoute une adresse IPv6 à l'interface eth1
ip addr add 2001:0db8:85a3::0370:7334/64 dev eth1
Supprime toutes les adresses de l'interface eth1
ip addr flush dev eth4
^
05 juillet 2015

htmlpdflatexmanmd




ip-addrlabel

ip-addrlabel

Gestion de label d'adresse de protocole

   Les labels d'adresse IPv6 sont utilisé pour la sélection d'adresse; ils sont décris dans la rfc 3484. La précédence est gérée par l'espace utilisateur et seulement le label lui-même est stocké dans le kernel.

add Ajoute un label

        prefix PREFIX
        dev DEV L'interface sortante
        label NUMBER le label pour le prefix. 0xffffffff est réservé

del Supprime un label. Les arguments sont les même que pour add, mais le label est optionnel
list Liste les labels
flush Vides les labels dans le kernel.

^
05 juillet 2015

htmlpdflatexmanmd




ip-l2tp

ip-l2tp

Configuration des tunnels non-gérés statiques L2TPv3

   Les commandes ip l2tp sont utilisées pour établir des tunnels statiques non-gérés L2TPv3. Pour les tunnels non-gérés il n'y a pas de protocole de contrôle L2TP donc aucun service en espace utilisateur n'est requis. Les tunnels sont créés manuellement sur le système local et sur le pair distant.

   L2TPv3 est prévu pour le tunneling niveau 2. Les tunnels statiques sont utiles pour établir des liens réseaux via les réseaux IP quand les tunnels sont fixés. Les tunnels L2TPv3 peuvent transporter des données de plus d'une session. Chaque session est identifiée par un session_id et le tunnel_id du tunnel parent. Un tunnel doit être créé avant qu'une session puisse être créé dans le tunnel.

   En créant un tunnel L2TP, l'adresse IP du paire distant est spécifié, qui peut être soit une IPv4 ou une IPv6. L'adresse IP locale utilisée pour atteindre le paire doit également être spécifié. C'est l'adresse sur laquelle le système local écoute et accepte les paquets de données L2TP du paire.

   L2TPv3 définis 2 formats d'encapsulation de paquet: UDP ou IP. L'encapsulation UDP est la plus commune. L'encapsulation IP utilise une valeur de protocole IP dédiée pour gérer les données L2TP sans la couche UDP. Utiliser l'encapsulation IP seulement quand il n'y a pas de périphérique NAT ou firewall dans le chemin réseaux.

   Quand une session Ethernet L2TPv3 est créée, une interface réseaux virtuel est créé pour la session, qui doit être configurée et activée, tout comme une autre interface réseaux. Quand une donnée est passée via l'interface, elle est passée dans le tunnel L2TP au paire. En configurant les tables de routage du système ou en ajoutant l'interface à un bridge, l'interface L2TP est comme un câble virtuel connecté au paire.

   Établir un pseudo-lien ethernet non-géré L2TPv3 implique de créer les contexts L2TP manuellement dans le système local et sur le paire. Les paramètres utilisé sur chaque site doivent correspondre ou aucune donnée ne passera. Aucune vérification de consistance n'est possible vu qu'il n'y a pas de protocole de contrôle utilisé pour établir les tunnels L2TP. Une fois l'interface réseau virtuelle configurée et activée, les données peuvent être transmises, même si le paire n'a pas été encore configuré. Si le paire n'est pas configuré, les paquets L2TP seront supprimés par le paire.

   Pour établir un tunnel L2TP non-géré, utiliser les commande l2tp add tunnel et l2tp add session décrite dans ce document. Puir configurer et activer l'interface virtuelle.

   Noter que les tunnels non-gérés ne gérent que les trames ethernet. Si vous voulez gérer du trafic PPP (L2TPv2), vous avez besoin d'un serveur L2TP qui implémente le protocole de contrôle L2TP. Le protocole de contrôle L2TP permet d'établir des tunnels et session dynamiques et fournissent un détection et correction d'erreurs.

add tunnel Ajouter un tunnel

        name NAME Définis le nom de la session de l'interface réseau. Défaut: l2tpethN
        tunnel_id ID Définis l'id du tunnel, qui est une valeur entière 32-bits assignée au tunnel par le paire. La valeur utilisé doit correspondre à la valeur tunnel_id utilisée par le paire.
        remote ADDR Définis l'adresse IP du paire distant. Peut être spécifié comme IPv4 ou IPv6.
        local ADDR Définis l'adresse IP de l'interface locale utilisée pour le tunnel. Cette adresse doit être l'adresse d'une interface locale. Peut être spécifié comme IPv4 ou IPv6.
        encap ENCAP Définis le type d'encapsulaion du tunnel (udp ou ip ).
        udp_sport PORT Définis le port source à utiliser pour le tunnel. Doit être présent quand l'encapsulation udp est utilisée.
        udp_dport PORT Définis le port upd de destination pour le tunnel. Doit être présent quand l'encapsulation udp est utilisée.

del tunnel Supprime un tunnel.

        tunnel_id ID Définis l'id du tunnel à supprimer. Toutes les sessions dans le tunnel doivent être supprimés avant.

show tunnel Affiche des informations sur les tunnels

        tunnel_id ID Définis l'id du tunnel à afficher. Non spécifié, affiche tous les tunnels

add session Ajoute une nouvelle session à un tunnel

        name NAME Définis le nom de la session de l'interface réseau. Défaut: l2tpethN
        tunnel_id ID Définis l'id du tunnel, qui est une valeur entière 32-bits assignée au tunnel par le paire. La valeur utilisé doit correspondre à la valeur tunnel_id utilisée par le paire.
        peer_session_id ID Définis l'id de session du paire, qui est une valeur entière 32-bits assignée à la session par le paire. La valeur utilisé doit correspondre au session_id utilisé par le paire.
        cookie HEXSTR Définis une valeur cookie optionnel à assigner à la session. C'est une valeur 4 ou 8 octets, ex: 014d3636deadbeef. La valeur doit correspondre à la valeur de cookie définie par le paire. La valeur du cookie est incorporée dans les paquets de données L2TP et est vérifié par le paire. N'utilise pas de cookie par défaut.
        peer_cookie HEXSTR Définis une valeur cookie du paire optionnel à assigner à la session. C'est une valeur 4 ou 8 octets, ex: 014d3636deadbeef. La valeur doit correspondre à la valeur de cookie définie par le paire. Il indique au système local quelle valeur cookie il s'attend à trouver dans les paquets L2TP reçus. N'utilise pas de cookie par défaut.
        l2spec_type L2SPECTYPE Définis le type d'en-tête spécifique à niveau 2 de la session: none ou udp
        offset OFFSET Définis l'octet dans l'en-tête L2TP où les données utilisateurs commencent dans les paquets de données transmis. Si définis, doit correspondre à la valeur peer_offset utilisé. Défaut: 0
        peer_offset OFFSET Définis l'octet dans l'en-tête L2TP où les données utilisateurs commencent dans les paquets de données reçus. Si définis, doit correspondre à la valeur offset utilisé. Défaut: 0

del session Détruit une session

        tunnel_id ID Définis l'id du tunnel dans lequel la session est localisée
        session_id ID L'id de session à supprimer

show session Affiche des informations sur les sessions

        tunnel_id ID Définis l'id du tunnel dans lequel les sessions sont affichées
        session_id ID L'id de session à afficher

Exemples

Définir des tunnels L2TP et des sessions
site-A:# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 encap udp local 1.2.3.4 remote 5.6.7.8 udp_sport 5000 udp_dport 6000
site-A:# ip l2tp add session tunnel_id 3000 session_id 1000 peer_session_id 2000
site-B:# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 encap udp local 5.6.7.8 remote 1.2.3.4 udp_sport 6000 udp_dport 5000
site-B:# ip l2tp add session tunnel_id 4000 session_id 2000 peer_session_id 1000
site-A:# ip link set l2tpeth0 up mtu 1488
site-B:# ip link set l2tpeth0 up mtu 1488
Noter que les adresse IP, ports UDP et id de session/tunnel correspondent et inversés dans chaque site.
Configurer comme interface IP
site-A:# ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0
site-B:# ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0
site-A:# ping 10.42.1.2
Configurer comme interfaces bridgés
site-A:# ip link set l2tpeth0 up mtu 1446
site-A:# ip link add br0 type bridge
site-A:# ip link set l2tpeth0 master br0
site-A:# ip link set eth0 master br0
site-A:# ip link set br0 up
En utilisant les VLAN, définis un bridge par vlan et bridger chaque VLAN sur une session L2TP séparé
site-A:# ip link set l2tpeth0 up mtu 1446
site-A:# ip link add brvlan5 type bridge
site-A:# ip link set l2tpeth0.5 master brvlan5
site-A:# ip link set eth1.5 master brvlan5
site-A:# ip link set brvlan5 up

   Ajouter l'interface L2TP à une bridge force le bridge à forwarder le trafic sur le lien L2TP comme avec une autre interface. Le bridge apprend les adresses MAC des hôtes attachés à chaque interface et forwards les frames d'un port à un autre. Les adresse IP ne sont pas assignés aux interface l2tpethN. Si le bridge est configurés correctement des 2 côté, il devrait être possible d'atteindre les hôtes dans le réseau bridgé du paire.

   Quand des frames ethernet brut son bridgé via un tunnel L2TP, de grandes frames peuvent être fragmentés et forwardés comme fragment IP individuels au destinataire, en fonction du MTU de l'interface physique utilisé par le tunnel. Quand les frames ethernet gérent les protocoles qui sont réassemblés par le destinataire, comme IP, il n'y a pas de problème. Cependant, une telle fragmentation peut causer des problèmes pour les protocoles comme PPPoE où le destinataire s'attend à recevoir des frames ethernet exactement comme transmises. Dans de tels cas, il est important que les frames quittant le tunnel soient réassemblé en une seul frame avant d'être forwardé. Pour le faire, activer le tracking de connection netfilter (conntrack) ou charger manuellement le module degrag netfilter à chaque point de tunnel.

site-A:# modprobe nf_degrag_ipv4
site-B:# modprobe nf_degrag_ipv4

   Les tunnels L2TPv3 non-gérés sont supportés par certains équipements réseaux. Dans Linux, les messages L2TP Hello ne sont pas supportés dans les tunnels non-gérés. Les message Hello sont utilisés par L2TP pour détecter les erreurs des liens pour pouvoir automatiser le rétablissement des tunnels dynamiques. Si un paire non-linux supporte les messages Hello dans les tunnels non-gérés, il doit être désactivé pour fonctionner avec Linux.

   Linux utilise par défaut le type Layer2SpecificHeader par défaut comme définis dans le protocole L2TPv3 (rfc3931).
^
15 juin 2015

htmlpdflatexmanmd




ip-link

ip-link

configuration des périphériques réseaux

Commandes

add Créé une nouveau périphérique.

        link DEVICE Spécifie le périphérique physique sur lequel opérer

                NAME Spécifie le nom du nouveau périphérique
                TYPE Spécifie le type du nouveau périphérique:

                        bridge Périphérique bridge ethernet
                        bond Périphérique bond
                        dummy Interface réseau factice
                        ifb Périphérique Intermediate Functional Block
                        ipoib Périphérique IP sur Infiniband
                        macvlan Interface basée sur une adresse de lien réseau (MAC)
                        macvtap Interface basée sur une adresse de lien réseau et TAP.
                        vcan Interface Controller Area Network
                        veth Interface ethernet virtuelle
                        vlan Interface LAN virtuelle 802.1q
                        vxlan LAN virtuel étendue
                        ip6tnl Interface tunnel IPv4|ipv6 sur IPv6
                        ipip Interface tunnel IPv4 sur IPv4
                        sit Interface tunnel IPv6 sur IPv4
                        gre Tunnel virtuel GRE sur IPv4
                        gretap Tunnel L2 virtuel GRE sur IPv4
                        ip6gre Tunnel virtuel GRE sur IPv6
                        ip6gretap Tunnel L2 virtuel GRE sur IPv6

        numtxqueues QUEUE_COUNT Spécifie le nombre de queues de transmission pour le nouveau périphérique
        numrxqueues QUEUE_COUNT Spécifie le nombre de queues de réception pour le nouveau périphérique
        index IDX Spécifie l'index désiré pour le nouveau périphérique virtuel

Support VXLAN

   Pour un lien de type VXLAN, les arguments suivants sont supportés:

        id VNI Spécifie l'identifiant physique VXLAN à utiliser
        dev PHYS_DEV Spécifie le périphérique physique à utiliser pour une communication tunnel endpoint
        group IPADDR Spécifie l'adresse IP multicast à joindre. Ne peut pas être utilisé avec remote
        remote IPADDR Spécifie l'adresse IP unicast à utiliser dans les paquets sortants quand l'adresse de lien réseau de destination n'est pas connue dans la base de forwarding de périphérique vxlan.
        local IPADDR Spécifie l'adresse IP source à utiliser dans le paquets sortants.
        ttl TTL Spécifie la valeur TTL à utiliser pour les paquets sortants
        tos TOS Spécifie la valeur TOS à utiliser pour les paquets sortants
        port MIN MAX Spécifie la plage de ports à utiliser comme ports sources UDP pour communiquer avec en endpoint dans un tunnel VXLAN
        [no]learning Spécifie si les adresses de lien réseaux et IP non-connus sont entrés dans la base de forwading VXLAN
        [no]rsc Spécifie si le route short circuit est activé
        [no]proxy Spécifie si le proxy arp est activé
        [no]l2miss Spécifie si les notifications netlink LLADR miss sont générés
        [no]l3miss Spécifie si les notifications netlink IP ADDR miss sont générés

Support IP6GRE/IP6GRETAP

   Pour un lien de type IP6GRE/IP6GRETAP, les arguments suivants sont supportés:

        remote ADDR Spécifie l'adresse IPv6 distante du tunnel
        local ADDR Spécifie l'adresse IPv6 de lien local fixe pour les paquets tunnélisés.
        [i|o]seq oseq active le séquençage des paquets sortant. iseq nécessite que tous les paquets entrants soient sérialisés
        [i|o]key KEY Utilise GRE avec la clé spécifiée. KEY est soit un nombre ou une adresse IPv4. key spécifie la même clé dans les 2 directions, ikey et okey spécifier différentes clé pour l'entrée et la sortie.
        [i|o]csum Génère/requière des checksums pour les paquets tunnelisés. ocsum calcul les checksums pour les paquets sortant et icsum nécessite que tous les paquets entrant aient un checksum correct. csum est équivalent à icsum ocsum.
        hoplimit TTL Spécifie la valeur de limite de saut à utiliser dans les paquets sortants.
        encaplimit ELIM Spécifie une limite d'encapsulation fixée. Défaut: 4
        lowlabel FLOWLABEL Spécifie un label de flux fixe
        tclass TCLASS Spécifie le champ de classe de trafic dans les paquets tunnelisés. Peut être soit une valeur hexa à 2 chiffres, ou une chaîne prédéfinie. inherit copie le champ depuis l'en-tête IP original, inherit/STRING oo inherit/00..ff servent pour les paquets non-IP tunnelisés. défaut: 00.

delete Supprime un lien virtuel

        dev DEVICE Spécifie le périphérique physique sur lequel opérer.

set Change les attributs des périphériques

        dev DEVICE Spécifie le périphérique sur lequel opérer.
        group GROUP GROUP a 2 rôles: si group et det sont présents, ils placent le périphérique dans le groupe spécifié. Si seul un groupe est spécifié, la commande opère sur tous les périphérique dans ce groupe.
        up, down Change l'état du périphérique
        arp on|off Change le flag NOARP dans le périphérique
        multicast on|off Change le flag MULTICAST dans le périphérique
        dynamic on|off Change le flag DYNAMIC dans le périphérique
        name NAME Change le nom du périphérique
        txqueuelen NUMBER
        txqlen NUMBER Change la longueur de file de transmission du périphérique
        mtu NUMBER Change le MTU du périphérique
        address LLADDRESS Change l'adresse de station de l'interface
        broadcast LLADDRESS
        brd LLADDRESS
        peer LLADDRESS Change l'adresse de broadcast de lien réseau ou l'adresse paire quand l'interface est POINTTOPOINT
        netns PID Place le périphérique dans l'espace de nom réeau associé avec le PID du processus
        netns NETNSNAME Place le périphérique dans l'espace de nom réeau associé avec le nom spécifié
        alias NAME Donne un nom symbolique à un périphérique
        group GROUP Spécifie le groupe auquel appartient le périphérique. Les groupes disponibles sont listés dans /etc/iproute2/group
        vf NUM Spécifie un périphérique de fonction virtuel à configurer. Le périphérique VF associé doit être spécifié en utilisant le paramètre dev.

                mac LLADDRESS Change l'adresse de station pour le VF spécifié. le paramètre vf doit être spécifié
                vlan VLANID Chagne le vlan assigné pour le VF spécifié.
                qos VLAN-QOS Assigne la priorité vlan pour le tag vlan.
                rate TXRATE Change la bande passante de transmission permise, en Mbps, pour le VF spécifié. 0 désactive la limite.
                max_tx_rate TXRATE Change la bande passante de transmission maximum permise, en Mbps, pour le VF spécifié.
                min_tx_rate TXRATE Change la bande passante de transmission minimum permise, en Mbps, pour le VF spécifié.
                spoofchk on|off Active la vérification de spoofing de paquets pour le VF spécifié
                state auto|enable|disable Définis l'état de lien virtuel comme vu par le VF spécifié. À auto, signifie une réflexion de l'état du lien PF, enable laisse le VF communiquer avec d'autres VF sur cet hôte même si le lien PF est down, disable force le HW à détruire tout paquet envoyé par le VF.

        master DEVICE Définis le périphérique maître du périphérique ( périphérique enslave )
        nomaster Indéfinis le périphérique maître

show Affiche les attributs du périphérique

        dev NAME Nom du périphérique à afficher. Omis, affiche tous les périphériques dans le groupe par défaut
        group GROUP Spécifie que groupe de périphérique sont affichés
        up N'affiche que les interface fonctionnelles

Exemples

ip link show
Affiche l'état de tous les liens réseaux sur le système
ip link set dev ppp0 mtu 1400
Change le MTU du périphérique ppp0
ip link add link eth0 name eth0.10 type vlan id 10
Créer une nouvelle interface vlan sur eth0
ip link delete dev eth0.10
Supprime de périphérique vlan spécifié
^
05 juillet 2015

htmlpdflatexmanmd




ip-maddress

ip-maddress

Gestion des adresses multicast

show Liste les adresses multicast

        dev NAME Nom du périphérique

add Ajoute une adresse multicast
delete Supprime une adresse multicast

        address LLADDRESS Adresse multicast le lien réseaux
        dev NAME Nom du périphérique

^
05 juillet 2015

htmlpdflatexmanmd




ip-monitor

ip-monitor, rtmon

Supervision d'état

   l'utilitaire ip peut superviser l'état des périphériques, adresses et routes en continue. Cette option a un format légèrement différent. La syntaxe est la suivante:

  ip monitor [ all | OBJECT-LIST ] [ file FILENAME ]

   OBJECT-LIST est la liste des types d'objets à superviser. Peut contenir link, address, route, mroute, prefix, neigh, netconf. Si aucun argument file n'est donné, ip ouvre RTNETLINK, écoute et dump le changements d'états.

   Si l'option file est donné, le programme n'écoute par sur RTNETLINK, mais ouvre le fichier donné, et dump son contenu. Le fichier devrait contenir des messages RTNETLINK sauvés au format binaire. Un tel fichier peut être généré avec l'utilitaire rtmon. Cet utilitaire a une syntaxe en ligne de commande similaire à ip monitor. Idéalement, rtmon devrait être démarré avec la première commande de configuration réseaux. Par exemple, si vous insérez:

rtmon file /var/log/rtmon.log

   dans un script de démarrage, vous serez capable de voir tout l'historique plus tard. Il est cependant possible de démarrer rtmon à tout moment. Il ajoute l'historique avec l'état dumpé au moment de démarrer.

^
05 juillet 2015

htmlpdflatexmanmd




ip-mroute

ip-mroute

Gestion du cache de routage multicast

   Les objets mroutes sont des entrées du cache de routage multicast crée par un service de routage au niveau utilisateur (pimd ou mouted). Dûs à la limitation de l'interface courante du moteur de routage multicast, il est impossible de changer les objets mroute administrativement, on ne peut que les afficher. Cette limitation sera supprimée dans le future.

show Liste les entrées du cache de routage mroute

        to PREFIX Le préfixe sélectionnant les adresses multicast de destination à lister
        iif NAME L'interface sur laquelle les paquest multicast sont reçus
        from PREFIX Le préfixe sélectionnant les adresses IP source des routes multicast
        table TABLE_ID L'id de table multicast. Peut être local, main, default, all ou un numéro.

^
05 juillet 2015

htmlpdflatexmanmd




ip-neighbour

ip-neighbour

Gestion des tables arp et de voisinage

   neighbour manipule les objets voisins qui établissent les liens entre les adresses de protocole et les adresses le lien réseaux pour les hôtes partageant le même lien. Les entrées de voisinage sont organisés en tables. La table de voisinage IPv4 et également connue par un autre nom - la table ARP.

add Ajoute une nouvelle entrée de voisinage
change Change en entrée existante
replace ajoute ou change une entrée existante

        to ADDRESS L'adresse de protocole IPv4 ou IPv6 du voisin
        dev NAME Interface qui est attaché au voisin
        lladdr LLADDRESS L'adresse de lien réseaux du voisin. Peut également être null
        nud NUD_STATE L'état de l'entrée voisine. nud est une abréviation pour 'Neighbour Unreachability Detection'. L'état peut prendre une des valeurs suivantes:

                permanent L'entrée est valide indéfiniment et ne peut être supprimé qu'administrativement
                noarp L'entrée est valide. Ne tente pas de valider cet entrée, mais elle peut être supprimée lorsqu'elle expire
                reachable L'entrée est valid tant que le timeout est valide
                stale L'entrée est valide mais suspicieuse.

delete Supprime une entrée de voisinage. Les argument sont les même que pour add, excepté que lladdr et nud sont ignorés.
show Liste les entrées de voisinage

        to ADDRESS préfixe qui sélectionne es voisins dans la liste
        dev NAME liste seulement les voisin attachés à ce périphérique
        proxy Liste les proxy voisins
        unused Liste seulement les voisin qui ne sont pas utilisés actuellement.
        nud NUD_STATE Liste seulement les entrées de voisinage dans cet état. NUD_STATE peut prendre les valeurs listées ou la valeurs spéciale all qui signifie tous les états. Si cette option est absente, ip liste toutes les entrées excepté pour none et noarp
        flush vide les entrées voisines. A les même arguments que show. Sans argument, les entrée vidées n'incluent pas permanent et noarp. Avec l'option -statistics, la commande devient verbeuse. Si l'option est données 2 fois, dump également toutes les entrées vidées.

Exemples

Afficher la table de voisinage dans le kernel
ip neighbour
supprimer es entrées dans la table de voisinage sur le périphérique eth0
ip neigh flush dev eth0
^
05 juillet 2015

htmlpdflatexmanmd




ip-netconf

ip-netconf

Supervision de configuration réseaux

   netconf peut superviser les paramètres IPv4 et IPv6 ( voir /proc/sys/net/ipv[4|6]/conf/[all|DEV]/ ) comme le forwarding, rp_filter ou mc_forwarding. Si aucune interface n'est spécifiée, l'entrée all est affichée.

show Affiche les paramètres réseaux

        dev NAME Nom de l'interface à afficher

^
05 juillet 2015

htmlpdflatexmanmd




ip-netns

ip-netns

gestion des espaces de noms réseaux

   Un espace de nom réseaux est logiquement une autre copie de la pile réseaux, avec ses propres routes, règle firewall, et périphériques réseaux. Par convention, un espace de nom réseaux nommé est un objet à /var/run/netns/NAME qui peut être ouvert. Maintenir ce descripteur de fichier ouvert maintient espace de noms réseaux actif. Le descripteur de fichier peut être utilisé avec l'appel système setns(2) pour changer l'espace de noms associé avec une tâche.

   Pour les applications qui comprennent les espaces de noms, la convention est de rechercher les fichiers de configuration de réseau global dans /etc/netns/NAME/, puis dans /etc/. Par exemple, si vous voulez une version différente de /etc/resolv.conf pour un espace de noms réseaux utilisé pour isoler votre vpn, il sera nommé /etc/netns/myvpn/resolv.conf.

exec automatise la manipulation de cette configuration, convention de fichier pour un espace de noms réseau d'application non prévu, en créant un espace de montage et en le liant tous les fichiers d'espace de nom réseau dans leur emplacement traditionnel dans /etc.
list Affiche tous les espaces de nom réseaux dans /var/run/netns
add NAME Créer un nouvel espace de nom réseau
delete NAME Si NAME est présent dans /var/run/netns, il est démonté et le point de montage est supprimé.
identifiy PID Recherche dans /var/run/netns tous les espaces de nom réseaux du processus spécifié.
pids NAME Recherche dans /var/run/netns tous les processus qui ont l'espace de nom réseaux nommé comme espace de nom primaire.
exec NAME cmd ... Cette commande permet aux application qui ne gèrent pas l'espace de nom réseaux d'être lancé dans un autre espace de nom réseaux autre que celui par défaut.
monitor Regarde les évènements d'ajout et de suppression d'espace de nom réseaux et affiche une ligne pour chaque événement qu'il voit.

Exemples

Afficher la liste des espaces de nom réseaux
ip netns list
Créer un espace de nom réseaux et le nomme vpn
ip netns add vpn
Ajoute d'interface de boucle local dans l'espace de nom réseaux vpn
ip netns exec vpn link set lo up
^
05 juillet 2015

htmlpdflatexmanmd




ip-ntable

ip-ntable

configuration des tables de voisinage

show Liste les tables de voisinage

        dev DEV Liste seulement la table attachée à ce périphérique
        name NAME Liste seulement la table avec le nom donné

change Modifie les paramètres de table, tels que les timers et les longueurs de file

        name NAME Nom de la table à modifier
        dev DEV Nom du périphérique dont la table est à modifier

Exemples

Afficher les paramètres de table voisine dans le périphérique eth0
ip ntable show dev eth0
Changer le nombre de paquets en queue pendant que l'adresse est résolue:
ip ntable change name arp_cache queue 8 dev eth0
^
15 juin 2015

htmlpdflatexmanmd




ip-route

ip-route

Gestion des tables de routage

   ip route est utilisé pour manipules les entrées dans les tables de routage du kernel. Les types de routes sont:

unicast L'entrée décrit des véritables chemins vers les destinations couvertes par le préfixe de route.
unreachable Ces destinations sont inatteignables. Les paquets sont supprimés silencieusement.
prohibit Ces destinations sont inatteignables. les paquets sont supprimés silencieusement et un message ICMP est généré.
local Les destinations sont assignées à cet hôte. Les paquets sont délivrés localement.
broadcast Les destinations sont des adresses de broadcast. Les paquets sont envoyés sur des liens broadcast.
throw Une route de contrôle spéciale utilisé avec les règles de stratégie. Si une telle route est séléctionée, rechercher dans cette table se termine en prétendant qu'aucune route n'a été trouvée et un ICMP unreachable est émis.
anycast non implémenté
multicast Un type spécial utilisé pour le routage multicast. N'est pas présent dans les tables de routage normales.

   Linux 2.x peut grouper les routes dans plusieurs tables de routage identifiées par un numéro dans la plage 1 à 2^31 ou par un nom depuis le fichier /etc/iproute2/rt_tables. Par défaut, toutes les routes sont insérées dans la table main (254) et le kernel n'utilise que cette table. Les valeurs 0, 253, 254 et 255 sont réservés.

   Actuellement, une autre table existe toujours, qui est invisible mais importante, la table local (255). Cette table consiste de routes pour les adresses locales et de broadcast. Le kernel maintient cette table automatiquement et l'administrateur n'a généralement pas besoin de la modifier.

   Les tables de routages multiples entrent en jeu quand des stratégies de routage sont utilisées.

add Ajouter une nouvelle route
change Changer une route
replace Changer ou ajouter une nouvelle route

        to TYPE PREFIX Préfix de destination de la route. Si type est omis, assume unicast. PREFIX est une adresse IP ou IPv6 suivi optionnellement par un masque. les PREFIX spécial default est équivalent à 0/0 ou ::/0
        tos TOS
        dsfield TOS La clé Type Of Service. Cette clé n'a pas de masque associé et le match le plus long est interprété comme: 1, compare le TOS de la route et du paquet. S'il ne sont pas égal, le paquet peut matcher une route avec un TOS 0. TOS est soit un nombre hexa 8-bits, soit un identifiant de /etc/iproute2/rt_dsfield.
        metric NUMBER
        preference NUMBER La valeur de préférence de la route. NUMBER est un nombre 32-bits arbitraire.
        table TABLEID La table où ajouter cette route. TABLEID peut être un nombre ou une chaîne du fichier /etc/iproute2/rt_tables. Si omis, assume la table main.
        dev NAME Nom du périphérique de sortie.
        via ADDRESS L'adresse du prochain saut.
        src ADDRESS L'adresse source à préférer en envoyant au destinations couvertes par le préfixe de route.
        realm REALMID Le domaine auquel la route est assignée. Peut être un nombre ou une chaîne depuis le fichier /etc/iproute2/rt_realms
        mtu MTU
        mtu lock MTU Le MTU associé avec le chemin de la destination. Si lock n'est pas utilisé, le MTU peut être mis à jours par le kernel via le Path MTU Discovery.
        window NUMBER Fenêtre TCP maximum à annoncer à ces destinations, mesurée en octets. Il limite les salves de données maximales que les paires TCP sont autorisés à nous envoyer.
        rtt TIME Le RTT (Round Trip Time) initial estimé. Si aucun suffixe n'est spécifié les unités sont des valeurs brutes passées directement au code de routage pour maintenir la compatibilité avec les versions précédentes. Sinon un suffixe de s, sec, ou secs est utilisé pour spécifier les secondes et ms, msec ou msecs pour spécifier les millisecondes.
        rttvar TIME Variante RTT initiale estimée. Les valeur sont spécifiée comme avec rtt.
        rto_min TIME TimeOut de retransmission TCP minimum à utiliser en communiquant avec cette destination. Les valeurs sont spécifiées comme pour rtt.
        ssthresh NUMBER Une estimation pour le seuil initial de début lent.
        cwnd NUMBER le clamp pour la fenêtre de congestion. Il est ignoré si le flag lock n'est pas utilisé.
        initcwnd NUMBER La taille de fenêtre initialement reçue pour les connexions à cette destination. La taille de fenêtre actuelle est cette valeur multipliée par le MSS de la connexion. La valeur par défaut est 0, signifiant l'utilisation d'une valeur Slow Start
        quickack BOOL Active/désactive ack rapide pour les connexions à cette destination.
        advmss NUMBER le MSS (Maximal Segment Size) à annoncer aux destinations en établissant des connexions TCP. Si non spécifié, Linux utilise une valeur par défaut calculée depuis le premier MTU du prochain périphérique.
        reordering NUMBER Ré-ordonnancement maximum dans le chemin vers cette destination. Si non donné, Linux utilise la valeur sélectionnée avec sysctl (net/ipv4/tcp_reordering)
        nexthop NEXTHOP Le prochain saut d'une route multi-path. NEXTHOP est une valeur complexe avec sa propre syntaxe similaire à la liste des argument top-level:

                via ADDRESS Router suivant
                dev NAME Périphérique de sortie
                weight NUMBER Poid pour cet élément d'une route multi-path reflétant sa bande passante relative ou qualité.

        scope SCOPE_VAL Le scope des destinations couvertes par le préfixe de route. SCOPE_VAL peut être un nombre ou une chaîne du fichier /etc/iproute2/rt_scopes. Si omis, ip assume le scope global pour toutes les routes unicast avec gateway, le scope link pour toutes les routes unicast et broadcast directes, et le scope host pour les routes locales.
        protocol RTPROTO L'identifiant de protocole de routage de cette route. RTPROTO peut être un nombre ou une chaîne depuis le fichier /etc/iproute2/rt_protos. De nombreuses valeurs de protocole one une interprétation fixée:

                redirect La route a été installée due à une redirection ICMP
                kernel La route a été installée par le kernel durant l'autoconfiguration
                boot La route a été installée durant la séquence de boot.
                static La route a été installée par l'administrateur
                ra La route a été installée par Router Discovery Protocol.

        onlink Prétend que le prochain saut est directement attaché à ce lien, même s'il ne matche pas de préfixe d'interface.

delete Supprime une route. A les même arguments que ip route add, mais leur sémantique sont un peu différents. Les valeur de clé (to, tos, preference et table) sélectionnent la route à supprimer. Si des attributs optionnels sont présents, ip vérifie qu'ils coïncident avec les attributs de la route à supprimer. Si aucune route n'est trouvée, ip route del échoue.
show Liste les routes. La commande affiche le contenu des tables de routage ou des routes sélectionnées par les critères.

        to SELECTOR Sélectionne seulement les routes depuis la plage de destinations données. SELECTOR consiste d'un modifier optionnel (root, match ou exact) et d'un préfixe. root PREFIX sélectionne les routes avec les préfixes pas plus cours que PREFIX. ex: root 0/0 sélectionne toute la table de routage. match PREFIG sélectionne les routes avec les préfixe pas plus long que PREFIX. ex: match 10.0/16 sélectionne 10.0/16, 10/8 et 0/0, mais pas 10.1/16 et 10.0.0/24. exact PREFIX sélectionne les routes avec le préfixe exact. Non spécifié, assume root 0/0.
        tos TOS
        dsfield TOS Selectionne seulement les routes avec le TOS donné
        table TABLEID Affiche les routes depuis cette table. défaut: table main. TABLEID peut être soit l'ID soit le nom de la table, ou une des valeurs spéciales:

                all Liste toutes les tables
                cache dump le cache de routage

        cloned
        cached Liste les routes clonnées, par ex. les routes qui ont été forkée dynamiquement depuis d'autres routes parce que certains attributs de route ont été mis à jours (ex: MTU). Actuellement équivalent à table cache.
        from SELECTOR Même syntaxe que to, mais lie la plage d'adresse source au lieu de destination. ne fonctionne qu'avec les routes clonées.
        protocol RTPROTO Liste seulement les routes de ce protocole
        scope SCOPE_VAL Liste seulement les routes dans ce scope
        type TYPE Liste seulement les routes de ce type
        dev NAME Liste seulement les routes allant via ce périphérique
        via PREFIX Liste seulement les routes allant via les routeurs de prochains saut sélectionnés par PREFIX
        src PREFIX Liste seulement les routes avec les adresses sources préférées sélectionnées par PREFIX
        realm REALMID
        realms FROMREALM/TOREALM Liste seulement les routes avec ces domaines

flush Vide les routes sélectionnée par certains critères. Les arguments ont la même syntaxe et sémantique de ip route show, mais les tables de routage ne sont pas listées, mais purgées. La seule différence est l'action par défaut: show dump toute la table de routage main, mais flush affiche l'aide. Avec l'option -statistics, la commande devient verbeuse. Si donné 2 fois, dumps également toutes les routes supprimées.
get Récupère une simple route et affiche sont contenu exactement comme le kernel la vois.

        to ADDRESS Adresse de destination
        from ADDRESS Adresse source
        tos TOS
        dsfield TOS Le type de service
        iif NAME Le périphérique depuis lequel ce paquet est prévu d'arriver
        oif NAME Force le périphérique de sortie sur lequel ce paquet sera routé.
        connected Si aucune adresse source (option from) n'est donnée, recherche la route avec le jeu source à l'adresse préférée reçue depuis la première recherche.

           Noter que cette opération n'est pas équivalente à ip route show. show affiche les routes de sortie. get les résous et créé de nouveaux clones is nécessaire. Essentiellement, get est équivalent à envoyer un paquet sur ce chemin. Si iif n'est pas donné, le kernel créé une route pour sortir les paquets via de destination demandée. C'est équivalent à pinger la destination avec un ip route ls cache, cependant, aucun paquet n'est actuellement envoyé. Avec iif, le kernel prétent qu'un paquet est arrivé depuis cette interface et recherche un chemin pour forwarder le paquet.

save Sauvegarde les information de la table de routage. Fonctionne comme show, excepté que la sortie est une donnée utilisable par restore.
restore Restaure les informations de table de routage

Exemples

Affiche toutes les entrées de route dans le kernel:
ip ro
Ajoute une route par défaut via 192.168.1.1 qui peut être atteins via eth0:
ip route add default via 192.168.1.1 dev eth0
^
15 juin 2015

htmlpdflatexmanmd




ip-rule

ip-rule

Gestion de la base de stratégie de routage

   ip rule manipule les règles de la base de stratégie de routage contrôlant l'algorithme de sélection de route. Les algorithmes classiques de routage utilisant dans l'Internet créent des décisions de routage basé seulement sur l'adresse de destination des paquets ( et en théorie, mais pas en pratique, sur le champs TOS ).

   Dans certaines circonstances on veut router les paquets différemment en fonction d'autres champs du paquet: le protocole IP, ports du protocole de transport, etc. Cette tâche est appelée 'stratégie de routage'.

   Pour résoudre cette tâche, la destination conventionnelle basée sur une table de routage, ordonnée en accord avec la règle de correspondance la plus longue, et remplacée avec une base de données de stratégie de routage (RPDB), qui sélectionne les routes en exécutant certains jeux de règles.

   Chaque règle de stratégie de routage consiste d'un sélecteur et d'une action prédictive. Le RPDB est scanné dans l'ordre décroissant de priorité. Le sélecteur de chaque règle est appliqué à {source address, destination address, incoming interface, tos, fwmark} et, si le sélecteur matche le paquet, l'action est effectuée. La prédiction de l'action peut retourner un succès. Dans ce cas, il va soit donner une route ou une indication d'erreur et la recherche RPDB se termine. Sinon, le programme RPDB continue avec la règle suivante.

   Sémantiquement, l'action naturelle est de sélectionner le prochain saut et le périphérique de sortie. Au démarrage le kernel configure le RPDB consistant des 3 règles:

1. Priorité: 0, Selecteur: match tout, Action: recherche dans la table de routage local (ID 255). La table local est une table de routage spéciale contenant des routes de contrôle hautement prioritaire pour les adresses locales et de broadcast. La règle 0 est spéciale, elle ne peut pas être supprimée ou écrasée.
2. Priorité: 32766, Sélecteur: match tout, Action: Recherche dans la table de routage main (ID 254). La table main est la table de routage normale contenant toutes les routes sans stratégie. Cette règle peut être supprimée et/ou écrasée.
3. Priorité: 32767, Sélecteur: match tout, Action: recherche dans la table de routage default (ID 253). La table default est vide. Elle est réservée pour certains pré-traitements si aucune règle par défaut précédente n'a séléctionné le paquet. Cette règle peut également être supprimée.

   Chaque entrée RPDB a différents attributs additionnels. Par exemple, chaque règle a un pointer vers une table de routage. les règles NAT et masquerading ont un attribut pour sélectionner une nouvelle adresse IP à modifier. Derrière ça, les règles ont certains attributs optionnels, quelles routes ont, nommés realms. Ces valeurs n'écrasent pas celles contenue dans les tables de routage. Elles sont seulement utilisée si la route n'a sélectionné aucun attribut.

   Le RPDB peut contenir des règles de types suivants:

        unicast La règle stipule de retourner la route trouvée dans la table de routage référencée par la règle
        blackhole La règle stipule de supprimer le paquet
        unreachable La règle stipule de générer une erreur 'Network is unreachable'
        prohibit La règle stipule de générer une erreur 'Communication is administratively prohibited'
        nat La règle stipule de traduire l'adresse source du paquet IP en une autre valeur

add Insert une nouvelle règle
delete Supprime une règle

        type TYPE le type de cette règle.
        from PREFIX Sélectionne le préfixe source à matcher
        to PREFIX Sélectionne le préfixe de destination à matcher
        iif NAME Sélectionne le périphérique entrant à matcher. Si l'interface est la boucle locale, la règle matche seulement les paquets venant de cet hôte. Cela signifie que vous pouvez créer des tables de routage séparés pour les paquets venant des sockets locaux de ceux liés à un périphérique.
        oif NAME Sélectionne le périphérique sortant à matcher. L'interface sortant est seulement disponible pour les paquets venant de sockets locaux qui sont liés à un périphérique.
        tos TOS
        dsfield TOS Sélectionne la valeur TOS à matcher
        fwmark MARK Sélectionne la valeur fwmark à matcher
        priority PREFERENCE La priorité de cette règle. Chaque règle devrait avoir un jeu explicite de valeur de priorité unique.
        table TABLEID L'identifiant de table de routage à rechercher si la règle matche. Il est également possible d'utiliser une recherche au lieu d'une table
        suppress_prefixlength NUMBER Rejète les décisions de routage qui on une longueur de préfix de NUMBER ou moins
        suppress_ifgroup GROUP Rejète les décisions qui utilisent un périphérique appartenant au groupe d'interface spécifié.
        realms FROM/TO domaine à sélectionner si la règle a matché et que la recherche dans la table de routage a réussie. realms TO est seulement utilisé si la route ne sélectionne aucun domaine.
        nat ADDRESS La base du block d'adresse IP à traduire (pour les adresses source). ADDRESS peut être soit le début du block des adresses NAT (sélectionné par routes NAT) ou une adresse de l'hôte local (ou même 0). Dans le dernier cas le routeur ne traduit pas les paquets, mais les masquerade à cette adresse. Utiliser map-to au lieu de nat est la même chose.

flush dumps également toutes les tables supprimées
show Liste les règles

^
05 juillet 2015

htmlpdflatexmanmd




ip-tcp_metrics

ip-tcp_metrics

Gestion des métriques TCP

   ip tcp_metrics est utilisé pour manipuler les entrées dans le kernel qui conserve les informations TCP pour les destinations IPv4 et IPv6. Les entrées sont créées quand les sockets TCP veulent partager des informations pour les destinations et sont stockés dans un cache assortis par l'adresse de destination. Les informations sauvegardées peuvent inclure des valeurs pour les métriques (initialement obtenus depuis les routes), TSVAL récent pour recycler les TIME-WAIT, l'état pour Fast Open, etc. Pour des raisons de performances le cache ne peut pas grandir au delà de la limite configurée et les anciennes entrées sont remplacées avec les nouvelles informations. Le kernel ne supprime jamais d'entrées, elles peuvent seulement être vidées avec cet outil.

show Affiche les entrées cachées.

        adress PREFIX préfixe ou adresse IPv4/IPv6. non spécifié, affiche toutes les entrées.

   La sortie peut contenir les informations suivante:

        age ‹S.MMM›sec Temps depuis que l'entrée a été créée ou mise à jours. L'entrée est réinitialisée et rafraîchie à l'utilisation des métrique depuis les routes si les métriques ne sont pas mis à jours dans la dernière heure.
        cwnd ‹N› Valeur métrique CWND
        fo_cookie ‹HEX-STRING› Valeur cookie reçue dans SYN-ACK à utiliser par Fast Open pour les prochains SYN.
        fo_mss ‹N› Valeur MSS reçue dans SYN-ACK à utiliser par Fast Open pour les prochain SYN
        fo_syn_drops ‹N›/‹S.MMM›sec ago Nombre de suppression opur les SYN Fast Open sortant initiaux avec les données détectées en monitorant le SYN-ACK reçus après la retransmission SYN.
        reordering ‹N› Valeur métrique réordonnée
        rtt ‹N›us Valeur métrique RTT
        rttvar ‹N›us Valeur métrique RTTVAR
        ssthresh ‹SSTHRESH› Valeur métrique SSTHRESH
        tw_ts ‹TSVAL›/‹SEC›sec ago TSVAL récent et les secondes après l'avoir sauvé dans le socket TIME-WAIT

delete Supprime une simple entrée. Accepte le paramètre address
flush Vide les entrées sélectionnés par critère. A les même arguments que show.

Exemples

Affiche les entrées pour les destinations depuis un sous-réseaux
ip tcp_metrics show address 192.168.0.0/24
Idem mais le mot clé address est optionnel
ip tcp_metrics show 192.168.0.0/24
Tout afficher est l'action par défaut
ip tcp_metrics
Supprimer l'entrée pour 192.168.0.1 du cache
ip tcp_metrics delete 192.168.0.1
Supprimer les entrées pour les destinations du sous-réseaux
ip tcp_metrics flush 192.168.0.0/24
Supprimer toutes les entrées du cache
ip tcp_metrics flush all
Supprime toutes les entrées IPv6 du cache
ip -6 tcp_metrics flush all
^
05 juillet 2015

htmlpdflatexmanmd




ip-token

ip-token

Support d'identifiant d'interface tokenisé

Commandes

   Le support d'identifiant d'interface tokenisé IPv6 est utilisé pour assigner les adresses de partie hôte connus aux nœuds tout en obtenant un préfixe réseaux global depuis les annonces routeurs. La cible principale pour les identifiants tokenisés sont les plateformes serveurs où les adresses sont généralement configurées manuellement, au lieu d'utiliser DHCPv6 ou SLAAC. En utilisant les identifiant tokenisés, les hôtes peuvent encore déterminer leur préfixe réseau en utilisant SLAAC, mais plus facilement être re-numérotés si leur préfixe réseaux change. Les identifiants IPv6 tokenisés sont décris dans draft-chown-6man-tokenised-ipv6-identifiers-02

set Définis le token d'interface dans le kernel. Un fois définis, il ne peut plus être supprimé de l'interface, seulement écrasé.

        TOKEN L'identifiant
        dev DEV L'interface réseaux

get Affiche un identifiant d'interface tokenisé d'un périphérique réseaux partiulier. Accepte l'argument dev.
list Liste tous les identifiants d'interface tokenizés pour les interfaces réseaux du kernel.
^
15 juin 2015

htmlpdflatexmanmd




ip-tunnel

ip-tunnel

Gestion des tunnels

   les objets tunnel sont des tunnels, des paquets encapsulés dans des paquets IP et envoyés sur une infrastructure IP. La famille d'adresse encapsulée est spécifiée par l'option -f (défaut: IPv4).

add Ajoute un nouveau tunnel
change Change un tunnel existant
delete Supprime un tunnel

        name NAME Sélectionne le périphérique tunnel nommé
        mode MODE Définis le mode de tunnel. Pour IPv4: ipip, sit, isatap et gre. Pour IPv6: ip6ip6, ipip6 ip6gre, et any.
        remote ADDRESS Définis le endpoint distant du tunnel
        local ADDRESS Définis l'adresse locale fixée pour les paquets tunnélisés. Doit être une adresse sur une autre interface de cet hôte.
        ttl N Définis un TTL N fixé dans les paquets tunnelisés. 0 (défaut pour ipv4) signifie que les paquets héritent de la valeur TTL. défaut pour ipv6: 64
        tos T
        dsfield T
        tclass T Définis le type de service (IPv4) ou la classe de trafic (IPv6) dans les paquets tunnelisés, qui peuvent être spécifiés en hexa ou avec une chaîne prédéfinie. La valeur inherit copie le champ depuis l'en-tête IP d'origine. Les valeurs inherit/STRING ou inhesit/00..ff vont définir le champ à STRING ou 00..ff en tunnelisant les paquets non-IP. Défaut: 00.
        dev NAME Lie le tunnel au périphérique nommé pour que les paquets tunnelisés soient seulement routés via ce périphérique et ne sera pas capable de sortir par un autre périphérique quand la route vers le endpoint change.
        nopmtudisc Désactive le Path MTU Discovery sur ce tunnel. Il est activé par défaut. Noter qu'un ttl fixé est incompatible avec cette option.
        key K
        ikey K
        okey K (tunnels GRE uniquement) Utilise la clé K. K est soit un numéro ou une IP. Le paramètre key définis la clé à utiliser dans les 2 directions. ikey et okey définissent différentes clé pour l'entrée et la sortie.
        csum, icsum, ocsum (tunnels GRE uniquement) Génère/impose des checksums pour les paquets tunnelisés. csum est équivalent à icsum ocsum.
        seq, iseq, oseq (tunnels GRE uniquement) Sérialise les paquets. seq est équivalent à iseq oseq.
        encaplim ELIM (tunnels IPV6 uniquement) Définis une limite d'encapsulation fixée. (défaut: 4).
        flowlabel FLOWLABEL (tunnels IPV6 uniquement) Définis un flowlabel fixe.

prl potential router list (ISATAP uniquement)

        dev NAME Nom du périphérique obligatoire
        prldefault ADDR
        prl-nodefault ADDR
        prl-delete ADDR Ajoute ou supprime ADDR comme routeur potentiel ou routeur par défaut.

show Liste les tunnels.

^
15 juin 2015

htmlpdflatexmanmd




ip-xfrm

ip-xfrm

transform configuration

   xfrm est un framework ip pour transformer les paquets ( tel que le chiffrement de leur payloads ). Ce framework est utilisé pour implémenter la suite de protocole IPsec ( avec l'objet state opérant dans la base d'association de sécurité, et l'objet policy opérant dans la base de stratégie de sécurité ). Il est également utilisé pour le protocole de compression de payloads et les fonctionnalités IPv6 mobile.

monitor Monitor l'état des objets xfrm
state gére les états dans xfrm

        add Ajoute un nouvel état dans xfrm
        update Met à jours un état existant dans xfrm
        allocspi Alloue une valeur SPI
        delete Suppime un état existant dans xfrm
        get Récupère un état dans xfrm
        deleteall supprime tous les états dans xfrm
        list Affiche la liste des états dans xfrm
        flush vide tous les état dans xfrm
        count compte tous les états existant dans xfrm

                ID est spécifié par l'addresse source, l'adresse de destination, le protocole de transformation XFRM-PROTO, et/ou SPI (Security Parameter Index).
                XFRM-PROTO Spécifie le protocole de transformation: IPsec Encapsulating Security (esp), IPsec Authentication Header (ah), IP payload Compresion (comp), Mobile IPv6 Type 2 Routing Header (route2), ou Mobile IPv6 Home Address Option (hao)
                ALGO-LIST Contient un ou plusieurs algorithmes à utiliser. Chaque algorithme ALGO est spécifié par:

                        - Le type d'algorithme: encryption (enc), authentication (auth ou auth-trunc), authenticated encryption with associated data (aead), or compression (comp)
                        - Le nom de l'algorithme ALGO-NAME
                        - (excepté pour comp): le clé matérielle (ALGO-KEYMAT), qui peut inclure une clé et un salt ou une aucune valeur.
                        - (aead uniquement): la longueur Integrity Check Value ALGO-ICV-LEN en bits.

                        les algorithmes de chiffrement incluent: ecb(cipher_null), cbc(des), cbc(des3_ede), cbc(cast5), cbc(blowfish), cbc(aes), cbc(serpent), cbc(camellia), cbc(twofish), et rfc3686(ctr(aes)).
                        Les algorithmes d'authentification inculent: digest_null, hmac(md5), hmac(sha1), hmac(sha256), hmac(sha384), hmac(sha512), hmac(rmd610), et xcbc(aes).
                        Le chiffrement authentifié avec algorithme de données associée (AEAD) incluent: rfc4106(gcm(aes)), rfc4309(ccm(aes)), et rfc4543(gcm(aes)).
                        Les algorithmes de compression incluent deflate, lzs et lzjh.

                MODE Spécifie un mode d'opérations pour le protocole de transformation. les modes IPsec et IP Payload Compression sont transport, tunnel, et pour IPsec ESP beet (Bound End-to-End Tunnel). les modes Mobile IPv6 sont route optimiszation (ro) et bound trigger (in_trigger).
                FLAG-LIST Contient un ou plusieurs flags optionnels suivants: noecn, decap-dscp, nopmtudisc, wildrecv, icmp, af-unspec ou align4
                SELECTOR Sélectionne le trafic qui sera contrôlé par la stratégie, basée sur l'adresse source, l'adresse de destination, le périphérique réseau, et/ou UPSPEC.
                UPSPEC Sélection le trafic par protocole. Pour tcp, udp, sctp ou dccp, le port source et de destination peut optionnellement être spécifié. Pour les protocoles icmp, ipv6-icmp, ou mobility-headers, le type et le code peuvent optionnellement être spécifiés. Pour le protocole gre, la clé peut optionnellement être spécifié. D'autre protocoles peuvent être sélectionnés par nom ou nombre PROTO.
                LIMIT-LIST Définis les limites en secondes, octets, ou nombres de paquets.
                ENCAP Encapsule les paquets avec le protocole espinudp, espinudp-nonike, en utilisant le port source SPORT, le port de destination DPORT, et l'adresse originel OADDR.

policy Gère les stratégies dans xfrm

        add Ajoute une nouvelle stratégie
        update Met à jour une stratégie existante
        delete Supprime une stratégie existante
        get Récupère une stratégie existante
        deleteall Supprime toutes les stratégies xfrm
        list Affiche toutes les stratégies xfrm existant
        flush Vide les stratégies
        count Compte les stratégies existantes

                SELECTOR Sélectionne le trafic qui sera contrôlé par la stratégie, basée sur l'adresse sources, l'adresse de destination, le périphérique réseaux, et/ou UPSPEC.
                UPSPEC Sélectionne le trafic par protocole. Pour tcp, udp, sctp, ou dccp, le port source et de destination peuvent être optionnellement spécifiés. Pour les protocoles icmp, ipv6-icmp, ou mobility-header, le type et le code peuvent être optionnellement spécifiés. Pour le protocole gre, la clé peut optionnellement être spécifié. D'autres protocoles peuvent être spécifiés par nom ou numéro PROTO.
                DIR Sélectionne la direction de la stratégie: in, out ou fwd
                CTX Définis le contexte de sécurité
                PTYPE Peut être main (défaut) ou sub
                ACTION Peut être allow (défaut) ou block
                PRIORITY Nombre (défaut: 0)
                FLAG-LIST Contient un ou plusieurs flags optionnels: local ou icmp
                LIMIT-LIST Définis les limites en secondes, octets, ou nombre de paquets
                TMPL-LIST Liste template spécifiée en utilisant ID, MODE, REQID, et/ou LEVEL
                ID Spécifié par l'adresse source, l'adresse de destination, le protocole de transformation XFRM-PROTO, et/ou SPI.
                XFRM-PROTO Spécifie le protocole de transformation: IPsec Encapsulating Security (esp), IPsec Authentication Header (ah), IP payload Compresion (comp), Mobile IPv6 Type 2 Routing Header (route2), ou Mobile IPv6 Home Address Option (hao)
                MODE Spécifie un mode d'opérations pour le protocole de transformation. les modes IPsec et IP Payload Compression sont transport, tunnel, et pour IPsec ESP beet (Bound End-to-End Tunnel). les modes Mobile IPv6 sont route optimiszation (ro) et bound trigger (in_trigger).
                LEVEL Peut être required (défaut) ou use.

^
25 mars 2016

htmlpdflatexmanmd




ipcmk

ipcmk

Créer des ressources IPC

OPTIONS

-M, --shmem Créé un segment de mémoire partagé de la taille spécifiée, en octets par défaut.
-Q, --queue Créé une file de message
-S, --semaphore Créé un tableau de sémaphore avec le nombre d'éléments spécifiés
-p, --mode Permissions d'accès pour la ressource. Défaut: 0644
^
25 mars 2016

htmlpdflatexmanmd




ipcrm

ipcrm

supprimer des ressources IPC

   ipcrm supprime des objets IPC et les structures de données associées du système. Pour supprimer de tels objets, vous devez être root, ou le créateur ou le propriétaire de l'objet.

   les objets IPC system V sont de 3 types: mémoire partagée, files de messages, et sémaphore. La suppression d'objet de type file de message ou sémaphore est immédiate. Un objet de mémoire partagé est seulement supprimé après que tous les processus attaché se soient détaché de l'objet

   2 syntaxes sont supportées. L'ancienne syntaxe spécifie un mot clé à 3 lettres indiquant quelle classe d'objet doit être supprimer, suivi par un ou plusieurs identifiant IPC pour les objets de ce type.

   La syntaxe SUS-compliant permet la spécification de 0 ou plusieurs objets de tous les 3 types dans une simple ligne de commande, avec les objets spécifiés soit par clé soit par identifiant. Les clé et les identifiants peuvent être spécifiés en décimal, hexadécimal, ou octal.

   Les identifiants et clé peuvent être trouvés en utilisant la commande ipcs.

OPTIONS

-a, --all [shm] [msg] [sem] Supprime toutes les ressources. Quand une option est fournie, la suppression est effectuée seulement pour le type de ressource spécifié.
-M, --shmem-key Supprime le segment de mémoire partagé créé avec la clé spécifiée après que le dernier détachement est été effectué
-m, --shmem-id idem, en spécifiant son id
-Q, --queue-key Supprime le file de message créé avec la clé spécifiée
-q, --queue-id idem, en spécifiant son id
-S, --semaphore-key Supprime le sémaphore créé avec la clé spécifiée
-s, --semaphore-id idem, en spécifiant son id
^
25 mars 2016

htmlpdflatexmanmd




ipcs

ipcs

Afficher des renseignements sur l'utilisation des ressources IPC

   ipcs affiche des informations sur les ressources des communication interprocess pour lesquels le processus appelant a accès en lecture. Par défaut, affiche 3 ressources: le segment de mémoire partagé, file de messages et les tableaux de sémaphores

OPTIONS

-i, --id Affiche des détails sur la ressource spécifiée par son id. Doit être combiné avec -m, -q ou -s
-m, --shmems Affiche des informations sur les segments mémoire partagés actifs
-q, --queues Affiche des informations sur les files de messages actives
-s, --semaphores Affiche des informations sur les jeux de sémaphore actifs
-a, --all Affice toutes les informations
-c, --creator Affiche le createur et le propriétaire
-l, --limits Affiche les limites de ressources
-p, --pid Affiche les PID du créateur et le dernier opérateur
-t, --time Affiche les informations de temps.
-u, --summary affiche un sommaire du status
-b, --bytes Affiche les tailles en octets
--human Affiche les tailles au format human-readable.
^
18 septembre 2016

htmlpdflatexmanmd




ippfind

ippfind

Trouver des imprimantes réseaux

   ippfind trouve les services enregistrés avec un serveur DNS ou disponibles via des périphériques locaux. Son principal but est de trouver les imprimantes IPP et d'afficher leurs URI, afficher leur status actuel, ou lancer des commandes.

Types d'enregistrement

_http._tcp HTTP, rfc2616
_https._tcp HTTPS, rfc2818
_ipp._tcp IPP, rfc2911
_ipps._tcp IPPS, draft
_printer._tcp LPD, rfc1179

Expressions

   ippfind supporte les expressions comme find(1). Cependant, à la différence de find, ippfind utilise les expressions régulières POSIX au lieu des motifs de correspondance shell. Si --exec, -l, --ls, -p, --print, --print-name, -q, --quiet, -s ou -x ne sont pas spécifiés, ippfind ajoute --print.

-d regex, --domain regex Vrai si le domaine correspond à l'expression régulière
--false Toujours faux
-h regex, --host regex Vrai si le nom d'hôte correspond à l'expression régulière
-l, --ls Liste les attributs retournés par Get-Printer-Attributes pour les imprimantes IPP et sort les URLs HTTP.
--local Vrai si le service est local à cette machine
 -n regex, --name regex Vrai si le nom de l'instance du service correspond à l'expression régulière
--path regex Vrai si le chemin de ressource URI correspond à l'expression régulière
-P number[-number], --port number[-number] Vrai si le port correspond à la plage de nombre donnée
-p, --print Imprime l'URI si le résultat des expressions précédentes sont vrai. Le résultat est toujours vrai
-q, --quiet Mode silencieux, retourne simplement les codes de sortie
-r, --remote Vrai si le service n'est pas local
-s, --print-name Imprime le nom de l'instance du service si le résultat de la précédente expression est vrai. Le résultat est toujours vrai
--true Toujours vrai
-t key, --txt key Vrai si l'enregistrement TXI contient la clé nommée
--txt-key regex Vrai si l'enregistrement TXT contient la clé nommé et correspond à l'expression régulière
-u regex, --uri regex Vrai si l'URI correspond à l'expression régulière
-x utility [ argument ... ], --exec utility [ argument ... ] ; Exécute le programme spécifié si le résultat courant est vrai. Les arguments "{foo}" sont remplacées avec la valeur correspondante (voir les substitutions)

   Les expressions peuvent également contenir les modifiers suivants:

( expression ) Groupe le résultat des expressions
! expression, --not expression Inverse le sens de l'expression
expression --and expression ET logique
expression --or expression OU logique

Substitutions

{service_domain} Nom de domaine
{service_hostname} Nom de l'instance du service
{service_port} Numéro de port pour le serveur
{service_regtype} Type d'enregistrement DNS-SD
{service_scheme} Schéma d'URI pour le type d'enregistrement DNS-SD
{service_uri} URI pour le service
{txt_key} Valeur de l'enregistrement TGT key (en minuscule)

OPTIONS

-4 Utilise IPv4
-6 Utilise IPv6
-T seconds Timeout en secondes. À 1 ou inférieur, ippfind stop dès qu'il pense avoir tout trouvé
-V version Version IPP.

Variables d'environnement

IPPFIND_SERVICE_DOMAIN Nom de domaine
IPPFIND_SERVICE_HOSTNAME FQDN
IPPFIND_SERVICE_NAME Nom de l'instance du service
IPPFIND_SERVICE_PORT Numéro de port pour le serveur
IPPFIND_SERVICE_REGTYPE Type d'enregistrement DNS-SD
IPPFIND_SERVICE_SCHEME Schéma d'URI pour le type d'enregistrement DNS-SD
IPPFIND_SERVICE_URI URI pour le service
IPPFIND_TXT_KEY Valeur de l'enregistrement TYT pour KEY (majuscule)

Exemples

Affiche le status de toutes les imprimantes IPP enregistrés sur le réseaux
ippfind --ls
Envoyer une page de test PostScript à toutes les imprimantes PostScript
ippfind --txt-pdl application/postscript --exec ipptool -f onepage-letter.ps '{}' print-job.test
^
18 septembre 2016

htmlpdflatexmanmd




ipptool

ipptool

Effectuer des requêtes ipp

   ipptool envoie des requêtes IPP à l'uri spécifiée et test et/ou affiche le résultat. Chaque fichier de test spécifié définis une ou plusieurs requêtes, incluant le status de réponse attendu, attributs, et valeurs. La sortie est soit un texte, un texte formaté, un CSV, ou un rapport XML.

OPTIONS

--stop-after-include-error Stop si une erreur se produit dans un fichier inclus.
-4 Utilise IPv4
-6 Utilise IPv6
-C Spécifie que les requêtes devraient être envoyées en utilisant l'en-tête HTTP/1.1 "Transfer-Encoding: chunked", qui est requis pour être conforme avec toutes les versions IPP.
 -E Chiffrer la connexion au serveur en utilisant l'en-tête HTTP "Upgrade"
-I Continue même si des erreurs sont rencontrées
-L Spécifie que les requêtes devraient être envoyées en utilisant l'en-tête HTTP/1.0 "Content-Length:" qui est requis pour être conforme avec toutes les versions d'IPP.
-P filename.plist Spécifie que le résultat du test devrait être écrit dans e fichier XML nommé, en plus du rapport texte (-t). Incompatible avec -i et -n
-S Force le chiffrement TLS au serveur dédié.
-T seconds Spécifie un timeout pour les requêtes IPP en secondes
-V version Spécifie la version IPP par défaut. Défaut: 1.1
-X Spécifie que la sortie XML (plist) est souhaité au lieu d'un rapport texte. Incompatible avec -i et -n
-c Spécifie que la sortie CSV est souhaité au lieu d'un rapport texte.
-d name=value Définis une variable
-f filename Définis le fichier requête par défaut pour les tests
-l Spécifie que la sortie texte clair est souhaitée
-i seconds Spécifie que le dernier testfile devrait être répété à interval spécifié. Incompatible avec -X.
repeat-count Spécifie que le dernier testfile devrait être répété plusieurs fois. Incompatible avec -X
-q mode silencieux
-t Spécifie que le rapport de test est souhaité au lieu d'une sortie texte clair
-v Spécifie que tous les attributs de requête et réponse soient affichés en mode test.

Exemples

Obtenir une liste de jobs terminés pour myprinter
ipptool ipp://localhost/printers/myprinter get-completed-jobs.test
Envoyer des notifications par mail quand myprinter change
ipptool -d recipient=mailto:user@example.com ipp://localhost/printers/myprinter create-printer-subscription.test

Fichiers

Les fichiers standards suivants sont disponibles:
color.jpg
create-printer-subscription.test
document-a4.pdf
document-a4.ps
document-letter.pdf
document-letter.ps
get-completed-jobs.test
get-jobs.test
get-notifications.test
get-printer-attributes.test
get-subscriptions.test
gray.jpg
ipp-1.1.test
ipp-2.0.test
ipp-2.1.test
ipp-2.2.test
ipp-everywhere.test
onepage-a4.pdf
onepage-a4.ps
onepage-letter.pdf
onepage-letter.ps
print-job.test
print-job-deflate.test
print-job-gzip.test
testfile.jpg
testfile.pcl
testfile.pdf
testfile.ps
testfile.txt
validate-job.test
^
14 septembre 2016

htmlpdflatexmanmd




ipptoolfile

ipptoolfile

Format de fichier ipptool

Le programme ipptool accepte les fichiers texte libre qui décrivent une ou plusieurs requêtes IPP. Par exemple:
# This is a comment
{
    # The name of the test
    NAME "Print PostScript File"
    
    # The request to send
    OPERATION Print-Job
    GROUP operation-attributes-tag
    ATTR charset attributes-charset utf-8
    ATTR language attributes-natural-language en
    ATTR uri printer-uri $uri
    ATTR name requesting-user-name $user
    FILE testfile.ps
    
    # The response to expect
    STATUS successful-ok
    EXPECT job-id OF-TYPE integer WITH-VALUE ؎
    EXPECT job-uri OF-TYPE uri
}
{
    # The name of the test
    NAME "Get Attributes of PostScript Job"
    
    # The request to send
    OPERATION Get-Job-Attributes
    GROUP operation-attributes-tag
    ATTR charset attributes-charset utf-8
    ATTR language attributes-natural-language en
    ATTR uri printer-uri $uri
    ATTR integer job-id $job-id
    ATTR name requesting-user-name $user
    
    # The response to expect
    STATUS successful-ok
    EXPECT job-id OF-TYPE integer WITH-VALUE $job-id
    EXPECT job-uri OF-TYPE uri
    EXPECT job-state OF-TYPE enum WITH-VALUE 3,4,5,6,7,8,9
    EXPECT job-originating-user-name OF-TYPE name WITH-VALUE "$user"
}

Directives top-level

{ test } Définis un test
DEFINE variable-name value Définise une variable. Équivalent à -d variable-name=value.
DEFINE-DEFAULT variable-name value Définis la variable si elle n'a pas de valeur
FILE-ID "identifier" Spécifie un identifiant pour le fichier courant
IGNORE-ERRORS yes|no Spécifie si ipptool ignore les erreurs et continue par défaut.
INCLUDE "filename"|‹filename› Inclure un autre fichier de test. La première forme est relative au fichier courant.
INCLUDE-IF-DEFINED name "filename"|‹filename› Inclure un autre fichier de test si la variable nommée est définie
INCLUDE-IF-NOT-DEFINED name "filename"|‹filename› Inclus un autre fichier de test si la variable nommée n'est pas définie
SKIP-IF-DEFINED variable-name
SKIP-IF-NOT-DEFINED variable-name Spécifie si le reste du fichier test devrait être sauté quand la variable est ou n'est pas définie
STOP-AFTER-INCLUDE-ERROR yes|no Spécifie si les tests sont stoppés après une erreur dans un fichier inclus
TRANSFER auto|chunked|length Spécifie que les tests, par défaut, utilisent "Transfer-Encoding: chunked", ou "Content-Length:". auto utilise le premier avec les fichiers attachés et le second pour les requêtes sans fichier attaché.
VERSION 1.0|1.1|2.0|2.1|2.2 Spécifie le numéro de version IPP par défaut pour les tests.

Directives de test

ATTR tag attribute-name value(s) Ajoute un attribut à la demande de test. les valeurs sont séparées par ','
ATTR collection attribute-name { MEMBER tag member-name value(s) ... } [ ... ,{ ... } ] Ajoute une collection d'attribut à la demande de test. Les attributs membres suivent la même syntaxe que les attributs réguliers et peuvent eux-même être des collections imbriquées. Plusieurs collections peuvent être fournis, séparées par ','
COMPRESSION deflate|gzip|none Compression à utiliser dans le données suivant les attributs dans une requêtes Print-Job ou Send-Document
DELAY seconds délais avant de lancer ce test
DISPLAY attribute-name Spécifique la valeur d'un attribut à sortir dans le rapport de test
EXPECT attribute-name [ predicate(s) ]
EXPECT ?attribute-name predicate(s)
EXPECT !attribute-name Spécifie que la réponse doit|peut|ne doit pas incluse l'attribut nommé. Des prédicats peuvent être ajoutés. Les noms d'attribut peuvent spécifier des attributs membre en les séparant avec un '/' (ex: "media-col/media-size/x-dimension")
EXPECT-ALL attribute-name [ predicate(s) ]
EXPECT-ALL ?attribute-name predicate(s) Spécifie que la réponse doit/peut inclure l'attribut nommé et que toutes les occurrences de cet attriut doivent correspondre au prédicat donné
FILE filename Spécifie un fichier à inclure à la fin de la requête. Généralement utilisé en envoyant un fichier de test d'impression
GROUP tag Spécifie le tag de groupe pour les attributs sous-jacents dans la requête
IGNORE-ERRORS yes|no Spécifie si les erreurs sont ignorées ou non
NAME "literal string" Nom "human-readable" du test
OPERATION operation-code Spécifie l'opération à effectuer
PAUSE "message" Affiche le message fournis et attends que l'utilisateur appuie sur une touche pour continuer
REQUEST-ID ‹number›|random Spécifie le request-id à utiliser dans la requête.
RESOURCE path Chemin de ressource alternatif pour la requête HTTP POST. Par défaut, est pris dans l'URI fournie à ipptool
SKIP-IF-DEFINED variable-name
SKIP-IF-NOT-DEFINED variable-name Spécifie que le test courant devrait sauter quand la variable et ou non définie
SKIP-PREVIOUS-ERROR yes|no Indique si ipptool saute le test courant si le test précédent a généré une erreur
STATUS status-code [ predicate ] Spécifie un valeur de code de status attendus. Un prédicat peut être ajouté
TEST-ID "identifier" Spécifie une chaîne identifiant pour le test courant
TRANSFER auto|chunked|length Spécifie que les tests, par défaut, utilisent "Transfer-Encoding: chunked", ou "Content-Length:". auto utilise le premier avec les fichiers attachés et le second pour les requêtes sans fichier attaché.
VERSION 1.0|1.1|2.0|2.1|2.2 Spécifie le numéro de version IPP par défaut pour ce test

Prédicats attendus

COUNT number Nécessite que l'attribut EXPECT ait le nombre spécifié de valeurs
DEFINE-MATCH variable-name Définis la valiable à 1 quand la condition EXPECT correspond
DEFINE-NO-MATCH variable-name Définis la valiable à 1 quand la condition EXPECT ne correspond pas
DEFINE-VALUE variable-name Définis la variable quand la condition EXPECT correspond
IF-DEFINED variable-name Les conditions EXPECT ne s'appliquent que si la variable spécifiée est définie
IF-NOT-DEFINED variable-name Les conditions EXPECT ne s'appliquent que si la variable spécifiée n'est pas définie
IN-GROUP tag Nécessite que l'attribut EXPECT soit dans le group tag spécifié
OF-TYPE tag[,tag,...] Nécessite l'attribut EXPECT pour utiliser un des tag spécifiés
REPEAT-LIMIT number Spécifie le nombre max de répétitions si le prédicat REPEAT-MATCH ou REPEAT-NO-MATCH est spécifié. Défaut: 1000
REPEAT-MATCH
REPEAT-NO-MATCH Spécifie que le test courant devrait être répété quand la condition EXPECT correspond ou non
SAME-COUNT-AS attribute-name Nécessite que l'attribut EXPECT ait le même nombre de valeurs que l'attribut parallèle spécifié
WITH-ALL-HOSTNAMES "literal string"|"/regular expression/" Nécessite que toutes les valeurs URI contiennent un hostname correspondant
WITH-ALL-RESOURCES "literal string"|"/regular expression/" Nécessite que toutes les valeurs URI contiennent une ressource correspondante (incluant le /)
WITH-ALL-SCHEMES "literal string"|"/regular expression/" Nécessite que toutes les valeurs URI contiennent le schéma correspondant
WITH-ALL-VALUES ‹number|=number|›number|number[.....number]|false|true|"/regular expression/" Nécessite que toutes les valeurs de l'attribut EXPECT corresponde à la chaîne littérale ou la valeur booléenne
WITH-HOSTNAME "literal string"|"/regular expression/" Nécessite qu'au moins une valeur URI contienne un nom d'hôte correspondant
WITH-RESOURCE "literal string"|"/regular expression/" Nécessite qu'au moins une valeur URI contienne une ressource correspondante (incluant le /)
WITH-SCHEME "literal string"|"/regular expression/" Nécessite qu'au moins une valeur URI contienne une schéma correspondant
WITH-VALUE "literal string"|‹number|=number|›number|number[.....number]|false|true|"/regular expression/" Nécessite qu'au moins une valeur de l'attribut EXPECT corresponde aux nombres spécifiés.
WITH-VALUE-FROM attribute-name Nécessite que les valeurs de l'attribut EXPECT correspondent aux valeurs dans l'attribut spécifié (ex: "EXPECT job-sheets WITH-VALUE-FROM job-sheets-supported" nécessite que la valeur job-sheets soit listé dans job-sheets-supported)

Prédicats de status

DEFINE-MATCH variable-name Définis la variable à 1 quand STATUS correspond
DEFINE-NO-MATCH variable-name Définis la variable à 1 quand STATUS ne correspond pas
IF-DEFINED variable-name STATUS s'applique seulement si la variable spécifiée est définie
IF-NOT-DEFINED variable-name STATUS s'applique seulement si la variable spécifiée n'est pas définie
REPEAT-LIMIT number Spécifie le nombre maximum de répetition du test courant. Défaut: 1000
REPEAT-MATCH
REPEAT-NO-MATCH Spécifie que le test courant devrait être répété quand le code de status de réponse correspond ou non à la valeur spécifiée par la directive STATUS

Codes d'opération

Les codes d'opération correspondent aux nombres hexadécimal (0xHHHH) et noms de la rfc2911 et d'autres spécifications d'extension IPP. Voici une liste complète de noms supportés par ipptool:
Activate-Printer
CUPS-Accept-Jobs
CUPS-Add-Modify-Class
CUPS-Add-Modify-Printer
CUPS-Authenticate-Job
CUPS-Delete-Class
CUPS-Delete-Printer
CUPS-Get-Classes
CUPS-Get-Default
CUPS-Get-Devices
CUPS-Get-Document
CUPS-Get-PPD
CUPS-Get-PPDs
CUPS-Get-Printers
CUPS-Move-Job
CUPS-Reject-Jobs
CUPS-Set-Default
Cancel-Current-Job
Cancel-Job
Cancel-Jobs
Cancel-My-Jobs
Cancel-Subscription
Close-Job
Create-Job
Create-Job-Subscriptions
Create-Printer-Subscriptions
Deactivate-Printer
Disable-Printer
Enable-Printer
Get-Job-Attributes
Get-Jobs
Get-Notifications
Get-Printer-Attributes
Get-Printer-Support-Files
Get-Printer-Supported-Values
Get-Subscription-Attributes
Get-Subscriptions
Hold-Job
Hold-New-Jobs
Identify-Printer
Pause-Printer
Pause-Printer-After-Current-Job
Print-Job
Print-URI
Promote-Job
Purge-Jobs
Release-Held-New-Jobs
Release-Job
Renew-Subscription
Reprocess-Job
Restart-Job
Restart-Printer
Resubmit-Job
Resume-Job
Resume-Printer
Schedule-Job-After
Send-Document
Send-Hardcopy-Document
Send-Notifications
Send-URI
Set-Job-Attributes
Set-Printer-Attributes
Shutdown-Printer
Startup-Printer
Suspend-Current-Job
Validate-Document
Validate-Job

Codes de status

Les codes de status correspondent aux nombres hexadécimal (0xHHHH) et noms de la rfc2911 et d'autres spécifications d'extension IPP. Voici une liste complète de noms supportés par ipptool:
client-error-account-authorization-failed
client-error-account-closed
client-error-account-info-needed
client-error-account-limit-reached
client-error-attributes-not-settable
client-error-attributes-or-values-not-supported
client-error-bad-request
client-error-charset-not-supported
client-error-compression-error
client-error-compression-not-supported
client-error-conflicting-attributes
client-error-document-access-error
client-error-document-format-error
client-error-document-format-not-supported
client-error-document-password-error
client-error-document-permission-error
client-error-document-security-error
client-error-document-unprintable-error
client-error-forbidden
client-error-gone
client-error-ignored-all-notifications
client-error-ignored-all-subscriptions
client-error-not-authenticated
client-error-not-authorized
client-error-not-found
client-error-not-possible
client-error-print-support-file-not-found
client-error-request-entity-too-large
client-error-request-value-too-long
client-error-timeout
client-error-too-many-subscriptions
client-error-uri-scheme-not-supported
cups-error-account-authorization-failed
cups-error-account-closed
cups-error-account-info-needed
cups-error-account-limit-reached
cups-see-other
redirection-other-site
server-error-busy
server-error-device-error
server-error-internal-error
server-error-job-canceled
server-error-multiple-document-jobs-not-supported
server-error-not-accepting-jobs
server-error-operation-not-supported
server-error-printer-is-deactivated
server-error-service-unavailable
server-error-temporary-error
server-error-version-not-supported
successful-ok
successful-ok-but-cancel-subscription
successful-ok-conflicting-attributes
successful-ok-events-complete
successful-ok-ignored-notifications
successful-ok-ignored-or-substituted-attributes
successful-ok-ignored-subscriptions
successful-ok-too-many-events

Tags

Les tags correspondent aux noms de la rfc2911 et autres spécifications d'extension IPP . Tags de groupe:
document-attributes-tag
event-notification-attributes-tag
job-attributes-tag
operation-attributes-tag
printer-attributes-tag
subscription-attributes-tag
unsupported-attributes-tag

Tags de valeurs:
admin-define
boolean
charset
collection
dateTime
default
delete-attribute
enum
integer
keyword
mimeMediaType
nameWithLanguage
nameWithoutLanguage
naturalLanguage
no-value
not-settable
octetString
rangeOfInteger
resolution
textWithLanguage
textWithoutLanguage
unknown
unsupported
uri
uriScheme

Variables

   ipptool maintient une liste de variables qui peuvent être utilisées dans les chaînes litérales ou les valeurs d'attribut.

$$ Le caractère $
$ENV[name] Insert la valeur de la variable d'environnement spécifiée
$filename Insert le fichier fournis à ipptool avec l'option -f
$filetype Insert le type mime pour le fichier fournis à ipptool
$hostname Insert le nom d'hôte depuis l'URI fournis à ipptool
$job-id Insert le dernier job-id retourné dans un test
$job-uri Insert le dernier job-uri retourné dans un test
$notify-subscription-id Insert le dernier notify-subscription-ip retourné dans un test
$port Insert le port depuis l'URI fournie à ipptool
$resource Insert le chemin de la ressource depuis l'URI fournie à ipptool
$scheme Insert le schéma depuis l'URI fournie à ipptool
$uri Insert l'URI fournie à ipptool
$uriuser Insert le username depuis l'URI fournie à ipptool
$user Insert l'utilisateur courant
^
18 mars 2016

htmlpdflatexmanmd




isc-hmac-fixup

isc-hmac-fixup

Fixe les clé HMAC générées par d'anciennes versions de BIND

   Les versions de BIND9 jusqu'à BIND 9.6 avaient un bug causant les clé HMAC-SHA* qui étaient plus longues que la longueurs du hash d'être utilisées incorrectement, générant un MAC qui était incompatible avec d'autres implémentations dns.Les secrets qui ont été convertis avec isc-hmac-fixup sont raccourcis.

^
14 novembre 2016

htmlpdflatexmanmd




iscsi-iname

iscsi-iname

Outil de génération de nom d'initiateur iSCSI unique

OPTIONS

[-p=]prefix Préfixe passé au lieu de "iqn.2005-03.org.open-iscsi"
^
14 novembre 2016

htmlpdflatexmanmd




iscsi-inq

iscsi-inq

Utilitaire de requête de donnée INQUIRY depuis un LUN iSCSI

OPTIONS

-i, --initiator-name=‹IQN› Spécifie le nom de l'initiateur que iscsi-ls utilise en se loggant dans la cible. Défaut: 'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-inq'
-e, --evpd=‹INTEGER› Par défaut affiche les données standards. à 1, affiche les pages VPD étendues.
-c, --pagecode=‹INTEGER› Spécifie quelle page VPD afficher quand evpd est demandé. Défaut: 0x00 qui représente les pages VPD supportées
-d, --debug=‹INTEGER› Mode débug

Exemples

Afficher la page INQUIRY standard
iscsi-inq iscsi://192.0.2.1/iqn.ronnie.test/1
Lister les pages disponibles
iscsi-inq -e 1 iscsi://192.0.2.1/iqn.ronnie.test/1
Affiche une page spécifique
iscsi-inq -e 1 -c 0x80 iscsi://192.0.2.1/iqn.ronnie.test/1
^
14 novembre 2016

htmlpdflatexmanmd




iscsi-ls

iscsi-ls

Lister les targets iSCSI et les LUN

OPTIONS

-i, --initiator-name=‹IQN› Spécifie le nom de l'initiateur que iscsi-ls utilise en se loggant dans la cible. Défaut: 'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-ls'
-s, --show-luns Affiche en plus les LUN et leur types dans chaque cible découvertes
-d, --debug=‹INTEGER› Mode débug
^
14 novembre 2016

htmlpdflatexmanmd




iscsi-swp

iscsi-swp

Utilitaire pour définir-obtenir la protection d'écriture dans un LUN iSCSI

OPTIONS

-i, --initiator-name=‹IQN› Spécifie le nom de l'initiateur que iscsi-ls utilise en se loggant dans la cible. Défaut: 'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-ls'
-s, --swp {on|off} Par défaut, affiche seulement le paramètre courant. Permet de définir le flag.
-d, --debug=‹INTEGER› Mode débug
^
14 novembre 2016

htmlpdflatexmanmd




iscsi-test-cu

iscsi-test-cu

Suite de test iSCSI/SCSI

OPTIONS

-i, --initiator-name=‹IQN› Tous les tests utilisent au moins une connection iSCSI sur la cible et le nom de l'initiateur par défaut est 'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test'
-I, --initiator-name-2=‹IQN› Certains tests utilisent une seconde connection à la cible. Défaut: 'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test-2'
-l, --list Liste tous les tests disponibles
-t, --test=‹family›|*[.‹suite›|*[.‹test›|*]] Spécifie la liste de tests à lancer. Sans cette option, tous les tests sont exécutés.
-d, --dataloss Par défaut, les tests sont non-destructeurs. Cette option permet d'exécuter les tests qui modifient les données
-s, --allow-sanitize L'opcode SBC SANITIZE prend en temps significatif avant de se terminer et les tests avec cet opcode ne sont pas prévus pour les tests normaux
-V, --Verbose-scsi Affiche toutes les commandes SCSI qui sont envoyées au périphérique, arguments, et résultat attendus.
-x, --xml Produit un résultat de test au format xml
^
14 novembre 2016

htmlpdflatexmanmd




iscsiadm

iscsiadm

Utilitaire d'administration open-iscsi

Description

   iscsiadm permet de découvrir et se connecter à des targets iSCSI, accéder et gérer la base de donnée open-iscsi. Open-iscsi n'utilise pas le terme de nœud tel que définis dans la RFC iSCSI, où un nœud est un simple initiateur ou target iSCSI. Il utilise le terme de nœud pour référer à un portail dans une target. Pour le mode session, un sid (session id) est utilisé. Il peut être affiché avec iscsiadm -m session -P 1.

OPTIONS

-a, --ip=ipaddr (sous-mode ping). ipv4 ou ipv6
-A, --portal_type=[ipv4|ipv6] (sous-mode flashnode du mode host et seulement avec l'opération new) Spécifie le type de portail pour la nouvelle entrée de nœud flash à créer.
-b, --packetsize=packetsize (sous-mode ping) Taille de paquet ping
-c, --count=count (sous-mode ping) nombre d'itérations ping
-C, --submode=op Spécifie le sous-mode pour mode. op doit être le nom d'un sous-mode
-d, --debug=debug_level Mode debug, de 0 à 8
-H, --host=[hostno|MAC] Spécifie l'hôte SCSI à utiliser pour l'opération. Peut être un numéro d'hôte iscsi assigné à l'hôte par la couche scsi du kernel, ou l'adresse MAC d'un hôte scsi
-i, --interval=interval (sous-mode ping) interval entre les itérations ping
-I, --interface=[iface] Interface iSCSI à utiliser pour l'opération. les interfaces iSCSI sont définies dans /etc/iscsi/ifaces. pour (modes discovery, node et iface) iSCSI hardware (qla4xxx), la configuration iface doit avoir l'adresse hardware (iface.hwaddress = adresse MAC du port) et le driver/transport_name (iface.transport_name). Le nom de l'interface est le nom du fichier de configuration iface. Pour iSCSI logiciel, la configuration doit avoir soit l'adresse hardware (iface.hwaddress) ou le nom de l'interface de la couche réseau (iface.net_ifacename) et doit avoir le driver/transport_name.
-k, --killiscsid=[priority] Actuellement la priorité doit être 0. Celà va immédiatement stopper toutes les opértions iscsid et stopper iscsid. Il ne déconnecte aucune session. Équivalent à killall iscsid.
-D, --discover (mode discovery) Découvre les targets en utilisant la découverte avec le recid correspondant au type de découverte et portail spécifiés. S'il n'y a pas d'enregistrement découvert, il est créé en utilisant les paramètres de découvertes dans iscsid.conf. Doit être passé en mode discoverydb pour instruire iscsiadm d'effectuer la découverte.
-L, --loginall=[all|manual|automatic] (mode node) Login pour toutes les sessions avec le nœud ou les valeurs conn passée à toute session en cours, excepté celles marquées onboot.
-m, --mode op Spécifie le mode. (discovery, discoverydb, node, fw, host iface ou session)
-n, --name=name (mode node) spécifie un nom de champ dans un enregistrement. en sous-mode flashnode du mode host, spécifie le nom d'un paramètre du nœud flash. À utiliser avec l'opérateur update
-o, --op=op Spécifie un opérateur de base de données

        new, delete, update, show, nonpersistent Pour tous les modes excepté fw.
        apply et apllyall mode iface
        login et logout sous-mode flashnode
        delete ne devrait pas être utilisé sur une session en cours. delete supprime un recid spécifié. En mode discovery, si iscsiadm effectue un découverte il supprime les enregistrements pour les portals qui ne sont plus retournés.
        new créé un nouvel enregistrement de bas pour un objet donné. En mode node, recid est le nom target et portal (IP:port). En mode iface, recid est le nom iface. En mode discovery, recid est le type portal et discovery. En mode session, new logs dans une nouvelle session en utilisant le même nœud et informations iface que la session spécifiée
        update Met à jours le recid avec le nom à la valeur spécifiée. En mode discovery, si iscsiadm effectue une découverte, recid, name et value ne sont pas nécesaires. update opère sur les portails retournées par les targets, et met à jours les enregistrements de nœud avec les informations du fichier de configuration et de la ligne de commande.
        show défaut pour les modes node, discovery et iface. Également utiisés s'il n'y a pas de commandes passées dans le mode session et qu'un sid est passé. name et value sont ignorés
        nonpersistent Instruit iscsiadm de ne pas manipuler la base
        apply Les paramètres réseaux prennent effet sur l'iface spécifié
        applyall Les paramètres réseaux prennent effet sur tous les ifaces dont l'adresse MAC ou le numéro d'hôte correspond.
        login se log dans l'entrée de nœud flash spécifié
        logout Se déconnecte de l'entrée de nœud flash spécifié

-p, --portal=ip[:port] (mode discovery ou pour les opérations node) Utilise le portail spécifié. défaut pour port: 3260.
-P, --print=printlevel (mode node) affiche les nœud en arborescence.
-T, --targetname=targetname Utilise la target spécifiée
-r, --sid=sid | sysfsdir Utiliser le sid spécifié, ou utilise le chemin sysfs (ex: /sys/devices/platform/hostH/sessionS/targetH:B:I/H:B:I:L)
-R, --rescan (mode session) si le sid est également passé, rescan la session, sinon rescan toutes les sessions courantes.
-s, --stats Affiche des statistiques de session ou d'hôte.
-S, --show (mode node et session) En affichant les enregistrements, ne cache pas les valeurs masquée, comme le secret CHAP
-t, --type=type Doit être sendtargets (ou st), slp, isns ou fw (non supporté).
-u, --logout (mode node et session) déconnection du record spécifié
-U, --logoutall=[all,manual,automatic] déconnection de toutes les sessions avec le nœud ou les valeurs conn startup passé, ou toutes les sessions en cours, excepté celles marquée onboot.
-v, --value=value Spécifie une valeur à utiliser avec l'opérateur update
-x, --index=index index de l'entité sur laquelle opérer

Types de découverte

SendTargets protocole iSCSI natif qui permet à chaque target iSCSI d'envoyer une liste de targets disponibles à l'initiateur.
SLP Optionnellement, un target iSCSI peut utiliser SLP pour annoncer la disponibilité des targets.
iSNS iSNS enregistre les informations d'enregistrement sur les volumes de stockage dans un grand réseau.
fw De nombreux NIC et systèmes contiennent un mini initiateur iSCSI à utiliser au boot.

Codes de sortie

0 ISCSI_SUCCESS - commande réussie
1 ISCSI_ERR - Code d'erreur générique
2 ISCSI_ERR_SESS_NOT_FOUND - session non trouvée
3 ISCSI_ERR_NOMEM - impossible d'allouer des ressource pour l'opération
4 ISCSI_ERR_TRANS - Problème de connexion
5 ISCSI_ERR_LOGIN - erreur de login
6 ISCSI_ERR_IDBM - Erreur d'accès/gestion DB
7 ISCSI_ERR_INVAL - argument invalide
8 ISCSI_ERR_TRANS_TIMEOUT - timer de connexion expiré
9 ISCSI_ERR_INTERNAL - Erreur internel iscsi/kernel
10 ISCSI_ERR_LOGOUT - erreur de déconnexion
11 ISCSI_ERR_PDU_TIMEOUT - iSCSI PDU timedout
12 ISCSI_ERR_TRANS_NOT_FOUND - module de transport iSCSI non chargé dans le kernel
13 ISCSI_ERR_ACCESS - problème de permission d'accès iscsid ou de la commande iscsiadm
14 ISCSI_ERR_TRANS_CAPS - le module transport ne supporte pas l'opération
15 ISCSI_ERR_SESS_EXISTS - le session est connectée
16 ISCSI_ERR_INVALID_MGMT_REQ - requête IPC MGMT invalide
17 ISCSI_ERR_ISNS_UNAVAILABLE - service iSNS non supporté
18 ISCSI_ERR_ISCSID_COMM_ERR - une lecture/écriture iscsid a échoué
19 ISCSI_ERR_FATAL_LOGIN - erreur de connection iSCSI fatal
20 ISCSI_ERR_ISCSID_NOTCONN - Connection à iscsid impossible
21 ISCSI_ERR_NO_OBJS_FOUND - records/targets/sessions/portals non trouvé
22 ISCSI_ERR_SYSFS_LOOKUP - recherche dans sysfs impossible
23 ISCSI_ERR_HOST_NOT_FOUND - recherche d'hôte impossible
24 ISCSI_ERR_LOGIN_AUTH_FAILED - login failed, problème d'autorisation
25 ISCSI_ERR_ISNS_QUERY - requête iSNS échoué
26 ISCSI_ERR_ISNS_REG_FAILED - enregistrement/désenregistrement iSNS échoué

Exemples

Découvrir les target à une ip donnée
iscsiadm --mode discoverydb --type sendtargets --portal 192.168.1.10 --discover
login, doit utiliser un enregistrement de node trouvé par la découverte
iscsiadm --mode node --targetname iqn.2001-05.com.doe:test --portal 192.168.1.1:3260 --login
logout
iscsiadm --mode node --targetname iqn.2001-05.com.doe:test --portal 192.168.1.1:3260 --logout
lister les enregistrements de nœuds
iscsiadm --mode node
Afficher toutes les données pour un enregistrement nœud donné
iscsiadm --mode node --targetname iqn.2001-05.com.doe:test --portal 192.168.1.1:3260

Fichiers

/etc/iscsi/iscsid.conf Fichier de configuration lu par iscsid et iscsiadm au démarrage
/etc/iscsi/initiatorname.iscsi fichier contenant les initiatorname et initiatoralias iSCSI lu par iscsid et iscsiadm au démarrage
/etc/iscsi/nodes/ Base de configuration persistante Open-iSCSI
/etc/iscsi/send_targets Répertoire contenant les portails
^
14 novembre 2016

htmlpdflatexmanmd




iscsid

iscsid

Service Open-iSCSI

   iscsid implément le chemin de contrôle du protocole iSCSI, plus certaines facilités de gestion.

OPTIONS

[-c|--config=]config-file Spécifie le fichier de configuration. Défaut: /etc/iscsi/iscsid.conf
[-i|--initiatorname=]iname-file Lit le nom de l'initiateur depuis iname-file au lieu de /etc/iscsi/initiatorname.iscsi
[-f|--foreground] Ne lance pas en tâche de fond
[-d|--debug=]debug_level Affiche des informations de debuggage, de 0 à 8
[-u|--uid=]uid UID du processus
[-g|--gid=]gid GID du processus
[-n|--no-pid-file] Ne pas écrire de PID dans un fichier
[-p|--pid=]pid-file Écris le PID dans le fichier spécifié. Défaut: /run/iscsid.pid

Fichiers

/etc/iscsi/iscsid.conf Fichier de configuration lu par iscsid et iscsiadm au démarrage
/etc/iscsi/initiatorname.iscsi fichier contenant les initiatorname et initiatoralias iSCSI lu par iscsid et iscsiadm au démarrage
/etc/iscsi/nodes/ Base de configuration persistante Open-iSCSI
^
14 novembre 2016

htmlpdflatexmanmd




iscsid.conf

iscsid.conf

fichier de configuration pour open-iscsi

Options iscsid

iscsid.startup Spécifie la commande de démarrage de iscsid si vous souhaitez que iscsid démarre quand un outil iscsid doit y accéder, au lieu des scripts d'initialisation.
iscsid.safe_logout (bool) Vérifie les montages actifs dans le périphériques accessibles via une session et refuse de se déconnecter s'il y en a. Défaut: no.

Options NIC/HBA

open-iscsi peut créer une session et la lier à un NIC/HBA. pour la configuration, voir un exemple de fichier de configuration iface

Options de démarrage

node.startup = [automatic|manual] Définis le type de démarrage de session au lancement de iscsid. Défaut: manual
node.leading_login (bool) pour les nœuds 'automatic', à yes tente de se connecter sur chaque iface disponible jusqu'à un succès, puis stop. À no, tente de se connection à toutes les iface simultanément.

Options CHAP

node.session.auth.authmethod = CHAP Active l'authentification CHAP. Défaut: None
node.session.auth.username = username username pour l'authentification CHAP
node.session.auth.password = password Mot de passe pour l'authentification CHAP
discovery.sendtargets.auth.authmethod = CHAP Active l'authentification CHAP pour une session discovery sur un target. Défaut: None
discovery.sendtargets.auth.username = username username CHAP de session discovery pour l'authentification de l'initiateur par les targets.
discovery.sendtargets.auth.password = password mot de passe CHAP de session discovery
discovery.sendtargets.auth.username_in = username_in username CHAP de session discovery pour l'authentification des targets par l'initiateur
discovery.sendtargets.auth.password_in = password_in mot de passe CHAP de session discovery

Options timeouts

node.session.timeo.replacement_timeout Délai en secondes de rétablissement de session après une erreur SCSI. À 0 l'IO échoue immédiatement, ‹ 0, l'IO reste en file d'attente indéfiniment. Défaut: 120
node.conn[0].timeo.login_timeout Délai pour accomplir le login, en seconde. Défaut: 15
node.conn[0].timeo.logout_timeout Délai pour la déconnection complète, en secondes. Défaut: 15
node.conn[0].timeo.noop_out_interval Délai avant d'envoyer un ping une fois connecté, défaut: 5
node.conn[0].timeo.noop_out_timeout Délai pour une réponse Nop-out avant d'échouer. Avec dm-multipath, l'IO échoue sur la couche multipath. Défaut: 5
node.session.err_timeo.abort_timeout Délai d'attente pour une réponse avant d'échouer l'opération et tenter un reset lun. défaut: 15
node.session.err_timeo.lu_reset_timeout Délai d'attente pour une réponse d'unité logique avant l'échouer l'opération et tenter de rétablir la session. Défaut: 30
node.session.err_timeo.tgt_reset_timeout Délait d'attente pour une réponse d'un target avant d'échouer l'opération et tenter de rétablir une session. Défaut: 30

Options retry

node.session.initial_login_retry_max Pour spécifier le nombre de fois que iscsid devrait retenter un login si les tentatives de login échouent à cause de l'expiration node.conn[0].timeo.login_timeout, modifier cette option. Ce compteur, avec node.conn[0].timeo.login_timeout, déterminent le login initial. node.session.initial_login_retry_max est multiplié par node.conn[0].timeo.login_timeout pour en déterminer la quantité. défaut: 8

Options de session et de file de périphériques

node.session.cmds_max Contrôle le nombre de commande mis en file d'attente pour la session. Défaut: 128
node.session.queue_depth Contrôle la profondeur de la file d'attente du périphérique. Défaut: 32

Options de performances système

node.session.xmit_thread_priority Pour iscsi_tcp et ib_iser, chaque session a un thread utilisé pour transmettre ou mettre en file les données vers le hardware. Cette option définis la priorité de thread. Défaut: -20.

Options iSCSI

node.session.iscsi.InitialR2T Active le contrôle de flux R2T (ex: l'initiateur doit attendre une comande R2T avant d'envoyer des données)
node.session.iscsi.InitialR2T Désactive le contrôle de flux R2T (ex: l'initiateur a un R2T initial implicite "FirstBurstLength" à l'offset 0). Défaut: No
node.session.iscsi.ImmediateData Àctive les données immédiates (ex: l'initiateur envoie des données non-solicitée avec les paquets de commande iSCSI). Défaut: Yes
node.session.iscsi.FirstBurstLength Nombre d'octets entre 512 et 2^24-1 des données non-solicitée que l'initiateur peut envoyer dans un PDU iSCSI à un target. Défaut: 262144
node.session.iscsi.MaxBurstLength Payload SCSI max que l'initiateur négocie avec le target, entre 512 et 2^24-1 octets. Défaut: 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength Nombre d'octets entre 512 et 2^24-1 que l'initiateur peut reçevoir dans un PDU iSCSI d'un target. Défaut: 262144
node.conn[0].iscsi.MaxXmitDataSegmentLength Nombre d'octets entre 512 et 2^24-1 que l'initiateur envoie dans un PDU iSCSI à un target. Défaut: 0 ( utilise MaxRecvDataSegmentLength)
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength Spécifie le nombre max d'octets de données que l'initiateur peut reçevoir dans un PDU iSCSI d'un target durant une session de découverte, entre 512 et 2^24-1. Défaut: 32768
node.conn[0].iscsi.HeaderDigest = CRC32C,None Permet aux targets de contrôler la vérification de hash, par ordre de préférence. None en premier indique que l'initiateur préfère ne pas vérifier le hash. Si une seule valeur est spécifié, force ce mode. Défaut: None
node.conn[0].iscsi.DataDigest = CRC32C,None Permet aux targets de contrôler la vérification de hash, par ordre de préférence. Défaut: None

Options de contournement

node.session.iscsi.FastAbort (Bool) Certains target comme IET préfèrent, une fois que l'initiateur a envoyé une fonction de gestion de tâche comme ABORT TASK ou LOGICAL UNIT RESET, ne plus répondre aux PDU comme R2T. Défaut: Yes (permet ce comportement)
^
14 novembre 2016

htmlpdflatexmanmd




iscsistart

iscsistart

Outil de boot iSCSI

   iscsistart démarre une session avec les paramètres qui lui sont passés, ou en utilisant les informations de boot iBFT ou Open Firmware (OF). Ce programme ne devrait pas être utilisé pour gérer les sessions. Il est principalement utilisé pour démarrer les sessions utilisées pour le boot root iSCSI

OPTIONS

[-i|--initiatorname=]name Définis initiatorName
[-t|--targetname=]name Définis TargetName
[-g|--tgpt=]N Définis le target portal group tag
[-a|--address=]A.B.C.D Définis l'adresse IPv4
[-p|--port=]N Définis le port
[-u|--username=]N définis le username
[-w|--password=]N Mot de passe
[-U|-username_in=]N Définis le username entrant
[-W|--password_in=]N Mot de passe entrant
[-d|--debug=]debug_level Mode debug
[-b|--fwparam_connect] Créé une session sur le target en utilisant les infos iBFT ou OF
[-N|--fwparam_network] Définis le réseau tels que spécifié par iBFT ou OF
[-P|--param=]NAME=VALUE Définis le paramètre spécifié. Peut être spécifié plusieurs fois
^
14 novembre 2016

htmlpdflatexmanmd




iscsi_discovery

iscsi_discovery

Découvrir des targets iSCSI

   Effectue des découvertes sendtargets sur l'IP spécifié. Si un record est généré, tente de se logger au portail en utilisant le transport préféré. (défaut: TCP) Si le login réussi, marque le portail pour le login automatique et se déconnecte.

OPTIONS

[-p=]port-number Définis le port. Défaut: 3260
[-d] Mode debug
[-t=]transport-type Définis le type de transport. Défaut: TCP
[-f] Force un transport spécifique
[-m] Démarrage manuel, ne définis pas de démarrage automatique
[-l] Se log sur les nœuds découverts. Défaut: false
^
14 novembre 2016

htmlpdflatexmanmd




isnsadm

isnsadm

Utilitaire client iSNS

   isnsadm est un utilitaire permettant d'interragir avec un serveur iSNS.

OPTIONS

-c filename, --config filename Spécifie le fichier de configuration. Défaut: /etc/isns/isnsadm.conf
-d facility, --debug facility Active de débug. facility peut être:

        socket Transmission/réception réseau
        auth Informations liées à l'authentification et la sécurité
        message couche du protocole iSNS
        state État de la base de données
        scn Message SCN (state change notification)
        esi message ESI (entity status inquiry)
        all Tout

--local Utilise un socket Unix pour dialoguer avec le serveur iSNS. Uniquement disponible par root
-s servename, --server servername Serveur à utiliser.
--control Identité d'un nœud de contrôle. Les nœud de contrôle sont spéciaux et ont plus de droits d'accès et modification dans la base que les nœuds de stockage normaux.
--key attr=value mode enregistrement uniquement, et permet de spécifier une clé.
--keyfile=filename En créant une stratégie pour un nouveau client iSNS, isnsadm est capable de générer une clé DSA pour le client. La partie publique est stockée dans l'objet stratégie, et la partie privée est stockée dans le fichier spécifié par l'option keyfile.

Attributs supportés

   La plupart des modes prennent une liste d'attributs comme argument sur la ligne de commande. Le nommage et la syntaxe de ces attributs sont les même pour tous les modes. Cependant, certains mode ne supporte qu'un jeu limité d'attribut.
   Les attributs sont généralement donnés en name=value. Les attributs vides sont supportés.

entity-id (alias eid)(tag 1) Network Entity
entity-prot (tag 2) Network Entity
entity-index (tag 7)
iscsi-name (tag 32) iSCSI Storage Node
iscsi-node-type (tag 33)
iscsi-alias (tag 34)
iscsi-idx (tag 36)
iscsi-authmethod (tag 42)
portal-addr (tag 16)
portal-port (tag 17)
portal-name (tag 18)
portal-esi-port (tag 20)
portal-esi-interval (tag 21)
portal-idx (tag 22)
portal-scn-port (tag 23)
portal-group-index (tag 52) Portal Group
pg-name (tag 48)
pg-addr (tag 49)
pg-port (tag 50)
pg-tag (alias pgt)(tag 51)
pg-idx (tag 52)
dd-id (tag 2065) Discovery Domain
dd-name (tag 2066)
dd-member-iscsi-idx (tag 2067)
dd-member-name (tag 2068)
dd-member-fc-name (tag 2069)
dd-member-portal-idx (tag 2070)
dd-member-addr (tag 2071)
dd-member-port (tag 2072)
dd-features (tag 2078)
policy-name (alias spi) Policy Object
policy-key -
policy-entity -
policy-node-type -
policy-object-type -
policy-functions -

Attributs Portail

   Les informations de portail sont transportés par 2 attributs séparés dans iSNS; un attribut address maintenant l'adresseIP, et l'attribut port maintenant le numéro de port et le protocole utilisé. isnsadm supporte une notation représentant un portail comme un pseudo-attribut. Ces 2 syntaxes sont équivalentes:

  

Attributs de champ de bits

   Les attributs iSNS sont des mots représentant un champ de bit. isnsadm affiche et parcour ces attributs au format human-readable au lieu d'utiliser la valeur numérique. En spécifiant un attribut bitfield, il est possible de combiner les caractères '+' ou ',': node-type=control+initiator

Mode enregistrement

   Le mode enregistrement est séléctionné en utilisant l'option --register, suivi par une liste d'un ou plusieurs objets à enregistrer avec le serveur iSNS. Par défaut, cela créé une entité réseau pour le client s'il n'en existe pas, et place les nouveau objets dedans. Généralement, on enregistre tous les objets pour une entité réseaux en une seule opération. Chaque objet est spécifié comme un type, optionnellement suivis par une liste d'attributs: target=iqn.2005-01.org.open-iscsi.foo:disk1,alias=disk1. Les types d'objets suivants sont supportés:

        entity=name Indique au serveur de grouper tous les objets dans l'objet conteneur Network Entity. Normalement, le serveur iSNS assigne automatiquement un nom d'entité qui est en phase avec ses stratégies, et il n'y a pas besoin de le spécifier explicitement.
        initiator[=name] Enregistre ne nœud de stockage iSCSI de type initiator.
        target[=name] Enregistre un nœud de stockage de type target.
        control[=name] Enregistre un nœud de stockage de type control.
        portal=[address:port/proto] Enregistre un portail en utilisant l'adresse donnée.
        pg Ergesitre un groupe de portail joignant le portail et nœud précédant. Les groupes de portail peuvent être utilisés pour décrire les portails préférés pour un nœud donné.

   Il y a 2 options de ligne de commande additionnels utilisés exclusivement avec le mode enregistrement. --replace recréé une nouvelle entité réseau, le serveur supprime l'ancien et tous les nœud et portails qu'il contient. --key permet de remplace simplement une partie de l'entité réseaux.

par exemple, supposons une entité contenant le portail 10.1.1.1:860, et l'adresse du client changé en 10.2.7.7:
isnsadm --replace --key portal=10.1.1.1:860 portal=10.2.7.7:860

   L'option --key ne reconnaît qu'un sous-jeu d'attributs:

        Entity eid=identifier
        Portail portail=address:port
        iSCSI Node iscsi-name=name

Mode requête

   Le mode Query consiste d'une liste de paires attr=value. Tous les attributs doivent appartenir au même type d'objet. Il est également possible de spécifier un nom d'attribut sans valeur qui match tout objet possédant un tel attribut sans regarder sa valeur.

Mode liste

   Affiche tous les objets d'un type donné, optionnellement restreint aux valeurs d'attribut correspondant. Les argument sont des noms de type (entities, nodes, portails, dds, ddsets, portail-groups et policies"

Mode dé-enregistrement

   deregistration supporte le même jeu d'attributs que le mode query.

Discovery Domain Registration

   Ce mode permet d'enregistrer un domaine de découverte ou d'ajouter de nouveaux membres. Seule des attributs de domaine de découvert sont reconnus.

Discovery Domain Deregistration

   Permet de dé-enregistrer un domaine de découverte. Supporte le même jeu d'attributs que le mode query.

Enrôlement client

   Ce mode ne fonctionne que quand le serveur reconnaît le client comme ayant des capacités de nœud contrôle, qui est possible de 2 manières, avec --local en root sur l'hôte isnsd, ou --control. Pour enrôler un client, utiliser l'option --enroll, suivis par le nom source du client à enrôler. La chaîne sera utilisé comme nom de stratégie de sécurité que le client utilise pour s'identifier lui-même. Les attributs supportés sont:

name (alias spi) Nom de stratégie
key Clé publique du client
entity Identifiant d'entité assignée
node-type Types de nœud permis
node-name Noms de nœud permis
functions Bitmap des fonctions permises
object-type Masque d'accès aux objets

   Note: pour générer une clé DSA, un jeu de paramètres DSA doit être installé. Par défaut isnsadm s'attend à le trouver dans /etc/isns/sda.params. Ces paramètres sont créé par isnsd --init une fois sur le serveur. Alternativement, la commande suivante peut être utilisée: openssl dsaparam 1024 -out /etc/isns/dsa.params

Exemples

Initialiser les paramètres et clé DSA du serveur
isnsd --init
Créer un objet policy pour un nœud nommé isns.control, en lui octroyant les privilèges control
isnsadm --local --keyfile=control.key --enroll isns.control node-type=ALL functions=ALL object-type=ALL
Créer un objet nœud de stockage pour la machine de gestion
isnsadm --local --register control
dans cette machine, enrôler les hôtes supplémentaires
isnsadm --control --keyfile=somehost.key --enroll iqn.2005-01.org.open-iscsi.somehost node-type=target+initiator
Pour créer un domaine de découverte, et y ajouter de nœuds
isnsadm --control --dd-register dd-name=mydomain member-name=iqn.org.bozo.client iqn.org.bozo.jbod ...
Ajouter des membres à un DD existant
isnsadm --control --dd-register dd-id=42 member-name=iqn.com.foo member-name=iqn.com.bar
l'ID DD peut être obtenu avec
isnsadm --control --query dd-name=mydomain
En mode management, enregistrer un nœud et portail dans un hôte nommé client.bozo.org
isnsadm --control --register entity=client.bozo.org initiator=iqn.org.bozo.client portal=191.168.7.1:860
^
14 novembre 2016

htmlpdflatexmanmd




isnsadm.conf

isnsadm.conf, isnsd.conf, isnsdd.conf

Fichiers de configuration iSNS

   Tous les utilitaires Open-iSNS lisent leur configuration dans un fichier dans /etc/isns. Il y a un fichier par application, isnsd, isnsadm, et isnsdd. Des valeurs de délai acceptent une unité: d (jour), h (heure), m (minute), ou s (seconde).

Options génériques

HostName Par défaut, les applications Open-iSNS récupèrent le nom d'hôte de la machine avec gethostname(3), et utilisent une recherche DNS pour retrouver le nom canonique. Cette option remplace ce mode
SourceName Obligatoire pour toutes les applications Open-iSNS. Devrait être le nom qui identifie le client de manière unique. Il y a 2 lectures de la rfc4171, une exige qun nom iSCSI tel que 'iqn.2001-04.com.example.host', et une autre suggère un format plus simple, tel que fqdn du client.
IQNPrefix Spécifie le préfixe de nom qualifié iSCSI; doit être sous la forme iqn.YYYY-MM, YYYY étant l'année et MM le mois.
ServerAddress (client) Spécifie le nom d'hôte ou l'adresse du serveur iSNS à contacter.
SLPRegister (serveur) À 1, le service s'enregistre lui-même avec le service SLP. Cela permet aux clients de contacter le serveur sans avoir à configurer d'adresse statiquement.
PIDFile (serveur) Spécifie le nom du fichier pid. Défaut: /var/run/isnsd.pid

Options liée à la base de données

Database Spécifie comment la base est stockée. Vide, la base est conservée en mémoire, sinon, c'est le répertoire où isnsd conserve sa base.
DefaultDiscoveryDomain iSNS définis la visibilité des autres nœuds en utilisant les Discovery Domains. Un nœud de stockage A ne verra que le nœud de stockage B, s'ils sont membres du même domaine de découverte. À 1, indique à isnsd de créer un domaine de découverte virtuel, qui maintient tous les nœuds qui ne font pas partie d'un domaine de découverte configuré administrativement.
RegistrationPeriod Le serveur iSNS peut purger les entités enregistrées après une certaine période d'inactivité. Les clients qui s'enregistrent sont supposés rafraîchir leur enregistrement dans cette période.
ESIRetries Open-iSNS est capable de monitorer l'accessibilité des nœuds de stockage et leur portails en utilisant une fonctionnalité de protocole appelé ESI (Entity status inquiry). Les clients demandent à superviser ESI en enregistrant un port ESI avec chaque portail. Le serveur envoie des messages ESI à ces portails à interval régulier. Si le portail échoue à répondre plusieurs fois, il est considéré mort, et sera supprimé de la base. ESIRetries spécifie le nombre max de tentative. Défaut: 3
ESIMinInterval interval ESI minimum. Défaut: 60 secondes
ESIMaxInterval Interval ESI maximum. Défaut: 10 minutes
SCNRetries Les clients iSNS peuvent enregistrer leur message SCN (State Change Notification) reçus pour connaître les changements dans la base iSNS. Spécifie le nombre de tentatives de transmission d'une message SCN par le serveur avant abandon. Défaut: 3
SCNCallout Chemin du programme helper que isnsdd invoque quand il traite un SCN d'un serveur. Ce programme est invoqué avec un argument indiquant le type d'événement (add, update, ou remove), suivi par une liste d'attributs name=value, en utilisant les noms et conventions décris dans isnsadm.

Options liées à la sécurité

   Le standard iSNS définis une méthode d'authentification basée sur l'algorithme DSA. Les participants dans l'échange authentifient les messages en ajoutant un bloc d'authentification contenant un horodatage, une chaîne identifiant la clé utilisée, et une signature numérique du message. La même méthode est également utilisée par SLP.

   La chaîne contenue dans la bloc d'authentification est référée au SPI (Security Policy Index). Cette chaîne peut être utilisée par le serveur pour rechercher la clé publique du client; donc la chaîne peut être utilisée comme nom du fichier de clé publique dans un répertoire, ou pour récupérer un certificat dans LDAP.

   Pour les applications clientes Open-iSNS, il y a seulement 2 clés: la clé privée du client, utilisée pour signer les message qu'il envoie au serveur, et la clé publique du serveur, utilisée pour vérifier la signature des messages du serveur.

   Le serveur iSNS doit, en plus de sa clé privée, accéder à toutes les clés publiques des clients qui vont communiquer avec lui.

Security Active l'authentification DSA. à 1, le client signe tous les message, et s'attend à des messages serveur signés.
AuthName Chaîne utilisée come SPI dans tous les messages sortants qui ont un bloc auth. Défaut: le nom d'hôte (voir l'option HostName)
AuthKeyFile Chemin de la clé DSA encodé PEM. Défaut: /etc/isns/auth_key
ServerKeyFile (client), fichier contenant la clé publique DSA encodé PEM du serveur. Défaut: /etc/isns/server_key.pub
KeyStore (serveur) spécifie l'emplacement des clés.
Auth.ReplayWindow Pour compenser le décalage d'horloge entre 2 hôtes, Open-iSNS applique un léger flou en comparant les horodatages contenus dans le message et l'horloge système. Défaut: 5m
Auth.TimestampJitter En vérifiant les messages entrant, Open-iSNS vérifie que les horodatages envoyés par le pair sont augmenté monotoniquement. Pour compenser le réordonnancement des messages par le réseaux, un jitter est accepté. Si un horodatage d'un message entrant n'est pas avant cette durée en seconde, le message est accepté. Défaut: 1s

Stockage de clé et stratégie

   L'implémentation actuelle supporte 2 types de stockage de clé. Le premier utilise un simple répertoire pour stocker les clés publiques, chaque clé a un fichier PEM et nommé par le SPI du client. Ce type n'est pas recommandé puisqu'il ne stock aucune information de stratégie.

   L'approche recommandé est d'utiliser une base de donnée. Celà utilise des objets de stratégie spécifique aux vendeurs pour gérer les chaîne SPI, clé publique, noms d'entité, nom de source et d'autres bits de statégie. La base de données est configurée en définissant l'option KeyStore à la valeur DB:. Les objets de stratégie Open-iSNS ont les attributs suivants, en plus du SPI:

Source Nom de nœud source que le client doit utiliser. Défaut: la chaîne SPI
Functions bitmap détaillant quelles fonctions le client peut invoquer. Les noms de bit correspondent aux noms cours utilisé dans la rfc4711, tel que DevAttrReg, DevAttrQry, etc. Défaut: autorise l'enregistrement, requête et désenregistrement, et SCNRegister
Entity name C'est le nom de l'entité assigné au client. Si définit, un enregistrement par le client n'est pas autorisé avec un autre nom. Si le client s'enregistre sans identifiant d'entité, le serveur le nom donné par la stratégie. Défaut: pas de restriction
Object access Champ de bits de permission d'accès pour chaque type d'objet (lecture, écriture).
Node types Champ de bits décrivant quels types de nœud de stockage un client peut enregistrer. (target, initiator ou control). Défaut: initiator uniquement.

Options liées au réseau

Network.MaxSockets Nombre de connexion entrantes acceptées. Défaut: 1024.
Network.ConnectTimeout timeout d'attente d'établissement de connexion TCP. Défaut: 60s
Network.ReconnectTimeout Si une connextion échoue, délai d'attente avant de retenter. Défaut: 10s
Network.CallTimeout Délai d'attente de timeout d'un appel au serveur iSNS. Défaut: 60s.
^
14 novembre 2016

htmlpdflatexmanmd




isnsd

isnsd

Service iSNS

   isnsd implémente le protocole iSNS (Internet Storage Name Service) tel que définis dans la rfc4171. iSNS est un protocole de découverte pour iSCSI et iFCP

OPTIONS

-c filename, --config filename Fichier de configuration à utiliser. Défaut: /etc/isns/isnsd.conf
-F, --foreground Ne lance pas en tâche de fond
-4 Crée un socket IPv4 uniquement
-6 Créé un socket IPv6 iniquement. Mode par défaut
-d facility, --debug facility Active de débug. facility peut être:

        socket Transmission/réception réseau
        auth Informations liées à l'authentification et la sécurité
        message couche du protocole iSNS
        state État de la base de données
        scn Message SCN (state change notification)
        esi message ESI (entity status inquiry)
        all Tout

--dump-db Fonction helper qui lit la base et l'affiche sous forme compréhensive.
--init Créé une clé d'authentification serveur, et les paramètres DSA requis.
^
14 novembre 2016

htmlpdflatexmanmd




isnsdd

isnsdd

Service de découverte iSNS

   isnsdd est un service coté client pour iSNS. Il enregistre des nœuds de stockage et des portails avec le service iSNS, et rafraîchis ces enregistrements. Le service s'enregistre lui-même également pour recevoir les notifications SCN, et les traite. Il peut être configuré pour invoquer une application externe pour chaque notification reçue. Le nom du programme peut être appelé avec l'option SCNCallout.

OPTIONS

-c filename, --config filename Spécifie le fichier de configuration. Défaut: /etc/isns/isnsdd.conf
-F, --foreground Ne lance pas en tâche de fond
--role role Indique avec quelle capacité le service doit s'enregistrer. (initiator ou control). Défaut: initiator.
-d facility, --debug facility Active de débug. facility peut être:

        socket Transmission/réception réseau
        auth Informations liées à l'authentification et la sécurité
        message couche du protocole iSNS
        state État de la base de données
        scn Message SCN (state change notification)
        esi message ESI (entity status inquiry)
        all Tout
^
14 novembre 2016

htmlpdflatexmanmd




istgt

istgt

Target iSCSI

   istgt est un target iSCSI conçus pour les nœuds de cluster multipath.

OPTIONS

-c config fichier de configuration à utiliser.
-p pidfile Fichier PID à écrire
-l facility Facilité syslog à utiliser
-m mode Mode opérationnel 0 = traditionnel (==20100707), 1 = normal (défaut), 2 = expérimental.
-t flag Affiche des informations de suivi sur stderr (all, net, iscsi, scsi, lu, none)
-q mode silencieux
-D Ne met pas en tâche de fond

Fichiers

/etc/istgt/istgt.conf Fichier de configuration
/etc/istgt/auth.conf fichier d'information d'authentification
/var/run/istgt.pid Fichier PID
^
25 novembre 2016

htmlpdflatexmanmd




istgt.conf

istgt.conf

Fichier de configuration pour istgt

[Global]

Comment "Section Globale"
NodeBase Nom du nœud (ex: "iqn.2007‐09.jp.ne.peach.istgt")
PidFile Fichier pid. Défaut: /var/run/istgt.pid
AuthFile Fichier pour l'authentification. Défaut: /etc/istgt/auth.conf
MediaDirectory Pour les média amovibles (DVD/tape). Défaut: /var/istgt
LogFacility Facilité syslog (défaut: local7)
Timeout Timeout d'E/S socket. Défaut: 30
NopInInterval Interval d'envoie de NOPIN. Défaut: 20
DiscoveryAuthMethod Auto|CHAP Information d'authentification pour la session découverte
DiscoveryAuthGroup AuthGroup9999 idem
MaxSessions 16 Sessions maximum réservés
MaxConnections 4 Connexions maximum réservés
MaxR2T 32 Nombre maximum d'envoie R2T dans chaque connexion. 0 désactive, 1-256.
MaxOutstandingR2T
DefaultTime2Wait
DefaultTime2Retain
FirstBurstLength
MaxBurstLength
MaxRecvDataSegmentLength
InitialR2T Yes|No
ImmediateData Yes
DataPDUInOrder Yes
DataSequenceInOrder Yes
ErrorRecoveryLevel 0

[UnitControl]

Comment "Commentaire pour ce contrôleur"
AuthMethod Auto|CHAP ‹Mutual›
AuthGroup AuthGroup10000
Portal UC1 ‹IP›:3261
Netmask ‹IP›

[PortalGroup1]

Comment "Commentaire"
Portal ‹label› ‹IP›:‹port›

[InitiatorGroup1]

Comment "Initiator Group1"
InitiatorName "[!]‹iqn...›"|ALL Nom de l'initiateur. ! refuse le login/découverte
Netmask ‹ip/mask›

[LogicalUnit1]

Comment "Disque 1"
TargetName disk1 Nom du target
TargetAlias "Data Disk1" Alias pour ce target
Mapping PortalGroup1 InitiatorGroup1 Utilise les initiators via les portails
AuthMethod Auto
AuthGroup AuthGroup1
UseDigest Header Data|Auto
UnitType Disk UnitInquiry ‹vendor› ‹Product› ‹Revision› ‹Serial›
QueueDepth 0-255 0=désactivé, 1-255 activé avec la profondeur spécifiée. Défaut: 32
MaxOutstandingR2T 16
DefaultTime2Wait 2
DefaultTime2Retain 60
FirstBurstLength 262144
MaxBurstLength 1048576
MaxRecvDataSegmentLength 262144
InitialR2T Yes
ImmediateData Yes
DataPDUInOrder Yes
DataSequenceInOrder Yes
ErrorRecoveryLevel 0 Remplacer les paramètres globaux
LUN0 Storage ‹vol-path› ‹size› Volume logique pour cet unité dans LUN0
LUN0 Option RPM 7200 Spécifier la vitesse de rotation du disque. 0=non reporté, 1=SSD, ؏= vitesse de rotation.
LUN0 Option FormFactor 2 format du disque: 0=non indiqué, 1=5,25, 2=3.5, 3=2.5, 4=1.8, 5=moins de 1,8 pouces
LUN0 Option ReadCache Disable Pour une utilisation future
LUN0 Option WriteCache Disable Pour une utilisation future
^
14 novembre 2016

htmlpdflatexmanmd




istgtcontrol

istgtcontrol

Utilitaire de commande de target iSCSI

   istgtcontrol est un utilitaire de contrôle pour istgt. Il peut être utilisé pour requêter et changer le status d'une instance istgt locale ou distante. Par défaut il se connection et d'authentifite au portail de target iSCSI dans istgtcontrol.conf.

Commandes

noop Ne fait rien, test simplement la réactivité du portail et l'authentification CHAP.
version Affiche la version de istgt auquel istgtcontrol est connecté
list Lister tout, ou les targets spécifiées, qui sont partagés par le portail
load charge un nouveau média sur l'unité spécifié. Émet la même commande que si le lecteur avait été fermé dans le périphérique scsi
unload Débranche un média de l'unité spécifiée
change file Change le média chargé par l'unité spécifiée
reset Réinitialise le LUN spécifié du portail
info Affiche toutes les connexions du portail

OPTIONS

-c config Fichier de configuration à utiliser. Défaut: /etc/istgt/istgtcontrol.conf
-h host Remplace le portail de target par le nom d'hôte/IP spécifié. Défaut: localhost si rien n'est spécifié dans le fichier de configuration
-p port Remplace le port. Défaut: 3261 si rien n'est spécifié dans le fichier de configuration
-t target Spécifie le IQN target affecté par la commande
-l lun Spécifie le LUN target affecté par la commande. Défaut: 0
-f flags flags passé au portail en chargeant un nouveau média. Défaut: 'ro' (ro, rw, extend, dynamic)
-s size Spécifie la taille du media à charger.
-q mode silencieux
-v mode verbeux
-A method Définis la méthode d'authentification préférée pour la connextion au portail. (CHAP/Mutual ou CHAP/Auto)
-U user Username pour s'authentifier au portail
-S secret Mot de passe pour s'authentifier au portail
-M muser Username d'authentification mutuelle
-R msecret Password d'authentification mutuelle
^
31 mars 2016

htmlpdflatexmanmd




iwatch

iwatch

Monitoring de système de fichier en temps réel utilisant inotify

   iWatch est un outil Perl pour inotify pour superviser les changements dans des répertoires et fichiers spécifiques, en envoyant des alarmes à l'administrateur système en temps réel. Il peut:

- Envoyer des notifications via des email sur les changements
- Exécuter les actions programmables immédiatement
- Agir comme un HIDS (Host-based Intrusion Detection System) ou un vérificateur d'intégrité

   iWatch peut être lancé comme service pour comme simple commande. Le mode service utilise un fichier de configuration xml. Le mode ligne de commande n'utilise pas de fichier de configuration.

   Dans le fichier de configuration, chaque cible peut avoir son propre email de contact.

Options pour le mode service

-d Mode service
-f Spécifie le fichier de configuration. Défaut: /etc/iwatch/iwatch.xml
-p Fichier pid à utiliser. Défaut: /var/run/iwatch.pid
-v mode verbeux

Options pour le mode ligne de commande

-c Spécifie la commande à exécuter
-C Spécifier l'encodage. Défaut: utf-8
Spécifie une liste d'événements à monitorer
-m Adresse email de contact
-r Recherche récursivement dans un répertoire
-s on|off Active/désactive les rapports à syslog. Défaut: off
-t Spécifie un filtre (regex) à comparer avec le nom de fichier ou du répertoire.
-v mode verbeux
-x Spécifie un fichier ou répertoire exclus
-X Similaire mais en utilisant une expression régulière

Chaînes pour la commande

   En utilisant l'option -c, ces chaînes sont disponible:

%c Event cookie number
%e Nom de l'événement
%f Chemin complet du fichier
%F L'ancien nom du fichier (moved_to)
%p Nom du programme (iWatch)
%v Numéro de version

Événements

   Les événements suivant sont possibles pour l'options -e:

access Le fichier est accédé
attrib Les attributs sont changés
close Le fichier est fermé
close_nowrite fichier fermé après avoir été ouvert en mode lecture-seule
close_write fichier fermé après avoir été ouvert en mode lecture écriture
create Fichier créé dans le répertoire
delete Fichier supprimé dans le répertoire
delete_self Le fichier supervisé a été supprimé
ignored Le fichier a été ignoré
isdir en événement s'est produit avec le repertoire
modify Le fichier a été modifié
move un fichier/répertoire dans le répertoire recherché a été déplacé
moved_from Un fichier a été déplacé depuis
moved_to Un fichier a été déplacé vers
oneshot Seulement avoyé une fois
open Le fichier a été ouvert
q_overflow La file d'événement déborde
unmount Le système de fichier sur lequel le fichier existe a été démonté
default = close_write, create, delete, move, delete_self et move_self
all_events Tous les événements

Exemples

Monitor les changements dans le /tmp avec les événements pas défaut:
iwatch /tmp
Monitor seulement les événements access et create dans /etc, récursivement, à l'exception de /etc/mail, et envoie un mail à root@example.com
iwatch -r -e access,create -m root@example.com -x /etc/mail /etc
Monitor /bin récursivement, et exécute les commandes w et ps -ef
iwatch -r -c (w;ps -ef)|mail -s '%f was changed' root@localhost /bin
Monitor ~/projects, excluant les répertoires .svn.
iwatch -r -X '.svn' ~/projects

Exemple de fichier de configuration
‹?xml version="1.0" ?›
    ‹!DOCTYPE config SYSTEM "/etc/iwatch/iwatch.dtd" ›
    
‹config›
    ‹guard email="root@example.com" name="iWatch"/›
    ‹watchlist›
    ‹title›WEB server integrity monitoring‹/title›
    ‹contactpoint email="someone@example.com" name="Administrator"/›
        ‹path type="recursive" syslog="on" alert="off" exec="echo %p: %e %f | /usr/bin/sendxmpp -t foo@jabber-br.org"›/var/www‹/path›
        ‹path type="exception"›/var/www/counter‹/path›
    ‹/watchlist›
‹/config›

   Les 2 premières lignes définissent la version XML et le fichier qui définis le motif utilisé par iWatch (défaut: /etc/iwatch/iwatch.dtd).

   La déclaration ‹config› est utilisé pour marquer le port de départ de la configuration. La ligne guard email est utilisée pour spécifier l'email et le nom du champ From:. watchlist délimite un block de définitions à superviser. La déclaration watchlist peut être spécifié plusieurs fois.

   title est utilisé pour ajouter un titre pour identifier le block. contactpoint est l'email du contact. path peut monitorer un fichier/répertoire ou exécuter des actions.

Autre exemple possédant 3 watchlist:
‹?xml version="1.0" ?›
‹!DOCTYPE config SYSTEM "iwatch.dtd"›
    
‹config›
    ‹guard email="admin@localhost" name="iWatch"›‹/guard›
    ‹watchlist›
        ‹title›Public Website‹/title›
        ‹contactpoint email="webmaster@example.com" name="WebMaster"/›
        ‹path type="single"›/var/www/localhost/htdocs‹/path›
        ‹path type="single" syslog="on"›/var/www/localhost/htdocs/About‹/path›
        ‹path type="recursive"›/var/www/localhost/htdocs/Photos‹/path›
    ‹/watchlist›
    ‹watchlist›
        ‹title›Operating System‹/title›
        ‹contactpoint email="admin@localhost" name="Administrator"/›
        ‹path type="recursive"›/etc/apache2‹/path›
        ‹path type="single"›/etc/passwd‹/path›
        ‹path type="recursive"›/etc/mail‹/path›
        ‹path type="exception"›/etc/mail/statistics‹/path›
        ‹path type="single" filter="shadow|passwd"›/etc‹/path›
    ‹/watchlist›
    ‹watchlist›
        ‹title›Only Test‹/title›
        ‹contactpoint email="root@localhost" name="Administrator"/›
        ‹path type="single" alert="off" exec="(w;ps -ef)|mail -s %f root@localhost"›/tmp/dir1‹/path›
        ‹path type="single" events="access,close" alert="off" exec="(w;ps -ef)|mail -s %f root@localhost"›/tmp/dir2‹/path›
        ‹path type="single" events="default,access" alert="off" exec="(w;ps -ef)|mail -s '%f is accessed' root@localhost"›/tmp/dir3‹/path›
        ‹path type="single" events="all_events" alert="off"›/tmp/dir4‹/path›
    ‹/watchlist›
‹/config›

^
25 mai 2017

htmlpdflatexmanmd




jail.conf

jail.conf, fail2ban.conf

Configuration pour le serveur fail2ban

   fail2ban a 4 types de fichier de configuration:

fail2ban.conf Configuration globale de fail2ban
filter.d/*.conf Filtres spécifiant comment détecter les erreurs d'authentification
action.d/*.conf Actions définissant les commandes pour bannir et débannir les adresses IP
jail.conf Les jails définissent les combinaisons de filtre avec les actions

Format des fichiers de configuration

Les fichiers .conf sont distribués par Fail2Ban. Il est recommandé que ces fichiers restent inchangés pour simplifier les mises à jours. Si nécessaire, les personnalisations devraient être fournies dans des fichiers .local. Par exemple, pour activer le jail [ssh-iptables-ipset] spécifié dans jail.conf, créer un fichier jail.local contenant:
jail.local
    [ssh-iptables-ipset]
    
    enabled = true

tail.d et fail2ban.d En plus des fichier .local, pour jail.conf et fail2ban.conf, il y a un répertoire correspondant contenant des fichier .conf additionnels. L'ordre de configuration des jail est:
[ENDSECTION]
[SECTION] name="-" table="listes" imbrication="1"
jail.conf jaid.d/*.conf
jail.local jail.d/*.local

Les fichiers de configuration ont des sections et des paire nom = valeur. Les fichiers de configuration peuvent inclure d'autres fichiers de configuration, qui sont souvent utilisé dans les filtres et actions, en utilisant les directives before et after. En utilisant les mécanismes d'interpolation de chaîne Python, d'autres définitions sont permise et peuvent ensuite être utilisées dans d'autres définitions sous la forme %(name)s:
baduseragents = IE|wget
failregex = %(known/failregex)s

Additionnellement à l'interpolation $(known/parameter)s, qui ne fonctionne pas pour les paramètres init de filtre et action, un tag d'interpolation ‹known/parameter› peut être utilisé. Cela permet d'étendre un paramètre un filtre ou action directement dans le jail sans créer de filtre séparément.
# filter.d/test.conf:
[Init]
test.method = GET
baduseragents = IE|wget
[Definition]
failregex = ^%(__prefix_line)\s+"‹test.method›"\s+test\s+regexp\s+-\s+useragent=(?:‹baduseragents›)

# jail.local:
[test]
# use filter "test", overwrite method to "POST" and extend known bad agents with "badagent":
filter = test[test.method=POST, baduseragents="badagent|‹known/baduseragents›"]

fail2ban.conf

   Ces fichier ont une section, [Definition]. Les éléments sont:

loglevel Niveau de verbosité des logs de sortie: CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. Défaut: ERROR
logtarget Cible des logs: filename, SYSLOG, STDERR ou STDOUT. Défaut: STDERR
socket Fichier socket. Défaut: /var/run/fail2ban/fail2ban.sock. utilisé pour la communication avec les serveur fail2ban
pidfile Fichier pid. Défaut: /var/run/fail2ban/fail2ban.pid
dbfile nom de la base de données. Défaut: /var/lib/fail2ban/fail2bn.sqlite3. Contient les données persistante.
dbpurgeage age de purge de la base, en secondes. Défaut: 86400

jail.conf

   Les options suivantes sont applicables dans les jail. Elles apparaissent dans une section spécifiant le nom du jail ou dans la section [DEFAULT]

filter Nom du filtre - nom d'un fichier dans /etc/fail2ban/filter.d/, sans l'extension
logpath Nom des fichiers de log à surveiller, séparés par des newline.
logencoding Encodage des fichiers de logs. Défaut: auto (utilise la locale système)
banaction Action pour le bannissement (défaut: iptables-multiport).
banaction_allports Idem, mais pour certains jails "allports" signifie "pam-generic" ou "recidive". Défaut: iptables-allports
action Actions dans /etc/fail2ban/action.d, sans l'extension
ignoreip Liste des IP à ne pas bannir. Peut inclure un masque cidr
ignorecommand La commande qui est exécutée pour déterminer si l'IP candidate pour le bannissement ne devrait pas être bannie
bantime Durée du ban
findtime Interval de temps, en secondes, avant l'heure courante où les erreurs comptent comme un ban
maxretry Nombre d'erreur qui se produisent dans findtime pour bannir une IP
backend Backend à utiliser pour détecter les changements dans le logpath. Défaut: auto, qui tente, dans l'ordre, pyinotify, gamin, systemd, polling.
usedns Utilise DNS pour résoudre les noms d'hôte qui apparaîssent dans les logs.
failregex Expression régulière Python à ajouter aux failregex du filtre.
ignoreregex expression régulière, si la ligne de log match, à ne pas considérer.

action.d/*.conf

   Les fichiers action spécifie quelles commande sont exécutées pour bannir et débannir une adresse IP. Les fichiers action ont 2 section, Definition et Init. La section Init définis des paramètres qui peuvent être écrasés pour un jail particulier. Les commandes suivantes peuvent être présents dans la section Definition

actionstart Commande à exécuter quand le jail démarre
actionstop Commande à exécuter quand le jail s'arrête
actioncheck Commande à exécuter avant tout autre action
actionban Commande à exécuter pour bannir l'adresse IP
actionunban Commande à exécuter pour débannir l'adresse IP

   La section Init permet de définir des actions spécifiques à l'action. Les éléments spéciaux suivants peuvent être définis dans la section Init:

timeout Délai max en seconde qu'une commande peut mettre à s'exécuter, avant d'être terminée

   Les commandes spécifiées dans la section Definition sont exécutées via un shell système donc les redirections shell et contrôle de process sont autorisés. Les commandes doivent retourner 0, sinon une erreur est loggée. De plus, si actioncheck qui avec un status non-0, il est considéré que le status du firewall a changé et fail2ban doit se réinitialiser. Les tags sont entre ‹›. Tous les éléments de la section Init sont des tags qui sont remplacés dans les commandes action. Plus d'une commande est autorisée. Chaque commande doit être sur une ligne séparée et indenté avec des espaces blanc.

Tags d'action

   Les tags suivants sont substitués dans l'actionban, actionunban, et actioncheck.

ip IPv6 à bannir
failures Nombre de fois que l'erreur se produit dans le fichier de log
ipfailures idem, mais le total de toutes les erreurs pour cette IP dans tous les jails, depuis la base persistante
ipjailfailures idem, mais le total basé sur les erreus de lIP pour le jail courant
time temp (epoch) du ban
matches Chaîne concaténées des lignes du fichier de log des matchs qui génèrent le ban. De nombreux caractères interprétés par le shell sont échappés pour éviter les injection
ipmatches idem, mais inclus toutes les lignes pour l'IP qui sont contenus avec la base persistante
ipjailmatches idem, mais les matches sont limités pour l'ip et pour le jail courant

Fichiers d'action Python

   Les actions basées sur python peuvent également être utilisés, où le nom de fichier doit être [actionname].pv. Le fichier python doit contenir une variable Action, qui pointe vers une classe python. Cette classe doit implémenter une interface minimum tel que décris dans fail2ban.server.action.ActionBase.

filter.d/*.conf

   Ces fichiers sont utilisés pour identifier les tentatives d'authentification échouées dans les fichiers de log et pour extraire l'adresse IP de l'hôte. La principale section est la section Definition. Il y a 2 définitions de filtre définie dans cette section:

failregex Expression régulière pour matcher les tentatives échouées.
ignoreregex Expression régulière pour identifier les entrées de log qui doivent être ignorées.

   Similairement aux actions, les filtres on une section Init qui peut écraser jail.conf/jail.local. Les éléments qui peuvent s'y trouver sont:

maxlines Nombre maximum de lignes à mettre en tampon pour matcher les expressions régulières multilignes
datepattern Spécifie une motif/regex de date personnalisé pour le détecteur de date
journalmatch Spécifie le journal systemd utilisé pour filtrer les entrées du journal.

   Les filtres peuvent également avoire une section INCLUDES, utilisée pour lire d'autres configurations:

before Indique que ce fichier est lu avant la section Definition
after Indisque que ce fichier est lu après la section Definition
^
09 juin 2010

htmlpdflatexmanmd




join

join

Écrit sur la sortie standard une ligne pour chaque paire de lignes en entrée qui ont des champs identiques

   Normalement, l'ordre de trie est spécifiée par LC_COLLATE. A moins que -t ne soit donné, la comparaison ignore les blancs au début et à la fin des champs joints, comme avec sort -b. Si --ignore-case est donné, la comparaison ignore la casse, comme avec sort -f

  Il peut être utile d'utiliser sort -k 1b,1 pour trier un fichier en champs à joindre.

OPTIONS

-a FILE-NUMBER Affiche une ligne pour chaque ligne 'unpairable' dans le fichier FILE-NUMBER (soit 1 soit 2), en plus de la sortie normale.
--check-order Quitte avec un message d'erreur si un fichier d'entrée n'est pas ordonné correctement.
--nocheck-order Ne vérifie pas si les fichiers en entrées sont triés. mode par défaut.
-e STRING Remplace les champs en sortie qui sont manquant dans l'entrée avec STRING.
-i, --ignore-case Ignore la casse.
-1 FIELD Joint sur le champs FIELD du fichier 1
-2 FIELD Joint sur le champs FIELD du fichier 2
-j FIELD Equivalent à -1 FIELD -2 FIELD
-o FIELD-LIST Construit chaque ligne en sortie en accord avec le format de FIELD-LIST. Chaque élément dans FIELD-LIST est soit le caractère '0' ou a la forme M.NM le numéro du fichier (1 ou 2) et N un numéro de champ.
-t CHAR Utilise le caractère CHAR comme séparateur de champ d'entrée et de sortie. Utiliser sort -t CHAR pour produire cet ordre.
-v FILE-NUMBER Affiche une ligne pour chaque ligne 'unpairable' dans FILE-NUMBER (soit 1 soit 2), au lieu de la sortie standard

Exemples

cat file1
a a1
c c1
b b1
cat file2
a a2
c c2
b b2
join file1 file2
a a1 a2
c c1 c2
b b1 b2
^
31 mars 2016

htmlpdflatexmanmd




journal-remote.conf

journal-remote.conf, journal-remote.conf.d

Fichiers de configuration du service de journalisation distant

   La configuration par défaut est définie durant la compilation, donc un fichier de configuration dans /etc/systemd/ contient les entrées commentées montrant les défaut. Quand un package doit personnaliser la configuration, il peut installer des configurations dans /usr/lib/systemd/*.conf.d/. Le fichier de configuration principal est lu avant tous les autres, et a la précédence la plus faible. Les fichiers dans un sous-répertoire sont triés alphabétiquement, sans regarder dans quel sous-répertoire il réside. Pour désactiver un fichier de configuration fournis par un vendeur, la manière recommandée est de placer un lien vers /dev/null dans le répertoire /etc avec le même nom de fichier que le fichier de configuration du vendeur.

OPTIONS

SplitMode host ou none
ServerKeyFile= Clé SSL au format PEM
ServerCertificateFile= Certificat CA au format PEM
TrustedCertificateFile= Certificat CA
^
31 mars 2016

htmlpdflatexmanmd




journalctl

journalctl

Gestion du journal systemd

   Permet de requêter le contenu du journal systemd qui est écrit par systemd-journald.service. Sans paramètre, affiche tout le journal, en commençant par les entrées les plus anciennes

   Si un ou plusieurs arguments de match sont passés, la sortie est filtrée en accord. Un match est dans le format "FIELD=VALUE" (ex: _SYSTEMD_UNIT=httpd.service), réferant aux composant d'une entrée de journal structuré. Voir systemd.journal-fields pour une liste de champs. Si plusieurs match sont spécifiés et matchant différents champs, les entrées de logs sont filtrés par les 2 (les entrées affichées matchent tous les champs). Si 2 matchs s'appliquent sur le même champs, les entrées affichées matchent une des valeurs du champs. Le caractère final '+' peut apparaître comme séparateur de mot entre les autres termes (OU logique)

  

OPTIONS

--no-full, --full, -l Réduit la taille des champs s'ils ne rentrent pas dans la largeur de colonne.
-a, --all Affiche tous les champs, même s'ils contiennent des cararctères non-imprimables ou sont très long
-f, --follow Affiche seulement les entrées de journal récent, et affiche les entrées en continue
-e, --pager-end Va immédiatement à la fin du journal dans le pager. Ne fonctionne qu'avec less
-n, --lines= Nombre de lignes à afficher (défaut: 10)
--no-tail Affiche toutes les lignes, même avec -f
-r, --reverse Les nouvelles entrées s'affiche en premier
-o, --output= Contrôle le formatage des entrées du journal. Prend une des options suivantes:

        short Est le défaut et génère une sortie la plus identique au formattage classique des fichiers syslogs, une entrée par ligne.
        short-iso Similaire, mais affiche les timestamp au format ISO 8601
        short-precise Similaire, mais affiche les timestamp avec une précision au microseconde.
        short-monotonic Similaire, mais affiche les timestamp monotonique
        verbose Affiche les entrée structurées avec tous les champs.
        export Sérialise le journal dans un flux binaire pour les sauvegardes et les transferts réseaux
        json Formate les entrées en structures de données JSON, une par ligne.
        json-pretty Similaire mais les formate sur plusieurs lignes
        json-sse Similaire, mais les format pour être utilisable pour Server-Sent Events
        cat Génère une sortie sans métadonnées, ni timestamp.

--utc Exprime de temps en UTC
-x, --catalog Ajoute les lignes de log avec les textes explicatifs du catalog de message. Cela va ajouter des textes d'aide aux messages de log dans la sortie si disponible.
-q, --quiet Supprime tous les message d'information (ex: --Logs begin at ...", "--Reboot --"), et tout messages de journaux système inaccessible quand lancé comme utilisateur normal.
-m, --merge Affiche les entrées de tous les journaux disponible, inclant ceux distants
-b [ID][±offset], --boot=[ID][±offset] Affiche les message d'un boot spécifique. Cela ajoute un match pour "_BOOT_ID=". L'argument peut être vide, dans ce cas, ajoute un match pour le boot courant.
--list-boots Affiche une liste de nombre de boots, leurs ID et le timestamp du premier et dernier message.
-k, --dmesg Affiche seulement les messages kernel. Implique -b et ajoute le match "_TRANSPORT=kernel"
-t, --identifier=SYSLOG_IDENTIFIER Affiche les messages pour l'identifiant syslog spécifié
-u, --unit=UNIT|PATTERN Affiche les messages pour l'unité spécifiée ou correspondant au motif. Peut être spécifié plusieurs fois
--user-unit= Affiche les messages pour l'unité de session utilisateur spécifié. Peut être spécifié plusieurs fois
-p, --priority= Filtre les messages par priorité ou plage de priorité. ( "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7))
-c, --cursor= Affiche le entrées depuis l'emplacement dans le journal spécifié par le curseur spécifié
--after-cursor= Affiche les entrées après l'emplacement spécifié par le curseur.
--show-cursor= Affiche le curseur après la dernière entrée
-S, --since=, -U, --until= Affiche les entrée depuis ou jusqu'à la date spécifiée. Le format devrait être au format "2012-10-30 18:17:16", voir systemd.time pour la spécification complète des dates.
-F, --field= Affiche toutes les valeurs possible que le champ spécifié peut prendre dans toutes les entrées du journal.
--system, --user Affiche les message des services système et kernel, ou de l'utilisateur courant. Non spécifié, affiche tous les messages que l'utilisateur peut voir.
-M, --machine= Affiche les messages d'un conteneur local.
-D DIR, --directory=DIR Répertoire où rechercher les journaux
--file=GLOB Opère sur les fichiers journaux spécifiés par le GLOB au lieu des chemins de journaux par défaut. Peut être spécifié plusieurs fois.
--root=ROOT Opère sur les catalogues sous le répertoire spécifié
--new-id128 Au lieu d'afficher le contenu du journal, génère un nouvel ID 128bits pour identifier les messages. C'est prévu pour les développeurs qui ont besoin d'un nouvel identifiant pour un nouveau message.
--header Affiche seulement les informations d'en-tête dus champs de journal accédés.
--disk-usage Affiche l'utilisation disque des fichiers journaux
--vacuum-size=, --vacuum-time=, --vaccum-files= Supprime les fichiers journaux archivés jusqu'à ce que l'espace disque qu'ils utilisent soit inférieur à la taille ou le nombre de journaux, ou postérieur à la date spécifié.
--list-catalog [128-bits ID...] Liste le contenu du catalogue de message.
--dump-catalog [128-bit-ID...] Affiche le contenu du catalogue de message
--update-catalog Met à jours les indexs de catalogue
--setup-keys Au lieu d'afficher le contenu des journaux, génère une nouvelle paire de clé pour FSS. Cela génère une clé de scellement et une clé de vérification. La clé de scellement est stockée dans le répertoire des journaux et devrait rester dans l'hôte. La clé de vérification devrait être stocké ailleurs.
--force Quand --setup-keys est passé et que FSS (Forward Secure Sealing) a déjà été configuré, recréé les clés FSS.
--interval= Spécifie l'interval de changement pour la clé en générant une paire de clé FSS avec --setup-keys. Un interval plus court augmente la consommation CPU mais raccourcis la plage de temps des altération de journaux indétectable. Défaut: 15min
--verify Vérifie le fichier journal pour sa consistance interne. Si le fichier a été généré avec FSS activé et la clé a été spécifiée dans --verify-key, l'authenticité du journal est vérifié.
--verify-key= Spécifie la clé de vérification FSS à utiliser pour l'opération --verify
--sync Demande au service de journalisation d'écrire toutes les données non-écrite dans les fichiers journaux
--flush Demande au service de journalisation de vider les logs stockés dans /run/log/journal dans /var/log/journal, si le stockage persistant est activé.
--rotate Demande au service de journalisation de tourner les fichiers journaux.
--no-pager N'utilise pas de pager.

Variables d'environnement

SYSTEMD_PAGER Pager à utiliser. Vide, ou 'cat' est équivalent à --no-pager
SYSTEMD_LESS Remplace les options par défaut de less ('FRSXMK')

Exemples

Collecter tous les logs
journalctl
Ajouter un match
journalctl _SYSTEMD_UNIT=avahi-daemon.service
Si 2 champs sont matchés, seules les entrées matchant les 2 expressions sont affichées
journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097
Si 2 matchs réfèrent au même champ, toutes les entrées matchant une des expression sont affichés
journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service
Avec '+', 2 expression peuvent être combinées
journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service
Affiche tous les logs générés par DBus
journalctl /usr/bin/dbus-daemon
Affiche tous les logs kernel du boot précédent
journalctl -k -b -1
Affiche un log du service système apache.service
journalctl -f -u apache
^
31 mars 2016

htmlpdflatexmanmd




journald.conf

journald.conf, journald.conf.d

Fichiers de configuration du service de journalisation

   La configuration par défaut est définie durant la compilation, donc un fichier de configuration dans /etc/systemd/ contient les entrées commentées montrant les défaut. Quand un package doit personnaliser la configuration, il peut installer des configurations dans /usr/lib/systemd/*.conf.d/. Le fichier de configuration principal est lu avant tous les autres, et a la précédence la plus faible. Les fichiers dans un sous-répertoire sont triés alphabétiquement, sans regarder dans quel sous-répertoire il réside. Pour désactiver un fichier de configuration fournis par un vendeur, la manière recommandée est de placer un lien vers /dev/null dans le répertoire /etc avec le même nom de fichier que le fichier de configuration du vendeur.

OPTIONS

Storage= Contrôle œu stocker les données. volatile stocke les donnée uniquement en mémoire, sous /run/log/journal, persistent stocke les données sur disque sous /var/log/journal et /run/log/journal au boot si le disque n'est pas accessible. auto est similaire mais ne créé pas /var/log/journal, "none" désactive le stockage et toutes les données sont supprimées. Défaut: auto.
Compress= (Bool). Si activé (défaut), les objets qui sont stockées dans le journal et qui sont plus grandes qu'un certain seuil, sont compressés avant d'être écrites.
Seal= (Bool). Si activé (défaut), et une clé sealing est disponible, FSS pour tous les fichiers journaux persistent est activé.
SplitMode= Contrôle si les fichiers journaux sont séparés par utilisateurs. uid génère un journal pour chaque utilisateur. login, les utilisateurs loggés ont un journal, mais les utilisateurs non-loggés et les utilisateurs système vont dans le journal système. none stocke tout dans le journal système. Défaut: uid
RateLimitInterval=
RateLimitBurst= Configure la limite appliquées à tous les messages générés dans le système. Si, dans l'interval de temps définis par RateLimitInterval, plus de message que RateLimitBurst sont loggés par un service, tous les autres messages dans l'interval sont supprimés. La limite est appliquée par service. Défaut 1000 messages en 30secondes. À 0, désactive les limites.
SystemMaxUse=
SystemKeepFree=
SystemMaxFileSize=
SystemMaxFiles=
RuntimeMaxUse=
RuntimeKeepFree=
RuntimeMaxFileSize=
RuntimeMaxFiles= Force les limites de taille dans les fichiers journaux. Les options préfixées par System s'appliquent aux fichiers stockés dans un système de fichier persistant, plus spécifiquement /var/log/journal. Les options préfixés pas Runtime s'appliquent aux fichiers stockés en mémoire volatile, plus spécifiquement /run/log/journal. MaxUser contrôle l'espace disque utilisable par le journal. KeepFree contrôle l'espace disque à laisser libre pour d'autres utilisations. Journald respecte les 2 limites et utilise la valeur la plus petite des 2 (défaut: 10% et 15%). MaxFileSize contrôle la taille de chaque fichier avant rotation, et MaxFiles contrôle combien de fichiers individuels conserver (Défaut: 100).
MaxFileSec= Temps maximum pour stocker les entrées dans un fichier journal avant la prochaine rotation.
MaxRetentionSec= Temps maximum pour stocker les entrées du journal. Contrôle si les fichiers journaux contenant des entrées plus anciennes que la date spécifiée sont supprimées.
SyncIntervalSec= Timeout avant synchronisation des fichiers sur disque. Une fois synchronisés, les fichiers sont placés OFFLINE. La synchro est toujours faite après un message de priorité CRIT, ALERT, ou EMERG. Défaut: 5min
ForwardToSyslog=
ForwardToKMsg=
ForwardToConsole=
ForwardToWall= Contrôle si les messages de log reçues par journald devraient être forwardés à syslog, au buffer de log kernel (kmsg), à la console système, ou comme message wall. Défaut: activé seulement pour Wall.
MaxLevelStore=
MaxLevelSyslog=
MaxLevelKMsg=
MaxLevelConsole=
MaxLevelWall= Contrôle le niveau de log max des messages à stocker sur disque, forwardés à syslog, kmsg, la console ou wall. (emerg, alert, crit, err, warning, notice, info, debug, ou une valeur entière de 0-7). Défaut: debug, debug, notice, info, emerg, respectivement.
TTYPath= Change la console TTY à utiliser si ForwardToConsole=yes est utilisé. Défaut: /dev/console.

Forward vers syslog

   Les événements journaux peuvent être transférés vers un service le log différent de 2 manières différentes. Avec la première méthode, les messages sont immédiatement transférés à un socket (/run/system/journal/syslog), où le service syslog traditionnel peut être lu. Cette méthode est contrôlée par l'option "ForwardToSyslog=". Avec la seconde méthode, un service syslog devient un client de journal normal, et lit les messages depuis les fichiers journaux, similairement à journalctl. Les messages n'ont pas à être lus immédiatement, ce qui permet à un service de log qui n'est pas lancé tout de suite au boot d'accéder aux mesages depuis le démarrage du système. De plus, les méta-données sont disponible. Cette méthode est disponible seulement si les messages sont stockés dans un fichier journal. Elle ne fonctionne pas avec Storage=none.
^
29 juin 2014

htmlpdflatexmanmd




.k5identity

.k5identity

Liste de règles pour sélectionner un principal

   Ce fichier, qui réside dans le home d'un utilisateur, contient une liste de règle pour sélectionner un principal client basé sur le serveur accédé. Ces règles sont utilisée pour choisir un cache d'accréditifs dans la collection de cache quand c'est possible. Chaque ligne a la forme

  principal field=value

  Si le principal serveur rencontre toutes les contrainte de champ, le principal est choisi comme principal client. Les champs suivant sont reconnus:

realm Si le domaine du principal du serveur est connus, il est matché avec cette valeur, qui peut être un pattern en utilisant les wildcard shell.
service Si le serveur principal est un principal basé sur l'hôte, son composant service est matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.
host Si le principal du serveur est un principal basé sur l'hôte, son nom d'hôte est convertis en minuscule et matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.

   Si le principal du serveur matche plusieurs lignes dans ce fichier, le principal depuis le premier matche est utilisé. Si aucune ligne ne matche, les accréditifs seront sélectionnés d'une autre manière, tel que le realm heuristic ou le cache primaire courant.

L'exemple suivant sélectionne le principal client alice@KRBTEST.COM si le serveur principal est dans ce domaine, le principal alice/root@EXAMPLE.COM si l'hôte serveur est dans un sous-domaine, et le principal alice/mail@EXAMPLE.COM en accédant au service IMAP sur mail.example.com:
alice@KRBTEST.COM realm=KRBTEST.COM
alice/root@EXAMPLE.COM host=*.servers.example.com
alice/mail@EXAMPLE.COM host=mail.example.com service=imap

^
29 juin 2014

htmlpdflatexmanmd




.k5login

.k5login

Liste de principaux Kerberos

   Ce fichier réside dans le home de l'utilisateur, contenant une liste de principaux Kerberos. tous ceux ayant des tickets valide pour un principal dans ce fichier est autorisé à accéder à l'hôte avec l'UID de l'utilisateur dont ce fichier est dans son home. Une utilisation commune est de placer ce fichier dans le home de root, autorisant les administrateurs système à accéder en root à l'hôte via Kerberos.

Exemples

Supposons que l'utilisateur Alice a un fichier .k5login dans son répertoire home contenant la ligne suivante:
bob@FOOBAR.ORG
Celà permet à bob d'utiliser Kerberos tel que SSH, pour accéder au compte Alice, en utilisant les tickets Kerberos de bob.
Supposons qu'Alice est un administrateur système. Alice et les autres administrateurs auront leurs principaux dans le .k5login de root:
alice@BLEEP.COM
joeadmin/root@BLEEP.COM
Cela permet aux administrateurs de se logger en root avec leur tickets.
^
27 juin 2014

htmlpdflatexmanmd




k5srvutil

k5srvutil


Commandes

list Liste les clé dans un keytab
change Utilise le protocole kadmin pour mettre à jours les clés dans la base Kerberos avec des clés générées aléatoirement, et met à jours les clés dans le keytab. Si un numéro de version de clé ne matche pas le numéro de version dans la base, l'opération échoue. Les anciennes clés sont laissées dans le keytab pour que des tickets existant continuent à fonctionner. Si le flag -i est donné, k5srvutil demande confirmation avant de changer chaque clé. -e permet de spécifier les types de chiffrement et de salt.
delold Supprime les anciennes clé du keytab.
delete Supprime les clés dans le keytab, demande confirmation.

   k5srvutil utilise kadmin pour éditer le keytab.

OPTIONS

-i Demande confirmation pour chaque opération
-f filename Spécifie le fichier keytab
keysalts Spécifie les types de chiffrement et de salt à utiliser.
^
20 juin 2014

htmlpdflatexmanmd




kadm5.acl

kadm5.acl

Fichier acl pour kadmind

   Kadmind utilise un fichier d'acl pour gérer les droits d'accès à la base Kerberos. Pour les opérations qui affectent les principaux, le fichier d'acl contrôle également quels principaux peuvent opérer sur quels autres principaux. L'emplacement par défaut est LOCALSTATEDIR/krb5kdc/kadm5.acl ou la variable acl_file dans kdc.conf.

Syntaxe

   Les lignes vides ou commençant par # sont ignorées. les lignes contenant une entrée acl a le format suivant:

  principal permissions [target_principal [ restrictions] ]

  Note: l'ordre des lignes est importante. La première entrée correspondante va contrôler l'accès pour un acteur principal sur un principal cible.

principal (Nom de principal complet ou partiel) Spécifie le principal dont les permissions sont définies
permissions Spécifie quels opérations peuvent être effectuées ou non par le principal. C'est une chaîne d'un ou plusieurs caractères ou leur opposé majuscule qui désactive cette permission:

        a ajout de principaux ou stratégies
        c changer les mots de passe pour les principaux
        d suppression de principaux ou stratégies
        i demandes de renseignements concernant les principaux et stratégies
        l lister les principaux ou stratégies
        m modification de principaux ou stratégies
        p propagation de la base de principaux
        s paramétrage explicite des clés pour un principal
        x raccourci pour admcil. Tous les privilèges

target_principal (Optionnel. Nom de principal complet ou partiel) Spécifie le principal sur lequel les permissions s'appliquent. chaque composant du nom peut être wildcarded (*). Peut également inclure des référence au principal, dans lequel *number matche le wilcard correspondant dans principal
restrictions (optionnel) Une chaîne de flags. Les restrictions permises sont:

        {+|-}flagname flag est forcé à la valeur indiquée. Les flags permissifs sont les même que les flags + et - pour les commandes add_principal et modify_principal de kadmin.
        -clearpolicy La stratégie est forcée à être vide
        -policy pol La stratégie est forcée à pol
        -{expire, pwexpire, maxlife, maxrenewlife} time (chaîne de temps getdate) la valeur associée est forcée à MIN(time, valeur demandée)

           Ces flags agissent comme restriction sur toute opération d'ajout ou de modification qui sont permis dans la ligne d'ACL.

   Attention: si le fichier d'acl est modifié, kadmind doit être redémarré pour prendre en compte les modifications.

Exemple

Exemple de fichies kadm5.acl:
*/admin@ATHENA.MIT.EDU    *    
joeadmin@ATHENA.MIT.EDU ADMCIL
joeadmin/*@ATHENA.MIT.EDU il    */root@ATHENA.MIT.EDU
*/root@ATHENA.MIT.EDU cil    *1@ATHENA.MIT.EDU
*/*@ATHENA.MIT.EDU i
*/admin@EXAMPLE.COM x    *    -maxlife 9h -postdateable

ligne 1 Tout principal dans le domaine ATHENA.MIT.EDU avec une instance admin a tous les privilèges administratifs
ligne 2 et 3 L'utilisateur joeadmin a toutes les permissions avec son instance admin, joeadmin/admin@ATHENA.MIT.EDU (matche de la ligne 1), il n'a aucune permission avec son instance joeadmin@ATHENA.MIT.EDU (matche de la ligne 2). Ses instances root et autre non admin ont les permissions de lister et demander avec tout principal qui a l'instance root (macthe de la ligne 3).
ligne 4 Tout principal root dans ATHENA.MIT.EDU peut demander, lister ou changer les mots de passe de leur instance nul, mais pas les autres instance null.
ligne 5 Tout principal dans ATHENA.MIT.EDU (sauf joeadmin@ATHENA.MIT.EDU comme mentionné plus haut) a les privilèges demander.
ligne 6 Finallement, tout principal avec une instance admin dans EXAMPLE.COM a toutes les permissions, mais tout principal qu'ils créent ou modifient ne seront par capable d'obtenir de tickets post-datés ou avec une durée de vie supérieur à 9 heures.
^
25 juin 2014

htmlpdflatexmanmd




kadmin

kadmin

Interface CLI pour l'administration de Kerberos

   kadmin et kadmin.local sont des interfaces en ligne de commande pour le système d'administration de Kerberos. Ils fonctionnent de manière similaire à l'exception que kadmin.local communique directement avec le fichier de base de données.

   Le client distant kadmin utilise Kerberos pour s'authentifier auprès de kadmind en utilisant le principal de service kadmin/ADMINHOST, où ADMINHOST est le fqdn du serveur d'administration, ou kadmin/admin. Si le cache d'accréditifs contient un ticket pour un de ces principaux, et que l'option -c est spécifié, ce ticket est utilisé pour s'authentifier à kadmind. Sinon les options -p et -k sont utilisés pour spécifier le nom du principal client utilisé pour s'authentifier. Une fois que kadmin a déterminé le nom du principal, il demande un ticket de service au KDC, et l'utilise pour s'authentifier à kadmind.

OPTIONS

-r realms Utilise de domaine spécifié par défaut
-p principal Utilise le principal spécifié pour s'authentifier. Sinon, kadmin va ajouter /admin au nom de principal primaire du ccache par défaut, la valeur de la variable d'environnement USER, ou le username obtenu par getpwuid, dans cet ordre.
-k Utilise un keytab pour déchiffrer la réponse du KDC au lieu de demander un mot de passe. Dans ce cas, le principal par défaut sera host/hostname. S'il n'y a par de keytab spécifié avec l'option -t, le keytab par défaut sera utilisé.
-t keytab Utilise keytab pour déchiffrer la réponse du KDC. Peut seulement être utilisé avec l'option -k
-n  Demande un traitement anonyme. 2 types de principaux anonyme sont supportés. Pour l'anonymité complète, configurer PKINIT et utiliser l'option -n avec un principal sous la forme @REALM. Si permis par le KDC, un ticket anonyme sera retourné. Une seconde forme est supportée, et cache l'identité du client mais pas le domaine du client. Pour ce mode, utiliser kinit -n avec un principal normal. Si supporté par le KDC, le principal, mais pas le domaine, sera remplacé par le principal anonymous.
-c credentials_cache Utile de cache d'accréditifs spécifié. Le cache devrait contenir un ticket de service pour kadmin/ADMINHOST ou kadmin/admin. Si non spéifié, kadmin demande un nouveau ticket au KDC et le stocke dans son propre cache temporaire.
-w password Utilise le mot de passe au lieu de le demander
-q query Effectue le requête spécifiée et quitte.
-d dbname Spécifie le nom de la base KDC. Ne s'applique par au module de base LDAP
-s admin_server[:port] Spécifie le serveur d'administration à contacter
-m Avec kadmin.local, demande le mot de passe maître de la base au lieu de chercher un fichier stash
-e “enc:salt...” Définis la liste keysalt à utiliser pour toute nouvelle clé créée.
-O Force l'utilisation de l'ancienne authentification AUTH_GSSAPI
-N Empêche l'utilisation de l'ancienne authentification AUTH_GSSAPI
-x db_args Spécifie les arguments spécifique à la base. les options supportée pour le module de base LDAP sont:

        -x host=hostname Spécifie le serveur LDAP à contacter
        -x binddn=bind_dn DN de l'objet à utiliser par le serveur d'administration pour le bind ldap.
        -x bindpwd=bind_password Mot de passe pour le binddn
        -x debug=level Niveau de verbosité pour le client OpenLDAP.

Commandes

   En utilisant le client distant, les commandes disponible peuvent être restreins en accord avec les privilèges dans kadm5.acl.

add_principal

   Crée le principal spécifié, en demandant 2 fois le mot de passe. Si aucune stratégie de mot de passe n'est spécifiée, la stratégie nommée default est assignée au principal si elle existe. Cependant, créer une stratégie default ne va pas assigner automatiquement ce stratégie aux principaux déjà existant. Cette stratégie peut être supprimée avec l'option -clearpolicy

        -expire expdate (chaîne getdate_time) Date d'expiration du principal
        -pwexpire pwexpdate (chaîne getdate_time) Date d'expiration du mot de passe
        -maxlife maxlife (chaîne getdate_time) Durée de vie de ticket max pour le principal
        -maxrenewlife maxrenewlife (chaîne getdate_time) Durée de vie de renouvellement max des tickets
        -kvno kvno Numéro de version de clé initial
        -policy policy Stratégie de mot de passe utilisé par ce principal.
        -clearpolicy Empêche l'assignation automatique d'une stratégie si non spécifiée par -policy
        {-|+}allow_postdated Droit d'obtenir des tickets post-datés
        {-|+}allow_forwardable Droit d'obtenir des tickets forwardable
        {-|+}allow_renewable Droit d'obtenir des tickets renouvelable
        {-|+}allow_proxiable Droit d'obtenir des tickets proxiable
        {-|+}allow_dup_skey Droit d'effectuer une authentification user-to-user
        {-|+}requires_preauth force le principal à ce pré-authentifier
        {-|+}requires_hwauth Utiisation d'un hardware pour la pré-authentification
        {-|+}ok_as_delegate flag okay as delegate dans les tickets fournis avec ce principal en tant que service.
        {-|+}allow_svr Droit de délivrer des tickets de service pour ce principal
        {-|+}allow_tgs_req Droit d'obtenir un TGS pour un ticket de service pour ce principal
        {-|+}allow_tix Droit d'obtenir un ticket pour ce principal
        {-|+}needchange Force le changement de mot de passe à la prochaine authentification
        {-|+}password_changing_service Marque ce principal comme principal de service de changement de mot de passe
        {-|+}ok_to_auth_as_delegate Droit d'obtenir des tickets forwardable à soi-même depuis des utilisateurs arbitraires
        {-|+}no_auth_data_required Droit d'ajouter des données PAC ou AD-SIGNEDPATH
        -randkey Définis la clé du principal à une valeur aléatoire
        -nokey Crée un principal sans clé
        -pw password Définis de mot de passe pour ce principal
        -e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
        -x db_princ_args Options spécifique à la base:

                -x dn=dn Spécifie l'objet LDAP qui va contenir le principal Kerberos à créer
                -x linkdn=dn Spécifie l'objet LDAP pour lequel le nouveau principal Kerberos va pointer
                -x containerdn=container_dn Spécifie le conteneur sous lequel le principal Kerberos est créé
                -x tktpolicy=policy Associe une stratégie de ticket au principal Kerberos

Note

   Les options containerdn et linkdn ne peuvent pas être spécifiés avec l'option dn. Si ces options ne sont pas spécifiées, les principaux sont créés sous le conteneur principal configurés dans le domaine. Ces options devraient pointer dans les sous-arborescences ou le conteneur principal configurés dans le domaine.

Exemple
kadmin: addprinc jennifer
WARNING: no policy specified for "jennifer@ATHENA.MIT.EDU";
defaulting to no policy.
Enter password for principal jennifer@ATHENA.MIT.EDU:
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
Principal "jennifer@ATHENA.MIT.EDU" created.
kadmin:

modify_principal

   Modifie le principal spécifié, en changeant les champs spécifiés. Les options de add_principal s'appliquent également à cette commande, excepté -randkey, -pw et -e. Cette commande nécessite les privilège modify. Alias: modprinc

        -unlock Débloque un principal.

rename_principal

   Renomme l'ancien principal avec le nouveau principal. Demande configuration sauf si -force est donné. Nécessite les privilèges add et delete. Alias: renprinc

delete_principal

   Supprime le principal spécifié de la base. emande configuration sauf si -force est donné. Nécessite les privilèges delete. Alias: delprinc

change_password

   Change le mot de passe du principal. Demande un nouveau mot de passe si -randkey ou -pw ne sont pas spécifiés. Nécessite les privilège changepw, ou que le principal qui lance ce programme est le même que le principal à changer. Aliar: cpw

        -randkey Définis la clé du principal à une valeur aléatoire
        -pw password Définis de mot de passe pour ce principal
        -e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
        -keepold Conserve les clés existantes dans la base.

Exemple
kadmin: cpw systest
Enter password for principal systest@BLEEP.COM:
Re-enter password for principal systest@BLEEP.COM:
Password for systest@BLEEP.COM changed.
kadmin:

purgekeys

   Purge les anciennes clé du principal. Si -keepkvno est spécifié, alors seul les clés avec des kvno inférieur sont purgés. Si -all est spécifié, purge toutes les clés. Nécessite le privilège modify

get_principal

   Récupère les attributs du principal. L'option -terce affiche les champs en tant que chaîne séparés par des tabulations. Nécessite le privilège inquire, ou que le principal utilisant le programme soit le même que le principal cible. Alias: getprinc

Exemple
kadmin: getprinc tlyu/admin
Principal: tlyu/admin@BLEEP.COM
Expiration date: [never]
Last password change: Mon Aug 12 14:16:47 EDT 1996
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]
    
kadmin: getprinc -terse systest
systest@BLEEP.COM 3 86400 604800 1
785926535 753241234 785900000
tlyu/admin@BLEEP.COM 786100034 0 0
kadmin:

list_principal

   Récupère des noms de principal. L'expression est une expression glob qui peut contenir les caractères *, ? et []. Tous les noms de principaux qui matche l'expression sont affichés. Sans expression, liste tous les principauix. Si l'expression ne contient pas un caractère @, ce caractère est ajouté avec le domaine local à l'expression. Nécessite le privilège list. Alias: listprincs, get_principals, get_princs

Exemple
kadmin: listprincs test*
test3@SECURE-TEST.OV.COM
test2@SECURE-TEST.OV.COM
test1@SECURE-TEST.OV.COM
testuser@SECURE-TEST.OV.COM
kadmin:

get_strings

   Affiche les attributs chaîne dans le principal. Nécessite le privilège inquire. Alias: getstr

set_strings

   Définis un attribut chaîne dans le principal. Les attributs chaîne sont utilisés pour fournir une configuration par principal au KDC et certaine modules du KDC. Nécessite le privilège modify. Alias setstr. Les attributs suivants sont reconnus par le KDC:

        session_enctypes Spécifie les types de chiffrement supportés pour les clés session quand le principal est authentifié en tant que serveur.

del_strings

   Supprime un attribut chaîne du principal. Nécessite le privilège delete. Alias: delstr

add_policy

   Ajoute une stratégie de mot de passe à la base. Nécessite le privilège add. Alias: addpol

        -maxlife time (chaîne getdate_time) Définis la durée de vie max d'un mot de passe
        -minlife time (chaîne getdate_time) Définis la durée de vie min d'un mot de passe
        -minlength length Définis la longueur maximum d'un mot de passe
        -minclasses number Définis le nombre minimum de classes de caractères requis dans un mot de passe. Les 5 classes sont: minuscule, majuscule, nombres, ponctuation et espaces blancs.
        -history number Définis le nombre de clé à conserver pour un principal. Non supporté avec le module LDAP
        -maxfailure maxnumber Définis le nombre d'échec d'authentification avant que le principal soit bloqué. 0 le désactive.
        -failurecountinterval failuretime (chaîne getdate_time) Définis le temps permis entre les échecs d'authentification.
        -lockoutduration lockouttime (chaîne getdate_time) Définis la durée pour lequel le principal est bloqué. 0 signifie que le compte est bloqué jusqu'à ce qu'un administrateur le débloque.
        -allowedkeysalts Spécifie les tuples key/salt supportés pour les clés à long terme en définissant ou en changeant un mot de passe de principal. Les tuples doivent être séparés par une virgule. Pour enlever le tuple de la stratégie, utiliser "-"

Exemple
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
kadmin:

modify_policy

   Modifie la stratégié de mot de passe spécifiée. Les options sont les même que pour add_policy. Nécessite le privilège modify. Alias: modpol

delete_policy

   Supprime la stratégie de mot de passe spécifiée. Demande confirmation. Échoue si la stratégie est utilisée par un principal. Nécessite le privilège delete. Alias: delpol

Exemple
kadmin: del_policy guests
Are you sure you want to delete the policy "guests"?
(yes/no): yes
kadmin:

get_policy

   Affiche les valeurs de la stratégie spécifiées. -terse affiche les champs séparés par des tabulations. Nécessite le privilège inquire. Alias: getpol

Exemple
kadmin: get_policy admin
Policy: admin
Maximum password life: 180 days 00:00:00
Minimum password life: 00:00:00
Minimum password length: 6
Minimum number of password character classes: 2
Number of old keys kept: 5
Reference count: 17
    
kadmin: get_policy -terse admin
admin 15552000 0 6 2 5 17
kadmin:

list_policies

   Liste des stratégie basée sur l'expression. Nécessite le privilège list. Alias: listpols, get_policies, getpols

Exemple
kadmin: listpols
test-pol
dict-only
once-a-min
test-pol-nopw
    
kadmin: listpols t*
test-pol
test-pol-nopw
kadmin:

ktadd

   Ajoute un principal, ou tous les principaux matchant l'expression de l'option glob, à chaque fichier keytab. Chaque clé de principal est randomisé dans le processus. Nécessite les privilèges inquire et changepw. pour utiliser -glob, nécessite le privilège list.

        -k[eytab] keytab Utilise le fichier keytab spécifié
        -e enc:salt,... Utilise la liste keysalt spécifiée
        -q mode silencieux
        -norandkey Ne randomise pas les clé. Ne peut pas être utilisé avec -e.

Exemple
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
    encryption type aes256-cts-hmac-sha1-96 added to keytab
    FILE:/tmp/foo-new-keytab
kadmin:

ktremove

   Supprime des entrées pour le principal spécifié du keytab. Ne nécessite aucune permission. Si all est spéficié, toutes les entrées pour le principal sont supprimés; si old est spécifié, toutes les entrée sauf le kvno le plus récent sont supprimés. Si kvno est spécifié, supprime les entrées avec ce kvno.

        -k[eytab] keytab Utilise le fichier keytab spécifié
        -q mode silencieux

Exemple
kadmin: ktremove kadmin/admin all
Entry for principal kadmin/admin with kvno 3 removed from keytab
    FILE:/etc/krb5.keytab
kadmin:

lock

   Bloque la base. Ne fonctionne qu'avec le module DB2

unlock

   Réactive la base après un lock

list_requests

   Liste les demandes kadmin disponible. Alias lr, ?

quit

   Quitte le programme. Alias exit,q
^
25 juin 2014

htmlpdflatexmanmd




kadmind

kadmind

Serveur d'administration Kerberos

   kadmind lance le serveur d'administration Kerberos. kadmind est généralement lancé sur le serveur maître. Si la base du KDC utilise le module LDAP, le serveur d'administration et le KDC n'ont pas besoin d'être sur la même machine. kadmind accepte les demandes distantes depuis les programmes kadmin et kpasswd pour administrer les informations dans la base.

   Une fois le serveur lancé, il se place lui-même en tâche de fond. kadmind peut être configuré pour la propagation incrémentale de la base, qui permet aux esclaves de recevoir les principaux et les stratégie incrémentalement au lieu d'un dump complet. La propagation incrémentale nécessite le principal kiprop/MASTER\@REALM où MASTER est le nom d'hôte canonique du KDC maître et REALM est le domaine.

OPTIONS

-r realm Spécifie le domaine Kerberos
-m Demande le mot de passe maître au lieu d'un fichier sur le disque.
-nofork Ne met pas le serveur en tâche de fond
-port port-number Port d'écoute du serveur
-P pid_file Spécifie le PID du processus
-p kdb5_util_path Spécifie de chemin de la commande kdb5_util pour dumper le KDC en réponse à une re-synchronisation complète que iprop est activé
-K kprop_path Spécifie le chemin vers la commande kprop pour envoyer des dumps complets en réponse à une re-synchonisation complète.
-F dump_file Spécifie le chemin à utiliser pour dumper le KDB en réponse à une re-synchonisation complète
-x db_args Spécifie les argument spécfique à la base.

        -x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
        -x host=ldapuri Spécifie le serveur LDAP à contacter
        -x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
        -x bindpwd=bind_password Mot de passe du binddn
        -x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
^
09 février 2014

htmlpdflatexmanmd




kbuildsycoca

kbuildsycoca

Reconstruit le cache de configuration système. Il s'assure du bon fonctionnement des opérations de KDE en lisant dans tous les fichiers .desktop, .xml, et .protocol pour construire une base binaire.

OPTIONS

--nosignal Ne pas signaler les applications à mettre à jours
--noincremental Désactive les mises à jours incrémentales, relit tout.
--checkstamps Vérifie le timestamps des fichiers
--nocheckfiles Désactive la vérification des fichiers
--global Créé une base globale
--menutest Effectue un test de génération de menu uniquement
--track menu-id Traque l'id de menu dans un but de déboggage

Options QT

--display displayname Spécifier l'affichage du serveur X
--session ‹sessionId› Spécifier l'application à restaurer
--cmap Amène l'application à installer une palette de couleurs privée sur un affichage sur 8 bits
--ncols ‹count› Limite le nombre de couleurs allouées dans le cube de couleurs pour un affichage sur 8 bits, si l'application utilise les spécifications de couleurs QApplication::ManyColor
--nograb Demande à Qt de ne jamais capturer la souris ou le clavier
--dograp Annule l'effet de --nograb
--sync Passe en mode synchrone
--fn, --font ‹fontname› Définit la police de l'application
--bg, --background ‹color› Définit la couleur de fond par défaut et une palette pour l'application (les ombres claires et sombres sont calculées)
--fg, --foreground ‹color› Définit la couleur de premier plan par défaut
--btn, --button ‹color› Définit la couleur par défaut des boutons
--name ‹name› Définit le nom de l'application
--title ‹title› Définit le titre de l'application (légende)
--testability charger l'infrastructure de testabilité
--visual TrueColor Force l'application à utiliser un affichage en couleurs réelles sur un affichage sur 8 bits
--inputstyle ‹inputstyle› Définit le style d'entrée XIM (X Input Method). Les valeurs possibles sont « onthespot », « overthespot », « offthespot » et « root »
--im ‹XIM server› Définir le serveur XIM
--noxim Désactiver XIM
--reverse Reflète la disposition entière des composants graphiques (« widgets »)
--stylesheet ‹file.qss› Applique la feuille de style Qt aux composants graphiques de l'application
--graphicssystem ‹system› Utilise un système graphique différent au lieu du système par défaut, les options sor et opengl (expérimental)

Options de KDE

--caption ‹caption› Utiliser caption comme nom dans la barre de titre
--icon ‹icon› Utiliser icon comme icône de l'application
--config ‹filename› Utiliser un fichier de configuration auxiliaire
--nocrashhandler Désactiver le gestionnaire de pannes.
--waitforwm Attend un gestionnaire de fenêtres compatible avec WM_NET
--style ‹style› définit le style de l'interface graphique de l'application
--geometry ‹geometry› définit la géométrie de client du composant graphique (widget) principal

Fichiers

/var/tmp/kde-$USER/ksycoca4 Emplacement par défaut où les fichiers de cache sont stockés

Variables d'environnement

KDEDIRS Répertoires faisant partie de l'installation de KDE
KDESYCOCA Chemin des fichiers de base de données de sycoca
^
01 janvier 2014

htmlpdflatexmanmd




kcheckrunning

kcheckrunning

Indiquer l'état courant d'une session KDE

   Programme simple qui indique si une session KDE est déjà en cour (resultCode= 0), si $DISPLAY n'est pas définis ou ne peut pas se connecter au X server (resultCode = 2).

^
26 juin 2014

htmlpdflatexmanmd




kdb5_ldap_util

kdb5_ldap_util

Utilitaire de maintenance de la base LDAP de Kerberos

OPTIONS

-D user_dn DN de l'utilisateur pour les opérations sur le serveur
-w passwd Mot de passe de l'utilisateur
-H ldapuri URI du serveur LDAP à contacter.

Commandes

create [-subtrees subtree_dn_list] [-sscope search_scope] [-containerref container_reference_dn] [-k mkeytype] [-kv mkeyVNO] [-m|-P password|-sf stashfilename] [-s] [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] Crée un domaine dans l'annuaire.

        -subtrees subtree_dn_list Spécifie la liste des subtrees contenant les principaux d'un domaine, séparés par ":"
        -sscope search_scope Spécifie le scope de recherche pour les principaux sous le subtree (1 - onelevel, 2 - subtree)
        -containerref container_reference_dn DN du conteneur dans lequel les principaux d'un domaine seront créés.
        -k mkeytype Spécifie le type de clé de la clé maître dans la base.
        -kv mkeyVNO Spécifie le numéro de version de la clé maître dans la base; défaut: 1.
        -m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
        -P password Spécifie le mot de passe maître.
        -r realm Spécifie le domaine Kerberos
        -sf stashfilename Spécifie le fichier stash pour le mot de passe maître.
        -s Spécifie que le fichier stash est à créer
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    create -subtrees o=org -sscope SUB -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Initializing database for realm 'ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

modify [-subtrees subtree_dn_list] [-sscope search_scope] [-containerref container_reference_dn] [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] Modifie les attributs d'un domaine.

        -subtrees subtree_dn_list Spécifie la liste des subtrees contenant les principaux d'un domaine, séparés par ":"
        -sscope search_scope Spécifie le scope de recherche pour les principaux sous le subtree (1 - onelevel, 2 - subtree)
        -containerref container_reference_dn DN du conteneur dans lequel les principaux d'un domaine seront créés.
        -r realm Spécifie le domaine Kerberos
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu modify +requires_preauth -r
    ATHENA.MIT.EDU
Password for "cn=admin,o=org":
shell%

view [-r realm] Affiche les attribut d'un domaine. -r spécfie le domaine Kerberos de la base

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    view -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Realm Name: ATHENA.MIT.EDU
Subtree: ou=users,o=org
Subtree: ou=servers,o=org
SearchScope: ONE
Maximum ticket life: 0 days 01:00:00
Maximum renewable life: 0 days 10:00:00
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE

destroy [-f] [-r realm] Supprime un domaine existant. -f ne demande pas confirmation, -r spécifie de domaine de la base.

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu destroy -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Deleting KDC database of 'ATHENA.MIT.EDU', are you sure?
(type 'yes' to confirm)? yes
OK, deleting database of 'ATHENA.MIT.EDU'...
shell%

list Liste le nom des domaines

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu list
Password for "cn=admin,o=org":
ATHENA.MIT.EDU
OPENLDAP.MIT.EDU
MEDIA-LAB.MIT.EDU
shell%

stashsrvpw [-f filename] servicedn Permet à un administrateur de stocker un mot de passe pour un objet service dans un fichier pour que le KDC et le serveur d'administration puissent l'utiliser pour s'authentifier auprès du serveur LDAP. -f filename est le chemin complet du fichier, servicedn est le DN de l'objet service.

Exemples
kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyfile
    cn=service-kdc,o=org
Password for "cn=service-kdc,o=org":
Re-enter password for "cn=service-kdc,o=org":

create_policy [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name Crée une stratégie de ticket dans l'annuaire.

        -r realm Spécifie le domaine Kerberos
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.
        policy_name Nom de la stratégie de ticket

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    create_policy -r ATHENA.MIT.EDU -maxtktlife "1 day"
    -maxrenewlife "1 week" -allow_postdated +needchange
    -allow_forwardable tktpolicy
Password for "cn=admin,o=org":

modify_policy [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name Modifie les atributs d'une stratégie de ticket. Les options sont les même que pour create_policy

Exemples
kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu modify_policy -r ATHENA.MIT.EDU
    -maxtktlife "60 minutes" -maxrenewlife "10 hours"
    +allow_postdated -requires_preauth tktpolicy
Password for "cn=admin,o=org":

view_policy [-r realm] policy_name Affiche les attributs d'une stratégie de ticket. policy_name est le nom de la stratégie

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    view_policy -r ATHENA.MIT.EDU tktpolicy
Password for "cn=admin,o=org":
Ticket policy: tktpolicy
Maximum ticket life: 0 days 01:00:00
Maximum renewable life: 0 days 10:00:00
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE

destroy_policy [-r realm] [-force] policy_name Détruit une stratégie de ticket. -force ne demande pas confirmation.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    destroy_policy -r ATHENA.MIT.EDU tktpolicy
Password for "cn=admin,o=org":
This will delete the policy object 'tktpolicy', are you sure?
(type 'yes' to confirm)? yes
** policy object 'tktpolicy' deleted.

list_policy [-r realm] Liste les stratégie de ticket dans le domaine.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    list_policy -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
tktpolicy
tmppolicy
userpolicy

^
25 juin 2014

htmlpdflatexmanmd




kdb5_util

kdb5_util

Utilitaire de maintenance de la base Kerberos

   kdb5_util permet à un administrateur d'effectuer des procédures de maintenance dans la base Kerberos. Les base peuvent être crées, détruites, et dumpé/chargé vers/depuis un fichier. kdb5_util peut créer un fichier stash pour le clé maître Kerberos. Quand kdb5_util est lancé, il tente de récupérer la clé maître et d'ouvrir la base. Cependant, l'exécution continue sans s'occuper de savoir s'il a réussi, parce que la base peut ne pas exister ou le fichier stash peut être corrompus. Noter que certains module KDC ne supportent pas cette commande.

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom de la base de données Kerberos principale.
-k mkeytype Spécifie le type de clé de la clé maître dans la base.
-kv mkeyVNO Spécifie le numéro de version de la clé maître dans la base; défaut: 1.
-M mkeyname Nom du principal pour la clé maître dans la base,
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-sf stash_file Spécifie le fichier stash pour le mot de passe maître.
-P password Spécifie le mot de passe maître.

Commandes

create [-s] Crée une nouvelle base de données. -s créé également le fichier stash.
destroy [-f] Supprime une base de données. -f ne demande pas confirmation à l'utilisateur.
stash [-f keyfile] Stocke la clé du principal maître dans un fichier stash. -f écrase le keyfile dans kdc.conf
dump [-b7|-ov|-r13] [-verbose] [-mkey_convert] [-new_mkey_file mkey_file] [-rev] [-recurse] [filename [principals...]] Dumps la base courante et la base KADM5 dans un fichier ASCII. Par défaut, la base est dumpé dans le format courant.

        -b7 Dump dans le format Kerberos 5 beta 7
        -ov Dump au format ovsec_adm_export
        -r13 Dump au format Kerberos 5 1.3.
        -r18 Dump au format Kerberos 5 1.8.
        -verbose Affiche le nom de chaque principal et stratégie tel que dumpés
        -mkey_convert Demande pour une nouvelle clé maître. Cette clé est utilisé pour re-chiffrer la clé principal dans le dump
        -new_mkey_file mkey_file Nom du fichier stash.
        -rev dump dans l'ordre inverse. Permet de récupérer des principaux qui ne se dump pas normalement.
        -recurse Dump la base récursivement.

load [-b7|-ov|-r13] [-hash] [-verbose] [-update] filename [dbname] Charge un dump dans la base. Sans option pour déterminer le format du dump, le format est détecté automatiquement. Sauf avec l'option -udpate, load créé une nouvelle base contenant uniquement les données dans le dump.

        -b7 Spécifie que le dump est au format Kerberos 5 Beta 7
        -ov Spécifie que le dump est au format ovsec_adm_import
        -r13 Spécifie que le dump est au format Kerberos 5 1.3
        -r18 Spécifie que le dump est au format Kerberos 5 1.8
        -hash La base est stockée comme hash. Non spécifiée, la base est stockée comme un btree. Non recommandé.
        -verbose Affiche le nom de chaque principal et stratégie tel que dumpés
        -update Ajoute le dump à une base existante.

ark [-e enc:salt,...] principal Ajoute de nouvelles clé aléatoire au principal. -e spécifie la liste de type de chiffrement et de salt à utiliser.
add_mkey [-e etype] [-s] Ajoute une nouvelle clé maître, mais ne la marque par active. -e spécifie la liste de type de chiffrement et de salt à utiliser. -s place la clé dans le fichier stash (créé s'il n'existe pas)
use_mkey mkeyVNO [time] Définis le temps d'activation de la clé maître spécifiée par mkeyVNO. Une fois une clé maître active, elle sera utilisé comme nouvelle clé principal. si time n'est pas spécfié, l'heure courante est utilisée. time est au format getdate_time
list_mkeys Liste toutes les clés maître, de la plus récente à la plus ancienne.
purge_mkeys [-f] [-n] [-v] Supprime les clé maître non utilisée pour protéger un principal.

        -f Ne demande pas confirmation
        -n  Dry run, affiche les clé maître qui serait supprimées, mais ne les supprime pas.
        -v mode verbeux

        update_princ_encryption [-f] [-n] [-v] [princ-pattern] Met à jours les enregistrements de principal (ou ceux qui matchent le princ-pattern) pour re-chiffrer le clés en utilisant la clé maître active, si elle sont chiffrée en utilisant une autre version, et donne un compteur du nombre de principaux mis à jours. -f ne demande pas confirmation. -v traite chaque principal listé. -n simule l'action.
^
20 juin 2014

htmlpdflatexmanmd




kdc.conf

kdc.conf

Fichier de configuration des services Kerberos

   Ce fichier est un supplément à krb5.conf et est utilisé uniquement dans les KDC. Normalement, kdc.conf se trouve dans le répertoire d'état du KDC, LOCALSTATEDIR/krb5kdc mais peut être changé dans la variable KRB5_KDC_PROFILE. Noter qu'il faut redémarrer les services kdc pour prendre en comptes les changements.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

  

Sections

   Le fichier kdc.conf peut contenir les sections suivantes:

[kdcdefaults] Valeurs par défaut pour le fonctionnement du KDC
[realms] Configuration et paramètres de base de données spécifique au domaine
[dbdefaults] Paramètres de base de données par défaut
[dbmodules] Paramètres par base de données
[logging] Contrôle les logs des services Kerberos

[kdcdefaults]

   À une exception près, les relations dans cette section spécifient les valeur par défaut pour les variable du domaine à utiliser si la sous-section [realms] ne contient par de relation pour le tag.

host_based_services
kdc_ports
kdc_tcp_ports
no_host_referral
restrict_anonymous_to_tgt
kdc_max_dgram_reply_size Spécifie la taille de packet maximum que peut être envoyé en UDP. Défaut: 4096

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section où les relations définissent les paramètres du KDC pour ce domaine. L'exemple suivant montre comment définir un paramètre pour le domaine ATHENA.MIT.EDU:


[realms]
    ATHENA.MIT.EDU = {
        max_renewable_life = 7d 0h 0m 0s
    }

acl_file (chaîne). Emplacement du fichier d'acl que kadmind utilise pour déterminer quels principaux ont un accès privilégié à la base. Défaut: LOCALSTATEDIR/krb5kdc.acl
database_module (chaîne). Indique le nom de la section de configuration sous [dbmodules] pour les paramètres spécifiques à la base utilisé par la librairie. Défaut: le nom du domaine.
database_name (chaîne, déprécié) Spécifie l'emplacement de la base Kerberos pour ce domaine, si DB2 est utilisé et que la section de configuration [dbmodules] ne spécifie par un nom de base. Défaut: LOCASTATEDIR/krb5kdc/principal
default_principal_expiration (chaîne, temps absolu). Spécifie le temps d'expiration par défaut des principaux créés dans ce domaine. Défaut: 0 qui signifie aucune expiration.
default_principal_flags (Chaîne) Spécifie les attributs par défaut des principaux crées dans ce domaine. Le format est une liste de flags séparés par une ",", avec un "+" avant chaque flag à ajouter, et "-" à enlever. Défaut: les flag suivant sont permis postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, et service. Les flags possibles sont:

        allow-tickets Le KDC va fournir de tickets pour ce principal
        dup-skey permet au principal d'obtenir une clé de session pour un autre utilisateur.
        forwardable Permet au principal d'obtenir des tickets forwardable
        hwauth Le principal doit utiliser un périphérique hardware pour la pré-authentification
        no-auth-data-required Empêche les données PAC et AD-SIGNEDPATH d'être ajoutés au ticket de service pour le principal
        ok-as-delegate Indique au client que les accréditifs peuvent et devraient être délégués en s'authentifiant auprès du service
        ok-to-auth-as-delegate Permet au principal d'utiliser des tickets S4USelf
        postdateable Permet au principal d'obtenir des tickets post-datés.
        preauth Le principal doit de pré-authentifier auprès du KDC avant de recevoir un ticket. Pour un principal de service, cela signifie que les tickets de service pour ce principal seront uniquement fournis aux clients avec un TGT qui a le bit preauthenticated mis.
        proxiable Permet au principal d'obtenir des tickets proxy
        pwchange Force le changement de mot de passe pour ce principal
        pwservice Marque ce principal comme service de changement de mot de passe. Devrait être utilisé uniquement dans des cas spéciaux, par exemple, si le mot de passe de l'utilisateur a expiré, alors l'utilisateur doit obtient des tickets pour ce principal sans passer par une authentification normal par mot de passe pour pouvoir changer le mot de passe.
        renewable Permet au principal d'obtenir des tickets renouvelable.
        service Permet au KDC de fournir des tickets de service pour ce principal
        tgt-based Permet au principal d'obtenir des tickets basés sur un TGT au lieu de répéter le process d'authentification utilisé pour obtenir ce TGT.

dict_file (chaîne) Emplacement du fichier dictionnaire contenant les chaînes non permises pour un mot de passe.
host_based_services (liste séparée par des espaces ou des virgules) Liste des services qui vont obtenir un traitement des référants basés sur l'hôte même si le principal du serveur n'est pas marqué comme basé sur l'hôte par le client.
iprop_enable (bool) Spécifie si la propagation incrémentale de la base est permise. Défaut: false.
iprop_master_ulogsize (entier) Spécifie le nombre max d'entrées de log à retenir pour la propagation incrémentale. max: 2500, défaut: 1000
iprop_slave_poll (chaîne de temps delta) Spécifie la fréquence des mises à jours les esclaves auprès du maître. Défaut: 2m (minutes)
iprop_port (numéro de port) Spécifie le numéro de port à utiliser pour la propagation incrémentale. Requis dans les configuration des maître et esclaves.
iprop_resync_timeout (chaîne de temps delta). Spécifie le temps d'attente pour une propagation complète. Optionnel et est utilisé par les esclaves uniquement. Défaut: 5m.
iprop_logfile (Nom de fichier) Spécifie où se situe le fichier de log des mises à jours. Par défaut, utilise database_name.ulog
kadmind_port (numéro de port) Port d'écoute du service kadmind. Défaut: 749
key_stash_file (chaîne) Spécifie l'emplacement du fichier stash. Défaut: LOCALSTATEDIR/krb5kdc/.k5.REALM.
kdc_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes UDP. Défaut: 88,750
kdc_tcp_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes TCP (Défaut: 88).
master_key_name (chaîne) Spécifie le nom du principal associé avec la clé maître. Défaut: K/M
master_key_type (Chaîne de type de clé) Spécifie le type de clé maître. Défaut: aes256-cts-hmac-sha1-96.
max_life (chaîne de temps) Spécifie le temps maximum pour lequel un ticket peut être valide dans le domaine. Défaut: 24heures.
max_renewable_life (chaîne de temps) Spécifie le temps maximum durant lequel un ticket valide peut être renouvelé dans ce domaine. Défaut: 0
no_host_referral (liste séparée par des espaces ou des virgules) Liste
des_crc_session_supported (bool) À true, le KDC assume que les principaux de service supportent des-cbc-crc pour les type de clé de session. Défaut: true.
reject_bad_transit (bool) À true, le KDC vérifie la liste des domaines de transit pour les tickets inter-domaines avec le chemin de transit calculé depuis les noms des domaines et la section capaths de son fichier krb5.conf; si le chemin dans le ticket contient un domaine qui n'est pas dans le chemin calculé, le ticket ne sera pas délivré. Si cette valeur est à false, de tels tickets seront toujours émis. si le flag disable-transited-check est mis dans la requête entrante, cette vérification n'est pas effectuée. L'option reject_bad_transit force de telles requête à être toujours rejetées. Défaut: true
restrict_anonymous_to_tgt (bool) À true, le KDC rejète les demandes de tickets pour des principaux anonymes au principaux de service autre que le domaine du TGS. Cette option permet les PKINIT anonymes pour les tickets FAST sans autoriser l'authentification anonyme aux services. Défaut: false.
supported_enctypes (liste de key:salt) Spécifie les combinaisons key/salt par défaut des principaux pour ce domaine. Tout principal créé via kadmin aura des clé de ce type. Défaut: aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal.

[dbdefaults]

   Cette section spécifie les valeur par défaut pour certains paramètres de base, à utiliser si la sous-section dbmodules ne contient pas de relation pour ce tag.

ldap_kerberos_container_dn
ldap_kdc_dn
ldap_kadmind_dn
ldap_service_password_file
ldap_servers
ldap_conns_per_server

[dbmodules]

   Cette section contient des paramètres utilisés par les bases du KDC et les modules. Chaque tag dans cette section est le nom d'un domaine Kerberos ou un nom de section spécifié par le paramètre database_module du domaine. L'exemple suivant montre comment définir un paramètre de base pour le domaine ATHENA.MIT.EDU:

[dbmodules]
    ATHENA.MIT.EDU = {
        disable_last_success = true
    }

database_name Ce tag spécifique à db2 indique l'emplacement de la base dans le système de fichier. Défaut: LOCALSTATEDIR/krb5kdc/principal
db_library Indique le nom du module de base à charger. peut être db2 ou kldap
disable_last_success À true, supprime les mises à jours KDC du champ "last successful authentication" des entrées de principal nécessitant une pré-authentification. Positionner ce flag peut améliorer les performances. (Les entrées de principal qui ne nécessitent par de pré-authentification ne mettent jamais ce champ)
disable_lockout À true, supprime les champs "last failed authentication" et "failed password attempts" des entrées de principal nécessitant une pré-authentification. peut améliorer les performances.
ldap_conns_per_server Indique le nombre de connexios à maintenir par serveur LDAP
ldap_kadmind_dn Indique le bind DN par défaut pour le service kadmind. Cet objet devrait avoir les droits de lire et écrire dans la base Kerberos dans la base LDAP.
ldap_kdc_dn Indique le bind DN par défaut pour le service krb5kdc. Cet objet devrait avoir les droits de lire dans la base Kerberos dans la base LDAP et d'écrire les données sauf si disable_lockout et disable_last_success sont à true.
ldap_kerberos_container_dn Indique le DN de l'objet conteneur où les objets de domaine sont localisés.
ldap_servers Liste les serveur LDAP à contacter.
ldap_service_password_file Indique le fichier contenant les mots de passe stashed (créés par kdb5_ldap_util stashsrvpw) pour les objets ldap_kadmind_dn et ldap_kdc_dn.
db_module_dir contrôle l'emplacement les modules de base de données. devrait être un chemin absolu. Ce tag pour être spécifié directement dans la section dbmodules.

[logging]

   Cette section indique comment krb5kdc et kadmind effectuent les logs. Les clés dans cette section sont les noms des services, qui peut être un parmi:

admin_server Spécifie comment kadmind effectue les logs
kdc Spécifie comment krb5kdc effectue les logs
default Spécifie comment les 2 services effectuent les logs.

   Les valeurs sont sous la forme suivante:

FILE=filename ou FILE:filename Log les messages dans le fichier spécifié. si la 1ère forme est utilisée, le fichier est écrasé.
STDERR Log les message sur stderr
CONSOLE Log les messages dans la console
DEVICE=‹devicename› Log les messages dans le périphérique spécifié
SYSLOG[:severity[:facility]] Los les messages dans syslog

Dans l'exemple suivant, les messages du KDC vont dans la console et dans syslog. Les messages de kadmind vont dans /var/adm/kadmin.log et dans le périphérique /dev/tty04
[logging]
    kdc = CONSOLE
    kdc = SYSLOG:INFO:DAEMON
    admin_server = FILE:/var/adm/kadmin.log
    admin_server = DEVICE=/dev/tty04

[otp]

   Chaque sous-section de [opt] est le nom du type de token OTP. Les tags dans la sous-section définis la configuration requise pour forwarder une requête OTP au serveur radius. Pour chaque type de token, les tags suivants peuvent être spécifiés:

server Serveur où envoyer les requêtes RADIUS. Peut être un nom d'hôte et un port optionnel, une adresse IP ou un socket UNIX. Défaut LOCALSTATEDIR/krb5kdc/‹name›.socket
secret Indique le fichier qui peut être relatif à LOCALSTATEDIR/krb5kdc contenant le secret utilisé pour chiffré les packets RADIUS. Le secret devrait apparaître sur la première ligne du fichier. Si server indique un socket unix, ce tag est optionnel.
timeout Entier qui spécifie le temps en secondes durant lequel de KDC devrait attendre pour contacter le serveur RADIUS. Ce tag est le temps total entre toutes les tentatives et devrait être inférieur au temps de validité de l'OTP. Défaut: 5 secondes
retries Nombre de re-tentatives auprès du serveur RADIUS. Défaut: 3
strip_realm À true, le principal sans le domaine sera passé au serveur RADIUS, sinon le domaine est inclus. Défaut: true.

Dans l'exemple suivant, les requêtes sont envoyées à un serveur distant via UDP:
[otp]
    MyRemoteTokenType = {
        server = radius.mydomain.com:1812
        secret = SEmfiajf42$
        timeout = 15
        retries = 5
        strip_realm = true
    }

Un token par défaut implicite nommé DEFAULT est définis pour les type de token non spécifiés. Sa configuration est décrite ci-dessous.
[otp]
    DEFAULT = {
        strip_realm = false
    }

Options PKINIT

   Cet valeurs peuvent être spécifiées dans [kdcdefaults] comme valeur par défaut, ou dans une sous-section de [realms]. Noter qu'une valeur spécifique à un domaine remplace, n'ajoute pas, une spécification kdcdefaults. L'ordre de recherche est:

1. sous-section de [realms]:
    [realms]
        EXAMPLE.COM = {
            pkinit_anchors = FILE:/usr/local/example.com.crt
        }

2. Valeur générique dans la section [kdcdefaults]:
    [kdcdefaults]
        pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_allow_upn Spécifie que le KDC est prêt à accepter les certificats client avec un SAN UPN. Défaut: false. Sans cette option, le KDC accepte uniquement les certificats avec id-pkinit-san comme définis dans la rfc4556. Il n'y a actuellement aucune option pour désactiver la vérification SAN dans le KDC.
pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le KDC est prêt à accepter dans les certificats client. Les valeurs reconnues sont:

        kpClientAuth C'est la valeur par défaut et spécifie que les certificats client doivent avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
        scLogin Les certificats client avec id-ms-sc-logon seront acceptés
        none Les certificats client ne seront pas vérifiés pour un EKU acceptable.

pkinit_identity Spécifie l'emplacement des information d'identité X.509 du KDC. Cette option est requise si pkinit est supportée par le KDC
pkinit_kdc_ocsp Spécifie l'emplacement de l'OCSP du KDC
pkinit_mapping_file Spécifie le nom du fichier de mappage d'acl pkinit. Ce fichier map les principaux aux certificats qu'ils utilisent.
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le KDC pour compléter le chaîne. Peut être spécifiée plusieurs fois
pkinit_revoke Spécifie l'emplacement de la CRL. Peut être spécifié plusieurs fois
pkinit_require_crl_checking Spécifie que la vérification de révocation est requise.

Types de chiffrement

des-cbc-crc DES cbc mode avec CRC-32 (weak)
des-cbc-md4 DES cbc mode avec RSA-MD4 (weak)
des-cbc-md5 DES cbc mode avec RSA-MD5 (weak)
des-cbc-raw DES cbc mode raw (weak)
des3-cbc-raw Triple DES cbc mode raw (weak)
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd Triple DES cbc mode avec HMAC/sha1
des-hmac-sha1 DES avec HMAC/sha1 (weak)
aes256-cts-hmac-sha1-96 aes256-cts AES-256 CTS mode avec 96-bit SHA-1 HMAC
aes128-cts-hmac-sha1-96 aes128-cts AES-128 CTS mode avec 96-bit SHA-1 HMAC
arcfour-hmac rc4-hmac arcfour-hmac-md5 RC4 avec HMAC/MD5
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp Exportable RC4 avec HMAC/MD5 (weak)
camellia256-cts-cmac camellia256-cts Camellia-256 CTS mode avec CMAC
camellia128-cts-cmac camellia128-cts Camellia-128 CTS mode avec CMAC
des Fammille DES: des-cbc-crc, des-cbc-md5, and des-cbc-md4 (weak)
des3 Famille triple DES: des3-cbc-sha1
aes Famille AES: aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96
rc4 Famille RC4: arcfour-hmac
camellia Famille Camellia: camellia256-cts-cmac and camellia128-cts-cmac

   La chaîne DEFAULT peut être utilisé pour les type de jeu par défaut pour les variables en question. Les types ou familles peuvent être supprimées de la liste courante en les préfixant avec un "-". Les types ou familles peuvent être préfixés avec un "+" pour la symétrie; il a la même signification que simplement lister le type ou la famille. Par exemple, DEFAULT -des sera le jeu de chiffrement par défaut avec les types DES supprimés, et des3 DEFAULT sera le jeu de chiffrement par défaut avec triple DES supprimé.

   Alors que aes128-cts et aes256-cts sont supportés pour toutes les opérations Kerberos, ils ne sont pas supportés par d'anciennes versions de l'implémentation GSS-API.

Listes de keysalt

   Les clés Kerberos pour les utilisateurs sont généralement dérivés des mots de passe. Les commandes et les paramètres de configuration Kerberos qui affectent la génération de clés prennent la liste des paires enctype-salttype, appelés "liste keysalt". Chaque paire keysalt est un nom de type de chiffrement suivi par un nom de salttype, dans le format enc:salt. Par exemple:

  kadmin -e aes256-cts:normal,aes128-cts:normal

  va lancer kadmin pour qu'il génère par défaut des clé dérivés pour les types de chiffrement aes256-cts et aes128-cts, en utilisant un salt normal.

   Pour s'assurer que les gens qui utilisent le même mot de passe n'aient pas la même clé, Kerberos 5 incorpore plus d'informations dans la clé en utilisant un salt. Les types de salt supportés sont les suivant:

normal Défaut pour Kerberos v5
v4 Utilisé uniquement par Kerberos v4 (pas de salt)
norealm Idem au défaut, sans utiliser d'information de domaine.
onlyrealm Utilise seulement les information de domaine comme salt
afs3 AFS version 3, utilisé uniquement pour la compatibilité avec Kerberos v4
special Génère un salt aléatoire.

Exemple

Exemple de fichier de configuration kdc.conf
[kdcdefaults]
    kdc_ports = 88
    
[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4
        database_module = openldap_ldapconf
    }
    
[logging]
    kdc = FILE:/usr/local/var/krb5kdc/kdc.log
    admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
    
[dbdefaults]
    ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
    
[dbmodules]
    openldap_ldapconf = {
        db_library = kldap
        disable_last_success = true
        ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_service_password_file = /etc/kerberos/service.keyfile
        ldap_servers = ldaps://kerberos.mit.edu
        ldap_conns_per_server = 5
    }
^
26 janvier 2014

htmlpdflatexmanmd




kded

kded

Manipuler les updates de base Sycoca

   kded est responsable de la création de fichier sycoca, par ex, le cache binaire des services, servicetypes, mimetypes pour un utilisateur particulier.

  Il monitor les répertoires contenant les fichiers .desktop. Quand un fichier est ajouté/supprimé, il attend 5 secondes (en cas d'une série d'updates), et lance kbuildsycoca4 pour mettre à jour le sycoca.

  Il vérifie les fichiers de mise à jour installés, par ex. les fichiers .upd utilisés pour mettre à jour les fichiers de configuration des utilisateurs quand les formats de ces fichiers de configuration changent. kconf_update est lancé pour faire ces mises à jours.

   Quand le nom d'hôte change, il va faire le nécessaire dans l'environnement KDE et X-server pour permettre aux opérations de continuer correctement, en lançant kdontchangethehostname pour faire les changements.

  Ces tâches sont aussi effectuées au lancement de KDE pour s'assurer que la configuration de l'utilisateur est à jours.

  Il est aussi responsable pour lancer les modules kde à la demande et les modules init KDE comme:

        Konqueror Browser Preloader Réduit le temps de chargement de konqueror
        Directory Watcher monitor les changements dans les répertoires
        Hardware Detection Fournis une interface utilisateur pour les évènements hardware
        SSL Certificate Policy Fournis les certificats SSL configurés par l'utilisateur aux applications
        Network Proxy Configuration Configuration de proxy automatique
        Password Caching Cache de mot de passe temporaire
        Sound Policy Fournis des stratégies de système sonore aux applications
        Favicons Stocke les icônes des sites web
        Display Management Gère les affichages et sorties vidéo
        Cookie jar Stocke les cookies réseau
        Network Watcher Conserve les traces réseau et liste les répertoires du réseau network:/ KIO slave
        Subversion Module Fournis diverses actions de subversion au filemanager et autres logiciels
        Network Statut Gère le statut des interfaces réseau et fournis des notifications pour les applications utilisant le réseau
        Write Daemon Regarde les message des utilisateurs locaux envoyés par write et wall
        Notification area watcher Garde trace des applications qui veulent utiliser D-Bus
        KMixD Service Mixer KmixD
        Systemtray daemon Converve les traces des applications qui utilisent le system tray basé sur DBus
        Keyboard Daemon Conserve les trace des changements de clavier (nouveau clavier, layout changé)
        Remote URL Change Notifier Fournis les notifications de changement pour les dossiers réseau
        Activity Manager Backend du gestionnaire d'activité Nepomuk
        Display Management change monitor Notifie comment l'affichage a été tourné
        Free Space Notifier Alerne lorsqu'il n'y a plus d'espace disque dans le home
        Removable Device Automounter Monte les périphérique automatiquement si nécessaire
        Nepomuk Search Module Module helper pour KIO pour s'assurer des mises à jours automatiques des listings de recherche Nepomuk
        Power Management Gestion et notification des CPU, affichage et batterie
        K Remote Control Daemon Gère les commandes de contrôle distants reçus
        Status Notifier Manager Gère les services qui fournissent le statut notifier des interfaces utilisateurs
        DNS-SD Service Discovery Monitor Monitor le réseau pour les services DNS-SD
        Drive Ejector Démonte automatiquement les lecteurs quand leur bouton d'éjection est pressé
        Time zone Fournis l'accès aux timezones du système pour les applications
        Input Actions Service d'action d'entrée effectuant des actions configurés sur des touches pressées

   Les modules init peuvent être activés/désactivés en utilisant systemsettings

Options génériques

--help-all Affiche toutes les options
--check Vérifier la base de données Sycoca une fois seulement

Options QT

--display displayname Spécifier l'affichage du serveur X
--session ‹sessionId› Spécifier l'application à restaurer
--cmap Amène l'application à installer une palette de couleurs privée sur un affichage sur 8 bits
--ncols ‹count› Limite le nombre de couleurs allouées dans le cube de couleurs pour un affichage sur 8 bits, si l'application utilise les spécifications de couleurs QApplication::ManyColor
--nograb Demande à Qt de ne jamais capturer la souris ou le clavier
--dograp Annule l'effet de --nograb
--sync Passe en mode synchrone
--fn, --font ‹fontname› Définit la police de l'application
--bg, --background ‹color› Définit la couleur de fond par défaut et une palette pour l'application (les ombres claires et sombres sont calculées)
--fg, --foreground ‹color› Définit la couleur de premier plan par défaut
--btn, --button ‹color› Définit la couleur par défaut des boutons
--name ‹name› Définit le nom de l'application
--title ‹title› Définit le titre de l'application (légende)
--testability charger l'infrastructure de testabilité
--visual TrueColor Force l'application à utiliser un affichage en couleurs réelles sur un affichage sur 8 bits
--inputstyle ‹inputstyle› Définit le style d'entrée XIM (X Input Method). Les valeurs possibles sont « onthespot », « overthespot », « offthespot » et « root »
--im ‹XIM server› Définir le serveur XIM
--noxim Désactiver XIM
--reverse Reflète la disposition entière des composants graphiques (« widgets »)
--stylesheet ‹file.qss› Applique la feuille de style Qt aux composants graphiques de l'application
--graphicssystem ‹system› Utilise un système graphique différent au lieu du système par défaut, les options sont raster et opengl (expérimental)

Options de KDE

--caption ‹caption› Utiliser caption comme nom dans la barre de titre
--icon ‹icon› Utiliser icon comme icône de l'application
--config ‹filename› Utiliser un fichier de configuration auxiliaire
--nocrashhandler Désactiver le gestionnaire de pannes.
--waitforwm Attend un gestionnaire de fenêtres compatible avec WM_NET
--style ‹style› définit le style de l'interface graphique de l'application
--geometry ‹geometry› définit la géométrie de client du composant graphique (widget) principal
--nofork Ne pas exécuter en arrière-plan.
^
09 février 2014

htmlpdflatexmanmd




kdeinit

kdeinit

Lanceur de processus KDE

   kdeinit4 est un lanceur de programme similaire à init utilisé pour booter UNIX. Il exécute des programmes KDE et les kdeinit loadable modules (KLMs). Utiliser kdeinit lance une application 2 fois plus rapidement et réduit la consommation de mémoire. Il est lié avec toutes les librairies que les applications ont besoin, ce qui accélère le chargement.

  Désavantages:

  Le nom de processus des applications qui sont lancés par kdeinit4 et "kdeinit4". Des applications comme killall vont seulement voir kdeinit4 comme nom de processus. Utiliser kdekillall à la place.

OPTIONS

--no-fork Ne pas forker, ne quitte pas tant que le programme n'est pas terminé
--no-kded Ne lance pas kded
--suicide Se termine quand plus aucune application KDE ne tourne
+program Lance le programme et capture les requêtes
-program Lance le programme et sans capturer les requêtes

Fichiers

/tmp/kde-$USER/kdeinit4_$INSTANCE Utilisé par kdeinit

Variables d'environnement

HOME Répertoire personnel de l'utilisateur
KDE_HOME_READONLY Spécifie si le répertoire personnel est en lecture seule
KDE_IS_PRELINKED indique que les programmes KDE sont pre-linked
KDE_DISPLAY Indique à kdeinit4 qu'il tourne sous un environnement de bureau KDE
^
30 juin 2014

htmlpdflatexmanmd




kdestroy

kdestroy

Supprimer les caches d'accréditifs

   kdestroy est un utilitaire pour supprimer des tickets d'autorisation Kerberos actifs en supprimant les caches d'accréditifs. Si le cache n'est pas spécifié, le cache par défaut est supprimé.

OPTIONS

-A Supprime tous les caches dans la collection, si une collection de cache est disponible
-q mode silencieux
-c cache_name Supprime le cache spécifié

Notes

   Le cache d'accréditifs par défaut peut varier entre les systèmes. Si la variable d'environnement KRB5CCNAME est définie, sa valeur est utilisée comme cache de tickets par défaut.

  Il est recommandé de placer la commande kdestroy dans le fichier .logout pour supprimer tous les tickets à la deconnexion.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
26 janvier 2014

htmlpdflatexmanmd




kdm

kdm

Gestionnaire d'affichage de KDE

OPTIONS

-daemon Daemonise même quand il est démarré par init
-nodaemon Ne daemonise pas même s'il est lancé depuis la ligne de commande
-config file Utilise le fichier de configuration spécifié
-xrm res Écrase la ressource spécifié
-error file Utilise le fichier le log spécifié
-debug num:

        0x1 core log
        0x2 config reader log
        0x4 greeter log
        0x8 IPC log
        0x10 session sub-daemon post-fork delay
        0x20 config reader post-start delay
        0x40 greeter post-start delay
        0x80 don't use syslog
        0x100 core Xauth log
        0x400 valgrind config reader and greeter
        0x800 strace config reader and greeter

Fichiers

/etc/kde4/kdm/backgroundrc Fichiers de configuration du fond
/etc/kde4/kdm/kdm.options Options de configuration de kdm
/etc/kde4/kdm/kdmrc Fichier de configuration de kdm
/etc/kde4/kdm/Xaccess Fichier de contrôle d'accès pour les connections XDCMP
/etc/kde4/kdm/Xreset Script lancé en root quand la session est terminée
/etc/kde4/kdm/Xsession Script lancé en user après le login
/etc/kde4/kdm/Xsetup Script lancé en root avant que le login apparaisse
/etc/kde4/kdm/Xstartup Script lancé en root avant que le session démarre
/etc/kde4/kdm/Xwilling La sortie de ce script est affiché dans la fenêtre
^
26 janvier 2014

htmlpdflatexmanmd




kdm.options

kdm.options

Options de configuration pour le gestionnaire d'affichage X. Il contient un jeu de flags qui déterminent le fonctionnement de kdm.

OPTIONS

[no-]ignore-nologin N'affiche pas le contenu de /etc/nologin en utilisant xmessage
[no-]restart-in-upgrade En cas d'upgrade, le service kdm est stoppé puis redémmarré
^
01 janvier 2014

htmlpdflatexmanmd




kdmctl

kdmctl

Contrôle distant kdm

   kdmctl utilise les socket UNIX. Il y'a 2 types de sockets: global (dmctl) et par affichage (dmctl-‹display›). Le dossier global appartient à root, les dossier associés à une affichage appartiennent à un utilisateur. Le répertoire dans lequel les sockets sont localisés est déterminé comme suit:

  - l'option -s est examiné

  - $DM_CONTROL est examiné

  - FifoDir est recherché

  - /var/run/xdmctl et /var/run sont tentés.

   Si $DISPLAY est définis et -g non définis, le socket spécifique est utilisé, sinon utilise le global.

OPTIONS

-g, --global Utilise le socket global
-d, -display Écrase $DISPLAY
-s, -socket Écrase $DM_CONTROL
-c, --config Utilise un fichier de config kdm alternatif

Commandes Globales

login display (now|schedule) user password [session_arguments] Authentifie un utilisateur sur un affichage particulier. si now est spécifié, toute session déjà démarrée sera terminée, sinon l'authentification se fera à la fin de la session.
resume Force un retour depuis le mode console, même si des connexions TTY sont encore actives.
manage display [display_class [auth_name auth_data]] Débute la gestion de l'affichage distant désigné.display_class est utilisé pour la correspondance de configuration. auth_name et auth_data doivent être spécifiés si l'affichage requiert une authentification X. Le format est le même que celui des 2 ième et 3 ième colonnes de la sortie de la commande xauth list.
unmanage display Arrête la gestion de l'affichage distant désigné.

Commandes par affichage

lock L'affichage est marqué comme verrouillé
unlock Annule l'effet de la commande lock et réactive la reconnexion automatique.
suicide L'arrêt de la session en cours est forcé.

Commandes par tous les sockets

caps Retourne une liste des capacités de cette socket.

        kdm identifie kdm dans le cas où un autre gestionnaire de connexion implémenterait aussi ce protocole
        list, lock, suicide, login, resume, manage Les commandes respectives sont disponibles
        bootoptions Pour l'arrêt, la commande listbootoptions et le = de shutdown sont gérés
        shutdown ‹list› shutdown est disponible et autorisé pour les utilisateurs listés
        nuke ‹list› L'arrêt forcé du système peut être effectué par les utilisateurs listés.
        nuke L'arrêt forcé du système peut être effectué par tout le monde
        reserve ‹nombre› Des affichages réservés sont configurés, et nombre sont disponibles en ce moment

list [all | alllocal] Retourne la liste des sessions en cours. alllocal liste également les sessions passives. Le format est ‹display›,‹vt›,‹user›,‹session type›,‹flag›. (Flag: * - appartient au socket effectuant la requête, ! - sessions ne pouvant pas être terminées par le socket effectuant la requête, t - les session TTY)
reserve Démarre un nouvel écran de connexion.
activate (vt|affichage) Change pour un VT (terminal virtuel) particulier.
listbootoptions Liste les options de démarrage disponibles.
shutdown (reboot | halt) [=bootchoice] (ask|trynow|forcenow|schedule|start (-1|end (force|forcemy|cancel)))) Demande un arrêt électrique ou un redémarrage du système.
shutdown cancel [local|global] Annule un arrêt programmé.
shutdown status Retourne une liste d'information à propos des procédures d'arrêt.
^
01 janvier 2014

htmlpdflatexmanmd




kdmrc

kdmrc

Script de configuration pour kdm

   Les sections sont dénotées [Nom de la Section]

  Les sections avec des paramètres spécifiques à un affichage ont la syntaxe formelle [X- ‹host› [ : ‹number› [ _ class ] ] - ‹subsection› ]

  Toutes les sections avec le même sub-section constituent une classe de section.

  La section depuis laquelle la configuration est extraite est déterminée par ces règles:

  - Une correspondance exacte est prioritaire sur une correspondance partielle pour la partie hôte, qui à son tour est prioritaire sur un caractère joker.

  - La priorité décroît de gauche à droite pour des correspondances exactes identiques

  Exemple : le nom d'affichage « myhost.foo:0 », classe «dpy»

        [X-myhost.foo:0_dpy] est prioritaire sur
        [X-myhost.foo:0_*] identique à [X-myhost.foo:0], est prioritaire sur
        [X-myhost.foo:*_dpy] est prioritaire sur
        [X-myhost.foo:*_*] (identique à [X-myhost.foo]) est prioritaire sur
        [X-.foo:*_*] (identique à [X-.foo]) est prioritaire sur
        [X-+:0_dpy] est prioritaire sur
        [X-*:0_dpy] est prioritaire sur
        [X-*:0_*] (identique à [X-*:0]) est prioritaire sur
        [X-*:*_*] (identique à [X-*]).
        - Ces sections ne correspondent pas à cet affichage :
        [X-hishost], [X-myhost.foo:0_dec], [X-*:1], [X-:*] -

   Les sections communes sont [X-*] (tous les affichages), [X-:*] (tous les affichages locaux) et [X-:0] (le premier affichage local).

  Les caractères spéciaux sont échappés: espaces de début et de fin(\s), tabulation (\t), fin de ligne (\n), retour chariot (\r) et '\' (\\)

Section General

ConfigVersion Existe uniquement pour faire des mises à jour automatiques propre.
StaticServers Liste d'afficheurs (X-Servers) gérés par kdm en permanence (défaut: 0)
ReserveServers Liste d'affichages à la demande (défaut: vide)
ServerVTs Liste des terminaux virtuels à allouer aux X-Servers (défaut: vide)
ConsoleTTYs Lorsque kdm bascule en mode console, il commence à surveiller toutes les lignes TTY listées ici (sans /dev/ au début). Si aucune d'elle n'est active pendant un certain temps, kdm bascule à nouveau vers le login X. (défaut: vide)
PidFile Nom du fichier pid pour le processus principale kdm. (défaut: vide )
LockPidFile Contrôle si kdm utilise le verrouillage par fichier pour éviter que de multiples gestionnaires soient lancés. (défaut: true )
AuthDir Dossier où sont stockés les fichiers d'autorisation pour X-Server lors de l'initialisation de la session. kdm s'attend à ce que le système supprime les fichiers périmés de ce dossier au redémarrage. (défaut: /var/run/xauth)
AutoRescan (bool) contrôle si kdm relit automatiquement sa config en cas de changement. (défaut: vide)
RandomDevice Fichier de génération des nombres aléatoire. Si vide, utilise le système d'entropy du système (défaut: vide)
FifoDir Dossier dans lequel les sockets de commandes doivent être créés (défaut: /var/run/xdmctl)
FifoGroup Le groupe auquel le socket de commande global doit appartenir.
GreeterUID L'utilisateur propriétaire du processus de l'écran de connexion. (défaut: root)
DataDir Dossier dans lequel kdm doit enregistrer des données de travail persistantes (défaut: /var/lib/kdm)
DmrcDir Dossier dans lequel kdm doit enregistrer les fichiers .drmc. Nécessaire que les les homes ne peuvent être lus avant connexion.

Section Xdmcp

Enable kdm doit écouter les requêtes Xdmcp entrantes
Port Port d'écoute udp (défaut: 177)
KeyFile Le style d'authentification XDMCP XDM-AUTHENTICATION-1 requiert une clé privée. Spécifie le fichier contenant cette clé.
Xaccess Pour se prémunir des services non autorisés XDMCP et pour permettre la transmission de requêtes indirectes XDMCP, ce fichier contient une base de données de noms d'hôtes qui sont autorisés à accéder directement à cette machine, ou contient une liste d'hôtes dont les requêtes doivent être transmises. (défaut: ${kde_confdir}/kdm/Xaccess )
ChoiceTimeout Secondes d'attente de la réponse (défaut: 15)
RemoveDomainname supprime la portion domaine s'il est identique au nom de domaine de l'hôte. (défaut: true)
SourceAddress IP de la connexion entrante
Willing Spécifie un programme en cours d'exécution en tant que root lorsqu'une requête xdcmp est reçue

Section Shutdown

HaltCmd Commande à lancer pour arrêter le système (ex: /sbin/shutdown -h now)
RebootCmd Commande à lancer pour redémarrer le système (ex: /sbin/shutdown -r now)
AllowFifo Spécifie si on peut arrêter le système avec le socket de commande globale (défaut: false)
BootManager Gestionnaire de démarrage que kdm doit utiliser pour proposer des options de démarrage dans la boite de dialogue arrêt (none,Grub,Grub2,Lilo)

Section X-*-Core

OpenDelay Délai en seconde entre les tentative de connexion. défaut: 15
OpenTimeout délai en seconde après qui OpenRepeat soit atteint avant de une nouvelle tentative de connexion. défaut: 120
OpenRepeat Nombre de tentative. (défaut: 5)
StartAttempts Nombre de tentative de démarrer un afficheur étranger, listé dans StaticServers avant d'abandonner et le désactiver. (défaut: 4)
ServerAttempts Nombre de tentative de démarrer le X-Server local. (défaut: 1)
ServerTimeout Délai en seconde d'attente pour le démarrage d'un X-Server local. (défaut: 30)
ServerCmd Ligne de commande pour démarrer le X-Server, sans afficher le nombre et les spécification du VT. (défaut ex: /usr/X11R6/bin/X)
ServerArgsLocal Arguments additionnels pour les X-Servers pour les sessions locales.
ServerArgsRemote Arguments additionnels pour les X-Servers pour les sessions distantes.
ServerVT Le VT sur lequel le X-Server doit s'exécuter. Utiliser plutôt ServerVTs. 50 pour l'assignation automatique, 61 pour éviter l'assignation)
ServerTTY Pour les OS ne prenant pas en charge les VT. lorsque que kdm passe en mode console, is surveille les activités de cette ligne TTY (dans /dev/) Si la ligne n'est pas utilisée pendant quelques temps, kdm repasse au login X.
ServerUID L'utilisateur que le serveur X doit connecter. (vide connecte en root)
PingInterval Délai en minutes entre les pings pour la détection des afficheurs déconnectés
PingTimeout Délai en minutes max à attendre la réponse à la requête du terminal, et de déclarer la session terminée.
TerminateServer Permet à kdm de redémarrer X-Server local après avoir quitté la session au lieu de reconfigurer (défaut; false)
Authorize Contrôle si kdm génère et utilise une autorisation pour les connexions locales au X-Server. (défaut: true)
AuthNames à true, utilise le mécanisme d'autorisation listé: MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1, SUN-DES-1, MIT-KERBEROS-5 (défaut: DEF_AUTH_NAME)
ResetForAuth Pour les ancien X-Servers, kdm envoie SIGHUP pour provoquer une re-configuration pour qu'il relise la nouvelle autorisation
AuthFile Ce fichier est utilisé pour communiquer les données d'autorisation depuis kdm vers X-Server, en utilisant l'option -auth de la ligne de commande du X-Server. doit être dans un dossier protégé contre les écritures
Resources Fichier à charger par xrdb en tant que base de données dans la fenêtre mère de l'écran 0 de l'afficheur. Nécessaire uniquement si la configuration du programme a besoin de certaines ressources du serveur X.
Xrdb Le programme xrdb à utiliser. (défaut: ${x_bindir}/xrdb)
Setup Programme à exécuter en root avant d'afficher l'écran de connexion. (ex: Xsetup)
Startup Programme à exécuter en root après que le processus d'authentification de l'utilisation ait réussi (ex: Xstartup)
Reset Programme à exécuter en root après que la session soit terminée (ex: Xreset)
Session Programme à exécuter en tant que propriétaire de la session à l'ouverture de la session. ex: Xsession (défaut: ${x_bindir}/xterm -ls -T)
FailsafeClient Si la session du programme échoue à s'exécuter, kdm retourne à ce programme, exécuté sans argument mais avec les variable d'environnement de la session (défaut: ${x_bindir}/xterm)
UserPath Variable $PATH pour les sessions non root
SystemPath variale $PATH pour tous les programme sauf pour les sessions non-root
SystemShell variable $SHELL pour les programme sauf la session (défaut: /bin/sh)
UserAuthDir Lorsque kdm ne peut pas écrire dans le fichier habituel d'autorisation de l'utilisateur ($HOME/.Xauthority), il crée un nom de fichier unique dans son dossier et fait pointer la variable XAUTHORITY vers ce fichier. (défaut /tmp)
ForceUserAuthDir à true, UserAuthDir sera utilisé sans condition
AutoReLogin activé, kdm redémarre une session automatiquement après un arrêt intempestif du X-Server (ou tué par Alt-Ctrl-BackSpace). ouvre une brèche de sécurité. défaut: false
AllowRootLogin à true,Permet à root d'ouvrir une session
AllowNullPasswd à false, autorise les utilisateurs sans mot de passe
AllowShutdown Qui peut arrêter le système (None, root, all) (défaut: all)
AllowSdForceNow Qui peut annuler les session actives lors d'une demande d'arrêt (None, Root, All) défaut: all
DefaultSdMode Choix par défaut des conditions/synchronisations d'arrêt (schedule - arrête après la fin de toutes les sessions actives, TryNow - arrêt si aucune session active, ForceNow - Arrêt sans condition) (défaut: Schedule)
ScheduledSd Comment proposer des options de planification d'arrêt (Never, Optional, Always) défaut Never
NoPassEnable Active la connexion sans mot de passe pour cet affichage (défaut: false)
NoPassUsers Les utilisateur qui n'ont pas besoin de fournir de mot de passe pour se connecter. @ pour spécifier un groupe, addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo pour tous sauf root.
AutoLoginEnable Active la connexion automatique (défaut false)
AutoLoginAgain à true, une connexion automatique aura lieu après déconnexion, sinon aura lieu seulement après démarrage d'une session d'affichage (défaut: false)
AutoLoginDelay Délai en seconde avant qu'une connexion automatique démarre
AutoLoginUser L'utilisateur à connecter automatiquement.
AutoLoginPass Mot de passe pour l'utilisateur à connecter automatiquement. Obligatoire pour les domaines NIS et Kerberos (faire un chmod 600 kdmrc)
AutoLoginLocked Vérrouiller immédiatement la session démarrée automatiquement. ne fonctionne qu'avec les sessions KDE. défaut: false
SessionsDirs Liste de dossiers contenant les définitions de types de session, classé par ordre de priorité décroissantes) (défaut: ${kde_datadir}/kdm/sessions)
ClientLogFile fichier relatif au home pour rediriger la sortie de la session (%d - nom de l'afficheur actuel, %u - nom d'utilisateur, %% - un simple %, %r - Quand il est impossible d'utiliser le nom de fichier construit en toute sécurité et que la spécification contient % stuffr, d'autres noms seront essayés - cette fois-ci en modifiant % stuffr en stuff suivi d'un nombre aléatoire) défaut: .xsession-errors
ClientLogFallback Utilisé quand il est impossible d'utiliser ClientLogFile. n'est pas un emplacement relatif. défaut: /tmp/xerr-%u-%d%-r
UseSessReg: Spécifie si le fichier d'enregistrement utmp/wtmp/lastlog doit être utilisé, sinon la commande sessreg devrait être utilisée pour les système avec PAM. défaut: true.

Section X-*-Greeter

GUIStyle Style graphique pour l'écran de connexion.
ColorScheme Modèle de couleur du composant graphique pour l'écran de connexion
LogoArea Ce qui doit être affiché à droite des lignes d'entrées de l'écran de connexion si UserList est désactivé, ou au-dessus si UserList est activé (None, Logo, Clock) défaut: Clock
LogoPixmap Image à afficher dans l'écran de connexion si LogoArea=Logo
GreeterPos Coordonnées relatives (% de la taille de l'écran) auxquels le centre le l'écran de connexion est placé (défaut: 50,50)
GreeterScreen Le moniteur où afficher l'écran.
GreetString Titre de l'écran de connexion. (défaut: Welcome to %s at %n). Les caractères suivants peuvent être utilisés:

        %d Nom de l'affichage actuel
        %h Nom d'hôte local, éventuellement avec nom de domaine
        %n nom du noeud local
        %s Le système d'exploitation
        %r La version de l'OS
        %m Type de machine
        %% simple %

Antialiasing Liste les polices à l'écran (défaut: false)
GreetFont Police de caractère à utiliser pour le titre de l'écran de connexion (défaut: Serif 20pt bold)
StdFont Police standard utilisée dans l'écran de connexion ( défaut: Sans Serif 10pt)
FailFont Police de caractère utilisée pour le message "Login Failed" (défaut: Sans Serif 10pt bold)
NumLock Etat du verrouillage numérique pendant l'écran de connexion (Off, On, Keep). Défaut: Keep
Language Langue et paramètres locaux à utiliser, econdé comme $LANGUAGE. Si vide, utilise la config de l'environnement.
UserCompletion Active l'auto-completion. défaut: false
UserList Affiche une liste d'utilisateurs avec les noms de connexion, réels et images. défaut: true
ShowUsers Contrôle les utilisateurs affiché par UserList. (Selected - utilise SelectedUsers. NotHidden - utilise tous les utilisateurs du système sauf ceux dans HiddenUsers.) défaut: NotHidden
SelectedUsers Liste des utilisateurs à afficher dans la liste
HiddenUsers Liste des utilisateurs à masquer de la liste
MinShowUID Min ID à utiliser dans la liste
MaxShowUID Max ID à utiliser dans la liste
SortUsers Trie les utilisateurs (défaut: true)
FaceSource Si UserList est activé, indique où chercher les images (AdminOnly - depuis ‹FaceDir›/$USER.face[.icon], PreferAdmin - préférer ‹FaceDir› puis se rabattre sur $HOME, PreferUser - dans l'autre sens, UserOnly, depuis $HOME/.face[.icon])
FaceDir Défaut: ${kde_datadir}/kdm/faces
PreselectUser Spécifier si un utilisateur doit être présélectionné pour la connexion (None, Previous, Default)
DefaultUser Utilisateur à utiliser lorsque PreselectUser=Default
FocusPasswd Le curseur se place automatiquement sur le champ mot de passe.
EchoPasswd Affiche le mot de passe saisie dans une bulle. Défaut: true
UseBackground Démarre automatiquement krootimage pour configurer l'arrière plan (défaut: true)
BackgroundCfg Fichier de configuration utilisé par krootimage (défaut: ${kde_confdir}/kdm/backgroundrc)
GrabInput Permet de réserver les entrées souris et clavier. améliore la sécurité mais rend les écrans tactiles inutilisables. (Never, IfNoAuth, Always). défaut IfNoAuth
GrabServer Permet de garder la main sur X server et le clavier. Améliore la sécurité mais désactive UseBackground et Setup
GrabTimeout Temps d'accaparement. défaut: 3
AuthComplain Avertir si un affichage n'a pas d'autorisation X. défaut: true
LoginMode Spécifie le mode et s'il peut basculer (LocalOnly, DefaultLocal, DefaultRemote, RemoteOnly). Défaut: LocalOnly
ChooserHosts Liste d'hôtes à ajouter automatiquement au menu de connexion distante. Défaut: addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo
ForgingSeed Source aléatoire
ShowLog Active la commande xconsole (défaut: false)
LogSource Données sources pour xconsole. si vide, une redirection du log de la console est requise depuis /dev/console.
PluginsLogin modules externes pour la fenêtre de dialogue de connexion. chaque module est spécifié comme nom de base qui sera ajouté à $kde_modulesdir/kgreet_base. défaut: classic
PluginsShutdown Idem pour la boite de dialogue d'arrêt
PluginOptions Options sous la forme key=value pour les modules externes
AllowConsole Ajoute l'action "Passer en mode console". défaut: true
AllowClose Affiche "Redémarrer le serveur X/Fermer la Connexion". défaut: true
Preloader Programme à exécuter lorsque l'écran de connexion est visible.
UseTheme Mode thème. défaut: false
Theme Thème à utiliser.
AllowThemeDebug Active Alt-Ctrl-D pour permettre le debuggage du thème.

Spécifier des X-Servers permanents

   Chaque entrée dans la liste StaticServers indique un afficheur qui doit être constamment géré et qui n'utilise pas XDMCP. Cette méthode est typiquement utilisée uniquement pour les X-Server locaux qui sont lancés par kdm, mais kdm peut aussi bien gérer de façon externe les X-Server « étrangers ») déjà lancés, qu'ils s'exécutent sur la machine locale ou à distance. La syntaxe formelle d'une spécification est, pour tous les serveurs X:

  display name [_display class]

   Le nom de l'afficheur doit être quelque chose qui peut être passé dans l'option -display à un programme X. Les afficheurs spécifiés dans ReserveServers ne seront pas démarrés quand kdm démarre, mais lorsque ce sera explicitement requis par la socket de commande (ou FIFO). Si des afficheurs de réserve sont spécifiés, le menu de KDE aura un élément Start New Session en bas.

   Lorsque kdm démarre une session, il configure les données d'autorisation pour le X-Server. Pour les serveurs locaux, kdm passe l'argument -auth filename sur la ligne de commande du X-Server pour pointer vers son fichier de données de l'autorisation. Pour les afficheurs XDMCP, kdm passe les données de l'autorisation au X-Server via le message XDMCP « Accept ».

Contrôle D'accès de XDMCP

   Le fichier spécifié par l'option AccessFile fournis des informations que kdm utilise pour contrôler l'accès depuis les afficheurs requérant un service via XDMCP. Le fichier contient 4 types d'entrées.

  - Direct: un nom d'hôte ou un modèle, comparé au nom d'hôte du périphérique de l'afficheur. Les modèles utilisent des méta-caractères (*, ?). ! exclut le nom d'hôte. = est requis pour spécifier une macro. suffixé par NOBROADCAST empêche un serveur de kdm d'apparaître dans les menu réalisées à partir des requêtes broadcast.

  - Indirect est similaire et contient un nom d'hôte, modèle ou macro, mais suivi d'une liste de nom d'hôtes et de macro vers lesquels les requêtes doivent être transmises

  - Listen [interface [multicast list]] kdm surveille les requête XDMCP seulement sur les interfaces spécifiées. Pour IPv6 le multicast XDCMP est ff0X:0:0:0:0:0:0:12b. (x vaut 1.noeud local, 2. lien local, 5. site local, etc.)

   Une définition de macro contient un nom de macro et une liste de nom d'hôte et d'autres macro. Les noms des macro commencent avec '%'.

Programmes supplémentaires

   Éxécutés par kdm à différentes étapes d'une session.

Configuration

   Xsetup est exécuté après le démarrage ou la ré-initialisation du X-server, mais avant que l'écran de connexion ne soit affiché. Les variables suivantes sont transmises:

DISPLAY Le nom d'affichage associé
PATH la valeur de SystemPath
SHELL La valeur de SystemShell
XAUTHORITY Peut contenir un fichier d'autorité
DM_CONTROL la valeur de FifoDir

Démarrage

   Xstartup est exécuté en tant que root lorsque l'utilisateur se connecte. C'est ici qu'il faut mettre les commandes qui ajoutent les entrées au fichier utmp (le programme sessreg peut s'avérer utile ici), qui montent les dossiers personnels des utilisateurs depuis les serveurs de fichiers, ou qui abandonnent la session si certaines exigences ne sont pas satisfaites (mais remarquez que sur les systèmes modernes, beaucoup de ces tâches sont déjà prises en charge par les modules PAM). Les variables suivantes sont transmises:

DISPLAY Le nom d'affichage associé
HOME Le home de l'utilisateur
USER nom de l'utilisateur
PATH la valeur de SystemPath
SHELL La valeur de SystemShell
XAUTHORITY Peut contenir un fichier d'autorité
DM_CONTROL la valeur de FifoDir

Session

   Xsession est la commande qui est exécutée en tant qu'utilisateur de la session. Elle est exécutée avec les droits de l'utilisateur autorisé. L'un des mot clés failsafe, default ou custom, ou une chaîne de caractères pour évaluer par un interpréteur de commandes compatible Bourne est passé en premier argument. En sus de toutes celles qui peuvent être spécifiées dans ExportList, les variables d'environnement suivantes sont transmises:

DISPLAY Le nom d'affichage associé
HOME Le home de l'utilisateur
LOGNAME Nom de l'utilisateur
USER nom de l'utilisateur
PATH la valeur de SystemPath
SHELL La valeur de SystemShell
XAUTHORITY Peut contenir un fichier d'autorité
DM_CONTROL la valeur de FifoDir
KRBTKFILE peut contenir un nom de cache d'autorisations Kerberos4
KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5
XDM_MANAGED Contiend une liste de paramètres que la session peut trouver intéressante, comme les modules externe de conversation utilisé pour la connexion
DESKTOP_SESSION Le nom de la session que l'utilisateur a choisi d'exécuter

Réinitialisation

   Xreset est exécuté après que la session utilisateur soit terminée. Exécutez en tant que root, il doit contenir les commandes qui annulent les effets des commandes de Xstartup, supprimant les entrées de utmp ou libérant les dossiers d'un serveur de fichiers. Les variables d'environnement qui ont été transmises à Xstartup le sont aussi à Xreset. plus d'info ici: uubu.fr
^
01 juillet 2014

htmlpdflatexmanmd




Kerberos - Formats

Kerberos - Formats

Formats et données diverses

Format de temps supportés

   Le format time_duration est utilisé pour exprimé une durée de temp dans les fichiers de configuration Kerberos est les commandes utilisateur. Les formats permis sont:

Format____Exemple____valeure
h:m[:s]___36:00______36 hours
NdNhNmNs__8h30s______8 hours 30 seconds
N_________3600_______1 hour

   Note: l'interval de temps ne devrait pas excéder 2147483647 secondes.

   Le format getdate_time spécifie une date. Les formats permis sont:


Date___________mm/dd/yy______07/27/12
_______________month dd, yyyy_Jul 27, 2012
_______________yyyy-mm-dd____2012-07-27
Absolute time__HH:mm[:ss]pp__08:30 PM
_______________hh:mm[:ss]____20:30
Relative time__N tt__________30 sec
Time zone______Z_____________EST
_______________z_____________-0400

   Le format absolute_time, rarement utilisé peut être noté selon un des formats suivants:

Format__________________Example_______________Value
yyyymmddhhmmss__________20141231235900________One minute before 2015
yyyy.mm.dd.hh.mm.ss_____2014.12.31.23.59.00
yymmddhhmmss____________141231235900
yy.mm.dd.hh.mm.ss_______14.12.31.23.59.00
dd-month-yyyy:hh:mm:ss__31-Dec-2014:23:59:00
hh:mm:ss________________20:00:00______________8 o’clock in the evening

Types de chiffrement

   Kerberos peut utiliser divers algorithmes de chiffrement pour protéger des données. Un type de chiffrement Kerberos est une combinaison spécifique d'un algorithme de chiffrement avec un algorithme d'intégrité pour fournir la confidentialité et l'intégrité des données. Les clients effectuent 2 types de demandes (KDC-REQ) au KDC: AS-REQ et TGS-REQ. Le client utilise l'AS-REQ pour obtenir des tickets initiaux ( appelés TGT ), et utilisent TGS-REQ pour obtenir des tickets de service. Le KDC utilise 3 types de clé différentes en fournissant un ticket au client.

La clé long-terme du service: Le KDC l'utilise pour chiffrer le ticket de service actuel. Le KDC utilise la première clé long-terme dans le kvno le plus récent.
La clé de session: Le KDC choisis aléatoirement cette clé et place une copie dans le ticket et une autre copie dans la partie chiffrée de la réponse.
La clé de chiffrement de réponse: Le KDC l'utilise pour chiffrer la réponse qu'il envoie au client. Pour les réponses AS, c'est une clé long-terme du client. Pour les réponses TGS, c'est soit la clé de session du ticket authentifiant, ou une clé de sous-session.

   Chaque type de demande permet au client d'envoyer une liste de type de chiffrement qu'il accepte. Pour AS-REQ, cette liste affecte la sélection de la clé de session et la clé de chiffrement de la réponse. Pour TGS-REQ, cette liste affecte uniquement la sélection de la clé de session.

   Compatibilité des types de chiffrement:
   des-cbc-crc_____________weak____all_____›=2000
   des-cbc-md5_____________weak____all__ __›=2000
   arcfour-hmac____________ _______›=1.3___›=2000
   aes128-cts-hmac-sha1-96_ _______›=1.3___›=Vista
   camellia128-cts-cmac____ _______›=1.9___none

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
KRB5_KTNAME Fichier keytab par défaut
KRB5_CLIENT_KTNAME Fichier keytab client par défaut
KRB5CCNAME fichier du cache d'accréditifs par défaut, sous la forme type:residual
KRB5RCACHETYPE Type de cache replay par défaut. (défaut: dfl) none pour le désactiver
KRB5RCACHEDIR Répertoire du cache replay par défaut.
KPROP_PORT port kprop à utiliser. Défaut: 754
KRB5_TRACE Fichier pour les logs.
^
18 juin 2014

htmlpdflatexmanmd




Kerberos - Installer les KDC

Kerberos - Installer les KDC

Introduction à la configuration initiale des KDC

   En implémentant Kerberos dans un environnement de production, il est préférable d'avoir plusieurs KDC esclave avec un KDC maître pour s'assurer de la disponibilité continue des service kerberisés. Chaque KDC contient une copie de la base de donnée Kerberos. Le KDC maître contient la copie modifiable de la base, qui est répliquée au esclaves à intervalle régulier. Tous les changements de base sont faites sur le maître. Les esclave fournissent les services TGS, mais pas d'administration de la base, quand le KDC maître n'est pas disponible. Le MIT recommande d'installer tous les KDC pour être en mesure de fonctionner soit en tant que maître ou un esclave. Celà permet de facilement basculer un esclave en maître si nécessaire.

Attention

   Le système Kerberos s'appuyent du la disponibilité des informations de temps correcte, assurez vous que le maître et les esclaves ont une horloge synchronisée correctement. Il est préférable d'installer les KDC sur du hardware dédié et sécurisé avec un accès limité.

Installer et configurer le KDC maître

Dans ce document, nous utilisons les noms suivants:
kerberos.mit.edu____-_master KDC
kerberos-1.mit.edu__-_slave KDC
ATHENA.MIT.EDU______-_realm name
.k5.ATHENA.MIT.EDU__-_stash file
admin/admin_________-_admin principal

Éditer les fichiers de configuration du KDC

   Modifier les fichiers de configuration, krb5.conf et kdc.conf, pour refléter les informations telles que le mappage domain-realm et les noms des serveurs kerberos. Beaucoup de tags dans la configuration ont des valeurs par défaut qui sont adéquat à la plupart des sites. Les variables KRB5_CONFIG et KRB5_KDC_PROFILE permettent de spécifier les fichiers altérnatifs:


export KRB5_CONFIG=/yourdir/krb5.conf
export KRB5_KDC_PROFILE=/yourdir/kdc.conf

krb5.conf

   Si vous n'utilisez pas les enregistrements DNS TXT, vous devez spécifier le default_realm dans la section [libdefault]. Si vous n'utilisez par les enregistrements DNS SRV, vous devez inclure le tag kdc pour chaque realm dans la section [realms]. Pour communiquer avec le serveur kadmin dans chaque realm, le tag admin_server doit être définis dans la section [realms].

Exemple de fichier krb5.conf
[libdefaults]
    default_realm = ATHENA.MIT.EDU
    
[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        admin_server = kerberos.mit.edu
    }

kdc.conf

   Ce fichier peut être utilisé pour contrôler les ports d'écoute du KDC en de kadmind, et les paramètres par défaut spécifique au realm, le type de base et son emplacement et le logging.

Exemple de fichier kdc.conf
[kdcdefaults]
    kdc_ports = 88,750

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = aes256-cts
        supported_enctypes = aes256-cts:normal aes128-cts:normal
        # If the default location does not suit your setup,
        # explicitly configure the following values:
        #    database_name = /var/krb5kdc/principal
        #    key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
        #    acl_file = /var/krb5kdc/kadm5.acl
    }

[logging]
    # By default, the KDC and kadmind will log output using
    # syslog. You can instead send log output to files like this:
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

   Remplacer ATHENA.MIT.EDU et kerberos.mit.edu avec le nom de votre domaine et serveur Kerberos, respectivement.

  Note: vous devez avoir les droits d'écriture sur les répertoires cibles ( et doivent exister ) utilisés par database_name, key_stash_file, et acl_file.

Créer la base KDC

   Il faut utiliser la commande kdb5_util sur le KDC maître pour créer la base Kerberos et le fichier optionnel stash.

  Note: Si vous choisissez de ne pas installer un fichier stash, le KDC va vous demander la clé maître chaque fois qu'il démarre.

   kdb5_util va vous demander le mot de passe maître pour la base Kerberos. L'exemple suivant montre comment créer une base Kerberos et le fichier stash sur le KDC maître.


shell% kdb5_util create -r ATHENA.MIT.EDU -s
    
Initializing database '/usr/local/var/krb5kdc/principal' for realm 'ATHENA.MIT.EDU',
master key name 'K/M@ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: ‹= Type the master password.
Re-enter KDC database master key to verify: ‹= Type it again.
shell%

   Cela va créer 5 fichiers dans LOCALSTATEDIR/krb5kdc ( ou l'emplacement spécifié dans kdc.conf ):

        - 2 fichiers de base de données, principal et principal.ok
        - Le fichier de base de données administrative, principal.kadm5
        - Le fichier de lock de la base administrative, principal.kadm5.lock
        - Le fichier stash, dans cet exemple .k5.ATHENA.MIT.EDU. utiliser l'option -s pour ne pas générer ce fichier.

Ajouter les administrateurs au fichier d'ACL

   Ensuite, vous devez créer un fichier d'acl et y placer le principal Kerberos d'au moins un administrateur. Ce fichier est utilisé par kadmind pour contrôler quel principaux peuvent voir et effectuer des modifications privilégiées dans les fichiers de base Kerberos. Le nom du fichier d'acl est déterminé par la variable acl_file dans kdc.conf ( défaut: LOCALSTATEDIR/krb5kdc/kadm5.acl )

Ajouter les administrateurs à la base kerberos

   Vous devez ajouter les principaux administratifs à la base de données Kerberos. Vous devez ajouter au moins un principal pour permettre la communication entre kadmind et kadmin sur le réseaux. Pour cela, utiliser l'utilitaire kadmin.local sur le KDC maître. Il est conçus pour être lancé sur un KDC maître sans utiliser d'authentification Kerberos. Vous devez avoir un accès en lecture/écriture à la base Kerberos.

   Les principaux administratifs que vous créez devraient être ceux ajoutés dans le fichier d'acl.

Dans l'exemple suivant, le principal administratif admin/admin est créé:
shell% kadmin.local
    
kadmin.local: addprinc admin/admin@ATHENA.MIT.EDU
    
WARNING: no policy specified for "admin/admin@ATHENA.MIT.EDU";
assigning "default".
Enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Enter a password.
Re-enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Type it again.
Principal "admin/admin@ATHENA.MIT.EDU" created.
kadmin.local:

Démarrer le service Kerberos sur le KDC maître

À ce point, vous êtes prêt à démarrer le KDC (krb5kdc) et les services administratifs sur le KDC maître:
shell% krb5kdc
shell% kadmind

   Chaque service va se forker en tâche de fond.

Vous pouvez vérifier qu'ils sont lancés correctement en vérifiant les messages de démarrage dans les emplacement le logging spécifiés dans krb5.conf:
shell% tail /var/log/krb5kdc.log
Dec 02 12:35:47 beeblebrox krb5kdc[3187](info): commencing operation
shell% tail /var/log/kadmin.log
Dec 02 12:35:52 beeblebrox kadmind[3189](info): starting

En vérification additionnelle, vérifier si kinit réussit avec les principaux administratifs:
shell% kinit admin/admin@ATHENA.MIT.EDU

Installer les KDC esclave

   Maintenant vous être prêt à configurer les KDC esclaves.

  Note: en assumant que vous paramètrez le KDC de manière à facilement basculer le maître avec un des esclaves, vous devriez effectuer chaque étape sur de maître sur les esclaves, sauf les ces instructions spécifient le contraire.

Créer les keytabs pour les KDC esclave

   Chaque KDC a besoin d'un clé host dans la base Kerberos. Ces clés sont utilisée pour l'authentification mutuelle lors de la propagation des dump de la base de donnée depuis le maître.

   Sur le KDC maître, se connecter à l'interface administrative et créer le principal de l'hôte pour chaque service host des KDC. Par exemple, si le maître s'appel kerberos.mit.edu, et l'esclave s'appel kerberos-1.mit.edu:


shell% kadmin
kadmin: addprinc -randkey host/kerberos.mit.edu
NOTICE: no policy specified for "host/kerberos.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos.mit.edu@ATHENA.MIT.EDU" created.
    
kadmin: addprinc -randkey host/kerberos-1.mit.edu
NOTICE: no policy specified for "host/kerberos-1.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos-1.mit.edu@ATHENA.MIT.EDU" created.

   Il n'est pas nécessaire d'avoir le maître dans la base Kerberos, mais peut être nécessaire si vous souhaitez basculer le maître en esclave. Ensuite, extraire chaque clé host pour tous les KDC participants et les stocker dans chaque fichier keytab de l'hôte. Idéalement, vous devriez extraire chaque keytab localement dans son propre KDC. Si cela n'est pas faisable, vous devriez utiliser une session chiffrée pour les envoyer sur le réseau. Pour extraire un keytab sur un serveur esclave:


kadmin: ktadd host/kerberos-1.mit.edu
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.

Configurer les KDC esclave

   La propagation de la base de données copie le contenu de la base du maître, mais ne propage pas les fichiers de configuration, les fichiers stash, ou le fichier d'acl. Les fichiers suivants doivent être copiés à la main pour chaque esclave:

        - krb5.conf
        - kdc.conf
        - kadm5.acl
        - master key stash file

   Déplacer les fichiers copiés dans leur répertoires appropriés, exactement comme sur le KDC maître. La base est propagée du maître vers les esclaves via le service kpropd. Vous devez explicitement spécifier les principaux qui sont autorisé à fournir les mises à jours Kerberos sur les esclaves avec une nouvelle base de données. Créer un fichier nommé kpropd.acl dans le répertoire d'état KDC contenant les principaux host pour chaque KDC:


host/kerberos.mit.edu@ATHENA.MIT.EDU
host/kerberos-1.mit.edu@ATHENA.MIT.EDU

   Note: si vous souhaitez que le maître et l'esclave puis être inversés, listez les principaux hôtes depuis tous les KDC participants dans les fichiers kpropd.acl dans tous les KDC. Sinon, vous avez seulement besoin de lister le principal de l'hôte du KDC maître dans kpropd.acl des KDC esclaves.

Ensuite, ajoutez la ligne suivante dans /etc/inetd.conf dans chaque KDC:
krb5_prop 754/tcp # Kerberos slave propagation

   Redémarrez inetd. Alternativement, démarrer kpropd comme service standalone. Cela est nécessaire quand la propagation incrémental est activé.

   Maintenant que le KDC est capable d'accepter la propagation de la base, vous avez besoin de propager la base depuis le maître. Note: Ne pas démarrer le KDC esclave avant d'avoir une copie du maître.

Propager la base à chaque esclave

Premièrement, créer un fichier dump de la base sur le maître:
shell% kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
Puis, propager manuellement la base à chaque esclave:
shell% kprop -f /usr/local/var/krb5kdc/slave_datatrans kerberos-1.mit.edu
Database propagation to kerberos-1.mit.edu: SUCCEEDED

   Vous aurez besoin d'un script pour dumper et propager la base. voici un exemple de script shell. Rappelez vous que vous avez besoin de remplacer /usr/local/var/krb5kdc avec le nom du répertoire d'état KDC.


#!/bin/sh
    
kdclist = "kerberos-1.mit.edu kerberos-2.mit.edu"
    
kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
    
for kdc in $kdclist
do
    kprop -f /usr/local/var/krb5kdc/slave_datatrans $kdc
done

Vous avez besoin du définir un cron pour lancer ce script à intervalle régulier. Maintenant que l'esclave a une copie de la base Kerberos, vous pouvez démarrer krb5kdc:
shell% krb5kdc

Erreurs de propagation

kprop: No route to host while connecting to server
Assurez vous que le nom d'hôte de l'esclave est correct et que les firewalls entre le maître et l'esclave autorisent le port 754.
kprop: Connection refused while connecting to server
Si l'esclave tente de lancer kpropd via inetd, assurez vous que inetd est configuré pour accepter les connections krb5_prop. inetd a besoin de relire sa configuration pour qu'un changement soit pris en compte.
kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
assurez vous que:

        1. L'heure est synchonisée
        2. Le fichier stash du maître a été copié sur l'esclave à l'emplacement attendu
        3. L'esclave a un fichier keytab contenant un principal host pour le nom d'hôte de l'esclave.

Ajouter des principaux à la base

   Une fois les KDC définis et fonctionnels, vous êtes prêt à utiliser kadmin pour charger les principaux pour vos utilisateurs, hôtes, et autres services dans la base kerberos. Vous pouvez occasionnellement utiliser un des esclaves comme maître. Cela peut se produire si vous mettez à jour le maître, ou si le maître crash.

Basculer de maître et d'esclave

   Si le KDC maître fonctionne, effectuez les étapes suivantes sur l'ancien maître:

        1. Tuer kadmind
        2. Désactiver le job cron qui propage la base
        3. Lancer le script de propagation manuellement, pour s'assurer que tous les esclaves ont la dernière copie de la base.

   Sur le nouveau maître:

        1. Démarrer Kadmind
        2. Définir un cron pour propager la base
        3. Bascules les CNAME de l'ancien vers le nouveau maître. Si vous ne pouvez pas le faire, vous aurez besoin de changer le fichier krb5.conf sun chaque client dans le domaine kerberos.
^
01 juillet 2016

htmlpdflatexmanmd




keys-ecryptfs

keys-ecryptfs

Système de fichier stacké à chiffrement transparent

   ecryptfs est un système de fichier stacké qui chiffre et déchiffre de manière transparente chaque fichier en utilisant une clé de chiffrement de fichier (FEK) générée aléatoirement.

   Chaque FEK est en retour chiffré avec une clé de chiffrement de clé de chiffrement de fichier (FEFEK) soit dans l'espace kernel ou en espace utilisateur avec un service appelé ecryptfsd. Dans le premier cas, l'opération est effectuée directement par le cryptoAPI du kernel en utilisant une clé, la FEFEK, dérivée d'une passphrase de l'utilisateur; dans l'autre cas, la FEK est chifrée par ecryptfsd avec l'aide de librairies externes pour supporter d'autres mécanismes comme les clés publiques, PKCS#11 et TPM.

   La structure de données définie par ecryptfs pour contenir les informations requises pour le déchiffrement FEK est appelé le jeton d'authentification et , actuellement, peut être stocké dans une clé kernel de type 'user', inséré dans la session de l'utilisateur par l'utilitaire userspace mount.ecryptfs fournis avec le paquet ecryptfs-utils

   Le type de clé encrypted a été étendue avec l'introduction du nouveau format ecryptfs pour être utilisé en conjonction avec le système de fichier ecryptfs. Les clé chiffrées au nouveau format stockent un jeton d'authentification dans son payload avec un FEFEK générée aléatoirement par le kernel et protégé par la clé maître.

   Pour éviter les attaques plaintext, le 'datablob' obtenu via les commandes 'keyctl print' ou 'keyctl pipe' ne contiennent pas tout le jeton d'authentification, dont le contenu est connu, mais seulement la FEFEK sous forme chiffrée.

   Le système de fichier ecryptfs peut réellement bénéficier de l'utilisation de clé chiffrées car les clés requises peuvent être générées de manière sécurisée par un administrateur et fournis au boot une fois la clé de confiance fournie pour effectuer le montage dans un environnement contrôlé. Un autre avantage est que la clé n'est pas exposée aux traitements de logiciels malicieux, parce qu'elle est disponible en clair seulement au niveau du kernel.

Utilisation

keyctl add encrypted name "new ecryptfs key-type:master-key-name keylen" ring
keyctl add encrypted name "load hex_blob" ring
keyctl update keyid "update key-type:master-key-name"
name:= '‹ 16 hexadecimal characters ›'
key-type:= 'trusted' | 'user'
keylen:= 64

Exemple d'utilisation de clé chiffrée avec le système de fichier ecryptfs

Créer un clé chiffrée "1000100010001000" de 64bits de long au format ecryptfs et la sauver avec une clé utilisateur précédemment chargée "test":
keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u 19184530
keyctl print 19184530
ecryptfs user:test 64 490045d4bfe48c99f0d465fbbbb79e7500da954178e2de0697
dd85091f5450a0511219e9f7cd70dcd498038181466f78ac8d4c19504fcc72402bfc41c2
f253a41b7507ccaa4b2b03fff19a69d1cc0b16e71746473f023a95488b6edfd86f7fdd40
9d292e4bacded1258880122dd553a661
keyctl pipe 19184530 › ecryptfs.blob
Monter un système de fichier ecryptfs avec la clé chiffrée créée "1000100010001000" dans le répertoire /secret:
mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret
^
25 mai 2017

htmlpdflatexmanmd




keys.txt

keys.txt

Service de rétention de clé kernel

   Ce service autorise les clé cryptographiques, jetons d'authentification, mappage d'utilisateur inter-domaine, et similaire d'être mis en cache dans le kernel pour utiliser les systèmes de fichier et d'autres services kernel.

   Les portes-clés sont permis; ce sont des type spéciaux de clé qui peuvent maintenir des liens vers d'autres clés. Chaque processus a 3 souscription de porte clé standard qu'un service peut utiliser pour trouver des clés.

   Le service de clé peut être configuré ou activé avec "Security options"/"Enable access key retention support" (CONFIG_KEYS)

Présentation

   Dans ce contexte, les clés représentent des unités de données cryptographiques, des jetons d'authentification, porte clé, etc. Ils sont représenté dans le kernel pas la structure key.

   Chaque clé a un nombre d'attribut:

- un numéro de série
- un type
- une description
- des informations de contrôle d'accès
- une date d'expiration
- Un payload
- l'état

   Chaque clé reçois un numéro de série du type key_serial_t qui est unique pour la durée de vie de cette clé. Tous les numéros de série sont des entier 32bits positifs. Les programmes userspace peuvent utiliser le numéro de série d'une clé comme moyen d'y accéder, sujet à vérification des permissions.

   Chaque clé est d'un type définis. Les types doivent être enregistrés dans le kernel par un service kernel (tel qu'un système de fichier) avant que des clés de ce type puissent être ajoutées ou utilisées. Les programmes userspace définissent les nouveaux type directement. Les types de clé sont représentés dans le kernel par la structure key_type. cela définis un nombre d'opérations qui peuvent être effectuées sur une clé de ce type.

   Chaque clé a une description, qui devrait être une chaîne affichable. Le type de clé fournis une opération pour effectuer une correspondance entre la description dans un cré et une chaîne critère

   Chaque clé peut être définie pour expirer à un moment donné par la fonction d'instantiation du type. Les clés peuvent être immortelles.

   Chaque clé peut avoir un payload. C'est la quantité de données qui représente la clé. Dans le cas d'un porte-clé, c'est une liste de clés qui sont liées au trousseau; dans le cas d'une clé définie par l'utilisateur, c'est un blob de donnée arbitraire Ce payload n'est pas requis, et le payload peut, en fait, être simplement stocké dans la structure de clé elle-même

   Similairement, quand le userspace souhaite lire le contenu de la clé, si permis, une autre opération de type de clé sera appelée pour convertir le payload attaché à la clé en un blob de donnée.

   Chaque clé peut être dans un des états de base suivant:

- non-instancié. La clé existe, mais n'a pas de données attachée. Les clés demandée depuis le userspace sont dans cet état
- instancié: C'est l'état normal. La clé est formée, et a des donnée attachées
- Négative. C'est un état relativement court. La clé agit comme une note disant que l'appel précédent du userspace a échoué, et agit comme un accélérateur de recherche de clé. une clé négative peut être mise à jours vers un état normal.
- expiré. Les clé ont dépassés la durée de vie définie. Une clé expirée pour être mise à jours pour revenir à un état normal
- révoqué. Une clé est placée dans cet état par une action userspace.
- dead. Le type de clé a été désenregistré

Vue générale du service de clés

   Le service de clé fournis des fonctionnalité:

           Le service de clé définis 3 types de clé spéciaux

                keyring Keyring sont des clé spéciales qui contiennent une liste d'autres clé.
                user Une clé de ce type a une description et un payload qui sont des blobs arbitraires de données. Ils peuvent être manipulés par le userspace et ne sont pas prévus pour être utilisés par les services kernel
                logon Comme une clé user, une clé logon a un payload qui est un blob de données arbitraire. Il est prévue comme un emplacement pour stocker des secrets qui sont accessible au kernel mais pas aux programmes userspace

        Chaque processus souscrit à 3 keyrings: un keyring spécifie au thread, un keyring spécifique au processus, et un keyring spécifique à une session.
        Chaque user ID résident dans le système maintient 3 keyrings spéciaux: un spécifique à l'utilisateur et un spécifique à la session utilisateur.
        Chaque utilisateur a 2 quotas avec lesquel les clés qu'ils possèdent sont suivis. Une limite le nombre total de clé et de trousseaux, et l'autre limite la quantité totale d'espace qui peut être consommé par les descriptions et payload
        Il y a une interface d'appel système par laquelle les programmes peuvent créer et manipuler les clé et trousseaux.
        Il y a une interface kernel par laquelle les services peuvent enregistrer des type et rechercher des clés
        Il y a une manière pour qu'une recherche faite depuis le kernel revienne au userspace pour demander une clé qui ne peut pas être trouvée dans un trousseau de processus
        Un système de fichier optionnel est disponible via lequel la base de clé peuvent vue et manipulée

Permissions d'accès aux clés

   Les clé ont un propriétaire, un groupe d'accès, et un masque de permission. La masque a jusqu'à 8 bit chacun pour le processeur, utilisateur, groupe et les autres accès. Seul six de chaque jeu de 8bits sont définis. Ces permissions sont:

        View Permet de voir une clé ou un trousseau, incluant le type et description
        Read Permet de voir une le payload d'une clé, ou la liste des clé liées au trousseau
        Write Permet d'instancier un payload de clé ou de le mettre à jours, ou d'ajouter/supprimer un lien vers un trousseau.
        Search Permet de rechercher un trousseau et des clés.
        Link Permet de lier une clé ou un trousseau. Pour créer un lien d'un trousseau vers une clé, un processus doit avoir la permission Write sur le trousseau, et la permission Link sur la clé
        Set Attribute Permet de changer le masque de permissions

Support SELinux

   La classe de sécurité "key" a été ajoutée à SELinux pour que le contrôle d'accès puisse être appliqué aux clés créées dans divers contextes. Actuellement, toutes les permissions de base ci-dessus sont fournis dans SELinux, SELinux est simplement invoqué une fois les vérification de permissions de base effectuées.

   La valeur du fichier /proc/self/attr/keycreate influence le labéling des clés créées. Si le contenu de ce fichier correspont à un contexte de sécurité SELinux, la clé obtiendra ce contexte, sinon, la clé obtiendra le contexte courant de la tâche qui a invoqué la création de la clé. Les tâches doivent données explicitement les permissions à assigner à un contexte particulier aux clé nouvellement créées, en utilisant la permission "create" dans la classe de sécurité key.

   Les trousseaux par défaut associés avec les utilisateurs sont labélisés avec le contexte par défaut de l'utilisateur si et seulement si les programmes login ont été configurés correctement pour initialiser keycreate durant le processus de login. Sinon, il vont être labélisé avec le contexte du programme login lui même.

   Noter, cependant, que les trousseaux par défaut associés avec l'utilisateur root sont labélisés avec le contexte kernel par défaut, vu qu'ils sont créés très tôt dans le processus de boot, avant que root ait une chance de se connecter.

   Les trousseaux associés avec de nouveaux threads sont chacun labélisés avec le contexte de leur thread associés, et les trousseaux de session et de processus sont gérés de manière similaire.

Nouveaux fichiers procfs

   2 fichiers ont été ajoutés à procfs par lesquels un administrateur peut trouver le status du service de clé:

/proc/keys Liste les clé qui sont actuellement lisibles par la tâche lisant le fichier, en donnant les informations sur le type, description et permissions. Les clés incluse dans la liste sont celles dont la permission View est donné au processus qui lit le fichier. Noter que les vérifications de sécurité LSM sont effectuées, et peuvent filtrer les clés que le processus courant n'est pas autorisé à voir.


        Le contenu ressemble à:
SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY
00000001 I----- 39 perm 1f3f0000 0 0 keyring _uid_ses.0: 1/4
00000002 I----- 2 perm 1f3f0000 0 0 keyring _uid.0: empty
00000007 I----- 1 perm 1f3f0000 0 0 keyring _pid.1: empty
0000018d I----- 1 perm 1f3f0000 0 0 keyring _pid.412: empty
000004d2 I--Q-- 1 perm 1f3f0000 32 -1 keyring _uid.32: 1/4
000004d3 I--Q-- 3 perm 1f3f0000 32 -1 keyring _uid_ses.32: empty
00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0
00000893 I--Q-N 1 35s 1f3f0000 0 0 user metal:silver: 0
00000894 I--Q-- 1 10h 003f0000 0 0 user metal:gold: 0

        I Instancié
        R Révoqué
        D Mort
        Q Contribut au quota de l'utilisateur
        U En construction
        N Clé négative

/proc/key-users Ce fichier liste les données pour chaque utilisateur qui a au moins une clé dans le système. De telles données incluent les informations de quota et des statistiques:


        [root@andromeda root]# cat /proc/key-users
0: 46 45/45 1/100 13/10000
29: 2 2/2 2/100 40/10000
32: 2 2/2 2/100 40/10000
38: 2 2/2 2/100 40/10000

        ‹UID› User ID
        ‹usage› Structure refcount
        ‹inst›/‹keys› Nombre total de clés et le nombre instanciées
        ‹key›/‹max› Quota - compteur de clé
        ‹bytes›/‹max› Quota - taille de clé

   4 nouveaux fichiers sysctl ont été ajoutés également pour contrôler les limites de quota:

/proc/sys/kernel/keys/root_maxkeys Nombre maximum de clés que root peut posséder
/proc/sys/kernel/keys/root_maxbytes Taille maximum en octets que root peut stocker dans ces clés
/proc/sys/kernel/keys/maxkeys Nombre total de clé qu'un utilisateur peut posséder
/pro/sys/kernel/keys/maxbytes Taille maximum en octets qu'une utilisateur peut stocker dans ces clés

Garbage collector

   Les clés morets (pour lesquelles le type a été supprimé) sont automatiquement unlinked des trousseaux et supprimés dès que possible par un collector en tâche de fond.

Similairement, les clé révoquées et expirées sont collectées, mais seulement au bout d'un certain temps. Ce délai est définis en secondes dans:
/proc/sys/kernel/keys/gc_delay
^
23 mai 2010

htmlpdflatexmanmd




kill

kill

Envoyer un signal à un processus

   Le signal par défaut est TERM. Utiliser -l ou -L pour une liste possible de signaux. Les signaux particulièrement utiles sont HUP, INT, KILL, STOP, CONT, et 0. Les signaux peuvent être spécifiés de 3 manières différentes. -9 -SIGKILL -KILL. Les valeur de PID négatives peuvent être utilisés pour choisir les groupes de processus; voir la colonne PGID de la commande ps. Un PID de -1 est spécial; il indique tous les processus excepté le processus kill lui-même et init.

Quelques signaux


Nom_____Num_____Action_____Description
0________0_______n/a________Code de sortie indiquant si un signal peut être envoyé.
ALRM____14_______exit_______
HUP______1_______exit_______
INT______2_______exit_______
KILL_____9_______exit_______Ne peut pas être bloqué
PIPE____13_______exit_______
TERM____15_______exit_______
STOP_____________stop_______Ne peut pas être bloqué
CONT_____________restart____Continue si stoppé, sinon ignore
QUIT_____3_______core_______
TRAP_____5_______core_______

   Note: Le shell peut avoir une commande kill intégré.

Exemples

kill -9 -1
tue tous les processus que vous pouvez tuer
kill -l 11
Traduit le nombre 11 en nom de signal
kill -L
Liste les signaux
kill 123 543 2341 3453
Envoie le signal par défaut à ces processus
^
23 mai 2010

htmlpdflatexmanmd




killall

killall

Tuer tous les processus

   killall tue les processus par nom. Il envoie un signal à tous les processus (SIGTERM par défaut) spécifiés. Les signaux peuvent être spécifiés par nom, par numéro ou par l'option -s. Si le nom spécifié n'est pas un expression régulière et contient un "/", les processus exécutant ce fichier seront tués, indépendamment de leur nom.

OPTIONS

-e, --exact Requière le nom exacte, mais ne gère que 15 caractères max.
-I, --ignore-case insensible à la casse
-g, --process-group Tue le groupe de processus auquel le processus appartient. Le signal est envoyé une seule fois par groupe.
-i, --interactive demande confirmation avant de tuer.
-l, --liste Liste les noms de signaux.
-q, --quiet n'affiche rien si aucun processus n'a été tué
-r, --regexp Utiliser les regex pour trouver les processus à tuer
-s, --signal envoie le signal spécifié aux processus
-u, --user Tue uniquement les processus appartenant à user
-v, --verbose mode verbeux
-w, --wait Attend que tous les processus soit tués. killall vérifie une fois par seconde.
-Z, --context (SELinux uniquement) spécifie le contexte de sécurité : tue uniquement les processus ayant un contexte de sécurité particulier.
^
23 mai 2010

htmlpdflatexmanmd




killall5

killall5

Envoie un signal à tous les processus

   C'est la commande killall de system V. Il envoie un signal à tous les processus excepté les threads du kernel et les processus de la propre session, donc il ne tuera pas le shell qui le lance.

OPTIONS

-o dit a killall5 d'omettre ce pid
^
30 juin 2014

htmlpdflatexmanmd




kinit

kinit

Obtenir un TGT initial

OPTIONS

-v mode verbeux
-l lifetime (Chaîne time_duration) Demande un ticket avec la durée de vie spécifiée (ex: kinit -l 5:30 ou kinit -l 5h30m).
-s start_time (Chaîne time_duration) Demande un ticket post-daté en spécifiant le délai avant que le ticket devienne valide.
-r renewable_life (Chaîne time_duration) Demande des tickets renouvelables, avec la durée de vie totale spécifiée.
-f Demande des tickets forwardable
-F Demande des tickets non-forwardable
-p Demande des tickets proxiable
-P Demande des tickets non-proxiable
-a Demande des tickets restreins aux adresses locales de l'hôte.
-A Demande des tickets non restreins pas des adresses
-C Demande la canonisation du nom du principal, et permet au KDC de répondre avec un principal client différent.
-E  Traite le nom du principal comme un nom d'entreprise
-v Demande que le TGT dans le cache ( avec le flag invalid ) soit passé au KDC pour validation.
-R Demande de renouveler le TGT.
-k [-i | -t keytab_file] Demande un ticket, obtenu depuis un clé dans le keytab de l'hôte. L'emplacement du keytab peut être spécifié avec -t, ou avec -i pour spécifier l'utilisation de keytab du client par défaut. Par défaut, un ticket d'hôte pour l'hôte local est requis, mais tout principal peut être spécifié. Sur le KDC, l'emplacement du keytab spécial KDB: peut être utilisé pour indiquer que kinit devrait ouvrir la base du KDC et rechercher la clé directement. Cela permet aux administrateur d'obtenir des tickets pour tous principal qui supporte l'authentification basé sur les clé.
-n  Demande un traitement anonyme.
-I input_ccache Spécifie le nom du cache d'accréditifs qui contient déjà un ticket. En obtenant ce ticket, si les informations d'obtention de ce ticket sont également présentes dans le cache, ces informations seront utilisées pour affecter l'obtention des nouveaux tickets, incluant les méthodes d'authentification auprès du KDC.
-T armor_ccachef Spécifie le nom du cache d'accréditifs qui contient déjà un ticket. Si supporté par le KDC, ce cache sera utilisé pour protéger la demande, empêchant les attaques par dictionnaire offline et permettant d'utiliser des mécanismes de pré-authentification additionnels.
-c cache_name Utilise le cache spécifié comme cache d'accréditifs au lieu du cache par défaut spécifié par la variable KRB5CCNAME
-S service_name Spécifie un nom de service alternatif à utiliser pour obtenir les tickets initiaux.
-X attribute[=value] Spécifie un attribut/valeur de pré-authentification interprété par les modules de pré-authentification. Les attributs reconnus par PKINIT sont les suivants:

        X509_user_identity=value Spécifie où trouver les informations d'identité X509 de l'utilisateur
        X509_anchors=value Spécifie où trouver les informations de validation X509
        flag_RSA_PROTOCOL[=yes] Spécifie l'utilisation de RSA au lieu de DH

Variables d'environnement

        KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
DEFKTNAME Emplacement par défaut pour le keytab de l'hôte local
^
30 juin 2014

htmlpdflatexmanmd




klist

klist

Lister les principaux et les tickets dans les caches

OPTIONS

-e  Affiche les types de chiffrements de la clé de session et du ticket pour chaque accréditif dans le cache, ou chaque clé dans le fichier keytab
-l Si une collection de cache est disponible, affiche un sommaire des caches présents dans la collection
-A Si une collection de cache est disponible, affiche le contenu de tous les caches présents dans la collection
-c Liste les tickets dans le cache d'accréditifs.
-f Affiche les flags présent dans les accréditifs, en utilisant les abréviations suivante:

        F Forwardable
        f forwarded
        P Proxiable
        p proxy
        D postDateable
        d postdated
        R Renewable
        I Initial
        i invalid
        H Hardware authenticated
        A preAuthenticated
        T Transit policy checked
        O Okay as delegate
        a anonymous

-s Mode silencieux
-a Affiche une liste d'adresses dans les accréditifs
-n  Affiche les adresses numériques au lieu des adresses reverse
-C Liste les données de configuration stockés dans le cache d'accréditifs quand klist les rencontre.
-k Liste les clés dans le keytab
-i avec -k, utilise le keytab du client par défaut au lieu du keytab acceptor, si aucun nom n'est donné.
-t Affiche l'heure d'entrée pour chaque entrée keytab
-K Affiche la valeur de clé de chiffrement dans chaque entrée keytab
-V Affiche la version de Kerberos et quitte.

Variables d'environnement

        KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
DEFKTNAME Emplacement par défaut pour le keytab de l'hôte local
^
28 mars 2016

htmlpdflatexmanmd




kmod

kmod

Gestion des modules Linux

   kmod est un binaire multi-call qui implémente les programmes utilisé pour contrôler les modules du kernel. Il est généralement appelé sous ses autres noms: lsmod, insmod, rmmod, modinfo, modprobe ou depmod

Commandes

list Liste les modules actuellement chargés
static-nodes Affiche les informations du nœud statique fournis par les modules de la version actuelle du kernel
^
12 octobre 2016

htmlpdflatexmanmd




kpartx

kpartx

Créer des maps de périphérique depuis des tables de partition

   Cet outil, dérivé de partx, lit les tables de partitions sur le périphérique spécifié et créé des maps de périphérique sur les segments de partition détectés.

OPTIONS

-a Ajoute des mappages de partition
-r Mappages lecture seule
-d Supprimer des mappages de partition
-u Mettre à jours des mappages de partition
-l Liste les mappages de partition qui aurait été ajouté avec -a
-p Définis le délimiteur de numéro de partition
-f Force la création des mappages
-g Force la table de partition GUID
-v mode verbeux
-s Mode syncho. Ne retourne pas tant que les partitions ne sont pas créées

Exemples

Monter toutes les partitions dans une image raw
kpartx -av disk.img
cela affichera:
loop3p1 : 0 20964762 /dev/loop3 63
Pour vérifier la partition:
fsck /dev/mapper/loop3p1
Pour supprimer le périphérique
kpartx -d disk.img
^
30 juin 2014

htmlpdflatexmanmd




kpasswd

kpasswd

Changer le mot de passe d'un principal

   Cette commande est utilisée pour changer le mot de passe d'un principal. kpasswd demande d'abord le mot de passe actuel, puis demande à l'utilisateur de rentrer le nouveau mot de passe 2 fois. Si le principal est gouverné par une stratégie qui spécifie la longueur et/ou la complexité, le nouveau mot de passe doit se conformer à cette stratégie.

OPTIONS

principal Change le mot de passe pour le principal Kerberos. Sinon, kpasswd utilise le nom du principal depuis le ccache existant s'il y'en a un, sinon, le principal est dérivé de l'identité de l'utilisateur qui appel kpasswd.
^
26 juin 2014

htmlpdflatexmanmd




kprop

kprop

Propage le dump de la base Kerberos

   kprop est utilisé pour propager un fichier de dump de la base Kerberos de manière sécurisé, depuis le serveur maître vers un esclave

OPTIONS

-r realm Spécifie le domaine Kerberos
-f file Fichier à propager
-P port Port à utiliser pour contacter le serveur kpropd sur l'hôte distant
-d mode debug
-s keytab Spécifie l'emplacement du fichier keytab

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
^
26 juin 2014

htmlpdflatexmanmd




kpropd

kpropd

Service d'écoute pour la propagation des bases Kerberos

   kpropd tourne sur un serveur esclave et écoute les demandes de mises à jours faites par le programme kprop. Si la propagation incrémentale est activé, il demande périodiquement les mises à jour au maître.

   Quand l'esclave reçoit une demande kprop du maître, kpropd accepte la base du KDC dump et le place dans un fichier, puis lance kdb5_util pour charger la base dumpée dans la base active utilisée par krb5kdc. Quand la propagation incrémentale n'est pas utilisée, kpropd est généralement invoqué par inetd en utilisant:

  kprop stream tcp nowait root /usr/local/sbin/kpropd kpropd

   kpropd peut également être lancé en tant que serveur autonome, il se met en tâche de fond et écoute sur le port 754 par défaut. Ce mode est requis pour la propagation incrémentale. La propagation incrémentale peut être activée avec iprop_enable dans kdc.conf. L'intervalle de propagation incrémentale est déterminé par iprop_slave_poll. Si l'esclave reçoit des mises à jours, kpropd met à jours son fichier de log avec toutes les mises à jours du maître. kproplog peut être utilisé pour voir un sommaire de ces logs. Si la propagation incrémentale est activée, le principal kiprop/slavehostname@REALM doit être présent dans le fichier keytab de l'esclave. kproplog peut être utilisé pour forcer une réplication complète si activé.

OPTIONS

-r realm Spécifie le domaine Kerberos
-f file Fichier à importer
-p Chemin du programme kdb5_util
-d mode debug
-P Port d'écoute
-a acl_file
Chemin du fichier d'acl

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

Fichiers

kpropd.acl chaque entrée est une ligne contenant le principal d'un hôte depuis lequel la machine local va autoriser la propagation de la base Kerberos via kprop.
^
27 juin 2014

htmlpdflatexmanmd




kproplog

kproplog

Affiche le contenu les logs de mise à jours de la base Kerberos

   kproplog affiche le contenu des logs de mise à jours du KDC sur la sortie standard. Il peut être utilisé pour garder une trace des mises à jours incrémental de la base principal. Le fichier de log contient les logs maintenus par le processus kadmind sur le serveur maître, et kpropd sur les serveurs esclaves. Quand une mise à jours se produit, elle est loggée dans ce fichier. kproplog nécessite un accès en lecture à ce fichier, il va afficher uniquement les mises à jours pour le KDC sur lequel il est lancé. Sans options, affiche un sommaire des logs. Si invoqué sur le maître, affiche uniquement un sommaire des mises à jours.

OPTIONS

-R Ré-initialise le fichier de log. Force une re-synchronisation complète. Si utilisé sur un esclave, il va tout synchroniser. Sur un maître, tous les esclaves vont demander une synchronisation complète.
-h Affiche un sommaire des logs. Inclus le numéro de version, l'état de la base, le nombre d'updates, le timestamp du premier et dernier update, et le numéro de version de la première et dernière entrée.
-e num Affiche le num dernières entrées dans le log.
-v Affiche les attributs individuels par update. Exemple de sortie générée pour une entrée:


Update Entry
    Update serial # : 4
    Update operation : Add
    Update principal : test@EXAMPLE.COM
    Update size : 424
    Update committed : True
    Update time stamp : Fri Feb 20 23:37:42 2004
    Attributes changed : 6
        Principal
        Key data
        Password last changed
        Modifying principal
        Modification time
        TL data

Variables d'environnement

KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
^
30 juin 2014

htmlpdflatexmanmd




krb5-config

krb5-config

Indique quels flags utiliser pour compiler et lier les programmes avec Kerberos

   Krb5-config indique au programmeur d'application quels flags utilisés pour compiler et linker les programmes avec les librairies Kerberos installées.

OPTIONS

--all Affiche la version, vendeur, préfixe, et exec-prefix
--version Affiche le numéro de version de Kerberos
--vendor Affiche le nom du vendeur de l'installation Kerberos
--prefix Affiche le préfixe pour lequel l'installation Kerberos a été construite
--exec-prefix Affiche le préfixe pour les exécutables pour lequel l'installation Kerberos a été construite
--defccname Affiche l'emplacement du cache d'accréditifs par défaut.
--defktname Affiche l'emplacement du keytab par défaut
--defcktname Affiche l'emplacement du keytab client par défaut
--cflags Affiche les flags de compilation utilisés pour construire l'installation Kerberos
--libs [library] Affiche les options du compileur nécessaire pour linkerà la librairie spécifiée. les valeurs permises sont:

        krb5 Kerberos 5 applications (default)
        gssapi GSSAPI applications with Kerberos 5 bindings
        kadm-client Kadmin client
        kadm-server Kadmin server
        kdb Applications qui accèdent à la base Kerberos
^
18 juin 2014

htmlpdflatexmanmd




krb5.conf

krb5.conf

Fichier de configuration Kerberos

   Ce fichier contient la configuration Kerberos, incluant l'emplacement des serveurs KDC et admin pour les domaines Kerberos, les valeurs par défaut pour le domaine courant et pour les applications kerberos, et les mappages de nom d'hôte dans les royaumes Kerberos. Normallement, ce fichier est dans /etc mais son emplacement peut être spécifié dans la variable KRB5_CONFIG.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

  

ou:
fubar = {
    foo = bar
    baz = quux
}

   Placer un * à la fin d'une ligne indique que c'est la valeur final pour le tag. Cela signifie que ni le reste du fichier de configuration, ni un autre fichier de configuration ne sera vérifié pour une autre valeur pour ce tag.

Par exemple, les lignes suivantes:
foo = bar*
foo = baz
Alors la seconde valeur ne sera jamais lue.

Le fichier krb5.conf peut inclure d'autres fichiers en utilisant une des directives suivantes au début d'une ligne:
include FILENAME
includedir DIRNAME

   FILENAME et DIRNAME doivent être des chemin absolus. Le fichier ou le répertoire nommé doit exister et lisible. Inclure un répertoire inclue tous les fichiers dans le répertoire dont le nom consiste uniquement de caractères alphanumériques, "-" ou "_". Les fichiers de profils sont syntaxiquement indépendants de leurs parent, donc chaque fichier inclus doit commencer avec un en-tête de section. Le fichier krb5.conf peut spécifier que la configuration devrait être obtenue depuis un module chargeable, au lieu du fichier lui-même, en utilisant le directive suivante au début de la ligne avant toute section headers:

  module MODULEPATH:RESIDUAL

  MODULEPATH peut être relatif au chemin de librairies de l'installation de krb5, ou peut être un chemin absolus. RESIDUAL est fournis au module à l'initialisation. Si krb5 utilise une directive module, kdc.conf devrait également l'utiliser.

Sections

   krb5.conf peut contenir les sections suivantes:

[libdefaults] Paramètres utilisés par la libraire Kerberos v5
[realms] information et paramètres de contact spécifique au domaine
[domain_realm] Map les noms d'hôte serveur à des domaines Kerberos
[capaths] Chemins d'authentification pour les inter-domaines non-hiérarchiques
[appdefaults] Paramètres utilisés par certaines applications Kerberos
[plugins] Contrôle l'enregistrement des plugins

   Additionnellement, krb5.conf peut inclure une des relations décrites dans kdc.conf, mais n'est pas une pratique recommandée.

[libdefaults]

allow_weak_crypto à false (défaut), les type de chiffrements faibles seront exclus des listes default_tgs_enctypes, default_tkt_enctypes, et permitted_enctypes.
ap_req_checksum_type Un entier qui spécifie le type de checksum AP-REQ à utiliser dans l'authentifiant. Doit être non définis pour le checksun approprié pour la clé de chiffrement soit utilisé.
canonicalize A true (défaut: false), la requête du ticket initial va demander la canonicalisation du nom du principal, et que répondre avec des principaux du client différent du principal demandé sera accepté.
ccache_type Détermine le format du cache d'accéditifs créés par kinit ou autre. défaut: 4, qui représente le format le plus courant.
clockskew Définis la quantité maximum permise de décalage d'horloge en seconde que la librairie va tolérer. Défaut: 300.
default_ccache_name Cette relation spécifie le nom du cache d'accréditifs par défaut. Défaut: DEFCCNAME.
default_client_keytab_name Cette relation spécifie le nom du keytab par défaut pour obtenir les accréditifs du client. Défaut: DEFCKTNAME.
default_keytab_name Cette relation spécifie le nom du keytab par défaut à utiliser par les serveurs d'application tels que sshd. Défaut: DEFKTNAME.
default_realm Identifie le domaine Kerberos par défaut pour le client. Si non définis, un domaine doit être spécifié avec tout principar Kerberos en invoquant un programme tel que kinit
default_tgs_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un TGS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
default_tkt_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un AS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
dns_canonicalize_hostname Indique si la recherche de noms sera utilisée pour canoniser les noms d'hôte à utiliser dans les nom principal de service. Définis ce flag à false pour améliorer la sécurité en réduisant le dépendance à DNS. Défaut: true.
dns_lookup_kdc Indique si les enregistrements DNS SRV dervaient pour localiser le KDC et d'autre serveurs pour un domaine, s'il ne sont pas listés par krb5.conf. (noter que l'entrée admin_server doit être dans krb5.conf pour pouvoir contacter kadmin, parce que l'implémentation DNS pour kadmin est incomplète).
extra_addresses Permet à un ordinateur d'utiliser plusieurs adresses locales, pour permettre à Kerberos de travailler dans un réseau qui utilise le NAT. Les adresses devraient être listée séparées par une virgule. n'a pas d'effet si noaddresses est à true.
forwardable À true, les tickets initiaux ne seront pas forwardable par défaut, si permis par le KDC. Défaut: false
ignore_acceptor_hostname En acceptant les contextes de sécurité GSSAPI ou krb5 pour les principaux de service basés sur l'hôte, ignore tout nom d'hôte passé par l'application appelante, et permet aux clients d'authentifier tout principal de service dans le keytab correspondant au nom du service et au nom du domaine. peut compromettre la sécurité des environnements d'hôte virtuels. Défaut: false.
k5login_authoritative À true, les principaux doivent listés dans le fichier k5login de l'utilisateur pour avoir un accès login, si un fichier .k5login existe. Si ce flag est à false, un principal peut avoir l'accès login au travers d'autre mécanismes même si un k5login existe mais ne liste pas le principal. Défaut: true.
k5login_directory Si définis, la librairie va rechercher le fichier k5login de l'utilisateur local dans le répertoire spécifié, avec un nom de fichier correspondant au nom de l'utilisateur local. Sinon, recherche un fichier nommé .k5login dans le home de l'utilisateur. Pour des raisons de sécurité, .k5login doit être possédé par l'utilisateur local ou par root.
kdc_req_checksum_type Un entier qui spécifie le type de checksum à utilise pour les demande KDC, pour la compatibilité avec de vieille version de KDC.
noaddresses À true, les demandes pour les tickets initiaux ne seront pas faites avec des jeux de restriction d'adresse, permettant aux tickets d'être utilisés via les NAT. Défaut: true.
permitted_enctypes Identifie tous les types de chiffrement permis pour le chiffrement de clé de session. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
plugin_base_dir Répertoire de base où se trouvent les plugins krb5. Défaut: krb5/plugins
preferred_preauth_types Permet de définir le type de pré-authentification préféré du client. Défaut: "17, 16, 15, 14" qui force libkrb5 à utiliser PKINIT si supporté.
proxiable À true, les tickets initiaux seront mandatables, si permis par le KDC. Défaut: false
rdns À true, la recherche de noms inversée sera utilisée en plus de la recherche de nom pour canoniser les nom d'hôte à utiliser dans les noms de principaux de service. Si dns_canonicalize_hostname est à false, ce flag n'a pas d'effet. défaut: true.
realm_try_domains Indique si les composants de domaine des hôte devraient être utilisés pour déterminer de domaine Kerberos de l'hôte. La valeur de cette variable est un entier: -1 signifie ne pas rechercher, 0 tente le domaine de l'hôte, 1 tente le domaine immédiatement parent, etc. Le mécanisme usuel de la librairie pour localiser les domaines Kerberos est utilisé pour déterminer si un domaine est un domaine valide, qui peut impliquer de consulter DNS si dns_lookup_kdc est mis. Défaut: -1
renew_lifetime Définis la durée de vie de renouvellement pour les demandes de tickets initiaux. Défaut: 0
safe_checksum_type Un entier qui spécifie le type de checksum à utiliser pour les demandes KRB-SAFE. Défaut: 8 (RSA MD5 DES). Ce champ est ignoré quand ça valeur est incompatible avec le type de clé de session.
ticket_lifetime Durée de vie par défaut pour les demandes de tickets initiaux. Défaut: 1 jour
udp_preference_limit En envoyant un message au KDC, la librairie tente d'utiliser TCP avant UDP si la taille du message est supérieur à udp_preference_limit.
verify_ap_req_nofail À true, une tentative de vérifier des accréditifs initiaux va échouer si la machine client n'a pas de keytab. Défaut: false

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section qui définis les propriétés de ce domaine. Pour chaque domaine, les tags suivants peuvent être spécifiés dans la sous-section:

admin_server Identifie l'hôte où le serveur d'administration réside. Typiquement, c'est le serveur maître. Ce tag doit avoir une valeur pour permettre la communication avec le serveur kadmind
auth_to_local Permet de définir un règle générale pour le mappage des noms des principaux aux nom des utilisateurs locaux. Est utilisé s'il n'y a pas de mappage explicite pour le nom principal. Les valeurs possible sont:

        RULE:exp Le nom local sera formulé depuis exp. Le format est [n:string](regexp)s/pattern/replacement/g. L'entier n indique combien de composants le principal cible devrait avoir. Si cela matche, alors un chaîne sera formée depuis string, en substituant le domaine du principal pour $0 et le n-ième composant du principal pour $n ( exemple, si le principal était johndoe/admin alors [2:$2$1foo] va résulter dans la chaîne adminjohndoefoo). Si la chaîne matche regexp, alors la substitution de commande s//[g] ne va jamais parcourir la chaîne. le g optionnel matche toutes les occurences.
        DEFAULT Le nom du principal sera utilisé tel que le nom d'utilisateur. Si le principal a plus d'un composant ou n'est pas le domaine par défaut, cette règle n'est pas applicable et la conversion va échouer.


        Par exemple:
[realms]
    ATHENA.MIT.EDU = {
        auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
        auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//
        auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/
        auto_to_local = DEFAULT
    }

           va résulter en tout principal sans root ou admin comme second composant à traduire avec la règle par défaut. Un principal avec un second composant admin va devenir son premier composant. root sera utilisé comme nom local pour tout principal avec un second composant root. L'exception à ces règles sont tout principal johndoe/* qui sera toujours le nom local guest.

auth_to_local_names Cette sous-section vous permet de définir explicitement des mappages de noms de principaux à des noms locaux. Le tag est le nom mappé, et la valeur est l'utilisateur local
default_domain Ce tag spécifie le domaine utilisé pour étendre les noms d'hôte en traduisant les principaux Kerberos v4 en principaux v5.
kdc Le nom ou l'adresse d'un hôte hébergeant un KDC pour ce domaine. Un numéro de port optionnel peut être inclus. Si le nom ou l'adresse contient des ":", utiliser des crochets pour distinguer le ":" de l'adresse du numéro de port. Pour que la machine puisse communiquer avec le KDC, ce tag doit être donné, ou il doit y avoir des enregistrements DNS SRV.
kpasswd_server Pointe vers le serveur où tous les changements de mot de passe sont effectués. S'il n'y a pas de telles entrées, le port 464 de l'hôte admin_server sera tenté.
master_kdc Identifie le KDC maître. Actuellement, ce tag est utilisé dans un cas: si la tentative d'obtention des accréditifs échoue à cause d'un mot de passe invalide, le client va tenter de contacter le KDC maître, dans le cas où le mot de passe de l'utilisateur vient juste d'être changé.

[domain_realm]

   Cette section fournis une traduction depuis un nom de domaine ou un nom d'hôte en un nom de domaine Kerberos. Le nom du tag peut être un nom d'hôte ou un nom de domaine, où les noms de domaine sont identifiés par un préfixe point (.). La valeur est le nom de domaine Kerberos pour un hôte ou un domaine particulier. Une relation de nom d'hôte fournis implicitement la relation de nom de domaine correspondante, sauf si une relation de nom de domaine explicite est fournie. Le domaine Kerberos peut être identifié soit dans la section realm ou en utilisant les enregistrements DNS SRV. Les noms d'hôte et domaine devraient être en minuscules. Par exemple:

[domain_realm]
    crash.mit.edu = TEST.ATHENA.MIT.EDU
    .dev.mit.edu = TEST.ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

   mappe l'hôte crash.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU. La seconde entrée map tous les hôtes sous le domaine dev.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU sauf l'hôte dev.mit.edu qui est mappé au domaine ATHENA.MIT.EDU.

   Si aucune traduction ne s'applique au nom d'hôte utilisé pour un principal de service pour une demande de ticket de service, la librairie va tenter d'obtenir un référant au domaine approprié depuis le KDC du domaine du client. Si cela échoue, le domaine de l'hôte est considéré être la portion de domaine du nom d'hôte convertit en majuscules, sauf le paramètre realm_try_domains dans la section libdefaults qui force un domaine parent différent à utiliser.

[capaths]

   Pour pouvoir effectuer une authentification inter-domaine directe ( non hiérarchique ), une configuration est nécessaire pour déterminer les chemins d'authentification entre les domaines.

   Un client va utiliser cette section pour trouver le chemin d'authentification entre son domaines et le domaine du serveur. Le serveur va utiliser cette section pour vérifier le chemin d'authentification utilisé par le client, en vérifiant le champ transited.

   Il y a un tag pour chaque domaine client participant, et chaque tag a des sous-tags pour chaque domaine serveur. La valeur des sous-tags est un domaine intermédiaire qui peuvent participer dans l'authentification inter-domaine. Les sous-tags peuvent être répétés s'il y a plus d'un domaine intermédiaire. Une valeur "." signifie que le 2 domaines partagent les clés directement, et aucun intermédiaire ne devrait être autorisé à participer.

   Seul ces entrées qui sont nécessaire dans le client ou le serveur doivent être présent. Un client a besoin d'un tag pour son domaine local avec des sous-tags pour tous les domaines des serveurs auquel il aura besoin de s'authentifier. Un sereur a besoin d'un tag pour chaque domaine des clients qu'il désert, avec un sous-tag pour chaque domaine serveur.

   Par exemple, ANL.GOV, PNL.GOV et NERSC.GOV veulent utiliser le domaine ES.NET comme domaine intermédiaire. ANL a un sous-domaine TEST.ANL.GOV qui va s'authentifier avec NERSC.GOV mais pas PNL.GOV. La section capaths pour les systèmes ANL.GOV ressembleraient à:


[capaths]
    ANL.GOV = {
        TEST.ANL.GOV = .
        PNL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    TEST.ANL.GOV = {
        ANL.GOV = .
    }
    PNL.GOV = {
        ANL.GOV = ES.NET
    }
    NERSC.GOV = {
        ANL.GOV = ES.NET
    }
    ES.NET = {
        ANL.GOV = .
    }

La section capaths du fichier de configuration utilisé dans les systèmes NERSC.GOV ressembleraient à:
    [capaths]
        NERSC.GOV = {
            ANL.GOV = ES.NET
            TEST.ANL.GOV = ES.NET
            TEST.ANL.GOV = ANL.GOV
            PNL.GOV = ES.NET
            ES.NET = .
        }
        ANL.GOV = {
            NERSC.GOV = ES.NET
        }
        PNL.GOV = {
            NERSC.GOV = ES.NET
        }
        ES.NET = {
            NERSC.GOV = .
        }
        TEST.ANL.GOV = {
            NERSC.GOV = ANL.GOV
            NERSC.GOV = ES.NET
        }

   Quand un sous-tag est utilisé plus d'une fois dans un tag, les clients utilisent l'ordre des valeurs pour déterminer le chemin. L'ordre des valeurs n'est pas important pour les serveurs.

[appdefault]

   Chaque tag dans cette section nomme une application Kerberos v5 ou un option qui est utilisé par certaines applications Kerberos v5. La valeur du tag définis le fonctionnement par défaut pour cette application.

par exemple:
[appdefaults]
    telnet = {
        ATHENA.MIT.EDU = {
            option1 = false
        }
    }
    telnet = {
        option1 = true
        option2 = true
    }
    ATHENA.MIT.EDU = {
        option2 = false
    }
    option2 = true

   Les 4 manières présentées de spécifier la valeur d'une option sont affichés dans l'ordre de précédence descendante. Dans cet exemple, si telnet fonctionne dans le domaine EXAMPLE.COM, il devrait, par défaut, avoir option1 et option2 à true. Cependant, un programme telnet dans le domaine ATHENA.MIT.EDU devrait avoir l'option1 à false et option2 à true. Tout autre programme dans ATHENA.MIT.EDU devrait avoir l'option2 à false par défaut. Tout programme fonctionnant dans d'autre domaine devraient avoir option2 à true.

   La liste d'options spécifiable pour chaque application peut être trouvée dans les man des applications.

[plugins]

   Les tags dans cette section peuvent être utilisées pour enregistrer les modules dynamique et pour activer/désactiver les modules. Tous les interface activable n'utilisent pas cette section. Celles qui l'utilise sont documentées ici. Chaque interface pluggable correspond à une sous-section. Toutes les sous-sections supportent les même tags:
   [SECTION]
   [SECTION] name="-" table="paragraphes" imbrication="0"
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront désactivés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront activés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. Chaque valeur est une chaîne sous la forme modulename:pathname. chaque module est enregistré comme module dynamique pour l'interface pluggable. Si pathname n'est pas un chemin absolus, il est considéré relatif à plugin_base_dir.

   Pour les interfaces pluggable où l'ordre des modules est importante, les modules enregistrés avec un tag module viennent en premier, dans l'ordre qu'il sont enregistrés. Si enable_only est utilisé, alors l'ordre de ces tags remplace l'ordre des modules normal.

  Les sections suivantes sont actuellement supportées dans la section plugins.

interface ccselect

   La sous-section ccselect contrôle les modules pour la sélection du cache d'accréditifs dans une collection de cache. En plus des modules dynamique enregistrés, les modules embarqués suivant existent:

        k5identity Utilise un fichier .k5identity dans le home de l'utilisateur pour sélectionner un principal
        realm Utilise le domaine de service pour deviner un cache approprié depuis la collection.

interface pwqual

   Cette sous-section contrôle les modules pour l'interface de qualité de mot de passe, qui est utilisé pour rejeter les mots de passe faibles lors des changements de mot de passe. Les modules embarqués suivant existent pour cette interface:

        dict Vérifie avec un fichier dictionnaire du domaine
        empty Rejète les mots de passe vide
        hesiod Vérifie avec les informations utilisateurs stockés dans Hesiod ( seulement si Kerberos est construit avec le support de Hesiod )
        princ Vérifie avec les composant du nom du principal

interface kadm5_hook

   Fournis des plugins avec des informations sur la création de principaux, la modification, changement de mot de passe et suppression. Cette interface peut être utilisée pour écrire un plugin pour synchroniser Kerberos MIT avec celui de Microsoft.

interface clpreauth et kdcpreauth

   Ces interfaces permettent aux modules de fournir des mécanisme de pré-authentification au client et au KDC. Les modules intégrés suivant existent pour ces interfaces:

        pkinit Implémente le mécanisme de pré-authentification pkinit
        encrypted_challenge Implémente FAST
        encrypted_timestamp Implément le mécanisme de timestamp chiffré

interface hostrealm

   Cette section contrôle les modules pour l'interface host-to-realm, qui affecte le mappage locale des noms d'hôte et le choix du domaine par défaut. Les module intégré suivant existent pour cette interface:

        profile Consulte la section [domain_realm] du profile pour les mappages host-to-realm autoritatifs, et la variable default_realm pour le domaine par défaut.
        dns Recherche les enregistrements DNS pour les mappages et le domaine par défaut. n'opère que si dns_lookup_realm est à true.
        domain Applique de l'heuristique pour les mappages host-to-realm. Implémente la variable realm_try_domains, et utilise le domaine parent en majuscule du nom d'hôte si cela ne produit pas de résultat.

interface localauth

   Contrôle les modules pour l'interface d'autorisation local, qui affecte la relation entre les principaux Kerberos et les comptes système locaux. Les modules intégrés suivant existent pour cette interface:

        default Implémente le type DEFAULT pour les valeurs auth_to_local
        rule Implémente le type RULE pour les valeur auth_to_local
        names Recherche un mappage auth_to_local_names pour le nom du principal
        k5login Autorise un principal à un compte local en accord avec le .k5login du compte
        an2ln Autorise un principal à un compte local si le nom du principal se mappe au nom local

Options PKINIT

   Les options suivante sont spécifique à PKINIT. Ces valeur peuvent être spécifiées dans [libdefaults] comme valeurs globales par défaut, ou dans une sous-section spécifique au domaine, ou peuvent être spécifiés comme valeurs spécifique au domaine dans la section [realms]. Les valeurs spécifique au domaine écrase, n'ajoutent pas à une spécification libdefaults par défaut. L'ordre de recherche est:

1. sous-section spécifique au domaine de [libdefaults]
[libdefaults]
    EXAMPLE.COM = {
        pkinit_anchors = FILE:/usr/local/example.com.crt
    }

2. Valeurs spécifique au domaine dans [realms]
[realms]
    OTHERREALM.ORG = {
        pkinit_anchors = FILE:/usr/local/otherrealm.org.crt
    }

3. Valeur générique dans [libdefaults]
[libdefaults]
    pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

Spécifier les informations d'identité PKINIT

  

FILE:filename[,keyfilename] Cette option est dépendante du contexte.

           Dans pkinit_identity ou pkinit_identities, filename spécifie le nom d'un fichier PEM contenat le certificat de l'utilisateur. Si Keyfilename n'est pas spécifié, la clé privée de l'utilisateur est attendue dans filename.

           Dans pkinit_anchors ou pkinit_pool, filename est assumé être le nom d'un fichier ca-bundle style OpenSSL.

DIR:dirname Cette option est dépendante du contexte.

           Dans pkinit_identity ou pkinit_identities, dirname spécifie un répertoire avec des fichiers .crt et .key.

           Dans pkinit_anchors ou pkinit_pool, dirname est assumé être un répertoire CA hashé style OpenSSL où chaque certificat CA est stocké dans un fichier nommé hash-of-ca-cert.#

PKCS12:filename filename est le nom d'un pkcs#12, contenant le certificat de l'utilisateur en la clé privée.
PKCS11:[module_name=]modname[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] Tous les mots clé sont optionnels. modname spécifie l'emplacement de la librairie PKCS#11. Si une valeur est rencontrée sans mot clé, il est assumé être le modname. Si aucun nom de module n'est spécifié, le défaut est opensc-pkcs11.so. slotid= et/ou token= peuvent être spécifiés pour forcer l'utilisation d'un lecteur de carte ou un token spécifique. certid= et/ou certlabel peuvent être utilisés pour forcer la sélection d'un certificat particulier sur un périphérique.
ENV:envvar envvar spécifie le nom d'une variable d'environnement qui a été définie à une valeur se conformant à une des valeur précédente. Par exemple, ENV:X509_PROXY où la variable d'environnement X509_PROXY a été définie à FILE:/tmp/my_proxy.pem

options krb5.conf pour PKINIT

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_cert_match Spécifie les règles de correspondance que le certificat client doit matcher avant d'être utilisé pour l'authentification PKINIT. Peut être spécifié plusieurs fois. Tous les certificats sont vérifiés avec chaque règle jusqu'à ce qu'un certificat matche. La comparaison de chaîne Issuer et Subject sont des représentations chaîne rfc2253 des valeurs Issuer DN et Subject DN du certificat. La syntaxe de la règle est [relation-operator]component-rule ... où:

        relations-operator peut être soit && signifiant toutes les composantes des règles doivent matcher, ou || signifiant que seul un composant de règle doit matcher. Défaut: &&
        component-rule Peut être un des suivant. Noter qu'il n'y a pas de ponctuation ou d'espace blanc entre les composantes de règle:

                ‹SUBJECT› regular-expression
                ‹ISSUER› regular-expression
                ‹SAN› regular-expression
                ‹EKU› extended-key-usage-list
                ‹KU› key-usage-list

                   extended-key-usage-list est une liste de valeurs Extended Key Usage. Toutes les valeurs dans la liste doivent être présents dans le certificat. Les valeurs sont:

                        pkinit
                        msScLogin
                        clientAuth
                        emailProtection

                   key-usage-list est une liste de valeurs requises Key Usages. Toutes les valeurs dans la liste doivent être présentes dans le certificat. Les valeurs sont:

                        digitalSignature
                        keyEncipherment


                exemple:
pkinit_cert_match = ||‹SUBJECT›.*DoE.*‹SAN›.*@EXAMPLE.COM
pkinit_cert_match = &&‹EKU›msScLogin,clientAuth‹ISSUER›.*DoE.*
pkinit_cert_match = ‹EKU›msScLogin,clientAuth‹KU›digitalSignature

pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le certificat KDC présenté au client doit contenir. (Noter que si le certification du KDC a le pkinit SubjectAlternativeName encodé comme nom Kerberos TGS, la vérification EKU n'est pas nécessaire vu que la CA fournie a certifié cela comme certificat KDC). Les valeurs reconnues sont:

        kpKDC C'est la valeur par défaut et spécifie que le KDC doit avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
        kpServerAuth Un certificat KDC avec le id-kp-serverAuth EKU tel qu'utilisé par Microsoft sera accepté
        none Le certificat du KDC ne sera pas vérifié pour savoir s'il a un EKU acceptable.

pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_identities Spécifie les emplacements à utiliser pour trouver les information d'identité X.509 du client. Peut être spécifié plusieurs fois. Ces valeur ne sont pas utilisées si l'utilisateur spécifie X509_user_identity sur la ligne de commande.
pkinit_kdc_hostname La présence de cette option indique que le client est prêt à accepter un certificat KDC avec un dNSName SAN au lieu de nécessiter de id-pkinit-san comme définis dans la rfc4556. peut être spécifié plusieurs fois.
pkinit_longhorn À true, on parle au KDC Longhorn
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le client pour compléter la validation de la chaîne. Peut être spécifié plusieurs fois.
pkinit_require_crl_checking Vérifie les informations de révocation.
pkinit_revoke Spécifie l'emplacement de la CRL à utiliser pour vérifier les informations de révocations.
pkinit_win2k Spécifie si le domaine cible est supporte l'ancienne version, pré-rfc, de Kerberos
pkinit_win2k_require_binding À true, le KDC cible attendu est patché pour retourner une réponse avec un checksum. Défaut: false

Expansion de paramètres

   De nombreuses variables, telles que default_keytab_name, permettent d'étendre les paramètres:

%{TEMP} Répertoire temporaire
%{uid} User ID réel ou Windows SID
%{euid} User ID effectif ou Windows SID
%{USERID} Idem à %{uid}
%{null} Chaîne vide
%{LIBDIR} Répertoire d'installation des librairies
%{BINDIR} Répertoire d'installation des binaires
%{SBINDIR} Répertoire d'installation des binaires administratifs
%{username} nom de l'utilisateur unix ou user ID effectif
%{APPDATA} (Windows) Roaming application data for current user
%{COMMON_APPDATA} (Windows) Application data for all users
%{LOCAL_APPDATA} (Windows) Local application data for current user
%{SYSTEM} (Windows) Windows system folder
%{WINDOWS} (Windows) Windows folder
%{USERCONFIG} (Windows) Per-user MIT krb5 config file directory
%{COMMONCONFIG} (Windows) Common MIT krb5 config file directory

Exemple de fichier krb5.conf


[libdefaults]
    default_realm = ATHENA.MIT.EDU
    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
    dns_lookup_kdc = true
    dns_lookup_realm = false
    
[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        kdc = kerberos-2.mit.edu:750
        admin_server = kerberos.mit.edu
        master_kdc = kerberos.mit.edu
        default_domain = mit.edu
    }
    EXAMPLE.COM = {
        kdc = kerberos.example.com
        kdc = kerberos-1.example.com
        admin_server = kerberos.example.com
    }
    
[domain_realm]
    .mit.edu = ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU
    
[capaths]
    ATHENA.MIT.EDU = {
         EXAMPLE.COM = .
    }
    EXAMPLE.COM = {
         ATHENA.MIT.EDU = .
    }

^
26 juin 2014

htmlpdflatexmanmd




krb5kdc

krb5kdc

Service d'authentification Kerberos et centre de distribution des clés

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom sous lequel la base principale peut être trouvée. Ne s'applique pas aux base LDAP
-k keytype Spécifie le type de clé de la clé maître.
-M mkeyname Spécifie le nom du principal pour la clé maître dans la base.
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-n  Spécifie que le KDC ne se place pas en tâche de fond.
-P pid_file PID du service
-p portnum Numéros de port UDP d'écoute. Liste séparé par "," Défaut 88,750
-w numworkers Fork le nombre de processus spécifié pour écouter et traiter en parallèle. Le processus parent agit comme superviseur et relai les signaux SIGHUP.

   Note: Sur les OS qui supportent pktinfo, utiliser les sous-processus empêche de KDC d'écouter les paquets UDP sur les interfaces créés après que le KDC ait démarré.

-x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
-x host=ldapuri Spécifie le serveur LDAP à contacter
-x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
-x bindpwd=bind_password Mot de passe du binddn
-x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
-T offset Spécifie un offset de temps, en secondes, pendant lequel le KDC va opérer.

Exemples

   Le KDC peut désservir jusqu'à 32 domaines. Les domaines sont listés sur la ligne de commande, les options par domaine peuvent être spécifiés avant chaque domaine:

  krb5kdc -p 2001 -r REALM1 -p 2002 -r REALM2 -r REALM3

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
^
01 janvier 2014

htmlpdflatexmanmd




kstartupconfig

kstartupconfig

Permet de charger des options de configuration dans startkde sans nécessiter de lancer quelque chose de lié aux librairies KDE.

   Les options de configuration sont écris dans $KDEHOME/share/config/startupconfigkeys, un option par ligne au format ‹file› ‹group› ‹key› ‹default›. Les valeurs de ces options seront écrites dans $KDEHOME/share/config/startupconfig en tant que script shell. ex: "ksplashrc KSplash Theme Default" donnera "ksplashrc_ksplash_theme=Default".

   Kstartupconfig stocke chaque ligne de startupconfigkeys dans startupconfigfiles suivi par les paths pour tous les fichiers présents dans les options. Les fichiers non existant sont précédés par un !. La liste des fichiers est terminée par une ligne contenant "*" Si les timestamps de tous les fichiers sont plus récent que le timestamp du fichier startupconfigfile, kdostartupconfig est lancé pour créer ou mettre à jours tous les fichiers nécessaires (nécessite les librairies KDE, mais ce cas est rare)

^
30 juin 2014

htmlpdflatexmanmd




ksu

ksu

Version kerberisé de su

   ksu est une version Kerberisé du programme su qui a 2 objectifs: sécuriser les changements d'ID d'utilisateur réel et effctifs, et de pouvoir créer de nouveaux contextes de sécurité.

Authentification

   ksu opère en 2 phases: l'authentification et l'autorisation. Résoudre le nom du principal de la cible est la première étape de l'authentification. L'utilisateur peut soit spécifier sont nom de principal avec -n, ou un nom de principal par défaut sera assigné en utilisant l'heuristique. Le nom de l'utilisateur cible doit être le premier argument du ksu; si non spécifié, root est le défaut. Si . est spécifié, l'utilisateur cible sera l'utilisateur source, Si l'utilisateur source est root ou l'utilisateur cible est l'utilisateur source, aucune authentification est aucune autorisation ne sera effectuée. Sinon, ksu recherche un ticket Kerberos approprié dans le cache de la source.

   Ce ticket peut être soit pour un serveur final, ou un TGT pour le domaine du principal cible. Si le ticket pour le serveur final est déjà dans le cache, il est déchiffré et vérifié. S'il n'est pas dans le cache mais que le TGT l'est, le TGT est utilisé pour obtenir le ticket. Si aucun de cet tickets n'est présent, et ksu est compilé avec GET_TGT_VIA_PASSWD, l'utilisateur devra entrer son mot de passe qui sera ensuite utilisé pour obtenir un TGT. Si l'utilisateur est loggé à distance et n'a pas de canal sécure, le mot de passe peut être exposé. Si ni le ticket ni GET_TGT_VIA_PASSWD ne sont présent, l'authentification échoue.

Autorisation

   Cette section décris l'autorisation de l'utilisateur source quand ksu est appelé sans l'option -e.Une fois l'authentification réussie, ksu vérifie que le principal cible est autorisé pou accéder au compte cible. Dans le home de l'utilisateur cible, ksu tente d'accéder à .k5login et .k5users Pour vérifier les autorisations.

   Si le nom du principal cible est trouvé dans le .k5login, l'utilisateur source, est autorisé à accéder au compte cible. Sinon, ksu recherche le fichier .k5users. Si le nom de principal cible est trouvé sans commandes ou suivi uniquement par *, l'utilisateur source est autorisé. Si les 2 fichiers ne sont trouvés mais qu'aucune entrée appropriée pour le principal cible n'existe, l'accès est refusé. Si les 2 fichiers n'existent pas le principal aura accès au compte en accord avec la règle de mappage aname-›lname. Sinon l'autorisation échoue.

Exécution du shell cible

   Une fois l'autorisation réussie, ksu se comporte comme su. L'environnement n'est pas modifié sauf USER, HOME, et SHELL. Si l'utilisateur cible n'est pas root, USER est l'utilisateur cible. Sinon USER reste inchangé. La variable d'environnement KRB5CCNAME est définie au nom du cache de la cible. L'ID utilisateur réel et effectif sont changés à l'utilisateur cible. Une fois le shell terminé, ksu supprime le cache cible, sauf si -k.

Créer un nouveau contexte de sécurité

   ksu peut être utilisé pour créer un nouveau contexte de sécurité pour le programme cible ( soit le shell, soit la commande spécifiée avec -e). Le programme cible hérite d'un jeu d'accréditifs de l'utilisateur source. Par défaut, ce jeu inclue tous les accréditifs dans le cache source, plus tout type d'accréditifs obtenus durant l'authentification. L'utilisateur source est capable de limiter les accréditifs dans le jeu avec les options -z ou -Z. -z restreins la copie des tickets du cache source dans le cache cible aux seuls tickets où le client == le nom principal cible. -Z fournis à l'utilisateur cible un cache neuf, sans accréditifs. Noter que pour des raisons de sécurité, quand l'utilisateur source est root et l'utilisateur cible non-root, -z est le mode par défaut.

   Note: durant l'authentification, seul les tickets qui pourraient être obtenus sans fournir de mot de passe sont cachés dans le cache source.

OPTIONS

-n target_principal_name Spécifie un nom de principal cible. non spécifié, un nom de principal par défaut est assigné via les cas suivant:

        Cas 1: l'utilisateur source est non-root Si l'utilisateur cible est l'utilisateur source, le nom de principal par défaut est définis au principal par défaut du cache source. Si le cache n'existe pas, le nom de principal par défaut est target_user@local_realm. Si les utilisateurs source et cible sont différent et que .k5users et .k5login n'existent pas, le nom de principal est target_user_login_name@local_realm. Sinon, en commençant avec le premier principal listé ci-dessous, ksu vérifie si le principal est autorisé à accéder au compte cible et s'il y a un ticket pour ce principal dans le cache source.

                a. Principal par défaut du cache source
                b. target_user@local_realm
                c. source_user@local_realm

        Cas 2: l'utilisateur source est root Si l'utilisateur cible est non-root, le nom de principal par défaut est target_user@local_realm. Sinon, si le cache source existe, le nom est un principal par défaut du cache source. Si le cache source n'existe pas, le nom est root\@local_realm.

-c source_cache_name Spécifie le nom du cache source. Non spécifié, utilise KRB5CCNAME, ou définis à krb5cc_‹target uid›.(gen_sym()).
-k Ne supprime pas le cache cible à la sortie du shell ou de la commande.
-d mode debug
-z Restreins la copie de tickets du cache source dans le cache cible aux seuls tickets où client==le nom du principal cible.
-Z Ne copie aucun tickets du cache source dans le cache cible.
-q mode silencieux
-l lifetime (chaîne time_duration) Spécifie la durée de vie pour les tickets demandés. défaut 12 heures.
-r time (chaîne time_duration) spécifie l'option renewable à demander pour les tickets.
-p Spécifie que l'option proxiable devrait être demandé pour le ticket
-f Spécifie que l'option forwardable devrait être demandé pour le ticket
-e command [args ...] Exécute la commande spécifiée au lieu d'exécuter le shell cible.

           Le fichier .k5users a le format suivant: Une seul entrée par ligne qui peut être suivie par une liste de commandes que le principal est autorisé à exécuter. Un nom de principal suivi par un * signifie que l'utilisateur est autorisé à exécuter une commande. Ainsi, l'exemple suivant:

                jqpublic@USC.EDU ls mail /local/kerberos/klist
                jqpublic/secure@USC.EDU *
                jqpublic/admin@USC.EDU

           La première ligne autorise à exécuter ls, mail et klist. La deuxième ligne autorise à exécuter toute commande, et la troisième autorise uniquement à exécuter le shell cible, tout comme la deuxième ligne, mais pas la première.

-a args Spécifie les arguments à passer au shell cible. cette option peut être utilisé pour simuler l'option -e avec: -a -c[command [arguments]].

Instructions d'installation

   ksu peut être compilé avec les flags suivant:

GET_TGT_VIA_PASSWD Si aucun ticket approprié n'est trouvé dans le cache source, demande à l'utilisateur son mot de passe.
PRINC_LOOK_AHEAD Durant la résolution du nom de principal par défaut, permet à ksu de trouver les noms des principaux dans le fichier .k5users.
CMD_PATH Spécifie une liste de répertoires contenant les programmes que les utilisateur sont autorisés à exécuter (via le fichier .k5users)
HAVE_GETUSERSHELL Si l'utilisateur source est non-root, ksu insiste pour que le shell de l'utilisateur invoqué soit un shell légal.

   ksu devrait être possédé par root et avoir le set user bit mis.
^
30 juin 2014

htmlpdflatexmanmd




kswitch

kswitch

Spécifier le cache primaire dans une collection

OPTIONS

-c cachename Spécifie le cache d'accréditifs à rendre primaire
-p principal Recherche un cache contenant des accréditifs pour le principal, dans la collection.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
27 juin 2014

htmlpdflatexmanmd




ktutil

ktutil

Utilitaire de gestion de fichiers keytab

Commandes

list Affiche la keylist courante. Alias: l
read_kt keytab Lit le keytab Kerberos v5 dans la keylist courante. Alias: rkt
read_st srvtab Lis le srvtab Kerberos v4 dans la keylist courante. Alias: rst
write_kt keytab Écrit la keylist courant dans le keytab. Alias: wkt
write_st srvtab Écrit la keylist courant dans le srvtab. Alias: wst
clear_list Efface le keylist courante. Alias: clear
delete_entry supprime l'entrée dans le numéro de slot de la keylist courante. Alias: delent
add_entry {-key|-password} -p principal -k kvno -e enctype Ajoute un principal dans la keylist en utilisant une clé ou un mot de passe. Alias: addent
list_requests Affiche une liste des commande disponibles. Alias: lr,?
quit quitte. Alias: exit,q

Exemples


ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
    aes128-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
    aes256-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: write_kt keytab
ktutil:

^
30 juin 2014

htmlpdflatexmanmd




kvno

kvno

Acquière un ticket de service pour les principaux spécifiés et affiche les numéros de version de clé pour chaque.

OPTIONS

-c ccache Spécifie le nom du cache d'accréditifs à utiliser
-e etype Spécifie le enctype à demander pour la clé de session de tous les services nommés.
-q Mode silencieux en cas de réussite.
-P Spécifie que les arguments service1 service2 ... sont interprétés comme noms d'hôte, et les principaux de service sont à construire depuis ces nom et le nom de service sname. Les noms d'hôte de service seront canonisés en accord avec les règles pour construire les principaux de service.
-U for_user Spécifie que S4U2Self est utilisé pour obtenir un ticket pour for_user. Si la délégation de contraintes n'est pas requise, le nom de service doit matcher le cache d'accréditifs du principal du client.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
28 mars 2016

htmlpdflatexmanmd




kxc

kxc

Client d'échange de clé

   kxc est le client pour kxd. Il prend une clé et un certificat client, le certificat du serveur et une URL (ex: kxd://server/host1/key1), et affiche sur stdout la clé retournée. Il y a un script pour ouvrir des périphérique cryptsetup automatiquement: kxc-cryptsetup.

OPTIONS

--client_key=‹file› Fichier contenant la clé privée du client
--client_cert=‹file› Certificat du client
--server_cert=‹file› Certificats du serveur
^
28 mars 2016

htmlpdflatexmanmd




kxc-cryptsetup

kxc-cryptsetup

wrapper cryptsetup pour kxc

   kxc-cryptsetup est un wrapper pour invoquer kxc tout en prenant les options des fichiers dans /etc/kxc/. Il peut être utilisé comme script de clé cryptsetup, pour automatiquement obtenir les clé pour ouvrir des périphériques kxc.

^
28 mars 2016

htmlpdflatexmanmd




kxd

kxd

Service d'échange de clé

   kxd est un service d'échange de clé, qui dessert des clé sur https. Il peut être utilisé pour obtenir des clé à distance au lieu d'utiliser un stockage local. Son utilisation principale est d'obtenir des clé pour ouvrir des périphériques dm-crypt automatiquement, sans avoir à stocker les clé sur la machine locale. Sa configuration est stockée dans /etc/kxd/data, dans lequel il y a un répertoire pas clé (ex: /etc/kxd, data, host1/key1/), chacun contenant les fichiers suivants:

key Contient la clé à donner au client
allowed_clients Contient un ou plusieurs certificats PEM clients autorisés à demander la clé
allowed_hosts Contient un ou plusieurs noms d'hôte (un par ligne)
email_to Un ou plusieurs email de destination pour les notifications (un par ligne)

OPTIONS

--key=‹file› clé privée à utiliser. Défaut: /etc/kxd/key.pem
--cert=‹file› Certificat à utiliser. Défaut: /etc/kxd/cert.pem
--data_dir=‹directory› Répertoire des données. Défaut: /etc/kxd/data
email_from=‹email-address› Adresse email de l'émetteur pour l'envoie des emails
--ip_addr=‹ip-address› Adresse IP d'écoute. Défaut: 0.0.0.0
--logfile=‹file› Fichier de log. '-' pour stdout. Défaut: utilise syslog
--port=‹port› Port d'écoute. Défaut: 19840
--smtp_addr=‹host:port› Addresse du serveur smtp
^
10 octobre 2011

htmlpdflatexmanmd




La Compression

La Compression

l'effet compression

   La compression est généralement utilisée pour réduire la dynamique du signal audio. Pourquoi est-il nécessaire d'appliquer un tel traitement? Contrairement à l'oreille humaine, la reproduction des sons est limitée par la technologie. Ainsi, alors que l'oreille humaine présente une flexibilité/plage dynamique étonnante, vous permettant d'entendre successivement le bruit d'une goutte d'eau puis celui d'un avion au décollage. La plage dynamique de l'oreille humaine (de très faible à très fort) est de l'ordre du rapport d'un milliard pour un. Par exemple la puissance d'un son tel que le réacteur d'un jet est un milliard de fois plus élevé que celle du son des molécules de l'air frappant le tympan humain.

   N'importe quel reproduction de son qui dépend de l'électronique sera loin d'épouser la plage dynamique de notre oreille, limitée vers le bas par le bruit de fond intrinsèque du système et limitée vers la haut par l'écrêtage (distorsion) . Ces contraintes physiques rendent cette flexibilité impossible à obtenir dans un dispositif de reproduction audio.

   Pour ce qui est de la limite inférieure, le niveau du signal doit être plus élevé que celui d'un niveau plancher ou "bruit de fond", généré par les composants électroniques. La limite supérieur est quand à elle déterminée par les tensions internes tolérées par les composants. Si cette règle n'est pas respectée, une distorsion apparaît. Il est par ailleurs nécessaire de conserver une certaine réserve dynamique en prévision des crêtes du signal, même si cela doit limiter la plage dynamique. On cherche donc à ménager une réserve dynamique importante, tout en évitant que le niveau moyen du signal ne s'approche trop du niveau du bruit de fond. C'est là le rôle de la compression. Le compresseur vous permet de contrôler/réduire les crêtes du signal et de rehausser le niveau moyen.

   Faire passer un signal audio dans n'importe quel circuit électronique produit un bruit de fond (souvent une quantité très infime), le but et ainsi d' optimiser la balance entre le signal "pur" et le bruit de fond. Le compresseur (ou, dans sa forme la plus radicale, le limiteur) est probablement l'outil le plus communément utilisé dans le contrôle de la dynamique. En termes simples, le compresseur est destiné à limiter la dynamique sonore pour, par exemple, relever les signaux faibles et atténuer les signaux forts.

Les avantages pratiques du compresseur

- une protection des haut-parleur, étant donné que le compresseur limitera les crêtes musicales excessives
- un niveau sonore plus homogène et un plus 'gros' son (plus de 'punch'), puisque l'atténuation des crêtes permet au reste du signal de bénéficier d'un niveau moyen plus élevé
- plus de gain et de consistance dans les composantes du mix.

Les effets secondaires du compresseur

- le bruit, quand le seuil est réglé trop bas et le gain élevé pour réajuster le niveau, le bruit de fond devient ainsi plus fort, dans ce cas il faut utiliser un noise gate.
- l'effet de 'pompage', quand le temps de rétablissement du compresseur est trop long, il s'ensuit une crête dans les signaux faibles qui disparaissent ou diminuent avec le release..
- l'effet 'breathing' (respiration), quand le ratio est trop élevé, le seuil trop bas, et le release time trop court, le bruit de fond va moduler de haut en bas..
- l'over-compression : appliquer trop de compression à un mix, un manque de dynamique et un son plat, sans 'vie' en résulte. Les variations de dynamique d'une musique sont une composante importante, ne les enlevez pas, il faut juste les contrôler.

   Les premiers types de compresseurs sont apparus dans les années 30'; ceux-ci étaient d'une conception très simple et proposaient le réglage de deux paramètres. A l'aide de la première de ces deux commandes, l'utilisateur devait définir un réglage basé sur le niveau estimé du signal à traiter. La seconde commande (taux) déterminait la réduction de dynamique à appliquer sur l'ensemble du signal transmis au compresseur. De cette manière, le processus de compression traitait les deux extrêmes du signal: le gain appliqué aux signaux les plus faibles était le même que celui retranché aux signaux les plus élevés.

   Les compresseurs modernes prennent également en compte un point de seuil. Lorsque le niveau du signal dépasse le niveau du seuil, le compresseur commence à réduire le niveau du signal de sortie avec un taux déterminé par le paramètre Ratio. Une fois le signal passé sous le niveau du seuil, le compresseur cesse le traitement.

Distinction compresseurs/limiteurs

   Un compresseur sert essentiellement à réduire progressivement la dynamique du signal au-delà du point fixé comme seuil ; le limiteur sert quant à lui à éviter que le signal ne dépasse une limite fixée. Les compresseurs et les limiteurs sont souvent utilisés de manière conjointe : le compresseur applique ainsi une réduction harmonieuse/douce du niveau alors que le limiteur évite tout écrêtage/distorsion de manière plus radicale.

Compresseur Limiteur (ratio ∞:1)
   On recourt généralement à un compresseur pour réduire la dynamique et avoir un meilleur contrôle du signal. Il existe cependant plusieurs approches de la compression : plusieurs situations de départ et éventuellement plusieurs objectifs, dont la nature varie selon les applications. Il est d'autant plus difficile de donner des réponses universelles sur la manière d'appliquer la compression tant la touche personnelle a d'importance. Les paragraphes suivants vous présentent néanmoins quelques lignes directrices:

   Voici tout d'abord une brève description des paramètres fondamentaux intervenant dans la compression:

Threshold (seuil): Le compresseur est activé lorsque le signal franchit le niveau du seuil Ratio
(taux): Ce réglage détermine le taux avec lequel la compression est appliquée au signal. Il est exprimé en rapport à 1dB. Ainsi, pour un ratio de 1:1, une augmentation du niveau du signal de 1dB au dessus du seuil en entrée résultera d'une augmentation du niveau de 1dB au dessus du seuil en sortie, vous aurez compris ici qu'aucune compression n'est appliquée. Par contre, avec un ratio de 4:1, une augmentation du niveau de 4dB au dessus du seuil en entrée résultera d'une augmentation de seulement 1dB en sortie. à un ratio élevé (au delà de 20:1) vous obtenez un limiter, et à un ratio de infini:1, il faut une agmentation infinie en entrée pour obtenir 1dB en sortie, dons le limiter est maximal, rien ne passe au dessus du seuil. Certains compresseur comme le plug-in Waves C1, permet des ratio inférieur à 1:1 et descendent jusqu'à 0.5:1 ce qui devient un expander, l'inverse du compresseur.
Attack (attaque): L'attaque correspond au temps de réaction du compresseur. Plus le temps d'attack est court, plus le compresseur se déclenche vite lorsque le signal franchi le seuil
Release retablissement): Le release détermine le temps nécessaire au compresseur pour cesser d'appliquer la réduction du gain après que le signal soit repassé sous le niveau du seuil.

Soft knee et Hard knee

   Sur un graphe on voit très bien comment réagit le compresseur. les niveaux d'entrée se situent sur l'axe horizontal, et les niveau de sortie, sur l'axe verticale. Le graphe permet ainsi de visualiser la relation niveau d'entrée/sortie. Grâce à ce graphe on peut facilement voir et comprendre le type de courbe utilisé pour la réduction du gain.

Pente Hard Knee Pente Soft Knee
   Nous avons vu que la compression d'active dès que le seuil est franchi. La plupart des compresseurs fonctionnent en mode hard knee (pente dure), ici le ratio est appliqué immédiatement après que le seuil soit franchi, ce qui donne une compression très efficace, mais peut être audible à ratio élevé. La compression soft knee (pente douce) utilise une courbe de transition entre le niveau non compressé (au dessous du seuil) et le signal compressé ( au-dessus du seuil). L'attaque du compresseur s'en trouve plus doux, le son devient plus naturel, mais manque d'efficacité sur des temps d'attaque très court. Ici, le threshold, se trouve au milieu de la courbe de transition. La dureté de la courbe dépend des compresseurs. Les compresseurs Behringer (Autocomp pro et composer pro), ont un system de pente adaptative en fonction du signal (l'attack et le release peuvent l'être également), pour combiner les avantages du soft knee et du hard knee, le Wave C1 utilise une pente un peu plus dure que les soft knee classiques, et les module Sabines (Graphi-Q, power-Q, Real-Q2) ont un réglage qui permet de régler la courbe, allant du hard knee à un soft knee très large et les réglages vont jusqu'à 40dB de plage entre le début et la fin de la courbe.

Les différents types de compression

La compression large bande: c'est le mode de fonctionnement des compresseurs conventionnels. La compression s'applique au signal dès que celui-ci franchi le seuil. Les réglages de seuil, du ratio, de l'attack et du release sont appliqués sur la totalité du spectre.
La compression multibandes: vous permet d'appliquer des compressions indépendantes sur les différentes plages de fréquences du signal. Le signal audio est ainsi partagé en plusieurs bandes de fréquences, ce qui vous permet d'obtenir de bien meilleurs résultats lorsque vous travaillez avec un signal complexe couvrant un spectre relativement large. Lorsque vous utilisez un compresseur non multibande, avec une grosse caisse par exemple, ce dernier réduit la dynamique de l'ensemble du signal. Ce type de traitement génère ce qu'il est courant d'appeler un effet de "pompage". Grâce au partage du signal en trois bandes de fréquences (grave, médium et aiguë) sur les modules TC-Electronic (Triple-C, Finalyzer) et à la possibilité d'utiliser des réglages du seuil et du ratio différents sur chacune de ces bandes, la compression est largement optimisée. Certains compresseur multibandes séparent le signal sur six bandes comme les Behringer ultra-dyne dsp-9024, avec un limiter séparé, ou encore sur 4 bandes (Waves C4).

   Il existe d'autre modes de compression, comme le mode enveloppe, présent sur le module TC-Electronic Triple-C, qui utilise une enveloppe ADSR. vous aurez remarqué que les compresseur classiques utilisent une enveloppe AD (Attack Release) et parfois ADS (Sustain, plus souvent appelé Hold), son fonctionnement reste toutefois différent : Un gain d'attaque est appliqué (sur une durée fixe de 1ms) au signal lorsque celui-ci franchit le seuil, puis l'attack règle le temps mis par le compresseur pour ramener le signal en dessous du seuil. Ensuite il est maintenu au niveau du seuil ( Sustain). Le temps de release complété d'un gain de release définissent la façon dont la compression de termine une fois le signal repassé en dessous du seuil.

   Le plug-in Waves C1, lui utilise un mode de compression par filtrage. Le signal sidechain est filtré à l'aide de 4 filtres au choix (Band-pass, Hi-pass, Low-pass, Band-reject), afin de cibler une plage de fréquence qui va contrôler la compression, ce qui permet de multiple application, tel qu'un égaliseur dynamique, un dé-esseur, etc...

   Il existe en fonction des compresseurs, différents paramètres supplémentaires:

Sidechain: le Sidechain est un signal qui contrôle la compression d'un autre signal. Généralement, le signal d'entrée est séparé en 2, l'un sert de contrôleur, l'autre est le signal traité, cela permet de cibler une plage de fréquence comme le plug-in Waves C1, ou encore le Tc-Electronic Triple-C à l'aide d'un égaliseur externe. Le C1 permet, en mode stéréo, d'utiliser un canal pour commander l'autre.
Lookahead: C'est un délai à anticipation qui permet d'optimiser la compression appliqué en analysant le signal avant de lui appliquer le traitement. Les résultats sont excellent, mais un décalage non négligeable est crée, de 3ms, sur le Triple-C, et jusqu'à 7,5 ms sur le C1
Hold (maintient): Détermine le temps minimum pendant lequel la compression est appliquée, même si le signal repasse au dessous du seuil.
Gain (ou Level): La compression diminuant la dynamique, il en résulte une perte de puissance du signal en sortie, il est souvent nécessaire de rehausser le niveau.
Soft lim: Les compresseur et les limiter fonctionnent souvent de manière conjointe, certain compresseur possèdent un limiter séparé comme le Triple-C ,le Behringer Ultra-dyne dsp9024 ou encore les modules Sabine, qui permet de stopper les crêtes trop importantes, et sources de distorsions harmoniques.
Low/ Peak: Les compresseur standard utilisent la tension efficace(RMS) pour contrôler de la réduction du gain ; le mode peak permet d'utiliser les crêtes pour commander la compression, ce qui est particulièrement adapté aux signaux percussifs

   Attention certain compresseur fonctionnent encore comme les premiers compresseur, les deux extrêmes du signal sont traités : le gain appliqué aux signaux faibles est le même que celui retranché au signaux les plus élevés. C'est le cas du compresseur du Korg Triton, et de la plupart des compresseurs pour guitare électrique afin d'ajouter du sustain au son comme le Boss CS-3 compressor sustainer. le taux de compression se fait à l'aide un paramètre unique de sensibilité, le temps d'attack est également présent, un petit égaliseur est parfois présent. Le Korg Triton permet de régler le niveau d'entrée de l'égaliseur, et possède un gain pour l'atténuation/augmentation des basses et hautes fréquences en entrée. Un mix entre le signal traité (wet) et le signal non traité (dry) est ajouté et peut être, comme le gain de sortie, commandé par un modulateur dynamique (amt).

Compresser la guitare

   Les compresseurs sont utilises pour réduire la dynamique d'un signal. Comment ce traitement peut il améliorer le son de votre guitare ? Il est des situations dans lesquelles il vaut mieux ne pas appliquer de compression sur le signal de guitare. En revanche il en est d'autres dans lesquelles ce traitement est indispensable pour faire ressortir le son de votre guitare et lui conférer davantage de puissance. Voici quelques exemples illustrant ce point de vue :

   Supposons que vous souhaitiez jouer une rythmique répétitive en son clair, toujours au même niveau ; c'est pratiquement impossible. Il arrive toujours que certaines notes soient jouées trop fort. A la suite de quoi l'ingénieur du son réduit légèrement le niveau sur les voies des guitares pour ne pas laisser passer de trop fortes crêtes de signal. A ce niveau général "réduit" (auquel ni vous ni l'ingénieur du son ne souhaitiez arriver au départ), les notes les moins fortes disparaissent complètement. Le compresseur constitue dans ce cas une solution au problème. Une atténuation judicieuse des crêtes du signal permet a vous et a l'ingénieur du son de travailler avec un niveau de la guitare beaucoup plus homogène.

   Vous pouvez également appliquer une compression sur une guitare Lead pour en tempérer les variations de niveau. La combinaison d'un réglage de seuil assez bas (laissant le compresseur travailler constamment) et d'un taux élevé vous permet d'obtenir un effet de compression très marque. A titre d'exemple, écoutez le fameux solo de David Gilmour dans le morceau "Another Brick In The Wall" de l'album "The Wall"

   Cependant si votre style de jeu nécessite une bonne dose de dynamique (le style de jeu caractéristique de Robben Fords, par exemple), il est sans doute préférable de ne pas appliquer de compression du tout.

   De nombreux effets et en particulier le compresseur sont particulièrement avantageux ; attention toutefois, de mauvais réglages peuvent dénaturer votre jeu

Les différents compresseur

   Il existe des tas de compresseur sur le marché, sous la forme de plug-ins (Waves C1, C4,C360,RCL) à intégrer dans un séquenceur, sous la forme de module entièrement ou partiellement dédié à la compression, et enfin, les multi-effets intègrent tous un compresseur.

Wave C1
   Tous les compresseurs n'ont pas le même but, certain sont prévus pour la scene comme les compressions inclues dans les modules de Sabine graphi-Q (égaliseur 31 bandes numerique, compresseur/limiter, anti-larsen et retard numérique du signal), le power-Q (analyser real time, correcteur graphique,anti-larsen fbx, correcteur paramétrique, compresseur/limiter, noise gate/expander) et le real-Q2 ().

dbx 226 XL
Sabine Power-Q
   Certain compresseurs sont adaptés aux guitares électrique pour des riffs puissant, c'est le cas du boss CS-3, du Danelectro surf & truf compressor, du Marshall BB2, du Digitech KXP, pour ce qui est des petites pédales, et bien évidement touts les multieffets pour guitares et guitares basse intègrent un compresseur.

  D'autres compresseurs sont plus généralistes, comme le Behringer MDX 2200 et 2600 composer pro, le mdx-1600 autocomp pro, ou le Tc-Electronic Triple-C.

Tc Electronic Triple-C
   Certain compresseur sont numériques, d'autre analogique, et certain intègrent même une lampes qui donne de la "chaleur" au son, comme les opto-compresseur, qui possède un circuit de détection doté de résistance sensibles à la lumière (AVALON AD2044, tout simplement le meilleur de la compression à lampe !).

Le fameux Avalon AD2044 …
   Beaucoup de modules sont couplés à d'autres effets, pour plus d'efficacité, le MindPrint DTC est un préampli/ compresseur à lampe.

  Pour résumer la compression est un effet qui est très important, et que l'on a tendance à oublier à tort. Le compresseur n'est pas pour autant aussi simple à régler, il doit être subtile, discret, voir inaudible, ce qui le rend encore plus difficile à paramétrer, mais tout bon compresseur numérique possède des presets adaptés à pas mal de situations et qui fournissent une base très efficace pour vos propres paramètres. Faites des essais avec vos compresseur, plug-ins ou multi-effects ne vous apporterons pas la même compression, ce qui permettra de comparer, et de comprendre l'effet en application.
^
11 octobre 2011

htmlpdflatexmanmd




La Réverbération

La Réverbération

l'effet réverbération

   Tout le monde connaît ce phénomène du son qui se réfléchit sur les parois. Dans les églises le phénomène est très accentué.

Qu'est ce que la réverbération

   Le son est une excitation des particules d'un milieu, émit par un source en mouvement ou en vibration et se propage dans ce milieu, de particule à particule, en cercle concentrique, et s'étend ainsi dans tout le milieu. En gros, pour qu'un son ait lieu, il faut une source sonore, dans un milieu (ici on ne considérera que l'air). Cette source sonore va émettre des vibrations, qui vont se propager dans l'air. Lorsqu'un onde va 'percuter' un mur, une partie de son énergie va être absorbées par le mur, et le reste va être renvoyée dans la pièce, c'est la réverbération. La réverbération est la somme de toutes les ondes sonores se propageant dans une pièce, qui ont percuté au moins une fois un mur (ou encore le plafond ou le sol, ou tout autre obstacle). L'onde qui part directement de la source s'appelle le son directe, l'onde qui est percutée et renvoyée dans la pièce s'appelle la réflexion. A mesure que les ondes se réfléchissent, leurs intensité diminue fortement, et le son devient très diffus.

Les notions a retenir

   Il faut retenir 3 évènements : Le son directe, c'est le son que produit la source sonore, il se propage dans l'air, depuis cette source et dans toutes les directions, jusqu'a ce qu'il rencontre un obstacle, un mur par exemple. Le son est réfléchi, mais avec moins d'intensité, dut aux propriétés d'absorptions sonore des murs, il s'agit du son réverbéré. Cette réflexion n'est évidement pas la seule, puisque les ondes sonore se propagent jusqu'a ce qu'elles soient totalement absorbées, les ondes sonores se reflechissent à nouveau un certain nombre de fois sur les murs (et autres obstacles évidements), et le son devient de plus en plus diffus. La fin de la reverb est donc un son diffus très caractéristique.

   Les premières réflexions sont séparées de la reverb parce que elles ont, de par leur précocité, une intensité assez élevée et non diffus, ce qui permet à notre oreille de percevoir une notion d'espace, la taille de la pièce, le type de pièce (murs en pierre, en bois), etc. Elle sont donc très importantes. La reverb, il s'agit des dernières réflexions, qui ont perdu beaucoup d'intensité et d'informations, et l'oreille ne les interprète plus comme des ondes réfléchit, mais comme un son diffus, qui donnent des informations sur la taille de la pièce. Notez que les premières réflexions ne concernent que les petits espaces, les grand espaces et en extérieur ne contiennent que peut de ces premières réflexions, celles-ci étant généralement localise entre les 50 et 200 premières ms suivant la taille de la pièce.

Paramétrer un réverbération

   Il existe beaucoup de reverb différentes, hardware et software, de 3 ou 4 réglages pour une pédale guitare (Boss RV-5, Digitech XDV), jusqu'a la monstrueuse M3000 de TC Electronics avec ses 33 paramètres..., en passant par les reverb à ressort, quasi disparues et très recherchées aujourd'hui, les merveilles Lexicon (PCM 91), les reverb multicanals (Lexicon 960 L, TC Electronics M6000, Waves 360' Reverb, Kind of Loud DreamVerb), etc. Des plus classiques jusqu'aux émulateurs de pièce en 3 dimensions, toutes proposent leur technologies et leur couleurs.

   La plupart des reverbs possèdent trois réglages principaux : Direct, Pre-Delay, DecayTime. Le premier évidemment permet de régler le niveau du signal original, certain le proposent sous la forme de réglage Wet/Dry. Le Pre-delay règle le temps avant que commence la reverb. Le DecayTime règle le temps de la fin de la reverb, pour être plus précis, le temps que met la reverb à être un million de fois plus faible, en gros à diminuer de 60 dB.

   Les réglages peuvent être plus nombreux, mais de telles reverb sont ainsi plus longue et plus difficiles à régler, cela dit le résultat est évidemment un cran en dessus. Sachez quand même que toutes les reverbs ne s'appliquent pas a tout, une Boss RV-5 est dédiée Guitare et n'est pas prévue pour le mastering, tout comme une TC System 6000 dédiée au 5.1, ne donnera rien dans votre rack guitare. Le chapitre reverb en tout genre décrit certaines reverb, de la plus simple à la plus complexe, ce qui vous donnera une approche sur le paramétrage de la réverbération.

Paramètres d'une réverbération

Type c'est le type de reveb, permettant de choisir la façon dont "sonne" la reverb (vous n'aurez pas la même reverb dans une pièce avec des murs en pierre ou avec des murs en bois, si vous étés dans une foret, etc.).
Size permet de régler la taille de la pièce, donc de retarder et d'espacer les premières réflexions (qui seront plus longues à venir, faut qu'elles aient le temps de faire l'aller-retour...) et évidemment aussi la reverb. Ce réglage vous permet de simuler une petite pièce jusqu'au grandes salles de concerts, cathédrales, stades....
Pre-Delay règle le delay entre le signal direct et les premières réflexions, à noter que ce réglages règle, sur certaines reverbs, le temps avant que ne commence la fin de la reverb, les premières réflexions étant calculées en fonction. il est en outre possible sur certaines reverbs de régler de Pre-delay avec des valeurs négatives, c'est le signal direct qui est retarde, créant une reverbe inversée (les premières réflexions ont lieu avant le signal direct).
DecayTime règle le temps de déclin, le temps que met la reverb à diminuer de 60 dB. La voix parlée est souvent utilisée avec des temps inférieur à 1 s. La musique Pop, le Jazz et la musique de chambre sont meilleurs avec des temps de 1.2 s ou moins. La musique orchestrale est meilleur entre 1.5 et 2.3 s, et les chorales et musiques d'orgues sont souvent meilleures entre 3 et 5 s. Egalement pour une petite pièce entre 0.2 et 0.5 s, pièce moyenne, club entre 0.7 et 1.2 s, petites salles de concert et théâtres entre 1.1 et 1.8 s, une grande salle de concert entre 1.6 et 2.3, églises, cathédrales et autres grandes architectures jusqu'à 6 s, et certains cas exceptionnels de 40 s. Les musiques rapides travaillent mieux avec des temps courts.
Diffusion (ou densité) permet de régler le son diffus pour une reverb plus épaisse
Direct, Early Ref, Reverb on trouve souvent 3 réglages de volume, permettant de régler séparément le signal direct, les premières réflexions et la reverb

   Les reverb les plus complètes proposent (Waves, TC Electronics, etc.) des réglages du volume et de la durée séparées pour les hautes et basses fréquences pendant le temps de déclin (Damping), permettant d'augmenter le réalisme : une fréquence basse produit un son sourd et tend à supprimer des informations qui permettent de déterminer la distance ; beaucoup de pièces avec des murs solide renvoient peu de basses fréquence. En général, c'est parce qu'un mur avec plus de transmission des basses fréquences à un niveau plus élevé des 'bruits nuisibles', causées par la perte de sons basse de la pièce. D'autres paramètres permettent d'ajouter de la couleur à la reverb.

Les types de reverb

   La réverbération permet donc d'augmenter le réalisme puisqu'elle recrée la réverbération d'une pièce, que ce soit une pièce ou une salle de concert, elle permet de placer les instruments dans un contexte, un espace. La réverbération fait l'objet d'une étude toute particulière depuis de nombreuses années. Les techniques développées pour recréer cette réverbération ont été nombreuses, dont certaines ont eut leurs heures de gloires, et que l'on retrouve aujourd'hui sous forme d'émulation, dont voici les plus couramment rencontrées:

- Plate Les réverbérations à plaque étaient a l'origine élaborées en utilisant une grande plaque de métal fin suspendue verticalement et maintenue par des ressorts. Des capteurs fixés à la plaque transmettaient un signal qui faisait vibrer la plaque, recréant ainsi par diffusion le son de grands espaces acoustiques. Elles ont la particularité de se 'fondre' dans la musique, en adoucissant et épaississant le son. Elles sont très appréciées en musique Pop, notamment sur les instruments de batterie et les percussions. Les réverbérations à plaque ne produisaient pas de premières réflexion, et pour assurer un predelay on plaçait un delay, place avant la chambre de réverbération elle même.
- Room Les réverbérations Room simulent de véritables pièces, avec la sensation d'être réellement dans une petite pièce. Très utile sur les batteries et percussions, mais aussi sur les guitares électriques.
- Hall Les réverbérations Hall recréent l'acoustique d'espaces réels, des petites salles jusqu'aux grandes salles de concert. Cette reverb est particulièrement clair, permet d'ajouter de l'espace sans altérer le signal source. Très souvent appliquée sur les instruments et les voix, elle donne un sens d'homogénéité a vos pistes enregistrées séparément, donnant l'impression qu'elles ont été enregistrées ensembles.
- Chamber Pour la petite histoire, les chambres de réverbération étaient des pièces à la forme bizarre équipée d'une enceinte et d'un jeu de micros dont la fonction était de saisir l'ambiance en différents endroits de la pièce. Ces réverbérations sont homogènes, relativement dépourvues de notion de dimension avec très peu de coloration sonore. Les premières réflexions sont similaire aux reverb Hall. Cela dit, la notion de taille et d'espace est nettement moins prononcée. Cette caractéristique, associe à la faible coloration sonore du déclin permet une utilisation sur une vaste palette sonore, notamment les voix parlées, pour lesquels elles renforcent la sensation de niveau sonore sans pour autant colorer le son.
- Stage Les réverbérations stage donne une reverb stéréo, tout en préservant le signal non-traite. Elle augmente la perception de la positions des différents instruments dans l'espace stéréo,
- Ambience Les réverbérations ambience ajoutent de la chaleur, de la dimension et de la profondeur au signal sans le colorer. Cette reverb est souvent utilisée pour donner une ambiance d'espace (pièce) à un enregistrement ou à un discours. En musique, elle permet de rajouter de la distance à une prise avec micro rapproche.
- Gate/Inv Les réverbérations gate ont été créées en connectant un noise gate analogique en sortie de la réverbération. Le temps de chute était instantané alors que le temps de maintient permettait de faire varier la durée et le son. Elles sont particulièrement adaptées aux batteries et percussions, notamment sur la caisse clair et les toms.
- reverb à ressort Les réverbérations à ressort fonctionnent un peu comme les reverb plate. Le signal passe dans des ressorts, les mettant ainsi en vibration. Ces reverb aujourd'hui quasi disparues sont très recherchées. Elles ont équipées bon nombre d'amplis guitare, elles donnent un son très épais et très profond.
- Les reverb à modélisation Les réverbérations à modélisation sont apparues avec le numérique. Chaque fabriquant développe ses propres technologies et algorithmes. Elle permettent de recréer un espace en 3 dimension virtuel dans lequel les premières réflexions et la reverb sont calculées. Le réalisme est impressionnant, mais le nombre de paramètres à régler les destinent surtout dans des domaines ou la notion d'espace est très importante (films et post-production, son en 5.1)

   Je vous décrit ici quelques technologies développes par les plus grand fabricants (TC Electronic, Lexicon) qui ont fait leur preuves autant en studio, en Live et pour les films. Avant tous voici quelques principes de réverbération numériques parmi les plus récentes recherches effectuées:

Réverbération générique

   La réverbération générique est un effet flatteur donnant du sustain au son que vous pouvez ajouter à de nombreuses sources du mixage, sur un signal stéréo ou multicanal. Cet effet ajoute peu de caractère au son, mais ne le transforme que très peu. L'effet est dilué dans le son. Si l'effet offre un réglage de premières réflexions, elles ne sont que très peu nombreuses et jouent un rôle insignifiant. Par conséquent, une localisation marquée n'est pas appliquée au signal, ce qui est le but recherche lorsque la même réverbération est appliquée à plusieurs sources.

Avantages des reverberations generiques:
- Meilleur choix pour les signaux composites ou déjà mixés et en effet multi-canal.
- Meilleur choix lors de l'utilisation d'un Joystick multi-canal sur une console ou une station audionumérique.
- Meilleur choix sur un micro classique
- Efficace sur les sources en mouvement.
- Plus joli que la réalité.
- Facile et rapide d'utilisation.
Les 'contres':
- L'effet dilué efface le caractère des sources individuelles.
- La modification de hauteur peut devenir un problème avec certaines sources.
- La compatibilité mono est souvent sacrifiée au bénéfice d'une largeur de champ étendue.
- Le positionnement dans l'espace est inférieur à celui obtenu avec une réverbération basée sur la source

Reverberation de source

   Lorsque les éléments du mixage sont traites séparément, il est possible de définir exactement comment chacun doit être entendu. Il n'y a aucune raison d'appliquer une réverbération générique à plusieurs sources individuelles, à moins qu'elles ne soient sensées être places sur le même point dans l'espace acoustique ou a moins de manquer de départs auxiliaires. Lorsqu'il est souhaitable de distinguer les éléments partageant la même position dans le champ acoustique, utilisez la réverbération source. Les différences subtiles entre les structures de réflexion des diverses sources peuvent faire une différence sensible en terme de profondeur, d'expressivité et de positionnement naturel dans l'espace.

   Les réverbérations de source sont capables de générer des structures de premières réflexions multiples et complexes. Pour obtenir les meilleurs résultats, si certaines réflexions sont déjà reprises par un micro, elles doivent être supprimées de la structure simulée en utilisant le réglage correct d'atténuation des premières réflexions. Les instruments ou sources peuvent partager alternativement la même entrée de réverbération par groupes (par exemple gauche de la scène, centre et droite), pour obtenir un résultat meilleur et plus complexe que celui obtenu avec les réverbérations génériques utilisées avec un seul départ auxiliaire.

Avantages des réverbérations source:
- Meilleur choix lorsque les sources d'entrée peuvent être séparées
- Meilleur choix avec les micro sélectifs
- Meilleure profondeur et distinction dans le mixage
- Ajoute du caractère et de la définition à la source
Les 'contres':
- Nécessite plus de départs ou de sorties directes que les réverbérations génériques
- Pas davantage sur les signaux composites
- Pas idéal pour les sources en mouvement.

Réverbération échantillonnée

   Les réverbérations à échantillonnage sont une déclinaison des réverbérations source : Une réponse en impulsion est prélevée dans la véritable pièce, basée sur une source spécifique sur la position réelle du micro. Cette pièce avec position gelée de la source, du micro et du point d'écoute peut ensuite être appliquée à tout signal. Par expérience, nous savons qu'il est difficile d'exprimer l'ambiance de la pièce par les enceintes du fait des compromis intrinsèques des processus de reprise et de transmission lors de la capture de la réponse d'une pièce. Ceci est en particulier vrai avec les formats multi-canaux comme le 5.1 et le 6.1, ou des DSP peuvent être utilises pour optimiser une pièce virtuelle pour une configuration spécifique d'enceintes.

Avantages de l'échantillonnage:
- Sensation 'vivante' ou naturelle
- Possibilité de capturer certaines propriétés naturelles de la pièce
- sonorité différente de la simulation
Les 'contres':
- Peu de possibilités d'édition. L'édition ne semble pas naturelle
- Difficulté de saisir la sensation d'espace, contrairement a la simulation
- Une seule position de source fixe par moteur
- Temps de chargement long

Les technologies TC Electronic

   TC Electronic développe des algorithmes parmi les plus puissants. Utilisées autant en studio, en Live qu'en film et post-production, elles offrent le plus de réalisme. Le nombre de paramètre à régler est des plus impressionnant, permettant un contrôle total, et même de créer de nouvelles reverbs...

Reverberation VSS-3 La VSS-3 est basée sur un algorithme généraliste offrant des possibilités de réglages simples, ce qui vous permet d'obtenir de multiples sons. La VSS-3 est une réverbération générique de haute qualité, cette technologie ayant été déclinée en version Film et post-production, et en version surround.
Reverberation VSS-4 La VSS-4 est une véritable réverbération stéréo (avec entrée stéréo et sortie stéréo), radicalement différente des effets qui se contentent d'ajouter un champ sonore diffus sur la fin d'un signal a deux canaux. Basée sur les réflexions multi-angles de la source traitée, la précision de la VSS-4 est comparable au traitement naturel de sources mono stéréo placées dans un espace réel ou virtuel. Les deux sources d'entrée peuvent être utilisées pour un mixage stéréo final ou pour positionner deux sources individuelles mono dans le même espace virtuel. La VSS-4 est une réverbération véritablement stéréo simulant une pièce réelle : même si vous traitez une source avec une seule entrée, vous obtenez un signal de sortie stéréo contenant les premières réflexions et les champs diffus stéréo. Utilisée en mastering, la VSS-4 conserve une transparence totale de résolution lorsqu'elle est bypassée et conserve les deux sources placées à +/- 30 degrés.
Reverberation NonLin-2 NonLin est un effet de réverbération avec réglage d'enveloppe, d'attaque de maintient et de rétablissement. Elle peut générer une ambiance compacte pour les chants, des sons prononcés type années '80 sur les sons de batterie, des effets de réverbération inversée ou des effets spéciaux nouveaux. La NonLin offre également des effets de Gated Reveb, mais étant donnée qu'elle n'a pas besoin d'être déclenchée, elle peut être utilisée sur tout types de sources.

   Par rapport aux effets de réverbération du passé, la NonLin offre une réponse plus longue et plus diffuse avec une résolution accrue, mais un traitement classique à faible densité est également disponible. Cependant, l'utilisation de cet effet fait plus qu'ajouter une enveloppe libre, une réponse réglable et une résolution accrue à ce son classique. L'effet NonLin offre un paramètre Twist qui modifie le son de façon radicale de manière étrange. La fonction Twist peut ne pas toujours être du meilleur goût, mais elle ajoute du piquant a votre créativité et ajoute du caractère à toute source ou mixage.

Reverberation DVR-2 La DVR-2 est une superbe réverbération générique avec une véritable couleur vintage. La création de la DVR-2 a pris plusieurs années, avec comme but, la simulation de la réverbération la plus classique : L'EMT250. Une réverbération à la sonorité particulièrement belle. La création de la DVR-2 a impliqué la synergie de nombreux aspects conceptuels, matériel, logiciel, la perception... Bien qu'en mode normal la DVR-2 offre le son d'une 250 parfaitement alignée, avec ses défauts simulés par DSP, l'algorithme peut également être utilisé en mode haute résolution. Cette fonction atténue sensiblement le bruit de fond.

   La VSS-4TS est une VSS-4 avec réglages séparés pour les deux reverbs présentes, permettant une reverb stéréo des plus réaliste.

Les technologies Lexicon

   Leader incontestable de la réverbération pendant des décennies, la qualité des ses reverb n'a été égalée qu'avec l'avènement du numérique. A l'époque les réverbérations analogiques Lexicon coûtaient une fortune. Aujourd'hui, le numérique et la concurrence ont forcé Lexicon à revoir sérieusement ses prix et a entrer dans l'ère du numérique. Lexicon a une autre optique de la réverbération que TC Electronic. Lexicon modélise les vieilles reverb qui ont fait leur preuve, avec une qualité toujours au top. Toutes les reverb classiques, plate, room, chamber, concert hall, etc.. sont reprises en version numérique, avec une qualité jamais atteinte.

Random Hall L'algorithme Random Hall donne aux enregistrements l'impression d'avoir été enregistré dans une vrai pièce acoustique. Il s'agit d'une reverb hall, offrant la possibilité d'ajouter des premières réflexions qui ont été crées dans des clusters de pré-écho.

Les reverb Multicanal

   Avec le cinéma, le multicanal s'est rapidement développé. Pourtant plus ancien que la stéréo, le multi-canal s'est retrouvé une seconde jeunesse grâce à la technologie et les moyens d'aujourd'hui (Dolby Surround). Il n'est donc pas surprenant que l'un des premiers effets entièrement dédiés au multicanal soit la reverb. Le but recherche est évidemment le réalisme : En 5.1 il y a 5 HP satellites, il faut donc que la reverb soit en relation dans tous ces satellite, et les réflexions se diffusent dans toutes les directions, comme dans la réalité. En gros, le spectateur doit "être dans la scène". La reverb multi-canal est donc un vrai challenge, et la aussi, chaque fabriquant développe sa propre technologie.

Reverb en tout genre

   Ici, je vais vous présenter quelques reverbs du marche, de façon à couvrir au maximum tous les types de reverbs. L'intérêt ici est de comprendre qu'à la base les réglages sont les même, à quelques différences près, et de vous montrer également qu'une reverb à 50 000 paramètres n'est pas un effet qui ne peut se régler que par des physiciens chevronnes, on trouve seulement des réglages plus fins, pour des besoins spécifiques. Sachez que ce n'est pas un guide et mieux vaut aller les tester dans un magasin de musique pour apprécier la qualité et ses besoin, une Boss RV-5 donnant pleine satisfaction pour une guitariste exigeant, une R4000 satisfera mieux les ingénieurs du sons : Les besoins ne sont pas les même...

Boss RV-5

   Là on tape dans le plus simple. Bon d'accord les amplis guitare qui intègrent une reverb n'ont....qu'un seul réglage ! Cela peut certes être suffisant pour bon nombre de guitaristes, mais vous ne pouvez contrôler précisément votre reverb et l'utilisation d'une pédale peut palier à ce problème. La RV-5 donc, est une reverb numérique au format des pédales Boss, dotée d'entrées et de sorties stéréo

TC Electronic G-Major

   Le G-Major est le dernier multi-effet guitare de TC Electronic. Son utilisation est extrêmement simple malgré les possibilités. Les effets sont de qualité, et intègrent plusieurs émulations de reverbs classiques :

Spring Réverbération qui reproduit le son des anciennes réverbérations à ressort, du type de celles utilisées sur les amplis Vintage de guitare.
Decay Détermine la longueur de la fin de la réverbération
Pre-delay Permet de placer un court delay entre le signal direct et la fin de la réverbération. Permet de conserver un signal source clair, avec une fin de réverbération plus diffuse arrivant légèrement plus tard.
Size Détermine la taille de la pièce
Reverb Lev Détermine le niveau des premières réflexions
HiColor Permet de régler l'équilibre spectral du signal dans les hautes fréquences
Hi Factor Facteur multiplicatif du paramètre HiColor
LoColor Permet de régler l'équilibre spectral du signal dans les basses fréquences
Lo Factor Facteur multiplicatif du paramètre LoColor Room Level : Détermine le niveau de la fin de la réverbération
Diffuse Densité de la fin de la réverbération

TC-Electronic G-Major

TC Electronic FireworX

   Le FireworX est l'un des meilleurs processeur d'effets du marche, il intègre deux type de reverb : une simple et une advanced. La simple n'a que cinq paramètres, mais reste de qualité. L'intérêt d'une reverb inclue dans un multi-effet, est qu'elle ne doit pas être trop longue à régler, car, multi-effet oblige, d'autres effets sont à régler, et vous n'avez pas toutes la nuit devant vous.

Type Détermine le type de reverb, c'est a dire la relation entre le pre-delay, les premières réflexions et le déclin (types : Room, Club, Hall, Church, Cathedral, Grand Hall, Fast Decay, Slow Decay, Plate, Spring)
Decay Time Réglage du temps de déclin
Predelay Réglage du temps d'arrivée des premières réflexions
Reverb Level Réglage combine des niveau Room et Decay, correspondant au niveau général de sortie de la reverb
Color Détermine l'équilibre spectral du son des premières réflexions
Le reverb Advanced est le même algorithme mais vous fournis plus de contrôles:
Room Size Détermine la dimension de la pièce, modifie automatiquement la longueur du pre-delay (temps d'arrivée des premières réflexions) et le moment du déclenchement du déclin (instant ou le déclin de la réverbération commence).
Reverb Level Réglage combiné des niveaux Room et Decay, correspondant
au niveau général:
High Color Détermine la tenue en aigus du déclin
High Factor Accentue ou atténue l'effet défini par High Color (facteur multiplicatif)
Low Color Détermine la tenue en graves du déclin
Low Factor Accentue ou atténue l'effet défini par Low Color (facteur multiplicatif)
Room Parameters Détermine le niveau des premières réflexions
Color Détermine l'équilibre sonore des premières réflexions
Color Factor Accentue ou atténue l'influence du paramètre Color sur le signal (facteur multiplicatif)
Predelay Règle le temps d'arrivée des premiers réflexions
Decay Level Détermine le niveau du déclin
Diffuse Permet un réglage plus fin de la densité du déclin, aide à réduire le scintillement au minimum
Decay Start Détermine le commencement du déclin.

TC-Electronic FireworX

TC Electronic M3000

   La M3000 est un processeur de réverbération, la reverb ici y règne en maître, les algorithmes y sont parmi les plus puissants et les plus fournis, les possibilités sont immense, on n'est plus dans le même domaine, pas la peine de l'inclure dans votre rack guitare, les applications se tournent plus vers le studio, les films et post-production, le surround. Bien sur, la M3000 est polyvalente, mais elle est très longue à régler, et seul des mains expertes sauront en tirer le meilleur. Les algorithmes fonctionnent en 2 modes, Easy, permet de le régler en quelques paramètres, et le mode expert... je vous laisse découvrir les entrailles de la bête

VSS-3 Plutôt que de chercher à pousser plus avant les limites de la technologie de réverbération existante, TC Electronic a préféré repenser la conception des réverbérations numériques. Résultat, la technologie VSS donne une reverb de haute qualité, très réaliste et polyvalente.

Decay Temps de déclin de la réverbération (de 0.1 a 20 s)
Early Lev Niveau de sortie des premières réflexions
Rev Lev Niveau de sortie sur la fin de la réverbération
Rev Delay Délai de la fin de la réverbération (entre les premières réflexions et la fin de la réverbération)
Pre Delay Delay place à l'entrée de l'algorithme, il détermine le temps d'arrivée des premières réflexions.
Premières réflexions:
Early Type Permet de choisir le type de premières réflexions
Early Size Permet de modifier la taille du paramètre Early Type
Early Bal Positionnement droite/gauche des premières réflexions
Hi Color Permet de régler l'équilibre spectral du paramètre Early Type
Lo Cut Filtre coupe-bas, permet d'atténuer les basses fréquences des Premières Réflexions
Chute de la reverb:
Rev Type Permet de sélectionner le type de reverb
Diffuse Contrôle le taux de diffusion du déclin de la reverb
Rev Bal Positionnement droite/gauche du déclin de la reverb
Hi Cut Filtre coupe-haut, atténue les hautes fréquences en amont de la fin de la reverb
Hi Soften Filtre qui adouci les aigus de la fin de la reverb (les signaux agressifs)
Hi Decay Temps de Decay pour les hautes fréquences (facteur multiplicateur)
Hi Xover Fréquence de coupure entre les filtres médium et aigu
Mid Decay Temps de decay pour les fréquences médium (facteur multiplicateur)
Mid Xover Fréquence de coupure entre les bas-médium et les médium
Lo Mid Decay Temps de decay pour les bas-médium (facteur multiplicateur)
Lo Xover Fréquence de coupure entre les graves et les bas-médium
Lo Decay Temps de decay des basses (facteur multiplicateur)
Lo Damp Freq Règle la fréquence du filtre coupe-bas du paramètre Lo Damp
Lo Damp Atténuation en dB des basses fréquences
Reverb Modulation:
Type Détermine le type de modulation
Rate Règle la vitesse du LFO
Width Largeur de la modulation
Space Modulation:
Type Type de modulation de l'espace
Rate Règle la vitesse du LFO
Width Largeur de la modulation
Depth Profondeur de modulation de l'espace

   Il y a 3 algorithmes dérivés de la VSS-3 : un noise Gate VSS, une VSS-3 couplé à un Noise Gate ; VSS-FP, dédiée aux films et post-production ; VSS-SR, VSS-3 Surround.

TC-Electronic M3000

TC Electronic R4000

   La R4000 est le dernier né des processeurs de réverbération, elle n'a pas de nouveaux algorithmes, mais rassembles ceux issue de la M3000, M5000 et du System 6000.

Pre Delay Détermine le déclenchement du générateur d'enveloppe. donne de la profondeur et de la définition dans le mixage.
Attack Temps d'attaque de l'enveloppe
Hold Temps de maintient
Release temps de rétablissement
Style Sélectionne le type de base de réverbération
Diffuse Règle le taux de diffusion applique
Type Sélectionne le type de traitement applique sur la réverbération
Ratio : Taux de "Twist" Width Détermine la largeur stéréo en sortie
LoCut Filtre coupe-bas en entrée de réverbération
HiCut Filtre coupe-haut en entrée de réverbération.

TC-Electronic R4000

Lexicon PCM 91

   La Lexicon PCM 91 reprend toutes les reverb classique : plate, room, chamber, concert hall, etc. reprises en version numérique, avec une qualité jamais atteinte. Les réglages sont « standard » à par quelque un spécifique pour peaufiner ses réglages. Son fonctionnement est un jeu d'enfant, et il ne faut que quelques minutes pour obtenir la reverb désirée

Lexicon PCM91

Waves Trueverb

   Waves TrueVerb est un superbe plug-in, sans doute l'un des meilleur. Ses possibilités sont à la hauteur de sa qualité, malheureusement, il faut un ordi puissant, et mieux vaut posséder des DSP sur sa carte audio pour pouvoir travailler confortablement.

Dimensions Change le 'caractère' des premières réflexions simulées dans un espace à 'n' dimensions.
Room size Taille de la pièce en m3.
Link La reverb et le prédelay règlent le niveau des dernières réflexions dans la pièce.
Balance Contrôle la balance entre la reverb et le son direct, plus les premières réflexions.
DecayTime en s (référence standard -60 dB) détermine les temps de chaque première réflexion et la fin de la reverb.
Prédelay en ms, contrôle le temps avant que commence la reverb
Density Contrôle la densité des réflexions initiales de la reverb
RevShelf En dB. N'affecte que les premières réflexions, en simulant l'absorption caractéristique des surfaces d'une vraie pièce. Par exemple une pièce sourde avec beaucoup de tissus ou tapis, auront une valeur très bonne.
Freq. En Hz. Règle le 'coin' de fréquence pour RevShelf et ERAbsorb
ReverbDamping Les quatre boutons contrôlent le decay de la reverb. Deux curseur permettent de contrôler la fréquence et la rotation des Basse fréquences ou hautes fréquences (LF ou HF).
LF Damp En Hz. Règle la fréquence du ratio des basses fréquences.
LF Ratio Contrôle le temps de decay des basses fréquences, relative au decay time.
HF Damp En Hz. Règle la fréquence du ratio des hautes fréquences.
HF Ratio Contrôle le temps de decay des hautes fréquences, relative au decay time.
Direct active/désactive le son direct
EarlyRef active/désactive les premières réflexions
Reverb active/désactive la réverbération

Waves TrueVerb

Waves Renaissance Reverb

   Les plug-ins Renaissance de Waves integrent les meilleur technologies qui permet de réduire les réglages à l'essentiel, le plug-ins automatisant le reste. Le Renaissance Reverb est une évolution de TrueVerb, et les réglages ont été simplifies, permettant de disposer d'une TrueVerb améliorée avec moins de réglages, et donc plus simple et plus rapide à régler:

Predelay Contrôle le temps avant que commence la reverb
Time Règle le temps de decay de la reverb
Size Contrôle différents paramètres en fonction du type de reverb
Diffusion Sert de balance entre les premières réflexions
Decay Permet de déterminer si le decay est linéaire ou non
Early ref Contrôle le niveau de sortie des premières réflexions
Reverb Contrôle le niveau de sortie de la reverb
Wet/Dry Balance entre le signal traité et non traité
Freq/ratio Ces 4 réglages règlent le Damping (atténuation/augmentation de la durée des basses et hautes fréquences de la reverb par rapport au Decay Time)
Freq/gain Ces 4 réglages contrôlent la pente de l'égalisation de la reverb
Reverb type Permet de choisir un type de reverb
Decorrelation Contrôle la quantité de corrélation entre les 2 canaux dans les premières réflexions. L'effet est subtile mais peut apporter un accordage fin dans la couleur d'un son.

Renaissance Reverb

waves R360

   Le plug-in Waves R360 est dédié au son multicanal. Son fonctionnement reste toutefois particulier : beaucoup de réverbérations numériques génèrent les premières réflexions et les dernières réflexions séparément mais dans la même unité. En multicanal, les premières réflexions doivent être en relation avec le panning, pour permettre d'augmenter la localisation spatiale. Pour créer une balance correcte, la distance de panning est incorporée dans le plug-in S360 Imager.

Reverb properties:
PreDelay Spécifie combine de temps doit se passer entre le son de la source et la génération de la réverbération
Rear ofs Règle le temps de predelay des canaux de face par rapport aux canaux arrière
Size Règle la taille de la pièce virtuelle
Density Règle la densité de la reverb
Reverb Mix:
In Gain Ajuste le gain d'entrée pour la reverb
Center Spécifie le canal central pour la sortie de la reverb
In LFE Détermine la quantité du signal du canal LFE va entrer dans la réverbération
Out LFE Détermine la quantité de réverbération doit sortir dans le canal LFE
Front/Rear Balance entre l'avant et l'arrière de l'espace sonore
Bright Ajuste la brillance des canaux arrière
LFE LowPass Détermine la sortie de la reverb dans le canal LFE
ReverbDamping Les quatre boutons contrôlent le decay de la reverb. Deux curseur permettent de contrôler la fréquence et la rotation des Basse fréquences ou hautes fréquences (LF ou HF).
LF Damp En Hz. Règle la fréquence du ratio des basses fréquences.
LF Ratio Contrôle le temps de decay des basses fréquences, relative au decay time.
HF Damp En Hz. Règle la fréquence du ratio des hautes fréquences.
HF Ratio Contrôle le temps de decay des hautes fréquences, relative au decay time.
Reverb Time Détermine le temps que met un son à diminuer de 60 dB
Reverb EQ Freq/gain Ces 4 réglages contrôlent la pente de l'égalisation de la reverb

Waves R360

L960

   Fruit de 20 ans de recherche, la Lexicon L960 est une reverb multicanal professionnelle numérique de haute qualité. Elle reprend les reverb Lexicon et les étend au multicanal et les réglages y sont légion. La télécommande est ultra pratique, avec afficheur couleur et munie de faders de contrôle. La Haute qualité signé Lexicon.

Lexicon L960

S6000

   La réponse de Tc Electronic à Lexicon : Le system 6000 est le concurrent direct de la L960 de Lexicon. Elle se présente également sous forme d'un rack muni d'une télécommande de pilotage. Les reverb ici sont signée TC et les possibilités énormes en font un monstre dédié pour professionnels exigent.

TC-Electronic S6000
^
05 septembre 2015

htmlpdflatexmanmd




ld.so

ld.so, ld-linux.so

loader/linker dynamique

   Le linker dynamique peut être lancé soit indirectement par un programme lié dynamiquement ou une librairie, ou directement en exécutant:

  /lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]

   les programmes ld.so et ld-linux.so* trouvent et chargent les librairie nécessaires à un programme, préparent le programme et le lance.

   Les binaires linux nécessitent une liaison dynamique sauf si l'option -static a été donné à ld(1) durant la compilation.

   Le programme ld.so manipule les binaires a.out, un format utilisé depuis longtemps, ld-linux.so* manipulent les formats ELF (/lib/ld-linux.so.1 pour libc5, /lib/ld-linux.so.2 pour glibc2), qui sont utilisés depuis de nombreuses années. Sinon, les 2 ont le même comportement, et utilisent les même fichiers et programmes ldd(1), ldconfig(8), et /etc/ld.so.conf

   En résolvant les dépendances de librairies, le linker inspecte d'abord chaque chaîne de dépendance pour voir s'il contient un slash (cela se produit si un chemin de librairie contenant des '/' a été spécifié au moment du lien). Si un slash est trouvé, la chaîne de dépendance est interprété comme chemin (relatif ou absolu), et la librairie est chargée en utilisant ce chemin.

   Si une dépendance de librairie ne contient pas de '/', elle recherché dans l'ordre suivant:

- (ELF uniquement) Utiliser les répertoires spécifiés dans l'attribut de section dynamique DT_RPATH du binaire si présent et que l'attribut DT_RUNPATH n'existe pas. L'utilisation de DT_RPATH est déprécié
- Utilise la variable d'environnement LD_LIBRARY_PATH. Excepté si l'exécutable est un binaire set-user-ID/set-group-ID, auquel cas il est ignoré
- (ELF uniquement) Utilise les répertoires spécifiés dans l'attribut de section dynamique DT_RUNPATH du binaire si présent
- depuis le fichier de cache /etc/ld.so.cache, qui contient une liste compilée de librairies candidat précédemment trouvé. Si, cependant, le binaire a été lié avec l'option du linker -z nodeflib, les librairies dans les chemins par défaut sont sautés.
- Dans le chemin par défaut /lib, puis /usr/lib. Si le binaire a été lié avec -z nodeflib, cette étape est sauté

Expansion de token rpath

   ld.so comprend certaines chaîne dans une spécification rpath (DT_RPATH ou DT_RUNPATH); ces chaînes sont substituées comme suit:

$ORIGIN ou ${ORIGIN} Étend au répertoire contenant l'exécutable de l'application. Donc, une application localisée dans somedir/app pourrait être compilé avec gcc -Wl,-rpath,'$ORIGIN/../lib' pour qu'il trouve une librairie partagée dans somedir/lib peut importe où se trouve somedir.
$LIB ou ${LIB} S'étends à lib ou lib64 en fonction de l'architecture.
$PLATFORM ou ${PLATFORM} s'étends à la chaîne correspondant au type de processeur du système hôte (ex: X86_64). Dans certaines architectures, le kernel linux ne fournis pas un telle chaîne.

OPTIONS

--list Liste toutes les dépendances et comment elles sont résolues
--verify Vérifie que le programme est lié dynamiquement et que ce linker peut le gérer.
--library-path PATH Utilise le PATH spécifié au lieu de la variable LD_LIBRARY_PATH
--inhibit-rpath LIST Ignore les information RPATH et RUNPATH dans les noms d'objet dans LISTE.
--audit LIST Utilise les objets nommés dans LIST comme auditeurs.

Capacités hardware

   Certaines librairies sont compilées en utilisant des instructions spécifiques au hardware qui n'existe pas sur tous les CPU. De telles librairies devraient être installée dans des répertoires dont le nom définis les capacités hardware, tel que /usr/lib/sse2/. Le linker dynamique vérifie ces répertoires avec le hardware de la machine et sélectionne la version la plus appropriée de la librairie donnée. Les répertoire de capacité hardware peuvent être hiérarchisés pour combiner les fonctionnalités CPU. La liste des noms de capacités hardware supportée dépend du CPU. Les noms suivant sont actuellement reconnus:

Alpha ev4, ev5, ev56, ev6, ev67
MIPS loongson2e, loongson2f, octeon, octeon2
PowerPC 4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx
SPARC flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
s390 dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch
x86 (32-bit only) acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm

Variables d'environnement

LD_ASSUME_KERNEL glibc ›= 2.2.3. Force le linker dynamique à assumer qu'il fonctionne sur un système avec une version ABI kernel différent.
LD_BIND_NOT glibc ›=2.2. Ne met pas à jour le Global Offset Table et la Procedure Linkage Table en résolvant un symbole.
LD_BIND_NOW glibc ›=2.1.1. Si non vide, le linker dynamique résous tous les symboles au démarrage au lieu de déférer les appels de fonction au moment ou il sont référencé la première fois.
LD_LIBRARY_PATH Liste de répertoire dans lequel rechercher les librairies ELF au moment de l'exécution. Ignoré pour les programmes set-user-ID et set-group-ID
LD_PRELOAD Une liste de librairies partagées ELF additionnels à charger avant toutes les autres.
LD_TRACE_LOADED_OBJECTS ELF uniquement. non vide, force le programme à lister ses dépendance comme lancé par ldd, au lieu de se lancer normalement
LD_AOUT_LIBRARY_PATH (libc5) Version de LD_LIBRARY_PATH pour les binaires a.out
LD_AOUT_PRELOAD (libc5) Version de LD_PRELOAD pour les binaires a.out
LD_AUDIT glibc ›=2.4. Liste d'objets partagé à charger avec tous les autres dans un espace de nom de linker séparé.
LD_BIND_NOT glibc ›=2.1.95. ne met pas à jours GOT et PLT après avoir résolus un symbole
LD_DEBUG glibc ›=2.1. Mode verbeux du linker dynamique. (all ou help).
LD_DEBUG_OUTPUT glibc ›=2.1. Fichier dans lequel écrit la sortie LD_DEBUG (défaut: l'erreur standard)
LD_DYNAMIC_WEAK glibc ›=2.1.91. Autorise à écraser les symboles faibles (revenir à l'ancien comportement glibc)
LD_HWCAP_MASK glibc ›=2.1. Masque pour les capacités hardware.
LD_KEEPDIR (libc5). N'ignore pas le répertoire dans les noms des librairies a.out à charger.
LD_NOWARN (libc5).Supprime les alertes sur les librairie a.out avec des numéros de version mineur incompatible.
LD_ORIGIN_PATH glibc ›=2.1. Chemin œu le binaire est trouvé
LD_POINTER_GUARD glibc ›=2.4. À 0, désactive le pointer guarding, sinon l'active.
LD_PROFILE glibc ›=2.1. Le nom d'un simple objet partagé à profiler.
LD_PROFILE_OUTPUT glibc ›=2.1. Répertoire où la sortie LD_PROFILE doit être écrite.
LD_SHOW_AUXV glibc ›=2.1. Affiche un tableau auxiliaire passé par le kernel.
LD_USE_LOAD_BIAS Non définis, les exécutables et objets partagés pré-liés honorent les adresses de base de leur librairies et les PIE et autres objets partagé ne les honore pas. Si définis, tous les honorent. À 0 aucun de les honorent.
LD_VERBOSE glibc ›=2.1. Si non vide, affiche les informations de versionning de symbole sur le programme si LD_TRACE_LOADED_OBJECTS a été mis.
LD_WARN ELF, glibc ›=2.1.3. non vide, alerte sur les symboles non-résolus
LDD_ARGV0 libc5. argv[0] est utilisé par ldd quand aucun n'est présent.

Fichiers

/lib/ld.so linker/loader dynamique a.out
/lib/ld-linux.so.{1,2} linker/loader dynamique ELF
/etc/ld.so.cache Fichier contenant une liste compilée de répertoires dans lesquels rechercher les librairies et une liste ordonnées de librairies candidates.
/etc/ld.so.preload Fichier contenant une liste de librairies partagées ELF à charger avant le programme.
lib*.so* Librairies partagées.
^
12 octobre 2013

htmlpdflatexmanmd




ldap.conf

ldap.conf, .ldaprc

Fichier de configuration LDAP

   ldap.conf est utilisé pour définir les paramètres LDAP par défaut pour les clients. les utilisateurs peuvent créer un fichier ldaprc ou .ldaprc dans leur répertoire personnel. D’autres fichiers de configuration peuvent être spécifiés en utilisant les variables d’environnement LDAPCONF et LDAPRC. Les options peuvent être également définies par des variables d’environnement en les préfixant par "LDAP" (ex: pour BASE, LDAPBASE). Certaines options sont user-only et sont ignorés s’ils sont trouvés dans ldap.conf.

Les fichiers et variables sont lus dans cet ordre:
variable $LDAPNOINIT , et si non définie:
system file /usr/local/etc/openldap/ldap.conf,
user files $HOME/ldaprc, $HOME/.ldaprc, ./ldaprc,
system file $LDAPCONF,
user files $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
variables $LDAP‹uppercase option name›.

OPTIONS

URI ‹ldap[si]://[name[:port]] ...› Spécifie les URI des serveurs LDAP.
BASE ‹base› Spécifie le DN de base pour les opérations de recherche
BINDDN ‹dn› Spécifie le Bind DN à utiliser (user-only)
DEREF ‹when› Spécifie comment les alias sont déréférencés. peut être: never Jamais déréférencés searching les alias sont déréférencés en subordonnés de l’objet de base, mais pas en localisant l’objet de base de la recherche finding Les alias sont déréférencés en localisant l’objet de base de la recherche always Les alias sont toujours déréférencés.
NETWORK_TIMEOUT ‹integer› Spécifie le timeout en seconde pour les connections
REFERRALS ‹on/true/yes/off/false/no› Spécifie si le client devrait automatiquement suivre les référant retournés par le serveur. Noter que ldapsearch n’utilise pas cette option.
SIZELIMIT ‹integer› Spécifie le nombre d’entrées à utiliser pour les recherches.
TIMELIMIT ‹integer› Spécifie une limite de temps en seconde pour les recherches.
TIMEOUT ‹integer› Spécifie un timeout en secondes après lesquels les appels LDAP sont annulés si aucune réponse n’est reçue.

Options SASL

SASL_MECH ‹mechanism› Spécifie le mécanisme SASL à utiliser (user-only)
SASL_REALM ‹realm› Royaume SASL
SASL_AUTHCID ‹authcid› Spécifie l’identité d’authentification (user-only)
SASL_AUTHZID ‹authcid› Spécifie l’identité d’authorisation (user-only)
SASL_SECPROPS ‹properties› Spécfie les propriétés de sécurité SASL. peut être:

        none seul, désactive ("noanonymous,noplain")
        noplain Désactive les mécanismes sujets à attaques simple
        noactive Désactive les mécanismes suet à attaques actives.
        nodict Désactive les mécanismes sujets à attaque passive par dictionnaire
        noanonymous Désactive les mécanismes qui supportent les logins anonymes
        forwardsec Nécessite de renvoye un secret entre les sessions
        passcred Nécessite des mécanismes qui passent les accréditations client.
        minssf=‹factor› Spécifie le facteur minimum à utiliser
        maxssf=‹factor› Spécifie le facteur maximum à utiliser
        maxbufsize=‹factor› Spécifie la taille de tampon maximum. (0 désactive)

Options GSSAPI

GSSAPI_SIGN ‹on/true/yes/OFF/false/no› Spécifie si GSS_C_INTEG_FLAG devrait être utilisé
GSSAPI_ALLOW_REMOTE_PRINCIPAL ‹on/true/yes/OFF/false/no› Spécifie si l’authentification devrait tenter de former le principal de l’attribut ldapServiceName ou dnsHostName des entrées RootDSE cibles.

Options TLS

TLS_CACERT ‹filename› Spécifie le fichier contenant les certficats des autorités reconnus par le client
TLS_CACERTDIR ‹path› Spécifie le répertoire contenant les certficats des autorités reconnus par le client
TLS_CERT ‹filename› Fichier contenant le certificat du client (user-only)
TLS_KEY ‹filename› Spécifie le fichier contenant la clé privée (user-only)
TLS_CIPHER_SUITE ‹cipher-suite-spec› Spécifie les suites de chiffrement accèptables, par ordre de préférence
TLS_PROTOCOL_MIN ‹major›[.‹minor›] Spécifie la version de protocol SSL/TLS minimum. (pour TLS v1.1 mettre 3.2)
TLS_RANDFILE ‹filename› Spécifie le fichier contenant des données aléatoires quand /dev/urandom n’est pas disponible.
TLS_REQCERT ‹level› Spécifie quels vérifications effectuer sur les certificats serveur dans une session TLS:

        never Ne vérifie rien
        allow Le certification serveur est requis. S’il n’est pas fournis, ou s’il n’est pas valide, la session procède normalement
        try Le certificat serveur est requis. si le certificat n’est pas fournis, la session continue normalement. Si le certificat n’est pas valide, termine la session.
        demand|hard Le certificat serveur est obligatoire et doit être valide.
        TLS_CRLCHECK ‹level› Spécfie si la CRL doit être vérifiée : none
        Pas de vérification peer
        Vérifie la CRL du certificat du partie all
        Vérifie la CRL pour toute la chaîne de certificat

TLS_CRLFILE ‹filename› Spécifie le fichier contenant la CRL.

Variables d'environnement

LDAPNOINIT Désactive tous les paramètres par défaut
LDAPCONF Chemin du fichier de configuration
LDAPRC Fichier de configuration dans $HOME ou $CWD
LDAP‹option-name› Options comme dans ldap.conf
^
08 septembre 2013

htmlpdflatexmanmd




ldapcompare

ldapcompare

Outil de comparaison ldap

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-z Mode silencieux

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

ldapcompare "uid=babs,dc=example,dc=com" sn:Jensen
ldapcompare "uid=babs,dc=example,dc=com" sn ::SmVuc2Vu
^
08 septembre 2013

htmlpdflatexmanmd




ldapdelete

ldapdelete

Outil de suppression d’entrées LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-c Mode continue, les erreurs sont reportées, mais la requête continue
-f file Lit une série de DN depuis le fichier
-r Suppression récursivement
-z sizelimit Limite en recherchant le DN à supprimer

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapexop

ldapexop

Fournis des opérations étendues LDAP par oid ou un des mot clé spécial whoami, cancel ou refresh.

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-f file Lit les opérations depuis le fichier

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapmodify

ldapmodify, ldapadd

Ajouter/modifier des entrées dans LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-a Ajoute une nouvelle entrée. défaut pour ldapadd
-c Mode continue, les erreurs sont reportées, mais la requête continue
-f file Lit les entrées depuis le fichier
-S file Reporte les enregistrements qui ont été skippés à cause d’une erreur dans le fichier spécifié

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapmodrdn

ldapmodrdn

Outil de renommage LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-c Mode continue, les erreurs sont reportées, mais la requête continue
-s newsup Spécifie un nouveau supérieur de l'entrée (ldapv3 uniquement)
-r Supprime les anciennes valeurs RDN de l'entrée
-f file Lis les informations de modification depuis le fichier

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

on assume que le fichier /tmp/entrymods existe et a le contenu :
cn=Modify Me,dc=example,dc=com
cn=The New Me
la commande :
ldapmodrdn -r -f /tmp/entrymods
va changer le RDN de l’entrée "Modify Me" depuis "Modify ME" vers "The New Me" et l’ancien cn "Modify Me" sera supprimé.
^
08 septembre 2013

htmlpdflatexmanmd




ldappasswd

ldappasswd

Change le mot de passe d’une entrée LDAP

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-A Demande l’ancien mot de passe. Évite de spécifier le mot de passe sur la ligne de commande
-a oldpasswd Spécifie l’ancien mot de passe
-t oldPasswdFile Spécifie le fichier contenant l’ancien mot de passe.
-S Demande le nouveau mot de passe. Évite de spécifier le mot de passe sur la ligne de commande
-s newpasswd Définit le nouveau mot de passe.
-T newPasswdFile Définit le fichier contenant le nouveau mot de passe.

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapsearch

ldapsearch

Outil de recherche ldap

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité
-c Mode continue, les erreurs sont reportées, mais la requête continue
-u Inclus la forme User Friendly Name des DN dans la sortie
-t[t] -t écrit les valeurs non-imprimables dans un jeu de fichiers temporaires. -tt écrit toutes les valeurs retournées dans les fichiers.
-T path Ecrit les fichiers temporaires dans ce répertoire
-F prefix Préfix URL des fichiers temporaires (défaut : file ://‹path›)
-A Récupère les attributs uniquement
-L Affiche le résultat au format LDIF. -L utilise le format LDIFv1, -LL désactive les commentaires, -LLL n’affiche pas la version LDIF.
-S attribute Trie les entrées retournée basé sur l’attribut spécifié.
-b searchbase Point de départ pour la recherche
-s base|one|sub|children Scope de recherche
-a never|always|search|find Spécifie le mode de déréférencement des alias.
-l timelimit temps d’attente max en seconde pour qu’une recherche se complète
-z sizelimit Nombre d’entrées max pour qu’une recherche se complète.
-f file Pour chaque ligne dans le fichier, effectue une recherche. Dans ce cas, le filtre spécifié sur la ligne de commande est traité comme pattern où la première occurence de %s est remplacée par la ligne.

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
08 septembre 2013

htmlpdflatexmanmd




ldapurl

ldapurl

Outil de formatage d’URL LDAP

OPTIONS

-a attrs Liste de sélecteur d’attributs
-b searchbase Point de départ pour la recherche
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-H ldapuri URI du serveur LDAP
-S scheme Schema d’URL
-s base|one|sub|children Scope de recherche

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]

Exemples

ldapurl -h ldap.example.com -b dc=example,dc=com -s sub -f "(cn=Some One)"
retourne:
ldap ://ldap.example.com:389/dc=example,dc=com ??sub ?(cn=Some%20One)
ldapurl -H ldap ://ldap.example.com:389/dc=example,dc=com ??sub ?(cn=Some%20One)
retourne :
scheme : ldap
host : ldap.example.com
port : 389
dn : dc=example,dc=com
scope : sub
filter : (cn=Some One)
^
08 septembre 2013

htmlpdflatexmanmd




ldapwhoami

ldapwhoami

Outil pour l'opération WhoAmI

OPTIONS

-V[V] Affiche les informations de version
-d debuglevel Niveau de debug
-n  simule la requête, mais ne l’exécute pas
-M[M] Permet de gérer le DSA IT control. -MM rend le contrôle critique.
-x Authentification simple
-D binddn DN pour l’authentification simple
-W Demande le mot de passe pour l’authentification simple
-w passwd Définis le mot de passe pour l’authentification simple
-y passwdfile Utilise le contenu du fichier comme mot de passe pour l’authentification simple
-H ldapuri URI du serveur LDAP
-P 2|3 Version du protocole à utiliser
-e [!]ext[=extparam] Spécifie les extensions générales. ! indique la criticité
-E [!]ext[=extparam] Spécifie les extensions de recherche. ! indique la criticité
-o opt[=optparam] Spécifie les options générales (nettimeout=‹timeout› en secondes ou "none" ou "max", ldif-wrap=‹width› en colonnes, ou "no")
-O security-properties Spécifie les propriétés SASL
-I Mode interactif SASL.
-Q SASL en mode silencieux, ne demande jamais
-N N’utilise pas le reverse DNS pour canoniser les hôtes SASL
-U authcid Spécifie l’authentification ID pour le bind SASL.
-R realm Spécifie le realm SASL
-X authzid Spécifie l’authorization ID demandé pour le bind SASL
-Y mech Spécifie le mécanisme SASL à utiliser
-Z[Z] Fournis l’opération étendue StartTLS. -ZZ, l’opération doit être un succès

-v Augmente la verbosité

Extensions Générales

[!]assert=‹filter› un filtre RFC 4515
!authzid=‹authzid› "dn :‹dn›" ou "u :‹user›"
[!]bauthzid Contrôle authzid RFC 3829 authzid
[!]chaining[=‹resolve›[/‹cont›]]
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=‹attrs›] (a comma-separated attribute list)
[!]preread[=‹attrs›] (a comma-separated attribute list)
[!]relax
sessiontracking
abandon, cancel, ignore SIGINT envoie une réponse abandon/cancel,ou ignore; Si critique, n’attend pas SIGINT.

Extensions de recherche

!dontUseCopy
[!]domainScope scope du domaine
[!]mv=‹filter› Filtre des valeurs de match
[!]pr=‹size›[/prompt|noprompt] paged results
[!]sss=[-]‹attr[:OID]›[/[-]‹attr[:OID]›...] Tri coté serveur
[!]subentries[=true|false] subentries
[!]sync=ro[/‹cookie›] LDAP Sync refreshOnly
rp[/‹cookie›][/‹slimit›] LDAP Sync refreshAndPersist
[!]vlv=‹before›/‹after›(/‹offset›/‹count›| :‹value›) virtual list view
[!]deref=derefAttr:attr[,attr[...]][ ;derefAttr:attr[,attr[...]]]
[!]‹oid›[=‹value›]
^
05 septembre 2015

htmlpdflatexmanmd




ldconfig

ldconfig

Configure les liaisons dynamiques

   ldconfig créé les liens et caches nécessaires pour trouver les libraires dans les répertoires spécifiés, dans le fichier /etc/ld.so.conf, et dans les répertoire de confiance /lib et /usr/lib. Le cache est utilisé par le linker run-time, ld.so. ldconfig vérifie les en-têtes et noms de fichier des librairies qu'il rencontre.

OPTIONS

-v mode verbeux
-n  Ne traite que les répertoires spécifiés sur la ligne de commande, et non /lib et /usr/lib. Implique -N
-N Ne reconstruit pas le cache. Sauf si -X est également spécifié, les liens sont mis à jours
-X Ne met pas à jours les liens. reconstruit le cache sauf si -N est spécifié.
-f conf Utiliser le fichier spécifié au lieu de /etc/ld.so.conf
-C cache Utilise le cache spécifié au lieu de /etc/ld.so.cache
-r root Change et utilis root comme répertoire root
-l mode librairie. Lie manuellement les librairies.
-p Affiche les listes de répertoires candidat dans le cache courant.
^
05 septembre 2015

htmlpdflatexmanmd




ldd

ldd

Afficher les dépendances de librairie partagées

   ldd affiche les librairies partagées par chaque programme ou librairie partagées sur la ligne de commande. Normalement, ldd invoque le linker dynamique standard (ld.so) avec la variable d'environnement LD_TRACE_LOADED_OBJECTS à 1, qui force le linker à afficher les dépendances de librairie. Cependant, sous certaines circonstances, certaines versions de ldd peuvent tenter d'obtenir les informations de dépendances directement en exécutant le programme. Donc, ne jamais employer ldd sur un exécutable non fiable, ce qui pourrait résulter dans l'exécution de code arbitraire. Une alternative plus sûre est d'utiliser:objdump -p /path/to/program | grep NEEDED

OPTIONS

-v, --verbose Affiche toutes les informations, incluant le versionning de symboles
-u, --unused Affiche les dépendances directes non utilisées.
-d, --data-relocs Affiche les relocations pour les objets de données et les fonctionne, et reporte les objets ou fonctions manquantes
^
01 février 2014

htmlpdflatexmanmd




less

less

l'opposé de more

Commandes

h, H Affiche l'aide
SPACE, ^V, f, ^F Défile N lignes (défaut: un écran)
z idem. N devient le nouveau défaut
ESC-SPACE idem SPACE, mais défile un écran complet même si la fin du fichier est atteint
ENTER, RETURN, ^N, e, ^E, j, ^J Défille N lignes de texte (défaut: 1)
d, ^D Défile N ligne (défaut: 1/2 écran). Si N est spécifié, devient le nouveau défaut pour d et u
b, ^B, ESC-v défile N lignes en arrière (défaut: un écran)
w idem. N devient le nouveau défaut
y, ^Y, ^P, k, ^K défile N ligne en arrière (défaut: 1).
y, ^U Défile N lignes en arrière (défaut: 1/2 écran). Si N est spécifié, devient le nouveau défaut pour d et u
ESC-), RIGHTARROW Défile horizontalement de N caractères vers la droite. (défaut: 1/2 écran). Si N est spécifié, devient le nouveau défaut.
ESC-( or LEFTARROW Défile horizontalement de N caractères vers la gauche. (défaut: 1/2 écran). Si N est spécifié, devient le nouveau défaut.
r, ^R, ^L Repaint l'écran
R Repaint l'écran, en omettant le buffer d'entrée.
F Défile vers le bas et tente de lire guand la fin du fichier est atteint.
g, ‹, ESC-‹ va à la ligne N. (défaut: 1, début du fichier)
G, ›, ESC-› Va à la ligne N. (défaut: fin du fichier)
p, % va à la position N pourcent dans le fichier
P Va à la ligne contenant le N-ième Octet
{ Si un { apparaît dans la ligne du haut, va au } correspondant. N permet de spécifier le N-ième { de la ligne
} Si un } apparaît dans la ligne du haut, va au { correspondant. N permet de spécifier le N-ième } de la ligne
[ Comme {, mais pour [
] Comme }, mais pour ]
ESC-^F Suivi par 2 caractères, agis comme {, mais utilise les 2 caractères comme balise d'ouverture et de fermeture.
ESC-^B Suivi par 2 caractères, agis comme ], mais utilise les 2 caractères comme balise d'ouverture et de fermeture.
m Suivi par une lettre minuscule, marque la position courante avec cette lettre
', ^X^X Suivi par une lettre minuscule, retourne à la position marquée
/pattern Recherche en avant la N-ième ligne contenant le motif. (défaut:1) caractères spéciaux pour le motif:

^N, ! Recherche les lignes qui ne matchent pas le motif
^E, * Rechercher dans plusieurs fichiers
^F, @ Commence la recherche à la première ligne du premier fichier
^K Surligne tout texte qui match le motif
^R N'interprète pas les méta-caractères de l'expression régulière.

?pattern Recherche en arrière dans le fichier la N-ième ligne contenant le motif (défaut 1). Les caractères spéciaux sont les même que /pattern, mais ^E et ^F sont dans le sens inverse.
ESC-/pattern Idem à "/*"
ESC-?pattern Idem à "?*"
n Répète la recherche précédente
N Répète la recherche précédente, mais inverse la direction
ESC-n Répète la recherche précédente, mais traverse les fichiers.
ESC-N Répète la recherche précédente, mais inverse la direction et traverse les fichiers
ESC-u Annule le surlignage de la recherche
&pattern Affiche uniquement les lignes qui match le motif. prend en charge les caractères spéciaux ! et ^R de /pattern
^X^V, E, :e [filename] Examine un nouveau fichier.
:n Examine le N-ième fichier suivant (défaut 1)
:p Examine le N-ième fichier précédent (défaut 1)
:x Examine le N-ière fichier dans la ligne de commande (défaut: 1)
:d Supprime le fichier courant de la liste
t Va au tag suivant
T Va au tag précédent
=, ^G, :f Affiche certaines informations sur le fichier courant
- Suivis par un option de ligne de commande à une lettre, change le paramètre et affiche un message sur cette option
-- comme - mais pour les options longues
-+ Suivi par une option de ligne de commande à une lettre, réinitialise l'option à sa valeur par défaut
--+ Comme -+ mais pour les options longues
-! Suivi par une option de ligne de commande à une lettre, réinitialise l'option à l'opposé de son défaut
--! comme -! mais pour les options longues
_ Suivi par une option de ligne de commande à une lettre, affiche un message décrivant le paramètre actuel de cette option
__ idem _ mais pour les options longues
+cmd exécute la commande à chaque fois qu'un nouveau fichier est examiné (ex: +G affiche directement la fin de chaque fichier)
V Affiche la version de less
q, Q, :q, :Q, ZZ quitte less
v Invoque $EDITOR ou $VISUAL
! shell-command Invoke un shell pour lancer la commande données. % est remplacé par le nom du fichier courant.
!! répète la dernière commande shell.
| ‹m› shell-command pipe une section du fichier dans la commande données. La section en pipe va de la première ligne de l'écran courant à la position marquée m. peut également être '^' ou '$' pour indiquer le début ou la fin du fichier, ou '.' ou newline pour piper l'écran courant.
s filename Sauve l'entrée courante dans un fichier. ne fonctionne que si l'entrée est un pipe

OPTIONS

-?, --help Affiche l'aide
-a, --search-skip-screen Force les recherches à commencer au début ou à la fin du fichier au lieu de l'écran courant
-A, --SEARCH-SKIP-SCREEN Force les recherches à commencer à la ligne cible
-bn, --buffer=n Spécifie la taille de tampon utilisé par less pour chaque fichier en Ko(défaut 64K). -1 == illimité
-B, --auto-buffers Idem mais utilisé avec les pipes
-c, --clear-screen Repaindre l'écran depuis la ligne du haut au lieu de la ligne du bas
-C, --CLEAR-SCREEN comme -c, compatibilité avec des veilles versions de less
-d, --dumb Supprime les messages d'erreurs normalement affichés
-Dxcolor, --color=xcolor Définis la couleur du texte affiché. x est un simple caractère qui sélectionne le type de texte à colorer: n=normal, s=standout, d=bold, u=underline, b=blink. color est une paire de valeur "foreground.background"
-e, --quit-at-eof Quitte automatiquement la 2ème fois que la fin du fichier est atteinte
-E, --QUIT-AT-EOF Quitte automatiquement la 1ère fois que la fin du fichier est atteinte
-f, --force Force les fichiers non-réguliers à s'ouvrir
-F, --quit-if-one-screen Force less a quitter si le fichier tient entièrement dans un seul écran
-g, --hilite-search surligne uniquement la chaîne particulière trouvés par la dernière commande au lieu de toutes les chaînes trouvées.
-G, --HILITE-SEARCH Supprime tous les surlignements de chaîne trouvées par la dernière recherche
-hn, --max-back-scroll=n Nombre de ligne max pour défiler en arrière. S'il est nécessaire de défiler en arrière plus de n lignes, l'écran est repaint.
-i, --ignore-case Ignore la casse lors des recherches. Ignoré si la recherche contient des lettres majuscules
-I, --IGNORE-CASE Comme -i, mais ignore la casse tout le temps
-jn, --jump-target=n Spécifie une ligne à l'écran où la ligne cible doit être positionnée
-J, --status-column Affiche un colonne de status à gauche de l'écran qui marque les lignes qui matchent la recherche
-kfilename, --lesskey-file=filename ouvre et interprète le fichier nommé (fichier lesskey). Peut être spécifié plusieurs fois
-K, --quit-on-intr Quitte avec un code 2 quand un caractère d'interruption est reçus
-L, --no-lessopen Ignore $LESSOPEN
-m, --long-prompt prompt comme more (verbeux), avec le % dans le fichier.
-M, --LONG-PROMPT prompt encore plus verbeux que more
-n, --line-numbers Supprime les numéros de ligne
-N, --LINE-NUMBERS Affiche les numéros de ligne au début de chaque ligne
-ofilenmae, --log-file=filename Copie l'entrée dans le fichier. Uniquement quand le fichier d'entrée est un pipe
-Ofilename, --LOG-FILE=filename comme -o, mais écrase un fichier existant sans demander confirmation
-ppattern, --pattern=pattern équivalent à +/pattern.
-Pprompt, --prompt=prompt Fournit un moyen d'adapter les trois styles rapides à vos préférences -Ps définis le prompt court, -Ph change le prompt pour l'écran d'aide, -Pm change le prompte moyen, -PM change le prompt long, P= change le prompt de la commande '=', -Pw change le message affiché en attendant les données (commande F)
-q, --quiet, --silent mode silencieux, utilise le "bell" visuel
-Q, --QUIET, --SILENT mode silencieux
-r, --raw-control-chars Affiche les caractères de contrôle sous forme brut.
-R, --RAW-CONTROL-CHARS comme -r, mais seul les séquences échappée ANSI "color" sont affichées.
-s, --squeeze-blank-lines Réduit plusieurs lignes vide contigües en une seule
-S, --chop-long-lines Ne revient pas à la ligne lorsque les lignes sont plus grandes que l'écran.
-ttag, --tag=tag Édite le fichier contenant ce tag.
-Ttagsfile, --tag-file=tagsfile Spécifie un fichier de tags
-u, --underline-special Affiche les tabulations, backspace et retours chariot.
-U, --UNDERLINE-SPECIAL les tabulations, backspace et retours chariot sont traité comme caractères de contrôle
-V, --version Affiche la version de less
-w, --hilite-unread Surligne temporairement la première nouvelle ligne après un défilement en arrière d'un écran
-W, --HILITE-UNREAD comme -w, mais pour les défilements supérieur à une ligne.
-xn,..., --tabs=n,... Définit la position des tabulations (ex: -x9,17 définit les tabulations aux position 9, 17, 25, 33, etc.) défaut: n=8
-X, --no-init Désactive l'envoi des chaînes d'initialisation et de dé-initialisation termcap au terminal
-yn, --max-frow-scroll=n Spécifie le nombre de ligne max pour le défilement en avant. au delà, l'écran est repeint
-[z]n, --window=n Change la taille de défilement d'écran par défaut à n lignes. (défaut: un écran)
-"cc, --quotes=cc Change les quotes des noms de fichiers
-~, --tilde N'affiche pas le tilde sue les lignes après la fin du fichier
-#, --shift Spécifie le nombre de position par défaut du défilement horizontal
--no-keypad Désactive l'envoi des chaînes d'initialisation et de dé-initialisation keypad au terminal
--follow-name avec -F, ré-ouvre périodiquement le fichier par nom et actualise son contenu
-- Sur la ligne de commande, marque la fin des options
+ si une option de la ligne de commande commence avec un +, le reste de l'option est une commande initiale de less

Édition de ligne

   En entrant une commande en bas de l'écran, certaines clés peuvent être utilisées pour manipuler la ligne de commande.

LEFTARROW, ESC-h Déplace le curseur un espace à gauche
RIGHTARROW, ESC-l Déplace le curseur d'un espace à droite
^LEFTARROW, ESC-b, ESC-LEFTARROW déplace le curseur d'un mot à gauche
^RIGHTARROW, ESC-w, ESC-RIGHTARROW Déplace le curseur d'un mot à droite
HOME, ESC-0 Déplace le curseur au début de la ligne
END, ESC-$ Déplace le curseur à la fin de la ligne
BACKSPACE Supprime le caractère à gauche du curseur, ou annule la ligne de commande si elle est vide
DELETE, ESC-x Supprime le caractère sous le curseur
^BACKSPACE, ESC-BACKSPACE Supprime le mot à gauche du curseur
^DELETE, ESC-X, ESC-DELETE Supprime le mot sous le curseur
UPARROW, ESC-k Récupère la précédente commande
DOWNARROW, ESC-j Récupère la commande suivante
TAB Complète le nom de fichier partiel
BACKTAB, ESC-TAB Comme TAB, mais cycle dans la direction inverse
^L Complète la partie manquante du fichier. S'il y'a plusieurs correspondances, ils sont tous entrées dans la ligne de commande
^U Supprime toute la ligne de commande
^G Supprime tout le ligne de commande et retourne le prompt principal

Pré-processeur d'entrée

   Il est possible de spécifier un pré-processeur pour less. Ce programme ou script écrira le contenu dans un fichier différent, appelé le fichier de remplacement. C'est de fichier qui sera affiché dans less, mais c'est le fichier initial qui sera indiqué à l'utilisateur. Un pré-processeur reçoit un argument, le fichier original, et une fois terminé, doit afficher le nom du fichier de remplacement sur son entrée standard. S'il ne fournis pas le fichier, less utilise le fichier original. la ligne de commande devrait inclure une occurrence de %s, qui sera remplacé par le nom de fichier quand le pré-processeur est invoqué.

  Quand less ferme un fichier ouvert de cette manière, il va appeler un autre programme, appelé le post-processeur, qui va effectuer les actions de nettoyage. Ce programme reçoit 2 argument, le fichier original et le fichier de remplacement. Il peut inclure 2 occurrence de %s, une est remplacée par le fichier original, l'autre par le fichier de remplacement.

Exemple, dans de nombreux systèmes Unix, ces 2 scripts vont permettre de conserver les fichiers compressés
lessopen.sh:
#! /bin/sh
case "$1" in
        *.Z) uncompress -
        if [ -s /tmp/less.$$ ]; then
                echo /tmp/less.$$
        else
                rm -f /tmp/less.$$
        fi
        ;;
esac
    
lessclose.sh:
#! /bin/sh
rm $2

   Pour les utiliser, définir les 2 variables: LESSOPEN="lessopen.sh %s" et LESSCLOSE="lessclose.sh %s %s".

  Il est aussi possible de définir un pré-processeur pour piper le fichier de donnée directement dans less, ce qui évite de dé-compresser tout le fichier avant l'afficher.


lesspipe.sh:
#! /bin/sh
case "$1" in
        *.Z) uncompress -c $1 2›/dev/null
        ;;
esac
    
avec LESSOPEN="|lesspipe.sh %s"

Jeux de caractères

   LESSCHARSET peut être utilisé pour sélectionner un jeu de caractère ( ascii, iso8859, latin1, latin9, dos, ebcdic, IBM-1407, koi8-r, next, utf-8, windows)

  Dans de rares cas, il peut être désirable d'adapter less pour utiliser un jeu de caractère autre que celui définis par LESSCHARSET. LESSCHARDEF peut être utilisée pour définir un jeu de caractère. Ça doit être une chaîne où chaque caractère dans la chaîne représente un caractère dans le jeu. Le caractère "." est utilisé pour un caractère normal, "c" pour control, et "b" pour binaire, Un nombre décimal peut être utilisé pour la répétition. Par exemple, "bccc4b" signifie que le caractère 0 est binaire, 1, 2 et 3 sont des control, 4, 5, 6 et 7 sont binaire, et 8 est normal, Tous les caractères après le dernier sont le même que le dernier, donc 9 à 255 seront normaux.

  Cette table montre la valeur de LESSCHARDEF qui est équivalent à chaque valeur pour LESSCHARSET:

        ascii 8bcccbcc18b95.b
        dos 8bcccbcc12bc5b95.b.
        ebcdic 5bc6bcc7bcc41b.9b7.9b5.b..8b6.10b6.b9.7b9.8b8.17b3.3b9.7b9.8b8.6b10.b.b.b.
        IBM-1047 4cbcbc3b9cbccbccbb4c6bcc5b3cbbc4bc4bccbc191.b
        iso8859 8bcccbcc18b95.33b.
        koi8-r 8bcccbcc18b95.b128.
        latin1 8bcccbcc18b95.33b.
        next 8bcccbcc18b95.bb125.bb

   Si ces variables ne sont pas définies, less recherche dans l'ordre: utf8 dans LC_ALL, LC_CTYPE, ou LANG, via setlocale, ou utilise latin1.

  Les caractères de contrôle et binaires sont affichés en vidéo inversé, en notation d'insertion (ex: ^A pour control-A) seulement si inverser le bit 0100 résulte en un caractère normal imprimable. Sinon, le caractère est affiché en nombre hexa. Ce format peut être changé en définissant LESSBINFMT. LESSBINFMT peut commencer par "*" et un caractère pour sélectionner l'attribut d'affichage: "*k" est clignotant, "*d" est en gras, "*u" est surligné, "*s" est inversé, "*n" est normal. Si LESSBINFMT ne commence pas par "*", l'attribut est assumé. Le reste de LESSBINFMT est une chaîne que peut inclure une séquence d'échappement style printf (a % suivi par x, X, o, d, etc.).

   Par exemple, s'il vaut "*u[%x]", les séquences binaires sont affichées en hexa surligné entouré par des crochets. (défaut: "*s‹%02X›"). LESSBINFMT doit faire moins de 31 caractères.

  Quand le jeu de caractère est utf8, la variable LESSUTFBINFMT agit similairement, mais s'applique à l'unicode. (défaut: "‹U+%04lX›"). Cette variable est lue après LESSBINFMT donc elle a toujours priorité.

  

   L'option -P permet de personnaliser les prompts. Certains caractères sont interprétés:

%bX Remplacé par l'offset de l'octet dans le fichier courant. X spécifie le ligne dont l'offset doit être utilisé, ou 't' pour la ligne du haut, 'm' pour la ligne du milieu, 'b' pour la ligne du bas, 'B' la ligne juste après la ligne du bas, et 'j' utilise la ligne cible comme spécifié par l'option -j.
%B Remplacé par la taille du fichier courant
%c Remplacé par le numéro de colonne apparaissant dans la première colonne de l'écran
%dX Remplacé par le numéro de page d'une ligne. La ligne à utiliser est déterminée par X comme pour %b
%D Remplacé Par le numéro de pages dans le fichier d'entrée.
%E Remplacé par le nom de l'éditeur ( $VISUAL ou $EDITOR )
%f Remplacé par le nom du fichier d'entrée
%F Remplacé par le dernier composant du nom du fichier courant
%i Remplacé par l'index du fichier courant dans la liste des fichiers d'entrée
%lX Remplacé par le numéro de ligne d'une ligne dans le fichier d'entrée. La ligne à utiliser est déterminé par X, comme dans %b
%L Remplacé par le numéro de ligne de la dernière ligne dans le fichier d'entrée
%m Remplacé par le nombre total de fichiers d'entrée
%pX Remplacé par le % dans le fichier courant, basé sur les octets. La ligne à utiliser est déterminé par X, comme dans %b
%PX Remplacé par le % dans le fichier courant, basé sur les numéros de ligne. La ligne à utiliser est déterminé par X, comme dans %b
%s Comme %B
%t Supprime les espace en trop.
%x Remplacé par le nom du prochain fichier

   Si un élément est inconnu, il est remplacé par '?'. Le format de la chaîne peut être changée en fonction de certaines conditions. un ? suivi par un caractère agit comme un 'IF'. Si la condition est vrai, tous les caractères après le '?' et jusqu'à un ',' sont inclus dans le prompt. Un ',' peut apparaître après un '?' pour indiquer un 'ELSE'.

?a Vrai si un caractère a été inclus dans le prompt
?bX vrai si l'offset de la ligne spécifiée est connue
?B Vrai si la taille du fichier courant est connus
?c Vrai si le texte est décalé horizontalement (%c n'est pas 0)
?dX Vrai si le numéro de page de la ligne spécifiée est connus
?e Vrai si à la fin du fichier
?f vrai s'il y'a un fichier d'entrée (pas de pipe)
?lX Vrai si le numéro de ligne de la ligne spécifiée est connue
?L Vrai si le numéro de la dernière ligne du fichier est connu
?m Vrai s'il y'a plus d'un fichier en entrée
?n Vrai si c'est le premier prompt dans un nouveau fichier d'entrée
?pX Vrai si le % dans le fichier courant, basé sur l'offset, de la ligne spécifiée est connue
?PX Vrai si le % dans le fichier courant, basé sur le nombre de ligne, de la ligne spécifiée est connue
?s comme ?B
?x Vrai si le fichier courant n'est pas le dernier fichier

Exemples

Affiche le nom du fichier, s'il est connu, sinon affiche "Standard input"
?f%f:Standard input
Affiche le nom du fichier s'il est connu, suivi par le numéro de ligne s'il est connu, sinon le % s'il est connu, sinon l'offset s'il est connu, sinon un '/' est affiché
?f%f .?ltLine %lt:?pt%pt\%:?btByte %bt:-...
Affiche le nom du fichier si c'est le premier prompt, suivi par "file N of N" s'il y'a plus d'un fichier. Affiche "(END)" si c'est la fin du fichier suivi par le nom du prochain fichier s'il y'en a un. tout espace en trop est supprimé. C'est le prompt par défaut.
?n?f%f .?m(file %i of %m) ..?e(END) ?x- Next\: %x..%t
Prompt par défaut (-m)
?n?f%f .?m(file %i of %m) ..?e(END) ?x- Next\: %x.:?pB%pB\%:byte %bB?s/%s...%t
Prompt par défaut (-M)
?f%f .?n?m(file %i of %m) ..?ltlines %lt-%lb?L/%L. :byte %bB?s/%s. .?e(END) ?x- Next\: %x.:?pB%pB\%..%t
Message par défaut produitpar la commande =
?f%f .?m(file %i of %m) .?ltlines %lt-%lb?L/%L. .byte %bB?s/%s. ?e(END) :?pB%pB\%..%t
Valeur par défaut pour LESSEDIT:
%E ?lm+%lm. %f

Sécurité

   Si $LESSSECURE vaut 2, less se lance en mode sécure. Les fonctionnalités suivante sont désactivées:

        ! Commande shell
        | Commande pipe
        :e Commande examine
        v Commande d'édition
        s, -o Fichiers de log
        -k Utilisation des fichiers lesskey
        -u Utilisation des fichiers de tags
        Les métacaractères, comme '*'
        La complétion des noms de fichier (TAB, ^L)

Compatibilité

   Si $LESS_IS_MORE vaut 1, less agit conforme à la commande posix more.

Variables d'environnement

COLUMNS Définit le nombre de colonnes dans l'écran. Prend précédence sur $TERM.
EDITOR Nom de l'éditeur par défaut
HOME Répertoire personnel de l'utilisateur
HOMEDRIVE, HOMEPATH La concaténation des ces 2 variables est le nom du home si $HOME n'est pas définis
INIT Nom du répertoire init de l'utilisateur
LANG Langage à utiliser pour déterminer le jeu de caractères
LC_CTYPE Langage à utiliser pour déterminer le jeu de caractères
LESS Option à passer à less
LESSANSIENDCHARS caractère qui peut terminer une séquence d'échappement de couleur ANSI (défaut: m)
LESSANSIMIDCHARS caractère qui peut apparaître entre le caractère ESC etle caractère de fin dans une séquence d'échappement de couleur ANSI (défaut: "0123456789;[?!"'#%()*+ ")
LESSBINFMT Format pour l'affichage des caractère non-contrôle, non-imprimables
LESSCHARDEF Définis un jeu de caractères
LESSCHARSET Définis un jeu de caractères prédéfinis
LESSCLOSE Ligne de commande pour invoquer le pré-processeur
LESSECHO Nom du programme lessecho, nécessaire pour étendre les méta-caractères
LESSEDIT Chaîne prototype. voir PROMPTS
LESSGLOBALTAGS Nom de la commande utilisé par -t pour trouver les tags globaux
LESSHISTFILE Nom du fichier d'historique des commandes de recherche et des commandes shell (défaut: "$HOME/.lesshst"
LESSHISTSIZE Nombre maximum de ligne à sauver dans le fichier d'historique
LESSKEY Nom du fichier lesskey par défaut
LESSKEY_SYSTEM Nom du fichier lesskey système par défaut
LESSMETACHARS Liste des caractères considérés comme méta-caractères par le shell
LESSMETAESCAPE Préfix à ajouter avant chaque méta-caractères envoyé au shell. Si vide, les méta-caractères ne sont pas passés au shell
LESSOPEN Ligne de commande pour invoquer le pré-processeur
LESSSECURE A 1, less est en mode sécure
LESSSEPARATOR Chaîne à ajouter au nom du répertoire dans la complétion des nom de fichier
LESSUTFBINFMT Format pour afficher les Unicodes non-imprimables
LESS_IS_MORE Emule more
LINES Définis le nombre de lignes à l'écran. Prend précédence sur $TERM
PATH Chemins de recherche de l'utilisateur
SHELL Shell courant de l'utilisateur
TERM Type de terminal
VISUAL Nom de l'éditeur par défaut
^
02 février 2014

htmlpdflatexmanmd




lessecho

lessecho

Étend les métacaractères. Il affiche ses arguments sur la sortie standard, mais ceux qui contiennent des espaces sont mis entre guillemets.

OPTIONS

-ox Spécifie x comme caractère quote ouvrante
-cx Spécifie x comme caractère quote fermante
-pn Spécifie n comme caractère quote ouvrante, comme entier
-dn Spécifie n comme caractère quote fermante, comme entier
-mx Spécifie que x est un métacaractère
-nn  Spécifie que n est une métacaractère. un entier
-ex Spécifie que y est le caractère d'échappement pour les métacaractères
-fn Spécifie que n est le caractère d'échappement pour les métacaractères, un entier
-a Spécifie que tous les arguments doivent être entre guillemets.
^
02 février 2014

htmlpdflatexmanmd




lessfile

lessfile, lesspipe

préprocesseur pour less

   lessfile et lesspipe sont des programmes qui sont utilisés pour modifier la manière dont le contenus d'un fichier est affiché dans less. Celà signifie que less peut automatiquement des fichiers compressés.

  lesspipe va jeter le contents/info sur stdout et less va les lire à mesure qu'ils arrivent. Celà permet de ne pas attendre de tout décoder pour que less ne commence à afficher le contenu.

  lessfile va jeter le contents/info sur stdout dans un fichier que less va ensuite lire. une fois terminé, lessfile va supprimer le fichier.

  pour utiliser lesspipe ou lessfile, rajouter dans le script de login:

  eval "$[lessfile)"

  ou

  eval "eval $(lesspipe)"

Type de fichiers reconnus

   Les types de fichier suivant sont reconnus par leur extension:

*.a
*.arj
*.tar.bz2
*.bz
*.bz2
*.deb, *.udeb
*.doc
*.gif, *.jpeg, *.jpg, *.pcd, *.png, *.tga, *.tiff, *.tif
*.iso, *.raw, *.bin
*.lha, *.lzh
*.tar.lz, *.tlz
*.lz
*.7z
*.pdf
*.rar, *.r[0-9][0-9]
*.rpm
*.tar.gz, *.tgz, *.tar.z, *.tar.dz
*.gz, *.z, *.dz
*.tar
*.tar.xz, *.xz
*.jar, *.war, *.xpi, *.zip
*.zoo

Filtres utilisateur

   Il est possible d'étendre cet préprocesseurs. Créer le fichier .lessfilter et le placer dans le home. Il est important que ce programme retourne un code de sortie correct: 0 is ce programme gère l'entrée, 1 si lesspipe/lessfile doivent la gérer. Exemple:


#!/bin/sh
case "$1" in
    *.extension)
        extension-handler "$1"
        ;;
    *)
    exit 1
esac
exit 0
    
^
02 février 2014

htmlpdflatexmanmd




lesskey

lesskey

Spécifie des key bindings pour less

   Le fichier d'entrée est un fichier texte qui les décris ou '-' pour l'entrée standard. Si aucun fichier n'est spécifié, $HOME/.lesskey ou $INIT/lesskey.ini. Le fichier de sortie est un fichier binaire lu par less.

  Le fichier d'entrée contient des sections, chacune commençant avec une ligne qui identifie le type de section. Les sections possibles sont:

        #command Définis de nouvelles clé de commande
        #line-edit Définis de nouvelles clé d'édition de ligne
        #env Définis de nouvelles variables d'environnement

Section Commande

   Cette section a la forme: string ‹whitespace› action [extra-string] ‹newline›

        whitespace est une séquence d'un ou plusieurs caractères blanc.
        string est la ou les clés (max: 15) qui invoquent l'action
        action est le nom de l'action less, de la liste ci-dessous
        string peut contenir les caractères suivant:

                \b BACKSPACE
                \e ESCAPE
                \n NEWLINE
                \r RETURN
                \t TAB
                \ku UP ARROW
                \kd DOWN ARROW
                \kr RIGHT ARROW
                \kl LEFT ARROW
                \kU PAGE UP
                \kD PAGE DOWN
                \kh HOME
                \ke END
                \kx DELETE

           un '\' suivi par un autre caractère sera interprété littéralement. Une action peut être suivie par une chaîne supplémentaire, qui est parsé dans less dès que l'action est effectuée. Peut-être utile pour étendre les fonctionnalités d'une commande.

Exemple

Le fichier d'entrée suivant décris le jeu de clés par défaut utilisé par less:
#command
\r forw-line
\n forw-line
e forw-line
j forw-line
\kd forw-line
^E forw-line
^N forw-line
k back-line
y back-line
^Y back-line
^K back-line
^P back-line
J forw-line-force
K back-line-force
Y back-line-force
d forw-scroll
^D forw-scroll
u back-scroll
^U back-scroll
\40 forw-screen
f forw-screen
^F forw-screen
^V forw-screen
\kD forw-screen
b back-screen
^B back-screen
\ev back-screen
\kU back-screen
z forw-window
w back-window
\e\40 forw-screen-force
F forw-forever
R repaint-flush
r repaint
^R repaint
^L repaint
\eu undo-hilite
g goto-line
\kh goto-line
‹ goto-line
\e‹ goto-line
p percent
% percent
\e[ left-scroll
\e] right-scroll
\e( left-scroll
\e) right-scroll
{ forw-bracket {}
} back-bracket {}
( forw-bracket ()
) back-bracket ()
[ forw-bracket []
] back-bracket []
\e^F forw-bracket
\e^B back-bracket
G goto-end
\e› goto-end
› goto-end
\ke goto-end
= status
^G status
:f status
/ forw-search
? back-search
\e/ forw-search *
\e? back-search *
n repeat-search
\en repeat-search-all
N reverse-search
\eN reverse-search-all
& filter
m set-mark
' goto-mark
^X^X goto-mark
E examine
:e examine
^X^V examine
:n next-file
:p prev-file
t next-tag
T prev-tag
:x index-file
:d remove-file
- toggle-option
:t toggle-option t
s toggle-option o
_ display-option
| pipe
v visual
! shell
+ firstcmd
H help
H help
V version
0 digit
1 digit
2 digit
3 digit
4 digit
5 digit
6 digit
7 digit
8 digit
9 digit
q quit
q quit
:q quit
:q quit
ZZ quit

Précédence

   Les commandes lesskey prennent précédence sur les commandes par défaut de less.

Exemple

Le fichier d'entrée suivant décrit le jeu par défaut de clé d'édition de ligne utilisé par less:
#line-edit
\t forw-complete
\17 back-complete
\e\t back-complete
^L expand
^V literal
^A literal
\el right
\kr right
\eh left
\kl left
\eb word-left
\e\kl word-left
\ew word-right
\e\kr word-right
\ei insert
\ex delete
\kx delete
\eX word-delete
\ekx word-delete
\e\b word-backspace
\e0 home
\kh home
\e$ end
\ke end
\ek up
\ku up
\ej down
^G abort

Section Variables d'environnement

Cet exemple définie le jeu de caratères à latin1:
#env
LESS = -i
LESSCHARSET = latin1
^
01 février 2014

htmlpdflatexmanmd




lexgrog

lexgrog

Parse les informations d'en-tête dans les pages de manuel. Lit la liste des fichiers donnés comme page de manuel ou pages cat et affiche leur nom et description comme utilisé par apropos et whatis. La liste des filtre de pré-traitement requis sont passés à nroff ou troff ou les 2

OPTIONS

-m, --man Parse l'entrée comme fichier source de page man.
-c, --cat Parse l'entrées comme page de man préformattée
-w, --whatis Affiche le nom et la description depuis l'en-tête, comme utilisé par whatis et apropos
-f, --filters liste des filtres de pré-traitement
encoding, --encoding=encoding Définis l'encodage pour les pages.

Exemples

lexgrog man.1
man.1: "man - an interface to the on-line reference manuals"
lexgrog -fw man.1
man.1 (t): "man - an interface to the on-line reference manuals"
lexgrog -c whatis.cat1
whatis.cat1: "whatis - display manual page descriptions"
lexgrog broken.1
broken.1: parse failed
^
10 octobre 2011

htmlpdflatexmanmd




Le Chorus

Le Chorus

l'effet chorus

   Les effets de chorus sont créés à l'aide d'un delai assez court, modulé par un oscillateur basse fréquence. La modulation apportée à ce délai particulièrement court apporte des variations très légères de la hauteur de note. Une fois mélangées au son direct, ces transpositions apportent au son un effet de chorus; quand au signal module, seul il ne donne qu'un effet Vibrato.

   Le Flanger est similaire au chorus, mais se différencie par une ré-injection et la longueur du délai. Le retard sur le chorus est d'environ 10-20 ms alors qu'il est plutôt de 1 - 10 ms sur le flanger.

   Le chorus produit un son chatoyeux, plein en multipliant la source initiale. À l'origine, ces effets étaient utilisés pour donner du corps au pistes et aux guitares sans colorer le son. Les effets de chorus sont souvent utilisés avec les réverbérations à plaque, les échos et autres effets de réverbération.

Les réglages

Speed: Règle la vitesse du LFO (ou vitesse de modulation du chorus, ou encore fréquence). des temps de 10-20 ms sont généralement utilisés
Depth: Détermine la profondeur de la modulation du chorus (également nommé intensité)

   Quelques chorus permettent d'autres contrôles:

Delay: modifie la longueur du delay Phase Reversed: Inverse la phase sur le canal droit mais uniquement sur le signal traite. Permet d'élargir l'image stéréo
LFO Curve: Type de courbe de LFO. Généralement on trouve TRI, SIN, et Up, mais on peut parfois trouver l'onde Square
LFO Phase: Décale la phase des LFO sur les sorties droite et gauche

Quelques Chorus

   Le TC Electronic 2290 est un multi-effet qui produit l'un des meilleur Chorus du marches, il est base sur un rapport vitesse/profondeur (Speed/Depth) qui utilise le nombre d'or (golden ratio), ce qui garantit un effet de Chorus harmonieux quel que soit le réglage. Le FireworX (Multi-effet haut de gamme de TC Electronic) propose ce chorus issue de la 2290 et permet de désactiver ce ratio, afin d'obtenir un chorus plus extrême.

   Le multi-effet de Lexicon, le MPX 550 offre des chorus stéréo, hérite de la Lexicon PCM 80, créant un son aérien riche qui simule le son de sources multiples a partir d'une seule. Ces effets sont impressionnants sur une guitare acoustique ou sur une électrique en son clair. Ils utilisent six circuits de retard aléatoires indépendants dont la panoramique varie dans le champ stéréo.
^
10 octobre 2011

htmlpdflatexmanmd




Le De-esseur

Le De-esseur

l'effet de-esseur

   Nous connaissons tous les 'ess' (appelées aussi les sibilantes) que produise les orateurs et les chanteurs à travers un microphone lors d'une prononciation d'une syllabe qui produit une énergie maximum dans le micro. Beaucoup d'enregistrements vocaux contiennent ces sibilantes, les voix fortes, un mauvais enregistrement, ou simplement beaucoup de mots contenant des 'ess'. Les instruments à vents, par exemple, peuvent également créer un bruit aiguë. Il est donc nécessaire de contrôler ces 'ess', mais aussi les son en 'shh' et 'chh'.

   Le dé-esseur est un compresseur doté d'un sidechain filtré qui permet de cibler une plage de fréquences précise qui est utilisée contrôler la compression, cette atténuation se fait ainsi uniquement sur la plage de fréquence désirée au lieu d'une compression de toute la bande du signal.

- Les sons 'ess' des voix d'homme se situent généralement, autour de 4500 Hz,
- Les sons 'shh' des voix d'homme si situent un octave plus bas que les 'ess', autour de 3385Hz. L'atténuation doit être très modérée dans ces fréquences.
- Les sons 'ess' des voix de femme se situent généralement autour de 6779 Hz
- Les sons 'shh' des voix de femme se situent généralement autour de5077 Hz

   Le dé-esser doit de préférence être placé avant l'égaliseur et la compression de la voix. Utiliser le Dé-esser en mastering d'une musique rock pour atténuer les fréquence dominantes des cymbales et pédale charleston de la batterie est très efficace.

   Le dé-esser est très important pour les enregistrement vocaux, mais peut être efficace sur les fréquences aiguë gênantes que produisent certain instruments de musique comme les instruments à cordes, ou encore les cymbales d'une batterie peuvent être également contrôlée par un dé-esser. Si vous ne possédez pas de dé-esseur, vous pouvez utiliser un compresseur doté d'un signal sidechain pouvant être filtré (Waves C1, Tc-Electronic Triple-C) ou utilisez un égaliseur , mais là le résultat sera beaucoup moins efficace. Le Waves DeEsser est un bon de-esseur qui permet de cibler très facilement les 'ess' en permettant une écoute solo du signal sidechain filtré.

^
10 octobre 2011

htmlpdflatexmanmd




Le Delay

Le Delay

l'effet delay

   Les delay et les échos répètent un son en un court laps de temps après la première fois. L'effet le plus simple (et le plus vieux) est l'écho à bande - une simple répétition 100 ms après le signal initial. L'écho à bande fut notamment beaucoup utilisé sur la voix d'Elvis Presley et sur les pistes de guitare Rockabilly. L'écho à bande délivre de multiple répétitions lorsque le signal de sortie est ré-injecté en entrée. Une seule répétition se transforme en de multiples à chaque fois plus faible et plus étouffée que la précédente. Cet étouffement est caractéristique des enregistrements analogiques à bande. Les delay numériques ne possèdent pas cette caractéristique: chaque répétition est exactement semblable au signal d'entrée et seul le niveau varie d'une répétition à l'autre.

   L'écho à bande et le delay numérique sont tous les deux très utiles, mais différents. L'écho à bande possède un son plus chaud se détachant du son original; le delay numérique délivre une copie parfaite du signal initial. Avec les effets d'écho et de delay, les répétitions tombent en rythme avec la musique. Il est important de faire coïncider les répétitions en rythme avec la musique

   Dans la nature, le délai se manifeste des que l'on se trouve en présence d'une paroi réfléchissante; il faut au moins deux surfaces en regard pour qu'apparaisse un écho. Pour que notre oreille perçoive une répétition audible, la durée de ce retard doit être d'au moins 20 ms - soit 1/50e de seconde. Cela correspond, pour un son, à un parcours de 6.8 mètres. Quand on passe à une échelle plus petite, les dimensions d'une pièce par exemple, les rebonds successifs des sons sur les parois ne sont plus perçus séparément par l'oreille, qui les « fusionne »: les échos sont devenus réverbération.

   Il est loin le temps ou, pour obtenir un écho, on avait recours à un magnétophone équipé d'un varispeed pour faire varier la durée entre les répétitions, ou, dans le meilleur des cas, à une « chambre d'écho », sorte de magnétophone dédié, ou une boucle de bande passait devant plusieurs têtes d'écartement réglable. Dispositif perfectionné par Pink Floyd, qui n'hésita pas, pour les longs délais de Us And Them, sur 'Dark Side Of The Moon', à faire rebondir le signal sur plusieurs pistes d'un 8 pistes varispeedé, cumulant ainsi les retards procures par chacune. Citons aussi Jean-Michel Jarre, qui inséra des réducteurs de bruits Dolby A sur ses Revox pour 'Oxygène' ou 'Equinoxe'.

Les types de délai

   Les delay audio sont très largement utilises en studio. Il y en a beaucoup de versions, analogiques, numériques, acoustiques, a bande etc. avec leur propres caractères.

Le delay Multi-tap Une ligne de delay joue simplement une copie du signal original suivant un retard (delay) à une certaine durée de temps. Quand vous ajoutez ces copies retardées, beaucoup d'effets extraordinaires peuvent être crées. Quand vous jouez différents signaux retardés avec l'original, ou chaque signal est retarde différemment, vous obtenez un delay multitap. Un multi-tap est simplement un delay a sorties multiples (tap) le long du delay.Les reverbes numériques opèrent en utilisant un principe similaire. En ajoutant des copies miroirs de l'original à lui même et en réduisant le gain à chaque fois. L'effet d'un écho dans un grand espace peut être reproduit. Les delay multi-tap permettent en outre de contrôler le nombre exacte de répétitions et de placer chaque répétition précisément (fonction rythmique), avec des fonctions permettant de décaler aléatoirement certaines répétitions, permettant "d'humaniser" la ligne de delay, ainsi que des fonctions de quantisation.
Delay Ping-Pong Le delay ping-pong permet de déplacer le son dans la champ stéréo de façon synchronisé avec le temps de retard. Il est possible de placer alternativement les répétitions à droite et à gauche (L-R ou encore L-C-R), ou de placer le delay dans le champ stéréo (un delay de 5 répétitions utilise 5 positions de panoramique de gauche à droite).
Delay Dynamique Crée par TC Electronic sur la mythique 2290 TC, Le delay dynamique permet d'atténuer le signal de sortie à un niveau déterminé lorsque le signal d'entrée dépasse un certain seuil
Delay Reverse Les delay reverse permettent de jouer des copies inversées (copies miroir) du signal. Il est possible de choisir les copies qui sont inversée: la première répétition est inversée, les autres sont jouées normalement ; les répétitions sont jouées normalement sauf la dernière qui est inversée ; les répétitions paires sont inversées ; les répétitions impaires sont inversées.

Les contrôles

Delay: Temps de retard de la ou les répétitions
Feedback: % de réinjection du signal à l'entrée du delay (permet de déterminer le nombre de répétitions). à 0, vous n'avez qu'une répétition
Feedback Hi Cut: Les dernières technologies numériques rendent aujourd'hui possible la reproduction extrêmement fidèle d'un signal d'entrée ; un traitement mis a profit pour les répétitions d'un effet de delay, par exemple. Ce traitement n'est pas forcement souhaitable avec des répétitions longues appliquées au signal d'une guitare ; des répétitions trop précises peuvent créer un effet peu avantageux au son moins homogène. Pour compenser ce phénomène, essayez d'utiliser la répétition du filtre coupe-haut, émulant le traitement des unités de delay analogique ou à bande.
Feedback Lo Cut: L'application d'un retard sur un signal riche en fréquences graves entraîne parfois l'apparition d'un ronflement. Si ce phénomène se produit, essayez d'étouffer le registre grave au moyen du paramètre Lo Cut plutôt que de réduire le niveau général du delay.

   La ligne de delai PingPong vous permet de contrôler la panoramique des répétitions de gauche a droite dans une configuration stéréo. Certaines techniques ont déjà fait leurs preuves :

   Essayez d'appliquer le delay PingPong sur le déclenchement des notes à attaque progressive. Cette technique confère une forte envergure au son. Vous pouvez également essayer d'utiliser le delay PingPong pour répéter des sons de batterie ; ou utilisez le delay pour créer un gros son sample avec une guitare Lead.

   D'autres fonctions permettent d'élargir le delay dans le champ stéréo, ou pour ajouter un effet de Chorus pour adoucir le delay, ou encore le gain et la position stéréo de chaque Tap, etc. Essayez le plug-in Waves SuperTap, qui possède une ligne de 6 delay et permet d'émuler beaucoup de type de delay.
^
11 octobre 2011

htmlpdflatexmanmd




Le Detune

Le Detune

l'effet detune

   Le Detune est un effet de désaccordage. Ces effets de désaccord ajoutent un son retardé ou transposé au signal source, épaississant le son. Ceci crée une simulation particulièrement fidèle du doublage de piste. Ces effets offrent également une excellente alternative aux effets de Chorus, empruntant la richesse du Chorus sans le balayage audible crée par la vitesse du Chorus. Certains effets de Detune vont jusqu'à 4 voix, une paire de voix par canal. Plus le désaccord est important, plus la paire est dé-accordée, délivrant un son velouté sans avoir besoin de mélanger un signal non traité.

   Un instrument qui utilise naturellement cet effet de désaccordage est l'accordéon. L'effet peut être subtil ou très épais (les amateurs parlent de "plein jeu"). Le principe consiste à jouer 2 ou 3 notes en même temps, la note juste, une légèrement plus aiguë, et une légèrement plus grave, donnant le son "musette" que nos chers grand-parents adorent...

^
10 octobre 2011

htmlpdflatexmanmd




Le Dithering

Le Dithering

l'effet Dithering

   Lorsque vous travaillez à une résolution plus élevé que la résolution finale, vous êtes amené à réduire la nombre de bits nécessaire à la représentation du signal. Une troncation est opéré. Par exemple vous travaillez en 24 bits, et vous voulez sortir votre mix sur un CD en 16 bits. Une troncation des 8 bits supérieurs est opérée. Ce n'est pas tout : la plupart des modules de traitements numériques (plug-ins) opèrent avec une résolution plus élevé, puis tronque les bits en trop pour revenir à la résolution d'entrée.

   Par exemple, lorsqu'un signal 24 bits est traité, le module de traitement calcule en 48 bits voir 64 bits, pour une traitement plus précis du signal. A la sortie du module, une troncation s'opère, avec une perte des bits supérieur. Une telle troncation crée une distorsion non-linéaire audible dans les signaux faibles, et une perte de qualité et de fidélité devient importante si le signal est traité plusieurs fois de suite. L'oreille humaine utilise les informations des signaux faibles pour construire une image mentale de l'espace stéréo. Une perte de la notion d'espace et de la transparence apparaît avec la perte de bits dut à la troncation des traitements numériques.

   La solution est d'appliquer un dither et un noise shaping au signal chaque fois que la résolution est augmentée puis réduite.

   Avant de re quantifier (réduire le nombre de bit pour réduire la résolution), un léger bruit (appelé dither) très précisément contrôlé, est ajouté au signal. Ceci permet de convertir la distorsion non-linéaire des signaux faibles (causés par une troncation) par une bruit stable (appelé 'hiss'). Ceci enlève toutes traces de non-linéarité des signaux faibles, mais génère un léger bruit de fond. L'augmentation du niveau du bruit de fond n'est pas idéal pour des applications de haute qualité audio, mais le niveau perçu du dither peut être réduit en contrôlant le bruit (noise-shaping), en le plaçant dans le spectre audio où l'oreille humaine est la moins sensible.

   Le principe du dither est simple : "capturer" la meilleur qualité audio dans une résolution inférieur depuis une résolution supérieur.

   Il existe de plus en plus de plug-ins de dithering, le Waves L1-Ultrmaximizer possède un la technologie IDR (Increase Digital Resolution), fruit de plusieurs années de recherche, qui semble être le meilleur dither du moment, et permet un contrôle plus étendu en proposant plusieurs type de dither et de noise-shaping. Le module UV-22 de Steinberg, incorporé dans le séquenceur Cubase, est un dither très efficace également, et optimiser pour sortir un mix en 16 bits. Les modules Tc-electronics possèdent également un dither, qui lui n'est pas contrôlable, ci ce n'est la résolution de sortie, mais est excellent et optimisé pour ses modules.

   Vous l'aurez compris, le dithering est très important quand vous travaillez en numérique, il évite de gâcher tout le boulot que vous avez fait, et permet de supprimer l'un des défauts le plus important du traitement numérique. N'hésitez pas à essayer le plug-in Waves L1-Ultramaximizer, qui d'une part vous donnera un mix très pêchu et optimal et d'autre part d'appliquer un dither tout simplement merveilleux, et doté de pas mal de réglages permettant de l'utiliser dans toutes sorte de travaux, en mastering audio haute qualité, ou même en production multimédia basse qualité.

^
11 octobre 2011

htmlpdflatexmanmd




Le Doppler

Le Doppler

l'effet Doppler

waves doppler
   Doppler est l'effet entendu quand une source sonore, tel qu'une voiture ou un train passe, et le ton change. Les son sont plus haut. Quand le son approche, et plus bas quand le son s'éloigne. Le processeur Waves Doppler est très facile à opérer et a un petit ensemble de contrôles. Il est basé "sur la réalité" dont certains contrôles simulent les lois de physique (air humide, gain qui change avec la distance).

   Cependant vous pouvez régler les valeurs de Doppler pour travailler aussi bien en dehors de ces lois ; il est dit qu'il y a " la réalité ", et il y a " Hollywood", quand les effets sont ressentit avec leur perception appropriée. Quelquefois ce qu'une audience attendrait est de ne pas se baser sur les lois de physique du tout !

Une petite histoire

   L'effet Doppler a été nommé par un Physicien Australien, Christian Doppler (1803-1853), qui a théorisé le phénomène des ondes sonores depuis une source en mouvement qui seraient plus proches quand le son se rapproche, et l'inverse quand le son s'éloigne. La fréquence qui est entendu va changer. Les ondes qui se rapprochent vont avoir une hauteur plus élevé, et les ondes qui s'éloignent auront une hauteur plus basse. C'est due au fait que la vitesse du son est relativement constante (ça dépend de l'altitude, de la température et le l'humidité).

   Mr. Doppler a prouvé sa théorie en 1842 en plaçant un trompettiste sur un train qui passait à vitesses variées. Il a également placé un musicien au sol avec lui qui pouvait prendre soigneusement note des changements de hauteur de la trompette sur le train. Cela a permis de prouver sa théorie, et il a aussi théorisé le fait que cela s'applique également sur la lumière, mais il n'a pas pu créer un preuve pour ça.

   Plus tard, un scientifique appelé Fizeau a généralisé le théorème de Doppler et a vraiment trouvé que l'effet Doppler était applicable à la lumière et autres propagation d'ondes à travers un milieu. Par exemple, c'est comme cela que la police mesure la vitesse d'une voiture en mouvement, et comment a été théorisé l'expansion de l'univers (en observant le "red-shift", ou les fréquences abaissées des étoiles en mouvement loin de notre perspective).

Waves Doppler - Contrôles et interface

Space Display Cette fenêtre affiche la trajectoire en face de l'auditeur, qui est localisé au point 0.0 (le point rouge)
Direction Contrôle la direction de la trajectoire
Elapse Time Compteur de temps écoulé de la trajectoire
Track La ligne orange est la trajectoire
Track Time Contrôle le temps total, en seconde, de la trajectoire
Center Time C'est la 'crête' de la hauteur de l'effet qui est par défaut au milieu du temps total de la trajectoire.
Mode Choisir si la trajectoire est effectuée une fois ou en boucle
Trigger En mode énergie, l'effet démarre quand un signal audio est détecté ; en mode manual, l'effet démarre à chaque fois que l'on click sur ce bouton

Master Reality Control

Gain Quand les sons sont à distance, leur volume est faible. A 0% il n'y a aucun changement de gain, à 100%, l'effet est le plus réaliste, et à 200% l'effet est exagéré.
Pan Waves Doppler produit une sortie stéréo basée sur le trajet du son. à 0% il n'y a pas de stéréo, à 100% la panoramique est la plus réaliste et à 200% on obtient une très large stéréo.
Pitch L'effet Doppler est basé sur le changement de hauteur des sons. Vous pouvez réduire cet effet. à 0% il n'y a pas de changement, à 100% l'effet est le plus réaliste et à 200% le pitch est exagéré.
Air Damp Avec l'augmentation de la distance, le son voyage dans l'air et les hautes fréquences sont diminuée. à 0% il n'y a pas d'effet, à 100% l'effet est le plus réaliste et à 200% l'effet est exagéré.
Reverb Contrôle le taux de reverb à la sortie Reverb Time : Temps total de la reverb en s
Reverb Brightness Contrôle le caractère des hautes fréquences de la reverb

waves doppler
waves doppler

Presets

   Les presets sont des suggestions et des exemples, il constituent donc une bonne base de départ pour paramétrer l'effet à vos besoins.

Doppler Reset Ce preset possède tous les paramètres par défaut. L'effet va de gauche à droite avec un exagération du pitch et du pan. Un peu de reverb ajoute la notion d'espace et augmente la distance
Superfast Flyby1.9sec Un effet très court, pour les missiles, guerres spaciales, et objets passant très proche de l'auditeur.
Long, passing close,20sec Effet long et très réaliste, pour des trains, hélicoptères, voitures...
Long approach and away, 20sec Un autre effet long et réaliste avec une approche plus longue. Le Pan est seulement de 30% pour éviter les balances trop extrêmes, la reverb ajoute un effet souillé qui peut simuler un tunnel ou un trajet le long des immeubles.
Medium in/out,5.5sec Effet modéré, utilisé avec des voitures qui passent dans la scène par exemple
Medium, passing fast, 10sec Une version plus longue et rapide avec une courbe plus dure, un gain et un pitch augmentés.
Short in, long away,10sec Un effet classique, avec une approche rapide et un temps de passage très long, qui peut être utilisé pour les balles de fusils comme dans les film.
HighSpeedPassBy,4sec Très proche du point central et un temps très court qui donne l'effet d'une très grande vitesse.
Fast in/out U.turn Le son approche de l'auditeur, et repart rapidement, l'effet est extrême.
RightApproach,AwayCenter,10sec Le son vient de la droite et ne dépasse pas la ligne centrale
RocketFlyBy,5sec Une variation de HighSpeedPassBy
RocketFlyBy,3sec Plus rapide que le preset précédent
StraightAway,15sec Le pitch est constant, simule un déplacement d'objet
StraightIn,15sec Identique au preset précédent, mais le pitch est plus haut que la réalité et la gain augmente quand la source s'approche.
Les autres presets sont des effets purs, non réalistes.
^
11 octobre 2011

htmlpdflatexmanmd




Le Flanger

Le Flanger

l'effet flanger

   Le flanger a été vraisemblablement crée dans le studio Abbey Road Studios, en appliquant une pression sur le bord de la bande d'une cassette, d'où 'Flange', pour ralentir la machine. Le principe était 2 machines (identiques) à bande placées dans un enregistrement et recevaient la même entrée, et la sortie allait dans la table. La phase était inversée quelquefois sur une des sorties pour un effet plus 'gros'. Une des bandes était périodiquement freinée puis accélérée par l'ingénieur en pressant son pouce sur le rebord. Il en résultait un série d'annulations de phase et d'accentuation du signal avec un son d'avion a réaction caractéristique.

   George Martin a repris cette situation en utilisant un transformateur a voltage variable pour changer plus précisément la vitesse d'une machine, alignant doucement un machine une machine un peu plus vite et l'autre un peu plus lente. D'autres personnes l'ont ensuite utilise pour créer des effets de flange, chorus et d'autres effets connus par tous ceux qui connaissent les albums des beatles.

   Éventuellement, cette fonction peut être créée en utilisant une ligne de delays analogiques pour prendre la place de la machine a bande, qui devait être rembobinée toutes les 25 min. Le flanger en ligne de delays peut être semi-automatise en plaçant un LFO. Le LFO permet de changer le temps de delay d'une des lignes de delay. Certains appareils n'ont qu'une ligne de delay, mais pour émuler correctement, 2 lignes sont requises, une ligne ira plus vite et plus lentement que l'autre. Avec une seule ligne de delay, vous ne pouvez pas aller plus vite que le signal source, ce qui donne un effet appelé 'Thru to null', ou les signaux sont parfaitement égaux des 2 côtés.

   Les effets de flanger sont crées a l'aide d'un delai assez court, module par un oscillateur basse fréquence. La modulation apportée à ce delai particulièrement court apporte des variations très légères de la hauteur de note. Ce signal est réinjecté (c'est principalement ce qui le différencie du Chorus), Il se crée un série d'annulations de phase et d'accentuation du signal, le son donne parfois l'effet d'un d'avion a réaction. Les flangers basés sur des lignes de delay possèdent des delais à 2 taps - un par canal. Le premier Tap est fixe et le second balaye sur le premier. Le mixage des deux Taps crée l'effet de Flanger.

Les reglages

Rate/Speed Règle la fréquence du LFO en Hz, donc la vitesse de modulation de l'effet, généralement utilise entre 1 et 10 ms
Depth Contrôle l'amplitude du LFO (profondeur de l'effet de Flanger ou intensité)
Delay Règle le delay de base de l'effet
Feedback Taux de réinjection du signal (il est parfois possible d'inverser la phase de signal réinjecté)

Autres Paramètres

Filter Place un filtre dans le signal traite
Tape Force le signal direct a être retarde également avec le signal traite
Link/golden ratio Permet de lier les contrôles Rate et Depth, ce qui permet de maintenir le même ratio entre eux
Stereo Ne change pas la phase des sorties, mais règle la phase du LFO entre la droite et la gauche.
Phase Reversed Inverse la phase du canal droit, mais uniquement sur le signal traite. Cette fonction permet d'élargir l'image stéréo
Cross Feedback Règle l'équilibre de la réinjection entre les 2 canaux.
LFO Curve/Waveform Type de courbe de LFO (syn ou Tri), la plus courante étant syn (sinusoïdal)
LFO Phase décale la phase du LFO des canaux gauche et droite

   Le TC Electronic 2290 est un multi-effet qui produit l'un des meilleur Flanger du marches, il est base sur un rapport vitesse/profondeur (Speed/Depth) qui utilise le nombre d'or (golden ratio), ce qui garantit un effet de Flanger harmonieux quel que soit le réglage. Le FireworX (Multi-effet haut de gamme de TC Electronic) a hérite du flanger de la 2290, et peut désactiver le golden ratio afin de créer un flanger plus extrême Le plug Waves MetaFlanger peut être utilise pour produire une grande variété de flanger classiques, des phasers vintage, des chorus et autre.

Le plugin Wave MetaFlanger
^
11 octobre 2011

htmlpdflatexmanmd




Le Noise gate

Le Noise gate

l'effet Noise gate

   Tout signal passant à travers des composants électroniques (préamplis, effects, mixage, etc...) se voit agrémenté d'un bruit de fond généré par ces composants électroniques. Ce bruit de fond devient d'autant plus gênant que le signal subit de nombreux traitements. La compression également permet de réhausser le niveau général du signal et donc d'augmenter le bruit de fond. On utilise donc une 'porte de bruit' (noise gate) qui permet de définir un seuil au dessus duquel la porte est ouverte et laisse passer le signal, et au dessous duquel, la porte se ferme et le signal est stoppé.

   Le principe est très simple, et fonctionne presque comme un compresseur, avec un threshold, une attack, un release. Certain noise gate comme le Waves C1 permettent de conserver un minimum de bruit de fond, qui évite les gros 'vides' et le seuil de la porte peut dans certain cas avoir deux réglages, un seuil pour l'ouverture de la porte, et un pour la fermeture de la porte, ce qui permet de régler le temps d'attack, et une transition moins dure.

   Pour éviter la coupure trop directe du noise gate utilisez un expander de signaux faibles, certain noise gate possède un telle fonction (Waves C1).

Le noise gate ne laisse passer que les signaux forts

^
11 octobre 2011

htmlpdflatexmanmd




Le Normalizer

Le Normalizer

l'effet Normalizer

   Un signal audio possède un volume maximum, défini par les crêtes les plus fortes, et un niveau minimum, généralement le bruit de fond. lors du mastering, le signal audio est optimisé pour obtenir le meilleur 'son' possible en fonction de son support final. Un CD, à une résolution de 16 bits, ce qui est assez grossier, et la pression acoustique maximum n'est que de 96 dB. Ce qui fait qu'un signal destiné à être stocké sur ce support doit subir un voir plusieurs traitements de dynamique avant son impression. Compression, limiter sont souvent nécessaires mais il est également courant de 'normaliser' le signal.

   Le niveau maximal admissible sans saturation, correspond à 0dBFS (Full Scale), c'est à peut près à ce niveau (en tout cas pas au-delà) que doit se trouver le niveau maximum du signal (les crêtes les plus élevées) afin d'obtenir un niveau moyen efficace (RMS) le plus élevé possible. Le nomalizer se base sur les niveaux maximum du signal, et le 'cale' sur 0dBFS afin d'utiliser toute la plage dynamique d'un CD.

   L'optimisation du signal, en mastering, commence généralement par le normalizer qui permet d'avoir le niveau optimal avant d'attaquer un compresseur, limiter, expander...

   Il peut être préférable avant la normalisation de compresser et limiter le signal, même infimement, afin d'éviter que des crêtes trop élevées ne viennent handicaper le niveau moyen du signal, qui serait alors trop bas, juste à cause de quelques crête trop hautes et qui peuvent être diminuées, la plupart du temps, sans que cela soit audible.

   Le normalizer est donc une sinon la derniere étape en mastering et permet d'adapter le niveau moyen du signal au niveau maximum admissible (régler par rapport aux crêtes les plus hautes) sans avoir de saturation.

   Par simple curiosité, essayez le plug-in Waves L1-Ultramaximizer, qui fait bien mieux qu'un normalizer. Bien mieux !

^
11 octobre 2011

htmlpdflatexmanmd




Le Panning

Le Panning

l'effet panning

   Suivant les cas on l'appel AutoPan, Panner, Panning. Pan est le diminutif de panoramique, ce qui veut dire la droite et la gauche de l'espace stéréo. Le panning est donc un effet qui permet de balancer un son alternativement à droite et à gauche. Au sens strict, le panning correspond à un changement inversement proportionnel de niveau sur les canaux gauche et droit. Un LFO (par canal, et synchronises en opposition de phase) connecte a ces niveaux permet de les augmenter ou de les diminuer.

   L'effet est des plus simple, et possède une sortie toujours stéréo évidement, l'entrée pouvant être mono ou stéréo. Cet effet est disponible sur tous les multi-effets, et toutes les marques de pédales d'effet guitare en proposent une. L'effet n'est pas toujours utilise, mais permet de déplacer, même très subtilement, un ou plusieurs sons dans l'image stéréo, donnant du dynamisme et du mouvement dans un mix. Les effets spéciaux sont également possibles. Noter que si vous synchronisez les deux LFO en phase, vous obtenez un Tremolo.

^
11 octobre 2011

htmlpdflatexmanmd




Le Rotary

Le Rotary

l'effet rotary

   Les enceintes à haut-parleurs tournants ont été conçues pour donner un effet majestueux de vibrato/chœur aux orgues électroniques de théâtre et d'église. Le modèle le plus connu est la Leslie modèle 122, qui possède deux haut-parleurs tournant en sens inverse : une trompe aiguë et un haut-parleur basse fréquence à deux vitesses (lente et rapide). Le son créé par le changement de vitesse des éléments en rotation est vraiment magique. L'effet envoûtant et spacieux est difficile a décrire - mais tellement facile à reconnaître.

   Eléments incontournables des organistes, les effets Rotary sont également parfaits pour les rythmiques de guitares ou de piano électrique. Ces effets offrent une solution alternative extrêmement intéressante aux effets de chorus et de tremolo, quelle que soit la source sonore utilisée.

   Malheureusement peut d'effet sont disponible, et inutile de chercher une cabine Leslie, sa rareté est a la hauteur de son prix.

   Lexicon propose sur ses multi-effets (MPX 550) une simulation précise d'une cabine de type Leslie.... L'effet est obtenu par une combinaison synchronisée de la modification de la hauteur du signal, d'un tremolo et d'un effet de panoramique. Comme sur l'enceinte originale, les fréquences graves et aiguës tournent en sens inverse. La vitesse des deux transducteurs est indépendante, et les caractéristiques d'accélération et de ralentissement sont recréées afin de simuler l'inertie des éléments mécaniques originaux.

^
10 octobre 2011

htmlpdflatexmanmd




Le tremolo

Le tremolo

l'effet tremolo

   Le tremolo est une variation rythmique du niveau sonore, utilise communément comme technique d'expression par les chanteurs et les musiciens d'instruments a vent. Le tremolo est également l'un des effets électronique les plus anciens, fréquemment utilise sur les guitares électriques, les pianos électriques et parfois les voix. La différence entre les effets de tremolo réside principalement dans la vitesse et la forme d'onde utilisée pour la modulation du signal. Lorsque l'effet est utilise sur un signal stéréo, la droite et la gauche peuvent être synchronisées pour produire des déplacement impressionnants du signal dans le champ stéréo donnant un effet de panning.

   Au sens strict, le tremolo correspond à un changement de niveau identique sur les canaux gauche et droit. Un LFO (par canal, et synchronises en phase) connecte a ces niveaux permet d'augmenter ou de diminuer les niveaux. Il est conseille d'adapter la vitesse au tempo du morceau car le tremolo est un effet principalement rythmique.

^
11 octobre 2011

htmlpdflatexmanmd




Le Vibrato

Le Vibrato

l'effet vibrato

   L'effet de vibrato permet de moduler la hauteur du signal. Le résultat est similaire à la technique du vibrato des chanteurs, ou encore certains instruments de musique (la barre de vibrato d'une guitare électrique). Contrairement à un effet de chorus aucun signal direct n'est mélange au signal traite module en hauteur. Au sens strict le vibrato est un LFO qui permet de moduler la hauteur du signal.

Réglages

Speed Règle la vitesse du LFO (ou vitesse de modulation, ou encore fréquence), des temps de 10-20 ms sont généralement utilises
Depth Détermine l'Amplitude de l'effet (également nomme profondeur de modulation ou intensité)

Autres contrôles

Phase Reversed Inverse la phase sur le canal droit mais uniquement sur le signal traite. Permet d'élargir l'image stéréo LFO
Curve Type de courbe de LFO. Généralement on trouve TRI, SIN, et Up, mais on peut parfois trouver l'onde Square
LFO Phase Décale la phase des LFO sur les sorties droite et gauche
^
11 octobre 2011

htmlpdflatexmanmd




Le Whammy

Le Whammy

l'effet Whammy

   L'effet Whammy permet de contrôler la hauteur d'une voix supplémentaire, au moyen d'une pédale d'expression MIDI externe

Contrôles

Whammy en %. Détermine l'équilibre entre le son direct et le signal traite. Lorsque vous sélectionnez 100 %, aucun signal direct de la guitare n'est audible ; seul le son désaccorde est audible
Direction Détermine si la pédale d'expression doit réduire ou augmenter la hauteur du signal lorsqu'elle est actionnée
Range Détermine la plage sur laquelle le bloc Whammy peut désaccorder le signal (1-Oct/2-Oct)
^
30 janvier 2015

htmlpdflatexmanmd




libvirt-pools

libvirt-pools

Définitions des pools de stockage

‹pool type="iscsi"› type peut être dir, fs, netfs, disk, iscsi, scsi, mpath, rbd, sheepdog, gluster, zfs ou logical.

        ‹name›myname‹/name fournis un nom pour le pool, qui doit être unique à l'hôte.
        ‹uuid› 3e3fce45-4f53-4fa7-bb32-11f34168b82b ‹/uuid› Fournis un identifiant pour le pool, qui doit être globalement unique.
        ‹allocation› 10000000 ‹/allocation› Fournis l'allocation du stockage total pour le pool, en octets. N'est pas applicable en créant un pool.
        ‹capacity› 50000000 ‹/capacity› Fournis la capacité de stockage totale pour le pool, en octets. N'est pas applicable en créant un pool.
        ‹available› 40000000 ‹/available› Fournis l'espace disponible pour allouer de nouveaux volumes, en octets. N'est pas applicable en créant un pool.
        ‹source› Utilisé pour décrire la source du pool de stockage

                ‹device path="demo-target"/› fournis la sources des pools stockés par des périphériques physiques ( fs, logical, disk, iscsi, zfs). Peut être répété plusieurs fois en fonction du pilote de backend. Contient un seul attribut path qui est le chemin vers le nœud du périphérique block.
                ‹dir path="/my/path"/› Fournis la source pour les pools de type dir.
                ‹adapter type='scsi_host' name='scsi_host1'/› Fournis la source pour les pools de type scsi:

                        name Nom de l'adapter scsi
                        type Spécifie le type d'adapter ( scsi_host ou fc_host ). Si omit et que name est spécifié, scsi_host est utilisé.
                        wwnn
                        wwpn World Wide Node Name et World Wide Port Name sont utilisé par l'adapter fs_host pour identifier de manière unique le périphérique.
                        parent Utilisé avec le type fc_host pour spécifier le périphérique scsi_host parent.
                        managed Attribut optionnel pour instruire le backend scsi de gérer la destruction du vHBA quand le pool est détruit. (yes ou no)
                        ‹parentaddr› Utilisé par le type scsi_host au lieu de l'attribut name pour identifier de manière unique l'hôte scsi:

                                unique_id Nécessite que parentaddr soit utilisé pour déterminer les adapters scsi_host pour l'adresse PCI fournis.
                                ‹address› Adresse PCI pour le périphérique scsi_host à utiliser:

                                        domain Entier 2 octets héxa
                                        bus valeur entre 0 et 0xff
                                        slot valeur entre 0x0 et 0x1f
                                        function Valeur entre 0 et 7.

                        ‹/parentaddr›

                ‹/adapter›
                ‹host› Fournis la source pour les pools stockés sur les stockages distant (netfs, iscsi, rbd, sheepdog, gluster). Utilisé en combinaison avec un élément directory ou device. Contient un attribut name qui est le nom d'hôte ou l'adresse IP du serveur port pour un numéro de port spécifique.
                ‹auth› Si présent, fournis les accréditifs nécessaires pour accéder à la source.

                        type doit être "chap" pour iscsi ou "ceph" pour rbd.
                        username spécifie le nom d'utilisateur pour l'authentification
                        ‹secret› l'attribut type est mandatoire et attache un objet secret qui maintient les accréditifs, uuid contient l'uuid de l'objet secret et usage match la clé spécifiée dans l'objet secret.

                name Spécifie la source pour les pools nommés (logical, rbd, sheepdog, gluster).
                format Fournis des informations sur le format du pool (pour les pools fs, netfs, disk, logical). Contient un simple attribut type dont la valeur est spécifique au backend). Utilisé pour indiquer le type de système de fichier, de réseau, le type de table de partition, ou le type de meta-donnée LVM.
                vendor Fournis des informations sur le vendeur du périphérique de stockage. Contient un attribut name dont la valeur est spécifique au backend.
                product Fournis un nom de produit pour le périphérique de stockage. Contient un attribut name dont la valeur est spécifique au backend.
                ‹target› Utilisé pour décrire le mappage du pool de stockage ans le système de fichier hôte. Il peut contenir 5 éléments:

                        path Fournis l'emplacement auquel le pool sera mappé dans l'espace de nom du système de fichier local.
                        ‹permissions› Actuellement utile uniquement pour les pools dir et fs-based, qui sont mappés comme répertoire dans le système de fichier local. Il fournis des informations sur les permissions à utiliser pour le répertoire final quand le pool est construit.

                                ‹owner› 107 ‹/owner› Spécifie le propriétaire du répertoire final
                                ‹group› 107 ‹/group› Spécifie le groupe propriétaire du répertoire final
                                ‹mode› 0744 ‹/mode› Spécifie les permissions à définir sur le répertoire final
                                ‹label› virt_image_t ‹/label› Contient le label MAC pour selinux.

                        ‹/permission›
                        ‹timestamps› Actuellement utile uniquement pour les pools dir et fs-based, qui sont mappés comme répertoire dans le système de fichier local.

                                ‹atime› 1341933637.273190990 ‹/atime› Date de dernier accès
                                ‹mtime› 1341930622.047245868 ‹/mtime› Date de dernière modification
                                ‹ctime› 1341930622.047245868 ‹/ctime› Date de création

                        ‹/timestamps›
                        ‹encryption type='...'› Spécifie comment le volume est chiffré

                ‹/target›

        ‹/source›

‹/pool›

^
24 janvier 2015

htmlpdflatexmanmd




libvirt.conf

libvirt.conf

Fichier de configuration pour libvirt, permet de définir des alias pour les URI fréquemments utilisées.

Options

uri_aliases = [] Définis les alias, chaque ligne entre les crochets est sous la forme ‹alias›=‹URI›.
uri_default Spécifie l'URI utilisée par défaut

Exemples d'alias

hail=qemu+ssh://root@hail.cloud.example.com/system",
sleet=qemu+ssh://root@sleet.cloud.example.com/system",

format d'URI

Le format d'une URI est:
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]

Transports

name Nom passé à la fonction virConnectOpen. (ex: name=qemu:///system)
command Commande externe (ex: command=/opt/openssh/bin/ssh)
socket Chemin vers un socket unix (ex: socket=/opt/libvirt/run/libvirt/libvirt-sock)
netcat Nom d'une commande netcat, par défaut nc (ex: netcat=/opt/netcat/bin/nc)
keyfile fichier contenant une clé privée à utiliser pour l'authentification (ex: keyfile=/root/.ssh/example_key)
no_verify Désactive la vérification des clé pour SSH et TLS (ex: no_verify=1)
no_tty Empêche ssh de demander un mot de passe s'il ne peut pas se connecter automatiquement. (ex: no_tty=1)
pkipath Chemin vers les certificats X.509 pour le client. (ex: pkipath=/tmp/pki/client)
known_hosts Pour libssh2. Chemin vers un fichier known_hosts pour vérifier la clé de l'hôte.(ex: known_hosts=/root/.ssh/known_hosts)
sshauth pour libssh2. liste de méthodes d'authentification à utiliser. (ex: sshauth=agent,privkey,keyboard-interactive)
^
24 janvier 2015

htmlpdflatexmanmd




libvirtd

libvirtd

Service de gestion libvirt

Description

   libvirtd est le composant serveur du système de gestion de virtualisation libvirt. Ce sevice fonctionne sur les serveur hôte et effectuent des tâche de gestion pour les invités virtualisés. Les librairies client libvirt et utilitaires se connectent à ce service pour fournir des tâches ou collecter des informations sur la configuration et les ressources du système hôte et des invités.

  libvirtd relis sa configuration quand il reçoit un SIGHUP.

OPTIONS

-d, --daemon Lance en tâche de fond
-f, --config FILE Utilise le fichier de configuration spécifié
-l, --listen Écoute sur TCP/IP au lieu d'un socket unix
-p, --pid-file FILE Utilise ce nom pour le fichier PID
-t, --timeout secondes Quitte après le temps spécifié passé sans connexion client.
-v, --verbose mode verbeux

Fichiers

SYSCONFDIR/libvirtd.conf Fichier de configuration de libvirtd
LOCALSTATEDIR/run/libvirt/libvirt-sock
LOCALSTATEDIR/run/libvirt/libvirt-sock-ro Sockets utilisé par libvirtd
SYSCONFDIR/pki/CA/cacert.pem certificat d'autorité
SYSCONFDIR/pki/libvirt/servercert.pem Certificat du serveur
SYSCONFDIR/pki/libvirt/private/serverkey.pem Clé privée du serveur
LOCALSTATEDIR/run/libvirtd.pid Fichier PID

Fichiers en non-root

$XDG_CONFIG_HOME/libvirtd.conf Fichier de configuration de libvirtd
$XDG_RUNTIME_DIR/libvirt/libvirt-sock Socket utilisé par libvirtd
$HOME/.pki/libvirt/cacert.pem certificat d'autorité
$HOME/.pki/libvirt/servercert.pem Certificat du serveur
$HOME/.pki/libvirt/private/serverkey.pem Clé privée du serveur
$XDG_RUNTIME_DIR/libvirt/libvirtd.pid Fichier PID
^
24 janvier 2015

htmlpdflatexmanmd




libvirtd.conf

libvirtd.conf

Fichier de configuration pour libvirtd

Options

listen_tls à 0, écoute les connexions non chiffrées, à 1, écoute les connexions chiffrées
tls_port Port d'écoute pour les connexions tcp sécurisés.
tcp_port Port d'écoute pour les connexions tcp non-sécurisés.
listen_addr Adresse d'écoute pour les connexions tcp
mdns_adv à 1, active l'avertissement mDNS des services client.
mdns_name par défaut "Virtualization Host HOSTNAME",où HOSTNAME est substitué par le nom court de la machine.
unix_sock_group Groupe propriétaire du socket
unix_sock_ro_perms Permissions du socket RO unix, utilisé pour la supervision des VM
unix_sock_rw_perms Permissions du socket RW unix, utilisé pour la gestion complète des VM.
unix_sock_dir Répertoire où créer/trouver le socket.
auth_unix_ro Définis le schéma d'authentification pour les socket RO unix (none,sasl,polkit)
auth_unix_rw Définis le schéma d'authentification pour les socket RW unix (none,sasl,polkit)
auth_tcp Définis le schéma d'authentification pour les sockets TCP (none,sasl,polkit)
auth_tls Définis le schéma d'authentification pour les sockets TCP sécurisés (none,sasl,polkit)
access_drivers = [ "nop" | "polkit" ] Par défaut un utilisateur authentifié est autorisé à accéder a toutes les API. Les pilotes d'accès peuvent y placer des restrictions. Par défaut, le driver 'nop' est activé, signifiant qu'aucun contrôle d'accès n'est fait une fois le client authentifié. Sinon, 'polkit' peut être utilisé
key_file Clé privée du service
cert_file Chemin des fichiers de certificat du serveur
ca_file Certificat de CA à utiliser
crl_file CRL à utiliser
tls_no_sanity_certificate À 1, désactive la vérification de son certificat
tls_no_verify_certificate À 1, désactive la vérification des certificats client
tls_allowed_dn_list = ["DN1", "DN2"] Une liste blanche de DN X.509. Si c'est une liste vide, personne ne peut se connecter.
sasl_allowed_username_list = ["joe@EXAMPLE.COM", "fred@EXAMPLE.COM" ] Une liste blance de noms d'utilisateurs sasl autorisé. Si c'est une liste vide, personne ne peut se connecter.
max_clients = 5000 Nombre de clients simultané autorisés
max_queued_clients = 1000 Longueur de la file d'attente de connexion autorisés
max_anonymous_clients = 20 Longueur de la file d'attente de clients accéptés mais pas encore authentifiés
min_workers = 5 Limite minimum de clients prévu, au dessus de cette limite, d'autre threads sont crées.
max_workers = 20 Limite maximum. Généralement max_workers == max_clients
prio_workers Nombre de clients prioritaires. Si tous les clients du pool de workers sont bloqués, certains appel marqués en haute priorité peuvent être exécutés dans ce pool.
max_requests = 20 Limite totale d'appels RPC concurrents. Devrait être au moins aussi grand que max_workers. Au delà de cette limite, les requêtes RPC seront lues en mémoire et mises en file d'attente. Cela impact l'utilisation de la mémoire, chaque requête nécessitant 256Ko de mémoire.
max_client_requests = 5 Limite de requête concurrentes par client. Pour éviter qu'un client monopolise le serveur, devrait être une petite fraction de max_requests.
log_level = 3 Niveau de logs ( 4 errors, 3 warnings, 2 information, 1 debug )
log_filters="3:remote 4:event" Filtre le logs. Permet de sélectionner différent niveaux de log pour une catégorie de logs donné. Plusieurs filtres peuvent être définis dans un simple @filters Le format est:

        x:name
        x:+name où name est une chaîne qui est matchée avec un nom de fichier source (ex: "remote", "qemu", ou "util/json") "+" indique à libvirt de logger les stack trace pour chaque message, et x est le niveau minimum où les messages matchant sont loggés:

                1: DEBUG
                2: INFO
                3: WARNING
                4: ERROR

log_outputs="3:syslog:libvirtd" Une sortie est un emplacement où sauver les informations de log. plusieurs sorties peuvent être définis. Le format est:

        x:stderr Erreur standard
        x:syslog:name Uitilise syslog
        x:file:file_path Sort dans un fichier
        x:journald Utilise journald
        x est le niveau minimum, agissant comme filtre:

                1:DEBUG
                2:INFO
                3:WARNING
                4:ERROR

audit_level = 2 Pernet d'altérer le sous-système d'audit:

        0 Désactive l'audit
        1 Active l'audit, seulement si permis par l'hôte
        2 Active l'audit, et qui si désactivé par l'hôte

audit_logging = 1 À 1, les messages d'audit seront envoyés via l'infrastructure de logging libvirt. Défaut: 0
host_uuid = "00000000-0000-0000-0000-000000000000" Fournis l'UUID de l'hôte ici dans le cas ou la commande 'dmidecode -s system-uuid' ne fournis pas d'uuid valide.
keepalive_interval = 5 Permet à libvirtd de détecter les connexions client cassé ou morts. Un keepalive est envoyé à un client après cet interval (en seconde) d'inactivité pour vérifier s'il répond.
keepalive_count = 5 Nombre maximum de message keepalive sans réponses à envoyer avant de fermer automatiquement la connexion.
keepalive_required = 1 À 1, libvirtd refuse de parler aux clients qui ne supportent pas le protocole keepalive. Défaut: 0.
^
02 juillet 2010

htmlpdflatexmanmd




link

link

Créer un lien dur, interface minimaliste à la fonction système link

   link FILENAME LINKNAME

  FILENAME doit être un fichier existant, et LINKNAME doit spécifier une entrée inexistante dans un répertoire existant. Cette commande agit comme ln --directory --no-target-directory FILENAME LINKNAME

^
17 mars 2010

htmlpdflatexmanmd




Linux Bridge

Linux Bridge

Permet de transformer une machine Linux en commutateur

   Sl est très versatile et très performant. Il est notamment utilisé sur certaines box (livebox, etc...). Il est ainsi possible de créer plusieurs commutateurs virtuels, d’appliquer des règles de filtrage avec Iptables, ou plus adapté, Ebtables. Linux bridge gère le STP et les trames taguées. Il est nécessaire que le noyau linux soit compilé avec l’option "networking -› 802.1d Ethernet Bridging" . Sous Debian, les noyaux sont compilés avec cette option par défaut. Il suffit donc d’installer le paquet bridge-utils

Configuration

   Linux bridge est très simple à configurer, il suffit de créer un commutateur, lui inclure les interfaces que l’on désire, et si nécessaire de paramétrer le STP.

brctl addbr ajouter un commutateur
brctl delbr supprimer un commutateur
brctl addif ajouter une interface a un commutateur
brctl delif supprimer une interface d’un commutateur
brctl show affiche la liste des commutateurs
brctl showmacs affiche la liste des addresses MAC
brctl stp active/désactive le stp
brctl showstp affiche les info stp
brctl setageing ajuste ageing time
brctl setbridgeprio ajuste bridge priority
brctl setfd ajuste le bridge forward delay
brctl sethello ajuste le hello time
brctl setmaxage ajuste le max message age
brctl setpathcost ajuste le path cost
brctl setportprio ajuste le port priority

Exemples

pour créer un commutateur avec 2 interfaces:
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr mybridge
brctl addif mybridge eth0
brctl addif mybridge eth1
ifconfig mybridge up
Il est nécessaire que les interfaces n’aient pas d’adresses IP. Ici, la machine ne possède aucune adresse IP, elle n’est donc pas manageable à distance. Pour lui donner une adresse, remplacer la dernière ligne par:
ifconfig mybridge 192.168.100.5 netmask 255.255.255.0
ou si on préfère une attribution par dhcp:
dhclient mybridge
À noter qu’il est possible de créer un commutateur avec une seule interface, il est donc possible sur un poste client de créer un commutateur sur l’interface réseau, et ainsi de pouvoir profiter des possibilités d’Ebtables pour le filtrage.
^
02 juillet 2010

htmlpdflatexmanmd




ln

ln

Créer des liens entre les fichiers

   ln crée des liens entre les fichiers. Par défaut il crée des liens dur, -s permet de créer des liens symbolique.

  - si 2 fichiers sont donnés, ln crée un lien du premier fichier dans le second.

  - si une cible est donnée, ln crée un lien de ce fichier dans le répertoire courant

  - si -t est donné ou si le dernier fichier est un répertoire et que -T n'est pas donné, ln crée un lien de chaque cible dans le répertoire spécifié, en utilisant le nom des cibles.

  Normalement ln ne supprime pas de fichiers existant, utiliser -f pour supprimer automatiquement, -i pour demander avant de supprimer, ou -b pour les renommer.

   Un lien dur est un autre nom pour un fichier existant ; le lien et l'original ne sont pas distinct. ils partagent le même inode. Vous ne pouvez pas créer un lien dur sur un répertoire, et les liens dur ne peuvent pas être sur un autre système de fichier que l'original.

  Les lien symboliques, sont un type de fichier spécial dans lequel le lien réfère à un fichier différent. Les liens symboliques peuvent contenir des chaînes arbitraires; un "dangling symlink" se produit quand la chaîne ne résout pas un fichier. Un lien symbolique absolue pointe toujours sur le même fichier, même si le dossier contenant le lien est déplacé, à l'exception des liens visible depuis une autre machine. Un lien symbolique relatif est toujours résolu en relation avec le répertoire qui contient le lien, et est souvent utile pour référer aux fichiers sur le même périphérique sans regarder le nom sous lequel le périphérique est monté.

OPTIONS

-b, --backup[=METHOD] Crée un backup de chaque fichier qui serait supprimé ou écrasé.
-d, -F, --directory Tente de créer un lien dur sur les répertoire, mais va probablement échouer à cause des restrictions systèmes.
-f, --force Supprime les fichiers de destination existant.
-i, --interactive Demande avant de supprimer les fichiers de destination
-n, --no-dereference Ne traite pas la dernière opérande spécialement quand c'est un répertoire ou un lien symbolique.
-s, --symbolic Créer des liens symboliques.
-S SUFFIX, --suffix=SUFFIX ajoute un suffixe au backup crées avec -b
-t DIRECTORY, --target-directory=DIRECTORY Spécifie le répertoire de destination
-T, --no-target-directory Ne traite pas spécialement la dernière opérande quand c'est un lien symbolique ou un répertoire.
-v, --verbose affiche le nom de chaque fichier après l'avoir lié avec succès.
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/users/local.users

/etc/selinux/‹SELINUXTYPE›/contexts/users/local.users

Fichier de configuration des utilisateurs locaux SELinux

   Ce fichier contient les définitions des utilisateurs locaux sous la forme de déclaration d'utilisateur en langage de stratégie et est déprécié et remplacé par les services semanage. Ce fichier consiste d'une ou plusieurs entrées terminée pas ';', au format: user seuser_id roles role_id [[level level] [range range]];

user seuser_id l'identifiant de l'utilisateur SELinux
roles role_id Un ou plusieurs identifiants de rôle
level level Le niveau MLS/MCS
range range La plage que l'utilisateur peut utiliser.


user test_u roles staff_r level s0 range s0 - s15:c0.c1023;

^
06 mai 2017

htmlpdflatexmanmd




locale

locale

Description du support multilangue

   Une locale est un jeu de langue et de règles culturelle. Celà couvre les aspects tels que la langue pour les messages, les jeux de caractères, conventions lexicographiques, ett. Un programme doit être capable de déterminer sa locale et agir en accord pour être portable à différentes cultures.

   Il y a différentes catégories pour les informations de locale qu'un programme peut avoir besoin:

LC_ADDRESS Change les paramètres qui décrivent les formats (ex: adresse postale) utilisée pour décrire les emplacements et éléments lié à la géographie.
LC_COLLATE Cette catégorie gouverne les règles de collation utilisées pour les expressions régulières et le trie, incluant les classes d'équivalences de caratère et les éléments de collation multicaractère. Cette catégorie de locale change le comportement des fonctions strcoll(3) et strxfrm(3), qui sont utilisé pour comparer les chaînes dans l'alphabet local.
LC_CTYPE Cette catégorie détermine l'interprétation des séquences d'octet comme caractère, les classifications de caractère, et le comportement des classes de caractère. Cette catégorie détermine également les règles de translitération de caractère pour iconv(1), et iconv(3). Il change le comportement des fonctions de manipulation de caractère et de classification, comme isupper(3) et toupper(3), et les fonctions de caractère multi-octet comme mblen(3) ou wctomb(3)
LC_IDENTIFICATION Change les paramètres liées aux métadonées pour la locale. Les applications qui ont besoin de cette information peut utiliser nl_langinfo(3) pour récupérer des éléments non standard, tel que _NL_IDENTIFICATION_TITLE (titre de ce document locale) et _NL_IDENTIFICATION_TERRITORY (territoire géographique auquel ce document s'applique), qui peut retourner des chaînes comme "English locale for the USE" et "USA".
LC_MONETARY Détermine le formattage utilisé pour les valeurs numériques monétaires. Celà change les informations retournées par localeconv(3)
LC_MESSAGES Cette catégorie affecte la langue dans laquelle les messages sont affichés. gettext(3), ngettext(3) et rpmatch(3) utilisent cette information.
LC_MEASUREMENT Paramètres liés au système de mesure dans la locale. nl_langinfo(3) permet de récupérer l'élément _NL_MEASUREMENT_MEASUREMENT, qui retourne un pointeur vers un caractère qiu a la valeur 1 (metric) ou 2 (US customary units)
LC_NAME Décrit les formats utilisé pour les personnes. nl_langinfo(3) retourne cette information.
LC_NUMERIC Détermine les règles de formattage utilisées pour les valeurs numériques non-monétaires
LC_PAPER Paramètres liés aux dimensions de taille de papier standard
LC_TELEPHONE Décrit le format utilisé pour les numéros de téléphone
LC_TIME Format utilisé pour les dates et valeurs de temps
LC_ALL Toutes les catégories

   La variable d'environnement suivante est utilisée par newlocale(3) et setlocale(3), et donc affecte tous les programmes nom localisés:

LOCPATH Liste de chemins, séparés par un ':', qui devraientt être utilisé pour trouver les données de locale. Si définis, seul les fichiers provenant de ces chemins et le chemin par défaut du système sont utilisés.

Fichiers

/usr/lib/locale/locale-archive Emplacement d'archive de locale par défaut
/usr/lib/locale Emplacement par défaut pour les fichiers de locale
^
06 mai 2017

htmlpdflatexmanmd




/etc/locale.conf

/etc/locale.conf

Fichier de configuration pour les paramètres de locales

   Ce fichier configure les paramètres de locales système. Il est lu par systemd. Le format consiste d'une liste séparée par une nouvelle ligne d'assignement de variables compatible avec le shell.

   Les options de ligne de commande kernel locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION= peuvent être utilisées au boot pour définir les locales. les paramètres suivants peuvent être définis:

LANG=
LANGUAGE=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATION=

   Note: LC_ALL ne peut pas être configuré dans ce fichier.

^
06 mai 2017

htmlpdflatexmanmd




localectl

localectl

Contrôle la locale système et les paramètres clavier

   localectl peut être utilisé pour afficher ou changer la locale sysème et les paramètres de couche clavier. Il communique avec systemd-localed pour modifier les fichiers tels que /etc/locale.conf et /etc/vconsole.conf Noter que les changements effectués avec cet utilitaire peut nécessiter de reconstruire initramfs. Noter que systemd-firstboot(1) peut être utilisé pour initialiser la locale système pour les images système montés (mais non chargés)

OPTIONS

--no-ask-password Ne demande pas l'authentification utilisateur pour les opérations privilégiées
--no-convert si set-keymap ou set-x11-keymap est invoqué avec cette option, le keymap ne sera pas convertis de la console vers X11, ou X11 vers la console, respectivement
-H, --host= Exécute l'opération à distance
--no-pager Ne pipe pas dans un pager

Commandes

status Affiche le status courant
set-locale LOCALE... Définis la local système. Prend un ou plusieurs assignement tel que "LANG=deDE.utf8", etc.
list-locales Liste les locales disponibles
set-keymap MAP [TOGGLEMAP] Définis le mappage clavier pour la console et X11.
list-keymaps Liste les mappages clavier disponibles pour la console
set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]] Définis le mappage clavier pour X11 et les claviers virtuels. voir kbd(4)
list-x11-keymaps
list-x11-keymap-layouts
list-x11-keymap-variants [LAYOUT]
list-x11-keymap-options Liste les modèles, couche, variantes et options de clavier X11.

Variables d'environnement

SYSTEMD_PAGER Pager à utiliser. Vide, ou 'cat' est équivalent à --no-pager
SYSTEMD_LESS Remplace les options par défaut de less ('FRSXMK')
^
30 janvier 2014

htmlpdflatexmanmd




logger

logger

Interface en ligne de commande pour syslog

OPTIONS

-d, --udp Utilise UDP
-i, --id Log le process ID du processus logger avec chaque ligne
-f, --file Log le contenu du fichier spécifié.
-n, --server Écrit au serveur syslog spécifié en UDP au lieu d'utiliser les routines syslog
-P, --port Port UDP à utiliser (défaut: 514)
-p, --priority Spécifie la priorité sous forme numérique ou paire facility.level (ex: local3.info)
-s, --stderr Affiche également le message sur l'erreur standard
-t, --tag Marque chaque ligne avec le tag spécifié
-u, --socket Écrit dans le socket spécifié au lieu des routines syslog
-- Fin de la liste d'arguments

Les facility sont: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0 à local7.
Les noms de niveau valides sont: alert, crit, debug, emerg, err, info, notice, warning.

Exemples

logger System rebooted
logger -p local0.notice -t HOSTIDM -f /dev/idmc
logger -n loghost.example.com System rebooted
^
31 mai 2010

htmlpdflatexmanmd




login

login

Utilisé pour établir une nouvelle session avec le système

   login en peut pas être invoqué comme sous-processus. Typiquement, login est traité par le shell comme exec login qui force l'utilisateur à quitter le shell courant. Après une connexion réussie, vous serez informé des messages du système (/etc/motd). On peut les désactiver en créant un fichier vide .hushlogin dans le répertoire utilisateur. Le message concernant les mails sera "you have new mail", "you have mail" ou "no mail".

   le nom d'utilisateur et de groupe sont définis dans /etc/passwd. Les variables $HOME, $SHELL, $PATH, $LOGNAME et $MAIL sont définies en fonction des champs appropriés. Les valeurs de ulimit, umask et de nice peuvent également être affectés en fonction des entrées du champ GECOS.

OPTIONS

-f Ne pas réaliser d´authentification. L´utilisateur est pré-authentifié.
-h Nom de l´hôte distant pour cette connexion.
-p Préserver l´environnement.
-r Exécuter le protocole de connexion automatique (autologin) pour rlogin.

   Les options -r, -h et -f ne peuvent être utilisées que par root.

Configuration

   ces variables de /etc/login.defs modifient le comportement de login

CONSOLE_GROUPS Liste des groupes supplémentaire à ajouter à l'utilisateur quand il se logge sur la console ( comme déterminé par le paramèter CONSOLE ) Défaut: none
DEFAULT_HOME Indique si la connexion est permise si on ne peut pas accéder au répertoire personnel. Défaut: no
ENV_PATH Si défini, il sera utilisé pour définir PATH quand un utilisateur ordinaire se connecte. La valeur peut être précédée par PATH=, ou une liste de chemins séparés par des deux points (ex /bin:/usr/bin). Défaut: PATH=/bin:/usr/bin
ENV_SUPATH Si défini, sera utilisé pour définir PATH quand le super-utilisateur se connecte. La valeur peut être précédée par PATH= ou une liste de chemins séparés par deux points (ex /sbin:/bin:/usr/sbin:/usr/bin). Défaut: PATH=/bin:/usr/bin.
ERASECHAR Le caractère ERASE du terminal (010 = backspace, 0177 = DEL).
FAIL_DELAY délai en secondes avant qu´un nouvel essai soit permit après un échec de connexion.
FAKE_SHELL Si défini, login exécutera cet interpréteur de commandes au lieu de l´interpréteur de l´utilisateur spécifié dans /etc/passwd.
HUSHLOGIN_FILE Si défini, ce fichier peut désactiver tous les affichages habituels durant la séquence de connexion. Si un nom de chemin complet est spécifié, alors le mode silencieux sera activé si le nom ou l´interpréteur de commandes de l´utilisateur sont trouvés dans le fichier. Si ce n´est pas un nom de chemin complet, alors le mode silencieux sera activé si le fichier existe dans le répertoire personnel de l´utilisateur.
KILLCHAR Le caractère KILL du terminal (025 = CTRL/U).
LOGIN_RETRIES Le nombre maximum de tentatives de connexion en cas de mauvais mot de passe. sera probablement écrasé par PAM, puisque le module pam_unix est réglé en dur pour n´effectuer que 3 tentatives.
LOGIN_TIMEOUT Le temps maximum en secondes pour la connexion.
LOG_OK_LOGINS Activer la journalisation des connexions réussies.
LOG_UNKFAIL_ENAB Activer l´affichage des noms d´utilisateurs inconnus quand les échecs de connexions sont enregistrés. peut être un problème de sécurité si un utilisateur entre son mot de passe au lieu de son nom d´utilisateur.
TTYGROUP, TTYPERM Les permissions du terminal: le login tty sera possédé par le group TTYGROUP, et les permission seront mis à TTYPERM. Défaut: le groupe primaire de l'utilisateur et les droit 0600.
TTYTYPE_FILE Si définis, le fichier qui mappe la ligne tty au paramètre d'environnement TERM. Chaque ligne de ce fichier en dans un format comme "vt100 tty01"
USERGROUPS_ENAB À yes, userdel supprime le groupe de l'utilisateur s'il ne contient plus de membres, et useradd crée par défaut un group de même nom que l'utilisateur

Fichiers

/var/run/utmp Liste des sessions de connexion en cours.
/var/log/wtmp Liste des sessions de connexion précédentes.
/etc/passwd Informations sur les comptes des utilisateurs.
/etc/shadow Informations sécurisées sur les comptes utilisateurs.
/etc/motd Fichier contenant le message du système.
/etc/nologin Empêcher les utilisateurs non-root de se connecter.
/etc/ttytype Liste des types de terminaux.
$HOME/.hushlogin Supprimer l´affichage des messages du système.
^
13 juillet 2010

htmlpdflatexmanmd




logname

logname

Affiche le nom d'utilisateur appelant

   logname affiche le nom d'utilisateur appelant, comme trouvé dans /var/run/utmp ou /etc/utmp.

^
03 mars 2019

htmlpdflatexmanmd




logrotate

logrotate

Tourne, compresse et envoie les logs par mail

   logrotate est conçus pour simplifier l'administration des systèmes qui génèrent un grand nombre de fichiers de log. Il permet de faire des rotations, de les compresser, les supprimer et les envoyer par mail automatiquement. Chaque fichier de log peut être géré quotidiennement, hebdomadairement ou mensuellement, ou quand il est trop volumineux

   Normalement, logrotate est lancé en job quotidien (cron). Il ne modifie pas un log plus d'une fois par jour sauf si le critère pour ce log est basé sur sa taille et que logrotate est lancé plus d'une fois par jour, ou -f ou --force est utilisé

   Plusieurs fichiers de configuration peuvent être passés sur la ligne de commande. Les derniers fichiers de configuration peuvent écraser les options des premiers, donc l'ordre des fichiers de configuration est important. Normalement, un seul fichier de configuration qui inclus d'autres fichiers de configuration devrait être utilisé.

   Sans arguments, logrotate affiche sa version et quitte

OPTIONS

-d, --debug Mode debug
-f, --force Force la rotation, même s'il pense que ce n'est pas nécessaire
-l, --log file log sa sortie dans le fichier spécifié
-m, --mail command commande à utiliser pour envoyer les logs par mail. Accèpte 2 arguments, le sujet et le destinataire
-s, --state statefile utilise le fichier d'état spécifié. Défaut: /var/lub/logrotate/logrotate.status
-v, --verbose mode verbeux
^
03 mars 2019

htmlpdflatexmanmd




logrotate.conf

logrotate.conf

Configuration pour logrotate

OPTIONS

compress compresse les logs lors de la rotation
compresscmd Commande à utiliser pour compresser les fichiers. Défaut: gzip
uncompresscmd Commande à utiliser pour décompresser les fichiers. Défaut: gunzip
compressext Extension à utiliser pour les logs compressés. Défaut: dépend de la commande de compression
compressoptions Options passée au programme de compression. Défaut: -6
copy Créé une copie du fichier de log, mais ne change pas l'original
copytruncate tronque le fichier de log original à une taille vide après avoir créé au lieu de déplacer l'ancien fichier de log et d'en recréer un nouveau.
create mode owner group, create owner group Spécifie les permissions et propriétaires du fichier créé
createolddir mode owner group Si le répertoire olddir n'existe pas, le créé
daily Effectue une rotation quotidiennement
dateext Ajoute une extension de type YYYYMMDD pour les logs
dateformat Spécifie le format de date à utiliser. Seuls %Y %m %d %H %M %S %V %s sont permis.
dateyesterday Utilise la date d'hier au lieu d'aujourd'hui pour l'ajout de la date
datehourago Utilise les heures passée au lieu de la date courante
delaycompress Compression différée à la prochaine rotation
extension ext les fichiers de logs avec l'extension spécifié peuvent rester après la rotation.
hourly les fichiers de logs sont tourné chaque heure
ifempty Toure le fichier de log même s'il est vide. Remplace notifempty
include file_or_dir Permet d'inclure d'autre directives dans d'autres fichiers
mail address quand un log doit être supprimé, il est envoyé par mail à l'adresse spécifiée
mailfirst envoie le fichier de log qui vient d'être tourné
maillast envoie le fichier de log qui doit être supprimé
maxage count supprime les logs tournés plus anciens que le nombre de jours spécifié. l'âge est vérifié seulement si le fichier doit être tourné.
maxsize size Tourne le log s'il est supérieur à la taille spécifiée en octets même avant l'interval de temps spécifié
minsize Tourne le log s'il est supérieur à la taille spécifiée en octets mais pas avant l'interval de temps spécifié
missingok Si le fichier de log est manquant, n'emet pas d'erreur
monthly tourne les logs mensuellement
nocompress ne compresse pas les logs tournés
nocopy Ne copie pas le log original et le laisse en place
nocopytruncate ne tronque pas le log original aprè l'avoir copié
nocreate les nouveaux fichiers de log ne sont pas créés
nocreateolddir ne créé par le répertoire olddir s'il n'existe pas
nodelaycompress pas de compression différée
nodateext n'ajoute pas l'extension de date
nomail Pas d'envoie par mail
nomissingok Si un fichier de log n'existe pas, génère une erreur
noolddir Les logs sont tournés dans le répertoire où ils résident
nosharedscripts Lance les scripts prerotate et postrotate pour tous les fichiers de log.
noshred n'utilise pas shred pour supprimer les anciens fichiers de log
notifempty Ne pas tourner le log s'il est vide
olddir directory Place les logs dans le répertoire spécifié. Ce répertoire doit être dans le même périphérique physique, sauf si copy, copytruncate ou renamecopy est utilisé
postrotate/endscript Commandes exécutées par /bin/sh une fois le log tourné. Le premier argument est le fichier de log. Avec sharedscripts, le pattern est passé
prerotate/endscript Commandes exécutées par /bin/sh avant de tourner le log
firstaction/endscript Commandes exécutées par /bin/sh une fois avant que tous les logs matchant le pattern soient tournés, avant prerotate et lancé seulement si au moin un log est tourné
lastaction/endscript Commandes exécutées par /bin/sh une fois tous les fichiers de log tourné, après postrotate et seulement si au moins un log a été tourné
preremove/endscript Commandes exécutées par /bin/sh une fois juste avant de supprimer un fichier de log
rotate count Les fichiers de log sont tourné le nombre de fois spécifié. à 0, les anciens logs sont supprimés au lieu d'être tournés
size size Taille au delà duquel le log est tourné. Ne fonctionne pas avec les intervals, voir maxsize et minsize.
sharedscripts les scripts prerotate et postrotate sont lancés une fois pour tous les logs
shred Utilise shred pour supprimer les fichier
shredcycles count nombre de cycle shred
start count Nombre de base pour la rotation
su user group La rotation des logs sont effectués sous cet utilisateur
tabooext [+] list Liste d'extensions taboo. si un '+' précède la liste, la liste est augmentée. défaut: .rpmsave, .rpmorig, ~, .disabled, .dpkg-old, .dpkg-dist, .dpkg-new, .cfsaved, .ucf-old, .ucf-dist, .ucf-new, .rpmnew, .swp, .cfsaved, .rhn-cfg-tmp-*
weekly [weekday] Tourne les logs hebdomadairement
yearly Tourne les logs annuellement
^
02 novembre 2016

htmlpdflatexmanmd




logsave

logsave

Sauver la sortie d'une commande dans un logfile

   logsave exécute la commande spécifiée avec les arguments donné, et sauve une copie de sa sortie dans un fichier de log. Si le répertoire pour logfile n'existe pas, logsave accumule la sortie dans sa mémoire jusqu'à ce qu'il puisse écrire. Une copie de la sortie est également écrite sur stdout. si la commande est '-', logsave prend l'entrée standard et le sauve dans le logfile. logsave est utile pour sauvegarder la sortie des scripts de boot jusqu'à ce que la partition /var soit monté.

OPTIONS

-a Ajoute la sortie dans le logfile au lieu d'écraser le fichier
-s Saute l'écriture dans le fichier de log le texte qui est entre crochet avec un ctrl-A (ASCII 001) ou ctrl-B (ASCII 002). Cela permet d'afficher une barre de progression.
-v mode verbeux
^
12 février 2014

htmlpdflatexmanmd




look

look

Affiche les lignes commençant par la chaîne donnée

   Si le fichier est omis, /usr/share/dict/words est utilisé, seul les caractères alphanumériques sont comparés et la casse est ignorée.

OPTIONS

-b recherche binaire
-d seul les caractère alphanumériques sont comparés
-f ignore la casse
-t Spécifie un caractère de terminaison de chaîne

Variables d'environnement

LANG Langage à utiliser pour déterminer le jeu de caractères
LC_ALL Langage à utiliser pour déterminer le jeu de caractères
LC_TYPE Langage à utiliser pour déterminer le jeu de caractères
^
19 septembre 2016

htmlpdflatexmanmd




lp

lp

Imprimer des fichiers

   lp demande l'impression d'un fichier ou modifie un travail d'impression en attente. Utiliser "-" pour forcer l'impression à partir de l'entrée standard. CUPS fournit plusieurs façons de spécifier la destination par défaut. Les variables d'environnement LPDEST et PRINTER sont lues en premier. Sinon, la commande lpoptions est utilisée, suivis par la valeur par défaut spécifiée en utilisant lpadmin.

OPTIONS

-- Fin des options
-E  Forcer le chiffrement lors de la connexion au serveur
-U username Indiquer l'identifiant à utiliser pour les connexions au serveur
-d destination Imprimer sur l'imprimante donnée
-h host[:port] Utiliser un autre serveur
-i id_travail Indiquer l'identifiant du travail d'impression à modifier
-m Envoyer un mail lorsque l'impression est terminée
copies Nombre de copies à effectuer (1 à 100)
-o nom=valeur [nom=valeur ...] Définir des options pour le travail d'impression
-q priorité Définir la priorité du travail d'impression (1 à 100), défaut: 50.
-s Ne pas afficher le numéro du travail
-t nom Définir le nom du travail
-H hh:mm Suspend l'impression jusqu'à l'heure définie
-H hold Suspend l'impression indéfiniment
-H immediate Imprime immédiatement
-H restart Relance un travail terminé
-H resume Lance une impression suspendu
-P liste-de-page Définis quelles sont les pages à imprimer

Options communes des travaux

-o collate=true Imprime des copies assemblées
-o fit-to-page Adapte le contenu pour remplir la page
-o job-hold-until=when Maintient le job jusqu'au temps spécifié. when peut être indefinite, day-time (entre 6h et 18h), night (entre 18h et 6h), second-shift (entre 16h et 0h), third-shift (entre 0h et 8h), ou weekend (samedi et dimanche)
-o job-hold-until=hh:mm Maintient le job jusqu'à l'heure UTC spécifiée
-o job-priority=priority Priorité du job de 1 à 100. Défaut: 50
-o job-sheets=name Imprime une page de couverture (bannière) avec le document. Peut être "classified", "confidential", "secret", "standard", "topsecret", ou "unclassified"
-o job-sheets=start-name,end-name Imprime les pages de couverture (bannières) avec le document
-o mirror Mirroir chaque page
-o media=size Définis la taille de la page (a4, letter, legal, etc.)
-o orientation-requested=4|5|6 Imprime en paysage (4=90° anti-horaire, 5=90° horaire, 6=180°)
-o sides=one-sided Imprime sur un côté du papier
-o sides=two-sided-long-edge Imprime recto-verso
-o sides=two-sided-short-edge Imprime recto-verso au format paysage
-o number-up={2|4|6|9|16} Affiche 2, 4, 6, 9, ou 16 pages du document sur chaque page
-o number-up-layout=layout Spécifie le layout des pages avec l'option number-up. "btlr", "btrl", "lrbt", "lrtb", "rlbt", "rltb", "tblr", ou "tbrl". Les 2 premières lettres déterminent l'ordre de colonne, les 2 dernières, l'ordre des lignes.
-o outputorder=reverse Imprime les page dans l'ordre inverse
-o page-border=border Imprime une bordure autour de chaque page. "double", "double-thick", "single", ou "single-thick"
-o page-ranges=page-list Spécifique quelles pages imprimer dans le document. La liste peut contenir des numéros et des plages (#-#) (ex: 1,3-5,16)

Exemples

Imprime 2 copies d'un document sur l'imprimante par défaut
lp -n 2 filename
Affiche un document legal recto-verso sur l'imprimante foo:
lp -d foo -o media=legal -o sides=two-sided-long-edge filename
lp -d foo -o number-up=2 filename
Affiche une représentation 2 pages sur l'imprimante foo:
lp -d foo -o number-up=2 filename
^
18 septembre 2016

htmlpdflatexmanmd




lpadmin

lpadmin

Configurer les imprimantes et classes d'imprimantes CUPS

   lpadmin configure les imprimantes et classes d'imprimantes CUPS. Il est également utilisé pour définir l'imprimante ou classe d'imprimante par défaut.

   Lorsque l'option -E est utilisée avant les options -d, -p ou -x, la communication avec le serveur est chiffré

   La première méthode d'utilisation de la commande (avec -d) définis l'imprimante ou la classe par défaut. Les impressions futures demandées par les commandes lp ou lpr utiliseront cette destination sauf avis contraire de l'utilisateur par l'utilisation de la commande lpoptions

   La seconde forme de la commande (avec -p) configure l'imprimante indiquée ou la classe.

   La troisième forme de la commande (avec -x) supprime l'imprimante ou classe destination. Tous les travaux d'impression en attente sur cette destination sont supprimés, et les travaux en cours d'impression sont arrêtés.

Options de configuration

   Les options suivantes sont reconnues pour la configuration d'une file d'impression

-c classe Ajouter l'imprimante donnée à la classe. Si la classe n'existe pas, elle est créée.
-i interface Crée un script d'interface System V pour l'imprimante. Ne peut pas être utilisée avec -P.
-m model Définis un script d'interface System V pour l'imprimante ou un fichier PPD pour l'imprimante du répertoire model ou en utilisant une des interfaces du pilote. ldinfo -m donne la liste des modèles pris en charge
-o cupsIPPSupplies=[true|false] Indique si le niveau de fournitures IPP doit être rapporté
-o cupsSNMPSupplies=[true|false] Indique si les valeurs SNMP du niveau de fourniture (rfc3805) doivent être rapportés
-o job-k-limit=valeur Définir les quotas par utilisateur en ko.
-o job-page-limit=valeur Définir les quotas par utilisateur en nombre de pages
-o job-quota-period=valeur Définir l'intervalle de temps pour les quotas par utilisateur, en seconde
-o job-sheets-default=bannière[,bannière] Fixer la ou les pages de bannière par défaut pour les travaux d'impression.
-o nom=valeur Définir une options PPD pour l'imprimante. lpoption -l donne la liste des options
-o name-default=valeu Définis au niveau du serveur une options par défaut pour la destination.
-o port-monitor=nom Fixer le programme à utiliser pour les communication binaires lors de l'impression (none, bcp, tbcp).
-o printer-error-policy=nom Stratégie à utiliser en cas d'erreur quand le programme de transmission n'arrive pas à envoyer le travail à l'imprimante. (abort-job, retry-job, retry-current-job, stop-printer).
-o printer-is-shared=true/false Place l'imprimante à l'état partagée ou non.
-o printer-op-policy=nom Stratégie des opérations IPP associées à l'imprimante.
-R nom-défaut Supprimer les options données pour l'imprimante
-r class Supprime l'imprimante de la classe. Si la classe devient vide, elle est supprimée
-u allow:{user|@group}{,user|,@group}*
-u deny:{user|@group}{,user|,@group}*
-u allow:all Définis les accès au niveau utilisateur sur une imprimante.
-v "device-uri" Définis l'attribut device-uri de la file d'impression. lpinfo -v pour la liste des URI
-D "info" Description textuelle de la destination
Active la destination et accepte les jobs, identique à lancer cupsaccept et cupsenable
-L "location" Emplacement textuelle de la destination
-P ppd-file Définir le fichier PPD (Postscript Printer Description) à utiliser avec cette imprimante. Annule -i

Exemples

Créer une file d'impression IPP Everywhere
lpadmin -p mon_imprimante -E -v ipp://mon_imprimante.local/ipp/print -m everywhere
^
06 septembre 2016

htmlpdflatexmanmd




lpc

lpc

Contrôle d'imprimantes en ligne de commande

   lpc permet de contrôler partiellement les files d’impression des imprimantes et classes d'imprimantes de CUPS et de récupéré l'état des files d'impression. lpc est spécifique au système d'impression de Berkeley, et ne permet pas de configurer les files d'attente de CUPS, utiliser lpadmin pour cela.

Commandes

exit
quit Quitter
Status Affiche l'état des files d'impression
^
06 septembre 2016

htmlpdflatexmanmd




lpinfo

lpinfo

Afficher les périphériques et pilotes disponibles

OPTIONS

 -E Chiffrer la connexion au serveur
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur
-l Afficher un liste longue.
--device-id id Indiquer l'ID des périphériques IEEE-1284 à faire correspondre lors du parcours de la liste des pilotes avec -m
--exclude-schemes list liste séparée par des virgules de périphériques ou de schémas PPD à exclure du résultat
--include-schemes list liste séparée par des virgules de périphériques ou de schémas PPD à inclure dans le résultat
--language locale Spécifie la langue lors de la création de la liste des pilotes avec -m
--make-and-model name marque et modèle correspondant lors de la création de la liste des pilotes avec -m
--product name Nom du produit à sélectionner lors de la création de la liste des pilotes avec -m
--timeout secondes Délais d'attente lors de la création de la liste des périphériques avec -m

Exemples

Lister tous les périphériques
lpinfo -v
Lister tous les pilotes
lpinfo -m
Lister tous les pilotes correspondants à HP LaserJet
lpinfo --make-and-model "HP LaserJet" -m
^
18 septembre 2016

htmlpdflatexmanmd




lpmove

lpmove

Déplacer un travail d'impression vers une nouvelle destination

   lpmove déplace le travail d'impression ou tous les travaux de source vers destination. Le travail peut être soit l'identifiant du travail d'impression, soit l'ancienne destination et l'identifiant du travail.

OPTIONS

 -E Chiffrer la connexion au serveur
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur

Exemples

Déplacer le travail 123 de old_printer vers new_printer
lpmove 123 new_printer
ou
lpmove old_printer-123 new_printer
Déplacer tous les travaux
lpmove old_printer new_printer
^
19 septembre 2016

htmlpdflatexmanmd




lpoptions

lpoptions

Afficher ou définir les options par défaut et d'imprimantes

   lpoptions affiche ou définis les options d'impression et les options par défaut. Sans spécifier d'imprimante, l'imprimante par défaut est utilisée. Si les options -l, -o ou -r ne sont pas spécifiés, les options courantes sont affichés sur stdout. Lancé en root, lpoptions gère les options pour tous les utilisateurs dans le fichier /etc/cups/lpoptions, sinon les options sont gérées dans le fichier ~/.cups/lpoptions.

OPTIONS

-E  Forcer le chiffrement lors de la connexion au serveur
-U username Indiquer l'identifiant à utiliser pour les connexions au serveur
-d destination[/instance] Définis l'imprimante par défaut.
-h host[:port] Utiliser un autre serveur
-l Liste les options spécifiques à l'imprimante et leur paramètre actuels
-o option[=value] Spécifie une nouvelle option
-p destination[/instance] Définis la destination et l'instance.
-f option Supprime l'option spécifiée
-x destination[/instance] Supprime les options pour la destination

Fichiers

~/.cups/lpoptions Options et instances par utilisateur
/etc/cups/lpoptions Options et instances pour tous les utilisateurs
^
18 septembre 2016

htmlpdflatexmanmd




lpq

lpq

Afficher le status des files d'impression

OPTIONS

 -E Chiffrer la connexion au serveur
-P destination[/instance] Spécifier l'imprimante ou nom de classe
-U Spécifier un identifiant alternatif
-a Afficher les jobs de toutes les imprimantes
-h server[:port] Spécifier le serveur
-l Mode plus verbeux
+interval Spécifier un interval pour un reporting continue
^
19 septembre 2016

htmlpdflatexmanmd




lpr

lpr

Imprimer des fichiers

   lpr demande l'impression de fichiers. Les fichiers qui sont donnés dans la ligne de commande sont envoyé à la destination donnée

OPTIONS

-E  Forcer le chiffrement lors de la connexion au serveur
-h host[:port] Utiliser un autre serveur
-C nom, -J nom, T nom Définir le nom du travail
-P destination[/instance] Imprimer les fichiers sur l'imprimante donnée
-U utilisateur Indiquer l'identifiant à utiliser pour les connexions au serveur
-# copies Nombre de copies à effectuer ( de 1 à 100)
-h Désactiver l'impression de la bannière. Équivalent à -o job-sheets=none
-l Indiquer que le fichier est déjà formaté pour la destination et qu'aucun filtre n'a besoin d'être appliqué. Équivalent à -o raw
-m Envoyer un mail lorsque l'impression est terminée
-o option[=valeur] Définir une option d'impression
-p Indique qu chaque page doit avoir un en-tête ombré avec la date, l'heure, le nom du travail d'impression et le numéro de page. Équivalent à -o prettyprint
-q suspendre l'impression d'un travail
-r Indiquer que les fichiers nommés doivent être effacés après l'impression

Options de job communes

   En plus les options spécifiques à l'imprimante reporté par lpoptions, les options génériques suivantes sont disponible:

-o collate=true Imprime des copies assemblées
-o fit-to-page Adapte le contenu pour remplir la page
-o job-hold-until=when Maintient le job jusqu'au temps spécifié. when peut être indefinite, day-time (entre 6h et 18h), night (entre 18h et 6h), second-shift (entre 16h et 0h), third-shift (entre 0h et 8h), ou weekend (samedi et dimanche)
-o job-hold-until=hh:mm Maintient le job jusqu'à l'heure UTC spécifiée
-o job-priority=priority Priorité du job de 1 à 100. Défaut: 50
-o job-sheets=name Imprime une page de couverture (bannière) avec le document. Peut être "classified", "confidential", "secret", "standard", "topsecret", ou "unclassified"
-o job-sheets=start-name,end-name Imprime les pages de couverture (bannières) avec le document
-o mirror Mirroir chaque page
-o media=size Définis la taille de la page (a4, letter, legal, etc.)
-o orientation-requested=4|5|6 Imprime en paysage (4=90° anti-horaire, 5=90° horaire, 6=180°)
-o sides=one-sided Imprime sur un côté du papier
-o sides=two-sided-long-edge Imprime recto-verso
-o sides=two-sided-short-edge Imprime recto-verso au format paysage
-o number-up={2|4|6|9|16} Affiche 2, 4, 6, 9, ou 16 pages du document sur chaque page
-o number-up-layout=layout Spécifie le layout des pages avec l'option number-up. "btlr", "btrl", "lrbt", "lrtb", "rlbt", "rltb", "tblr", ou "tbrl". Les 2 premières lettres déterminent l'ordre de colonne, les 2 dernières, l'ordre des lignes.
-o outputorder=reverse Imprime les page dans l'ordre inverse
-o page-border=border Imprime une bordure autour de chaque page. "double", "double-thick", "single", ou "single-thick"
-o page-ranges=page-list Spécifique quelles pages imprimer dans le document. La liste peut contenir des numéros et des plages (#-#) (ex: 1,3-5,16)

Exemples

Imprimer 2 copies d'un document sur l'imprimante par défaut
lpr -# 2 nom_fichier
Imprimer en recto-verso sur une page Legal avec l'imprimante toto
lpr -P foo -o media=legal -o sides=two-sided-long-edge nom_fichier
Imprimer une double composition avec l'imprimante toto
lpr -P foo -o number-up=2 nom_fichier
^
18 septembre 2016

htmlpdflatexmanmd




lprm

lprm

Annuler des jobs

OPTIONS

 -E Chiffrer la connexion au serveur
-P destination[/instance] Spécifier l'imprimante ou nom de classe
-U Spécifier un identifiant alternatif
-h server[:port] Spécifier le serveur
 - Annuler tous les jobs

Exemples

Annuler le job courant sur l'imprimante par défaut:
lprm
Annuler le job 1234
lprm 1234
Annuler tous les jobs
lprm -
^
19 septembre 2016

htmlpdflatexmanmd




lpstat

lpstat

Afficher les informations de status cups

   lpstat affiche les informations de status sur les classes, jobs et imprimantes courantes. Sans argument, liste les jobs actifs de l'utilisateur courant.

OPTIONS

-E  Forcer le chiffrement lors de la connexion au serveur
-H Afficher le port et nom du serveur
-R Afficher le rang des jobs
-U username Spécifier un nom d'utilisateur alternatif
-W which-jobs Spécifie quels jobs afficher (completed, not-conpleted). Doit apparaître avant -o et/ou les noms des imprimantes.
-a [printer(s)] Affiche l'états des files d'impression
-c [class(es)] Affiche les classe d'imprimantes et leur imprimantes.
-d Affiche la destination par défaut
-h host[:port] Utiliser un autre serveur
-l Liste long d'imprimantes, classes, et jobs
-o [destination(s)] Affiche les files d'impression et leur destination
-p [printer(s)] Affiche les imprimantes et si elles sont autorisé à imprimer.
-r Affiche si le serveur CUPS fonctionne
-s Affiche un sommaire
-t Affiche toutes les informations (= -r -d -c -v -a -p -o)
-u [user(s)] Affiche une liste de jobs d'impression de l'utilisateur spécifié.
-v [printer(s)] Affiche les imprimantes et quels périphériques y sont attachés.
^
28 juin 2010

htmlpdflatexmanmd




ls

ls, dir, vdir

Liste les informations sur les fichiers

   Pour les arguments non-options qui sont des répertoires, par défaut ls liste le contenu ces répertoires, non récursivement, et omet les fichiers cachés. Par défaut la sortie est triée alphabétiquement.

  dir est équivalent à ls -C -b

  vdir est équivalent à ls -l -b

Codes de sortie

0 succès
1 problèmes mineurs
2 problèmes sérieux

Options: fichiers listés

-a, --all Affiche également les fichiers cachés.
-A, almost-all identique, mais ignore '.' et '..'
-B, --ignore-backups ignore les fichiers se terminant par '~'
-d, --directory liste seulement le nom des dossiers, au lieu de lister leur contenu. ne suit pas les liens symbolique. a moins que -H, ou -L ne soit spécifié.
-H, --dereference-command-line si la ligne de commande spécifie un lien symbolique, affiche des informations sur la référence au lieu du lien lui-même.
--dereference-command-line-symlink-to-dir ne déréférence pas les liens symboliques, avec une exception : si un argument de ligne de commande spécifie un lien symbolique qui réfère à un répertoire, affiche les informations pour ce répertoire au lieu du lien. c'est le mode par défaut.
--group-directories-first Groupe tous les fichiers, puis les affiche avant les fichiers.
--hide=PATTERN Dans les dossiers, ignore les fichiers dont le nom correspond à PATTERN, identique à -I, sauf si -a ou -A est donné.
-I PATTERN, --ignore=PATTERN Dans les dossiers, ignore les fichiers correspondant à PATTERN.
-L, --dereference En affichant les informations de fichier sur un lien symbolique, affiche les informations pour la référence au lieu du lien lui même, cependant ls affichera toujours le nom du lien symbolique.
-R, --recursive Liste le contenu de tous les répertoires récursivement.

Options: informations affichées

--author Liste chaque auteur de fichier en produisant un listing au format long.
-D, --dired Avec le fomat long -l, affiche une ligne additionnelle après la sortie principale du type : //DIRED// BEG1 END1 BEG2 END2 ....

           BEGN et ENDN sont des entiers non-signés qui enregistrent la position de l'octet du début et de la fin de chaque non de fichier dans la sortie.

  Si les dossiers sont listés récursivement, une sortie est produite pour les sous-répertoire :

  //SUBDIRED// BEG1 END1

  et enfin, une ligne sous la forme :

  //DIRED-OPTIONS// --quoting-style=WORD

--full-time Affiche la la date au format long.
-g N'affiche pas le propriétaire du fichier.
-G, --no-group N'affiche pas le groupe propriétaire du fichier
-h, --human-readable Affiche la taille de chaque fichier avec un préfixe.
-i, --inode Affiche le numéro d'inode de chaque fichier
-l, --format=long, format=verbose Affiche le type de fichier, les permissions, user:group, la taille et la date.

        Le type de fichier est un des suivant :
        - fichier régulier
        b fichier spécial block
        c fichier spécial caractère
        C Fichier haute performance
        d répertoire
        l lien symbolique
        p FIFO
        s socket
        ? autre
       
        les bits de mode :
        s set-user-ID ou set-group-ID et le bit exécutable correspondant sont mis
        S set-user-ID ou set-group-ID et mis mais pas le bit exécutable correspondant
        t sticky bit et le bit exécutable au autres sont mis
        T sticky bit est mis mais pas le bit exécutable aux autres
        x le bit exécutable est mis
        - rien n'est mis
        ls utilise un '.' pour indiquer un fichier avec SELinux, mais sans autre méthode d'accès alternatif.

-n, --numéric-uid-gid affiche l'ID des user:group au lieu des noms.
-o n'affiche pas les information de groupe
-s, --size affiche l'allocation de disque de chaque fichier. C'est la quantité d'espace disque utilisé par le fichier, qui est généralement un petit peu plus que la taille du fichier.
--si identique à -h, mais utilise les puissance de 1000.
-Z, --context Affiche le contexte de sécurité SELinux ou ' ?' si rien n'est trouvé.

Options: trie

-c, --time=ctime, --time=status si -l ou -o est utilisé, affiche le ctime au lieu du mtime.
-f ne trie pas les fichiers
-r, --reverse inverse l'ordre de trie
-S, --sort=size trie par taille, du plus gros au plus petit
-t, --sort=time trie par mtime, du plusrécent au plus ancien
-u, --time=atime, --time=access, -time=use affiche le atime au lieu du mtime
-U, --sort=version trie par numéro et nom de version, le plus faible en premier.
-X, --sort=extension trie alphabétiquement par extension de fichier.

Options: formatage de la sortie

-1, --format=single-column liste les fichiers, un par ligne
-C, --format=vertical Liste les fichiers en colonne, triés verticalement.
--color [=WHEN] Utilise des couleurs pour distinguer les types de fichiers. WHEN peut être :

        none N'utilise pas les couleur
        auto utilise uniquement les couleur si la sortie standard est le terminal
        always utilise toujour les couleurs

-F, --classify, --indicator-style=classify Ajoute un caractère à chaque fichier indiquant le type de fichier :

         *  exécutable
        / répertoire
        @ lien symbolique
        | fifo
        = socket

--file-type, --indicator-style=file-type Ajoute un caractère à chaque fichier indiquant le type de fichier. identique à -F mais n'indique pas les exécutables.
--indicator-style=WORD Ajoute un caractère à chaque nom de fichier du type WORD :

        none n'ajoute pas de caractère.
        slash Ajoute un / pour les répertoires. identique à -p
        file-type dentique à --file-type
        classify ajoute un * aux fichier réguliers exécutables, sinon fonctionne comme file-type. identique à -F ou --classify

-k affiche la taille des fichiers en blocks de 1024 octets.
-m, --format=commas Liste les fichiers horizontalement, autant qu'il pourra sur chaque ligne, séparés par ', '
-p, --indicator-style=slash ajoute un / à chaque dossier
-x, --format=across, format=horizontal Liste les fichiers en colonnes, triés horizontalement
-T COLS, --tabsize=COLS Définit la largeur des tabulations (défaut 8).
-w, --width=COLS définit la largeur de l'écran. par défaut utilise les paramètres du terminal ; sinon la variable d'environnement COLUMNS est utilisé si elle est définie, sinon le défaut est 80.
--time-style=STYLE liste la date dans le style STYLE :

        +FORMAT FORMAT est interprété comme un argument de date.
        full-iso affiche la date en utilisant ISO 8601. le style est équivalent à +%Y-%m-%d %H:%M:%S.%N %z
        long-iso Liste la date au format ISO 8601. est équivalent à +%Y-%m-%d %H:%M
        iso liste au format ISO 8601 pour les date anciennes. est équivalent à +%Y-%m-%d $newline%m-%d %H:%M
        locale affiche la date sous la forme locale, généralement définit par LC_TIME.
        posix-STYLE affiche la date au format posix. STYLE peut être un des précédent.

Options: formater les noms des fichiers

-b, --escape, --quoting-style=escape met un '\' devant les caractères non graphiques
-N, --literal, --quoting-style=literal ne quote pas les noms de fichier. les caractères non-graphique sont affichés avec un 'question mark' si la sortie est le terminal.
-q, --hide-control-chars affiche un 'question mark' au lieu des caractères non-graphiques dans les noms de fichier.
--show-control-chars Affiche les caractères non-graphique tels quel dans les noms de fichier.
-Q, --quote-name, quoting-style=c Met les noms de fichier entre '"'.
--quoting-style=WORD WORD peut être :

        literal affiche les noms tels quels
        shell met les noms de fichier entre ' s'ils contiennent des méta-caractères.
        shell-always met tous les noms de fichier entre '
        c Met les nom de fichier entre "
        escape met un '\' devant les caractères non graphiques
        clocale met les noms de fichier entre ` et '
        locale identique à clocale
        On peut spécifier la valeur par défaut de --quoting-style avec la variable d'environnement QUOTING_STYLE.

Variables d'environnement

QUOTING_STYLE Spécifie la valeur par défaut de --quoting-style
^
31 octobre 2016

htmlpdflatexmanmd




lsattr

lsattr

Lister les attributs de fichier dans un système de fichier ext

OPTIONS

-R Lister les attributs récursivement dans les répertoires et leur contenu
-a Lister tous les fichiers dans les répertoires, incluant les fichiers cachés
-d Lister les répertoire comme les autres fichiers au lieu de lister leur contenu
-l Afficher les options utilisant des noms long au lieu d'un simple caractère
-p Lister le numéro de projet du fichier
-v Lister le numéro de version/génération du fichier
^
07 mai 2016

htmlpdflatexmanmd




lsblk

lsblk

Liste les informations sur tous les périphériques block spécifiés ou disponible.

OPTIONS

-a, --all Liste également les périphériques vide
-b, --bytes Affiche la colonne de taile en octets au lieu du format human-readable
-D, --discard Affiche des informations sur les capacités interdites pour chaque périphériques
-d, --nodeps Ne pas afficher le propriétaire ou les esclaves.
-e, --exclude list Exclus les périphériques spécifiés par une liste séparée par une ',' de numéro de périphérique majeur. les ramdisk sont exclus par défaut.
-f, --fs Affiche des informations sur les systèmes de fichier. Équivalent à -o NAME,FSTYPE,LABEL,MOUNTPOINT
-I, --include list Inclus les périphériques spécifiés.
-i, --ascii Utilise des caractères ASCII pour le formatage de l'arborescence
-l, --list Produit une sortie sous la forme d'une liste
-m, --perms Affiche des informations du le propriétaire et les permissions. Équivalent à -o NAME,SIZE,OWNER,GROUP,MODE
-o, --output list Spécifie quelles colonnes afficher.
-O, --output-all Affiche toutes les colonnes disponibles
-P, --pairs Produit une sortie sous la forme de paires clé="valeur".
-p, --paths Affiche les chemins de périphériques complet
-r, --raw Produit une sortie au format brut.
-s, --scsi Affiche seulement les périphériques scsi. Toutes les partitions, esclaves ou propriétaire sont ignorés.
-s, --inverse Affiche les dépendance dans l'ordre inverse
-t, --topology Affiche une topologie de périphérique block. Équivalent à -o NAME,ALIGNMENT,MIN-IO,OPT-IO,PHY-SEC,LOG-SEC,ROTA,SCHED,RQ-SIZE,WSAME
-x, --sort column Trie les ligne par la colonne spécifiée.

codes de retour

0 Réussite
1 Échec
32 Aucun des périphériques indiqués n'a été trouvé
64 Les périphériques indiqués n’ont pas tous été trouvés

Variables d'environnement

LIBBLKID_DEBUG =all Activer la sortie de débogage de libblkid
LIBMOUNT_DEBUG =all Activer la sortie de débogage de libmount.
LIBSMARTCOLS_DEBUG =all Activer la sortie de débogage de libsmartcols
^
15 juin 2013

htmlpdflatexmanmd




lscgroup

lscgroup

Liste tous les cgroups

OPTIONS

‹controllers›:‹path› Définis le cgroup et ses enfants à afficher, sinon affiche tous les cgroups
^
03 février 2016

htmlpdflatexmanmd




lscpu

lscpu

Afficher des informations sur l'architecture des micro-processeurs

   lscpu s'appuye sur le contenu de sysfs et /proc/cpuinfo pour afficher les informations de manière optimisées et faciliter la lecture.

OPTIONS

-a, --all Inclu les processeurs hors ligne. Nécessite -e ou -p
-b, --online Limite la sortie aux cpu online. Nécessite -e ou -p
-c, --offline Limite la sortie aux cpu offline. Nécessite -e ou -p
-e, --extended[=liste] Mode tableau
-p, --parse[=liste] Optimise la sortie pour faciliter l'analyse
-s, --sysroot ‹dir› Collecte le données pour une autre instance. Le répertoire est la racine du système de l'instance Linux à inspecter
-x, --hex Utilise les notations hexadécimales
^
22 mai 2017

htmlpdflatexmanmd




lsinitrd

lsinitrd

Outil pour afficher le contenu d'une image initramfs

OPTIONS

-s, --size Trie le contenu par taille
-f, --file ‹filename› afficher le contenu du fichier spécifié
-k, --kver ‹kernel version› Affiche l'initramfs de la version kernel spécifiée
--unpack décompresse l'initramfs dans le répertoire courant au lieu d'afficher le contenu
--unpackearly décompresse le microcode dans le répertoire courant
-v, --verbose décompresse en mode verbeux
^
25 mars 2016

htmlpdflatexmanmd




lsipc

lsipc

Affiche les informations sur les facilités IPC actuellement employés dans le système

OPTIONS

-i, --id Affiche des détails sur la ressource spécifiée par son id. Doit être combiné avec -m, -q ou -s
-g, --global Affiche l'utilisation système et les limites. Cette option peut être combiné avec -m, -k ou -s.
-m, --shmems Affiche des informations sur les segments mémoire partagés actifs
-q, --queues Affiche des informations sur les files de messages actives
-s, --semaphores Affiche des informations sur les jeux de sémaphore actifs
-c, --creator Affiche le createur et le propriétaire
-e, --export Affiche les donnée au format NAME=VALUE
-J, --json Utilise le format JSON
-l, --list Utilise le format liste.
-n, --newline Affiche chaque information sur une ligne séparée
--noheadings N'affiche pas les en-tête
--notruncate Ne tronque pas la sortie
-o, --output list Spécifie quelle colonnes afficher
-p, --pid Affiche les PID du créateur et du dernier opérateur
-r, --raw Sortie brute
-t, --time Affiche les informations de temps.
--time-format type Affiche les date au format short, full ou iso.
^
25 mars 2016

htmlpdflatexmanmd




lslogins

lslogins

Affiche des informations sur les utilisateurs connus dans le système

   Examine les logs wtmp et btmp, /etc/shadow et /etc/passwd et affiche les informations souhaitées.

OPTIONS

-a, --acc-expiration Affiche les données sur la date du dernier changement de mot de passe et la date d'expiration du compte.
--btmp-file Chemin alternatif pour btmp
-c, --colon-separate Sépare les informations sur chaque utilisateur avec une ',' au lieu d'un newline
-e, --export Affiche les données au format NAME=VALUE
-f, --failed Affiche les données sur la dernière tentative de connection échouée de l'utilisateur
-G, --supp-groups Affiche des informations sur les groupes
-g, --groups affiche seulement les utilisateurs appartenant aux groupes spécifiés.
-L, --last Affiche les informations sur les données contenant les dernières sessions des utilisateurs.
-l, --logins Affiche seulement les données des utilisateurs avec un login spécifié. Plus d'un login peut être spécifié
-n, --newline Affiche chaque information sur une nouvelle ligne
--noheadings N'affiche pas les en-têtes
--notruncate Ne tronque pas la sortie
-o, --output Spécifie quel colonnes afficher
-p, --pwd Affiche des informations liées au login par mot de passe
-r, --raw Sortie brute
-s, --system-accs Affiche les comptes système.
--time-format affiche les dates au format cour
-u, --user-accs Affiche les comptes utilisateur
--wtmp-file Chemin alternatif pour wtmp
-Z, --context Affiche le contexte de sécurité de l'utilisateur
-z, --print0 Délimite les entrées utilisateur avec un caractère null au lieu d'une nouvelle ligne
^
28 mars 2016

htmlpdflatexmanmd




lsmod

lsmod

Affiche le statut des modules dans le kernel Linux

   lsmod est un programme simple qui format le contenu de /proc/modules, affichant les modules actuellement chargés

^
23 mars 2014

htmlpdflatexmanmd




lspci

lspci

Utilitaire pour afficher des informations sur les bus PCI dans le système et les périphériques connectés

   Par défaut, il affiche une liste brève des périphériques.

Options d'affichage basic

-m Dump les données de périphériques dans une forme compatible
-mm Dump les données de périphériques dans une forme plus facile à parser par un script
-t Affiche un diagramme hiérarchique contenant tous les bus, ponts, périphériques et leur connexions entre eux

Options d'affichage

-v mode verbeux peut être spécifié jusqu'à 3 fois pour augmenter la verbosité (-vvv)
-k Affiche les pilotes du kernel manipulant le périphérique et les modules capable de le manipuler.
-x Affiche un dump hexadécimal de la partie standard de l'espace de configuration ( les 64 ou 128 octets pour les pont CardBus )
-xxx Affiche un dump hexadécimal de tout l'espace de configuration PCI
-xxxx Affiche un dump hexadécimal de l'espace de configuration PCI étendu (4096 octets) disponible sur les bus PCI express et PCI-X 2.0
-b View centrée sur les bus. Affiche les numéros d'IRQ et les adresses tel que vue par les cartes sur le bus PCI.
-D Affiche toujours les numéros de domaine PCI.

Options de contrôle de résolution d'ID en nom

-n  Affiche les code de vendeur et de périphérique en nombre au lieu de les rechercher dans la liste d'ID
-nn  Affiche les codes de vendeur et de périphérique en nombre et en nom
-q Utilise DNS pour requêter une base d'ID PCI centrale si le périphérique n'est pas trouvé dans le fichier local. Si la recherche DNS réussie, le résultat est mis en cache dans ~/.pciids-cache
-qq Idem, mais le cache local est réinitialisé
-Q Requête la base centrale pour toutes les entrées

Options pour la séléction des périphériques

-s [[[[‹domain›]:]‹bus›]:][‹slot›][.[‹func›]] Affiche seulement les périphériques dans le domaine spécifié. Les domaines sont numérotés de 0 à ffff, les bus de 0 à ff, les slot de 0 à 1f et les fonctions de 0 à 7. Chaque composant peut être omi ou définis à *. Tous les nombres sont héxadécimaux.
-d [‹vendor›]:[‹device›] Affiche uniquement les périphériques avec l'ID de vendeur et de périphérique spécifié.

Autres options

-i ‹file› Utilise le fichier de liste d'ID spécifié au lieu de /usr/share/misc/pci.ids
-p ‹file› Utilise le fichier spécifié comme table d'ID PCI manipulé par les modudes du kernel au lieu de /lib/modules/kernel_version/modules.pcimap
-M Invoque le mode de mappage de bus qui effectue un scan de tous les périphériques PCI, incluant ceux qui sont mal configurés. Utile uniquement avec un mode d'accès hardware direct. Le mappeur de bus ne scanne que le domain PCI 0

Options d'accès PCI

   PCI utilise la librairie PCI pour communiquer avec les périphériques PCI (voir pcilibs(3)). On peut utiliser les options suivantes pour influencer sont fonctionnement:

-A ‹method› La librairie supporte de nombreuses méthodes pour accéder au hardware PCI. Par défaut, elle utilise la première méthode disponible. -A help pour voir les méthodes disponible.
-O ‹param›=‹value› Le fonctionnement de la librairie est contrôlée par de nombreux paramètres. -O help pour lister les paramètres connus.
-H1 Utilise l'accès hardware direct via le mécanisme de configuration Intel 1 (idem -A intel-conf1)
-H2 Utilise l'accès hardware direct via le mécanisme de configuration Intel 2 (idem -A intel-conf2)
-F ‹file› Au lieu d'accéder au vrai hardware, lis la liste des périphériques et leurs valeurs depuis leurs registre de configuration depuis le fichier spécifié, produit par lspci -x.
-G Augmente le niveau de verbosité de la librairie.

Affichage

   Pour traitement la sortie de lspci automatiquement, utiliser les formats machine-readable (-m, -vm, -vmm). Tous les autres formats peuvent changer d'un version à une autre. Tous les nombres sont en hexadécimal.

Format simple

   Dans le format simple (-m), chaque périphérique est décris sur une seule ligne, qui est formatté comme paramètres utilisable par un script. Certains arguments sont positionnels: slot, class, vendor name, device name, subsystem vendor et subsystem name. Le reste des arguments sont:

        -rrev numéro de révision
        -pprogif interface de programmation

   L'ordre relatif des arguments positionnels et options est indéfinis.

Format verbeux

   le format verbeux (-vmm) est une séquence d'enregistrements séparés par des lignes blanches. Chaque enregistrement décris un périphérique par une séquence de lignes, chaque ligne contenant un paire tag: value Les tags sont sensibles à la casse. Les tags suivants sont définis:

        Slot Le nom du slot où le périphérique réside ([domain:]bus:device.function). C'est toujours le premier enregistrement
        Class Nom de la classe
        Vendor Nom du vendeur
        Device Mon du périphérique
        SVendor Nom du vendeur du sous-système
        SDevice Mon du sous-système
        PhySlot Le slot physique où réside le périphérique
        Rev Numéro de révision
        ProgIf Interface de programmation
        Driver Pilote actuellement utilisé
        Module Modules kernel capables de gérér ce périphérique

Format verbeux compatible

   (-vm) Dans ce mode, lspci tente d'être compatible avec ses anciennes versions.

Fichiers

/usr/share/misc/pci.ids Liste d'ID PCI connus, maintenus à http://pciids.sourceforge.net/. utiliser update-pciids pour le metter à jours
/usr/share/misc/pci.ids.gz Si compilé avec le support de la compression, ce fichier est tenté avant pci.ids
~/.pciids-cache Tous les ID trouvés via les requêtes DNS.
^
15 juin 2013

htmlpdflatexmanmd




lssubsys

lssubsys

Liste les hiérarchies contenant le sous-système donné

OPTIONS

controller Définis le sous-système dont la hiérarchie est affichée.
-m, --mount-points Affiche les points de montage. seul le premier point de montage des hiérarchies sont affichées
-M, --all-mount-points Affiche tous les points de montage
-a, --all Affiche tous les sous-systèmes, incluant ceux non montés
-i, --hierarchies Affiche le nombre de hiérarchie attachées si le sous-système est dans une hiérarchie
^
21 mars 2014

htmlpdflatexmanmd




lsusb

lsusb

Utilitaire pour afficher les informations sur les bus USB dans le système et les périphériques connectés

OPTIONS

-v, --verbose mode verbeux
-s [[bus]:][devnum] Affiche uniquement les périphériques sur le bus spécifié et/ou le devnum, donnés en décimal
-d [vendor]:[product] Affiche seulement les périphériques avec le vendor ID et le product ID, donnés en hexa
-D device Ne scanne pas /dev/bus/usb, mais affiche uniquement les informations sur le périphérique dont le fichier est donné. (devrait être sous la forme /dev/bus/usb/001/001)
-t Dump l'arborescence des périphériques USB.

Fichiers

var/lib/usbutils/usb.ids Une liste de tous le ID de périphériques connus (vendeurs, produits, classes, sous-classes et protocoles)
^
22 mars 2016

htmlpdflatexmanmd




luksformat

luksformat

Créé et format un périphérique LUKS

   luksformat est un wrapper autour de cryptsetup et mkfs qui fournis une interface simple pour créer un périphérique chiffré qui suis le standard LUKS et pour placer un système de fichier dans le périphérique chiffré. Le système de fichier par défaut est vfat vu qu'il est plus commun sur les périphérique amovibles.

syntaxe:
luksformat [-t fstype] device [mkfs_options]

^
15 juin 2016

htmlpdflatexmanmd




lvchange

lvchange

Changer les attributs d'un volume logique

OPTIONS

-a|--activate [a][e|s|l]{y|n} Contrôle la disponibilité des volumes logiques à utiliser immédiatement après que la commande soit terminées. Par défaut, les nouveaux volumes logiques sont activés (-ay). -an laisse le nouveau volume logique inactif si possible. -aay, l'autoactivation est gérée avec un match dans activation/auto_activation_volume_list dans lvm.conf. -aey active exclusivement sur un nœud et -a{a|l}y active seulement sur le nœud local.
--activationmode {complete|degraded|partial} Le mode d'activation détermine si les volumes logiques sont autorisés à être activés quand il y a des volumes physiques manquant. complete est le plus restrictif. degraded autorise les LV RAID même si des PV sont manquant (mirror n'est pas considéré comme LV raid). partial permet d'activer tout LV même si des portions sont manquants
--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
-k|--setactivationskip {y|n} Contrôle si les volumes logiques sont flaggés pour être ignoré à l'activation. --ignoreactivationskip doit être utilisé. Le flag n'est pas appliqué durant la désactivation. Utiliser lvchange --setactivationskil pour changer le flag skip. voir activation/auto_set_activation_skip dans lvm.conf.
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--cachepolicy Policy Seulement pour les LV cache. Définis la stratégie de cache. mq est la stratégie de base, smq est plus avancé
--cachesettings Key=Value Seulement pour les LV cache. Définis les paramètres cache.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-C|--contiguous {y|n}
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--deltag Tag
--detachprofile
--discards {ignore|nopassdown|passdown}
--errorwhenfull {y|n}
--ignorelockingfailure
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié
--ignoreskippedcluster
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
--monitor {y|n} Active le monitoring d'un mirroir, snapshot ou pool thin avec dmeventd si installé. Si un périphérique utilisé par un mirroir monitoré reporte une erreur d'E/S, l'erreur est gérée en accord avec activation/mirror_image_fault_policy et activation/mirror_log_fault_policy dans lvm.conf
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-P|--partial
-p|--permission {r|rw} Définis les permissions d'accès. Défaut: rw
-M|--persistent {y|n} [--major Major] [--minor Minor] À yes, le numéro mineur est persistant. Les volumes pool ne peuvent pas avoir de numéros mineur et majeur persistants. Définis le numéro majeur et mineur. Non supporté avec les volumes pools. Ignoré avec les kernels récents
--poll {y|n} Sans le polling de transformation en tâche de fond d'un volume logique le processus ne se complète jamais. S'il y a un pvmove ou lvconvert incomplet, utiliser --poll y pour relancer le processus.
--[raid]maxrecoveryrate Rate Définis le taux de récupération maximum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]minrecoveryrate Rate éfinis le taux de récupération minimum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]syncaction {check|repair} Utilisé pour initialiser diverses opérations de synchronisation RAID. check et repair fournissent un moyen de vérifier l'intégrité du lv RAID.
--[raid]writebehind IOCount Nombre maximum d'écritures en suspend permis dans les périphériques dans un RAID1 marqué write-mostly. Une fois cette valeur atteinte, les écritures deviennent synchrones. À 0, permet au système de choisir la valeur arbitrairement.
--[raid]writemostly PhysicalVolume[:{y|n|t}] Marque un périphérique RAID1 en write-mostly. Toutes les lectures sur des périphériques sont évités sauf si nécessaire.
-r|--readahead {ReadAheadSectors|auto|none} Définis le compteur de secteur read ahead de ce volume logique.
--refresh Si le lv est actif, recharche ses métadonnées.
--resync Force une resynchronisation complète d'un mirroir.
-S|--select Selection Critère de sélection
--sysinit Indique que lvchange est invoqué à l'initialisation du système, avant que les systèmes de fichiers accessible en écriture soient disponibles. Équivalent à --ignorelockingfailure --ignoremonitoring --poll n et définir LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-Z|--zero {y|n} Définis le mode de provisionnement pour les pool thin.

Variables d'environnement

LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES Supprime les messages d'erreur de lock

Exemples

Change les permissions dans le volume lvol1 dans le vg vg00
lvchange -pr vg00/lvol1
^
06 juin 2016

htmlpdflatexmanmd




lvconvert

lvconvert

Convertis un volume logique lineaire vers un mirroir ou snapshot

   lvconvert est utilisé pour changer le type de segment ou les caractéristiques d'un volume logique. Par exemple, il peut ajouter ou supprimer les images redondantes d'un volume logique, changer le type de log d'un mirroir, ou désigner un volume logique comme dépôt de snapshot.

   Si la conversion nécessite l'allocation d'extents physique, l'allocation sera restreinte à ces extents physique. Si la conversion libère des extents physiques et qu'un ou plusieurs PV sont spécifiés, les extents physiques sont d'abords libérés depuis ces PV.

opérations

   Une seule de ces option est requise:

--cache, -H, --type cache Convertis un volume logique en LV cache avec l'utilisation d'un pool cache spécifié avec --cachepool.
--corelog identique à --mirrolog core
--merge Fusionne un snapshot dans son volume d'origine ou fusionne une image raid1 (qui a été splitée de son mirroir avec --trackchanges) dans son mirroir. Si les 2 volumes ne sont pas ouverts, la fusionne démarre immédiatement. Fusionner un snapshot dans un origine qui ne peut pas être fermé et diferré à la prochaine activation du volume. Durant la fusion, les lectures et écritures de l'origine apparaîssent comme s'ils étaient dirigés dans le snapshot à fusionner. Une fois terminé, le snapshot est supprimé. Plusieurs snapshots peuvent être spécifiés sur la ligne de commande ou un @tag peut être utilisé pour spécifier plusieurs snapshots.
--mirrorlog {disk|core|mirrored} Spécifie le type de log à utiliser. Défaut: disk, qui est persistant est nécessite peut d'espace disque, généralement sur un disques séparé. Core peut être utile pour les mirroirs à durée de vie courte: il signifie que le mirroir est regénéré en copiant les données depuis le premier périphérique à chaque fois que le périphérique est actuvé. mirrored créé un log persistant qui est lui-même mirroré.
--mirrors Spécifie le degré du mirroir à créer. Par exemple "-m 1" convertis le volume logique d'origine en un mirroir avec 2 parties; c'est à dire un volume linéaire avec une copie. Il y a 2 implémentations mirroir qui correspondent aux type de segment mirroir et raid1. le type par défaut est raid1.
--repair Répare un mirroir après une erreur disque et tente de fixer les métadonnées de pool thin. Par défaut, le nombre de mirroir d'origine sera restauré si possible. -y permet de répondre automatiquement aux questions. -f permet de ne rien remplacer. --use-policies utilise la stratégie de remplacement spécifiée dans lvm.conf. La réparation des pools thin ne peut se faisre que sur les volume thin inactifs. Il n'y a pas de validation des métadonnées entre le kernel et lvm2, et nécessite un travail manuel ultérieur. Une fois réparé, les anciennes métadonnées sont disponibles dans le LV "‹pool›_meta‹n›".
--replace Supprime le PV spécifié et le remplace avec un disponible dans le VG ou depuis la liste fournie. Seulement disponible pour les types de segment raid.
--snapshot Recréé un snapshot de volumes logique après avoir été séparés en utilisant --splitsnapshot.
--split Sépare le volume logique spécifié.
--splitcache Sépare le volume logique cache du pool de cache. Avant qu'il soit sortie du cache, le cache est vidé. Le volume est ainsi laissé inutilisé et peut être utilisé pour cacher un autre volume.
--splitsnapshot Sépare le volume logique snapshot spécifié de son origine. Le volume splitté contient les chunks qui diffèrent de l'origine avec les métadonnées les décrivant. Ce volume peut être effacé et détruit avec lvremove. l'inverse de --snapshot
--splitmirrors Spécifie le nombre d'images redondantes d'un mirroir à splitter pour former un nouveau volume logique. Un nom doit être fournis pour le nouveau LV avec --name, sauf si --trackchanges est spécifié
-T, --thin, --type thin Converti le volume logique en volume logique thin du pool thin spécifié avec --thinpool. Le volume logique original est renomé en un nouveau volume logique lecture-seule. utiliser --originname pour spécifier un nom. Le volume ne peut plus être modifié tant qu'il est utilisé comme volume d'origine externe pour les zones non-provisionnées d'un volume logique thin.
--type SegmentType Utilisé pour convertir un volume logique en un autre type de segment (cache, cache-pool, raid1, snapshot, thin, ou thin-pool). En convertissant un volume logique en LV cache, l'argument --cachepool est requis. En convertissant un volume logique en LV thin, --thinpool est requis.
--uncache décache le volume logique cache spécifié. Avant que le volume devienne non-caché, le cache est vidé. à la différence avec --splitcache le volume pool cache est supprimé. Cette option est l'inverse de --cahe.

OPTIONS

-b, --background Lance en tâche de fond
--cachepolicy Policy Définis la stratégie de cache. mq est le nom de la stratégie de base. smq est plus avancé.
--cachepool CachePoolLogicalVolume{Name|Path} Cet argument est nécessaire en convertissant un volume logique en LV cache.
--cachesettings Key=Value Définis les paramètres de cache.
-c, --chunksize ChunkSize[b|B|s|S|k|K|m|M|g|G] Donne la taille de chunk pour les volumes logique snapshot, pool cache et pool thin. Pour les snapshots, la valeur doit être en puissance de 2 entre 4Kib et 512Kib. Défaut: 4. pour les cache, la valeur doit être entre 32KiB et 1GiB, défaut: 64. pour les pools thin, la valeur doit être entre 64KiB et 1GiB.
--discards {ignore|nopassdown|passdown} Traitement des annulations par la couche thin dans le kernel et passé au volume physique.
-i, --interval ‹seconds› Interval d'affichage de la progression en %
--name Le nom à appliquer à un volume logique qui a été splitté depuis un volume logique mirroir
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--oniginname NewExternalOriginVolumeName Le nouveau nom pour le volume logique original, qui devient le volume origine externe pour un volume logique thin. Sans cette option, le nom par défaut est "lvol‹n›" où ‹n› est le numéro LVM interne du volume logique. Ce volume sera lecture seule est ne peut plus être modifié tant qu'il est utilisé comme origine externe.
--poolmetadata PoolMetadataLogicalVolume{Name|Path} Spécifie les métadonnées cache ou thin. La taille devrait être entre 2Mio et 16Gio. Le pool cache est spécifié avec l'option --cachepool. Le pool thin est spécifié avec l'option --thinpool. Si le pool spécifié existe déjà, les métadonnée du pool seront placées dans le volume logique. Les propriétés du poor sont préservées par défaut. Il peut être utile pour réparer les métadonnées de pool ou pour redimensionner offline.
--poolmetadatasize PoolMetadataSize[b|B|s|S|k|K|m|M|g|G] Définis la taille des métadonnées du pool thin ou cache. La valeur par défaut est estimée avec (Pool_LV_size / Pool_LV_chunk_size addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo 64bits).
--poolmetadataspare {y|n} Contrôle la création et la maintenance de métadonnées de volume logique spare utilisé pour la récupération automatique de pool. Seul un tel volume est maintenu dans un volume group avec une taille des plus grosses métadonnées de volume du pool. Défaut: yes.
-r, --readahead {ReadAheadSectors|auto|none} Définis le compteur de secteurs de readhead des métadonnées de volume logique du pool thin. Défaut: auto.
-R, --regionsize MirrorLogRegionSize Un mirroir est divisé en régions de cette taille (en Mo), et le log mirroir utilise cette granularité pour tracer quelles région sont en synchro
--stripes Indique le nombre de stripes. C'est égale au nombre de volumes physiques pour disperser le volume logique. Ne peut pas s'appliquer à un espace déjà alloué.
-I, --stripesize Indique le nombre de Ko pour la granularité des stripes. La tailles doit être une puissance de 2 mais ne peut excéder la taille d'extent physique.
--thinpool ThinPoolLogicalVolume{Name|Path} Spécifie ou convertis un volume logique en un volume de données de pool thin. Le contenu du volume convertis est perdu. Les métadonnées du volume logique du pool thin peuvent être spécifiés avec l'option --poolmetadata ou alloués avec --poolmetadatasize.
--trackchanegs Avec --splitmirrors dans un raid1, suit les changements pour que l'image lecture seul détacchée peut être fusionnée efficacement de nouveau dans le mirroir. Seul les régions du périphérique détaché où les données ont changés seront resynchronisés.
-Z, --zero {y|n} Contrôle les 0 des premiers 4Kio de données dans le snapshot. Si le volume est lecture seul, le snapshot ne sera pas mis à 0. Pour les volume thin il contrôle les 0 des blocks provisionnés. Noter que provisionner un grand nombre de chunks à 0 impacte les performances.

Exemples

Convertir le volume logique linéaire "vg00/lvol1" en volume logique mirroir:
lvconvert -m1 vg00/lvol1
Convertir le volume logique linéaire "vg00/lvol1" en volume logique RAID1:
lvconvert --type raid1 -m1 vg00/lvol1
Convertir un mirroir avec un log disque en un mirroir avec un log en mémoire:
lvconvert --mirrorlog core vg00/lvol1
Convertir un mirroir avec un log en mémoire en un mirroir avec un log disque:
lvconvert --mirrorlog disk vg00/lvol1
Convertir un volume logique mirroir en un volume logique linéaire:
lvconvert -m0 vg00/lvol1
Convertir un volume logique mirroir en un volume logique RAID1 avec le même nombre d'images:
lvconvert --type raid1 vg00/mirror_lv
Convertir le volume logique "vg00/lvol2" en snapshot du volume original "vg00/lvol1":
lvconvert -s vg00/lvol1 vg00/lvol2
Convertir un volume logique linéaire "vg00/lvol1" en mirroir, en utilisant des extents physiques /dev/sda:0-15 et /dev/sdb:0-15 pour l'allocation des nouveaux extents:
lvconvert -m1 vg00/lvol1 /dev/sda:0-15 /dev/sdb:0-15
Convertir le volume logique mirroir "vg00/lvmirror1" en linéaire, libérant les extents physiques de /dev/sda:
lvconvert -m0 vg00/lvmirror1 /dev/sda
Fusionner "vg00/lvol1_snap" dans son origine:
lvconvert --merge vg00/lvol1_snap
Si "vg00/lvol1", "vg00/lvol2" et "vg00/lvol3" sont tous taggés avec "some_tag" chaque volume logique snapshot sera fusionné en série. Si --background est utilisé il démarre la fusion des snapshots en parallèle:
lvconvert --merge @some_tag
Extrait une image du mirroir, créant un nouveau volume logique "lv_split". Le mirroir d'où l'image est extraite est réduite en accord. S'il y avait un mirroir 2-way (créé avec -m 1), le volume original résultant sera linéaire:
lvconvert --splitmirrors 1 --name lv_split vg00/lvmirror1
Un volume logique créé avec --type raid1 peut utiliser --trackchanges en splittant une image. Détacher une image du lv mirroir lv_raid1 comme périphérique lecture seul et suivre les changements:
lvconvert --splitmirrors 1 --trackchanges vg00/lv_raid1
Fusionner une image qui a été détachée temporairement de son mirroir avec --trackchanges dans son mirroir d'origine:
lvconvert --merge vg00/lv_raid1_rimage_1
Remplacer le volume physique /dev/sdb1 dans le volume logique RAID1 my_raid1 avec le volume physique /dev/sdf1.
lvconvert --replace /dev/sdb1 vg00/my_raid1 /dev/sdf1
Convertis le volume logique vg00/lvpool en un pool thin avec une taille de chunk de 128Kio et convertit vg00/lv1 en volume thin dans ce pool. le lv d'origine est utilisé comme origine externe d'origine, où toutes les écriture vers de tels volumes sont stockés dans le pool:
lvconvert --type thin --thinpool vg00/lvpool -c 128 lv1
Convertis le volume logique vg00/origin en volume thin dans le pool thin vg00/lvpool. Ce volume thin utilisera vg00/origin comme volume d'origine externe pour les zones non-provisionnées dans ce volume. L'origine externe utilise le nouveau nom vg00/external:
lvconvert -T --thinpool vg00/lvpool --originname external vg00/origin
Convertis un volume logique existant en LV pool cache utilisant les métadonnées de cache donnés:
lvconvert --type cache-pool --poolmetadata vg00/lvx_meta vg00/lvx_data
lvrename vg00/lvx_data vg00/lvx_cachepool
Convertis un volume logique existant en un LV cache dans le pool donné et une taille de chunk de 128Kio:
lvconvert --cache --cachepool vg00/lvx_cachepool -c 128 vg00/lvx
Détacher le pool cache d'un volume logique caché vg00/lvol1 existant et laisser le pool cache non-utilisé:
lvconvert --splitcache vg00/lvol1
Supprimer le pool cache d'un volume logique existant vg00/lvol1:
lvconvert --uncache vg00/lvol1
^
15 juin 2016

htmlpdflatexmanmd




lvcreate

lvcreate

Créer un volume logique

   lvcreate créé un nouveau volume logique dans un volume group en allouant des extents logiques dans le pool d'extents physiques disponibles dans ce volume group. S'il n'y a pas suffisamment d'extents physique, le volume group peut être étendu avec d'autres volumes physiques ou en réduisant des volumes logiques existants dans ce volume group. Si un ou plusieurs volumes physiques sont spécifiés, l'allocation d'extents physiques seront restreints à ces volumes. Le secondes forme supporte la création de volumes logiques snapshot qui conservent le contenu du volume logique original.

OPTIONS

-a|--activate [a][e|l|s]{y|n} Contrôle la disponibilité des volumes logiques à utiliser immédiatement après que la commande soit terminées. Par défaut, les nouveaux volumes logiques sont activés (-ay). -an laisse le nouveau volume logique inactif si possible. -aay, l'autoactivation est gérée avec un match dans activation/auto_activation_volume_list dans lvm.conf. -aey active exclusivement sur un nœud et -a{a|l}y active seulement sur le nœud local.
--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-H|--cache Crée un volume logique cache pour pool de cache. avec --extents ou --siwe, créé un volume logique cache. quand le nom du volume group est spécifié avec un volume logique existant qui n'est pas un pool cache, un tel volume est traité comme volume cache origine et un pool cache est créé. Dans ce cas --extents ou --size est utilisé pour spécifier la taille de volume pool cache.
--cachemode {passthrough|writeback|writethrough} Spécifie un mode de cache pour les écriture dans un lv cache. writeback,
--cachepolicy Policy Seulement pour les LV cache. Définis la stratégie de cache. mq est la stratégie de base, smq est plus avancé
--cachepool CachePoolLogicalVolume Spécifie le nom du volume pool cache. L'autre manière de spécifiée le nom du pool est d'ajouter le nom du VG en argument.
--cachesettings Key=Value Seulement pour les LV cache. Définis les paramètres cache.
-c|--chunksize ChunkSize Spécifie la taille de chunk pour les LV snapshot, pool cache et pool thin. Pour les snapshots, doit être une puissance de 2 entre 4Kio (défaut) et 512Kio. Pour les pools cache la valeur doit être un multiple de 32Kio entre 32Kio et 1Gio (défaut: 64Kio). Quand la taille est spécifiée avec le volume caching, elle ne peut pas être inférieur à la taille de chunk du pool cache. Pour les pools thin la valeur doit être un multiple de 64Kio (défaut) et 1Gio. allocation/thin_pool_chunk_size_policy dans lvm.conf sélectionne une stratégie de calcul différent.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-C|--contiguous {y|n} Définis ou redéfinis la stratégie d'alllocation contigüe pour les volumes logiques. Défaut: pas d'allocation contigüe
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--discards {ignore|nopassdown|passdown} Définie le mode d'annulation pour le pool thin. Défaut: passdown.
--errorwhenfull {y|n} Configure le comportement d'un pool thin quand l'espace est remplis. Défaut: no. Le périphérique met ses opérations en queue jusqu'au timeoute. À yes, les opération I/O sont immédiatement mis en erreur.
-l|--extents LogicalExtentsNumber[%{FREE|ORIGIN|PVS|VG} Définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size LogicalVolumeSize Définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, sinon elle est prise comme valeur absolue.
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonnée original.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié
--minor Minor [-j|--major Major] Définis le numéro majeur et mineur. Non supporté avec les volumes pools. Ignoré avec les kernels récents
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
-m|--mirrors Mirrors Créé un LV mirroir avec le nombre de copies spécifiée. avec --nosync, la création du mirroir saut la resynchronisation initiale. Toutes les données après seront mirrorée, mais le contenu original ne le sera pas.
--corelog|--mirrorlog {disk|core|mirrored} --corelog est équivalent à --mirrorlog. Spécifie le type de log à utiliser pour le mode mirror. disk créé une copie persistante des données. core signifie que le mirroir est regénéré en copiant les données du premier périphérique à chaque fois que le volume logique est activé, comme après un reboot. mirrored créé un log persistant qui est lui-même mirroré
--nosync N'effectue pas la resynchro initial à la création du mirroir
-R|--regionsize MirrorLogRegionSize] Un mirroir est divisé en région de la taille spécifiée, et le log mirroir utilise cette granularité pour suivre les régions à synchroniser.
--monitor {y|n} Active le monitoring d'un mirroir, snapshot ou pool thin avec dmeventd si installé. Si un périphérique utilisé par un mirroir monitoré reporte une erreur d'E/S, l'erreur est gérée en accord avec activation/mirror_image_fault_policy et activation/mirror_log_fault_policy dans lvm.conf
-n|--name LogicalVolume Définis le nom du nouveau volume logique
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-p|--permission {r|rw} Définis les permissions d'accès. Défaut: rw
-M|--persistent {y|n} À yes, le numéro mineur est persistant. Les volumes pool ne peuvent pas avoir de numéros mineur et majeur persistants.
--poolmetadatasize MetadataVolumeSize Définis la taille des métadonnées du pool. Entre 2Mio et 16Gio pour les pool thin, jusqu'à 16Gio pour un pool cache. La valeur par défaut pour un thin pool est ((Pool_LV_size / Pool_LV_chunk_size addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo 64b)
--poolmetadataspare {y|n} Contrôle la création et la maintenance de métadonnées de pool spare qui sont utilisés pour la récupération automatique du pool. Un seul volume est maintenu dans un volume group avec la taille des plus grosses métadonnées du pool.
--[raid]maxrecoveryrate Rate Définis le taux de récupération maximum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]minrecoveryrate Rate Définis le taux de récupération minimum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
-r|--readahead {ReadAheadSectors|auto|none} Définis le compteur de secteur read ahead de ce volume logique.
-k|--setactivationskip {y|n} Contrôle si les volumes logiques sont flaggés pour être ignoré à l'activation. --ignoreactivationskip doit être utilisé. Le flag n'est pas appliqué durant la désactivation. Utiliser lvchange --setactivationskil pour changer le flag skip. voir activation/auto_set_activation_skip dans lvm.conf.
-s|--snapshot|-H|--cache {[VolumeGroup/]OriginalLogicalVolume Créé un LV snapshot pour un lv existant, appelé le lv d'origine. Un snapshot thin est créé quand l'origine est un volume thin et la taille n'est pas spécifiée. Un thin snapshot partage les même blocks dans le volume pool thin. Un snapshot de volume non thin avec la taille spécifié n'a pas besoin d'avoir la même quantité de stockage que l'origine, généralement 15-20% est suffisant. Note: une petite quantité d'espace allouée est utilisé pour suivre les emplacements des chunks de donnée. Si --thinpool est spécifié, un volume thin est créé et utilise le volume logique d'origine spécifié comme origine externe qui sert de blocks non-provisionnés. Seul les volumes lecture-seul peuvent être utilisés comme origine externe.
-V|--virtualsize VirtualSize Créé un périphérique provisionné léger ou un périphérique sparse. global/spase_segtype_default dans lvm.conf configure le type de segment sparse par défaut.
-t|--test Lance en mode test
-T|--thin Créé un pool thin ou un lv thin ou les 2. Avec --size et --extents, créé un lv pool thin. Avec --virtualsize, créé un lv thin dans le pool donné. Avec les 3 arguments, créé un pool thin et un lv utilisant ce pool.
--thinpool ThinPoolLogicalVolume Nom du volume pool thin.
--type SegmentType Créé un volume logique avec le type de segment spécifié. ( cache, cache-pool, error, linear, mirror, raid1, raid4, raid5_la, raid5_ls (= raid5), raid5_ra, raid5_rs, raid6_nc, raid6_nr, raid6_zr (= raid6), raid10, snapshot, striped, thin, thin-pool ou zero). Défaut: linear.
-v|--verbose Mode verbeux
-W|--wipesignatures {y|n} Contrôle l'effacement des signatures détectées dans le nouveau LV. Si cette option n'est pas spécifiée, la signature est remplie de 0 avec -Z. Peut être contrôlé avec allocation/wipe_signatures_when_zeroing_new_lvs dans lvm.conf. Si l'effacement blkid est utilisé allocation/use/blkid_wiping doit être définis. Les lv lecture seul ne sont pas effacés
-Z|--zero {y|n}] Remplis de 0 les 4Kio de données du début du lv. Défaut: yes. Les lv lecture seul ne sont pas effacés.

Exemples

Créer un lv striped avec 3 stripes, une taille de stripe de 8Kio et une taille de 100Mio dans le VG vg00
lvcreate -i 3 -I 8 -L 100M vg00
Créer un lv mirroir avec 1 copie et une taille de 500Mio utilisable
lvcreate -m1 --mirrorlog core -L 500M vg00
Créer un lv snapshot vg00/snap qui a accès au contenu de vg00/lvol1 à la date de création du snapshot. Si le lv d'origine contient un système de fichier, on peut monter le snapshot dans un répertoire arbitraire pour accéder au contenu du système de fichier pour lancer une sauvegarde tout en mettant à jours le système de fichier original
lvcreate --size 100m --snapshot --name snap /dev/vg00/lvol1
Créer un lv snapshot vg00/snap avec une taille de 20% du lv d'origine
lvcreate -s -l 20%ORIGIN --name snap vg00/lvol1
Créer un périphérique sparse nommé /dev/vg1/sparse de 1Tio avec un espace de 100Mio de données actuelles
lvcreate --virtualsize 1T --size 100M --snapshot --name sparse vg1
Créer un lv linéaire vg00/lvol1 utilisant les extents physiques /dev/sda:0-7 et /dev/sdb:0-7 pour l'allocation des extents
lvcreate -L 64M -n lvol1 vg00 /dev/sda:0-7 /dev/sdb:0-7
Créer un lv Raid5 5Gio vg00/my_lv avec 3 stripes (plus un disque de parité) et une taille de stripe de 64Kio
lvcreate --type raid5 -L 5G -i 3 -I 64 -n my_lv vg00
Créer un lv RAID5 vg00/my_lv, utilisant tout l'espace disque dans le VG et répartis sur tous les PV dans le VG
lvcreate --type raid5 -l 100%FREE -n my_lv vg00
Créer un RAID10 de 5Gio vg00/my_lv avec 2 stripes dans 2 mirroirs. Noter que les arguments -i et -m fonctionnent différemment:
lvcreate --type raid10 -L 5G -i 2 -m 1 -n my_lv vg00
Créé un lv pool de 100Mio pour du provisionning léger avec 2 stripes de 64Kio et un taille de chunk de 2156Kio avec un volume de 1Tio
lvcreate -i 2 -I 64 -c 256 -L100M -T vg00/pool -V 1T --name thin_lv
Créé un lv snapshot thin "thinsnap" du volume thin "thinvol" qui partagent les même blocks dans le pool thin. Noter que la taille ne doit pas être spécfiée sinon un snapshot non-thin est créé:
lvcreate -s vg00/thinvol --name thinsnap
Créer un volume snapshot thin d'un volume lecture seule inactif "origin" qui devient ensuite l'origine externe pour ce snapshot
lvcreate -s --thinpool vg00/pool origin
Créer un lv pool cache qui peut être utilisé pour cacher un volume logique
lvcreate --type cache-pool -L 1G -n my_lv_cachepool vg /dev/fast1
S'il y a un lv pool cache exsistant, créer un grand périphérique lent (le lv origine) et le lier au lv pool cache, créant un lv cache
lvcreate --cache -L 100G -n my_lv vg/my_lv_cachepool /dev/slow1
S'il y a un lv existant, créer le lv pool cache et le lier avec ce lv, créant un lv cache
lvcreate --type cache -L 1G -n my_lv_cachepool vg/my_lv /dev/fast1
^
24 mai 2016

htmlpdflatexmanmd




lvdisplay

lvdisplay

Affiche les attributs des volumes logiques

   lvdisplay permet de voir les attributs d'un volume logique. lvs est une alternative qui fournis les même informations dans le style ps.

OPTIONS

-a|--all Inclus les informations sur les volumes logiques interne tels que les mirroirs
-c|--colon Affiche la sortie en colonne.
--commandprofile ProfileName -d|--debug
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--maps Affiche le mappage les extents logiques aux volumes physiques et aux extents physiques Pour mapper les extents physiques aux extents logique utiliser: pvs --segments -o +lv_name,seg_start_pe,segtype
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-v|--verbose Mode verbeux
-C|--columns Sortie séparée par des ':'
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field1[,Field2...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. lv_all sélectionne toutes les colonnes de volume logiques, et lvseg_all sélectionne toutes les colonnes de segment de volume logique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes

Exemples

Afficher les attributs d'un volume logique
lvdisplay -v vg00/lvol2
Afficher les attributs d'un snaphot et le lv d'origine:
lvdisplay vg00/snapshot
^
24 mai 2016

htmlpdflatexmanmd




lvextend

lvextend

Étend la taille d'un volume logique

   lvextend permet d'étendre la taille d'un volume logique. Les extensions de lv snapshot sont également supportés. Mais pour changer le nombre de copies dans un volume logique mirroré, utiliser lvconvert.

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande
-f|--force Ne demande pas confirmation
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonné originel.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-l|--extents [+]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN} Étend ou définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size [+]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Étend ou définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, sinon elle est prise comme valeur absolue.
-n|--nofsck N'effectue pas de fsck avant d'étendre le système de fichier qu'en c'est nécessaire.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-r|--resizefs Redimensionne le système de fichier en même temps que le volume logique en utilisant fsadm
--use-policies Redimensionne le volume logique en accord avec la stratégie
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Étend la taille du volume logique "vg01/lvol10" de 54MiO dans le volume physique /dev/sdk3. C'est seulement possible si /dev/sdk3 est un membre du volume groupe vg01 et qu'il y a suffisamment d'extents physique:
lvextend -L +54 /dev/vg01/lvol10 /dev/sdk3
Étend la taille du volume logique "vg01/lvol01" par la quantité totales dans le volume physique /dev/sdk3. C'est équivalent à spécifier "-l +100%PVS" sur la ligne de commande:
lvextend /dev/vg01/lvol01 /dev/sdk3
Étends un volume logique "vg01/lvol01" de 16Mio en utilisant les extents physiques /dev/sda:8-9 et /dev/sdb:8-9 pour allouer les extents:
lvextend -L+16M vg01/lvol01 /dev/sda:8-9 /dev/sdb:8-9
^
22 mai 2016

htmlpdflatexmanmd




lvm

lvm

Outils lvm2

   lvm fournis les outils en ligne de commande pour LVM2. Si lvm est invoqué sans arguments, affiche un prompt. Les commandes LVM peuvent être entrées directement.

   Si lvm est invoqué avec argv[0] définis au nom d'une commande spécifique, il agit comme cette commande

   À l'invocation, lvm nécessite seulement que les descripteurs de fichier stdin, stdout et stderr soient disponible. Si d'autres sont trouvés, ils sont fermés et des messages l'alerte sont émis.

   Là où les commandes prennent des noms VG ou LV en argument, le chemin complet est optionnel. Un LV appelé lvol0 dans un VG appelé vg0 peuvent être spécifiés sous la forme vg0/lvol0. Quand une liste de VG est requise mais laissée vide, une liste de tous les VG sera substituée. Quand une liste de LV est requise main un VG est donné, une liste de tous les LV dans ce VG est subsitué.

   Un avantage d'utiliser le shell intégré est que les informations de configuration sont mis en cache en interne entre les commandes.

   Un fichier contenant un simple script avec une commande par ligne peut également être donné sur la ligne de commande. Le script peut également être exécuté directement si la première ligne est #! suivie par le chemin de lvm.

Commandes intégrées

   Les commandes suivantes sont intégrées dans lvm sans liens créés dans le système de fichier.

config =lvmconfig
devtypes Affiche les types de périphériques block intégrés reconnus
formats Affiche les formats de métadonnées reconnus
help Affiche l'aide
lvpoll Opérations lvmpolld complet
pvdata Non encore implémenté
segtypes Affiche les types de segments LVM reconnus
systemid Affiche tout system ID actuellement définis dans cet hôte
tags Affiche tous les tags définis dans cet hôte
version Affiche la version

Commandes

   Les commandes suivantes implémentent les fonctionnalité de cœur de LVM

pvchange Change les attributs d'un volume physique
pvck Vérifie les métadonnées d'un volume physique
pvcreate Initialise un disque ou une partition à utiliser par LVM
pvdisplay Affiche les attributs d'un volume physique
pvmove Déplace les extents physiques
pvremove Supprime un volume physique
pvresize Redimensionne un disque ou une partition utilisé par lvm
pvs Affiche des informations sur les volumes physique
pvscan Scanne tous les disques pour les volumes physique
vgcfgbackup Sauvegarde la zone de descripteur de volume group
vgcfgrestore Restaure la zone de descripteur de volume group
vgchange Change les attributs d'un volume group
vgck Vérifie les métadonnées d'un volume group
vgconvert convertis le format de métadonnées d'un volume group
vgcreate Créé un volume group
vgdisplay Affiche les attributs d'un volume group
vgextend Ajoute des volumes physiques à un volume group
vgimport rend les volumes group exportés connus du système
vgimportclone Importe et renomme des volume group dupliqués
vgmerge Fusionne 2 volumes group
vgmknodes Recréé un répertoire de Volume Group et les fichier spéciaux de volume logique
vgreduce Réduit un volume group en supprimant un ou plusieurs volumes physique
vgremove Supprime un volume group
vgrename Renomme un volume group
vgs Affiche des informations sur les volume group
vgscan Scanne tous les disques pour les volumes group et reconstruit les caches
vgsplit Split un volume group en 2, en déplaçant les volumes logiques d'un volume group vers un autre en déplaçant tous les volumes physiques
lvchange Change les attributs d'un volume logique
lvconvert Convertis un volume logique d'un linéaire vers un mirror ou un snapshot
lvcreate Créé un volume logique dans un volume group existant
lvdisplay Affiche les attributs d'un volume logique
lvextend Étend la taille d'un volume logique
lvmchange Change les attributs de LVM
lvmconfig Affiche les informations de configuration après avoir chargé lvm.conf et autres fichiers de configuration
lvmdiskscan Scanne tous les périphériques visible pour LVM2
lvmdump Créé des dump d'informations lvm2 pour diagnostique
lvreduce Réduit la taille d'un volume logique
lvremove Supprime un volume logique
lvrename renomme un volume logique
lvresize Redimensionne un volume logique
lvs Affiche des informations sur les volumes logique
lvscan Scanne tous les disque pour les volumes logique

   Les commande suivantes ne sont pas encore implémentées mais le seront dans le future: lvmadc, lvmsar, pvdata.

OPTIONS

   Les options suivantes sont disponible pour de nombreuses commandes. Elles sont implémentées de manière générique et documentés ici au lieu des man individuels

-v, --verbose mode verbeux
-d, --debug définis le niveau de débug, de 1 à 6 fois pour augmenter les détails.
-q, --quiet Supprime la sortie et les messages de log. Supprime également tout prompt et répond automatiquement no
--yes Par de prompt et répond toujours yes
-t, --test Lance en mode test. Les commandes ne mettent pas à jours les métadonnées.
--driverloaded {y|n} à n, ne tente pas de contacter le pilote device-mapper du kernel
-A, --autobackup {y|n} Backup automatiquement les métadonnées après un changement.
-P, --partial Définis, les outils fond de leur mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement. Quand un partie d'un volume logique est manquant, /dev/ioerror est substitué, et dmsetup peut être utilisé pour retourner les erreurs I/O.
-S, --select ‹selection› Pour les commandes de rapport, affiche seulement les lignes qui matchent le critère donné.
-M, --metadatatype Type$ Spécifie quel type de métadonnée utiliser, tel que lvm1 ou lvm2.
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule tel que lvchange -ay et vgchange -ay même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et certains vg clusterisés doivent être ignorés.
--readonly Lance la commande en mode spécial lecture seul qui lit les métadonnées sur disque sans nécessiter de créer un lock.
--foreign Force la commande à accéder aux volumes groupe exterieur. PEut être utilisé pour reporter ou afficher un VG qui est possédé par un autre hôte. Les performances peuvent être très réduite parce que le cache lvmetad n'est pas utilisé
--shared Accède à un volume group partagé, qui serait ignoré quand lvmlockd n'est pas utilisé.
--addtag tag Ajoute le tag spécifié à un PV, VG ou LV. Peut être spécifié plusieurs fois. Les tags peuvent être donné sur la ligne de commande à la place des arguments PV, VG, ou LV.
--deltag tag Supprime le tag spécifié
--alloc {anywhere|contiguous|cling|inherit|normal} Sélectionne la stratégie d'allocation quand une commande doit allouer des Extents physiques depuis le Volume Group. Chaque Volume Group et Logical Volume a une stratégie d'allocation définie. Défaut pour VG: normal, LV: inherit

        normal Applique des règles de sens commun qui ne place pas les stripes parallèles dans le même volume physique.
        inherit applique la même stratégie que le VG
        contiguous Nécessite que les nouveaux extents soient placé adjacent aux extents physique existant
        cling Place le nouvel extent physique sur le même volume physique que les extents physique dans le même stripe du volume logique

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser en traitant une commande LVM.
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser en traitant une commande LVM.
--profile ProfileName idem à --metadataprofile pour vgcreate, lvcreate, vgchange et lvchange, et --commandprofile pour les autres commandes.
--config ConfigString Configuration à utiliser

Allocation

   Quand une opération doit allouer des Extents physique pour un ou plusieurs volumes physique, les outils traitent comme suit:

   Tout d'abord, ils génèrent le jeu complet d'Extents Physique non-alloués dans le Volume Group. Si une plage d'Extents sont fournis à la fin de la ligne de commande, seul les Extents physique non-alloués dans cette plage dans les volumes physique spécifiés sont considérés.

   Ensuite, ils tentent chaque stratégie d'allocation en retour, en commençant la stratégie la plus stricte (contiguous) et se termine avec la stratégie spécifiée avec --alloc ou la valeur par défaut. Pour chaque stratégie, en commençant depuis l'Extent logique avec le numéro le plus faible de l'espace du volume logique vide qui doit être remplis, ils allouent autant d'espace que possible en accord avec les restrictions imposées par la stratégie. Si plus d'espace est nécessaire, ils utilise la stratégie suivante.

   Les restrictions sont les suivantes:

   Contiguous nécessite que l'emplacement physique d'un extent logique qui n'est pas le premier extent logique d'un volume logique soit adjacent à l'emplacement physique de l'extent logique le précédent immédiatement.

   Quand un volume logique est stripé ou mirroré, les restrictions ci-dessus sont appliquées indépendamment à chaque stripe ou image mirroir qui nécessite de l'espace.

   Normal ne choisit pas un Extent Physique qui partage le même volume physique comme Extent Logique déjà alloué à un volume logique parallèle (ex: un striped ou une image mirroir différente) au même offset dans ce volume logique parallèle.

Types de volume logique

   Certains types de volumes logiques sont simple à créer et peut être fait avec une simple commande lvcreate. Les types de volume logique linear et striped en sont un exemple. D'autre types de volume logique peuvent nécessiter plus d'une commande pour les créer, comme les types cache et thin provisioning.

Critères de Sélection

   Les critères de sélection sont un jeu de déclaration combinés par des opérateurs logique et de groupement. La déclaration consiste de nom de colonne pour lequel un jeu de valeurs valides est définis en utilisant des opérateurs de comparaison. Pour une liste complète de noms de colonne qui peuvent être utilisé dans la sélection, voir la sortie de ‹commande lvm› -S help

Opérateurs de comparaison (cmp_op)

=~ Matche l'expression régulière
!~ ne match pas l'expression régulière
= égal à
!= Non égal à
›= Supérieur ou égal à
Supérieur à
‹= Inférieur ou égal à
Inférieur à

Opérateurs logiques binaire (cmp_log)

&& Tous les champs doivent matcher
, Idem
|| Au moins un champs doit matcher
# idem

Opérateurs logique unaire

! Négation

Opérateurs de groupement

() parenthèses
[] Liste
{} Sous-jeu de liste

Spécification de grammaire informelle

   STATEMENT = column cmp_op VALUE | STATEMENT log_op STATEMENT | (STATEMENT) | !(STATEMENT)

Variables d'environnement

HOME Répertoire contenant .lvm_history si le shell readline interne est invoqué
LVM_COMAND_PROFILE Nom du profile de commande par défaut à utiliser pour les commandes LVM.
LVM_SYSTEM_DIR Répertoire contenant lvm.conf. Défaut: /etc/lvm
LVM_SUPPRESS_FD_WARNINGS Supprime les alertes sur les descripteurs de fichier inattendus passés à lvm
LVM_VG_NAME Nom deu volume group qui est assumé pour toute référence à un volume logique qui ne spécifie pas de chemin.
LVM_LVMETAD_PIDFILE Nom du volume group qui stocke l'ID du process lvmetad
LVM_LVMETAD_SOCKET Chemin du socket utilisé pour communiquer avec lvmetad
LVM_LVMPOLLD_PIDFILE Chemin du fichier qui stocke l'ID du processus lvmpolld
LVM_LVMPOLLD_SOCKET Chemin du socket utilisé pour communiquer avec lvmpolld
LVM_LOG_FILE_EPOCH Chaîne jusqu'à 32 lettre à ajouter au nom du fichier de log et suivi par l'ID du processus et un horodatage. Si définis, chaque processus log dans un fichier séparé
LVM_EXPECTED_EXIT_STATUS Le status anticipé quand le processus quitte. Utiliser "›N" pour matcher un status supérieur à N
LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES Utilisé pour supprimer les messages d'alerte quand le lock configuré est indisponible
DM_ABORT_ON_INTERNAL_ERRORS Annule le traitement si le code détecte une erreur interne non-fatal
DM_DISABLE_UDEV Évite l'interaction avec udev. LVM va gérer les nœud dans /dev directement
^
23 mai 2016

htmlpdflatexmanmd




lvm-config

lvm-config, lvm-dumpconfig

Afficher la configuration LVM

   lvmconfig produit une sortie formattée de la configuration LVM. La comme a une forme identique à lvm dumpconfig

OPTIONS

-f, --file Envoie la sortie dans le fichier spécifié
-l, --list Liste les paramètres de configuration avec commentaire. Identique à lvmconfig --type list --withsummary
--type {current|default|diff|full|missing|new|profilable|profilable-command|profilable-metadata} Sélectionne le type de configuration à afficher.

        current Affiche la configuration lvm.conf courante
        default Affiche les paramètres de configuration assignés avec les valeurs par défaut
        diff Affiche tous les paramètres de configuration pour lesquels les valeurs diffèrent de la valeur par défaut
        full Affiche toute l'arborescence de configuration.
        list Affiche une liste des paramètres de configuration
        missing Affiche tous les paramètres de configuration avec des valeurs par défaut qui sont manquant dans la configuration courante
        new Affiche tous les nouveaux paramètres de configuration introduit par la version courante de LVM (ou spécifiée avec --atversion)
        profilable Affiche tous les paramètres de configuration profilable avec des valeurs par défaut.
        profilable-command Affiche tous les paramètres de configuration profilable avec les valeurs assignées qui peuvent être utilisés dans les profile de commande
        profilable-metadata Affiche tous les paramètres de configuration profilable avec les valeurs assignées qui peuvent être utilisés dans les profile de métadonnées

--atversion Spécifie une version LVM au format x.y.z. Pour limiter l'affichage des paramètres
--sinceversion Idem, applicable seulement avec --type new
--ignoreadvanced Exclus les paramètres de configuration avancés
--ignoreunsupported Exclus les paramètres de configuration non-supportés
--ignorelocal Ignore la section local
--config Utilise la chaîne spécifiée pour remplacer la configuration existante
--commandprofile Utilise le profile spécifié pour remplacer la configuration existante
--profile Identique à --commandprofile mais la configuration n'est pas appliquée pour la commande lvmconfig
--metadataprofile Spécifie le profile pour remplacer la configuration existante
--mergedconfig Quand la commande lvmconfig est lancée avec --config option et/ou --commandprofile (ou avec la variable d'environnement LVM_COMMAND_PROFILE), --profile, --metadataprofile, fusionne tout le contenu de la configuration avant de l'afficher
--showdeprecated Inclus les paramètres de configuration dépréciée dans la sortie
--showunsupported Inclus les paramètres de configuration non-supportés
--validate Valide la configuration courante utilisée et quitte avec un code de sortie approprié
--withsummary Affiche une ligne de commantaire pour chaque nœud de configuration
withcomments Affiche un commentaire complet pour chaque nœud de configuration.
--withspaces Quand approprié, ajoute plus d'espace dans la sortie pour une meilleur lisibilité
--withversions Affiche également un commentaire contenant la version d'introduction pour chaque nœud de configuration.
^
22 mai 2016

htmlpdflatexmanmd




lvm.conf

lvm.conf

Fichier de configuration pour LVM2

   lvm.conf est chargé durant l'initialisation de lvm. Ce fichier peut en retour charger d'autres fichiers.

   Les paramètres définis dans lvm.conf peuvent être remplacés par une des méthodes de configuration étendues suivantes:

   - Configuration spécifiée sur la ligne de commande en utilisant --config.

   Un profile est un jeu de paramètres de configuration personnalisable sélectionné. Il y a 2 groupes de profile: les profiles de commande et les profiles de métadonnées.

   - Le profile de commande est utilisé pour écraser les paramètres de configuration au niveau de la commande lvm globale. Il est appliqué au début de l'exécution de la commande lvm et est utilisé tout le temps de l'exécution de la commande. Le profile de commande est appliqué avec --commandprofile.

   - Le profile de métadonnées est utilisé pour écraser les paramètres de configuration au niveau Volume Group/Logical Volume. Il est appliqué indépendamment pour chaque VG/LV qui est traité. Ainsi, chaque VG/LV peut stocker le nom de profile utilisé dans ses métadonnées pour que le profile s'applique automatiquement quand ce VG/LV est traité. Le profile de métadonnée peut être spécifié avec --metadataprofile et --detachprofile. les commande de reporting fournissent -o vg_profile et -o lv_profile pour affiche le profile de métadonnées actuellement attachés au VG/LV.

   Le jeu d'options permis pour les profiles de commande est mutuellement exclusif quand il est comparé avec le jeu d'options permis pour les profiles de métadonnées. Les paramètres qui appartiennent aux 2 set ne peuvent être mixés ensemble et les outils LVM vont rejeter de tels profiles.

   LVM lui-même fournis quelques profiles de configuration prédéfinis. Les utilisateurs sont autorisés à ajouter plus de profile avec différentes valeurs si nécessaire. Dans ce but, il y a la commande profile_template.profile (pour les profiles de commande) et metadata_profile_template.profile (pour les profiles de métadonnées) qui contient tous les paramètres qui sont personnalisable par profiles d'un certain type. Les utilisateurs sont encouragés à copier ces templates et de les éditer si nécessaire. Alternativement, lvmconfig --file ‹profilename› --type profilable-commande ‹section› ou lvmconfig --file ‹profilename› --type profilable-metadata ‹section› peuvent être utilisé pour générer une configuration avec des paramètres profilables dans un des type pour la section donné et de les sauver dans le nouveau profile. Si la section n'est pas spécifiée, tous les paramètres profilables sont reportés.

   Les profiles sont stockés dans /etc/lvm/profile par défaut. Cet emplacement peut être changé en utilisant le paramètres config/profile_dir. Chaque configuration de profile est stocké dans un fichier ProfileName.profie dans le répertoire de profile.

   Quand plusieurs méthodes de configuration sont utilisés en même temps et que lvm recherche la valeur d'un paramètre particulier, il traverse la configuration en cascade de gauche à droite:

   Ligne de commande -› profile de commande -› profile de métadonnées -› config de tag -› lvmlocal.conf -› lvm.conf

   S'il n'y a pas de paramètre trouvé à la fin de la cascade, une valeur par défaut est utilisée pour ce paramètre. Utiliser lvmconfig pour vérifier les paramètres utilisés et leur valeurs par défaut.

Syntaxe

   Les espaces blancs ne sont pas significatif sauf dans dans les guillemets. Grammaire informelle:

file = value* Un fichier de configuration consiste d'un jeu de valeurs
value = section | assignment Une valeur peut être soit une nouvelle secion, ou un assignement
section = identifier '{' value* '}' Une section regroupe des valeurs associées ensemble. Si la même section est rencontrée plusieurs fois, le contenus de toutes les instances sont concaténés ensemble dans l'ordre où elles apparaissent. Elle est dénotée par un nom et délimitée par des {}
assignment = identifier '=' ( array | type ) Un assignement associe un type avec un identifiant. Si l'identifiant contient des barres obliques, ils sont interprétés comme délimiteur de chemin. La déclaration section/key = value est équivalente à section { key = value }. Si plusieurs instances de la même clé est rencontrée, seule la dernière valeur est utilisé (et une alerte est émise).
array = '[' ( type ',')* type ']' | '[' ']' les tableaux non-homogènes sont supportés. Un tableau vide est acceptable
type = integer | float | string integer = [0-9]* ; float = [0-9]*'.'[0-9]* ; string = '"'.*'"'

Paramètres

   La commande lvmconfig affiche les paramètres de configuration LVM dans divers formats.

Affiche une liste de tous les paramètres de configuration possible, avec leur valeurs par défaut.
lvmconfig --type default
Idem, avec commantaires:
lvmconfig --type default --withcomments
idem avec les valeurs courantes:
lvmconfig --type current
Affiche tous les paramètres configurés avec une valeur différente du défaut:
lvmconfig --type diff
Affiche un simple paramètre avec sa valeur par défaut, description, où Section réfère à la section de configuration:
lvmconfig --type default --withcomments Section/Setting
^
23 mai 2016

htmlpdflatexmanmd




^
22 mai 2016

htmlpdflatexmanmd




lvmcache

lvmcache

Cache LVM

   Le type de volume logique cache utilise un LV petit et rapide pour améliorer les performances d'un LV grand et lent. Il stocke les blocks fréquemment utilisé dans le LV rapide. Il est appelé le pool cache, et le grand LV est appelé l'origine. À cause des requis de dm-cache (le pilote kernel), lvm split le LV pool dans 2 périphériques - le LV de données de cache et LV de métadonnées de cache. Le LV de données de cache contient les blocks de données copiées. Le LV de métadonnées de cache maintient les informations d'audit qui spécifie où les blocks sont stockés. Les utilisateurs devraient être familiarisés avec ces LV s'ils souhaitent créer le meilleur LV caché possible Tous les LV associés doivent être dans le même VG

Utilisation du cache

   La méthode principale pour utiliser un LV de type cache:

0. créer OriginLV

Créé un LV ou identifie un LV origine existant
lvcreate -n OriginLV -L LargeSize VG SlowPVs
Exemple:
lvcreate -n lvol0 -L 100G vg

1. créer CacheDataLV

1. créer CacheDataLV
Créé le LV de métadonnées de cache. Ce LV maintient les blocks depuis OriginLV. La taille de ce LV est la taille du cache. Exemple:
lvcreate -n Cache0meta -L 12M vg /dev/fast

2. créer CachePoolLV

Combine les 2 LV en un LV pool.
lvconvert --type cache-pool --poolmetadata vg/cache0meta vg/cache0

3. Créer CacheLV

Créé un LV cache en liant le LV pool au LV origine.
lvconvert --type cache --cachepool vg/cache0 vg/lvol0

Suppression du cache

Un LV pool peut être déconnecté d'un LV Cache, laissant un LV pool inutilisé, et un LV origine sans cache:
lvconvert --splitcache vg/cache0
Supprimer un LV pool sant supprimer sont LV origine lié:
lvremove vg/CachePoolLV
Une commande alternative déconnecte également le pool du cache, et supprime le pool:
lvconvert --uncache vg/cacheLV
Supprimer un LV cache supprime le LV origine et le LV pool lié
lvremove vg/CacheLV

Tolérance d'erreurs dans un LV pool.

0. Créer un LV origine:
lvcreate -L 10G -n lv1 vg /dev/slow_devs
1. Créer un cache LV data RAID1:
lvcreate --type raid1 -m 1 -L 1G -n cache1 vg /dev/fast1 /dev/fast2
2. Créer un cache LV métadonnée RAID1:
lvcreate --type raid1 -m 1 -L 8M -n cache1meta vg /dev/fast1 /dev/fast2
3. Créer un LV pool combinant le LV data et le LV metadata:
lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1
4. Créer un LV cache en combinant le LV pool et le LV origine
lvconvert --type cache --cachepool vg/cache1 vg/lv1

Mode de cache

   Le mode de cache par défaut est "writethrough". Ce mode s'assure que toute donnée écrite sera stocké dans le pool et dans l'origine. La perte d'un périphérique associé avec le pool dans ce cas ne signifie pas la perte d'une donnée.

   Un autre mode de cache, "writeback" retarde l'écriture des blocks de données du pool dans l'origine. Ce mode augmente les performances, mais la perte d'un périphériques du pool peut résulter de pertes de données.

   Avec l'options --cachemode, le mode peut être définis en créant un cache, ou changé sur un cache existant.

Exemples

Créer un LV origin:
lvcreate -L 10G -n lv1 vg /dev/slow
Créer un cache LV data:
vcreate -L 1G -n cache1 vg /dev/fast
Créer un cache LV metadata
lvcreate -L 8M -n cache1meta vg /dev/fast
Créer un cache LV pool
lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1
Créer le cache:
lvconvert --type cache --cachepool vg/cache1 --cachemode writethrough vg/lv1

Stratégie de cache

   Le sous-système de cache a des paramètres additionnels par LV: la stratégie de cache à utiliser. 3 stratégie sont actuellement disponible: smq est la stratégie par défaut, m. est une ancienne implémentation, et cleaner est utilisé pour forcer le cache à vider toutes les écritures en cache sur l'origin

   La stratégie mq a des paramètres. Les défaut sont choisis pour être convenable pour la majorité des systèmes, mais dans des circonstances spéciales, changer ces paramètres peuvent améliorer les performances.

   Avec les options --cachepolicy et --cachesettings, la stratégie de cache et les paramètres peuvent être définis en créant un cache, ou changé dans un cache existant.

Exemple

Changer la stratégie d'un cache existant:
lvchange --cachepolicy mq --cachesettings 'migration_threshold=2048 random_threshold=4' vg/lv1
Dans lvm.conf:
allocation/cache_policy
allocation/cache_settings

Taille de chunk

   La taille de blocks de données gérés par un pool peut être spécifié avec l'option --chunksize à la création. La valeur doit être un multiple de 32KiO entre 32KiO et 1GiO.

   Utiliser une taille de chunk qui est trop grande réduit l'utilité du cache. Cependant, une taille trop petite surcharge le travail de gestion des chunks qui sont mappés dans le cache.

Pour afficher la taille de chunk du cache:
lvs -o+chunksize VG/CacheLV
Dans lvm.conf:
cache_pool_chunk_size
Pour connaître la valeur par défaut:
lvmconfig --type default allocation/cache_pool_chunk_size

Automatic pool metadata LV

   Un LV data peut être convertit au LV pool sans spécifier de LV métadonnée. LVM va automatiquement créer un LV métadonnées depuis le même VG.

Créer un nouveau cache sans un LV origine existant

Un LV cache peut être créé en utilisant un pool sans un LV origine existant. Un nouveau LV origin est créé et lié au pool en une étape
lvcreate --type cache -L LargeSize -n CacheLV --cachepool VG/CachePoolLV VG SlowPVs

Création de LV pool en une seule étape

Un LV pool peut être créé en une seule commande, au lieu d'utiliser lvconvert sur des LV existant:
lvcreate --type cache-pool -L CacheSize -n CachePoolLV VG FastPVs

Convertir des LV existant en type cache

Quand un LV origine existant est convertis en LV cache, le pool spécifié peut être un LV normal, au lieu d'un LV pool. Dans ce cas, lvm convertis le LV normal en cache. Un LV metadata peut optionnellement être spécifié.
lvcreate -n OriginLV -L LargeSize VG
lvcreate -n CacheDataLV -L CacheSize VG
lvconvert --type cache --cachepool VG/CataDataLV VG/OriginLV
C'est équivalent à
lvcreate -n OriginLV -L LargeSize VG
lvcreate -n CacheDataLV -L CacheSize VG
lvconvert --type cache-pool VG/CacheDataLV
lvconvert --type cache --cachepool VG/CachePoolLV VG/OriginLV
^
23 mai 2016

htmlpdflatexmanmd




lvmconf

lvmconf

Modifier la configuration LVM

   lvmconf est un script qui modifie la configuration dans un fichier de configuration lvm. De plus, il peut également définir le service systemd ou SysVinit en accord avec les changements dans la configuration lvm si nécessaire.

OPTIONS

--disable-cluster Définis locking_type au type par défaut non-clusterisé. reset également lvmetad à son défaut.
--enable-cluster Définis locking_type au type par défaut clusterisé dans ce système. Désactive également l'utilisation de lvmetad vu qu'il ne supporte pas les environnements clusterisés
--enable-halvm Définis locking_type utilisable pour l'utilisation LVM HA. Désactive également lvmetad vu qu'il ne supporte pas les environnements LVM HA.
--disable-halvm Définis locking_type au type par défaut non-clusterisé. reset également lvmetad à son défaut.
--file ‹configfile› Applique les changements dans le fichier spécifié. Défaut: /etc/lvm/lvm.conf
--lockinglib ‹lib›, --lockinglibdir ‹dir› Définis la librairie de locking à charger si un type de locking externe est utilisé
--services En plus de définir la configuration, active/désactive les services clvmd et lvmetad. Ce script ne configure pas les services fournis par les agents de ressource cluster.
--mirrorservice Active/désactive également le service optionnel cmirrord en manipulant les services (applicable seulement avec --services)
--startstopservices démarre/stoppe immédiatement les services (applicable seulement avec --services)
^
16 juin 2016

htmlpdflatexmanmd




lvmdbusd

lvmdbusd

Service qui fournis une API D-Bus à LVM

OPTIONS

--debug Mode debug
--udev Utilise les événements udev pour déclencher les mises à jours
^
23 mai 2016

htmlpdflatexmanmd




lvmdiskscan

lvmdiskscan

Scanne les périphériques LVM2 visibles

   lvmdiskscan recherche tous les disques SCSI, (E)IDE, md et d'autres types de périphériques block dans le système à la recherche de volumes physiques LVM. La taille reportée est la taille du périphérique réel. Définir un filtre dans lvm.conf pour restreindre le scan pour éviter un CDROM par exemple.

OPTIONS

-l, --lvmpartition Reporte uniquement les volumes physiques
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




lvmdump

lvmdump

Créé des dumps d'information lvm2 pour diagnostique

   lvmdump est un outil pour dumper diverses informations sur lvm2. Par défaut, il créé un tarball. Le contenu est le suivant:

- Informations dmsetup
- Table de processus en cours d'exécution
- Entrées récentes dans /var/log/messages
- Configuration lvm complète et cache
- Liste les nœuds présents sous /dev
- Liste des fichiers présent dans /sys/block
- Liste des fichiers présent dans /sys/devices/virtual/block
- (-m) dump des métadonnées
- (-a) Sortie debug de vgscan pvscan et liste tous les pv, vg et lv disponibles
- (-c) information du status de cluster
- (-l) État lvmetad
- (-p) État lvmpolld
- (-s) informations et contexte système
- (-u) informations et contexte udev

OPTIONS

-a Informations avancée. Si lvm est blocké, ce script peut blocker également.
-c si clvmd est en cours de fonctionnement, récupère les informations de cluster également
-d dir Dump dans un répertoire au lieu d'un tar.
-l Inclus l'état lvmetad
-m Collecte les métadonnées
-p Inclus l'état lvmpolld
-s informations et contexte système
-u informations et contexte udev

Variables d'environnement

LVM_BINARY Le binaire LVM2 à utiliser. Défaut: lvm
DMSETUP_BINARY binaire dmsetup à utiliser. Défaut: dmsetup
^
23 mai 2016

htmlpdflatexmanmd




lvmetad

lvmetad

Service de cache de métadonnées lvm

   Le service met en cache les métadonnées pour que les commandes lvm puissent les lire sans scanner les disques. Le cache peut être un avantage parce que scanner les disques consomme du temps et peut interférer avec le fonctionnement du système et des disques.

   lvmetad ne lit pas les métadonnées depuis le disque lui-même. la commande pvscan --cache scanne les disque, lit les métadonnées et les envoie à lvmetad.

   Les nouveaux disques LVM qui apparaîssent dans le système doivent être scannés par pvscan avant que lvmetad les connaisse. Si lvmetad ne connaît pas les disques, les commandes lvm utilisant lvmetad ne les connaissent pas. Quand des disques sont ajoutés ou supprimés du système, lvmetad doit être mis à jours.

   lvmetad est généralement combiné avec des services basés sur les événements qui lancent automatiquement pvscan -- cache sur les nouveaux disques. De cette manière, le cache lvmetad est automatiquement mis à jours. Les règle udev lvm et les services systemd implémentent cet automatisme.

   Si lvmetad est démarré ou redémarré après avoir ajouté des disques au système, ou si le global_filter a changé, le cache doit être mis à jours.

   L'utilisation de lvmetad est géré dans lvm.conf par l'option global/use_lvmetad (voir lvmconfig --withcomments global/use_lvmetad)

   Pour ignorer des disques lvm au niveau système, utiliser devices/global_filter

OPTIONS

-l level[,level...] Spécifie les niveaux de log des messages à générer, séparés par une ','.
-p pidfile_path Chemin du fichier pid. Défaut: /run/lvmetad.pid
-s socket_path Chemin du socket. Défaut: /run/lvm/lvmetad.socket
-t timeout_value Délai d'inactivité avant que le service se termine. À 0, ne s'arrête jamais.
-f Ne fork pas, ne lance pas en tâche de fond

Variables d'environnement

LVM_LVMETAD_PIDFILE Chemin du fichier pid.
LVM_LVMETAD_SOCKET Chemin du socket.
^
28 juin 2016

htmlpdflatexmanmd




lvmlockctl

lvmlockctl

Contrôle pour lvmlockd

OPTIONS

--quit|-q Terminer lvmlockd
--info|-i AFfiche les informations d'état de lock depuis lvmlockd
--dump|-d Affiche le tampon de log de lvmlockd
--wait|-w 0|1 Option d'attente pour les autres commandes
--force|-f 0|1 Option force pour les autres commandes
--kill|-k ‹vgname› Tue l'accès au VG quand sanlock ne peut pas renouveler le bail
--drop|-r ‹vgname› Efface les locks pour le VG quand il n'est plus utilisé après --kill
--gl-enable|-E ‹vgname› Active le lock global dans le VG sanlock
--gl-disable|-D ‹vgname› Désactive le lock global dans le VG sanlock
--stop-lockspaces|-S Stop tous les lockspaces
^
28 juin 2016

htmlpdflatexmanmd




lvmlockd

lvmlockd

Service de lock LVM

   Les commandes LVM utilisent lvmlockd pour coordonner l'accès au stockage partagé. Quand LVM est utilisé sur des périphériques partagés par plusieurs hôtes, les locks vont:

- Coordonner la lecture/écriture dus métadonnées LVM
- Valider le cache des métadonnées
- Empêcher l'activation concurrente des volumes logiques

   lvmlockd utilise un gestionnaire de lock externe, les options sont:

sanlock Place les locks sur le disque dans le stockage LVM
dlm Utilise la communication réseaux et un gestionnaire de cluster

OPTIONS

--test|-T Mode test
--foreground|-f Ne lance pas en tâche de fond
--daemon-debug|-D Ne fork pas et affiche le débug sur stdout
--pid-file|-p path Spécifie le fichier PID
--socket-path|-s path Définis le chemin du socket
--syslog-priority|-S err|warning|debug Spécifie la priorité syslog
--gl-type|-g sanlock|dlm Définis le type de lock global
--host-id|-i num Définis l'id hôte pour le sanlock local
--host-id-file|-F path Un fichier contenant le sanlock local host_id
--sanlock-timeout|-o seconds Remplace le timeout d'E/S sanlock par défaut
--adopt|-A 0|1 récupère les locks d'une instance précédente de lvmlockd

Utilisation

   En utilisant LVM avec lvmlockd la première fois, il est nécessaire d'effectuer les étapes suivantes:

1. Choisir un gestionnaire de lock

        dlm Si dlm (ou corosync) est déjà utilisé par un autre logiciel cluster, sélectionner dlm. dlm utilise corosync qui nécessite une configuration additionnelle au delà du périmètre de ce document.
        sanlock sanlock ne dépend pas d'un logiciel de clustering

2. Configurer les hôtes pour utiliser lvmlockd Sur tous les hôtes où lvmlockd fonctionne, configurer lvm.conf:


       
locking_type = 1
use_lvmlockd = 1
# avec sanlock, assigner un host_id unique (de 1 à 2000) dans /etc/lvm/lvmlocal.conf local/host_id

3. Démarrer lvmlockd Utiliser un fichier d'init ou simplement lancer lvmlockd
4. Démarrer le gestionnaire de lock (sanlock) systemctl start wdmd sanlock ou (dlm) systemctl start corosync dlm
5. Créer un VG sur les périphériques partagés vgcreate --shared ‹vgname› ‹devices›. L'option shared définis le type de lock VG à sanlock ou dlm en fonctionne du gestionnaire utilisé.
6. Démarrer le VG sur tous les hôtes vgchange --lock-start. lvmlockd nécessite que les VG partagés soient démarrés avant qu'ils soient utilisés. Le lock manager démarre (joint) le lockspace du VG et peut prendre du temps.
7. Créer et activer les LV Les commandes lvcreate et lvchange sont utilisées pour créer et activer les LV dans un VG partagé. Un LV activé exclusivement sur un hôte ne peut pas être activé sur un autre. Quand plusieurs hôtes doivent utiliser le même LV simultannément, le LV peut être activé avec un lock partagé.

Démarrage et arrêt Une fois la configuration initiale, le démarrage et l'arrêt incluent les étapes suivantes. Elles sont effectuée manuellement ou en utilisant le gestionnaire de service système:

        - Démarrer lvmetad
        - Démarrer lvmlockd
        - Démarrer le lock manager
        - vgchange --lock-start
        - Activer les LV dans les VG partagés

La séquence d'arrêt est l'inverse:

        - Désactiver les LV dans les VG partagés
        - vgchange --lock-stop
        - Arrêter le gestionnaire de lock
        - Arrêter lvmlockd
        - Arrête lvmetad

Contrôle d'accès au VG

   Les termes suivants sont utilisés pour décrire les différentes formes de contrôle d'accès au VG.

   Un lockd VG est un VG partagé qui a un 'lock type' dlm ou sanlock. Il nécessite lvmlockd. Ces VG existent sur des stockages partagés qui sont visibles à plusieurs hôtes. Les commandes LVM utilisent lvmlockd pour effectuer le lock pour ces LV quand ils sont utilisés.

   Si le gestionnaire de lock pour le type de lock n'est pas disponible (par ex non démarré est échoue), lvmlockd n'est pas capable d'acquérir les locks pour les commandes LVM. Les commandes LVM qui lisent uniquement le VG vont généralement être autorisé à continuer sans locks dans ce cas. Les commandes pour modifier ou activer le VG vont échouer.

   Un local VG est utilisé par un simple hôte. Il n'a pas de type de lock ou un type 'none'. Les commandes LVM et lvmlockd n'effectuent pas de lock pour ces VG. Un VG local existe typiquement sur les périphériques locaux et ne peuvent pas être utilisés par différents hôtes.

   Si un VG local existe sur des périphériques partagés, il devrait être possédé par un simple hôte en ayant son system_id définis. Seul l'hôte avec un system_il correspondant peut utiliser le VG local. Un VG sans type de lock et sans system_id devrait être exclus de tous sauf un hôte en utilisant les filtres lvm.conf. Sans protection, un VG local sur un périphérique partagé peut facilement être endommagé ou détruit.

   Un VG clvm est un VG sur un stockage partagé qui nécessite clvmd pour le clustering.

VG lockés sur les hôtes n'utilisant pas lvmlockd

   Seul les hôtes qui utilisent les VG lockd devraient être configurés pour lancer lvmlockd. Cependant, les périphériques partagés utilisés par les VG lockd peuvent être visible aux hôte n'utilisant par lvmlockd. D'un hôte n'utilisant pas lvmlockd, les VG lockd sont ignorés de la même manière que les VG étranger. L'option --shared pour le reporting et les commandes d'affichage affichent les VG lockd sur un hôte n'utilisant pas lvmlockd, tout comme --foreign affiche les VG étranger.

Comparaison vgcreate

   Le type de contrôle d'accès VG est spécifié dans la commande vgcreate pour toutes les options vgcreate

vgcreate ‹vgname› ‹devices› Créé un VG local avec le system_id local quand lvmlockd et clvm ne sont pas configurés
Créé un VG local avec le system_id local quand lvmlockd est configuré
Créé un VG clvm quand clvm est configuré
vgcreate --shared ‹vgname› ‹devices› Nécessite que lvmlockd soit configuré est fonctionnel
Créé un VG lockd avec le type de lock sanlock|dlm en fonction du gestionnaire de lock courant
Les commandes LVM nécessitent des locks de lvmlockd pour utiliser le VG
lvmlockd obtient les locks depuis le gestionnaire de lock sélectionné
vgcreate -c|--clustered y ‹vgname› ‹devices› Nécessite que clvm soit configuré et fonctionnel
Créé un VG clvm avec le flag clustered
Les commandes LVM réclament les lockd à clvmd pour utiliser le VG

Créer le premier VG sanlock

   Créer le premier VG sanlock n'est pas protégé par le locking et nécessite une attention particulière. les sanlock existent dans le VG, donc ils ne sont pas disponible tant que le VG n'existe pas. Le premier sanlock VG contient le lock global.

- Le premier vgcreate doit avoir le chemin vers un périphérique qui n'a pas été initialisé avec pvcreate. L'initialisation pvcreate nécessite le lock global, qui ne sera pas disponible tant que le premier sanlock VG n'est pas crée
- En lançant vgcreate pour le premier sanlock VG, s'assurer que le périphérique utilisé n'est pas utilisé par une autre commande LVM. L'allocation de périphériques partagés est généralement protégé par le lock global, mais cela ne peut pas être fait pour le premier sanlock VG qui va maintenir le lock global
- En lançant vgcreate pour le premier sanlock VG, s'assurer que le nom du VG n'est pas utilisé par une autre commande LVM. L'unicité des noms des VG est généralement assurée par le lock global.
- Parce que le premier sanlock VG contient le lock global, ce VG doit être accessible à tous les hôtes qui utilisent les VG partagés avec sanlock. Tous les hôtes doivent utiliser le lock global depuis le premier VG sanlock.

Utiliser les VG lockd

   Il y a quelques considération spéciales en utilisant les VG lockd. Quand use_lvmlockd est activé dans lvm.conf, puis le premier VG lockd est créé, il n'existe pas de lock global. Dans cet état initial, les commandes LVM tentent et échouent à acquérir le lock global, produisant une alert, et certaines commande sont désactivée. Une fois le premier VG lockd créé, le lock global sera disponible, et LVM sera pleinement opérationnel.

   Quand un nouveau VG lockd est créé, son espace de lock est automatiquement démarré sur l'hôte qui l'a créé. Les autres hôte doivent lancer vgchange --lock-start pour démarrer le nouveau VG avant de pouvoir l'utiliser.

   Depuis la commande vgs, les VG lockd sont indiqués par 's' dans le champ attr. Le type de lock et les arguments de lock peuvent être affichés avec vgs -o+locktype,lockargs

   Les VG lockd doivent être démarrés et stoppé, , à la différence d'autres types de VG.

   vgremove d'un VG lockd échoue si d'autres hôte ont le VG démarré. Lance vgchange --lock-stop ‹vgname› sur tous les autres hôtes avant un vgremove.

Démarrer et stopper les VG

   Démarrer un VG lockd (vgchange --lock-start) indique au gestionnaire de lock de démarrer (joindre) le lockspace pour le VG sur l'hôte où il est lancé. Les locks créés pour le VG sont disponibles pour les commandes LVM sur l'hôte. Avant qu'un VG soit démarré, seu les commandes LVM qui lisent/affichent le VG sont autorisés à continuer sans locks. En utilisant le type de lock sanlock, démarrer un VG peut prendre du temps.

   Stopper un VG lockd (vgchange --lock-stop) indique au gestionnaire de stopper (quitter) le lockspace pour le VG sur l'hôte où il est lancé. Un VG ne peut pas être stoppé pendant qu'il a des LV actifs.

   Un VG lockd peut être démarré une fois que les points suivants soient vrai:

- lvmlockd est en cours de fonctionnement
- le gestionnaire de lock est en cours de fonctionnement
- Le VG est visible au système

Un VG lockd peut être stoppé si tous les LV sont désactivés. Tous les VG lockd peuvent être démarrés/stoppé en utilisant:
vgchange --lock-start
vgchange --lock-stop
Les VG individuels peuvent être démarrés/stoppé en utilisant:
vgchange --lock-start ‹vgname› ...
vgchange --lock-stop ‹vgname› ...
Pour que vgchange n'attende pas que le démarrage soit complété:
vgchange --lock-start --lock-opt nowait ...
lvmlockd peut être appélé directement pour stopper tous les lockspaces
lvmlockctl --stop-lockspaces

   Pour démarrer seulement les VG lockd sélectionnés, utiliser lvm.conf activation/lock_start_list. Quand défini, seul les VG nommés dans cette liste sont démarrés par vgchange. Si la liste n'est pas définie, tous les VG lockd visibles sont démarrés.

Démarrage et activation automatique

Les scripts ou programmes dans l'hôte qui démarrent automatiquement les VG utilisent l'option auto pour indiquer que la commande est lancée automatiquement par le système:
vgchange --lock-start --lock-opt auto [‹vgname› ...]

   Sans configuration additionnelle, l'option auto n'a pas d'effet; tous les VG sont démarrés sauf restreint par lock_start_list

   Cependant, quand activation/auto_lock_start_list dans lvm.conf est définis, la commande de démarrage auto effectue une phase de filtrage supplémentaire pour tous les VG démarrés, en testant chaque nom de VG avec la liste auto_lock_start_list. Cette directive définis les VG lockd qui seront démarré par la commande auto. Les VG lockd visible non incus dans la liste sont ignorés par la commande de démarrage auto. Si la liste est indéfinis, tous les noms de VG passent ce filtre.

   auto_lock_start_list permet à un utilisateur de sélectionner certains VG lockd qui devraient être démarrés automatiquement par le système. Pour utiliser l'auto activation des LV lockd, (voir auto_activation_volume_list), le démarrage automatique les VG lockd correspondants sont nécessaire.

Lock interne

   Pour optimiser l'utilisation de LVM avec lvmlockd, il y'a 3 types de locks:

GL lock

   Le lock global est associé avec les informations globales. qui ne sont pas isolés à un seul VG. Cela inclus l'espace de nom VG global, le jeu de périphérique non-utilisés et les PV orphelins et les propriétés des PV orphelins. Le lock global est utilisé en mode partagé par les commandes qui lisent cette information, ou en mode exclusif par les commandes que la change.

   La commande vgs acquière le lock global en mode partagé parce qu'il reporte la liste de tous les noms des VG.

   vgcreate acquière le lock global en mode exclusif parce qu'il créé un nouveau nom VG, et prend un PV de la liste des PV non utilisés

   Quand une commande LVM est donnée avec un tag, ou utilise select, il doit lire tous les VG pour correspondre au tag ou à la sélection, qui nécessite d'acquérir le lock global.

VG lock

   Un lock VG est associé avec chaque VG. Il est obtenu en mode partagé pour lire le VG et en mode exclusif pour le changer. Ce lock sérialise l'accès au VG avec toutes les autres commandes LVM accédant au VG depuis tous les hôtes.

   La commande vgs n'acquière le lock global que pour lire la liste de tous les noms VG, mais acquière le lock VG pour chaque VG avant de le lire.

lock LV

   Un lock LV est acquis avant que le LV soit activé, et est relâché après que le LV soit désactivé. Si le lock LV ne peut pas être acquis, le LV n'est pas activé. Les locks LV sont persistant et restent en place une fois l'activation faite. Les locks GL et VG sont transitoires et sont maintenus seulement pendant une commande LVM.

Retentatives de lock

   Si une requête pour un lock GL ou VG échoue à cause d'un conflit de lock avec un autre hôte, lvmlockd retente automatiquement pendant un cour lapse de temps avant de retourner une erreur à la commande LVM. Si ces retentatives sont insuffisantes, la commande LVM va retenter toute la demande de lock un nombre de fois spécifié par global/lvmlockd_retries avant d'échouer. Si une requête pour un lock LV échoue à cause d'un conflit de lock, la commande échoue immédiatemen.

Gérer le lock global dans les VG sanlock

   Le lock global existe dans un des VG sanlock. Le premier VG sanlock créé va contenir le lock global. Les VG sanlock suivant vont chacun contenir des locks global désactivés qui peuvent être activés ultérieurement si nécessaire.

   Le VG contenant le lock global doit être visible à tous les hôtes utilisant les VG sanlock. Cela peut être une raison de créer un petit VG sanlock, visible à tous les hôte, et dédié à maintenir ce lock global. Bien que non requis, cette stratégie peut éviter les problème si des VG sont déplacés ou supprimés.

   La commande vgcreate acquière typiquement le lock global, mais dans le cas du premier VG sanlock, il n'y a pas de lock global à acquérir tant que le premier vgcreate n'est pas complété. Donc, créer le premier VG sanlock est un cas spécial qui ignore le lock global.

   vgcreate pour un VG sanlock détermine qu'il est le premier à exister si aucun autre VG sanlock n'est visible. Il est possible que d'autre VG sanlock existent mais ne sont pas visible à l'hôte que lance vgcreate. Dans ce cas, vgcreate créé un nouveau VG sanlock avec le lock global activé. Quand l'autre VG sanlock avec le lock global apparaît, lvmlockd va voir plus d'un VG avec un lock global activé, et les commandes LVM vont reporter qu'il y a des locks global dupliqués.

Si la situation se produit où plus d'un VG sanlock contient un lock global, le lock global devrait être désactivé manuellement dans tous sauf un avec la commande:
lvmlockctl --gl-disable ‹vgname›

Un problème opposé peut se produire si le VG maintenant le lock global est supprimé. Dans ce cas, aucun lock global n'existe, et les commande LVM échouent à l'acquérir. Dans ce cas, le lock global doit être manuellement activé dans un des VG sanlock restant avec la commande:
lvmlockctl --gl-enable ‹vgname›

   Un petit VG sanlock dédié pour maintenir le lock global peut éviter ce cas.

LV lvmlock interne

   Un VG sanlock contient un LV caché appelé lvmlock qui maintient les locks sanlock. vgreduce ne peut pas supprimer le PV maintenant le LV lvmlock. Pour supprimer ce PV, changer le type de lock VG à none, lancer vgreduce, puis changer le type lock VG à sanlock. Similairement, pvmove ne peut pas être utilisé dans un PV utilisé par le LV lvmlock. Pour placer le LV lvmlock dans un périphérique spécifique, créer le VG avec seulement ce périphérique, puis utiliser vgextend pour ajouter d'autres périphériques.

LV partagés

   Quand un LV est utilisé en concurrence par plusieurs hôtes, le LV peut être activé sur plusieurs hôtes en utilisant un lock partagé. Pour activer le LV avec un lock partagé: lvchange -asy vg/lv

   Avec lvmlockd, une mode d'activation non-spécifié est toujours exclusif, par exemple, -ay vaut -aey.

   Si le type LV ne permet pas au LV d'être utilisé en concurrence par plusieurs hôtes, le lock d'activation partagé n'est pas permis et la commande lvchange va reporter une erreur. Les types LV qui ne peuvent pas être utilisés en concurrence depuis plusieurs hôtes sont les thin, cache, raid, mirror, et snapshot.

   lvextend sur un LV avec des locks partagé n'est pas encore permis. Le LV doit être désactivé, ou activé exclusivement pour lancer lvextend.

Récupérer les locks sanlock des PV perdus

   L'approche générale est de changer le type de lock VG à none, puis remettre à sanlock. Cela recréé le LV lvmlock interne et les locks nécessaires. D'autres étapes peuvent être nécessaire pour gérer les PV manquants.

Erreurs système de lock

lvmlockd Si lvmlockd échoue ou est terminé pendant qu'il maintient les lock, les locks sont orphelins dans le gestionnaire de lock. lvmlockd peut être redémarré avec une options pour adopter les locks dans le gestionnaire de lock qui les maintenait depuis une instance précédente.
dlm/corosync Si dlm ou corosync échoue, le système de clustering va isoler l'hôte en utilisant une méthode configuré dans le cluster. Les commandes LVM sur les autres hôtes ne pourront pas acquérir de lock tant que le procéssus de récupération n'est pas terminé.

Erreur de stockage sanlock

   Si le PV sous un LV lvmlock dans un VG sanlock est déconnecté, ne répond pas ou est trop lent, sanlock ne peut pas renouveler le bail pour les locks des VG. Après un certain temps, le bail expire, et les locks que l'hôte possède dans le VG peuvent être acquis par d'autres hôtes. Le VG doit être désactivé sur l'hôte avec le bail expiré avant que d'autres hôtes puissent acquérir les locks.

   Quand le service sanlock détecte que le bail du stockage est perdu, il lance la commande lvmlockctl --kill ‹vgname›. Cette commande émet un message syslog indiquant que le bail du stockage est perdu pour le VG et les LV doivent être immédiatement désactivés.

   Si aucun LV n'est actif dans le VG, le lockspace avec un bail expiré est supprimé, et les erreurs sont reportés en tantant d'utiliser le VG. Utiliser lvmlockctl --drop pour effacer le lockspace gelé de lvmlockd.

   Si le VG a des LV actifs quand le lock est perdu, les LV doivent être rapidement désactivés avant que le bail lockspace n'expire. Une fois tous les LV désactivés, lvmlockctl --drop ‹vgname› efface le lockspace ede lvmlockd. Si tous les LV dans le VG ne sont pas désactivés dans les 40 secondes, sanlock réinitialise l'hôte en utilisant le watchdog local. La réinitialisation machine est effectivement une forme sévère de désactivation les LV avant de pouvoir être activés dans d'autres hôtes.

   Dans le future, lvmlockctl kill pourra tenter automatiquement de forcer la désactivation des LV avant le que bail n'expire.

Erreur du service sanlock

   Si le service sanlock échoue pou quitte alors que le lockspace est démarré, le watchdog local réinitialise l'hôte. C'est nécessaire pour protéger les ressources d'application qui dépendent des bails sanlock.

Changer le nom du cluster dlm

   Quand un VG dlm est créé, le nom du cluster est sauvegardé dans les métadonnées du VG. Pour utiliser le VG, un hôte doit être dans le cluster dlm nommé. Si le nom change, ou le VG est déplacé dans un nouveau cluster, le nom du cluster dlm sauvegardé dans le VG doit également être changé.

Pour voir le nom du cluster dlm dans le VG, utiliser
vgs -o+locktype,lockargs ‹vgname›
Pour changer le nom du cluster dlm dans le VG:

        - stopper le VG sur tous les hôte
        vgchange --lock-stop ‹vgname›
        - Changer le type de lock VG à none
        vgchange --lock-type none ‹vgname›
        - Changer le nom du cluster dlm sur l'hôte ou déplacer le VG dans le nouveau cluster. Le nouveau cluster dlm doit être actif sur l'hôte
        cat /sys/kernel/config/dlm/cluster/cluster_name
        - Changer le type de lock VG à dlm qui définis le nouveau nom du cluster
        vgchange --lock-type dlm ‹vgname›
        Démarrér le VG sur les hôte qui l'utilisent
        vgchange --lock-start ‹vgname›

   Pour changer le nom du cluster dlm dans le VG quand le nom du cluster dlm a déjà changé, ou le VG a déjà été déplacé dans un autre cluster:

        - S'assurer que le VG n'est pas utilisé par un hôte
        - Le nouveau cluster dlm doit être actif
        cat /sys/kernel/config/dlm/cluster/cluster_name
        - Changer le type de lock VG à none
        vgchange --lock-type none --force ‹vgname›
        - Changer le type de lock à dlm
        vgchange --lock-type dlm ‹vgname›
        Démarrer le VG sur les hôtes qui l'utilisent
        vgchange --lock-start ‹vgname›

Changer un VG local en VG lockd

   Tous les LV doivent être inactifs pour changer le type de lock. lvmlockd doit être configuré et en cours de fonctionnement.

Changer un VG local en VG lockd avec la commande
vgchange --lock-type sanlock|dlm ‹vgname›
Démarrér le VG sur les hôte qui l'utilisent
vgchange --lock-start ‹vgname›

Changer un VG lockd en VG local

   Stopper le VG lockd sur tous les hôtes, puis lancer
   Pour changer un VG d'un type lockd à un autre, le changer d'abord en un VG local, puis dans le nouveau type

Changer un VG clvm en VG lockd

Tous les LV doivent être inactif pour changer le type de lock. Changer d'abord le VG clvm en VG local. Dans un cluster clvm en cours de fonctionnement, changer un VG clvm en VG local avec
vgchange -cn ‹vgname›
Si le cluster clvm n'est plus en cours de fonctionnement sur aucun nœud, des options supplémentaires peuvent être utilisées pour forcer le VG local
vgchange --config 'global/locking_type=0 global/use_lvmlockd=0' -cn ‹vgname›
Une fois le VG en local, suivre les étapes dans changer un VG local en un VG lockd.

Limites des VG lockd

   Listes de ce qui ne fonctionne pas encore dans les VG lockd

        - Créer un nouveau pool thin et un nouveau lv thin en une seule commande
        - Utiliser lvcreate pour créer des pools cache ou des LV cache (utiliser lvconvert)
        - Utiliser des origines externes pour les LV thin
        - Spliter les mirroirs est snapshots des LV
        - vgsplit
        - vgmerge
        - redimensionner un LV qui est actif dans le mode partagé sur plusieurs hôtes.

Changement lvmlockd depuis clvmd

   Bien que lvmlockd et clvmd sont des système entièrement différents, l'utilisation des commande LVM restent similaires. Les différences sont plus notables en utilisant l'option sanlock de lvmlockd. La différence d'utilisation visible entre les VG lockd avec lvmlockd et les VG clvm avec clvmd sont:

        - lvm.conf doit être configuré pour utiliser soit lvmvlockd (use_lvmlockd=1) soit clvmd (locking_type=3), mais pas les 2
        - vgcreate --shared créé un VG lockd, et vgcreate --clustered y créé un VG clvm
        - lvmlockd ajoute l'option pour utiliser sanlock pour le locking, évitant le besoin d'un cluster réseau.
        - lvmlockd utilise le mode d'activation exclusif par défaut quand le mode l'activation n'est pas spécifié. -ay signifie -aey
        - Les commandes lvmlockd s'appliquent toujours à l'hôte local, et n'a pas d'effet sur les hôte distants
        - lvmlockd fonctionne avec les pools thin et cache
        - lvmlockd fonctionne avec lvmetad
        - lvmlockd sauve le nom du cluster dans le VG lockd utilisant dlm
        - lvmlockd nécessite de démarrer/stopper les VG lockd avec vgchange --lock-start et --lock-stop
        - vgremove d'un VG sanlock peut échouer en indiquant que tous les hôtes ne sont pas stoppés dans le lockspace du VG
        - vgreduce ou pvmove d'un PV dans un VG sanlock échoue s'il maintient le LV lvmlock
        - lvmlockd utilise les retentatives lock au lieu de files d'attentes de lock
        - lvmlockd inclus des options de reporting VG lock_type et lock_args, et une options de reporting LV lock_args pour voir les champs de métadonnées correspondants
        - Les les commande vgs, le 6ème champ, "s" pour "shared" est affiché pour les VG lockd
        - Si lvmlockd échoue ou est terminé pendant qu'il est en cours d'utilisation, les locks restent, mais sont orphelins dans le gestionnaire de lock. lvmlockd peut être redémarré avec une option pour adopter les locks orphelins depuis une précédente instance de lvmlockd.
^
23 mai 2016

htmlpdflatexmanmd




lvmpolld

lvmpolld

Service lvm d'interrogation

   lvmpolld est un service de scrutin pour lvm. Le service reçoit des requêtes pour interroger les opérations déjà initialisée dans la commande lvm2. Les requêtes d'interrogation viennent de lvconvert, pvmove, lvchange ou vgchange.

   Le but de lvmpolld est de réduire le nombre de processus en tâche de fond par opération. Il élimine également la possibilité de terminer de manière non-solicitée les processus par des facteurs externes.

   lvmpolld est utilisé par lvm seulement si permis dans lvm.conf en spécifiant le paramètre global/use_lvmpolld.

OPTIONS

   Pour lancer le service dans un environnement de test, pidfile_path et socket_path doivent être changés.

-f, --foreground Ne fork pas, ne lance pas en tâche de fond
-l, --log {all|wire|debug} Sélectionne le type de message de log à générer. Les messages sont loggés par syslog.
-p, --pidfile chemin du fichier pid. défaut: /run/lvmpolld.pid
-s, --socket Chemin du fichier socket. Défaut: /run/lvm/lvmpolld.socket
-t, --timeout Le service s'arrête après le temps donné sans opération. à 0, ne quitte jamais
-B, --binary Chemin alternatif du binaire lvm.
--dump Contacte le service lvmpolld en cour de fonctionnement pour obtenir l'état complet et affiche les données au format brut.

Variables d'environnement

LVM_LVMPOLLD_PIDFILE Chemin du fichier pidfile
LVM_LVMPOLLD_SOCKET Chemin du fichier socket
^
06 juin 2016

htmlpdflatexmanmd




lvmsystemid

lvmsystemid

ID système LVM

   Les VG locaux peuvent exister sur des stockages partagés où ils sont visibles à plusieurs hôtes. Ces VG sont prévus pour être utilisé par une seule machine. Un system_id identifiant un hôte unique peut être assigné à un VG pour indiquer le propriétaire du VG. Ce propriétaire peut utiliser le VG normalement, et tous les autres hôtes vont l'ignorer.

   Le system id n'est pas une propriété dynamique, et peut seulement être changée dans des circonstances très limitées. Ces changements limités ne sont pas parfaitement reflétés via les hôtes. Une vue plus cohérente de stockage partagée nécessite d'utiliser un système de lock inter-hôte pour coordonner l'accès et mettre à jours les caches.

   Le system_id est une chaîne identifiant un hôte de manière unique. Il peut être définis manuellement ou automatiquement par lvm en utilisant un identifiant unique déjà disponible dans l'hôte, par exemple machine-id ou uname.

   Dans vgcreate, le system_id local est sauvé dans les métadonnées du VG. L'hôte local possède le nouveau VG, et les autres hôtes ne peuvent pas l'utiliser.

   Un VG sans system_id peut être utilisé par n'importe quel hôte. un foreign VG est un VG avec un system_id tel que vu par un hôte avec un system_id qui ne matche pas le system_id du VG.

   Les caractères de system_id valides sont les mêmes que les caractères valides pour un nom de VG. Si un system_id contient des caractères invalides, ils sont omis. Si un system_id dépasse la longueur maximale (128), il est tronqué.

Limitations et alertes

   pour bénéficier pleinement du system_id, tous les hôtes doivent avoir un system_id, et les VG également. Un VG sur un stockage partagé peut être endommagé ou détruit dans certains cas.

- Un VG sans system_id peut être utilisé sans restriction par tous les hôtes, même les hôtes qui ont un system_id. Pour vérifier qu'un VG a un system_id, utiliser vgs -o+systemid. Pour ajouter un system_id, utiliser vgchange --systemid
- 2 hôtes ne devraient pas avoir le même system_id.
- Les PV orphelins (ou les périphériques inutilisés) sur des stockages partagés sont complètement non-protégés par le systemid. Les commandes qui utilisent ces PV, tel que vgcreate ou vgextend, peut effectuer des opérations conflictuelles et corrompre les PV.

types d'accès VG

   Un VG local est prévu pour être utilisé par un simple hôte. Un VG partagé ou clusterisé est prévu pour être utilisé par plusieurs hôtes. Ils peuvent être distingués par:

non-restreint: un VG local qui n'a pas de system_id. Ce type de VG n'est pas protégé est accéssible à tous les hôtes
possédé: un VG local qui a un system_id, tel que vu par un hôte anay un system_id correspondant. Ce VG est accessible à l'hôte
Étranger: un VG local qui a un system_id, tel que vu par un hôte ayant un system_id qui ne correspond pas.
Exporté: un VG local qui a été exporté avec vgexport et n'a pas de system_id. Ce type de VG ne peut être accédé que par vgimport.
partagé: un VG partagé ou "lockd" a lock_type définis et pas de system_id. il est utilisé sur un stockage partagé pour plusieurs hôtes, uniquement via lvmlockd
clusterisé: Un VG clusterisé ou "clvm" a le flag clustered mis et pas de system_id. Il est utilisé sur un stockage partagé par plusieurs hôtes, en utilisant clvmd.

system_id_source Le system_id d'un hôte peut être définis de plusieurs manières. lvm.conf global/system_id_source définis la méthode utilisée pour trouver le system_id local:

        none lvm n'utilise pas de system_id
        machineid Le contenu de /etc/machine-id est utilisé comme id système
        uname La chaîne utsname.nodename de uname(2) est utilisé comme system_id.
        lvmlocal Définis dans lvmlocal.conf local/system_id
        file définis dans un fichier spécifié par lvm.conf global/system_id_file

   Changer system_id_source change le system_id, ce qui peut empêcher l'utilisation de VG. Si un system_id_source autre que none échoue à la résolution du system_id, l'hôte sera autorisé à accéder aux VG sans system_id, mais ne sera pas autorisé à accéder aux VG avec un system_id.

extra_system_ids

   Dans certains cas, l'hôte qui lance la commande assigne son propre system_id au nouveau VG. Pour le remplacer par un autre system_id, utiliser: vgcreate --systemid ‹SystemID› ‹VG› ‹Devices›. Si l'argument de --systemid est une chaîne vide, le VG est créé sans system_id.

Rapport/affichage

   Le system_id d'un VG est affiché avec l'option de repporting systemid. Les commandes de rapport/affichage ignorent les VG étrangés par défaut. Pour afficher ces VG, l'option --foreign peut être utilisé. Cela implique que la commande lise les VG sur les disques et non via lvmetad.

vgexport/vgimport

   vgexport efface le system_id. Les autres hôtes continuent à voir le VG nouvellement exporté comme étrangé à cause du caching local (quand lvmetad est utilisé). Mettre à jours manuellement le cache avec pvscan --cache pour reconnaître le nouveau VG exporté.

   vgimport définis le system_id. vgimport scanne automatiquement les nouveaux VG exportés.

vgchange

Un hôte peut changer le system_id de ses propres VG, mais la commande nécessite confirmation du fait que l'hôte perd l'accès à ces VG
vgchange --systemid SystemID VG

   Le system_id peut être supprimé d'un VG en spécifiant une chaîne vide comme nouveau system_id. Un hôte ne peut pas changer directement le system_id d'un VG étranger. Pour déplacer un VG d'un hôte à un autre, vgexport et vgimport doivent être utilisés. Pour devenir propriétaire d'un VG étranger, un hôte peut ajouter le system_id étranger à sa liste extra_system_ids, changer le system_id de ce VG, puis supprimer le system_id de sa extra_system_ids.

VG partagés

   Un VG partagé/lockd n'a pas de system_id, permettant à plusieurs hôte de l'utiliser via lvmlockd. Changer un VG en un type lockd efface le system_id.

VG clusterisés

   Un VG clusterisé/clvm n'a pas de system_id, permettant à plusieurs hôte de l'utiliser via clvmd. Changer un VG en type clustered efface le system_id existant. Changer le VG clustered en non-clustered définis le system_id de l'hôte qui a lancé la commande vgchange.

creation_host

   dans vgcreate, le champ de métadonnées VG creation_host est définis par défaut à uname de l'hôte. Ce champ ne peut pas être changé, et n'est pas utilisé pour contrôler l'accès. Quand system_id_source est "uname", system_id et creation_host sont les même.

Orphelins

   Les VG orphelins sont des périphériques non-utilisé. À cause de celà, il ne sont pas protégés par un system_id, et tous les hôtes peuvent les utiliser. La coordination des changements des changements en VG orphelins est hors du périmètre du system_id.

   Les effets sont spécialement évidents quand lvm utilise lvmetad. Par exemple, si plusieurs hôte voient un VG orphelin, et un hôte créé un VG en utilisant l'orphelin, les autres hôtes continuent de le voir orphelin. Rien n'empêche les autres hôte d'utiliser ce PV et le corrompre. Si les autres hôte lancent une commande de rescan, et mettent à jours lvmetad, ils le reconnaîtront.
^
22 mai 2016

htmlpdflatexmanmd




lvmthin

lvmthin

Provisionning léger lvm

   Les blocks dans un volume logique standard sont alloués quand le LV est créé, mais les blocks dans un provisionning léger sont alloués quand ils sont écris. À cause de celà, un LV thin provisioned a une taille virtuelle, et peut être plus grand que l'espace physique disponible. La quantité de stockage physique fournie pour les LV thin provisioned peut être augmentée ultérieurement en cas de besoin.

   Les blocks dans un LV standard sont alloués (durant la création) dans le VG, mais les blocks dans un LV thin sont alloués (durant l'utilisation) depuis un "thin pool LV" spécial. Ce pool contient des blocks de stockage physique, et les blocks dans les LV thin référencent simplement les blocks dans le pool.

   Un thin pool LV doit être créé avant que les LV thin puissent y être créés. Un thin pool LV est créé en combinant 2 LV standard: Un LV de données qui maintient les blocks pour les LV thin, et un LV de métadonnées, qui maintient les blocks de données associés avec les LV thin.

   Les snapshots de LV thin sont inefficaces parce que les blocks de données communs à un LV thin et un de ses snapshots sont partagés. Les snapshots peuvent être plus de LV thin ou d'autre snapshots thin. Les blocks communs à des snapshots récursifs sont également partagés dans le thin pool. Il n'y a pas de limite ou de dégradation des séquences de snapshots.

   Vu que les LV thin ou les LV snapshot y sont écris, ils consomment des blocks de données dans le pool. À mesure que les blocks de données diminuent dans le pool, il peut être nécessaire d'en fournir. Cela peut être en étandant le pool. Supprimer les LV thin ou les snapshots du pool peut également libérer des blocks dans le pool. Cependant, supprimer les LV n'est pas toujours une manière efficace de libérer de l'espace parce que la quantité est limité au nombre de blocks non partagés avec d'autres LV dans le pool.

   L'allocation de block incrémental de pools thin peut causer les LV à devenir fragmentés. Les LV standard évitent généralement en allouant tous les blocks en une fois durant la création.

Termes Thin

ThinDataLV Grand LV créé dans un VG, utilisé par le pool thin pour stocker les blocks ThinLV
ThinMetaLV Petit LV créé dans un VG, utilisé pour suivre l'utilisation des blocks de données
ThinPoolLV Combinaison de ThinDataLV et ThinMetaLV, contenant les ThinLV et les SnapLV
ThinLV Créé depuis le ThinPoolLV, apparaît blanc après la création
SnapLV Snapshot créé depuis le ThinPoolLV, apparaît comme un snapshot d'un autre LV après la création

Utilisation Thin

   La méthode première pour utiliser le provisionning thin est:

1. Créer ThinDataLV Créer un LV qui va maintenir les données du pool thin
lvcreate -n pool0 -L 10G vg0
2. Créer ThinMetaLV Créer un LV qui va maintenir les métadonnées
lvcreate -n pool0meta -L 1G vg0
3. Créer le ThinPoolLV Combiner les données et métadonnées en un LV pool
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0
4. Créer un ThinLV Créer un nouveau LV thin depuis le pool. Ce LV est créé avec une taille virtuelle
lvcreate -n thin1 -V 1T --thinpool vg0/pool0
lvcreate -n thin2 -V 1T --thinpool vg0/pool0
5. Créer un SnapLV Créer des snapshots d'un ThinLV ou SnapLV existant. Ne pas spécifier -L, --size pour créer un snapshot.
lvcreate -n thin1s1 -s vg0/thin1
lvcreate -n thin1s2 -s vg/thin1
lvcreate -n thin1s1s1 -s vg/thin1s1
6. Activer un SnapLV Les snapshots thin sont créés avec le flag "activation skip", indiqué par l'attribut "k". Utiliser -K avec lvchange ou vgchange pour activer les snapshots avec l'attribut "k"
lvchange -ay -K vg0/thin1s1

Syntaxe alternative pour spécifier le type thin-pool

La syntaxe pour créer un pool est:
lvconvert --type -thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV
Un LV existant est convertis en un pool thin en changeant son type en thin-pool. Une syntaxe alternative peut être utilisée pour la même opération:
lvconvert --thinpool VG/ThinDataLV --poolmetadata VG/ThinMetaLV

   Le type thin-pool est déduit par lvm; l'option --thinpool n'est pas un alias pour --type thin-pool. L'utilisation de l'option --thinpool ici est différente de l'utilisation de l'option --thinpool en créant un LV thin, où il spécifie le pool dans lequel le LV thin est créé.

Automatic pool metadata LV

Un LV thin de données peut être convertis en un LV pool thin sans spécifier de LV metadata. LVM créé automatiquement un LV metadata dans le même VG
lvcreate -n pool0 -L 10G vg0
lvconvert --type thin-pool vg0/pool0

Spécifier des périphériques pour les LV de données et de métadonnées

Les LV de données et de métadonnées dans un thin pool sont mieux créés sur des périphériques physiques séparés. Pour cela, spécifie les nom de périphérique à la fin de la ligne lvcreate. Cela peu être utile pour utiliser des périphériques rapides pour les métadonnées
lvcreate -n pool0 -L 10G vg0 /dev/sdA
lvcreate -n pool0meta -L 1G vg0 /dev/sdB
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

Tolérance aux panne en utilisant RAID

Pour la tolérance aux panne, utiliser un raid pour le pool de données et de métadonnées. C'est recommandé pour les métadonnées
lvcreate --type raid1 -m 1 -n pool0 -L 10G vg0 /dev/sdA /dev/sdB
lvcreate --type raid1 -m 1 -n pool0meta -L 1G vg0 /dev/sdC /dev/sdD
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

LV metadata spare

La première fois qu'un LV pool est créé, lvm crée un lv metadata space dans le VG. Ce comportement peut être contrôlé avec l'option --poolmetadataspare y|n.

   Pour créer le LV pmspare (pool metadata spare), lvm crée d'abord un LV avec un nom par défaut, par ex lvol0, puis le convertit en un LV caché avec le suffix _pmspare, par ex, lvol0_pmspare. Un pmspare est conservé dans un VG à utiliser pour tout pool thin. Le pmspare LV ne peut pas être créé explicitement, mais peut être supprimé explicitement.

Exemple

lvcreate -n pool0 -L 10G vg0
lvcreate -n pool0meta -L 1G vg0
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

Vérification et réparation des métadonnées

Si un thin pool metadata est endommagé, il peut être réparé. Vérifier et réparer un thin pool metadata est analogue à lancer fsck sur un système de fichier.

Quand un thin pool LV est activé, lvm lance la commande thin_check pour vérifier les métadonnées dans le LV de métadonnées du pool.

lvm.conf thin_check_executable peut être définis avec une chaîne vide ("") pour désactiver l'étape thin_check. Ce n'est pas recommandé.
lvm.conf thin_check_options Contrôle les options de commande utilisées pour la commande thin_check

   Si la commande thin_check trouve un problème avec les métadonnées, le LV pool n'est pas activé, et les métadonnées doivent être réparées.

Les commandes de réparation simple ne réussisent pas toujours. La réparation avancée peut nécessiter d'éditer les métadonnée du pool thin et les métadonnées lvm.
lvconvert --repair VG/ThinPoolLV

   La réparation effectue les étapes suivantes:

1. Créer une nouvelle copie réparée des métadonnées lvconvert lance la commande thin_repair pour lire les métadonnées endommagées dans le LV de métadonnées existant, et écrit une nouvelle copie réparée dans le LV pmspare du VG.
2. Remplacer le thin pool metadata LV Si l'étape 1 est réussie, le LV de métadonnées du pool thin est remplacé avec le LV pmspare contenant les métadonnées corrigées. L'ancien devient visible avec le nouveau nom ThinPoolLV_tmetaN (où N est 0, 1, ...).

   Si la réparation fonctionne, le LV pool thin et ses LV thin peuvent être activés, et le LV contenant les métadonnées du pool thin endommagé peut être supprimé. Il peut être utile de déplacer le nouveau LV de métadonnées vers un meilleur PV.

   Si la réparation ne fonctionne pas, le LV du pool thin et ses LV thin sont perdus.

   Si les métadonnées sont restaurées manuellement avec thin_repair directement, le LV de métadonnées du pool peuvent être échangé avec un autre LV contenant les nouvelles métadonnées:

Activation des snapshots thin

Quand un LV snapshot thin est créé, il a le flag "activation skip" par défaut. Ce flag est indiqué par l'attribut 'k' affiché par lvs
lvs vg/thin1s1

   Ce flag indique que le LV snapshot n'est pas activé par des commande d'activation normales. Ce comportement ne s'applique pas aux commandes de désactivation.

   Un LV snapshot avec l'attribut 'k' peut être activé en utilisant -K (ou --ignoreactivationskip) en plus de l'option standard -ay (ou --activate y)

Commande pour activer un LV snapshot thin:
lvchange -ay -K VG/SnapLV

   Le flag persistant "activation skip" peut être désactivé durant lvcreate, ou ultérieurement avec lvchange en utilisant l'option -kn (ou --setactivationskip n). Il peut être activé avec -kv (ou --setactivationskip y).

   Quand le flag 'activation skip' est supprimé, les commandes d'activation normales vont activer le LV, et l'option -K n'est pas nécessaire

La commande pour créer un LV snapshot sans le flag:
lvcreate -kn -n SnapLV -s VG/ThinLV
Commande pour supprimer le flag d'un LV snapshot:
lvchange -kn VG/SnapLV

lvm.conf auto_set_activation_skip Contrôle le paramètre d'activation utilisé par lvcreate

Supprimer les LV pool thin, les LV thin et les snapshots

   Supprimer un LV thin et ses snapshots associés retourne les blocks utilisés au LV pool thin. Ces blocks sont réutilisés pour d'autres LV thin et snapshots.

   Supprimer un LV pool thin supprime le LV de données, et le LV de métadonnées et retourne l'espace au VG.

   La suppression de LV pool thin, LV thin et snapshots avec lvremove, ne peuvent pas être récupérés avec vgcfgrestore. vgcfgbackup ne récupère pas les métadonnées du pool.

Gérer manuellement l'espace libre d'un LV pool thin

   L'espace disponible dans le LV pool thin peut être affiché avec la commande lvs. L'espace libre peut être ajouté en étendant le LV pool thin.

Commande pour étendre l'espace du pool:
lvextend -L Size VG/ThinPoolLV

Exemple

Doubler l'espace physique d'un pool:
lvextend -L+10G vg0/pool0

   D'autres méthodes pour augmenter l'espace dans le pool inclus de supprimer un LV thin et des snapshots associés, ou lancer fstrim dans le système de fichier utilisant un LV thin.

Gérer manuellement l'espace de métadonnées d'un LV pool thin

   L'espace de métadonnées disponible dans un LV pool thin peut être affiché avec la commande lvs -o+metadata_percent

Commande pour étendre l'espace de métadonées du pool:
lvextend --poolmetadatasize Size VG/ThinPoolLV

Utiliser fstrim pour augmenter l'espace libre dans un LV pool thin

   Supprimer des fichiers dans un système de fichier au dessus d'un LV thin ne rajoute pas généralement d'espace libre dans le pool. Lancer manuellement fstrim peut retourner de l'espace dans le pool qui a été utilisé par des fichier supprimés. fstrim ne fonctionne pas si le LV pool thin a le mode discards à ignore.

Exemple

   Un pool thin a 10G d'espace physique, et un LV thin qui a une taille virtuelle 100G. Écrire un fichier 1G dans le système de fichier réduit l'espace libre dans le pool thin de 10% et augmente l'utilisation virtuelle du système de fichier de 1%. Supprimer le fichier de 1G restore les 1% virtuel du système de fichier, me ne restaure pas les 10% physiques. la commande fstrim restore cet espace physique au pool thin.

Étendre automatiquement le LV pool thin

   Le service lvm dmeventd (lvm2-monitor) supervise l'utilisation de données des LV pool thin et les étends quand l'utilisation atteind un certain niveau. L'espace libre nécessaire doit exister dans le VG pour étendre les LV pool thin. Superviser et étendre les LV pool thin sont contrôlés indépendamment.

Supervision

   Quand un LV pool thin est activé, dmeventd va le superviser par défaut. La commande pour démarrer et stopper la supervision dmeventd d'un LV pool thin:
   Le status de supervision actuel peut être affiché avec la commande lvs -o+seg_monitor

autoextension

   dmeventd devrait être configuré pour étendre les LV pool thin avant que tout l'espace soit utilisé. Les alertes sont émises via syslog quand l'utilisation d'un pool thin atteind 80%, 85%, 90% et 95%. Le point auquel dmeventd étend un pool, et la quantité sont contrôlés avec 2 paramètres de configuration:

lvm.conf thin_pool_autoextend_threshold % qui défins quand le pool devrait être étendu. À 100 désactive l'extension automatique. La valeur minimum est 50.
lvm.conf thin_pool_autoextend_percent Définis la quantité d'espace à ajouter, en pourcentage de la taille courante.

Désactivation

   Il y a plusieurs manières où l'extension des pools thin peut être empêché.

- Si le service dmeventd ne fonctionne pas, aucun monitoring ou extension automatique ne va se produire
- Même quand dmeventd fonctionne, toute la supervision peut être désactivée avec le paramètre de monitoring dans lvm.conf
- Pour activer ou créer un LV pool thin sans interagir avec dmeventd, utiliser l'option --ignoremonitoring peut être utilisé.
- Définir thin_pool_autoextend_threshold à 100 désactive l'extension automatique.

Exemple

   Si thin_pool_autoextend_threshold vaut 70 et thin_pool_autoextend_percent vaut 20, quand un pool excède 70% d'utilisation, il est étendu de 20%. Pour un pool de 1G, en utilisant 700M cela déclenche une redimmensionnement à 1,2G. Quand l'utilisation excède 840M, le pool sera étendu à 1,44G, et ainsi de suite.

Épuisement de l'espace

   Proprement géré, l'espace de données des pool thin devraient être étendus avant que tout l'espace soit utilisé. Si l'espace est déjà épuisé, il peut être toutefois être étendus.

   Le comportement d'un pool thin plein est configurable avec l'option --errorwhenfull y|n de lvcreate ou lvchange. Cette option ne s'applique seulement pour les écritures.

La commande pour changer le comportement d'un pool thin complet:
lvchange --errorwhenfull {y|n} VG/ThinPoolLV

lvm.conf error_when_full Contrôle l'erreur dans le fichier de configuration

Le paramètre courant d'un LV pool thin peut être affiché avec
lvs -o+lv_when_full

   Le paramètre errorwhenfull n'affecte pas les paramètre de supervision et autoextension, et ces derniers n'affectent pas non plus le paramètre errorwhenfull. C'est seulement quand la supervision/autoextension ne sont pas effectifs que le pool thin devient plein et que le paramètre errorwhenfull est appliqué.

   Le défaut est 'n'. Les écritures des LV thin sont acceptés et mis en queue, dans l'attente d'espace disponible. Une fois l'espace étendu, les écritures en attente sont traitées.

   En attendant d'être étendus, le pool thin met les écriture en queue pour 60 secondes (le défaut). Si l'espace n'a pas été étendus après ce délai, les écritures en queue retournent une erreur à l'appelant, par ex le système de fichier. Cela peut résulter en une corruption du système de fichier pour les systèmes de fichier non-journalisés qui peut nécessiter fsck. Quand un pool thin retourne des erreurs d'écriture à un LV thin, un système de fichier est sujet à la perte de données utilisateur non-synchronisés.

   Le timeout de 60 secondes peut être changé ou désactivé avec l'option du module kernel dm-thin-pool no_space_timeout.
^
23 mai 2016

htmlpdflatexmanmd




lvm lvpoll

lvm lvpoll

Commande interne utilisée par lvmpolld pour compléter des opérations de volume logique

   lvpoll est utilisé par lvmpolld pour superviser et compléter les opérations lvconvert et pvmove. lvpoll n'initie pas de lui même ces opérations et ne doivent généralement être appelées directement.

OPTIONS

--polloperation {pvmove|convert|merge|merge_thin} Option obligatoire. pvmove réferre à une opération qui déplace des données. convert réferre à une augmentation qui augmente le nombre de copies redondantes des données maintenue par un mirroir. merge indique une opération de fusion qui n'implique pas de volumes thin. merge_thin indique une opération merge implique des snapshots thin.
--abort Annule un pvmove en progression
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--handlemissingpvs Utilisé quand l'opération doit gérer des PV manquant pour pouvoir continuer. Celà peut se produire quand lvconvert répare un mirroir avec un ou plusieurs périphériques en faute
-i|--interval Seconds Affiche la progression
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Relance l'opération pvmove identifié par le volume logique vg00/pvmove0
lvm lvpoll --polloperation pvmove vg00/pvmove0
Annule la même opération
lvm lvpoll --polloperation pvmove --abort vg00/pvmove0
Trouver le nom du LV pvmove résultant d'un pvmove /dev/sda1
lvs -a -S move_pv=/dev/sda1
Relance la conversion mirroir de vg00/lvmirror
lvm lvpoll --polloperation convert vg00/lvmirror
Compléter la réparation du mirroir
lvm lvpoll --polloperation convert vg/damaged_mirror --handlemissingpvs
fusionner les snapshots:
lvm lvpoll --polloperation merge vg/snapshot_old
finir la fusion de snapshot thin
lvm lvpoll --polloperation merge_thin vg/thin_snapshot
^
23 mai 2016

htmlpdflatexmanmd




lvreduce

lvreduce

Réduire la taille d'un volume logique

   lvreduce permet de réduire la taille d'un volume logique. Il est nécessaire d'e s'assure que tout système de fichier dans le volume est redimensionner avant de lancer lvreduce pour que les extents qui sont enlevés ne soient pas utilisés.

   Réduire les volumes logique snapshot est supporté également. Mais pour changer le nombre de copies dans un volume logique en mirroir utiliser lvconvert. Les tailles seront arrondies si nécessaire, par exemple, la taille de volume doit être un nombre exacte d'extents et la taille d'un segment striped doit être un multiple du nombre de stripes.

OPTIONS

-A|--autobackup {y|n} [--commandprofile ProfileName
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-f|--force Force la réduction de la taille sans demander.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-l|--extents [-]LogicalExtentsNumber[%{VG|LV|FREE|ORIGIN} Réduit ou définis la taille du volume logique en unité d'extents logique. avec le signe '-' la valeur est soustraite de la taille actuelle et sans, la valeur est une taille absolue. Le nombre total d'extents physique libérés sera supérieur à cette valeur logique si, par exemple, le volume est mirroré. Le nombre peut également être exprimé en % total de l'espace dans le vg avec le suffixe %VG, relatif à la taille existante du volume logique avec le suffixe %LV, comme pourcentage de l'espace libre restant dans le VG avec les suffixe %FREE, ou (pour un snapshot) comme % de l'espace totale de l'origine avec le suffixe %ORIGIN. La valeur résultante pour la soustraction est arrondie à l'inférieur, pour la taille absolue la taille est arrondie au supérieur.
-L|--size [-]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Réduit ou définis la taille lv en unité spécifiée. avec '-' la valeur est soustraite de la taille actuelle et sans, la valeur est absolue.
-n|--nofsck N'effectue pas de fsck avant de redimmensionner le système de fichier quand le système de fichier le nécessite.
-r|--resizefs Redimmensionne le système de fichier avec le Lv en utilisant fsadm.

Exemples

Réduire la taille du volume logique lvol1 dans le vg vg00 de 3 extents logiques
lvreduce -l -3 vg00/lvol1
^
23 mai 2016

htmlpdflatexmanmd




lvremove

lvremove

Supprimer un volume logique

   lvremove supprime un ou plusieurs volumes logiques. Les volumes logiques ne peuvent pas être désactivé ou supprimés s'ils sont ouverts (s'ils contiennent un système de fichier monté). Supprimer un volume logique origine supprime également tous les snapshots dépendants.

   Si le volume logique est clusterisé il doit être désactivé sur tous les nœuds dans le cluster avant qu'il puisse être supprimé. Un simple lvchange émis depuis un des nœuds peut le faire.

   Si les paramètres de configuration metadata/record lvs history est activé et le volume logique à supprimer forme une partie de l'historique d'au moins un volume logique qui est présent, alors une représentation simplifiée du volume logique sera retenu. Cela inclus le temps de suppression, la date de création, le nom, l'uuid, et le nom du volume group et permet de voir la chaîne des volumes snapshot thin même après que certains volumes logiques intermédiaire aient été supprimés. Les noms de tels volumes logique historique acquièrent un '-' comme préfixe (ex: '-lvol1') et ne peut pas être réactivé. Utiliser lvremove une seconde fois, avec les '-', pour le supprimer completement.

OPTIONS

-f, --force, -ff Supprimer les volumes logiques actifs sans confirmation. Pour traiter des pools endommagés, utiliser -ff
--nohistory Désactive l'enregistrement de l'historique des volumes logique qui sont supprimés.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-S|--select Selection Ne traite que les lignes qui matchent le critère donné
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Supprimer le volume logique actif lvol1 dans le vg vg00 sans demander de confirmation:
lvremove -f vg00/lvol1
Supprimer tous les volumes logique dans le volume group vg00:
lvremove vg00
^
23 mai 2016

htmlpdflatexmanmd




lvrename

lvrename

Renommer un volume logique

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-t|--test Lance en mode test
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
-f|--force Ne demande pas confirmation
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.

Exemples

Renommer lvold dans le volume group vg02 en lvnew
lvrename /dev/vg02/lvold vg02/lvnew
Syntaxe alternative pour renommer ce volume logique
lvrename vg02 lvold lvnew
^
24 mai 2016

htmlpdflatexmanmd




lvresize

lvresize

Redimensionne un volume logique

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--commandprofile ProfileName Sélectionne le profile de configuration de commande
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonné originel.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-l|--extents [+][-]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN} Étend ou définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle, '-' la valeur est soustraite, et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size [+][-]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Étend ou définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, '-' pour soustraire, sinon elle est prise comme valeur absolue.
--poolmetadatasize [+]MetadataVolumeSize[bBsSkKmMgG] Change ou définis la taille de métadonnées du pool thin. May: 16Gio
-f|--force Ne demande pas confirmation
-n|--nofsck N'effectue pas de fsck avant d'étendre le système de fichier qu'en c'est nécessaire.
-r|--resizefs Redimensionne le système de fichier en même temps que le volume logique en utilisant fsadm

Exemples

Étendre un volume logique vg1/lv1 de 16Mo en utilisant les extents physiques /dev/sda:0-1 et /dev/sdb:0-1 pour l'allocation des extents:
lvresize -L+16M vg1/lv1 /dev/sda:0-1 /dev/sdb:0-1
^
24 mai 2016

htmlpdflatexmanmd




lvs

lvs

Affiche des informations sur les volumes logiques

OPTIONS

--all Inclus des informations sur les volumes logiques internes
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. lv_all sélectionne toutes les colonnes de volume logiques, et lvseg_all sélectionne toutes les colonnes de segment de volume logique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--rows Affiche les colonnes brutes
--segments Produit une ligne de sortie pour chaque allocation contigue d'espace dans chaque volume physique
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
-H, --history Inclus l'historique des volumes logique dans la sortie
^
23 mai 2016

htmlpdflatexmanmd




lvscan

lvscan

Scan tous les disques à la recherche de volumes logiques

   lvscan scanne tous les volumes group ou tous les périphériques blocks supportés dans le système à la recherche des volumes logiques. La sortie consiste d'une ligne pour chaque volume logique indiquant s'il est actif, un origine ou un snapshot, la taille et sa stratégie d'allocation. Utiliser lvs ou lvdisplay pour obtenir des informations plus compréhensibles.

OPTIONS

--all Inclus des informations sur les volumes logiques interne tel que les mirroirs.
--cache LogicalVolume Uniquement si lvmetad est utilisé. Émet un rescan des labels physiques et des zones de métadonnées de tous les PV que le volume logique utilise. Peut être utilisé quand un volume logique RAID devient dégradé, pour mettre à jours les informations sur les volumes physique indisponible. Seulement nécessaire si le volumen logique n'est pas monitoré par dmeventd
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-v|--verbose Mode verbeux
^
30 juin 2013

htmlpdflatexmanmd




lxc

lxc

Présentation

Les options suivantes doivent être présentes dans le kernel:
    * General setup
    * Control Group support
-› Namespace cgroup subsystem
-› Freezer cgroup subsystem
-› Cpuset support
-› Simple CPU accounting cgroup subsystem
-› Resource counters
-› Memory resource controllers for Control Groups
    * Group CPU scheduler
-› Basis for grouping tasks (Control Groups)
    * Namespaces support
-› UTS namespace
-› IPC namespace
-› User namespace
-› Pid namespace
-› Network namespace
    * Device Drivers
    * Character devices
-› Support multiple instances of devpts
    * Network device support
-› MAC-VLAN support
-› Virtual ethernet pair device
    * Networking
    * Networking options
-› 802.1d Ethernet Bridging
    * Security options
-› File POSIX Capabilities

Spécifications

   Un conteneur est un objet où la configuration est persistante. L'application est lancée dans ce conteneur et va utiliser cette configuration. Quand un processus est lancé, le conteneur est lancé. Quand le dernier processus dans le conteneur se termine, le conteneur est stoppé. Le conteneur peut être volatile, c'est à dire créé directement avec un fichier de configuration.
^
28 novembre 2016

htmlpdflatexmanmd




lxc-2.0.5

lxc-2.0.5

Présentation

Les options suivantes doivent être présentes dans le kernel:
    * General setup
    * Control Group support
-› Namespace cgroup subsystem
-› Freezer cgroup subsystem
-› Cpuset support
-› Simple CPU accounting cgroup subsystem
-› Resource counters
-› Memory resource controllers for Control Groups
    * Group CPU scheduler
-› Basis for grouping tasks (Control Groups)
    * Namespaces support
-› UTS namespace
-› IPC namespace
-› User namespace
-› Pid namespace
-› Network namespace
    * Device Drivers
    * Character devices
-› Support multiple instances of devpts
    * Network device support
-› MAC-VLAN support
-› Virtual ethernet pair device
    * Networking
    * Networking options
-› 802.1d Ethernet Bridging
    * Security options
-› File POSIX Capabilities
Les options suivantes doivent être présentes dans le kernel:
    * General setup
    * Control Group support
-› Namespace cgroup subsystem
-› Freezer cgroup subsystem
-› Cpuset support
-› Simple CPU accounting cgroup subsystem
-› Resource counters
-› Memory resource controllers for Control Groups
    * Group CPU scheduler
-› Basis for grouping tasks (Control Groups)
    * Namespaces support
-› UTS namespace
-› IPC namespace
-› User namespace
-› Pid namespace
-› Network namespace
    * Device Drivers
    * Character devices
-› Support multiple instances of devpts
    * Network device support
-› MAC-VLAN support
-› Virtual ethernet pair device
    * Networking
    * Networking options
-› 802.1d Ethernet Bridging
    * Security options
-› File POSIX Capabilities

Spécifications

   Un conteneur est un objet isolant des ressources de l'hôte. L'application/système est lancé dans un conteneur spécifié par une configuration qui est soit initialement créé ou passé en paramètres.
^
14 octobre 2014

htmlpdflatexmanmd




lxc-attach

lxc-attach

Lance un processus dans un conteneur en cours d'exécution

OPTIONS

-a, --arch Spécifie l'architecture. Accèpte les même paramètres que l'option lxc.arch.
-e, --elevated-privileges Ne supprime pas les privilège en exécutant la commande dans le conteneur. Le nouveau processus ne sera pas ajouté au cgroup du conteneur et ses capabilities ne seront pas supprimé avant l'exécution.
-s, --namespaces Spécifie l'espace de nom à attacher, en liste pipé, ex: NETWORK|IPC. MOUNT, PID, UTSNAME, IPC, USER, NETWORK. Implique -e
-R, --remount-sys-proc$ force à remonter /proc et /sys pour refléter les contextes d'espace de nom courant.
--keep-env Conserve l'environnement courant pour les programmes attachés. Mode par défaut, mais va changer dans le future à cause de fuites d'informations dans le conteneur.
--clear-env Efface l'environnement avant d'attacher.
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Pour ajouter un nouveau shell dans un conteneur existant:
lxc-attach -n container
Pour redémarrer le service cron d'un container existant:
lxc-attach -n container -- /etc/init.d/cron restart
Désactiver eth1 d'un conteneur qui n'a pas la capability NET_ADMIN:
lxc-attach -n container -e -- /sbin/ip link delete eth1
ou utiliser -s pour utiliser les outils installés sur l'hôte en dehors du conteneur:
lxc-attach -n container -s NETWORK -- /sbin/ip link delete eth1
^
25 novembre 2016

htmlpdflatexmanmd




lxc-attach-2.0.5

lxc-attach-2.0.5

Lance un processus dans un conteneur en cours d'exécution

OPTIONS

-f, --rcfile config_file Spécifie le fichier de configuration pour configurer la virtualisation et l'isolation pour le conteneur.
-a, --arch Spécifie l'architecture. Accèpte les même paramètres que l'option lxc.arch.
-e, --elevated-privileges Ne supprime pas les privilège en exécutant la commande dans le conteneur. Le nouveau processus ne sera pas ajouté au cgroup du conteneur et ses capabilities ne seront pas supprimé avant l'exécution. Les privilèges sont séparés par un |. Accèpte CGROUP, CAP et LSM.
-s, --namespaces Spécifie l'espace de nom à attacher, en liste pipé, ex: NETWORK|IPC. MOUNT, PID, UTSNAME, IPC, USER, NETWORK. Implique -e
-R, --remount-sys-proc force à remonter /proc et /sys pour refléter les contextes d'espace de nom courant.
--keep-env Conserve l'environnement courant pour les programmes attachés. Mode par défaut, mais va changer dans le future à cause de fuites d'informations dans le conteneur.
--clear-env Efface l'environnement avant d'attacher.
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
25 novembre 2016

htmlpdflatexmanmd




lxc-autostart-2.0.5

lxc-autostart-2.0.5

démarrer/stopper/tuer des conteneur auto-démarrés

   lxc-autostart traite les conteneur avec lxc.start.auto définis. Il permet à l'utilisateur de démarrer et d'arrêter ces conteneurs dans le bon ordre, attendant le bon moment. Il supporte le filtrage par lxc.cgroup ou simplement lancer tous les conteneurs définis. Il peut également être utilisé par des outils externe en mode list où aucune action n'est effectuée et affiche la liste des conteneurs affectés.

OPTIONS

-r, --reboot Reboot du conteneur
-s, --shutdown Stoppe le conteneur
-k, --kill Tue toutes les tâches dans le conteneur
-L, --list Affiche seulement le nom du conteneur au lieu d'effectuer l'action.
-t, --timeout TIMEOUT Attend TIMEOUT secondes avant de stopper/démarrer le conteneur
-g, --group GROUP Liste des groupes à sélectionner. Peut être spécifié plusieurs fois.
-a, --all Ignore lxc.group et sélectionne tous les conteneurs auto-démarrés
-A, --ignore-auto Ignore le flag lxc.start.auto. Combiné avec -a, sélectionne tous les conteneurs dans le système.

Autostart et boot système

   La commande lxc-autostart fait partie du service LXC. Autorisé à lancer des hôtes au démarrage, il est utilisé pour sélectionner les conteneurs à démarrer dans l'ordre et le délai entre chaque démarrage quand l'hôte boot.

   Chaque conteneur peut faire partie d'un ou plusieurs groupes, ou aucun. 2 groupes sont spéciaux. 1 est le groupe NULL. L'autre est le groupe "onboot"

   Quand le système boot avec lxc, il tente d'abord de booter tous les conteneur avec lxc.start.auto == 1 qui est un membre du groupe onboot. Le démarrage dans l'ordre de lxc.start.order. Si un lxc.start.delay est spécifié il est honoré avant de démarrer le prochain conteneur. Une fois les membres du groupe onboot démarrés, le système lxc lance les conteneurs avec lxc.start.auto == 1 mais non membre du groupe onboot.

Exemple de démarrage

Démarre le groupe onboot en premier, puis le groupe NULL
-g "onboot,"
Démarre le groupe DNS, puis web, puis NULL, suivis par onboot:
-g "dns,web,,onboot"
^
14 octobre 2014

htmlpdflatexmanmd




lxc-cgroup

lxc-cgroup

Gère le cgroup associé avec un conteneur

OPTIONS

state-object Spécifie le state object name
[value] Spécifie la valeur à assigner au state-object
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Afficher les périphériques permis:
lxc-cgroup -n foo devices.list
Assigner les processeurs 0 et 3 au conteneur:
lxc-cgroup -n foo cpuset.cpus "0,3"
^
25 novembre 2016

htmlpdflatexmanmd




lxc-cgroup-2.0.5

lxc-cgroup-2.0.5

Gère le cgroup associé avec un conteneur

OPTIONS

state-object Spécifie le state object name
[value] Spécifie la valeur à assigner au state-object
-q, --quiet mode silencieux
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
--rcfile=FILE Spécifie le fichier de configuration pour la virtualisation et l'isolation

Exemples

Afficher les périphériques permis:
lxc-cgroup -n foo devices.list
Assigner les processeurs 0 et 3 au conteneur:
lxc-cgroup -n foo cpuset.cpus "0,3"
^
25 novembre 2016

htmlpdflatexmanmd




lxc-checkconfig-2.0.5

lxc-checkconfig-2.0.5

Vérifie le support lxc dans le kernel

Exemple

Vérifie le kernel courant. CONFIG peut être définis dans l'environnement
lxc-checkconfig
^
14 octobre 2014

htmlpdflatexmanmd




lxc-checkpoint

lxc-checkpoint

Vérifie le conteneur et dump son état dans un fichier.

OPTIONS

-S, --statefile=FILE Écrit l'état du conteneur dans cet fichier. est exclusif avec --statefd
-d, --statefd=FD Écrit l'état du conteneur dans le descripteur de fichier
-k, --kill Tue le conteneur après vérification. Les processus reçoivent un SIGKILL. est exclusif avec --pause
-p, --pause Mais le conteneur en pause avec la vérification
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Démarre un nouveau conteneur 123 calculant les décimales de pi:
lxc-execute -n 123 -- pi1 -d 500000
lxc-execute --name=123 -- pi1 -d 500000
pour checkpoint ce même conteneur en mode dump-death:
lxc-checkpoint -n 123 -S /share/123/chkpt1 -k
lxc-checkpoint --name=123 --statefile=/share/123/chkpt1 -k
pour vérifier le même conteneur et le mettre en pause:
lxc-checkpoint -n 123 -S /share/123/chkpt1 -p
lxc-checkpoint --name=123 -S /share/123/chkpt1 -p
^
25 novembre 2016

htmlpdflatexmanmd




lxc-config-2.0.5

lxc-config-2.0.5

Demander la configuration système lxc

OPTIONS

-l Liste toutes les clé supportées
‹item› Requêter la valeur de la clé spécifiée
^
14 octobre 2014

htmlpdflatexmanmd




lxc-console

lxc-console

Lance une console permettant de se logger dans le conteneur

   Si le service tty a été configuré et est disponible pour le conteneur spécifié comme paramètre, cette commande va lancer une console permettant de se logger dans le conteneur.

OPTIONS

[escape character] Spécifie le préfixe de séquence d'échappement à utiliser au lieu de ‹ctrl a›.
-t [ttynum] Spécifie le tty à utiliser
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
25 novembre 2016

htmlpdflatexmanmd




lxc-console-2.0.5

lxc-console-2.0.5

Lance une console permettant de se logger dans le conteneur

   Si le service tty a été configuré et est disponible pour le conteneur spécifié comme paramètre, cette commande va lancer une console permettant de se logger dans le conteneur.

OPTIONS

[escape character] Spécifie le préfixe de séquence d'échappement à utiliser au lieu de ‹ctrl a›.
-t [ttynum] Spécifie le tty à utiliser
-q, --quiet mode silencieux
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
^
25 novembre 2016

htmlpdflatexmanmd




lxc-copy-2.0.5

lxc-copy-2.0.5

Copie un conteneur existant

   lxc-copy créé et optionnellement démarre des copies de conteneurs existants. Il remplace lxc-clone et lxc-start-ephemeral. Les copies peuvent être des clones complets, dans ce cas tout le système de fichier du conteneur est simplement copié dans le nouveau conteneur. La copie peut également être un snapshot, par exemple une copie COW du conteneur original. Dans ce cas, le stockage doit supporter les snapshots (aufs, btrfs, lvm et zfs).

   si -e est spécifié un snapshot éphémère du conteneur original est créé et démarré. Les conteneur éphémères sont configurés avec lxc.ephemeral = 1 et sont détruits à l'arrêt. Si -e et -D sont spécifiés, un snapshot non éphémère est créé et démarré.

   Les conteneurs créés et démarrés avec -e peuvent avoir des montages personnalisé. Il sont spécifiés pavec -m. 3 types de montages sont supportés: aufs, bind et overlay.

OPTIONS

-N, --newname newname Nom pour la copie
-p, --newpath newpath Chemin pour la copie
-R, --rename Renomme le conteneur original
-s, --snapshot Crée un snapshot du conteneur original.
-F, --foreground Lance le snapshot en foreground
-d, --daemon Lance le snapshot en tâche de fond
-m, --mount mounttype Spécifie un montage pour un snapshot avec ses options (ex: ind=/src:/dest:ro,overlay=/src:/dest)
-B, --backingstorage backingstorage Spécifie le type de stockage à utiliser (aufs, btrfs, dir, lvm, loodp, overlay, zfs)
-L, --fssize size [unit] Spécifie la taille pour un système de fichier LVM
-D, --keepdata Avec -e, un conteneur non-éphémère est créé et démarré
-K, --keepname Le hostname du conteneur original est conservé pour la copie
-M, --keepmac L'adresse MAC du conteneur original est conservé pour la copie
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration

Hook de copie

   Si le conteneur copié a un ou plusieurs lxc.hook.clone, les hooks spécifiés sont appelés pour le nouveau conteneur. Les 3 premiers arguments passés au hook sont le nom du conteneur, une section 'lxc' et le type de hook (clone). La variable d'environnement LXC_ROOTFS_MOUNT donne le chemin sous lequel le système de fichier root est monté. Le chemin du fichier de configuration est stocké dans LXC_SRC_NAME, et le chemin ou le périphérique dans lequel le rootfs est localisé est dans LXC_ROOTFS_PATH.
^
10 octobre 2014

htmlpdflatexmanmd




lxc-create

lxc-create

Créer un objet système où sont stockés les informations de configuration et utilisateur

   L'objet est un répertoire crée dans/var/lib/lxc et identifié par son nom.

OPTIONS

-f config_file Spécifie le fichier de configuration
-t template Raccourci vers ur scrite lxc-template.
-B backingstore vaut dir, lvm, loop, btrfs, best

        dir (défaut) signifie que le système racine du conteneur sera un répertoire sous /var/lib/lxc/container/rootfs.
        btrfs le système racine doit être btrfs, et le conteneur sera crée dans un nouveau volume. Cela permet de créer des clones
        lvm un périphérique block lvm sera utilisé et les options disponible sont --lvname --vgname --thinpool --fstype et --fssize
        best lxc tente dans l'ordre: btrfs, zfs, lvm, dir.

-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
28 novembre 2016

htmlpdflatexmanmd




lxc-create-2.0.5

lxc-create-2.0.5

Créer conteneur

   lxc-create créé un objet système où sont stockés les informations de configuration et où peuvent être stockés les informations utilisateur. Le nom est utilisé pour spécifier le conteneur à utiliser avec les différentes commandes LXC. L'objet est un répertoire crée dans/var/lib/lxc et identifié par son nom.

OPTIONS

-f config_file Spécifie le fichier de configuration
-t template Raccourci vers un script lxc-template.
-B backingstore dir, lvm, loop, btrfs, zfs, rbd, ou best

        dir (défaut) signifie que le système racine du conteneur sera un répertoire sous /var/lib/lxc/container/rootfs.
        btrfs le système racine doit être btrfs, et le conteneur sera crée dans un nouveau volume. Cela permet de créer des clones
        lvm un périphérique block lvm sera utilisé et les options disponible sont --lvname --vgname --thinpool --fstype et --fssize
        best lxc tente dans l'ordre: btrfs, zfs, lvm, dir.

-- template-options Passe des options au template. voir lxc-create -t TEMPLATE -h
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
10 octobre 2014

htmlpdflatexmanmd




lxc-destroy

lxc-destroy

Supprimer un conteneur

OPTIONS

-f Si un conteneur est un cour de fonctionnement, l'arrête avant.
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
^
28 novembre 2016

htmlpdflatexmanmd




lxc-destroy-2.0.5

lxc-destroy-2.0.5

Supprimer un conteneur

OPTIONS

-f Si un conteneur est un cour de fonctionnement, l'arrête avant.
-s, --snapshots Détruit le conteneur spécifié incluant tous ses snapshots
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
25 novembre 2016

htmlpdflatexmanmd




lxc-device-2.0.5

lxc-device-2.0.5

Gère les périphériques des conteneurs en cours d'exécution

OPTIONS

-n, --name=NAME Nom du conteneur
‹action› Type d'action à effectuer, seul 'add' est actuellement supporté
‹DEVICE› Périphérique à ajouter
[NAME] Nom pour le périphérique dans le conteneur

Exemples

Créer /dev/video0 dans le conteneur p1
lxc-device -n p1 add /dev/video0
Place eth0 de l'hôte en tant que eth1 dans p1
lxc-device -n p1 add eth0 eth1
^
11 octobre 2014

htmlpdflatexmanmd




lxc-execute

lxc-execute

Lance une application dans un conteneur via un processus intermédiaire lxc-init qui aura le pid 1. lxc-init est conçu pour forwarder les signaux à la commande lancée.

OPTIONS

-f, --rcfile config_file Spécifie le fichier de configuration pour le conteneur
-s, --define KEY=VAL Permet d'assigner des variables supplémentaires
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
28 novembre 2016

htmlpdflatexmanmd




lxc-execute-2.0.5

lxc-execute-2.0.5

Lance une application dans un conteneur via un processus intermédiaire lxc-init qui aura le pid 1. lxc-init est conçu pour forwarder les signaux à la commande lancée.

OPTIONS

-f, --rcfile config_file Spécifie le fichier de configuration pour le conteneur
-s, --define KEY=VAL Permet d'assigner des variables supplémentaires
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
10 octobre 2014

htmlpdflatexmanmd




lxc-freeze

lxc-freeze

Met en pause les processus d'un conteneur

OPTIONS

-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
28 novembre 2016

htmlpdflatexmanmd




lxc-freeze-2.0.5

lxc-freeze-2.0.5

Met en pause les processus d'un conteneur

OPTIONS

-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
14 octobre 2014

htmlpdflatexmanmd




lxc-halt

lxc-halt

Arrête un conteneur sans terminer les processus. Fournis un switch au runlevel 0 dans le conteneur

OPTIONS

CONTAINER Spécifie le conteneur.
^
25 novembre 2016

htmlpdflatexmanmd




lxc-info-2.0.5

lxc-info-2.0.5

Demande des informations sur un conteneur

OPTIONS

-c, --config KEY Affiche une clé de configuration d'un conteneur. Peut être spécifié plusieurs fois
-s, --state Affiche simplement l'état du conteneur
-p, --pid Affiche simplement le pid du conteneur
-i, --ips Affiche simplement les adresses IP du conteneur
-S, --stats Affiche des statistiques du conteneur. Noter que pour des raisons de performances le kernel ne comptabilise pas la mémoire sauf si une limite est définie (ex: lxc.cgroup.memory.kmem.limit_in_bytes = number)
-H, --no-humanize Affiche les statistiques en brut.
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration

Exemples

Afficher les informations pour foo
lxc-info -n foo
Afficher les informations pour tous les conteneurs dont le nom commence par ubuntu
lxc-info -n 'ubuntu*'
Afficher la paire veth de foo
lxc-info -n foo -c lxc.network.0.veth.pair
^
11 octobre 2014

htmlpdflatexmanmd




lxc-kill

lxc-kill

Envoie un signal au process 1 du conteneur. si utilisé sur une application lancée par lxc-execute, lxc-init le forward au pid 2

OPTIONS

--name=NAME SIGNUM Envoie SIGNUM au premier processus du conteneur
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

envoie le signal 26 au process pi1 dans le conteneur 123:
lxc-execute -n 123 -- pi1 -d 500000
lxc-kill --name=123 26
^
14 octobre 2014

htmlpdflatexmanmd




lxc-ls

lxc-ls

Lister les conteneurs existant sur le système

OPTIONS

-# Affiche une entrée par ligne (défaut quand /dev/stdout n'est pas un tty)
--active Liste uniquement les conteneurs actifs (idem à --frozen --running)
--frozen Liste seulement les conteneurs gelés
--running Liste seulement les conteneurs en cours de fonctionnement
--stopped Liste seulement les conteneurs stoppés
-f, --fancy Utilise une sortie fantaisie, en colonnes
-F, --fancy-format Liste séparé par des "," de colonnes à afficher dans la sortie fancy. La liste des champs accèpté est: name, state, ipv4, ipv6, autostart, pid, memory, ram, swap
--nesting Affiche les conteneurs imbriqués
filter (regex) Le filtre spécifié sera appliqué au nom du conteneur.

Exemples

Liste tous les conteneurs, un par ligne avec nom, état, adresse ipv4 et ipv6
lxc-ls --fancy
Lister tous les conteneurs actifs et affiche la liste dans une colonne
lxc-ls --active -1
^
25 novembre 2016

htmlpdflatexmanmd




lxc-ls-2.0.5

lxc-ls-2.0.5

Lister les conteneurs existant sur le système

OPTIONS

-1 Affiche une entrée par ligne (défaut quand la sortie n'est pas a tty)
--active Liste seulement les conteneur actifs (idem à --frozen --running)
--frozen Liste seulement les conteneurs gelés
--running Liste seulement les conteneurs en cours de fonctionnement
--stopped Liste seulement les conteneurs stoppés
-f, --fancy Utilise une sortie fantaisie, en colonnes
-F, --fancy-format Liste séparé par des "," de colonnes à afficher dans la sortie fancy. voir avec --help
-g, --groups groups Liste de groupes que le conteneur doit avoir pour être affichés
--nesting=NUM Affiche les conteneurs imbriqués. Le niveau d'imbrication à afficher peut être spécifié
--filter=regex L'expression est appliquée au nom du conteneur
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration

Exemples

Liste tous les conteneurs, un par ligne avec nom, état, adresse ipv4 et ipv6
lxc-ls --fancy
Lister tous les conteneurs actifs et affiche la liste dans une colonne
lxc-ls --active -1
^
14 octobre 2014

htmlpdflatexmanmd




lxc-monitor

lxc-monitor

Supervise l'état des conteneurs spécifiques

OPTIONS

-Q, --quit quitte immédiatement s'il n'a pas de client au lieu d'attendre 30 secondes
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Superviser les états du conteneur foo
lxc-monitor -n foo
Superviser les états des conteneurs foo et bar
lxc-monitor -n 'foo|bar'
Superviser les états des conteneurs dont le nom commence avec 'f' ou 'b'
lxc-monitor -n '[f|b].*'
Superviser les états de tous les conteneurs
lxc-monitor -n '.*'
^
25 novembre 2016

htmlpdflatexmanmd




lxc-monitor-2.0.5

lxc-monitor-2.0.5

Supervise l'état des conteneurs spécifiques

OPTIONS

-Q, --quit Demande à lxc-monitord dans chaque lxcpath de quitter.lxc-monitord quitte immédiatement s'il n'a pas de client au lieu d'attendre 30 secondes
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration

Exemples

Superviser les états du conteneur foo
lxc-monitor -n foo
Superviser les états des conteneurs foo et bar
lxc-monitor -n 'foo|bar'
Superviser les états des conteneurs dont le nom commence avec 'f' ou 'b'
lxc-monitor -n '[f|b].*'
Superviser les états de tous les conteneurs
lxc-monitor -n '.*'
^
14 octobre 2014

htmlpdflatexmanmd




lxc-ps

lxc-ps

Liste les processus appartenant à un conteneur spécifique

OPTIONS

--name NAME spécifie le nom du conteneur pour limiter la sortie
--lxc Limite la sortie au processus appartenant à tous le conteneur lxc
ps_options l'option est passée à la commande ps
^
10 octobre 2014

htmlpdflatexmanmd




lxc-restart

lxc-restart

Redémarre un conteneur depuis un fichier.

OPTIONS

-S, --state-file=FILE Lit l'état du conteneur dans le fichier
-d, --statefd=FD Lit l'état du conteneur dans le descripteur de fichier
-p Met le conteneur en pause après l'avoir redémarré
-f, --rcfile=config_file Spécifie le fichier de configuration pour l'isolation du conteneur.
-s KEY=VAL Assigne la valeur VAL à la variable KEY.
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Démarre un nouveau conteneur 123 calculant les décimales de pi:
lxc-execute -n 123 -- pi1 -d 500000
lxc-execute --name=123 -- pi1 -d 500000
pour checkpoint ce même conteneur en mode dump-death:
lxc-checkpoint -n 123 -S /share/123/chkpt1 -k
lxc-checkpoint --name=123 --statefile=/share/123/chkpt1 -k
Et pour le redémarrer avec un id différent:
lxc-restart -n 200 -S /share/123/chkpt1
lxc-restart --name=200 --statefile=/share/123/chkpt1
^
25 novembre 2016

htmlpdflatexmanmd




lxc-snapshot-2.0.5

lxc-snapshot-2.0.5

Snapshot un conteneur

   Les snapshots sont stockés comme conteneur snapshot sous le chemin de configuration du conteneur.

OPTIONS

-c, --comment comment-file Associe le commentaire dans le fichier spécifié avec le snapshot
-d, --destroy snapshot-name Détruit le snapshot nommé. 'ALL' détruit tous les snapshots
-L, --list Liste les snapshots existants
-C, --showcomments Affiche les commentaires dans la liste des snapshots
-r, --restore snapshot-name Restaure un snapshot, signifiant la création d'un nouveau conteneur complet, qui est une copie du snapshot
-N, --newname En restaurant un snapshot, le dernier argument optionnel si non spécifié via --newname, est le nom à utiliser pour le conteneur restauré. Si ce nom est identique au nom original du conteneur, le conteneur original sera détruit et le conteneur restauré le remplacera. Noter que supprimer le snapshot original n'est pas possible avec aufs, overlayfs ou zfs.
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
11 octobre 2014

htmlpdflatexmanmd




lxc-start

lxc-start

Lance une application dans un conteneur. Les processus et groupes de processus orphelin ne sont pas supportés avec cette commande, utiliser lxc-execute à la place.

OPTIONS

-d, --daemon Lance en tâche de fond
-p, --pidfile Crée un fichier avec le process id spécifié
-f, --rcfile config_file Fichier de Configuration pour le conteneur
-c, --console console-device spécifie un device à utiliser pour la console du conteneur, ex. /dev/tty8. Par défaut, utilise le terminal courant.
-L, --console-log console-logfile Spécifie un fichier pour logger la sortie de la console du conteneur.
-s, --define KEY=VAL Permet d'assigner des variables supplémentaires
-c, --close-all-fds Si un des descripteurs de fichier est hérité, le ferme. -d implique -c
--share-net name|pid hérite un espace de nom réseau. Il continuera d'être géré pas son propriétaire original. La configuration réseau dans ce conteneur est ignorée et les scripts up/down ne sont pas exécutés.
--share-ipc name|pid Hérite d'un espace de nom IPC
--share-uts name|pid Hérite d'un espace de nom UTS
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
28 novembre 2016

htmlpdflatexmanmd




lxc-start-2.0.5

lxc-start-2.0.5

Lance une application dans un conteneur

OPTIONS

-d, --daemon Lance en tâche de fond
-F, --foreground Ne lance pas en tâche de fond
-p, --pidfile Crée un fichier avec le process id
-f, --rcfile config_file Fichier de Configuration pour le conteneur
-c, --console console-device spécifie un device à utiliser pour la console du conteneur, ex. /dev/tty8. Par défaut, utilise le terminal courant.
-L, --console-log console-logfile Spécifie un fichier pour logger la sortie de la console du conteneur.
-s, --define KEY=VAL Permet d'assigner des variables supplémentaires
-C, --close-all-fds Si un descripteur de fichier est hérité, le ferme. -d implique -c
--share-net name|pid hérite un espace de nom réseau. Il continuera d'être géré pas son propriétaire original. La configuration réseau dans ce conteneur est ignorée et les scripts up/down ne sont pas exécutés.
--share-ipc name|pid Hérite d'un espace de nom IPC
--share-uts name|pid Hérite d'un espace de nom UTS
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
11 octobre 2014

htmlpdflatexmanmd




lxc-stop

lxc-stop

Arrêter une application dans un conteneur

OPTIONS

-r, --reboot Redémarre de conteneur
-k, --kill Tue toutes les tâches dans le conteneur au lieu de les terminer proprement
--nokill termine les tâches proprement, mais ne détruit pas le conteneur
--nolock Évite l'utilisation d'un lxc locking, et devrait être utilisé seulement si lxc-stop est bloqué à cause d'un mauvais état système.
-W, --nowait effectue l'action demandé et quitte
-t, --timeout TIMEOUT attend TIMEOUT secondes avec de détruit brutalement le conteneur

Codes de sortie

0 Le conteneur a été stoppé avec succès
1 Un erreur s'est produite en stoppant le conteneur
2 Le conteneur spécifié existe mais n'est pas en cours de fonctionnement
^
28 novembre 2016

htmlpdflatexmanmd




lxc-stop-2.0.5

lxc-stop-2.0.5

Arrêter une application dans un conteneur

   lxc-stop reboot, éteind proprement, ou tue tous les processus dans le conteneur. Par défaut il tente d'éteindre le conteneur en envoyant le signal lxc.haltsignal (SIGPWR par défaut) au processus init du conteneur, attend 60 secondes, et quitte si le conteneur s'est arrêté, ou envoie lxc.stopsignal (SIGKILL par défaut) pour forcer l'extinction. Un reboot envoien un lxc.rebootsignal (SIGINT par défaut).

OPTIONS

-r, --reboot Redémarre de conteneur
-k, --kill Tue toutes les tâches dans le conteneur au lieu de les terminer proprement
--nokill termine les tâches proprement, mais ne détruit pas le conteneur si l'arrêt a échoué
--nolock Évite l'utilisation d'un lxc locking, et devrait être utilisé seulement si lxc-stop est bloqué à cause d'un mauvais état système.
-W, --nowait effectue l'action demandé et quitte
-t, --timeout TIMEOUT attend TIMEOUT secondes avec de détruit brutalement le conteneur

Codes de sortie

0 Le conteneur a été stoppé avec succès
1 Un erreur s'est produite en stoppant le conteneur
2 Le conteneur spécifié existe mais n'est pas en cours de fonctionnement
^
10 octobre 2014

htmlpdflatexmanmd




lxc-unfreeze

lxc-unfreeze

Résume les processus d’un conteneur

OPTIONS

-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié
^
28 novembre 2016

htmlpdflatexmanmd




lxc-unfreeze-2.0.5

lxc-unfreeze-2.0.5

Résume les processus d’un conteneur

OPTIONS

-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration
^
25 novembre 2016

htmlpdflatexmanmd




lxc-unshare-2.0.5

lxc-unshare-2.0.5

Lance un tâche dans un nouveau jeu d'espaces de noms

   lxc-unshare permet de lancer une tâche dans un jeu d'espaces de noms clonés. Principalement utilisé pour des tests. En dépit de son nom, il utilise toujours un clone au lieu de départager la nouvelle tâche avec les nouveaux namespaces.

OPTIONS

-s namespaces Spécifie les espaces de nom à attacher en liste séparé par un pipe. MOUNT, PID, UTSNAME, IPC, USER et NETWORK.
-u user Spécifie un userid pour la nouvelle tâche
-H hostname Définis le hostname dans le nouveau conteneur. Uniquement avec UTSNAME
-i interfacename Place l'interface nommée dans le conteneur. Seulement avec NETWORK
-d Met en tâche de fond
-M Monte les système de fichier par défaut (/proc, /dev/shm et /dev/mqueue) dans le conteneur. Seulement avec MOUNT

Exemples

Lancer un nouveau shell avec sont propre UTSNAME
lxc-unshare -s UTSNAME /bin/bash
Lancer un shell dans un nouvel espace réseau, pid et mount
lxc-unshare -s "NETWORK|PID|MOUNT" /bin/bash
Avec 2 interfaces réseaux (lo et veth1) et le hostname 'slave'
lxc-unshare -s "NETWORK|PID|MOUNT|UTSNAME" -M -H slave -i veth1 /bin/bash
^
25 novembre 2016

htmlpdflatexmanmd




lxc-user-nic-2.0.5

lxc-user-nic-2.0.5

Créer et attacher un nic à un autre namespace network

   lxc-user-nic est un setuid-root programme avec lequel les utilisateurs peuvent créer des interfaces réseau à utiliser par un conteneur lxc. Il consulte /etc/lxc/lxc-usernet pour déterminer le nombre d'interfaces l'utilisateur est autorisé à créer, et quel bridge peut être attaché. Il conserve le nombre d'interface dans /run/lxc/nics.

OPTIONS

pid pid pour la tâche dont
type Type d'interface réseau à attacher. Actuellement seul veth est supporté.
bridge Bridge auquel attacher l'interface
nicname nom de l'interface réseau
^
25 novembre 2016

htmlpdflatexmanmd




lxc-usernsexec-2.0.5

lxc-usernsexec-2.0.5

Lancer une tâche en root dans un nouvel espace de nom utilisateur

OPTIONS

-m uid-map uid map à utiliser dans l'espace de nom utilisation. Chaque map consiste en 4 valeur séparés par ':'. 1) le caractère u, g ou b (both), 2) userid, 3)userid vu dans l'hôte. 4) nombre d'id à mapper.

Exemples

lancer un shell avec des sous uid mappé dans le conteneur:
lxc-usernsexec
Lancer un shell autre que /bin/sh
lxc-usernsexec -- /bin/bash
map l'uid 1000 en 0, et root en 190000
lxc-usernsexec -m b:0:1000:1 -m b:1:190000:1 -- /bin/chown 1:1 $file
^
11 octobre 2014

htmlpdflatexmanmd




lxc-wait

lxc-wait

Attend un état de conteneur spécifique avant de se terminer

OPTIONS

-s states Spécifier l’état du conteneur
-t timeout attend timeout secondes pour l'état désiré
-P, --lxcpath=PATH Utilise un chemin alternatif (défaut: /var/lib/lxc)
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Utilise identifiant de conteneur spécifié

Exemples

Quitte quand RUNNING est atteind:
lxc-wait -n foo -s RUNNING
Quitte quand RUNNING ou STOPPED est atteind:
lxc-wait -n foo -s 'RUNNING|STOPPED'
^
28 novembre 2016

htmlpdflatexmanmd




lxc-wait-2.0.5

lxc-wait-2.0.5

Attend un état de conteneur spécifique avant de se terminer

OPTIONS

-s states Spécifier l’état du conteneur
-t timeout attend timeout secondes pour l'état désiré
-q, --quiet mode silencieux
-P, --lxcpath=PATH Chemin alternatif du conteneur. Défaut: /var/lib/lxc
-o, --logfile=FILE log dans le fichier spécifié (défaut: pas de log)
-l, --logpriority=LEVEL Priorité des log
-n, --name=NAME Nom du conteneur
--rcfile=FILE Spécifie le fichier de configuration

Exemples

Quitte quand RUNNING est atteind:
lxc-wait -n foo -s RUNNING
Quitte quand RUNNING ou STOPPED est atteind:
lxc-wait -n foo -s 'RUNNING|STOPPED'
^
25 novembre 2016

htmlpdflatexmanmd




lxc.conf-2.0.5

lxc.conf-2.0.5

Fichiers de configuration pour LXC

   La configuration du conteneur est maintenu dans le config stocké dans le répertoire du conteneur. Une configuration de base est générée à la création du conteneur avec des valeurs par défaut recommandée depuis le template choisis, plus d'autres venant du fichier /etc/lxc/default.conf ou ~/.config/lxc/default.conf pour les conteneurs non privilégiés.

Configuration système

   La configuration système est utilisée pour définir des valeurs tels que les chemins de recherche et les paramètres de stockage pour LXC.
^
25 novembre 2016

htmlpdflatexmanmd




lxc.container.conf-2.0.5

lxc.container.conf-2.0.5

Fichiers de configuration de conteneur pour LXC

   Les conteneurs linux sont toujours créé avant être utilisés. Cette création définis un jeu de ressources système à virtualiser/isoler quand un processus utilise le conteneur. Par défaut, les pid, sysv ipc et points de montage sont virtualisés et isolés. Les autres ressources système sont partagées entre les conteneurs, tant qu'ils sont explicitement définis dans la configuration.

Configuration

lxc.include Spécifie un fichier de configuration à inclure
lxc.arch Autoriser un jeu d'architectures pour le conteneur, par exemple lancer des binaires 32bits dans un hôte 64bits
lxc.utsname Spécifie le hostname pour le conteneur
lxc.haltsignal Spécifie un signal utilisé pour arrêter le conteneur (utilisé par lxc-stop) Défaut: SIGPWR
lxc.rebootsignal Spécifie un signal utilisé pour redémarrer le conteneur (utilisé par lxc-stop) Défaut: SIGINT
lxc.stopsignal Spécifie un signal utilisé pour stopper le conteneur (utilisé par lxc-stop) Défaut: SIGKILL
lxc.init_cmd Chemin absolu dans le rootfs du conteneur du binaire à utiliser comme init. Défaut: /sbin/init
lxc.init_uid UID à utiliser dans un namespace user pour init. Défaut: 0
lxc.init_gid GID à utiliser dans un namespace user pour init. Défaut: 0
lxc.ephemeral (bool) Spécifie si un conteneur est détruit à l'arrêt
lxc.network Peut être utilisé sans valeur pour supprimer toutes valeurs précédentes.
lxc.network.type Spécifie le type de réseau à utiliser pour le conteneur. Chaque fois qu'un lxc.network.type est trouvé, une nouvelle configuration réseau commence et permet de définir plusieurs types de réseaux:

        none Le conteneur partage l'espace réseau de l'hôte
        empty Ne créé que l'interface loopback
        veth Créé une paire ethernet virtuel, dont la partie dans l'hôte est attaché à un bridge.
        vlan interface vlan lié avec l'interface
        macvlan lie une interface macvlan
        phys Une interface déjà existante est assignée au conteneur

lxc.network.vlan.id Pour le type vlan, indique le numéro du vlan
lxc.network.flags Àction à prendre pour le réseau (up=active l'interface)
lxc.network.link Spécifie l'interface à utiliser pour le trafic réseau réel (type phys ou macvlan)
lxc.network.mtu mtu max pour cette interface
lxc.network.name Nom de l'interface
lxc.network.hwaddr Adresse mac pour l'interface virtuelle
lxc.network.ipv4 IPv4 de l'interface
lxc.network.ipv4.gateway passerelle de l'interface
lxc.network.ipv6 IPv6 pour l'interface
lxc.network.ipv6.gateway Passerelle ipv6 pour l'interface
lxc.network.script.up script à exécuter après la création/configuration de l'interface (côté hôte).
lxc.network.script.down script à exécuter après la avant de détruire l'interface (côté hôte).
lxc.pts Si définis, le conteneur aura une nouvelle instance de pseudo tty. La valeur spécifie le nombre de tty permis.
lxc.console.logfile Chemin vers un fichier où la sortie de la console est écrite
lxc.console Chemin vers un périphérique auquel la console est attachée. Option dangereuse.
lxc.tty Spécifie le nombre de tty à rendre disponible dans le conteneur
lxc.devttydir Spécifie un répertoire sous /dev sous lequel créer les périphériques de console du conteneur. les pty Unix98 sont créés sur l'hôte et lié dans les périphériques attendus dans le conteneur. Par défaut, il sont liés sur /dev/console et /dev/ttyN. Cela peut empêcher des misesà jours. En changeant d'emplacement sous /dev, ils seront liés symboliquement.
lxc.autodev Par défaut lxc ne créé que quelques liens symboliques dans /dev du conteneur (fd,stdin,stdout,stderr) ais ne créé pas automatiquement les entrées de périphérique. À 1, lxc monte un nouveau tmpfs sous /dev (limité à 500k) et définis les périphériques minimum requis. À 0, empêche de monter et remplir /dev
lxc.kmsg Active /dev/kmrsg comme lien vers /dev/console. Défaut: 0
lxc.mount Les points de montage sont privés au conteneur. Spécifie l'emplacement d'un fichier fstab contenant les informations de montage.
lxc.mount.entry Spécifie un point de montage correspondant à une ligne dans le fichier fstab
lxc.mount.auto Spécifie quels systèmes de fichiers kernel devraient être automatiquement montés:

        proc:mixed /proc est monté en rw, mais /proc/sys et /proc/sysrq-trigger sont montés en ro
        proc:rw /proc est monté en rw
        sys:mixed /sys en ro, /sys/devices/virtual/net en rw
        sys:ro monté en ro
        sys:rw monté en rw
        cgroup:mixed Monte un tmpfs sous /sys/fs/cgroup, créé les répertoires pour toutes les hiérarchies auquel le conteneur est ajouté, créé les sous-répertoires avec le nom du cgroup, et mount le cgroup du conteneur dans ce répertoire. Le conteneur sera capable d'écrire dans son propre cgroup mais pas les parents, vu qu'ils sont remontés en ro
        cgroup:ro tout en ro
        group:rw en rw
        cgroup-full:mixed Un peu plus simplifié que cgroup:mixed, peut laisser fuiter des information dans le conteneur.
        group-full:ro tout en ro
        cgroup-full:rw tout en rw

lxc.rootfs Emplacement du système de fichier racine pour le conteneur. Peut être un fichier image, un répertoire, ou un périphériques block. Non spécifié, partage celui de l'hôte
lxc.rootfs.mount Où monter récursivement lxc.rootfs avant le pivot.
lxc.rootfs.options Options de montage supplémentaires pour rootfs
lxc.rootfs.backend Spécifie le type de backend rootfs à utiliser (dir, zfs,...).
lxc.cgroup.[subsystem name] Spécifie la valeur cgroup à définir.
lxc.cap.drop Capabilities à supprimer dans le conteneur, sans le préfix CAP.
lxc.cap.keep Spécifie la capabilitie à conserver dans le conteneur. none supprime toutes les capabilities
lxc.aa_profile Spécifie le profile apparmor sous lequel le conteneur devrait fonctionner. unconfined désactive apparmor. unchanged conserve le profile du conteneur parent.
lxc.aa_allow_incomplete les profiles apparmor sont basés sur des chemins. Donc des restrictions de fichier nécessitent des restrictions de montage. Cependant, ces restrictions de montage ne sont pas encore implémentées dans le kernel. À 0, le conteneur n'est pas démarré si le kernel n'a pas les fonctions de montage apparmor, donc un regression après une mise à jours kernel sera détectée.
lxc.se_context Spécifie le contexte SELinux sous lequel le conteneur devrait être lancé ou unconfined_t. (ex: system_u:system_r:lxc_t:s0:c22)
lxc.seccomp Spécifie un fichier contenant la configuration seccomp à charger avant que le conteneur démarre.
lxc.id_map Un conteneur peut être démarré dans un namespace user privé avec un mappage. Contient 4 champs séparés par des espaces:

        1 'u', 'g', ou 'b' pour both
        2 L'UID/GID vu dans le namespace
        3 L'UID/GID vu dans l'hôte
        4 Le nombre d'uid/gid consécutifs à mapper

hooks

   Les hooks de conteneur sont des programmes ou des scripts qui peuvent être exécutés à divers moments dans la durée de vie d'un conteneur. Quand un hook est exécuté, des informations sont passées en argument et via les variables d'environnement:

        - Le nom du conteneur
        - Section (toujours 'lxc')
        - Type de hook (ex: 'clone' ou 'pre-mount')
        - Arguments additionnels.
        LXC_NAME Nom du conteneur
        LXC_ROOTFS_MOUNT Chemin du rootfs monté
        LXC_CONFIG_FILE Chemin du fichier de configuration de conteneur
        LXC_SRC_NAME Dans le cas d'un hook clone, c'est le nom du conteneur original
        LXC_ROOTFS_PATH valeur de lxc.rootfs pour le conteneur

lxc.hook.pre-start Un hook à lancer dans l'espace de nom de l'hôte avant que le ttys du conteneur, consoles ou mountages soient effectués.
lxc.hook.pre-mount Un hook à lancer dans l'espace de nom fs du conteneur avant que le rootfs ne soit up. Permet la manipulation du rootfs (ex: fs chiffré)
lxc.hook.mount Un hook à lancer dans l'espace de nom du conteneur après que le montage ait été effectué, mais avant le pivot_root
lxc.hook.autodev Un hook à lancer dans l'espace de nom du conteneur après que le montage ait été effectué, mais avant le pivot_root si lxc.autodev == 1. Permet d'assister le remplissage de /dev
lxc.hook.start Un hook à lancer dans l'espace de nom du conteneur immédiatement après l'exécution du init. Nécessite un programme dans le conteneur
lxc.hook.stop Un hook à lancer dans l'espace de nom de l'hôte après que le conteneur ait été éteind. Pour chaque espace de nom un argument est passé au hook contenant le type de namespace et un fichier qui peut être utilisé pour obtenir un fd vers le namespace correspondant.
lxc.hook.post-stop Un hook à lancer dans l'espace de nom de l'hôte après que le conteneur ait été stoppé.
lxc.hook.clone Un hook à lancer quand le conteneur est cloné.
lxc.hook.destroy Un hook à lancer quand le conteneur est détruit

   Des variables d'environnement sont disponible aux hooks pour fournir des informations de configuration. Toutes les variables ne sont pas valides dans tous les contextes. En particulier, tous les chemins sont relatifs au système hôte et donc non valides durant lxc.hook.start

LXC_NAME Nom du conteneur
LXC_CONFIG_FILE Chemin du fichier de configuration de conteneur
LXC_CONSOLE Chemin de la console de sortie du conteneur si non null
LXC_CONSOLE_PATH Chemin de la console de sortie de log du conteneur si non null
LXC_ROOTFS_MOUNT Chemin du rootfs monté dans l'hôte
LXC_ROOTFS_PATH Valeur de lxc.rootfs pour le conteneur
LXC_SRC_NAME Dans le cas d'un hook clone, c'est le nom du conteneur original
LXC_TARGET Seulement pour le hook stop. Vaut stop ou reboot
LXC_CGNS_AWARE Non définis, cette version de lxc ne gère pas les namespaces cgroup. Ne garantit pas que ces namespaces sont activés dans le kernel.

lxc.loglevel Niveau de log de 0 (trace) à 8 (fatal)
lxc.logfile Fichier où logger les infos
lxc.start.auto (bool) Indique si le conteneur devrait être auto-démarré.
lxc.start.delay Délai d'attente avant que le conteneur suivant ne soit démarré
lxc.start.order Un entier utilisé pour trier les conteneurs durant l'auto-démarrage
lxc.monitor.unshare Si non 0, le namespace de montage sera non partagé avec l'hôte avant l'initialisation du conteneur (avant le hook pre-start). Nécessite CAP_SYS_ADMIN.
lxc.group Clé multivalué pour placer le conteneur dans un groupe.

lxc.environment Permet de passer des variables d'environnement au conteneur. Noter que ces variables sont visibles dans l'hôte dans /proc/PID/environ

Exemples de configuration

Exemple de configuration réseau:
lxc.utsname = myhostname
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597

uid/gid mapping
lxc.id_map = u 0 100000 10000
lxc.id_map = g 0 100000 10000

cgroup
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw

Exemple de configuration complexe:
lxc.utsname = complex
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588
lxc.network.type = macvlan
lxc.network.flags = up
lxc.network.link = eth0
lxc.network.hwaddr = 4a:49:43:49:79:bd
lxc.network.ipv4 = 10.2.3.4/24
lxc.network.ipv4 = 192.168.10.125/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596
lxc.network.type = phys
lxc.network.flags = up
lxc.network.link = dummy0
lxc.network.hwaddr = 4a:49:43:49:79:ff
lxc.network.ipv4 = 10.2.3.6/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3297
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
lxc.mount = /etc/fstab.complex
lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
lxc.rootfs = /mnt/rootfs.complex
lxc.cap.drop = sys_module mknod setuid net_raw
lxc.cap.drop = mac_override
^
25 novembre 2016

htmlpdflatexmanmd




lxc.system.conf-2.0.5

lxc.system.conf-2.0.5

Fichiers de configuration du système LXC

   Ce fichier est localisé dans /etc/lxc/lxc.conf ou ~/.config/lxc/lxc.conf. Ce fichier est utilisé pour définir des valeurs telles que les chemins de recherche par défaut et les paramètres de stockage pour LXC.

lxc.lxcpath Emplacement dans lequel tous les conteneur sont stockés
lxc.default_config Emplacement de la configuration du conteneur par défaut
lxc.cgroup.use liste de cgroup à définis. Si aucun n'est définis, tous les contrôleurs sont utilisés
lxc.cgroup.pattern Chaîne utilisée pour générer le chemin cgroup (ex: lxc/%n)
lxc.bdev.lvm.vg Nom du volume groupe par défaut
lxc.bdev.lvm.thin_pool nom du pool thin par défaut
lxc.bdev.zfs.root Nom du root ZFS par défaut

^
25 novembre 2016

htmlpdflatexmanmd




lxc.usernet-2.0.5

lxc.usernet-2.0.5

Administration de réseau utilisateur non-privilégié

   /etc/lxc/lxc-usernet contrôle les limites du programme lxc-user-nic pour les interfaces réseau qu'un utilisateur non-privilégié peut créer. Le fichier de configuration consiste d'entrées sous la forme:

  user|@group type bridge number

        user|@group username ou nom du groupe auquel l'entrée s'applique
        type Type de réseau autorisé. Seule veth est supporté actuellement
        bridge nom du bridge auquel les interfaces peuvent être attachés
        number Nombre d'interfaces réseau du type donné que l'utilisateur/groupe peut attacher au bridge donné.

^
10 octobre 2011

htmlpdflatexmanmd




L'echo

L'echo



   Les delay et les écho répètent un son en un court laps de temps après la première fois. L'effet le plus simple (et le plus vieux) est l'écho a bande - une simple répétition 100 ms après le signal initial. L'écho a bande fut notamment beaucoup utilise sur la voix d'Elvis Presley et sur les pistes de guitare Rockabilly. L'écho a bande délivre de multiple répétions lorsque le signal de sortie est re-injecte en entrée. Une seule répétition se transforme en de multiples a chaque fois plus faible et plus étouffée que la précédente. Cet étouffement est caractéristique des enregistrements analogiques a bande. L'écho a bande et le delay numérique sont tous les deux très utiles, mais différents. L'écho a bande possède un son plus chaud se détachant du son original ; le delay numérique délivre une copie parfaite du signal initial. Avec les effets d'écho, les répétitions tombent en rythme avec la musique. Il est important de faire coïncider les répétitions en rythme avec la musique.

   Dans la nature, l'écho se manifeste des que l'on se trouve en présence d'une paroi réfléchissante ; il faut au moins deux surfaces en regard pour qu'apparaisse un écho. Pour que notre oreille perçoive une répétition audible, la durée de ce retard doit être d'au moins 20 ms - soit 1/50e de seconde. Cela correspond, pour un son, a un parcours de 6.8 mètres. Quand on passe a une échelle plus petite, les dimensions d'une pièce par exemple, les rebonds successifs des sons sur les paries ne sont plus perçus séparément par l'oreille, qui les 'fusionne': les échos sont devenus réverbération.

   Il est loin le temps ou, pour obtenir un écho, on avait recours a un magnétophone équipé d'un varispeed pour faire varier la durée entre les répétitions, ou, dans le meilleur des cas, a une 'chambre d'écho', sorte de magnétophone dédié, ou une boucle de bande passait devant plusieurs têtes d'écartement réglable. Dispositif perfectionné par Pink Floyd, qui n'hésita pas, pour les longs délais de Us And Them, sur 'Drak Side Of The Moon', a faire rebondir le signal sur plusieurs pistes d'un 8 pistes varispeedé, cumulant ainsi les retards procurés par chacune. Citons aussi Jean-Michel Jarre, qui inséra des réducteurs de bruits Dolby A sur ses Revox pour 'Oxygène' ou 'Equinox'.

   Du temps des delays a bande magnétique, chaque écho représentait une génération d'enregistrement/lecture analogique: autrement dit, la bande passante rétrécissait, le souffle augmentait. Un phénomène qui se produit également en extérieur, les molécules d'air ayant tendance a étouffer les aigus. En numérique, cet effet est simule en utilisant un filtre passe bas et passe haut appelé Damping.

   Le plug-in Karlette de Steinberg (inclut dans Cubase), est une simulation d'un écho a bande équipée de 4 têtes, chaque tête possédant ses propres réglages: le temps de delai (retard), le volume, la panoramique (gauche/droite), le feedback (nombre de répétitions) et un damp pour finir de simuler le mieux possible le son caractéristique des chambres d'écho a bandes.

Le plugin Karlette

^
10 octobre 2011

htmlpdflatexmanmd




L'expander

L'expander

l'effet expander

   L'expander est tout simplement l'effet inverse de la compression. Le compresseur permet de diminuer la dynamique, l'expander lui, redonne de la dynamique aux crêtes du signal. Il fonctionne comme un compresseur mais avec la courbe vers le haut. Au delà d'un seuil fixé, le niveau du signal est expansé (augmenté). Sont utilisation est souvent de redonner de la dynamique à un signal trop compressé. Ce type d' expander décrit est un expander de signaux fort. Il existe aussi un expander pour les signaux faibles, qui lui à un rôle d'atténuer le bruit de fond à mesure que le niveau du signal descend. Il est utilisé pour remplacer un noige gate, dont a coupure et trop abrupte au niveau du seuil, et permet également de conserver un minimum de bruit de fond, ce qui peut être désiré dans certains cas.

   L'expander à de multiple application. Il n'est pas un effet primordiale mais peut sauver un enregistrement qui a été trop compressé et sonne 'plat'. Certain compresseur et noise gate peuvent se transformer en expander (Wave C1). Un compresseur devient expander quand le ratio est inférieur à 1:1 (ex: 0.5:1). Un noise gate devient expander quand le seuil de la porte n'est plus un 'interrupteur' mais devient réellement un seuil doté d'un ratio vers le bas.

l

^
18 mars 2010

htmlpdflatexmanmd




Magic SysRq key

Magic SysRq key

Touches Magic SysRq key

   Les magic SysRq key sont une fonctionnalité du noyau Linux qui permet par une combinaison de touches de lancer des commandes de bas niveau. Elle doit être activée à la compilation du noyau.

  La principale utilité de cette fonctionnalité est de pouvoir redémarrer un système bloqué sans corrompre le système de fichier.

  Sur un ordinateur x86, la combinaison utilisée est formée des 3 touches : Alt+Imprim écran ou Syst et une autre touche qui détermine l'action à effectuer : r « récupère » le clavier, approprié le plus souvent par le système de fenêtrage X Window.

k tue tous les processus de la console virtuelle active
b redémarre immédiatement le système. Cette fonctionnalité peut provoquer des pertes de données : ce qui est en mémoire cache n'est pas écrit sur les disques ; cette fonctionnalité est beaucoup plus radicale que le Ctrl-Alt-Delete de Microsoft ou que le Ctrl+Alt+Del de Linux
c redémarre le processus kexec et affiche le message du crash
s synchronise tous les systèmes de fichier montés Cette fonctionnalité peut être très utile si on doit faire un arrêt rapide de l'ordinateur (arrêt électrique ou logiciel) : elle permet de ne pas perdre les données en mémoire cache
o arrête le système
u passe tous les systèmes de fichier montés en lecture seule
p affiche les registres courants et les flags dans la console
t affiche la liste des différentes tâches actives ainsi que des informations pour chacune
m affiche les informations relatives à la mémoire dans la console (dans cette situation, le noyau n'est pas en mesure de tenir compte de la disposition des touches sur le clavier, et interprète les frappes comme si elles étaient réalisées sur un clavier QWERTY. Dans le cas de l'utilisation d'un clavier AZERTY, il faut donc appuyer sur ',' la touche qui se trouve à l'emplacement du m du clavier QWERTY)
de 0 à 9 permet de définir le type de messages du noyau qui s'affichent dans la console
f appelle la fonction oom_kill, elle tue le processus qui consomme toute la mémoire disponible
e envoie le signal SIGTERM à tous les processus excepté init
i envoie le signal SIGKILL à tous les processus excepté init
l envoie le signal SIGKILL à tous les processus init compris

   Toutes autres touches non assignées à une commande affiche une aide sommaire dans la console.

Modifications

   Les différentes méthodes pour modifier cette fonctionnalité sont

  - méthode la plus rapide : dans le fichier sysctl.conf, interdire ces fonctionnalités en mettant kernel.sysrq=0. Dans ce cas, le contenu du fichier /proc/sys/kernel/sysrq sera '0'.

  - Méthode plus longue, mais plus rigoureuse : Avant de générer un noyau, paramétrer le booléen CONFIG_MAGIC_SYSRQ à false dans les paramètres kernel hacking

  - Méthode de loin la plus rigoureuse, mais aussi la plus complexe et la plus longue : Il peut être tentant de supprimer les fonctionnalités trop dangereuses, et de laisser celles qui peuvent être utiles dans certains cas extrêmes

  Pour supprimer les fonctions jugées trop dangereuses : Avant de générer le noyau, il faut modifier un des fichiers sysrq.c des sources du noyau, Il y a plusieurs fichiers sysrq.c, il faut choisir celui correspondant au type de processeur concerné.

Redémarrer proprement un système bloqué

Pour redémarrer un système Linux qui ne répond plus, il faut utiliser la séquence de touches suivante :
1. unraw — récupérer le contrôle du clavier X ;
2. terminate — envoyer SIGTERM a tous les processus, pour leur permettre de s'arrêter proprement ;
3. kill — envoyer SIGKILL a tous les processus, pour les forcer à s'arrêter immédiatement ;
4. sync — synchroniser les disques, écrire le contenu du tampon sur le disque ;
5. unmount — remonter tous les systèmes de fichiers en lecture seule, pour ne pas devoir lancer fsck au redémarrage ;
6. boot.

   Il faut commencer par maintenir simultanément les touches Alt et Syst, puis l'une après l'autre les touches dans l'ordre donné, en attendant au moins deux secondes entre chaque touche.

  Cela permet de démonter correctement les systèmes de fichiers, ce qui évite de risquer des corruptions de données et de devoir exécuter fsck au redémarrage. De plus les processus ont du temps pour enregistrer des sauvegardes d'urgence le cas échéant.
^
17 janvier 2012

htmlpdflatexmanmd




mailstat

mailstat

Parcourt un fichier $LOGFILE généré par procmail et affiche un sommaire sur les messages délivrés à tous les répertoires

   mailstat parcourt un fichier $LOGFILE généré par procmail et affiche un sommaire sur les messages délivrés à tous les répertoires (taille totale, taille moyenne, nombre de messages). $LOGFILE est tronqué à 0, à moins que -k soit spécifié. si un mail est arrivé, le code de sortie est 0, sinon 1.

OPTIONS

-k Conserve le logfile intacte
-l Format d'affichage long
-m Fusionne les erreurs sur une seule ligne
-o Utilise l'ancien fichier de log
-t Format d'affichage terse
-s Silencieux si aucun mail
^
11 septembre 2016

htmlpdflatexmanmd




mailto.conf

mailto.conf

Fichier de configuration pour le notificateur email de cups

   Le fichier mailto.conf définis le serveur de mail local et les préférences de notification par mail pour CUPS

Directives

Cc cc-address@domain.com Spécifie un destinataire additionnel
From from-address@domain.com Émetteur des notifications
Sendmail sendmail command and options Commande sendmail à utiliser pour envoyer les mails.
SMTPServer servername Serveur SMTP pour envoyer les mail.
Subject subject-prefix Spécifie une chaîne préfixe pour la ligne sujet.
^
30 janvier 2014

htmlpdflatexmanmd




man

man

Man est le pager de manuel système. Chaque page donné en argument est normalement le nom du programme, utilitaire ou fonction.

Liste des sections

1 Programmes exécutables ou commandes shell
2 appels système (fonctions fournies par le kernel)
3 Appel de librarie
4 Fichiers spéciaux généralement trouvés dans /dev
5 Formats de fichier et conventions
6 Jeux
7 Divers
8 Commandes d'administration système
9 Routine kernel non standard

   Les sections conventionnels incluent:

  NAME, SYNOPSIS, CONFIGURATION, DESCRIPTION, OPTIONS, EXIT STATUS, RETURN VALUE, ERRORS, ENVIRONNEMENT, FILES, VERSIONS, CONFORMING TO, NOTES, BUGS, EXAMPLE, AUTHORS et SEE ALSO.

  Les conventions suivantes s'appliquent à la section synopsis et peuvent être utilisées comme guide dans les autres sections:

Texte en gras taper exactement comme affiché
texte italique Remplace avec l'argument approprié
[-abc] ces arguments sont optionnels
-a|-b Ne peuvent pas être utilisés ensemble
argument ... L'argument est répétable
[expressions] ... Toutes l'expression est répétable

OPTIONS Générales

-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath
-d, --debug Mode debug
-D, --default Réinitialise les paramètres à leur valeurs par défaut
--warnings[=warnings] Active les alertes de groff.

Opérations du mode principal

-f, --whatis Equivalent à whatis
-k, --apropos Equivalent à apropos
-K, --global-apropos Recherche du texte dans toutes les pages de manuel.
-l, --local-file Active le mode local. Recherche dans les fichiers locaux au lieu des manuels système.
-w, --where, --location N'affiche pas le man, mais affiche l'emplacement des fichiers source nroff
-W, --where-cat, --location-cat N'affiche pas le man, mais affiche l'emplacement des fichiers cat
-c, --catman Utilisé par le programme catman
-R encoding, --recode=encoding Spécifie l'encodage pour l'affichage des manuels

Recherche de pages de manuel

-L locale, --locale=locale Remplace l'appel setlocale(3)
-m system[,...], --systems=system[,...] Permet d'accéder à des page de manuel d'autres OS.
-M path, --manpath=path Spécifie un manpath alternatif à utiliser.
-S list, -s list, --sections=list Liste de sections de manuel à rechercher.
-e sub-extension, --extension=sub-extension sur les systèmes qui incorporent beaucoup de pages de manuel, il peut y avoir plusieurs manuels ayant le même nom. exemple tcl peut avoir exit(3), on peut l'appeler avec exit(3tcl). *tcl permet de restreindre les recherches.
-i, --ignore-case Insensible à la casse lors de la recherche de pages de man
-I, --match-case Recherche sensible à la casse
--regex Permet de spécifier que la recherche est un regex. implique a
--wildcard Affiche toutes les pages avec n'importe quelle partie dans le nom ou le contenu matchent chaque argument page. implique -a
--names-only si --regex ou --wildcard, match uniquement les nom des pages, pas la description, comme avec whatis
-a, --all Par défaut, man va quitter après avoir affiché les pages de man qu'il a trouvé
-u, --update effectue une vérification de consistance 'inode level' sur son cache.
--no-subpages Support pour les page de manuel qui ont des sous commandes. ex:

        man -aw git diff
        /usr/share/man/man1/git-diff.1.gz
        man -aw --no-subpages git diff
        /usr/share/man/man1/git.1.gz
        /usr/share/man/man3/Git.3pm.gz
        /usr/share/man/man1/diff.1.gz

Contrôler la sortie formatée

-p pager, --pager=pager Spécifie le pager à utiliser. ne peut pas être utilisé avec -f ou -k
-r prompt, --prompt=prompt si une version récente de less est utilisé comme pager, tente de définir son prompt et certaines options sensibles.
-7, --ascii Affiche en pure ascii(7)
-E encoding, --encoding=encoding Génère la sortie pour un jeu de caractères tel que UTF-8
--no-hyphenation, --nh Désactive la césure automatique
--no-justification, --nj Désactive la justification automatique
-p string, --preprocessor=string Spécifie la séquence de pré-processeurs à lancer avant nroff ou groff. ex: eqn (e), grap (g), pic (p), tbl (p), tbl (t), vgrind (v), refer (r). zsoelim est toujours lancé au tout début.
-t, --troff Utilise groff -mandoc pour formater la page de manuel.
-T[device], --troff-device[=device] Change la sortie de groff. implique -t. ex: dvi, latin1, ps, utf8, X75 et X100
-H[browser], --html[=browser] Force groff à produire une sortie HTML.
-X[dpi], --gxditview[=dpi] Affiche la sortie de groff en utilisant gxditview. dpi peut être 75, 75-12, 100 ou 100-12.
-Z, --ditroff Groff utilise un post-processeur pour produire une sortie utilisable pour le périphérique choisi.

Exemples

Affiche la page de manuel de ls
man ls
Affiche successivement, toutes les pages de manuel intro disponibles.
man -a intro
Formatte le manuel référencé par l'alias en format troff par défaut et le pipe dans une imprimante nommée ps
man -t alias | lpr -Pps
Décompress et formatte en dvi
man -l -Tdvi ./foo.1x.gz › ./foo.1x.dvi
Recherche la description courte et les noms de page de manuel pour le regex donné. (idem à apropos -r printf)
man -k printf
Recherche les pages de manuel référencés par smail et affiche les descriptions courtes. (idem à whatis -r smail)
man -f smail

Variables d'environnement

MANPATH Chemin de recherche pour les pages de manuel
MANROFFSEQ Détermine le jeu de préprocesseurs à utiliser
MANSECT Liste de sections dans lesquels rechercher et dans quel ordre.
MANPAGER Pager à utiliser (défaut: pager -s)
PAGER Pager à utiliser (défaut: pager -s)
MANLESS Avec less comme pager, copie cette valeur telle quelle dans $LESS
BROWSER Liste de commandes utilisées pour lancer un navigateur web.
SYSTEM Si le système a accès à des pages de manuel d'autres OS, permet de les inclure
MANOPT Parsé avant la ligne de commande pour des options spécifiques
MANWIDTH Longueur de ligne (défaut: 80)
MAN_KEEP_FORMATTING les caractères de formattage définis sont affichés.
MAN_KEEP_STDERR non vide, permet d'afficher les erreurs dans la sortie
LANG Utilisé pour rechercher les locales
LC_MESSAGES Utilisé pour rechercher les locales.

Fichiers

/etc/manpath.config Fichier de configuration de man-db
/usr/share/man Contient les manuels
/usr/share/man/index.(bt|db|dir|pag) DB cache pour l'index global.
/var/cache/man/index.(bt|db|dir|pag) DB cache pour l'index global. FHS compliant
^
01 février 2014

htmlpdflatexmanmd




mandb

mandb

Créé ou met à jours les caches d'index des pages de manuel

Caches

   mandb peut être compilé pour supporter les types de base de données suivantes:

        Berkeley db index.bt
        GNU gdbm index.db
        UNIX ndbm index.(dir|pag)

OPTIONS

-d, --debug Mode debug
-q, --quiet mode silencieux
-s, --no-straycats Ne perd pas de temps à rechercher ou ajouter dans les db pour les fichiers égarés.
-p, --no-purge Ne perd pas de temps à vérifier les pages supprimées ni les purger dans les bases.
-c, --create Supprime toute base existante puis les recréé au lieu de les mêttre à jours.
-u, --user-db Créer une base user uniquement
-t, --test Effectue une vrification sans modification
-f, --filename Met à jours uniquement les entrées avec le nom donné.
-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath

Fichiers

/etc/manpath.config Fichier de configuration de man-db
/var/cache/man/index.(bt|db|dir|pag) DB cache pour l'index global. FHS compliant
/usr/man/index.(bt|db|dir|pag) db cache traditionnel
/var/catman/index.(bt|db|dir|pag) db cache compliant FSSTND
^
01 février 2014

htmlpdflatexmanmd




manpath

manpath

Détermine les chemins de recherche pour les pages de manuel

OPTIONS

-q, --quiet mode silencieux
-d, --debug Mode debug
-c, --catpath Une fois le manpath déterminé, chaque élement du path est convertit à son catpath relatif
-g, --global Produit un manpath consistant de tous les paths nommés 'global' dans le fichier de configuration man-db
-m system[,...], --systems=system[,...] Permet d'accéder à des page de manuel d'autres OS.
-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath

Variables d'environnement

MANPATH Chemin de recherche pour les pages de manuel
SYSTEM Si le système a accès à des pages de manuel d'autres OS, permet de les inclure

Fichiers

/etc/manpath.config Fichier de configuration de man-db
^
01 février 2014

htmlpdflatexmanmd




manpath.config

manpath.config

Fichier de configuration pour manpath

Format

MANDATORY_MANPATH manpath_element manpaths que tout $MANPATH automatiquement généré devrait contenir (généralement inclus /usr/man)
MANPATH_MAP path_element manpath_element Pour tout path_element trouvé dans $PATH, map manpath_element dans $MANPATH
MANDB_MAP manpath_element [ catpath_element ] Indique quel manpath sont traités comme manpath système et optionnellement où leurs fichiers cats devraient être stockés. (généralement /usr/man, /usr/local/man et /usr/X11R6/man)
DEFINE key value Définis divers variable de configuration. Peut inclure des variable pour le pager et divers chemins vers des programmes tel que grep et tbl.
SECTION section ... Défini l'ordre dans lequel les sections de manuel devraient être recherchés. (défaut: 1 n l 8 3 0 2 5 4 9 6 7)
MINCATWIDTH width Si la largeur du terminal est inférieur à la largeur spécifiée, les pages cat ne seront pas créés ni affichés. (défaut: 80)
MAXCATWIDTH width Si la largeur du terminal est supérieur à la largeur spécifiée, les pages cat ne seront pas créés ni affichés.
CATWIDTH width Si non-zéro, les pages cat seront formatés à la largeur donnée
NOCACHE Empêche man de créer les pages cat automatiquement.
^
17 janvier 2012

htmlpdflatexmanmd




mbox

mbox

Format pour le stockage des mails

   Un fichier mbox est un fichier texte contenant un nombre arbitraire de mails. Chaque mail consiste d'un postmark, suivis par un mail formaté en accord avec la RFC822 et rfc2822. Le format de fichier est orienté ligne. Les lignes sont séparées par le caractère acsii 10

   Une ligne postmark consiste de 4 caractères "From", suivi par un espace, suivi par l'adresse de l'émetteur du message, suivi par un espace blanc et suivi par la date. Cette ligne est souvent appelé la ligne From_

   L'adresse de l'émetteur est addr-spec comme définis dans la RFC2822. La date est au format date-time comme sortie par asctime(3). Exemple:

  From uubu@uubu.fr Wed Jan 04 11:29:45 2012

  Pour éviter les confusions avec une ligne dans un mail commençant par "From ", ils doivent être mis entre "".

^
08 mai 2017

htmlpdflatexmanmd




mcstransd

mcstransd

Service MCS. Traduit les labels MCS/MLS sous forme lisible

OPTIONS

-F Ne lance pas en tâche de fond
^
22 mai 2016

htmlpdflatexmanmd




md

md

Pilote Multiple Device

   Le pilote md fournis des périphériques virtuels qui sont créés depuis un ou plusieurs périphériques indépendants. Cet array de périphériques contient souvent une redondance et les périphériques sont souvent des périphériques disques.

   md supporte les RAID niveau 1 (mirroring), 4 (striped avec parité), 5 (striped avec parité distribué), 6 (striped avec double redondance), et 10 (striped et mirroré). Si un périphérique échoue en utilisant un de ces levels, l'array contitue de fonctionner.

   md supporte également les configurations pseudo-raid (non-redondants) incluant le raid0 (striped array), linear (array sérialisé), multipath (un jeu de différentes interfaces vers le même périphérique) et faulty (une couche sur un simple périphérique dans lequel les erreurs sont injectés).

Métadonnées MD

   Chaque périphérique dans un array peut avoir des métadonnées stockées dans le périphérique. Ces métadonnées sont parfois appelés superblock. Les métadonnées enregistrent des informations sur la structure et l'état de l'array pour pouvoir ré-assembler l'array après un arrêt.

   Depuis la version 2.6.10 du Kernel, md fournis le support pour 2 formats différents de métadonnées, et d'autres formats peuvent être ajoutés.

   Le format commun, la version 0.90, a un superblock qui fait 4ko et est écrit dans un block aligné sur 64Ko qui démarre au plus 64K et moins de 128k de la fin du périphérique (ex, pour obtenir l'adresse du superblock arrondir la taille du périphérique à un multiple de 64K, puis soustraire 64K). La taille disponible pour chaque périphérique est la quantité d'espace avent le superblock, dont entre 64K et 128K est perdu quant un périphérique est incorporé dans un array MD. Ce superblock stock les champs multi-octet de manière indépendante su processeur, pour que les array puissent être déplacés entre des machines de différents processeurs.

   Le nouveau format, version 1, a un superblock qui fait normalement 1K de long, mais peut faire plus. Il est normalement stocké entre 8K et 12k de la fin du périphérique, sur un alignement 4K, bien de des variante peuvent être stockées au début du disque (version 1.1) ou à 4K du début du périphérique (version 1.2). Ce format de métadonnées stocke les données multi-octets dans un format indépendant du processeur et supporte des centaines de périphériques contre 28 pour les versions 0.90.

   Les métadonnées contiennent, entre autre:

LEVEL Le type d'array
UUID Un identifiant 128bits unique qui identifie l'array

   Quand une versions 0.90 est redéfinie (ex, ajout de péripériques dans un raid 5), le numéro de version est temporairement mis à 0.91. Celà permet de s'assurer que le processus s'est terminé correctement.

Métadonnées sans arrays

   Bien qu'il est recommandé de créer des array avec des superblocks pour qu'ils puissent être réassemblés correctement, il y a certaines circonstances où un array sant superblock est préférrable:

LEGACY ARRAY Les première versions du pilote md ne supportent que les configuration LINEAR et RAID0 et n'utilise pas de superblock (qui est moins critique dans ces configuration).
FAULTY Ce type ne tire aucun bénéfice d'un superblock
MULTIPATH Il est souvent possible de détecter les périphériques qui sont des chemins différents du même stockage directement au lieu d'avoir un superblock distinct. Dans ce cas, un array multipath sans superblock a du sens.
RAID1 Dans certaines configurations il peut être souhaitable de créer une configuration raid1 sans superblock, pour maintenir l'état de l'array n'importe où.

Métadonnées externes

   Depuis le kernel 2.6.28, le pilote md supporte les arrays avec des métadonnées externe. C'est à dire que les métadonnées ne sont pas gérés par le kernel mais par un programme de l'espace utilisateur. Cela permet de supporter différents formats de métadonnées.

   md est capable de communiquer avec le programme externe via différents attributs sysfs pour qu'il puisse effectuer les changements appropriés - par exemple, pour marquer un périphérique comme étant en faute. Si nécessaire, md attend que le programme prenne connaissance de l'événement en écrivant dans un attribut sysfs. la man mdmon(8) contient des détails sur cette intéraction.

   Conteneurs

LINEAR

   Un array LINEAR sérialise simplement l'espace disponible de chaque lecteur pour former un grand disque virtuel. L'avantage de cet arrangement par rapport au raid0 est que l'array peut être configuré plus tard sans perturber les données dans l'array.

RAID0

   Un raid0 est également connu comme array striped. Il est configuré à la création avec un taille de shunk qui doit être une puissance de 2, et au moins 4 KiO. Le premier chunk est assigné au premier disque, le second au deuxième disque, etc. Cette collection de chunk forment un stripe. Si les périphériques dans l'array n'ont pas tous la même taille, une fois le plus petit disque remplis, le pilote collecte les chunks en stripes plus petits.

RAID1

   Un raid1 est également connus comme un jeu mirroir. Une fois initialisé, chaque périphérique dans un raid1 devrait avoir la même taille. Si ce n'est pas le cas, seul la quantité d'espace disponible sur le plus petit périphérique est utilisé.

   Noter que la lecture balancé faite par le pilote n'améliore pas les performance comme un raid0. Les périphériques individuels dans un raid1 peuvent être marqués 'write-mostly'. Ces lecteurs sont exclus de la lecture balancée et seront lus seulement s'il n'y a pas d'autre option. Peut être utile pour des périphériques connectés sur un lien lent.

RAID4

   Un raid4 est similaire à un RAID0 avec un périphérique suplémentaire pour stocker la parité. Ce périphérique est le dernier des périphériques actifs dans l'array. à la différence de raid0, raid4 nécessite également que tous les stripes disques, donc l'espace supplémentaire sur les disques plus grand que le plus petit est perdu.

   Cela permet à l'array de continuer de fonctionner si un disque échoue.

RAID5

   Similaire au raid5, mais les blocks de parités pour chaque stripe est distribué sur tous les périphériques. Cela permet plus de parallelisme dans les écritures. Il y a également plus de parallélisme pendant les lecture.

RAID6

   Similaire au raid5, mais peut gérer la perte de 2 périphériques sans perte de données. Nécessite N+2 disques. Les performances d'un raid6 est légerement inférieur à un raid5 en mode simple disque d'erreur, et très lent pour un mode double disque d'erreur.

RAID10

   Fournis une combinaison de raid1 et raid0, et parfois appelé raid1+0. Chaque block de données est dupliqué un certain nombre de fois, et la collection résultante de ces blocks sont distribués sur plusieurs disques.

   En configurant un raid10, il est nécessaire de spécifier le nombre de réplicas de chaque block de données qui sont requis (généralement 2) et si leur layout est 'near', 'far' ou 'offset'

Exemples de layout raid10

   Les exemples ci-dessous visualisent la distribution de chunk dans les périphériques sous-jacents pour le layout.

   Pour simplifier il est assumé que la taille des chunks est égal à la taille des blocks des périphériques sous-jacents tout comme ceux du périphérique RAID10 exporté par le kernel.

   Les nombres décimaux (0, 1, 2, ...) sont les chunks du RAID10 et donc également des blocks et adresse de blocks du périphérique raid exporté

Layout "near" Quand des réplicas 'near' sont choisis, les copies multiples d'un chunk donné sont disposés consécutivement (aussi proche les uns des autres que possible) dans les stripes de l'array.

Avec un nombre paire de périphériques, ils sont probablement être au même offset sur les différents périphériques. C'est le raid1+0 classique; c'est à dire 2 groupes de périphériques mirrorés. Dans l'exemple ci-dessous, les groupes de périphériques #1 / #2 et #3 / #4 sont des raid1, formant un raid0.
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____0_____|_____1_____|_____1_____|
|0x01_|_____2_____|_____2_____|_____3_____|_____3_____|
|...__|____...____|____...____|____...____|____...____|
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|
|...__|____...____|____...____|____...____|____...____|
|0x80_|____254____|____254____|____255____|____255____|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
________\- - - - -v- - - - -/___\- - - - -v- - - - -/_
________________RAID1___________________RAID1_________
________\- - - - - - - - - - -v- - - - - - - - - - -/_
____________________________RAID0_____________________

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___0____|___1____|___1____|___2____|
|0x01_|___2____|___3____|___3____|___4____|___4____|
|...__|__...___|__...___|__...___|__...___|__...___|
|_:___|___:____|___:____|___:____|___:____|___:____|
|...__|__...___|__...___|__...___|__...___|__...___|
|0x80_|__317___|__318___|__318___|__319___|__319___|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

Layout "far" Quand les réplicas far sont choisis, les copies d'un chunk sont disposés assez éloignés (aussi loin qu'il est raisonnablement possible)

   D'abord une séquence complète de tous les blocks de données (c'est à dire la données vues sur le périphériques blocks raid10 exporté) sont stripé sur les périphériques Puis une autre séquence (shift) complète de tous les blocks de données; et ainsi de suite

   Le shift nécessaire pour empêcher de placer les copies du même chunks sur les même périphériques est actuellement une permutation cyclique avec l'offset 1 de chaque stripes dans une séquence complet de chunks

L'offset 1 est relatif à la séquence complète précédente de chunks, donc en cas de plus de 2 copies par chunk on obtient les offsets suivantes:
1. Séquence complète de chunks: offset = 0
2. Séquence complète de chunks: offset = 1
3. Séquence complète de chunks: offset = 2
...
n. complete sequence of chunks: offset = n-1

Exemple avec 2 copies par chunk et un nombre paire de périphériques:
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____1_____|_____2_____|_____3_____|_\
|0x01_|_____4_____|_____5_____|_____6_____|_____7_____|_›_[#]
|...__|____...____|____...____|____...____|____...____|_:
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|_:
|...__|____...____|____...____|____...____|____...____|_:
|0x40_|____252____|____253____|____254____|____255____|_/
|0x41_|_____3_____|_____0_____|_____1_____|_____2_____|_\
|0x42_|_____7_____|_____4_____|_____5_____|_____6_____|_›_[#]~
|...__|____...____|____...____|____...____|____...____|_:
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|_:
|...__|____...____|____...____|____...____|____...____|_:
|0x80_|____255____|____252____|____253____|____254____|_/
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___1____|___2____|___3____|___4____|_\
|0x01_|___5____|___6____|___7____|___8____|___9____|_›_[#]
|...__|__...___|__...___|__...___|__...___|__...___|_:
|_:___|___:____|___:____|___:____|___:____|___:____|_:
|...__|__...___|__...___|__...___|__...___|__...___|_:
|0x40_|__315___|__316___|__317___|__318___|__319___|_/
|0x41_|___4____|___0____|___1____|___2____|___3____|_\
|0x42_|___9____|___5____|___6____|___7____|___8____|_›_[#]~
|...__|__...___|__...___|__...___|__...___|__...___|_:
|_:___|___:____|___:____|___:____|___:____|___:____|_:
|...__|__...___|__...___|__...___|__...___|__...___|_:
|0x80_|__319___|__315___|__316___|__317___|__318___|_/
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

   Avec [#] étant la séquence complète de chunks et [#]~ la permutation cyclique avec l'offset 1 (dans le cas de plus de 2 copies par chunk ce serait ([#]~)~, (([#]~)~)~, ...)

   L'avantage de ce layout est que MD peut facilement propager les lectures séquentiellement sur le périphériques, les rendant similaire au raid0 en terme de vitesse. Les écriture en revenche sont plus lents

Layout offset Quand des réplicas offset sont choisis, toutes les copies d'un chunk donné sont stripé consécutivement (offset par la longueur du stripe avec chacun d'entre eux) sur les périphériques.

   Expliqué en détail, les chunks consécutif sont stripés sur les périphériques, immédiatement suivis par une copie décalée de ces chunk. Ce motif se répète pour tous les chunks consécutifs suivant.

   Le shift est nécessaire pour empêcher de placer les copies des même chunks sur le même périphérique avec une permutation de 1 de chaque copie stripée de chunks consécution.

L'offset 1 est relatif à la copie précedente, donc dans le cas de plus de 2 copies par chunk on obtient:
1. chunks consécutifs ‹nombre de périphériques›: offset = 0
2. chunks consécutifs ‹nombre de périphériques› = 1
3. chunks consécutifs ‹nombre de périphériques› = 2
...
n. chunks consécutifs ‹nombre de périphériques› = n-1

Exemple avec 2 copies par chunk et un nombre paire de périphériques:
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____1_____|_____2_____|_____3_____|_)_AA
|0x01_|_____3_____|_____0_____|_____1_____|_____2_____|_)_AA~
|0x02_|_____4_____|_____5_____|_____6_____|_____7_____|_)_AB
|0x03_|_____7_____|_____4_____|_____5_____|_____6_____|_)_AB~
|...__|____...____|____...____|____...____|____...____|_)_...
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|___:
|...__|____...____|____...____|____...____|____...____|_)_...
|0x79_|____251____|____252____|____253____|____254____|_)_EX
|0x80_|____254____|____251____|____252____|____253____|_)_EX~
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___1____|___2____|___3____|___4____|_)_AA
|0x01_|___4____|___0____|___1____|___2____|___3____|_)_AA~
|0x02_|___5____|___6____|___7____|___8____|___9____|_)_AB
|0x03_|___9____|___5____|___6____|___7____|___8____|_)_AB~
|...__|__...___|__...___|__...___|__...___|__...___|_)_...
|_:___|___:____|___:____|___:____|___:____|___:____|___:
|...__|__...___|__...___|__...___|__...___|__...___|_)_...
|0x79_|__314___|__315___|__316___|__317___|__318___|_)_EX
|0x80_|__318___|__314___|__315___|__316___|__317___|_)_EX~
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

   Avec AA, AB, ..., AZ, BA, ... étant le jeu de ‹nombre de périphériques› consécutifs de chunks et AA~, AB~, ..., AZ~, BA~, ... la permutation cyclique avec l'offset 1 (dans le cas de plus de 2 copies par chunk, il y aura (AA~)~, ... et ((AA~)~)~, ... et ainsi de suite)

   Cela donne des caractéristiques de lecture similaires à far, mais plus adapté à de grandes tailles de chunk, sans autant d'écritures.

   Il devrait être noté que le nombre de périphériques dans un raid10 n'a pas besoin d'être un multiple du nombre de réplica de chaque block de données; cependant, il doit y avoir au moins autant de périphériques que de réplicas

   Si, par exemple, un array est créé avec 5 périphériques et 2 réplicas, alors un espace équivalent à 2,5 périphériques sera disponible, et chaque block sera stocké sur 2 périphériques différents.

   Finalement, il est possible d'avoir un array avec des copies à la fois near et far. Si un array est configuré avec 2 copies near et 2 copies far, il y aura un total de 4 copies de chaque block, chacun sur un disque différent.

MULTIPATH MULTIPATH n'est pas vraiment un RAID vu qu'il n'y a qu'un disque physique dans un array md MULTIPATH. Cependant il y a plusieurs points d'accès à ce périphérique, et un de ces chemins peut échouer, donc il y a quelques similarités.

   Un array MULTIPATH est composé d'un nombre de périphériques logiquement différents, souvent des interfaces fibre qui réfèrent tous au même périphérique. Si une de ces interfaces échoue (ex: dûs à un problème de cable), le pilote va tenter de rediriger les requêtes vers une autre interface.

   Le disque MULTIPATH ne reçoit plus de développement et ne devrait pas être utilisé.

FAULTY Le module md FAULTY est fournis dans un but de tests. Un array FAULTY a exactement un périphérique et est normalement assemblé sans superblock, dont l'array créé fournis un accès directe à toutes les données dans le périphérique.

   Le module FAULTY peut être requis pour simuler des fautes pour permettre de tester d'autres niveaux md ou systèmes de fichier. Les fautes peuvent être choisies pour se déclencher sur des requêtes de lecture, et peut être transitoires ou persistantes.

Arrêt non propre

   Quand des changements sont fait sur un array RAID1/4/5/6/10 il y a une possibilité d'inconsistance pour de courtes périodes de temps vu que chaque mise à jours nécessite d'écrire au moins 2 blocks sur différents périphériques, et ces écritures peuvent ne pas se produire au même moment. Donc si un système avec un de ces array est éteind au milieu d'une opération d'écriture, l'array peut être inconsistant.

   Pour gérer cette situation, le pilote md marque l'array 'dirty' avant d'écrire une donnée, et le marque 'clean' quan l'array est désactivé à l'extinction. Si le pilote md trouve un array dirty au démarrage, il procède à une correction. Pour RAID1, cela implique de copier le contenu du premier disque dans tous les autres. Pour RAID4/5/6, cela implique de recalculer la parité pour chaque stripe et de s'assurerque le block de parité a une valeur correcte. Pour RAID10 cela implique de copier un des réplicas de chaque block dans tous les autres. Ce processus de resynchronisation est effectue en tâche de fond. L'array peut être utilisé pendant ce temps, mais possiblement avec des performances réduites.

   Si un RAID4/5/6 est dégradé (il manque au moins un disque, 2 pour un raid6) quand il est redémarré après un arrêt non propre, il ne peut pas recalculer la parité, et des données corrompues peuvent ne pas être détectés. Le pilote md ne démarrera pas si un array dans ces condition sans intervention manuelle, bien que ce comportement peut être changé par un paramètre kernel.

Récupération

   Si le pilote md détecte une erreur d'écriture sur un périphérique dans un RAID1/4/5/6/10, il désactive immédiatement le périphérique (marqué faulty) et continue ses opérations sur les autres disques. Il y a un disque spare, le pilote va démarrer le re-création sur un des disques spare.

   Dans le kernel, une erreur de lecture force md à ne pas tenter de récupérer un mauvais block, ex, il va trouve la donnée correcte quelque-part, écrire sur le block défectueux, puis tenter de lire ce block de nouveau. Si l'écriture ou la re-lecture échoue, md traite l'erreur de la même manière qu'une erreur d'écriture est traitée, et échoue tout le périphérique.

   Quand ce processus de récupération se produit, md monitor l'accès à l'array et affiche le taux de récupération si d'autre activités se produisent, donc un accès normal à l'array n'est pas affecté. Quand une autre activité survient, le processus de récupération la traite à pleine vitesse. Les vitesses sont contrôlés avec 'speed_limit_min' et 'speed_limit_max'.

scrubbing et mismatches

   Vu que les périphériques de stockage peuvent développer de mauvais blocks à tout moment il est utile de lire régulièrement tous les blocks de tous les périphériques dans un array pour capturer ces blocks defectueux le plus tôt possible. Ce processus est appelé scribbing.

   Les arrays md peuvent être scrubbés en écrivant soit check ou repair dans le fichier md/sync_action dans le répertoire sysfs pour le périphérique.

   En demandant un scrub, md lit tous les block et vérifie la consistance des données. Pour raid1/10, cela signifie que les copies sont identiques. pour raid4/5/6 cela signifie que le block de parité est correcte.

   Si une erreur de lecture est détectée durant ce processus, le gestion d'erreur corrige les données. Dans de nombreux cas, cela corrige effectivement le mauvais block.

   Si tous les blocks sont lus avec succès mais apparaîssent inconsistants, ils sont considérés comme mismatch.

   Si 'check' a été utilisée, aucune action n'est prise pour gérer le mismatch, il est simplement enregistré. Si 'repair' est utilisé, un mismatch sera réparé de la même manière que resync répare les array. Pour raid5/6, de nouveaux blocks de parité sont écris. Pour raid1/10, tous sauf un block sont écrasés avec le contenu de ce block.

   Un compteur de mismatch est enregistré dans sysfs 'md/mismatch_cnt'. Il est mis à 0 quand un scrub commence et est incrémenté quand un secteur est trouvé qui est un mismatch, il ne détermine pas exactement combien de secteurs sont affectés mais ajoute simplement le nombre de secteurs dans l'unité IO qui été utilisé. Donc une valeur de 128 peut signifier qu'une vérification de 64Ko a trouvé une erreur (128*512o = 64Ko)

   Si un array est créé par mdadm avec --assume-clean alor une vérification ultérieure peut s'attendre à trouver des mismatch. Dans un raid5/6 propre, tout mismatch devrait indiquer un problème hardware.

   Cependant, sur un raid1/10 il est possible qu'il s'agisse d'un problème logiciel. Cela ne signifie pas nécessairement que les données dans l'array sont corrompues. Cela peut simplement signifier que le système ne s'occupe pas de ce qui est stocké sur cette partie de l'array - c'est de l'espace inutilisé.

   La cause principale de mismatch sur un raid0/10 se produit si une partition swap ou un fichier swap est stockés dans l'array.

   Quand le sous-système swap souhaite écrire une page de mémoire, il flag la page comme 'clean' dans le gestionnaire mémoire et demande au périphériques swap de l'écrire. Il est possible que la mémoire soit changée durant l'écriture dans le swap. Dans ce cas le flag 'clean' sera effacé une fois l'écriture complétée, et le sous-système swap va simplement oublier que le swapout a été tenté, et va possiblement choisir une page différente à écrire.

   Si le périphériques swap était sur un raid1/10, la donnée est envoyée de la mémoire vers de périphérique 2 fois, donc il est possible que la mémoire ait été changée entre temps. Ainsi, la valeur mismatch_cnt ne peut pas être interprété de manière sûre sur un raid1 ou raid10, notamment quand le périphérique est utilisé pour le swap.

Bitmap write-intent logging

   md supporte le log d'écriture basé sur bitmap. Si configuré, le bitmap est utilisé pour enregistrer quels blocks de l'array peuvent être désyncho. Avant toute requête d'écriture, md s'assure que le bit correspondant dans le log est mis. Après un délai sant écritures dans une zone de l'array, le bit correspondant est effacé.

   Ce bitmap est utilisé pour 2 optimisations:

   D'abord, après un arrêt non propre, le processus de resyncho va consulter le bitmap et seulement resynchroniser les blocks qui correspondent aux bits mis dans le bitmap. Cela peut considérablement réduire le temps de resynchro

   Ensuite, quand un lecteur échoue et est enlevé de l'array, md arrête d'effacer les bits dans les log. Si ce même disque est réajouté à l'array, md va le notifier et seulement récupérer les section du disque qui sont couverts par les bits mis dans le log. Cela peut permettre à un périphérique d'être temporairement enlevé puis réinséré sans causer de gros coûts de récupération.

   Le log d'écriture peut être stocké dans un fichier sur un périphérique séparé, ou peut être stocké près des superblocks d'un array qui a des superblocks. Il est possible d'ajouter un log à un array actif, ou de le supprimer.

Bad block list

   Chaque périphérique dans un array md peut stocker une liste de blocks défectueux connus. Cette liste a une taille de 4k et est généralement positionnée à la fin de l'espace entre le superblock et les données

   Quand un block ne peut pas être lu et ne peut pas être réparé en écrivant les données récupérées depuis les autres périphériques, l'adresse du block est stockée dans la liste des blocks défectueux. Similairement si une tentative d'écriture dans un block échoue, l'adresse sera enregistrée comme block défectueux. Si une tentative d'enregistrer le block défectueux échoue, tout le périphérique est marqué en erreur.

   Tenter de lire depuis un block défectueux génère une erreur de lecture. Tenter d'écrire dans un block défectueux connus est ignoré si des erreurs d'écriture ont été reportés par le périphérique. S'il n'y a pas d'erreur d'écriture, les données sont écrites dans le block et en cas de succès, l'adresse est supprimée de la liste.

Journal d'écriture RAID456

   Dû à la nature non-atomique des opérations d'écriture raid, d'interruption des opérations d'écriture (crash système, etc) sur un raid456 peut créer une inconsistance de parité et la perte de données. (également appelé RAID-5 write hole).

   md supporte l'écriture dans un journal. Quand l'array est créé, un périphérique journal additionnel peut être ajouté à l'array via l'option write-journal. Ce journal fonctionne comme les journaux des systèmes de fichier. Avant d'écrire les données sur disque, md écris les données et la parité du stripe dans le périphérique journal. Après un crash, md recherche dans le périphérique journal les opérations d'écritures incomplètes, et les écrit sur les disques.

   Quand le périphérique journal échoue, l'array est forcé en mode lecture-seule.

write-behind

   md supporte write-behind sur les arrays RAID1. Cela permet à certains périphériques dans l'array d'être flaggé write-mostly. MD ne lit dans ces périphériques seulement s'il n'y a pas d'autres options. Si un bitmap write-intend est également fournis, les requêtes d'écriture vers les périphérique write-mostly sont traités comme des requêtes write-behind et md n'attend pas que les écritures soient complétées avant de reporter l'écriture complétée au système de fichier.

   Cela permet à un RAID1 avec write-behind d'être utilisé comme donnée miroir sur un lien lent dans une machine distante. La latence supplémentaire de lien distant ne ralentira pas les opérations normales, mais le système distant continura à maintenir une copie raisonablement à jour de toutes les données

RESTRIPING

   re restriping, également appelé reshaping, est le processus de ré-arrangement des données stockées dans chaque stripe dans une nouvelle couche. Cela peut être dû au changement du nombre de disques dans l'array (donc les stripes sont plus long), changer la taille de chunk, ou changer l'arrangement des données et de la parité (possiblement changer le niveau de raid).

   md peut remodeler un raid4/5/6 pour avoir un nombre différent de disques et pour avoir un layout différent ou une taille de chunk différente. Il peut également convertir entre les différents niveaux de raid. Il peut également convertir entre raid0 et raid10, et entre raid0, raid4 ou raid5. D'autres possibilités peuvent suivre dans le future.

   Durant un traitement de stripe il y a une section critique durant lequel les données sont écrasées sur le disque. Pour l'opération d'augmentation du nombre de disques dans un raid5, cette section critique couvre les premier stripes (le nombre étant le produit de l'ancien et du nouveau nombre de disques). Une fois cette section critique passée, les données sont seulement écrite dans les aires de l'array qui ne maintient pas de données

   Pour un traitement qui réduit le nombre de périphériques, la section critique est à la fin du processus de reshaping.

   md n'est pas capable de s'assurer de la préservation des données s'il y a un crash durant la section critique. Si md doit démarrer un array qui a échoué durant une section critique, il refuse de démarrer l'array.

   Pour gérer ce cas, un programme userspace doit:

        - désactiver les écritures dans cette section de l'array (en utilisant l'interface sysfs)
        - Créer une copie des données
        - permettre au processus de continuer et invalider l'accès en écriture au backup et restauration une fois la section critique passée
        - fournir pour restorer les données critiques avant de redémarrer l'array après un crash.

   mdadm le fait pour les array raid5. Pour les opérations qui ne changent pas la taille de l'array, par exemple augmenter a taille de chunk, ou convertir un raid5 en raid6 avec un périphériques supplémentaire, tout le processus est la section critique. Dans ce cas, le restripe doit progresser en étapes, vu qu'une section est suspendue, backupée, restripée, et relachée.

Interface sysfs

   Chaque périphériques block apparaît dans sysfs. Pour les périphériques MD, ce répertoire va contenir un sous-répertoire 'md' qui contient divers fichiers pour fournir l'accès aux informations sur l'array.

   Cette interface est documentée dans Documentation/md.txt:

md/sync_speed_min Si définis, écrase le paramètre système dans /proc/sys/dev/raid/speed_limit_min pour cet array uniquement. La valeur 'system' force l'utilisation du paramètre système.
md/sync_speed_max Idem, pour /proc/sys/dev/raid/speed_limit_max
md/sync_action Peut être utilisé pour superviser et contrôler les processus de resynchro/récupération. Écrire check déclenche la vérification de la consistance de tous les blocks de données. Un compteur de problèmes est stocké dans md/mismatch_count. 'repair' peut être écrit pour vérifier et corriger les erreurs.
md/stripe_cache_size Seulement disponible pour un raid5/6. Enregistre la taille (en pages par périphérique) du cache de stripe qui est utilisé pour synchoniser toutes les opérations d'écriture dans l'array et toutes les opérations de lecture si l'array est dégradé. Défaut: 256 (de 17 à 32768). Augmenter cette valeur améliore les performances dans certaines situations, au prix d'une consommation mémoire système accrue (memory_consumed = system_page_size addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo nr_disks addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo stripe_cache_size)
md/preread_bypass_threshold Seulement disponible pour un raid5/6. Cette variable définis le nombre de fois que md effectue un full-stripe-write avant de servire un stripe qui nécessite une pré-lecture. défaut: 1 (de 0 à stripe_cache_size). À 0, maximise l'écriture séquentielle au prix de l'équité pour les threads qui effectuent de petites écritures ou des écritures aléatoires.

Paramètres kernel

raid=noautodetect Désactive l'auto-detection des array au boot. Si un disque est partitionné avec des partitions de style MSDOS, si une des 4 partitions primaires a le type 0xFD, cette partition est normalement inspectée pour voir si elle fait partie d'un array. Ce paramètre désactive cette détection.
raid=partitionable
raid=part Indique que les array auto-détectés devraient être créés comme arrays partitionnables, avec un numéro majeur différent des array non-partitionnables. Le numéro de périphérique est listé comme 'mdp' dans /proc/devices'
md_mod.start_ro=1
/sys/module/md_mod/parameters/start_ro md démarre tous les array en lecture seule. C'est un RO soft qui bascule automatiquement en lecture-écriture à la première requête d'écriture.
md_mod.start_dirty_degraded=1
/sys/module/md_mod/parameters/start_dirty_degraded ne démarre pas de raid4/5/6 qui est dégradé. Ce paramètre permet de forcer le démarrage de tels array au boot. (utile pour /)
md=n,dev,dev,...
md=dn,dev,dev,... Indique au pilote md d'assembler '/dev/md n' depuis les périphériques listés. Seulement nécessaire pour démarrer le périphérique maintenant le système de fichier racine.
md=n,l,c,i,dev... Indique au pilote md d'assembler un array RAID0 ou LINEAR dans superblock. 'n' donne le nombre de périphériques, 'l' donnele niveau (0=RAID0 ou -1=LINEAR), 'c' donne la taille de chunk en logarithme base-2 par 12, donc 0 indique 4k, 1 indique 8k. 'i' est ignoré.

Fichiers

/proc/mdstat Contient les informations sur le status de l'array en cours d'exécution
/proc/sys/dev/raid/speed_limit_min Reflète la vitesse courante de reconstruction quand l'activité de non-reconstruction est en cours dans un array. La vitesse est en Kio/s, et est un taux par périphérique. Défaut: 1000.
/proc/sys/dev/raid/speed_limit_max Reflète la vitesse courante de reconstruction quand aucune activité de non-reconstruction est en cours dans un array. Défaut: 200,000.
^
07 juin 2010

htmlpdflatexmanmd




md5sum

md5sum

Calcul un checksum 128-bits pour chaque fichier spécifié

OPTIONS

-b, --binary Traite chaque fichier en binaire, en le lisant en mode binaire, préfixe le nom du fichier par '*'. Principalement utile sur les systèmes MS-DOS.
-c, --check Lit les informations de checksum et de nom de fichier dans le fichier et report si le checksum correspond avec le fichier nommé. Le format du fichier d'entrée est généralement le format de sortie d'un md5sum précédent.
--quiet Cette option est utile seulement quand on vérifie les checksums. Ne génère pas de 'OK' pour chaque message vérifié avec succès.
--status Cette option est utile seulement quand on vérifie les checksums. Ne génère pas de diagnostic et ne sort pas d'alerte en cas d'erreur.
-t, --text Traite chaque fichier en entrée comme texte. Utile pour les systèmes de type MS-DOS.
-w, --warn En vérifiant les checksums, alerte sur les ligne de checksums MD5 mal formatés.
^
22 mai 2016

htmlpdflatexmanmd




mdadm

mdadm

Gestion de périphériques raid

   Les périphériques RAID logiciel Linux sont implémentés via le pilote md (Multiple Devices). Actuellement, linux supporte les périphériques LINEAR, RAID0, RAID1, RAID4, RAID5, RAID6, RAID10, MULTIPATH, FAULTY, et CONTAINER

MULTIPATH N'est pas un mécanisme raid logiciel, mais implique des périphériques multiples: chaque périphérique est un chemin vers un stockage physique. Il ne devrait plus être utilisé
FAULTY N'est pas un mécanisme raid, et implique seulement 1 périphérique. Il fournis un couche sur un vrai périphérique qui peut être utilisé pour injecter des fautes
CONTAINER est différent, c'est une collection de périphériques qui sont gérés comme un set. C'est similaire à un jeu de périphériques connectés à un contrôleur RAID hardware. Le jeu de périphériques peut contenir plusieurs RAID, chacun utilisant certains ou tous les blocks dans certains périphériques du set. Par exemple, 2 périphériques d'un set de 5 périphériques peuvent former un RAID 1 en utilisant tout l'espace. Les 3 autres peut avoir un raid5 utilisant la moitie de chaque périphérique, et un raid0 pour la seconde moitié.

Modes

   mdadm a de nombreux modes d'opérations:

assemble assemble les composants d'un array précédemment créé en un array actif.
build Construit un tableau sans superblocks.
create Créé un nouvel array avec superblocks.
follow
monitor supervise un ou plusieurs périphériques md et agit sur les changements d'état.
grow Agrandit ou réduit un array.
incremental assembly Ajoute un périphérique dans un array.
manage gérer un array, comme ajouter un nouveau spare, et supprimer a périphérique
misc mode qui fait toutes les autres opérations sur les array actifs tel qu'effacer les anciens superblocks.
auto-detect Demande au kernel d'activer tout les arrays auto-détectés

Options pour sélectionner un mode

-A, --assemble assemble un array existant
-B, --build Construit un array sans superblocks
-C, --create Créé un nouvel array
-F, --follow, --monitor Sélectionne le mode monitor
-G, --grow Change la taille d'un array actif
-I, --incremantal Ajoute/supprime un périphérique à un array
--auto-detect Demande au kernel de démarrer les array auto-détectés. ne fonctionne que si md est compilé dans le kernel (pas en module)

   Si un périphérique est donné avant toute options, ou si la première option est --add, --re-add, --add-spare, --fail, --remove, ou --replace, le mode Manage est assumé.

Options non spécifique au mode

-v, --verbose mode verbeux
-q, --quiet Mode silencieu
-f, --force Force l'action
-c, --config= Spécifie le fichier de configuration ou le répertoire. Défaut: /etc/mdadm/mdadm.conf et /etc/mdadm/mdadm.conf.d/
-s, --scan Scanne la configuration ou /proc/mdstat pour les informations manquantes.
-e, --metadata= Déclare de style de métadonnées de raid à utiliser. Défaut: 1.2 pour --create:

        0, 0.90 Utilise le format original 0.90. Ce format limite les array à 28 périphériques, et 2To.
        1, 1.0, 1.1, 1.2 default Utilise le nouveau format.
        ddf Utilise le format DDF (Disk Data Format) définis par SNIA. En créant un array DDF, un CONTAINER est créé.
        imsm Utilise le format Intel Matrix Storage Manager. Cela créé un CONTAINER géré de manière similaire à DDF.

--homehost* Remplace tout paramètre HOMEHOST dans la configuration et fournis l'identité de l'hôte qui devrait être considéré le home de tous les arrays. cet homehost est enregistré dans les métadonnées.
--prefer= Quand mdadm a besoin d'afficher le nom d'un périphérique il le trouve normalement dans /dev. Quand un chemin est donné avec cette option, mdadm va préférer un nom plus long s'il contient un composant. par exemple --prefer-by-uuid va préférer un nom dans /dev/by-uuid/
--home-cluster= Spécifie le nom du cluster pour le périphérique md. Le périphérique md peut être assemblé seulement dans le cluster qui match le nom spécifié.

Options pour create, build, ou grow

-n, --raid-devices= Spécifie le nombre de périphériques actifs dans l'array, incluant les spare et ceux manquants
-x, --spare-devices= Spécifie le nombre de périphériques spare dans l'array initial
-z, --size= Espace en Kio à utiliser dans chaque disque dans le raid 1/4/5/6. Doit être un multiple de la taille de chunk, et doit laisser 128Kb à la fin du disque pour le superblock RAID.
-Z, --array-size= C'est seulement avec' --grow et son effet n'est pas persistant. Avec cette option, l'array paraît plus petit qu'il ne l'est.
-c, --chunk= Spécifie la taille de chunk en KiO. Défaut: 512KiO. Pour s'assurer de la compatibilité avec les anciennes versions, le défaut à la construction d'un array sans métadonnées persistantes est de 64Ko. C'est seulement significatif pour les raid 0/4/5/6/10. les raid 4/5/6/10 nécessitent un taille en puissance de 2. Dans tous les cas, doit être un multiple de 4Ko.
--rounding Spécifie le facteur d'arrondissement pour un array linéaire. La taille de chaque composant sera arrondi à un multiple de cette taille. Défaut: 0
-l, --level= Définis le niveau de raid. avec --create les options sont: linear, raid0, 0, stripe, raid1, 1, mirror, raid4, 4, raid5, 5, raid6, 6, raid10, 10, mulitpath, mp, faulty, container. Avec --build: linear, stripe, raid0, 0, raid1, multipath, mp, faulty.
-p, --layout=, --parity= Configure le détails de la couche de données pour les raid 5/6/10, et contrôle les modes d'erreur pour faulty. pour un raid5: left-asymmetric, left-symmetric, right-asymmetric, right-symmetric, la, ra, ls, rs. Défaut: left-symmetric. Il est également possible de forcer un raid5 à utiliser une couche raid4 avec parity-first ou parity-last. Pour les raid5 DDF, ddf-zero-restart, ddf-N-restart et ddf-N-contitue. Ces layouts sont également disponible pour le raid6. 4 layouts sont fournis en étape intermédiaire pour convertir un raid5 en raid6: left-symmetric-6, right-symmetric-6, left-asymmetric-6, right-asymmetric-6, et parity-first-6.

           Pour faulty, les options sont: write-transient, wt, read-transient, rt, write-persistent, wp, read-persistent, rp, write-all, read-fixable, rf, clear, flush, none. Chaque mode d'erreur peut être suivi par un nombre, qui est utilisé comme période entre la génération d'erreurs. Pour les raid10: n, o, ou f, suivi par un nombre. Défaut: n2:

        n (near copies) Plusieurs copie d'un block de données sont à un offset similaire dans différents périphériques
        o (offset copies) Au lieur de dupliquer les chunks dans un stripe, tous les stripes sont dupliqués mais avec une rotation d'un périphérique pour que les blocks dupliqués soient sur différents périphériques.
        f (far copies) Plusieurs copies ont des offsets différents. voir md(4) pour plus de détails.

-b, --bitmap= Spécifie un fichier où stocker un bitmap. Ce fichier ne devrait pas exister sauf si --force est donné. Le même fihier devrait être donné en assemblant l'array. Si le mot internal est donné, le bitmap est stocké avec les métadonnées dans l'array, et donc est répliqué sur tous les périphériques Si le mot none est donné avec le mode --grow, tout bitmap présent est supprimé. Is le mot clustered est donné, l'array est créé pour un environnement clusterisé Un bitmap est crée pour chaque nœud comme définis par le paramètre --nodes et sont stockés en interne
--bitmap-chunk= Définis la taille de chunk du bitmap. Chaque bit correspond à autant de Ko de stockage. En utilisant un bitmap basé sur un fichier, le défaut est d'utiliser la taille la plus petite qui fait au moins 4 et au plus 2^21 chunks
-W, --write-mostly Les périphériques listés dans une commande --build, --create, --add seront flaggés en write-mostly. raid1 uniquement et signifie que le pilote md évite de lire dans ces périphériques si possible. Peut être utile pour un mirroir sur un réseau lent.
--write-behind= Active le mode write-behind (raid1). Si un argument est spécifié, il définis le nombre max d'écritures arriéré permis. Défaut: 256. un bitmap write-extent est requis, et ce mode n'est tenté que sur les disques marqués write-mostly.
--assume-clean Dit à mdadm que l'array pré-existant est correct. peut être utile en tentant une récupération après une erreur majeur
--backup-file= Nécessaire avec --grow utilisé pour augmenter le nombre de périphériques dans un raid 5 ou 6 s'il n'y a pas de disque spare disponible, ou pour réduire, changer le niveau de raid ou le layout.
--data-offset= Les array avec des métadonnées 1.x peut laisser un espace entre le début d'un périphérique et le début des données. Normalement le début des données est calculé automatiquement, mais cette option permet de le spécifier manuellement
--continue Cette option est complémentaire à l'option --freeze-reshape pour assembly. Il est nécessaire quand l'opération --grow est interrompue et n'est pas redémarré automatiquement à cause de l'utilisation de --freeze-reshape durant l'assemblage de l'array.
-N, --name= Définis un nom pour l'array. Seulement effectif en créant un array avec un superblock version 1, ou un array dans un conteneur DDF.
-R, --run Insiste pour que mdadm lance l'array, même si certains composants apparaîssent actif dans un autre array ou système de fichier. Normalement, mdadm demande confirmation pour cela, cette option suprime la question.
-f, --force Insiste pour que mdadm accepte la géométrie et le layout spécifié sans question.
-o, --readonly Démarre l'array en mode lecture seule
-a, --auto{=yes,md,mdp,part,p}{NN} Instruit mdadm sur la manière de créer un fichier de périphérique si nécessaire, en allouant possiblement un numéro mineur non-utilisé. "md" utilise un array non-partitionnable, "mdp", "part" ou "p" utilise un array partitionnable. "yes" nécessite que le périphérique md ait le format standard. Depuis mdadm 3.0, la création de périphérique est effectuée par udev, donc cette option n'est pas nécessaire
-a, --add Peut être utilisé en mode grow dans 2 cas. Il l'array cible est un array linear, --add peut être utilisé pour ajouter un ou plusieurs périphériques. Si l'option --raid-disks est utilisé pour augmenter le nombre de périphériques dans un array, --add peut être utilisé pour ajouter des périphériques supplémentaire à inclure dans l'array.
--nodes Ne fonction que lorsque l'array est pour un environnement clusterisé. Il spécifie le nombre max de nœuds dans le cluster qui vont utiliser ce périphérique simultannément. Défaut: 4
--write-journal Spécifie un périphérique journal pour l'array raid 4/5/6. Devrait être un SSD avec une durée de vie raisonnable

Options pour l'assemblage

-u, --uuid= uuid de l'array à assembler. Les périphériques qui n'ont pas cet uuid sont exclus
-m, --super-minor= numéro mineur du périphérique créé. Les périphériques qui n'ont pas ce numéro mineur sont exclus.
-N, --name= Spécifie le nom de l'array à assembler.
-f, --force Assemble l'array même si les métadonnées dans certains périphériques apparaîssent périmés.
-R, --run Tente de démarrer l'array même si moins de disques sont donné que la dernière fois qu'il a été actif.
--no-degraded Inverse de --run. Ne démarre que si tous les disques attendus sont présents.
-a, --auto{=yes,md,mdp,part,p}{NN} Voir plus haut
-b, --bitmap= Spécifie le fichier bitmap qui a été donné à la création de l'array.
--backup-file= Si utilisé pour re-définir un array (changer le nombre de périphériques, ou la taille de chunk) et que le système crash durant la section critique, cette option doit également être présent avec --assemble pour permettre à des données possiblement corrompus d'être restaurées.
--invalid-backup Si le fichier nécessaire pour l'option ci-dessus n'est pas disponible, un fichier vide peut être donné avec cette option pour indiquer que le fichier backup est invalide. Dans ce cas les données qui étaient ré-arrangés au moment du crash peuvent être perdus irrévocablement, mais le reste de l'array peut être récupérable. Cette option devrait être utilisée quand dernier recours.
-U, --update= Met à jours le superblock dans chaque périphérique en assemblant l'array. L'argument donné peut être (sparc2.2, summaries, uuid, name, nodes, homehost, home-cluster, resync, byteorder, devicesize, no-bitmap, bbl, no-bbl, metadata, ou super-minor):

        sparc2.2 Ajuste le superblock d'un array qui a été sur une machine Sparc tournant sur un Kernel 2.2 patché.
        super-minor Met à jours le champ 'preferred minor' dans chaque superblock pour correspondre au numéro mineur de l'array à assembler.
        uuid Change l'uuid de l'array
        name Change le nom de l'array stocké dans le superblock. (superblock V1 uniquement)
        nodes Change les nœuds de l'array comme stocké dans le superblock bitmap. Ne fonctionne que pour les environnements clusterisés
        homehost Change le homehost enregistré dans le superblock. Pour les superblocks V0, c'est identique à uuid, pour V1, met à jours le nom
        home-cluster Change le nom du cluster. Ne fonctionne que pour les environnements clusterisés
        resync Marque l'array 'dirty' signifiant qu'une redondance dans l'array peut être incorrect, et force un resync
        byteorder Permet de déplacer l'array entre des machines avec un byte-order différent.
        summaries Corrige les sommaires dans le superblock. (compteurs de périphériques total, fonctionnels, actifs, en erreur, et spare)
        devicesize S'applique au métadonnées 1.1 et 1.2, utile quand le périphérique a changé de taille.
        metadata Fonction avec les métadonnées 0.90 et va le convertir en v1.0. L'array ne doit pas être durty ni write-intent bitmap
        no-bitmap Peut être utilisé quand un array a un bitmap interne qui est corrompus. Ignore le bitmap interne
        bbl Réserve l'espace dans chaque périphérique pour une liste de blocks défectueux, de 4k vers la fin du disque.
        no-bbl Supprime toute réservation pour la liste de blocks défectueux. Si la liste contient des entrées, il échoue.

--freeze-reshape Utilisé dans les scripts de démarrage. Quand un array sous reshape est assemblé au boot, cette option stop le reshape après la section critique. Cela se produit avant l'opération de pivot du système de fichiers et évite de perdre le contexte du système de fichier. Le reshape peut être repris ultérieurement avec --continue de la commande grow.

Pour le mode Manage

-t, --test Sauf si une erreur sérieuse se produit, mdadm quitte avec le status 2 si aucun changements n'est fait dans l'array et 0 si au moins un changement a été fait.
-a, --add Périphériques listés à chaud. Si un périphérique apparaît avoir fait partie récemment d'un array, le périphérique est re-ajouté. En cas d'échec ou si le périphérique n'a jamais fait partie de l'array, le périphérique est ajouté comme hot-spare. Si l'array est dégradé, il démarre immédiatement la reconstruction des données sur ce spare.
--re-add Re-ajoute un périphérique qui a été précédemment supprimé de l'array. Si les métadonnées dans le périphérique reportent qu'il est un membre de l'array, et que le slot qui est utilisé est vacant, ce périphérique est ajouté à l'array à la même position. Cela va automatiquement récupérer les données de ce périphérique. Utilisé dans un array qui n'a pas de métadonnées, assume que la récupération basée sur bitmap est suffisante pour rendre le périphérique suffisamment consistant avec l'array. avec des métadonnées V1.x, peut être accompagné avec --update-devicesize, --update=bbl ou --update=no-bbl.
--add-spare Ajoute un périphérique spare. Similaire à --add excepté qu'il ne tente pas de --re-add avant.
-r, --remove Supprime les périphériques listés. Ils ne doivent pas être actifs.
-f, --fail, --set-faulty Marque les périphériques listés en faute.
--replace Marque les périphériques listés à remplacer. Tant qu'un spare est disponible, il reconstruit et remplace le périphérique marqué. C'est similaire à marquer le périphérique en faute, mais il reste en service durant le traitement de récupération.
--with Peut suivre une liste de périphériques --replace. Ces périphériques sont utilisés de préférence pour remplacer les périphériques. Ces périphériques doivent déjà être marqués spare dans l'array.
--write-mostly Les périphériques qui sont ajoutés ou re-ajoutés auront le flag 'write-mostly' mis. Seulement valide pour RAID1 et signifie que md évite toute lecture dans ces périphériques si possible
--readwrite Les périphériques qui sont ajoutés ou re-ajoutés auront le flag 'write-mostly' effacé.
--cluster-confirm Confirme l'existence du périphérique. Émis en réponse à une requête --add par un nœud dans un cluster. Quand un nœud ajoute un périphérique il envoie un message à tous les nœuds dans le cluster pour rechercher un périphérique avec un UUID. Cela traduit en une notification udev avec l'UUID du périphériques à ajouter et le numéro de slot. Le nœud reçevant doit acquiter ce message avec --cluster-confirm. Les arguments valides sont ‹slot›:‹devicename› dans le cas où le périphérique est trouvé ou ‹slot›:missing si non trouvé.

   Chacune de ces options nécessite que le premier périphérique listé est l'array sur lequel agir, et le reste sont les périphérique à ajouter, supprimer, marqué en faute, etc. les différentes opération peuvent être spécifiée pour différents périphériques (ex: mdadm /dev/md0 --add /dev/sda1 --fail /dev/sdb1 --remove /dev/sdb1 ).

   Si un array utilise un bitmap write-intent, les périphériques qui ont été supprimés peuvent être re-ajouté de manière à éviter une reconstruction complète et seulement mettre à jour les blocks qui ont été changés depuis qu'il a été supprimé. Pour les array avec des métadonnées persistantes (superblocks) c'est fait automatiquement. Pour les array créés avec --build, mdadm doit indiquer que ce périphérique a été supprimé récemment avec --re-add.

   Les périphériques peuvent seulement être supprimés d'un array s'ils ne sont pas actifs, par exemple, doivent être spare ou en faute. Pour supprimer un périphérique actif, il faut le marquer en faute avant.

Mode Misc

-Q, --query Examine un périphérique pour voir si c'est un périphérique md et si c'est un composant d'un array md.
-D, --detail Affiche les détails d'un ou plusieurs périphériques md
--detail-platform Affiche des détails sur les capacités RAID de la plateform (firmware/topologie hardware) pour un format de métadonnées donné. Sans argument, mdadm scanne tous les controleurs à la recherche de leur capacités. Sinon, mdadm ne regarde que le contrôleur spécifié par l'argument sous la forme d'un chemin absolus ou un lien (ex: /sys/devices/pci0000:00/0000:00:1f.2)
-Y, --export Avec --detail, --detail-platform, --examine, ou --incremental, la sortie est formatté en paire clé=valeur pour simpifier l'import dans l'environnement. MD_STARTED indique si un array a été démarré, qui peut inclure une raison. MD_FOREIGN indique si l'array est attendu sur cet hôte
-E, --examine Affiche le contenu des métadonnées stockés dans le(s) périphérique(s) spécifié(s). --examine s'applique aux périphériques qui sont des composants d'un array, alors que --detail s'applique à l'array actif.
--sparc2.2 Si un array a été créé sur une machine sparc avec un kernel 2.2 patché avec le support RAID, le superblock a été créé de manière incorrect, incompatible avec les kernel 2.4 et +. Cette option fix le superblock avant de l'afficher. Dans ce cas, on peut assembler avec --assemble --update=sparc2.2.
-X, --examine-bitmap Repporte les inforamtions sur le fichier bitmap. L'argument est soit un fichie bitmap externe, ou un composant array dans le cas d'un bitmap interne.
--examine-badblock Liste les blocks défectueux enregistrés dans un périphérique (métadata v1.x)
--dump=directory, --restore=directory Sauve les métadonnées d'une liste de périphériques, ou les restaure.
-R, --run Démarre un array partiellement assemblé. Si --assemble n'a pas suffisamment de périphériques pour démarrer l'array, cette option démarre l'array en mode dégradé.
-S, --stop Désactive un array
-o, --readonly Marque un array en lecture seule
-w, --readwrite Marque l'array en lecture écriture
--zero-superblock Si le périphérique contient un superblock md valide, le block est remplis de zéro. avec --force, le block œu ce superblock devrait être sera écrasé même s'il apparaît non valide
--kill-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array inactif dans le conteneur, ce sous-array est supprimé. Supprimer tous les sous-array laisse un conteneur vide ou un superblock spare dans les disques. voir --zero-superblock pour supprimer complètement un superblock.
--update-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array dans le conteneur, tente de mettre à jour le superblock doné dans le sous-array.
-t, --test Avec --detail, le code de sortie de mdadm est mis pour refléter le status du périphérique
-W, --wait Pour chaque périphérique md donné, attend la fin d'une resyncho, récupération, ou reshaping avant de quitter.
--wait-clean Pour chaque périphérique md doné ou chaque périphérique dans /proc/mdstat si --scan est donné, s'assure que l'array est marqué clean dès que possible.
--action= Définis le 'sync_action' pour tous les périphériques donné à idle, frozen, check ou repair. idle annule l'action en cours bien que certaines action vont redémarrer automatiquement. frozen annule l'action en cours et s'assur qu'aucune autre action ne démarre automatiquement.

Mode assemblage incrémental

--rebuild-map, -r Reconstruit le fichier de map (/run/mdadm/map) que mdadm utilise pour suivre les array actuellement assemblés
--run, -R Lance un array assemblé dès qu'un nombre minimum de périphériques sont disponibles.
--scan, -s avec -R, scan le fichier de map à la recherche d'array qui sont assemblés incrémentalement et tente de démarrer tous ceux qui ne sont pas déjà démarrés. Si un tel array est listé dans mdadm.conf comme nécessitant un bitmap externe, ce bitmap sera attaché avant.
--fail, -f Permet au système hotplug de supprimer les périphériques qui ont disparus complètement du kernel. Ils sont d'abord mis en faute, puis supprimés de l'array. Cela permet au périphérique en faute d'être automatiquement remplacé par un nouveau périphériques sans métadonnées s'il apparaît au chemin spécifié. Cette option est normallement définis seulement par un script udev.

Mode Monitor

-m, --mail Addresse mail où envoyer des alertes
-p, --program, --alert Programme à lancer quant un événements est détecté
-y, --syslog Tous les événements sont reportés via syslog. Les messages ont la facilité 'daemon'
-d, --delay Délay en seconde d'attente avant de resonder les arrays md. Défaut: 60 secondes. Il n'est pas nécessaire de réduire ce délai vu que le kernel alerte immédiatement mdadm en cas de changement.
-r, --increment mdadm génère des événements RebuildNN avec le % d'incrément donné
-f, --daemonise Lance mdadm en tâche de fond
-i, --pid-file quand mdadm est lancé en mode service, écris le pid du process dans le fichier spécifié
-1, --oneshot Vérifie les arrays seulement une fois. Cela génère des événements NewArray, DegradedArray et SparesMissing.
-t, --test Génère une alert TestMessage pour tout array trouvé au démarrage.
--no-sharing Inhibe la fonctionnalité pour déplacer les spares entre les arrays. Seul un processus de monitoring démarré avec --scan, mais sans ce flag est permis.

Mode ASSEMBLE

   Assemble un ou plusieurs arrays RAID depuis des composants pré-existants. Pour chaque array, mdadm doit connaître le périphérique md, l'identité de l'array, et des périphériques. Ils peuvent être trouvés de différentes manières.

   sans l'option --scan, le premier périphériques donné est le périphérique md. Avec --scan, tous les périphériques listés sont des périphériques md et un assemblage est tenté. Avec --scan, sans périphérique listé, tous les périphériques listés dans le fichier de configuration sont assemblés. Si aucun array n'est décris pas le fichier de configuration, les arrays qui peuvent être trouvé dans des périphériques non-utilisés seront assemblés

   Sans l'option --scan et avec exactement 1 périphérique donné, mdadm agit comme avec --scan et les informations d'identité sont extraits du fichier de configuration.

   L'identité peut être donné avec l'option --uuid, --name ou --super-minor.

   Les périphériques peuvent être donnés dans la commande --assemble ou dans le fichier de configuration. Seul les périphériques qui ont un superblock md contenant la bonne identité seront considérés.

   Le fichier de configuration est seulement utilisé s'il est explicitement donné avec --config ou requêté avec --scan. Dans ce cas, /etc/mdadm/mdadm.conf ou /etc/mdadm.conf est utilisé.

   si --scan n'est pas donné, le fichier de configuration sera seulement utilisé pour trouver l'identité d'un array

   Normallement l'array est démarré après qu'il soit assemblé. Cependant si --scan n'est pas donné et tous les disques attendu ne sont pas listés, l'array n'est pas démarré. Pour forcer l'array à être démarré dans ce cas, utiliser le flag --run

   Si udev est actif, mdadm ne créé pas d'entrée dans /dev, et laisse faire udev. Il enregistre les informations dans /run/mdadm/map qui permet à udev de choisir le nom correct. Si udev n'est pas configuré, mdadm créé lui-même les périphériques dans /dev. Dans ce cas, --auto peut être suffixé par un nombre correspondant au nombre de partitions à créer au lieu des 4 par défaut.

Auto Assemblage

   Quand --assemble est utilisé avec --scan et qu'aucun périphérique n'est listé, mdadm tente d'abord d'assembler tous les arrays listés dans le fichier de configuration. Si aucun array n'est listé dans la configuration, il recherche les périphériques disponibles à la recherche d'array et tente d'assembler ce qu'il trouve. Les array qui sont taggés comme appartenant à un homehost donné seront assemblés et démarrés normalement. Les array qui n'appartiennent pas à cet hôte sont démarrés en "read-auto" pour qui rien ne soit écrit dans ce périphérique.

   Si mdadm trouve un jeu consistant de périphériques qui semblent être dans un array, et si le superblock est taggé comme appartenant à l'hôte donné, il va automatiquement choisir un nom de périphérique et tenter d'assembler l'array. Si l'array utilise des métadonnées v0.90, le numéro mineur enregistré dans le superblock est utilisé pour créer un nom dans /dev/md/. Si l'array utilise des métadonnées v1, le nom dans le superblock est utilisé pour créer un nom dans /dev/md/.

   Ce comportement peut être modifié par la ligne AUTO dans mdadm.conf. Cette ligne peut indiquer que le type de métadonnées spécifique devrait ou non être automatiquement assemblé. Si un array est trouvé qui n'est pas listé dans mdadm.conf et a un format de métadonnées qui est refusé par la ligne AUTO, il ne sera pas assemblé. La ligne AUTO peut également exiger que tous les arrays identifiés comme appartenant à ce homehost devraient être assemblés sans regarder leur type de métadonnées.

   Note: L'auto-assemblage ne peut pas être utilisé pour assembler et activer certains array qui doivent être reshape. En particulier quand un backup-file ne peut pas être fournis, tout reshape qui nécessite un backup-file pour continuer ne peut pas être auto assemblé. Un array qui est agrandit et a passé la section critique peut être assemblée en utilisant l'auto-assemblage.

Build Mode

   Similaire à --create. La différence est qu'il créé un array sans superblock. Avec ces arrays il n'y a pas de différence entre la création initiale de l'array et l'assemblage dans l'array, excepté qu'il y a des données utiles dans le second cas.

   Le niveau peut être RAID0/1/10, multipath, ou faulty, ou un de leur synonymes. Tous les périphériques doivent être listés et l'array sera démarré une fois complet. Il est souvent approprié d'utiliser --assume-clean avec les raid1/10.

Create Mode

   Initialise un nouvel array md, associe certains périphériques avec lui, et active l'array. Le périphérique nommé n'existe normalement pas quand mdadm --create est lancé, mais sera créé par udev une fois l'array actif.

   Quand des périphériques sont ajoutés, ils sont vérifiés pour vois s'ils contiennent des superblocks RAID ou des systèmes de fichier. Ils sont également vérifiés pour voir si la variance dans la taille de périphérique excède 1%. Si une anomalie est constatée, l'array ne sera pas lancé automatiquement, bien que la présence de --run peut outrepasser cette précaution.

   Pour créer un array dégradé dans lequel certains périphériques sont manquants, donner simplement le mot 'missing' à la place du nom de périphérique. Cela laisse le slot correspondant vide dans l'array. Pour un raid4/5, au plus un slot peut être manquant, pour un raid6, au plus 2 slots peuvent être manquants. Pour un raid1, seul un périphérique a besoin d'être donné, tous les autres peuvent être manquant.

   En créant un array RAID5, mdadm créé automatiquement un array dégradé avec un disque spare, parce que créer le spare dans un array dégradé est généralement plus rapide que resynchroniser la parité dans un non-dégradé. Cette fonctionnalité peut être remplacée par l'option --force.

   En créant un array avec des métadonnées version 1 un nom pour l'array est requis. S'il n'est pas donné avec --name, mdadm en choisis un basé sur le dernier composant du nom du périphérique créé. Donc si /dev/md3 est créé, le nom 3 sera choisis. Si /dev/md/home est créé, home sera choisis.

   En créant une partition basée sur l'array, en utilisant mdadm avec des métadonnées v1.x, le type de partition devrait être 0xDA. Ce type permet une meilleur précision vu que l'utilisation d'autres (RAID auto-detect 0xFD, ou une partition Linux 0x83), peut créer des problèmes dans le cas de récupération d'array.

   Un nouvel array a normalement un UUID 128bits aléatoire assigné qui est unique. Il est possible de choisir l'UUID avec l'option --uuid.

   Si le type d'array support un bitmap write-intent, et si les périphériques dans l'array excèdent 100G, un bitmap write-intent interne sera automatiquement ajouté sauf si explicitement demandé avec l'option --bitmap. Dans ce pas l'espace pour un bitmap est réservé pour qu'il puisse être ajouté avec --grow --bitmat=internal.

   Si le type de métadonnées le supporte (v1.x), l'espace sera alloué pour stocker une liste de blocks défectueux.

   En créant un array avec un CONTAINER, on peut donner à mdadm soit la liste des périphériques à utiliser, ou simplement le nom du conteneur. Le premier cas permet de contrôler les périphériques à utiliser pour le raid. Le 2ème cas permet à mdadm de choisir automatiquement quels périphériques utiliser basé sur l'espace disponible.

   Les options de gestion générales qui sont valides avec --create sont:

--run Insiste pour démarrer l'array, même si des périphériques semblent être utilisés
--readonly démarre en lecture seule - pas encore supporté

Mode Manage

   Permet de gérer les périphérique dans un array. Il est possible d'effectuer plusieurs opération en une commande: mdadm /dev/md0 -f /dev/hda1 -r /dev/hda1 -a /dev/hda1, qui va d'abord marque /dev/hda1 en faute, puis le supprimer de l'array, et finallement l'ajouter comme spare. Seul 1 md peut être affecter par une simple commande.

   Quand un périphérique est ajouté à un array actif, mdadm vérifie pour voir s'il a des métadonnées qui spécifie s'il était récemment un membre de cet array. Si c'est le cas, it tente de ré-ajouter le périphérique. S'il n'y a pas eu de changements depuis qu'il a été supprimé, ou si l'array a un bitmap write-intent qui a été enregistré où les changements ont été faits, le périphérique devient immédiatement un membre et les différences enregistrées dans le bitmap sont résolues.

Mode Misc

   Le mode MISC inclus des opérations distinct qui opérent sur des périphériques distincts. Les opération sont:

--query Le périphérique devrait être un périphérique md actif. Affiche une description détaillée de l'array. --brief et --scan réduit les détails et formatte la sortie pour être incluse dans mdadm.conf. Le code de sortie donne des informations:

        0 L'array fonctionne normalement
        1 L'array a au moins un disque en erreur
        2 L'array a plusieurs disques en erreurs inutilisables
        4 Erreur en tentant d'obtenir des informations sur le périphérique

--detail-platform Affiche des détails sur les capacités RAID de la plateforme (firmware/topologie hardware). Si les métadonnées sont spécifiées avec -e ou --metadata= le code de retour est:

        0 Les métadonnées ont énuméré avec succès les composants de la plateforme dans le système
        1 Les métadonnées sont indépendante de la plateforme
        3 Les métadonnées ont échoué à trouver ses composants de la plateforme
       

--update-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array dans le conteneur, il tente de mettre à jours le superblock dans le sous-array. C'est similaire à mettre à jours un array en mode assemble aec d'option -U.
--examine Le périphérique devrait être un composant d'un array md. mdadm lit le superblock md du périphérique et affiche le contenu. Si --brief ou --scan est donné, les périphériques qui sont des composant d'un array sont groupés ensemble et affiché comme simple entrée utilisable dans mdadm.conf.
--dump=dir Si le périphérique contient des métadonnées RAID, un fichier sera créé dans le répertoire spécifié et les métadonnées y seront écrites. Le fichier aura la même taille que le périphérique et contient les métadonnées au même emplacement. Cepenadnt le fichier sera sparse, donc seul ces blocs de métadonnées seront alloués. Plusieurs périphériques peuvent être listés.
--restore=dir Inverse de --dump. mdadm localise un fichier dans le répertoire et restore les métadonnées.
--stop Les périphériques devraient être des array md actif à désactiver, tant qu'ils ne sont pas utilisés.
--run Active un array md partiellement assemblé
--readonly Marque un array activ en lecture seule.
--scan excepté avec --examine, force l'opération à être appliqué à tous les array listés dans /proc/mdstat. --examine prend en compte les périphériques dans le fichier de configuration.
-b, --brief mode moins verbeux.

Mode Monitor

   vérifie périodiquemenent des array md et repporte tout les événements. De plus, mdadm peut déplacer les disques spare d'un array à un autre s'il est dans le même spare-group ou domain et si l'array de destinatio a un disque en erreur mais pas de spare.

   Le résultat de la supervision des array est la génération d'événements. Ces événements sont passé à un programme séparé (si spécifié) et peuvent être envoyés par mail.

   En passant les événements à un programme, celui-ci est lancé une fois par événement, et a 2 ou 3 arguments dans l'ordre: le nom de l'événement, le nom du périphérique md et le nom du périphérique.

   Si --scan est donné, un programme ou une adresse email doit être spécifié sur la ligne de commande ou dans le fichier de configuration, sinon mdadm ne supervise rien. Sans --scan, mdadm continue de superviser tant qu'il trouve quelque chose à superviser. Si aucun programme ou email n'est donné, chaque événement est reporté sur stdout. Les différents événements sont:

DeviceDisappeared Un array précédemment configuré ne semble plus être configuré (syslog priority: Critical)
RebuildStarted Un array commence la reconstruction (syslog priority: Warning)
RebuildNN où NN est un nombre indiquant le pourcentage de reconstruction effectuée. Les événements sont générés avec un incréments fixé qui peut être spécifié sur la ligne de commande. (syslog priority: Warning)
RebuildFinished Un array a été reconstruit, soit parce qu'il a fini normalement, soit parce qu'il a été annulé. (syslog priority: Warning)
Fail Un périphérique actif d'un aray a été marqué en faute (syslog priority: Critical)
FailSpare Un périphérique spare qui a été reconstruit pour remplacer un périphérique en faute a échoué (syslog priority: Critical)
SpareActive Un disque spare a été reconstruit pour remplacer un périphérique en faute et a réussi la reconstruction (syslog priority: Info)
NewArray Un nouvel array a été détecté dans le fichier /proc/mdstat (syslog priority: Info)
DegradedArray Un array apparaît être dégradé. Ce message n'est pas généré quand mdadm remarque un disque en faute qui a généré la dégradation, mais seulement quand mdadm note qu'un array est dégradé quand il est vu la première fois. (syslog priority: Critical)
MoveSpare Un disque spare a été déplacé d'un array dans un spare-group ou domain vers un autre array. (syslog priority: Info)
SparesMissing La configuration indique qu'un array devrait avoir un certain nombre de périphériques spare, mais mdadm détecte qu'il y en a moins. (syslog priority: Warning)
TestMessage Un array a été trouvé au démarrage, et le flag --test était donné (syslog priority: Info)

   Seul Fail, FailSpare, DegradedArray, SparesMissing et TestMessage sont envoyés par mail. Tous les événements sont envoyés au programme. Chaque événement a un périphériques array associé et possiblement un périphérique physique. Pour Fail, FailSpare, et SpareActive ce disque est le périphérique physique. Pour MoveSpare, ce périphérique est l'array où le spare est déplacé.

   Pour que mdadm déplace les spares d'un array à un autre, les différents arays doivent être labélisés avec le même spare-group ou les spares doivent être autorisés à migrer via les stratégies de domaine dans le fichier de configuration. les noms des spare-group doievnt être uniques.

   Quand mdadm détecte qu'un array dans un groupe de spare a moins de périphériques actifs que nécessaire pour que l'array sont complet, et n'a pas de périphériques spare, il recherche un autre array dans le même groupe de spare qui est complet et fonctionnel et possède un spare. Il va tenter de déplacer le spare, et en cas d'erreur en ajoutant le spare à l'array, il le remet dans l'array d'origine.

   Si le groupe de spare pour un array dégradé n'est pas définis, mdadm recherche les règles de migration de spare spécifié par les lignes POLICY dans mdadm.conf et effectue les même étapes ci-dessus sur les spare qui matchent.

Mode Grow

   Le mode GROW est utilisé pour changer la taille ou le shape d'un array actif. Pour que cela fonctionne, le kernel doit supporter les changements nécessaire. Les changement supportés sont:

- Changer l'attribut "size" des RAID1/4/5/6.
- Augmenter ou diminuer l'attribut 'raid-devices' des RAID0/1/4/5/6
- Changer la taille de chunk et le layout des RAID0/4/5/6/10
- Convertir entre RAID1 et RAID5, entre RAID5 et RAID6, entre RAID0, RAID4 et RAID5, et entre RAID0 et RAID10.

Mode Grow

   Utiliser GROW dans les conteneurs est actuellement supporté seulement pour le format de conteneur IMSM d'Intel. Le nombre de périphériques dans un conteneur peut être augmenté, ce qui affecte tous les array dans le conteneur, ou un array dans un conteneur peut être convertis entre les niveaux supportés par le conteneur, et la conversion est un de ceux listés ci-dessus. Re-dimensionner un array dans un conteneur IMSM avec --grow --siwe n'est pas encore supporté.

   agrandir (par ex, étendre le nombre de périphériques raid) pour le format de conteneur IMSM a un status expérimental. Il est permis par la variable d'environnement MDADM_EXPERIMENTAL qui doit être à '1'. Ceci pour les raisons suivantes:

1. Le check-pointing n'a pas été pleinement testé. Cela peut causer des incompatibilités durant l'expansion: un array qui est étendus ne peut pas voyager entre Windows et les systèmes Linux.
2. Interrompre l'expansion n'est pas recommandé.

   Note: le Checkpointing natif d'Intel n'utilise pas l'option --backup-file et c'est transparent pour l'assemblage.

Changer la taile

   Normalement quand un array est construit la taille est donnée par le plus petit des disques. Si tous les petits disques dans un array sont supprimés et remplacés avec des disques plus grand, il faut changer la taille avec GROW pour prendre en compte l'espace supplémentaire. Si la taille est augmentée de cette manière, une resynchro démarre pour s'assurer que les nouvelles parties de l'array sont synchronisées.

   Noter que quand la taille d'un array change, tout système de fichier qui peut être stocké dans un array doit être explicitement étendu pour utiliser l'espace supplémentaire, ou réduit avant de réduire l'array.

   Également, la taille d'un array ne peut pas être changé s'il a un bitmap actif. Si un array a un bitmap, il doit être supprimé avant de changer la taille. Une fois le changement complet effectué, un nouveau bitmap peut être créé.

Changer les périphériques raid

   Un array RAID1 peut fonctionner avec plusieurs périphériques à partir de 1 (bien que 1 n'est pas très utile). Il est parfois souhaitable d'augmenter ou diminuer le nombre de disques actifs. Noter que c'est différents d'ajouter ou supprimer à chaud, qui change le nombre de périphériques inactifs.

   En réduisant le nombre de périphériques dans un raid1, les slots qui sont supprimés de l'array doivent déjà être vacants. C'est à dire, les périphériques qui étaient dans ces slots doivent être en erreur et supprimés.

   Changer le nombre de périphériques actifs dans un raid5/6 nécessite plus d'effort. Chaque block dans l'array doit être lu et re-écrit dans un nouvel emplacement. Le kernel est capable d'augmenter le nombre de périphériques dans un raid5 de manière sûre, incluant le redémarrage d'un reshape interrompu. Le kernel est également capable d'augmenter ou diminuer le nombre de périphériques dans un raid5 ou 6.

   Le kernel est capable de convertir un raid0 en raid4 ou 5. mdadm utilise cette fonctionnalité et la capacité d'ajouter des périphériques à un raid4 pour permettre aux périphériques d'être ajoutés dans un raid0. En demandant cela, mdadm convertis le raid0 en un raid4, ajoute les disques nécessaire et reshape, puis convertit le raid4 en raid0.

   En diminuant le nombre de disques, la taille de l'array diminue également. S'il y avait des données dans l'array, elles peuvent être supprimées de manière irréversible, donc il faut d'abord réduire le système de fichier dans l'array pour correspondre à la nouvelle taille. Pour éviter tout accident, mdadm exige que la taille de l'array soit réduite avant avec mdadm --grow --array-size. C'est un changement réversible qui rend simplement la fin de l'array inaccessible. L'integrité des données peuvent ainsi être vérifiées avant de réduire le nombre de périphériques.

   En relocalisant les tout premiers stripes dans un raid5 ou 6, il n'est pas possible de conserver les données sur le disques completement consistant et à l'épreuve des crash. Pour fournir la sécurité requise, mdadm désactive les écritures dans l'array lors du reshaping de la section critique, et créé un backup des données qui sont dans cette section. Pour les agrandissements, ce backup peut être stocké dans un des périphériques sparses de l'array, cependant il peut également être stocksé dans un fichier séparé avec --backup-file, et est obligatoire pour les réductions, changements de niveau de RAID et de layout. Si cette option est utilisée, et que le système crash durant la période critique, le même fichier doit être passé à --assemble pour restaurer le backup et réassembler l'array. En réduisant, le reshape est fait depuis la fin jusqu'au début, donc la section critique est à la fin du reshape.

Changement le level

   Changer le niveau de RAID d'un array est fait instantannément. Cependant, dans le cas d'un raid5 vers un raid6 cela oblige un layout non-standard du raid6, et dans le raid6 vers un raid5 ce layout non-standard est requis avant le changement. Donc bien que le changement de niveau soit instantanné, le changement de layout peut prendre du temps. Un --backup-file est requis. Si l'array n'est pas simultannément agrandis ou réduit, la taille de l'array restera la même - par exemple, reshape un raid5 à 3 disques en un raid6 à 4 disques - le fichier backup ne sera pas utilisé seulement pour la section critique, mais via toute l'opération reshape, comme décris dans la section sur les changeents de layout.

Changement de taille de chunk et de layout

   Changer la taille de chunk ou de layout sans également changer le nombre de disques implique une ré-écriture de tous les blocks. Pour éviter la perte de données en cas de crash, un --backup-file doit être fournis. Les petites section de l'array seront copiés dans le fichier backup pendant qu'ils sont réarrangés. Cela signifie que toutes les données seront copiées 2 fois, donc ce type de reshape est très lent.

   Si le reshape est interrompu, ce fichier backup doit être donné à mdadm --assemble pour que l'array puisse être ré-assemblé. En conséquence, le fichie ne peut pas être stocké dans le périphériques en cours de reshape.

Changement de bitmap

   Un bitmap write-intent peut être ajouté ou supprimé d'un array actif. On peut ajouter un bitmap interne ou externe. Noter que l'ajout d'un bitmap stocké dans un fichier qui est dans le système de fichier affecté dans le raid peut bloque le système.

Mode Incrémental

   Ce mode est conçu pour être utilisé en conjonction avec le système de découverte de périphérique. Quand des périphériques sont trouvés dans le système, ils peuvent être passé à mdadm --incremental pour être ajoutés à l'array approprié.

   Inversement, il peut également être utilisé avec --fail pour faire l'inverse et trouver l'array d'un périphérique particulier et le retirer.

   Si le périphérique passé est un périphériques conteneur, alors tous les arrays décris par les métadonnées du conteneur seront démarrés.

   mdadm effectue des tests pour déterminer si le périphérique fait partie d'un array, et dans quel array il devrait être membre. Si un array approprié est trouvé, ou peut être créé, mdadm ajoute le périphérique à l'array et le démarre.

   Noter que mdadm n'ajoute les périphériques à un array que s'il était fonctionnel (actif ou spare) dans l'array. Le support pour l'inclusion automatique d'un nouveau disque comme un spare dans certains array nécessite une configuration via le fichier de configuration (POLICY). Les tests que mdadm effectue sont les suivants:

- Si le périphérique est permis par mdadm.conf, c'est à dire listé dans une ligne DEVICES. Si DEVICES contient le mot clé 'partitions', tous les périphériques sont permis.
- Si le périphérique a un superblock md valide.

   mdadm conserve une liste d'array qui sont partiellement assemblés dans /run/mdadm/map. Si aucun array n'existe qui matche les métadonnées dans le nouveau périphérique, mdadm doit choisir un nom de périphérique et un numéro d'unité. Si se base sur un nom donné dans mdadm.conf et un nom stocké dans les métadonnées. Si le nom suggère un numéro d'unité, ce nombre est utilisé, sinon un numéro libre est choisis. Normalement, mdadm préfère créer un array partitionnable, cependant si la ligne CREATE dans mdadm.conf suggère un array non-partitionnable, il l'honore.

   Si l'array n'est pas trouvé dans le fichier de configuration et que ses métadonnées n'identifient pas qu'il appartient au homehost, mdadm choisis un nom pour l'array qui ne rentre pas en conflict avec un array qui appartient à cet hôte. Il le fait en ajoutant un '_' et un petit nombre au nom préférré par les métadonnées.

   Une fois un array approprié trouvé ou créé et le périphérique ajouté, mdadm doit décider si l'array est prêt à démarrer. Si compare le nombre de périphériques disponible (non-spare) au nombre de périphériques que les métadonnées suggèrent pour être actif. S'il y a assez de disque, l'array est démarré.

   --run peut alternativement être passé à mdadm auquel cas l'array sera lancé dès qu'il y a assez de disque. Notes qu'aucune de ces approche n'est vraiment idéal. Si tous les périphériques sont découverts, mdadm -IRs peut être lancé pour démarrer tous les arrays qui sont assemblés incrémentalement. Cela signifie qu'aucune mise à jours des métadonnées n'est faite, ni resyncho ou récupération. De plus, les périphériques qui sont trouvés avant la première écriture peuvent être ajoutés de manière sûre.

Variables d'environnement

MDADM_NO_MDMON Empêche de démarrage de mdmon
MDADM_NO_UDEV Ne laisse pas udev créer les fichiers de périphériques
MDADM_NO_SYSTEMCTL N'utilise pas systemd pour démarrer les tâches
IMSM_NO_PLATFORM À 1, désactive les vérifications de plateform Intel pour les raid IMSM.
MDADM_GROW_ALLOW_OLD Si un array est stoppé durant un reshape, qui utilise un fichier backup, puis il est ré-assemblé, mdadm peut se pleindre que le fichier backup est trop ancien. À 1, ne vérifie pas le fichier backup.
MDADM_CONF_AUTO Toute chaîne dans cette variable est ajoutée au démarrage de la ligne AUTO dans le fichier de configuration. Peut être utilisé pour désactiver certains types de métadonnées. (ex: '-ddf -imsm' pour désactiver ces array )

Exemples

Voir si un périphérique est un array, ou en fait partie
mdadm --query /dev/name-of-device
Assembler et démarrer tous les arrays listés dans le fichier de configuration
mdadm --assemble --scan
Stopper tous les array
mdadm --stop --scan
Si une adresse email ou un programme est donné dans le fichier de configuration, monitor le status de tous les arrays listé dan ce fichier en les requêtant toutes les 2 minutes
mdadm --follow --scan --delay=120
Créer /dev/md0 en raid1 avec /dev/hda1 et /dev/hdc1:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/hd[ac]1
Créer un fichier de configuration prototype qui décris les arrays actifs
echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' › mdadm.conf mdadm --detail --scan ›› mdadm.conf
Trouver les array qui peuvent être assemblés depuis des disques (pas des partitions), et stocke les informations au format du fichier de configuration.
echo 'DEVICE /dev/hd[a-z] /dev/sd*[a-z]' › mdadm.conf mdadm --examine --scan --config=mdadm.conf ›› mdadm.conf
Créer une liste de périphérique en lisant /proc/partitions et assemble /dev/md0 avec tous les périphériques avec un superblock raid et un numéro mineur 0
mdadm -Ac partitions -m 0 /dev/md0
Si le fichier de configuration contient une adresse email ou un programme d'alerte, lance mdadm en fond et monitor tous les périphériques md. Écris également le fichier pid
mdadm --monitor --scan --daemonise › /run/mdadm/mon.pid
Tente d'incorporer le périphérique nouvellement découvert dans un array approprié
mdadm -Iq /dev/somedevice
Reconstruit la map d'array depuis les arrays courant, puis démarre ceux qui peuvent l'être
mdadm --incremental --rebuild-map --run --scan
Tout périphérique composant de /dev/md4 sera marqué en faute et supprimé de l'array
mdadm /dev/md4 --fail detached --remove detached
l'array /dev/md4 qui est un RAID5 sera convertis en RAID6. Il devrait normalement y avoir un disque spare dans l'array avant
mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4
Créer un array DDF avec 6 disques
mdadm --create /dev/md/ddf --metadata=ddf --raid-disks 6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Créer un raid5 avec 3 périphériques dans le jeu DDF donné. N'utilise que 30Go dans chaque disque
mdadm --create /dev/md/home -n3 -l5 -z 30000000 /dev/md/ddf
Assemble un array ddf pré-existant
mdadm -A /dev/md/ddf1 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Assemble tous les arrays contenus dans l'array ddf, assignant un nom approprié
mdadm -I /dev/md/ddf1
Affiche l'aide pour le mode création
mdadm --create --help
Affiche l'aide sur le format du fichier de configuration
mdadm --config --help

Fichiers

/proc/mdstat
/etc/mdadm/mdadm.conf (ou /etc/mdadm.conf)
/etc/mdadm/mdadm.conf.d (ou /etc/mdadm.conf.d)
/run/mdadm/map

Noms des périphériques

   mdadm comprend 2 types de noms pour les périphériques array. Le premier est dit standard, qui matche les noms utilisés par le kernel et qui apparaîssent dans /proc/mdstat.

   Le second peut être librement choisi, mais doit résider dans /dev/md/. En donnant un nom à mdadm pour créer ou assembler un array, le chemin complet doit être donné, ou le suffixe du second type de nom.

   Quand mdadm choisis les noms de périphérique durant l'auto-assemblage ou l'assemblage incrémental, il ajoute parfois une petite séquence de nombre à la fin du nom pour éviter les conflits entre plusieurs array de même nom. Si mdadm peut déterminer que l'array est vraiment déstiné à cet hôte, soit par un hostname dans les métadonnées, ou par la présence de l'array dans mdadm.conf, il n'utilise pas le suffixe si possible. Également, si le homehost est spécifié en ‹ignore›, mdadm n'utilise le suffixe que si un array différent de même nom existe déja ou est listé dans la configuration.

Les noms standard sont sous la forme:
/dev/mdNN
NN est un nombre. Les noms standard pour les arrays partitionnables sont sous la forme:
/dev/md_dNN
Les numéro de partition sont indiqués en ajoutant pMM (ex: /dev/md/d1p2)
Depuis le kernel 2.6.28 un array non-partitionnable peut être partitionné, donc md_dNN n'est plus nécessaire, et des partitions /dev/mdNNpXX sont possibles.
Depuis le kernel 2.6.29 les noms standard peut être non-numérique:
/dev/md_XXX
XXX est une chaine. Ces noms sont supportés par mdadm v3.3.
^
22 mai 2016

htmlpdflatexmanmd




mdadm.conf

mdadm.conf

Configuration pour mdadm

   Le fichier est une collection de mots séparés par un espace. Les mot utilisant un espace sont entre guillemet simple. Une ligne commençant par un espace sont considérés comme la suite de la ligne précédente. Les mots clé sont les suivants:

DEVICE une ligne device liste les périphériques ( ou les partitions) qui peuvent contenir un composant d'un array MD. En recherchant les composants d'un array, mdadm scanne ces périphériques. Une ligne device peut contenir plusieurs périphériques séparés par des espaces et peut contenir des wirdcard, ou les mots clés containers et partitions. Ce dernier force mdadm à lire /proc/partitions et à inclure tous les périphériques et partitions trouvés. mdadm n'utilise pas les noms dans /proc/partitions mais seulement les numéros majeur et mineur. Il scanne /dev pour trouver le nom qui matche les numéros. Si aucune ligne DEVICE n'est trouvée, assume "DEVICE partitions containers".

par exemple:
DEVICE /dev/hda* /dev/hdc* 
DEV /dev/sd* 
DEVICE /dev/disk/by-path/pci* 
DEVICE partitions

ARRAY Les lignes array identifient les arrays. le second mot peut être le nom du périphérique où l'array est normalement assemblé, tel que /dev/md1. Si le nom ne commence pas par un '/', il est traité comme relatif à /dev/md. le mot ‹ignore› peut être donné auquel cas un array qui matche le reste de la ligne n'est jamais automatiquement assemblé. Si aucun nom de périphérique n'est donné, mdadm détermine lui-même un nom approprié. les autres mots identifient l'array, ou l'array comme membre d'un groupe. Si plusieurs identités sont données, un périphérique composant doit matcher toutes les identité pour matcher. Chaque identité a un tag et une valeur. Les tags sont:

        uuid= doit correspondre à l'uuid stocké dans le superblock
        name= doit correspondre au nom stocké dans le superblock
        super-minor= numéro mineur stocké dans le superblock
        devices= Liste séparé par ',' de nom de périphérique ou motif. Seul ces périphériques seront utilisés pour assembler l'array. Ces périphériques doivent également être listés dans une ligne DEVICE
        level= Niveau de RAID. Pour compatibilité avec la sortie de mdadm --examine --scan
        num-devices= nombre de périphériques dans un array actif complet. Pour compatibilité avec la sortie de mdadm --examine --scan
        spares= Nombre de spares attendus dans l'array.
        spare-group= Nom textuel pour un groupe d'array. Tous les arrays avec le même nom de spare-group sont considérés comme étant du même groupe
        auto= indique si mdadm utiliser des array partitionnable ou non, en l'absence de udev. cette option n'est plus nécessaire
        bitmap= Fichier dans lequel un bitmap write-intent devrait être trouvé.
        metadata= Format des métadonnées de l'array
        container= spécifie que cette array est un array membre d'un conteneur. contient un chemin dans /dev ou l'uuid du conteneur
        member= Spécifie que cet array est un array membre d'un conteneur. identifie quel membre d'un conteneur appartient l'array.

MAILADDR Donne une adresse email pour les alertes à envoyer quand mdadm fonctionne en mode monitor
MAILFROM Adresse de l'émetteur du mail.
PROGRAM Donne le nom d'un programme à lancer quand mdadm --monitor détecte des événements potentiellement interressant.
CREATE Donne les valeurs par défaut à utiliser en créant les arrays et les nouveaux membres d'un array. inclus:

        owner=
        group= id user/group ou noms à utiliser. Défaut: root/wheel ou root/disk.
        mode= mode de fichier. Défaut: 0600
        auto= correspond à l'opion --auto de mdadm. Donne yes, md, mdp, part, pour indiques combien de périphériques d'entrée manquant devraient être créés
        metadata= Forma de métadonnées à utiliser
        symlinks=no Normalement, un line dans /dev est créé par mdadm avec un nom commençant par md ou md_. Supprime la création de ce lien
        names=yes Permet d'utiliser des noms arbitraires pour les périphériques md
        bbl=no à no, désactive la réservation de l'espace pour la liste des blocks défectueux

HOMEHOST devrait être un nom d'hôte ou les mots clés ‹system› (utilise gethostname(2)), ‹none› (n'assume aucun nom) ou ‹ignore› (Permet de définir un nom explicit à la création)
AUTO Une liste de noms de format de métadonnées peuvent être donnés, précédé par un '+' ou un '-'. homehost est également permis équivalent à all. (0.90, 1.x, ddf, imsm).
POLICY Spécifie le comportement automatique permis sur les nouveaux périphériques dans le système et fournis une manière de marquer les spares qui peuvent être déplacer entre les array comme domaine de migration. Les domaine peuvent être définis via les policy en spécifiant un nom de domain pour des chemins dans /dev/disk/by-path. Un périphérique peut appartenir à plusieurs domaines. Le domaine d'un array est l'union des domaines de tous les périphériques dans cet array. Un spare peut être automatiquement déplacé d'un array à un autre si le domaine de l'array de destination contient tous les domaines du nouveau disque ou si les array ont le même spare-group. Les mots clés dans les policy sont:

        domain= Chaine arbitraire
        metadata= 0.9 1.x ddf ou imsm
        path= glob de fichier correspondant à tout dans /dev/disk/by-path
        type= disk ou part
        auto= yes, no, ou homehost
        action= include, re-add, spare, spare-same-slot, ou force-spare:

                include Permet d'ajouter un disque à un array si les métadonnées dans ce disque matche cet array
                re-add Inclus le périphérique dans l'array s'il apparaît en être un membre ou qu'un membre a été récemment supprimé et l'array a un bitmap write-intent pour autoriser la fonctionnalité re-add
                spare Comme ci-dessus et si le périphérique est vide, il devient un spare s'il y a array qui est candidat.
                spare-same-slot comme ci-dessus et si le slot a été utilisé par un array qui est dégradé et que le périphérique n'a pas de métadonnées, il devient automatiquement membre de l'array (ou son conteneur)
                force-spare comme ci-dessus et le disque devient un spare dans tous les autres cas.

Exemple

DEVICE /dev/sdc1
DEVICE /dev/hda1 /dev/hdb1

ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
ARRAY /dev/md1 superminor=1
ARRAY /dev/md2 devices=/dev/hda1,/dev/hdb1
ARRAY /dev/md4 uuid=b23f3c6d:aec43a9f:fd65db85:369432df spare-group=group1
ARRAY /dev/md5 uuid=19464854:03f71b1b:e0df2edd:246cc977 spare-group=group1
ARRAY /dev/md/home UUID=9187a482:5dde19d9:eea3cc4a:d646ab8b auto=part
ARRAY /dev/md9 name='Data Storage'

POLICY domain=domain1 metadata=imsm path=pci-0000:00:1f.2-scsi-* action=spare
POLICY domain=domain1 metadata=imsm path=pci-0000:04:00.0-scsi-[01]* action=include

MAILADDR root@mydomain.tld
PROGRAM /usr/sbin/handle-mdadm-events
CREATE group=system mode=0640 auto=part-8
HOMEHOST ‹system›
AUTO +1.x homehost -all
^
22 mai 2016

htmlpdflatexmanmd




mdmon

mdmon

Supervision des métadonnées md externes

   le kernel 2.6.27 ajoute le support des métadonnées externes. Ces métadonnées externes impliques que l'espace utilisateur gère toutes les mises à jours des métadonnées. La responsabilité du kernel est de notifier l'espace utilisateur quand un événement de métadonnées se produit, tels qu'une erreur disque. Le kernel, dans des cas importants, attends l'espace utilisateur pour prendre une action sur ces notifications.

Mises à jours des métadonnées

   mdmon est un service de mise à jours des métadonnées. mdmon requête l'espace de nom sysfs à la recherche de changements dans les attributs array_state, sync_action et state. Quand un changement est détecté il appel un handler par type de métadonnées pour effectuer les modifications sur les métadonnées. Les actions sont les suivantes:

array_state - inactif Efface le bit dirty pour le volume et laisse l'array stoppé
array_state - write pending Définis le bit dirty pour l'array puis met array_state à actif. Les écritures sont bloquées tant que les écritures de l'espace utilisateur sont actifs
array_state - active-idle Le timer safe mode a expiré pour l'array et définis l'état pour nettoyer les écritures de block dans l'array
array_state - clean Efface le bit dirty pour le volume
array_state - read-only État initial de tous les array au démarrage. mdmon prend une des 3 actions suivantes:

        1/ Transition de l'array vers read-auto conservant le bit dirty effacé si le handler de métadonnées détermine que l'array n'a pas besoin de resynchro ou autre modifications
        2/ Transition de l'array vers actif si le handler de métadonnées détermines qu'une resynchro ou autres manipulations est nécessaire.
        3/ Laisser l'array read-only si le volume est marqué à ne pas superviser.

sync_action - resync-to-idle Notify l'handler de métadonnées qu'une resynchro peut avoir fini. Si un processus de resynchro est en attente avant d'être complété, cet événement permet au handler de métadonnées de vérifier la resynchro
sync_action - recover-to-idle Un spare peut avoir finis la reconstruction donc indique au handler l'état de chaque disque. C'est l'opportunité de l'handler d'effacer les bits out-of-sync et le status dégradé du volume.
‹disk›/state - faulty Une erreur disque déclenche une série d'événements. D'abord, notify le handler qu'un disque a échoué, et notify le kernel qu'il peut débloquer les écritures qui étaient dépendant de ce disque. Ensuite le disque est mis à removed+ de l'array membre. Finallement le disque est marqué en erreur dans tous les autres array membre dans le conteneur.

Conteneurs

   Les formats de métadonnées externe, comme DDF, diffèrent des formats de métadonnées MD natifs dans le sens qu'ils définissent un jeu de disques et une série de sous-array dans ces disques. Les métadonnées en comparaison définissent une relation 1:1 entre un jeu de périphériques block et un array RAID. Par exemple, pour créer 2 array à différents niveaux RAID dans un simple jeu de disques, les métadonnées MD nécessitent que les disques soient partitionnés puis chaque array peut être créé avec un sous-jeu de ces partitions. Les formats externes supportés effectuent cet opération disques en interne.

   Les périphériques conteneur maintiennent simplement les références de tous les disques membre et permet aux outils mdmon de déterminer quels array actifs appartiennent à quel conteneur. Certaines commandes de gestion d'array comme la suppression ou l'ajout de disque sont seulement valides au niveau du conteneur. Les conteneurs sont identifiés dans /proc/mdstat avec une vversion de métadonnées "external:‹metadata name›". Les périphériques membres sont identifiés par "external:/‹container device›/‹member index›", ou "external:-‹container device›/‹member index›" si l'array est lecture seule.

Options

CONTAINER Le périphérique conteneur à superviser. Peut être un chemin complet comme /dev/md/container, ou un simple nom de périphérique md.
--foreground Ne lance pas en tâche de fond
--takeover Instruit mdmon de remplacer un service mdadm déjà en cours d'exécution
--all Trouve tous les conteneurs actifs et démarre le monitoring sur chacun d'entre-eux

Démarrage et arrêt

   mdmon doit être lancé quand un système de fichier dans le périphérique monitoré est monté avec des considérations spéciale quand le système de fichier root est monté depuis un périphérique mdmon supervisé. Noter qu'en général mdmon est nécessaire même si le système de fichier est monté en lecture seule. et certains systèmes de fichier restent en écriture dans ces circonstances, par exemple pour rejouer un journal après un arrêt non propre.

   Quand l'array est assemblé par le code initramfs, mdadm démarre automatiquement mdmon si requis. Cela signifie que mdmon doit être installé dans l'initramfs et doit il doit y avoir un système de fichier en écriture dans lequel mdmon peut créer un pid et un socket. Le système de fichier particulier à utiliser est donné à mdmon à la compilation. défaut: /run/mdadm.

   Une fois le système root instancié avec un pivot_root, mdmon devrait être lancé avec --all --takeover pour que le mdmon lancé dans l'initramfs puisse être remplacé.

   À l'arrêt, mdmon ne devrait pas être terminer avec les autres processus. Vu qu'il maintien un fichier ouvert dans /dev, il n'est pas possible de démonter /dev si c'est un système de fichie séparé

Exemples

Terminer le mdmon en cours d'exécution est terminé et une nouvelle instance est démarré:
mdmon --all-active-arrays --takeover
^
17 janvier 2012

htmlpdflatexmanmd




mesg

mesg

Contrôle les accès en écriture à votre terminal.

OPTIONS

y autorise l'accès en écriture à votre terminal
n Interdit l'accès en écriture à votre terminal

   Sans option, mesg affiche l'état courant. Si vous être loggé sur plusieurs terminaux, vous pouvez définis le statut des autres sessions en utilisant une redirection. Par exemple: mesg n ‹ /dev/pts/46
^
16 septembre 2016

htmlpdflatexmanmd




mime.convs

mime.convs

Fichier de conversion de type mime pour cups

   Le fichier mime.convs définis les filtres disponibles pour convertir les fichiers d'un format à un autre. Les filtres standards supportent text, PDF, PostScript, et de nombreux types de fichiers image.

   Des fitres additionnels sont spécifiés dans le fichiers avec l'extension .convs dans le répertoire de configuration CUPS.

Chaque ligne spécifie les types mime source et de destination, avec un coût relatif associé avec le filtre et le filtre à lancer:
source/type destination/type cost filter
par exemple, pour convertir un PostScript au format cups raster:
application/vnd.cups-postscript application/vnd.cups-raster 50 pstoraster

source/type spécifie le type MIME source
destination/type Spécifie le type MIME de destination
cost Spécifie le coût relatif pour lancer le filtre. Une valeur de 100 signifie que le filtre utilise une grande quantité de ressources, et 0 signifie que le filtre utilise très peu de ressources
filter Spécifie le nom du programme.

^
16 septembre 2016

htmlpdflatexmanmd




mime.types

mime.types

Fichier de description de type mime pour cups

Le fichier mime.types définis les types de fichiers reconnus. Des types de fichiers additionnels sont spécifiés dans les fichiers avec l'extension .types dans le répertoire de configuration cups. Chaque ligne commence avec le type mime et optionellement suivi pasr une série de règles de reconnaissance de fichier:
mime/type [ rule ... rule ]

   Les types sont sensibles à la casse et sont stockés dans l'ordre alphanumérique ascendant.

   Les règles peuvent être groupées en utilisant des parenthèses, jointes avec un '+' pour un ET logique, joint en utilisant ',' ou un espace blanc pour un OU logique, et inversé avec un '!'

Règles

   Les règles prennent 2 formes, une extension de fichier, et les fonction avec des valeurs de tests entre parenthèses

match("pattern") Vrai si le nom de fichier correspond au motif donné
ascii(offset,length) Vrai si length octets commençant à l'offset sont des ASCII valides (CR, NL, TAB, BS, 32-126)
printable(offset,length) Vrai si length octets commençant à l'offset sont des caractères 8-bits ASCII valides (CR, NL, TAB, BS, 32-126, 128-254)
priority(number) Spécifie la priorité relative du type mime. Défaut: 100.
string(offset,"string") Vrai si les octets à l'offset correspondent à la chaîne
istring(offset,"string") Vrai si les octets à l'offset correspondent à la chaîne (insensible à la casse)
char(offset,value) Vrai si l'octet à l'offset est identique à la valeur
short(offset,value) Vrai si l'entier 16-bits big-endian à l'offset est identique à la valeur
int(offset,value) Vrai si l'entier 32-bits big-endian à l'offset est identique à la valeur
locale("string") Vrai si la locale courante correspond à la chaîne
contains(offset,range,"string") Vrai si les octets à l'offset pour la plage d'octet contient la chaîne

Constantes chaînes

   Les constantes chaînes peuvent être spécifiées dans des guillemets double pour les chaînes contenant des espaces blanc et des ‹› pour les chaînes hexadécimales.

Correspondance et priorité

   Quand CUPS doit déterminer le type mime d'un fichier, il vérifie tous les types mimes définis dans les fichiers .types. Quand 2 ou plusieurs types correspondent au fichier, le type choisis dépend du nom du type et de la priorité. Si les types ont la même priorité, les noms sont stockés alphanumériquement dans l'ordre ascendant et le premier type est choisis.

Exemples

Définir 2 types mimes pour des données raster, dont un est un sous-jeu avec une priorité supérieur
application/vnd.cups-raster string(0,"RaSt") string(0,"tSaR") \
    string(0,"RaS2") string(0,"2SaR") \
    string(0,"RaS3") string(0,"3SaR")
    
image/pwg-raster string(0,"RaS2") + \
    string(4,PwgRaster㙌›) priority(150)
^
02 juillet 2010

htmlpdflatexmanmd




mkdir

mkdir

Créer des répertoires

   mkdir crée des répertoires avec les noms spécifiés. par défaut, reporte une erreur si un répertoire existe déjà.

OPTIONS

-m MODE, --mode=MODE définit les bits de permission de fichier des répertoires crées. Utilise la même syntaxe que chmod.
-p, --parents Crée les dossiers parents manquants pour chaque argument. leur bits de mode sont u+rwx.
-v, --verbose Affiche un message pour chaque fichier crée.
-Z CONTEXT, --context=CONTEXT Définit le contexte de sécurité SELinux à utiliser pour créer les répertoires.
^
01 novembre 2016

htmlpdflatexmanmd




mke2fs

mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4, mkfs.ext4dev

Créer un système de fichiers ext2/3/4

OPTIONS

-b block-size Indiquer la taille des blocks en octets. Les tailles valides sont: 1024, 2048 et 4096 octets par block.
-c Vérifier les blocs défectueux avant de créer le système de fichier. Indiqué 2 fois, un test en lecture/écriture plus lent est utilisé.
-C cluster-size Indiquer la taille du cluster en octets pour les systèmes de fichiers utilisant bigalloc. Les valeurs corrects sont entre 2048octets et 256Mo par cluster.
-D Utilise les E/S directs pour l'écriture sur disque. Évite d'utiliser trop de mémoire tampon qui peut influer sur des applications en cours de fonctionnement, mais au prix d'un formattage plus lent.
-e error-behavior Change le comportement du kernel quand des erreurs sont détectés. Dans tous les cas, une erreur force e2fsck au prochain reboot:

        continue Continue l'exécution normalement
        remount-ro Remonte le système de fichier en lecture seule
        panic Créé un kernel panic

-E extended-options Définis des options étendues:

        mmp_update_interval=interval Ajuste l'interval de mise à jours MMP en secondes. 0 = défaut. Doit être inférieur à 300 secondes
        stride=stride-size Configure le système de fichier pour un RAID avec des blocks de système de fichier de stride-size. C'est le nombre de blocks lus ou écris sur disque avant de changer de disque, souvent référré à la taille de chunk.
        stripe_width=stripe-width Configure le système de fichier pour un RAID avec des blocks de système de fichier de stripe-width par stripe. Généralement stride-size * N, où N est le nombre de disques de données dans le RAID.
        offset=offset Créé le système de fichier à un offset depuis le début du périphérique. Utile pour créer des images disques pour les machines virtuelles
        resize=max-online-resize Réserve suffisamment d'espace pour que la table de descripteur de groupe de block puis grandir pour supporter un système de fichier qui a max-online-resize blocks
        lazy_itable_init[= ծ to disable, 1 to enable›] activé et uninit_bg activé, la table d'inode n'est pas complètement initialisée par mke2fs. Accélère l'initialisation du système de fichiers.
        lazy_journal_init[= ծ to disable, 1 to enable›] Activé, l'inde journal n'est pas complètement remplis de 0 par mke2fs. Accélère l'initialisation du système de fichiers.
        num_backup_sb=ծ|1|2› Si sparse_super2 est activé, cette option contrôle s'il y a 0, 1 ou 2 backups des superblocks
        packed_meta_blocks[= ծ to disable, 1 to enable›] Place les bitmaps d'allocation et la table d'inode au début du disque. Nécessite flex_bg, et créé également le journal au début du système de fichier. Utile pour les disques flash qui utilisent SLC flash au début du disque. Maximise également la zone de blocks de données contigus.
        root_owner[=uid:gid] Spécifie le UID/GID du répertoire root. Non spécifié, utilise ceux ayant appelé mke2fs.
        test_fs Définis un flag dans le superblock indiquant qu'il peut être monté en utilisant le code expérimental du kernel, tels que le système de fichier ext4dev
        discard Tente de rejeter les blocks au moment du mkfs (rejeter les blocks initialement est utile dans les disques SSD et les stockages sparse/thin-provisioned). Quand le périphérique annonce qu'il rejète toutes les données à 0, il marques toutes les tables d'inode non encore à 0 comme à 0. Celà accelère l'initialisation du système de fichier. Mis par défaut
        nodiscard Ne tente pas de rejeter les blocks
        quotatype Spécifie les types de quota (usrquota, grpquota, prjquota) qui doivent être activés dans le système de fichier créé. Si project est activé, prjquota sera initialisé également.

-f fragment-size Spécifie a taile de fragments en octets
-F Force mke2fs à créer un système de fichier même si le périphérique spécifié n'est pas une partition dans un périphérique block, ou si d'autres paramètres n'ont pas de sens. Peut être spécifié 2 fois
-g blocks-per-group Spécifie le nombre de blocks dans un groupe de block. Normalement cette option ne devrait pas être utilisée
-G number-of-groups Spécifie le nombre de groupes de blocks qui sont packés ensemble pour créer un plus grand groupe de block virtuel (ou groupe flex_bg). Celà améliore la localité des méta-données et les performances pour les grosses charges de méta-données. Le nombre de groupes doit être une puissance de 2.
-i bytes-per-inode Spécifie le ration octet/inode. mke2fs créé un inode pour chaque bytes-per-inode octets d'espace dans le disque. Il n'est pas possible de changer ce ratio après la création du système de fichier. Noter que redimensionner un système de fichier change le nombre d'inode pour maintenir ce ratio.
-I inode-size Spécifie la taille de chaque inode en octets. Doit être une puissance de 2 supérieur ou égal à 128. Il n'est pas possible de changer cette valeur après la création du système de fichier.
-j Créer un système de fichier avec un journal ext3.
-J journal-options Créé un journal ext3 en utilisant les options spécifiées:

        size=journal-size Créé un journal interne de la taille spécifiée en Mo. Doit être d'au-moins 1024 blocks de système de fichier et maximum 10.240.000 blocks.
        location=journal-location Spécifie l'emplacement du journal. Peut être spécifié soit comme numéro de block, ou comme offset depuis le début du système de fichier en spécifiant une unité (M, G, etc).
        device=external-journal Attache le système de fichier au périphérique block journal spécifié. Le journal externe doit d'abord avoir été créé avec mke2fs -O journal_dev external-journal. Noter que le journal doit avec la même taille de block
        -l filename Lit la liste de blocks défectueux depuis le fichier.
        -L new-volume-label Définis le label pour le système de fichier. (max 16 octets)
        -m reserved-blocks-percentage Spécifie le pourcentage de blocks réservés pour le superuser. Évite la fragmentation, et permet aux services root comme syslogd de continuer de fonctionner correctement que des processus non-privilégiés soient blockés en écriture. Défaut: 5%
        -M last-mounted-directory Définis le dernier réperoire monté pour le système de fichier. Peut être utile pour les utilitaires qui désactivent le dernier répertoire monté pour déterminer où le système de fichier devrait être monté.
        -n  Mode simulation. Ne créé pas de système de fichier, mais affiche se qu'il fait.
        -N number-of-inodes Change le calcul par défaut du nombre d'inodes qui devraient être réservés pour le système de fichier (qui est basé sur le nombre de blocks et le ratio bytes-per-inode).
        -o creator-os Remplace la valeur par défaut du champs "creator operating system" du système de fichier. Ce champ est généralement mis au nom de L'OS pour lequel mke2fs est compilé.
        -O [^]feature[,...] Créé un système de fichier avec les fonctionnalité données. Les fonctionnalités par défaut sont spécifiées dans la section [defaults] de /etc/mke2fs.conf ou dans les sous-sections [fs_types] pour les types d'utilisation tel que spécifié par -T.
        -q Mode silencieux
        -r revision Définis la révision du système de fichier pour le nouveau système de fichier. Défaut: 1
        -S Écris le superblock et les descripteurs de groupe uniquement. Mesure extrême à prendre seulement dans le cas ou tous les superblocks et sauvegardes sont corrompues.
        -t fs-type Spécifie le type de système de fichier (ext2, ext3, ext4, etc) à créer.
        -T usage-type[,...] Spécifie comme le système de fichier est utilisé, pour que mke2fs puisse choisir des paramètres de système de fichier optimals.
        -U UUID Spécifie l'UUID
        -v mode verbeux
        -z undo_file Avant d'écraser un block de système de fichier, écris l'ancien contenu dans un fichier d'undo. Peut être utilisé par e2undo pour restaurer l'ancien contenu. Si aucun nom de fichier n'est spécifié, créé un mke2fs-device.e2undo dans le répertoire spécifié par E2FSPROGS_UNDO_DIR, ou la directive undo_dir dans le fichier de configuration.

Variables d'environnement

MKE2FS_SYNC Non 0, détermine la fréquence d'appel à sync(2) durant l'initialisatio de la table d'inode
MKE2FS_CONFIG Emplacement du fichier de configuration pour mke2fs
MKE2FS_FIRST_META_BG Non 0, sa valeur est utilisée pour déterminer le premier groupe de block méta.
MKE2FS_DEVICE_SECTSIZE Non 0, sa valeur est utilisée pour déterminer la taille de secteur physique
MKE2FS_SKIP_CHECK_MSG Définis, n'affiche pas le message de vérification automatique des systèmes de fichier causés par le compteur de mount ou l'interval de vérification.
^
01 novembre 2016

htmlpdflatexmanmd




mke2fs.conf

mke2fs.conf

Fichier de configuration pour mke2fs

Exemple


[section1]
    tag1 = value_a
    tag1 = value_b
    tag2 = value_c
    
[section 2]
    tag3 = {
        subtag1 = subtag_value_a
        subtag1 = subtag_value_b
        subtag2 = subtag_value_c
    }
    tag1 = value_d
    tag2 = value_e
}

Sections

[options] Contient les relations qui influencent le comportement de mke2fs
[defaults] Contient les paramètres à utiliser par défaut par mke2fs.
[fs_types] Contient les relations qui définissent les paramètres par défaut utilisé pour un système de fichier et une utilisation spécifigue.

[options]

proceed_delay Mis à un entier positif, mke2fs traite après ce délais en seconde, après avoir demandé à l'utilisateur la permission de traiter, même si l'utilisateur n'a pas répondu. Défaut: 0, attend indéfiniment la réponse du client.

[defaults]

base_features Spécifie les fonctionnalités activés pour les systèmes de fichier nouvellement créés.
default_features Fonctionnalités qui devraient être ajoutés ou supprimés des fonctionnalités listées dans base_features.
enable_periodic_fsck (bool) spécifie si une vérification du système de fichier devrait être forcé au boot. À true, vérifie tous les 180 jours, ou après un nombre aléatoire de montage.
force_undo (bool) à true, mke2fs tente toujours de créer un fichier d'undo, même si le fichier peut être gros et peut ralentir la création du système de fichier.
fs_type Type de système de fichier par défaut.
undo_dir Répertoire où placer le fichier d'undo.

   Tous les tags qui peuvent être spécifiés par sous-section peut être définis dans cette section.

[fs_types]

   Chaque tag dans cette section nomme un type de système de fichier ou utilisation qui peut être spécifié avec -t ou -T. Si mke2fs est lancé sous le nom mke2fs.ext4, il utilise le type de système de fichier ext4 et les options dans le tag ext4.

base_features Fonctionnalités initialement activé pour ce type de système de fichier
errors Comportement en cas d'erreur (continue, remount-ro, panic)
features Liste de fonctionnalités qui modifie le jeu de fonctionnalité utilisé par le nouveau système de fichier construit. La syntaxe est la même de l'option -O.
default_features Jeu de fonctionnalité qui devraient être activés ou désactivés après avoir appliqué les fonctionnalités listées dans base_features et features. Peut êtr changé par -O.
auto_64-bit_support (bool) spécifie si mke2fs ajoute automatiquement le 64bits si le nombre de blocks le nécessite. resize_inode est automatiquement désactivé vu qu'il ne supporte pas les numéros de blocks 64bits.
default_mntopts Jeu d'options de montage à activer par défaut.
blocksize Taille de block par défaut.
lazy_itable_init Spécifie si la table d'inode ne devrait pas être initialisé complètement.
journal_location Spécifie l'emplacement du journal
num_backup_sb indique si les systèmes de fichier avec sparse_super2 devraient avoir 0, 1 ou 2 sauvegardes
packed_meta_blocks (bool) spécifie si l'emplacement des bitmaps d'allocation, table d'inode, et journal devraient être localisés au début du système de fichier.
inode_ratio Spécifie le ratio d'inode par défaut
inode_size Taille d'inode
reserved_ratio Pourcentage de blocks réservé pour root
hash_alg Spécifie l'algorithme de hashage utilisé pour les nouveaux système de fichier avec des répertoire b-tree hashés (legacy, half_md4, et tea).
flex_bg_size Spécifie le nombre de groupes de blocks packés ensemble pour en créer un grand virtuel.
options Options étendues additionnelles, équivalent à -E.
discard (bool) Indique que mke2fs doit ignorer le périphérique avant la création du système de fichier
cluster_size Taille de cluster par défaut si bigalloc est activé.
make_hugefiles (boo) permet la création de fichiers pré-alloués comme partie du formattage du système de fichier.
hugefiles_uid UID pour tous les fichiers et répertoires créés par la fonctionnalité make_hugefiles
hugefiles_gid GID pour tous les fichiers et répertoires créés par la fonctionnalité make_hugefiles
hugefiles_umask umask de création utilisé pour créer les fichiers et répertoires par la fonctionnalité make_hugefiles
num_hugefiles Nombre de hugefiles à créer.
hugefiles_slack Spécifie l'espace réservé pour d'autres fichiers
hugefiles_size Taille des huge files. Non spécifié, remplis tous le système de fichier
hugefiles_align Spécifie l'alignement pour le block de début des huges files.
hugefiles_align_disk Spécifie si l'alignement devrait être relatif au début du disque. Défaut: false = aligné au début du système de fichier.
hugefiles_name Spécifie le nom de fichier de base pour les huge files
hugefiles_digits Spécifie la largueur (0 padded) du champs pour le nombre de huge file
zero_hugefiles (bool) spécifie si les blocks 0 sont écris dans les hugefiles à leur création par mke2fs.

[devices]

   Chaque tag dans cette section nomme un périphérique pour que des paramètres par défaut puissent être spécifiés.

fs_type Paramètre par défaut pour l'option -t si non spécifié sur la ligne de commande
usage_types Paramètre par défaut pour l'option -T si non spécifié sur la ligne de commande
^
02 juillet 2010

htmlpdflatexmanmd




mkfifo

mkfifo

Créer des fichiers fifo

   Un FIFO est un fichier spécial qui permet à des processus indépendant de communiquer. Un processus ouvre le fichier FIFO en écriture, et un autre processus ouvre ce même fichier FIFO en lecture.

OPTIONS

-m MODE, --mode=MODE définit le mode des FIFO crées, utilise la même syntaxe que chmod.
-Z CONTEXT, --context=CONTEXT Définis le contexte de sécurité SELinux à utiliser pour créer les FIFO.
^
05 janvier 2014

htmlpdflatexmanmd




mkfontdir

mkfontdir

Créé un index des fichiers fonts dans un répertoire.

   Pour chaque répertoire donné, il lit tous les fichiers de font, et les écrit dans un fichier nommé fonts.dir dans ce répertoire. Le serveur X utilise ce fichier pour trouver les fichiers de fonts. La première ligne de ce fichier donne le nombre de fonts dans le fichier, le reste liste les fonts elles-mêmes.

  Les fichiers de fonts scalables n'incluent pas le le nom de font X, le fichier fonts.scale (créé avec mkfontscale) est utilisé pour les importer dans fonts.dir.

   fonts.alias est utilisé pour mapper de nouveaux noms aux fonts existantes, et devrait être édité à la main. Le format est 2 colonnes séparées par un espace blanc. La première contient l'alias, la seconde le pattern de nom de font. les lignes commençant par '!' sont ignorés. Si aucun des champs ne spécifie le champ size de la font, c'est un alias scalable. Les alias n'ont pas besoin de référencer des fonts dans le même répertoire.

  L'option -e spécifie un répertoire avec des fichiers d'encodage. La liste est écrite dans encodings.dir, ce fichier est utilisé par le serveur X pour trouver les informations d'encodage. Il a le même format que fonts.dir.

OPTIONS

-e  Spécifie un répertoire contenant des fichiers d'encodage. Peut être spécifié plusieurs fois
-n  Ne scan pas ni n'écrit de fichiers de fonts, utile pour générer des répertoires d'encodage uniquement
-p Préfixe à ajouter au chemin des fichiers d'encodage lorsqu'ils sont écrits dans encodings.dir.
-r Garde les répertoires d'encodage non-absolus.
-x suffix Ignore les fichiers de fonts avec le suffixe spécifié
-- Fin des options

Fichiers

fonts.dir Liste des fonts présent dans le répertoire
fonts.scale Liste des fonts scalable présent dans le répertoire
fonts.alias Liste d'alias de fonts
encodings.dir Liste des encodages et leur fichier.
^
05 janvier 2014

htmlpdflatexmanmd




mkfontscale

mkfontscale

Pour chaque répertoire donné, mkfontscale lit les fonts scalables est les liste dans un fichier nommé fonts.scale

OPTIONS

-b Lit les fonts bitmap. ignorés par défaut
-s Ignore les fonts scalable. Avec -b, lit les fichiers fonts.scale
-o filename envoie la sortie du programme dans le fichier spécifié. (défaut: fonts.scale, ou fonts.dir si -b est spécifié)
-x suffix Exclus tous les fichiers avec ce suffix
-a encoding Ajoute l'encodage à la liste des encodages recherchés
-f fuzz Définis la fraction de caractères qui peuvent être manquant dans les grands encodages, en %, défaut 2%
-l Ecrit un fonts.dir utilisable par les implémentations qui ne peuvent pas réencoder les fonts legacy (bdf et pcf).
-e  Spécifie un répertoire contenant des fichiers d'encodage. Peut être spécifié plusieurs fois
-r Garde les répertoires d'encodage non-absolus.
-n  Ne scanne pas ni n'écrit de fichiers de fonts, utile pour générer des répertoires d'encodage uniquement
-- Fin des options
^
01 novembre 2016

htmlpdflatexmanmd




mklost+found

mklost+found

Créer un répertoire lost+found dans un système de fichier étendu linux

   mklost+found est utilisé pour créer un répertoire mklost+found dans le répertoire de travail courant. Il y a normalement un répertoire lost+found à la racine de chaque système de fichier. mklost+found pré-alloue des blocks de disque dans le répertoire lost+found pour que lorsque e2fsck est lancé pour récupérer un système de fichier, il n'a pas besoin d'allouer des blocks dans le système de fichier pour stocker un grand nombre de fichiers non liés. Cela permet de s'assurer que e2fsck n'a pas a allouer de blocks de données durant la récupération d'un système de fichier.

^
02 juillet 2010

htmlpdflatexmanmd




mknod

mknod

Créer des fichiers spéciaux fifo, caractère ou block

   mknod [OPTION]... NAME TYPE [MAJOR MINOR]

  Le terme fichier spécial a une signification spécial sous unix: quelque-chose qui peut générer ou recevoir des données. Généralement, cela correspond à un périphérique physique. La commande mknod crée ce type de fichier. De tels périphériques peuvent être lus soit un caractère à la fois, soit par block. les arguments après le nom sont :

p pour un FIFO
b pour un fichier spécial block
c pour un fichier spécial caractère

   En créant un fichier spécial block ou caractère, les numéros de périphérique major et minor doivent être donnés. Ils peuvent être donnés en hexa, octal ou décimal.

OPTIONS

m MODE, --mode=MODE Définit le mode des fichiers crées, la syntaxe est de type chmod.
-Z CONTEXT, --context=CONTEXT Définit le contexte de sécurité SELinux utilisé pour créer les fichiers.
^
03 novembre 2011

htmlpdflatexmanmd




mkpasswd

mkpasswd

frontend pour crypt(3)

OPTIONS

-S, --salt=STRING salt. Ne doit pas contenir de préfixe tel que $1$
-R, --rounds=NUMBER Nombre de passes. dépendant du chiffrement utilisé
-m, --method=TYPE Méthode utilisé. Peut être md5, des, sha-256, sha-512 ou help
-5 idem à --method=md5
-P, --passwd-fd=NUM Lit le mot de passe depuis le descripteur de fichier NUM au lieu d’utiliser getpass(3).
-s, --stdin identique à --password-fd=0

Variables d'environnement

MKPASSWD_OPTIONS Une liste d’options qui vont être évaluées avant ceux spécifiés sur la ligne de commande.
^
05 novembre 2016

htmlpdflatexmanmd




mkswap

mkswap

Initialise une zone swap

OPTIONS

-c, --check Vérifie le périphérique à la recherche de blocks défectueux. Affiche le compteur de blocks défectueux
-f, --force Force l'opération. Permet de créer une zone swap plus grande que le fichier ou la partition. Sans cette option, mkswap refuse d'écraser le premier block dans une périphérique avec une table de partition.
-L, --label label spécifie un label pour le périphérique.
-p, --pagesize size Spécifie la taille de page en octets.
-U, --uuid UUID Spécifie l'UUID à utiliser
-v, --swapversion 1 Spécifie la version. Obsolète vu que -v 0 n'est plus supportée.

Notes

- La taille utile maximum dépend de l'architecture et de la version du kernel
- Le nombre maximum de page qu'il est possible d'adresser par l'en-tête swap est 4294967295. Le reste est ignoré
- Linux supporte jusqu'à 32 zones de swap.
- mkswap refuse les zone inférieur à 10 pages

Variables d'environnement

LIBBLKID_DEBUG =all Activer la sortie de débogage de libblkid
^
28 mars 2016

htmlpdflatexmanmd




modinfo

modinfo

Affiche des informations sur un module du kernel Linux

   Si le module spécifié n’est pas un fichier, il cherche dans /lib/modules/version/, comme modprobe. Par défaut, liste chaque attribut du module sous la forme champs:valeur.

OPTIONS

-F, --field Affiche seulement les valeurs de champs, une par ligne.
-b basedir, --basedir basedir Répertoire racine pour les modules. Défaut: /
-k kernel Fournis des informations sur un autre kernel que le kernel courant
-0, --null Utilise le caractère ascii 0 pour séparer les valeurs au lieu d’un newline.
-a, --author
-d, --description
-l, --license
-p, --parameters
-n, --filename Raccourcis pour l’auteur, la description, la licence, les paramètres et le nom de fichier, respectivement
^
28 mars 2016

htmlpdflatexmanmd




modprobe

modprobe

Ajoute ou supprime des modules du kernel Linux

   Ajoute ou enlève des modules du kernel Linux. Il n’y a pas de différence entre ’-’ et ’_’ dans les noms de module. Il cherche dans /lib/modules/`uname -r` les modules et autres fichiers, excepté pour le fichier optionnel /etc/modprobe.conf et le répertoire /etc/modprobe.d. modprobe utilise également des options de module spécifiés sur la ligne de commande sous la forme ‹module›.‹option›

   modprobe ne fait rien du module, la résolution de symbole et les paramètres sont vérifiés par le kernel. Les erreurs sont des messages du kernel, visible via dmesg.

   modprobe attend un fichier modules.dep.bin à jours (ou un fichier modules.dep), comme généré par l’utilitaire depmod. Ce fichier liste les modules dont il dépend, et modprobe l’utilise pour ajouter ou enlever ces dépendances automatiquement.

OPTIONS

-a, --all Insert tous les noms de module sur la ligne de commande
-b, --use-blacklist applique les commandes blacklist dans les fichiers de configuration aux noms de modules.
-C, --config Utilise le fichier spécifié au lieu de /etc/modprobe.conf ou /etc/modprobe.d. Cette option est passée aux commandes install ou remove aux autres commandes modprobe dans la variable MODPROBE_OPTIONS
-c, --showconfig Affiche la liste des informations de version des module requis par un module.
--dump-modversions Dump la configuration effective du répertoire de configuration et quitte
-d, --dirname Répertoire où les modules peuvent être trouvés / par défaut
--first-time Normalement modprobe réussi et ne fait rien si un module à insérer est déjà présent ou en supprimant un module qui n’est pas présent. Cette commande fait échouer modprobe dans ce cas.
--force-vermagic Chaque module contient des informations importantes, tels que les version du compileur et du kernel. Si un module échoue au chargement et que le kernel dit que le "version magic" ne correspond pas, vous pouvez utiliser cette option pour le supprimer.
--force-modversion Quand les modules sont compilés avec CONFIG_MODVERSIONS mis, une section détaillant les versions de chaque interface utilisée par le module est créée. Si un module échoue au chargement et que le kernel dit que le module n’a pas la bonne version d’une interface, cette option supprime les informations de version.
-f, --force Tente de supprimer les informations de version. Identique à --force-vermagic et -force-modversion
-i, --ignore-install --ignore-remove ignore les commandes install et remove dans le fichier de configuration du module spécifié
-l, --list Liste tous les module correspondant à "*".
-n, --dry-run, --show Fait tout sauf inserer et supprimer les modules.
-q, --quiet N’affiche pas de message d’erreur
-R, --resolve-alias Affiche tous les noms de module qui matchent un alias
-r, --remove décharge un module
-S, --set-version Définis la version du kernel
--show-depends Liste les dépendances d'un module, incluant le module lui-même. Produit un jeu de modules, un par ligne, préfixé par "insmod" et utilisé par les distributions pour déterminer quels modules inclure dans les images initramfs.
-s, --syslog Syslog les messages d’erreur (LOG_DAEMON avec le level LOG_NOTICE)
-t, --type Restreint -l aux modules dans le répertoire matchant au répertoire donné.
-v, --verbose mode verbeux

Variables d'environnement

MODPROBE_OPTIONS peut être utilisé pour passer des arguments à modprobe
^
22 mars 2016

htmlpdflatexmanmd




module-signing

module-signing

Signature des modules kernel

Présentation

   La facilité de signature de module kernel signe cryptographiquement les modules durant l'installation et vérifie la signature au chargement des modules. Cela augmente la sécurité de kernel en interdisant le chargement des modules non-signés ou les modules signés avec une clé invalide. La signature de module augmente la sécurité en rendant le chargement de code malicieux plus dur dans le kernel. La vérification de la signature est fait par le kernel donc il n'est pas nécessaire d'avoir de clé de confiance dans l'espace utilisateur.

   Cette facilité utilise les certificats X.509 pour encoder les clé publiques. Les signature ne sont pas encodées par un type standard. La facilité supporte actuellement seulement RSA. Les algorithmes de hashage qui peuvent être utilisée sont SHA-1, SHA-224, SHA-256, SHA-384, et SHA-512.

Configuration

   La facilité de signature de module est activée par la section "Enable Loadable Module Support" de la configuration du kernel et en activant CONFIG_MODULE_SIG. Il y a quelques options disponibles:

Require modules to be validly signed CONFIG_MODULE_SIG_FORCE - spécifie le comportement du kernel lorsque la signature d'un module ne peut pas être vérifiée. off, autorise les module non-signés ou non valides, restrictive impose une signature valide.
Automatically sign all modules CONFIG_MODULE_SIG_ALL - Signe les modules automatiquement durant la phase modules_install. À off, les modules doivent être signés manuellement avec scripts/sign-file
Which hash algorithm should modules be signed with? Présente un choix d'algorithmes de hashage pour signer les modules
File name or PKCS#11 URI of module signing key CONFIG_MODULE_SIG_KEY - Définir cette option à une valeur différente que le défaut "certs/signing_key.pem" désactive l'autogénération des clés de signatures. Cette chaîne devrait identifier un fichier contenant une clé privée et son certificat correspondant au format PEM, ou - sur les système où OpenSSL ENGINE pkcs11 est fonctionnel
Additional X.509 keys for default system keyring CONFIG_SYSTEM_TRUSTED_KEYS - Définis un fichier PEM contenant des certificats additionnels qui seront inclus dans le système par défaut.

Générer les clés

   Une paire de clé cryptographique est requise pour générer et vérifier les signatures. Une clé privée est utilisée pour générer une signature et la clé publique correspondante est utilisée pour la vérifier. La clé privée est seulement nécessaire durant le build, et peut être supprimée ensuite. La clé publique est embarquée dans le kernel.

   Dans des conditions normales, CONFIG_MODULE_SIG_KEY est inchangé de son défaut, le build génère automatiquement une nouvelle clé en utilisant openssl s'il n'existe pas de fichier certs/signing_key.pem. certs/x509.genkey est également généré et contient les paramètres openssl.

Par défaut la section req_distinguished_name contient:
[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company

La taille de clé est également définie avec:
[ req ]
default_bits = 4096

Il est également possible de générer manuellement les fichiers avec le fichier x509.genkey:
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 -config x509.genkey -outform PEM -out kernel_key.pem -keyout kernel_key.pem

Clés publiques dans le kernel

   Le kernel contient un jeu de clé publiques qui peuvent être vues par root (cat /proc/keys).

   Au delà la clé publique générée spécifiquement pour la signature de module, des certificats additionnels peuvent être fournis au format PEM référencés par l'option kernel CONFIG_SYSTEM_TRUSTED_KEYS.

   De plus, le code peut prendre des clés publiques depuis un stockage hardware et les ajouter (ex: depuis une base de clé UEFI)

Finalement, il est possible d'ajouter des clé publiques en faisant:
keyctl padd asymmetric "" [.system_keyring-ID] ‹[key-file]›

   Noter cependant que le kernel ne permet que d'ajouter des clés dans .system_keyring s'ils sont signés par une clé déjà présente dans le .system_keyring au moment où elle est ajoutée.

Signer des modules manuellement

   Pour signer manuellement un module, utiliser le script sign-file. Ce script nécessite 4 arguments: l'algorithme de hashage, le nom de la clé privée ou une URI PKCS#11, la clé publique et le module à signer.

exemple:
scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko

   L'algorithme de hashage utilisé ne doit pas correspondre à celui configuré, mais l'algorithme utilisé doit être compilé dans le kernel ou un module chargeable. Si la clé privée nécessite une passphrase ou PIN, il peut être fournis dans la variable d'environnement $KBUILD_SIGN_PIN

Modules signés et stripping

   Un module signé a une signature numérique simplement ajouté à la fin. La chaîne '~ Module signature appended~ .' à la fin diu fichier du module confirme qu'une signature est présente mais ne confirme pas que la signature est valide.

   Les modules signés sont embarqué comme signature hors du conteneur ELF. Donc, ils ne peuvent plus être stripped une fois la signature calculée. Noter que tout le module est le payload signé, incluant les informations de debug présents au moment de la signature.

Charger des modules signés

   Les modules sont chargés avec insmod, modprobe, init_module() ou finit_module(), exactement comme pour les modules non-signés et aucun traitement n'est fait dans l'espace utilisateur. La vérification de la signature est entièrement faite dans le kernel

Signatures non-valides et modules non-signé

   Si CONFIG_MODULE_SIG_FORCE est activé ou enforcemodulesig=1 est fournis au kernel, le kernel va seulement charger les modules signés et valides pour lequel il possède une clé publique. Un module pour lequel le kernel a une clé, mais qui prouve qu'une signature ne correspond pas ne sera pas chargé. Tout module dont la signature n'est pas lisible sera rejeté.

Administrer/protéger la clé privée

   Vu que la clé privée est utilisée pour signer les modules, les virus et malware peuvent l'utiliser pour signer des modules et compromettre l'OS. La clé privée doit être soit détruite, soit placée dans une emplacement sûre et non possédé dans le nœud root du kernel.
^
28 mars 2016

htmlpdflatexmanmd




modules.dep

modules.dep, modules.dep.bin

Liste des dépendances des modules

   Ces fichiers sont générés par depmod. Liste les dépendances pour chaque module dans le répertoire /lib/modules/version. Ils sont utilisés par les utilitaires comme modprobe. Ces fichiers ne sont pas prévus pour être modifié. Utiliser modinfo pour obtenir des informations sur les modules.

^
15 juin 2017

htmlpdflatexmanmd




/etc/moduli

/etc/moduli

moduli Diffie-Hellman

   Le fichier /etc/moduli contient les nombre premier et générateurs pour sshd lors de l'échange de clé Diffie-Hellman.

   Un nouveau moduli peut être généré par ssh-keygen en utilisant un processus à 2 étapes. Un pass initial de génération candidat, utilisant ssh-keygen -G, calcule les nombres qui sont utiles. Puis une passe test, utilisant ssh-keygen -T, fournis au haut niveau d'assurance que les nombres sont premiers et sont sûre pour les opérations DH. Le format moduli est utilisé comme sortie depuis chaque passe.

   Le fichier consiste d'enregistrement, un par modulo, contenant 7 champs:

        timestamp La date du traitement du modulus
        type Spécifie la structure interne (0=inconnu, non testé, 2=safe prime, 4=Sophie Germain)
        tests Indisque le type de tests de primalité (0x00=non testé,0x01=nombre composite, pas premier, 0x02=Sleve of Eratosthenes, 0x04=Probabilistic Miller-Rabin primality tests)
        trials Nombre de primalité effectués dans le modulus
        size Taille du prime en bits
        generator Le générateur recommandé à utiliser avec ce modulus (en hexa)
        modulus Le modulus lui-même en hexadécimal

^
01 février 2014

htmlpdflatexmanmd




more

more

Filtre pour paginer du texte un écran à la fois

OPTIONS

-num taille de l'écran en nombre de ligne.
-d Affiche un message au lieu d'un son en cas de touche illégale.
-l empêche d'effectuer une pause à chaque ^L (form feed).
-f Compte logiquement et non en ligne. (les lignes longues ne sont pas pliées.)
-p Ne pas faire défiler, mais effacer tout l'écran puis affiche le texte
-c Ne pas faire défiler, mais peindre chaque écran depuis le haut, en effaçant les lignes restantes
-s réduit plusieurs lignes blanches en une seule
-u Supprime le soulignement
+/ Spécifie une chaîne à rechercher avant d'afficher chaque fichier
+num Commence au numéro de ligne spécifié

Commandes

   Certaines commandes peuvent être précédées par un nombre décimal appelé k.

h, ? Affiche l'aide
SPACE Affiche les k lignes de texte suivantes (défaut: taille d'écran)
z idem, mais l'argument devient le nouveau défaut
RETURN idem mais le défaut est 1. l'argument devient le nouveau défaut
d, ^D défile k lignes (défaut: 11). l'argument devient le nouveau défaut
q, Q, INTERRUPT Quitte
s Saute k lignes de texte (défaut 1)
f Saute k écran de texte (défaut 1)
b, ^B Saute k écran de texte en arrière (défaut 1) ne fonctionne pas avec les pipe.
' Aller à l'endroit où la précédente recherche a commencée
= Affiche le numéro de ligne courant
/pattern Recherche le k-ième occurrence de l'expression régulière. (défaut 1)
n Recherche le k-ième occurrence de la dernière expression régulière. (défaut 1)
!‹cmd›, :!‹cmd› Exécute ‹cmd› dans un sous shell
v Démarre un éditeur à la ligne courante pris dans $VISUAL ou $EDITOR (défaut 'vi')
^L Redéssine l'écran
:n Va au k-ieme fichier (défaut 1)
:p va au k-ième fichier en arrière (défaut 1)
:f Affiche le nom du fichier courant et le numéro de ligne
. Répète la commande précédente

Variables d'environnement

MORE Spécifie les options pour more
SHELL Shell courant de l'utilisateur
TERM Type de terminal
^
12 février 2015

htmlpdflatexmanmd




mount.glusterfs

mount.glusterfs

script pour monter un volume glusterfs natif

OPTIONS

log-file=LOG-FILE Fichier à utiliser pour les logs
log-level=LOG-LEVEL Sévérité des logs (TRACE, DEBUG, INFO, WARNING, ERROR et CRITICAL)
acl Support des acl
fopen-keep-cache ne vide pas le cache à l'ouverture du fichier
selinux support selinux
worm mode worm
aux-gfid-mount Active l'accès au système de fichier via gfid directement
ro mode lecture seule
enable-ino32=BOOL Utilise des inodes 32-bits au lieu de 64-bits
mem-accounting Active l'accounting de mémoire interne
capability Active la capability fichier
attribute-timeout=SECONDS timeout pour les inodes dans le module fuse (défaut: 1)
entry-timeout=SECONDS timeout pour le module fuse (défaut: 1)
background-qlen=N longueur de file du module fuse (défaut: 64)
gid-timeout=SECONDS timeout de liste de group auxiliaire pour le traducteur fuse (défaut: 0)
negative-timeout=SECONDS timeout négatif dans le module fuse (défaut: 0)
volume-name=VOLUME-NAME nom du volume à utiliser pour le point de montage
direct-io-mode=disable désactive le mode E/S direct
congestion-threshold=N Seuil de congestion du module fuse (défaut: 48)
backup-volfile-servers=SERVERLIST liste de serveurs de backups du volume au format suivant: mount -t glusterfs -obackup-volfile-servers=‹server2›:‹server3›:...:‹serverN› ‹server1›:/‹volname› ‹mount_point›
backupvolfile-server=SERVER liste de serveurs de backups du volume au format suivant: mount -t glusterfs -obackupvolfile-server=‹server2› ‹server1›:/‹volname› ‹mount_point›
background-qlen=N longueur de file du module fuse (défaut: 64)
no-root-squash=BOOL désactive le root squashing pour le client trusté (défaut: off)
root-squash=BOOL Active le root squashing pour le client trusté (défaut: on)
use-readdirp=BOOL mode readdirp
^
03 décembre 2016

htmlpdflatexmanmd




mountstats

mountstats

Afficher divers statistiques client NFS par montage

Sous-commandes

mountstats Affiche une combinaison de statistiques RPC par opération, compteur d'évènements NFS, et compteur d'octets NFS
iostat Affiche des statistiques type iostat
nfsstat Affiche des statistiques type nfsstat

Options générales

-f infile, --file infile Lit les statistiques depuis le fichier au lieu de /proc/self/mountstats. Le fichier doit être dans le même format.
-S sincefile, --since sincefile Affiche la différence entre les statistiques courantes et celles dans le fichier spécifié

Options pour mountstats

-n, --nfs Affiche seulement les statistiques NFS
-r, --rpc Affiche seulement les statistiques RPC
-R, --raw Affiche des statistiques brutes

Options pour iostat

‹interval› Délai en seconde entre chaque rapport
‹count› Nombre de rapport à générer

Options pour nfsstat

-3 uniquement les statistique pour nfsv3
-4 uniquement les statistique pour nfsv4
^
03 février 2016

htmlpdflatexmanmd




msr

msr

Périphérique d'accès au MSR des CPU x86

   /dev/cpu/CPUNUM/msr fournit une interface pour lire et écrire les registres spécifiques au modèle (MSR) d'un processeur x86. CPUNUM est le numéro du processeur d'après la liste dans /proc/cpuinfo

   L'accès au registre se fait en ouvrant le fichier et en se déplaçant dans le fichier à la position égale au numéro du MSR, puis en lisant ou écrivant des blocs de 8 octets. Des transferts de taille supérieure à 8 octets correspondent à plusieurs lectures ou écritures du même registre. Ce fichier est protégé de telle sorte que seul root ou membres du groupe root puissent y accéder.

Notes

   Le pilote msr n'est pas chargé automatiquement. Avec les noyaux modulaires il est possible de le charger avec modprobe msr.
^
12 octobre 2016

htmlpdflatexmanmd




multipath

multipath

Auto-configuration de targets Device Mapper

   multipath est utilisé pour détecter et regrouper les chemins multiples vers des périphériques, pour la tolérance aux pannes ou pour des raisons de performance.

OPTIONS

-v level Niveau de verbosité

        0 Pas de sortie
        1 Affiche les noms créés ou mis à jours uniquement
        2+ Affiche toutes les informations

-d mode simulation
-l Affiche la topologie multipath depuis les informations dans sysfs et device mapper
-ll Affiche la topologie multipath depuis tous les sources d'information disponible
-f Enlève le périphérique multipath spécifié, si inutilisé
-F enlève tous les périphériques multipath non-utilisés
-t Affiche la table hardware interne
-r Force le rechargement devmap
-i Ignore le fichier wwids en traitant les périphériques
-B Traite le fichier bindings en lecture seule
-b bindings_file Spécifie l'emplacement du fichier bindings
-c Vérifie si un périphérique block devrait être un chemin dans un périphérique multipath
-q Autorise les tables de périphérique avec queue_if_no_path quand multipathd n'est pas en cour de fonctionnement
-a Ajoute le wwid pour le périphérique spécifié dans le fichiers wwids
-u Vérifie si le périphérique spécifié dans l'environnement devrait être dans un périphérique multipath
-w Supprime le wwid pour le périphérique spécifié dans le fichier wwid
-W Réinitialise le fichier wwid pour seulement inclure les périphériques multipath courants
-p policy Force les nouveaux mappage à utiliser la stratégie spécifiée:

        failover 1 chemin par groupe de priorité
        multibus Tous les chemins dans un groupe de priorité
        group_by_serial Un groupe de priorité par sérial
        group_by_prio Un groupe de priorité par valeur de priorité.
        group_by_node_name Un groupe de priorité par nom de nœud cible. Les noms sont pris dans /sys/class/fc_transport/target*/node_name
^
12 octobre 2016

htmlpdflatexmanmd




multipath.conf

multipath.conf

Fichier de configuration pour multipath

   Chaque section contient un ou plusieurs attributs ou sous-sections. Les mots clé reconnus pour les attributs ou sous-sections dépendent de la section dans laquelle elles se trouvent. Les sections suivantes sont reconnues:

        defaults Cette section définis les valeurs par défaut pour les attributs qui sont utilisé quand aucune valeur n'est donnée dans le périphérique approprié ou de nom de section
        blacklist Définis quels périphériques devraient être exclus de la découverte de topologie multipath
        blacklist_exceptions Définis quels périphérique devraient être inclus dans la découverte de topologie multipath, même s'ils sont listés dans la section blacklist
        multipaths Définis les topologies multipath. Elles sont indexées par un WWID (Word Wide Identifier)
        devices Définis les paramètres spécifique à un périphérique
        overrides Définis les valeurs pour les attributs qui devraient remplacer les paramèters spécifique au périphérique pour tous les périphériques

Section defaults

verbosity Niveau de verbosité. (de 0 à 6, défaut: 2)
polling_interval Interval entre 2 vérifications de chemin, en seconde. Pour un fonctionnement correcte, l'interval entre les vérifications augmente graduellement jusqu'à max_polling_interval. Cette valeur sera remplacée par le paramètre WatchdogSec dans multipathd.service si systemd est utilisé. (défaut: 5).
max_polling_interval Interval maximum entre 2 vérifications de chemin, en secondes. Défaut: 4 * polling_interval
reassign_maps Active le réassignement des mappages device-mapper. Avec cette option, multipathd remap les mappages DM pour continuellement pointer vers un périphérique multiple, et non les périphériques block sous-jacent. Défaut: no
multipath_dir Répertoire où les objets partagés sont stockés. Défaut: /lib[64]/multipath/
path_selector Chemin par défaut pour l'algorithme à utiliser. Généralement offert par le kernel:

        round-robin 0 Boucle tout chemin dans le groupe de chemin, envoyant la même quantité d'E/S dans chaque
        queue-length 0 Envoie le prochain pool d'E/S sur le chemin ayant le moins de traitement E/S en cours
        service-time 0 Choisi le chemin pour le prochain pool d'E/S basé sur sur la quantité de traitement d'E/S dans le chemin et sa bande passante relative.

path_grouping_policy Stratégie de groupement de chemin par défaut à appliquer aux multipaths non-spécifiés:

        failover On chemin par groupe de priorité
        multibus Tous les chemins dans un groupe de priorité
        group_by_serial Un groupe de priorité par numéro de série
        group_by_prio Un groupe de priorité par valeur de priorité.
        group_by_node_name Un groupe de priorité par nom de nœud cible

uid_attribute Attribut udev fournissant un identifiant unique de chemin
prio Le nom de la routine de priorité de chemin. La routine spécifiée devrait retourner une valeur numérique spécifiant la priorité relative de ce chemin. Actuellement, les routines suivantes sont implémentées:

        const Retourne une priorité constante de 1
        sysfs Utilise les attributs sysfs access_state et preferred_path pour générer la priorité de chemin. Accepte l'option exclusive_pref_bit
        emc dépendant du hardware. Génère la priorité de chemin pour les array de classe DGC
        alua dépendant du hardware. Génère la priorité de chemin basé sur les paramètres SCSI-3 ALUA
        ontap dépendant du hardware. Génère la priorité de chemin pour la classe RDAC LSI/Engenio/NetApp
        hp_sw dépendant du hardware. Génère la priorité de chemin pour les arrays HP/COMPAQ/DEC HSG80 et MSA/HSV
        hds dépendant du hardware. Génère la priorité de chemin pour les arrays Hitachi HDS Modular
        random Génération aléatoire entre 1 et 10
        weightedpath Génère la priorité de chemin basé sur l'expression régulière et la priorité fournie come argument nécessite prio_args

prio_args Arguments à passer à la fonction prio
features Spécifie des fonctionnalités device-mapper à utiliser. La syntaxe est num list ou num est le numéro, entre 0 et 6, des fonctionnalités dans list. Les valeurs possible pour liste sont:

        queue_if_no_path Met en queue si aucun chemin n'est actif
        no_partitions Désactive la génération de partitions automatique via kpartx
        pg_init_retries Nombre de retentatives pg_init, doit être entre 1 et 50
        pg_init_delay_msecs Nombre de secondes avant une retentative pg_init, doit être entre 0 et 60000

path_checker Méthode par défaut à utiliser pour déterminer les états de chemin. Les valeurs possibles sont:

        tur Émet une commande TEST UNIT READY au périphérique
        emc_clarification dépendant du hardware. requête la page spécifique EVPD 0xC0 DGC/EMC pour déterminer l'état de chemin pour les arrays CLARiiON CX/AX et EMC VNX
        hp_sw dépendant du hardware. Vérifie l'état de chemin pour les arrays HP/COMPAQ/DEC HSG80 et MSA/HSV
        rdac dépendant du hardware. Vérifie l'état de chemin pour la classe RDAC LSI/Engenio/NetApp
        cciss_tur dépendant du hardware. Vérifie l'état de chemin pour les contrôleurs HP/COMPAQ Smart Array(CCISS)

alias_prefix Préfix user_friendly. Défaut: mpath
failback Indique comment gérer les erreurs de groupe de chemin:

        immediate failback immédiatement au chemin du groupe à la priorité la plus élevée qui contient des chemins actifs.
        manual N'effectue pas de failback automatique
        followover N'effectue un failback automatique quand quand le premier chemin d'un pathgroup devient actif. Cela permet d'empêcher un nœud d'être rejeté quand un autre nœud demande le failover
        values › 0 Défère le failback (temps en secondes)

rr_min_io Nombre d'E/S à route dans le chemin avant de basculer dans le suivant dans le même groupe de chemin. Uniquement pour le multipath basé sur BIO. Défaut: 1000
rr_min_io_rq Nombre de requêtes d'E/S à router vers un chemin avant de basculer vers le suivant dans le même groupe de chemin. Uniquement pour les requêtes basées sur multipath. Défaut: 1
max_fds Nombre maximum de descripteurs de fichier qui peuvent être ouverts par multipath et multipathd. 'max' prend la valeur dans /proc/sys/fs/nr_open. Si non définis, utilise open_fds du processus appelant. généralement 1024. Pour plus de sécurité devrait être le nombre max de chemins + 32, si ce nombre est supérieur à 1024. Défaut: max
rr_weight à priorities, le configurateur multipath assigne un poid de chemin tel que "path prio * rr_min_io". peut être priorities ou uniform
no_path_retry Spécifie le nombre de retentatives jusqu'à désactiver la queue, ou fail pour échouer immédiatement. queue ne stop jamais la queue. Si non définis, aucune queue n'est tentée
queue_without_daemon à no, quand multipathd stoppe, la queue est désactivée pour tous les périphériques. Utile pour les périphériques qui définissent no_path_retry. Si une machine s'éteint alors que tous les chemins sont down, il est possible de bloquer en attende d'E/S du périphérique après que multipathd ai été stoppé. Sans multipathd, l'accès aux chemins ne peut être restauré, et le kernel ne peut pas indiquer de stopper la queue. Défaut: no
checker_timeout Spécifie le timeout à utiliser pour la vérification de chemin et es prioritiseurs qui émettent des commandes SCSI avec un timeout explicit. Défaut: /sys/block/sd‹x›/device/timeout
flush_on_last_del À yes, multipathd désactive la queue quand le dernier chemin vers un périphérique a été supprimé. Défaut: no
user_friendly_names À yes, en utilisant le fichier /etc/multipath/bindings pour assigner de manière persistante et unique un alias au multipath, sous la forme mpath‹n›. À no, utilise le wwid comme alias.
fast_io_fail_tmo Nombre de secondes d'attente de la couche SCSI après qu'un problème ait été détecté sur un port distant FO avant d'échouer les E/S sur ce port. Devrait être inférieur à dev_loss_tmo. Défaut: 5
dev_loss_tmo Nombre de secondes d'attente de la couche SCSI après qu'un problème ait été détecté sur un port distant FO avant de le supprimer du système. 'infinity' définis à la valeur max (2147483647 secondes, ou 68ans). Il sera automatiquement ajusté à l'interval no_path_retry addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo polling_interval si un nombre de tentatives est donné dans no_path_retry et que l'interval de retentative qlobal est supérieur à dev_loss_tmo. Linux définis cette valeur à 300 si fast_io_fail_tmo n'est pas définis. Défaut: 600
bindings_file Chemin complet du fichier binding à utiliser quand l'option user_friendly_names est définis.
wwids_file Chemin complet du fichier eds WWID, utilisé pour garder une trace des WWID pour les LUN qui ont été créés dans le passé
log_checker_err À 'once', multipathd log la première erreur de vérification de chemin au niveau 2, et les autres erreur au niveau 3 jusqu'à ce que le périphérique soit restauré. À 'always', multipathd logs toujours au niveau 2
reservation_key Clé de réservation d'action du service utilisé par mpathpersist. Il doit être définis pour tous les périphériques multipath utilisant les réservation persistantes, et doit être identique au champ RESERVATION KEY du paramètre PERSISTENT RESERVE OUT.
retain_attached_hw_handler À yes, si la couche SCSI a déjà attaché un hardware_handler au périphérique multipath, multipath ne force pas le périphérique à utiliser celui spécifié dans ce fichier de configuration. Défaut: yes
detect_prio À yes, multipath tente de détecter si le périphérique supporte SCSI-3 ALUA. Si c'est le cas, le périphérique utilisera automatiquement le prioritizer sysfs si les attributs access_state et preferred_path sont supportés, ou le prioritiseur alua le cas échéant.
force_sync À yes, multipathd Vérifie les chemin en mode sync uniquement. Cela signifie que seul un vérificateur tourne à la fois, utile quand les vérificateurs tournant en parallèle créent une surchage CPU.
strict_timinig À yes, multipathd démarre une nouvelle boucle de vérification de chemin après exactement 1 seconde, pour que chaque vérification de chemin se produise exactement à polling_interval secondes. Si les systèmes surchargés, les vérification peuvent prendre plus d'une seconde
deferred_remove À yes, multipathd déferre la suppresion au lieu d'une suppression régulière quand le dernier chemin a été supprimé. Cela signifie que si le périphérique continue à être utilisé, il sera libéré quand le dernier utilisateur le fermera.
partition_delimiter Non définis, quand multipath renomme un périphérique, il agit simplement comme kpartx. ajoute seulement un 'p' aux noms se terminant dans un nombre. Si définis, multipath agit comme "kpartix -p" et ajoute toujours un délimiteur
config_dir Si définis, multipath recherche dans ce répertoire pour des fichiers .conf, et y lit les informations de configuration, tout comme /etc/multipath.conf.
delay_watch_checks › 0, multipathd recherche les chemins qui sont devenus récemment valides durant ce délai.
delay_wait_checks › 0, quand un périphérique qui est récemment revenu online échoue de nouveau dans le délai delay_watch_checks, la prochaine fois qu'il revient online il sera marqué et retardé, et ne sera pas utilisé jusqu'à ce qu'il ait passé ces vérification
find_multipaths À yes, au lieu de tenter de créer un périphérique multipath pour chaque chemin non-blacklisté, multipath créé seulement un périphérique si une des 3 conditions sont rencontrées: 1) il y a au moins 2 chemins non-blacklistés avec le même WWID, 2) l'utilisateur force manuellement la création en spécifinat un périphérique avec la commande multipath, ou 3) un chemin a le même wwid précédemment créé. Défaut: no
uxsock_timeout timeout CLI reçu en ms. Défaut: 1000
retrigger_tries Nombre de fois que multipathd tente de gérer un uevent pour obtenir le WWID. Défaut: 3
retrigger_delay Définis le délai, en secondes, d'attente entre les triggers. Défaut: 10
missing_uev_wait_timeout Contrôle le délai d'attente de multipathd après qu'un nouveau périphérique multipath soit créé, pour reçevoir un évènement de changement de udev pour ce périphérique, avant d'activer automatiquement les reloads de périphérique. Défaut: 30

Section blacklist

devnode expression régulière des périphériques à exclure
wwid Le wwid d'un périphérique
property Expression régulière d'une propriété udev à exclure
device Sous-section pour la description d'un périphérique. Accepte les mots-clé vendor et product

Section blacklist

devnode expression régulière des périphériques à inclure
wwid Le wwid d'un périphérique
property Expression régulière d'une propriété udev à inclure
device Sous-section pour la description d'un périphérique. Accepte les mots-clé vendor et product

Section multipaths

multipath Sous-section décrivant un multipath

        wwid Index du conteneur
        alias nom symbolique pour le mappage multipath
        path_grouping_policy
        path_selector
        prio
        prio_args
        failback
        rr_weight
        no_path_retry
        rr_min_io
        rr_min_io_rq
        flush_on_last_del
        features
        reservation_key
        user_friendly_names
        deferred_remove
        delay_watch_checks
        delay_wait_checks Identiques à la section defaults

Section devices

device Sous-section décrivant un périphérique

        vendor Identifiant de vendeur
        product Identifiant de produit
        revision Identifiant de révision
        product_blacklist Chaîne à blacklister pour ce vendeur
        alias_prefix Préfix user_friendly à utiliser pour ce type de périphérique
        hardware_handler hardware handler à utiliser pour ce type de périphérique:

                emc DGC class arrays as CLARiiON CX/AX and EMC VNX
                rdac LSI/Engenio/NetApp RDAC class
                hp_sw HP/COMPAQ/DEC HSG80 and MSA/HSV arrays
                alua SCSI-3 ALUA compatible arrays

        path_grouping_policy
        uid_attribute
        path_selector
        path_checker
        prio
        prio_args
        features
        failback
        rr_weight
        no_path_retry
        rr_min_io
        rr_min_io_rq
        fast_io_fail_tmo
        dev_loss_tmo
        flush_on_last_del
        retain_attached_hw_handler
        detect_prio
        deferred_remove
        delay_watch_checks
        delay_wait_checks Options identiques à la section defaults

Section overrides

path_grouping_policy
uid_attribute
getuid_callout
path_selector
path_checker
alias_prefix
features
prio
prio_args
failback
rr_weight
no_path_retry
rr_min_io
rr_min_io_rq
flush_on_last_del
fast_io_fail_tmo
dev_loss_tmo
user_friendly_names
retain_attached_hw_handler
detect_prio
deferred_remove
delay_watch_checks
delay_wait_checks Options identiques à la section devices ou defaults
^
12 octobre 2016

htmlpdflatexmanmd




multipathd

multipathd

service multipath

   Le service multipathd est en charge de vérifier les chemins en erreur. Quand celà se produit, il reconfigure la map multipath auquel le chemin appartient, pour que cette map regagne un maximum de performance et de redondance.

   Ce service exécute l'outil de configuration multipath externe quand les événements se produisent. En retour, l'outil multipath signale au service multipathd quand c'est fait avec la reconfiguration devmap, pour qu'il puisse rafraîchir sa liste de path échoués.

OPTIONS

-d Ne met pas en tâche de fond.
-s Supprime l'horodatage
-v level Niveau de verbosité. 0=error. 3 et + affiche beaucoups d'information
-B Liaisons lecture-seule
-k Mode interractif.
-n  Ignore les nouveaux périphériques

Commandes

list|show paths Affiche les chemins que multipathd monitore et leur état.
list|show paths format $format Affiche les chemins que multipathd monitore en utilisant un format spécifié
list|show maps|multipaths Affiche les périphériques multipath que multipathd monitore
list|show maps|multipaths format $format Affiche le status de tous les périphériques multipath qui multipathd gère, en utilisant un format contenant des wildcard
list|show maps|multipaths status Affiche le status de tous les périphériques que multipathd monitore
list|show maps|multipaths stats Affiche des statistiques sur tous les périphériques multipath que multipathd monitore
list|show maps|multipaths topology Affiche la topologie multipath courante. Identique à multipath -ll
list|show topology Affiche la topologie multipath courante. Identique à multipath -ll
list|show map|multipath $map topology Affiche la topologie d'un périphérique multipath spécifié par $map.
list|show wildcards Affiche le format wildcard utilisé dans les commandes interactives
list|show config Affiche la configuration actuelle
List|show blacklist Affiche les règles blacklist courantes
list|show devices Affiche tous les périphériques block par nom et s'il sont blacklistés ou non
list|show status Affiche le nombre de vérificateurs de chemin dans chaque état possible, le nombre de chemins monitorés, et si multipathd gère actuellement un uevent
list|show daemon Affiche l'état du service multipathd
add path $path Ajoute un chemin à la liste des chemins monitorés. $path est tel que listé dans /sys/block
remove|del path $path Arrête de monitorer un chemin
add map|multipath $map Ajoute un périphérique multipath à la liste des périphériques monitorés. $map peut être un périphérique dm tel que listé dans /sys/block, un alias, ou un uid.
remove|del map|multipath $map Arrête de monitorer un périphérique multipath
resize map|multipath $map Redimensionne $map à la taille donnée
switch|switchgroup map|multipath $map group $group Force un périphérique multipath à passer dans un groupe de chemin spécifique. $group est l'index du groupe de chemin, en commençant à 1
reconfigure Reconfigure les multipaths
suspend map|multipath $map Met la $map en pause
resume map|multipath $map Relance une $map en pause
reset map|multipath $map Réassigne des tables dm existants en utilisant le périphérique multipath au lieu de ses chemins
reload map|multipath $map Recharge un périphérique multipath
fail path $path Met le chemin $path à l'état échoué
reinstate path $path Réactive un $path à l'état échoué
disablequeueing maps|multipaths Désactive la queue dans tous les périphériques multipath
restorequeueing maps|multipaths Réactive la queue dans tous les périphériques multipath
disablequeueing map|multipath $map Désactive la queue sur le $map
restorequeueing map|multipath $map Réactive la queue dans le $map
forcequeueing daemon Force multipathd en mode queue_without_daemon pour que la queue no_path_rethy ne se désactive pas quand le service s'arrête
restorequeueing daemon Restaure le mode queue_without_daemon configuré
map|multipath $map setprstatus Active la gestion de réservation persistante sur $map
map|multipath $map unsetprstatus Désactive la gestion de réservaion persistante sur $map
map|multipath $map getprstatus Affiche le status de la gestion de réservation persistante sur $map
quit|exit Quitter la session interactive
shutdown Stop multipathd

Intégration système

   Compilé avec le support systemd, 2 fichiers de service systemd sont installés, multipathd.service et multipathd.socket. Ce dernier instruit systemd d'intercepter le socket de commande CLI, pour que tout appel à l'interface CLI démarre le service si nécessaire. multipathd.service gère les définitions pour contrôler le service. Le service lui-même utilise l'interface sd_notify(3) pour communiquer avec systemd. Les mots clé suivant sont reconnus:

WatchdogSec= Active le watchdogSec interne à systemd. multipath envoie des notifications via sd_notify(3) à systemd pour réinitialiser le watchdog. les paramètres polling_interval et max_polling_interval sont remplacés par les paramètres watchdog.
OOMScoreAdjust= Remplace le mécanisme d'ajustement OOM interne
LimitNOFILE= Remplace le paramètre max_fds
^
30 juin 2010

htmlpdflatexmanmd




mv

mv

Déplace ou renomme des fichiers

   Si 2 noms de fichiers sont spécifiés, déplace le premier fichier dans le second.

  Si -t est donnés ou que le dernier fichier est un répertoire et que -T est donné, déplace chaque fichier source dans le répertoire spécifié.

  mv peut déplacer n'importe quel type de fichier, d'un système de fichier vers un autre. mv essaye toujours de copier les attributs étendus. Si un fichier de destination existe mais n'est pas en écriture, que l'entrée est un terminal, et que -f n'est pas donné, mv demande confirmation pour remplacer le fichier.

OPTIONS

-b, --backup[=METHOD] Créer une sauvegarde de chaque fichier qui aurait été écrasé ou supprimé.
-f, --force Ne demande pas confirmation avant de supprimer un fichier de destination.
-i, --interactive Demande confirmation pour écraser un fichier existant dans la destination.
-n, --no-clobber N'écrase pas un fichier existant
-u, --update Ne déplace pas de fichier autre que répertoire qui a une destionation avec le mtime identique ou plus récent.
-v, --verbose affiche le nom de chaque fichier avant de le déplacer.
--strip-trailing-slashes supprime les '/' de fin de chaque argument de source.
-S SUFFIX, --suffix=SUFFIX ajoute un suffix au fichier de backup crées avec -b
-t DIRECTORY, --target-directory=DIRECTORY Spécifie le répertoire de destination
-T, --no-target-directory ne traite pas le dernier opérande spécialement quand c'est un répertoire ou un lien symbolique.
^
04 mai 2010

htmlpdflatexmanmd




my.cnf

my.cnf

Fichier de configuration MySQL

   Les programmes suivantes supportent les fichiers d'options : myisamchk, myisampack, mysql, mysql.server, mysqladmin, mysqlbinlog, mysqlcc, mysqlcheck, mysqld_safe, mysqldump, mysqld, mysqlhotcopy, mysqlimport et mysqlshow.

  MySQL lit les fichiers suivant:

/etc/my.cnf options globales
DATADIR/my.cnf Options spécifiques au serveur généralement /usr/local/mysql/data ou /usr/local/var pour une installation source
default-extra-file le fichier spécifié par --default-extra-file=#
/.my.cnf options spécifique à l'utilisateur

   MySQL essaie de lire les fichiers d'options dans l'ordre ci-dessus. La syntaxe dans les fichiers d'options est similaire aux options de la commande, sans les doubles tirets.

#comment ou ;comment Commentaires
[group] group est le nom du programme ou du groupe pour lequel vous souhaitez configurer des options.
opt_name est équivalent à --opt_name sur la ligne de commande
opt_name=value est équivalent à --opt_name=value sur la ligne de commande
set_variable = variable=value est équivalent à --set-variable variable=value, utilisé pour spécifier une variable à mysqld.
On peut utiliser les séquences spéciales ‘\b’, ‘\t’, ‘\n’, ‘\r’, ‘\\’ et ‘\s’ dans les valeurs des options pour représenter des effacement, tabulations, nouvelles lignes, retour chariot et espaces. [client]
le group d'options [client] est lu par tous les programmes clients

Exemple

exemple de fichier d'options global typique
[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
key_buffer_size=16M
max_allowed_packet=8M

[mysqldump]
quick

exemple de fichier d'options utilisateur classique
[client]
# Le mot de passe suivant sera envoyé par tous les clients standards MySQL
password="my_password"

[mysql]
no-auto-rehash
set-variable = connect_timeout=2

[mysqlhotcopy]
interactive-timeout

Options communes à tous les programmes

--no-defaults N'utilise aucun fichier d'options.
--print-defaults Affiche le nom du programme et toutes les options qui seront lues dans les fichiers d'options.
--defaults-file=path_name Utilise uniquement le fichier d'options indiqué. path_name est le chemin complet pour y accéder.
--defaults-extra-file=path_name Lit ce fichier d'options après le fichier d'options globales, et avant le fichier d'options utilisateurs. path_name est le chemin complet pour y accéder.

On peut utiliser my_print_defaults pour analyser les fichiers d'options. il prend en argument les groupes à tester. Exemple:
my_print_defaults client mysql
--port=3306
--socket=/tmp/mysql.sock
--no-auto-rehash

mysql_multi

exemple de fichier d'options pour mysqld-multi:
[mysqld_multi]
mysqld = /usr/local/bin/safe_mysqld
mysqladmin = /usr/local/bin/mysqladmin
user = multi_admin
password = multipass

[mysqld2]
socket = /tmp/mysql.sock2
port = 3307
pid-file = /usr/local/mysql/var2/hostname.pid2
datadir = /usr/local/mysql/var2
language = /usr/local/share/mysql/english
user = john

[mysqld3]
socket = /tmp/mysql.sock3
port = 3308
pid-file = /usr/local/mysql/var3/hostname.pid3
datadir = /usr/local/mysql/var3
language = /usr/local/share/mysql/swedish
user = monty

[mysqld4]
socket = /tmp/mysql.sock4
port = 3309
pid-file = /usr/local/mysql/var4/hostname.pid4
datadir = /usr/local/mysql/var4
language = /usr/local/share/mysql/estonia
user = tonu

[mysqld6]
socket = /tmp/mysql.sock6
port = 3311
pid-file = /usr/local/mysql/var6/hostname.pid6
datadir = /usr/local/mysql/var6
language = /usr/local/share/mysql/japanese
user = jani

^
08 mai 2010

htmlpdflatexmanmd




myisamchk

myisamchk

Maintenance des tables et leur recouvrement

   Utilitaire pour vérifier et réparer les tables MyISAM (les tables avec les fichiers .MYI et MYD). Les même concepts s'appliquent à isamchk pour vérifier et réparer les tables ISAM (les tables avec les fichier .ISM et .ISD. myisamchk permet d'obtenir des informations sur les tables de la base de donnée, pour analyser, réparer ou optimiser ces tables. Bien penser à sauvegarder la base avant réparation d'une table. Les opérations qui affectent des index peuvent causer une recompilation des index FULLTEXT avec des paramètres qui ne sont pas les paramètres courants du serveur. Utiliser mysqlcheck pour les commandes, puisque le serveur se charge de tout alors qu'avec myisamchk, vous devez vous assurer que le serveur ne va pas utiliser les tables en même temps que vous.

syntaxe

shell› myisamchk [options] tbl_name
On peut spécifier plusieurs noms de table. On peut aussi spécifier un nom sous la forme d'un fichier d'index (avec l'option .MIY), qui permettra de spécifier toutes les tables dans un dossier en utilisant le schéma *.MIY. Par exemple
shell› myisamchk /path/to/database/*.MYI
Pour vérifier rapidement toutes les tables
myisamchk --silent --fast /path/to/datadir/*/*.MIY
isamchk --silent /path/to/datadir/*/*.ISM
Pour vérifier toutes les tables et réparer celles qui sont corrompue
myisamchk --silent --force --fast --update-state -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM

   L'erreur suivante: myisamchk: warning: 1 clients is using or hasn't closed the table properly

   Signifie que vous essayez de vérifier une table qui a été modifiée par un autre programme (comme le serveur mysqld) qui n'a pas encore refermé le fichier de table, ou que le fichier n'a pas été correctement refermé. Si mysqld fonctionne, vous devez forcer la fermeture correcte des fichiers de tables avec la commande FLUSH TABLES, et vous assurer que personne n'utilise les tables durant vos opérations avec myisamchk.

Options générales de myisamchk

--debug=debug_options, -# debug_options Affiche le log de débogage. La chaîne debug_options vaut souvent : 'd:t:o,filename'.
--silent, -s Mode silencieux. Affiche uniquement les erreurs. Vous pouvez utiliser deux fois -s (-ss) pour que myisamchk soit très silencieux.
--verbose, -v Mode détaillé. Affiche plus d'informations. Vous pouvez combiner ce mode avec les options -d et -e. Utilisez -v plusieurs fois, (-vv, -vvv) pour plus de détails encore.
--version, -V Affiche la version et quitte.
--wait, -w Au lieu de s'arrêter avec une erreur si la table est verrouillé, le programme attend que la table soit libérée avant de continuer. Notez que si vous utilisez mysqld avec l'option --skip-external-locking, la table peut ne peut être verrouillée que par une autre commande myisamchk.

Options de vérifications pour myisamchk

-c, --check Vérifie les erreurs d'une table. Ceci est l'opération par défaut de myisamchk si vous ne lui donnez aucune autre option.
-e, --extend-check Vérifie la table minutieusement (ce qui est un peu lent si vous avez des index). Cette option ne doit être utilisée que pour les cas extrêmes. Normalement, myisamchk ou myisamchk --medium-check devrait, dans la plupart des cas, être capable de trouver s'il y a des erreurs dans la table. Si vous utilisez --extended-check et que vous avez beaucoup de mémoire, vous devez augmenter de beaucoup la valeur de key_buffer_size
-F, --fast Ne vérifie que les tables qui n'ont pas été fermées proprement.
-C, --check-only-changed Ne vérifie que les tables qui ont changé depuis la dernière vérification.
-f, --force Redémarrez myisamchk avec -r (répare) sur la table, si myisamchk trouve une erreur dans la table.
-i, --information Affiche des statistiques à propos de la table vérifiée.
-m, --medium-check Plus rapide que --extended-check, mais ne trouve que 99.99% des erreurs. Devrait, cependant, être bon pour la plupart des cas.
-U, --update-state Enregistre le fichier .MYI lorsque la table à été vérifiée ou a été corrompue. Cela devrait être utilisé pour tirer tous les avantages de l'option --check-only-changed, mais vous ne devez pas utiliser cette option si le serveur mysqld utilise cette table et que vous utilisez mysqld avec --skip-external-locking.
-T, --read-only Ne marque pas la table comme vérifiée. C'est pratique si vous utilisez myisamchk pour vérifier une table issue d'une autre application qui n'utilise pas les verrous. (comme mysqld --skip-external-locking).

Options de réparation de myisamchk

--backup, -B Fait une sauvegarde du fichier .MYD, sous le nom filename-time.BAK
--character-sets-dir=path Dossier qui contient les jeux de caractères.
--correct-checksum Somme de contrôle correcte pour la table.
--data-file-length=#, -D # Taille maximale du fichier de données (lors de la re-création du fichier de données, et qu'il est complet).
--extend-check, -e Essaie de retrouver toutes les lignes possibles du fichier de données. Normalement, cette option va aussi découvrir beaucoup de lignes erronées. N'utilisez pas cette option si vous n'êtes pas totalement désespérés.
--force, -f Écrase les anciens fichiers temporaires (table_name.TMD) au lieu d'annuler.
--keys-used=#, -k # Si vous utilisez les tables ISAM, indique au gestionnaire de table ISAM qu'il doit uniquement modifier les # premiers index. Si vous utilisez le gestionnaire de table MyISAM, cette option indique quelles clés utiliser, et chaque bit binaire représente une clé (la première clé est le bit 0). Cela permet de réaliser des insertions plus rapides. Les index désactivés pourront être réactivés avec l'option myisamchk -r.
--no-symlinks, -l Ne pas suivre les lignes symboliques. Normalement, myisamchk répare les tables qu'un lien symbolique représente.
--parallel-recover, -p Utilise la même technique que -r et -n, mais crée les clés avec des threads différents, en parallèle.
--quick, -q Réparation rapide, sans modifier le fichier de données. Il est possible d'ajouter l'option -q pour forcer myisamchk à modifier le fichier original en cas de clés doublons.
--recover, -r Peut réparer presque tout, sauf les clés uniques qui ne le sont plus (ce qui est extrêmement rare avec les tables ISAM/MyISAM). Si vous voulez restaurer un table, c'est l'option à utiliser en premier. Si myisamchk indique que la table ne peut pas être corrigée avec l'option -r, vous pouvez alors passer à l'option -o. Notez que dans le cas rarissime où -r, le fichier de données est toujours intact. Si vous avez beaucoup de mémoire, vous pouvez augmenter la taille du buffer sort_buffer_size
--safe-recover, -o Utilise une ancienne méthode de restauration (lit toutes les lignes dans l'ordre, et modifie l'arbre d'index conformément pour les lignes trouvées). C'est une méthode qui est beaucoup plus lente que l'option -r, mais elle est capable de traiter certaines situations exceptionnelles que -r ne pourrait pas traiter. Cette méthode utilise aussi moins d'espace disque que -r. Normalement, vous devriez commencer à réparer avec l'option -r, et uniquement sur l'échec de cette option, passer à -o. Si vous avez beaucoup de mémoire, vous devriez augmenter la taille du buffer de clé key_buffer_size
--set-character-set=name Change le jeu de caractères utilisé par l'index.
--sort-recover, -n Force myisamchk à utiliser le tri pour résoudre les clés, même si le fichier temporaire doit être énorme.
--tmpdir=path, -t path Chemin pour stocker les fichiers temporaires. Si cette option n'est pas fournie, myisamchk va utiliser la variable d'environnement TMPDIR pour cela.
--unpack, -u Décompresse des données compressées avec myisampack.

Autres options de myisamchk

-a, --analyze Analyse la distribution des clés. Cela améliore les performances des jointures en permettant à l'optimiseur de jointure de mieux choisir l'ordre d'utilisation des clés. myisamchk --describe --verbose table_name' ou SHOW KEYS dans MySQL.
-d, --description Affiche des informations sur la table.
-A, --set-auto-increment[=value] Force AUTO_INCREMENT à commencer avec une valeur supérieure. Si aucune valeur n'est fournie, la prochaine valeur de la colonne AUTO_INCREMENT sera la plus grande valeur de la colonne +1.
-S, --sort-index Trie les blocs de l'arbre d'index dans l'ordre haut/bas. Cela va optimiser les recherches, et les scans de tables par clés.
-R, --sort-records=# Trie les lignes en fonction de l'index. Cela rassemble vos données, et peut accélérer les lectures de lignes par intervalle avec SELECT et ORDER BY sur cet index (ce tri peut être très lent la première fois). Pour connaître les numéros d'index de tables, utilisez la commande SHOW INDEX, qui affiche les index dans le même ordre que myisamchk ne les voit. Les index sont numérotés à partir de 1.

L'espace mémoire est très important quand on utilise myisamchk
myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...
myisamchk utilise des fichiers temporaires dans le dossier TEMPDIR. Lors de la réparation, il va aussi avoir besoin d'espace disque.

Utiliser myisamchk pour restaurer une table

   si mysqld a l'option --skip-external-locking, on ne peut pas utiliser myisamchk pour vérifier une table. Si vous utilisez myisamchk pour réparer ou optimiser les tables, vous devez toujours vous assurer que mysqld n'utilise pas cette table

Vérifier la cohérence d'une table

cette commande trouvera 99,9% des erreurs
myisamchk nom_de_table
cette commande trouvera 99,999% des erreurs
myisamchk -m nom_de_table
cette commande fait une vérification complète et exhaustive de toutes les données
myisamchk -e nom_de_table
idem mais affiche des informations statistiques
myisamchk -e -i nom_de_table

Réparer les tables

On peut réparer les tables MyISAM avec REPAIR TABLE. Les symptômes de corruption de tables sont des requêtes qui s'interrompent inopinément
tbl_name.frm locked against change: tbl_name.frm est verrouillée en écriture
Can't find file tbl_name.MYI (Errcode : ###): Impossible de trouver le fichier tbl_name.MYI (Errcode: ###)
Unexpected end of file: Fin de fichier inattendue
Record file is crashed: Fichier de données crashé
Got error ### from table handler: Reception de l'erreur ### de la part du gestionnaire de table
Pour obtenir plus d'informations sur l'erreur, vous pouvez exécuter la commande perror

Optimisation de table

Pour réorganiser les lignes fragmentées et éliminer l'espace perdu par les effacements et les modifications
shell› myisamchk -r table_name
de la même manière OPTIMIZE TABLE effectue une réparation de la table, et une analyse des index, puis trie l'arbre d'index pour accélérer les recherches de clé.
myisamchk dispose aussi d'un grand nombre d'options à utiliser pour améliorer les performances de la table
-S, --sort-index
-R index_num, --sort-records=index_num
-a, --analyse
Mettre en place un régime d'entretient de MySQL. Vérifier par un cron une fois par semaine
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
Défragmentation du fichier, mysqld éteint
shell› myisamchk -r -s --sort-index -O sort_buffer_size=16M */*.MYI
Pour les tables ISAM, la commande est similaire à
shell› isamchk -r -s --sort-index -O sort_buffer_size=16M */*.MYI

Obtenir des informations sur une table

Exécute myisamchk en "mode description" pour produire une description de votre table
myisamchk -d nom_de_table
Pour produire plus d'informations durant l'exécution de myisamchk
myisamchk -d -v nom_de_table
Affiche les informations les plus importantes pour une table
myisamchk -eis nom_de_table
C'est l'équivalent de -eis, mais qui vous indique ce qui se passe
myisamchk -eiv nom_de_table
^
08 mai 2010

htmlpdflatexmanmd




myisampack

myisampack, pack_isam

Compresser les tables myisam et isam

   myisampack sert à compresser des tables myisam et pack_isam sert à compresser les tables isam. myisampack fonctionne en compressant séparément chaque colonne de la table. myisampack compresse le fichier avec un gain de 40 à 70%.

- Si mysqld a été appelé avec l'option --skip-external-locking, ce n'est pas une bonne idée que d'appeler myisampack si la table risque d'être mise à jour par le processus principal.
- Une fois compressé, la table n'est plus accessible qu'en lecture seule.
- Myisampack peut aussi compresser les colonnes BLOB et TEXT.

OPTIONS

--backup, -b fait une sauvegarde de la table sous le nom tbl_name.OLD
--force, -f force la compression de la table, même si elle grossit ou si le fichier temporaire existe déjà. Crée alors un fichier tbl_name.TMD lors de la compression.
--join=big_tbl_name, -j big_tbl_name rassemble toutes les tables indiquées dans une seule table appelée big_tbl_name. Toutes les tables appelées doivent être identiques (même noms de colonnes, même types, même index, etc...)
--packlengh=#, -p # Spécifie la taille de stockage de la longueur de ligne, en octets (valeur : 1, 2 ou 3) stocke toutes les lignes avec des pointeurs de lignes de 1, 2 ou 3 octets.
--silent, -s mode silencieux, seules les erreurs seront affichées
--test, -t test simplement la compression
--tmp_dir=path, -T path utilise le dossier temporaire indiqué
--verbose, -v mode détaillé
--wait, -w attend et réessaie, si la table était déjà en cour d'utilisation
^
08 mai 2010

htmlpdflatexmanmd




mysql

mysql

Client MySQL

OPTIONS

--batch, _B Affiche les résultats avec une tabulation comme résultat, et chaque ligne avec une nouvelle ligne. N'utilise pas l'historique.
--character-sets-dir=path Le dossier où les jeux de caractères sont crées.
--compress, _C Utilise la compression avec le protocole client/serveur
--database=db_name, -D db_name La base de données à utiliser, particulièrement pratique dans my.cnf
--debug[=debug_options], -# [debug_options] génère un log de débogage. debug_options vaut souvent 'd:t:o,file_name'. Par défaut : 'd:t:o,/tmp/mysql.trace'
--debug-info, -T Affiche des informations de débogage lorsque le programme se termine.
--default-character-set=charset Jeu de caractère par défaut
--execute=statement, -e statement exécute une commande et quitte. Le résultat est au format de l'option --batch
--force, -f Continue même si vous recevez une erreur SQL
--host=host_name, -h host_name connexion avec l'hôte indiqué.
--html, H produit un résultat au format html
--ignore-space, i ignore les espaces après les noms de fonctions.
--local-infile[=0|1] active ou désactive la possibilité d'utiliser la commande LOCAL pour LOAD DATA INFILE
--named-commands, -G les commandes nommées sont activées. activé par défaut. avec l'option -g le format long des commandes fonctionne.
--no-auto-rehash, -A pas de rehashage automatique, mysql se lance plus rapide, mais vous devez utiliser rehash pour utiliser la complétion de noms de tables.
--no-beep, -b ne fait pas de bips en cas d'erreur
--no-named-commands, -g désactive les commandes nommées
--no-pager désactive le système de page, et affiche directement dans la sortie standard.
--no-tee Désactive le fichier de sortie
--one-database, O ne modifie que la base par défaut. Pratique pour éviter les modifications dans les autres bases dans le fichier de log.
--pager[=command] type d'affichage. les pageurs valides sont less, more, cat (› filename), etc.
--password[=password), -p[password] mot de passe de connexion au serveur.
--port=port_num, -P port_num numéro de port TCP pour la connexion.
--prompt=format_str modifie le format de l'invite de commande
--protocol=TCP|SOCKET|PIPE|MEMORY spécifie le protocole de connexion à utiliser
--quick, -q ne met pas en cache le résultat, et l'affiche ligne par ligne. N'utilise pas le fichier d'historique.
--raw, -r écrit les valeurs des colonnes dans les conversions de protections, utilisé en mode --batch
--reconnect si la connexion est perdue, essaie de se reconnecter automatiquement au serveur, une seule fois. Pour supprimer la reconnexion automatique, utiliser --skip-reconnect.
--safe-updates, --i-am-a-dummy, -U N'autorise que les commandes UPDATE et DELETE qui utilisent des clés. --safe-updates pour annuler.
--silent, -s mode très silencieux
--skip-column-names, -N n'écrit pas les noms de colonnes dans les résultats.
--skip-line-numbers, -L N'écrit pas les numéros de lignes dans les erreurs. Pratique pour comparer des résultats qui incluent des messages d'erreurs.
--socket=path, -S path Le fichier de socket à utiliser pour la connexions
--table, -t affichage au format de table. mode par défaut pour le mode non-batch
--tee=file_name ajoute tout dans le fichier de sortie. ne fonctionne qu'en mode batch
--unbuffered, -n vide le buffer de requête après chaque requêtes
--user=user_name, -u user_name nom d'utilisateur pour la connexion.
--verbose, -v mode verbeux
--vertical, -E affiche le résultat d'une requête verticalement. sans l'option, utiliser \G pour obtenir le même résultat.
--wait, -w attend et retente si la connexion s'interrompt au lieu de quitter.
--xml, -X affiche le résultat au format XML, put également se spécifier par --var=OPTION:

        connect_timeout Nombre de secondes avant que la connexion n'expire. Valeur par défaut: 0.
        max_allowed_packet Taille maximale du paquet de communication avec le serveur. Valeur par défaut : 16777216.
        max_join_size Limite automatique pour les commandes de jointure avec l'option --i-am-a-dummy. Valeur par défaut: 1 000 000 (un million).
        net_buffer_length Buffer pour les communications TCP/IP et socket. Valeur par défaut: 16 ko.
        select_limit Limite automatique pour les commandes SELECT avec l'option --i-am-a-dummy Valeur par défaut: 1000.

Exemples avec pager

Écrire les résultats dans un fichier
mysql› pager cat › /tmp/log.txt
passer les options que le page comprendra
mysql› pager less -n -i -S
-S de less rend le résultat plus lisible
Dans cet exemple, la commande va envoyer les résultats de la commande dans deux fichiers différents, dans deux dossiers différents, placés dans deux répertoires /dr1 et /dr2, mais affichera toujours le résultat à l'écran via less.
mysql› pager cat | tee /dr1/tmp/res.txt | tee /dr2/tmp/res2.txt | less -n -i -S

Exemple pour le prompt

\v version de mysqld
\d database en cours
\h hôte MySQL
\p port de connexion
\u nom d'utilisateur
\U Identifiant complet username@host
\\ ‘\’
\n nouvelle ligne
\t tabulation
\ espace
\_ espace
\R heure 24h (0-23)
\r heure 12h (1-12)
\m minutes
\y année sur deux chiffres
\Y année sur quatre chiffres
\D format de date complet
\s secondes
\w jour de la semaine en trois lettres (Mon, Tue, ...)
\P am/pm \o mois au format numérique
\O mois en trois lettres (Jan, Feb, ...)
\c compteur du nombre de commande

Exemple avec la variable d'environnement MYSQL_PS1

shell› export MYSQL_PS1="(\u@\h) [\d]› "
ou dans le fichier d'options
[mysql]
prompt=(\\u@\\h) [\\d]›\\_
^
04 mai 2010

htmlpdflatexmanmd




MySQL - concept général

MySQL - concept général

Système de gestion de base de données

   MySQL est un système de gestion de base de données, un serveur de bases de données relationnelles. Une base de données est un ensemble organisé de données. SQL signifie « Structured Query Language »

Emplacement des fichiers

/usr/bin Programmes clients
/usr/sbin serveur mysqld
/var/lib/mysql Fichiers de log et bases de données
/usr/share/doc/packages Documentation
/usr/share/mysql Fichiers de messages d'erreurs et jeux de caractères
sql-bench Suites de tests

Comptes par défaut

   Le script mysql_install_db démarre le serveur mysqld et initialise les tables de droits, avec les paramètres suivants:

  Deux comptes MySQL root sont créés en tant qu'administrateurs ayant tous les droits. Le mot de passe de l'utilisateur initial root est vide ou définit pendant l'installation.

  Deux comptes utilisateur anonyme sont créés, qui peuvent faire ce qu'ils veulent avec toutes les tables dans la base de données 'test' ou commençant par 'test_'. Cela signifie qu'un utilisateur peut se connecter sans mot de passe et être traité comme un utilisateur anonyme.

  Les connexions doivent être faîtes en spécifiant le nom d'hôte. Ces comptes ont tous les droits dans les bases test ou dont le nom commence par test_.

Pour modifier les mots de passe utiliser SET PASSWORD
shell› mysql -u root
mysql› SET PASSWORD FOR ''@'localhost' = PASSWORD('nouveau_mot') ;
mysql› SET PASSWORD FOR ''@'host_name' = PASSWORD('nouveau_mot') ;
Pour connaître le host_name taper
mysql› SELECT Host, User FROM mysql.user ;
On peut utiliser la commande UPDATE pour changer les mots de passe des comptes anonymes.
shell› mysql -u root
mysql› UPDATE mysql.user SET Password = PASSWORD('nouveau_mot') WHERE User = '' ;
flush privileges demande au serveur de relire les tables de droits
mysql› FLUSH PRIVILEGES ;
si on préfère supprimer les comptes anonymes
shell› mysql -u root
mysql› DELETE FROM mysql.user WHERE User = '' ;
mysql› FLUSH PRIVILEGES ;

Introduction

Connexion au serveur MySql
mysql -h hote -u utilisateur -p
pour se déconnecter
QUIT ou EXIT
pour obtenir le numéro de version du serveur MySQL
SELECT VERSION(), CURRENT_DATE ;
entrer plusieurs requêtes sur une seule ligne
SELECT VERSION() ; SELECT NOW() ;
entrer une commande sur plusieurs, ligne : la fin d'une requête se termine par ' ;'
mysql› SELECT
-› USER()
-› ,
-› CURRENT_DATE ;
Annuler une requête en cour de frappe, sur une seule ligne taper
\c
afficher les bases de données existantes
SHOW DATABASES ;
accéder à une base
use test
créer une base de donnée
create database test ;
se connecter à mysql directement dans une base
mysql -u utilisateur -ppassword test
créer une table
CREATE TABLE animal (nom VARCHAR(20), maitre VARCHAR(20),
-› espece VARCHAR(20), sexe CHAR(1), naissance DATE, mort DATE) ;
pour afficher la structure de la table
describe animal ;
créer un fichier pour remplir une table, chaque champ doit être séparé par une tabulation
pour importer un fichier dans une table :
LOAD DATA LOCAL INFILE "animal.txt" INTO TABLE animal ;
ajouter des enregistrement un par un (utiliser NULL pour indiquer une valeur manquante)
mysql› INSERT INTO animal
-› VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL) ;
récupérer des informations
SELECT quoi_selectionner
FROM quel_table
WHERE conditions_a_satisfaire
pour tout sélectionner
SELECT * from animal ;
corriger une erreur dans une table, il existe au moins 2 façons de le faire. la première consiste a vider la table, corriger le fichier et le recharger
mysql› SET AUTOCOMMIT=1 ; # Utilisé pour une recréation rapide de la table
mysql› DELETE FROM animal ;
mysql› LOAD DATA LOCAL INFILE "animal.txt" INTO TABLE animal ;
ou corriger l'enregistrement avec update
mysql› UPDATE animal SET naissance = "1989-08-31" WHERE nom = "Bowser" ;
sélectionner des lignes particulières :
mysql› SELECT * FROM animal WHERE nom = "Bowser" ;
avec les booléennes
mysql› SELECT * FROM animal WHERE espece = "chien" AND sexe = "f" ;
plus complexe
mysql› SELECT * FROM animal WHERE (espece = "chat" AND sexe = "m")
-› OR (espece = "chien" AND sexe = "f") ;
sélectionner des colonnes
mysql› SELECT nom, naissance FROM animal ;
pour minimiser le résultat à des champs uniques utiliser DISTINCT
mysql› SELECT DISTINCT maitre FROM animal ;
trie des enregistrements
mysql› SELECT nom, naissance FROM animal ORDER BY naissance ;
pour trier en respectant la casse
mysql› SELECT nom, naissance FROM animal ORDER BY BINARY naissance ;
pour trier dans l'ordre décroissant
mysql› SELECT nom, naissance FROM animal ORDER BY naissance DESC ;
on peut trier sur plusieurs colonnes
mysql› SELECT nom, espece, naissance FROM animal ORDER BY espece, naissance DESC ;
ici l'ordre décroissant n'est appliqué qu'à naissance.

Calcul des Dates

Pour calculer l'âge par rapport à une date de naissance, il faut calculer la différence entre l'année en cour et l'année de naissance, puis soustraire la date courante si la date du jour se produit plus tôt dans l'année civile que la date de naissance
mysql› SELECT nom, naissance, CURRENT_DATE,
-› (YEAR(CURRENT_DATE)-YEAR(naissance))
-› - (RIGHT(CURRENT_DATE,5)‹RIGHT(naissance,5))
-› AS age
-› FROM animal ;
YEAR extrait l'année de la date et RIGHT(naissance,5) extrait les 5 caractères les plus à droite de la date qui représente MM-DD (année civile).
Pour calculer l'âge d'un animal à sa mort, s'il est déjà mort
mysql› SELECT nom, naissance, mort,
-› (YEAR(mort)-YEAR(naissance)) - (RIGHT(mort,5)‹RIGHT(naissance,5))
-› AS age
-› FROM animal WHERE mort IS NOT NULL ORDER BY age ;
si l'animal est mort, le champ mort est différent de NULL.
pour afficher dans combien de mois est leur anniversaire
mysql› SELECT nom, naissance, MONTH(naissance) FROM animal ;
ceux dont l'anniversaire est dans 5 mois :
mysql› SELECT nom, naissance FROM animal WHERE MONTH(naissance) = 5 ;
autres valeurs utilisables : YEAR(), MONTH(), et DAYOFMONTH().
on peut utiliser des fonctions de calcul d'intervalle
mysql› SELECT nom, naissance FROM animal
-› WHERE MONTH(naissance) = MONTH(DATE_ADD(NOW(), INTERVAL 1 MONTH)) ;
autre manière pour un résultat similaire
mysql› SELECT nom, naissance FROM animal
-› WHERE MONTH(naissance) = MOD(MONTH(NOW()), 12) + 1 ;
valeur NULL : on ne peut pas utiliser de comparateur : '=', '‹', '›' ou '‹›'. il faut utiliser IS NULL ou IS NOT NULL.

Recherche de modèles

'_' représente n'importe quel caractère, '%' un nombre arbitraire de caractères. on n'utilise pas = ni ‹› mais LIKE et NOT LIKE.
mysql› SELECT * FROM animal WHERE nom LIKE "b%" ;
mysql› SELECT * FROM animal WHERE nom LIKE "%w%" ;
mysql› SELECT * FROM animal WHERE nom LIKE "_____" ;
les expressions régulières étendues. avec ce type de modèle, utiliser REGEXP et NOT REGEXP ou RLIKE et NOT RLIKE
'.' représente n'importe quel caractère, [...] n'importe quel caractère inclus entre les crochets, fonctionne aussi comme [a-z].
'*' nombre arbitraire de caractère, '^' pour spécifier en début de chaîne ou '$' en fin de chaîne. REGEXP n'est pas sensible à la casse, utiliser binary pour la respecter.
mysql› SELECT * FROM animal WHERE nom REGEXP "^b" ;
mysql› SELECT * FROM animal WHERE nom REGEXP "^[bB]" ;
mysql› SELECT * FROM animal WHERE nom REGEXP BINARY "^b" ;
mysql› SELECT * FROM animal WHERE nom REGEXP "fy$" ;
REGEXP cherche le motif recherché donc pas besoin de * au contraire de LIKE :
mysql› SELECT * FROM animal WHERE nom REGEXP "w" ;
pour recherche une chaîne exacte : .n signifie répéter n fois.
mysql› SELECT * FROM animal WHERE nom REGEXP "^.....$" ;
mysql› SELECT * FROM animal WHERE nom REGEXP "^.5$" ;

Compter les lignes

La fonction COUNT() compte le nombre de résultats non NULL
mysql› SELECT COUNT(*) FROM animal ;
mysql› SELECT maitre, COUNT(*) FROM animal GROUP BY maitre ;
la clause GROUP BY est nécessaire pour grouper tous les enregistrements par maître, sinon on a une erreur
mysql› SELECT espece, sexe, COUNT(*) FROM animal GROUP BY espece, sexe ;
mysql› SELECT espece, sexe, COUNT(*) FROM animal
-› WHERE espece = "chien" OR espece = "chat"
-› GROUP BY espece, sexe ;
mysql› SELECT espece, sexe, COUNT(*) FROM animal
-› WHERE sexe IS NOT NULL
-› GROUP BY espece, sexe ;

Utiliser plus d'une table

mysql› SELECT animal.nom,
-› (TO_DAYS(date) - TO_DAYS(naissance))/365 AS age, remarque
-› FROM animal, evenement
-› WHERE animal.nom = evenement.nom AND type = "mise bas" ;
on peut joindre une table sur elle-même
mysql› SELECT p1.nom, p1.sexe, p2.nom, p2.sexe, p1.espece
-› FROM animal AS p1, animal AS p2
-› WHERE p1.espece = p2.espece AND p1.sexe = "f" AND p2.sexe = "m" ;
Obtenir des informations à propos des bases de données et des tables
Show databases
montrer dans quelle base on est
select database()
montrer les tables
Show Tables
afficher les champs de la table
Describe animal

Utilisation de mysql en mode batch

Pour utiliser mysql en mode batch, placer les commandes dans un fichier et utiliser la commande
mysql ‹ fichier-batch
capturer l'affichage
mysql ‹ fichier.batch › mysql.out
la sortie en mode batch est différente du mode interactif, pour obtenir le même affichage utiliser l'option mysql -t . Pour écrire les commandes
mysql -vvv.
pour exécuter un fichier depuis la commande
source nom_fichier

Exemples de requêtes usuelles

valeur maximale d'une colonne
SELECT MAX(article) AS article FROM shop
la ligne contenant le maximum d'une certaine colonne
SELECT article, dealer, price FROM shop WHERE price=(SELECT MAX(price) FROM shop) ;
la même chose en triant dans l'ordre décroissant, puis afficher la première ligne
SELECT article, dealer, price FROM shop ORDER BY price DESC LIMIT 1 ;
maximum d'une colonne par groupe
SELECT article, MAX(price) AS price FROM shop GROUP BY article
la ligne contenant la plus grande valeur d'un certain champ par rapport à un groupe
SELECT article, dealer, price FROM shop s1 WHERE price=(SELECT MAX(s2.price) FROM shop s2 WHERE s1.article = s2.article) ;
la même en plusieurs étapes, en créant une table temporaire
CREATE TEMPORARY TABLE tmp (
article INT(4) UNSIGNED ZEROFILL DEFAULT '0000' NOT NULL,
price DOUBLE(16,2) DEFAULT '0.00' NOT NULL) ;
LOCK TABLES shop read ;
INSERT INTO tmp SELECT article, MAX(price) FROM shop GROUP BY article ;
SELECT shop.article, dealer, shop.price FROM shop, tmp
WHERE shop.article=tmp.article AND shop.price=tmp.price ;
UNLOCK TABLES ;
DROP TABLE tmp ;
ou encore (en une étape)
SELECT article,
SUBSTRING( MAX( CONCAT(LPAD(price,6,'0'),dealer) ), 7) AS dealer,
0.00+LEFT( MAX( CONCAT(LPAD(price,6,'0'),dealer) ), 6) AS price
FROM shop
GROUP BY article ;
Utiliser les variables utilisateur. Trouver l'article avec le plus haut et le plus bas prix
mysql› SELECT @min_price :=MIN(price),@max_price :=MAX(price) FROM shop ;
mysql› SELECT * FROM shop WHERE price=@min_price OR price=@max_price ;
utiliser les clés étrangères
CREATE TABLE person (
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
name CHAR(60) NOT NULL,
PRIMARY KEY (id)
) ;
CREATE TABLE shirt (
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
style ENUM('t-shirt', 'polo', 'dress') NOT NULL,
color ENUM('red', 'blue', 'orange', 'white', 'black') NOT NULL,
owner SMALLINT UNSIGNED NOT NULL REFERENCES person(id),
PRIMARY KEY (id)
) ;
INSERT INTO person VALUES (NULL, 'Antonio Paz') ;
INSERT INTO shirt VALUES
(NULL, 'polo', 'blue', LAST_INSERT_ID()),
(NULL, 'dress', 'white', LAST_INSERT_ID()),
(NULL, 't-shirt', 'blue', LAST_INSERT_ID()) ;
INSERT INTO person VALUES (NULL, 'Lilliana Angelovska') ;
INSERT INTO shirt VALUES
(NULL, 'dress', 'orange', LAST_INSERT_ID()),
(NULL, 'polo', 'red', LAST_INSERT_ID()),
(NULL, 'dress', 'blue', LAST_INSERT_ID()),
(NULL, 't-shirt', 'white', LAST_INSERT_ID()) ;

SELECT * FROM person ;
+----+---------------------+
|-id-|---------name--------|
+----+---------------------+
|--1-|-Antonio-Paz---------|
|--2-|-Lilliana-Angelovska-|
+----+---------------------+

SELECT * FROM shirt ;
+----+---------+--------+-------+
|-id-|--style--|-color--|-owner-|
+----+---------+--------+-------+
|--1-|-polo----|-blue---|----1--|
|--2-|-dress---|-white--|----1--|
|--3-|-t-shirt-|-blue---|----1--|
|--4-|-dress---|-orange-|----2--|
|--5-|-polo----|-red----|----2--|
|--6-|-dress---|-blue---|----2--|
|--7-|-t-shirt-|-white--|----2--|
+----+---------+--------+-------+

SELECT s.* FROM person p, shirt s WHERE p.name LIKE 'Lilliana%' AND s.owner = p.id AND s.color ‹› 'white' ;
+----+-------+--------+-------+
|-id-|-style-|-color--|-owner-|
+----+-------+--------+-------+
|--4-|-dress-|-orange-|-2-----|
|--5-|-polo--|--red---|-2-----|
|--6-|-dress-|-blue---|-2-----|
+----+-------+--------+-------+

Recherche sur deux clefs
SELECT champ1_index, champ2_index FROM test_table WHERE champ1_index = '1'
OR champ2_index = '1'
avec UNION
SELECT field1_index, field2_index FROM test_table WHERE field1_index = '1'
UNION
SELECT field1_index, field2_index FROM test_table WHERE field2_index = '1' ;
calcul du nombre de visites par jour
CREATE TABLE t1 (year YEAR(4), month INT(2) UNSIGNED ZEROFILL,
day INT(2) UNSIGNED ZEROFILL) ;
INSERT INTO t1 VALUES(2000,1,1),(2000,1,20),(2000,1,30),(2000,2,2),
(2000,2,23),(2000,2,23) ;
SELECT year,month,BIT_COUNT(BIT_OR(1‹‹day)) AS days FROM t1
GROUP BY year,month ;
Utiliser AUTO_INCREMENT. L'attribut AUTO_INCREMENT peut être utilisé pour générer un identifiant unique pour les nouvelles lignes
CREATE TABLE animals (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
name CHAR(30) NOT NULL,
PRIMARY KEY (id)
) ;
INSERT INTO animals (name) VALUES ("dog"),("cat"),("penguin"),
("lax"),("whale"),("ostrich") ;
SELECT * FROM animals ;
On peut récupérer la valeur utilisée de la clé AUTO_INCREMENT avec la fonction LAST_INSERT_ID() ou la fonction API mysql_insert_id().
Pour les tables MyISAM et BDB on peut spécifier AUTO_INCREMENT sur une colonne secondaire d'une clef multi-colonnes. Dans ce cas la valeur généré est calculée de la façon suivante :
MAX(auto_increment_column)+1) WHERE prefix=given-prefix .
Utile lorsqu'on veut placer des données dans des groupes ordonnés.
CREATE TABLE animals (
grp ENUM('fish','mammal','bird') NOT NULL,
id MEDIUMINT NOT NULL AUTO_INCREMENT,
name CHAR(30) NOT NULL,
PRIMARY KEY (grp,id)
) ;
INSERT INTO animals (grp,name) VALUES("mammal","dog"),("mammal","cat"),
("bird","penguin"),("fish","lax"),("mammal","whale"),
("bird","ostrich") ;
SELECT * FROM animals ORDER BY grp,id ;

Qui retourne :
+--------+----+---------+
|--grp---|-id-|-name----|
+--------+----+---------+
|-fish---|--1-|-lax-----|
|-mammal-|--1-|-dog-----|
|-mammal-|--2-|-cat-----|
|-mammal-|--3-|-whale---|
|-bird---|--1-|-penguin-|
|-bird---|--2-|-ostrich-|
+--------+----+---------+

Utilisation de MySQL avec Apache

Pour changer le format d'archivage d'Apache dans MySQL pour le rendre plus lisible, mettre ceci dans la configuration d'Apache :
LogFormat \
"\"%h\",%%Y%m%d%H%M%St,%›s,\"%b\",\"%Content-Typeo\", \
\"%U\",\"%Refereri\",\"%User-Agenti\""
Avec MySQL, vous pouvez exécuter une requête de cette manière :
LOAD DATA INFILE '/local/access_log' INTO TABLE table_name
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\'

Administration du serveur

mysqld est le serveur MySQL
mysqld-max version du serveur qui inclut des fonctionnalités supplémentaires
mysqld-safe est un script de démarrage du serveur. Tente de démarrer mysqld-max s'il existe sinon mysqld.
mysql.server est un script de démarrage du serveur, utilisé sur les systèmes qui ont un dossier contenant des services système. Il invoque mysqld-safe pour démarrer le serveur.
mysqld_multi est un script de démarrage qui peut lancer ou arrêter différentes instances du serveur, installées sur le système.
mysql_install_db crée les tables de droits MySQL, avec les droits par défaut.
mysql_fix_privilege_tables script utilisé après une mise à jour de MySQL pour mettre à jour les tables de droits, et les adapter aux nouvelles versions de MySQL.
myisamchk utilitaire pour décrire, vérifier, optimiser et réparer les tables MyISAM
make_binary_distribution crée une version compilée de MySQL.
mysqlbug script de rapport de bug de MySQL.

   Pour connaître les moteurs de stockage que votre serveur supporte, utiliser la commande SHOW ENGINES; safe_mysqld est la méthode recommandée pour démarrer un démon mysqld. Il ajoute des fonctionnalités de sécurité telles que le redémarrage automatique lorsqu'une erreur survient et l'enregistrement d'informations d'exécution dans un fichier de log. Par défaut il essaie de lancer mysqld-max s'il existe. Pour remplacer le comportement par défaut et spécifier explicitement le serveur à utiliser, spécifier --mysqld ou --mysqld-version.

Le mode SQL du serveur

   Le serveur MySQL peut fonctionner avec différents modes SQL, et peut s'appliquer au niveau de la connexion du client. Cela permet aux applications d'adapter le comportement du serveur en fonction de leur attentes. Le mode définit quelle syntaxe SQL le serveur doit supporter, et quels types de vérification il doit faire. Pour donner un mode par défaut au démarrage : --sql-mode="modes". On peut modifier le mode à chaud avec SET [SESSION|GLOBAL] sql_mode='modes'

Modes

ANSI change la syntaxe et le comportement pour être plus compatible avec le standard SQL
STRICT_TRANS_TABLES Si une valeur n'a pu être insérée dans une table transactionnelle sans modification, la commande est annulée. Pour une tables non-transactionnelle, la commande est annulée si cela survient dans une ligne unique ou dans la première ligne d'une insertion multiple.
TRADITIONAL le serveur se comporte comme un système SQL traditionnel
ALLOW_INVALID_DATES N'autorise pas la vérification totale des dates. Vérifie simplement que le mois est dans l'intervalle de 1 à 12, et que le jour est dans l'intervalle de 1 à 31. C'est très pratique pour les applications Web où la date est obtenue de 3 champs différents, et que vous voulez stocker exactement la date saisie sans validation. Ce mode s'applique aux colonnes de type DATE et DATETIME. Il ne s'applique pas aux colonnes TIMESTAMP, qui demandent toujours une date valide.
ANSI_QUOTES Traite ‘"’ comme un délimiteur d'identifiant (comme le caractère MySQL ‘`’) et non comme un délimiteur de chaînes. Vous pouvez toujours utiliser ‘`’ pour délimiter les identifiants en mode ANSI. Avec ANSI_QUOTES activée, vous ne pouvez pas utiliser les guillemets doubles pour délimiter une chaîne de caractères, car ce sera uniquement interprété comme un identifiant.
ERROR_FOR_DIVISION_BY_ZERO Produit une erreur en mode strict et sinon une alerte, lorsque MySQL doit tenter une division par 0 ou un MOD(X,0)) durant une commande INSERT/ UPDATE. Si ce mode n'est pas activé, MySQL retourne simplement NULL pour les divisions par zéro. Si utilisé avec l'attribut IGNORE, MySQL génère une alerte pour les divisions par zéro, mais le résultat de l'opération sera NULL
IGNORE_SPACE Permet les espaces entre le nom de la fonction et le caractère ‘(’. Cela force les noms de fonctions a être traités comme des mots réservés. En conséquence, si vous voulez accéder aux bases, tables et colonnes dont le nom est un mot réservé, vous devez le mettre entre délimiteurs.
NO_AUTO_VALUE_ON_ZERO affecte la gestion des colonnes de type AUTO_INCREMENT. Normalement, vous générez le prochain numéro de séquence dans la colonne en insérant soit NULL soit 0 dedans. NO_AUTO_VALUE_ON_ZERO supprime ce comportement pour 0 pour que seule la valeur NULL génère le prochain numéro de séquence. Ce mode est utile si vous avez stocké la valeur 0 dans la colonne AUTO_INCREMENT de la table. Ce n'est pas recommandé. Par exemple, si vous voulez exporter une table avec mysqldump et que vous la rechargez, normalement MySQL va générer de nouveaux identifiants pour les lignes avec la valeur 0, ce qui entraînera une différence avec la table originale. En activant NO_AUTO_VALUE_ON_ZERO avant de recharger le fichier exporter, vous évitez des problèmes. mysqldump va automatiquement inclure les commandes nécessaires dans l'export, pour activer NO_AUTO_VALUE_ON_ZERO.
NO_DIR_IN_CREATE Lors de la création d'une table, ignore les directives INDEX DIRECTORY et DATA DIRECTORY. Cette option est pratique sur un esclave de réplication.
NO_FIELD_OPTIONS N'affiche pas les options spécifiques à MySQL dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité
NO_KEY_OPTIONS N'affiche pas les options spécifiques à MySQL dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité.
NO_TABLE_OPTIONS N'affiche pas les options de tables spécifiques à MySQL (comme ENGINE) dans le résultat de SHOW CREATE TABLE. Ce mode est utilisé par mysqldump dans un souci de portabilité.
NO_ZERO_DATE Ne permet pas l'utilisation de '0000-00-00' comme date valide. Vous pouvez toujours insérer des dates nulles avec l'option IGNORE. NO_ZERO_IN_DATE N'accepte pas les dates où le mois ou le jour vaut 0. Si utilisé avec L'option IGNORE, la date '0000-00-00' sera insérée pour chaque date invalide.
NO_UNSIGNED_SUBTRACTION Dans les opérations de soustraction, ne marque pas le résultat UNSIGNED si un des opérandes est non signé. Notez que cela fait que UNSIGNED BIGINT n'est plus totalement utilisable dans tous les contextes.
ONLY_FULL_GROUP_BY N'autorise pas les requêtes dont la clause GROUP BY fait référence à une colonne qui n'est pas sélectionnée.
PIPES_AS_CONCAT Traite || comme un opérateur de concaténation (identique à CONCAT()) au lieu d'être un synonyme de OR.
REAL_AS_FLOAT Traite le type REAL comme un synonyme FLOAT plutôt que comme un synonyme de DOUBLE.
STRICT_ALL_TABLES Active le mode strict pour tous les moteurs de stockage. Les valeurs invalides sont rejetées. Plus de détails suivent.
STRICT_TRANS_TABLES Active le mode strict pour tous les moteurs de stockage transactionnels. Les valeurs invalides sont rejetées. Plus de détails suivent.

Variables système dynamique

modifier une variable au lancement du serveur
mysqld --key_buffer_size=16M
modifier une variable à chaud
mysql› SET sort_buffer_size = 10 * 1024 * 1024 ;
Spécifier explicitement s'il s'agit d'une variable global ou de session
mysql› SET GLOBAL sort_buffer_size = 10 * 1024 * 1024 ;
mysql› SET SESSION sort_buffer_size = 10 * 1024 * 1024 ;
Voir les variables du serveur
SHOW variables
Affiche des informations sur le statut du serveur
SHOW STATUS
Remet à 0 de nombreuses variables de status
FLUSH STATUS
Arrêter le serveur: si un utilisateur a les droit SHUTDOWN il peut arrêter le serveur avec
mysqladmin shutdown

Sécurité général du serveur

   MySQL dispose d'un système de sécurité basé sur des liste de contrôle d'accès (ACL) pour toutes les connexions, requêtes et opérations que l'utilisateur peut faire. Il y'a aussi le support des connexions SSL entre le client et le serveur MySQL.

  Suivre les règles suivante:

- Ne donnez jamais à personne (sauf au compte MySQL root ) accès à la table user de la base mysql !. Le mot de passe chiffré est le vrai mot de passe de MySQL.
- Apprenez le système de droits MySQL. Les commandes GRANT et REVOKE sont utilisés pour contrôler les accès à MySQL. Ne donnez pas plus de droits nécessaire. Ne donnez jamais de droits à tous les serveurs hôtes.
- Ne stockez jamais de mot de passe en clair dans votre base. À la place, utilisez MD5(), SHA1() ou une autre fonction de signature injective
- utilisez des mots de passe fort.
- Placez votre serveur derrière un parefeu

Liste de vérification

- Essayez la commande mysql -u root sans mot de passe
- Utilisez la commande SHOW GRANTS et vérifiez qui a accès à quoi. Puis utilisez la commande REVOKE pour retirer les droits inutiles.

Protéger MySQL contre les attaques

   Toutes les informations autre que les mots de passes sont transférées en clair. Pour sécuriser le traffic, il est recommandé d'utiliser le protocole compressé et d'utiliser ssh pour établir des connexions chiffrées.

- N'exécutez jamais le démon MySQL avec l'utilisateur root. Pour démarrer mysqld sous un autre nom d'utilisateur Unix, ajoutez la ligne user qui spécifie le nom de l'utilisateur, dans le fichier d'options de [mysqld] de /etc/my.cnf.
- N'autorisez pas l'utilisation de liens symboliques pour les tables. Cette fonctionnalité peut être désactivée avec l'option --skip-symbolic-links. C'est particulièrement important si vous utilisez mysqld comme root, car tout utilisateur a alors le droit d'écrire des données sur le disque, n'importe où sur le système !!
- Vérifiez que l'utilisateur Unix qui exécute mysqld est le seul utilisateur avec les droits de lecture et écriture dans le dossier de base de données.
- Ne donnez pas le droit de PROCESS à tous les utilisateurs. Le droit SUPER peut être utilisé pour fermer des connexions clients, changer les variables systèmes et contrôler la réplication.
- Ne donnez pas le droit de FILE à tous les utilisateurs. Tout utilisateur qui possède ce droit peut écrire un fichier n'importe où sur le serveur, avec les droits hérités du démon mysqld.
- Si vous voulez restreindre le nombre de connexions d'un utilisateur, vous pouvez le faire en utilisant la variable max_user_connections de mysqld. La commande GRANT dispose aussi d'options de contrôle des ressources, pour limiter l'utilisation du serveur par un compte utilisateur.

Options de démarrage qui concerne la sécurité

--local-infile[=(0|1)] si vous utilisez --local-infile=0 alors vous ne pourrez pas utiliser LOAD DATA LOCAL INFILE
--safe-user=create activé, tout utilisateur ne peut pas créer d'autres utilisateurs avec les droits de GRANT, s'il ne dispose pas des droits d'insertion dans la table mysql.user Si vous voulez donner un accès à un utilisateur pour qu'il puisse créer des utilisateurs avec les droits dont il dispose, vous pouvez lui donner les droits suivant : GRANT INSERT(user) ON mysql.user TO 'user'@'hostname'; cela va assurer que l'utilisateur ne peut pas modifier une colonne directement, mais qu'il peut exécuter la commande GRANT sur d'autres utilisateurs.
--secure-auth interdit l'identification pour les comptes qui ont d'anciens mot de passe (ղ.1.1)
--skip-grant-tables force le serveur à ne pas utiliser les tables de droits. Donne tous les droits a tous les utilisateurs.
--skip-name-resolve les nom d'hôtes ne sont pas résolus. toutes les valeurs de la colonne host dans les tables de droits doivent être des adresses ip, ou bien localhost
--skip-networking Ne pas accepter les connexions TCP/IP venant du réseau, mais uniquement via socket Unix.

Problèmes de sécurité avec LOAD DATA LOCAL

   La commande LOAD DATA peut lire des données sur le serveur hôte ou charger un fichier sur le client avec LOCAL.

  Pour le client en ligne de commande mysql, LOAD DATA LOCAL peut être activé en spécifiant l'option --local-infile[=1], ou désactivé avec --local-infile=0.

  Vous pouvez désactiver toutes les commandes LOAD DATA LOCAL du serveur MySQL en démarrant mysqld avec --local-infile=0. Similairement, pour mysqlimport, les options --local et -L activent le chargement distant de fichiers. Dans ce cas, il faut que le serveur accepte aussi cette configuration pour que l'opération fonctionne.

Règles de sécurité et droits d'accès au serveur

Table des droits d-accès
   Lors de la seconde étape du contrôle d'accès (vérification de la requête), le serveur peut, suivant la requête, consulter aussi les tables tables_priv et columns_priv. Les champs de ces tables sont:

Autre tables des droits d-accès
   Chaque table de droit contient des champs d'identification et des champs de droits.

  - Les champs d'identification déterminent quels utilisateurs correspondent à cette ligne dans la table.

  - Les champs de droits indiquent si le droit est donné. Les champs d'identification sont des chaînes:

Champs d-identification
   Dans les tables user, db et host tous les champs de droits sont déclarés avec le type ENUM('N','Y')

  Dans les tables tables_priv et column_priv les champs de droits sont déclarés comme des champs de type SET.

Champs de droits
   Le serveur utilise les tables de droits comme ceci :

- La table user détermine si le serveur accepte ou rejette la connexion. Pour les connexions acceptées, tous les privilèges donnés dans la table user indiquent des privilèges globaux. Ces droits s'appliquent à toutes les bases du serveur.
- Les champs d'identification de la table db déterminent quels utilisateurs peuvent accéder à quelles bases, depuis quel hôte. Les champs de droits indiquent les opérations permises. Les droits s'appliquent alors à toutes les bases du serveur.
- La table host est utilisée comme extension de la table db lorsque vous voulez qu'une ligne de la table db s'applique à plusieurs hôtes dans votre réseau, laissez la colonne host vide dans la table db.
- Les tables tables_priv et columns_priv sont similaires à la table db, mais elles s'appliquent au niveau des tables et des colonnes, plutôt qu'au niveau des tables.

   Notez que les droits d'administration ne sont spécifiés que dans la table user, tout comme FILE.

  Pour voir les droit d'un utilisateur:

  SHOW GRANTS FOR 'bob'@'pc84.example.com';

  Un outil de diagnostique pratique est le script mysqlaccess.

Droits fournis par MySQL

Droit fournits par MySQL
   Les droits de SELECT, INSERT, UPDATE et DELETE vous permettent de faire des opérations sur les lignes qui existent, dans une table existante d'une base.

  La commande SELECT requiert le droit de SELECT uniquement si des lignes sont lues dans une table. Vous pouvez exécuter une commande SELECT même sans aucun droit d'accès à une base de données dans le serveur. Par exemple, vous pourriez utiliser le client mysql comme une simple calculatrice :

  mysql› SELECT 1+1;

  mysql› SELECT PI()*2;

  Le droit de INDEX vous donne le droit de créer et détruire des index de table.

  Le droit de ALTER vous donne le droit de modifier une table avec la commande ALTER TABLE.Les droits de CREATE et DROP vous permettent de créer de nouvelles tables et bases de données, et de les supprimer.

  Le droit de GRANT vous permet de donner les droits que vous possédez à d'autres utilisateurs.

   Le droit de FILE vous donne la possibilité de lire et écrire des fichiers sur le serveur avec les commandes LOAD DATA INFILE et SELECT ... INTO OUTFILE.

  Les autres droits sont utilisés pour les opérations administratives qui sont exécutées par l'utilitaire mysqladmin. La table ci-dessous montre quelle commande est associée à mysqladmin avec un de ces droits :

mysqladmin - commandes autorisées
   La commande reload indique au serveur de relire les tables de droits.

  La commande refresh vide les tables de la mémoire, écrit les données et ferme le fichier de log. flush-privileges est un synonyme de reload. Les autres commandes flush-* effectuent des fonctions similaires à la commande refresh mais sont plus limitées dans leur application, et sont préférables dans certains contextes.

  Par exemple, si vous souhaitez simplement vider les tampons dans le fichier de log, utilisez flush-logs, qui est un meilleur choix que refresh.

  La commande shutdown éteint le serveur.

   La commande processlist affiche les informations sur les threads qui s'exécutent sur le serveur. La commande kill termine un des threads du serveur. Vous pouvez toujours afficher et terminer vos propres threads, mais vous aurez besoin des droits de PROCESS pour afficher les threads, et le droit de SUPER pour terminer ceux qui ont été démarrés par d'autres utilisateurs.

  C'est une bonne idée en général, de ne donner les droits de Grant qu'aux utilisateurs qui en ont besoin, et vous devriez être particulièrement vigilant pour donner certains droits :

- Le droit de GRANT permet aux utilisateurs de donner leurs droits à d'autres utilisateurs. Deux utilisateurs avec des droits différents et celui de GRANT pourront combiner leurs droits respectifs pour gagner un autre niveau d'utilisation du serveur.
- Le droit de ALTER peut être utilisé pour tromper le système en renommant les tables.
- Le droit de FILE peut servir à lire des fichiers accessibles à tous sur le serveur, et les placer dans une base de données. Le contenu pourra alors être lu et manipulé avec SELECT. Cela inclus le contenu de toutes les bases actuellement hébergées sur le serveur !
- Le droit de SHUTDOWN peut conduire au dénis de service, en arrêtant le serveur.
- Le droit de PROCESS permet de voir en texte clair les commandes qui s'exécutent actuellement, et notamment les changements de mot de passe.
- Le droit de SUPER peut être utilisé pour terminer les connexions ou modifier le mode opératoire du serveur.
- Les droits sur la base de données mysql peuvent être utilisés pour changer des mots de passe ou des droits dans la table des droits (Les mots de passe sont stockés chiffrés, ce qui évite que les intrus ne les lisent). S'ils accèdent à un mot de passe dans la table mysql.user, ils pourront l'utiliser pour se connecter au serveur avec cet utilisateur (avec des droits suffisants, le même utilisateur pourra alors remplacer un mot de passe par un autre).

Connexion au serveur MySQL

shell› mysql [-h nom_d_hote] [-u nom_d_utilisateur] [-pvotre_mot_de_passe]
shell› mysql [--host=nom_d_hote] [--user=nom_d_utilisateur] [--password=votre_mot_de_passe]
On peut spécifier les paramètres de connexion dans la section [client] du fichier de configuration my.cnf :
[client]
host=nom_d_hote
user=nom_d'utilisateur
password=votre_mot_de_passe

   Contrôle d'accès, étape 1: Vérification de la connexion

  Votre identité est basée sur 3 informations:

- l'hôte depuis l'endroit où vous vous connectez
- Votre nom d'utilisateur MySQL
- Le mot de passe

   La vérification est réalisée avec les 3 colonnes de la table user [host, user et password]. host peut être un nom d'hôte ou une ip. Pour les ip on peut spécifier le masque:(spécifier une plage)

  GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';

  Caractères utilisable pour host: % n'importe quel hôte, ou encore x.y.%

  Pour connaître sous quel utilisateur on est connecté: SELECT CURRENT_USER();

   Contrôle d'accès, étape 2 : Vérification de la requête

  pour chaque requête, le serveur vérifie les droits. Ces droits peuvent provenir des tables user, db, tables_priv, column_priv. les droit sont vérifiés comme suit :

droits globaux
OR (droits de base AND droits d'hôte)
OR droits de table
OR droits de colonne

   On devrait toujours tester les requêtes dans la table de droits, en utilisant l'utilitaire mysqlaccess.

  Lors de la modification de privilèges, les droits GRANT, REVOKE et PASSWORD sont immédiatement pris en compte. Si on modifie les tables de droit manuellement avec INSERT UPDATE etc... on doit exécuter la commande FLUSH PRIVILEGES ou la commande mysqladmin flush-privileges, ou encore mysqladmin reload

  syntaxe pour modifier le mot de passe :

  SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');

Gestion des comptes utilisateur

   Les noms d'utilisateurs MySQL peuvent avoir jusqu'à 16 caractères. Il y'a 2 manières d'ajouter de nouveaux comptes:

- Utiliser la commande GRANT
- Manipuler la table des droits directement

exemples de syntaxe:
mysql› GRANT ALL PRIVILEGES ON generator.php TO 'monty'@'localhost'
-› IDENTIFIED BY 'un_mot_de_passe' WITH GRANT OPTION ;
mysql› GRANT ALL PRIVILEGES ON generator.php TO 'monty'@'%'
-› IDENTIFIED BY 'un_mot_de_passe' WITH GRANT OPTION ;
mysql› GRANT RELOAD,PROCESS ON generator.php TO 'admin'@'localhost' ;
mysql› GRANT USAGE ON generator.php TO 'dummy'@'localhost' ;
mysql› INSERT INTO user VALUES('localhost','monty',PASSWORD('un_mot_de_passe'),
-› 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y') ;
mysql› INSERT INTO user VALUES('%','monty',PASSWORD('un_mot_de_passe'),
-› 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y') ;
mysql› INSERT INTO user SET Host='localhost',User='admin',
-› Reload_priv='Y', Process_priv='Y' ;
mysql› INSERT INTO user (Host,User,Password)
-› VALUES('localhost','dummy','') ;
mysql› FLUSH PRIVILEGES ;
mysql› GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-› ON bankaccount.*
-› TO custom@localhost
-› IDENTIFIED BY 'stupid' ;
mysql› GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-› ON expenses.*
-› TO custom@whitehouse.gov
-› IDENTIFIED BY 'stupid' ;
mysql› GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-› ON customer.*
-› TO custom@'%'
-› IDENTIFIED BY 'stupid' ;
mysql› INSERT INTO user (Host,User,Password)
-› VALUES('localhost','custom',PASSWORD('stupid')) ;
mysql› INSERT INTO user (Host,User,Password)
-› VALUES('server.domain','custom',PASSWORD('stupid')) ;
mysql› INSERT INTO user (Host,User,Password)
-› VALUES('whitehouse.gov','custom',PASSWORD('stupid')) ;
mysql› INSERT INTO db
-› (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
-› Create_priv,Drop_priv)
-› VALUES
-› ('localhost','bankaccount','custom','Y','Y','Y','Y','Y','Y') ;
mysql› INSERT INTO db
-› (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
-› Create_priv,Drop_priv)
-› VALUES
-› ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y') ;
mysql› INSERT INTO db
-› (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
-› Create_priv,Drop_priv)
-› VALUES('%','customer','custom','Y','Y','Y','Y','Y','Y') ;
mysql› FLUSH PRIVILEGES ;

Si vous voulez donner un accès spécifique à un utilisateur à partir de n'importe quelle machine d'un domaine donné, vous pouvez utiliser la commande GRANT, en utilisant ‘%’ comme joker dans le nom de l'hôte
mysql› GRANT ...
-› ON generator.php
-› TO monutilisateur@"%.mondomaine.com"
-› IDENTIFIED BY 'monmotdepasse' ;
Pour faire la même chose en modifiant directement la table de droits, faites
mysql› INSERT INTO user VALUES ('%.mondomaine.com', 'monutilisateur',
-› PASSWORD('monmotdepasse'),...) ;
mysql› FLUSH PRIVILEGES ;
Supprimer un compte utilisateur, utiliser la commande
DROP USER

Limiter les ressources utilisateur

- nombre de requêtes par heure
- nombre de modifications par heure
- Nombre de connexions réalisées par heures

Pour configurer et changer les limites d'un compte existant, utiliser la commande GRANT USAGE au niveau global avec ON *.*.
mysql› GRANT USAGE ON generator.php TO 'francis'@'localhost'
-› WITH MAX_QUERIES_PER_HOUR 100 ; ; limite de requêtes à 100
mysql› GRANT USAGE ON generator.php TO 'francis'@'localhost'
-› WITH MAX_CONNECTIONS_PER_HOUR 0 ; ; limite supprimée
Pour remettre à 0 les compteurs pour tous les comptes, faites
FLUSH USER_RESOURCES
puis
FLUSH PRIVILEGES

Configurer les mots de passe

les mots de passe peuvent être assignés avec mysqladmin.
mysqladmin -u user_name -h host_name password "newpasswd"
On peut utiliser SET PASSWORD
SET PASSWORD FRO 'user_name'@'%' = PASSWORD('newpasswd') ;
modifier son propre mot de passe
SET PASSWORD = PASSWORD('newpasswd') ;
On peut utiliser GRANT USAGE au niveau global ON generator.php
GRANT USAGE ON generator.php TO 'user_name'@'%' IDENTIFIED BY 'newpasswd' ;
on peut utiliser la table user directement. Pour établir un mot de passe à la création d'un compte
INSERT INTO user (Host,User,Password) VALUES('%','new_user','newpasswd') ;
FLUSH PRIVILEGES ;
Pour changer le mot de passe d'un compte existant
UPDATE user SET Password = PASSWORD('newpasswd') WHERE Host = '%' AND User = 'user_name' ;
FLUSH PRIVILEGES ;
En utilisant mysqladmin password ou GRANT .....IDENTIFIED BY la fonction PASSWORD() n'est pas nécessaire.
Il est possible de lister les mots de passe dans le groupe [client] de my.cnf. faire un chmod 400 /etc/mysql/my.cnf

Connexions sécurisées

   MySQL n'utilise pas les connexions chiffrées par défaut, car cela ralentit considérablement le protocole de communication. Chiffrer les données est une tâche particulièrement coûteuse, qui peut ralentir considérablement les tâches principales de MySQL.

  Pour utiliser les connexions sécurisées utiliser le script configure avec les options --with-vio et --with-openssl

  Pour vérifier que le serveur supporte les connexions sécurisées utiliser la commande : SHOW VARIABLES LIKE 'have_openssl'

DIR=`pwd`/openssl
PRIV=$DIR/private
mkdir $DIR $PRIV $DIR/newcerts
cp /usr/share/ssl/openssl.cnf $DIR
replace ./demoCA $DIR -- $DIR/openssl.cnf
# Créez les dossiers nécessaires : $database, $serial et $new_certs_dir optionnel
touch $DIR/index.txt
echo "01" › $DIR/serial
# Génération du cerificat d'autorité (CA)
openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/cacert.pem -config $DIR/openssl.cnf
# Création des clé et requêtes serveur
openssl req -new -keyout $DIR/server-key.pem -out $DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf
# Supprimez la passe-phrase de la clé (optionnel)
openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem
# Signez le certificat serveur
openssl ca -policy policy_anything -out $DIR/server-cert.pem -config $DIR/openssl.cnf -infiles $DIR/server-req.pem
# Créez les clé et requêtes client
openssl req -new -keyout $DIR/client-key.pem -out $DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf
# Supprimez la passe-phrase de la clé (optionnel)
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem
# Signez le certificat client
openssl ca -policy policy_anything -out $DIR/client-cert.pem -config $DIR/openssl.cnf -infiles $DIR/client-req.pem
# Créez le fichier my.cnf que vous pourrez utiliser pour tester les différents certificats
cnf=""
cnf="$cnf [client]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/client-cert.pem"
cnf="$cnf ssl-key=$DIR/client-key.pem"
cnf="$cnf [mysqld]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/server-cert.pem"
cnf="$cnf ssl-key=$DIR/server-key.pem"
echo $cnf | replace " " '
' › $DIR/my.cnf
# To test MySQL
mysqld --defaults-file=$DIR/my.cnf &
mysql --defaults-file=$DIR/my.cnf
pour tester les connexions SSL, lancez le serveur comme ceci :
mysqld --default-file=/path/to/my.cnf &
puis lancer le programme client en utilisant le même fichier d'options :
mysql --defaults-file=/path/to/my.cnf

Options de GRANT avec SSL

MySQL peut vérifier les certificats X509 en plus de la combinaison habituelle de nom d'utilisateur et mot de passe.
Différentes possibilités pour limiter les connexions:

l'option REQUIRE SSL requière que les connexions soient chiffrées avec SSL
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret" REQUIRE SSL ;
REQUIRE X509 impose au client d'avoir un certificat valide, mais le certificat lui même importe peu, la seul restriction est qu'il doit être possible de vérifier la signature avec une autorité de certification.
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret" REQUIRE X509 ;
REQUIRE ISSUER “issuer” restreint les tentatives de connexions : le client doit se présenter avec un certificat X509 valide, émit par l'autorité de certification “issuer”. Utiliser un certificat x509 implique obligatoirement des chiffrements, donc l'option SSL est sous entendue.
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret"
-› REQUIRE ISSUER "C=FI, ST=Some-State, L=Helsinki,
"› O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com" ;
REQUIRE SUBJECT “subject” impose au client d'avoir un certificat X509 valide avec le sujet “subject”
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret"
-› REQUIRE SUBJECT "C=EE, ST=Some-State, L=Tallinn,
"› O=MySQL demo client certificate,
"› CN=Tonu Samuel/Email=tonu@mysql.com" ;
REQUIRE CIPHER “cipher” est utilisé pour s'assurer que les chiffrements sont suffisamment robuste, et que la bonne longueur de la clé est utilisée.
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret"
-› REQUIRE CIPHER "EDH-RSA-DES-CBC3-SHA" ;
Les options SUBJECT, ISSUER et CIPHER peuvent être combinées :
mysql› GRANT ALL PRIVILEGES ON test.* TO root@localhost
-› IDENTIFIED BY "goodsecret"
-› REQUIRE SUBJECT "C=EE, ST=Some-State, L=Tallinn,
"› O=MySQL demo client certificate,
"› CN=Tonu Samuel/Email=tonu@mysql.com"
-› AND ISSUER "C=FI, ST=Some-State, L=Helsinki,
"› O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com"
-› AND CIPHER "EDH-RSA-DES-CBC3-SHA" ;

Options SSL en ligne de commande

--ssl indique que le serveur autorise les connexions SSL, on doit spécifier également les options –ssl-ca ,–ssl-cert et –ssl-key
--ssl-ca=file_name chemin vers le fichier avec une liste des autorités de certifications SSL connus
--ssl-capath=directory_name le chemin où se trouve les certificats SSL au format PEM
--ssl-cipher=file_name nom du fichier de certificat SSL à utiliser pour établir une connexion sécurisée.
--ssl-cipher=cipher_list liste de chiffrements autorisées, à utiliser avec SSL a le même format que la commande openssl ciphers.
--ssl-key=file_name nom du fichier de la clé SSL à utiliser pour établir une connexion sécurisée.

Prévention des désastres et restauration

   Pour sauvegarder des bases de données:

  Faire un LOCK TABLES sur les tables concernées, suivi d'un FLUSH TABLES pour celles-ci. On a besoin que d'un verrou en lecture, cela permet aux autres threads de continuer à effectuer des requêtes sur les tables dont on fait la copie des fichiers. FLUSH TABLES est requis pour s'assurer que toutes les pages d'index actifs soient écrits sur le disque avant de commencer la sauvegarde.

  Pour faire une sauvegarde d'une table SQL, il suffit d'utiliser SELECT INTO OUTFILE ou BACKUP TABLE. On peut utiliser aussi mysqldump ou le script mysqlhotcopy.

Effectuer une sauvegarde complète de la base de données:
mysqldump –tab=/path/to/backup –opt –all
ou
mysqlhotcopy base /path/to/backup

   Arrêtez mysqld et le redémarrer avec l'option –log-update[=nom-fichier]. Les fichiers de log fournissent les informations dont vous avez besoin pour répliquer les modifications de la base de données qui sont subséquents au moment où vous avez utilisé mysqldump.

  Si votre serveur MySQL est un esclave, quelque soit la sauvegarde que vous utilisez, lorsque vous sauvez vos données sur votre esclave, vous devez aussi sauver les fichiers master.info et relay-log.info, qui sont nécessaires pour relancer la réplication après la restauration des données de l'esclave. Si votre esclave doit traiter des commandes LOAD DATA INFILE, vous devez aussi sauver les fichiers nommés SQL_LOAD-*, qui sont dans le dossier spécifié par --slave-load-tmpdir. Ce dossier vaut par défaut la valeur de la variable tmpdir, si elle n'est pas spécifiée. L'esclave aura besoin de ces fichiers pour relancer la réplication d'une opération LOAD DATA INFILE interrompue.

   Si vous avez besoin de restaurer quelque chose, essayez d'abord de restaurer vos tables avec REPAIR TABLE ou myisamchk -r en premier. Cela devrait fonctionner dans 99.9% des cas. Si myisamchk ne réussi pas, essayez la procédure suivante (cela ne fonctionnera que si vous avez démarré MySQL avec --log-update:

Restaurez la sauvegarde originale de mysqldump.
Exécutez la commande suivante pour remettre en marche les mises à jour dans le log binaire:
shell› mysqlbinlog hostname-bin.[0-9]* | mysql

Politique de sauvegarde

   Faire une sauvegarde de toutes les tables InnoDB dans toutes les bases:

  shell› mysqldump --single-transaction --all-databases › backup_sunday_1_PM.sql

  Le fichier .sql résultant, produit par mysqldump contient les commandes SQL INSERT qui peuvent être utilisées pour recharger les tables ultérieurement.

   Pour effectuer des sauvegarde incrémentales, le serveur doit être lancé avec l'option --log-bin pour qu'il puisse stocker ces modifications au fur et à mesure des modifications des données. Cette option active le log binaire, ce qui fait que chaque commande qui modifie les données est enregistré dans un fichier appelé log binaire. A chaque fois que le serveur redémarre, MySQL créer un nouveau fichier de log binaire, en utilisant le numéro de séquence suivant.

  Lorsque le serveur fonctionne on peut aussi lui dire de clore le fichier log et d'en ouvrir un nouveau avec la commande SQL FLUSH LOGS ou bien avec mysqladmin flush-logs. La commande mysqldump dispose aussi d'une option pour clore les fichiers de logs. Le fichier .index contient la liste de tous les fichiers de logs binaire du dossier de données. Ce fichier est utilisé durant les opérations de réplication.

utiliser mysqldump pour qu'il referme les logs binaires lors de la sauvegarde complète, et que le fichier de sauvegarde contienne les noms des nouveaux fichiers de logs
shell› mysqldump --single-transaction --flush-logs --master-data=2 --all-databases › blackup_sunday_1_PM.sql
pour supprimer les logs anciens, par exemple ceux qui sont antérieurs à la sauvegarde complète :
shell› mysqldump --single-transaction --flush-logs --master-data=2 --all-databases --delete-master-logs › backup_sunday_1_PM.sql

   Noter que la commande est dangereuse si le serveur est un maitre réplicateur car les esclaves pourraient ne pas avoir traité le contenu des logs binaires. La description de la commande PURGE MASTER LOGS explique ce qui doit être vérifié avant d'effacer un fichier de log binaire.

Utiliser les sauvegardes pour la restauration:
shell› mysql ‹ blachup_sunday_1_PM.sql
pour utiliser les sauvegardes incrémentales:
shell› mysqlbinlog mysqld-bin.000007 mysqld-bin.000008 | mysql
Il reste la dernière sauvegarde, qui est le dernier fichier de log binaire. de préférence spécifier un chemin vers un volume sécurisé pour l'option --log-bin.

Fichiers de log de MySQL

Le log d'erreurs Problèmes rencontrés lors du démarrage, de l'exécution ou de l'arrêt de mysqld.
Le log ISAM Garde une trace des changements liés au tables ISAM. Utilisé uniquement pour déboguer le code ISAM.
Le log de requêtes Connexions établies et requêtes exécutées.
Le log de mises à jour Désapprouvé : Enregistre toutes les commandes qui changent les données.
Le log binaire Enregistre toutes les commandes qui changent quelque chose. Utilisé pour la réplication.
Le log des requêtes lentes Enregistre toutes les requêtes qui ont pris plus de long_query_time à s'exécuter ou celles qui n'ont pas utilisé d'index.

   Par défaut, tous les fichiers de log peuvent être trouvés dans le dossier de données de mysqld.On peut forcer mysqld à rouvrir les fichiers de log ou à passer à un nouveau log en exécutant FLUSH LOGS.

  Le log d'erreurs: Contiennent les informations indiquant quand mysqld a été lancé ou arrêté, ainsi que les erreurs critiques. si mysqld s'arrête inopinément -› restarted mysqld. Si mysqld remarque une table à réparer/analyser, il l'écrit également.

  Pour spécifier l'emplacement du log d'erreur: --log-error[=file_name]. Sans cette option, écrit sur la sortie standard.

  Pour démarrer le log général de requêtes: --log[=fichier] (par défaut nommé 'hostname'.log)

  Pour démarrer le log des requêtes lentes: --log-slow-queries[=file_name]. Toutes les requêtes plus longues que long_query_time secondes à s'exécuter. Le temps d'acquisition d'un verrou n'est par compté. Pour obtenir un sommaire des requêtes lentes, utiliser mysqldumpslow.

Entretient des fichier de log

   mysql-log-rotate permet de gérer les logs. attention au logs pour la réplication.Pour forcer Mysql à utiliser de nouveaux fichiers de log: mysqladmin flush-logs ou FLUSH-LOGS.

  flush-logs permet de fermer les logs puis les rouvre, donc il faut les déplacer avant.

Multiples serveurs sur une seule machine

au minimum, les options suivantes doivent être différentes sur chaque serveur:
--port=port_num port d'écoute TCP
--socket=path chemin du socket
--pid-file=path chemin du fichier PID
Les options suivantes, si utilisées, doivent être différentes pour chaque serveur:
--log=path
--log-bin=path
--log-update=path
--log-error=path
--log-isam=path
--bdb-logdir=path
Pour de meilleurs performances, on pour également spécifier les options suivantes, pour répartir la charge entre plusieurs disques physiques

--tmpdir=path
--bdb-tmpdir=path
Également, le dossier de données:

--datadir=path
En cas de plusieurs installations de MySQL à différents endroits, utiliser:

--base-dir=path
Pour spécifier de fichier d'option à utiliser:

--defauts-file

Pour lancer un serveur avec son fichier d'option
shell› mysqld --defaults-file=C :\my-opts1.cnf
pour l'éteindre
shell› mysqladmin --port=3307 shutdown
On peut compiler mysql avec différents port et socket pour chacun avec
./configure --with-tcp-port=port_number --with-unix-socket-path=file_name --prefix=/usr/local/mysql-4.0.17
Connaître les caractéristiques d'un serveur
mysqladmin --host=host_name --port=port_number variables
Pour lancer un serveur sans l'avoir compilé avec des valeurs par défaut
/path/to/mysqld_safe --socket=file_name --port=port_number
Pour utiliser un dossier de données différent, utiliser l'option
--datadir=path à mysqld_safe
Idem, en utilisant les variables d'environnement pour spécifier le nom du socket et le port
shell› MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell› MYSQL_TCP_PORT=3307
shell› export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell› scripts/mysql_install_db
shell› bin/mysqld_safe &
^
04 mai 2010

htmlpdflatexmanmd




MySQL - gestion du cache

MySQL - gestion du cache

Gestion du cache MySQL

   C'est une méthode rapide pour lancer un second serveur pour le tester. Le plus agréable de cette méthode est que les variables d'environnement vont être adoptées par les logiciels clients que vous invoquerez avec le même Shell. Par conséquent, les connexions seront automatiquement dirigées vers le nouveau serveur. Pour les scripts de démarrage, la commande doit être :

  mysqld_safe --defaults-file=path-to-option-file

Cache de requêtes MySQL

   MySQL server bénéficie d'un cache de requêtes. En fait, le cache sauvegarde le texte d'une requête SELECT avec le résultat qui a été envoyé au client. Si une requête identique est appelée par la suite, le serveur retournera le résultat à partir du cache plutôt que d'analyser puis exécuter la requête à nouveau.

  Le cache de requêtes est extrêmement utile dans un environnement où les tables ne changent pas souvent, et que vous avez de nombreuses requêtes identiques. C'est la situation classique des serveurs Web, qui génèrent beaucoup de pages dynamiques à partir du même contenu.

  Note : Le cache de requêtes ne retourne pas de données périmées. À chaque fois que les données sont modifiées, les entrées correspondantes dans le cache sont effacées.

   Si vous ne voulez pas utiliser le cache de requêtes paramétrez query_cache_size à zéro. En désactivant le cache de requête, il n'y a aucune surcharge apparente. (le cache de requêtes peut être désactivé à l'aide de l'option de configuration --without-query-cache)

Fonctionnement du cache de requêtes

Les requêtes sont comparées avant analyse, donc ces 2 requêtes sont considérées comme différentes:
SELECT * FROM tbl_name
Select * from tbl_name

   Les requêtes qui utilisent différentes bases de données, différents protocoles ou différents jeux de caractères sont alors considérés comme différentes.

  Si un résultat de requête a été retourné depuis le cache de requête, la variable Com_select ne sera pas incrémenté, mais Qchache_hits le sera.

  Si une table change, toutes les requêtes mise en cache qui utilisaient cette table sont retirés.

  Une requête ne peut être mise en cache si elle contient l'une des fonctions suivantes:

fonctions non mises en cache
   Une requête ne sera pas mise en cache dans ces conditions:

- Elle contient des fonctions définies par l'utilisateur : UDF.
- Elle contient des variables utilisateur.
- Elle fait référence à des tables de la base mysql.
- Elle est de l'une des formes suivantes:
- SELECT ... IN SHARE MODE
- SELECT ... INTO OUTFILE ...
- SELECT ... INTO DUMPFILE ...
- SELECT * FROM ... WHERE autoincrement_col IS NULL
- La dernière forme n'est pas mise en cache, car elle est utilisée comme palliatif pour ODBC, afin d'obtenir la dernière valeur insérée.
- Elle utilise une table TEMPORARY.
- Elle n'utilise pas de tables.
- L'utilisateur a un droit de niveau colonne pour l'une des tables impliquée.
- Avant la lecture de la requête dans le cache de requête, MySQL vérifie que l'utilisateur a les droits SELECT pour toutes les bases de données impliquées. Si ce n'est pas le cas, le résultat n'est pas utilisé.

Options relatives au cache de requêtes utilisés dans une requête SELECT
SQL_CACHE Le résultat de la requête est en cache si la valeur de la variable query_cache est à ON ou DEMAND
SQL_NO_CACHE Le résultat de la requête n'est pas mis en cache

Exemples

SELECT SQL_CACHE id, name FROM customer ;
SELECT SQL_NO_CACHE id, name FROM customer ;

Configuration du cache de requêtes

   Pour configurer la taille du cache, modifier la variable query_cache_size. Une valeur de 0 désactive le cache.

  L'allocation de mémoire pour le cache se fait en bloc à mesure des besoin, c'est couteux en temps, pour définir une taille de bloc modifier query_cache_min_res_unit (défaut: 4ko). Le nombre de blocks libres et de requêtes supprimées pour libérer de la place sont stockées dans le variables Qcache_free_blocks et Qcache_lowmem_prunes

  Chaque requête a besoin au minimum de 2 blocs, un pour le texte de la requête et un autre, ou plus, pour le résultat. De même chaque table utilisée par une ou plusieurs requêtes a besoin d'un bloc.

        query_cache_type modifie son comportement:
        0, OFF Empêche la mise en cache ou la lecture de résultat en cache
        1, ON Permet le cache, sauf SELECT SQL_NO_CACHE
        2, DEMAND met tout en cache

Pour savoir si le cache est actif:
SHOW VARIABLES LIKE 'have_query_cache' ;
Pour désactiver le cache pour une session
SET SESSION query_cache_type=OFF
Pour défragmenter le cache de requêtes
FLUSH QUERY CACHE
et
FLUSH TABLE
Pour visualiser les performances du cache
SHOW STATUS LIKE 'Qcache%';
Le nombre total de commandes SELECT vaut
Com_select + Qcache_hits + requêtes avec une erreur
La valeur de Com_select est
qcache_inserts + qcache_not_cached + erreurs de droits d'accès ou de colonnes
^
04 mai 2010

htmlpdflatexmanmd




MySQL - Le langage

MySQL - Le langage

Description du langage MySQL

Chaînes

   Si le serveur est en mode ANSI_QUOTES, les chaînes ne peuvent être mises qu'entre guillemets simples

\0 un 0 ASCII(NUL)
\' guillemet simple
\" guillemet double
\b effacement
\n nouvelle ligne
\r retour chariot
\t tabulation
\z ASCII(26)(Control-Z) Peut être encodé pour éviter des problèmes avec windows, puisqu'il équivaut à une fin de fichier
\\ un anti-slash
\% un signe pourcentage littéral
\_ Un signe souligné littéral

   Si vous voulez insérer des données binaires dans un champ chaîne (comme un BLOB), les caractères suivants doivent être échappés:

NUL ASCII 0
\ ASCII 92
' ASCII 39
" ASCII 34

Les nombres

Valeurs hexadécimales:
mysql› SELECT x'4D7953514C';
-› 'MySQL'
mysql› SELECT 0xa+0;
-› 10
mysql› SELECT 0x5061756c;
-› 'Paul'
mysql› SELECT 0x41, CAST(0x41 AS UNSIGNED);
-› 'A', 65
mysql› SELECT HEX('cat');
-› '636174'
mysql› SELECT 0x636174;
-› 'cat'
Valeurs booléennes:
TRUE vaut 1 et FALSE vaut 0
champs de bits:
mysql› CREATE TABLE t (b BIT(8));
mysql› INSERT INTO t SET b = b'11111111';
mysql› INSERT INTO t SET b = b'1010';

   Valeurs NULL : signifie "pas de données" et est différent des valeurs comme 0 ou des chaînes vides

Noms de bases, tables, index, colonnes et alias

   limité a 64 octets(255 pour les alias). les identifiants sont stockés en utf8 et peuvent être entre guillemets

caractères de protection pour les identifiants contenant des caractères spéciaux ou sont un mot réservé :
`
mysql› SELECT * FROM `select` WHERE `select`.id › 100;
identifiants. Pour faire référence à une colonne:
col_name
tbl_name.col_name
db_name.tbl_name.col_name
commentaires:
# ceci est un commentaire
— ceci est un commentaire
/* ceci
est un
commentaire */

Mots clé réservés


ADD_________________ALL_______________ALTER
ANALYZE_____________AND_______________AS
ASC_________________ASENSITIVE________BEFORE
BETWEEN_____________BIGINT____________BINARY
BLOB________________BOTH______________BY
CALL________________CASCADE___________CASE
CHANGE______________CHAR______________CHARACTER
CHECK_______________COLLATE___________COLUMN
CONDITION___________CONSTRAINT________CONTINUE
CONVERT_____________CREATE____________CROSS
CURRENT_DATE________CURRENT_TIME______CURRENT_TIMESTAMP
CURRENT_USER________CURSOR____________DATABASE
DATABASES___________DAY_HOUR__________DAY_MICROSECOND
DAY_MINUTE__________DAY_SECOND________DEC
DECIMAL_____________DECLARE___________DEFAULT
DELAYED_____________DELETE____________DESC
DESCRIBE____________DETERMINISTIC_____DISTINCT
DISTINCTROW_________DIV_______________DOUBLE
DROP________________DUAL______________EACH
ELSE________________ELSEIF____________ENCLOSED
ESCAPED_____________EXISTS____________EXIT
EXPLAIN_____________FALSE_____________FETCH
FLOAT_______________FLOAT4____________FLOAT8
FOR_________________FORCE_____________FOREIGN
FROM________________FULLTEXT__________GRANT
GROUP_______________HAVING____________HIGH_PRIORITY
HOUR_MICROSECOND____HOUR_MINUTE_______HOUR_SECOND
IF__________________IGNORE____________IN
INDEX_______________INFILE____________INNER
INOUT_______________INSENSITIVE_______INSERT
INT_________________INT1______________INT2
INT3________________INT4______________INT8
INTEGER_____________INTERVAL__________INTO
IS__________________ITERATE___________JOIN
KEY_________________KEYS______________KILL
LEADING_____________LEAVE_____________LEFT
LIKE________________LIMIT_____________LINES
LOAD________________LOCALTIME_________LOCALTIMESTAMP
LOCK________________LONG______________LONGBLOB
LONGTEXT____________LOOP______________LOW_PRIORITY
MATCH_______________MEDIUMBLOB________MEDIUMINT
MEDIUMTEXT__________MIDDLEINT_________MINUTE_MICROSECOND
MINUTE_SECOND_______MOD_______________MODIFIES
NATURAL_____________NOT_______________NO_WRITE_TO_BINLOG
NULL________________NUMERIC___________ON
OPTIMIZE____________OPTION____________OPTIONALLY
OR__________________ORDER_____________OUT
OUTER_______________OUTFILE___________PRECISION
PRIMARY_____________PROCEDURE_________PURGE
READ________________READS_____________REAL
REFERENCES__________REGEXP____________RELEASE
RENAME______________REPEAT____________REPLACE
REQUIRE_____________RESTRICT__________RETURN
REVOKE______________RIGHT_____________RLIKE
SCHEMA______________SCHEMAS___________SECOND_MICROSECOND
SELECT______________SENSITIVE_________SEPARATOR
SET_________________SHOW______________SMALLINT
SONAME______________SPATIAL___________SPECIFIC
SQL_________________SQLEXCEPTION______SQLSTATE
SQLWARNING__________SQL_BIG_RESULT____SQL_CALC_FOUND_ROWS
SQL_SMALL_RESULT____SSL_______________STARTING
STRAIGHT_JOIN_______TABLE_____________TERMINATED
THEN________________TINYBLOB__________TINYINT
TINYTEXT____________TO________________TRAILING
TRIGGER_____________TRUE______________UNDO
UNION_______________UNIQUE____________UNLOCK
UNSIGNED____________UPDATE____________USAGE
USE_________________USING_____________UTC_DATE
UTC_TIME____________UTC_TIMESTAMP_____VALUES
VARBINARY___________VARCHAR___________VARCHARACTER
VARYING_____________WHEN______________WHERE
WHILE_______________WITH______________WRITE
XOR_________________YEAR_MONTH________ZEROFILL

   Voici de nouveaux mots réservés en MySQL 5.0:


ASENSITIVE__________CALL______________CONDITION
CONTINUE____________CURSOR____________DECLARE
DETERMINISTIC_______EACH______________ELSEIF
EXIT________________FETCH_____________INOUT
INSENSITIVE_________ITERATE___________LEAVE
LOOP________________MODIFIES__________OUT
READS_______________RELEASE___________REPEAT
RETURN______________SCHEMA____________SCHEMAS
SENSITIVE___________SPECIFIC__________SQL
SQLEXCEPTION________SQLSTATE__________SQLWARNING
TRIGGER_____________UNDO______________WHILE

Types de colonnes - numériques

- si vous spécifiez l'option ZEROFILL pour une valeur numérique, mysql ajoute automatiquement l'attribut UNSIGNED à la colonne.
TINYINT[(M)] [UNSIGNED] [ZEROFILL] Un très petit entier. L'intervalle de validité pour les entiers signés est de -128 à 127. L'intervalle de validité pour les entiers non-signés est 0 à 255.
BIT, BOOL, BOOLEAN Ce sont des synonymes de TINYINT(1). Un type booléen complet, qui sera introduit pour être en accord avec la norme SQL-99.
SMALLINT[(M)] [UNSIGNED] [ZEROFILL] Un petit entier. L'intervalle de validité pour les entiers signés est de -32768 à 32767. L'intervalle de validité pour les entiers non-signés est 0 à 65535.
MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] Un entier. L'intervalle de validité pour les entiers signés est de -8388608 à 8388607. L'intervalle de validité pour les entiers non-signés est 0 à 16777215.
INT[(M)] [UNSIGNED] [ZEROFILL] Un grand entier. L'intervalle de validité pour les entiers signés est de -2147483648 à 2147483647. L'intervalle de validité pour les entiers non-signés est 0 à 4294967295.
INTEGER[(M)] [UNSIGNED] [ZEROFILL] Synonyme INT.
BIGINT[(M)] [UNSIGNED] [ZEROFILL] Un très grand entier. L'intervalle de validité pour les entiers signés est de -9223372036854775808 à 9223372036854775807. L'intervalle de validité pour les entiers non-signés est 0 à 18446744073709551615.

   Quelques conseils à suivre avec les colonnes de type BIGINT:

- Tous les calculs arithmétiques sont fait en utilisant des BIGINT signés ou des valeurs DOUBLE. Il est donc recommandé de ne pas utiliser de grands entiers non-signés dont la taille dépasse 9223372036854775807 (63 bits), hormis avec les fonctions sur les bits! Si vous faîtes cela, les derniers chiffres du résultats risquent d'être faux, à cause des erreurs d'arrondis lors de la conversion de BIGINT en DOUBLE.
MySQL peut gérer des BIGINT dans les cas suivants:
- Utiliser des entiers pour stocker des grandes valeurs entières non signées, dans une colonne de type BIGINT.
- Avec MIN(big_int_column) et MAX(big_int_column).
- Avec les opérateurs (+, -, *, etc.) où tous les opérandes sont des entiers.
- Vous pouvez toujours stocker une valeur entière exacte BIGINT dans une colonne de type chaîne. Dans ce cas, MySQL fera des conversions chaîne / nombre, qui n'utilisera pas de représentation intermédiaire en nombre réels.

   ‘-’, ‘+’ et ‘*’ utiliseront l'arithmétique entière des BIGINT lorsque les deux arguments sont des entiers. Cela signifie que si vous multipliez deux entiers (ou des résultats de fonctions qui retournent des entiers), vous pourriez rencontrer des résultats inattendus lorsque le résultat est plus grand que 9223372036854775807.

FLOAT(precision) [UNSIGNED] [ZEROFILL] Un nombre à virgule flottante. précision peut valoir ‹=24 pour une précision simple, et entre 25 et 53 pour une précision double. Ces types sont identiques aux types FLOAT et DOUBLE, décrit ci-dessous. FLOAT(X) a le même intervalle de validité que FLOAT et DOUBLE, mais la taille d'affichage et le nombre de décimales est indéfini.

   En MySQL version 3.23, c'est un véritable nombre à virgule flottante. Dans les versions antérieures, FLOAT(precision) avait toujours 2 décimales. Notez qu'utiliser FLOAT peut vous donner des résultats inattendus, car tous les calculs de MySQL sont fait en double précision. Cette syntaxe est fournie pour assurer la compatibilité avec ODBC. Utiliser des FLOAT peut vous donner des résultats inattendus, car les calculs sont fait en précision double.

FLOAT[(M,D)] [UNSIGNED] [ZEROFILL] Un petit nombre à virgule flottante, en précision simple. Les valeurs possibles vont de -3.402823466E+38 à -1.175494351E-38, 0, et 1.175494351E-38 à 3.402823466E+38. Si UNSIGNED est spécifié, les valeurs négatives sont interdites. L'attribut M indique la taille de l'affichage, et D est le nombre de décimales. FLOAT sans argument et FLOAT(X) (où X est dans l'intervalle 0 à 24) représente les nombres à virgule flottante en précision simple.
DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL] Un nombre à virgule flottante, en précision double. Les valeurs possibles vont de -1.7976931348623157E+308 à -2.2250738585072014E-308, 0, et 2.2250738585072014E-308 à 1.7976931348623157E+308. Si UNSIGNED est spécifié, les valeurs négatives sont interdites. L'attribut M indique la taille de l'affichage, et D est le nombre de décimales. DOUBLE sans argument et FLOAT(X) (où X est dans l'intervale 25 to 53) représente les nombres à virgule flottante en précision double.
DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)] [UNSIGNED] [ZEROFILL] Ce sont des synonymes pour DOUBLE. Exception : si le serveur SQL utilise l'option REAL_AS_FLOAT, REAL est alors un synonyme de FLOAT plutôt que DOUBLE.
DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL] Un nombre à virgule flottante littéral. Il se comporte comme une colonne de type CHAR : "littéral" ("unpacked") signifie que le nombre est stocké sous forme de chaîne : chaque caractère représente un chiffre. La virgule décimale et le signe moins ‘-’ des nombres négatifs ne sont pas comptés dans M (mais de l'espace leur est réservé). Si D vaut 0, les valeurs n'auront pas de virgule décimale ou de partie décimale. L'intervale de validité du type DECIMAL est le même que DOUBLE, mais le vrai intervalle de validité de DECIMAL peut être restreint par le choix de la valeur de M et D. Si UNSIGNED est spécifié, les valeurs négatives sont interdites. Si D est omis, la valeur par défaut est 0. Si M est omis, la valeur par défaut est 10.
DEC[(M[,D])] [UNSIGNED] [ZEROFILL], NUMERIC[(M[,D])] [UNSIGNED] [ZEROFILL], FIXED[(M[,D])] [UNSIGNED] [ZEROFILL] Ce sont des synonymes pour DECIMAL

Types de colonnes - dates et heures

DATE Une date. L'intervalle supporté va de '1000-01-01' à '9999-12-31'. MySQL affiche les valeurs de type DATE au format 'YYYY-MM-DD', mais vous permet d'assigner des valeurs DATE en utilisant plusieurs formats de chaînes et nombres.
DATETIME Une combinaison de date et heure. L'intervalle de validité va de '1000-01-01 00:00:00' à '9999-12-31 23:59:59'. MySQL affiche les valeurs de type DATE au format 'YYYY-MM-DD HH:MM:SS', mais vous permet d'assigner des valeurs DATE en utilisant plusieurs formats de chaînes et nombres.
TIMESTAMP[(M)] Un timestamp. L'intervalle de validité va de '1970-01-01 00:00:00' à quelque part durant l'année 2037. les valeurs TIMESTAMP sont affichées au format YYYYMMDDHHMMSS, YYMMDDHHMMSS, YYYYMMDD ou YYMMDD, suivant que la valeur de M est 14 (ou absente), 12, 8 ou 6, respectivement, mais vous permet d'assigner des valeurs aux colonnes TIMESTAMP en utilisant des nombres ou des chaînes. TIMESTAMP est retournée comme une chaîne, au format 'YYYY-MM-DD HH:MM:SS'. Si vous voulez que MySQL vous retourne un nombre, ajoutez +0 à la colonne. Les différentes tailles de timestamp ne sont pas supportées.

   Une colonne TIMESTAMP est utile pour enregistrer les dates et heures des opérations INSERT et UPDATE, car elle prend automatiquement date actuellement si vous ne lui assignez pas de valeur par vous-même. Vous pouvez aussi lui donner la valeur courante en lui donnant la valeur NULL. L'argument M affecte l'affichage des colonnes de type TIMESTAMP. ses valeurs sont toujours stockées sur 4 octets. Notez que les colonnes TIMESTAMP(M) où M vaut 8 ou 14 sont indiquée comme étant des nombres, alors que les colonnes TIMESTAMP(M) sont indiquées comme étant des chaînes. Cela est fait pour s'assurer que l'ont peut enregistrer et lire correctement les tables ayant ce type.

TIME Une heure. L'intervalle va de '-838:59:59' à '838:59:59'. MySQL affiche les valeurs TIME au format 'HH:MM:SS', mais vous permet d'assigner des valeurs TIME en utilisant des nombres ou des chaînes.
YEAR[(2|4)] Une année, au format 2 ou 4 chiffres (par défaut, c'est 4 chiffres). Les valeurs possibles vont de 1901 à 2155 plus 0000 pour le format à 4 chiffres, et de 1970 à 2069 si vous utilisez le format à 2 chiffres. MySQL affiche les valeurs YEAR au format YYYY mais vous permet d'assigner des valeurs en utilisant des nombres ou des chaînes.

Types de colonnes - chaînes

CHAR et VARCHAR Les types CHAR et VARCHAR sont similaires, mais diffèrent dans la manière dont ils sont stockés et récupérés.

   La longueur d'une colonne CHAR est fixée à la longueur que vous avez défini lors de la création de la table. La longueur peut être n'importe quelle valeur entre 1 et 255. Quand une valeur CHAR est enregistrée, elle est complété à droite avec des espaces jusqu'à atteindre la valeur fixée. Quand une valeur de CHAR est lue, les espaces en trop sont retirés.

   Les valeurs contenues dans les colonnes de type VARCHAR sont de tailles variables. Vous pouvez déclarer une colonne VARCHAR pour que sa taille soit comprise entre 1 et 255, exactement comme pour les colonnes CHAR. Par contre, contrairement à CHAR, les valeurs de VARCHAR sont stockées en utilisant autant de caractères que nécessaire, plus un octet pour mémoriser la longueur. Les valeurs ne sont pas complétées. Au contraire, les espaces finaux sont supprimés avant stockage. Si vous assignez une chaîne de caractères qui dépasse la capacité de la colonne CHAR ou VARCHAR, celle ci est tronquée jusqu'à la taille maximale du champ.

   Les valeurs dans les colonnes CHAR et VARCHAR sont classées et comparées sans tenir compte de la casse, à moins que l'attribut BINARY n'ai été spécifié lors de la création de la table. L'attribut BINARY signifie que les valeurs sont classées et triées en tenant compte de la casse, suivant l'ordre des caractères ASCII de la machine ou est installé le serveur MySQL. BINARY n'affecte pas les méthodes de lecture et de stockage des valeurs. L'attribut BINARY se propage dans une expression : il suffit qu'une seule colonne, utilisée dans une expression, ait l'attribut BINARY pour que toute l'expression ne tienne plus compte de la casse.

BINARY et VARBINARY Les types BINARY et VARBINARY sont similaires à CHAR et VARCHAR, hormis le fait qu'ils contiennent des chaînes binaires, plutôt que des chaînes de texte. C'est à dire, qu'ils contiennent des chaînes d'octets, plutôt que des chaînes de caractères. Cela signifie qu'ils n'ont pas de jeu de caractères associé, et les tris et comparaisons sont basées sur la valeur numérique de l'octet. La taille maximale pour les types BINARY et VARBINARY, est la même que celles de CHAR et VARCHAR, hormis le fait que la taille de BINARY et VARBINARY est une taille en octets, et non pas en caractères.
BLOB et TEXT une valeur TEXT est une valeur BLOB insensible à la casse. Pour les index des colonnes BLOB et TEXT, vous devez spécifier une taille d'index. Pour les colonnes de type CHAR et VARCHAR, la taille du préfixe est optionnelle. Il n'y a pas de suppression des espaces finaux lors du stockage de valeur dans des colonnes de type BLOB et TEXT, ce qui est le cas dans pour les colonnes de type VARCHAR. Les colonnes BLOB et TEXT ne peuvent avoir de valeur par défaut. (DEFAULT). Les quatre types BLOB (TINYBLOB, BLOB, MEDIUMBLOB, et LONGBLOB). Les quatre types TEXT (TINYTEXT, TEXT, MEDIUMTEXT, et LONGTEXT)
ENUM Une énumération ENUM est une chaîne dont la valeur est choisie parmi une liste de valeurs autorisées lors de la création de la table. Cette chaîne peut aussi être la chaîne vide ("") ou NULL dans certaines circonstances. Si une colonne d'énumération est déclarée NULL, NULL devient aussi une valeur autorisée, et la valeur par défaut est alors NULL. Si une colonne d'énumération est déclarée NOT NULL, la valeur par défaut est le premier élément de la liste des valeurs autorisées.

        Chaque élément de l'énumération dispose d'un index.
        - Les valeurs de la liste des valeurs autorisées sont indexées à partir de 1.
        - L'index de la valeur NULL est NULL.
        - Une énumération peut avoir un maximum de 65535 éléments.
        - Il est déconseillé de stocker des valeurs numériques dans un ENUM car cela engendre des confusions

SET Un SET est une chaîne qui peut avoir zéro ou plusieurs valeurs, chacune doit être choisie dans une liste de valeurs définies lors de la création de la table. Les valeurs des colonnes SET composées de plusieurs membres sont définies en séparant celles-ci avec des virgules (‘,’). Ce qui fait que la valeur d'un membre de SET ne peut contenir lui même de virgule. Un SET peut avoir au plus 64 membres.

        Par exemple, une colonne définie en tant que SET("un", "deux") NOT NULL peut avoir l'une de ces valeurs:
        ""
        "un"
        "deux"
        "un,deux"

Capacité des colonnes numériques

Type de colonne/Espace requis
TINYINT 1 octet
SMALLINT 2 octets
MEDIUMINT 3 octets
INT, INTEGER 4 octets
BIGINT 8 octets
FLOAT(p) 4 if X ‹= 24 or 8 if 25 ‹= X ‹= 53
FLOAT 4 octets
DOUBLE PRECISION, REAL 8 octets
DECIMAL(M,D) M+2 octets si D › 0, M+1 octets si D=0 (D+2, si M‹D)

Capacité des colonnes temporelles

Type de colonne / Espace requis
DATE 3 octets
DATETIME 8 octets
TIMESTAMP 4 octets
TIME 3 octets
YEAR 1 octet

Capacité des colonnes texte

Type de colonne / Espace requis
CHAR(M) M octets, 1 ‹= M 255
VARCHAR(M) L+1 octets, avec L ‹= M et 1 ‹= M ‹= 255
TINYBLOB, TINYTEXT L+1 octets, avec L ‹ 2^8
BLOB, TEXT L+2 octets, avec L ‹ 2^16
MEDIUMBLOB, MEDIUMTEXT L+3 octets, avec L ‹ 2^24
LONGBLOB, LONGTEXT L+4 octets, avec L ‹ 2^32
ENUM('valeur1','valeur2',...) 1 ou 2 octets, suivant le nombre d'éléments de l'énumération (65535 au maximum)
SET('valeur1','valeur2',...) 1, 2, 3, 4 ou 8 octets, suivant le nombre de membres de l'ensemble (64 au maximum)

Fonctions dans SELECT et WHERE - Priorité des opérateurs

:=
||, OR, XOR
&&, AND
BETWEEN, CASE, WHEN, THEN, ELSE
=, ‹=›, ›=, ›, ‹=, ‹, ‹›, !=, IS, LIKE, REGEXP, IN
|
&
‹‹, ››
-, +
*, /, DIV, %, MOD
^
- (unary minus), (unary bit inversion)
NOT, !
BINARY, COLLATE

Fonctions dans SELECT et WHERE - Opérateurs de comparaison

= Egal

mysql› SELECT 1 = 0 ;
-› 0
mysql› SELECT '0' = 0 ;
-› 1
mysql› SELECT '0.0' = 0 ;
-› 1
mysql› SELECT '0.01' = 0 ;
-› 0
mysql› SELECT '.01' = 0.01 ;
-› 1

‹=› Comparaison compatible avec NULL. Cet opérateur fait une comparaison d'égalité comme l'opérateur =, mais retourne 1 plutôt que NULL si les deux opérandes sont NULL, et 0 plutôt que NULL si un opérande est NULL
‹›, != Différent

mysql› SELECT '.01' ‹› '0.01' ;
-› 1
mysql› SELECT .01 ‹› '0.01' ;
-› 0
mysql› SELECT 'zapp' ‹› 'zappp' ;
-› 1

‹= Inférieur ou égal

mysql› SELECT 0.1 ‹= 2;
-› 1

Strictement inférieur

mysql› SELECT 2 ‹ 2 ;
-› 0

›= Supérieur ou égal

mysql› SELECT 2 ›= 2 ;
-› 1

Strictement supérieur

mysql› SELECT 2 › 2 ;
-› 0

IS NULL, IS NOT NULL Tester si une valeur est ou n'est pas NULL

mysql› SELECT 1 IS NULL, 0 IS NULL, NULL IS NULL ;
-› 0 0 1
mysql› SELECT 1 IS NOT NULL, 0 IS NOT NULL, NULL IS NOT NULL ;
-› 1 1 0

expression BETWEEN min AND max Si expression est supérieure ou égale à min et expression est inférieure ou égale à max, BETWEEN retourne 1, sinon 0. Ceci est équivalent à l'expression (min ‹= expression AND expression ‹= max) si tous les arguments sont du même type. Dans tous les autres cas, la conversion de type prends place, selon les règles suivantes, mais appliquée aux trois arguments.

mysql› SELECT 1 BETWEEN 2 AND 3 ;
-› 0
mysql› SELECT 'b' BETWEEN 'a' AND 'c' ;
-› 1
mysql› SELECT 2 BETWEEN 2 AND '3' ;
-› 1
mysql› SELECT 2 BETWEEN 2 AND 'x-3' ;
-› 0

expr NOT BETWEEN min AND max Même chose que NOT (expr BETWEEN min AND max). COALESCE(list) Retourne le premier élément non-NULL de la liste

mysql› SELECT COALESCE(NULL,1) ;
-› 1
mysql› SELECT COALESCE(NULL,NULL,NULL) ;
-› NULL

GREATEST(value1,value2,...) Avec deux ou plusieurs arguments, retourne la valeur la plus grande. Les arguments sont comparés en utilisant les mêmes règles que pour LEAST()

mysql› SELECT GREATEST(2,0) ;
-› 2
mysql› SELECT GREATEST(34.0,3.0,5.0,767.0) ;
-› 767.0
mysql› SELECT GREATEST('B','A','C') ;
-› 'C'

expr IN (valeur,...) Retourne 1 si expr est l'une des valeurs dans la liste IN, sinon retourne 0. Si toutes les valeurs sont des constantes, toutes les valeurs sont évaluées avec le type de expr et triées. La recherche de l'élément est alors faite en utilisant la recherche binaire. Cela signifie que IN est très rapide si les valeurs contenues dans la liste IN sont toutes des constantes. Si expr est une chaîne sensible à la casse, la comparaison est faite dans un contexte sensible à la casse:

mysql› SELECT 2 IN (0,3,5,'wefwf') ;
-› 0
mysql› SELECT 'wefwf' IN (0,3,5,'wefwf') ;
-› 1

expr NOT IN (value,...) Même chose que NOT (expr IN (valeur,...)).
ISNULL(expr) Si expr est NULL, ISNULL() retourne 1, sinon il retourne 0

mysql› SELECT ISNULL(1+1) ;
-› 0
mysql› SELECT ISNULL(1/0) ;
-› 1

   Notez que la comparaison de deux valeurs NULL en utilisant = donnera toujours false !

INTERVAL(N,N1,N2,N3,...) Retourne 0 si N ‹ N1, 1 si N ‹ N2 etc... Tous les arguments sont traités en tant qu'entiers. Il est requis que N1 ‹ N2 ‹ N3 ‹ ... ‹ Nn pour que cette fonction fonctionne correctement. Cela est due à la recherche binaire utilisée (très rapide)

mysql› SELECT INTERVAL(23, 1, 15, 17, 30, 44, 200) ;
-› 3
mysql› SELECT INTERVAL(10, 1, 10, 100, 1000) ;
-› 2
mysql› SELECT INTERVAL(22, 23, 30, 44, 200) ;
-› 0

LEAST(value1,value2,...) Avec deux arguments ou plus, retourne la plus petite valeur.

mysql› SELECT LEAST(2,0) ;
-› 0
mysql› SELECT LEAST(34.0,3.0,5.0,767.0) ;
-› 3.0
mysql› SELECT LEAST('B','A','C') ;
-› 'A'

Fonctions dans SELECT et WHERE - Opérateurs logiques

NOT, ! (NON) logique. Évalue à 1 si l'opérande est 0, à 0 si l'opérande est non nulle, et NOT NULL retourne NULL. Le dernier exemple donne 1 car l'expression est évaluée comme (!1)+1

mysql› SELECT NOT 10 ;
-› 0
mysql› SELECT NOT 0 ;
-› 1
mysql› SELECT NOT NULL ;
-› NULL
mysql› SELECT ! (1+1) ;
-› 0
mysql› SELECT ! 1+1 ;
-› 1

AND, && (ET) logique. Évalue à 1 si toutes les opérandes sont différentes de zéro et de NULL, à 0 si l'une des opérandes est 0, dans les autres cas, NULL est retourné.

mysql› SELECT 1 && 1 ;
-› 1
mysql› SELECT 1 && 0 ;
-› 0
mysql› SELECT 1 && NULL ;
-› NULL
mysql› SELECT 0 && NULL ;
-› 0
mysql› SELECT NULL && 0 ;
-› 0

   Notez que pour les versions antérieures à la 4.0.5 l'évaluation est interrompue lorsque NULL est rencontré, au lieu de continuer à tester une éventuelle existence de 0. Cela signifie que dans ces versions, SELECT (NULL AND 0) retourne NULL au lieu de 0. En 4.0.5 le code a été revu pour que le résultat réponde toujours au normes ANSI tout en optimisant le plus possible.

OR, || (OU inclusif) logique. Évalue à 1 si aucune opérande n'est nulle, à NULL si l'une des opérandes est NULL, sinon 0 est retourné.

mysql› SELECT 1 || 1 ;
-› 1
mysql› SELECT 1 || 0 ;
-› 1
mysql› SELECT 0 || 0 ;
-› 0
mysql› SELECT 0 || NULL ;
-› NULL
mysql› SELECT 1 || NULL ;
-› 1

XOR (OU exclusif) logique. Retourne NULL si l'une des opérandes est NULL. Pour les opérandes non-NULL, évalue à 1 si un nombre pair d'opérandes est non-nul, sinon 0 est retourné. a XOR b est mathématiquement égal à (a AND (NOT b)) OR ((NOT a) and b).

mysql› SELECT 1 XOR 1 ;
-› 0
mysql› SELECT 1 XOR 0 ;
-› 1
mysql› SELECT 1 XOR NULL ;
-› NULL
mysql› SELECT 1 XOR 1 XOR 1 ;
-› 1

Fonctions dans SELECT et WHERE - Fonctions de contrôle

IFNULL(expr1,expr2) Si l'argument expr1 n'est pas NULL, la fonction IFNULL() retournera l'argument expr1, sinon elle retournera l'argument expr2. La fonction IFNULL() retourne une valeur numérique ou une chaîne de caractères, suivant le contexte d'utilisation

mysql› SELECT IFNULL(1,0) ;
-› 1
mysql› SELECT IFNULL(NULL,10) ;
-› 10
mysql› SELECT IFNULL(1/0,10) ;
-› 10
mysql› SELECT IFNULL(1/0,'oui') ;
-› 'oui'

NULLIF(expr1,expr2) Si l'expression expr1 = expr2 est vrai, la fonction retourne NULL sinon elle retourne expr1. Cela revient à faire CASE WHEN x = y THEN NULL ELSE x END

mysql› SELECT NULLIF(1,1) ;
-› NULL
mysql› SELECT NULLIF(1,2) ;
-› 1

IF(expr1,expr2,expr3) Si l'argument expr1 vaut TRUE (expr1 ‹› 0 et expr1 ‹› NULL) alors la fonction IF() retourne l'argument expr2, sinon, elle retourne l'argument expr3. La fonction IF() retourne une valeur numérique ou une chaîne de caractères, suivant le contexte d'utilisation

mysql› SELECT IF(1ؐ,2,3) ;
-› 3
mysql› SELECT IF(1հ,'oui','non') ;
-› 'oui'
mysql› SELECT IF(STRCMP('test','test1'),'non','oui') ;
-› 'non'

   Si l'argument expr2 ou expr3 est explicitement NULL alors le type du résultat de la fonction IF() est le type de la colonne non NULL. L'argument expr1 est évalué comme un entier, cela signifie que si vous testez un nombre à virgule flottante ou une chaîne de caractères, vous devez utiliser une opération de comparaison

mysql› SELECT IF(0.1,1,0) ;
-› 0
mysql› SELECT IF(0.1‹؎,1,0) ;
-› 1

CASE valeur WHEN [compare-value] THEN résultat [WHEN [compare-value] THEN résultat ...] [ELSE résultat] END,
CASE WHEN [condition] THEN résultat [WHEN [condition] THEN résultat ...] [ELSE résultat] END
La première version retourne résultat si valeur=compare-value. La seconde version retourne le résultat de la première condition qui se réalise. Si aucune des conditions n'est réalisé, alors le résultat de la clause ELSE est retourné. Si il n'y a pas de clause ELSE alors NULL est retourné. Le type de la valeur retournée (INTEGER, DOUBLE ou STRING) est de même type que la première valeur retournée (l'expression après le premier THEN).

mysql› SELECT CASE 1 WHEN 1 THEN "un"
WHEN 2 THEN "deux" ELSE "plus" END ;
-› "un"
mysql› SELECT CASE WHEN 1؎ THEN "vrai" ELSE "faux" END ;
-› "vrai"
mysql› SELECT CASE BINARY "B" WHEN "a" THEN 1 WHEN "b" THEN 2 END ;
-› NULL

Fonctions dans SELECT et WHERE - Fonctions de chaînes de caractères

   Les fonctions qui traitent les chaînes de caractères retournent NULL si la longueur du résultat finit par dépasser la taille maximale du paramètre max_allowed_packet, défini dans la configuration du serveur.

ASCII(str) Retourne le code ASCII du premier caractère de la chaîne de caractères str. Retourne 0 si la chaîne de caractère str est vide. Retourne NULL si la chaîne de caractères str est NULL. ASCII() fonctionne avec des valeurs numériques entre 0 et 255. Voir aussi la fonction ORD().

mysql› SELECT ASCII('2') ;
-› 50
mysql› SELECT ASCII(2) ;
-› 50
mysql› SELECT ASCII('dx') ;
-› 100

BIN(N) Retourne une chaîne de caractères représentant la valeur binaire de l'argument N, où l'argument N est un nombre de type BIGINT. Cette fonction est un équivalent de CONV(N,10,2). Retourne NULL si l'argument N est NULL.

mysql› SELECT BIN(12) ;
-› '1100'

BIT_LENGTH(str) Retourne le nombre de bits de la chaîne de caractères str.

mysql› SELECT BIT_LENGTH('text') ;
-› 32

CHAR(N,...) La fonction CHAR() interprète les arguments comme des entiers et retourne une chaîne de caractères, constituée des caractères, identifiés par leur code ASCII. Les valeurs NULL sont ignorées

mysql› SELECT CHAR(77,121,83,81,'76') ;
-› 'MySQL'
mysql› SELECT CHAR(77,77.3,'77.3') ;
-› 'MMM'

CHAR_LENGTH(str) Retourne le nombre de caractères de la chaîne str: Un caractère multi-octets compte comme un seul caractère. Cela signifie que pour une chaîne contenant 5 caractères de 2 octets, LENGTH() retournera 10, alors que CHAR_LENGTH() retournera 5.
CHARACTER_LENGTH(str) est un synonyme de CHAR_LENGTH()
COMPRESS(string_to_compress) Compresse une chaîne. Cette fonction requiert la présence de la bibliothèque zlib. Sinon, la valeur retournée sera toujours NULL.

mysql› SELECT LENGTH(COMPRESS(REPEAT('a',1000))) ;
-› 21
mysql› SELECT LENGTH(COMPRESS('')) ;
-› 0
mysql› SELECT LENGTH(COMPRESS('a')) ;
-› 13
mysql› SELECT LENGTH(COMPRESS(REPEAT('a',16))) ;
-› 15

   La chaîne compressée est stockée de cette manière: Les chaînes vides sont stockées comme des chaînes vides; Les chaînes non-vides sont stockées avec 4 octets de plus, indiquant la taille de la chaîne non compressée, suivie de la chaîne compressée. Si la chaîne se termine avec des espaces, un point supplémentaire "." est ajouté, pour éviter que les espaces terminaux soient supprimés de la chaîne. N'utilisez pas les types CHAR ou VARCHAR pour stocker des chaînes compressée. Il est mieux d'utiliser un type BLOB.

CONCAT_WS(separator, str1, str2,...) La fonction CONCAT_WS() signifie CONCAT With Separator, c'est-à-dire "concaténation avec séparateur". Le premier argument est le séparateur utilisé pour le reste des arguments. Le séparateur peut être une chaîne de caractères, tout comme le reste des arguments. Si le séparateur est NULL, le résultat sera NULL. Cette fonction ignorera tous les arguments de valeur NULL et vides, hormis le séparateur. Le séparateur sera ajouté entre tous les arguments à concaténer

mysql› SELECT CONCAT_WS(",","Premier nom","Deuxième nom","Dernier nom");
-› 'Premier nom,Deuxième nom,Dernier nom'
mysql› SELECT CONCAT_WS(",","Premier nom",NULL,"Dernier nom") ;
-› 'Premier nom,Dernier nom'

CONV(N,from_base,to_base) Convertit des nombres entre différentes bases. Retourne une chaîne de caractères représentant le nombre N, convertit de la base from_base vers la base to_base. La fonction retourne NULL si un des arguments est NULL. L'argument N est interprété comme un entier, mais peut être spécifié comme un entier ou une chaîne de caractères. Le minimum pour la base est 2 et son maximum est 36. Si to_base est un nombre négatif, N sera considéré comme un nombre signé. Dans le cas contraire, N sera traité comme un nombre non-signé. La fonction CONV travaille avec une précision de 64 bits

mysql› SELECT CONV("a",16,2) ;
-› '1010'
mysql› SELECT CONV("6E",18,8) ;
-› '172'
mysql› SELECT CONV(-17,10,-18) ;
-› '-H'
mysql› SELECT CONV(10+"10"+'10'+0xa,10,10) ;
-› '40'

ELT(N,str1,str2,str3,...) Retourne str1 si N = 1, str2 si N = 2, et ainsi de suite. Retourne NULL si N est plus petit que 1 ou plus grand que le nombre d'arguments. La fonction ELT() est un complément de la fonction FIELD()

mysql› SELECT ELT(1, 'ej', 'Heja', 'hej', 'foo') ;
-› 'ej'
mysql› SELECT ELT(4, 'ej', 'Heja', 'hej', 'foo') ;
-› 'foo'

EXPORT_SET(bits,on,off,[séparateur,[nombre_de_bits]]) Retourne une chaîne dont tous les bits à 1 dans "bit" sont représentés par la chaîne "on", et dont tous les bits à 0 sont représentés par la chaîne "off". Chaque chaîne est séparée par 'séparateur' (par défaut, une virgule ‘','’) et seul "nombre_de_bits" (par défaut, 64) "bits" est utilisé

mysql› SELECT EXPORT_SET(5,'Y','N',',',4)
-› Y,N,Y,N

FIELD(str,str1,str2,str3,...) Retourne l'index de la chaîne str dans la liste str1, str2, str3, .... Retourne 0 si str n'est pas trouvé. La fonction FIELD() est un complément de la fonction ELT()

mysql› SELECT FIELD('ej', 'Hej', 'ej', 'Heja', 'hej', 'foo') ;
-› 2
mysql› SELECT FIELD('fo', 'Hej', 'ej', 'Heja', 'hej', 'foo') ;
-› 0

FIND_IN_SET(str,strlist) Retourne une valeur de 1 à N si la chaîne str se trouve dans la liste strlist constituée de N chaînes. Une liste de chaîne est une chaîne composée de sous-chaînes séparées par une virgule ‘,’. Si le premier argument est une chaîne constante et le second, une colonne de type SET, la fonction FIND_IN_SET() est optimisée pour utiliser une recherche binaire très rapide. Retourne 0 si str n'est pas trouvé dans la liste strlist ou si la liste strlist est une chaîne vide. Retourne NULL si l'un des arguments est NULL. Cette fonction ne fonctionne pas correctement si le premier argument contient une virgule ','

mysql› SELECT FIND_IN_SET('b','a,b,c,d') ;
-› 2

HEX(N_or_S) Si l'argument N_OR_S est un nombre, cette fonction retournera une chaîne de caractère représentant la valeur hexadécimale de l'argument N, où l'argument N est de type BIGINT. Cette fonction est un équivalent de CONV(N,10,16). Si N_OR_S est une chaîne de caractères, cette fonction retournera une chaîne de caractères hexadécimale de N_OR_S où chaque caractère de N_OR_S est converti en 2 chiffres hexadécimaux. C'est l'inverse de la chaîne 0xff.

mysql› SELECT HEX(255) ;
-› 'FF'
mysql› SELECT HEX("abc") ;
-› 616263
mysql› SELECT 0x616263 ;
-› "abc"

INSERT(str,pos,len,newstr) Retourne une chaîne de caractères str, après avoir remplacé la portion de chaîne commençant à la position pos et de longueur len caractères, par la chaîne newstr. Cette fonction gère les caractères multi-octets.

mysql› SELECT INSERT('Quadratic', 3, 4, 'What') ;
-› 'QuWhattic'

INSTR(str,substr) Retourne la position de la première occurrence de la chaîne substr dans la chaîne de caractères str. Cette fonction est exactement la même que la fonction LOCATE(), à la différence que ces arguments sont inversés. Cette fonction gère les caractères multi-octets. cette fonction sera sensible à la casse si l'argument est une chaîne de caractères binaire.

mysql› SELECT INSTR('foobarbar', 'bar') ;
-› 4
mysql› SELECT INSTR('xbar', 'foobar') ;
-› 0

LCASE(str) est un synonyme de LOWER().
LEFT(str,len) Retourne les len caractères les plus à gauche de la chaîne de caractères str. Cette fonction gère les caractères multi-octets.

mysql› SELECT LEFT('foobarbar', 5) ;
-› 'fooba'

LENGTH(str) Retourne la taille de la chaîne str, mesurée en octets. Un caractère multi-octets compte comme un seul caractère. Cela signifie que pour une chaîne contenant 5 caractères de 2 octets, LENGTH() retournera 10, alors que CHAR_LENGTH() retournera 5.

mysql› SELECT LENGTH('text') ;
-› 4

LOAD_FILE(file_name) Lit le fichier file_name et retourne son contenu sous la forme d'une chaîne de caractères. Le fichier doit se trouver sur le serveur qui exécute MySQL, vous devez spécifier le chemin absolu du fichier et vous devez avoir les droits en lecture sur celui-ci. Le fichier doit pouvoir être lisible par tous et doit être plus petit que max_allowed_packet. Si ce fichier n'existe pas ou ne peut pas être lu pour différentes raisons, la fonction retourne NULL

mysql› UPDATE tbl_name
SET blob_column=LOAD_FILE("/tmp/picture")
WHERE id=1

LOCATE(substr,str), LOCATE(substr,str,pos) Retourne la position de la première occurrence de la chaîne substr dans la chaîne de caractères str. Retourne 0 si substr ne se trouve pas dans la chaîne de caractères str. Cette fonction gère les caractères multi-octets.

mysql› SELECT LOCATE('bar', 'foobarbar') ;
-› 4
mysql› SELECT LOCATE('xbar', 'foobar') ;
-› 0
mysql› SELECT LOCATE('bar', 'foobarbar',5) ;
-› 7

LOWER(str) Retourne la chaîne str avec tous les caractères en minuscules, en fonction du jeu de caractères courant (par défaut, c'est le jeu ISO-8859-1 Latin1). Cette fonction gère les caractères multi-octets.

mysql› SELECT LOWER('QUADRATIQUE') ;
-› 'quadratique'

LPAD(str,len,padstr) Retourne la chaîne de caractères str, complétée à gauche par la chaîne de caractères padstr jusqu'à ce que la chaîne de caractères str atteigne len caractères de long. Si la chaîne de caractères str est plus longue que len' caractères, elle sera raccourcie de len caractères.

mysql› SELECT LPAD('hi',4,' ??') ;
-› ' ??hi'

LTRIM(str) Retourne la chaîne de caractères str sans les espaces initiaux

mysql› SELECT LTRIM(' barbar') ;
-› 'barbar'

MAKE_SET(bits,str1,str2,...) Retourne une liste (une chaîne contenant des sous-chaînes séparées par une virgule ‘,’) constituée de chaînes qui ont le bit correspondant dans la liste bits. str1 correspond au bit 0, str2 au bit 1, etc... Les chaînes NULL dans les listes str1, str2, ... sont ignorées

mysql› SELECT MAKE_SET(1,'a','b','c') ;
-› 'A'
mysql› SELECT MAKE_SET(1 | 4,'hello','nice','world') ;
-› 'hello,world'
mysql› SELECT MAKE_SET(0,'a','b','c') ;
-› ''

MID(str,pos,len) est un synonyme de SUBSTRING(str,pos,len).
OCT(N) Retourne une chaîne de caractères représentant la valeur octal de l'argument N, où l'argument N est un nombre de type BIGINT. Cette fonction est un équivalent de CONV(N,10,8). Retourne NULL si l'argument N est NULL

mysql› SELECT OCT(12) ;
-› '14'

OCTET_LENGTH(str) est un synonyme de LENGTH().
ORD(str) Si le premier caractère de la chaîne str est un caractère multi-octets, la fonction retourne le code de ce caractère, calculé à partir du code ASCII retourné par cette formule

(1st octet * 256)
+ (2nd octet * 256^2)
+ (3rd octet * 256^3) ...
Si le premier caractère n'est pas un caractère multi-octet, la fonction retournera la même valeur que la fonction ASCII()
mysql› SELECT ORD('2') ;
-› 50

POSITION(substr IN str) est un synonyme de LOCATE(substr,str).
QUOTE(str) Échappe les caractères d'une chaîne pour produire un résultat qui sera exploitable dans une requête SQL. Les caractères suivants seront précédés d'un anti-slash dans la chaîne retournée : le guillemet simple (‘'’), l'anti-slash (‘\’), ASCII NUL, et le Contrôle-Z. Si l'argument vaut NULL, la valeur retournée sera le mot ``NULL'' sans les guillemets simples.

mysql› SELECT QUOTE("Don't") ;
-› 'Don\'t !'
mysql› SELECT QUOTE(NULL) ;
-› NULL

REPEAT(str,count) Retourne une chaîne de caractères constituée de la répétition de count fois la chaîne str. Si count ‹= 0, retourne une chaîne vide. Retourne NULL si str ou count sont NULL

mysql› SELECT REPEAT('MySQL', 3) ;
-› 'MySQLMySQLMySQL'

REPLACE(str,from_str,to_str) Retourne une chaîne de caractères str dont toutes les occurrences de la chaîne from_str sont remplacées par la chaîne to_str. Cette fonction gère les caractères multi-octets.

mysql› SELECT REPLACE('www.mysql.com' ;, 'w', 'Ww') ;
-› 'WwWwWw.mysql.com' ;

REVERSE(str) Retourne une chaîne dont l'ordre des caractères est l'inverse de la chaîne str. Cette fonction gère les caractères multi-octets.

mysql› SELECT REVERSE('abc') ;
-› 'cba'

RIGHT(str,len) Retourne les len caractères les plus à droite de la chaîne de caractères str. Cette fonction gère les caractères multi-octets.

mysql› SELECT RIGHT('foobarbar', 4) ;
-› 'rbar'

RPAD(str,len,padstr) Retourne la chaîne de caractères str, complétée à droite par la chaîne de caractères padstr jusqu'à ce que la chaîne de caractères str atteigne len caractères de long. Si la chaîne de caractères str est plus longue que len' caractères, elle sera raccourcie de len caractères.

mysql› SELECT RPAD('hi',5,' ?') ;
-› 'hi ???'

RTRIM(str) Retourne la chaîne de caractères str sans les espaces finaux. Cette fonction gère les caractères multi-octets.

mysql› SELECT RTRIM('barbar ') ;
-› 'barbar'

SOUNDEX(str) Retourne la valeur Soundex de la chaîne de caractères str. Deux chaînes qui ont des sonorités proches auront des valeurs soundex proches. Une chaîne Soundex standard possède 4 caractères, mais la fonction SOUNDEX() retourne une chaîne de longueur arbitraire. Vous pouvez utiliser la fonction SUBSTRING() sur ce résultat pour obtenir une chaîne Soundex standard. Tout caractère non alpha-numérique sera ignoré. Tous les caractères internationaux qui ne font pas partie de l'alphabet de base (A-Z) seront considérés comme des voyelles

mysql› SELECT SOUNDEX('Hello') ;
-› 'H400'
mysql› SELECT SOUNDEX('Quadratically') ;
-› 'Q36324'
expr1 SOUNDS LIKE expr2
Identique à
SOUNDEX(expr1)=SOUNDEX(expr2)

SPACE(N) Retourne une chaîne constituée de N espaces

mysql› SELECT SPACE(6) ;
-› ' '

SUBSTRING(str,pos), SUBSTRING(str FROM pos), SUBSTRING(str,pos,len), SUBSTRING(str FROM pos FOR len) Retourne une chaîne de len caractères de long de la chaîne str, à partir de la position pos. La syntaxe ANSI SQL92 utilise une variante de la fonction FROM. Cette fonction gère les caractères multi-octets.

mysql› SELECT SUBSTRING('Quadratically',5) ;
-› 'ratically'
mysql› SELECT SUBSTRING('foobarbar' FROM 4) ;
-› 'barbar'
mysql› SELECT SUBSTRING('Quadratically',5,6) ;
-› 'ratica'

SUBSTRING_INDEX(str,delim,count) Retourne une portion de la chaîne de caractères str, située avant count occurrences du délimiteur delim. Si l'argument count est positif, tout ce qui précède le délimiteur final sera retourné. Si l'argument count est négatif, tout ce qui suit le délimiteur final sera retourné. Cette fonction gère les caractères multi-octets.

mysql› SELECT SUBSTRING_INDEX('www.mysql.com' ;, '.', 2) ;
-› 'www.mysql' ;
mysql› SELECT SUBSTRING_INDEX('www.mysql.com' ;, '.', -2) ;
-› 'mysql.com'

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str) Retourne la chaîne de caractères str dont tous les préfixes et/ou suffixes remstr ont été supprimés. Si aucun des spécificateurs BOTH, LEADING ou TRAILING sont fournis, BOTH est utilisé comme valeur par défaut. Si remstr n'est pas spécifié, les espaces sont supprimés. Cette fonction gère les caractères multi-octets.

mysql› SELECT TRIM(' bar ') ;
-› 'bar'
mysql› SELECT TRIM(LEADING 'x' FROM 'xxxbarxxx') ;
-› 'barxxx'
mysql› SELECT TRIM(BOTH 'x' FROM 'xxxbarxxx') ;
-› 'bar'
mysql› SELECT TRIM(TRAILING 'xyz' FROM 'barxxyz') ;
-› 'barx'

UCASE(str) UCASE() est un synonyme de UPPER()
UNCOMPRESS(string_to_uncompress) Décompresse une chaîne compressée avec COMPRESS(). Si l'argument n'est pas une valeur compressée, le résultat est NULL. Cette fonction requiert la bibliothèque zlib. Sinon, la valeur retournée est toujours NULL.

mysql› SELECT UNCOMPRESS(COMPRESS('any string')) ;
-› 'any string'
mysql› SELECT UNCOMPRESS('any string') ;
-› NULL

UNCOMPRESSED_LENGTH(compressed_string) Retourne la taille de la chaîne avant compression.

mysql› SELECT UNCOMPRESSED_LENGTH(COMPRESS(REPEAT('a',30)));
-› 30

UNHEX(str) Le contraire de HEX(string). C'est à dire, chaque paire de chiffres hexadécimaux sont interprétées comme des nombres, et sont convertis en un caractère représenté par le nombre. Le résultat est retournée sous forme de chaîne binaire.

mysql› SELECT UNHEX('4D7953514C') ;
-› 'MySQL'
mysql› SELECT 0x4D7953514C ;
-› 'MySQL'
mysql› SELECT UNHEX(HEX('string')) ;
-› 'string'
mysql› SELECT HEX(UNHEX('1267')) ;
-› '1267'

UPPER(str) Retourne la chaîne str en majuscules, en fonction du jeu de caractères courant. Par défaut, c'est le jeu ISO-8859-1 Latin1. Cette fonction gère les caractères multi-octets.

mysql› SELECT UPPER('Hey') ;
-› 'HEY'

Fonctions dans SELECT et WHERE - Opérateurs de comparaison de chaînes de caractères

   MySQL convertit automatiquement les nombres en chaînes et et vice-versa. Si vous devez convertir explicitement un nombre en chaîne, passez-le en argument de la fonction CONCAT() ou CAST()

  expr LIKE pat [ESCAPE 'escape-char']

  La réalisation d'expressions utilisant les expressions régulières simples de comparaison de SQL retourne 1 (TRUE) ou 0 (FALSE). Avec LIKE, vous pouvez utiliser les deux jokers suivants:

% Remplace n'importe quel nombre de caractères, y compris aucun
_ Remplace exactement un caractère

mysql› SELECT 'David !' LIKE 'David_' ;
-› 1
mysql› SELECT 'David !' LIKE '%D%v%' ;
-› 1

   Pour tester la présence littérale d'un joker, précédez-le d'un caractère d'échappement. Si vous ne spécifiez pas le caractère d'échappement ESCAPE, le caractère "\" sera utilisé:

\% Remplace le caractère littéral '%'
\_ Remplace le caractère littéral '_'

mysql› SELECT 'David !' LIKE 'David\_' ;
-› 0
mysql› SELECT 'David_' LIKE 'David\_' ;
-› 1
Pour spécifier un caractère d'échappement différent, utilisez la clause ESCAPE:
mysql› SELECT 'David_' LIKE 'David|_' ESCAPE '|' ;
-› 1

   Les deux exemples suivants illustrent le fait que les comparaisons de chaînes de caractères ne sont pas sensibles à la casse à moins qu'une des opérandes soit une chaîne binaire.

mysql› SELECT 'abc' LIKE 'ABC' ;
-› 1
mysql› SELECT 'abc' LIKE BINARY 'ABC' ;
-› 0

   LIKE est également autorisé pour les expressions numériques. (C'est une extension MySQL à la norme ANSI SQL LIKE.)

mysql› SELECT 10 LIKE '1%' ;
-› 1

expr NOT LIKE pat [ESCAPE 'escape-char'] Équivalent à NOT (expr LIKE pat [ESCAPE 'escape-char']).
expr NOT REGEXP pat, expr NOT RLIKE pat Équivalent à NOT (expr REGEXP pat).
expr REGEXP pat, expr RLIKE pat Effectue une recherche de chaîne avec l'expression régulière pat. Le masque peut être une expression régulière étendue. Retourne 1 si expr correspond au masque pat, sinon, retourne 0. RLIKE est un synonyme de REGEXP.

mysql› SELECT 'Monty !' REGEXP 'm%y%%' ;
-› 0
mysql› SELECT 'Monty !' REGEXP '.*' ;
-› 1
mysql› SELECT 'new*\n*line' REGEXP 'new\\*.\\*line' ;
-› 1
mysql› SELECT 'a' REGEXP 'A', 'a' REGEXP BINARY 'A' ;
-› 1 0
mysql› SELECT 'a' REGEXP '^[a-d]' ;
-› 1

STRCMP(expr1,expr2) STRCMP() retourne 0 si les chaînes sont identiques, -1 si la première chaîne est plus petite que la seconde et 1 dans les autres cas:

mysql› SELECT STRCMP('text', 'text2') ;
-› -1
mysql› SELECT STRCMP('text2', 'text') ;
-› 1
mysql› SELECT STRCMP('text', 'text') ;
-› 0

Fonctions dans SELECT et WHERE - Fonctions numériques

Opérations arithmétiques
+ Addition
- Soustraction
- Moins unaire.
Multiplication
/ Division
DIV Division entière

   Fonctions mathématiques

  Toutes les fonctions mathématiques retournent NULL en cas d'erreur.

ABS(X) Retourne la valeur absolue de X. Cette fonction est utilisable avec les valeurs issues des champs BIGINT.

mysql› SELECT ABS(2) ;
-› 2
mysql› SELECT ABS(-32) ;
-› 32

ACOS(X) Retourne l'arc cosinus de X, c'est à dire, la valeur de l'angle dont X est la cosinus. Retourne NULL si X n'est pas dans l'intervalle -1 - 1.

mysql› SELECT ACOS(1) ;
-› 0.000000
mysql› SELECT ACOS(1.0001) ;
-› NULL
mysql› SELECT ACOS(0) ;
-› 1.570796

ASIN(X) Retourne l'arc sinus de X, c'est à dire, la valeur de l'angle dont le sinus est X. Retourne NULL si X n'est pas dans l'intervalle -1 - 1

mysql› SELECT ASIN(0.2) ;
-› 0.201358
mysql› SELECT ASIN('foo') ;
-› 0.000000

ATAN(X) Retourne l'arc tangente de X, c'est à dire, la valeur de l'angle dont la tangente est X.

mysql› SELECT ATAN(2) ;
-› 1.107149
mysql› SELECT ATAN(-2) ;
-› -1.107149

ATAN(Y,X), ATAN2(Y,X) Retourne l'arctangente des variables X et Y. Cela revient à calculer l'arctangente de Y / X, excepté que les signes des deux arguments servent à déterminer le quadrant du résultat

mysql› SELECT ATAN(-2,2) ;
-› -0.785398
mysql› SELECT ATAN2(PI(),0) ;
-› 1.570796

CEILING(X), CEIL(X Retourne la valeur entière supérieure de X. Notez que la valeur retournée sera de type BIGINT

mysql› SELECT CEILING(1.23) ;
-› 2
mysql› SELECT CEILING(-1.23) ;
-› -1

COS(X) Retourne le cosinus de X, où X est donné en radians.

mysql› SELECT COS(PI()) ;
-› -1.000000

COT(X) Retourne la cotangente de X.

mysql› SELECT COT(12) ;
-› -1.57267341
mysql› SELECT COT(0) ;
-› NULL

CRC32(expr) Calcule la somme de contrôle et retourne un entier 32 bits non-signé. Le résultat est la valeur NULL si l'argument est NULL. L'argument attendu est une chaîne, et sera traité comme une chaîne s'il n'est pas du bon type.

mysql› SELECT CRC32('MySQL') ;
-› 3259397556

DEGREES(X) Retourne l'argument X, convertit de radians en degrés.

mysql› SELECT DEGREES(PI()) ;
-› 180.000000

EXP(X) Retourne la valeur de e (la base des logarithmes naturels) élevé à la puissance X.

mysql› SELECT EXP(2) ;
-› 7.389056
mysql› SELECT EXP(-2) ;
-› 0.135335

FLOOR(X) Retourne la valeur entière inférieure de X. Notez que la valeur retournée sera de type BIGINT

mysql› SELECT FLOOR(1.23) ;
-› 1
mysql› SELECT FLOOR(-1.23) ;
-› -2

LN(X) Retourne le logarithme naturel de X (népérien). C'est un synonyme de la fonction LOG(X).

mysql› SELECT LN(2) ;
-› 0.693147
mysql› SELECT LN(-2) ;
-› NULL

LOG(X), LOG(B,X) Appelée avec un seul paramètre, cette fonction retourne le logarithme naturel (népérien) de X. Appelée avec deux paramètres, cette fonction retourne le logarithme naturel de X pour une base B arbitraire

mysql› SELECT LOG(2) ;
-› 0.693147
mysql› SELECT LOG(-2) ;
-› NULL
mysql› SELECT LOG(2,65536) ;
-› 16.000000
mysql› SELECT LOG(1,100) ;
-› NULL

LOG(B,X) est l'équivalent de LOG(X)/LOG(B).
LOG2(X) Retourne le logarithme en base 2 de X. Utile pour trouver combien de bits sont nécessaires pour stocker un nombre

mysql› SELECT LOG2(65536) ;
-› 16.000000
mysql› SELECT LOG2(-100) ;
-› NULL

MOD(N,M), N % M, N MOD M Modulo (équivalent de l'opérateur % dans le langage C). Retourne le reste de la division de N par M. Cette fonction ne pose pas de problèmes avec les BIGINT

mysql› SELECT MOD(234, 10) ;
-› 4
mysql› SELECT 253 % 7 ;
-› 1
mysql› SELECT MOD(29,9) ;
-› 2

PI() Retourne la valeur de pi. Par défaut, 5 décimales sont retournées, mais MySQL utilise la double précision pour pi.

mysql› SELECT PI() ;
-› 3.141593
mysql› SELECT PI()+0.000000000000000000 ;
-› 3.141592653589793116

POW(X,Y), POWER(X,Y) Retourne la valeur de X élevée à la puissance Y

mysql› SELECT POW(2,2) ;
-› 4.000000
mysql› SELECT POW(2,-2) ;
-› 0.250000

RADIANS(X) Retourne l'argument X, converti de degrés en radians.

mysql› SELECT RADIANS(90) ;
-› 1.570796

RAND(), RAND(N) Retourne un nombre aléatoire à virgule flottante compris dans l'intervalle 0 - 1.0. Si l'argument entier N est spécifié, il est utilisé comme initialisation du générateur de nombres aléatoires. Vous ne pouvez pas utiliser une colonne de valeur RAND() dans une clause ORDER BY, parce que ORDER BY va évaluer la colonne plusieurs fois.

mysql› SELECT RAND() ;
-› 0.9233482386203
mysql› SELECT RAND(20) ;
-› 0.15888261251047
mysql› SELECT RAND(20) ;
-› 0.15888261251047
mysql› SELECT RAND() ;
-› 0.63553050033332
mysql› SELECT RAND() ;
-› 0.70100469486881

ROUND(X), ROUND(X,D) Retourne l'argument X, arrondi à un nombre à D décimales. Avec deux arguments, la valeur est arrondie avec D décimales. Si D vaut 0, le résultat n'aura ni de partie décimale, ni de séparateur de décimal. Notez que le comportement de l'opérateur ROUND(), lorsque l'argument est exactement entre deux entiers, dépend de la bibliothèque C active. Certaines arrondissent toujours à l'entier pair le plus proche, toujours vers le haut, toujours vers le bas, ou toujours vers zéro. Si vous avez besoin d'un certain type d'arrondissement, vous devez utiliser une fonction bien définie comme TRUNCATE() ou FLOOR().

mysql› SELECT ROUND(-1.23) ;
-› -1
mysql› SELECT ROUND(-1.58) ;
-› -2
mysql› SELECT ROUND(1.58) ;
-› 2
mysql› SELECT ROUND(1.298, 1) ;
-› 1.3
mysql› SELECT ROUND(1.298, 0) ;
-› 1
mysql› SELECT ROUND(23.298, -1) ;
-› 20

SIGN(X) Retourne le signe de l'argument sous la forme -1, 0, ou 1, selon que X est négatif, zéro, ou positif.

mysql› SELECT SIGN(-32) ;
-› -1
mysql› SELECT SIGN(0) ;
-› 0
mysql› SELECT SIGN(234) ;
-› 1

SIN(X) Retourne le sinus de X, où X est donné en radians.

mysql› SELECT SIN(PI()) ;
-› 0.000000
SQRT(X) Retourne la racine carrée de X.
mysql› SELECT SQRT(4) ;
-› 2.000000
mysql› SELECT SQRT(20) ;
-› 4.472136

TAN(X) Retourne la tangente de X, où X est donné en radians.

mysql› SELECT TAN(PI()+1) ;
-› 1.557408

TRUNCATE(X,D) Retourne l'argument X, tronqué à D décimales. Si D vaut 0, le résultat n'aura ni séparateur décimal, ni partie décimale. Notez que les nombres décimaux ne sont pas stockés exactement comme les nombres entiers , mais comme des valeurs doubles. Vous pouvez être dupés par le résultat suivant (Ce résultat est normal car 10.28 est actuellement stocké comme cela 10.2799999999999999):

mysql› SELECT TRUNCATE(10.28*100,0) ;
-› 1027

Fonctions dans SELECT et WHERE - Dates et heures

ADDDATE(date,INTERVAL expr type), ADDDATE(expr,days) Lorsque utilisé avec la forme INTERVAL, ADDDATE() est un synonyme de DATE_ADD(). La fonction complémentaire SUBDATE() est un synonyme DATE_SUB(). La seconde syntaxe est utilisée si expr est une expression de type DATE ou DATETIME, et que days est un nombre de jour à ajouter à expr.

mysql› SELECT DATE_ADD('1998-01-02', INTERVAL 31 DAY) ;
-› '1998-02-02'
mysql› SELECT ADDDATE('1998-01-02', INTERVAL 31 DAY) ;
-› '1998-02-02'
mysql› SELECT ADDDATE('1998-01-02', 31) ;
-› '1998-02-02'

ADDTIME(expr,expr2) ADDTIME() Ajoute expr2 à expr et retourne le résultat. expr est une expression de type DATE ou DATETIME, et expr2 est une expression de type TIME.

mysql› SELECT ADDTIME("1997-12-31 23:59:59.999999", "1 1:1:1.000002") ;
-› '1998-01-02 01:01:01.000001'
mysql› SELECT ADDTIME("01:00:00.999999", "02:00:00.999998") ;
-› '03:00:01.999997'

CURDATE(), CURRENT_DATE Retourne la date courante au format 'YYYY-MM-DD' ou YYYYMMDD, suivant le contexte numérique ou chaîne:

mysql› SELECT CURDATE() ;
-› '1997-12-15'
mysql› SELECT CURDATE() + 0 ;
-› 19971215

CURRENT_DATE, CURRENT_DATE() sont synonymes de CURDATE().
CURTIME() Retourne l'heure courante au format 'HH:MM:SS' or HHMMSS suivant le contexte numérique ou chaîne

mysql› SELECT CURTIME() ;
-› '23:50:26'
mysql› SELECT CURTIME() + 0 ;
-› 235026

CURRENT_TIME, CURRENT_TIME() sont synonymes de CURTIME()
CURRENT_TIMESTAMP, CURRENT_TIMESTAMP() sont synonymes de NOW().
DATE(expr) Extrait la partie date de l'expression expr de type DATE ou DATETIME

mysql› SELECT DATE('2003-12-31 01:02:03') ;
-› '2003-12-31'

DATEDIFF(expr,expr2) Retourne le nombre de jours entre la date de début expr et la date de fin expr2. expr et expr2 sont des expressions de type DATE ou DATETIME. Seule la partie DATE est utilisée dans le calcul

mysql› SELECT DATEDIFF('1997-12-31 23:59:59','1997-12-30') ;
-› 1
mysql› SELECT DATEDIFF('1997-11-31 23:59:59','1997-12-31') ;
-› -30

DATE_ADD(date,INTERVAL expr type), DATE_SUB(date,INTERVAL expr type) Ces fonctions effectuent des calculs arithmétiques sur les dates. La table suivante indique la signification des arguments type et expr:


type Valeur___________Attendue expr Format

MICROSECOND___________MICROSECONDS
SECOND________________SECONDS
MINUTE________________MINUTES
HOUR__________________HOURS
DAY___________________DAYS
WEEK__________________WEEKS
MONTH ________________MONTHS
QUARTER ______________QUARTERS
YEAR__________________YEARS
SECOND_MICROSECOND____'SECONDS.MICROSECONDS'
MINUTE_MICROSECOND____'MINUTES.MICROSECONDS'
MINUTE_SECOND_________'MINUTES:SECONDS'
HOUR_MICROSECOND______'HOURS.MICROSECONDS'
HOUR_SECOND___________'HOURS:MINUTES:SECONDS'
HOUR_MINUTE___________'HOURS:MINUTES'
DAY_MICROSECOND_______'DAYS.MICROSECONDS'
DAY_SECOND____________'DAYS HOURS:MINUTES:SECONDS'
DAY_MINUTE____________'DAYS HOURS:MINUTES'
DAY_HOUR______________'DAYS HOURS'
YEAR_MONTH ___________'YEARS-MONTHS'

   MySQL autorise tous les signes de ponctuation, comme délimiteur dans le format de expr. Ceux qui sont affichés dans la table sont des suggestions. Si l'argument date est une valeur DATE et que vos calculs impliquent des parties YEAR, MONTH et DAY (c'est à dire, sans partie horaire), le résultat sera de type DATE. Sinon, le résultat est de type DATETIME

mysql› SELECT '1997-12-31 23:59:59' + INTERVAL 1 SECOND ;
-› '1998-01-01 00:00:00'
mysql› SELECT INTERVAL 1 DAY + '1997-12-31' ;
-› '1998-01-01'
mysql› SELECT '1998-01-01' - INTERVAL 1 SECOND ;
-› '1997-12-31 23:59:59'
mysql› SELECT DATE_ADD('1997-12-31 23:59:59',
-› INTERVAL 1 SECOND) ;
-› '1998-01-01 00:00:00'
mysql› SELECT DATE_ADD('1997-12-31 23:59:59',
-› INTERVAL 1 DAY) ;
-› '1998-01-01 23:59:59'
mysql› SELECT DATE_ADD('1997-12-31 23:59:59',
-› INTERVAL '1:1' MINUTE_SECOND) ;
-› '1998-01-01 00:01:00'
mysql› SELECT DATE_SUB('1998-01-01 00:00:00',
-› INTERVAL '1 1:1:1' DAY_SECOND) ;
-› '1997-12-30 22:58:59'
mysql› SELECT DATE_ADD('1998-01-01 00:00:00',
-› INTERVAL '-1 10' DAY_HOUR) ;
-› '1997-12-30 14:00:00'
mysql› SELECT DATE_SUB('1998-01-02', INTERVAL 31 DAY) ;
-› '1997-12-02'
mysql› SELECT DATE_ADD('1992-12-31 23:59:59.000002',
-› INTERVAL '1.999999' SECOND_MICROSECOND) ;
-› '1993-01-01 00:00:01.000001'

   Si vous spécifiez un intervalle qui est trop court (il n'inclut pas toutes les parties d'intervalle attendues par type), MySQL suppose que vous avez omis les valeurs de gauche. Par exemple, si vous spécifiez un type type de DAY_SECOND, la valeur expr devrait contenir des jours, heures, minutes et secondes. Si vous fournissez une valeur de la forme '1:10', MySQL suppose que les jours et heures manquent, et que la valeur représente des minutes et secondes. En d'autres termes, '1:10' DAY_SECOND est interprété comme '1:10' MINUTE_SECOND. C'est similaire au comportement de MySQL avec les valeurs de type TIME, qui représente des durées plutôt que des horaires. Notez que si vous ajoutez ou soustrayez à une valeur de type DATE des horaires, le résultat sera automatiquement au format DATETIME

mysql› SELECT DATE_ADD('1999-01-01', INTERVAL 1 DAY) ;
-› '1999-01-02'
mysql› SELECT DATE_ADD('1999-01-01', INTERVAL 1 HOUR) ;
-› '1999-01-01 01:00:00'

   Si vous utilisez des dates malformées, le résultat sera NULL. Si vous ajoutez des MONTH, YEAR_MONTH ou YEAR, et que le résultat a un jour du mois qui est au-delà de ce qui est possible dans le mois, le jour sera adapté au plus grand jour possible du mois. Par exemple

mysql› SELECT DATE_ADD('1998-01-30', interval 1 month) ;
-› '1998-02-28'

   Notez que dans l'exemple précédent, le mot clé INTERVAL et le spécificateur type sont insensibles à la casse.

DATE_FORMAT(date,format)
Formate la date avec le format. Les spécificateurs suivants peuvent être utilisé dans la chaîne format

%% Un signe pourcentage littéral ‘%’.
%a Nom du jour de la semaine, en abrégé et en anglais (Sun..Sat)
%b Nom du mois, en abrégé et en anglais (Jan..Dec)
%c Mois, au format numérique (1..12)
%d Jour du mois, au format numérique (00..31)
%D Jour du mois, avec un suffixe anglais (1st, 2nd, 3rd, etc.)
%e Jour du mois, au format numérique (0..31)
%f Microsecondes (000000..999999)
%H Heure (00..23)
%h Heure (01..12)
%I Heure (01..12)
%i Minutes, au format numérique (00..59)
%j Jour de l'année (001..366)
%k Heure (0..23)
%l Heure (1..12)
%m Mois, au format numérique (01..12)
%M Nom du mois (January..December)
%p AM ou PM
%r Heures, au format 12 heures (hh:mm:ss [AP]M)
%s Secondes (00..59)
%s Secondes (00..59)
%T Heures, au format 24 heures (hh:mm:ss)
%U Numéro de la semaine (00..53), où Dimanche est le premier jour de la semaine
%u Numéro de la semaine (00..53), où Lundi est le premier jour de la semaine
%V Numéro de la semaine (01..53), où Dimanche est le premier jour de la semaine, utilisé avec '%X'
%v Numéro de la semaine (01..53), où Lundi est le premier jour de la semaine, utilisé avec '%x'
%W Nom du jour de la semaine (Sunday..Saturday)
%w Numéro du jour de la semaine (0=Sunday..6=Saturday)
%X Année, pour les semaines qui commencent le Dimanche, au format numérique, sur 4 chiffres, utilisé avec '%V'
%x Année, pour les semaines qui commencent le Lundi, au format numérique, sur 4 chiffres, utilisé avec '%v'
%y Année, au format numérique, sur 2 chiffres
%Y Année, au format numérique, sur 4 chiffres

Tous les autres caractères sont simplement copiés dans le résultat sans interprétation
mysql› SELECT DATE_FORMAT('1997-10-04 22:23:00', '%W %M %Y') ;
-› 'Saturday October 1997'
mysql› SELECT DATE_FORMAT('1997-10-04 22:23:00', '%H :%i :%s') ;
-› '22:23:00'
mysql› SELECT DATE_FORMAT('1997-10-04 22:23:00',
'%D %y %a %d %m %b %j') ;
-› '4th 97 Sat 04 10 Oct 277'
mysql› SELECT DATE_FORMAT('1997-10-04 22:23:00',
'%H %k %I %r %T %S %w') ;
-› '22 22 10 10:23:00 PM 22:23:00 00 6'
mysql› SELECT DATE_FORMAT('1999-01-01', '%X %V') ;
-› '1998 52'

DAY(date) DAY() est un synonyme de DAYOFMONTH().
DAYNAME(date) Retourne le nom du jour de la semaine de date

mysql› SELECT DAYNAME('1998-02-05') ;
-› 'Thursday'

DAYOFMONTH(date) Retourne le jour de la date date, dans un intervalle de 1 à 31

mysql› SELECT DAYOFMONTH('1998-02-03') ;
-› 3

DAYOFWEEK(date) Retourne l'index du jour de la semaine: pour date (1 = Dimanche, 2 = Lundi, ... 7 = Samedi). Ces index correspondent au standard ODBC

mysql› SELECT DAYOFWEEK('1998-02-03') ;
-› 3
DAYOFYEAR(date) Retourne le jour de la date date, dans un intervalle de 1 à 366 :
mysql› SELECT DAYOFYEAR('1998-02-03') ;
-› 34

EXTRACT(type FROM date) La fonction EXTRACT() utilise les mêmes types d'intervalles que la fonction DATE_ADD() ou la fonction DATE_SUB(), mais extrait des parties de date plutôt que des opérations de date.

mysql› SELECT EXTRACT(YEAR FROM "1999-07-02") ;
-› 1999
mysql› SELECT EXTRACT(YEAR_MONTH FROM "1999-07-02 01:02:03") ;
-› 199907
mysql› SELECT EXTRACT(DAY_MINUTE FROM "1999-07-02 01:02:03") ;
-› 20102
mysql› SELECT EXTRACT(MICROSECOND FROM "2003-01-02 10:30:00.00123") ;
-› 123

FROM_DAYS(N) Retourne la date correspondant au nombre de jours (N) depuis la date 0. FROM_DAYS() n'est pas fait pour travailler avec des dates qui précèdent l'avènement du calendrier Grégorien (1582), car elle ne prend pas en compte les jours perdus lors du changement de calendrier.

mysql› SELECT FROM_DAYS(729669) ;
-› '1997-10-07'

FROM_UNIXTIME(unix_timestamp) Retourne une représentation de l'argument unix_timestamp sous la forme 'YYYY-MM-DD HH:MM:SS' ou YYYYMMDDHHMMSS, suivant si la fonction est utilisé dans un contexte numérique ou de chaîne.

mysql› SELECT FROM_UNIXTIME(875996580) ;
-› '1997-10-04 22:23:00'
mysql› SELECT FROM_UNIXTIME(875996580) + 0 ;
-› 19971004222300

   Si format est donné, le résultat est formaté en fonction de la chaîne format. format peut contenir les mêmes options de format que celles utilisées par DATE_FORMAT()

mysql› SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
-› '%Y %D %M %h :%i :%s %x') ;
-› '2003 6th August 06:22:58 2003'

GET_FORMAT(DATE | TIME | TIMESTAMP, 'EUR' | 'USA' | 'JIS' | 'ISO' | 'INTERNAL') Retourne une chaîne de format. Cette fonction est pratique lorsqu'elle est utilisée avec les fonctions DATE_FORMAT() et STR_TO_DATE(). Les trois valeurs possibles pour le premier argument, et les cinq valeurs possible pour le second argument donnent 15 formats d'affichage (pour les options utilisées, voyez la table de la fonction DATE_FORMAT())

Appel fonction / Résultat
GET_FORMAT(DATE,'USA') '%m.%d.%Y'
GET_FORMAT(DATE,'JIS') '%Y-%m-%d'
GET_FORMAT(DATE,'ISO') '%Y-%m-%d'
GET_FORMAT(DATE,'EUR') '%d.%m.%Y'
GET_FORMAT(DATE,'INTERNAL') '%Y%m%d'
GET_FORMAT(TIMESTAMP,'USA') '%Y-%m-%d-%H.%i.%s'
GET_FORMAT(TIMESTAMP,'JIS') '%Y-%m-%d %H :%i :%s'
GET_FORMAT(TIMESTAMP,'ISO') '%Y-%m-%d %H :%i :%s'
GET_FORMAT(TIMESTAMP,'EUR') '%Y-%m-%d-%H.%i.%s'
GET_FORMAT(TIMESTAMP,'INTERNAL') '%Y%m%d%H%i%s'
GET_FORMAT(TIME,'USA') '%h :%i :%s %p'
GET_FORMAT(TIME,'JIS') '%H :%i :%s'
GET_FORMAT(TIME,'ISO') '%H :%i :%s'
GET_FORMAT(TIME,'EUR') '%H.%i.%S'
GET_FORMAT(TIME,'INTERNAL') '%H%i%s'

mysql› SELECT DATE_FORMAT('2003-10-03', GET_FORMAT(DATE, 'EUR')
-› '03.10.2003'
mysql› SELECT STR_TO_DATE('10.31.2003', GET_FORMAT(DATE, 'USA'))
-› 2003-10-31

HOUR(time) Retourne le nombre d'heures pour l'heure time, dans un intervalle de 0 à 23

mysql› SELECT HOUR('10:05:03') ;
-› 10

   Cependant, l'intervalle des valeurs TIME est bien plus grand, et donc, HOUR peut retourner des valeurs plus grandes que 23

mysql› SELECT HOUR('272:59:59') ;
-› 272

LAST_DAY(date) Prend une valeur de format DATE ou DATETIME, et retourne le dernier jour du mois correspondant. Retourne NULL si l'argument est invalide.

mysql› SELECT LAST_DAY('2003-02-05'), LAST_DAY('2004-02-05') ;
-› '2003-02-28', '2004-02-29'
mysql› SELECT LAST_DAY('2004-01-01 01:01:01') ;
-› '2004-01-31'
mysql› SELECT LAST_DAY('2003-03-32') ;
-› NULL

LOCALTIME, LOCALTIME() sont synonymes de NOW().
LOCALTIMESTAMP, LOCALTIMESTAMP() sont synonymes de NOW().
MAKEDATE(year,dayofyear) Retourne une valeur de format DATE, à partir d'une année et du numéro de jour. dayofyear doit être plus grand que 0 ou le résultat sera NULL.

mysql› SELECT MAKEDATE(2001,31), MAKEDATE(2001,32) ;
-› '2001-01-31', '2001-02-01'
mysql› SELECT MAKEDATE(2001,365), MAKEDATE(2004,365) ;
-› '2001-12-31', '2004-12-30'
mysql› SELECT MAKEDATE(2001,0) ;
-› NULL

MAKETIME(hour,minute,second) Retourne une valeur de format TIME, calculée à partir des arguments hour, minute et second.

mysql› SELECT MAKETIME(12,15,30) ;
-› '12:15:30'

MICROSECOND(expr) Retourne le nombre de microsecondes dans l'expression de type TIME ou DATETIME expr, sous la forme d'un nombre entre 0 et 999999.

mysql› SELECT MICROSECOND('12:00:00.123456') ;
-› 123456
mysql› SELECT MICROSECOND('1997-12-31 23:59:59.000010') ;
-› 10

MINUTE(time) Retourne le nombre de minutes pour l'heure time, dans un intervalle de 0 à 59

mysql› SELECT MINUTE('98-02-03 10:05:03') ;
-› 5

MONTH(date) Retourne le numéro du mois de la date date, dans un intervalle de 1 à 12

mysql› SELECT MONTH('1998-02-03') ;
-› 2

MONTHNAME(date) Retourne le nom du mois de la date

mysql› SELECT MONTHNAME("1998-02-05") ;
-› 'February'

NOW() Retourne la date courante au format 'YYYY-MM-DD HH:MM:SS' ou YYYYMMDDHHMMSS, suivant le contexte numérique ou chaîne

mysql› SELECT NOW() ;
-› '1997-12-15 23:50:26'
mysql› SELECT NOW() + 0 ;
-› 19971215235026

PERIOD_ADD(P,N) Ajoute N mois à la période P (au format YYMM ou YYYYMM). Retourne une valeur dans le format YYYYMM. Notez que l'argument P n'est pas de type date

mysql› SELECT PERIOD_ADD(9801,2) ;
-› 199803

PERIOD_DIFF(P1,P2) Retourne le nombre de mois entre les périodes P1 et P2. P1 et P2 doivent être au format YYMM ou YYYYMM. Notez que les arguments P1 et P2 ne sont pas de type date

mysql› SELECT PERIOD_DIFF(9802,199703) ;
-› 11

QUARTER(date) Retourne le numéro du trimestre de la date date, dans un intervalle de 1 à 4

mysql› SELECT QUARTER('98-04-01') ;
-› 2

SECOND(time) Retourne le nombre de secondes pour l'heure time, dans un intervalle de 0 à 59

mysql› SELECT SECOND('10:05:03') ;
-› 3

SEC_TO_TIME(seconds) Retourne l'argument seconds, convertit en heures, minutes et secondes au format 'HH:MM:SS' ou HHMMSS, suivant le contexte numérique ou chaîne

mysql› SELECT SEC_TO_TIME(2378) ;
-› '00:39:38'
mysql› SELECT SEC_TO_TIME(2378) + 0 ;
-› 3938

STR_TO_DATE(str,format) Cette fonction est l'inverse de la fonction DATE_FORMAT(). Elle prend la chaîne str, et une chaîne de format format, puis retourne une valeur DATETIME. Les valeurs de type DATE, TIME ou DATETIME contenues dans la chaîne str doivent être au format spécifié. Pour les options qui sont utilisables dans la chaîne format, voyez la table dans la description de la fonction DATE_FORMAT(). Tous les autres caractères sont utilisés littéralement, et ne seront pas interprétés. Si str contient une valeur illégale, STR_TO_DATE() retourne NULL.

mysql› SELECT STR_TO_DATE('03.10.2003 09.20', '%d.%m.%Y %H.%i')
-› 2003-10-03 09:20:00
mysql› SELECT STR_TO_DATE('10rap', '%crap')
-› 0000-10-00 00:00:00
mysql› SELECT STR_TO_DATE('2003-15-10 00:00:00', '%Y-%m-%d %H :%i :%s')
-› NULL

SUBDATE(date,INTERVAL expr type), SUBDATE(expr,days) Lorsqu'elle est utilisée avec la forme INTERVAL du second argument, SUBDATE() est synonyme DATE_SUB()

mysql› SELECT DATE_SUB('1998-01-02', INTERVAL 31 DAY) ;
-› '1997-12-02'
mysql› SELECT SUBDATE('1998-01-02', INTERVAL 31 DAY) ;
-› '1997-12-02'
mysql› SELECT SUBDATE('1998-01-02 12:00:00', 31) ;
-› '1997-12-02 12:00:00'

SUBTIME(expr,expr2) SUBTIME() Soustrait expr2 de expr et retourne le résultat. expr est une expression de format DATE ou DATETIME et expr2 est une expression de type TIME.

mysql› SELECT SUBTIME("1997-12-31 23:59:59.999999", "1 1:1:1.000002") ;
-› '1997-12-30 22:58:58.999997'
mysql› SELECT SUBTIME("01:00:00.999999", "02:00:00.999998") ;
-› '-00:59:59.999999'

SYSDATE() est un synonyme de NOW().
TIME(expr) Extrait la partie horaire de l'expression expr, de type TIME ou DATETIME.

mysql› SELECT TIME('2003-12-31 01:02:03') ;
-› '01:02:03'
mysql› SELECT TIME('2003-12-31 01:02:03.000123') ;
-› '01:02:03.000123'

TIMEDIFF(expr,expr2) TIMEDIFF() retourne la durée entre l'heure de début expr et l'heure de fin expr2. expr et expr2 sont des expressions de type TIME ou DATETIME, et doivent être de même type.

mysql› SELECT TIMEDIFF('2000:01:01 00:00:00', '2000:01:01 00:00:00.000001') ;
-› '-00:00:00.000001'
mysql› SELECT TIMEDIFF('1997-12-31 23:59:59.000001','1997-12-30 01:01:01.000002') ;
-› '46:58:57.999999'

TIMESTAMP(expr), TIMESTAMP(expr,expr2) Avec un seul argument, retourne l'expression expr de type DATE ou DATETIME sous la forme d'une valeur DATETIME. Avec deux arguments, ajouter l'expression expr2 à l'expression expr et retourne le résultat au format DATETIME.

mysql› SELECT TIMESTAMP('2003-12-31') ;
-› '2003-12-31 00:00:00'
mysql› SELECT TIMESTAMP('2003-12-31 12:00:00','12:00:00') ;
-› '2004-01-01 00:00:00'

TIMESTAMPADD(interval,int_expr,datetime_expr) Ajoute l'expression entière int_expr à l'expression datetime_expr au format DATE ou DATETIME. L'unité de int_expr est donnée avec l'argument interval, qui peut être l'une des valeurs suivantes : FRAC_SECOND, SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER, ou YEAR. La valeur interval peut être spécifiée, en utilisant un des mots-clé cités, ou avec le préfixe SQL_TSI_. Par exemple, DAY et SQL_TSI_DAY sont tous les deux valides.

mysql› SELECT TIMESTAMPADD(MINUTE,1,'2003-01-02') ;
-› '2003-01-02 00:01:00'
mysql› SELECT TIMESTAMPADD(WEEK,1,'2003-01-02') ;
-› '2003-01-09'

TIMESTAMPDIFF(interval,datetime_expr1,datetime_expr2) Retourne la différence entière entre les expressions datetime_expr1 et datetime_expr2, de format DATE et DATETIME. L'unité du résultat est donné par l'argument interval. Les valeurs légales de interval sont les mêmes que pour la fonction TIMESTAMPADD().

mysql› SELECT TIMESTAMPDIFF(MONTH,'2003-02-01','2003-05-01') ;
-› 3
mysql› SELECT TIMESTAMPDIFF(YEAR,'2002-05-01','2001-01-01') ;
-› -1

TIME_FORMAT(time,format) Cette fonction est utilisée exactement comme la fonction DATE_FORMAT() ci-dessus, mais la chaîne format ne doit utiliser que des spécificateurs d'heures, qui gèrent les heures, minutes et secondes. Les autres spécificateurs génèreront la valeur NULL ou 0. Si la valeur time contient une valeur d'heure qui est plus grande que 23, les formats %H et %k produiront une valeur qui est hors de l'intervalle 0..23. L'autre format d'heure produira une heure modulo 12

mysql› SELECT TIME_FORMAT('100:00:00', '%H %k %h %I %l') ;
-› '100 100 04 04 4'

TIME_TO_SEC(time) Retourne l'argument time, convertit en secondes

mysql› SELECT TIME_TO_SEC('22:23:00') ;
-› 80580
mysql› SELECT TIME_TO_SEC('00:39:38') ;
-› 2378

TO_DAYS(date) Retourne le nombre de jours depuis la date 0 jusqu'à la date date. TO_DAYS() n'est pas fait pour travailler avec des dates qui précèdent l'avènement du calendrier Grégorien (1582), car elle ne prend pas en compte les jours perdus lors du changement de calendrier.

mysql› SELECT TO_DAYS(950501) ;
-› 728779
mysql› SELECT TO_DAYS('1997-10-07') ;
-› 729669

UNIX_TIMESTAMP(), UNIX_TIMESTAMP(date) Lorsqu'elle est appelé sans argument, cette fonction retourne un timestamp Unix (nombre de secondes depuis '1970-01-01 00:00:00' GMT). Si UNIX_TIMESTAMP() est appelé avec un argument date, elle retourne le timestamp correspondant à cette date. date peut être une chaîne de type DATE, DATETIME, TIMESTAMP, ou un nombre au format YYMMDD ou YYYYMMDD, en horaire local. Lorsque UNIX_TIMESTAMP est utilisé sur une colonne de type TIMESTAMP, la fonction reçoit directement la valeur, sans conversion explicite. Si vous donnez à UNIX_TIMESTAMP() une date hors de son intervalle de validité, elle retourne 0. Si vous voulez soustraire une colonne de type UNIX_TIMESTAMP(), vous devez sûrement vouloir un résultat de type entier signé.

mysql› SELECT UNIX_TIMESTAMP() ;
-› 882226357
mysql› SELECT UNIX_TIMESTAMP('1997-10-04 22:23:00') ;
-› 875996580

UTC_DATE, UTC_DATE() Retourne la date UTC courante au format 'YYYY-MM-DD' ou YYYYMMDD suivant le contexte numérique ou chaîne

mysql› SELECT UTC_DATE(), UTC_DATE() + 0 ;
-› '2003-08-14', 20030814

UTC_TIME, UTC_TIME() Retourne l'heure UTC courante au format 'HH:MM:SS' or HHMMSS suivant le contexte numérique ou chaîne

mysql› SELECT UTC_TIME(), UTC_TIME() + 0 ;
-› '18:07:53', 180753

UTC_TIMESTAMP, UTC_TIMESTAMP() Retourne l'heure et la date UTC courante au format 'YYYY-MM-DD HH:MM:SS' or YYYYMMDDHHMMSS suivant le contexte numérique ou chaîne

mysql› SELECT UTC_TIMESTAMP(), UTC_TIMESTAMP() + 0 ;
-› '2003-08-14 18:08:04', 20030814180804

WEEK(date [,mode]) Avec un seul argument, retourne le numéro de la semaine dans l'année de la date spécifiée, dans un intervalle de 0 à 53 (oui, il peut y avoir un début de semaine numéro 53), en considérant que Dimanche est le premier jour de la semaine. Avec deux arguments, la fonction WEEK() vous permet de spécifier si les semaines commencent le Dimanche ou le Lundi et la valeur retournée sera dans l'intervalle 0-53 ou bien 1-52. Lorsque l'argument mode est omis, la valeur de la variable default_week_format est utilisé. Voici un tableau explicatif sur le fonctionnement du second argument

Valeur / Signification
0 La semaine commence le Sunday ;l'intervalle de valeur de retour va de 0 à !2 ; la semaine 1 est la première semaine de l'année
1 La semaine commence le Monday ;l'intervalle de valeur de retour va de 0 à !2 ; la semaine 1 est la première semaine de l'année qui a plus de trois jours
2 La semaine commence le Sunday ;l'intervalle de valeur de retour va de 1 à !2 ; la semaine 1 est la première semaine de l'année
3 La semaine commence le Monday ;l'intervalle de valeur de retour va de 1 à !2 ; la semaine 1 est la première semaine de l'année qui a plus de trois jours
4 La semaine commence le Sunday ;l'intervalle de valeur de retour va de 0 à !2 ; la semaine 1 est la première semaine de l'année qui a plus de trois jours
5 La semaine commence le Monday ;l'intervalle de valeur de retour va de 0 à !2 ; la semaine 1 est la première semaine de l'année
6 La semaine commence le Sunday ;l'intervalle de valeur de retour va de 1 à !2 ; la semaine 1 est la première semaine de l'année qui a plus de trois jours
7 La semaine commence le Monday ;l'intervalle de valeur de retour va de 1 à !2 ; la semaine 1 est la première semaine de l'anné

mysql› SELECT WEEK('1998-02-20') ;
-› 7
mysql› SELECT WEEK('1998-02-20',0) ;
-› 7
mysql› SELECT WEEK('1998-02-20',1) ;
-› 8
mysql› SELECT WEEK('1998-12-31',1) ;
-› 53

   Si vous préférez que le résultat soit calculé en fonction de l'année qui contient le premier jour de la semaine de la date utilisée en argument, vous devriez utiliser les valeurs 2, 3, 6, or 7 de l'argument mode.

mysql› SELECT YEAR('2000-01-01'), WEEK('2000-01-01',0) ;
-› 2000, 0
mysql› SELECT WEEK('2000-01-01',2) ;
-› 52
Alternativement, utilisez la fonction YEARWEEK()
mysql› SELECT YEARWEEK('2000-01-01') ;
-› 199952
mysql› SELECT MID(YEARWEEK('2000-01-01'),5,2) ;
-› '52'

WEEKDAY(date) Retourne l'index du jour de la semaine, avec la conversion suivante : date (0 = Lundi, 1 = Mardi, ... 6 = Dimanche).

mysql› SELECT WEEKDAY('1997-10-04 22:23:00') ;
-› 5
mysql› SELECT WEEKDAY('1997-11-05') ;
-› 2

WEEKOFYEAR(date) Retourne le numéro de semaine dans l'année, sous forme d'un nombre compris entre 1 et 53.

mysql› SELECT WEEKOFYEAR('1998-02-20') ;
-› 8

YEAR(date) Retourne l'année de la date date, dans un intervalle de 1000 à 9999

mysql› SELECT YEAR('98-02-03') ;
-› 1998
mysql› SELECT YEAR('98-02-03') ;
-› 1998

YEARWEEK(date), YEARWEEK(date,start) Retourne l'année et la semaine d'une date. L'argument start fonctionne exactement comme l'argument start de la fonction WEEK(). Notez que l'année dans le résultat peut être différente de l'année passée en argument, pour la première et la dernière semaine de l'année. Notez que le numéro de semaine est différent de celui que la fonction WEEK() retourne (0) pour les arguments optionnels 0 ou 1, comme WEEK() puis retourne la semaine dans le contexte de l'année.

mysql› SELECT YEARWEEK('1987-01-01') ;
-› 198653

Fonctions dans SELECT et WHERE - Fonctions sur les bits

MySQL utilise l'arithmétique des BIGINT (64-bits) pour les opérations sur les bits. Ces opérateurs travaillent donc sur 64 bits.
| OU bit-à-bit (OR). Le résultat est un entier de 64 bits non signé.

mysql› SELECT 29 | 15 ;
-› 31

& ET bit-à-bit (AND). Le résultat est un entier de 64 bits non signé.

mysql› SELECT 29 & 15 ;
-› 13

^ XOR bit-à-bit. Le résultat est un entier de 64 bits non signé.

mysql› SELECT 1 ^ 1 ;
-› 0
mysql› SELECT 1 ^ 0 ;
-› 1
mysql› SELECT 11 ^ 3 ;
-› 8

‹‹ Décale les bits de l'entier (BIGINT) sur la gauche. Le résultat est un entier de 64 bits non signé.

mysql› SELECT 1 ‹‹ 2 ;
-› 4

›› Décale les bits de l'entier (BIGINT) sur la droite. Le résultat est un entier de 64 bits non signé.

mysql› SELECT 4 ›› 2 ;
-› 1

Inverse tous les bits. Le résultat est un entier de 64 bits non signé.

mysql› SELECT 5 & 1 ;
-› 4

BIT_COUNT(N) Retourne le nombre de bits non nuls de l'argument N

mysql› SELECT BIT_COUNT(29) ;
-› 4

Fonctions dans SELECT et WHERE - Fonctions de chiffrement

AES_ENCRYPT(str,key_str), AES_DECRYPT(crypt_str,key_str) Ces fonctions permettent le chiffrement/déchiffrement de données utilisant l'algorithme AES. Une clé de 128 bits est utilisé pour le chiffrement. Les arguments peuvent être de n'importe quelle taille. Si l'un des arguments est NULL, le résultat de cette fonction sera NULL.

Vous pouvez utiliser les fonctions AES pour stocker des données sous une forme chiffrées en modifiant vos requêtes
INSERT INTO t VALUES (1,AES_ENCRYPT("text","password")) ;
Vous pouvez obtenir encore plus de sécurité en évitant de transférer la clé pour chaque requête, en la stockant dans une variable sur le serveur au moment de la connexion
SELECT @password :="my password" ;
INSERT INTO t VALUES (1,AES_ENCRYPT("text",@password)) ;

DECODE(crypt_str,pass_str) Déchiffre la chaîne chiffrée crypt_str en utilisant la clé pass_str. crypt_str doit être une chaîne qui a été renvoyée par la fonction ENCODE().
ENCODE(str,pass_str) Chiffre la chaîne str en utilisant la clé pass_str. Pour déchiffrer le résultat, utilisez la fonction DECODE(). Le résultat est une chaîne binaire de la même longueur que string. Si vous voulez sauvegarder le résultat dans une colonne, utilisez une colonne de type BLOB.
DES_DECRYPT(crypt_str[,key_str]) Déchiffre une chaîne chiffrée à l'aide de la fonction DES_ENCRYPT(). Notez que cette fonction fonctionne uniquement si vous avez configuré MySQL avec le support SSL. Si l'argument key_string n'est pas donné, la fonction DES_DECRYPT() examine le premier bit de la chaîne chiffrée pour déterminer le numéro de clé DES utilisé pour chiffrer la chaîne originale, alors la clé est lu dans le fichier des-key-file pour déchiffrer le message. Pour pouvoir utiliser cela, l'utilisateur doit avoir le privilège SUPER. Si vous passé l'argument key_string à cette fonction, cette chaîne est utilisée comme clé pour déchiffrer le message. Si la chaîne string_to_decrypt ne semble pas être une chaîne chiffrée, MySQL retournera la chaîne string_to_decrypt. Si une erreur survient, cette fonction retourne NULL.
DES_ENCRYPT(str[,(key_num|key_str)]) Chiffre la chaîne avec la clé donnée en utilisant l'algorithme DES. Notez que cette fonction fonctionne uniquement si vous avez configuré MySQL avec le support SSL. La clé de hachage utilisée est choisie en suivant les recommandations suivantes

Un seul argument La première clé de des-key-file est utilisée.
Un numéro de clé Le numéro de la clé donnée (0-9) de des-key-file est utilisée.
Une chaîne La chaîne donnée key_string doit être utilisé pour chiffrer string_to_encrypt.

La chaîne retournée doit être une chaîne binaire où le premier caractère doit être CHAR(128 | key_number).
Le nombre 128 a été ajouté pour reconnaître facilement une clé de hachage. Si vous utilisez une chaîne comme clé, key_number doit être 127.
Si une erreur survient, la fonction retournera NULL.
La longueur de la chaîne de résultat doit être : new_length= org_length + (8-(org_length % 8))+1.
Chaque key_number doit être un nombre dans l'intervalle 0 à 9. Les lignes dans le fichier peuvent être dans n'importe quel ordre. des_key_string est la chaîne qui permettra le chiffrement du message. Entre le nombre et la clé, il doit y avoir au moins un espace. La première clé est la clé par défaut qui sera utilisé si vous ne spécifiez pas d'autres clés en arguments de la fonction DES_ENCRYPT().
Vous pouvez demander à MySQL de lire de nouvelles valeurs de clé dans le fichier de clés avec la commande FLUSH DES_KEY_FILE. Cela requière le privilège Reload_priv.
Un des bénéfices d'avoir une liste de clés par défaut est que cela donne aux applications la possibilité de regarder l'existence de la valeur chiffrée de la colonne, sans pour autant donner la possibilité à l'utilisateur final de déchiffrer ces valeurs.

mysql› SELECT customer_address FROM customer_table WHERE
crypted_credit_card = DES_ENCRYPT("credit_card_number") ;

ENCRYPT(str[,salt]) Chiffre la chaîne str en utilisant la fonction crypt(). L'argument salt doit être une chaîne de deux caractères.

mysql› SELECT ENCRYPT("hello") ;
-› 'VxuFAJXVARROc'

   Si la fonction crypt() n'est pas disponible sur votre système, la fonction ENCRYPT() retournera toujours NULL. La fonction ENCRYPT() conserve uniquement les 8 premiers caractères de la chaîne str, au moins, sur certains système. Le comportement exact est directement déterminé par la fonction système crypt() sous-jacente.

MD5(str) Calcul la somme de vérification MD5 de la chaîne string. La valeur retournée est un entier hexadécimal de 32 caractères qui peut être utilisé, par exemple, comme clé de hachage. C'est l'algorithme RSA ("RSA Data Security, Inc. MD5 Message-Digest Algorithm").

mysql› SELECT MD5("testing") ;
-› 'ae2b1fca515949e5d54fb22b8ed95575'

OLD_PASSWORD(str) retourne la valeur pre-4.1 de PASSWORD()
PASSWORD(str) Calcule un mot de passe chiffré à partir de la chaîne str. C'est cette fonction qui est utilisé pour chiffrer les mots de passes MySQL pour être stockés dans une colonne de type Password de la table user. Le chiffrage par PASSWORD() n'est pas réversible. PASSWORD() n'est pas un chiffrage comparable à la fonction de chiffrage Unix. Voir ENCRYPT(). La fonction PASSWORD() est utilisée durant l'identification au serveur MYSQL. Il est recommandé de ne pas l'utiliser pour vos applications. Utilisez plutôt MD5() ou SHA1().

mysql› SELECT PASSWORD('badpwd') ;
-› '7f84554057dd964b'

SHA1(str), SHA(str) Calcule la somme de vérification SHA1 160 bits de la chaîne string, comme décrit dans la RFC 3174 (Secure Hash Algorithm). La valeur retournée est un entier hexadécimal de 40 caractères, ou bien NULL dans le cas où l'argument vaut NULL. Une des possibilités d'utilisation de cette fonction est le hachage de clé. Vous pouvez aussi l'utiliser comme fonction de cryptographie sûre pour stocker les mots de passe. La fonction SHA1() a été ajoutée dans la version 4.0.2 de MySQL et peut être considérée comme une méthode de cryptographie plus sûre que la fonction MD5(). La fonction SHA() est un alias de la fonction SHA1()

Fonctions dans SELECT et WHERE - Fonctions d'information

BENCHMARK(count,expr) La fonction BENCHMARK() exécute l'expression expr de manière répétée count fois. Elle permet de tester la vélocité de MySQL lors du traitement d'une requête. Le résultat est toujours 0. L'objectif de cette fonction ne se voit que du côté client, qui permet à ce dernier d'afficher la durée d'exécution de la requête. Le temps affiché est le temps côté client, et non pas les ressources processeurs consommées. il est conseillé d'utiliser BENCHMARK() plusieurs fois de suite pour interpréter un résultat, en dehors de charges ponctuelles sur le serveur.

mysql› SELECT BENCHMARK(1000000,ENCODE("bonjour","au revoir")) ;

CHARSET(str) Retourne le jeu de caractères de la chaîne argument.

mysql› SELECT CHARSET('abc') ;
-› 'latin1'
mysql› SELECT CHARSET(CONVERT('abc' USING utf8)) ;
-› 'utf8'
mysql› SELECT CHARSET(USER()) ;
-› 'utf8'

Les valeurs retournées possibles sont (Les valeurs les plus faibles ont la plus haute priorité):
0 Collation explicite
1 Par de collation
2 Collation implicite
3 Coercible

COLLATION(str) Retourne la collation du jeu de caractères de la chaîne argument

mysql› SELECT COLLATION('abc') ;
-› 'latin1_swedish_ci'
mysql› SELECT COLLATION(_utf8'abc') ;
-› 'utf8_general_ci'

CONNECTION_ID() Retourne l'identifiant de connexion courant (thread_id). Chaque connexion a son propre identifiant unique

mysql› SELECT CONNECTION_ID() ;
-› 23786

CURRENT_USER() Retourne le nom d'utilisateur et le nom d'hôte de la session courante. Cette valeur correspond au compte qui a été utilisé durant l'identification auprès du serveur. Cela peut être différent des valeurs de USER().

mysql› SELECT USER() ;
-› 'davida@localhost'
mysql› SELECT * FROM mysql.user ;
ERROR 1044 : Access denied for user : '@localhost' to
database 'mysql'
mysql› SELECT CURRENT_USER() ;
-› '@localhost'

   Cet exemple montre que même si le client a indiqué le nom d'utilisateur davida (comme mentionné par la fonction USER()), le serveur a identifié le client comme un utilisateur anonyme (comme indiqué par la fonction CURRENT_USER()). Une situation qui arrive s'il n'y a aucun compte de listé dans les tables de droits pour davida.

DATABASE() Retourne le nom de la base de données courante. Si aucune base de données n'a été sélectionnée, DATABASE() retourne une chaîne vide. A partir de la version 4.1.1, elle retourne NULL.

mysql› SELECT DATABASE() ;
-› 'test'

FOUND_ROWS() Une commande SELECT peut inclure une clause LIMIT pour restreindre le nombre de lignes qui sera retourné par le client. Dans certains cas, il est mieux de savoir combien de lignes une commande aurait retourné, sans la clause LIMIT, mais sans lancer à nouveau le calcul. Pour cela, ajoutez l'option SQL_CALC_FOUND_ROWS dans la commande SELECT, puis appelez FOUND_ROWS() après.

mysql› SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
-› WHERE id › 100 LIMIT 10 ;
mysql› SELECT FOUND_ROWS() ;

   Le second SELECT retourne un nombre indiquant combien de lignes le premier SELECT aurait retourné s'il n'avait pas été écrit avec une clause LIMIT. Notez que si vous utilisez SELECT SQL_CALC_FOUND_ROWS ..., MySQL calcule toutes les lignes dans la liste des résultats. Ainsi, c'est plus rapide si vous n'utilisez pas de clause LIMIT et que la liste des résultats n'a pas besoin d'être envoyée au client. Si la commande SELECT précédente n'inclut pas l'option SQL_CALC_FOUND_ROWS, alors FOUND_ROWS() pourrait retourner une valeur différente suivant que LIMIT est utilisé ou pas.

   SQL_CALC_FOUND_ROWS et FOUND_ROWS() peuvent être pratiques dans des situations où vous devez limiter le nombre de lignes que la requête retourne, mais que vous devez tout de même connaître le nombre de lignes total, sans exécuter une seconde requête. Un exemple classique est un script web qui présente des résultats de recherche. En utilisant FOUND_ROWS(), vous connaîtrez facilement le nombre de lignes de résultat. L'utilisation de SQL_CALC_FOUND_ROWS et FOUND_ROWS() est plus complexe pour les requêtes UNION que pour les commandes SELECT simples, car LIMIT peut intervenir plusieurs fois dans une commande UNION. Elle sera appliquée à différentes commandes SELECT de la commande UNION, ou globalement à l'UNION.

   Le but de SQL_CALC_FOUND_ROWS pour UNION est de retourner le nombre de lignes qui aurait été retourné sans la clause globale LIMIT. Les conditions d'utilisation de SQL_CALC_FOUND_ROWS avec UNION sont

        - Le mot clé SQL_CALC_FOUND_ROWS doit apparaître dans le premier SELECT de l'UNION.
        - La valeur de FOUND_ROWS() est exactement la même que si UNION ALL était utilisé. Si UNION sans ALL est utilisé, des réductions de doublons surviendront, et la valeur de FOUND_ROWS() sera approximative.
        - Si aucune clause LIMIT n'est présente dans UNION, SQL_CALC_FOUND_ROWS est ignoré et retourne le nombre de lignes dans la table temporaire créé durant le traitement de l'UNION.

LAST_INSERT_ID(), LAST_INSERT_ID(expr) Retourne le dernier identifiant automatiquement généré par une colonne AUTO_INCREMENT.

mysql› SELECT LAST_INSERT_ID() ;
-› 195

   Le dernier ID généré est conservé par le serveur pour chaque connexion. Un autre client ne la modifiera donc pas, même s'ils génèrent une autre valeur AUTO_INCREMENT de leur coté. Ce comportement permet de s'assurer que les actions des autres clients ne perturbe pas les actions du client en cours. La valeur de LAST_INSERT_ID() ne sera pas modifiée non plus si vous modifiez directement la valeur d'une colonne AUTO_INCREMENT avec une valeur simple (c'est à dire, une valeur qui n'est ni NULL, ni 0).

   Si vous insérez plusieurs lignes au même moment avec une requête INSERT, LAST_INSERT_ID() retourne la valeur de la première ligne insérée. La raison à cela est que cela rend possible la reproduction facilement la même requête INSERT sur d'autres serveurs. Si vous utilisez une commande INSERT IGNORE et que la ligne est ignorée, le compteur AUTO_INCREMENT sera malgré tout incrémenté, et LAST_INSERT_ID() retournera une nouvelle valeur. Si expr est donnée en argument à la fonction LAST_INSERT_ID(), alors la valeur de l'argument sera retourné par la fonction et sera enregistré comme étant la prochaine valeur retournée par LAST_INSERT_ID(). Cela peut être utilisé pour simuler des séquences.

Commencez par créer la table suivante
mysql› CREATE TABLE sequence (id INT NOT NULL) ;
mysql› INSERT INTO sequence VALUES (0) ;
Utilisez cette table pour générer des séquences de nombre comme ceci
mysql› UPDATE sequence SET id=LAST_INSERT_ID(id+1) ;
mysql› SELECT LAST_INSERT_ID() ;

   La commande UPDATE incrémente le compteur de séquence, et fait que le prochain appel à LAST_INSERT_ID() va retourner une valeur différente. La commande SELECT lit cette valeur. La fonction C mysql_insert_id() peut aussi être utilisée pour lire la valeur. Vous pouvez générer des séquences sans appeler la fonction LAST_INSERT_ID(), mais l'utilité d'utiliser cette fonction cette fois ci est que la valeur ID est gérée par le serveur comme étant la dernière valeur générée automatiquement. (sécurité multi-utilisateur). Vous pouvez retrouver le nouvelle ID tout comme vous pouvez lire n'importe quelle valeur AUTO_INCREMENT dans MySQL. Par exemple, la fonction LAST_INSERT_ID() (sans argument) devrait retourner la nouvelle ID.

   La fonction C de l'API mysql_insert_id() peut être également utilisée pour trouver cette valeur. Notez que la fonction mysql_insert_id() est incrémentée uniquement après des requêtes INSERT et UPDATE, donc, vous ne pouvez pas utiliser la fonction C de l'API pour trouver la valeur de LAST_INSERT_ID(expr) après avoir exécuté d'autres types de requêtes, comme SELECT ou bien SET.

SESSION_USER() est un synonyme de USER().
SYSTEM_USER() est un synonyme de USER().
USER() Retourne le nom d'utilisateur et le nom d'hôte courant MySQL. La valeur indique le nom d'utilisateur qui a été spécifié lors de l'identification avec le serveur MySQL, et l'hôte client avec lequel il est connecté

mysql› SELECT USER() ;
-› 'davida@localhost'

VERSION() Retourne une chaîne indiquant la version courante du serveur MySQL. Notez que si votre version se termine par -log, cela signifie que le système d'historique est actif.

mysql› SELECT VERSION() ;
-› '4.1.2-alpha-log'

Fonctions dans SELECT et WHERE - Fonctions diverses

FORMAT(X,D) Formate l'argument X en un format comme '#,###,###.##', arrondi à D décimales. Si D vaut 0, le résultat n'aura ni séparateur décimal, ni partie décimale

mysql› SELECT FORMAT(12332.123456, 4) ;
-› '12,332.1235'
mysql› SELECT FORMAT(12332.1,4) ;
-› '12,332.1000'
mysql› SELECT FORMAT(12332.2,0) ;
-› '12,332'

GET_LOCK(str,timeout) Tente de poser un verrou nommé str, avec un délai d'expiration (timeout) exprimé en seconde. Retourne 1 si le verrou a été posé avec succès, 0 si il n'a pas pu être posé avant l'expiration du délai et NULL si une erreur est survenu (comme par exemple un manque de mémoire, ou la mort du thread lui-même, par mysqladmin kill). Un verrou sera levé lorsque vous exécuterez la commande RELEASE_LOCK(), GET_LOCK() ou si le thread se termine. Cette fonction peut être utilisée pour implémenter des verrous applicatifs ou pour simuler des verrous de lignes. Les requêtes concurrentes des autres clients de même nom seront bloquées ; les clients qui s'entendent sur un nom de verrou peuvent les utiliser pour effectuer des verrouillages coopératifs.

mysql› SELECT GET_LOCK("lock1",10) ;
-› 1
mysql› SELECT IS_FREE_LOCK("lock2") ;
-› 1
mysql› SELECT GET_LOCK("lock2",10) ;
-› 1
mysql› SELECT RELEASE_LOCK("lock2") ;
-› 1
mysql› SELECT RELEASE_LOCK("lock1") ;
-› NULL

   Notez que le deuxième appel à RELEASE_LOCK() retourne NULL car le verrou "lock1" a été automatiquement libéré par le deuxième appel à GET_LOCK().

INET_ATON(expr) Retourne un entier qui représente l'expression numérique de l'adresse réseau. Les adresses peuvent être des entiers de 4 ou 8 octets.

mysql› SELECT INET_ATON("209.207.224.40") ;
-› 3520061480

   Le nombre généré est toujours dans l'ordre des octets réseau ; par exemple, le nombre précédent est calculé comme ceci : 209*256^3 + 207*256^2 + 224*256 +40. Depuis MySQL 4.1.2, INET_ATON() comprend aussi les IP courtes

mysql› SELECT INET_ATON('127.0.0.1'), INET_ATON('127.1') ;
-› 2130706433, 2130706433

INET_NTOA(expr) Retourne l'adresse réseau (4 ou 8 octets), de l'expression numérique exp

mysql› SELECT INET_NTOA(3520061480) ;
-› "209.207.224.40"

IS_FREE_LOCK(str) Regarde si le verrou nommé str peut être librement utilisé (i.e., non verrouillé). Retourne 1 si le verrou est libre (personne ne l'utilise), 0 si le verrou est actuellement utilisé et NULL si une erreur survient (comme un argument incorrect).
IS_USED_LOCK(str) Vérifie si le verrou appelé str est actuellement posé ou pas. Si c'est le cas, la fonction retourne l'identifiant de connexion qui a le verrou. Sinon, elle retourne NULL.
MASTER_POS_WAIT(log_name, log_pos) Bloque le maître jusqu'à ce que l'esclave atteigne une position donnée dans le fichier d'historique principal, durant une réplication. Si l'historique principal n'est pas initialisé, retourne NULL. Si l'esclave n'est pas démarré, le maître restera bloqué jusqu'à ce que l'esclave soit démarré et ai atteint la position demandée. Si l'esclave a déjà dépassé cette position, la fonction se termine immédiatement. La valeur retournée est le nombre d'évènements qui a du être traité pour atteindre la position demandée, ou NULL en cas d'erreur. Cette fonction est très utile pour contrôler la synchronisation maître-esclave, mais elle a été initialement écrite pour faciliter les tests de réplications.
RELEASE_LOCK(str) Libère le verrou nommé str, obtenu par la fonction GET_LOCK(). Retourne 1 si le verrou a bien été libéré, 0 si le verrou n'a pas été libéré par le thread (dans ce cas, le verrou reste posé) et NULL si le nom du verrou n'existe pas. Le verrou n'existe pas si il n'a pas été obtenu par la fonction GET_LOCK() ou si il a déjà été libéré. La commande DO est utilisable avec RELEASE_LOCK().
UUID() Retourne un Universal Unique Identifier (UUID) généré grâce à "DCE 1.1 : Remote Procedure Call" (Appendix A) CAE (Common Applications Environment) Specifications, publié par le The Open Group en octobre 1997 (Document numéro C706).

   Un UUID est conçu comme un numéro qui est globalement unique dans l'espace, et le temps. Deux appels à UUID() sont supposés générer deux valeurs différentes, même si ces appels sont faits sur deux ordinateurs séparés, qui ne sont pas connectés ensembles. Un UUID est un nombre de 128 bits, représenté par une chaîne de 5 nombres hexadécimaux, au format aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee: Les trois premiers nombres sont générés à partir d'un timestamp. Le quatrième nombre préserver l'unicité temporelle si le timestamp perd sa monotonie (par exemple, à cause du changement d'heure d'hiver/été). Le cinquième nombre est un nombre IEEE 802 qui fournit l'unicité. Un nombre aléatoire est utilisé la si ce dernier n'est pas disponible (par exemple, comme l'hôte n'a pas de carte Ethernet, nous ne savons pas comment trouver une adresse matériel sur le système d'exploitation). Dans ce cas, l'unicité spatiale ne peut être garantie. Néanmoins, une collision aura une très faible propriété.

mysql› SELECT UUID() ;
-› '6ccd780c-baba-1026-9564-0040f4311e29'

Fonctions dans GROUP BY

AVG(expr) Retourne la moyenne de l'expression expr

mysql› SELECT student_name, AVG(test_score)
-› FROM student
-› GROUP BY student_name ;

BIT_AND(expr) Retourne la combinaison AND bit à bit de expr. Le calcul est fait en précision de 64 bits (BIGINT).
BIT_OR(expr) Retourne la combinaison OR bit à bit de expr. Le calcul est fait en précision de 64 bits (BIGINT). Cette fonction retourne 0 s'il n'y a pas de ligne à traiter.
BIT_XOR(expr) Retourne la combinaison XOR bit à bit de expr. Le calcul est fait en précision de 64 bits (BIGINT). Cette fonction retourne 0 s'il n'y a pas de ligne à traiter.
COUNT(expr) Retourne le nombre de valeurs non-NULL dans les lignes lues par la commande SELECT

mysql› SELECT student.student_name,COUNT(*)
-› FROM student,course
-› WHERE student.student_id=course.student_id
-› GROUP BY student_name ;

COUNT(*) est un peu différente dans son action, car elle retourne le nombre de lignes, même si elles contiennent NULL. COUNT(*) est optimisée pour retourner très rapidement un résultat si SELECT travaille sur une table, qu'aucune autre colonne n'est lue, et qu'il n'y a pas de clause WHERE. Par exemple:

mysql› SELECT COUNT(*) FROM student ;

   Cette optimisation s'applique uniquement pour les tables MyISAM et ISAM, car un compte exact du nombre de lignes est stocké pour ces types de tables, et il peut être lu très rapidement. Pour les moteurs de tables transactionnels, (InnodB, BDB), le stockage de cette valeur est plus problématique, car plusieurs transactions peuvent survenir en même temps, et affecter ce compte.

COUNT(DISTINCT expr,[expr...]) Retourne le nombre de valeurs non-NULL distinctes:

mysql› SELECT COUNT(DISTINCT results) FROM student ;

   Avec MySQL, vous pouvez lire le nombre d'expression distinctes qui ne contiennent pas NULL, en plaçant ici une liste d'expression. Avec SQL-99, vous devriez faire une concaténation de toutes les expressions dans COUNT(DISTINCT ...)

GROUP_CONCAT(expr) Syntaxe complète:
GROUP_CONCAT([DISTINCT] expr [,expr ...]
[ORDER BY unsigned_integer | col_name | formula [ASC | DESC] [,col ...]]
[SEPARATOR str_val])
Retourne la chaîne résultant de la concaténation de toutes les valeurs du groupe

mysql› SELECT student_name,
-› GROUP_CONCAT(test_score)
-› FROM student
-› GROUP BY student_name ;
ou:
mysql› SELECT student_name,
-› GROUP_CONCAT(DISTINCT test_score
-› ORDER BY test_score DESC SEPARATOR " ")
-› FROM student
-› GROUP BY student_name ;

   Avec MySQL, vous pouvez obtenir la concaténation d'une série d'expressions. Vous pouvez éliminer les doublons en utilisant DISTINCT. Si vous voulez trier les valeurs du résultat, il faut utiliser ORDER BY. Pour trier en ordre inverse, ajoutez le mot clé DESC (descendant) au nom de la colonne que vous triez dans la clause ORDER BY. Par défaut, l'ordre est ascendant. Cela peut être spécifié explicitement avec le mot clé ASC. SEPARATOR est une chaîne qui sera insérée entre chaque valeur du résultat. La valeur par défaut est une virgule ",". vous pouvez supprimer le séparateur en spécifiant la chaîne vide SEPARATOR "".

   Vous pouvez donner une taille maximale à la variable group_concat_max_len de votre configuration. La syntaxe pour faire cela durant l'exécution est

SET [SESSION | GLOBAL] group_concat_max_len = unsigned_integer ;

   Si une taille maximale a été atteinte, le résultat sera tronqué à cette taille maximale. Note : il y a encore de petites limitations pour GROUP_CONCAT() lorsqu'il faut utiliser des valeurs DISTINCT avec ORDER BY et et en utilisant les valeurs BLOB.

MIN(expr), MAX(expr) Retourne le minimum ou le maximum de expr. MIN() et MAX() peuvent prendre des chaînes comme argument: dans ce cas, elles retournent la valeur minimale ou maximale de la valeur de la chaîne.

mysql› SELECT student_name, MIN(test_score), MAX(test_score)
-› FROM student
-› GROUP BY student_name ;

STD(expr), STDDEV(expr) Retourne la déviation standard de expr la racine carrée de la VARIANCE(). Ceci est une extension au standard SQL 99. La forme STDDEV() de cette fonction est fournie pour assurer la compatibilité Oracle.
SUM(expr) Retourne la somme de expr. Notez que si le résultat ne contient pas de ligne, cette fonction retournera NULL.
VARIANCE(expr) Retourne la variance standard de l'expression expr (en considérant que les lignes forment une population totale, et non pas un échantillon. Le nombre de ligne est le dénominateur.

Procédures stockées et fonctions

   Une procédure stockées est un jeu de commandes SQL qui réside sur le serveur. Une fois qu'elle sont enregistrées, les clients n'ont pas besoin de soumettre chaque commande individuellement, mais peuvent les lancer d'un seul coup.

   Les procédures stockées fournissent un gain de performances, car moins d'informations sont échangées entre le serveur et le client. En échange, cela augmente la charge du serveur, car ce dernier doit réaliser plus de travail. Souvent, il y a de nombreux clients, mais peut de serveurs.

- Les procédures stockées requièrent la table proc dans la base mysql.
- Le droit de CREATE ROUTINE est nécessaire pour créer une procédure stockée.
- Le droit de ALTER ROUTINE est nécessaire pour pouvoir modifier ou effacer une procédure stockée. Le droit est fourni automatiquement au créateur d'une routine.
- Le droit de EXECUTE est requis pour exécuter une procédure stockée. Cependant, ce droit est fourni automatiquement au créateur d'une routine. De plus, la caractéristique par défaut SQL SECURITY est définie (DEFINER), ce qui fait que les utilisateurs qui ont accès à une base de données associée à une routine ont le droit d'exécuter la routine

Déclencheurs

   Un déclencheur est un objet de base de données nommé, qui est associé à une table et qui s'active lorsqu'un événement particulier survient dans une table. les commandes suivantes configurent une table, ainsi qu'un déclencheur pour les commandes INSERT sur cette table. Le déclencheur va effectuer la somme des valeurs insérées dans une des colonnes

mysql› CREATE TABLE account (acct_num INT, amount DECIMAL(10,2)) ;
mysql› CREATE TRIGGER ins_sum BEFORE INSERT ON account
-› FOR EACH ROW SET @sum = @sum + NEW.amount ;

CREATE TRIGGER
CREATE TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_stmt

   Le déclencheur est associé à la table appelée tbl_name. tbl_name doit faire référence à une table permanente. Vous ne pouvez pas associer un déclencheur avec une table TEMPORARY ou une vue. trigger_time est le moment d'action du déclencheur. Il peut être BEFORE (avant) ou AFTER (après). trigger_event indique le type de commande qui active le déclencheur. Il peut valoir INSERT, UPDATE ou DELETE. Il ne peut pas y avoir deux déclencheurs pour une même table avec les mêmes configurations de moment et de commande.

   trigger_stmt est la commande à exécuter lorsque le déclencheur s'active. Si vous voulez utiliser plusieurs commandes, utilisez les agrégateurs BEGIN ... END. Cela vous permet aussi d'utiliser les mêmes codes que ceux utilisés dans des procédures stockées. Dans la commande d'activation d'un déclencheur, vous pouvez faire référence aux colonnes dans la table associée au déclencheur en utilisant les mots OLD et NEW. OLD.col_name fait référence à une colonne d'une ligne existante avant sa modification ou son effacement. NEW.col_name fait référence à une colonne d'une ligne après insertion ou modification.

   L'utilisation de SET NEW.col_name = value requiert le droit de UPDATE sur la colonne. L'utilisation de SET value = NEW.col_name requiert le droit de SELECT sur la colonne. La commande CREATE TRIGGER requiert le droit de SUPER.

DROP TRIGGER
DROP TRIGGER tbl_name.trigger_name Supprime un déclencheur. Le nom du déclencheur doit inclure le nom de la table, car chaque déclencheur est associé à une table particulière. La commande DROP TRIGGER requiert le droit de SUPER.

Vues

ALTER VIEW
ALTER VIEW view_name [(column_list)] AS select_statement Cette commande modifie la définition d'une vue. select_statement est le même que pour CREATE VIEW
CREATE VIEW CREATE [OR REPLACE] [ALGORITHM = MERGE | TEMPTABLE] VIEW view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]

Cette commande crée une nouvelle vue, ou remplace une vue existante si la clause OR REPLACE est fournie. La clause select_statement est une commande SELECT qui fournit la définition de la vue. La liste optionnelle de colonnes peut être fournie pour définir explicitement les noms des colonnes. Une vue peut être créée par différents types de commandes SELECT.
Par exemple, SELECT peut faire référence à une table seule, une jointure ou une UNION. La commande SELECT peut ne pas faire de référence à une table. Les exemples suivants définissent une vue qui sélectionne 2 colonnes dans une table, et leur applique une transformation

mysql› CREATE TABLE t (qty INT, price INT) ;
mysql› INSERT INTO t VALUES(3, 50) ;
mysql› CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t ;
mysql› SELECT * FROM v ;

   Par défaut, la vue est placée dans la base de données par défaut. Pour créer une vue explicitement dans une base de données, spécifiez le nom de la base de données lors de la création: db_name.view_name

mysql› CREATE VIEW test.v AS SELECT * FROM t ;

DROP VIEW
DROP VIEW [IF EXISTS] view_name [, view_name] ... [RESTRICT | CASCADE] DROP VIEW supprime une ou plusieurs vues. Vous devez avoir les droits de DROP pour chaque vue.
SHOW CREATE VIEW
SHOW CREATE VIEW view_name Cette commande montre la commande CREATE VIEW qui créera la vue spécifiée.

INFORMATION_SCHEMA

   Les métadonnées sont des informations sur les données, telles que le nom des bases de données, des tables, le type de données des colonnes ou les droits d'accès. On appelle aussi ces données le dictionnaire de données ou le catalogue système.
^
04 mai 2010

htmlpdflatexmanmd




MySQL - Optimisation

MySQL - Optimisation

Optimisation de MySQL

Limitations et inconvénients conceptuels

   Avec les tables de type MyISAM, MySQL utilise un verrouillage extrêmement rapide (plusieurs lecture / une seule écriture). Le plus gros problème survient quand vous avez un mélange de flux de modifications et des sélections lentes sur la même table. Si c'est un problème sur plusieurs tables, vous pouvez utiliser un autre type de table.

Suite de tests MySQL

crash-me est une page web qui test 450 points, utilisé notamment pour la portabilité. Actuellement vous pouvez vous faire une idée des tests en regardant le code et les résultats dans le répertoire sql-bench.
Les scripts de test ont été écrit en perl et utilisent le module perl DBI. Vous aurez aussi avoir besoin des pilotes spécifiques DBD de chaque serveurs que vous testez.

La suite de tests est située dans le dossier sql-bench. Pour exécuter la suite de tests, lancer run-all-tests
cd sql-bench
perl run-all-tests --server=server_name

Super Smack est un utilitaire de test, qui peut mettre le serveur à genou, utile pour tester les fortes charges du serveur avant sa mise en production.

Optimisation des commandes SELECT et autres requêtes

- Premièrement, ce qui affecte toutes les requêtes: plus votre système de droits est compliqué, plus vous aurez des baisses de performances.
- Si vous n'avez aucun GRANT, MySQL optimisera les vérifications de droit, pour les système volumineux, il est bénéfique d'éviter GRANT.
- Si vous n'avez pas de droits de niveau tables ou colonne, le serveur n'a pas à vérifier le contenu des tables tables_priv et columns_priv.
- Similairement, si vous n'avez pas de limites de ressources, le serveur n'a pas de comptes de ressources à faire.
- si le problème est spécifique à une expression MySQL ou une fonction, vous pouvez utiliser la fonction BENCHMARK() pour effectuer un test de performances. la syntaxe est BENCHMARK(100000,1+1G);

Syntaxe Explain (Obtenir des informations sur SELECT)

EXPLAIN tbl_name ou
EXPLAIN SELECT tbl_name
EXPLAIN tbl_name est un synonyme de DESCRIBE tbl_name ou SHOW COLUMNS FROM tbl_name

   Lorsque vous faite précéder SELECT avec EXPLAIN, MySQL vous explique comment il va traiter la commande SELECT, choisir les tables et index pour les jointures. Avec EXPLAIN, vous pouvez identifier les index à ajouter pour accélérer les commandes SELECT.Vous devriez souvent utiliser la commande ANALYSE TABLE pour mettre à jour les statistiques de cardinalité de vos tables, qui affectent les choix de l'optimiseur.

   En général, lorsque vous voulez rendre un SELECT ... WHERE plus rapide, la première chose à faire est de voir si vous pouvez ajouter des index. Toutes les références entre les tables doivent normalement être faites avec des index. Vous pouvez utiliser la commande EXPLAIN pour déterminer les index utilisés pour le SELECT.

  Pour aider MySQL à mieux optimiser les requêtes, exécutez myisamchk --analyze sur une table après l'avoir remplie avec quelques données consistantes. Cela met à jour une valeur pour chaque partie de l'index qui indique le nombre moyen de lignes qui ont la même valeur. Vous pouvez vérifier le retour de l'exécution d'analyze en faisant SHOW INDEX FROM nom_de_table et examiner la colonne Cardinality.

   Pour trier un index et des données par rapport à un index, utilisez myisamchk --sort-index --sort-records=1 (si vous voulez trier selon le premier index). Notez, toutefois, que ce tri n'est pas le plus optimal et prendra beaucoup de temps pour une grosse table.EXPLAIN affiche la valeur ALL dans la colonne type lorsque MySQL utilise n scans de table pour résoudre une requête. Cela arrive par exemple lorsque la table est si petite qu'il est plus rapide d'analyser la table que d'utiliser les index. C'est un cas courant pour les tables de moins de 10 lignes, et de taille de ligne faible.

Pour éviter les scans de grosses tables
ANAYZE TABLE
Pour forcer l'utilisation d'un index
FORCE INDEX.

Conception

   MySQL conserve les données et les index dans deux fichiers séparés. De nombreux (et en fait presque toutes) les autres bases mélangent les données et les index dans le même fichier.

- Rendre les tables aussi compact que possible
- réduire la taille des données optimise les performances, l'indexation de colonnes de petites taille prend aussi moins de ressources.
- utiliser les types les plus efficaces et les plus petits possible
- utiliser les types d'entiers les plus petits possibles, par exemple MEDIUMINT est préférable a INT
- Déclarez des colonnes NOT NULL si possibles colonnes de taille variable prennent moins de place sur le disque
- la clé primaire doit être aussi courte que possible, cela rend l'identification des lignes plus efficace.
- Ne créer que des index dont vous avez besoin, les index sont bons pour accélérer les lectures, mais sont plus lents pour les écriture des données
- s'il est probable qu'une colonne a un préfixe unique avec les premiers caractères, il est mieux de n'indexer que ce préfixe.
- il peut être parfois intéressant de séparer en 2 une table qui est scannée très souvent.

- tous les types de colonnes de MySQL peuvent être indexés.
- vous pouvez avec tous les gestionnaire de tables avoir au moins 16 clés et une taille d'index d'au moins 256 octets.
- pour les colonnes CHAR et VARCHAR, il est possible d'indexer un préfixe de la colonne.
- les moteurs de table MyISAM et InnoDB supportent aussi l'indexation des colonnes BLOB et TEXT. Lors de l'indexation, vous devez spécifier une taille pour l'index:
CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
- MySQL peut créer des index sur plusieurs colonnes. Un index peut comprendre jusqu'à 15 colonnes (sur les colonnes de type CHAR et VARCHAR, vous pouvez utiliser uniquement le début de la colonne pour l'indexation).
- Un index sur plusieurs colonnes peut être compris comme un tableau trié contenant des valeurs créées par concaténation des valeurs des colonnes indexées.

mysql› CREATE TABLE test (
-› id INT NOT NULL,
-› nom CHAR(30) NOT NULL,
-› prenom CHAR(30) NOT NULL,
-› PRIMARY KEY (id),
-› INDEX nom_index (nom,prenom)) ;
l'index nom_index sera utilisé pour les requêtes suivantes:
mysql› SELECT * FROM test WHERE nom="Widenius" ;
mysql› SELECT * FROM test WHERE nom="Widenius"
-› AND prenom="Michael" ;
mysql› SELECT * FROM test WHERE nom="Widenius"
-› AND (prenom="Michael" OR prenom="Monty") ;
mysql› SELECT * FROM test WHERE nom="Widenius"
-› AND prenom ›="M" AND prenom ‹ "N" ;
mais nom_index ne sera pas utilisé pour:
mysql› SELECT * FROM test WHERE prenom="Michael" ;
mysql› SELECT * FROM test WHERE nom="Widenius"
-› OR prenom="Michael" ;
Tous les index de MySQL (PRIMARY, UNIQUE et INDEX) sont stockés sous la forme de B-tree.

Cache des tables MyISAM

   MyISAM utilise un cache qui garde en mémoire les blocs de tables les plus souvent utilisés. Pour les blocs d'index, un buffer de clés est utilisé. Pour les blocs de données, MySQL n'utilise pas de cache, mais exploite le cache natif du système de fichiers.

  Les accès aux caches de clés sont à accès simultanés entre les threads. Vous pouvez configurer plusieurs caches de clés, et assigner différents index de tables spécifiquement.

  Pour contrôler la taille du cache: key_buffer_size. À 0, le cache est désactivé. Le cache de clé est désactivé si la taille du buffer est top petite.

Sans cache de clé, les fichiers d'index sont lus avec le cache du système de fichier.
Accès au cache: un buffer non modifié est en accès simultanné, s'il est modifié, les threads sont en attente.
Cache de clé multiple: pour assigner un index à un cache spécifique:
CACHE INDEX

Les 2 commandes suivantes assignent les index des tables t1, t2 et t3 au cache de clé appelé hit_cache
mysql› CACHE INDEX t1, t2, t3 IN hot_cache ;


+---------+--------------------+----------+----------+
|--Table--|---------Op---------|-Msg_type-|-Msg_text-|
+---------+--------------------+----------+----------+
|-test.t1-|-assign_to_keycache-|--status--|----OK----|
|-test.t2-|-assign_to_keycache-|--status--|----OK----|
|-test.t3-|-assign_to_keycache-|--status--|----OK----|
+---------+--------------------+----------+----------+

le cache de clé peut être crée en spécifiant sa taille avec le paramètre
mysql› SET GLOBAL keycache1.key_buffer_size=128*1024;
pour détruire le cahce, lui donner une taille de 0
mysql› SET GLOBAL keycache1.key_buffer_size=0;

Pour un serveur en charge, nous recommandons la stratégie suivante pour le cache de clés:
- Un cache de clés principal qui représente 20% de l'espace alloué pour tous les caches de clés. Il sera utilisé par les tables qui sont le plus sollicitées, mais qui ne sont pas modifiées.
- Un cache de clé minoritaire qui représente 20%, Il sera utilisé pour les tables intermédiaires, qui sont intensivement modifiés, comme des tables temporaires par exemple.
- Un cache de clés secondaire qui représente 60% qui sera le cache par défaut, utilisé pour toutes les autres tables.

Stratégie d'insertion au milieu

   Par défaut le système de gestion de cache utilise la stratégie LRU (le moins utilisé est remplacé en premier). On peut choisir la stratégie de l'insertion par le milieu.

  Lors de l'utilisation de la stratégie d'insertion au milieu, la chaîne LRU est divisée en deux parties: une sous-chaîne principale, et une sous-chaîne secondaire. Le point de division entre les deux parties n'est pas fixé, mais le système s'assure que la partie principale n'est pas "trop petite", et qu'elle contient au moins key_cache_division_limit % de bloc de cache de clés. key_cache_division_limit est un composant d'une variable structurée de cache de clé, et sa valeur peut être modifiée indépendamment pour chaque cache.

   Lorsqu'un bloc d'index est lu dans une table, depuis le cache de clé, il est placé à la fin de la sous-chaîne secondaire. Après un certain nombre d'accès, il est promu dans la sous-chaîne principale. Un bloc de la chaîne principale est placé à la fin de la chaîne. Le bloc circule alors dans la la sous-chaîne. Si le bloc reste à la fin de la sous-chaîne suffisamment longtemps, il est rétrogradé dans la chaîne secondaire. Ce temps est déterminé par la valeur du composant key_cache_age_threshold.

  La stratégie de l'insertion au milieu vous permet de garder les blocs les plus utilisés dans le cache. Si vous préférez utiliser la stratégie LRU classique, laissez la valeur de key_cache_division_limit à 100.

   La stratégie d'insertion au milieu aide à améliorer les performances lorsque l'exécution d'une requête qui requiert un scan d'index place dans le cache toutes les valeurs de l'index. Pour éviter cela, vous devez utiliser la stratégie d'insertion au milieu, avec une valeur très inférieure à 100 pour key_cache_division_limit. Les blocs les plus utilisés seront conservés dans le cache durant un tel scan.

Préchargement des index

   S'il y a suffisamment de blocs dans le cache de clé pour contenir tout un index, ou au moins les blocs correspondant aux blocs non-terminaux, alors cela vaut la peine de pré-charger l'index avant de commencer à l'utiliser. Le pré-chargement vous permet de mettre les blocs d'index dans un buffer de cache le plus efficacement : il lit les blocs séquentiellement sur le disque.

Pour pré-charger un index dans un cache
LOAD INDEX INTO CACHE
Par exemple, la commande suivante précharge les index des tables t1 et t2
mysql› LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
L'option
IGNORE LEAVES
fait que les blocs non-terminaux seuls seront lus dans l'index. Par conséquent, la commande ci-dessus va charger tous les blocs de l'index de t1, mais uniquement les blocs non-terminaux de t2
Un cache de clé peut être restructuré à tout moment, en modifiant les valeurs de ses paramètres
mysql› SET GLOBAL cold_cache.key_buffer_size=4*1024*1024;
Si vous assignez une nouvelle valeurs aux variables key_buffer_size ou key_cache_block_size, le serveur va détruire l'ancienne structure du cache, et en recréer un

Quand MySQL ouvre et ferme les tables

table_cache, max_connections et max_tmp_tables affectent le nombre maximum de tables que le serveur garde ouvertes.
table_cache est lié au max_connections.

   Par exemple, pour 200 connexions simultanées, vous devriez avoir un cache de table d'environ 200*n, où n est le nombre maximum de table dans une jointure. Vous devez aussi réserver des pointeurs de fichiers supplémentaires pour les tables temporaires et les fichiers. Assurez vous que votre système d'exploitation peut gérer le nombre de pointeurs de fichiers demandé par l'option table_cache. Si table_cache est trop grand, MySQL peut être à court de pointeurs, et refuser des connexions, échouer à l'exécution de requêtes, ou être très instable. Vous devez aussi prendre en compte que les tables MyISAM peuvent avoir besoin de deux pointeurs de fichiers pour chaque table différente. Vous pouvez augmenter le nombre de pointeurs de fichiers disponibles pour MySQL avec l'option de démarrage -open-files-limit=#.

   Le cache de tables ouvertes reste au niveau de table_cache entrées (par défaut, 64 ; cela peut être modifié avec l'option -O table_cache=# de mysqld). Notez que MySQL peut ouvrir temporairement plus de tables, pour être capable d'exécuter des requêtes.

  Une table qui n'est pas utilisée est refermée, et supprimée du cache de table, dans les circonstances suivantes:

        - Lorsque le cache est plein, et qu'un thread essaie d'ouvrir une table qui n'est pas dans le cache.
        - Lorsque le cache contient plus de table_cache lignes, et qu'aucun thread n'utilise cette table.
        - Lorsque quelqu'un utilise la commande mysqladmin refresh ou mysqladmin flush-tables.
        - Lorsque quelqu'un exécute la commande FLUSH TABLES.

   Si vous ouvrez une table avec HANDLER table_name OPEN, un objet de table dédié sera alloué pour le thread. Cet objet de table n'est pas partagé avec les autres threads, et il ne sera pas fermé avant que le thread n'appelle HANDLER table_name CLOSE, ou que le thread ne meurt

Optimiser le serveur mysql

Si vous avez bcp de RAM et que vous voulez des performances maximales, vous pouvez essayer
shell› safe_mysqld -O key_buffer=64M -O table_cache=256 -O sort_buffer=4M -O read_buffer_size=1M &
Si vous n'avez que 128 Mo et seulement quelques tables, mais que vous demandez beaucoup de classements, vous pouvez essayer cela
shell› safe_mysqld -O key_buffer=16M -O sort_buffer=1M
Si vous avez peu de mémoire et beaucoup de connections, essayez cela
shell› safe_mysqld -O key_buffer=512k -O sort_buffer=100k -O read_buffer_size=100k &
Ou encore
shell› safe_mysqld -O key_buffer=512k -O sort_buffer=16k -O table_cache=32 -O read_buffer_size=8k -O net_buffer_length=1K &

   Si vous utilisez GROUP BY ou ORDER BY sur des fichiers de taille supérieure à la mémoire disponible, vous devriez augmenter la valeur de record_rnd_buffer pour accélérer la lecture des lignes après que le classement ait été fait

  A l'installation de MySQL, un répertoire support-files est créé, et contient plusieurs exemples de fichiers my.cnf: my-huge.cnf, my-large.cnf, my-medium.cnf et my-small.cnf. Vous pouvez les utiliser comme base pour optimiser votre système.

  Si vous avez vraiment beaucoup de connections, des problèmes peuvent apparaître avec le fichier d'échange si mysqld n'a pas été configuré pour utiliser peu de mémoire pour chaque connexion. mysqld fonctionne mieux si vous avez suffisamment de mémoire pour toutes les connections.

Pour voir les effets d'un changement de paramètre, essayez
shell› mysqld -O key_buffer=32m --help

   MySQL 5.0.1 propose une nouvelle méthode plus souple pour l'optimisation, qui permet à l'utilisateur de contrôler l'exhaustivité de la recherche de l'optimisateur dans sa quête pour la méthode la plus efficace pour traiter une requête. L'idée générale est que plus le nombre de méthodes étudiées est petit, moins l'optimisateur prendra de temps à compiler la requête.

  La variable optimizer_prune_level indique à l'optimisateur d'omettre des méthodes basées sur l'estimation du nombre de lignes utilisées dans les tables. Notre expérience montre que ce type de "prévision" échoue rarement, tout en réduisant considérablement le temps de compilation des requêtes. C'est pour cela que cette variable est active par défaut.

   La variable optimizer_search_depth indique la "profondeur" d'analyse de l'optimisateur. Les valeurs les plus faibles de optimizer_search_depth peuvent conduire à de grandes différences dans le temps de compilation. Par exemple, une requête avec 12-13 ou plus peut facilement prendre des heures ou des jours à compiler si optimizer_search_depth a une valeur proche du nombre de tables à traiter. Mais, si optimizer_search_depth vaut 3 ou 4, le compilateur peut traiter cette requête en une minute environ. Si vous n'êtes pas sûrs de la valeur raisonnable de optimizer_search_depth, donnez lui la valeur de 0 pour que l'optimisateur puisse déterminer la valeur automatiquement.

Influence de la compilation et des liaisons sur la vitesse de MySQL

   Les exécutables les plus rapides sont obtenus en liant avec -static. le code le plus rapide sera obtenu en compilant avec pgcc et -O3.

  Il est aussi possible d'utiliser CXX=gcc à la configuration de MySQL pour éviter l'inclusion de la bibliothèque libstdc++ (qui n'est pas nécessaire).

  A la compilation de MySQL, vous devriez uniquement utiliser le support des caractères que vous allez utiliser. (Option --with-charset=xxx.)

Liste des mesures que nous avons effectués

- L'utilisation de pgcc et la compilation complète avec l'option -O6 donne un serveur mysqld 1% plus rapide qu'avec gcc 2.95.2.
- Si vous utilisez la liaison dynamique (sans -static), le résultat est 13% plus lent sur Linux.
- Sachez que vous pouvez néanmoins utiliser la liaison dynamique pour les bibliothèques de MySQL. Seul le serveur a des performances critiques.
- Si vous allégez votre binaire mysqld avec l'option strip libexec/mysqld, vous obtenez un binaire jusqu'à 4% plus rapide.
- Si vous utilisez TCP/IP plutôt que les sockets Unix, le résultat est 7.5% plus lent sur le même ordinateur. (Si vous vous connectez sur localhost, MySQL utilisera les sockets par défaut.)
- Si vous vous connectez en TCP/IP depuis un autre ordinateur avec un lien Ethernet 100 Mo/s, le résultat sera 8 à 11% plus lent.
- L'utilisation de connections sécurisées ( toutes les données chiffrées par le support interne de SSL) pour nos tests comparatifs a provoqué une perte de vitesse de 55%.
- Si vous compilez avec --with-debug=full, vous perdrez 20% de performances sur la plupart des requêtes, mais la perte peut être plus importante sur certaines requêtes
- La compilation sur Linux-x86 avec gcc sans les pointeurs -fomit-frame-pointer ou -fomit-frame-pointer -ffixed-ebp rend mysqld 1 à 4% plus rapide.

Gestion de la mémoire du serveur

- Le buffer de clés (variable key_buffer_size) est partagé par tous les threads. Les autres buffers sont alloués par le serveur suivant les besoins.
- Chaque connexion utilise un espace spécifique au thread:

        - une pile (par défaut, 64 ko, variable thread_stack),
        - un buffer de connexion (variable net_buffer_length),
        - un buffer de résultat (variable net_buffer_length).
        - Le buffer de connexion et celui de résultat sont dynamiquement élargit jusqu'à max_allowed_packet suivant les besoins. Lorsque la requête s'exécute, une copie de la chaîne de requête est aussi allouée.

- Tous les threads partagent la même mémoire de base.
- Chaque requête qui effectue une analyse séquentielle d'une table, alloue un buffer de lecture (variable record_buffer).
- Lors de la lecture de lignes en ordre 'aléatoire' (par exemple, après un tri), un buffer de lecture aléatoire est allouée pour éviter les accès disques (variable record_rnd_buffer).
- Toutes les jointures sont faîtes en une seule passe, et la plupart des jointure sont faîtes sans utiliser de table temporaire. La plupart des table temporaires sont faîtes en mémoire (table HEAP). Les tables temporaires avec beaucoup de données (calculées comme la somme des tailles de toutes les colonnes) ou qui contiennent des colonnes de type BLOB sont sauvées sur le disque.
- La plupart des requêtes qui sont triées allouent un buffer de tri, et entre 0 et 2 fichiers temporaires
- Toute l'analyse et les calculs sont faits en mémoire locale. Aucune mémoire supplémentaire n'est nécessaire pour les petits calculs, et les allocations et libérations de mémoire sont évités. La mémoire n'est allouée que pour les chaînes très grandes
- Chaque fichier d'index est ouvert une fois, et le fichier de données est ouvert pour chaque thread concurrent. Pour chaque thread concurrent, une structure de table, une structure de colonne pour chaque colonne et un buffer de taille 3 * n est alloué (où n est la taille maximale de ligne, en dehors des colonnes de type BLOB). Une colonne de type BLOB utilise 5 à 8 octets de plus que la taille des données du BLOB. Les gestionnaires de table ISAM/MyISAM utilisent un buffer d'une ligne de plus pour leur utilisation interne
- Pour chaque table qui a une colonne BLOB, un buffer est dynamiquement agrandi pour lire les valeurs BLOB. Si vous analysez toute une table, un buffer aussi grand que la plus grande valeur de la colonne BLOB sera alloué.
- Les gestionnaires de tables pour les tables en cours d'utilisation sont sauvées dans un cache, et géré comme une pile FIFO. Normalement, ce cache contient 64 lignes. Si une table doit être utilisée par deux threads concurrents simultanément, le cache contiendra deux entrées pour la table.

MySQL et DNS

- Si votre service DNS est très lent et que vous avez beaucoup d'hôtes, vous pouvez améliorer les performances soit en désactivant le DNS avec --skip-name-resolve, soit en augmentant la taille de HOST_CACHE_SIZE (par défaut : 128) et en recompilant mysqld
- Il est possible de désactiver le cache de noms d'hôte avec --skip-host-cache.
- Il est possible de vider le cache des noms d'hôtes avec FLUSH HOSTS ou avec mysqladmin flush-hosts.
- Si vous ne voulez pas autoriser les connections par TCP/IP, vous pouvez utiliser l'option --skip-networking au démarrage de mysqld.

Problème avec les disques

   Utiliser des liens symboliques

  Cela signifie que vous allez faire un lien symbolique sur le fichier d'index et/ou le fichier de données sur un autre disque. Cela améliore les lectures et écriture.

  Sous Linux, vous pouvez améliorer les performances (jusqu'à 100% en charge n'est pas difficile) en utilisant hdparm pour configurer votre interface disque.

La commande suivante doit être une série de bonnes options de hdparm pour MySQL (et probablement d'autres applications)
hdparm -m 16 -d 1
Si vous n'avez pas besoin de savoir quand un fichier a été accédé la dernière fois (ce qui n'est pas utile avec un serveur de base de données), vous pouvez monter votre système de fichier avec l'option
-o noatime
vous pouvez monter des disques avec l'option
-o async
pour que le système de fichiers soit modifié de manière asynchrone.
^
19 mai 2010

htmlpdflatexmanmd




MySQL - Réplication

MySQL - Réplication

Réplication MySQL

   MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et les autres servent d'esclaves. Le serveur entretient des logs binaires, ainsi qu'un fichier d'index des logs binaires.

   Chaque esclave, après connexion réussie au serveur maître, indique le point qu'il avait atteint depuis la fin de la dernière réplication, puis récupère les dernière modifications, puis se met en attente des prochains évènements en provenance du maître.

  Un esclave peut aussi servir de maître à son tour, pour réaliser une chaîne de réplication. toute modification des tables sont répliquées, et doivent intervenir sur le serveur maître.

  On peut utiliser la commande LOAD DATA FROM MASTER pour configurer une esclave. Mais ne fonctionne que si toutes les tables du maître sont du type MyISAM, et qu'il est possible d'obtenir un verrou de lecture global, pour qu'aucune lecture ne se fasse durant le transfert des tables depuis le maître.

   Cette limitation est temporaire et sera supprimée une fois le système de sauvegarde programmé. On estime une vitesse de 1Mo par seconde.

  Si le maître est indisponible ou que la connexion est perdue, l'esclave va tenter une reconnexion tous les master-connect-retry secondes.

  Les capacités de réplications de MySQL sont implémentées à l'aide de 3 threads : 1 sur le maitre et 2 sur l'esclave. Lorsque la commande START SLAVE est envoyée, l'esclave crée un thread d'I/O qui se connecte au maître et lit les logs binaires. le maître crée un thread pour envoyer les logs binaires. Ce thread est le Binlog Dump dans le résultat de SHOW PROCESSLIST. Le 3eme thread lit les commandes et les exécute. pour obtenir des info sur les esclaves : SHOW SLAVE STATUS.

Fichiers de relais et de statut de la réplication

   Par défaut ils sont nommés sous la forme host_name-relay-bin.nnnhost_name est le nom de l'esclave. l'esclave garde la trace des logs dans un fichier d'index host_name-relay-bin.index. Les noms par défaut se remplacent avec les options : --relay-log et --relay-log-index.

  ces logs ont le même format que les logs binaires et peuvent être lus avec mysqlbinlog.

  Un log est crée à chaque démarrage du serveur, par la commande FLUSH LOGS ou une taille supérieure à max_relay_log_size.

  Un esclave crée 2 autres fichiers appelés master.info et relay-log.info qui contiennent des informations comme celle affichées par la commande SHOW SLAVE STATUS.

  Si vous perdez les logs, mais que relay-log.info existe, on peut l'étudier pour déterminer ce que le thread SQL a traité, puis utiliser CHANGE MASTER TO avec les options MASTER_RELAY_LOG et MASTER_RELAY_POS pour lui faire relire les logs depuis ce point.

Mise en place de la réplication

   Il est nécessaire d'éteindre brièvement le serveur principal.

  Créer un utilisateur Mysql spécial pour la réplication, avec les droits de REPLICATION SLAVE. Il faut lui donner les droits de réplication depuis tous les esclaves. Le nom d'hôte doit être tel que chaque serveur esclave peut l'utiliser pour se connecter au maître :

  GRANT REPLICATION SLAVE ON generator.php TO replication@'%s' identified by 'password'

  Si on envisage d'utiliser LOAD TABLE FROM MASTER ou LOAD DATA FROM MASTER sur l'esclave, on doit donner des droits supplémentaires : SUPER et RELOAD, ainsi que les droits SELECT sur les tables à charger.

  Si on utilise des tables MyISAM, décharger toutes les tables et blocs en utilisant FLUSH TABLES WITH READ LOCK ; puis faire une sauvegarde des données du maître.

Éventuellement compresser la sauvegarde
tar -cvf /tmp/mysql-snapshot.tar ./cette_base
puis copier l'archive sur l'esclave au même emplacement et la décompresser
tar -xvf /tmp/mysql-snapchot.tar
Il n'est pas besoin de répliquer la base mysql
Lorsque le verrou de lecture a été posé par
FLUSH TABLES WITH READ LOCK
lire les valeurs courantes du fichier de log et de son offset sur le maitre
SHOW MASTER STATUS;
la colonne file montre le nom du fichier de log et la colonne position affiche l'offset. Pour enlever le verrou
UNLOCK TABLES;
pour faire une sauvegarde rapide d'une base InnoDB le mieux est d'arrêter le serveur, puis de copier les fichiers de données InnoDB, leur logs et leur fichier de définition (.frm). Puis utiliser
SHOW MASTER STATUS
Pour noter l'offset courant. Puis éteindre le serveur sans déverrouiller le serveur et vérifier par
mysqladmin -root shutdown
Une alternative, valable pour les 2 types MyISAM et InnoDB est de prendre un export SQL du maître mais c'est plus long
mysqldump -master-data
sur le maitre, puis exécuter les commandes SQL sur les esclaves

- Si le maître fonctionne sans l'option -log-bin, le nom du fichier de log et l'offset seront vides, dans ce cas utiliser la chaîne vide ('') comme nom de fichier de log et la valeur 4 comme offset.
- Dans my.cnf, ajouter les options -log-bin et server-id=unique_number dans le groupe [mysqld]. Chaque serveur doit avoir un identifiant différent.
- Copier la sauvegarde des données dans les esclaves, s'assurer que les droits sur ces données sont corrects. L'utilisateur qui fait fonctionner MySQL doit avoir les droits d'écriture et de lecture sur ces bases, comme le maître.
- Redémarrer les esclaves. lancer l'esclave avec l'option --skip-slave-start s'il était déjà configuré pour la réplication. Utiliser --log-warnings pour plus de détails.
- Si vous avez fait une sauvegarde du maître avec l'utilitaire mysqldump, charger l'export avec mysql -u root -p ‹ dump_file.sql

puis sur l'esclave en utilisant les valeurs lu sur le maître
mysql› CHANGE MASTER TO
-› MASTER_HOST='‹master host name›',
-› MASTER_USER='‹replication user name›',
-› MASTER_PASSWORD='‹replication password›',
-› MASTER_LOG_FILE='‹recorded log file name›',
-› MASTER_LOG_POS=‹recorded log offset› ;
Lancer les thread esclaves
mysql › START SLAVE ;
l'esclave devrait alors se connecter au maître pour rattraper les modifications.

Une fois que l'esclave a initié la réplication, vous trouverez 2 fichiers : master.info et relay.info
Options pour les esclaves, normalement il y'en a pas besoin ils sont dans master.info

--master-host
--master-user
--master-password
--master-port
--master-connect-retry
--master-ssl
--master-ssl-ca
--master-ssl-capath
--master-ssl-cert
--master-ssl-cipher
--master-ssl-key

   Ces commandes sont utilisés lors du lancement de l'esclave la première fois ou après un RESET SLAVE et arrêté puis relancé le serveur. On peut préférer spécifier ces options avec CHANGE MASTER TO.

Exemple de configuration

[mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com

Options de contrôle de la réplication

--log-slave-updates Dit à l'esclave d'enregistrer les modifications effectuées par son thread SQL dans son propre log binaire. Par défaut, cette option est à Off. Pour que cette option ait un effet, l'esclave doit être lancé avec le log binaire activé. --log-slave-updates sert lorsque vous voulez faire une chaîne de serveur de réplication. Par exemple : A -› B -› C. C'est-à-dire, A sert de maître à l'esclave B, et B sert de maître à l'esclave C. Pour que cela fonctionne, avec B qui sert d'esclave et de maître simultanément, vous devez lancer B avec l'option --log-slave-updates. A et B doivent être lancés avec le log binaire activé.
--log-warnings Fait que l'esclave affiche plus de message sur ses activités Cette option n'est pas limitée à la réplication.
--master-connect-retry=seconds Le nombre de secondes qu'un esclave attend avant de tenter de se re-connecter au maître. Par défaut, elle vaut 60.
--master-host=host Spécifie l'hôte ou l'IP du maître de réplication. Si cette option n'est pas fournie, le thread esclave ne sera pas lancé.
--master-info-file=file_name Le nom à utiliser pour le fichier dans lequel l'esclave stocke les informations sur le maître. Par défaut, c'est mysql.info
--master-password=password Le mot de passe que l'esclave utilise lors de l'identification auprès du maître
--master-port=port_number Le port du maître que l'esclave utilise lors de l'identification auprès du maître. Si le port n'est pas configuré, la valeur de la variable MYSQL_PORT est utilisée. Si vous n'y avez pas touché lors de la compilation avec configure, ce doit être 3306
--master-ssl
--master-ssl-ca=file_name
--master-ssl-capath=directory_name
--master-ssl-cert=file_name
--master-ssl-cipher=cipher_list
--master-ssl-key=file_name Ces options servent à configurer la réplication chiffrée, lorsque la connexion avec le maître utilise SSL. Leurs significations respectives est la même que les options --ssl, --ssl-ca, --ssl-capath, --ssl-cert, --ssl-cipher, --ssl-key
--master-user=username Le nom d'utilisateur que l'esclave utilise lors de l'identification auprès du maître. Le compte doit avoir les droits de REPLICATION SLAVE. Si l'utilisateur maître n'est pas configuré, l'utilisateur test est utilisé.
--max-relay-log-size=# Pour faire la rotation automatique des logs.
--read-only Cette option fait que le serveur n'autorise aucune modification, hormis celles du thread esclave, ou celle des utilisateurs ayant les droits de SUPER. Cela peut être utile si vous voulez vous assurer que l'esclave ne reçoit aucune modification des clients.
--relay-log=filename Pour spécifier la localisation et le nom qui doivent être utilisés pour les logs de relais. Les noms par défaut sont de la forme host_name-relay-bin.nnn, où host_name est le nom du serveur esclave et nnn indique le numéro de séquence du log de relais. Vous pouvez utiliser ces options pour avoir des noms de fichier de log de relais indépendants du nom d'hôte, ou si vos logs ont tendances à devenir très grands (et que vous ne voulez pas réduire la valeur de max_relay_log_size) et que vous devez les mettre dans un autre dossier, ou simplement pour accélérer la vitesse d'équilibrage entre deux disques.
--relay-log-index=filename Pour spécifier la localisation et le nom qui doivent être utilisés pour le fichier d'index du log de relais. Le nom par défaut est host_name-relay-bin.index, où host_name est le nom du serveur esclave.
--relay-log-info-file=filename Pour donner au fichier relay-log.info un autre nom ou pour le placer dans un autre dossier. Le nom par défaut est relay-log.info dans le dossier de données.
--relay-log-purge=0|1 Active ou désactive la vidange automatique des logs de relais, dès qu'ils ne sont plus utiles. C'est une variable globale, qui peut être dynamiquement modifiée avec SET GLOBAL RELAY_LOG_PURGE=0|1. Sa valeur par défaut est 1.
--relay-log-space-limit=# Limite la taille maximale de tous les fichiers de logs de relais sur l'esclave (une valeur de 0 signifie "sans limite"). Lorsque la limite est atteinte, le thread d'I/O fait une pause : il ne lit plus rien dans le log binaire du maître, jusqu'à ce que le thread SQL ait avancé, et effacé des fichiers de logs. Notez que cette limite n'est pas absolue. Avec --relay-log-space-limit, il ne faut pas utiliser de valeur inférieure à deux fois la taille de --max-relay-log-size (ou --max-binlog-size si --max-relay-log-size vaut 0) car dans ce cas, il y a des chances que le thread d'I/O attende de l'espace libre parce que --relay-log-space-limit est dépassée, mais que le thread SQL n'ait pas de logs à effacer, et ne peut donc libérer le thread d'I/O, forcant le thread d'I/O à ignorer temporairement --relay-log-space-limit.
--replicate-do-db=db_name Indique à l'esclave qu'il doit restreindre la réplication aux commandes qui utilisent la base de données db_name par défaut (c'est à dire celle qui est sélectionnée avec la commande USE). Pour spécifier plusieurs base de données, utilisez cette option aussi souvent que nécessaire. Noter que cela ne va pas autoriser les commandes multi-bases, comme UPDATE some_db.some_table SET foo='bar' si une base de données différente ou qu'aucune base de données n'est sélectionnée. Si vous avez besoin que les commandes multi-bases fonctionnent, utilisez --replicate-wild-do-table=db_name.%

Un exemple qui pourrait ne pas fonctionner comme vous l'attendez: si l'esclave est lancé avec --replicate-do-db=sales et que vous émettez une commande sur le maître, la commande UPDATE suivante ne sera pas répliquée:
USE prices;
UPDATE sales.january SET amount=amount+1000 ;
Si vous avez besoin de répliquer des commandes multi-bases, utilisez l'option --replicate-wild-do-table=db_name.% à la place.
La raison principale de ce comportement "vérifie juste la base par défaut" est qu'il est difficile de savoir si une requête doit être répliquée, uniquement à partir de la requête. Par exemple, si vous utilisez une requête multi-tables DELETE ou multi-tables UPDATE, qui a des conséquences dans d'autres bases. La vérification de la base courante est aussi très rapide.

--replicate-do-table=db_name.table_name Dit à l'esclave qu'il doit restreindre la réplication à une table spécifiée. Pour spécifier plusieurs tables, il faut utiliser cette directive plusieurs fois, une fois par table. Cela fonctionnera pour les mises à jours multi-bases, au contraire de --replicate-do-db
--replicate-ignore-db=db_name Indique à l'esclave qu'il doit ne doit pas assurer la réplication avec les commandes qui utilisent la base de données db_name par défaut (c'est à dire celle qui est sélectionnée avec la commande USE). Pour spécifier plusieurs base de données, utilisez cette option aussi souvent que nécessaire. Note que cela ne va pas autoriser les commandes multi-bases, comme UPDATE some_db.some_table SET foo='bar' si une base de données différente ou qu'aucune base de données n'est sélectionnée. Si vous avez besoin que les commandes multi-bases fonctionnent, assurez vous que vous avez MySQL 3.23.28 ou plus récent, et utilisez --replicate-wild-do-table=db_name.%

Un exemple qui pourrait ne pas fonctionner comme vous l'attendez: si l'esclave est lancé avec --replicate-ignore-db=sales et que vous émettez une commande sur le maître, la commande UPDATE suivante ne sera pas répliquée
USE prices;
UPDATE sales.january SET amount=amount+1000;
Si vous avez besoin de répliquer des commandes multi-bases, utilisez l'option --replicate-wild-ignore-table=db_name.% à la place

--replicate-ignore-table=db_name.table_name Dit à l'esclave qu'il ne doit pas répliquer les commandes qui touchent à la table spécifiée, même si d'autres tables sont modifiées dans la même commande. Pour spécifier plusieurs tables, il faut utiliser cette directive plusieurs fois, une fois par table. Cela fonctionnera pour les mises à jours multi-bases, au contraire de --replicate-ignore-db

Notes sur cette liste d'options

--replicate-wild-do-table=db_name.table_name Dit à l'esclave qu'il doit restreindre la réplication aux tables dont le nom vérifie le masque spécifié. Le masque peut contenir les caractères ‘%’ et ‘_’, qui ont la même signification que dans les expressions régulières de la clause LIKE. Pour spécifier plusieurs tables, il faut utiliser cette directive plusieurs fois, une fois par table. Cela fonctionnera pour les mises à jours multi-bases, au contraire de --replicate-do-db

Exemple :
--replicate-wild-do-table=foo%.bar%
va répliquer les mises à jour qui surviennent sur toutes les tables de toutes les bases qui commencent par foo, et dont le nom de table commence par bar.

   Notez que si vous utilisez --replicate-wild-do-table=foo%.%, alors la règle sera propagée à CREATE DATABASE et DROP DATABASE, c'est à dire que ces deux commandes seront répliquées si le nom de la base correspond au masque (foo% ici) (la magie est ici déclenchée par % comme masque de table.).

  Si le masque de noms de tables est %, il accepte tous les noms de tables et les options s'appliquent aux commandes de niveau base de données (comme CREATE DATABASE, DROP DATABASE et ALTER DATABASE). Par exemple, si vous utilisez --replicate-wild-do-table=foo%.%, les commandes de niveau de base de données seront répliquées si le nom de la base de données est accepté par le masque foo%.

   Si vous voulez faire la réplication des tables du type ma_petite%base (ceci est le nom exact de la base), mais que vous ne voulez pas répliquer la base ma1petiteAABCbase, vous devez protéger les caractères '_' et '%': il faut utiliser une syntaxe équivalent à: replicate-wild-do-table=my\_own\%db. Et si vous spécifiez cette option en ligne de commande, suivant votre système, vous devrez protéger aussi le caractère \ (par exemple, en Shell bash, vous devez émettre une option sous la forme --replicate-wild-do-table=my\\_own\\%db).

--replicate-wild-ignore-table=db_name.table_name Dit à l'esclave qu'il ne doit pas répliquer les tables dont le nom vérifie le masque spécifié. Pour spécifier plusieurs tables, il faut utiliser cette directive plusieurs fois, une fois par table. Cela fonctionnera pour les mises à jours multi-bases, au contraire de --replicate-do-db.

Exemple
--replicate-wild-ignore-table=foo%.bar%
n'autorisera pas de modifications dans les tables des bases dont le nom commence par foo et dont le nom de table commence par bar. Pour des informations sur le fonctionnement du filtre, voyez l'option --replicate-wild-ignore-table. La règle pour inclure des caractères littéraux est la même que pour --replicate-wild-ignore-table.

--replicate-rewrite-db=from_name-›to_name Dit à l'esclave de remplacer la base courante (celle qui est sélectionnée avec USE) par to_name si elle était from_name sur le maître. Seules les commandes impliquant des tables peuvent être affectées. (CREATE DATABASE, DROP DATABASE ne le seront pas), et uniquement si from_name était la base de données courante sur le maître. Cela ne fonctionnera pas pour les commandes multi-bases de données. Notez que la traduction est faite avant que les règles --replicate-* ne soient testées.

Si vous utilisez cette option en ligne de commande, et que vous utilisez le caractère ‘’, qui peut être spécial pour votre interpréteur Shell, protégez-le comme ceci :
shell› mysqld --replicate-rewrite-db="olddb-›newdb"

--replicate-same-server-id À utiliser sur les serveurs esclaves. Généralement, vous pouvez spécifier la valeur 0 pour éviter les réplications infinies. Si cette option vaut 1, l'esclave n'ignorera pas les événements de réplication, même s'ils portent son propre numéro d'identification. Normalement, cela n'est utile que pour de très rares configurations. Vous ne pouvez pas mettre cette option à 1 si --log-slave-updates est utilisé.
--report-host=host Le nom d'hôte ou l'adresse IP de l'esclave, qui doit être indiquée lors de l'enregistrement de l'esclave chez le maître. Cela apparaîtra dans l'affichage de la commande SHOW SLAVE HOSTS. Laissez cette option vide pour que l'esclave ne s'enregistre pas sur le maître. Notez qu'il n'est pas suffisant pour que le maître lise l'adresse IP de l'esclave sur le socket, une fois que l'esclave se connecte. À cause du NAT et des problèmes de routages, cette IP peut être invalide pour se connecter au maître depuis l'hôte ou les autres esclaves.
--report-port=port_number Le port de connexion indiqué par l'esclave lors de son enregistrement chez le maître. Configurez cette option si l'esclave utilise un port autre que le port par défaut, ou si vous avez installé un tunnel spécial pour le maître ou les autres esclaves. Dans le doute, laissez cette option vide.
--skip-slave-start Dit à l'esclave de ne pas lancer les threads esclaves au démarrage du serveur. L'utilisateur pourra les lancer manuellement, avec START SLAVE.
--slave_compressed_protocol=# Si cette option vaut 1, alors le protocole client/serveur compressé sera utilisé, si l'esclave et le maître le supportent.
--slave-load-tmpdir=filename Cette option vaut par défaut la variable tmpdir. Lorsque le thread SQL réplique des commandes LOAD DATA INFILE, il extrait les fichiers à charger du log de relais dans un fichier temporaire, puis charge ce fichier dans la table. Si le fichier chargé sur le maître est immense, le fichier temporaire sera aussi grand. Il faudra donc dire à l'esclave de placer ces fichiers temporaires sur un grand disque, qui sera différent de tmpdir: utilisez cette option. Dans ce cas, vous pouvez aussi utiliser l'option --relay-log, car les fichiers de log de relais seront aussi grands. --slave-load-tmpdir doit pointer sur un système de fichier basés sur un disque, et non pas sur une portion de mémoire: l'esclave doit pouvoir accéder à ce fichier pour répliquer la commande LOAD DATA INFILE, même après un redémarrage.
--slave-net-timeout=# Le nombre de secondes à attendre des données du maître, avant d'annuler la lecture en considérant que la connexion est rompue, et de tenter de se reconnecter. La première reconnexion intervient immédiatement après l'expiration du délai. L'intervalle entre deux tentatives de connexion est contrôlé par l'option --master-connect-retry.
--slave-skip-errors= [err_code1,err_code2,... | all] Normalement, la réplication s'arrête lorsqu'une erreur survient, ce qui vous donne l'opportunité de résoudre les incohérences manuellement. Cette option Indique au thread SQL les erreurs qu'il doit ignorer durant la réplication. N'utilisez pas cette option si vous ne connaissez pas la raison des erreurs que vous rencontrez. S'il n'y a pas de bugs dans votre réplication, et qu'il n'y a pas de bug dans MySQL, vous ne devriez pas rencontrer d'erreurs, ni utiliser cette option. L'utilisation abusive de cette option conduit irrémédiablement l'esclave à être désynchronisé avec le maître sans que vous ne sachiez d'où vient l'erreur.

   Pour les codes d'erreur, il faut utiliser les numéros d'erreurs fournis par l'esclave dans le log d'erreur, et dans le résultat de SHOW SLAVE STATUS. La liste complète des messages d'erreurs est disponible dans la distribution source, dans le fichier Docs/mysqld_error.txt.

Exemple de réplication

   Mysql permet de multiples configurations de réplication.

  Sur le maître

  Dans /etc/mysql/my.cnf ajouter:

log-bin les log-bin doivent être activés, c'est sur ces log que se base la réplication
id-server=1 ce numéro doit être unique à chaque serveur

on crée l'utilisateur pour la réplication
GRANT REPLICATION SLAVE ON generator.php TO replication@'server-B' identified by 'password'
puis on lock les tables
FLUSH TABLES WITH READ LOCK;
on note le fichier de log et sa position ; attention la valeur n'est valide que si log-bin est déjà activé, sinon utiliser les valeur par défaut
SHOW MASTER STATUS ;
on copie les tables que l'on souhaite répliquer pour les envoyer sur l'esclave. et on enlève le verrou
UNLOCK TABLES;
on peut relancer le serveur mysql
/etc/init.d/mysql restart

   Sur le serveur esclave :

  dans /etc/mysql/my.cnf, dans la section [mysqld] ajouter:

log-bin
id-server=2
skip-slave-start cette options sert pour éviter de prendre en compte les options de réplication puisque l'on va la lancer en ligne.
#master-host=server-B on laisse ces lignes commentée pour le premier démarrage.
#master-port=3306
#master-user=replication
#master-password=password
#master-connect-retry=60
#report-host=db-slave.uubu
#log-slave-updates n'est utile qu'en cas d'un modèle de réplication A › B › C. B joue alors le rôle de relay

on crée l'utilisateur pour la réplication
GRANT REPLICATION SLAVE ON generator.php TO replication@'server-A' identified by 'password'
on stop le serveur mysql
/etc/init.d/mysql stop
on copie les bases du master, bien vérifier les droits ! On relance le serveur mysql
/etc/init.d/mysql start
on lance la réplication
mysql› CHANGE MASTER TO
-› MASTER_HOST='server-A',
-› MASTER_USER='replication',
-› MASTER_PASSWORD='password',
le fichier de log qu'on a noté via SHOW MASTER STATUS
-› MASTER_LOG_FILE='‹recorded log file name›',
idem pour la position
-› MASTER_LOG_POS=‹recorded log offset› ;
puis lancement en tant qu'esclave
START SLAVE
ouvrir de nouveau /etc/mysql/my.cnf
on peut supprimer skip-slave-start puisque la réplication est en place, et décommenter les lignes qu'on avait ajouté en commentaire. Relancer le serveur
/etc/init.d/mysql restart

Explication de log-slave-updates

   Le serveur B se base sur le log-bin du serveur A pour répliquer les données. Par défaut, le serveur B ne log pas dans ses log-bin les données de réplication. Dans le cas où on souhaiterai ajouter un serveur C qui se réplique sur B, il est nécessaire d'ajouter cette options, afin que les données répliquées soient bien écrite dans les log-bin.

Autres exemple de réplication

   Le système est très souple, ici j'explique une réplication de type A › B + le principe pour une réplication en chaîne de type A › B › C.

  Il est bien sûr possible que B et C se répliquent tous 2 sur A directement.

  Il est même possible de créer une réplication croisée de type A‹›B. La manip n'est pas très différente, mais un peu plus délicate.

  Dans un premier temps il faut suivre l'exemple ci-dessus pour créer une réplication de A vers B. Ensuite reprendre l'exemple, locker les tables sur B, noter le log-bin et sa position, puis suivre l'exemple de B ci-dessus, et l'appliquer sur A : renseigner /etc/mysql/my.cnf, relancer le serveur, puis lancer la réplication.
^
08 mai 2010

htmlpdflatexmanmd




mysqladmin

mysqladmin

Utilitaire d'administation de MySQL

COMMANDES

create databasename Crée une nouvelle base.
drop databasename Efface une base et toutes ces tables.
extended-status Affiche un message de statut du serveur très complet.
flush-hosts Vide tous les hôtes mis en cache.
flush-logs Vide de la mémoire tous les logs.
flush-privileges Recharger les tables de droits (identique à la commande reload).
flush-status Remet à zéro les variables de statut.
flush-tables Vide de la mémoire toutes les tables.
flush-threads Vide les threads de cache.
kill id,id,... Termine un thread MySQL.
password new-password Spécifie un nouveau mot de passe. Modifie l'ancien mot de passe en new-password pour le compte que vous utilisez lors de la connexion avec mysqladmin.
ping Vérifie si mysqld fonctionne ou pas.
processlist Affiche la liste des processus du serveur. Cela revient à la commande SHOW PROCESSLIST. Si --verbose est utilisé, le résultat est le même que SHOW FULL PROCESSLIST.
reload Recharge les tables de droits.
refresh Vide de la mémoire toutes les tables, puis ferme et réouvre les fichiers de logs.
shutdown Éteins le serveur.
slave-start Démarre l'esclave de réplication.
status Affiche le message de statut court du serveur.
slave-stop Éteind l'esclave de réplication.
variables Affiche les variable disponibles.
version Affiche la version du serveur.

   La commande mysqladmin status liste les colonnes suivantes:

        Uptime Nombre de secondes de vie du serveur MySQL.
        Threads Nombre de threads actifs (clients).
        Questions Nombre de questions reçu des clients depuis le démarrage de mysqld.
        Slow queries Nombre de requêtes qui ont pris plus de long_query_time secondes.
        Opens Combien de tables sont ouvertes par mysqld.
        Flush tables Nombre de commandes flush ..., refresh et reload.
        Open tables Nombre de tables qui sont ouvertes actuellement.
        Memory in use Mémoire allouée directement par mysqld (uniquement disponible si MySQL a été compilé avec l'option --with-debug=full).
        Maximum memory used Maximum de mémoire allouée directement par mysqld (uniquement disponible si MySQL a été compilé avec l'option --with-debug=full).

OPTIONS

--help, - ? Affiche le message d'aide et quitte.
--character-sets-dir=path Le dossier où les jeux de caractères sont stockés.
--compress, -C Compresse toutes les informations entre le client et le serveur, si les deux le supporte.
--count=#, -c # Le nombre d'itération à faire. Cela fonctionne uniquement avec --sleep (-i).
--debug[=debug_options], -# [debug_options] Écrit un log de débogage. La chaîne debug_options est souvent 'd:t:o,file_name'. La valeur par défaut est 'd:t:o,/tmp/mysqladmin.trace'.
--force, -f Ne demande pas de confirmation pour la commande drop database. Avec des commandes multiples, continue même si une erreur survient.
--host=host_name, -h host_name Connexion au serveur MYSQL avec le nom d'hôte donné.
--password[=password], -p[password] Le mot de passe utilisé lors de la connexion sur le serveur. S'il n'est pas donné en ligne de commande, il sera demandé interactivement. Notez que si vous utilisez la forme courte -p, vous ne devez pas laisser d'espace entre l'option et le mot de passe.
--port=port_num, -P port_num Le numéro de port TCP/IP pour la connexion.
--protocol=TCP | SOCKET | PIPE | MEMORY Spécifie le protocole de connexion à utiliser.
--relative, -r Affiche la différence entre la valeur courante et la valeur précédente, lorsque utilisé avec l'option -i. Actuellement, cette option fonctionne avec la commande extended-status.
--silent, -s Mode très silencieux.
--sleep=delay, -i delay Exécute les commandes encore et encore, avec delay secondes entre deux.
--socket=path, -S path Le fichier de socket à utiliser pour la connexion.
--user=user_name, -u user_name Nom d'utilisateur pour la connexion, si ce n'est pas l'utilisateur Unix courant.
--verbose, -v Affichage plus détaillé (-v -v -v indique le format d'affichage de table).
--version, -V Affiche la version et quitte.
--vertical, -E Affiche la sortie verticalement. Similaire à --relative, mais verticalement.
--wait[=#], -w[#] Si la connexion n'a pu être établie, attend et retente au lieu d'abandonner. Si une valeur est spécifiée, elle indique le nombre de tentatives. La valeur par défaut est 1 fois.

   Vous pouvez aussi configurer ces options avec la syntaxe --var_name=value:

        connect_timeout Le nombre de secondes avant une expiration de connexion. (Par défaut, 0.)
        shutdown_timeout Le nombre de seconde d'attente de l'extinction. (Par défaut, 0.)
^
08 mai 2010

htmlpdflatexmanmd




mysqlbinlog

mysqlbinlog

Exécuter des requêtes dans les logs binaire

OPTIONS

--database=db_name, -d db_name Limite les lignes à cette base de données (log local uniquement).
--force-read, -f Continue même si vous obtenez une erreur SQL.
--host=host_name, -h host_name Lit le log binaire depuis le serveur MySQL distant.
--local-load=path, -l path Prépare les fichiers temporaires destinés aux commandes LOAD DATA INFILE dans le dossier spécifié.
--offset=N, -o N Ignore les N première lignes.
--password[=password], -p[password] Le mot de passe utilisé lors de la connexion sur le serveur. S'il n'est pas donné en ligne de commande, il sera demandé interactivement. Notez que si vous utilisez la forme courte -p, vous ne devez pas laisser d'espace entre l'option et le mot de passe.
--port=port_num, -P port_num Le numéro de port TCP/IP pour la connexion.
--position=N, -j N Commence la lecture dans le log binaire à la position N.
--protocol=TCP | SOCKET | PIPE | MEMORY Spécifie le protocole de connexion à utiliser.
--read-from-remote-server, -R Lit le log binaire depuis un serveur MySQL. Les options de connexion distantes seront ignorées à moins que cette option ne soit donné. Ces options sont --host, --password, --port, --protocol, --socket et --user.
--result-file=name, -r name Export direct vers le fichier spécifié.
--short-form, -s Affiche uniquement les commandes du log, sans les informations supplémentaires.
--socket=path, -S path Le fichier de socket à utiliser pour la connexion.
--user=user_name, -u user_name Le nom d'utilisateur MySQL lors de la connexion à distance.
--version, -V Affiche la version et quitte.

Exemples

Vous pouvez envoyer le résultat de mysqlbinlog vers un client mysql avec un pipe: c'est une technique pour restaurer le serveur après un crash
shell› mysqlbinlog hostname-bin.000001 | mysql
ou:
shell› mysqlbinlog hostname-bin.[0-9]* | mysql
Si vous avez plus d'un fichier de log binaire à exécuter sur le serveur MySQL, la méthode sûre est de tout faire avec la même connexion MySQL.
shell› mysqlbinlog hostname-bin.000001 hostname-bin.000002 | mysql
La seconde méthode:
shell› mysqlbinlog hostname-bin.000001 › /tmp/statements.sql
shell› mysqlbinlog hostname-bin.000002 ›› /tmp/statements.sql
shell› mysql -e "source /tmp/statements.sql"
^
08 mai 2010

htmlpdflatexmanmd




mysqlcheck

mysqlcheck, mysqlrepair, mysqlanalyze, mysqloptimize

Outil d'entretient et de réparation de tables MyISAM

   À la différence de myisamchk, mysqlcheck s'utilise lorsque mysqld fonctionne. Il y'a 3 façons de l'utiliser:

shell› mysqlcheck [options] db_name [tables]
shell› mysqlcheck [options] --databases DB1 [DB2 DB3...]
shell› mysqlcheck [options] --all-databases

   mysqlcheck dispose l'une fonctionnalité spéciale, comparé aux autres clients: le comportement par défaut, c'est à dire la vérification des tables, peut être modifiée en renommant le fichier binaire. Si vous voulez avoir un fichier qui répare les tables par défaut, il suffit de copier mysqlcheck sur votre disque, et de l'appeler mysqlrepair, ou bien, de faire un lien symbolique sur l'exécutable et de l'appeler mysqlrepair. Si vous appelez mysqlrepair, il va réparer les tables par défaut.

Les noms qui change le mode par défaut sont
mysqlrepair L'option par défaut est --repair
mysqlanalyze L'option par défaut est --analyze
mysqloptimize L'option par défaut est --optimize

OPTIONS

-?, --help Affiche ce message d'aide, et termine.
--all-databases, -A Vérifie toutes les bases. C'est la même chose que --databases dans toutes les bases sélectionnées.
--all-in-1, -1 Au lieu de faire une requête par table, exécute toutes les requêtes dans une requête, séparément pour chaque base. Les noms de tables seront séparés par une virgule.
--analyze, -a Analyse les tables indiquées.
--auto-repair Si une table vérifiées est corrompue, la corrige automatiquement. La réparation sera faite après la vérification de toutes les tables, si des tables corrompues ont été découvertes.
--character-sets-dir=... Dossier contenant le jeu de caractères.
--check, -c Vérifie les tables en erreur
--check-only-changed, -C Vérifie uniquement les tables qui ont été modifiées depuis la dernière modification, ou qui n'ont pas été correctement fermées.
--compress Utiliser la compression du protocole client/serveur.
--databases, -B Pour tester plusieurs bases de données. Notez que la différence d'utilisation : dans ce cas, aucune table n'est précisé. Tous les arguments de noms sont considérés comme des noms de base.
--debug[=debug_options], -# [debug_options] Affiche le log de débogage. Souvent, la chaîne debug_options vaut 'd:t:o,nom_de_fichier'.
--default-character-set=... Spécifie le jeu de caractères par défaut.
--extended, -e Si vous utilisez cette option avec CHECK TABLE, elle va s'assurer que la table est totalement cohérente, mais prends beaucoup de temps. Si vous utilisez cette option avec REPAIR TABLE, elle va réaliser une réparation exhaustive de la table, qui peut non seulement prendre un temps très long, mais produire de nombreuses lignes erronées.
--fast, -F Ne vérifie que les tables qui n'ont pas été correctement fermées.
--force, -f Continue même si on rencontre une erreur SQL.
--host=host_name, -h host_name Connexion à l'hôte.
--medium-check, -m Plus rapide que la vérification complète, mais ne trouvera que 99.99 % de toutes les erreurs. Cela devrait être la bonne option pour la plupart des situations.
--optimize, -o Optimise la table.
--password[=password], -p[password] Le mot de passe à utiliser lors de la connexion au serveur. Si aucun mot de passe n'est fourni, il sera demandé en ligne de commande. Il ne faut pas laisser d'espace entre l'option -p et le mot de passe.
--port=port_num, -P port_num Le numéro de port de la connexion.
--protocol=TCP | SOCKET | PIPE | MEMORY Pour spécifier le protocole à utiliser pour la connexion.
--quick, -q Si vous utilisez cette option avec CHECK TABLE, elle va éviter que l'analyse ne traite toutes les lignes pour vérifier les mauvais liens. C'est la méthode d'analyse la plus rapide. Si vous utilisez cette option avec REPAIR TABLE, elle va essayer de ne réparer que le fichier d'index. C'est la méthode la plus rapide pour la réparation.
--repair, -r Peut corriger presque tout, sauf les problèmes de doublons pour les clés uniques.
--silent, -s Affiche moins de messages d'erreurs.
--socket=path, -S path Nom du fichier de socket à utiliser pour la connexion.
--tables Remplace l'option --databases ou -B. Tous les arguments suivants sont considérés comme des noms de tables.
--user=user_name, -u user_name Nom d'utilisateur pour la connexion, si ce n'est pas l'utilisateur courant.
--verbose, -v Affiche des informations sur les différentes étapes.
--version, -V Affiche les informations de version, et termine
^
04 mai 2010

htmlpdflatexmanmd




mysqld

mysqld, mysqld-max, mysqld-safe, mysql.server, mysqld_multi

Serveur de base de donnée mysql

mysqld est le serveur MySQL
mysqld-max version du serveur qui inclut des fonctionnalités supplémentaires
mysqld-safe est un script de démarrage du serveur. Tente de démarrer mysqld-max s'il existe sinon mysqld.
mysql.server est un script de démarrage du serveur, utilisé sur les systèmes qui ont un dossier contenant des services système. Il invoque mysqld-safe pour démarrer le serveur.
mysqld_multi est un script de démarrage qui peut lancer ou arrêter différentes instances du serveur, installées sur le système.

mysqld-max est une version mysqld compilée avec des fonctionnalités supplémentaires.
MySQL AB compile le serveur SQL avec les options suivantes :

        --with-server-suffix=-max ajoute le suffixe -max à la chaîne de version mysqld
        --with-innodb active le support du moteur InnoDB.
        --with-bdb active le support du moteur de table Berkeley DB

   Pour connaître les moteurs de stockage que votre serveur supporte, utiliser la commande SHOW ENGINES; safe_mysqld est la méthode recommandée pour démarrer un démon mysqld. Il ajoute des fonctionnalités de sécurité telles que le redémarrage automatique lorsqu'une erreur survient et l'enregistrement d'informations d'exécution dans un fichier de log. Par défaut il essaie de lancer mysqld-max s'il existe. Pour remplacer le comportement par défaut et spécifier explicitement le serveur à utiliser, spécifier --mysqld ou --mysqld-version.

Options identique de mysql_safe et mysqld

--basedir=path Le chemin jusqu'à l'installation de MySQL.
--core-file-size=# Taille du fichier core que mysqld doit être capable de créer. Il est passé à ulimit -c.
--datadir=path Le chemin jusqu'au dossier de données.
--defaults-extra-file=path Le nom du fichier d'options à lire en plus des fichiers habituels.
--defaults-file=path Le nom d'un fichier d'options qui doit être lu à la place du fichier d'options habituel.
--err-log=path L'ancienne option --log-error, à utiliser avant MySQL 4.0.
--ledir=path Le chemin jusqu'au dossier contenant le dossier mysqld. Utilisez cette option pour indiquer explicitement le lieu du serveur.
--log-error=path Écrit le fichier d'erreurs dans le fichier
--mysqld=prog_name Le nom du programme serveur (dans le dossier ledir) que vous voulez lancer. Cette option est nécessaire si vous utilisez une distribution binaire MySQL, mais que les données sont hors du dossier d'installation.
--mysqld-version=suffix Cette option est similaire à l'option --mysqld, mais vous spécifiez uniquement le suffixe du nom du programme. Le nom de base sera alors mysqld. Par exemple, si vous utilisez --mysqld-version=max, mysqld_safe va lancer le programme mysqld-max dans le dossier ledir. Si l'argument de --mysqld-version est vide, mysqld_safe utilise mysqld dans le dossier ledir.
--nice=priority Utilise le programme nice pour donner la priorité du serveur.
--no-defaults Ne lit aucun fichier d'options.
--open-files-limit=count Le nombre de fichiers que mysqld ouvre au maximum. La valeur de l'option est passée à ulimit -n. Notez que vous devez lancer mysqld_safe en tant que root pour que cela fonctionne correctement.
--pid-file=path Le chemin jusqu'au fichier d'identifiant de processus.
--port=port_num Le numéro de port à utiliser pour attendre les connexion TCP/IP.
--socket=path Le fichier de socket Unix pour les connexions locales.
--timezone=zone Configure la variable d'environnement TZ. Consultez votre documentation système pour connaître le format légal des fuseaux horaires.
--user=user_name | user_id Lance le serveur mysqld sous le nom d'utilisateur user_name ou avec l'utilisateur d'identifiant numérique ID user_id. (``Utilisateur'' dans ce contexte représente le compte système, et non pas les utilisateurs des tables de droits MySQL).

   mysql.server est utilisé pour arrêter les services. Il lit les options dans les sections [mysql.server], [mysqld] et [mysql_server]

  mysqld_multi est un programme pour gérer plusieurs serveurs MySQL qui utilisent différents sockets Unix et ports TCP.

  

Options de mylsql_multi

--config-file=name Un fichier de configuration alternatif. Note : cela ne va pas modifier les options de ce programme ([mysqld_multi]), mais uniquement les groupes [mysqld#]. Sans cette option, tout sera lu dans le fichier d'options traditionnel my.cnf. Cette option n'affecte pas la façon avec laquelle mysqld_multi lit ses options, qui sont toujours prises dans le groupe [mysqld_multi] du fichier my.cnf habituel.
--example Affiche un exemple de fichier de configuration.
--help Affiche l'aide et quitte.
--log=name Fichier de log. Le chemin complet et le nom du fichier sont nécessaires.
--mysqladmin=prog_name L'exécutable mysqladmin à utiliser lors de l'arrêt du serveur.
--mysqld=prog_name L'exécutable mysqld à utiliser. Notez que vous pouvez donner cette option à safe_mysqld. Ces options sont passées à mysqld. Assurez-vous que vous avez bien mysqld dans votre variable d'environnement PATH ou corrigez safe_mysqld.
--no-log Affiche les données d'historique à l'écran plutôt que dans le fichier de log. Par défaut, le fichier de log est activé.
--password=password Le mot de passe de l'utilisateur mysqladmin.
--tcp-ip Connexion au serveur MySQL via le port TCP/IP au lieu de la socket Unix. Cela affecte l'arrêt et le rapport. Si le fichier de socket manque, le serveur peut continuer de tourner, mais il n'est plus accessible que par port TCP/IP. Par défaut, les connexions sont faites avec les sockets Unix.
--user=user_name L'utilisateur MySQL pour mysqladmin.
--version Affiche le numéro de version et quitte.

Options de ligne de commande de mysqld

   mysqld lit les options des groupes mysqld et server. Un serveur MySQL intégré lit les options des groupes server, embedded et xxxxx_SERVER, où xxxxx est le nom de l'application. Pour voir la liste complète des options de mysqld: mysqld --verbose --help

--allow-suspicious-udfs contrôle le fait que les options utilisateurs qui disposent d'un seul symbole puisse être chargé. Désactivé par défaut.
--ansi utilise la syntaxe ANSI SQL. Pour un contrôle plus précis utiliser l'option --sql-mode
--basedir=path, --b path chemin jusqu'au dossier d'installation
--big-tables autorise la sauvegarde de grands résultats dans des fichiers temporaires. Résout le problème des erreur "table full", mais ralentit les requêtes alors que des tables en mémoire suffirait.
--bind-address=IP l'adresse IP à utiliser
--console écrit les messages d'erreurs sur la sortie standard, même si --log-error est spécifié
--character-sets-dir=path dossier contenant les jeux de caractères
--chroot=path met le démon mysqld en environnement chroot au démarrage
--core-file Écrit le fichier core lorsque mysqld s'arrête inopinément. Pour certains fichier vous devez spécifier aussi --core-file-size à safe_mysqld
--datadir=path, -h path chemin jusqu'au dossier des données
--debug[=debug_options], -# [debug_options] si MySQL est configuré avec --with-debug permet d'obtenir un fichier de trace.
--default-character-set=character spécifie le jeu de caractères par défaut
--default-collation=collation spécifie la collation par défaut.
--default-storage-engine=type synonyme de --default-table-type
--default-table-type=type spécifie le type de table par défaut
--delay-key=write[= OFF | ON | ALL ] spécifie comment l'option DELAYED KEYS doit être utilisé.
--des-key-file=file_name lit les clés par défaut utilisés par DES_ENCRYPT() et DES_DECRYPT()
--exit-info, -T Cette option est la combinaison d'options que vous pouvez utiliser pour le débogage du serveur mysqld.
--external-locking Active le verrouillage système. Notez que si vous utilisez cette option sur un système pour qui lockd ne fonctionne pas (comme Linux), vous allez bloquer rapidement mysqld avec les verrous. Anciennement appelée --enable-locking.
--flush Écrit toutes les données sur le disque après chaque requête SQL. Normalement, MySQL fait des écritures sur le disque après chaque requête, et laisse le système d'exploitation assurer la synchronisation avec le disque.
--init-file=file Lit les commandes SQL dans ce fichier au démarrage. Chaque commande doit être sur une ligne, et ne pas utiliser de commentaires.
--language=lang_name, -L lang_name Spécifie la langue utilisée pour les messages d'erreur du client. Le chemin complet doit être utilisé.
--log[=file], -l [file] Enregistre les connexions et les requêtes dans ce fichier. Si vous ne le faites pas, MySQL va utiliser host_name.log comme nom de fichier.
--log-bin=[file] Enregistre toutes les requêtes qui modifient des données dans un log. Ce log est utilisé pour la sauvegarde et la réplication. Si vous ne le faites pas, MySQL va utiliser host_name-bin comme nom de fichier.
--log-bin-index[=file] Fichier d'index pour les noms de fichiers de log binaire. Si vous ne le faites pas, MySQL va utiliser host_name-bin.index comme nom de fichier.
--log-error[=file] Enregistre les messages d'erreurs et les messages de démarrage dans ce fichier Si vous ne le faites pas, MySQL va utiliser host_name.err comme nom de fichier.
--log-isam[=file] Enregistre toutes les modifications des tables ISAM/MyISAM dans ce fichier (uniquement nécessaire pour déboguer ISAM/MyISAM).
--log-long-format Enregistre des informations supplémentaires dans les fichiers de log (log de modifications, log binaire de modifications, log de requêtes lentes, n'importe quel log en fait). Par exemple, le nom d'utilisateur et un timestamp sont enregistrés avec la requête. Si vous utilisez --log-slow-queries et --log-long-format, alors les requêtes qui n'utilisent pas d'index seront aussi enregistrées. Notez que --log-long-format est obsolète depuis la version 4.1, où --log-short-format a été introduite (le format de log long est la configuration par défaut en version 4.1). Notez aussi que depuis la version MySQL 4.1 l'option --log-queries-not-using-indexes est disponible pour enregistrer spécifiquement les requête qui n'utilisent pas d'index, dans le log de requêtes lentes.
--log-queries-not-using-indexes Si vous utilisez cette option avec --log-slow-queries, alors les requêtes qui n'utilisent pas d'index seront aussi enregistrées dans le log de requêtes lentes.
--log-short-format Enregistre moins d'information dans les fichiers de log (log de modifications, log binaire de modifications, log de requêtes lentes, n'importe quel log en fait). Par exemple, les noms d'utilisateur et un timestamp ne seront pas enregistrés avec les requêtes.
--log-slow-queries[=file] Enregistre toutes les requêtes qui prennent plus de long_query_time secondes a s'exécuter.
--log-warnings, -W Affiche les alertes comme Aborted connection... dans le fichier d'erreur .err. Activer cette option est recommandé, par exemple, si vous utilisez la réplication : vous obtiendrez plus d'informations sur ce qui se passe, comme les erreurs de connexion réseau, ou les reconnexions.
--low-priority-updates Les opérations de modifications de table (INSERT/DELETE/UPDATE) auront une priorité inférieure aux sélections. Cela peut être aussi fait via l'attribut INSERT | REPLACE | UPDATE | DELETE LOW_PRIORITY ... pour baisser la priorité d'une requête, ou avec SET LOW_PRIORITY_UPDATES=1 pour changer la priorité dans plus d'un thread
--memlock Verrouille le processus mysqld en mémoire. Cela fonctionne si votre système support la fonction mlockall() (comme Solaris). Ceci peut être utile si vous avez des problèmes avec le système d'exploitation qui force mysqld à utiliser le swap sur le disque.
--myisam-recover [=option[,option...]]] Cette option est la combinaison de DEFAULT, BACKUP, FORCE et QUICK. Vous pouvez aussi lui donner la valeur explicite de "" si vous voulez désactiver cette option. Si cette option est utilisée, mysqld va vérifier si la table est marquée comme corrompue à l'ouverture de chaque table (cette dernière option ne fonctionne que si vous utilisez l'option --skip-external-locking). Si c'est le cas, mysqld va essayer de vérifier la table. Si la table était corrompue, mysqld essaie alors de la réparer.
--pid-file=path Le chemin jusqu'au fichier de PID utilisé par safe_mysqld.
--port=port_num, -P port_num Numéro de port utilisé pour attendre les connexion TCP/IP.
--old-protocol, -o Utilise le protocole 3.20, pour la compatibilité avec de très vieux clients.
--one-thread Utilise uniquement un thread (pour débogage sous Linux). Cette option est disponible uniquement si le serveur est compilé avec les options de débogage.
--open-files-limit=count Pour changer le nombre de pointeurs de fichiers disponibles pour mysqld. Si cette option n'est pas configurée, ou qu'elle vaut 0, alors mysqld va utiliser cette valeur pour réserver ce nombre de pointeurs de fichiers, à utiliser avec setrlimit(). Si la valeur est 0 alors mysqld va réserver max_connections*5 ou max_connections + table_cache*2 (le plus grand des deux) pointeurs de fichiers. Il est recommandé d'augmenter cette valeur si mysqld émet des erreurs de type 'Too many open files'.
--safe-mode Ignore certains étapes d'optimisation.
--safe-user-create Si cette option est activée, un utilisateur ne peut pas créer de nouveaux utilisateurs avec la commande GRANT si l'utilisateur n'a pas les droits de INSERT dans la table mysql.user ou dans aucune colonne de cette table.
--secure-auth Interdit l'identification des comptes qui ont des mots de passe ancien (avant la version 4.1).
--skip-bdb Désactive l'utilisation des tables BDB. Cela va économiser de la mémoire et accélérer le serveur un peu. N'utilisez pas cette option si vous avez besoin des tables BDB.
--skip-concurrent-insert Désactive la possibilité de sélectionner et insérer en même temps dans les tables MyISAM (cela n'est utile que si vous pensez que vous avez trouvé un bug dans cette fonctionnalité).
--skip-external-locking Ne pas utiliser le verrouillage du système. Pour utiliser les utilitaires isamchk ou myisamchk vous devez alors éteindre le système.
--skip-grant-tables Cette option force le serveur à ne pas utiliser le système de privilège du tout. Cela donne à tous l'accès complet à toutes les bases de données ! Vous pouvez demander à un serveur en exécution d'utiliser à nouveau les tables de droits en exécutant la commande mysqladmin flush-privileges ou mysqladmin reload).
--skip-host-cache Ne pas utiliser le cache de nom de domaine pour une résolution des IP plus rapide, mais interroger le serveur DNS à chaque connexion.
--skip-innodb Désactive l'utilisation des tables InnoDB. Cela va économiser de la mémoire et accélérer le serveur un peu. N'utilisez pas cette option si vous avez besoin des tables InnoDB.
--skip-isam Désactive l'utilisation des tables ISAM. Cela va économiser de la mémoire et accélérer le serveur un peu.
--skip-name-resolve Les noms d'hôtes ne sont pas résolus. Toutes les colonnes Host dans vos tables de droits doivent être des IP numériques ou le mot localhost
--skip-networking Ne pas attendre les connexions TCP/IP du tout. Toutes les interactions du serveur mysqld seront faites avec les sockets Unix. Cette option est particulièrement recommandée pour les systèmes qui utilisent des requêtes locales.
--skip-new Ne pas utiliser les nouvelles routines qui sont possiblement erronées.
--symbolic-links, --skip-symbolic-links Active ou désactive le support des liens symboliques. signifie que vous pouvez mettre un fichier d'index MyISAM ou un autre fichier de données dans un autre dossier, avec les options INDEX DIRECTORY ou DATA DIRECTORY de la commande CREATE TABLE. Si vous effacer ou renommez la table, les fichiers qui sont des liens symboliques seront aussi effacés ou renommés.
--skip-show-database Si MySQL est configuré avec --with-debug=full, tous les programmes vérifieront la mémoire pour rechercher les écrasements de zone lors des allocations et libérations de mémoire. Comme ce test est lent, vous pouvez l'éviter, si vous n'avez pas besoin de tester la mémoire, en utilisant cette option.
--skip-stack-trace Ne pas écrire les piles de traces. Cette option est pratique lorsque vous utilisez mysqld avec un débogueur. Sur certains systèmes, vous devez aussi utiliser cette option pour obtenir un fichier de core.
--skip-thread-priority Désactive les priorités des threads pour améliorer la vitesse de réponse.
--socket=path Sous Unix, le fichier de socket pour les connexions locales. (par défaut, /tmp/mysql.sock).
--sql-mode=value[,value[,value...]] Spécifie le mode SQL.
--temp-pool En utilisant cette option, vous allez réduire le jeu de noms qui sont utilisés lors de la création de fichier temporaires, plutôt qu'un nom unique à chaque fois. Ceci est un palliatif au noyau Linux qui crée plusieurs fichiers nouveaux avec des noms différents. Avec l'ancien comportement, Linux semble "perdre de la mémoire", car ils sont alloués au cache d'entrées du dossier au lieu de celui du disque.
--transaction-isolation=level Configure le niveau d'isolation des transactions. Le niveau peut être READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ ou SERIALIZABLE
--tmpdir=path, -t path Chemin vers les fichiers temporaires. Il peut s'avérer pratique si votre dossier par défaut /tmp réside dans une partition qui est trop petite pour absorber les tables temporaires. cette option accepte différents chemins, qui sont utilisés en alternance. Les chemins doivent être séparés par des deux points (‘ :’) sous Unix. Il est possible de dire à tmpdir de pointer sur un système de fichiers en mémoire, hormis si le serveur MySQL est un esclave. Si c'est un esclave, il faut un système de fichiers permanents (pour que la réplication des tables temporaires et des commandes LOAD DATA INFILE) survive a un redémarrage de la machine : un système de fichiers en mémoire tmpdir, qui est effacé au lancement de la machine n'est pas acceptable. Un disque est nécessaire pour tmpdir, dans ce contexte.
--user=user_name | user_id, -u user_name | user_id Éxécute le démon mysqld avec l'utilisateur user_name ou userid (numérique). (``utilisateur'' dans ce contexte fait référence à l'utilisateur du système d'exploitation, mais pas l'utilisateur MySQL, listé dans les tables de droits.) Cette option est obligatoire lorsque vous démarrez mysqld en tant que root. Le serveur va changer d'ID durant le lancement du serveur, pour utiliser un autre utilisateur que root.
--version, -V Affiche les informations de version.

   Pour éviter des trous de sécurité si un utilisateur ajoute --user=root dans un fichier my.cnf (et donc, faisant que le serveur fonctionne en tant que utilisateur système root), mysqld utilise uniquement la première option --user spécifiée, et produit une alerte s'il rencontre d'autres options --user. Les options des fichiers /etc/my.cnf et datadir/my.cnf sont traités avant les options de ligne de commande, et il est recommandé que vous ajoutiez l'option --user dans le fichier /etc/my.cnf puis spécifiez une valeur autre que root. L'option de /etc/my.cnf peut être placée avant toute autre option --user, ce qui assure que le serveur fonctionnera avec l'utilisateur autre que root, et qu'une alerte apparaîtra si une autre option --user est découverte.
^
08 mai 2010

htmlpdflatexmanmd




mysqldump

mysqldump

Utilitaire de sauvegarde des structures de tables de données

Plusieurs méthodes
shell› mysqldump [options] db_name [tables]
shell› mysqldump [options] --databases DB1 [DB2 DB3...]
shell› mysqldump [options] --all-databases

OPTIONS

--help, -? Affiche le message d'aide et quitte.
--add-drop-table Ajoute une commande drop table avant chaque requête de création de table.
--add-locks Ajoute une commande LOCK TABLES avant l'export de table et une commande UNLOCK TABLE après (Pour accélérer les insertions dans MySQL).
--all-databases, -A Exporte toutes les tables. C'est l'équivalent de l'option --databases avec toutes les bases de données sélectionnées.
--allow-keywords Permet la création de colonnes ayant des noms de mots réservés. Cela fonctionne en préfixant chaque nom de colonne avec le nom de la table.
--comments[=0|1] Si cette option prend 0, elle supprime les informations additionnelles (comme les versions de programme, les versions d'hôte) dans les exports. L'option --skip-comments fait la même chose. Par défaut, la valeur de cette option est 1, pour conserver ces informations.
--compatible=name Produit un résultat qui est compatible avec les autres bases de données, ou avec d'anciennes versions de MySQL. Les valeurs possibles de name sont mysql323, mysql40, postgresql, oracle, mssql, db2, sapdb, no_key_options, no_table_options, ou no_field_options. Pour utiliser plusieurs valeurs, séparez les par des virgules. Ces valeurs ont la même signification que les options correspondantes de configuration du mode SQL.
--complete-insert, -c Utilise des commandes INSERT complètes, avec les noms de colonnes.
-C, --compress Compresse toutes les informations entre le client et le serveur, les deux supporte la compression.
--create-options Inclut toutes les options spécifiques MySQL de création de table dans les commandes CREATE TABLE.
--databases, -B Pour exporter plusieurs bases de données. Notez la différence d'utilisation. Dans ce cas, aucune table n'est spécifié. Tous les arguments de noms sont considérés comme des noms de base. Une ligne USE db_name; sera ajoutée dans l'export avant chaque base de données.
--debug[=debug_options], -# [debug_options] Active l'historique de débogage. La chaîne de format est généralement 'd:t:o,file_name'.
--default-character-set=charset Configure le jeu de caractères par défaut pour l'export. S'il n'est pas spécifié, mysqldump 10.3 ou plus récent va utiliser utf8. Les versions plus anciennes utiliseront latin1.
--delayed Les insertions se font avec la commande INSERT DELAYED.
--delete-master-logs Sur un maître de réplication, efface le log binaire une fois que l'opération d'export est faite. Cette option active automatiquement --first-slave.
--disable-keys, -K Pour chaque table, entoure les commandes d'INSERT avec les commandes /* !40000 ALTER TABLE tbl_name DISABLE KEYS */; et /* !40000 ALTER TABLE tbl_name ENABLE KEYS */;. Cette option n'est effective que pour les tables MyISAM.
--extended-insert, -e Utilise la nouvelle syntaxe multi-ligne INSERT. (Cela donne des insertions plus courtes et plus efficaces).
--fields-terminated-by=..., --fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --fields-escaped-by=..., --lines-terminated-by=... Ces options sont utilisées avec l'option -T et ont la même signification que les clauses correspondantes de la commande LOAD DATA INFILE.
--first-slave, -x Verrouille toutes les tables de toutes les bases de données.
--flush-logs, -F Écrit tout le fichier de log du serveur avant de commencer l'export. Notez que si vous utilisez cette option avec --all-databases (ou l'option -A), les logs seront vidés pour chaque base de données exportée.
-f, --force Continue même si une erreur SQL survient durant l'export.
--host=host_name, -h host_name Exporte les données depuis le serveur MySQL vers l'hôte indiqué. L'hôte par défaut est localhost.
--lock-tables, -l Verrouille toutes les tables avant de commencer l'export. Les tables sont verrouillées avec READ LOCAL pour permettre des insertions concurrentes sur les tables MyISAM. Notez que lorsque vous exportez des tables de bases différentes, l'option --lock-tables va verrouiller chaque base séparément. Cette option ne vous garantira pas que vos tables seront logiquement cohérente entre les bases. Des tables de différentes bases pourraient être exportées dans des états très différents.
--master-data Cette option est similaire à --first-slave, mais produit aussi une commande CHANGE MASTER TO qui fait que le serveur esclave va commencer à la bonne position dans le log du maître, si vous utilisez cette exportation pour configurer initialement l'esclave.
--no-create-db, -n CREATE DATABASE la ligne /* !32312 IF NOT EXISTS*/ db_name; ne sera pas ajouté dans l'export. Sinon, la ligne ci-dessus sera ajoutée, si l'une des options --databases ou --all-databases a été activée.
--no-create-info, -t N'écrit pas les informations de création de table (la requête CREATE TABLE).
--no-data, -d N'écrit aucune ligne d'informations sur la table. C'est très pratique si vous voulez simplement exporter la structure de la table.
--opt Identique à --quick --add-drop-table --add-locks --extended-insert --lock-tables. Vous obtiendrez l'export le plus rapide à importer dans un serveur MySQL.
--password[=password], -p[password] Le mot de passe à utiliser lors de la connexion au serveur.
--port=port_num, -P port_num Le port TCP/IP à utiliser avec l'hôte.
--protocol=TCP | SOCKET | PIPE | MEMORY Pour spécifier le protocole de connexion à utiliser.
--quick, -q Ne garde pas en buffer les requêtes, mais écrit immédiatement dans la sortie.
--quote-names, -Q Protège les noms des tables et colonnes avec le caractère ‘`’.
--result-file=file, -r file Écrit directement dans le fichier indiqué. Cette option doit être utilisé sur MSDOS, car cela évite que la nouvelle ligne ‘\n’ soient converties en ‘\n\r’ (nouvelle ligne et retour chariot).
--single-transaction Cette option ajoute la commande SQL BEGIN avant d'exporter les données vers le serveur. C'est généralement pratique pour les tables InnoDB et le niveau d'isolation de transaction READ_COMMITTED, car ce mode va exporter l'état de la base au moment de la commande BEGIN sans bloquer les autres applications. Lorsque vous utilisez cette option, pensez bien que seules les tables transactionnelles seront exportées dans un état cohérent, c'est à dire que les tables MyISAM ou HEAP qui seront exportées avec cette option, pourront changer d'état. Cette option est mutuellement exclusive avec l'option --lock-tables car LOCK TABLES va valider une transaction interne précédente.
--socket=path, -S path Le fichier de socket à utiliser pour les connexions locale (à localhost), qui est l'hôte par défaut.
--skip-comments Identique à --comments = 0.
--tab=path, -T path Crée un fichier table_name.sql, qui contient les commandes SQL CREATE, et un fichier table_name.txt, qui contient les données, pour chaque table. Le format du fichier .txt est celui qui est spécifié par les options --fields-xxx et --lines--xxx. Note : cette option ne fonctionne qui si mysqldump est exécuté sur la même machine que le démon mysqld, et que le nom d'utilisateur et le groupe de mysqld (normalement l'utilisateur mysql, et le groupe mysql) doivent avoir des permission pour créer et écrire un fichier dans le dossier que vous spécifiez.
--tables Remplace l'option --databases ou -B. Tous les arguments suivant les options sont considérés comme des noms de tables.
--user=user_name, -u user_name Le nom d'utilisateur MySQL lors de la connexion à un serveur distant.
--verbose, -v Mode détaillé. Affiche plus d'informations sur les faits et gestes du programme.
--version, -V Affiche la version du programme et quitte.
--where='where-condition', -w 'where-condition' Exporte uniquement les lignes sélectionnées. Notez que les guillemets sont obligatoires. Exemples : "--where=user='jimf'" "-wuserid؏" "-wuseridկ"
-X, --xml Exporte la base au format XML

Exemples

L'usage normal de mysqldump est probablement de faire des sauvegardes de bases
mysqldump --opt database › backup-file.sql
Vous pouvez importer les données dans la base MySQL avec
mysql database ‹ backup-file.sql
ou
mysql -e "source /patch-to-backup/backup-file.sql" database
Cependant, il est très pratique pour remplir un autre serveur MySQL avec des informations depuis une base
mysqldump --opt database | mysql ---host=remote-host -C database
Il est possible d'exporter plusieurs bases de données en une seule commande
mysqldump --databases database1 [database2 ...] › my_databases.sql
Si vous souhaitez exporter toutes les bases, vous pouvez utiliser
mysqldump --all-databases › all_databases.sql
^
08 mai 2010

htmlpdflatexmanmd




mysqlhotcopy

mysqlhotcopy

Sauvegarde rapide des bases de données

shell› mysqlhotcopy db_name [/path/to/new_directory]
shell› mysqlhotcopy db_name_1 ... db_name_n /path/to/new_directory
shell› mysqlhotcopy db_name./regex/

OPTIONS

--allowold Ne pas annuler si la sauvegarde existe déjà (renomme simplement en _old)
--checkpoint=db_name.tbl_name Insère un point de contrôle dans la table spécifiée (base.table)
--debug Active le débogage.
--dryrun, -n Rapporte les actions réalisées sans les faire.
--flushlog Vide les logs sur le disque une fois que toutes les tables sont verrouillées.
--keepold Ne pas effacer une sauvegarde précédente (celle qui a été renommée) lorsque c'est terminé.
--method=# Méthode de copie (cp ou scp).
--noindices Ne pas inclure les fichiers d'index complet dans la copie, pour faire des fichiers de sauvegarde plus petit et plus rapide. Les index peuvent toujours être reconstruits plus tard avec myisamchk -rq..
-p, --password=# Mot de passe utilisé pour la connexion au serveur.
--port=port_num, -P port_num Port utilisé pour la connexion au serveur.
--quiet, -q Mode silencieux. N'affiche que les erreurs.
--regexp=expr Copie toutes les bases dont le nom vérifie un masque d'expression régulière.
--socket=path, -S path Socket utilisée pour la connexion au serveur.
--suffix=str Suffixe des noms des bases copiées.
--tmpdir=path Dossier temporaire (au lieu de /tmp).
--user=user_name, -u user_name Nom d'utilisateur pour la connexion au serveur
^
08 mai 2010

htmlpdflatexmanmd




mysqlimport

mysqlimport

Utilitaire pour LOAD DATA INFILE

   La plupart des options correspondent.

  shell› mysqlimport [options] database textfile1 [textfile2 ...]

  mysqlimport utilise de nom des fichiers sans les extensions pour nommer les tables.

OPTIONS

--columns=column_list, -c column_list Cette option prend une liste de noms de colonnes, séparés par des virgules. Ce champs est utilisé pour créer une commande LOAD DATA INFILE correcte, qui sera alors passée à MySQL.
--compress, -C Compresse toutes les informations entre le client et le serveur, si c'est possible.
--debug[=debug_options], -# [debug_options] Active le débogage. la valeur de debug_options est souvent: 'd:t:o,file_name'.
--delete, -D Vide la table avant d'importer le fichier texte.
--fields-terminated-by=..., --fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --fields-escaped-by=..., --lines-terminated-by=... Ces options ont la même signification que les clauses correspondantes de LOAD DATA INFILE.
--force, -f Ignore les erreurs. Par exemple, si une table n'existe pas pour un fichier texte, mysqlimport va continuer de traiter les autres fichiers. Sans --force, mysqlimport se termine dès qu'une erreur survient.
--host=host_name, -h host_name Importe les données sur le serveur MySQL, avec l'hôte spécifié. La valeur par défaut est localhost.
--ignore, -i Voir la description de --replace.
--ignore-lines=n Ignore les n premières lignes du fichier de données.
--local, -L Lit le fichier d'entrée dans le client. Par défaut, les fichiers textes sont supposés être lus par le serveur, si vous vous connectez à localhost (qui est l'hôte par défaut).
--lock-tables, -l Verrouille toutes les tables en écriture avant de ne traiter les fichiers textes. Cela assure que toutes les tables sont synchronisée sur le serveur.
--password[=password], -p[password] Le mot de passe à utiliser lors de la connexion au serveur. Notez que si vous utilisez l'option courte (-p), vous ne pouvez pas laisser d'espace entre l'option est le mot de passe. Si vous ne spécifiez pas le mot de passe avec l'option, mysqlimport va vous demander le mot de passe en ligne.
--port=port_num, -P port_num Le port TCP/IP utilisé avec l'hôte. Cela sert pour les connexions à des hôtes qui ne sont pas localhost, pour lequel la socket Unix est utilisée.
--protocol=TCP | SOCKET | PIPE | MEMORY Spécifie le protocole à utiliser pour se connecter.
--replace, -r Les options --replace et --ignore contrôlent la gestion des lignes lues envers les lignes qui existent déjà sur le serveur. Si vous spécifiez l'option --replace, les nouvelles lignes remplaceront les lignes existantes. Si vous spécifiez --ignore, les lignes qui sont en double dans une table qui dispose d'une colonne de type unique sont ignorés. Si vous ne spécifiez pas ces options, une erreur surviendra lorsqu'une clé en double sera trouvée, et la lecture du reste du fichier sera annulé.
--silent, -s Mode silencieux. N'affiche que les erreurs qui surviennent.
--socket=path, -S path Le fichier de socket à utiliser lors de la connexion à localhost (qui est l'hôte par défaut).
--user=user_name, -u user_name Le nom de l'utilisateur MySQL à utiliser lors de la connexion au serveur MySQL. La valeur par défaut est celui de votre utilisateur Unix.
--verbose, -v Mode détaillé. Affiche bien plus d'informations sur les actions du programme.
^
08 mai 2010

htmlpdflatexmanmd




mysqlshow

mysqlshow

Informations sur les bases, tables et colonnes

   mysqlshow fournis une interface pour de nombreuses déclarations SQL SHOW. Si le dernier argument contient des caractères *, ?, %, ou _, seul les noms qui match seront affichés.

OPTIONS

--bind-address=ip_address Permet de spécifier l'interface utilisé pour se connecter au serveur
--character-sets-dir=path dossier contenant les jeux de caractères
--compress, -C Compresse toutes les informations entre le client et le serveur, si c'est possible.
--count Affiche le nombre de lignes par table.
--debug[=debug_options], -# [debug_options] Écrit un log. une chaîne debug_options est généralement 'd:t:o,file_name'. Défaut: 'd:t:o'
--debug-check Affiche des informations de débuggage quand le programme se termine.
--debug-info Affiche des informations de mémoire et CPU quand le programme se termine.
--default-character-set=charset_name Utilise le jeu de caractère spécifié
--default-auth=plugin Plugin d'authentification côté client à utiliser
--host=host_name, -h host_name Nom du serveur MySQL à utiliser
--keys, -k Affiche les index de table
--password[=password], -p[password] Le mot de passe à utiliser lors de la connexion au serveur.
--plugin-dir=path Le répertoire où rechercher les plugins.
--port=port_num, -P port_num Le numéro de port TCP/IP pour la connexion.
--protocol={TCP|SOCKET|PIPE|MEMORY} Protocol de connexion à utiliser pour se connecter au serveur
--show-table-type, -t Affiche une colonne indiquant le type de table, comme dans SHOW FULL TABLES. le type est BASE TABLE ou VIEW
--socket=path, -S path Socket utilisée pour la connexion au serveur.
--ssl* Les options qui commencent par --ssl spécifient les paramètres de connexion en utilisant SSL
--status, -i Affiche des informations supplémentaire sur chaque table.
--user=user_name, -u user_name Nom d'utilisateur pour la connexion au serveur
--verbose, -v Mode détaillé. Affiche plus d'informations sur les faits et gestes du programme.
^
04 mai 2010

htmlpdflatexmanmd




MySQL - Moteurs de table

MySQL - Moteurs de table

Moteur de table et types de table

On peut créer une table en spécifiant la clause ENGINE ou TYPE:
CREATE TABLE t (i INT) ENGINE = INNODB ;
CREATE TABLE t (i INT) TYPE = MEMORY ;
si on omet cette clause, le moteur par défaut est utilisé, spécifié par la variable système table_type. Pour convertir une table d'un type à l'autre, utilisez la commande ALTER TABLE, pour indiquer le nouveau type:
ALTER TABLE t ENGINE = MYISAM ;
ALTER TABLE t TYPE = BDB ;

Moteur de table MyISAM

   Chaque table MyISAM est stockée en trois fichiers. Les fichiers portent le nom de la table, et ont une extension qui spécifie le type de fichier. Le fichier .frm stocke la définition de la table. L'index est stocké dans un fichier avec l'extension .MYI (MYIndex), et les données sont stockées dans un fichier avec l'extension .MYD (MYData).

- Toutes les clés numériques sont stockées avec l'octet de poids fort en premier, pour améliorer la compression.
- Support des grands fichiers
- Les lignes de taille dynamique sont bien moins fragmentées lors de l'utilisation d'insertion et d'effacement.
- Le nombre maximal d'index par table est de 64
- La taille maximale d'une clé est de 1000 octets
- Les colonnes BLOB et TEXT peuvent être indexées.
- Les valeurs NULL sont autorisées dans une colonne indexée. Elles prennent 0 à 1 octets par clé.
- Les fichiers d'index sont généralement plus petits en MyISAM qu'en ISAM.
- améliore l'utilisation d'espace dans l'arbre des clés.
- Vous pouvez placer les fichiers de données et d'index dans différents dossiers pour obtenir plus de vitesse avec les options de table DATA DIRECTORY et INDEX DIRECTORY, dans la commande CREATE TABLE.
- chaque colonne de caractères peut avoir un jeu de caractères distinct.
- Il y a un indicateur dans le fichier MyISAM qui indique si la table a été correctement fermée.
- myisampack peut compresser des colonnes BLOB et VARCHAR.
- Support du vrai type VARCHAR; une colonne VARCHAR commence avec une taille, stockée sur 2 octets.
- Les tables ayant des colonnes VARCHAR peuvent avoir un format de lignes fixe ou dynamique.
- VARCHAR et CHAR peuvent prendre jusqu'à 64 ko.
- Un index de hashage peut être utilisé avec UNIQUE. Cela vous permettra d'avoir un index UNIQUE sur toute combinaison de colonnes de la table. Vous ne pourrez pas utiliser un index UNIQUE pour une recherche.

   Les options suivantes de mysqld permettent de modifier le comportement des tables MyISAM:

--myisam-recover=mode Active le mode de restauration automatique des tables MyISAM corrompues.
--delay-key-write=ALL N'écrit pas les buffers de clés entre deux écritures dans une table MyISAM.

   Note: Si vous faîtes cela, vous ne devez pas utiliser les tables MyISAM avec d'autres programmes (comme depuis un autre serveur MySQL ou avec myisamchk) lorsque la table est utilisée. Sinon, vous allez obtenir une corruption d'index.

  Utiliser --external-locking n'aidera pas les tables qui utilisent --delay-key-write.

   Les variables systèmes suivantes affectent le comportement des tables MyISAM

bulk_insert_buffer_size La taille du cache d'index lors des insertions de masse. Note : c'est une limite par thread !
myisam_max_extra_sort_file_size Utilisée pour aider MySQL à décider quand utiliser le cache de clé lent mais sûr.
myisam_max_sort_file_size N'utilise pas la méthode de tri rapide pour créer un index, si un fichier temporaire dépasserait cette taille.
myisam_sort_buffer_size La taille du buffer lors de la restauration de table.

   La restauration automatique est activée si vous lancez mysqld avec l'option --myisam-recover. Dans ce cas, lorsque le serveur ouvre la table MyISAM, il vérifie si la table a été marquée comme crashée ou si le compteur de tables ouvertes n'est pas zéro ou si le serveur utilise --skip-external-locking. Si une des conditions précédente est vraie, il arrive ceci

- La table est analysée pour rechercher des erreurs.
- Si le serveur trouve une erreur, il essaie de faire une réparation rapide (avec le tri, sans recréer de données).
- Si la réparation échoue à cause d'une erreur dans le fichier de données (par exemple, une erreur de clé), le serveur essaie à nouveau, en re-créant le fichier de données.
- Si la réparation échoue encore, le serveur essaie encore avec une ancienne méthode réparation (écrire les lignes les unes après les autres, sans tri). Cette méthode devrait être capable de réparer tout les types d'erreurs, et elle occupe peu de place sur le disque.
- Si la restauration n'est toujours pas capable de retrouver toutes les lignes, et que vous n'avez pas spécifié l'option FORCE dans la valeur de l'option --myisam-recover, la réparation automatique s'annule, avec le message d'erreur suivant: Error : Couldn't repair table : test.g00pages
- Si vous spécifiez la valeur FORCE, une alerte comme celle-ci sera écrite dans les logs: Warning : Found 344 of 354 rows when repairing ./test/g00pages

   Notez que si la valeur de restauration automatique inclut BACKUP, le processus de restauration créera des fichiers avec des noms de la forme tbl_name-datetime.BAK. Vous devriez avoir une tâche régulière avec cron pour supprimer automatiquement ces fichiers dans les bases de données pour nettoyer le volume.

   Pour avoir une approximation de la taille du fichier d'index, faire la somme de (longueur_clef+4)/0.67 pour toutes les clefs. (c'est le pire des cas où les clefs sont insérées dans l'ordre et qu'aucune n'est compressée).

   MyISAM supporte 3 différents types de tables. Deux des trois sont choisis automatiquement selon le type de colonne que vous utilisez. Le troisième, tables compressées, ne peut être crée qu'avec l'outil myisampack. Quand vous créez une table avec CREATE ou en modifiez la structure avec ALTER vous pouvez, pour les tables n'ayant pas de champ BLOB forcer le type de table en DYNAMIC ou FIXED avec l'option ROW_FORMAT=# des tables. Bientôt, vous pourrez compresser/décompresser les tables en spécifiant ROW_FORMAT=compressed | default à ALTER TABLE.

   Tables statiques: Ceci est le format par défaut. Il est utilisé lorsque la table ne contient pas de colonnes de type VARCHAR, BLOB, ou TEXT. Ce format est le plus simple et le plus sûr. C'est aussi le format sur disque le plus rapide.

- Toutes les colonnes CHAR, NUMERIC, et DECIMAL sont complétées par des espaces jusqu'à atteindre la longueur totale de la colonne.
- Très rapide.
- Facile à mettre en cache.
- Facile à reconstruire après un crash, car les enregistrements sont localisés dans des positions fixées.
- N'a pas à être réorganisé (avec myisamchk) sauf si un grand nombre de lignes est effacé et que vous voulez retourner l'espace libéré au système d'exploitation.
- Requière généralement plus d'espace disque que les tables dynamiques.

   Tables à format de ligne dynamiques: Ce format est utilisé avec les tables qui contiennent des colonnes de type VARCHAR, BLOB ou TEXT, ou si la table a été créée avec l'option ROW_FORMAT=dynamic. Vous pouvez utiliser la commande SQL OPTIMIZE table ou Shell myisamchk pour défragmenter une table.

- Toutes les colonnes de type chaîne sont dynamiques (hormis celle qui sont de taille inférieure à 4).
- Chaque ligne est précédée d'un octet qui indique quelles sont les lignes vides ('', bit à 1) et celle qui le ne sont pas (bit à 0). Une colonne vide n'est pas la même choses qu'une colonne qui contient NULL. Si une colonne a une taille de zéro après avoir supprimé les espaces finaux, ou un nombre a une valeur de zéro, il est marqué dans cet octet, et la colonne sera ignorée sur le disque. Les chaînes non vides sont sauvées avec un octet de plus pour y stocker la taille.
- Ce format prend généralement moins de place que des tables à format fixe.
- Chaque ligne consomme autant d'espace que nécessaire. Si une ligne devient trop grande, elle sera coupée en blocs et écrites dans le fichier de données. Cela engendre la fragmentation du fichier de données. Dans ce cas, vous pouvez avoir à exécuter la commande myisamchk -r de temps en temps pour améliorer les performances. Utilisez myisamchk -ei tbl_name pour obtenir des statistiques.
- Ce format de table n'est pas toujours facile à reconstituer après un crash, car une ligne peut être fragmentée en de nombreux blocs, et un fragment peut manquer.

La taille d'une ligne de format variable se calcule avec
3
+ (nombre de colonnes + 7) / 8
+ (nombre de colonnes de tailles chars)
+ taille compactée des colonnes numériques
+ taille des chaînes
+ (nombre de colonne de valeur NULL + 7) / 8

- Il y a un aussi un supplément de 6 octets pour chaque lien. Une ligne de format dynamique utilise un lien à chaque fois qu'une modification cause un agrandissement de la ligne. Chaque nouveau bloc lié fait au moins 20 octets, pour que le prochain agrandissement utilise aussi ce bloc. Si ce n'est pas le cas, un nouveau bloc sera lié, avec un autre coût de 6 octets. Vous pouvez vérifier le nombre de liens dans une table avec la commande myisamchk -ed. Tous les liens sont supprimés avec la commande myisamchk -r.

   tables compressées: C'est un type en lecture seule qui est généré avec l'outil optionnel myisampack.

- Les tables compressées prennent très peu d'espace disque.
- Chaque ligne est compressée séparément (optimisation des accès). L'en-tête d'un enregistrement est fixé (1-3 octets) selon le plus grand enregistrement dans la table. Chaque colonne est compressée différemment. Quelques un des types de compressions sont:

        - Compression des espaces en suffixe.
        - Compression des espaces en préfixe.
        - Les nombres avec la valeur 0 sont stockés en utilisant 1 octet.
        - Si les valeurs dans une colonne de type entier ont un petit intervalle, la colonne est stockée en utilisant le type le plus petit possible.
        - Si une colonne n'a qu'un petit éventail de valeurs, son type est changé en ENUM.
        - Une colonne peut utiliser une combinaison des compressions précédentes.
        - Peut gérer les enregistrements de tailles fixes ou variables.

   Vous pouvez réparer une table corrompue avec REPAIR TABLE. Vous pouvez aussi réparer une table, lorsque mysqld ne fonctionne pas, avec la commande myisamchk

Tables assemblées MERGE

   Une table MERGE est un groupe de tables MyISAM identiques qui sont utilisées comme une seule. "Identique" signifie que toutes les tables ont la même structure de colonnes et d'index

Tables MEMORY (HEAP)

   Le moteur de stockage MEMORY crée des tables dont le contenu est stocké en mémoire.

- Vous pouvez avoir des clés non-uniques dans une table MEMORY. (C'est une fonctionnalité rare pour les index hash).
- Si vous avez un index hash sur une table HEAP avec un haut degré de duplication (de nombreux valeurs d'index contiennent la même valeur), les modifications dans cette table peuvent affecter les valeurs des clés et toutes les suppressions seront plus lentes. Le facteur de ralentissement est proportionnel au degré de duplication (ou inversement proportionnel à la cardinalité).
- Les tables HEAP utilisent un format de ligne fixe.
- HEAP ne supporte pas les colonnes de type BLOB/TEXT.
- HEAP ne supporte pas les colonnes de type AUTO_INCREMENT.
- Les tables HEAP sont partagées entre tous les clients (comme une autre table).
- La caractéristique des tables MEMORY qui fait que les tables sont stockées en mémoire est partagée avec les tables internes que le serveur crée à la volée lors du traitement des requêtes. Cependant, les tables internes ont aussi la capacité d'être converties en tables disques automatiquement, si elles deviennent trop grandes. La taille limite est déterminée par la valeur de tmp_table_size.

   Les tables MEMORY ne peuvent pas être converties en tables disques. Pour vous assurer que vous ne faîtes rien de dangereux pour le serveur, vous pouvez utiliser la variable système max_heap_table_size pour imposer une taille maximale aux tables MEMORY. Pour des tables individuelles, vous pouvez utiliser l'option de table MAX_ROWS avec la commande CREATE TABLE.

- Vous avez besoin de suffisamment de mémoire pour accepter toutes les tables HEAP que vous allez utiliser simultanément.
- Pour libérer de la mémoire, vous devez exécuter la commande DELETE FROM heap_table, TRUNCATE heap_table ou DROP TABLE heap_table.
- Si vous voulez remplir les tables MEMORY au lancement du serveur MySQL, vous pouvez utiliser l'option --init-file. Par exemple, vous pouvez mettre les commandes telles que INSERT INTO ... SELECT et LOAD DATA INFILE pour lire des données dans une source de données persistante.
- Si vous utilisez la réplication, les tables MEMORY du maître se vident à l'extinction. Cependant, un esclave peut ne pas s'apercevoir que ces tables ont été vidées, et il risque de retourner des données invalides si vous l'utilisez. lorsqu'une table MEMORY est utilisée sur le maître, il émet une commande DELETE FROM automatiquement, pour synchroniser l'esclave et le maître. Notez que même avec cette stratégie, l'esclave aura des données obsolètes entre le moment où le maître s'éteint et celui où il est redémarré. Mais si vous utilisez l'option --init-file pour remplir la table MEMORY au lancement du serveur, elle s'assurera que cette intervalle est bien null.

La mémoire nécessaire pour les tables HEAP sont
SUM_OVER_ALL_KEYS(max_length_of_key + sizeof(char*) * 2)
+ ALIGN(length_of_row+1, sizeof(char*))

ALIGN() représente un facteur d'arrondi, car la taille de la ligne doit faire exactement un multiple de la taille du pointeur de char. sizeof(char*) vaut 4 sur les machines 32 bits et 8 sur une machine 64 bits.

Tables BDB ou BerkeleyDB

   En utilisant les tables BDB, vos tables ont plus de chances de survivre aux crashs, et vous avez accès à COMMIT et ROLLBACK avec les transactions. Les options suivantes de mysqld peuvent être utilisées pour modifier le comportement des tables BDB:

--bdb-home=répertoire Répertoire de base des tables BDB. Cela doit être le même répertoire que vous avez utilisés pour --datadir.
--bdb-lock-detect=# Détection des verrouillages Berkeley. (DEFAULT, OLDEST, RANDOM, ou YOUNGEST).
--bdb-logdir=répertoire Répertoire des fichiers de log de Berkeley DB.
--bdb-no-recover Ne pas démarrer Berkeley DB en mode de restauration.
--bdb-no-sync Ne pas vider les tampons synchroniquement.
--bdb-shared-data Démarrer Berkeley DB en mode multi-processus (Ne pas utiliser DB_PRIVATE lors de l'initialisation de Berkeley DB)
--bdb-tmpdir=répertoire Répertoire des fichiers temporaires de Berkeley DB.
--skip-bdb Désactive l'utilisation des tables BDB.

   Les variables systèmes suivante affectent le comportement des tables BDB. bdb_max_lock est le nombre maximal de verrous actifs sur une table BDB. Si vous utilisez --skip-bdb, MySQL n'initialisera pas la bibliothèque Berkeley DB et cela économisera beaucoup de mémoire. Bien sûr, vous ne pouvez pas utiliser les table BDB si vous utilisez cette option. Si vous essayez de créer une table BDB, MySQL créera une table MyISAM à la place.

   Normalement, vous devez démarrer mysqld sans --bdb-no-recover si vous avez l'intention d'utiliser des tables BDB. Cela peut cependant vous poser des problèmes si vous essayez de démarrer mysqld alors que des fichiers de log BDB sont corrompus. Vous pouvez spécifier le nombre maximal de verrous avec bdb_max_lock (10000 par défaut) que vous pouvez activer sur une table BDB. Vous devez l'augmenter si vous obtenez des erreurs du type: bdb : Lock table is out of available locks Got error 12 from ... lorsque vous avez fait de longues transactions ou quand mysqld doit examiner beaucoup de lignes pour calculer la requête. Vous pouvez aussi changer les options binlog_cache_size et max_binlog_cache_size si vous utilisez de grandes transactions multi-lignes.

Moteur de table EXAMPLE

   C'est un moteur "bidon" qui ne fait rien du tout. Son but est de fournir des exemples au niveau du code source de MySQL pour illustrer l'écriture d'un moteur de table. En tant que tel, il intéressera surtout les développeurs.

Moteur de table FEDERATED

   C'est un moteur de table qui accède à des tables dans une base de données distante, plutôt que dans des fichiers locaux.

Moteur de table ARCHIVE

   Il est utilisé pour stocker de grande quantité de données, sans index, et de manière très économique. Le moteur ARCHIVE ne supporte que les commandes INSERT et SELECT: aucun effacement, remplacement ou modification. Une commande SELECT effectue un scan de table complet. Les enregistrements sont compressés au moment de leur insertion. Vous pouvez utiliser la commande OPTIMIZE TABLE pour analyser la table, et compresser encore plus.

Moteur CSV

   Ce moteur stocke les données dans un fichier texte, avec le format valeurs séparées par des virgules.

Moteur de table InnoDB

   InnoDB fournit à MySQL un gestionnaire de table transactionnelle (compatible ACID), avec validation (commits), annulations (rollback) et capacités de restauration après crash. InnoDB utilise un verrouillage de lignes, et fournit des lectures cohérentes comme Oracle, sans verrous. Ces fonctionnalités accroissent les possibilités d'utilisation simultanées des tables, et les performances. Il n'y a pas de problème de queue de verrous avec InnoDB, car les verrous de lignes utilisent très peu de place. Les tables InnoDB sont les premières tables MySQL qui supportent les contraintes de clés étrangères (FOREIGN KEY).

   Si vous ne souhaitez pas utiliser les tables InnoDB, vous pouvez ajouter l'option skip-innodb dans votre fichier d'options MySQL. Les deux ressources disques importantes gérées par InnoDB sont sa table de données et son fichier de log. Si vous ne spécifiez aucune options de configuration InnoDB, MySQL créera un fichier de données auto-croissant appelé ibdata1 et deux fichiers de log de 5 Mo appelés ib_logfile0 et ib_logfile1 dans le dossier de données MySQL.

Pour configurer le fichier de données InnoDB, utilisez l'option innodb_data_file_path dans my.cnf:
innodb_data_file_path=datafile_spec1[ ;datafile_spec2]...

Exemples

Cette configuration crée un fichier de données de 10 Mo ibdata1, auto-croissant. Il n'y a pas de dossier de sauvegarde d'indiqué: par défaut, c'est le dossier de données de MySQL.
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
Une table contenant 50 Mo de données, appelée ibdata1 et un fichier 50 Mo auto-croissant, appelé ibdata2 dans le dossier de données
[mysqld]
innodb_data_file_path=ibdata1:50M ;ibdata2:50M:autoextend
La syntaxe complète de la spécification de fichier de données inclut le nom du fichier, sa taille, et différents attributs:
file_name:file_size[:autoextend[:max:max_file_size]]
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend:max:500M
La ligne de configuration suivante permet au fichier ibdata1 de croître jusqu'à 500 Mo
[mysqld]
innodb_data_home_dir = /ibdata
innodb_data_file_path=ibdata1:50M ;ibdata2:50M:autoextend
crée deux fichiers appelés ibdata1 et ibdata2 mais les place dans le dossier /ibdata,
!!!!Note : InnoDB ne crée pas les dossiers
Si vous spécifier l'option innodb_data_home_dir sous forme de chaîne vide, vous pouvez spécifier des noms de chemins absolus dans la valeur de innodb_data_file_path. L'exemple ci-dessous est équivalent au précédent:
[mysqld]
innodb_data_home_dir =
innodb_data_file_path=/ibdata/ibdata1:50M ;/ibdata/ibdata2:50M:autoextend

Exemple de configuration
[mysqld]
# Vous pouvez placer d'autres options MYSQL ici
# ...
# Le fichier de données doit contenir vos données et index.
# Assurez vous que vous avez l'espace disque nécessaire.
innodb_data_file_path = ibdata1:10M:autoextend
#
# Utilisez un buffer de taille 50 à 80 % de votre mémoire serveur
set-variable = innodb_buffer_pool_size=70M
set-variable = innodb_additional_mem_pool_size=10M
#
# Utilisez un fichier de log de taille 25 % du buffer mémoire
set-variable = innodb_log_file_size=20M
set-variable = innodb_log_buffer_size=8M
#
innodb_flush_log_at_trx_commit=1

Options de démarrage InnoDB

innodb_additional_mem_pool_size La taille du buffer mémoire d'InnoDB, pour ses dictionnaires d'informations, et ses structures internes de données. Une valeur pratique est 2Mo, mais plus vous aurez de tables dans votre application, plus vous devrez augmenter cette valeur. Si InnoDB est à court de mémoire, il va allouer de la mémoire auprès du système, et écrire des messages dans le fichier de logs.
innodb_buffer_pool_size La taille de buffer mémoire que InnoDB utiliser pour mettre en cache les données et les index de tables. Plus cette valeur est grand, et moins vous ferez d'accès disques. Sur un serveur dédiés, vous pouvez monter cette valeur jusqu'à 80% de la mémoire physique de la machine. Ne lui donnez pas une valeur trop grande, car cela peut engendrer l'utilisation de mémoire sur le disque par votre serveur.
innodb_data_file_path Chemin individuel vers les fichiers de données, et leur taille. Le chemin complet de chaque fichier de données est créé en concaténant innodb_data_home_dir avec les chemins spécifiés ici. La taille du fichier est spécifiée en méga-octets, ce qui explique la présence du 'M' après les spécifications ci-dessus. Vous pouvez donner au fichier une taille supérieure à 4 Go sur les systèmes d'exploitation qui acceptent les gros fichiers.
Sur certains systèmes, la taille doit être inférieure à 2 Go.Si vous ne spécifiez pas innodb_data_file_path, le comportement par défaut est de créer un fichier auto-croissant de 10 Mo, appelé ibdata1. vous pouvez donner une taille de fichier de plus de 4Go sur les systèmes d'exploitation qui supportent les grands fichiers. Vous pouvez aussi utiliser les partition raw.
innodb_data_home_dir La partie commune du chemin de tous les fichiers de données InnoDB. Si vous ne mentionnez pas cette option, la valeur par défaut sera celle du dossier de données MySQL. Vous pouvez aussi spécifier une chaîne vide, et dans ce cas, les chemins spécifiés dans innodb_data_file_path seront des chemins absolus.
innodb_fast_shutdown Par défaut, InnoDB fait une purge complète et vide le buffer d'insertion avant une extinction. Ces opérations peuvent prendre beaucoup de temps. Si vous donnez à ce paramètre la valeur de 1, InnoDB ignore ces opérations d'extinction. Sa valeur par défaut est 1.
innodb_file_io_threads Nombre de pointeurs de fichier de InnoDB. Normalement, cette valeur doit être de 4.
innodb_file_per_table Cette option fait que InnoDB va stocker chaque table dans un fichier .ibd indépendant. Voyez la section sur les espaces de tables multiples.
innodb_flush_log_at_trx_commit Normalement, cette option vaut 1, ce qui signifie que lors de la validation de la transaction, les logs sont écrits sur le disque, et les modifications faites par la transaction deviennent permanentes, et survivront un crash de base. Si vous souhaitez réduire la sécurité de vos données, et que vous exécutez de petites transactions, vous pouvez donner une valeur de 0 à cette option, pour réduire les accès disques.
innodb_flush_method La valeur par défaut pour cette option est fdatasync. Une autre option est O_DSYNC.
innodb_force_recovery Attention : cette option ne doit être définie que dans les cas où vous voulez exporter les données d'une base corrompue, dans une situation d'urgence. Les valeurs possibles de cette option vont de 1 à 6. Par mesure de sécurité, InnoDB empêche les modifications de données si la valeur de cette option est supérieure à 0.
innodb_lock_wait_timeout Le délai d'expiration des transactions InnoDB, en cas de blocage de verrou, avant d'annuler. InnoDB détecte automatiquement les blocages de verrous et annule alors les transactions. Si vous utilisez la commande LOCK TABLES, ou un autre gestionnaire de table transactionnelles que InnoDB dans la même transaction, un blocage de verrou peut survenir, et InnoDB ne pourra pas le détecter. Ce délai est donc pratique pour résoudre ces situations.
innodb_log_arch_dir Le dossier où les logs complétés doivent être archivés, si nous utilisons l'archivage de logs. La valeur de ce paramètre doit être actuellement la même que la valeur de innodb_log_group_home_dir.
innodb_log_archive Cette valeur doit être actuellement de 0. Au moment de la restauration de données à partir d'une sauvegarde, à l'aide des log binaires de MySQL, il n'y a actuellement pas besoin d'archiver les fichiers de log InnoDB.
innodb_log_buffer_size La taille du buffer que InnoDB utilise pour écrire les log dans les fichiers de logs, sur le disque. Les valeurs utiles vont de 1 Mo à 8 Mo. Un grand buffer de log permet aux grandes transactions de s'exécuter sans avoir à écrire de données dans le fichier de log jusqu'à la validation. Par conséquent, si vous avez de grandes transactions, augmenter cette taille va réduire les accès disques.
innodb_log_file_size Taille de chaque fichier de log dans un groupe de log, exprimé en méga-octets. Les valeurs pratiques vont de 1Mo à une fraction de la taille du buffer de log (1 / le nombre de logs, en fait). Plus la taille est grande, moins de points de contrôles seront utilisés, réduisant les accès disques. La taille combinée des logs doit être inférieure à 4 Go sur les systèmes 32 bits.
innodb_log_files_in_group Nombre de fichiers de logs dans le groupe de log. InnoDB écrit dans ces fichiers de manière circulaire. Une valeur de 2 est recommandée. C'est la valeur par défaut.
innodb_log_group_home_dir Le dossier pour les fichiers de logs. Il doit avoir la même valeur que innodb_log_arch_dir. Si vous ne spécifiez pas de paramètre de log InnoDB, la configuration par défaut va créer deux fichiers de logs de 5 Mo, appelés ib_logfile0 et ib_logfile1 dans le dossier de données MySQL.
innodb_max_dirty_pages_pct Cette entier va de 0 à 100. Par défaut, il vaut 90. Le thread principal de InnoDB essaie de transmettre les pages au pool de buffer, pour qu'un pourcentage maximal de innodb_max_dirty_pages_pct soit encore en attente de flush. Si vous avez le droit de SUPER, ce pourcentage peut être changée durant l'exécution du serveur:SET GLOBAL innodb_max_dirty_pages_pct = value ;
innodb_mirrored_log_groups Nombre de copies identiques de groupe de log que nous conservons. Actuellement, cette valeur doit être au minimum de 1.
innodb_open_files Ce n'est utile que si vous utilisez les espaces de tables multiples. Cette option spécifie que le nombre maximal de fichier .ibd que InnoDB peut garder ouvert simultanément. La valeur minimum est de 10. La valeur maximum est de 300.
Les pointeurs de fichiers utilisés par .ibd sont réservés pour InnoDB. Ils sont indépendants de ceux spécifiés par —open-files-limit, et n'affectent pas les opérations de cache. innodb_thread_concurrency
InnoDB essaie de garder le nombre de thread système concurents inférieur à la limite de ce paramètre. La valeur par défaut est 8. Si vous avez des problèmes de performances, et que SHOW INNODB STATUS revèle que des threads attendent des sémaphores, essayez de diminuer ou augmenter ce paramètre. Si vous avez un serveur avec de nombreux processeurs et disques,
vous pouvez essayer d'augmenter la valeur, pour utiliser au mieux les ressources disponibles. Une valeur recommandée est la somme du nombre de processeurs et de disques que vous avez. Une valeur de 500 ou supérieur, supprime la vérification de concurrence.

Créer des bases InnoDB

utiliser TYPE = InnoDB. ex:
CREATE TABLE CUSTOMER (A INT, B CHAR (20), INDEX (A)) TYPE = InnoDB ;
La quantité d'espace disponible apparaît dans la section de commentaire de la commande SHOW. Par exemple:
SHOW TABLE STATUS FROM test LIKE 'CUSTOMER'
vous pouvez désactiver l'auto-validation avec la commande SET AUTOCOMMIT = 0 et utiliser les commandes COMMIT et ROLLBACK pour valider ou annuler vos transactions. Si vous voulez laisser le mode d'auto-validation tranquille, vous pouvez placer vos commandes entre START TRANSACTION et COMMIT ou ROLLBACK.

Convertir des tables MyIsam vers InnoDB

   pour utiliser le moteur InnoDB pour la création de table par défaut, utiliser default-table-type=innodb dans le groupe [mysqld]. Le moyen le plus rapide pour mettre la table au format InnoDB est d'insérer directement les lignes dans une table InnoDB, c'est à dire, utiliser ALTER TABLE ... TYPE=INNODB, ou créer un table InnoDB vide, avec la même définition et de faire l'insertion de toutes les lignes avec INSERT INTO ... SELECT * FROM ....

INSERT INTO newtable SELECT * FROM oldtable
WHERE yourkey › something AND yourkey ‹= somethingelse ;
Une fois que toutes les données ont été insérées dans la table, vous pouvez la renommer.

   Colonnes AUTO_INCREMENT avec InnoDB: Innodb va ajouter dans le dictionnaire de données un compteur spécial appelé compteur auto-increment, qui est utilisé pour assigner les nouvelles valeurs de la colonne.

   Contraintes de clés étrangères FOREIGN KEY: La syntaxe des définitions de contraintes de clés étrangères de InnoDB est la suivante:

[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
REFERENCES tbl_name (index_col_name, ...)
[ON DELETE CASCADE | SET NULL | NO ACTION | RESTRICT]
[ON UPDATE CASCADE | SET NULL | NO ACTION | RESTRICT]

   Les deux tables doivent être de type InnoDB, dans la table, il doit y avoir un INDEX où les clés étrangères sont listées comme première colonne, dans le même ordre, et dans la table référencée, il doit y avoir un INDEX où les colonnes référencées sont listées comme premières colonnes, dans le même ordre. Les préfixes d'index ne sont pas supportés pour les clés de contrainte.

exemple:
CREATE TABLE parent(id INT NOT NULL,
PRIMARY KEY (id)
) TYPE=INNODB ;
CREATE TABLE child(id INT, parent_id INT,
INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)
ON DELETE CASCADE
) TYPE=INNODB ;
exemple plus complexe :
CREATE TABLE product (category INT NOT NULL, id INT NOT NULL,
price DECIMAL,
PRIMARY KEY(category, id)) TYPE=INNODB ;
CREATE TABLE customer (id INT NOT NULL,
PRIMARY KEY (id)) TYPE=INNODB ;
CREATE TABLE product_order (no INT NOT NULL AUTO_INCREMENT,
product_category INT NOT NULL,
product_id INT NOT NULL,
customer_id INT NOT NULL,
PRIMARY KEY(no),
INDEX (product_category, product_id),
FOREIGN KEY (product_category, product_id)
REFERENCES product(category, id)
ON UPDATE CASCADE ON DELETE RESTRICT,
INDEX (customer_id),
FOREIGN KEY (customer_id)
REFERENCES customer(id)) TYPE=INNODB ;

InnoDB et la réplication

   Il est aussi possible d'utiliser la réplication pour que les tables de l'esclave ne soient pas les mêmes que les tables du maître. Par exemple, vous pouvez répliquer les modifications d'une table InnoDB sur le maître dans une table MyISAM sur l'esclave. Pour configurer un nouvel esclave sur le maître, vous devez faire une copie de l'espace de table InnoDB, des fichiers de log, ainsi que les fichiers .frm des tables InnoDB, et les placer sur l'esclave. Il y a des limitations mineures à la réplication InnoDB: LOAD TABLE FROM MASTER ne fonctionne pas pour les tables InnoDB. Il y a des palliatifs: 1) exportez la table du maître, et envoyez la sur l'esclave, ou, 2) utilisez ALTER TABLE tbl_name TYPE=MyISAM sur le maître avant de configurer la réplication avec LOAD TABLE tbl_name FROM MASTER, et ensuite, ALTER TABLE pour remettre les tables en mode InnoDB après cela.
^
14 septembre 2010

htmlpdflatexmanmd




named

named

service DNS

   named est un serveur de nom de domaine. Invoqué sans argument, named lit le fichier de configuration /etc/named.conf, lit les données initiales et écoute les requêtes.

OPTIONS

-4 utilise IPv4 uniquement
-6 utilise IPv6 uniquement
-c config-file utilise le fichier de configuration spécifié
-d debug-level Définis le niveau de débug
-D string Spécifie la chaîne utilisée pour identifier une instance de named dans la liste de processus.
engine-name Spécifie le hardware cryptographique à utiliser
-f ne place pas le serveur en tâche de fond
-g lance le serveur en tache de fond et force tous les log dans stderr.
-m flag active les flags de debuggage de l'utilisation mémoire.
#cpus Crée #cpus threads pour profiter des systèmes à plusieurs CPU. Défaut: 1 thread par cpu.
-p port Écoute les requêtes sur le port spécifié.
-s Écrit des statistiques d'utilisation mémoire sur stdout en quittant
-S #max-socks Permet à named d'utiliser #max-socks sockets. Défaut: 4096 (21000 lorsque compilé avec --with-tuning=large)
-t directory chroot dans le répertoire spécifié, mais avant de lire le fichier de configuration.
-U #listeners Utilise le nombre de threads pour l'écoute de packets UDP entrants sur chaque adresse. Défaut: CPUs / 2
-u user définit l'utilisateur après avoir complété les opérations privilégiés.
-V Affiche la version et les options de build, puis quitte

Signaux

SIGHUP force named à relire sa configuration
SIGINT,SIGTERM Arrêter le serveur
^
14 septembre 2010

htmlpdflatexmanmd




named-checkconf

named-checkconf

Vérifie la syntaxe de la configuration de named

OPTIONS

-t directory chroot dans le répertoire spécifié
-p Affiche le fichier named.conf et tous les fichiers inclus en forme canonique si aucune erreur n'a été detectée
-x Avec -p, cache les clé partagées en les remplaçant pas des '?'
-z Effectue un teste de charge de toutes les zones master trouvé dans named.conf
-j En chargeant un zonefile lit le journal s'il existe
filename le nom du fichier de configuration à vérifier (défaut /etc/named.conf)
^
14 septembre 2010

htmlpdflatexmanmd




named-checkzone

named-checkzone, named-compilezone

Vérification de validité et d'intégrité

   named-checkzone vérifie la validité et l'intégrité d'un fichier de zone. named-compilezone est similaire, mais il dump toujours le contenu de la zone dans un fichier de zone dans un format spécifié.

OPTIONS

-q mode silencieux
-j En chargeant le fichier de zone, lit le journal s'il existe.
-J filename Lit le journal depuis le fichier spécifié (implique -j)
-c class spécifie la classe de la zone. Si non spécifié "IN" est assumé.
-i mode Effectue des vérifications d'intégrité de zone post-load. les modes possible sont full, full-sibling, local, local-sibling et none

        mode full vérifie que les records MX, SRV et NS refère à un record A ou AAA.
        mode local vérifie seulement que les records MX, SRV et NS refère à des noms d'hôte dans la zone.
        mode full-sibling et local-sibling sont identiques à full et local, mais désactive la vérification du sibling glue.

-f format Spécifie le format du fichier de zone. peut être text ou raw
-F format Spécifie le format du fichier de sortie spécifiée. peut être text ou raw
-k mode Effectue une vérification "check-names" avec le mode d'échec spécifié. Peut être fail, warn ou ignore
-l ttl Définis un TTL max permis pour le fichier d'entrée. Tout enregistrement supérieur implique le rejet de la zone
-m mode Spécifie si les records MX réfèrent à une adresse. Peut être fail, warn ou ignore
-M mode Vérifie si un record MX réfère à un CNAME. peut être fail, warn ou ignore
mode Vérifie si les records NS réfèrent à une adresse. peut être fail, warn ou ignore
-o filename Écrit la sortie dans le fichier spécifié
-r mode Vérifie les records qui sont traités différemment par DNSSEC mais sont sémantiquement égal.
-s style Spécifie le style du fichier de zone dumpé. Peut être full ou relative.
-S mode Vérifie si un record SRV réfère à un CNAME
-t directory chroot au répertoire spécifié
-T mode Vérifie si les record TXT et SPF existent on non. Une erreur est émise s'ils ne correspondent pas. (warn ou ignore)
-w directory chdir vers le répertoire spécifié pour que les chemins relatifs dans les directives $INCLUDE fonctionnent.
-D Dump le fichier de zone au format canonique. Toujours activé pour named-compilezone
-W mode Spécifie si la vérification est pour les non-terminal wildcards
zonename Le nom de domaine de la zone à vérifier
filename Le nom du fichier de zone
^
18 mars 2016

htmlpdflatexmanmd




named-journalprint

named-journalprint

Affiche le journal de zone au format human-readable

   Les fichiers journaux sont automatiquement créés par named quand des changements sont fait dans les zones dynamiques. Chaque ajout ou suppression y est enregistré au format binaire, permettant de ré-appliquer les changements dans la zone quand le serveur est redémarré après un crash. Par défaut, le nom des fichier journaux se terminent avec l'extension .jnl.

^
18 mars 2016

htmlpdflatexmanmd




named-rrchecker

named-rrchecker

Vérificateur de syntaxe pour les RR

   named-rrchecker lit un RR depuis l'entrée standard et vérifie sa syntaxe.

OPTIONS

-o origin Spécifie un origine à utiliser pour interpréter l'enregistrement
-p Affiche l'enregistrement résultant au format canonique
-u Affiche l'enregistrement résultant dans une forme inconnue
-C, -T, -P Affiche la classe, type standard, et type privé, respectivement.
^
18 janvier 2015

htmlpdflatexmanmd




nbd-server

nbd-server

Dessert un fichier comme périphérique block à d'autre machine.

Description

   Avec NBD, un client peut utiliser un fichier, exporté sur le réseaux depuis un serveur, comme périphérique block. NBD peut être utile pour les clients léger sans disques qui ont besoin d'espace swap, mais on peut également y créer un système de fichier et l'utiliser comme système de fichier local.

   nbd-server implémente un peut de sécurité via un fichier appelé /etc/nbd-server/allow. Ce fichier doit lister les adresse IP ou les masques réseaux des client qui sont autorisés à se connecter. S'il n'existe pas, tous les clients sont capable de se connecter. Si le fichier est vide, aucun client ne peut se connecter.

   Noter que bien que la ligne de commande permet de spécifier un export, l'utilisation de cette option est dépréciée. Il est préférable d'utiliser le fichier de configuration.

   Bien que nbd-server fonctionne, les nouveaux exports peuvent être ajoutés en ré-écrivant le fichier de configuration puis en envoyant un SIGHUP au serveur, ce qui le force à relire sa configuration.

OPTIONS

ip L'addresse ip d'écoute du service. Peut être une IPv4 ou une IPv6 ou un nom d'hôte. Dans le dernier cas, nbd-serveur fait une recherche de nom et écoute sur la première adresse qui lui est retournée. Non spécifié, nbd-server écoute sur toutes les interfaces.
port Le port d'écoute du service. Si 0 est spécifié, nbd-server va écouter sur stdin.
filename Le nom du fichier qui devrait être exporté. Cela peut être tout fichier, incluant des périphériques block réel (ex: depuis /dev). Si le nom du fichier inclus la chaîne %s, elle sera substituée avec l'adresse IP du client.
size La taille du périphérique block côté client. Utile en conjonction avec l'option -m
-r Export le fichier en lecture seule. Si un client tente d'y écrire, il recevra une erreur mais restera connecté.
-m Travail avec plusieurs fichiers. Cela peut être utilisé pour exporter des périphériques block plus grand que la taille de fichier maximum permise dans le système de fichier. Pour utiliser cette options, il faut créer des fichiers avec les noms au format name.X où name est donné en argument filename, et X est un nombre commençant à 0.
-c Copy on write. Les opérations d'écritures ne sont pas faite sur le fichier exporté, mais dans un fichier séparé. Ce fichier est supprimé quand la connexion est terminée. Cela ralentis le service.
-C Spécifier le fichier de configuration. Défaut: /etc/nbd-server/config.
-M Spécifie le nombre maximum de connexions ouverte. Non spécifié, aucune limite n'est définie.
-d Ne fork pas.
host list filename Cet argument devrait contenir un liste d'IP pour les hôtes qui peuvent se connecter au serveur. les wildcards ne sont pas permis. Si le fichier n'existe pas, il est ignoré ( et tous les hôte peuvent se connecter ); si le fichier existe, mais est vide, aucun hôte ne peut se connecter. Par défaut, le nom nbd_server.allow est utilisé, et recherché dans le répertoire courant, sauf si nbd-server est compilé en service, auquel cas il le recherche dans "/".
section name Si -o est donné, nbd-server affiche la section du fichier de configuration avec cet argument en en-tête qui est fonctionnellement équivalent à d'autres options spécifiés sur la ligne de commande, et quitte.

Exemples

Exporter un fichier /export/nbd/exp-bl-dev sur le port 2000:
nbd-server 2000 /export/nbd/exp-bl-dev
Exporter le même fichier en lecture seule:
nbd-server 2000 /export/nbd/exp-bl-dev -r
Exporter le même fichier en r/w, mais en s'assurant que les changements seront perdu au redémarrage:
nbd-server 2000 /export/nbd/exp-bl-dev -c
^
18 janvier 2015

htmlpdflatexmanmd




nbd-server.config

nbd-server.config

Fichier de configuration pour ndb-server

Description

   Un en-tête de section est un nom unique qui est entre [ et ], et dénote le début d'un section; une section continue jusqu'à ce qu'une autre section commence ou la fin du fichier. La première section doit s'appeler generic et est utilisée pour les option globales qui s'appliques à plus d'un export et doit toujours être présent. Chaque autre section maintient un export; les noms de ces section ne sont pas important excepté qu'ils doivent être unique.

Options pour la section generic

allowlist (bool,optionnel) permet au client de rechercher une liste d'exports depuis ce serveur. nbd-client -l permet d'avoir cette liste.
group (string,optionnel) Le nom du groupe sous lequel le service fonctionne. Non spécifié le serveur ne tente pas de changer son GID.
includedir (string,optionnel) Répertoire contenant les fichiers avec l'extension '.conf' qui contiennent d'autres directives de configuration. la section [generic] ne peut pas être dans un de ces fichiers.
listenaddr (string,optionnel) Contient l'IP local sur laquelle le service écoute.
oldstyle (bool,optionnel) à true, le serveur exporte tous les exports sur un port séparé. Dans ce cas, l'option port pour les exports individuels est mandatoire.
port (string,optionnel) port d'écoute du serveur. Défaut: 10809.
user (string,optionnel) le nom du l'utilisateur sous lequel le service fonctionne. Non spécifié le serveur ne tente pas de changer son UID.

Options pour les sections d'export

authfile (string,optionnel) Le nom du fichier d'autorisation pour cet export. Ce fichier devrait contenir une ligne par adresse IP, ou par réseau en notation CIDR. Si le fichier n'existe pas, tout le monde est autorisé à se connecter. Si le fichier existe mais vide, aucun client n'est autorisé à se connecter.
copyonwrite (bool,optionnel) Spécifie si l'export est copy-on-write, qui n'écrit pas dans le fichier maître, mais dans un fichier séparé, qui est supprimé à la déconnexion.
exportname (string,requis) le nom du fichier qui sera exporté. Doit être pleinement qualifié. Utilisé en conjonction avec temporary, spécifie un template pour le fichier temporaire concerné, et donc peut être utilisé pour contrôler le répertoire dans lequel il est créé.
filesize (entier,optionnel) désactive l'autodétection de la taille du fichier ou du périphérique block. Doit être spécifié en octets. Si l'option multifile est présent, cette option spécifie la taille de tout l'export, pas les fichiers individuels.
flush (bool,optionnel) à true, le serveur informe le client qu'il supporte et souhaite envoyer des requêtes flush quand la couche élévateur les reçois, ce qui cause un fdatasync() ou fsync() si l'option sync est présente dans le stockage. Cela augmente la fiabilité dans le cas des shutdown non propre au prix d'un dégradation des performances.
fua (bool,optionnel) à true, le serveur informe le client qu'il supporte et souhaite envoyer des commandes fua (force specified commands) quand la couche élévateur les reçois, ce qui cause la commande spécifiée d'être synchronisée sur le stockage avec sync_file_range(), ou fdatasync(). Cela augmente la fiabilité dans le cas des shutdown non propre au prix d'un dégradation des performances.
listenaddr (string,optionnel) Adresse IP d'écoute pour cet export, si ordstyle est spécifié dans la section generic
maxconnections (entier,optionnel) Limite le nombre de connections ouverte pour cet export
multifile (bool,optionnel) à true, le serveur recherche les fichiers sous la forme exportname.integer, où exportname est le nom du fichier, suivi d'un nombre unique commençant à 0.
port (integer) requis si oldstyle est spécifié dans la section generic, pour d'écoute pour cet export.
postrun (string,optionnel) si spécifié, assume que c'est une commande qui sera lancée quand un client sera déconnecté. Peut être utile pour nettoyer ce que prerun a définis, ou logger quelque chose. le code de sortie de postrun est ignoré.
prerun (string,optionnel) si spécifié, cette commande sera exécutée après que le client se soit connecté au serveur, mais avant que le serveur commence à desservir . Si la commande contient %s, cette chaîne sera remplacée par le nom du fichier qui est exporté. Si la commande se termine avec un status autre que 0, le serveur assume que l'export a échoué et refuse de le desservir.
readonly (bool,optionnel) Quand cette option est activée, le serveur informe le client qu'il préférerai envoyer des requêtes dans l'order de l'élévateur. Seulement requis quand le serveur n'utilise par l'algorithme d'élévateur, ou cet algorithme est neutralisé.
sdp (bool,optionnel) à true, le serveur utilise SDP ( Socket Direct Protocol) pour desservir l'export, au lieu de simplement l'IP. C'est plus rapide, mais nécessite un hardware spécial ( comme InfiniBand).
sparse_cow (bool,optionnel) à true, le serveur utilise les fichiers sparses pour implémenter l'option copy-on-write. De tels fichiers prennent moins d'espace qu'ils apparaissent, ce qui permet au serveur de manipuler des fichiers plus grands que n'est le périphériques block.
sync (bool,optionnel) Quand cette option est activée, le serveur va appeler un fsync() après chaque écriture au backend. Cela augmente la fiabilité dans le cas des shutdown non propre au prix d'un dégradation des performances.
temporary (bool,optionnel) Créé un export temporaire avec un nom basé sur le nom de l'export. L'export ne persistera par entre les invocations du serveur. Incompatible avec l'option multifile
timeout (string,optionnel) Nombre de secondes qu'une connexion peut être en attente pour cet export. Quand une connexion attend trop longtemps, le serveur force la déconnexion. Désactivé à 0.
transactionlog (string,optionnel) Si spécifié, ce chemin est utilisé pour générer un log de transaction. Ce log est un fichier binaire qui consiste de requêtes envoyés et des réponses reçus par le serveur, mais en excluant les données.
trim (bool,optionnel) quand cette option est activée, le serveur annonce qu'il support la commande NBD_CMD_TRIM pour l'export, cette commande permet au serveur d'annuler la donnée du disque, mais ne l'oblige pas à le faire.
virtstyle (string,optionnel) Définis le style de virtualisation. La virtualisation permet de créer un export qui va desservir un fichier différent en fonction de l'adresse IP qui se connecte. Quand la virtualisation est active, le paramètre exportname nécessite de contenir la chaine %s, qui sera remplacé par l'adresse IP du client. Le résultat de cette transformation est utilisé comme nom de fichier à ouvrir. Il y a 4 type de virtualisation supportés:

        ipliteral %s est remplacé par l'adresse IP du client. (ex: exporname = /export/%s et le client est 192.168.1.100, le serveur tente de desservir /export/192.168.1.100; pour une IPv6, /export/2001:6f8:32f:0:0:0:0:39)
        iphash idem, mais remplace les point par des "/" ( ex /export/192/168/1/100 )
        cidrhash Nécessite d'ajouter un espace et un nombre après lui, qui sera utilisé comme masque réseau. (ex pour un cidrhash = 16, tente d'ouvrir /export/192.168.0.0/192.168.1.100).

Exemples

Configuration simple:
[generic]
[export]
exportname = /export/blkdev
Pour plus de sécurité, on peut créer un fichier d'autorisation:
[generic]
user = nbd
group = nbd
[export]
exportname = /export/blkdev
authfile = /etc/nbd-server/allow
Et le fichier /etc/nbd-server/allow:
127.0.0.1
192.168.0.0/8
192.168.1.1
Pour être compatible avec les anciens clients:
[generic]
oldstyle = true
[export]
exportname = /export/blkdev
port = 12345
^
18 janvier 2015

htmlpdflatexmanmd




nbd-trdump

nbd-trdump

Traduit un log de transaction nbd sous forme human readable

Sortie

Une demande du client au serveur
Une réponse du serveur au client
H Le handle du packet
C La commande envoyée
O L'offset depuis le début du disque
L La longueur de la donnée
E L'erreur retournée
^
03 décembre 2016

htmlpdflatexmanmd




needrestart

needrestart

Vérifier les services qui doivent être redémarrés après une mise à jours de librairies

OPTIONS

-v mode verbeux
-q mode silencieux
-m ‹mode› Définis le mode de détail technique (e = easy, a = advanced)
-n  Réponse par défaut = no
-c ‹cfg› Spécifier le fichier de configuration
-r ‹mode› Définis le mode de redémarrage (l = list only, i = interactive restart, a = automatic restart)
-b Active le mode batch
-p Mode plugin nagios
-f ‹fe› frontend debconf
-u ‹ui› Utiliser le package UI préféré
-k Vérifie les kernels obsolètes
-l Vérifie les librairies obsolètes
^
31 mars 2017

htmlpdflatexmanmd




netdevstat

netdevstat

Outil d'enregistrement d'activité réseaux

   netdevstat est un script systemtap pour enregistrer l'activité réseau des processus et affiche des statistiques pour les opérations de transmission/réception

OPTIONS

update interval Définis l'interval d'échantillonage
total duration Définis le temps total de mesure en secondes
display histogram Si présent, l'histogramme sera affiché en fin de mesure
^
17 mars 2010

htmlpdflatexmanmd




netstat

netstat

Affiche les connexions réseau, les tables de routage, les statistique des interfaces, les connexions masquées, les messages netlink, et les membres multicast

   Sans option, affiche l'état des connexions réseau en listant les sockets ouvertes.

  Familles d'adresse: --tcp --udp --raw --groups --unix --inet [--ax25] [--ipx] [--netrom]

-e  donne quelques info supplémentaire (userid)
-v permet de signaler des familles d'adresses connues non supportées par le noyau
-o affiche des informations supplémentaires sur les timers réseau
-a affiche tous les sockets, y compris les sockets d'écoute des serveurs
-r, --route permet de visualiser les tables de routage (comme route)
-i, --interfaces affiche une table des interfaces réseaux (comme ifconfig)
-M, --masquerade Permet de voir les sessions ayant de l'IP-masquerade
-N, --netlink Les noyaux récents supportent une communication avec l'utilisateur nommé netlink. affiche des messages relatifs à la création, la suppression d'interfaces ou de routes à partir de /dev/route

OPTIONS

-v, --verbose active le mode verbeux
-n, --numéric affiche des adresses en format numérique, au lieu du nom symbolique
-p, --programs affiche le nom et le PID des processus propriétaires de chaque socket décrite
-l affiche les ports en écoute
-A, --af utilise une méthode différente pour affecter les familles d'adresses. utiliser des "," pour séprarer les familles d'adresses (ex : inet, unix, ipx, ax25, netrom et ddp). L'utilisation des options longues --inet, --unix, --ipx, --ax25, --netrom et --ddp à le même effet
-c, --continuous affiche la table séléctionnée chaque seconde.

Exemples

Voir quel programme utilise quel port (ou encore netstat -latupe)
netstat -a -A inetd -p
lister les services associés aux ports en écoute
netstat -ntulp
^
05 mai 2017

htmlpdflatexmanmd




NetworkManager

NetworkManager

Service de gestion réseaux

   Le service NetworkManager tente de simplifier et d'automatiser la configuration réseaux et les opérations réseaux. Les informations sur le réseau sont exportés via D-Bus.

   NetworkManager exécute les scripts dans /etc/NetworkManager/dispatcher.d ou ses sous-répertoire dans l'ordre alphabétique en réponse aux événements réseaux. Chaque script devrait être un fichier exécutable possédé par root. Ils ne doivent pas être en écriture par le groupe et les autres, ni suid.

   Chaque script reçoit 2 arguments, le premier est le nom de l'interface, et le second est l'action. Pour les actions de périphérique, l'interface est le nom de l'interface kernel utilisable pour la configuration IP. Donc c'est soit VPN_IP_IFACE, DEVICE_IP_IFACE, ou DEVICE_IFACE. Pour les action hostname et connectivity-change, c'est toujours none.

pre-up L'interface est connectée au réseau, mais pas encore activée. Les scripts agissant dans cet événement doivent être dans le sous-répertoire pre-up.d, et NetworkManager attend la fin de l'exécution du script avant d'indiquer aux applications que l'interface est pleinement activée
up L'interface est activée
pre-down L'interface n'est pas encore déconnecté du réseau. Les scripts agissant dans cet événement doivent être placés dans le sous-répertoire pre-down.d, et NetworkManager attend la fin de l'exécution du script avant de déconnecter l'interface. Noter que cet événement n'est pas émis pour les déconnections forcées
down L'interface a été désactivée
vpn-pre-up Le VPN est connecté au réseau mais n'est pas encore activé. Les scripts sont dans le sous-répertoire pre-up.d
vpn-up Une connection VPN a été activée
vpn-pre-down Le VPN n'est pas encore déconnecté du réseau. Les scripts agissant dans cet événement doivent être placés dans le sous-répertoire pre-down.d, et NetworkManager attend la fin de l'exécution du script avant de déconnecter l'interface. Noter que cet événement n'est pas émis pour les déconnections forcées
vpn-down La connection VPN a été désactivée
hostname Le nom d'hôte du système a été mis à jours. Le nom de l'interface est vide et aucune variable d'environnement n'est définie pour cette action.
dhcp4-change Le bail dhcpv4 a changé
dhcp6-change Le bail dhcpv6 a changé
connectivity-change L'état de connexion réseau a changé

Variables d'environnement

   L'environnement contient plus d'informations sur l'interface et la connexion. Les variables suivanetes sont disponible à utiliser dans les scripts

CONNECTION_UUID l'UUID du profile de connexion
CONNECTION_ID le nom du profile de connexion
CONNECTION_DBUS_PATH Le chemin D-Bus de NetworkManager de la connexion
CONNECTION_FILENAME Le fichier du profile de connexion
CONNECTION_EXTERNAL À 1, indique que la connexion décris une configuration réseau créé en-dehors de NetworkManager
DEVICE_IFACE Nom de l'interface du périphérique.
DEVICE_IP_IFACE Nom de l'interface IP du périphérique.
IP4_ADDRESS_N Adresse IPv4 sous la forme "adresse/préfixe passerelle", où N est un numéro de 0 à (adresses IPv4 -1). La passerelle est déprécié.
IP4_NUM_ADDRESSES Contient le nombre d'adresses IPv4 que le script peut attendre
IP4_GATEWAY Passerelle IPv4
IP4_ROUTE_N Route IPv4 au format "address/prefix next-hop metric", où N est un nombre de 0 à ‹route-1›
IP4_NAMESERVERS Liste séparé par un espace de serveurs DNS
IP4_DOMAINS Liste séparé par un espace de domaines de recherche
DHCP4_‹dhcp-option-name› Si la connection utilise DHCP, chaque option DHCP est définis dans une variable
IP6_‹name› Certaines variables IPv4 sont également disponible pour IPv6
DHCP6_‹name› Certaines variables IPv4 sont également disponible pour IPv6
CONNECTIVITY_STATE L'état de connexion réseau

   Dans le cas du VPN, VPN_IP_IFACE est définis, et les variables IP4_* et IP6_* avec le préfixe VPN sont exportés également, comme VPN_IP4_ADDRESS_0, VPN_IP4_NUM_ADDRESSES.

   Les scripts sont lancés un à la fois, mais de manière asynchrone depuis le processus principale NetworkManager, et sont tués s'ils sont trop long. Si un script doit prendre beaucoup de temps pour s'exécuter, il faut lancer un processus enfant pour que le parent puisse se terminer rapidement. Les scripts qui sont des liens symboliques pointant dans /etc/NetworkManager/dispatcher.d/no-wait.d/ sont lancés immédiatement, sans attendre la fin du script précédent.

OPTIONS

-N, --no-daemon Ne lance pas en tâche de fond
-d, --debug Mode debug
-p, --pid-file Spécifie l'emplacement du fichier pid
--state-file Spécifie un fichier pour stocker l'état de NetworkManager. Défaut: /var/lib/NetworkManager/NetworkManager.state
--config Spécifie le fichier de configuration. Défaut: /etc/NetworkManager/NetworkManager.conf
--plugins Liste les plugins utilisés pour gérer les paramètres de connexions système. (keyfile, ifcfg-rh, ifcfg-suse, ifupdown)
--log-level Définis le niveau de log
--log-domains Liste d'opérations loggés
--print-config Affiche la configuration de NetworkManager

Propriétés udev

   Le gestionnaire de périphérique udev est utilisé pour la découverte. Les propriétés suivantes influencent la manière dont NetworkManager gère les périphériques:

NM_UNMANAGED Aucune connexion par défaut n'est créé et ne tente pas d'activation automatique si cette propriété est à 1.

Signaux

SIGHUP Recharge la configuration de NetworkManager
SIGUSR1 Force à ré-écrire la configuration DNS, mais ne redémarre pas le plugin dns et n'interrompt pas la résolution de nom.
^
05 mai 2017

htmlpdflatexmanmd




NetworkManager.conf

NetworkManager.conf

Fichier de configuration de NetworkManager

   /etc/NetworkManager/NetworkManager.conf, /etc/NetworkManager/conf.d/name.conf, /usr/lib/NetworkManager/conf.d/name.conf, /var/lib/NetworkManager/NetworkManager-intern.conf sont les emplacement par défaut de la configuration de NetworkManager

[main]

plugins[+|-]=‹plugin› Définis une liste de plugins à utiliser. Défaut: keyfile
monitor-connection-files Définis si les plugins configurés devraient définir les monitors de fichier. Désactivé par défaut.
auth-polkit Spécifie si le système utilise PolicyKit pour l'authorisation. à false, toutes les requêtes sont autorisées. à true, les requêtes non-root sont autorisées en utilisant PolicyKit. Défaut: true.
dhcp Définis le client DHCP utilisé. (dhclient, dhcpd, internal). Défaut: les 3, dans cet ordre.
no-auto-default Spécifie les périphériques pour lesquels NetworkManager ne devrait pas créer de connexion par défaut. Par défaut, NetworkManager crée une connexion pour tout périphérique Ethernet qui est géré et qui n'a pas de connexion configuré. Peut avoir la valeur spéciale '*' pour s'appliquer à tous les périphériques. /var/run/NetworkManager/no-auto-default.state contient ces périphériques pour empêcher de créer la connection par défaut. Cette liste peut contenir une liste de périphérique ou d'adresse MAC.
ignore-carrier
assume-ipv6ll-only Spécifie les périphériques pour lequels NetworkManager tente de générer une connexion basé sur la configuration initiale quand le périphérique a seulement une adresse de lien local IPv6
configure-and-quit à true, NetworkManager quitte une fois la configuration réseau initiale terminée, et lance des helpers pour préserver les bails dhcp et les adresses ipv6
dns Définis le mode de traitement dns (resolv.conf):

        default met à jours /etc/resolv.conf
        dnsmask Lance dnsmask comme serveur de nom cache local, en utilisant un split dns s'il y a une connexion VPN. Il est possible de passer des paramètre à dnsmask en les ajoutant dans les fichiers dans ${prefix}/etc/NetworkManager/dnsmasq.d/
        unbound NetworkManager utilise dnssec-triggerd avec une configuration split DNS et le support de dnssec. /etc/resolv.conf est géré par dnssec-triggerd
        none NetworkManager ne modifie pas resolv.conf. implique "rc-manager unmanaged"

rc-manager Définis le mode de gestion de /etc/resolv.conf.

        symlink /etc/resolv.conf est un lien vers un fichier dans le répertoire runtime. Si /etc/resolv.conf est déjà un lien pointant vers un autre emplacement, il n'est pas modifié.
        file NetworkManager gérer /etc/resolv.conf comme fichier.
        resolvconf Lance resolvconf pour mettre à jours la configuration DNS
        netconfig Lance netconfig pour mettre à jours la configuration DNS
        unmanaged Ne touche pas à /etc/resolv.conf

debug Liste séparé par des "," d'options de debuggage. Cette valeur est combinée avec la variable NM_DEBUG. Les valeurs supportées sont:

        RLIMIT_CORE Définis "ulimit -c unlimited" pour écrire les coredumps.
        fatal-warnings Définis g_log_set_always_fatal() sur coredump dans les messages d'alert de glib. == --g-fatal-warnings

autoconnect-retries-default Nombre de fois qu'une activation de connexion devrait être automatiquement tenté avant de basculer sur une autre. Ne s'applique que pour les connexions qui peuvent auto-connect et ont la propriété "connection.autoconnect-retries" à -1. Défaut: 4

[keyfile]

   Cette section contient les options spécifique au plugin keyfile, et est normalement utilisé quand on utilise pas d'autre plugin spécifique à une distribution

path Emplacement où les keyfiles sont lus et stockés. Défaut: ${prefix}/etc/NetworkManager/conf.d
unmanaged-devices Voir la section format de liste de périphérique pour la syntaxe

[ifupdown]

   Cette section contient les options spéciques au plugin ifupdown

managed à true, les interfaces d-ans /etc/network/interfaces sont gérées par NetworkManager. Défaut: false

[logging]

   Cette section contrôle les log de NetworkManager. Ces paramètres peuvent être écrasés par les options --log-level et --log-domains

level Niveau de verbosité (OFF, ERR, WARN, INFO, DEBUG, TRACE)
domains Liste de domaines: PLATFORM, RFKILL, ETHER, WIFI, BT, MB, DHCP4, DHCP6, PPP, WIFI_SCAN, IP4, IP6, AUTOIP4, DNS, VPN, SHARING, SUPPLICANT, AGENTS, SETTINGS, SUSPEND, CORE, DEVICE, OLPC, WIMAX, INFINIBAND, FIREWALL, ADSL, BOND, VLAN, BRIDGE, DBUS_PROPS, TEAM, CONCHECK, DCB, DISPATCH, AUDIT, SYSTEMD, VPN_PLUGIN, NONE, ALL, DEFAULT, DHCP, IP.
backend debug (syslog+stderr), syslog, journal
audit Envoie les enregistrements d'audit à auditd. À false, ces données sont seulement envoyées au système de logging système. Défaut: true

[connection]

   Spécifie les valeurs par défaut pour les connexions

connection.autoconnect-slaves
connection.lldp
connection.stable-id
ethernet.cloned-mac-address
ethernet.generate-mac-address-mask Défaut: preserve
ethernet.mtu à 0, le MTU n'est pas reconfiguré durant l'activation du périphérique sauf si requis par les contraintes IPv6. Non spécifié, un DHCP6/SLAAC est utilisé ou une valeur par défaut de 1500
ethernet.wake-on-lan
infiniband.mtu à 0, le MTU n'est pas reconfiguré durant l'activation du périphérique sauf si requis par les contraintes IPv6. Non spécifié, un DHCP6/SLAAC est utilisé ou laissé non-spécifié
ip-tunnel.mtu À 0, le MTU n'est pas reconfiguré durant l'activation du périphérique sauf si requis par les contraintes IPv6. Non spécifié, un DHCP6/SLAAC est utilisé ou une valeur par défaut de 1500
ipv4.dad-timeout
ipv4.dhcp-timeout
ipv4.route-metric Non spécifié, la valeur par défaut pour l'interface est utilisée
ipv6.ip6-privacy non définis, utilise le contenu de /proc/sys/net/ipv6/conf/default/use_tempaddr
ipv6.route-metric
vpn.timeout Défaut: 60 secondes
Wifi.ccloned-mac-address défaut: preserve
wifi.mtu À 0, le MTU n'est pas reconfiguré durant l'activation du périphérique sauf si requis par les contraintes IPv6. Non spécifié, un DHCP6/SLAAC est utilisé ou une valeur par défaut de 1500
wifi.powersave Défaut: ignore

Sections connection

Il est possible de configurer plusieurs sections connection en ayant des noms qui commencent tous par "connection":
[connection]
ipv6.ip6-privacy=0
connection.autoconnect-slaves=1
vpn.timeout=120
    
[connection-wifi-wlan0]
match-device=interface-name:wlan0
ipv4.route-metric=50
    
[connection-wifi-other]
match-device=type:wifi
ipv4.route-metric=55
ipv6.ip6-privacy=1

   Les sections avec un fichier sont considérés dans l'ordre d'apparence, à l'exception que la section [connection] est toujours considéré en dernier. En vérifiant une valeur par défaut, les sections sont recherchés jusqu'à ce que la valeur soit trouvée.

   Les propriétés suivantes contrôle comment une section connection s'applique:

match-device Permet de restreindre les périphériques
stop-match (bool) Si match-device match, les sections suivantes ne sont pas considérés. Défaut: no

[device]

   Configuration persistante par périphérique. Exemple:
   match-device=interface-name:eth3

   Les propriétés suivantes sont supportés:

ignore-carrier Spécifie les périphérique pour lesquel NetworkManager va ignorer l'état carrier. Normalement, pour les périphériques qui supportent carrier-detect comme Ethernet et InfiniBand, NetworkManage n'autorise seulement à activer une connexion si carrier est présent (ex: un cable est connecté), et est désactivé si carrier est détruit plus de quelques secondes
wifi.scan-rand-mac-address Configure la génération aléatoire d'adresse MAC durant le scan. Défaut: yes.
wifi.scan-generate-mac-address-mask Tout comme les paramètres par connection ethernet.generate-mac-address-mask et wifi.generate-mac-address-mask, permet deconfigurer la génération aléatoire MAC durant le scan

Sections device

   Tout comme la section [connection], la section [device] fonctionne de manière similaire

[connectivity]

   Cette section contrôle la fonctionnalité de vérification de connectivité optionnelle de NetworkManager. Cela permet de détecter si le système peut accéder à internet ou s'il est derrière un portail captif.

uri L'URI d'une page web à requêter périodiquement. Cette page devrait retourner l'en-tête X-NetworkManager-Status avec une valeur "online". Alternativement, le corp peut être être définis à "NetworkManager is online".
interval Interval en secondes de vérification de la connectivité
response Contrôle la vérification du contenu du corps. Défaut: "NetworkManager is online"

[global-dns]

   Cette section configure les paramètres DNS globaux qui écrasent la configuration spécifique à une connection

search Liste de domaines de recherche
options Liste d'options à passer au résolveur

[global-dns-domain]

   Les sections commençant par "global-dns-domain-" autorisent une configuration DNS globale pour des domaines spécifiques. La partie du nom qui suit spécifie le nom du domaine auquelle la section s'applique.

servers Liste d'adresses de serveurs DNS à utiliser
options Liste d'options DNS spécifique au domaine

[.config]

   Section spéciale qui contient les options qui s'appliquent au fichier de configuration qui contient l'option

enable à false, le fichier de configuration n'est pas pris en compte durant le chargement. Défaut: true. Noter que le fichier principal NetworkManager.conf ne peut pas être désactivé

Plugins

keyfiles plugin générique qui supporte tous les types de connection et capacités de NetworkManager.
ifcfg-rh Utilisé sous Fedora et RedHat et lit et écris les configuration dans /etc/sysconfig/network-scripts/ifcfg-*. Activer ce module active également ibft. Utiliser no-ibft pour l'empêcher
ifcfg-suse Déprécié. Utiliser keyfile à la place
ifupdown Plugin pour les distributions Debian et Ubuntu.
ibft, no-ibft Permet de lire la configuration iBFT (iSCSI Boot Firmware Table). La configuration est lue avec /sbin/iscsiadm. Noter que ibft utilise /sbin/iscsiadm et donc nécessite CAP_SYS_ADMIN.

Format de listing de périphérique

Matche tous les périphériques
IFNAME match le nom de l'interface (sensible à la casse)
HWADDR Match l'adresse MAC du périphérique
interface-name-IFNAME, interface-name:~ IFNAME Match le nom de l'interface du périphérique. le globbing est supporté (* et ?). sensible à la casse
interface-name:=IFNAME Matche de nom de l'interface. Pas de globbing et sensible à la casse
mac:HWADDR Matche l'adresse MAC de l'interface
s390-subchannels:HWADDR Matche le périphérique basé sur l'adresse subchannel
type:TYPE Matche le type de périphérique
except:SPEC Match négatif de périphérique
SPEC[,;]SPEC Plusieurs SPECS peuvent être concaténés.

Exemples:
interface-name:em4
mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth2
interface-name:vboxnet*,except:interface-name:vboxnet2
*,except:mac:00:22:68:1c:59:b1
^
03 novembre 2011

htmlpdflatexmanmd




newgrp

newgrp

Permet de changer l’identifiant de groupe de l’utilisateur au cour d’une session

   Si - est fournie, l’environnement de l’utilisateur est réinitialisé, comme si l’utilisateur venait de se connecter. newgrp change l’identifiant de groupe réel, ou au groupe par défaut défini dans /etc/passwd si aucun groupe n’est spécifié. newgrp essayera également d’ajouter le groupe à l’ensemble des groupes de l’utilisateur.

  newgrp utilise des variables dans login.defs

^
07 mai 2017

htmlpdflatexmanmd




rewrole

rewrole

Lancer un shell avec un nouveau rôle SELinux

   Le nouveau contexte est dérivé de l'ancien contexte dans lequel newrole est exécuté. Si un rôle est spécifié mais pas le domaine, le type par défaut est dérivé du rôle spécifié par le niveau.

OPTIONS

-r, --role ROLE Spécifie le nouveau contexte
-t, --type TYPE Spécifie le nouveau domaine
-l, --level Spécifie le niveau ou plage
-p, --preserve-environment Préserve les variables d'environnment, sinon un nouvel environnement minimal est créé

Exemples

Changer de rôle
› id -Z
staff_u:staff_r:staff_t:SystemLow-SystemHigh
› newrole -r sysadm_r
› id -Z
staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
Changer la sensibilité
› id -Z
staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
› newrole -l Secret
› id -Z
staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
Changer la sensibilité
› id -Z
staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
› newrole -l Secret-Secret
› id -Z
staff_u:sysadm_r:sysadm_t:Secret
Lancer un programme d-ans un contexte et niveau donné:
› newrole -r sysadm_r -- -c "/path/to/app arg1 arg2..."
› newrole -l Secret -- -c "/path/to/app arg1 arg2..."
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/newrole_pam.conf

/etc/selinux/newrole_pam.conf

Configuration pour newrole

   Ce fichier est utilisé par la commande newrole et mappe les applications ou commandes en fichiers de configuration PAM. Chaque ligne contient le nom du fichier exécutable suivi par le nom d'un fichier de configuration pam qui existe dans /etc/pam.d

^
29 octobre 2011

htmlpdflatexmanmd




newusers

newusers

Met à jour ou créer de nouveaux utilisateurs par lots

   Lit un fichier contenant des paires de nom d'utilisateur et de mot de passe. Chaque ligne est au format (même format que passwd(5)):

  pw_name:pw_passwd:pw_uid:pw_gid:pw_gecos:pw_dir:pw_shell

pw_name Nom de l'utilisateur
pw_passwd Mot de passe en clair qui sera chiffré
pw_uid UID de l'utilisateur. Si vide, un UID non utilisé est choisi. Si un UID est changé, le propriétaire des fichiers devra être changé manuellement.
pw_gid GID de l'utilisateur. Si ce champ est un nombre, il devient le groupe primaire de l'utilisateur. Si ce GID n'existe pas, il est créé avec le nom de l'utilisateur. vide, un nouveau groupe est créé avec un GID disponible.
pw_gecos GECOS de l'utilisateur
pw_dir Répertoire personnel de l'utilisateur. S'il n'existe pas, il est créé, s'il est changé, il n'est pas déplacé.
pw_shell Shell de l'utilisateur.

   La première passe créé les utilisateurs avec un mot de passe désactivé, la seconde passe met à jours tous les mots de passe utilisant PAM.

OPTIONS

-r, --system Crée un compte système. les informations d'UID sont pris de SYS_UID_MIN et SYS_UID_MAX de /etc/login.defs

Configuration

les variables suivantes de login.defs sont utilisées:
GID_MAX, GID_MIN
MAX_MEMBERS_PER_GROUP
PASS_MAX_DAYS
PASS_MIN_DAYS
PASS_WARN_AGE
SYS_GID_MAX
SYS_GID_MIN
SYS_UID_MAX
SYS_UID_MIN
UID_MAX
UID_MIN
UMASK
^
05 décembre 2016

htmlpdflatexmanmd




nfs4_acl

nfs4_acl

Listes de contrôle d'accès NFSv4

Le format de sortie pour une ACL NFSv4 est:
A::OWNER@:rwatTnNcCy
A::alice@nfsdomain.org:rxtncy
A::bob@nfsdomain.org:rwadtTnNcCy
A:g:GROUP@:rtncy
D:g:GROUP@:waxTC
A::EVERYONE@:rtncy
D::EVERYONE@:waxTC

Format d'ACL

   une ACL NFSv4 est écrite comme une acl_spec, consistant d'une ou plusieurs ace_specs. Une simple ACE NFSv4 est une ace_spec de 4 champs sous la forme: type:flags:principal:permissions

Types d'ACE

A Allow - autorise un principal à effectuer les actions
D Deny - Empêche le principal d'effectuer des actions
U Audit - Log toute tentative d'accès par un principal nécessitant les permissions.
L Alarm - génère une alarme système à une tentative d'accès

Flags d'ACE

   Il y a 3 types de flags: groupe, héritage et administration. Noter que les ACE sont hérités de l'ACL du répertoire parent à leur création.

Flags de groupe

        g groupe -indique que le principal représente un groupe

Flags d'héritage

        d Les sous-répertoires créés héritent de l'ACE
        f Les fichier créé héritent de l'ACE, sans les flags d'héritage.
        n Les sous-répertoires créé héritent de l'ACE, sans les flags d'héritage
        i L'ACE n'est pas considérée dans les vérifications de permissions, mais sont héritables; cependant, ce flag est supprimé des ACE héritées

Flags d'administration

        S Déclenche une alarm/audit quand le principal est autorisé à effectuer une action couverte par les permissions
        F Déclenche une alarm/audit quand le principal n'est pas autorisé à effectuer une action couverte par les permissions

Principaux d'ACE

   Un principal est soit un utilisateur nommé, soit un groupe, ou un des 3 principaux spéciaux: OWNER@, GROUP@, et EVERYONE@, qui représentent les distinctions POSIX.

Permissions d'ACE

r fichier: lire les données / répertoire: lister le contenu
w fichier: écrire des données / répertoire: Créer des fichiers
a fichier: Ajouter des données / répertoire: Créer des sous-répertoires
x fichier: Exécuter / répertoires: Changer de répertoire
d Supprime le fichier/répertoire.
D répertoire: supprimer les fichiers et sous-répertoires.
t Lire les attributs du fichier/répertoire
T Changer les attributs du fichier/répertoire
n Lire les attributs nommés du fichier/répertoire
N Changer les attributs nommés du fichier/répertoire
c Lire les ACL
C Changer les ACL
o Changer le propriétaire du fichier/répertoire
y Autorise les clients à utiliser les E/S synchrones avec le serveur.

Flags d'héritage

   Les flags d'héritage peuvent être divisés en 2 catégories: primaire (héritage fichier/répertoire) et secondaires (pas de propagation d'héritage et héritage uniquement), qui sont seulement significatifs dans la mesure où ils affectent les 2 flags primaires.

   Les flags no-propagate-inherit et inherit-only peuvent être difficiles à retenir: le premier détermine si l'ACE hérité d'un nouveau répertoire enfant est lui-même héritable; le second détermine si une ACE héritable affecte le répertoire parent (en plus d'être héritable). Ils peuvent être utilisés en tandem.

   Quand un sous-répertoire hérite d'une ACE de l'ACL du répertoire parent, cela peut être fait de 2 manières différentes dépendant de l'implémentation du serveur:

        - Dans le premier cas, la même ACE est définis dans l'ACL du sous-répertoire
        - Dans le second cas, 2 ACE différentes sont définis dans l'ACL du sous-répertoire: un avec tous les flags d'héritage enlevés, et un avec le flag inherit-only. Cette approche simplifie la modification des droits d'accès aux sous-répertoire lui-même sans modifier les ACE héritables.

Accès refusés

   les ACE deny devraient être évités autant que possible, cela augmente la confusion et la complexité. L'ordre des ACE est importante, et en dépit de l'ambiguïté de la rfc3530, les permissions non explicitement autorisées sont refusées.
^
05 décembre 2016

htmlpdflatexmanmd




nfs4_getfacl

nfs4_getfacl

Obtenir les listes de contrôle d'accès sur un système de fichier NFS monté

   nfs4_getfacl permet d'afficher la liste de contrôles d'accès d'un fichier ou répertoire dans un système de fichier NFSv4 monté et supportant le contrôle d'accès.

^
05 décembre 2016

htmlpdflatexmanmd




nfs4_setfacl

nfs4_setfacl, nfs4_editfacl

Manipuler les ACL NFSv4

Commandes

-a acl_spec [index] ajoute les ACE depuis acl_spec à l'ACL du fichier. Les ACE sont ajoutées à l'index donné. Défaut: 1
-A acl_file [index] ajoute les ACE depuis le fichier acl_file à l'ACL du fichier. Les ACE sont insérées à l'index donné. Défaut: 1
-x acl_spec | index supprime les ACE correspondantes à acl_spec, ou à l'index donné.
-X acl_file Supprime les ACE correspondantes à acl_spec dans le fichier acl_file.
-s acl_spec Définis l'ACL du fichier à acl_spec
-S acl_file Définis l'ACL du fichier à acl_spec du acl_file
-e, --edit Édite l'ACL du fichier dans l'éditeur définis par la variable d'environnement EDITOR, et définis l'ACL résultante en quittant l'éditeur
-m from_ace to_ace Modifie l'ACL du fichier en remplaçant from_ace avec to_ace

Notes

   Si '-' est donné avec -A -X ou -S, lit acl_spec depuis stdin

OPTIONS

-R, --recursive Applique les changement récursivement
-L, --logical Avec -R, suit les liens symboliques
-P, --physical Avec -R, ne suit pas les liens
--test Affiche le résultat au lieu de modifier effectivement l'ACL

Alias de permissions

   "read"(R), "write"(W) et "execute"(X) peuvent être utilisés pour définir les permissions. R vaut "rntcy", W vaut "watTNcCy" et X "xtcy"

Exemples

Assumant l'ACL suivante du fichier foo:
A::OWNER@:rwatTnNcCy
D::OWNER@:x
A:g:GROUP@:rtncy
D:g:GROUP@:waxTC
A::EVERYONE@:rtncy
D::EVERYONE@:waxTC
Autoriser alice@nfsdomain.org les accès "read" et "execute"
nfs4_setfacl -a A::alice@nfsdomain.org:rxtncy foo
idem, en utilisant les alias
nfs4_setfacl -a A::alice@nfsdomain.org:RX foo
Éditer l'ACL
nfs4_setfacl -e foo
Définir l'ACL depuis l'ACL d'un fichier
nfs4_setfacl -S newacl.txt foo
Définir récursivement les ACL à tous les fichiers et sous-répertoires du répertoire courant sans suivre les liens
nfs4_setfacl -R -P -S newacl.txt *
Suprimer la première ACE et afficher le résultat sans les changer
nfs4_setfacl --test -x 1 foo
Supprimer les 2 dernières ACE
nfs4_setfacl -x "A::EVERYONE@rtncy, D::EVERYONE@:waxTC" foo
Modifier la 2ème ACE
nfs4_setfacl -m D::OWNER@:x D::OWNER@:xo foo
Définir les ACL de bar et frobaz à l'ACL de foo
nfs4_getfacl foo | nfs4_setfacl -S - bar frobaz
^
03 décembre 2016

htmlpdflatexmanmd




nfsd

nfsd, rpc.nfsd

Serveur nfs

   rpc.nfsd implémente la partie utilisateur du service NFS. La fonctionnalité principale est gérée par le module kernel nfsd. Le programme userspace spécifie quel type de socket le service kernel doit écouter, la version NFS q'uil devrait supporter, et le nombre de thread que le kernel devrait utiliser.

OPTIONS

-d, --debug Active le debug
-H, --host Spécifie un nom d'hôte particulier ou adresse d'écoute
-p, --port Port d'écoute. Défaut: 2049
-r, --rdma Active l'écoute des requêtes NFS rdma
--rdma=port Port RDMA. Défaut: 20049
-N, --no-nfs-version vers Permet de limiter le supporte de NFS à certaines versions
-s, --syslog log les messages dans syslog au lieu de stderr
-T, --no-tcp Désactive les connexions TCP pour les clients
-U, --no-udp Désactive les connexions UDP pour les clients
-V, --nfs-version vers Permet de limiter le supporte de NFS à certaines versions
-L, --lease-time lease-time nfsv4, en seconde (entre 10 et 3600). délai pour les client pour confirmer leur état avec le serveur
-G, --grace-time grace-time nfsv4. Les requêtes de fichier ouvert et les NLM ne sont pas autorisés passé ce délay pour permettre au client de récupérer l'état.
nproc Spécifie le nombre de threads nfs. Défaut: 1 thread.
^
08 décembre 2016

htmlpdflatexmanmd




nfsdcltrack

nfsdcltrack

Programme de suivi d'appel client NFS

   nfsdcltrack est un programme côté serveur, qui suit les appels clients. Quand une partition réseau est combinée avec un reboot serveur, il y a des conditions qui peuvent permettre au serveur d'autoriser des réclamations de lock quand d'autres clients ont des conflits de lock (rfc3530 et rfc5661). Pour empêcher ces problèmes, le serveur doit garder une trace des informations client. nfsdcltrack fournis cette fonctionnalité

OPTIONS

-d, --debug Active le debug
-F, --foreground Ne lance pas en tâche de fond
-s storagedir, --storagedir=storagedir Répertoire où les informations de stockage stable devraient être conservés. Défaut: /var/lib/nfs/nfsdcltrack

Commandes

init Initialise la base
create Créé un nouvel enregistrement client ou met à jours l'horodatage d'un client existant. Nécessite un nfs_client_id4 en argument, en hexa
remove Supprime un enregistrement client de la base. Nécessite un nfs_client_id4 en argument, en hexa
check Vérifie si un nfs_client_id4 est autorisé à réclamer. Nécessite un nfs_client_id4 en argument, en hexa
check gracedone
Supprime tout enregistrement client non-réclamé de la base. Nécessite un délai de boot epoch en argument.

Configuration externe

Le répertoire pour les informations de stockage stable peut être définis via le fichier /etc/nfs.conf en définissant la valeur storagedir dans la section nfsdcltrack:
[nfsdcltrack]
storagedir = /shared/nfs/nfsdcltrack
^
05 décembre 2016

htmlpdflatexmanmd




nfsidmap

nfsidmap

Programme idmapper NFS

   Le protocole NFSv4 représente les valeurs UID/GID du système local en chaîne sous la forme user@domain. Le processus de traduction s'appèle l'ID mapping.

   Le système dérive la partie de la chaîne en effectuant une recherche password ou group. Le mécanisme de recherche est configuré dans /etc/idmapd.conf. Par défaut, la partie de la chaîne est le nom de domaine du système.

OPTIONS

-c Efface le keyring du toutes les clés
-d Affiche le nom de domaine NFSv4 effectif du système
-g user Révoque la clé gid du l'utilisateur donné
-l Affiche toutes les clé dans le keyring. Uniquement pas root
-r user Révoque la clé uid et gid de l'utilisateur donné
-t timeout Définis le délai d'expiration en secondes de la clé. Défaut: 600 secondes
-u user Révoque l'uid de l'utilisateur donné
-v Mode verbeux. Peut être spécifié plusieurs fois

Configuration

Le fichier /etc/request-key.conf peut être modifié pour que /sbin/sequest-key puisse diriger correctement les upcall. La ligne suivante peut être ajoutée avant qu'un call à keyctl échoue:
create id_resolver    *    *    /usr/sibn/nfsidmap -t 600 %k %d
Cela redirige toutes les requêtes id_resolver à nfsidmap.

   Le système idmapper utilise 4 descriptions de clé:

        uid Trouver l'UID pour l'utilisateur donné
        gid Trouver le GID pour le groupe donné
        user Trouver le username pour l'UID donné
        group Trouver le groupname pour le GID donné

On peut les gérer individuellement:
create id_resolver uid:*    *    /some/other/program %k %d
create id_resolver    *    *    /usr/sbin/nfsidmap %k %d
^
03 décembre 2016

htmlpdflatexmanmd




nfsiostat

nfsiostat

Émule iostat pour les points de montage NFS en utilisant /proc/self/mountstats

‹interval› Délai en seconde entre chaque rapport
‹count› Si spécifié, nombre de rapport à générer
‹options› voir plus bas
‹mount_point› affiche les statistiques sur les points de montage spécifiés

OPTIONS

-a, --attr Affiche des statistiques relatives au cache d'attributs
-d, --dir Affiche des statistiques relatives aux opérations de répertoire
-l, --list=LIST Affiche seulement des statistiques pour les points de montages spécifiés
-p, --page Affiche des statistiques relatives au cache de pages
-s, --sort Trie les points de montage par ops/secondes

Champs

op/s Nombre d'opérations par secondes
rpc bklog Longueur de file de backlog
kB/s Nombre de ko écris/lus par seconde
kB/op Nombre de Ko de écris/lus par opération
retrans Nombre de retransmissions
avg RTT (ms) Durée entre le moment où le kernel du client envoie la requête RPC jusqu'à la réception de la réponse
avg exe (ms) Durée depuis le moment où le client NFS envoie une requête RPC à son kernel jusqu'à ce que la requête RPC soit complétée, incluant le temp RTT
^
03 décembre 2016

htmlpdflatexmanmd




nfsstat

nfsstat

Statistiques NFS

OPTIONS

-s, --server Affiche les statistiques côté serveur
-c, --client Affiche les statistiques côté client
-n, --nfs Affiche seulement les statistiques NFS
-2 uniquement les statistiques nfsv2
-3 uniquement les statistiques nfsv3
-4 uniquement les statistiques nfsv4
-m, --mounts Affiche des statistiques sur chaque système de fichier NFS monté
-r, --rpc Affiche seulement les statistiques RPC
-o facility Affiche les statistiques pour les facilités spécifiées:

        nfs Information du protocole NFS
        rpc Informations générales RPC
        net Statistiques niveau réseau.
        fh Informations sur le cache de gestion de fichier du serveur
        rc Informations sur le cache de réponse du serveur
        io Informations sur l'utilisation E/S
        ra Informations sur le cache readhead
        all Affiche tout

-v, --verbose Équivalent à -o all
-l, --list Affiche les informations sous forme de liste
-S, --since file Importe les statistiques depuis le fichier spécifié et affiche la différence avec les statistiques actuelles. (/proc/net/rpc/nfs pour les statistiques client) et (/proc/net/rpc/nfsd pour les statistiques serveur)
-Z[interval], --sleep=[interval] prend un snapshot des statistiques courantes, et s'arrête jusqu'à SIGINT, puis prend un second snapshot et affiche les différences. Si un interval en seconde est spécifié, attend ce délai.

Exemples

Afficher toutes les informations sur NFS:
nfsstat -o all -234
idem:
nfsstat --verbose -234
Afficher des informations sur les versions actives de NFS:
nfsstat -o all
Afficher des statistiques du serveur nfsv3
nfsstat --nfs --server -3
afficher des informations sur les systèmes de fichiers nfs montés
nfsstat -m
^
23 mai 2010

htmlpdflatexmanmd




nice

nice

Lance un processus avec une priorité spécifique. La priorité d'un processus va de -20 (la plus haute priorité) à 19 (priorité la plus faible)

   Les valeurs négatives ne peuvent être utilisées que par root.

Codes de sortie

0 si aucune commande n'est spécifiée
1 si nice lui-même a échoué
126 si la commande est trouvée mais ne peut pas être invoquée
127 si la commande ne peut pas être trouvée
^
05 juin 2010

htmlpdflatexmanmd




nl

nl

Écrit chaque fichier ou l'entrée standard sur la sortie standard, et ajoute les numéros de ligne à certaines ou toutes les lignes.

   nl décompose son entrée en pages. Par défaut, le numéro de ligne est remis à 1 en haut de chaque page. nl traite tous les fichiers en entrée comme un simple document, il ne reset pas les numéros de lignes entre les fichiers.

  Une page consiste en 3 sections : header, body et footer. Il peut y'avoir des sections vides. Chacune peut être numérotée dans un style différent.

  Le début de chaque section des pages est indiqués dans le fichier d'entrée par une ligne contenant un de ces délimiteur :

        \ :\ :\ : début du header
        \ :\ : début du body
        \ : début du footer

OPTIONS

-b STYLE, --body-numbering=STYLE Selectionne le style de numérotation des lignes pour la section body :

        a numérote toutes les lignes
        t Numérote seulemet les lignes non vide
        n ne numérote pas les lignes
        pBRE numérote uniquement les lignes qui contiennent une correspondance de l'expression régulière BRE

-d CD, --section-delimiter=CD Définis les caractères de délimitation des sections.
-f STYLE, --footer-numbering=STYLE identique à -b mais pour la section footer
-h STYLE, --header-numbering=STYLE identique à -b mais pour la section header
-i NUMBER, --page-increment=NUMBER Incrémente les numéros de ligne par NUMBER (défaut : 1)
-l NUMBER, --join-blank-lines=NUMBER NUMBER lignes vide consécutives sont considérées comme une seule (défaut : 1), et n'en numérote qu'une seule. Une ligne vide ne contient aucun caractère, y compris de caractères blanc.
-n FORMAT, --number-format=FORMAT Sélectionne le format de numérotation de ligne (défaut : rn)

        ln justifié à gauche
        rn justifié à droite
        rz justifié à droite et remplit de zéro.

-p, --no-renumber Ne reset pas le numéro de ligne au début d'une page.
-s STRING, --number-separator=STRING Sépare le numéros de ligne du texte avec STRING (défaut : TAB)
-v NUMBER, --starting-line-number=NUMBER Définit le numéro de ligne initial sur chaque page à NUMBER (défaut 1)
-w, --number-width=NUMBER Utilise NUMBER caractères pour les numéros de lignes (défaut : 6)
^
05 mai 2017

htmlpdflatexmanmd




nm-online

nm-online

Indiquer si le réseau est connecté

   nm-online est un utilitaire qui cherche à savoir si vous être online. C'est fait en demandant à NetworkManager son status.

OPTIONS

-t, --timeout Délai d'attente pour une connexion. défaut: 30 secondes
-x, --exit Quitte immédiatement si NetworkManager ne fonctionne pas ou se connecte
-q, --quiet N'affiche rien
-s, --wait-for-startup Attend que NetworkManager ait complété son démarrage.

Codes de sortie

0 Succès - déjà online ou connexion établie durant le timeout
1 offline
2 Erreur inattendue
^
12 mai 2017

htmlpdflatexmanmd




nm-settings

nm-settings

Paramètres et propriétés des profiles de connexion NetworkManager

   NetworkManager est basé sur un concept de profiles de connexion. Les profiles de connexions sont gérés par NetworkManager via le services de paramètres et sont exportés sur D-Bus.

802-1x

altsubject-matches (tableau de chaînes) Liste de chaînes à matcher avec le altSubjectName du certificat présenté par le serveur d'authentification. vide, aucune vérification n'est effectuée. Défaut: vide
anonymous-identity (chaîne) identité anonyme pour les méthodes d'authentification EAP. Utilisé comme identité non-chiffrée avec les type EAP qui supportent différentes identités tunnelisées come EAP-TTLS
ca-cert (chaîne d'octets) Contient le certificat CA utilisé par la méthode EAP spécifié dans la propriété eap.
ca-path (chaîne) chemin d'un répertoire contenant les certificats à ajouter à la chaîne de vérification
client-cert (chaîne d'octets) Contient le certificat client utilisé par la méthode EAP spécifiée dans la propriété eap
domain-suffix-match (chaîne) Contrainte pour le nom de domaine. Si définis, ce FQDN est utilisé comme suffixe requis pour les éléments dNSName du certificat présenté par le serveur d'authentification.
eap (tableau de chaînes) La méthode EAP permise pour l'authentification avec 802.1x. (leap, md5, tls, peap, ttls, pwd fast).
identity (chaîne) Identité pour les méthodes d'authentification. Généralement le login
name (chaîne) Nom du paramètre qui identifie le paramètre dans la connexion. Chaque type de paramètre a un nom unique pour ce type, par exemple ppp, wireless, wired. Défaut: 802-1x
pac-file (chaîne) Chemin du fichier contenant PAC pour EAP-FAST
password (chaîne) mot de passe pour les méthodes l'authentification EAP. A précédence sur 'password-raw'
password-flags (NMSettingSecretFlags) Flags indiquant comment manipuler la propriété password
password-raw (tableau d'octets) Mot de passe utilisé par les méthodes d'authentification EAP.
password-raw-flags (NMSettingSecretFlags) Flags indiquant comment manipuler la propriété password-raw
phase1-fast-provisionning (chaîne) active/désactive le provisionning in-line des accréditifs EAP-FAST quand FAST est spécifié comme méthode EAP. (0-désactivé, 1-provisionning non-authentifié, 2-provisionning authentifié, 3-provisionning authentifié et non authentifié)
phase1-peaplabel (chaîne) Force l'utilisation du nouveau label PEAP durant la dérivation de clé. Certains serveurs RADIUS peuvent l'exiger pour interopérer avec PEAPv1.
phase1-peapver Version PEAP à utiliser. Non définis, la version donné par le serveur est utilisé. (0 ou 1)
phase2-altsubject-matches (tableau de chaînes) Liste de chaîne à matche avec le altSubjectName du certificat présenté par le serveur d'authentification durant la phase 2. vide, aucune vérification n'est effectuée
phase2-auth (chaîne) Spécifie les méthodes d'authentification non-EAP de la phase 3 quand EAP utilise un tunnel TLS (pap, chap, mschap, mschapv2, gtc, otp, md5, tls).
phase2-autheap (chaîne) Spécifie les méthodes d'authentification EAP de la phase 2 quand la méthode EAP utiliser un tunnel TLS. (md5, mschapv2, otp, gtc, tls).
phase2-ca-cert (tableau d'octets) Contient le certificat CA de la phase 2.
phase2-ca-path (chaîne) répertoire contenant les certificats additionnels
phase2-client-cert (tableau d'octets) Contient le certificat client de la phase 2.
phase2-domain-suffix-match (chaîne) Contraint le nom de domaine du serveur. ce FQDN est un suffixe à matcher dans dNSName du certificat présenté par le serveur d'authentification.
phase2-private-key (tableau d'octets) Contient la clé privée de la phase 2 quand phase2-auth ou phase2-autheap est à 'tls'.
phase2-private-key-password [chaîne) mot de passe utilisé pour déchiffrer la clé privée
phase2-private-key-password-flags (NMSettingSecretFlags) Flags indiquant comment gérer la propriété phase2-private-key-password.
phase2-subject-match (chaîne) sous-chaîne à matcher avec le sujet du certificat présenté par le serveur d'authentification durant la phase2.
pin (chaîne) PIN utilisé pour les méthodes d'authentification EAP
pin-flags (NMSettingSecretFlags) Flags indiquant comme gérer la propriété pin.
private-key (tableau d'octets) Contient la clé privée quand la propriété eap est à 'tls'.
private-key-password (chaîne) mot de passe pour déchiffrer la clé privée
private-key-password-flags (NMSettingSecretFlags) flags indiquant comme gérer la propriété private-key-password.
subject-match (chaîne) sous-chaîne à matcher avec le sujet du certificat présenté par le serveur d'authentification. déprécié en faveur de NMSetting8021x:domain-suffix-match
system-ca-certs (bool) à TRUE, écrase ca-path et phase2-ca-path en utilisant le répertoire CA système spécifié à la configuration avec --system-ca-path.

adsl

encapsulation (chaîne) Encapsulation de la connexion ADSL. (vcmux ou llc)
name (chaîne) nom du paramètre, qui identifie de manière unique le paramètre dans la connexion. défaut: adsl
password (chaîne) mot de passe utilisé pour authentifier le service ADSL
password-flags (NMSettingSecretFlags) flags indiquant comme gérer la propriété password
protocol (chaîne) protocole de connexion ADSL (pppoa, pppoe, ou ipoatm)
username (chaîne) username pour l'authentification
vci (uint32) VIC de la connexion ADSL
vpi (uint32) VPI de la connexion ADSL

bluetooth

bdaddr (tableau d'octets) l'adresse bluetooth du périphérique
name (chaîne) nom du paramètrage: bluetooth
type (chaîne) soit 'dun' pour Dial-Up Networking ou 'panu' pour Personnal Area Networking

bond

interface-name (chaîne) déprécié en faveur de connection.interface-name.
name (chaîne) nom du paramétrage (bond)
options (dictionnaire) dictionnaire de paires clé/valeurs d'option bonding. défaut: {'mode':'balance-rr'}

bridge

ageing-time (uint32) temps en seconde de la durée de l'adresse MAC ethernet. défaut: 300
forward-delay (uint32) forwarding delay STP, en secondes. Défaut: 15
hello-time (uint32) hello time STP, en secondes. défaut: 2
interface-name (chaîne) déprécié en faveur de connection.interface-name
mac-address (tableau d'octets) si spécifié, l'adresse mac du commutateur.
max-age (uint32) amximum message age STP, en secondes. défaut: 20
multicast-snooping (bool) contrôle si IGMP snooping est activé pour ce commutateur.
name (chaîne) nom du paramétrage: bridge
priority (uint32) Priorité STP du bridge. défaut: 32768
stp (bool) Active STP.

bridge-port

hairpin-mode (bool) Active le mode hairpin pour le port, les frames sont renvoyés via le port ou la frame a été reçue
name (chaîne) nom du paramètrage = bridge-port
path-cost (uint32) port cost STP pour les destinations via ce port
priority (uint32) priorité STP de ce port

cdma

name (chaîne) nom du paramètrage: cdma
number (chaîne) numéro à composer pour établir la connexion au réseau mobile CDMA. défaut: #777
password (chaîne) mot de passe pour l'authentification
password-flags (NMSettingSecretFlags) Flags indiquant comment manipuler la propriété password
username (chaîne) username pour l'authentification

connection

autoconnect (bool) si la connexion est automatiquement connectée par NetworkManager quand les ressources pour la connexion sont disponibles. Défaut: TRUE
autoconnect-priority (int32) Priorité autoconnect. défaut: 0
autoconnect-retries (int32) nombre de tentatives de connexions durant l'autoactivation. 0 signifie indéfiniment, -1 et le défaut global (4 fois si non modifié)
autoconect-slaves (NMSettingConnectionAutoconnectSlaves) Si ou non les esclaves de cette connexion devraient être automatiquement activés. 0-non, 1-activer les connexions esclave, -1-défaut.
gateway-ping-timeout (uint32) › à 0, délais du succès de l'addressage IP jusqu'à que le timeout soit atteint, ou une réponse d'une gateway à un ping
id (chaîne) identifiant unique pour la connection
interface-name (chaîne) nom de l'interface réseau à laquelle la connexion est lié
lldp (int32) Si lldp est activé pour la connexion. Défaut:-1
master (chaîne) Nom de l'interface du périphérique maître ou l'uuid de la connexion maître
metered (NMMettered) Si la connexion est mesurée
name (chaîne) Nom du paramètrage: connection
permissions (tableau de chaînes) Tableau définissant l'accès d'un utilisateur à cette connexion. Vide, tous les utilisateurs sont autorisés à accéder à cette connexion. Chaque entrée est sous la forme "[type]:[id]:[reserved]". Actuellement seul le type "user" est utilisé.
read-only (bool) indique si la connexion peut être modifié en utilisant D-Bus (FALSE), ou non (TRUE)
secondaries (tableau de chaînes) Liste d'UUID de connexions qui devraient être activés quand la connexion de base elle-même est activée. Actuellement seul les connexions VPN dont supportés
slave-type (chaîne) nom du paramètre du type de périphurique de cette commexion maître (ex: bond0) ou NULL si cette connexion n'est pas un esclave
stable-id (chaîne) Tocken pour générer des ID stable pour la connexion. Il est utilisé pour générer des IPv6 privées stable avec ipv6.addr-gen-mode=strable-privacy. Également utilisé pour émettre l'adresse MAC cloné générée pour ethernet.cloned-mac-address=stable et wifi.cloned-mac-address=stable. Spécifie un stable-id permet à plusieurs connexions de générer les même adresses. Il est possible de générer des ID via des substitution: ${CONNECTION}, ${BOOT}, ${RANDOM}.
timestamp (uint64) Temps en seconde depuis l'Epock, que la connection a été activée avec succès. MetworkManager met à jours cette valeur périodiquement.
type (chaîne) Type de base de la connexion. Pour les connexions dépendantes du hardware, devrait contenir le nom du paramètre du type de matériel (ex: 802-3-ethernet, 802-11-wireless, bluetooth, etc.), et pour les connexions non hardware, devrait contenir le nom du type de paramètre (vpn, bridge, etc.)
uuid (chaîne) Identifiant unique pour la connexion. Devrait être assigné à la création de la connexion, et ne devrait jamais être changé.
zone (chaîne) Niveau de confiance de la connexion. texte lible insensible à la casse (ex: Home, Work, Public). NULL ou non spécifié, la connexion sera placée dans la zone par défaut tel que définis par le firewall.

dcb

app-fcoe-flags (NMSettingDcbFlags) Flags pour l'application FCoE DCB. Peut être une combinaison de NM_SETTINGS_DCB_FLAG_ENABLE(0x1, NM_SETTING_DCB_FLAG_ADVERTISE (0x2), et NM_SETTING_DCB_FLAG_WILLING (0x4)
app-fcoe-mode (chaîne) Mode contrôleur FCoE; soit "fabric" ou "vn2vn"
app-fcoe-priority (int32) Priorité la plus élevée (0-7) à utiliser pour les frames FCoE, ou -1 pour la priorité par défaut
app-fip-flags (NMSettingDcbFlags) Flags pour l'application DCB FIP. peut être une combinaison de NM_SETTINGS_DCB_FLAG_ENABLE(0x1, NM_SETTING_DCB_FLAG_ADVERTISE (0x2), et NM_SETTING_DCB_FLAG_WILLING (0x4)
app-fip-priority (int32) Priorité la plus élevée (0-7) à utiliser pour les frames FIP, ou -1 pour la priorité par défaut
app-iscsi-flags (NMSettingDcbFlags) Flags pour l'application DCB iSCSI. peut être une combinaison de NM_SETTINGS_DCB_FLAG_ENABLE(0x1, NM_SETTING_DCB_FLAG_ADVERTISE (0x2), et NM_SETTING_DCB_FLAG_WILLING (0x4)
app-iscsi-priority (int32) Priorité la plus élevée (0-7) à utiliser pour les frames iSCSI, ou -1 pour la priorité par défaut
name (chaîne) Nom du paramètrage: dcb
priority-bandwidth (tableau de uint32) Tableau de 8 valeurs uint, où l'indexe correspond à la priorité utilisateur (0-7), et la valeur indique le pourcentage de bande passante du groupe assigné à la priorité. La somme de tous les pourcentages doit faire 100%
priority-flow-control (tableau de uint32) Tableau de 8 booléens œu l'indexe correspond à la priorité utilisateur (0-7) et la valeur indique si la priorité devrait transmettre une pause de priorité
priority-flow-control-flags (NMSettingDcbFlags) flags pour DCP PFC (Priority Flow Control). peut être une combinaison de NM_SETTINGS_DCB_FLAG_ENABLE(0x1, NM_SETTING_DCB_FLAG_ADVERTISE (0x2), et NM_SETTING_DCB_FLAG_WILLING (0x4)
priority-group-bandwidth (tableau de uint32) Tableau de 8 valeurs uint, où l'indexe correspond à la priorité de groupe (0-7), et la valeur indique le pourcentage de bande passante allouée à ce groupe. La somme de tous les pourcentages doit faire 100%
priority-group-flags (NMSettingDcbFlags) Flags pour DCB Priority Groups. peut être une combinaison de NM_SETTINGS_DCB_FLAG_ENABLE(0x1, NM_SETTING_DCB_FLAG_ADVERTISE (0x2), et NM_SETTING_DCB_FLAG_WILLING (0x4)
priority-group-id (tableau de uint32) Tableau de 8 valeurs uint, où l'indexe correspond à la priorité utilisateur (0-7), et la valeur indique le Priority Group ID. Les priorité permisses sont 0-7, ou 15 pour le groupe non restreint.
priority-strict-bandwidth (tableau de uint32) Tableau de 8 booléens œu l'indexe correspond à la priorité utilisateur (0-7) et la valeur indique si la priorité peut utiliser toute la bande passante allouée au groupe assigné
priority-traffic-class (tableau de uint32) Tableau de 8 valeurs uint, où l'indexe correspond à la priorité utilisateur (0-7), et la valeur indique la classe de trafique (0-7) pour laquelle la priorité est mappée

generic

name (chaîne) Nom du paramètrage, qui identifie de manière unique les paramètres dans la connexion.

gsm

apn (chaîne) Nom du point d'accès GPRS spécifiant l'APN utilisé pour établis une session de données avec le réseau GSM.
device-id (chaîne) Identifiant unique de périphérique (tel que donné par le service de gestion WWAN)
home-only (bool) à TRUE, seuls les connexions au réseau personnel est autorisé. Les connexions aux réseaux roaming ne sont pas faites. Défaut: FALSE
name (chaîne) Nom du paramétrage: gsm
network-id [chaîne) ID réseau (format GSM LAI, ex: MCC-MNC) pour forcer un enregistrement spécifique.
number (chaîne) Numéro à composer pour établir une session de données PPP.
password (chaîne) Mot de passe utilisé pour l'authentification avec le réseau.
password-flags (NMSettingSecretFlags) flags indiquand comment gérer la propriété password
pin (chaîne) Si la SIM est blockée avec un PIN, elle doit être débloquée avec un PIN
pin-flags (NMSettingSecretFlags) Flags indiquant comment gérer la propriété pin
sim-id (chaîne) identifiant unique de carte SIM
sim-operator-id (chaîne) chaîne MCC/MNC comme "310260" ou "21601" identifiant l'opérateur mobile.
username (chaîne) username utilisé pour l'authentification sur le réseau.

infiniband

mac-address (tableau d'octets) Si spécifié, cette connexion ne s'applique qu'au périphérique IPoIB dont l'adresse mac correspond. Cette propriété ne change pas l'adresse MAC
mtu (uint32) non 0, ne transmet que les paquets de la taille spécifiée ou inférieur, splittant les paquets plus gros en plusieurs frames.
name (chaîne) Nom du paramétrage: infiniband
p-key (int32) P_Key infiniband à utiliser pour ce périphérique. -1 utilise le P_Key par défaut (à l'index 0)
parent (chaîne) nom de l'interface du périphérique parent de ce périphérique. Normalement NULL, sauf si p_key est définis.
transport-mode (chaîne) Mode IPoIB (datagram ou connected)

ipv4

address-data (tableau d'ipv4) tableau d'IPv4. Chaque dictionnaire d'adresse contient au moins les entrées 'address', et 'prefix'
addresses (tableau de tableau de uint32) déprécié en faveur de address-data et gateway
dad-timeout (int32) Timeout en ms utilisé pour vérifier la présence d'adresse IP dupliquées
dhcp-client-id (chaîne) chaîne envoyée au serveur DHCP pour identifier la machine
dhcp-fqdn (châine) Si la propriété dhcp-send-hostname est à TRUE, le fqdn spécifié sera envoyé au serveur DHCP en acquérant le bail. exlusif avec dhcp-hostname.
dhcp-hostname (chaîne) si dhcp-send-hostname est à true, le nom spécifié ici est envoyé au serveur DHCP
dhcp-send-hostname (bool) à true, envoie le hostname au serveur DHCP
dhcp-timeout (int32) timeout de transaction DHCP, en secondes. Défaut: 0
dns [tableau d'uint32) tableau d'adresses IP des serveurs DNS
dns-options (tableau de chaînes) tableau d'options DNS tel que décris dans man resolv.conf. NULL utilise les valeurs par défaut
dns-priority (int32) Priorité DNS intra-connexion. La priorité relative est utilisée pour déterminer l'ordre des serveurs DNS dans resolv.conf. Une valeur faible place les serveurs en haut du fichier. Défaut: 0, qui sélectionne la valeur par défaut: 50 pour VPN, et 100 pour les autres connexions.
dns-search (tableau de chaîne) tableau de domaines de recherche DNS
gateway (chaîne) La passerelle associée avec cette configuration
ignore-auto-dns (bool) Quand method est à auto et cette propriété à TRUE, les serveurs de nom et domaines de recherche automatiquement configurés sont ignorés et seuls les serveurs et domaines spécifiés dans les propriétés dns et dns-search sont utilisés.
ignore-auto-routes (bool) si method est à 'auto' et cette propriété à TRUE, les routes automatiquement configurées son ignorées et seules les routes dans la propriété routes sont utilisées
may-fail (bool) à TRUE, autorise la configuration réseau même si le fichier de configuration spécifié par cette propriété échoue au timeout. Noter qu'au moins une configuration IP doit réussir our la configuration réseau générale échoue.
method (chaîne) Méthode de configuration IP 'auto', 'manual', 'link-local', et 'shared'
name (chaîne) Nom du paramétrage: ipv4
never-default (bool) à TRUE, cette connexions n'est jamais la connexion par défaut pour ce type IP, ce qui signifie que la route par défaut n'est jamais assignée
route-data (tableau de dictionnaire) Tableau de routes IPv4. Chaque dictionnaire de route contient au moins les entrées 'dest' et 'prefix'. La plupart des routes ont également une entrée 'gateway'
route-metric (int64) Métrique par défaut pour les routes qui n'en spécifient pas une explicite. Défaut: -1 signifiant que la métrique est choisie automatiquement basé sur le type de périphérique.
routes (tableau de tableau d'uint32) Déprécié en faveur de route-data

ipv6

addr-gen-mode (int32) Configure la méthode pour créer l'adresse rfc4862: eui64 ou stable-privacy (rfc7217)
address-data (tableau de dictionnaire) Tableau d'IPv6. chaque entrée contient au moins address et prefix.
addresses (tableau d'ipv6) déprécié en faveur de address-data
dad-timeoute (int32) timeout en ms pour vérifier la présence d'adresses IP dupliquées. défaut: -1, utilise la valeur par défaut.
dhcp-hostname (chaîne) si dhcp-send-hostname est à true, le nom spécifié ici est envoyé au serveur DHCP
dhcp-send-hostname (bool) à true, envoie le hostname au serveur DHCP
dhcp-timeout (int32) timeout de transaction DHCP, en secondes. Défaut: 0
dns [tableau d'uint32) tableau d'adresses IP des serveurs DNS
dns-options (tableau de chaînes) tableau d'options DNS tel que décris dans man resolv.conf. NULL utilise les valeurs par défaut
dns-priority (int32) Priorité DNS intra-connexion. La priorité relative est utilisée pour déterminer l'ordre des serveurs DNS dans resolv.conf. Une valeur faible place les serveurs en haut du fichier. Défaut: 0, qui sélectionne la valeur par défaut: 50 pour VPN, et 100 pour les autres connexions.
dns-search (tableau de chaîne) tableau de domaines de recherche DNS
gateway (chaîne) La passerelle associée avec cette configuration
ignore-auto-dns (bool) Quand method est à auto et cette propriété à TRUE, les serveurs de nom et domaines de recherche automatiquement configurés sont ignorés et seuls les serveurs et domaines spécifiés dans les propriétés dns et dns-search sont utilisés.
ignore-auto-routes (bool) si method est à 'auto' et cette propriété à TRUE, les routes automatiquement configurées son ignorées et seules les routes dans la propriété routes sont utilisées
ip6-privacy (NMSettingIP6ConfigPrivacy)
may-fail (bool) à TRUE, autorise la configuration réseau même si le fichier de configuration spécifié par cette propriété échoue au timeout. Noter qu'au moins une configuration IP doit réussir our la configuration réseau générale échoue.
method (chaîne) Méthode de configuration IP 'auto', 'manual' ou 'link-local'
name (chaîne) Nom du paramétrage: ipv6
never-default (bool) à TRUE, cette connexions n'est jamais la connexion par défaut pour ce type IP, ce qui signifie que la route par défaut n'est jamais assignée
route-data (tableau de dictionnaire) Tableau de routes IPv6. Chaque dictionnaire de route contient au moins les entrées 'dest' et 'prefix'. La plupart des routes ont également une entrée 'gateway'
route-metric (int64) Métrique par défaut pour les routes qui n'en spécifient pas une explicite. Défaut: -1 signifiant que la métrique est choisie automatiquement basé sur le type de périphérique.
routes (tableau de tableau d'uint32) Déprécié en faveur de route-data
token (chaîne) configure le token pour les identifiants d'interface IPv6 draft-chown-6man-tokenised-ipv6-identifiers-02. Utile avec eui64.

ip-tunnel

encapsulation-limit (uint32) Nombre de niveaux d'encapsulation additionels à ajouter aux paquets. Uniquement pour les tunnels IPv6
flow-label (uint32) Label de flux à assigner aux packets.
input-key (chaîne) La clé utilisée pour les paquets entrant.
local (chaîne) endpoint local du tunnel. doit contenir une IPv4 ou IPv6.
mode (uint32) Mode de tunneling, par exemple NM_IP_TUNNEL_MODE_IPIP, ou NM_IP_TUNNEL_MODE_GRE
mtu (uint32) 0
name Nom du paramétrage: ip-tunnel
output-key (chaîne) Clé utilisée pour les paquets sortants
parent (chaîne) nom de l'interface parent ou UUID de la connexion parent
path-mtu-discovery (bool) Si Path MTU Discovery est activé dans ce tunnel (défaut: TRUE)
remote (chaîne) enppoint distant du tunnel. Doit être une IPv4 ou IPv6
tos (uint32) Type de service IPv4 ou classe de trafique IPv6
ttl (uint32) TTL à assigner aux paquets tunnelisés. Défaut: 0, les paquets héritent de la valeur TTL

macsec

encrypt (bool) Si le trafique transmis doit être chiffré (défaut: TRUE)
mka-cak (chaîne) CAK pré-partagé pour l'agrément de clé MACsec
mka-cak-flags (NMSettingSecretFlags) Flags indiquant comment gérer la propriété mka-cak.
mka-ckn (chaîne) CKN pré-partagé pour l'agrément de clé MACsec
mode (int32) Spécifie commande la CAK pour MKA est obtenue
name Type de paramètrage: macsec
parent (chaîne) nom de l'interface parent ou UUID de la connexion parent
port (int32) Composant port du SCI, entre 1 et 65534
validation (int32) Mode de validation pour les frames entrantes

macvlan

mode (uint32) mode macvlan qui spécifie le mécanisme de communication entre plusieurs macvlans dans le même périphérique
name (chaîne) nom du paramètrage: macvlan
parent (chaîne) nom de l'interface parent ou UUID de la connexion parent
promiscuous (bool) si l'interface devrait être en mode promiscuous. Défaut: TRUE
tap (bool) Si l'interface devrait être un MACVTAP. Défaut: FALSE

802-11-olpc-mesh

channel (uint32) Canal sur lequel le réseau à joindre est localité
dhcp-anycast-address (tableau d'octets) addresse MAC DHCP anycast utilisé pour demander une adresse IP via DHCP
name (chaîne) nom du paramètrage: 802-11-olpc-mesh
ssid (tableau d'octets) SSID du réseau à joindre

ppp

baud (uint32) non 0, indique à pppd de définir le port série au baudrate spécifié. à 0, la vitesse est choisie automatiquement
crtscts (bool) à TRUE, pppd doit définir le port série pour utiliser le contrôle de flux hardware avec les signaux RTS et CTS. Défaut: FALSE
lcp-echo-failure (uint32) non 0, pppd assume que la connexion au paire a échoué si le numéro spécifié de LCP echo-requests n'a pas reçu de réponse du paire.
lcp-echo-interval (uint32) non 0, pppd envoie un LCP echo-request au paire toutes les n secondes.
mppe-stateful (bool) à TRUE, MPPE avec état est utilisé.
mru (uint32) non 0, pppd demande au paire d'envoyer des paquets au maximum à la taille spécifiée
mtu (uint32) non 0, pppd n'envoie pas de paquet dont la taille excède cette taille
name (chaîne) nom du paramètrage: ppp
no-vj-comp (bool) À true, ne demande pas la compression d'en-tête TCP Van Jacobsen
noauth (bool) à TRUE, ne demande pas d'authentification
nobsdcomp (bool) à TRUE, ne demande pas de compression BSD
nodeflate (bool) à TRUE ne demande pas de compression 'deflate'
refuse-chap (bool) à TRUE, n'utilise pas la méthode d'authentification CHAP
refuse-eap (bool) à TRUE, n'utiliset pas la méthode d'authentification EAP
refuse-mschap (bool) à TRUE, n'utiliset pas la méthode d'authentification MSCHAP
refuse-mschapv2 (bool) à TRUE, n'utiliset pas la méthode d'authentification MSCHAPv2
refuse-pap (bool)à TRUE, n'utiliset pas la méthode d'authentification PAP
require-mppe (bool) à TRUE, mppe est requis pour la session PPP.
require-mppe-128 (bool) à TRUE MPPE 128-bits est requis pour la session PPP.

pppoe

name (chaîne) nom du paramétrage: pppoe
password (chaîne) Mot de passe utilisé pour authentifier le service PPPeE
password-flags (NMSettingSecretFlags) Flags indiquant comment manipuler la proriété password
service (chaîne) si spécifié, instruit PPPoE à seulement initier des session avec des concentrateurs d'accès.
username (chaîne) username pour l'authhentification

proxy

browser-only (bool) Si la configuration proxy est pour les navigateurs uniquement
method (int32) Méthode pour la configuration proxy défaut: NM_SETTING_PROXY_METHOD_NONE(0)
name (chaîne) nom du paramétrage: proxy
pac-script (chaîne) script PAC pour la connexion
pac-url (chaîne) URL pour obtenir le fichier PAC

serial

baud (uint32) Vitesse pour la communication. Défaut: 57600
bits (uint32) Largeur d'octet de la communication. Défaut: 8
name (chaîne) nom du paramétrage: serial
parity (octet) Parité de la connexion: 69 (ASCII 'E') pour une parité paire, 111 (ASCII 'o') pour impaire, 110 (ASCII 'n') pour aucune parité
send-delay (uint64) Temps d'attente entre chaque octet envoyé au modem, en microsecondes. Défaut: 0
stopbits (uint32) Nombre de bits stop pour la communication, 1 ou 2. Défaut: 1.

team

config (chaîne) la configuration JSON pour l'interface team. La configuration devrait contenir une configuration acceptable pour teamd.
interface-name (chaîne) déprécié en faveur de connection.interface-name.
name (chaîne) nom du paramétrage: team

team-port

config (chaîne) la configuration JSON pour l'interface team. La configuration devrait contenir une configuration acceptable pour teamd.
name (chaîne) nom du paramétrage: team-port

tun

group (chaîne) Le group ID qui possède le périphérique. à NULL, tout le monde peut utiliser le périphérique
mode (uint32) Mode opératoire du périphérique NM_SETTING_TUN_MODE(1) pour créer un périphérique L3 et NM_SETTING_TUN_MODE_TAP(2) pour créer un périphérique L2
multi-queue (bool) à TRUE, l'interface supporte plusieurs descripteurs de fichier (queues) pour paralléliser l'envoie/réception des paquets, sinon, l'interface ne supporte qu'une seule queue. Défaut: FALSE
name (chaîne) nom du paramétrage: tun
owner [chaîne) Le user ID qui possède le périphérique. NULL, tout le monde peut utiliser le périphérique
pi (boo) à TRUE, l'interface ajoute 4 octets d'en-tête décrivant l'interface physique aux paquets. Défaut: FALSE
vnet-hdr (bool) à TRUE, les paquets IFF_VNET_HDR incluent un en-tête de réseau virtio. Défaut: FALSE

vlan

egress-priority-map (tableau de chaînes) pour les paquets sortants, une liste de mappage de priorités SKB Linux en priorités 802.1p. Le mappage est donné au format "from:to" et sont des entiers non-signés.
flags (NMVlanFlags) Flags qui contrôlent le comportement et les fonctionnalités de l'interface vlan. NM_VLAN_FLAG_REORDER_HEADERS (0x1) réordonne les en-tête des paquets sortants, NM_VLAN_FLAG_GVRP (0x2) utilise le protocole GVRP, NM_VLAN_FLAG_LOOSE_BINDING (0x4) perd la liaison de l'interface de l'état opérant du périphérique maire. NM_VLAN_FLAG_MVRP (0x8) utilise le protocole MVRP.
id (uint32) Identifiant du vlan, de 0 à 4094. Défaut: 0
ingress-priority-map (tableau de chaînes) Pour les paquets entrants, une liste de mappage de priorité 802.1p en priorité SKB Linux.
interface-name (chaîne) déprécié en faveur de connection.interface-name
name (chaîne) nom du paramétrage: vlan
parent (chaîne) si donné, spécifie le nom de l'interface parent. non spécifié, la connexion doit contenir un paramètre "802-3-ethernet" avec une propriété "mac-address"

vpn

data (dictionnaire de chaîne) dictionnaire de paires clé/valeurs de données spécifique au plugin VPN.
namo (chaîne) nom du paramétrage: vpn
persistent (bool) Si le service VPN supporte la persistence, et cette propriété à TRUE, le VPN tente de rester connecté entre les changements de liens, jusqu'à déconnexion explicite
secrets (dictionnaire de chaîne) Dictionnaire de paires clé/valeur de secrets spécifiue au plugin VPN, comme des mots de passe ou des clés privées
service-type (chaîne) Nom du service D-Bus du plugin VPN que ce paramètre utilise pour se connecter au réseau (ex: org.freedesktop.NetworkManager.vpnc pour le plugin vpnc)
timeout (uint32) timeout du service VPN pour établir la connexion. Certains services peuvent prendre du temps pour se connecter. 0 signifie le timeout par défaut: 60 secondes.
user-name (chaîne) Si la connexion VPN nécessite un username pour l'authentification.

vxlan

ageing (uint32) Durée de vie en secondes des entrées FDB apprises par le kernel. défaut: 300
destination-port (uint32) port UDP de destination pour communiquer au endpoint distant
id (uint32) Spécifie l'identifiant réseau VXLAN à utiliser
l2-miss (bool) Spécifie si les notification LL ADDR miss sont générés. défaut: FALSE
l3-miss (bool) Spécifie si les notification IP ADDR miss sont générés. défaut: FALSE
learning (bool) Spécifie si une adresse L2 inconnue et les IP sont entrée dans la learning base VXLAN. Défaut: TRUE
limit (uint32) Spécifie le nombre max d'entrées FDB. Défaut: 0 = illimité
local (chaîne) nom du paramétrage: vxlan
parent (chaîne) nom de l'interface parent
proxy (bool) Spécifie si le proxy ARP est activé. Défaut: FALSE
remote (châine) Spécifie l'adresse IP unicast de destination pour les paquets sortants quand l'adresse l2 n'est pas connue dans la forwarding base VXLAN, ou l'IP multicast à joindre
rsc (bool) Spécifie si le route short circuit est activé. Défaut: FALSE
source-port-max (uint32) port UDP source max pour communiquer au endpoint
source-port-min (uint32) port UDP de destination minimum
tos (uint32) Valeur TOS pour les paquets sortants
ttl (uint32) ttl à utliser pour les paquets sortants

wimax

mac-address (tableau d'octets) Déprécié. Si spécifié, cette connexion s'applique au périphérique WiMAX qui matche cette adresse MAC.
name (chaîne) nom du paramétrage: wimax
network-name (chaîne) Déprécié. Nom du NSP du réseau WiMAX

802-3-ethernet

assigned-mac-address (chaîne) Addresse MAC clonée. Peut être une adresse MAC, ou un des mots clés suivant: preserve, permanent, random, ou stable.
auto-negotiate (bool) à TRUE, force l'auto-négociation de vitesse de port et le mode duplex. Défaut: FALSE
cloned-mac-address (tableau d'octets) déprécié en faveur de assigned-mac-address
duplex (chaîne) uniquement si auto-negotiate vaut 'off'. Configure le périphérique pour utiliser le mode duplex spécifié: half ou full.
generate-mac-address-mask (chaîne) si cloned-mac-address vaut random ou stable, cette propriété spécifie les bits qui sont fixes.
mac-address (tableau d'octets) si spécifié, cette connection ne s'applique qu'au périphérique dont l'adresse MAC permanent correspond
mac-address-blacklist (tableau de chaînes) Cette connection ne s'applique jamais aux périphérique dont l'adresse MAC permanente matche une de ces adresses
mtu (uint32) spécifie le mtu max pour cette connection
name (chaîne) nom du paramétrage: 802-3-ethernet
port (chaîne) Spécifie le type de port à utiliser si le périphérique support plusieurs méthodes d'attachement. tp (twisted Pair), aui (Attachment Unit Interface), bnc (Thin Ethernet) ou mii (Media Independant Interface).
s390-nettype (chaîne) Type de périphérique réseau s390 (qeth, lcs, ou ctc).
s390-options (dictionnaire de chaînes) dictionnaire de paires de clé/valeurs d'options s390. Les clés permises sont portno, layer2, portname et protocol.
speed (uint32) Peut être définis à une valeur supérieur à 0 quand auto-negotiate est à off. Dans ce cas, définis la vitesse en Mbit/s.
wake-on-lan (uint32) Options NMSettingWiredWakeOnLan à activer. peut être une des combinaisons: NM_SETTING_WIRED_WAKE_ON_LAN_PHY (0x2), NM_SETTING_WIRED_WAKE_ON_LAN_UNICAST (0x4), NM_SETTING_WIRED_WAKE_ON_LAN_MULTICAST (0x8), NM_SETTING_WIRED_WAKE_ON_LAN_BROADCAST (0x10), NM_SETTING_WIRED_WAKE_ON_LAN_ARP (0x20), NM_SETTING_WIRED_WAKE_ON_LAN_MAGIC (0x40) ou les valeurs spéciales NM_SETTING_WIRED_WAKE_ON_LAN_DEFAULT (0x1) (pour utiliser les paramètres globaux) et NM_SETTING_WIRED_WAKE_ON_LAN_IGNORE (0x8000) (pour désactiver la gestion de Wake-on-LAN dans NetworkManager).
wake-on-lan-password (chaîne) Mot de passe utilisé avec magic-packet-based Wake-on-LAN, représentée comme une adresse MAC. NULL indique qu'aucun mot de passe n'est requis.

802-11-wireless

assigned-mac-address (chaîne) Le nouveau champ pour l'adresse MAC clonée. Peut être une adresse MAC ou un des mots spécial "preserve", random" ou "stable".
band (chaîne) bande de fréquence 802.11: "a" (5GHz 802.11a), ou "bg" (2,4GHz 802.11).
bssid (tableau d'octets) Dirige le périphérique au point d'accès associé.
channel (uint32) Canal wireless à utiliser. Défaut: 0
cloned-mac-address (tableau d'octets) déprécié en faveur de assigned-mac-address
generate-mac-address-mask (chaîne) si cloned-mac-address vaut random ou stable, cette propriété spécifie les bits qui sont fixes.
hidden (bool) à TRUE, indique que ce réseau cache son SSID.
mac-address (tableau d'octets) si spécifié, cette connection ne s'applique qu'au périphérique dont l'adresse MAC permanent correspond
mac-address-blacklist (tableau de chaînes) Cette connection ne s'applique jamais aux périphérique dont l'adresse MAC permanente matche une de ces adresses
mac-address-randomization (uint32) déprécié en faveur de cloned-mac-address. NM_SETTING_MAC_RANDOMIZATION_DEFAULT (0) (Utilise la valeur globale par défaut), NM_SETTING_MAC_RANDOMIZATION_NEVER (1) (pas d'aléatoire), NM_SETTING_MAC_RANDOMIZATION_ALWAYS (2).
mode (chaîne) mode réseau Wi-Fi: "infrastructure", "adhoc" ou "ap".
mtu (uint32) mtu pour les paquets transmis
name (chaîne) nom du paramétrage: 802-11-wireless
powersave (uint32) NM_SETTING_WIRELESS_POWERSAVE_DISABLE (2), NM_SETTING_WIRELESS_POWERSAVE_ENABLE (3), NM_SETTING_WIRELESS_POWERSAVE_IGNORE (1), NM_SETTING_WIRELESS_POWERSAVE_DEFAULT (0)
rate (uint32) Dirige de périphérique pour utiliser seulement le bitrate spécifié pour la communication avec le point d'accès, en Kb/s.
security déprécié
seen-bssids (tableau de chaînes) Une liste de BSSID (formatté sous forme d'adresse MAC) qui ont été détectés comme partie de la connection Wi-Fi. Géré par NetworkManager
ssid (tableau d'octets) SSID du réseau Wi-Fi. Doit être spécifié
tx-power (uint32) le périphérique utilise la puissance de transmission spécifiée, en dBm.

802-11-wireless-security

auth-alg (chaîne) avec WEP, indique l'algorithme d'authentification requise "open", "shared" "leap".
group (tableau de chaînes)Liste d'algorithmes de chiffrement qui empêche les connection aux réseaux Wi-Fi qui n'utilisent pas un de ces algorithmes. "wep40", "wep104", "tkip" ou "ccmp"
key-mgmt (chaîne) Gestion de clé utilisé pour la connection "none" (WEP), "ieee8021x" (Dynamic WEP), "wpa-none" (Ad-Hoc WPA-PSK), "wpa-psk" (infrastructure WPA-PSK), ou "wpa-eap" (WPA-Enterprise).
leap-password (chaîne) password de connexion pour les connexions LEAP
leap-password-flags (NMSettingSecretFlags) Flags indiquant comment gérer la propriété leap-password.
leap-username (chaîne) username pour la connexion
name (chaîne) nom du paramétrage: 802-11-wireless-security
pairwise (tableau de chaînes) Liste d'algorithme de chiffrement d'appairement permis pour les connections Wi-Fi
proto (tableau de chaînes) Liste de chaînes spécifiant les versions WPA permises "wpa" ou "rsn" (autorise WPA2/RSN).
psk (chaîne) Clé pré-partagée pour les réseaux WPA.
psk-flags (NMSettingSecretFlags) Flags indiquant comment gérer la propriété psk
wep-key-flags (NMSettingSecretFlags) Flags indiquant comment gérer les propriétés wep-key[0-3].
wep-key-type (NMWepKeyType) Contrôle l'interprétation des clés WEP. NM_WEP_KEY_TYPE_KEY (1) (la clé a 10 ou 26 caractères hexa, ou 5 ou 13 caractères ASCII) ou NM_WEP_KEY_TYPE_PASSPHRASE (2)
wep-key0 (chaîne) Clé WEP d'index 0
wep-key1 (chaîne) Clé WEP d'index 1
wep-key2 (chaîne) Clé WEP d'index 2
wep-key3 (chaîne) Clé WEP d'index 3
wep-tx-keyidx (uint32) Si WEP statique est utilisé et un indexe de clé WEP non-défaut est utilisé par l'AP, place cet index ici. (0 à 3)

Types de flags secret

0x0 Le système doit fournir et stocker le secret
0x1 Un agent userspace gère le secret
0x2 Le secret n'est pas sauvé et est demandé à l'utilisateur à chaque fois.
0x4 Indique que le secret n'est pas requis et ne devrait pas être demandé à l'utilisateur
^
05 mai 2017

htmlpdflatexmanmd




nmcli

nmcli

Outil d'administration de NetworkManager

   Cet outil contrôle NetworkManager et affiche le status réseaux.

OPTIONS

-t, --terse Affichage adapté aux traitement dans les scripts
-p, --pretty Affiche plus compréhensible
-m, --mode { tabular | multiline } Affichage tabulaire ou multiligne. Défaut: multiline
-c, --colors {yes | no | auto} Contrôle si la sortie utilise les couleurs. Défaut: auto
-f, --fields { field1,field2...|all|common } Contrôle les champs affiché sur la sortie. Défaut: common
-e, --escape {yes|no} Indisque si les caractères : et \ sont échappés en mode terse. Défaut: yes
-a,--ask nmcli stop et demande des arguments. Utile pour demander un mot de passe
-s, --show-secrets Affiche les mots de passe et secrets qui peuvent être présent dans la sortie.
-w, --wait seconds Délai d'attente d'une opération NetworkManager. Utile pour les commande qui prennent du temps comme l'activation de connection. 0 signifie pas d'attente
--complete-args Affiche la liste des arguments possible pour le dernier argument.

Commande general

status Affiche le status général de NetworkManager
hostname [hostname] Affiche ou définis le nom d'hôte.
permissions Affiche les permissions qu'un appelant a pour diverses opérations authentifiées
logging [level level][domains domains...] Affiche ou change le niveau de log de NetworkManager et les domaines.

Commande networking

on, off Active ou désactive le contrôle du réseaux par NetworkManager.
connectivity [check] Affiche l'état de la connectivité réseaux. L'état indiques:

        none L'hôte n'est pas connecté à un réseau
        portal L'hôte est derrière un portail captif et ne peut pas accéder à Internet
        limited L'hôte est connecté à un réseau, mais n'a pas accès à internet
        full L'hôte est connecté à un réseau et a pleinement accès à internet
        unknown Le status de connectivité ne peut être trouvé

Commande radio

wifi [on|off] Affiche ou définis le status du WiFi dans NetworkManager.
wwan [on|off] Affiche ou définis le status de WWAN dans NetworkManager
al [on|off] Affiche ou dfinis le status du wifi et WWAN dans NetworkManager

Commande monitor

   Observe l'activité NetworkManager. Regarde les changements d'état de connectivité, périphérique ou profiles de connexion.

Commande connection

show [--active][--order[+-]category:...] Liste les profiles de connection sur disque et en mémoire. --order permet d'afficher dans un ordre particulier (active, name, type, path). sans préfix ou avec +, trie dans l'ordre ascendant.
show [--active][id|uuid|path|apath] ID... Affiche des détails pour les connections spécifiées. --active affiche seulement les profiles actifs. Les mots clés sont utilisé si l'ID est ambigus:

        id L'ID dénote le nom d'une connexion
        uuid L'ID dénote un UUID de connexion
        path l'ID dénote un chemin de connexion D-Bus
        apath L'ID dénote un chemin de connexion actif D-Bus

up [id|uuid|path] ID [ifname ifname] [ap BSSID] [passwd-file file] Active une connexion. La connexion est identifiée par son nom, UUID ou chemin D-Bus. Si l'ID est ambigus le mot clé id, uuid ou path peut être utilisé. si requis, ifname sélectionne un périphérique particulier. ap spcécifie un BSSID de l'AP à utiliser dans le cas de connexions Wi-Fi. --wait spécifie le timeout (defaut: 90s). passwd-file spécifie les accréditifs pour l'activation. peut être sous la forme:

        setting_name.property_name:the password Spécifie le mot de passe explicitement
        802-11-wireless-security.psk:secret12345 Pour WPA PSK
        802-1x.password:my 1X password mot de passe 802.1x

down [ id | uuid | path | apath ] ID... Désactive une connexion
modify [--temporary] [ id | uuid | path ] ID { option value | [+|-]setting.property value } ... Ajoute, modify ou supprime des propriétés dans le profile de connexion. une valeur "" supprime la valeur.
add [save { yes | no }] { option value | [+|-]setting.property value } ... Créé une nouvelle connexion en utilisant les propriétés spécifiées.. Pour construire une connexion significative il faut nécessairement la propriété connection.type (ethernet, wifi, wimax, pppoe, gsm, cdma, infiniband, bluetooth, vlan, bond, bond-slave, team, team-slave, bridge, bridge-slave, vpn, olpc-mesh, adsl, tun, ip-tunnel, macvlan, vxlan). save contrôle si la connexion doit être persistante
edit { [ id | uuid | path ] ID | [type type] [con-name name] } Édite une connexion existante, ou en ajouter une, en utilisant un éditeur interactif. type spécifie le type de connexion, et con-name spécifie le nom pour la connexion.
clone [--temporary] [ id | uuid | path ] ID new_name Clone une connexion. La connexion clonée est identifiée par son nom, UUID, ou chemin D-Bus. --temporary ne conserve pas le nouveau profile au redémarrage
delete [ id | uuid | path ] ID... Supprime une connexion configurée
monitor [ id | uuid | path ] ID... supervise l'activité du profile de connexion. Affiche une ligne si la connexion spécifiée change
reload Recharge tous les fichiers de connexion depuis le disque
load filename Charge/recharge un ou plusieurs fichiers de connexion.
import [--temporary] type type file file Importe une configuration externe comme profile NetworkManager. Le type de fichier d'entrée est spécifiée par type
export [id|uuid|path] ID [file] Exporte une connexion. Seul les connexions VPN sont supportés pour le moment.

Commande device

status Affiche le status du périphérique. C'est l'action par défaut
show [ifname] Affiche des informations détaillées sur les périphériques. Sans argument, examine tous les périphériques.
set [ifname] ifname [ autoconnect { yes | no } ] [ managed { yes | no } ] Définis les propriétés du périphérique
connect ifname Connecte le périphérique. NetworkManager tente de trouver une connexion convenable à activer. Il considère également les connexions non-autoconnect
reapply ifname Tente de mettre à jours de le périphérique
modify ifname { option value | [+|-]setting.property value }... Modifie le paramètre courant du périphérique. Cette commande permet d'effectuer des changements temporaires de la configuration active.
disconnect ifname Déconnecte un périphérique et empêche de périphérique d'activer d'autres connections sans intervention manuelle.
delete ifname Supprime un périphérique. Supprime l'interaface du système. Ne fonctionne que pour les périphériques logiciels
monitor [ifname...] Supervise l'activité du périphérique. Affiche une ligne indiquant le changement d'état de l'interface
wifi [list [ifname ifname][bssid BSSID]] Liste les points d'accès wifi.
wifi connect (B)SSID [password password] [ wep-key-type { key | phrase } ] [ifname ifname] [bssid BSSID] [name name] [ private { yes | no } ] [ hidden { yes | no } ] Connecte un réseaux Wi-Fi spécifié par son SSID ou BSSID. La commande créé une nouvelle connexion et l'active sur un périphérique.

        password Mot de passe WEP ou WPA
        wep-key-type Type de secret WEP, (key ou phrase)
        ifname Interface à utiliser pour l'activation
        bssid La connexion créée est restreinte pour le BSSID
        name Nom de la connexion
        private à yes, la connexion n'est visible que de l'utilisateur qui l'a créé.
        hidden à yes, pour les points d'accès qui ne broadcast pas le SSID

wifi hotspot [ifname ifname] [con-name name] [ssid SSID] [ band { a | bg } ] [channel channel] [password password] Créé un hotspot Wi-Fi. La commande créé un profile de connection hotspot en accord avec les capacités du périphérique Wi-Fi, et l'active. Le hotspot est sécurisé avec WPA si le périphérique/pilote le supporte, WEP sinon. Utiliser connection down ou device disconnect pour stopper le hotspot. Les paramètres sont:

        ifname Périphérique à utiliser
        con-name Nom du profile à créer
        ssid SSID du hotspot
        band bande Wi-Fi à utiliser
        channel Canal Wi-Fi à utiliser
        password Mode de passe à utiliser. Non fournis, nmcli en génère un. Noter que --show-secrets peut être utilisé pour afficher le mot de passe.
        wifi rescan [ifname ifname][ssid SSID...] Rescan immédiatement les points d'accès disponibles. en spécifiant le SSID, il est possible de rechercher ce SSID spécifique.
        lldp [ list [ ifname ifname ]] Affiche des informations sur les périphériques voisins appris via le protocole lldp.

Commande agent

secret Enregistre nmcli comme agent secret NetworkManager et écoute les demandes de secrets. Ce n'est généralement pas nécessaire parce que nmcli peut gérer les secrets à la connection aux réseaux.
polkit Enregistre nmcli comme agent polkit pour la session utilisateur.
all Lance nmcli comme secret NetworkManager et agent polkit

Variables d'environnement

LC_ALL Langage à utiliser pour déterminer le jeu de caractères
LC_MESSAGES Utilisé pour rechercher les locales
LANG Langage à utiliser pour déterminer le jeu de caractères

Codes de sortie

0 succès
1 Erreur non-spécifiée ou inconnue
2 entrée utilisateur invalide
3 Timeout expiré (--wait)
4 Activation de connexion échouée
5 Désactivation de connexion échouée
6 Déconnexion de périphérique échouée
7 Suppression de connexion échouée
8 NetworkManager n'est pas en cours de fonctionnement
10 La connection, périphérique ou point d'accès n'existe pas
65 avec --complete-args, un nom de fichier est attendu.

Exemples

Voir si NetworkManager est en cours de fonctionnement
nmcli -t -f RUNNING general
Affiche le status de NetworkManager
nmcli -t -f STATE general
Désactiver le wifi
nmcli radio wifi off
Lister les connexions que possède NetworkManager
nmcli connection show
Afficher toutes les connexions configurées en mode multiligne
nmcli -p -m multiline -f all con show
Lister toutes les connexions actives
nmcli connection show --active
Afficher tous les noms de profile de connexion et leur propriété auto-connect
nmcli -f name,autoconnect c s
afficher des détails pour le profile de connexion "My default em1"
nmcli -p connection show "My default em1"
AFficher des détails pour "My Home Wifi" avec tous les mots de passe:
nmcli --show-secrets connection show "My Home WiFi"
Affiche des détails pour la connexion active "My default em1":
nmcli -f active connection show "My default em1"
afficher les détails de configuration statique du profile de connexion
nmcli -f profile con s "My wired connection"
Activer un profile de connexion sur eth0
nmcli -p con up "My wired connection" ifname eth0
Connecter le Wi-Fi avec l'uuid spécifié au point d'accès donné
nmcli con up 6b028a27-6dc9-4411-9886-e9ad1dd43761 ap 00:3A:98:7C:42:D3
Aficher le status de tous les périphériques
nmcli device status
Déconnecter une connection de l'interface em2 et marquer le périphérique comme indisponibble pour l'auto-connexion.
nmcli dev disconnect em2
Afficher des détails pour wlan0, en limitant aux sections GENERAL et WIFI-PROPERTIES
nmcli -f GENERAL,WIFI-PROPERTIES dev show wlan0
Afficher tous les profiles de connection disponibles pour l'interface Wi-Fi wlp3s0
nmcli -f CONNECTIONS device show wlp3s0
Lister tous les points d'accès disponibles connus
nmcli dev wifi
Créer une nouvelle connexion nommée "My cafe" et le connecter au SSID "Cafe Hotspot 1" avec le mot de passe caffeine.
nmcli dev wifi con "Cafe Hotspot 1" password caffeine name "My cafe"
Créer un profile hotspot et se connecter. Affiche le mot de passe
nmcli -s dev wifi hotspot con-name QuickHotspot
Démarre un partage de connexion IPv4 en utilisant le périphérique em1. Le partage est activé jusqu'à ce que le périphérique soit déconnecté
nmcli dev modify em1 ipv4.method shared
Ajoute temporairement une adresse IP au périphérique
nmcli dev modify em1 ipv6.address 2001:db8::a:bad:c0de
Ajoute non-interactivement une connexion Ethernel à eth0 avec DHCP, puis désactive le flag autoconnect
nmcli connection add type ethernet autoconnect no ifname eth0
Ajoute un VLAM avec l'id 55, sur eth0 et nommé Maxipes-fik
nmcli c a ifname Maxipes-fik type vlan dev eth0 id 55
Ajoute une connexion qui utiliser eth0 et a seulement une IPv6 lien-local
nmcli c a ifname eth0 type ethernet ipv4.method disabled ipv6.method link-local
Édite une connexion existante dans un éditeur interactif
nmcli connection edit ethernet-em1-2
Ajoute une nouvelle connexion Ethernet dans l'éditeur interactif
nmcli connection edit type ethernet con-name "yet another Ethernet connection"
Modifie la propriété autoconnect
nmcli con mod ethernet-2 connection.autoconnect no
Modifie le propriété mtu dans les paramètre wi-fi d'une connexion
nmcli con mod "Home Wi-Fi" wifi.mtu 1350
Définis l'adressage manuellement et les adresse dans le profile em1-1
nmcli con mod em1-1 ipv4.method manual ipv4.addr "192.168.1.23/24 192.168.1.1, 10.10.1.5/8, 10.0.0.11"
Ajoute un serveur DNS public google aux serveurs DNS dans le profile ABC
nmcli con modify ABC +ipv4.dns 8.8.8.8
Supprime l'adresse IP spécifiée du profile ABC
nmcli con modify ABC -ipv4.addresses "192.168.100.25/24 192.168.1.1"
Importe une configuration OpenVPN
nmcli con import type openvpn file ~/Downloads/frootvpn.ovpn
Export le profile VPM
nmcli con export corp-vpnc /home/joe/corpvpn.conf
^
15 juillet 2010

htmlpdflatexmanmd




nohup

nohup

Lancer une commande de manière à ce que les signaux hangup soient ignorés.

   nohup lance la commande spécifié de manière à ce que les signaux hangup soient ignorés, donc une commande peut continuer même après s'être déconnecté. Si l'entrée standard est le terminal, elle est redirigé vers /dev/null. Si la sortie standard est un terminal, elle est redirigé vers le fichier nohup.out, ou $HOME/nohup.out s'il ne peut pas être accédé en écriture. Si l'erreur standard est un terminal, elle est redirigé vers le même descripteur de fichier que la sortie standard. nohup ne place pas automatiquement la commande en fond, vous devez le faire explicitement, en terminant la ligne de commande avec un &.

Exemple

Pour rediriger la sortie d'un commande lancée avec nohup:
nohup make › make.log
^
18 mars 2016

htmlpdflatexmanmd




nsec3hash

nsec3hash

Générer des hash NSEC3

   nsec3hash génère un hash NSEC3 basé sur un jeu de paramètre NSEC3. Il peut être utilsé pour vérifier la validité des enregistrements NSEC3 dans une zone signée

Arguments

salt Le salt fournis à l'algorithme de hashage
algorithm Un nombre indiquant l'algorithme de hashage. (actuellement 1=SHA-1)
iterations Nombre de temps additionnel de génération de hash
domain Nom du domaine
^
10 juillet 2014

htmlpdflatexmanmd




nslcd

nslcd

Daemon de service de nom LDAP local

   nslcd est un service qui fait des requêtes LDAP pour NSS et PAM. Il est configuré via nslcd.conf

OPTIONS

-c, --check Vérifie si le service est lancé. 0 s'il fonctionne, 1 sinon
-d, --debug Mode débug, nslcd ne se place pas en tâche de fond et envoie ses logs sur stderr.
-n, --nofork Ne se fork pas et reste en foreground

Signaux

SIGTERM/SIGINT Annule toute requête en cours et se termine
SIGUSR1 Retente les connexions echouées, sans respecter reconnect_sleeptime et reconnect_retrytime

Fichiers

/etc/nslcd.conf Fichier de configuration de nslcd.
^
10 juillet 2014

htmlpdflatexmanmd




nslcd.conf

nslcd.conf

Fichier de configuration de nslcd

options runtimes

threads NUM Spécifie le nombre de threads. Défaut: 5
uid UID user id du service
gid GID Groupe du service
log SCHEME [LEVEL] Contrôle les logs. SCHEME peut être none ou syslog. (défaut: syslog info)

options de connexion

uri URI URI du serveur LDAP. La valeur alternative DNS peut être utilisée pour rechercher les DNS SRV avec la syntaxe DNS:DOMAIN.
ldap_version VERSION Spécifie la version du protocole LDAP à utiliser
binddn DN DN à utiliser pour le bind.
bindpw PASSWORD Mot de passe du binddn
rootpwmoddn DN Spécifie le DN à utiliser quand root tente de modifier le mot de passe d'un utilisateur en utilisant le module PAM.
rootpwmodpw PASSWORD Mot de passe de rootpwmoddn

options SASL

sasl_mech MECHANISM Spécifie le mécanisme SASL à utiliser pour l'authentification SASL
sasl_realm REALM Domaine SASL
sasl_authcid AUTHCID Identité d'authentification
sasl_authzid AUTHZID Identité d'authorisation (doit être spécifié au format dn:‹dn› ou u:‹username›)
sasl_secprops PROPERTIES Spécifie les propriétés de sécurité SASL de Cyrus. les valeurs permise sont décrites dans ldap.conf
sasl_canonicalize yes|no Détermine si le nom d'hôte du serveur LDAP devrait être canonisé ou non. À yes, effectue un reverse lookup.

options Kerberos

krb5_ccname NAME Nom pour le cache d'accréditations Kerberos

options de recherche et mappage

base [MAP] DN Base de recherche. Peut être spécifié plusieurs fois. Une base de recherche globale peut être spécifiée ou un map spécifique.
scope [MAP] sub[tree]|one[level]|base|children Spécifie le scope de recherche.
deref never|searching|finding|always Définis la stratégie de dé-référencement des alias.
referrals yes|no Spécifie si les référant doivent être suivis ou non.
filter MAP FILTER Filtre de recherche à utiliser pour un map spécifique.
map MAP ATTRIBUTE NEWATTRIBUTE Permet de définir d'autres attributs que ceux de la rfc2307.

options de timing et reconnexion

bind_timelimit SECONDS limite de temps pour la connexion au serveur. Défaut: 10 secondes
timelimit SECONDS Spécifie la limite de temps pour une réponse du serveur. 0 pour une attente infinie.
idle_timelimit SECONDS Période d'inactivité avant de fermer la connexion au serveur. Défaut: pas de limite
reconnect_sleeptime SECONDS Temps au delà duquel un serveur ldap est considéré indisponible. Une fois ce temps atteins, les tentatives seront faites une fois par cette tranche de temps. défaut: 10 secondes.

options SSL/TLS

ssl on|off|start_tls Spécifie le mode à utiliser
tls_reqcert never|allow|try|demand|hard Spécifie quelles vérifications effectuer sur le certificat du serveur. Les valeurs sont décrites dans ldap.conf.
tls_cacertdir PATH Répertoire contenant les certificats X.509 pour l'authentification du paire. Ignoré avec GnuTLS.
tls_cacertfile PATH Spécifie le chemin du certificat X.509 pour l'authentification du paire.
tls_randfile PATH Chemin de la source d'entropie. Ignoré avec GnuTLS
tls_ciphers CIPHERS Chiffrement à utiliser pour TLS.
tls_cert PATH Chemin du certificat du client
tls_key PATH Chemin du fichier contenant la clé privé du client.

autres options

pagesize NUMBER › 0, définis le nombre de résultat pour une recherche paginés. Défaut: 0.
nss_initgroups_ignoreusers user1,user2,... Empêche la recherche du groupe membership dans ldap pour les utilisateurs spécifiés. Peut être spécifié plusieurs fois.
nss_min_uid UID uid minimum pour les recherches dans ldap
nss_nested_groups yes|no Si l'attribut member pointe vers un autre groupe, les membres imbriqués sont retournés. Défaut: no.
validnames REGEX pattern pour déterminer les noms d'utilisateurs et de groupes valides.
ignorecase yes|no Prend en compte ou non la casse. yes peut exposer le système à des vulnérabilités.
pam_authz_search FILTER Permet de paramétrer la vérification d'authorisation. Le filtre spécifié est exécuté et si une entrée matche, l'accès est donné. Le filtre peut contenir les variables suivantes: $username, $service, $ruser, $rhost, $tty, $hostname, $fqdn, $dn, $uid. Peut être spécifié plusieurs fois.
pam_password_prohibit_message "MESSAGE" Refuse la modification de mot de passe avec pam_ldap et affiche le message spécifié. Peut être utilisé pour rediriger l'utilisateur vers un autre moyen de changer son mot de passe.
reconnect_invalidate DB,DB,... Si définis, vide les caches spécifiés au démarrage et lors des reconnexions au serveur. db est une des maps nsswitch.
cache CACHE TIME [TIME] Durée de rétentions des entrées dans le cache interne.

Expressions de mappage d'attributs

   Pour certains attributs, une expression de mappage peut être utilisé pour construire la valeur résultante. C'est actuellement seulement possible pour les attributs qui n'ont pas besoin d'être utilisés dans les filtres de recherche. Les expressions sont un sous-jeu d'expressions shell. Au lieu de substitution de variable, la recherche d'attribut est faite sur l'entrée courante et la valeur d'attribut est substituée. Les expressions suivantes sont supportés:

${attr}, $attr Substitue la valeur de l'attribut
${attr:-word} Substitue la valeur de l'attribut ou, si l'attribut n'est pas définis ou vide, substitue le mot.
${attr:+word} Substitue le mot si l'attribut si l'attribut est mis, sinon substitue une chaîne vide.
${attr#word} Supprime le match le plus court possible de la gauche de la valeur de l'attribut
${attr##word} Supprime le match le plus long possible de la gauche de la valeur de l'attribut
${attr%word} Supprime le match le plus long possible de la droite de la valeur de l'attribut
${attr%%word} Supprime le match le plus court possible de la droite de la valeur de l'attribut

   Seul la version '#' est supportée par nslcd, les autres sont supportés par pynslcd. Également, le seul wilcard supporté par nslcd est ?. Les caractères ", $ et \ doivent être échappés.

Exemples

Utilise l'attribut shadowFlag, avec la valeur 0 par défaut:
"${shadowFlag:-0}"
Utilise uid pour construire homeDirectory si cette attribut est manquant:
"${homeDirectory:-/home/$uid}"
Si isDisabled est mis, retourne 100:
"${isDisabled:+100}"
Enlève le préfixe {crypt} de userPassword:
"${userPassword#{crypt\}}"
^
14 août 2011

htmlpdflatexmanmd




nsswitch.conf

nsswitch.conf

Fichier de configuration pour la gestion des services de nom

   Les bases de données suivantes sont disponibles:

aliases alias de messagerie, utilisé par sendmail
ethers Numéros ethernet
group groupes d'utilisateurs, utilisé par getgrent(3)
hosts Noms d'hôtes et numéros, utilisé par gethostbyname(3) et similaires
netgroup liste d'hôtes et d'utilisateurs, utilisé pour les règles d'accès, NIS uniquement
networks noms réseaux et numéros, utilisés par getnetent(3)
passwd mots de passe utilisateurs, utilisé par getpwent(3)
protocols protocoles réseaux, utilisés par getprotoent(3)
publickey clés publiques et secret pour Secure_RPC utilisé par NFS et NIS+
rpc Noms et valeurs RPC, utilisé par getrpcbyname(3)
services services réseaux, utilisé par getservent(3)
shadow mots de passe utilisateurs, utilisés par getspnam(3)

Exemple de nsswitch.con par défaut:
passwd : compat
group : compat
shadow : compat
    
hosts : dns [!UNAVAIL=return] files
networks : nis [NOTFOUND=return] files
ethers : nis [NOTFOUND=return] files
protocols : nis [NOTFOUND=return] files
rpc : nis [NOTFOUND=return] files
services : nis [NOTFOUND=return] files

   La première colonne est la base de données. Le reste de la ligne spécifie le processus de recherche. Vous pouvez spécifier le fonctionnement pour chaque base de données. La configuration pour chaque base de données peut contenir 2 éléments différents: la spécification du service et la réaction de la recherche.

La syntaxe de la réaction de recherche est la suivante:
'[' ( ' !' ? STATUS '=' ACTION )+ ']'

STATUS = success | notfound | unavail | tryagain
ACTION = return | continue
success Aucune erreur ne s'est produit et l'entrée désirée est retournée (défaut : return)
notfound le processus de recherche fonctionne mais la valeur recherchée n'a pas été trouvée (défaut : continue)
unavail le service est indisponible de manière permanente. Cela peut être un fichier non disponible, ou pour DNS, le serveur non disponible ou une requête non permise. (Défaut : continue)
tryagain Le service est temporairement indisponible. Cela peut être un fichier bloqué ou un serveur saturé (défaut : continue)

Intéraction avec le mode compat

   libc5 sans NYS n'a pas de nss mais permet certains contrôles de stratégie. Dans /etc/passwd vous pouvez avoir des entrées sous la forme +user ou +@netgroup (inclut l'utilisateur spécifié depuis la map NIS passwd), -user ou -@netgroup (exclut l'utilisateur spécifié), et + (inclus tous les utilisateurs, excepté ceux exclus).

   Vous pouvez écraser certains champs passwd pour un utilisateur particulier depuis la map NIS passwd en utilisant la forme étendue +user :: :: :: dans /etc/passwd. Les champs non vides écrasent les informations dans la map NIS passwd. Vu que la plupart des personnes placent un + à la fin de /etc/passwd pour inclure tout le monde depuis NIS, le switch fournit une alternative plus rapide pour ce cas (passwd : files nis) qui ne requière pas le simple + dans /etc/passwd, /etc/group et /etc/shadow. Si ce n'est pas suffisant, le service compat fournit une sémantique +/- complète. Par défaut, la source nis est utilisée, mais peut être changé en spécifiant nisplus comme source pour la pseudo base de données passwd_compat, group_compat et shadow_compat. Ces pseudos bases de données sont uniquement disponibles dans la librairie GNU C.

Fichiers

   Un service nommé SERVICE est implémenté par une librairie d'objet partagée nommée libnss_SERVICE.so.X qui est dans /lib.

/etc/nsswitch.conf Fichier de configuration
/lib/libnss_compat.so.X implémente compat
/lib/libnss_db.so.X implémente db
/lib/libnss_dns.so.X implémente dns
/lib/libnss_files.so.X implémente files
/lib/libnss_hesiod.so.X implémente hesiod
/lib/libnss_nis.so.X implémente nis
/lib/libnss_nisplus.so.2 implémente nisplus

Notes

   Pour chaque processus utilisant nsswitch.conf, le fichier entier est lu une seule fois.
^
14 septembre 2010

htmlpdflatexmanmd




nsupdate

nsupdate

Envoie des requêtes de mise à jour dynamique

OPTIONS

-d mode debug
-D Affiche des info de debuggage additionnels à -d
-L Définit le niveau de debug.
-g Active le mode GSS-TSIG standard
-o utilise une variant de GSS-TSIG utilisé par windows 2000
-y [hmac:]keyname:secret génère une signature avec [hmac:]keyname:secret
-k keyfile lit le secret partagé depuis le fichier spécifié. Ce fichier peut être de 2 formats différent, un simple fichier contenant une déclaration de clé dans le style named.conf, qui peut être déclaré par ddns-confgen, ou une paire de fichiers dont les noms sont au format Kname.+157.+random.key et Kname.+157.+random.private, qui peuvent être générés par dnssec-keygen.
-l lance nsupdate en mode localhost uniquement. Définis l'adresse du serveur à localhost. Les connections utiliserons une clé TSIG trouvé dans /var/run/named/session.key, automatiquement généré par named si une zone maitre a update-policy à local.
-v force l'utilisation de TCP
-p définis le numéro de port par défaut pour les connections au serveur de nom
-t timeout définis le temps maximum d'une requête de mise à jours avant d'être abordées. défaut 300sec.
-u udptimeout définit l'interval UDP retry. défaut 3 sec. à 0, calcul l'interval depuis le timeout et le nombre de retry.
-r définis le nombre de retry. défaut : 3
-R randomdev Spécifie la source de random.
-P Affiche les listes de type non-méta pour lequels le format de présentation spécifique au type sont connus. Affiche la liste de types privés spécifiques à named.
-T Idem, mais affiche la liste de type assignés par l'IANA

Format d'entrée

server servername [port] Envoie les requêtes au serveur de noms spécifié
local address [port] Envoie les requêtes en utilisant l'adresse local spécifiée.
zone zonename Spécifie que toues les mises à jours sont faites dans la zone spécifiée
class classname Spécifie la calle par défaut
ttl seconds Spécifie le ttl par défaut pour les records. none efface le ttl par défaut
key [hmac:]keyname secret Spécifie le clé pour signer toutes les mises à jours.
gsstsig Utilise GSS-TSIG pour signer la mise à jours. équivalent à -g
ordgsstsig Utilise la version Windows 2000 de GSS-TSIG pour signer la mise à jours. Équivalent à -o
realm [realm_name] Avec GSS_TSIG, utiliser le domaine spécifié au lieu du domaine kerberos de krb5.conf
[prereq] nxdomain domain-name Requière qu'aucun record n'existe avec le nom domain-name
[prereq] yxdomain domain-name Requière que domain-name existe
[prereq] nxrrset domain-name [class] type requière qu'aucun record du type spécifié n'existe.
[prereq] yxrrset domain-name [class] type requière qu'un record du type spécifié existe
[update] del[ete] domain-name [ttl] [class] [type [data...]] supprime tout record correspondant au domain-name, type et class
[update] add domain-name ttl [class] type data... Ajoute un nouveau record
show Affiche le message courant, contenant tous les prérequis et updates spécifiés depuis le dernier envoie
send Envoie le message courant. Est équivalent à entrer une ligne blanche
answer Affiche la réponse
debug Active le debuggage

Exemples

supprimer et ajouter des records pour la zone example.com
nsupdate
› update delete oldhost.example.com A
› update add newshost.example.com 86400 A 172.16.1.1
› send
Vérifie qu'il n'existe pas déjà un record avant de l'ajouter:
nsupdate
› prereq nsdomain nickname.example.com
› update add nickname.exaple.com 86400 CNAME somehost.example.com
› send
^
20 décembre 2015

htmlpdflatexmanmd




NUMA

NUMA

Système NUMA - introduction

   Les information relatives à numa peuvent être trouvées dans /sys/devices/system/node/

  /proc/‹pid›/numa_maps donne des informations sur la stratégie mémoire et l'allocation NUMA utilisée pour le processus. Chaque ligne contient des informations sur la plage mémoire utilisé par le processus.

   Le premier champ de chaque ligne montre l'adresse de début de la plage mémoire. Ce champ permet de corréler avec le contenu de /proc/‹pid›/maps, qui contient l'adresse de fin de la plage et d'autres informations, tel que les permissions d'accès et le partage

   Le second champ montre la stratégie mémoire actuellement effective pour la plage mémoire. Noter que la stratégie mémoire n'est pas nécessairement la stratégie installée par le processus pour cette plage mémoire. Spécifiquement, si le processus a installé une stratégie défaut pour cette plage, la stratégie effective pour cette plage sera la stratégie du processus, qui peut ou non être le défaut.

   Le reste de la ligne contient des informations sur les pages allouées dans la plage mémoire, comme suit:

N‹node›=‹nr_pages› le nombre de pages allouées dans le nœud. nr_pages inclus seulement les pages actuellement mappées par le processus. La migration de page et la réclamation de mémoire peut avoir des pages non mappées temporairement associées avec cette plage mémoire.
file=‹filename› le fichier concerné par la plage mémoire. Si le fichier est mappé comme privé, les accès d'écriture peuvent avoir généré des pages COW dans cette plage mémoire. Ces pages sont affichées comme pages anonymes.
heap plage mémoire utilisée pour le heap
stack plage mémoire utilisée pour la pile
huge plage de grandes mémoire
anon=‹pages› nombre de pages anonymes dans la plage
dirty=‹pages› nombre de dirty pages
mapped=‹pages› nombre total de pages mappées, si différent des pages dirty et anon
mapmax=‹count› mapcount maximum (nombre de processus mappant une seule page
swapcache=‹count› Nombre de pages qui ont une entrée associée dans le swap
active=‹pages› Nombre de pages dans la liste active. affiché seulement s'il est différent du nombre de pages dans cette plage. Cela signifie que des pages inactives existent dans la plage mémoire.
writeback=‹pages› Nombre de pages actuellement en cour d'écriture sur disque

^
20 décembre 2015

htmlpdflatexmanmd




numactl

numactl

Contrôle la stratégie NUMA pour les processus ou le partage mémoire

   numactl lance les processus avec une planification NUMA spécifique ou stratégie de placement mémoire. La stratégie est définis pour la commande héritée par tous ses enfants. De plus il peut définir une stratégie persistante pour les segments de mémoire partagée ou fichiers.

   Les nœuds peuvent être spécifié comme N,N,N ou N-N ou N,N-N ou N-N,N-N. Les nœuds relatifs peuvent être spécifiés comme +N,N,N ou +N-N ou +N,N-N. + indique que les numéros de nœuds sont relatifs au jeu de processus de nœud permis dans son cpuset actuel. !N-N indique l'inverse de N-N. Au lieu d'un numéro de nœud, un nœud peut également être:

netdev:DEV Le nœud connecté au périphérique réseau dev
file:PATH Le périphérique block PATH
ip:HOST le nœud du périphérique réseau de HOST
block:PATH le nœud du périphérique block PATH
pci:[seg:]bus:dev[:func] le nœud du périphérique PCI

   Noter que block résout les noms de périphériques block du kernel seulement pour les noms udev dans le fichier dans /dev.

  Les paramètres de stratégie sont:‹/br›

--all, -a reset le cpuset par défaut, afin qu'il soit possible d'utiliser tous les cpu/nœuds pour les paramètres de stratégie suivante.
--interleave=nodes, -i nodes Définie une stratégie d'entrelacement mémoire. La mémoire sera allouée en utilisant un round robin dans les nœuds. Plusieurs nœuds peuvent être spécifiés dans --interleave, --membind et --cpunodebind
--membind=nodes, -m nodes Alloue la mémoire uniquement dans les nœuds. L'allocation échoue s'il n'y a pas suffisamment de mémoire disponible dans ces nœuds.
--cpunodebind=nodes, -N nodes Execute le processus seulement sur les cpus spécifiés. Accepte les numéros de cpu comme affiché dans le champ processor de /proc/cpuinfo ou les cpus relatifs dans le cpuset courant. "all" est accepté, qui signifie tous les cpu du cpuset.
--localalloc, -l Alloue toujours dans le nœud courant
--preferred=node Alloue la mémoire de préférence dans le nœud spécifié, mais si la mémoire ne peut être allouée, utilise d'autres nœuds.
--show, -s Affiche les paramètre de stratéie numa du processus courant
--hardware, -H Affiche l'inventaire des nœuds disponible dans le système.

           numactl peut définir une stratégie pour un segment de mémoire partagée SYSV ou un fichier dans shmfs/hugetlbfs. Cette stratégie est persistante et sera toujours utilisée par tous les mappages de cette mémoire partagée. L'ordre des options a une signification ici. La spécification doit au moins inclure --shm, --shmid, --file pour spécifier le segment de mémoire partagée ou le fichie et une stratégie mémoire comme décrite plus haut ( --interleave, --localalloc, --preferred, --membind ).

--huge En créant un segment de mémoire partagée SYSV, utilise des grandes pages. Seulement valide avant --shmid ou --shm
--offset Spécifie l'offset dans le segment de mémoire partagé. défaut: 0. Les unités valides sont m (Mo), g(Go), k(Ko), sinon est spécifié en octets.
--strict Donne une erreur quand une page dans l'aire de stratégie dans le segment de mémoire partagée a déjà généré une faute avec un conflit de stratégie. par défaut, ignore silencieusement.
--shmmode shmmode seulement valide avant --shmid ou shm en créant un segment de mémoire partagé avec un mode numérique shmmode.
--length length Applique la stratégie à la longueur de plage du segment de mémoire partagée ou créé la longueur du segment. par défaut, utilise la longueur restante requise quand un segment de mémoire partagée est créé et spécifie la longueur du nouveau segment. Les unités de valeurs sont m, g, k ou en octet par défaut.
--shmid id Créé ou utilise un segment de mémoire partagé avec l'id numérique spécifié
--shm shmkeyfile Crée ou utilise un segment de mémoire partagé, avec l'id généré en utilisant fotk(3) depuis shmkeyfile.
--file tmpfsfile Définis la stratgie pour un fichier dans tmpfs ou hugetlbfs
--touch Touch les pages pour forcer la stratégie. Ne les touch pas par défaut, la stratégie est appliquée quand une application mappe et accède à une page.
--dump Dump la stratégie dans la plage spécifiée
--dump-nodes Dump tous les nœuds de la plage spécifique (très verbeux!)

   Les spécifieurs de nœud valides sont:

all tous les nœuds
number Numéro de nœud
number1{,number2} nœud number1 et nœud number2
number1-number2 plage de nœuds
! nodes Inverse la sélection

Exemples

Lance myapplic sur les cpu 0-4 et 8-12 du cpuset courant:
numactl --physcpubind=+0-4,8-12 myapplic arguments
Lance une grosse base avec sa mémoire entrelacée sur tous les CPU:
numactl --interleave=all bigdatabase arguments
Lance le process dans le nœud 0 avec la mémoire allouée dans les nœuds 0 et 1:
numactl --cpunodebind=0 --membind=0,1 process
Idem, mais avec une option (-l) qui peut être confondue avec une option numactl:
numactl --cpunodebind=0 --membind=0,1 -- process -l
Lance network-server dans le nœud de périphérique réseau eth0 avec sa mémoire également dans le même nœud:
numactl --cpunodebind=netdev:eth0 --membind=netdev:eth0 network-server
Définis le nœud 1 comme préféré et affiche l'état résultant:
numactl --preferred=1 numactl --show
Entrelace toute la région mémoire partagée sysv spécifiée par /tmp/shmkey sur tous les nœuds:
numactl --interleave=all --shm /tmp/shmkey
Place un fichier tmpfs dans 2 nœuds:
numactl --membind=2 dd if=/dev/zero of=/dev/shm/A bs=1M count=1024
numactl --membind=3 dd if=/dev/zero of=/dev/shm/A seek=1024 bs=1M count=1024
Réinitialise la stratégie pour le fichier de mémoire partagée file à la stratégie par défaut localalloc:
numactl --localalloc /dev/shm/file

Notes

   Les commande ne sont pas exécutée en utilisant un shell. Utiliser sh -c pour cela.

  Définir la stratégie pour un fichier hugetlbfs ne fonctionnement pas actuellement.

  Les segment de mémoire partagée plus grand que l'espace d'adressage ne peut pas être complètement sous stratégie.
^
20 décembre 2015

htmlpdflatexmanmd




numad

numad

Service en userspace qui fournis des conseils de placement et de gestion de processus pour utiliser efficacement les CPU et la mémoire dans le système avec une topologie NUMA

   numad est un service qui monitor la topologie NUMA et l'utilisation des ressources. Il tente de localiser les processus pour la localité NUMA, l'affinité, en ajustant dynamiquement pour changer les conditions système. numad fournis également un guide pour assister la gestion des applications avec une liaison manelle des ressources CPU et mémoire.

OPTIONS

-C 0|1 Cette option contrôle si numad traite le cache de fichier inactif comme mémoire disponible. Par défaut, il peut compter le cache de fichier inactif comme mémoire libre.
-d mode debug
-H ‹THP_scan_sleep_ms› Définis l'intervalle de scan transparent hugepage en milliseconde. /sys/kernel/mm/tranparent_hugepage/khugepaged/scan_sleep_millisecs est généralement de 10000ms par l'os. Le défaut est changé par numad à 1000ms vu que çà aide le service hugepage à être plus agressif quand il déplace la mémoire entre les nœuds. à 0, numad laisse la valeur du système. 100ms peut améliorer les performances des processus à forte charge qui utilisent de nombreuses transparent_hugepages.
-i ‹[min_interval:]max_interval› Interval de temps d'attente entre les scans système. Défaut: 5 (min) et 15 (max) secondes. max_interval à 0 cause le service à quitter. Une valeur plus grande diminue la charge de numad, mais diminue la réponse les charges changeantes.
-K 0|1 Cette options contrôle si numad conserve entrelacement de la propagation de mémoire au travers des nœuds NUMA, ou tente de fusionner la mémoire entrelacée dans les nœuds NUMA locaux. Le mode par défaut est de fusionner la mémoire entrelacée C'est approprié pour localiser les processus dans un sous-jeu des nœuds NUMA du système. Si vous lancez une grosse application simple instance que alloue de la mémoire entrelacée parce que la charge aura des motifs d'accès mémoire imprédictibles, les résultats seront meilleur avec -K 1 pour instruire numad de conserver la mémoire entrelacée distribuée.
-l ‹log_level› Définis le niveau de log. défaut: 5
-m ‹target_memory_locality› Définis le seuil de localité mémoire désiré pour stopper le déplacement de mémoire. numad peut arrêter de traiter la mémoire quand plus de ce pourcentage de mémoire du processus est déjà localisé dans le ou les nœuds cible. le défaut est 90%. numad localise fréquemment ce seuil mais ne le fait pas nécessairement. à 100%, numad tente en permanence de déplacer la mémoire que le kernel n'arrivera jamais à déplacer.
-p ‹PID› ajoute le pid à la liste d'inclusion des processus à considérer pour la gestion, si le processus utilise déjà des ressources significative. Peut être spécifié plusieurs fois au démarrage, mais une fois lancé, un seul pid peut être ajouté à la liste d'inclusion par invocation de numad. Utilisé avec -S pour contrôler précisemment le périmètre des processus que numad peut gérer. Noter que ce processus spécifié ne sera pas nécessairement géré activement sauf s'il rencontre le seuil de numad, qui est actuellement de 300Mo et 1/2 CPU.
-r ‹PID› Supprime le pid des liste d'inclusion et d'exclusion des processus. une foir le service démarré, seul un PID peut être supprimé par invocation de numad. Avec -S, -p et -x pour contrôler précisemment le périmètre des processus que numad peut gérer.
-R ‹CPU_LIST› Spécifie une liste de cpu que numad devrait considérer comme réservé pour une utilisation non numad. Aucun processus ne sera lié aux CPU spécifiés par numad. Cette option est seulement effective quand numad démarre.
-S 0|1 Cette option contrôle si numad scanne tous les processus système ou seulement les processus dans la liste d'inclusion PID. Scan tous les processus par défaut. -S 0 scanne seulement la liste d'inclusion PID . numad -S 0 -p ‹PID-1› -p ‹PID-2› -p ‹PID-3› limit le scan, et donc la gestion automatique NUMA, à seulement 3 processus.
-t ‹logical_CPU_percent› Spécifie la valeur de ressource des CPU logique. Les threads hardware partagent généralement pluse de ressources, et ces CPU logiques ajoutent seulement une fraction de puissance CPU. Par défaut numad considère les CPU logiques à seulement 20% d'un cœur hardware dédié.
-u ‹target_utilization› Définis le pourcentage de consommation d'un nœud. Défaut: 85%. Diminuer cette valeur pour maintenir plus de ressource disponible dans chaque nœud. à 100, les performances systèmes sont améliorée. Il est possible d'aller jusqu'à 130 pour surcharger les CPU dans les nœuds, mais l'utilisation mémoire est toujours plafonnée à 100%.
-v mode verbeux
-w ‹NCPUS[:MB]› demande à numad les meilleurs nœuds NUMA pour lier une entité qui nécessite ‹NCPUS›. La quantité de mémoire est optionnelle, mais devrait normallement être spécifiée pour que numad recommande les nœuds NUMA avec la capacité CPU disponible et la mémoire disponible. La sortie de cette option est une chaîne qui contient une liste de nœud NUMA. Cette liste devrait être placé dans une variable (ex:NODES), et utilisé comme paramètre dans numactl -m $NODES -N $MODES ...
-x ‹PID› Ajoute le PID à la liste d'exclusion de processus à blacklister de la gestion. Peut être spécifié plusieurs fois au démarrage, mais une seul fois ensuite par invocation de numad. avec -S permet de contrôle précisemment le périmètre des processus que numad peut gérer.

Exemples

numad peut être lancé comme service système:
/usr/bin/numad
les autres invocation de numad peuvent être utilisé pour changer dynamiquement les options à chaud:
/usr/bin/numad -i0
^
21 décembre 2015

htmlpdflatexmanmd




numastat

numastat

Affiche des statistiques mémoire par nœud numa pour les processus et l'os

   numastat sans options ou argument, affiche des statistiques par nœud numa avec les champs suivant:

numa_hit Mémoire allouée avec succès dans ce nœud comme prévu
numa_miss Mémoire allouée dans ce nœud en dépit des préférences de processus Chaque numa_miss a un numa_foreign dans un autre nœud
numa_foreign est la mémoire prévu pour ce nœud, mais actuellement allouée dans un nœud différent.
interleave_hit Mémoire entrelacée allouée avec succès dans ce nœud comme prévu
local_node mémoire allouée dans ce nœud alors qu'un processus fonctionnait dessus
other_node mémoire allouée dans ce nœud alors qu'un processus fonctionnait dans un autre nœud.

OPTIONS

-c Minimise la table affichée
-m Afiche les informations mémoire système type meminfo.
-p ‹PID› ou ‹pattern› Affiche les informations mémoire par nœud pour le pid ou motif spécifié.
-s[‹node›] Trie les données de la table dans l'ordre descendant.
-v Rapport plus verbeux
-z Enlève les données 0 de la table
^
21 décembre 2015

htmlpdflatexmanmd




numatop

numatop

Outil d'analyse pour l'accès mémoire

   Les système modernes utilisent un concept NUMA (Non-Uniform Memory Access) pour le multi-cpu. Dans les systèmes NUMA et les processeurs organisés de telle manière que certaines parties de la mémoire sont proches d'un processeur donné, alors que d'autres parties sont plus éloignées. Un processeur peut accéder à la mémoire proche de lui plus rapidement que la mémoire éloignée.

   numatop est un outil d'observation pour la caractérisation de localité mémoire en temps-réel et d'analyse de processus et threads tournant dans un système NUMA. Il aide l'utilisateur à caractériser le fonctionnement NUMA des processus et threads et d'identifier où les goulots d'étranglement se produisent en terme de performances. L'outil utilise la technologie de compteur de performance Intel et associe les données de performances avec les informations temps réel de Linux pour fournir une analyse temps-réel dans les systèmes de production. L'outil peut être utilisé pour:

- caractériser la localité de tous les processus et threads pour identifier ceux ayant la localité la plus pauvre dans le système.
- Identifier les aires de mémoire "hot", indiquer la latence mémoire moyenne, et fournir l'emplacement où la mémoire accédée est allouée. Une aire de mémoire "hot" est où les accès process/thread sont les plus fréquent. numatop a un métrique appelé "ACCESS%" qui spécifie le pourcentage d'accès mémoire attribuable à chaque aire mémoire. numatop n'enregistre que les accès mémoire qui ont des latences supérieures à ceux prédéfinis par le seuil (128 cycles cpu)
- Fournis les call-chain dans le code process/thread qui accède à une aire mémoire hot.
- Fournis call-chain quand le process/thread génère certains compteurs d'évènement (RMA/LMA/IR/CYCLE). Les call-chain aident à localiser le code source qui génèrent les évènements.

        RMA Remote Memory Access
        LMA Local Memory Access
        IR Instruction Retired
        CYCLE cycles CPU

- Fournir des statistiques par nœud pour l'utilisation mémoire et CPU. Un nœud est une région de mémoire dans laquelle tout octet a la même distance de chaque CPU.
- Affiche, en utilisant une interface user-friendly, la liste des process/thread triés par certaines métriques (par défaut, trié par l'utilisation CPU). Les utilisateur peuvent également utiliser les raccourcis pour retrier la sortie par ces métriques: RMA, LMA, RMA/LMA, CPI et CPU%.

        RMA/LMA ratio de RMA/LMA
        CPI cycle CPU par instruction
        CPU% utilisation CPU

   numatop est un outil GUI qui traque et analyse périodiquement l'activité NUMA des processus et threads et affiche des métriques utiles.

   Ci-dessous est une description détaillée des diverses affichages et les éléments de données qu'elles affichent.

WIN1 - Supervision des processus et threads

   Affiche la caractérisation de localité de tous les processus. C'est la première fenêtre affichée a démarrage. Cette fenêtre affiche une liste de processus, trié par % de CPU. Généralement, le processus intensifs en mémoire est également intensif en CPU. les touches 1,2,3,4, et 5 permettent de trier la sortie par RMA, LMA, RMA/LMA, CPI, et CPU%, respectivement.

        RAM(K) nombre de RMA (l'unité est 1000)
        LMA(K) nombre de LMA (l'unité est 1000)
        RMA/LMA ratio de RMA/LMA
        CPI cycles CPU par instruction
        CPU% utilisation CPU du système

        Q quitter l'application
        H Rafraîchir la fenêtre
        R Rafraîchis les données
        I Passer à WIN2
        N Passer à WIN11
        1 Trier par RMA
        2 Trier par LMA
        3 Trier par ratio RMA/LMA
        4 Trier par CPI
        5 Trier par CPU%

WIN2 - Supervision des processus et threads (normalisée)

   Affiche la caractérisation de localité normalisée de tous les processus

        RPI(K) RMA normalisé par 1000 instructions: RPI(K) = RMA/ (IR / 1000)
        LPI(K) LMA normalisé par 1000 instructions: RPI(K) = LMA/ (IR / 1000)
        Les autres métrique sont les mêmes.

        Q quitter l'application
        H Passer à WIN1
        B Retour à la précédent fenêtre
        R Rafraîchis les données
        N Passer à WIN11
        1 Trier par RPI
        2 Trier par LPI
        3 Trier par ratio RMA/LMA
        4 Trier par CPI
        5 Trier par CPU%

WIN3 - Supervision de processus

   Affiche la caractérisation de localité avec l'affinité de nœud d'un processus spécifié

        NODE L'id de nœud
        CPU% UTilisation CPU par nœud
        Les autres métriques restent les mêmes

        Q quitter l'application
        H Passer à WIN1
        B Retour à la précédent fenêtre
        R Rafraîchis les données
        N Passer à WIN11
        L Affiche les informations de latence
        C Affiche le call-chain

WIN4 - Supervision de tous les threads

   Affiche la caractérisation de localité de tous les threads dans un processus spécifié.

WIN6 - Supervision des aires mémoire

   Affiche l'utilisation d'aire mémoire avec la latence d'accès associée d'un process/thread

        ADDR Addresse de début de l'aire mémoire
        SIZE Taille de l'aire mémoire
        ACCESS% Pourcentage d'accès mémoire fait dans cette aire mémoire
        LAT(ns) La latence moyenne des accès mémoire
        DESC Description de l'aire mémoire

        Q quitter l'application
        H Passer à WIN1
        B Retour à la précédent fenêtre
        R Rafraîchis les données
        A Affiche la distribution de nœuds d'accès mémoire
        C Affiche le call-chain quand les process/thread accèdent à la mémoire.

WIN7 - vue générale de distribution de nœuds d'accès mémoire

   Affiche le pourcentage d'accès mémoire venant du process/thread de chaque nœud

        Q quitter l'application
        H Passer à WIN1
        B Retour à la précédent fenêtre
        R Rafraîchis les données

WIN8 - sépare l'aire mémoire dans la mémoire physique dans le nœud

   Sépare l'aire mémoire dans le mappage physique dans le nœud avec la latence d'accès associée d'un processus/thread.

WIN9 - Call-chain quand les process/threads génèrent l'evènement (RMA/LMA/CYCLE/IR)

   Détermire les call-chains du code qui génère RMA/LMA/CYCLE/IR

        Q quitter l'application
        H Passer à WIN1
        B Retour à la précédent fenêtre
        R Rafraîchis les données
        1 Localise le call-chain quand le processus/thread génère RMA
        2 Localise le call-chain quand le processus/thread génère LMA
        3 Localise le call-chain quand le processus/thread génère CYCLE
        4 Localise le call-chain quand le processus/thread génère IR

WIN10 - Call-chain quand le process/thread accède à l'aire mémoire

   Détermine les call-chains du code qui référence cette aire mémoire. La latence doit être supérieure au seuil de latence prédéfinis (128 cycles CPU)

WIN11 - Vue générale des nœuds

   Affiche les statistiques de base par nœud pour ce système

        MEM.ALL RAM utilisable totale (physique moins quelques octets réservés et le code du kernel)
        MEM.FREE Somme LowFree + HighFree
        CPU% UTilisation CPU par nœud

WIN12 - information de nœud

   Affiche l'utilisation et CPU pour le nœud sélectionné

        CPU Tableau de cpu logiques appartenant à ce nœud
        CPU% Utilisation de CPU par nœud
        MEM active quantité de mémoire utilisé la plus récemment et n'est pas réclamé
        MEM inactive Quantité de mémoire qui n'a pas été utilisé depuis un certain temps et est éligible au swap
        Dirty Quantité de mémoire attendant d'être écrite sur disque
        Writeback Quantité de mémoire activement écrite sur le disque
        Mapped Toutes les pages mappée dans un processus

OPTIONS

-s sampling_precision balance entre précision et charge(normal), précision(high), faible charge(low). défaut: normal.
-l log_level Spécifie le niveau de log dans le fichier de log. valeurs valides: 2
-f log_file spécifie le fichier de log
-d dump_file Spécifie le fichier de dump

Exemples

Lancer numatop à haute précision:
numatop -s high
Écrire tous les messages d'alerte dans /tmp/numatop.log:
numatop -l 2 -o /tmp/numatop.log
Dump les données de l'écrant dans /tmp/dump.log:
numatop -d /tmp/dump.log

Notes

   Il est nécessaire d'avoir les privilèges root pour lancer numatop, ou de définir /proc/sys/kernel/perf_event_paranoid à 1. numatop supporte les processeurs Intel Xeon.
^
05 juin 2010

htmlpdflatexmanmd




od

od

Écrit une représentation de chaque fichier ou de l'entrée standard

   Chaque ligne de sortie consiste de l'offset dans l'entrée, suivie par un groupe de données du fichier. Par défaut, od affiche l'offset en octal, et chaque groupe de donnée du fichier est de type short int. Si OFFSET est donné, il spécifie combien d'octets passer avant de formater et afficher l'entrée. interprété en octal par défaut.

OPTIONS

-A RADIX, --address-radix=RADIX Selectionne la base pour l'affichage de l'offset :

        d décimal
        o octal
        x hexadécimal
        n n'affiche pas l'offset

-J BYTES, --skip-bytes=BYTES Permet de sauter BYTES octets au début du fichier. si BYTES commence par '0x' ou '0X', il est interprété en hexadécimal, s'il commence par 'O', en octal et sans préfix, en décimal. On peut ajouter un facteur multiplicatif :

        b 512 octets
        KB 10000 octets
        K 1024 octets
        etc...

-N BYTES, --read-bytes=BYTES Sort BYTES octets de l'entrée. les préfixes et suffix sont identique à l'option -J
-S BYTES, --strings[=BYTES] Sort uniquement "string constants" : au moins BYTES caractères graphique ASCII consécutifs, suivis par un ASCII NUL. Les préfixe et les suffixes sont identiques à l'option -J
-t TYPE, --format=TYPE Sélectionne le format de sortie des données du fichier. TYPE est une chaîne d'un ou plusieurs caractère indicateur. suffixer avec 'z' permet d'afficher la représentation ascii à la fin de la ligne, à la façon d'un éditeur hexadécimal.

        a nom du caractère.
        c caractère ASCII
        d décimal signé
        f virgule flottante
        o octal
        u décimal non signé
        x hexadécimal

           Hormis a et c, vous pouvez spécifier le nombre d'octets à utiliser pour interpréter chaque nombre en suffixant l'indicateur avec un entier décimal. Alternativement vous pouvez spécifier la taille avec un de ces types:

  pour d, o, u et x:

                C type char
                S type short
                I type integer
                L type long

           pour f:

                F type float
                D type double
                L type Long double

-v, --output-duplicate Sort les lignes consécutives qui sont identiques. Par défaut, en cas de plusieurs lignes consécutives identique, od ne sort que la première ligne et place un astérisk sur la ligne suivante.
-w[N], --width[=N] Dump N octets en entrée par ligne en sortie. défaut 16. si N est omis, défaut est 32.

           Les options suivante sont des formats cours pour des combinaisons d'options :

        -a Equivalent à -t a
        -b Equivalent à -t o1
        -c Equivalent à -t c
        -d Equivalent à -t u2
        -f Equivalent à -t fF
        -i Equivalent à -t dI
        -l Equivalent à -t dL
        -o Equivalent à -t o2
        -s Equivalent à -t d2
        -x Equivalent à -t x2

Exemples

Affichage dans le style d'un héditeur hexa :
od -vA x -t x2z -N 512 /dev/sda
^
10 mai 2016

htmlpdflatexmanmd




openca - ocspd

openca - ocspd

service OCSP

   openca-ocspd est un répondeur OCSP conforme à la rfc2560. Il peut être utilisé pour vérifier le status d'un certificat en utilisant les clients OCSP.

OPTIONS

-d Détache le processus principal du processus appelant
-p n Spécifie le port d'écoute. Défaut: 2560
-b address Spécifie l'adresse IP d'écoute. Défaut:_*
-c file Fichier de configuration. Défaut: /usr/local/etc/ocspd.conf
-md digest Spécifie le hash à utiliser pour générer les réponses. Défaut: sha1
-k passwd Spécifie le mot de passe utilisé pour charger la clé privée
-i passin Source du mot de passe de la clé
-engine id Spécifie un engine
-r chroot_dir chroot l'application dans le répertoire spécifié
-v Affiche des détails sur les opération effectuées
^
10 mai 2016

htmlpdflatexmanmd




openca - ocspd.conf

openca - ocspd.conf

Fichier de configuration pour openca-ocspd

   Le fichier de configuration est divisé en sections, et est conforme à la syntaxe spécifiée dans openssl-config.

Exemple


[ ocspd ]
default_ocspd = OCSPD_default
    
[ OCSPD_default ]
    
dir = /usr/local/etc/ocspd
db = $dir/index.txt
md = sha1
    
ca_certificate = $dir/certs/cacert.pem
ocspd_certificate = $dir/certs/ocspd_cert.pem
ocspd_key = $dir/private/ocspd_key.pem
pidfile = $dir/ocspd.pid
    
user = ocspd
group = daemon
bind = *
port = 2560
max_childs_num = 5
max_req_size = 8192
    
request = ocsp_req
response = ocsp_response
    
dbms = dbms_ldap # Example using the LDAP for CRL retrivial
    
#dbms = dbms_file # Example using file for CRL
    
engine = HSM # ENGINE section
    
####################################################################
[ ocsp_req ]
default_keyfile = key.pem
    
####################################################################
[ ocsp_response ]
dir = /usr/local/etc/ocspd
ocsp_add_response_certs = $dir/certs/chain_certs.pem
ocsp_add_response_keyid = yes
next_update_days = 0
next_update_mins = 5
    
####################################################################
[ dbms_ldap ]
    
# It is possible to use an URI to identify a CRL and/or the CA certificate, the general format is:
# [protocol]://[user[:pwd]@]server[:port]/[path]
#
# where:
# protocol - specifies the protocol to be used, supported are
# file, ldap, http
# user - is the user for auth (meaningful only if ldap or
# http is used)
# pwd - password used for auth (meaningful only if ldap
# or http is used)
# port - port to connect to (meaningful only if ldap or
# http is used)
# path - complete path to the object (meaningful only if
# http is used)
#
# You can have the CRLs/CA certificates on a simple file
# crl_url = file:///usr/local/etc/ocspd/crl.pem
#
# You can retrieve the CRLs/CA certificates from a web server
# crl_urt = http://server/ca/cacert.der
#
# You can store the CRL into an LDAP server, simply
# store it in certificateRevocationList;binary attribute
#
# There are different way, all legal, to specify the CRL
# URL address:
# crl_url = ldap://user:pwd@ldap.server.org:389
# crl_url = ldap://ldap.server.org:389
crl_url = ldap://localhost
    
# The CRL entry DN is the DN to look for when retrieving the
# date from the LDAP server. Put here the complete DN (usually
# the DN of the CA's certificate).
crl_entry_dn = "email=email@address, cn=Certification Auth, \
o=Organization, c=IT"
    
####################################################################
[ dbms_file ]
    
# You can have the CRL on a simple file in PEM format
crl_url = file:///usr/local/etc/ocspd/crl.pem
    
[ HSM ]
# Hardware accelerators support via the ENGINE interface
engine_id = MyAccelerator
0.engine_pre = login:1:10:11:myPassword
# 0.engine_post = logout:1:10:11

default_ocspd Dans cette section du fichier de configuration sont placés les options utilisées par le répondeur, certains sont disponibles en utilisant les options de la ligne de commande.
db Spécifie la db où tout est concervé. Actuellement, le seul format fichier supporté est celui de openssl.
md Spécifie le hash à utiliser. Défaut: sha1
ca_certificate Chemin vers de certificat de la CA
ocspd_certificate Chemin vers le certificat utilisé par le répondeur
ocspd_key Chemin de la clé privée du certificat utilisé par le répondeur
pidfile fichier du pid du processus
user UID du processus
group GID du processus
bind Adresse d'écoute
port Port d'écoute
threads_num Nombre de threads qui devraient être créés au démarrage. plus le nombre est élevé, plus il peut gérer les fort trafics.
chroot_dir chroot d'application dans le répertoire spécifié
max_req_size Taille maximum de requête reçue. Au delà la requête est détruite. Généralement les requêtes font environ 200/300 octets
request section non utilisé actuellement
response section Ici sont conservés les options pour la construction des réponses
dbms Options pour la crl
ocsp_add_response_certs Chemin d'un fichier contentant les certificats à ajouter à la réponse (généralement toute la chaîne de certification).
ocsp_add_response_keyid Spécifie si l'id de clé est ajouté dans la réponse
next_update_days Nombre de jours jusqu'à la prochaine mise à jours.
next_update_mins idem pour la partie minutes. La réponse est valide pour days+mins
ca_url URI où le certificat de la CA est localisée. (file:// http:// ou ldap://)
crl_url URI où la crl est localisée (file:// http:// ou ldap://)
crl_entry_dn avec ldap, spécifie le dn où rechercher l'attribut certificateRevocationList
engine_id Spécifie l'id de l'engine
engine_pre, engine_post Paramètres d'initialisation du périphérique
^
13 février 2012

htmlpdflatexmanmd




OpenCT

OpenCT

Pilotes pour cartes à puce

   Openct implémente des pilotes pour de nombreux lecteurs de carte. Ils sont fournis au format ifdhandler requis pour pcsc-lite. OpenCT a également un mécanisme primitif pour exporter les lecteurs de carte sur des machines distantes via tcp/ip.

Présentation générale

Le scénario le plus simple et recommandé est:
Application (ex : mozilla)
librairie PKCS11(ex : OpenSC)
OpenCT
Kernel Linux

   Mozilla peut charger les modules de sécurité implémentant PKCS11, opensc le fait et a une interface directe pour utiliser openCT

Parfois vous avez cette pile:
Application
PC-SC/Lite
Driver
Kernel

   PC/SC est un standard sous Windows, donc de nombreuses applications veulent l’utiliser pour communiquer avec les cartes à puce. pcsclite a besoin de pilotes au format ifdhandler. OpenCT a un pilote au format ifdhandler.

Le 3ème modèle:
Application
Driver

   est très simple et a été conçus pour DOS.Il fonctionne très bien pour une application et un utilisateur. Il n’est plus utilisé.

Système d'exploitation

   Les lecteurs de carte USB necéssitent un support USB pour que OpenCT soit notifié. hotplug tend à être remplacé par udev ou hald.

Configurer udev

Pour le support USB sous Linux vous devez avoir:
- libusb
- CONFIG_HOTPLUG pour que le kernel laisse savoir si un lecteur ou un token est branché
- udev installé
- Copier les fichiers suivant:
/lib/udev/rules.d/50-openct.rules
/lib/udev/openct_usb
/lib/udev/openct_pcmcia
/lib/udev/openct_serial

Accès au lecteur de carte distant

   cette fonctionnalité n’inclus aucun mécanisme de sécurité.

Sur la machine avec le lecteur, ajouter à openct.conf (exemple avec un lecteur série):
reader xiring {
    driver = xiring;
    device = serial:/dev/ttyS0;
};

Démarrer ifdproxy pour pointer vers la machine distante:
ifdproxy export xiring /dev/ttyS0 ‹machine-distante› :‹port›

Sur la machine avec le logiciel, ajouter dans openct.conf:
ifdhandler = /usr/sbin/ifdhandler;
ifdproxy {
    server-port = /var/run/openct/proxy,
    device-port = :6666;
};
reader xiring {
    driver = xiring;
    device = remote:serial1@/var/run/openct/proxy;
};

Démarrer openct
/etc/init.d/openct start
ifdproxy server
^
13 février 2012

htmlpdflatexmanmd




openct-control

openct-control

démon openct

OPTIONS

-d mode debug
-n  Désactiver le branchement à chaud
-f Spécifier le fichier de configuration (défaut : /etc/openct.conf)

Commandes

init initialiser openct
attach driver type device Attacher un périphérique
status Affiche le status de tous les lecteurs présent
shutdown Arrête le service OpenCT

Variables d'environnement

OPENCT_SOCKETDIR Spécifie l’emplacement pour les fichiers et sockets (défaut : /var/run/openct)
^
13 février 2012

htmlpdflatexmanmd




openct-tool

openct-tool

Utilitaire pour les cartes à puces openCT

OPTIONS

-d mode debug
-f Spécifier le fichier de configuration (défaut : /etc/openct.conf)
-r Index du lecteur de carte à utiliser

Commandes

list lister les lecteurs trouvés
atr Afficher l’ATR de la carte insérée
wait Attend que la carte soit insérée
rwait Attend qu’un lecteur de carte soit inséré
mf Tente de sélectionner le répertoire principal de la carte
read dump la mémoire de la carte synchrone
^
13 février 2012

htmlpdflatexmanmd




openct.conf

openct.conf

Fichier de configuration pour openct


debug = 0; # niveau de debug
hotplug = yes; # Active le mode hotplug
    
# Path to ifdhandler
ifdhandler {
    program = /usr/sbin/ifdhandler; # emplacement de l’ifdhandler
    force_poll = 1; # désactiver si ›=2.6.27.14 ou 2.6.28.3
    user = openctd;
    groups = {
        usb,
    };
};
    
ifdproxy { # configuration pour idfproxy
    server-port = /var/run/openct/.ifdproxy,
    device-port = :6666;
};
    
# Liste des lecteurs et leurs options
    
#reader towitoko {
# driver = towitoko;
# device = serial :/dev/ttyS0;
#};
    
#reader gempc {
# driver = gempc;
# device = serial :/dev/ttyS0;
#};
    
#reader cm4000 {
# driver = cm4000;
# device = pcmcia :/dev/cmm0;
#};
    
#reader cm4040 {
# driver = ccid;
# device = pcmcia_block :/dev/cmx0;
#};
    
#reader pertosmart1030 {
# driver = pertosmart1030;
# device = serial :/dev/ttyS0;
#};
    
# ID pour Hotplug
driver egate {
    ids = {
        usb:0973/0001,
    };
};

driver ePass3000 {
    ids = {
        usb:096e/0401,
    };
};

driver etoken {
    ids = {
        usb:0529/050c,
        usb:0529/0514,
    };
};
driver etoken64 {
    ids = {
        usb:0529/0600,
        usb:0529/0700,
    };
};
driver eutron {
    ids = {
        usb:073d/0005,
    };
};
driver ikey2k {
    ids = {
        usb:04b9/1202,
    };
};
driver ikey3k {
    ids = {
        usb:04b9/1300,
    };
};
driver starkey {
    ids = {
        usb:096e/0005,
    };
};
driver cardman {
    ids = {
# usb:076b/0596, # OMNIKEY CardMan 2020
# usb:076b/1784, # OMNIKEY CardMan 6020
# usb:08d4/0009, # Fujitsu Siemens SCR USB Reader
    };
};
driver ccid {
    ids = {
        usb:03f0/1024, # HP Keyboard with CCID reader
        usb:046a/0010, # Cherry smartboard G83-6744
        usb:04e6/5115,
        usb:04e6/5116,
        usb:04e6/5117, # SCM Micro token size reader
        usb:04e6/511d, # SCM Micro SCR3311
        usb:04e6/E001,
        usb:04e6/E003,
        usb:073d/0c00, # Eutron SimPocket (doesn’t work yet)
        usb:076b/1021, # OmniKey CardMan 1021
        usb:076b/3021,
        usb:076b/5121,
        usb:076b/5321, # OmniKey CardMan 5321
        usb:076b/6622, # OmniKey CardMan 6121
        usb:0783/0003,
        usb:08e6/3437, # Gemplus
        usb:08e6/3438, # Gemplus GemPC Key SmartCard Reader
        usb:08e6/4433, # Gemplus
        usb:0b97/7762, # O2 Micro, Inc. Oz776 SmartCard Reader
        usb:0b97/7772, # O2 Micro, Inc. Oz776 SmartCard Reader
        usb:0bf8/1006, # fujitsu siemens 3.5" drive size reader
        usb:0dc3/1004, # Athena Smartcard Solutions, Inc. ASEKey
        usb:0a89/0030, # Aktiv Rutoken ECP
    };
};
driver pertosmart1030 {
    ids = {
        usb:072f/0001,
        usb:072f/8009,
    };
};
driver pertosmart1038 {
    ids = {
        usb:072f/9000,
        usb:072f/9006, # ACS CryptoMate Token
        usb:072f/9007, # ACS ACR 100 SIMFlash
        usb:072f/90d0,
    };
};
#driver wbeiuu { # driver not working yet
# ids = {
# usb:104f/0004,
# };
#};
    
# Tested with USBID 0c4b:0100. These are red readers : one with LCD,
# another one without.
driver cyberjack {
    ids = {
        usb:0c4b/0100,
    };
};
driver rutoken {
    ids = {
        usb:0a89/0020, # Aktiv Rutoken S
        usb:0a89/0012, # Aktiv uaToken S
    };
};

^
26 septembre 2013

htmlpdflatexmanmd




OpenLDAP - Limites

OpenLDAP - Limites

configuration des limites de slapd

   Il est généralement préférable de limiter les ressources du serveur pour qu'il soit accessible à tous les clients. OpenLDAP fournit 2 type de limites : un limite de taille, qui peut être restreinte par le nombre d'entrées qu'un client peut récupérer en une seule opération, et une limite de temps, qui restreint le temps qu'une opération peut se poursuivre.

Limites Soft et Hard

   L'administrateur du serveur peut limiter les limites hard et soft. Les limites soft sont les valeurs de limite par défaut, les limites hard sont les limites qui ne peuvent pas être dépassée par les utilisateurs LDAP.

  Les clients LDAP peuvent spécifier leur propre limites de taille et de temps pour les opérations de recherche.

  Si le client spécifie une limite alors la plus faible des valeurs entre celle-ci et la hard limit sera choisie. Si le client ne spécifie pas de limite, la soft limit s'applique.

Le rootdn n'est pas sujet à ces limites.
sizelimit {‹integer›|unlimited} # défaut 500
timelimit {‹integer›|unlimited} # défaut 3600
Une forme étendue permet aux limites soft et hard d'être séparés.
sizelimit size[.{soft|hard|unchecked}]=‹integer› [...]
timelimit time.{soft=‹integer›} [...]
exemple
sizelimit size.soft=10 size.hard=75

   Le mot clé unchecked spécifie une limite du nombre d'entrées que le serveur va examiner une fois qu'il a crée un lot de résultats candidat en utilisant les indices. Ça peut être très important dans les gros annuaires, quand une recherche qui ne peut pas être satisfaite depuis un index peut nécessiter d'examiner des millions d'entrées.

Limites par base

   Chaque base de donnée peut avoir ses propres limites. La syntaxe est plus flexible, et permet différentes limites à appliquer à différentes entités. le terme entité est utilisé pour indiquer l'ID de la personne ou du processus qui a initié l'opération LDAP. Dans slapd.conf le mot clé est limits. En utilisant le backend slapd config, l'attribut correspondant est olcLimits. La syntaxe est la même dans les 2 cas.

limits ‹who› ‹limit› [‹limit› [ ... ]]

   la clause limits peut être spécifiée plusieurs fois. Le serveur examine chaque clause jusqu'à ce qu'il en trouve une qui corresponde à l'ID qui a requis l'opération. Si aucune correspondante n'est trouvée, les limites globales sont utilisées.

Spécifier à qui s'applique les limites

La partie ‹who› peut prendre les valeurs suivante:
*____________________________All, including anonymous and authenticated users
anonymous____________________Anonymous (non-authenticated) users
users________________________Authenticated users
self_________________________User associated with target entry
dn[.‹basic-style›]=‹regex›___Users matching a regular expression
dn.‹scope-style›=‹DN›________Users within scope of a DN
group[/oc[/at]]=‹pattern›____Members of a group

Spécifier des limites de temps

time.soft=‹integer›
où integer est la durée en seconde.
si soft ou hard ne sont pas spécifiés, la valeur est utilisée pour les 2:
limits anonymous time=27
la valeur unlimited peut être utilisé pour supprimer la limite de temps hard :
limits dn.exact="cn=anyuser,dc=example,dc=org" time.hard=unlimited
spécifier des tailles limites.
size[.soft|hard|unchecked]=integer›
où integer est le nombre d'entrée maximum que slapd va retourner.

Limites de taille et résultats paginés

   Si le client LDAP ajoute le pagedResultsControl pour les opérations de recherche, la limite de taille hard est utilisée par défaut, parce que la requête pour une taille de page spécifique est considérée comme une requête explicite pour une limitation sur un nombre d'entrée à retourner. Cependant, la taille limite s'applique au compteur total des entrées retournées dans la recherche, et pas dans une simple page.

size.pr={‹integer›|noEstimate|unlimited}

integer est la taille de page maximum si aucune taille implicite n'est donnée. noEstimate n'a pas d'effet dans l'implémentation courante vu que le serveur ne retourne pas une estimations de taille de résultat. unlimited indique qu'aucune limite n'est appliquée à la taille de page maximum.
size.prtotal contrôle le nombre total d'entrées qui peuvent être retournés par une recherche paginée. Par défaut la limite est la même que la limite size.hard.
size.prtotal={‹integer›|unlimited|disabled}
unlimited supprime la limite sur le nombre d'entrée qui peuvent être retournés par une recherche paginée. disabled peut être utilisé pour désactiver sélectivement les recherche de résultat paginés.

Exemples

cet exemple applique des limites de temps et de taille pour toutes les recherche par les utilisateurs, excepté rootdn.
sizelimit 50
timelimit 10
Limites hard et soft global: Il est parfois utile de limiter la taille des résultats mais de permettre aux clients de demander une limite plus élevée si nécessaire. Cela peut être fait en définissant des limites soft et hard séparés:
sizelimit size.soft=5 size.hard=100
Pour se prémunir des clients qui font des recherches non-indexées inefficaces, ajouter la limite unchecked:
sizelimit size.soft=5 size.hard=100 size.unchecked=100
Donner des limites plus grandes pour des utilisateurs spécifiques.
limits dn.exact="cn=anyuser,dc=example,dc=org" size=100000
limits dn.exact="cn=personnel,dc=example,dc=org" size=100000
limits dn.exact="cn=dirsync,dc=example,dc=org" size=100000
Il est généralement mieux d'éviter de mentionner des utilisateurs spécifiques dans la configuration serveur. Une meilleur manière est de donner des limites supérieurs à un groupe:
limits group/groupOfNames/member="cn=bigwigs,dc=example,dc=org" size=100000
Limiter qui peut faire des recherche paginées
limits group/groupOfNames/member="cn=dirsync,dc=example,dc=org" size.prtotal=unlimited
limits users size.soft=5 size.hard=100 size.prtotal=disabled
limits anonymous size.soft=2 size.hard=5 size.prtotal=disabled
^
19 octobre 2013

htmlpdflatexmanmd




OpenLDAP - Sécurité

OpenLDAP - Sécurité

Considérations de sécurité

Écoute sélective: Par défaut, slapd écoute sur toutes les adresses IPv4 et IPv6. Pour spécifier les ip sur lesquelles slapd écoute: slapd -h ldap://127.0.0.1
Firewall IP: Les capacités de firewalling IP du système peuvent être utilisées pour restreindre l'accès. Généralement, slapd écoute sur le port 389/tcp pour ldap:// et le port 636/tcp pour ldaps://. slapd peut être configuré pour écouter sur d'autres ports.
TCP Wrappers: TCP wrappers fournis un système de contrôle d'accès basé sur des règles pour contrôler les accès TCP/IP sur le serveur. Par exemple: slapd: 10.0.0.0/255.0.0.0 127.0.0.1: ALLOW, slapd ALL: DENY
Protection de confidentialité et d'intégrité de données: TLS peut être utilisé pour fournir une protection de confidentialité et d'intégrité de données. OpenLDAP supporte la négociation de TLS (SSL) via StartTLS et ldaps://. Des mécanismes SASL (Simple Authentication and Security Layer) comme DIGEST-MD5 et GSSAPI sont également disponible.
Facteurs de sécurité forte: Le serveur utilise SSF pour indiquer la force du mécanisme. Un SSF de 0 spécifie aucune protection, à 1 des protections d'intégrité sont en place. un SSF › 1 indiquent la longueur de clé de cryptage. par exemple: DES fait 56, 3DES fait 112, AES fait 128, 192 ou 256.

        'security' contrôle les opérations de restriction quand les protections appropriées ne sont pas en place. Exemple:
        security ssf=1 update_ssf=112
        requière une protection d'intégrité pour toutes les opérations et une protection 3DES ou équivalent, pour les opérations de mise à jour (add, delete, modify, etc.)

Méthodes d'authentification

   La méthode simple a 3 modes d'opération: anonyme, non-authentifié, authentifié par user/password.

  L'accès anonyme est requis en ne fournissant pas de nom et de mot de passe pour une simple opération. l'accès non authentifié est requis en fournissant un nom, mais pas de mot de passe. L'accès authentifié requière un nom valide et un mot de passe.

  le mécanisme anonyme est activé par défaut, il peut être désactivé par "disallow bind_anon".

  note: désactiver le mécanisme anonyme n'empêche pas les accès anonymes à l'annuaire. Pour exiger une authentification pour accéder à l'annuaire, utiliser "require authc"

   L'accès non-authentifié est désactivé par défaut et peut être activé par "allow bind_anon_cred"

  L'accès authentifié est activé par défaut. Cependant les mots de passe sont stockés en clair, il est recommandé de l'utiliser uniquement avec des session chiffrées. Il est recommandé que toutes les authentifications non protégées soient désactivées en utilisant par ex: security simple_bind=56 qui exige les simple_bind d'utiliser le cryptage DES ou meilleur.

  Le mécanisme d'authentification user/password peut être complètement désactivé en utilisant "disallow bind_simple".

Stockage des mots de passe

   Les mots de passe LDAP sont normalement stockés dans l'attribut userPassword. la RFC4519 spécifie que les mots de passe ne sont pas stockés sous forme chiffrée. Cela permet d'utiliser une grande quantité de mécanismes basés sur les mots de passe, comme DIGEST-MD5.

  Cependant, il peut être préférable de stocker un hash des mots de passe. slapd supporte plusieurs schémas de stockage.

  L'attribut userPassword peut avoir une ou plusieurs valeurs, et il est possible pour chaque valeur d'être stockées sous une forme différente. durant l'authentification, slapd va chercher un des mots de passe qui correspondrai. Le schéma de stockage est stocké comme préfixe dans la valeur, donc un hash utilisant SHA1 ressemblera à:

  userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3

Schéma de stockage de mot de passe SSHA

ces valeurs sont représentée sous la forme:
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
schéma de stockage de mot de passe CRYPT
Ce schéma utilise la fonction système crypt(3). Il produit le hash traditionnel à 13 caractères, mais peut également générer le hash MD5 34 octets de glibc2.
userPassword: {CRYPT}aUihad99hmev6
userPassword: {CRYPT}$1$czBJdDqS$TmkzUAb836oMxg/BmIwN.1

Schéma de stockage de mot de passe MD5

Ce schéma prend simplement le hash md5 et le stocke sous la forme base64:
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
schéma de stokage de mot de passe SMD5
Il améliore le schéma MD5
userPassword: {SMD5}4QWGWZpj9GCmfuqEvm8HtZhZS6E=
schéma de stockage de mot de passe SHA
SHA est plus sécurisé que MD5
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=

Schéma de stockage de mot de passe SASL

   Ce n’est pas vraiment un schéma de stockage de mot de passe. Il utilise l’attribut userPassword pour déléguer la vérification à un autre processus.

Schéma de stockage de mot de passe Kerberos

   Ce n’est pas un schéma de stockage de mot de passe, il utilise la valeur de l’attribut de userPassword pour déléguer la vérification à Kerberos

Authentification Externe

   Depuis OpenLDAP 2.0 slapd a la capacité de déléguer la vérification de mot de passe à un processus séparé. Il utilise la fonction sasl_checkpass(3). Le choix est très large, comme l’option d’utiliser saslauth(8) qui utiliser les fichiers local, kerberos, un serveur IMAP, un autre serveur LDAP ou tout ce qui peut supporter le mécanisme PAM.

  L’authentification externe fonctionne seulement avec les mots de passe en clair. ce système est sélectif, il utilise uniquement les utilisateurs dont l’attribut userPassword est marqué avec "SASL".

exemple:
userPassword: {SASL}username@realm

Configurer slapd pour l'utilisation d'un fournisseur d'authentification

   Quand une entrée a une valeur de mot de passe "{SASL}", OpenLDAP délègue tout le processus de validation à cyrus SASL. Tout la configuration est faite dans les fichiers de configuration de SASL.

  Un fichier nommé /usr/lib/sasl2/slapd.conf gouverne l’utilisation de SASL quand il communique avec slapd.

Simple exemple pour un serveur qui utilise saslauth pour vérifier les mots de passe:
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/sasl2/mux

Configurer saslauth

saslauthd est capable d’utiliser différents services d’authentification, vois saslauthd(8). Exemple de saslauthd.conf qui utilise M$ Active Directory:
ldap_servers: ldap://dc1.example.com/ ldap://dc2.example.com/
ldap_search_base: cn=Users,DC=ad,DC=example,DC=com
ldap_filter: (userPrincipalName=%u)
ldap_bind_dn: cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com
ldap_password: secret
dans ce cas, saslauthd est lancé avec le mécanisme d’authentification ldap et est définis pour combiner SASL avec le login:
saslauthd -a ldap -r
^
13 février 2012

htmlpdflatexmanmd




OpenSC

OpenSC

Librairie PKCS#11

   OpenSC est une librairie PKCS #11 ainsi qu'une API pour l'utiliser. Sur la carte, OpenSC implémente PKCS #15

^
13 février 2012

htmlpdflatexmanmd




opensc-explorer

opensc-explorer

Utilitaire intéractif pour accéder aux cartes à puce

OPTIONS

--reader, -r Utilise le numéro de lecteur de carte donné
--card-driver, -c Utilise le pilote de carte donné
--verbose, -v mode verbeux

Commandes

ls Liste tous les fichiers dans le DF courant
cd file-id Changer de DF spécifié par sont file-id
info [file-id] Affiche les attributs d’un fichier spécifié par son file-id
create file-id size Crée un nouveau EF en spécifiant sont file-id et sa taille
delete file-id Supprime le EF ou DF spécifié par son file-id
verify key-typekey-id [key] Présente un PIN ou une clé à la carte. le key-type peut être CHV, KEY ou PRO, le key-id est la clé ou le PIN et les clé est la clé ou le PIN à vérifié en hexa.
change CHVid [old-pin] new-pin Changer un pin
put file-id [input] Copie un fichier local sur la carte
get file-id [output] Copie un EF dans un fichier local
mkdir file-id size Créer un DF
pksign Créer un signature de clé publique. (actuellement non implémenté)
pkdecrypt Décrypte un clé publique. (actuellement non implémenté)
erase Efface la carte
quit Quitter le programme.
^
13 février 2012

htmlpdflatexmanmd




opensc-tool

opensc-tool

Utilitaire générique pour cartes à puce

OPTIONS

--atr, -a Affiche l’Answer To Reset de la carte, au format hexa
--serial Afficher le numéro de série de la carte (ICCSN) en hexa
--send-apdu, -s Envoie un APDU arbitraire à la carte au format AA:BB:CC:DD:EE:FF...
--list-files, -f Liste tous les fichiers stockés sur la carte
--list-readers, -l Liste tous les lecteurs configurés
--list-drivers, -D Liste tous les pilotes de carte installés
--list-rdrivers, -R Liste tous les pilotes de lecteur installés
--reader, -r Numéro du lecteur --card-driver, -c
Utilise le lecteur de carte donné --verbose, -v
Mode verbeux
^
13 février 2012

htmlpdflatexmanmd




opensc.conf

opensc.conf

Fichier de configuration pour OpenSC


app default {
    debug = 0 ; # niveau de debug
    debug_file = "/var/log/opensc-debug.log" ; # Fichier où ecrire les informations de debug (défaut : stdout)
    error_file = "/var/log/opensc-errors.log" ; # Fichier où ecrire les information d’erreur (défaut : stderr)
    profile_dir = PKGDATADIR ; # Répertoire de profil pour pkcs15-init (défaut : /usr/share/opensc)
    reader_drivers = pcsc, openct, ctapi ; # pilotes à charger au démarrage. ’internal’ va charger tous les pilote liés statiquement (défaut)
}
    
    {
        reader_driver ctapi { # configuration pour le pilote ctapi
            module /usr/local/towitoko/lib/libtowitoko.so {
                ports = 0 ; # port CT-API 0..3 (COM1..4) 4 (printer) 5 (modem) 6..7 (LPT1..2)
            }
        }
    
        reader_driver pcsc { # configuration pour le pilote pcsc
            max_send_size = 252 ; # Taille max des données envoyée et reçues. Vérifier avec lsusb -vv pour dwMaxIFSD
            max_recv_size = 252 ;
            connect_exclusive = false ; # connecter le lecteur en mode exclusif (défaut : false)
            connect_reset = true ; # réinitialiser la carte après déconnection (défaut : true)
            transaction_reset = false ; # réinitialise la carte après charque transaction (défaut : false)
            enable_pinpad = false ; # active pinpad si détecté (défaut : false)
        }
    
        reader_driver openct {
            readers = 5 ; Lecteurs virtuels à allouer (défaut : 5)
        }
    
        card_drivers = customcos, internal ; # pilotes à charger au démarrage. ’internal’ charge tous les pilotes liés dynamiquement (défaut et doit toujours être la dernière entrée)
        card_driver customcos {
            module = /usr/lib/opensc/drivers/card_customcos.so ; # emplacement du pilote
        }
    
        force_card_driver = autodetect ; # si spécifié, force OpenSC à utiliser ce pilote.(défaut : autodetect)
        # noms des pilotes internes supportés : etoken, flex, cyberflex, gpk, miocos, mcrd, setcos, starcos, tcos, openpgp, jcop, oberthur, belpic, emv, piv
        card_atr 3b:f0:0d:ca:fe { # nouvelle entrée pour le pilote flex. Format générique : card_atr ‹hex encoded ATR (case-sensitive !)›
            atrmask = "ff:ff:ff:ff:ff" ; # masque AND pour l’ATR de la carte pour la l’identification de la référence ATR.
            driver = "flex" ; # pilote à utiliser
            name = "My CryptoFlex card" ; { nom de la carte
                type = "2002" ; # type de carte (valeur entière)
                flags = "keygen", "rng", "0x80000000" ; # flags au format hexa (ou chaine pour certains : keygen = capacités de génération de clé embarqué, rng = source de nombre aléatoire embarqué) pour personnaliser les capacités de la carte.
                pkcs15emu = "custom" ; # Couche d’amulation PKCS #15, force le pilote d’émulation pour les cartes spécifiques
                force_protocol = "t0" ; # Force le protocole à utiliser (t0, t1 ou raw)
            }
            card_atr 3B:7D:96:00:00:80:31:80:65:B0:83:11:00:AC:83:00:90:00 { # les cartes PIV on besoin d’un entrée comme ceci
                name = "PIV-II" ;
                driver = "piv" ;
            }
            card_atr 3b:6e:00:ff:45:73:74:45:49:44:20:76:65:72:20:31:2e:30 { # les cartes Estonian ID et le pilote Micardo fonctionne ensemble avec T=0. Seul l’ATR ’cold’ devrait être spécifié
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 {
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 { # Les cartes D-Trust sont aussi basées sur micardo et T=0
                force_protocol = t0 ;
            }
            card_atr 3b:ff:94:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:23 {
                force_protocol = t0 ;
            }
            card_atr 3b:ff:11:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:a6 {
                force_protocol = t0 ;
            }
            framework pkcs15 { # block spécifique au framework PKCS #15
                use_caching = false ; # spécifie d’utiliser les fichier en cache dans le home de l’utilisateur en apprenant la carte (pkcs15-tool -L) (ne doit pas être utilisé en root) (défaut : false)
                enable_pkcs15_emulation = yes ; # Active l’émulation pkcs15 (défaut : yes)
                try_emulation_first = yes ; # tente d’abord l’émulation pkcs15 avant le traitement normal pkcs15 (défaut : no)
                enable_builtin_emulation = yes ; # Active l’émulation intégrée
                builtin_emulators = esteid, openpgp, tcos, starcert, infocamere, postecert, actalis, atrust-acos, gemsafe, tccardos, PIV-II ; # liste des émulateurs pkcs15 intégrés à tester
                emulate custom { # Paramètre pour un émulateur pkcs15 chargé depuis une librairie externe
                    module = /usr/lib/opensc/drivers/p15emu_custom.so ; # emplacement de la librairie
                }
            }
        }
    
        app opensc-pkcs11 { # paramètres pour le module PKCS11 OpenSC
        pkcs11 {
            num_slots = 4 ; # Nombre de slot maximum par carte à puce
            hide_empty_tokens = yes ; # Cache les slots vides
            lock_login = true ; # opensc tente de locker la carte une fois authentifiée via C_Login. (défaut : false)
            cache_pins = true # normalement le module pkcs11 ne met pas en cache le pin présenté via C_Login, mais certaines carte ne fonctionne pas correctement avec opensc (défaut : true)
            soft_keygen_allowed = true ; # Force la génération de pair de clé embarqué (défaut : true)
            }
        }

^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - config

OpenSSL - config

Fichers de configuration de la librairie CONF

   La librairie CONF openssl peut être utilisée pour lire les fichiers de configuration. Elle est utilisée pour le fichier de configuration maître openssl.cnf et dans d'autres endroits comme dans les fichiers SPKAC et les fichiers d'extensions de certificat pour l'utilitaire x509. Les application openssl peuvent également utiliser la librairie CONF pour leur propre utilisation.

   Un fichier de configuration est divisé en nombre de sections. Chaque section commence avec une ligne [ section_name ] et se termine quand une nouvelle section commence.

   La première section d'un fichier de configuration est spécial et est réferré à la section par défaut qui est généralement non nommée. Quand un nom est recherché il est d'abord recherché dans une section nommée, puis dans la section par défaut.

   L'environnement est mappé en une section appelée ENV. Chaque section consiste d'un nombre de paire nom=valeur.

   La valeur peut être étendue en utilisant la forme $var ou ${var}, qui substitue la valeur de la variable dans la section courante. Il est également possible de substituer une valeur d'une autre section en utilisant la syntaxe $section::name ou ${section::name}. En utilisant la forme $ENV::name les variables d'environnement peuvent être substituées. Il est également possible d'assigner des valeurs aux variables d'environnement en utilisant le nom ENV::name, cela fonctionne si le programme recherche des variables d'environnement en utilisant la librairie CONF au lieu d'appeler getenv() directement.

Configuration de la librairie openssl

   Les application peuvent configurer automatiquement certains aspects d'openssl en utilisant le fichier de configuration maître, ou optionnellement un fichier de configuration alternatif. L'utilitaire openssl inclus cette fonctionnalité; toute sous-commande utilise le fichier de configuration maître sauf si une option est utilisée dans la sous commande pour utiliser un fichier de configuration alternatif.

   Pour activer la configuration de librairie la section par défaut doit contenir la ligne appropriée qui pointe vers la section de configuration principale. Le nom par défaut est openssl_conf qui est utilisé par l'utilitaire openssl. D'autres applications peuvent utiliser un nom alternatif

La section de configuration devrait consister en un jeu de nom=valeur qui contient des informations spécifique au module. Le nom représente le nom du module de configuration et la valeur est spécifique au module. Par exemple:
openssl_conf = openssl_init

[openssl_init]
oid_section = new_oids
engines = engine_section
    
[new_oids]
... new oids here ...
    
[engine_section]
... engine stuff here ...

Module de configuration d'objet ASN1

Ce module a le nom oid_section. La valeur est le nom de la section contenant les paires de valeur d'OID. Bien que certains utilitaires openssl ont leur propre section d'objet ASN1, toutes ne l'ont pas. En utilisant le module de configuration d'objet ASN1 tout l'utilitaire openssl peut voir les nouveaux objets. Par exemple:
[new_oids]
some_new_oid = 1.2.3.4
some_other_oid = 1.2.3.5

Il est également possible de définir la valeur avec un nom long, suivi par une virgule et l'OID:
shortName = some object long name, 1.2.3.4

Module de configuration engine

   Le module de configuration ENGINE a le nom des engines. La valeur pointe vers une section contenant les informations de configuration du moteur.

Chaque section spécifique est utilisée pour définir les algorithmes par défaut, le chargement dynamique, d'initialisation et les contrôles envoyés. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
# Configure ENGINE named "bar"
bar = bar_section
    
[foo_section]
... foo ENGINE specific commands ...

[bar_section]
... "bar" ENGINE specific commands ...

La commande engine_id est utilisée pour donner le nom du moteur. par exemple:
[engine_section]
# This would normally handle an ENGINE named "foo"
foo = foo_section
    
[foo_section]
# Override default name and use "myfoo" instead.
engine_id = myfoo

   La commande dynamic_path charge et ajoute un engine. C'est équivalent au contrôle SO_PATH avec la partie argument suivie par LIST_ADD avec la valeur 2 et LOAD à l'engine dynamic.

   La commande init détermine l'initialisation de l'engine. À 0 l'engine n'est pas initialisé. La commande default_algorithms définis les algorithmes par défaut qu'un engin fournis en utilisant les fonctions ENGINE_set_default_string().

Si le nom match aucune des commande ci-dessus, il sont considérés comme des commandes ctrl qui sont envoyés à l'engine. La valeur de la commande est l'argument de la commande ctrl. Si la v+aleur est une chaîne vide aucune valeur n'est envoyée à la commande. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
    
[foo_section]
# Load engine from DSO
dynamic_path = /some/path/fooengine.so
# A foo specific ctrl.
some_ctrl = some_value
# Another ctrl that doesn't take a value.
other_ctrl = EMPTY
# Supply all default algorithms
default_algorithms = ALL

Module de configuration EVP

Ce module a le nom alg_section qui pointe vers une section contenant les commandes algorithme. Actuellement la seule commande algorithme supportée est fips_mode dont la valeur devrait être un booléen. par exemple:
alg_section = evp_settings
    
[evp_settings]
fips_mode = on

Module de configuration ssl

Ce module a le nom ssl_conf qui pointe vers une section contenant les configurations ssl. Chaque ligne dans la section contient le nom de la configuration et la section. Chaque section consiste de paires commande-valeur pour SSL_CONF. Chaque paire sera passée à SSL_CTX ou la structure SSL en cas d'appel SSL_CTX_config() ou SSL_config() avec le nom de configuration approprié. Noter que tout caractère avant le point initial dans la section est ignoré donc la même commande peut être utilisée plusieurs fois:
ssl_conf = ssl_sect
    
[ssl_sect]
server = server_section
    
[server_section]
RSA.Certificate = server-rsa.pem
ECDSA.Certificate = server-ecdsa.pem
Ciphers = ALL:!RC4

Notes

   Si un fichier de configuration tente d'étendre une variable qui n'existe pas alors une erreur est flaggée et le fichier n'est pas chargé. Cela peut se produire si une variable d'environnement n'existe pas.

   Cela peut fonctionner en incluant une section par défaut pour fournir une valeur par défaut: si la recherche d'environnement échoue, la valeur par défaut sera utilisée. Pour que cela fonctionne correctement la valeur par défaut doit être définie très tôt dans le fichier de configuration.

Si la même variable existe dans la même section, seule la dernière est prise en compte. Sous certaines circonstances comme avec les DN le même champ peut être présent plusieurs fois:
1.OU = "My first OU"
2.OU = "My Second OU"

Exemples

Exemple de fichier de configuratio utilisant des fonctionnalités décrite plus haut:
HOME=/temp
RANDFILE= ${ENV::HOME}/.rnd
configdir=$ENV::HOME/config
    
[ section_one ]
# We are now in section one.
# Quotes permit leading and trailing whitespace
any = " any variable name "
    
other = A string that can \
cover several lines \
by including \\ characters
    
message = Hello World\n
    
[ section_two ]
greeting = $section_one::message

L'exemple suivant montre come étendre les variables d'environnement. Supposont que l'on veut une variable tmpfile référrant à un fichier temporaire. Le répertoire où il est placé peut être déterminé par la variable d'environnement TEMP ou TMP, mais elle peut ne pas être définie. En incluant les noms des variables d'environnement sans que celle-ci n'existe créé une erreur en chargeant le fichier de configuration. En utilisant la section par défaut pour les 2 valeurs:
# si TMP n'existe pas
TMP=/tmp
# Si TMP existe
TEMP=$ENV::TMP
tmpfile=${ENV::TEMP}/tmp.filename

Exemple pour entrer en mode fips:
openssl_conf = openssl_conf_section
    
[openssl_conf_section]
alg_section = evp_sect
    
[evp_sect]
fips_mode = yes

Configuration plus complexe:
openssl_conf = openssl_conf_section
    
[openssl_conf_section]
alg_section = evp_sect
oid_section = new_oids
    
[evp_sect]
fips_mode = no
    
[new_oids]
# New OID, just short name
newoid1 = 1.2.3.4.1
# New OID shortname and long name
newoid2 = New OID 2 long name, 1.2.3.4.2

   Les exemples ci-dessus peuvent être utilisées avec toute application utilisant la librairie si openssl_conf est modifié pour correspondre au nom de l'application.

Par exemple, si le second fichie d'exemple ci-dessus est sauvé dans example.cnf, la ligne de commande:
OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1
va afficher
0:d=0 hl=2 l= 4 prim: OBJECT :newoid1

BUGS

   Il n'y a actuellement aucun moyen d'utiliser des caractères en utilisant la notation octal \nnn. Les chaînes sont toutes terminer par un caractère null, donc les nulls ne peuvent pas faire partie de la valeur. Les fichiers sont chargés en une seule passe. Cela signifie qu'une expansion de variable ne fonctionne que si les variables sont référencées très tôt dans le fichier.
^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - engine

OpenSSL - engine

Trouver et charger les engines

   La commande engine est utilisée pour voir le status et les capacités des engines spécifiés. Les engines peuvent être spécifiés avant ou après tous les autres flags de la ligne de commande.

OPTIONS

-v -vv -vvv -vvvv -v liste les commandes de contrôle temps-réel, -vv ajoute une description pour chaque commande, -vvv ajoute les flags d'entrée, et -vvvv ajoute les flags d'entrée internes
-c Liste les capacités de chaque engine
-t Teste si chaque engine spécifié est disponible, et affiche la réponse
-tt Affiche une erreur pour un engine non-disponible
-pre command=item -post command Configuration en ligne de commande des engines. -pre est donné à l'engine avec qu'il soit chargé et -post est donné une fois chargé.

Exemple

Pour lister toutes les commandes disponibles d'un engine dynamique
openssl engine -t -tt -vvvv dynamic
Pour lister les capacités de l'engine rsax
openssl engine -c
^
19 février 2012

htmlpdflatexmanmd




OpenSSL - asn1parse

OpenSSL - asn1parse

Parser les structures ASN.1, ou extraire les données ASN.1

OPTIONS

-inform DER|PEM Format d’entrée (DER : binaire, PEM : base64)
-in filename Fichier d’entrée
-out filename Fichier de sortie où placer les données DER.
-noout Ne sort pas la version parsée du fichier en entrée
-offset number Commence à parser à l’offset spécifié
-length number Nombre d’octets à parser
-i Indenter la sortie en accord avec le "depth" des structures
-oid filename Un fichier contenant un OID additionnel.
-stdparse offset Parse le contenu des octets de l’objet ASN.1 en commençant à l’offset spécifié. Peut être spécifié plusieurs fois.
-genstr string, -genconf file Génère des données encodée basé sur la chaîne ou le fichier spécifié en utilisant le format ASN1_generate_nconf

SORTIE

La sortie contient des lignes de ce type:
0:d=0 hl=4 l= 681 prim : SEQUENCE
.....
229:d=3 hl=3 l= 141 prim : BIT STRING
373:d=2 hl=3 l= 162 cons : cont [ 3 ]
376:d=3 hl=3 l= 159 cons : SEQUENCE
379:d=4 hl=2 l= 29 cons : SEQUENCE
381:d=5 hl=2 l= 3 prim : OBJECT

   Chaque ligne commence avec un offset décimal. d=xx spécifie la profondeur courante. hl=XX donne la longueur d’en-tête du type courant. l=XX donne la longueur du contenu.

Exemples

parser un fichier
openssl asn1parse -in file.pem
parser un fichier DER
openssl asn1parse -inform DER -in file.der
générer un UTF8String simple
openssl asn1parse -genstr ’UTF8:Hello World’
Générer un UTF8String, ne pas parser la sortie
openssl asn1parse -genstr ’UTF8:Hello World’ -noout -out utf8.der
génerer en utilisant un fichier de configuration
openssl asn1parse -genconf asn1.cnf -noout -out asn1.der
exemple de fichier de configuration
asn1=SEQUENCE:seq_sect
[seq_sect]
field1=BOOL:TRUE
field2=EXP:0, UTF8some random string
^
26 février 2012

htmlpdflatexmanmd




OpenSSL - ca

OpenSSL - ca

Application CA minimaliste. Peut être utilisé pour signer des requêtes de certificats et générer des CRL. Maintient également une base des certificats délivrés et leur status.

Options CA

-config filename Spécifie le fichier de configuration à utiliser
-name section Spécifie la section du fichier de configuration à utiliser
-in filename Fichier source contenant une requête de certificat à signer
-ss_cert filename un certificat auto-signé à signer par la CA
-spkac filename Un fichier contenant une clé publique signée Netscape, un challenge et des valeurs de champs assitionnels à signer par la CA.
-infiles Si présent doit être la dernière option. Tous les arguments qui suivent sont traités comme des noms de fichier contenant des requêtes.
-out filename Fichier de sortie. (défaut : stdout)
-outdir directory Répertoire où placer les certificats de sortie. Le certificat sera nommé avec un numéro hexa et l’extension pem.
-cert Fichier du certificat CA
-keyfile filename La clé privée à utiliser pour signer la requête
-key password Le mot de passe à utiliser pour chiffrer la clé privée
-selfsign indique que les certificats délivrés doivent être signés avec la clé qui a servit à signer la requête (spécifié avec -keyfile). Les requêtes signées avec un certificat différent sont ignorés. si spkac, ss_cert ou gencrl sont spécifiés, cette option est ignorée.
-passin arg La source du mot de passe.
-verbose mode verbeux
-notext N’affiche pas la forme texte dans le fichier de sortie
-startdate date Permet de définir la date de début au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-enddate date Permet de définir la date d’expiration au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-days arg Le nombre de jours pendant lesquels certifier ce certificat
-md alg Le message digest à utiliser (md5 sha1 et mdc2)
-policy arg Spécifie la stratégie CA à utiliser. C’est une section dans le fichier de configuration
-msie_hack Permet un fonctionnemnt avec les très vieux contrôle d’enrollement de certificat IE ’certenr3’.
-preserveDN Normalement l’ordre du DN est le même que l’ordre des champs dans la section de stratégie. Avec cette option, l’ordre est le même que dans la requête
-noemailDN Le DN d’un certificat peut contenir le champ email s’il est présent dans le DN de la requête ; cependantil est préférable d’avoir l’email dans l’extnsion altName. Avec cette option, le champs email est supprimé du sujet du certificat et définis dans les extensions si présent.
-batch Dans ce mode tous les certificats sont certifiés automatiquement sans poser de questions.
-extensions section La section du fichier de configuration contenant les extensions à ajouter quand un certificat est délivré. Sans extention, un V1 est créé, si une extension est présente, même vide, un v3 est créé.
-extfile file Un fichier de configuration additionnel contenant les extensions à ajouter.
-engine id Spécifie le type de moteur. peut être définis à default pour tous les algorithmes disponibles
-subj arg Remplace le sujet dans la reque^te. doitêtre au format /type0=value0/type1=value1/type2=...
-utf8 Les valeurs dns les champs sont interprétés comme chaînes UTF-8 (par défaut en ASCII)
-multivalue-rdn l’argument -subj est interprété comme RDN multivalué. ex : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe (sans cette option : 123456+CN=John Doe)

Options CRL

-gencrl Génère une CRL basé sur les informations dans le fichier d’index
-crldays num Nombre de jours avant la prochaine CRL. valeur placée dans le champ nextUpdate de la CRL.
-crlhours num Nombre d’heure avant la prochaine CRL.
-revoke filename Un nom de fichier contenant un certificat à révoquer.
-crl_reason reason Raison dela révocation. Peut être (unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold ou removeFromCRL). Définis une raison de révocation va créer une CRL v2.
-crl_hold instruction Définis la raison de révocation à certificateHold et l’instruction doit etre un OID (pet être à holdInstructioNone (=obsolete), holdInstructionCallIssuer ou HoldInstructionReject)
-crl_compromise time Définis la raison de révocation keyCompromise et le temps au format YYYYMMDDHHMMSSZ.
-crl_CA_compromise time Idem pour CACompromise
-crlexts section Section dans le fichier de configuration contenant les extensions CRL à inclure. Sans extension, une CRL v1 st générée.

Options du fichier de configuration

   La section par défaut doit être nommée dans l’option default_ca de la section ca (ou de la section par défaut).

oid_file Spécifie le fichier contenant des oid additionnels, un par ligne.
oid_section Spécifie la section dans le fichier de configuration contenant les oid additionnels.
new_certs_dir Idem à -outdir
certificate idem à -cert
private_key idem à -keyfile
RANDFILE un fichier utilisé pour lire et écrire des informations de nombre aléatoire.
default_startdate idem à -startdate
default_enddate idem à -enddate
default_crl_hours idem à -crlhours
default_crl_days idem à -crldays
default_md idem à -md
database le fichier de données à utiliser
unique_subject à yes, les certificats doivent avoir un sujet unique
serial Fichier texte contenant le prochain numéro de CRL en hexa à utiliser.
x509_extensions idem à -extensions
crl_extensions idem à -crlexts
preserve idem à -preserveDN
email_in_dn idem à -noemailDN
msie_hack idem à -msie_hack
policy idem à -policy
name_opt, cert_opt Permettent au format utilisé d’afficher les détails du certificat lorsqu’il est demandé à l’utilisateur de confirmer la signature.
copy_extensions Détermine comment les extensions dans la requête sont manipulés. non spécifié ou à none, lesextensions sont ignorés. à copy, les extensions non encore présentes sont copiées dans le certificat. a copyall, toutes les extensions sont copiées en supprimant celles déjà présentes

Exemples

Signer une requête de certificat:
openssl ca -in req.pem -out newcert.pem
signer une requête e certificat, en utilisant les extensions de CA:
openssl ca -in req.pem -extensions v3_ca -out newcert.pem
Générer une CRL:
openssl ca -gencrl -out crl.pem
signer plusieurs requêtes:
openssl ca -infiles req1.pem req2.pem req3.pem
Certifier un SPKAC Netscape:
openssl ca -spkac spkac.txt
exemple de fichier SPKAC (tronquée pour plus de clarté):
SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
CN=Steve Test
emailAddress=steve@openssl.org
0.OU=OpenSSL Group
1.OU=Another Group

Exemple de section ca dans la configuration


[ ca ]
default_ca = CA_default # Section ca par défaut
    
[ CA_default ]
dir = ./demoCA # Répertoire de base
database = $dir/index.txt # fichier d’index
new_certs_dir = $dir/newcerts # Répertoire pour les nouveaux certificats délivrés
    
certificate = $dir/cacert.pem # Certificat racine
serial = $dir/serial # fichier serial
private_key = $dir/private/cakey.pem# Clé privée de la ca
RANDFILE = $dir/private/.rand # Fichier de nombres aléatoire
    
default_days = 365 # Durée de validité du certificat
default_crl_days= 30 # Durée de la CRL
default_md = md5 # md à utiliser
    
policy = policy_any # Stratégie par défaut
email_in_dn = no # Ne pas ajouter le mail dans le DN
    
name_opt = ca_default # Option d’affichage du nom du sujet
cert_opt = ca_default # Option d’affichage du certificat
copy_extensions = none # Ne pas copier les extensions depuis la requête
    
[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Variables d'environnement

OPENSSL_CONF Réflète l’emplacement du fichier de configuration maître (idem à -config)
^
27 février 2012

htmlpdflatexmanmd




OpenSSL - ciphers

OpenSSL - ciphers

Convertis les listes de chiffrement en liste de préférence ordonnées. Peut être utilisé comme outil de test pour déterminer la liste de chiffrement.

OPTIONS

-v mode verbeux
-V idem à -v mais inclus les codes des suites de chiffrements en hexa.
-ssl3 Uniquement les chiffrements SSL v3
-ssl2 Uniquement les chiffrements SSL v2
-tls1 Uniquement les chiffrements TLS v1
cipherlist Une liste de chiffrement à convertir en une liste de préférence de chiffrement.

Format de liste de chiffrement

   Une liste consiste en une ou plusieurs chaîne de chiffrement séparés par des ':'. Une liste peut être une suite de chiffrements simple comme RC4-SHA. Elle peut représenter un certain algorithme. Par exemple SHA1 représente toutes les suites utilisant cet algorithme, et SSLv3 représente tous les algorithmes SSLv3.

  Les listes de suite de chiffrement peuvent être combinées en une simple chaîne en utilisant le '+' (est un ET logique), un '!' pour les chiffrements à supprimer de la liste, un '-' pour ceux à supprimer, mais qui peuvent être rajoutés ultérieurement. En plus, la chaine de chiffrement @STRENGTH peut être utilisée pour trier la liste de chiffrement courante dans l'ordre de longueur de clé de chiffrement.

Chaînes de chiffrement

   Liste des chaînes de chiffrement permises et leur signification:

DEFAULT Liste de chiffrement par défaut. Déterminé à la compilation. (pour openssl v1.0.0 est normalement à ALL:!aNULL:!eNULL). Doit être la première chaîne de chiffrement spécifiée.
COMPLEMENTOFDEFAULT Les chiffrement inclus dans ALL, mais non actifs par défaut.
ALL Toutes les suites de chiffrement sauf eNULL
COMPLEMENTOFALL Les suites de chiffrement non activés par ALL, actuellement eNULL.
HIGH Suites de chiffrements élevés. Actuellement, signifie toutes les longueurs de clé supérieurs à 128 bits, et certains chiffrements avec clé 128 bits.
MEDIUM Suites de chiffrements moyens. Actuellement, signifie toutes les longueurs de clé à 128 bits.
LOW Suites de chiffrements faibles. Actuellement, signifie toutes les longueurs de clé supérieurs à 56 ou 64 bits mais exclus les suites de chiffrement d’export
EXP, EXPORT Algorithmes de chiffrement d’export, incluant les clés à 56 et 64 bits.
EXPORT40 Algorithmes de chiffrement d’export de 40 bits
EXPORT56 Algorithmes de chiffrement d’export de 56 bits
eNULL, NULL Chiffrement qui n’offrent pas de cryptage.
aNULL Suites de chiffrement n’offrant pas d’authentification. Actuellement, les algorithmes DH anonymes. Vulnérables aux attaques MITM.
kRSA, RSA Suites de chiffrement utilisant les échanges de clé RSA
kEDH Suites de chiffrement utilisant les agréments de clé DH éphémères
kDHr, kDHd Suites de chiffrement utilisant les agréments de clé DH et les certificats DH signés par CA avec des clé RSA et DSS, respectivement.
aRSA Suites de chiffrement utilisant l’authentification RSA.
aDSS, DSS Suites de chiffrement utilisant l’authentification DSS
aDH Suites de chiffrement utilisant effectivement l’authentification DH.
kFZA, aFZA, eFZA, FZA Suites de chiffrement utilisant l’échange de clé, l’authentification et/ou le chiffrement FORTEZZA
TLSv1, SSLv3, SSLv2 Suites de chiffrement utilisant respectivement TLS v1, SSL v3 et SSL v2.
DH Suites de chiffrement utilisant DH, incluant DH anonyme.
ADH Suites de chiffrement utilisant DH anonyme.
AES Suites de chiffrement utilisant AES
CAMELLIA Suites de chiffrement utilisant Camellia
3DES Suites de chiffrement utilisant 3DES
DES Suites de chiffrement utilisant DES
RC4 Suites de chiffrement utilisant RC4
RC2 Suites de chiffrement utilisant RC2
IDEA Suites de chiffrement utilisant IDEA
SEED Suites de chiffrement utilisant SEED
MD5 Suites de chiffrement utilisant MD5
SHA1, SHA Suites de chiffrement utilisant SHA1
aGOST Suites de chiffrement utilisant GOST R 34.10 (soit 2001 soit 94) pour l’authentification
aGOST01 Suites de chiffrement utilisant l’authentification GOST R 34.10-2001
aGOST94 Suites de chiffrement utilisant L’authentification GOST R 34.10-94
kGOST Suites de chiffrement utilisant l’échange de clé VKO 34.10 (RFC 4357)
GOST94 Suites de chiffrement utilisant HMAC basé sur GOST R 34.10-94
GOST89MAC Suites de chiffrement utilisant GOST 28147-89 MAC

Noms des suites de chiffrement

   Les listes suivantes donnent les noms des suites de chiffrement SSL ou TLS et leur équivalent OpenSSL.

Suites de chiffrement SSL v3.0


SSL_RSA_WITH_NULL_MD5 NULL-MD5
SSL_RSA_WITH_NULL_SHA NULL-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
SSL_RSA_WITH_RC4_128_MD5 RC4-MD5
SSL_RSA_WITH_RC4_128_SHA RC4-SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
SSL_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
    
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_DES_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_DES_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA
    
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
SSL_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA
    
SSL_FORTEZZA_KEA_WITH_NULL_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA Not implemented.

Suites de chiffrement TLS v1.0


TLS_RSA_WITH_NULL_MD5 NULL-MD5
TLS_RSA_WITH_NULL_SHA NULL-SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
TLS_RSA_WITH_RC4_128_MD5 RC4-MD5
TLS_RSA_WITH_RC4_128_SHA RC4-SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
TLS_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
TLS_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
    
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_DES_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA
    
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
TLS_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
TLS_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

Suites de chiffrement AES de la rfc3268, étendant TLS v1.0


TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
    
TLS_DH_DSS_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_AES_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_256_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-DSS-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA
    
TLS_DH_anon_WITH_AES_128_CBC_SHA ADH-AES128-SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA ADH-AES256-SHA

Suites de chiffrement Camellia de la rfc4132, étendant TLS v1.0


TLS_RSA_WITH_CAMELLIA_128_CBC_SHA CAMELLIA128-SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA CAMELLIA256-SHA
    
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE-DSS-CAMELLIA128-SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE-DSS-CAMELLIA256-SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE-RSA-CAMELLIA128-SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE-RSA-CAMELLIA256-SHA
    
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA ADH-CAMELLIA128-SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA ADH-CAMELLIA256-SHA

Suites de chiffrement SEED de la rfc4162, étendant TLS v1.0


TLS_RSA_WITH_SEED_CBC_SHA SEED-SHA
    
TLS_DH_DSS_WITH_SEED_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_SEED_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_SEED_CBC_SHA DHE-DSS-SEED-SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA DHE-RSA-SEED-SHA
    
TLS_DH_anon_WITH_SEED_CBC_SHA ADH-SEED-SHA

Suites de chiffrement GOST du draft-chudov-cryptopro-cptls, étendant TLS v1.0

Note: Ces chiffrements nécessitent un moteur qui inclut les algorithmes cryptographique GOST tel que le moteur ccgost, inclus dans OpenSSL.
TLS_GOSTR341094_WITH_28147_CNT_IMIT GOST94-GOST89-GOST89
TLS_GOSTR341001_WITH_28147_CNT_IMIT GOST2001-GOST89-GOST89
TLS_GOSTR341094_WITH_NULL_GOSTR3411 GOST94-NULL-GOST94
TLS_GOSTR341001_WITH_NULL_GOSTR3411 GOST2001-NULL-GOST94

Exports additionnels 1024 et autres suites de chiffrement

Note: Ces chiffrements peuvent aussi être utilisé dans SSL v3
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DHE-DSS-DES-CBC-SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA EXP1024-DHE-DSS-RC4-SHA
TLS_DHE_DSS_WITH_RC4_128_SHA DHE-DSS-RC4-SHA

Suites de chiffrement SSL v2.0


SSL_CK_RC4_128_WITH_MD5 RC4-MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5 EXP-RC4-MD5
SSL_CK_RC2_128_CBC_WITH_MD5 RC2-MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 EXP-RC2-MD5
SSL_CK_IDEA_128_CBC_WITH_MD5 IDEA-CBC-MD5
SSL_CK_DES_64_CBC_WITH_MD5 DES-CBC-MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5

Exemples

Lister tous les chiffrements OpenSSL incluant les chiffrements NULL:
openssl ciphers -v ’ALL:eNULL’
Inclure tous les chiffrements excepté NULL et DH anonyme, et trier par force:
openssl ciphers -v ’ALL : !ADH :@STRENGTH’
Inclure seulement les chiffrements 3DES puis placer RSA en dernier:
openssl ciphers -v ’3DES :+RSA’
Inclure tous les chiffrements RC4 mais laisser ceux sans authentification:
openssl ciphers -v ’RC4 : !COMPLEMENTOFDEFAULT’
Inclure tous les chiffrements avec authentification RSA mais laisser les chiffrements sans cryptage:
openssl ciphers -v ’RSA : !COMPLEMENTOFALL’
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - cms

OpenSSL - cms

Utilitaire CMS (Cryptographic Message Syntax)

OPTIONS

-encrypt Chiffre un mail avec le certificat donné. Le fichier d’entrée est le message à chiffrer. Le fichier de sortie est le mail chiffré au format MIME. Le type de CMS actuel est EnvelopedData.
-decrypt Déchiffre un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est un mail au format MIME. le fichier de sortie est le mail déchiffré.
-sign Signe un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est le message à signer, le fichier de sortie est le message signé au format MIME.
-verify Vérifie le mail signé. L’entrée est le mail signé, le fichier de sortie et la sortie est la donnée signée.
-cmsout Prend un message en entrée et écrit une structure CMS encodée PEM
-resign Re-signe un message: prend un message existant et un ou plusieurs nouveaux signataires.
-data_create Créé un type CMS Data
-data_out Type une donnée et sort le contenu
-digest_create Crée un type CMS DigestedData
-digestVerify Vérifie un CMS DigestedData et sort le contenu
-compress Créé un CMS CompressedData. OpenSSL doit être compilé avec zlib pour que cette option fonctionne.
-uncompress Décompresse un CMS CompressedData.
-EncryptedData_encrypt Chiffre le contenu en utilisant une clé symétrique et un algorithme CMS EncryptedData et sort le contenu.
-sign_receipt Génère et sort un reçu signé pour le message spécifié. Le message d’entrée doit contenir une requête de reçu signée.
-verify_receipt receipt Vérifie un reçu signé dans le fichier spécifié. Le message d’entrée doit contenir une requête de reçu.
-in filename Fichier d’entrée
-inform SMIME|PEM|DER Format du fichier d’entrée, à utiliser avec -receipt_verify
-out filename Fichier de sortie
-outform SMIME|PEM|DER Spécifie le format du fichier de sortie (défaut SMIME)
-stream -indef -stream et indef sont équivalent et permettent le streaming I/O pour les opérations d’encodage. Cela permet un traitement en une passe de donnée sans nécessiter de maintenir tout le contenu en mémoire.
-noindef Désactive le streaming I/O.
-content filename spécifie un fichier contenant le contenu détaché. Seulement utile avec -verify et si la structure CMS utilise une signature détachée du contenu.
-text Ajoute des en-têtes text/plain au message fournis.
-noout Ne sort par la structure CMS parsée. Utile avec -print
-print pour -cmsout, affiche tous les champs de la structure CMS.
-CAfile file Un fichier contenant les certificats trustés. Utile avec -verify
-CApath dir Un répertoire contenant les certificats CA. Utile avec -verify
-md digest Algorithme digest à utiliser pour signer ou re-signer.
-[ciphers] L’algorithme de chiffrement à utiliser. Voir enc pour la liste des chiffrements supportés. (Défaut : 3DES)
-nointern En vérifiant un message, les certificats inclus dans le message sont utilisé pour vérifier la signature. Avec cette option, seul les certificats spécifiés avec -certfile sont utilisés.
-no_signer_cert_verify Ne vérifie pas le certificat du message signé.
-nocerts En signant un message, le certificat du signataire est inclus. Cette option l’empêche.
-noattr Normalement quand un message est signé, des attributs sont inclus dont la date de signature et les algorithmes symétriques supportés. Cette option ne les inclus pas.
-nosmimecap Exclus la liste des algorithmes supportés pour les attributs signés. D’autres options telles que la date de signature et le type de contenu sont inclus.
-binary Normalement, le message d’entrée est convertit au format canonique qui utilise CR et LF comme fin de ligne comme requis par la spécification S/MIME. Avec cette option, aucune conversion n’est faite.
-nodetach En signant un message en utilisant une signature opaque la forme est plus résistante aux translations par les relais, mais ne peut pas être lus par les agents qui ne supportent pas S/MIME. Sans cette option, la signature en texte clair est utilisée.
-certfile file Permet de spécifier des certificats additionnels, qui seront inclus dans le message. Ces certificats devraient être au format PEM.
-certsout file Tout certificat contenus dans le message sont écris dans le fichier spécifié
-signer file Un certificat de signature. Peut-être spécifiée plusieurs fois.
-recip file Le certificat pour le déchiffrement d’un message. Ce certificat doit matcher un des destinataires du message.
-keyid Utilise le subject key identifier pour identifier les certificats au lieu du nom et du numéro de série. Le certificat doit inclure une extension subject key identifier.
-receipt_request_all -receipt_request_first Pour que l’option -sign inclue une requête de reçu. Indique que les requêtes devraient être fournies par tous les destinataires ou le premier tiers des destinataires.
-receipt_request_to_emailaddress Ajoute une adresse mail où les reçus signés devraient être envoyés. Doit être fournis si un reçu signé est demandé.
-receipt_request_print Pour -verify, affiche le contenu des demandes de reçus signés.
-secretkey key Spécifie la clé symétrique à utiliser. La clé doit être fournie en hexa.
-secretkeyid id L’identifiant de clé pour la clé symétrique fournies pour le type KEKRecipentInfo.
-econtent_type type Définis le type de contenu encapsulé. Peut-être un OID soit en texte soit sous forme numérique.
-inkey file La clé privée à utiliser pour signer ou déchiffrer.
-passin arg Le mot de passe pour la clé privée.
-rand file(s) Un ou plusieurs fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoires, ou un socket EGD.
cert.pem... Un ou plusieurs certificats de destinataire de message à utiliser pour chiffrer un message
-to, -from -subject Les en-têtes du mail.
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig Diverse options de validation de la chaîne de certificat. Voir verify.

Codes de sortie

0 succès de l’opération
1 Erreur en parsant les options
2 Un des fichiers d’entrée ne peut pas être lu
3 Une erreur s’est produite en créant le fichier CMS ou en lisnt le message MIME
4 Erreur durant la vérification ou le déchiffrement du message
5 Le message a été vérifié correctement mais une erreur s’est produite en écrivant les certificats des signeurs.

Compatibilité avec le format PKCS #7

   l’utilitaire smime peut seulement traiter l’ancien format pkcs #7. L’utilitaire cms supporte le format CMS.

        L’utilisation de -keyid avec -sign ou -encrypt
        L’option -outform PEM
        L’option -compress
        L’option -secretkey avec -encrypt
        -EncryptedData_create et -data_create ne peuvent être traitée par les commandes smime.

Exemples

Créer un message signé en texte clair:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem
Créer un message signé opaque:
openssl cms -sign -in message.txt -text -out mail.msg -nodetach -signer mycert.pem
Créer un message signé, incluant des certificats additionnels et lire la clé privée depuis un autre fichier:
openssl cms -sign -in in.txt -text -out mail.msg -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
Créer un message signé avec 2 signataires, utiliser un identifier de clé:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem -signer othercert.pem -keyid
Envoyer un message signé sous Unix directement à sendmail, incluant les en-têtes:
openssl cms -sign -in in.txt -text -signer mycert.pem -from steve@openssl.org -to someone@somewhere -subject "Signed message" | sendmail someone@somewhere
Vérifier un message et extraire le certificat du signataire en cas de réussite:
openssl cms -verify -in mail.msg -signer user.pem -out signedtext.txt
Envoyer un mail chiffré avec 3DES:
openssl cms -encrypt -in in.txt -from steve@openssl.org -to someone@somewhere -subject "Encrypted message" -des3 user.pem -out mail.msg
Signer et chiffrer un mail:
openssl cms -sign -in ml.txt -signer my.pem -text | openssl cms -encrypt -out mail.msg -from steve@openssl.org -to someone@somewhere -subject "Signed and Encrypted message" -des3 user.pem
Déchiffrer un mail:
openssl cms -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
La sortie de la Netscape est une structure PKCS #7 avec le format de signature détachée. Pour vérifier la signature, mettre la structure codé en base 64 entre:
-----BEGIN PKCS7-----
-----END PKCS7-----
Et utiliser la commande:
openssl cms -verify -inform PEM -in signature.pem -content content.txt
Alternativement vous pouvez décoder la signature et utiliser:
openssl cms -verify -inform DER -in signature.der -content content.txt
Créer et chiffrer un message en utilisant Camellia 128 bits:
openssl cms -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
Ajouter un signataire à un message existant:
openssl cms -resign -in mail.msg -signer newsign.pem -out mail2.msg
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - crl

OpenSSL - crl

Utilitaire de traitement des fichiers CRL

OPTIONS

-infor DER|PEM Format du fichier d’entrée.
-outform DER|PEM Spécifie le format de la sortie
-in filename Spécifier le fichier d’entrée
-out filename Spécifier le fichier de sortie
-text Affiche la CRL au format texte
-noout Ne sort pas la version encodée de la CRL
-hash Sort un hash de nom de l’émetteur. Peut être utilisé pour rechercher les CRL dans un répertoire par émetteur
-issuer Affiche le nom de l’émetteur
-lastupdate affiche le champ lastUpdate
-nextupdate Affiche le champ nextUpdate
-CAfile file Vérifie l signature d’un CRL avec le certificat spécifié
-CApath dir Vérifie la signature d’une CRL en recherchant le certificat dabs DIR. Ce répertoire doit être un répertoire de certificat standard: un hash du nom du sujet est lié à chaque certificat (x509 -hash)

Notes

Le format PEM utilise les en-tête et pieds de page suivante:
-----BEGIN X509 CRL-----
-----END X509 CRL-----

Exemples

Convertir une CRL PEM en DER
openssl crl -in crl.pem -outform DER -out crl.der
Afficher un certificat DER en texte clair
openssl crl -in crl.der -text noout
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - crl2pkcs7

OpenSSL - crl2pkcs7

Utilitaire pour créer une structure PKCS #7 depuis une CRL et des certificats

OPTIONS

-infor DER|PEM Format de la CRL d’entrée.
-outform DER|PEM Spécifie le format de la structure PKCS #7 en sortie
-in filename Spécifier la CRL d’entrée
-out filename Spécifier le fichier de sortie
-certfile filename Spécifie un fichier contenant un ou plusieurs certificats au format PEM. Tous ces certificats seront ajoutés à la structure PKCS #7. Peut-être spécifié plusieurs fois.
-nocrl N’inclue pas de CRL dans le fichier de sortie.

Exemples

Créer une structure PKCS #7 depuis un certificat et une CRL
openssl crl2pkcs7 -in crl.pem -certfile cert.pem -out p7.pem
Créer une structure PKCS #7 au format DES sans CRL et depuis différent certificats
openssl crl2pkcs7 -nocrl -certfile newcert.pem -certfile demoCA/cacert.pem -outform DER -out p7.der
^
29 février 2012

htmlpdflatexmanmd




OpenSSL - dgst

OpenSSL - dgst

Afficher le message digest en hexa d’un ou plusieurs fichiers. Peut également être utilisé pour les signatures numérique et la vérification.

OPTIONS

-c Affiche le digest en 2 groupes de chiffre séparés par un ’:’
-d Affiche des informations de debuggage BIO
-hex Affiche le digests en tant que dump hexa. Défaut pour les digest normaux en opposé aux signatures numériques.
-binary Affiche le digest au format binaire
-out filename Nom du fichier de sortie
-sign filename Signe numérique le digest en utilisant la clé privée dans le fichier spécifié.
-keyform PEM|ENGINE Spécifie le format de la clé pour signer le digest.
-engine id Utilise l’id pour les opérations (incluant le stockage de la clé privée). Ce moteur n’est pas utilisé comme source pour les algorithmes digest, à moins qu’il soit également spécifié dans le fichier de configuration
-sigopt nm:v Passer des options à l’algorithme de signature durant les opérations de signature et de vérification.
-passing arg Mot de passe de la source du mot de passe.
-verify filename Vérifie la signature en utilisant la clé publique dans le fichier spécifié.
-prverify filename Vérifie la signature en utilisant la clé privée dans le fichier spécifié.
-signature filename La signature à vérifier
-hmac key Créé un MAC hashé en utilisant la clé spécifiée.
-mac alg Créer un MAC en utilisant l’algorithme spécifié.
-macopt nm:v Passer des options à l’algorithme MAC
-rand file(s) Spécifier le(s) fichier(s) à utiliser pour le générateur de nombre aléatoire, ou un socket EGD.
file... Fichier en entrée pour les opération de digest.
^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - dhparam

OpenSSL - dhparam

Génération et manipulation de paramètre DH

OPTIONS

-inform DER|PEM Format du fichier d'entrée
-outform DER|PEM Format du fichier de sortie
-in filename Fichier d'entrée
-out filename Fichier de sortie
-dsaparam Si spécifié, les paramètres DSA sont lus ou créé au lieu de paramètres DH; ils sont convertis au format DH. Sinon, les premiers 'fort' seront utilisé pour la génération de paramètres DH.
-check Vérifie si les paramètres sont valides
-2, -5 Générateur à utiliser. Si présent, le fichier d'entrée est ignoré et les paramètres sont générés. Défaut: 2
-rand file(s) Fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoire, ou un socket EGD.
numbits Spécifie le nombre de bit à utiliser. Doit être la dernière option. Défaut: 2048
-noout Inhibe la sortie de la version encodée des paramètres
-text Affiche les paramètres DH au format lisible
-C Convertis les paramètres en code C. Les paramètres peuvent ainsi être chargés en appelant get_dhNNNN()
-engine id dhparam va tenter d'obtenir une référence fonctionnelle du moteur spécifié.

Notes

   Le programme dhparam combine les fonctionnalités des programmes dh et gendh dans les versions précédentes de OpenSSL. Les programmes dh et gendh sont retenus pour d'autres utilisations dans le future.

Les paramètres DH au format PEM utilisent les en-tête et pied de page suivant:
-----BEGIN DH PARAMETERS-----
-----END DH PARAMETERS-----

   Openssl supporte actuellement l'ancien PKCS#3 DH, pas le nouveau X9.42 DH.
^
01 mars 2012

htmlpdflatexmanmd




OpenSSL - dsa

OpenSSL - dsa

Traitement des clés dsa. Utilise le format compatible SSLeay pour le chiffrement des clés privées, les applications devraient utiliser pkcs8, plus sécure.

OPTIONS

-inform DER|PEM Format du fichier d’entrée. DER avec une clé privée utilise une forme encodée ASN1 DER d’une séquence ASN.1 consistant de valeurs de version (0 actuellement), p, q, g, les clés publique et privée en tant qu’entier ASN.1.
-outform DER|PEM Format de la sortie.
-in filename Fichier contenant la clé à lire
-passing arg Source du mot de passe du fichier d’entrée.
-out filename fichier de sortie où écrire une clé.
-passout arg source du mot de passe du fichier de sortie
-des|des3|-idea Algorithme utilisé pour chiffrer la clé privée.
-text Affiche la clé privée, publique et les paramètres
-noout n’affiche pas la sortie encodée de la clé
-modulus Affiche la valeur de la composante clé publique de la clé
-pubin Par défaut, la clé privée est lue depuis le fichier d’entrée. Cette option lit une clé publique à la place.
-pubout Par défaut, une clé privée est sortie. Avec cette option, une clé publique est sortie.
-engine id dsa va tenter d’obtenir une référence fonctionnelle au moteur spécifié.

Notes

Le format de clé privée PEM utilise:
-----BEGIN DSA PRIVATE KEY-----
-----END DSA PRIVATE KEY-----
Le format de clé publique PEM utilise:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

Exemples

Supprimer une passphrase d’une clé privée DSA:
openssl dsa -in key.pem -out keyout.pem
Chiffrer une clé privée en utilisant 3DES:
openssl dsa -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl dsa -in key.pem -outform DER -out keyout.der
Afficher les composants d’une clé privée sur stdout:
openssl dsa -in key.pem -text -noout
Affiche la partie publique d’une clé privée:
openssl dsa -in key.pem -pubout -out pubkey.pem
^
01 mars 2012

htmlpdflatexmanmd




OpenSSL - dsaparam

OpenSSL - dsaparam

Manipulation et génération de paramètres DSA

OPTIONS

-inform DER|PEM Format du fichier d’entrée. DER avec une clé privée utilise une forme encodée ASN1 DER d’une séquence ASN.1 consistant de valeurs de version (0 actuellement), p, q, g, les clés publique et privée en tant qu’entier ASN.1.
-outform DER|PEM Format de la sortie.
-in filename Fichier contenant les paramètres à lire
-out filename fichier de sortie où écrire les paramètres
-text Affiche les paramètres DSA de manière compréhensible
-noout n’affiche pas la version encodée des paramètres
-C Convertir les paramètres en code C.
-genkey Génère un DSA en utilisant soit les paramètres spécifiés, soit les paramètres générés.
-rand file(s) Le(s) fichier(s) utilisé par le générateur de nombre aléatoire.
numbits Taille en bits des paramètres générés.
-engine id dsaparam va tenter d’obtenir une référence fonctionnelle au moteur spécifié.

Notes

Les paramètres DSA PEM utilisent:
-----BEGIN DSA PARAMETERS-----
-----END DSA PARAMETERS-----

^
12 mai 2015

htmlpdflatexmanmd




OpenSSL - ec

OpenSSL - ec

Outil de traitement de clé EC

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie où écrire la clé
-passout password source du mot de passe du fichier de sortie
-des|-des3|-idea Chiffre la clé privée avec DES, triple DES ou IDEA, ou un autre chiffrement supporté
-text Affiche des infos sur les clés privée et publique
-noout N’affiche pas la version encodée de la clé
-modulus Affiche la valeur du modulo de la clé
-pubin Lit une clé publique en entrée plutôt qu’une clé privée
-pubout Sort une clé publique plutôt qu’une clé privée
-engine id ec va tenter d’obtenir une référence fonctionnelle de ce moteur.
-conv_form Spécifie comment les points sur la courbe elliptique sont convertis en chaîne d'octets ( compressed, uncompressed ou hybrid ).
-param_enc arg Spécifie comment les paramètres de courbe elliptique sont encodés. named_curve ou explicit

Notes

la forme PEM de la clé privée contient:
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----

Exemples

Chiffrer une clé privée avec 3DES:
openssl ec -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl ec -in key.pem -outform DER -out keyout.der
Afficher les composants d'une clé privée sur stdout:
openssl ec -in key.pem -text -noout
Afficher la partie publique d'une clé privée:
openssl ec -in key.pem -pubout -out pubkey.pem
Changer les paramètres d'encodage à explicit:
openssl ec -in key.pem -param_enc explicit -out keyout.pem
Changer la conversion de point à compressed:
openssl ec -in key.pem -conv_form compressed -out keyout.pem
^
12 mai 2015

htmlpdflatexmanmd




OpenSSL - ecparam

OpenSSL - ecparam

Manipulation et génération de paramètre EC

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-out filename fichier de sortie où écrire les paramètres
-text Affiche des infos sur les clés privée et publique
-noout n’affiche pas la version encodée des paramètres
-C Convertis les paramètres EC en code C.
-check Valide les paramètres de courbe elliptique
-name arg Utilise les paramètres EC avec le nom court spécifié.
-list_curves Affiche la liste de tous les paramètres EC implémentés.
-conv_form Spécifie comment les points sur la courbe elliptique sont convertis en chaîne d'octets ( compressed, uncompressed ou hybrid ).
-param_enc arg Spécifie comment les paramètres de courbe elliptique sont encodés. named_curve ou explicit
-no_seed Inhibe que le 'seed' pour la génération de paramètre soit inclus dans la structure ECParameters
-genkey Génère une clé privée EC en utilisant les paramètres spécifiés
-rand file Un ou plusieurs fichiers contenant des données aléatoires.
-engine id ecparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM des paramètres EC utilisent la forme:
-----BEGIN EC PARAMETERS-----
-----END EC PARAMETERS-----

Exemples

Créer des paramètres EC avec le groupe 'prime192v1':
openssl ecparam -out ec_param.pem -name prime192v1
Créer des paramètres EC avec les paramètres explicites:
openssl ecparam -out ec_param.pem -name prime192v1 -param_enc explicit
Valider les paramètres EC donnés:
openssl ecparam -in ec_param.pem -check
Créer des paramètres EC et une clé privée:
openssl ecparam -out ec_key.pem -name prime192v1 -genkey
Changer l'encodage des points à compressed:
openssl ecparam -in ec_in.pem -out ec_out.pem -conv_form compressed
Afficher les paramètres EC:
openssl ecparam -in ec_param.pem -noout -text
^
06 mars 2012

htmlpdflatexmanmd




OpenSSL - enc

OpenSSL - enc

Routines de chiffrements symétriques

   Permet de chiffrer ou déchiffrer des données en utilisant divers block ou flux de chiffrement en utilisant des clés basé sur mot de passe ou fournis explicitement. L’encodage/décodage en base 64 peut également être effectué en plus du chiffrement/déchiffrement.

OPTIONS

-in filename Fichier d’entrée
-out filename Fichier de sortie
-pass arg Source du mot de passe
-salt Utilise un Salt dans les routines de dérivation de clé pendant le chiffrement (défaut). Généré aléatoirement avec l’option -S
-nosalt N’utilise pas de Salt. Ne doit être utilisé que pour des tests un pour compatibilité avec des anciennes versions d’OpenSSL.
-S salt Le Salt à utiliser au format hexa
-e  Chiffre la donnée en entrée (défaut)
-d Déchiffre la donnée en entrée
-a Traite les données en base 64.
-base64 Idem à -a
-A si -a, le traitement base64 se fait sur une ligne
-k password Le mot de passe à dériver de la clé. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-kfile filename Le mot de passe à dériver de la clé depuis ce fichier. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-K key La clé à utiliser en hexa. IV doit être spécifié avec -iv. Si la clé et le mot de passe sont spécifiés, IV est généré depuis le mot de passe.
-iv IV L’IV à utiliser en hexa
-p Afficher la clé et l’IV utilisé
-P Idem à -p mais quitte immédiatement
-bufsize number Définis la taille du tampon pour les E/S
-nopad Désactive le padding de block standard
-debug Débug les BIO utilisé pour les E/S
-z Compresse ou décompresse en texte clair en utilisant zlib avant le chiffrement ou après le déchiffrement.
-none Utilise le chiffrement NULL

Notes

   Les moteurs qui fournissent de nouveaux algorithmes de chiffrement (tel que ccgost qui fournis l’algorithme gost89) devraient être configurés dans le fichier de configuration. Les moteurs spécifiés sur la ligne de commande peuvent seulement être utilisé avec des implémentations de chiffrement assisté par hardware supportés par OpenSSL core.

Chiffrements supportés

Noter que certains chiffrements peuvent être désactivés à la compilation.
base64 Base 64
    
bf-cbc Blowfish in CBC mode
bf Alias for bf-cbc
bf-cfb Blowfish in CFB mode
bf-ecb Blowfish in ECB mode
bf-ofb Blowfish in OFB mode
    
cast-cbc CAST in CBC mode
cast Alias for cast-cbc
cast5-cbc CAST5 in CBC mode
cast5-cfb CAST5 in CFB mode
cast5-ecb CAST5 in ECB mode
cast5-ofb CAST5 in OFB mode
    
des-cbc DES in CBC mode
des Alias for des-cbc
des-cfb DES in CBC mode
des-ofb DES in OFB mode
des-ecb DES in ECB mode
    
des-ede-cbc Two key triple DES EDE in CBC mode
des-ede Two key triple DES EDE in ECB mode
des-ede-cfb Two key triple DES EDE in CFB mode
des-ede-ofb Two key triple DES EDE in OFB mode
    
des-ede3-cbc Three key triple DES EDE in CBC mode
des-ede3 Three key triple DES EDE in ECB mode
des3 Alias for des-ede3-cbc
des-ede3-cfb Three key triple DES EDE CFB mode
des-ede3-ofb Three key triple DES EDE in OFB mode
    
desx DESX algorithm.
    
gost89 GOST 28147-89 in CFB mode (provided by ccgost engine)
gost89-cnt `GOST 28147-89 in CNT mode (provided by ccgost engine)
    
idea-cbc IDEA algorithm in CBC mode
idea same as idea-cbc
idea-cfb IDEA in CFB mode
idea-ecb IDEA in ECB mode
idea-ofb IDEA in OFB mode
    
rc2-cbc 128 bit RC2 in CBC mode
rc2 Alias for rc2-cbc
rc2-cfb 128 bit RC2 in CFB mode
rc2-ecb 128 bit RC2 in ECB mode
rc2-ofb 128 bit RC2 in OFB mode
rc2-64-cbc 64 bit RC2 in CBC mode
rc2-40-cbc 40 bit RC2 in CBC mode
    
rc4 128 bit RC4
rc4-64 64 bit RC4
rc4-40 40 bit RC4
    
rc5-cbc RC5 cipher in CBC mode
rc5 Alias for rc5-cbc
rc5-cfb RC5 cipher in CFB mode
rc5-ecb RC5 cipher in ECB mode
rc5-ofb RC5 cipher in OFB mode
    
aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode
aes-[128|192|256] Alias for aes-[128|192|256]-cbc
aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode
aes-[128|192|256]-cfb1 128/192/256 bit AES in 1 bit CFB mode
aes-[128|192|256]-cfb8 128/192/256 bit AES in 8 bit CFB mode
aes-[128|192|256]-ecb 128/192/256 bit AES in ECB mode
aes-[128|192|256]-ofb 128/192/256 bit AES in OFB mode

Exemples

Encoder un fichier binaire en base 64
openssl base64 -in file.bin -out file.b64
Décoder le même fichier
openssl base64 -f -in file.b64 -out file.bin
Chiffrer un fichier avec 3DES en mode CBC
openssl des3 -salt -in file.txt -out file.des3
Déchiffrer un fichier en fournissant le mot de passe
openssl des3 -d -salt -in file.des3 -out file.txt -k mypassword
Chiffrer un fichier puis l’encoder en base 64 avec blowfish en mode CBC
openssl bf -a -salt -in file.txt -out file.bf
Décode un fichier base 64 et le déchiffrer
openssl bf -d -salt -a -in file.bf -out file.txt
Déchiffre des données en utilisant une clé RC4 40 Bits
openssl rc4-40 -in file.rc4 -out file.txt -K 0102030405
^
06 mars 2012

htmlpdflatexmanmd




OpenSSL - ErrStr

OpenSSL - ErrStr

Utilitaire pour afficher la description d'un code d'erreur

Exemple

le code d’erreur suivant:
27594:error:2006D080:lib(32):func(109):reason(128):bss_file.c:107:
avec openssl errstr 2006D080 produit:
error:2006D080:BIO routines:BIO_new_file:no such file
^
07 mars 2012

htmlpdflatexmanmd




OpenSSL - gendsa

OpenSSL - gendsa

Génère des clés privées DSA à partir de fichiers de paramètres DSA

OPTIONS

-des|-des3|-idea Algorithme à utiliser pour chiffrer la clé privée.
-rand file(s) Fichiers utilisés pour le génération de nombre aléatoire
-engine id gendsa va tenter d’obtenir un référence fonctionnelle pour le moteur spécifié.
^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - genpkey

OpenSSL - genpkey

Génération de clé privée

OPTIONS

-out filename Nom du fichier de sortie
-outform PEM|DER Format du fichier de sortie
-pass arg Source du mot de passe du fichier de sortie
-cipher Algorithme à utiliser pour chiffrer la clé privée.
-engine id genpkey va tenter d’obtenir une référence fonctionnelle pour le moteur spécifié.
-algorithm alg Algorithme de clé publique à utiliser tel que RSA, DSA ou DH. Doit précéder -pkeyopt
-pkeyopt opt:value Définis une option pour l’algorithme de clé publique.
-genparam Génère un jeu de paramètres au lieu d’une clé privée. Doit précéder -algorithm, -paramfile ou -pkeyopt
-paramfile filename Fichier contenant les paramètres à utiliser pour générer la clé privée. Doit précéder -pkeyopt.
-text Affiche une représentation texte des clés publique et privée et des paramètres.

Options de génération de clé

   Les options prises en charge par chaque algorithme et même chaque mise en œuvre d’un algorithme peut varier.

Options de génération de clé RSA

rsa_keygen_bits:numbits Nombre de bits dans la clé générée. (défaut : 1024)
rsa_keygen_pubexp:value Valeur d’exposant publique RSA, en décimal ou hexa (défaut : 65537)

Options de génération de clé DSA

dsa_paramgen_bits:numbits Nombre de bits dans les paramètres générés (défaut 1024)

Options de génération de paramètres DH

dh_paramgen_prime_len:numbits Nombre de bits dans le paramètre p
dh_paramgen_generator:value valeur à utiliser pour le générateur g
dh_rfc5114:num Applique les paramètres RFC5114. num peut être (1 : groupe de 1024 avec sous-groupe 160bits, 2 : groupe de 2048 avec sous-groupe 224bits ,3 : groupe de 2048 avec sous-groupe 256bits).

Options de génération de paramètres EC

ec_paramgen_curve:curve La courbe EC à utiliser

Options de paramètres et de génération de clé GOST2001

paramset:name Spécifie le paramètre GOST R 34.10-2001 en accord avec la RFC 4357. Les paramètres suivants sont supportés

paramset   OID               Usage
A 1.2.643.2.2.35.1 Signature
B 1.2.643.2.2.35.2 Signature
C 1.2.643.2.2.35.3 Signature
XA 1.2.643.2.2.36.0 Key exchange
XB 1.2.643.2.2.36.1 Key exchange
test 1.2.643.2.2.35.0 Test purposes

Exemples

Générer une clé privée RSA en utilisant les paramètres par défaut:
openssl genpkey -algorithm RSA -out key.pem
Chiffrer une clé privée en utilisant AES128 et la passphrase 'hello':
openssl genpkey -algorithm RSA -out key.pem -aes-128-cbc -pass pass:hello
Générer une clé RSA 2048bits et un exposant publique 3:
openssl genpkey -algorithm RSA -out key.pem -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:3
Générer des paramètres DSA 1024bits:
openssl genpkey -genparam -algorithm DSA -out dsap.pem -pkeyopt dsa_paramgen_bits:1024
Générer une clé DSA depuis des paramètres:
openssl genpkey -paramfile dsap.pem -out dsakey.pem
Générer des paramètres DH 1024bits:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_paramgen_prime_len:1024
sortir des paramètres DH RFC5114 type 2:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_rfc5114:2
Générer une clé DH depuis des paramètres:
openssl genpkey -paramfile dhp.pem -out dhkey.pem
^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - genrsa

OpenSSL - genrsa

Outil de génération de clé RSA, remplacé par genpkey

OPTIONS

-out filename Nom du fichier de sortie
-passout arg Source du mot de passe pour le fichier de sortie
-des|-des3|-idea Algorithme à utiliser pour chiffrer la clé privée
-F4|-3 L’exposant publique à utiliser, soit 65537 ou 3. (défaut 65537)
-rand file(s) fichier(s) contenant les données aléatoires utilisée par le générateur de nombre aléatoire.
-engine id genrsa va tenter d’obtenir une référence fonctionnelle pour le moteur spécifié.
numbits Taille de la clé privée, doit être le dernier argument (défaut 512)
^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - nseq

OpenSSL - nseq

Créer ou examiner une séquence de certificat Netscape

OPTIONS

-in filename Fichier à examiner
-out filename Fichier de sortie
-toseq Normalement, une séquence de certificat Netscape sera fournis et la sortie contient les certificats.et cette option, la situation et inversée.

Exemples

Sortir les certificats d’une séquence de certificat Netscape:
openssl nseq -in nseq.pem -out certs.pem
Créer une séquence de certificat Netscape:
openssl nseq -in certs.pem -toseq -out nseq.pem

Notes

La forme PEM utilise:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - ocsp

OpenSSL - ocsp

Utilitaire OCSP

Options client

-out filename Fichier de sortie
-issuer filename Spécifie l’issuer du certificat courant. Peut-être spécifié plusieurs fois et doit être au format PEM. Doit être spécifié avant -cert
-cert filename Ajoute le certificat spécifié à la requête.
-serial num Idem à cert excepté que le certificat avec le numéro de série spécifié est ajouté à la requête, en entier décimal précédé par 0x. Des valeurs négatives sont acceptées.
-signer filename, -signkey filename Signe la requête OCSP en utilisant le certificat spécifié par signer et la clé privée spécifiée par signkey. Sans signkey, lit la clé privée depuis le certificat du signer. Sans ces 2 options, la requête n’est pas signée.
-sign_other filename Certificats additionnels à inclure dans la requête signée.
-nonce, -no-once Ajoute ou désactive une extension OCSP nonce d’une requête. Normalement si une requête OCSP est entrée en utilisant respin, nonce n’est pas ajouté. Si une requête OCSP est créée, un nonce est automatiquement ajouté.
-req_text, -resp_text, -text Affiche la forme texte d’une requête ou d’une réponse OCSP ou les 2 respectivement.
-reqout file, respout file Écrit la requête ou la réponse en DER
-reqin file, respin file Lit la requête ou la réponse depuis le fichier spécifié.
-url responder_url Spécifie l’url du répondeur.
-host hostname:port, path pathname La requête est envoyée à l’hôte spécifié, ou le chemin HTTP (défaut : /)
-CAfile file, -CApath pathname Fichier ou répertoire contenant les certificats CA. Utilisé pour vérifier la réponse OCSP.
-verify_other file Fichier contenant des certificats additionnels à rechercher lors de la tentative de localisation du certificat de signature de la réponse OCSP.
-trust_other Les certificats spécifié par -verify_other sont explicitement trustés sans vérification additionnelles. Utile pour une chaîne complète de certificat.
-VAfile file Fichier contenant les certificats du répondeur trustés explicitement. Equivalent à -verify_other et -trust_other.
-noverify Ne vérifie par la signature du répondeur OCSP ou les valeurs nonce.
-no_intern Ignore les certificats contenus dans la réponse OCSP lors de la recherche du certificat du signataire.
-no_signature_verify Ne vérifie pas la signature de la réponse OCSP.
-no_cert_verify Ne vérifie par les certifications des signataires de la réponse OCSP.
-no_chain N’utilise pas les certificats dans la réponse comme certificats CA additionnels non-trustés.
-no_cert_checks N’effectue aucune vérification supplémentaire sur les certificats des signataires de la réponse OCSP
-validity_period nsec, -status_age age Spécifie la plage de temps en secondes toléré dans une réponse OCSP. Chaque réponse de statut de certificat inclus notBefore et notAfter. Le temps courant devrait être entre ces 2 valeurs. Cette options permet de spécifier une autre plage de temps.
-md5|-sha1|-sha256|-ripemod160|... Définis l’algorithme digest à utiliser pour l’identification du certificat dans la requête OCSP. Défaut : SHA1.

Options serveur

-index indexfile Fichier d’index au format ca contenant les informations de révocation de certificat. Si cette option est spécifiée, ocsp est en mode répondeur, sinon il est en mode client.
-CA file Certificat CA correspondant aux informations de révocation dans indexfile.
-rsigner file Certificat pour signer les réponses
-rother file Certificats additionnels à inclure dans la réponse
-resp_no_certs N’inclus pas de certificat dans la réponse.
-resp_key_id Identifie le certificat signataire en utilisant l’ID de clé. Défaut : utilise le nom du sujet.
-rkey file La clé privée pour signer les réponses.
-port portnum Port d’écoute des requêtes OCSP. Doit être spécifié dans l’option url.
-nrequest number Le serveur va quitter après avoir reçu number requêtes, défaut : illimité.
-nmin minutes, -ndays days Nombre de minutes ou de jours où de nouvelles informations de révocation sont disponibles. Utilisé dans le champ nextUpdate. Sans cette option, ce champ est omis, les nouvelles informations sont immédiatement disponible.

Exemples

Créer une requête OCSP et l’écrire dans un fichier:
openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -reqout req.der
Envoyer une requête à un répondeur OCSP:
openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -url http://ocsp.myhost.com/ -resp_text -respout resp.der
Lire une réponse OCSP et l’afficher au format texte:
openssl ocsp -respin resp.der -text
Serveur OCSP sur le port 8888 en utilisant une configuration standard CA, et un certificat de répondeur séparé:
openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem -text -out log.txt
Idem, mais quitte après 1 requête:
openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem -nrequest 1
Demander des informations de statut en utilisant une requête générée en interne:
openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem -issuer demoCA/cacert.pem -serial 1
Demander des informations de statut en utilisant une requête lu depuis un fichier, sort la réponse dans un autre fichier:
openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem -reqin req.der -respout resp.der
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - passwd

OpenSSL - passwd

Calcul des hash de mot de passe

OPTIONS

-crypt Utilise l’algorithme crypt (défaut)
-1 Utilise l’algorithme MD5 type BSD 1
-apr1 utilise l’algorithme aprl (variante apache de l’algorithme BSD)
-salt string Spécifier le salt à utiliser. Implique -noverify
-in file Fichier contenant les mots de passes
-stdin Lit les mots de passe depuis stdin
-noverify n’effectue pas de vérification lors de la lecture d’un mot de passe depuis le terminal
-quiet n’affiche pas d’alertes quand les mots de passe donnés sur la ligne de commande sont tronqués.
-table Dans la liste de sortie, ajoute les mots de passe en texte clair, suivi d’un TAB et du hash.

Exemples

openssl passwd -crypt -salt xx password:
xxj31ZMTZzkVA
openssl passwd -1 -salt xxxxxxxx password:
$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.
openssl passwd -apr1 -salt xxxxxxxx password:
$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkcs12

OpenSSL - pkcs12

Utilitaire pkcs #12

Options de lecture

-in filename Fichier pkcs#12 à lire
-out filename Fichier où écrire les certificats et clé privée au format PEM.
-pass arg, -passin arg passphrase pour chiffrer les clés privées
-noout Ne sort pas les clé et certificats dans le fichier de sortie.
-clcerts sort uniquement les certificats clients (pas de certificat CA)
-cacerts sort uniquement les certificats CA
-nocerts Ne sort pas les certificats
-nokeys Ne sort pas les clés privées
-info Affiche des informations additionnelles sur la structure du fichier PKCS#12
-des|-des3|-idea|-aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256 Algorithme à utiliser pour chiffrer la clé privée.(défaut : des3)
-nodes Ne chiffre pas les clés privées
-nomacver Ne tente pas de vérifier l’intégrité MAC avant de lire le fichier
-twopass Séparer l’intégrité et le chiffrement du mot de passe. Peut rendre le fichier illisible.

Options de création

-export Spécifie une création de fichier PKCS#12
-out filename Nom du fichier PKCS#12 à créer
-in filename Fichier à lire contenant les certificats et clé privées au format PEM
-inkey filename fichier contenant la clé privée à lire.
-name friendlyname ’friendly name’ pour le certificat et sa clé privée.
-certfile filename Fichier où lire les certificats additionnels
-caname friendlyname friendly name’ pour les autres certificats. Peut-être spécifié plusieurs fois
-pass arg, -passout arg source du mot de passe pour le fichier de sortie.
-passin password Source du mot de passe pour déchiffrer la clé privée.
-chain Tente d’inclure toute la chaîne de certificat
-descert Chiffre le certificat en utilisant 3des (défaut : des3 pour la clé privée et RC2-40bits pour le certificat)
-keypbe alg, -certpbe alg Algorithme utilisé pour chiffrer la clé et les certificats. peut-être un algorithme PKCS#15 ou PKCS#12 PBE.
-keyex|-keysig Spécifie que la clé privée doit être utilisé pour un échange de clé ou juste signer. Uniquement interprété par MSIE et logiciels MS.
-macalg digest Spécifie l’algorithme digest MAC (défaut : SHA1)
-nomaciter, -noiter Affecte le compteur d’itération dans les algorithmes de clé et MAC.(défaut : 2048)
-maciter Inclus pour compatibilité avec les versions précédentes.
-nomac Ne tente pas de fournir l’intégrité MAC.
-rand file(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.
-CAfile file Fichier de la CA
-CAptah dir Répertoire contenant les certificats CA.
-CSP name Ecrit le nom sous la forme Microsoft CSP name.

Exemples

Lire un fichier PKCS #12 et le sortir dans un fichier:
openssl pkcs12 -in file.p12 -out file.pem
Sortie seulement les certificats clients dans un fichier:
openssl pkcs12 -in file.p12 -clcerts -out file.pem
Sortir uniquement la clé privée dans un fichier:
openssl pkcs12 -in file.p12 -nocerts -out file.pem
Ne pas chiffrer la clé privée:
openssl pkcs12 -in file.p12 -out file.pem -nodes
Afficher des informations sur le fichier PKCS #12:
openssl pkcs12 -in file.p12 -info -noout
Créer un fichier PKCS #12:
openssl pkcs12 -export -in file.pem -out file.p12 -name "My Certificate"
Inclure des certificats supplémentaires:
openssl pkcs12 -export -in file.pem -out file.p12 -name "My Certificate" -certfile othercerts.pem
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkcs7

OpenSSL - pkcs7

Utilitaire pkcs #7

OPTIONS

-inform DER|PEM Spécifie le format d’entrée
-outform DER|PEM Spécifie le format de sortie
-in filename Fichier à lire
-out filename Fichier à écrire
-print-certs Affiche les certificats et CRL contenus dans le fichier.
-text Affiche les détails des certificats
-noout Ne sort pas la version encodée de la structure PKCS #7
-engine id pkcs7 va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Convertir un fichier PKCS #7 PEM en DER:
openssl pkcs7 -in file.pem -outform DER -out file.der
Afficher tous les certificats dans un fichier:
openssl pkcs7 -in file.pem -print_certs -out certs.pem

Notes

Le format PKCS #7 PEM utilise:
-----BEGIN PKCS7-----
-----END PKCS7-----

Pour assurer la compatibilité avec certaines CA, il accepte également:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - pkcs8

OpenSSL - pkcs8

Outil de conversion de clé privée au format pkcs#8

   Cette commande traite les clé privées au format pkcs#8. Elle peut gérer le format PrivateKeyInfo et EncryptedPrivateKeyInfo avec divers algorithmes PKCS#5 (1.5 et 2.0) et PKCS#12.

OPTIONS

-topk8 Normallement une clé privée PKCS#8 est attendue en entrée et un format de clé privée traditionnel est écris. Cette option inverse la situation
-inform DER|PEM Spécifie le format d'entrée
-outform DER|PEM Spécifie le format de sortie
-passing arg Source du mot de passe du fichier d'entrée
-out filename Fichier de sortie
-passout arg source du mot de passe du fichier de sortie
-iter count En créant un nouveau conteneur PKCS#8, utilise le nombre d'itérations donné sur le mot de passe pour dériver la clé de chiffrement.
-nocrypt Les clé PKCS#8 générées sont normallement des structures EncryptedPrivateKeyInfo. Cette option créé des structure PrivateKeyInfo.
-2 alg Active l'utilisation des algorithmes PKCS#5 v2.0. Normalement les clés privées PKCS#8 sont chiffrées avec un mot de passe basé sur l'algorithme de chiffrement pbeWithMD5AndDES-CBC qui utilise DES 56-bits. PKCS#5 v2.0 permet d'utiliser des algorithmes tel que 3DES 168bits, ou RC2 128bits.
-v2prf alg Définis l'algorithme PRF à utiliser avec PKCS#5 v2.0. Une valeur typique est hmacWithSHA256
-v1 alg Définis l'algorithme PKCS#5 v1.5 ou PKCS#12 à utiliser.
-nooct Génère des clé privées RSA dans un format cassé que certains logiciels utilisent
-embed Génère des clé DSA dans un format cassé.
-nsdb Génère des clé DSA dans un format cassé compatible avec les base de clé privée Netscape.
-engine id pkcs8 va tenter d'obtenir une référence fonctionnelle du moteur spécifié.
-scrypt Utilise l'algorithme scrypt pour le chiffrement de la clé privée en utilisant les paramètres par défaut. Actuellement N=16384, r=8 et p=1 et AES en mode CBC avec une clé 256 bits. Ces paramètres peuvent être modifiés avec -scrypt_N, -scrypt_r, -scrypt_p et -v2

Notes

Le format chiffré des fichiers PKCS#8 encodés PEM utilisent les en-tête et fin suivant:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

La version non-chiffrée:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

   Les clé privées chiffrées en utilisant PKCS#5 v2.0 et un compteur d'itération élevé sont plus sécurisés que ceux chiffrés en utilisant les formats compatible SSLeay traditionnels. Le chiffrement par défaut est seulement de 56bits parce que c'est le chiffrement le plus courant dans les implémentations supportant PKCS#8.

   Certains logiciels peuvent utiliser des algorithmes de chiffrement basé sur mot de passe PKCS#12 avec des clés privées au format PKCS#8: ils sont gérés automatiquement mais il n'y a pas d'option pour les produire.

   Il est possible d'écrire des clé privée encodées DER au format PKCS#8 parce que les détails de chiffrement sont inclus au niveau ASN1 alors que le format traditionnel les inclus au niveau PEM.

Algorithmes PKCS#5 v1.5 et PKCS#12

   Divers algorithmes peuvent être utilisés avec l'option -v1, incluant PKCS#5 v1.5 et PKCS#12:

PBE-MD2-DES PBE-MD5-DES Ces algorithmes sont inclus dans la spécification PKCS#5 v1.5. Ils offrent une protection 56-bits vu qu'ils utilisent DES
PBE-SHA1-RC2-64 PBE-MD2-RC2-64 PBE-MD5-RC2-64 PBE-SHA1-DES Ces algorithmes ne sont pas mentionnés dans la spécification PKCS#5 v1.5 mais utilisent le même algorithme de dérivation de clé et sont supportés par certains logiciels. Ils sont mentionnés dans PKCS#5 v2.0. Ils utilisent soit rs2 64bits, ou DES 56bits
PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40 Ces algorithems utilisent l'algorithme de chiffrement de mot de passe PKCS#12 et utilisent 3DES ou rc2 128bits.

Exemples

Convertir une forme privée traditionnelle en PKCS#5 v2.0 avec 3DES
openssl pkcs8 -in key.pem -topk8 -v2 des3 -out enckey.pem
Convertir un forme privée traditionnelle en PKCS#5 v2.0 avec AES 256 en mode CBC et hmacWithSHA256 PRF
openssl pkcs8 -in key.pem -topk8 -v2 aes-256-cbc -v2prf hmacWithSHA256 -out enckey.pem
Convertir une clé privée en PKCS#8 utilisant PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem
Convertir un clé privée en PKCS#8 en utilisant un algorithme compatible PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem -v1 PBE-SHA1-3DES
Lire une clé privée PKCS#8 DER non-chiffré
openssl pkcs8 -inform DER -nocrypt -in key.der -out key.pem
Convertir une clé privée depuis un format PKCS#8 dans un format traditionnel
openssl pkcs8 -in pk8.pem -out key.pem
Convertir une clé privée au format PKCS#8, la chiffrer avec AES-256 et un million d'itération
openssl pkcs8 -in raw.pem -topk8 -v2 aes-256-cbc -iter 1000000 -out pk8.pem

Standards

   Le format des clé privée DSA PKCS#8 (et d'autres) ne sont pas bien documentés: c'est caché dans PKCS#11 v2.01, section 11.9. Openssl se conforme à ce standard.
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkey

OpenSSL - pkey

Outil de traitement de clé privée ou publique

OPTIONS

-inform DER|PEM Format du fichier d’entrée
-outform DER|PEM Spécifie le format de sortie
-in filename Fichier à lire
-out filename Fichier à écrire
-passin arg source du mot de passe du fichier d’entrée
-passout password source du mot de passe du fichier de sortie.
-cipher Chiffre la clé privée avec le chiffrement spécifié
-text Affiche les composant de clé privée ou publique en texte clair en plus de la version encodée.
-text_pub Affiche uniquement la composante clé publique.
-noout Ne sort pas la version encodée de la clé
-pubin Par défaut, la clé privée est lue depuis le fichier d’entrée, cette option lit une clé publique à la place
-pubout Par défaut une clé privée est écrite en sortie. Cette option sort une clé publique.
-engine id pkey va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Enlever un passphrase d’une clé RSA:
openssl pkey -in key.pem -out keyout.pem
Chiffrer une clé publique avec 3DES:
openssl pkey -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl pkey -in key.pem -outform DER -out keyout.der
Afficher les composants de clé privée:
openssl pkey -in key.pem -text -noout
Afficher les composants publics d’une clé privée:
openssl pkey -in key.pem -text_pub -noout
Sortie la partie publique d’une clé privée:
openssl pkey -in key.pem -pubout -out pubkey.pem
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkeyparam

OpenSSL - pkeyparam

Outil de traitement de paramètres d'algorithme de clé publique

OPTIONS

-in filename Fichier à lire au format PEM
-out filename Fichier à écrire au format PEM
-text Affiche les paramètres en clair en plus de la version encodée
-noout Ne sort pas la version encodée des paramètres
-engine id pkeyparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Afficher la version des paramètres:
openssl pkeyparam -in param.pem -text
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - pkeyutl

OpenSSL - pkeyutl

Utilitaire de manipulation de clé publique

OPTIONS

-in filename Spécifie le nom du fichier d’entrée
-out filename Spécifie le fichier de sortie
-inkey file fichier clé d’entrée, par défaut devrait être une clé privée.
-keyform PEM|DER Format de clé PEM, DER ou ENGINE
-passin arg Source du mot de passe de la clé en entrée
-peerkey file Fichier de clé pair, utilisé par les opérations de dérivation de clé
-peerform PEM|DER Format du fichier de clé pair PEM, DER ou ENGINE
-engine id pkeyutil va tenter d’obtenir une référence fonctionnelle de ce moteur.
-pubin Le fichier d’entrée est une clé publique
-certin L’entrée est un certificat contenant une clé publique
-rev Renverse l’ordre du tampon d’entrée. Utile pour certains libraires comme CryptoAPI qui présente l’entrée au format little endian
-sign Signe les données d’entrée et sort le résultat signé, requière une clé privée.
-verify Vérifie les données en entrée avec le fichier de signature et indique si l’opération à réussie ou non
-verifyrecover Vérifie les données entrée et sort les données récupérées
-encrypt Chiffre les données en entrée en utilisant un clé publique
-decrypt Déchiffre les données en entrée en utilisant une clé privée
-derive Dérive une clé partagée en utilisant une clé paire
-hexdump Dump en hexa les données sorties
-asn1parse asn1parse les données en sortie. Utilisé avec -verifyrecover

Notes

   Les opérations et options dépendent de l’algorithme de clé et de son implémentation. Tous les algorithmes supportent l’option digest:alg qui spécifie le digest à utiliser pour les opérations de signature et vérification.

RSA

   RSA supporte les opérations de chiffrement, déchiffrement, signature et vérification.

-rsa_padding_mode:mode Définis le padding RSA. (pkcs1, sslv23, none oaep, x931 et pss). oeap supporte uniquement le chiffrement et déchiffrement. pss support uniquement la signature et la vérification. rsa_pss_saltlen:len pour le mode pss, spécifie la longueur du salt. (Valeurs spéciales : -1 - le salt est à la longueur du digest, -2 - valeur maximum permise).

DSA

   DSA support les opérations de signature et de vérification uniquement.

DH

   DH supporte uniquement les opérations de dérivation

EC

   EC supporte les opérations de signature, de vérification et de dérivation. La signature et vérification utilise ECDSA et la dérivation ECDH.

Exemples

Signer des données en utilisant une clé privée:
openssl pkeyutl -sign -in file -inkey key.pem -out sig
Récupérer des données signées:
openssl pkeyutl -verifyrecover -in sig -inkey key.pem
Vérifier la signature:
openssl pkeyutl -verify -in file -sigfile sig -inkey key.pem
Signer les données en utilisant un message digest:
openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256
Dériver une clé secrète partagée:
openssl pkeyutl -derive -inkey key.pem -peerkey pubkey.pem -out secret
^
19 février 2012

htmlpdflatexmanmd




OpenSSL - présentation

OpenSSL - présentation

Utilitaire cryptographique

   OpenSSL est un utilitaire cryptographique implémentant SSL v2/v3 et TLS v1 et les standards cryptographiques liés. Il permet de:

        - Crée des paramètres de clé RSA, DH et DSA
        - Créer des certificats X.509, CSR et CRL
        - Calculer les digests de messages
        - Crypter et décrypter avec chiffrement
        - Tests client/serveur SSL/TLS
        - Manipuler les mails signé ou chiffré S/MIME

Sommaire des commandes

list-standard-commands Affiche la liste des commandes standards
list-message-digest-commands Affiche la liste des commandes Digest standard
list-cipher-commands Affiche la liste des commandes de chiffrement standard
list-public-key-algorithms Liste les algorithmes de clé publique supportés.
no-‹commande› test si une commande est disponible. (Sort 0 si la commande existe, 1 sinon)

Commandes standards

asn1parse Parse une séquence ASN.1
ca Gestion de CA
ciphers Détermine le Cipher Suite Description
cms Utilitaire CMS
crl Gestion de CRL
crl2pkcs7 Conversion de CRL vers pkcs7
dgst Calcul de Message Digest
dh Gestion des paramètre Diffie Hellman
dhparam Génération et gestion des paramètres Diffie Hellman
dsa Gestion des données DSA
dsaparam Génération des paramètres DSA
ec Traitement de clé EC
ecparam Génération et manipulation de paramètres EC
enc Encodage avec Chiffrement
engine Information et manipulation du moteur
errstr Conversion des numéro d’erreur en message d’erreur
gendh Génération des paramètres Diffie Hellman
gendsa Génération des paramètres DSA
genrsa Génération des paramètres RSA
genpkey Génération des clés privée ou paramètres
nseq Créer ou examiner une séquence de certificat Netscape
ocsp Utilitaire pour le protocole Online Certificate Status
passwd Génération de hash de mot de passe
pkcs12 Gestion des données PKCS #12
pkcs7 Gestion des données PKCS #7
pkey Gestion de clé publique et privée
pkeyparam Gestion des paramètres d’algorithme de clé publique
pkeyutl Utilitaire pour les opérations cryptographique de clé publique
rand Génère des octets pseudo-aléatoire
req Gestion des CSR
rsa Gestion des données RSA
rsautil Utilitaire RSA pour signer, vérifier, chiffrer et déchiffrer
s_client Implémente un client générique SSL/TLS pour établir une connexion transparente à un serveur distant.
s_server Implémente un serveur SSL/TLS qui accepte les connections depuis des clients distant.
s_time Timer de connexion SSL
sess_id Gestion de données de session SSL
smime Traitement des mail S/MIME
speed Mesure de vitesse des algorithmes
spkac Utilitaire de génération et d’affichage SPKAC
ts Outil client/serveur d’autorité TimeStamping
verify Vérification de certificats X.509
version Information de version d’openssl
x509 Gestion des données des certificats x509

Commandes Digest Standards

md2 digest md2
md5 Digest md5
mdc2 digest mdc2
rmd160 digestion RMD-160
sha digest sha
sha1 digest sha-1
sha224 digest sha-224
sha256 digest sha-256
sha384 digest sha-384
sha512 digest sha-512

Commandes d’encodage et de chiffrement

base64 Encodage en base64
bf bf-cbc bf-cfb bf-ecb bf-ofb Chiffrement blowfish
cast cast-cbc Chiffrement CAST
cast5-cbc cast5-cfb cast5-ecb cast5-ofb Chiffrement CAST5
des des-cbc des-cfb des-ecb des-ede des-ebe-cbc des-ebe-cfb des-ebe-ofb des-ofb Chiffrement DES
des3 desx des-ede3 des-ede3-cdc des-ede3-cfb des-ede3-ofb Chiffrement TRIPLE-DES
idea idea-cbc idea-cfb idea-ecb idea-ofb Chiffrement IDEA
rc2 rc2-cbc rc2-ecb rc2-ofb Chiffrement RC2
rc4 Chiffrement rc4
rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb Chiffrement rc5

Arguments de pass-phrase

pass:password Le mot de passe actuel est password.
env:var Obtenir le mot de pass depuis la variable d’environnement var
file:pathname La première ligne du fichier est le mot de passe. Si ce même fichier est spécifié à -passin et -passout, la première ligne est pour l’entrée la ligne suivante est pour la sortie
fd:number Lit le mot de passe depuis le descripteur de fichier spécifié
stdin Lit le mot de passe depuis l’entrée standard
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - rand

OpenSSL - rand

Générateur pseudo-aléatoire

OPTIONS

-out file Spécifie le fichier à écrire
-rand file(s) Utilise le(s) fichier(s) pour le moteur de nombre aléatoire.
-base64 Effectue un encodage en base 64 sur la sortie
-hex Affiche la sortie en hexa.
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - req

OpenSSL - req

Utilitaire pour créer et traiter des requêtes pkcs#10

OPTIONS

-inform PEM|DER Format du fichier d’entrée
-outform PEM|DER Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie
-passout arg Source du mot de passe pour le fichier de sortie
-text Affiche la requête en clair
-subject Affiche le sujet de la requête
-pubkey Affiche la clé publique
-noout N’affiche pas la version encodée de la requête
-modulus Affiche le modulo de la clé publique contenue dans la requête
-verify Vérifie la signature de la requête
-new Génère une nouvelle requête de certificat.
-subj arg Remplace le champ sujet dans la requête d’entrée doit être au format /type0=value0/type1=value1/typeN=valueN...
-rand file(s) Fichier(s) contenant les données aléatoire pour le générateur de nombre aléatoire.
-newkey arg Crée une nouvelle requête de certificat et une nouvelle clé privée. arg peut être sous la forme rsa:nbits où nbits est la longueur de la clé RSA. Tous les autres algorithmes supportent la forme alg:file où file est un fichier de paramètre. param:file utilise le fichier de paramètre ou le certificat spécifié par file. L’algorithme est déterminé par les paramètres.
-pkeyopt opt:value Définie une options d’algorithme. (Voir genpkey)
-key filename Spécifie le fichier contenant la clé privée à lire. Accepte le format PKCS#8.
-keyform PEM-DER Le format du fichier de clé privée.
-keyout filename Nom du fichier où écrire la clé privée.
-nodes Si cette option est spécifiée, la clé privée créée n’est pas chiffrée
-[digest] Spécifie le message digest à utiliser pour signer la requête.
-multivalue-rdn Permet d’interpréter -subj au format RDN multi-valué (exemple : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe, sinon le format sera : 123456+CN=John Doe)
-x509 Sort un certificat auto-signé au lieu d’une requête de certificat.
-days -n avec -x509, spécifie la durée de validité du certificat (défaut : 30jours)
-set_serial n Définis le numéro de série du certificat auto-signé. Peut-être en décimal ou en hexa.
-extensions section
-reqexts section Spécifient les sections alternatives à inclure dans la requête.
-utf8 interprète les valeurs de champs au format UTF8
-nameopt option détermine comment le sujet et l’issuer sont affichés (voir x509)
-repopt Personnalise le format de sortie avec -text. l’argument peut être une simple options ou plusieurs, séparés par des ’,’ (voir x509)
-asn1-kludge Par défaut, req sort les requêtes de certificat ne contenant pas d’attributs dans le format PKCS#10 correct. Cependant, certaines CA acceptent uniquement les requêtes ne contenant pas d’attributs dans une forme invalide : cette options produit ce format invalide (les attributs dans une requête PKCS#10 sont définis comme un set d’attribut SET OF. Ils ne sont pas optionnels donc si aucun attribut n’est présent, il devrait être encodé comme un SET OF vide, une forme invalide ne contient pas ce SET OF vide)
-no-asn1-kludge Inverse l’effet de -asn1-kludge
-newhdr Ajoute le mot NEW dans l’en-tête et pied de page PEM.
-batch Mode non-interactif
-verbose Affiche les détails sur l’opération courante
-engine id req va tenter d’obtenir une référence fonctionnelle du moteur spécifié
-keygen_engine id Spécifie un moteur qui devrait être utilisé pour les opérations de génération de clé.

Format du fichier de configuration

input_password output_password Les mots de passe pour les fichier de clé privée d’entrée et de sortie (remplace passin et passout)
default_keyfile Taille en bits de la clé (défaut 512, remplace -newkey)
oid_file Spécifie un fichier contenant des OID additionnels. Chaque ligne consiste de l’oid suivi d’un espace blanc, suivi du nom cours, suivi par un blanc et suivi par un nom long.
oid_section Spécifie la section dans le fichier de configuration contenant les oid supplémentaires
RANDFILE Spécifie un nom de fichier contenant les données aléatoires à utiliser par le moteur de génération de nombres pseudo-aléatoires
encrypt_key à no, la clé privée n’est pas chiffrée. (Remplace -nodes)
default_md Spécifie l’algorithme digest à utiliser. (md5, sha1 ou mdc2, défaut : md5)
string_mask Masque l’utilisation de certaines chaines dans certains champs. default utilise PrintableStrings, T61Strings et BMPStrings.
pkix utilise PrintableStrings et BMPStrings. utf8only utilise UTF8Strings. nombstr utilise PrintableStrings et T61Strings.
req_extensions Spécifie la section du fichier de configuration contenant la liste des extensions à ajouter à une requête (remplace -reqexts)
x509_extensions Spécifie la section du fichier de configuration contenant un liste des extensions à ajouter au certificat généré avec -x509 (remplace -extensions)
prompt à no désactive la demande des champs du certificat et prend les valeurs dans le fichier de configuration
utf8 à yes les valeurs de champs sont interprétés en utf8 (ASCII par défaut)
attributes Spécifie la section contenant les attributs de requête. Identique à distinguished_name. Actuellement ignoré par OpenSSL.
distinguished_name Spécifie la section contenant les champs dn à demander pour générer un certificat ou une requête.

Format des sections Distinguished Name et Attribute

Il y’a 2 formats pour ces sections. Si l’option prompt est à no, ces sections consistent de noms de champs et de valeur. Par exemple:
CN=My Name
OU=My Organization
emailAddress=someone@somewhere.org

Si prompt est absent ou à yes, ces sections contiennent la liste des champs à demander:
fieldName="prompt"
fieldName_default="default field value"
fieldName_min= 2
fieldName_max= 4

fieldname est le nom d’un champs, par exemple commonName ou CN. "prompt" est utilisé pour demander à l’utilisateur d’entrer les informations du champ. Si l’utilisateur n’entre rien, ce champ est omis.
- Si une valeur par défaut est définie, elle sera utilisée si l’utilisateur n’entre rien. L’utilisateur peut outrepasser cette valeur par défaut en entrant le caractère '.'
- Les limites min et max peuvent être utilisé pour limiter les valeurs de champs. Par exemple, countryName peut seulement avoir 2 caractères et doivent être correspondre à un PrintableString
- Certains champs comme organizationName peuvent être utilisé plus d’une fois dans un DN. Un second organizationName peut être entré en l’appelant 1.organizationName
- Les noms de champs permis sont des noms cours ou long d’object identifier. Incluant : commonName, countryName, localityName, organizationName, organizationUnitName, stateOrProvinceName. emailAddress, name, surname, givenName, dnQualifier.
- Des object identifier additionnels peuvent être définis avec les options oid_file et oid_section dans le fichier de configuration. Ces champs additionnels seront traités comme si c’était un DirectoryString

Exemples

Examiner et vérifier une requête de certificat:
openssl req -in req.pem -text -verify -noout
Créer une clé privée et générer une requête de certificat:
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out req.pem
Idem en utilisant uniquement req:
openssl req -newkey rsa:1024 -keyout key.pem -out req.pem
Générer un certificat root auto-signé:
openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem
Exemple de fichier pointé par l’option oid_file:
1.2.3.4 shortName A longer Name
1.2.3.6 otherName Other longer Name
Exemple d’une section pointée par oid_section:
testoid1=1.2.3.5
testoid2=$testoid1.6

Exemple de fichier de configuration demandant les valeurs de champs


[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
    
dirstring_type = nobmp
    
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
    
localityName = Locality Name (eg, city)
    
organizationalUnitName = Organizational Unit Name (eg, section)
    
commonName = Common Name (eg, YOUR name)
commonName_max = 64
    
emailAddress = Email Address
emailAddress_max = 40
    
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
    
[ v3_ca ]
    
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

Exemple de configuration contenant toutes les valeurs de champs


RANDFILE = $ENV ::HOME/.rnd
    
[ req ]
default_bits = 1024
default_keyfile = keyfile.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
prompt = no
output_password = mypass
    
[ req_distinguished_name ]
C = GB
ST = Test State or Province
L = Test Locality
O = Organization Name
OU = Organizational Unit Name
CN = Common Name
emailAddress = test@email.address
    
[ req_attributes ]
challengePassword = A challenge password

Notes

Le format PEM inclus:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----

Certains logiciels comme Netscape certificate server nécessitent:
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----

Variables d'environnement

OPENSSL_CONF peut être utilisé comme emplacement de fichier de configuration alternatif.
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - rsa

OpenSSL - rsa

Traitement des clés rsa

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie où écrire la clé
-passout password source du mot de passe du fichier de sortie
-sgckey Utilisé pour l’algorithme modifié NET utilisé avec certaines versions de Microsoft IIS et les clé SGC.
-des|-des3|-idea Algorithme utilisé pour chiffrer la clé privée.
-text Affiche des infos sur les clés privée et publique
-noout N’affiche pas la version encodée de la clé
-modulus Affiche la valeur du modulo de la clé
-check Vérifie la consistance de la clé privée RSA
-pubin Lit une clé publique en entrée plutôt qu’une clé privée
-pubout Sort une clé publique plutôt qu’une clé privée
-engine id rsa va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM de la clé privée contient:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

la forme PEM de la clé publique contient:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

Exemples

Supprimer le passphrase d’une clé privée:
openssl rsa -in key.pem -out keyout.pem
Chiffrer une clé privée avec triple DES:
openssl rsa -in key.pem -des3 -out keyout.pem
Convertir une cléprivée PEM en DER:
openssl rsa -in key.pem -outform DER -out keyout.der
Afficher les composantes de la clé privée:
openssl rsa -in key.pem -text -noout
Afficher la partie publique de la clé privée:
openssl rsa -in key.pem -pubout -out pubkey.pem
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - rsautl

OpenSSL - rsautl

Utilitaire rsa

OPTIONS

-in filename Fichier d’entrée
-out filename Fichier de sortie
-inkey file Fichier de clé privée RSA en entrée
-pubin Le fichier d’entrée est une clé publique RSA
-certin L’entrée est un certificat contenant une clé publique RSA
-sign Signe la donnée en entrée et sort le résultat signé. requière une clé privée RSA
-verify Vérifie les données en entrée et sort les données récupérées
-encrypt Chiffre l’entrée en utilisant la clé publique RSA
-decrypt Déchiffre l’entrée en utilisant la clé privée RSA
-pkcs, -oeap, -ssl, -raw Le padding à utiliser (respectivement PKCS#1 v1.5, PKCS#1 OEAP, padding utilisé dans ssl v2, aucun padding). pour les signatures, seul -pkcs et -raw sont utilisé
-hexdump Dump en hexa les données en sortie
-asn1parse asn1parse la sortie. utile avec -verify

Notes

   rsautl utilise directement l’algorithme RSA, il ne peut être utlisé que pour de petites portions de données.

Exemples

Signer des données en utilisant une clé privée:
openssl rsautl -sign -in file -inkey key.pem -out sig
Récupérer les données signées:
openssl rsautl -verify -in sig -inkey key.pem
Examiner les données signées en raw:
openssl rsautl -verify -in file -inkey key.pem -raw -hexdump


0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0070 - ff ff ff ff 00 68 65 6c-6c 6f 20 77 6f 72 6c 64 .....hello world

   Ce block est formaté PKCS#1. çà été fait en utilisant encrypt puis en déchiffrant le block detype 2 (le 2eme octet) et un padding aléatoire visible à la place des octets 0xff. Il est possible d’analyser la signature des certificats en utilisant rsautl avec asn1parse.

En considérant un exemple auto-signé dans certs/pca-cert.pem:
openssl asn1parse -in pca-cert.pem


0:d=0 hl=4 l= 742 cons : SEQUENCE
4:d=1 hl=4 l= 591 cons : SEQUENCE
8:d=2 hl=2 l= 3 cons : cont [ 0 ]
10:d=3 hl=2 l= 1 prim : INTEGER :02
13:d=2 hl=2 l= 1 prim : INTEGER :00
16:d=2 hl=2 l= 13 cons : SEQUENCE
18:d=3 hl=2 l= 9 prim : OBJECT :md5WithRSAEncryption
29:d=3 hl=2 l= 0 prim : NULL
31:d=2 hl=2 l= 92 cons : SEQUENCE
33:d=3 hl=2 l= 11 cons : SET
35:d=4 hl=2 l= 9 cons : SEQUENCE
37:d=5 hl=2 l= 3 prim : OBJECT :countryName
42:d=5 hl=2 l= 2 prim : PRINTABLESTRING :AU
....
599:d=1 hl=2 l= 13 cons : SEQUENCE
601:d=2 hl=2 l= 9 prim : OBJECT :md5WithRSAEncryption
612:d=2 hl=2 l= 0 prim : NULL
614:d=1 hl=3 l= 129 prim : BIT STRING

Le BIT STRING final contient la signature actuelle, et peut être extrait avec:
openssl asn1parse -in pca-cert.pem -out sig -noout -strparse 614
La clé publique du certificat peut être extrait avec:
openssl x509 -in test/testx509.pem -pubkey -noout ›pubkey.pem
La signature peut être analysée avec:
openssl rsautl -in sig -verify -asn1parse -inkey pubkey.pem -pubin


0:d=0 hl=2 l= 32 cons : SEQUENCE
2:d=1 hl=2 l= 12 cons : SEQUENCE
4:d=2 hl=2 l= 8 prim : OBJECT :md5
14:d=2 hl=2 l= 0 prim : NULL
16:d=1 hl=2 l= 16 prim : OCTET STRING
0000 - f3 46 9e aa 1a 4a 73 c9-37 ea 93 00 48 25 08 b5 .F...Js.7...H%..

C’est la version parsée d’une structure ASN1 DigestInfo, ici avec un digest md5.
La partie du certificat qui a été signée peut être extraite avec:
openssl asn1parse -in pca-cert.pem -out tbs -noout -strparse 4
et son digest calculé avec:
openssl md5 -c tbs
MD5(tbs)= f3:46:9e:aa:1a:4a:73:c9:37:ea:93:00:48:25:08:b5
Qui peut être récupéré avec cette valeur.
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - sess_id

OpenSSL - sess_id

Utilitaire pour manipuler et afficher les ID de session SSL/TLS

OPTIONS

-inform DER|PEM Format d’entrée
-outform DER|PEM Format de sortie
-in filename Fichier d’entrée contenant les informations de session
-out filename Fichier de sortie où écrire les informations de session
-text Affiche les composante clé privée et publique en texte clair en plus de la version encodée
-cert Si un certificat est présent dans la session il sera sortie, si -text il sera affiché
-noout Ne sort pas la version encodée de la session
-context ID Spécifie l’id de session

Sortie


SSL-Session :
Protocol : TLSv1
Cipher : 0016
Session-ID : 871E62626C554CE95488823752CBD5F3673A3EF3DCE9C67BD916C809914B40ED
Session-ID-ctx : 01000000
Master-Key : A7CEFC571974BE02CAC305269DC59F76EA9F0B180CB6642697A68251F2D2BB57E51DBBB4C7885573192AE9AEE220FACD
Key-Arg : None
Start Time : 948459261
Timeout : 300 (sec)
Verify return code 0 (ok)

Détails

Protocol Protocole utilisé (TLSv1, SSLv2 ou SSLv3)
Cipher Chiffrement utilisé
Session-ID L’id de session en hexa
Session-ID-ctx Contexte de l’id de session en hexa
Master-Key Clé maître de session SSL
Key-Arg Argument clé, utilisé en SSLv2
Start Time Heure de début de la session au format Unix standard
Timeout timeout en secondes
Verify return code code de retour quand le certificat client est vérifié

Notes

La version PEM du fichier de session utilise:
-----BEGIN SSL SESSION PARAMETERS-----
-----END SSL SESSION PARAMETERS-----

^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - smime

OpenSSL - smime

Utilitaire smime

OPTIONS

-encrypt Chiffrer un mail.
-decrypt Déchiffrer un mail
-sign Signer un mail
-verify Vérifier un mail signé
-pk7out Prend un message et le sort sous forme d’une structure PKCS#7 PEM
-resign Resigne un message
-in filename Ficher d’entrée
-inform SMIME|PEM-DER Format du fichier d’entrée
-out filename Fichier de sortie
-outform SMIME|PEM|DER Format du fichier de sortie
-stream -indef sont équivalent et activent le streaming I/O pour les opérations d’encodage. Permet de traiter en une seule passe sans maintenir toutes les données en mémoire.
-noindef Désactive le streaming I/O
-content filename Ficher contenant le contenu détaché. Utilisable si la structure PKCS#7 utilise la signature détachée, où le contenu n’est pas inclus.
-text Ajoute les en-têtes MIME en texte clair.
-CAfile file Fichier contenant la chaînes des certificats à truster, utilisé avec -verify
-CApath dir Répertoire contenant les certificats CA en ’hash form’
-md digest Algorithme de digest à utiliser pour signer ou resigner. (Défaut SHA1)
-[cipher] Algorithme de chiffrement à utiliser (défaut RC2 40bits)
-nointern Normalement lors de la vérification d’un message, les certificats inclus dans le message sont recherché pour valider la signature. Cette options utilise ceux spécifié avec -certfile.
-noverify Ne pas vérifier le certificat du signataire d’un message signé
-nochain Ne pas vérifier la chaîne de certificats des signataires.
-nosigs Ne tente pas de vérifier les signatures dans le message
-nocerts En signant un message, le certificat du signataire est normalement inclus. Cette option ne l’inclus pas.
-noattr Normalement un message signé inclus des attributs dont la date de signature et les algorithmes symmétriques supportés. Cette option ne les inclus pas.
-binary Normalement le message est convertit au format canonique utilisant CR et LF comme fin de ligne comme requis dans la spécification S/MIME. Avec cette option, aucune traduction n’est faite.
-nodetach En signant un message avec une signature opaque, plus résistant aux traductions par relais mais ne peuvent pas être lus pas des MTA qui ne supportent pas S/MIME. Avec cette option, aucune traduction n’est faite.
-certfile file Certificats PEM additionnels à inclure avec le message.
-signer file Certificats des signataires si un message est vérifié avec succès, ces certificats seront écris dans le fichier.
-recip file Certificat pour déchiffrer un message. Doit matcher un des bénéficiaires du message.
-inkey file La clé privée à utiliser pour signer ou déchiffrer. Peut être spécifié plusieurs fois.
-passin arg Source du mot de passe de la clé privée.
-rand file(s) fichier(s) contenant les données pour le générateur de nombre aléatoire.
cert.pem Un ou plusieurs certificats utilisés pour chiffrer un message
-to, -from, -subject Champs d’en-tête du mail
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check,
-extended_crl, -x509_strict, -policy -check_ss_sig Diverses options de vérification de chaîne de certificat. voir verify

Notes

   Cette version ne permet qu’un seul signataire, mais permet de vérifier des messages contenant plusieurs signataires.

Codes de sortie

0 succès de l’opération
1 Une erreur s’est produite en parsant les options
2 Un des fichiers en entrée ne peut être lu
3 Une erreur s’est produite en créant un fichier PKCS #7 ou en lisant un message SMIME
4 Une erreur s’est produite en déchiffrant ou en vérifiant le message
5 Le message a été vérifié correctement mais une erreur s’est produite en écrivant les certificats des signataires

Exemples

Créer un message signé en texte clair:
openssl smime -sign -in message.txt -text -out mail.msg -signer mycert.pem
Créer un message signé opaque:
openssl smime -sign -in message.txt -text -out mail.msg -nodetach -signer mycert.pem
Créer un message signé, incluant des certificats additionnels et en lisant la clé privée depuis un autre fichier:
openssl smime -sign -in in.txt -text -out mail.msg -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
Créer un message signé par 2 signataires:
openssl smime -sign -in message.txt -text -out mail.msg -signer mycert.pem -signer othercert.pem
Envoyer un message signé à sendmail, incluant des en-têtes:
openssl smime -sign -in in.txt -text -signer mycert.pem -from steve@openssl.org -to someone@somewhere -subject "Signed message" | sendmail someone@somewhere
Vérifier un message et extraire le certificat du signataire:
openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt
Envoyer un message chiffré avec 3DES:
openssl smime -encrypt -in in.txt -from steve@openssl.org -to someone@somewhere -subject "Encrypted message" -des3 user.pem -out mail.msg
Signer et chiffrer un mail:
openssl smime -sign -in ml.txt -signer my.pem -text | openssl smime -encrypt -out mail.msg -from steve@openssl.org -to someone@somewhere -subject "Signed and Encrypted message" -des3 user.pem
Déchiffrer un mail:
openssl smime -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
Créer un message chiffrer avec Camellia 128bits:
openssl smime -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
Ajouter un signataire à un message:
openssl smime -resign -in mail.msg -signer newsign.pem -out mail2.msg
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - speed

OpenSSL - speed

Test de performances des algorithmes

OPTIONS

-engine id speed va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
[0 ou plusieurs algorithmes] si aucun algorithme n’est spécifié, test tous les algorithmes disponibles.
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - spkac

OpenSSL - spkac

Utilitaire d’affichage et de génération SPKAC (Signed Public Key And Challenge)

OPTIONS

-in filename Fichier en entrée
-out filename Fichier de sortie
key keyfile Crée un fichier SPKAC en utilisant la clé privée spécifiée -in, -noout, -spksect et -verify seront ignorés
-passin password Source du mot de passe du fichier d’entrée
-challenge string challenge si un SPKAC est créé.
-spkac spkacname Permet une forme alternative de la variable contenant le SPKAC. (Défaut : SPKAC)
-spksect section Spécifie une forme alternative de la section contenant le SPKAC.
-noout N’affiche pas la version texte du SPKAC
-pubkey Affiche la clé publique d’un SPKAC
-verify Vérifie la signature du SPKAC fournis
-engine id spkac va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Exemples

Afficher le contenu d’un SPKAC:
openssl spkac -in spkac.cnf
Vérifier la signature d’un SPKAC:
openssl spkac -in spkac.cnf -noout -verify
Créer un SPKAC en utilisant le challenge 'hello':
openssl spkac -key key.pem -challenge hello -out spkac.cnf
Exemple d’un SPKAC:
SPKAC=MIG5MGUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA1cCoq2Wa3Ixs47uI7FPVwHVIPDx5yso105Y6zpozam135a
8R0CpoRvkkigIyXfcCjiVi5oWk+6FfPaD03uPFoQIDAQABFgVoZWxsbzANBgkqhkiG9w0BAQQFAANBAFpQtY/FojdwkJ
h1bEIYuc2EeM2KHTWPEepWYeawvHD0gQ3DngSC75YCWnnDdq+NQ3F+X4deMx9AaEglZtULwV4=
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - s_client

OpenSSL - s_client

Programme client SSL/TLS qui peut se connecter à un hôte distant en utilisant SSL/TLS. Utilitaire de diagnostique très utile

OPTIONS

-connect host:port Hôte et port distant (défaut : localhost:4433)
-cert certname Le certificat à utiliser (défaut : n’utilise pas de certificat)
-certform format Format du certificat, DER ou PEM
-key keyfile La clé privée à utiliser
-keyform format Le format de la clé privée, DER ou PEM
-pass arg Source du mot de passe de la clé privée
-verify depth Active la vérification du certificat du serveur et spécifie la longueur max de la chaine de certificat du serveur
-CApath directory Répertoire à utiliser pour la vérification du certificat du serveur. doit être un ’hash format’
-CAfile file Fichier contenant les certificats à truster
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all,
-policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig Définir divers options de validation de la chaîne de certificat (voir verify)
-reconnect Se reconnecte au même serveur 5 fois avec le même session ID, utile pour tester le cache de session.
-pause effectue une pause d’une seconde entre chaque appel de lecture et d’écriture
-showcerts Affiche la chaîne entière de certificat (défaut : seul le certificat du serveur est affiché)
-prexit Affiche les informations de session quand le programme quitte.
-state Affiche les statistiques de session SSL
-debug Affiche des informations additionnelles, incluant un dump hexa de tout le traffic
-msg Affiche tous les messages de protocole avec un dump hexa
-nbio_test Tests IO non bloquant
-nbio Active l’I/O non bloquant
-crlf Traduit un line feed depuis le terminal en CR+LF
-ign_eof Inhibe la fin de connection quand la fon du fichier est atteind
-quiet N’affiche pas d’information de session et des certificats. active implicitement -ign_oef
-psk_identity identity Utilise l’identité PSK lors de l’utilisation de la suite de chiffrement PSK
-psk key Sépcifie la clé PSK lors de l’utilisation de la suite de chiffrement PSK. La clé est donnée en nombre hexa sans le 0x, par exemple : -psk 1a2b3c4d
-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1 Désactive l’utilisation de certains protocoles SSL ou TLS. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveur et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-cipher cipherlist Permet d’envoyer la liste des chiffrements à modifier. Le serveur détermine quelle suite est utilisée et devrait prendre la première supportée dans la liste.
-starttls protocol Envoie les messages spécifique au protocole pour passer en TLS pour les communications. le protocole est un mot clé pour le protocole (smtp, pop3, imap et ftp)
-tlsextdebug Affiche un dump hexa des extensions TLS reçues du serveur
-no_ticket Désactive le support de ticket de session RFC4507bis
-sess_out filename sort la session SSL dans le fichier
-sess_in sess.pem Charge la session SSL depuis le fichier. Le client va tenter de résumer une connection depuis cette session.
-engin id s_client va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
-rand file(s) Le(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.

Exemples

se connecter à un serveur SSL distant:
openssl s_client -connect servername:443
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - s_server

OpenSSL - s_server

Serveur SSL/TLS

OPTIONS

-accept port Port TCP d’écoute (défaut : 4433)
-context id ID de Context SSL. Peut être une valeur chaîne.
-cert certname Certificat à utiliser.
-certform PEM|DER Format du certificat
-key keyfile Clé privée à utiliser
-keyform PEM|DER Format de la clé privée
-pass arg Source du mot de passe de la clé privée
-dcert filename, -dkey keyname Certificat et clé privée additionnel
-dcertform format, -dkeyform format, -dpass arg Le format du certificat et de la clé privée supplémentaire, et la source du mot de passe.
-nocert Ne pas utiliser de certificat. Restreint la suite de chiffrements à anonymous DH.
-dhparam filename Fichier de paramètres DH à utiliser
-no_dhe Ne charge aucun paramètre DH et désactive les suites de chiffrement ephemeral DH.
-no_tmp_rsa Pour les suites utilisant une clé RSA temporaire, désactive la génération d’une telle clé.
-verify depth, -Verify depth Spécifie la longueur max de la chaîne de certificat client et force le serveur à demander le certificat du client. -verifie, le client n’a pas à fournir de certificat, -Verify l’oblige.
-crl_check, -crl_check_all Vérifie la CRL. Les crl sont ajoutés au fichier de certificat.
-CApath directory Répertoire contenant les certificats de la CA au ’hash format’
-CAfile file Un fichier contenant les certificats de confiance
-state Affiche l’état de session SSL
-debug Affiche des informations de débogage incluant un dump hexa de tout le trafic
-msg Affiche tous les messages de protocoles avec dump hexa
-nbio_test Tests IO non bloquant
-nbio Active l’I/O non bloquant
-crlf Traduit un line feed depuis le terminal en CR+LF
-quiet Inhibe l’affichage de session et des informations de certificat
-psk_hint hint Utilise l’identité PSK en utilisant la suite de chiffrement PSK.
-psk key Utilise la clé PSK spécifié. La clé est donnée en hexa sans 0x, exemple : 1a2b3c4d
-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1 Désactive l’utilisation de certains protocoles SSL ou TLS. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-hack Active une solution de contournement pour certaines anciennes versions de Netscape SSL.
-cipher cipherlist Permet de modifier la liste des chiffrements utilisés par le serveur.
-tlsextdebug Affiche un dump hexa des extensions TLS reçue
-no_ticket Désactive le support de ticket de session RFC4507bis
-www Envoie un message de statut au client quand il se connecte. Inclus beaucoup d’informations sur les chiffrements utilisé et divers paramètres de session, la sortie est au format HTML.
-WWW Emule un serveur web simple. Les pages chargées sont relatives au répertoire courant. (Ex : https://myhost/page.html charge ./page.html)
-HTTP idem, mais les pages chargée contiennent une réponse HTTP complète et correcte.
-engine id s_server va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
-id_prefix arg Génère un ID de session SSL/TLS préfixé par arg.
-rand file(s) Le(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.

Commandes connectées

   Si une connexion est établie avec un client SSL et ni -www ni -WWW n’est utilisé, les données du client sont affichées et l’appuie sur une touche sera envoyé au client:

q Termine la connexion SSL courante, mais accepte les nouvelles connections
Q Termine la connexion SSL courante et quitte.
r Renégocie la session SSL
R Renégocie la session SSL et demande un certificat client
P Envoie un texte en clair à la connexion TCP : devrait forcer le client à se déconnecter dû à une violation de protocole.
S Affiche les informations de statut du cache de session

Notes

s_server peut être utilisé pour débugger les clients SSL. Pour accepter les connections depuis un navigateur web:
openssl s_server -accept 443 -www
Beaucoup de navigateurs ne supportent que les suites de chiffrement RSA. Les paramètres de session peuvent être imprimés avec sess_id.
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - s_time

OpenSSL - s_time

Programme de test de performance SSL/TLS

OPTIONS

-connect host:port Spécifie l’hôte:port distant
-www page Spécifie la page à GET. Sans cette options, s_time effectue simplement un handshake pour établir la connexion SSL, mais ne transfère pas de données payload.
-cert certname Certificat à utiliser (PEM)
-key keyfile Clé privée à utiliser
-verify depth Active la vérification du certificat du serveur et spécifie la longueur max de la chaine de certificat du serveur
-CApath directory Répertoire à utiliser pour la vérification du certificat du serveur. doit être un ’hash format’
-CAfile file Fichier contenant les certificats à truster
-new Effectue un test de temps en utilisant un nouvel ID de session pour chaque connexion.
-reuse Effectue un test de temps en utilisant le même ID de session.
-nbio Active l’I/O non bloquant
-ssl2, -ssl3 Désactive l’utilisation de certains protocoles SSL. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-cipher cipherlist Permet d’envoyer la liste des chiffrements à modifier. Le serveur détermine quelle suite est utilisée et devrait prendre la première supportée dans la liste.
-time length Spécifie le temps en second que s_time devrait mettre pour établir les connections et optionnellement transférer les données payload du serveur.

Notes

s_time peut être utilisé pour mesurer les performances d’une connexion SSL. Pour se connecter à un serveur SSL HTTP et obtenir la page par défaut:
openssl s_time -connect servername:443 -www / -CApath yourdir -CAfile yourfile.pem -cipher commoncipher [-ssl3]
^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - ts

OpenSSL - ts

Outil de Time Stamping Authority (TSA) client/serveur

   ts est un outil de base TSA client/serveur comme spécifié dans la RFC3161. Un TSA peut être une partie d’une PKI et son rôle est de fournir une preuve à long terme de l’existence d’un horodatage avant une date particulière. Brève description du protocole:

        1. Le client TSA calcule un hash 'one-way' pour un fichier de données et l’envoie au TSA.
        2. Le TSA attache la date et l’heure courante au hash reçu, signe le tout et renvoie ce token au client.
        3. Le client TSA reçoit le token et vérifie la signature. Il vérifie également si le token contient le même hash qu’il avait envoyé au TSA.

Génération de requête et Time Stamp

-query Permet de générer une requête avec les options suivantes:

        -rand file:file... Fichier contenant les données pour le générateur pseudo-aléatoire, plusieurs fichiers peuvent être utilisés
        -config configfile Fichier de configuration à utiliser. Seul la section OID est utilisée (remplace la variable OPENSSL_CONF)
        -data file_to_hash Fichier de donnée pour lequel la requête doit être crée.
        -digest digest_bytes Permet de spécifier l’empreinte du message sans le fichier de donnée, au format hexadécimal
        -md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|... Message digest à appliquer au fichier de données
        -policy object_id Stratégie que le client s’attend à ce que le TSA utilise pour créer le time stamp. Sous forme OID numérique ou nom IOD.
        -no_nonce Aucun nonce n’est utilisé, sinon un nombre pseudo-aléatoire 64 bits est inclus dans la requête. nonce est recommandé.
        -cert Le TSA doit inclure son certificat de signature dans la réponse
        -in request.tsq Spécifie une précédente requête time stamp en DER à afficher en sortie
        -out request.tsq Nom du fichier de sortie pour écrire la requête.
        -text Affiche la sortie compréhensible au lieu du DER.

Génération d'une réponse Time Stamp

-reply Créer une réponse time stamp, incluant le status de la réponse et le token lui-même, avec les options suivantes:

        -config configfile Fichier de configuration à utiliser. (remplace la variableOPENSSL_CONF)
        -section tsa_section Nom de la section contenant les paramètres pour la génération de la réponse
        -queryfile request.tsq Nom du fichier contenant la requête timestamp encodée en DER
        -passin password_src Source du mot de passe pour la clé provée du TSA
        -signer tsa_cert.pem Certificat du signataire du TSA au format PEM. Doit avoir eactement un extension d’utilisation de clé ’timeStamping’ et doit être critique
        -inkey private.pem clé privée du signataire du TSA au format PEM
        -chain certs_file.pem Certification au format PEM à inclure dans la répnose en plus du certificat u signataire
        -policy object_id Stratégie par défaut à utiliser pour la réponse à moins que le client en demande une. (nom ou OID)
        -in response.tsr Spécifie une réponse timestamp créé précédemment ou un tocken timestamp au format DER qui sera écrit dns le fichier de sortie. Ne requière pas de requête. Permet d’examiner le contenu d’une réponse
        -token_in avec -in, indique que l’entrée est un otken timestamp DER (ContentInfo) au lieu d’une réponse (TimeStampResp)
        -out response.tsr Fichier de sortie
        -token_out La sortie est un timestamp token (ContentInfo) au lieu d’une réponse (TimeStampResp)
        -text Sort au format human-readable au lieu d’un DER
        -engine id ts va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Vérification de réponse Time Stamp

-verify permet de vérifier une réponse ou un jeton, il accèpte les options suivante:

        -data file_to_hash La réponse ou le token doit être vérifié avec. Ce fihcier est hashé avec le message digest spécifié dans le token.
        -digest digest_bytes La réponse ou le token doit être vérifié avec le message digest
        -queryfile request.tsq La requête originale en DER
        -in response.tsr La réponse qui doit être vérifiée au format DER
        -token_in avec -in, indique que l’entrée est un token DER (ContentInfo) au lie d’une réponse (TimeStampResp)
        -CApath trusted_cert_path Répertoire contenant Les certificats de CA du client
        -CAfile trusted_certs.pem Le nom du fichier contenant un jeu de certificats PEM de ca
        -untrusted cert_file.pem Définis des certificats non-trustés PEM qui peuvent être nécessaire pour créer une chaîne de certificat

Options de configuration

tsa section, default_tsa Section principale. Spécifie le nom d’une autre section qui contient toutes les autres options pour la commande -reply
oid_file voir ca
oid_section voir ca
RANDFILE voir ca
serial Voir le nom du fichier qui contient le numéro de série héxa de la dernière réponse timestamp. il est incréménté de 1
crypto_device Moteur openssl par défaut pour tous les algorithmes disponibles
signer_cert PEM certificat de signature TSA (idem à -signer)
certs Fichier contenant les certificats PEM à inclure dans la réponse (idem à -chain)
signer_key Clé privée du TSA en PEM
default_policy Stratégie par défaut (idem à -policy)
other_policies Liste de stratégies accèptés par le TSA
digests Liste des algorithmes de messages digest accéptès par le TSA
accuracy Source de précision du temps de TSA en secondes, millisecondes et microsecondes
clock_precision_digits Nombre maximum de chiffre représentant la fraction de secondes à inclure dans le champs time (max : 6)
ordering à yes, la réponse générée par ce TSA peut toujour être ordonnée, même si la différence de temps entre 2 réponses est inférieurs à la précision du temps
tsa_name à yes, le sujet du TSA doit est inclus dans le champs name de la réponse
ess_cert_id_chain les objets SignedData créés par le TSA contiennent toujours l’id du certificat du signataire dans l’attribut signed (RC2634)

Exemples

Créé une requêtes pour design.txt avec SHA-1 sans nonce ni stratégie ni certificat dans la réponse:
openssl ts -query -data design1.txt -no_nonce -out design1.tsq
Similaire en spécifiant le digest:
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b -no_nonce -out design1.tsq
Afficher le contenu des requêtes précédentes:
openssl ts -query -in design1.tsq -text
Créer une requête qui inclus MD5 de design2.txt, le certificat du signataire et nonce et spécifie la stratégie:
openssl ts -query -data design2.txt -md5 -policy tsa_policy1 -cert -out design2.tsq
Créer une réponse:
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem -signer tsacert.pem -out design1.tsr
idem en utilisant les paramètres dans un fichierde configuration:
openssl ts -reply -queryfile design1.tsq -out design1.tsr
Afficher la réponse:
openssl ts -reply -in design1.tsr -text
Créer un token:
openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
Afficher un token
openssl ts -reply -in design1_token.der -token_in -text -token_out
Extraire le token d’un réponse:
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
Ajouter le status ’granted à un token en crént une réponse valide:
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
Vérifier une réponse avec la requête:
openssl ts -verify -queryfile design1.tsq -in design1.tsr -CAfile cacert.pem -untrusted tsacert.pem
Vérifier une réponse qui inclus la chaîne de certificat:
openssl ts -verify -queryfile design2.tsq -in design2.tsr -CAfile cacert.pem
Pour vérifier un token avec le fichier originel:
openssl ts -verify -data design2.txt -in design2.tsr -CAfile cacert.pem
Pour vérifier un token avec une empreinte:
openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b -in design2.tsr -CAfile cacert.pem
^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - verify

OpenSSL - verify

Vérifier les chaînes de certificat

OPTIONS

-CApath directory Répertoire des certificats de confiance
-CAfile file Fichier de certificats de confiance
-untrusted file Fichiers de certificats non trustés
-purpose purpose Utilisation du certificat
-verbose mode verbeux
-issuer_checks Affiche des info liés à la recherche du certifieurs.
-policy arg Active le traitement de stratégie et ajoute ’arg’ au user-initial-policy-set (RFC5280)
-policy_check Active le traitement de stratégie de certificat
-explicit_policy définis require-explicite-policy (RFC5280)
-inhibit_any définis inhibit-any-policy (see RFC5280)
-inhibit_map définis inhibit-policy-mapping (see RFC5280)
-policy_print Affiche des info sur le traitement des tratégies
-crl_check Vérifie la crl
-crl_check_all Vérifie la validité de toute la chaîne de certificat
-ignore_critical Ignore les extension critique non gérées
-x509_strict mode strict X.509 compliance
-extended_crl Active les fonctionnalités étendues de CRL
-use_deltas Active le support des CRL delta
-check_ss_sig Vérifie la signature du root CA
indique la dernière option, les arguments suivants sont des certificats
certificates Un ou plusieurs certificats à vérifier

Opérations de vérification

   verify utilise les même fonctions que la vérification SSL et S/MIME. La différence entre verify et les opérations de vérification est que verify peut passer les erreurs et de continuer les opérations de vérifications.

Diagnostique

Quand une opération échoue, un message d’erreur est affiché du type:
server.pem: /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024 bit)
error 24 at 1 depth lookup:invalid CA certificate

La première ligne contient le nom du certificat qui a été vérifié, suivi du sujet.
La seconde ligne contient le numéro d’erreur est une courte description de l’erreur


0 X509_V_OK : ok
2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT : unable to get issuer certificate
3 X509_V_ERR_UNABLE_TO_GET_CRL : unable to get certificate CRL
4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE : unable to decrypt certificate’s signature
5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE : unable to decrypt CRL’s signature
6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY : unable to decode issuer public key
7 X509_V_ERR_CERT_SIGNATURE_FAILURE : certificate signature failure
8 X509_V_ERR_CRL_SIGNATURE_FAILURE : CRL signature failure
9 X509_V_ERR_CERT_NOT_YET_VALID : certificate is not yet valid
10 X509_V_ERR_CERT_HAS_EXPIRED : certificate has expired
11 X509_V_ERR_CRL_NOT_YET_VALID : CRL is not yet valid
12 X509_V_ERR_CRL_HAS_EXPIRED : CRL has expired
13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD : format error in certificate’s notBefore field
14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD : format error in certificate’s notAfter field
15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD : format error in CRL’s lastUpdate field
16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD : format error in CRL’s nextUpdate field
17 X509_V_ERR_OUT_OF_MEM : out of memory
18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT : self signed certificate
19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN : self signed certificate in certificate chain
20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY : unable to get local issuer certificate
21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE : unable to verify the first certificate
22 X509_V_ERR_CERT_CHAIN_TOO_LONG : certificate chain too long
23 X509_V_ERR_CERT_REVOKED : certificate revoked
24 X509_V_ERR_INVALID_CA : invalid CA certificate
25 X509_V_ERR_PATH_LENGTH_EXCEEDED : path length constraint exceeded
26 X509_V_ERR_INVALID_PURPOSE : unsupported certificate purpose
27 X509_V_ERR_CERT_UNTRUSTED : certificate not trusted
28 X509_V_ERR_CERT_REJECTED : certificate rejected
29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH : subject issuer mismatch
30 X509_V_ERR_AKID_SKID_MISMATCH : authority and subject key identifier mismatch
31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH : authority and issuer serial number mismatch
32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN:key usage does not include certificate signing
50 X509_V_ERR_APPLICATION_VERIFICATION : application verification failure

^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - version

OpenSSL - version

Affiche les informations de version d’openssl

OPTIONS

-a Toutes les informations
-v Version courante d’openssl
-b La date de buid de la version courante
-o Information optionnelles
-c Flags de compilation
-p Paramètre de plateforme
-d Paramètre OPENSSLDIR
^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - x509

OpenSSL - x509

Utilitaire de manipulation de certificat

OPTIONS

-inform DER|PEM|NET Format du fichier x509 en entrée
-outform DER|PEM|NET Format du fichier en sortie
-in filename Fichier en entrée
-out filename Fichier de sortie
-md2|-md5|-sha1|-mdc2 Message digest à utiliser
-engine id x509 va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Options d'affichage

-text Affiche le certificat au format texte.
-certopt option Personnalise la sortie utilisée avec -text liste d’options à afficher. Peut être spécifié plusieurs fois
-noout N’affiche pas la version encodée de la requête
-pubkey Affiche le block SubjectPublicKeyInfo du certificat au format PEM
-modulus Affiche la valeur du modulo de la clé publique contenue dans le certificat
-serial Affiche le numéro de série du certificat
-subject_hash Affiche le hash du nom du certificat
-issuer_hash Affiche le hash de l’issuer du certificat
-hash idem à -subject_hash
-subject_hash_old Affiche le hash du nom du certificat en utilisant l’ancien algorithme pré v1
-issuer_hash_old Affiche le hash de l’issuer du certificat en utilisant l’ancien algorithme pré v1
-subject Affiche le sujet
-issuer Affiche le fournisseur
-nameopt option Détermine comment le sujet et l’issuer sont affichés (voir options de nom)
-email Affiche les adresses email
-ocsp_uri Affiche les adresses de répondeur OCSP
-startdate Affiche la date de début de validité du certificat
-enddate Affiche la date de fin de validité du certificat
-dates Affiche la date de début et d’expiration du certificat
-fingerprint Affiche le digest de la version encodé DER du certificat
-C Affiche le certificat sous la forme d’un source C

Paramètres de confiance

-trustout Sort un certifcat de confiance.
-setalias arg Définis l’alias du certificat
-alias Affiche l’alias du certificat, s’il existe
-clrtrust Efface toutes les utilisations de confiance et permises du certificat
-clrreject Efface toutes les utilisations rejetée ou interdites du certificat
-addtrust arg Ajoute une utilisation de certifiaction de confiance. (clientAuth, serverAuth, emailProtection)
-addreject arg Ajoute une utilisation interdite. Accèpte lesmême valeurs que -addtrust
-purpose Effectue des tests sur les extensions du certificat et affiche le résultat (voir les extensions de certificat)

Options de signature

-signkey filename Signe le fichier en entrée avec la clé privée spécifiée. Si l’entrée est une requête de certificat, génère un certificat auto-signé
-clrext Supprime des extensions d’un certificat
-keyform PEM|DER Format de la clé privée
-days arg Spécifie le nombre de jours pour créer une validité pour le certificat
-x509toreq Convertit un certificat en une requête
-req L’entrée est une requete au lieu d’un certificat
-set_serial n Numéro de série à utiliser en décimal ou hexa
-CA filename Certificat de la CA à utiliser pour signer le certificat
-CAkey filename Clé privée de la CA
-CAserial filename Définis le fichier de numéro de série à utiliser
-CAcreateserial Créé le fichier de numéro de série s’il n’existe pas
-extfile filename Fichier contenant les extensions à utiliser
-extensions section Section où se trouvent les extensions à ajouter

Options de nommage

compat Utiliser l’ancien formats, équivalent à ne spécifier aucune option de nommage
RFC2253 Affiche les noms compatibles avec la rfc2253 equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_unknown, dump_der, sep_comma_plus, dn_rev et sname
oneline Format oneline, plus lisible que rfc2253. equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_space, space_eq et sname
multiline Format multiligne. équivalent à spécifier: esc_ctrl, esc_msb, sep_multiline, space_eq, lname et align.
esc_2253 Échappe les caractères spéciaux (,+"‹› ;#) requis par la rfc2253
esc_ctrl Échappe les caractères de contrôle d’échappement
esc_msb Echappe les caractères avec le MSB mis, c’est à dire les valeurs ASCII › 127
use_quote Échappe certains caractères en les plaçant entre "" au lieu de \
utf8 Convertit toutes les chaînes en UTF8
no_type Ne tente pas d’interpréter les caractères multi-octets
show_type Affiche le type de chaîne caractère ASN1
dump_der Dump en encodé DER les champs qui doivent être dumpé en hexa
dump_nostr Dump les types de chaînes non caractères
dump_all Dump tous les champs
dump_unknown Dump les champs dont l’OID n’est pas reconnus par openssl
sep_comma_plus
sep_comma_plus_space
sep_semi_plus_space
sep_multiline Déterminent les séparateurs de champs
dn_rev Renverse les champs d’un DN
nofname
sname
lname
oid Altère la manière dont le nom des champs est affiché
align Aligne les valeurs de champs
space_eq Met des espace autour du caractère ’=’

Options de texte

compatible Utiliser l’ancien formats, équivalent à ne spécifier aucune option de sortie
no_header N’affiche pas les en-têtes
no_version N’affiche pas le numéro de version
no_serial N’affiche pas le numéro de série
no_signame N’affiche pas l’algorithme de signature utilisé
no_validity N’affiche pas la validité
no_subject N’affiche pas le sujet
no_issuer N’affiche pas l’issuer
no_pubkey N’affiche pas la clé publique
no_sigdump Ne dump par la signature du certificat
no_aux N’affiche pas les informations de trust du certificat
no_extensions N’affiche pas les extensions X509v3
ext_default Tente d’afficher les extensions de certificat non supportés
ext_error Affiche une erreur pour les extensions de certificat non supportés
ext_parse Parse en ASN1 les extensions non supportés
ext_dump Dumps en hexa les extensions non supportés
ca_default Valeur utilisé par l’utilitaire ca. equivalent à o_issuer, no_pubkey, no_header, no_version, no_sigdump et no_signame

Exemples

Afficher le contenu d’un certificat:
openssl x509 -in cert.pem -noout -text
Afficher le numérode série d’un certificat:
openssl x509 -in cert.pem -noout -serial
Affiche le sujet d’un certificat:
openssl x509 -in cert.pem -noout -subject
Afficher le sujet du certificat sous la forme RFC2253:
openssl x509 -in cert.pem -noout -subject -nameopt RFC2253
Afficher le sujet du certificat en une ligne et en utf8:
openssl x509 -in cert.pem -noout -subject -nameopt oneline,-esc_msb
Affiche l’empreinte MD5 du certificat:
openssl x509 -in cert.pem -noout -fingerprint
Affiche l’empreinte SHA1 du certificat:
openssl x509 -sha1 -in cert.pem -noout -fingerprint
Convertir un certificat PEM en DER:
openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
Convertit un certificat en requête:
openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem
Convertit une requête en un certificat auto-signé utilisant des extensions:
openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions v3_ca -signkey key.pem -out cacert.pem
Signer une requête en utilisant le certificat d’un CA et en ajoutant des extensions utilisateur:
openssl x509 -req -in req.pem -extfile openssl.cnf -extensions v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial
Définis un certificat à truster pour un client SSL et changer son alias en "Steve’s Class 1 CA":
openssl x509 -in cert.pem -addtrust clientAuth -setalias "Steve’s Class 1 CA" -out trust.pem

Notes

Le format PEM utilise les élements suivants:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

ou:
-----BEGIN X509 CERTIFICATE-----
-----END X509 CERTIFICATE-----

Les certificats trustés auronts les lignes:
-----BEGIN TRUSTED CERTIFICATE-----
-----END TRUSTED CERTIFICATE-----

Extensions de certificat

   l’option -purpose vérifie les extensions de certificat et détermine l’utilisation du certificat.

basicContraints (Bool)Cette extension est utilisé pour déterminer si le certificat peut être utilisé comme CA.
keyUsage Cette extension contient des restrictions sur l’utilisation du certificat. Un certificat CA doit avoir le but keyCertSign mis si cette extension est présente.

Description de chaque tests

SSL Client L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication. keyUsage doit être absent ou avoir le bit digitalSignature mis.
SSL Client CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication.
SSL Server L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC. keyUsage doit être absent ou avoir le bit digitalSignature et/ou keyEncipherment mis.
SSL Server CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC.
Netscape SSL Server Pour que les clients Netscape se connectent à un serveur SSL il doitavoir le bit keyEncipherment mis si keyUsage est présent
Common S/MIME Client Tests L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
S/MIME Signing idem, et test le bit digitalSignature sur keyUsage est présent
S/MIME Encryption idem et test le bit keyEncipherment sur keyUsage est présent
S/MIME CA L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
CRL Signing KeyUsage doit être absent ou avoir le bit CRL Signing mis.
CRL Signing CA Test normal CA, excepté que l’extention basicContraints ne doit pas être présent
^
15 avril 2013

htmlpdflatexmanmd




OpenSSL - x509v3_config

OpenSSL - x509v3_config

Format de configuration des extensions de certificat X509 v3

   Le format est le suivant:

  extension_name=[critical,] extension_options

  Si critical est présent, l’extension est critique. Il y’a 4 types d’extension: chaînes, multi-valué, raw, et arbitraire.

exemple chaîne:
nsComment="This is a Comment"
exemple multi-valué:
basicConstraints=critical,CA:true,pathlen:1
variante d’un multivalué:
basicConstraints=critical,@bs_section
[bs_section]
CA=true
pathlen=1

Extensions standard

Contraintes de base Extension multi-valué qui indique si un certificat est un certificat de CA


basicConstraints=CA:TRUE
basicConstraints=CA:FALSE
basicConstraints=critical,CA:TRUE, pathlen:0

   Un certificat de CA doit avoir basicContraints à TRUE et optionnellement un pathlen qui indique le nombre maximum de CA qui peut apparaitre sous celle-ci dans une chaîne. A 0, peut seulement signer des certificats finaux.

Utilisation de clé Extension multi-valué consistant d’une liste de noms d’utilisation de clé permis Les noms supportés sont : digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly et decipherOnly.

exemple:
keyUsage=digitalSignature, nonRepudiation
keyUsage=critical, keyCertSign

Utilisation de clé étendue Consiste en une liste d’utilisation indiquant l’utilisation de la clé publique. Peut être un nom court, ou un OID:

Value Meaning
----- -------
serverAuth SSL/TLS Web Server Authentication.
clientAuth SSL/TLS Web Client Authentication.
codeSigning Code signing.
emailProtection E-mail Protection (S/MIME).
timeStamping Trusted Timestamping
msCodeInd Microsoft Individual Code Signing (authenticode)
msCodeCom Microsoft Commercial Code Signing (authenticode)
msCTLSign Microsoft Trust List Signing
msSGC Microsoft Server Gated Crypto
msEFS Microsoft Encrypted File System
nsSGC Netscape Server Gated Crypto

exemple:
extendedKeyUsage=critical,codeSigning,1.2.3.4
extendedKeyUsage=nsSGC,msSGC

Identifiant de clé du sujet Extention de type chaîne qui prend 2 valeurs : hash qui suit la rfc3280 ou une chaîne hexa donnant la valeur de l’extension à inclure

exemple:
subjectKeyIdentifier=hash

Identifiant de clé d’autorité Permet 2 options, keyid et issuer et peuvent prendre optionnellement la valeur always

           Avec keyid, tente de copier le subject key identifier depuis le certificat parent. Avec always, une erreur est retourné si l’option échoue.

  avec issuer, copie l’issuer et le numéro de série de l’issuer

exemple:
authorityKeyIdentifier=keyid,issuer

Subject Alternative Name L’extention subjectAltName permet d’inclure divers valeurs : email, URI, DNS, RID (ID:Object Identitifer), IP, dirName (un DN) et otherName.

        email contient une options spécial ’copy’ qui inclus automatiquement les emails contenus dans le sujet dans l’extension
        dirName devrait pointer vers une section contenant un DN à utiliser.
        otherName peut inclure des données arbitraires associées avec un OID

exemple:
subjectAltName=email:copy,email:my@other.address,URI :http://my.url.here/
subjectAltName=IP:192.168.7.1
subjectAltName=IP:13::17
subjectAltName=email:my@other.address,RID:1.2.3.4
subjectAltName=otherName:1.2.3.4;UTF8:some other identifier
    
subjectAltName=dirName:dir_sect
    
[dir_sect]
C=UK
O=My Organization
OU=My Unit
CN=My Name

Issuer Alternative Name Supporte toutes les options litéral de subjectAltName. Il ne supporte pas l’option mail:copy. Il supporte issuer:copy qui copie tous les subjectAltName du certificat de l’issuer

exemple:
issuerAltName = issuer:copy

Authority Info Access Extension d’accès aux informations de l’authorité donne des détails sur la mannière d’accéder à certaines informations lié à la CA. la syntaxe est accessOID;location, où location a la même syntaxe qu’un subjectAltName (excepté email:copy) accessOID peut être un OID valide mais seul certaines valeurs ont une signification, par exemple OCSP et calssuers

exemple:
authorityInfoAccess = OCSP;URI:http://ocsp.my.host/
authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html

Point de distribution de CRL Extension multi-valuée qui peut être un nom:valeur utilisant la même forme qu’un subjectAltName

   Dans le cas d’une simple option, la section indiquée contient les valeurs pour chaque champs. dans cette section:

  Si le nom est fullname la valeur devrait contenir le nom complet du point de distribution dans le même format que subjectAltName.

  Si le nom est relativename, la valeur devrait contenir un nom de section dont le contenu représente un DN

  Le nom CRLIssuer devrait contenir une valeur pour ce champ au format subjectAltName

  Si le nom est reasons, la valeur devrait consister en un champ contenant les raisons: keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, AACompromise.

exemple:
crlDistributionPoints=URI:http://myhost.com/myca.crl
crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth...
crlDistributionPoints=crldistpoint1_section
    
[crldistpoint1_section]
fullname=URI:http://myhost.com/myca.crl
CRLissuer=dirName:issuer_sect
reasons=keyCompromise, CACompromise
    
[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Issuing Distribution Point Devrait seulement apparaître dans les CRL. Extension multi-valuée dont la syntaxe est similaire à la section pointé par l’extension de point de distribution de CRL avec quelques différences

   Les noms reasons et CRLIssuer ne sont pas reconnus

  Le nom onlysomereasons est accepté. La valeur est au même format que le champ reasons des crlDistributionPoints. Les noms onlyuser, onlyCA, onlyAA et indirectCRL sont aussi acceptés et sont des booléen.

exemple:
issuingDistributionPoint=critical, @idp_section
[idp_section]
fullname=URI:http://myhost.com/myca.crl
indirectCRL=TRUE
onlysomereasons=keyCompromise,CACompromise
[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Certificate Policies Extension raw

Si on suit la recommandation PKIX, en utilisant des OID:
certificatePolicies= 1.2.4.5, 1.1.3.4

   Si on inclus des qualifiers, les OID de stratégie et les qualifieurs doivent être spécifiés dans une section séparée (sous la forme @section) La section référée doit inclure l’OID de stratégie en utilisant policyIdentifier. les qualifiers cPSuri peuvent être inclus avec cette syntaxe:


CPS.nnn=value

les qualifiers userNotice peuvent être définis avec:
userNotice.nnn=@notice

   Cette section peut inclure explicitText, organization et noticeNumbers.

exemple:
certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect
[polsect]
policyIdentifier = 1.3.5.8
CPS.1="http://my.host.name/";
CPS.2="http://my.your.name/";
userNotice.1=@notice
[notice]
explicitText="Explicit Text Here"
organization="Organisation Name"
noticeNumbers=1,2,3,4

   Si userNotice est utilisé avec IE5, il faut l’option ia5org avant pour modifier l’encodage. Cette options modifie le type de champs organization dans la rfc2459, il peut seulement être de type DisplayText. Dans la rfc3280 IA5String est aussi permis.

Policy Constraints Extension multivaluée consistant de nom requireExplicitPolicy ou inhibitPolicyMapping et une valeur entière non négative Au moins un composant doit être présent.

exemple:
policyConstraints = requireExplicitPolicy:3

Inhibit Any Policy Extension chaîne consistant de valeurs non négatives

exemple:
inhibitAnyPolicy = 2

Name Constraints Extension multi-valuée. Le nom devrait commencer avec le mot permitted ou excluded, suivi par un ';' le reste suivi la syntaxe subjectAltName excepté email:copy et IP

exemple:
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
issuingDistributionPoint = idp_section

OCSP No Check Extension chaîne, mais sa valeur est ignored

exemple:
noCheck = ignored

Extensions arbitraires

   Si une extension n’est pas supportée par OpenSSL, elle doit être encodé en utilisant le format arbitraire. Il est possible d’utiliser ce format pour les extensions connues.

  Il y’a 2 manières d’écrire des extensions de type arbitraire:

Utiliser le mot ASN1 suivi de l’extension en utilisant la même syntaxe que ASN1_generate_nconf(3):
1.2.3.4=critical,ASN1:UTF8String:Some random data
1.2.3.4=ASN1:SEQUENCE:seq_sect
[seq_sect]
field1 = UTF8:field1
field2 = UTF8:field2

Utiliser le mot DER pour inclure les donnée brutes:
1.2.3.4=critical,DER:01:02:03:04
1.2.3.4=DER:01020304

La valeur après DER est un dump DER d’une extension. Une extension peut être placée dans cette forme pour remplacer le mode par défaut :
basicConstraints=critical,DER:00:01:02:03

Notes

Si une extension est multi-valué et un champs doit contenir un ',', la forme longue doit être utilisée sinon le séparateur sera mal interprété:
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar


va produire une erreur, mais ceci est valide:
subjectAltName=@subject_alt_section
[subject_alt_section]
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar

Due à la librairie conf, le même nom de champ ne peut se trouver qu’une seul fois. Celà signifie que:
subjectAltName=@alt_section
[alt_section]
email=steve@here
email=steve@there

Va seulement reconnaître la dernière valeur, alors que ceci reconnaîtra toutes les valeurs:
[alt_section]
email.1=steve@here
email.2=steve@there

^
03 février 2016

htmlpdflatexmanmd




openvt

openvt

Lance un programme dans un nouveau terminal virtuel

   openvt trouve le premier VT disponible, et lance la commande donnée dessus. L'entrée, la sortie et l'erreur standards sont dirigés sur le terminal. Le PATH est utilisé pour trouver le commande. Sans commande spécifiée, la variable SHELL est utilisée.

OPTIONS

-c, --console=VTNUMBER Utilise le VT donné au lieu du premier disponible. Nécessite un accès en écriture au VT fournis.
-f, --force Force l'ouverture du VT sans vérifier s'il est prêt
-e, --exec Exécute directement la commande donnée, sans forker. openvt doit ouvrir un leader de session pour que cela fonction (voir setsid)
-s, --switch Bascule dans le nouveau VT en lançant la commande.
-u, --user Propriétaire du VT à utiliser. Ne devrait pas être utilisé avec -c ou -l
-l, --login Crée un login shell. Un - est ajouté avant le nom de la commande à exécuté
-v, --verbose mode verbeux
-w, --wait Attend que la commande se termine. Si -w et -s sont utilisé ensemble, openvt revient au terminal contrôlant.
-- Fin des options d'openvt

Exemples

Lancer un shell dans le prochain VT disponible
openvt bash
Lancer un login shell
openvt -l bash
Distinguer les options de la commande
openvt -- ls -l
^
08 février 2015

htmlpdflatexmanmd




pacemakerd

pacemakerd

Service pacemaker

OPTIONS

-V, --verbose Augmente la verbosité
-S, --shutdown Dit à Pacemaker d'éteindre la machine
-F, --features Affiche la version complète et liste les fonctionnalités de pacemaker
-f, --foreground Ne met pas en tâche de fond
-p, --pid-file=value Fichier pid
^
06 avril 2014

htmlpdflatexmanmd




paco

paco

Gestionnaire de paquet lors de l'installation depuis le code source

   En installant un paquet, paco peut être utilisé en mode log (avec l'option -l) pour envelopper la commande d'installation (ex: "make install"), et logger les fichiers créés. par défaut, les log sont dans le répertoire /var/log/paco. Une fois un paquet installé et loggé, paco peut être utilisé en mode liste, qui est de défaut, pour afficher les informations du paquet. Il y'a également des options pour supprimer des paquet, requêter de propriétaire des fichiers, ou maintenir la base de paquets.

Options générales

-a, --all Applique l'action spécifiée à tous les paquets loggés. ne fonctionne pas avec l'option -r
-L, --logdir=DIR Répertoire pour les logs (défaut: /var/log/paco)
-v, --verbose mode verbeux, -vv affiche également des messages de débuggage

Options de maintenance de base

-u, --update Synchronise le log du paquet avec le status courant du système de fichier, calculant la taille des fichiers loggés et en vérifiant ceux qui sont manquants. détecte ceux qui sont compressés.
-U, --unlog Supprime le log du paquet de la base

Options générales de liste

-b, --block-size=SIZE Utilise des block de la taille spécifiée.
-k, --kilobytes idem à --block-size=1k ou --block-size=1024
--sort=WORD trie la liste par: name, size, date, files, missing-files ou missing-size
-r, --reverse inverse l'ordre de trie
-t, --total Affiche les totaux à la fin de la liste

Options générales de paquet

-1, --one-column Liste un paquet par ligne
-F Affiche le nombre de fichiers installés
-M Affiche la nombre de fichiers manquants
-C Affiche le nombre de fichier partagés (installés et manquants)
-d, --date Affiche la date d'installation (-dd affiche l'heure également)
-s, --size Affiche la taille de chaque paquet installé
-n, --missing-size Affiche la taille manquante de chaque paquet installé (taille originale - taille courante)

-Options de liste de fichiers

-f, --files Liste les fichiers actuellement installés
-m, --missing-files Liste les fichiers manquants (fichiers supprimés après l'installation)
-c, --shared Avec -f et/ou -m, liste seulement les fichier partagés (ceux également loggés par d'autres paquets)
-N, --non-shared Avec -f et/ou -m, liste seulement les fichier non-partagés (ceux non loggés par d'autres paquets)
-w, --who-shares Avec -c, affiche les noms des paquets qui partagent chaque fichier
-y, --symlinks Affiche le contenu des fichiers symboliques
-s, --size Affiche la taille de chaque fichier
-z, --no-package-name N'affiche pas le nom du paquet.

Options d'information

-i, --info Affiche des informations sur le paquet
-o, --configure-options Affiche les options de configure
-q, --query, --owner Requête les paquets qui possèdent un ou plusieurs fichiers

Options de log

-l, --log active le mode log. Si une commande shell est donnée en argument, l'exécute de la monitore, log les fichiers créés, sinon la liste des fichiers est lue depuis l'entrée standard.
-p, --package=PKG Spécifie le nom du paquet à logger, qui doit commencer par un caractère alpha-numéric.
-D, --dirname Utilise le nom du répertoire courant comme nom du paquet à logger
-E, --exclude=PATH1:PATH2:... Liste de chemins à ignorer durant le log. Défaut: /dev:/tmp:/usr/src:/media:/selinux:/sys:/usr/share/info/dir
-I, --include=PATH1:PATH2:... Liste de chemins à scanner durant le log. Défaut: /
--ignore-errors Ne quitte pas si la commande d'install échoue.
--log-missing Log également les fichiers manquants
-+, --append Avec -p ou -D, si le paquet est déjà loggé, ajoute la liste des fichiers à son log

Options de suppression

-r, --remove Supprime un paquet, laissant les fichiers partagés et demande confirmation. Les fichiers compressés ont également supprimés. -rr, le paquet est supprimé de la base.
-B, --batch Ne demande pas confirmation lors de la suppression
-e, --skip=PATH1:PATH2:... Ne supprime pas les fichiers dans ces chemins
--remove-shared Supprime également les fichiers partagés

Correspondance de chemins

   Les options -I, -E, et -e accèptent une liste de chemins, chacun peut contenir des caractères d'expansion (*,? et [..]]. Les fichiers sont matchés avec chacun de ces paths, suivant l'expansion standard de shell, mais avec l'exception suivante: Si un chemin ne contient wildcard, et est un repertoire, il matche tout fichier dans ce repertoire.

Exemples

logger l'installation du paquet foo-1.0, qui est installé avec make -C src install. Utiliser des guillemets pour empêcher l'interprétation de -C
paco -lp foo-1.0 "make -C src install"
Utilser les guillemets simples si la commande contient déjà des guillemets doubles
paco -lp foo-1.0 'echo "hello world" › /var/log/foo.log'
L'argument de fin d'option peut être utilisé dans le même but
paco -lp foo-1.0 -- make -C src install
Alternativement, on peut utiliser le répertoire courant comme nom de paquet
paco -lD "make install && make install.man"
Si on a oublié d'installer un fichier, il peut être ajouté
paco -lp+ foo-1.0 "install foo /bin/foo"
Noter que -+ ne permet pas de supprimer un fichier dans le log
paco -lp+ foo-1.0 "rm /bin/foo"
Ne supprime pas le fichier du log
Pour éviter ce problème il est parfois utile de joindre des commandes d'install composés en une seule commande. Par exemple, pour un paquet qui installe /bin/foo, mais on veut qu'il s'install dans /usr/bin/foo:
paco -lp foo-1.0 make install
paco -lp+ foo-1.0 "mv /bin/foo /usr/bin/foo"
Les 2 fichiers sont marqués dans les logs. /usr/bin/foo est marqué installé et /bin/foo est marqué manquant. les 2 commandes peuvent être spécifié sur une seule ligne, celà marque /foo/bar même s'il est manquant.
echo /foo/bar | paco --log-missing -lp foo
Pour supprimer toutes les versions du paquet foo, en laissant les fichiers dans /etc et /root:
paco -r --batch -e /etc:/root foo
Pour supprimer le paquet foo-3.3, en laissant les fichiers dans /var/log et les fichiers *.conf
paco -r -e '/var/log:*.conf' foo-3.3
On a installé le paquet bubble-1.9 en préfix /opt/bubble-1.9, mais on n'a pas loggé l'installation. Cela peut être fait avec
find /opt/bubble-1.9 | paco -lp bubble-1.9

fichiers

/etc/pacorc fichier de configuration de paco
/var/log/paco répertoire par défaut pour les logs
^
06 avril 2014

htmlpdflatexmanmd




pacorc

pacorc

Fichier de configuration pour paco

   Le fichier consiste de paires de clé/valeur. Les commentaires sont sur des lignes séparés et commencent avec #.

OPTIONS

LOGDIR [-L|--logdir] Répertoirse pour les logs de paco (défaut: /var/log/paco)
MAX_DB_AGE nombre maximum de jours depuis la dernière mise à jours de la base de donnée. Quand cette limite est atteinte, paco affiche a warning. à 0 est désactivé, ( défaut: 7)
INCLUDE [-I|--include] Liste de chemins à scanner en loggant l'installation d'un package (défaut: / )
EXCLUDE [-E|--exclude] Liste de chemins à ignorer en loggant l'installation d'un package (défaut: '/dev:/tmp:/usr/src:/media:/selinux:/sys:/usr/share/info/dir' )
BLOCK_SIZE Taille de fichier dans les logs. Devrait être définis à la taille de block du système de fichier (défaut: 0). note: cette option est différente de l'option -b de paco
APPARENT_SIZE idem à BLOCK_SIZE=1
LOG_IGNORE_ERRORS [--ignore-errors] À 1, paco log les paquet même si l'install échoue (défaut: 0 )
LOG_IGNORE_SHARED [--ignore-shared] À 1, paco ignore les fichiers partagé dans les logs (défaut: 0 )
CASE_SENSITIVE À 1, paco devient sensible à la casse. (défaut : 0 )

correspondance de chemin

   Les variables INCLUDE et EXCLUDE acceptent une liste de path, chacun pouvant contenir les wildcards ( *, ?, et [...]). Les fichiers sont matchés avec chacun de ces path, suivant l'expansion shell standard, mais avec l'exception suivante: si un chemin dans la liste ne contient pas de wildcard, et que c'est un répertoire, in match tous fichiers dans ce répertoire.

Variables d'environnement

PACO_DEBUG À yes, paco agit comme avec l'option -vv
^
03 octobre 2010

htmlpdflatexmanmd




PAM

PAM

Pluggable Authentication Modules

   Linux-PAM est un système de librairies qui manipulent les tâches d'authentification des services dans le système. La librairie fournis une API qui fournis un système d'authentification déféré.

   La fonctionnalité principal de PAM est la nature de l'authentification qui est configurable dynamiquement. L'administrateur est libre de choisir comment les applications vont authentifier un utilisateur. La configuration individuelle peut être définie dans le fichier de configuration /etc/pam.conf. Alternativement, la configuration peut être définie dans des fichiers individuels dans /etc/pam.d/.

   Linux-PAM sépare les tâches d'authentification en 4 groupes indépendants: gestion des comptes; gestion de l'authentification; gestion des mots de passe; gestion de session.

   Le mécanisme account fournit une seule primitive: il vérifie si le compte demandé est disponible (si le compte n'est pas arrivé à expiration, si l'utilisateur est autorisé à se connecter à cette heure de la journée, etc.).

   Le mécanisme auth fournit deux primitives; il assure l'authentification réelle, éventuellement en demandant et en vérifiant un mot de passe, et il définit des "certificats d'identité" tels que l'appartenance à un groupe ou des "tickets" kerberos.

   Le mécanisme password fournit une seule primitive: il permet de mettre à jour le jeton d'authentification (en général un mot de passe), soit parce qu'il a expiré, soit parce que l'utilisateur souhaite le modifier.

   Le mécanisme session fournit deux primitives: mise en place et fermeture de la session. Il est activé une fois qu'un utilisateur a été autorisé afin de lui permettre d'utiliser son compte. Il lui fournit certaines ressources et certains services, par exemple en montant son répertoire personnel, en rendant sa boîte aux lettres disponible, en lançant un agent ssh, etc.

Syntaxe du fichier de configuration

   Le format de chaque rêgle est une collection de tokens séparés par un espace:

  service type control module-path modeul-arguments

service est typiquement le nom de l'application. Le service 'other' est réservé pour définir les règles par défaut.
type est le gestionnaire auquel la règle correspond ( account, auth, password, session ). Si le type est précédé par un '-', la librairie PAM ne loggera rien s'il n'est pas possible de charger le module s'il n'est pas présent dans le système.
control indique le comportement de PAM-API si le module échoue dans sa tâche d'authentification. Il y'a 2 types de syntaxe: un simple mot clé, et une paire [value=action].

Les valeurs possibles

        required Retourne un échec mais seulement après que les modules stackés restant aient été invoqués.
        requisite identique à required, mais retourne le contrôle. La valeur de retour est associée avec le premier required ou requisite qui a échoué. Ce flag peut être utilisé comme protection contre la possibilité qu'un utilisateur ait l'opportunité d'entrer un mot de passe dans un environnement non sécurisé.
        sufficient Le succès d'un tel module est suffisant pour satisfaire aux requis de la pile de module (si un précédent required a échoué, celui-ci est ignoré). Si le module réussit, retourne le succès immédiatement sans essayer les autres modules.
        optional Le succès ou l'échec n'est pas important si c'est le seul module dans la pile.
        include inclue toutes les lignes d'un type donné depuis un fichier de configuration spécifié en argument.
        substack Identique à include mais diffère dans les actions done et die dans une sous pile qui n'ignorent pas le reste de la pile, mais seulement sur la sous pile.
        [value=action1 value2=action2 ...]valueN correspond au code de retour de la fonction invoquée dans le module. peut être:success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete, et default.

                default implique toutes les valueN non mentionnées explicitement.
                actionN prend une des valeurs suivante:
                ignore Le status de retour ne contribut pas à retourner un code que l'application obtient.
                bad le code de retour indique que le module a échoué. Si c'est le premier module de la pile à échouer, ce status est utilisé pour toute la pile.
                die Idem à bad mais la pile de termine immédiatement.
                ok Ce code devrait contribuer directement au code de retour de toute la pile.
                done Idem à ok mais termine immédiatement la pile
                N (entier non signé) Idem à ok mais saute immédiatement au N-ème module suivant dans la pile
                reset Efface toute trace de l'état du module et commence avec le module suivant.

        required [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
        requisite [success=ok new_authtok_reqd=ok ignore=ignore default=die]
        sufficient [success=done new_authtok_reqd=done default=ignore]
        optional [success=done new_authtok_reqd=ok default=ignore]

module-path est soit le nom de fichier utilisé par l'application (comence par un '/'), soit un chemin relatif à l'emplacement des modules: /lib/security ou /lib64/security/
module-arguments est une liste de tokens séparés par un espace ou entre [] si des arguments contiennent des espaces, qui peut être utilisé pour modifier le fonctionnement d'un PAM.

Exemple de configuration

Un système considéré sécurisé a une entrée other raisonnablement sécurisé:
other auth required pam_deny.so
other account required pam_deny.so
other password required pam_deny.so
other session required pam_deny.so
l'exemple suivant fournit des alertes utiles pour les administrateurs:
other auth required pam_warn.so
other password required pam_warn.so
exemple classique sur les machines moins sensible dans /etc/pam.d/other:
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
Il est conseillé d'avoir une entrée other sécurisée:
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so
^
03 octobre 2010

htmlpdflatexmanmd




pam_access

pam_access

Module de contrôle d'accès

   Ce module est principalement utilisé pour la gestion d'accès. Il fournit contrôle d'accès de login style logdaemon sur les noms de logins, hôtes ou noms de domaines, les adresses internet ou réseaux ou nom de lignes terminal. Les rêgles d'accès par défaut sont pris dans /etc/security/access.conf. Si PAM est compilé avec le support d'audit, le module reporte quand il refuse l'accès basé sur l'origine (hôte ou tty).

   Le fichier de rêgles par défaut spécifie des combinaisons (user/group, host) (user/group, network/mask) (user/group, tty) pour qu'un login soit accèpté ou refusé. L'ordre est important, le module s'arrête à la première correspondance trouvée. Chaque ligne possède la syntaxe suivante:

permission:users/groups:origins
- Le premier champs est soit '+' pour authoriser l'accès soit '-' pour l'interdire.
- Le second champ est une liste d'un ou plusieurs noms de login, groups, ou ALL. Pour différencier les noms des groupes, les groupes sont écris entre parenthèses.
- Le troisième champ est une liste de noms tty, noms d'hôtes, noms de domaines (commençant par '.'), numéros de réseau (se termine par '.'), addresse réseaux avec le masque, ALL ou LOCAL qui correspond uniquement si PAM_RHOST n'est pas définis et le champs origin est définis depuis PAM_TTY ou PAM_SERVICE. Il est possible d'utiliser @netgroupname dans l'hôte ou les pattern utilisateur.
- L'opérateur EXCEPT permet d'écrire des rêgles compacte.
- Si nodefgroup n'est pas définis, le fichier group est recherché quand un nom ne correspond pas à l'utilisateur. Seul les groupes qui correspondant à de tels utilisateurs sont explicitement listés.

OPTIONS

accessfile=/path/to/access.conf Spécifie le fichier de rêgles à utiliser
debug syslog de nombreuses informations
noaudit Ne report pas les logins des hôtes et tty non autorisés dans le sous-système d'audit.
fieldsep=separators Modifie le séparateur par défaut
listsep=separators Modifie le séparateur de listes
nodefgroup Les tokens utilisateurs qui ne sont pas entre parenthèse ne correspondent jamais aux groupes

Codes de retour

PAM_SUCCESS accès autorisé
PAM_PERM_DENIED Accès non autorisé
PAM_IGNORE pam_setcred a été appelé et ne fait rien
PAM_ABORT Aucune donnée ou option ne peut être donné.
PAM_USER_UNKNOWN utilisateur inconnus du système

Exemples

l'utilisateur root devrait toujours être autorisé à accéder à cron, X11, et les tty
+:root:crond :0 tty1 tty2 tty3 tty4 tty5 tty6
root devrait avoir accès depuis les hôtes qui ont une IPv4
+:root:192.168.200.1 192.168.200.4 192.168.200.9
+:root:127.0.0.1
root devrait avoir accès depuis les réseau 192.168.201.0
+:root:192.168.201.
ou
+:root:192.168.201.0/24
ou
+:root:192.168.201.0/255.255.255.0.
root devrait avoir accès depuis les hôtes foo1.bar.org et foo2.bar.org
+:root:foo1.bar.org foo2.bar.org
root devrait avoir accès depuis le domaine foo.bar.org
+:root:.foo.bar.org
root ne devrait pas avoir accès à toutes les ressources
-:root:ALL
l'utilisateur foo et le groups admins devraitent avoir accès à toutes les sources
+:@admins foo:ALL
Les utilisateurs john et foo devraient avoir accès depuis une adresse IPv6
+:john foo:2001:db8:0:101 ::1
john devrait avoir accès depuis le réseau IPv6
+:john:2001:db8:0:101 ::/64
interdire les logins console à tout le monde sauf shutdown, sync et tous les autres comptes, qui sont membre du groupe wheel
-:ALL EXCEPT (wheel) shutdown sync:LOCAL
Tous les autres utilisateurs devraient être refusés depuis toutes les autres sources
-:ALL:ALL
^
03 octobre 2010

htmlpdflatexmanmd




pam_cracklib

pam_cracklib

Vérifie le mot de passe via dictionnaire

   ce module peut être utilisé dans la pile password. Il demande un mot de passe et vérifie sa complexité avec un dictionnaire et définis des rêgles pour identifier les choix faibles. Si le mot de passe est jugé suffisemment fort, le module redemande confirmation du mot de passe à l'utilisateur. Si tout s'est bien passé le mot de passe est passé au modules suivants pour être installé comme nouveau token d'authentification.

   La vérification du mot de passe s'effectue comme suit: la routine Cracklib est appelé pour vérifier si le mot de passe est trouvé dans un dictionnaire; et si ce n'est pas le cas, une autre vérification est faite:

        Palindrome Est-ce que le nouveau mot de passe est un palindrome
        case change only Est ce que le nouveau mot de passe et l'ancien non qu'un changement de casse
        similar Si le nouveau mot de passe est trop proche de l'ancien. Principalement contrôlé par un argument, difok qui est un nombre de caractères qui diffèrent. Le défaut est 10 ou la moitié de la taille du nouveau mot de passe s'il est inférieur.
        simple Est ce que le mot de passe est trop petit. Contrôlé par 5 arguments: minlen, dcredit, ucredit, lcredit et ocredit.
        rotated Est ce que le nouveau mot de passe est une rotation de l'ancien mot de passe.
        Same Consecutive characters Vérification optionnelle des caractères consécutifs
        Contains user name Vérification optionnel desmots de passe contenant le nom de l'utiliateur.

   Ce module n'a pas d'argument. Avec le crypte md5, les mots de passe ne peuvent dépasser 8 caractères.

OPTIONS

debug Écrit des informations dans syslog.
authok_type=XXX Remplace le mot UNIX dans "New UNIX password : " et "Retype UNIX password : " par celui spécifié
retry=N Demande à l'utilisateur N fois avant de retourner une erreur. Défaut 1.
difok=N Change la règle par défaut de 5 caractères dans le nouveau mot de passe qui ne doivent pas être présent dans l'ancien mot de passe.
difignore=N Combien de caractères doit avoir le mot de passe avant que difok soit ignoré. Défaut est 23.
minlen=N Taille minimum pour le nouveau mot de passe (plus 1 si credits ne sont pas désactivé - défaut) Défaut 9
dcredit=N Credit maximum pour avoir des chiffres dans le mot de passe. défaut 1
ucredit=N crédit maximum pour avoir des lettres majuscule dans le mot de passe
lcredit=N Crédit maximum pour avoir des lettre minuscule dans le mot de passe.
ocredit=N Crédit maximum pour avoir d'autres caractères dans le mot de passe
minclass=N Nombre minimum de classes de caractère requises. Les 4 classes sont les chiffre, minuscules, majuscules et les autres. défaut 0
maxrepeat=N Nombre maximum de caractères consécutifs identiques dans le mot de passe.
reject_username Rejète le mot de passe s'il contient le nom de l'utilisateur
use_authtok Utilisé pour forcer le module à ne pas demander de nouveau mot de passe mais d'en utiliser un fournis par le module passowrd précédent.
dictpath=/path/to/dict Chemin vers les dictionnaires

Valeurs retournées

PAM_SUCCESS le nouveau mot de passe à passé toutes les vérifications
PAM_AUTHTOK_ERR Aucun nouveau mot de passe n'a été entré, le nom d'utilisateur ne peut pas être déterminé ou le nouveau mot de passe à échoué la vérification
PAM_AUTHTOK_RECOVERY_ERR L'ancien mot de passe n'a pas été fournis par un module précent ou n'est pas fournis par l'utilisateur
PAM_SERVICE_ERR Une erreur interne s'est produite

Exemples

Exemple montrant commant il peut être stacké avec le composant password de pam_unix:
passwd password required pam_cracklib.so retry=3
passwd password required pam_unix.so use_authtok
Autre exemple dans le cas où vous voulez utiliser md5:
password required pam_cracklib.so difok=3 minlen=15 dcredit=2 ocredit=2
password required pam_uix.so use_authtok nullok md5
Autre exemple dans le cas où vous ne voulez pas utiliser les crédits:
password required pam_cracklib.so dcredit=-1 ucredit=-1 ocredit=-1 lcredit
=0 minlen=0
password required pam_unix.so use_authtok nullok md5
^
04 octobre 2010

htmlpdflatexmanmd




pam_debug

pam_debug

ce module sert à des fin de débuggage pour déterminer comment la pile PAM opère

OPTIONS

auth=value La fonction pam_sm_authenticate retourne value
cred=value La fonction pam_sm_setcred retourne vlaue
acct=value La fonction pam_sm_acct_mgmt retourne value
prechauthtok=value La fonction pam_sm_chauthtok retourne value si le flag PAM_PRELIM_CHECK est mis
chauthtok=value La fonction pam_sm_chauthtok retourne value si le flag PAM_PRELIM_CHECK n'est pas mis
open_session=value La fonction pam_sm_open_session retourne value
close_session=value La fonction pam_sm_close_session retourne value

   où value peut être: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete.

   Fournis tous les modules et retourne le code PAM_SUCCESS par défaut si aucune autre valeur n'a été spécifié, sinon retourne la valeur.

Exemples

auth requisite pam_permit.so
auth [success=2 default=ok] pam_debug.so auth=perm_denied cred=success
auth [default=reset] pam_debug.so auth=success cred=perm_denied
auth [success=done default=die] pam_debug.so
auth optional pam_debug.so auth=perm_denied cred=perm_denied
auth sufficient pam_debug.so auth=success cred=success
^
04 octobre 2010

htmlpdflatexmanmd




pam_deny

pam_deny

Refuser l'accès, indique toujours une erreur.

Valeurs retournées

PAM-AUTH_ERR retournée par les services account et auth
PAM_CRED_ERR retourné par la fonction setcred
PAM_AUTHTOK_ERR retourné par le service password
PAM_SESSION_ERR retourné par le service session

Exemples

other auth required pam_warn.so
other auth required pam_deny.so
other account required pam_warn.so
other account required pam_deny.so
other password required pam_warn.so
other password required pam_deny.so
other session required pam_warn.so
other session required pam_deny.so
^
04 octobre 2010

htmlpdflatexmanmd




pam_echo

pam_echo

Afficher du texte

   pam_echo est un module qui affiche des messages texte pour informer l'utilisateur. Les séquences commençant par % sont interprétés comme suit:

        %H Le nom de l'hôte distant (PAM_RHOST)
        %h Le nom de l'hôte local
        %s le nom du service (PAM_SERVICE)
        %t Le nom du terminal (PAM_TTY)
        %U Le nom de l'utilisateur distant (PAM_RUSER)
        %u Le nom de l'utilisateur local (PAM_USER)

file=/path/message Le contenu du fichier sera affiché

   Tous les types de module sont fournis.

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_SUCCESS le message s'est affiché correctement
PAM_IGNORE PAM_SILENT est donné ou le fichier de message n'existe pas

Exemples

Exemple montrant comment afficher des information sur les bons mots de passe:
password optional pam_echo.so file/usr/share/doc/good-password.txt
password required pam_unix.so
^
04 octobre 2010

htmlpdflatexmanmd




pam_env

pam_env

Définis des variables d'environnement

   Par défaut, les règles sont définies dans /etc/security/pam_env.conf. Chaque ligne commence avec le nom de la variable, puis 2 options possibles pour chaque variable DEFAULT et OVERRIDE. DEFAULT autorise à définir la variable à une valeur par défaut. OVERRIDE remplace la valeur par défaut.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

   Les variables d'environnement peuvent être utilisées dans les valeurs en utilisant $string et les PAM_ITEM peuvent être utilisés avec @string

OPTIONS

conffile=/path/to/pam_env.conf Spécifie le fichier de règles
debug syslog les informations de debugage
envfile=/path/to/environment Indique le fichier d'environnement à remplacer par défaut. Utile quand différents services nécessitent des environnements différents.
readenv=0|1 Active la lecture du fichier spécifié par envfile
user_envfile=filename Indique un fichier d'environnement .pam alternatif à remplacer par défaut. Ce fichier est relatif au répertoire home de l'utilisateur
user_readenv=0|1 active la lecture du fichier d'environnement utilisateur.

Valeurs retournées

PAM_ABORT Toutes les données et options ne peuvent être reçues
PAM_BUF_ERR Erreur de tampon mémoire
PAM_IGNORE Aucun pam_env.conf et fichier d'environnement ne peut être trouvé
PAM_SUCCESS Les variables d'environnement ont été définis

Exemples

Définis la variable REMOTEHOST pour tous les hôtes distant, "localhost" par défaut au lieu de ne rien définir du tout
REMOTEHOST DEFAULT=localhost OVERRIDE=@PAM_HOST
Définis la variable DISPLAY si elle semble raisonnable
DISPLAY DEFAULT=$REMOTEHOST:0.0 OVERRIDE=$DISPLAY
Quelques variales simple
PAGER DEFAULT=less
MANPAGER DEFAULT=less
LESS DEFAULT="M q e h15 z23 b80"
NNTPSERVER DFAULT=localhost
PATH DEFAULT=$HOME/bin :/usr/local/bin :/bin :/usr/bin :/usr/local/bin/X11 :/usr/bin/X11
Autres exemple
DOLLAR DEFAULT=\$
DOLLARDOLLAR DEFAULT=
DOLLARPLUS DEFAULT=\$REMOTEHOST$REMOTEHOST
ATSIGN DEFAULT="" OVERRIDE=\@
^
04 octobre 2010

htmlpdflatexmanmd




pam_exec

pam_exec

Appeler une commande externe

   L'environnement de l'enfant est définit dans la liste d'environnement PAM courante, comme retournée par pam_getenvlist. En plus les items PAM suivant sont exportés: PAM_RHOST, PAM_RUSER, PAM_SERVICE, PAM_TTY, PAM_USER et PAM_TYPE, qui contiennent un des types de modules: account, auth, password, open_session et close_session.

OPTIONS

debug Affiche des informations de debugage
expose_authtok Durant l'authentification la commande appelé peut lire le mot de passe depuis stdin
log=file La sortie de la commande est ajouté au fichier spécifié
quiet Par défaut le module affiche le statut de sortie. quiet supprime ce message
seteuid Par défaut le module va exécuter la commande externe avec le real user ID du processus appelant. Spécifier cette option signifie que la commande est lancé avec l'effective user ID.

Valeurs retournées

PAM_SUCCESS La commande externe à été exécutée avec succès
PAM_SERVICE_ERR Aucun argument ou nombre d'arguments incorrect
PAM_SYSTEM_ERR Une erreur système s'est produite ou la commande a échouée
PAM_IGNORE pam_setcred a été appelé, qui n'exécute pas la commande

Exemples

Ajouter cette ligne dans /etc/pam.d/passwd pour reconstruire la base NIS après chaque changement de mot de passe local
password optional pam_exec.so /usr/bin/make -C /var/yp
^
04 octobre 2010

htmlpdflatexmanmd




pam_faildelay

pam_faildelay

Change le délai d'échec

   Sans délai donné, utilise la valeur FAIL_DELAY dans /etc/login.defs

OPTIONS

debug syslog les informations de debuggage
delay=N Définis le délai en microsecondes

Valeurs retournées

PAM_IGNORE Le délai a été ajusté avec succès
PAM_SYSTEM_ERR Le délai spécifié n'est pas valide

Exemples

L'exemple suivant définis le délai d'échec à 10 secondes
auth optional pam_faildelay.so delay=10000000
^
04 octobre 2010

htmlpdflatexmanmd




pam_filter

pam_filter

Module de filtrage

   Ce module fournis un accès à toute entrée/sortie qui passent entre l'utilisateur et l'application. C'est seulement utilisable pour les tty et les applications stdin/stdout.

  Pour fonctionner ce module requière que les filtres soient installés sur le système. Le simple filtre fournit avec le module transpose simplement les lettres majuscules/minuscules sur les flux d'entrée/sortie.

  Chaque composant du module a le potentiel d'invoquer le filtre désiré. Le filtre est toujours appelé avec le privilège de l'application appelante et non l'utilisateur. Pour cette raison il ne peut pas être tué par l'utilisateur sans fermer sa session

OPTIONS

debug Affiche des informations de debuggage
new_term L'action par défaut du filtre est de définir PAM_TTY pour indiquer le terminal que l'utilisateur utilise pour se connecter à l'application. Cet argument indique que le filtre devrait définit PAM_TTY au terminal pseudo-filtré
non_term Ne tente pas de définit PAM_TTY
runX Pour que le module invoque un filtre il doit savoir quand l'invoquer. Cet argument spécifie quand le faire. Les valeurs permises sont 1 et 2 qui indique le temps précis où le filtre est lancé.
filter Le chemin du filtre

Valeurs retournées

PAM_SUCESS Le nouveau filtre à été définit correctement
PAM_ABORT Erreur critique

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour voir comment configurer le login pour transposer les lettre majuscule et minuscule une fois l'utilisateur loggé
session required pam_filter.so /lib/security/pam_filter/upperLOWER
^
04 octobre 2010

htmlpdflatexmanmd




pam_ftp

pam_ftp

Module pour accès anonyme

   pam_ftp est un module PAM qui fournis un accès anonymous style ftp. Ce module intercèpte le nom et le mot de passe de l'utilisateur. Si le nom est ftp ou anonymous, le mot de passe de l'utilisateur est supprimé au délimiteur '@' dans PAM_RUSER et PAM_RHOST; Le nom d'utilisateur est définis à ftp. dans ce cas, le module succède. Alternativement, le module définis PAM_AUTHTOK avec le mot de passe entré et échoue. Ce module n'est pas sûr.

OPTIONS

debug Affiche des informations de debuggage
ignore Ne fait pas attention à l'email de l'utilisateur s'il est fournit
ftp=XXX,YYY,... Au lieu de ftp et anonymous, fournis un login anonymous à la liste des utilisateurs spécifiés.

   Ne fournis que le module auth. retoune PAM_SUCCESS en cas de succès et PAM_USER_UNKNOWN s'il ne connait pas l'utilisateur.

Exemples

Ajouter ces lignes dans /etc/pam.d/ftpd pour manipuler les logins anonyme style ftp
auth sufficient pam_ftp.so
auth required pam_unix.so use_first_pass
auth required pam_listfile.so onerr=succeed item=user sense=deny file=/etc/ftpusers
^
04 octobre 2010

htmlpdflatexmanmd




pam_group

pam_group

Modifie l'accès des groupes

   Ce module fonctionne en parallèle avec /etc/group. Il n'authentifie pas l'utilisateur, mais son groupe. Par défaut les règles sont définies dans /etc/security/group.conf. Il ne fournis que le module auth. La syntaxe est la suivante:

  services;ttys;users;times;groups

services est une liste logique de noms de services PAM auquel la règle s'applique
tty est une liste logique de noms de terminal auquel la règle s'applique
users est une liste logique d'utilisateurs ou un groupe ou un netgroup auquel la règle s'applique les groupes sont précédés par '%' et les netgroup par '@'
times est utilisé pour indiquer quand ces groupes sont donnés à l'utilisateur. Le format est une liste de jour/plage-de-temps. Les jours sont spécifié par une séquence de 2 caractères, MoTuSa par exemple signifie Monday Tuesday et Saturday. Noter que les jours qui sont répétés s'annulent: MoMo = aucun jour, MoWk = toute la semaine sauf lundi. peut être Mo Tu We Th Fr Sa Su Wk Wd Al. On peut préfixer les jours avec ' !' pour spécifier "tout sauf". La plage de temps est sous la forme de 2 fois "HHMM".
groups est une liste de groupes que l'utilisateur hérite. Ces groupes sont ajoutés si les champs précédents sont satisfaits

Valeurs retournées

PAM_SUCCESS le membre du groupe est autorisé
PAM_ABORT aucune donnée nécessaire n'est trouvée
PAM_BUF_ERR Erreur de tampon mémoire
PAM_CRED_ERR Le membre du groupe n'est pas autorisé
PAM_IGNORE pam_sm_authenticate a été appelé et ne fait rien
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

En lancant xsh sur tty*, l'utilisateur 'us' à accès à la disquette (au travers du groupe floppy)
xsh ;tty*& !ttyp* ;us ;al0000-2400 ;floppy
idem, l'utilisateur sword a accès aux jeux via le groupe le groupe floppy après les heures de travail
xsh ; tty* ; sword ; !Wk0900-1800 ; games, sound
xsh ; tty* ; * ; Al0900-1800 ; floppy
Un membre du groupe admin tournant sous xsh sur tty* a accès au group plugdev
xsh ; tty* ; %admin ; Al0000-2400 ; plugdev
^
04 octobre 2010

htmlpdflatexmanmd




pam_issue

pam_issue

Ajoute un message au prompt

   Ne fournis que le type de module auth. Il reconnait les caractères échappés suivant:

\d jours
\l nom du tty
\m architecture de la machine (uname -m)
\n nom d'hôte du noeud réseau de la machine (uname -n)
\o nom de domain du système
\r version du système d'exploitation (uname -r)
\t heure
\s Nom du système d'exploitation (uname -s)
\u nombre d'utilisateurs actuellement loggés
\U idem à \u mais suffixe "user" ou "users"
\v Version du système (uname -v)

OPTIONS

noesc désactive l'interprétation des caractères d'échappement
issue=issue-file-name Fichier de sortie

Valeurs retourmées

   Retoune PAM_BUF_ERR, PAM_IGNORE, PAM_SERVICE_ERR et PAM_SUCCESS (le nouveau prompt a été définis)

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour définir une message au login
auth optional pam_issue.so issue=/etc/issue
^
06 octobre 2010

htmlpdflatexmanmd




pam_keyinit

pam_keyinit

Affiche le fichier keyinit

   pam_keyinit s'assure que le process invoque une session keyring autre que la session keyring par défaut de l'utilisateur. Il vérifie si la session keyring du processus est le défaut de l'utilisateur, et si c'est le cas, crée une nouvelle session keyring anonyme. Ce module est utilié principalement pour les processus de login. Ce module ne devrait pas être invoqué par des programmes comme su. Le package keyutils est utilisé pour manipuler les clés plus directement.

OPTIONS

debug Affiche des informations de debuggage
force force le session keyring du processus invoquant pour être remplacé inconditionnellement
revoke Force le session keyring du processus invoquant pour être révoqué quand ce processus quitte si le session keyring pour ce processus

Valeurs retournées

   ne fournit que le type de module session. Retourne PAM_SUCCESS, pam_ATH_ERR, PAM_BUF_ERR, PAM_IGNORE, PAM_SERVICE_ERR, PAM_SESSION_ERR et PAM_USER_UNKNOWN

Exemples

Ajouter cette ligne dans les entrées logins pour commencer chaque session login avec sa propre session keyring
session required pam_keyinit.so
^
02 juillet 2014

htmlpdflatexmanmd




pam_krb5

pam_krb5

Module d'authentification Kerberos

OPTIONS

ccache=‹pattern› Utilise le pattern pour créer le cache d'accréditifs. doit être sous la forme ‹type›:‹residual›. %u est remplacé avec l'id de l'utilisateur. %p est remplacé avec le PID courant. Si pattern se termine avec la chaîne XXXXXX, une chaîne aléatoire est utilisée. (auth et session)
ccache_dir=‹directory› Stocke les caches utilisateur dans le répertoire spécifié au lieu de /tmp (auth et session)
debug mode debug
forwardable Obtient des tickets forwardable (auth)
ignore_k5login Ne regarde jamais dans le fichier .k5login dans le home de l'utilisateur (auth et account)
ignore_root Ne fait rien si l'utilisateur est root.
minimum_uid=‹uid› ID minimum pour authoriser l'authentification
no_ccache ne créé pas de cache de ticket après l'authentification (auth). non définissable dans krb5.conf
realm=‹realm› Obtient des accréditifs dans le domaine spécifié au lieu de celui par défaut. non définissable dans krb5.conf
renew_lifetime=‹lifetime› Obtient des tickets renouvelable (auth)
retain_after_close Ne détruit pas le cache de ticket temporaire lorsque pam_end() ou pam_close_session() sont appelés. (auth et session)
search_k5login Utilise .k5login de l'utilisateur pour l'authentification.
try_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, demande un mot de passe.
use_authtok Utilise le mot de passe d'un module précédent au lieu d'en demander un. Ne demande jamais de mot de passe.
use_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, si aucun module n'a de mot de passe, en demande un, si un mot de passe est trouvé et ne fonctionne pas, échoue sans en demander un.

Variables d'environnement

KRB5CCNAME Définis par pam_setcred(). Fichier du cache d'accréditifs par défaut, sous la forme type:residual
PAM_KRB5CCNAME Définis par pam_authenticate() pour pointer vers le cache de ticket temporaire utilisé pour l'authentification.

Fichiers

/tmp/krb5cc_UID_RANDOM Nom du cache d'accréditifs par défaut.
/tmp/krb5cc_pam_RANDOM no du cache d'accréditifs utilisé pour le cache temporaire crée par pam_authenticate(). il est supprimé à la fin de la session pam ou quand pam_setcred() est appelé.
~/.k5login Fichier contenant les principaux Kerberos autorisés à accéder à ce compte.

Exemples

Exemple de configuration PAM:
auth sufficient pam_krb5.so ignore_root
session optional pam_krb5.so ignore_root
account required pam_krb5.so ignore_root
password optional pam_krb5.so ignore_root

Exemple de configuration krb5.conf
[appdefaults]
forwardable = true
    pam = {
        minimum_uid = 100
        EXAMPLE.COM = {
            ignore_k5login = true
        }
    }

^
06 octobre 2010

htmlpdflatexmanmd




pam_lastlog

pam_lastlog

Affiche une ligne d'information sur la dernière connexion de l'utilisateur

   Le module maintient le fichier /var/log/lastlog.

OPTIONS

debug Affiche des informations de debuggage
silent N'informe par 'utilisateur sur le précédent login, met simplement à jours /var/log/lastlog
never Si /var/log/lastlog est vide, indique à l'utilisateur qu'il n'a jamais été loggé
nodate N'affiche pas la date du dernier login
noterm N'affiche pas le nom du terminal
nohost N'indique pas depuis quel hôte le dernier login a eu lieu
nowtmp Ne met pas à jour l'entrée wtmp
noupdate Ne met aucun fichier à jour
showfailed Affiche le nombre de logins échoués et la date de la dernier tentative échouée depuis btmp

Valeurs retournées

PAM_SUCCESS tout est ok
PAM_SERVICE_ERR Erreur interne
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour afficher le dernier login d'un utilisateur
session required pam_lastlog.so wtmp
^
13 novembre 2010

htmlpdflatexmanmd




pam_ldap

pam_ldap

Authentification via un serveur ldap

   pam_ldap fournit l'authentification, l'autorisation et le changement de mot de passe depuis un serveur ldap. Il inclus le support sécurisé, authentification sasl, les politiques de mot de passe renforcés pas le serveur, les autorisations de login basés sur les hôtes et groupes.

  Quand il autorise ou authentifie un utilisateur, pam_ldap map le nom de login de l'utilisateur à un DN en cherchant dans l'annuaire. Cela doit être possible en utilisant l'identité du système local, spécifié dans ldap.conf (cette étape initial ne supporte que l'authentification simple pour le moment).

  Pour authentifier ou autoriser un utilisateur, pam_ldap tente de se lier au serveur en utilisant le DN de l'utilisateur. pam_ldap est généralement configuré dans ldap.conf, mais certaines options peuvent être configurées dans le fichier de configuration PAM, pour permettre une granularité par service.

   Les options du fichier de configuration consistent d'un mot clé suivi par un espace et des arguments. Il est possible de configurer certains aspects de pam_ldap par service dans les fichiers de configuration de pam

OPTIONS

config=‹path› Spécifie le fichier de configuration à utiliser au lieu de ldap.conf. Il n'est pas possible d'utiliser plusieurs instances de configuration.
use_first_pass Spécifie que pam_ldap devrait toujours utiliser le premier mot de passe fournis dans la pile d'authentification
try_first_pass Spécifie que pam_ldap devrait d'abord essayer le premier mot de passe fournis dans la pile d'authentification, puis de demander à l"utilisateur le mot de passe LDAP si l'authentification échoue.
ignore_unknown_user Spécifie que pam_ldap devrait retourner PAM_IGNORE pour les utilisateurs non présents dans l'annuaire.
ignore_authinfo_unavail Spécifie que pam_ldap devrait retourner PAM_IGNORE s'il ne peut contacter le serveur LDAP
no_warn Spécifie que les messages d'alerte ne devraient pas être propagés dans l'application PAM
use_authok Identique à use_first_pass pour le changement de mot de passe uniquement
^
06 octobre 2010

htmlpdflatexmanmd




pam_limits

pam_limits

Limiter les ressources

   pam_limits définit les limites des ressources système qui peuvent être obtenues dans une session utilisateur. Les utilisateurs uid=0 sont affectés par cette limite également. Par défaut, les limites sont définies dans /etc/security/limits.conf, puis les fichiers *.conf dans /etc/security/limits.d/. Ce module ne doit pas être appelé avec une application multi-thread.

  Si Linux-PAM est compilé avec le support audit, le module report quand il refuse l'accès basé sur une limite du nombre maximum d'utilisateurs de sessions login courante. Ne fournit que le type de module session.

Description de la configuration

‹domain› ‹type› ‹item› ‹value›

domain un utilisateur, un @groupe, '*' pour l'entrée par défaut et '%' pour la limite maxlogins uniquement, peut aussi être utilisée avec la syntaxe %groupe
type hard, soft et '-' le dernier force les 2 limites ensemble
item Peut avoir les éléments suivant:

        core limite la taille du fichier core (Ko)
        data taille de donnée maximum (Ko)
        fsize taille de fichier max (Ko)
        memlock allocation mémoire max (Ko)
        nofile nombre max de fichiers ouverts
        stack taille de pile max (Ko)
        cpu nombre de CPU
        nproc nombre max de processus
        as limite d'espace d'adresse (Ko)
        maxlogins nombre max de logins pour cet utilisateur (sauf pour uid=0)
        maxsyslogins Nombre max de logins sur le système
        priority (priorité du processus utilitateur)
        locks nombre max de fichiers lockés
        sigpending nombre max de signaux en suspend
        msqueue mémoire max utilisée par la queue de message POSIX
        nice priorité nice max autorisé
        rtprio priorité realtime max pour les processus non-privilégiés

   toutes les valeurs peuvent être -1, unlimited ou infinity sauf pour priority et nice

OPTIONS

change_uid change le real uid de l'utilisateur pour qui les limites sont définies.
conf=/path/to/limits.conf Spécifie l'emplacement du fichier de limites
debug Affiche des informations de debugage
utmp_early certains applications cassés allouent une entrée utmp pour l'utilisateur avant que l'utilisateur soit admis sur le système. si certains services configurés pour faire çà, vous pouvez sélectivement utiliser cet argument pour compenser ce fonctionnement.
noaudit Ne rapporte pas les excès de logins au système d'audit

Valeurs retournées

PAM_ABORT Ne peut pas avoir les limites
PAM_IGNORE Aucune limite trouvée pour l'utilisateur
PAM_PERM_DENIED les nouvelles limites ne peuvent pas être définies
PAM_SERVICE_ERR Ne peut pas lire le fichier de config
PAM_SUCCESS Les limites ont été changés

Exemples

* soft core 0
* hard rss 10000
@student hard nproc 20
@faculty soft nproc 20
@faculty hard nproc 50
ftphard nproc 0
@student - maxlogins 4
^
06 octobre 2010

htmlpdflatexmanmd




pam_listfile

pam_listfile

Autorise ou refuse les services basé sur un fichier arbitraire

   le mdule récupère l'item du type spécifié:

        user spécifie le username, PAM_USER
        tty spécifie le nom du terminal, PAM_TTY
        rhost spécifie le nom de l'hôte distant, PAM_RHOST
        ruser spécifie l'utilisateur distante, PAM_TUSER

   et cherche une instance de cet item dans file=filename. filename contient une ligne par item listé. Si l'item est trouvé, alors si sense=allow, retourne PAM_SUCCESS sinon si sense=deny, retourne PAM_AUTH_ERR.

   Si une erreur est rencontrée (par exemple si filename n'existe pas ou un argument mal construit est trouvé), alors si onerr=succeed, retourne PAM_SUCCESS, sinon si onerr=fail, retourne PAM_AUTH_ERR ou PAM_SERVICE_ERR.

  apply= peut être utilisé pour restreindre l'application à un utilisateur spécifique (apply=username) ou un groupe (apply=@groupname). Utile seulement avec tty, rhost et shell

OPTIONS

item=[tty|user|rhost|ruser|group|shell] Ce qui est listé dans le fichier et doit être vérifié
sense=allow Action à prendre si trouvé dans le fichier.
file=/path/filename Fichier contenant un item par ligne
onerr=succeed quoi faire si quelques chose se produit comme l'impossibilité d'ouvrir le fichier
apply=user restreint à l'utilisateur ou le groupe spécifié
quiet ne log par les erreurs

   fournis tous les types de module

Valeurs retournées

PAM_SUCCESS en cas de succès
PAM_AUTH_ERR en cas d'échec
PAM_BUFF_ERR, PAM_SERVICE_ERR en cas d'erreur interne
PAM_IGNORE si aucune rêgle ne s'applique

Exemples

l'authentification classique ftpusers peut être implémenté avec cette entrée dans /etc/pam.d/ftpd
auth required pam_listfile.so onerr=succeed item=user sense=deny file=/etc/ftpusers
note que les utilisateur listés dans /etc/ftpusers ne sont pas autorisés pour accéder au service ftp
Pour autoriser le login pour certains utilisateurs, vous pouvez utiliser une entrée dans /etc/pam.d/login
auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/loginusers
^
06 octobre 2010

htmlpdflatexmanmd




pam_localuser

pam_localuser

Les Utilisateurs doivent être listés dans le fichier passwd

   fournis tous les types de module

OPTIONS

debug affiche des informations de debugagge
file=/path/passwd Utilise un fichier autreque /etc/passwd

Valeurs retournées

PAM_SUCCESS le nouvel utilisateur local a été définis avec success
PAM_SERVICE_ERR Aucun nom d'utilisateur n'a été donné
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Ajouter cette ligne dans /etc/pam.d/su pour permettre au utilisateurs du groupe wheel à utiliser su
account suficient pam_localuser.so
account required pam_whell.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_loginuid

pam_loginuid

Définis le loginuid process attribute pour le processus authentifié

   C'est nécessaire pour auditer correctement les applications. Ce module devrait être utilisé seulement pour les applications d'entrée comme login, sshd, sshd, gdm, vsftpd, crond et atd. Vous ne devriez pas utiliser ce module avec des application comme sudo ou su. Ne fournis que les types de module session

OPTIONS

require_auditd Force le module à questionner le status du démon d'audit et refuser les logins s'il n'est pas lancé.

Exemples

auth required pam_unix.so
auth required pam_nologin.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
session required pam_loginuid.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_mail

pam_mail

Informe sur les mails disponible

   Ce module fournis le service "you have a new mail" à l'utilisateur. Fournis les types de module session et auth

OPTIONS

close indique si l'utilisateur à un mail au logout également
debug Affiche des informations de debuggage
dir=maildir recherche les mails de l'utilisateur dans le répertoire spécifié par maildir/‹login› par défaut : /var/log/mail/‹login›
empty Affiche également un message si l'utilisateur n'a pas de mail
hash=count mail directory hash depth
noenv ne définit pas la variable d'environnement MAIL
nopen n'affiche pas d'information au login. Utile pour définir MAIL sans rien afficher
quiet n'affiche que lorsqu'il y'a des nouveaux mail
standard ancien format "You have...". implique empty également

Valeurs retournées

PAM_BUF_ERR erreur tampon mémoire
PAM_SERVICE_ERR argument malformé
PAM_SUCCESS succès
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour indiquer que l'utilisateur a de nouveau mails quand il se log sur le système
session optional pam_mail.so standard
^
06 octobre 2010

htmlpdflatexmanmd




pam_mkhomedir

pam_mkhomedir

Créer un répertoire home

   ce module crée un répertoire home utilisateur s'il n'existe pas quand la session commence. Cela permet aux utilisateurs d'être présent dans la base central (tel que NIS, kerberos ou LDAP) sans utiliser un système de fichier distribué ou en pré-créant un grand nombre de répertoires. Le répertoire squelette (généralement /etc/skel/) est utilisé pour copier les fichiers par défaut et définir également un umask pour l'utilisateur.

OPTIONS

silent N'affiche pas d'information
skel=/path/to/skel/directory Spécifie le répertoire squelette
umask Spécifie le masque de création de fichiers

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_CRED_INSUFFICIENT insufficient credentials to access authentification data
PAM_PERM_DENIED Pas assez de permission pour créer le nouveau répertoire ou lire le dossier squelette
PAM_USER_UNKNOWN utilisateur inconnu
PAM_SUCCESS variables d'environnement définis

Exemples

un exemple du fichier /etc/pam.d/login
auth requisite pam_securetty.so
auth sufficient pam_ldap.so
auth required pam_unix.so
auth required pam_nologin.so
account sufficient pam_ldap.so
account required pam_unix.so
password required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_mail.so standard
^
06 octobre 2010

htmlpdflatexmanmd




pam_motd

pam_motd

Afficher le fichier motd

   pam_motd permet d'afficher le contenu d'un fichier motd une fois loggé avec succès. par défaut /etc/motd. La taille du message est limitée à 64Ko. Ne fournit que le type de module session.

Valeurs retournées

PAM_IGNORE c'est la seule valeur retournée par ce module

Exemples

exemple d'utilisation dans /etc/pam.d/login
session optional pam_motd.so motd=/etc/motd
^
14 novembre 2010

htmlpdflatexmanmd




pam_mysql

pam_mysql

Authentification auprès d'un serveur MySQL

OPTIONS

verbose Si définis à 1 logs des informations détaillées
debug Un alias du mode verbose
user Le nom de l'utilisateur à utiliser pour la connexion au serveur MySQL
passwd Le mot de passe de l'utilisateur spécifié par user
host Le nom d'hôte ou le chemin absolu du socket unix où le serveur MySQL écoute
db Le nom de la base de données contenant les noms de logins unique et leur mot de passe. Peut être une combinaison de tables avec la syntaxe JOIN. Par exemple: [table=Host LEFT JOIN HostUser ON HostUser.host_id=Host.id LEFT JOIN User ON HostUser.user_id=User.id]
update_table le nom de la table utilisée pour l'altération des mot de passe.
usercolumn Le nom de la colonne contenant les noms unix
passwdcolumn le nom de la colonne contenant les mots de passe cryptés
statcolumn Le nom de la colonne ou une expression SQL qui indique le statut de l'utilisateur. Le statut est exprimé par la combinaison de 2 bits:

        bit 0 à 1 le compte a expiré
        bit 1 à 1 le mot de passe doit être changé

crypt La méthode de cryptage du mot de passe:

        0 aucun cryptage
        1 ou Y crypt(3)
        2 ou mysql utilise MYSQL PASSWORD()
        3 ou md5 hash md5
        4 ou sha1 hash sha1

md5 Utilise md5 par défaut pour le hash crypt(3). N'a de sens que si crypt vaut Y
use_323_passwd Utilise MySQL version 3 pour la fonction de cryptage si crypt vaus mysql
where critère additionnel pour la requête
sqllog active ou non le log SQL
logtable Le nom de la table dans lequel écrire les logs
logmsgcolumn le nom de la colonne dans la table de log où est écrire le pid du processus utilisant pam_mysql
loghostcolumn Le nom de la colonne où l'IP de la machine est stocké
logrhostcolumn Le nom de la colonne où stocker l'hôte distant qui initie la session
logtimecolumn Le nom de la colonne dans laquelle écrire le timestamp
config_file Chemin vers le fichier de configuration dans le style NSS_Mysql qui énumère les options par ligne. Les noms d'options acceptées sont:

        - users.host (host)
        - users.database (db)
        - users.db_user (user)
        - users.db_passwd (passwd)
        - users.where_clause (host)
        - users.table (table)
        - users.update_table (update_table)
        - users.user_column (usercolumn)
        - users.password_column (passwdcolumn)
        - users.status_column (statcolumn)
        - users.password_crypt (crypt)
        - users.use_323_password (use_323_passwd)
        - users.use_md5 (md5)
        - users.where_clause (where)
        - users.disconnect_every_operation (disconnect_every_op) *1
        - verbose (verbose)
        - log.enabled (sqllog)
        - log.table (logtable)
        - log.message_column (logmsgcolumn)
        - log.pid_column (logpidcolumn)
        - log.user_column (logusercolumn)
        - log.host_column (loghostcolumn)
        - log.rhost_column (logrhostcolumn) setfor2
        - log.time_column (logtimecolumn)

use_first_pass à true pam_mysql ne demande pas de mot de passe et utilise celui fournit par un précédent module d'authentification. S'il n'est pas donné, l'authentification échoue
try_first_pass Tente avec le mot de passe fournit pas un précédent module d'authentification. S'il échoue, demande le mot de passe à l'utilisateur
disconnect_every_op Par défaut, pam_mysql conserve la connexion à la base mysql jusqu'à ce que la session soit terminée. Cette option permet de déconnecter à chaque fois que l'opération PAM s'est terminée.

Exemples

auth optional pam_mysql.so user=root passwd=password
account required pam_mysql.so user=root passwd=password
^
06 octobre 2010

htmlpdflatexmanmd




pam_namespace

pam_namespace

Définit un espace de nom privé

   pam_namespace définit un espace de nom privé pour une session avec répertoire poly-instancés. Un répertoire poly-instancié fournis une instance différente de lui-même basé sur le nom utilisateur, ou en utilisant SELinux, le nom d'utilisateur, contexte de sécurité ou les 2. Si un script exécutable /etc/security/namespace.init existe, il est utilisé pour initialiser l'instance du répertoire après qu'il ai été définis et monté dans le répertoire poly-instancié. Le script reçoit le chemin du répertoire poly-instancié, le chemin du répertoire instance, si le répertoire instance a été nouvellement crée (0 pour non, 1 pour oui), et le nom de l'utilisateur.

  Le module dissocie l'espace de nom de session du parent. Un mount/umount est effectué dans l'espace de nom du parent.

   /etc/security/namespace.conf spécifie quels répertoires sont poly-instanciés, comment ils sont poly-instanciés, comment l'instance sera nommé, et les utilisateurs pour qui la poly-instatiation sera effectuée.

  Le format de /etc/security/namespace.conf:

  polydir instance_prefix method list_of_uids

polydir est un chemin absolu du répertoire à poly-instancier. La chaîne $HOME est remplacée avec le home de l'utilisateur, et $USER par le nom d'utilisateur. Ce champs ne peut pas être vide
instance_prefix chaîne utilisée pour construire le chemin pour l'instanciation de polydir. En fonction de la méthode de poly-instanciation
method est la méthode utilisée pour la poly-instanciation. Ce champs ne peut pas être vide. Peut être:

        user pour une poly-instaciation basé sur le nom d'utilisateur
        level pour une poly-instanciation basé sur le niveau MLS sur processus et le nom d'utilisateur
        context pour une poly-instanciation basé sur le contexte de sécurité du processus et le nom d'utilisateur
        tmpfs pour monter le système de fichier tmpfs comme instance de répertoire
        tmpdir pour créer un répertoire temporaire comme instance de répertoire qui est supprimé quand l'utilisateur ferme sa session
        context et level sont disponible uniquement avec SELinux.

list_of_uids est une liste séparée par une virgule de noms d'utilisateurs pour qui la poly-instanciation n'est pas effectuée. Si ce champs est vide, s'effectue pour tous les utilisateurs si la liste est précédée par " ", la poly-instanciation est effectuée uniquement pour les utilisateurs dans la liste.

   method peut aussi contenir les flags optionnels suivant:

        create=mode,owner,group crée le répertoire poly-instancié. Les paramètres sont optionnels. Par défaut le mode est déterminé par umask, owner est l'utilisateur et group est le groupe de l'utilisateur.
        iscript=path chemin du script d'init.
        noinit Le script d'init ne sera pas exécuté
        shared les répertoire instanciés pour les méthodes "context" et "level" ne contiendrons pas le nom d'utilisateur et seront partagés à tous les utilisateurs.

   Le répertoire où les instances poly-instanciées sont créées, doit exister et doit avoir, par défaut, le mode 0000. Cela nécessite que le parent de l'instance soit de mode 0000 et puisse être écrasé avec l'option de ligne de commande ignore_instance_parent_mode

  Avec les méthodes context et level, le contexte SELinux qui est utilisé est le contexte utilisé pour exécuter un nouveau processus comme obtenus par getexeccon. Ce contexte doit être définis par l'application appelante ou le module pam_selinux.so. Si ce contexte n'est pas définis la poly-instaciation sera basé uniquement sur le nom d'utilisateur.

OPTIONS

debug syslog les informations de debuggage
unmnt_remnt Pour les programmes comme su et newrole, le login session a déjà définis un espace de nom poly-instancié. Pour ces programmes, la poly-instanciation est effectuée basé sur le nouveau user id ou le contexte de sécurité, cependant la commande a d'abord besoin d'annuler la poly-instanciation effectuée par login. Cet argument instruit la commande d'annuler d'abord la précédente poly-instanciation avant de traiter avec la nouvelle basé sur le nouveau id/context
unmnt_only Pour les programmes de confiance qui veulent annuler un mount existant et traiter les répertoires instanciés, cet argument leur permet de démonter une instance actuellement montée.
require_selinux si SELinux n'est pas activé, retourne une erreur
gen_hash Au lieu d'utiliser la chaîne de contexte de sécurité pour le nom de l'instance, génère et utilise son hash md5
ignore_config_error Si une ligne dans le fichier de configuration correspondant à un répertoire poly-instancié contient une erreur de format, ignore le traitement de la ligne suivante. Sans cette option, pam va retourner une erreur au programme appelant, forçant à terminer la session
ignore_instance_parent_mode Les répertoires parents sont supposés avec le mode 000. En utilisant cette option, un administrateur peut choisir d'ignorer le mode du parent. À utiliser avec précaution vu que cela réduit le but d'isolation et de sécurité de la poly-instanciation
no_unmount_on_close Pour certain programmes de confiance comme newrole, la session ouverte est appelée depuis un processus enfant alors que le parent ferme la session. Pour ces commandes, utiliser cette option pour instruire pam_close_session de ne pas démonter le répertoire poly-instancié dans la parent.
use_current_context utile pour les services qui n'utilisent pas pam_selinux pour changer le contexte SELinux avec l'appel setexeccon. Le module va utiliser le contexte SELinux par défaut de l'utilisateur pour la poly-instanciation level et context

   ne fournis que le type de module session. Ce module ne doit pas être appelé depuis un processus multithread.

Valeurs retournées

PAM_SUCCESS espace de nom définit avec succès
PAM_SERVICE_ERR erreur inattendue
PAM_SESSION_ERR erreur de configuration inattendue

Exemples

exemple de ligne dans /etc/security/namespace.conf
/tmp /tmp-inst/ level root,adm
/var/tmp /var/tmp/tmp-inst/ level root,adm
$HOME $HOME/$USER.inst/inst- context
ligne à placer dans une fichier de config
session required pam_namespace.so [arguments]
^
06 octobre 2010

htmlpdflatexmanmd




pam_nologin

pam_nologin

Empêche les login non-root

   pam_nologin empêche les utilisateurs de se logger sur le système quand /var/run/nologin ou /etc/nologin existent. Le contenu du fichier est affiché à l'utilisateur. Ce module n'a pas d'effet sur l'utilisateur root. Fournis les types de module auth et account

OPTIONS

file=/path/nologin utilise ce fichier au lieu /var/run/nologin ou /etc/nologin
successok Retourne PAM_SUCCESS si aucun fichier n'existe, renvoie PAM_IGNORE par défaut

Valeurs retournées

PAM_AUTH_ERR L'utilisateur n'est pas root et /etc/nologin existes, l'utilisateur est permit à se logger.
PAM_BUF_ERR Erreur de tampon mémoire
PAM_IGNORE Valeur retournée par défaut
PAM_SUCCESS soit l'utilisateur est root, soit le fichier nologin n'existe pas
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

exemple d'utilisation dans /etc/pam.d/login
auth required pam_nologin.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_permit

pam_permit

Permet de toujours autoriser l'accès

   Dans le cas d'une authentification, le nom d'utilisateur est nobody si l'application n'est fournis pas un. Ce module est dangereux.

Exemples

Ajouter cette ligne dans les entrées other pour désactiver la gestion des comptes, mais continue de permettre aux utilisateurs de se logger
account required pam_permit.so
^
12 février 2012

htmlpdflatexmanmd




pam_pkcs11

pam_pkcs11

Module PAM d'authentification via une librairie PKCS #11

   Module PAM pour faire de l'authentification au moyen d'un certificat X509 au travers d'une librairie PKCS #11. Pour la vérification des certificats utilisateurs, le certificat de l'autorité stocké localement et la CRL en ligne ou locale sont utilisés. Les modules PKCS #11 doivent remplir les prérequis de RSA Asymmetric Client Signing Profil. Pour permettre au propriétaire d'un certificat de se connecter, pam_pkcs11 utilise des modules appelés des mappers, qui effectuent des mappages cert-to-login.

Configurer le package

1. créer le répertoire de base /etc/pam_pkcs11/
2. Copier ${base}/etc/pam_pkcs11.conf.example dans /etc/pam_pkcs11/ et le renommer en /etc/pam_pkcs11/pam-pkcs11.conf
3. créer /etc/pam_pkcs11/crls/ et /etc/pam_pkcs11/cacerts/. Le répertoire tools/ fournis un outil pkcs11_make_hask_link qui peut être utilisé pour créer les fichiers de hash pour chaque fichier certificat et crl valide.
4. Choisir un ou plusieurs mappers à installer, les configurer.
5. Éditer et configurer /etc/pam.d/xxx
6. Utiliser pkcs11_inspect et pklogin_finder pour voir si vous pouvez lire le certificat et effectuer un mappage correct
7. tester un login.

Configurer pam_pkcs11

la configuration de pam-pkcs11 se fait en 2 étapes:
1. configurer pam-pkcs11
2. Configurer les options PAM.

Vous devez connaître

- quel module PKCS #11 vous allez utiliser, et son fichier
- quels mappers vous voulez et comment le créer et l'éditer
- Les fichiers de l'authorité de certification et le fichier de révocation
- Une liste d'utilisateurs autorisés à se connecter, et leur certificats correspondant.

Spécifier la CRL et la CA

   pam-pkcs11 a besoin d'une liste d'authorité de certification reconnue pour valider l'utilisateur. Celà s'applique également à la CRL :

1. Créer les répertoire ca_dir et crl_dir en accord avec le fichier de configuration
2. Copier les certificats de la CA au format DER ou PEM
3. Créer un hash link vers les certificats CA, fournis avec pkcs11_make_hash_link. Noter que openSSL doit être installé :
cd /etc/pam_pkcs11/cacerts
/usr/bin/pkcs11_make_hash_link
4. Répéter la procédure pour la CRL
5. Sélectionner la stratégie de vérification de certificat (cert_policy)

   NOTE : Du à des limitations de librairie OpenSSL, les certificats de la CA doivent résider dans le système de fichier local.

Un fichier de map a la syntaxe suivante:
Certificate1 data -› login1
Certificate2 data -› login2
Certificate3 data -› login3
Ce fichier est parsé du début àla fin et la première occurence qui match est retournée.

Configuration PAM

   Configurer les fichiers pam.d

  auth sufficient pam_pkcs11.so ...

OPTIONS

debug mode debug
err_display_time Secondes à attendre après un message d'erreur pour lire le message
config_file Spécifier le fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
nullok Autorise les mots de passe vide
use_first_pass Ne demande pas le mot de passe à l'utilisateur, mais le prend depuis le PAM_items.
try_first_pass Ne demande pas le mot de passe à l'utilisateur à moins que PAM_(OLD)AUTHOK ne soit pas mis.
use_authok Comme try_first_pass mais échoue si le nouveau PAM_AUTHOK n'a pas été précédemment mis.
pkcs11_module=‹file› Nom de fichier du module PKCS11 (défaut : /etc/pam_pkcs11/pkcs11_module.so)
slot_num=‹nb› Numéro de slot à utiliser (défaut = 0 = utiliser le premier slot disponible)
ca_dir=‹path› Répertoire contenant les certificats CA (défault : /etc/pam_pkcs11/cacerts/)
crl_dir=‹path› Répertoire contenant la CRL (défault : /etc/pam_pkcs11/crls/)
cert_policy=none, ca, signature, crl_online, crl_offline, crl_auto Spécifier la stratégie de vérification par défaut.

Utiliser la fonction d'auto-détection de LOGIN

   Depuis pam-pkcs11-0.4.2 pam-pkcs11 peut déduire le username depuis le certificat utilisateur sans utiliser le login prompt.

  Quand pam_get_user() retourne null ou une chaîne vide, pam-pkcs11 va alors utiliser la fonction ’find’ du mapper au lieu du match normal. Si le finder retourne un succès, le username est définit avec pam_set_item(PAM_USER) et PAM_AUTH_OK est retourné.

Il y’a 2 manières d’utiliser cette fonctionnalité :
a. Patcher gdm et login pour détecter la présence d’un carte et retourner null comme nom d’utilisateur
b. Utiliser une version non patchée et entrée un espace pour login et entrée pour gdm.
^
12 février 2012

htmlpdflatexmanmd




pam_pkcs11.conf

pam_pkcs11.conf

fichier de configuration pour pam_pkcs11

   Le fichier de configuration utilise la librairie scconf. Les paramètres et données sont groupées dans des blocks. ils peuvent être imbriqués.

Un fichier de configuration pam_pkcs11 ressemble à:
pam-pkcs11
    global options
    [...]
    use_pkcs11_module = pkcs11 module to be used
    pkcs11_module module1 {
        module1 specific options
    }
    pkcs11_module module2 {
        module2 specific options
    }
    [...]
    use_mappers = mapper1, mapper2,... ;
    mapper mapper1 {
        mapper1 specific options
    }
    mapper mapper2 {
        mapper2 specific options
    }
    [...]
    mapper mapperN {
        mapperN specific options
    }
}

Exemple de fichier pam_pkcs11.conf
pam_pkcs11 {
    nullok = true ; # Allow empty passwords
debug = true ; # Enable debugging support.
    use_first_pass = false ; # Do not prompt for the passwords but take them from the PAM_ items instead
    try_first_pass = false ; # Do not prompt for the passwords unless PAM_(OLD)AUTHTOK is unset.
    use_authtok = false ; # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set (intended for stacking password modules only).
    use_pkcs11_module = opensc ; # Filename of the PKCS #11 module. The default value is "default"
    
pkcs11_module opensc {
    module = /usr/lib/opensc-pkcs11.so ;
    description = "OpenSC PKCS#11 module" ;
    slot_description = "none" ; # spécifier le slot à utiliser. préférer cette option à slot_num.
    # slot_num = 0 ; # spécifier soit slot_description, soit slot_num.
    ca_dir = /etc/pam_pkcs11/cacerts ; # répertoire contenant les certificats de l’autorité au format pem ou asn1 oui des liens hash.
    crl_dir = /etc/pam_pkcs11/crls ; # répertoire contenant la CRL offline
    support_threads = false ; # certaines librairies supportent le multi-thread
    cert_policy = ca,signature ; # définis la vérification de certificat
    # none aucune vérification
    # ca vérfication de la CA
    # crl_online télécharge la CRL
    # crl_offline utilise la crl offline
    # crl_auto tente d’abord la online, puis la offline
    # signature vérifie la signature
    token_type = "Smart card" ; # spécifie le type de token. sera utilisé dans le message de prompt.
    pkcs11_module etoken { # Aladdin eTokenPRO 32
        module = /usr/local/lib/libetpkcs11.so
        description = "Aladdin eTokenPRO-32" ;
    
        slot_num = 0 ;
        support_threads = true ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = ca,signature ;
    }
    pkcs11_module nss { # NSS (Network Security Service) config
        nss_dir = /etc/ssl/nssdb ;
        crl_policy = none ;
    }
    pkcs11_module default { # Default pkcs11 module
        module = @libdir@/pam_pkcs11/pkcs11_module.so ;
        description = "Default pkcs#11 module" ;
        slot_num = 0 ;
        support_threads = false ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = none ;
    }
    use_mappers = digest, cn, pwent, uid, mail, subject, null ;    # spécifie les mappers à utiliser:
        # subject    Sujet du certificat
        # pwent     CN ou gecos
        # ldap        mapper LDAP
        # opensc    Cherche le certificat dans ${HOME}/.eid/authorized_certificates
        # openssh    Cherche la clé public du certificat dans ${HOME}/.ssh/authorized_keys
        # mail        compare le champs email du certificat
        # ms        Utilise l’UPN
        # krb        Compare avec le Kerberos Principal Name
        # cn        Compare le CN
        # uid        Compare l’UID
        # digest    Certificat Digest
        # generic    Contenu définis par l’utilisateur
        # null        blind access/deny mapper
    mapper_search_path = @libdir@/pam_pkcs11 ;    # chemin des module mapper.
    mapper subject {                # Mapper le sujet du certificat pour le login, fournis dans un fichier sous la forme "Subject -› login"
        debug = false ;
        #module = @libdir@/pam_pkcs11/subject_mapper.so ;
        module = internal ;
        ignorecase = false ;
        mapfile = file :///etc/pam_pkcs11/subject_mapping ;
    }
    mapper pwent {                # map le CN à getpwent()
        debug = false ;
        ignorecase = false ;
        module = internal ;
        #module = @libdir@/pam_pkcs11/pwent_mapper.so ;
    }
    mapper ldap {                # mapper d’annuaire
        debug = false ;
        module = @libdir@/pam_pkcs11/ldap_mapper.so ;
        ldaphost = "" ;                 # fqdn du serveur ldap (utilise l’URI ldap pour en spécifier plusieurs)
        ldapport = ;                 # port du serveur ldap s’il n’est pas donné dans l’URI
        URI = "" ;                # list d’URI utilisés dans l’ordre
        scope = 2 ;                 # scope de recherche : 0 (base), 1 (one), 2 (sub)
        binddn = "cn=pam,o=example,c=com" ;     # DN du bind. doit avoir un accès en lecture
        passwd = "" ;                 # password du binddn
        base = "ou=People,o=example,c=com" ;    # base de recherche
        attribute = "userCertificate" ;        # attribut qui contient le certificat
        filter = "(&(objectClass=posixAccount)(uid=%s))" # Filtre de recherche pour les entrées utilisateurs ( doit seulement laisser passer l’entrée pour le login utilisateur )
        ssl = tls                # off (désactiver), tls (activer tls), on|ssl (activer ssl)
        tls_randfile =                 # chemin de la source entropie
        tls_cacertfile = /etc/ssl/cacert.pem    # Chemin vers le certification pour l’authentification du pair
        tls_cacertdir =                # Répertoire contenant les certificats X509 pour l’authentification du pair
        tls_checkpeer = 0            # 0 ou 1. spécifie de vérifier le certificat.
        tls_ciphers =                 # Chiffrement à utiliser
        tls_cert = ...                # Chemin du fichier contenant le certificat local pour l’authentification TLS client
        tls_key = ...                # Chemin du fichier contenant la clé privée pour l’authentification TLS client
    }
    mapper opensc {                 # recherche les certificats depuis $HOME/.eid/autorized_certificates qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/opensc_mapper.so ;
    }
    mapper openssh {                # Cherche les clés publique dans $HOME/.ssh/authorized_keys qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/openssh_mapper.so ;
    }
    mapper mail {                # Compare le champ email du certificat
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/mail_mapper.so ;
        mapfile = file :///etc/pam_pkcs11/mail_mapping ;    # Déclarer un fichier de map, ’empty’ ou vide pour ne pas utiliser de fichier de map
        ignorecase = true ;            # ignorer la casse
        ignoredomain = false ;            # Vérifie le domaine mx. en utilisant un fichier de map, cette option est ignorée.
    }
    mapper ms {                    # utilise l’UPN (login@AD_domain)
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/ms_mapper.so ;
        ignorecase = false ;
        ignoredomain = false ;
        domain = "domain.com" ;
    }
    mapper krb {                # Compare avec le principal kerberos
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/krb_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper cn {                    # le CN est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/cn_mapper.so ;
        ignorecase = true ;
        # mapfile = file :///etc/pam_pkcs11/cn_map ;
        mapfile = "none" ;
    }
    mapper uid {                # l’uid (s’il existe) est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/uid_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper digest {                # Evalue le digest du certificat et le map dans un fichier
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/digest_mapper.so ;
        algorithm = "sha1" ;             # Algorithme utilisé pour évaluer le digest ("null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160")
        mapfile = file :///etc/pam_pkcs11/digest_mapping ;
        # mapfile = "none" ;
    }
    mapper generic {                # mapper de contenu générique
        debug = true ;
        #module = @libdir@/pam_pkcs11/generic_mapper.so ;
        module = internal ;
        ignorecase = false ;            # ignirer la casse
        cert_item = cn ;             # ( "cn" , "subject" , "kpn" , "email" , "upn" ou "uid" )
        mapfile = file :///etc/pam_pkcs11/generic_mapping ;
        use_getpwent = false ;            # utiliser petpwent() pour mapper le login
    }
    mapper null {                # Pas de mappage. Quand un utilisateur match à NULL ou nobody
        debug = false ;
        # module = @libdir@/pam_pkcs11/null_mapper.so ;
        module = internal ;
        default_match = false ;            # match toujours (true) ou échoue toujours (false)
        default_user = nobody ;            # en cas de match, retourner cet utilisateur
    }
}

^
06 octobre 2010

htmlpdflatexmanmd




pam_pwhistory

pam_pwhistory

Autoriser l'accès en utilisant le fichier .pwhistory

   Ce module sauve les derniers mots de passe pour chaque utilisateur dans le but de forcer l'historique de changement de mot de passe et empêcher l'utilisateur d'alterner entre les même mots de passe trop fréquemment. Ce module ne fonctionne pas avec kerberos. En général, il n'a aucun sens en conjonction avec NIS ou LDAP, vu que les anciens mot de passe sont stockés sur la machine local et ne sont pas disponible sur une autre machine. Ne fournis que le type de module password.

OPTIONS

debug syslog les informations de debuggage
use_authtok En changeant de mot de passe, force à utiliser le nouveau mot de passe fournis par un module précédent (par exemple pam_cracklib)
enforce_for_root La vérification est forcée également pour root
remember=N Sauve les derniers N mots de passe dans /etc/security/opasswd. Défaut 10.
retry=N Demande à l'utilisateur N fois avant de retourner une erreur. Défaut 1.
authtok_type=STRING voir pam_get_authtok pour plus de détails

Valeurs retournées

PAM_AUTHTOK_ERR Aucun nouveau motde passe n'a été rentré, l'utilisateur a annulé le changement demot de passe ou le nouveau mot de passe ne peut pas être changé
PAM_IGNORE l'historique des mots de passe est désactivé
PAM_MAXTRIES Le mot de passe a été rejeté trop de fois
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

exemple de section password
password required pam_pwhistory.so
password required pam_unix.so use_authtok
En combinaison avec pam_cracklib
password required pam_cracklib.so retry=3
password required pam_pwhistory.so use_auththok
password required pam_unix.so use_authtok
^
16 novembre 2010

htmlpdflatexmanmd




pam_radius_auth

pam_radius_auth

Authentification auprès d'un serveur Radius

OPTIONS

debug syslog des informations détaillées
use_first_pass Récupère le mot de passe depuis un précédant module. S'il ne peut récupérer de mot de passe, échoue.
try_first_pass Récupère le mot de passe depuis un précédant module. S'il ne peut récupérer de mot de passe, le demande à l'utilisateur
skip_passwd Ne demande pas de mot de passe, même si aucun n'a été trouvé. envoie le précédent s'il en existe un ou envoie un mot de passe NULL.
conf=foo Fichier de configuration à utiliser. défaut : /etc/raddb/server
client_id=bar Envoie un Attribut RADIUS NAS-Identifier avec la chaîne spécifiée. si client_id n'est pas spécifié, le type PAM_SERVICE est utilisé ('login', 'su', 'passwd', etc.) Peut être désactivé avec client_id=
retry=# Définit le nombre de tentatives.
use_authok Force l'utilisation d'un mot de passe précédemment entré. Nécessaire pour la vérification de la complexité des mots de passe, par exemple, en utilisant cracklib.
ruser si PAM_USER est root, utilise la valeur de PAM_RUSER au lieu de PAM_USER pour déterminer le nom d'utilisateur à authentifier via RADIUS. Celà permet à su d'agir comme sudo
localifdown retourne PAM_IGNORE au lieu de PAM_AUTHINFO_UNAVAIL si RADIUS auth échoue à cause d'une indisponibilité réseau.
accounting_bug Utilisé, le vecteur de réponse de compte n'est pas validé. (pour la compatibilité de très vieux serveur RADIUS)

Exemples

auth sufficient /lib/security/pam_radius_auth.so
account sufficient /lib/security.pam_radius_auth.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_rhosts

pam_rhosts

Autorise l'accès en utilisant le fichier .rhosts

   Ce module effectue une authentification réseau standard pour les services, comme utilisé par les implémentations traditionnels de rlogin et rsh.

  Le mécanisme d'authentification de ce module est basé sur le contenu de 2 fichiers, /etc/hosts.equiv et/ou /.rhosts. Premièrement, les hôtes listés dans le fichier sont traités comme équivalent au localhost. Ensuite, les entrées dans la copie de l'utilisateur du fichier est utilisé pour mapper les paires "remote-host remote-user" au compte utilisateur sur l'hôte courant. L'accès est donné à l'utilisateur si son hôte est présent dans /etc/hosts.equiv et son compte distant identique à celui local, ou si le compte distant a une entrée dans le fichier de configuration personnel. Ne fournit que le type de module auth.

OPTIONS

debug Affiche des informations de debuggage
silent mode silencieux
superuser=account définit account en tant que root

Exemples

Pour autoriser l'acès à un utilisateur par /etc/hosts.equiv ou .rhosts pour rsh, ajouter les lignes suivantes dans /etc/pam.d/rsh
auth required pam_rhosts.so
auth required pam_nologin.so
auth required pam_env.so
auth required unix.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_rootok

pam_rootok

Obtenir un accès root

   pam_rootok authentifie l'utilisateur si sont uid est 0. Les applications qui sont crées setuid-root retiennent généralement l'UID de l'utilisateur mais se lancent avec l'effective UID. C'est le real UID qui est vérifié. Fournit les types de module auth, acct et password.

Valeurs retournées

PAM_SUCCESS l'UID est 0
PAM_AUTH_ERR l'UID n'estpas 0

Exemples

Dans le cas de l'application su, l'usage historique est de permettre au superuser d'adopter l'identité d'un utiliser inférieur sans utiliser de mot de passe. Pour obtenir de fonctionnement avec PAM les lignes suivantes sont necessaires dans /etc/pam.d/su
auth sufficient pam_rootok.so
auth required pam_unix.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_securetty

pam_securetty

Limite le login root aux périphériques spéciaux

   pam_securtty permet les logins root seulement si l'utilisateur est loggé sur un tty sécurisé, comme définis par la liste dans /etc/securetty. Il vérifie également que /etc/securetty est un fichier texte et n'est pas writable. Ce module n'a pas d'effet sur les utilisateurs non-root et nécessite que l'application renseigne PAM-TTY correctement. Ne fournit que le type de module auth.

Valeurs retournées

PAM_SUCCESS l'utilisateur est autorisé à continuer l'authentification
PAM_AUTH_ERR Authentification rejetée
PAM_INCOMPLETE Une erreur d'application s'est produite
PAM_SERVICE_ERR erreur s'est produite
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth required pam_securetty.so
auth required pam_unix.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_selinux

pam_selinux

Définit le contexte de sécurité par défaut

   Quand une application ouvre une session en utilisant pam_selinux, le shell exécuté va se lancer dans un contexte de sécurité par défaut, ou si l'utilisateur choisit le fichier pam permet le contexte de sécurité sélectionné. Ajouter pam_selinux dans un fichier pam peut forcer les autres modules à changer leur mode. L'option close et open aident à mitiger le problème. l'option close va seulement forcer la portion close de pam_selinux a s'exécuter, et pam_open la portion open. Vous pouvez ajouter pam_selinux dans le fichier de configuration 2 fois. Ne fournit que le type de module session.

OPTIONS

close Exécute seulement la portion close_session à s'exécuter
debug syslog les information de debuggage
open exécute seulement laportion open_session du module
nottys ne tente pas de paramétrer le contexte de sécurité des tty
verbose tente d'informer l'utilisateur quand le contexte de sécurité est définis
select_context tente de demander à l'utilisateur un rôle de contexte de sécurité personnalisé. Si MLS est on demande aussi le niveau de sensibilité
env_param Tente d'obtenir un rôle de contexte de sécurité custom depuis l'environnement PAM. si MLS est on obtient également le niveau de sensibilité. Cette option est l'option select_context sont mutuellement exclusif. Les variables d'environnement PAM sont SELINUX_ROLE_REQUESTED, SELINUX_LEVEL_REQUESTED, et SELINUX_USE_CURRENT_RANGE. ce dernier s'il est définis à 1 force le module a fonctionner comme si use_current_range a été spécifié sur la ligne de commande.
use_current_range utilise le niveau de sensibilité du processus courant pour le context utilisateur au lieu du niveau par défaut. Supprime également la demande du niveau de sensibilité ou de tenter de l'obtenir via l'environnement PAM

Valeurs retournées

PAM_AUTH_ERR Ne peut pas récupérer ou définir de contexte valide
PAM_SUCCESS le contexte de sécurité a été définis
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth required pam_unix.so
session required pam_permit.so
session optional pam_selinux.so
^
08 mai 2017

htmlpdflatexmanmd




pam_sepermit

pam_sepermit

Module PAM pour autoriser/refuser le login en fonction de l'état d'enforcement SELinux

   Quand un utilisateur se log et match une entrée dans le fichier de configuration, il est autorisé seulement quand SELinux est en mode enforcing, sinon l'accès lui est refusé. Pour les utilisateurs qui ne matchent pas dans le fichier de configuration, le module retourne PAM_IGNORE.

OPTIONS

debug mode debug
conf=/path/to/conf/file Chemin alternatif du fichier de configuration

   Ce module fournis les type auth et account

Valeurs de retour

PAM_AUTH_ERR SELinux est désactivé ou en mode permissif et l'utilisateur match.
PAM_SUCCESS SELinux est en mode enforcing et l'utilisateur match
PAM_IGNORE L?utilisateur ne match pas
PAM_USER_UNKNOWN Le module n'est pas capable de déterminer le nom utilisateur
PAM_SERVICE_ERR Erreur durant la lectule du fichier de configuration

Exemple

auth [success=done ignore=ignore default=bad] pam_sepermit.so
auth required pam_unix.so
account required pam_unix.so
session required pam_permit.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_shells

pam_shells

Vérifie les shells de login valides

   pam_shells autorise l'accès au système si le shell utilisateur est listé dans /etc/shells. Il vérifie également si /etc/shells est un fichier texte et n'est pas writable. Ne fournis que les type de module auth et account.

Valeurs retournées

PAM_AUTH_ERR l'accès a été refusé
PAM_SUCCESS l'accès est autorisé
PAM_SERVICE_ERR le module n'est pas capable d'obtenir le nom de l'utilisateur

Exemples

auth required pam_shells.so
^
06 octobre 2010

htmlpdflatexmanmd




pam_succeed_if

pam_succeed_if

Test les caractéristiques des comptes

   pam_succeed_if est conçu pour réussir ou non l'authentification en se basant sur les caractéristiques du compte de l'utilisateur. Une utilisation est de sélectionner si d'autres modules sont chargés en fonction de ce test.

OPTIONS

debug syslog les informations de debuggage
use_uid Évalue les conditions en utilisant le compte utilisateur de l'application au lieu de l'utilisateur qui s'authentifie
quiet mode silencieux
quiet_fail ne log pas les echecs
quiet_success ne log pas les réussites
audit syslog les utilisateurs inconnus

Conditions

   Les conditions sont composés de 3 mots un champs, un test et une valeur de test.

field ‹ number
field ‹= number
field eq number
field ›= number
field › number
field ne number
field = string
field != string
field = glob
field in item:item :...
user ingroup group
user notingroup group
user innetgr netgroup
user notinnetgr group

Exemples

Pour émuler de principe de pam_wheel, excepté qu'il ne revient pas au group 0
auth required pam_succeed_if.so quiet user ingroup wheel
charge seulement les autres modules si l'UID est › 500
type [ default=1 success=ignore ] pam_succeed_if.so quiet uid › 500
type required othermodule.so arguments
^
07 octobre 2010

htmlpdflatexmanmd




pam_tally2

pam_tally2

Module compteur de login

   Ce module maintient un compteur de tentative d'accès, peut ré-initialiser ce compteur en cas de succès et peut refuser l'accès si trop de tentatives échouent.

  pam_tally2 est composé de 2 parties: pam_tally2.so et pam_tally2. Ce dernier est une application optionnelle qui peut être utilisé pour interroger et manipuler le fichier compteur. Il peut afficher le compteur de l'utilisateur, définir les compteurs individuels ou reset tous les compteurs Définir des compteurs élevés peut être utile pour bloquer les utilisateurs sans changer leur mot de passe. Par exemple, il peut être utile effacer tous les compteurs à minuit depuis un cron.

  Normalement, les tentatives échouées au compte root ne bloque pas ce compte, pour prévenir les DOS. Fournit les types de module auth et account.

Options globales

   Peuvent être utilisées par les types de module auth et account.

onerr=fail Si quelque-chose se produit (comme l'impossibilité d'ouvrir le fichier), retourne PAM_SUCCESS si onerr=succeed.
file=/path/to/counter Fichier où sont conservés les compteurs
audit log les noms d'utilisateurs qui ne sont pas trouvés
silent mode silencieux
no_log_info ne syslog rien

Options Auth

   La phase d'authentification incrémente d'abord le compteur de tentative de login et vérifie si l'utilisateur devrait avoir l'accès refusé. Si l'utilisateur est authentifié et le processus de login continus à l'appel pam_setcred, le compteur est ré-initialisé.

deny=n Refuse l'accès si le compteur excède N tentatives.
lock_time=n Refuse toujours après n secondes après qu'une tentative échoue
unlock_time=n Autorise l'accès après n secondes après une tentative échouée. Si cette option est utilisée l'utilisateur sera bloqué pendant la durée de temps spécifiée après avoir dépassé le nombre de tentative maximum. Sinon le compte est bloqué jusqu'à ce qu'il soit débloqué manuellement
magic_root Si le module est invoqué par une utilisateur d'uid=0 le compteur n'est pas incrémenté.
no_lock_time N'utilise pas le champs .fail_locktime dans /var/log/faillog pour cet utilisateur
even_deny_root Le compte root peut devenir indisponible
root_unlock_time=n Cette option implique even_root. Autorise l'accès après n secondes au compte root après une tentative échouée.
serialize Sérialise l'accès au fichier compteur utilisant les locks. Cette options peut être utilisée seulement pour les services non-multi-threads parce qu'il dépend du fcntl locking dans le fichier compteur. C'est également une bonne idée d'utiliser cette option seulement dans des configuration où le temps entre la phase auth et la phase account ou setcred n'est pas dépendant du client. Sinon le client sera capable de prévenir les authentification simultanées par le même utilisateur en prolongeant artificiellement le temps que le fichier lock.

Options Account

   La phase account ré-initialise le compteur de tentatives si l'utilisateur n'est pas root. Cette phase peut être utilisée optionnellement pour les services qui n'appellent pas pam_setcred correctement ou si le reset devrait être fait sans regarder les échecs de la phase account des autres modules.

magic_root Si le module est invoqué par un utilisateur avec uid=0 le compteur n'est pas changé. Le sysadmin devrait l'utiliser pour les services utilisateurs, comme su, sinon cet argument devrait être omis.

Valeurs retournées

PAM_AUTH_ERR option invalide, le module ne peut pas retrouver le nom d'utilisateur, compteur invalide, fichier non trouvé ou trop de logins échoués
PAM_SUCCESS Tous est ok
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Exemple de /etc/pam.d/login pour bloquer le compte au bout de 4 tentatives. Le root ne sera pas bloqué. Le compte sera débloqué après 20 minutes. Le module n'a pas à être appelé dans la phase account parce que login appelle pam_setcred correctement
auth required pam_securetty.so
auth required pam_tally2.so deny=4 even_deny_root unlock_time=1200
auth required pam_env.so
auth required pam_unix.so
auth required pam_nologin.so
account required pam_unix.so
password required pam_unix.so
session required pam_limits.so
session required pam_unix.so
session required pam_lastlog.so nowtmp
session optional pam_mail.so standard
^
07 octobre 2010

htmlpdflatexmanmd




pam_time

pam_time

Contrôle des horaires d'accès

   pam_time n'authentifie pas l'utilisateur, mais restreint l'accès à un système et/ou des applications à des horaires particulières. Pour que ce module fonctionne correctement, le fichier /etc/security/time.conf doit être présent et correctement formaté. Fournit les types de modules account. La syntaxe des lignes du fichier est sous la forme:

  services;ttys;users;times

services est une liste logique de noms de services PAM
ttys Liste logique de nom de terminaux
users Liste d'utilisateurs ou netgroupes
times Utilisé pour indiquer à quels moment la règle s'applique. Le format est une liste de jour/plage-de-temps. Les jours sont spécifié par une séquence de 2 caractères, MoTuSa par exemple signifie Monday Tuesday et Saturday. Noter que les jours qui sont répétés s'annule: MoMo = aucun jour, MoWk = toute la semaine sauf lundi. peut être Mo Tu We Th Fr Sa Su Wk Wd Al. On peut préfixer les jours avec ' !' pour spécifier "tout sauf". La plage de temps est sous la forme de 2 fois "HHMM".

OPTIONS

debug syslog les informations de debuggage
noaudit ne report pas les logins refusés

Valeurs retournées

PAM_SUCCESS l'accès est autorisée
PAM_ABORT Problèmes de données
PAM_BUF_ERR erreur tampon mémoire
PAM_PERM_DENIED L'accès est refusé
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Tous les utilisateurs sauf root n'ont pas accès aux login console en permanence
login;tty* & !ttyp*;!root;!Al0000-2400
Les jeux configurés pour utiliser PAM ne sont accessibles qu'en dehors des heures de travail, mais ne s'applique pas à l'utilisateur waster
games;*;!waster;Wd0000-2400 | Wk1800-0800
^
08 octobre 2010

htmlpdflatexmanmd




pam_timestamp

pam_timestamp

Authentifie avec le cache d'authentification

   pam_timestamp met en cache les tentatives réussis de login, et permet d'utiliser une tentative réussit récente comme base de l'authentification. C'est similaire au mécanisme sudo. il utilise les fichiers dans /var/run/sudo/. Fournis les types de module auth et session.

OPTIONS

timestamp_timeout=number Spécifie le nombre de secondes que le timestamp reste valide après la dernière modification (défaut 300secondes)
verbose Tente d'informer l'utilisateur quand l'accès est donné.
debug syslog les informations de debuggage.

Valeurs retournées

PAM_AUTH_ERR Le module ne peut pas récupérer le nom d'utilisateur ou aucun fichier timestamp n'a été trouvé
PAM_SUCCESS tout est ok
PAM_SESSION_ERR Le fichier timestamp ne peut pas être créé ou mis à jour

Exemples

auth sufficient pam_timestamp.so verbose
auth required pam_unix.so
session required pam_unix.so
session optional pam_timestamp.so
^
09 novembre 2010

htmlpdflatexmanmd




pam_umask

pam_umask

Définis de masque de création de fichier

   pam_umask définit le masque de création de fichier de l'environnement en cours. Ne fournis que le type de module session. Le umask affecte les permissions par défaut assignées aux fichiers nouvellement crées. pam_umask tente d'obtenir la valeur umask depuis les emplacements suivant, dans l'ordre:

        - umask = argument
        - umask = entrée des champs utilisateur GECOS
        - pri= Entrée des champs utilisateurs GECOS
        - ulimit= entrée des champs utilisateur GECOS
        - UMASK= entrée depuis /etc/default/login
        - Entrée UMASK depuis /etc/login.defs

OPTIONS

debug Affiche les informations de debuggage
silent N'affiche pas de messages d'information
usergroups Si l'utilisateur n'est pas root et que le nom d'utilisateur est le même que le nom du groupe principal, les bits umask du groupe sont définit comme ceux du propriétaire (exemple : 022 -› 002, 077 -› 007)
umask=mask Définit le mask pour les nouveau fichiers (umask) au masque & 0777. La valeur est interprétée en octal

Valeurs retournées

PAM_SUCCESS Le nouveau umask a été défini avec succès
PAM_SERVICE_ERR Aucun nom d'utilisateur n'a été donné
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour définir un umask spécifique au login
session optional pam_umask.so umask=0022
^
09 novembre 2010

htmlpdflatexmanmd




pam_unix

pam_unix

Authentification pas mot de passe traditionnel

   pam_unix.so est le module d'authentification par défaut. Il utilise les appels standard depuis les librairies système basé sur les éléments shadow suivant: expire, last_change, max_change, min_change, warn_change. Pour le dernier, il peut empêcher l'utilisateur de changer son mot de passe, ou attendre qu'il ai changé son mot de passe. Par défaut ce module n'autorise pas l'accès si le mot de passe n'est pas définit.

  unix_chkpwd est fournit pour vérifier le mot de passe de l'utilisateur quand il est stocké dans une base protégée en lecture.

  Le composant password de ce module effectue la mise à jour du mot de passe de l'utilisateur.

  Le composant session de ce module log quand un utilisateur se log ou quitte le système.

OPTIONS

debug syslog les informations de debuggage
audit un peu plus extrême que debug
nullok permet l'accès à une utilisateur sans mot de passe
try_first_pass Avant de demande le mot de passe à l'utilisateur, le module essaye le mot de passe précédemment stacké.
use_first_pass Force le module à utiliser un mot de passe précédemment stacké et ne prompt jamais l'utilisateur.
nodelay Peut être utilisé pour décourager le composant d'authentification de demander un délai quand l"authentification échoue.
use_authok Le changement de mot de passe force le module à remplacer le nouveau mot de passe par celui fournit par un mot de passe précédemment stacké. C'est utilisé par exemple avec le module pam_cracklib
not_set_pass Cet argument est utilisé pour informer le module de ne pas prêter attention ou de rendre les ancien ou les nouveaux mot de passe depuis/vers d'autres module de mot de passe.
nis NIS RPC est utilisé pour définir les nouveau mot de passe
remember=n les dernier n mots de passe pour chaque utilisateurs sont sauvés dans /etc/security/passwd dans le but de forcer l'historique de changement de mot de passe et d'empêcher l'utilisateur de réutiliser les même mots de passe trop fréquemment.
shadow tente de maintenir un shadow based system
md5 crypte en md5 les nouveau mots de passe
bigcrypt crypte avec DEC C2
sha256 crypte avec SHA256
sha512 crypte avec SHA512
blowfish crypte avec blowfish
rounds=n Définit le nombre de passe des algorithmes SHA256, SHA512 et blowfish broken_shadow
ignore les erreurs en lisant les informations shadow de l'utilisateur dans le module de gestion de compte. minlen=n
Définis la longueur minimum du mot de passe. pour DES max=8

   Les arguments invalides sont syslog(3). Retourne tous les types de module.

Exemples

exemple d'utilisation dans /etc/pam.d/login: authentifier l'utilisateur
auth required pam_unix.so
s'assuer que le compte etle mot de passe sont actifs
account required pam_unix.so
change le mot de passe, mais vérifie d'abord la force avec pam_cracklib
password required pam_cracklib.so retry=3 minlen=6 difok=3
password required pam_unix.so use_authok nullok md5
session required pam_unix.so
^
11 novembre 2010

htmlpdflatexmanmd




pam_userdb

pam_userdb

Authentification auprès d'un base de données

   pam_userdb est utilisé pour vérifier un user/password avec des valeurs stockées dans une DB Berkeley. Ne fournis que les types de module auth et account.

OPTIONS

crypt=crypt Indique si le mot de passe est stocké en crypté et en clair dans la DB. S'il est crypté, le mot de passe devrais être stocké dans le DB sous la forme crypt(3).
db=/path/database Spécifie le chemin de la db à utiliser
debug Affiche des informations de debuggage
dump dump toutes les entrées dans la db dans le log.
icase la vérification du mot de passe est sensible à la casse. ne fonctionne que pour les mots de passe en clair
try_first_pass Utilise le token précédemment obtenu par un autre module.
use_first_pass Utilise le token d'authentification précedemment obtenu parun autre module. Si ce token ne peut pas être obtenu, le module échoue.
unknown_ok Ne retourne pas d'erreur si l'utilisateur n'est pas dans la db.
key_only le username et le password sont concatenés ensemble dans le hash db sous la forme 'username-password" avec une valeur aléatoire.

Valeurs retournées

PAM_AUTH_ERR Authentification échouée
PAM_AUTHOK_RECOVERY_ERR Les informations d'authentification ne peut être récupérées
PAM_BUF_ERR Erreur de tampon mémoire
PAM_CONV_ERR Erreur de conversation
PAM_SERVICE_ERR Erreur dans le module
PAM_SUCCESS succès
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth sufficient pam_userdb.so icase db=/etc/dbtest.db
^
11 novembre 2010

htmlpdflatexmanmd




pam_warn

pam_warn

Log tous les éléments PAM

   pam_warn est un module qui log le service, terminal, user, remote user et remote host dans syslog(3). Ce module retourne toujours PAM_IGNORE. Ce module fournis tous les types de module.

Exemples

Si on a pas d'entrée de config pour un service, l'entrée other est utilisé. Par sécurité on refuse et on log tout
other auth required pam_warn.so
other auth required pam_deny.so
other account required pam_warn.so
other account required pam_deny.so
other password required pam_warn.so
other password required pam_deny.so
other session required pam_warn.so
other session required pam_deny.so
^
11 novembre 2010

htmlpdflatexmanmd




pam_wheel

pam_wheel

Permet l'accès root aux membres du groupe wheel

   pam_wheel permet un accès root au système si l'utilisateur est un membre du groupe wheel. Si aucun groupe avec ce nom n'existe, le module utilise le groupe avec l'ID de groupe 0. Fournit les types de module auth et account.

OPTIONS

debug Affiche des informations de debuggage
deny Renverse le sens de l'opération auth: si l'utilisateur essaye d'avoir l'accès UID 0 et est membre du groupe wheel, l'accès est refusé. si l'utilisateur n'est pas dans le groupe, retourne PAM_IGNORE.
group=name au lieu de vérifier les groupes 0 ou wheel, utilise le nom du groupe pour effectuer l'authentification
root_only ne vérifie que l'appartenance au groupe wheel
trust retourne PAM_SUCCESS au lieu de PAM_IGNORE si l'utilisateur est un membre du groupe wheel
use_uid La vérification de l'appartenance au groupe wheel est faite avec l'uid courant au lieu de l'original. (utile en passant avec su d'un compte à un autre)

Valeurs retournées

PAM_AUTH_ERR Erreur d'authentification
PAM_BUF_ERR Erreur de tampon mémoire
PAM_IGNORE La valeur retournée devrait être ignorée par PAM
PAM_PERM_DENY Permission refusée
PAM_SERVICE_ERR Ne peut pas déterminer le nom de l'utilisateur
PAM_SUCCESS succès
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Le compte root a accès par défaut (rootok), seul les membres du groupe wheel peuvent devenir root, mais l'authentification UNIX non-root s'applique
su auth sufficient pam_rootok.so
su auth required pam_wheel.so
su auth required pam_unix.so
^
11 novembre 2010

htmlpdflatexmanmd




pam_xauth

pam_xauth

Forward xauth keys between users

   pam_xauth est conçu pour forwarder les clés xauth (parfois appelées cookies) entre les utilisateurs. Sans pam_xauth, quand xauth est activé et qu'un utilisateur utilise su pour obtenir les privilèges d'un autre utilisateur, cet utilisateur n'est plus capable d'accéder à l'affichage X de l'utilisateur parce que le nouvel utilisateur n'a pas la clé necessaire pour accéder à l'affichage. pam_xauth résoud le problème en forwardant la clé. Celà veut dire par exemple, que quand vous lancez su depuis une session xterm, vous être capable de lancer des programmes X sans explicitement utiliser la commande xauth ou les fichier ./Xauthority.

  pam_xauth ne forward les clés seulement si xauth peut lister une clé connectée à la varialbe d'environnement DISPLAY. Le contrôle d'accès est fournis par /.xauth/export dans le répertoire home de l'utilisateur qui invoke et /.xauth/import dans le home de l'utilisateur cible.

OPTIONS

debug Affiche des informations de debuggage
xauthpath=/path/to/xauth Spécifie le chemin du programme xauth (par défaut /usr/X11R6/bin/xauth, /usr/bin/xauth ou /usr/bin/X11/xauth)
systemuser=UID Spécifie le plus haut UID qui sera assumé devenir l'utilisateur système. pam_xauth varefuser de forwarder aux utilisateurs avec un UID inférieur ou égal à ce nombre, excépté pour root et le "targetuser" si spécifié.
targetuser=UID Spécifie un simple UID cible quiest exempt de la vérification systemuser

   Ne fournis que le type de module session

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_PERM_DENIED permission refusée par le fichier import/export
PAM_SESSION_ERR Ne peut pas déterminer le nom d'utilisateur, l'UID ou accéder au hom de l'utilisateur
PAM_SUCCESS succès
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Exemple pour /etc/pam.d/su pour forwarder les clés xauth entre les utilisateurs
session optional pam_xauth.so
^
09 mars 2013

htmlpdflatexmanmd




parted

parted

Utilitaire de manipulation de partitions

OPTIONS

-l, -list Liste les partitions sur tous les périphériques bloc
-m, -machine Affiche une sortie parsable
-s, -script Ne demande pas confirmation
-a, -align Définis l’alignement pour les nouvelles partitions. Les types valides sont :

        none Utilise l’alignement minimum permis par le type de disque
        cylinder Aligne les partitions sur les cylindres
        minimal l’alignement est donné par la topologie du disque
        optimal Utilise l’alignement optimal comme donné par la topologie du disque.

Commandes

[device] Le périphérique bloc à utiliser
[command [options]] Commandes à exécuter. Les commandes possibles sont :

        check partition vérifie la partition donnée
        cp [source-device] source dest copie le système de fichier de la partition source sur source-device (défaut : périphérique courant) dans la partition de destination sur le périphérique courant.
        mkfs partition fs-type Créer un système de fichier : fat16, fat32, ext2, linux-swap ou reiserfs
        mklabel label-type Crée un nouveau label de disque : bsd dvh gpt loop mac msdos pc98 ou sun
        mkpart part-type [fs-type] start end Crée une partition avec un système de fichier. fs-type peut être fat16, fat32, ext2, HFS, linux-swap, NTFS, reiserfs ou ufs. part-type peut-être primary, logical ou extended
        move partition start end déplace une partition
        name partition name Définis le nom de la partition (ne fonctionne que sur les labels Max, PC98 et GPT)
        print Affiche la table de partition
        rescue start end Récupère une partition perdue localisée quelque part entre start et end
        resize partition start end Redimensionne un système de fichier dans une partition.
        rm partition supprime la partition
        select device Sélectionne le périphérique courant (peut être un périphérique disque, un périphérique raid, ou un LVM)
        set partition flag state Change l’état du flag : boot, root, swap, hidden, raid, lvm, lba et palo. state doit être soit on soit off
        unit unit définis l’unité à utiliser. Peut être s (secteur), B (octet), kB, MB, GB, TB, % (% du périphérique), cyl (cylindres) chs ou compact (mB en, entrée, human-readable en sortie)
^
07 mai 2016

htmlpdflatexmanmd




partx

partx

Annonce au kernel la présence et la numérotation des partitions d'un disque

   Demande au kernel la présence et le nombre de partitions sur les disques. En donnant un périphérique ou une image disque, partx tente de parcourir la table de partitions et de lister leur contenu. Optionnellement, il ajoute ou supprime des partitions.

   partx n'est pas un programme fdisk. Ajouter ou supprimer des partitions ne change pas le disque, il indique seulement au kernel la présence et le nombre de partitions sur le disque.

OPTIONS

-a, --add Ajoute les partitions spécifiées, ou lit le disque et ajoute toutes les partitions.
-b, --bytes Affiche la colonne SIZE en octets au lieu du format human-readable
-d, --delete Supprime les partitions spécifiées, ou toutes les partitions.
-u, --update Met à jours les partitions spécifiées
-x, --noheadings N'affiche pas la ligne d'en-tête
-l, --list Liste les partitions. Noter que tous les nombre sont en secteurs de 512 octets. Déprécié, préférer --show
-o, --ouput list Définis les colonnes de sortie pour --show et --raw.
-P, --pairs Affiche un format clé="valeur"
-n, --nr M:N Spécifie la plage de partitions. La plage peut être négative (--nr :-1 indique la dernière partition, et --nr -2:-1 signifie les 2 dernières partitions). Les plages supportées sont:

        M Spécifie seulement une partition
        M: spécifie la limite inférieur
        :N Spécifie la limite supérieur
        M:N ou
        M-N Spécifie les limites supérieur et inférieur

-r, --raw Utilise le format brut.
-s, --show Liste les partitions
-t, --type type Spécifie le type de partition (aix, bsd, dos, gpt, mac, minix, sgi, solaris_x86, sur, ultrix ou unixware).

Exemples

Affiche la partition 3 de /dev/sdb
partx --show /dev/sdb3
partx --show -nr 3 /dev/sdb3
partx --show /dev/sdb3 /dev/sdb
Liste toutes les sous-partitions de /dev/sdb3 (le périphérique est utilisé comme un disque entier)
partx --show - /dev/sdb3
Affiche le secteur de début de la partition 5 dans /dev/sdb sans en-tête
partx -o START -g --nr 5 /dev/sdb
Liste la longueur en secteurs et human-readable de la taille de la partition 5 de /dev/sda
partx -o SECTORS,SIZE /dev/sda5 /dev/sda
Ajoute toutes les partitions disponible de 3 à 5 dans /dev/sdd
partx --add --nr 3:5 /dev/sdd
Supprime la dernière partition dans /dev/sdd
partx -d --nr :-1 /dev/sdd
^
03 novembre 2011

htmlpdflatexmanmd




passwd

passwd

Modifier le mot de passe d’un utilisateur. Un utilisateur normal peut seulement changer son propre mot de passe. passwd peut également changer le compte ou la période de validité du mot de passe associé

OPTIONS

-a, --all Ne peut être utilisée qu’avec -S et permet d’afficher l’état des mots de passe pour tous les utilisateurs
-d, --delete Supprime le mot de passe
-e, --expire Annule immédiatement la validité du mot de passe d’un compte. Ceci permet d’obliger un utilisateur à changer son mot de passe à sa prochaine connexion.
-i, --inactive DUREE_INACTIVITE Permet de désactiver un compte un certain nombre de jours après que son mot de passe soit arrivé en fin de validité depuis le nombre de jours spécifié, l’utilisateur ne pourra plus se connecter.
-k, --keep-tokens Indique qu’un changement de mot de passe devrait être exécuté uniquement pour les tokens d’authentification expiré.
-l, --lock Bloque le mot de passe du compte spécifié, en ajoutant un ’ !’ au début du hash du mot de passe). Cette méthode ne désactive pas le compte, il est toujours possible de se logger en utilisant d’autres token d’authentification tel que les clés SSH. Pour désactiver un compte, utiliser usermod --expiredate 1. Les utilisateurs avec un mot de passe bloqués ne peuvent pas changer leur mot de passe.
-m, --mindays JOURS_MIN Nombre de jours minimum entre chaque changement de mot de passe. A 0, désactive cette option.
-q, --quiet mode silencieux
-r, --repository REPOSITORY change le mot de passe dans le REPOSITORY
-S, --status Affiche l’état d’un compte. Cet état est constitué de 7 champs :

        - Nom du compte
        - Si le mot de passe est bloqué (L), n’a pas de mot de passe (NP) ou as un mot de passe utilisable (P)
        - Date de dernière modification du mot de passe
        - Durée minimum avant modification
        - Durée maximum de validité
        - Durée d’avertissement
        - Durée d’inactivité
        Les durées sont exprimées en jours.

-u, --unlock Déverrouille le mot de passe du compte spécifié.
-w, --warndays DUREE_AVERTISSEMENT Fixe le nombre de jours avant que le changement de mot de passe ne soit obligatoire et durant lequel l’utilisateur est prévenu que son mot de passe arrive à expiration.
-x, --maxdays JOURS_MAX Fiche le nombre de jours pendant lesquels un mot de passe reste valable, après, le mot de passe devra être modifié.

   passwd utilise PAM pour authentifier les utilisateurs et pour changer leur mot de passe (voir /etc/pam.d/passwd)

Valeurs de retour

0 succès
1 Permission refusée
2 combinaison d’options non valable
3 échec inattendu
4 le fichier passwd est manquant
5 fichier passwd en cour d’utilisation
6 paramètre non valable pour l’option
^
09 juin 2010

htmlpdflatexmanmd




paste

paste

Écrit sur la sortie standard des lignes consistant de lignes correspondante séquentiellement de chaque fichier donné, séparés par une tabulation

OPTIONS

-s, --serial affiche les lignes d'un fichier à la fois au lieu d'une ligne de chaque fichier.
-d DELIM-LIST, --delimiters=DELIM-LIST Utilise les caractères DELIM-LIST au lieu d'une tabulation, en alternant chaque caractère.

Exemples

cat num2
1
2
cat let3
a
b
c
paste num2 let3
1 a
2 b
c
paste -s num2 let3
1 2
a b c
^
07 juillet 2010

htmlpdflatexmanmd




patchchk

patchchk

Vérifie la validité de la portabilité des noms de fichier

   Pour chaque nom, pathchk affiche un message d'erreur si une de ces conditions est vrai:

- Un des répertoires existant dans le nom n'a pas la permission de recherche.
- la longueur du nom est plus large que le maximum supporté par le système.
- la longueur d'un composant du nom est plus long que le maximum du système de fichier.

   Un nom non-existant n'est pas une erreur.

OPTIONS

-p Au lieu d'effectuer une vérification basé sur le système de fichier courant, affiche un message d'erreur si une de ces condifition est vrai:

        - Le nom de fichier est vide
        - Le nom de fichier contient des caractères en dehors du jeu de caractère portable POSIX, qui inclue les lettres et chiffres ASCII, ., ,, _, - et /.
        - La longueur du nom de fichier ou un de ses composant excède la limite POSIX.

-P Affiche un message d'erreur si un nom de fichier est vide, ou s'il contient un composant qui commence avec '-'
--portability Affiche un message d'erreur si le nom n'est pas portable sur tous les hôtes POSIX. equivalent à -p -P
^
13 février 2012

htmlpdflatexmanmd




pcscd

pcscd

Service PC/SC pour pcsclite et le framework MuscleCard

   Service PC/SC pour pcsclite et le framework MuscleCard. C’est un gestionnaire de ressource qui coordonne les communications entre les lecteur de cartes et les cartes et tokens connectés au système.

  Les pilotes de lecteur de carte série sont dans /usr/lib/pcsc/drivers. pcscd localise les pilotes en utilisant /var/lib/pcscd/reader.conf (les pilotes sont disponibles à http://www.musclecard.com/drivers.html)

  Les pilotes USB sont placés dans /usr/lib/pcscd/drivers. Vous ne devriez pas ajouter de pilote USB dans reader.conf.

Fichiers

/var/lib/pcscd/reader.conf: Fichier de configuration des lecteurs
/var/run/pcscd/pcscd.pid: process id
/usr/lib/pcsc/drivers: Répertoire des pilotes usb.

OPTIONS

-a, --apdu log les APDU et SW en utilisant la méthode de debug
-c, --config Spécifie le fichier alternatif à /var/lib/pcscd/reader.conf
-f, --foreground Ne lance pas en tâche de fond et envoie les mesage sur stderr au lieu de syslog
-d, --debug Niveau de debug
--info Utilise le niveau de log info (mode par défaut)
--error Utilise le niveau de log error
--critical Utilise le niveau de log critical
-H, --hotplug Demande à pcscd de rescanner les bus USB et relire /var/lib/pcscd/reader.conf pour détecter les lecteurs non-USB.
^
13 février 2012

htmlpdflatexmanmd




pcsc_scan

pcsc_scan

Scanner les lecteurs de carte

   Scan les lecteurs de carte à interval régulier. Il demande à pcscd la liste des lecteurs disponible. Quand une carte est insérée, il affiche diverses informations:

  Date et heure, nom du lecteur, état de la carte et évènements, ATR de la carte à l’insertion et analyse si la commande ATR_analysis est disponible

OPTIONS

-n  N’effectue pas d’analyse ATR.
^
11 février 2015

htmlpdflatexmanmd




pengine

pengine

Options qui peuvent être configurées pour le moteur de stratégie.

OPTIONS

no−quorum−policy = enum [stop] Quoi faire quand le cluster n'a pas de quorum (stop, freeze, ignore, suicide)
symmetric−cluster = boolean [true] Toutes les ressources peuvent se lancer de partout par défaut
default−resource−stickiness = integer [0]
is−managed−default = boolean [true] Définis si les ressources du cluster devaient démarrer/stopper quand demandé
maintenance−mode = boolean [false] Définis si les ressources de monitor du cluster devaient démarrer/stopper quand demandé
start−failure−is−fatal = boolean [true] Traite toujours les erreurs de démarrage comme fatal
enable−startup−probes = boolean [true] Devrait vérifier le cluster pour les ressources actives durant le démarrage
stonith−enabled = boolean [true] Les nœuds en erreur sont "stonithisés"
stonith−action = enum [reboot] Action à envoyer au périphérique STONITH (reboot, poweroff, off)
stonith−timeout = time [60s] Temps d'attente pour terminer l'action STONITH
startup−fencing = boolean [true] Nœud STONITH non vus
cluster−delay = time [60s] délai d'aller-retour sur le réseau
batch−limit = integer [0] Nombre de jobs que le TE est autorisé à exécuter en parallèle
migration−limit = integer [−1] Nombre de jobs de migration que le TE est autorisé à exécuter en parallèle sur un nœud
default−action−timeout = time [20s] Délai d'attente pour que les actions se terminent
stop−all−resources = boolean [false] Spécifie si le cluster stop toutes les ressources actives
stop−orphan−resources = boolean [true] Spécifie si les ressources supprimées devaient être stoppées
stop−orphan−actions = boolean [true] Spécifie si les actions supprimées sont annulées
remove−after−stop = boolean [false] Supprime les ressources du LRM après qu'elles aient été stoppées
pe−error−series−max = integer [−1] Le nombre max d'entrées PE resultant en ERROR à sauvegarder. 0 pour désactiver, -1 illimité
pe−warn−series−max = integer [5000] Le nombre max d'entrées PE resultant en WARNING à sauvegarder. 0 pour désactiver, -1 illimité
pe−input−series−max = integer [4000] Nombre d'autres entrées PE à sauvegarder. 0 pour désactiver, -1 illimité
node−health−strategy = enum [none] Les attributs de nœud de combinaison de stratégie pour déterminer la santé générale du nœud. (none, migrate-on-red, only-green, progressive, custom)
node−health−green = integer [0] Le score green traduit en contraintes rsc_location. seulement avec node−health−strategy
node−health−yellow = integer [0] Le score yellow traduit en contraintes rsc_location. seulement avec node−health−strategy
node−health−red = integer [−INFINITY] Le score red traduit en contraintes rsc_location. seulement avec node−health−strategy
placement-strategy = enum [defaut] La stratégie pour déterminer le placement de ressource (default, utilization, minimal, balanced).
^
16 juillet 2010

htmlpdflatexmanmd




Permissions de fichiers

Permissions de fichiers

Description des permissions de fichiers

Structure des bits de mode de fichier

   Les bits de mode de fichier ont 2 parties, les bits de permission de fichier et les bits de mode spéciaux.

   Il y'a 3 types de permission que l'utilisateur peut avoir pour un fichier:

        1. permission de lire le fichier. pour les répertoires, permission de lister le contenu.
        2. permission d'écrire dans le fichier. pour les répertoire, permet de créer et supprimer des fichiers.
        3. Permission d'exécuter le fichier. pour les répertoires, permet d'accéder aux fichiers.

   Il y'a 3 catégories d'utilisateurs que peuvent avoir différentes permissions:

        1. le propriétaire du fichier
        2. les autres utilisateurs qui sont dans le groupe du fichier
        3. Tous les autres.

   Les fichiers ont un propriétaire et un groupe quand ils sont crées. Généralement le propriétaire est l'utilisateur courant et le groupe est le groupe du répertoire, mais celà dépend des systèmes, le système de fichier, et la manière dont il est créé.

  En plus des 3 catégories de permission, les bits de mode ont 3 composants spéciaux, qui affectent seulement les fichiers exécutables et les répertoires:

1. Définis l'ID de l'utilisateur effectif du processus, appelé le bit set-user-ID ou bit setuid. Pour les répertoires, donne aux fichiers crées le même propriétaire, et définis le set-user-ID pour les sous-répertoire crées.
2. Définis l'ID du groupe effectif du processus, appelé le bit set-group-ID ou bit setgid. Pour les répertoires, donne aux fichiers crées le même groupe, et définis le set-group-ID pour les sous-répertoire crées.
3. Empêche les utilisateurs non privilégiés de supprimer ou renommer un fichier dans un répertoire à moins qu'ils aient leur propre fichiers dans ce répertoire. appelé le restricted deletion flag. Pour les fichiers réguliers sur de vieux systèmes, sauver l'image du programme dans le périphérique swap pour qu'il se charge plus rapidement. Appelé le sticky bit.

   En plus des bits de mode de fichiers ci-dessus, il y'a des attributs de fichiers spécifiques aux systèmes de fichier. Par exemple les ACL, si un fichier est compressé, si un fichier peut être modifié, et si un fichier peut être dumpé. ex:

        ext2 Les attributs spécifiques à ce système de fichier se paramètre avec chattr
        FFS Les attributs spécifiques à ce système de fichier se paramètre avec chflags

Modes Symboliques

   les modes symboliques représentent les changements des bits de mode des fichiers. Le format des modes symboliques est:

  [ugoa...][+-=]PERMS...[,...]

        u Le propriétaire du fichier
        g Les utilisateur du groupe du fichier
        o tous les autres
        a tous les utilisateurs, identique à ugo
       
        + Ajouter les permissions
        - supprimer les permissions
        = définir les permissions
       
        r permission en lecture
        w permission en écriture
        x permet d'exécution.

Exemples

donne accès en lecture/écriture pour tous les utilisateurs:
a=rw
Supprime les permissions en écriture à tous les utilisateurs autre que le propriétaire:
go-w
supprimer tous les droits à tous le monde excepté le propriétaire:
go=
ou
og-rwx

Copier les permissions existantes

   Il est possible de baser les permissions d'un fichier sur des permissions existantes. Il faut utiliser u, g ou o. Par exemple le mode o+g copie les permissions du groupe aux autres utilisateurs.

Changer les bits de mode spéciaux

Pour définir le bits setuid, utiliser u pour la partie user et s dans la partie permissions
Pour définir le bits setgid, utiliser g pour la partie user et s dans la partie permissions
pour définir les bits setuid et setgid, omettre la partie user (ou utiliser a), et s dans la partie permissions
Pour définir le restricted deletion flag ou le sticky bit, omettre la partie user (ou utiliser a) et t dans la partie permissions

Exemples

définir le setuid:
u+s
supprimer le setuid et setgid:
a-s
définit le restricted deletion flag ou le sticky bit:
+t

Exécution conditionnelle

   utiliser 'X' au lieu de 'x' affecte le droit d'exécution/recherche si le fichier est un répertoire ou avait déjà les permissions d'exécution. Par ex: a+X donne à tous les utilisateurs le droit de recherche dans les répertoires, ou d'exécuter les fichiers si quelqu'un pouvait les exécuter avant.

Effectuer plusieurs changements

   Il y'a 2 manières d'effectuer des changement multiples.

La première manière est de spécifier plusieurs opérations. Par exemple, donner aux utilisateurs autre que le propriétaire la permission de lire et si c'est un répertoire ou si quelqu'un avait le droit de l'exécuter, de le faire également. et refuse l'écriture:
og+rX-w
La deuxième manière est de spécifier plus d'un mode symbolique simple. Par exemple, donner à tous le droit en lecture mais refuser l'écriture pour tous les utilisateurs hormis le propriétaire:
a+r,go-w
Définir explicitement toutes les permissions
u=rwx,g=rx,o=
Les 2 méthodes peuvent être combinées
a+r,g+x-W
Donner à tous les utilisateurs le droit en lecture, donner au groupe le droit d'exécution/recherche, mais pas en écriture
u+r,g+rx,o+r,g-w

Umask et protection

   Si la partie user d'un mode symbolique est omis, le défaut est a, excepté pour les permissions qui sont définies dans la variable système umask. La valeur de umask peut être définie en utilisant la commande umask. Sa valeur par défaut varie d'un système à l'autre.

  Omettre la partie user d'un mode symbolique n'est généralement pas très utile sauf avec '+', cela permet d'utiliser umask comme protection facilement personnalisable.

Par exemple, si umask a la valeur 2, qui supprime les permissions en écriture pour les utilisateurs qui ne sont pas dans le groupe du fichier, alors le mode
+w
ajoute la permission au fichier et son propriétaire et au groupe, mais pas aux autres utilisateurs
a+w
ignore umask, et donne le droit à tous les utilisateurs

Modes numériques

   Il est possible de spécfier le mode symbolique en octal. Ce nombre est toujours interprété en octal. Il n'est pas necessaire de rajouter des 0, comme en C. 0055 est le même que 55.

        Tous les autres utilisateurs
        1 Exécution/recherche
        2 Écriture
        4 Lecture
        Les utilisateurs dans le groupe du fichier
        10 Exécution/recherche
        20 Écriture
        40 Lecture
        Le propriétaire
        100 Exécution/recherche
        200 Écriture
        400 Lecture
        bits de mode spéciaux
        1000 Restricted deletion flag ou sticky bit
        2000 Set group ID
        4000 Set user ID

Répertoires avec Set-User-ID et Set-Group-ID

   Sur beaucoup de systèmes, si un répertoire a le setgid de mis, les fichiers nouvellement crées héritent du même groupe que le répertoire, et les sous-répertoire nouvellement crées héritent du setgid. Sur certains systèmes, le setuid a le même effet. Ce mécanisme permet aux utilisateurs de partager des fichiers facilement. Les commandes comme chmod et mkdir effacent ces bits généralement.

        ces commandes laissent le setuid et setgid des sous-répertoires:
        mkdir A B C
        chmod 755 A
        chmod 0755 B
        chmod u=rwx,go=rx C
        mkdir -m 755 D
        mkdir -m 0755 E
        mkdir -m u=rwx,go=rx F
        ces commandes essayent de définit setuid et setgid sur les sous-répertoires:
        mkdir G H
        chmod 6755 G
        chmod u=rwx,go=rx,a+s H
        mkdir -m 6755 I
        mkdir -m u=rwx,go=rx,a+s J
        cette commande essaye de supprimer setuid et setgid du répertoire D:
        chmod a-s D
^
08 mai 2010

htmlpdflatexmanmd




perror

perror

Expliquer les codes d'erreur

   Pour la plupart des erreurs système, MySQL affiche en plus d'un message texte, le code d'erreur système dans le style suivant:

message ... (errno: #)
message ... (Errcode: #)

   perror affiche une description pour le code d'erreur système ou pour le moteur de stockage.

Exemples

shell› perror 13 64
OS error code 13: Permission denied
OS error code 64: Machine is not on the network
Pour obtenir le message d'erreur pour un cluster MySQL
shell› perror --ndb errorcode

OPTIONS

--help, --info, -I, -? Affiche l'aide
--ndb Utilisé pour les codes d'erreur d'un cluster MySQL
--silent, -s mode silencieux, seules les erreurs seront affichées
--verbose, -v Mode détaillé. Affiche plus d'informations sur les faits et gestes du programme.
^
23 mai 2010

htmlpdflatexmanmd




pidof

pidof

Recherche l'ID d'un processus en cours

OPTIONS

-s Ne retourne qu'un seul pid
-c ne retourne que les id qui tournent avec le même dossier root. Ignoré pour les utilisateurs non-root
-x Retourne également l'id du shell qui a lancé le script nommé
-o omet l'id spécifié. %PPID peut être utilisé pour nommer le processus parent du programme pidof
^
24 décembre 2016

htmlpdflatexmanmd




pkaction

pkaction

Obtenir des détails sur les actions enregistrées

   pkaction est utilisé pour obtenir des informations sur les actions PolicyKit.

OPTIONS

--action-id Affiche seulement l'action spécifiée
--verbose Affiche des détails
^
24 décembre 2016

htmlpdflatexmanmd




pkcheck

pkcheck

Vérifier si un processus est autorisé

   pkcheck est utilisé pour vérifier si un processus, est autorisé à effectuer une action.

OPTIONS

--process processus pour lequel enregistrer l'agent d'authentification
--system-bus-name Nom du sujet pour lequel enregistrer l'agent d'authentification
--detail key value Peut être spécifié plusieurs fois pour passer des détails sur l'action
--allow-user-interaction Attend pour l'authentification
--list-temp Liste toutes les autorisations temporaires pour la session courante
--revoke-temp Révoque toutes les autorisations temporaires pour la session courante.
--action-id Spécifie l'action à vérifier
--process [pid|pid,pid-start-time|pid,pid-start-time,uid] Spécifie le processus à vérifier
--enable-internal-agent Si aucun agent d'authentification n'est disponible, enregistre son agent d'authentification textuel

Valeurs de retour

   si le processu spécifié est autorisé, pkcheck quitte avec une valeur de retour de 0. Si l'autorisation résultante contient des détails, ils sont affiché sur stdout.

   Si le processus spécifié n'est pas autorisé, pkcheck quitte avec une valeur de 1 et un message de diagnostique est affiché sur stdout.

   Si le processus spécifié n'est pas autorisé parce l'agent d'authentification a été fermé par l'utilisateur, pkcheck quitte avec une valeur 3 et un message de diagnostique affiché sur stderr. Des détails sont affichés sur stdout

   Si une erreur se produit pour l'autorisation, pkcheck quitte avec une valeur de retour de 127 et un message de diagnostique est affiché sur stderr.

   Si une ou plusieurs options passées sont malformées, pkcheck quitte avec une valeur de 126. Si stdin est un tty, ce man est également affiché.
^
05 mars 2012

htmlpdflatexmanmd




PKCS#1

PKCS#1

RSA Cryptography Standard

   RSA (Rivest Shamir Adleman) est un algorithme asymétrique.

Génération des clés

Pour calculer une paire de clé privée/publique RSA, l’algorithme s’appuie sur 2 nombres premiers, p et q. Une fois ces 2 nombres déterminés, on obtient 2 nombres:
n = p x q
z = ( p - 1 ) x ( q - 1 )
On calcul ensuite l’indicatrice d’Euler e de z (inférieur à z), qui doit nécessairement être premier avec z:
d = e-1 mod((p - 1)(q - 1))

   le couple (n,e) est la clé publique, le couple (n,d) est la clé privée. Une fois e, d et n caclulés, il faut détruire p, q, et z pour des raisons évidentes de sécurité. La clé privée est généralement chiffrée avec un algorithme symmetrique pour la conserver de façon sûre.

Chiffrement et déchiffrement

Pour chiffrer un nombre, il faut le mettre à la puissance de e. Le reste modulo n représente le nombre chiffré:
c = te mod n
pour déchiffrer, on utilise la même opération, mais à la puissance d:
t = cd mod n
exemple simple utilisant de petits nombres:
pour chiffrer le texte suivant: "Hello World", on choisis p = 37 et q = 43.
on déduit :
n = 37 x 43 = 1591
z = 36 x 42 = 1512
on choisit e = 19, premier avec 1512. L’inverse de 19 modulo 1512 est d = 955.
pour chiffrer chaque caractère:
Hello World = 72 101 108 108 111 32 87 111 114 108 100


H___e___l___l___o___ ___W___o___r___l___d
72__101_108_108_111_32__87__111_114_108_100

on caclule chaque caractère avec:
7219 [1591] = 335 ; 10119 [1591] = 1174 ; etc…


72____101____108____108____111___32____87____111___114___108____100
335___1174___1329___1329___703___930___431___703___632___1329___396

On déchiffre avec:
335955 [1591] = 72 ; 1174955 [1591] = 101 ; etc…

Notes

   Plusieurs techniques permettent de déchiffrer ou déduire la clé privée:

- si p et q sont trop petits, un brute force ne prend que très peu de temps à déterminer la clé privée. il faut donc choisir des valeures très grandes (minimum 1024 bits)
- Le chiffrement par caractère comme dans l’exemple ci-dessus, peut être cassé en déterminant la fréquence des octets (analyse fréquentielle). Il est préférable de chiffrer un bloc d’octets.
- n ne doit pas être inférieur au bloc d’octets à chiffrer, sinon plusieurs valeurs initiales peuvent donner le même nombre chiffré, donnant des erreurs au déchiffrement.
- on peut déterminer la taille d’une clé privée en déterminant le temps que prend le déchiffrement d’un message. Toute la sécurité RSA repose sur le temp nécessaire pour calculer p et q à partir de n.
^
15 février 2012

htmlpdflatexmanmd




pkcs11-data

pkcs11-data

Manipulateur de token accessible via PKCS #11. Il utilise cryptoki

OPTIONS

--verbose Mode verbeux
--add-provider Ajouter un fournisseur PKCS #11. Peut-être spécifié plusieurs fois.
--public objet Data dans la section publique
--prompt-prog Demande l’enregistrement
--token-wait Attend jusqu’à ce que le token soit inséré
--cmd=tokens Liste les token disponibles
--cmd=list Liste les objets

        --token= Id du token

--cmd=export Exporter un objet

        [--token=] Id du token
        --application= Nom de l’application
        --label Label
        [--file] Fichier cible ou stdout

--cmd=import Importer des objets

        --token= Id du token
        --application= Nom de l’application
        --label Label
        [--file] Fichier source ou stdin

--cmd=remove Supprimer un objet

        --token= Id du token
        --application= Nom de l’application
        --label Label
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-destroy

pkcs11-destroy

Détruit les clés stockées dans un périphérique PKCS#11

OPTIONS

-m module Spécifie le module PKCS#11
-s slot slot à utiliser en ouvrant la session. Défaut: 0
-i ID Liste seulement les objets avec l'ID spécifié
-l label liste seulement les objets avec le label spécifié
-p PIN Spécifie le PIN pour le périphérique
-w seconds Spécifie le délay avant de détruire la clé. Défaut: 5 secondes. À 0, la destruction est immédiate
^
15 février 2012

htmlpdflatexmanmd




pkcs11-dump

pkcs11-dump

Dump le contenu d’un token PKCS #11 sur stdout dans un format lisible

   Les types supportés sont:

CKO_DATA
CKO_CERTIFICATE
CKO_PUBLIC_KEY
CKO_PRIVATE_KEY
CKO_SECRET_KEY
CKO_HW_FEATURE
CKO_DOMAIN_PARAMETERS
CKO_MECHANISM
CKO_VENDOR_DEFINED

OPTIONS

info
slotlist
dump
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-keygen

pkcs11-keygen

Générer une nouvelle paire de clé

OPTIONS

-a algorithm RSA, DSA, DH, ECC ou un algorithme de signature DNSSEC (ex: NSEC3RSASHA1, ECDSAP256SHA256). Défaut: RSA
-b keysize Taille de la clé (256 ou 384)
 -e Pour RSA uniquement, utilise en grand exporsant
-i id Spécifie l'id pour la création des objets
-m module Spécifie le module PKCS#11
-P Définis la nouvelle clé privée non-sensible et extractible
-p PIN Spécifie le PIN pour le périphérique
-q mode silencieux
-S Pour les clé DH uniquement, utilise un nombre premier spécial 768, 1024 ou 1536 bits.
-s slot slot à utiliser en ouvrant la session. Défaut: 0
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-list

pkcs11-list

Lister les objets PKCS#11

OPTIONS

-P Liste seulement les objets publiques
-m module Spécifie le module PKCS#11
-s slot slot à utiliser en ouvrant la session. Défaut: 0
-i ID Liste seulement les objets avec l'ID spécifié
-l label liste seulement les objets avec le label spécifié
-p PIN Spécifie le PIN pour le périphérique
^
15 février 2012

htmlpdflatexmanmd




pkcs11-listcerts

pkcs11-listcerts

Lister les certificats PKCS#11 d’une carte à puce

OPTIONS

debug mode debug
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-tokens

pkcs11-tokens

Liste les périphériques pkcs#11 disponible

OPTIONS

-m module Spécifie le module PKCS#11
^
15 février 2012

htmlpdflatexmanmd




pkcs11-tool

pkcs11-tool

Utilitaire pour gérer et utiliser les token de sécurité PKCS#11. Il permet de gérer et les objets sur les cartes à puce, lister et lire le PIN, clés et certificats stockés

OPTIONS

--login, -l Authentifie le token avant d’effectuer d’autres opérations.
--pin, -p Utilise le pin donné pour les opérations.
--so-pin Utilise le pin donné comme Security Officer PIN (doit être utilisé avec --label)
--init-token Initialise un token : défini son label et le Security Officer PIN
--init-pin Initialise le PIN de l’utilisateur
--change-pin, -c Change le pin de l’utilisateur
--test, -t Effectue des tests sur le token
--show-info, -I Affiche les informations générale sur le token
--list-slots, -L Affiche une liste de slots disponible sur le token
--list-mechanisms, -M Affiche une liste de mécanismes supportés par le token
--list-objects, -O Affiche la liste des objets
--sign, -s Signe des données
--hash, -h Hash des données
--mechanism, -m Utilise le mécanisme spécifié pour les opérations du token
--keypairgen, -k Génère une nouvelle pair de clé
--write-object, -w Écrit une clé ou un certificat dans le token
--type, -y Spécifie le type d’objet sur lequel opérer (cert, privkey, pubkey)
--id, -d Spécifie l’id de l’objet sur lequel opérer
--label, -a Spécifie le nom de l’objet sur lequel opérer
--slot Spécifie l’id du slot à utiliser
--slot-id Spécifie le nom du slot à utiliser
--set-id, -e Définis le CKA_ID de l’objet
--attr-from Extrait les informations du chemin spécifié (certificat DER) et créé les attributs correspondant quand il écrit un objet dans le token. (ex : le sujet du certificat est utilisé pour écrire le CKA_SUBJECT)
--input-file, -i Spécifie le chemin d’un fichier en entrée
--output-file, -o Spécifie le chemin d’un fichier en sortie
--module Spécifie le module pkcs11 à charger
--moz-cert, -z Tester une génération et la requête de pair de clé type mozilla. Spécifier le chemin du fichier du certificat
--verbose, -v mode verbeux
^
15 février 2012

htmlpdflatexmanmd




pkcs11_eventmgr

pkcs11_eventmgr

Identique à card_eventmgr avec quelques améliorations. Il utilise la libraire PKCS #11 au lieu de l’API pcsc-lite, le polling time et le temps d’expiration est en seconde

commandes

[no]debug mode debug
[no]daemon placer en tâche de fond
polling_time=‹s› Temps en secondes entre 2 statuts consécutifs (défaut : 1)
expire_time=‹s› Temps en seconde pour l’évènement expire_time au retrait de la carte (défaut : 0)
config_file=‹file› Fichier de configuration à utiliser (défaut : /etc/pam_pkcs11/pkcs11_eventmgr.conf)
pkcs11_module=‹file› Libraire PKCS #11 à utiliser (défaut : /usr/lib/pkcs11/opensc-pkcs11.so)
^
15 février 2012

htmlpdflatexmanmd




pkcs11_eventmgr.conf

pkcs11_eventmgr.conf

Fichier de configuration pour pkcs11_eventmgr


pkcs11_eventmgr {
    daemon = true ; # lancer en tâche de fond
    debug = false ; # mode debug
    polling_time = 1 ; #polling time en secondes
    expire_time = 0 ; # temps d’expiration en seconde (0 pas d’expiration)
    pkcs11_module = /usr/lib/opensc-pkcs11.so ; # module PKCS #11 à utiliser
    # Liste des évènements et actions
    event card_insert {
        on_error = ignore ;
        action = "/usr/bin/play /usr/share/sounds/warning.wav",
        "/usr/X11R6/bin/xscreensaver-command -deactivate" ;
    }
    event card_remove {
        on_error = ignore ;
        action = "/usr/bin/play /usr/share/sounds/error.wav",
        "/usr/X11R6/bin/xscreensaver-command -lock" ;
    }
    event expire_time {
        on_error = ignore ;
        action = "/bin/false" ;
    }
}

Problèmes de sécurité

   Toutes les commandes des évènements sont exécutées avec les privilèges utilisateur.

  En invoquant setuid et setgid, ces commandes ignorent l’environnement de l’utilisateur et définissent le leur.

  Les actions sont exécutées via execve("/bin/sh","-c","commande",null,environ).
^
15 février 2012

htmlpdflatexmanmd




pkcs11_inspect

pkcs11_inspect

Utilitaire pour explorer des certificats

   Il utilise le même fichier de configuration que pam_pkcs11. Il charge les mappers définis et les utilise pour regarder dans le certificat les entrées requises. Quand un mapper trouve une entrée valide, il la convertit en UTF-8 et l’affiche sur stdout.

OPTIONS

debug mode debug
config_file=‹file› Fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
^
15 février 2012

htmlpdflatexmanmd




pkcs11_make_hash_link

pkcs11_make_hash_link

hash symbolique de certificats

   Crée un lien hash symbolique pour chaque certificat CA et chaque CRL dans le répertoire donné

^
15 février 2012

htmlpdflatexmanmd




pkcs11_setup

pkcs11_setup

Affiche tous les certificats

OPTIONS

debug mode debug
list_module liste les modules disponible et configurés dans /etc/pam_pkcs11/pam_pkcs11.conf
use_module Affiche le module utilisé par pam_pkcs11 ou le définis
ins_action[=commande] Affiche les commande exécutées quand la carte est insérée ou définis les commandes
rm_action[=commande] Affiche les commande exécutées quand la carte est retirée ou définis les commandes
^
15 février 2012

htmlpdflatexmanmd




pkcs15-crypt

pkcs15-crypt

Effectuer des opérations crypto en utilisant des cartes pkcs #15

OPTIONS

--sign, -s Signer numériquement une donnée lue depuis un fichier. Le contenu du fichier est le résultat d’une opération de hash md5. Il attend une donnée binaire. Si aucun fichier de sortie n’est spécifié, affiche sur stdout
--pkcs1 pkcs15-crypt attend en entrée des données à la longueur correcte. Cette option force pkcs15-crypt à convertir à la bonne longueur en utilisant pkcs1
--sha-1 Le fichier d’entrée est le résultat d’une opération de hash SHA1 au lieu de md5. (Doit être en représentation binaire)
--decipher, -c Déchiffre le contenu du fichier. le résultat est écrit sur stdout si aucun fichier de sortie n’est spécifié
--key, -k Spécifie l’id de la clé à utiliser
--reader, -r Sélectionne le nième lecteur de carte
--input, -i Spécifie le fichier à utiliser en entrée
--output, -o Spécifie le fichier à utiliser en sortie
--raw, -R Sort les données brut 8bits
--pin, -p Spécifie le PIN si une opération le nécessite
--verbose, -v mode verbeux
^
15 février 2012

htmlpdflatexmanmd




pkcs15-init

pkcs15-init

Utilitaire de personnalisation de carte à puce

   Il permet de créer des structures PKCS #15 sur les cartes à puce, créer des PIN et ajouter des clés et des certificats. Les détails de la structure est contrôlée par des profils.

Utilisation du PIN

   Une carte OpenSC peut avoir un security officer PIN, et 0 ou plusieurs PIN utilisateurs. Généralement, un PIN est une séquence de chiffres, mais certaines cartes acceptent des caractères ascii. Le SO-PIN est spécial, il est utilisé pour protéger les métadonnées sur la carte, tel que la structure PKCS #15 elle-même. Le SO-PIN est optionnel. Pour chaque PIN, vous pouvez spécifier un PUK.

Modes opératoires

  

Initialisation

Première étape de la personnalisation de la carte, et va créer les fichiers de bases sur la carte. Pour créer une structure PKCS #15 (le PIN, le PUK et le SO-PIN sont demandés):
pkcs15-init --create-pkcs15
Si la carte le supporte, vous pouvez également l’effacer avant avec --erase

Installation du PIN de l'utilisateur

Avant d’installer des objets, vous avez besoin d’au moins un PIN pour protéger ces objets (demande le PIN et le PUK):
pkcs15-init --store-pin --id " nn
Où nn est un ID PKCS #15 en notation hexadécimal. Les valeurs communes sont 01, 02, etc.

Génération de clé

Pour générer une nouvelle clé et la stocker:
pkcs15-init --generate-key " keyspec " --auth-id " nn
Où keyspec décrit l’algorithme et la longueur de la clé à créer, tel que rsa/512. Actuellement seul RSA est supporté. nn est l’ID d’un PIN utilisateur
Cela va stocker la portion privée et publique de la clé. Par défaut, tente d’utiliser la fonctionnalité embarquée de la carte.

Télécharger la clé privée

Vous pouvez utiliser une clé par un autre moyen et la charger dans la carte. Doit être au format PEM, DER, et les certificats pkcs12 et pfx :
pkcs15-init --store-private-key key.pem --id 45 --auth-id 01
L’option --id sert pour définir 2 templates de clé. l’id 45 sert pour l’authentification et l’id 46 pour la non-répudiation.

Télécharger la clé publique

--store-public-key stocke la clé publique. Utiliser --format pour spécifier le format du fichier (PEM par défaut)

Télécharger un certificat

--store-certificat stocke le certificat. Le fichier est supposé être un fichier x.509 au format DER

Télécharger les fichiers pkcs#12

pkcs15-init --store-private-key key.p12 --format pkcs12 --auth-id 01

OPTIONS

--profil, -p Charge le profile général spécifié. Des options peuvent être spécifiées pour ce module en ajoutant un + entre chaque option. ex : pkcs15+onepin
--card-profile, -c Charge l’option de profile de carte spécifié.
--create-pkcs15, -C Crée un structure PKCS #15 sur la carte
--erase-card, -E Efface la carte avant de créer la structure PKCS #15
--generate-key, -G Dit à la carte de générer une nouvelle clé et de la stocker sur la carte, avec l’algorithme/longueur spécifiée
--store-private-key, -S Télécharge la clé privée sur la carte. Crée également un objet clé publique
--store-public-key, -P Télécharge la clé publique sur le certificat
--store-certificate, -X Stocke le certificat sur la carte
--so-pin, --so-puk, --pin, --puk Permet de spécifier les valeurs pour les opérations qui le nécessite
--passphrase Permet de spécifier la passphrase pour débloquer la clé privée
--verbose, -v mode verbeux
--options-file Lit les options additionnelles depuis le fichier spécifié. Ce fichier est supposé contenir une option longue par ligne. (Peut être spécifié plusieurs fois). ex:

        pin frank
        puk zappa
^
15 février 2012

htmlpdflatexmanmd




pkcs15-tool

pkcs15-tool

Utilitaire pour manipuler les structures de données PKCS #15

OPTIONS

--learn-card, -L Met en cache les données du token PKCS #15. Les opérations suivantes sont effectuées sur les données en cache si possible.
--read-certificate, -r Lit le certificat avec l’id spécifié
--list-certificates, -c Liste tous les certificats présent
--list-pins Liste tous les PIN
--change-pin Change un PIN
--unblock-pin, -u Débloque un PIN en utilisant le PUK
--list-keys, -k Listes les clés privées
--list-public-keys Liste toutes les clés publiques
--read-public-key Lit la clé publique avec l’id spécifié
--read-ssh-key Lit la clé publique avec l’id spécifié, affiche dans un format compatible pour $HOME/.ssh/authorized_keys
--output, -o Fichier de sortie
--no-cache Désactive la mise en cache des données
--pin-id, -a Spécifie le PIN à utiliser pour l’opération. Utile avec -change-pin
--reader Utilise le lecteur spécifié par son numéro
--verbose, -v mode verbeux
^
07 mars 2012

htmlpdflatexmanmd




PKCS#3

PKCS#3

Diffie-Hellman Key-Agreement Standard

   L’échange de clé Diffie-Hellman est une méthode par laquelle 2 personnes peuvent se mettre d’accord sur un nombre qu’ils peuvent utiliser pour chiffrer des données.

Exemple

1. 2 utilisateurs A et B choisisent un nombre premier p et une base g: p=23, et g=3
2. L’utilisateur A choisi un nombre secret a=6
3. L’utilisateur A envoie la valeur A = ga [mod p] = 36 [23] = 16
4. L’utilisateur B choisit un nombre secret b=15
5. L’utilisateur B envoie la valeur B = gb [mod p] = 315 [23] = 12
6. L’utilisateur A calcule la clé secrète K : (gb [mod p])a [mod p] = 126 [23] = 9
7. L’utilisateur B calcule la clé secrète K : (ga [mod p])b [mod p] = 1615 [23] = 9

   Il est nécessaire d’utiliser des nombres suffisamment grand pour éviter une attaque par recherche exhaustive.

  Diffie-Hellman est vulnérable aux attaques MITM. Pour parer à cette attaque, on peut signer les échanges avec une paire de clés asymétriques.
^
24 décembre 2016

htmlpdflatexmanmd




pkexec

pkexec

Exécuter une commande sous un autre utilisateur

   pkexec permet à un utilisateur autorisé d'exécuter le programmes spécifié sous un autre utilisateur. Si l'utilisateur n'est pas spécifié, utilise root.

Valeur de retour

   une fois terminé, la valeur de retour est la valeur de retour du programme. Si le processus appelant n'est pas autorisé ou qu'une autorisation ne peut pas être obtenue ou qu'une erreur s'est produite, pkexec quitte avec une valeur de retour de 127. Si l'autorisation ne peut être obtenue, pkexec quitte avec la valeur 126.

l'agent d'authentification

   pkexec, comme tout autre application PolicyKit, utilise l'agent d'authentification enregistré pour le procéssus appelant. Cependant, si aucun agent d'authentification n'est disponible, pkexec enregistre son propre agent d'authentification. Ce comportement peut être désactivé avec --disable-internal-agent.

Notes de sécurité

   Exécuter un programme sous un autre utilisateur est une opération privilégiée. Par défaut l'autorisation requise nécéssite une authentification administrative. De plus, le dialogue d'authentification présenté à l'utilisateur affiche le chemin complet du programme à exécuter dont l'utilisateur est au courant de se qu'il va se passer.


+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_needed_to_run_`/bin/bash'_____|
|__________as_the_super_user_______________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_the_super_user_is_required_to_perform_this___|
|__________action._________________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Command:_/bin/bash______________________________________|
|__Run_As:__Super_User_(root)______________________________|
|__Action:__org.freedesktop.policykit.exec_________________|
|__Vendor:__The_PolicyKit_Project__________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

   L'environnement dans lequel le programme tourne, est définis à un environnement minimal et sûr pour éviter d'injecter du code via LD_LIBRARY_PATH ou des mécanismes similaires. De plus, la variable d'environnement PKEXEC_UID est définie avec l'UID invoquant pkexec. En résultat, pkexec n'autorise pas de lancer des application X11 sous un autre utilisateur vu que $DISPLAY et $XAUTHORITY ne sont pas définis. Il y a 2 variables retenus si org.freedesktop.policykit.exec.allow_gui dans une action est définis à une valeur non-nul. C'est découragé, et utilisé uniquement pour compatibilité.

Autorisations requises

   Par défaut, org.freedesktop.policykit.exec est requis sauf si un fichier de définition d'action est présent pour le programme en question. pour exiger une autre autorisation, cela peut être spécifié en utilisant l'annotation org.freedesktop.policykit.exec.path dans une action.

Exemple

Pour spécifier un type d'autorisation nécessaire pour exécuter le programme /usr/bin/pk-example-frobnicate sous un autre utilisateur, écrire simplement une définition d'action:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC
    "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"›
‹policyconfig›
    
    ‹vendor›Examples for the PolicyKit Project‹/vendor›
    ‹vendor_url›http://hal.freedesktop.org/docs/PolicyKit/‹/vendor_url›

    ‹action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"›
        ‹description›Run the PolicyKit example program Frobnicate‹/description›
        ‹description xml:lang="da"›Kør PolicyKit eksemplet Frobnicate‹/description›
        ‹message›Authentication is required to run the PolicyKit example program Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹message xml:lang="da"›Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹icon_name›audio-x-generic‹/icon_name›
        ‹defaults›
            ‹allow_any›no‹/allow_any›
            ‹allow_inactive›no‹/allow_inactive›
            ‹allow_active›auth_self_keep‹/allow_active›
        ‹/defaults›
        ‹annotate key="org.freedesktop.policykit.exec.path"›/usr/bin/pk-example-frobnicate‹/annotate›
    ‹/action›
    
‹/policyconfig›

   placer ce fichier dans /usr/share/polkit-1/actions avec un nom qui ait du sens, par exemple l'espace de nom de l'action. Noter que pkexec ne valide pas les arguments passés au programme. Dans un cas normal (où l'authentification administration est requise à chaque fois que pkexec est utilisé), ce n'est pas un problème vu que si l'administrateur est un administrateur il peut simplement lancer pkexec bash pour devenir root.

   Cependant, si une action est utilisée pour laquelle l'utilisateur peut retenir l'authorisation ( ou si l'utilisateur est implicitement autorisé), tel qu'avec pk-example-frobnicate ci-dessus, cela peut être un problème de sécurité. Donc, les programmes pour lesquels l'autorisation requise par défaut est changé, ne devraient jamais implicitement faire confiance à l'entrée utilisateur.
^
23 mai 2010

htmlpdflatexmanmd




pkill

pkill, pgrep

Chercher-envoyer un signal

pgrep cherche dans les processus en cours et affiche leur ID, en fonctions de critères.
pkill envoie un signal (SIGTERM par défaut) au processus au lieu de les lister.

OPTIONS

-c supprime la sortie normale, affiche à la place un compteur de processus correspondant
-d delimiter Définit la chaîne utilisé pour délimiter chaque ID dans la sortie (par défaut un newline)
-f le motif correspond à la ligne de commande
-g seul les processus dont l'id du groupe de processus correspondant sont listés.
-G seul les processus dont l'id du groupe réel correspondant sont listés.
-l liste le nom du processus et son ID
-n  Liste l'ID du plus récent processus correspondant
-o Liste le plus ancien processus correspondant
-P seul les processus dont l'ID du processus parent correspondant sont listés
-s Seul les processus appartenant à l'ID de session correspondant sont listés
-t seul les processus contrôlé par l'id du terminal correspondant sont listés
-u Seul les processus appartenant à l'ID utilisateur effectif correspondant sont listés.
-U Seul les processus appartenant à l'ID utilisateur réel correspondant sont listés.
-v Inverse la correspondance
-x seul les processus dont le nom ( ou la ligne de commande avec l'option -f) correspond parfaitement sont listés.
-signal Définit le signal à envoyer à chaque processus correspondant, soit en valeur numérique soit le nom symbolique du signal (pkill uniquement)

Exemples

trouver l'id de named
pgrep -u root named
liste uniquement les processus de root et daemon:
pgrep -u root,daemon
forcer syslog à relire sont fichier de configuration:
pkill -HUP syslogd
donner des information détaillée sur tous les processus xterm:
ps -fp $(pgrep -d, -x xterm)
renice les processus netscape:
renice +4 `pgrep netscape`

Codes de sortie

0 un ou plusieurs processus on été trouvé
1 aucun processus n'a été trouvé
2 erreur de syntaxe
3 erreur fatal

Notes

   le motif de recherche est tronqué au delà de 15 caractères. pgrep et pkill ne s'affichent jamais en cas de correspondance.
^
15 février 2012

htmlpdflatexmanmd




pklogin-finder

pklogin-finder

Trouver des maps Cert-to-login

   Utilisé pour trouver les maps Cert-to-login, en dehors de l’environnement PAM. Peut être utilisé pour créer et tester les maps. Il utilise la même structure de configuration que le module pam-pkcs11. Il lit le certificat et tente tous les mappers spécifiés pour trouver l’utilisateur.

OPTIONS

[no]debug mode debug
config_file=‹file› Fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
^
24 décembre 2016

htmlpdflatexmanmd




pkttyagent

pkttyagent

Helper d'authentification textuel

   pkttyagent est utilisé pour démarrer un agent d'authentification textuel pour le sujet spécifié par --process ou --system-bus-name. Si aucun n'est spécifié, utilise le processus parent.

   Pour être notifié quand l'agent d'authentification a été enregistré, écouter soit D-Bus ou utiliser --notify-fd pour passer le numéro d'un descripteur de fichier au programme. Ce fd sera fermé quand l'agent d'authentification est enregistré.

Valeur de retour

   Si l'agent d'authentification ne peut pas être enregistré, pkttyagent quitte avec un code de sortie de 127. Des messages de diagnostique sont affichés sur stderr.

   Si une ou plusieurs options sont malformées, pkttyagent quitte avec le code 126. Si stdin est un tty, ce man est également affiché.

   Si l'agent d'authentification a été enregistré avec succès, pkttyagent continue de fonctionner, interagissant avec l'utilisateur si nécessaire. Quand ses services ne sont plus nécessaires, le processus s'arrête.

Notes

   Vu que les PID peuvent être recyclés, l'appelant devrait toujours utiliser pid,pid-start-time en utilisant l'option --process. La valeur de pid-start-time peut être déterminé en consultant par exemple proc. Si seul pid est passé à l'option --process, pkttyagent recherche l'heure de début de lui-même.

OPTIONS

--process { pid | pid,pid-start-time} processus pour lequel enregistrer l'agent d'authentification
--system-bus-name busname Nom du sujet pour lequel enregistrer l'agent d'authentification
--notify-fd fd Permet de passer un descripteur de fichier pour connaître quand l'agent d'authentification est enregistré
--fallback Empêche l'agent d'authentification textuel de remplacer un agent d'authentification existant.
^
05 septembre 2015

htmlpdflatexmanmd




pldd

pldd

afficher les objets partagés liés dynamiquement dans un processus

   pldd affiche une liste d'objets partagés dynamiquement qui sont liés dans le processus spécifié par son PID. Cette liste inclus les librairies qui ont été chargées dynamiquement en utilisant dlopen(3).

^
31 mai 2010

htmlpdflatexmanmd




policy-rc.d

policy-rc.d

le script /usr/bin/policy-rc.d doit être géré par /usr/sbin/update-alternatives

OPTIONS

--quiet Ne génère pas de message d'erreur.
--list liste les règles définies pour l'id de script donné

   la liste des action doit être séparée pas des espaces. Elles sont toujours connues ( start, [force-]stop, restart, [force-]reload, status ).

  si invoke-rc.d détecte un start ou restart hors runlevel, l'action "start" ou "restart" sera changé en "(start)" ou "(restart)". Cà permet à policy-rc.d de différentier un démarrage hors runlevel d'un démarrage normal.

  le runlevel est optionnel. Si aucun runlevel n'est spécifié, il est considéré comme inconnus/indéfinis.

Codes de sortie

0 action autorisée
1 action inconnue (politique indéfinie)
100 id de script inconnu
101 action interdit
102 erreur système
103 erreur de syntaxe
104 réservé
105 mode incertains, ou indéfinis
106 action non permise

Règles de filtrage interne

   invoke-rc.d implémente ces règles:

1 une action "start" hors runlevel interdit
2 une action "restart" hors runlevel interdit
3 une action pour un script non exécutable est interdit (Cette 3eme règle nepeut pas être outrepassée)
^
24 décembre 2016

htmlpdflatexmanmd




polkit

polkit

framework d'autorisation

   policyKit fournis une API d'autorisation conçue pour être utilisée par des programmes privilégiés (mécanismes) offrant un service à des programmes non privilégiés (clients) sous la forme d'un mécanisme IPC tel que D-Bus ou pipes Unix. Dans ce scénario, le mécanisme traite généralement le client n'étant pas de confiance. Pour toute requête d'un client, le mécanisme doit déterminer si la requête est autorisée ou si elle devrait refuser le service au client. En utilisant l'API PolicyKit, un mécanisme peut décharger cette décision à un tier de confiant: l'autorité PolicyKit.

   En plus d'agir comme autorité, PolicyKit permet aux utilisateurs d'obtenir une autorisation temporairement en authentifiant soit un utilisateur administratif ou le propriétaire de la session auquel appartient l'utilisateur. C'est utile pour les scénarios où un mécanisme doit vérifier que l'opérateur du système est réellement l'utilisateur ou réellement un utilisateur administratif.

Architecture système

   L'architecture système de PolicyKit est composé de l'autorité (implémenté comme un service dans D-Bus) et un agent d'authentification par session utilisateur (fournis et démarré par la session utilisateur). Additionnellement, PolicyKit support des points d'extensions - spécifiquement, les vendeurs et/ou sites peuvent écrire des extensions pour contrôler complètement la stratégie d'autorisation. Dans un diagramme block, l'architecture ressemble à ceci:


    +-------------------+
_|___Authentication__|
_|_______Agent_______|
_+-------------------+
_|_libpolkit-agent-1_|
_+-------------------+
________^__________________________________+--------+
________|__________________________________|_Client_|
________+--------------+___________________+--------+
_______________________|________________________^
_______________________|________________________|
User_Session___________|________________________|
=======================|========================|=============
System_Context_________|________________________|
_______________________|________________________|
_______________________|____________________+---+
_______________________V____________________|
_____________________/------------\_________|
_____________________|_System_Bus_|_________|
_____________________\------------/_________|
_______________________^________^___________V
_______________________|________|______+---------------------+
________+--------------+________|______|______Mechanism______|
________|_______________________|______+---------------------+
________V_______________________+----›_|_libpolkit-gobject-1_|
+------------------+___________________+---------------------+
|_org.freedesktop._|
|____PolicyKit1____|
+------------------+
|___Backends_and___|
|____Extensions____|
+------------------+

   libpolkit-gobject-1 enveloppe l'API D-Bus PolicyKit utilisant GObject. Cependant, un mécanisme peut également utiliser l'API D-Bus ou la commande pkcheck pour vérifier les autorisations.

   La librairie libpolkit-agent-1 fournis une abstraction du système d'authentification natif, par exemple pam et également des facilités d'enregistrement et de communication avec le service D-Bus PolicyKit.

   Les extensions PolicyKit et les backends d'autorité sont implémentés en utilisant libpolkit-backend-1

Agents d'authentification

   Un agent d'authentification est utilisé pour que l'utilisateur d'une session prouve qu'il est l'utilisateur ou un utilisateur administratif. Pour s'intégrer avec le reste de la session utilisateur, les agents d'authentification sont censés être fournis par la session utilisateur que l'utilisateur utilise. Par exemple, un agent d'authentification peut ressembler à:


+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__L'authentification_est_requise_pour_lancer______|
|__________des_tests_ATA_SMART_____________________________|
|__________________________________________________________|
|_________Une_application_tente_d'effectuer_une_action_____|
|_________qui_nécessite_des_privilèges._L'authentification_|
|_________super_utilisateur_est_requis_pour_effectuer______|
|_________cette_action.____________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Si le système est configuré sans un compte root il peut vous autoriser à sélectionner un utilisateur administratif:
+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_required_to_run_ATA_SMART_____|
|__________self_tests______________________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_one_of_the_users_below_is_required_to________|
|__________perform_this_action.____________________________|
|__________________________________________________________|
|__________[[Face]_Patrick_Bateman_(bateman)_________[V]]__|
|__________________________________________________________|
|__________Password_for_bateman:_[______________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

   Les applications qui tournent pas sous un environnement de bureau peuvent ne pas avoir d'agent d'authentification associé avec lui. De telles applications peuvent utiliser le type PolkitAgentTextListener ou pkttyagent pour que l'utilisateur puisse s'authentifier en utilisant une interface textuelle.

Déclarer des actions

   Un mécanisme doit déclarer un jeu d'actions pour utiliser PolicyKit. Les actions correspondent aux opérations que les clients peuvent demander et sont définis dans des fichiers XML que le mécanisme install dans /usr/share/polkit-1/actions.

Les action PolicyKit sont en namespace et peuvent seulement contenir les caractères "[a-z][0-9].-". Chaque fichier XML peut contenir plus d'une action mais toutes les actions doivent être dans le même espace de nom et le fichier doit être nommé après l'espace de nom et doit avoir l'extension .policy. Le fichier XML doit avoir la déclaration doctype suivante:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"›

   L'élément policyconfig doit être présent exactement une fois. Les éléments qui peuvent être utilisés dans policyconfig incluent:

vendor Le nom du projet ou vendeur qui fournis les action dans le document XML.
vendor_url Une URL du projet ou vendeur qui fournis les action dans le document XML.
icon_name Un icône représentant le projet ou vendeur qui fournis les actions.
action Déclare une action. Le nom de l'action est spécifiée en utilisant l'attribut id et peuvent seulement contenir les caractères "[a-z][0-9].-"

   Les éléments qui peuvent être inclus dans les actions sont:

        description Une description de l'action
        message Le message affiché à l'utilisateur quand les accréditifs sont demandés.
        defaults Cet élément est utilisé pour spécifier des autorisation implicites au client

           Les éléments qui peuvent être utilisés dans defaults incluents:

                allow_any Autorisation implicite qui s'applique à tout client.
                allow_inactive Autorisation implicite qui s'applique aux clients dans les sessions inactives dans les consoles locales.
                allow_active Autorisation implicite qui s'applique aux clients dans les sessions actives dans les consoles locales.

                   Chaque élément allow_any, allow_inactive, et allow_active peuvent contenir les éléments suivants:

                        no non autorisé
                        yes autorisé
                        auth_self Authentification par le propriétaire de la session d'où vient le client requise
                        auth_admin Authentification par un utiliateur administratif est requis
                        auth_self_keep Comme auth_self mais l'autorisation est conservé pour une période brève.
                        auth_admin_keep Comme auth_admin mais l'autorisation est conservée pour une brève période.

        annotate Utilisé pour annoter une action avec une paire de clé/valeur. La clé est spécifiée en utilisant l'attribut clé et la valeur est spécifiée en utilisant la valeur attribut. Cet élément peut apparaître 0 ou plusieurs fois.
        vendor Utilisé pour remplacer le vendeur sur une base par action
        vendor_url Utilisé pour remplacer l'URL vendeur sur une base par action
        icon_name Utilisé pour remplacer le nom de l'icône sur une base par action

   Les éléments localization, description et message peuvent exister 0 ou plusieurs fois avec différents attributs xml:lang

   Pour lister les actions installées, utiliser la commande pkaction

Annotations connues

org.freedesktop.policykit.exec.path est utilisé par le programme pkexec fournis par PolicyKit.
org.freedesktop.policykit.imply (sa valeur est une chaîne contenant une liste séparée par un espace d'identifiants d'action). peut être utilisé pour définir des actions méta. La manière dont elles fonctionnent et que si un sujet est autorisé pour une action spécifiée, il est également autorisé pour toutes les autres action de l'annotation. Une utilisation typique est en définissant un shell avec un simple bouton lock qui devrait débloquer plusieurs actions pour des mécanismes distincts.
org.freedesktop.policykit.owner peut être utilisé pour définir un jeu d'utilisateurs qui peuvent demander si un client est autorisé à effectuer cette action. Si cette annotation n'est pas spécifiée, seul root peut vérifier si un client tournant sous un utilisateur différent est autorisé pour une action. La valeur de cette annotation est une chaîne contenant une liste séparée par des espaces d'entrées PolkitIdentity. par exemple "unix-user:42 unix-user:colord". Une utilisation typique est pour les processus qui tournent sous un utilisateur système au lieu de root.
^
24 décembre 2016

htmlpdflatexmanmd




polkitd

polkitd

Service PolicyKit

   polkitd fournis le service D-Bus org.freedesktop.PolicyKit1 dans le bus de message système. Les utilisateurs ou administrateurs ne devraient jamais avoir besoin de démarrer ce service vu qu'il est démarré par dbus-daemon quand une application appèlent le service.

^
07 mai 2017

htmlpdflatexmanmd




/usr/libexec/selinux/hll/pp

/usr/libexec/selinux/hll/pp

Lit un fichier .pp et affiche l'équivant CIL

   Si le fichier d'entrée n'est pas fournis, ou '-', lis depuis stdin. Si le fichier de sortie n'est pas spécifié, ou '-', affiche CIL sur stdout

^
16 septembre 2016

htmlpdflatexmanmd




ppdcfile

ppdcfile

Format de fichier source du compiler ppd de cups

Le compileur PPD de cups lit les fichiers méta qui contiennent des descriptions d'un ou plusieurs fichiers PPD à générer avec ppdc. Le format de fichier source est un fichier texte ASCII. Les informations de pilote d'imprimante peuvent être groupés en utilisant { ... }; les directives peuvent être placées n'importe où dans une ligne et sont suivies par une ou plusieurs valeurs. La liste des directives et valeurs acceptées sont:

#define name value
#elif {name | value}
#else
#endif
#font name encoding "version" charset status
#if {name | value}
#include ‹filename›
#include "filename"
#media name width length
#media "name/text" width length
#po locale "filename"
Attribute name "" value
Attribute name keyword value
Attribute name "keyword/text" value
Choice name "code"
Choice "name/text" "code"
ColorDevice boolean-value
ColorModel name colorspace colororder compression
ColorModel "name/text" colorspace colororder compression
ColorProfile resolution/mediatype gamma density matrix
Copyright "text"
CustomMedia name width length left bottom right top "size-code" "region-code"
CustomMedia "name/text" width length left bottom right top "size-code" "region-code"
Cutter boolean-value
Darkness temperature name
Darkness temperature "name/text"
DriverType type
Duplex type
Filter mime-type cost program
Finishing name
Finishing "name/text"
Font *
Font name encoding "version" charset status
Group name
Group "name/text"
HWMargins left bottom right top
InputSlot position name
InputSlot position "name/text"
Installable name
Installable "name/text"
LocAttribute name "keyword/text" value
ManualCopies boolean-value
Manufacturer "name"
MaxSize width length
MediaSize name
MediaType type name
MediaType type "name/text"
MinSize width length
ModelName "name"
ModelNumber number
Option name type section order
Option "name/text" type section order
PCFileName "filename.ppd"
Resolution colorspace bits-per-color row-count row-feed row-step name
Resolution colorspace bits-per-color row-count row-feed row-step "name/text"
SimpleColorProfile resolution/mediatype density yellow-density red-density gamma red-adjust green-adjust blue-adjust
Throughput pages-per-minute
UIConstraints "*Option1 *Option2"
UIConstraints "*Option1 Choice1 *Option2"
UIConstraints "*Option1 *Option2 Choice2"
UIConstraints "*Option1 Choice1 *Option2 Choice2"
VariablePaperSize boolean-value
Version number

^
07 juin 2010

htmlpdflatexmanmd




pr

pr

Pagination et multi-colonnes

   pr Écrit chaque fichier ou l'entrée standard sur la sortie standard, pagine et optionnellement sort en format multicolonnes et/ou regroupe tous les fichiers, imprime tout en parallèle, un par colonne.

  Par défaut, un en-tête à 5 lignes est imprimé à chaque page: 2 lignes blanches, une ligne avec la date, le nom du fichier, et le compteur de page, 2 lignes blanches. La longueur par défaut de PAGE_LENGTH est de 66 lignes. Le nombre par défaut de ligne de texte est donc de 56. La ligne de texte de l'en-tête prend la forme DATE STRING PAGE.

  Les colonnes ont une largeur égale, séparée par une chaîne optionnelle (un espace par défaut). Pour les sorties multi-colonnes, les lignes seront toujours tronquées à PAGE_WIDTH (défaut : 72). Pour les sorties simple colonne, aucune ligne n'est tronquée par défaut.

OPTIONS

+FIRST_PAGE[:LAST_PAGE, --pages=FIRST_PAGE[:LAST_PAGE] Commence à afficher avec FIRST_PAGE et stop avec LAST_PAGE.
-COLUMN, --columns=COLUMN Produit COLUMN colonnes en sortie.
-a, --across Affiche les lignes alterné sur les colonnes (type ligne1 ligne2 ligne3...)
-c, --show-control-chars Affiche les caractères de contrôle
-d, --double-space Double l'espace de sortie
-D FORMAT, --date-format=FORMAT Format l'en-tête en utilisant FORMAT, en utilisant la même convention que `date +FORMAT` (défaut : %Y-%m-%d %H :%M et si POSIXLY_CORRECT est spécifié : %b %e %H :%M %Y)
-e[IN-TABCHAR[IN-TABWIDTH]], --expand-tabs[=IN-TABCHAR[IN-TABWIDTH]] Étend les tabulations en espaces en entrée. IN-TABCHAR est le caractère de tabulation en entrée et IN-TABWIDTH et la largeur de la tabulation (par défaut 8)
-f, -F, --form-feed Utilise un saut de page au lieu de newlines pour séparer les pages de sortie. n'altère pas la longueur de page de 66 lignes.
-h HEADER, --header=HEADER Remplace le nom de fichier dans l'en-tête avec la chaine STRING
-i[OUT-TABCHAR[OUT-TABWIDTH]], --output-tabs[=OUT-TABCHAR[OUT-TABWIDTH]] Remplace les espaces avec des tabulations en sortie. OUT-TABCHAR est le caractère de tabulation, OUT-TABWIDTH est la largeur de la tabulation (défaut 8)
-J, --join-lines Fusionne les lignes de pleine longueur. Utilisé avec l'option -COLUMN, -a -COLUMN ou -m. Désactive l'option -w/-W. Aucun alignement de colonne n'est utilisé. Peut être utilisé avec --sep-string[=STRING]
-l PAGE_LENGTH, --length=PAGE_LENGTH Définit la longueur de page à PAGE_LENGTH (défaut 66 lignes) si inférieur à 10, l'en-tête et pied de page sont omis.
-m, --merge Fusionne et affiche tous les fichiers en parallèle, un dans chaque colonne. Si une ligne est trop large elle est tronquée, à moins que -J soit utilisé.
-n[NUMBER-SEPARATOR[DIGITS]], --number-lines[=NUMBER-SEPARATOR[DIGITS]] Numérote les lignes avec des nombre à DIGITS chiffres. NUMBER-SEPARATOR est le caractère entre le numéro de ligne et le texte.
-N LINE_NUMBER, --first-line-number=LINE_NUMBER Définis le numéro de la première ligne.
-o MARGIN, --indent=MARGIN Indente chaque ligne avec une marge de MARGIN espace.
-r, --no-file-warnings N'affiche pas de message d'erreur quand un fichier ne peut pas être ouvert.
-s[CHAR], --separator[=CHAR] Sépare les colonnes par un simple caractère (une tabulation par défaut sans -w et aucun caractère avec -w)
-SSTRING, --sep-string[=STRING] Utilise STRING pour séparer les colonnes en sortie. n'affecte pas -w/-W.
-t, --omit-header N'imprime pas l'en-tête usuel (et le pied de page), et ne remplit pas le bas des pages. Aucune structure de page n'est produite, la pagination pré-définie n'est pas changée. -t remplace -h
-T, --omit-pagination N'imprime pas l'en-tête (et le pied de page). Élimine toute forme de retour chariot dans le fichier d'entrée.
-v, --show-nonprinting Affiche les caractères non imprimables en notation octal
-w PAGE_WIDTH, --width=PAGE_WIDTH Définit la largeur des lignes pour les sorties multi-colonnes.
-W PAGE_WIDTH, --page_width=PAGE_WIDTH Définie la largeur des lignes. Valide avec ou sans l'option -COLUMN
^
12 juillet 2010

htmlpdflatexmanmd




printenv

printenv

Affiche les variables d'environnement

   printenv affiche les variables d'environnement. Si aucune variables n'est spécifiée, printenv affiche les valeurs de toutes les variables d'environnement.

^
11 septembre 2016

htmlpdflatexmanmd




printers.conf

printers.conf

Fichier de configuration d'imprimante pour cups

   Le fichier printers.conf définis les imprimantes locales disponible. Il est normalement dans /etc/cups et est maintenu par cupsd. Ce fichier n'est pas prévu pour être édité ou géré manuellement.

^
05 juillet 2010

htmlpdflatexmanmd




printf

printf

Afficher du texte

   printf affiche une chaine en interprétant les directives '%' et '\' pour formater des arguments.

        - L'argument est réutilisé si necessaire: ex printf %s a b affiche ab
        - Les arguments manquant sont traites comme chaîne nul ou 0, selon s'il sagit d'un chaine ou d'un nombre.
        - un \c additionnel ne produit plus de sortie.
        - la sequence hexa \xHH a 2 chiffres maximum, alors que C peut avoir un nombre illimité de chiffres.
        - si un caractère est entouré de "'" ou '"' alors affiche sa valeur numérique. printf "%d" "'a' donne 97

   Un argument virgule flottante doit utiliser une virgule, mais est affiché en accord avec la variable d'environnement LC_NUMERIC.

  printf interprète \000 en octal et \xHH en hexa.

  printf interprète \u pour les caractères unicodes 16-bits, spécifié par quatres chiffrers hexa, et \U pour les caractères unicodes 32-bits, spécifié par 8 chiffres hexa.

  Pour s'assurer d'utiliser le programme printf et non la commande intégré dans bash, lancer printf par env.

^
08 octobre 2016

htmlpdflatexmanmd




ps

ps

Afficher un instantanné des processus

   ps affiche des informations sur une sélection des processus actifs. Pour une mise à jours répétitive de la sélection, utiliser top. ps accepte plusieurs types d'options:

Options UNIX qui peuvent être groupés et doivent être précédes par un '-'
Options BSD qui peuvent être groupés et ne doivent pas être utilisé avec un '-'
Options longues GNU Qui sont précédés par '--'

   Les options des différents types peuvent être librement mixés, mais des conflits peuvent apparaître. Noter que ps -aux est distinct de ps aux. Les standards POSIX et UNIX exigent que ps -aux affiche tous les processus possédés par l'utilisateur x, et affiche tous les processus qui ont été sélectionnés par d'option -a.

   Par défaut, ps sélectionne tous les processus avec le même user ID effectif (euid=EUID) comme utilisateur cournat et associé par le même terminal que l'invoqueur. Il affiche le process ID (pid=PID), le terminal associé avec les processus (tname=TTY), le temps CPU cumulé (time=TIME), et le nom de l'exécutable (ucmd=CMD). La sortie n'est pas triée par défaut.

   L'utilisation des options de type BSD ajoute un état de processus (stat=STAT) à l'affichage par défaut et affiche les arguments de la ligne de commande (args=COMMAND) au lieu du nom de l'exécutable. Ce mode peut être changé avec la variable d'environnement PS_FORMAT. L'utilisation des options type BSD changent également la sélection de processus pour inclure les processus de tous les autres terminaux (TTYs) qui sont possédés par l'utilisateur courant.

   Excepté quand spécifié, les options de sélection de processus sont additifs.

Pour voir tous les processus dans le système en utilisant la syntaxe standard:
ps -e
ps -ef
ps -ef
ps -ely
Pour voir tous les processus dans le système avec la syntaxe BSD:
ps ax
ps axu
Pour afficher une arborescence de processus:
ps -ejH
ps axjf
Pour obtenir des informations sur les threads:
ps -eLf
ps axms
Pour obtenir les informations de sécurité:
ps -eo euser,ruser,suser,fuser,f,comm,label
ps axZ
ps -eM
Pour voir tous les processus fonctionnant sous root au format utilisateur:
ps -U root -u root u
Pour voir tous les processus avec un format définis par l'utilisateur:
ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
ps -Ao pid,tt,user,fname,tmout,f,wchan
Afficher seulement les PID de syslogd:
ps -C syslogd -o pid=
Afficher seulement le nom du PID 42:
ps -p 42 -o comm=

Sélection de simple processus

a Sélection "seulement vous-même".
-A, -e Sélectionne tous les processus.
-a Sélectionne tous les processus excepté les processus non associés avec un terminal et les leaders de session.
-d Sélectionne tous les processus excepté les têtes de session
--deselect, -N Sélectionne tous les processus excepté ceux qui remplissent les conditions spécifiées (inverse la sélection).
T Sélectionne tous les processus excepté ceux associés avec ce terminal. Identique à l'option t sans argument.
r Restreins la sélection seulement aux processus en cours de fonctionnement.
x Restriction "doit avoir un tty"

Sélection de processus par liste

   Ces options acceptent un seul argument sous la forme d'une liste séparé par ',' ou ' '. Ils peuvent être utilisés plusieurs fois. par exemple: ps -p "1 2" -p 3,4

-123, 123 Identique à --pid 123
-C cmdlist Sélectionne par nom de commande. Sélectionne les processus dont le nom de l'exécutable est dans cmdlist
-g grplist Sélectionne par session ou par nom de groupe effectif.
--Group grplist Sélection par Group ID réel ou nom.
--group grplist sélectionne par group ID effectif ou nom. Sélectionne les processus dont le nom de groupe effectif ou ID est dans grplist.
-p pidlist, -p pidlist, --pid pidlist Sélectionne par process ID
-ppid pidlist Sélectionne par PID parent.
-s sesslist, --sid sesslist Sélection par session ID.
-t ttylist, --tty ttylist Sélectionne par tty
U userlist, -u userlist, --user userlist Sélection par user ID effectif
-U userlist --User userlist Sélection par user ID effectif

Contrôles de format de sortie

   Ces options sont utilisée pour choisir les informations affichées par ps.

-c Affiche différentes informations du scheduler pour l'option -l
--context Affiche le context de sécurité (SELinux)
-f Listing complet. Peut être combiné avec d'autres options pour ajouter de colonnes. Affiche également les arguments de commande.
-F Format complet.
--format format format spécifié. Identique à -o et o
j Contrôle de job BSD
-j format de jobs
l Format long BSD
-l Format long. L'option -y est souvent utile avec lui.
-M Ajoute une colonne de données de sécurité. Identique à Z (pour SELinux)
O format Spécifier l'ordre de trie.
-O format Identique mais préchargé avec certaines colonnes par défaut. identique à -o pid,format,state,tname,time,command ou -o pidformat,tname,time,cmd
o format Format spécifié par l'utilisateur. Identique à -o et --format
-o format Format utilisateur. le format est un simple argument sous la forme d'une liste séparé par des ',' ou ' '. Les en-têtes peuvent être renommés(ps -o pid,ruser=RealUser -o comm=Command). Si tous les en-têtes sont vides (ps -o pid= -o comm=), l'en-tête n'est pas affiché. La largeur des colonnes augmente si nécessaire pour des en-tête plus large; cela peut être utilisé pour élargir les colonnes tel que WCHAN (ps -o pid,wchan=WIDE-WCHAN-COLUMN -o comm). Le contrôle de largeur explicite ps opid,wchan:42,cmd permet de le faire également.

        s Affiche le format du signal
        u Affiche le format orienté utilisateur
        v Affiche le format de mémoire virtuelle
        X Enregistre le format
        -y n'affiche pas les flag. Ne peut être utilisé qu'avec -l
        Z Ajoute une colonne de donnée de sécurité. Identique à -M (pour SELinux)

Modifieurs de sortie

c Affiche le vrai nom de la commande. c'est dérivé du nom du fichier exécutable, au lieu de la valeur de argv
--cols n, --columns n Définis la largeur de l'écran
--cumulative Inclus certaines données de processus enfant morts
e Affiche l'environnement après la commande.
f, --forest hiérarchie de processus ASCII
h Pas d'en-tête (ou un par écran dans le type BSD).
-H Affiche la hiérarchie des processus
--headers Répète les lignes d'en-tête, une par page de sortie
-k spec Spécifie l'ordre de trie. Trier la syntaxe est [+|-]key[,[+|-]key[,...]]. Utiliser un clé de la section Spécifieurs de format standard.

        exemples
        ps jaxkuid,-ppid,+pid
        ps axk comm o comm,args
        ps kstart_time -ef

--lines n Définis la hauteur d'écran
namelist, N namelist Définis le fichier namelist. Identique à N. le fichier namelist est nécessaire pour un affichage WCHAN propre, et doit correspondre à la version de Linux pour une sortie correcte. Sans cette option, le chemin de recherche par défaut pour namelist est:

        $PS_SYSMAP
        $PS_SYSTEM_MAP
        /proc/\*/wchan
        /boot/System.map-$(uname -r)
        /boot/System.map
        /lib/modules/$(uname -r)/System.map
        /usr/src/linux/System.map
        /System.map

n Sortie numérique pour WCHAN et USER (incluant tous les types de UID et GID).
--no-headers, --no-heading N'affiche pas le ligne d'en-tête.
--rows n Définis la hauteur d'écran
S Summarise les informations, tel que l'utilisation CPU, des processus enfant morts dans leur parent. Utile pour examiner un système où un processus parent forks en répétition des enfants de courte durée qui ne fonctionne pas.
--sort spec Spécifie l'ordre de trie. la syntaxe est [+|-]key[,[+|-]key[,...]]. exemple: ps jax --sort=uid,-ppid,+pid
w, -w Sortie large. Utiliser cet option 2 fois pour une largeur illimitée
--width n Définis la largeur de l'écran

Affichage des threads

H Affiche les threads comme s'ils étaient des processus
-L Affiche les threads, possiblement avec les colonnes LWP et NLWP
m, -m Affiche les threads après les processus
-T Affiche les threads, possiblement avec la colonne SPID

Autres informations

L Liste tous les spécifieurs au format long
V, -V, --version Affiche la version de procps-ng

Notes

   ps fonctionne en lisant le système de fichier virtuel /proc. ps n'a pas besoin d'être setuid kmem ni d'avoir aucun privilèges pour fonctionner. Ne pas donner à ce ps des permissions spéciales.

Ce ps doit accéder aux données namelist pour un affichage correcte de WCHAN.
L'utilisation CPU est actuellement exprimée en pourcentage de temps passé durant tous de cycle d'un processus. Ce n'est pas idéal, et n'est pas conforme au standards.
Les champs SIZE et RSS ne comptent pas certaines parties d'un processus incluant des tables de page, pile kernel, structure thread_info, et structure task_struct. C'est généralement au moins 20KiB de mémoire qui sont toujours résidents. SIZE est la taille virtuelle du processus (code+data+stack).
Les processus marqués ‹defunct› sont des processus morts (appelés zombie) qui restent parce que leur parent ne les ont pas détruit proprement. Ce processus seront détruit par init si le processus parent de termine.
Si la longueur du username est supérieur à la longueur de la colonne d'affichage, le user ID est affiché à la place.

Flags de processus

   La somme de ces valeurs est affiché dans la colonne F, qui est fournis par le spécifieur de sortie flags:

        1 Forké mais pas exécuté
        4 A utilisé les privilèges super-utilisateur.

codes d'état de processus

D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped, either by a job control signal or because it is being traced
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent

codes d'état de processus supplémentaires BSD

high-priority (not nice to other users)
N low-priority (nice to other users)
L has pages locked into memory (for real-time and custom IO)
s is a session leader
l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
+ is in the foreground process group

Spécifieurs de format standard

   Les différents mots clé qui peuvent être utilisés pour contrôler le format de sortie (ex avec l'option -o) ou pour trier les processus sélectionnés avec l'option --sort (exemple: ps -eo pid,user,args --sort user) Cette version de ps tente de reconnaître le plus de mots clés utilisé dans d'autres implémentations de ps.

   Les spécifieurs de format suivant peuvent contenir des espaces: args, cmd, comm, command, fname, ucmd, ucomm, lstart, bsdstart, start. Certains mots clé peut ne pas être disponible pour le trie.

        CODE - HEADER DESCRIPTION
        %cpu $CPU Utilisation cpu du processus au format "##.#". Actuellement, c'est le temps CPU utilisé divisé par le temps de fonctionnement du processus. (ratio cputime/realtime), exprimé en pourcentage (alias pcpu)
        %mem %MEM Ratio de la taille du jeu résident du processus de la mémoire physique sur la machine, exprimée en pourcentage (alias pmem)
        args COMMAND Commande avec tous ses arguments.
        blocked BLOCKED Masque des signaux bloqués.
        bsdstart START date de démarrage de la commande. Si le processus a démarré depuis moins de 24heures, le format est " HH:MM", sinon c'est "Mmm:SS" où Mmm est le mois sur 3 lettres.
        bsdtime TIME Temps cpu cumulé user + système.
        c C Utilisation du processeur. Actuellement, c'est une valeur entière du pourcentage d'utilisation sur la durée de vie du processus.
        caught CAUGHT Masque des signaux capturés.
        cgroup CGROUP Affiche les cgroupe auquel le processus appartient.
        class CLS Classe de scheduling du processus. Les valeurs de champ possibles sont:

                - not reported
                TS SCHED_OTHER
                FF SCHED_FIFO
                RR SCHED_RR
                B SCHED_BATCH
                ISO SCHED_ISO
                IDL SCHED_IDLE
                ? unknown value

        cls CLS idem à class
        cmd CMD voir args
        comm COMMAND Nom de la commande (seulement le nom de l'exécutable). Les modification du nom de la commande ne seront pas affichés.
        command COMMAND Voir args
        cp CP dixième de pourcentage d'utilisation CPU
        cputime TIME Temps CPU cumulatif au format [DD-]hh:mm:ss (alias time)
        egid EGID GID effecif du processus comme entier décimal
        egroup EGROUP GID effectif du processus. C'est le GID textuel, s'il peut être obtenu et que la largeur du champ le permet, ou une représentation décimal sinon (alias group)
        eip EIP Pointer d'instruction
        esp ESP Pointeur de pile
        etime ELAPSED Temps passé depuis que le processus a démarré, sous la forme [[DD-]hh:]mm:ss.
        etimes ELAPSED Temps passé depuis que le processus a démarré, en secondes
        euid EUID UID effectif (alias uid)
        euser EUSER Nom d'utilisateur effectif. C'est l'UID textuel, s'il peut être obtenu et que la largeur du champ le permet, ou une représentation décimal sinon (alias uname, user)
        flag, flags f F Flags associés avec le processus (alias flag, flags)
        fgid FGID GID d'accès du système de fichier (alias fsgid)
        fgroup FGROUP ID de groupe d'accès du système de fichier. C'est un ID de groupe textuel, s'il peut être obtenu et que la largeur de champ le permet. (alias fsgroup)
        fname COMMAND 8 premiers octets du nom de base du fichier exécutable du processus. La sortie dans cette colonne peut contenir des espaces
        fuid FUID ID utilisateur d'accès au système de fichier (alias fsuid)
        fuser FUSER ID utilisateur d'accès au système de fichier . C'est un ID utilisateur textuel, s'il peut être obtenu et que la largeur de champ le permet
        gid GID voir egid (alias egid)
        group GROUP voir egroup. (alias egroup)
        ignored, IGNORED masque des signaux ignorés (alias sig_ignore, sigignore)
        ipcns IPCNS Numéro d'inode unique décrivant l'espace de nom du process.
        label LABEL Label de sécurité, principalement utilisé par SELinux.
        lstart STARTED date/heure de démarrage de la commande. voir également bsdstart, start, start_time et stime)
        lsession SESSION Affiche l'identifiant de session de login d'un processus, si le support de systemd est inclus
        lwp LWP ID de thread de l'entité dispatchable (alias spid,tid)
        lxc LXC nom du conteneur lxc dans lequel la tâche tourne.
        machine MACHINE Affiche le nom de la machine pour les processus assigné à des VM ou conteneurs, si le support de systemd est inclus
        maj_flt MAJFLT numéro de page faults majeur qui s'est produit avec ce processus
        min_flt numéro de page faults mineur qui s'est produit avec ce processus
        mntns MNTNS Numéro d'inode unique décrivant l'espace de nom du process.
        netns NETNS Numéro d'inode unique décrivant l'espace de nom du process.
        ni NI Valeur nice.
        nice voir ni
        nlwp NLWP nombre de lwps (threads) dans le processus. Alias thcount.
        nwchan WCHAN Adresse de la fonction kernel où le processus attend.
        ouid OWNER UID de propriétaire de la session d'une processus, si le support de systemd est inclus
        pcpu %CPU (alias %cpu)
        pending PENDING Masque de signaux d'attente. Les signaux d'attente dans le processus sont distincts des signaux d'attente des threads individuels. Utiliser l'option m ou -m pour voir les 2. (alias sig)
        pgid PGID ID du groupe du processus, ou ID de processus du groupe du chef de processus (alias pgrp)
        pgrp PGRP (alias pgid)
        pid PID ID du processus (alias tgid)
        pidns PIDNS Numéro d'inode décrivant l'espace de nom auquel le processus appartient
        pmem %MEM (alial %mem)
        policy POL Classe du scheduler du processus (alias class, cls)
        ppid PPID ID du processus parent
        pri PRI Priorité du processus. Des valeur élevée signifient un priorité inférieure
        rgid RGID GID réel
        rgroup RGROUP Nom réel du groupe.
        rss RSS Resident Set Sigze, la mémoire physique non-swappée qu'une tâche a utilisé (en Ko) (alias rssize, rsz)
        rssize RSS (alias rss, rsz)
        rsz RSZ (alias rss, rssize)
        rtprio RTPRIO Realtime priority
        ruid RUID UID réel
        ruser RUSER Nom d'utilisateur réel
        s S État (sur un caractère). Voir stat. (alias state)
        sched SCH Stratégie de scheduling du processus. Les stratégies SCHED_OTHER (SCHED_NORMAL), SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_ISO, et SCHED_IDLE sont affichés respectivement 0, 1, 2, 3, 4, et 5.
        seat SEAT Identifiant associé avec tous les périphériques hardwares assignés à l'emplacement spécifique, si le support de systemd est inclus
        sess SESS ID de session, ou le PID du chef de session. (alias session, sid)
        sgi_p P Processeur sur lequel le processus est exécuté. Affiche '*' si le processus n'est pas en cours d'exécution
        sgid SGID GID sauvé (alias svgid)
        sgroup SGROUP Nom du groupe sauvé.
        sid SID (alias sess, session)
        sig PENDING (alias pending, sig_pend)
        sigcatch CAUGHT (alias caught, sig_catch)
        sigignore IGNORED (alias ignored, sig_ignore)
        sigmask BLOCKED (alias blocked, sig_block)
        size SIZE Quantité approximative d'espace swap qui est requis si le processus modifiait les pages writable puis se swapait. Ce nombre est très approximatif
        slice SLICE Affiche l'unité slice auquel appartient le processus, si le support systemd est inclus
        spid SPID (alias lwp,tid)
        stackp STACKP Adresse du bas de la pile pour le processus
        start STARTED Date à laquelle la commande a démarré. Si le processus n'a pas été démarré la même année que ps, affiche seulement l'année
        start_time START Date et heure de lancement du processus.
        state S (alias s)
        suid SUID UID sauvé. (alias svuid)
        supgid SUPGID GID des groupes supplémentaires
        supgrp SUPGRP Noms des groupes supplémentaires
        suser SUSER Nom de l'utilisateur sauvegardé
        svgid SVGID (alias sgid)
        svuid SVUID (alias suid)
        sz SZ Taille dans les pages physiques de l'image core du processus. Inclus text, data, et stack
        tgid TGID Nombre représentant le groupe de threads auquel une tâche appartient. (alias pid)
        thcount THCNT nombre de threads kernels possédés par le processus (alias nlwp)
        tid TID Nombre unique représentant une entité dispatchable. (alias lwp, spid).
        time TIME Temps CPU cumulé au format "[DD-]HH:MM:SS". (alias cputime)
        tname TTY tty contrôlant. (alias tt, tty)
        tpgid TPGID ID du groupe de processus sur le tty auquel le processus est connecté, ou -1 si le processus n'est pas connecté à un tty
        trs TRS Taille Text resident set, quantité de mémoire physique dévouée au code exécutable
        tt TT TTY controlant (alias tname, tty)
        tty TT (alias tname, tt)
        ucmd CMD (alias comm, ucomm)
        ucomm COMMAND alias (comm, ucmd)
        uid UID (alias euid)
        uname USER (alias euser,user)
        unit UNIT Unit auquel appartient le processus, si le support systemd est inclus.
        user USER (alias euser, uname)
        userns USERNS Numéro inode unique décrivant l'espace de nom auquel le processus appartient.
        utsns UTSNS Numéro inode unique décrivant l'espace de nom auquel le processus appartient.
        uunit UUNIT user le unit auquel appartient le processus, si le support systemd est inclus
        vsize VSZ (alias vsz)
        vsz VSZ Taille de mémoire virtuelle en Kio. (alias vsize)
        wchan WCHAN Nom de la fonction kernel dans lequel le processus est en attente.

Variables d'environnement

COLUMNS Change la largeur d'affichage par défaut
LINES Change la hauteur par défaut
PS_PERSONALITY posix, old, linux, bsd, sun, digital, ...
CMD_ENV posix, old, linux, bsd, sun, digital, ...
I_WANT_A_BROKEN_PS Force l'interpretation de ligne de commande obsolète
LC_TIME Format de date
POSIXLY_CORRECT Strictement Conforme à POSIX
POSIX2 À on, agit comme POSIXLY_CORRECT
UNIX95 Pas d'excuse pour ignorer les mauvaise fonctionnalités de ps
_XPG Annule CMD_ENV=irix
^
03 février 2016

htmlpdflatexmanmd




ptmx

ptmx, pts

Pseudo-terminaux maître et esclave

   Le fichier /dev/ptmx est un fichier spécial caractère avec un numéro majeur 5 et un numéro mineur 2, en mode 0666, appartenant à root:root. Il sert à créer une paire de pseudo-terminaux maître et esclave.

   Lorsqu'un processus ouvre /dev/ptmx, il reçoit un descripteur de fichier pour le pseudo-terminal maître (PTM), et un périphérique est créé pour le pseudo-terminal esclave (PTE) dans le répertoire /dev/pts. Chaque descripteur obtenu en ouvant /dev/ptmx est un PTM indépendant avec son PTE associé, dont le chemin d'accès peut être obtenu en passant le descripteur à ptsname(3).

   Avant d'ouvrir le pseudo-terminal esclave, vous devez passer le descripteur du maître à grantpt(3) et unlockpt(3). Une fois que les 2 pseudo-terminaux sont ouverts, l'esclave fournit une interface au processus qui est identique au vrai terminal.

   Les données écrites sur l'esclave se retrouvent en entrée sur le descripteur du maître. Les données écrites sur le maître se retrouvent en entrée sur l'esclave.

   En pratique les pseudo-terminaux servent à implémenter des émulateurs de terminaux comme xterm(1), dans lesquels les données lues sur le terminal maître sont interprétées par l'application de la même manière que le ferait un vrai terminal, et pour implémenter des programmes de connexion distante comme sshd dans lesquels les données lues sur le PTM sont envoyées sur le réseau à un programme client qui est connecté à un terminal ou un émulateur.

   Les pseudo-terminaux servent aussi à envoyer des données aux programmes qui refusent de lire des données depuis des tubes (comme us et passwd)

Notes

   Le support sous Linux est réalisé en utilisant le système de fichier devpts, qui devrait être monté sous /dev/pts.
^
21 juillet 2010

htmlpdflatexmanmd




ptx

ptx

Lit un fichier texte et produit essentiellement un index permuté, avec chaque mot clé dans son contexte

-G, --traditional désactive toutes les extensions GNU. Si non spécifié, on peut spécifier plusieurs fichiers ou aucun.

Sélection de jeu de caractères

-f, --ignore-case met les minuscules en majuscule pour le trie. ptx assume que le fichier d'entrée est en ISO 8859-1 (latin-1).

Sélection de mot et traitement d'entrée

-b FILE, --break-file=FILE Option alternative à -W décrivant quels caractères composent les mots. il introduit le nom d'un fichier qui contient une liste de caractères qui ne peuvent pas faire partie d'un mot.
-i FILE, --ignore-file=FILE Le fichier associé avec cette option contient une liste de mots qui ne seront jamais comme mot clé.
-o FILE, --only-file=FILE Le fichier associé avec cette option contient une liste de mots qui seront retenus pour la sortie.
-r, --references Sur chaque ligne d'entrée, la séquence principale de caractères non-blanc seront pris pour référence pour identifier cette ligne dans l'index permuté.
-S REGEXP --sentence-regexp=REGEXP Cette option sélectionne quelle expression régulière va décrire la fin d'une ligne ou la fin d'une phrase. En fait, cette expression n'est pas seulement la distinction entre la fin des lignes ou la fin des phrases, et les limites de la ligne d'entrée n'ont pas de signification spécial en dehors de cette options. si -G et -r ne sont pas spécifiés, ce REGEX est importé :

           [.?!][]\"')]*\\($\\|\t\\| \\)[ \t\n]* sinon (si -r est spécifié) regex est: \n

  Utiliser un REGEX vide désactive la reconnaissance de la fin des ligne ou des phrases.

-W REGEXP, --word-regexp=REGEXP Cette option décrit quelle expression va décrire chaque mot clé. par défaut, si -G n'est pas spécifié, un mot est une séquence de lettres; le REGEXP utilisé est \w+ sinon un mot est quelque chose qui se termine par un espace, une tabulation ou un newline, le REGEXP utilisé est [^ \t\n]+

Formattage de sortie

-g NUMBER, --gap-size=NUMBER Sélectionne l'écart minimum d'espace blanc entre les champs sur la ligne de sortie.
-w NUMBER, --width=NUMBER Sélectionne la largeur maximum de sortie de chaque ligne.
-A, --auto-reference Sélectionne les références automatique. chaque ligne en entrée aura une référence automatique composé du nom du fichier et la ligne, avec une ',' entre eux.
-R, --right-side-refs Dans le format de sortie par défaut, si cette option n'est pas spécifiée, les références produite par l'effet des options -r ou -A sont placées à droite des lignes sorties, après le contexte. avec cette options, les références sont placées au début de chaque ligne en sortie.
-F STRING, --flac-truncation=STRING Si la sortie est tronquée, reporte en utilisant STRING
-m STRING, --macro-name=STRING Sélectionne une autre STRING à utiliser au lieu de 'xx', en générant une sortie utilisable par nroff ou troff ou TeX
-o, --format=roff Sélectionne un format de sortie pour le traitement par nroff ou troff. Chaque ligne de sortie ressemblera à: .xx "TAIL" "BEFORE" "KEYWORD_AND_AFTER" "HEAD" "REF"
-T, --format=tex Choisit un format de sortie utilisable par TeX. chaque ligne de sortie ressemblera à: \xx TAILBEFOREKEYWORDAFTERHEADREF
^
03 février 2016

htmlpdflatexmanmd




pty

pty

Interfaces de pseudo-terminaux

   Un pseudoterminal (abrégé pty) est une paire de périphériques caractères virtuels qui fournissent un canal de communication bidirectionnelle. Un bout du canal est appelé le maître, l'autre est appelé esclave. Le bout esclave du pseudo-terminal fournit une interface qui se comporte exactement comme un terminal classique. Un processus qui s'attend à être connecté à un terminal peut ouvrir le bout esclave d'un pseudo-terminal puis être piloté par un programme qui a ouvert le bout maître. Tout ce qui est écrit sur le maître est fourni au processus sur l'esclave comme si c'était écrit sur un terminal. Par exemple, écrire le caractère d'interruption (généralement ctrl-C) sur le périphérique maître cause l'envoi d'un signal d'interruption SIGINT au groupe de processus qui est connecté à l'esclave. Réciproquement, tout ce qui est écrit sur l'esclave peut être lu par le processus qui connecté au maître. Les pseudo-terminaux sont utilisé par des application telles que des services de login à distance (ssh, rlogin, telnet), les émulateurs de terminaux, script, screen, et expect.

   Historiquement, 2 API de pseudo-terminaux ont évolués: BSD et System V. SUSv1 a standardisé une API de pseudo-terminal basée sur l'interface System V, et cette API doit être utilisée dans tous les nouveaux programmes qui utilisent des pseudo-terminaux.

   Linux fournit à la fois des pseudo-terminaux de type BSD et de type System V (standardisés). Les terminaux de type System V sont souvent appelés pseudo-terminaux UNIX 98 sur les systèmes Linux. Depuis Linux 2.6.4, les pseudo-terminaux de type BSD sont considérés obsolètes.

Pseudoterminaux UNIX 98

   Un maître est ouvert en appelant posix_openpt(3). Cette fonction ouvre le périphérique de clonage de maître, /dev/ptmx; Une fois initialisé le périphérique, changé le propriétaire et les permissions du périphérique esclave avec grantpt(3), et déverrouillé l'esclave avec unlockpt(3), le périphérique esclave correspondant peut être ouvert en passant le nom renvoyé par ptsname(3) dans un appel à open(2).

   Le noyau Linux impose une limite au nombre de pseudo-terminaux UNIX 98 disponibles. La limite est ajustable de façon dynamique par le fichier /proc/sys/kernel/pty/max, et le fichier /proc/sys/kernel/pty/nr indique combien de peudoterminaux sont actuellement utilisés.

Pseudoterminaux BSD

   Les pseudo-terminaux de type BSD sont fournis par paires précréées, avec des noms sous la forme /dev/ptyXY (maître) et /dev/ttyXY (esclave), ou X est une lettre de l'ensemble de 16 caractères [p-za-e], et Y est une lettre de l'ensemble de 16 caractères [0-9a-f]. Un processus trouve un pseudo-terminal inutilisé en essayant d'ouvrir chaque maître de pseudo-terminal avec open(2) jusqu'à ce qu'une ouverture réussisse.

Fichiers

/dev/ptmx Périphérique de clonage de maître UNIX 98
/dev/pts/0 /dev/pts/1 /dev/pts/2 /dev/pts/3 /dev/pts/ptmx Périphériques esclaves UNIX 98
/dev/pty[p-za-e][0-9a-f] périphériques maîtres BSD
/dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 /dev/ttyS4 /dev/ttyS5 /dev/ttyS6 /dev/ttyS7 /dev/ttyS8 /dev/ttyS9 périphériques esclaves BSD

Notes

   Une description de l'ioctl TIOCPKT qui contrôle l'opération en mode paquet, se trouve dans tty_ioctl(4).
^
02 janvier 2017

htmlpdflatexmanmd




pulse-client.conf

pulse-client.conf

Fichier de configuration client PulseAudio

   La librairie cliente PulseAudio lit ses directives de configuration depuis un fichier au démarrage. Si le fichier par-utilisateur ~/.config/pulse/client.conf existe, il est utilisé, sinon, /etc/pulse/client.conf est utilisé. De plus, des directives peuvent également être placés dans ~/.config/pulse/client.conf.d/ et /etc/pulse/client.conf.d/. Ces fichiers doivent se terminer par .conf, et sont traités alphabétiquement.

Directives

default-sink= sink par défaut auquel se connecter. La variable $PULSE_SINK a précédence
default-source= Source par défaut à laquelle se connecter. $PULSE_SOURCE a précédence
default-server= Serveur par défaut auquel se connecter $PULSE_SERVER a précédence
autospawn= Démarre automatiquement un service pulseaudio quand nécessaire. Défaut: yes
daemon-binary= Chemin du service pulseaudio à lancer si autospawn est à yes.
extra-arguments= Arguments à passer au service pulseaudio. Défaut: --log-target=syslog
cookie-file= Spécifie le chemin du cookie d'authentificatino pulseaudio. Défaut: ~/.config/pulse/cookie
enable-shm= Active le transfert de donnée via POSIX ou via mémoire partagée memfd. Défaut: yes
enable-memfd= Active le tranfert de données via memfd. Défaut: yes
shm-size-bytes= Définis la taille de segment mémoire partagé pour les clients, en octets. Le défaut dépend du système, généralement 64 Mio.
auto-connect-localhost= Tente automatiquement de se connecter à localhost via IP. Risque de sécurité. Défaut: no
auto-connect-display= Tente automatiquement de se connecter à $DISPLAY de X11 si définis. Risque de sécurité. Défaut: no.
^
02 janvier 2017

htmlpdflatexmanmd




pulse-daemon.conf

pulse-daemon.conf

fichier de configuration du service pulseaudio

   pulseaudio lit ses directives de configuration dans ~/.config/pulse/daemon.conf s'il existe, sinon /etc/pulse/daemon.conf. De plus, les fichiers dans ~/.config/pulse/daemon.conf.d/ et /etc/pulse/daemon.conf.d/. Noter que le serveur lit également un script de configuration au démarrage (default.pa)

Directives générales

daemonize= (bool) Lance en tâche de fond après le démarrage
fail= (bool) Échoue le démarrage si une des directives dans default.pa échoue
allow-module-loading= (bool) autorise ou non le chargement de modules après le démarrage. Désactivé par défaut pour des raisons de sécurité
allow-exit= (bool) Autorise ou non l'arrêt à la demande des utilisateurs. Défaut: yes
resample-method= Algorithme de resampling à utilise. (src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, src-zero-order-hold, src-linear, trivial, speex-float-N, speex-fixed-N, ffmpeg, soxr-mq, soxr-hq, soxr-vhq).
enable-remixing= (bool) Désactivé, les cannaux upmix ou downmix ne sont jamais dans des canaux différents, mais fait un simple match basé sur le nom. Défaut: yes
enable-lfe-remixing= (bool) Si désactivé, upmixing ou downmixing ignorent les canaux LFE. Défaut: no
lfe-crossover-freq= Fréquence crossover en Hz pour le filtre LFE. 0 désactive le filtre LFE. Défaut: 0
use-pid-file= (bool) Crée un fichier PID dans le répertoire courant ($XDG_RUNTIME_DIR/pulse/pid). Si activé, permet d'utiliser des commandes comme --kill ou --check. Si vous prévoyez de lancer plus d'une instance par utilisateur, il est mieux de désactiver cette option.
cpu-limit= Si désactivé, n'install pas le limiteur de charge CPU.
system-instance= (bool) Lance le service en mode système
local-server-type= Utile si l'on souhaite que les clients D-Bus utilisent un serveur distant. Ne plus utiliser cette option
enable-shm= (bool) Active le transfert de données via POSIX ou memfd. Défaut: yes
enable-membf= (bool) Active la mémoire partagée memfd. Défaut: no
shm-size-bytes= Définis la taille de segment mémoire partagé pour le service, en octets. Non spécifié ou à 0, une valeur par défaut, généralement 64MiO est utilisé.
lock-memory= Bloque le processus PulseAudio entier en mémoire. Défaut: no.
flat-volumes= Active les volumes flat, par ex, où il est possible de laisser le volume sink égal au maximum des volumes des entrées qui y sont connectés. Défaut: yes

Scheduling

high-priority= Renice le service après le redémarrage pour devenir un processus haute-priorité. Défaut: yes
realtime-scheduling= Tente d'acquérir le scheduling SCHED_FIFO pour les threads IO.
realtime-priority= priorité temps-réel à acquérir. Note: JACK utilise 10 par défaut, 9 pour les clients. Il est donc recommandé d'utiliser une valeur plus basse. Défaut: 5
nice-level= Niveau nice à acquérir pour le service. Défaut: -11

Temps d'inactivité

exit-idle-time= Termine le service après que le dernier client quitte et que ce délai spécifié en seconde est passé. Défaut: 20
scache-idle-time= vide les entrées du cache de sample autochargés après ce délai en seconde sans activité. Défaut: 20

Paths

dl-search-path= Chemin où rechercher les objets partagés.
default-script-file= fichier script de configuration à charger. Défaut: ~/.config/pulse/default.pa, ou /etc/pulse/default.pa
load-default-script-file= Charge le script de configuration par défaut spécifié dan default-script-file. Défaut: yes

Logging

log-target= cible des logs: stderr, syslog, journal, auto, file:PATH ou newfile:PATH
log-level= debug, info, notice, warning ou error
log-meta= ajoute l'emplacement du code dans les messages loggés. Défaut: no
log-time= Ajoute un horodatage aux messages loggés. Défaut: no
log-backtrace= Supérieur à 0, avec chaque message loggé, ajoute un stack trace jusqu'au nombre de stack frames spécifié. Défaut: 0

Limites de ressource

   Voir getrlimit(2) pour plus d'informations. Définir à -1 si PulseAudio ne devrait pas toucher aux limites de ressource:

rlimit-as Défaut: -1
rlimit-rss Défaut: -1
rlimit-core Défaut: -1
rlimit-data Défaut: -1
rlimit-fsize Défaut: -1
rlimit-nofile Défaut: -1
rlimit-stack Défaut: -1
rlimit-nproc Défaut: -1
rlimit-locks Défaut: -1
rlimit-sigpending Défaut: -1
rlimit-msgqueue Défaut: -1
rlimit-memlock Défaut: 16 Kio. Noter que les librairies clients JACK peuvent nécessiter plus de mémoire bloqué.
rlimit-nice Défaut: 31
rlimit-rtprio Défaut: 9
rlimit-rttime Défaut: 1000000

   De nombreux pilotes tentent d'ouvrir le périphérique audio avec ces paramètres et retournent des plus faibles paramètres. Les paramètres par défaut sont équivalent à un CD: 16bits, 2 canaux, 44100Hz.

default-sample-format= Format de sampling par défaut: u8, s16le, s16be, s24le, s24be, s24-32le, s24-32be, s32le, s32be, float32le, float32be, ulaw, alaw
default-sample-rate= Fréquence d'échantillonnage
default-sample-channels= Nombre de canaux par défaut
default-channel-map channel map par défaut
alternate-sample-rate Fréquence d'échantillonnage alternatif

Paramètres de fragment par défaut

   Certains pilotes nécessitent que le tampon de lecture hardware soit subdivisé en plusieurs fragments. Il est possible de changer ces métriques pour les machines avec des latences de scheduler hautes.

default-fragments= Nombre de fragments par défaut. Défaut: 4
default-fragment-size-msec= Durée d'un seul fragment. Défaut: 25ms, donc un total de 100ms

Paramètres de volume déferrés

   Avec la fonctionnalité de volume plat, le volume HW sink est mis au même niveau que le flux d'entrée ayant le plus fort volume. tout autre flux est ajusté dans SW. Certains mixers hardware ne peuvent pas être ajustés précisemment et le changement de volume peut créer des problèmes en sortie. Pour s'assurer que les volumes SW et HW sont appliqués correctement, leur application doit être synchronisé. Les paramètres suivants peuvent être définis pour affiner le processus:

enable-deferred-volume= Active le volume déférré pour les sinks qui le supporte. Activé par défaut
deferred-volume-safety-margin-usec= Délai en usec par lequel l'augmentation de volume HW est retardé et la diminution de volume HW est avancée. Défaut: 8000usec
deferred-volume-extra-delay-usec= Délai en usec par lequel le changement de volume HW est retardé. des valeurs négatives sont acceptées. Défaut: 0
^
02 janvier 2017

htmlpdflatexmanmd




pulseaudio

pulseaudio

Système de son pulseaudio

   PulseAudio est un serveur de son faible latence pour Linux.

OPTIONS

--version Affiche la version
--dump-conf Charge le fichier de configuration daemon.conf, puis les options sur la ligne de commande, et dump la configuration résultante.
--dump-modules Liste les modules disponible. -v affiche des informations supplémentaires
--dump-resample-methods Liste les resamplers audio disponible
--cleanup-shm Identifie les segments mémoire partagés POSIX de PulseAudio blockés dans /dev/shm et les supprime si possible. C'est fait implicitement quand un nouveau service démarre ou qu'un client tente de se connecter à un service.
--start Démarre PulseAudio s'il ne tourne pas déjà. C'est différent de démarrer PulseAudio sans --start qui échoue si PA fonctionne déjà.
-k,--kill Termine un service en cour de fonctionnement. Équivalent à envoyer SIGTERM
--ckeck Retourne 0 si pulseaudio est déjà en cour de fonctionnement.
--system[=BOOL] Lance une instance système. Noter que cela désactive certaines fonctionnalités de pulseaudio et n'est généralement pas recommandé. Cette fonctionnalité nécessite une configuration spéciale et un utilisateur UNIX dédié.
-D,--daemonize[=BOOL] Met en tâche de fond. no pour systemd
--fail[=BOOL] Échoue le démarrage quand une des commandes spécifiés dans le script de démarrage default.pa échoue.
--high-priority[=BOOL] Tente d'aquérir un haut niveau de priorité. Ne réussit que si l'utilisateur appelant a une limite de ressource RLIMIT_NICE différent de 0, ou appelé avec SUID root.
--realtime[=BOOL] Tente d'acquérir un temps réel pour les threads d'E/S PulseAudio. Ne réussit que si l'utilisateur appelant a une limite de ressource RLIMIT_RTPRIO mis, ou appelé avec SUID root.
--disallow-module-loading[=BOOL] Désactive le chargement de module au démarrage. C'est une fonctionnalité de sécurité recommandé quand --system est utilisé. Cependant, cela casse certaines fonctionnalités.
--disallow-exit[=BOOL] Interdit un utilisateur de demander l'arrêt du processus.
--exit-idle-time=SECS Termine le service au bout de SECS seconde en pause
--scache-idle-time=SECS Décharge les samples autochargés du cache s'il ne sont pas utilisé durant le temps spécifié
--log-level[=LEVEL] Niveau de log, de 0 à 4 (error, warn, notice, info, debug). Défaut: notice
-v, --verbose mode verbeux
--log-target={auto,syslog,journal,stderr,file:PATH,newfile:PATH} Spécifie la cible des log.
--log-meta[=BOOL] Affiche le code source dans les logs
--log-time[=BOOL] Affiche l'horodatage dans les logs
--log-backtrace=FRAMES Quand FRAMES est supérieur à 0, log pour chaque message un trace de la pile jusqu'au nombre de stack frames spécifié.
-p, --dl-search-path=PATH Définis le chemin de recherche pour les objets partagés
--resample-method=METHOD Utilise le resampler spécifié par défaut (voir --dump-resample-methods pour les valeurs possibles)
--use-pid-file[=BOOL] Créé un fichier PID. Si désactivé, permet de lancer plusieurs serveurs de son par utilisateur.
--no-cpu-limit[=BOOL] N'install pas de limiteur de charge CPU. Par défaut, pulseaudio se termine lui-même s'il consomme trop de cpu.
--disable-shm[=BOOL] les clients et les serveurs peuvent échanger des données audio via POSIX ou des segments de mémoire partagés memfd. Si désactivé, pulseaudio communique exclusivement via des sockets. Noter que memfd est toujours désactivé avec --system.
--enable-memfd[=BOOL] Les clients et les serveurs peuvent échanger des données audio via memfd ( le mécanisme de mémoire partagé anonyme Linux ). Si désactivé, pulseaudio communique via mémoire partagé POSIX.
-L,--load="MODULE ARGUMENTS" Charge le module spécifié
-F, --file=FILENAME Lance le script spécifié au démarrage. Peut être spécifié plusieurs fois. Combiner avec -n pour désactiver le chargement du script par défaut (default.pa)
-C Ouvre un interpréteur de commande après de démarrage. Équivalent à --load=module-cli.
Ne charge pas le script par défaut default.pa. Utile avec -C ou --file

Fichiers

~/.config/pulse/daemon.conf
/etc/pulse/daemon.conf Paramètres de configuration pour le service PulseAudio.
~/.config/pulse/default.pa
/etc/pulse/default.pa Script de configuration par défau.
~/.config/pulse/client.conf
/etc/pulse/client.conf Paramètres de configuration pour les applications clients PulseAudio.

Signaux

SIGINT, SIGTERM Stop le service
SIGHUP dump un rapport long sur stdout ou syslog
SIGUSR1 Charge module-cli
SIGUSR2 Charge module-cli-protocol-unix

Users et groupes UNIX

Le groupe pulse-rt: Si le binaire PulseAudio est marqué SUID root, alors l'appartenance de l'utilisateur appelant dans ce groupe décide si le scheduling temps réel et/ou haute priorité est activé.
Le groupe pulse-access: Si PulseAudio est lancé en service système, l'accès est donné à tous les membres de ce groupe quand ils sont connectés via des sockets AF UNIX.
User/Groupe pulse: Si PulseAudio est lancé en service système et lancé en root, bascule dans ce user/group.

Scheduling temps-réel et haute-priorité

   Pour minimiser les risques de suppression durant la lecture il est recommandé de lancer pulseaudio avec un scheduling temps-réel. Cela découple la latence du service de la charge système et donc est la meilleur manière de s'assurer que PulseAudio obtient toujours le temps CPU quand il en a besoin. Cependant c'est un risque de sécurité, vu que pulseaudio tourne sous un processus, avec les privilèges de scheduling temps-réel, l'utilisateur peut mal l'utiliser et bloquer le système.

   Pour minimiser le risque, pulseaudio n'active pas le temps réel par défaut. Il est cependant recommandé de l'activer dans des systèmes sûre. Vu que le scheduling realtime est une opération privilégiée, certains changements sont nécessaire pour le permettre. 2 options sont disponibles:

   La limite RLIMIT_RTPRIO peut être utilisé pour permettre aux utilisateurs d'aquérir le scheduling temps-réel. Une limite de ressource de 9 est recommandé.

   Alternativement, le bit SUID root peut être définis pour le binaire pulseaudio. Donc le service obtiens les privilèges root. Cependant, conserver CAP_NICE, mais seulement si l'utilisateur appelant est un membre du groupe pulseaudio. Pour tous les autres utilisateurs toutes les capabilities sont supprimés. L'avantage est que les privilèges temps-réel sont seulement autorisés au service pulseaudio, pas à tous les processus de l'utilisateur.

   Alternativement, si le risque de bloquage de la machine est considéré trop grande, un scheduling de haute priorité peut être activé au lieu d'un scheduling temps-réel en utilisant --high-priority. Une limite de ressource RLIMIT_NICE à 31 ( un niveau nice -11) est recommandé.

Variables d'environnement

PULSE_SERVER Spécifie le serveur auquel se connecter quand un client demande une connexion à un serveur de son. Cette chaîne est une liste d'adresses séparés par un espace blanc. (unix:, tcp:, tcp4:, tcp6:)
PULSE_SINK nom symbolique du sink auquel se connecter quand un client créé un flux playback et ne demande pas explicitement un sink spécifique.
PULSE_SOURCE nom symbolique de la source à laquelle se connecter quand un client créé un flux d'enregistrement et ne demande pas de source spécifique.
PULSE_BINARY Chemin du binaire PulseAudio
PULSE_CLIENTCONFIG Chemin du fichier que devrait être lu au-lieu de client.conf
PULSE_COOKIE Chemin du fichier qui contient le cookie d'authentification PulseAudio. Défaut: ~/.config/pulse/cookie
^
20 juin 2016

htmlpdflatexmanmd




pv

pv

Superviser la progression des données via un pipe

   pv affiche la progression des données via un pipeline en donnant des informations tel que le temps passé, le pourcentage complété (avec barre de progression), Taux, total transféré, et ETA. Pour l'utiliser, l'insérer dans un pipeline entre 2 processus, avec les options appropriées. Son entrée standard sera passé à sa sortie standard et la progression sera affichée sur l'erreur standard. pv copie chaque fichier fournis en retour sur la sortie standard. Si aucun fichier n'est spécifié, copie simplement l'entrée standard, et fonctionne comme cat.

Options d'affichage

-p, --progress Active la barre de progression. Si l'entrée standard n'est pas un fichie et qu'aucune taille n'est donnée, la barre ne peut pas indiquer la progression, et se déplace donc de gauche à droite pour indique que les données sont en cours de déplacement
-t, --timer Active le timer. Affiche le temps passé total.
-e, --eta Active le timer ETA. Il tente de le deviner, basé sur les taux de transfert précédents et la taille totale des donnée.
-I, --fineta Active le timer ETA, mais affiche la date locale estimée de l'arrivée au lieu du temps passé.
-r, --rate Active le compteur de taux.
-a, --average-rate Affiche le compteur moyen de taux
-b, --bytes Affiche le compteur d'octets total
-T, --buffer-percent Active l'affichage du % de tampon transféré.
-A, --last-written NUM Affiche les dernier NUM octets écris
-F, --format FORMAT Ignore les options -p, -t, -e, -r, -a- -b, -T et -A et utilise le format spécifié pour déterminer le format de sortie.
-n, --numeric Sortie numérique. Au lieu de donner une indication visuelle de la progression, pv donne un entier en %, un par ligne, sur l'erreur standard.
-q, --quiet Pas de sortie. Utile avec -L

Options de sortie

-W, --wait Attend que le premier octet soit transféré avant d'afficher la barre de progression ou calculer tout ETA.
-D, --delay-start SEC Attend le délai spécifié avant afficher les informations de progression
-s SIZE, --size SIZE Assume que la quantité totale de données à transférer est SIZE octets en calculant les pourcentages et les ETA.
-l, --line-mode Au lieu de compter les octets, compte les lignes.
-0, --null Compte les lignes terminées par un caractère null. implique --line-mode
-i SEC, --interval SEC délai de mise à jours. (défaut: toutes les secondes)
-w WIDTH, --width WIDTH Assume que le terminal fait WIDTH caractères de large (défaut: 80 s'il ne peut pas le deviner)
-H HEIGHT, --height HEIGHT Assume que le terminal fait HEIGHT lignes de haut (défaut: 25 s'il ne peut pas le deviner)
-N NAME, --name NAME Préfixe les informations de sortie avec le nom spécifié.
-f, --force Force la sortie. Normalement, pv ne sort pas d'affichage visuel si l'erreur standard n'est pas un terminal.
-c, --cursor Utilise les séquences de positionning du curseur au lieu des retours charriot.

Options de transfert

-L RATE, --rate-limit RATE Limite le taux de transfert
-B BYTES, --buffer-size BYTES Utilise une taille de tampon de transfers à la taille spécifiée
-C, --no-splice N'utilise jamais splice(2), même si c'est possible. cet appel système est une manière plus efficace de transférer des données dans un pipe que read(2) et write(2), mais signifie que le tampon de transfert ne peut pas être utilisé. Cela empêche -A et -T de fonctionner.
-E, --skip-errors Ignore les erreurs de lecture en tentant de sauter ces sections. (similaire à dd conv=sync, noerror)
-S, --stop-at-size Si une taille est spécifiée avec -s, stop le transfert une fois cette taile atteinte.
-d PID[:FD], --watchfd PID[:FD] Au lieu de transférer des données, lit de descripteur de fichier du PID spécifié.
-R PID, --remote PID Si PID est une instance de pv qui est déjà en cours de fonctionnement, cette option force cette instance à agir comme si elle avait été donnée sur la ligne de commande.

Options générales

-P FILE, --pidfile FILE Sauve le PID de pv dans le fichier spécifié.

Formattage

   l'option -F permet de déterminer le format de sortie. les séquences suivantes peuvent être utilisées:

%p Barre de progression. Équivalent à -p
%t Temps passé. Équivalent à -e
%e Temps restant ETA. Équivalent à -e
%I Temps local ETA restant. Équivalent y -I
%r Taux de transfert de données courant. Équivalent à -r
%a Taux de transfert moyen des données. Équivalent à -a
%b Octets transférés. Équivalent à -b
%T % de tampon de transfert utilisé. Équivalent à -T
%nA Affiche les derniers n octets écrits.
%N préfix à ajouter. Équivalent à -N
%% le caractère %

Codes de sortie

1 Indique un problème avec les options -R ou -P
2 Un ou plusieurs fichiers ne peuvent pas être accedés, stat(2) ou ouverts
4 Un fichier d'entrée est le même que le fichier de sortie
8 Erreur interne avec la fermeture d'un fichier ou en passant au fichier suivant
16 Erreur en transférant des données
32 Un signal a fait quitté prématurément
64 Erreur d'allocation mémoire

Exemples

voir la vitesse de transfert de fichie avec nc:
pv file | nc -w 1 somewhere.com 3000
transférer un fichier d'un autre processus et passer la taille attendue à pv:
cat file | pv -s 12345 | nc -w 1 somewhere.com 3000
Exemple plus complexe utilisant une sortie numérique pour aller dans dialog pour un affichage de progression plein-écran
(tar cf - . | pv -n -s $(du -sb . | awk '{print $1}') | gzip -9 › out.tgz) 2›&1 | dialog --gauge 'Progress' 7 70
Prend une image d'un disque, en sautant les erreurs:
pv -EE /dev/sda › disk-image.img
Écrire une image dans un disque
pv disk-image.img › /dev/sda
Remplir un disque de 0. Noter que si l'entrée ne peut pas être calculée, et que la sortie est un périphérique block, la taile du périphérique block sera utilisé et pv stopera automatiquement à cette taille.
pv ‹ /dev/zero › /dev/sda
Voir le descripteur 3 ouvert par un autre processus:
pv -d 1234:3
Voir tous les descripteurs de fichier utilisés par le processus 1234
pv -d 1234
^
23 mai 2016

htmlpdflatexmanmd




pvchange

pvchange

Change les attributs d'un volume physique

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-f|--force Ne demande pas confirmation
--deltag Tag Supprime le tag spécifié
--metadataignore {y|n} Ignore ou on les zones de métadonnées dans ce volume physique. Si ces zones sont ignorées, LVM ne stocke pas de métadonnées dans ces zones dans ces volumes physiques
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-a|--all Si le chemin du PV n'est pas spécifié sur la ligne de commande, tous les volumes physiques sont recherchés
-x|--allocatable {y|n} Active/désactive l'allocation d'extents physique dans ce volume physique
-u|--uuid Génère un nouvel UUID aléatoire pour les volumes physiques spécifiés

Exemples

Désactiver l'allocaction d'extents physiques:
pvchange -x n /dev/sdk1
^
23 mai 2016

htmlpdflatexmanmd




pvck

pvck

Vérifier les métadonnées des volumes physiques

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--labelsector sector Par défaut, 4 secteurs du volume physique sont scannés pour un label LVM, en commençant au secteur 0. Ce paramètre permet de spécifier un secteur différent de départ. par exemple supposons une table de partition corrompue ou perdu dans /dev/sda, mais vous suspectez qu'il y avait une partition LVM à 100MiB. Cette zone du disque peut être scannée en utilisant la valeur 204800 (100*1024*1024/512)
^
06 juin 2016

htmlpdflatexmanmd




pvcreate

pvcreate

initialiser un disque ou une partition pour LVM

   Initialise le périphériques pour l'utiliser avec LVM. Chaque volume physique peut être un disque, une partition, un fichier loopback ou un périphérique méta. Pour les partitions DOS, l'id de partition devrait être 0x8e. Pour une partition GPT, l'id est E6D6D379-F507-44C2-A23C-238F2A3DF928. Pour les disques entiers, la table de partition doit être effacée.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-f[f]|--force [--force Force la création sans confirmation
-y|--yes Répond yes à toutes les questions
--labelsector Par défaut le PV est labelisé avec un identifiant LVM dans son second secteur. Cette option permet d'utiliser un secteur différent au défaut du disque (entre 0 et 3).
--bootloaderareasize size Créé une zone bootloader séparé de taille spécifiée à côté des données dans laquelle lvm n'alloue pas d'extents. Le début de cette zone est toujours alignée. Pour voir cette zone, utiliser pvs -o +pv_ba_start,pv_ba_size
-M|--metadatatype type Spécifie quel type de métadonnée à utiliser
--[pv]metadatacopies NumberOfCopies Nombre de zones de métadonées à définir dans chaque PV (0, 1 ou 2). à 2, 2 copies des métadonnées du VG sont maintenus dans le PV, une avant, et une à la fin.
--metadatasize size Quantité d'espace approximative à définir pour chaque zone de métadonnées. La taille peut être arrondie.
--metadataignore {y|n} Ignore ou non les zones de métadonnées dans ce volume physique. Si ces zones sont ignorées, LVM ne stocke pas de métadonnées dans ces zones dans ces volumes physiques
--dataalignment alignment Aligne le début des données à un multiple de ce nombre. Ensuite, en créant un VG, physicalExtentSize devrait être spécifié de manière approprié.
--dataalignmentoffset alignment_offset Décale le début de la zone des données
--restorefile file avec --uuid, extrait l'emplacement et la taile des données dans le PV depuis le fichier (produit par vgcfgbackup) et s'assure que les métadonnées que le programme produit est consistant.
--norestorefile Avec --uuid, permet de spécifier un uuid sans fournir un backup des métadonnées
--setphysicalvolumesize size Remplace la taille automatiquement détectée du PV.
-u|--uuid uuid Définis l'uuid pour le périphériques
-Z|--zero {y|n} Spécifie si les 4 premiers secteurs (2048octets) du périphériques devraient être effacés.

Exemples

Initialise la partition 4 sur un disque SCSI et le 5ème disque SCSI:
pvcreate /dev/sdc4 /dev/sde
Si le 2ème disque est un disques avec des secteurs de 4Kio qui compensent pour le partitionnement windows (le secteur 7 est le block logique le plus bas alligné, les serveurs 4Kio commencent à LBA -1, et en consequence le serveur 63 est aligné sur les limites 4Kio), le définir manuellement:
pvcreate --dataalignmentoffset 7s /dev/sdb
^
24 mai 2016

htmlpdflatexmanmd




pvdisplay

pvdisplay

Affiche les attributs d'un volume physique

   pvdisplay permet de voir les attributs d'un ou plusieurs volumes physiques comme la taille, taille d'extents physique, espace utilisé pour les métadonnées, etc.

OPTIONS

-c|--colon Génère une sortie séparée par des ',' pour simplifier le traitement pas des scripts. pvs a un meilleur contrôle sur la sortie.
-C|--columns Affiche la sortie en colonnes, l'équivalent de pvs.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--maps Affiche le mapping des extents physiques aux volumes logiques et extents logiques.
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-s|--short Affiche seulement la taille des volumes physique donné
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-v[v]|--verbose Mode verbeux
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
-a|--all Inclus des informations sur les périphériques qui n'ont pas été initialisé avec pvcreate
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes donnéespv_all sélection toutes les colonnes de volume physique, et pvseg_all sélectionne toutes les colonnes de segment de volume physique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
^
25 mai 2016

htmlpdflatexmanmd




pvmove

pvmove

Déplacer des extents physiques

   pvmove permet de déplacer des extents physiques alloués dans un PV vers un ou plusieurs auters VG. On peut optionnellement spécifier un volume logique auquel cas seul les extents utilisés par ce LV seront déplacés. Si aucun PV de destination n'est spécifié, les règles d'allocation normales pour le volume group sont utilisés.

   pvmove fonctionne comme suit:

1. Un volume logique temporaire pvmove est créé pour stocké les détails de tous les mouvements de données requis.
2. Tout volume logique dans le volume group est recherché pour les données contigues qui doivent bouger en accord avec les arguments de la ligne de commande. Pour chaque portion de données trouvé, un nouveau segment est ajouté à la fin du LV pvmove. Ce segment prend la forme d'un mirroir temporaire pour copier la donnée depuis l'emplacement original vers le nouvel emplacement. Le LV d'origine est mis à jours pour utiliser le nouveau segment temporaire dans le LV pvmove au lieu d'accéder à la données directement.
3. Les métadonnées du volume group sont mis à jours sur disque
4. Le premier segment du volume logique pvmove est activé et démarré pour mirrorer la première partie des données. Seulement un segment est mirroré à la fois.
5. Un service vérifie la progression. Quand il détecte que le premier mirroir temporaire est in-sync, il casse ce mirroir pour que seul le nouvel emplacement soit utilisé et écrit un checkpoint dans les métadonnées du volume group sur disque. Puis il active le mirroir pour le segment suivant
6. Quand il n'y a plus de segment à mirrorer, le volume logique temporaire est supprimé et les métaddonées du volume group est mis à jours pour que les volumes logique reflètent les nouveaux emplacement.

   Si l'option --atomic est utilisé, une approche légèrement différente est utilisée pour le déplacement. Un volume pvmove temporaire est également créé pour stocker les détails de tous les données en mouvement. Ce LV temporaire contient tous les segments de divers LV qui doivent être déplacés. Cependant cette fois, un volume logique identique est alloué qui contient le même nombre de segments et un mirroire est créé pour copier le contenu du premier LV temporaire vers le second. Quand une copie complète est accomplie, les volume logiques temporaire sont supprimés, laissant derrière les segments sur le volume physique de destinatio. Si une annulation est émis durant le déplacement, tous les volumes logique à déplacer resteront dans le volume physique source.

OPTIONS

--abort Annule tous les déplacement en cours. Si --atomic, tous les volumes logique restent dans le PV source.
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
--atomic Rend l'opération atomique. Cela s'assure que tous les volumes logiques affectés sont déplacés dans la destination ensemble.
-b|--background Lance le service en tâche de fond
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-i|--interval Seconds interval d'affichage de la progression
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-v|--verbose Mode verbeux
-n|--name Déplace seulement les extents appartenant au volume logique spécifié

Exemples

Déplacer tous les extents physique utilisés par un LV dans /dev/sdb1 vers des extents physique ailleurs dans le volume group:
pvmove /dev/sdb1
Additionnellement, un périphérique de destination peut être spécifié:
pvmove /dev/sdb1 /dev/sdc1
Effectuer l'action seulement sur les extents appartiennent à un volume logique lvol1:
pvmove -n lvol1 /dev/sdb1 /dev/sdc1
Au lieu de déplacer le contenu de tous le périphérique, il est possible de spécifier une plage d'extents physiques, par exemple 1000 à 1999:
pvmove /dev/sdb1:1000-1999
ou
pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999
Si la source et la destination sont sur le même disque, la stratégie d'alloctation anywhere peut être nécessaire:
pvmove --alloc anywhere /dev/sdb1:1000-1999 /dev/sdb1:0-999
La partie d'un volume logique spécifique présent dans une plage d'extents physique peut également être déplacé:
pvmove -n lvol1 /dev/sdb1:1000-1999 /dev/sdc1
^
23 mai 2016

htmlpdflatexmanmd




pvremove

pvremove

Supprimer un volume physique

   pvremove supprime la table dans un périphérique pour que LVM ne le reconnaisse plus comme volume physique.

OPTIONS

-ff, --force --force Force la suppression d'un volume physique appartenant à un volume group existant. Normalement, vgreduce devrait être utilisé au lieu de cette commande. Il n'est pas possible de supprimer un volume physique utilisé par un volume logique actif
-y, --yes Répond oui à toutes les questions
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-t|--test Lance en mode test
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




pvresize

pvresize

Redimensionne un disque ou une partition utilisé par LVM2

   pvresize redimensionne le volume physique qui peut déjà être dans un volume group et avoir des volumes logiques actifs.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
--setphysicalvolumesize size Remplace la taille automatiquement détectée du PV

Exemples

Étend le PV sur /dev/sda1 après avoir agrandi la partition avec fdisk:
pvresize /dev/sda1
Réduit le PV sur /dev/sda1 avant de réduire la partition avec fdisk:
pvresize --setphysicalvolumesize 40G /dev/sda1

Restrictions

   pvresize refuse de réduire le volume physique s'il a alloué des extents après l'endroit ou la nouvelle fin devrait être. Dans le future, il devrait les relocaliser ailleurs dans le volume group s'il y a suffisamment d'espace libre, comme le fait pvmove. pvresize ne fonctionne pas correctement dans les volumes LVM1.
^
24 mai 2016

htmlpdflatexmanmd




pvs

pvs

Affiche des informations sur les volumes physiques

OPTIONS

--all Inclus des informations sur les périphériques qui n'ont pas été initialisé avec pvcreate
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. pv_all sélectionne toutes les colonnes de volume physique, et pvseg_all sélectionne toutes les colonnes de segment de volume physique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--rows Affiche les colonnes brutes
--segments Produit une ligne de sortie pour chaque allocation contigue d'espace dans chaque volume physique
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
^
25 mai 2016

htmlpdflatexmanmd




pvscan

pvscan

Scanne tous les disques à la recherche des volumes physiques

   pvscan opère différemment quand il est utilisé avec lvmetad

   Scanner des disques est nécessaire pour lire les métadonnées LVM et identifier les PV. Une fois lu, lvmetad met en cache ces métadonnées pour que les commandes lvm puis les lire sans scanner les disques à nouveau.

   Quand lvmetad est utilisé, les nouveaux disques doivent être scannés avec vpscan --cache.

Notes

- En donnant des périphériques en argument, pvscan --cache ne scanne que ceux spécifiés
- Les règle udev LVM et services systemd sont utilisés pour initier le scan automatique
- l'option devices/global_filter de lvm.conf permet de filtrer les disques à scanner.
- Si lvmedat est démarré ou redémarré, tous les périphériques doivent être rescannés
- lvmetad ignore les anciens formats de métadonnées
- Pour notifier lvmetad sur un périphérique qui n'est plus présent, les numéros mineur et majeur doivent être donnés

Activation automatique

   Quand les services système détectent un nouveau périphérique LVM, la première étape est de scanner automatiquement et de mettre en cache les métadonnée du périphérique, avec pvscan --cache. La seconde étape est d'activer automatiquement les LV qui sont présent dans le nouveau périphérique. Cette auto-activation est faite par la même commande pvscan --cache quand l'option -a|--activate ay est inclus.

auto-activation des VG ou LV peut être activé/désactivé en utilisant:
lvm.conf activation/auto_activation_volume_list

   Quand ce paramètre est non-définis, tous les LV sont auto-activés.

   Quand un VG ou un LV n'est pas auto-activé, l'activation traditionnelle en utilisant vgchange ou lvchange -a|--activate est nécessaire.

Notes

- l'auto-activation de pvscan peut être faite seulement en combinaison avec --cache
- L'auto-activation est désignée par un argument "a" dans "-a|--activate ay". Cela signifie de distinguer les commandes générées par le système des commandes utilisateur, bien qu'elle peut être utilisée dans une commande d'activation. Quand utilisé, l'auto-activation volume_list est appliqué.
- L'auto-activation n'est pas encore supporté pour les LV qui font partie de volumes groupe partiel ou clusterisé.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-e|--exported Affiche seulement les volumes physique appartenant à un volume group exporté
-n|--novolumegroup Affiche seulement les volumes physiques n'appatenant pas à un volume group
-s|--short Format court
-u|--uuid Affiche les UUID en plus des noms de périphérique
-a|--activate ay Active automatiquement les volumes logiques
-b|--background Lance en tâche de fond
--cache --major major --minor minor Scanne un ou plusieurs périphériques et envoie les métadonnées à lvmetad
^
03 novembre 2011

htmlpdflatexmanmd




pwck

pwck

Vérifier l’intégrité des fichiers de mots de passe

   Toutes les entrées de /etc/shadow et /etc/passwd sont vérifiées afin de s’assurer qu’elles ont le bon format et qu’elles contiennent des données valables dans chaque champ. Une confirmation est demandé pour détruire les entrées mal formatées ou ayant des erreurs irrécupérables.

Vérifications effectuées

        Nombre correcte de champs
        Unicité des noms d’utilisateurs
        Validité des UID et GID
        Validité des groupes primaires
        Validité du répertoire personnel
        Validité du shell initial

   Les vérifications dans shadow sont effectuées quand un second paramètre de fichier est spécifié ou quand /etc/shadow existe sur le système. Les vérifications sont :

        Chaque mot de passe correspond à une entrée shadow, et chaque shadow a une entrée dans passwd
        Les mots de passe sont indiqués dans le fichier des mots de passe cachés
        Nombre correct de champs
        Le dernier changement de mot de passe n’est pas dans le future.

OPTIONS

-q Les avertissements qui ne nécessitent pas une action de l’utilisateur ne sont pas affichés
-r Mode lecture seule
-s Trie les entrées de /etc/passwd et /etc/shadow par UID

   pwck utilise des variables dans login.defs

Valeurs de retour

0 succès
1 erreur de syntaxe
2 une entrée de mot de passe est incorrecte
3 impossible d’ouvrir les fichiers de mots de passe
4 impossible de verrouiller les fichiers de mots de passe
5 impossible de mettre à jours les fichiers de mots de passe
6 impossible de trier les fichiers de mots de passe
^
03 novembre 2011

htmlpdflatexmanmd




pwconv

pwconv, pwunconv, grpconv, grpunconv

Convertir vers et depuis les fichiers de mots de passe ou de groupe cachés

pwconv crée le fichier shadow à partir du fichier passwd et d’un éventuel fichier shadow
pwunconv crée le fichier passwd à partir des fichiers shadow et passwd puis supprime shadow
grpconv crée le fichier gshadow à partir du fichier group et d’un éventuel fichier gshadow
grpunconv crée le fichier group à partir des fichiers gshadow et group puis supprime gshadow

   pwconv et grpconv sont similaires. Dans un premier temps, les entrées shadow ou gshadow qui n’existent pas dans passwd ou group sont retirés. Ensuite, les entrées shadow n’ayant pas pour mot de passe ’x’ dans le fichier passwd sont mises à jours. Enfin les entrées passwd sont remplacées par ’x’.

  pwunconv et grpunconv sont similaires. Les mots de passe principaux sont mis à jours à partir des fichiers shadow. Les entrées existant dans passwd mais pas dans shadow sont laissés. Puis shadow est supprimé.

  Ces utilitaires utilisent les paramètres dans login.defs

^
12 juillet 2010

htmlpdflatexmanmd




pwd

pwd

Affiche le nom du répertoire courant

OPTIONS

-L, --logical Si le contenus de la variable d'environnement PWD fournit un nom absolue du répertoire courant, mais optionnement avec des liens symboliques, alors affiche ce contenus. Sinon, sort le défaut -P
-P, --physical Affiche de nom complet du répertoire
^
10 juillet 2014

htmlpdflatexmanmd




pynslcd

pynslcd

Daemon de service de nom LDAP

   pynslcd est un service qui fait des requêtes LDAP pour NSS et PAM. Il est configuré via nslcd.conf

OPTIONS

-c, --check Vérifie si le service est lancé. 0 s'il fonctionne, 1 sinon
-d, --debug Mode débug, pynslcd ne se place pas en tâche de fond et envoie ses logs sur stderr.
-n, --nofork Ne se fork pas et reste en foreground
^
05 janvier 2014

htmlpdflatexmanmd




qdbus

qdbus

Interface de communication pour les applications qt.

OPTIONS

--system Se connecter au bus système
--literal Affiche les réponses littéralement
servicename Le service à connecter (ex: org.freedesktop.DBus)
path Le chemin de l'objet
method La méthode à appeler

EXEMPLES

Lister toutes les informations de statut sur un service
qdbus org.ktorrent.ktorrent
^
16 janvier 2015

htmlpdflatexmanmd




qemu-img

qemu-img

Permet de créer, convertir et modifier des images offline.

OPTIONS

check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] filename
create [-q] [-f fmt] [-o options] filename [size]
commit [-q] [-f fmt] [-t cache] filename
compare [-f fmt] [-F fmt] [-p] [-q] [-s] filename1 filename2
convert [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename
info [-f fmt] [--output=ofmt] [--backing-chain] filename
map [-f fmt] [--output=ofmt] filename
snapshot [-q] [-l | -a snapshot | -c snapshot | -d snapshot] filename
rebase [-q] [-f fmt] [-t cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
resize [-q] filename [+ | -]size
amend [-q] [-f fmt] -o options filename

Paramètres

filename Nom du fichier
fmt Format de l'image
--backing-chain énumère les informations sur les fichiers dans une chaine d'image disque.
size Taille du fichier en octets. Supporte les suffixes "k" or "K" (kilobyte, 1024) "M" (megabyte, 1024k), "G" (gigabyte, 1024M) et T (terabyte, 1024G). "b" est ignoré
output_filename Nom de destination du disque
output_fmt Format de destination
options Liste séparé par des ',' d'options sous la forme nom=valeur. Utiliser "-o ?" pour les options supportées par le format utilisé.
snapshot_param Est le paramètre utilisé pour le snapshot intern, le format est 'snapshot.id=[ID],snapshot.name=[NAME]' ou '[ID_OR_NAME]'
-c L'image doit être compressée(qcow only)
-h Affiche les formats supportés
-p Affiche une barre de progression
-q Mode silencieux. N'affiche que les erreurs.
-S size Indique le nombre consécutif d'octets qui doivent contenir seulement des 0 pour créer une image sparse durant la conversion.
-t cache Spécifie le mode du cache à utiliser avec le fichier de destination.

Paramètres pour la commande snapshot

snapshot est le nom du snapshot à créer, appliquer ou supprimer
-a Applique un snapshot (revient à l'état sauvegardé )
-c Crée un snapshot
-d Supprime un snapshot
-l Liste tous les snapshot dans l'image donné

Paramètres pour pour la commande compare

-f Premier format d'image
-F Second format d'image
-s Mode strict - échoue sur une taille d'image différente ou une allocation de secteur différent

Paramètres pour pour la commande convert

 -n Saute la création du volume cible

Description de commande

check [-f fmt] [--output=ofmt] [-r [leaks | all]] filename Effectue une vérification de consistante sur l'image disque filename. La commande peut sortir dans le format ofmt qui est soit "human" soit "json". Si "-r" est spécifié, qemu-img tente de réparer les inconsistances. "-r leaks" répare seulement les clusters perdus, "-r all" fixe toutes les erreurs. Seul les formats qcow2, qed, et vdi supportent la vérification de consistance. Dans le cas où l'image a des inconsistances, la vérification quitte avec 0. D'autres codes se sortie indique le type d'inconsistance:

        0 Vérification complète, l'image est consistante
        1 Vérification non complète à cause d'erreurs interne
        2 Vérification complète, l'image est corrompue
        3 Vérification complète, l'image a des clusters perdus, mais n'est pas corrompue
        63 La vérification n'est pas supportée par le format de l'image.

   Si "-r" est spécifié, les codes de sortie représentant l'état de l'image réfère à l'état après sa réparation.

   create [-f fmt] [-o options] filename [size]

  Crée la nouvelle image disque à la taille et au format spécifié. En fonction du format, des options sont disponibles.

   Si l'option backing_file est spécifié, l'image enregistrera seulement les différence depuis le backing_file. Aucune taille n'est nécessaire dans ce cas. backing_file ne sera jamais modifié sauf si vous utilisez qemu-img commit ou la commande monitor commit.

   La taille peut également être spécifiée en utilisant l'option taille avec -o, qui n'a pas besoin d'être spécifiée séparemment dans ce cas.

   commit [-f fmt] [-t cache] filename

  Envoie les changements enregistrés dans le fichier spécifié dans son image de base. Si le fichier de base est plus petite que le snapshot, alors le backing file sera redimmensionné à la même taille que le snapshot. Si le snapshot est plus petit que le backing file, ce dernier ne sera pas tronqué. Si vous voulez que le backing file matche la taille du plus petit snapshot, pour pouvez le tronquer vous-même une fois le commit effectué.

   compare [-f fmt] [-F fmt] [-p] [-s] [-q] filename1 filename2

  Vérifie si les 2 images ont le même contenu. Vous pouvez comparer les images avec différents formats ou paramètres. Le format est sondé sauf si -f et/ou -F sont utilisés.

   Par défaut, les images avec une taille différente sont considérés identique si la plus grande image ne contient seulement des secteurs non-alloués ou remplis de 0 à la fin de l'image. En plus, si un secteur n'est pas alloué dans une image et contient seulement des 0 dans l'autre, il est évalué identique. Vous pouvez utiliser le mode strict en spécifiant l'option -s, ce qui fait échouer dans le cas où le taille des images diffèrent ou si un secteur est alloué dans une image et pas dans l'autre.

   compare quitte avec le code de sortie 0 si les images sont identiques, et 1 sinon. D'autres codes de sortie signifient que des erreurs ont été rencontrés:

0 Les images sont identiques
1 Les images diffèrent
2 Erreur en ouvrant une image
3 Erreur en vérifiant une allocation de secteur
4 Erreur en lisant les données

   convert [-c] [-p] [-n] [-f fmt] [-t cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename

  convertis l'image disque filename ou un snapshot snapshot_param en image disque output_filename en utilisant le format output_fmt. Peut optionnellement être compressé (-c) ou chiffré, en fonction du format.

   Seul les formats qcow et qcow2 supportent la compression. La compression est lecture seul. Cela signifie que si un secteur compressé est réécrit, la réécriture sera une donnée non compressée. La conversion d'image est également utile pour obtenir des images plus petites en utilisant un format scalaire tel que qcow ou cow: les secteurs vides sont détectés et supprimés de l'image de destination. backing_file permet de forcer l'image de sortie à être créée en copie de l'image de base. le backing_file devrait avoir le même contenu que l'image de base de l'entrée, cependant le chemin, le format, etc. peuvent différer. Si -n est spécifié, la création du volume cible sera ignoré. C'est utile pour des formats tels que rbd si le volume cible a déjà été créé avec les options spécifique du site qui ne peuvent pas être fournis par qemu-img.

   info [-f fmt] [--output=ofmt] [--backing-chain] filename

  Donne des informations sur l'image disque. À utiliser en particulier pour connaître a taille réservée dans le disque qui peut être différent de la taille affichée. Si les snapshot sont stoqués dans l'image disque, elle peuvent être affichées également. La commande peut afficher dans le format ofmt qui est soit "human" soit "json".

   Si une image diques a une chaîne backing file, les informations sur chaque image disque dans la chaîne peuvent être récursivement énumérés en utilisant l'option --backing-chain.

Si vous avez un chaîne d'image:
base.qcow2 ‹- snap1.qcow2 ‹- snap2.qcow2
Pour énumérer les informations sur chaque image disque:
qemu-img info --backing-chain snap2.qcow2

   map [-f fmt] [--output=ofmt] filename

  Dump les méta-données de l'image et sa chaîne de backing_file. En particulier, cette commande dump l'état d'allocation de tous les secteurs de filename, ensemble avec le fichier le plus haut dans la chaîne. 2 formats d'options sont possibles. Le format par défaut ('human') dumps seulement les aires non-zero du fichier. Ces parties du fichier sont omis, de même pour les parties qui ne sont pas allouées le long de la chaîne. La sortie de qemu-img va identifier un fichier d'où le donnée peuvent être lues, et l'adresse dans le fichier. Chaque linge va inclure 4 champs, les 3 premiers sont un héxa.

Par exemple:
Offset Length Mapped to File
0 0x20000 0x50000 /tmp/overlay.qcow2
0x100000 0x10000 0x95380000 /tmp/backing.qcow2

   signifie que les octets 0x20000 (131072) commençant à l'offset 0 dans l'image sont disponibles dans /tmp/overlay.qcow2 (ouvert en format raw) commençant à l'offset 0x50000 (327680). Les données qui sont compressées, chiffrée ou autre ne sont pas disponible dans le format brute et vont générer des erreur pour le format "human". Notez que les noms de fichiers peuvent inclure des sauts de ligne, ce qui n'est pas sûr pour analyser ce format de sortie dans les scripts.

   Le format alternatif json retourne un tableau de dictionnaires au format json. Il va inclure des information similaires dans les champs start, length et offset; il inclus également d'autres informations plus spécifiques:

- Si les secteurs contient une donnée ou non (data); si false, les secteurs sont soit non alloués, ou remplis de 0.
- Si La données est 0 (zero)
- Pour raccourcir la sortie, le fichier cible est exprimmé en depth, par exemple, une profondeur de 2 réfère au backing file du backing file de filename.

   snapshot [-l | -a snapshot | -c snapshot | -d snapshot ] filename

  Liste, applique, créer, ou supprime un snapshot de l'image filename.

   rebase [-f fmt] [-t cache] [-p] [-u] -b backing_file [-F backing_fmt] filename

  Change le backing file au backing_file et (si le format de l'image de filename le supporte) le format du backing file est changé en backing_fmt. Si backing_file est spécifié "", l'image est rebasé dans aucun backing file ( ex: elle va exister indépendamment de tout backing file).

  Il y a 2 modes différents dans lequel "rebase" peut opérer:

safe mode C'est le mode par défaut et effectue une opération de rebase réel. Le nouveau backing file peut différer de l'ancien et qemu-img rebase va s'occuper de conserver inchangé le contenu visible à l'invité de filename. Pour cela, tous les clusters qui diffèrent entre backing_file et l'ancien backing file de filename sont fusionné dans filename avant de changer de backing file. Noter que le safe mode est plus coûteux, comparable à convertir une image. Ne fonctionne que si l'ancien backing file existe.
unsafe mode qemu-img utilise le mode unsafe si -u est spécifié. Dans ce mode, seul en nom du backing file et le format de filename sont changés sans vérification du contenu du fichier. L'utilisateur doit spécifier le nouveau backing_file correcte, ou le contenu visible de l'invité de l'image sera corrompue. Ce mode est utile pour renommer ou déplacer le backing file ailleurs. Il peut être utilisé sans ancien backing file, par ex, on peut l'utiliser pour fixer un image dont le backing file a déjà été déplacé/renommé.

   rebase peut être utilisé pour effectuer une opération diff dans 2 images disque. Cela peut être utile quand un invité est copié ou cloné

Disons que base.img a été clonée en modified.img en la copiant, et cet invité modified.img a été lancé donc il y a quelques changements comparés à base.img. Pour construire une petite image appelée diff.cqow2 qui contient seulement la différence:
qemu-img create -f qcow2 -b modified.img diff.qcow2
qemu-img rebase -b base.img diff.qcow2
modified.img peut être supprimé, vu que base.img + diff.qcow2 contient la même information.

   resize filename [+ | -]size

  Change l'image disque comme si elle avait été créée avec la taille donnée. Avant d'utiliser cette commande pour réduire une image disque, vous devez utiliser les outils de système de fichier et de partitionnement dans la VM pour réduires les tailles alloués aux systèmes de fichiers et partitions, sinon des données seront perdues. Après avoir utilisé cette commande pour agrandir une image disque, vous devez utiliser les outils de partitionnement et de systèmes de fichiers dans la v pour utiliser le nouvel espace disque.

   amend [-f fmt] -o options filename

  Modifie les options spécifiques au format de l'image. Tous les formats ne supportent pas cette opération.

Notes

   Les formats d'image suivant sont supportés:

raw Format d'image brute, il a l'avantage d'être simple et facilement exportable à d'autres émulateurs.
qcow2 Format d'image qemu, le format le plus verstatile. Il a les images les plus petites, supporte le chiffrement, la compression et les snapshots multiples.

Options du format qcow2

compat Détermine la version qcow2 à utiliser. compat=0.10 utilise le format traditionnel qui peut être lu par tous les qemu. compat=1.1 active les extensions du format.
backing_file Nom d'une image de base
backing_fmt Formate de l'image de base
encryption Active le chiffrement 128-bits AES-CBC
cluster_size Change la taille de cluster ( doit être entre 512 et 2M). Les petites taille améliorent la taille de l'image, et les plus grandes taille améliorent les performance.
preallocation (off, full, falloc, metadata). Alloue tout l'espace disque. Améliore les performances.
lazy_refcounts à on, Les updates de comptage de référence sont reportés pour éviter les E/S de méta-données et améliorer les performances. Intéressant avec cache = writethrough. Le compromis est qu'après un crash d'hôte, les tables de comptage de référence doivent être reconstruites, qemu-img check -r all est requis et peut prendre du temps.
nocow A on, désactive le COW du fichier. Seulement valide sur brtfs.
^
16 janvier 2015

htmlpdflatexmanmd




qemu-nbd

qemu-nbd

QEMU Disk Network Block Device Server. Exporte des images disques Qemu en utilisant le protocole NBD

OPTIONS

-p, --port=port Port d'écoute ( défaut: 1024 )
-o, --offset=offset offset dans l'image
-b, --bind=iface Interface d'écoute ( défaut: 0.0.0.0 )
-k, --socket=path Utitile un socket unix avec le chemin donné
-r, --read-only Export lecture seule
-P, --partition=num Expose seulement la partition spécifiée
-s, --snapshot Utilise un fichie snapshot
-n, --nocache Désactive le cache de l'hôte
-c, --connect=dev Connecte le fichier au périphérique donné
-d, --disconnect Déconnecte le périphérique spécifié
-e, --shared=num Le périphérique peut être partagé par num client ( défaut: 1 )
-t, --persistent Ne quitte pas à la dernière connection
-v, --verbose mode verbeux

Exemples

Acceder a une partition d'un disque virtuel sur l'hôte:
modprobe nbd
qemu-nbd -c /dev/nbd0 /path/to/mydisk.qcow2
ensuite, identifier les partitions:
fdisk -l /dev/nbd0
et la monter:
mount /dev/nbd0p1 /mnt/vmpart1
pour démonter proprement:
umount /mnt/vmpart1 && qemu-nbd -d /dev/nbd0 && rmmod nbd
^
28 août 2015

htmlpdflatexmanmd




quot

quot

Sommaire du propriétaire de système de fichier

   Affiche le nombre de Ko dans le système de fichiers actuellement possédé par chaque utilisateur et groupe. Ne fonctionne qu'avec XFS.

OPTIONS

-a Génère un rapport pour tous les systèmes de fichier montés en donnant la taille utilisé par chaque utilisateur et groupe.
-c Affiche 3 colonnes donnant la taille de fichier en Ko, le nombre de fichiers, et un total cumulé.
-f Affiche un compteur en Ko et le nombre de fichiers possédé par chaque utilisateur et groupe
-g Reporte les groupes
-u Reporte les utilisateurs
-v Affiche 3 colonne contenant le nombre de Ko non accédés dans les 30, 60, et 90 derniers jours.
-i Ignore les montages montés par automounter
-T Évite de tronquer les noms d'utilisateurs de plus de 8 caractères
-Q Ne trie par la sortie
^
28 août 2015

htmlpdflatexmanmd




quota

quota

Affiche l'utilisation disque et les limites

OPTIONS

-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-g, --group Affiche les quotas de groupe pour le groupe auquel l'utilisateur est membre. Les groupes optionnels spécifié restreigne l'affiche à ceux-ci
-u, --user Flag équivalent au mode par défaut
-v, --verbose Affiche les quotas dans les systèmes de fichier où aucun stockage n'est alloué
-s, --human-readable Affichage au format automatique
--always-resolve Tente toujours de traduire les user/group en uid/gid même si le nom est composé de chiffre uniquement.
-p, --raw-grace Quand l'utilisateur est en période de grâce, le temps en seconde est reporté. Le champ vaut '0' quand la période de grâce n'est pas en effet.
-i, -no-autofs Ignore les points de montage montés par automounter
-l, --local-only Reporte les quotas seulement sur les systèmes de fichiers locaux.
-A, --all-nfs Reporte les quotas pour tous les systèmes de fichier NFS
-f, --filesystem-list Reporte les quotas seulement pour les systèmes de fichier spécifiés sur la ligne de commande.
-m, --no-mixed-pathnames Actuellement, les chemins des points de montage NFS4 sont envoyés sans le dernier '/'. rpc.rquotad l'utilise pour reconnaître les montages NFS4. Cette option envoie toujours des chemin avec le dernier '/'.
-q, --quiet Affiche un message plus concis, contenant seulement les informations sur les systèmes de fichier où les quotas sont en cours.
-Q, --quiet-refuse N'affiche pas de message d'erreur si la connection à rpc.rquotad est refusé.
-w, --no-wrap N'enveloppe pas la ligne si le périphérique est trop long. Utile pour les scripts
--show-mntpoint Affiche également le point de montage comme identification de système de fichier
--hide-device N'affiche pas le nom de périphérique dans une identification de système de fichier

   Seul root peut utiliser -u pour afficher les limites d'autres utilisateurs.

Fichiers

aquota.user
aquota.group Fichier de quota à la racine du système de fichier (v2)
quota.user
quota.group Fichier de quota à la racine du système de fichier (v1)
/etc/mtab Systèmes de fichiers par défaut.
^
28 août 2015

htmlpdflatexmanmd




quotacheck

quotacheck

Scanne un système de fichier pour l'utilisation disque, créé, vérifie et répare les fichiers de quota

   quotacheck examine chaque système de fichier, construit une table d'utilisation disque courant, et compare cette table avec ceux qui sont enregistrés dans le fichier de quota. Si une inconsistance est détectée, le fichier le quota et le système courant sont mis à jours. Par défaut, seul les quotas utilisateur sont vérifiés. quotacheck s'attend à ce que chaque système de fichier à vérifier ai les quota activés.

   quotacheck devrait être lancé à chaque démarrage du système quand des systèmes de fichiers non-valide sont montés. Il est fortement recommandé de lancer quotacheck avec les quotas désactivé pour le système de fichier.

OPTIONS

-b, --backup force à créer des backup pour le fichier de quota avant d'écrire.
-v, --verbose Reporte ses opération à mesure de sa progression.
-d, --debug Mode debug, affiche beaucoup d'informations.
-u, --user Vérifie seulement les quotas utilisateur
-g, --group vérifie seulement les quotas de groupe.
-c, --create-files Ne lit par les fichiers de quota non existants. Ne fait qu'un scan et le sauvegarde sur le disque.
-f, --force Force la vérification et l'écriture d'un nouveau fichier de quota.
-M, --try-remount Ce flag force la vérification en mode lecture/écriture si le remontage échoue.
-m, --no-remount Ne tente pas de remonter le système de fichier lecture-seul.
-i, --interactive Mode interactif.
-n, --use-first-dquot Si les fichiers de quota deviennent corrompus, il est possible de dupliquer les entéers pour un simple utilisateur ou groupe.
-F, --format=format-name Traite les quotas au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-a, --all Vérifie tous les système de fichiers montés non-NFS dans /etc/mtab
-R, --exclude-root Utilisé avec -a, tous les systèmes de fichier excepté le système de fichier racine sont vérifiés.
^
28 août 2015

htmlpdflatexmanmd




/etc/quotagrpadmins

/etc/quotagrpadmins



   Ce fichier liste les administrateurs des groupes qui vont recevoir une alerte si warnquota --group trouve un groupe excédant ses limites. Chaque ligne consiste d'un nom de groupe, suivi par ':' et un nom d'utilisateur.

Exemple:
# comment
users: root

^
28 août 2015

htmlpdflatexmanmd




quotaon

quotaon, quotaoff

Active/désactive les quotas

   quotaon annonce au système que les quotas disques devraient être activés sur un ou plusieurs systèmes de fichiers. Les fichiers de quota de système de fichier doivent être présents dans le répertoire root du système de fichier spécifié et doit être nommé soit aquota.user pour la version 2, soit quota.user pour la version 1, aquota.group ou quota.group.

   Les systèmes de fichier XFS sont des cas spéciaux. XFS considère les informations de quota comme des métadonnées du système de fichier et utilise un journal pour fournir un haut niveau de garantie de consistance. Il y a 2 composants du système de quota XFS: l'accounting et les limites. Les systèmes de fichier XFS nécessitent que le quota accounting soit activé au montage. Il est possible de l'activer/désactiver les limites à la volée.

   quotaoff annonce au système que les systèmes de fichier devraient désactiver les quotas.

Options quotaon

-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-a, --all Tous les système de fichiers monté et non NFS dans /etc/fstab avec quota sont activés pour les quotas.
-v, --verbose Affiche un message pour chaque système de fichier où les quotas sont activés.
-u, --user Manipule les quotas utilisateur
-g, --groupe Manipule les quotas de groupe
-p, --print-state Au lieu d'activer les quotas, affiche seulement l'état des quotas.
-x, --xfs-command enforce gérè les limites pour XFS
-f, --off quotaon se comporte comme quotaoff

Options quotaoff

-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-a, --all Tous les système de fichiers monté et non NFS dans /etc/fstab avec quota sont désactivés pour les quotas.
-v, --verbose Affiche un message pour chaque système de fichier affecté
-u, --user Manipule les quotas utilisateur
-g, --groupe Manipule les quotas de groupe
-p, --print-state Au lieu de désactiver les quotas, affiche seulement l'état des quotas.
-x, --xfs-command enforce gérè les limites pour XFS
-x, --xfs-command account peut être utilisée pour désactiver le quota accounting.
^
28 août 2015

htmlpdflatexmanmd




quotastats

quotastats

Affiche des statistiques sur les quota

   Il affiche les élements suivants:

- version de quota supporté par le kernel
- Nombre de recherches dquot
- Nombre d'abandons dquot
- Nombre de lectures dquot
- Nombre d'écritures dquot
- Nombre de synchro quotafile
- Nombre d'atteintes du cache dquot
- Nombre de dquot alloués
- Nombre de dquot libres
- Nombre d'entrée dquot utilisés

^
28 août 2015

htmlpdflatexmanmd




/etc/quotatab

/etc/quotatab

device description

   Ce fichier liste des descriptions des périphérique pour les notifications warnquota. Chaque ligne consiste d'un nom de périphérique suivi par un ':' et une description.

Exemple:
# comment
/dev/sda2: Home directories.|This becomes the second line.

^
28 août 2015

htmlpdflatexmanmd




quotatool

quotatool

Manipule les quotas des systèmes de fichier

OPTIONS

-u [[:]uid] Définis les quotas utilisateur. ':' permet d'utiliser les uid non présent dans /etc/passwd
-g [[:]gid Définis les quotas de groupe. ':' permet d'utiliser les gid non présent dans /etc/group
-b Définis les quotas de block
-i Définis les quotas de inode
-R Ne fait qu'augmenter les quotas, jamais les diminuer.
-t TIME Définis la période de grâce du système.
-r Ré-initialise la période de grâce
-l NUM Définis la limite hard
-q Définis la limite soft
-d Dump les informations de quota pour les utilisateur/groupe au format machine
Mode simulation, ne fait rien
-v Mode verbeux, peut être spécifié jusqu'à 3 fois

Exemples

Définis la limite de block soft à 800Mo, la limit hard à 1Go pour l'utilisateur mpg4 dans /home
quotatool -u mpg4 -b -q 500M -l 1G /home
augmente la limite soft de 100Mo pour le gid non-existant 12345 dans /dev/loop3
quotatool -g :12345 -b -q +100M /dev/loop3
Définis la limite d'inode hard à 2000 pour l'utilisateur johan dans /var
quotatool -u johan -i -l 2000 /var
Définis la période de grâce de block global à une semaine dans /home
quotatool -u -b -t "1 week" /home
Redémarre la période de grâce d'inode pour l'utilisateur johan sur le système de fichier racine
quotatool -u johan -i -r /
^
28 août 2015

htmlpdflatexmanmd




quota_nld

quota_nld

Service de message netlink de quota

   quota_nld écoute sur un socket netlink et traite les alertes de quota reçus. Par défaut, quota_nld renvois ces messages sur DBUS et le terminal du l'utilisateur pour lequel l'alerte est dirigé.

OPTIONS

-D, --no-dbus Ne renvois pas les warning sur DBUS
-C, --no-console N'affiche pas d'alerte sur le terminal de l'utilisateur
-b, --print-below Si les alertes de quota sont affichés sur le terminal de l'utiliteur, inclus les messages sur leur limites soft et hard.
-F, --foreground Lance le service en tâche de fond.
^
13 février 2012

htmlpdflatexmanmd




reader.conf

reader.conf, reader.conf.d

Fichiers de configuration pour les pilotes des lecteurs pcscd

Syntaxe

   Chaque entrée doit être définie par 4 champs:

FRIENDLYNAME Texte arbitraire pour identifier le lecteur. Affiché par la commande pcsc_scan
DEVICENAME (ifdhandler ›= 3.0). Utilisé pour identifier le port physique sur lequel le lecteur est connecté
LIBPATH Nom du fichier du pilote
CHANNELD (ifdhandler ‹ 3.0). Remplacé par DEVICENAME

Exemples

Gemplus lecteur GemPCTwin avec communication série:
FRIENDLYNAME "GemPCTwin serial"
DEVICENAME /dev/ttyS0
LIBPATH /usr/lib/pcsc/drivers/serial/libccidtwin.so.0.4.1
CHANNELID 1
^
02 juillet 2010

htmlpdflatexmanmd




readlink

readlink

Affiche la référence d'un lien symbolique

   readlink peut fonctionner dans un des 2 modes supportés.

  mode readlink (mode par défaut) sort la valeur du lien symbolique.

  mode canonicalize sort le nom absolue du fichier donné.

OPTIONS

-f, --canonicalize utilise le mode canonicalize. si un composant du nom de fichier excepté si le dernier est manquant ou inexistant, quitte sans sortie.
-e, --canonicalize-existing utilise le mode canonicalize. Si un composant est manquant ou indisponible, readlink quitte sans sortie
-m, --canonicalize-missing Si un composant est manquant ou indisponible, quite sans sortie.
-n, --no-newline Ne sort pas de newline final.
-s, -q, --silent, --quiet n'affiche pas de message d'erreur
-v, --verbose reporte les messages d'erreur
^
05 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/removable_context

/etc/selinux/‹SELINUXTYPE›/contexts/removable_context

Fichier de configuration de contexte de périphériques débranchable

   Ce fichier contient le label par défaut qui devrait être utilisé pour les périphériques hot-plug qui ne sont pas définis dans le fichier media. Le fichier consiste d'une seule ligne user:role:type[:range]

Exemple

system_u:object_r:removable_t:s0
^
23 mai 2010

htmlpdflatexmanmd




renice

renice

Modifie la priorité d'un processus en cours d'exécution

OPTIONS

-n, —priority La priorité du processus
-g, —pgrp spécifier l'ID du groupe de processus
-u, —user spécifier l'utilisateur
-p, —pid spécifier l'ID du processus

Exemples

Change la priorité des processus 987 et 32, et tous les processus des utilisateur daemon et root
renice +1 987 -u daemon root -p 32
^
08 mai 2010

htmlpdflatexmanmd




replace

replace

Utilitaire de remplacement de chaîne dans les fichiers ou sur la sortie standard

shell› replace from to [from to] ... -- file_name [file_name] ...
shell› replace from to [from to] ... ‹ file_name

   from représente une chaîne à rechercher et to représente son remplacement. Cela peut être une ou plusieurs paires de chaînes. L'option -- indique où la liste de remplacement se termine et où le nom du fichier commence. replace affiche un message indiquant quel fichier il modifie actuellement.

Exemples

replace peut être utilisé pour inverser des chaînes. Par exemple, pour inverser a et b dans des fichiers donnés:
replace a b b a -- file1 file2 ...

OPTIONS

-#debug_options Active le débuggage
-s Mode silencieux
-v Augmente la verbosité
^
28 août 2015

htmlpdflatexmanmd




repquota

repquota

Sommaire des quotas pour un système de fichier

   repquota affiche un sommaire de l'utilisation disque et des quotas pour les systèmes de fichier spécifiés. Pour chaque utilisateur le nombre courant de fichiers et la quantité d'espace (en Ko) est affiché, avec les limites de quotas. Dans la 2ème colonne repquota affiche 2 caractères marquant queles limites sont dépassées. Si l'utilisateur est au-delà de son espace softlimit ou atteins son hardlimit, le premier caractère est '+'. Sinon, le caractère affiché est '-'.

   repquota doit traduire les id de tous les utilisateurs/groupes pour les noms donc il prend du temps pour afficher toutes les informations.

OPTIONS

-a, --all Reporte tous les systèmes de fichiers indiqués dans /etc/mtab
-v, --verbose Reporte tous les quotas, même s'ils n'y a pas d'utilisation.
-c, --batch-translation Cache les entrées pour reporter et traduire les uid/gid plus rapidement.
-C, --no-batch-translation Traduit les entrées individuellement. C'est plus rapide quand les utilisateurs sont stockés dans une base de donnée.
-t, --truncate-names tronque les user/groupe supérieurs à 9 caractères.
-n, --no-names Ne pas résoudre les UID/GID
-s, --human-readable Format automatique
-p, --raw-grace Quand l'utilisateur est en période de grâce, le temps en seconde est reporté. Le champ vaut '0' quand la période de grâce n'est pas en effet.
-i, --no-autofs ignore les points de montage montés par automounter
-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-g, --group Reporte les quotas utilisateur
-u, --user Reporte les quotas de groupe
^
01 novembre 2016

htmlpdflatexmanmd




resize2fs

resize2fs

Redimensionner un système de fichier ext2/3/4

   Il peut être utilisé pour agrandir ou réduire un système de fichier non monté. Si le système de fichier est monté il peut être étendu si le kernel supporte le redimensionnement à chaud. La taille peut être en s (secteurs de 512 octets), K (Kio), M (Mio), ou G (Gio). resize2fs ne manipule pas la taille des partitions, utiliser fdisk ou lvextend.

OPTIONS

-b Active la fonctionnalité 64bits, redimensionne les descripteurs de groupe si nécessaire et déplace les métadonnées en conséquence.
-d debug-flags Active divers fonctionnalités de debugage:

        2 relocalisations de block
        4 relocalisation d'inode
        8 Déplacement de table d'inode
        16 information de temps
        32 Calcule de taille minimum de système de fichier.

-f Force le traitement
-F Vide le tampon dy périphérique avant de commencer.
-M réduit le système de fichier pour minimiser sa taille autant que possible
-p Affiche une barre de progression
-P Affiche une estimation sur le nombre de blocks dans ce système de fichier avec -M et quitte.
-s Désactive la fonctionnalité 64bits, et libère les blocks qui ne sont plus utilisés.
-S RAID-stride resize2fs determine le stride RAID spécifié à la création du système de fichier. Cette option permet de spécifier le stride manuellement.
-z undo_file Avant d'écraser un block, l'écrit dans un fichier undo.
^
03 février 2016

htmlpdflatexmanmd




resizecons

resizecons

Change l'idée kernel de la taille de la console

   La commande resizecons tente de changer le mode vidée de la console. Il y a différents aspects à cela: le kernel, le matériel doit le savoir et les programmes utilisateurs doivent le savoir, et la police de la console peut nécessiter une adaptation.

   Le kernel parle des changement en utilisant l'ioctl VT_RESIZE. Cela permet au kernel de ré-allouer la mémoire écran de la console pour toutes les consoles virtuelles, et peut échouer s'il n'a pas suffisamment de mémoire. Dans ce cas, il tente de dé-allouer certaines consoles virtuelle en premier. Si cet ioctl réussit, mais une dernière étape ( par ex. vous n'avez pas les permissions), vous pouvez vous retrouver avec un écran désordonné.

   La partie la plus difficile côté matériel, vu qu'il nécessite une connaissance détaillée du matériel vidéo, et des nombreux registres. Seul le changement de lignes est assez facile, et resizecons tente de le faire lui-même avec l'option -lines. La commande resizecons COLSxROWS va exécuter restoretextmode -r COLSxROWS ( et donc nécessite d'avoir svgalib d'installé). Ici, COLSxROWS est un fichier qui a été cré par restoretextmode -w COLSxROWS. Les permissions root sont requises, ou restoretextmode doit avoir le setuid root.

   Pour les programmes utilisateurs, resizecons fait un 'stty rows ROWS cols COLS' pour chaque console active ( entre tty0 et tty15), et envoie un SIGWINCH à selection s'il le trouve dans /tmp/selection.pid.

   Enfin, il traite les fonts en exécutant setfont. Généralement, la mauvaise font est chargée, et il est nécessaire de choisir une autre font avec setfont par vous-même.

Bugs

   resizecons ne fontionne pas avec tous les hardwares. Par exemple, il ne peut pas être utilisé sur les plateformes autre que x86 et x86_64. Voir fbset comme alternative.
^
13 mars 2010

htmlpdflatexmanmd




resolv.conf

resolv.conf

Configuration des serveurs DNS

   Ce fichier contient le(s) serveur(s) DNS. Ce fichier est automatiquement mis à jour par le client DHCP. Si vous utilisez une configuration réseau fixe, il est necessaire de renseigner ce fichier. Pour spécifier un serveur DNS utiliser la directive nameserver. Vous pouvez spécifier jusqu’à 3 serveurs DNS.

OPTIONS

domain indique le domaine local de la machine. Sans cette options, déduit le domain via gethostname(2), sinon le domain est root.
search indique les domaines de recherche. Normalement déterminé par domain, permet de spécifier des domaines de recherche spécifiques (max 6 - 256 caractères). Pour une liste de sous domaines, utiliser l’option ndots pour éviter les attaques MITM. Cette options peut générer beaucoup de trafic réseau si les domaines listés ne sont pas locaux.
debug active le débuggage
ndots:n seuil pour le nombre de ’.’ qui doivent apparaître dans un nom donné à res_query(3) avant qu’une requête absolue initiale soit faite. défaut : 1, ce qui signifie que si le nom contient un ’.’, il sera d’abord tenté comme nom absolu.
timeout:n Délai en second de timeout d’un requête (défaut 30s)
attemps:n Nombre de tentative de requête avant de retourner une erreur (défaut 5)
rotate effectue un round-robin sur la liste des serveur de noms spécifiés
no-check-names Ne vérifie pas si les noms contiennent des caractères invalide tels que ’_’, caractères non-ascii ou des caractères de contrôle
int6 Affecte les requêtes AAAA avant une requête A dans la fonction gethostbyname(3) et le mappage des réponses IPv4 dans une forme tunnelisée IPv6 si aucun enregistrement AAAA n’est trouvé mais qu’un enregistrement A existe.
ip6-bytestring Les recherches IPv6 inverse sont faites en utilisant le format décrit dans la RFC 2673. Désactivé, le format nibble est utilisé.
ip6-dotint/no-ip6-dotint Désactivé, les recherches inverses IPv6 sont faites dans la zone ip6.int (déprécié), sinon dans ip6.arpa. Activé par défaut
edns0 Active le support pour les extensions DNS (RFC2671)

Exemples

nameserver 81.253.149.9
nameserver 80.10.246.3
nameserver 192.169.1.1
domain uubu.fr
search uubu.fr
options timeout:3
options attempts:4
options rotate
^
07 mai 2017

htmlpdflatexmanmd




restorecon

restorecon

Restaure les contextes de sécurité par défaut SELinux

   Ce programme est principalement utilisé pour réinitialiser le contexte de sécurité d'un ou plusieurs fichiers. Il peut être lancé à tout moment pour corriger des erreurs, ajouter le support pour de nouvelles stratégies, ou avec l'option -n pour simplement vérifier les contextes. Si un objet fichier n'a pas de contexte, restorecon écrit un contexte par défauut dans les attributs étendus de l'objet fichier. Si nu objet fichier a un contexte, restorecon ne modifie que la portion de type du contexte de sécurité.

OPTIONS

-i ignore les fichiers qui n'existent pas
-f infilename Fichier contenant une liste de fichiers à traiter pal l'application, ou '-' pour stdin
-e directory Répertoire à exclure. Peut être spécifié plusieurs fois
-R, -r Change les labels des fichiers et répertoires récursivement
-n  Ne change par les labels
-o outfilename Sauve la liste des fichiers avec un context incorrect dans ce fichier
-P Affiche une progression en affichant un '*' tous les 1000 fichiers
-v Affiche les changements dans les labels
-F Force à réinitialiser le contexte pour correspondre à file_context pour les fichiers personnalisable, et le contexte de fichier par défaut, en changeant l'utilisateur, rôle, plage et le type.
^
07 mai 2017

htmlpdflatexmanmd




restorecond

restorecond

Service qui supervise la création de fichier et définis le contexte de fichier SELinux par défaut

   Ce service utilise inotify pour voir les fichiers listés dans le fichier /etc/selinux/restorecond.conf. Quand ils sont créés, ce service s'assure que le contexte du fichier est correct en accord avec la stratégie

OPTIONS

-d mode debug
-f restorecond_file Spécifie un fichier de configuration alternatif
-u Active le mode utilisateur. ans restorecond dans la session utilisateur et lis /etc/selinux/restorecond_user.conf. Utilise Dbus pour s'assure que seul une instance restorecond tourne par session utilisateur.
-v mode verbeux
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/restorecond.conf

/etc/selinux/restorecond.conf, restorecond-user.conf

Configuration pour restorecond

   restorecond.conf contient une liste de fichiers qui peuvent être créé par les applications avec un contexte de sécurité incorrect. Le service restorecond vérifie leur création et corrige leur contexte de sécurité en accord avec les fichiers de configuration de stratégie active /etc/selinux/‹policy_name›/contexts/files. Chaque ligne du fichier contient le chemin complet d'un fichier ou répertoire. Les entrées qui commencent avec un tilde seront étendus aux fichiers dans les répertoires personnels des utilisateurs. Noter qu'il est possible de lancer restorecond dans une session utilisateur avec l'option -u, et nécessite un fichier /etc/selinux/restorecond-user.conf.

^
28 mars 2016

htmlpdflatexmanmd




restricted-ssh-commands

restricted-ssh-commands

Restreindre les utilisateurs SSH à un jeu prédéfinis de commandes

   restricted-ssh-commands est conçu pour être appelé par SSH pour restreindre un utilisateur à lancer uniquement certaines commandes. Une liste d'expressions régulière permises peuvent être configurés dans /etc/restricted-ssh-commands. La commande demandé doit correspondre à au moins une expression régulière. Sinon elle sera rejetée.

   Le paramètre optionnel est le nom du fichier de configuration sous /etc/restricted-ssh-commands à utiliser. Si omis, le nom de l'utilisateur sera utilisé.

Créer un fichier de configuration dans /etc/restricted-ssh-commands/$config et ajouter la ligne suivant dans ~/.ssh/authorized_keys pour l'utiliser:
command="/usr/lib/restricted-ssh-commands",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa [...]

Codes de sortie

124 Le fichier de configuration contient au moins une expression régulière, mais la commande demandée ne matche pas
125 Pas de fichier de configuration ou ne contient pas d'expressions régulière

Exemple

Supposons un dépôt de package Debian sur un hôte en utilisant reprepro pour uploader les paquets. La configuration de package est dans /srv/reprepro, et le fichier de configuration est /etc/restricted-ssh-commands/reprepro contenant les expressions régulières suivante:
^scp -p( -d)? -t( --)? /srv/reprepro/incoming(/[^ /]*)?$
^chmod 0644 /srv/reprepro/incoming/[^ /]*$
^reprepro ( -V)? -b /srv/reprepro processincoming foobar$
^
08 juin 2010

htmlpdflatexmanmd




rfc2131

rfc2131

Dynamic Host Configuration Protocole

   DHCP (Dynamic Host Configuration Protocole) est un protocole faisant lui même partie de la suite de protocole BOOTP. Protocole de niveau application de type client-serveur, il permet à un hôte n'ayant pas de configuration réseau (adresse IP, masque, adresse dns, passerelle etc...), d'en obtenir une afin de pouvoir communiquer sur le réseau.

   DHCP permet l'allocation dynamique d'adresse IP mais peut également réserver certaines adresses à des clients spécifiques. On distingue 3 types d'allocations. L'allocation dynamique attribue une adresse IP à une machine parmi le pool d'adresse disponible. L'allocation automatique fonctionne de la même manière, mais fournit un baille infini, réservant ainsi l'IP de manière permanente. L'allocation manuelle, consiste à réserver une IP associée à une adresse MAC, garantissant à une machine de toujours obtenir la même adresse.

   Grâce à l'allocation dynamique d'adresse IP, une adresse IP peut être réutilisée sur le réseau lorsqu'une machine n'est plus connectée, permettant ainsi de profiter au mieux de la plage d'adresse disponible. De plus la configuration manuelle de chaque client peut être longue et source d'erreur, et en cas de modification du réseau (changement de l'adresse du dns ou de la passerelle par exemple) il est nécessaire de reconfigurer chaque client. Grâce à DHCP, les modifications sont apportées uniquement au serveur DHCP, propageant ainsi la mise à jour de la configuration à tous les clients.

   Il est possible d'avoir plusieurs serveurs DHCP sur un réseau, les clients DHCP doivent attendre un certains temps lors d'une demande de configuration, afin de recevoir plusieurs offres, et de pouvoir choisir celle qui lui convint le mieux.

   Un client peut également demander à utiliser certains paramètres spécifique, comme une adresse réseau particulière ou une durée de bail.

   Un serveur DHCP s'assure qu'une adresse IP n'est pas utilisée 2 fois sur le même réseau. Il mémorise les configurations client de manière à redonner, dans la mesure du possible, la même configuration au même client.

Format d'un message DHCP


_op (1)____|_Htype (1)____|_Hlen (1)____|_Hops (1)
________________________xid (4)___________________
_____________Secs (2)____|_flags (2)______________
_______________________ciaddr (4)_________________
_______________________yiaddr (4)_________________
_______________________siaddr (4)_________________
_______________________giaddr (4)_________________
_______________________chaddr (16)________________
_______________________sname (64)_________________
______________________fichier (128)_______________
____________________options (variable)____________

Description des champs

op (1 octet) Code opération du message / type du message. 1 = BOOTREQUEST, 2 = BOOTREPLY
htype (1 octet) Adresse matérielle, voir la section ARP dans le RFC "Assigned Numbers" ; par ex., '1' = Ethernet 10Mb.
hlen (1 octet) Longueur de l'adresse matérielle (par ex. '6' for Ethernet 10Mb).
hops (1 octet) Mis à zéro par le client, utilisé de manière optionnelle par les agents de relais quand on démarre via un agent de relais
xid (4 octets) Identifiant de transaction, un nombre aléatoire choisit par le client, utilisé par le client et le serveur pour associer les messages et les réponses entre un client et un serveur
secs (2 octets) Rempli par le client, les secondes s'écoulent depuis le processus d'acquisition ou de renouvellement d'adresse du client
flags (2 octets) Drapeaux (voir figure 2).
ciaddr (4 octets) Adresse IP des clients, rempli seulement si le client est dans un état AFFECTÉ, RENOUVELLEMENT ou REAFFECTATION et peut répondre aux requêtes ARP
yiaddr (4 octets) 'votre' (client) adresse IP.
siaddr (4 octets) Adresse IP du prochain serveur à utiliser pour le processus de démarrage ; retournée par le serveur dans DHCPOFFER et DHCPACK.
giaddr (4 octets) Adresse IP de l'agent de relais, utilisée pour démarrer via un agent de relais.
chaddr (16 octets) Adresse matérielle des clients.
sname (64 octets) Nom d'hôte du serveur optionnel, chaîne de caractères terminée par un caractère nul.
fichier (128 octets) Nom du fichier de démarrage, chaîne terminée par un nul ; nom "generic" ou nul dans le DHCPDISCOVER, nom du répertoire explicite dans DHCPOFFER.
options (variable) Champ de paramètres optionnels. Voir le document d'options pour une liste des options définies.

Alloctation d'une adresse réseau

1) le client diffuse un message DHCPDISCOVER sur son réseau local physique. Ce message peut inclure des options qui suggèrent des valeurs pour les adresses réseau et la durée du bail.
2) chaque serveur DHCP peut répondre avec un message DHCPOFFER, qui inclut une adresse réseau valide dans le champ yiadrr, ainsi que d'autres paramètres de configuration.
3) le client choisit parmi les propositions DHCPOFFER reçu par les serveur DHCP celle qui lui convient le mieux, puis diffuse un DHCPREQUEST, en re-spécifiant l'adresse IP choisie et les options de configurations.
4) le serveur répond par un DHCPACK en re-spécifiant l'adresse et les paramètres de configuration pour valider la demande du client.
5) Le client DEVRAIT faire une vérification finale sur les paramètres (généralement un ARP). Si le client détecte que l'adresse est déjà utilisée, il DOIT envoyer un DHCPDECLINE au serveur et relancer le processus de configuration. Le client DEVRAIT attendre un minimum de dix secondes avant de relancer la configuration pour éviter un trafic réseau excessif dans le cas d'un bouclage.

En cas de requête invalide, par exemple un DHCPREQUEST contenant une adresse IP invalide ou que le bail a expiré, le serveur peut diffuser un DHCPNACK.
Si l'adresse IP reçu par un client est déjà utilisée par un autre client du réseau, le client peut envoyer un DHCPDECLINE pour prévenir le serveur DHCP.
Lorsque le client désire libérer l'adresse réseau, il envoie un DHCPRELEASE au serveur.
Le client peut seulement demander les paramètres de configuration locaux avec un message DHCPINFORM. Dans ce cas le client possède déjà une adresse réseau attribuée de manière externe.

Format des messages DHCP

   DHCP utilise UDP comme protocole de transport des messages.

   Un message DHCPDISCOVER contient l'adresse MAC source du client et l'adresse MAC de diffusion en destination (FF:FF:FF:FF:FF:FF). L'adresse IP source est 0.0.0.0 et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Le port source est 68 et le port de destination est 67. Cette diffusion est nécessaire puisque le client ne connait pas le ou les adresses des serveur DHCP.

   Un message DHCPOFFER contient l'adresse MAC source du serveur, l'adresse MAC de destination du client. L'adresse IP source est celle du serveur DHCP, et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Port source 67 et port destination 68. Ce message contient les paramètre de configuration.

   Un message DHCPREQUEST contient l'adresse MAC source du client et l'adresse MAC de diffusion en destination (FF:FF:FF:FF:FF:FF). L'adresse IP source est 0.0.0.0 et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Le port source est 68 et le port de destination est 67. Ce message est toujours en diffusion puisque cela permet à tous les serveur DHCP de recevoir le DHCPREQUEST. Le champ Server Identifier permet de spécifier à quel serveur DHCP est destiné le DHCPREQUEST. La diffusion permet aux autres serveur DHCP d'être avertit que le client décline leur DHCPOFFER. Ce message contient également les paramètres de configuration.

   Un message DHCPACK contient l'adresse MAC source du serveur, l'adresse MAC de destination du client. L'adresse IP source est celle du serveur DHCP, et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Port source 67 et port destination 68. Ce message contient de nouveau les paramètres de configuration. Il permet de confirmer l'attribution de l'adresse réseau. Un client qui se souvient de l'adresse réseau qui lui a déjà été attribuée, peut ignorer l'envoie d'un DHCPDISCOVER et envoie directement un DHCPREQUEST. Lors du renouvellement d'un bail, le client envoie un DHCPREQUEST, mais en unicast, le serveur DHCP lui envoie un DHCPACK confirmant le renouvellement du bail.

Durée et renouvellement du bail

   Le client maintient deux temporisateurs, T1 et T2 qui spécifient les temps auxquels le client essaie d'étendre son bail sur son adresse réseau. T1 est le temps au bout duquel le client entre en état RENOUVELLEMENT et tente de contacter le serveur qui a émis l'adresse réseau du client. T2 est le temps au bout duquel le client entre en état REAFFECTATION et tente de contacter un serveur. T1 DOIT être plus récent que T2, qui doit être plus récent que la date à laquelle expire le bail.

   Au temp T1 ( 0,5*durée_du_bail) le client envoie un message DHCPREQUEST. Si aucun DHCPACK n'arrive avant T2 (0,875*durée_du_bail) le client envoie un DHCPREQUEST. En cas de non réponse le client peut re-émettre un DHCPREQUEST à la moitié du temps restant, jusqu'à un minimum de 60sec.

   Si le bail expire avant que le client ne reçoive un DHCPACK, le client passe en état INIT, il DOIT alors immédiatement stopper tout processus réseau et nécessite une initialisation des paramètres réseau comme si le client n'était pas initialisé.

Relay DHCP

   Comme les clients contactent les serveurs DHCP à l'aide d'une diffusion, dans un inter-réseau, vous devrez théoriquement installer un serveur DHCP par sous-réseau. Si votre routeur prend en charge la RFC 1542, il peut faire office d'agent de relais DHCP, et ainsi relayer les diffusions de demande d'adresse IP des clients DHCP dans chaque sous-réseau.

   Si votre routeur ne prend pas en charge la RFC 1542, une machine serveur peut être configurée comme agent de relais DHCP, il suffira de lui spécifier l'adresse du serveur DHCP. Les demandes des clients DHCP seront relayées vers le serveur DHCP par l'agent de relais DHCP qui transmettra les offres aux clients.

   Après avoir envoyé une trame de broadcast, le client DHCP dialoque avec l'agent de relai DHCP en unicast. L'agent demande une adresse au serveur DHCP dont il connaît l'adresse (2). Le serveur retourne à l'agent une adresse (3) qui est donnée au client DHCP par l'agent (4).

   Le principal problème du service DHCP est la mise à jour des serveurs de noms d'hôtes. Bind sous Linux permet la mise à jour dynamique (RFC 2136) grâce à un serveur "updater" qui peut ajouter ou supprimer dynamiquement des enregistrements de ressources. Il faut pour corriger cela installer un serveur DNS dynamique ( DDNS) qui accepte les inscriptions des clients DHCP.
^
07 juillet 2013

htmlpdflatexmanmd




rfc2307-bis02

rfc2307-bis02

Mappage des entités unix et TCP/IP dans ldap

Attributs

uidNumber Identifiant Unique d’un utilisateur dans un domaine administratif
gidNumber Identifiant Unique d’un group dans un domaine administratif
gecos General Comprehensive Operating System
homeDirectory Chemin absolus du répertoire personnel
loginShell Chemin du shell de connection
shadowLastChange Jours depuis le 1er janvier 1970 que le mot de passe as été changé
shadowMin Nombre de jours minimum avant qu’un mot de passe puisse être changé
shadowMax Nombre de jours maximum avant qu’un mot de passe expire
shadowWarning Nombre de jours avant que l’utilisateur ne soit prévenus que son mot de passe va expirer
shadowInactive Nombre de jours après que le mot de passe ait expiré pour que le compte soit désactivé
shadowExpire Jours depuis le 1er Janvier 1970 que le compte est désactivé
shadowFlag Champ réservé
memberUid Nom de connexion appartenant au groupe
memberNisNetgroup Entité NIS appartenant au netgroup
nisNetgroupTriple triplet hostname/username/domainname
ipServicePort Numéro de port de service
ipServiceProtocol Nom du protocole de service
ipProtocolNumber Numéro de protocole IP
oncRpcNumber Numéro ONC RPC
ipHostNumber Adresse IP de l’hôte
ipNetworkNumber IP du réseau (sans les ’0’, ex 192.168)
ipNetmaskNumber Masque de sous réseau
macAddress Adresse MAC
bootParameter Paramètres de boot
bootFile Nom de l’image de boot
nisMapName Nom d’une map NIS générique
nisMapEntry Une entrée NIS générique
nisPublicKey Clé publique NIS
nisSecretKey Secret NIS
nisDomain Domaine NIS
automountMapName Nom d’une map d’automontage
automountKey Clé d’automontage
automountInformation Informations d’automontage

ObjectClass

posixAccount Compte avec des attributs POSIX
shadowAccount Attributs additionnels pour les mots de passe
posixGroup Groupe de comptes
ipService Service IP
ipProtocol Protocole IP
oncRpc Open Network Computing Remote Procedure Call
ipHost Un hôte, un périphérique IP
ipNetwork Un réseau
nisNetgroup Un netgroup
nisMap Une map NIS
nisObject Une entrée dans une map NIS
ieee802Device Un périphérique avec une adresse MAC
bootableDevice Un périphériques avec des paramètres de démarrage
nisKeyObject Un objet avec une clé publique et un secret
nisDomainObject Associe un domaine NIS avec un contecte de nommage
automountMap Une map d’automontage
automount Informations d’automontage
groupOfMembers Un groupe avec des membres

- Il est suggéré que uid et cn soient utilisés comme attributs de nommage des entrées posixAccount et posixGroup, respectivement.
- Les membres de groupe peuvent être des noms de connexion (valeurs de memberUid) ou des DN (valeurs de member)
- Le champ GECOS d’un compte est déterminé par l’attribut gecos. S’il n’est pas présent, le cn doit être utilisé.
- Une entrée de classe posixAccount, posixGroup ou shadowAccount sans authPassword ou userPassword ne devrait pas être utilisé pour l’authentification.

Si userPassword est utilisé, ses valeurs doivent être représentées par la syntaxe suivante:
passwordvalue = schemeprefix hashedpasswd
schemeprefix = "" scheme ""
scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme
altscheme = "x-" keystring
hashedpasswd = hashed password

Définition des attributs

attributetype ( 1.3.6.1.1.1.1.0 NAME ’uidNumber’
    DESC ’An integer uniquely identifying a user in an administrative domain’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.1 NAME ’gidNumber’
    DESC ’An integer uniquely identifying a group in an administrative domain’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.2 NAME ’gecos’
    DESC ’The GECOS field ; the common name’
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.3 NAME ’homeDirectory’
    DESC ’The absolute path to the home directory’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.4 NAME ’loginShell’
    DESC ’The path to the login shell’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.5 NAME ’shadowLastChange’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.6 NAME ’shadowMin’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.7 NAME ’shadowMax’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.8 NAME ’shadowWarning’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.9 NAME ’shadowInactive’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.10 NAME ’shadowExpire’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.11 NAME ’shadowFlag’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.12 NAME ’memberUid’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.13 NAME ’memberNisNetgroup’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.14 NAME ’nisNetgroupTriple’
    DESC ’Netgroup triple’
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.15 NAME ’ipServicePort’
    DESC ’Service port number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.16 NAME ’ipServiceProtocol’
    DESC ’Service protocol name’
    EQUALITY caseIgnoreMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 1.3.6.1.1.1.1.17 NAME ’ipProtocolNumber’
    DESC ’IP protocol number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.18 NAME ’oncRpcNumber’
    DESC ’ONC RPC number’
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.19 NAME ’ipHostNumber’
    DESC ’IPv4 addresses as a dotted decimal omitting leading zeros or IPv6 addresses as defined in RFC2373’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.20 NAME ’ipNetworkNumber’
    DESC ’IP network omitting leading zeros, eg. 192.168’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.21 NAME ’ipNetmaskNumber’
    DESC ’IP netmask omitting leading zeros, eg. 255.255.255.0’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.22 NAME ’macAddress’
    DESC ’MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.23 NAME ’bootParameter’
    DESC ’rpc.bootparamd parameter’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.24 NAME ’bootFile’
    DESC ’Boot image name’
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributetype ( 1.3.6.1.1.1.1.26 NAME ’nisMapName’
    DESC ’Name of a generic NIS map’
    EQUALITY caseIgnoreMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.1564 )
    
attributetype ( 1.3.6.1.1.1.1.27 NAME ’nisMapEntry’
    DESC ’A generic NIS entry’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.151024
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.28 NAME ’nisPublicKey’
    DESC ’NIS public key’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.29 NAME ’nisSecretKey’
    DESC ’NIS secret key’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.30 NAME ’nisDomain’
    DESC ’NIS domain’
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26256 )
    
attributetype ( 1.3.6.1.1.1.1.31 NAME ’automountMapName’
    DESC ’automount Map Name’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.32 NAME ’automountKey’
    DESC ’Automount Key value’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )
    
attributetype ( 1.3.6.1.1.1.1.33 NAME ’automountInformation’
    DESC ’Automount information’
    EQUALITY caseExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

Définition des Classe d’objets


objectclass ( 1.3.6.1.1.1.2.0 NAME ’posixAccount’ SUP top AUXILIARY
    DESC ’Abstraction of an account with POSIX attributes’
    MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
    MAY ( authPassword $ userPassword $ loginShell $ gecos $
    description ) )
    
objectclass ( 1.3.6.1.1.1.2.1 NAME ’shadowAccount’ SUP top AUXILIARY
    DESC ’Additional attributes for shadow passwords’
    MUST uid
    MAY ( authPassword $ userPassword $ description $
    shadowLastChange $ shadowMin $ shadowMax $
    shadowWarning $ shadowInactive $
    shadowExpire $ shadowFlag ) )
    
objectclass ( 1.3.6.1.1.1.2.2 NAME ’posixGroup’ SUP top AUXILIARY
    DESC ’Abstraction of a group of accounts’
    MUST gidNumber
    MAY ( authPassword $ userPassword $ memberUid $
    description ) )
    
objectclass ( 1.3.6.1.1.1.2.3 NAME ’ipService’ SUP top STRUCTURAL
    DESC ’Abstraction an Internet Protocol service. Maps an IP port and protocol (such as tcp or udp) to one or more names ; the distinguished value of the cn attribute denotes the service’s canonical name’
    MUST ( cn $ ipServicePort $ ipServiceProtocol )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.4 NAME ’ipProtocol’ SUP top STRUCTURAL
    DESC ’Abstraction of an IP protocol. Maps a protocol number to one or more names. The distinguished value of the cn attribute denotes the protocol canonical name’
    MUST ( cn $ ipProtocolNumber )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.5 NAME ’oncRpc’ SUP top STRUCTURAL
    DESC ’Abstraction of an Open Network Computing (ONC) [RFC1057] Remote Procedure Call (RPC) binding. This class maps an ONC RPC number to a name. The distinguished value of the cn attribute denotes the RPC service canonical name’
    MUST ( cn $ oncRpcNumber )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.6 NAME ’ipHost’ SUP top AUXILIARY
    DESC ’Abstraction of a host, an IP device. The distinguished value of the cn attribute denotes the host’s canonical name. Device SHOULD be used as a structural class’
    MUST ( cn $ ipHostNumber )
    MAY ( authPassword $ userPassword $ l $ description $
    manager ) )
    
objectclass ( 1.3.6.1.1.1.2.7 NAME ’ipNetwork’ SUP top STRUCTURAL
    DESC ’Abstraction of a network. The distinguished value of the cn attribute denotes the network canonical name’
    MUST ipNetworkNumber
    MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) )
    
objectclass ( 1.3.6.1.1.1.2.8 NAME ’nisNetgroup’ SUP top STRUCTURAL
    DESC ’Abstraction of a netgroup. May refer to other netgroups’
    MUST cn
    MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
    
objectclass ( 1.3.6.1.1.1.2.9 NAME ’nisMap’ SUP top STRUCTURAL
    DESC ’A generic abstraction of a NIS map’
    MUST nisMapName
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.10 NAME ’nisObject’ SUP top STRUCTURAL
    DESC ’An entry in a NIS map’
    MUST ( cn $ nisMapEntry $ nisMapName )
    
objectclass ( 1.3.6.1.1.1.2.11 NAME ’ieee802Device’ SUP top AUXILIARY
    DESC ’A device with a MAC address ; device SHOULD be used as a structural class’
    MAY macAddress )
    
objectclass ( 1.3.6.1.1.1.2.12 NAME ’bootableDevice’ SUP top AUXILIARY
    DESC ’A device with boot parameters ; device SHOULD be used as a structural class’
    MAY ( bootFile $ bootParameter ) )
    
objectclass ( 1.3.6.1.1.1.2.14 NAME ’nisKeyObject’ SUP top AUXILIARY
    DESC ’An object with a public and secret key’
    MUST ( cn $ nisPublicKey $ nisSecretKey )
    MAY ( uidNumber $ description ) )
    
objectclass ( 1.3.6.1.1.1.2.15 NAME ’nisDomainObject’ SUP top AUXILIARY
    DESC ’Associates a NIS domain with a naming context’
    MUST nisDomain )
    
objectclass ( 1.3.6.1.1.1.2.16 NAME ’automountMap’ SUP top STRUCTURAL
    MUST ( automountMapName )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.17 NAME ’automount’ SUP top STRUCTURAL
    DESC ’Automount information’
    MUST ( automountKey $ automountInformation )
    MAY description )
    
objectclass ( 1.3.6.1.1.1.2.18 NAME ’groupOfMembers’ SUP top STRUCTURAL
    DESC ’A group with members (DNs)’
    MUST cn
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
    description $ member ) )

^
10 novembre 2014

htmlpdflatexmanmd




rfc2315

rfc2315

Syntaxe des messages cryptographiques

Définitions

   Pour ce document, les définitions suivantes s'appliquent:

AlgorithmIdentifier un type qui identifie un algorithme et ses paramètres associés. Ce type est définis dans X.509.
ASN.1 Abstract Syntax Notation One, définis dans X.208
Attribute un type qui contient un type d'attribut et une ou plusieurs valeurs d'attribut. Ce type est définis dans X.501.
BER Basic Encoding Rules, comme définis dans X.209
Certificat un type qui lie un dn d'une entité à une clé publique avec une signature numérique. Ce type est définis dans X.509. Ce type contient également le dn du fournisseur du certificat, un numéro de série, l'algorithme de signature, et une période de validité.
CertificateSerialNumber un type qui identifie de manière unique un certificat avec ceux signés par un fournisseur de certificat particulier. Ce type est définis dans X.509.
CertificateRevocationList un type qui contient des informations sur les certificats dont la validité a été prématurément révoquée par le fournisseur.
DER Distinguished Encoding Rules for ASN.1, comme définis dans X.509
DES Data Encryption Standard, comme définis dans FIPS PUB 46-1
desCBC L'identifiant d'objet pour DES en mode cipher-block chaining
ExtendedCertificate Un type qui consiste d'un certificat X.509 et un jeu d'attributs, signés collectivement par le fournisseur du certificat. Définis dans PKCS#6
MD2 RSA Data Security, incluant l'algorithme MD2. rfc1319
md2 L'identifiant d'objet pour MD2
MD5 RSA Data Security, incluant l'algorithme MD5. rfc1321
md5 L'identifiant d'objet pour MD5
Name Un type qui identifie de manière unique des objets dans un annuaire X.500. Ce type est définis dans X.501. Dans un certificat X.509, le type identifie de fournisseur du certificat et l'entité dont la clé publique est certifiée.
PEM Internet Privacy-Enhanced, comme définis dans rfc1421-1424
RSA Le crypto-système à clé publique RSA
rsaEncryption L'identifiant d'objet pour le chiffrement RSA

Vue générale

   La syntaxe est suffisamment généraliste pour supporter de nombreux types de contenus. Ce document en définis 6: donnée, donnée signée, donnée enveloppée, donnée enveloppée et signée, donnée hashée et donnée chiffrée. D'autres types peuvent être ajoutés dans le future. L'utilisation des types de contenu définis en dehors de ce document est possible, mais est sujet à agrément bilatéral entre les parties échangeant du contenu.

   Ce document exporte un type, ContentInfo, et divers identifiants d'objets.

   Il y a 2 classes de type de contenu: base et amélioré. Les types de contenu dans la classe de base contient seulement les donnée, sans amélioration cryptographique. Présentement, un type de contenu est dans cette classe, le type de contenu donnée. Les types de contenus dans la classe améliorée contiennent le contenu d'un certain type (possiblement chiffré), et d'autre améliorations cryptographique. Par exemple, le contenu donnée enveloppée peut contenir du contenu de données signée, qui peut contenir du contenu donnée. Les 4 type de contenu non données remplissent la classe améliorée. Les types de contenu dans la classe améliorée emploient ainsi l'encapsulation, donnent naissance au termes de contenu extérieur ( celui contenant les améliorations) et de contenu intérieur ( celui qui est amélioré ).

   Le document est conçu de manière à ce que les types de contenus améliorés puissent être préparés dans une simple classe en utilisant un encodage BER de longueur indéfinie. L'opération à une seule passe est spécialement utile si le contenu est stockée sur des cassettes, ou est pipé depuis un autre processus. Un des inconvénients de l'opération simple-passe est qu'il est difficile de sortir un encodé DER en une simple passe, vu que la longueur de divers composants peuvent ne pas être connus à l'avance. Vu que l'encodage DER est requis par les type de contenu donnée signée, donnée signé et enveloppée, donnée hashée, une passe supplémentaire peut être nécessaire quand un type de contenu autre que donnée est le contenu interne de l'un de ces types de contenu.

Types utiles

   Les sections suivantes définissent les types qui sont utiles dans au moins 2 endroits dans le document.

CertificateRevocationLists

   Le type CertificateRevocationList donne un jeu de listes de révocation de certificat. Il est conçus pour que le jeu d'informations soit suffisant pour déterminer si les certificats avec lequel le jeu est associé est "hot listed" mais il peut y avoir plusieurs listes de révocation que nécessaire, ou moins que nécessaire.

  CertificateRevocationLists ::= SET OF CertificateRevocationList

ContentEncryptionAlgorithmIdentifier

   Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu tel que DES. Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement map une chaîne d'octets ( le message ) en une autre chaîne d'octet ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse.

  ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

DigestAlgorithmIdentifier

   Le type DigestAlgorithmIdentifier identifie un algorithme de hashage, ex. MD2 et MD5. Un algorithme de hashage mappe une chaîne d'octets ( le message ) en une autre chaîne d'octets ( le hash ).

  DigestAlgorithmIdentifier ::= AlgorithmIdentifier

DigestEncryptionAlgorithmIdentifier

   Le type DigestEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de hash avec lequel un hash peut être chiffré. Par exemple, rsaEncryption. Un algorithme de chiffrement de hash supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le hash ) a une autre chaîne d'octets ( le hash chiffré ) sous le contrôle d'une clé de chiffrement de hash. L'opération de déchiffrement est l'inverse.

  DigestEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ExtendedCertificateOrCertificate

Le type ExtendedCertificateOrCertificate donne soit un certificat étendu PKCS#6 ou un certificat X.509. Ce type suit la syntaxe recommandée dans PKCS#6:
ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate, -- X.509
    extendedCertificate [0] IMPLICIT ExtendedCertificate }

ExtendedCertificatesAndCertificates

   le type ExtendedCertificatesAndCertificates donne un jeu de certificats étendus et de certificats X.509. Il est conçus pour que le jeu soit suffisant pour contenir des chaînes depuis un "root" ou "top-level certification authority" vers tous les signataires avec lequel le jeu est associé, mais il peut y avoir plus de certificats que nécessaire, ou moins.

  ExtendedCertificatesAndCertificates ::= SET OF ExtendedCertificateOrCertificate

IssuerAndSerialNumber

Le type IssuerAndSerialNumber identifie un certificat ( et donc une entité et une clé publique ) par le nom distinct du fournisseur du certificat et un numéro de série spécifique au fournisseur.
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }

KeyEncryptionAlgorithmIdentifier

   Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé avec lequel une clé de chiffrement de contenu peut être chiffrée. Ex: rsaEncryption.

  KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

Version

   Le type Version donne un numéro de version de syntaxe, pour compatibilité avec de future révisions de ce document.

Syntaxe générale

La syntaxe générale pour le contenu échangé entre les entités en accord avec ce document associe un type de contenu avec le contenu. La syntaxe devrait avoir le ContentInfo en ASN.1:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content
    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
    
ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu. C'est un OID, qui signifie que c'est un chaîne unique assignée par l'autorité qui définis le type de contenu.
content Est le contenu. Ce champ est optionnel, et si non présent, sa valeur attendu doit être fournie par d'autres moyens.

Notes

        1. Les méthodes ci-dessous assument que le type de contenu peut être déterminé uniquement par le contentType, donc le type définis avec l'oid ne devrait par être un type CHOICE.
        2. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée signée, donnée signée et enveloppée, ou donnée hashée, un algorithme message-digest est appliqué aux octets du contenu encodé DER du champ content. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée enveloppée ou donnée signée et enveloppée, un algorithme de chiffrement de contenu est appliqué aux octets d'un encodé BER à longueur définie du champ.
        3. L'omission optionnelle du champ content rend possible la construction de signatures externes, par exemple, sans modification ou réplication du contenu avec lequel la signature s'applique. Dans le cas de signatures externe, le contenu à signer sera omis de la valeur ContentInfo encapsulée interne inclus dans le type de contenu donnée signée.

Type de contenu donnée

   Le type de contenu de donnée est conçus pour référer à des chaînes arbitraires d'octets, tel que des fichiers texte ASCII. L'interprétation est laissée à l'application, de telles chaînes n'ont pas besoin d'une structure interne.

  Data ::= OCTET STRING

Type de contenu donnée signée

   Le type de contenu donnée signée consiste du contenu d'un type et du hash du contenu pour 0 ou plusieurs signataires. Le hash chiffré pour un signataire est une signature numérique sur le contenu pour ce signataire. Tout type de contenu peut être signé par plusieurs signataires en parallèle. De plus, la syntaxe a un cas dégénéré dans lequel il n'y a pas de signataires sur le contenu. Le cas dégénéré fournis un moyen de diffuser des certificat et des listes de révocation de certificat.

   Il est prévu que l'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu du type de contenu donnée. Une autre application typique est de diffuser des certificat et des listes de révocation de certificat.

  Le processus par lequel la donnée signée est construite se fait par les étapes suivantes:

1. Pour chaque signataire, un message digest est calculé sur le contenu avec un algorithme de hashage spécifique au signataire. ( Si 2 signataires emploient le même algorithme, le hash doit alors être calculé pour seulement un d'entre eux). Si le signataire authentifie une information autre que le contenu, le hash du contenu et l'autre information sont hashé avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash et d'autres informations associées sont chiffrées avec la clé privé du signataire.
3. Pour chaque signataire, le hash chiffré et d'autres informations spécifiques au signataire sont collectés dans une valeur SignerInfo. Les certificats et les listes de révocation de certificat pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectés dans cette étape.
4. Les algorithme de hashage pour tous les signataires et les valeur SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire vérifie les signatures en déchiffrant le hash chiffré pour chaque signataire avec la clé publique du signataire, puis compare le hash récupéré avec un hash calculé indépendamment. La clé publique du signataire est soit contenue dans un certificat inclus dans l'information du signataire, soit est référencée par un nom de fournisseur et un numéro de série spécifique au fournisseur qui identifie de manière unique le certificat pour la clé publique.

   Cette section est divisée en 5 parties. La première décrit le type SignedData, la seconde décrit le type SignerInfo, la troisième et quatrième décrivent le hashage, et la dernière section est un sommaire de la compatibilité avec PEM.

type SignedData

Le type de contenu donnée signée devrait avec le type ASN.1:
SignedData ::= SEQUENCE {
    version Version,
    digestAlgorithms DigestAlgorithmIdentifiers,
    contentInfo ContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }
    
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. Devrait être à 1 pour cette version du document.
digestAlgorithms Est une collection d'identifiant d'algorithme de hashage. Il peut y avoir plusieurs élément dans la collection, incluant 0. Chaque élément identifie l'algorithme de hashage ( et ses paramètres associés ) sous lequel le contenu est hashé pour un signataire. La collection est conçue pour lister les algorithmes de hashage employés par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification la vérification de signature en une passe.
contentInfo Est le contenu qui est signé. Il peut avoir n'importe quel type de contenu défini.
certificates Est le jeu de certificat étendu PKCS#6 et de certificats X.509. Il est prévu que le jeu soit suffisant pour contenir des chaînes depuis un root reconnus pour tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats que nécessaire, et il peut y avoir les certificats suffisants pour contenir les chaînes depuis 2 ou plusieurs autorité racine indépendants. Il peut également y avoir moins de certificats que nécessaire, s'il est prévu que la vérification des signatures aient un moyen alternatif.
clrs Est un jou de liste de révocation de certificats. Il est prévus que le jeu contienne des informations suffisantes pou déterminer si les certificats dans le champ certificates sont listés ou non, mais une telle correspondance n'est pas nécessaire. Il peut y avoir plus d'un liste de révocation que nécessaire, et il peut y en avoir moins que nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs élément dans la collection, ou aucun.

notes

1. Le fait que le champ digestAlgorithms vient avant le champ contentInfo et que le champ signerInfos vient après rend possible le traitement d'une valeur SignedData en une seul passe.
2. Les différences entre la version 1 de SignedData et la version 0 (définis dans PKCS#7, version 1.4) sont les suivantes:

        - Les champs digestAlgorithms et signerInfos peuvent contenir 0 éléments dans la version 1, mais pas dans la version 0
        - Le champ crl est permis dans le version 1, mais pas dans la version 0.

           Excepté pour la différence dans le numéro de version, les valeurs SignedData version 0 sont acceptable comme valeurs de version 1. Un implémentation peut cependant traiter les valeurs SignedData n'importe quelle version comme si elles étaient de la version 1.

3. Dans le cas dégénéré où il n'y a pas de signataires sur le contenu, la valeur ContentInfo à signer est sans importance. Il est recommandé dans ce cas que le type de contenu de la valeur ContentInfo à signer soit une donnée, et le champ content du ContentInfo est omis.

Type SignerInfo

Les informations par signataires sont représenté dans le type SignerInfo:
SignerInfo ::= SEQUENCE {
    version Version,
    issuerAndSerialNumber IssuerAndSerialNumber,
    digestAlgorithm DigestAlgorithmIdentifier,
    authenticatedAttributes
        [0] IMPLICIT Attributes OPTIONAL,
    digestEncryptionAlgorithm
        DigestEncryptionAlgorithmIdentifier,
    encryptedDigest EncryptedDigest,
    unauthenticatedAttributes
        [1] IMPLICIT Attributes OPTIONAL }
    
EncryptedDigest ::= OCTET STRING

version Est le numéro de version de syntaxe. Devrait être à 1 pour cette version du document.
issuerAndSerialNumber Spécifie le certificat du signataire ( et donc de dn et la clé publique ) par dn de fournisseur et numéro de série spécifique au fournisseur.
digestAlgorithm Identifie l'algorithme de hashage ( et ses paramètres associés ) sous lequel le contenu et les attributs authentifiés ( si présent ) sont hashés. Il devrait être parmis ceux dans le champ digestAlgorithms de la valeur SignerInfo supérieur.
authenticatedAttributes Est un jeu d'attributs qui sont signés (ex: authentifiés) par le signataire. Le champ est optionnel, mais il doit être présent si le type de contenu de la valeur ContentInfo à signer n'est pas une donée. Si le champ est présent, il doit contenir, au minimum, 2 attributs:

        1. Un attribut de type de contenu PKCS#9 ayant comme valeur le type de contenu de la valeur ContentInfo à signer
        2. Un attribut de hash PKCS#9 ayant comme valeur le hash du contenu.

D'autres type d'attributs peut être utiles ici, tel que la date de signature, également définis dans PKCS#9.
digestEncryptionAlgorithm Identifie l''algorithme de chiffrement ( et ses paramètres associés) sous lequel le message digest et informations associées sont chiffrés avec la clé privée du signataire.
encryptedDigest Est le résultat du chiffrement du hash et des informations associées avec là clé privée du signataire.
unauthenticatedAttributes Est un jeu d'attributs qui ne sont pas signé par le signataire. Ce champ est optionnel. Les types d'attributs qui peuvent être utiles ici, tels que countersignatures, sont définis dans PKCS#9.

Notes

1. Il est recommandé dans l'intérêt de la compatibilité PEM que le champ authenticatedAttributes soit omis quand le type de contenu de la valeur ContentInfo est une donnée et qu'il n'y a pas d'autres attributs à signer.
2. La différence entre SignerInfo version 1 et version 0 est le processus de chiffrement du message-digest. Seul les processus compatibles PEM sont différents, reflétant les changements dans les méthodes de signature PEM. Il n'y a pas de différence dans les processus de chiffrement de message-digest non compatible PEM.
Il est suggéré que les implémentation PKCS génèrent seulement des valeurs SignedData version 1. Vu que la méthode de signature PEM avec la version 0 est obsolète.

Processus de hashage

   Le processus de hashage calcule un hash sur soit le contenu à signer soit le contenu avec les attributs authentifiés du signataire. Dans les 2 cas, l'entrée initial du processus de hashage est la valeur du contenu à signer. Spécifiquement, l'entrée initiale sont les octets de contenu du champ ContentInfo encodé en DER pour lequel le processus de signature est appliqué. Seul les octets des contenus encodé DER de ce champ sont hashé, ni les octets identifiant ni les octets de longueur.

   Le résultat du processus de hashage dépend de la présence ou non du champ authenticatedAttributes. Que ce champ est absent, le résultat est simplement le hash du contenu. Quand ce champ est présent, cependant, le résultat est le hash de l'encodage DER complet des valeurs d'attributs contenus dans le champ authenticatedAttributes. ( le tag IMPLICIT [0] dans le champ authenticatedAttributes ne fait pas partie des valeurs d'attributs. Le tag des valeurs d'attributs est SET OF, et l'encodé DER du tag SET OF, au lieu du tag IMPLICIT [0], doit être hashé avec les octets le longueur et de contenu des valeur d'attributs). Vu que la valeur Attributes, quand le champ est présent, doit contenir comme attribut le type de contenu et le hash du contenu, ces valeurs sont indirectement inclus dans le résultat.

   Quand le contenu à signer a le type de contenu donnée et que le champ authenticatedAttributes est absent, seul la valeur de la donnée est hashé. Cela a l'avantage que la longueur du contenu à signer n'a pas besoin d'être connu à l'avance dans le processus de chiffrement. Cette méthode est compatible avec PEM.

   Bien que les octets identifiant et les octets de longueur ne sont pas hashés, ils restent protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme de hashage vu qu'il est assumé infaisable de trouver 2 messages distincts ayant le même hash. De plus, en assumant que le type de contenu détermine de manière unique les octets identifiant, ces octets sont protégés implicitement dans une des 2 manières: sont par l'inclusion du type de contenu dans les attributs authentifiés, soit en utilisant l'alternative PEM qui implique que le type de contenu soit une donnée.

   Note: Le fait que le hash est calculé sur la partie encodée DER ne signifie pas que DES est la méthode requise pour représenter cette partie pour le transfère des données. En effet, il est prévu que certaines implémentations de ce document peut stocker des objets autre que encodés DER, mais de telles pratiques n'affectent par le calcule du hash.

Processus de chiffrement du hash

   L'entrée dans le processus de chiffrement de hash - la valeur fournie à l'algorithme de chiffrement de hash du signataire - inclus le résultat du processus de hashage et l'identifiant de l'algorithme de hashage. Le résultat du processus de chiffrement du hash est le chiffrement avec la clé privée du signataire de l'encodé DER d'une valeur de type DigestInfo:


DigestInfo ::= SEQUENCE {
    digestAlgorithm DigestAlgorithmIdentifier,
    digest Digest }
    
    Digest ::= OCTET STRING

digestAlgorithm Identifie l'algorithme de hash et les paramètres associés avec lequel le contenu et les attributs authentifié sont hashés. Il devrait être le même que le champ digestAlgorithm de la valeur SignerInfo supérieur.
digest est le résultat lu processus de hashage

Notes

1. La seule différence entre le processus de signature définie ici et les algorithme de signature définis dans PKCS#1 est que les signatures sont représentées en chaîne d'octets.
2. L'entrée du processus de chiffrement typiquement va avoir 30 octets ou moins. Si digestEncryptionAlgorithm est rsaEncryption de PKCS#1, cela signifie que la longueur du modulo RSA est au moins 328bits, ce qui est raisonnable et consistant avec les recommandations de sécurité.
3. Un identifiant d'algorithme de hashage est inclus dans la valeur DigestInfo pour limiter le dégâts résultant d'un algorithme de hashage compromis. Pour l'instant, supposons un adversaire qui est capable de trouver un hash MD2 donné. Cet adversaire pourrait ainsi forger une signature pour trouver un message avec le même hash, et présenter la signature précédente comme la signature sur le nouveau message. Cette attaque va réussir seulement si le signataire avec utilisé MD2, vu que la valeur DigestInfo contient l'algorithme. Si un signataire n'a jamais validé MD2 et utilise toujours MD5, alors le MD2 compromis n'affecte pas le signataire.
4. Il y a potentiellement une ambiguïté dû au fait que la valeur DigestInfo n'indique pas si le champ de hash contient seulement le hash du contenu ou le hash du champ authenticatedAttributes encodé DER complet. En d'autre termes, il est possible pour un adversaire de transformer une signature dans les attributs authentifiés à une qui apparaît être seulement dans le contenu en changeant le contenu à encoder DER du champ authenticatedAttributes, et ainsi supprimer le champ authenticatedAttributes. La transformation inverse est possible, mais nécessite que le contenu soit l'encodé DER d'une valeur d'attributs authentifiés, ce qui est peu probable. Cette ambiguïté n'est pas un nouveau problème, ni significatif, vu que le contexte va généralement empêcher les abus. En effet, il est également possible pour un adversaire de transformer une signature dans un certificat ou une liste de révocation de certificat à une qui apparaît être seulement dans le contenu donnée signée.

Compatibilité avec PEM

   La compatibilité avec les type de processus MIC-ONLY et MIC-CLEAR dans PEM se produisent quand le type de contenu de ContentInfo à signer est une donnée, il n'y a par d'attributs authentifiés, l'algorithme de hash est md2 ou md5, et l'algorithme de chiffrement de hassh est rsaEncryption. Sous toutes ces conditions, le hash chiffré produit ici matche celui produit dans PEM parce que:

1. La valeur d'entrée de l'algorithme de hash dans PEM est le même que dans ce document quand il n'y a pas d'attributs authentifiés, MD2 et MD5 dans PEM sont les même que md2 et md5.
2. La valeur chiffrée avec la clé privée du signataire dans PEM est la même que dans ce document quand il n'y a pas d'attributs authentifié. RSA dans PEM est le même que rsaEncryption.

   Les autres parties du type de contenu donnée signée ( certificates, CRLs, algorithm identifiers, etc.) sont facilement traduisible depuis et vers leur composant PEM correspondant.

Type de contenu donnée enveloppée

   Le type de contenu donnée enveloppée consiste d'un contenu chiffré de n'importe quel type et de clé de chiffrement de contenu chiffrés pour un ou plusieurs conteneurs. La combinaison du contenu chiffré et de la clé de chiffrement de contenu chiffrée pour un conteneur est une enveloppe numérique pour ce conteneur. Tout type de contenu peut être enveloppé pour autant de type de conteneurs en parallèle.

   Il est prévu que l'application typique du type de contenu donnée enveloppée est de représenter une ou plusieurs enveloppe numérique de conteneurs dans le contenu de donnée, donnée hashée, ou donnée signée. Le processus par lequel une donnée enveloppée est construite est faites des étapes suivantes:

1. Une clé de chiffrement de contenu pour un algorithme de chiffrement de contenu particulier est généré aléatoirement.
2. Pour chaque conteneur, la clé de chiffrement de contenu est chiffrée avec la clé publique du conteneur
3. Pour chaque conteneur, la clé de chiffrement chiffrée et d'autres informations spécifique au conteneur sont collectées dans une valeur RecipientInfo
4. Le contenu est chiffré avec la clé de chiffrement de contenu
5. Les valeurs RecipientInfo pour tous les conteneurs sont collectés ensemble avec le contenu chiffré dans une valeur EnvelopedData

   Un destinataire ouvre l'enveloppe en déchiffrant celle des clés de chiffrement de contenu chiffré avec la clé privée du destinataire et déchiffre le contenu chiffré avec la clé de chiffrement de contenu récupérée. La clé privée du destinataire est référencée par un dn de fournisseur et un numéro de série spécifique qui identifie de manière unique le certificat pour la clé publique correspondance.

   Cette section est divisée en 4 parties, la première décris le type EnvelopedData, la deuxième décris le type RecipientInfo, et la troisième et quatrième décrivent les processus de chiffrement de contenu et de chiffrement de clé. Ce type de contenu n'est pas compatible avec PEM, vu que PEM implique toujours des signatures numériques, jamais des enveloppes seules.

Type EnvelopedData

Le type de contenu donnée enveloppée devrait avoir le type ASN.1:
EnvelopedData ::= SEQUENCE {
    version Version,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo }
    
RecipientInfos ::= SET OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm
        ContentEncryptionAlgorithmIdentifier,
    encryptedContent
        [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
recipientInfos Est une collection d'information par destinataires. Il doit y avoir au moins un élément dans la collection
encryptedContentInfo Est l'information de contenu chiffré
contentType Indique le type de contenu
contentEncryptionAlgorithm Identifie l'algorithme de chiffrement de contenu et ses paramètres associés sous lequel le contenu est chiffré. Le processus de chiffrement de contenu est décris plus bas. Cet algorithme est le même pour tous les destinataires.
encryptedContent Est le résultat du chiffrement du contenu. Ce champ est optionnel, et si non présent, sa valeur doit être fournie par d'autres moyens.

   Note: Le fait que le champ recipientInfos vient avant le champ encryptedContentInfo rend possible le traitement d'une valeur EnvelopedData en une seule passe.

Type RecipientInfo

Les informations par destinataire sont représentés dans le type RecipientInfo:
RecipientInfo ::= SEQUENCE {
    version Version,
    issuerAndSerialNumber IssuerAndSerialNumber,
    keyEncryptionAlgorithm
    
        KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
EncryptedKey ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
issuerAndSerialNumber Spécifie le certificat du destinataire ( et donc sont dn et sa clé publique ) par dn de fournisseur et numéro de série.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé ( et ses paramètres associés ) avec lequel la clé de chiffrement de contenu est chiffrée avec la clé publique du destinataire.
encryptedKey Est le résultat du chiffrement de la clé de chiffrement de contenu avec la clé publique du destinataire.

Processus de chiffrement de contenu

   L'entrée pour le processus de chiffrement de contenu est la valeur du contenu à envelopper. Spécifiquement, l'entrée sont les octets du contenu de longueur définie encodée BER du champ content de la valeur ContentInfo pour lequel le processus d'enveloppe est appliqué. Seul les octets de contenu de l'encodé BER sont chiffrés, et non les octets identifiant ou les octets de longueur; ces octets ne sont pas représentés du tout.

   Quand le contenu à envelopper à un contenu de type donnée, seule la valeur de la donnée ( par ex. le contenu d'un fichier ) est chiffré. Cela a l'avantage que la longueur du contenu à chiffrer n'a pas besoin d'être connus à l'avance. Cette méthode est compatible avec PEM.

   Les octets identifiant et les octets de longueur ne sont pas chiffrés. Les octets de longueur peuvent être protégés implicitement par le processus de chiffrement, dépendant de l'algorithme de chiffrement. Les octets identifiant ne sont pas protégés du tout, bien qu'ils puissent être récupérés depuis le type de contenu, assumant que le type de contenu détermine de manière unique les octets identifiant. La protection explicite de l'identifiant et de la longueur nécessite que le type donnée signée et enveloppée soit employé, ou que les type de contenu donnée hashé, donnée enveloppée soient appliqués successivement.

Notes

1. La raison qu'un encodé BER de longueur définie est requise est que le bit indiquant si la longueur est définie ou indéfinie n'est pas enregistrée dans le type de contenu donnée enveloppée. L'encodage de longueur définie est plus appropriée pour des types simple tels que les chaîne d'octets.
2. Certains algorithmes de chiffrement de contenu assument que la longueur d'entrée est un multiple de k octets, où k › 1, et laissent l'application définir une méthode pour manipuler l'entrée dont la longueur ne serait pas un multiple de k octets. Pour de tels algorithmes, la méthode devrait être de compléter l'entrée à la fin avec k - (l mod k) octets, tous ayant la valeur k - (l mod k), où l est la longueur de l'entrée. En d'autre termes, l'entrée est remplie à la fin avec une des chaînes suivante:


01 -- if l mod k = k-1
02 02 -- if l mod k = k-2
    
    k k ... k k -- if l mod k = 0

           Le padding peut être supprimé de manière non-ambigu vu que toute l'entrée est remplie et qu'aucune chaîne de padding n'est un suffixe d'un autre. Cette méthode est définie si et seulement si k ‹ 256; les méthodes pour k supérieur sont un problème.

Processus de chiffrement de clé

   L'entrée du processus de chiffrement de clé - la valeur fournie à l'algorithme de chiffrement de clé du destinataire - est simplement la valeur de la clé de chiffrement de contenu.

Type de contenu donnée signée et enveloppée

   Cette section définis le type de contenu donnée signée et enveloppée. Pour faire court, le principal de cette section sont exprimée en terme des 2 sections précédentes.

   Le type de contenu donnée signée et enveloppée consiste d'un contenu chiffré de n'importe quel type, des clés de chiffrement de contenu chiffré pour un ou plusieurs destinataires, et du hash doublement chiffrés pour un ou plusieurs signataires. Le double chiffrement consiste d'un chiffrement avec la clé privée du signataire suivi par un chiffrement avec la clé de chiffrement de contenu.

   La combinaison du contenu chiffré et de la clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Le hash chiffré récupéré pour un signataire est une signature numérique sur le contenu récupéré pour ce signataire. Tout tupe de contenu peut être enveloppé pour des destinataire et signé par des signataire en parallèle.

   Il est prévu que l'application typique d'un type de contenu donnée enveloppée et signée est de représenter la signature numérique d'un signataire et une ou plusieurs enveloppe numérique d'un ou plusieurs destinataires dans le contenu du type de contenu donnée. Le processus pour signer et envelopper est construit selon les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu particulier est généré aléatoirement.
2. Pour chaque destinataire, la clé de chiffrement de contenu est chiffrée avec la clé publique du destinataire
3. Pour chaque destinataire, la clé de chiffrement de contenu chiffrée et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Pour chaque signataire, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. ( si 2 signataires emploient le même algorithme de hash, le hash doit être calculé une seule fois ).
5. Pour chaque signataire, le hash est les informations associées sont chiffrées avec la clé privée du signataire, et le résultat est chiffré avec la clé de chiffrement de contenu. ( le deuxième chiffrement peut nécessiter que le résultat du premier chiffrement soit padded à un multiple d'un taille de block)
6. Pour chaque signataire, le hash et les informations spécifique doublement chiffrés sont collecté dans une valeur SignerInfo.
7. Le contenu est chiffré avec la clé de chiffrement de contenu.
8. Les algorithmes de hash pour tous les signataires, les valeurs SignerInfo pour tous les signataires et les valeurs RecipientInfo pour tous les destinataires sont collecté ensemble avec le contenu chiffré dans une valeur SignedAndEnvelopedData.

   Un destinataire ouvre les enveloppes et vérifie les signature en 2 étapes. D'abord, celle contenant les clé de chiffrement de contenu est déchiffrée avec la clé privée du destinataire, et le contenu chiffré est déchiffré avec la clé de chiffrement de contenu récupéré. Ensuite, le hash doublement chiffré pour chaque signataire est déchiffré avec la clé de chiffrement de contenu récupérée, le résultat est déchiffré avec la clé publique du signataire et le hash récupéré est comparé avec un hash calculé indépendemment.

   Cette section est divisée en 3 parties. La première décris le type SignedAndEnvelopedData et la deuxième décris le processus de chiffrement. Les autres types et processus sont les même que dans les sections précédente. La troisième partie est un sommaire de compatibilité avec PEM.

   Note: Le type de contenu donnée signée et enveloppée fournis un amélioration cryptographique similaire à celui résultant d'un combinaison séquentielle des type de contenu donnée signée et donnée enveloppée. Cependant, vu que le type de contenu donnée signée et enveloppée n'a pas d'attributs authentifié ou non-authentifié, ni ne fournis d'enveloppe pour les information de signataire autre que la signature, la combinaison séquentielle est généralement préférable au contenu SignedAndEnvelopedData. Excepté quand la compatibilité avec le type de processus ENCRYPTED dans PEM est recherché.

Type SignedAndEnvelopedData

Le type de contenu donnée signée et enveloppée devrait avoir le type ASN.1:
SignedAndEnvelopedData ::= SEQUENCE {
    version Version,
    recipientInfos RecipientInfos,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encryptedContentInfo EncryptedContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
            OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
recipientInfos Est une collection d'information par destinataires. Il doit y avoir au moins un élément dans la collection
digestAlgorithms Est une collection d'identifiants d'algorithme de hashage.
encryptedContentInfo Est le contenu chiffré. Il peut avoir tout type de contenu
certificates Est un jeu de certificats PKCS#6 et de certificats X.509
crls Est un jeu de listes de révocation de certificat
signerInfos Est une collection d'information par signataire. Il doit y avoir au moins un élément dans la collection.

Notes

1. Le fait que les champs recipientInfos et digestAlgorithms soient avant les champs contentInfo et signerInfos rend possible de traiter un valeur SignedAndEnvelopedData en une passe.
2. La différence entre les version 0 et 1 de SignedAndEnvelopedData est que le champ crls est permis dans la version 1, mais pas dans la version 0.

Processus de chiffrement de hash

   L'entrée du processus de chiffrement est la même que pour processus de chiffrement de hash, mais le processus lui-même est différent. Spécifiquement, le processus à 2 étapes. D'abord, l'entrée est fournie à l'algorithme de chiffrement de hash du signataire. Ensuite, le résultat est chiffré avec la clé de chiffrement de contenu. Il n'y a pas d'encodage DER entre les 2 étapes; la valeur de sortie de la première étape est entrée directement dans la seconde étape. Ce processus est compatible avec le processus ENCRYPTED dans PEM.

   Note: Le but de la seconde étape est d'empêcher un adversaire de récupérer le hash du contenu. Sinon, un adversaire sera capable de déterminer qui d'une liste de contenus candidats est le contenu actuel en comparant leur hash.

Compatibilité avec PEM

   La compatibilité avec le type de processus ENCRYPTED de PEM se produit quand le type de contenu de la valeur ContentInfo à signer et envelopper est une donnée, l'algorithme de hash est md2 ou md5, l'algorithme de chiffrement est DES en mode CBC, l'algorithme de chiffrement de hash est rsaEncryption, et l'algorithme de chiffrement de clé est rsaEncryption. Sous toutes ces conditions, le hash doublement chiffré et la clé de chiffrement de contenu chiffré matchent celui produit dans PEM parce que les raisons données plus haut sont similaires aussi bien que les suivantes:

1. La valeur d'entrée de l'algorithme de chiffrement de contenu dans PEM est la même que dans ce document. DES en mode CBC est le même que desCBC.
2. La valeur d'entrée de l'algorithme de chiffrement de clé dans PEM est la même que dans ce document. RSA dans PEM est le même que rsaEncryption.
3. Le processus de double chiffrement appliqué au hash dans ce document et dans PEM sont les même

   Les autres parties du type de contenu donnée signée et enveloppée ( certificates, CRLs, algorithm identifiers, etc. ) sont facilement transposables depuis et vers leur composant PEM.

Type de contenu donnée hashé

   Le type de contenu donnée hashée consiste du contenu de n'importe quel type et un hash du contenu. Il est prévu que l'application typique du type de contenu donnée hashée est d'ajouter l'intégrité du contenu d'entrée au type de contenu donnée enveloppée. Le processus par lequel une donnée hashée est construite est constituée des étapes suivantes:

1. Un hash est calculé sur le contenu avec un algorithme de hashage
2. L'algorithme de hashage est le hash sont collecté ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant ce hash avec un hash calculé indépendamment.

Le type de contenu donnée hashée devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version Version,
    digestAlgorithm DigestAlgorithmIdentifier,
    contentInfo ContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
digestAlgorithm Identifie l'algorithme de hashage et ses paramètres associés avec lequel le contenu est hashé.
contentInfo Est le contenu qui est hashé
digest Est le résulta du processus de hashage

   Note: Le fait que le champ digestAlgorithm vient avant le champ contentInfo est le champ digest vient aprés rend possible le traitement d'une valeur DigestedData en une seule passe.

Type de contenu donnée chiffrée

   Le type de contenu donnée chiffrée consiste d'un contenu chiffré de n'importe quel type. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire ni clé de chiffrement de contenu. Les clé sont supposés être gérées par d'autres moyens.

   Il est prévu que l'application typique du type de contenu donnée chiffrée est de chiffrer le contenu du type de contenu donnée pour stochage local, où la clé de chiffrement peut être un mot de passe.

Le type de contenu donnée chiffrée devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version Version,
    encryptedContentInfo EncryptedContentInfo }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
encryptedContentInfo contient les information sur le contenu chiffré

Object Identifiers

   Ce document définis 7 identifiant d'objet: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData.

L'identifiant d'objet pkcs-7 identifie ce document
pkcs-7 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7 }

Les OID data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData, identifient, respectivement, les type de contenu donnée, donnée signée, donnée enveloppée, donnée signée et enveloppée, donnée hashée et donnée chiffrée.
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
    signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
    envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
    signedAndEnvelopedData OBJECT IDENTIFIER ::= { pkcs-7 4 }
    digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
    encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }

   Ces OID sont prévus pour être utilisé dans le champ contentType d'une valeur de type ContentInfo.
^
15 août 2016

htmlpdflatexmanmd




rfc2460

rfc2460

Spécification IPv6

   IPv6 succède à IPv4 et apporte les changements suivant:

Capacités d'adressage étendus IPv6 étend la taille d'adresse de 32 bits à 128 bits, pour supporter un plus grand nombre de nœuds adressables, et une auto-configuration plus simple. Le routage multicast est amélioré en ajoutant un scope aux adresses multicast. Un nouveau type d'adresse appelés adresse anycast est définis, utilisé pour envoyer un paquet à n'importe qui dans un groupe de nœud.
Simplification du format d'en-tête Certains champs IPv4 ont été supprimés, d'autre rendus optionnels, pour réduire le coût de traitement de la manipulation des paquets et pour limiter le coût de la bande passante de l'en-tête IPv6.
Support amélioré pour les extensions et les options Change la manière dont les options de l'en-tête sont encodées pour un forwarding plus efficace et une plus grande flexibilité.
Capacité de labélisation de flux Permet de labéliser les paquets appartenant à un trafic particulier pour lequel l'émetteur demande une manipulation spéciale.
Authentification et confidentialité Les extensions pour supporter l'authentification, l'intégrité des données, et la confidentialité des données.

Terminologie

node Un périphérique qui implémente IPv6
router Un nœud qui transmet les paquets IPv6 qui ne lui sont pas adressés
host Tout nœud qui n'est pas un routeur
upper layer Un protocole de la couche immédiatement au dessus d'IPv6, comme TCP ou UDP.
link Un moyen de communication sur lequel les nœud peuvent communiquer, ex: Ethernet, PPP, X.25, Frame Relay, ou ATM
neighbors Un nœud attaché au même lien
interface L'attachement d'un nœud à un lien
address Un identifiant de la couche IPv6 pour une interface ou un jeu d'interfaces.
packet Un en-tête IPv6 plus le payload
link MTU Maximum Transmission Unit: taille max d'un paquet qui peut être véhiculé sur un lien.
path MTU Le MTU le plus faible de tous les liens dans le chemin entre un nœud source et un nœud de destination.

Format de l'en-tête


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|_Traffic_Class_|___________Flow_Label__________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________Payload_Length________|__Next_Header__|___Hop_Limit___|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+_________________________Source_Address________________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+______________________Destination_Address______________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version 4bits - numéro de version du protocole (6)
Traffic Class 8bits - Champ de classe de trafic
Flow Label 20bits - Label
Payload Length 16bits - Longueur du payload IPv6
Next Header 8bits - Identifie le type d'en-tête qui suit. Utilise les même valeurs que IPv4
Hop Limit 8bits - Décrémenté de 1 par chaque nœud qui forward le paquet.
Source Address 128bits - Adresse de l'émetteur
Destination Address 128bits - Adresse du destinataire

   Dans IPv6, les information optionnelles sont encodées dans des en-tête séparées qui peuvent être placés entre l'en-tête IPv6 et l'en-tête de la couche supérieur. Il peut y avoir 0, 1 ou plusieurs extensions, chacun identifié par le champ next header:

Format de l'en-tête


+---------------+------------------------
|__IPv6_header__|_TCP_header_+_data
|_______________|
|_Next_Header_=_|
|______TCP______|
+---------------+------------------------

+---------------+----------------+------------------------
|__IPv6_header__|_Routing_header_|_TCP_header_+_data
|_______________|________________|
|_Next_Header_=_|__Next_Header_=_|
|____Routing____|______TCP_______|
+---------------+----------------+------------------------

+---------------+----------------+-----------------+-----------------
|__IPv6_header__|_Routing_header_|_Fragment_header_|_fragment_of_TCP
|_______________|________________|_________________|__header_+_data
|_Next_Header_=_|__Next_Header_=_|__Next_Header_=__|
|____Routing____|____Fragment____|_______TCP_______|
+---------------+----------------+-----------------+-----------------

   À une exception, les en-tête d'extension ne sont pas examinés ou traités par les nœuds le long du chemin, jusqu'à ce que le paquet atteigne le nœud identifié dans le champ destination address. Donc, un démultiplexage normal dans le champ next header invoque le module pour traiter la première extension, ou l'en-tête du upper-layer s'il n'y a pas d'extension. Le contenu et les sémantiques de chaque extension détermine si ou non on doit traiter le next header. Cependant, les en-têtes d'extension doivent être traités strictement dans l'ordre auquel ils apparaissent dans le paquet.

   L'extension Hop-by-Hop est une exception, qui gère les informations qui doivent être examinés et traités par tous les nœuds dans le chemin de livraison, incluant les nœuds source et de destination. Cet extension doit suivre immédiatement l'en-tête IPv6. Sa présence est indiquée par la valeur 0 dans le champs next header.

   Si, en résultat du traitement d'un en-tête, un nœud nécessite de traiter le next header mais que la valeur de next header n'est pas reconnue par le nœud, il devrait détruire le paquet et envoyer un message ICMP Parameter Problem à la source du paquet, avec un code ICMP de 1 et un Pointeur ICMP contenant l'offset de la valeur non reconnue dans le paquet. La même action devrait être faite si un nœud rencontre un next header de 0 dans un en-tête autre que l'en-tête IPv6

   Chaque en-tête d'extension est un entier multiple de 8 octets, pour pouvoir maintenir un alignement 8 octets pour les autres en-têtes. Une implémentation complète d'IPv6 inclus l'implémentation des en-tête d'extension suivantes:

Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload

   Les 4 premiers sont spécifiés dans ce document, les 2 derniers sont spécifiés dans la rfc2402 et la rfc2406.

Ordre d'en-tête d'extension

   Quand plus d'un en-tête d'extension sont utilisé dans le même paquet, il est recommandé qu'ils apparaissent dans l'ordre suivant:

IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
upper-layer header

note 1: Pour les options à traiter par la première destination qui apparaît dans le champ Destination Address plus les destinations suivante listée dans l'en-tête Routing.
note 2: Des recommandation additionnelles au regard le l'ordre des en-tête d'authentification et d'encapsulation sont donnés dans la rfc2406.
note 3: Pour les options à traiter seulement par la destination finale du paquet.

   Chaque en-tête d'extension devrait exister un seule fois au plus, excepté pour l'en-tête Destination Options qui devrait exister au plus 2 fois.

   Si l'en-tête upper-layer est un autre en-tête IPv6, il peut seulement être suivant par ses propres extensions, qui sont sujet aux même recommandation d'ordre.

   Si et quand d'autre en-tête d'extension sont définis, leur contrainte d'ordre relative aux en-tête définis plus haut doivent être spécifiés.

Options

2 des en-tête d'extension définis ici -- Hop-by-Hop et Destination Header -- gère un nombre variable d'options type-length-value (TLV) encodés, dont le format est le suivant:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-_-_-_-_-_-_-_-_-
|__Option_Type__|__Opt_Data_Len_|__Option_Data____
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-_-_-_-_-_-_-_-_-

Option Type 8bits - identifiant du type d'option
Opt Data Len 8bits - Longueur du champ Option Data en octets
Option Data Champ de longueur variable.

   La séquence d'options dans un en-tête doit être traité strictement dans l'ordre qu'ils apparaissent dans l'en-tête. Les identifiant d'Option Type sont encodés en interne de manière à ce que leur 2 bit MSB spécifient l'action à effectuer si le nœud le traitant ne reconnaît pas l'Option Type:

00 Passe l'option et continue à traiter l'en-tête
01 Supprime le paquet
10 Détruit le paquet et envoie un ICMP parameter Problem, Code 2.
11 Détruit le paque et envoie un ICMP parameter Problem, Code 2 seulement si de Destination Address n'est pas une adresse multicast.

   Le bit suivant spécifie si l'Option Data de cette option peut changer en cour de route vers la destination finale. Quand un en-tête d'authentification est présent dans le paquet, pour une option dont la donnée peut changer en cour de route, tout son champ Option Data doit être traité comme une série de 0 en calculant ou en vérifiant la valeur d'authentifiant le paquet.

0 Option Data ne change pas en cour de route
1 Option Data peut changer en cour de route

   Les 3 bits MSB décris ci-dessus sont traités comme partie de l'Option Type, et non indépendamment. Le même espace de numérotation d'Option Type est utilisé par Hop-by-Hop et Destination Options. Cependant, la spécification d'une option particulière peut restreindre son utilisation à seulement un de ces en-tête.

   Des options individuelles peuvent avoir des besoin d'alignement spécifiques, pour s'assurer que les valeurs multi-octets dans Option Data conserve les limites naturelles. L'alignement requis d'une option est spécifiée en utilisant la notation xn+y, signifiant que l'Option Type doit apparaître comme un multiple entier de x octets du début de l'en-tête, plus y octets. Par exemple:

2n Signifie un offset 2 octets depuis le début de l'en-tête
8n+2 Signifie un offset 8 octets depuis le début de l'en-tête, plus 2 octets.

   Il y a 2 options de padding qui sont utilisées si nécessaire pour aligner les options suivantes et aligner l'en-tête à un multiple de 8 octets. Ces options de padding doivent être reconnues par toutes les implémentations IPv6:

Pad1 (alignement requis: non)
+-+-+-+-+-+-+-+-+
|_______0_______|
+-+-+-+-+-+-+-+-+

   Note: le format de l'option Pad1 est un cas spéciale, il n'a pas de champs de longueur et valeur. Cette option est utilisée pour insérer un octet de padding dans les options de l'en-tête. Si plus d'un octet de padding sont requis, l'option PadN, ci-dessous, doit être utilisé:

PadN (alignement requis: non)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-_-_-_-_-_-_-_-_-
|_______1_______|__Opt_Data_Len_|__Option_Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-_-_-_-_-_-_-_-_-

   L'option PadN est utilisé pour insérer 2 ou plusieurs octets de padding dans les options de l'en-tête. Pour N octets de padding, le champs Opt Data Len contient la valeur N-2, et l'Option Data consiste de N-2 octets de valeur 0.

Hop-by-Hop

   L'option Hop-by-Hop est utilisé pour gérer les information optionnelles qui doivent être examinés par tous les nœud le long du chemin de livraison du paquet. Cette option est identifiée par la valeur Next Header 0 dans l'en-tête IPv6, et a le format suivant:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|__Hdr_Ext_Len__|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________+
|_______________________________________________________________|
._______________________________________________________________.
.____________________________Options____________________________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8bits - identifie le type d'en-tête immédiatement suivant l'option Hop-by-Hop
Hdr Ext Len 8bits - Longueur de l'option Hop-by-Hop en unité de 8 octets, n'incluant pas les 8 premiers octets.
Options Variable, contient une ou plusieurs options TLV.

Routing

   L'en-tête Routing est utilisé par une source IPv6 pour lister un ou plusieurs nœud intermédiaire à visiter sur le chemin vers la destination du paquet. Cette fonction est très similaire à Loos Source et Record Route d'IPv4. Cet en-tête est identifié par la valeur Next Header de 43 et a le format suivant:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|__Hdr_Ext_Len__|__Routing_Type_|_Segments_Left_|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
._______________________________________________________________.
._______________________type-specific_data______________________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8bits - identifie le type d'en-tête immédiatement suivant l'option Routing
Hdr Ext Len 8bits - Longueur de l'option Routing en unité de 8 octets, n'incluant pas les 8 premiers octets.
Routing Type 8bits - identifant d'une variante d'en-tête Routing particulière
Segments Left 8bits - Nombre de segment de routes restant à visiter
Type-specific data Variable - le format est déterminé par Routing Type.

   Si, en traitant un paquet reçu, un nœud rencontre un en-tête Routing avec un Routing Type inconnu, le comportement dépend de la valeur du champ Segments Left:

   Si Segment Left vaut 0, le nœud doit ignorer l'en-tête Routing et traiter l'en-tête suivant dans le paquet.

   Si Segment Left ne vaut pas 0, le nœud doit détruire le paquet en envoyer un ICMP Parameter Problem, code 0.

   Si, une fois l'en-tête Routing traité un nœud intermédiaire détermine que le paquet doit être forwardé sur un lien dont le link MTU est inférieur à la taille du paquet, le nœud doit détruire le paquet et envoyer un ICMP Packet Too Big.

L'en-tête Routing Type 0 a le format suivant:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|__Hdr_Ext_Len__|_Routing_Type=0|_Segments_Left_|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________________________Reserved___________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+___________________________Address[1]__________________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+___________________________Address[2]__________________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
._______________________________._______________________________.
._______________________________._______________________________.
._______________________________._______________________________.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+___________________________Address[n]__________________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8bits - Identifie le prochain header
Hdr Ext Len 8bits - Longueur de l'en-tête Routing en unité de 8 octets, n'incluant pas les 8 premiers octets
Routing Type 0
Segment Left 8bits - Nombre de segments restant
Reserved 32bits - Initialisé à 0 pour la tranmission; ignorée à la reception
Address[1..n] Vecteur d'adresses 128 bits, numérotées de 1 à n

   Les adresses multicast ne doivent pas apparaître dans l'en-tête Routing de type 0, ou dans le champ Destination Address d'un paquet gérant un en-tête Routing de type 0.

Un en-tête Routing n'est pas examiné ou traité tant qu'il n'atteind pas le nœud identifié dans le champ Destination Address. Dans ce nœud, le module Routing est chargé, et dans le cas du type 0, effectue l'algorithme suivant:
if Segments Left = 0 {
    traite le next header dans le paquet, dont le type est
    identifié par Next Header dans l'en-tête Routing
}
else if Hdr Ext Len is odd {
    Envoie un ICMP Parameter Problem, Code 0 à la source, pointant
    sur le champs Hdr Ext Len, et détruit le paquet
}
else {
    Calcule n, le nombre d'adresses dans l'en-tête Routing, en
    divisant Hdr Ext Len par 2
    
    if Segments Left is greater than n {
        Envoie un ICMP Parameter Problem, Code 0 à la source, pointant
        sur le champ Segments Left, et détruit le paquet
    }
    else {
        décrémente Segments Left de 1;
        Calcule i, l'index de la prochaine adresses à visiter dans
        le vecteur d'adresse, en soustrayant Segment Left de n
    
        if Address [i] or the IPv6 Destination Address is multicast {
            détruit le packet
        }
        else {
            Inverse Destination Address et Address[i]
    
            if the IPv6 Hop Limit is less than or equal to 1 {
                Envoie un ICMP Time Exceeded -- Hop Limit Exceeded
                dans le message Transit à la source et détruit le paquet
            }
            else {
                décrémente Hop Limit de 1
    
                renvoie le paquet au module IPv6 pour le transmettre
                à la nouvelle destination
            }
        }
    }
}

   Considérons le case suivant comme exemple de cet algorithme. Un nœud source S envoie un paquet à destination du nœud D, en utilisant en en-tête Routing pour forcer le paquet à être routé via les nœuds intermédiaire I1, I2 et I3. Les valeurs de l'en-tête IPv6 et des champs d'en-tête Routing sur chaque segment dans le chemin de livraison serait comme suit:

Lorsque le paquet va de S à I1:
Source Address = S    Hdr Ext Len = 6
Destination Address = I1    Segments Left = 3
                Address[1] = I2
                Address[2] = I3
                Address[3] = D

Lorsque le paquet va de I1 à I2:
Source Address = S    Hdr Ext Len = 6
Destination Address = I2    Segments Left = 2
                Address[1] = I1
                Address[2] = I3
                Address[3] = D

Lorsque le paquet va de I2 à I3:
Source Address = S    Hdr Ext Len = 6
Destination Address = I3    Segments Left = 1
                Address[1] = I1
                Address[2] = I2
                Address[3] = D

Lorsque le paquet va de I3 à D:
Source Address = S Hdr Ext Len = 6
Destination Address = D Segments Left = 0
                Address[1] = I1
                Address[2] = I2
                Address[3] = I3

Fragment

   L'en-tête Fragment est utilisé par une source IPv6 pour envoyer un paquet plus grand que dans le path MTU vers sa destination. (À la différence d'IPv4, la fragmentation n'est effectuée que par les nœuds sources). L'en-tête Fragment est identifié par une valeur Next Header de 44 et a le format suivant:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|___Reserved____|______Fragment_Offset____|Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Identification________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8bits - identifie le prochain en-tête
Reserved 8bits - Initialisé à 0 pour la transmission, ignorée à la reception
Fragment Offset 13bits - l'offset, en unités de 8 octet de la donnée suivant cet en-tête, relatif au début de la partie Fragmentable du paquet original
Res 2bits - Initialisé à 0 pour la transmission, ignorée à la reception
M flag 1 = d'autres fragments, 0 = dernier fragment.
Identification 32bits - Voir ci-dessous

   Pour envoyer un paquet qui est trop grand pour le MTU du chemin vers sa destination, un nœud source peut diviser le paquet en fragments et envoyer chaque fragment comme paquet séparé, à réassemble par le destinataire.

   Pour tout paquet qui est fragmenté, le nœud source génère une valeur d'identification. Cette identification doit être différente qui tout autre paquet fragmenté envoyé récemment avec la même adresse source et de destination. Si un en-tête Routing est présent, l'adresse de destination à se préoccuper est celle de la destination finale.

Le paquet initial, non-fragmenté est référé au paquet original, et il consiste de 2 parties:
+------------------+----------------------//-----------------------+
|__Unfragmentable__|_________________Fragmentable__________________|
|_______Part_______|_____________________Part______________________|
+------------------+----------------------//-----------------------+

   La partie non-fragmentable consiste de l'en-tête IPv6 plus les en-tête d'extension qui doivent être traités par les nœuds sur le chemin de la destination.

   La partie fragmentable consiste du reste du paquet, c'est à dire les en-tête d'extension qui doivent être traités seulement par la destination, plus le upper-layer.

   La partie Fragmentable du paque original est divisée en fragments, chacun, possiblement excepté du dernier, devient un entier multiple de 8 octets de long. Les fragments sont transmis dans des paquets fragment séparés:


Paquet_original:
+------------------+--------------+--------------+--//--+----------+
|__Unfragmentable__|____first_____|____second____|______|___last___|
|_______Part_______|___fragment___|___fragment___|_...._|_fragment_|
+------------------+--------------+--------------+--//--+----------+

Paquets_fragment:
+------------------+--------+--------------+
|__Unfragmentable__|Fragment|____first_____|
|_______Part_______|_Header_|___fragment___|
+------------------+--------+--------------+

+------------------+--------+--------------+
|__Unfragmentable__|Fragment|____second____|
|_______Part_______|_Header_|___fragment___|
+------------------+--------+--------------+
______________________o
______________________o
______________________o
+------------------+--------+----------+
|__Unfragmentable__|Fragment|___last___|
|_______Part_______|_Header_|_fragment_|
+------------------+--------+----------+

   Chaque fragment est composé de:

        1- La partie non-fragmentable du paquet original, avec le Payload Length de l'en-tête original changé pour contenir la longueur de ce paquet fragment (excluant la longueur de l'en-tête IPv6), et le champ Next Header de dernier en-tête de la partie non-fragmentée changée à 44.
        2- Un en-tête Fragment contenant:

                - La valeur Next Header qui identifie le premier header de la partie Fragmentable du paquet original
                - Un Fragment Offset contenant l'offset du fragment, en unités de 8 octets, relatif au début de la partie fragmentable du paquet originale. Le Fragment Offset du premier fragment est 0.
                - La valeur du flag M à 0 si le fragment est le dernier, sinon 1
                - La valeur d'identification générée pour le paquet original

        3- Le fragment lui-même

À la destination, les paquets fragment sont réassemblés dans leur version non-fragmenté. Les règles suivantes gouvernent le ré-assemblage.

- Un paquet original est ré-assemblé seulement depuis les paquets fragments qui ont la même adresse source, de destination, et d'identification
- La partie non-fragmentable du paquet ré-assemblé consiste de tous les en-tête jusqu'à, mais n'incluant pas, l'en-tête Fragment du premier paquet fragment (c'est à dire avec Fragment Offset à 0), avec les 2 changements suivants:


        - Le champ Next Header du dernier en-tête de la partie non-fragmentable est obtenu du champ Next Header de l'en-tête Fragment du premier fragment.
        - La longueur du paylod du paquet ré-assemblé est calcudé avec la longueur de la partie non-fragmentable, et la longueur et l'offset du dernier fragment. Par exemple, une formule pour calculer la longueur du payload est:
        PL.orig = PL.first - FL.first - 8 + (8 addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo FO.last) + FL.last où:

                PL.orig= champ Payload Length du paquet réassemblé
                PL.first= champ Payload Length du premier fragment réassemblé
                FL.first= Longueur du fragment suivant l'en-tête Fragment du premier paquet fragment.
                FO.last* Champ Fragment Offset de l'en-tête fragment du dernier paquet fragment
                FL.last= Longueur de fragment suivant l'en-tête fragment du dernier paquet fragment.

- La partie Fragmentable du paquet ré-assemblé est construite depuis les fragments suivant les en-tête fragment dans chaque paquet fragment. La longueur de chaque fragment est calculé en soustrayant du Payload Length du paquet la longueur des en-tête entre l'en-tête IPv6 et le fragment.
- L'en-tête fragment n'est pas présent dans le paquet final ré-assemblé.

   Les erreurs suivant peuvent se produire en réassemblant des paquets fragmentés:

        - Si les fragments reçus sont insuffisant pour réassembler un paquet dans les 60 secondes après la réception du premier fragment de ce paquet, le ré-assemblage du paquet doit être abandonné et tous les paquets fragments détruits. Si le premier fragment (celui avec un Fragment Offset à 0) a été reçu, un ICMP Time Exceeded -- Fragment Reassembly Time Exceeded devrait être envoyé à la source de ce fragment.
        - Si la longueur d'un fragment, comme dérivé du champ Payload Length du paquet fragment, n'est pas un multiple de 8 octets et que le flag M est à 1, alors ce fragment doit être détruit et un message ICMP Parameter Problem, code 0 doit être envoyé à la source, pointant sur le champ Payload Length du paquet fragment.
        - Si la longueur et l'offset d'un fragment sont définis de sorte que le Payload Length du paquet ré-assemblé excède 65535 octets, ce fragment doit être détruit est un ICMP Parameter Problem, code 0 doit être envoyé à la source, pointant sur le champ Fragment Offset du paquet fragment.

   Les conditions suivante ne sont pas sensé se produire, mais ne sont pas considérés comme des erreurs:

        - Le nombre et le contenu des en-tête précédant l'en-tête fragment de différents fragment du même paquet original peut différer. Les en-têtes présent avant l'en-tête fragment dans chaque paquet fragment sont traités quand le paquet arrive, avant la mise en queue des fragment pour ré-assemblage. Seul ces en-tête dans le paquet fragment d'offset 0 sont retenus dans le paquet réassemblé.
        - Les valeurs Next Header dans les en-tête Fragment de différents fragments du même paquet original peuvent différer. Seul la valeur du fragment d'offset 0 est utilisé pour le ré-assemblage.

Destination Options

   L'en-tête Destination Options est utilisé pour gérer des informations optionnelles qui doivent être examinés seulement par le nœud destinataire du paquet. Cet en-tête est identifié par la valeur Next Header 60 et a le format suivant:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|__Hdr_Ext_Len__|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________+
|_______________________________________________________________|
._______________________________________________________________.
.____________________________Options____________________________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__Next_Header__|__Hdr_Ext_Len__|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________+
|_______________________________________________________________|
._______________________________________________________________.
.____________________________Options____________________________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8bits - Identifie le prochain type d'en-tête
Hdr Ext Len 8bits - Longueur de l'en-tête en unité de 8 octets, n'incluant pas les 8 premiers octets
Options Variable

   Les seules options de destination définies dans ce document sont Pad1 et PanN décris plus haut.

   Noter qu'il y a 2 manières possible d'encoder les informations de destination optionnelles dans un paquet IPv6: soit commme option dans l'en-tête Destination Header, ou comme en-tête d'extension séparée. L'en-tête fragment et l'en-tête Authentication sont des examples de cette approche. L'approche utilisée dépend de l'action désirée du nœud destination qui ne comprend pas les information optionnelles:

        - Si l'action désirée est pour que le nœud de destination supprime le paquet et, seulement si l'adresse de destination n'est pas une adresse multicast, envoie un ICMP Unrecognized Type à l'adresse source, alors l'information peut être encodé dans un en-tête séparé ou comme option dans Destination Options dont l'Option Type un MSB à 11.
        - Si une autre action est souhaitée, le informations doivent être encodées comme option dans Destination Options dont Option Type a le MSB à 00, 01, ou 10.

No Next Header

   La valeur 59 dans le champ Next Header indique qu'il n'y pas rien après cet en-tête. Si le champ Payload Length de l'en-tête IPv6 indique la présence d'octets après un en-tête dont le Next Header est à 59, ces octets doivent être ignorés, et passés tel quel si le paquet doit être forwardé.

Problèmes de taille de paquet

   IPv6 nécessite que tout lien dans l'internet ait un MTU de 1280 octets ou supérieur. Dans un lien qui ne peut pas convoyer un paquet 1280 octets en un paquet, une fragmentation et un ré-assemblage doit être fournis au niveau de la couche sous IPv6.

   Les lients qui ont un MTU configurable (par exemple PPP) doivent être configurés pour avoir un MTU d'au moins 1280 octets; Il est recommandé que le MTU soit de 1500 octets ou supérieur, pour gérer les encapsulation (ex: tunneling) sans générer de fragmentation IPv6.

   Sur chaque lien sur lequel un nœud est directement attaché, le nœud doit être capable d'accepter les paquets aussi grand que le MTU du lien

   Il est fortement recommandé que les nœuds IPv6 implémentent Path MTU Discovery (rfc1981), pour pouvoir découvrir les MTU supérieurs à 1280. Cependant, une implémentation minimale d'IPv6 peut simplement restreindre à envoyer des paquets de 1280 octets au plus, et omettre la découverte de MTU.

   POur envoyer un paquet plus grand que le MTU du chemin, un nœud peut utiliser l'en-tête Fragment pour fragmenter le paquet à la source. Cependant, l'utilisation d'une telle fragmentation est découragée dans toute application capable d'ajuster ses paquets à la taille du Path MTU.

   Un nœud doit être capable d'accepter un paquet fragmenté qui, après ré-assemblage, est plus grand que 1500 octets. Un nœud est autorisé à accepter des paquets fragmentés qui ré-assemblent à plus de 1500 octets. Un protocole upper-layer ou une application qui dépend de la fragmentation IPv6 pour envoyer des paquets supérieurs au MTU d'un chemin ne devrait pas envoyer des paquets supérieur à 1500 octets sauf s'il a l'assurance que la destination est capable de ré-assembler les paquets de taille plus grande.

   En réponse à un paquet IPv6 qui est envoyé à une destination IPv4 (ex: un paquet qui est traduit d'IPv6 vers IPv4), l'émetteur IPv6 peut recevoir un ICMP Packet Too Big reportant un Next-Hop MTU inférieur à 1280. Dans ce cas, le nœud IPv6 n'est pas obligé de réduire la taille des paquets sous-jacent à moins de 1280, mais doit inclure un en-tête fragment dans ses paquets pour que le routeur traduisant IPv6 vers IPv4 puisse obtenir une valeur d'identification correcte pour les fragments IPv4. Noter que cela signifie que le payload peut nécessiter d'être réduit à 1232 octets (1280 moins 40 pour l'en-tête IPv6 et 8 pour l'en-tête fragment), et plus petits si d'autres en-têtes sont utilisés.

Flow Labels

   Le champ 20bits Flow Label dans l'en-tête IPv6 peut être utilisé par une source pour labéliser les séquences de paquets pour lesquels il demande une manipulation spéciale par les routeurs IPv6, tel qu'un QOS différent, ou un service temps-réel. Cet aspect d'IPv6 est, au moment de la rédaction, expérimental est sujet à changement. Les hôtes ou routeurs qui ne supportent pas les fonctions de Flow Label, ignorent le champs.

Classes de trafic

   Le champ 8bits Traffic Class dans l'en-tête IPv6 est disponible par les nœuds émetteur et/ou les routeurs pour identifier et distinguer différentes classes ou priorités de paquets IPv6. Au moment de la rédaction de ce document, il y a des expérimentations dans l'utilisation de Type of Service d'IPv4 et/ou les bits Precedence pour fournir diverses formet de services différenciés pour les paquets IP. Le champ Traffic Class dans l'en-tete IPv6 est prévu pour permettre une fonctionnalité similaire dans IPv6.

   Les pré-requis suivants s'appliquent au champ traffic class:

        - L'interface de service IPv6 d'un nœud doit fournir un moyen pour un protocole upper-layer de founir une valeur de Traffic Class. La valeur par défaut doit être 0.
        - Les nœuds qui supportent une utilisation spécifique de certains bits Traffic Class sont autorisés à changer la valeur de ces bits dans les paquets qu'ils émettent, forwardent, ou reçoivent. Les nœud devraient ignorer et laisser les bits de Traffic Class inchangé pour les paquets qui ne supportent aucune utilisation spécifique.
        - Un protocole upper-layer ne doit pas assumer que la valeur des bits Traffic Class dans un paquet reçu soient les même que la valeur envoyée par la source du paquet.

Problématiques des protocole upper-layer

   Tout protocole transport ou upper-layer qui incluent les adresses de l'en-tête IP dans sont checksum doivent être modifiés pour IPv6, pour inclure des adresses IPv6 128bits. En particulier, l'illustration suivante montre le pseudo-header TCP et UDP pour IPv6:


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+_________________________Source_Address________________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+______________________Destination_Address______________________+
|_______________________________________________________________|
+_______________________________________________________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________________Upper-Layer_Packet_Length___________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________zero_____________________|__Next_Header__|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Si le paquet IPv6 contient un en-tête Routing, l'adresse de destination utilisé dans le pseudo-entête est celui de la destination finale. Dans le nœud émetteur, l'adresse sera dans le dernier élément de l'en-tête Routing.
- La valeur Next Header dans le pseudo-entête identifie le protocole upper-layer (ex: 6 pour TCP, 17 pour UDP). Il va différer de la valeur Next Header dans l'en-tête IPv6 s'il y a des en-tête d'extension entre l'en-tête IPv6 et les données.
- À la différence d'IPv4, quand des paquets UDP sont émis par un nœud IPv6, le checksum IDP n'est pas optionnel. C'est à dire, quand un paquet UDP est émis, le nœud IPv6 doit calculer un checksum UDP sur le paquet et le pseudo-header, et, si ce calcul résulte à 0, il doit être changé pour 0xFFFF dans l'en-tête UDP. Les destinataires IPv6 doivent détruire les paquets UDP contenant un checksum 0, et devraient logger l'erreur.

   La version IPv6 d'ICMP inclus le pseudo-header ci-dessus dans son calcul de checksum; c'est un changement par rapport à ICMP d'ipv4. La raison pour ce changement est de protéger ICMP contre les problèmes de livraison ou la corruption des champs d'en-tête d'IPv6 sur lequel il dépend, qui, à la différence d'IPv4, ne sont pas couverts par un checksum de la couche internet. Le champ Next Header dans le pseudo-header pour ICMP contient la valeur 58.

Durée de vie d'un paquet

   À la différence d'IPv4, Les nœuds IPv6 ne sont pas obligés de forcer une durée de vie de paquet maximum. C'est la raison pour laquelle le champ Time-to-Live d'IPv4 a été renommé Hop Limit dans IPv6. Dans la pratique, très peu d'implémentations IPv4 sont conformes à cette durée de vie.

Taille de payload upper-layer maximum

   En calculant la taille du payload maximum disponible pour les données upper-layer, un protocole upper-layer doit prendre en compte la taille de l'en-tête IPv6 relative à l'en-tête IPv4. Par exemple, dans IPv4, l'option MSS de TCP est calculée comme taille de paquet maximum (une valeur par défaut ou une valeur apprise via Path MTU Discovery) moins 40 octets (20 cotets pour IPv4, et 20 octets pour TCP). En utilisant TCP sur IPv6, le MSS doit être calculé comme taille de paquet maximum moins 60 octets, parce que l'en-tête IPv6 minimum (sans extensions) fait 20 octets de plus que IPv4.

Répondre aux paquets avec des en-têtes Routing

   Quand un protocole upper-layer envoie un ou plusieurs paquets en réponse à un paquet reçus qui inclus un en-tête Routing, les réponses ne doivent pas inclure un en-tête Routing qui a été automatiquement dérivé en inversant l'en-tête Routing sauf si l'integrité et l'authenticité de Source Address et de l'en-tête Routing a été vérifiée. En d'autre termes, seul les paquets de types suivants sont autorisés à répondre à un paquet ayant un en-tête routing:

        - Les paquets réponse qui n'ont pas d'en-tête Routing
        - Les paquets réponse qui ont un en-tête Routing qui n'est pas dérivé de l'en-tête Routing du paquet reçu
        - Les paquets réponse qui ont un en-tête Routing dérivé de l'en-tête Routing si et seulement si l'intégrité et l'authenticité de Source Address et de l'en-tête Routing a été vérifié.
^
24 août 2013

htmlpdflatexmanmd




rfc2589

rfc2589

Extensions pour les services d'annuaire dynamiques

   LDAP support les accès aux services d'annuaire statique, permettant d'effectuer des opérations relativement rapide. Les services d'annuaire dynamiques sont différents puisqu'ils stockent des informations qui ont une durée de vie. un cas typique est un client ou une personne qui est soit online, dans ce cas il a une entrée dans l'annuaire, soit offline et dans ce cas l'entrée disparait. Bien que les opérations du protocole et les attributs sont utilisés de la même manière que pour les services d'annuaires statiques, les clients qui stockent ces informations dans l'annuaire doivent périodiquement rafraîchir ces informations. Les entrées qui n'ont pas été rafraîchies après une période données sont supprimés par le serveur. Un mécanisme de contrôle de flux du serveur est aussi décrit et permet au serveur d'informer les clients de la fréquence de rafraîchissement.

Prérequis

   Les extension de protocole doivent permettre d'accéder aux informations dynamiques dans un annuaire de manière standard.

Entrées dynamiques et classes d'objet

   Une entrée dynamique est un objet dans l'annuaire qui a une durée de vie associée avec lui. Cette durée de vie est définie lors de la création de l'objet et quand il expire, l'objet est supprimé. En invoquant l'opération étendue refresh, le TTL est réinitialisé.

Requête de rafraichissement

Cette opération envoyée par un client indique au serveur de conserver l'entrée dynamique et de réinitialiser sa durée de vie. Un client peut demander cette opération en transmettant un PDU contenant un ExtendedRequest:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL
    }

requestName doit être définis à: "1.3.6.1.4.1.1466.101.119.1"
requestValue va contenir le DER du type ASN.1 suivant:


SEQUENCE {
    entryName [0] LDAPDN,
    requestTtl [1] INTEGER
    }

entryName est le nom UTF8 de l'entrée dynamique. Cette entrée doit déjà exister.
requestTtl est le temps en secondes (1 à 31557600) du nouveau TTL à définir.

Réponse au rafraichissement

Si un serveur implémente cette extension, le serveur doit répondre un PDU contenant ExtendedResponse:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
    COMPONENTS OF LDAPResult,
    responseName [10] LDAPOID OPTIONAL,
    response [11] OCTET STRING OPTIONAL
    }

responseName contient la même chaîne que dans la demande. Le champ response va contenir un DER de la sequence ASN.1 suivante:


SEQUENCE {
    responseTtl [1] INTEGER
    }

   Le champ responseTtl est le temps en secondes que le serveur a choisi comme champ ttl pour cette entrée. Il ne doit pas être plus petit que le choix du client, mais il peut être plus grand. Cependant, pour éviter tout abus, les serveurs sont autorisés à raccourcir le TTL d'un client à un minimumde 86400 secondes.

Schéma

dynamicObject Cette classe définis une entrée dynamique
entryTtl Maintient le TTL de l'entrée
dynamicSubtrees dans le rootDSE, maintient les sous-arborescences où sont supportée les entrées dynamiques.


( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'This class, if present in an entry, indicates that this entry has a limited lifetime and may disappear automatically when its time-to-live has reached 0. There are no mandatory attributes of this class, however if the client has not supplied a value for the entryTtl attribute, the server will provide one.'
SUP top AUXILIARY )
    
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'This operational attribute is maintained by the server and appears to be present in every dynamic entry. The attribute is not present when the entry does not contain the dynamicObject object class. The value of this attribute is the time in seconds that the entry will continue to exist before disappearing from the directory. In the absence of intervening refresh operations, the values returned by reading the attribute in two successive searches are guaranteed to be nonincreasing. The smallest permissible value is 0, indicating that the entry may disappear without warning. The attribute is marked NO-USER-MODIFICATION since it may only be changed using the refresh operation.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
NO-USER-MODIFICATION USAGE dSAOperation )
    
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
DESC 'This operational attribute is maintained by the server and is present in the Root DSE, if the server supports the dynamic extensions described in this memo. The attribute contains a list of all the subtrees in this directory for which the server supports the dynamic extensions.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE dSAOperation )

Prérequis client

   Les clients peuvent vérifier si le serveur supporte les extensions dynamiques en vérifiant le champs supportedExtension dans le RootDSE. Les client doivent vérifier le dynamicSubtrees pour vérifier si les extensions dynamiques sont supportée sur une arborescence spécifique.

  Les client ne doivent pas s'attendre à ce qu'une entrée soit présente après que le TTL soit dépassé. Toutefois, les client ne doivent pas assumer que l'objet sera supprimé immédiatement après la durée de vie atteinte.

  le CRP (Client Refresh Period) est définis par le serveur, basé sur le entryTtl. Une fois une opération AddRequest effectuée, le client devrait immédiatement envoyer une opération étendue refresh pour récupérer le CRP dans la responseTtl.

  Les client ne doivent pas demander des refresh sur des entrées qui n'existent pas et devraient toujours être prêt à manipuler des cas d'entrées expirées. Les clients devraient également être préparés à des opération de refresh qui échouent (ex: un proxy down).

Prérequis serveur

   Les serveur sont responsables de la suppression des objets expirés, mais il n'est pas requis qu'ils le fasse immédiatement.
^
25 septembre 2013

htmlpdflatexmanmd




rfc2696

rfc2696

Extension de contrôle pour la manipulation des résultats paginés

   Ce contrôle permet à un client de contrôler la quantité de résultat retourné par le serveur lors d’une opération de recherche. Utile lorsqu’un client a des ressources limitées et peut ne pas être en mesure de traiter le résultat entièrement, ou lorsqu’un client est connecté sur un connection à faible bande passante.

  Ce contrôle est inclus dans les messages searchRequest et searchResultDone.

La structure de ce contrôle est la suivante:
pagedResultsControl ::= SEQUENCE {
    controlType 1.2.840.113556.1.4.319,
    criticality BOOLEAN DEFAULT FALSE,
    controlValue searchControlValue
}

searchControlValue est une chaîne encodée BER de la séquence suivante:
realSearchControlValue ::= SEQUENCE {
    size INTEGER (0..maxInt),
    -- requested page size from client
    -- result set size estimate from server
    cookie OCTET STRING
}

Intéraction client-serveur

   Un client peut spécifier un pagedResultsControl avec la taille de page et un cookie vide. La taille de page peut être supérieur à 0 et inférieur à sizeLimit.

   Si la taille de page est supérieur ou égale à sizeLimit, le serveur devrait ignorer ce contrôle. Si le serveur ne supporte pas ce contrôle le serveur doit retourner une erreur unsupportedCriticalExtension si le client a positionné criticality, sinon le serveur devrait ignorer le contrôle.

   Chaque fois que le serveur retourne un jeu de résultat au client, le serveur inclus le contrôle unsupportedCriticalExtension dans le message searchResultDone. Dans le contrôle retourné, la taille peut être définie à l’estimation du serveur du nombre total d’entrées à retourner. les serveurs qui ne peuvent pas l’estimer devraient retourner 0. Le cookie doit être mis à une valeur vide s’il n’y plus d’entrée à retourner.

   Le client doit considérer le cookie comme opaque et ne s’occupe pas de son contenu. Quand le client veut récupérer plus d’entrées, il doit envoyer une searchRequest avec toutes les valeurs identique à la requête initiale à l’exception du cookie, et optionnellement une taille de page modifiée. le cookie à fournir dans la requête est le dernier cookie reçu.

   Une séquence est abandonnée par une requête qui contient pagedResultsControl de 0 et le dernier cookie retourné par le client. Un client peut utiliser l’opération abandon pour abandonner la recherche, mais ce n’est pas encouragé et peut invalider le cookie du client.

   Si le serveur ne peut pas continuer une opération paginé, il devrait retourner l’erreur appropriée dans une entrée searchResultDone, le client et le serveur devraient considérer le jeu de résultat terminé et non-récupérable.

Exemples

le client envoie une requête avec une résultat paginé à 3:
C: SearchRequest + pagedResultsControl(3,"")
Le serveur répond avec 3 entrées et une indication du nombre total d’entrées (5) dans le résultat et un cookie à utiliser pour la suite
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultDone + pagedResultsControl(5, "opaque")
Le client envoie la même requête en changeant simplement le cookie, demande la page suivante:
C: SearchRequest + PagedResultsControl(3, "opaque")
Le serveur répond avec le 2 dernière entrées en indiquant qu’il n’y a plus d’entrées:
S: SearchResultEntry
S: SearchResultEntry
S: SearchResultDone + pagedResultsControl(5,"")
^
10 novembre 2013

htmlpdflatexmanmd




rfc2798

rfc2798

inetOrgPerson

Attributs

carLicense: licence ou pluque d'enregistrement associée à un individu
( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
    DESC 'vehicle license or registration plate'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

departmentNumber: Code de département (ex: 1234 ou ABC/123)
( 2.16.840.1.113730.3.1.2
    NAME 'departmentNumber'
    DESC 'identifies a department within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

displayName: Identifie un nom à utiliser pour cette entrée
( 2.16.840.1.113730.3.1.241
    NAME 'displayName'
    DESC 'preferred name of a person to be used when displaying entries'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

employeeNumber: Id assigné à une personne.
( 2.16.840.1.113730.3.1.3
    NAME 'employeeNumber'
    DESC 'numerically identifies an employee within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

employeeType: Identifie la relation employeur/employé.
( 2.16.840.1.113730.3.1.4
    NAME 'employeeType'
    DESC 'type of employment for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

jpegPhoto: Photos d'une personne
( 0.9.2342.19200300.100.1.60
    NAME 'jpegPhoto'
    DESC 'a JPEG image'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

preferredLanguage: Langages préféré, parlé ou lu.
( 2.16.840.1.113730.3.1.39
    NAME 'preferredLanguage'
    DESC 'preferred written or spoken language for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

userSMIMECertificate: certificat de la personne
( 2.16.840.1.113730.3.1.40
    NAME 'userSMIMECertificate'
    DESC 'PKCS#7 SignedData used to support S/MIME'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

userPKCS12: PFX qui identifie une personne
( 2.16.840.1.113730.3.1.216
    NAME 'userPKCS12'
    DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

ObjectClass


( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
    SUP organizationalPerson
    STRUCTURAL
    MAY (
    audio $ businessCategory $ carLicense $ departmentNumber $
    displayName $ employeeNumber $ employeeType $ givenName $
    homePhone $ homePostalAddress $ initials $ jpegPhoto $
    labeledURI $ mail $ manager $ mobile $ o $ pager $
    photo $ roomNumber $ secretary $ uid $ userCertificate $
    x500uniqueIdentifier $ preferredLanguage $
    userSMIMECertificate $ userPKCS12
    )
)

^
26 septembre 2013

htmlpdflatexmanmd




rfc2849

rfc2849

LDAP Data Interchange Format

Définition de la syntaxe formelle:
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
ldif-change-record = dn-spec SEP *control changerecord
version-spec = "version:" FILL version-number
version-number = 1*DIGIT ; version-number MUST be "1" for the LDIF format described in this document.
dn-spec = "dn:" (FILL distinguishedName / ":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING ; a distinguished name
base64-distinguishedName = BASE64-UTF8-STRING ; a distinguishedName which has been base64 encoded
rdn = SAFE-STRING a relative distinguished name
base64-rdn = BASE64-UTF8-STRING an rdn which has been base64 encoded
control = "control:" FILL ldap-oid ; controlType
    0*1(1*SPACE ("true" / "false")) ; criticality
    0*1(value-spec) ; controlValue
    SEP
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) An LDAPOID
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
    ":" FILL (BASE64-STRING) /
    "‹" FILL url)
url = ‹a Uniform Resource Locator
AttributeDescription = AttributeType [" ;" options]
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options = option / (option " ;" options)
option = 1*opt-char
attr-type-chars = ALPHA / DIGIT / "-"
opt-char = attr-type-chars
changerecord = "changetype:" FILL
    (change-add / change-delete /
    change-modify / change-moddn)
change-add = "add" SEP 1*attrval-spec
change-delete = "delete" SEP
change-moddn = ("modrdn" / "moddn") SEP
    "newrdn:" ( FILL rdn /
    ":" FILL base64-rdn) SEP
    "deleteoldrdn:" FILL ("0" / "1") SEP
    0*1("newsuperior:"
( FILL distinguishedName /
    ":" FILL base64-distinguishedName) SEP)
change-modify = "modify" SEP *mod-spec
mod-spec = ("add:" / "delete:" / "replace:")
    FILL AttributeDescription SEP
    *attrval-spec
    "-" SEP
SPACE = %x20 ; ASCII SP, space
FILL = *SPACE
SEP = (CR LF / LF)
CR = %x0D ; ASCII CR, carriage return
LF = %x0A ; ASCII LF, line feed
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F ; any value ‹= 127 decimal except NUL, LF, and CR
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
    %x21-39 / %x3B / %x3D-7F
    ; any value ‹= 127 except NUL, LF, CR,
    ; SPACE, colon (":", ASCII 58 decimal)
    ; and less-than ("‹" , ASCII 60 decimal)
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
    UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-CHAR
BASE64-UTF8-STRING = BASE64-STRING ; MUST be the base64 encoding of a UTF8-STRING
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A ; +, /, 0-9, =, A-Z, and a-z
BASE64-STRING = [*(BASE64-CHAR)]

Notes sur la syntaxe LDIF

1 - Pour la version décrite dans ce document, la version est 1.
2 - toute ligne non vide, y compris les commentaires peuvent être coupé en insérant un SEP et un SPACE. Il ne doit pas se produire avant le premier caractère de la ligne.
3 - toute ligne qui commence par '#' est un commentaire et est ignoré.
4 - Tout dn ou rdn qui contient des caractères autre que ceux de SAFE-UTF8-CHAR, ou commençant avec un caractère autre que SAFE-INIT-UTF8-CHAR, doivent être encodé en base64.
5 - Quand une valeur d'attribut vide doit être inclus dans le fichier LDIF, elle doit être représenté comme attributeDescription ":" FILL SEP. 'ex: "seeAlseo:" suivie d'une nouvelle ligne)
6 - Quand une URL est spécifiée dans un attrval-spec, les conventions suivantes s'appliquent:

        -a- Les implémentations devraient supporter le format d'url file://
        -b- les implémentations peuvent supporter d'autre formats d'URL

7 - les DN, DN et valeurs d'attributs de syntaxe DirectoryString doivent être des chaîne UTF8 valides.
8 - Les valeurs ou DN qui se terminent avec SPACE devraient être encodée en base64.
9 - Quand les contrôles sont inclus dans un fichier LDIF, les implémentations peuvent choisir d'ignorer certains d'entre-eux. Si la criticité d'un contrôle est "true", l'implémentation doit soit inclure le contrôle, ou ne pas envoyer l'opération au serveur.
10 - Quand un attrval-spec, DN ou RDN est encodé base64, les règles d'encodage spécifiées en 5 sont utilisée avec les exceptions suivantes:

        -a- Il n'y a pas d'exigence que le flux de sortie soit être représenté en ligne de 76 caractère max
        -b- Les chaînes base64 peuvent contenir des caractères autre que BASE6-CHAR, mais sont ignorés

Exemples

Un simple LDIF avec 2 entrées:
version: 1
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 555 1212
description: A big sailing fan.
    
dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212

Un fichier contenant un entrée avec une valeur coupée:
version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
cn:Barbara Jensen
cn:Barbara J Jensen
cn:Babs Jensen
sn:Jensen
uid:bjensen
telephonenumber:+1 408 555 1212
description:Babs is a big sailing fan, and travels extensively in sea
    rch of perfect sailing conditions.
title:Product Manager, Rod and Reel Division

Un fichier contenant une valeur encodée en base64:
version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
B3V0IG1vcmUu

Un fichier contenant un entrée avec des valeurs d'attribut encodés en UTF8, incluant un tag de langage.
version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=‹JapaneseOU›,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: ‹JapaneseOU›
ou ;lang-ja:: 5Za25qWt6YOo
# ou ;lang-ja:: ‹JapaneseOU›
ou ;lang-ja ;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou ;lang-ja:: ‹JapaneseOU_in_phonetic_representation›
ou ;lang-en: Sales
description: Japanese office
    
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=‹uid›,ou=‹JapaneseOU›,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: rogasawara@airius.co.jp
givenname ;lang-ja:: 44Ot44OJ44OL44O8
# givenname ;lang-ja:: ‹JapaneseGivenname›
sn ;lang-ja:: 5bCP56yg5Y6f
# sn ;lang-ja:: ‹JapaneseSn›
cn ;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn ;lang-ja:: ‹JapaneseCn›
title ;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title ;lang-ja:: ‹JapaneseTitle›
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: ‹JapaneseGivenname›
sn:: 5bCP56yg5Y6f
# sn:: ‹JapaneseSn›
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: ‹JapaneseCn›
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: ‹JapaneseTitle›
givenname ;lang-ja ;phonetic:: 44KN44Gp44Gr44O8
# givenname ;lang-ja ;phonetic::
‹JapaneseGivenname_in_phonetic_representation_kana›
sn ;lang-ja ;phonetic:: 44GK44GM44GV44KP44KJ
# sn ;lang-ja ;phonetic:: ‹JapaneseSn_in_phonetic_representation_kana›
cn ;lang-ja ;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn ;lang-ja ;phonetic:: ‹JapaneseCn_in_phonetic_representation_kana›
title ;lang-ja ;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title ;lang-ja ;phonetic::
# ‹JapaneseTitle_in_phonetic_representation_kana›
givenname ;lang-en: Rodney
sn ;lang-en: Ogasawara
cn ;lang-en: Rodney Ogasawara
title ;lang-en: Sales, Director

Un fichier contenant une référence à un fichier externe
version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Horatio Jensen
    
cn: Horatio N Jensen
sn: Jensen
uid: hjensen
telephonenumber: +1 408 555 1212
jpegphoto:‹ file:///usr/local/directory/photos/hjensen.jpg

Un fichier contenant une série de changements et commentaires:
version: 1
# Ajouter une nouvelle entrée
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Fiona Jensen
sn: Jensen
uid: fiona
telephonenumber: +1 408 555 1212
jpegphoto:‹ file:///usr/local/directory/photos/fiona.jpg
    
# Supprimer une entrée existante
dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
changetype: delete
    
# Modifier le rdn d'une entrée
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: cn=Paula Jensen
deleteoldrdn: 1
    
# Renommer une entrrée et la déplacer
dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: ou=Product Development Accountants
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=com
# Modifier une entrée. Ajouter une valeur, en supprimer une, en remplacer
une et supprimer une valeur spécifique.
dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
changetype: modify
add: postaladdress
postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
-
delete: description
-
replace: telephonenumber
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
-
delete: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 555 9876
-
# autre exemple de modification: vider les valeurs d'un attribut, et
supprimer complètement un attribut
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
changetype: modify
replace: postaladdress
-
delete: description
-

Un fichier LDIF contenant un changement avec un contrôle
version: 1
dn: ou=Product Development, dc=airius, dc=com
control: 1.2.840.113556.1.4.805 true
changetype: delete

^
25 septembre 2013

htmlpdflatexmanmd




rfc2891

rfc2891

Extension de contrôle pour le trie des résultats de recherche coté serveur

   Ces contrôles permettent à un client de spécifier les attributs et règles de correspondance qu'un serveur devrait utiliser pour retourner les résultats. Ces contrôles peuvent être utiles quand un client a des fonctionnalités limitées ou ne peuvent pas trier les résultats, mais nécessite que le résultat soit trié. Les contrôles de trie permettent de retourner un code de résultat pour le trie qui est indépendant du code de résultat retourné.

Requête

controleType vaut "1.2.840.113556.1.4.473"
controlValue vaut:


SortKeyList ::= SEQUENCE OF SEQUENCE
{ attributeType AttributeDescription,
    orderingRule [0] MatchingRuleId OPTIONAL,
    reverseOrder [1] BOOLEAN DEFAULT FALSE }

SortListKey est une séquence ordonnée pour le trie.
MatchingRuleId devrait être un valide pour le type d'attribut auquel il s'applique.

Réponse

Ce contrôle est inclus dans le message searchResultDone.
SortResult ::= SEQUENCE {
    sortResult ENUMERATED {
    success (0), — results are sorted
    operationsError (1), — server internal failure
    timeLimitExceeded (3), — timelimit reached before sorting was completed
    strongAuthRequired (8), — refused to return sorted results via insecure protocol
    adminLimitExceeded (11), — too many matching entries for the server to sort
    noSuchAttribute (16), — unrecognized attribute type in sort key
    inappropriateMatching (18), — unrecognized or inappropriate matching rule in sort key
    insufficientAccessRights (50), — refused to return sorted results to this client
    busy (51), — too busy to process
    unwillingToPerform (53), — unable to sort
    other (80)
},
attributeType [0] AttributeDescription OPTIONAL }

Intéraction Client-Serveur

   sortKeyRequestControl spécifie un ou plusieurs types d'attributs et de règles de correspondance pour les résultats retournés par une recherche.

  Le serveur devrait retourner tous les résultats dans l'ordre spécifié. Si reverseOrder est à TRUE le résultat sera inversé.

  Il y'a 6 scénarios possibles qui peuvent se produire en résultat au contrôle de trie inclue dans la requête:

1- Si le serveur ne supporte pas ce contrôle et que le client met le champs criticality, le serveur doit retourner unavailableCriticalExtension.
2- Si le serveur ne supporte par ce contrôle et que criticality est FALSE, le serveur doit ignorer le contrôle et traiter la requête.
3- Si le serveur supporte ce contrôle mais ne peut pas trier le résultat avec les clés spécifiées et que le champs criticality est mis, le serveur devrait retourner unavailableCriticalExtension
4- Si le serveur supporte ce contrôle mais ne peut pas trier le résultat avec les clés spécifiées et que le champs criticality est FALSE, le serveur devrait retourner tous les résultats non triés. et inclure sortKeyResponseControl dans searchResultDone.
5- Si le serveur supporte ce contrôle et peut trier le résultat en utilisant les clés spécifiées, il devrait inclure le sortKeyResponseControl dans searchResultDone avec sortResult à success.
6- Si la recherche échoue ou qu'il n'y a pas de résultat le serveur devrait omettre le sortKeyResponseControl du searchResultDone.

   Le client est assuré que le résultat est trié uniquement si le code de résultat dans sortKeyResponseControl est à success.

   Si un client demande un trie à un serveur qui chaîne la requête et récupère des entrées depuis plusieurs serveurs, et que criticality est positionné, le serveur doit fusionner le résultat avant de les retourner au client ou doit retourner unwillingToPerform

   Quand sortKeyRequestControl est utilisé avec pagedResultsControl , le serveur devrait envoyer les messages searchResultEntry triés avec les clés appliqués au résultat total, et non sur les pages. sortKeyList doit être présent sur chaque message searchRequest pour le résultat paginé. Il ne doit pas changer entre les searchRequests pour le même résultat.
^
03 novembre 2013

htmlpdflatexmanmd




rfc2985

rfc2985

PKCS#9: Définition des attributs et classes d'objets

objectClass

pkcsEntity general-purpose auxiliary obj for PKCS-related entities
( 1.2.840.113549.1.9.24.1 NAME 'pkcsEntity' SUP top AUXILIARY MAY ( pKCS7PDU & userPKCS12 & pKCS15Token & encryptedPrivateKeyInfo ) )
naturalPerson general-purpose auxiliary obj about human beings
( 1.2.840.113549.1.9.24.2 NAME 'naturalPerson' SUP top AUXILIARY MAY ( emailAddress $ unstructuredName $ unstructuredAddress $ dateOfBirth & placeOfBirth & gender & countryOfCitizenship & countryOfResidence & pseudonym & serialNumber ) )

Attributes

pKCS7PDU
( 1.2.840.113549.1.9.25.5 NAME 'pKCS7PDU' DESC 'PKCS #7 ContentInfo PDU' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
userPKCS12
( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'PKCS #12 PFX PDU for exchange of personal information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
pKCS15Token
( 1.2.840.113549.1.9.25.1 NAME 'pKCS15Token' DESC 'PKCS #15 token PDU' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
encryptedPrivateKeyInfo
( 1.2.840.113549.1.9.25.2 NAME 'encryptedPrivateKeyInfo' DESC 'PKCS #8 encrypted private key info' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
emailAddress
( 1.2.840.113549.1.9.1 NAME 'emailAddress' DESC 'Email address' EQUALITY pkcs9CaseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
unstructuredName
( 1.2.840.113549.1.9.2 NAME 'unstructuredName' DESC 'PKCS #9 unstructured name' EQUALITY pkcs9CaseIgnoreMatch SYNTAX 1.2.840.113549.1.9.26.1 )
unstructuredAddress
( 1.2.840.113549.1.9.8 NAME 'unstructuredAddress' DESC 'PKCS #9 unstructured address' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
dateOfBirth
( 1.3.6.1.5.5.7.9.1 NAME 'dateOfBirth' DESC 'Date of birth' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
placeOfBirth
( 1.3.6.1.5.5.7.9.2 NAME 'placeOfBirth' DESC 'Place of birth' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
gender
( 1.3.6.1.5.5.7.9.3 NAME 'gender' DESC 'Gender' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE )
countryOfCitizenship
( 1.3.6.1.5.5.7.9.4 NAME 'countryOfCitizenship' DESC 'Country of citizenship' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
countryOfResidence
( 1.3.6.1.5.5.7.9.5 NAME 'countryOfResidence' DESC 'Country of residence' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
pseudonym
( 2.5.4.65 NAME 'pseudonym' DESC 'Pseudonym' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
contentType
( 1.2.840.113549.1.9.3 NAME 'contentType' DESC 'PKCS #7 content type attribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )
messageDigest
( 1.2.840.113549.1.9.4 NAME 'messageDigest' DESC 'PKCS #7 mesage digest attribute' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
signingTime
( 1.2.840.113549.1.9.5 NAME 'signingTime' DESC 'PKCS #7 signing time' EQUALITY signingTimeMatch SYNTAX 1.2.840.113549.1.9.26.2 SINGLE-VALUE )
counterSignature
( 1.2.840.113549.1.9.6 NAME 'counterSignature' DESC 'PKCS #7 countersignature' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
challengePassword
( 1.2.840.113549.1.9.7 NAME 'challengePassword' DESC 'Challenge password for certificate revocations' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

Matching Rules

pkcs9CaseIgnoreMatch
( 1.2.840.113549.1.9.27.1 NAME 'pkcs9CaseIgnoreMatch' SYNTAX 1.2.840.113549.1.9.26.1 )
signingTimeMatch
( 1.2.840.113549.1.9.27.3 NAME 'signingTimeMatch' SYNTAX 1.2.840.113549.1.9.26.2 )
^
06 novembre 2013

htmlpdflatexmanmd




rfc3045

rfc3045

Sockage des informations de vendeur dans le root DSE

   Les clients LDAP découvrent des données spécifique au serveur tel que les contrôles et extensions en lisant le root DSE. Il est souhaitable de pouvoir découvrir le vendeur et la version du serveur.

Types d'attributs

vendorName
( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
vendorVersion
( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
^
27 octobre 2013

htmlpdflatexmanmd




rfc3062

rfc3062

Opération Password Modify

   L'intégration de LDAP et des services d'authentification externes a introduit des identités d'authentification non-DN et permis la décentralisation du stockage des mots de passe. Ainsi, les mécanismes de mise à jours de l'annuaire ne peuvent pas être utilisés pour changer les mots de passe.

Requête et réponse

L'opération étendue Password Modify est identifiée par l'OID passwdModifyOID:
passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1
PasswdModifyRequestValue ::= SEQUENCE {
    userIdentity [0] OCTET STRING OPTIONAL
    oldPasswd [1] OCTET STRING OPTIONAL
    newPasswd [2] OCTET STRING OPTIONAL }
PasswdModifyResponseValue ::= SEQUENCE {
    genPasswd [0] OCTET STRING OPTIONAL }

   Une requête est une ExtendedRequest avec le champ requestName contenant le passwdModifyOID et fournis optionnellement un champs requestValue, qui devrait contenir un PasswdModifyRequestValue avec un ou plusieurs champs présents.

Le champ userIdentity, si présent, devrait contenir une chaîne représentant l'utilisateur associé avec la requête. Si ce champs n'est pas présent, la requête agis sur le mot de passe de l'utilisateur associé avec la session LDAP.
Le champ oldPasswd, si présent, devrait contenir le mot de passe courant de l'utilisateur
Le champ newPasswd, si présent, devrait contenir le nouveau mot de passe de l'utilisateur

Prérequis

   Les clients ne devraient pas envoyer de requête sans s'assurer d'une sécurité adéquate. Les serveurs devraient retourner une erreur si la protection n'est pas suffisante.

  Les serveurs devraient indiquer leur support pour cette opération étendu en fournissant PasswdModifyOID dans supportedExtension.

  Si le serveur ne reconnaît pas les champs ou ne supporte pas la combinaison des champs fournis, il ne devrait pas changer le mot de passe.

  Si oldPasswd est présent et que sa valeur ne peut être vérifiée ou est incorrect, le serveur ne devrait pas changer le mot de passe de l'utilisateur.

   Le serveur ne devrait pas générer un mot de passe si le client a fournis un nouveau mot de passe. Si un client ne fournis pas de nouveau mot de passe, le serveur devrait soit générer un mot de passe, ou retourner une erreur.

  Le serveur peut retourner adminLimitExceeded, busy, confidentialityRequirement, operationError, unavailable, unwillingToPerform, ou un autre resultCode s'il n'est pas en mesure de compléter l'opération.

  Les serveurs peuvent implémenter des stratégies administratives pour restreindre cette opération.
^
22 mai 2015

htmlpdflatexmanmd




rfc3088

rfc3088

OpenLDAP Root Service - Service de référencement LDAP expérimental

   Le projet OpenLDAP opère comme service de référencement d'accès aux annuaires LDAP, connu comme le "OpenLDAP Root Service". Le système Automatisé génère des références basée sur les informations d'emplacement de service publiées dans les enregistrement DNS SRV RR. Ce document décris ce service.

   Les annuaires LDAP utilisent un schéma de nommage hiérarchique hérité de X.500. Traditionnellement, les déploiements X.500 ont utilisé un schéma de nommage géo-politique. Cependant, l'infrastructure d'enregistrement et les services de localisation dans beaucoups de portions du nommage hiérarchique sont inadéquates ou non-existants.

   La construction d'un annuaire global nécessite une infrastructure d'enregistrement et un service de localisation robuste. L'utilisation du nommage basé sur le domaine internet permet aux services d'annuaire LDAP de faire un levier vers une infrastructure d'enregistrement DNS des enregistrement de ressource DNS SRV existants pouvant être utilisé pour localiser les services.

   La plupart des implémentations LDAP existantes ne supportent pas la localisation des services d'annuaires en utilisant les DNS SRV RR. Cependant, la plupart des serveurs supportent la génération de références vers des serveurs supérieurs. Ce service fournis un service LDAP root que les serveur peuvent utilisé comme leur service référant supérieur.

   Un client peut également utiliser le service directement pour localiser les services associés avec un DN arbitraire dans la hiérarchie.

   Note: les mécanismes utilisé par le service sont expérimentaux. Les descriptions fournies par ce document ne sont pas définitifs.

Générer des références basées sur les DNS SRV RR

Le service mappe un DN vers un fqdn en utilisant l'algorithme suivant:
domain = null;
foreach RDN left-to-right // [1]
{
    if not multi-valued RDN and RDN.type == domainComponent
    {
        if ( domain == null || domain == "." )
        { // start
            domain = "";
        }
        else
        { // append separator
            domain .= ".";
        }
        if ( RDN.value == "." )
        { // root
            domain = ".";
        }
        else
        { // append domainComponent
            domain .= RDN.value;
        }
        continue;
    }
    domain = null;
}

Exemples

Distinguished Name_________________Domain
----------------------------- ------------
DC=example,DC=net_______________example.net
UID=jdoe,DC=example,DC=net______example.net
DC=.____________________________. [2]
DC=example,DC=net,DC=.__________. [3]
DC=example,DC=.,DC=net__________net [4]
DC=example.net__________________example.net [5]
CN=Jane Doe,O=example,C=US______null
UID=jdoe,DC=example,C=US________null
DC=example,O=example,DC=net_____net
DC=example+O=example,DC=net_____net
DC=example,C=US+DC=net__________null

Notes

0) Une version ultérieur utilisera un mécanisme standardisé
1) Une version ultérieur de ce service peut utiliser un algorithme droit-à-gauche.
2) La rfc2247 ne statut pas sur la manière de mapper le domaine représentant là racine de l'arborescence vers un DN. On suggère que la racine du domaine soit mappé à "DC=." et qu'il soit inversable
3) La rfc2247 statut que le domaine "example.net" devrait être mappé au dn "DC=example,DC=net", et non "DC=example,DC=net,DC=.", ce n'est pas notre intention d'introduire ou supporter un domaine alternatif au mappage de DN.
4) La rfc2247 statut que le domaine "example.net" devrait être mappé au dn "DC=example,DC=net", et non "DC=example,DC=.,DC=net", ce n'est pas notre intention d'introduire ou supporter un domaine alternatif au mappage de DN.
5) La rfc2247 statut que la valeur d'un type d'attribut DC est un composant de domaine. Il ne devrait pas contenir plusieurs composants de domaine multiple. Une version ultérieur de ce service peut mapper ce domaine à null ou être encodé pour retourner un erreur de DN invalide.

   Si le domaine est null ou ".", le service stop tout traitement et retourne noSuchObject. Une version ultérieur de ce service peut annuler le traitement si le domaine résultant est un domaine top-level.

Localiser les services LDAP

   Le service root localise les services associés avec une nom de domaine pleinement qualifié en requêtant le DNS pour les enregistrements de ressoure LDAP SRV. Pour le domaine example.net, le service devrait émettre une demande SRV pour le domaine "_ldap._tcp.example.net". Une requête réussie va retourner un ou plusieurs enregistrements de ressources sous la forme:

  _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.

   Si aucun enregistrement de ressource LDAP SRV n'est retourné ou une erreur DNS se produit, le service annule tout traitement et retourne noSuchObject. Une version ultérieur de ce service gérera mieux les erreurs.

Construire les réferences LDAP

   Pour chaque DNS SRV RR retourné pour le domaine, une URL LDAP est construite. Pour l'enregistrement ci-dessus, l'url serait:

  ldap://ldap.example.net:389/

   Ces URL sont ainsi retournées dans le référant. Les URL sont actuellement retournés dans l'ordre du resolver.

Opérations du protocole

   Cette section décris comment le service effectue des opération LDAP de base. Le service supporte les opérations étendues prévues via certains contrôles.

Opérations de base

   Les opérations de base retournent un résultat référant si le DN cible peut être mappé à un jeu d'URLs LDAP comme décris ci-dessus. Sinon, une réponse noSuchObject ou autre réponse appropriée est retournée.

Opération Bind

   Ce service accepte le bind anonyme. Tous les autres bind retournent un code non 0. En particulier, les clients qui envoient des accréditifs en texte claire vont recevoir un unwillingToPerform avec un texte d'avertissement. Vu que ce service est en lecture seule, l'authentification lDAP v3 n'est pas supportée.

Unbind

   Une fois une demande unbind reçue, le serveur abandonne toutes requêtes faites par le client et déconnecte.

Extended

   Le service ne reconnaît actuellement aucune opération étendue.

Update

   Une version future de ce document peut retourner unwillingToPerform pour toutes les opérations de modification vu que c'est un service non authentifié.

Controle ManageDSAit

Le service supporte le contrôle ManageDSAit. Si les informations de l'emplacement DNS sont disponible pour de DN de base lui-même, le service retourne unwillingToPerform pour les opérations autre que de recherche. Pour les opérations de recherche, une entrée va être retourné si elle est dans le scope et correspond au filtre fournis. Par exemple:
c: searchRequest {
    base="DC=example,DC=net"
    scope=base
    filter=(objectClass=*)
    ManageDSAit
}
    
s: searchEntry {
    dn: DC=example,DC=net
    objectClass: referral
    objectClass: extensibleObject
    dc: example
    ref: ldap://ldap.example.net:389/
    associatedDomain: example.net
}
s: searchResult {
    success
}

Si les informations d'emplacement DNS sont disponible pour la portion DC d'une entrée subordonnée, le service retourne noSuchObject avec le matchedDN à la portion DC de la base pour la recherche et les opérations de mise à jours:
c: searchRequest {
    base="CN=subordinate,DC=example,DC=net"
    scope=base
    filter=(objectClass=*)
    ManageDSAit
}
    
s: searchResult {
    noSuchObject
    matchedDN="DC=example,DC=net"
}

Utiliser le service

   Les serveurs peuvent être configurés pour référer les requêtes à ‹ldap://root.openldap.org:389›. Bien que les clients peuvent utiliser le service directement, Ce n'est pas encouragé. Les clients devraient utiliser un service local et utiliser ce service seulement quand il est référencé. Le service supporte LDAPv3 et LDAPv2+ sur TCP/IPv4. Une version future de ce document supportera TCP/IPv6 ou d'autres protocoles de transport/internet.

Disponibilité

   Ce service fonctionne actuellement sur un seul hôte. Cet hôte et les ressources réseaux associées ne sont pas exhaustives. On peut facilement augmenter la disponibilité à la demande. Le service peut également être facilement dupliqué localement.

Interopérabilité du protocole

   Le serveur implémente toutes les fonctionnalités LDAPv3 nécessaire au service. LDAPv2 de supporte pas les referral et donc ne peut pas être utilisé par ce service. LDAPv2+ fournis des extensions à LDAPv2, incluant les référants. Une future version de ce document supprimera le support le LDAPv2+.

Considérations de sécurité

   Ce service fournis des informations aux clients anonymes. Cette information est dérivée des annuaires publiques, appelés DNS.

   L'utilisation de l'authentification nécessiterait aux clients de divulguer des informations au service. Cela serait une invasion non-nécessaire.

   Le manque de chiffrement permet l'écoute des demandes et réponses. Une version ultérieur de ce service pourrait supporter le chiffrement.

   La protection de l'intégrité des informations n'est pas fournie par le service. Le service est sujet à diverses formes d'attaques DNS. Une version ultérieur de ce document peut supporter DNSSEC et fournir une protection d'intégrité.

   Le service est sujet à diverses attaque DOS. Une version ultérieur de ce document nécessiterait une meilleur protection pour de tels attaques.
^
27 octobre 2013

htmlpdflatexmanmd




rfc3112

rfc3112

Schéma de mot de passe d'authentification

   L'attribut userPassword est conçu pour utiliser l'opération simple bind password. Cependant les valeurs de userPassword doivent être des mots de passe en texte clair. L'attribut authPassword est conçus pour stocker des informations utilisées pour implémenter une authentification par mot de passe simple. L'attribut supporte plusieurs schéma de stockage. Une règle de correspondance est fournie pour l'utilisation avec des filtres de recherche qui permettent aux clients d'affirmer qu'un mot de passe matche une des valeurs de l'attribut.

Définition du schéma


( 1.3.6.1.4.1.4203.1.1.2 DESC 'authentication password syntax' )

Les valeurs de cette syntaxe sont encodées en accord avec:
authPasswordValue = w scheme s authInfo s authValue w
scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F ; 0-9, A-Z, "-", ".", "/", or "_"
authInfo = schemeSpecificValue
authValue = schemeSpecificValue
schemeSpecificValue = *( %x21-23 / %x25-7E ) ; printable ASCII less "$" and " "
s = w SEP w
w = *SP
SEP = %x24 ; "$"
SP = %x20 ; " " (space)

   où scheme décrit le mécanisme et authInfo et authValue sont spécifique au schéma. authInfo est souvent un salt encodé en base64. authValue est souvent un dérivé de mot de passe encodé en base 64.

authPasswordExactMatch Règle de correspondance qui permet à un client d'affirmer une valeur authPasswordSyntax (règle d'égalité)
authPasswordMatch Règle de correspondance qui permet à un client d'affirmer qu'un mot depasse match un authPasswordSyntax en utilisant un filtre extensibleMatch.
supportedAuthPasswordSchemes Les valeurs de cet attribut sont des noms de schéma de mot de passe supportés par le serveur
authPassword Les valeurs de cet attribut représentent les mots de passe de l'utilisateur
authPasswordObject Les entrées de cet classe d'objet peuvent contenir un attribut authPassword

authPasswordExactMatch
( 1.3.6.1.4.1.4203.1.2.2
    NAME 'authPasswordExactMatch'
    DESC 'authentication password exact matching rule'
    SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

authPasswordMatch
( 1.3.6.1.4.1.4203.1.2.3
    NAME 'authPasswordMatch'
    DESC 'authentication password matching rule'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

supportedAuthPasswordSchemes
( 1.3.6.1.4.1.4203.1.3.3
    NAME 'supportedAuthPasswordSchemes'
    DESC 'supported password storage schemes'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
    USAGE dSAOperation )

authPassword
( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword'
    DESC 'password authentication information'
    EQUALITY 1.3.6.1.4.1.4203.1.2.2
    SYNTAX 1.3.6.1.4.1.4203.1.1.2 )

authPasswordObject
( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject'
    DESC 'authentication password mix in class'
    MAY 'authPassword'
    AUXILIARY )

schéma MD5

   authValue est le MD5 digest encodé base64 de la concaténation du mot de passe et du salt. L'encodage base 64 est fournis dans authInfo. Le salt doit faire 64 bits minimum.

schéma SHA1

   authValue est le digest SHA1 encodé base64 de la concaténation du mot de passe et du salt. L'encodage base 64 est fournis dans authInfo Le salt doit faire 64 bits minimum.

Problèmes d'implèmentation

   Les serveurs peuvent restreindre le schéma utilisé en conjonction avec un processus d'authentification particulier. Les serveurs peuvent utiliser d'autres mécanismes de stockage, tel que userPassword ou un stockage externe, en conjonction avec authPassword.

   Les serveurs qui supportent le simple bind doivent supporter SHA1 et devraient supporter MD5.

   Les serveurs ne devraient pas publier ou initier des opérations sur les valeurs de authPassword ni permettre des opérations qui exposent authPassword ou les assertions authPasswordMatch à moins qu'une protection de confidentialité soit en place.

   Les serveur ne devraient pas assumer qu'un AuthPasswordMatch réussi, soit par compare ou par search, est suffisant pour avoir accès à l'annuaire. L'opération bind doit être utilisé pour authentifier l'annuaire.
^
07 juillet 2016

htmlpdflatexmanmd




rfc3161

rfc3161, rfc5816

PKIX Time-Stamp Protocol

   Un service d'horodatage supporte la preuve qu'une donnée existait à une date donnée. Un TSA peut être opéré par un Tiers de confiance (TTP - Trusted Third Party), bien que d'autres modèles opérationels peuvent être appropriés, par ex, une organisation peut exiger un TSA pour de l'horodatage interne.

   Les services de non-répudiation exigent la capacité d'établir l'existence d'une donnée avant une date spécifiée. Ce protocole peut être utilisé comme bloque de construction de tels services.

   Pour associer une donnée avec un point dans le temps, une autorité d'horodatage (TSA) peut être utilisé. Ce tiers de confiance fournis une preuve d'existence pour cette donnée particulière à une point dans le temps.

   Le rôle du TSA est de dater une donnée pour établir l'évidence indiquant qu'une donnée existait avant une date particulière. Cela peut être utilisé, par exemple, pour vérifier qu'une signature numérique a été appliquée à un message avant que le certificat correspondant n'ait été révoqué, permettant à une clé publique révoquée d'être utilisé pour vérifier la signature créé avant la date de révocation. C'est une opération PKI importante. Le TSA peut également être utilisé pour indiquer la date d'émission quand une deadline est critique, ou pour indiquer la date de transaction pour les entrées dans un log.

Le TSA

   Le TSA est un TTP qui créé des jetons d'horodatage pour indiquer qu'une donnée a existé à un point dans le temps particulier. Pour le reste du document, une "requête valide" signifie une requête que peut être décodée correctement.

Pre-requis du TSA

   Le TSA doit:

- Utiliser une source de temps fiable pour chaque jeton d'horodatage
- Inclure une date fiable pour chaque jeton d'horodatage
- Inclure un entier unique pour chaque jeton d'horodatage généré
- produire un jeton d'horodatage une fois reçu une requête valide, si possible
- Inclure dans chaque jeton d'horodatage un identifiant pour indiquer de manière unique la stratégie de sécurité sous laquelle le jeton a été créé.
- horodater seulement une représentation hashée des données
- examiner l'OID d'une fonction de hash résistante aux collisions et vérifier que la longueur du hash est consistante avec l'algorithme
- Ne pas example l'empreinte à horodater de toute autre manière
- Ne pas inclure d'identification de l'identité demandeur dans les jetons d'horodatage
- Signer chaque jeton d'horodatage en utilisant une clé générée exclusivement dans ce but et avoir cette propriété de clé indiquée dans le certificat correspondant.
- Inclure les informations additionnelles dans le jeton d'horodatage, si demandé en utilisant le champs extensions, seulement pour les extensions qui sont supportés par le TSA. Si ce n'est pas possible, le TSA doit répondre avec un message d'erreur.

Transactions TSA

   Comme premier message de ce mécanisme, l'entité demande un jeton d'horodatage via une requête (qui est ou inclus un TimeStampReq) au TSA. Comme second message, le TSA répond en envoyant une réponse (qui est ou inclus un TimeStampResp) à l'entité.

   Une fois reçu la réponse ( qui est ou inclus un TimeStampResp qui contient normalement un TimeStampToken (TST) ), l'entité doit vérifier le status retourné dans la réponse et en l'absence d'erreur il doit vérifier les divers champs contenus dans le TimeStampToken et la validité de la signature numérique du TimeStampToken. En particulier, il doit vérifier que l'horodatage correspond à ce qui était demandé. Le demandeur doit vérifier que le TimeStampToken contient l'identifiant de certificat correcte du TSA, l'empreinte des données correcte, et l'OID de l'algorithme de hashage correcte. Il doit ensuite vérifier le délai de la réponse en vérifiant soit la date incluse dans la réponse avec une source de temp locale fiable de référence, si disponible, ou la valeur du nonce (un grand nombre aléatoire avec une grande probabilité qu'il a été généré par le client seulement une seule fois) inclus dans la réponse avec la valeur inclus dans la demande. Si une de ces vérification échoue, le TimeStampToken doit être rejeté.

   Ensuite, le certificat du TSA peut avoir été révoqué, le status du certificat doivrait être vérifié pour s'assurer que le certificat est valide.

   Ensuite, l'application cliente devrait vérifie le champ policy pour déterminer si la stratégie sous laquelle le jeton a été émis est acceptable pour l'application.

Identification du TSA

   Le TSA doit signer chaque message avec une clé réservée spécifiquement dans ce but. Un TSA peut avoir des clé privées distincts, par ex, pour gérer différentes stratégie, différents algorithmes, différentes tailles de clé ou pour augmenter les performances. Le certificat correspondant doit contenir seulement une instance du champ d'utilisation de clé avec KeyPurposeIP ayant la valeur: id-kp-timeStamping. Cette extension doit être critique.

L'identifiant d'objet suivant identifie le KeyPurposeIP ayant la valeur id-kp-timeStamping
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
        identified-organization(3) dod(6)
        internet(1) security(5) mechanisms(5) pkix(7)
        kp (3) timestamping (8)}

Format des requêtes

Une requête time-stamping est comme suit:
TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --Un OID d'algorithme de hash et la valeur du hash des donnée à horodater
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }

   Le champ version (actuellement v1) décris la version de la demande d'horodatage.

Le champ messageImprint devrait contenir le hash des données à horodater. Le hash est représenté comme chaîne d'octets. Sa longueur doit correspondre à la longueur de la valeur du hash pour cet algorithme. (20 octets pour SHA1, 16 pour MD5).
MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }

   L'algorithme de hashage indiqué dans le champ hashAlgoritm devrait être un algorithme de hashage connu. Cela signifie qu'il doit être one-way et résistant aux collisions. Le TSA devrait vérifier si l'algorithme de hashage donné est connu pour être suffisant. Si le TSA ne reconnait pas l'algorithme de hashe ou sait qu'il est faible, le TSA devrait refuser de fournir le jeton d'horodatage en retournant un pkiStatusInfo de 'bad_alg'.

   Le champ reqPolicy, si inclus, indique la stratégie TSA sous laquelle le TimeStampTocke devrait être fournis. TSAPolicyId est définis comme suit: TSAPolicyId ::= OBJECT IDENTIFIER

   Le nonce, si inclus, permet au client de vérifier la date de la réponse quand aucune horloge locale n'est disponible. Le nonce est un grand nombre aléatoire avec une forte probabilité que le client l'a généré seulement une seule fois. Dans ce cas la même valeur nonce doit être incluse dans la réponse, sinon la réponse doit être rejetée.

   Si le champ certReq est présent et à true, le certificat du TSA qui est référencé par l'identifiant ESSCertID dans un attribut SigningCertificate ou ESSCertIDv2 dans la réponse doit être fournie par le TSA dans le champ certificates de la structure SignedData dans cette réponse. Ce champ peut également contenir d'autres certificats.

   Si le champ certReq est manquant ou s'est est présent est à false, le champ certificates ne doit pas être présent dans la réponse.

   Le champ extensions est un manière générique d'ajouter des informations additionnelles aux requêtes dans le future. Les extensions sont définies dans la rfc2459. Si une extension, qu'elle soit marquée critique ou non, est utilisée par un demandeur mais non reconnue par le TSA, le serveur ne doit pas émettre de jeton et doit retourner une erreur (unacceptedExtension)

   La requête d'horodatage ne doit pas identifier le demandeur, vu que cette information n'est pas validée par le TSA. Dans les situations où le TSA exige l'identité du demandeur, une identification/authentification alternative doit être mise en place.

Format de réponse

Une réponse d'horodatage est comme suit:
TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }

Le status est basé sur la définition des status dans la rfc2510 comme suit:
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }

Quand le status contient la valeur 0 ou 1, un TimeStampToken doit être présent. Quand le status contient une autre valeur, un TimeStampToken ne doit pas être présent. Une des valeurs suivantes doit être contenus dans le status:
PKIStatus ::= INTEGER {
    granted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4), // indique une révocation imminente
    revocationNotification (5) // indique une révocation

   Les serveurs conformes ne doivent pas produire d'autres valeur. Les clients conforme doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

Quand le TimeStampToken n'est pas présent, failInfo indique la raison du rejet de le requête et peut être une des valeurs suivantes:
PKIFailureInfo ::= BIT STRING {
    badAlg (0), -- identifiant d'algorithme non supporté ou inconnu
    badRequest (2), -- transaction non permise ou non supportée
    badDataFormat (5), -- Mauvais format de données transmises
    timeNotAvailable (14), -- Source de temps du TSA non disponible
    unacceptedPolicy (15), -- La stratégie TSA demandée n'est pas supportée par le TSA
    unacceptedExtension (16), -- extension non supportée par le TSA
    addInfoNotAvailable (17), -- Les informations additionnelles demandées ne sont pas comprises ou non disponible
    systemFailure (25) -- La requête ne peut pas être gérée à cause d'une erreur système
}

   Ce sont les seules valeurs de PKIFailureInfo qui doivent être supportées.

   Les serveurs conformes ne doivent pas produire d'autres valeurs. Les clients conformes doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

   Le champ statusString de PKIStatusInfo peut être utilisé pour inclure un texte de raison.

Un TimeStampToken est comme suit. Il est définis comme ContentInfo et doit encapsuler un type de contenu de données signée.
TimeStampToken ::= ContentInfo
    -- contentType is id-signedData ([CMS])
    -- content is SignedData ([CMS])

   Les champs de type EncapsulatedContentInfo de la construction SignedData ont la signification suivante:

eContentType est un identifiant d'objet qui spécifie uniquement le type de contenu. Pour un jeton d'horodatage il est définis comme suit:
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

   eContent est le contenu, un chaîne d'octet, un TSTInfo encodé DER.

Le jeton d'horodatage ne doit pas contenir de signature autre que la signature du TSA. L'identifiant de certificat (ESSCertID ou ESSCertIDv2) du certificat TSA doit être inclus comme attribut signerInfo dans l'attribut SigningCertificate.
TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- doit avoir la même valeur que le champ similaire dans TimeStampReq
    serialNumber INTEGER,
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- Doit être présent si le champ similaire est présent dans TimeStampReq, et doit avoir la même valeur
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

   Le champ version (v1) décris la version du jeton d'horodatage. Les serveurs conformes doivent être capable de fournir des jetons version 1.

   Parmis les champs optionnels, seul nonce doit être supporté. Les demandeurs conforme doivent être capable de reconnaitre les jeton d'horodatage version 1 avec tous les champs optionnels présents, mais ne sont pas obligés de comprendre les sémantiques des extensions. si présent.

   Le champ policy doit indiquer la stratégie TSA sous laquelle la réponse a été produite. Si un champ similaire est présent dans TimeStampReq, il doit avoir la même valeur, sinon une erreur unacceptedPolicy doit être retournée. Cett stratégie peut inclure les types d'information suivantes (bien que cette liste n'est certainement pas exhaustive):

- Les condition sous lesquels le jeton peut être uilisé
- La disponibilité de log de jeton d'horodatage, pour permettre une vérification ultérieur de l'authenticité du jeton.

   Le messageImprint doit avoir la même valeur que le champ similaire dans le TimeStampReq, indiquant que la taille de la valeur du hash matche la taille attendue de l'algorithme de hashage identifié dans hashAlgorithm.

   Le champ serialNumber est un entier assigné par le TSA pour chaque TimeStampTocken. Il doit être unique pour chaque TimeStampToken émis par un TSA donné.

   genTime est la date à laquelle le jeton a été créé par le TSA. Il est exprimé en temp UTC pour réduire la confusion avec le timezone local. UTC est une échelle de temp, basée sur le secon (SI), comme définis et recommandé par le CCIR, et maintenu par le Bureau International des Poids et Mesures (BIPM). Un synonime est le temp "Zulu" qui est utilisé par l'aviation civile et représentée par la lettre Z.

accuracy représent la déviation de temp autour du temps UTC contenus dans GeneralizedTime.
Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

   Si un des éléments est manquant, la valeur est considéré comme 0. En ajoutant la valeur accuracy dans le GeneralizedTime, une limite supérieur du temp auquel le jeton d'horodatage a été créé par la TSA peut être obteni. De la même manière, en soustrayant l'accuracy au GeneralizedTime, une limite inférieur du temp auquel le jeton a été créé par le TSA peut être obtenu.

   Si le champ ordering est manquant, ou s'il est présent et mis à false, le champ genTime indique seulement le temp auquel le jeton a été créé par le TSA. Dans un tel cas, l'ordre des jetons d'horodatage émis par le même TSA ou différents TSA est seulement possible quand la différence entre le genTime du premier jeton et le genTime du second jeton est supérieur à la somme des accuracy du genTime pour chaque jeton.

   Si le champ ordering est présent et à true, tout jeton du même TSA peut toujours être ordonné basé sur le champ genTime, sans regarder l'accuracy GenTime.

   Le champ nonce doit être présent s'il est présent dans le TimeStampReq. Dans ce cas, il doit être recopié dans la structure TimeStampReq.

   Le but du champ tsa est de donner une indication pour identifier le nom du TSA. Si présent, il doit correspondre à un des nom de sujet inclus dans le certificat qui est utilisé pour vérifier le jeton. Cependant, l'identification de l'entité qui a signé la réponse se produit toujours via l'utilisation de l'identifiant de certificat (ESSCertID) dans l'attribut SigningCertificate ou ESSCertIDv2 dans l'attribut SigningCertificateV2 qui fait partie du signerInfo.

   Les extensions sont une manière générique d'ajouter des informations additionnelles dans le future.

Transports

   Il n'y a pas de mécanisme de transport obligatoire pour les messages TSA dans ce document. Les mécanismes décris ci-dessous sont optionnels, d'autres mécanisme pouvant être définis dans le future.

E-mail

Cette section spécifie un moyen de transporter des messages encodés ASN.1 pour l'échange de protocole via les mails. 2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

Content-Type: application/timestamp-reply
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

   Ces objets MIME peuvent être respectivement envoyés et reçus en utilisant les moteurs de traitement MIME qui fournissent un simple transport par mail des messages d'horodatage.

Pour les types MIME application/timestamp-query et application/timestamp-reply, les implémentations devraient inclure les paramètres optionnels "name" et "filename". Inclure un nom de fichier aide à préserver le type d'information quand les requêtes et réponses d'horodatage sont sauvées en tant que fichier. Quand ces paramètres sont inclus, un nom de fihier avec l'extension approprié devrait être sélectionné:
______MIME Type_____________________File Extension
application/timestamp-query____________.TSQ
application/timestamp-reply____________.TSR

Fichier

   Un fichier contenant un message timestamp doit contenir seulement l'encodé DER d'un message TSA. De tels fichiers peuvent être utilisé pour transporter les messages timestamp en utiisant ftp par exemple.

   Une requête timestamp devrait être contenue dans un fichier avec l'extension .tsq, et une réponse devrait être contenue dans un fichier avec l'extension .tsr

Socket

   Le protocole suivant basé sur TCP est utilisé pour transporter les messages TSA. Ce protocole est utilisable pour les cas où une entité initie une transaction et peut demander un résultat. Le protocole assume qu'un processus d'écoute dans un TSA peut accepter les messages TSA sur un port définis (318).

   Généralement un initiateur lie ce port et envoie le message TSA initiale. Le répondeur répond avec un message TSA et/ou avec un numéro de référence à utiliser ultérieurement pour demander la réponse.

   L'initiateur d'une transaction envoie un "direct TCP-based TSA message" au destinataire. Le destinataire répond avec un message similaire. Un "direct TCP-based TSA message" consiste de: length (32-bits), flag (8-bits), value (defined below)

Le champ longueur contient le nombre d'octets du reste du message. Toutse les valeurs 32bits dans ce protocole sont spécifiés pour être dans l'ordre d'octet réseaux
Message name flag value
tsaMsg '00'H DER-encoded TSA message -- message TSA
pollRep '01'H polling reference (32 bits),
                    time-to-check-back (32 bits)
                    -- Réponse quand aucun message TSA n'est prête. Utilise la valeur polling reference (et la valeur de date estimée) pour la demande ultérieur.
pollReq '02'H polling reference (32 bits)
                    -- demande d'une réponse TSA pour le message initial
negPollRep '03'H '00'H
                     pas d'autre réponses ultérieur (ex: transaction complète)
partialMsgRep '04'H next polling reference (32 bits),
                    time-to-check-back (32 bits),
                    DER-encoded TSA message
                    -- réponse partielle du message initial plus une nouvelle référence d'attente à utilise pour obtenir la prochaine partie de la réponse
finalMsgRep '05'H DER-encoded TSA message
                    -- réponse finale du message initial
errorMsgRep '06'H human readable error message
                    -- produit quand une erreur est détectée

   La séquence des messages qui se produit est:

a) L'entité envoie tsaMsg et reçoit un pollRep, negPollRep, partialMsgRep, ou finalMsgRep dans la réponse.
b) L'entité envoie un message pollReq et reçois negPollRep, partialMsgRep, finalMsgRep, ou errorMsgRep dans la réponse

HTTP

2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query
    
    ‹‹the ASN.1 DER-encoded Time-Stamp Request message››
    
Content-Type: application/timestamp-reply
    
    ‹‹the ASN.1 DER-encoded Time-Stamp Response message››

   Ces 2 objets MIME peuvent être envoyés et reçus en utilisant un moteur de traitement HTTP sur des liens WWW et fournis un transport simple via navigateur internet. Une fois un requête valide reçue, le serveur doit répondre avec soit une réponse valide avec le type application/timestamp-response, ou avec une erreur HTTP.

Considérations de sécurité

   Tout le document est concerné par les considérations de sécurité. En concevant un service TSA, les considérations suivantes ont été identifiées comme ayant un impacte sur la validité ou la confiance dans le jeton d'horodatage.

   1. Quand un TSA ne doit plus être utilisé, mais la clé privée TSA n'a pas été compromise, le certificat de l'autorité doit être révoqué. Quand l'extension reasonCode relatif au certificat révoqué du TSA est présent dans les extensions d'entrée de CRL, il doit être mis soit à unspecified, affiliationChanged, superseded ou cessationOfOperation. Dans ce cas, les jetons signés avec la clé correspondante seront considérés comme invalides, mais les jetons générés avant la date de révocation resteront valides. Quand l'extension reasonCode n'est pas présent dans la CRL, tous les jetons qui ont été signés avec la clé correspondante doivent être considérés comme invalides. Pour cette raison, il est recommandé d'utiliser l'extension reasonCode.

   2. Quand la clé privée TSA a été compromise, le certificat correspondant doit être révoqué. Dans ce cas, l'extension reasonCode peut être présent et dans ce cas doit être à keyCompromise. Tout jeton signé par le TSA utilisant cette clé privée ne peuvent plus être validés. Pour cette raison, il est impératif que la clé privée du TSA soit conservé en lieu sûr et contrôlé pour minimiser la possibilité d'être compromise. Dans le cas où la clé privée est compromise, un audit de tous les jetons générés par le TSA peut fournir un moyen de discriminer les jetons. 2 jetons d'horodatage de 2 TSA différents est une autre manière d'adresser ce problème.

   3. La clé de signature TSA doit être suffisamment longue pour une durée de vie confortable. Même si c'est le cas, la clé a une durée de vie définie. Donc, tout jeton signé par le TSA devrait être horodatées de nouveau (si des copies authentique des anciennes CRL sont disponibles) ou notarisé (s'il elle ne le sont pas) à une date ultérieur pour renouveler la confiance qui existe dans la signature du TSA. Les jetons d'horodatage peuvent également être conservés avec un "Evidence Recording Authority" pour maintenir ce trust.

   4. Une application client utilisant seulement un nonce et sans horloge locale devrait être concerné par la quantité de temp qu'il est prêt à attendre la réponse. Une attaque MITM peut introduire un délai. Donc, un TimeStampResp qui prend trop de temp devrait être considéré comme suspect. Vu que chaque méthode de transport spécifié dans ce document a différentes caractéristiques de délai, la durée considérée acceptable dépend du transport utilisé, ainsi que les facteurs environnementaux.

   5. Si différentes entités obtiennent des jetons d'horodatage sur le même objet en utilisant le même algorithme de hashage, ou une simple entité obtient plusieurs jetons sur le même objet, les jetons générés incluent le même message; en résultat, un observateur avec accès à ces jetons peut en déduire que l'horodatage réfère aux même données.

   6. Le replays délibérés ou par inadvertance pour les demandes incorporant le même algorithme de hashage et de valeur peut se produire. Les replays par inadvertance se produisent quand plus d'une copie de la même requête est envoyée au TSA à cause de problèmes réseau. Les replays délibérés se produisent via MITM. Pour détecter ces situations, de nombreuses techniques peuvent être utilisé. Utiliser un nonce permet toujours de détecter les replay, et est recommandé. Il est également possible d'utiliser une horloge local, et une fenêtre de temps durant laquelle le demandeur mémorise tous les hash envoyés . En reçevant une réponse, le demandeur s'assure que l'heure de la réponse est dans la fenêtre et qu'il y a une seule occurence de la valeur de hash dans cette fenêtre de temps.

APPENDIX A - attributs Time-stamp utilisant CMS

   Une des utilisations majeur de l'horodatage est d'horodater une signature pour prouver qu'une signature numérique a été créée avant une date donnée. Le certificat correspondant est révoqué, cela permet à un vérificateur de savoir si la signature a été créé avant ou après la date de révocation.

   Un endroit sensible où stocker un timestamp est dans une structure CMS comme un attribut non-signé. Cette appendice définis un attribut Signature Time-stamp qui peut être utilisé pour horodater une signature numérique.

Les identifiant d'objets suivants identifient cet attribut:
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

La valeur de cet attribut a le type ASN.1 SignatureTimeStampToken:
SignatureTimeStampToken ::= TimeStampToken

   La valeur du champ messageImprint dans TimeStampToken doit être un hash de la aleur du champ signature dans SignerInfo pour le signedData à horodater.

APPENDIX 1 - Placer une signature à un point dans le temps

   On présent un exemple d'une utilisation possible de ce service d'horodatage généraliste. Il place une signature à un point dans le temps, depuis lequel les informations de status du certificat appropri(ex, CRL) doit être vérifié. Cette application est prévue pour être utilisée en conjonction avec des preuves générées en utilisant un mécanisme de signature numérique.

   Les signature peuvent seulement être vérifiées en accord avec une stratégie de non-répudiation. Cette stratégie peut être implicite ou explicite (ex, indiquée dans la preuve fournie par le signataire). La stratégie de non-répudiation peut spécifier, entre-autre, la période permise par un signataire pour déclarer la compromission d'un clé de signature utilisée pour la génération des signatures numérique. Donc une signature ne peut pas garantir d'être valide jusqu'à la fin de cette période.

   Pour vérifier une signature numérique, la technique basique suivante peut être utilisée:

A) Les informations d'horodatage doivent être obtenus juste après la production de la signature

        1) La signature est présentée au TSA. Le TSA retourne un TimeStampToken (TST).
        2) Le demandeur du service doit vérifier que le TimeStampToken est correct.

B) La validité de la signature numérique peut ainsi être vérifiée de la manière suivante:

        1) Le jeton d'horodatage lui-même doit être vérifié et qu'il s'applique à la signature du signataire
        2) La date indiquée par le TSA dans le TimeStampToken doit être retrouvée.
        3) Le certificat utilisé par le signataire doit être identifié et récupéré
        4) La date indiquée par le TSA doit être dans la période de validité du certificat du signataire
        5) Les informations de révocation sur ce certificat, à la date de l'opération d'horodatage, doit être récupéré
        6) Si le certificat est révoqué, la date de révocation doit être ultérieur à la date indiquée par le TSA.

   Si toutes ces conditions sont réussies, la signature numérique doit être déclarée comme valide.

APPENDIX C - Module ASN.1 utilisant la syntaxe 1988


PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
    
DEFINITIONS IMPLICIT TAGS ::=
    
BEGIN
    
-- EXPORTS ALL --
    
IMPORTS
Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} ;
    
-- Locally defined OIDs --
    
-- eContentType for a time-stamp token
    
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
    
-- 2.4.1
    
TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --a hash algorithm OID and the hash value of the data to be time-stamped
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }
    
MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }
    
TSAPolicyId ::= OBJECT IDENTIFIER
    
-- 2.4.2
    
TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }
    
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }
    
PKIStatus ::= INTEGER {
    granted (0),
        -- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present.
    grantedWithMods (1),
        -- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present.
    rejection (2),
    waiting (3),
    revocationWarning (4),
        -- this message contains a warning that a revocation is imminent
        revocationNotification (5)
-- notification that a revocation has occurred }
    
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badRequest (2),
    badDataFormat (5),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17)
    systemFailure (25)
    
TimeStampToken ::= ContentInfo
    
TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- MUST have the same value as the similar field in TimeStampReq
    serialNumber INTEGER,
        -- Time-Stamping users MUST be ready to accommodate integers up to 160 bits.
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- MUST be present if the similar field was present in TimeStampReq. In that case it MUST have the same value.
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

END
^
06 novembre 2013

htmlpdflatexmanmd




rfc3296

rfc3296

Named Subordinate References

objectClass

   Détail les éléments du schéma et du protocole pour représenter et gérer les références subordonnées nommées dans LDAP. un objet référant maintient une ou plusieurs URI contenus dans des valeurs de type d'attributs de référence et sont utilisé pour générer des références. Un contrôle, ManageDsaIT, est définis pour permettre de manipuler ces référants et autres objets spéciaux comme des objets spéciaux.

ObjectClass referral

Cette classe d'objet devrait être utilisé en conjonction avec la classe d'objet extensibleObject pour supporter les attributs de nommage utilisé dans le DN de l'entrée. Les objets référrant sont normalement instanciés aux DSE immédiatement subordonnés au entrées dans un contexte de nommage maintenu par le DSA.
( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'named subordinate reference object' STRUCTURAL MUST ref )

Type d'attribut ref

Ce type d'attribut a une syntaxe directoryString sensible à la casse et multi-valué. Les valeurs placées dans cet attribut doivent être conforme à la spécification donnée pour l'attribut labeledURI. Si cet attribut réfère à un serveur LDAP, il doit être sous la forme d'URL LDAP. Cette URL LDAP ne devrait pas contenir de scope, filtre, liste d'attribut, ou extension et devrait contenir un DN on-vide.
( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'named reference - a labeledURI' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE distributedOperation )

Contrôle ManageDsaIT

   Un client peut fournir le contrôle ManageDsaIT avec une opération pour indiquer que l'opération est de gérer des objets dans le DIT. Ce contrôle indique que les entrée spécifique sont traitées comme des entrées normales.

  Le controlType vaut 2.16.840.1.113730.3.4.2 et controlValue est absent.

Références des subordonnés nommés

   Une référence subordonnée nommée est construite en instançiant un objet referral dans le serveur dé-référençant avec les les valeurs de l'attribut ref. qui pointent vers le subtree correspondant maintenu dans le serveur référencié. En général, le nom de l'objet referral est le même que l'objet référencé et cet objet référencé est un préfixe de contexte.

   Si le serveur A maintient DC=example,dc=net et le serveur B maintient dc=sub,dc=example,dc=net, le serveur A peut contenir un objet referral nommé dc=sub,dc=example,dc=net qui contient un attribut ref avec la valeur ldap ://B/dc=sub,dc=example,dc=net


dn: DC=sub,DC=example,DC=net
dc: sub
ref: ldap://B/DC=sub,DC=example,DC=net
objectClass: referral
objectClass: extensibleObject

   Typiquement, le DN de l'objet referral et le DN de l'objet sur le serveur référencé sont les même. Si l'attribut ref a plusieurs valeurs, tous les DN contenus dans les URL LDAP devraient être équivalent. Les administrateurs devraient éviter de configurer des boucles en utilisant des référants. Les références nommées doivent être traitées comme des entrées normales si la requête inclus le contrôle manageDsaIT.

scénario

   Les sections suivante contiennent des spécifications sur l'utilisation des referral dans différent scénarios. Il est à noter que, dans ce document, une opération de recherche est conceptuellement divisée en 2 phases distincts : 1. trouver l'objet de base où la recherche commence, et 2. effectuer la recherche.

Exemple de configuration

Par exemple, supposons que le serveur contacté (hosta) maintient l'entrée O=MNN,C=WW" et l'entrée "CN=manager,O=MNN,C=WW" et les objets referral suivants:
dn: OU=People,O=MNN,C=WW
ou: People
ref: ldap://hostb/OU=People,O=MNN,C=US
ref: ldap://hostc/OU=People,O=MNN,C=US
objectClass: referral
objectClass: extensibleObject

dn: OU=Roles,O=MNN,C=WW
ou: Roles
ref: ldap://hostd/OU=Roles,O=MNN,C=WW
objectClass: referral
objectClass: extensibleObject

   Le premier referral indique que hostb et hostc maintiennent "OU=People,O=MNN,C=WW". Le second indique que hostd maintient "OU=Roles,O=MNN,C=WW".

Considérations de l'objet cible

   Cette section détail la manipulation des referral pour les opérations add, compare, delete, modify et modrdn. Si le client demande une de ces opérations, il y'a 4 cas que le serveur doit gérer.

   cas 1: l'objet cible n'est pas manipulé parle serveur et n'est pas dans ou subordonné à un contexte de nommage ni subordonné à un referral maintenu par le serveur.

   Le serveur devrait traiter la requête normallement comme approprié pour une base non-exsitante qui n'est pas dans un contexte de nommage du serveur. (retourne générallement noSuchObject ou un referral).

   cas 2: L'objet cible est maintenu par le serveur et est un objet referral.

   Le serveur devrait retourner l'URI contenu dans ref, modifié comme suit.

exemple: Si le client requête une opération modify pour l'objet cible "OU=People,O=MNN,C=WW", le serveur va retourner:
ModifyResponse (referral) {
    ldap ://hostb/OU=People,O=MNN,C=WW
    ldap ://hostc/OU=People,O=MNN,C=WW
}

   cas 3: L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral.

   Si le contexte de nommage le plus proche ne contient pas de referral auquel l'objet cible est subordonné, le serveur devrait traiter la requête de manière appropriée (généralement retourne noSuchObject)

   cas 4: L'objet cible n'est pas maintenu par le serveur, mais le contexte de nommage le plusproche contient un referral.

   Si le client demande une opération pour laquelle l'objet cible n'est pas maintenu par le serveur et que le contexte de nommage le plus proche contient un referral, le serveur devrait retourner une réponse referral contruite avec la portion URI de la valeur ref.

exemple: Si le client fournir une opération add où l'objet cible a un DN de "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
AddResponse (referral) {
    ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
}

Considérations de l'objet de base

   Cette section détail la manipulation des referral pour le traitement de l'objet de base dans les opérations de recherche, il y'a 4 cas.

   Dans les cas où l'URI retourné est une URL LDAP, le serveur doit fournir un scope explicite avant de le retourner. En plus, la partie DN doit être modifiée de sorte qu'il réfère à la cible appropriée dans le serveur référencé.

   Si le dé-référencement d'alias est nécessaire pour trouver l'objet referral, la partie DN de l'URI doit être remplacée avec le DN de base comme modifié par le dé-référencement d'alias de sorte que l'URL réfère au nouvel objet cible.

   cas 1: L'objet de base n'est pas maintenu par le serveur et n'est pas dans ou subordonné à un contexte de nommage maintenu par le serveur.

   Le serveur devrait traiter la requête normalement comme approprié pour une base non-existante qui n'est pas dans un contexte de nommage du serveur (généralement retourne un referral supérieur ou noSuchObject).

   cas 2: L'objet de base est maintenu par le serveur et est un objet referral.

   Le serveur devrait retourner la valeur URI contenu dans ref, modifié comme indiqué plus haut.

exemple: Si le client requête un recherche subtree avec l'objet de base "OU=Roles,O=MNN,C=WW", le serveur va retourner:
SearchResultDone (referral) {
    ldap ://hostd/OU=Roles,O=MNN,C=WW??sub
}

   cas 3: L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche ne contient pas de referral dont l'objet de base est subordonné. Le serveur devrait retourner noSuchObject

   cas 4: L'objet de base n'est pas maintenu par le serveur, mais le contexte de nommage le plus proche contient un objet referral dont l'objet de base est subordonné. Le serveur devrait retourner une réponse referral qui est construite depuis la portion URI de ref.

exemple: Si le client requête un search sur la base "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner:
SearchResultDone (referral) {
    ldap ://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
}

Considérations de continuation de recherche

   Pour les opérations de recherche, une fois l'objet de base trouvé et qu'il n'est pas un objet referral, la recherche peut progresser.

   exemple: Si un client requête un search subtree de "O=MNN,C=WW", en plus de toute entrée dans le scope dont le filtre match, hosta va aussi retourner 2 références de recherche en tant que 2 objets referral dans le scope. Une réponse possible peut être :

SearchEntry for O=MNN,C=WW
SearchResultReference {
    ldap://hostb/OU=People,O=MNN,C=WW??sub
    ldap://hostc/OU=People,O=MNN,C=WW??sub
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
    ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
SearchResultDone (success)

exemple avec one level: Si le client effectue la recherche de scope OneLevel, une réponse possible peut être:
SearchResultReference {
    ldap://hostb/OU=People,O=MNN,C=WW??base
    ldap://hostc/OU=People,O=MNN,C=WW??base
}
SearchEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
    ldap://hostd/OU=Roles,O=MNN,C=WW??base
}
SearchResultDone (success)

BindRequest

   Les serveurs ne devraient pas retourner de resultCode referral si un nom bind (ou aun authentication identity ou une authorization identity) est ou est subordonné à un objet referral mais peut utiliser les informations connues pour traiter la requête bind. Si le serveur n'utilise par ces informations, il doit traiter la requête normallement (retourner un invalidCredentials)

Modify DN

   Si le newSuperior est un objet referral ou est subordonné à un objet referral, le serveur devrait retourner un affectsMultipleDSAs. si le newRDN existe déjà mais est un objet referral, le serveur devrait retourner affectsMultipleDSAs au lieu de entryAlreadyExists.
^
14 août 2016

htmlpdflatexmanmd




rfc3315

rfc3315

DHCPv6

   Ce document décrit DHCP pour IPv6, un protocole client/serveur qui fournis une configuration gérée de périphériques.

   DHCP peut fournir un périphérique avec des adresses assignées par un serveur DHCP et des informations de configuration, qui sont gérés dans des options. DHCP peut être étendu via la définition de nouvelles options pour gérer les informations de configuration non spécifiées dans ce document.

   DHCP est un protocole d'auto-configuration d'adresse à état et let protocole d'auto-configuration à été référré dans la rfc4862.

   Les modèles opérationnels et les informations de configuration pour DHCPv4 et DHCPv6 sont suffisamment différents pour que l'intégration entre les 2 services ne soient pas inclus dans ce document.

Protocoles et adressage

   Les clients et les serveurs échangent des messages DHCP en utilisant UDP. Le client utilise une adresse de lien-local ou les adresses déterminées via d'autres mécanismes pour transmettre et reçevoir les messages DHCP.

   Les serveurs DHCP reçoivent des messages des clients en utilisant une adresse multicast link-scoped. Un client DHCP transmet la plupart des messages à cette adresse multicast réservée, donc ce client n'a pas besoin d'être configuré avec l'adresse des servers DHCP.

   Pour autoriser un client DHCP à envoyer un message à un serveur DHCP qui n'est pas attaché au même lien, un relasi DHCP sur le lien du client va relayer les messages.

   Une fois que le client a déterminé l'adresse d'un serveur, il peut envoyer les messages directement au serveur en utilisant l'unicast.

Les échanges client-serveur impliquant 2 messages

   Quand un client DHCP n'a pas besoin qu'un serveur DHCP lui assigne ses adresses IP, le client peut obtenir des informations de configuration tel qu'une liste de serveurs DNS ou NTP disponibles via un simple échange de message avec le serveur DHCP. Pour obtenir des informations de configuration le client envoie d'abord un message Information-Request à l'adresse multicast All_DHCP_Relay_Agents_and_Servers. Les serveurs répondent avec un message Reply contenant la configuration pour le client.

   Cet échange assume que le client ne demande que des informations de configuration et non d'adresses IPv6.

   Quand un serveur a des adresses IPv6 et d'autres informations de configuration envoyés à un client, le client et le serveur sont capable d'échanger en utilisant seulement 2 messages, au lieu de 4 comme décris dans la section suivante. Dans ce cas, le client envoie un message Solicit à All_DHCP_Relay_Agents_and_Servers demandant l'assignement des adresses et autres informations de configuration. Ce message inclus une indication que le client accepte un message de réponse immédiat du serveur. Le serveur qui est prêt à envoyer l'assignement d'adresses au client répond immédiatement. Les informations de configuration et les adresses dans la réponse sont ainsi immédiatement disponibles au client.

   Chaque adresse assignée au clien a une durée de vie préféré et valide spécifié par le serveur. Pour demander une extension de durée, le client envoie un message Renew au serveur. Le serveur envoye un Reply au client avec la nouvelle durée de vie.

Les échanges client-serveur impliquant 4 messages

   Pour demander l'assignement d'une ou plusieurs adresses IPv6, un client localise d'abord un serveur DHCP, puis lui demande l'assignement des adresses et autres informations de configuration. Le client envoie un message Solicit à l'adresse All_DHCP_Relay_Agents_and_Servers pour trouver les serveurs DHCP disponibles. Tout serveur qui répond aux exigences du client répondent avec un message Advertise. Le client choisis ensuite un des serveurs et envoie un message Request au serveur demandant la confirmation de l'assignement. Le serveur répond avec un message Reply qui contient les adresses confirmées et la configuration.

Terminologie DHCP

Approprié au lien Une adresse est approprié au lien quand l'adresse est consistante avec la connaissance du serveur DHCP de la topologie réseau, de l'assignement de préfixe et des stratégies d'assignement d'adresse.
binding Un binding est un groupe d'enregistrement de données serveur contenant les informations du serveur sur les adresses dans un IA ou les informations de configuration explicites assignées au client. Ces informations de configuration qui sont retournées au client via une stratégie ne nécessitent pas de liaison. Une liaison contenant des informations sur un IA est indexé par le triplet ‹DUID,IA-type, IAID›
Paramètre de configuration Un élément du jeu d'informations de configuration dans le serveur et délivré au client en utilisant DHCP.
DHCP domain Un jeu de liens gérés par DHCP et opéré par une simple entité administrative
DHCP realm Un nom utilisé pour identifier le domain administratif DHCP pour lequel une clé d'authentification DHCP a été sélectionnée
DUID Un DHCP Unique IDentifier pour un participant DHCP. Chaque client et serveur DHCP a exactement un DUID.
Identity Association (IA) Une collection d'adresses assignées à un client. Chaque IA a un IAID associé. Un client peut avoir plus d'un IA assigné; par exemple, une pour chacune de ses interfaces.
Identity association identifier (IAID) Un identifiant pour un IA choisis par le client. Chaque IA a un IAID unique.
Identity association for non-temporary addresses (IA_NA) Un IA qui gère les adresses assignée qui ne sont pas des adresses temporaire
Identity association for temporary addresses (IA_TA) Un IA qui gères les adresses temporaires
Reconfigure key Une clé fournie à un client par un serveur utilisé pour fournir une sécurité pour les messages Reconfigure
transaction ID Une valeur opaque utilisée pour correspondre aux réponses avec les réponses initiées soit par un client soit par un serveur

Adresses Multicast

   DHCP utilise les adresses multicast suivantes:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2) Une adresse multicast utilisée par un client pour communiquer avec les serveurs et agents relais du voisinage
All_DHCP_Servers (FF05::1:3) Une adresse multicast utilisée par un agent relais pour communiquer avec les serveurs, soit pour envoyer des messages à tous les serveurs, soit parce qu'il ne connaît pas les adresses unicast des serveurs.

Ports UDP

   Les clients écoutent les messages UDP sur le port 546. Les serveurs et agents relais écoutent sur le port UDP 547.

Types de messages DHCP

   DHCP définis les types de messages suivants:

SOLICIT(1) Un client envoie un message Solicit pour localiser les serveurs
ADVERTISE(2) Un serveur envoie un message Advertise pour indiquer qu'il est disponible pour les services DHCP, en réponse à un message Solicit.
REQUEST(3) Un client envoie un message Request pour demander des paramètres de configuration, incluant des adresses IP, à un serveur spécifique.
CONFIRM(4) Un client envoie un message Confirm aux serveurs disponible pour déterminer si les adresse qui lui ont été assignées sont appropriées au lien sur lequel le client est connecté.
RENEW(5) Un client envoie un message Renew au serveur qui lui a fournis les adresses et paramètres de configuration pour renouveler son bail et mettre à jours d'autres paramètres de configuration.
REBIND(6) Un client envoie un message Rebind aux serveurs DHCP pour étendre la durée de vie des adresses assignées et mettre à jours d'autres paramètres de configuration. Ce message est envoyé quand un client n'a pas reçu de réponse à un message Renew
REPLY(7) Un serveur envoie un message Reply contenant les adresses assignée et les paramètres de configuration en réponse à un message du client.
RELEASE(8) Un client envoie un message Release au serveur pour pour indiquer que le client n'utilise plus une ou plusieurs adresses assignées.
DECLINE(9) Un client envoie un message Decline au serveur pour indiquer qu'une ou plusieurs adresse assignée sont déjà utilisées sur le lien.
RECONFIGURE(10) Un serveur envoie un message Reconfigure à un client pour informer le client que le serveur a de nouveaux paramètres de configuration, ou une mises à jours de ceux-ci, et que le client doit initier un Renew/Reply, ou Information-request/Reply.
INFORMATION-REQUEST(11) Un client envoie un message Information-request à un serveur pour demander les paramètres de configuration sans l'assignement d'adresses IP au client.
RELAY-FORW(12) Un agent relay envoie un message Relay-forward pour relayer les messages au serveurs. Le message reçu est encapsulé dans une option dans le messages Relay-forward
RELAY-REPL(13) Un serveur envoie un message Relay-reply pour relayer les messages à un client. Le messages client est encapsulé dans une option dans le message Relay-reply.

Codes de status

   DHCPv6 utilise des codes de status pour communiquer le résultat des opérations demandées, et pour fournir des informations additionnelles sur la cause spécifique de l'erreur d'un message.

Paramètres de transmission et retransmission

Cette table de valeur est utilisée pour décrire le comportement de transmission de message des clients et serveurs:
Parameter_____Default_____Description
-------------------------------------
SOL_MAX_DELAY_____1 sec___Max delay of first Solicit
SOL_TIMEOUT_______1 sec___Initial Solicit timeout
SOL_MAX_RT______120 secs__Max Solicit timeout value
REQ_TIMEOUT_______1 sec___Initial Request timeout
REQ_MAX_RT_______30 secs__Max Request timeout value
REQ_MAX_RC_______10 ______Max Request retry attempts
CNF_MAX_DELAY_____1 sec___Max delay of first Confirm
CNF_TIMEOUT_______1 sec___Initial Confirm timeout
CNF_MAX_RT________4 secs__Max Confirm timeout
CNF_MAX_RD_______10 secs__Max Confirm duration
REN_TIMEOUT______10 secs__Initial Renew timeout
REN_MAX_RT______600 secs__Max Renew timeout value
REB_TIMEOUT______10 secs__Initial Rebind timeout
REB_MAX_RT______600 secs__Max Rebind timeout value
INF_MAX_DELAY_____1 sec___Max delay of first Information-request
INF_TIMEOUT_______1 sec___Initial Information-request timeout
INF_MAX_RT______120 secs__Max Information-request timeout value
REL_TIMEOUT_______1 sec___Initial Release timeout
REL_MAX_RC________5 ______MAX Release attempts
DEC_TIMEOUT_______1 sec___Initial Decline timeout
DEC_MAX_RC________5 ______Max Decline attempts
REC_TIMEOUT_______2 secs__Initial Reconfigure timeout
REC_MAX_RC________8 ______Max Reconfigure attempts
HOP_COUNT_LIMIT__32 ______Max hop count in a Relay-forward message

Représentation des valeurs de temps et Infinity

   Toutes les valeurs de temp pour les durées de vie, T1 et T2 sont des entiers non-signés. La valeur 0xffffffff signifie infinis.

Formats de message client/serveur

   Tous les messages DHCP envoyés entre clients et serveurs partagent un format d'en-tête identique et une zone variable pour les options.

Les options sont stockées en série dans le champ options, sans padding entre les options. Les options sont alignées à l'octet.
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____msg-type___|_______________transaction-id__________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
.____________________________options____________________________.
.___________________________(variable)__________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type Identifie le type de message DHCP
transaction-id L'id de transaction pour cet échange
options Les options dans ce message

Formats de message serveur/agent relais

Les agents relais échangent des messages avec les serveurs pour rejouer les messages entre les clients et les serveurs qui ne sont pas connectés sur le même lien.
_0___________________1___________________2___________________3
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____msg-type___|___hop-count___|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________|
|_______________________________________________________________|
|_________________________link-address__________________________|
|_______________________________________________________________|
|_______________________________+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|_______________________________|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________|
|_______________________________________________________________|
|_________________________peer-address__________________________|
|_______________________________________________________________|
|_______________________________+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|_______________________________|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________|
._______________________________________________________________.
.____________options_(variable_number_and_length)___....________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message Relay-forward

msg-type RELAY-FORW
hop-count nombre d'agents relais qui ont relayé ce message
link-address Une adresse globale ou site-local qui sera utilisé par le serveur pour identifier le lien sur lequel le client est localisé
peer-address L'adresse du client ou de l'agent relais depuis lequel le message à relayé a été reçu
options Doit inclure l'option "Relay Message option", et peut inclure d'autres options ajoutées par l'agent relais.

Message Relay-reply

msg-type RELAY-REPL
hop-count Copié depuis le message Relay-forward
link-adress Copié depuis le message Relay-forward
peer-address Copié depuis le message Relay-forward
options Doit inclure l'option "Relay Message option"

Représentation et utilisation des noms de domaine

   Un nom de domaine ou une liste de noms de domaine est encodé en utilisant la technique décrite dans la section 3.1 de la rfc1035. Un nom de domaine ne doit pas être stocké sous la forme compressée dans DHCP.

DHCP Unique IDentifier

   Chaque client et serveur DHCP a un DUID. Les serveurs DHCP utilisent les DUID pour identifier les clients pour la sélection des paramètres et dans l'association des IA avec les client. Les clients DHCP utilisent les DUID pour identifier un serveur dans les messages où un serveur doit être identifié.

   Les clients et serveurs doivent traiter les DUID comme valeurs opaques et doivent seulement comparer les DUID. Les clients et serveurs ne doivent pas interpréter les DUID d'une autre manière. Les clients et serveurs ne doivent pas restreindre les DUID aux types définis dans ce document, vu que d'autres types de DUID peuvent être définis dans le future.

   Le DUID est géré dans une option parce qu'il peut être de longueur variable et parce qu'il n'est pas requis dans tous les messages DHCP. Le DUID est conçus pour être unique entre tous les clients/serveurs, et stable pour un client ou un serveur, et ne devrait pas changer dans le temps si c'est possible.

   La motivation pour avoir plus d'un type de DUID est que le DUID doit être globalement unique, et doit également être facile à générer. Le trie de l'identifiant globalement unique qui est simple à générer pour un périphérique qui peut différer. Également, certains périphériques peuvent ne pas contenir de stockage persistant, et retenir un DUID généré n'est pas possible, donc le schéma DUID doit s'adapter à de tels périphériques.

Contenu du DUID

   Un DUID consiste d'un code de type à 2 octets, suivis par un nombre variable d'octets. Un DUID ne peut pas dépasser 128 octets de long. Les types suivants sont actuellement définis:

1 Adresse de lien réseau + une date
2 ID unique assigné par le vendeur basé sur le numéro d'entreprise
3 Adresse de lien réseau

DUID type 1 (DUID-LLT)

Ce type de DUID consiste d'un champ type à 2 octets contenant la valeur 1, un code de type hardware à 2 octets, 4 octets contenant une date, suivas par l'adresse de lien-réseaux d'une des interfaces connectée au périphérique DHCP au moment de la génération du DUID. La date est l'heure de génération du DUID, représenté en secondes depuis minuit (UTC), 1er Janvier 2000, modulo 2^32. Le type hardware doit être un type hardware valide assigné par l'IANA comme décris dans la rfc826.
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________1_______________|____hardware_type_(16_bits)____|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|________________________time_(32_bits)_________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
._______________________________________________________________.
._____________link-layer_address_(variable_length)______________.
._______________________________________________________________.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Le choix de l'interface réseau peut être complètement arbitraire, tant que l'interface fournis une adresse de lien réseau unique pour le type de lien, et le même DUID-LLT devrait être utilisé en configurant toutes les interfaces réseau connectées au périphérique, sans regarder quelle interface de lien réseau a été utilisée pour générer le DUID-LLT

   Les clients et serveurs utilisant ce type de DUID doivent stocker le DUID-LLT dans un stockage stable, et doivent continuer à utiliser le DUID-LLT même si l'interface réseau utilisée pour génerer le DUID-LLT est supprimée. Les clients et serveurs qui n'ont pas de stockage stable ne doivent pas utiliser ce type de DUID.

   Les clients et serveurs qui utilisent ce DUID devraient tenter de configurer le temps avant de génerer le DUID, si possible, et doivent utiliser une sources de temps (par exemple, RTC) en générant le DUID, même si cette source de temp ne peut pas être configurée avant de générer le DUID. L'utilisation d'une source de temps rend peu probable que 2 DUID-LLT identiques soient générés si l'interface réseau est supprimée du client et qu'un autre client utilise la même interface réseau pour génerer un DUID-LLT.

   Cette méthode de génération de DUID est recommandée pour les périphériques courant tels que les postes de travail, imprimantes, routeurs, etc. qui contiennent un stockage non-volatile.

   Il est cependant possible que cet algorithme génère un DUID créant une collision. Un client DHCP qui génère un DUID-LLT en utilisant ce mécanisme doit fournir une interface administrative qui remplace le DUID existant avec un nouveaux DUID.

DUID type 2 (DUID-EN)

Cette forme de DUID est assignée par le vendeur au périphérique. Il consiste du Private Enterprise Number du vendeur maintenu par l'IANA, suivi par un identifiant unique assigné par le vendeur.
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________2_______________|_______enterprise-number_______|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___enterprise-number_(contd)___|_______________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_______________________________|
.___________________________identifier__________________________.
._______________________(variable_length)_______________________.
._______________________________________________________________.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   La source de l'identifiant est laissée au vendeur, mais chaque partie de l'identifiant de chaque DUID-EN doit être unique au périphérique, et doit être assigné au périphérique au moment de sa fabrication et stocké dans un stockage non-volatile, et devrait être stocké dans un stockage non-effacable.

DUID type 3 (DUID-LL)

Ce type de DUID consiste de 2 octets contenant le type 3, un code de type hardware à 2 octets, suivi par l'adresse de lien réseau d'une interface connectée au client ou serveur.
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________3_______________|____hardware_type_(16_bits)____|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
._______________________________________________________________.
._____________link-layer_address_(variable_length)______________.
._______________________________________________________________.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Le choix de l'interface réseau peut être complètement arbitraire, tant que cette interface fournis une adresse de lien réseau unique et est attaché en permanence au périphérique qui génère le DUID-LL. Le même DUID-LL devrait être utilisé pour configurer toutes les interfaces réseaux connectées au périphérique, sans regarder qui adresses de lien réseau a été utilisée pour générer le DUID.

   DUID-LL est recommandé pour les périphériques qui ont une interface réseau connecté en permanence avec une adresse de lien réseau, et n'a pas de stockage non-volatile. LUID-LL ne doit pas être utilisé par les clients DHCP ou les serveurs qui ne peuvent pas dire si une interface réseau est attachée en permanence au périphérique sur lequel le client DHCP fonctionne.

Identity Association

   Un identity-association (IA) est une construction qu'un serveur et un client peut utiliser pour identifier, grouper, et gérer un jeu d'adresses IPv6 liées. Chaque IA consiste d'un IAID et d'informations de configurations associées.

   Un client doit associer au moins un IA distinct avec chacune de ses interfaces réseau depuis un serveur DHCP. Le client utilise les IA assignés à une interface pour obtenir des informations de configuration depuis un serveur pour cette interface. Chaque IA doit être associée avec exactement une interface.

   Le IAID identifie de manière unique l'IA et doit être choisis pour être unique avec les IAID dans le client. Le IAID est choisis par le client. Pour une utilisation donnée d'un IA par le client, le IAID pour cet IA doit être consistant entre les redémarrages du client DHCP. Le client peut stocker le IAID dans un stockage non volatile ou en utilisant un algorithme qui produira un IAID consistant tant que la configuration du client n'a pas changé.

   Les informations de configuration dans un IA consiste d'une ou plusieurs adresses IPv6 avec les temps T1 et T2 pour l'IA. Chaque adresse dans un IA a une durée de vie préférentielle et une durée de vie valide. Les durées de vie sont transmises du serveur au client dans l'option IA. La durée de vie s'applique à l'utilisation des adresses IPv6.

Séléctionner des adresses pour l'assignement à un IA

   Un serveur séléctionne des adresses à assigner à un IA en accord avec les stratégies d'assignement d'adresse déterminés par l'administrateur serveur et les informations spécifiques déterminés par le serveur pour le client vient d'un combinaison des sources suivantes:

- Le lien via lequel le client est attaché. Le sereur détermine le lien comme suit:

        - Si le serveur reçoit le message directement du client et que l'adresse source dans le datagramme IP dans lequel le message a été reçu est une adresse de lien local, alors le client est sur le même lien que l'interface sur laquelle le message a été reçu.
        - Si le serveur reçoit le message depuis un agent relais, alors le client est sur le même lien que celui avec lequel l'interface, identifié par le champ link-address dans le message de l'agent relais, est attaché.
        - Si le serveur reçoit le message directement du client et que l'adresse source dans le datagramme IP dans lequel le message a été reçu n'est pas une adresse de lien local, alors le client est sur le lien identifié par l'adresse source dans le datagramme IP.

- Le DUID est fournis pas le client
- D'autres informations dans les options fournies par le client

   Toute adresse assignée par un serveur qui est basé sur un identifiant EUI-64 doit inclure un identifiant d'interface avec les bits "u" (universal/local) et "g" (individual/group) de l'identifiant d'interface (rfc2373)

   Un serveur ne doit pas assigner une adresse qui est réservée pour d'autres utilisations.

Gestion des adresses temporaires

   Un client peut demander l'assignement d'adresses temporaires. DHCPv6 gère l'assignement sans faire de différence pour ces adresses temporaires. DHCPv6 n'indique rien sur le détails des adresses temporaires, comme la durée de vie, comment les clients utilisent ces adresses, les règles de génération d'adresses temporaires, etc.

   Les client demandent des adresses temporaire et les serveur leur en assigne. Les adresses temporaires sont gérées dans l'option IA pour les adresses temporaires (IA_TA). Chaque option IA_TA contient au moins une adresses temporaire pour chaque préfixe dans le lien sur lequel le client est attaché.

   L'espace de nombre IAID pour l'option IA_TÀ est séparé de l'IAID pour l'option IA_NA.

Transmission de messages par un client

   Sauf mentionné dans ce document, ou dans un document décrivant comment IPv6 gère un type de lien spécifique, un client envoie les messages DHCP à l'adresse All_DHCP_Relay_Agents_and_Servers

   Un client utilise le multicast pour atteindre tous les serveurs ou un serveur individuel. Un serveur individuel est indiqué en spécifiant le DUID du serveur dans l'option Server Identifier dans le message du client.

Fiabilité des échanges initiés par le client

   Les clients DHCP sont responsables de la fiabilité de la livraison des messages dans les échanges initiés par le client. Si un client DHCP échoue à recevoir une réponse attendue d'un serveur, le client doit retransmettre son message. Cette section décris la stratégie de retransmission à utiliser par les clients.

   Noter que la procédure décrite dans cette section est légèrement modifiée quand utilisée avec le message Solicit.

   Le client commence l'échange en transmettant un message au serveur. L'échange se termine qund le client à reçue la réponse appropriée du ou des serveurs, ou quand l'échange est considéré échoué en accord avec le mécanisme de retransmission décris ci-dessous.

   Le comportement de retransmission du client est contrôlé et décris par les variables suivantes:

RT Retransmission timeout
IRT Initial retransmission time
MRC Maximum retransmission count
MRT Maximum retransmission time
MRD Maximum retransmission duration
RAND Randomization factor

   Avec chaque transmission de message ou retransmission, le client met RT en accord avec les règles données plus bas. Si RT expire avant que l'échange se termine, le client recalcule RT et retransmet le message.

   Chaque calcul d'un nouveau RT inclus un facteur aléatoire (RAND), qui est entre -0.1 et +0.1. Ce facteur est inclus pour minimiser la synchronisation des messages transmis par les clients DHCP.

   L'algorithme pour choisir un nombre aléatoire n'a pas besoin d'être cryptographique. L'algorithme devrait produire une séquence différente pour chaque invocation d'un client DHCP.

Le RT pour la transmission du premier message est basé sur IRT:
RT=IRT + RAND*IRT

Le RT pour chaque transmission suivante est basé sur la valeur RT précédente:
RT = 2*RTprev + RAND*RTprev

Le MRT spécifie une limite maximum de la valeur de RT. Si MRT a une valeur de 0, il n'y a pas de limite maximum. Sinon:
if ( RT › MRT )
_RT = MRT + RAND*MRT

   Le MRC spécifie le nombre de retransmission. Sauf à 0, l'échange échoue quand le client a atteint cette limite de retransmission.

   Les MRD spécifie une limite de temps pour la retransmission d'un message. Saux à 0, l'échange échoue une fois ce temps passé à transmettre le message.

   Si MRC et MRD ne sont pas à 0, l'échange échoue quand une de ces conditions est atteinte. Si MRC et MRD sont à 0, le client continue à transmettre le message jusqu'à ce qu'il reçoive une réponse.

Validation de message

   Les clients et serveurs devraient supprimer tous messages qui contiennent des options qui ne sont pas autorisés à apparaître dans le message reçu. Par exemple, une option IA n'est pas permis dans un message Information-request. Les clients et serveurs peuvent choisir d'extraire les informations d'un tel message si l'information est utile pour le destinataire.

   Un serveur doit supprimer les messages Solicit, Confirm, Rebind ou Information-request s'il les reçoit avec une adresse de destination unicast.

   Si un serveur reçoit un message qui contient des options qu'il ne devrait pas contenir, que des options sont manquantes, ou n'est pas valide, il peut envoyer un Reply (ou Advertise) avec une option Server Identifier, une option Client Identifier si elle était incluse dans le message et une option Status Code avec le status UnSpecFail.

Utilisation des ID de transaction

   Le champ transaction-id maintien une valeur utilisée par les clients et les serveurs pour synchroniser les réponses des serveurs aux message client. Un client devrait générer un nombre aléatoire qui ne peut pas être facilement deviné ou prédit à utiliser comme ID de transaction pour chaque nouveau message qu'il envoie. Un client doit laisser l'ID de transaction inchangé dans les retransmissions d'un message.

Message Solicit

   Les clients doivent détruire tous messages Solicit reçus. Les serveurs doivent détruire tous messages Solicit qui n'incluent pas l'option Client Identifier ou qui incluent une option Server Identifier.

Message Advertise

   Les clients doit détruire tous messages Advertise qui rencontre une de ces conditions:

- Le message n'inclus pas l'option Server Identifier
- Le message n'inclus pas l'option Client Identifier
- Le contenu de l'option Client Identifier ne correspond pas à la valeur utilisée par le client dans son message Solicit

   Les serveurs et agent relais doivent supprimer tous messages Advertise reçus.

Message Request

   Les clients doivent détruire tout message Request. Les serveurs doivent détruire tout message Request qui rencontre une de ces conditions:

- Le message n'inclus pas l'option Server Identifier
- Le contenus de l'option Server Identifier ne match pas le DUID du serveur
- Le message n'inclus pas l'option Client Identifier

Message Confirm

   Les clients doivent détruire tous message Confirm. Les serveurs doivent détruire tous messages Confirm qui n'incluent pas l'option Client Identifier ou qui n'incluent pas l'option Server Identifier.

Message Renew

   Les cients doivent détruire tous messages Renew reçus. Les serveur doivent détruire tous message Renew qui rencontre une de ces conditions:

- Le message n'inclus pas l'option Server Identifier
- Le contenu de l'option Server Identifier ne correspond pas à l'identifiant du serveur
- Le message n'inclus pas l'option Client Identifier

Message Rebind

   Les clients doivent détruire tous messages Rebind. Les serveurs doivent détruire tous message Rebind qui n'incluent pas l'option Client Identifier ou qui n'incluent pas l'option Server Identifier.

Messages Decline

   Les clients doivent détruire tous messages Decline reçus. Les serveurs doivent détruire tout message Decline qui rencontre une de ces conditions:

- Le message n'inclue pas l'option Server Identifier
- Le contenue de l'option Server Identifier ne correspond par à l'identifiant du serveur
- Le message n'inclue pas l'option Client Identifier

Message Release

   Les clients doivent détruire tous messages Release reçus. Les serveurs doivent détruire tout message Release qui rencontre une de ces conditions:

Message Reply

   Les clients doivent détruire tout message Reply qui rencontre une de ces conditions:

- Le message n'inclue pas l'option Server Identifier
- Le champ transaction-id dans le message ne correspond par à la valeur utilisée dans le message original

   Si le cilent a inclus l'option Client Identifier dans le message d'origine, le message Reply doit inclure une option Client Identifier contentant le DUID du client. Si le client n'a pas inclue l'option Client Identifier dans le message d'origine, le message Reply ne doit pas inclure une option Client Identifier.

Message Reconfigure

   Les serveurs et agents relais doivent détruire tous message Reconfigure. Les clients doit détruire tout message Reconfigure qui rencontre une de ces conditions:

- Le message n'a pas été unicast au client
- Le message n'inclue pas l'option Server Identifier
- Le message n'inclue pas l'option Client Identifier qui contient le DUID du client
- Le message ne contient pas l'option Reconfigure Message et le msg-type doit être une valeur valide
- Le message inclue une option IA et msg-type dans l'option Reconfigure Message est INFORMATION-REQUEST
- Le message n'inclue pas d'authentification DHCP:

        - Le message ne contient pas une option d'authentification
        - Le message ne passe pas la validation de l'authentification effectuée par le client.

Message Information-request

   Les clients doivent détruire tous message Information-request reçus. Les serveurs doivent détruire tout message Information-request reçus qui rencontre une de ces conditions:

- Le message inclus une option Server Identifier et le DUID dans l'option ne correspond pas au DUID du serveur.
- Le message inclue une option IA

Message Relay-forward

   Les client doit détruire tous message Relay-forward reçus

Message Relay-reply

   Les clients et serveur doivent détruire tous message Relay-reply reçus.

Sélection d'adresse source client et interface

   Quand un client envoie un message DHCP à l'adresse All_DHCP_Relay_Agents_and_Servers, il devrait envoyer le message via l'interface pour laquelle les informations de configuration sont demandées. Cependant, le client peut envoyer le message via une autre interface attachée sur le même lien, si et seulement si le client est certain que les 2 interfaces sont attachées au même lien. Le client doit utiliser une adresse de lien local assigné à l'interface pur laquelle il demande les informations de configuration comme adresse source.

   Quand un client envoie un message DHCP directement à un serveur en utilisant unicast (après avoir reçu l'option Server Unicast de ce serveur), l'adresse source dans l'en-tête IP doit être une adresse assignée à l'interface pour laquelle le client souhaite obtenir une configuration et qui est utilisable par le serveur en répondant au client.

Solicitation serveur DHCP

   Cette section décris comment un client localise les serveurs qui assignent des adresses aux IA appartenant au client.

   Le client est responsable de la création des IA et de la demande à un serveur d'assigner des adresses IPv6 à l'IA. Le client créé d'abord un IA et lui assigne un IAID. Le client transmet un message Solicit contenant une option IA décrivant l'IA. Les serveurs qui peuvent assigner des adresses à l'IA répondent au client avec un message Advertise. Le client initie alors un échange de configuration.

   Si le client accepte un message Reply avec l'assignement d'adresse fournis et autres ressources en réponse au message Solicit, le client inclus une option Rapid Commit dans le message Solicit.

Comportement client

   Un client utilise le message Solicit pour découvrir les serveurs DHCP configurés pour assigner les adresses ou retourner d'autres paramètres de configuration sur le lien sur lequel le client est attaché.

Création des messages Solicit

   Le client définis le champ msg-type à SOLICIT. Le client génère un ID de transaction et l'insert dans le champ transaction-id

   Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client inclus l'option IA pour tous les IA pour lesquelle il souhaite que le serveur assigne des adresses. Le client peut inclure des adresses dans les IA comme adresses préférentielles. Le client ne doit pas inclue d'autres options dans le message Solicit, excepté si spécifiquement permis dans la définition des options individuelles.

   Le client utilise les options IA_NA pour demander l'assignement d'adresses non-temporaires et utilise les options IA_TA pour demander l'assignement d'adresses temporaire. Les 2 peuvent être inclus dans les messages DHCP.

   Le client devrait inclure une option Option Request pour indiquer les options que le client souhaite reçevoir. Le client peut additionnellement inclure les instances de ces options qui sont identifiées dans l'option Option Request, avec des valeurs pour indiquer ses préférences.

   Le client inclus une option Reconfigure Accept si le client est capable d'accepter les messages Reconfigure du serveur.

Transmission des messages Solicit

   Le premier message Solicit du client doit être retardé par un temps aléatoire entre 0 et SOL_MAX_DELAY. Dans le cas d'un message Solicit transmis quand DHCP est initié par IPv6 ND, le délais donne la quantité de temps d'attente après que ND cause le client à invoquer le protocole d'autoconfiguration avec état. Ce délai aléatoire désynchonise les client qui démarrent en même temps.

   Le client transmet le message en accord avec la section "Fiabilité des échanges initiés par le client", en utilisant les paramètres suivants:

IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0

   Si le client a inclus une option Rapid Commit dans son message Solicit, le client termine le processus d'attente dès qu'un message Reply avec l'option Rapid Commit est reçu.

   Si le client attend un message Advertise, le mécanisme dans la section "Fiabilité des échanges initiés par le client" est modifié comme suit dans la transmission des messages solicit. L'échange de message n'est pas terminé par la réception d'un Advertise avant que le premier RT soit atteinds. Au lieu de celà, le client collecte les messages Advertise jusqu'à ce que le premier RT soit passé. Également, le premier RT doit être sélectionné pour être strictement supérieur à IRT en choisissant RAND pour être strictement supérieur à 0.

   Un client doit collecter les message Advertise pendant les RT premières secondes sauf s'il reçoit un message Advertise avec une valeur de préférence à 255. La valeur de préférence est gérée dans l'option Preference. Tout Advertise qui n'inclus pas une option Preference est considérée avec une préférence à 0. Si le client reçoit un Advertise qui inclus une option Preference avec une valeur 255, le client commence immédiatement un échange en envoyant un Request au serveur. Si le client reçoit un message Advertise qui n'inclus pas l'option Preference avec une valeur de 255, le client continue à attendre le RT. Si le premier RT est atteind et que le client a reçu un Advertise, le client doit continue avec un échange en envoyant un Request.

   Si le client ne reçoit pas d'Advertise, il commence le mécanisme de retransmission. Le client termine le processus de retransmission dès qu'il reçoit un Advertise, et le client agit sur le message Advertise sans attendre d'autre message Advertise.

   Un client DHCP devrait choisir MRC et MRD à 0. Si le client DHCP est configuré avec MRC ou MRD autre qu'à 0, il doit arrêter sa tentative de configurer l'interface si l'échange échoue, puis devrait redémarrer le processus de reconfiguration après un événement externe, tel que l'entrée utilisateur, redémarrage système, ou quand le client est attaché à un nouveau lien.

Réception des Messages Advertise

   Le client doit ignorer tout message Advertise qui inclus une option Status Code contenant la valeur NoAddrsAvail, à l'exception que le client peut afficher le message de status associé à l'utilisateur.

   Une fois un ou plusieurs messages Advertise valide reçus, le client en séléctionne un ou plus basé sur les critères suivants:

- Les message Advertise avec la valeur de préférence serveur la plus élevé sont préférés.
- Dans un groupe de message Advertise avec la même valeur de préférence serveur, un client peut séléctionner les serveurs dons les message Advertise annoncent des informations d'interêt au client.
- Le cilent peut choisir un serveur moins préféré si ce serveur a un meilleurs jeu de paramètres.

   Une fois qu'un client a sélectionne le ou les messages Advertise, le client stocke les informations sur chaque serveur. Si le client doit sélectionner un serveur alternatif dans le cas où un serveur ne répond pas, le client choisis le serveur suivant en accord avec les critères ci-dessus.

Réception d'un message Reply

   Si le client inclus une option Rapid Commit dans le message Solicit, il s'attend à un message Reply qui inclus une option Rapid Commit. Le client supprime tous message Reply qui ne contiennent pas l'option Rapid Commit. Si le client reçoit un message Reply valide avec l'option Rapid Commit, il traite le message. S'il ne reçoit pas un tel Reply, le client traite le message Advertise comme décris ci-dessus.

   Si le client reçois un message Reply valide qui inclus une option Rapid Commit, il peut:

- Traiter le message Reply comme décris plus bas, et supprimer tous messages Reply reçus en réponse au Request, ou
- Traiter tout message Reply en réponse au Request et supprimer le message Reply qui inclus l'option Rapid Commit.

Comportement serveur

   Un serveur envoie un message Advertise en réponse aux messages Solicit valides qu'il reçoit pour annoncer la disponibilité du serveur au client.

Réception des messages solicit

   Le serveur détermine les information sur le client et son emplacement, puis vérifie sa stratégie administrative pour répondre au client. Si le serveur n'est pas autorisé à répondre au client, le serveur supprime le message Solicit. Par exemple, si la stratégie administrative du serveur est de répondre uniquement aux clients capable d'accèpter un message Reconfigure, le serveur supprimera tout message Solicit indiquant qu'il n'accepte pas de message Reconfigure.

   Si le client a inclus une option Rapid Commit et que le serveur a été configuré pour répondre avec l'assignement d'adresse et autre ressources, le serveur répond avec un Reply comme décris plus bas. Sinon, le serveur ignore l'option Rapid Commit et traite le reste du message comme si l'option n'était pas présente.

Création et transmission des messages Advertise

   Le serveur met le champ msg-type à ADVERTISE et copie le contenu du champ transaction-id du message Solicit reçu du client dans le message Advertise. Le serveur inclus son identifiant dans une option Server Identifier et copie le Client Identifier dans le message Advertise.

   Le serveur peut ajouter une option préférence. Les implémentations serveur devraient permettre le paramètrage de valeur de préférence serveur par l'administrateur. La valeur de préférence doit être à 0 par défaut.

   Le serveur inclus une option Reconfigure Accept si le serveur exige du client qu'il accèpte les messages Reconfigure.

   Le serveur inclus les options que le serveur retourne au client dans un message Reply. Les informations dans ces options peuvent être utilisé par le client dans la sélection d'un serveur si le client reçoit plus d'un message Advertise. Si le client a inclus une option Option Request dans le message Solicit, le serveur inclus les options dans le message Advertise contenant les paramètres de configuration pour toutes les options identifiées dans l'option Option Request pour lesquelles le serveur a été configuré pour répondre au client. Le serveur peut retourner d'autres options au client s'il a été configuré pour le faire.

   Si le message Solicit du client incluait une ou plusieurs options IA, le serveur doit inclure les options IA dans le message Advertise contenant les adresses à assigner aux IA. Si le client a inclus des adresses dans les IA dans le message Solicit, le serveur les utilise comme préférences pour ce client.

   Si le serveur n'assigne pas d'adresse à des IA dans un Request du client, le serveur doit envoyer un message Advertise qui inclus seulement une option Status Code avec le code NoAddrsAvail et un message de status pour l'utilisateur, une option Server Identifier avec le DUID du serveur, et une option Client Identifier avec le DUID du client.

   Si le message Solicit a été reçu directement par le serveur, le serveur unicast le message Advertise directement au client en utilisant l'adresse dans le champ adresse source du datagramme IP. Le message Advertise doit être unicast sur le lien sur lequel le message Solicit a été reçus.

   Si le message Solicit a été reçu dans un message Relay-forward, le serveur construit un message Relay-reply avec le message Advertise dans le payload d'une option relay-message. Si le message Relay-forward incluait une option Interface-id, le serveur copie cette option dans le message Relay-reply. Le serveur unicast le message Relay-reply directement à l'agent relay en utilisant l'adresse dans le champ adresse source du datagramme IP.

Création et transmission des messages Reply

   Le serveur doit envoyer l'assignement des adresses ou autres informations de configuration avant d'envoyer un message Reply à un client en réponse à un message solicit.

   En utilisant un échange Solicit-Reply, le serveur envoie l'assignement des adresses avant d'envoyer le message Reply. Le client peut assumer qu'il a reçu les adresses dans le message Reply et n'a pas besoin d'envoyer un message Request pour ces adresses.

   Typiquement, les serveur qui sont configurés pour utiliser l'échange Solicit-Reply sont déployés pour qu'un seul serveur réponde à un message Solicit. Si plus d'un serveur répond, le client utilise seulement les adresses d'un seul de ces serveurs.

   Le serveur inclus une option Rapid Commit dans le message Reply pour indiquer que le Reply est en réponse à un message Solicit.

   Le serveur inclus une option Reconfigure Accept s'il souhaite que le client accepte les messages Reconfigure.

Échange de configuration DHCP initié par le client

   Un client initie un échange de message avec un ou plusieurs serveurs pour obtenir ou mettre à jours sa configuration. Le client peut initier l'échange comme partie du processus de configuration système, quand requis.

Comportement client

   Un client utilise les messages Request, Renew, Rebind, Release, et Decline durant le cycle de vie normal des adresses. Il utilise Confirm pour valider les adresses quand il a été déplacé sur un nouveau lien. Il utilise les message Information-Request quand il a besoin d'informations de configuration sans adresses.

   Si le client a une addresse source de scope suffisant qui peut être utilisé par le serveur comme adresse de retour, et que le client a reçu une option Server Unicast du serveur, le client devrait unicast tous messages Request, Renew, Release et Decline au serveur.

Création et transmission des messages Request

   Le client utilise un message Request pour populer les IA avec des adresses et obtenir d'autres informations de configuration. Le serveur inclus un ou plusieurs options IA dans le message Request. Le serveur retourne les adresses et autres informations sur les IA au client dans les options IA dans un message Reply.

   Le client génère un ID de transaction et l'insert dans le champ transaction-id.

   Le client doit inclure une option Client Identifier pour s'identifier lui-même au serveur. Le client ajoute toute autre options appropriées, incluant une ou plusieurs options IA.

   Le client doit inclure une option Option Request pour indiquer les options que le client souhaite obtenir. Le client peut inclure des options avec des valeur pour indiquer ses préférences sur ces paramètres.

   Le client inclus une option Reconfigure Accept indiquant si le client accèpte les messages Reconfigure du serveur.

   Le client transmet le message en utilisant les paramètres suivants:

IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
MRD 0

   Si l'échange échoue, le client prend une action basée sur la stratégie locale du client. Des exemples d'actions que le client peut prendre incluent:

- Sélectionner un autre serveur de la liste de serveurs connus, par exemple, les serveurs qui ont répondu avec un message Advertise
- Initier le processus de découverte de serveur
- Terminer le processus de configuration et reporter une erreur.

Création et transmission des messages Confirm

   Un client pouvant être placé sur un nouveau lien, les préfixes des adresses assignées aux interfaces sur ce lien ne sont plus appropriés pour le lien sur lequel le client est attaché. Par exemple:

- Le client redémarre
- Le client est physiquement connecté à une connection filaire
- Le client revient d'un mode veille
- Le client utilise une technologie sans-fil et change de point d'accès

   Dans ces situations, quand un client peut avoir changé de lien, le client doit initier un échange Confirm/Reply. Le client inclus les IA assignés à l'interface qui a changé de lien, avec les adresses associées avec ces IA, dans son message Confirm. Tout serveur répondant indique si ces adresses sont appropriées pour le lien pour lequel le client est attaché avec le status dans le message Reply qu'il retourne au client.

   Le client met le champ msg-type à CONFIRM. Le client génère un ID de transaction dans le champ transaction-id.

   Le client doit inclure une option Client Identifier pour s'identifier lui-même au serveur. Le client inclus les options IA pour tous les IA assignés à l'interface pour laquelle le message Confirm est envoyé. Les options IA incluent toutes les adresses que le client a associé avec ces IA. Le client devrait mettre les champs valid-lifetime dans les options IA Address à 0, vu que le serveur va ignorer ces champs.

   Le premier message Confirm du client dans l'interface doit être retardé par un délais aléatoire entre 0 et CNF_MAX_DELAY. Le client transmet le message en utilisant les paramètres suivants:

IRT CNF_TIMEOUT
MRT CNF_MAX_RT
MRC 0
MRD CNF_MAX_RD

   Si le client ne reçois pas de réponse avant que le processus de transmission ne se termine, le client devrait continuer à utiliser les adresses IP, en utilisant le dernier lifetime connus pour ces adresses, et devrait continuer à utiliser tout paramètres précédemment utilisés.

Création et transmission des messages Renew

   Pour étendre la durée de vie des adresses associées aux IA, le client envoie un message Renez au serveur. Le client inclus les options IA Address dans l'option IA pour les adresse associées avec l'IA. Le serveur détermine les nouvelles durées de vie pour les adresses dans l'IA en accord avec la configuration administrative du serveur. Le serveur peut également ajouter de nouvelles adresses à l'IA. Le serveur peut supprimer les adresses de l'IA en définissant les durées de vie préférrés et valide de ces adresses à 0.

   Le serveur contrôle le temps auquel le client contacte le serveur pour étendre la durée de vie des adresses assignées via les paramètres T1 et T2.

   Au temps T1 pour un IA, le client initie un échange Renew/Reply pour étendre la durée de vie des adresses dans l'IA. Le client inclus une option IA avec toutes les adresses actuellement assignées à l'IA dans son message Renew.

   Si T1 ou T2 est à 0 (pour un IA_NA) ou s'il n'y a pas de T1 ou T2 (pour un IA_TA), le client peut envoyer un message Renew ou Rebind, respectivement, à la discretion du client.

   Le client met msg-type à RENEW. Le client génère un ID de transaction dnas transaction-id. Le client place l'identifiant du serveur de destination dans une option Server Identifier.

   Le client doit inclure une option Client Identifier pour s'identifier lui-même au serveur. Le client ajoute toutes options appropriées, incluant une ou plusieurs options IA. Le client doit inclure une liste d'adresse que le client a associé avec les IA dans le message Renew.

   Le client doit inclure une option Option Request pour indiquer les options que le client souhaite reçevoir. Le client peut inclure des options avec des valeurs comme indicateur au serveur que le client souhaite avoir en retour.

IRT REN_TIMEOUT
MRT REN_MAX_RT
MRC 0
MRD Remaining time until T2

   L'échange est terminé quand le temps T2 est atteind, auquel cas le client commence un échange Rebind.

Création et transmission des messages Rebind

   Au temps T2 pour un IA, le client initie un échange Rebind/Reply avec un serveur disponible. Le client inclus une option IA avec toutes les adresses actuelement assignées à l'IA dans son message Rebind.

   Le client met msg-type à REBIND. Le client génère un ID de transaction dans le champ transaction-id. Le client doit inclure une option Client Identifier, et ajoute les options appropriées, incluant une ou plusieurs options IA. Le client doit incluer la liste des adresses associées avec l'IA dans le message REBIND.

IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Temps restant jusqu'à ce que la durée de vie de toutes les adresses aient expirées.

   L'échange est terminé quand les durées de vie de toutes les adresses assignées à l'IA ont expirée. À ce moment le client a plusieurs alternative:

- Le client peut utiliser un message Solicit pour localiser un nouveau serveur DHCP et envoyer un Request pour l'IA expiré à un nouveau serveur.
- Si le client a d'autres adresses dans d'autres IA, le client peut choisir de supprimer l'IA expiré et d'utiliser les adresses dans les autres IA.

Création et transmission des messages Information-request

   Le client utilise un message Information-request pour obtenir des informations de configuration sans assigner d'adresses. Le client met msg-type à INFORMATION-REQUEST. Le client génère un ID de transaction dans le champ transaction-id.

   Le client devrait inclure une option Client Identifier pour s'identifier au serveur. Si le client n'inclus pas cette option, le serveur ne sera pas capable de retourner d'options spécifiques au client, ou le serveur peut choisir de ne pas répondre du tout. Le client doit inclure cette option si le message Information-Request est authentifié.

   Le client doit inclure une option Option Request pour indiquer les options que le client souhaite reçevoir. Le client peut inclure des options avec des valeurs comme préférences.

   Le premier message Information-request du client dans l'interface doit être retardé par un délay aléatoire entre 0 et INF_MAX_DELAY. Le client transmet le message avec les paramètres suivants:

IRT INF_TIMEOUT
MRT INF_MAX_RT
MRC 0
MRD 0

Création et transmission des messages Release

   Pour libérer une ou plusieurs adresses, un client envoie un message Release au serveur. Le client met msg-type à RELEASE et génère un ID de transaction dans le champ transaction-id.

   Le client place l'identifiant du serveur qui a alloué les adresses dans une option Server Identifier. Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client inclus les options contenant les IA contenant les adresses à libérer.

   Le client ne doit pas utiliser les adresses qu'il a libéré. Parce que les message Release peuvent être perdus, le client devrait retransmettre le message s'il ne reçoit pas de réponse. Cependant, il y a des scénarios où le client peut ne pas vouloir attendre (ex: extinction). Les implémentations devraient retransmettre une ou plusieurs fois, mais peuvent choisir de terminer la retransmission plus tôt.

IRT REL_TIMEOUT
MRT 0
MRC REL_MAX_RC
MRD 0

   Si les adresses sont libérées mais la réponse est perdue, le client va retransmettre le message Release, et le serveur peut répondre avec un Reply indiquant le status NoBinding.

Création et transmission des messages Decline

   Si un client détecte qu'une ou plusieurs adresses assignées par le serveur sont déja utilisées par un autre nœud, le client envoie un message Decline au serveur pour informer que l'adresse est suspecte.

   Le client met msg-type à DECLINE. Le client génère un ID de transaction dans le champ transaction-id, et place d'identifiant du serveur qui a alloué la ou les adresses dans une option Serveur Identifier.

   Le client doit inclure une option Client Identifier pour s'identifier au serveur. Le client inclus les options contenant les IA pour les adresses qu'il décline. Les adresses qu'il décline doivent être incluses dans les IA. Les autres adresses que le client souhaite continuer à utiliser ne doivent pas être ajoutées dans les IA.

   Le client ne doit pas utiliser les adresses qu'il décline. Le client transmet le message en utilisant les paramètres suivants:

IRT DEC_TIMEOUT
MRT 0
MRC DEC_MAX_RC
MRD 0

   Si des adresses sont déclinées mais le Reply du serveur DHCP est perdu, le client retransmet le message Decline, et le serveur peut répondre avec un Reply indiquant un status NoBinding. Donc, le client ne traite pas un message Reply avec un status NoBinding dans un échange Decline vu qu'il indique une erreur.

Réception des messages Reply

   Une fois reçu un message Reply valide en réponse à un message Solicit (avec l'option Rapid Commit), Request, Confirm, Renew, Rebind ou Information-request, le client extrait les informations de configuration contenues dans la réponse.

   Le client devrait effectuer une détection d'adresses dupliquée sur chaque adresse dans les IA qu'il reçoit dans le message Reply avant de les utiliser. Si une des adresses est utilisée sur le lient, le client envoie un message Decline au serveur.

   Si le Reply a été reçu en réponse à un message Solicit (avec l'option Rapid Commit), Request, Renew ou Rebind, le client met à jours les informations qu'il a enregistré sur les IA depuis les options IA contenus dans le Reply:

- Enregistre les temps T1 et T2
- Ajoute toute nouvelle adresse dans l'option IA à l'IA enregistrée par le client
- Met à jours la durée de vie des adresses dans l'option IA
- Supprime toute adresses de l'IA, enregistré par le client, qui ont une durée de vie de 0 dans l'option IA Address
- Laisse toute information inchangée sur les adresses que le client a enregistré dans l'IA mais n'était pas inclus dans l'IA reçu du serveur.

   La gestion des informations de configuration spécifique est détaillée dans la définition de chaque option plus bas dans ce document.

   Si le client reçoit un message Reply avec un code de status contenant UnspecFail, le serveur indique qu'il n'est pas capable de traiter le message à cause d'une condition non spécifiée. Si le client retransmet le message original au même serveur pour retenter la même opération, le client doit limiter le taux de retransmission du message et limiter la durée de retransmission.

   Quand le client reçois un message Reply avec un code de status UseMulticast, le client enregistre le message et envois les messages suivants au serveur via l'interface sur laquelle il a reçus le Reply. Le client renvoie le message original en utilisant le multicast.

   Quand le client reçoit un status NotOnLink du serveur en réponse à un message Confirm, le client effectue une solicitation de serveur, et une configuration initié par le client. Si le client reçois un message Reply qui n'indique pas un status NotOnLink, le client peut utiliser l'adresse dans l'IA et ignorer tous messages qui indiquent un status NotOnLink.

   Le client examine le code de status dans chaque IA individuel. Si le code de status est NoAddrsAvail, le client n'a pas reçus d'adresses utilisatble dans l'IA et peut choisir de tenter d'obtenir des adresses pour l'IA depuis d'autres serveurs. Le client utilise les adresses et autres informations des IA qui ne contiennent pas le code NoAddrsAvail. Si le cient ne reçoit pas d'adresses dans aucun IA, il peut soit tenter d'utiliser un autre serveur, ou utiliser un Information-request pour obtenir d'autres informations de configuration.

   Quand le client reçoit un message Reply en réponse à un Renew ou un Rebind, le client examine chaque IA indépendamment. Pour chaque IA dans le message Renew ou Rebind original, le client:

- Envoie un message Request si l'IA contenait une option Code Status avec le status NoBinding ( et n'envoie pas de messages additionnels )
- Enovie un Renew/Rebind si l'IA n'est pas dans le message Reply
- Sinon accept l'information dans l'IA

   Quand le client reçoit un message Reply valide en réponse à un message Release, le client considère l'événement Releas complété, sans regarder l'option Status Code retourné par le serveur.

Comportement du serveur

   Dans la plupart des instances, le serveur envoie un Reply en réponse à un message client. Ce Reply doit toujours contenir l'option Server Identifier contenant le DUID du serveur et l'option Client Identifier correspondant au message reçu du client s'il était présent.

   Dans la plupart des messages Reply, le serveur inclus les options contenant les informations de configuration pour le client. Le serveur doit connaître les recommandations des tailles de paquet et l'utilisation de la fragmentavtion. Si le client a inclus une option Option Request dans son message, le serveur inclus les options dans la résponse contenant les paramètres de configuration pour toutes les options identifiées à retourner au client. Le serveur peut retourner d'autres options au client s'il a été configuré pour celà.

Réception des messages Request

   Quand le serveur reçoit un message Request via unicast d'un client auquel le serveur n'a pas d'option unicast, le serveur détruit le Request et réponds avec un message Reply contenant un status UseMulticast.

   Quand le serveur reçoit une message Request valide, le serveur créé les liaisons avec ce client en accord avec la stratégie du serveur et les informations de configuration et enregistre les IA et autres information demandées par le client.

   Le serveur doit inclure une option Server Identifier et Client Identifier. dans le message Reply.

   Si le serveur trouve que le préfixe d'une ou plusieurs IP dans un IA dans le message du client n'est pas approprié pour le lien, le serveur doit retourner l'IA au client avec un code de status NotOnLink.

   Si le serveur ne peut pas assigner des adresses à un IA dans le le message du client, le serveur doit inclure l'IA dans le Reply sans adresses et un status dans l'IA contenant le status NoAddrsAvail.

   Pour tout IA auquel le serveur peut assigner des adresses, le serveur inclus l'IA avec les adresses et autres paramètres de configuration, et enregistre l'IA comme nouvelle liaison cliente.

   Le serveur inclus l'option Reconfigure Accet si le serveur souhaite que le client accepte les messages Reconfigure.

   Le serveur inclus d'autres options contenant des informations de configuration à retourner au client.

   Si le serveur trouve que le client a inclus un IA dans la requête pour lequel le serveur a déjà une liaison associée avec le client, le client a renvoyé un message Request pour lequel il n'a pas reçus de message Reply. Le serveur renvoie un message Reply précédemment mis en cache, ou envoie un nouveau message Reply.

Reception des messages Confirm

   Quand le serveur reçoit un message Confirm, le serveur détermine si les adresses dans le message Confirm sont appropriés pour le lien auquel le client est attaché. Si toutes les adresses dans le message Confirm ont passé ce test, le serveur retourne un status Success. Si une des adresse ne passe pas ce test, le serveur retourne un status NotOnLink. Si le serveur n'est pas capable d'effectuer ce test, où s'il n'y a pas d'adresses, le serveur ne doit pas envoyer de réponse au client.

   Le serveur ignore les champs T1 et T2 dans les options IA et les champs preferred-lifetime et valid-lifetime dans les options IA Address.

   Le serveur construit un message Reply en mettant msg-type à REPLY, et copie le transaction-id depuis le message Confirm.

   Le serveur doit inclure les options Server Identifier et Client Identifier. Les server inclus une option Status Code indiquant le status du message Confirm.

Réception des messages Renew

   Quand le serveur reçoit un message Renew via unicast d'un client auquel le serveur n'a pas envoyé d'option unicast, le serveur répond avec un code de status UseMulticast.

   Quand le serveur reçoit un message Renew qui contient une option IA d'un client, il localise la liaison du client et vérifie que les informations client dans l'IA correspondent au informations stockées.

   Si le serveur ne peut pas trouver d'entrée cliente pour l'IA, le serveur retourne l'IA ne contenant aucune adresse avec un Status NoBinding.

   Si le serveur trouve les adresses dans l'IA pour le client, e serveur renvoie l'IA au client avec de nouveaux temps T1/T2. Le serveur peut choisir de changer la liste des adresses et les durées de vie des adresses dans les IA qui sont retournés au client.

   Le serveur construit un message Reply en mettant msg-type à REPLY, en copiant le transaction-id depuis de message Renew, inclus les options Server Identifier et Client Identifier, et inclus d'autres options contenant des informations de configuration.

Réception des messages Rebind

   Quand le serveur reçoit un message Rebind qui contient une option IA d'un client, il localise la liaison du client et vérifie que les information dans l'IA correspondent aux informations stockées.

   Si le serveur ne peut pas trouver d'entrée client pour l'IA et que le serveur détermine que les adresses dans l'IA ne sont pas appropriés pour le lien sur lequel l'interface client est attachée, en accord avec la configuration du serveur, le serveur peut envoyer un message Reply au client contenant l'IA du client, avec les durées de vie pour ces adresses à 0. Ce Reply constitue une notification explicite au client que les adresses dans l'IA ne sont plus valides. Dans cette situation, si le serveur n'envoie pas de message Reply, il supprime silencieusement le message Rebind.

   Si le serveur trouve qu'une des adresses n'est plus appropriée pour le lien auquel le client est attaché, le serveur retourne l'adresse au client avec une durée de vie de 0.

   Si le serveur trouve les adresses dans l'IA pour le client, le serveur devrait retourner l'IA au client avec les nouvelles durées de vie et les temps T1 et T2.

   Le serveur construit un message Reply en définissant msg-type à REPLY, et en copiant le transaction-id du message Rebind.

   Le serveur doit inclure une option Server Identifier et l'option Client Identifier.

   Le serveur inclus d'autres options contenant les informations de configuration à retourner au client.

Réception des messages Information-Request

   Quand le serveur reçoit un message Information-Request, le client demande des informations de configuration qui n'incluent pas l'assignement d'adresses. Le serveur détermine tous les paramètres de configuration appropriés au client, basé sur la stratégie de configuration du serveur.

   Le serveur construit un message Reply en définissant msg-type à REPLY, et en copiant le transaction-id.

   Le serveur doit inclure l'option Server identifier, et si le client l'a fournis, l'option Client Identifier.

   Le serveur inclus les options contenant les informations de configuration à retourner au client.

   Si le message Information-request reçus du client n'inclus pas l'option Client Identifier, le serveur devrait répondre avec un Reply contenant tous les paramètres de configuration qui ne sont pas déterminés par l'identité du client. Si le serveur choisis de ne pas répondre, le client peut continuer de retransmettre le message Information-request indéfiniment.

Réception des messages Release

   Quand le serveur reçoit un message Release via unicast depuis un client auquel le serveur n'a pas envoyé d'option unicast, le serveur supprime le message et répond avec un status UseMulticast, une option Server Identifier et l'option Client Identifier.

   À la réception d'un message Release valide, le serveur examine les IA et les adresses dans les IA. Si les IA dans le messages sont dans une liaison pour le client, et que les adresses dans les IA ont été assignées par le serveur à ces IA, le serveur supprime les adresse des IA et les rend de nouveau disponible. Le serveur ignore les adresses non assignées à l'IA, bien qu'il peut choisis de logger les erreurs.

   Une fois toutes les adresses traitées, le serveur génère un message Reply et inclus le status Success, Server Identifier et Client Identifier. Pour chaque IA dans le message Release pour lequel le serveur n'a pas de liaison, le serveur inclus un status NoBinding dans l'option IA. Aucune autre option n'est incluse dans l'option IA.

   Un serveur peut choisir de garder un enregistrement des adresses assignées et des IA après que les durées de vie aient expirées pour permettre au serveur de réassigner les adresse précédemment assignées à un client.

Réception de messages Decline

   Quand le serveur reçoit un message Decline via unicast depuis un client auquel le serveur n'a pas envoyer d'option unicast, il répond avec un status UseMulticast.

   À la réception d'un message Decline valide, le serveur examine les IA et les adresses dans les IA. Si les IA dans le message sont dans une liaison pour le client, et que les adresses dans les IA ont été assignés par le serveur pour ces IA, le serveur supprime les adresses depuis les IA. Le serveur ignore les adresses non assignées à l'IA.

   Le client a trouvé toutes les adresses dans le message Decline comme étant déjà utilisé sur son lien. Cependant, le serveur devrait marquer les adresses déclinée par le client pour que les adresses ne soient pas assignées à d'autres clients, et peut choisir de créer une notification indiquant que ces adresses ont été déclinées. La stratégie locale du serveur détermine quand les adresses identifiées dans un message Decline peuvent être disponible pour l'assignement.

   Une fois toutes les adresse traitées, le serveur génère un message Reply et inclus une option Status Code avec la valeur Success, d'option Server Identifier, et Client Identifier. Pour chaque IA dans le message Decline pour lequel le serveur n'a pas d'information de liaison, le serveur ajoute une option IA pour laquelle le serveur n'a pas d'information de liaison, avec un status NoBinding. Aucune autre option n'est incluse dans l'option IA.

Transmission des messages Reply

   Si le message original a été reçu directement par le serveur, le serveur unicast le message Reply directement au client en utilisant l'adresse source du message reçu. Le message Reply doit être unicasté via l'interface dans laquelle le message original a été reçu.

   Si le message original a été reçu dans un message Relay-forward, le serveur construit un message Relay-reply avec le message Reply dans le payload d'une option Relay Message. Si les messages Relay-forward incluaient une option interface-id, le serveur copie cette option dans le message Relay-reply. Le serveur unicast le message Relay-reply directement à l'agent relay en utilisant l'adresse source du message Relay-forward.

Échange de configuration initié par le serveur

   Un serveur initie un échange de configuration pour forcer les clients DHCP à obtenir de nouvelles adresses IP et d'autres informations de configuration. Par exemple, un administrateur peut utiliser un échange de configuration initié par le serveur quand les liens dans le domain DHCP doivent être rénumérotés. D'autres exemples incluent les changements d'emplacement des services d'annuaire, l'ajout de nouveaux services tels que l'impression, et la disponibilité de nouveaux logiciels.

Comportement du serveur

   Un serveur envoie un message Reconfigure pour forcer un client à initier immédiatement un Renew/Reply ou un échange Information-request/Reply avec le serveur.

Création et transmission de messages Reconfigure

   Le serveur met msg-type à RECONFIGURE. Le serveur met le champ transaction-id à 0. Le serveur inclus une option Server Identifier, et une option Client Identifier dans le message Reconfigure.

   Le serveur peut inclure une option Option Request pour informer le client des informations qui ont été changés ou les nouvelles informations qui ont été ajoutées. En particulier, le serveur spécifie l'option IA dans l'option Option Request si le serveur souhaite que le client obtienne une nouvelle adresse. Si le serveur identifie l'option IA dans l'option Option Request, le serveur doit inclure une option IA qui ne contient pas d'autres sous-options pour identifier chaque IA qui doit être reconfigurée dans le client.

   À cause du risque d'attaques DDOS contre les client DHCP, l'utilisation d'un mécanisme de sécurité est obligatoire dans les messages Reconfigure. Le serveur doit utiliser l'authentification DHCP dans le message Reconfigure.

   Le serveur doit inclure une option Reconfigure Message pour sélectionner si le client répond avec un message Renew ou un message Information-request.

   Le serveur ne doit pas inclure d'autres options dans le Reconfigure excepté si spécifiquement permis dans la définition des options individuelles.

   Un serveur envoie chaque message Reconfigure à un simple client DHCP, en utilisant une adresse unicast de scope suffisant. Si le serveur n'a pas d'adresse à laquelle envoyer le message Reconfigure directement, le serveur utilise un message Relay-reply et envoie le message Reconfigure à un agent relais qui va relayer le message au client. Le serveur peut obtenir l'adresse du client et de l'agent relais si requis, via l'information du serveur sur les clients qui sont en contact avec le serveur, ou via un agent externe.

   Pour reconfigurer plus d'un client, le serveur unicast un message séparé à chaque client. Le serveur peut initier la reconfiguration de plusieurs clients simultannément; par exemple, un serveur peut envoyer un message Reconfigure à des clients additionnels pendant que d'autres échanges de reconfiguration sont en cours.

   Le message Reconfigure force le client à initier un échange Renew/Reply ou Information-request/Reply avec le serveur. Le serveur interprète la réception d'un message Renew ou Information-request du client comme satisfaisant le message Reconfigure.

Timout et retransmission des messages Reconfigure

   Si le serveur ne reçoit pas de message Renew ou Information-Request du client dans les REC_TIMEOUT ms, le serveur retransmet le message Reconfigure, double de temps REC_TIMEOUT et attend de nouveau. Le serveur continue ce processus jusqu'à REC_MAX_RC tentative infructueuse, auquel cas le serveur devrait annuler le processus de reconfiguration pour ce client.

Réception des messages Renew

   Le serveur génère et envoie un message Reply au client, incluant les options pour les paramètres de configuration. Le serveur peut inclure des options contenant les IA et de nouvelles valeurs pour d'autres paramètres de configuration dans le message Reply, même si ces IA et paramètres ne sont pas demandés dans le message Renew du client.

Réception des messages Information-request

   Le serveur génère et envoie un message Reply au client, incluans les options pour les paramètres de configuration. Le serveur peut inclure des options contenant de nouvelles valeurs pour d'autres paramètre même si ces paramètres n'ont pas été demandé par le client.

Comportement client

   Un client reçoit des messages Reconfigure envoyés au port UDP 546 sur les interfaces pour lesquelles il a acquis les informations de configuration via DHCP. Ces messages peuvent être envoyés à tout moment. Vu que le résultat d'une reconfiguration peut affecter les programmes de la couche application, le client devrait logger ces événements, et peut notifier les programmes des changements.

Réception des messages Reconfigure

   À la reception d'un message Reconfigure valide, le client répond avec soit un message Renew soit un message Information-request. Le client ignore le champ transaction-id dans le message Reconfigure. pendant que la transaction est en progression, le client supprime silencieusement tout message Reconfigure reçus.

Création et transmission des messages Renew

   En répondant à un Reconfigure, le client créé et envoie le message Renew exactement de la même manière que décris dans la section "création et transmission des messages Renew", à l'exception que le client copie l'option Option Request et les options IA du message Reconfigure dans le message Renew.

Création et transmission des messages Information-request

   En répondans à un message Reconfigure, le client créé et envoie le message Information-request exactement comme dans la section "création et transmission des messages Information-request", à l'exception que le client inclus une option Server Identifier avec l'identifiant du message Reconfigure.

Timeout et retransmission des messages Renew et Information-request

   Le client utilise les même variables et algorithmes de retransmission qu'avec les messages Renew et Information-request générés par un échange initié par le client. Si le client ne reçoit pas de réponse du serveur à la fin du processus de retransmission, le client ignore et supprime le message Reconfigure.

Réception des messages Reply

   À la reception d'un message Reply valide, le client traite les options et définis ou réinitialise les paramètres de configuration. Le client enregistre et met à jours la durée de vie des adresse spécifiées dans les IA dans le message Reply.

Comportement de l'agent relais

   L'agent relais peut être configuré pour utiliser une liste d'adresses de destination, qui peut inclure des adresse unicast, l'adresse All_DHCP_Servers, ou d'autres adresses sélectionnées par l'administrateur réseau. Si l'agent relais n'a pas été expicitement configuré, il doit utiliser l'adresse All_DHCP_Servers. Si l'agent relais relaye les messages à l'adresse All_DHCP_Servers ou d'autres adresses multicast, il définis le champ Hop Limit à 32.

Relayer un message client ou un message Relay-forward

   Un agent relais relaye les messages des client et les messages Relay-forward depuis d'autres agents relais. Quand un agent relais reçoit un message valide à relayer, il construit un nouveau message Relay-forward. L'agent relais copie l'adresse source de l'en-tête IP du message reçus dans le champ peer-address du message Relay-forward. L'agent relais copie le message DHCP reçu dans une option Relay Message dans le nouveau message. L'agent relais ajoute d'autres options s'il est configuré pour les inclure.

Relayer un message du client

   Si l'agent relais reçoit le message à relayer depuis un client, il place une adresse de scope globale ou de site avec un préfixe assigné au lien sur lequel le client devrait reçevoir une adresse dans le champ link-address. Cette adresse sera utilisée par le serveur pour déterminer le lien sur lequel le client devrait reçevoir une adresse et d'autres informations de configuration. Le Hop-Count est mis à 0.

   Si l'agent relais ne peut pas utiliser l'adresse dans le champ link-address pour identifier l'interface via laquelle la réponse au client sera relayé, l'agent relais doit inclure une option Interface-id dans le message Relay-forward. Le serveur inclus l'option Interface-id dans son message Relay-reply. L'agent relais remplissent le champ link-address tel que décris dans le paragraphe précédent sans regarder s'il inclus une option Interface-id dans le message Relay-forward.

Relayer un message depuis l'agent relais

   Si le message reçus par l'agent relais est un message Relay-forward et le hop-count est supérieur ou égal à HOP_COUNT_LIMIT, l'agent relais supprime le message.

   L'agent relais copie l'adresse source de l'en-tête IP dans lequel le message a été reçus du client dans le champ peer-address dans le message Relay-forward et met le hop-count à la valeur du champs hop-count du message reçu, incrémenté de 1.

   Si l'adresse source de l'en-tête IP du message reçus est une adresse global ou de site, l'agent relais met le champ link-address à 0; sinon l'agent relais met le champ link-address à l'adresse global ou de site assigné à l'interface sur laquelle le message a été reçu, ou inclus une option Interface-ID pour identifier l'interface sur laquelle le message a été reçu.

Relayer un message Relay-reply

   L'agent relais traite les options incluses dans le message Relay-reply en plus de l'option Relay Message, puis supprime ces options.

   L'agent relais extrait le message de l'option Relay Message et le transmet à l'adresse contenu dans le champ peer-address du message Relay-reply.

   Si le message Relay-reply inclus une option Interface-ID, l'agent relais transmet le message du serveur au client sur le lien identifié. Sinon, si le champ link-address n'est pas à 0, l'agent relais transmet le message sur le lien identifié par le champ link-address.

Construction des message Relay-reply

   Un serveur utilise un message Relay-reply pour retourner une réponse à un client si le message original du client a été relayé au serveur dans un message Relay-forward ou pour enoyer un message Reconfigure au client si le serveur n'a pas d'adresse utilisable pour envoyer le message directement.

   Une réponse au client doit être relayée via le même agent relais que le message original. Le serveur créé un message Relay-reply qui inclus une option Relay Message contenant le message pour l'agent relais suivant dans le chemin de retour au client. Le message Relay-reply contient une autre option Relay Message à envoyer au prochain agent relais, et ainsi de suite. Le serveur doit enregistrer le contenu des champs peer-address dans le message reçu pour construire le message Relay-reply approprié.

   Par exemple, si le client C envoie un message relayés par l'agent relais A au relais B puis au serveur, le serveur envoie le message Relay-reply à l'agent relais B:

msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, contenant:

        msg-type: RELAY-REPLY
        hop-count: 0
        link-address: address from link to which C is attached
        peer-address: C
        Relay Message option: ‹response from server›

   En envoyant un message Reconfigure à un client via un agent relais le serveur créé un message Relay-reply qui inclus une option Relay Message contenant le message Reconfigure pour le prochain agent relais dans le chemin de retour au client. Le serveur met le champs peer-address dans l'en-tête du message Relay-repy à l'adresse du client, et met le champ link-address tel que requis par l'agent relais pour relayer le message Reconfigure au client. Le serveur obtient les adresses du client et de l'agent relais avant l'intéraction avec le client ou via un mécanisme externe.

Authentification des messages DHCP

   Certains administrateurs réseaux peuvent souhaiter fournir l'authentification de la source et du contenu des messages DHCP. Par exemple, les client peuvent être sujets à des attaques par refus de service via l'utilisation de serveurs faux DHCP, ou par des serveurs mal configurés. Les administrateurs réseau peuvent souhaiter contraindre l'allocation des adresses aux hôtes autorisés pour éviter les attaques DOS.

Sécurité des messages envoyés entre les serveurs et agents relais

   Les agents relais et les serveurs qui échangent des messages sécurisés utilisent les mécanismes IPsec pour IPv6. Si un message client est transféré via plusieurs agents relais, chaque agent relais doit avoir une relation de confiance établis. Les agents relais et les serveurs utilisent IPsec sous les conditions suivantes:

Selectors Les agents relais sont manuellement configurés avec les adresses de l'agent relais ou serveur auxquels les messages DHCP sont forwardés. Chaque agent relais et serveur qui utilise IPsec pour sécuriser les messages DHCP doit également être configuré avec une liste d'agents relais auxquels les messages sont transmis. Les sélecteurs pour les agents relais et serveurs échangent des messages DHCP sur les port UDP 546 et 547.
Mode Les agents relais et les serveurs utilisent le mode transport et ESP. Les informations dans les messages DHCP ne sont généralement pas considérés confidentiels, donc le chiffrement n'est pas utilisé.
Gestion de clé Parce que les agents relais et les serveurs sont utilisés dans une organisation, les schémas à clé publique ne sont pas nécessaires. Parce que les agents relais et les serveurs doivent être configurés manuellement, la gestion de clé manuelle peut suffire, mais n'offre pas de défense contre les messages rejoués. IKE avec des clé pré-partagés devraient être supportés. IKE avec des clés publiques peut être supporté.
Stratégie de sécurité Les messages DHCP entre les agents relais et les serveurs devraient seulement être acceptés des paires DHCP tel qu'identifié dans la configuration locale
Authentification Les clés partagées, indexées à l'adresse IP source du message DHCP reçus, sont adéquats dans cette application
Disponibilité Les implémentations IPsec appropriées sont disponibles pour les serveurs et agents relais dans des périphériques plus récents dans l'entreprise.

Sommaire de l'authentification DHCP

   L'authentification des messages DHCP est accomplis via l'utilisation de l'option Authentication. Les informations d'authentification dans cette option peuvent être utilisées pour identifier de manière fiable la source d'un message DHCP et pour confirmer que le contenu du message DHCP n'a pas été altéré.

   L'option Authentication fournis un framework pour plusieurs protocoles d'authentification. 2 sont définis ici. Tout message DHCP ne doit pas inclure plus d'une option Authentication.

   Le champ protocole dans l'option Authentication identifie le protocole spécifique utilisé pour générer les informations d'authentification dans l'option. Le champ algorithm identifie un algorithme spécifique dans le protocole d'authentification; par exemple, le champ algorithm spécifie l'algorithme de hashage utilisé pour générer le MAC dans l'option authentication. Le champ Replay Detection Method (RDM) spécifie le type de détection utilisé.

Détection de répétition

   Le champ Replay Detection Method (RDM) détermine le type de détection de répétition utilisé dans le champ Replay Detection.

   Si le champ RDM contient 0x00, le champ Replay Detection doit être mis à la valeur d'un compteur monotonique incrémental. Utiliser un compteur, tel que la date courante, peut réduire le risque d'attaques. Cette méthode doit être supporté par tous les protocoles.

Protocole d'authentification retardé

   Si le champ protocole est 2, le message utilise le mécanisme "delayed authentication". Dans l'authentification retardée, le client demande une authentification dans son message Solicit, et le serveur répond avec un message Advertise qui inclus l'authentification. Cette information d'authentification contient une valeur nonce générée par la source comme un MAC pour fournir une authentification du message et de l'entité. L'utilisation d'une technique particulière basée sur HMAC en utilisant MD5 est définis ici.

Option Authentication dans le protocole Delayed Authentication

   Dans un message Solicit, le client remplis les champs protocol, algorithm et RDM dans l'option Authentication avec les préférences du client. Le client met le champ replay detection à 0 et omet le champ authentication information. Le client met le champ option-len à 11.

   Dans tous les autres messages, les champs protocol et algorithm identifient la méthode utilisée pour construire le contenu du champ authentication information. Le champ RDM identifie la méthode utilisée pour construire le contenu du champ replay detection. Le format de Authentication information est:

DHCP realm Le royaume DHCP qui identifie la clé utilisée pour générer la valeur HMAC-MD5
key ID L'identifiant de clé qui identifie la clé utilisée pour générer la valeur HMAC-MD5
HMAC-MD5 Le MAC généré en appliquant un MD5 au message DHCP en utilisant l'identifiant de clé par le DHCP realm, client DUID, et key ID.

   L'émeteur calcule le MAC en utilisant l'algorithme de génération HMAC et la fonction de hashage MD5. Tout de message DHCP, incluant l'en-tête et les options, sont utilisé comme entrée dans la fonction de calcul MD5

Validation du message

   Tout message DHCP qui inclus plus d'une option authentication doit être détruit.

   Pour valider un message entrant, le receveur vérifie d'abord que la valeur dans le champ replay detection est acceptable en accord avec la méthode spécifiée dans le champ RDM. Ensuite, le reçeveur calcule le MAC. Tout le message est utilisé en entrée de la fonction MAC, en mettant le champ MAC à 0. Si le MAC calculé ne correspond pas avec celui reçu, le reçeveur détruit le message DHCP.

Utilisation de clé

   Chaque client DHCP a un jeu de clés. Chaque clé est identifié par ‹DHCP realm, client DUID, key id›. Chaque clé a également une durée de vie. La clé ne peut pas être utilisé avant la fin de sa durée de vie. Les clés du client sont initialement distribuées au client via un mécanisme tiers. La durée de vie pour chaque clé est distribuée avec la clé.

   Le client et le serveur utilise une des clés du client pour authentifier les messages DHCP durant une session (jusqu'au prochain message Solicit envoyé par le client).

Considération client pour le protocole d'authentification retardé

   Le client annonce son intention d'utiliser l'authentification DHCP en incluant une option Authentication dans son message Solicit. Le serveur séléctionne une clé pour le client basé sur le DUID du client. Le client et le serveur utilisent cette clé pour authentifier tous les messages DHCP échangés durant la session.

Envoyer des messages Solicit

   Quand le client envoie un message Solicit et souhaite utiliser l'authentification, il inclus une option Authentication avec le protocole désiré, l'algorithme et RDM. Le client n'inclus pas replay detection ni authentication information dans l'option Authentication.

Recevoir les messages Advertise

   Le client valide tous message Advertise contenant une option Authentication spécifiant le protocole d'authentication retardé en utilisant le teste de validation.

   Le comportement de client si aucun message Advertise n'inclus d'information d'authentification ou ne passe le test de validation, est contrôlé par sa stratégie locale.

   Un client doit être configurable pour supprimer les messages non-authentifiés et devrait être configuré par défaut pour les supprimer si le client a été configuré avec une clé d'authentification.

Envoyer des messages Request, Confirm, Rebind, Decline ou Release

   Si le cilent a authentifié le message Advertise avec lequel le client a séléctionné le serveur, le client doit générer les informations d'authentification pour les messages suivants. Quand le client envoie un message, il doit utiliser la même clé utilisée par le serveur pour générer les informations d'authentification.

Envoyer des messages Information-request

   Si le serveur a séléctionné une clé pour le client dans un échange précédent, le client doit utiliser la même clé durant la session.

Reçevoir des messages Reply

   Si le client a authentifié le Advertise qu'il accepte, le client doit valider le message Reply associé depuis le serveur. Le client doit détruire le Reply si le message échoue le test de validation et peut logger l'erreur. Si le Reply échoue le test, le client doit redémarrer le processus de configuration DHCP en envoyant un message Solicit.

Considération serveur

   Une fois reçus un message Solicit qui contient une option Authentication, le serveur détecte une clé pour le client, basée sur le DUID du client et la stratégie de sélection de clé. Le serveur identifie la clé séléctionnée dans le message Advertise et utilise la clé pour valider tous les autres messages reçus.

Réception de Solicit et envoie de Advertise

   Le serveur séléctionne une clé pour le client et inclus les informations d'authentification dans le message Advertise retourné au client. Le serveur doit enregistrer l'identifiant de la clé séléctionnée pour le client et utilise cette clé pour valider tous les autres messages échangés avec le client.

Réception de Request, Confirm, Renew, Rebind, Release et envoie de Reply

   Le serveur utilise l'identifiant de clé dans le message et valide le message. Si le message échoue le test ou le serveur ne connaît pas l'identifiant de clé, le serveur doit détruire le message et peut logger l'erreur.

   Si le message passe le test, le serveur répond au message en incluant les informations d'authentification générées en utilisant la clé identifiée dans le message reçu.

Protocole de reconfiguration de clé d'authentification

   Ce protocole fournis une protection contre les mauvaises configurations d'un client causé par un message Reconfigure envoyé par un serveur DHCP malicieux. Dans ce protocole, un serveur DHCP envoie un Reconfigure Key au client dans l'échange initial. Le client enregistre le Reconfigure Key à utiliser pour authentifier les messages Reconfigure suivants de ce serveur. Le serveur inclus un HMAC calculé depuis le Reconfigure Key dans les messages Reconfigure suivants.

   Le Reconfigure Key envoyé par le serveur et le HMAC dans les messages Reconfigure suivants sont gérés dans une option Authentication. Le protocole Reconfigure Key est utilisé seulement si le client et le serveur n'utilisent pas d'autres protocole d'authentification et que le client et le serveur ont négocié l'utilisation des messages Reconfigure.

   Les champs suivants sont mis dans une option Authentication pour le protocole d'authentification Reconfigure Key:

protocol 3
algorithm 1
RDM 0

   Le format des informations d'authentification pour le Reconfigure Key Authentication Protocol contient un champ Type sur 1 octet contenant le type dans le champ Value (1=Reconfigure Key, utilisé dans la réponse,2=HMAC-MD5 du message, utilisé dans un message Reconfigure). Le champ Value contient les données.

Considérations serveur pour le protocole Reconfigure Key

   Le serveur séléctionne un Reconfigure Key pour un client durant un échange Request/Reply, Solicit/Reply ou Information-request/Reply. Le serveur enregistre le Reconfigure Key et transmet cette clé au client dans une option Authentication dans le Reply. Le Reconfigure Key fait 128bits de long, et doit être un nombre aléatoire cryptographiquement fort.

   Pour fournir l'authentification pour un message Reconfigure, le serveur sélectionne une valeur replay detection en accord avec le RDM séléctionné par le serveur, et calcul un HMAC-MD5 du message Reconfigure en utilisant le Reconfigure Key pour le client. Le serveur calcul le HMAC-MD5 sur tout le message Reconfigure, incluant l'option Authentication; le champ HMAC-MD5 est mis à 0. Le serveur inclus le HMAC-MD5 dans le champ authentication information dans une option Authentication inclus dans le message Reconfigure envoyé au client.

Considérations client pour le protocole Reconfigure Key

   Le client reçoit un Reconfigure Key du serveur dans le message Reply initial du serveur. Le client enregistre le Reconfigure Key à utiliser dans les messages Reconfigure suivants.

   Pour authentifier un message Reconfigure, le client calcul un HMAC-MD5 du message DHCP en utilisant le Reconfigure Key reçus du serveur. Si le HMAC-MD5 calculé correspond avec la valeur dans l'option Authentication, le client accepte le message Reconfigure.

Options DHCP

   Les options sont utilisées pour qérer des informations additionnelles et paramètres dans les messages DHCP. Toutes les options partagent une base commune. Ce document décris les options DHCP de base de la spécification DHCP. D'autres options peuvent être définies dans des documents séparées.

   Sauf mention, chaque option peut apparaître seulement dans la zone d'options et peut apparaître seulement une seule fois.

Format des options

Le format des options DHCP est:
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________option-code__________|___________option-len__________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________________________option-data__________________________|
|______________________(option-len_octets)______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code Un entier non-signé identifiant le type d'option.
option-len Un entier non-signé donnant la longueur du champ option-data
option-data Les données pour l'option

Client Identifier

   L'option Client Identifier est utilisé pour spécifier un DUID identifiant un client.

option-code OPTION_CLIENTID (1)
option-len Longueur du DUID en octets
DUID Le DUID du client.

Serveur Identifier

   L'option Serveur Identifier est utilisé pour spécifier un DUID identifiant un serveur.

option-code OPTION_SERVERID (2)
option-len Longueur du DUID en octets
DUID Le DUID du serveur

Identity Association for Non-temporary Addresses

   Gère un IA_NA, les paramètres associés et les adresses non-temporaires associées.

option-code OPTION_IA_NA (3)
option-len 12 + longueur du champ IA_NA-options
IAID Identifiant unique pour cet IA_NA.
T1 Temps auquel le client contacte le serveur auprès duquel l'IA_NA a été obtenus pour étendre la durée de vie, exprimée en secondes
T2 Temps auquel le client contacte un serveur disponible pour étendre la durée de vie des adresses assignée.
IA_NA-options Options associées avec cet IA_NA

   Noter qu'un IA_NA n'a pas de durée de vie associée. Dans un message envoyé par le client, les temps T1 et T2 sont les préférences du client.

Identity Association for Temporary Addresses

   Gère un IA_TA, les paramètres associés et les adresses temporaire associées.

option-code OPTION_IA_TA (4)
option-len 4 + longueur du champ IA_TA-options
IAID Identifiant unique pour cet IA_TA
IA_TA-options Options associées avec cet IA_TA

   Quand la durée de vie de toutes les adresses dans un IA_TA ont exprirés, l'IA peut être considéré comme expiré.

IA Address

   L'option IA Address est utilisée pour spécifier les adresses IPv6 associées avec un IA_NA ou un IA_TA. Cette option doit être encapsulée dans le champ Option pour une option IA_NA ou IA_TA.

option-code OPTION_IAADDR (5)
option-len 24 + longueur du champ IAaddr-options
IPv6 address Une adresse IPv6
Preferred-lifetime Durée de vie préférrée pour l'adresse, en secondes
valid-lifetime Durée de vie valide pour l'adresse, en secondes
IAaddr-options Options associées avec cette adresse

Option Request

   Utilisé pour identifier une liste d'options dans un message entre un client et un serveur.

option-code OPTION_ORO (6)
option-len 2*nombre d'options demandées
requested-option-code-n Le code d'option demandé.

Preference

   Cette option est envoyée par un serveur à un client pour affecter la sélection d'un serveur par le client.

option-code OPTION_PREFERENCE (7)
option-len 1
pref-value La valeur de préférence pour le serveur dans ce message

Elapsed Time

option-code OPTION_ELAPSED_TIME (8)
option-len 2
elapsed-time Durée depuis que le client a commencé sa transaction DHCP. exprimé en centièmes de secondes

Relay Message

   Transporte un message DHCP dans un message Relay-forward ou Relay-reply

option-code OPTION_RELAY-MSG (9)
option-len Longueur du DHCP-relay-message
DHCP-relay-message Le message DHCP à relayer.

Authentication

   Gère les informations d'authentification pour authentifier l'identité et le contenu des messages DHCP.

option-code OPTION_AUTH (11)
option-len 11 + Longueur du champ information
protocol Protocole utilisé
algorithm Algorithme utilisé
RDM Méthode de détection de rejeu.
Replay detectsion Information de détection pour le RDM
authentication information L'information d'authentification tel que spécifié par protocol et algorithm

Server Unicast

   Le serveur envoie cette option à un client pour indiquer que le client est autorisé à unicast les messages au serveur.

option-code OPTION_UNICAST (12)
option-len 16
server-address L'adresse IP où envoyer les messages

Status Code

   Retourne le status lié au message ou l'option dans laquelle elle apparaît.

option-code OPTION_STATUS_CODE (13)
option-len 2 + longueur du status-message
status-code code de status
status-message Chaîne UTF-8 à afficher à l'utilisateur. ne doit pas se terminer par une NULL.

Rapid Commit

   Utilisé pour signaler l'utilisation d'un échange 2 messages.

option-code OPTION_RAPID_COMMIT (14)
option-len 0

User Class

   Utilisé par un client pour identifier le type ou la catégorie d'utilisateur ou d'applications qu'il représente

option-code OPTION_USER_CLASS (15)
option-len Longueur du champ user-class-data
user-class-data Classes utilisateur envoyé par le client

Vendor Class

   Utilisé par un client pour identifier le vendeur du hardware sur lequel le client fonctionne.

option-code OPTION_VENDOR_CLASS (16)
option-len 4 + longueur de vendor-class-data
enterprise-number Enterprise Number du vendeur
vendor-class-data Configuration hardware de l'hôte

Vendor-specific Information

   Utilisé par les clients et serveur pour échanger des informations spécifiques au client

option-code OPTION_VENDOR_OPTS (17)
option-len 4 + longueur de option-data
enterprise-number Enterprise Number du vendeur
option-data object opaque interprété par le code spécifique au vendeur

Interface-Id

   L'agent relais peut envoyer l'option Interface-Id pour identifier l'interface sur laquelle le message client a été reçu.

option-code OPTION_INTERFACE_ID (18)
option-len longueur de interface-id
interface-id Valeur opaque générée par l'agent relais pour identifier un de ses interfaces.

Reconfigure Message

   Un serveur inclus une option Reconfigure Message dans un message Reconfigure pour indiquer au client si le client réponds avec un message Renew ou un message Information-request.

   option-code
   option-len
   msg-type

Reconfigure Accept

   Un client utilise cette option pour annoncer au serveur qu'il accept les messages Reconfigure, et le serveur l'utilise pour indiquer au client s'il accepte les message Reconfigure.

option-code OPTION_RECONF_ACCEPT
option-len 0

Adresses Multicast

All_DHCP_Relay_Agents_and_Servers address FF02::1:2
All_DHCP_Servers address FF05::1:3

Types de messages DHCP

SOLICIT 1
ADVERTISE 2
REQUEST 3
CONFIRM 4
RENEW 5
REBIND 6
REPLY 7
RELEASE 8
DECLINE 9
RECONFIGURE 10
INFORMATION-REQUEST 11
RELAY-FORW 12
RELAY-REPL 13

Options DHCP

OPTION_CLIENTID 1
OPTION_SERVERID 2
OPTION_IA_NA 3
OPTION_IA_TA 4
OPTION_IAADDR 5
OPTION_ORO 6
OPTION_PREFERENCE 7
OPTION_ELAPSED_TIME 8
OPTION_RELAY_MSG 9
OPTION_AUTH 11
OPTION_UNICAST 12
OPTION_STATUS_CODE 13
OPTION_RAPID_COMMIT 14
OPTION_USER_CLASS 15
OPTION_VENDOR_CLASS 16
OPTION_VENDOR_OPTS 17
OPTION_INTERFACE_ID 18
OPTION_RECONF_MSG 19
OPTION_RECONF_ACCEPT 20

Codes de status

Success 0 Succès
UnspecFail 1 Erreur, raison non spécifiée
NoAddrsAvail 2 Le serveur n'a pas d'adresses disponible à assigner aux IA
NoBinding 3 Enregistrement client non disponible
NotOnLink 4 Le préfix pour l'adresse n'est pas approprié pour le lien sur lequel le client est attaché
UseMulticast 5 Indique au client d'utiliser multicast.
^
01 décembre 2014

htmlpdflatexmanmd




rfc3370

rfc3370

Algorithmes de Syntaxe de message cryptographique

Introduction

   CMS est utilisé pour signer, hasher, authentifier, ou chiffrer numériquement des messages. Ce document décris l'utilisation des algorithmes utilisés communément avec CMS. Les implémentations de CMS peuvent supporter ces algorithmes; et peuvent également supporter d'autres algorithmes. Cependant, si une implémentation choisis de supporter un des algorithmes décris dans ce document, l'implémentation doit le faire comme décris dans ce document.

   Les valeurs CMS sont générées en utilisant ASN.1, encodé BER. Les identifiants d'algorithmes ( qui incluent les identifiants d'objets ASN.1) identifient les algorithmes de cryptographiques, et certains algorithmes nécessitent des paramètres additionnels. Quand nécessaire, les paramètres sont spécifiés avec une structure ASN.1. L'identifiant d'algorithme pour chaque algorithme est spécifié, et que nécessaire, la structure de paramètres est spécifiée. Les champs dans le CMS employé par chaque algorithme sont identifié.

Changements depuis la rfc 2630

   Ce document obsolète la section 12 de la rfc 2630. La séparation des spécification du protocole et des algorithmes permet à chacun d'être mis à jours sans impacter d'autre. Cependant, les conventions pour utiliser des algorithmes additionnels avec CMS sont spécifiés dans des documents séparés.

Algorithmes de hashage

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent SHA-1 ou MD5. Les identifiants d'algorithmes de hashage sont localisés dans le champ digestAlgorithms du SignedData, le champ digestAlgorithm du SignerInfo, le champ digestAlgorithm du DigestedData, et le champ digestAlgorithm du AuthenticatedData.

   Les valeurs de hash sont placés dans le champ DigestedData et l'attribut authentifié messages-digest.

SHA-1

L'algorithme de hashage SHA-1 est définis dans FIPS pub 180-1. L'identifiant d'algorithme pour SHA-1 est:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

   Il y a 2 encodages possible pour le champ de paramètres AlgorithmIdentifier. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement. L'encodage correct est d'omettre le champ parameters; cependant, les implémentations doivent également gérer les champ parameters qui contiennent un NULL.

   Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir un NULL. Les implémentations doivent accepter un AlgorithmIdentifiers SHA-1 sans paramètres. Les implémentations doivent accepter AlgorithmIdentifiers SHA-1 avec un AlgorithmIdentifiers avec un parameters NULL. Les implémentations devraient générer des AlgorithmIdentifiers SHA-1 sans parameters.

MD5

L'algorithme de hashage MD5 est définis dans la rfc1321. L'identifiant d'algorithme pou MD5 est:
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }

   Le champ parameters de AlgorithmIdentifier doit être présent, et doit contenir NULL. Les implémentations peuvent accepter le AlgorithmIdentifiers MD5 avec parameters absent ou à NULL.

Algorithmes de signature

   Cette section spécifie les conventions employées par les implémentation CMS qui supportent DSA ou RSA. Les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo du SignedData. Également, les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo des attributs countersignatures. Les valeurs de signature sont localisées dans le champ signature du SignerInfo du SignedData. Également, les valeurs de signature dans le champ signature des attributs countersignature.

DSA

L'algorithme de signature DSA est définis dans FIPS Pub 186. DSA doit être utilisé avec l'algorithme SHA-1. L'identifiant d'algorithme DSA sujetà à clé publique dans les certificats est:
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 }

   La validation de signature DSA nécessite 3 paramètres, communément appelés p, q et g. Quand l'identifiant d'algorithme id-dsa est utilisé, le champ parameters de AlgorithmIdentifier est optionnel. Si présent, ce champ doit contenir les 2 valeurs de paramètre DSA encodés en utilisant le type Dss-Parms. Si absent, le sujet de la clé publique DSA utilise les même paramètres DSA que le fournisseur de certificat:


Dss-Parms ::= SEQUENCE {
    p INTEGER,
    q INTEGER,
    g INTEGER }

Quand l'identifiant d'algorithme id-dsa est utilisé, la clé publique DSA, communément appelée Y, doit être encodée en integer. La sortie de cet encodage est placé dans la clé publique du sujet du certificat:
Dss-Pub-Key ::= INTEGER -- Y

L'identifiant de l'algorithme DSA avec signature SHA-1 est:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

Quand l'identifiant de l'algorithme id-dsa-with-sha1 est utilisé, le champ de paramètres AlgorithmIdentifier doit être absent. En signant, l'algorithme DSA génère 2 valeurs, communément appelés r et s. Pour transférer ces 2 valeurs en tant que signature, il doivent être encodés en utilisant le type Dss-Sig-Value:
Dss-Sig-Value ::= SEQUENCE {
    r INTEGER,
    s INTEGER }

RSA

L'algorithme de signature RSA est définis dans la rfc2437, et spécifie l'utilisation de l'algorithme de signature RSA avec les algorithmes de hashage SHA-1 et MD5. L'identifiant d'algorithme pour les sujets de clé publique RSA dans les certificats est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

Quand l'identifiant d'algorithme rsaEncryption est utilisé, le champ parameters de AlgorithmIdentifier doit contenir NULL. Quand l'identifiant d'algorithme rsaEncryption est utilisé, la clé publique RSA, qui est composée d'un modulo et d'un exposant publique, doit être encodé en utilisant le type RSAPublicKey. La sortie de cet encodage est placé dans la clé publique du sujet du certificat.
RSAPublicKey ::= SEQUENCE {
    modulus INTEGER, -- n
    publicExponent INTEGER } -- e

   Les implémentations CMS qui incluent l'algorithme de signature RSA doivent implémenter l'algorithme de hashage SHA-1. De telles implémentations devraient également supporter l'agorithme MD5.

   L'identifiant d'algorithme rsaEncryption est utilisé pour identifier les valeurs de signature RSA sans regarder l'algorithme de hashage utilisé. Les implémentations CMS qui incluent l'algorithme de signature RSA doivent supporter l'identifiant d'algorithme de valeur de signature rsaEncryption, et les implémentations CMS peuvent supporter les identifiant d'algorithme de valeur de signature RSA et l'algorithme de hashage.

L'identifiant d'algorithme pour RSA avec signature SHA-1 est:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

L'identifiant d'algorithme pour RSA avec signature MD5 est:
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

   Quand les identifiants d'algorithme de signature rsaEncryption, sha1WithRSAEncryption, ou md5WithRSAEncryption sont utilisés, le champ parameters de AlgorithmIdentifier doit être NULL.

   En signant, l'algorithme RSA génère une seule valeur, et cette valeur est utilisée directement comme valeur de signature.

Algorithmes de gestion de clé

   CMS accueille les techniques de gestion de clé suivant: key agreement, key transport, previously distributed symmetric key-encryption keys, et passwords.

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent l'agrément de clé en utilisant X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) et X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).

   Quand un algorithme d'agrément de clé est utilisé, un algorithme de chiffrement de clé est également nécessaire. Donc, quand l'agrément de clé est supporté, un algorithme de chiffrement de clé doit être fournis pour chaque algorithme de chiffrement de contenu. Les algorithmes d'enveloppement de clé pour Triple-DES et RC2 sont décris dans la rfc3217.

   Pour l'agrément de clé des clés de chiffrement de clé RC2, 128bits doivent être générés en entrée du processus d'expansion de clé utilisé pour calculé la clé effective RC2.

   Les identifiants d'algorithme d'agrément de clé sont localisé dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les identifiants d'algorithme d'envelopement de clé sont localisés dans parameters de KeyWrapAlgorithm dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey. Les clés message-authentication enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

X9.42 Ephemeral-Static Diffie-Hellman

   L'agrément de clé Ephemeral-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Ephemeral-Static Diffie-Hellman, le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo est utilisé comme suit:

- la version doit être 3
- originator doit être l'alternative originatorKey. le champ algorithm de originatorKey doit contenir l'identifiant d'objet dh-public-number avec parameters absent. le champ publicKey de originatorKey doit contenir la clé publique éphémère de l'émetteur. l'identifiant d'objet dh-public-number est:


dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm peut être présent ou absent. Les implémentations CMS doivent supporter l'absence de ukm, et devraient supporter la présence d'ukm. Quand présent, ukm est utilisé pour s'assurer qu'une clé de chiffrement de clé est générée quand la clé privée éphémère doit être utilisée plus d'une fois.
- keyEncryptionAlgorithm doit être l'identifiant d'algorithme id-alg-ESDH. Le champ de paramètre d'identifiant d'algorithme pour id-alg-ESDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu ave la clé de chiffrement générée en utilisa l'algorithme d'agrément de clé X9.42 Ephemeral-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc3217. la syntaxe de l'identifiant d'algorithme id-alg-ESDH et ses paramètres est:


id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
    
KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et un clé chiffrée pour chaque destinataire. Le KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit RecipientKeyIdentifier contenant d'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Ephemeral-Static Diffie-Hellman générée en utilisant l'algorithme spécifié par le KeyWrapAlgorithm.

X9.42 Static-Static Diffie-Hellman

   L'agrément de clé Static-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Static-Static Diffie-Hellman, les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo sont utilisé comme suit:

- la version doit être 3
- originator doit être sost issuerAndSerialNumber soit subjectKeyIdentifier. Dans les 2 cas, le certificat de l'auteur contient la clé publique statique de l'émetteur. La rfc 3279 spécifie la syntaxe et les valeurs des paramètres AlgorithmIdentifier qui sont inclus dans le certificat de l'auteur. Le champ d'information de clé publique du certificat de l'auteur doit contenir l'identifiant d'objet dh-public-number:


dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm doit être présent. ukm s'assure qu'une clé de chiffrement de clé différente est générée pour chaque message entre les même émetteur et destinataire.
- keyEncryptionAlgorithm doit être d'identifiant d'algorithme id-alg-SSDH. Le champ parameter de d'identifiant d'algorithme pour id-alg-SSDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé générée en utilisant l'algorithme d'agrément de clé X9.42 Static-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc 3217. L'identifiant d'algorithme id-alg-SSDH et ses paramètres est:


id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
    
KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et une clé chiffrée pour chaque destinataire. KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit le RecipientKeyIdentifier contenant l'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Static-Static Diffie-Hellman générée en utilisant l'algorithme spécifiée par KeyWrapAlgorithm.

Algorithmes de transport de clé

   Cette section spécifie les conventions employés par les implémentations CMS qui supportent le transport de clé en utilisant RSA. Les identifiant d'algorithme de transport de clé sont localisé dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm. Les clé de chiffrement de contenu chiffrés par transport de clé sont localisés dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey.

RSA

L'algorithme de transport de clé RSA est le shéma de chiffrement RSA définis dans la rfc 2313, le type de block est 02, où le message à chiffrer est la clé de chiffrement de contenu. L'identifiant d'algorithme pour RSA est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   Le champ parameters de AlgorithmIdentifier doit être présent, et le champ parameters doit contenir NULL. En utilisant une clé de chiffrement de contenu Triple-DES, les implémentations CMS doivent ajuster les bits de parité pour chaque clé DES comprises dans la clé Triple-DES avant le chiffrement RSA.

   L'utilisation du chiffrement RSA, comme définis dans la rfc 2313, pour fournir la confidentialité a une vulnérabilité conue. La vulnérabilité est plus dans l'utilisation dans les application intéractives que dans les environnement de stockages. Dans informations et contre-mesure sont discutés dans la section considération de sécurité de ce document et la rfc3218.

   Noter que le même schéma de chiffrement RSA est également définis dans la rfc 2437, qui est appelé RSAES-PKCS1-v1.5.

Algorithmes de clé de chiffrement de clé symétriques

   Cette section spécifie les conventions employés par les implémentations CMS qui supportent la gestion de clé de chiffrement de clé en utilisant Triple-DES ou RC2. Quand RC2 est supporté, des clé RC2 128 bits doivent être utilisé, et doivent être utilisées avec le paramètre RC2ParameterVersion à 58. Une implémentation CMS peut supporter un key-encryption et content-encryptionalgorithms mixés. Par exemple, une clé de chiffrement de contenu 40-bits RC2 peut être enveloppé avec une clé de chiffrement de clé Triple-DES 168-bits ou avec une clé de chiffrement de clé 128-bits RC2.

   Les identifiants d'algorithme d'enveloppement sont localisé dans les champs EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm.

   Les clé de chiffrement de contenus enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KEKRecipientInfo. Les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey.

   La sortie d'un algorithme d'agrément de clé est une clé de chiffrement de clé, et cette clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Pour suppporter l'agrément de clé, les identifiants d'algorithme d'enveloppement sont localisés dans le KeyWrapAlgorithm parameter des champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm. Cependant, seuls les algorithmes d'agrément de clé qui fournissent des clés d'authentification doivent être utilisé avec AuthenticatedData. Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey, les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

Triple-DES Key Wrap

   Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé avec une clé de chiffrement de clé 168-bits Triple-DES.

Le chiffrement Triple-DES a l'identifiant d'algorithme :
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

   Le champ parameter de AlgorithmIdentifier doit être NULL. L'algorithme d'envelope de clé utilisé pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES est spécifiée dans la rfc3217.

RC2 Key Wrap

   Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé dans une clé de chiffrement de clé Triple-DES 168-bits. Similairement, une clé de chiffrement de contenu RC2 40-bits peut être enveloppé dans une clé de chiffrement de clé RC2 128-bits.

Le chiffrement de clé RC2 a l'identifiant d'algorithme:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

Le champ parameter de AlgorithmIdentifier doit être RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER

   Les bits de clé effectifs RC2 ( la taille de clé ) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

   Les clé RC2 128-bits doivent être utilisés comme clé de chiffrement de clé, et doivent être utilisé avec le paramètre RC2ParameterVersion à 58.

   L'algorithme d'enveloppe de clé utilisé pour chiffrer une clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2 est spécifiée dans la rfc 3217.

Algorithmes de dérivation de clé

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent la gestion de clé basé sur mot de passe en utilisant PBKDF2. Les algorithmes de dérivation de clé sont utilisés pour convertir un mot de passe en une clé de chiffrement de clé comme partie de la technique de gestion de clé basée sur mot de passe.

   Les identifiants d'algorithme de dérivation de clé sont localisés dans les champs EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm et AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm. La clé de chiffrement de clé qui est dérivée du mot de passe est utilisée pour chiffrer la clé de chiffrement de contenu.

   Les clé de chiffrement de contenu chiffrés avec une clé de chiffrement de clé dérivé de mot de passe sont localisés dans le champ EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey. Les clés d'authentification de message chiffrés avec de clés de chiffrement de clé dérivés de mot de passe sont localisés dans le champ AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey.

L'algorithme de dérivation de clé PBKDF2 est spécifié dans la rfc 2898. keyDerivationAlgorithmIdentifier identifie l'algorithme de dérivation de clé, et ses paramètres associés utilisés pour dériver la clé de chiffrement de clé du mot de passe fournis. L'identifiant d'algorithme pour l'algorithme de dérivation de clé PBKDF2 est:
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

Le champ parameter de AlgorithmIdentifier doit être PBKDF2-params:
PBKDF2-params ::= SEQUENCE {
    salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
    iterationCount INTEGER (1..MAX),
    keyLength INTEGER (1..MAX) OPTIONAL,
    prf AlgorithmIdentifier
        DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

   Dans le PBKDF2-params, le salt doit utiliser la chaîne d'octet spécifiée.

Algorithmes de chiffrement de contenu

   Cette section spécifie les conventions employées par les implémentation CMS qui supportent le chiffrement de contenu en utilisant Triple-DES 3 clés en mode CBC, Triple 2-clés en mode CBC, ou RC2 en mode CBC.

   Les identifiants d'algorithme de chiffrement de contenu sont localisés dans les champs EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm et EncryptedData EncryptedContentInfo contentEncryptionAlgorithm. Les algorithme de chiffrement de contenu sont utilisé pour chiffrer le contenu localisé dans le champ EnvelopedData EncryptedContentInfo encryptedContent et le champ EncryptedData EncryptedContentInfo encryptedContent.

Triple-DES CBC

   L'algorithme Triple-DES est composé de 3 opération DES séquentielles: chiffrer, déchiffrer, et chiffrer. Triple-DES 3-clés utilise une clé différente pour chaque opération DES. Triple-DES 2-clés utilise une clé pour les opérations de chiffrement et une clé différente pour l'opération de déchiffrement. Les même identifiant d'algorithme sont utilisé pour les 2.

L'identifiant d'algorithme pour Triple-DES en mode CBC est:
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

Le champ parameters de AlgorithmIdentifier doit être présent, et le champ doit contenir un CBCParameter:
CBCParameter ::= IV
IV ::= OCTET STRING -- exactement 8 octets

RC2 CBC

L'algorithme RC2 est décris dans la rfc2268. L'identifiant d'algorithme pour RC2 en mode CBC est:
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }

Le champ parameters de AlgorithmIdentifier doit être présent et doit contenir un RC2CBCParameter:
RC2CBCParameter ::= SEQUENCE {
    rc2ParameterVersion INTEGER,
    iv OCTET STRING } -- exactement 8 octets

   Les bits de clé effectifs RC2 (la taille de clé) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

Algorithms de code d'authentification de message

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent HMAC avec SHA-1. Les identifiant d'algorithme MAC sont localisés dans le champ macAlgorithm de AuthenticatedData. es valeurs MAC sont localisées dans le champ mac de AuthenticatedData.

HMAC avec SHA-1

L'algorithme HMAC avc SHA-1 est décris dans la rfc 2104. L'identifiant d'algorithme pour HMAC avec SHA-1 est:
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

   Il y a 2 encodages possibles pour le champ parameters de AlgorithmIdentifier pour HMAC avec SHA-1. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement.

   Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir NULL. Les implémentations doivent accepter HMAC avec SHA-1 avec parameters absent, et doivent accepter HMAC avec SHA-1 avec paramaters à NULL. Les implémentations devraient générer des AlgorithmIdentifiers HMAC avec SHA-1 avec parameters absent.

Module ASN.1


CryptographicMessageSyntaxAlgorithms
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
    
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    -- EXPORTS All
    -- Les types et valeurs définis dans ce module sont exporté pour l'utilisation dans d'autres modules ASN.1.
    -- D'autres applications peuvent les utiliser.
    
IMPORTS
    -- Imports de la rfc 3280, Appendix A.1
        AlgorithmIdentifier
            FROM PKIX1Explicit88 { iso(1)
                identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ;
    
    -- Algorithm Identifiers
    
    sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }
    
    md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }
    
    id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
    
    id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }
    
    rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
    
    md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
    
    sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
    
    dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
    
    id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
    
    id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
    
    id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
    
    id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
    
    des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
    
    rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }
    
    hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
    
    id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
    
    -- Public Key Types
    
    Dss-Pub-Key ::= INTEGER -- Y
    
    RSAPublicKey ::= SEQUENCE {
        modulus INTEGER, -- n
        publicExponent INTEGER } -- e
    
    DHPublicKey ::= INTEGER -- y = g^x mod p
    
    -- Signature Value Types
    
    Dss-Sig-Value ::= SEQUENCE {
        r INTEGER,
        s INTEGER }
    
    -- Algorithm Identifier Parameter Types
    
    Dss-Parms ::= SEQUENCE {
        p INTEGER,
        q INTEGER,
        g INTEGER }
    
    DHDomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g
        q INTEGER, -- factor of p-1
        j INTEGER OPTIONAL, -- subgroup factor
        validationParms ValidationParms OPTIONAL }
    
    ValidationParms ::= SEQUENCE {
        seed BIT STRING,
        pgenCounter INTEGER }
    
    KeyWrapAlgorithm ::= AlgorithmIdentifier
    
    RC2wrapParameter ::= RC2ParameterVersion
    
    RC2ParameterVersion ::= INTEGER
    
    CBCParameter ::= IV
    
    IV ::= OCTET STRING -- exactly 8 octets
    
    RC2CBCParameter ::= SEQUENCE {
        rc2ParameterVersion INTEGER,
        iv OCTET STRING } -- exactly 8 octets
    
    PBKDF2-params ::= SEQUENCE {
        salt CHOICE {
            specified OCTET STRING,
            otherSource AlgorithmIdentifier },
        iterationCount INTEGER (1..MAX),
        keyLength INTEGER (1..MAX) OPTIONAL,
        prf AlgorithmIdentifier
            DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
    
END -- of CryptographicMessageSyntaxAlgorithms

Considérations de sécurité

   La technique de gestion de clé employée pour distribuer les clé d'authentification de message doit elle-même fournir l'authentification, sinon le contenu est délivré avec l'intégrité depuis une source inconnue. Ni RSA, ni Ephemeral-Static Diffie-Hellman ne fournissent l'authentification de l'origine des données nécessaires. Static-Static Diffie-Hellman fournis l'authentification de l'origine des données nécessaire quand l'auteur et les clés publiques des destinataires sont liés aux entités appropriés dans les certificats X.509.

   Quand plus de 2 parties partagent la même clé d'authentification de message, l'authentification de l'origine des donnée n'est pas fournie. Toutes les parties qui connaissent la clé d'authentification de message peuvent calculer un MAC valide, donc le contenu pourrait venir de n'importe lequel de ces parties.

   Les implémentations doivent générer des clé de chiffrement de contenu, de clé d'authentification de message, des vecteurs d'initialisation, des valeurs one-time aléatoirement, et du padding. Également, la génération de paires de clé publique/privées assure des nombres aléatoires. L'utilisation inadéquate de générateurs de nombre pseudo-aléatoires pour générer des valeurs peut engendrer des problèmes de sécurité. Un attaquant peut trouver qu'il est plus facile de reproduite l'environnement PRNG qui de produire les clé, en cherchant le plus petit jeu de possibilités résultants, au lieu de brute forcer tout l'espace de clé. La génération de nombre aléatoires de qualité est difficile. Les rfc1750 offre un guide important dans ce but, et l'appendice 3 de FIPS Pub 186 fournis une technique PRNG de qualité.

   En utilisant les algorithmes d'agrément de clé ou des clé de chiffrement de clé symétrique précédemment distribués, une clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Si les algorithmes de chiffrement de clé et de chiffrement de contenu sont différents, la sécurité effective est déterminée par le plus faible des 2. Les implémenteurs doivent s'assurer que les algorithmes de chiffrement de clé sont aussi fort sinon plus que les algorithmes de chiffrement de contenu.

   La rfc 3217 spécifie des algorithmes d'enveloppe de clé utilisés pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES ou pour chiffrer un clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2. Les algorithmes d'enveloppe de clé utilisent le mode CBC, et ont été revus pour l'utilisation avec Triple-DES et RC2. Ils n'ont pas été revus pour l'utilisation avec d'autres modes cryptographiques ou d'autres algorithmes de chiffrement. Cependant, si une implémentation CMS souhaite supporter d'autres chiffrements, les algorithmes d'enveloppe de clé additionnels doivent être définis pour supporter ces chiffrements additionnels.

   Les implémenteurs devraient vérifier si les algorithmes cryptographiques deviennent faible dans le temps. De nouvelles techniques de cryptanalyse sont développées et les performances de calcul s'améliorent, Le facteur temps pour casser un algorithme cryptographique sera réduit. Cependant, les implémentations d'algorithmes crytographiques devraient être modulaires permettant aux nouveaux algorithmes d'être facilement insérés.

   Les utilisateurs de CMS, particulièrement ceux employant le CMS pour le support d'applications intéractives, devraient savoir que RSA, comme spécifié dans la rfc 2313, est vulnérable à des attaques de texte chiffré choisis lorsqu'il est appliqué à des fins de chiffrement. L'exploitation de cette vulnérabilité identifiée, révélant le résultat d'un déchiffrement RSA particulier, nécessite l'accès à un oracle qui répondra à un grand nombre de textes chiffrés (basé sur les résultats disponibles actuellement), qui sont construits adaptivement en réponse à une réponse reçue précédemment fournissant des informations sur la réussite ou l'échec des opération de déchiffrement tentés. En résultat, l'attaque apparaît significativement moins faisable dans les environnements S/MIME store-and-forward que pour les protocoles intéractif.

   Une version mises à jours de PKCS#1 a été publiée, la version 2.0, qui préserve le support pour le format de padding de chiffrement, et définis une nouvelle alternative. Pour résoudre la vulnérabilité, la version 2.0 spécifie et recommande l'utilisation de OAEP quand RSA est utilisé pour fournir la confidentialité. Voir la rfc 3218 pour plus d'informations sur la vulnérabilité de PKCS#1 version 1.5.
^
24 juillet 2015

htmlpdflatexmanmd




rfc3647

rfc3647

Framework de stratégie de certificat et de pratiques de certification

Introduction

   En général, un certificat à clé publique lie une clé publique maintenue par une entité (telle qu'une personne, une organisation, compte, périphérique, ou site) à un jeu d'informations qui identifient l'entité associée avec l'utilisation de la clé privée correspondante. Dans beaucoup de cas impliquant des certificats d'identité, cette entité est connue comme le "subject" ou "subscriber" du certificat. 2 exceptions cependant, incluant les périphérique (dans lequel le souscripteur est généralement l'organisation contrôlant le périphérique) et les certificats anonymes (dans lequel l'identité de l'individu ou de l'organisation n'est pas disponible depuis le certificat lui-même). D'autres types de certificats lient les clés publiques aux attributs d'une entité autre que l'identité de l'entité, tel qu'un rôle, un titre, ou des informations de solvabilité.

   Un certificat est utilisé par un utilisateur de certificat ou un tiers de confiance qui a besoin d'utiliser, et compte sur la précision de, le lien entre la clé publique du sujet distribué via ce certificat et l'identité et/ou d'autres attributs du sujet contenu dans ce certificat. Un tiers de confiance est fréquemment une entité qui vérifie la signature numérique du sujet du certificat où la signature numérique est associée avec un mail, document électronique, ou autre donnée. D'autres exemples de tiers de confiance peut inclure un émetteur de mail chiffré à un souscripteur, un utilisateur d'un navigateur web vérifiant un certificat serveur durant une session SSL, et une entité opérant un serveur qui contrôle l'accès aux informations online en utilisant des certificats client comme mécanisme de contrôle d'accès. En résumé, un tiers de confiance est une entité qui utilise une clé publique dans un certificat (pour vérification de signature et/ou chiffrement). Le degré auquel le tiers de confiance peut faire confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie de la CA, les procédures, et les contrôles de sécurité. Le scope de la responsabilité du souscripteur (par exemple, en protégeant la clé privée); et les responsabilités statué et les termes et conditions de responsabilité de la CA.

   Un certificat X.509 version 3 peut contenir un champ déclarant qu'une ou plusieurs stratégies de certificat spécifiques s'appliquent à ce certificat. En accord avec X.509, une stratégie de certificat (CP) est "un jeu de règles nommés qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des pré-requis de sécurité communs". Un CP peut être utilisé par un tiers de confiance pour aider à décider si un certificat est suffisamment digne de confiance et par ailleurs approprié pour une application particulière. Le concept CP est un prolongement du concept de déclaration de stratégie développé pour Internet Privacy Enhanced Mail.

   Une description plus détaillée des pratiques suivies par une CA en émettant et gérant des certificats peut être contenu dans une déclaration de pratique de certification (CPS) publié par ou référencé par la CA. En accord avec American Bar Association Information Security Committee's Digital Signature Guidelines (DSG) et l'Information Security Committee's PKI Assessment Guidelines (PAG), "un CPS est une déclaration des utilisations qu'une autorité de certification emploie pour émettre des certificats". En général, les CPS décrivent également des pratiques liées à tous les services de cycle de vie des certificats (ex: émission, gestion, révocation, renouvellement, etc), et les CPS fournissent des détails concernant d'autres question d'affaires, juridiques et techniques. Les termes contenus dans un CP ou CPS peuvent ou non être obligatoire pour les participants d'une PKI comme un contrat. Un CP ou CPS peut lui-même prétendre être un contrat. Plus communément, cependant, un agrément peut incorporer un CP ou CPS par référence et ainsi tenter de lier les parties de l'agrément à partie ou tous ses termes. Par exemple, certaines PKI peuvent utiliser un CP ou ( plus communément ) un CPS qui est incorporé par référence dans l'agrément entre un souscripteur et une CA ou RA (appelé un agrément de souscripteur) ou l'agrément entre un tiers de confiance et une CA (appelé un agrément de tiers de confiance ou RPA). Dans d'autres cas, cependant, un CP ou CPS n'a pas de signification contractuelle du tout. Une PKI peut définir ces CP ou CPS comme étant strictement informationels ou des documents d'information.

But

   Le but de ce document est double. D'abord, le document explique les concepts d'un CP ou d'un CPS, décris les différences entre ces 2 concepts, et décris leur relation au souscripteur et agréments de tiers de confiance. Ensuite, ce document présente un framework pour assister les rédacteurs et utilisateurs de stratégie de certificat ou CPS en définissant et comprenant ces documents. En particulier, le framework identifie les éléments qui peuvent être nécessaire à considérer en formulant un CP ou CPS. Le but n'est pas de définir de stratégie de certificat particulière ou CPS.

Périmètre

   Le périmètre de ce document est limité à la discussion des éléments qui peuvent être couverts dans un CP (comme définis dans X.509) ou CPS (comme définis dans DSG et PAG). En particulier, ce document décris les types d'information qui devraient être considérés pour les inclure dans un CP ou CPS. Bien que le framework présenté généralement assume l'utilisation de certificat X.509v3 pour fournir l'assurance d'identité, il n'est pas prévus qu'il soit restreint à l'utilisation de ce format de certificat. À la place, il est prévus que ce framework soit adaptable à d'autres formats de certificat et certificats fournissant des assurance autre que l'identité qui peuvent entrer en utilisation.

   Le scope ne s'étend pas à la définition des stratégies de certificat (tels que les stratégies de sécurité des organisation, stratégie de sécurité des systèmes, ou stratégie de labelisation des données). De plus, ce document ne définis pas de CP ou CPS spécifiue. En outre, en présentant un framework, ce document devrait être vu et utilisé comme un outil flexible présentant des éléments qui devraient être considérés comme un intérêt particulier pour les CP ou CPS, et pas comme une formue rigide pour produire des CP ou CPS.

   Ce document assume que le lecteur est familiarisé avec les concepts généraux de signature numérique, certificat, et infrastructure à clé publique, comme utilisé dans X.509, le DSG et le PAG.

Définitions

   Ce document utilise les termes suivant:

Activation Data Les valeurs, autre que les clés, qui sont requis pour opérer des modules cryptographiques et qui nécessitent d'être protégés.
Authentification Le processus qui établis que les individus, organisation, ou autre sont qui ils prétendent être. Dans le contexte d'une PKI, l'authentification peut être le processus d'établissement qu'un individu ou organisation applique pour accéder à quelque chose sous un certain nom est, en fait, l'individu ou l'organisation propre. Cela correspond au deuxième processus impliqué dans l'identification.
CA-certificate Un certificat pour une clé publique de CA émise par une autre CA
Certificate Policy Un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou class d'applications avec des besoins de sécurités communs. Par exemple, un CP particulier peut indiquer l'applicabilité d'un type de certificat pour l'authentification des parties engagés dans des transaction b2b pour le commerce de biens ou de services dans une plage de prix donné.
Certification path Une séquence ordonnée de certificats qui, ensemble avec la clé publique de l'objet initial dans le chemin, peuvent être traités avec la clé publique de l'objet initial dans le chemin, peut être traité pour obtenir l'objet final est dans le chemin.
Certification Practice Statement Une déclaration des pratiques qu'une autorité de certification emploie en émettant, gérant, révoquant, et renouvelant les certificats.
CPS Summary (ou CPS Abstract) Un sous-jeu des dispositions d'une CPS complète qui est rendue publique par une CA.
Identification Les processus établissant l'identité d'un individu ou d'une organisation, par ex, pour montrer qu'un individu ou une organisation est un individu ou une organisation spécifique. Dans le contexte d'une PKI, l'identification réfère à 2 processus:

        1. Établir qu'un nom donné d'un individu ou d'une organisation correspond à une identité du monde réel d'un individu ou d'une organisation
        2. Établir qu'un individu ou une organisation s'applique pour un accès à quelque chose sous ce nom est, en fait, l'individu ou l'organisation nommée. Une identification d'une personne peut être un demandeur de certificat, un demandeur pour un emploie dans un poste de confiance participant à une PKI, ou une personne cherchant accès au réseaux ou à une application, telle qu'un administrateur CA cherchant l'accès aux systèmes CA.

Issuing certification authority Dans le contexte d'un certificat particulier, la CA émettrice est la CA qui a émise le certificat.
Participant Un individu ou une organisation qui joue un rôle dans une PKI donnée comme un souscripteur, un tiers de confiance, CA, RA, etc.
PKI Disclosure Statement Un instrument qui complète une CP ou une CPS en divulguant des informations essentielles sur les stratégies et pratiques d'une CA/PKI. Un PDS est un véhicule pour divulguer et souligner les informations normalement couvertes en détail par les documents CP et/ou CPS associés. En conséquence, un PDS n'est pas prévu pour remplace une CP ou CPS.
Policy qualifier Information dépendante de la stratégie qui peut accompagner un identifiant de CP dans un certificat X.509. De telles informations peuvent inclure un pointeur vers une URL d'une CPS applicable ou d'un agrément de tiers de confiance. Il peut également inclure du texte qui contient les termes d'utilisation du certificat ou des informations légales.
Registration authority (RA) Une entité qui est responsable pour une ou plusieurs fonctions: l'identification et l'authentification des demandeurs de certificat, l'approbation ou le rejet des applications de certificat, initier les révocations de certificat ou leur suspension sous certaines circonstances, traiter les demandes de renouvellement ou changement de clé. Les RA, cependant, ne signent ou n'émettent pas de certificat.
Relying party Un destinataire d'un certificat qui agit en se fondant sur ce certificat et/ou toutes signature vérifiées en utilisant ce certificat. Dans ce document, les termes "certificate user" et "relying party" sont utilisé de la même manière.
Relying party agreement (RPA) Un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et responsabilité entre ces parties en regardant la vérification des signatures ou d'autres utilisation des certificats.
Set of provisions Une collection de déclarations de stratégies et/ou de pratique, couvrant un éventails de sujets standards, à utiliser dans l'expression d'un CP ou CPS utilisant l'approche décrite dans ce framework.
Subject certification authority (subject CA) Dans le contexte d'un certificat CA particulier, le subjet CA est la CA dont la clé publique est certifiée dans le certificat
Subscriber Un Sujet d'un certificat qui a été émis.
Subscriber Agreement Un agrément entre une CA et un souscripteur qui établis les droits et responsabilités des parties en regardant l'émission et la gestion des certificats.
Validation Le processus d'identification des demandeurs de certificat. la validation est un sous-jeu de l'identification et réfère à l'identification dans le contexte d'établissement de l'identité des demandeurs de certificat.

Concepts

   Cette section explique les concepts des CP et CPS, et décris leur relation avec d'autres documents PKI, tels que les agréments de souscripteur et de tiers de confiance. D'autres concepts liés sont également décris. Certains supports couverts dans cette section et dans d'autres sections sont spécifiques aux extensions de stratégie de certificat comme définis dans X.509v3. Excepté pour ces sections, ce framework est prévu pour être adaptable à d'autres formats de certificat qui peuvent être utilisés.

Certificate Policy

   Quand une autorité de certification émet un certificat, elle fournis une déclaration à l'utilisateur du certificat qu'une clé publique particulière est liée à l'identité et/ou d'autres attributs d'une entité particulière. La mesure par laquelle le tiers de confiance devrait se conformer sur cette déclaration, cependant, doit être évalué par le tiers de confiance ou d'entité qui contrôle ou coordonne la manière dont les tiers de confiance ou les applications de confiance utilisent les certificats. Différents certificats sont émis suivant différentes pratiques et procédures, et peuvent être utilisable pour différentes applications et/ou buts.

   Le standard X.509 définis une CP comme un jeu nommé de règles qui indique l'applicabilité d'un certificat à une communauté et/ou classe d'application particulier avec les pré-requis de sécurité communs. Un certificat X.509v3 peut identifier une CP applicable spécifique, qui peut être utilisé par un tiers de confiance pour décider de faire confiance ou non à un certificat, la clé publique associée ou les signatures numériques vérifiées en utilisant la clé publique pour un but particulier.

   Il y a typiquement 2 catégories de CP. D'abord, certaines CP indiquent l'applicabilité d'un certificat à une communauté particulière. Ces CP présentent les pré-requis pour l'utilisation de certificat et les pré-requis des membres d'une communauté. Par exemple, une CP peut se concentrer sur les besoins d'une communauté géographique, tel que les pré-requis de stratégie ETSI pour les CA émettant des certificats qualifiés. Également, une CP de ce type peut se focaliser sur les besoins d'une communauté de marché spécifique telle que les services financiers.

   La seconde catégorie de CP indique l'applicabilité d'un certificat à une classe d'applications avec des pré-requis de sécurité communs. Ces CP identifient un jeu d'applications ou d'utilisations pour les certificats et indique que ces applications ou utilisations nécessitent un certain niveau de sécurité. Ils sont ainsi exposés aux exigences PKI qui sont appropriés pour cet applications ou utilisation. Une CP dans cette catégorie créé souvent des jeux de pré-requis appropriés pour un certain niveau d'assurance fournis par les certificats, relatifs aux certificats émis conformément aux CP liés. Ces niveaux d'assurance peuvent correspondre à des classes ou des types de certificat.

   Par exemple, le Government of Canada PKI Policy Management Authority (GOC PMA) a établis 8 stratégies de certificat dans un seul document, 4 stratégies pour les certificats utilisé pour les signatures et 4 certificat pour les certificats utilisé pour le chiffrement. Pour chacune de ces applications, le document établis 4 niveaux d'assurances: rudimentaire, basique, moyen et élevé. Le GOC PMA décris certains types d'utilisation de signature numérique et de confidentialité, chacun avec un certain jeu de pré-requis de sécurité, et groupé en 8 catégories. Le GOC PMA établis ainsi les pré-requis PKI pour chacune de ces catégories, en créant 8 types de certificats, chacun fournissant des niveaux d'assurance rudimentaire, basique, moyen et élevé. La progression du niveau d'assurance rudimentaire à élevé correspond à l'augmentation du niveau de sécurité et d'assurance requis.

   Une CP est représentée dans un certificat par un numéro unique appelé un OID. Cet OID, ou au moins un "arc", peut être enregistré. Un "arc" est le début d'une séquence numérique d'un OID et est assigné à une organisation particulière. Le processus d'enregistrement suit les procédures spécifiées dans les standards ISO/IETC et ITU. Le partie qui enregistre l'OID ou l'arc peut également publier le texte d'un CP, pour être examiné par les tiers de confiance. Tout certificat va explicitement déclarer une seule CP ou, possiblement, être émis en accord avec un petit nombre de stratégies différentes. De telles déclaration apparaissent dans l'extension de stratégie de certificat des certificats X.509v3. Quand une CA place plusieurs CP dans une extension de stratégie de certificat d'un certificat, la CA affirme que le certificat est approprié pour utilisation en accord avec une des CP listées.

   Les CP constituent également une base pour un audit, accréditation, ou autre évaluation d'une CA. Chaque CA peut être évaluée avec une ou plusieurs stratégie de certificat ou CPS qui sont reconnus comme implémentés. Quand une CA émet un certificat CA pour une autre CA, le CA émettrice doit évaluer le jeu de stratégie de certificats pour lequel il trust le sujet. Le jeu évalué est ainsi indiqué par la CA émettrice dans le certificat CA. Le traitement logique du chemin de certification X.509 emploie ces indication CP dans son modèle de validation.

Exemples de stratégie de certification

   Dans un but d'exemple, supposons que l'International Air Transport Association ( IATA ) s'engage à définir certaines stratégies de certificat pour l'utilisation dans l'industrie du transport aérien, dans une PKI opérée par IATA en combinaison avec les PKI opérés par les transports aériens individuels. 2 CP peuvent être définis - l'IATA General-Purpose CP, et l'IATA Commercial-Grade CP.

   L'IATA General-Purpose CP pourrais être utilisé par l'industrie pour protéger les informations de routine (ex: mails) et pour authentifier les connexions depuis les navigateurs web vers les services d'informations générales. Les paires de clé sont générées, stockées, et gérées en utilisant des systèmes à base de logiciel et à faible coût, tels que les navigateurs commerciaux. Sous cette stratégie, un certificat peut être automatiquement émis à tous les employés dans l'annuaire de l'IATA ou un membre qui a envoyé une demande de certificat signée par le biais d'un administrateur réseaux dans son organisation.

   L'IATA Commercial-Grade CP pourrait être utilisé pour protéger les transactions financières ou lier les échanges contractuels entre les entreprises. Sous cette stratégie, l'IATA pourrait imposer que les paires de clé certifiées soient générées et stockées dans des jetons hardwares cryptographiques approuvés. Les certificat et jetons pourraient être fournis aux employés avec une autorité de validation. Les individus autorisés peuvent ainsi être obligés d'être présents dans le bureaux de sécurité de l'organisation, montrer un badge d'identification valide, et signer un agrément de souscripteur qui leur impose de protéger le jeton et de l'utiliser seulement pour les buts autorisés.

Champs de certificat X.509

   Les extensions X.509 suivant sont utilisés pour supporter les CP:

- Extension de stratégies de certificat
- Extension de mappage de stratégie
- Extension de contrainte de stratégie

Extension de stratégie de certificat

   Un champ de stratégies de certificat liste les CP que l'autorité de certification déclare comme applicable. En utilisant l'exemple de l'IATA General-Purpose et Commercial-Grade définis plus haut, les certificats émis pour les employés normaux vont contenir l'identifiant d'objet pour la stratégie à but générale. Les certificats émis pour les employés avec autorité de validation vont contenir les identifiants d'objets pour les 2 stratégies. L'ajout des 2 stratégies dans les certificats signifie qu'ils sont appropriés pour les 2 stratégies. Ces stratégies de certificat peuvent également être optionnellement transmettre les valeurs de qualifiants pour chaque stratégie identifié.

   En traitant un chemin de certification, un CP qui est acceptable pour l'application doit être présent dans tous les certificats dans le chemin, par ex., dans les certificats CA et les certificat EE.

   Si le champ de stratégies de certificats est marqué critique, il sert le même but que décris plus haut mais a un rôle additionnel. Spécifiquement, il indique que l'utilisation du certificat est restreint à une des stratégies identifiées, par ex, l'autorité de certification déclare que le certificat doit seulement être utilisé en accord avec les dispositions d'au moins une CP listée. Ce champ est prévu pour protéger l'autorité de certification contre les réclamations pour des dommages causés par un tiers de confiance qui a utilisé le certificat dans un but inapproprié ou d'une manière inapproprié, comme stipulé dans la CP applicable.

   Par exemple, l'Internal Revenue Service peut émettre des certificat pour les contribuables dans le but de protéger les déclarations fiscales. L'Internal Revenue Service peut comprendre et accommoder les risques lié à l'émission de mauvais certificat, par ex, à un imposteur. Supposons, cependant, que quelqu'un à utilisé un certificat comme base pour le chiffrement de secrets commerciaux à plusieurs millions de dollars, qui tombent ensuite dans de mauvaises mains suite à une attaque par cryptanalytique par un attaquant qui est capable de déchiffrer le message. L'Internal Revenue Service peut vouloir se défendre lui-même contre les réclamations de dégâts dans de telles circonstances en pointant la criticité de l'extension des stratégies de certificat pour montrer la mauvaise utilisation du certificat par le souscripteur et le tiers de confiance. L'extension de stratégies de certificat marquée critique est prévue pour limiter les risques de la CA dans de telles situations.

Extension de mappage de stratégie

   L'extension de mappage de stratégie peut seulement être utilisé dans les certificats CA. Ce champ permet à une autorité de certification d'indiquer que certaines stratégies dans son propre domaine peuvent être considérés équivalents à d'autres stratégies dans le domaine du sujet de l'autorité de certification.

   Par exemple, supposons que pour faciliter l'interopérabilité, l'ACE Corporation établis un agrément avec ABC Corporation pour cross-certifier les clés publiques de chaque autorité de certification pour sécuriser mutuellement leur échanges respectifs. De plus, supposons que les 2 entreprises ont des stratégies de protection de transaction financières pré-existantes appelées ace-e-commerce et abc-e-commerce, respectivement. On peut voir que générer simplement les cross-certificats entre les 2 domaines ne fournis pas l'interopérabilité, vu que les 2 applications d'entreprises sont configurées avec, en les certificats des employés sont renseignés avec, leur stratégies de certificat respectifs. Une possibilité est de reconfigurés toutes les applications financières pour imposer une des 2 stratégies et de ré-émettre tous les certificats avec les 2 stratégies apparaissant dans l'extension de stratégies de certificat. Une autre solution, qui peut être plus simple à administrer, utilise le champ de mappage de stratégie. Si ce champ est inclus dans un cross-certificat pour l'autorité de certification d'ABC Corporation émis par l'autorité de certification de ACE Corporation, il peut fournir une déclaration que la stratégie de protection des transactions financières de ABC (ex: abc-e-commerce) peut être considéré équivalent à celle de ACE Corporation (ex: ace-e-commerce). Avec une telle déclaration inclue dans le cross-certificat émis à ABC, les applications tiers dans le domaine ACE nécessitent la présence de l'identifiant d'objet pour que la CP ace-e-commerce soit également acceptée, traitée, et validée une fois les certificats émis dans le domaine ABC contenant l'identifiant d'objet pour la CP abc-e-commerce.

Extension de contraintes de stratégie

   L'extension de contraintes de stratégie supporte 2 fonctionnalités optionnelles. La première est la capacité pour une autorité de certification de nécessiter que les indications de CP explicites soient présents dans tous les certificats suivant dans la chaîne de certification. Les certificats au début d'un chemin de certification peuvent être considérés par un tiers de confiance comme partie d'un domaine de confiance, par ex, les autorités de certification sont validés pour tous les buts donc aucune CP n'est nécessaire dans l'extension de stratégies de certificat. De tels certificats n'ont pas besoin d'indications explicites de CP. Quand une autorité de certification dans le domaine, cependant, certifie en dehors du domaine, il peut activer les pré-requis d'un CP qui doit apparaître dans les certificats suivants dans le chemin de certification.

   L'autre fonctionnalité optionnelle dans le champ de contraintes de stratégie est la capacité pour une autorité de certification de désactiver le mappage de stratégie pour les autorités de certification suivant dans la chaîne de certification. Il peut être prudent de désactiver le mappage de stratégies en certifiant en dehors du domaine. Cela peut aider à contrôler les risques dus à des trusts de transitions.

Qualifiants de stratégie

   Le champ d'extension de stratégies de certificat comporte une disposition pour le transport, avec chaque identifiant de CP, d'informations se stratégie dans le champ qualifier. Le standard X.509 ne mandate pas le but lequel ce champ est utilisé, ni ne décris la syntaxe pour ce champ. Les types de qualifiants de stratégie peuvent être enregistrés par une organisation.

   Les types de qualifiants de stratégie suivant sont définis dans la rfc3280:

a) Le CPS Pointer contient un pointer vers une CPS, sommaire de CPS, RPA, ou PDS publié par la CA. Le pointeur est sous la forme d'une URI.
b) Le User Notice contient une chaîne texte qui est affiché au souscripteur et les tiers de confiance avant l'utilisation du certificat. Le texte peut être un IA5String ou BMPString. Une CA peut invoquer une procédure qui nécessite que la prise de connaissance par le tiers de confiance des termes applicables et des conditions d'utilisation.

   Les qualifiants de stratégie peuvent être utilisé pour supporter la définition de CP génériques ou paramétrisés. En fournissant la CP de base, les types de qualifiants de stratégie peuvent être définis pour transmettre, sur une base par-certificat, des détails de stratégie spécifiques additionnels qui complète la définition générique.

Déclaration de pratique de certification

   Le terme certification practice statement (CPS) est définis par le DSG et PAG en tant que "déclaration de pratique qu'un autorité de certification emploie pour émettre des certificats". Comme statué plus haut, une CPS établis les pratiques concernant le cycle de vie des services en plus de l'émission, tel que la gestion de certificat (incluant la publication et l'archivage), la révocation, et le renouvellement. Dans le DSG, le ABA étend cette définition avec les commentaires suivants:

   "Une déclaration de pratique de certification peut prendre la forme d'une déclaration par l'autorité de certification des détails de son système fiable et les pratiques qu'elle emploie dans ses opérations et dans le support d'émission d'un certificat." Cette forme de CPS est le type le plus commun, et peut varier en longueur et en niveau de détail.

   Certaines PKI peuvent ne pas avoir besoin de créer de déclaration détaillée et approfondie des pratiques. Par exemple, la CA peut elle-même être le tiers de confiance et sera toujours conscient de la nature et de la fiabilité de ses services. Dans d'autres cas, une PKI peut fournir des certificats fournissant seulement un très bas niveau d'assurance où les applications à sécuriser peuvent causer seulement des risques marginaux s'il sont compromis. Dans ces cas, une organisation établissant une PKI peut seulement vouloir écrire ou avec des CA utilisant un agrément de souscripteur, agrément de tiers de confiance, en fonction du rôle des différents participants de PKI. Dans de telles PKI, cet agrément peut servir comme seule déclaration de pratique utilisé par une ou plusieurs CA dans cette PKI. En conséquence, cet agrément peut également être considéré une CPS et peut être intitulé ou sous-titré comme tel.

   Également, vu qu'une CPS détaillée peut contenir des détails sensible de son système, une CA peut choisir de ne pas publier l'entièreté du CPS. Elle peut choisir de ne publier qu'une CPS sommaire ( ou CPS abstrait ). La CPS sommaire contient seulement les dispositions de la CPS que la CA considère être pertinents pour les participants dans la PKI (tel que les responsabilités des tiers ou les étapes du cycle de vie du certificat). Une CPS sommaire, cependant, ne contient pas les disposition sensibles de la CPS complète qui peut fournir à un attaquant les informations utiles sur les opérations de la CA. Tout au long de ce document, l'utilisation de CPS inclus la CPS détaillée et la CPS sommaire.

   Les CPS ne constituent pas automatiquement des contrats et ne lie pas automatiquement les participants de la PKI comme un contrat le ferai. Lorsqu'un document sert de double objectif d'agrément de souscripteur ou tiers de confiance et CPS, le document est prévu pour être un contrat et constitue un contrat liant dans la mesure où un agrément de souscripteur ou de tiers de confiance serait considéré comme tel. La plupart des CPS, cependant, ne sont pas à double usage. Ainsi, dans beaucoup de cas, les termes de la CPS ont un effet lié comme termes de contrat seulement si un document séparé créé une relation contractuelle entre les parties et que ce document incorpore une partie ou toute la CPS en référence. De plus, si une PKI particulière emploie une CPS sommaire, la CPS sommaire peut être incorporé dans un agrément de souscripteur ou de tiers de confiance applicable.

   Dans le future, un tribunal ou une loi statutaire ou réglementaire applicable peut déclarer qu'un certificat lui-même est un document qui est capable de créer une relation contractuelle, pour étendre ses mécanismes conçus pour être incorporé par référence ( tel que l'extension de stratégies de certificat et ses qualifiants ) indique que les termes d'utilisation apparaissent dans certains documents. Pendant ce temps, cependant, certains agréments de souscripteurs et tiers de confiance peuvent incorporer une CPS par référence et ainsi prendre ses dispositions sur les parties de tels accords.

Relation entre CP et CPS

   Les CP et CPS adressent le même jeu de sujets qui sont d'interêt pour un tiers de confiance en terme de degré à et le but pour lequel un certificat à clé publique devrait être trusté. Leur principales différences sont dans le focus de leurs disposition. Un jeu CP énonce les pré-requis et les standards imposés par la PKI en respect de divers sujets. En d'autres termes, le but du CP est d'établir ce que les participants doivent faire. Une CPS, en contraste, status comment une CA et d'autres participants dans un domaine donné implémentent les procédures et contrôles pour répondre aux pré-requis statués dans la CP. En d'autres termes, le but de la CPS est de déclarer comment les participants effectuent leur fonction et implémentent les contrôles.

   Une autre différence relate le périmètre de couverture des 2 types de document. Vu qu'une CP est une déclaration des pré-requis, il est préférable pour communiquer un guide d'exploitation minimum qui doivent être rencontrés par les PKI intéropérantes. Donc, une CP s'applique généralement à plusieurs CA, plusieurs organisations, ou plusieurs domaines. En contraste, une CPS d'applique seulement à une simple CA ou une simple organisation.

   Un CA avec une seule CPS peut supporter plusieurs CP ( utilisés pour différentes applications et/ou différentes communautés tiers de confiance ). Également, plusieurs CA, avec des CPS différentes, peuvent supporter la même CP.

   Par exemple, le gouvernement fédéral peut définir une CP globale au gouvernement pour gérer les informations de ressources humaines confidentielles. La CP sera une déclaration générale des pré-requis pour les participants dans la PKI du gouvernement, et une indication des types d'applications pour lesquelles elle est prévue. Chaque département ou agence souhaitant opérer une autorité de certification dans cet PKI peut nécessiter l'écriture de sa propre CPS pour supporter cette CP en expliquant comment elle gère les pré-requis de la CP. Dans le même temps, un CPS de département ou agence peut supporter d'autres stratégies de certificat.

   Une autre différence entre une CP et une CPS concerne le niveau de détail des dispositions. Bien que le niveau de détail peut varier dans les CPS, une CPS va généralement être plus détaillée qu'un CP. Une CPS fournis une description détaillée des procédures et contrôles en places pour se conformer aux requis de la CP, alors que la CP est plus générale.

   Les principales différences entre CP et CPS peuvent être résumés comme suit:

a) Une PKI utilise une CP pour établir les requis qui statuent sur ce que les participants doivent faire. Une simple CA ou organisation peut utiliser une CPS pour divulguer comment elle se conforme aux requis d'une CP ou comment elle implémente ses pratiques et contrôles.
b) Une CP facilite l'interopérabilité entre cross-certification, certification unilatérale, ou d'autres moyens. De plus, elle est prévue pour couvrir plusieurs CA. En contraste, une CPS est une déclaration d'une seul CA ou organisation. Son but n'est pas de simplifier l'interopération.
c) Une CPS est généralement plus détaillée qu'une CP et spécifie comment la CA se conforme aux requis spécifiés dans une ou plusieurs CP sous lesquelles elle émet des certificats.

   En plus de populer l'extension de stratégies de certification avec l'OID de la CP applicable, une autorité de certification peut inclure, dans les certificats quelle émet, une référence à ses CPS.

Relation entre CP, CPS et d'autres documents

   CP et CPS jouent un rôle centrale en documentant les pré-requis et pratiques d'une PKI. Cependant, ce ne sont pas les seuls documents. Par exemple, les agréments de souscripteur et les agréments de tiers de confiance jouent un rôle critique en allouant les responsabilités des souscripteur et tiers de confiance liés à l'utilisation de certificats et des paires de clé. Ils établissent les termes et conditions sous lesquelles les certificats sont émis, gérés, et utilisés. Le terme agrément de souscripteur est définis par le PAG comme: "un agrément entre une CA et un souscripteur qui établis les droits et obligation des parties au regard de l'émission et la gestion des certificats". Le PAG définis un agrément de tiers de confiance comme: "un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et obligations entre ces parties au regard de la vérification des signatures numériques ou d'autres utilisations de certificats".

   Comme mentionné précédemment, un agrément de souscripteur, un agrément de tiers de confiance, ou un agrément qui combine les 2 peut également service de CPS. Dans d'autres PKI, cependant, un agrément de souscripteur ou de tiers de confiance peut incorporer certains ou tous les termes d'une CP ou CPS par référence. D'autre PKI encore peuvent distiller depuis une CP et/ou CPS les termes qui sont applicables au souscripteur et place de tels termes dans un agrément de souscripteur auto-contenu, sans incorporer de CP ou CPS par référence. Elles peuvent utiliser la même méthode pour distiller les termes de tiers de confiance depuis une CP et/out CPS et placer de tels termes dans un agrément de tiers de confiance. Créer de tels agrément auto-contenus a l'avantage de créer des documents qui sont plus faciles à lire par les consommateurs. Dans certains cas, les souscripteur et les tiers de confiance peuvent être considérés comme des consommateurs sous une loi applicable, qui sont sujets aux lois civiles des pays, incorporer une CP ou une CPS par référence peut ne pas être efficace pour lier les consommateurs aux termes dans une CP ou CPS incorporé.

   Les CP et CPS peuvent être incorporés par référence dans d'autres documents, incluant:

- Agréments d'interopérabilité ( incluant les agréments entre les CA pour la cross-certification, la certification unilatérale, ou d'autres formes d'interopération ).
- Agréments de vendeur ( sous lequels un vendeur de PKI accepte de se conformer aux normes énoncées dans une CP ou CPS ).
- Un PDS

   Un PDS a une fonction similaire à une CPS sommaire. C'est un document relativement court contenant seulement un sous-jeu de détails critiques sur une PKI ou CA. Il peut différer d'une CPS sommaire, cependant, dans son but qui est d'agir comme sommaire d'information sur la nature globale de la PKI, en contraste à une forme condensée d'une CPS.

   De plus, son but est de distiller les informations sur la PKI, en opposé à la protection d'information sensible de sécurité contenu dans une CPS non-publiée, bien qu'un PDS pourrait servir également cette fonction.

   Tout comme un rédacteur pourrait souhaiter référer à une CP ou CPS ou l'incorporer par référence dans un agrément ou PDS, une CP ou CPS peut référer à d'autres documents lors de l'établissement des requis ou en définissant les déclarations. Par exemple, une CP pour définir les requis pour le contenu de certificat en se référant à un document externe énonçant un profile de certificat standard. Référencer des documents externes permet à une CP ou CPS d'imposer des requis détaillés ou des déclarations détaillées sans avoir à ré-écrire les dispositions longue depuis d'autres documents dans la CP ou CPS. De plus, référencer un document dans une CP ou CPS est une autre manière utile de diviser les dispositions entre les informations publique et les informations confidentielles sensibles ( en plus de ou comme alternative à une CPS sommaire ). Par exemple, une PKI peut souhaiter publier une CP ou CPS, mais maintenir les paramètres de construction du site pour une CA comme information confidentielle. Dans ce cas, la CP ou CPS pourrait référencer un manuel externe ou un document contenant ces paramètres détaillés.

   Les documents qu'une PKI peut souhaiter faire référence dans une CP ou CPS incluent:

- Une stratégie de sécurité
- Manuels de formation, opérationnel, installation, et utilisateurs ( qui peuvent contenir des requis opérationnels )
- Plans de gestion de clés
- Guides de ressources humaine et manuels d'embauche ( qui peuvent décrire certains aspects de pratiques de sécurité personnel )
- Stratégie d'email ( qui peut discuter des responsabilités des souscripteurs et tiers de confiance, aussi bien que les implications de gestion de clé, si applicable )

Jeu de disposition

   Un jeu de dispositions est une collection de pratiques et/ou déclarations de stratégies, couvrant un éventail de sujets à utiliser dans l'expression d'une CP ou CPS employant l'approche décrite dans ce framework.

   Une CP peut être exprimée comme un seul jeu de dispositions

   Une CPS peut être exprimée comme un seul jeu de dispositions avec chaque composant adressant les requis d'une ou plusieurs stratégie de certificat, ou, alternativement, comme une collection organisée de jeux de dispositions. Par exemple, une CPS pourrait être exprimées comme un combinaison des éléments suivants:

a) Une liste de stratégies de certificats supportés par la CPS;
b) Pour chaque CP dans (a), un jeu de dispositions qui contiennent les déclarations répondant à cette CP en ajoutant les détails non stipulés dans la stratégie ou expressément laissée à la discrétion de la CA (dans ses CPS); de telles déclarations servent à statuer comment cette CPS particulière implémente les requis d'une CP particulière, ou
c) Un jeu de dispositions qui contiennent des déclarations de pratique de certification dans la CA, sans regarder la CP.

   Les déclarations fournies dans (b) et (c) peuvent augmenter ou affiner les stipulations de la CP applicable, mais ne doit généralement pas être en conflit avec une des stipulations d'une telle CP. Dans certains cas, cependant, une autorité de stratégie peut permettre des exceptions aux pré-requis dans une CP, parce que certains contrôles de compensation de la CA sont décris dans sa CPS, qui permet à la CA de fournir des assurances qui sont équivalents aux assurances fournies par les CA qui sont complètement conformes avec la CP.

   Ce framework dessine le contenu d'un jeu de dispositions, en terme de 9 composants principaux, comme suit:

1. Introduction
2. Publication et dépôt
3. Identification et Authentification
4. Pré-requis opérationnels du cycle de vie de certificat
5. Installation, gestion, et contrôles opérationnels
6. Contrôles de sécurité techniques
7. Profiles de certificat, CRL, et OCSP
8. Audit de conformité
9. Autres affaires et questions juridiques

   Les PKI peuvent utiliser ce simple framework de 9 composant primaires pour écrire une CP ou CPS simple. De plus, une CA peut utiliser ce framework pour écrire des agréments de souscripteur et/ou de tiers de confiance. Si une CA utilise ce framework pour construire un agrément, il peut utiliser le paragraphe 1 comme introduction, peut exposer les responsabilités des parties dans le paragraphe 2-8, et peut utiliser le paragraphe 9 pour couvrir les problèmes légaux et commerciaux décris plus en détail plus bas. L'ordre des sujets dans ce simple framework et les questions juridiques et de business est le même que l'ordre des sujets dans un logiciel typique ou d'autres agréments technologiques. Cependant, une PKI peut établir un jeu de documents centraux ( avec une CP, CPS, agrément de souscripteur et de tiers de confiance ) ayant tous la même structure et ordre des sujets, facilitant ainsi les comparaisons et les mappages entre ces documents et entre les documents correspondant d'autres PKI.

   Ce simple framework peut également être utile pour les agrément autre que les agréments de souscripteur et de tiers de confiance. Par exemple, une CA souhaitant externaliser certains services à une RA ou une autorité de fabrication de certificat ( certificate manufacturing authority (CMA) ) peuvent trouver utile d'utiliser ce framework comme checklist pour écrire un agrément d'autorité d'enregistrement ou d'externalisation. Similairement, 2 CA peuvent souhaiter utiliser ce framework pour définir une cross-certification, certification unilatérale, ou d'autre agréments d'interopérabilité.

   Les composants primaires du framework peuvent rencontrer les besoins des rédacteurs de CP, CPS et agréments cours. Cependant, ce framework est extensible, et sa couverture de 9 composants est suffisamment flexible pour s'adapter aux besoins des rédacteurs de CP et CPS. Spécifiquement, les composants apparaissant ci-dessus peuvent comprendre plusieurs éléments. La section suivante fournis une description plus détaillée du contenu des composants et leur sous-composants. Les rédacteurs de CP et CPS sont autorisés à ajouter des niveaux additionnels de sous-composants sous les sous-composant pour correspondre à leurs besoins.

Contenu du jeu de dispositions

   Cette section étends le contenu du framework de dispositions. Les sujets identifiés dans cette section sont, en conséquence, des sujets candidats pour être inclus dans une CP ou CPS détaillée.

   bien que de nombreux sujets sont identifiés, il n'est pas nécessaire pour une CP ou une CPS d'inclure une déclaration concrète pour chaque sujet. À la place, une CP ou CPS particulière peut indiquer "aucune stipulation" pour un composant, sous-composant, ou élément sur lequel la CP ou CPS n'impose aucun requis ou ne divulgue rien. En ce sens, la liste des sujets peut être considéré comme une checklist de sujets pour aider à la rédaction d'une CP ou CPS.

   Il est recommandé que chaque composant et sous-composant soit inclus dans une CP ou CPS, même s'il n'y a aucune stipulation; cela indique au lecteur qu'une décision consciente a été faite d'inclure ou exclure une disposition concernant ce sujet. Ce style de rédaction protège contre les oublis par inadvertance d'un sujet, tout en facilitant la comparaison de différentes stratégies de certificat ou CPS.

   Dans une CP, il est possible de laisser certains composants, sous-composants et/ou élément non-spécifiés, et pour stipuler que les informations requises seront indiquées dans un qualifiant de stratégie, ou le document vers lequel le qualifiant de stratégie pointe. Le jeu de dispositions devrait référencer ou définir les types de qualifiant de stratégie requis et devrait spécifier les valeurs par défaut applicables.

1. Introductions

   Ce composant identifie et introduit le jeu de dispositions, et indique les types d'entité et applications pour lesquels le document écris.

1.1 Vue générale

   Ce sous-composant fournis une introduction générale au document. Ce sous-composant peut également être utilisé pour fournir un synopsis de la PKI pour laquelle la CP ou CPS s'applique. Par exemple, il peut définir différents niveaux d'assurance fournis par les certificats dans une PKI particulière, une représentation diagrammatique de la PKI être utile ici.

1.2 Nom du document et identification

   Ce sous-composant fournis des noms applicable ou d'autres identifiants incluant les identifiants d'objets ASN.1, pour le document. Un exemple d'un tel nom de document serait "US Federal Government Policy for Secure E-mail".

1.3 Participants de la PKI

   Ce sous-composant décris l'identité ou les types d'entités qui ont un rôle de participant dans une PKI:

        Autorités de certification, Par ex, les entités qui émettent des certificat. Une CA est la CA émettrice respectant le certificat CA qui lui a été donné. Les CA peuvent être organisés hiérarchiquement dans laquelle une CA d'organisation émet des certificats à des CA opérés par des organisations subordonnées, comme une branche, une division, ou un département dans une plus grande organisation.
        autorités d'enregistrement, par ex, les entités qui établissent les procédures d'enrôlement pour les candidats de certificats finaux, l'identification et l'authentification pour les candidats de certificats, et l'initialisation des demandes de révocation pour les certificats, et les approuver le renouvellement ou le changement de clé des certificats. Les organisations subordonnées dans une grande organisation peuvent agir comme RA pour la CA servant toute l'organisation, mais les RA peuvent également être externe à la CA.
        souscripteurs des exemples de souscripteurs qui reçoivent des certificats d'une CA incluent les employés d'une organisation avec sa propre CA, les clients de banque ou de courtage, organisations hébergeant des sites de e-commerce, etc.
        Tiers de confiance. Des examples de tiers de confiance incluent les employés d'une organisation ayant sa propre CA qui reçoit des emails signés par d'autres employs, les clients d'un site e-commerce, les organisations participant à un échange business-to-business, etc.
        Autres participants, tels que les autorités de fabrique de certificat, les fournisseurs de services de dépôt, et d'autres entités fournissant des service liés à la PKI.

1.4 Utilisation de certificat

   Ce sous-composant contient:

        - Une liste ou les types d'applications pour lesquels les certificats émis sont utilisable, tels que les mails éléctroniques, les transactions de vente, contrats, ou ordre de voyage, et/ou
        - Une liste ou les types d'applications pour lesquels l'utilisation des certificats est interdite.

   Dans le cas d'une CP ou CPS décrivant différents niveaux d'assurance ce sous-composant peut décrire les application ou les types d'applications qui sont appropriés ou inappropriés pour les différents niveaux d'assurance.

1.5 Administration de stratégie

   Ce sous-composant inclus le nom et l'adresse de l'organisation qui est responsable pour la rédaction, l'enregistrement, la maintenance, et la mise à jours de cette CP ou CPS. Il inclus également le nom, l'adresse email, numéro de téléphone, et numéro de fax d'une personne à contacter. Au lieu de nommer un personne, le document peut nommer un titre ou un rôle, un email alias, et d'autres informations généralisées. Dans certains cas, l'organisation peut statuer qui sa personne de contact, seule ou avec d'autre, est disponible pour répondre aux questions sur ce document.

   De plus, quand une autorité de stratégie formelle ou informelle est responsable pour déterminer si une CA devrait être autorisée à opérer dans ou intéropérer avec une PKI, il peut être souhaitable d'approuver la CPS d'une CA comme étant utilisable pour l'a CP de l'autorité de stratégie. Si c'est le cas, ce sous-composant peut inclure le nom ou titre, adresse email, numéro de téléphone, fax, et autres informations généralisées de l'entité en charge de prendre de telles décisions. Finalement, dans ce cas, le sous-composant peut également inclure les procédures par lesquels cette détermination est faite.

1.6 Définitions et acronymes

   Ce sous-composant contient une liste de définitions pour les termes définis utilisés dans ce document, aussi bien qu'une liste d'acronymes dans le document leur signification.

2 Responsablités de publication et de dépôt

   Ce composant contient les dispositions applicable avec:

- Une identification de l'entité ou les entités qui opèrent les dépôts dans la PKI, tels qu'une CA, CMA, ou fournisseur de service de dépôt indépendant
- La responsabilité d'un participant de PKI pour publier les informations de pratiques, certificat, et le statuts courant de tels certificats, qui peuvent inclurent les responsabilités de rendre la CP ou CPS disponible au publique en utilisant divers mécanismes en identifiant les composants, sous-composants, et élément de tels documents qui existent mais ne sont pas publiquement disponible, par exemple, les contrôles de sécurité, les procédures de dédouanement, ou information secrètes.
- Quand les informations doivent être publiés et la fréquence de publication, et
- le contrôle d'accès sur les objets publiés incluant les CP, CPS, certificats, statuts de certificats, et CRL.

3 Identifiation et authentification

   Ce composant décris les procédures utilisées pour authentifier l'identité et/ou les autres attributs d'un utilisateur demandant un certificat à une CA ou une RA avant de recevoir le certificat. En plus, le composant énonce les procédures pour authentifier l'identité et les critères d'accèptation des demandes des entités cherchant à devenir un CA, RA, ou d'autres entités opérant dans ou intéropérant avec la PKI. Il décris également comment les parties demande un renouvellement de clé ou une révocation sont authentifiés. Ce composant adresse également les pratiques de nommage, incluant la reconnaissance des droits de marque dans certains noms.

3.1 Nommage

   Ce sous-composant inclus les éléments suivants pour le nommage et l'identification des souscripteurs:

- Les types et noms assignés au sujet, tel que les DN X.500, noms rfc822, et noms X.400.
- Si les noms doivent avoir un sens ou non
- Si les souscripteurs peuvent être anonymes ou des pseudonymes, et s'ils le peuvent, quels noms leur sont assignés ou peuvent être utilisé par les souscripteurs anonymes.
- Les règles pour interpréter divers formes de nom, tels que le standard X.500 et rfc822.
- Si les nom doivent être uniques, et
- La reconnaissance, l'authentification, et le rôle des marques.

3.2 Validation initiale de l'identité

   Ce sous-composant contient les éléments suivant pour les procédures d'identification et d'authentification pour l'enregistrement initial de chaque type de sujet (CA, RA, souscripteur, ou autre participant):

- Si et comment le sujet doit prouver la possession d'une clé privée associée à la clé privée en cours d'enregistrement, par exemple, une signature numérique dans le message de demande de certificat.
- Les requis d'identification et d'authentification pour l'entité organisationnelle du souscripteur ou du participant (CA, RA, souscripteur, ou autre participant), par exemple, en consultant la base d'un service qui identifie les organisations ou en inspectant les statuts de l'organisation.
- Les requis d'identification et d'authentification pour un souscripteur ou une personne agissant pour le compte d'une organisation ou d'un participant (CA, RA, dans le cas de certificats émis aux organisation ou périphériques contrôles par une organisation, souscripteur, ou autre participant), incluant:

        - Le type de documentation et/ou le nombre de référence d'identification requis.
        - Comment une CA ou RA authentifie l'identité de l'organisation ou individu basé sur la documentation ou les accréditifs fournies
        - Si l'individu doit se présenter personnellement à la CA ou RA authentifiante.
        - Comment un individu tel qu'une personne de l'organisation est authentifiée, tels que par référence à des documents d'autorisation signés ou un badge d'identification d'entreprise.

- La liste des informations de souscripteur qui n'est pas vérifiée durant l'enregistrement initial
- La validation de l'autorité implique de déterminer si une personne a des droits spécifiques ou des permissions incluant la permission d'agir pour le compte d'une organisation pour obtenir un certificat; et
- Dans le cas des applications par une CA souhaitant opérer dans, ou interopérer avec, une PKI, ce sous-composant contient le critère par lequel un PKI, CA, ou autorité de stratégie détermine si la CA est prévue pour de telles opérations ou intéropérations. Une telle intéropération peut inclure la cross-certification, certification unilatérale, ou d'autres formes d'intéropérations.

3.3 Identification et authentification pour les demande de renouvellement de clé

   Ce sous-composant adresse les éléments suivant pour les procédures d'identification et d'authentification pour le renouvellement de clé pour chaque type de sujet (CA, RA, souscripteur, ou autres participants).

- les requis d'identification et d'authentification pour les routines de renouvellement de clé, tel qu'une demande de renouvellement de clé qui contient la nouvelle clé et est signée en utilisant la clé actuellement valide, et
- Les requis d'identification et authentification pour le renouvellement de clé après la révocation de certificat. Un exemple est l'utilisation du même processus que pour la validation initiale

3.4 Identification et authentification pour les demandes de révocation

   Ce sous-composant décris les procédures d'identification et d'authentification pour une demande de révocation pour chaque type de sujet (RA, CA, souscripteur, et autres participants).

4 Requis opérationnel du cycle de vie des certificats

   Ce composant est utilisé pour spécifier les requis imposés en émettant des CA, sujets de CA, RA, souscripteurs, ou autres participants en respect avec le cycle de vie d'un certificat.

   Dans chaque cous-composant, des considérations séparées peuvent être nécessaire à donner au sujet d'une CA, RA, souscripteurs, et autres participants

4.1 Demande de certificat

   Ce sous-composant est utilisé pour adresser les requis suivant au regard de la demande de certificat:

- Qui peut émettre une demande de certificat, tel qu'un sujet de certificat ou la RA; et
- Le processus l'enrôlement utilisé par les sujets pour émettre des demandes de certificat et les responsabilités en connexion avec ce processus. Un exemple de ce processus est quand le sujet génère la paire de clé et envoie une demande à la RA. La RA valide et signe le demande et l'envoi à la CA. Une CA ou RA peut avoir la responsabilité d'établir le processus d'enrôlement pour pouvoir recevoir la demande. De même, les demandeurs de certificat peuvent avoir la responsabilité de fournir des informations précises sur leurs demandes de certificat.

4.2 Traitement des demandes de certificat

   Ce sous-composant est utilisé pour décrire la procédure pour traiter les demandes de certificat. Par exemple, La CA et RA émettrice peut effectuer des procédures d'identification et d'authentification pour valider la demande de certificat. En suivant ces étapes, la CA ou RA va soit approuver soit rejeter la demande, éventuellement basé sur certains critères. Finalement, ce sous-composant définis la durée limite qu'une CA et/ou RA doit agir et traiter la demande.

4.3 Émission de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivant lié à l'émission de certificat:

- Les actions effectuées par la CA durant l'émission du certificat, par exemple une procédure par laquelle la CA valide la signature de la RA et l'autorité RA et génère un certificat; et
- Les mécanismes de notification, s'il y'en a, utilisé par la CA pour notifier le souscripteur de l'émission du certificat; par exemple, la procédure par laquelle la CA envoie par e-mail le certificat au souscripteur ou la RA ou les informations permettant au souscripteur de télécharger le certificat depuis un site web.

4.4 Acceptation de certificat

   Ce sous-composant adresse les éléments suivant:

- La conduite d'un candidat qui sera considéré pour constituer l'acceptation du certificat. Une telle conduite peut inclure des étapes d'affirmation pour indiquer l'acceptation, les actions impliquant l'acceptation, ou un rejet du certificat ou de son contenu. Par exemple, l'acceptation peut être considéré si la CA n'a pas reçu de notification du souscripteur dans une certaine période de temps; un souscripteur peut envoyer un message signé acceptant le certificat; ou un souscripteur peut envoyer un message signé rejetant le certificat qui inclus la raison du rejet et identifie les champs dans le certificat qui sont incorrect ou incomplets.
- La publication du certificat par la CA. Par exemple, la CA peut poster le certificat dans un annuaire LDAP ou X.500.
- La notification de l'émission du certificat par la CA à d'autres entités. Par exemple, la CA peut envoyer le certificat à la RA.

4.5 Utilisation du certificat et de la paire de clé

   Ce sous-composant est utilisé pour décrire les responsabilités liées à l'utilisation des clés et des certificats, incluant:

- La responsabilité du souscripteur lié à l'utilisation de la clé privée et du certificat du souscripteur. Par exemple, on peut imposer au souscripteur d'utiliser un clé privée et un certificat uniquement pour les applications appropriées comme indiquée dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage). L'utilisation d'une clé privée et d'un certificat sont sujet aux termes de l'agrément du souscripteur, l'utilisation de la clé privée est permise seulement après que le souscripteur a accepté le certificat correspondant, ou le souscripteur doit arrêter l'utilisation de la clé privée après l'expiration ou la révocation du certificat.
- Les responsabilités des tiers de confiance liés à l'utilisation d'une clé publique de souscripteur et du certificat. Par exemple, un tiers de confiance peut être obligé de valider les certificats seulement pour les applications appropriées comme indiqué dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage), exécuter avec succès les opération de clé publique comme condition de validation d'un certificat, assumer la responsabilité de vérifier le statut d'un certificat en utilisant un des mécanismes requis ou permis définis dans la CP/CPS, et le consentement des termes de l'agrément du tiers de confiance comme condition de validation de certificat.

4.6 Renouvellement de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivants liés au renouvellement de certificat. Le renouvellement de certificat signifie l'émission d'un nouveau certificat au souscripteur sans changer le souscripteur ou d'autres clé publiques du participant ou informations dans le certificat:

- Les circonstances sous lesquelles le renouvellement du certificat prend place, tel que lorsque le certificat a expiré, mais la stratégie permet de réutiliser la même paire de clé.
- Qui peut faire des demandes de renouvellement de certificat, par exemple, le souscripteur, la RA, ou la CA peut automatiquement renouveler un certificat EE.
- Les procédures de CA ou RA pour traiter les demandes de renouvellement pour émettre le nouveau certificat, par exemple, l'utilisation d'un jeton, tels qu'un mot de passe, pour ré-authentifier le souscripteur, ou les procédures qui sont les même qui l'émission d'un certificat initial.
- La notification d'un nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.7 Renouvellement le clé

   Ce sous-composant est utilisé pour décrire les éléments suivants liés à un souscripteur ou un autre participant générant une nouvelle paire de clé et application pour l'émission d'un nouveau certificat qui certifie la nouvelle clé publique:

- Les circonstances sous lesquelles le renouvellement de clé de certificat peut ou doit être fait, tels qu'après la révocation d'un certificat pour une raison de compromission de clé ou après qu'un certificat a expiré et que la période d'utilisation de la paire de clé a également expiré.
- Qui peut demander le renouvellement le clé de certificat, par exemple, le souscripteur
- Les procédures CA ou RA pour traiter les demandes de renouvellement de clé pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission de certificat initial.
- La notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.8 Modification de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivant liés à l'émission d'un nouveau certificat du à des changement d'informations dans le certificat autre qui la clé publique:

- Les circonstances sous lesquelles la modification de certificat peut se faire, tels qu'un changement de nom, changement de rôle, réorganisation résultant en un changement dans le DN.
- Qui peut effectuer des demandes de modification de certificat, par exemple, les souscripteurs, personnel des ressources humaines, ou la RA.
- Les procédures CA ou RA pour traiter les demandes de modification pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission initiale.
- Notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.9 Révocation et suspension de certificat

   Ce sous-composant adresse les points suivants:

- Les circonstances sous lesquelles un certificat peut être suspendu et les circonstances sous lesquelles il doit être révoqué, par exemple, dans le cas ou un souscripteur termine sont contrat, perd son jeton cryptographique, ou suspecte la compromission de la clé privé
- Qui peut demander la révocation du certificat du participant, par exemple, le souscripteur, RA ou CA dans le cas d'un certificat EE.
- Les procédures utilisées pour les demandes de révocation de certificat, tels qu'un message signé numériquement de la RA, du souscripteur, ou un appel téléphonique de la RA.
- La période de grâce disponible au souscripteur, dans laquelle le souscripteur doit créer une demande de révocation.
- Le temps dans lequel la CA doit traiter la demande de révocation
- Les mécanismes, s'il y en a, que le tiers de confiance peuvent utiliser ou doivent utiliser pour vérifier le statut des certificats qui souhaitent valider.
- Si un mécanisme de CRL est utilisé, la fréquence d'émission
- Si un mécanisme de CRL est utilisé, le délai maximum entre la génération de la CRL et sa publication (en d'autres termes, le temps maximum de traitement)
- La disponibilité d'un mécanisme de vérification on-line, par exemple, OCSP.
- Les pre-requis des tiers de confiance pour effectuer des vérification de statut/révocation on-line
- D'autres formes d'annonce de révocation disponible
- Toutes variations des stipulations précédentes pour lesquelles la suspension ou la révocation est le résultat d'une compromission de clé privée
- Les circonstances sous lesquelles un certificat peut être suspendu
- Qui peut demander la suspension d'un certificat, par exemple, le souscripteur, le personnel des ressources humaines, un superviseur du souscripteur, ou la RA dans le cas d'un certificat utilisateur.
- Les procédures pour demander la suspension du certificat, tel qu'un message signé numériquement du souscripteur ou d'un RA, un appel téléphonique de la RA
- La durée de suspension

4.10 Services de statut de certificat

   Ce sous-composant adresse les services de vérification de statut de certificat disponible aux tiers de confiance, incluant:

- Les caractéristiques opérationnelles des services de vérification de statut de certificat
- La disponibilité de tels services, et toutes stratégies applicables sur l'indisponibilité
- Toutes fonctionnalités optionnelles de tels services.

4.11 Fin de souscription

   Ce sous-composant adresse les procédures utilisée pour les souscripteurs pour terminer la souscription des services CA, incluant:

- La révocation des certificat à la fin de la souscription ( qui peut différer, en fonction de si la fin de souscription est dûe à l'expiration du certificat ou la fin du service ).

4.12 dépôt et récupération de clé

   Ce sous-composant contient les éléments pour identifier les stratégies et pratiques liées au dépôt, et/ou récupération des clés privées quand des services de dépôt de clés privée sont disponibles.

- Identification du document contenant les stratégies et pratiques de dépôt de clé et de récupération ou une liste de telles stratégies et pratiques
- Identification du document contenant les stratégies et pratiques d'encapsulation des clés de session ou une liste de telles stratégie et pratiques.

5. Gestion, opérationnel, et contrôles physiques

   Ce composant décris les contrôles de sécurité non-techniques (c'est à dire, les contrôles physiques, procédurales et personnelles) utilisées par la CA émettrice pour effectuer de manière sécurisée les fonctions de génération de clé, authentification du sujet, assurances de certificat, révocation de certificat, audit, et archivage.

   Ce composant peut également être utilisé pour définir des contrôles de sécurité non-techniques sur les dépôt, tels que les sujets CA, RA, souscripteurs, et autres participants. Les contrôles de sécurité non-techniques pour les CA, RA, souscripteurs, et autres participants peuvent être les mêmes, similaires, ou très différents.

   Ces contrôles de sécurité non-techniques sont critique pour valider les certificat vu qu'un manque de sécurité peut compromettre les opérations CA résultantes par exemple, en la création de certificats ou CRL avec des informations erronées ou la compromission de la clé privée de la CA.

   Dans chaque sous-composant, des considérations séparées vont, en général, être donnés à chaque type d'entité.

5.1 Contrôles de sécurité physiques

   Dans ce sous-composant, les contrôles physiques sur les installation abritant les systèmes de l'entité sont décris:

- La construction et l'emplacement du site, tel que la pré-requis de construction pour des zones à haute sécurité et l'utilisation de salles fermées, cages, coffre-fort, et armoires.
- L'accès physique, par ex, les mécanismes de contrôles d'accès d'une zone à une autre ou l'accès à des zones de haute sécurité, tels que les opérations CA localisées dans une salle information sécurisée et supervisée par des gardiens ou des alarmes de sécurité.
- Puissance et climatisation
- Exposition à l'eau
- Prévention et protection contre le feu
- Stockage, par exemple, la nécessité d'un stockage de sauvegarde dans un emplacement séparé qui est sécurisé physiquement et protégé du feu et de l'eau.
- L'élimination des déchets
- sauvegarde hors-site

5.2 Contrôles procédurales

   Dans ce sous-composant, les pré-requis opur reconnaître les rôles de confiance sont décris, avec les responsabilités de chaque rôle. Des exemples de rôles de confiance incluent les administrateurs systèmes, les responsables de la sécurité, et les auditeurs système.

   Pour chaque tâche identifié, le nombre d'individus requis pour effectuer la tâche devrait être statué pour chaque rôle. L'identification et l'authentification requis pour chaque rôle peut également être définis.

   Ce composant inclus également la séparation des privilèges en termes de rôles qui ne peuvent pas être effectués par les même individus.

5.3 Contrôles de sécurité personnel

   Ce sous-composant adresse les éléments suivant:

- Qualifications, expérience, et habilitations que le personnel doit avoir comme condition pour jouer ces rôles de confiance ou d'autres rôles importants. Par exemple les accréditifs, expérience professionnelle, et habilitations gouvernementales que les candidats à ces positions doivent avoir.
- La vérification des antécédents et des procédures d'habilitations qui sont requis dans le cadre de l'embauche de personnel remplissant des rôles de confiance ou d'autres rôles importants; de tels rôles peuvent nécessiter une vérification de leur casier judiciaire, références, et habilitations additionnelles qu'un participant engage après une décision d'embauche d'une personne particulière.
- Formations requises et procédures de formations pour chaque rôle qui suivent l'embauche.
- Toute période de renouvellement et les procédures de renouvellement pour chaque rôle après l'achèvement de la formation initiale.
- La fréquence et la séquence de la rotation des postes sur divers rôles
- Les sanctions contre le personnel pour les actions non autorisées, l'utilisation d'autorité non autorisée, l'utilisation non autorisé des systèmes dans le but d'imposer la responsabilité sur un participant.
- Les contrôles du personnel qui sont des indépendant aux lieu d'employés de l'entité, par exemple:

        - Exigences de cautionnement sur le personnel sous contrat
        - Les exigences contractuelles, y compris l'indemnisation des dommages dûs à des actions du personnel en contrat
        - L'audit et la supervision du personnel en contrat
        - D'autres contrôles sur le personnel en contrat

- La documentation à fournir au personnel durant la formation initiale, le renouvellement, ou autre.

5.4 Procédures d'audit de connexion

   Ce sous-composant est utilisé pour décrire les évènements de connexion et les systèmes d'audit, implémentés dans le but de maintenir un environnement sécurisé.

- Les types d'évènements enregistrés, tels que les opérations sur le cycle de vie des certificats, tentatives d'accès au système, et requêtes faites au système.
- Fréquence à laquelle les logs d'audits sont traités ou archivés, par exemple, chaque semaine, suivant un évènement anormal ou d'alerte, ou quand le log d'audit est plein.
- Période pour laquelle les données d'audit sont conservées
- Protection des logs d'audit:

        - Qui peut voir les logs d'audit, par exemple, les administrateurs d'audit
        - La protection contre la modification des logs d'audit, par exemple une exigence qu'aucune modification ou suppression les enregistrements d'audit ou que seul l'administrateur d'audit peut supprimer un fichier d'audit comme partie de la rotation du fichier d'audit
        - Protection contre la suppression des logs d'audit.

- Procédures de sauvegarde des log d'audits
- Si le système de d'accumulation des logs d'audits est interne ou externe à l'entité
- Si le sujet qui à causé un évènement d'audit est notifié de l'action d'audit
- L'évaluation des vulnérabilité, par exemple, où les données d'audit sont lancées via un outils qui identifie les tentatives potentielles pour casser le système de sécurité

5.5 Archivage des données d'enregistrement

   Ce sous-composant est utilisé pour décrire les stratégies d'archivage des enregistrements:

- Les types d'enregistrement qui sont archivés, par exemple, toutes les données d'audit, les information d'application de certificat, et la documentation supportant les applications de certificat.
- La période de rétention pour une archive
- La protection d'une archive

        - Qui peut voir l'archive, par exemple, seulement l'administrateur d'audit
        - La protection contre la suppression de l'archive
        - La protection contre la détérioration du support sur lequel l'archive est stockée, tel que la migration des donnée périodiquement sur un nouveau support.
        - La protection contre l'obsolescence du matériel, systèmes d'exploitation et autres logiciels.

- Les procédure de sauvegarde des archives
- Les pré-requis pour l'horodatage des enregistrements
- Si le système de collecte d'archive est interne ou externe
- Les procédures pour obtenir et vérifier les informations d'archive, tels que le besoin de maintenir 2 copies de l'archive sous le contrôle de 2 personnes, et que les 2 copies soient comparées pour s'assurer que les informations sont valides.

5.6 Renouvellement des clés

   Ce sous-composant décris les procédures pour fournir une nouvelle clé aux utilisateurs de la CA après un renouvellement de clé par la CA. Ces procédures peuvent être les même que les procédures pour fournir la clé courante. Également, la nouvelle clé peut être certifiée dans un certificat signé en utilisant l'ancienne clé.

5.7 Récupération après sinistre ou compromission

   Ce sous-composant décris les pré-requis liées à la notification et les procédures de récupérations dans le cas d'une compromission ou d'un sinistre. Chaque point suivant doit être adressé séparément

- L'identification ou la liste des incidents et compromissions applicable et les procédure de gestion et de reporting.
- Les procédures de récupération utilisée si les ressources informatiques, logiciels et/ou données sont corrompues ou suspectée comme tel. Ces procédures décrivent comment un environnement sécurisé est ré-établis, quels certificats sont révoqués, si la clé de l'entité est révoquée, comme la nouvelle clé publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les procédures de récupération utilisées si la clé de l'entité est compromise. Ces procédures décrivent comment un environnement est ré-établis, comme la nouvelle clé de l'entité publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les capacités de l'entité pour s'assurer de la continuité du business après un sinistre naturel ou autre. De telles capacités peuvent inclure la disponibilité d'un site distant sur lequel les opérations peuvent être récupérées. Il peut également inclure les procédures pour sécuriser ses facilités durant la période de temps suivant un désastre naturel ou autre et avant un rétablissement d'un environnement sécurisé, soit sur le site original, soit sur un site distant. Par exemple, les procédures pour protéger contre le vol de matériel sensible sur un site endommagé par un séisme.

5.8 Cessation de CA ou RA

   Ce sous-composant décris les requis liées aux procédures pour la notification de cessation et la cessation d'une CA ou RA, incluant l'identité du gardien des documents d'archive de la CA ou RA.

6. Contrôles de sécurité technique

   Ce composant est utilisé pour définir les mesures techniques prises par la CA émettrice pour protéger ses clés cryptographique et données d'activation (par ex, PIN, mot de passe, ou clé partagées gérées manuellement). Ce composant peut également être utilisé pour imposer des contraintes sur les dépôts, sujets CA, souscripteur, et autres participants pour protéger leur clés privées, données d'activation pour leur clé privées, et paramètres de sécurité critique. La gestion de clé sécurisé est critique pour s'assurer que tous les secrets et clés privées et données d'activation sont protégées et utilisés seulement par le personnel autorisé.

   Ce composant décris également d'autres contrôles de sécurité technique utilisées par la CA émettrice pour effectuer les fonctions sécurisées de génération de clé, d'authentification de l'utilisateur, d'enregistrement de certificat, de révocation de certificat, d'audit, et d'archivage. Les contrôle techniques incluent les contrôle de sécurité du cycle de vie ( incluant la sécurité de l'environnement de développement logiciel, la méthodologie de développement logiciel) et les contrôles de sécurité opérationnel.

   Ce composant peut également être utilisé pour définir d'autres contrôles de sécurité technique sur les dépôts, sujets CA, RA, souscripteurs, et autres participants.

6.1 Génération et installation de paire de clé

   La génération et l'installation de paire de clé doit être considéré pour la CA émettrice, les dépôts, sujets de CA, RA, et souscripteurs. Pour chacun de ces types d'entité, les questions suivantes peuvent potentiellement être répondues:

1. Qui génère l'entité publique, la paire de clé? Cela peut être le souscripteur, la RA, ou la CA. Également, comment est effectuée la génération de la clé? Est-ce que la génération de clé est faite par un hardware ou un software?
2. Comment est fournie la clé privée à l'entité de manière sécurisée? Par exemple, une situation où l'entité l'a généré et donc l'a déjà, qui manipule physiquement la clé privée, envoie un jeton contenant la clé privée de manière sécurisée ou en la délivrant dans une session SSL.
3. Comment la clé publique de l'entité est fournie de manière sécurisée à l'autorité de certification? Certaines possibilités sont dans une session SSL ou dans un message signé par la RA.
4. Dans le cas de la CA, comment la clé publique de la CA est fournie aux tiers de confiance de manière sécurisée.
5. Quels sont les tailles de clé?
6. Qui génère les paramètres de la clé publique, et est-ce que la qualité des paramètres sont vérifiés durant la génération?
7. Dans quel but la clé peut être utilisée, ou quel usage de clé est interdite? Pour les certificats X.509v3, ces but devraient être mappés dans les flags d'utilisation de clé.

6.2 Contrôles de Protection de clé privé et de module cryptographique

   Les pré-requis pour la protection de la clé privée et des modules cryptographiques doivent être considérés pour la CA emettrice, les dépôts, les sujets de CA, RA, et souscripteurs. Pour chacun de ces types ou entités, les questions suivantes doivent être répondue:

1. Quels standards, s'il y en a, sont requis pour le module cryptographique utilisé pour générer les clé? Un module cryptographique peut être composé de hardware, software, firmware, ou une combinaison. Par exemple, est-ce que les clé certifiées par l'infrastructure doivent être générés en utilisant des modules conformes FIPS 140-1? Si c'est le cas, quel est le niveau FIPS 140-1 du module? Y'a t'il une autre ingénierie ou d'autres contrôles liés au module cryptographique, tel que l'identification des limites du module cryptographique, l'entrée/sortie, les rôles et services, l'état de la machine, la sécurité physique, la sécurité logiciel, la sécurité du système d'exploitation, la conformité des algorithmes, la compatibilité éléctro-magnétique, et les selfs tests.
2. Est-ce que la clé privée est sous contrôle de n de m personnes. Si c'est le cas, fournir n et m (2 contrôleurs est un cas spécial où n=m=2)
3. Est-ce que la clé privée est entiercée? si c'est le cas, qui est l'agent d'entièrcement, sous quelle forme est la clé entiercée (texte clair, chiffré, splitté), et quels sont les contrôles de sécurités dans le système d'entièrcement?
4. Est-ce que la clé privée est sauvegardée? Si c'est le cas, qui est l'agent de sauvegarde, sous quelle forme est la clé sauvegardée, et quels sont les contrôles de sécurité dans le système de sauvegarde?
5. Est-ce que la clé privée est archivée? Si c'est le cas, qui est l'agent d'archivage, sous quelle forme est archivée la clé, et quels sont les contrôles de sécurité dans le système d'archivage?
6. Sous quelles circonstances, s'il y en a, la clé privée peut être transférée dans ou depuis un module cryptographique? Qui est autorisé à effectuer une telle opération de transfert? Sous quelle forme est la clé privée durant le transfert?
7. Comment est stocké la clé privée dans le module?
8. Qui peut activer (utiliser) la clé privée? Quelles actions doivent être effectués pour activer la clé privée (ex: login, mise en route, fournir un PIN, insérer la clé/jeton, automatique, etc.)? Une fois la clé activée, est-ce que la clé est active pour une période indéfinie, active pour une seule fois, ou pour une période définie?
9. Qui peut désactiver la clé privée et comment? des exemples des méthodes de désactivation de clés privée incluent la déconnexion, suppression de la clé/jeton, désactivation automatique, et date d'expiration.
10. Qui peut détruire la clé privée et comment? Par exemple, la remise symbolique, la destruction symbolique, et écraser la clé.
11. Fournir les capacité du module cryptographique dans les zones suivantes: identification des limites du module cryptographique, entrée/sortie, rôles et services, état de la machine, sécurité physique, sécurité logiciel, sécurité du système d'exploitation, conformité des algorithmes, compatibilité éléctromagnétique, et selfs tests. Les capacités peuvent être exprimés via une référence de conformité avec un standard tel que FIPS 140-1 et le niveau associé.

6.3 Autres aspects de la gestion de paire de clés

   D'autres aspects de gestion de clé doivent être considérés pour la CA émettrice, les dépôts, les sujets CA, RA, souscripteurs, et d'autres participants. Pour chacun de ces types d'entité, les questions suivante ont potentiellement besoins d'être répondues:

1. Est-ce que la clé publique est archivée? Si c'est le cas, qui est l'agent d'archivage et quels sont les contrôles de sécurité sur le système d'archivage? Également, quel logiciel et hardware doit être conservé comme partie de l'archive pour permettre d'utiliser la clé publique dans le temps? Note: ce sous-composant n'est pas limité aux requis aux pré-requis ou à la description de l'utilisation des signatures numériques avec les données d'archive, mais peut adresser les contrôles d'intégrité autre que les signatures numériques quand une archive nécessite une protection contre l'altération. Les signatures numériques ne fournissent pas de protection contre l'altération ou de protection de l'intégrité des données; Elles vérifient simplement l'intégrité des données. De plus, la période d'archivage peut être supérieur à une signature numérique appliquée à la donnée archivée.
2. Quel est la période opérationnelle des certificats émis au souscripteur. Quelles périodes d'utilisation, ou durée de vie, pour les paires de clé du souscripteur?

6.4 Données d'activation

   Les données d'activation réfèrent aux valeurs de données autre que les clé privées qui sont nécessaire pour opérer les clés privées ou les modules cryptographique contenant les clés privées, tels qu'un PIN, passphrases, ou portions d'une clé privée utilisées dans un schéma de splitting de clé. La protection des données d'activation empêchent l'utilisation non autorisée de la clé privée, et les besoins potentiels à considérer pour la CA émettrice, les sujets CA, RA, et les souscripteurs. Une telle considération nécessite potentiellement d'adresser tout le cycle de vie des données d'activation depuis la génération jusqu'à l'archivage et la destruction. Pour chaque types d'entité (CA émettrice, sujets CA, RA, souscripteur, et autres participants), toutes les questions listées en 6.1 à 6.3 peuvent potentiellement être répondus en respect des données d'activation au lieu du respect des clés.

6.5 Contrôles de sécurité informatique

   Ce sous-composant est utilisé pour décrire les contrôles de sécurité informatique tels que: l'utilisation de concept de base de calcul de confiance, le contrôle d'accès discrétionnaire, le contrôle d'accès obligatoire, la réutilisation d'object, l'audit, d'identification et l'authentification, les chemin de confiance, les tests de sécurité, et les tests de pénétration. L'assurance de produit peut également être adressé.

   Un taux de sécurité informatique pour les systèmes informatiques peut être requis. Le taux peut être basé, par exemple, sur le Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), ou le Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. Ce sous-composant peut également adresser les requis pour l'analyse de l'évaluation de produit, tests, profilage, certification de produit, et/ou accréditation de produit lié à l'activité entreprise.

6.6 Contrôles de sécurité du cycle de vie

   Ce sous-composant adresse les contrôles de développement système et les contrôles de gestion de la sécurité.

   Les contrôles de développement système incluent la sécurité de l'environnement de développement, la sécurité du personnel de développement, la sécurité de la gestion de configuration durant la maintenance produit, les pratique d'ingénierie logiciel, la méthodologie de développement logiciel, la modularité, couches, l'utilisation de concepts à sécurité intégrée et implémentation technique et sécurité des facilités de développement.

   Les contrôles de gestion de sécurité incluent l'exécution d'outils et de procédures pour s'assurer que les systèmes opérationnels et réseaux adhèrent à la sécurité configurée. Ces outils et procédures incluent la vérification de l'intégrité du logiciel de sécurité, firmware, et hardware pour s'assurer de leur opérations correct.

   Ce sous-composant peut également adresser le cycle de vie de la sécurité basé par exempel, sur Trusted Software Development Methodology (TSDM) niveau IV et V, independent life-cycle security controls audit, et Software Engineering Institute's Capability Maturity Model (SEI-CMM).

6.7 Contrôles de sécurité réseaux

   Ce sous-composant adresse les contrôles liés à la sécurité des réseaux, incluant les firewalls.

6.8 Horodatage

   Ce sous-composant adresse les requis ou pratiques liées à l'utilisation d'horodatage de diverses données. Il peut également discuter de si l'application de l'horodatage doit utiliser une source de temps fiable.

7. Profils de certificat et de CRL

   Ce composant est utilisé pour spécifier le format de certificat et, si des CRL et/ou OCSP sont utilisés, le format de CRL et/ou OCSP. Cela inclus les informations dans les profils, versions, et extensions utilisées.

7.1 Profil de certificat

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les versions supportées
- Les extensions de certificat utilisées et leur criticité
- Les identifiant d'objet d'algorithmes cryptographiques
- Les formes de nom utilisé pour la CA, RA, et les noms des souscripteurs
- Les contraintes de nom utilisés et les formes de nom utilisé dans les contraintes de nom
- Les OID de CP applicable
- L'utilisation de l'extension de contrainte de stratégie
- La syntaxe et sémantiques des qualifiants de stratégie
- Les sémantiques de traitement pour l'extension critique CP

7.2 Profile de CRL

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les numéro de version supportés
- Les extensions d'entrée de CRL utilisées et leur criticité

7.3 Profile OCSP

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 2560.

- La version d'OCSP qui est utilisé comme base pour établir un système OCSP
- Les extensions OCSP utilisés et leur criticité

8 Audit et autres évaluations de conformité

   Ce composant adresse les sujets suivants:

- La liste des sujets couverts par l'évaluation et/ou la méthodologie d'évaluation utilisée pour effectuer l'évaluation; par exemple WebTrust pour les CA et SAS 70.
- La fréquence de l'audit de conformité ou autres évaluations pour chaque entité qui doit être évalué conformément à une CP ou CPS, ou les circonstances qui vont déclencher une évaluation; par exemple un audit annuel, évaluation pré-opérationnelle comme condition d'autorisation pour une entité d'être opérationnelle, ou des investigations suivant une possible compromission de la sécurité.
- L'identité et/ou les qualifications du personnel effectuant l'audit ou autre évaluation.
- La relation entre l'évaluateur et l'entité qui est évaluée, incluant le degré d'indépendance de l'évaluateur.
- Les actions prises en résultat de déficience trouvé durant l'évaluation; par exemple, une suspension temporaire des opérations jusqu'à ce que la déficience soit corrigée, la révocation de certificats émis par l'entité évaluée, le changement de personnel, les investigations spéciales ou des évaluation de conformité plus fréquentes, et les demandes pour les dommages contre l'entité évaluée.
- Qui est habilité à voir les résultat d'une évaluation (ex, les entités évaluées, d'autres participant, tout le monde), qui leur fournis, et comment ils sont communiqués.

9 Autre questions juridiques et sur l'entreprise

   Ce sous-composant couvre les questions juridiques et liées à l'entreprise. Les sections 9.1 et 9.2 discutent des questions d'entreprise de redevances à percevoir pour divers services et les responsabilités financières des participants pour maintenir les ressources pour les opérations en cours et pour le payements des jugements ou règlement en réponse aux allégations formulées contre eux. Les sections restantes sont plus généralement concernés par les sujets légaux.

   À partir de la section 9.3, l'ordre des sujets est le même que l'ordre des sujets dans un agrément de licence logiciel ou autre agrément technologique. En conséquence, ce framework n'est pas seulement pour les CP et CPS, mais également associé aux agréments liés à la PKI, spécialement les agréments de souscripteur et de tiers de confiance. Cet ordre est prévu pour aider les avocats examinant les CP, CPS et autres documents qui adhèrent à ce cadre.

   En respect à de nombreux sous-composant légaux dans ce composant, une rédacteur de CP ou CPS peut choisir d'inclure dans le document les termes et conditions qui s'appliquent directement aux souscripteurs ou tiers de confiance. Par exemple, une CP ou CPS peut énoncer les limitations de responsabilité applicables aux souscripteurs et tiers de confiance. L'inclusion des termes et conditions est plus approprié dans les cas où la CP ou CPS est elle-même un contrat ou partie d'un contrat.

   Dans d'autres cas, cependant, la CP ou CPS n'est pas un contrat ou partie d'un contrat; à la place, elle est configurée pour que ses termes et conditions soient appliquées aux parties par des documents séparés, qui peuvent inclure des agréments associés, tels qu'un agrément de souscripteur ou tiers de confiance. Dans ce cas, un rédacteur de CP peut écrire une CP de façon à exiger que certaines conditions juridiques apparaissent (ou n'apparaissent pas) dans de tels agréments. Par exemple, une CP pour inclure un sous-composant statuant qu'un certain terme de limitation de responsabilité apparaisse dans les agréments de souscripteur et de tiers de confiance. Un autre exemple est une CP qui contient un sous-composant interdisant l'utilisation d'un agrément de souscripteur ou de tiers de confiance contenant une limitation de la responsabilité de la CA incompatible avec les disposition de la CP. Un rédacteur de CPS peut utiliser des sous-composants légaux pour divulguer que certains termes et conditions apparaissent dans des agréments de souscripteur, de tiers de confiance, ou d'autres, associé, utilisé par la CA. Une CPS peut expliquer, par exemple, que la CA écris qu'elle utilise un agrément de souscripteur ou de tiers de confiance associé qui applique une disposition particulière pour limiter la responsabilité.

9.1 Honoraires

   Ce sous-composant contient les dispositions applicables liés aux frais des CA, dépôts, ou RA, tels que:

- frais d'émission ou de renouvellement de certificat
- frais d'accès au certificat
- frais d'accès aux informations de status ou de révocation
- frais pour d'autres services tels que ceux fournissant l'accès aux CP ou CPS
- Stratégies de remboursement

9.2 Responsabilité financière

   Ce sous-composant contient les pré-requis ou les informations relatives aux ressources disponible aux CA, RA, et autres participants fournissant des services de certification pour supporter l'exécution de leurs responsabilité opérationnels, et pour rester solvable et payer les dommages dans le cas où ils sont tenus de payer un jugement ou un règlement dans le cadre d'une réclamation résultant de ces opérations. De telles dispositions incluent:

- Une déclaration que le participant maintient un certain montant de couverture d'assurance pour ses engagements envers les autres participants.
- Une déclaration que le participant a accès à d'autres ressources pour supporter les opérations et payer les dommages pour la responsabilité potentielle, qui peut être formulée en termes d'un niveau minimum d'actifs nécessaires pour opérer et couvrir les imprévus qui pourraient survenir au sein d'une PKI, par exemple, les actifs sur le bilan d'une organisation, un cautionnement, une lettre de crédit, et un droit en vertu d'un accord pour une indemnité sous certaines circonstances.
- Une déclaration qu'un participant a un programme qui offre une assurance de première partie ou la protection de garantie à d'autres participants dans le cadre de leur utilisation de la PKI.

9.3 Confidentialité des informations de l'entreprise

   Ce sous-composant contient les dispositions liées au traitement des information confidentielles de l'entreprise que les participants peuvent communiquer aux autres, tels que les business plan, informations de vente, secrets bancaires, et autres informations reçues d'un tiers de confiance sous un agrément de non-divulgation. spécifiquement, ce sous-composant adresse:

- Le périmètre de ce qui est considéré comme information confidentielle.
- Les types d'informations qui sont considérés hors périmètre des informations confidentielles
- Les responsabilités des participants qui reçoivent des informations confidentielles pour éviter une compromission, et éviter des les utiliser ou les divulguer à des tiers.

9.4 Confidentialité des renseignements personnels

   Ce sous-composant est lié à la protection que les participants, particulièrement les CA, RA, et dépôts, peut nécessiter pour permettre d'identifier les informations privées personnelles des candidats de certificat, souscripteurs, et autres participants. Spécifiquement, ce sous-composant adresse les éléments suivant:

- La désignation et divulgation du plan de protection des renseignements personnels applicables qui s'appliquent aux activités des participants, si requis par la stratégie ou la loi applicable.
- Les informations qui sont considérés ou non privée dans la PKI
- Toute responsabilité des participants qui reçoivent des informations privée pour les sécuriser, et éviter leur utilisation ou divulgation à des tiers.
- Tout prérequis pour avis, ou le consentement des individus concernant l'utilisation ou la divulgation d'informations privées.
- Toutes circonstances sous lesquelles un participants a droit ou est tenus de divulguer des informations privées en vertu judiciaire, traitement administratif dans un processus privée ou gouvernemental, ou tout traitement légal.

9.5 Droits de propriété intellectuelle

   Ce sou-composant adresse les droits de propriété intellectuelle, tels que les droits d'auteur, brevets, marques, ou secrets commerciaux, que certains participants peuvent avoir ou réclamer dans une CP, CPS, certificats, noms, et clés, ou font l'objet d'une licence ou de participant.

9.6 Représentations et garanties

   Ce sous-composant peut inclure des représentations et garanties de divers entités qui sont faites en vertu de la CP ou CPS. Par exemple, une CPS qui sert de contrat peut contenir une garantie de la CA que les informations contenus dans le certificat sont précis. Alternativement, une CPS peut contenir une garantie moins étendue où les informations dans le certificat sont vrai au mieux de la connaissance de la CA après avoir effectué certaines procédures d'authentification de l'identité. Ce sous-composant peut également inclure des prérequis que les représentations et garanties apparaissent dans certains agréments. Par exemple, une CP peut contenir un prérequis qui toutes les CA utilisent un agrément de souscripteur, et qu'un agrément de souscripteur doit contenir une garantie par la CA que les informations dans le certificat est précis. Les participants qui peuvent faire les représentation et garanties incluent les CA, RA, souscripteurs, tiers de confiance, et autres participants.

9.7 exclusions de garanties

   Ce sous-composant peut inclure des exclusions de garanties expresses qui pourraient être réputé exister dans un accord, et les exclusions de garanties implicites qui pourraient être imposées par la loi applicable, tels que les garanties de qualité marchande ou d'adéquation pour un but particulier. La CP ou CPS peut directement imposer de tels exclusions, ou la CP ou CPS peut maintenir une obligation que les exclusions apparaissent dans les agrément associés.

9.8 Limitations de responsabilité

   Ce sous-composant peut inclure des limitations de responsabilité dans une CP ou CPS ou des limitations qui apparaissent ou doivent apparaître dans un agrément associés avec la CP ou CPS. Ces limitations peuvent rentrer dans un des deux catégories: les limitations sur les éléments de dommages récupérables et les limitations sur la quantité de dommage récupérable, également connus sous le terme plafonnement de responsabilité. Souvent, les contrats contiennent des clauses empêchant la récupération d'éléments de dommage tels qu'un dommage accessoire et indirect, et les dommage punitifs. Fréquemment, les contrats contiennent des clauses qui limitent la possible récupération d'une partie ou l'autre à un certain montant ou à un montant correspondant à un indice de référence, tels que le montant qu'un vendeur a été payé en vertu du contrat.

9.9 Indémité

   Ce sous-composant inclus les dispositions par lesquelles un partie utilise envers un second partie pour les pertes ou dommages encourus par le second partie, résultant généralement de la conduite de la première partie. Ils peuvent apparaîtrent dans une CP, CPS, ou agrément. Par exemple, une CP peut nécessiter que les agréments de souscripteur contiennent un terme sous lequel un souscripteur est responsable de l'indemnisation de la CA pour les pertes que la CA soutient découlant de fausses déclarations d'un souscripteur dans la demande de certificat en vertu de laquelle la CA a émis au souscripteur un certificat inexact. Similairement, une CPS peut dire qu'une CA utilise un agrément de tiers de confiance, sous lequel les tiers de confiance sont responsable de l'indemnisation d'une CA en cas de perte que la CA soutient à cause de l'utilisation d'un certificat sans vérifier les informations de révocation de statut ou l'utilisation d'un certificat dans un but que la CA n'a pas permis.

9.10 Durée et résiliation

   Ce sous-composant peut inclure la durée dans laquelle une CP ou CPS demeure en vigueur et les circonstances sous lesquelles le document, portions du document, ou son applicabilité à un participant particulier peut être terminé. En plus ou alternativement, la CP ou CPS peut inclure les exigences que certaines clause de durée et de résiliation apparaissent dans un agrément. En particulier, de tels termes incluent:

- La durée d'un document ou agrément, c'est à dire, quand le document devient effectif et quand il expire s'il n'est pas résilié plus tôt
- Les dispositions de résiliation statuant sur les circonstances sous lesquelles le document, certaines portions, ou son application à un participant particulier cesse d'être en effet.
- Les conséquences de résiliation du document. Par exemple, certaines dispositions d'un agrément peuvent survivre à la résiliation et rester en vigueur. Des exemples incluent la connaissance des droits de propriété intellectuelle et les dispositions de confidentialité. Également, la résiliation peut impliquer une responsabilité des parties de retourner les informations confidentielles au partie qui l'a divulgué.

9.11 Remarques individuels et communications avec les participants

   Ce sous-composant discute de la manière par laquelle un participant peut ou doit communiquer avec un autre participant sur une base 1 à 1 pour qu'une telle communication soit légalement effective. Par exemple, une RA peut souhaiter informer la CA qu'elle souhaite terminer sont agrément avec la CA. Ce sous-composant est différent des fonctions de publication et de dépôt, parce contrairement aux communications individuelles décrites dans ce sous-composant, la publication et l'envoi dans un dépôt servent à communiquer à une large audience. Ce sous-composant peut établir des mécanismes pour communiquer et indiquer les informations de contact à utiliser pour router de telles communications, tel que les email signés numériquement à une adresse spécifique, suivie par un email signé d'accusé de réception.

9.12 Modifications

   Si sera occasionnellement nécessaire d'amender une CP ou CPS. Certains de ces changements ne vont pas réduire matériellement l'assurance qu'une CP ou son implémentation fournis, et sera jugé par l'administrateur de stratégie sur l'effet insignifiant de l'acceptabilité des certificats. De tels changement dans une CP ou CPS ne nécessitent pas de changement dans l'OID de CP ou le pointeur CPS. D'une autre manière, certains changements dans une spécification va changer matériellement l'acceptabilité des certificats pour des buts spécifiques, et ces changement peuvent nécessiter des changements correspondant à l'OID de la CP ou le pointeur CPS. Ce sous-composant peut également contenir les informations suivantes:

- Les procédures par lesquelles la CP ou CPS et/ou les autres documents doivent, peuvent être, ou sont amendés. Dans le cas des amendements de CP ou CPS, les procédures de changement peuvent inclure un mécanisme de notification pour fournir des avis de modifications proposées aux parties concernées, tels que les souscripteurs ou tiers de confiance, une période de commentaire, un mécanisme par lequel les commentaires sont reçus, revus, et incorporés dans le document, et un mécanisme par lequel les amendements deviennent effectifs.
- Les circonstances sous lesquelles les amendements de CP ou CPS nécessitent un changement d'OID ou pointeur de CPS.

9.13 Procédures de règlement de différends

   Ce sous-composant discute des procédures utilisée pour résoudre les différents découlant des CP, CPS et/ou agréments. Des exemples de telles procédures incluent l'exigence qu'un différent soit résolu dans un certain forum ou par des mécanismes de résolutions de différents alternatifs.

9.14 Lois gouvernementales

   Ce sous-composant énonce une déclaration que la loi d'une certaine juridiction régit l'interprétation et l'application de la CP ou CPS ou agréments.

9.15 Conformité avec les lois applicables

   Ce composant a trait aux conditions énoncées que les participants se conforment avec les lois applicables, par exemple, les lois liées au hardware et software cryptographique que peuvent être sujet aux lois de contrôle d'export d'une juridiction donnée. La CP ou CPS pourrait prétendre imposer de telles exigences ou peuvent exiger que ces dispositions figurent dans d'autres agréments.

9.16 Dispositions diverses

   Ce sous-composnat contient diverses dispositions, parfois appelé "dispositions passe-partout" dans les contrats. Les clauses couvertes dans ce sous-composant peuvent apparaître dans une CP, CPS, ou agréments et inclus:

- Une clause d'agrément entière, qui identifie typiquement le document ou les documents comprenant l'intégralité de l'agrément entrée les parties et status que ces agrément remplacent tous les accords antérieurs et actuels écris ou compris oralement relatifs à la même question.
- Une clause de cession, qui peut agir pour limiter la capacité d'un partie dans un agrément, l'attribution de ses droits en vertu de l'accord à un autre partie (comme le droit de recevoir un flux de paiement dans le future) ou de limiter la capacité d'un partie à déléguer ses obligations en vertu de l'accord.
- Une clause de divisibilité, qui énonce les intentions des parties dans le cas où une cour ou un autre tribunal détermine qu'une clause dans un agrément est, pour certaines raisons, invalides ou non-applicables, et dont le but est fréquemment d'empêcher l'inapplicabilité d'une clause causant l'ensemble de l'agrément inapplicable.
- Une clause d'application, qui peut indiquer qu'un partie gagnant dans un litige découlant d'un accord a droit à des honoraires d'avocats dans le cadre de sa récupération, ou peut statuer que le renoncement d'un partie d'une rupture de contrat d'un partie ne constitue par un renoncement permanent, ou un renoncement future ou autres violation de contrat.
- Un clause de force majeur, communément utilisée pour excuser la performance d'un ou plusieurs partie à un accord en raison d'un événement hors du contrôle raisonnable de ou des parties affectées. En règle générale, la durée de l'exécution dispensée est proportionnelle à la durée du retard causé par l'événement. La clause peut également prévoir la résiliation de l'accord dans les circonstances et conditions spécifiées. Les événements considérés pour constituer une force majeur peut inclure ce que l'on appelle les "actes de dieu", les guerres, terrorisme, grèves, catastrophes naturelles, défaillances de fournisseurs ou vendeurs, ou défaillances de l'internet ou autre infrastructure. Les clauses de force majeur doivent être rédigées de manière à être compatibles avec d'autres parties du framework et des agrément de niveau de service applicable. Par exemple, les responsabilités et les capacités de continuation d'activité et de reprise sur incident peut placer des événements sous le contrôle raisonnable des parties, telles qu'une obligation de maintenir une alimentation électrique de secours.

9.17 Autres Dispositions

   Ce sous-composant est "fourre-tout" où des responsabilités additionnelles et termes peuvent être imposés aux participants de la PKI qui ne rentre par nécessairement dans une autre catégorie de ce framework. Les rédacteurs de CP et CPS peut placer toute disposition dans ce sous-composant qui n'est pas couvert par un autre sous-composant.

Considérations de sécurité

   En accord avec X.509, une stratégie de certificat est un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des exigences de sécurité particulières. Une CP peut être utilisée par un tiers de confiance pour aider à décider si un certificat, et sa liaison, sont suffisamment dignes de confiance et appropriés à une application particulière.

   Le dégré auquel un tier de confiance peut avoir confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie d'opération de la CA, les procédures, et les contrôles de sécurité techniques, incluant de scope des responsabilités des souscripteurs (par exemple, en protégeant la clé privée), et les responsabilités statué et les termes de responsabilités de la CA (par exemple, les garanties, déclarations de garanties, et les limitations de responsabilité).

   Ce document fournis un framework pour adresser les aspects techniques, procédurales, personnelles, et physiques des autorités de certification, d'enregistrement, les dépôts, souscripteurs, et modules cryptographiques de confiance, pour s'assurer que la génération de certificats, la publication, le renouvellement, changement de clé, utilisation, et révocation est faite de manière sécurisée.

Plan d'un jeu de dispositions

   Cette section contient un plan recommandé pour un jeu de dispositions prévues pour servir de checklist ou de template standard à utiliser par les rédacteurs de CP ou CPS. Un tel plan facilite:

- La comparaison entre 2 stratégies de certificats durant la cross-certification ou d'autres formes d'interopérations.
- La comparaison d'une CPS avec une CP pour s'assurer que la CPS implémente fidèlement la stratégie
- La comparaison entrée 2 CPS.

   Afin de se conformer à cette rfc, les rédacteurs d'une CP ou CPS conformes sont fortement encouragés à adhérer à ce plan. Bien que l'utilisation d'un plan alternatif est découragé, il peut être accepté si une justification est fournie pour la déviation et une table de mappage est fournie pour discerner clairement où chaque éléments décris dans ce plan est fournis.


1. INTRODUCTION
1.1 Overview
1.2 Document name and identification
1.3 PKI participants
1.3.1 Certification authorities
1.3.2 Registration authorities
1.3.3 Subscribers
1.3.4 Relying parties
1.3.5 Other participants
1.4 Certificate usage
1.4.1. Appropriate certificate uses
1.4.2 Prohibited certificate uses
1.5 Policy administration
1.5.1 Organization administering the document
1.5.2 Contact person
1.5.3 Person determining CPS suitability for the policy
1.5.4 CPS approval procedures
1.6 Definitions and acronyms
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1 Repositories
2.2 Publication of certification information
2.3 Time or frequency of publication
2.4 Access controls on repositories
3. IDENTIFICATION AND AUTHENTICATION (11)
3.1 Naming
3.1.1 Types of names
3.1.2 Need for names to be meaningful
3.1.3 Anonymity or pseudonymity of subscribers
3.1.4 Rules for interpreting various name forms
3.1.5 Uniqueness of names
3.1.6 Recognition, authentication, and role of trademarks
3.2 Initial identity validation
3.2.1 Method to prove possession of private key
3.2.2 Authentication of organization identity
3.2.3 Authentication of individual identity
3.2.4 Non-verified subscriber information
3.2.5 Validation of authority
3.2.6 Criteria for interoperation
3.3 Identification and authentication for re-key requests
3.3.1 Identification and authentication for routine re-key
3.3.2 Identification and authentication for re-key after revocation
3.4 Identification and authentication for revocation request
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11)
4.1 Certificate Application
4.1.1 Who can submit a certificate application
4.1.2 Enrollment process and responsibilities
4.2 Certificate application processing
4.2.1 Performing identification and authentication functions
4.2.2 Approval or rejection of certificate applications
4.2.3 Time to process certificate applications
4.3 Certificate issuance
4.3.1 CA actions during certificate issuance
4.3.2 Notification to subscriber by the CA of issuance of certificate
4.4 Certificate acceptance
4.4.1 Conduct constituting certificate acceptance
4.4.2 Publication of the certificate by the CA
4.4.3 Notification of certificate issuance by the CA to other entities
4.5 Key pair and certificate usage
4.5.1 Subscriber private key and certificate usage
4.5.2 Relying party public key and certificate usage
4.6 Certificate renewal
4.6.1 Circumstance for certificate renewal
4.6.2 Who may request renewal
4.6.3 Processing certificate renewal requests
4.6.4 Notification of new certificate issuance to subscriber
4.6.5 Conduct constituting acceptance of a renewal certificate
4.6.6 Publication of the renewal certificate by the CA
4.6.7 Notification of certificate issuance by the CA to other entities
4.7 Certificate re-key
4.7.1 Circumstance for certificate re-key
4.7.2 Who may request certification of a new public key
4.7.3 Processing certificate re-keying requests
4.7.4 Notification of new certificate issuance to subscriber
4.7.5 Conduct constituting acceptance of a re-keyed certificate
4.7.6 Publication of the re-keyed certificate by the CA
4.7.7 Notification of certificate issuance by the CA to other entities
4.8 Certificate modification
4.8.1 Circumstance for certificate modification
4.8.2 Who may request certificate modification
4.8.3 Processing certificate modification requests
4.8.4 Notification of new certificate issuance to subscriber
4.8.5 Conduct constituting acceptance of modified certificate
4.8.6 Publication of the modified certificate by the CA
4.8.7 Notification of certificate issuance by the CA to other entities
4.9 Certificate revocation and suspension
4.9.1 Circumstances for revocation
4.9.2 Who can request revocation
4.9.3 Procedure for revocation request
4.9.4 Revocation request grace period
4.9.5 Time within which CA must process the revocation request
4.9.6 Revocation checking requirement for relying parties
4.9.7 CRL issuance frequency (if applicable)
4.9.8 Maximum latency for CRLs (if applicable)
4.9.9 On-line revocation/status checking availability
4.9.10 On-line revocation checking requirements
4.9.11 Other forms of revocation advertisements available
4.9.12 Special requirements re key compromise
4.9.13 Circumstances for suspension
4.9.14 Who can request suspension
4.9.15 Procedure for suspension request
4.9.16 Limits on suspension period
4.10 Certificate status services
4.10.1 Operational characteristics
4.10.2 Service availability
4.10.3 Optional features
4.11 End of subscription
4.12 Key escrow and recovery
4.12.1 Key escrow and recovery policy and practices
4.12.2 Session key encapsulation and recovery policy and practices
5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11)
5.1 Physical controls
5.1.1 Site location and construction
5.1.2 Physical access
5.1.3 Power and air conditioning
5.1.4 Water exposures
5.1.5 Fire prevention and protection
5.1.6 Media storage
5.1.7 Waste disposal
5.1.8 Off-site backup
5.2 Procedural controls
5.2.1 Trusted roles
5.2.2 Number of persons required per task
5.2.3 Identification and authentication for each role
5.2.4 Roles requiring separation of duties
5.3 Personnel controls
5.3.1 Qualifications, experience, and clearance requirements
5.3.2 Background check procedures
5.3.3 Training requirements
5.3.4 Retraining frequency and requirements
5.3.5 Job rotation frequency and sequence
5.3.6 Sanctions for unauthorized actions
5.3.7 Independent contractor requirements
5.3.8 Documentation supplied to personnel
5.4 Audit logging procedures
5.4.1 Types of events recorded
5.4.2 Frequency of processing log
5.4.3 Retention period for audit log
5.4.4 Protection of audit log
5.4.5 Audit log backup procedures
5.4.6 Audit collection system (internal vs. external)
5.4.7 Notification to event-causing subject
5.4.8 Vulnerability assessments
5.5 Records archival
5.5.1 Types of records archived
5.5.2 Retention period for archive
5.5.3 Protection of archive
5.5.4 Archive backup procedures
5.5.5 Requirements for time-stamping of records
5.5.6 Archive collection system (internal or external)
5.5.7 Procedures to obtain and verify archive information
5.6 Key changeover
5.7 Compromise and disaster recovery
5.7.1 Incident and compromise handling procedures
5.7.2 Computing resources, software, and/or data are corrupted
5.7.3 Entity private key compromise procedures
5.7.4 Business continuity capabilities after a disaster
5.8 CA or RA termination
6. TECHNICAL SECURITY CONTROLS (11)
6.1 Key pair generation and installation
6.1.1 Key pair generation
6.1.2 Private key delivery to subscriber
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to relying parties
6.1.5 Key sizes
6.1.6 Public key parameters generation and quality checking
6.1.7 Key usage purposes (as per X.509 v3 key usage field)
6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1 Cryptographic module standards and controls
6.2.2 Private key (n out of m) multi-person control
6.2.3 Private key escrow
6.2.4 Private key backup
6.2.5 Private key archival
6.2.6 Private key transfer into or from a cryptographic module
6.2.7 Private key storage on cryptographic module
6.2.8 Method of activating private key
6.2.9 Method of deactivating private key
6.2.10 Method of destroying private key
6.2.11 Cryptographic Module Rating
6.3 Other aspects of key pair management
6.3.1 Public key archival
6.3.2 Certificate operational periods and key pair usage periods
6.4 Activation data
6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data
6.5 Computer security controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.6 Life cycle technical controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security controls
6.7 Network security controls
6.8 Time-stamping
7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1 Certificate profile
7.1.1 Version number(s)
7.1.2 Certificate extensions
7.1.3 Algorithm object identifiers
7.1.4 Name forms
7.1.5 Name constraints
7.1.6 Certificate policy object identifier
7.1.7 Usage of Policy Constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical Certificate Policies extension
7.2 CRL profile
7.2.1 Version number(s)
7.2.2 CRL and CRL entry extensions
7.3 OCSP profile
7.3.1 Version number(s)
7.3.2 OCSP extensions
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1 Frequency or circumstances of assessment
8.2 Identity/qualifications of assessor
8.3 Assessor's relationship to assessed entity
8.4 Topics covered by assessment
8.5 Actions taken as a result of deficiency
8.6 Communication of results
9. OTHER BUSINESS AND LEGAL MATTERS
9.1 Fees
9.1.1 Certificate issuance or renewal fees
9.1.2 Certificate access fees
9.1.3 Revocation or status information access fees
9.1.4 Fees for other services
9.1.5 Refund policy
9.2 Financial responsibility
9.2.1 Insurance coverage
9.2.2 Other assets
9.2.3 Insurance or warranty coverage for end-entities
9.3 Confidentiality of business information
9.3.1 Scope of confidential information
9.3.2 Information not within the scope of confidential information
9.3.3 Responsibility to protect confidential information
9.4 Privacy of personal information
9.4.1 Privacy plan
9.4.2 Information treated as private
9.4.3 Information not deemed private
9.4.4 Responsibility to protect private information
9.4.5 Notice and consent to use private information
9.4.6 Disclosure pursuant to judicial or administrative process
9.4.7 Other information disclosure circumstances
9.5 Intellectual property rights
9.6 Representations and warranties
9.6.1 CA representations and warranties
9.6.2 RA representations and warranties
9.6.3 Subscriber representations and warranties
9.6.4 Relying party representations and warranties
9.6.5 Representations and warranties of other participants
9.7 Disclaimers of warranties
9.8 Limitations of liability
9.9 Indemnities
9.10 Term and termination
9.10.1 Term
9.10.2 Termination
9.10.3 Effect of termination and survival
9.11 Individual notices and communications with participants
9.12 Amendments
9.12.1 Procedure for amendment
9.12.2 Notification mechanism and period
9.12.3 Circumstances under which OID must be changed
9.13 Dispute resolution provisions
9.14 Governing law
9.15 Compliance with applicable law
9.16 Miscellaneous provisions
9.16.1 Entire agreement
9.16.2 Assignment
9.16.3 Severability
9.16.4 Enforcement (attorneys' fees and waiver of rights)
9.16.5 Force Majeure
9.17 Other provisions

^
25 septembre 2013

htmlpdflatexmanmd




rfc3671

rfc3671

Attributs collectifs

   Les attributs collectifs X500 permettent de partager des caractéristiques communes sur des collections d'entrées. Une collection d'entrées est un groupement d'objets et alias basés sur des propriété communes. Une collection d'entrées consiste de toutes les entrées dans un scope d'atttribus subentry collectifs. Une entrée peut appartenir à plusieurs collections.

   Les attributs partagés par les entrées dans une collection d'entrées sont appelés des attributs collectifs. Les valeurs de ces attributs sont visibles mais non modifiables par les clients. Ils sont modifiable via leur collective attributes subentry associé.

   Les entrées peuvent spécifiquement exclure un attribut collectif particulier en listant l'attribut dans collectiveExclusions. Comme d'autres attributs utilisateurs, les attributs collectifs sont sujet un contrôles d'accès, administratifs et de contenu.

   Les attributs opérationnels suivant sont utilisés pour gérer les attributs collectifs. Les serveurs LDAP doivent agir en accord avec les modèles d'annuaire X500 lorsqu'ils fournissent ce service.

collectiveAttributeSubentry

   Les sous-entrées de cette classe d'objet sont utilisées pour administrer les attributs collectifs et sont référés à des collective attribute subentry.

  ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )

   Un collective attribute subentry devrait contenir au moins un attribut collectif. Ces attributs sont disponible pour les opérations de recherche, comparaison pour toutes les entrées dans le scope de la sous-entrée. Les attributs collectifs sont cependant administrés via la sous-entrée. Les implémentations de cette spécification devraient supporter les sous-entrées d'attribut collectif dans les aires administratifs collectiveAttributeSpecificArea (2.5.23.5) et collectiveAttributeInnerArea (2.5.23.6) (RFC3672)

collectiveAttributeSubentries

Identifie toutes les collective atribute subentries qui affectent l'entrée
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )

collectiveExclusions

Permet d'exclure des attributs collectifs d'une entrée
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )

Collective Attribute Types

   Un type d'attribut utilisateur peut être définis comme collectif. Celà indique que ce même attribut va apparaitre dans les entrées d'une collection sujet à l'utilisation de l'attribut collectiveExclusions et autres contrôles administratifs. Les types d'attributs collectifs sont communément définis comme sous-type des types non collectifs. Par convention, les attributs collectifs sont nommés en préfixant le nom de leur supertype non collectif avec "c-". Par exemple, l'attribut telephoneNumber est nommé c-telephoneNumber.

   Les attributs collectifs ne devraient pas être SINGLE-VALUED et ne devraient pas apparaître dans les types d'attributs d'une définition de classe d'objet. Les attributs opérationnels ne devraient pas être définis comme collectif.


Collective Locality Name ( 2.5.4.7.1 NAME 'c-l' SUP l COLLECTIVE )
    
Collective State or Province Name ( 2.5.4.8.1 NAME 'c-st' SUP st COLLECTIVE )
    
Collective Street Address ( 2.5.4.9.1 NAME 'c-street' SUP street COLLECTIVE )
    
Collective Organization Name ( 2.5.4.10.1 NAME 'c-o' SUP o COLLECTIVE )
    
Collective Organizational Unit Name ( 2.5.4.11.1 NAME 'c-ou' SUP ou COLLECTIVE )
    
Collective Postal Address ( 2.5.4.16.1 NAME 'c-PostalAddress' SUP postalAddress COLLECTIVE )
    
Collective Postal Code ( 2.5.4.17.1 NAME 'c-PostalCode' SUP postalCode COLLECTIVE )
    
Collective Post Office Box ( 2.5.4.18.1 NAME 'c-PostOfficeBox' SUP postOfficeBox COLLECTIVE )
    
Collective Physical Delivery Office Name ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName' SUP physicalDeliveryOfficeName COLLECTIVE )
    
Collective Telephone Number ( 2.5.4.20.1 NAME 'c-TelephoneNumber' SUP telephoneNumber COLLECTIVE )
    
Collective Telex Number ( 2.5.4.21.1 NAME 'c-TelexNumber' SUP telexNumber COLLECTIVE )
    
Collective Facsimile Telephone Number ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber' SUP facsimileTelephoneNumber COLLECTIVE )
    
Collective International ISDN Number ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber' SUP internationalISDNNumber COLLECTIVE )

^
26 septembre 2013

htmlpdflatexmanmd




rfc3672

rfc3672

Subentries dans LDAP

   Dans les annuaires X500, les sous-entrées sont des entrées spéciales utilisées pour maintenir des informations associées avec une sous-arborescence. C’est un type d’entrée spécial subordonné à un point administratif. Il contient des attributs qui sont pertinents pour une sous-arborescence. Les sous-entrées et leur point administratif font partie du même contexte de nommage. Une simple sous-entrée peut servir de nombreux aspects de l’autorité administrative.

Subtree Specification Syntax

   Fournis un mécanisme général pour la spécification de jeu d’entrées dans une sous-arborescence du DIT. une sous-arborescence commence à une entrée de base et inclus tous les subordonnés. une subtree specification est toujours utilisée dans un contexte ou un scope qui détermine implicitement les limites de la sous-arborescence. Cette syntaxe correspond au type SubtreeSpecification (X501):


SubtreeSpecification ::= SEQUENCE {
    base [0] LocalName DEFAULT { },
    COMPONENTS OF ChopSpecification,
    specificationFilter [4] Refinement OPTIONAL }
    
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0 .. MAX)
    
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }

La syntaxe LDAP est :
( 1.3.6.1.4.1.1466.115.121.1.45 DESC ’SubtreeSpecification’ )

base Le composant base nomme l’entrée de base de la sous-arborescence. cette entrée peut être une sequence de RDN relatif à l’entrée root, ou vide si la base est le root lui-même.
Specific Exclusion Liste d’exclusion qui spécifie les entrées et leur subordonnés à exclure de l’arborescence. chaque entrée est une sequence de RDN relatif à l’entrée de base. Chaque exclusion est de forme chopBefore ou chopAfter. chopBefore exclue l’entrée et ses subordonnées, chopAfter exclue seulement les subordonnés.
Minimum est Maximum Permettent l'exclusion d'entrées basé sur leur profondeur dans le DIT
Specification Filter Expression booléenne sur l’assertion des valeurs de l’attribut objectClass de l’entrée de base et ses subordonnés. un élément d’assertion est évalué à TRUE pour une entrée si l’attribut objectClass de l’entrée contient l’OID nommé.

Types d'attributs de rôle administratif

L’attribut opérationnel administrativeRole est spécifié comme suit:
( 2.5.18.5 NAME ’administrativeRole’
    EQUALITY objectIdentifierMatch
    USAGE directoryOperation
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

Les valeurs possible pour cette attribut sont définis dans X.501:
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea

   L’attribut opérationnel administrativeRole est aussi utilisé pour réguler les sous-entrées qui ont le droit d’être subordonné à une entrée administrative. Une sous-entrée qui n’est pas d’une classe permise ne peut pas être subordonnée à cette entrée administrative.

Type d’attribut de spécification de sous-arborescence.
( 2.5.18.6 NAME ’subtreeSpecification’
    SINGLE-VALUE
    USAGE directoryOperation
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )

   Cet attribut est présent dans toutes les sous-entrées. nomme les collections d’entrées dans le DIT pour un ou plusieurs aspects de l’autorité administrative.

Classe d’objet subentry
( 2.5.17.0 NAME ’subentry’
    SUP top STRUCTURAL
    MUST ( cn $ subtreeSpecification ) )

Contrôle des sous-entrées

   Le contrôle des subentry peut être envoyé avec un searchRequest pour contrôler la visibilité des entrées qui sont dans le scope. Le contrôle est un contrôle LDAP dont controlType est 1.3.6.1.4.1.4203.1.10.1, et controlValue contient un booleen encodé BER indiquant la visibilité. Noter que la visibilité à true vaut { 01 01 FF } et FALSE vaut { 01 01 00 }.

Considérations de sécurité

   Les subentry maintiennent des informations administratives ou autre informations sensibles et devraient être protégés des accès non-autorisé.

Descripteurs
NAME Type OID
---- --------
accessControlInnerArea R 2.5.23.3
accessControlSpecificArea R 2.5.23.2
administrativeRole A 2.5.18.5
autonomousArea R 2.5.23.1
collectiveAttributeInnerArea R 2.5.23.6
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.17.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6

A: Attribute
O: objectClass
R: Administrative Role

Subtree spécification ABNF:
SubtreeSpecification = "{" [ sp ss-base ]
    [ sep sp ss-specificExclusions ]
    [ sep sp ss-minimum ]
    [ sep sp ss-maximum ]
    [ sep sp ss-specificationFilter ]
    sp "}"
    
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
    
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
    
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore " :" LocalName
chopAfter = id-chopAfter " :" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item " :" OBJECT-IDENTIFIER
and = id-and " :" Refinements
or = id-or " :" Refinements
not = id-not " :" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
    
BaseDistance = INTEGER-0-MAX

^
03 novembre 2013

htmlpdflatexmanmd




rfc3712

rfc3712

Schéma pour les services d'impression

objectClass

slpServicePrinter
( 1.3.18.0.2.6.254 NAME 'slpServicePrinter' DESC 'Service Location Protocol (SLP) information.' AUXILIARY SUP slpService )
printerAbstract
( 1.3.18.0.2.6.258 NAME 'printerAbstract' DESC 'Printer related information.' ABSTRACT SUP top MAY ( printer-name $ printer-natural-language-configured $ printer-location $ printer-info $ printer-more-info $ printer-make-and-model $ printer-multiple-document-jobs-supported $ printer-charset-configured $ printer-charset-supported $ printer-generated-natural-language-supported $ printer-document-format-supported $ printer-color-supported $ printer-compression-supported $ printer-pages-per-minute $ printer-pages-per-minute-color $ printer-finishings-supported $ printer-number-up-supported $ printer-sides-supported $ printer-media-supported $ printer-media-local-supported $ printer-resolution-supported $ printer-print-quality-supported $ printer-job-priority-supported $ printer-copies-supported $ printer-job-k-octets-supported $ printer-current-operator $ printer-service-person $ printer-delivery-orientation-supported $ printer-stacking-order-supported $ printer-output-features-supported ) )
printerService
( 1.3.18.0.2.6.255 NAME 'printerService' DESC 'Printer information.' STRUCTURAL SUP printerAbstract MAY ( printer-uri $ printer-xri-supported ) )
printerServiceAuxClass
( 1.3.18.0.2.6.257 NAME 'printerServiceAuxClass' DESC 'Printer information.' AUXILIARY SUP printerAbstract MAY ( printer-uri $ printer-xri-supported ) )
printerIPP
( 1.3.18.0.2.6.256 NAME 'printerIPP' DESC 'Internet Printing Protocol (IPP) information.' AUXILIARY SUP top MAY ( printer-ipp-versions-supported $ printer-multiple-document-jobs-supported ) )
printerLPR
( 1.3.18.0.2.6.253 NAME 'printerLPR' DESC 'LPR information.' AUXILIARY SUP top MUST ( printer-name ) MAY ( printer-aliases) )

Attributes

printer-uri
( 1.3.18.0.2.4.1140 NAME 'printer-uri' DESC 'A URI supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
printer-xri-supported
( 1.3.18.0.2.4.1107 NAME 'printer-xri-supported' DESC 'The unordered list of XRI (extended resource identifiers) supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
printer-name
( 1.3.18.0.2.4.1135 NAME 'printer-name' DESC 'The site-specific administrative name of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-natural-language-configured
( 1.3.18.0.2.4.1119 NAME 'printer-natural-language-configured' DESC 'The configured natural language in which error and status messages will be generated (by default) by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-location
( 1.3.18.0.2.4.1136 NAME 'printer-location' DESC 'The physical location of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-info
( 1.3.18.0.2.4.1139 NAME 'printer-info' DESC 'Descriptive information about this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-more-info
( 1.3.18.0.2.4.1134 NAME 'printer-more-info' DESC 'A URI for more information about this specific printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
printer-make-and-model
( 1.3.18.0.2.4.1138 NAME 'printer-make-and-model' DESC 'Make and model of this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-ipp-versions-supported
( 1.3.18.0.2.4.1133 NAME 'printer-ipp-versions-supported' DESC 'IPP protocol version(s) that this printer supports.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-multiple-document-jobs-supported
( 1.3.18.0.2.4.1132 NAME 'printer-multiple-document-jobs-supported' DESC 'Indicates whether or not this printer supports more than one document per job.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
printer-charset-configured
( 1.3.18.0.2.4.1109 NAME 'printer-charset-configured' DESC 'The configured charset in which error and status messages will be generated (by default) by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 SINGLE-VALUE )
printer-charset-supported
( 1.3.18.0.2.4.1131 NAME 'printer-charset-supported' DESC 'Set of charsets supported for the attribute values of syntax DirectoryString for this directory entry.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 )
printer-generated-natural-language-supported
( 1.3.18.0.2.4.1137 NAME 'printer-generated-natural-language-supported' DESC 'Natural language(s) supported for this directory entry.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.1563 )
printer-document-format-supported
( 1.3.18.0.2.4.1130 NAME 'printer-document-format-supported' DESC 'The possible source document formats which may be interpreted and printed by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-color-supported
( 1.3.18.0.2.4.1129 NAME 'printer-color-supported' DESC 'Indicates whether this printer is capable of any type of color printing at all, including highlight color.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
printer-compression-supported
( 1.3.18.0.2.4.1128 NAME 'printer-compression-supported' DESC 'Compression algorithms supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-pages-per-minute
( 1.3.18.0.2.4.1127 NAME 'printer-pages-per-minute' DESC 'The nominal number of pages per minute which may be output by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-pages-per-minute-color
( 1.3.18.0.2.4.1126 NAME 'printer-pages-per-minute-color' DESC 'The nominal number of color pages per minute which may be output by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-finishings-supported
( 1.3.18.0.2.4.1125 NAME 'printer-finishings-supported' DESC 'The possible finishing operations supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-number-up-supported
( 1.3.18.0.2.4.1124 NAME 'printer-number-up-supported' DESC 'The possible numbers of print-stream pages to impose upon a single side of an instance of a selected medium.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
printer-sides-supported
( 1.3.18.0.2.4.1123 NAME 'printer-sides-supported' DESC 'The number of impression sides (one or two) and the two-sided impression rotations supported by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-media-supported
( 1.3.18.0.2.4.1122 NAME 'printer-media-supported' DESC 'The standard names/types/sizes (and optional color suffixes) of the media supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-media-local-supported
( 1.3.18.0.2.4.1117 NAME 'printer-media-local-supported' DESC 'Site-specific names of media supported by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-resolution-supported
( 1.3.18.0.2.4.1121 NAME 'printer-resolution-supported' DESC 'List of resolutions supported for printing documents by this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15255 )
printer-print-quality-supported
( 1.3.18.0.2.4.1120 NAME 'printer-print-quality-supported' DESC 'List of print qualities supported for printing documents on this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-job-priority-supported
( 1.3.18.0.2.4.1110 NAME 'printer-job-priority-supported' DESC 'Indicates the number of job priority levels supported by this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-copies-supported
( 1.3.18.0.2.4.1118 NAME 'printer-copies-supported' DESC 'The maximum number of copies of a document that may be printed as a single job on this printer.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-job-k-octets-supported
( 1.3.18.0.2.4.1111 NAME 'printer-job-k-octets-supported' DESC 'The maximum size in kilobytes (1,024 octets actually) incoming print job that this printer will accept.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
printer-current-operator
( 1.3.18.0.2.4.1112 NAME 'printer-current-operator' DESC 'The identity of the current human operator responsible for operating this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-service-person
( 1.3.18.0.2.4.1113 NAME 'printer-service-person' DESC 'The identity of the current human service person responsible for servicing this printer.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 SINGLE-VALUE )
printer-delivery-orientation-supported
( 1.3.18.0.2.4.1114 NAME 'printer-delivery-orientation-supported' DESC 'The possible delivery orientations of pages as they are printed and ejected from this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-stacking-order-supported
( 1.3.18.0.2.4.1115 NAME 'printer-stacking-order-supported' DESC 'The possible stacking order of pages as they are printed and ejected from this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-output-features-supported
( 1.3.18.0.2.4.1116 NAME 'printer-output-features-supported' DESC 'The possible output features supported by this printer.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
printer-aliases
( 1.3.18.0.2.4.1108 NAME 'printer-aliases' DESC 'List of site-specific administrative names of this printer in addition to the value specified for printer-name.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15127 )
^
28 juillet 2015

htmlpdflatexmanmd




rfc3739

rfc3739

Profile de certificats qualifiés

   Ce document forme un profile de certificat, basé sur la rfc3280, pour les certificat d'identité émis à des personnes naturelles.

   Le profile définis les conventions spécifiques pour les certificats qui sont qualifiés avec un framework définis, les Certificat Qualifiés nommés. Cependant, le profile ne définis aucune exigence légale pour de tels certificats qualifiés.

   Le but de ce document est de définir un profile de certificat qui supporte l'émission de certificat qualifiés indépendamment des exigences légales. Le profile n'est cependant pas limité aux certificats qualifiés et le profile peut simplifier les besoins locaux.

   Cette spécification fait partie d'une famille de standards pour la PKI X.509 de l'Internet. Elle est basées sur X.509 et la rfc3280, qui définissent les formats de certificat sous-jacent nécessaire à l'implémentation complète de ce standard.

Exigences et hypothèses

   Ce terme "Qualified Certificate" est utilisé par la directive européenne pour les signature électroniques (EU-ESDIR) pour référer à un type spécifique de certificats, en conformité avec la législation européenne sur la signature électronique. Cette spécification est prévue pour supporter cette classe de certificats, mais son périmètre n'est pas limité à cette application.

   Dans ce standard, le terme "Qualified Certificate" est utilisé généralement, décrivant un certificat dont le but premier est d'identifier une personne avec un haut niveau d'assurance, où le certificat répond à des exigences de qualification définie par un framework légale applicable, tels que la directive européenne sur la signature électronique. Les mécanismes actuels qui décident si un certificat devrait ou non être considéré comme certificat qualifié au regard de la législation est hors du périmètre de ce standard.

   L'harmonisation dans le champs des certificats d'identité émis aux personnes naturelles, en particulier les certificats qualifiés, est essentiel dans de nombreux aspects qui sont hors du périmètre de la rfc3280. Les aspects les plus important qui affectent le périmètre de cette spécification sont:

- Définition des noms et informations d'identité pour pouvoir identifier le sujet associé d'une manière uniforme
- Définition des informations qui identifient la CA et la juridiction sous laquelle la CA opère en émettant un certificat particulier.
- Définition de l'extension d'utilisation de clé pour les certificats qualifiés
- Définition de la structure d'informations pour le stockage d'informations biométriques.
- Définition d'une méthode standardisée de stocker des états pré-définis d'intérêt pour des certificats qualifiés.
- Exigences pour les extensions critiques

Propriétés

   Ce profile adapte les besoins de profilage pour les certificats qualifiés basés sur les hypothèses que:

- Les certificats qualifiés sont émis par une CA qui qui déclare que le certificat sert le but d'un certificat qualifié
- Le certificat qualifié indique une stratégie de certificat conforme aux engagements, pratiques, et procédures entrepris par la CA.
- Le certificat qualifié est émis à une personne naturelle.
- Le certificat qualifié contient un nom qui peut être soit basé sur le vrai nom du sujet ou un pseudonyme.

Déclaration d'intention

   Ce profile définis les conventions pour déclarer dans un certificat qu'il sert l'objectif d'être un certificat qualifié. Cela permet à la CA de définir explicitement cette intention.

   Ce profile définis 2 méthodes pour inclure cette information:

- Comme information définie par une stratégie de certificat inclue dans l'extension de stratégies de certificat
- Comme déclaration inclue dans l'extension de déclaration de certificats qualifiés.

problématique de stratégie

   Certains aspects de stratégie définissent le contexte dans lequel ce profile est compris et utilisé. Il est cependant en dehors du scope de ce profile de spécifier une stratégie ou les aspects légaux qui vont gouverner les services qui émettent ou utilisent les certificat en accord avec ce profile.

   C'est cependant un hypothèse sous-jacente dans ce profile qu'une CA émettrice responsable va entreprendre de suivre une stratégie de certificat qui est consistante avec ses engagements, pratiques et procédure.

Unicité des noms

   Les noms distincts sont initialement définis dans X.501 comme représentation d'un nom d'annuaire, définis comme une construction qui identifie un objet particulier parmi un ensemble de tous les objets. Le nom distinct doit être unique pour chaque sujet certifié par une CA comme définie par le champ issuer, pour toute la durée de vie d'une CA.

Profile de certificat et d'extensions de certificat

   Cette section définis les conventions de profile de certificat. Le profile est basé sur le profile de certificat de l'Internet (rfc3280), qui lui-même est basé sur le format X.509v3. Pour une implémentation complète de cette section, les implémenteurs doivent consulter les formats et sémantiques définies dans la rfc3280.

Champs de certificat de base

   Cette section fournis des détails au regard du contenu de 2 champs dans le certificat de base. Ces champs sont issuer et subject.

Issuer

   Le champ issuer devrait identifier l'organisation responsable de l'émission du certificat. Le nom devrait être un nom officiellement enregistré de l'organisation.

   Le nom distinct de l'émetteur devrait être spécifié en utilisant le sous-jeu approprié les attributs suivants:

domainComponent
countryName
stateOrProvinceName
organizationName
localityName
serialNumber

   L'attribut domainComponent est définis dans la rfc2247, tous les autres attributs sont définis dans la rfc3280 et X.520.

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour identifier l'organisation émettrice.

   Un tiers de confiance peut avoir à consulter les stratégies de certificat associés et/ou la CPS de l'émetteur, pour pouvoir déterminer les sémantiques du nom des champs.

Subject

   Le champs subject d'un certificats conforme avec ce profile devrait contenir un nom distinct du sujet. Le champ subject devrait contenir un sous-jeu des attributs suivants:

domainComponent
countryName
commonName
surname
givenName
pseudonym
serialNumber
title
organizationName
organizationUnitName
stateOrProvinceName
localityName

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour distinguer un nom de sujet d'un autre nom de sujet. C'est à dire, les attributs listés ci-dessus sont suffisant pour s'assurer de l'unicité des noms de sujet.

   De ces attributs, le champs sujet devrait inclure au moins un des suivants:

Choix I: commonName
Choix II: givenName
Choix III: pseudonym

   La valeur de l'attribut countryName spécifie un contexte général dans lequel d'autres attributs sont compris. L'attribut country n'indique pas nécessairement le pays de citoyenneté ou de résidence du sujet, ni n'indique le pays d'émission.

   Note: de nombreuses implémentations X.500 nécessitent la présence de countryName dans le DIT. Dans les cas où le nom du sujet, comme spécifié dans le champ subject, spécifie une entrée d'annuaire X.500, l'attribut countryName devrait toujours être présent.

   L'attribut commonName devrait, si présent, contenir un nom du sujet. Cela peut être dans le format de présentation préféré du sujet, ou un format préféré par la CA, ou un autre format. Les pseudonymes, surnoms, et noms ayant une orthographe autre que définie par le nom enregistré peut être utilisé. Pour comprendre la nature du nom présenté dans commonName, les applications conformes peuvent avoir à examiner les valeurs présentes des attributs givenName et surname, ou l'attribut pseudonym.

   Note: de nombreuses implémentations client pré-supposent la présence de la valeur de l'attribut commonName dans le champ subject et utilisent cette valeur pour afficher le nom du sujet sans regarder la présence de givenName, surname, ou pseudonym.

   Les types d'attribut surname et givenName devraient être utilisés dans le champ suject si ni l'attribut commonName ni l'attribut pseudonym n'est présent. Dans les cas où le sujet a seulement givenName, l'attribut surname devrait être omis.

   Le type d'attribut pseudonym devrait, si présent, contenir un pseudonyme du sujet. L'utilisation de l'attribut pseudonym ne doit pas être combiné avec l'utilisation de l'attribut surname et/ou givenName.

   Le type d'attribut serialNumber devrait, si présent, être utilisé pour différencier entre les noms où le champ subject serait sinon identique. Cet attribut n'a pas de sémantique définie au-delà de s'assurer de l'unicité des noms des sujets. Il peut contenir un nombre ou un code assigné par la CA ou un identifiant assigné par un gouvernement ou une autorité civile. C'est de la responsabilité de la CA de s'assurer que le serialNumber est suffisant à résoudre toute collision du nom du sujet.

   Le type d'attribut title devrait, si présent, être utilisé pour stocker une position désignée ou fonction ou sujet dans l'organisation spécifiée par les attributs organisationnelle présent dans le champs subject. L'association entre le titre, le sujet, et l'organisation est au-delà du périmètre de ce document.

   Les types d'attribut organizationName et organizationalUnitName, si présents, sont utilisé pour stocker le nom et les informations essentielles d'une organisation avec lequel le sujet est associé. Le type d'association entre l'organisation et le sujet est au-delà du périmètre de ce document.

   Les types d'attribut stateOrProvinceName et localityName devraient, si présents, être utilisés pour stocker les information géographiques avec lequel le sujet est associé. Si une valeur organizationName est également présente, les valeurs d'attribut stateOrProvinceName et localityName devraient être associés avec l'organisation spécifiée. Le type d'association entre stateOrProvinceName et localityName et soit le subject ou organizationName est au-delà du périmètre de ce document.

   Les implémentations conformes devraient être capable d'interpréter les attributs nommés dans cette section.

Extensions de certificat

   Cette section fournis des détails additionnels sur le contenu des 4 extensions de certificats définis dans la rfc3280: subjectAltName, subjectDirectoryAttributes, certificate policies, et key usage. Cette section définis également 2 extensions additionnelles: informations biométriques et déclaration de certificat qualifié.

Subject Alternative Name

   Si l'extension subjectAltName est présent, et qu'elle contient un directoryName, alors le directoryName doit suivre la convention spécifié dans la section subject plus haut dans ce document.

Subject Directory Attributes

   L'extension subjectDirectoryAttributes peut être présente et peut contenir des attributs additionnels associés avec le sujet, comme complément aux informations présentes dans le champ subject et l'extension subjectAltName.

   Les attributs prévus pour le stockage dans cet extension sont les attributs qui ne font pas partie du nom distinct du sujet, mais qui peuvent être utiles pour d'autres buts (ex: autorisation). Cette extension ne doit pas être marquée critique.

   Les implémentations conformes devraient être capable d'interpréter les attributs suivants:

- dateOfBirth
- placeOfBirth
- gender
- countryOfCitizenship
- countryOfResidence

   D'autres attributs peuvent être inclus en accord avec les définitions locales.

   L'attribut dateOfBirth devrait, si présent, contenir la valeur de la date de naissance du sujet. La manière dans laquelle la date de naissance est associée avec le sujet est hors du périmètre de ce document. La date de naissance est définis au format GeneralizedTime et devrait préciser GMT 12.00.00 (midi) jusqu'à la granularité des secondes, pour empêcher les changements de date accidentels lié aux ajustement de zone. Par exemple, une date de naissance du 27 Septembre 1959 est encodé "19590927120000Z". Une application qui lit un certificat conforme devrait ignorer toute donnée de temps et simplement présenter la date contenue sans ajustement de zone.

   L'attribut placeOfBirth devrait, si présent, contenir la valeur du lieu de naissance du sujet. La manière dans laquelle le lieu de naissance est associé avec le sujet est au-delà du périmètre de ce document.

   L'attribut gender devrait, si présent, contenir la valeur du genre du sujet. Pour une femme la valeur 'F' ou 'f', et pour un homme la valeur 'M' ou 'm', doivent être utilisés. La manière dont le genre est associé avec le sujet est hors du périmètre de ce document.

   L'attribut countryOfCitizenship devrait, si présent, contenir l'identifiant d'au-moins un des pays de citoyenneté du sujet au moment où le certificat a été délivré. Si plus d'un pays est spécifié, chaque pays devrait être spécifié via un attribut countryOfCitizenship séparé. La détermination de la citoyenneté est une question de droit et est hors du périmètre de ce document.

   L'attribut countryOfResidence devrait, si présent, contenir la valeur d'au-moins un pays dans lequel le sujet réside. Si plus d'un pays de résidence est spécifié, chaque pays de résidence devrait être spécifié via un attribut countryOfResidence séparé. La détermination de résidence est une question de droit et est hors du périmètre de ce document.

Stratégies de certificat

   L'extension de stratégie de certificat devrait être présent et devrait contenir l'identifiant d'au-moins une stratégie de certificat qui reflète les pratiques et procédures utilisées par la CA. L'extension de stratégie de certificat peut être marquée comme critique.

   Les informations fournies par l'émetteur statuant le but du certificat, devrait être évident au travers de la stratégie indiquée.

   L'extension de stratégie de certificat doit inclure toutes les informations de stratégie nécessaire pour la validation de chemin de certification. Si les déclarations de stratégie connexes sont incluses dans l'extension QCStatements, alors ces déclarations devraient également être contenues dans les stratégies identifiées.

   Les stratégies de certificat peuvent être combinées avec tout qualifiant définis dans la rfc3280.

Utilisation de clé

   L'extension d'utilisation de clé devrait être présent. Les paramètres d'utilisation de clé devraient être définis en accord avec les définitions de la rfc3280. D'autres exigences sur les paramètres d'utilisation de clé peuvent être définis par stratégie locale et/ou exigences légales. L'extension d'utilisation de clé devrait être marqué critique.

Informations biométriques

   Cette section définis une extension optionnelle pour stocker les informations biométriques. Les informations biométriques sont stockés sous la forme d'un hash d'un modèle biométrique.

   Le but de cette extension est de fournir un moyen pour l'authentification d'information biométrique. Les informations biométriques qui correspondent au hash stocké ne sont pas stockés dans cette extension, mais l'extension peut inclure une URI (sourceDataUri) qui référence un fichier contenant cette information.

   Si inclus, l'URI doit utiliser le schéma http:// ou https://. Vu que les données d'identification en cours de vérification peuvent elles-même être des information sensibles, ceux qui déploient ce mécanisme peuvent également souhaiter considérer l'utilisation des URI qui ne peuvent pas être facilement liés par des tiers aux identités de ceux dont l'information est en cours de récupération.

   L'utilisation de l'option URI assume que le format d'encodage des données du contenu du fichier est déterminé via des moyens au-delà du périmètre de cette spécification, tel que les conventions de nommage de fichier et les méta-données dans le fichier. L'utilisation de cette URI n'implique pas que c'est la seule manière d'accéder à cette information.

   Il est recommandé que les informations biométriques dans cette extension soient limitées aux types d'informations utilisable pour la vérification humaine, par ex., lorsque la décision de savoir si l'information est une représentation précise du sujet est effectuée naturellement par une personne. Cela implique une utilisation où les informations biométriques soient représentée par, par exemple, une image affichée par le tiers de confiance, qui peut être utilisé par le tiers de confiance pour améliorer l'identification du sujet.

Cette extension ne doit pas être marquée critique.
biometricInfo EXTENSION ::= {
    SYNTAX BiometricSyntax
    IDENTIFIED BY id-pe-biometricInfo }
    
id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2}
    
BiometricSyntax ::= SEQUENCE OF BiometricData
    
BiometricData ::= SEQUENCE {
    typeOfBiometricData TypeOfBiometricData,
    hashAlgorithm AlgorithmIdentifier,
    biometricDataHash OCTET STRING,
    sourceDataUri IA5String OPTIONAL }
    
TypeOfBiometricData ::= CHOICE {
    predefinedBiometricType PredefinedBiometricType,
    biometricDataID OBJECT IDENTIFIER }
    
PredefinedBiometricType ::= INTEGER { picture(0),
    handwritten-signature(1)} (picture|handwritten-signature,...)
    

   L'image de type biométrique prédéfinie, si présent, devrait identifier que l'image source est sous la forme d'une image graphique affichable du sujet. Le hash de l'image graphique devrait être calculée sur tout le fichier image référencé.

   L'handwritten-signature de type biométrique prédéfinis, si présent, devrait identifier que la source de donnée est sous la forme d'une image graphique affichable de la signature manuscrite du sujet. Le hash de l'image graphique devrait être calculé sur tout le fichier image référencé.

Déclaration de certificat qualifié

   Cette section définis une extension optionnelle pour inclure les déclaration de propriétés explicites du certificat.

   Chaque déclaration devrait inclure un identifiant d'objet pour la déclaration et peut également inclure une donnée qualifiante optionnelle contenue dans le paramètre statementInfo.

   Si le paramètre statementInfo est inclus, alors l'identifiant d'objet de la déclaration devrait définir la syntaxe et devrait définir les sémantiques de ce paramètre. Si l'identifiant d'objet ne définis pas les sémantiques, un tiers de confiance peut avoir à consulter une stratégie de certificat ou CPS pour déterminer les sémantiques exactes.

   Cette extension peut être critique ou non. Si l'extension est critique, cela signifie que toutes les déclarations inclues dans l'extension sont considérés comme critique.


qcStatements EXTENSION ::= {
    SYNTAX QCStatements
    IDENTIFIED BY id-pe-qcStatements }
    
-- Note: cette extension en permet pas de mixer les déclarations de certificat qualifiés
-- critique et non-critique. Soit tout est critique, soit tous sont non-critique.
    
id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }
    
QCStatements ::= SEQUENCE OF QCStatement
QCStatement ::= SEQUENCE {
    statementId QC-STATEMENT.&Id({SupportedStatements}),
    statementInfo QC-STATEMENT.&Type({SupportedStatements}{@statementId}) OPTIONAL }
    
SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}

   Une déclaration approprié pour cette extension peut être une déclaration par l'émetteur que le certificat est émis comme certificat qualifié en accord avec un système légal particulier.

   D'autres déclarations appropriés pour cette extension peuvent être des déclaration liées aux juridictions légales applicables dans lequel le certificat est émis. Par exemple, on peut inclure une limite de confiance maximale pour le certificat indiquant les restrictions de la responsabilité de la CA.

Déclaration prédéfinies

   La déclaration de certificat (id-qcs-pkixQCSyntax-v1), identifie la conformité avec les exigences définis dans la rfc3039 obsolète. Cet déclaration est fournie pour l'identification des anciens certificats émis en conformité avec la rfc3039. Cette déclaration ne doit pas être inclue dans les certificats émis en accord avec ce profile.

   Ce profile inclus une nouvelle déclaration de certificat qualifié (identifié par l'OID id-qcs-pkixQCSyntax-v2), identifiant la conformité avec les exigences définies dans ce profile. Ce profile de certificat qualifié est référé à la version 2.

Cette déclaration identifie la conformité avec les exigences de la rfc3039. Cette déclaration peut optionnellement contenir des informations de sémantique additionnelles comme spécifié plus bas:
qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }

Cette déclaration identifie la conformité avec les exigences définis dans ce profile de certificat qualifié. Cette déclaration peut optionnellement contenir des informations de sémantiques additionnelles comme spécifié plus bas:
qcStatement-2 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v2 }
    
SemanticsInformation ::= SEQUENCE {
    semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL }
    (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
    WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
    
NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   Le composant SemanticsInformation identifié par id-qcs-pkixQCSyntax-v1 peut contenir un identifiant de sémantique et peut identifier un ou plusieurs nom d'autorité d'enregistrement.

   Le composant semanticsIdentifier, si présent, devrait contenir un OID, définissant les sémantiques pour les attributs et les noms dans les champs de base du certificat et les extensions. L'OID peut définir les sémantiques pour tout, ou pour un sous-groupe de tous les attributs présents et/ou les noms.

   Le composant NameRegistrationAuthorities, si présent, devrait contenir un nom d'une ou plusieurs autorité d'enregistrement, responsable pour l'enregistrement des attributs ou noms associés avec le sujet. L'association entre un nom identifié d'autorité d'enregistrement et les attributs présents peuvent être définis par un OID de sémantique, par une CP ou CPS, ou autre facteurs implicites.

   Si une valeur de type SemanticsInformation est présente dans un QCStatement où le composant statementID est mis à id-qcs-pkig-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2, alors au moins un des champs semanticsIdentifier ou nameRegistrationAuthorities doit être présent, comme indiqué. Noter que le composant statementInfo ne doit pas être présent dans une valeur QCStatement même si le composant statementID est mis à id-qcs-pkix-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2.

Considérations de sécurité

   La valeur légale d'une signature numérique qui est validée avec un certificat qualifié dépend hautement de la stratégie gouvernant l'utilisation de la clé privée associée. Le propriétaire de la clé privée, et le tiers de confiance, devraient s'assurer que la clé privée est utilisée uniquement avec le consentement du propriétaire légitime de la clé.

   Vu que les clés publiques sont pour une utilisation publique avec des implications légales pour les parties concernées, certaines conditions devraient exister avant qu'une CA émette des certificat comme certificats qualifiés. Les clés privées associées doivent être unique pour le sujet, et doivent être maintenue sous le contrôle exclusif du sujet. C'est à dire, une CA ne devrait pas émettre un certificat qualifié si les moyens d'utiliser une clé privée ne sont pas protégés contre les utilisation non-prévues. Cela implique que la CA ait une certaine connaissance du module cryptographique du sujet.

   La CA doit de plus vérifier que la clé publique contenue dans le certificat représente légitimement le sujet.

   La CA ne devrait pas émettre de certificats CA avec les extensions de mappage de stratégie indiquant l'acceptation d'une autre stratégie de CA sauf si les conditions sont rencontrées.

   En combinant le bit de nonRepudiation dans l'extension d'utilisation de clé avec d'autres bits d'utilisation de clé peut avoir des implication de sécurité en fonction du contexte dans lequel le certificat est utilisé. Les applications validant les signature électronique basés sur de tels certificats devraient déterminer si la combinaison d'utilisation de clé est approprié pour leur utilisation.

   La capacité de comparer 2 certificats qualifiés pour déterminer s'ils représentent la même entité physique est dépendante des sémantiques des noms des sujets. Les sémantiques d'une attribut particulier peut être différent pour différent émetteurs. En comparant les noms sans connaître les sémantiques des noms dans ces certificats particulier peut fournir de faux résultats.

   Cette spécification est un profile de la rfc3280. Les considérations de sécurité de ce document s'appliquent à cette spécification également.
^
17 septembre 2014

htmlpdflatexmanmd




rfc3829

rfc3829

Contrôles d'identité d'autorisation

   Ce document définis le support pour le contrôle de demande d'identité d'autorisation et le contrôle de réponse d'identité d'autorisation pour demander et retourner l'autorisation établie dans une opération bind. C'est utile quand il y a des étapes de mappage ou d'autre indirection durant le bind, le client peut savoir quelle identité a été autorisée. L'authentification client avec certificats est la principale situation où cela s'applique.

   Le support pour le contrôle de demande d'identité d'autorisation et le contrôle de réponse d'identité d'autorisation est indiqué par la présence de l'OID 2.16.840.1.113730.3.4.16 et 2.16.840.1.113730.3.4.15, respectivement, dans supportedControl du rootDSE.

Request

   Ce contrôle peut être inclus dans une demande bind dans le champ contrôles du LDAPMessage. Dans une opération bind a plusieurs étapes, le client doit fournir ce contrôle à chaque demande bind. controlType est 2.16.840.1.113730.3.4.16 et controlValue est absent.

Response

   Ce contrôle peut être inclus dans la réponse bind finale où la première demande bind a inclus de contrôle de demande. controlType est 2.16.840.1.113730.3.4.15. Si le bind a réussi et résulte en une identité ( non anonyme ), controlValue contient l'identité d'autorisation (authzId). Si le bind résulte en une association anonyme, controlValue est une chaîne vide. Si le bind résulte en plusieurs authzId, l'autzId primaire est retourné dans controlValue. Le contrôle est inclus uniquement dans une réponse bind dont le resultCode est success.

   Si le serveur nécessite des protections de confidentialité avant d'utiliser ce contrôle, le serveur reporte une erreur et retourne le code de retour confidentialityRequired.

   Si le client n'a pas les droits suffisants pour demander les informations d'autorisation, le serveur retourne le code insufficientAccessRights.

   Les identités présentés par un client comme partie du processus d'authentification peuvent être mappsé par le serveur à une ou plusieurs identités d'autorisation. Le contrôle de réponse bind peut être utilisé pour récupérer l'authzId primaire.

   Par exemple, durant l'authentification du client avec des certificats, un client peut posséder plus d'un certificat et ne peut pas être en mesure de déterminer lequel a été sélectionné pour l'authentification auprès du serveur. Le DN du champ sujet dans le certificat sélectionné peut ne pas correspondre exactement au DN dans l'annuaire, mais est passé par un processus de mappage dans le serveur. Une fois l'authentification par certificat complétée, le client peut fournir un bind SASL, spécifiant le mécanisme externe et incluant le contrôle de demande d'identité d'autorisation. La réponse peut inclure le contrôle de réponse d'identité d'autorisation indiquant le DN dans le DIT qui a été mappé.

Approche alternative

   L'opération étendue Who am I? fournis un mécanisme pour demander l'identité d'autorisation associée avec une connexion. Utiliser une opération étendue permet à un client d'apprendre d'identité d'autorisation après que le bind ait établis les protections d'intégrité et de confidentialité. Pour les environnements multithreadé ou à fort traffic, le contrôle étendu est préférable.
^
06 novembre 2013

htmlpdflatexmanmd




rfc3866

rfc3866

Language Tags and Ranges

   Il est souvent utile d'être capable d'indiquer le langage naturel associé avec les valeurs maintenus dans un annuaire et être capable de requêter l'annuaire sur des valeurs qui sont dans la langue que l'utilisateur demande.

Language Tags

   La section 2 de la BCP 47 (rfc 3066) décris le format de tag de langage qui est utilisé dans LDAP. brièvement, c'est une chaîne ASCII et '-'. ex: fr, en-US, ja-JP. ces tags sont insensible à la casse.

Language Ranges

   La section 2.5 de la BCP 47 (rfc 3066) décris les plages de langage. Un language range match un tag de langage s'il est égal à un préfix du tag. ex: la plage "de" match les tags "de" et "de-CH", mais pas "den". le range spécial "*" match tous les tags.

Attribute Descriptions

   Un attribut consiste d'un type, un jeu de 0 ou plusieurs options de tagging, et un jeu d'une ou plusieurs valeurs. Le type et les options sont combinés dans le AttributeDescription. AttributeDescription peut aussi contenir des options qui ne font pas partie de l'attribut, mais indiquent d'autres fonctions (tel que le range assertion ou le transfer encoding).

   Un AttributeDescription avec une ou plusieurs options de tagging est un sous-type direct de chaque AttributeDescription de même type avec toutes sauf une des options de tagging. Si le type d'AttributeDescription est un sous-type direct d'autres type, alors l'AttributeDescription est aussi un sous-type direct de l'AttributeDescription qui consiste du super-type et toutes les les options de tagging. donc, "CN;x-bar;x-foo" est un sous-type direct de "CN;x-bar", "CN;x-foo", et "name;x-bar;x-foo". Noter que "CN" est un sous-type de "name".

Utilisation des language tags dans LDAP

   Les serveurs qui supportent le stockage d'attributs avec des options de tag de langage dans le DIT devraient permettre à tout type d'attribut uns syntaxe chaîne d'avoir des options de tag de langage. Les serveurs peuvent permettre d'associer des options de langage avec d'autres type d'attributs.

  Les clients ne devraient pas assumer que les serveurs ont cette capacité.

  Les implémentations ne doivent pas interpréter la structure du tag en comparant 2 tags, et doivent les traiter simplement comme chaîne de caractère.

Options de tag de langage

   Un option de tag de langage associe un langage naturel avec des valeurs d'un attribut. Une description d'attribut peut contenir plusieurs attributs avec le même type d'attribut mais avec différentes combinaisons de tag de langage.

Une option de tag de langage en notation ABNF:
language-tag-option = "lang-" Language-Tag
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9

Exemples d'AttributeDescription valide:
givenName;lang-en-US
CN;lang-ja
SN;lang-de;lang-gem-PFL
O;lang-i-klingon;x-foobar
description;x-foobar
CN

Filtres de recherche

Par exemple, Un filtre d'égalité de type "name;lang-en-US" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-, wrong value)

   Noter que "CN" et "SN" sont des sous-type de "name"

Exemple, un filtre d'égalité de type "name" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray MATCHES
name: Billy Ray MATCHES
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (wrong value)

Attributs demandés dans la recherche

   Les clients peuvent fournir des options de tag de langage dans chaque AttributeDescrition dans la liste des attributs demandés. Si les options de tag de langage sont fournis, seul les attributs ayant la description sont retournés

exemple, si le client demande un attribut description, et une entrée qui match contient les attributs suivants:
objectClass: top
objectClass: organization
O: Software GmbH
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte

Le serveur devrait retourner:
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte

Compare

   Les tag peuvent être utilisés dans une requête compare. Le serveur les traites de la même manière que pour les recherches.

exemple, un requête compare de type "name" et une valeur d'assertion "Johann" avec une entrée:
objectClass: top
objectClass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius

   Le serveur devrait retourner compareTrue. Cependant, si le client demande un compare de type "name;lang-de", la requête échouera avec noSuchAttributeType.

Add

Les clients peuvent fournir ces tags dans AttributeDescription d'une nouvelle entrée à créer.exemple:
dn: CN=John Smith,DC=example,DC=com
objectClass: residentialPerson
CN: John Smith
CN;lang-en: John Smith
SN: Smith
SN;lang-en: Smith
streetAddress: 1 University Street
streetAddress;lang-en-US: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage

Modify

   Un client peut fournir ces tags dans un AttributeDescription comme partie d'un élement de modification. Les types d'attibuts et les options doivent matcher exactement les valeurs stockées dans l'annuaire.Par exemple, si la modification est 'delete', et que les valeurs à supprimer ont un tag de langage, ces options doivent être fournis dans l'opération modify.

Utilisation des plages de langage dans LDAP

   Une plage de langage, en notation ABNF:

  language-range-option = "lang-" [ Language-Tag "-" ]

  où language-Tag et définis dans la BCP 47.

Exemple d'AttributeDescription contenant des options de plage de langage:
givenName;lang-en-
CN;lang-
SN;lang-de-;lang-gem-
O;lang-x-;x-foobar

   Une option de plage de langage n'est pas une option de tagging. les attributs ne peuvent pas être stockés avec des options de plage de langage.

Filtres de recherche

   Si une option de plage de langage est présente dans un AttributeDescription dans une assertion, alors pour chaque entrée dans le scope, les valeurs de chaque attribut dont AttributeDescription consistent du même type d'attribut ou ses sous-type et contiennent un option de tag de langage correspondant sont retournés

exemple, un filtre d'égalité de type "name;lang-en-" et une valeur d'assertion "Billy Ray", avec l'entrée suivante:
dn: SN=Ray,DC=example,DC=com
objectClass: person DOES NOT MATCH (wrong type)
objectClass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray MATCHES
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-, wrong value)

Attributs demandés dans les opérations de recherche

   Les clients peuvent fournir des options de plage de langage dans chaque AttributeDescription dans la liste des attributs demandés dans une opération de recherche. Si le client demande l'attribut "name;lang-en-", le serveur pourrait retourner "name;lang-en-US" et "CN;lang-en;lang-ja", mais pas "SN" ni "name;lang-fr".

Comparaison

exemple, une requête compare de type "name;lang-" et une valeur d'assertion "Johann", avec l'entrée suivante:
objectClass: top
objectClass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
SN: Sibelius

   Le serveur devrait retourner compareTrue. Si le client avait fournis le type "name;lang-de", et la valeur d'assertion "Sibelius" avec l'entrée ci-dessus, la requête aurait échouée.

Découverte des options de langage

   Un serveur devrait indiquer qu'il supporte les options de tag de langage en publiant 1.3.6.1.4.1.4203.1.5.4 ( Language Tag Options ) et 1.3.6.1.4.1.4203.1.5.5 ( Language Range Options ) dans le rootDSE.
^
27 octobre 2013

htmlpdflatexmanmd




rfc3909

rfc3909

Opération Cancel

   L’opération étendue cancel (ou abandon), comme l’annuaire X.511 fournis une indication en retour. LDAP fournis l’opération Abandon qui permet d’annuler d’autres opérations. Cette opération n’a pas de réponse et ne nécessite pas de réponse de l’opération abandonnée. Cette sémantique ne fournis pas au client une indication claire de la sortie de l’opération Abandon. l’opération Cancel devrait être utilisé au lieu de l’opération Abandon quand le client a besoin d’une indication claire sur l’opération.

   l’opération Cancel est définie comme opération étendue, identifiée par l’OID 1.3.6.1.1.8

Requête Cancel

   La requête Cancel et une ExtendedRequest avec le champ requestName contenant 1.3.6.1.1.8 et un champ requestValue qui contient un valeur encodé BER cancelRequestValue.


cancelRequestValue::= SEQUENCE {
    cancelID MessageID }

   Le champs cancelID contient le message ID associé avec l’opération à annuler

Réponse Cancel

   Une réponse Cancel est une ExtendedResponseresponseName et les champs response sont absent

Codes de résultats additionnels

Les implémentations de cette spécification devraient reconnaitre les valeurs resultCode additionnels suivante:
canceled (118)
noSuchOperation (119)
tooLate (120)
cannotCancel (121)

Les classes d’opération suivante ne peuvent pas être annulées:
- les opérations qui n’ont pas de réponse
- les opérations qui établissent, altèrent ou détruisent des associations d’authentification et/ou d’authorisation
- les opérations qui établissent, altèrent ou détruisent des services de sécurité
- les opérations qui abandonnent ou annulent d’autres opérations

   Les serveurs devraient indiquer leur support pour cette extension en fournissant 1.3.6.1.1.8 dans supportedExtension.
^
08 novembre 2013

htmlpdflatexmanmd




rfc3928

rfc3928

LCUP: Client Update Protocol

   Ce protocole permet à un client LDAP de synchroniser le contenu d'un DIT et d'être notifié des changements du contenu. Il adresse les problèmes suivants:

   Lorsqu'un client utilise une copie local en lecture seul de l'annuaire et qu'il se connecte au réseau, il synchronise son contenu avec l'annuaire et peut optionnellement recevoir des notifications sur les changements qui se produisent pendant qu'il est en ligne. Par exemple, un client mail peut maintenir une copie local de l'adresse book qu'il synchronise avec la copie master quand le client est connecté au réseau de l'entreprise.

   Les applications qui synchronisent les données, une application meta-annuaire par exemple, va récupérer périodiquement une liste de modifications de l'annuaire, construire les changements, et les appliquer aux données stockées.

   Les clients qui ont besoin de prendre certaines actions quand une entrée d'annuaire est modifiée. Par exemple, un système de messagerie peut vouloir faire un 'create mailbox' quand une nouvelle personne est créée, et un 'delete mailbox' quand l'entrée est supprimée.

   Le problème suivant n'est pas adressé: La synchronisation entre serveurs d'annuaire.

   LCUP est conçus de telle sorte que le serveur n'a pas besoin de maintenir l'état des informations spécifique à chaque client. Le serveur peut maintenir des informations d'état additionnels sur la modification des attributs et autres. les clients sont responsable du stockage des informations sur la manière de mettre à jours leur données avec le contenu de l'annuaire. Le client décide quand et où récupérer les changements. LCUP nécessite que les clients initient la session update et "pull" les changements depuis le serveur.

applicabilité

   LCUP fonctionne mieux quand les conditions suivantes sont rencontrées:

1) le serveur stocke un certain degré d'informations d'état historique pour réduire la quantité de trafic requis pour les synchronisations incrémentales.
2) le client ne peut pas assumer comprendre le modèle d'information physique (attributs virtuels, opérationnels, subentries, etc.) implémentés par le serveur.

Spécification des éléments du protocole

Universally Unique Identifiers les DN peuvent changer, donc ils ne sont pas des identifiants fiables. Un UUID doit être utilisé avec LCUP. Le serveur doit fournir cet UUID en tant qu'attribut opérationnel single-value. (par exemple: entryUUID). LCUPUUID::= OCTET STRING
Schéma LCUP et cookie LCUP Le protocole LCUP utilise un cookie pour maintenir l'état des données client. Chaque format de cookie est identifié de manière unique avec son schéma. LCUPScheme::= LDAPOID. C'est l'OID qui identifie le format de la valeur du cookieLCUP. LCUPCookie::= OCTET STRING
contexte LCUP La partie du DIT qui est autorisé pour LCUP est appelé un contexte LCUP. Un serveur peut supporter un ou plusieurs contextes LCUP. Chaque contexte LCUP peut utiliser un schéma de cookie différent.

ResultCode additionnels

lcupResourcesExhausted (113) Le serveur n'a plus de ressources
lcupSecurityViolation (114) Le client est suspecté d'actions malicieuses
lcupInvalidData (115) Schéma ou cookie invalide
lcupUnsupportedScheme (116) Le schéma du cookie est un OID valide mais n'estpas supporté par ce serveur
lcupReloadRequired (117) Indique que les données client doivent être réinitialisées si le serveur ne contient pas suffisamment d'information pour synchroniser les données, ou si les données du serveur ont été rechargée depuis la dernière session de synchronisation.

Contrôle Sync Request

Ce contrôle a controlType à 1.3.6.1.1.7.1 et controlValue, un OCTET STRING contenant un syncRequestControlValue encodé BER:
syncRequestControlValue ::= SEQUENCE {
    updateType ENUMERATED {
        syncOnly (0),
        syncAndPersist (1),
        persistOnly (2) },
    sendCookieInterval [0] INTEGER OPTIONAL,
    scheme [1] LCUPScheme OPTIONAL,
    cookie [2] LCUPCookie OPTIONAL
}

   sendCookieInterval Le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update à chaque sendCookieInterval nombre de SearchResultEntry et SearchResultReference retourné au client. Par exemple, si la valeur est 5, le serveur devrait envoyer le cookie dans la valeur du contrôle Sync Update pour toutes les 5 recherches retournés au client. Si cette valeur est absente, 0 ou inférieur à 0, le serveur choisis l'interval.

  Ce contrôle est seulement applicable au message searchRequest.

Contrôle Sync Update

Ce contrôle a controlType à 1.3.6.1.1.7.2 et controlValue un OCTET STRING contenant le syncUpdateControlValue encodé BER:
syncUpdateControlValue ::= SEQUENCE {
    stateUpdate BOOLEAN,
    entryUUID [0] LCUPUUID OPTIONAL, — REQUIRED for entries —
    UUIDAttribute [1] AttributeType OPTIONAL,
    entryLeftSet [2] BOOLEAN,
    persistPhase [3] BOOLEAN,
    scheme [4] LCUPScheme OPTIONAL,
    cookie [5] LCUPCookie OPTIONAL
}

   UUIDAttribute contient le nom ou l'OID de l'attribut que le client devrait utiliser pour effectuer les recherches pour les entrées basée sur l'UUID. Le client devrait être capable de l'utiliser dans un filtre de recherche d'égalité, par exemple "(‹uuid attribute›=‹entry UUID value›)" et devrait être capable de l'utiliser dans la liste des attributs de requête search pour retourner ses valeurs. UUIDAttribute peut être omis si le serveur ne supporte pas les recherches sur les valeurs UUID.

Contrôle Sync Done

Ce contrôle a controlType à 1.3.6.1.1.7.3 et controlValue contenant un syncDoneValue encodé BER:
syncDoneValue ::= SEQUENCE {
    scheme [0] LCUPScheme OPTIONAL,
    cookie [1] LCUPCookie OPTIONAL
}
   Un client initie une synchronisation ou une session de recherche persistente avec un serveur en attachant un Sync Request à un message searchRequest. La spécification de recherche détermine le DIT, le jeu d'attributs et la quantité de données que le client veut recevoir. Le contrôle Sync Request contient la spécification de requête du client. S'il y'a une condition d'erreur, le serveur doit retourner SearchResultDone avec un resultCode approprié à l'erreur.

Synchronisation initiale et re-synchronisation complète

   Les champs du contrôle Sync Request doivent être spécifiés comme suit:

updateType Doit être mis à syncOnly ou syncAndPersist
sendCookieInterval Peut être définis
scheme Peut être définis. si définis, le serveur doit utiliser ce schéma ou retourner lcupUnsupportedScheme, sinon, le serveur peut utiliser tout schéma qu'il supporte
cookie Ne doit pas être définis.

Synchronisation incrémentale et de mise à jours

   Les champs du contrôle Sync Request doivent être spécifiés comme suit:

updateType Doit être à syncOnly ou syncAndPersist
sendCookieInterval Peut être définis
scheme Doit être définis
cookie Doit être définis

   Le client devrait toujours utiliser le dernier cookie reçu par le serveur.

Persistent Only

   Les champs de Sync Request doivent être spécifié comme suit:

updateType Doit être à persistOnly
sendCookieInterval Peut être définis
scheme Peut être définis
cookie Peut être définis, mais le serveur doit l'ignorer.
   Dans la réponse au client, le serveur retourne 0 ou plusieurs SearchResultEntry ou SearchResultReference, suivis par un SearchResultDone. Chaque SearchResultEntry ou SearchResultReference contient aussi un contrôle Sync Update qui décrit l'état LCUP de l'entrée retournée. SearchResultDone contient un contrôle Sync Done.

Réponses Sync Update Informational

   Le serveur peut utiliser le contrôle Sync Update pour retourner des informations non liées à une entrée particulière. Il peut le faire à tout moment pour retourner un cookie au client, ou pour informer le client que la phase de sync d'une recherche syncAndPersist est complète et que la phase persist a commencé. Il peut le faire durant la phase persist même quand aucune entrée n'a changé/ Pour faire çà, il faut retourner:

- un PDU SearchResultEntry avec objectName contenant le DN de baseObject de la requête de recherche et avec un attribut list vide.
- Un contrôle Sync Update avec les champs définis comme suit :

stateUpdape Doit être à TRUE
entryUUID Devrait être l'UUID du baseObject de la requête search
entryLeftSet Doit être à FALSE
persistPhase Doit être FALSE si la recherche est dans la phase sync et TRUE si elle est dans la phase persist.
UUIDAttribute Devrait seulement être définis si c'est soit le premier résultat retourné soit l'attribut a changé
scheme Doit être définis si le cookie est définis et que le format a changé, sinon il peut être omi.
cookie Devrait être définis

   Durant une requête SyncAndPersist, le serveur doit retourner immédiatement après que la dernière entrée de la phase sync ait été envoyée et avant que la première entrée de la phase persist ait été envoyée. Celà permet au client de savoir quand la phase sync se termine et quand la phase persist commence.
   Le champ cookie d'un contrôle Sync Update peut être définis dans tout résultat retourné, durant la phase sync et persist. Le serveur devrait retourner le cookie suffisamment souvent pour que le client resynchronise dans une période de temps raisonnable en cas de déconnections par ex. Le champ sendCookieInterval est une suggestion au serveur et il devrait respecter cette valeur.

  Le champ scheme doit être définis si le cookie est présent et que le format a changé, sinon il peut être omis.

Définition d'une entrée qui entre dans le jeu de résultat

   Une entrée doit être considérée rentrer dans le jeu de résultat de la recherche du client si un des conditions est rencontrée:

- Durant la phase sync pour une opération sync incrémentale, l'entrée est présent dans le jeu de résultat de la recherche mais n'était pas présente avant ; typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.
- Durant la phase persist pour une opération de recherche persistante, l'entrée entre dans le jeu de résultat de recherche, typiquement une entrée qui a été ajoutée ou déplacée dans l'annuaire.

Définition d'une entrée qui a changé

   Une entrée doit être considérée changée si un ou plusieurs de ses attributs dans la liste des attributs de la recherche ont été modifiés.

Définition d'une entrée qui a quitté le jeu de résultat

   Une entrée doit être considérée sortie du jeu de résultat si elle rencontre une de ces conditions:

- Durant la phase sync, l'entrée n'est pas présente dans le jeu de résultat mais était présent avant.
- Durant la phase persist, l'entrée quitte le jeu de résultat.

Résultats pour les entrées présentes dans le jeu de résultat

   Une entrée devrait être retournée présente sous les conditions suivante:

- La requête est une synchronisation initiale pour une requête full resync et l'entrée est présent dans le jeu de résultat de la recherche du client.
- La requête est une synchronisation incrémentale et l'entrée a changé ou est entrée dans le jeu de résultat depuis la dernière synchronisation.
- La recherche est dans la phase persist et l'entrée entre dans le jeu de résultat ou change.

   Pour un retour SearchResultEntry, les champs du contrôle Sync Update doivent être définis comme suit:

stateUpdate Doit être FALSE
entryUUID Doit être l'UUID de l'entrée
entryLeftSet Doit être FALSE
persistPhase Doit être FALSE durant la phase sync, TRUE durant la phase Persist
UUIDAttribute Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé
schema comme plus haut
cookie Comme plus haut

Résultat pour les entrées qui ont quitté le jeu de résultat

   Une entrée devrait être considéré ayant quitté le jeu de résultat si elle est dans les conditions suivantes:

- La requête est une synchronisation incrémentale durant la phase sync et l'entrée est sortie du jeu de résultat
- La recherche est dans la phase persist et l'entrée a quitté le jeu de résultat
- L'entrée a quitté le jeu derésultat suitte à un LDAP delte ou ldap ModifyDN

stateUpdate Doit être FALSE
entryUUID Doit être l'UUID de l'entrée qui a quitté le jeu de résultat
entryLeftSet Doit être TRUE
persistPhase Doit être FALSE durant la phase sync, TRUE durant la phase Persist
UUIDAttribute Devrait être définis seulement si c'est le premier résultat retourné ou si l'attribut a changé
schema comme plus haut
cookie Comme plus haut

Retourner les résultats durant la phase persistante

   Le serveur devrait retourner les entrées changées au client le plus rapidement possible

Pas de mixe de phase sync et persist

   Durant la phase sync, le serveur ne doit pas retourner d'entrée avec le flag persistPhase à TRUE et durant la phase persisit ce flag doit être à TRUE.

Retourner les résultats mis à jours durant la phase sync

   Il peut y avoir des mises à jours des entrées dans le jeu de résultats durant l'opération de recherche. Si le serveur est surchargé de mises à jours et qu'il tente d'envoyer toutes ces mises à jours, il peut ne jamais terminer la phase sync. C'est à la discretion de l'implémentation du serveur de décider quand le client est en "in sync", c'est à dire quand se termine un suncOnly ou quand envoyer la réponse Update Informational entre les phases sync et persist.

Attributs opérationnels et entrées administratives

   Ils devraient être retournés tels qu'il seraient retournés dans une recherche normal. Si le serveur ne supporte pas la synchronisation des attributs opérationnel, le serveur doit retourner SearchResultDone avec un result unwillingToPerform

Garantie de convergence

   Si durant une recherche LCUP soit durant la phase sync ou persist, le serveur détermine qu'il ne peut pas garantir la délivrance de la copie au client pour une éventuelle convergence, il devrait immédiatement terminer la recherche LCUP et retourner un resultCode lcupReloadRequired.

Fin de recherche LCUP

Fin initiée par le serveur Quand le serveur a terminé le traitement avec succès, il attache un contrôle Sync Done au message SearchResultDone et il l'envoie au client. Cependant, si le resultCode de ce message est différent de success ou canceled, le contrôle Sync Done peut être omis. Le cookie doit être présent si resultCode est success ou canceled. Il devrait être présent si le resultCode est lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, ou adminLimitExceeded. Celà permet au client de resynchroniser plus facilement.
Fin initiée par le client Si le client doit terminer la synchronisation et veut obtenir le cookie qui représente l'état courant, il fournis une opération LDAP Cancel. Le serveur répond immédiatement avec une réponse LDAP Cancel.
Limite de temps et de taille Le serveur doit supporter les limites de taille et de temps. Le serveur doit s'assurer que si l'opération est terminée dû à ces conditions, le cookie est renvoyé au client.
Opération sur la même connexion Il est permis au client de fournis des opérations LDAP sur la connexion utilisé par le protocole.
Intéraction avec d'autres contrôles LCUP ne définit pas de restriction ni ne garantie la capacité d'utiliser les contrôles de ce document avec d'autres contrôles.
Considérations de réplication L'utilisation d'un cookie LCUP avec plusieurs DSA dans un environnement répliqué n'estpas définis parLCUP. Une implémentation LCUP peut supporter la continuation de session avec un autre DSA. Les clients peuvent envoyer des cookies retournés par un DSA à un autre DSA.

Considérations côté client

Utiliser les cookies avec différents critères de recherche Le cookie reçu d'un serveur après une session de synchronisation devrait seulement être utilisé avec les même spécifications de recherche qui ont généré le cookie.
Manipulation de référrant Le client peut reçevoir un référrant quandla recherche de base est une référence subordonnées et va terminer l'opération.

Considération d'implémentation serveur

Support des UUID Les serveurs doivent supporter les UUID.
Exemple en utilisant un RUV comme valeur de cookie Par concept, le protocole supporte plusieurs schéma de cookie, ce qui permet à différentes implémentations la flexibilité du stockage des informations. Une implémentation raisonnable serait d'utiliser le ReplicaUpdate Vector. Pour chaque Master, RUV contient le plus grand CSN vu par ce master. En plus, RUV implémenté par certains serveurs contiennent une génération de réplica, un chaîne opaque qui identifie le stockage des données de réplica. La valeur change quand les données sont rechargées. La génération de réplica est utilisé pour signaler aux parties de réplication/synchronisation que les données de réplica ont été rechargée et que tous les autres réplica doivent être réinitialisées.
Support pour plusieurs schéma de cookie Un serveur doit publier les OID des schéma de cookie supportés
^
21 juin 2016

htmlpdflatexmanmd




rfc4033

rfc4033

Introduction à la sécurité DNS et aux pré-requis

   Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS.

Définition des termes DNSSEC important

Authentication Chain Une séquence alternée de RRsets de clé publique DNS (DNSKEY) et de RRset de Delegation Signer (DS) forment une chaîne de donnée signée, et chaque lien dans la chaîne étant garant de la suivante. Un RR DNSKEY est utilisé pour vérifier la signature couvrant un RR DS et permet au RR DS d'être authentifié. Le RR DS contient un hash d'un autre RR DNSKEY et ce nouveau RR DNSKEY en retour authentifie un autre RRset DNSKEY et , en retour, certains RR DNSKEY dans ce jeu peuvent être utilisés pour authentifiier un autre RR DS, et ainsi de suite jusqu'à ce que la fin de la chaîne se termine avec un RR DNSKEY dont la clé privée correspondante signe la donnée DNS souhaitée. Par exemple, le RRset DNSKEY root peut être utilisé pour authentifier le RRset DS pour "example.". Le RRset DS "example." contient un hash qui matche une DNSKEY "example.", et la clé privée correspondante à ce DNSKEY signe le RRset DNSKEY "example." Les RRset DNSKEY signe les données enregistré tel que "www.example." et les RR DS pour les délégation comme "subzone.example."
Authentication key Une clé publique qu'un résolveur a vérifié et peut ainsi l'utiliser pour authentifier les données. Un résolveur peut obtenir les clés d'authentification de 3 manières. D'abord, le résolveur est généralement configuré pour connaître au moins une clé publique; cette donnée configurée est généralement soit la clé publique elle-même ou un hash de la clé publique tel que trouvé dans le RR DS. Ensuite, le résolveur peut utiliser une clé publique authentifiée pour vérifier un RR DS et le RR DNSKEY pour lequel le RR DS réfère. Enfin, le résolveur peut être capable de déterminer qu'une nouvelle clé publique a été signée par la clé privée correspondante à une autre clé publique que le résolveur a vérifié. Noter que le résolveur doit toujours être guidé par la stratégie locale quand il décide d'authentifier une nouvelle clé publique même si la stratégie locale est simplement pour authentifier une nouvelle clé publique pour laquelle le résolveur est capable de vérifier la signature.
Authoritative RRset Dans le contexte d'une zone particulière, un RRset est authoritatif si et seulement si le nom propriétaire du RRset est dans le sous-jeu de l'espace de nom qui est au niveau ou sous le zone apex et au niveau ou sous la séparation de la zone de ses enfant, s'il y en a. Tous les RRsets dans la zone apex sont authoritatifs, excepté pour certains RRsets à ce nom de domaine qui, si présent, appartient au parent de cette zone. Ces RRset peuvent inclure un RRset DS, le RRset NSEC référençant ce RRset DS (le NSEC parental), et les RR RRSIG associés avec ces RRset, tous étant authoritatif dans la zone parente. Similairement, si cette zone contient des points de délégation, seul le RRset NSEC parent, les RRsets DS, et tou RR RRSIG associés avec ces RRsets sont autoritatifs pour cette zone
Delegation Point Terme utilisé pour décrire le nom côté parent d'une coupure de zone. C'est à dire, le point de délégation pour "foo.example" serait le nœud foo.example dans la zone "example" (opposé à l'apex de zone de la zone foo.example").
Island of Security Termet utilisé pour décrire une zone signée et déléguée qui n'a pas de chaîne d'authentification de son parent déléguant. C'est à dire qu'il n'y a pas de RR DS contenant un hash d'un RR DNSKEY pour l'île dans la zone du parent déléguant. Une île de sécurité est désservie par des serveurs de nom sécurisés et peut fournir des chaînes d'authentification à toute zone enfant déléguée. Les réponses d'une île de sécurité ou ses descendants peut seulement être authentifié si ses clés d'authentification peuvent être authentifiés par un moyen de confiance en dehors du protocole DNS
Key Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une ou plusieurs autres clé d'authentification pour une zone donnée. Typiquement, la clé privée correspondant à une KSK va signer une clé de signature de zone, qui en retour a une clé privée correspondante qui va signer les données de la zone. La stratégie locale peut nécessiter que la clé de signature de zone soit changée fréquemment, alors que la KSK peut avoir une période de validité plus longue pour fournir un point d'entrée sécurisé plus stable dans la zone. Désigner une clé d'authentification comme KSK est purement un problème opérationnel: La validation DNSSEC ne distingue pas les KSK et les autres clé d'authentification DNSSEC, et il est possible d'utiliser une seul clé pour signer les clé et signer la zone.
Non-Validation Security-Aware Stub Resolver Un résolveur sécurisé qui valide un ou plusieurs serveurs de noms récursifs sécurisés pour effectuer plus de tâches discutés dans ce document. En particulier, un tel résolveur est une entité qui envoie des requêtes DNS, reçois les réponses DNS, et est capable d'établir un canal sécurisé approprié vers un serveur récursif sécurisé qui fournir ces services à la demande.
Non-Validating Sub Resolver Un terme plus simple pour Non-Validation Security-Aware Stub Resolver
Security-Aware Name Server Une entité agissant dans le rôle d'un serveur de noms qui comprend les extensions de sécurité DNS définis dans ce document. En particulier, un serveur de nom sécurisé est une entité qui reçois des requêtes DNS, envoie des réponses DNS, supporte l'extension EDNS0 et le bit D0, et supporte les types RR et bits d'en-tête de messages définis dans ce document.
Security-Aware Recursive Name Server Une entité qui agit comme serveur de nom sécurisé et résolveur sécurisé.
Security-Aware Resolver Une entité agissant dans le rôle d'un résolveur qui comprend les extensions de sécurité DNS pour fournir des services additionnels. Ces résolveurs peuvent être soit validateurs soit non-validateurs, dépendant si le résolveur vérifie les signatures DNSSEC par lui-même ou fait confiance à un serveur de nom sécurisé pour le faire.
Security-Oblivious ‹anything} tout ce qui n'est pas sécurisé
Signed Zone Une zone dont les RRset sont signés et qui contiennent des enregistrements DNSKEY, RRSIG, NSEC et optionnellement DS
Trust Anchor Un RR DNSKEY configuré ou un hash RR DS d'un RR DNSKEY. Un résolveur sécurisé validant utilise cette clé publique ou le hash comme point de départ pour construire la chaîne d'authentification d'une réponse DNS. En général, un résolveur validateur obtient les valeurs initiales de ses ancres de confiance via un moyen sécurisé en dehors du protocole DNS. La présence d'une ancre de confiance implique également que le résolveur s'attende à ce que la zone vers laquelle l'ancre de confiance soit signée.
Unsigned Zone Une zone qui n'est pas signée
Validating Security-Aware Stub Resolver Un résolveur sécurisé qui envoie des requêtes en mode récursif mais qui valide la signature par lui-même au lieu de simplement faire confiance à un serveur de nom sécurisé.
Validating Stub Resolver Un terme plus simple pour Validating Security-Aware Stub Resolver
Zone Apex Terme utilisé pour décrire le nom d'une coupure de zone côté client
Zone Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une zone. Typiquement, une ZSK fait partie du même RRset DNSKEY que la KSK dont la clé privée correspondante signe ce RRset DNSKEY, mais la ZSK est utilisée dans un but différent et peut être différente de la KSK en autre, sur sa durée de vie.

Services fournis par la sécurité DNS

   Les extensions de sécurité DNS fournissent l'authentification de l'origine des données et l'intégrité des données, incluant les mécanismes pour authentifier le refus de l'existance de données DNS.

   Ces mécanismes nécessitent de changer le protocole DNS. DNSSEC ajoute 4 nouveaux types d'enregistement de ressource: Resource Record Signature (RRSIG), DNS Publik Key (DNSKEY), Delegation Signer (DS), et Next Secure (NSEC). Il ajoute également 2 nouveaux bits d'en-tête: Checking Disables (CD) et Authenticated Data (AD). Pour supporter des tailles de messages DNS plus grands, DNSSEC exige le support EDNS0. Finallement, DNSSEC nécessite le support pour le bit d'en-tête DNSSEC OK (DO) pour qu'un résolveur sécurisé puissent indiquer dans ses requêtes qu'il souhaite reçevoir les RR DNSSEC dans les réponses.

Authentification de l'origine des données et intégrité des données

   DNSSEC fournis l'authentification en associant des signature numérique générées cryptographiquement avec les RRset DNS. Ces signatures numérique sont stockées dans un nouvel enregistrement de ressource, l'enregistrement RRSIG. Généralement, il y a une seule clé privée qui signe les données d'une zone, mais plusieurs clés sont possibles. Par exemple, il peut y avoire des clés pour chaque algorithme de signature. Si un résolveur sécurisé apprend un clé publique de zone, il peut authentifier les données signées de cette zone. Un concept DNSSEC important est que la clé qui signe les données d'une zone est associée avec la zone elle-même et pas avec les serveurs de nom ayant autorité sur la zone. (Les clé publique pour les mécanismes d'authentification de transaction DNS peuvent également apparaître dans les zone, mais DNSSEC lui-même est concerné par la sécurité des données DNS, par la sécurité des canaux de transaction DNS. Les clés associées avec la sécurité des transaction peuvent être stockés dans des types RR différents)

   Un résolveur sécurisé peut apprendre une clé publique d'une zone soit en ayant une ancre de confiance configuré dans le résolveur ou par résolution normale DNS, auquel cas les clé publiques sont stockées dans un nouveau type d'enregistrement de ressource, le RR DNSKEY. Noter que les clés privées utilisée pour signer les donées de la zone doivent être conservé de manière sécurisés et devraient être stockés hors-line. Pour découvrir un clé publique de manière sûre via la résolution DNS, la clé cible elle-même doit être signée par une clé d'authentification configurée ou une autre clé qui a été authentifiée précédemment. Les résolveurs sécurisés authentifient les information de zone en formant une chaîne d'auhentification depuis une nouvelle clé publique apprise vers une clé publique authentifiée connue, qui en retour a été soit configurée dans le résolveur ou doit avoir été apprise et vérifiée précédemment. Donc, le résolveur doit être configuré avec au moins un trust anchor.

   Si l'ancre de confiance configurée est une clé de signature de zone, elle authentifie la zone associée; si la clé configurée est une clé de signature de clé, elle authentifie une clé de signature de zone. Si l'ancre de confiance configuré est le hash d'une clé au lieu de la clé elle-même, le résolveur peut obtenir la clé via une requête DNS. Pour aider les résoleurs à établir cette chaîne d'authentification, les serveurs de noms tentent d'envoyer les signatures nécessaire à authentifier les clé publique de la zone dans le message de réponse DNS avec la clé publique elle-même.

   Le type RR Delegation Signer (DS) simplifie certaines tâches administratives en signant les délégation entre les limites administratives. Le RRset DS réside au point de délégation dans une zone parent et indique les clé publique correspondante aux clé privées utilisée pour signer les RRset DNSKEY dans l'apex de zone enfant déléguée. L'administrateur de la zone enfant, en retour, utilise les clés privée correspondantes à une ou plusieurs des clé publique dans ce RRset DNSKEY pour signer les données de la zone enfant. La chaîne d'authentification est donc DNSKEY-›[DS›DNSKEY]*-›RRset, où '*' dénote 0 ou plusieurs sous-chaînes DS-›DNSKEY. DNSSEC permet des chaînes d'authentification plus complexes, tels que des couches additionnelles de RR DNSKEY signant d'autres RR DNSKEY dans une zone.

   Un résolveur sécurisé construit normalement cette chaîne d'authentification depuis la racine de la hiérarchie DNS jusqu'aux zones basés sur une connaissance configurée de la clé publique pour root. La stratégie locale, cependant, peut également permettre au résolveur d'utilisen une ou plusieurs clé publique configurées (ou hash de ces clé) autre que la clé publique root, peuvent ne pas fournir de connaissance configuré de la clé publique root, ou peuvent empêcher le résolveur d'utiliser des clé publique particulières pour des raisons arbitraires, même si ces clés publique sont signées correctement et vérifiables. DNSSEC fournis des mécanismes par lesquels un résolveur peut déterminer si la signature d'un RRset est valide. Dans l'analyse finale, cependant, authentifier les clé DNS et les donnée est sujet à la stratégie locale, qui peut étendre ou même remplacer les extensions de protocole définis dans ce document.

Authentifier les noms et la non-existence de type

   Le mécanisme de sécurisé décris ci-dessus ne fournis qu'une manière de signer des RRset exsistant dans une zone. Le problème des réponses négatives avec le même niveau d'intégrité et d'authentification exige l'utilisation d'un nouveau type d'enregistrement de ressource, NSEC. NSEC permet à un résolveur d'authentifier une réponse négative depuis soit le nom, ou la non-existance du type avec les même mécanisme utilisés pour authentifier les autres réponses DNS. L'utilisation des enregistrements NSEC nécessite une représentation canonique et d'ordre pour les noms de domaine dans les zones. Les chaînes d'enregistrement NSEC décrivent explicitement les gaps, ou espace vides, entre les noms de domaine dans une zone et la liste des types de RRset présent aux noms existant. Chaque enregistrement NSEC est signé et authentifié en utilisant les mécanismes décris plus haut.

Services non-fournis par la sécurité DNS

   DNS a été conçus à l'origine avec la supposition que DNS retourne la même réponse à une requête donnée sans regarder qui a émis la requête, et que toutes les données dans DNS est donc visible. DNSSEC n'est pas conçus pour fournir la confidentialité, les listes de contrôle d'accès, ou d'autres moyens de différencier les questionneurs.

   DNSSEC ne fournis pas de protection contre les attack DOS. Les résolveurs et les serveurs de nom sécurisé sont vulnérables à uen classe d'attaque DOS additionnel basé sur les opérations cryptographiques.

   Les extensions de sécurité DNS fournissent l'authentification de l'origine des données DNS. Les mécanismes définis plus haut ne sont pas conçus pour protéger es opérations telles que les transferts de zone et les mises à jours dynamiques. Les schéma d'authentification de message décris dans les rfc2845 et rfc3007 adressent les opérations de sécurité pour ces transactions.

Périmètre du document et problème Last Hop

   La spécification dans ce jeu de document définis le comportement pour les signataires de zone et les serveurs de nom sécurisés et les résolveurs qui valident les entités peuvent déterminer de manière non-ambigües l'état des données. Un résolveur validateur peut déterminer les 4 états suivants:

Secure Le résolveur validant a une ancre de confiance, a une chaîne de confiance, et est capable de vérifier toutes les signatures dans la réponse.
Insecure Le résolveur validant a une ancre de confiance, une chaîne de confiance, et, à certains points de délégation, la preuve signées de la non-existance d'un enregistrement DS. Celà indique que les branches sous-jacents dans l'arborescence sont probablement non-sécurisés. Un résolveur peut avoir une stratégie local pour marquer les parties de l'espace de domaine comme insécure.
Bogus Le résolveur validant a une ancre de confiance et une délégation sécurisée indique que les données subsidiaires sont signées, mais la réponse échoue la validation: signatures manquantes, signatures expirées, signatures avec des algorithmes non-supportés, données manquantes, etc.
Indeterminés Il n'y a pas d'ancre de confiance qui indique qu'une portion spécifique de l'arborescence est sécurisé. C'est le mode d'opération par défaut.

   Cette spécification définis seulement comment les serveurs de nom sécurisés peuvent signaler aux résolveurs non-validateurs que les données trouvés sont à l'état bogus (en utilisant RCODE=2 "Server Failure")

   Il y a un mécanisme pour les serveurs de nom sécurisés pour signaler aux résolveurs sécurisé que les données sont sécurisés (en utilisant le bit AD)

   Cette spécification ne définis pas de format pour communiquer la raison des réponses bogus ou insecure.

   Une méthode pour signaler les codes d'erreur avancés et les stratégies entre un résolveur sécurisé et les serveurs de noms récursifs est un sujet pour un travail future, tout comme l'interface entre un résolveur sécurisé et les applications qui l'utilisent. Noter, cependant, que le manque de spécification d'une telle communication n'empêche pas de déployer des zones signées ou le déploiement de serveurs de noms récursifs sécurisés qui empêchent la propagation de données bogus aux applications.

Considérations du résolveur

   Un résolveur sécurisé doit être capable d'effectuer des fonctions cryptographiques nécessaires à la vérification de signatures numérique en utilisant au moins les algorithmes obligatoire. Ces résolveurs doivent être capable de former une chaîne d'authentification depuis une nouvelle zone apprise vers une clé authentifiée, tel que décris plus haut. Ce processus peut nécessiter des requêtes additionnelles aux zones intermédiaires pour obtenir les enregistrements DNSKEY, DS, et RRSIG. Un résolveur devrait être configuré avec au moins une ancre de confiance comme point de départ depuis lequel il tente d'établir les chaînes d'authentification.

   Si un résolveur est séparé des serveurs de nom autoritatifs par un serveur de nom récursif ou par un périphérique intermédiaire qui agit comme proxy pour DNS, et si le serveur de nom récursif ou le périphérique intermédiaire n'est pas sécurisé, le résolveur n'est pas capable d'opérer dans un mode sécurisé. Par exemple, si les paquets d'un résolveur sont routés via un NAT qui inclus un proxy DNS qui n'est pas sécurisé, le résolveur peut avoir des difficultés ou l'impossibilité d'obtenir ou valider la données DNS signée.

   Si un résolveur sécurisé doit faire confiance à une zone non-signée ou un serveur de nom qui n'est pas sécurisé, le résolveur n'est pas capable de valider les réponses DNS et à besoin d'une stragégie locale pour accepter les réponses non-vérifiées

   Un résolveur sécurisé doit prendre en compte la période de validité en déterminant le TTL des données en cache, pour éviter que les données signées en cache soient au-delà de la période de validité de la signature. Cependant, il devrait être permis que l'horloge du résolveur soit fausse. Donc, un résolveur qui fait partie d'un serveur de nom récursif doit faire attention aux bit CD. Cela permet d'éviter le blocage des signatures valide via d'autres résolveurs qui sont clients de ce serveur de nom récursif.

Considérations du résolveur cache

   Bien que non strictement requis par le protocole, beaucoups de requêtes DNS ont pour origine les résolveurs cache. Ces résolveurs, par définition, sont des résolveurs minimals qui utilisent les requête récursives pour décharger le travaille de la résolution DNS à un serveur de nom récursif. L'architecture DNSSEC doit prendre en compte les résolveurs cache, mais les fonctionnalités de sécurité dans le résolveur cache diffèrent de ceux nécessaires dans un résolveur itératif sécuris.

   Même un résolveur cache non sécurisé peut bénéficier de DNSSEC si les serveurs de noms récursifs qu'il utilise sont sécurisés, mais pour que le résolveur cache puisse s'appuyer sur les services DNSSEC, le résolveur doit faire confiance à serveurs de nom récursifs en question et aux canaux de communication entre lui et ces serveurs de nom. Le premier de ces problème est un problème de stratégie locale: un résolveur non-sécurisé n'a pas le choix mais se place lui-même à la merci des serveurs de noms récursifs qu'il utilise, vu qu'il ne valide pas DNSSEC. Le second problème nécessite un mécanisme de canal sécurisé; l'utilisation des mécanismes d'authentification de transaction sécurisé comme SIG(0) ou TSIG est suffisant, et est approprié avec IPsec. Les implémentations peuvent avoir d'autres choix disponible, tels que des mécanisme de communication interprocess spécifiques à l'OS. La confidentialité n'est pas nécessaire pour ce canal, mais l'intégrité des données et l'authentification des messages le sont.

   Un résolveur sécurisé fait confiance aux serveurs de noms sécurisé et ses canaux de communication et peut choisir d'examiner le bit AD dans l'en-tête des messages qu'il reçoit. Le résolveur peut utiliser ce flag pour voir si le serveur de nom récursif est capable de valider les signatures pour toutes les données dans les sections d'autorité et de réponse

   Il y a une étape de plus qu'un résolveur sécurisé peut effectuer, s'il n'est pas capable d'établir une relation de confiance avec les serveurs de nom récursifs qu'il utilise: il peut effectuer sa propre validation de signature en définissant le bit CD dans ses requêtes. Un résolveur est capable de traiter les signatures DNSSEC comme relation de confiance entre les administrateurs de zone et le résolveur lui-même.

Considérations de zone

   Il y a de nombreuses différences entre des zones signées et non-signées. Une zone signée contient des enregistrements liées à la sécurité additionnels (RRSIG, DNSKEY, DS, et NSEC). Les enregistrements RRSIG et NSEC peuvent être générées par un procéssus de signature avec de servir la zone. Les enregistrements RRSIG qui accompagnent les données de zone ont une date de création et d'expiration définis qui établissent une période de validité pour les signatures et les données de zone que les signatures couvrent.

Valeurs TTL vs Période de validité RRSIG

   Il est important de noter la distinction entre la valeur TTL des RRset et la période de validité de signature spécifiée par le RR RRSIG couvrant ce RRset. DNSSEC ne change par la définition ou la fonction de la valeur TTL, qui est prévue pour maintenir la cohérence de la base dans les caches. Un résolveur cache purge les RRest de ses caches à la fin de la période spécifiée par les champs TTL et ces RRsets, sans regarder si le résolveur est sécurisé.

   Les champs de création et d'expiration dans le RR RRSIG, spécifient la période durant laquelle la signature peut être utilisée pour valider les RRset couvert. Les signatures associées avec les données de zone signées sont seulement valides pour la période de temps spécifiés par ces champs dans les RR RRSIG en question. Les valeurs TTL ne peuvent pas étendre la période de validit des RRset signés dans le cache du résolveur, mais le résolveur peut utiliser le temps restant avant l'expiration du la période de validité de la signature d'un RRset comme limite supérieur pour le TTL du RRset signé et ses RR RRSIG associés dans le cache.

Problème de dépendance temporelle pour les zones

   L'information dans une zone signée a une dépendance temporelle qui n'existe pas dans le protocole DNS original. Une zone signée nécessite une maintenance régulière pour s'assurer que chaque RRset dans la zone a un RR RRSIG valide. La période de validité de signature d'un RR RRSIG est un interval durant lequel la signature pour un RRset signé particulier peut être considéré comme valide, et les signatures des différents RRset dans une zone peuvent expirer à des moments différents. Resigner un ou plusieurs RRset dans une zone va changer un ou plusieurs RR RRSIG, qui en retour nécessite d'incrémenter le numéro de série SOA de la zone pour indiquer qu'une zone a changé et resigner le RRset SOA lui-même. Donc, resigner un RRset dans une zone peut également déclencher des messages DNS NOTIFY et des opération de transfert de zone.

Considérations de serveur de nom

   Un serveur de nom sécurisé devrait inclure les enregistrements DNSSEC appropriés (RRSIG, DNSKEY, DS, et NSEC) dans toutes les réponses aux requêtes des résolveurs qui ont signalé leur volonté de recevoir de tels enregistrement via l'utilisation du bit DO dans l'en-tête EDNS, sujet aux limitations de taille de message. À cause de l'ajout de ces RR DNSSEC pouvant facilement tronquer le message UDP et retourner en TCP, un serveur de nom sécurisé doit également supporter le mécanisme UPD "sender's UDP payload".

   Si possible, la partie privée de chaque paire de clé DNSSEC devrait être conservée hors-ligne, mais ce n'est pas possible pour une zone pour laquelle les mises à jours dynamiques sont permis. Dans le cas des mises à jours dynamiques, le serveur maître primaire pour la zone doit resigner la zone quand elle est mise à jours, dont la clé privée correspondant à la ZSK doit être online. C'est une exemple de situation dans laquelle la capacité de séparer le RRset DNSKEY de la zone en ZSK et KSK peut être utile, vu que la KSK peut rester offline et peut avoir une durée de vie plus longue que les ZSK.

   Par lui-même, DNSSEC n'est pas suffisant pour protéger l'intégrité d'une zone durant les opérations de transfert de zone, vu que même une zone signée contient des données non-signées, non-authoritatives si la zone a des enfants. Donc, les opérations de maintenance de zone nécessitent des mécanismes additionnels (tels que TSIG, SIG(0) ou IPsec)

Famille de document de sécurité DNS

   Le jeu de document DNSSEC peut être partitionné en plusieurs groupes sous les documents du protocole DNS de base. Les jeu de document de protocole DNSSEC réfère à 3 documents qui forment le cœur des extensions de sécurité DNS:

1. Introduction et exigents pour la sécurité DNS (ce document)
2. Enregistrements de ressource pour les extensions de sécurité DNS (rfc4034)
3. Modification de protocole pour les extensions de sécurité DNS (rfc4035)

   Le jeu de document de spécification d'algorithme de signature numérique réfère au groupe de documents qui décrivent comme les algorithmes de signature numérique devraient être implémentés dans DNSSEC. Voir la rfc4034 pour la liste des algorithmes définis.

   Le jeu de documents de protocole d'authentification de transaction réfère au groupe de documents qui gérènt l'authentification des messages DNS, incluant l'établissement et la vérification des clé secrètes.

   Je jeu de document d'utilisation des nouvelles sécurités réfère aux documents qui visent à utiliser les extensions de sécurité DNS proposés pour d'autres but de sécurité. DNSSEC ne fournis pas de sécurité directe pour ces nouvelles utilisations mais peuvent être utilisé pour les supporter. Les documents qui rentre dans cette catégorie incluent l'utilisation de DNS dans le stockage et la distribution de certificats
^
27 juin 2016

htmlpdflatexmanmd




rfc4034

rfc4034

Enregistrements de ressource pour les extensions de sécurité DNS

   Les extensions de sécurité DNS introduisent 4 nouveaux type d'enregistrement de ressource DNS: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), et Delegation Signer (DS). Ce document définis le but de chacun de ces RR, le format RDATA de ces RR, et leur format de présentation (ASCII).

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les jeus d'enregistrement de ressources (RRsets). Les clé publiques sont stockées dans les RR DNSKEY et sont utilisé dans le processus d'authentification DNSSEC.: Une zone signe son RRset authoritatif en utilisant une clé privée et stocke la clé publique correspondante dans un RR DNSKEY. Un résolveur peut ainsi utiliser la clé publique pour valider les signature couvrant les RRset dans la zone, et donc les authentifier.

   Le RR DNSKEY n'est pas prévu comme un enregistrement pour stocker des clé publiques arbitraires et ne doit pas être utilisé pour stocker des certificats ou des clé publiques non liées à l'infrastructure DNS.

   La valeur Type pour le RR DNSKEY est 48, le RR DNSKEY est indépendant de la class et n'a pas de requis de TTL spécial.

Format DNSKEY RDATA

Le RDATA pour un RR DNSKEY consiste d'un champ de Flags à 2 octets, un champ Protocole 1 octet, en champ Algorithme 1 octet, et le champ de clé publique:
_____________________1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3____
____0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___|______________Flags____________|____Protocol___|___Algorithm___|
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___/_______________________________________________________________/
___/____________________________Public_Key_________________________/
___/_______________________________________________________________/
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Flags

   Le bit 8 est le flag de clé de zone. Si le bit 7 est mis, l'enregistrement DNSKEY maintient une clé de zone DNS, et le nom propriétaire du RR DNSKEY doit être le nom d'une zone. S'il est non-mis, l'enregistrement DNSKEY maintien un autre type de clé publique DNS et ne doit pas être utilisé pour vérifier les RRSIG qui couvrent les RRsets.

   Le bit 15 est le flag de point d'entrée sécurisé, décris dans la rfc3757. Mis, l'enregistrement DNSKEY maintient une clé utilisée comme point d'entrée. Ce flag est seulement prévu pour être un départ de signature de zone, ou pour débugger les logiciel; les validateurs ne doivent pas altérer leur comportement durant le processus de validation de signature en se basant sur ce bit. Il signifie également qu'un RR DNSKEY avec le bit SEP mis à également besoin du flag Zone Key mis pour être capablede générer des signature légalement. Un RR DNSKEY avec SEP mis et le bit 7 non mis ne doivent pas être utilisés pour vérifier les RRSIG qui couvrent les RRsets.

Champ Protocol

   Le champ Protocol doit avoir la valeur 3, et le RR DNSKEY doit être traité comme invalide durant la vérification de la signature si une autre valeur est trouvée.

Champ Algorithm

   Identifie l'algorithme cryptographique à clé publique et détermine le format du champ de clé publique.

Champ Public Key

   Maintien la clé publique. Le format dépend de l'algorithme de la clé stockée et est décrit dans un document séparé.

Notes sur le design de DNSKEY RDATA

   Bient que le chaps Protocol a toujours la valeur 3, il est retenu pour compatibilité avec les premières versions de l'enregistrement KEY

Format de présentation des RR DNSKEY

   Le format de présentatin de la portion RDATA est comme suit:

- Le champ Flag doit être représenté comme entier décimal non-signé. Avec les flags actuellement définis, les valeurs possibles sont: 0, 256 et 257.
- Le champ protocol doit être représenté comme entier décimal non-signé avec une valeur de 3
- Le champ algorithm doit être resprésenté comme entier décimal non-signé, ou comme mnémonique d'algortihme.
- La clé publique doit être représentée en base64.

Exemple de RR DNSKEY

Le RR DNSKEY suivant stocke un clé de zone DNS pour example.com.
example.com. 86400 IN DNSKEY 256 3 5 (_AQPSKmynfzW4kyBv015MUG2DeIQ3
_______________________________________Cbl+BBZH4b/0PY1kxkmvHjcZc8no
_______________________________________kfzj31GajIQKY+5CptLr3buXA10h
_______________________________________WqTkF7H6RfoRqXQeogmMHfpftf6z
_______________________________________Mv1LyBUgia7za6ZEzOJBOztyvhjL
_______________________________________742iU/TpPSEDhm2SNKLijfUppn1U
_______________________________________aNvv4w==__)

   Les 4 premiers champs spécifient le nom propriétaire, le TTL, la Classe , et le type de RR (DNSKEY). Une valeur 256 indique que le bit de clé de zone est mis. La valeur 3 est la valeur de protocole. La valeur 5 indique l'algorithme à clé publique (RSA/SHA1). Le reste est la clé publique encodé en base64

L'enregistrement de ressource RRSIG

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les RRset. Les signatures numériques sont stockées dans les RRSIG et sont utilisé dans le processus d'authentification DNSSEC décris dans la rfc4035. Un validateur peut utiliser ces RRSIG pour authentifier les RRest de la zone. Le RR RRSIG doit seulement être utilisé pour valider les signatures numérique utilisés pour sécuriser les opérations DNS.

   Un enregistrement RRSIG contient la signature pour un RRset avec un nom, classe et type. Le RR RRSIG spécifie un interval de validité pour la signature et utilise Algorithm, nom du signataire, et le Key Tag pour identifier le RR DNSKEY contenant la clé publique qu'un validateur peut utiliser pour vérifier la signature.

   Parce que tout RRset authoritatif dans une zone doit être protégé par une signature numérique, les RR RRSIG doivent être présents pour les noms contenant un RR CNAME. C'est un changement de la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom qu'un enregistrement de ressource CNAME dans une zone signée.

   La valeur de Type pour le RR RRSIG est 46. Le RR RRSIG est indépendant de la classe. Un RR RRSIG doit avoir la même classe que le RRset qu'il couvre. La valeur TTL d'un RRSIG doit correspondre au TTL du RRset qu'il couvre. C'est une exception des règles de la rfc2181 pour les valeurs TTL des RR individuels dans un RRset: les RR RRSIG individuels avec le même nom propriétaire ont différentes valeur TTL si le RRset qu'ils couvrent ont différentes valeurs TTL.

Format RRSIG RDATA

Le RDATA pour un RR RRSIG consiste d'un champ Type à 2 octets, un champ Algorithm à 1 octet, un champ Labels 1 octet, un champ TTL 4 octets, un champ Signature Expiration 4 octets, un champ Signature Inception 4 octets, en tag Key 2 octets, le champ du nom du signataire et le champ Signature.
_-_-_-_-_-_-_-_-_-_-_1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3_
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|________Type_Covered___________|__Algorithm____|_____Labels____|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Original_TTL__________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Expiration_____________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Inception______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________Key_Tag____________|_______________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_________Signer's_Name_________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Signature__________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Type Covered

   Ce champ identifie le type du RRset couvert pas cet enregistrement RRSIG

Champ Algorithm Number

   Ce champ identifie l'algorithme cryptographique utilisé pour créer la signature.

Champ Labels

   Spécifie le nombre de labels dans le nom propriétaire du RR RRSIG. La signification de ce champs est qu'un validateur l'utilise pour déterminer si la réponse a été synthétisée depuis un wildcard. Si c'est le cas, il peut être utilisé pour déterminer quel nom propriétaire a été utilisé pour générer la signature.

   Pour valider une signature, le validateur a besoin du nom propriétaire original qui a été utilisé pour créer la signature. Si ce nom contient un label wildcard, le nom propriétaire peut avoir été étendu par le serveur durant le processus de réponse, auquel cas le validateur doit reconstruire le nom original pour pouvoir valider la signature. La rfc4035 décris comment utiliser le champ Labels pour reconstruire le nom propriétaire original.

   La valeur du champ Label ne doit pas compter le label null (root) qui termine le nom propriétaire ni le label wildcard. La valeur du champ Labels doit être inférieur ou égal au nombre de labels dans le nom propriétaire RRSIG. Par exemple, "www.example.com." a une valeur de champ Labels de 3, et "*.example.com." a une valeur de 2. Root ('.') a une valeur de 0.

   Bien que le label wildcard n'est pas inclus dans le compteur stocké dans le champ Labels du RR RRSIG, le label wildcard fait partie du nom propriétaire du RRset quant la signature est générée ou vérifiée.

Champ TTL Original

   Spécifie le TTL du RRset couvert tel qu'il apparaît dans le zone authoritative.

   Ce champ est nécessaire parce que le cache du résolveur décrémente la valeur TTL d'un RRset en cache. Pour valider une signature, un validateur nécessite le TTL original. la rfc4035 décris comment utiliser ce champ pour reconstruire le TTL original.

Champs Signature Expiration et Inception

   Ces champ spécifie la période de validité pour la signature. L'enregistrement RRSIG ne doit pas être utilisé pour authentifier avant la date de début, et ne doit pas être utilisée pour l'authentification après la date d'expiration.

   Ce champsspécifie une date et heure sous la forme d'un nombre non-signé 32bits en secondes depuis le 1 Janvier 1970 00:00:00 UTC. L'interval le plus long qui peut être exprimé par ce format est approximativement de 136ans. Un RR RRSIG peut avoir un champ Expiration qui est numérique plus petit que le champ Inception si la valeur du champ du champ d'expiration est proche du maximum 32bits ou si la signature a une durée de vie longue.

Champ Key Tag

   Contient la valeur de tag de clé du RR DNSKEY qui valide cette signature.

Champs Signer's Name

   Ce champ identifie le nom propriétaire du RR DNSKEY qu'un validateur est supposé utiliser pour valider cette signature. Ce champ doit contenir le nom de la zone du RRset couvert. Un émetteur ne doit pas utiliser la compression de nom DNS dans ce champ en transmettant un RR RRSIG

Champ Signature

   Le champ signature contient la signature cryptographique qui couvre le RDATA RRSIG (excluant le champ signature) et le RRset spécifié par le nom du RRSIG, la classe RRSIG, et le type RRSIG. Le format de ce champ dépend de l'algorithme utilisé.

Calcul de Signature

Une signature couvre le RDATA RRSIG et couvre les données RRset spécifiées par le nom propriétaire RRSIG, la classe et le type couvert RRSIG. Le RRset est sous la forme canonique et est signé comme suit:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

ou '|' dénote une concaténation. RRSIG_RDATA est le format des champs RDATA RRSIG avec le champ Signer's Name sous forme canonique et le champ Signature est exclus.
RR(i) = owner | type | class | TTL | RDATA length | RDATA

   owner est le nom propriétaire pleinement qualifié du RRset sous la forme canonique. Chaque RR doit avoir le même nom propriétaire et la même classe que le RR RRSIG. Chaque RR dans le Rset doit avoir le type RR listé dans le champ Type Covered du RR RRSIG. Tous nom DNS dans le champ RDATA de chaque RR doit être sous la forme canonique, et le RRset doit être trié dans l'ordre canonique.

Format de présentation RR RRSIG

   Le format de présentation de la portion RDATA est comme suit:

- Le champ Type Covered est représenté comme un mnémonique du type RR. Quand le mnémonique n'est pas connus, la représentation du TYPE rfc3597 doit être utilisé.
- Le champ Algorithm doit être représenté soit comme entier décimal non-signé ou comme mnémonique.
- Le champ Labels doit être représenté comme entier décimal non-signé
- Le champ Original TTL doit être représenté comme entier décimal non-signé
- Les champs Signature Expiration Time et Inception Time doivent être représenté soit comme entier décimal non-signé indiquant les secondes depuis le 1 Janvier 1970 00:00:00 UTC, ou sous la forme YYYMMDDHHmmSS en UTC.

           Noter qu'il est toujours possible de faire la distinction entre les 2 format parce que le format YYYYMMDDHHmmSS fait toujours exactement 14 chiffres, alors que la représentation décimale 32bits ne peut jamais dépasser 10 chiffres.

- Le champ Key Tag doit être représenté comme entier décimal non-signé
- Le champ Signer's Name doit être représenté en nom de domaine
- Le champ Signature est représenté en Base64.

Exemple de RR RRSIG

Le RR RRSIG suivant stocke la signature pour un RRset A de host.example.com:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
_______________________________20030220173103 2642 example.com.
_______________________________oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
_______________________________PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
_______________________________B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
_______________________________GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
_______________________________J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

   Les 4 premiers champs spécifient le nom propriétaire, le TTL, la classe, et le type RR (RRSIG). Le A represente le type couvert. La valeur 5 identifie l'algorithme (RSA/SHA1), la valeur 3 est le nombre de labels dans le nom propriétaire original. 86400 est le TTL d'origine pour le RRset A couvert. 20030322173103 et 20030220173103 sont les date de début et de fin de validité de la signature. 2642 est le Key Tag, et example.com. est le nom du signataire.

   Noter la combinaison du nom, classe et type couvert du RR indiquent que ce RRSIG couvret le RRset A host.example.com. La valeur Labels indique qu'il n'y a pas d'expansion wildcard. Algorithm, Signer's Name et Key Tag indiquent que cette signature peut être authentifiée en utilisant un RR DNSKEY dans la zone example.com dont l'algorithme est 4 et dont le tag de clé est 2642

Enregistrement de ressource NSEC

   Le RR NSEC liste 2 choses séparée: le prochain nom propriétaire qui contient les données autoritatives ou un point de délégation RRset NS, et le jeu de type RR présents au nom propriétaire du RR NSEC (rfc3845). Le jeu complet de RR NSEC dans une zone indique quels RRset autoritatif existe dans une zone et forme également une chaîne de noms propriétaires authoritatifs dans la zone. Cette information est utilisée pour fournir un déni d'existance authentifié pour les données DNS, comme décris dans la rfc4035.

   Parce que tout nom autoritatif dans une zone doit faire partie d'une chaîne NSEC, les RR NSEC doivent être présents pour les noms contenant un RR CNAME. C'est un changement par rapport à la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom comme le fait un RR CNAME dans une zone non-signée.

   La valeur du type pour un RR NSEC est 47. Le RR NSEC est indépendant de la classe et devrait avoir le même TTL que le champ SOA minimum TTL.

Format NSEC RDATA

Le RDATA d'un RR NSEC est comme suit:
_-_-_-_-_-_-_-_-_-_-_1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/______________________Next_Domain_Name_________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________Type_Bit_Maps___________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Next Domain Name

   Ce champ contient le nom propriétaire qui a les données autoritatives ou contient un RRset NS de point de délégation. La valeur de ce champ dans le dernier enregistrement NSEC dans la zone est le nom de l'apex de zone (le nom propriétaire du RR SOA de la zone). Cela indique que le nom propriétaire du RR NSEC est le dernier nom dans l'ordre canonique de la zone.

   Un émetteur ne doit pas utiliser la compression de noms DNS dans ce champ en le transettant. Les noms propriétaires des RRset pour lesquel la zone donnée n'est pas autoritative (comme les enregistrements glue) ne doivent pas être listés dans ce champ sauf si au moins un RRset autoritatif existe avec le même nom propriétaire.

Champ Type Bit Maps

Identifie les types du RRset qui existe au niveau du nom propriétaire du RR NSEC. L'espace du type RR est splitté en 256 blocks, chacun représentant les 8bits LSB de l'espace du type RR 16-bits. Chaque block qui a au moins un type RR actif est encodé en utilisant un simple octet de numéro de fenêtre ( de 0 à 255), un simple octet de longueur (de 1 à 32) indiquant le nombre d'octets utilisés pour le bitmap de block, et jusqu'à 32 octets (256bits) de bitmaps. Les blocks sont présent dans le RDATA du RR NSEC en augmentant l'ordre numérique:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

   où "|" dénote la concaténation

   Chaque bitmap encode les 8bits LSB des types RR dans le block, dans l'ordre de bit réseau. Le premier bit est le bit 0. Pour le block de fenêtre 0, le bit 1 correspond au type RR 1 (A), le bit 2 correspond au RR type 2 (NS), etc. pour le block de fenêtre 1, le bit 1 correspond au RR type 257, et le bit 2 correspond au RR type 258. Si un bit est mis, il indique qu'un RRset de ce type est présent pour le nom propriétaire NSEC.

   Les bits représentant les pseudo-type doivent être effacés, vu qu'ils n'apparaîssent pas dans la zone de données. Si rencontré, ils doivent être ignorés

   Les blocks sans type ne doivent pas être inclus. Les 0 restant dans le bitmap doivent être omis. La longueur de chaque bitmap de block est déterminé par le code de type avec la valeur numérirque la plus grande.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attension spéciale. Les bits correspondant au RRset NS de délégation et les type RR pour lequels la zone parent a une donnée autoritative doivent être mis; les bits correspondants à tout RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

   Une zone ne doit pas inclure le RR NSEC pour un domaine qui ne maintient que des enregistrements glue.

Ajout des noms wildcard dans RDATA NSEC

   Il un nom wildcard apparaît dans une zone, le label wildcard est traité comme symbole littéral et est traité de la même manière que pour tout nom propriétaire.

Format de présentation RR NSEC

   Le format de présentation de la portion RDATA est comme suit:

- Le champ Next Domain Name est représenté comme un nom de domaine
- Le champs Type Bit Map est resprésenté comme une séquence de mnémoniques de type RR.

Exemple de RR NSEC

L'exemple suivant identifie les RRset associés avec alfa.example.com. et identifie le nom autoritatif suivant après alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )

   Les 4 premiers champs identifient le nom, TTL, class et type RR (NSEC). host.example.com. est le nom autoritatif suivant après alfa.example.com dans l'ordre canonique. Les mnémoniques A, MX, RRSIG, NSEC et TYPE1234 indiquent qu'il y a des RRsets correspondants associés avec le nom alfa.example.com.

  La section RDATA du RR NSEC serait encodé:


0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20

   Assumant que le validateur peut authentifier cet enregistrement NSEC, il peut être utilisé pour prouver que beta.example.com n'existe pas, ou pour prouver qu'il n'y a pas d'enregistrement AAAA associé avec alfa.example.com.

Enregistrement de ressource DS

   Le RR DS réfère à un RR DNSKEY et est utilisé dans le processus d'authentification DNSKEY. Un RR DS réfèrre à un RR DNSKEY en stockant le tag de clé, le numéro d'algorithme, et un hash du RR DNSKEY. Noter que bien que le hash soit suffisant pour identifier le clé publique, stocker le tag de clé et l'algorithme aide à le processus d'identification plus efficacement. En authentifiant l'enregistrement DS, un résolveur peut authentifier le RR DNSKEY pour lequel le RR DS pointe.

   Le RR DS et son RR DNSKEY correspondant ont le même nom propriétaire, mais ils sont stockés à différents emplacements. Le RR DS apparaît seulement côté parental d'une délégation, et est autoritatif dans la zone parent. Par exemple, le DS RR pour example.com est stocké dans la zone com. Le RR DNSKEY est stocké dans la zone example.com. Cela simplifie la gestion de zone DNS et la signature de zone en introduisant une traitement de réponse spécial pour le RR DS.

   Le type pour le RR DS est 43, et est indépendant de la classe. Le RR DS n'a pas de prérequis de TTL spécial.

Format DS RDATA

Le RDATA pour un RR DS consiste d'un champ 2 octets Key Tag, un champ algorithme 1 octet Algorithm un champ 1 octet Digest Type, et un champ Digest
_____________________1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________Key_Tag_____________|__Algorithm____|__Digest_Type__|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Digest_____________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Key Tag

   Le champ Key Tag liste le tag de clé du RR DNSKEY réferré par l'enregistrement DS. Le Key Tag utilisé par le RR DS est identique au Key Tag utilisé pas les RR RRSIG.

Champ Algorithm

   Le champ algorithme liste le numéro d'algorithme du RR DNSKEY correspondant à cet enregistrement DS.

Champ Digest Type

   Le RR DS réfèrre à un RR DNSKEY en inclant un hash de ce RR DNSKEY. Ce champ identifie l'algorithme utilisé pour construire le hash.

Champ Digest

Contient le hash du RR DNSKEY. Le hash est calculé en concaténant la forme canonique du nom propriétaire pleinement qualifié du RR DNSKEY uavec le RDATA DNSKEY et applique ainsi l'algorithme de hashage:
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

"|" dénote la concaténation.
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

   La taille du hash peut varier en fonction de l'algorithme et de la taille du RR DNSKEY.

Traitement des RR DS en validant les réponses

   Les RR DS lient la chaîne d'authentification entre les zones, donc le RR DS nécessite une attention particulière dans le traitement. Le RR DNSKEY réferré dans le RR DS doit être une clé de zone DNSSEC. Les flags du RR DNSKEY doivent avoir le bit 7 mis. Si les flags DNSKEY n'indiquent pas une clé de zone DNSSEC, le RR DS (et le RR DNSKEY correspondant) ne doivent pas être utilisés pour le processus de validation.

Format de présentation du RR DS

   Le champ key tag doit être représenté comme entier décimal non-signé. Le champ algorithm doit être réprésenté comme entier décimal non-signé ou mnémonique d'algorithme. Le champ Digest Type doit être réprésenté comme entier décimal non-signé. Le champ Digest doit être reprsenté comme une séquence de chiffres hexadécimaux sensible à la casse.

Exemple de RR DS

L'exemple suivant montre un RR DNSKEY et son RR DS correspondant:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshW
__________________________________________fwJr1AYtsmx3TGkJaNXV
__________________________________________2pHm822aJ5iI9BMzNXxe
__________________________________________DRD99WYwYqUSdjMmmAph
__________________________________________egXd/M5+X7OrzKBaMbCV
__________________________________________Uh6DhweJBjEVv5f2wwjM
__________________________________________nOf+EPbtG9DMBmADjFDc
__________________________________________ljwvFw==
__________________________________________) ; key id = 60485
    
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A
___________________________________________98631FAD1A292118 )

   Le 4 premiers champs spécifient le nom, TTL, classe et type RR (DS). La valeur 60485 est le tag de clé pour dskey.example.com. Les RR DNSKEY, et la valeur 5 dénotent l'algorithme utilisé par ce RR DNSKEY. La valeur 1 est l'algorithme utilisé pour construire le hash, et le reste est le hash.

Forme canonique et ordre d'enregistrement de ressource

   Cette section définis une forme canonique pour les enregistrements de ressource, un ordre canonique des noms DNS, et un ordre canonique d'enrgistrements de ressource dans un RRset. Un ordre de nom canonique est requis pour construire la chaîne de nom NSEC. Une forme RR canonique est l'ordre dans un RRset sont requis pour construire et vérifier les RR RRSIG.

Ordre de noms DNS canonique

   Pour la sécurité DNS, les noms propriétaires sont ordonnés en traitant les labels individuels comme chaînes d'octets non-signés justifiés à gauche. L'absence d'un trie d'octet avant un octet zéro, et les lettre US-ASCII majuscule sont traités comme s'ils étaient en minuscule.

   Pour calculer l'ordre canonique d'un jeu de noms DNS, on commence par trier les noms en accord avec leur labels les plus signifiant. Pour les noms dans lequel le label le plus signifiant est identique, on continue à trier en accord avec le label suivant, et ainsi de suite.

Par exemple, les noms suivants sont triés par ordre de nom DNS canoniques. Le lable le plus signifiant est "example". À ce niveau, "example" est en premier, suivis par les noms se terminant dans "a.example", puis par les noms se terminant par "z.example". Les noms dans chaque niveau sont traités de la même manière:
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example

Forme RR canonique

   Pour la sécurité DNS, la forme canonique d'un RR est le format des RR où:

1. Tout nom de domaine dans le RR est étendu et pleinement qualifié)
2. Toute lettre US-ASCII majuscule dans le nom propriétaire du RR sont remplacés par les lettres minuscules.
3. Si le type du RR est NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, ou NSEC, toutes les lettres US-ASCII majuscule dans les noms DNS contenur dans le RDATA sont remplacés par des minuscules.
4. Si le nom propriétaire du RR est un nom wildard, le nom propriétaire est dans sa forme non-étendue originale, inclunat le label '*'
5. Le TTL du RR est mis à sa valeur d'origine telle qu'elle apparaît dans la zone autoritative d'origine ou le champ Original TTL du RR RRSIG.

Ordre RR canonique dans un RRset

   Pour la sécurité DNS, les RR avec le même nom propriétaire, class et type sont triés en traitant la portion RDATA de la forme canonique de chaque RR comme séquence d'octet non-signé justifié à gauche dans laquelle l'absence d'un octet trie avant un octet zéro.

   La rfc2181 spécifie qu'un RRset n'est pas autorisé à contenir des enregistrements dupliqués (plusieurs RR avec le même nom propriétaire, class, type, et RDATA). Cependant, si une implémentation détecte des RR dupliqués en plaçant le RRset dans une forme canonique, il doit traite comme une erreur de protocole. Si l'implémentation choisis de gérer cette erreur de protocole dans l'esprit du principe de robustesse, il doit supprimer les RR dupliqués pour calculer la forme canonique du RRset.

Considérations de sécurité

   L'enregistrement DS pointe vers un RR DNSKEY en utilisant un hash cryptographique, le type d'algorithme de clé, et un tag de clé. L'enregistrement DS est prévu pour identifier un RR DNSKEY existant, mais il est théoriquement possible pour un attaquant de générer un DNSKEY qui corresponde à ces champs. La probabilité de construire un DNSKEY qui correspond dépend de l'algorithme de hasha utilisé. Actuellement, seul SHA-1 est définis.

   Le tag de clé est utilisé pour sélectionner le RR DNSKEY efficacement, mais il n'identifie pas de manière unique un simple RR DNSKEY. Il est possible que 2 RR DNSKEY distincts aient le même nom propriétaire, le même type d'algorithme, et le même tag de clé. Une implémentation qui utiliser seulement le tag de clé pour sélectionner un RR DNSKEY peut sélectionner la mauvaise clé dans certaines circonstances.

Algorithme et types de hashage

Les extensions de sécurité DNS sont conçus pour être indépendants des algorithmes cryptographique. Les enregistrements de ressource DNSKEY, RRSIG, et DS utilisent tous un numéro d'algorithme DNSSEC pour identifier l'algorithme utilisé par le RR. le RR DS spécifie également un numéro d'algorithme de hashage.
Value_Algorithm_[Mnemonic]__Signing__References___Status
__-----_--------------------_---------_----------__---------
____0___reserved
____1___RSA/MD5_[RSAMD5]_________n______[RFC2537]__NOT_RECOMMENDED
____2___Diffie-Hellman_[DH]______n______[RFC2539]___-
____3___DSA/SHA-1_[DSA]__________y______[RFC2536]__OPTIONAL
____4___Elliptic_Curve_[ECC]______________TBA_______-
____5___RSA/SHA-1_[RSASHA1]______y______[RFC3110]__MANDATORY
__252___Indirect_[INDIRECT]______n__________________-
__253___Private_[PRIVATEDNS]_____y______see_below__OPTIONAL
__254___Private_[PRIVATEOID]_____y______see_below__OPTIONAL
__255___reserved

   Le numéro d'algorithme 253 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commence avec un nom de domaine encodé, qui ne doit pas être compressé. Le nom de domaine indique l'algorithme utilisé, et le reste de la zone de clé publique est déterminé par cet algorithme.

   L'algorithme 254 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commencent avec un octet de longueur non-signé suivi par un OID encodé BER du cette longueur. L'OID indique l'algorithme de clé privée utilisé.

Types de hash DNSSEC

Un champ Digest Type dans un RR DS identifie l'algorithme de hasha utilisé par le RR. La table suivante liste les types actuellement définis:
0 Réservé
1 SHA-1
2-255 non-assigné

Calcule du tag de clé

   Le champ key tag dans les RR RRSIG et DS fournissent un mécanisme pour sélectionner une clé publique efficacement. Dans la plupars des cas, une combinaison de nom propriétaire, algorithme, et tag de clé peut efficacement identifier un enregistrement DNSKEY. Il est essentiel de noter que le Key Tag n'est pas unique.

   Le tag de clé est le même pour tous les types d'algorithmes DNSKEY excpté l'algorithme 1. L'algorithme de tag de clé est la somme du format du RDATA DNSKEY séparé en 2 groupes d'octets. D'abord, le RDATA est traité comme séries de groupes de 2 octets. Ces groupes sont ainsi ajoutés ensemble, en ignorant les bits de retenu.

L'implémentation de référence ANSI C suivante calcule la valeur d'un Key Tag. Cette implémentation de référence s'applique à tous les algorithmes excepté l'algorithme 1. Le code est écrit pour la clarté, non l'efficacité:
/*
    On assure que l'entier fait au moins 16 bits
    Le premier octet du tag de clé sont les 8 bits MSB de la valeur retournée
    Le second octet du tag de clé sont les 8 bits LSB de la valeur retournée
*/
unsigned int
keytag (
    unsigned char key[], /*the RDATA part of the DNSKEY RR*/
    unsigned int keysize /*the RDLENGTH*/
)
{
    unsigned long ac; /*assumed to be 32 bits or larger*/
    int i; /*loop index*/
    
    for ( ac = 0, i = 0; i ‹ keysize; ++i )
        ac += (i & 1) ? key[i] : key[i] ‹‹ 8;
    ac += (ac ›› 16) & 0xFFFF;
    return ac & 0xFFFF;
}

Algorithme 1 pour le tag de clé

   Le type de clé pour l'algorithme 1 (RSA/MD5) est définis différemment du tag de clé pour tous les autres algorithmes, pour des raisons historiques. Pour un RR DNSKEY avec l'algorithme 1, le tag de clé est les 16bits les plus signifiant des 24bits les moins signifiants dans le modulo de la clé publique. Noter que l'algorithme 1 n'est pas recommandé.
^
11 juillet 2016

htmlpdflatexmanmd




rfc4035

rfc4035

Modifications de protocole pour les extensions de sécurité DNS

   Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS. Ce document définis les modifications du protocole DNSSEC.

Signature de zone

   DNSSEC introdui le concept de zones signées. Une zone signée inclus une clé publique DNS (DNSKEY), un enregistrement de ressource de signature (RRSIG), Next Secure (NSEC), et optionnellement une délégation de signataire (DS). Une zone qui n'inclue pas ces enregistrements n'est pas une zone signée.

   DNSSEC nécessite un changement dans la définition de l'enrgistrement de ressource CNAME, pour permettre aux RR RRSIG et NSEC d'apparaître avec le même nom propriétaire que le fait un RR CNAME.

   DNSSEC spécifie le placement de 2 nouveaux type RR, RSEC et DS, qui peuvent être placés au niveau du parent (au point de délégation). C'est une exception à l'interdiction générale de placer des données dans la zone parent.

Inclure les RR DNSKEY dans une zone

   Pour signer une zone, l'administrateur de zone génère une ou plusieurs paires de clés publique/privée et les utilise pour signer les RRset authoritatif dans la zone. Pour chaque clé privée utilisée pour créer les RR RRSIG dans une zone, la zone doit inclure un RR DNSKEY de zone contenant la clé publique correspondante. Une clé de zone RR DNSKEY doit avoir le bit de clé de zone du champ de flags RDATA mis. Les clés publiques associées avec d'autres opérations DNS peuvent être stockées dans des RR DNSKEY et ne sont pas marquées comme clé de zone et ne doivent pas être utilisées pour vérifier les RRSIG.

   Si l'administrateur de zone prévois une zone signé pour être utilisable pour autre chose de la sécurité, l'apex de zone doit contenir au moins un RR DNSKEY pour agir comme point d'entrée sécurisé dans la zone. Ce point d'entrée sécurisé peut ainsi être utilisé comme cible d'une délégation sécurisé via un RR DS correspondant dans la zone parent.

Inclure les RR RRSIG dans une zone

   Pour chaque RRset autoritatif dans une zone signée, il doit y avoir au moins un enregistrement RRSIG qui rencontre les exigences suivantes:

        - Le nom propriétaire RRSIG est égal au nom propriétaire du RRset
        - La classe RRSIG est la même que la classe du RRset
        - Le champ Type Covered du RRSIG est égal au type du RRset
        - Le champ Original TTL du RRSIG est égal au TTL du RRset
        - Le champ Labels du RRSIG est égal au nombre de labels dans le nom propriétaire du RRset, sant compter le label root et le label le plus à gauche si c'est un wildcard
        - Le champ Signer's Name du RRSIG est égale au nom de la zone contenant le RRset
        - Les champs Algorithm, Signer's Name, et Key Tag identifient une clé de zone DNSKEY dans l'apex de la zone.

   Le processus pour construire le RR RRSIG pour un RRset donné est décris dans la rfc4034. Un RRset peut avoir plusieurs RR RRSIG associé avec lui. Un RR RRSIG lui-même ne doit pas être signé, vu que signer un RR RRSIG n'ajoute pas de valeur et créé une boucle infinie dans le processus de signature.

   Le RRset NS qui apparaît dans l'apex de la zone doit être signé, mais les RRset NS qui apparaîssent aux points de délégation ne doivent pas être signés. Les RRset Glue associés avec les délégation ne doivent pas être signés.

   Il doit y avoir un RRSIG pour chaque RRset utilisant au moins une DNSKEY de chaque algorithm dans le RRset DNSKEY de l'apex de la zone. Le RRset DNSKEY apex lui-même doit être signé par chaque algorithme apparaissant dans le RRset DS localisé dans le parent déléguant.

Inclure les RR NSEC dans une zone

   Chaque nom propriétaire dans la zone qui a une donnée autoritative ou un RRset NS point de délégation doit avoir un RR NSEC. Le format des RR NSEC et le processus pour le construire et donnée dans la rfc4034.

   La valeur TTL pour un RR NSEC devrait être la même que le TTL minimum de la zone.

   Un enregistrement NSEC (et son RRset RRSIG associé) ne doit pas être le seul RRset à un nom propriétaire particulier. C'est à dir, le processus de signature ne doit pas créer les RR NSEC ou RRSIG pour les nœuds de nom propriétaire qui n'est pas le nom propriétaire d'un RRset avant que la zone ne soit signée. La principale raison pour cela est un désire pour la consistance de l'espace de nom entre les versions signées et non signées de la même zone et un désire de réduire les risques de réponses inconsistantes dans les serveurs récursifs non sécurisés.

   Le bitmap de tout RR NSEC dans une zone signée doit indiquer la présence de l'enregistrement NSEC lui-même et les enregistrement RRSIG correspondants.

   La différence entre le jeu de noms propriétaire qui nécessite les enregistrements RRSIG et le jeu de noms propriétaire qui nécessitent les enregistrements NSEC est subtile et mérite d'être souligné. Les enregistrement RRSIG sont présent aux noms propriétaires de tous les RRset autoritatifs. Les enregistrements NSEC sont présents aux noms propriétaire et également aux noms propriétaires des délégations de la zone signée vers ses enfants. Ni NSEC ni RRSIG ne sont présents (dans la zone parente) aux noms propriétaire des RRset d'adresse glue. Noter, cependant, que cette distinction est généralement visible seulement durant le processus de signature de zone, vu que les RRset NSEC sont des données autoritatives et sont donc signées. Donc, tout nom propriétaire qui a un RRset NSEC aura des RR RRSIG également dans la zone signée.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attention spéciale. Les bits correspondants au RRset NS délégation et tout RRset pour lequel la zone parent an une donnée autoritative doit être mis; les bits correspondants à un RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

Inclure les RR DS dans une zone

   Le RR DS établis les chaînes d'authentification entre les zones DNS. Un RRset DS devrait être présent à un point de délégation quand la zone enfant est signée. Le RRset DS peut contenir plusieurs enregistrement, chacun référençant une clé publique dans la zone enfant utilisée pour vérifier le RRSIG dans cette zone. Tous les RRset DS dans une zone doivent être signés, et les RRset DS ne doivent pas apparaître dans l'apex de la zone.

   Un RR DS doit pointer vers un RR DNSKEY qui est présent dans le RRset DNSKEY de l'apex de l'enfant, et ce RRset doit être signé par la clé privée correspondante. Les RR DS qui échoue à ces conditios ne sont pas utilies pour la validation, mais parce que le RR DS et son RR DNSKEY sont dans des zones correspondantes, un erreur temporaire peut se produire.

   Le TTL d'un RRset DS matche le TTL du RRset NS déléguant (la zone contenant le RRset DS).

   La construction d'un RR DS nécessite la connaissance du RR DNSKEY correspondant dans la zone enfant, ce qui implique la communication entre les zones parent et enfant. Cette communication est un moyen opérationnel non couver par ce document.

Changement des RR CNAME

   Si un RRset CNAME est présent au nom d'une zone signée, les RRset RRSIG et NESC sont requis à ce nom. Un RRset KEY à ce nom pour les mises à jours dynamique sécurisé est également fournis (rfc3007). D'autre types ne doivent pas être présent à ce nom.

   C'est une modification de la définition du CNAME original de la rfc1034. La définition original du RR CNAME ne permet pas à d'autres type de cohexister avec un enregistrement CNAME, mais une zone signée exige les RR RRSIG et NSEC pour tout nom autoritatif. Pour résoudre ce conflit, cette spécification modifie la définition du RR CNAME pour lui permettre de cohexister vace les RR NSEC et RRSIG.

Type RR DNSSEC apparaissant aux coupures de zone

   DNSSEC a introduit 2 nouveaux types de RR qui sont inhabituels par le fait qu'ils peuvent apparaître du côté du parent. Au niveau du point de délégation, les RR NSEC sont requit au nom propriétaire. Un RR DS peut également être présent si la zone à déléguer est signée et cherche à avoir une chaîne d'authentification dans la zone parent. C'est une exception de la spécification DNS original, qui status que seul les RRset NS peuvent apparaître dans le point de délégation du parent.

   Cette spécification met à jours la spécification DNS pour permettre aux types RR NSEC et DS côté parent. Ces RRset sont autoritatif pour le parent quand ils apparaissent dans le point de délégation de la zone parent.

Service

   Cette section décris le comportement des entités qui incluent les fonctions des serveurs de nom sécurisés. Dans beaucoup de cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un serveur de nom autoritatif sécurisé possède certaines de ces exigences.

   Un serveur de nom sécurisé doit supporter EDNS0 (rfc2671), une taille de message d'au moins 1220 octets, et devrait supporter une taille de message de 4000 octets. Vu que les paquets IPv6 peuvent seulement être fragmentés par l'hôte source, un serveur de nom sécurisé devrait prendre en considération les étapes pour s'assurer que les datagrammes UDP qu'il transmet sur IPv6 sont fragmentés, si nécessaire, au MTU IPv6 minimum.

   Un serveur de nom sécurisé qui reçois une requête DNS qui n'inclus pas l'option EDNS pseudo-RR ou sans le bit DO doit traite les RR RRSIG, DNSKEY et NSEC comme si c'était un RRset sans traitement additionnel. Parce que le type RR DS a la propriété particulière de n'exister que dans la zone parente, les RR DS exigent toujours un traitement spécial.

   Les serveurs de nom sécurisés qui reçoivent des requêtes explicite pour les types RR de sécurité qui matchent le contenu de plus d'une zone qu'il déssert (par exemple, les RR NSEC, et RRSIG avant et après un point de délégation œu le sereur est autoritatif pour les 2 zones) devraient de comporter comme consistant. Tant que la réponse est toujours consistante pour chaque requête au serveur de nom, le serveur peut retourner au choix:

        - Les RRsets au dessus de la délégation
        - Les RRsets au dessous de la délégation
        - Les 2
        - Une section réponse vide
        - Une autre réponse
        - Une erreur

   DNSSEC alloue 2 nouveaux bits dans l'en-tête de message DNS: CD (Checking Disabled) et AD (Authentic Data). Le bit CD est contrôlé par les résolveurs. Un serveur de nom sécurisé doit copier le bit CD de la requête dans la réponse correspondante. Le bit AD est contrôlé par les serveurs de noms, et un serveur de nom sécurisé doit ignorer le bit AD dans les requêtes.

   Un serveur de nom sécurisé qui synthétise les RR CNAME depuis les RR DNAME (rfc2672) ne devrait pas générer de signatures pour les RR CNAME synthétisés.

Serveur de nom autoritatif

   Une fois une requête reçue qui a le bit DO de l'option EDNS(0) pseudo-RR, un serveur de nom autoritatif sécurisé pour une zone signée doit inclure les RR RRSIG, NSEC et DS, en accord avec les règles suivantes:

- Les RR RRSIG qui peuvent être utilisés pour authentifier une réponse doivent être inclus dans la réponse
- Les RR NSEC qui peuvent être utilisé pour fournir un refus d'existance authentifié doivent être inclus dans la réponse
- Soit un RRset DS ou un RR NSEC prouvant qu'aucun RR DS n'existe doit être inclus dans les référrants

   Ces règles s'appliquent seulement aux réponses où les sémantiques véhiculent des informations sur la présence ou l'absence d'enregistrement de ressource. C'est à dire, Ces règles ne sont pas prévues pour pour exclure les réponses tels que RCODE 4 (Not Implemented) ou RCODE 5 (Refused).

   DNSSEC ne change pas le protocole de transfert de zone.

Inclure les RR RRSIG dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom devrait tenter d'envoyer les RR RRSIG qu'un résolveur peut utiliser pour authentifier les RRset dans la réponse. Un serveur de nom devrait tenter de conserver le RRset et ses RRSIG ensemble dans une réponse. L'ajout des RR RRSIG dans une réponse est sujet aux règles suivantes:

        - En plaçant un RRset signé dans une section Answer, le serveur de nom doit également placer ses RR RRSEG dans la section Answer. Les RR RRISG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
        - En plaçant un RRset signé dans la section Authority, le serveur de nom doit également placer ses RR RRSIG dans la section Authority. Les RR RRSIG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
        - En plaçant un RRset signé dans la section Additional, le serveur de nom doit également placer ses RR RRSIG dans la section Additional. Si l'espace ne permet pas d'inclure le RRset et ses RR RRSIG associés, le serveur de nom peut retenir le RRset et enlever les RR RRSIG. Si cela se produit, le serveur de nom ne doit pas définir le bit TC.

Inclure les RR DNSKEY dans une réponse

   En répondant à une requête qui a le bit DO mis et que demande les RR SOA et NS à l'apex d'une zone signée, un serveur de nom autoritatif pour cette zone peut retourner le RRset DNSKEY de l'apex dans la section Additional. Dans cette situation, le RRset DNSKEY et les RR RRSIG associés ont une priorité inférieur que d'autres informations à placer dans la section additionnelle. Le server de nom ne devrait pas inclure le RRset DNSKEY sauf s'il y a suffisamment de place dans la réponse pour le RRset DNSKEY et les RR RRSIG associés. S'il n'y a pas assez de place, le server de nom doit les omettre et ne doit pas inclure le bit TC uniquement pour ces RR.

Inclure les RR NSEC dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif pour une zone signée doit inclure les RR NSEC dans chacun de ces cas:

No Data: La zone contient des RRset qui matche exactement ‹SNAME, SCLASS› mais ne contient pas de RRset qui match exactement ‹SNAME, SCLASS, STYPE›.
Name Error: La zone ne contient pas de RRset qui match ‹SNAME, SCLASS›, soit exactement, soit via l'expansion wildcard
Wildcard Answer: La zone ne contient pas le RRset qui match exactement ‹SNAME, SCLASS› mais contient un RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard
Wildcard No Data: La zone ne contient pas de RRset qui match exactement ‹SNAME, SCLASS› et contient un ou plusieurs RRset que match ‹SNAME, SCLASS› via l'expansion wildcard, mais ne contient pas de RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard.

   Dans chacun de ces cas, le serveur de nom inclus les RR NSEC dans la réponse pour prouver qu'un match exact pour ‹SNAME, SCLASS, STYPE› n'était pas présent dans la zone et que la réponse que le serveur retourne les données dans la zone est correct.

Inclure les RR NSEC: No Data Response

   Si la zone contient des RRset matchant ‹SNAME, SCLASS› mais ne contient pas de RRset matchant ‹SNAME, SCLASS, STYPE›, le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS›, puis le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS› avec les RR RRSIG associés dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure le RR NSEC ou les RR RRSIG associés, le serveur de nom doit mettre le bit TC.

   Vu que le nom recherché existe, l'expansion wildcard ne s'applique par à cette requête, et un simple RR NSEC suffit à prouver que le type RR demandé n'existe pas.

Inclure les RR NSEC: Name Error Response

   Si la zone ne contient pas de RRset matchant ‹SNAME, SCLASS› soit exactement soit via l'expansion wildcard, le serveur doit incluse les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de match exace pour ‹SNAME, SCLASS›
- Un RR NSEC prouvant que la zone ne contient pas de RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard

   Dans certains cas, un simple RR NSEC peut prouver ces 2 points. Si c'est le cas, le serveur devrait seulement inclure le RR NSEC et les RR RRSIG une seule fois dans la section Authority

   Si l'espace ne le permet pas, le serveur doit mettre le bit TC.

   Les noms propriétaires de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse.

   Noter que cette forme de réponse inclus les cas dans lesquels SNAME correspond à un nom non-terminal vide dans la zone (un nom qui n'est pas le nom propriétaire pour un RRset mais qui est le nom parent d'un ou plusieurs RRset).

Inclure les RR NSEC: Wildcard Answer Response

   Si la zone ne contient pas de RRset qui matche exactement ‹SNAME, SCLASS› mais contient un RRset qui matche ‹SNAME, SCLASS, STYPE› via l'expansion wildcard, le serveur de nom doit inclure la réponse étendue et les RR RRSIG étendus correspondants dans la section Answer et doit inclure dans la section Authority un RR NSEC et les RR RRSIG associés prouvant que la zone ne contient pas de match à ‹SNAME, SCLASS›. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur doit mettre le bit TC.

Inclure les RR NSEC: Wildcard No Data Response

   Ce cas est une combinaison des précédents cas. La zone ne contient pas de match exacte pour ‹SNAME, SCLASS›, et bien que la zen contient des RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard, aucun RRset ne match STYPE. Le serveur de nom doit inclure les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de RRset correspondant à STYPE au nom propriétaire wildcard qui match ‹SNAME, SCLASS›
- Un RR NSEC prouvant qu'il n'y a pas de RRset dans la zone qui aurait matché pour ‹SNAME, SCLASS›

   Dans certains cas, un simple RR NSEC peut prouver les 2. Les noms propriétaire de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Trouver les bon RR NSEC

   Comme expliqué plus haut, il y a de nombreuses situations dans lesquelles un serveur de nom doit localiser un RR NSEC qui prouve qu'aucun RRset correspondant à un SNAME n'existe. Localiste un tel RR NSEC dans une zone autoritative est relativement simple, du moins dans le concept. La suite assume que le serveur de nom est autoritatif pour la zone. L'algorithme ci-dessous est écrit pour clareté, non pour l'efficacité.

   Pour trouver les NSEC qui prouve qu'aucun RRset ne match le nom N dans la zone Z, constuire une séquence, S, consistant des noms propriétaire de tout RRset dans Z, trié dans l'ordre canonique, sans noms dupliqué. Trouver le nom M qui aurait précédé immédiatement N dans S si un RRset avec le nom N existait. M est le nom propriétaire du RR NSEC qui prouve qu'aucun RRset n'existe avec le nom N.

   L'algorithme pour trouver le RR NSEC qui prouve qu'un nom donné n'est pas couvert par un wildcard applicable est similaire mais nécessite une étape supplémentaire. Plus précisemment, l'algorithme pour trouver le NSEC prouvant qu'aucun RRsec n'existe avec le nom wildcard applicable est précisemment le même que l'algorithme pour trouver le RR NSEC qui prouve que les RRset avec un nom propriétaire n'existe pas. La partie manquante est une méthode pour déterminer le nom du wildcard applicable non-existant. En pratique, c'est facile, parce que le serveur de nom autoritatif à déjà vérifié la présence de ce nom wildcard dans l'étape (1)(c) de l'algorithme de recherche décrit dans la rfc1034.

Inclure les RR DS dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif retournant un référant inclus les données DNSSEC avec le RRset NS.

   Si un RRset DS est présent au point de délégation, le serveur de nom doit retourner le RR DS et ses RR RRSIG associés dans la section Authority avec le RRset NS.

   Si aucun RRset DS n'est présent au point de délégation, le serveur de nom doit retourner le RR NSEC qui prouve que le RRset DS n'est pas présent et les RR RRSIG associés du RR NSEC avec les RRset NS. Le serveur de nom doit placer le RRset NS avant les RRset NSEC et les RR RRSIG associés.

   En incluant ces RR DS, NSEC, et RRSIG, la taille de message augmente et peut causer l'omission de tous les RR glue. Si l'espace ne permet pas d'inclure les RRset DS ou NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Répondre aux requêtes pour les RR DS

   Le type RR DS n'est pas courant par le fait qu'il apparaît seulement dans la zone parente. Par exemple, le RRset DS pour la délégation de "foo.example" est stockée dans la zone "example". Cela nécessite un traitement spéciale pour les serveurs de nom et les résolveurs, vu que le serveur de nom pour la zone enfant est autoritative pour le nom à la coupure de zone par les règles DNS normales mais la zone enfant ne contient pas le RRset DS.

   Un résolveur sécurisé envoie des requêtes à la zone parent en recherchant un RR DS au point de délégation. Cependant, des règles spéciales sont nécessaires pour éviter la confusion des résolveurs non sécurisés qui peuvent traiter une telle requête (par exemple, dans une configuration réseau qui force un résolveur sécurisé à canaliser ses requêtes via un serveur de nom récursif non sécurisé). Le reste de cette section décris comment un serveur de nom sécurisé traite les requêtes DS pour éviter ce problème.

   Le besoin pour un traitement spécial par un serveur de nom sécurisé survient seulement quand toutes les conditions suivantes sont rencontrées:

- Le serveur de nom a reçu une requête pour le RRset DS à la coupure de zone
- Le serveur de nom est autoritaire pour la zone enfant
- Le serveur de nom n'est pas autoritatif pour la zone parent
- Le serveur de nom n'offre pas de récursion

   Dans tous les autres cas, le serveur de nom a soit une manière d'obtenir le RRset DS soit ne s'attend pas à avoir le RRset DS même si les règles de traitement pré-DNSSEC, donc le serveur de nom peut retourner soit le RRset DS ou une erreur en accord avec les règles de traitement normal.

   Si toutes les conditions ci-dessus sont rencontrées, cependant, le serveur de nom est autoritatif pour SNAME mais ne peut pas fournir le RRset demandé. Dans ce cas, le serveur de nom doit retourner une réponse "no data" montrant que le RRset DS n'existe pas dans l'apex de la zone enfant.

Répondre aux requêtes pour le type AXFR ou IXFR

   DNSSEC ne change par le processus de transfert de zone. Une zone signée contient les RR RRSIG, DNSKEY, NSEC, et DS, mais ces enregistrement n'ont pas de signification spéciale dans les opérations de transfert de zone.

   Un serveur de nom autoritatif n'est pas tenu de vérifier qu'une zene est proprement signée avent d'envoyer ou d'accepter un transfert de zone. Cependant, un serveur de nom autoritatif peut choisir de rejeter tout le transfert de zone si la zone ne répond pas à toutes les exigences décrites dans la section Signature de zone. L'objectif principal d'un transfert de zone est de s'assurer que tous les serveurs de nom autoritatifs ont une copie identique de la zone. Un serveur de nom autoritatif qui choisis d'effectuer sa propre validation de zone ne doit pas rejeter sélectivement certains RR et en accepter d'autres.

   Les RRset DS apparaîssent seulement coté parent d'une coupure de zone et sont des données autoritatives dans la zone parent. Comme avec tout autre RRset autoritatif, le RRset DS doit être inclus dans le transfert de zone dans lequel le RRset est une donnée autoritative. Dans la cas du RRset DS, c'est la zone parent.

   Les RR NSEC apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans ces 2 zones. Les RR NSEC à la coupure de zone parent et enfant ne sont jamais identique, vu que le RR NSEC dans l'apex de la zone enfant indiquent toujours la présence du RR SOA de la zone enfant alors que le RR NSEC du parent ne l'indique pas. Comme avec tout autre RR autoritatif, les RR NSEC doivent être inclus dans les transferts de zone dans lequels ils sont des données autoritatives. Le RR NSEC parent doit être inclus dans le transfert de zone de la zone parent, et le NSEC de l'apex de la zone enfant doit être inclus dans le transfert de la zone enfant.

   Les RR RRSIG apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans la zone contenant contenant le RRset autoritatif pour lequel le RR RRSIG fournis la signature. C'est à dire, le RR RRSIG pour un RRset DS ou un RR NSEC parent à la coupure de zone sera autoritatif dans la zone parent, et le RRSIG pour un RRset dans l'apex de la zone enfant sera autoritatif dans la zone enfant. Les RR RRSIG parent et enfant à la coupure de jone ne sont jamais identique. Comme d'autres RR autoritatif, les RR RRSIG doivent être inclus dans le transfert de zone dans lequel ils sont des données autoritatives.

bits AD et CD dans une réponse autoritative

   Les bits CD et AD sont conçus pour être utilisés dans une communication entre des résolveurs sécurisés et des serveurs de nom récursifs sécurisés. Ces bits ne sont pas significatif pour le traitement par les serveurs de nom autoritatifs.

   Un serveur de nom sécurisé ne valide pas la signature pour une donnée autoritative durant le traitement de la requête, même quand le bit CD est effacé. Un serveur de nom sécurisé devrait effacer le bits CD en créant une réponse autoritative.

   Un serveur de nom sécurisé ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère que tous les RRset dans les section Answer et Authority de la réponse sont authentiques. La stratégie locale d'un serveur de nom sécurisé peut considérer les données d'une zone autoritative comme authentique sans autre validation. Cependant, le serveur de nom ne doit pas le faire à moins qu'il n'obtienne la zone autoritative via un moyen sécurisé (tel qu'un mécanisme de transfert de zone sécurisé) et ne doit pas le faire sauf si ce comportement a été configuré explicitement.

   Un serveur de nom sécurisé qui supporte la récursion doit suivre les règles suivantes pour les bits CD et AD donnés ci-dessous en générant un réponse qui implique des données obtenus via la récursion.

Servers de nom récursifs

   Comme indiqué dans la rfc4033, un serveur de nom récursif sécurisé est une entité qui agit dans les rôles de serveur de nom sécurisé et de résolveur sécurisé. Cette section utilise les termes "partie serveur de nom" et "partie résolveur" pour référrer au code dans un serveur de nom qui implémente ces 2 rôles.

   La partie résolveur suis les règles usuelles pour le caching et le caching négatif qui s'applique à tout résolveur sécurisé

Le bit DO

   La partie résolveur doit mettre le bit DO en envoyant les requêtes, sans regarder l'état du bit DO dans la requête initiale reçue par la partie serveur de nom. Si le bit DO dans une requête initiale n'est pas mise, la partie serveur de nom doit enlever tous RR DNSSEC authentifiant de la réponse mais ne doit pas enlever les type RR DNSSEC que la requête initiale a demandé explicitement.

Le bit CD

   Le bit CD existe pour permettre à un résolveur sécurisé de désactiver la validation de la signature dans le traitement du serveur de nom d'une requête particulière.

   La partie serveur de nom doit copier le paramètre du bit CD de la requête à la réponse correspondante.

   La partie serveur de nom doit passer l'état du bit CD à la partie résolveur avec le reste de la requête initiale, pour que la partie résolveur sache s'il est nécessaire de vérifier la réponse qu'il retourne à la partie serveur de nom. Si le bit CD est mis, il indique que le résolveur d'origine souhaite effectuer une authentification via sa stratégie locale. Donc, la partie résolveur n'a pas besoin d'effectuer d'authentification dans les RRset dans la réponse. Quand le bit CD est mis, le serveur de nom récursif devrait, si possible, retourner la donnée demandée au resolveur d'origine, même si la stratégie locale du serveur aurait rejeté les enregistrements en question. C'est à dire, en définissant le bit CD, le résolveur d'origine a indiqué qu'il prend la responsabilité pour effectuer sa propre authentification, et le serveur de nom n'interfers pas.

   Si la partie résolveur implémente un cache BAD et la partie serveur de nom reçois une requête qui matche une entrée dans ce cache, La réponse de la partie serveur dépend de l'état du bit CD dans la requête originale. Si le bit CD estmis, la partie serveur de nom devrait retourner la données depuis le cache; si le bit CD n'est pas mis, la partie serveur de nom doit retourner le RCODE 2 (server failure)

   L'intention de cette règle est de fournir les données brute aux clients capable d'effectuer eux-même la vérification de la signature tout en protégeant le client qui dépent de cette vérification.

Le bit AD

   La partie serveur de nom ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère tous les RRset dans les section Answer et Authority de la réponse comme étant authentiques. La partie serveur de nom devrait mettre le bit AD si et seulement si la partie résolveur considère tous les RRset dans les serveur Answer et Authority comme étant authentiques. La partie résolveur doit suivre la procédure décrite dans la section "Authentifier les réponses DNS" pour déterminer si les RR en question sont authentiques. Cependant, pour compatibilité, un serveur de nom récursif peut mettre le bit AD quand une réponse incluse des RR CNAME non signés si ces RR CNAME démontrent avoir été synthétisés depuis un RR DNAME authentique qui est également inclus dans la réponse en accord avec les règles de synthèse de la rfc2672.

Résolution

   Cette section décrit le comportement des entités qui incluent des fonctions de résolution sécurisé. Dans la plupart des cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un résolveur sécurisé a de nombreuses exigences similaires. Les fonctions spécifique aux serveurs de nom récursif sécurisés sont décrits dans la section précédente.

Support EDNS

   Un résolveur sécurisé doit inclure un OPT pseudo-RR EDNS avec le bit DO mis en envoyant les requêtes

   Un résolveur sécurisé doit supporter une taille de message d'au moins 1220 octets, devrait supporter une taille de message de 4000 octets, et doit utiliser le champ sender,' UDP payload size dans le pseudo-RR pour annoncer la taile de message qu'il est prêt à accepter. Un couche IP du résolveur sécurisé doit gérer les paquets UDP fragmentés correctement sans regarder si ces fragments sont reçus via IPv4 ou IPv6.

Support de vérification de signature

   Un résolveur sécurisé doit supporter les mécanismes de vérification de signature et devrait les appliquer à chaque réponse reçue, excepté quand:

- Le résolveur sécurisé fait partie d'un serveur de nom récursif, et la réponse est le résultat d'une récursion à la demande d'une requête reçue avec le bit CD mis;
- La réponse est le résultat d'une requête générée directement via une interface d'application qui a instruit le résolveur de ne pas effectuer de validation pour cette requête;
- La validation pour cette requête a été désactivée par stratégie locale.

   Le support d'un résolveur sécurisé pour la vérification de signature doit inclure le support pour la vérification des noms propriétaires wildcard.

   Les résolveurs sécurisés peuvent requêter les RR de sécurité manquant en tentant d'effectuer une validation; les implémentations qui choisissent de le faire doit être prêt à recevoir une réponse qui n'est pas suffisante pour valider la réponse originale. Par exemple, une mise à jours de zone peut avoir changé ou supprimé l'information désirée entre les requêtes original et les requêtes suivantes.

   En tentant de récupérer les RR NSEC manquant qui résident dans le parent, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent, pas la zone enfant.

   En tentant de récupérer un DS manquant, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent. Comme vu plus haut, les serveurs de nom doivent appliquer des traitements spéciaux pour gérer le RR DS, et dans certaines situations le résolveur peut également nécessiter d'appliquer les règles spéciales pour localiser les serveurs de nom pour la zone parent si le résolveur n'a pas le RRset NS du parent. Pour localiser le RRset NS parent, le résolveur peut commencer avec le nom de délégation, enlever le label le plus à gauche, et requêter un RRset NS par ce nom. Si aucun RRset NS n'est présent à ce nom, le résolveur enlève le label le plus à gauche et retente la requête pour ce nom, en répétant le processus jusqu'à ce qu'il trouve le RRset NS ou n'ai plus de label.

Déterminer le status de sécurité des données

   Un résolveur doit être capable de déterminer s'il doit s'attendre à un RRset particulier signé. Plus précisemment, un résolveur sécurisé doit être capable de faire la distinction entre 4 cas:

Sécure: Un RRset pour lequel le résolveur est capable de construire une chaîne de RR DNSKEY et DS signés depuis une ancre de confiance au RRset. Dans ce cas, le RRset devrait être signé et est sujet à validation de signature.
Insecure: Un RRset pour lequel le résolveur sait qu'il n'a pas de chaîne de RR DNSKEY et DS signé. Cela se produit quand le RRset cible est dans une zone non signée. Dans ce cas le résolveur ne peut pas vérifier la signature.
Bogus: Un RRset pour lequel le résolveur estime qu'il est en mesure d'établir une chaîne de confiance, mais n'est pas capable de le faire, soit en raison de signature qu'il ne parvient par à valider, soit à cause de données manquantes que les RR DNSSEC indiquent qu'elles devraient être présentes. Ce cas peut indiquer une attaque ou une erreur de configuration.
Indeterminate: Un RRset pour lequel le résolveur n'est pas capable de déterminer si le RRset est signé, vu que le résolveur n'est pas capable d'obtenir les RR DNSSEC nécessaire. Cela peut se produire quand le résolveur sécurisé n'est pas capable de contacter les serveurs de nom pour les zones concernées.

Ancres de confiance configurés

   Un résolveur sécurisé doit être capable d'être configuré avec au moin une clé publique ou ur RR DS et devrait être capable d'être configuré avec plusieurs clé ou RR DS. Vu qu'un résolveur sécurisé n'est pas capable de valider les signatures sans ancre de confiance, le résolveur devrait avoir un mécanisme robuste pour obtenir de telles clé quand il démarre; par exemple un stockage non-volatile (disque dur) ou une configuration réseau local de confiance. Noter que les ancres de confiance couvrent également les clé qui sont mis à jours de manière sécurisé, qui peut être un support physique, un protocole d'échange de clé, ou d'autres moyens tiers.

Cacher les réponses

   Un résolveur sécurisé devrait mettre en cache chaque réponse comme simple entrée atomique contenant toute la réponse, incluant le RRset nomé et tout RR DNSSEC associé. Le résolveur devrait supprimer l'entrée quand un des RR qu'il contient expire. Dans beaucoup de cas le l'index de cache approprié pour l'entrée atomique est le triplet ‹QNAME, QTYPE, QCLASS›, mais pour les cas décris dans la section "inclure les RR NSEC: Name Error Response", l'index sera ‹QNAME, QCLASS›.

   La raison de ces recommandations est que, entre la requête initiale et l'expiration des données du cache, les données autoritatives peuvent avoir changé. Il y a 2 situation pour lesquel c'est important:

1. En utilisant l'enregistrement RRSIG, il est possible de déduire qu'une réponse a été synthétisée depuis un wildcard. Un serveur de nom récursif pourrait stocker cette donnée wildcard et l'utiliser pour générer des réponses positives aux requêtes autre que le nom pour lequel la réponse originale a été reçue.
2. Les RR NSEC reçues pour prouver la non-existance d'un nom pourrait être réutilisée par un résolveur pour prouver la non-existence d'un nom dans la plage de noms.

   En théorie, un résolveur pourrait utiliser les wildcard ou les RR NSEC pour générer des réponses positives et négatives (respectivement) jusqu'à ce que le TTL ou les signatures dans les enregistrement n'expirent. Cependant, il semble prudent pour les résolveurs d'éviter de bloquer les nouvelles données autoritatives ou de synthétiser de nouvelles donnés par eux même. Les résolveurs qui suivent cette recommandation auront une vue plus consistante de l'espace de nom.

Gérer les bits CD et AD

   Un résolveur sécurisé peut mettre le bit CD d'une requête pour indiquer que le résolveur prend la résponsabilité d'effectuer toute authentification que sa stratégie locale exige sur les RRsets dans la réponse.

   Un résolveur doit effacer le bit AD en créant une requête pour se protéger contre les serveurs de nom buggés qui copient bêtement les en-têtes qu'ils ne comprennent pas de la requête dans la résponse.

   Un résolveur doit ignorer la signification des bits CD et AD dans une réponse sauf si la réponse a été obtenue en utilisant un canal sécurisé ou le résolveur a été configuré spécifiquement pour le faire.

Cache des données BAD

   Bien que de nombreuses erreurs de validation sont transitoires, certaines sont persistantes, tel que les erreurs administratives. Vu que redemander n'aide pas dans ces cas, les résolveurs validateurs peuvent générer un quantité significative de trafique DNS non-nécessaire en mettant en cache les signatures invalides, avec quelques réstrictions.

   Conceptuellement, cacher de telles données est similaire aux caching négatif (rfc2308), excepté qu'au lieu de cacher une réponse invalide, le résolveur cache le fait qu'une réponse particulière à échoué la validation. Ce document réfèrre au cache de telles données au cache BAD.

   Les résolveurs qui implémentent un cache BAD doit effectuer certaines étapes pour éviter que le cache soit utilisé comme amplificateur d'attaque DOS, particulièrement:

- Vu que les RRset qui échouent la validation n'ont pas de TTL de confiance, l'implémentation doit leur assigner un TTL. Ce TTL devrait être petit, pour mitiger l'effet de cache de résultat d'une attaque.
- Pour éviter de cacher des erreurs de validation aléatoires (qui peuvent être le résultat d'une attaque), les résolveurs devraient suivre les requêtes qui résultent en erreurs de validation de devraient seulement répondre depuuis le cache BAD après que le nombre de fois que les réponse aux requêtes pour ce ‹QNAME, QTYPE, TCLASS› particulier a échoué la validation a excédé un valeur seuil.

   Les résolveurs ne doivent pas retourner les RRset depuis le cache BAD sauf si le résolveur n'a pas à valider les signature des RRset en question.

CNAME synthétisés

   Un résolveur sécurisé validateur doit traiter la signature d'un RR DNAME signé valide comme couvrant égaleent les RR CNAME non-signés qui pourraient avoir été synthétisés depuis le RR DNAME, tel que décris dans la rfc2672, au moins dans la mesure de ne pas rejeter une réponse parce qu'elle contient seulement de tels RR CNAME.

Résolveurs stub

   Un résolveur stub sécurisé doit supporter les types de RR DNSSEC, au moins pour éviter de mal gérer les réponses simplement parce qu'elles contiennent des RR DNSSEC.

Gérer les bit DO

   Un résolveur stub sécurisé non-validateur peut inclure les RR DNSSEC retournés par un serveur de nom récursif sécurisé comme partie des données que le stub resolver envoie à l'application, mais ce n'est pas obligatoire. Un stub resolver qui le fait doit mettre le bit DO pour recevoir les RR DNSSEC depuis le serveur de nom récursif.

   Un stub resolver sécurisé validateur doit mettre le bit DO, parce que sinon il ne reçoit pas les RR DNSSEC qu'il a besoin pour la validation de la signature.

Gérer le bit CD

   Un stub resolver sécurisé non-validateur ne devrait pas mettre le bit CD en envoyant les requêtes sauf s'il est demandé par l'application, vu que par définition, un stub resolver non-validateur dépend du serveur de nom récursif sécurisé qui effectue la validation pour lui.

   Un résolveur stub sécurisé validateur devrait mettre le bit CD, parce que sinon le serveur de nom récursif va répondre à la requête en utilisant la stratégie locale du serveur de nom, qui peut empêcher le stub resolver de reçevoir des données qui seraient acceptables pour la stratégie local du stub resolver.

Gérer le bit AD

   Un stub resolver sécurisé non-validateur peut choisir d'examiner le bit AD dans les réponses qu'il reçoit pout déterminer si le serveur de nom récursif sécurisé qui envoie la réponse prétend avoir cryptographiquement vérifié les données dans les section Answer et Authority de la réponse. Noter, cependant, que les réponse reçues par un stub resolver sécurisé dépend de la stratégie locale du serveur de nom sécurisé. Un stub resolver ne doit pas placer de confiace dans la prétendue validation de signature effectuée, exceptée quand le stub resolver sécurisé a obtenu les données en question depuis un serveur de nom récursif sécurisé de confiance via un canal sécurisé.

   Un résolveur stub validateur ne doit pas examiner le bit AD dans les messages de réponse, vu que par définition, le stub resolver effectue sa propre validation de signature.

Authentifier les réponses DNS

   Pour utiliser les RR DNSSEC pour d'authentification, un résolveur doit connaître au moins un RR DNSKEY ou DS authentifié. Le processus pour obtenir et authentifier cet ancre de confiance initial est fait via un mécanisme externe. Le reste de cette section assume que le résolveur a obtenu le jeu initial d'ancres de confiance.

   Un RR DNSKEY initial peut être utilisé pour authentifier un RRset DNSKEY dans l'apex de la zone. Pour authentifier un RRset DNSKEY apex en utilisant une clé initiale, le résolveur doit:

1. Vérifier que le RR DNSKEY initial apparaît dans le RRset DNSKEY apex, et que le RR DNSKEY a le Zone Key Flag mis.
2. Vérifier qu'il y a un RR RRSIG qui couvre le RRset DNSKEY apex, et que la combinaison du RR RRSIG et du RR DNSKEY authentifient le RRset DNSKEY. Le processus pour utiliser un RR RRSIG pour authentifier un RRset est décris plus bas.

   Une fois que le résolveur a authentifié le RRset DNSKEY apex en utilisant un RR DNSKEY initial, les délégation depuis cette zone peuvent être authentifiés en utilisant les RR DS. Celà permet à un résolveur de démarrer depuis une clé initiale et d'utiliser les RRset DS pour traiter récursivement l'arborescence DNS, en obtenant les autres RRset DNSKEY apex. Si le résolveur était configuré avec un RR DNSKEY root, et si chaque délégation a un RR DS associé avec lui, le résolveur peut obtenir et valider tout RRset DNSKEY apex. Le processus d'utilisation les RR DS pour authentifier les référrants est décris plus bas.

   Quand un résolveur indique le support pour DNSSEC (en définissant le bit DO), un serveur de nom sécurisé devrait tenter de fournir les RRset DNSSEC nécessaires dans une réponse. Cependant, un résolveur sécurisé peut reçevoir une réponse dans laquelle il manque des RR DNSSEC. Un résolveur devrait attendre les informations d'authentification des zones signées. Un résolveur devrait croire qu'une zone est signée si le résolveur a été configuré avec des informations de clé publique pour la zone, ou si le parent de la zone est signée, et contient un RRset DS.

Considérations spéciales pour les îlots de sécurité

   Les îlots de sécurité sont les zones signées pour lequelles il n'est pas possible de construire une chaîne d'authentification vers la zone depuis son parent. Valider les signature dans un îlot de sécurité nécessite que le validateur ait un moyen d'obtenir une clé de zone authentifiée initiale pour l'îlot. Si un validateur ne peut pas obtenir une telle clé, il devrait opérer comme si les zones étaient non-signées.

   Tous les processus normaux pour valider les réponse s'appliquent aux îlots de sécurité. La seul différence entre une validation normale et la validation d'une un îlot de sécurité et la manière dont le validateur obtient une ancre de confiance pour la chaîne d'authentification.

Authentifier les référrants

   Une fois le RRset DNSKEY apex pour une zone parent signée est authentifiée, les RRset DS peuvent être utilisés pour authentifier la délégation pour une zone enfant signée. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY dans l'apex de la zone enfant. L'utilisation d'un algorithme de hashage fort s'assure qu'il est impossible pour un attaquant de générer un RR DNSKEY qui matche le hash. Donc, authentifier le hash permet au résolveur d'authentifier le RR DNSKEY. Le résolveur peut ainsi utiliser ce RR DNSKEY pour authentifier tout le RRset DNSKEY apex enfant.

   En donnant un RR DS pour une délégatio, le RRset DNSKEY apex de la zone enfant peut être authentifié si:

- Le RR DS a été authentifié en utilisant un RR DNSKEY dans le RRset DNSKEY apex du parent.
- Algorithm et Key Tag dans le RR DS match les champs Algorithm et Key Tag d'un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant, et, quand le nom propriétaire du RR DNSKEY et RDATA sont hashés en utilisant l' algorithme de hashage spécifié dans le champ Digest Type dans le RR DS, les valeurs de hash correspondent.
- Le RR DNSKEY correspondant dans la zone enfant a le bit Zone Flag mis, la clé privée correspondante a signé le RRset DNSKEY apex de la zone, et le RR RRSIG résultant authentifie le RRset DNSKEY apex de la zone enfant.

   Si le référant de la zone parent ne contient pas un RRset DS, la réponse devrait inclure un RRset NSEC signé prouvant qu'il n'y a pas de RRset DS pour le nom délégué. Un résolveur sécurisé doit requêter les serveurs de nom pour la zone parent à la recherche du RRset DS si le réferrant n'inclus ni un RRset DS ni un RRset NSEC prouvant que le RRset DS n'existe pas.

   Si le validateur authentifie un RRset NSEC qui prouve qu'aucun RRset DS n'est présent pour cette zone, il n'y a pas de chemin d'authentification entre le parent et l'enfant. Si la résolveur a un DNSKEY initial ou un RR DS qui appartient à la zone enfant ou pour une délégation sous la zone enfant, le RR initial peut être utilisé pour ré-établir un chemin d'authentification. Si un tel RR n'existe pas, le validateur ne peut pas authentifier les RRset.

   Si le validateur ne support aucun algorithme listé dans le RRset DS authentifié, le résolveur n'a pas de chemin d'authentification. Le résolveur devrait traiter ce cas comme si un RRset NSEC authentifié prouvait qu'il n'y a pas de DS RRset.

   Note que, pour une délégation signée, il y a 2 RR NSEC associés avec le nom délégué. Un RR NSEC réside dans la zone parent et peut être utilisé pour prouver si un RRset DS existe pour le nom délégué. Le second réside dans la zone enfant et identifie quels RRset sont présent à l'apex de la zone.

   Si le résolveur ne supporte aucun algorithme listé dans un RRset DS, le résolveur n'est pas capable de vérifier le chemin d'authentification pour la zone enfant. Dans ce cas, le résolveur devrait traiter la zone enfant comme si elle était non-signée.

Authentifier un RRset avec un RR RRSIG

   Un validateur peut utiliser un RR RRSIG et le RR DNSKEY correspondant pour tenter d'authentifier les RRset. Le validateur vérifie d'abord le RR RRSIG pour vérifier qu'il couvre le RRset, a un interval de temps valide, et identifier un RR DNSKEY valide. Le validateur construit ensuite la forme canonique de la donnée signée en ajoutant le RDATA RRSIG (sans le champ Signature) avec la forme canonique du RRset couvert. Finalement, le validateur utilise la clé publique et la signature pour authentifier la donnée signée.

Vérifier la validité RR RRSIG

   Un résolveur sécurisé peut utiliser un RR RRSIG pour authentifier un RRset si toutes les conditions suivantes sont maintenues:

- Le RR RRSIG et le RRset doivent avoir le même nom propriétaire et la même classe
- Le champ Signer's Name du RR RRSIG doit être le nom de la zone qui contient le RRset
- Le champ Type Covered du RR RRSIG doit être égal au type du RRset.
- Le nombre de labels dans le nom propriétaire du RRset doit être supérieur ou égal à la valeur dans le champ Label du RR RRSIG
- La notion du validateur du temps courant doit être inférieur ou égal au temps listé dans le champ Expiration du RR RRSIG
- La notion du validateur du temps courant doit être supérieur ou égal au temps listé dans le champ Inception du RR RRSIG.
- Les champs Signer's Name, Algorithm, et Key Tag du RR RRSIG doivent correspondre au nom propriétaire, algorithm et key tag d'un RR DNSKEY dans le RRset DNSKEY de l'apex de zone.
- Le RR DNSKEY correspondant doit être présent dans le RRset DNSKEY de l'apex de zone, et doit avoir le bit Zone Flag mis.

   Il est possible que plus d'un RR DNSKEY corresponde aux conditions ci-dessus. Dans ce cas, le validateur ne peut pas prédéterminer lequel utiliser pour authentifier la signature, et doit tenter chaque RR DNSKEY jusqu'à ce que la signature soit validée.

   Noter que ce procéssus d'authentification est seulement significatif si le validateur authentifie le RR DNSKEY avant de l'utiliser pour valider les signatures. Le RR DNSKEY correspondant est considéré authentique si:

- Le RRset DNSKEY apex contenant le RR DNSKEY est considéré comme authentique, ou
- Le RRset couvert par le RR RRSIG est le RRset DNSKEY apex lui-même, et le RR DNSKEY match soit un RR DS authentifié de la zone parent ou matche une ancre de confiance.

Reconstruire les données signées

Une fois le RR RRSIG validé, le validateur doit reconstruire la donnée signée original. Cette donnée inclus le RDATA RRSIG (sans le champ signature) et la forme canonique du RRset. En plus d'être ordonné, la forme canonique peut également différer du RRset reçu à cause de la compression de nom DNS, des TTLs décrémentés, ou de l'expansion wildcard. La validateur devrait utiliser le reconstruction suivante:
signed_data = RRSIG_RDATA | RR(1) | RR(2)...

où "|" dénote un concaténation.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

name est calculé en accord avec la fonction plus bas
class est la classe du RRset
type est le type du RRset et de tous les RR dans la classe
OrigTTL est la valeur du champ Original TTL du RRSIG
- Tous les noms dans le champ RDATA sont sous la forme canonique
- Le jeu de RR(i) est trié par ordre canonique

Pour calculer le nom:
let rrsig_labels = La valeur du champ Labels RRSIG
    
let fqdn = nom de domaine pleinement qualifié sous la forme canonique
    
let fqdn_labels = compteur de label dans le fqdn
    
if rrsig_labels = fqdn_labels, name = fqdn
    
if rrsig_labels ‹ fqdn_labels, name = "*." | Les labels rrsig_label les plus à droite du fqdn
    
if rrsig_labels › fqdn_labels
    le RR RRSIG ne passe pas nécessairement la validation et ne doit pas être utilisé pour authentifier ce RRset.

   Les RRset NSEC au point de délégation nécessitent un traitement spécial. Il y a 2 RRset NSEC distinct associé avec un nom signé délégué. Un RRset NSEC réside dans la zone parent, et spécifique quels RRset snt présent dans la zone parent. L'autre réside dans la zone enfant et identifie quels RRset sont présent à l'apex dans la zone enfant. En reconstruisant le RRset NSEC original puor la délégation depuis la zone parent, le RR NSEC ne doit pas être combiné avec les RR NSEC de la zone enfant. En reconstruisant le RRset NSEC original pour l'apex de la zone enfant, les RR NSEC ne doivent pas être combinés avec les RR NSEC de la zone parent.

   Noter que les 2 RRset NSEC au point de délégation ont un RR RRSIG correspondant avec un nom propriétaire correspondant au nom délégué, et chacun de ces RR RRSIG est une donnée autoritative associée avec la zone qui contient le RRset NSEC.

Vérifier la signature

   Une fois que le résolveur a validé le RR RRSIG et reconstruit les données signées originales, le validateur peut tenter d'utiliser la signature cryptographique pour authentifier les données signées, et donc finalement, authentifier le RRset.

   Le champ Algorithm dans le RR RRSIG identifie l'algoritme cryptographique utilisé pour générer la signature. La signature elle-même est contenue dans le champ Signature du RDATA RRSIG, et la clé publique utilisée pour vérifier la signature est contenue dans le champ Public Key du ou des RR DNSKEY correspondants

   Si le champ Labels du RR RRSIG n'est pas égal au nombre de labels dans le nom propriétaire pleinement qualifié du RRset, le RRest est soit invalide, ou le résultat d'une expansion wildcard. Le résolveur doit vérifier que l'expansion wildcard a été appliqué correctement avant de considérer le RRset comme authentique.

   Si d'autre RR RRSIG couvrent également ce RRset, la stratégie de sécurité locale du résolveur détermine s'il doit tester les RR RRSIG et comment gérer les conflits si les RR RRSIG donnent différents résultats.

   Si le résolveur accèpte le RRset, le validateur doit mettre le TTL du RR RRSIG et chaque RR dans le RRset authentifié à une valeur pas supérieur au minimum de:

- Le TTl du RRset reçu dans la réponse
- Le TTL du RR RRSIG reçu dans la réponse
- La valeur dans le champ Original TTL du RR RRSIG, et
- La différence du temps d'expiration de la signature du RR RRSIG et la date courante.

Authentifier un RRset wilcard étendu positif

   Si le nombre de labels dans le nom propriétaire du RRset est supérieur au champ Labels du RR RRSIG couvrant, le RRset et sont RR RRSIG ont été créés en résultat d'une expansion wildcard. Une fois que le validateur a vérifié la signature, il doit vérifier la non-existance d'un match exacte pour la requête.

   Noter que la réponse reçue par le résolveur devrait inclure tous les RR NSEC nécessaire pour authentifier la réponse.

Authentifier la non-existance

   Un résolveur peut utiliser les RR NSEC authentifiés pour prouver qu'un RRset n'est pas présent dans une zone signée. Les serveurs de nom sécurisés devraient automatiquement inclure les RR NSEC nécessaires pour les zones signées dans leur réponses aux résolveurs sécurisés.

   La non existance est déterminée par les règles suivantes:

- Si le RR demandé match le nom propriétaire d'un RR NSEC authentifié, le bit du type RR NSEC liste tous les types de RR présents au nom propriétaire, et un résolveur peut prouver que le type RR demandé n'existe pas en vérifiant le type RR dans le bit map. Si le nombre de labels dans un nom propriétaire du RR NSEC est égal au champ Labels du RR RRSIG couvrant, l'existence du RR NSEC prouve que l'expansion wildcard n'a pas été utilisé pour matcher la requête.
- Si le nom RR demandé apparaît après le nom propriétaire du RR NSEC authentifié et avant le nom listé dans le champ Next Domain du RR NSEC en accord avec l'ordre DNS canonique définis dans la rfc4034, alors aucun RRset avec le nom demandé n'existe dans la zone. Cependant, il est possible qu'un wildcard ait été utilisé pour correspondre au nom propriétaire et type du RR demandé, donc prouver que le RRset demandé n'existe pas nécessite également qu'aucun RRset wildcard possible n'existe qui pourrait être utilisé pour générer une résponse positive.

   De plus, les résolveurs sécurisés doivent authentifier les RRset NSEC qui incluent la preuve de non-existence. Pour prouver la non-existence d'un RRset, le résolveur doit être capable de vérifier les RRset demandés qui n'existent pas et dont aucun RRset wildcard n'existe. Prouver cela peut nécessiter plus d'un RRset NSEC de la zone. Si le jeu complet de RRset NSEC n'est pas présent dans une réponse (par ex, dû à un message tronqué), le résolveur sécurisé doit renvoyer la demande pour pouvoir tenter d'obtenir la collection de RR NSEC nécessaire pour vérifier la non-existence de RRset demandé. Comme avec toutes les opération DNS, cependant, le résolveur doit délimiter le travail qu'il place dans la réponse d'une requête particulière.

   Vu que le RR NSEC validé prouve la non-existence de lui-même et de ses RR RRSIG correspondants, un validateur doit ignorer les paramètres des bits NSEC et RRSIG dans un RR NSEC.

Comportement des résolveurs si les signatures échouent

   Si aucun des RRSIG ne peut être validé, la résponse devrait être considérée BAD. Si la validation a été faite pour desservir une requête récursive, le serveur de nom doit retourner RCODE 2 au client. Cependant, il doit retourner la réponse complète si et seulement si la requête originale avait le bit CD mis.
^
07 juillet 2014

htmlpdflatexmanmd




rfc4120

rfc4120

Le protocole Kerberos v5

Le protocole Kerberos

   Kerberos fournit un moyen de vérifier les identités des principaux sur un réseau non-sûr. Ceci est fait sans s'appuyer sur la confiance des assertions par le système hôte, sans confiance basé sur les adresses de l'hôte, sans nécessiter de sécurité physique des hôtes sur le réseau, et en assumant qui les paquets sur le réseau peuvent être lus, modifiés et insérés. Kerberos effectue une authentification dans ces conditions en tant que service d'authentification tiers en utilisant la cryptographie conventionnelle. Les extensions Kerberos peuvent permettre l'utilisation de chiffrements à clé publique durant certaines phases de l'authentification.

   Le processus d'authentification de base de Kerberos se déroule comme suit: Un client envoie une demande au serveur d'authentification (AS) pour les accréditations pour un serveur donné. l'AS répond avec ces accréditations, chiffrés avec la clé du client. les accréditations consistent d'un ticket pour le serveur et une clé de chiffrement temporaire (souvent appelé un clé de session). Le client transmet le ticket ( qui contient l'identité du client et une copie de la clé de session, le tout chiffré avec la clé du serveur) au serveur. La clé de session (maintenant partagée par le client et le serveur) est utilisé pour authentifier le client et peut optionnellement être utilisé pour authentifier le serveur. Il peut être utilisé également pour chiffrer d'autres communications entre les 2 parties ou pour échanger une clé de sous-session séparée à utiliser pour chiffrer d'autres communications.

   L'implémentation du protocole de base consiste d'un ou plusieurs serveurs d'authentification fonctionnant sur un hôte sécurisé. Les serveurs d'authentification maintiennent une base de données de principaux et leur clés secrète. Pour ajouter l'authentification à ses transactions, une application réseaux ajoute des appels à la librairie Kerberos directement ou via GSS-API. Ces appels résultent en la transmission des messages nécessaires pour accomplir l'authentification.

   Le protocole de base consiste de nombreux sous-protocoles ( ou échanges ). Il y a 2 méthodes de base pour lequel un client peut demander des accréditations. Dans la première approche, le client envoie une requête en texte clair pour le serveur désiré au serveur AS. La réponse est envoyée chiffrée avec la clé secrète du client. Généralement cette requête est pour un TGT (Ticket-Granting Ticket), qui peut être utilisé ultérieurement avec le TGS (Ticket-Granting Server). Dans la seconde méthode, le client envoie une requête au TGS. Le client utilise de TGT pour s'authentifier lui-même auprès du TGS de la même manière que s'il avait contacté un serveur d'application qui nécessitait une authentification Kerberos. La réponse est chiffrée dans la clé de session du TGT. Bien que la spécification du protocole décrive l'AS et le TGT comme des serveurs séparés, en pratique il sont souvent implémentés comme points d'entrée différents du protocole dans seul serveur Kerberos.

   Une fois obtenues, les accréditations peuvent être utilisés pour vérifier l'identité des principaux dans une transaction, pour s'assurer de l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir qu'elle protection est nécessaire.

   Pour vérifier les identités des principaux dans une transaction, le client transmet le ticket au serveur d'application. Parce que le ticket est envoyé en clair (de partie sont chiffrés, mais ce chiffrement ne déjoue pas la répétition) et peut être intercepté et réutilisé par un attaquant, des informations additionnelles sont envoyées pour prouver que le message a bien pour origine le principal à qui le ticket a été fourni. Cette information ( appelée l'authentifiant) est chiffrée dans la clé de session et inclus un horodatage. l'horodatage prouve que le message a été récemment envoyés et n'est pas rejouée. Chiffrer l'authentifiant dans la clé de session prouve qu'il a été généré par un partie possédant la clé de session. Vu que personne excepté le principal et le serveur ne connaît la clé de session ( qui n'est jamais envoyée sur le réseau en clair ), cela garantis l'identité du client.

   L'intégrité des messages échangés entre les principaux peut également être garantis en utilisant la clé de session ( passée dans le ticket et contenus dans les accréditations ). Cette approche fournis la détection contre les attaques à répétition et les attaques par modification de flux. C'est accomplis en générant et en transmettant un checksum à l'épreuve des collisions du message du client, entrée avec la clé de session. La confidentialité et l'intégrité des messages échangés entre les principaux peuvent êrte sécurisé en chiffrant le données en utilisant la clé de session contenus dans le ticket ou la clé de sous-session trouvée dans l'authentifiant.

   les échanges d'authentification mentionnés plus haut nécessitent un accès lecture seule à la base de données Kerberos. Parfois, cependant, les entrées dans la base de données doit être modifiée, par exemple pour ajouter des principaux ou changer la clé d'un principal. Pour cela on utilise un protocole entre un client et un serveur Kerberos tiers, le serveur d'administration Kerberos (KADM). Il y a aussi un protocole pour maintenir plusieurs copies de la base Kerberos. Aucun de ces protocoles n'est décris dans ce document.

Fonctionnement inter-domaine

   Le protocole Kerberos est conçus pour opérer au delà des limites organisationnelle. Un client dans une organisation peut être authentifié pour un serveur dans une autre organisation. Chaque organisation souhaitant utiliser un serveur Kerberos établis son propre "domaine" (realm). Le nom de ce domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider d'honorer ou non une requête.

   En établissant des clé inter-domaine, les administrateurs de 2 domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs dans les autres domaines. Les échanges de clé inter-domaines ( une clé séparée peut être utilisé pour chaque direction ) enregistrent le service d'allocation de ticket de chaque domaine comme un principale dans l'autre domaine. Un client est ainsi capable d'obtenir un TGT pour le service d'allocation de ticket du royaume distant depuis le domaine local. Quand ce TGT est utilisé, le service d'allocation de ticket distant utilise la clé inter-domaine ( qui généralement diffère de sa propre clé TGS normale ) pour déchiffrer le TGT; ainsi il est certain que le ticket a été fournis par le TGS du client. Les tickets fournis par le service d'allocation de ticket distant va indiquer au service final que le client a été authentifié depuis un autre domaine.

   Sans opération inter-domaine et avec les permissions appropriées, le client peut l'enregistrement d'un principal nommé séparément dans en royaume distant et engager un échange normal avec ce domaine. Cependant, même pour un petit nombre de clients, cela devient lourd à gérer, et méthodes plus automatiques sont nécessaires.

   Un domaine est dit communiquer avec un autre si les 2 domaines partagent un clé inter-domaine, ou si le domaine local partage une clé inter-domaine avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification est la séquence de domaines intermédiaire qui servent de transit d'un domaine à un autre.

   Les domaines peuvent être organisés hiérarchiquement. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaine n'est pas directement partagée par 2 domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification. Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données pour construire un chemin d'authentification entre les domaines.

   Bien que les domaines sont typiquement hiérarchiques, les domaines intermédiaire peuvent être bypassés pour effectuer une authentification inter-domain au travers d'un chemin alternatif. Il est important pour le service final de connaître les domaines traversés. Pour simplifier cette décision, un champ dans chaque ticket contient les noms des domaines qui ont servis dans l'authentification du client.

   Le serveur d'application est responsable au final d'accepter ou non l'authentification et devrait vérifier le champ de transit. Le serveur d'application peut choisir de s'appuyer sur le KDC pour la vérification de ce champ. Le KDC du serveur d'application va mettre le flag TRANSITED-POLICY-CHECKED dans ce cas. Les KDC des domaines intermédiaire peuvent également vérifier ce champ vu qu'ils fournissent des TGT pour d'autre domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas ce champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient honorer ce flag.

Choisir un principal avec lequel communiquer

   Le protocole Kerberos fournis un moyen de vérifier que l'entité avec laquelle il communique est la même que celle enregistrée avec le KDC en utilisant l'identité revendiquée (le principal). Il est nécessaire de déterminer que cette identité correspond à l'entité avec laquelle on tente de communiquer.

   Quand des données appropriées ont été échangées en avance, l'application peut effectuer cette détermination syntaxiquement basé sur la spécification du protocole de l'application, les informations fournies par l'utilisateur, et les fichiers de configuration. Par exemple, le nom principal du serveur (incluant le domaine) pour un serveur telnet peut être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande), le préfixe "host/" spécifié dans la spécification du protocole de l'application, et un mappage à un domaine Kerberos dérivé syntaxiquement depuis la partie domaine du nom d'hôte et des informations spécifiées depuis la base de domaines Kerberos locale.

   On peut également s'appuyer sur les tiers de confiance qui font cette détermination, mais seulement quand les données obtenues depuis un tiers sont convenablement protégées en intégrité lorsqu'elles résident sur le serveur du tiers de confiance et lors de leur transmission. Par exemple, on ne devrait pas pas se fier à un enregistrement DNS non protégé pour

   Les implémentations de Kerberos et les protocoles basés sur Kerberos ne doivent pas utiliser de requêtes DNS non sécurisés pour canoniser les composants du nom d'hôte des noms de principal de service. Dans un environnement sans service de nom sécurisé, les auteurs d'application peuvent ajouter un nom de domaine configuré statiquement pour les noms d'hôtes non qualifiés avant de passer ce nom aux mécanismes de sécurité. Les facilités de service de nom sécurisés, si disponible, peuvent être trustés pour la canonisation de nom d'hôte, mais une telle canonisation par le client ne devrait pas être requise par les implémentations du KDC.

Authorisation

   En tant que service d'authentification, Kerberos fournis un moyen de vérifier l'identité des principaux sur un réseau. L'authentification est généralement la première étape dans le processus d'autorisation, déterminant si un client peut utiliser un service, à quels objets le client à accès, et le type d'accès permis pour chacun. Kerberos ne fournis pas par lui-même d'autorisation. La possession d'un ticket client pour un service fournis uniquement l'authentification de ce client pour ce service, et en l'absence de procédure d'autorisation, une application ne devrait pas lui autoriser l'utilisation de ce service.

   Des méthodes d'autorisation séparés peuvent être implémentés comme fonctions de contrôle d'accès spécifique à l'application et peut utiliser des fichiers sur le serveur d'application, sur des accréditations d'autorisation fournis séparément tels que ceux fournis dans les proxys. Ces accréditations peuvent être embarqués dans une donnée d'authentification du ticket lorsqu'il est encapsulé par l'élément de données d'autorisation produit par le KDC.

   Les applications ne devraient pas accepter la délivrance d'un ticket de service par le serveur Kerberos (même par un serveur Kerberos modifié) comme accordant l'autorisation d'utiliser le service, car de telles applications peuvent devenir vulnérables au détournement de cette vérification d'autorisation dans un environnement où sont fournies d'autres options pour l'authentification d'application, ou si elles interopèrent avec d'autres KDC.

Étendre Kerberos sans rupture d'intéropérabilité

   Avec la base d'implémentation de Kerberos déployée grandissante, étendre Kerberos devient de plus en plus important. Malheureusement, certaines extensions du protocole existant créent des problèmes d'intéropérabilité à cause de l'incertitude au regard du traitement de certaines options d'extentions par certaines implémentations.

   Kerberos fournis un mécanisme général pour l'extensibilité du protocole. Certains messages du protocole contiennent des trous typés -- des sous-messages qui contiennent une chaîne d'octet et un entier qui définis comment interpréter cette chaîne d'octet. Les types entier sont enregistrés centralement, mais ils peuvent être utilisés par les vendeurs d'extension et pour les extensions standardisés.

   Dans ce document, le mot extension réfère à une extension en définissant un nouveau type à insérer dans un trou typé existant dans un message du protocole. Il ne réfère pas à l'extension en ajoutant de nouveaux champs ASN.1, sauf mention.

Envoyer des messages extensibles

   If faut s'assurer que les anciennes implémentations peuvent comprendre les messages envoyés, même si elles ne comprennent pas une extension utilisée. À moins que l'emeteur sache qu'une extension est supportée, l'extension ne peut pas changer les sémantiques du coeur du message ou des extensions définies précédemment.

   Par exemple, une extension incluant des information de clé nécessaire à déchiffrer la partie chiffrée d'un KDC-REP pourrait seulement être utilisé dans les situations où le receveur est connus pour supporter l'extension. Donc en définissant de tels extensions il est important de fournir une manière pour le receveur de notifier à l'envoyeur la prise en charge de l'extension. Par exemple dans le cas d'une extension qui change la clé de réponse de KDC-REP, le client pourrait indiquer la prise en charge de l'extension en incluant un élément padata dans la séquence AS-REQ. Le KDC ne devrait utiliser l'extension que si cet élément padata est présent dans le AS-REQ. Même si la politique exige l'utilisation de l'extension, il est préférable de retourner une erreur en indiquant que l'extension est exigée que d'utiliser l'extension alors que le receveur peut ne pas la prendre en charge.

Hypothèse sur l'environnement

   Kerberos impose quelques hypothèses sur l'environnement dans lequel il peut fonctionner de façon appropriées, qui sont les suivantes:

- Les attaques DOS ne sont pas résolues avec Kerberos. Il y a des endroits dans le protocoles où un intrus peut empêcher une application de participer aux étapes d'authentification appropriées.
- Les principaux doivent garder secrètes leurs clés secrète. Si un intrus s'empare d'une manière un d'une autre de la clé d'un principal, il sera capable de se faire passer pour ce principal ou de se déguiser en n'importe quel serveur du principal légitime.
- Les attaques en devinant le mot de passe ne sont pas résolues par Kerberos. Si un utilisateur choisit un mot de passe faible, il est possible à un agresseur de monter avec succès une attaque de dictionnaire.
- Chaque hôte sur le réseaux doit avoir une horloge synchronisée à l'heure des autres hôtes. Cette synchronisation est utilisée pour réduire les besoins d'enregistrement des serveurs d'application lorsqu'ils refont effectivement la détection. Si les horloges sont synchronisées sur le réseaux, le protocole doit lui-même être synchronisé. Le degré d'approximation normal est de l'ordre de 5 minutes
- Les identifiants de principal ne sont pas recyclés à court terme. Un contrôle de mode d'accès normal utilise des ACL pour accorder les permissions à des principaux particuliers. Si une entrée d'acl périmée subsiste pour un principal supprimé et si l'identifiant du principal est réutilisé, le nouveau principal va hériter des droits spécifiés dans l'entrée d'acl périmée. On supprime ce problème en ne réutilisant pas les identifiants de principal.

Glossaire

Authentification Vérifier l'identité revendiquée par un principal
En-tête d'authentification Enregistrement qui contient un ticket et un authentifiant à présenter à un serveur au titre du processus d'authentification.
Chemin d'authentification Séquence de domaines intermédiaires traversés dans le processus d'authentification lors de la communication d'un domaine à l'autre.
Authentifiant Enregistrement contenant des informations dont on peut montrer qu'elles ont été générées récemment en utilisant la clé de session connue seulement du client et du serveur.
Autorisation Processus pour déterminer si un client a la permission d'utiliser un service, à quels objets le client a la permission d'accès et le type d'accès permis pour chacun.
Capacité Jeton qui accorde au porteur la permission d'accéder à un objet ou service. Dans Kerberos, ce peut être un ticket dont l'utilisation est restreinte par le contenu du champ de données d'autorisation, mais qui ne donne pas d'adresse réseau, avec la clé de session nécessaire pour utiliser le ticket.
Texte chiffré Résultat d'une fonction de chiffrement. Le chiffrement transforme le texte clair en texte chiffré
Client Processus qui utilise un service réseau au nom d'un utilisateur. Noter que dans certains cas, un serveur peut être lui-même un client de quelque autre serveur (par exemple, un serveur d'impression peut être un client d'un serveur de fichiers)
Accréditifs Un ticket plus la clé de session secrète nécessaire pour utiliser ce ticket avec succès dans un échange d'authentification
Type de chiffrement (etype) Associé à des données chiffrées; un type de chiffrement identifie l'algorithme utilisé pour chiffrer les données et est utilisé pour choisir l'algorithme approprié pour déchiffrer les données. Les étiquettes de type de chiffrement sont communiquées dans d'autres messages pour énumérer les algorithmes qui sont souhaités, pris en charge, préférés, ou permis en utilisation pour le chiffrement des données entre les parties. Cette préférence est combinée aux informations et politiques locales pour choisir l'algorithme à utiliser.
KDC (Key Distribution Center) Centre de distribution de clés. Service réseau qui fournit les tickets et les clés de sessions temporaires ; ou instance de ce service ou l'hôte sur lequel il fonctionne. Le KDC sert à la fois le ticket initial et les demandes de ticket d'allocation de ticket. La portion de ticket initial est parfois appelée serveur (ou service) d'authentification. La portion de ticket d'allocation de ticket est parfois appelée serveur (ou service) d'allocation de ticket.
Kerberos Nom donné au service d'authentification du Projet Athéna, protocole utilisé par ce service, ou code utilisé pour mettre en œuvre le service d'authentification. Le nom vient de celui du chien à trois têtes qui garde l'Hadès
Numéro de version de clé (kvno,Key Version Number) Étiquette associée aux données chiffrées qui identifie quelle clé a été utilisée pour le chiffrement lorsque une clé à longue durée associée à un principal change au fil du temps. Il est utilisé durant la transition vers une nouvelle clé de sorte que la partie qui déchiffre un message puisse dire si les données ont été chiffrées avec la vieille ou la nouvelle clé
Texte en clair Entrée dans une fonction de chiffrement ou sortie d'une fonction de chiffrement. Le déchiffrement transforme le texte chiffré en texte clair.
Principal Entité client ou serveur nommée qui participe à une communication réseau, avec un nom qui est considéré comme canonique.
Identifiant de principal Nom canonique utilisé pour identifier de façon univoque chaque différent principal.
Sceau Pour chiffrer un enregistrement contenant plusieurs champs de telle sorte que les champs ne puissent pas être remplacés individuellement sans connaissance de la clé de chiffrement ou sans laisser de traces d'altération.
Clé secrète Clé de chiffrement partagée par un principal et le KDC, distribuée en dehors des limites du système, avec une durée de vie longue. Dans le cas du principal d'un utilisateur humain, la clé secrète peut être déduite d'un mot de passe.
Serveur Principal particulier qui fournit une ressource aux clients réseau. Le serveur est parfois appelé serveur d'application.
Service Ressource fournie aux clients réseau; souvent fournie par plus d'un serveur (par exemple, un service de fichier distant)
Clé de session Clé de chiffrement temporaire utilisée entre deux principaux, avec une durée de vie limitée à la durée d'une seule "session" de connexion. Dans le système Kerberos, une clé de session est générée par le KDC. La clé de session est distincte de la sous-clé de session, décrite ci-après
Sous-clé de session Clé de chiffrement temporaire utilisée entre deux principaux, choisie et échangée par les principaux en utilisant la clé de session, et avec une durée de vie limitée à la durée d'une seule association. La sous-clé de session est aussi appelée sous-clé.
Ticket Enregistrement qui aide un client à s'authentifier auprès d'un serveur; il contient l'identité du client, une clé de session, un horodatage, et d'autres informations, toutes scellées en utilisant la clé secrète du serveur. Il ne sert qu'à authentifier un client lorsqu'il est présenté avec un authentifiant frais.

Utilisation et demandes de flags de ticket

   Chaque ticket Kerberos contient un ensemble de flags utilisés pour indiquer les attributs de ce ticket. La plupart des flags peuvent être demandés par un client lorsque le ticket est obtenu; certains sont automatiquement activés et désactivés en fonction des besoins du serveur. À l'exception du flag INVALID, les clients doivent ignorer les flags qu'ils ne reconnaissent pas. Les KDC doivent ignorer les options KDC qui ne sont pas reconnus. Certaines mises en œuvre de la rfc1510 sont connues pour rejeter les options KDC si la demande a été rejetée alors qu'elle avait été envoyée avec des options ajoutées depuis la rfc1510. Comme les nouveaux KDC ignorent les options inconnues, les clients doivent confirmer que le ticket retourné satisfait leur besoins.

   Noter qu'il n'est en général pas possible de déterminer si une option n'a pas été satisfaite parce qu'elle n'a pas été comprise ou si elle a été rejetée à cause de la configuration ou de la politique. Lors de l'ajout d'une nouvelle option au protocole Kerberos, les concepteurs devraient examiner si la distinction est importante pour leur option. Si elle l'est, il faut fournir un mécanisme pour que le KDC retourne une indication comme quoi l'option a été comprise mais rejetée, dans la spécification de l'option. Souvent dans de tels cas, le mécanisme doit être suffisamment tolérant pour permettre qu'une erreur soit retournée.

Ticket initial, pré-authentification, et matériel authentifié

   Le flag INITIAL indique qu'un ticket a été produit en utilisant le protocole d'AS, plutôt que produit sur la base d'un TGT. Les serveurs d'application qui veulent demander la preuve de la connaissance de la clé secrète d'un client (par exemple, un programme à changement de mot de passe) peut insister pour que ce flag soit établi dans tous les tickets qu'il accepte, et peut donc être assuré que la clé du client a été récemment présentée au serveur d'authentification.

   Les flags PRE-AUTHENT (pré-authentifié) et HW-AUTHENT (matériel-authentifié) donnent des informations supplémentaires sur l'authentification initiale, que le ticket en cours ait été produit directement (dans ce cas le flag INITIAL est établi) ou qu'il soit produit sur la base d'un TGT (le flag INITIAL n'est pas mis, mais PRE-AUTHENT et HW-AUTHENT sont ramenés du TGT).

Tickets invalides

   Le flag INVALID indique qu'un ticket est invalide. Les serveur d'application doivent rejeter les tickets qui ont ce fjag. Un ticket postdaté sera toujours produit sous cette forme. Les tickets invalides doivent être validés par le KDC avant utilisation, en étant présentés au KDC dans une demande TGS avec l'option VALIDATE spécifié. Le KDC ne validera le ticket qu'après l'heure de début soit passée. La validation est exigée de sorte que les tickets postdatés qui ont été volés avant leur heure de début puissent être rendus invalides de façon permanente (grâce à un mécanisme de liste noire)

Tickets renouvelables

   Les applications peuvent désirer détenir des tickets qui soient valides pour de longues durées. Cependant, cela peut exposer leurs accréditifs à des menaces de vol. Utiliser simplement des tickets à courte durée de vie et en obtenir périodiquement de nouveaux exige que le client ait un accès à long terme à sa clé secrète, ce qui présente un risque encore plus grand. Les tickets renouvelables peuvent être utilisés pour atténuer les conséquences d'un vol. Les tickets renouvelables ont 2 heures d'expiration: la première est quand l'instance actuelle du ticket expire, et la seconde est la valeur permissible la plus tardive pour une heure d'expiration individuelle. Un client d'application doit périodiquement présenter au KDC un ticket renouvelable, avec l'option RENEW dans la demande.

   Le KDC va produire un nouveau ticket avec une nouvelle clé de session et une nouvelle heure d'expiration. Tous les autres champs du ticket sont laissés inchangés par le processus de renouvellement. Lorsque arrive l'heure d'expiration la plus tardive permissible, le ticket est expiré de façon permanente. À chaque renouvellement, le KDC peut consulter une liste noire pour déterminer si le ticket a été noté volé depuis son dernier renouvellement.

   Le flag RENEWABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut habituellement être ignoré par les serveurs d'application. Cependant, certains serveurs d'application particulièrement soigneux peuvent interdire les tickets renouvelables.

   Si un ticket renouvelable n'est pas renouvelé à son heure d'expiration, le KDC ne renouvellera pas le ticket. Le flag RENEWABLE est rétabli par défaut, mais un client peut demander qu'il soit établi en mettant l'option RENEWABLE dans le message KRB_AS_REQ. S'il est établi, le champ renew-till dans le ticket contient l'heure après laquelle le ticket ne peut plus être renouvelé.

Tickets postdatés

   Les applications peuvent parfois avoir besoin d'obtenir des tickets à utiliser beaucoup plus tard; par exemple, un système de soumission par lots aura besoin de tickets valides au moment où le lot est à traiter. Cependant, il est dangereux de détenir des tickets valides dans une file d'attente. Les tickets postdatés fournissent le moyen d'obtenir ces tickets du KDC au moment de la soumission de la tâche, mais de les laisser dormants jusqu'à ce qu'ils soient activés et validés par une demande ultérieure du KDC. Si un vol de ticket devait être rapporté dans l'intervalle, le KDC refuserait de valider le ticket.

   Le flag MAY-POSTDATE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Ce flag doit être établi dans un TGT afin de produire un ticket postdaté sur la base du ticket présenté. Il est rétabli par défaut; un client peut le demander en établissant l'option ALLOW-POSTDATE dans le KRB_AS_REQ. Ce flag ne permet pas à un client d'obtenir un TGT postdaté; les TGT postdatés ne peuvent être obtenus qu'en demandant le postdatage dans le KRB_AS_REQ. La durée de vie d'un ticket postdaté sera la durée de vie restante du TGT au moment de la demande. Sauf si l'option RENEWABLE est aussi établie, auquel cas elle peut être la durée de vie complète du TGT. Le KDC peut limiter la durée d'un ticket postdaté.

   Le flag POSTDATED indique qu'un ticket a été postdaté. Le serveur d'application peut vérifier le champ authtime dans le ticket pour voir quand est survenue l'authentification originale. Certains services peuvent choisir de rejeter ces tickets, ou ne les accepter que dans une certaine période après l'authentification originale. Lorsque le KDC produit un ticket POSTDATED, il sera aussi marqué INVALID, de sorte que le client d'application doit présenter le ticket au KDC pour validation avant utilisation.

Tickets mandatables et mandataires

   Il peut être nécessaire qu'un principal permette à un service d'effectuer une opération en son nom. Le service doit être capable de prendre l'identité du client, mais seulement pour un objet particulier. Un principal peut permettre à un service de faire cela en lui accordant un mandat (proxy).

   Le processus de délivrance d'un mandat en utilisant les flags proxy et proxiable est utilisé pour fournir des accéditifs à utiliser avec des services spécifiques. Bien que ce soit conceptuellement aussi un mandat, les utilisateurs qui souhaitent déléguer leur identité dans une forme utilisable à tous propos doivent utiliser le mécanisme de transmission de ticket décrit au paragraphes suivant pour transmettre un TGT.

   Le flag PROXIABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Lorsqu'il est établi, ce flag dit au TGS qu'il est d'accord pour produire un nouveau ticket (mais pas un TGT) avec une adresse réseau différente fondée sur ce ticket. Ce flag est établi s'il est demandé par le client à l'authentification initiale. Par défaut, le client demandera qu'il soit établi lorsqu'il demande un TGT, et gu'il soit rétabli lorsqu'il demande tout autre ticket.

   Ce flag permet à un client de passer au serveur proxy d'effectuer une demande distante en son nom (par exemple, un client de service d'impression peut donner mandat au serveur d'impression d'accéder aux fichiers du client sur un serveur de fichiers particulier afin de satisfaire à une demande d'impression).

   Afin de compliquer l'utilisation des accréditifs volés, les tickets Kerberos sont souvent valides pour les seules adresses réseau spécifiquement incluses dans le ticket, mais il est permis, comme option de politique de permettre des demandes et de produire des tickets sans aucune adresse réseau spécifiée. Lorsqu'il accorde un mandat, le client doit spécifier la nouvelle adresse réseau à partir de laquelle le mandat sera utilisé ou indiquer que le mandat est produit pour être utilisé sur toute adresse.

   Le flag PROXY est établi dans un ticket par le TGS lorsqu'il produit un ticket proxy. Les serveurs d'application peuvent vérifier ce flag; et optionnellement peuvent demander une authentification supplémentaire de la part de l'agent qui présente de mandat afin de fournir une trace d'audit.

Tickets transmissibles

   La transmission d'authentification est une instance de mandat dans laquelle le service qui est accordé est l'utilisation complète de l'identité du client. Exemple: Un usager qui s'enregistre sur un système distant et veut l'authentification pour travailler à partir de ce système comme si l'enregistrement était local.

   Le flag FORWARDABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Le flag FORWARDABLE a une interprétation similaire à PROXIABLE, sauf que les TGT peuvent aussi être produits avec des adresses réseau différentes. Ce flag est ré-initialisé par défaut, mais les utilisateurs peuvent demander qu'il soit établi en mettant l'option FORWARDABLE dans la demande d'AS lorsqu'ils demandent le TGT initial.

   Le flag FORWARDED est mis par le TGS lorsqu'un client présente un ticket avec le flag FORWARDABLE mis et demande un ticket transmis en spécifiant l'option KDC FORWARDED et en fournissant un ensemble d'adresses pour le nouveau ticket. Il est aussi établi dans tous les tickets produits sur la base de tickets ayant le flag FORWARDED mis. Les serveurs d'application peuvent choisir de traiter les tickets FORWARDED différemment.

   Si les tickets sans adresse sont transmis d'un système à un autre, les clients devraient continuer d'utiliser cette option pour obtenir un nouveau TGT afin d'avoir des clés de session différentes sur les différents systèmes.

Vérification des stratégies traversées

   Dans Kerberos, le serveur d'application est responsable en dernier ressort de l'acceptation ou du rejet de l'authentification, et il devrait vérifier que seuls des KDC de confiance sont impliqués dans l'authentification d'un principal. Les champs de transit dans le ticket identifient quels domaines ( et donc quels KDC ) ont été impliqués dans le processus d'authentification, et un serveur d'application devrait normalement vérifier ce champ. Si l'un d'eux n'est pas de confiance pour authentifier le principal de client indiqué (probablement déterminé par une politique fondée sur le domaine), la tentative d'authentification doit être rejetée. La présence de ?DC de confiance dans cette liste ne donne aucune garantie; un KDC compromis peut avoir fabriqué la liste.

   Bien que le serveur d'extrémité décide en dernier ressort si l'authentification est valide, le KDC pour le domaine du serveur l'extrémité peut appliquer une politique spécifique du domaine pour la validation du champ de transit et l'acceptation des accréditifs pour l'authentification de traversée de domaine. Lorsque le KDC applique de telles vérifications et accepte une telle authentification de traversée de domaine, il va établir le flag TRANSITED-POLICY-CHECKED dans les tickets de service qu'il produit sur la base du TGT de traversée de domaine. Un client peut demander que les KDC ne vérifient pars le champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient respecter ce flag.

   Les serveurs d'application doivent soit faire eux-mêmes les vérifications de domaine traversé soit rejeter les tickets de traversée de domaine sans que TRANSITED-POLICY-CHECKED sois mis.

OK-as-Delegate

   Pour certaines applications, un client peut avoir besoin de déléguer son autorité à un serveur pour agir en son nom en contactant d'autres services. Cela exige que le client transmette les accréditifs à un serveur intermédiaire. La capacité pour un client à obtenir un ticket de service pour un serveur n'apporte pas d'information au client sur la question de savoir si le serveur devrait être considéré comme de confiance pour accepter des accréditifs délégués. Le flag OK-AS-DELEGATE donne à un KDC un moyen pour communiquer une politique de domaine local à un client sur le sujet de savoir si un serveur intermédiaire est de confiance pour accepter de tels accréditifs.

   La copie des flags de ticket dans la partie chiffrée de la réponse du KDC peut avoir le flag OK-AS-DELEGATE établi pour indiquer au client que le serveur spécifié dans le ticket a été déterminé par la politique du domaine comme étant un récepteur convenable de délégation. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs (en accordant soit un mandat soit un TGT retransmis) à ce serveur. Il est acceptable d'ignorer la valeur de ce flag. Lorsqu'il établit ce flag, un administrateur devrait considérer la sécurité et le placement du serveur sur lequel va fonctionner le service, ainsi que si le service exige l'utilisation d'accréditifs délégués.

Autres options de KDC

   Il y a 3 options supplémentaires qui peuvent être établies dans une demandes de KDC du client

Renewable-OK

   L'option REMEWABLE-OK indisque que le client acceptera un ticket renouvelable si un ticket avec la durée de vie demandée ne peut pas être autrement fourni. Si un ticket avec la durée de vie demandée ne peut pas être fourni, le KDC peut alors produire un ticket renouvelable avec un renew-till égal à la fin de durée de vie demandée. La valeur du champ renew-till peut encore être ajustée par des limites déterminées par le site ou des limites imposées par le principal ou serveur individuel.

ENC-TKT-IN-SKEY

   Dans sa forme de base, le protocole Kerberos prend en charge l'authentification dans un montage client-serveur et ne convient pas bien pour l'authentification dans un environnement d'homologue à homologue parce que la clé à long terme de l'usager ne reste pas sur la station de travail après la connexion initiale. L'authentification de tels homologues peut être prise en charge par Kerberos dans sa variante d'usager à usager. L'option ENC-TKT-IN-SKEY prend en charge l'authentification d'usager à usager en permettant que le KDC produise un ticket de service chiffré en utilisant la clé de session provenant d'un autre TGT produite pour un autre usager. L'option ENC-TKT-IN-SKEY n'est honorée que par le TGT. Elle indique que le ticket à produire pour le serveur est à chiffrer dans la clé de session à partir du second TGT supplémentaire fourni avec la demande.

Authentification hardware sans mot de passe

   L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser une forme d'authentification de matériel à la place de ou en plus du mot de passe du client ou autre clé de chiffrement à longue durée de vie. OPT-HARDWARE-AUTH n'est honoré que par l'AS. S'il est pris en charge et admis par la politique, le KDC va retourner un code d'erreur de KDC_ERR_PREAUTH_REQUIRED et inclure les METHOD-DATA exigées pour effectuer une telle authentification.

Échange de messages

   Les paragraphes qui suivent décrivent les interactions entre les clients et serveurs réseau et les messages impliqués dans ces échanges.

Échange service d'authentification

   L'échange de service d'authentification ( AS ) entre le client et le serveur d'authentification Kerberos est initialisé par un client qui souhaite obtenir des accréditifs d'authentification pour un serveur donné mais ne détient pas actuellement d'accréditifs. Dans la forme de base, la clé secrète du client est utilisée pour le chiffrement et le déchiffrement. Cet échange est normalement utilisé à l'initialisation d'une session de connexion pour obtenir des accréditifs pour un serveur d'allocation de tickets ( TGS ). qui seront utilisés ultérieurement pour obtenir des accréditifs pour d'autres serveurs sans avoir besoin d'utiliser la clé secrète du client. Cet échange est aussi utilisé pour demander des accréditifs pour des services qui ne doivent pas passer par le TGS ( le service de changement de mot de passe refuse les demandes si le demanteur ne peut pas démontrer qu'il a connaissance du vieux mot de passe ).

   Cet échange ne fournit par lui-même aucune assurance de l'identité de l'usager. Pour authentifier un usager qui s'inscrit sur un système local, les accréditifs obtenus dans l'échange d'AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des accréditifs pour un serveur local; ces accréditifs doivent ensuite être vérifiés par un serveur local à travers l'achèvement réussi de l'échange client/serveur.

   L'échange AS consiste en 2 messages: KRB_AS_REQ et KRB_AS_REP ou KRB_ERROR.

   Dans la demande, le client envoie (en clair) sa propre identité et l'identité du serveur pour lequel il demande les accréditifs, d'autres informations sur les accréditifs qu'il demande, et un nom temporaire généré de façon aléatoire qui peut être utilisé pour détecter des répétitions et pour associer les réponses aux demandes correspondantes. Ce nom temporaire doit être généré de façon aléatoire par le client et mémorisé pour vérification par rapport au nom aléatoire dans la réponse attendue. La réponse, KRB_AS_REP, contient un ticket que le client présentera au serveur, et une clé de session qui sera partagée par le client et le serveur. La clé de session et les informations supplémentaire sont chiffrées avec la clé secrète du client. La partie ciffrée du message KRB_AS_REP contient aussi le nom temporaire qui doit correspondre au nom temporaire provenant du message KRB_AS_REQ.

   Sans pré-authentification, l'AS ne sait pas si le client est réellement le principal nommé dans la demande. Il envoie simplement une réponse sans savoir s'il sont les mêmes et sans s'en soucier. Ceci est acceptable puisque personne sauf le principal dont l'identité a été donnée dans la demande se sera capable d'utiliser la réponse. Ses information critiques sont chiffrées avec la clé du principal. Cependant, un attaquant peut envoyer un message KRB_AS_REQ pour obtenir du texte en clair connu afin d'attaquer la clé du principal. Et particulièrement si la clé se fonde sur un mot de passe, cela peut créer un danger pour la sécurité. Ainsi, la demande initiale prend en charge un champ facultatif qui peut être utilisé pour passer des informations supplémentaires nécessaire pour l'échange initial. Ce champ devrait être utilisé pour la pré-authentification.

   Diverses erreurs peuvent survenir; elles sont indiquées par une réponse d'erreur KRB_ERROR à la place de la réponse KRB_AS_REP. Le message d'erreur n'est pas chiffré. Ce message contient des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Le contenu du message KRB_ERROR n'est pas protégé en intégrité, donc le client ne peut pas détecter les répétitions, contrefaçons, ou modifications. Une solution à ce problème sera donnée dans une prochaine version du protocole.

Génération du message KRB_AS_REQ

   Le client peut spécifier un certain nombre d'options dans la demande initiale. Parmi ces options figure la question de savoir si la pré-authentification est à effectuer; si le ticket demandé est renouvelable, mandatable, ou transmissible; s'il devrait être postdaté ou permettre de postdatage de tickets déduits; et si un ticket renouvelable sera accepté à la place d'un ticket non renouvelable si la date d'expiration du ticket demandé ne peut pas être satisfaite par un ticket non renouvelable.

Réception du message KRB_AS_REQ

   Si tout va bien, le traitement du message KRB_AS_REP résultera en la création d'un ticket que le client présentera au serveur.

   Parce que Kerberos peut fonctionner sur des transports non fiables comme UDP, le KDC doit être prêt à retransmettre des réponses dans le cas où elles sont perdues. Si un KDC reçoit une demande identique à l'une de celles qu'il a récemment traitées avec succès, le KDC doit répondre par un message KRB_AS_REP plutôt qu'une erreur de répétition. Afin de réduire la quantité de texte chiffré à disposition d'un attaquant potentiel, les KDC peuvent envoyer la même réponse que générée lors du premier traitement de la demande. Les KDC doivent obéir à ce comportement de répétition même si le transport réel utilisé est fiable.

Génération du message KRB_AS_REP

   Le serveur d'authentification cherche dans sa base de données les principaux de client et de serveur nommés dans le message KRB_AS_REQ, et en extrait les clés respectives. Si le principal client demandé nommé dans la demande est inconnu parce qu'il n'existe pas dans la base de données de principaux du KDC, un message d'erreur est retourné avec un KDC_ERR_C_PRINCIPAL_UNKNOWN.

   S'il lui est demandé de faire ainsi, le serveur pré-authentifie la demande, et si la vérification de pré-authentification échoue, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILES. Si la pré-authentification est exigée, mais n'était pas présente dans la demande, un message d'erreur avec le code KDC_ERR_PREAUTH_REQUIRED est retourné, et un objet METHOD-DATA sera mémorisé dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Cela inclure habituellement les éléments PA-ETYPE-INFO et/ou PA-ETYPE-INFO2. Si le serveur ne peut pas s'accommoder d'un des types de chiffrement demandé par le client, un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP est retourné.

   Autrement, le KDC génère une clé de session "aléatoire", ce qui signifie, entre autres choses, qu'il devrait être impossible de deviner la prochaine clé de session sur la base de la connaissance des clés de session passées. Bien que cela puisse être réalisé avec un générateur de nombres pseudo-aléatoires s'il se fonde sur les principes cryptographiques, il est plus souhaitable d'utiliser un générateur de nombres vraiment aléatoires, comme un de ceux fondés sur la mesure de phénomènes physiques aléatoires.

   En réponse à une demande d'AS, s'il y a plusieurs clés de chiffrement inscrites pour un client dans la base de données Kerberos, le champ etype de la demande d'AS est utilisé par le KDC pour choisir la méthode de chiffrement à utiliser pour protéger la partie chiffrée du message KRB_AS_REP qui est envoyé au client. S'il y a plus d'un type de chiffrement fort dans la liste etype, le KDC devrait utiliser le premier etype fort valide pour lequel une clé de chiffrement est disponible.

   Lorsque la clé de l'utilisateur est générée à partir d'un mot de passe ou d'une passphrase, la fonction string-to-key pour le type de clé de chiffrement particulier est utilisé, comme spécifié dans la rfc 3961. La valeur de salt et les paramètres supplémentaires pour la fonction string-to-key ont des valeurs par défaut qui peuvent être remplacés par les données de pré-authentification (n (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Comme le KDC est supposé mémoriser une copie seulement de la clé résultant, ces valeurs ne devraient pas être changées pour des clés fondées dus des mots de passe excepté lorsqu'on change la clé du principal.

   Lorsque le serveur d'AS va inclure les données de pré-authentification dans un KDC-ERROR ou dans un AS-REP, il doit utiliser PA-ETYPE-INFO2 et non PA-ETYPE-INFO, si le champ etype de la AS-REQ du client comporte au moins un type de chiffrement "plus récent". Autrement (lorsque le champ etype de l'AS-REQ ne comporte aucun type de chiffrement plus récent), il doit envoyer les deux PA-ETYPE-INFO2 et PA-ETYPE-INFO (tous 2 avec une entrée pour chaque enctype). Un enctype "plus récent" est tout enctype spécifié officiellement en premier concurrement ou ultérieurement à la publication de la présent rfc. Les enctypes DES, 3DES, ou RC4 et tous ceux définis dans la RFC1510 ne sont pas des enctypes "plus récents"

   Il n'est pas possible de générer une clé utilisateur de façon fiable selon une passphrase donnée sans contacter le KDC, car on ne pourra pas savoir si des valeurs de salt ou de paramètres de remplacement sont nécessaires.

   Le kDC va essayer d'allouer le type de la clé de session aléatoire d'après la liste des méthodes dans le champ etype. Le KDC va sélectionner le type approprié en utilisant la liste des méthodes fournie et les informations tirées de la base de données Kerberos qui indique les méthodes de chiffrement acceptables pour le serveur d'application. Le KDC ne produira pas de tickets avec un type faible de chiffrement de clé de session.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans une fenêtre acceptable pour le KDC et si l'option POSTDATE n'a pas été spécifié, l'heure de début du ticket est réglée à l'heure en cours du serveur d'authentification. S'il indique une heure future au delà de la fenêtre acceptable, mais si l'option POSTDATED n'a pas été spécifiée, l'erreur KDC_ERR_CANNOT_PORTDATE est retournée. Autrement, l'heure de début demandée est vérifiée par rapport à la politique du domaine local, et si l'heure de début du ticket est acceptable, il est réglé comme demandé, et le flag INVALID est mis dans le nouveau ticket.

   L'heure d'expiration du ticket sera réglée au plus tôt de l'heure de fin demandée et de l'heure déterminée par la politique locale, éventuellement en utilisant des facteurs spécifiques du domaine ou du principal. Par exemple, l'heure d'expiration peut être réglée au plus tôt de ce qui suit:

- L'heure d'expiration demandée dans le message KRB_AS_REQs
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal d'après la base de données du serveur d'authentification.
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal
- L'heure de début du ticket plus la durée de vie maximum réglée par la stratégie du domaine local

   Si l'heure d'expiration demandée moins l'heure de début est inférieur à la durée de vie minimum déterminée par un site, un message d'erreur avec le code KDC_ERR_NEVER_VALID est retourné. Si l'heure d'expiration demandée pour le ticket excède ce qui a été déterminé ci-dessus, et si l'option RENEWABLE-OK était demandé, le flag RENEWABLE est alors mis dans le nouveau ticket, et le champ renew-till peut être réglé au plus tôt de:

- Sa valeur demandée
- L'heure de début du ticket plus le minimum des deux durées de vie maximum associées aux entrées de base de données des principaux
- L'heure de début plus la durée de vie renouvelable maximum réglée par la politique du domaine local

   Le champ des flags du nouveau ticket aura les options suivantes établies s'ils ont été demandés et si la politique du domaine local le permet: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.. Si le nouveau ticket est postdaté, son flag INVALID est également mis.

   Si tout ce qui précède réussit, le serveur va chiffrer la partie de ciphertext du ticket en utilisant la clé de chiffrement extraite de l'enregistrement du principal du serveur dans la base de données Kerberos en utilisant le type de chiffrement associé à la clé du principal du serveur (ce choix n'est pas affecté par le etype dans la requête). Il forge alors un message KDC_AS_REP, en copiant les adresses de la demande dans le caddr de la réponse, en plaçant toutes les données de pré-authentification demandées dans le padata de la réponse, et en chiffrant la partie ciphertext dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande, ou dans une clé spécifiée par le mécanisme de pré-authentification utilisé.

Génération du message KDC_ERROR

   Plusieurs erreurs peuvent survenir, et le serveur d'authentification répond en envoyant un message d'erreur, KDC_ERROR, au client, avec les champs code d'erreur et e-text réglés aux valeurs appropriées.

Réception du message KRB_AS_REP

   Si le type du message de réponse est KDC_AS_REP, le client vérifie alors que les champs cname et crealm de la portion de texte en clair de la réponse correspondent à ce qui était demandé. Si un champ padata est présent, il peut être utilisé pour déduire la clé secrète appropriée pour déchiffrer le message. Le client déchiffre la partie chiffrée de la réponse en utilisant sa clé secrète et vérifie que le nom temporaire dans la partie chiffrée correspond au nom occasionnel qu'il a fourni dans sa demande (pour détecter des répétitions). Il vérifie aussi que sname et srealm de la réponse correspondent à ceux de la demande (ou des valeurs attendues), et que le champ d'adresse d'hôte est correcte. Il mémorise alors le ticket, la clé de sessions, les heures de début et d'expiration, et les autres informations pour un usage ultérieur. Le champ last-req (et le champ déconseillé key-expiration) tirés de la partie chiffrée de la réponse peuvent être vérifiés pour notifier à l'utilisateur une expiration de clé imminente. Ceci permet au programme client de suggérer un remède, comme un changement de mot de passe.

   À la validation du message KRB_AS_REP (en comparant le nom temporaire avec celui envoyé), le client sait que l'heure courante du KDC est celle lue dans le champ authtime de la partie chiffrée de la réponse. Le client peut optionnellement utiliser cette valeur pour synchroniser l'horloge dans les messages suivant en enregistrant avec le ticket la différence entre la valeur de authtime et l'horloge locale. Cet offset peut ainsi être utilisé par le même utilisateur pour ajuster le temps lu de l'horloge système lors de la génération des messages.

   Cette technique doit être utilisée en ajustant le biais d'horloge au lieu de changer directement l'horloge système, parce que la réponse du KDC n'est authentifiée qu'auprès de l'utilisateur dans la clé secrète a été utilisée, mais pas auprès du système ou de la workstation.

   Le déchiffrement correcte du message KRB_AS_REP n'est pas suffisant à l'hôte peut vérifier l'identité de l'utilisateur qui se connecte sur la workstation. L'utilisateur et un attaquant pourraient coopérer pour générer un message de format KRB_AS_REP qui se déchiffre correctement mais ne serait pas du KDC approprié. Si l'hôte souhaite vérifier l'identité de l'utilisateur, il doit exiger que l'utilisateur présente des accréditifs d'application qui puissent être vérifiés en utilisant une clé secrète que l'hôte aura mémorisé en toute sécurité. Si ces accréditifs peuvent être vérifiés, l'identité de l'usager peut alors être assurée.

Réception du message KRB_ERROR

   Si le type de message de réponse est KRB_ERROR, le client l'interprète alors comme une erreur et effectue toute tâche spécifique de l'application qui est nécessaire pour récupérer.

Échange d'authentification client/serveur

   L'échange d'authentification client/serveur (CS) est utilisé par les applications réseau pour authentifier le client auprès du serveur et vice versa. Le client doit déjà avoir acquis des accréditifs pour le serveur en utilisant l'échange AS ou TGS.

Message KRB_AP_REQ

   KRB_AP_REQ contient des informations d'authentification qui devraient faire partie du premier message dans une transaction authentifiée. Il contient un ticket, un authentifiant, et quelques informations de comptabilité supplémentaire. Le ticket est insuffisant par lui-même pour authentifier un client, car les tickets passent à travers le réseau. L'authentifiant est utilisé pour empêcher la répétition invalide de tickets en prouvant au serveur que le client connaît la clé de session du ticket et est donc fondé à utiliser le ticket. Le message KRB_AP_REQ est par ailleurs appelé un "en-tête d'authentification".

Génération d'un message KRB_AP_REQ

   Lorsqu'un client souhaite initier l'authentification auprès d'un serveur, il obtient (soit avec un cache d'arréditifs, l'échange d'AS, ou l'échange TGS) un ticket et une clé de session pour le service désiré. Le client peut réutiliser tous les tickets qu'il détient jusqu'à leur expiration. Pour utiliser un ticket, le client construit un nouvel authentifiant à partir de l'heure du système et de son nom, et facultativement à partir d'une somme de contrôle spécifique de l'application, un numéro de séquence initial à utiliser dans les messages KRB_SAFE ou KRB_PRIV, et/ou une sous-clé de session à utiliser dans les négociations pour une clé de session unique pour cette session particulière. Les authentifiants ne doivent pas être réutilisés et devraient être rejetés s'ils sont répétés sur un serveur. Noter que cela peut rendre les applications fondées sur des transports non fiables difficiles à coder correctement. Si le transport peut délivrer des messages dupliqués, un nouvel authentifiant doit être généré pour chaque essai, ou le serveur d'application doit faire correspondre demandes et réponses et répéter la première répétition en réponse à un duplicata détecté.

   Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire de sorte que même après l'échange de nombreux messages il n'y ait aucune probabilité de collision avec un autre numéro de séquence utilisé. Le client peut indiquer une exigence d'authentification mutuelle ou l'utilisation d'un ticket fondé sur une clé de session en mettant le ou les flags appropriés dans le champ ap-options du message. L'authentifiant est chiffré dans la clé de session et combiné avec le ticket pour former le message KRB_AP_REQ, qui est alors envoyé au serveur d'extrémité avec toutes information supplémentaires spécifiques de l'application.

Réception du message KRB_AP_REQ

   L'authentification se fonde sur l'heure courante du serveur, sur l'authentifiant, et sur le ticket. Plusieurs erreurs sont possibles. Si une erreur survient, on attend du serveur qu'il réponde un message KRB_ERROR au client. Ce message peut être encapsulé dans le protocole d'application si sa forme brute n'est pas acceptable pour le protocole.

   L'algorithme de vérification des informations d'authentification est le suivant. Si le type de message n'est pas KRB_AP_REQ, le serveur retourne l'erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé est indiquée par le ticket dans KRB_AP_REQ n'est pas une de celles que le serveur peut utiliser (par exemple, elle indique une vieille clé, et le serveur ne possède plus de copie de la vieille clé), l'erreur KRB_AP_ERR_BADKEYVER est retournée. Si le flag USE-SESSION-KEY est mis dans le champ ap-options, il indique au serveur l'utilisation de l'authentification d'utilisateur à utilisateur. et le chiffrement du ticket avec la clé de session provenant du TGT du serveur plutôt qu'avec la clé secrète du serveur.

   Le champ srealm dans la portion non chiffrée du ticket dans KRB_AP_REQ est utilisé pour spécifier quelle clé secrète devrait utiliser le serveur pour déchiffrer le ticket, parce qu'il est possible au serveur d'être enregistré dans plusieurs domaines, avec des clés différentes dans chacun. Le code d'erreur KRB_AP_ERR_NOKEY est retourné si le serveur n'a pas la clé appropriée pour déchiffrer le ticket.

   Le ticket est déchiffré en utilisant la version de la clé du serveur spécifiée par le ticket. Si la routine de déchiffrement détecte une modification du ticket (chaque système de chiffrement doit fournir des sauvegardes pour détecter le texte chiffré modifié), l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée (il y a de bonnes chances que différentes clés aient été utilisées pour chiffrer et pour déchiffrer).

   L'authentifiant est déchiffré en utilisant la clé de session extraite du ticket déchiffré. Si le déchiffrement montre qu'il a été modifié, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le nom et le domaine du client tirés du ticket sont comparés aux champs correspondants dans l'authentifiant. S'ils ne correspondent pas, l'erreur KRB_AP_ERR_BADMATCH est retournée; ceci est normalement causé par une erreur client ou une tentative d'attaque. Les adresses dans le ticket sont alors examinées à la recherche d'une adresse correspondant à l'adresse mentionnée par le système d'exploitation du client. Si aucune correspondance n'est trouvée, ou si le serveur insiste sur les adresses du ticket mais qu'aucune n'est présente dans le ticket, l'erreur KRB_AP_ERR_BADADDR est retournée. Si l'heure locale du serveur et l'heure du client dans l'authentifiant diffèrent au delà de l'admissible, l'erreur KRB_AP_ERR_SKEW est retournée.

   À moins que le serveur d'application ne fournisse ses propres moyens pour se protéger contre la répétition (par exemple, une séquence challenge-réponse initiée par le serveur après l'authentification, ou l'utilisation d'une sous-clé de chiffrement générée par le serveur), le serveur doit utiliser un cache pour mémoriser tout authentifiant présenté dans la plage de temps admissible. Une analyse soigneuse du protocole et de la mise en œuvre de l'application est recommandée avant d'éliminer ce cache. Le cache mémorise au moins les champ de nom du serveur, de nom du client, et d'heures tirés des authentifiants vus le plus récemment, et si une correspondance est trouvée, l'erreur KRB_AP_ERR_REPEAT est retournée. Noter qu'ici, le rejet est restreint aux authentifiants provenant du même principal vers le même serveur. Les autres principaux de clients qui communiquent avec le même principal du serveur ne devraient pas voir leurs authentifiants rejetés si les champ heure et microseconde se trouvent correspondre à d'autres authentifiants du client.

   Si un serveur perd la trace des authentifiants présentés pendant l'horaire admissible, il doit rejeter toutes les demandes jusqu'à la fin de la plage de temps, lui donnant l'assurance que tout authentifiant perdu ou répété se retrouvera hors plage.

   Note de mise en œuvre: Si un client génère plusieurs demandes au KDC avec le même horodatage, y compris le champ timestamp, toutes les demandes reçues sauf la première seront rejetées comme répétitions. Cela peut arriver, par exemple, si la résolution de l'horloge du client est trop grossière. Les mises en œuvre client devraient s'assurer que les horodatages ne sont pas réutilisés, éventuellement en incrémentant le champ timestamp dans l'horodatage lorsque l'horloge retourne la même heure pour plusieurs demandes.

   Si plusieurs serveur ( par exemple, différents services sur une machine, ou un seul service mis en œuvre sur plusieurs machines ) partagent un principal de service ( pratique non recommandée en général ), ils doivent partager ce cache, ou bien le protocole d'application doit être conçu de façon à en éliminer le besoin. Noter que ceci s'applique à tous les services. Si un protocole d'application n'a pas de protection contre la répétition, un authentifiant utilisé avec un tel service pourrait être répété ultérieurement dans un service différent avec le même principal de service mais sans protection contre la répétition.

   Si un numéro de séquence est fourni dans l'authentifiant, le serveur le sauvegarde pour utilisation ultérieure en traitant les messages KRB_SAFE et/ou KRB_PRIV. Si une sous-clé est présente, le serveur la sauvegarde pour plus tard ou l'utilise pour aider à générer son propre choix d'une sous-clé à retourner dans un message KRB_AP_REP.

   Le serveur calcule l'âge du ticket: heure locale du serveur moins l'heure de début dans le ticket. Si l'heure de début est plus tardive que l'heure en cours de plus que la plage horaire admissible, ou si le flag INVALID est mis, l'erreur KRB_AP_ERR_TKT_NYV est retournée. Autrement, si l'heure en cours est plus tardive que l'heure de fin de plus que la plage admissible, l'erreur KRB_AP_ERR_TKT_EXPIRED est retournée.

   Si toutes ces vérification ont réussi sans erreur, le serveur est assuré que le client possède les accréditifs du principal nommé dans le ticket, et donc, que le client a été authentifié auprès du serveur.

   Réussir ces vérifications ne fournit que l'authentification du principal désigné; cela n'implique pas l'autorisation d'utiliser le service désigné. Les applications doivent gérer l'autorisation sur la base du nom authentifié de l'utilisateur. de l'opération demandée, des informations de commande d'accès locales telles que celles contenues dans un fichier .k5login ou .k5users, et éventuellement d'un service d'autorisation distribué distinct.

Génération d'un message KRB_AP_REP

   Normalement, la demande l'un client va inclure à la fois les informations d'authentification et sa demande initiale dans le même message, et le serveur n'a pas besoin de répondre explicitement au KRB_AP_REQ. Cependant, si l'authentification mutuelle (authentifiant non seulement le client auprès du serveur, mais aussi le serveur auprès du client) est effectuée, le message KRB_AP_REQ aura MUTUAL-REQUIRED établi dans son champ ap-options, et un message KRB_AP_REP est exigé en réponse. Comme avec le message d'erreur, ce message peut être encapsulé dans le protocole d'application si sa forme "brute" n'est pas acceptable pour le protocole d'application. Les champs horodatage et microseconde utilisés dans la réponse doivent être les champs horodatage et microseconde du client (tels que fournis par l'authentifiant). Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire comme décrit ci-dessus pour l'authentifiant. Une sous-clé peut être incluse si le serveur désire négocier une sous-clé différente. Le message KRB_AP_REP est chiffré dans la clé de session extraite du ticket.

Réception du message KRB_AP_REP

   Si un message KRB_AP_REP est retourné, le client utilise la clé de session provenant des accréditifs obtenus pour que le serveur déchiffre le message et vérifie que les champs horodatage et microseconde correspondent à ceux de l'authentifiant qu'il a envoyé au serveur. S'ils correspondent, le client est alors assuré que le serveur est authentique. Le numéro de séquence est la sous-clé ( si présente ) sont conservés pour utilisation ultérieure ( noter que pour chiffrer le message KRB_AP_REP, la sous-clé de session n'est pas utilisée, même si elle est présent dans l'authentification ).

Utilisation de la clé de chiffrement

   Après que l'échange KRB_AP_REQ/KRB_AP_REP est terminé, le client et le serveur partagent une clé de chiffrement qui peut être utilisée par l'application. Dans certains cas, l'utilisation de cette clé de session sera implicite dans le protocole; dans d'autres, la méthode d'utilisation doit être choisie entre plusieurs possibilités. L'application peut choisir la clé de chiffrement réelle à utiliser pour KRB_PRIV, KRB_SAFE, ou d'autres utilisation spécifiques de l'application fondées sur la clé de session à partir du ticket et des sous-clés dans le message KRB_AP_REP et l'authentifiant. Les mises en œuvre du protocole peuvent fournir des routines pour choisir les sous-clés sur la base des clés de session et de nombres aléatoires et générer une clé négociée à retourner dans le message KRB_AP_REP.

   Pour atténuer l'effet des défaillances de la génération de nombres aléatoire chez le client, il est vivement recommandé que toute clé déduite par une application pour utilisation ultérieure incluent la pleine entropie de clé déduite de la clé de session générée par le KDC portée dans le ticket. On laisse les négociations de protocole sur la façon d'utiliser la clé (par exemple, pour choisir un type de chiffrement ou de somme de contrôle) au programmeur de l'application. Le protocole Kerberos n'impose pas de contrainte sur les options de mise en œuvre, mais un exemple de la façon dont cela peut être fait figure ci-après.

   Une façon qu'une application peut choisir pour négocier une clé à utiliser pour la protection ultérieure d'intégrité et de confidentialité est que le client propose une clé dans le champ sous-clé à l'authentifiant. Le serveur peut alors choisir une clé en utilisant la clé proposée par le client en entrée, retournant la nouvelle sous-clé dans le champ sous-clé de la réponse de l'application. Cette clé eut alors être utilisée pour la suite de la communication.

   Avec les échanges d'authentification aussi bien unilatérale que mutuelle, les homologues devraient veiller à ne pas s'envoyer l'un l'autre d'informations sensibles sans garanties appropriées. En particulier, les applications qui exigent la confidentialité ou l'intégrité devraient utiliser la réponse KRB_AP_REP du serveur au client pour que le client et le serveur s'assurent tous deux de l'identité de leur homologue. Si un protocole d'application exige la confidentialité de ses messages, il peut utiliser le message KRB_PRIV. Le message KRB_SAFE peut être utilisé pour s'assurer de l'intégrité.

Échange TGS

   L'échange TGS entre un client et le TGS est initié par un client lorsqu'il cherche à obtenir des accréditifs d'authentification pour un serveur donné (qui peut être enregistré dans un domaine distant), lorsqu'il cherche à renouveler ou valider un ticket existant, ou lorsqu'il cherche à obtenir un ticket mandataire. Dans le premier cas, le client doit déjà avoir acquis un ticket pour le TGS auprès de l'AS ( Le TGT est généralement obtenu quand un client quand un client s'authentifie sur le système ). Le format pour l'échange TGS est presque identique à l'échange AS. La différence principale est que le chiffrement et le déchiffrement dans l'échange TGS n'est pas effectuée dans le clé du client. À la place, le clé de session du TGT ou du ticket renouvelable, ou de la clé de sous-session d'un authentifiant est utilisé. Comme c'est le cas pour tous les serveur d'application, les tickets expirés ne sont pas acceptés par le TGS, donc une fois une TGT ou un renouvelable expiré, le client doit utiliser un échange séparé pour obtenir des tickets valides.

   L'échange TGS consiste de 2 messages: une requête ( KRB_TGS_REQ ), et une réponse ( KRB_TGS_REP ou KRB_ERROR ). Le message KRB_TGS_REQ inclus les informations authentifiant le client plus une requête pour des accréditifs. Les information d'authentification consistent de l'en-tête d'authentification ( KRB_AP REQ ), qui inclus le ticket TGT, renouvelable ou invalide du client précédemment obtenus. Dans les cas de TGT et de proxy, la requête peut inclure un ou plusieurs éléments: une liste d'adresses réseaux, une collection de données d'autorisation typées, ou des tickets supplémentaires. La réponse TGS ( KRB_TGS_REP ) contient es accréditifs demandés, chiffrés dans la clé de session provenant du TGT ou le ticket renouvelable, ou, si elle est présente, dans la sous-clé de session provenant de l'authentifiant. Le message KRB_ERROR n'est pas chiffré. Le message KRB_TGS_REP contient des informations qui peuvent être utilisées pour détecter les répétitions, et pour l'associer au message auquel il répond.

Génération du message KRB_TGS_REQ

   Avant d'envoyer une demande au TGS, le client doit déterminer dans quel domaine il pense qu'est enregistré le serveur d'application. Cela peut se faire de diverses façons. Il peut être connu à l'avance, peut être mémorisé dans un serveur de noms, ou peut être obtenu d'un fichier de configuration. Si le client connaît le nom et le domaine du principal du service et s'il ne possède pas encore un TGT pour le domaine approprié, il doit alors en obtenir un. Il essaye d'abord en demandant un TGT pour le domaine de destination à un serveur Kerberos pour lequel le client possède un TGT ( en utilisant de façon récurrent le message KRB_TGS_REQ ). Le serveur Kerberos peut retourner un TGT pour le domaine désiré, auquel cas le traitement peut se poursuivre. Autrement, le serveur Kerberos peut retourner un TGT pour un domaine qui est plus proche du domaine désiré. Noter que dans ces cas, la mauvaise configuration du serveur Kerberos peut causer les boucles dans le chemin d'authentification résultant. ce que le client devrait veiller à détecter et éviter.

   Si le serveur Kerberos retourne un TGT pour un domaine plus proche que le domaine désiré, le client peut utiliser la configuration de la politique locale pour vérifier que le chemin d'authentification utilisé est acceptable. Autrement, un client peut choisir son propre chemin d'authentification, plutôt que de s'appuyer sur le serveur Kerberos pour en choisir un. Dans les 2 cas, toute information de politique ou de configuration utilisée pour choisir ou valider des chemins d'authentification, par le serveur Kerberos ou par le client, doit être obtenue d'une source de confiance.

   Lorsqu'un client obtient un TGT qui est plus proche du domaine de destination, il peut mettre en cache ce ticket et le réutiliser dans des échange KRB_TGS futures avec les services dans le domaine plus proche. Cependant, si le client devait obtenir un TGT pour le domaine plus proche en commençant au KDC initial plutôt qu'au titre de l'obtention d'un autre ticket, un chemin plus court vers le domaine plus proche pourrait être utilisé. Ce chemin plus court peut être désirable parce que moins de KDC intermédiaires connaîtraient la clé de session du ticket impliqué. Pour cette raison, les clients devraient évaluer s'ils ont confiance dans les domaines de transit pour obtenir le ticket plus proche lorsqu'ils prennent la décision d'utiliser le ticket à l'avenir.

   Une fois que le client a obtenu un TGT pour le domaine approprié, il détermine quels serveur Kerberos servent ce domaine et contacte l'un d'entre eux. Leur liste peut être obtenue par un fichier de configuration ou un service réseau, ou elle peut être générée à partir du nom du domaine. Tant que les clés secrètes échangées par domaine sont gardées secrètes, seul de DOS résulte de l'utilisation d'un faux serveur Kerberos.

   Comme dans l'échange d'AS, le client peut spécifier un certain nombre d'options dans le message KRB_TGS_REQ. Une de ces options est l'options ENC-TKT-IN-SKEY utilisée pour l'authentification d'utilisateur à utilisateur. Lors de la génération du message KRB_TGS_REQ, cette option indique que le client inclut un TGT obtenu du serveur d'application dans le champ de tickets supplémentaires de la demande et que le KDC devrait chiffrer le ticket pour le serveur d'application en utilisant la clé de session provenant de ce ticket supplémentaire, au lieu d'une clé de serveur provenant de la base de données du principal.

   Le client prépare le message KRB_TGS_REQ, qui fournit un en-tête d'authentification comme élément du champ padata, et incluant les même champs qu'utilisés dans le message KRB_AS_REQ avec plusieurs champs facultatifs: le champ enc-authorization-data pour l'usage du serveur d'application et les tickets supplémentaires requis par certaines options.

   Pour préparer l'en-tête d'authentification, le client peut choisir une sous-clé de session avec laquelle sera chiffrée la réponse du serveur Kerberos. Si le client choisit une sous-clé de session, il faut veiller à s'assurer du caractère aléatoire de la sous-clé de session choisie.

   Si la sous-clé de session n'est pas spécifiée, la clé de session provenant du TGT sera utilisée. Si enc-authorization-data est présent, il doit être chiffré dans la sous-clé de session, si elle est présente, à partir de la portion d'authentifiant de l'en-tête d'authentification, ou, si elle n'est pas présente, en utilisant la clé de session provenant du TGT.

   Une fois préparé, le message est envoyé au serveur Kerberos pour le domaine de destination.

Réception du message KRB_TGS_REQ

   Le message KRB_TGS_REQ est traité de manière similaire au message KRB_AS_REQ mais il y a de nombreuses vérification supplémentaires à effectuer. D'abord, le serveur Kerberos doit déterminer pour quel serveur est le ticket d'accompagnement, et il doit choisir la clé appropriée pour le déchiffrer. Pour un message KRB_TGS_REQ normal, ce sera pour le TGS, et la clé du TGS sera utilisée. Si le TGT a été produit par un autre domaine, les clés inter-domaines appropriées doivent être utilisées. Si (a) le ticket d'accompagnement n'est pas un TGT pour le domaine courant, mais est pour un serveur d'application dans le domaine courant, (b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans la demande, et (c) le serveur pour lequel un ticket est demandé est le serveur désigné dans le ticket d'accompagnement, pus le KDC va déchiffrer le ticket dans l'en-tête d'authentification en utilisant la clé du serveur pour lequel elle a été produite. Si aucun ticket ne peut être trouvé dans le champ padata, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est retournée.

   Une fois que le ticket d'accompagnement a été déchiffré, la somme de contrôle fournie par l'utilisateur dans l'authentifiant doit être vérifiée par rapport au contenu de la demande, et le message doit être rejeté si les sommes de contrôle ne correspondent pas ( avec un code d'erreur KRB_AP_ERR_MODIFIED ) ou si la somme de contrôle n'est pas à l'épreuve des collisions ( avec un code d'erreur KRB_AP_ERR_INAPP_CKSUM ). Si le type de somme de contrôle n'est pas accepté, l'erreur KDC_ERR_SUMTYPE_NOSUPP est retournées.

   Si un des déchiffrements indique un échec de vérification d'intégrité, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le KDC doit envoyer un message KRB_TGS_REP valide s'il reçoit un message KRB_TGS_REQ identique à celui qu'il a traité récemment. Cependant, si l'authentifiant est une répétition, mais que le reste de la demande n'est pas identique, de KDC devrait alors retourner KRB_AP_ERR_REPEAT.

Génération du message KRB_TGS_REP

   Le message KRB_TGS_REP partage son format avec KRP_AS_REP, mais avec son champ de typee réglé à KRB_TGS_REP.

   La réponse va comporter un ticket pour le serveur demandé ou pour un serveur d'allocation de ticket d'un KDC intermédiaire à contacter pour obtenir le ticket demandé. La base de données Kerberos est interrogée pour restituer l'enregistrement pour le serveur approprié ( y compris la clé avec laquelle le ticket sera chiffré ). Si la demande est pour un TGT d'un domaine distant, et s'il n'y a pas de partage de clé avec le domaine demandé, le serveur Kerberos va alors choisir le domaine le plus proche du domaine demandé avec lequel il partage une clé et utiliser ce domaine à la place. C'est le seul cas où la réponse pour le KDC sera pour un serveur différent de celui demandé par le client.

   Par défaut, le champ d'adresse, le nom et le domaine du client, la liste des domaines de transit, l'heure de l'authentification initiale, l'heure d'expiration, et les données d'autorisation du ticket nouvellement produit seront copiées du TGT ou du ticket renouvelable. Si les champs de transit ont besoins d'être mis à jour, mais que le type de transit n'est par accepté, l'erreur KDC_ERR_TRTYPE_NOSUPP est retournée.

   Si la demande spécifie une heure de fin, l'heure de fin du nouveau ticket est réglée au minimum de (a) cette demande, (b) de l'heure de fin provenant du TGT, et (c) de l'heure de début du TGT plus le minimum de la durée de vie maximum pour le serveur 'application et la durée de vie maximum pour le domaine local ( la durée de vie maximum pour le principal demandeur a déjà été appliquée lors de la production du ticket ). Si le nouveau ticket doit être un renouvellement, l'heure de fin ci-dessus est alors remplacée par le minimum de (a) la valeur du champ renew_till du ticket et (b) l'heure de début pour le nouveau ticket plus la durée de vie (heure de fin - heure de début ) du vieux ticket.

   Si l'option FORWARDED a été demandée, le ticket résultant contiendra alors les adresses spécifiées par le client. Cette option ne sera honorée que si le flag FORWARDABLE est mis dans le TGT. L'option PROXY est similaire; le ticket résultant contiendra les adresses spécifiées par le client. Elle ne sera honorée que si le flag PROXIABLE est établi dans le TGT. L'option PROXY ne sera pas honorée sur les demandes de TGT supplémentaires.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans la plage horaire admissible pour le KDC et si l'option POSTDATE n'est pas spécifiée, l'heure de début du ticket est réglée à l'heure en cours de l'AS. Si elle indique une heure dans le futur au delà de la plage horaire admissible, mais l'option POSTDATE n'est pas spécifiée ou si le flag MAY-POSTDATE n'est pas mis dans le TGT, l'erreur KDC_ERR_CANNOT_POSTDATE est alors retournée. Sinon, si le TGT a le flag MAY-POSTDATE mis, le ticket résultant sera postdaté, et l'heure de début demandée sera vérifiée par rapport à la politique du domaine local. Si elle est acceptable, l'heure de début du ticket sera réglée comme demandé, et le flag INVALID sera mis. Le ticket postdaté doit être validé avant utilisation en le présentant au KDC après l'heure de début a été atteinte. Cependant, en aucun cas l'heure de début, de fin, ou de fin de renew-till d'un ticket postdaté nouvellement produit ne peut être étendue au delà de l'heure de renew-till du TGT.

   Si l'option ENC-TGT-IN-SKEY a été spécifiée et si un ticket supplémentaire a été inclus dans la demande, il indique que le client utilise l'authentification d'utilisateur à utilisateur pour prouver son identité à un serveur qui n'a pas d'accès à une clé persistante. Lors de la génération du message KRB_TGS_REP, cette option dans le message KRB_TGS_REQ dit au KDC de déchiffrer le ticket supplémentaire en utilisant la clé pour le serveur auquel le ticket supplémentaire a été produit et de vérifier qu'il est un TGT. Si le nom du serveur demandé manque dans la demande, le nom du client dans le ticket supplémentaire sera utilisé. Autrement, le nom du serveur demandé sera comparé au nom du client dans le ticket supplémentaire. Si c'est différent, la demande sera rejetée. Si la demande réussit, la clé de session provenant du ticket supplémentaire sera utilisée pour chiffrer le nouveau ticket produit au lieu d'utiliser la clé du serveur pour lequel le nouveau ticket sera utilisé.

   si (a) le nom du serveur dans le ticket qui est présenté au KDC au titre de l'en-tête d'authentification n'est pas celui du TGS lui-même, (b) le serveur est enregistré dans le domaine de ce KDC, et (c) l'option RENEW est demandé, donc le KDC va vérifier que le flag RENEWABLE est mis dans le ticket, que le flag INVALID n'est pas mis, et que le temp renew-till est dans le future. Si l'option VALIDATE est requis, le KDC va vérifier que le starttime a passé et que le flag INVALID est mis. Si l'option PROXY est demandé, le KDC va vérifier que le flag PROXIABLE est mis dans le ticket. Si le test réussis et que le ticket passe toutes les vérifications décris dans la prochaine section, le KDC va fournir le nouveau ticket approprié.

   La parie ciphertext de la réponse dans le message KRB_TGS_REP est chiffrée dans la clé de sous-session de l'authentifiant, si présent, ou dans la clé de session du TGT. Elle n'est pas chiffré en utilisant la clé secrète du client. De plus, les champs de date d'expiration de la clé du client et de numéro de version de clé sont laissés de côté car ces valeurs sont stockées avec les enregistrements de la base de données du client, et il n'y a pas besoin de cet enregistrement pour satisfaire une demande sur la base d'un TGT.

Recherche de tickets révoqués

   Chaque fois qu'une demande est faite au TGS, le ou les tickets présentés sont confrontés à une liste rouge de tickets annulés. Celle liste peut être mise en œuvre en mémorisant une gamme d'horodatages de production de tickets suspects; si un ticket présenté a un authtime dans cette gamme, il sera rejeté. De cette façon, un TGT volé ou un ticket renouvelable ne peut pas être utilisé pour obtenir des tickets supplémentaires une fois que le vol a été rapporté au KDC pour le domaine dans lequel réside le serveur. Tout ticket normal obtenu avant qu'il ait été rapporté volé sera toujours valide ( parce que les tickets n'exigent pas l'interaction avec le KDC ), mais seulement jusqu'à son heure d'expiration normale. Si les TGT ont été produites pour une authentification inter-domaine, l'utilisation du TGT inter-domaine se sera pas affectée sauf si la liste rouge est transmise aux KDC pour les domaines pour lesquels de tels tickets inter-domaine avaient été produits.

Codage du champ de transit

   Si l'identité du serveur dans le TGT qui est présenté au KDC au titre de l'en-tête d'authentification est celle du service d'allocation de tickets, mais si le TGT a été produit à partir d'un autre domaine, le KDC va chercher la clé inter-domaines partagée avec ce domaine et utiliser cette clé pour déchiffrer le ticket. Se le ticket est valide, le KDC va alors honorer la demande, sous réserve des contraintes soulignées ci-dessus au paragraphe qui décrit l'échange d'AS. La partie domaine de l'identité du client sera tirée du TGT. Le nom de domaine qu'a produit le TGT, si ce n'est par le domaine du principal client, sera ajouté au champ de transit du ticket à produire. Ceci est accomplis en lisant le champ de transit d'après de TGT ( qui est traité comme un ensemble non ordonné de noms de domaines ), en ajoutant le nouveau domaine à l'ensemble, et en construisant et écrivant sa forme ( abrégée ) codée (ce qui peut impliquer un réarrangement du codage existant ).

   Noter que le service d'allocation de tickets n'ajoute pas le nom de son propre domaine. Au lieu de cela, sa responsabilité est d'ajouter le nom du domaine précédent. Cela empêche un serveur Kerberos malveillant d'inscrire intentionnellement son propre nom ( il pourrais cependant omettre les noms d'autres domaines ).

   Ni les noms du domaine local ni ceux du domaine du principal ne sont à inclure dans le champ de transit. Ils apparaissent ailleurs dans le ticket et tous deux sont connus pour prendre part à l'authentification du principal. Parce que les points d'extrémité ne sont pas inclus, aussi bien l'authentification inter-domaine local que celle à un seul bond résulte en un champ de transit qui est vide.

   Comme à ce champ est ajouté le nom de chaque domaine de transit, il peut éventuellement être très long. Pour diminuer la longueur de ce champ, son contenu est codé. Les codages initialement acceptés sont optimisés sur le cas normal de communication inter-domaine: un arrangement hiérarchique de domaines utilisant les noms de domaine de style domaine ou X.500. Ce codage ( appelé DOMAIN-X500-COMPRESS ) est décris ci-dessous.

   Les noms de domaine dans le champ de transit sont séparés par une ",", les caractères ",", "\", les "." de fin, et les espaces d'en-tête sont des caractères spéciaux, et s'ils font partie d'un nom de domaine, ils doivent être entre guillemets dans le champ de transit en les faisant précéder d'un "\"

   Un nom de domaine se terminant par un "." est interprété comme étant ajouté au domaine précédent. Par exemple, ou peut coder la traversée de EDU, MIT.EDU, ATHENA.MIT.EDU, , WASHINGTON.EDU, et CS.WASHINGTON.EDU par:

  "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS."

  Noter que si ATHENA.MIT.EDU, ou CS.WASHINGTON.EDU étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ, et on aurait:

  "EDU,MIT.,WASHINGTON.EDU"

   Un nom de domaine commençant par un "/" est interprété comme ayant été ajouté au domaine précédent. Pour les besoins de l'ajout, le domaine précédant le premier domaine de la liste est considéré comme le domaine nul (""). Si un nom de domaine commençant par un "/" doit être autonome, il devrait alors être précédé d'un espace (" "). Par exemple, on pour coder la traversée de /COM/HP/APOLLO,/COM/HP,/COM, et /COM/DEC par:

  "/COM,/HP,/APOLLO, /COM/DEC"

  Comme dans l'exemple ci-dessus, si /COM/HP/APOLLO et /COM/DEC étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ:

  "/COM,/HP"

   Un sous-champ nul précédant ou suivant une "," indique que tous les domaines entre le domaine précédent et le prochain domaine ont été traversés. Pour les besoins de l'interprétation des sous-champs nuls, le domaine du client est considéré comme précédant ceux du champ de transit, et le domaine du serveur est considéré les suivre. Et donc, "," signifie que tous les domaines le long du chemin entre le client et le serveur ont été traversées. ",EDU, /COM," signifie que tous les domaines depuis le domaine du client jusqu'à EDU ( dans une hiérarchie de type domaine ) ont été traversés, et que tous depuis /COM jusqu'au domaine du serveur dans un style X.500 ont aussi été traversés. Cela pourrait survenir si le domaine EDU dans une hiérarchie partage une clé inter-domaine directement avec le domaine /COM dans une autre hiérarchie.

Réception du message KRB_TGS_REP

   Lorsque le message KRB_TGS_REP est reçu par le client, il est traité de la même manière que le traitement KRB_AS_REP décrit ci-dessus. La principale différence est que la partie chiffrée de la réponse doit être déchiffrée en utilisant la sous-clé de session provenant de l'authentifiant, s'il a été spécifié dans la demande, ou la clé de session provenant du TGT, plutôt que la clé secrète du client. Le nom du serveur retourné dans la réponse est le vrai nom du principal du service.

L'échange KRB_SAFE

   Le message KRB_SAFE peut être utilisé par des clients qui exigent la capacité à détecter les modifications des messages qu'ils échangent. Ceci est réalisé en incluant une somme de contrôle à l'épreuve des collisions des données utilisateur et de quelques informations de contrôle. La somme de contrôle est assortie avec une clé de chiffrement ( normalement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue.

Génération d'un message KRB_SAFE

   Lorsqu'une application souhaite envoyer un message KRB_SAFE, elle collecte ses données et les informations de contrôle appropriées et calcule une somme de contrôle sur l'ensemble. L'algorithme de somme de contrôle devrait être la somme de contrôle assortie mandatée pour être mise en œuvre ainsi que le système de chiffrement utilisé pour la clé de session ou de sous-session. La somme de contrôle est générée en utilisant la sous-clé de session, si elle est présente, ou la clé de session. Certaines mise en œuvre utilisent un algorithme de somme de contrôle différent pour les messages KRB_SAFE mais il n'est pas toujours possible de faire ainsi de façon interopérable.

   Les informations de contrôle pour le missage KDB_SAFE comportent à la fois un horodatage et un numéro de séquence. Le concepteur d'une application utilisant le message KRB_SAFE doit choisir au moins un des 2 mécanismes. Ce choix devrait se fonder sur les besoins du protocole d'application.

   Les numéros de séquence sont utiles lorsque tous les messages envoyés sont reçus par l'homologue. L'état de connexion est actuellement exigé pour l'entretien de la clé de session, aussi la maintenance du prochain numéro de séquence ne devrait pas présenter de problème supplémentaire.

   Si le protocole d'application est prévu pour tolérer des pertes de messages sans qu'ils soient renvoyés, l'utilisation de l'horodatage est le mécanisme de détection de répétition approprié. L'utilisation des horodatages est aussi le mécanisme approprié pour les protocoles de diffusion groupée dans lesquels tous les homologues partagent une sous-clé de session commune, mais certains messages seront envoyés à un sous-ensemble d'un homologue.

   Après le calcul de la somme de contrôle, le client transmet les informations et la somme de contrôle au receveur.

Réception du message KRB_SAFE

   Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est retourné.

   On vérifie d'abord que les champs version et type du protocole du message correspondent respectivement à la version en cours et à KRB_SAFE. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application vérifie que la somme de contrôle utilisée est une somme de contrôle à l'épreuve des collisions qui utilise des clés compatibles avec la clé de session ou clé de sous-session selon le cas approprié ( ou la clé d'application déduite des clés de session ou de sous-session ). Si ce n'est pas le cas, une erreur KRB_AP_ERR_INAPP_CKSUM est générée. D'adresse de l'expéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et ( si une adresse de réception est spécifiée ou si le receveur exige une adresse ) qu'une des adresses du receveur apparaît comme adresse de réception dans le message. Pour travailler avec la traduction d'adresse réseau, les expéditeurs peuvent utiliser le type d'adresse directionnel pour l'adresse d'expéditeur et ne pas inclure d'adresse de receveur. Un échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Puis les champs timestamp et usec et/ou de numéro de séquence sont vérifiés. Si timestamp et usec sont attendus et absents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Il n'est pas exigé que les timestamp soient strictement ordonnées; il est seulement exigé qu'ils soient dans la plage permise. Si les champs nom du serveur, ainsi que nom du client, heure, et microsecondes de l'authentifiant correspondent à de tels tuples récemment vus (envoyés ou reçus), l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp ni usec ni un numéro de séquence ne sont présents, une erreur KRB_AP_ERR_MODIFIED est générée. Finalement, la somme de contrôle est calculée sur les informations de données te de contrôle, et si elle ne correspond pas à la somme d contrôle reçue, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérification réussissent, l'application est sûr que le message a été généré par son homologue et n'a pas été modifié dans le transit.

   Les mises en œuvre devraient accepter tout algorithme de checksum qui a à la fois la sécurité adéquate et des clés compatibles avec la clé de session ou de sous-session. Les chechsums non keyed ou qui ne sont pas à l'épreuve des collisions ne conviennent pas pour cette utilisation.

L'échange KRB_PRIV

   Le message KRB_PRIV peut être utilisé par les clients qui exigent la confidentialité et la capacité à détecter les modifications des messages échangés. Il réalise cela en chiffrant les messages et en ajoutant des informations de contrôle.

Génération du message KRB_PRIV

   Lorsqu'une application souhaite envoyer un message KRB_PRIV, elle collecte ses données et les informations de contrôle appropriées et les chiffre avec une clé de chiffrement ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue ). Au titre des informations de contrôle, le client doit choisir d'utiliser soit un timestamp soit un numéro de séquence (ou les 2). Après le chiffrement des données d'utilisateur et des informations de contrôle, le client transmet le texte chiffré et certaines des informations "d'enveloppe" au receveur.

Réception du message KRB_PRIV

   Lorsqu'une application reçoit un messagse KRB_PRIV, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est rapporté.

   Il est d'abord vérifié que les champs de version et type du protocole du message correspondent respectivement à la version en cours et au KRB_PRIV. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre ensuite le texte chiffré et traite le texte clair qui en résulte. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   L'adresse de l'éxpéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message. Si une adresse de receveur est spécifiée ou si le receveur exige une adresse, une des adresse du receveur doit également apparaître comme adresse de receveur dans le message. Lorsqu'une adresse d'expéditeur ou de receveur peut ne par correspondre à l'adresse du message à cause d'une traduction d'adresse réseau, une application peut être écrite pour utiliser les adresses du type d'adresse directionnel à la place de l'adresse réseau réelle.

   Après cela intervient la vérification des champs timestamp et usec et/ou de numéro de séquence. Si le timestamp et usec sont attendus et ne sont pas présents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Si les champs de nom du serveurs, ainsi que le nom du client, l'heure, et microseconde provenant de l'authentifiant correspondent à tout tuple de ces valeurs vu récemment, l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp, ni usec ni un numéro de séquence n'est présent, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérifications réussissent, l'application peut supposer que le message a été généré par son homologue et a été transmis en toute sécurité.

L'échange KRB_CRED

   Le message KRB_CRED peut être utilisé par les clients qui exigent la capacité à envoyer des accréditifs Kerberos d'un hôte à l'autre. Ceci est réalisé par l'envoi des tickets avec les données chiffrées qui contiennent les clés de session et les autres informations associées à ces tickets.

Génération d'un message KRB_CRED

   Lorsqu'une application souhaite envoyer un message KRB_CRED, elle obtient d'abord ( en utilisant l'échange KRB_TGS ) des accréditifs à envoyer à l'hôte distant. Elle construit ensuite un message KRB_CRED en utilisant le ou les tickets ainsi obtenus, plaçant la clé de session qu'il est nécessaire d'utiliser pour chaque ticket dans le champ clé de la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRED.

   Les autres information associées à chaque ticket et obtenues durant l'échange KRB_TGS sont aussi placées dans la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRÉD. L'heure courante et, s'ils sont spécifiquement exigés par l'application, les champs nonce, s-address, et r-address sont placés dans la partie chiffrée du message KRB_CRED, qui est alors chiffré avec la clé de chiffrement précédemment échangée dans le KRB_AP ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est intervenue ).

   Note de mise en œuvre: lors de la construction d'un message KRB_CRED pour l'inclure dans un jeton de contexte initial GSS-API, la mise en œuvre MIT de Kerberos ne chiffrera pas le message KRB_CRED si la clé de session est DES ou triple DES. Pour l'intéropérabilité avec MIT, la mise en œuvre Microsoft ne chiffrera pas le KRB_CRED dans un jeton GSS-API si elle utilise une clé de session DES. MIT Kerberos peut recevoir et décoder des jetons KRB_CRED chiffrés ou non dans l'échange GSS-API. La mise en œuvre Heimdal de Kerberos peut aussi accepter des messages KRB_CRED chiffrés ou non. Comme le message KRB_CRED dans un jeton GSS-API est chiffré dans l'authentifiant, le comportement du MIT ne présente pas de problème de sécurité, bien qu'il soit en violation de la spécification Kerberos.

Réception d'un message KRB_CRED

   Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si une erreur survient, un code d'erreur est rapporté pour être utilisé par l'application Le message est vérifié en s'assurant que les champs de version et type de protocole correspondent respectivement à la version en cours et à KRB_CRED. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre alors le texte chiffré et traite le texte clair résultant. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   Si elle est présente ou exigé, le receveur peut vérifier que le rapport du système d'exploitation sur l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et qu'une des adresse de réception apparaît comme adresse de réception dans le message. La vérification d'adresse ne fournit aucune sécurité supplémentaire, car l'adresse, si elle est présente, a déjà été vérifiée dans le message KRB_AP_REQ et il n'y a aucun intérêt pour un agresseur à retourner un message KRB_CRED à celui qui l'a généré. Et donc, le receveur peut ignorer l'adresse même si elle est présente afin de mieux travailler dans des environnement de traducteur d'adresses réseau (NAT). L'échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Les receveurs peuvent sauter la vérification d'adresse, car le message KRB_CRED ne peut généralement pas être reflété à celui qui l'a généré. Les champs timestamp et usec ( et nonce, s'il est exigé) sont vérifiés ensuite. Si timestamp et usec ne sont pas présents, ou s'ils sont présents mais ne sont pas celui en cours, l'erreur KRB_AP_ERR_SKEW est générée.

   Si toutes les vérifications ont réussi, l'application mémorise chacun des nouveaux tickets dans sa mémoire cache d'accréditifs avec la clé de session et les autres informations dans la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.

Échanges d'authentification user to user

   L'authentification d'utilisateur à utilisateur fournit une méthode pour effectuer l'authentification lorsque le vérificateur n'a pas accès à un service de clé à long terme. Ce peut être le cas lorsqu'on utilise un serveur (par ex: un serveur Windows) comme utilisateur sur une workstation. Dans un tel cas, le serveur peut avoir accès au TGT obtenu lorsque l'utilisateur se connecte sur la workstation, mais comme le serveur fonctionne comme un utilisateur non privilégié, il peut ne pas avoir accès aux clés du système. Des situations similaires peuvent survenir en faisant fonctionnes des applications paire-à-paire.

   Pour traiter ce problème, le protocole Kerberos permet au client de demander que le ticket produit par le KDC soit chiffré en utilisant une clé de session provenant d'un TGT produit par la partie qui va vérifier l'authentification. Ce TGT doit être obtenu du vérificateur au moyen d'un échange extérieur au protocole Kerberos, habituellement au titre du protocole d'application. Noter que parce que le TGT est chiffré avec la clé secrète du KDC, il ne peut pas être utilisé pour l'authentification sans la possession de la clé secrète correspondante. De plus, parce que le vérificateur ne révèle pas la clé secrète correspondante, fournir le TGT du vérificateur ne permet pas de se faire passe pour le vérificateur.

   Le premier message est une négociation spécifique de l'application entre le client et le serveur, à la fin de laquelle tous deux ont déterminé qu'ils vont utiliser l'authentification d'utilisateur à utilisateur, et le client a obtenu le TGT du serveur.

   Ensuite, le client inclut le TGT du serveur comme ticket supplémentaire dans sa demande KRB_TGS_REQ au KDC et spécifie l'option ENC-TKT-IN-SKEY dans sa demande.

   S'il est validé, le ticket d'application retourné au client va être chiffré en utilisant la cé de session provenant du ticket supplémentaire et le client va le noter lorsqu'il utilise ou mémorise le ticket d'application.

   Lorsqu'il contacte le serveur en utilisant un ticket obtenu pour l'authentification l'utilisateur à utilisateur, le client doit spécifier le flag USE-SESSION-KEY dans le champ ap-options. Cela dit au serveur d'application d'utiliser la clé de session associée à son TGT pour déchiffrer le ticket de serveur fourni dans la demande d'application.

Spécifications de chiffrement et de checksum

   Les protocoles Kerberos décrits dans le présent document sont conçus pour le chiffrement de messages de tailles arbitraires, en utilisant le chiffrement de flux ou de blocs. Le chiffrement est utilisé pour prouver les identités des entités du réseau qui participent à l'échange de messages. Le KDC pour chaque domaine est de confiance pour tous les principaux enregistrés dans ce domaine pour mémoriser une clé secrète. La preuve de la connaissance de cette clé secrète est utilisée pour vérifier l'authenticité d'un principal.

   Le KDC utilise la clé secrète du principal ( dans l'échange d'AS ) ou une clé de session partagée ( dans l'échange de TGS ) pour chiffrer les réponses aux demandes de ticket; la capacité à obtenir la clé secrète ou la clé de session implique la connaissance des clés appropriées et l'identité du KDC. La capacité d'un principal à déchiffrer la réponse du KDC et à présenter un ticket et un authentifiant correctement formé ( généré avec la clé de session provenant de la réponse du KDC ) à un service vérifie l'identité du principal; de même, la capacité du service à extraire la clé de session du ticket et à prouver ainsi sa connaissance du secret dans une réponse vérifie d'identité du service.


   L'opération string-to-key fournie par la rfc3961 est utilisée pour produire une clé à long terme pour un principal ( généralement pour un utilisateur ). La chaîne salt par défaut, si fournis via les données de pré-authentification, est l'enchaînement des composants de domaine et de nom du principal, dans l'ordre, et sans séparateur. Sauf indication contraire, on utilise l'ensemble des paramètres opaque de string-to-key par défaut comme définis dans la rfc3961.

   Les données chiffrées, et les checksums sont transmis en utilisant les objets de données EncryptedData, EncryptionKey, et Checksum. Les opérations de chiffrement, déchiffrement, et de checksums décrites dans le présent document utilisent les opérations correspondantes de chiffrement, déchiffrement, et get_mic décrites dans la rfc3961, avec la génération implicite de clé spécifique utilisant les valeurs de KeyUsage spécifiées dans la description de chaque objet EncryptedDate ou Checksum pour faire varier la clé pour chaque opération. Noter que dans certains cas, la valeur à utiliser dépend de la méthode de choix de la clé ou du contexte du message.

   Les utilisations de clé sont des entiers non signés 32-bits, le 0 n'est pas permis. Les valeurs d'utilisation de clé de 512 à 1023 sont réservés pour des utilisation internes à une mise en œuvre de Kerberos. ( par exemple, alimenter un générateur de nombre pseudo-aléatoire avec une valeur produite en chiffrant quelque chose avec une clé de session et une valeur d'utilisation de clé non utilisée pour un autre objet. ) Les valeurs d'utilisation de clé de 1024 à 2047 sont réservés à l'usage des applications; les applications devraient utiliser des valeurs paires pour le chiffrement et des valeurs impaires pour les checksums dans cette gamme.

   Il peut exister d'autres documents qui définissent les protocoles dans les termes des types de chiffrement ou de checksums de la rfc1510. Ces documents ne connaissent rien sur les utilisations de clé. Afin que ces spécifications continuent d'avoir un sens en attendant leur mise à jour, si aucune valeur d'utilisation de clé n'est spécifié, les utilisation de clé 1024 et 1025 doivent être utilisés pour déduire les clés pour le chiffrement et les checksums, respectivement. ( ceci ne s'applique pas aux protocoles qui ont leur propre chiffrement indépendemment du présent cadre, en utilisant directement la clé qui résulte de l'échange d'authentification de Kerberos. ) De nouveaux protocoles définis en termes de types de chiffrement et de checksum Kerberos devraient utiliser leurs propres valeurs d'utilisation de clé.

   Sauf indication contraire, aucun chaînage d'état de chiffrement n'est fait d'une opération de chiffrement à un autre.

   Note de mise en œuvre: Bien que ce ne soit pas recommandé, certains protocoles d'application vont continuer d'utiliser directement les données de clé, même si c'est seulement dans les spécifications de protocole qui existent actuellement. Une mise en œuvre destinée à prendre en charge les applications Kerberos générales peuvent donc avoir besoin de rendre disponibles les données de clé, ainsi que les attributs et opérations décrits dans la rfc3961. Une des raisons les plus courantes pour effectuer directement le chiffrement est le contrôle direct sur la négociation et le choix d'un algorithme de chiffrement suffisamment fort ( dans le contexte d'une application de données ). Bien que Kerberos ne fournisse pas directement de facilité de négociation des types de chiffrement entre le client et le serveur d'application, il y a des approches qui utilisent Kerberos pour faciliter cette négociation. Par exemple, un client peut ne demander que des types de clé de session suffisamment fort au KDC et espérer que tout type retourné par le KDC sera compris et pris en charge par le serveur d'application.

Spécifications de message

   Le protocole Kerberos est défini ici en termes de notation ASN.1, qui fournit une syntaxe de spécification à la fois de la disposition abstraite des messages du protocole et de leurs codages. Les mises en œuvre qui n'utilisent pas un compilateur ASN.1 existant ou une bibliothèque de soutien devraient avoir une bonne compréhension de la spécification ASN.1 réelle afin de s'assurer d'un comportement correcte de la mise en œuvre.

   Noter qu'en plusieurs endroits, ds changements des types abstraits ont été faits par rapport à la rfc1510. Ceci en partie pour répondre à des hypothèses largement répandues faites par diverses mises en œuvre, qui résultent dans certains cas de violations non intentionnelles de la norme ASN.1. Elles sont clairement mentionnées lorsqu'elles surviennent. Les différences entre les types abstraits de la rfc1510 et les types abstraits dans le présent document peuvent causer l'émission de codages incompatibles quand on utilise certaines règles de codage, par exemple, les règles de codage compact ( PER, Packed Encoding Rules ). Cette incompatibilité théorique ne devrait pas être pertinente pour Kerberos, car Kerberos spécifie explicitement l'utilisation des règles de codage en méta-langage distinctif (DER, Distinguished Encoding Rules). Ce peu être un problème pour les protocoles qui cherchent à utiliser les types de Kerberos avec d'autres règles de codage. ( Cette pratique n'est pas recommandée ) À très peu d'exceptions près ( en particulier d'utilisation du BIT STRING ), les codages résultant de l'utilisation de DER restent identiques entre les types définis dans la rfc1510 et les types définis dans le présent document.

Les définitions de type de la présente section supposent une définition de module ASN.1 de la forme suivante:
KerberosV5Spec2 {
    iso(1) identified-organisation(3) dod(6) internet(1)
    security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
    -- reste de la définition ici
END

   Ceci spécifie que le contexte d'étiquetage du module devra être explicite et non automatique. Noter que dans certaines autres publications ( comme la rfc1510 et la rfc1964 ), la portion "dod" de d'identifiant d'objet est spécifiée par erreur comme ayant la valeur de "5". Dans le cas de la rfc1964, l'utilisation de la valeur d'OID correcte résulterait en un changement du protocole du câble; elle reste donc inchangée pour l'instant.

   Noter qu'ailleurs dans le document, la nomenclature de divers types de message est incohérente, mais elle suit largement les conventions du langage C, y compris l'utilisation du caractère souligné (_) et de l'écriture en majuscules de noms destinés à être des constantes numériques. Aussi, à certains endroits, les identifiants ( particulièrement ceux qui se réfèrent à des constantes ) sont écrits en majuscules afin de les distinguer du texte explicatif environnant.

   La notation ASN.1 ne permet pas de souligner dans les identifiants, aussi dans les définitions ASN.1 réelles, les soulignés sont remplacés par le traits d'union (-). De plus, les noms de membre de la structure et les valeur définies en ASN.1 doivent commencer par une lettre minuscule, alors que les noms du types doivent commencer par une majuscule.

Notes de compatibilité ASN.1

   Pour les besoins de la compatibilité, les mises en œuvre devraient tenir compte des notes spécifiques suivantes concernant l'utilisation de l'ASN.1 dans Kerberos. Ces notes ne décrivent pas les variantes standard de l'ASN.1. L'objet de ces notes est plutôt de décrire quelques bizarreries historiques et non la conformité de diverses mises en œuvre, ainsi que des ambiguïtés historiques, qui, bien qu'elles soient de l'ASN.1 valide, peuvent amener une certaine confusion dans la mise en œuvre.

Règles de codage distinct ASN.1

   Les codage des messages du protocole Kerberos doit obéir aux règles de codage en DER de l'ASN.1 telles que décrites dans X690. Certaines mises en œuvre ( qui sont principalement celles dérivées de DCE 1.1 et antérieures ) sont connues pour utiliser les règles de codage de base ( BER ) les plus générales; en particulier, cet mises en œuvre envoient des codages de longueur indéfinie. Les mises en œuvre peuvent accepter de tels codages dans l'intérêt de la rétro compatibles, bien qu'on doive prévenir les mises en œuvre que le décodage du BER le plus général est plein de périls.

Champs d'entier facultatifs

   Certaines mises en œuvre de distinguent par en interne entre une valeur d'entier facultative omise et une valeur transmise de zéro. Les endroits du protocole où ceci est pertinent sont divers champs de micro-secondes, de noms occasionnels, et de numéro de séquence. Les mises en œuvre devraient traiter les valeurs d'entier facultatives omises comme ayant été transmises avec une valeur de zéro, si c'est ce qu'attend l'application.

Types SEQUENCE OF vides

   Il y a des endroits du protocole où un message contient un type de SEQUENCE OF qui est un membre facultatif. Il peut en résulter un codage contenant une SEQUENCE OF vide. Le protocole Kerberos ne fait pas de distinction sémantique entre un type de SEQUENCE OF facultatif absent et un type de SEQUENCE OF facultatif présent mais vide. Les mises en œuvre ne devraient pas envoyer de codages de SEQUENCE OF vides marqués OPTIONAL, mais devraient les accepter comme équivalents à un type OPTIONAL vide. Dans la syntaxe ASN.1 qui décrit les messages Kerberos, les instances de ces types de SEQUENCE OF facultatifs problématiques sont indiquées avec un commentaire.

Tag Numbers non reconnus

   De futures révisions du présent protocole pourraient comporter de nouveaux types de message avec des numéros d'étiquette de classe APPLICATION différents. De telles révisions devraient protéger les mises en œuvre plus anciennes en envoyant seulement les types de messages que les parties comprennent; par exemple, au moyen d'un flag mis par le receveur dans une demande précédente. Dans l'intérêt de la robustesse du traitement d'erreurs, les mises en œuvre devraient accepter de traiter de toutes façons un message reçu avec une étiquette non reconnue, et retourner le cas échéant un message d'erreur.

   En particulier, les KDC devraient retourner KRB_AP_ERR_MSG_TYPE si le tag incorrecte est envoyé sur TCP. Les KDC ne devraient pas répondre aux messages reçus avec un tag inconnus sur UDP afin d'éviter les attaques DOS. Pour les applications non KDC, la mise en œuvre de Kerberos indique normalement une erreur à l'application qui prend les mesures appropriées sur la base du protocole d'application.

Tag Number supérieurs à 30

   Une mise en œuvre simple de décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros d'étiquette ASN.1 supérieures à 30, du fait que de tels numéros sont codés en utilisant plus d'un octet. Les révisions futures du présent protocole pourraient utiliser les numéros supérieurs à 30, et les mises en œuvre devraient être préparées à retourner une erreur, le cas échéant, lorsqu'elles ne reconnaissent pas l'étiquette.

Types Kerberos de base

   Ce paragraphe définit un certain nombre de types de base qui sont éventuellement utilisés dans plusieurs messages du protocole Kerberos

KerberosString

   La spécification d'origine du protocole Kerberos dans la rfc1510 utilise GeneralString à de nombreux endroits pour les données de chaîne human-readable. Les mise en œuvre historiques de Kerberos ne peuvent pas utiliser toute la puissance de GeneralString. Ce type ASN.1 exige l'utilisation de séquences d'échappement de désignation et d'invocation comme spécifié dans la norme ISO-2022/ECMA-35 pour commuter les ensembles de caractères, et l'ensemble de caractères par défaut qui est conçus désigné sous le nom de G0 est la version de référence internationale ( IRV ) - US ASCII de ISO-646/ECMA-6.

   La nomes ISO-2022/ECMA-35 définit 4 éléments de code d'ensemble de caractèrse (G0 à G3) et 2 éléments de code de fonction de contrôle (C0 à C1). DER interdit la désignation des ensembles de caractères autres que les ensembles G0 et C0. Malheureusement, cela semble avoir l'effet collatéral d'interdire l'utilisation de l'ensemble de caractères ISO Latin (ISO-8859) ou de tout autre ensemble de caractères qui utilise un jeu de 96 caractères, comme ISO-2022/ECMA-35 interdit de les désigner comme l'élément de code G0.

   En pratique, de nombreuses mises en œuvre traitent GeneralStrings comme chaînes 8 bits par défaut quel que soit le jeu de caractères, sans considération de l'utilisation correcte des séquences d'échappement. Le jeu de caractères par défaut est souvent déterminé par la localisation du systèmes d'exploitation de l'utilisateur habituel. Au moins une mise en œuvre majeure place des caractères Unicode codés en UTF-8 dans GeneralString. Cette incapacité à s'en tenir aux spécifications de GeneralString a pour conséquence des problèmes d'interopérabilité lorsque des codages de caractères incompatibles sont utilisés par des client, services et KDC Kerberos.

   Cette situation malheureuse est le résultat d'une documentation défectueuse des restrictions du type ASN.1 de GeneralString dans les spécifications Kerberos précédentes. Le nouveau (post-RFC 1510) type KerberosString, défini ci-dessous est une GeneralString qui a pour contrainte de ne contenir que des caractères en IA5String.

  KerberosString := GeneralString (IA5String)

   En général, les caractères de contrôle US-ASCII ne devraient pas être utilisés dans KerberosString. Les caractères de contrôle ne devraient pas être utilisés dans des noms de principal ou des noms de domaine

   Pour la compatibilité, les implémentations peuvent choisir d'accepter les valeurs de GeneralString qui contiennent des caractères autres que ceux permis par IA5String, mais elles devraient être conscientes que les codes de désignation de jeu de caractères seront vraisemblablement absents, et que le codage devrait probablement presque de toutes façons être traité comme spécifique de la localisation. Les implémentations peuvent aussi choisir d'émettre des valeurs de GeneralString qui sont au-delà ce celles permises par IA5String, mais elles devraient être conscientes que faire cela est extraordinairement risqué du point de vue de l'interopérabilité.

   Certaines mises en œuvre existantes utilisent GeneralString pour coder des caractères spécifiques de la localisation sans échappement. C'est une violation de la norme ASN.1. La plupart de ces mises en œuvre codent l'US-ASCII dans la moitié gauche, aussi tant que la mise en œuvre ne transmet que de l'US-ASCII, la norme ASN.1 n'est pas violée à cet égard. Lorsque ces mises en œuvre codent les caractères sans échappement spécifiques de la localisation avec le bit de plus fort poids établi, cela viole la norme ASN.1

   D'autres mises en œuvre sont connues pour utiliser GeneralString avec un codage UTF-8. Cela aussi est une violation de la norme ASN.1, car UTF-8 est un codage différent, et pas un jeu "G" à 94 ou 96 caractères tel que défini par la norme ISO 2022. On pense que ces mises en œuvre n'utilisent même pas la séquence d'échappement de ISO 2022 pour changer le codage des caractères. Même si les mises en œuvre devaient annoncer le changement de codage en utilisant la séquence d'échappement, la norme ASN.1 interdit l'utilisation de toute séquence d'échappement autre que celles utilisées pour désigner/invoquer les ensembles "G" ou "C" permis par GeneralString.

   De futures révisions de ce protocole permettront presque certainement une représentation plus interopérable des noms de principaux, probablement en y incluant UTF8String. Noter qu'appliquer une nouvelle contrainte à un type qui n'en avait pas auparavant constitue la création d'un nouveau type ASN.1. Dans ce cas particulier, le changement n'aboutit pas à un changement de codage en DER.

Domaine et PrincipalName


Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
    name-type [0] Int32,
    name-string [1] SEQUENCE OF KerberosString
}

   Les noms de domaine Kerberos sont codés comme KerberosStrings. Les domaines se doivent pas contenir de caractère avec le code 0 (US-ASCII NULL). La plupart des domaines vont normalement comporter plusieurs composants séparés par des points, dans le style des noms de domaine Internet, ou séparés par des "/", dans le style des noms X.500. Un PrincipalName est une séquences typée de composants comportant les sous champs suivants:

name-type Ce champ spécifie le type de nom qui suit. Ce champ devrait être traité comme conseil.
name-string Ce champ code une séquence de composants qui forment un nom, chaque composant étant codé comme un KerberosString. Pris ensemble, un PrincipalName et un domaine forment un identifiant de principal.

KerberosTime


KerberosTime ::= GeneralizedTime – sans fraction de seconde

   Les horodatages utilisés dans Kerberos sont codés comme GeneralizedTime. Une valeur KerberosTime ne doit pas inclure de portions fractionnée de seconde. Comme exigé par les DER, elle ne doit pas non plus inclure de séparateur, et elle doit spécifier la zone de temps UTC (Z). Exemple: le seul format valide pour l'heure UTC 6 minutes, 27 secondes aprés 21h le 6 novembre 1985 est 19851106210627Z.

Contraintes sur les types entiers

   Certains membres de type entier devraient être contraints à des valeur représentables en 32-bits, pour la compatibilité avec des limites raisonnables d'implémentation.


Int32 ::= INTEGER (-2147483648..2147483647)
    -- valeurs signées représentables en 32 bits
UInt32 ::= INTEGER (0..4294967295)
    -- valeurs de 32 bits non signées
Microseconds ::= INTEGER (0..999999)
    -- microsecondes

   Bien qu'il en résulte des changements des types abstraits de la version de la rfc1510, le codage DER ne devrait pas être altéré. Les anciennes implémentations étaient normalement limitées à des valeurs d'entier 32-bits, et les numéros alloués devraient entrer dans l'espace des valeurs entières représentables en 32-bits afin de promouvoir l'intéropérabilité. Plusieurs champs d'entiers dans les messages sont contraints à des valeurs fixes.

pvno comme TGT-VNO ou AUTHENTICATOR-VNO, ce champ récurant vaut toujours 5.
msg-type Ce champ est habituellement identique au tagNumber d'application du type de message qui le contient

HostAddress et HostAddresses


HostAddress ::= SEQUENCE {
    addr-type [0] Int32,
    address [1] OCTET STRING
}

   Note:HostAddress est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide. Le codage d'adresse d'hôte comporte 2 champs:

addr-type Ce champ spécifie le type d'adresse suivant.
address Code une seule adresse du type addr-type.

AuthorizationData

AuthorizationData est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide.
AuthorizationData
::= SEQUENCE OF SEQUENCE {
    ad-type [0] Int32,
    ad-data [1] OCTET STRING
}

ad-data Contient des données d'authorisation à interpréter conformément à la valeur du chanp ad-type correspondant
ad-type Spécifie le format du sous-champ ad-data.

   Chaque séquence de type et données est perçue comme un élément d'autorisation. Les éléments peuvent être spécifiques à l'application; cependant, il y a un jeu commun d'éléments récursifs qui devraient être compris par toutes les implémentations. Ces éléments contiennent d'autres éléments embarqués, et l'interprétation de l'élément encapsulé détermine lequel des éléments embarqués doit être interprétés, et ceux qui peuvent être ignorés.

   Ces éléments de données d'autorisation communs sont définis récursivement, signifiant que ad-data pour ces types va lui-même contenir une donnée de séquence d'autorisation. dont l'interprétation est affectée par l'élément encapsulant. En fonction de la signification de l'élément encapsulant, les éléments encapsulés peuvent être ignorés, pourraient être interprétés produit directement par le KDC, ou pourraient être stockés dans une partie plaintext séparé du ticket. Les types d'éléments encapsulant sont spécifiés comme partie de la spécification Kerberos parce que comportement fondé sur ces valeurs devrait être compris te toutes les implémentations, alors que d'autre éléments n'ont besoin d'être compris que par les applications qu'ils affectent.

   Les éléments de données d'autorisation sont considérés comme critiques s'ils sont présents dans un ticket ou un authentifiant. Si un type d'élément de données d'autorisation inconnu est reçu par un serveur dans un AP-REQ ou dans un ticket contenu dans un AP-REP, alors, sauf s'il est encapsulé dans un élément de données d'autorisation commun qui amende la criticité des éléments qu'il contient, l'authentification doit échouer. Les données d'autorisation sont destinées à restreindre l'utilisation d'un ticket. Si le service ne peut pas déterminer si la restriction s'applique à ce service, il peut en résulter une faiblesse de la sécurité de l'utilisation de ce ticket pour ce service. Les éléments d'autorisation qui sont facultatifs peuvent être inclus dans un élément AD-IF-RELEVANT.

Contenu des ad-data__________________ad-type
Codage DER de AD-IF-RELEVANT_________1
Codage DER de AD-KDCIssued___________4
Codage DER de AD-AND-OR______________5
Codage DER de AD-MANDATORY-FOR-KDC___8

IF-RELEVANT

   AD-IF-RELEVANT ::= AuthorizationData

  Les éléments encapsulés au sein de l'élément if-relevant sont destinés seulement à être interprétés par les serveurs d'application qui comprennent le ad-type particulier de l'élément incorporé. Les serveurs d'application qui ne comprennent pas le type d'un élément incorporé au sein de l'élément if-relevant peuvent ignorer l'élément non interprétable. Cet élément aide à l'interopérabilité des implémentations qui peuvent avoir des extensions locales pour l'autorisation.

  Le ad-type pour AD-IF-RELEVANT est (1)

KDCIssued


AD-KDCIssued ::= SEQUENCE {
    ad-checksum [0] Checksum,
    i-realm [1] Realm OPTIONAL,
    i-sname [2] PrincipalName OPTIONAL,
    elements [3] AuthorizationData
}

ad-checksum ckecksum cryptographique calculés sur le codage DER de AuthorizationData dans le champ "elements", keyed avec la clé de session. Son checksumtype est le type de checksum obligatoire pour le type de chiffrement de la clé de sessio, et sa valeur d'utilisation de clé est 19.
i-realm, i-sname Le nom du principal qui émet, s'il est différent de celui du KDC. Ce champ devrait être utilisé lorsque le KDC peut vérifier l'authenticité des éléments signés par le principal qui émet, et permet au KDC de notifier au serveur d'application la validité de ces éléments.
elements Séquence d'éléments de données d'autorisation produite par le KDC.

   Le champ ad-data produit par le KDC est destiné à fournir un moyen pour que les accréditifs de principal Kerberos incorporent en leur sein les attributs de privilège et autres mécanismes d'autorisation positive, amplifiant les privilèges du principal au-delà de ce qui peut être fait en utilisant des accréditifs sans un tel élément a-data.

   Les moyens ci-dessus ne peuvent être fournis sans cet élément à cause de la définition du champ authorization-data qui permet d'ajouter des éléments à volonté par le porteur d'un TGT au moment où il demande les tickets de service, et des éléments peuvent aussi être ajoutés à un ticket délégué par inclusion dans l'authentifiant.

   Pour les éléments produits par le KDC, ceci est empêché parce que les éléments sont signés par le KDC en incluant un checksum chiffrée en utilisant la clé du serveur (la même que celle utilisée pour chiffrer le ticket ou une clé dérivée de cette clé). Les éléments encapsulés avec l'élément produit par le KDC doivent être ignorés par le serveur d'application si cette signature n'est pas présente. De plus, les éléments encapsulés au sein de cet élément à partir d'un TGT peuvent être interprétés par le KDC, et utilisés comme base, conformément à la politique, pour inclure des éléments nouvellement signés au sein de tickets dérivés, mais ils ne seront par copiés directement sur un ticket dérivé. S'ils sont copiés directement sur un ticket dérivé par un KDC qui n'est pas au courant de cet élément, la signature ne sera pas correcte pour les éléments de ticket d'application, et le champ sera ignoré par le serveur d'application.

   Cet élément et les éléments qu'il encapsule peuvent être ignorés en toute sécurité par les applications, serveur d'application, et KDC qui n'implémentent pas cet élément.

AND-OR


AD-AND-OR ::= SEQUENCE {
    condition-count [0] Int32,
    elements [1] AuthorizationData
}

   Lorsque des éléments AD restrictifs sont encapsulés au sein de l'élément and-or, l'élément and-or est considéré comme satisfait si et seulement si au foins le nombre d'éléments encapsulés spécifié dans condition-count est satisfait. Donc, cet élément peut être utilisé pour mettre en œuvre une opération "ou" en réglant le champ condition-count à 1, et il peut spécifier une opération "et" en réglant le compte de condition au nombre d'éléments incorporés. Les serveurs d'application qui ne mettent pas en œuvre cet élément doivent rejeter les tickets qui contiennent des éléments de données d'autorisation de ce type. Le ad-type pour AD-AND-OR est (5)

MANDATORY-FOR-KDC

   AD-MANDATORY-FOR-KDC ::= AuthorizationData

  Les éléments AD encapsulés au sein de l'élément mandatory-for-kdc sont à interpréter par le KDC. Les KDC qui ne comprennent pas le type d'un élément incorporé au sein de l'élément mandatory-for-kdc doivent rejeter la demande. Le ad-type pour AD-MANDATORY-FOR-KDC est (8)

PA-DATA

   Historiquement, les PA-DATA étaient connues comme des données de pré-authentification, ce qui signifie qu'elles étaient utilisée pour augmenter l'authentification initiale auprès du KDC. Depuis cette époque, elles ont aussi été utilisées comme trou typé avec lequel on étend les échanges de protocoles avec le KDC.


PA-DATA ::= SEQUENCE {
    -- NOTE : la première étiquette est [1], et non [0]
    padata-type [1] Int32,
    padata-value [2] OCTET STRING -- peut être codée AP-REQ
}

padata-type Indique la façon d'interpréter l'élément padata-value. Les valeurs négatives de padata-type sont réservées pour des utilisations non-enregistrées; les valeurs non négatives sont utilisée pour une interprétation répertoriée du type d'élément.
padata-value Contient habituellement le codage DER d'un autre type; le champ padata-type identifie quel type est codé ici.


type de padata__Nom_______________Contenu de la valeur padata
1_______________pa-tgs-req________Codage en DER de AP-REQ
2_______________pa-enc-horodatage_Codage en DER de PA-ENC-TIMESTAMP
3_______________pa-pw-salt________sel (non codé en ASN.1)
11______________pa-etype-info_____Codage en DER de ETYPE-INFO
19______________pa-etype-info2____Codage en DER de ETYPE-INFO2

   Ce champ peut aussi contenir des informations nécessaires à certaines extensions au protocole Kerberos. Par exemple, il peut être utilisé pour vérifier l'identité d'un client avant qu'aucune réponse ne soit retournée.

   Le champ padata peut aussi contenir les informations nécessaires pour aider le KDC ou le client à choisir la clé nécessaire pour générer ou déchiffrer la réponse. Cette forme de padata est utile pour la prise en charge de l'utilisation de certaines cartes avec Kerberos.

PA-TGS-REQ

   Dans le cas de demandes de tickets supplémentaire KRB_TGS_REQ, padata-value contient une AP-REQ coddée. La somme de contrôle dans l'authentifiant ( qui doit être à l'épreuve des collisions ) est à calculer sur le codage de KDC-REQ-BODY.

Pré-authentification à timestamp chiffré

   Il y a des types de pré-authentification qui peuvent être utilisés pour pré-authentifier un client au moyen d'un timestamp chiffré.


PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
    
PA-ENC-TS-ENC ::= SEQUENCE {
    patimestamp [0] KerberosTime -- client's time --,
    pausec [1] Microseconds OPTIONAL
}

   patimestamp contient l'heure du client, et pausec contient les microsecondes, qui peuvent être omises si un client ne va pas générer plus d'une demande par seconde. Le texte chiffré ( padata-value ) comporte le codage de PA-ENC-TS-ENC, chiffré en utilisant la clé secrète du client et une valeur d'utilisation de clé de 1.

PA-PW-SALT

   padata-value pour ce type de pré-authentification contient de salt pour le string-to-key à utiliser par le client pour obtenir la clé pour déchiffrer la partie chiffrée d'un message AS-REP. Malheureusement, pour des raisons historiques, l'ensemble de caractères à utiliser n'est pas spécifié et probablement spécifique à la localisation.

   Dans l'exemple trivial, une chaîne de salt de longueur 0 est très courant pour les domaines qui ont converti leur bases de données de principal depuis une version 4. Un KDC ne devrait par envoyer PA-PW-SALT lorsqu'il produit un message KRB-ERROR qui demande une pré-authentification supplémentaire. Note d'implémentation: Certaines implémentations de KDC produisent un PA-PW-SALT erroné lorsqu'elle envoient un message KRB-ERROR qui demande une pré-authentification supplémentaire. Donc, les clients devraient ignorer un PA-PW-SALT accompagnant un KDC-ERROR qui demande une pré-authentification supplémentaire. Un KDC ne doit pas envoyer PA-PW-SALT lorsque le AS-REQ du client comporte au moins un etype "newer".

PA-ETYPE-INFO

   Le type de pré-authentification ETYPE-INFO est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP.


ETYPE-INFO-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY

   Le salt, comme celui de PA-PW-SALT, est aussi complètement non spécifié par rapport au jeu de caractères et est probablement spécifique à la localisation. Si ETYPE-INFO est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO-ENTRY, et son etype doit correspondre à celui du enc-part dans AS-REP. Un KDC ne doit pas envoyer PA-ETYPE-INFO lorsque le AS-REQ du client comporte un moins un etype "newer".

PA-ETYPE-INFO2

   Le type de pré-authentification ETYPE-INFO2 est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP


ETYPE-INFO2-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] KerberosString OPTIONAL,
    s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

   Le type de salt est un KerberosString, mais les installations existantes peuvent avoir des caractères spécifiques de la localisation mémorisés dans le chaînes de salt, et les développeurs peuvent choisir de les traiter. L'interprétation de s2kparams est spécifiée dans la description du cryptosystem associé au etype. Chaque cryptosystem a une interprétation par défaut de s2kparams qui restera si cet élément est omis dans le codage de ETYPE-INFO2-ENTRY.

   Si ETYPE-INFO2 est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO2-ENTRY, et son etype doit correspondre à celui du enc-part dans le AS-REP. L'ordre préféré des données de pré-authentification conseillé qui affecte le choix de clé du client est: ETYPE-INFO2, suivi par ETYPE-INFO, suivi par PW-SALT. Un KDC ne doit pas envoyer de ETYPE-INFO ou PW-SALT lorsque AS-REQ comporte au moins un etype "newer".

KerberosFlags



KerberosFlags ::= BIT STRING (SIZE (32..MAX))
    -- nombre minimum de bits qui doivent être envoyés, mais pas moins de 32

   Note de compatibilité: les paragraphes suivants décrivent un changement par rapport à la description de la rfc1510 des chaînes binaires qui résulteraient en une incompatibilité dans le cas d'une mise en œuvre strictement conforme au DER de l'ASN.1 et à la RFC1510.

   Les chaînes binaires ASN.1 ont plusieurs utilisations. L'utilisation la plus simple d'une chaîne est de contenir un vecteur de bits, sans signification particulière attachée aux bits individuels. Ce vecteur de bits n'est pas nécessairement un multiple de 8 bits de longueur. L'utilisation par Kerberos d'une chaîne binaire comme vecteur booléen compact dans lequel chaque élément a une signification distincte pose quelques problèmes. La notation naturelle pour un vecteur booléen compact est la notation ASN.1 "NamedBit", et les DER exigent que les codages d'une chaîne binaire qui utilise la notation "NamedBit" excluent tous bits à zéro en queue. Il est facile de négliger cette troncature, tout particulièrement dans les implémentations de langage C qui choisissent naturellement de mémoriser les vecteur booléens comme des entiers de 32bits.

   Par exemple, si la notation de KDCOptions devait inclure la notation "NamedBit", comme dans la rfc1510, et si la valeur KDCOptions à coder avait seulement le bit "transmissible" (bit numéro 1) mis, le codage DER doit n'inclure que 2 bits: le premier est à 0 et est réservé, et le bit de valeur 1 pour transmissible.

   La plupart des implémentations de Kerberos envoient inconditionnellement 32 bits sur le réseau lors du codage de chaînes binaires utilisée comme vecteurs booléens. Ce comportement viole la syntaxe ASN.1 utilisée pour les valeurs de flag dans la rfc1510, mais cela survient si fréquemment que la description du protocole en est modifiée pour s'en accommoder.

   Par conséquent, le présent document retire la notation "NamedBit" pour les bits individuels, les relèguant en commentaires. La contrainte de taille sur le type KerberosFlags exige qu'au moins 32 bits soient codés à tout moment, bien qu'une implémentation laxiste puisse choisir d'accepter moins de 32bits et de traiter les bits manquants comme mis à 0.

   Actuellement, aucune utilisation de KerberosFlags ne spécifie plus de 32bits de flags, bien que de futures révisions du présent document puissent le faire. Lorsque plus de 32 bits sont à transmettre dans une valeur de KerberosFlags, les futures révisions du présent document spécifieront spécifieront vraisemblablement que le plus petit nombre de bits nécessaires pour coder le bit de valeur un de plus haut rang devrait être envoyé. Ceci est assez similaire au codage en DER d'une chaîne binaire qui est déclarée avec la notation "NamedBit".

Type liés au cryptosystem

   De nombreux messages de protocole Kerberos contiennent un EncryptedData comme conteneur pour des données chiffrées de façon arbitraire, qui sont souvent le codage chiffré d'un autre type de données. Les champs au sein de EncryptedData assistent le receveur dans le choix d'une clé pour le déchiffrer


EncryptedData ::= SEQUENCE {
    etype [0] Int32 -- EncryptionType --,
    kvno [1] UInt32 OPTIONAL,
    cipher [2] OCTET STRING – texte chiffré
}

etype Ce champ spécifie l'algorithme de chiffrement utilisé pour chiffrer le texte
kvno Ce champ contient le numéro de version de clé utilisée pour chiffrer les données. n'est présent que dans les messages chiffrés avec des clés à longue durée.
cipher Contient le texte chiffré.

   Le type EncryptionKey est le moyen par lequel les clés cryptographiques utilisée pour le chiffrement sont transférées.


EncryptionKey ::= SEQUENCE {
    keytype [0] Int32 -- actually encryption type --,
    keyvalue [1] OCTET STRING
}

keytype Spécifie le type de chiffrement de la clé de chiffrement qui suit dans le champ keyvalue.
keyvalue Contient la clé elle-même, codée comme une chaîne d'octet.

   Les messages qui contiennent des données de texte en clair à authentifier le feront habituellement en utilisant un membre du type Checksum. La plupart des instances de Checksums utilisent un hachage chiffré, bien que des exceptions existent.


Checksum ::= SEQUENCE {
    cksumtype [0] Int32,
    checksum [1] OCTET STRING
}

cksumtype Indique l'algorithme utilisé pour générer la somme de contrôle qui l'accompagne
checksum Contient la somme de contrôle elle-même.

Tickets

   Ce paragraphe décrit les paramètres de format et de chiffrement pour les tickets et les authentifiants. Lorsqu'un ticket ou un authentifiant est inclus dans un message de protocole, il est traité comme un objet opaque. Un ticket est un enregistrement qui aide un client à s'authentifier auprès d'un service. Un ticket contient les informations suivantes:


Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno [0] INTEGER (5),
    realm____[1] Realm,
    sname____[2] PrincipalName,
    enc-part_[3] EncryptedData -- EncTicketPart
}
-- Partie chiffrée du ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
    flags______________[0] TicketFlags,
    key________________[1] EncryptionKey,
    crealm_____________[2] Realm,
    cname______________[3] PrincipalName,
    transited__________[4] TransitedEncoding,
    authtime___________[5] KerberosTime,
    starttime__________[6] KerberosTime OPTIONAL,
    endtime____________[7] KerberosTime,
    renew-till_________[8] KerberosTime OPTIONAL,
    caddr______________[9] HostAddresses OPTIONAL,
    authorization-data_[10] AuthorizationData OPTIONAL
}
-- champs traversés codés
TransitedEncoding ::= SEQUENCE {
tr-type__[0] Int32 -- doit être enregistré --,
contents_[1] OCTET STRING
}
TicketFlags ::= KerberosFlags
    -- reserved(0),
    -- forwardable(1),
    -- forwarded(2),
    -- proxiable(3),
    -- proxy(4),
    -- may-postdate(5),
    -- postdated(6),
    -- invalid(7),
    -- renewable(8),
    -- initial(9),
    -- pre-authent(10),
    -- hw-authent(11),
-- les flags suivants sont nouveaux depuis la RFC 1510
    -- transited-policy-checked(12),
    -- ok-as-delegate(13)

tkt-vno Spécifie le numéro de version pour le format de ticket. Ce document décrit la version 5
realm Spécifie le domaine qui a produit un ticket. Sert à identifier la partie de domaine de l'identifiant de principal du serveur. Comme un serveur Kerberos ne peut produire de tickets que pour des serveurs au sein de son domaine, les deux seront toujours identiques.
sname Spécifie tous les composants de la partie nom de l'identité du serveur, incluant les parties qui identifient une instance spécifique d'un service.
enc-part Contient le codage chiffré de la séquence EncTicketPart. Il est chiffré avec la clé partagée par Kerberos et le serveur d'extrémité (la clé secrète du serveur), en utilisant une clé de valeur d'utilisation de 2.
flags Indique lesquelles des diverses options ont été utilisées ou demandées lorsque le ticket a été produit. La signification des flags est la suivante:

        0 (Réserved)
        1 (forwardable) Le flag FORWARDABLE n'est normalement interprété que par le TGS, et peut être ignoré par les serveurs d'extrémité. Lorsqu'il est mis, ce flag dit au TGS qu'il est ok pour produire un nouveau TGT avec une adresse réseau différente fondée sur le ticket présenté.
        2 (forwarded) Lorsque mis, ce flag indique que le ticket a été transmis ou a été produit sur la base d'une authentification impliquant un TGT transmis.
        3 (proxiable) Normalement interprété que par le TGS et est identique que FORWARDABLE, excepté qu'il dit au TGS que seuls des non-TGT peuvent être produits avec des adresses réseau différentes.
        4 (proxy) Indique que ce ticket a été mandaté
        5 (may-postdate) Normalement interprété que par le TGS et indique qu'un ticket post-daté peut être produit sur la base de ce TGT.
        6 (postdated) Indique que ce ticket est post-daté
        7 (invalid) Indique que ce ticket est invalide, et qu'il doit être validé par le KDC avant utilisation.
        8 (renewable) Normalement interprété que par le TGS et peut être utilisé pour obtenir un ticket de remplacement qui expire à une date ultérieur.
        9 (initial) Indique que ce ticket a été produit en utilisant le protocole d'AS, et non pas produit sur la base d'un TGT.
        10 (pre-authent) Indique que durant l'authentification initiale, le client a été authentifié par le KDC avant la production d'un ticket.
        11 (hw-authent) Indique que le protocole utilisé pour l'authentification initiale exige l'utilisation d'un matériel.
        12 (transited-policy-checked) Indique que le KDC pour le domaine a vérifié le champ de transit par rapport à une politique définie par le domaine en matière de certificateurs de confiance. Si ce flag est à 0, le serveur d'application doit alors vérifier le champ de transit lui-même, et s'il est incapable de le faire, il doit rejeter l'authentification. Si le flag est à 1, le serveur d'application peut alors s'affranchir de la vérification.
        13 (ok-as-delegate) Indique que le serveur ( et non le client ) spécifié dans le ticket a été déterminé par la politique du domaine comme étant un receveur de délégation convenable. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs à ce serveur.
        14-31 (reserved) Réservé

key Ce champ existe dans le ticket et la réponse du KDC et il est utilisé pour passer la clé de session Kerberos au serveur d'application et au client.
crealm Ce champ contient le nom du domaine dans lequel le client est enregistré et dans lequel l'authentification initiale a eu lieu.
cname Ce champ contient la partie nom de l'identifiant de principal du client.
transited Ce champ donne la liste des noms des domaines Kerberos qui ont pris part à l'authentification de l'utilisateur à qui ce ticket a été produit. Il ne spécifie par l'ordre dans lequel les domaines ont été traversés. Quand les noms des CA sont à incorporer dans le champ de transit ( comme spécifié pour certaines extensions au protocole ), les noms X.500 des CA devraient être transposé en éléments dans ce champ en utilisant la transposition définis dans la rfc2253.
authtime Ce champ indique l'heure de l'authentification initiale du principal désigné. C'est l'heure de production du ticket original sur lequel est fondé ce ticket.
starttime Ce champ dans le ticket spécifie l'heure après laquelle le ticket sera valide. Avec le champ endtime, ce champ spécifié la durée de vie du ticket. S'il est absent, le champ authtime devrait alors être utilisé à la place pour déterminer la durée de vie du ticket.
endtime Ce champ contient l'heure après laquelle le ticket ne sera plus honoré.
renew-till Ce champ n'est présent que dans les ticket qui on le flag RENEWABLE mis. Indique l'heure de fin maximum qui peut être incluse dans un renouvellement. Il peut aussi être vu comme l'heure d'expiration absolue pour le ticket, y compris pour les renouvellements.
caddr Ce champ dans un ticket contient zéro (s'il est omis) ou plusieurs adresses d'hôte. Ce sont les adresses à partir desquelles le ticket peut être utilisé. S'il n'y a pas d'adresse, le ticket peut être utilisé à partir de toute localisation. La décision du KDC de produire, ou par le serveur d'extrémité d'accepter des tickets sans adresse est une décision de politique qui est laissée à Kerberos et aux administrateurs de service d'extrémité; ils peuvent refuser de produire ou d'accepter de tels tickets. À cause du large développement de la traduction des adresses réseau, il est recommandé que les politiques permettent la production et l'acceptation de tels tickets.

   Les adresse réseau sont incluses dans le ticket pour rendre plus difficile à un agresseur d'utiliser des accréditifs volés. Comme la clé de session n'est pas envoyée sur le réseau en clair, les accréditifs ne peuvent pas être volés simplement en écoutant le réseau; un agresseur doit gagner l'accès à une clé de session ( peut-être à travers des failles de la sécurité du système d'exploitation ou une session non surveillée d'un utilisateur négligeant) pour utiliser des tickets volés.

   Noter que l'adresse réseau à partir de laquelle une connexion est reçue ne peut pas être déterminée de façon fiable. Même si elle pouvant l'être, un agresseur qui a compromis la workstation du client pourrait utiliser les accréditifs à partir de là Inclure les adresses réseau ne fait que rendre plus difficile, mais pas impossible, à un agresseur de sortir avec des accréditifs volés et de les utiliser ensuite à partir d'un localisation sûre.

authorization-data Ce champ est utilisé pour passer les données d'autorisation du principal au nom duquel un ticket a été produit au service d'application. Si aucune données d'autorisation n'est incluse, ce champ sera laissé de côté. L'expérience nous montre que le nom de ce champ prête à confusion, et un meilleur nom serait "restrictions".

   Ce champ contient des restrictions à toute autorité obtenue sur la base d'une authentification utilisant le ticket. Il est possible à tout principal en possession d'accréditifs d'ajouter des entrées au champ de données d'autorisation car ces entrées prolongent les restrictions qui peuvent être faites avec le ticket. De telles additions peuvent être faites en spécifiant les entrées supplémentaires lorsqu'un nouveau ticket est obtenu durant l'échange TGS, ou elle peuvent être ajoutées durant une délégation chaînée utilisant le champ de données d'autorisation de l'authentifiant.

   Les données dans ce champ peuvent être spécifiques du service d'extrémité; le champ contiendra les noms des objets spécifiques du service, et les droits de ces objets. Bien que Kerberos ne soit pas concerné par le format du contenu des sous-champs, il en porte les information de type (ad-type).

   En utilisant le champ authorization-data, un principal est capable de produire un mandat valide pour un objet spécifique. Par exemple, un client souhaitant imprimer un fichier peut obtenir qu'un mandat de serveur de fichiers soit passé au serveur d'impression. En spécifiant le nom du fichier dans le champ authorization-data, le serveur de fichiers sait que le serveur d'impression peut seulement utiliser les droits du client lorsqu.il accède au fichier particulier à imprimer.

   On peut construire un service séparé qui fournit l'autorisation ou la certification d'appartenance à un groupe en utilisant le champ authorization-data. Dans ce cas, l'entité qui accorde l'autorisation (et non l'entité autorisée) peut obtenir un ticket en son nom propre (par exemple, le ticket est produit au nom d'un serveur privilégié), et cette entité ajoute des restrictions à sa propre autorité et délègue au client l'autorité restreinte à travers un mandataire. Le client présenterait alors cet accréditif d'autorisation au serveur d'application séparément de l'échange d'authentification. Autrement, de tels accréditifs d'autorisation peuvent être incorporés dans le ticket qui authentifie l'entité autorisée, lorsque l'autorisation est authentifiée séparément en utilisant l'élément de données d'autorisation produit par le KDC.

   De même, si on spécifie le champ authorization-data d'un mandataire et qu'on laisse en blanc les adresses d'hôte, le ticket et la clé de session qui résultent peuvent être traités comme une capacité. Le champ authorization-data est facultatif et n'a pas à être inclus dans un ticket.

Spécification pour les échanges AS et TGS

   Ce paragraphe spécifie le format des messages utilisés dans l'échange entre le client et le serveur Kerberos.

Définition de KRB_KDC REQ

   Le message KRB_KDC_REQ n'a pas de numéro d'étiquette d'application par lui-même. Il est incorporé dans KRB_AS_REQ ou KRB_TGS_REQ, qui ont chacune une étiquette d'application, selon que la demande est celle d'un ticket initial ou d'un ticket supplémentaire. Dans les 2 cas, le message est envoyé du client au KDC pour demander des accréditifs pour un service.

Les champs de message sont les suivants:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ := [APPLICATION 12] KDC-REQ
    
KDC-REQ ::= SEQUENCE { -- NOTE: la première étiquette est [1], pas [0]
    pvno    [1] INTEGER (5) ,
    msg-type    [2] INTEGER (10 -- AS -- | 12 -- TGS --),
    padata    [3] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    req-body    [4] KDC-REQ-BODY
}
    
KDC-REQ-BODY ::= SEQUENCE {
    kdc-options    [0] KDCOptions,
    cname    [1] PrincipalName OPTIONAL -- Ne sert que dans AS-REQ --,
    realm    [2] Realm -- Domaine du serveur et aussi du client dans AS-REQ --,
    sname    [3] PrincipalName OPTIONAL, from [4] KerberosTime OPTIONAL,
    till    [5] KerberosTime,
    rtime    [6] KerberosTime OPTIONAL,
    nonce    [7] UInt32,
    etype    [8] SEQUENCE OF Int32 -- Type de chiffrement dans l'ordre de préférence --,
    addresses    [9] HostAddresses OPTIONAL,
    enc-authorization-data    [10] EncryptedData OPTIONAL -- AuthorizationData --,
    additional-tickets    [11] SEQUENCE OF Ticket OPTIONAL -- NOTE : non vide
}
    
KDCOptions ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
        -- 15 est réservé pour la canonisation
        -- unused15(15),
        -- 26 n'était pas utilisé dans la rfc 1510
        -- disable-transited-check(26),--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

pvno Inclus dans chaque message de protocole, et spécifie le numéro du protocole. Doit être à 5
msg-type Indique le type d'un message. Il sera presque toujours le même que l'identifiant d'application associé à un message. Il est inclus pour rendre l'identifiant plus facilement accessible à l'application. Pour le message KDC-REQ, ce type sera KRB_AS_REQ ou KRB_TGS_REQ.
padata Contient les données de pré-authentification. Les demandes de tickets supplémentaires ( KRB_TGS_REQ ) doivent contenir un padata de PA-TGS-REQ. Ce champ contient une séquence d'informations d'authentification qui peuvent être nécessaire avant que les accréditifs puissent être produits ou déchiffrés.
req-body Paramètre fictif qui délimite l'extension des champs restants. Si une somme de contrôle est à calculer dur la demande, elle est calculée sur un codage de la séquence KDC-REQ-BODY qui est dans le champ req-body.
kdc-options Ce champ apparaît dans les demandes KRB_AS_REQ et KRB_TGS_REQ et indique les flags que le client veut mettre sur les tickets ainsi que les autres informations qui vont modifier le comportement du KDC. Lorsque c'est approprié, le nom d'une option peut être le même que celui du flag qui est mis par cette option. Bien que dans la plupart des cas le bit dans le champ options soit le même que celui du champ flags, cela n'est pas garanti, aussi il n'est pas acceptable de simplement copier le champ options dans le champ flags. Diverses vérifications doivent être faites avant qu'une option ne soit honorée.

   Le cahmp kdc_options est un champ binaire, où les options choisies sont indiquées par le bit mis, et les option non choisies et les champs réservés ne sont pas mis. La signification des options est la suivante:

        0 (Réserved)
        1 (FORWARDABLE) Indique que le tickest est fournis avec le flag forwardable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également forwardable.
        2 (FORWARDED) Seulement spécifié dans une demande au TGS et sera honoré si le TGT dans la demande a le bit FORWARDABLE mis.
        3 (PROXIABLE) Indique que le tickest est fournis avec le flag proxiable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également proxiable.
        4 (PROXY) Indique que c'est une demande pour un proxy et sera honoré si le TGT dans la demande a le bit PROXIABLE mis.
        5 (ALLOW-POSTDATE) Indique que le ticket à fournir doit avoir MAY-POSTDATE mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également MAY-POSTDATE.
        6 (POSTDATED) Indique que c'est une demande pour un ticket post-daté. Sera honoré si le TGT sur lequel il est basé a son MAY-POSTDATE mis. Le ticket résultant aura également le flag INVALID mis.
        7 (RESERVED)
        8 (RENEWABLE) Indique que le ticket à fournir doit avoir son flag RENEWABLE mis. Peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également renewable
        9 (RESERVED)
        10 (RESERVED)
        11 (RESERVED)
        12-25 (RESERVED)
        26 (DISABLE-TRANSITED-CHECK) Indique au KDC de ne pas vérifier le champ transited
        27 (RENEWABLE-OK) Indique qu'un ticket renouvelable sera acceptable si un ticket avec la durée de vie requise ne peut autrement être fourni, auquel cas un ticket renouvelable peut être produit avec un renew-till égal à l'heure de fin demandée.
        28 (ENC-TKT-IN-SKEY) N'est utilisée que par le TGS. indique que le ticket pour le serveur d'extrémité est à chiffrer avec la clé de session provenant du TGT supplémentaire fourni.
        29 (RESERVED)
        30 (RENEW) N'est utilisé que par le TGS. Indique que la demande est pour un renouvellement. Le ticket fournis est chiffré dans la clé secrète pour le serveur sur lequel il est valide. Ne sera honoré que si le ticket à renouveler a son flag RENEWABLE mis et si renew-till n'est pas passé.
        31 (VALIDATE) N'est utilisé que par le TGS. Indique que la demande est pour un ticket post-daté à valider.

cname et sname Ces champs sont les mêmes que ceux décrits pour le ticket plus haut. Le sname ne peut être absent que lorsque l'option ENC-TGT-IN-SKEY est spécifié. Si le sname est absent, le nom du serveur est tiré du nom du client dans le ticket passé comme ticket supplémentaire.
enc-authorization-data Si présent (et ne peut l'être que sous la forme de TGS_REQ), est un codage des authorizations désirées chiffré avec la sous-clé de session si elle est présent dans l'authentifiant, ou avec la clé de session dans le TGT (l'authentifiant et le TGT viennent tous deux du champ padata dans le KRB_TGS_REQ). La valeur d'utilisation de clé utilisée pour le chiffrement est 5 si une sous-clé de session est utilisée, ou 4 si la clé de session est utilisée.
realm Spécifie la partie domaine de l'identifiant de principal du serveur. Dans l'échange AS, c'est aussi la partie domaine de l'identifiant de principal du client.
from Ce champ est inclus dans les demandes de ticket KRB_AS_REQ et KRB_TGS_REQ lorsque le ticket demandé est à post-dater. Il spécifie l'heure de début de validité pour le ticket demandé. Si omis, le KDC devrait uiliser l'heure en cours.
till Contient la date d'expiration demandée par le client dans une demande de ticket. Il n'est pas facultatif, mais si l'heure de fin demandée est "19700101000000Z", le ticket aura l'heure maximum permise par le KDC.
rtime Ce champ est l'heure de renew-till envoyée au KDC dans une demande de ticket. facultatif.
nonce Fait partie de la demande et de la réponse du KDC. Il est destiné à contenir un nombre aléatoire généré par le client. Si le même nombre est inclus dans la réponse chiffrée provenant du KDC, cela montre à l'évidence que la réponse est fraîche et n'a pas été répétée par un attaquant. Les noms occasionnels ne doivent jamais être réutilisés.
etype Ce champ spécfie l'algorithme de chiffrement désiré à utiliser dans la réponse.
addresses Ce champ est inclus dans la demande de ticket, et il est facultativement inclus dans les demandes de tickets supplémentaire provenant du serveur d'allocation de tickets. Il spécifie les adresse à partir desquelles le ticket demandé doit être valide. Normalement, il inclut les adresse de l'hôte du client. Si un proxy est demandé, ce champ contiendra d'autres adresse. Ce champ est généralement copié par le KDC dans le champ cappr du ticket résultant.
additional-tickets Des tickets supplémentaire peuvent être facultativement inclus dans une demande au TGS. Si l'option ENC-TGT-IN-SKEY a été spécifiée, la clé de session provenant du ticket supplémentaire sera alors utilisée à la place de la clé du serveur pour chiffrer le nouveau ticket. Lorsque l'option ENC-TKT-IN SKEY est utilisée pour l'authentification d'utilisateur à utilisateur, ce ticket supplémentaire peut être un TGT produit par le domaine local ou un TGT inter-domaine produit pour le domaine du KDC en cours par un KDC distant. Si plus d'une option exigeant des tickets supplémentaire a été spécifiée, les tickets supplémentaire sont alors utilisés dans l'ordre spécifié par l'ordre des bits des options bits.

Définition de KRB_KDC_REP

   Le format de message KRB KDC_REP est utilisé pour la réponse du KDC à une demande initiale ( AS ) ou à une demande ultérieure ( TGS ). Il n'y a pas de type de message pour KRB_KDC_REP. Le type sera KRB_AS_REP ou KRB_TGS_REP. La clé utilisée pour chiffrer la partie de texte chifrée de la réponse dépend du type de message. Pour KRB_AS_REP, le texte est chiffré avec la clé secrète du client, et le numéro de version de clé du client est inclus dans le numéro de version de clé pour les données chiffrées. Pour KRB_TGS_REP, et texte est chiffré avec la clé de session provenant du TGT utilisé dans la demande. Dans ce cas, aucun numéro de version ne sera présent dans la séquence EncryptedData.

Les champs de message sont les suivants:
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (11 -- AS -- | 13 -- TGS --),
    padata    [2] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    crealm    [3] Realm,
    cname    [4] PrincipalName,
    ticket    [5] Ticket,
    enc-part    [6] EncryptedData -- EncASRepPart ou EncTGSRepPart, selon le cas
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPar ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
    key    [0] EncryptionKey,
    last-req    [1] LastReq,
    nonce    [2] UInt32,
    key-expiration    [3] KerberosTime OPTIONAL,
    flags    [4] TicketFlags,
    authtime    [5] KerberosTime,
    starttime    [6] KerberosTime OPTIONAL,
    endtime    [7] KerberosTime,
    renew-till    [8] KerberosTime OPTIONAL,
    srealm    [9] Realm,
    sname    [10] PrincipalName,
    caddr    [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
    lr-type    [0] Int32,
    lr-value    [1] KerberosTime
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_AS_REP ou KRB_TGS_REP
padata Décrits dans KRB_KDC_REQ. Une utilisation possible est de coder une chaîne salt à utiliser avec un algorithme de string-to-key. C'est utile pour faciliter les transitions si un nom de domaine doit changer; dans un tel cas, toutes les entrées déduites de mot de passe existantes dans la base de données Kerberos auraient un flag marquant qu'elles ont besoin d'une chaîne salt spécial jusqu'au prochain changement de mot de passe.
crealm, cname, srealm, et sname Décrits dans KRB_KDC_REQ.
ticket C'est le ticket nouvellement produit
enc-part Ce champ est un fourre-tout pour le texte chiffré et les informations qui s'y rapportent, qui forme la partie chiffrée d'un message. La description de la partie chiffrée du message suit chaque apparition de ce champ.

   La valeur d'utilisation de clé pour le chiffrement de ce champ est 3 dans un message AS-REP, en utilisant la clé à long-terme du client ou une autre clé choisie via des mécanismes de pré-authentification. Dans un message TGS-REP, la valeur d'utilisation de clé est 8 si la clé de session TGS est utilisée, ou 9 si une sous-clé d'authentifiant TGS est utilisée.

key Ce champ est le même que celui décrit au paragraphe ticket
last-req Ce champ est retourné par le KDC et spécifie l'heure de la dernière demande d'un principal. Selon les informations disponibles, ce peut être la dernière fois qu'une demande de TGT a été faite, ou la dernière fois qu'une demande fondée sur un TGT a réussi. I peut aussi couvrir tous les serveurs d'un domaine, ou juste un serveur particulier. Certaines implémentations peuvent afficher ces informations à l'utilisateur pour aider à découvrir des utilisations non autorisées d'une identité. C'est d'un esprit similaire à l'affichage de la dernière connexion affichée à la connexion dans les systèmes en tamps partagé.
lr-typeCe champ indique comment interpréter le champ lr-value suivant. Les valeurs négatives indiquent que ces informations n'appartiennent qu'au serveur qui répond. Les valeurs non négatives appartiennent à tous les serveurs pour le domaine. Les valeurs possibles sont:

        0 Aucune information n'est portée par le sous-champ lr-value.
        1 le sous-champ lr-value est l'heure de la dernière demande initiale pour un TGT.
        2 Le sous-champ lr-value est l'heure de la dernière demande initiale.
        3 Le sous-champ lr-value est l'heure de la production du plus récent TGT utilisé
        4 Le sous-champ lr-value est l'heure de la demande du dernier renouvellement
        5 Le sous champ lr-value est l'heure de la dernière demande (de tout type).
        6 Le sous-champ lr-value est l'heure de l'arrivée à expiration du mot de passe.
        7 Le sous-champ lr-value est l'heure de l'arrivée à expiration du compte.

lr-value Ce champ contient l'heure de la dernière demande. L'heure doit être interprété conformément au contenu du sous-champ lr-type qui l'accompagne.
nonce Décrits dans KRB_KDC_REQ.
key-expiration Ce champ fait partie de la réponse du KDC et spécifie l'heure à laquelle la clé secrète du client va arriver à expiration. L'expiration peut être le résultat du vieillissement d'un mot de passe ou de l'expiration d'un compte. S'il est présent, il devrait être réglé au plus tôt de l'expiration de la clé de l'utilisateur et de l'expiration du compte. L'utilisation de ce champ est déconseillé, et le champ last-req devrait être utilisé à la place pour porter ces informations. Ce champ sera normalement laissé en dehors de la réponse TGS car la réponse à une demande de TGS est chiffrée avec une clé de session et aucune information client n'a à être restituée de la base de données du KDC. Il appartient au client d'application ( généralement le programme de connexion) de prendre les mesures appropriées si l'heure d'expiration est imminente.
flags, authtime, starttime, endtime, renew-till et caddr Ces champs sont des duplications de ceux qui figurent dans la portion chiffré du ticket joint, et ils sont fournis pour que le client puisse vérifier qu'ils correspondent à la demande prévue et afin d'aider à une mise en mémoire cache appropriée du ticket. Si le message est du type KRB_TGS_REP, le champ caddr ne sera rempli que si la demande était pour un proxy ou un ticket transmis, ou si l'utilisateur substitue un sous-ensemble des adresses venant du TGT. Si les adresses demandées par le client ne sont pas présentes ou pas utilisées, les adresses contenues dans le ticket devront alors être les mêmes que celles incluses dans le TGT.

Spécifications de message client-serveur

   Ce paragraphe spécifie le format des messages utilisée pour l'authentification du client auprès du serveur d'application.

Définition de KRB_AP_REQ

   Le message KRB_AP_REQ contient le numéro de version du protocole Kerberos, le type de message KRB_AP_REQ, un champ d'options pour indiquer toutes les options utilisée, et le ticket et l'authentifiant eux-mêmes. Le message KRB_AP_REQ est souvent désigné comme un en-tête d'authentification.


AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (14),
    ap-options    [2] APOptions,
    ticket    [3] Ticket,
    authenticator    [4] EncryptedData -- Authentifiant
}
APOptions ::= KerberosFlags
    -- reserved(0),
    -- use-session-key(1),
    -- mutual-required(2)

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REQ
ap-options Ce champ apparaît dans la demande d'application KRB_AP_REQ et affecte la façon dont la demande est traitée. C'est un champ binaire, où les options choisies sont indiquées par le bis mis, et les options non choisies à 0. La signification des options est la suivante:

        (reserved) 1
        (use-session-key) Indique que le ticket que présente le client à un serveur est chiffré avec la clé de session venant du TGT du serveur. Quand cette option n'est pas spécifiée, le ticket est chiffré avec la clé secrète du serveur. 2
        (mutual-required) Dit au serveur que le serveur exige l'authentification mutuele, et qu'il doit répondre par un message KRB_AP_REP. 3-31
        (reserved)

ticket Ce champ est un ticket authentifiant le client auprès du serveur
authenticator Contient l'authentifiant chiffré, qui inclut le choix d'une sous-clé par le client.

   L'authentifiant chiffré est inclus dans le AP-REQ; il certifie à un serveur que l'envoyeur a une connaissance récente de la clé de chiffrement du ticket d'accompagnement, pour aider le serveur à détecter les répétitions. Il aide aussi au choix d'une vraie clé de session à utiliser dans cette session. Le codage DER de ce qui suit est chiffré avec la clé de session du ticket, avec une valeur d'utilisation de clé de 11 dans les échanges d'application normaux, ou 7 lorsque utilisée comme champ PA-TGS-REQ PA-DATA d'un échange TGS-REQ.


-- Authentifiant non chiffré
Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno    [0] INTEGER (5),
    crealm    [1] Realm,
    cname    [2] PrincipalName,
    cksum    [3] Checksum OPTIONAL,
    cusec    [4] Microseconds,
    ctime    [5] KerberosTime,
    subkey    [6] EncryptionKey OPTIONAL,
    seq-number    [7] UInt32 OPTIONAL,
    authorization-data    [8] AuthorizationData OPTIONAL
}

authenticator-vno Spécifie le numéro de version du format de l'authentifiant. Vaut 5
crealm et cname Décrit dans le paragraphe ticket
cksum Contient un checksum des données d'application qui accompagnent le KRB_AP_REQ. calculée en utilisant une valeur d'utilisation de clé de 10 dans les échanges d'application normaux, ou 6 lorsqu'utilisé dans le champ TGS-REQ PA-TGS-REQ AP-DATA
cusec Ce champ contient la partie microsecondes du timestamp du client. sa valeur va de 0 à 999999.
ctime Ce champ contient l'heure en cours sur l'hôte du client
subkey Ce champ contient le choix du client d'une clé de chiffrement à utiliser pour protéger cette session d'application spécifique. Sauf si une application spécifie autre chose, si ce champ est laissé de côté, la clé de session venant du ticket sera utilisée.
seq-number Ce champ optionnel comporte le numéro de séquence initial à utiliser par KRB_PRIV ou KRB_SAFE lorsque les numéros de séquence sont utilisés pour détecter les répétitions.

   Il peut aussi être utilisé par des messages spécifiques de l'application. Lorsqu'il est inclus dans l'authentifiant, ce champ spécifie le numéro de séquence initiale pour les messages du client au serveur. Lorsqu'il est inclus dans le message KRB_PRIV ou KRB_SAFE, il est incrémenté de un après l'envoi de chaque message. Les numéros de séquence sont dans la gamme de 0 à 2^32 -1 puis reviennent à 0.

   Pour que les numéros de séquence prennent adéquatement en charge la détection des répétitions, ils devraient être non-répétitifs, même à travers les frontières de connexion. Le numéro de séquence initiale devrait être aléatoire et uniformément distribué à travers l'espace complet des numéros de séquence possibles, de sorte qu'il ne puisse pas être deviné par un agresseur et de sorte que lui et les numéros de séquence successifs ne répètent pas d'autres séquences. Au cas où plus de 2^32 messages devraient être générés dans une série de message KRB_PRIV ou KRB_SAFE, un changement de clé devrait être effectué avant que les numéros de séquence soient réutilisés avec la même clé de chiffrement.

authorization-data Ce champ est décrit au paragraphe ticket. il est optionnel et n'apparaît que lorsque des restrictions supplémentaires sont à mettre à l'utilisation d'un ticket, au-delà de celles portées par le ticket lui-même.

Définition de KRB_AP_REP

   Le message KRB_AP_REP contient le numéro de version du protocole Kerberos, le type de message, en un timestamp chiffré. Le message est envoyé en réponse à une demande d'application ( KRB_AP_REQ ) pour laquelle l'option d'authentification mutuelle a été choisie dans le champ ap-options.


AP-REP ::= [APPLICATION 15] SEQUENCE {
    vno     [0] INTEGER (5),
    sg-type    [1] INTEGER (15),
    nc-part    [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
    time    [0] KerberosTime,
    usec    [1] Microseconds,
    ubkey    [2] EncryptionKey OPTIONAL,
    eq-number    [3] UInt32 OPTIONAL
}

nc-part La partie codée EncAPRepPart est chiffrée avec la clé de session partagée du ticket. Le champ de sous-clé facultatif peut être utilisé dans une négociation arrangée par l'application pour choisir une clé de session par association.
pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REP
enc-part Décrits dans KRB_KDC_REQ. Est calculé avec une valeur d'utilisation de clé de 12
ctime Heure courant sur l'hôte du client
cusec partie micro-seconde du timestamp
subkey Contient une clé de chiffrement à utiliser pour protéger cette session d'application spécifique.
seq-number Décrit au paragraphe ticket

Spécification du message KRB_SAFE

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par l'un ou l'autre côté ( client ou serveur ) d'une application pour envoyer un message inaltérable à son homologue. Il suppose qu'une clé de session ait été échangée précédemment. Le message KRB_SAFE contient des données d'utilisateur avec une somme de contrôle à l'épreuve des collisions chiffrée avec la dernière clé de chiffrement négociée via des sous-clés, ou avec la clé de session si aucune négociation n'est intervenue.

Les champs de message sont les suivants:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (20),
    safe-body    [2] KRB-SAFE-BODY,
    cksum    [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
    user-data    [0] OCTET STRING,
    timestamp    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress,
    r-address    [5] HostAddress OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_SAFE
safe-body Ce champ est un fourre tout pour le corps du message KRB_SAFE
cksum Ce champ contient le checksum des données d'application, calculée avec une valeur d'utilisation de clé de 15. La somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. D'abord, le cksum est mis à un type zéro, valeur de longueur zéro, et la somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. Puis la somme de contrôle est réglée au résultat de ce calcul. Finalement, la séquence KRB-SAFE est codée à nouveau.
user-data Ce champ fait partie des messages KRB_SAFE et KRB_PRIV, et contient les données spécifiques de l'application qui sont passées de l'envoyeur au receveur.
timestamp Ce champ fait partie des messages KRB_SAFE et KRB_PRIV. Heure courante le l'émetteur.
usec partie micro-seconde du timestamp
seq-number Ce champ est décrit au paragraphe ticket
s-address Spécifie l'adresse utilisée par l'eméteur du message
r-address Spécifie l'adresse utilisée par le receveur du message. Il peut être omis pour certaines utilisations ( comme les protocoles de diffusion ), mais le receveur peut arbitrairement rejeter de tels messages. Ce champ, avec s-address, peut être utilisé pour aider à détecter des messages qui on été incorrectement ou malicieusement délivrés à un mauvais receveur.

Spécification du message KRB_PRIV

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par un client et un serveur d'application pour envoyer en toute sécurité et confidentialité un message à son homologue. Il suppose qu'une clé de session ait précédemment été échangée (par exemple, en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_PRIV contient des données d'utilisateur chiffrées avec la clé de session.

Les champs de messages sont les suivant:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type [1] INTEGER (21), -- NOTE : Il n'y a pas d'étiquette [2]
    enc-part    [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
    user-data    [0] OCTET STRING,
    horodatage    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress -- adresse de l'envoyeur
    r-address    [5] HostAddress OPTIONAL -- adresse du receveur
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
enc-part Ce champ détient un codage de la séquence EncKrbPrivPart chiffrée avec le clé de session, avec une valeur d'utilisation de clé de 13. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-PRIV
user-data, horodatage, usec, s-address, et r-address Décrits dans KRB_SAFE
seq-number Décrits dans la section ticket

Spécification du message KRB_CRED

   Ce paragraphe spécifie le format d'un message qui peut être utilisé pour envoyer des accréditifs Kerberos d'un principal à un autre. Il est présenté ici pour encourager l'utilisation d'un mécanisme commun par les applications lors de la transmission des tickets ou la fourniture de mandataires aux serveurs subordonnées. Il suppose qu'une clé de session a déjà été échangée, peut-être en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_CRED contient une séquence de tickets à envoyer et les informations nécessaires pour utiliser les tickets, comportant la clé de session de chacun. Les informations nécessaires pour utiliser les tickets sont chiffrées avec une clé de chiffrement échangée précédemment ou transférée à l'aide du message KRB_CRED.

Les champs de message sont les suivants:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (22),
    tickets    [2] SEQUENCE OF Ticket,
    enc-part    [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
    ticket-info    [0] SEQUENCE OF KrbCredInfo,
    nonce    [1] UInt32 OPTIONAL,
    timestamp    [2] KerberosTime OPTIONAL,
    usec    [3] Microseconds OPTIONAL,
    s-address    [4] HostAddress OPTIONAL,
    r-address    [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
    key    [0] EncryptionKey,
    prealm    [1] Realm OPTIONAL,
    pname    [2] PrincipalName OPTIONAL,
    flags    [3] TicketFlags OPTIONAL,
    authtime    [4] KerberosTime OPTIONAL,
    starttime    [5] KerberosTime OPTIONAL,
    endtime    [6] KerberosTime OPTIONAL,
    renew-till    [7] KerberosTime OPTIONAL,
    srealm    [8] Realm OPTIONAL,
    sname    [9] PrincipalName OPTIONAL,
    caddr    [10] HostAddresses OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
tickets Ce sont les tickets obtenus du KDC pour utilisation spécifique par le receveur. Les tickets successifs sont appariés avec la séquence KrbCredInfo correspondante de enc-part du message KRB-CRED
enc-part Ce champ étient un codage de la séquence EncKrbCredPart chiffrée avec la clé de session partagée par l'envoyeur et le receveur prévu, avec une valeur d'utilisation de 14. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-CRED.
nonce Si elle en a la capacité, une application peut exiger l'inclusion d'un nom occasionnel généré par le receveur du message.Si la même valeur est incluse comme nom occasionnel danse le message, cela donne la preuve que le message est frais et n'a pas été répété par un agresseur.
timestamp et usec Ces champs spécifient l'heure à laquelle le message KRB-CRED a été généré. L'heure est utilisée pour fournir l'assurance que le message est frais.
s-address et r-address Décrit dans KRB_SAFE
key Ce champ existe dans le ticket correspondant passé par le message KRB-CRED et est utilisé pour passer la clé de session de l'envoyeur au destinataire prévu.
prealm et pname facultatifs. Nom et domaine de l'entité de principal délégué.
lags, authtime, starttime, endtime, renew-till, srealm, sname, et caddr facultatifs. Ces champs contiennent les valeurs des champs correspondants dans le ticket trouvé dans le champ ticket. Les descriptions des champs sont identiques aux descriptions dans le messages KDC-REP.

Spécification du message KRB_ERROR

   Ce paragraphes spécifie le format du message KRB_ERROR. Les champs inclus dans le message sont destinés à retourner autant d'informations que possible sur l'erreur. On ne s'attend pas à ce que toutes les informations exigées par les champs soient disponibles pour tous.les types d'erreur. Si les informations appropriées ne sont pas disponibles lors de la composition du message, le champ correspondant sera laissé de côté pour ce message. Noter que comme le message KRB_ERROR n'est pas protégé en intégrité, il est assez possible à un attaquant de le synthétiser ou le modifier. En particulier, cela signifie que le client ne devrait pas utiliser ces champs dans ce message pour des besoins critiques pour la sécurité, comme le réglage d'une horloge système ou la génération d'un authentifiant frais. Le message peut cependant être utile pour informer un utilisateur des raisons d'un échec.

Les champs de message sont les suivants:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (30),
    ctime    [2] KerberosTime OPTIONAL,
    cusec    [3] Microseconds OPTIONAL,
    stime    [4] KerberosTime,
    susec    [5] Microseconds,
    error-code    [6] Int32,
    crealm    [7] Realm OPTIONAL,
    cname    [8] PrincipalName OPTIONAL,
    realm    [9] Realm -- domaine du service --,
    sname    [10] PrincipalName -- domaine du service --,
    e-text    [11] KerberosString OPTIONAL,
    e-data    [12] OCTET STRING OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_ERROR
ctime et cusec Ces champs sont décris dans KRB_AP REP.Si les valeurs de ces champs sont connues de l'entité qui génère l'erreur, ils devraient être remplis dans la KRB-ERROR. Se les valeurs ne sont pas disponibles, ces champs peuvent être omis.
stime Ce champ contient l'heure en cours au serveur. Il est du type KerberosTime.
susec Ce champ contient la partie microseconde du timestamp.
error-code Ce champ contient le code d'erreur retourné par Kerberos ou le serveur.
crealm et cname Ces champs sont décrit au paragraphe ticket. Lorsque l'entité qui génère l'erreur connaît ces valeur, elle devraient être remplies dans le KRB-ERROR. Si les valeurs ne sont pas connues, les champs crealm et cname devraient être omis.
realm et sname Ces champs sont décrits dans le paragraphe ticket
e-text Ce champ contient du texte supplémentaire pour aider à expliquer le code d'erreur associé à l'échec de demande.
e-data Ce champ contient des données supplémentaires sur l'erreur à utiliser par l'application. Si le codes d'erreur est KDC_ERR_PREAUTH_REQUIRED, le champ e-data contiendra alors un odage de la séquence des champs padata, chacun correspondant à une méthode acceptable de pré-authentification et contenant facultativement des données pour la méthode: METHOD-DATA ::= SEQUENCE OF PA-DATA

   Pour les codes d'erreur définis dans le présent document autres que KDC_ERR_PREAUTH_REQUIRED, le format et le contenu du champ e-data sont définis par l'implémentation. De même, pour les codes d'erreur futurs, le format et le contenu du champ e-data sera défini par l'implémentation sauf spécification contraire. Qu'ils soient définis par l'implémentation ou dans un document futur, le champ e-data peut prendre la forme de TYPED-DATA:


TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    data-type    [0] Int32,
    data-value    [1] OCTET STRING OPTIONAL
}

Tag Number d'application

   Le tableau suivant fait la liste des numéros d'étiquette de classe d'application utilisés par divers type de données définies dans ce paragraphe:

tag Number - (type name) - commentaires
0 non utilisé
1 (Ticket) PDU
2 (Authenticator) non PDU
3 (EncTicketPart) non PDU
4-9 non utilisé
10 (AS-REQ) PDU
11 (AS-REP) PDU
12 (TGS-REQ) PDU
13 (TGS-REP) PDU
14 (AP-REQ) PDU
15 (AP-REP) PDU
16 (RESERVED16) TGT-REQ (d'utilisateur à utilisateur)
17 (RESERVED17) TGT-REQ (d'utilisateur à utilisateur)
18-19 non utilisé
20 (KRB-SAFE) PDU
21 (KRB-PRIV) PDU
22 (KRB-CRED) PDU
23-24 non utilisé
25 (EncASRepPart) non PDU
26 (EncTGSRepPart) non PDU
27 (EncApRepPart) non PDU
28 (EncKrbPrivPart) non PDU
29 (EncKrbCredPart) non PDU
30 (KRB-ERROR) PDU

   Les types ASN.1 marqués ci-dessus comme PDU sont les seuls types ASN.1 perçus comme types de niveau supérieur dans le protocole Kerberos, et sont les seuls types qui peuvent être utilisés comme éléments dans un autre protocoles qui utilise Kerberos.

Noms de domaine

   Bien que les noms de domaine soient codés comme des GeneralStrings et que techniquement un domaine puisse choisir le nom qu'il veut, l'intéropérabilité à travers les frontières de domaine exige un accord sur la façon dont les noms de domaine sont alloués et les informations qu'ils comportent.

   Pour mettre en application ces conventions, chaque domaine doit se conformer aux conventions elles-mêmes, et il doit exiger que tout domaine avec lequel il partage des clés inter-domaine se conforme aussi aux conventions et qu'il exige la même chose de ses voisins.

   Les noms de domaine Kerberos sont sensibles à la casse. Les noms de domaine qui ne diffèrent que par la casse des caractères ne sont pas équivalents. Il y a actuellement 3 styles de noms de domaine: domaine, X500, et autre:

domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
autre: NAMETYPE:rest/of.name=without-restrictions

   Les noms de style domaine doivent ressembler à des noms de domaine: Ils comportent des composants séparés par des points et ils ne contiennent ni ":" ni "/". Bien que les noms de domaine eux-mêmes ne soient pas sensibles à la casse, afin que les domaines correspondent, la casse doit aussi correspondre. Lors de l'établissement d'un nouveau nom de domaine fondé sur un nom de domaine internet, il est recommandé par convention que les caractères soient convertis en majuscules.

   Les noms X.500 contiennent le signe égal et ne peuvent pas contenir ":" avant le signe égal. Les noms de domaine pour les noms X.500 doivent être des représentations de chaîne des noms avec des composants séparés par des barres obliques. Les barres obliques en tête et en queue ne seront pas incluses. Noter que la barre oblique de séparation est cohérente avec les implémentations de Kerberos fondées sur la rfc1510, mais elle est différente du séparateur recommandé dans la rfc2253.

   Les noms qui entrent dans la catégorie autre doivent commencer par un préfixe ne contenant pas de signe égal ou point, et le préfixe doit être suivi par ":" et le reste du nom. Tous les préfixes attendent ceux qui commencent à être utilisés. Actuellement, aucun n'est alloué.

   La catégorie réservée comporte des chaînes qui n'entrent pas dans les 3 premières catégories. Tous les noms de cette catégorie sont réservés. Il est peut vraisemblable que des noms soient alloués dans cette catégorie sauf s'il y a de très forts arguments pour ne pas utiliser la catégorie autre.

   Ces règles garantissent qu'il n'y aura pas de conflit entre les divers styles de nom. Les contraintes supplémentaires suivantes s'appliquent à l'allocation de noms de domaine dans les catégories domaine et X.500: le nom d'un domaine pour les formats domaine ou X.500 doit être utilisé par l'organisation propriétaire d'un nom de domaine Internet ou d'un nom X.500, ou, dans le cas où un tel nom n'est pas enregistré, l'autorité pour utiliser un nom de domaine peut être dérivé de l'autorité du domaine parent. Par exemple, s'il n'y a pas de nom de domaine pour E40.MIT.EDU, l'administrateur du domaine MIT.EDU peut alors autoriser la création d'un domaine de ce nom.

   Ceci est acceptable parce que l'organisation à laquelle le parent est alloué est vraisemblablement aussi l'organisation autorisée à allouer des noms à ses enfants dans les systèmes de nom X.500 et domaine. Si le parent alloue un nom de domaine sans l'enregistrer aussi dans la hiérarchie de nom de domaine ou X.500, il est de la responsabilité du parent de s'assurer qu'à l'avenir il n'existe pas un nom identique au nom de domaine de l'enfant sauf s'il est alloué à la même entité comme nom de domaine.

Noms de principal

   Comme c'est le cas pour les noms de domaine, des conventions sont nécessaires pour s'assurer que tous sont d'accord sur les information impliquées par un nom de principal. Le champ name-type qui fait partie du nom de principal indique le type d'informations impliquées par le nom. Le name-type devrait être traité que comme un conseil pour interpréter la signification d'un nom. Il n'y a pas de sens à lui rechercher une équivalence. Les noms de principal qui ne diffèrent que par le name-type identifient le même principal. Le type de nom ne crée pas une partition de l'espace de nom. En ignorant le type de nom, 2 noms ne peuvent être les mêmes. Les types de nom suivants sont définis:

NT-UNKNOWN (0) Type de nom inconnu
NT-PRINCIPAL (1) Seulement le nom du principal comme dans DCE, ou pour les utilisateurs
NT-SRV-INST (2) Service et autre instance unique (krbtgt)
NT-SRV-HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
NT-SRV-XHST (4) Service avec hôte comme composants restants
NT-UID (5) ID unique
NT-X500-PRINCIPAL (6) Nom distinctif codé en X.509 [RFC2253]
NT-SMTP-NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple,user@example.com)
NT-ENTERPRISE (10) Nom d'entreprise - peut être transposé en nom de principal

   Lorsqu'un nom n'implique pas d'informations autres que son unicité à un moment particulier, le type de nom PRINCIPAL devrait être utilisé pour les utilisateurs, et il peut aussi être utilisé pour un serveur unique. Si le nom est un ID unique généré par la machine qu'il est garanti n'être jamais ré-alloué, le type de nom d'UID devrait alors être utilisé.

   Si le premier composant d'un nom identifie un service et si des composants restants identifient une instance du service d'un manière spécifiée par le serveur, le type de nom de SRV-INST devrait alors être utilisé. Un exemple de ce type de nom est le TGS dont le nom a un premier composant de krbtgt et un second composant identifiant le domaine pour lequel le ticket est valide.

   Si le premier composant d'un nom identifie un service et qu'il y a un seul composant suivant le nom de service qui identifie l'instance comme l'hôte sur lequel fonctionne le serveur, le type de nom SRV-HST devrait être utilisé. Ce type est normalement utilisé pour les services Internet tels que telnet et les commandes R de Berkeley. Si les composants séparés du nom de l'hôte apparaissent comme des composants successifs qui suivent le nom du service, le type de nom SRV-XHST devrait être utilisé. Ce type peut être utilisé pour identifier les serveurs sur des hôtes qui ont des noms X.500, et où "/" pourrait être ambiguë.

   Un type de nom NT-X500-PRINCIPAL devrait être utilisé lorsqu'un nom provenant d'un certificat X.509 est traduit en un nom Kerberos. Le codage du nom X.509 comme un principal de Kerberos doit être conforme aux règles de codage spécifiées dans la rfc2253.

   Un type de nom de SMTP permet à un nom d'être d'un forme qui ressemble à un nom de messagerie électronique SMTP. Ce nom, comportant un @ et un nom de domaine, est utilisé comme premier composant du nom de principal.

   Un type de nom de UNKNOWN devrait être utilisé lorsque la forme du nom n'est pas connue. Lors d'une comparaison des nom, un type de nom UNKNOWN correspondra aux principaux authentifiés avec des noms de tout type. Un principal authentifié avec un type de nom de UNKNOWN ne correspondra cependant qu'à d'autres noms de type UNKNOWN.

   Les noms de tout type avec un composant initial de krbtgt sont réservés pour le TGS.

Nom des principaux de serveur

   L'identifiant de principal pour un serveur sur un hôte sera généralement composé de 2 parties: Le domaine du KDC avec lequel le serveur est enregistré, et un nom à 2 composants NT-SRV-HST, si le nom d'hôte est un nom de domaine Internet, ou un nom multi-composants de type NT-SRV-XHST, si le nom de l'hôte est d'une forme qui permet "/" comme séparateurs. Le premier composant du nom à deux ou plusieurs composants va identifier le service, et les derniers composants vont identifier l'hôte. Lorsque le nom de l'hôte n'est pas sensible à la casse, le nom de l'hôte doit être en minuscule. Si c'est spécifié par le protocole d'application pour des services tels que telnet et les commandes R de Berkeley qui fonctionnent avec des privilèges de système, le premier composant peut être la chaîne host au lieu d'un identifiant spécifique du service.

Types d'adresse d'hôte

   Toutes les valeurs négatives pour le type d'adresse d'hôte sont réservées à une utilisation locale. Toutes les valeurs non négatives sont réservées aux champs et interprétations de type officiellement alloués.

Adresses Internet (IPv4) Les adresses Internet sont des quantités de 32bits codées dans l'ordre MSB. Une adresse IPv4 de bouclage ne devrait pas apparaître dans un PDU Kerberos. Le type des adresses IPv4 est (2)
Adresses Internet (IPv6) Les adresses IPv6 sont des guantités de 128bits codées danfs l'ordre MSB. Le type des adresses IPv6 est (24). Les adresses suivantes ne doivent pas apparaître dans un PDU Kerberos: l'adresse non spécifiée, la loopback, les adresses de lien locaux.

   Ces restrictions s'appliquent à l'inclusion dans les champs d'adresse des PDU, mais pas aux champs d'adresse des paquets qui pourraient porter ces PDU. La restriction est nécessaire parce que l'utilisation d'une adresse d'une portée non mondial pourrait permettre l'acceptation d'un message envoyé à partir d'un nœud qui pourrait avoir la même adresse, mais qui ne serait par l'hôte prévu. Si le type d'adresse local doit être utilisé pour une communication, la restriction d'adresse dans les tickets ne doit pas être utilisée. Les adresses IPv6 transposées en IPv4 doivent être représentées comme adresses de type 2.

Adresses DECnet de Phase IV Les adresses DECnet de Phase IV sont des adresses de 16 bits, codées dans l'ordre LSB. Le type des adresses DECnet de Phase IV est (12).
Adresses Netbios Les adresses Netbios sont des adresses de 16 octets normalement composées de caractères alphanumériques de 1 à 15 et complétées avec le caractère US-ASCII SPC (code 32). Le 16ème octet DOIT être le caractère US-ASCII NUL (code 0). Le type des adresses Netbios est (20)

Adresses directionnelles Inclure l'adresse de l'émetteur dans les messages KRB_SAFE et KRB_PRIV n'est pas souhaitable dans de nombreux environnements parce que les adresses peuvent être changées dans le transport par des traducteurs d'adresse réseau. Cependant, si ces adresses sont retirées les messages peuvent être soumis à une attaque par réflexion dans laquelle un message est répliqué en retour à son origine. Le type d'adresse directionnelle donne le moyen d'éviter les attaques des adresses dans le transport et en réflexion. Les adresses directionnelles sont codées comme des entiers non signés de 4 octets dans l'ordre des octets du réseau. Si le message est généré par la pratie qui envoie le message KRB_AP_REQ original, une adresse de 0 devrait être utilisé. Les applications qui impliquent plusieurs parties peuvent spécifier l'utilisation des autres adresses.

   Les adresses directionnelles doivent être utilisées uniquement pour le champ d'adresse d'envoyeur dans les messages KRB_SAFE ou KRB_PRIV. Elles no doivent pas être utilisées comme adresse de ticket ou dans un message KRB_AP_REQ. Ce type d'adresse devrait être utilisé seulement dans des situations où la partie qui envoie sait que la partie qui reçoit prend en charge le type d'adresse. Cela signifie généralement que les adresses directionnelles ne peuvent être utilisée que quand le protocoles d'application exige leur prise en charge. Les adresses directionnelles dont du type (3)

Échange de messages KDC: transports IP

   Kerberos définis 2 mécanismes de transport IP pour communiquer entre clients et serveurs: UDP/IP et TCP/IP.

UDP/IP

   Les KDC qui prennent en charge les transport IP doivent accepter les demandes UDP et devraient les écouter sur le port 88. Des accès de remplacement peuvent être utilisés quand plusieurs KDC fonctionnent sur plusieurs domaines sur le même hôte.

   Les clients Kerberos qui prennent en charge les transports IP devraient prendre en charge l'envoi des demandes UDP. Les client devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils veulent envoyer leur demande.

   Lorsqu'il contacte un KDC pour un KRB_KDC_REQ en utilisant UDP, le client doit envoyer un UDP ne contenant qu'un codage de la demande au KDC. Le KDC répondra avec un datagramme contenant seulement un encodage de la réponse (soi un KRB_ERROR, soit un KRB_KDC_REP) à l'adresse IP de l'envoyeur. La réponse à une demande faite au moyen d'un transport UDP/IP doit aussi utiliser le transport UDP. Si la réponse ne peut être traitée en utilisant UDP (par exemple, parce qu'elle est trop grande), le KDC doit retourner KRB_ERR_RESPONSE_TOO_BIG, forçant le client à réessayer la demande en utilisant le transport TCP.

TCP/IP

   Les KDC qui prennent en charge les transports IP doivent accepter les demandes TCP et devraient les écouter sur le port 88. Les clients doivent prendre en charge l'envoi des demandes TCP, mais peuvent choisir d'essayer une demande en utilisant initialement le transport UDP. Les clients devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils enverront leur demande.

   Lorsque le message KRB_KDC_REQ est envoyé au KDC sur un flux TCP, la réponse doit être retournées au client sur le même flux TCP qui était établis pour le demandes. Le KDC peut fermer le flux TCP après avoir envoyé une réponse, mais peut laisser le flux ouvert pendant une durées raisonnable s'il attend une suite. Il faut veiller, dans la gestion des connexions TCP avec le KDC, à empêcher les attaques DOS fondées sur le nombre de connexions TCP ouvertes.

   Le client doit être prêt à voir le flux fermé par le KDC à tout moment après la réception d'une réponse. Une clôture de flux ne devrait pas être traitée comme une erreur fatale. Plutôt, si plusieurs échanges sont exigés (par exemple, par certaines formes de pré-authentification), le client peut avoir besoin d'établir une nouvelle connexion quand il est prêt à envoyer les messages suivants. Un client peut clore le flux après réception d'une réponse, et devrait clore le flux s'il ne prévoit pas d'envoyer de messages de suite.

   Un client peut envoyer plusieurs demandes avant de recevoir des réponses, bien qu'il doive être prêt à traiter la fermeture de la connexion après la première réponse.

   Chaque demande (KRB_KDC_REQ) et réponse (KRB_KDC_REP ou KRB_ERROR) envoyée sur le flux TCP est précédée par la longueur de la demande en 4 octets dans l'ordre des octets du réseau. Le MSB de la longueur est réservé à une expansion future et doit actuellement être mis à zéro. Si un KDC qui ne comprend pas comment interpréter un MSB mis dans le codage de longueur, reçoit une demande avec le MSB mis, il doit retourner un message KRB-ERROR avec l'erreur KRB_ERR_FIELD_TOOLONG et doit clore le flux TCP.

Découverte de KDC sur les réseaux IP

   Les implémentations de client Kerberos doivent fournir un moyen pour que le client détermine la localisation des KDC. Traditionnellement, les implémentations Kerberos mémorisent de telles informations de configuration dans un fichier sur chaque machine cliente. L'expérience a montré que cette méthode de mémorisation des informations de configuration pose des problèmes d'informations périmées et d'évaluation, tout particulièrement lors de l'utilisation de l'authentification inter-domaine.

DNS

   Dans Kerberos, les noms de domaine sont sensibles à la casse. Bien qu'il soit fortement recommandé que tous les noms de domaine soient en majuscule, cette recommandation n'a pas été adoptée par tous les sites. Certains sites utilisent des noms tout en minuscules et d'autres utilisent une casse mélangée. DNS, d'un autre côté, est insensible à la casse pour les interrogations.

Spécification de localisation de KDC avec DNS SRV

   Les informations de localisation de KDC sont à mémoriser en utilisant les DNS RR SRV . Le format de ce RR est le suivant:

  _Service._Proto.Realm TTL Class SRV Priority Weight Port Target

  Le proto peut être udp ou tcp. Si ces enregistrements de SRV doivent être utilisé, les enregistrements upd et tcp doivent tous 2 être spécifiés pour tous les développements de KDC. Le Realm est de domaine Kerberos auquel cet enregistrement correspond. Le domaine doit être un nom de domaine de style domaine. TTL, Class, SRV, Priority, Weight et Target ont la signification standar définis dans la rfc2782.

   Conformément à cette rfc, le numéro de port utilisé pour les enregistrement de SRV "_udp" et "_tcp" devraient être la valeur allouée à "kerberos" par l'IANA: 88, sauf si le KDC est configuré pour écouter sur un autre accès TCP.

Découverte de KDC pour les Realms name stype domaine

   Ce sont des enregistrement DNS pour un domaine Kerberos EXAMPLE.COM. Il y a 2 serveurs Kerberos kdc1.example.com et kdc2.example.con. Les requêtes devraient d'abord être dirigées sur kdc1.example.com conformément à la priorité spécifée. Les pondérations ne sont pas utilisées dans cet échantillons d'enregistrements.

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.

Nom du TGS

   L'identifiant de principal du TGS doit être composé de 3 parties: le domaine du KDC qui produit les tickets TGS, et un nom en 2 parties du type NT-SRV-INST, dont la première partie est "krbtgt" et la seconde partie est le nom du domaine qui va accepter le TGT. Par exemple, un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour des tickets du KDC ATHENA.MIT.EDU a un identifiant de principal de "ATHENA.MIT.EDU" (domaine), ("krbtgt", "ATHENA.MIT.EDU") (nom). Un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour obtenir des tickets du domaine MIT.EDU a l'identifiant de principal "ATHENA.MIT.EDU" (domaine), ("krbtgt", "MIT.EDU") (nom).

OID pour Kerberosv5

Cet OID peut être utilisé pour identifier les messages de protocoles Kerberos encapsulés dans d'autres protocoles:
id-krb5 OBJECT IDENTIFIER ::= {
    iso(1) identified-organisation(3) dod(6) internet(1) security(5) kerberosV5(2)
}

Constantes du protocole et valeurs associées

   Les tableaux qui suivent font la liste des constantes utilisées dans le protocole et définissent leur signification. Dans la partie "spécification" sont spécifiés les gammes qui limitent les valeurs des constantes pour lesquelles les valeurs sont définies ici.

Valeurs d'utilisation de clé

   La spécification du chiffrement et de checksum exige en entrée un numéro d'utilisation de clé, pour altérer la clé de chiffrement utilisée dans tout message spécifique afin de rendre plus difficiles certains types d'attaques.

1. timestamp padata AS-REQ PA-ENC-TIMESTAMP, chiffré avec la clé de client
2. Tickets AS-REP et TGS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrés avec la clé de service
3. Partie chiffrée de AS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrée avec la clé de client
4. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la clé de session TGS
5. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la sous-clé d'authentifiant TGS
6. Somme de contrôle d'authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ, frappée avec la clé de session TGS
7. Authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ (inclut la sous-clé d'authentifiant de TGS), chiffré avec la clé de session TGS
8. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la clé de session TGS
9. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la sous-clé d'authentifiant de TGS
10. Somme de contrôle d'authentifiant AP-REQ, frappée avec la clé de session d'application
11. Authentifiant AP-REQ (inclut la sous-clé d'authentifiant d'application), chiffré avec la clé de session d'application
12. Partie chiffrée de AP-REP (inclut la sous-clé de session d'application), chiffré avec la clé de session d'application
13. Partie chiffrée de KRB-PRIV, chiffrée avec une clé choisie par l'application
14. Partie chiffrée de KRB-CRED, chiffrée avec une clé choisie par l'application
15. Somme de contrôle KRB-SAFE, frappé avec une clé choisie par l'application
16-18. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
19. Somme de contrôle AD-KDC-ISSUED (ad-checksum)
20-21. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
22-25. Réservés à une utilisation future dans les mécanismes GSS-API de Kerberos Version 5 [RFC4121].
26-511. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
512-1023. Réservés à des utilisations internes à une mise en œuvre Kerberos.
1024. Chiffrement à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés.
1025. Sommes de contrôle à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés
1026-2047. Réservé à l'usage d'application.

Types de données de pré-authentification

Padata et type de données (Padata-type) Commentaire
PA-TGS-REQ (1)
PA-ENC-TIMESTAMP (2)
PA-PW-SALT (3)
[reserved] (4)
PA-ENC-UNIX-TIME (5) déconseillé
PA-SANDIA-SECUREID (6)
PA-SESAME (7)
PA-OSF-DCE (8)
PA-CYBERSAFE-SECUREID (9)
PA-AFS3-SALT (10)
PA-ETYPE-INFO (11)
PA-SAM-CHALLENGE (12) sam/otp
PA-SAM-RESPONSE (13) sam/otp
PA-PK-AS-REQ_OLD (14) pkinit
PA-PK-AS-REP_OLD (15) pkinit
PA-PK-AS-REQ (16) pkinit
PA-PK-AS-REP (17) pkinit
PA-ETYPE-INFO2 (19) remplace pa-etype-info
PA-USE-SPECIFIED-KVNO (20)
PA-SAM-REDIRECT (21) sam/otp
PA-GET-FROM-TYPED-DATA (22) incorporé dans typed-data
TD-PADATA (22) incorpore padata
PA-SAM-ETYPE-INFO (23) sam/otp
PA-ALT-PRINC (24) crawdad@fnal.gov
PA-SAM-CHALLENGE2 (30) kenh@pobox.com
PA-SAM-RESPONSE2 (31) kenh@pobox.com
PA-EXTRA-TGT (41) Réservé extra TGT
TD-PKINIT-CMS-CERTIFICATES (101) CertificateSet du CMS
TD-KRB-PRINCIPAL (102) PrincipalName
TD-KRB-REALM (103) Domaine
TD-TRUSTED-CERTIFIERS (104 de PKINIT
TD-CERTIFICATE-INDEX (105) de PKINIT
TD-APP-DEFINED-ERROR (106) spécifique de l'application
TD-REQ-NONCE (107) ENTIER
TD-REQ-SEQ (108) ENTIER
PA-PAC-REQUEST (128) jbrezak@exchange.microsoft.com

Types d'adresse

IPv4 2
Directionnelle 3
ChaosNet 5
XNS 6
ISO 7
DECNET Phase IV 12
AppleTalk DDP 16
NetBios 20
IPv6 24

Types de données d'autorisation

Types de données d'autorisation Valeur de Ad-type
AD-IF-RELEVANT 1
AD-INTENDED-FOR-SERVER 2
AD-INTENDED-FOR-APPLICATION-CLASS 3
AD-KDC-ISSUED 4
AD-AND-OR 5
AD-MANDATORY-TICKET-EXTENSIONS 6
AD-IN-TICKET-EXTENSIONS 7
AD-MANDATORY-FOR-KDC 8
Valeurs réservées 9-63
OSF-DCE 64
SESAME 65
AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com)

Types de codages de transit

Type de codage traversé Valeur de Tr-type
DOMAIN-X500-COMPRESS 1
Valeurs réservées Toutes les autres

Numéro de version du protocole

pvno (5) Numéro de version en cours du protocole Kerberos

Types de message Kerberos

KRB_AS_REQ (10) Demande d'authentification initiale
KRB_AS_REP (11) Réponse à demande KRB_AS_REQ
KRB_TGS_REQ (12) Demande d'authentification fondée sur un TGT
KRB_TGS_REP (13) Réponse à demande KRB_TGS_REQ
KRB_AP_REQ (14) Demande d'application au serveur
KRB_AP_REP (15) Réponse à KRB_AP_REQ_MUTUAL
KRB_RESERVED16 (16) Réservé à une demande krb_tgt_request d'usager à usager
KRB_RESERVED17 (17) Réservé à une réponse krb_tgt_reply d'usager à usager
KRB_SAFE (20) Message d'application sûr (avec somme de contrôle)
KRB_PRIV (21) Message d'application privé (chiffré)
KRB_CRED (22) Message privé (chiffré) pour transmission d'accréditifs
KRB_ERROR (30) Réponse d'erreur

Types de noms

KRB_NT_UNKNOWN (0) Type de nom inconnu
KRB_NT_PRINCIPAL (1) Juste le nom du principal comme dans DCE, ou pour utilisateurs
KRB_NT_SRV_INST (2) Service et autre instance unique (krbtgt)
KRB_NT_SRV_HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
KRB_NT_SRV_XHST (4) Service avec hôte comme composants restants
KRB_NT_UID (5) ID unique
KRB_NT_X500_PRINCIPAL (6) Nom distinctif X.509 codé [RFC2253]
KRB_NT_SMTP_NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple, user@example.com)
KRB_NT_ENTERPRISE (10) Nom d'entreprise; peut être transposé en nom de principal

Codes d'erreur

KDC_ERR_NONE (0) Pas d'erreur
KDC_ERR_NAME_EXP (1) L'entrée du client dans la base de données a expiré
KDC_ERR_SERVICE_EXP (2) L'entrée du serveur dans la base de données a expiré
KDC_ERR_BAD_PVNO (3) Numéro de version du protocole demandé non accepté
KDC_ERR_C_OLD_MAST_KVNO (4) La clé du client est chiffrée avec la vieille clé maîtresse
KDC_ERR_S_OLD_MAST_KVNO (5) La clé du serveur est chiffrée avec la vieille clé maîtresse
KDC_ERR_C_PRINCIPAL_UNKNOWN (6) Client non trouvé dans la base de données Kerberos
KDC_ERR_S_PRINCIPAL_UNKNOWN (7) Serveur non trouvé dans la base de données Kerberos
KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) Plusieurs entrées du principal dans la de données
KDC_ERR_NULL_KEY (9) Le client ou le serveur a une clé nulle
KDC_ERR_CANNOT_POSTDATE (10) Ticket non éligible au postdatage
KDC_ERR_NEVER_VALID (11) Heure de début demandée postérieure à l'heure de fin
KDC_ERR_POLICY (12) La politique du KDC rejette la demande
KDC_ERR_BADOPTION (13) Le KDC ne peut pas traiter l'option demandée
KDC_ERR_ETYPE_NOSUPP (14) Le KDC ne prend pas en charge le type de chiffrement
KDC_ERR_SUMTYPE_NOSUPP (15) Le KDC n'accepte pas le type de somme de contrôle
KDC_ERR_PADATA_TYPE_NOSUPP (16) Le KDC ne prend pas en charge le type de padata
KDC_ERR_TRTYPE_NOSUPP (17) Le KDC ne prend pas en charge le type transité
KDC_ERR_CLIENT_REVOKED (18) Les accréditifs du client ont été révoqués
KDC_ERR_SERVICE_REVOKED (19) Les accréditifs du serveur ont été révoqués
KDC_ERR_TGT_REVOKED (20) Le TGT a été révoqué
KDC_ERR_CLIENT_NOTYET (21) Client pas encore valide ; réessayer plus tard
KDC_ERR_SERVICE_NOTYET (22) Serveur pas encore valide ; réessayer plus tard
KDC_ERR_KEY_EXPIRED (23) Mot de passe expiré ; changer le mot de passe pour recommencer
KDC_ERR_PREAUTH_FAILED (24) Informations de pré-authentification invalides
KDC_ERR_PREAUTH_REQUIRED (25) Pré-authentification supplémentaire exigée
KDC_ERR_SERVER_NOMATCH (26) Le serveur demandé et le ticket ne correspondent pas
KDC_ERR_DOIIVENT_USE_USER2USER (27) Principal de serveur valide seulement d'usager à usager
KDC_ERR_PATH_NOT_ACCEPTED (28) La politique du KDC rejette le chemin de transit
KDC_ERR_SVC_UNAVAILABLE (29) Un service n'est pas disponible
KRB_AP_ERR_BAD_INTEGRITY (31) Échec de vérification d'intégrité sur le champ déchiffré
KRB_AP_ERR_TKT_EXPIRED (32) Ticket expiré
KRB_AP_ERR_TKT_NYV (33) Ticket pas encore valide
KRB_AP_ERR_REPEAT (34) La demande est une répétition
KRB_AP_ERR_NOT_US (35) Le ticket n'est pas pour nous
KRB_AP_ERR_BADMATCH (36) Ticket et authentifiant ne correspondent pas
KRB_AP_ERR_SKEW (37) Biais d'horloge trop grand
KRB_AP_ERR_BADADDR (38) Adresse réseau incorrecte
KRB_AP_ERR_BADVERSION (39) Discordance de version de protocole
KRB_AP_ERR_MSG_TYPE (40) Type de message invalide
KRB_AP_ERR_MODIFIED (41) Flux de message modifié
KRB_AP_ERR_BADORDER (42) Message pas à son ordre
KRB_AP_ERR_BADKEYVER (44) Version de clé spécifiée non disponible
KRB_AP_ERR_NOKEY (45) Clé de service non disponible
KRB_AP_ERR_MUT_FAIL (46) Échec d'authentification mutuelle
KRB_AP_ERR_BADDIRECTION (47) Direction de message incorrecte
KRB_AP_ERR_METHOD (48) Autre méthode d'authentification exigée
KRB_AP_ERR_BADSEQ (49) Numéro de séquence incorrect dans le message
KRB_AP_ERR_INAPP_CKSUM (50) Type de somme de contrôle inapproprié dans le message
KRB_AP_PATH_NOT_ACCEPTED (51) La politique rejette le chemin de transit
KRB_ERR_RESPONSE_TOO_BIG (52) Réponse trop grosse pour UDP ; ressayer avec TCP
KRB_ERR_GENERIC (60) Erreur générique (description dans e-text)
KRB_ERR_FIELD_TOOLONG (61) Le champ est trop long pour cette mise en œuvre
KDC_ERROR_CLIENT_NOT_TRUSTED (62) Réservé pour PKINIT
KDC_ERROR_KDC_NOT_TRUSTED (63) Réservé pour PKINIT
KDC_ERROR_INVALID_SIG (64) Réservé pour PKINIT
KDC_ERR_KEY_TOO_WEAK (65) Réservé pour PKINIT
KDC_ERR_CERTIFICATE_MISMATCH (66) Réservé pour PKINIT
KRB_AP_ERR_NO_TGT (67) Pas de TGT disponible pour valider USER-TO-USER
KDC_ERR_WRONG_REALM (68) Réservé pour utilisation future
KRB_AP_ERR_USER_TO_USER_REQUIRED (69) Le ticket doit être pour USER-TO-USER
KDC_ERR_CANT_VERIFY_CERTIFICATE (70) Réservé pour PKINIT
KDC_ERR_INVALID_CERTIFICATE (71) Réservé pour PKINIT
KDC_ERR_REVOKED_CERTIFICATE (72) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNKNOWN (73) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE (74) Réservé pour PKINIT
KDC_ERR_CLIENT_NAME_MISMATCH (75) Réservé pour PKINIT
KDC_ERR_KDC_NAME_MISMATCH (76) Réservé pour PKINIT

Exigences d'intéropérabilité

   La version 5 du protocole Kerberos accepte une myriade d'options. Parmi celles-ci, plusieurs types de chiffrement et de sommes de contrôle; des schéma de codage de remplacement pour le champ de transit; des mécanismes facultatifs pour la pré-authentification; le traitement de tickets sans adresse; des options pour l'authentification mutuelle; l'authentification d'utilisateur à utilisateur; la prise en change de proxy; le format des noms de domaines; le traitement des données d'autorisation; et la transmission, le post-datage, et le renouvellement de tickets.

   Afin d'assurer l'intéropérabilité des domaines, il est nécessaire de définir une configuration minimale qui doit être prise en charge par toutes les mises en œuvre. Cette configuration minimale est sujette à changement ultérieurs.

Spécification 2

   Ce paragraphe définit la seconde spécification des options. Les implémentations qui sont configurées de cette façon peuvent être considérées comme prenant en charge la spécification 2 de Kerberos v5 (5.2).

Transport Le transport TCP/IP et UDP/IP doivent être pris en charge par les clients et KDC qui revendiquent la conformité à
la spécification 2. Méthodes de chiffrement et de somme de contrôle
Les mécanismes de chiffrement et de somme de contrôle suivants doivent être pris en charge:
Chiffrement: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Somme de contrôle: HMAC-SHA1-96-AES256 [RFC3962]

   Les mises en œuvre devraient aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communicant avec des principaux connus pour les accepter aussi. Les mécanismes suivants provenant de la [RFC3961] et de la [RFC3962] devraient être pris en charge:

Chiffrement: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Somme de contrôle: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

   Les implémentations peuvent aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communication avec des principaux connus pour les accepter aussi.

Noms de domaine Toutes les mises en œuvre doivent comprendre la hiérarchie des domaines à la fois dans le domaine Internet et dans le style X.500. Lorsque est demandé un TGT pour un domaine inconnu, le KDC doit être capable de déterminer les noms des domaines intermédiaires entre le domaine du KDC et le domaine demandé.
Codage de champ de transit DOMAIN-X500-COMPRESS doit être pris en charge. D'autres codages peuvent être acceptés, mais ils ne peuvent être utilisés lorsque ce codage est accepté par tous les domaines intermédiaires.
Méthodes de pré-authentification La méthode TGS-REQ doit être prise en charge. Elle n'est pas utilisée sur la demande initiale. La méthode PA-ENC-TIMESTAMP doit être acceptée par les clients, mais savoir si elle est activée par défaut peut être déterminé domaine par domaine. Si la méthode n'est pas utilisée dans la demande initiale et si l'erreur KDC_ERR_PREAUTH_REQUIRED est retournée, spécifiant PA-ENC-TIMESTAMP comme méthode acceptable, le client devrait ressayer la demande initiale en utilisant la méthode de pré-authentification PA-ENC-TIMESTAMP. Les serveurs n'ont pas besoin de prendre en charge la méthode PA-ENC-TIMESTAMP, mais si elle n'est pas acceptée, le serveur devrait ignorer la présence de la pré-authentification PA-ENC-TIMESTAMP dans une demande.
La méthode ETYPE-INFO2 doit être acceptée; cette méthode est utilisée pour communiquer l’ensemble des types de chiffrement acceptés, et les paramètres correspondants de salt et de string-to-key. La méthode ETYPE-INFO devrait être acceptée pour l’interopérabilité avec les mises en œuvre les plus anciennes.
Authentification mutuelle L’authentification mutuelle (via le message KRB_AP_REP) doit être acceptée.
Adresses et flags de ticket Tous les KDC doivent passer les tickets qui ne portent pas d’adresse (c’est-à-dire que si un TGT ne contient pas d’adresse, le KDC retournera des tickets dérivés). Les mises en œuvre devraient par défaut demander des tickets sans adresse, car cela augmente de façon significative l’interopérabilité avec la traduction d’adresse réseau. Dans certains cas, les domaines ou les serveurs d’application peuvent exiger que les tickets aient une adresse.

   Les mises en œuvre devraient accepter le type d’adresse directionnelle pour les messages KRB_SAFE et KRB_PRIV et devraient inclure des adresses directionnelles dans ces messages quand d’autres types d’adresse ne sont pas disponibles. Les tickets mandataires et transmis doivent être acceptés. Les domaines et serveurs d’application individuels peuvent y régler leur propre politique lorsque de tels tickets seront acceptés. Toutes les implémentations doivent reconnaître les tickets renouvelables et postdatés, mais ils n’ont pas besoin de les mettre réellement en œuvre. Si ces options ne sont pas prises en charge, l’heure de début et l’heure de fin dans le ticket devront spécifier l’entière durée de vie utile d’un ticket. Lorsque un ticket postdaté est décodé par un serveur, toutes les mises en œuvre devront rendre visible la présence du flag postdaté pour le serveur appelant

Authentification d’usager à usager La prise en charge de l’authentification d’usager à usager (via l’option ENC-TKT-IN-SKEY KDC) doit être fournie par les mises en œuvre, mais les domaines individuels peuvent décider au titre de leur politique de rejeter de telles demandes principal par principal ou domaine par domaine.
Données d’autorisation Les mises en œuvre doivent passer tous les sous-champs de données d’autorisation des TGT à tout ticket dérivé sauf si ils sont amenés à supprimer un sous-champ au titre de la définition de ce type de sous-champ enregistré. (Il n’est jamais incorrect de passer sur un sous-champ, et actuellement, aucun type de sous-champ enregistré ne spécifie la suppression au KDC.)
Les mises en œuvre doivent rendre disponible le contenu de tout sous-champ de données d’autorisation au serveur lorsque le ticket est utilisé. Les mises en œuvre ne sont pas obligées de permettre aux clients de spécifier le contenu des champs de données d’autorisation.
Gammes de constantes Toutes les constantes du protocole sont contraintes à des valeurs de 32 bits (signés) sauf contraintes supplémentaires provenant de la définition du protocole. Cette limite est donnée pour permettre aux mises en œuvre de faire des hypothèses sur les valeurs maximales qui seront reçues pour ces constantes. Les mises en œuvre recevant des valeurs hors de ces gammes peuvent rejeter la demande, mais elles doivent se récupérer proprement.

Valeurs de KDC recommandées

Durée de vie minimum 5 minutes
Durée de vie maximum renouvelable 1 semaine
Durée de vie maximum de ticket 1 jour
Biais d’horloge admissible 5 minutes
Adresses vides Admis
proxiable, etc. Admis
^
17 juin 2015

htmlpdflatexmanmd




rfc4210

rfc4210

Protocole de gestion de certificat des infrastructures à clé publique X.509

Introduction

   Ce document décris le protocole de gestion de certificat (CMP) des infrastructures à clé publique X.509. Les messages de protocole sont définis pour la création et la gestion des certificats. Le terme X.509 dans ce document réfère à un certificat X.509v3.

Définition des entités de PKI

   Les entités impliqués dans la gestion de PKI incluent l'entité finale et l'autorité de certification. Une autorité d'enregistrement peut également être utilisé.

Sujet et entités finales

   Le terme "subject" est utilisé ici pour référer à l'entité pour lequel le certificat est fournis, typiquement nommé dans le sujet ou le champ subjectAltName d'un certificat. Quand on souhaite distinguer les outils et/ou logiciels utilisés par le sujet (ex: un module de gestion de certificat local), on utilise le terme "subject equipment". En général, le terme "end entity" (EE), au lieu de "subject" est préféré pour éviter les confusions avec le nom du champ. Il est important de noter que les entités finales n'incluent pas seulement des utilisateurs humains d'applications, mais également les applications elles-mêmes. Ce facteur influence les protocoles que les opérations de gestion de PKI utilisent; par exemple, une application est plus susceptibles de savoir exactement quelles extensions de certificat sont nécessaires que ne le sont les utilisateurs humains.

   Les entités de gestion de PKI sont également des entités finales dans le sens qu'ils sont parfois nommés dans le sujet ou le subjectAltName d'un certificat ou un cross-certificate. Quand approprié, le terme "end entity" sera utilisé pour référer aux entités finales qui ne sont pas des entités de gestion de PKI.

   Toute entité finale nécessite un accès local sécurisé à certaines informations -- au minimum, son propre nom et clé privée, le nom d'une CA qui est directement trusté, et la clé publique de cette CA ( ou une empreinte de la clé publique où une version d'un certificat auto-fournis est disponible quelque part). Les implémentations peuvent utiliser un stockage local sécurisé pour plus que ce minimum. La forme de stockage varie également -- de simples fichier à des jetons cryptographiques inviolables. L'information stockée dans un tel stockage local est référé ici à l'environnement de sécurité personnel (PSE). Bien que les formats PSE sont au-delà du scope de ce document, un format générique d'échange pour les PSE est définis ici: un message réponse de certification peut être utilisé.

Autorité de certification

   L'autorité de certification peut ou non être un vrai tier de confiance du point de vue de l'entité finale. Très souvent, la CA appartient à la même organisation que les entités finales qu'elle supporte.

   De même, on utilise le terme CA pour référer à l'entité nommée dans le champ issuer d'un certificat. Quand il est nécessaire de distinguer les outils software ou hardware utilisé par la CA, on utilise le terme d'équipement CA. L'équipement CA inclus souvent un composant offline et un composant online, avec la clé privée de la CA uniquement disponible au composant offline.

   On utilise le terme "root CA" pour indiquer une CA qui est directement trusté par une entité finale; c'est à dire, acquérir de manière sécurité la valeur d'une clé publique d'une CA root nécessite certaines étapes out-of-band. Ce terme n'implique pas qu'une CA root soit nécessairement tout en haut d'une hiérarchie, simplement que la CA en question est trustée directement.

   Une CA subordonnée est une CA qui n'est pas une CA root pour l'entité finale. Souvent, une CA subordonnée ne sera une CA root pour aucune entité, mais ce n'est pas mandatoire.

   En plus des entités finales et des CA, de nombreux environnements font appel à un autorité d'enregistrement (RA) séparé de l'autorité de certification. Les fonctions du RA varie d'un cas à un autre mais peut inclure une authentification personnelle, la distribution de jetons, reporter la révocation, assignement de nom, génération de clé, archivage de paires de clé, etc.

   Ce document considère le RA comme composant optionnel: quand il n'est pas présent, la CA est supposé gérer les fonctions du RA, donc les protocoles de gestion de PKI sont les même du point de vue de l'entité finale. De même, on distingue le RA et les outils utilisés (les équipements RA).

   Noter qu'un RA est lui-même une entité finale. On assume que tous les RA sont en fait des entités finales certifiés et que les RA ont des clés privées qui sont utilisable pour la signature. La manière dont un équipement CA identifie des entités finales comme RA est un problème d'implémentation (par ex: Ce document ne spécifie pas d'opération de certification RA spécial). On ne mandate pas que le RA est certifié par la CA avec laquelle il inter-agit (donc un RA peut travailler avec plus d'une CA alors qu'il a été certifié une seule fois).

   Dans certaines circonstances, les entités finales vont communiquer directement avec une CA même quand un RA est présent. Par exemple, pour un enregistrement initial et/ou une certification, le sujet peut utiliser sont RA, mais communiquer directement avec le CA pour rafraîchir son certificat.

Pré-requis de gestion de PKI

   Les protocoles donnés ici nécessitent les pré-requis suivant pour la gestion de PKI:

1. La gestion de la PKI doit se conformer aux standards ISO/IEC 9594-8/ITU-T X.509
2. Il doit être possible de mettre à jour régulièrement une paire de clé sans affecter une autre paire de clé.
3. L'utilisation de la confidentialité dans les protocoles de gestion de PKI doit être conservé à un minimum pour pouvoir simplifier l'acceptation dans les environnements où une forte confidentialité peut causer des problèmes réguliers.
4. Les protocoles de gestion de PKI doivent permettre d'utiliser différents algorithmes cryptographiques ( incluant RSA, DSA, MD5 et SHA-1). Cela signifie qu'une CA, RA, ou entité finale donné, en principe, utilise les algorithmes qui lui conviennent pour ses propres paires de clés.
5. Les protocoles de gestion de PKI ne doivent pas pré-inclure la génération de paires de clé par l'entité finale concernée, par un RA, ou par une CA. La génération de clé peut également se produire n'importe où, mais dans le but de la gestion de PKI la clé est d'abord présente dans une entité finale, RA, ou CA.
6. Les protocoles de gestion de PKI doivent supporter la publication de certificats par l'entité finale concernée, par une RA, ou par une CA. Différences implémentations et différents environnements peuvent choisir n'importe quel approche ci-dessus.
7. Les protocoles de gestion de PKI doivent supporter la production de listes de révocation de certificat en permettant aux entités finales certifiées de créer des requêtes pour la révocation des certificats. Cela doit être fait de telle manière qu'une attaque DOS, qui est possible, ne soit pas simple.
8. Les protocoles de gestion de PKI doivent être utilisables sur une variété de mécanismes de transport, incluant les mails, http, TCP/IP et ftp.
9. L'autorité finale pour la création des certificats incombe à la CA. Aucune RA ou équipement d'entité finale ne peut supposer qu'un certificat fournis par une CA contienne ce qui a été demandé; Une CA peut altérer les valeurs de champs de certificat ou peut en ajouter, supprimer, ou modifier les extensions en accord à ses stratégies. En d'autres terme, toutes les entités PKI (entités finales, CA et CA) doivent être capable de manipuler les réponses aux requêtes pour les certificats dans lequel le certificat émis est différent de la demande. Noter qu'une stratégie peut dicter qu'une CA ne publie pas ou ne distribue pas le certificat tant que l'entité qui a fait la demande n'a pas accepté le certificat créé (généralement par un message certConf).
10. Une grâce, un changement planifié d'une paire de clé de CA non-compromise doit être supporté (noter que si la clé CA est compromise, la ré-initialisation doit être effectuée pour toutes les entités dans le domaine de la CA). Une entité finale dont le PSE contient la nouvelle clé publique CA doit également être capable de vérifier les certificats vérifiables en utilisant l'ancienne clé publique. Les entités finales qui trust directement l'ancienne paire de clé CA doivent également être capable de vérifier les certificat signés en utilisant la nouvelle clé privée de la CA.
11. Les fonctions d'un RA peut, dans certaines implémentations ou environnements, être géré par la CA elle-même. Les protocoles doivent être conçus pour que les entités finales utilisent le même protocole sans regarder si la communication est avec une CA ou une RA. Naturellement, l'entité finale doit utiliser la bonne clé public RA ou CA pour protéger la communication.
12. Pour une EE demandant un certificat contenant un valeur de clé publique donnée, celle-ci doit être prête à démontrer la possession de la clé privée correspondant.

Opérations de gestion de PKI

Le diagramme suivant affiche la relation entre les entités définies plus haut en terme d'opération de gestion de PKI. Les lettres dans le diagramme indiquent les protocoles dans le sens qu'un jeu définis de message de gestion de PKI peut être envoyé.
+---+_____cert._publish________+------------+______j
_____|___|__‹---------------------__|_End_Entity_|_‹-------
_____|_C_|_____________g____________+------------+______"out-of-band"
_____|_e_|____________________________|_^________________loading
_____|_r_|____________________________|_|______initial
_____|_t_|__________________________a_|_|_b_____registration/
_____|___|____________________________|_|_______certification
_____|_/_|____________________________|_|______key_pair_recovery
_____|___|____________________________|_|______key_pair_update
_____|_C_|____________________________|_|______certificate_update
_____|_R_|__PKI_"USERS"_______________V_|______revocation_request
_____|_L_|_-------------------+-+-----+-+------+-+-------------------
_____|___|__PKI_MANAGEMENT____|_^______________|_^
_____|___|____ENTITIES______a_|_|_b__________a_|_|_b
_____|_R_|____________________V_|______________|_|
_____|_e_|_____________g___+------+____d_______|_|
_____|_p_|___‹------------_|_RA___|_‹-----+____|_|
_____|_o_|______cert.______|______|_----+_|____|_|
_____|_s_|_______publish___+------+___c_|_|____|_|
_____|_i_|______________________________|_|____|_|
_____|_t_|______________________________V_|____V_|
_____|_o_|__________g_________________+------------+___i
_____|_r_|___‹------------------------|_____CA_____|-------›
_____|_y_|__________h_________________+------------+__"out-of-band"
_____|___|______cert._publish______________|_^_________publication
_____|___|______CRL_publish________________|_|
_____+---+_________________________________|_|____cross-certification
_________________________________________e_|_|_f__cross-certificate
___________________________________________|_|_______update
___________________________________________|_|
___________________________________________V_|
_________________________________________+------+
_________________________________________|_CA-2_|
_________________________________________+------+

1. Établissement de CA: en établissant une nouvelle CA, certaines étapes sont requises ( par ex. la production de crl initiales, l'export de la clé publique de la CA).
2. Initialisation de l'entité finale: inclus l'import d'une clé publique CA racine et la demande d'information sur les options supportées par une entité de gestion de PKI.
3. Certification: Diverses opérations résultent de la création de nouveaux certificats:

        1. Enregistrement/certification initiale: C'est le processus par lequel une entité finale se fait connaître auprès d'une CA ou RA, avant que la CA ne fournisse un certificat pour l'entité finale. Le résultat final de ce processus ( Quand il est réussit ) est qu'une CA fournis un certificat pour une clé publique d'une entité finale, et retourne ce certificat à l'entité finale et/ou poste ce certificat dans un répertoire publique. Ce processus peut, et est typiquement, être fait de plusieurs étapes, incluant une initialisation de l'équipement de l'entité finale. Par exemple, l'équipement de l'entité finale doit être initialisé de manière sécurisé avec la clé publique d'une CA, pour être utilisé dans la validation de chemins de certification.
        2. Mise à jour des paires de clé: Toute paire de clé doit être mis à jours régulièrement ( par ex: remplacé par une nouvelle paire de clé), et un nouveau certificat doit être fournis.
        3. Mise à jour de certificat: Vu que les certificats expirent, ils doivent être rafraîchis si rien n'a été changé dans l'environnement.
        4. Mise à jours de paire de clé de CA: Comme pour les entités finales, les paires de clé CA doivent être mis à jours régulièrement; cependant, différents mécanismes sont requis.
        5. Demande de cross-certification: Une CA demande de fournir un cross-certificat pour une autre CA. Pour ce standard, les termes suivants sont définis. Un cross-certificat est un certificat dans lequel le sujet de la CA et le fournisseur de la CA sont distincts et subjectPublicKeyInfo contient une clé de vérification (par ex: le certificat a été fournis pour la signature de la paire de clé du sujet de la CA.). Quand il est nécessaire de distinguer plus finement, les termes suivants peuvent être utilisé: un cross-certificat est appelé un certification inter-domaine si le sujet et le fournisseur appartiennent à des domaines administratifs différents.

                1. Note 1. La définition ci-dessus de cross-certificat s'aligne avec le term définis CA-certificate dans X.509. Noter que ce terme ne doit pas être confondu avec le type d'attribut cACertificate X.500, qui n'est pas lié.
                2. Note 2. Dans de nombreux environnements, le terme cross-certificate, sera compris comme synonyme de cross-certificate inter-domaine.
                3. Note 3. L'émission de cross certificat peut être, mais pas nécessairement, mutuel; c'est à dir, 2 CA peuvent fournir des cross certificats entre eux.

        6. Mise à jours de cross-certificats: Similairement à une mise à jours de certificat.

4. Opérations de découverte de certificat/CRL: Certaines opérations de gestion de PKI résultent dans la publication de certificats ou de CRL:

        1. Publication de certificat: Après avoir produit un certificat, un moyen de publication est nécessaire. Ce moyen définis dans PKIX peut impliquer les messages spécifiés plus bas, ou d'autres moyen (ldap par exemple).
        2. Publication de CRL: Comme pour une publication de certificat.

5. Opérations de récupération: Certaines opérations de gestion de PKI sont utilisée quand une entité finale a perdu son PSE:

        1. Récupération de paire de clé: Comme option, Les clé clients utilisateurs ( par exemple la clé privée de l'utilisateur utilisé pour le déchiffrement) peut être sauvegardé par une CA, une RA, ou un système de sauvegarde de clé associé avec une CA ou une RA. Si une entité a besoin de récupérer sa clé, un protocole d'échange peut être nécessaire pour supporter une telle récupération.

6. Opérations de révocation: Certaines opérations de PKI résultent en la création d'une nouvelle entrée de CRL et/ou une nouvelle CRL.

        1. Demande de révocation: Une personne autorisée avertis une CA d'une situation anormale nécessitant la révocation de certificat

7. Opérations PSE: Bien que la définition des opérations PSE soient en dehors du périmètre de ce document, on doit définir une PKIMessage ( CertRepMessage ) qui peut former la base de telles opérations.

   Noter que les protocoles on-line ne sont par la seule manière d'implémenter les opérations ci-dessus. Pour toutes les opérations, il y à des méthodes offline qui accomplissent le même résultat, et cette spécification ne mandate pas l'utilisation de protocoles on-line. Par exemple, quand des tokens hardware sont utilisé, de nombreuses opération peuvent être accomplies comme partie de la livraison de jetons physique.

Hypothèses et restrictions

Initialisation de l'entité finale

   La première étape pour une entité finale en dialoguant avec les entités de gestion de PKI est de demander les informations sur les fonctions de la PKI supportés et pour acquérir de manière sécurisé une copie des clé publiques de CA root.

Enregistrement/certification Initiale

   Il y a de nombreux schéma qui peuvent être utilisé pour accomplir un enregistrement et une certification des entités finales. Aucune méthode n'est adaptée pour toutes les situations à cause de la plage de stratégie qu'une CA peut implémenter et la variation dans les types d'entité finales qui peuvent se produire.

   Cependant, on peut classer les schémas d'enregistrement/certification qui sont supportés par cette spécification. Noter que le terme d'initial est crucial: on gère les situations où l'entité finale en question n'a jamais eu de contact avec la PKI. Quand l'entité finale possède déjà des clés certifiés, certaines simplification/alternatives sont possibles.

   En ayant classé les schémas qui sont supportés par cette spécification on peut ainsi spécifier certains comme obligatoire et d'autres comme optionnels. Le but est que les schéma obligatoires couvrent suffisamment de cas qui se produisent en utilisation réelle, alors que les schémas optionnels se produisent moins fréquemment. De cette manière, on accomplis une balance entre la flexibilité et la simplicité d'implémentation.

Critères utilisés

Initialisation de l'enregistrement/certification

   En terme de messages PKI qui sont produits, on peut regarder l'initialisation des échange d'enregistrement/certification initials comme se produisant chaque fois que le premier message de PKI lié à l'entité finale est produite. Noter que l'initialisation dans le monde réel de cette procédure peut se produire n'importe où.

Authentification du message originel de l'entité finale

   Les messages on-line produits par l'entité finale qui nécessitent un certificat peuvent être authentifiés ou non. Les prérequis ici sont pour authentifier l'origine de tous messages de l'entité finale vers la PKI (CA/RA).

   Dans cette spécification, une telle authentification est accomplie par la PKI ( CA/RA ) qui fournis à l'entité finale une valeur secrète ( clé d'authentification initiale ) et une valeur de référence ( utilisée pour identifier la valeur secrète ) via d'autres moyens. La clé d'authentification initiale peut ainsi être utilisée pour protéger les messages PKI important.

   Donc, on peut classer le schéma d'enregistrement/certification initial en fonction de si l'entité finale est on-line ou non -› les messages PKI sont authentifiés on non.

   Note 1: on ne discute pas des messages d'authentification de la PKI -› entité finale ici, vu que c'est toujours requis. Dans tous les cas, il peut être simplement une fois que la clé publique de la CA root a été installée dans l'équipement de l'entité finale ou peut être basée sur la clé d'authentification initiale.

   Note 2: Une procédure d'enregistrement/certification initiale peut être sécurisé via d'autres moyens alternatifs.

Emplacement de la génération de clé

   Dans cette spécification, la génération de clé est vu comme se produisant quand la clé publique ou privée se produit dans un PKIMessage. Noter que cela ne pré-inclus pas un service de génération de clé centralisée; la paire de clé actuelle peut avoir été générée n'importe où et envoyé à l'entité finale, RA, ou CA en utilisant un protocole de requête/réponse de génération de clé. Il y a donc 3 possibilités pour l'emplacement de la génération de clé: l'entité finale, une RA ou une CA.

Confirmation du succès de la certification

   Après la création d'un certificat initial pour une entité finale, Une assurance supplémentaire peut être obtenu en retournant une confirmation du succès de l'opération à l'entité finale, contenant le certificat. Cela donne 2 possibilités: confirmé ou non.

Schéma mandatoire

   Le critère ci-dessus permet un grand nombre de schéma d'enregistrement/certification initial. Cette spécification mandate qu'un équipement CA, RA, EE conformes doit supporter le schéma "Schéma authentifié de base", et peut supporter d'autres schémas additionnels.

Schéma centralisé

   En terme de classification, ce schéma est, d'une certaine manière, le plus simple possible, où:

- L'initialisation se produit sur la CA certifiante
- Aucune authentification on-line n'est requis
- La génération de clé se produit sur la CA authentifiante
- Aucun message de confirmation n'est requis

   En terme de flux de message, ce schéma signifie que le seul message requis est envoyé de la CA à l'entité finale. Le message doit contenir tout le PSE pour l'entité finale. Certains moyens externes doivent être fournis pour permettre à l'entité final d'authentifier le message reçu et pour décrypter et décrypter les valeurs.

Schéma authentifié de base

   En terme de classification, ce schéma est où:

- Une initialisation se produit au niveau de l'entité finale
- un message d'authentification est requis
- La génération de clé se produit sur l'entité finale
- Un message de confirmation est requis

   En terme de flux de message, ce schéma est comme suit: La génération de la clé, la création de la demande de certification et la protection de la clé d'authentification initiale (IAK) se produisent sur l'entité finale. L'autorité vérifie la requête, la traite et créé la réponse. L'entité final manipule cette réponse et créé la confirmation. L'autorité vérifie la confirmation et créé une réponse.

Preuve de possession de la clé privée

   Pour empêcher certaines attaques et pour permettre à une CA/RA de vérifier proprement la validité du lien entre une entité finale et une paire de clé, les opérations de gestion de PKI spécifiés ici permettent à une entité finale de prouver qu'il possède la clé privée correspondant à la clé publique pour laquelle un certificat est demandée. Une CA/RA est libre de choisir comment forcer le POP dans ses échanges de certification. Cependant, il est nécessaire qu'un CA/RA force le POP par n'importe quel moyen parce qu'il y a de nombreux protocoles opérationnels non-PKIX utilisés qui ne vérifient pas la liaison entre l'entité finale et la clé privée.

   POP est accomplis de différente manières en fonction du type de clé pour laquelle un certificat est demandé. Si une clé peut être utilisée différents but, une méthode appropriée peut être utilisée. Par exemple, une clé qui peut être utilisée pour signer, aussi bien que d'autres but, ne devraient pas être envoyés à la CA/RA pour prouver la possession).

   Cette spécification permet explicitement les cas où une entité finale fournis la preuve significative à une RA et que cette RA atteste à la CA que la preuve requise a été reçue et validée. Par exemple, une entité finale souhaite avoir une clé de signature certifiée, pourrait envoyer la signature appropriée à la RA, qui peut simplement notifier à la CA que l'entité finale a fournis la preuve requise. Bien sûr, une telle situation peut être interdite par stratégie ( ex: les CA peuvent être les seules entités permises à vérifier le POP durant la certification).

Clés de signature

   Pour les clés de signature, l'entité finale peut signer une valeur pour prouver la possession de la clé privée.

Clés de chiffrement

   Pour les clés de chiffrement, l'entité finale peut fournir la clé privée à la CA/RA, ou peut être requise pour déchiffrer une valeur pour prouver sa possession de la clé privée. En déchiffrant une valeur qui peut être accomplie soit directement, soit indirectement.

   La méthode directe sert à une RA/CA pour fournir un challenge aléatoire pour lequel une réponse immédiate par l'EE est requise.

   La méthode indirect sert à fournir un certificat qui est chiffré afin que l'EE puisse démontrer sa capacité à déchiffrer le message.

   Cette spécification encourage l'utilisation de la méthode indirecte parce qu'elle ne nécessite pas de messages supplémentaires à envoyer.

Clés d'agrément de clé

   Pour les clés d'agrément de clé, l'entité finale et l'entité de gestion de PKI doit établir un clé secrète partagée pour pouvoir prouver que l'entité finale possède la clé privée.

   Noter que cela nécessite de n'imposer aucune restriction sur les clés qui peuvent être certifiés par une CA donnée. En particulier, pour les clés Diffie-Hellman, l'entité finale peut librement choisir ses paramètres à condition que la CA puisse générer une paire de clé avec les paramètres appropriés si nécessaire.

Mise à jour de clé de la CA root

   Cette discussion s'applique uniquement aux CA qui sont directement trustés par certaines entités finales. Les CA auto-signés devraient être considérés comme des CA directement trustés. Reconnaître si une CA non auto-signé est supposé être directement trusté par certaines entités finales est une question de stratégie de CA et est hors du scope de ce document.

   La base de la procédure décrite ici est que la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice-versa. Donc, quand une CA met à jour sa paire de clé elle doit générer 2 valeurs d'attribut cACertificate supplémentaires si les certificats sont disponibles en utilisant un annuaire X.500 (pour un total de 4: OldWithOld, OldWithNew, NewWithOld, et NewWithNew).

   Quand une CA change sa paire de clé, ces entités qui ont acquis l'ancienne clé publique de la CA via des moyens tiers sont les plus affectés. Ce sont ces entités finales qui auront besoin d'accéder à la nouvelle clé publique CA protégée avec l'ancienne clé privée CA. Cependant, ils vont seulement avoir besoin de cela pour une période limitée (jusqu'à ce qu'ils aient acquis la nouvelle clé publique). Ce sera facile à accomplir quand les certificats des entités finales expirent.

   La structure de données utilisé pour protéger la nouvelle et l'ancienne clé publique CA est un certificat standard ( qui peut également contenir des extensions). Il n'y a pas de nouvelle structures de données requises.

   Note 1. Ce schéma n'utilise aucune extension X.509 v3 vu qu'il doit être capable fonctionner avec les certificats version 1. La présente de l'extension KeyIdentifier serait cependant plus efficace.

   Note 2. Bien que le schéma pourrait être généralisé pour couvrir des cas où les CA mettent à jours leur paire de clé plus d'une fois durant la période de validité du certificat d'une de ses entités finales, cette généralisation semble d'une valeur douteuse. Ne pas avoir cette généralisation signifie simplement que la période de validité des certificats émis avec l'ancienne paire de clé CA ne peut pas excéder la fin de la période de validité OldWithNew.

   Note 3. Ce schéma s'assure que les entités finales vont acquérir la nouvelle clé publique CA, à la dernière par expiration du dernier certificat qu'ils possèdent qui a été signé avec l'ancienne clé privée de la CA. Les opération de certificat et/ou de mise à jours de clé se produisant à d'autre moments ne nécessitent pas nécessairement cela.

Actions de l'opérateur CA

   Pour changer la clé de la CA, l'opérateur CA effectue:

1. Générer une nouvelle paire de clés
2. Créer un certificat contenant l'ancienne clé publique signée avec la nouvelle clé privée
3. Créer un certificat contenant la nouvelle clé publique signée avec l'ancienne clé privée
4. Créer un certificat contenant la nouvele clé publique CA signée avec la nouvelle clé privée
5. Publier ces nouveaux certificats via le dépôt et/ou d'autres moyens
6. Exporter la nouvelle clé publique CA pour que les entités finales puissent l'acquérir en utilisant un mécanisme externe (si nécessaire).

   L'ancienne clé privée CA n'est ainsi plus requise. Cependant, l'ancienne clé publique CA va continuer à être utilisée pour un certain temps. L'ancienne clé publique CA n'est plus requise ( autre que pour la non-répudiation ) quand toutes les entités finale de cette CA on acquis la nouvelle clé publique CA.

   Le certificat "old with new" doit avoir une période de validité commençant à la date de génération de l'ancienne paire de clé et se terminant à la date d'expiration de l'ancienne lé publique.

   Le certificat "new with old" doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à la date à laquelle toutes les entités finales de cette CA vont posséder la nouvelle clé publique.

   Le certificat 'new with new' doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à ou avant la date à laquelle la CA va mettre de nouveau à jour sa paire de clé.

Vérifier les certificats

   En vérifiant une signature, le vérificateur vérifie le certificat contenant la clé publique du signataire. Cependant, une fois qu'une CA est autorisée à mettre à jours ses clés il y a de nouvelles possibilités:

- Pour les cas impaires, le signataire des certificats est protégé avec la nouvelle clé publique, dans les cas paires, ce certificat est protégé avec l'ancienne clé publique.
- 2 types de dépôts: le dépôt contient la nouvelle et l'ancienne clé publique ou le dépôt ne contient que l'ancienne clé ( dû à un délay )
- 2 cas de possession de la clé: le PSE contient la nouvelle clé, ou le PSE contient l'ancienne clé.

Cas 1: le dépôt et le PSE contiennent la nouvelle clé: c'est le cas standard où le vérificateur peut directement vérifier le certificat sans utiliser le dépôt.
Cas 2: le dépôt et le PSE contiennent la nouvelle clé: Le vérificateur doit accéder au dépôt pour obtenir la valeur de l'ancienne clé publique
Cas 3: le dépôt a la nouvelle clé, mais pas le PSE. Dans ce cas, le vérifier doit accéder au dépôt pour obtenir la valeur de la nouvelle clé publique.
Cas 4: le dépôt a la nouvelle clé, mais pas le PSE. Le vérificateur peut directement vérifier le certificat sans utiliser le dépôt
Cas 5: Le PSE a la nouvelle clé, mais pas le dépôt. Bien que l'opération CA n'a pas mis à jours le dépôt, le certificat peut être directement validé (identique au cas 1)
Cas 6: Le PSE a la nouvelle clé, mais pas le dépôt. Le vérificateur pense qu'il s'agit d'un situation cas 2 et va accéder au dépôt, cependant, la vérification va échouer.
Cas 7: le dépôt et le PSE contiennent l'ancienne clé: Dans ce cas l'opérateur CA n'a pas mis à jours le dépôt et la vérification va échouer
Cas 8: le dépôt et le PSE contiennent l'ancienne clé: Bien que l'opérateur CA n'a pas mis à jours le dépôt, le vérificateur peut vérifier le certificat directement, (identique au cas 4)

Vérification dans les cas 1,4,5,8

   Dans ces cas, le vérificateur n'a pas de copie locale de la clé publique qui peut être utilisée pour vérifier le certificat directement. C'est la même situation où aucune clé n'a été changée. Noter que le cas 8 peut se produire entre le moment où l'opérateur CA a généré la nouvelle paire de clé et le moment où l'opérateur CA stock les attributs mis à jours dans le dépôt. Le cas 5 peut seulement se produire si l'opérateur CA a émis les certificats du signataire et du vérificateur durant cet écart ( L'opérateur CA devrait éviter cela).

Vérification dans le cas 2

   Dans le cas 2, le vérificateur doit avoir accès à l'ancienne clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut caCertificate dans le dépôt et prend le certificat OldWithNew (déterminé sur la période de validité; noter que les champs subject et issuer doivent correspondre).
2. Vérifie que c'est correcte en utilisant la nouvelle clé CA ( que le vérificateur a localement ).
3. Si correct, vérifie le certificat du signataire en utilisant l'ancienne clé CA.

   Le cas 2 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, puis émis le certificat du vérificateur; donc c'est un bon cas typique.

Vérification dans le cas 3

   Dans le cas 3, le vérificateur doit avoir accès à la nouvelle clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut CACertificate dans le dépôt et prend le certificat NewWithOld (déterminé sur la période de validité; le subject et issuer doivent matcher.
2. Vérifie que c'est correct en utilisant l'ancienne clé
3. Si correct, vérifie le certificat du signataire en utilisant la nouvelle clé CA.

   Le cas 3 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, et ainsi émis le certificat du signataire; donc c'est également un cas typique.

Érreur de vérification dans le cas 6

   Dans ce cas, la CA a émis le PSE du vérificateur, qui contient la nouvelle clé, sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Érreur de vérification dans le cas 7

   Dans ce cas, la CA a émis le certificat du signataire protégé avec la nouvelle clé sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Révocation - Changement de la clé CA

   Comme vu plus haut, la vérification d'un certificat devient de plus en plus complexe une fois que la CA est autorisée à changer sa clé. C'est également vrai pour les vérifications de révocation vu que la CA peut avoir signé la CRL en utilisant une clé privée plus récente que celle dans le PSE de l'utilisateur.

   L'analyse des alternatives est la même que pour la vérification du certificat.

Structures de données

   Cette section contient des descriptions des structures de données requise pour les messages de gestion de PKI. La section suivante décris les contraintes sur leur valeurs et la séquence des évènements pour chaque opération de gestion de PKI.

Message PKI

Tous les messages utilisés dans cette spécification pour les buts de gestion de PKI utilisent la structure suivante:
PKIMessage ::= SEQUENCE {
    header PKIHeader,
    body PKIBody,
    protection [0] PKIProtection OPTIONAL,
    extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

PKIHeader contient les informations qui sont communes aux messages PKI
PKIBody contient des informations spécifiques au message
PKIProtection si utilisé, contient les bits qui protègent le message de PKI.
extraCerts peut contenir des certificats qui peuvent être utiles. Par exemple, cela peut être utilisé par une CA ou RA pour présente une entité finale avec les certificats qui sont nécessaires pour vérifier son propre nouveau certificat. (Si, par exemple, la CA qui a émis le certificat EE n'est pas une CA root pour l'EE). Noter que ce champ ne contient pas nécessairement un chemin de certification; le destinataire peut avoir à trier, sélectionner, ou traiter les certificats supplémentaires pour pouvoir les utiliser.

En-tête de message de PKI

   Tous les messages de PKI nécessitent certaines informations d'en-tête pour l'adressage et l'identification de la transaction. Certaines de ces informations vont également être présentes dans une enveloppe spécifique au transport. Cependant, si le message PKI est protégé, alors cette information est également protégée.

La structure de données suivante est utilisée pour contenir cette information:
PKIHeader ::= SEQUENCE {
    pvno INTEGER { cmp1999(1), cmp2000(2) },
    sender GeneralName,
    recipient GeneralName,
    messageTime [0] GeneralizedTime OPTIONAL,
    protectionAlg [1] AlgorithmIdentifier OPTIONAL,
    senderKID [2] KeyIdentifier OPTIONAL,
    recipKID [3] KeyIdentifier OPTIONAL,
    transactionID [4] OCTET STRING OPTIONAL,
    senderNonce [5] OCTET STRING OPTIONAL,
    recipNonce [6] OCTET STRING OPTIONAL,
    freeText [7] PKIFreeText OPTIONAL,
    generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String

pvno est fixé à 2 pour cette version de ce document
sender contient le nom de l'émetteur du PKIMessage. Ce nom ( en conjonction avec senderKID, si fournis) devrait être suffisant pour indiquer la clé à utiliser pour vérifier la protection dans le message. Si rien sur l'émetteur n'est connus sur l'entité (ex: dans l'initialisation, un message req, où l'entité finale peut ne pas connaître son propre DN, e-mail, IP, etc), alors ce champ doit contenir une valeur NULL; c'est à dire une séquence de rdn de longueur 0. Dans un tel cas, le champ senderKID doit contenir un identifiant (par ex: un numéro de référence) qui indique au destinataire les information de clé secrète partagée appropriée pour vérifier le message.
recipient Contient le nom du destinataire du PKIMessage. Ce nom ( en conjonction avec recipKID, si fournis ) devrait être utilisable pour vérifier la protection du message.
protectionAlg Spécifie l'algorithme utilisé pour protéger le message. Si aucun bits de protection n'est fournis ( PKIProtection est optionnel ), ce champ doit être omis; si les bits de protection sont fournis, ce champ doit être fournis.
senderKID, recipKID Sont utilisables pour indiquer quelles clés ont été utilisées pour protéger le message. (RecipKID va normalement être requis seulement quand le message est protégé avec des clés DH ). Ces champs doivent être utilisés si nécessaire pour identifier de manière unique une clé et devraient être omis sinon.
transactionID est utilisé pour permettre au destinataire du message de le corréler avec une transaction sortante. C'est nécessaire pour toutes les transactions qui consistent d'une simple paire demande/réponse. Pour ces transactions demande/réponse, les règles sont comme suit. Un client peut populer le champ transactionID de la requête. Si un serveur reçois une telle requête qui a le champ transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle requête avec un champ transactionID manquant, alors il peut mettre le champ transactionID de la réponse.

   Pour les transaction qui consistent de plus qu'une simple paire demande/réponse, les règles sont comme suit. Les client devraient générer une transactionID pour la première demande. Si un serveur reçoit une telle demande avec le champs transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle demande sans le champs transactionID, il doit populer ce champs dans la réponse avec un ID généré par le serveur. Les requêtes et réponses suivantes doivent toutes mettre le champs transactionID avec la valeur établie. Dans tous les cas où un transactionID est utilisé, un client ne doit pas avoir plus d'une transaction avec le même transactionID en cours vers un serveur donné. Les serveur sont libre d'imposer ou non l'unicité du transactionID, tant qu'ils sont capable d'associer correctement les messages avec la transaction correspondante.

   Typiquement, cela signifie qu'un serveur va nécessiter que le couple client/transactionID soit unique, ou même le transactionID seul, s'il ne peut pas distinguer les clients basé sur les information au niveau du transport. Un serveur recevant le premier message d'un transaction ( qui nécessite plus d'une paire demande/réponse ) qui contient un transactionID qui ne permet pas de répondre aux contraintes ci-dessus ( généralement parce que le transactionID est déjà utilisé ) doit envoyer un ErrorMsgContent avec un PKIFailureInfo de transactionIdInUse. Il est recommandé que les client utilisent un transactionID avec une donnée pseudo-aléatoire 128-bits pour commencer la transaction pour réduire la probabilité d'avoir un transactionID utilisé par le serveur.

senderNonce, recipNonce protègent le PKIMessage avec les attaques replay. senderNonce est généralement une donnée pseudo-aléatoire 128-bits générée par l'émetteur, et recipNonce est copié de senderNonce du précédent message dans la transaction.
messageTime Contient l'horodatage du moment où l'émetteur a créé le message. Peut être utile pour permettre aux entités finales de corriger/vérifier l'heure local.
freeText Peut être utilisé pour envoyer des données additionnelles au destinataire. Le premier langage utilisé dans cette séquence indique la langue désirée pour les réponses.
generalInfo Peut être utilisé pour envoyer des données additionnelles traitable par la machine au destinataire. Les extentions generalInfo suivantes sont définies et peuvent être supportées:

ImplicitConfirm

C'est utilisé par l'EE pour informer la CA qu'elle ne souhaite pas envoyer une confirmation de certificat pour les certificats émis.
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL

   Si la CA autorise la demande, elle doit placer la même extension dans le PKIHeader de la réponse. Si l'EE ne trouve pas l'extension dans la réponse, elle doit envoyer la confirmation du certificat.

ConfirmWaitTime

C'est utilisé par la CA pour informer l'EE du temps d'attente prévu pour la confirmation de certificat avant de révoque le certificat et supprimer la transaction.
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime

Corps du message PKI


PKIBody ::= CHOICE {
    ir [0] CertReqMessages, --Initialization Req
    ip [1] CertRepMessage, --Initialization Resp
    cr [2] CertReqMessages, --Certification Req
    cp [3] CertRepMessage, --Certification Resp
    p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
    popdecc [5] POPODecKeyChallContent --pop Challenge
    popdecr [6] POPODecKeyRespContent, --pop Response
    kur [7] CertReqMessages, --Key Update Request
    kup [8] CertRepMessage, --Key Update Response
    krr [9] CertReqMessages, --Key Recovery Req
    krp [10] KeyRecRepContent, --Key Recovery Resp
    rr [11] RevReqContent, --Revocation Request
    rp [12] RevRepContent, --Revocation Response
    ccr [13] CertReqMessages, --Cross-Cert. Request
    ccp [14] CertRepMessage, --Cross-Cert. Resp
    ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
    cann [16] CertAnnContent, --Certificate Ann.
    rann [17] RevAnnContent, --Revocation Ann.
    crlann [18] CRLAnnContent, --CRL Announcement
    pkiconf [19] PKIConfirmContent, --Confirmation
    nested [20] NestedMessageContent, --Nested Message
    genm [21] GenMsgContent, --General Message
    genp [22] GenRepContent, --General Response
    error [23] ErrorMsgContent, --Error Message
    certConf [24] CertConfirmContent, --Certificate confirm
    pollReq [25] PollReqContent, --Polling request
    pollRep [26] PollRepContent --Polling response
}

   Les types spécifiques sont décris plus bas.

Protection de message PKI

   Certains message PKI vont être protéger pour l'intégrité. ( Noter que si un algorithme asymétrique est utilisé pour protéger un message et que le composant publique a déjà été certifié, l'origine du message peut également être authentifié ).

Quand la protection est appliquée, la structure suivante est utilisée:
PKIProtection ::= BIT STRING

L'entrée pour le calcul de PKIProtection est un encodé DER de la structure de données suivante:
ProtectedPart ::= SEQUENCE {
    header PKIHeader,
    body PKIBody
}

   Il peut y avoir des cas dans lesquels la chaîne de bit PKIProtection n'est délibérément pas utilisée pour protéger un message parce que d'autre protection externes sont appliqués à la place. Un tel choix est explicitement permit dans cette spécification. Des exemples de telles protections externes incluent les encapsulations PKCS#7 et Security Multiparts ( rfc1847 ) du PKIMessage ( ou simplement le PKIBody ), si les informations PKIHeader sont gérés de manière sécurisés dans le mécanisme externe. Il est noté, cependant, que de nombreux mécanismes externes nécessitent que l'entité finale possède déjà un certificat et/ou un DN unique, et/ou d'autres informations liées à l'infrastructure.

   Donc, ils peuvent être non appropriés pour un enregistrement initial, récupération de clé, ou tout autre processus avec des caractéristiques de 'boot-strapping'. Pour ces cas il peut être nécessaire que le paramètre PKIProtection soit utilisé. Dans le future, si et quand les mécanismes externes sont modifiés pour ces scénarios, l'utilisation de PKIProtection peut devenir rare ou non-existant.

   En fonction des circonstance, les bits PKIProtection peuvent contenir un MAC ou une signature. Seul les cas suivants peut se produire.

Information de secret partagé

Dans ce cas, l'émetteur et le destinataire partages une information secrète (établie via un moyen externe ou depuis une opération de gestion PKI précédente). PKIProtection va maintenir une valeur MAC et protectionAlg sera:
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
    salt OCTET STRING,
    owf AlgorithmIdentifier,
    iterationCount INTEGER,
    mac AlgorithmIdentifier
}

   Dans protectionAlg ci-dessus, la valeur salt est ajoutée à l'entrée du secret partagé. Le OWF est ainsi appliqué iterationCount fois, où le secret salé est l'entrée de la première itération et, pour chaque itération successive, l'entrée est la sortie de l'itération précédente. La sortie de l'itération finale ( appelée BASEKEY avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-Bits et K ‹= H, alors les bits K les plus signifiant de BASEKEY sont utilisés. Si K › H, alors tout BASEKEY est utilisé pour les bits H les plus signifiant de la clé, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé et ainsi de suite, jusqu'à ce que tous les bits K aient été dérivés.

   Note: il est recommandé que les champs de PBMParameter restent constants via les messages d'une simple transaction (ex: ir/ip/certConf/pkiConf) pour pouvoir réduire la charge associé avec le calcul de PasswordBasedMac.

Paires de clé DH

Où l'émetteur et le destinataire possèdent des certificats Diffie-Hellman avec des paramètres DH compatibles, pour pouvoir protéger le message l'entité finale doit générer une clé symétrique basée sur la clé privée DH et la clé publique DH du destinataire de message PKI. PKIProtection contient une valeur MAC protégé avec cette clé symétrique dérivée et protectionAlg sera:
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
    owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended)
    mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
}

   Dans le protectionAlg ci-dessus, OWF est appliqué au résultat du calcul DH. La sortie OWF (appelée BASEKEY, avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-bit et K ‹= H, les bits K les plus signifiant de BASEKEY sont utilisé. Si K › H, tout BASEKEY est utilisé pour les bits H les plus signifiants suivants, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, et ainsi de suite, jusqu'à ce que les bits K aient été dérivés.

Signature

   Dans ce cas, l'émetteur possède une paire de clé de signature et signe simplement le message PKI. PKIProtection va contenir la valeur de signature et protectionAlg sera un AlgorithmIdentifier pour une signature numérique.

Protection Multiple

Dans les cas ou une entité finale envoie un message PKI protégé à une RA, la RA peut transférer ce message à une CA, attachant sa propre protection ( qui peut être un MAC ou une signature, en fonction des informations et des certificats partagés entre la RA et la CA ). C'est accomplis en imbriquant tout le message envoyé par l'entité finale dans un nouveau message PKI. La structure utilisée est:
NestedMessageContent ::= PKIMessages

   L'utilisation des PKIMessages, une sequence de PKIMessage, laisse la RA automatiser les requêtes de nombreux EE dans un simple nouveau message. Par simplicité, tous les messages dans le batch doivent être de même type (ex: ir). Si la RA souhaite modifier les messages d'une certaine manière (ex: ajouter des valeur de champ particulier ou de nouvelles extensions), elle peut créer sont propre PKIBody. Le PKIMessage originel de l'EE peut être inclus dans le champ generalInfo de PKIHeader. l'infoType utilisé dans cette situation est {id-it 15} et infoValue est PKIMessages (le contenu doit être dans le même ordre que les demandes dans PKIBody).

Structures de données communes

   Avant de spécifier les types spécifique qui peuvent être placés dans un PKIBody, on définis certaines structures qui sont utilisées dans plus d'un cas.

Contenu des certificats demandés

   Divers messages de gestion de PKI nécessitent que l'initiateur du message indique certains des champs qui doivent être présent dans un certificat. La structure CertTemplate permet à une entité finale ou une RA de spécifier ce qu'elle souhaite dans le certificat. CertTemplate est identique à une certificat, mais avec tous les champs optionnels.

   Noter que même si l'initiateur spécifie complètement le contenus d'un certificat, une CA est libre de modifier les champs dans le certificat qu'elle émet. Si le certificat modifié n'est pas acceptable pour le demandeur, le demandeur doit renvoyer un message certConf qui soit n'inclus pas ce certificat, ou inclus ce certificat ( via un CertHash ) avec un statut "rejected".

Valeurs chiffrées

   Quand des valeurs chiffrées ( restreintes, dans cette spécification, à des clés privées ou des certificats ) sont envoyés dans les messages PKI, la structure de données EncryptedValue est utilisée.

   L'utilisation de cette structure nécessite que le créateur et de destinataire soient capable de chiffrer et déchiffrer, respectivement. Typiquement, cela signifie que l'émetteur et de destinataire aient, ou soient capable de générer une clé secrète partagée.

   Si le destinataire du PKIMessage possède déjà une clé privée utilisable pour le déchiffrement, alors le champ encSymmKey peut contenir une clé de session chiffrée en utilisant la clé publique du destinataire.

Codes de status et information d'erreur pour les messages PKI

Tous les messages de réponse incluent une information de status. Les valeurs suivantes sont définies.
PKIStatus ::= INTEGER {
    accepted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4),
    revocationNotification (5),
    keyUpdateWarning (6)
}

Les répondeurs peuvent utiliser la syntaxe suivante pour fournir certaines informations sur les cas d'erreur
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badMessageCheck (1),
    badRequest (2),
    badTime (3),
    badCertId (4),
    badDataFormat (5),
    wrongAuthority (6),
    incorrectData (7),
    missingTimeStamp (8),
    badPOP (9),
    certRevoked (10),
    certConfirmed (11),
    wrongIntegrity (12),
    badRecipientNonce (13),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17),
    badSenderNonce (18),
    badCertTemplate (19),
    signerNotTrusted (20),
    transactionIdInUse (21),
    unsupportedVersion (22),
    notAuthorized (23),
    systemUnavail (24),
    systemFailure (25),
    duplicateCertReq (26)
}
    
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL
}

Identification de certificat

   Pour pouvoir identifier des certificats particuliers, la structure de données CertId est utilisée.

Clé publique CA out-of-band

   Chaque CA root doit être capable de publier sa clé publique courante via des moyens externes. Bien que de tels mécanismes soient au-delà du scope de ce document, on définis des structures de données qui peuvent supporter de tels mécanismes.

Il y a généralement 2 méthodes disponibles: soit la CA publie directement son certificat auto-signé, ou cette information est disponible via l'annuaire ( ou équivalent ) et la CA publie un hash de cette valeur pour permettre la vérification de son intégrité avec utilisation.
OOBCert ::= Certificate

   Les champs dans ce certificat sont restreints comme suit:

- Le certificat doit être auto-signé (par ex: la signature doit être vérifiable en utilisant le champ subjectPublicKeyInfo.
- Les champs subject et issuer doivent être identiques
- Si le champ subject est NULL, alors les extensions subjectAltNames et issuerAltNames doivent être présents et avoir la même valeur
- Les valeur de toutes les autres extensions doivent être correct pour un certificat auto-signé.


OOBCertHash ::= SEQUENCE {
    hashAlg [0] AlgorithmIdentifier OPTIONAL,
    certId [1] CertId OPTIONAL,
    hashVal BIT STRING
}

   L'intension de la valeur de hash est que celui qui a reçu de manière sécurisée cette valeur peut vérifier un certificat auto-signé pour cette CA.

Options d'archive

   Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI archive une valeur de clé privée en utilisant la structure PKIArchiveOptions.

Information de publication

   Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI publient un certificat en utilisant la structure PKIPublicationInfo

Structures POP

Si la demande de certification concerne la signature d'une paire de clé, alors la preuve de possession de la clé privée est démontrée via l'utilisation de la structure POPOSigningKey.
POPOSigningKeyInput ::= SEQUENCE {
    authInfo CHOICE {
        sender [0] GeneralName,
        publicKeyMAC PKMACValue
    },
    publicKey SubjectPublicKeyInfo
}

   D'une autre manière, si la demande de certification est pour une paire de clé de chiffrement, alors la preuve de possession de la clé de privée peut être démontrée d'une des 3 manières suivante:

Méthode indirecte

   La CA ne retourne pas un certificat, mais un certificat chiffré ( le certificat chiffré avec une clé symétrique générée aléatoirement, et la clé symétrique est chiffrée avec la clé publique pour laquelle la demande de certificat est faite). L'entité finale prouve sa connaissance de la clé privée à la CA en fournissant le CertHash correct pour ce certificat dans le message certConf. Cela démontre le POP parce que l'EE peut seulement calculer le CertHash correct s'il est capable de récupérer le certificat, et il peut seulement récupérer le certificat s'il est capable déchiffrer la clé symétrique en utilisant sa propre clé privée. Pour que cela fonctionne, la CA ne doit pas publier le certificat tant que le message certConf n'est pas arrivé ( où certHash est utilisé pour démontrer POP).

Protocole Challenge-Response

   L'entité finale s'engage dans un protocole challenge-response ( en utilisant les messages POPODecKeyChall et POPODecKeyResp ) entre CertReqMessages et CertRepMessage -- c'est la méthode directe décrite plus haut. ( Cette méthode est généralement utilisée dans un environnement dans lequel une RA vérifie le POP et créé la demande de certification à la CA. Dans un tel scénario, la CA trust la RA pour avoir validé le POP correctement avant que la RA demande un certificat pour l'entité finale ). Le protocole complet ressemble comme suit:


EE____________RA____________CA
________----_req_----›
________‹---_chall_---
________----_resp_---›
______________________----_req'_---›
______________________‹---_rep_-----
______________________----_conf_---›
______________________‹---_ack_-----
________‹---_rep_-----
________----_conf_---›
________‹---_ack_-----

Ce protocole est plus long qu'un échange triple donné dans le choix 2 ci-dessus, mais permet à une RA d'être impliqué et a la propriété que le certificat n'est pas créé tant que le POS n'est pas complété. Dans certains environnements, un ordre différent peut être requis, tel que ceci ( peut être déterminé par stratégie):
EE____________RA____________CA
----_req_----›
‹---_chall_---
----_resp_---›
______________----_req'_---›
______________‹---_rep_-----
‹---_rep_-----
----_conf_---›
______________----_conf_---›
______________‹---_ack_-----
‹---_ack_-----

   Si la demande de certificat est pour une paire de clé d'agrément de clé (KAK), alors le POP peut être utilisé dans un échange triple décris plus haut pour encoder les paires de clé, avec les changement suivant: (1) le texte entre parenthèses 2) est remplacé avec "ex: le certificat chiffré avec la clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certification est faite". (2) le premier texte entre parenthèses du champ challenge est remplacé avec "(PreferredSymmAlg et une clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certificat est faite)". Alternativement, le POP peut utiliser la structure POPOSigningKey comme 4ème alternative pour démontrer le POP si la CA a déjà un certificat DH qui est connu de l'EE.

Les messages challenge-response pour POP d'une clé privée de chiffrement sont spécifié comme suit. Noter que cet échange est associé avec le message de demande de certification précédent by le transactionID utilisé dans le PKIHeader et par la protection appliquée au PKIMessage.
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
    owf AlgorithmIdentifier OPTIONAL,
    witness OCTET STRING,
    challenge OCTET STRING
}

Noter que la taille de Rand doit être approprié pour le chiffrement sous la clé publique de demandeur. Cet entier n'est généralement pas plus long que 64bits, laissant 100 octets pour le champ sender quand le modulo est 1024 bits. Si, dans certains environnements, les noms sont trop long, alors tout ce qui peut rentrer doit être utilisé ( tant que cela inclus au moins un nom commun, et tant que le destinataire est capable de comprendre l'abréviation).
POPODecKeyRespContent ::= SEQUENCE OF INTEGER

Sommaire des options POP

   Le texte dans cette section fournis de nombreuses options en respect des techniques POP. En utilisant SK pour Signing Key, EK pour Encryption Key, et KAK pour Key Agreement Key, les techniques peut être listés comme suit:

RAVerified
SKPOP
EKPOPThisMessage
KAKPOPThisMessage
KAKPOPThisMessageDHMAC
EKPOPEncryptedCert
KAKPOPEncryptedCert
EKPOPChallengeResp
KAKPOPChallengeResp

   En donnant ce tableau d'options, il est naturel de demander comment une entité finale peut connaître ce qui est supporté par la CA/RA. Les guides suivants devraient clarifier cette situation.

RAVerified Ce n'est pas une décision de l'EE; le RA l'utilise si et seulement si a vérifié le POP avant de transmettre la requête à la CA, donc il n'est pas possible pour l'EE de choisir cette technique.
SKPOP Si l'EE an une paire de clé de signature, c'est la seule méthode POP spécifiée pour l'utilisation dans la requête pour un certificat correspondant.
EKPOPThisMessage, KAKPOPThisMessage Donner on non sa clé privée à la CA/RA est une décision EE. Si l'EE décide de révéler sa clé, alors ce sont les seules méthodes POP disponible dans cette spécification pour l'accomplir.
KAKPOPThisMessageDHMAC L'EE peut seulement utiliser cette méthode si (1) la CA a un certificat DH disponible dans ce but, et (2) l'EE a déjà une copie de ce certificat. Si ces 2 conditions sont remplies, cette technique est clairement supportée et peut être utilisé par l'EE, si désiré.
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp L'EE choisis une des technique dans le message de demande, en fonction des préférences et du type de clés. L'EE ne fait pas de POP à ce moment là; il indique simplement quelle méthode il souhaite utilisé. Cependant, si la CA/RA répond avec une erreur badPOP, l'EE peut redemander en utilisant une autre méthode. Noter cependant que cette spécification encourage l'utilisation de EncryptedCert et, en outre, dit que le challenge-response devrait être utilisé quand une RA est impliquée et fait la vérification POP. Ainsi, l'EE devrait être capable de prendre une décision intelligente concernant la méthode POP à choisir dans la demande.

Initialisation de la demande

   Un message d'initialisation de demande contient comme PKIBody la structure CertReqMessages, qui spécifie les certificats demandés. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs qui doivent être fournis pour chaque demande de certificat. Ce message est prévu pour être utilisé par les entité qui s'initialise pour la première fois dans la PKI.

Initialisation de la réponse

   Un message d'initialisation de réponse contient comme PKIBody la structure CertRepMessage, qui a pour chaque attribut demandé un champ PKIStatusInfo, un sujet, et possiblement une clé privée (normalement chiffrée avec une clé de session, qui est elle-même chiffrée avec le protocolEncrKey). Noter que si la protection du message est de type secret partagé, tout certificat transporté dans le champ caPubs peut être directement validé comme certificat CA root par l'initiateur.

Demande de certification

   Un message de demande de certification contient comme PKIBody une structure CertReqMessages, qui spécifie les certificats demandés. Ce message est prévu pour être utilisé pour les entité PKI existantes qui souhaitent obtenir des certificats additionnels. Alternativement, PKIBody peut être un CertificationRequest. Cette structure peut être requise pour les demande de certificat pour les paires de clé de signature quand l'intéropérabilité avec les anciens systèmes est désirée, mais son utilisation est fortement découragée.

Réponse de certification

Un message de réponse de certification contient comme PKIBody une structure CertRepMessage, qui a la valeur de status pour chaque certificat demandé, et optionnellement une clé publique de CA, des informations d'erreur, un sujet, et une clé privée chiffrée.
CertRepMessage ::= SEQUENCE {
    caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
    response SEQUENCE OF CertResponse
}
    
CertResponse ::= SEQUENCE {
    certReqId INTEGER,
    status PKIStatusInfo,
    certifiedKeyPair CertifiedKeyPair OPTIONAL,
    rspInfo OCTET STRING OPTIONAL
         analogue à id-regInfo-utf8Pairs définis pour regInfo dans CertReqMsg
}
    
CertifiedKeyPair ::= SEQUENCE {
    certOrEncCert CertOrEncCert,
    privateKey [0] EncryptedValue OPTIONAL,
    publicationInfo [1] PKIPublicationInfo OPTIONAL
}
    
CertOrEncCert ::= CHOICE {
    certificate [0] Certificate,
    encryptedCert [1] EncryptedValue
}

   Seul un champ failInfo (dans PKIStatusInfo) et certificate (dans CertifiedKeyPair) peuvent être présents dans chaque CertResponse (en fonction du statut). Pour certaines valeurs de statut (ex: waiting), aucun des champs optionnels ne sont présents.

   En donnant un EncryptedCert et la clé de déchiffrement, le certificat peut êtr obtenu. Le but de cela est de permettre à une CA de retourner la valeur d'un certificat, mais avec la contrainte que seule le destinataire prévu peut obtenir le certificat. Le bénéfice de cette approche est qu'un CA peut répondre avec un certificat même en l'absence de preuve que le demandeur est l'entité finale qui peut utiliser la clé privée ( noter que la preuve n'est pas obtenue jusqu'à ce que le message certConf soit reçu par la CA). Donc, la CA n'aura pas à révoquer ce certificat dans le cas où quelque-chose ne va pas avec le POP.

Contenu des demandes de mise à jour de clé

   Pour les demandes de mise à jour de clé la syntaxe CertReqMessages est utilisée. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs fournis pour chaque clé à mettre à jours. Ce message est prévu pour être utilisé pour demanders des mises à jours de certificat existant non-révoqués et non-expirés. Une mise à jours est un remplacement de certificat contenant soit une nouvelle clé publique ou la clé publique courante.

Contenu des réponses de mise à jour de clé

   Pour les réponses de mise à jour de clé, la syntaxe CertRepMessage est utilisée. La réponse est identique à la réponse d'initialisation.

Contenu de demande de récupération de clé

   Pour les demandes de récupération de clé la syntaxe utilisée est identique à CertReqMessages des demandes d'initialisation. Typiquement, SubjectPublicKeyInfo et KeyId sont les champs qui peuvent être utilisé pour fournir une clé publique de signature pour laquelle un certificat est requis. Noter que si un historique de clé est requis, le demandeur doit fournir un contrôle de clé de chiffrement de protocole dans la demande.

Contenu de réponse de récupération de clé

Pour les réponses de récupération de clé, la syntaxe suivante est utilisée. Pour certaines valeurs de statut (ex: waiting), aucun champ optionnel n'est présent.
KeyRecRepContent ::= SEQUENCE {
    status PKIStatusInfo,
    newSigCert [0] Certificate OPTIONAL,
    caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL
}

Contenu de demande de révocation

Pour une demande de révocation d'un ou plusieurs certificats, la structure de données suivante est utilisée. Le nom du demandeur est présent dans la structure PKIHeader
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
    certDetails CertTemplate,
    crlEntryDetails Extensions OPTIONAL
}

Contenu de réponse de révocation

La réponse de révocation est envoyée au demandeur de la révocation:
RevRepContent ::= SEQUENCE {
    status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
    revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
    crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
}

Contenu de demande de cross-certification

   Les demandes de cross-certification utilisent la même syntaxe (CertReqMessages) que pour les demandes de certification normales, avec comme restriction que la paire de clé doit avoir été générée par la CA demandeur et que la clé privée ne doit pas être envoyée. Cet requête peut également être utilisé par les CA subordonnées pour obtenir leur certificats signés par la CA parent.

Contenu de réponse de cross-certification

   Les réponse de cross-certification utilisent la même syntaxe (CertRepMessage) que pour les réponse de certification normales, avec comme restriction qu'aucune clé privée de chiffrement ne peut être envoyée.

Contenu d'annonce de mise à jour de clé CA

Quand une CA met à jours sa propre paire de clé, la structure de données suivante peut être utilisé pour annoncer cet évènement:
CAKeyUpdAnnContent ::= SEQUENCE {
    oldWithNew Certificate,
    newWithOld Certificate,
    newWithNew Certificate
}

Annonce de certificat

Cette structure peut être utilisé pour annoncer l'existence de certificat. Noter que ce message est prévu pour être utilisé pour les cas (s'il y'en a) où il n'y a pas de méthode pré-existante pour la publication de certificats; il n'est pas prévu pour être utilisé où, par exemple, X.500 est la méthode pour la publication de certificats
CertAnnContent ::= Certificate

Annonce de révocation

Quand une CA a été révoquée, ou est en train de révoquer un certificat particulier, elle peut émettre une annonce de cet évènement:
RevAnnContent ::= SEQUENCE {
    status PKIStatus,
    certId CertId,
    willBeRevokedAt GeneralizedTime,
    badSinceDate GeneralizedTime,
    crlDetails Extensions OPTIONAL
}

   Une CA peut utiliser une telle annonce pour alerter ou notifier un sujet que son certificat est révoqué. C'est généralement utilisé quand la demande de révocation en vient pas du sujet concerné. Le champ willBeRevokedAt contient la date à laquelle une nouvelle entrée sera ajoutée aux CRLs concernées.

Contenu de confirmation PKI

Cette structure est utilisée dans le protocole d'échange comme PKIMessage final. Son contenu est le même dans tous les cas -- actullement il n'y a aucun contenu vu que PKIHeader gère toutes les informations requises.
PKIConfirmContent ::= NULL

   L'utilisation de ce message pour la confirmation de certificat n'est pas recommandée. certConf devrait être utilisé à la place. Une fois reçu un PKIConfirm pour une réponse de certificat, le destinataire peut le traiter comme un certConf avec tous les certificats acceptés.

Contenu de confirmation de certificat

Cette structure est utilisée par le client pour envoyer une confirmation à la CA/RA pour accepter ou rejeter le certificat.
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
    certHash OCTET STRING,
    certReqId INTEGER,
    statusInfo PKIStatusInfo OPTIONAL
}

   Pour un CertStatus particulier, l'omission du champ statusInfo indique l'acceptation du certificat spécifié. Alternativement, des détails de statut explicite peuvent être fournis dans le champ statusInfo.

   Dans CertConfirmContent, l'omission d'une structure CertStatus correspond à un certificat fournis dans la réponse précédente indiquant le rejet du certificat. Donc, un CertConfirmContent vide peut être utilisé pour indiquer le rejet de tous les certificats émis.

Contenu du message général PKI


InfoTypeAndValue ::= SEQUENCE {
    infoType OBJECT IDENTIFIER,
    infoValue ANY DEFINED BY infoType OPTIONAL
} -- où {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

Certificat de chiffrement de protocole CA

Peut être utilisé par l'EE pour obtenir un certificat depuis la CA à utiliser pour protéger les informations sensibles durant le protocole:
GenMsg: {id-it 1}, ‹ absent ›
GenRep: {id-it 1}, Certificate | ‹ absent ›
    
Les EE doivent s'assurer que le certificat correct est utilisé pour ce but.

Types de paire de clé de signature

Peut être utilisé par l'EE pour obtenir la liste des algorithmes de signature dont les valeur de clé publique peuvent être certifiés par la CA. Noter que dans le but de cet échange, rsaEncryption et rsaWithSHA1, par exemple, sont considérés équivalents.
GenMsg: {id-it 2}, ‹ absent ›
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Types de paire de clé d'agrément de clé/chiffrement

Peut être utilisé par le client pour obtenir la liste des algorithmes d'agrément de clé/chiffrement dont les valeurs de clé publique peut être certifiés par la CA.
GenMsg: {id-it 3}, ‹ absent ›
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Algorithme symétrique préféré

Peut être utilisé par le client pour obtenir l'algorithme de chiffrement préféré de la CA pour les informations confidentielles qui nécessitent d'échanger entre l'EE et la CA.
GenMsg: {id-it 4}, ‹ absent ›
GenRep: {id-it 4}, AlgorithmIdentifier

Paire de clé CA mise à jour

Peut être utilisé par la CA pour annoncer une mise à jour de clé de CA
GenMsg: {id-it 5}, CAKeyUpdAnnContent

CRL

Peut être utilisé par le client pour obtenir une copie de la dernière CRL.
GenMsg: {id-it 6}, ‹ absent ›
GenRep: {id-it 6}, CertificateList

Identifiant d'objet non supporté

C'est utilisé par le serveur pour retourner une liste d'identifiants d'objets qu'il ne reconnaît ou supporte.
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

Paramètres de paire de clé

Peut être utilisé par l'EE pour demander les paramètres de domaine à utiliser pour générer la paire de clé pour certains algorithmes à clé publique. Peut être utilisé, par exemple, pour demander P, Q et G appropriés pour générer la clé DH/DSA, ou pour demander un jeu de courbe elliptique.
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | ‹ absent ›

   Un infoValue absent dans GenRep indique que l'algorithme spécifié dans GenMsg n'est pas supporté. Les EE doivent s'assurer que les paramètres sont acceptable et que le message GenRep est authentifié.

passphrase de révocation

Peut être utilisé par l'EE pour envoyer un passphrase à une CA/RA pour authentifier un demande de révocation.
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, ‹ absent ›

Tags de langue supportés

Peut être utilisé pour déterminer le tag de langue approprié à utiliser dans les messages suivants. L'émeteur envoie sa liste de langages supportés ( par ordre de préférence ); le destinataire retourne celui qu'il souhaite utiliser. Si aucun des tags proposés ne sont supportés, une erreur doit être retournée.
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

Contenu de réponse PKI Général


GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Cette structure de données peut être utilisée par l'EE, CA ou RA pour transporter des informations d'erreur
ErrorMsgContent ::= SEQUENCE {
    pKIStatusInfo PKIStatusInfo,
    errorCode INTEGER OPTIONAL,
    errorDetails PKIFreeText OPTIONAL
}

   Ce message peut être généré à tout moment durant une transaction PKI. Si le client envoie cette requête, le serveur doit répondre avec une réponse PKIConfirm, ou un autre ErrorMsg si une partie de l'en-tête n'est pas valide. Chaque partie doit traiter ce message comme la fin de la transaction (si une transaction est en cours).

   Si la protection est souhaitée dans le message, le client doit le protéger en utilisant la même technique que le message de début de la transaction. La CA doit toujours le signer avec une clé de signature.

Demande et réponse d'interrogation

Cette paire de message est prévue pour manipuler les scénario dans lequel le client a besoin d'interroger le serveur pour déterminer le statut d'une transaction ir, cr, ou kur en cours. (par exemple quand le PKIStatus "waiting" a été reçu).
PollReqContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER }
    
PollRepContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER,
    checkAfter INTEGER, -- time in seconds
    reason PKIFreeText OPTIONAL }

   Les clauses suivantes décrivent quand les messages d'interrogation sont utilisés, et comment ils sont utilisés. Il est assumé que plusieurs messages certConf peuvent être envoyés durant les transactions. Il y'en aura un envoyé en réponse à chaque ip, cp, kup qui contient un CertStatus pour un certificat émis.

1. En réponse à un message ip, cp, ou kup, un EE va envoyer un certConf pour tous les certificats émis et, suivant le ack, un pollReq pour tous les certificats en attente.
2. En réponse à un message à un pollReq, une CA/RA va retourner un ip, cp, kup si un ou plusieurs certificats sont prêts; sinon, elle retourne un pollRep
3. Si l'EE reçois un pollRep, il attend au moins checkAfter avant d'envoyer un autre pollReq
4. Si nu ip, cd, ou kup est reçu en réponse à un pollReq, alors il sera traité de la même manière que la réponse initiale.


_______________________________START
_________________________________|
_________________________________v
______________________________Send_ir
_________________________________|_ip
_________________________________v
____________________________Check_status
____________________________of_returned_‹------------------------+
_______________________________certs_____________________________|
_________________________________|_______________________________|
_______+------------------------›|‹------------------+___________|
_______|_________________________|___________________|___________|
_______|________(issued)_________v_______(waiting)___|___________|
_____Add_to_‹-----------_Check_CertResponse_------›_Add_to_______|
____conf_list___________for_each_certificate______pending_list___|
_________________________________/_______________________________|
________________________________/________________________________|
___________________(conf_list)_/_____(empty_conf_list)___________|
______________________________/_____________________ip___________|
_____________________________/_________________+----------------+
______(empty_pending_list)__/__________________|____pRep
________END_‹----_Send_certConf_________Send_pReq------------›Wait
_________________________|_________________^___^_______________|
_________________________|_________________|___|_______________|
_________________________+-----------------+___+---------------+
____________________________(pending_list)

Dans l'échange suivant, l'EE s'enregistre pour 2 certificats en une seule demande:
Step__End_Entity_______________________PKI
____1___Format_ir
____2____________________-›_ir______-›
____3____________________________________Handle_ir
____4____________________________________Manual_intervention_is
_________________________________________required_for_both_certs.
____5____________________‹-_ip______‹-
____6___Process_ip
____7___Format_pReq
____8____________________-›_pReq_____-›
____9____________________________________Check_status_of_cert_requests
____10___________________________________Certificates_not_ready
____11___________________________________Format_pRep
____12___________________‹-_pRep_____‹-
____13__Wait
____14__Format_pReq
____15___________________-›_pReq_____-›
____16___________________________________Check_status_of_cert_requests
____17___________________________________One_certificate_is_ready
____18___________________________________Format_ip
____19___________________‹-_ip_______‹-
____20__Handle_ip
____21__Format_certConf
____22___________________-›_certConf_-›
____23___________________________________Handle_certConf
____24___________________________________Format_ack
____25___________________‹-_pkiConf___‹-
____26__Format_pReq
____27___________________-›_pReq_____-›
____28___________________________________Check_status_of_certificate
____29___________________________________Certificate_is_ready
____30___________________________________Format_ip
____31___________________‹-_ip_______‹-
____31__Handle_ip
____32__Format_certConf
____33___________________-›_certConf_-›
____34___________________________________Handle_certConf
____35___________________________________Format_ack
____36___________________‹-_pkiConf__‹-

Fonctions de gestion de PKI obligatoire

   Cette section décris les fonctions qui sont obligatoires dans le sens que toutes les implémentations EE, CA et RA doivent être capable de fournir les fonctionnalités décrites.

Initialisation de la CA root

   Une CA root nouvellement créée doit produire un certificat auto-émis, qui est une structure Certificate avec le profile définis pour le certificat "newWithNew" émis par la mise à jours de la clé CA.

   Pour que le certificat de la CA soit utile aux entités finales qui ne l'obtiennent pas par des moyens tiers, la CA doit également produire une empreinte pour son certificat. La structure de données utilisée pour gérer l'empreinte est OOBCertHash.

Mise à jours de la clé CA

   Les clés CA ( comme toutes les autres clés) on une durée de vie finie et doivent être mis à jours périodiquement. Les certificats NewWithNew, NewWithOld, et OldWithNew peuvent être émis par la CA pour aider les EE existantes qui possèdent l'ancien certificat auto-signé (OldWithOld) à passer de manière sécurisée au nouveau certificat (NewWithNew), et pour aider les nouvelles entités qui ont NewWithNew à obtenir OldWithOld pour la vérification de donné existante.

Initialisation de CA subordonnée

   Du point de vue des protocoles de gestion de PKI, l'initialisation d'une CA subordonnée est la même que l'initialisation d'un entité finale. La seule différence est que la CA subordonnée doit également produire une liste de révocation initiale.

Production de CRL

   Avant d'émettre des certificats, une CA nouvellement établie ( qui émet des crls ) doit produire des versions vides de chaque CRL qui sont périodiquement produites.

Demande d'information PKI

   Quand une entité PKI (CA, RA, ou EE) souhaite acquérir des informations sur le status courant d'une CA, elle peut lui envoyer une demande pour de telles informations.

   La CA doit répondre à le demande en fournissant toutes les informations demandées. Si certaines informations ne peuvent pas être fournies, une erreur doit être retournée.

   Si des PKIMessages sont utilisés pour demander et fournir cette information, alors la requête doit être le message GenMsg, la réponse doit être le message GenRep, et l'erreur doit être le message Error. Ce messages sont protégés en utilisant un MAC basé sur une information de secret partagé, ou en utilisant un autre moyen authentifié (si l'EE a un certificat existant).

Cross Certification

   Le demandeur CA est la CA qui va devenir le sujet du cross-certificat; le répondeur CA va devenir l'émetteur du cross-certificat. Le demandeur CA doit être "up and running" avant d'initialiser l'opération de cross-certification.

Schéma demande-réponse une voie

   Le schéma de cross-certification est essentiellement une opération one-way; c'est à dir, quand réussit, cette opération résulte en la création d'un nouveau cross-certificat. Si le pré-requis est que ce cross-certificat soit créé dans les 2 direction, alors chaque CA, en retour, doit initialiser une opération de cross-certification ( ou utiliser un autre schéma ).

   Ce schéma est prévu quand les 2 CA en question peuvent déjà se vérifier mutuellement leur signature. Description détaillée:

   La cross certification est initiée à une CA connue comme répondeur. L'administrateur CA pour le répondeur identifie la CA qu'il veut cross certifier et l'équipement du répondeur génère un code d'autorisation. L'administrateur du répondeur passe ce code d'autorisation à la CA demandeuse via un moyen externe à l'administrateur de la CA demandeuse, qui utilise ce code pour initier l'échange on-line.

   Le code d'autorisation est utilisé pour l'authentification et l'intégrité. C'est fait en générant une clé symétrique basée sur le code d'autorisation et en utilisant la clé symétrique pour générer des MAC pour tous les messages échangés. ( Une authentification peut alternativement être faite en utilisant les signature au lieu des MAC, si les CA sont capable de récupérer et valider les clés publiques requise.)

   La CA demandeuse initie l'échange en générant un demande de cross-certification ( ccr ) avec un nouveau nombre aléatoire. La CA demandeuse envoie le message ccr au répondeur. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccr, le répondeur valide le message et le MAC, sauvegarde le nombre aléatoire du demandeur, et génère son propre nombre aléatoire. Il génère ainsi un nouveau certificat qui contient la clé publique de la CA demandeuse et est signée avec la clé privée du répondeur. Le répondeur répond avec un message ccp. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccp, la CA demandeuse valide le message et le MAC. la CA demandeuse répond avec le message certConf. Les champs dans ce message sont protégés des modifications avec un MAC basé sur le code d'autorisation. La CA demandeuse peut écrire le certificat dans le dépôt comme aide pour la construction de future chemins de certificats.

   Une fois le message certConf reçu, le répondeur valide le message et le MAC, et envoi un accusé en utilisant le message PKIConfirm. Il peut également publier le certificat.

Notes

1. Le message ccr doit contenir une demande de certification complète: c'est à dire, tous les champs exceptés le numéro de série doivent être spécifiés par la CA demandeuse.
2. Le message ccp devrait contenir le certificat de vérification du répondeur; si présent, la CA demandeuse doit vérifier ce certificat.

   Une version plus simple et non-interactive de la cross-certification peut également être envisagé, dans lequel la CA émettrice obtient la clé publique de la CA depuis un dépôt, la vérifie via un mécanisme externe, et créé et publie le cross-certificat sans le concours explicite de la CA.

Initialisation de l'entité finale

   Comme avec les CA, les entités finales doivent être initialisées. L'initialisation des entités finales nécessite au moins 2 étapes:

- Acquisition des informations de la PKI
- Vérification tiers d'une clé publique de CA root

Acquisition d'information PKI

   Les informations requises sont:

- La clé publique de la CA racine courante
- (Si la CA certifiante n'est pas la CA racine) le chemin de certification depuis la CA racine jusqu'à la CA certifiante, avec les listes de révocation appropriés.
- Les algorithmes et paramètres d'algorithme que la CA certifiante supporte pour chaque utilisation.

   Des informations additionnelles peuvent être requises ( ex: extensions supportées ou informations de stratégie de CA) pour pouvoir produire une demande de certification qui sera réussie. Cependant, par simplicité, on n'oblige par l'EE d'obtenir ces information via les messages PKI. Le résultat final est simplement que certaines demandes de certification peuvent échouer (ex: si l'EE veut générer sa propre clé de chiffrement, mais que la CA ne le permet pas).

Vérification Out-of-Band de la clé CA racine

   Une EE doit posséder de manière sécurisée la clé publique de sa CA racine. Une méthode consiste à fournir à l'EE une empreinte du certificat de la CA via un moyen externe sécurisé. L'EE peut ainsi utiliser le certificat de la CA.

Demande de certificat

   Une EE initialisée peut demander un certificat additionnel à tout moment. Cette demande sera faite en utilisant le message de demande de certification (cr). Si l'EE possède déjà une paire de clé de signature ( avec un certificat de vérification correspondant ), alors ce message cr sera protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat dans un CertRepMessage.

Mise à jour de clé

   Quand une paire de clé va expirer, l'entité finale peut demander une mise à jour de clé; c'est à dire, qu'elle peut demander à la CA d'émettre un nouveau certificat pour une nouvelle paire de clé (ou, dans certaines circonstances, un nouveau certificat pour la même paire de clé (. La demande est faite en utilisant un message de demande de mise à jour de clé (kur). Si l'EE possède déjà une paire de clé de signature ( avec le certificats de vérification correspondant ), alors ce message sera typiquement protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat ( si la demande est réussie) dans une réponse de mise à jour de clé (kup), qui est syntaxiquement identique à un CertRepMessage.

Négociation de version

   Cette section définis la négociation de version utilisée pour supporter d'anciens protocoles entre client et serveurs.

   Si un client connaît les versions de protocoles supportés par le serveur (ex: depuis un précédent échange PKIMessage ou via un moyen externe ), il doit envoyer un PKIMessage avec la version la plus haute supportée par lui et le serveur. Si un client ne connaît pas les versions supportées par le serveur, il doit envoyer un PKIMessage en utilisant la version la plus élevée qu'il supporte.

   Si un serveur reçoit un message avec une version qu'il supporte, alors la version du message de réponse doit être la même que la version reçue. Si un serveur reçoit un message avec une version plus élevée ou moins élevée qu'il ne supporte, il doit envoyer en ErrorMsg avec le bit unsupportedVersion ( dans le champ failureInfo de pKIStatusInfo ). Si la version reçue est supérieur à la versions supportée, la version dans le message d'erreur doit être la plus haute version que le serveur supporte; si la version reçue est inférieur à la version la plus basse supportée par le serveur alors la version dans le message d'erreur doit être la version la plus basse que le serveur supporte.

   Si un client reçoit un ErrorMsgContent avec le bit unsupportedVersion et une version qu'il supporte, il peut retenter la requête avec cette version.

Support des implémentation rfc2510

   La rfc2510 ne spécifie pas le comportement des implémentation recevant des versions qu'il ne comprend pas vu qu'il ne comprend qu'une seule version. Avec l'introduction de cette révision, le comportement suivant sur le versionning est recommandé.

Clients parlant aux serveurs rfc2510

   Si, après avoir envoyé un message cmp2000, un client reçois un ErrorMsgContent avec une version de cmp1999, alors il doit annuler la transaction. Il peut ensuite retenter la transaction en utilisant des message cmp1999.

   Si un client reçois un PKIMessage non-erreur avec une version de cmp1999, il peut décider de continuer la transaction en utilisant les sémantiques rfc2510. S'il choisis de ne pas le faire et que la transaction n'est pas terminée, il doit annuler la transaction et envoyer un ErrorMsgContent avec une version de cmp1999.

Serveurs reçevant des PKIMessage cmp1999

   Si un serveur reçoit un message cmp1999, il peut revenir à un comportement rfc2510 et répondre avec des messages cmp1999. S'il choisi de ne pas le faire, il doit envoyer un ErrorMsgContent.

Considérations de sécurité

POP avec une clé de déchiffrement

   Dans les protocoles spécifiés avant, quand une entité finale doit prouver la possession d'un clé de déchiffrement, il est effectivement challengé pour déchiffrer quelque-chose (son propre certificat). Ce schéma (et beaucoup d'autres) peut être vulnérable à une attaque si le propriétaire de la clé de déchiffrement en question peut être dupé en déchiffrant un challenge arbitraire et en retournant le texte en clair à un attaquant. Bien que dans cette spécification, d'autres problèmes de sécurité sont requis pour que cette attaque réussise, il est concevable que des services futures pourraient être vulnérable à de telles attaques. Pour cette raison, on réitère la règle générale que les implémentations devraient suivre sur le déchiffrement arbitraire et la révélation du texte récupéré.

POP en exposant la clé privée

   Noter également qu'exposer une clé priée à la CA/RA comme technique POP peut exposer à des risques de sécurité. Les implémenteurs doivent faire preuve de prudence en sélectionnant et utilisant ce mécanisme POP particulier.

Appendice A. Raisons de la présence des RA

   Les raisons qui justifient la présence d'un RA peut être séparés en ceux, d'un part, qui sont dûs à des facteurs techniques, et ceux qui d'autre part sont de nature organisationnelles. Les raisons techniques sont les suivante:

- Si des jetons hardwares sont utilisé, toutes les entités finales n'ont pas l'équipement nécessaire à les initialiser; l'équipement RA peut inclure les fonctionnalités nécessaires.
- Certaines entités finales peuvent ne pas avoir la capacité de publier les certificats; de même, la RA peut être utilisé pour cela.
- La RA sera capable d'émettre des demandes de révocation signées à la demande des entités finales associées avec elle, alors que l'entité final peut ne pas être en mesure de le faire ( Si la paire de clé est complètement perdue ).

   Certaines raisons organisationnelles qui demandent la présente d'une RA sont:

- Il peut y avoir une raison de coût de concentrer les fonctionnalités dans un équipement RA plutôt que de fournir ces fonctionnalités à tous les EE.
- Établir des RA dans une organisation peut réduire le nombre de CA requises, ce qui est parfois désirable
- Pour beaucoup d'applications, Il y aura déjà en place une structure administrative pour que les candidats pour le rôle de RA soit facile à trouver.

Appendice B. Utilisation de passphrase de révocation

   Une demande de révocation doit incorporer des mécanismes de sécurité prévu, incluant une authentification propre, pour réduire la probabilité d'attaques DOS réussies. Une signature numérique dans la requête peut fournir l'authentification requise, mais il y a des circonstances sous lesquelles un mécanisme alternatif peut être souhaité (par ex: quand une clé privée n'est plus accessible et que l'entité souhaite demander une révocation avant de re-certifier une autre paire).

   Pour de telles circonstances, un PasswordBasedMac dans la demande est également obligatoire pour supporter cette spécification si les demandes de révocations sont également supportées et si les informations de secret partagé peuvent être établis entre le demandeur et le répondeur avant le besoin de révocation.

   Un mécanisme qui est utilisé dans certains environnement est la passphrase de révocation, dans lequel une valeur d'entropy suffisante ( ex: une passphrase relativement plus longue qu'un mot de passe court) est partagé entre (seulement) l'entité et la CA/RA à un certain moment avant la révocation; cette valeur est ensuite utilisé pour authentifier la demande de révocation.

   Dans cette spécification, la technique suivante pour établir une information à secret partagé est optionnelle. Son utilisation précise dans les messages CMP sont comme suit.

   L'OID et la valeur spécifié dans la section "passphrase de révocation" peuvent être envoyé dans un message GenMsg à tout moment, ou peut être envoyé dans le champ generalInfo du PKIHeader d'un PKIMessage a tout moment. ( En particulier, EncryptedValue peut être envoyé dans l'en-tête du message CertConf qui confirme l'acceptation des certificats requis dans une demande d'initialisation ou une demande de certification.). Cela transmet une passphrase de révocation choisie par l'entité ( ex: les octets déchiffrés du champ encValue) à la CA/RA; en outre, le transfert est accomplis avec les caractéristiques de confidentialité appropriés ( parce que la passphrase est chiffrée avec le protocolEncryptionKey de la CA/RA).

   Si une CA/RA reçois la passphrase de révocation dans un GenMsg, elle doit construire et envoyer un message GenRep qui inclus l'OID ( avec une valeur absente) spécifiée dans la section "passphrase de révocation". Si la CA/RA reçois la passphrase de révocation dans le champ generalInfo d'un PKIHeader d'un PKIMessage, elle doit inclure l'OID ( avec une valeur absente) dans le champ generalInfo du PKIHeader du PKIMessage de réponse correspondant. Si la CA/RA n'arrive pas à retourner le message de réponse approprié, elle doit envoyer un message d'erreur avec un status de rejet et optionnellement, un jeu de raison failInfo.

   Le champ valueHint de EncryptedValue peut contenir un identifiant de clé (choisi par l'entité finale, avec la passphrase elle-même) pour assister à la récupéraion de la passphrase correcte (ex, quand la demande de révocation est construite par l'entité et reçue par la CA/RA).

   Le messages de demande de révocation est protégé par un PasswordBasedMac, avec la passphrase de révocation comme clé. Si approprié, le champ senderKID dans le PKIHeader peut contenir la valeur précédemment transmise dans valueHint.

   En utilisant la technique spécifiée ci-dessus, la passphrase de révocation peut être initialement établie et mise à jour à tout moment sans nécessiter de messages supplémentaires ou d'échange externes. Par exemple, le message de demande de révocation lui-même (protégé et authentifié via un MAC qui utilise la passphrase de révocation comme clé) peut contenir, dans le PKIHeader, une nouvelle passphrase de révocation à utiliser pour authentifier de futures demandes de révocation pour tout autre certificat de l'entité. Dans certains environnements cela peut être préférable aux mécanismes qui révèlent la passphrase dans le message de demande de révocation, vu que cela peut permettre une attaque DOS dans laquelle la passphrase révélée est utilisée par un tier non-autorisé pour authentifier les demandes de révocation pour les autres certificat de l'entité. Cependant, parce que la passphrase n'est pas révélée dans la requête, il n'y a pas de pré-requis pour que la passphrase soit toujours mise à jours quand la demande de révocation est faite ( c'est à dire, la même passphrase peut être utilisée par une entité pour authentifier les demandes de révocation pour différents certificats à différents moments).

   De plus, la technique ci-dessus peut fournir une protection cryptographique forte sur tout le message de demande de révocation même quand une signature numérique n'est pas utilisée. Les techniques qui font de l'authentification de la demande de révocation en révélant simplement la passphrase de révocation ne fournissent pas de protection cryptographique sur les champs du message (donc une demande de révocation d'un certificat peut être modifié par un tier non autorisé pour révoquer un autre certificat pour cette entité).

Appendice C - Clarification du conportement des messages de demande

Dans le cas des mises à jours de la rfc4211, qui apporte des problème d'interprétation ou d'intéropérabilité, la rfc4211 devrait être le document normatif. Les définitions suivante viennent de la rfc4211. Elles sont inclues ici pour codifier les clarifications de comportement; sinon toutes les syntaxes et sémantiques sont identiques à la rfc4211.
CertRequest ::= SEQUENCE {
    certReqId INTEGER,
    certTemplate CertTemplate,
    controls Controls OPTIONAL }
    
-- Si certTemplate est une séquence vide, alors les contrôles peuvent contenir le contrôle
-- id-regCtrl-altCertTemplate, spécifiant un template pour un certificat autre qu'un
-- certificat à clé-publique x509v3. Inversement, si certTemplate n'est pas vide (au moins
-- un champ est présent), alors les contrôles ne doivent pas contenir id-regCtrl-altCertTemplate.
-- Le nouveau contrôle est définis comme suit:
    
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
    
POPOSigningKey ::= SEQUENCE {
    poposkInput [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier AlgorithmIdentifier,
    signature BIT STRING }
    
-- La signature (en utilisant AlgorithmIdentifier) est dans la valeur encodée DER de poposkInput.
-- Note: si CertReqMsg certReq certTemplate ( ou le contrôle altCertTemplate) contient les valeurs
-- subject et publicKey, alors poposkInput doit être omis et la signature doit être calculée dans
-- la valeur encodée DER de CertReqMsg certReq ( ou la valeur encodée DER de AltCertTemplate).
-- Si certTemplate/altCertTemplate ne contient ni le sujet ni la clé publique, poposkInput doit
-- être présent et doit être signé.
    
POPOPrivKey ::= CHOICE {
    thisMessage [0] BIT STRING,
    
-- Le type de "thisMessage" est donné en chaîne de bit dans la rfc4211; mais devrait être un
-- "EncryptedValue", en accord avec cette spécification.
    
    subsequentMessage [1] SubsequentMessage,
    dhMAC [2] BIT STRING }

Appendice D. profils de messages de gestion

   Cet appendice contient les profils détaillés pour ces PKIMessages qui doivent être supportés par les implémentations conformes. Les profils pour les PKIMessages utilisés dans les opérations de gestion PKI suivant sont fournis:

- Enregistrement/certification initiale
- Schéma authentifié de base
- Demande de certificat
- Mise à jour de clé

Règles générales pour l'interprétation de ces profils

1. Où les champs OPTIONAL ou DEFAULT ne sont pas mentionnés dans les profiles, ils doivent être absent du message. Les champs obligatoire ne sont pas mentionnés s'il ont une valeur évidente. (ex dans la version de cette spécification, pvno est toujours 2).
2. Où les structures se trouvent dans plus d'un message, elles sont profilés séparément comme appropriées.
3. Les algorithmIdentifier des structures PKIMessage sont profilés séparément.
4. Un DN X.500 spécial est appelé le "NULL-DN"; cela signifie un DN contenant une séquence RelativeDistinguishedNames de longueur 0 (son encodé DER est alors '3000'H).
5 Où un GeneralName est requis pour un champ, mais qu'aucune valeur prévue n'est disponible (ex: une entité produit une demande avant de connaître son nom), alors le GeneralName doit être un NULL-DN. Cette valeur spéciale peut être appelée NULL-GeneralName.
6. Où un profil omit de spécifier la valeur pour un GeneralName, la valeur NULL-GeneralName doit être présente dans le champs PKIMessage concerné.
7. Où toute ambiguïté peut se produire à cause du nommage des champs, le profile les nomme en utilisant une notation "point" (ex: certTemplate.subject signifie le champ subject dans un champ appelé certTemplate).
8. Où une séquence de types fait partie d'un message, une notation en tableau basé sur des 0 est utilisée pour décrire les champs dans la séquence (ex: crm[0].certReq.certTemplate.subject réfère à un sous-champ du premier CertReqMsh contenu dans un message de demande).
9. Tous les échanges de message PKI décris plus bas dans cet appendice nécessitent qu'un message certConf soit envoyé par l'entité qui initie et un PKIConfirm par l'entité qui répond. Le PKIConfirm n'est pas inclus dans certains profiles donnés vu que sont contenu est NULL et son header peut être utilisé pour le protectionAlg.

Utilisation des algorithmes

   La table suivante contient les définitions de l'utilisation d'algorithme dans les protocoles de gestion PKI. Les colonnes dans la table sont:

Name: Un identifiant utilisé pour les profiles de message
Use: Une description d'ou et pourquoi l'algorithme est utilisé
Mandatory: Un AlgorithmIdentifier qui doit être supporté par les implémentations conformes.
others: Alternatives à AlgorithmIdentifier.

Name_________Use________________________________________________Mandatory__________________Others
MSG_SIG_ALG__Protection des messages en utilisant une signature_DSA/SHA-1__________________RSA/MD5,ECDSA,...
MSG_MAC_ALG__Protection des messages en utilisant MAC___________PasswordBasedMac___________HMAC, X9.9,...
SYM_PENC_ALG_Chiffrement symétrique de la clé privée de l'EE____3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...
PROT_ENC_ALG_Chiffrement asymétrique de la clé privée___________D-H________________________RSA,ECDH,...
PROT_SYM_ALG_Chiffrement symétrique des bits de la clé privée___3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...

AlgorithmIdentifier mandatoire et spécifications:
DSA/SHA-1:
    AlgId: {1 2 840 10040 4 3};
    
Digital Signature Standard [FIPS-186]
    Public Modulus size: 1024 bits.
    
PasswordBasedMac:
    AlgId: {1 2 840 113533 7 66 13}, avec SHA-1 {1 3 14 3 2 26} et HMAC-SHA1 {1 3 6 1 5 5 8 1 2};
    
Secure Hash Standard [FIPS-180] and [RFC2104]
    HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1, "Shared secret information")
    
3-DES:
    AlgId: {1 2 840 113549 3 7}; (used in RSA's BSAFE and in S/MIME).
    
D-H:
    AlgId: {1 2 840 10046 2 1};
    
[ANSI-X9.42]
    Public Modulus Size: 1024 bits.
    DomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g^q = 1 mod p
        q INTEGER, -- prime factor of p-1
        j INTEGER OPTIONAL, -- cofactor, j›=2
        validationParms ValidationParms OPTIONAL
    }
    ValidationParms ::= SEQUENCE {
        seed BIT STRING, -- seed for prime generation
        pGenCounter INTEGER -- parameter verification
    }

Profile POP

Les champs POP utilisé (dans le champ signature du champ pop de la structure ProofOfPossession) en prouvant la possession d'une clé privée de signature qui correspond à une clé publique de vérification pour laquelle un certificat a été demandé.
Field_______________Value_________Comment
algorithmIdentifier_MSG_SIG_ALG___Seul la protection de la signature est permise pour cette preuve
signature___________present_______bits calculés en utilisant MSG_SIG_ALG

   La preuve de possession d'une clé privée de déchiffrement qui correspond à une clé public de chiffrement pour laquelle un certificat a été demandé n'utilise pas ce profile; le champ CertHash du message certConf est utilisé à la place.

   Toutes les CA/RA ne font pas de POP dans le protocole de demande de certification ( comment POP est faite peut être un problème de stratégie explicite pour une CA). Cependant, cette spécification mandate que les entités CA/RA doivent faire une POP comme partie du processus de certification. Toutes les entités finales doivent être préparée à fournir une POP.

Enregistrement/certification initial - schéma authentifié de base

   Une entité finale ( non initialisée ) demande un (premier) certificat à une CA. Quand la CA répond avec une message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA envoie en PKIConfirm en retour, terminant la transaction. Tous les message sont authentifiés.

   Ce schéma permet à l'EE de demander une certification d'une clé publique générée localement (typiquement une clé de signature). L'EE peut également choisir de demander la génération et la certification centralisée d'une autre paire de clé (typiquement une paire de clé de chiffrement). La certification peut seulement être demandée pour en clé publique générée localement.

   L'EE doit supporter le POP d'une clé privée, associée avec la clé publique générée localement.

  Préconditions:

1. L'EE peut authentifier la signature de la CA via un moyen externe
2. L'EE et la CA partage une clé MAC symétrique

Flux de messages:
Step#_End_entity___________________________PKI
______1___format_ir
______2______________________-›___ir______-›
______3________________________________________handle_ir
______4________________________________________format_ip
______5______________________‹-___ip______‹-
______6___handle_ip
______7___format_certConf
______8______________________-›___certConf_-›
______9________________________________________handle_certConf
_____10________________________________________format_PKIConf
_____11______________________‹-___PKIConf__‹-
_____12___handle_PKIConf

   Pour ce profile, on mandate que l'EE doit inclure tous CertReqMsg dans un simple PKIMessage, et que le PKI (CA) doit produire une seul réponse PKIMessage qui contient la réponse complète (ex: incluant la seconde paire de clé optionnelle, s'il elle a été demandée et si la génération de la clé centralisée est supportée). Par simplicité, on mandate également que ce message doit être le final (ex: pas d'utilisation du status "waiting").

   L'EE a une interaction out-of-band avec la CA/RA. Cette transaction établis le secret partagé, le referenceNumber et optionnellement le dn utilisé pour sender et subject dans le template du certificat. Il est recommandé que le secret partagé ait au moins 12 caractères de long.

Demande de certificat

   Une EE (initialisé) demande un certificat depuis une CA. Quand la CA répond avec un message contenant un certifica, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est cr ou cp
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg

Demande de mise à jour de clé

   Une entité finale ( initialisée ) demande un certificat à une CA ( pour mettre à jours la paire de clé et/ou le certificat correspondant qu'il possède déjà ). Quand la CA répond avec un message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est kur ou kup
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg
- regCtrl OldCertId devrait être utilisé

Appendice E: Profile de message de gestion PKI

   Cet appendice contient les profile pour les PKIMessages qui peuvent être supportés par les implémentations. Les profiles pour les PKIMessages utilisé dans les opération de gestion PKI suivant sont fournis:

- Mise à jours de clé CA racine
- Demande/réponse d'informations
- Demande/réponse de cross-certification
- Initialisation in-band en utilisant en certificat d'identité externe.

Certificats auto-signés

Le profile sur la manière dont un certificat peut être auto-signé. Ces structures sont utilisées pour les distributions de clés publiques de CA. Cela peut se produire d'une des 3 manières.
Type________Fonction
newWithNew__Une vrai certificat auto-signé; la clé publique contenue doit être utilisable pour vérifier la signature
oldWithNew__La précédente clé CA Root signée avec la nouvelle clé privée.
newWithOld__La nouvelle clé publique CA root signée avec la précédente clé privée.

   De tels certificats doivent contenir les valeurs sensibles pour tous les champs. Par exemple, quand présent, subjectAltName doit être identique à issuerAltName, et, quand présent, keyIdentifier doit contenir les valeurs appropriées, etc.

Mise à jours de clé Root

   Une CA racine met à jour sa paire de clé. Elle produit ainsi un message d'annonce de mise à jours de clé CA qui peut être disponible (via certains mécanismes de transport) aux EE concernées. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse d'information PKI

   L'entité finale envoie un message général à la PKI demandant des détails qui sont requis pour d'autres opérations de gestion PKI. La RA/CA répond avec une réponse générale. Si une RA génère la réponse, alors il va simplement transférer le message équivalent qui a été précédemment reçus de la CA, en ajoutant possiblement les certificats dans les champs extraCerts du PKIMessage. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse de cross-certification

   La création d'un simple cross-certificat (ex: pas 2 en même temps). La CA demandeuse peut choisir qui est responsable pour la publication du cross-certificat créé par la CA répondante via l'utilisation du contrôle PKIPublicationInfo.

  Préconditions:

1. La CA répondante peut vérifier l'origine de la demande avant de traiter la demande.
2. La CA demandeuse peut authentifier l'authenticité de l'origine de la réponse avant de traiter la réponse.

   L'utilisation de confirmation de certification et la confirmation du serveur correspondant est déterminé par le champ generalInfo dans le PKIHeader. Le profile suivant ne mandate pas le supporte pour ces confirmations.

Initialisation in-band via certificat externe

   Une EE ( non-initialisée ) souhaite s'initialiser dans la PKI avec une CA, CA-1. Elle utilise, pour l'authentification, un certificat d'identité pré-existant émis par une autre CA (externe), CA-X. Une relation de confiance doit déjà avoir été établis entre CA-1 et CA-X pour que CA-1 puisse valider le certificat de l'EE signé par CA-X. De plus, certains mécanismes doivent déjà avoir été établis dans le PSE de l'EE qui lui permet d'authentifier et vérifier les PKIMessage signés par CA-1.

   L'EE envoie une demande d'initialisation pour démarrer la transaction. Quand CA-1 répond avec un message contenant le nouveau certificat, l'EE répond avec une confirmation de certificat. CA-1 répond avec un PKIConfirm pour terminer la transaction. Tous les messages sont signés ( les messages EE sont signés en utilisant la clé privée qui correspond à la clé publique dans son certificat d'identité externe, les messages CA-1 sont signés en utilisant la clé privée qui correspond à la clé publique dans un certificat qui peut être chaîné à une ancre de confiance dans le PSE de l'EE). Le profile pour cet échange est identique à celui donné précédemment excepté:

- L'EE et CA-1 ne partagent pas de clé MAC symétrique
- Le nom de l'émetteur dans ir doit être présent
- protectionAlg de MSG_SIG_ALG doit être utilisé dans tous les messages
- le certificat d'identité externe doit être géré dans le champ extraCerts de ir
- senderKID et recipKID ne sont pas utilisés.
- body est ir ou ip
- Les bits de protections sont calculés en accord avec le champ protectionAlg
^
28 septembre 2013

htmlpdflatexmanmd




rfc4230

rfc4230

Attribut opérationnel entryUUID

   cet attribut maintient un Universally Unique IDentifier assigné par le serveur pour l'objet.

La syntaxe UUID telle que définie dans la rfc 4122:
UUID = time-low "-" time-mid "-"
    time-high-and-version "-"
    clock-seq-and-reserved
    clock-seq-low "-" node
time-low = 4hexOctet
time-mid = 2hexOctet
time-high-and-version = 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low = hexOctet
node = 6hexOctet
hexOctet = hexDigit hexDigit
hexDigit =
    "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
    "a" / "b" / "c" / "d" / "e" / "f" /
    "A" / "B" / "C" / "D" / "E" / "F"

Dans LDAP, les UUID sont encodés en utilisant la représentation de chaîne ASCII, par exemple: "597ae2f6-16a6-1027-98f4-d28b5365dc14"
La description LDAP pour UUID est: ( 1.3.6.1.1.16.1 DESC 'UUID' )

Règle de correspondance uuidMatch

   règle d'égalité. La sémantique est la même que octetStringMatch. La définition LDAP de cette règle est: ( 1.3.6.1.1.16.2 NAME 'uuidMatch' SYNTAX 1.3.6.1.1.16.1 )

uuidOrderingMatch

   Règle d'ordonnancement. La sémantique est la même que octetStringOrderingMatch. La définition LDAP pour uuidOrderingMatch est: ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' SYNTAX 1.3.6.1.1.16.1 )

Attribut entryUUID


( 1.3.6.1.1.16.4 NAME 'entryUUID'
    DESC 'UUID of the entry'
    EQUALITY uuidMatch
    ORDERING uuidOrderingMatch
    SYNTAX 1.3.6.1.1.16.1
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

   Les serveurs devraient générer et assigner un nouvel UUID à chaque entrée ajoutée. une entrée UUID est inchangeable.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4231

rfc4231

Opération Turn

   Cette opération étendue inverse les rôles du client et du serveur pour des échanges de protocole dans la session, ou pour permettre à chaque parties d'agir en tant que client et serveur.

Requête Turn

   L'opération Turn est définie par l'OID 1.3.6.1.1.19. La requête Turn est une ExtendedRequestrequestName contient 1.3.6.1.1.19 et requestValue est une valeur turnValue encodée BER:


turnValue ::= SEQUENCE {
    mutual BOOLEAN DEFAULT FALSE,
    identifier LDAPString
}

Réponse Turn

   La réponse est une ExtendedResponse où les champs responseName et responseValue sont absent. un resultCode à success indique qu'il est capable d'inverser la sessions.

Authentification

   Le modèle d'authentification de cette extension assume une authentification séparée des parties dans chacun de leur rôle. Un échange Bind est attendue entre les parties et leur nouveau rôle pour établir les identités dans ces rôles.

   Une fois le Turn complété, le partie répondant dans son nouveau rôle client a une association anonyme au partie initiant son nouveau rôle serveur. Si le turn est mutuel, l'association d'authentification du partie initiant est laissé intacte.

   Le partie répondant peut établir son identité dans son rôle client en demandant et complétant une opération Bind.

   La suite discute de divers scénarios d'authentification. A réfère au partie initiant (le client à l'origine) et B réfère au partie répondant ( le serveur à l'origine)

Utilisation avec TLS et une authentification simple


A-›B: StartTLS Request
B-›A: StartTLS(success) Response
A-›B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
A-›B: Bind(success) Response

   Dans ce scénario, TLS est initié et A établis son identité avec B avant de Turn en utilisant un mécanisme DN/password. après le Turn, B établis son identité avec A.

Utilisation avec TLS et SASL EXTERNAL


A-›B: StartTLS Request
B-›A: StartTLS(success) Response
A-›B: Bind(SASL(EXTERNAL)) Request
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(SASL(EXTERNAL)) Request
A-›B: Bind(success) Response

   Dans ce scénario, TLS est initié, et A établis son identité avec SASL avant de Turn. Après le Turn, B établis son identité avec A.

Utilisation de l'authentification mutuelle et SASL EXTERNAL


A-›B: Bind(SASL(GSSAPI)) Request
‹intermediate messages›
B-›A: Bind(success) Response
A-›B: Turn(TRUE,"XXYYZ") Request
B-›A: Turn(success) Response
B-›A: Bind(SASL(EXTERNAL)) Request
A-›B: Bind(success) Response

   Dans ce scénario, un échange d'authentification mutuel GSSAPI est complété entre A et B. après le Turn, B demande que A utilise une identité externe pour établir son identité d'authorisation LDAP.

Couches TLS et SASL

   La table suivante décris la relation entre la couche du message LDAP, SASL, TLS et la connection de transport dans une session LDAP.


- - - - - - -+- - - - - - - - - - - +
- - - - - - -| LDAP message layer _ |
- - - - - - -+- - - - - - - - - - - + › LDAP PDUs
- - - - - - -+- - - - - - - - - - - + ‹ data
- - - - - - -| ____ SASL layer ____ |
- - - - - - -+- - - - - - - - - - - + › SASL-protected data
- - - - - - -+- - - - - - - - - - - + ‹ data
- - - - - - -| _____ TLS layer ____ |
Application -+- - - - - - - - - - - + › TLS-protected data
- - - - - - -+- - - - - - - - - - - + ‹ data
- Transport -| transport connection |
- - - - - - -+- - - - - - - - - - - +

   Cette extension n'altère pas la relation, ni ne supprime les restriction générales des couches TLS et SASL multiples. StartTLS est utilisé pour initier la négociation TLS. si TLS est déjà établis, StartTLS peut échouer.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4370

rfc4370

Contrôle d'autorisation proxifié

   Permet à un client de demander qu'une opération soit traitée sous l'identité d'autorisation fournie au lieu de l'identité d'autorisation associée avec la connexion.

   Les serveurs supportant cette fonctionnalité devrait publier l'OID 2.16.840.1.113730.3.4.18 dans supportedControl.

   La criticité doit être présente et doit être à TRUE. Les serveurs rejètent toute requête non critique. controlValue devrait être présent et devrait soit contenir l'authzId représentant l'identité d'autorisation pour la requête ou être vide si une association anonyme doit être utilisée.

   Le mécanisme pour déterminer les droit d'accès est spécifique à la stratégie d'autorisation proxifiée du serveur.

   Si l'identité d'autorisation demandée est reconnue par le serveur, et que le client est autorisé à adopter l'autorisation demandée, la demande sera exécutée comme si elle était envoyée par l'identité d'autorisation proxy, sinon, le code de retour est 123.

Considération d'implémentation

   Durant l'évaluation d'une requête de recherche, un entrée qui aurait été retournée pour la recherche si elle avait été envoyée par l'identité d'autorisation proxy directement peut ne pas être retournée si le serveur trouve que le demandeur n'a pas les droit d'emprunter cette identité, même si l'entrée est dans le scope de recherche sous un DN qui implique de tels droits. Cela signifie que moins de résultat ou aucun résultat peut être retournée.
^
08 novembre 2013

htmlpdflatexmanmd




rfc4373

rfc4373

Bulk Update/Replication Protocol

   LBURP permet à un client LDAP d’effectuer des modifications/réplications auprès d’un serveur LDAP. LBURP définis un jeu opérations de modification dans une paire d’opérations étendue. Ces opérations contiennent chacune un numéro de séquence et une liste d’une ou plusieurs opérations de modification à effectuer.

Initialisation

   Le protocole est initié quand un fournisseur envoie StartLBURPRequest à un consommateur, qui notifie qu’un flux de LBURPUpdateRequests va suivre. Le fournisseur associe les sémantiques avec ce flux de requêtes en incluant l’OID du style de mise à jours/réplication dans le StartLBURPRequest. Le consommateur répond avec un message StartLBURPResponse

flux de mise à jours

   Après qu’un consommateur a répondu avec un StartLBURPResponse, le fournisseur envoie un flux de messages LBURPUpdateRequest au consommateur. Les messages dans ce flux peuvent être envoyés de manière asynchrone pour maximiser l’efficacité du transfert. Le consommateur répond à chaque LBURPUpdateRequest avec un message LBURPUpdateResponse.

LBURPUpdateRequest

   Chaque LBURPUpdateRequest contient un numéro de séquence identifiant sa position relative dans le flux. et un UpdateOperationList contenant la liste ordonnée des opérations à appliquer au DIT.

LBURPUpdateResponse

   Quand un consommateur a traité les opérations d’une UpdateOperationList, il envoie un LBURPUpdateResponse au fournisseur indiquant le succès ou l’échec des opérations.

Fin de mise à jours

   Une fois que le fournisseur a envoyé tous ses LBURPUpdateRequest, il envoie un message EndLBURPRequest au consommateur pour terminer le flux. Une fois reçu toutes les requêtes LBURPOperation et après avoir reçu le EndLBURPRequest, le consommateur répond avec un EndLBURPResponse.

Applicabilité du protocole

   LBURP est conçu pour faciliter les mise à jours en masse des serveurs LDAP. Il peut aussi être utilisé pour synchroniser les annuaires maître et esclave. Il n’est pas conçus dans l’optique de fournir des réplication multi-master.

Description du flux

F = Fournisseur
C = Consommateur
F -› C StartLBURPRequest. Contient l’OID pour le stype d’updte LBURP
C -› F StartLBURPResponse. Contient une instruction optionnelle maxOperations
F -› C Un flux de mises à jours consistant de 0 ou plusieurs LBURPUpdateRequest. Les requêtes peuvent être envoyés de manière asynchrone. Contient le numéro de séquence, et un updateOperationList d’opérations de mises à jours.
C -› F LBURPUpdateResponse. Envoyé quand le consommateur à finit le traitement d’une updateOperationList
F -› C EndLBURPRequest. Envoyé par le fournisseur quand il a envoyé tous ses LBURPUpdateRequest. Contient un numéro de séquence supérieur au dernier LBURPUpdateRequest envoyé.
C -› F EndLBURPResponse. Envoyé par le consommateur une fois toutes les LBURPOperation terminées et après avoir reçu EndLBURPRequest.

Elements du protocole

   LBURP utilise 2 messages LDAP extendedRequest: StartLBURPRequest et EndLBURPRequest pour initier et terminer le protocole. Un troisième extendedRequest, LBURPUpdateRequest est utilisé pour envoyer les opérations au consommateur.


ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
    requestName [0] LDAPOID,
    requestValue [1] OCTET STRING OPTIONAL
}
    
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}

StartLBURPRequest

requestName vaut 1.3.6.1.1.17.1 et requestValue contient la valeur suivante encodé BER:
StartLBURPRequestValue ::= SEQUENCE {
    updateStyleOID LDAPOID
}

updateStyleOID

   Identifie de manière unique le style de mise à jours à utiliser. LBUPR Incremental Update vaut 1.3.6.1.1.17.7

StartLBURPResponse

responseName vaut 1.3.6.1.1.17.2 et response contient la valeur suivante encodé BER:
StartLBURPResponseValue ::= maxOperations
maxOperations ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 — (2^^31 - 1) —

maxOperations

   Instruit le fournisseur de ne pas envoyer plus d’opération que cette valeur par updateOperationList. Si le consommateur n’envoie pas cette valeur, il doit être préparé à accèpter toutes les opérations fournies.

LBURPUpdateRequest

requestName vaut 1.3.6.1.1.17.5, et requestValue contient la valeur suivante encodé BER:
LBURPUpdateRequestValue ::= SEQUENCE {
    sequenceNumber INTEGER (1 .. maxInt),
    updateOperationList UpdateOperationList
}

sequenceNumber

   Permet au consommateur de traiter les requête LBURPOperation dans l’ordre spécifié par le fournisseur. La première valeur doit être 1 et incrémenté à chaque LBURPUpdateRequest.

UpdateOperationList

Liste d’une ou plusieurs requête de mise à jours LDAP:
UpdateOperationList ::= SEQUENCE OF SEQUENCE{
    updateOperation CHOICE {
    addRequest AddRequest,
    modifyRequest ModifyRequest,
    delRequest DelRequest,
    modDNRequest ModifyDNRequest
    },
    controls [0] Controls OPTIONAL
}

LBURPUpdateResponse

   Envoyé au fournisseur pour signaler que toutes les opérations d’un UpdateOperationList ont été complétés et pour donner le résultat des opérations. responseName contient 1.3.6.1.1.17.6

OperationResults

Quand un élément de réponse est inclus dans un message LBURPUpdateResponse, il contient la valeur suivante encodé BER:
OperationResults ::= SEQUENCE OF OperationResult
    
OperationResult ::= SEQUENCE {
operationNumber INTEGER,
ldapResult LDAPResult
}

operationNumber

   Identifie l’opération de mise à jours LDAP dans une UpdateOperationList d’un LBURPUpdateRequest qui a échoué. Les opérations sont numérotées en commençant à 1.

EndLBURPRequest

requestName vaut 1.3.6.1.1.17.3 et requestValue contient la valeur suivante encodé BER:
EndLBURPRequestValue ::= SEQUENCE {
    sequenceNumber INTEGER (1 .. maxInt)
}

EndLBURPRequest.sequenceNumber

   Est supérieur au dernier LBURPUpdateRequest.sequenceNumber reçu

EndLBURPResponse

   responseName vaut 1.3.6.1.1.17.4 et ne possède pas de réponse
^
08 novembre 2013

htmlpdflatexmanmd




rfc4403

rfc4403

Universal Description, Discovery, and Integration version 3

Représentation des structures de données UDDI

   Les informations qui créent un enregistrement dans un registre UDDI consiste de ces types de structure de données. Cette division par type d'information fournis des partitions simple pour assister dans la localisation et la compréhension rapide des différentes informations qui créent un enregistrement.

   Les données d'instance individuels gérés par un registre UDDI est sensible à la relation Parent/enfant trouvé dans le schéma. Un objet businessEntity contient un ou plusieurs objets unique businessService. Similairement, les objets businessService individuels, qui contiennent des informations qui incluent des pointers vers des instances d'objets tModel.

businessEntity

   Représente toute information connue sur un business ou une entité qui publie des information descriptives sur l'entité et les services qu'il offre.

businessService

   Les instance businessService représentent un service business logique. Chaque objet businessService est un enfant logique d'un objet businessEntity. Chaque élément businessService contient des informations descriptives en terme de business décrivant le type de service technique dans chaque instance businessService.

bindingTemplate

   Les descriptions techniques des services web sont accommodés via des instances individuelle d'objet bindingTemplate. Ces instance fournissent un support pour déterminer un point d'entrée technique ou un support optionnel de services hébergés à distance, aussi bien qu'un facilité pour décrire des caractéristiques techniques unique d'une implémentation donnée. Le support pour des paramètres et fichier de configuration particulier à des applications ou technologies sont également supportés.

  Chaque instance bindingTemplate a un seul parent businessService logique, qui en retour a un seul parent businessEntity logique.

tModel

   Cet objet prend la forme de métadonnées clé (data about data). Dans un sens général, le but d'un tModel dans le registre UDDI est de fournir un système de référence basé sur l'abstraction. Donc, le type de donnée qui tModel représente et nébuleux. un enregistrement tModel peut définir pleins de choses, mais dans la révision courante, 2 conventions ont été appliquées pour utiliser les tModels: comme source pour déterminer la compatibilité et comme références d'espace de nom clé. Les informations qui constituent un tModel sont assez simple. Il y'a une clé, un nom, une description optionnelle, et uneURL qui pointe quelquepart, potentiellement où un curieux peut trouver plus sur le concept représenté par la métadonnée dans le tModel.

publisherAssertion

   Beaucoup de business, tels que de grandes entreprises, ne sont pas représentées effectivement par un seul businessEntity, puisque leur description et découverte sont susceptible d'être divers. En concéquence, plusieurs cas de businessEntity peuvent être publiés, représentant diverses filiales. Néanmoins, ils représentent toujours une communauté plus ou moins couplé et souhaient certaines relations visible dans leurs enregistrements UDDI.

Information opérationnelle

   Avec UDDIv3, les informations opérationnelles associées avec le coeur des structures de données UDDI sont mainteni dans une structure OperationalInfo séparée, la signature numérique spécifiée par le publieur reste valide.

   La structure operationalInfo est utilisée pour transmettre les informations opérationnelles pour les structures de données du coeur UDDIv3, qui sont, les structures businessEntity, businessService, bindingTemplate et tModel. UDDIv3 OperationalInfo consiste de 5 éléments: created, Modified, modifiedIncludingChildren, nodeId, et authorizedName.

   En fonction de la strcture des données de UDDIv3 core, l'operationalInformation est représenté dansl'annuaire comme combinaison d'attributs opérationnels standard LDAP implicit: createTimestamp et modifyTimestamp, et les attributs explicites suivant: uddiAuthorizedName, uddiv3EntityCreationTime, uddiv3EntityModificationTime, et uddiv3NodeId.

Définition

uddiBusinessKey ID unique pour une instance donnée d'un uddiBusinessEntity.
uddiAuthorizedName Nom enregistré de l'individu qui a publié l'uddiBusinessEntity ou uddiTModel.
uddiOperator (obsolète par uddiv3NodeId) Nom certifié de l'opérateur de l'enregistrement UDDI qui gère la copie maître.
uddiName Noms 'human-readable' enregistrés pour le uddiBusinessEntity, uddiBusinessService, ou uddiTModel, orné d'une valeur xml:lang unique pour indiquer la langue dans laquelle ils sont exprimés.
uddiDescription Elément optionnel d'une ou plusieurs descriptions.
uddiDiscoveryURLs Liste d'URL qui pointent vers des mécanismes de découverte de services basés dur des fichiers additionnels
uddiUseType Décrit le type de contact ou adresse sous forme de texte libre. ex: "technical questions", "technical contact", "establish account", "sales contact", "headquarters", "sales office", "billing department", etc.
uddiPersonName Devrait lister lenom de la personne ou le nom d'un job disponible derrière le contact. 'ex: "administrator", "webmaster".
uddiPhone Numéro de téléphone pour le contact. Peut être orné avec un uddiUseType. ex: "Work Number#123 456-7890"
uddiEMail Utilisé pour maintenir les adresses email pour le contatc. Peut être orné avec un attribut uddiUseType. ex: "President of the United States #president@whitehouse.gov"
uddiSortCode (déprécié) Utiliser pour piloter le mode d'affichage externe des mécanisme qui trient les adresses. (ex: 1, 2, 3 ou a, b, c)
uddiTModelKey Id unique pour l'instance donnée d'un uddiTModel
uddiAddressLine Contient l'adresse actuelle sous forme de texte libre. Peut être orné avec 2 attributs descriptif, keyName et keyValue.(ex: "#"‹keyName›"#"‹keyValue›"#"‹addressData›)
uddiIdentifierBag Permet aux structures uddiBusinessEntity ou uddiTModel d'inclure des informations sur les formes communes d'identification tels que les nombres D-U-N-S, identifiant de taxe, etc. Peut être ornés avec un keyName et un keyValue. ex: ‹tModel›"#"‹keyName›"#"‹keyValue›
uddiCategoryBag Permet aux structures allows uddiBusinessEntity, uddiBusinessService, et uddiTModel d'être catégorisés en accord à une des nombreuses classification basé sur la taxonomie disponible, les Operator Sites fournissent un support de catégorie validée pour 3 taxonomies qui couvrent mers codes de l'industrie (via NAICS), classification de produits et services (via UNSPC), et géographie ( via ISO 3166 ). ex: ‹tModel›"#"‹keyName›"#"‹keyValue›
uddiKeyedReference Attribut généraliste pour une pair nom/valeur, avec référence à un tModel. ex: ‹tModel›"#"‹keyName›"#"‹keyValue›, tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
uddiServiceKey Clé unique pour un uddiBusinessService donné
uddiBindingKey Clé unique pour un uddiBindingTemplate donné
uddiAccessPoint Pointer vers un point d'entrée de service.
uddiHostingRedirector Utilisé pour désigner qu'une entrée uddiBindingTemplate est un pointeur vers une autre entrée uddiBindingTemplate.
uddiInstanceDescription Un ou plusieurs textes descriptifs qui désignent quel rôle une référence uddiTModel joue dans la description du service global. la valeur xml:lang précède le nom de la valeur avec le séparateur '#'
uddiInstanceParms Contient des paramètres requis pour l'utilisation d'une facette spécifique d'une description uddiBindingTemplate.
uddiOverviewDescription Courte description de lamnière dont un uddiTModel particulier doit être utilisé. la valeur xml:lang précède le nom de la valeur avec le séparateur '#'
uddiOverviewURL Maintient un URL vers une forme longue d'un document qui couvre la manière dont un uddiTModel particulier est utilisé comme composant d'une description de web service général. ex: Overview Description= "1#xml:lang#overviewDescription1", OverviewURL= "1#UseType#overviewURL"
uddiFromKey Clé unique qui référence le premier uddiBusinessEntity pour lequel l'assertion est faite.
uddiToKey Clé unique qui référence le second uddiBusinessEntity pour lequel l'assertion est faite
uddiUUID ID unique d'un objet uddiContact, uddiAddress, et uddiPublisherAssertion
uddiIsHidden Fournis un fonctionnalité pour l'opération delete_tModel.
uddiIsProjection Identifie un Business Service qui a un Service Projection
uddiLang modélise la structure sml:lang pour la strcucture Adderess dans UDDIv3.
uddiv3BusinessKey ID UDDIv3 unique pour une instance donnée de uddiBusinessEntity.
uddiv3ServiceKey ID UDDIv3 unique pour une instance donnée de uddiBusinessService.
uddiv3BindingKey ID UDDIv3 unique pour une instance donnée de uddiBindingTemplate.
uddiv3TModelKey ID UDDIv3 unique pour une instance donnée de uddiTModel.
uddiv3DigitalSignature Maintient la signature pour l'entité UDDI correspondante.
uddiv3NodeId Contient le Node Identity pour un noeud UDDIv3.
uddiv3EntityModificationTime Contient la date de dernière modification pour une entité UDDI
uddiv3SubscriptionKey ID UDDIv3 unique pour une instance donnée de uddiv3SubscriptionKey.
uddiv3SubscriptionFilter Filtre de souscription.
uddiv3NotificationInterval Chaîne d'interval de notification, de type xsd:duration et spécifie la fréquence de notification de changement asynchrone à fournir.
uddiv3MaxEntities Nombre maximum d'entité à retourner dans une notification de souscription.
uddiv3ExpiresAfter xsd:dateTime qui spécifie la date d'expiration associée avec une souscription
uddiv3BriefResponse Flag pour la réponse brève associée à une entité de souscription.
uddiv3EntityKey ID UDDIv3 unique pour une instance donnée d'une structure de données UDDI core.
uddiv3EntityCreationTime Permet de logger la date de création originale d'une entité UDDI
uddiv3EntityDeletionTime Permet de logger la date de suppression originale d'une entité UDDI

Schéma

Attributs
( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey' DESC 'businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName' DESC 'businessEntity publisher name' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
# ( 1.3.6.1.1.10.4.3 NAME 'uddiOperator' DESC 'registry site operator of businessEntitys master copy' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.4 NAME 'uddiName' DESC 'human readable name' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.5 NAME 'uddiDescription' DESC 'short description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.6 NAME 'uddiDiscoveryURLs' DESC 'URL to retrieve a businessEntity instance' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.7 NAME 'uddiUseType' DESC 'name of convention the referenced document follows' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName' DESC 'name of person or job role available for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.9 NAME 'uddiPhone' DESC 'telephone number for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.10 NAME 'uddiEMail' DESC 'e-mail address for contact' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# ( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode' DESC 'specifies an external display mechanism' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey' DESC 'tModel unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.13 NAME 'uddiAddressLine' DESC 'address' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.14 NAME 'uddiIdentifierBag' DESC 'identification information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey' DESC 'businessService unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey' DESC 'bindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint' DESC 'entry point address to call a web service' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector' DESC 'designates a pointer to another bindingTemplate' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription' DESC 'instance details description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms' DESC 'URL reference to required settings' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription' DESC 'outlines tModel usage' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL' DESC 'URL reference to overview document' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.26 NAME 'uddiToKey' DESC 'unique businessEntity key reference' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.27 NAME 'uddiUUID' DESC 'unique attribute' EQUALITY caseIgnoreMatchc SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden' DESC 'isHidden attribute' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection' DESC 'isServiceProjection attribute' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.30 NAME 'uddiLang' DESC 'xml:lang value in v3 Address structure' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey' DESC 'UDDIv3 businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey' DESC 'UDDIv3 businessService unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey' DESC 'UDDIv3 BindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey' DESC 'UDDIv3 TModel unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature' DESC 'UDDIv3 entity digital signature' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId' DESC 'UDDIv3 Node Identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime' DESC 'UDDIv3 Last Modified Time for Entity' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey' DESC 'UDDIv3 Subscription unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter' DESC 'UDDIv3 Subscription Filter' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval' DESC 'UDDIv3 Notification Interval' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities' DESC 'UDDIv3 Subscription maxEntities field' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter' DESC 'UDDIv3 Subscription ExpiresAfter field' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse' DESC 'UDDIv3 Subscription ExpiresAfter field' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey' DESC 'UDDIv3 Entity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime' DESC 'UDDIv3 Entity Creation Time' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime' DESC 'UDDIv3 Entity Deletion Time' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )

Classes d'objet
uddiBusinessEntity
( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity' SUP top STRUCTURAL MUST ( uddiBusinessKey $ uddiName) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDiscoveryURLs $ uddiDescription $ uddiIdentifierBag $ uddiCategoryBag $ uddiv3BusinessKey $ uddiv3DigitalSignature $ uddiv3EntityModificationTime $ uddiv3NodeId) )
uddiContact
( 1.3.6.1.1.10.6.2 NAME 'uddiContact' SUP top STRUCTURAL MUST ( uddiPersonName $ uddiUUID ) MAY ( uddiUseType $ uddiDescription $ uddiPhone $ uddiEMail ) )
uddiAddress
( 1.3.6.1.1.10.6.3 NAME 'uddiAddress' SUP top STRUCTURAL MUST ( uddiUUID ) MAY ( uddiUseType $ uddiSortCode $ uddiTModelKey $ uddiv3TmodelKey $ uddiAddressLine $ uddiLang) )
uddiBusinessService
( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService' SUP top STRUCTURAL MUST ( uddiServiceKey ) MAY ( uddiName $ uddiBusinessKey $ uddiDescription $ uddiCategoryBag $ uddiIsProjection $ uddiv3ServiceKey $ uddiv3BusinessKey $ uddiv3DigitalSignature $ uddiv3EntityCreationTime $ uddiv3EntityModificationTime $ uddiv3NodeId) )
uddiBindingTemplate
( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate' SUP top STRUCTURAL MUST ( uddiBindingKey ) MAY ( uddiServiceKey $ uddiDescription $ uddiAccessPoint $ uddiHostingRedirector $ uddiCategoryBag $ uddiv3BindingKey $ uddiv3ServiceKey $ uddiv3DigitalSignature $ uddiv3EntityCreationTime $ uddiv3NodeId) )
uddiTModelInstanceInfo
( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo' SUP top STRUCTURAL MUST ( uddiTModelKey ) MAY ( uddiDescription $ uddiInstanceDescription $ uddiInstanceParms $ uddiOverviewDescription $ uddiOverviewURL $ uddiv3TmodelKey) )
uddiTModel
( 1.3.6.1.1.10.6.7 NAME 'uddiTModel' SUP top STRUCTURAL MUST ( uddiTModelKey $ uddiName ) MAY ( uddiAuthorizedName $ uddiOperator $ uddiDescription $ uddiOverviewDescription $ uddiOverviewURL $ uddiIdentifierBag $ uddiCategoryBag $ uddiIsHidden uddiv3TModelKey $ uddiv3DigitalSignature $ uddiv3NodeId) )
uddiPublisherAssertion
( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion' SUP top STRUCTURAL MUST ( uddiFromKey $ uddiToKey $ uddiKeyedReference $ uddiUUID ) MAY ( uddiv3DigitalSignature $ uddiv3NodeId) )
uddiv3Subscription
( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription' SUP top STRUCTURAL MUST ( uddiv3SubscriptionFilter $ uddiUUID) MAY ( uddiAuthorizedName $ uddiv3SubscriptionKey $ uddiv3BindingKey $ uddiv3NotificationInterval $ uddiv3MaxEntities $ uddiv3ExpiresAfter $ uddiv3BriefResponse $ uddiv3NodeId) )
uddiv3EntityObituary
( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary' SUP top STRUCTURAL MUST ( uddiv3EntityKey $ uddiUUID) MAY ( uddiAuthorizedName $ uddiv3EntityCreationTime $ uddiv3EntityDeletionTime $ uddiv3NodeId) )

Name Forms
uddiBusinessEntityNameForm
( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm' OC uddiBusinessEntity MUST ( uddiBusinessKey ) )
uddiContactNameForm
( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm' OC uddiContact MUST ( uddiUUID ) )
uddiAddressNameForm
( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm' OC uddiAddress MUST ( uddiUUID ) )
uddiBusinessServiceNameForm
( 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm' OC uddiBusinessService MUST ( uddiServiceKey ) )
uddiBindingTemplateNameForm
( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm' OC uddiBindingTemplate MUST ( uddiBindingKey ) )
uddiTModelInstanceInfoNameForm
( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm' OC uddiTModelInstanceInfo MUST ( uddiTModelKey ) )
uddiTModelNameForm
( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm' OC uddiTModel MUST ( uddiTModelKey ) )
uddiPublisherAssertionNameForm
( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm' OC uddiPublisherAssertion MUST ( uddiUUID ) )
uddiv3SubscriptionNameForm
( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm' OC uddiv3Subscription MUST ( uddiUUID ) )
uddiv3EntityObituaryNameForm
( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm' OC uddiv3EntityObituary MUST ( uddiUUID ) )

DIT Structure Rules
uddiBusinessEntityStructureRule
( 1 NAME 'uddiBusinessEntityStructureRule' FORM uddiBusinessEntityNameForm )
uddiContactStructureRule
( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 ) )
uddiAddressStructureRule
( 3 NAME 'uddiAddressStructureRule' FORM uddiAddressNameForm SUP ( 2 ) )
uddiBusinessServiceStructureRule
( 4 NAME 'uddiBusinessServiceStructureRule' FORM uddiBusinessServiceNameForm SUP ( 1 ) )
uddiBindingTemplateStructureRule
( 5 NAME 'uddiBindingTemplateStructureRule' FORM uddiBindingTemplateNameForm SUP ( 4 ) )
uddiTModelInstanceInfoStructureRule
( 6 NAME 'uddiTModelInstanceInfoStructureRule' FORM uddiTModelInstanceInfoNameForm SUP ( 5 ) )
uddiTModelStructureRule
( 7 NAME 'uddiTModelStructureRule' FORM uddiTModelNameForm )
uddiPublisherAssertion
( 8 NAME 'uddiPublisherAssertionStructureRule' FORM uddiPublisherAssertionNameForm )
uddiv3SubscriptionStructureRule
( 9 NAME 'uddiv3SubscriptionStructureRule' FORM uddiv3SubscriptionNameForm )
uddiv3EntityObituaryStructureRule
( 10 NAME 'uddiv3EntityObituaryStructureRule' FORM uddiv3EntityObituaryNameForm )

^
01 septembre 2013

htmlpdflatexmanmd




rfc4422

rfc4422

Simple Authentication and Security Layer (SASL)

   SASL est un framework fournissant des services d'authentification et de sécurité de données dans des protocoles orienté connexion utilisant des mécanismes remplaçable. SASL fournis une interface structurée entre les protocoles et les mécanismes. SASL fournis également un protocole pour sécuriser les échanges. SASL est conçu pour permettre à de nouveaux protocoles de réutiliser les mécanismes existants.

   SASL fournis une couche d'abstraction entre les protocoles et les mécanismes. Pour utiliser SASL, chaque protocole fournis une méthode pour identifier le mécanisme à utiliser, une méthode pour échanger les challenges et une méthode pour la communication. Chaque mécanisme SASL définis une série de server-challenge et client-response qui fournissent les services d'authentification et de négociation de sécurisation des données.

Concept d'identité

   SASL nécessite 2 identités:

1) L'identité associé avec les accréditifs ( authentication identity )
2) L'identité qui agis en tant que ( authorization identity )

   Le client fournis ses accréditifs ( qui inclus ou implique un authentication identity) et optionnellement, une chaîne de caractère représentant l'authorization identity. Quand cette chaîne est omis ou vide, le client agis comme identité associé avec les accréditifs.

   Le serveur vérifie les accréditifs du clients et vérifie que l'identité qu'il associe avec les accréditifs du client (authorization idenity) a le droit d'agir comme authorization identity. Si une des vérifications échoue, l'échange SASL échoue.

Échange d'authentification

   Chaque échange d'authentification consiste d'un message du client vers le serveur demandant une authentification via un mécanisme particulier, suivi par une ou plusieurs paires de challenges du serveur et de réponse du client, suivis par un message du serveur indiquant la sortie de l'échange d'authentification.

Exemple d'échange

C: Request authentication exchange
S: Initial challenge
C: Initial response
‹additional challenge/response messages›
S: Outcome of authentication exchange

   Certains mécanismes spécifient que le client envoie une réponse initiale dans la requête. Plusieurs variantes sont possible.

Nommage des mécanismes

les mécanismes SASL sont nommés par des chaînes de caractère, de 1 à 20 caractère de long, en ASCII noté (ABNF) :
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
    
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)

Négociation de mécanisme

   La négociation des mécanismes est spécifique au protocole. Généralement, un protocole spécifie que le serveur avertis le client des mécanismes disponibles et supportés. Le client choisira le meilleur protocole de cette liste qu'il supporte.

Demande d'échange d'authentification

   L'échange d'authentification est initié par le client en demandant une authentification via le mécanisme qu'il spécifie. Le client envoie une message contenant le nom du mécanisme au serveur. Les particularité du message sont spécifiques au protocole. Noter que le nom du mécanisme n'est pas protégé par le mécanisme.

Challenges and Responses

   Les challenges et réponse sont imbriqués dans des messages de protocole. Le mécanisme peut être:

- Authentifier le client auprès du serveur
- authentifier le serveur auprès du client
- Transférer une chaîne authorization identity
- Négocier une couche de sécurité
- Fournir d'autres services.

   La négociation de couche de sécurité implique la négociation de services de sécurité à fournir dans la couche et comment ces services sont fournis. Après avoir reçu une requête d'authentification ou une réponse d'un client, le serveur peut fournir un challenge, annuler l'échange, ou indiquer la sortie de l'échange. Après avoir reçu un challenge, un mécanisme client peut fournir une réponse ou annuler l'échange.

Chaîne d'identité d'authorisation

   Cette chaîne est une séquence de caractères unicode représentant l'identité qui qui agis en tant que. Si cette chaîne est absente, le demandeur agis en tant qu'identité que le serveur associe avec les accréditifs du client. Une chaîne non vide indique que le client souhaite agir en tant qu'identité représentée par la chaîne.

Annuler l'échange

   Un client ou un serveur peut annuler l'échange.

Fin de l'authentification

   La conclusion de l'échange, le serveur envoie un message spécifique au protocole, au client indiquant la sortie de l'échange. La sortie est un échec si:

- L'échange d'authentification a échoué pour une quelconque raison
- Les accréditifs du client n'ont pu être vérifiés
- Le serveur ne peut associer une identité avec les accréditifs du client
- L'authorization Identity fournie est mal formaté
- L'identité associé avec les accréditifs du client n'est pas autorisé à agir en tant qu'authorization identity
- La couche sécurité demandée (ou son absence) n'est pas disponible et n'est pas utilisable par le client et/ou le serveur

   Le protocole peut inclure des données additionnelles dans le message.

Couches de sécurité

   Les mécanismes SASL peuvent offrir une grande variété de services dans les couches de sécurité, incluant l'intégrité des données et la confidentialité des données. Si la couche de sécurité est négociée dans l'échange, la couche n'est installée par le serveur qu'après le message de sortie d'échange.

Authentification multiple

   Sans être explicitement permis dans le protocole, seul un échange d'authentification réussis peut se produire dan une sessions. Quand plusieurs authentifications sont permis, en aucun cas il ne peut y avoir plusieurs couche de sécurité simultanés. Si une couche de sécurité est effective, et qu'une seconde négociation sélectionne une autre couche de sécurité, la seconde couche remplace la première.

Protocol requirements

   Pour qu'un protocole offre des services SASL, ses spécifications doivent fournir les informations suivantes:

1) un nom de service, à sélectionner du registre de services pour la forme de nom de service basé sur l'hôte GSSAPI.
2) Détail des négociations de mécanisme que le protocole fournis.
3) Définition des messages nécessaires pour l'échange d'authentification
4) Décrire la syntaxe de chaîne d'authorization identity non-vide
5) Détailler les facilité que le protocole fournis qui permettent au client/serveur d'annuler un échange
6) Identifier précisément où les couches de sécurité nouvellement négociée prenent effet.
7) Si le protocole supporte d'autres couche de sécurité tel que TLS, la spécification doit décrire l'ordre dans lequel les couches de sécurité sont appliquées dans les données du protocole
8) indiquer si le protocole supporte l'authentification multiple

Mechanism requirement

   Les spécification des mécanisme doivent fournir les informations suivantes:

1) le nom du mécanisme
2) Si le mécanisme est client-first ou server-first.
3) si le serveur doit fournir des données additionnelles en indiquant une sortie réussie
4) Si le mécanisme est capable de transférer l'authorization identity
5) Si le mécanisme offre une couche de sécurité
6) si la technologie cryptographique utilisée supporte l'intégrité des données
^
15 juillet 2013

htmlpdflatexmanmd




rfc4512

rfc4512

Directory Information Models

DIB Directory Information Base
DUA Directory User Agent
DSA Directory System Agent
DSE DSA-Specific Entry
DIT Directory Information Tree
RDN Relative Distinguished Name
AVA Attribute Value Assertions

   Le but d’un annuaire est de maintenir, et de fournir l’accès à des informations sur des objets d’interet. Un objet peut être tout ce qui peut être identifiable (peut être nommé). Certains attributs maintiennent des informations sur l’objet qu’ils représentent et sont appelés des attributs utilisateurs. D’autres attributs représentent des informations administratifs et/ou opérationnels et sont appelés des attributs opérationnels.

Classes d'objet abstraites

   Fournis une base de caractéristiques depuis lequel d’autres classes d’objet peuvent hériter. Une entrée ne peut pas appartenir à une classe abstraite à moins qu’elle appartiennent à une classe auxiliaire ou structurelle qui hérite de cette classe abstraite.

  Une classe abstraite ne peut pas dériver d’une classe auxiliaire ou structurelle. Toutes les classes d’objet structurelles dérivent directement ou indirectement de la classe objet 'top'. Une classe auxiliaire ne dérive pas nécessairement de top.

Classes d'objet structurelles

   Elles sont utilisées dans la définition de la structure des noms d’objets. Un objet ou alias est caractérisé par précisément une chaîne super-classe d’objet structurelle qui a une simple classe structurelle comme classe objet la plus subordonnée. Elle est appelée la classe objet structurelle de l’objet

Classes d'objet auxiliaires

   Elle sont utilisées pour augmenter les caractéristiques des entrées. Elle sont communément utilisées pour augmenter le jeu d’attributs requis et permit dans une entrée. Les classes auxiliaires ne peuvent pas être des sous-classes de classes structurelles

Types d'attributs

   Le type d’un attribut définis si il est multi-valué, la syntaxe et les règles de correspondance utilisées pour construire et comparer les valeurs de cet attribut, et d’autres fonctions. Si aucune correspondance d'égalité n'est spécifiée pour ce type d'attribut:

        - l’attribut ne peut pas être utilisé pour le nommage
        - 2 valeurs ne peuvent pas être équivalentes
        - les valeurs individuelles d’un attribut multi-valué ne peuvent pas être ajoutée/enlevées indépendamment
        - AVA (tels que la correspondance dans les filtres de recherche et de comparaisons) en utilisant les valeurs de cet attribut ne peuvent pas être effectuées

   Sinon, la règle de correspondance d’égalité spécifiée est utilisée pour évaluer l’AVA concernant le type d’attribut La règle d’égalité spécifiée doit être transitive et commutative.

  Le type d’attribut indique si l’attribut est un attribut utilisateur ou un attribut opérationnel. S’il est opérationnel, l’attribut indique l’usage opérationnel et si l’attribut est modifiable ou non par les utilisateurs.

  Un type d’attribut (un sous-type) peut dériver d’autres type d’attributs (un super-type). Les restrictions suivantes s’appliquent au sous-typage:

        - un sous-type doit avoir le même usage que son super-type direct la syntaxe du sous-type doit être la même, ou une re-définition de la syntaxe du super-type
        - un sous-type doit être collectif si son super-type est collectif.

   Chaque type d’attribut est identifié par un Object IDentifier (OID) et optionnellement d’un ou plusieurs noms cours (descripteurs)

Options d'attributs

   Toutes les options ne peuvent pas être associées avec des attributs maintenu dans l"annuaire. le tagging options le permet.

  Une description d’attribut peut être le sous-type direct de 0 ou plusieurs autres descriptions d’attributs. ces relations de sous-typage sont utilisées pour former une hiérarchie de description d’attributs et d’attributs.

  Les hiérarchies d’attribut permettent un accès à la DIB avec différents degré de granularité, grâce à la valeur des attributs qui sont accédés soit en utilisant leur description d’attribut direct ou une description d’attribut plus générique.

Alias

   Un alias, ou un nom alias, pour un objet est un nom alternatif qui est fournis par l’utilisation d’entrées alias. Chaque entrée alias contient dans l’attribut aliasedObjectName, le nom d’un objet.

Attributs opérationnels

   Il en existe 3 sortes:

        Directory operational attributes Est utilisé pour représenter une information opérationnelle et/ou administrative dans le Directory Information Model. Cela inclus les attributs opérationnels maintenus par le serveur (ex : createTimestamp), et les attributs opérationnels qui maintiennent des valeurs administrées par l’utilisateur (ex: ditContentRules)
        DSA-shared operational attributes Est utilisé pour représenter des information du DSA Information Model qui est partagé entre les DSA.
        DSA-specific operational attributes Est utilisé pour représenter des information sur le DSA Information Model qui est spécifique au DSA. ( bien que parfois peut être dérivé des informations partagées entres les DSA)

   Les attributs opérationnel ne sont normalement pas visible. Ils ne sont pas retournés dans les résultats de recherche à moins qu’ils aient été explicitement demandés Tous les attributs opérationnels ne sont pas modifiables.

Schéma

   Le schéma de l’annuaire est un jeu de définitions et de contraintes concernant la structure du DIT, les entrées possibles, etc.

Définition de schéma (ABNF)
oidlen = numericoid [ LCURLY len RCURLY ]
len = number
    
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
    
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
    
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
    
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
    
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
    
; Any UTF-8 encoded Unicode character
; except %x27 ("\’") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
    
; Any ASCII character except %x27 ("\’") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F

Le champ NAME fournis un jeu de noms court qui sont utilisés comme alias pour l’OID
Le champs DESC est optionnel et apporte un description
Le champ OBSOLETE, si présent, indique que l’élément n’est pas actif

Définition de classe d'objet


ObjectClassDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "SUP" SP oids ] ; superior object classes
    [ SP kind ] ; kind of class
    [ SP "MUST" SP oids ] ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    extensions WSP RPAREN
    
    kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

‹numericoid› est l’OID assigné à cette classe d’objet
NAME ‹qdescrs› Sont des noms courts identifiant cette classe d’objet
DESC ‹qdstring› est une courte description
OBSOLETE indique que cette classe d’objet n’est pas active
SUP ‹oids› spécifie les super-classes directe de cette classe d’objet.
kind Spécifie le type de classe (ABSTRACT, STRUCTURAL ou AUXILIARY)
MUST et MAY spécifient les jeux d’attributs requis et permis
‹extensions› décrit les extensions

Définition des attributs


AttributeTypeDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "SUP" SP oid ] ; supertype
    [ SP "EQUALITY" SP oid ] ; equality matching rule
    [ SP "ORDERING" SP oid ] ; ordering matching rule
    [ SP "SUBSTR" SP oid ] ; substrings matching rule
    [ SP "SYNTAX" SP noidlen ] ; value syntax
    [ SP "SINGLE-VALUE" ] ; single-value
    [ SP "COLLECTIVE" ] ; collective
    [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
    [ SP "USAGE" SP usage ] ; usage
    extensions WSP RPAREN ; extensions
    
    usage = "userApplications" / ; user
    "directoryOperation" / ; directory operational
    "distributedOperation" / ; DSA-shared operational
    "dSAOperation" ; DSA-specific operational

‹numericoid› est l’OID assigné à ce type d’attribut
NAME ‹qdescrs› sont des noms courts identifiant ce type d’attribut
DESC ‹qdstring› est une courte description
OBSOLETE Indique que cet attribut n’est pas actif
SUP oid Spécifie le supertype direct de ce type
EQUALITY, ORDERING, et SUBSTR Fournissent l’OID de l’égalité, l’ordonnancement et les règle de correspondance de chaîne, respectivement.
SYNTAX Identifie La syntaxe de la valeur par OID et peut suggérer une limite minimum
SINGLE-VALUE Indique que les attributs de ce type sont restreint à une seule valeur
COLLECTIVE Indique que cet attribut est collectif
NO-USER-MODIFICATION Indique que ce type d’attribut n’est pas modifiable par l’utilisateur
USAGE Indique l’application de ce type d’attribut
‹extensions› décrit les extensions

Chaque description de type d’attribut doit avoir au moins SUP ou SYNTAX.
Si SUP est fournis, SYNTAX, EQUALITY, ORDERING et SUBSTRING sont pris du super-type s’ils ne sont pas spécifié
COLLECTIVE nécessite un usage userApplications
NO-USER-MODIFICATION nécessite un usage opérationnel
AttributeTypeDescription ne liste pas les règles de correspondance utilisées avec ce type d’attribut dans un filtre de recherche extensibleMatch. C’est fait avec l’attribut matchingRuleUse.

Règles de correspondance

   Elles sont utilisée pour les opérations AVA tels que les opérations de comparaison ou les filtres de recherche, déterminant quelles valeurs individuelles sont ajoutée ou supprimée durant les opération de modification, et en comparant des DN.


MatchingRuleDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "SYNTAX" SP numericoid ; assertion syntax
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la règle de correspondance
NAME ‹qdescrs› sont des noms cours décrivant la règle
DESC ‹qdstring› est une courte description
OBSOLETE Indique que cette règle n’est pas active
SYNTAX Identifie la syntaxe d’assertion par OID
‹extensions› Décris les extensions

Utilisation des règles de correspondance

   Une règle de correspondance liste les types d’attributs qui sont utilisables avec un filtre de recherche extensibleMatch


MatchingRuleUseDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "APPLIES" SP oids ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la règle associée avec cette utilisation de règle
NAME ‹qdescrs› Sont des noms cours identifiant l’utilisation de règle
DESC ‹qdstring› est une courte description
OBSOLETE indique que cette utilisation de règle de correspondance est désactivée
APPLIES Fournis une liste de type d’attributs auxquel la règle s’applique
‹extensions› décrit les extensions

Syntaxes LDAP

   Les syntaxes LDAP de valeurs d’attribut et d’assertion sont décrites en ASN.1 et optionnellement, ont un encodage de chaîne (LDAP-specific encoding), généralement en UTF-8.


SyntaxDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "DESC" SP qdstring ] ; description
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID assignée à cette syntaxe LDAP
DESC ‹qdstring› est une courte description
‹extensions› Décris les extensions

Règles de contenu DIT

   Une DIT content rule est une règle régissant le contenu des entrées d’une classe d’objet structurelle particulière. Elle définissent quelles classes d’objets auxiliaires sont requis, permis on non permises dans l’entrée.


DITContentRuleDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    [ SP "AUX" SP oids ] ; auxiliary object classes
    [ SP "MUST" SP oids ] ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    [ SP "NOT" SP oids ] ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID de la classe structurelle associée avec ces DIT content rule
NAME ‹qdescrs› Sont des noms cours identifiant ce DIT content rule
DESC ‹qdstring› est une courte description
OBSOLETE Indique que ce DIT content rule est inactif
AUX Spécifie une liste de classes auxiliaires que les entrée sujettes à ce DIT content rules peuvent appartenir.
MUST, MAY, et NOT Spécifient les listes de type d’attributs qui sont requis, permis ou non-permis
‹extensions› décrit les extensions

Règles de structure DIT

   Une règle de structure DIT est une règle régissant la structure du DIT en spécifiant un supérieur autorisé à subordonner la relation d’entrée. une règle de structure concerne une forme de nom, et donc une classe structurelle, de structurer les règles supérieurs. Celà permet au entrées de la classe structurelle identifiées par la forme de nom d’exister dans le DIT comme subordonnée aux entrée régies par la règle structurelle supérieur.


DITStructureRuleDescription = LPAREN WSP
    ruleid ; rule identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "FORM" SP oid ; NameForm
    [ SP "SUP" ruleids ] ; superior rules
    extensions WSP RPAREN ; extensions
    
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number

‹ruleid› est identifiant de règle de ce DIT structure rule
NAME ‹qdescrs› sont des noms identifiant ce DIT structure rule
DESC ‹qdstring› est une courte description
OBSOLETE indique que ce DIT structure rule use n’est pas actif
FORM spécifie le name form associé à ce DIT structure rule
SUP identifie les règles supérieurs (par rule id)
‹extensions› Décris les extensions

Formes de nom

   un name form spécifie un RDN permis pour les entrées d’une classe d’objet structurelle particulière. il identifie une classe nommée et un ou plusieurs types d’attributs pour le nommage (ex: le RDN). ce sont des pièces primitives de spécification utilisées dans la définition de règles de structures de DIT. Chaque name form indique la classe structurelle à nommer, un jeu de types d’attributs requis, et un autre pour les types permis.


NameFormDescription = LPAREN WSP
    numericoid ; object identifier
    [ SP "NAME" SP qdescrs ] ; short names (descriptors)
    [ SP "DESC" SP qdstring ] ; description
    [ SP "OBSOLETE" ] ; not active
    SP "OC" SP oid ; structural object class
    SP "MUST" SP oids ; attribute types
    [ SP "MAY" SP oids ] ; attribute types
    extensions WSP RPAREN ; extensions

‹numericoid› est l’OID du name form
NAME ‹qdescrs› sont des noms identifiant ce name form
DESC ‹qdstring› est une courte description
OBSOLETE indique que ce name form est inactif
OC identifie la classe structurelle à laquelle cette règle s’applique
MUST et MAY Spécifient les jeux d’attributs nommés requis et permis pour ce name form
‹extensions› Décris les extensions

Sous-entrées de sous-schéma

   Elles sont utilisée pour administrer les informations sur le schéma de l’annuaire. Une sous-entrée de sous-schéma contient toutes les définitions de schéma utilisées par les entrées dans une partie de l’arborescence. Les serveurs peuvent autoriser la modification du sous-schéma.

Découverte du sous-schéma

   Pour découvrir le DN du sous-schéma qui maintient le sous-schéma contrôlant une entrée particulière, un client lit l’attribut opérationnel subschemaSubentry de cet entrée. Pour lire cet attribut, le client doit fournir une opération de recherche où le baseObject est le DN de l’entrée de sous-schéma. Le scope est baseObject, le filtre est "(objectClass=subschema)" et le champs attributs liste les attributs désirés.

DSA Information Model

   Le protocole LDAP assume qu’il y’a un ou plusieurs serveurs qui fournissent conjointement accès au DIT. Le serveur maintenant l’information originale est appelée le master, ceux qui maintiennent une copie, des serveurs shadowing ou caching.

context prefix La séquence de RDN partant de la racine du DIT jusqu’au vertex initial d’un contexte de nommage, correspondant au DN de ce vertex
naming context Une sous-arborescence d’entrées maintenus dans un DSA master

   Un contexte de nommages est la plus grande collection d’entrées, commençant à une entrée master, et incluant tous ses subordonnés et leur subordonnés, jusqu’aux entrées qui sont master sur d’autres serveurs. Le Root d’un DIT est un DSE et ne fait pas partit d’un contexte de nommage (ou d’une sous-arborescence). Chaque serveur a des valeurs d’attribut différents dans le root DSE.

Server-Specific Data Requirements

   Un serveur LDAP devrait fournir des informations sur lui-même et d’autres informations qui sont spécifiques à d’autres serveurs. C’est représenté sous la forme d’un groupe d’attributs dans le root DSE, qui sont nommé avec un DN sans RDN.

Cache et Shadowing

   Certains serveurs maintiennent des copies des entrées, qui peuvent être utilisée pour répondre à des requêtes ou des comparaisons, mais vont retourner des referrals ou contacter d’autres serveur si des opérations de modification sont demandées. Ces serveurs doivent s’assurer qu’ils ne violent pas de contrôle d’accès.

Conduite des serveurs

- Les serveurs doivent reconnaître tous les noms des attributs et classes définis dans ce document, mais n’ont pas besoin de supporter les fonctionnalité associés (sauf mentionné).
- Les serveurs doivent s’assurer que les entrées sont conformes au règles de schéma et autres contraintes
- Les serveurs peuvent supporter: DIT Content Rules, DIT Structure Rules, Name Forms, alias, la classe object extensibleObject, les sous-entrées.
- Les serveurs peuvent implémenter des éléments de schéma additionnel.

Considération IANA

Les descripteurs suivant réfèrent à cette RFC :
NAME    Type    OID
    
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0

Description des attributs

aliasedObjectName Le DN de l’objet pointé
objectClass Chaque entrée dans le DIT a un attribut objectClass
creatorsName Créateur de l’entrée dans le DIT
createTimestamp Date et heure de la création de l’entrée
modifiersName Spécifie le DN du dernier modificateur de l’objet
modifyTimestamp Date et heure de la dernière modification de l’objet
structuralObjectClass Indique la classe objet structurelle de l’entrée
governingStructureRule Indique la règle gouvernante de l’entrée
subschemaSubentry Permet aux clients de découvrir les attributs et classes d’objet permis et présents dans l’arborescence
objectClasses Maintient les définitions des classes d’objet
attributeTypes Maintient les définitions des types d’attributs
matchingRules Maintient les définitions des règles de correspondance
matchingRuleUse Maintient les définitions des utilisations de règle de correspondance
ldapSyntaxes Maintient les définitions des syntaxes LDAP
dITContentRules Maintient les définitions des règles de contenu de DIT
dITStructureRules Maintient les définitions des règles de structure de DIT
nameForms Liste les Names Form qui sont forcés
altServer (Root DSE) Serveurs alternatifs
namingContexts (Root DSE) Contexte de nommage
supportedControl (Root DSE) Contrôles LDAP reconnus
supportedExtension (Root DSE) Opération étendues reconnus
supportedFeatures (Root DSE) fonctionnalités LDAP reconnus
supportedLDAPVersion (Root DSE) Versions LDAP supportées
supportedSASLMechanisms (Root DSE) Mécanismes SASL reconnus

Description des classes d'objet

alias Un objet alias
subschema Le sous-schéma est maintenu en sous-entrées appartenant à cette classe
extensibleObject Permet à des objets de maintenir des attributs utilisateur

Définition des attributs


attributeType ( 2.5.4.1 NAME ’aliasedObjectName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE )
    
attributeType ( 2.5.21.5 NAME ’attributeTypes’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
    USAGE directoryOperation )
    
attributeType ( 2.5.21.4 NAME ’matchingRules’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
    USAGE directoryOperation )
    
attributeType ( 2.5.21.8 NAME ’matchingRuleUse’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
    USAGE directoryOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.16 NAME ’ldapSyntaxes’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
    USAGE directoryOperation )
    
attributeType ( 2.5.4.0 NAME ’objectClass’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
attributeType ( 2.5.21.6 NAME ’objectClasses’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
    USAGE directoryOperation )
    
attributeType ( 2.5.18.3 NAME ’creatorsName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.1 NAME ’createTimestamp’
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.4 NAME ’modifiersName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.2 NAME ’modifyTimestamp’
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.9 NAME ’structuralObjectClass’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.10 NAME ’governingStructureRule’
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.18.10 NAME ’subschemaSubentry’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE NO-USER-MODIFICATION
    USAGE directoryOperation )
    
attributeType ( 2.5.21.2 NAME ’dITContentRules’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
    USAGE directoryOperation )
    
attributeType ( 2.5.21.1 NAME ’dITStructureRules’
    EQUALITY integerFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
    USAGE directoryOperation )
    
attributeType ( 2.5.21.7 NAME ’nameForms’
    EQUALITY objectIdentifierFirstComponentMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
    USAGE directoryOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.6 NAME ’altServer’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.5 NAME ’namingContexts’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.13 NAME ’supportedControl’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.7 NAME ’supportedExtension’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.4203.1.3.5 NAME ’supportedFeatures’
    EQUALITY objectIdentifierMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.15 NAME ’supportedLDAPVersion’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    USAGE dSAOperation )
    
attributeType ( 1.3.6.1.4.1.1466.101.120.14 NAME ’supportedSASLMechanisms’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    USAGE dSAOperation )

Définition des classes d'objet


objectClass ( 2.5.6.1 NAME ’alias’
    SUP top STRUCTURAL
    MUST aliasedObjectName )
    
objectClass ( 2.5.20.1 NAME ’subschema’ AUXILIARY
    MAY ( dITStructureRules $ nameForms $ ditContentRules $
    objectClasses $ attributeTypes $ matchingRules $
    matchingRuleUse ) )
    
objectClass ( 1.3.6.1.4.1.1466.101.120.111 NAME ’extensibleObject’
    SUP top AUXILIARY )

^
23 août 2013

htmlpdflatexmanmd




rfc4513

rfc4513

Mécanismes de sécurité et méthodes d'authentification

   LDAP offre les mécanismes de sécurité suivants :

- Authentification simple (Bind) fournis des mécanisme nom/mot de passe, et SASL.
- Des mécanismes pour supporter des contrôles d'accès spécifiques au vendeur
- Un service d'intégrité des données via TLS ou des mécanismes SASL
- Un service de confidentialité des données via TLS ou des mécanismes SASL
- Limitation de l'utilisation des ressources serveurs au moyen de limites administratives
- Authentification serveur via TLS ou des mécanismes SASL

   Il est désirable de permettre aux clients de s'authentifier en utilisant divers mécanismes où les identités sont représentées sous forme de DN (RFC4512), chaîne (RFC4514), ou un nom d'utilisateur simple (RFC4013). Un serveur LDAP doit supporter le mécanisme d'authentification anonyme (Bind). Les implémentations LDAP qui supportent un mécanisme d'authentification autre que l'authentification anonyme (Bind) doivent supporter le mécanisme d'authentification nom/mot de passe Bind et doivent être capable de protéger ces accréditifs en utilisant TLS

Opération StartTLS

   Le but d'utiliser TLS avec LDAP est de s'assurer de la confidentialité et de l'intégrité des données, et optionnellement fournir l'authentification. Les services d'authentification de TLS sont disponibles dans LDAP uniquement en combinaison avec la méthode d'authentification SASL externe.

StartTLS Request Sequencing

   Un client peut envoyer la requête étendue StartTLS n'importe quand après avoir établis une session LDAP, excepté:

- Quand TLS est actuellement établie dans la session
- Quand une négociation multi-niveau SASL est en cours
- Quand il y'a des réponse en attente pour des requêtes précédemment fournies dans la session

   Une violation de ces points résultent en code de retour operationsError

Certificat Client

   Si des requêtes ou des demandes LDAP qu'un client émet en fournissant un certificat durant la négociation TLS et que ce certificat n'est pas utilisable ou ne peut être validé, le serveur peut utiliser une stratégie de sécurité local pour déterminer si la négociation réussie ou non.

Vérification de l'identité du serveur

   Pour prévenir d'une attaque MITM, le client doit vérifier l'identité du serveur. L'identité du serveur est appelé l'identité de référence. Le client détermine le type de l'identité de référence (ex: nom DNS ou Address IP) et effectue une comparaison entre l'identité de référence et chaque subjectAltName. Différents subjectAltName sont matchés de différentes manière.

  Le client peut mapper l'identité de référence à un type différent avant d'effectuer une comparaison, mais devrait le mapper uniquement en types pour lesquels le mappage est soit inhérent à la sécurité (ex : extraire le nom DNS de l'URI), soit pour effectuer un mappage sécurisé (ex: DNSSEC)

  L'identité du serveur peut également être vérifié en comparant son cn dans le RDN du subjectName, bien que ce soit déprécié.

Comparaison des noms DNS

   Si l'identité de référence est un nom de domaine internationalisé, il doit être convertit en ACE (ASCII Compatible Encoding) (RFC3490) avant de le comparer au SAN, en type dNSName. Le caractère '*' est autorisé dans les valeurs SAN de type dNSName.

Comparaison des adresses IP

   Quand l'identité de référence est une adresse IP, l'identité doit être convertie en représentation "network byte order" (RFC791, RFC2460) La chaîne d'octets est comparée avec le SAN de type iPAddress.

Comparaison des autres types subjectName

   L'implémentation des clients peut supporter une comparaison avec d'autres types de valeurs dans le SAN.

Discovery of Resultant Security Level

   Une fois TLS établis dans une session LDAP, les 2 parties sont libre de continuer ou non, basé sur une stratégie local et sur le niveau de sécurité atteint. Les implémentations peuvent réévaluer le niveau de sécurité à tout moment, et si le niveau est inadéquat, devraient supprimer la couche TLS.

Refresh of Server Capabilities Information

   Une fois TLS établis dans une session LDAP, le client devrait supprimer ou rafraîchir toutes les informations sur le serveur obtenu avant l'initialisation de TLS. C'est une protection aux attaques MITM.

Suite de chiffrement TLS

   De nombreux problèmes devraient être considérés en sélectionnant la suite de chiffrement TLS:

- la capacité de la suite de chiffrement à fournir une protection de confidentialité des mots de passe et autre.
- la considération de la valeur du mot de passe et/ou données versus le niveau de confidentialité fournies par lasuite de chiffrement.
- Les vulnérabilités de la suite de chiffrement aux attaque MITM. Cette suite ne devrait pas être utilisé pour protéger les mots de passe et autres données sensibles.
- Après une négociation TLS, les 2 parties devraient vérifier que les services de sécurité fournis par la suite de chiffrement négociée sont adéquat pour la session LDAP. Si ce n'est pas le cas, TLS devrait être terminé.

Etat d'Authorisation

   Toute session LDAP a un état d'autorisation. cet état comprend de nombreux facteurs tels que l'authentification établie, comment elle a été établie, et quels services de sécurité sont en place. Certains facteurs peuvent être déterminés et/ou affectés par des évènements de protocole.

  une fois la session LDAP établie, la session a une identité d'autorisation anonyme. dès qu'une session BindRequest est reçue, le serveur place la session dans un état d'autorisation anonyme. Si la requête est réussie, la session est placée dans l'état authentification requise avec son état d'autorisation associée.

Bind Operation

   Cette opération permet d'échanger des informations d'authentification entre le client et le serveur pour établir un nouvel état d'autorisation. Si l'identité d'autorisation est spécifiée, le serveur doit vérifier que l'identité d'authentification de client est permises pour permettre l'identité d'autorisation. Le serveur doit rejeter l'opération Bind avec un code invalidCredentials si le client n'est pas autorisé.

Simple Authentication Method

   L'authentification simple fournis 3 mécanismes d'authentification:

- un mécanisme d'authentification anonyme
- un mécanisme d'authentification non-authentifié
- un mécanisme d'authentification DN/mot de passe

Anonymous Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification anonyme de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom vide et en spécifiant l'authentification simple contenant un mot de passe vide.

Unauthenticated Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification non-authentifié de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom (DN) et en spécifiant l'authentification simple contenant un mot de passe vide.

Name/Password Authentication Mechanism of Simple Bind

   Un client LDAP peut utiliser le mécanisme d'authentification nom/mot de passe de la méthode simple Bind pour établir une autorisation anonyme en envoyant un Bind Request avec un nom (DN) et en spécifiant l'authentification simple contenant un mot de passe non vide.

Méthode d'authentification SASL

   LDAP permet d'utiliser les mécanismes SASL. Vu que LDAP fournis nativement les méthodes d'authentification anonyme et nom/mot de passe, les mécanismes similaire SASL ne sont pas utilisés avec LDAP.

Initialisation de l'authentification SASL et échange du protocole

   Le mécanisme SASL est initié via un message BindRequest avec les paramètres suivants:

- la version est 3
- AuthenticationChoice est sasl
- l'élément mécanisme de la séquence SaslCredentials contient la valeur du mécanisme SASL voulu
- Les crédentials optionnels de la séquence SaslCredentials peuvent être utilisés pour fournir une réponse client initiale pour les mécanismes qui stipulent que le client envoie les données en premier.

   un challenge est indiqué par le serveur qui envoie un message BindResponse avec un resultCode de saslBindProgress.

   Au niveau du message LDAP, ces challenges et réponses sont des tokens binaires opaque de longueur arbitraire. les serveurs LDAP utilisent le champ serverSaslCreds dans un message BindResponse pour transmettre chaque challenge. Les clients LDAP utilisent le champ credentials dans la séquence SaslCredentials d'un message BindRequest pour transmettre chaque réponse.

   Les clients envoyant un message BindRequest avec le choix sasl devraient envoyer une valeurs vide dans le champs nom, et les serveurs recevant un tel message devraient ignorer la valeur du champ nom.

  Un client peut annuler une négociation SASL en envoyant un message BindRequest avec une valeur différente dans le champ mecanism de SaslCredentials ou avec AuthenticationChoice autre que sasl.

  Le serveur indique la fin d'un échange SASL en répondant avec un BindResponse avec une valeur resultCode qui n'est pas saslBindProgress.

  Le champ serverSaslCreds dans le BindResponse peut être utilisé pour inclure un challenge optionnel avec une notification success pour les mécanismes qui spécifient que le serveur envoie des données additionnelles avec l'indication de réussite.

Champs optionnels

   LDAP fournis un champ optionnel pour une réponse initial dans un échange SASL et un champ optionnel pour les données additionnelles indiquant la sortie de l'échange. Vu que le contenu de ces champs dépend du mécanisme utilisé, SASL nécessite que le protocole détail comment un champ vide est distingué d'un champ absent. Une réponse vide est distinguée par la présence de SaslCredentials.credentials OCTET STRING (de longueur 0) dans le PDU. Si le client ne fournis pas de données additionnelles, ce champs doit être omis.

Octet où La couche de sécurité négociée prend effet

   les couches SASL prennent effet suivant la transmission par le serveur et la réception par le client d'un BindResponse final dans l'échange avec un resultCode à Success. La couche reste effective jusqu'à ce qu'une nouvelle couche soit installée

Détermination des mécanismes SASL supportés

   Les clients peuvent déterminer les mécanismes SASL supportés par le serveur en lisant l'attribut supportedSASLMecanisms depuis le Root DSE. Le serveur devrait autoriser tous les clients à lire cet attribut.

Règles pour utiliser les couches SASL

   Une fois une couche SASL installée, le client devrait supprimer ou rafraîchir les informations sur le serveur obtenus avant la négociation SASL.

Identité d'autorisation SASL

   Certains mécanismes SASL permettent aux clients de demander une identité d'autorisation pour la session LDAP. La décision de permettre ou non à l'identité d'authentification courante d'avoir accès à l'identité d'authorisation demandée est une décision locale. l'identité d'autorisation est une chaîne UTF8 sous la forme:


authzId = dnAuthzId / uAuthzId
    ; distinguished-name-based authz id
dnAuthzId = "dn :" distinguishedName
    ; unspecified authorization id, UTF-8 encoded
uAuthzId = "u :" userid
userid = *UTF8 ; syntax unspecified

Mécanismes d'authentification SASL EXTERNAL

   Un client peut utiliser le mécanisme SASL EXTERNAL pour demander au serveur LDAP d'authentifier et établir une identité d'autorisation en utilisant des crédentials de sécurité échangés par une couche de sécurité tel que par l'authentification TLS.

Implicit Assertion

   Une identité d'autorisation implicite est effectuée en invoquant une requête Bind SASL utilisant le mécanisme EXTERNAL qui n'inclus pas le champ optionnel crédentials. Le serveur va dériver l'identité d'autorisation du client de l'identité d'authentification fournies par la couche de sécurité en accord avec la stratégie locale.

Explicit Assertion

   Une identité d'autorisation explicite est effectuée en invoquant une requête Bind SASL utilisant le mécanisme EXTERNAL qui inclus le champ credentials. La valeur de ce champs est l'identité d'autorisation.

Considérations de sécurité général

   LDAP lui-même ne fournis aucune sécurité ou protection pour l'accès à l'annuaire par des moyens autres que le protocole LDAP. Les données sensibles peuvent être transportés dans presque tous les messages DAP, et leur divulgation peuvent-être soumis aux lois et autres réglementations dans de nombreux pays.

   Une session dans laquelle le client n'a pas établit des services de protection et d'intégrité des données est sujet à des attaques MITM.

   L'expérience montre que les clients peuvent mal utiliser le mécanisme d'authentification non-authentifié. Par exemple, un client peut prendre la décision de demander accès à des informations une fois une requête Bind complétée. Le serveur LDAP peut induire le client en erreurs, le laissant penser qu'il a été authentifié avec succès.

   LDAP autorise des attributs de mot de passe multi-valués. Dans les systèmes où les entrées doivent avoir un seul mot de passe, les contrôles administratifs doivent être renforcés.
^
27 juillet 2013

htmlpdflatexmanmd




rfc4514

rfc4514

Représentation des Distinguished Names

   Les annuaires X.500 utilisent des DN comme clé primaire des entrées dans l'annuaire. La structure d'un DN (X.501) est décris en ASN.1 (X.680). Dans les DAP X.500, les DN sont encodé en utilisant BER (Basic Encoding Rules) (X.690). Dans LDAP, la représentation des DN est décrite dans ce document.

X.501 définis la structure ASN.1 (X.680) des DN:
DistinguishedName ::= RDNSequence
    
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
    
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
    
AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue }

Exemples

un nom contenant 3 RDN:
UID=jsmith,DC=example,DC=net
3 RDN, dont le permier est multi-valué:
OU=Sales+CN=J. Smith,DC=example,DC=net
Exemple avec des caractères échappés:
CN=James \"Jim\" Smith\, III,DC=example,DC=net
Exemple d'encodage du caractère retour chariot:
CN=Before\0dAfter,DC=example,DC=net
Exemple utilisant l'encodage BER d'une chaîne de 2 octets (0x48 et 0x69):
1.3.6.1.4.1.1466.0=#04024869
Un RDN dont le cn consiste de 5 lettres:
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
Peut être encodé:
CN=Lu\C4\8Di\C4\87
^
15 juillet 2013

htmlpdflatexmanmd




rfc4515

rfc4515

Représentation des chaînes dans le filtres de recherche

Définition d'un filtre de recherche


Filter ::= CHOICE {
    and [0] SET SIZE (1..MAX) OF filter Filter,
    or [1] SET SIZE (1..MAX) OF filter Filter,
    not [2] Filter,
    equalityMatch [3] AttributeValueAssertion,
    substrings [4] SubstringFilter,
    greaterOrEqual [5] AttributeValueAssertion,
    lessOrEqual [6] AttributeValueAssertion,
    present [7] AttributeDescription,
    approxMatch [8] AttributeValueAssertion,
    extensibleMatch [9] MatchingRuleAssertion }
    
SubstringFilter ::= SEQUENCE {
    type AttributeDescription, initial and final can occur at most once
    substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
        initial [0] AssertionValue,
        any [1] AssertionValue,
        final [2] AssertionValue } }
    
AttributeValueAssertion ::= SEQUENCE {
    attributeDesc AttributeDescription,
    assertionValue AssertionValue }
    
MatchingRuleAssertion ::= SEQUENCE {
    matchingRule [1] MatchingRuleId OPTIONAL,
    type [2] AttributeDescription OPTIONAL,
    matchValue [3] AssertionValue,
    dnAttributes [4] BOOLEAN DEFAULT FALSE }
    
AttributeDescription ::= LDAPString Constrained to ‹attributedescription› [RFC4512]
    
AttributeValue ::= OCTET STRING
    
MatchingRuleId ::= LDAPString
    
AssertionValue ::= OCTET STRING
    
LDAPString ::= OCTET STRING UTF-8 encoded, [Unicode] characters

AttributeDescription est une représentation chaîne d'une description d'attribut
AttributeValue et AssertionValue ont une forme définie dans la RFC4517

Définition des filtres de recherche

Un filtre LDAP est une chaîne UTF8 définis par la grammaire suivante (notation ABNF)
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
    [matchingrule] COLON EQUALS assertionvalue )
    / ( [dnattrs]
    matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
    ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
    ; RPAREN, ASTERISK, and ESC.
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")

Exemples

cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
utilisation du matching rule "caseExactMatch":
(cn:caseExactMatch:=Fred Flintstone)
utilisation d'un MatchingRuleAssertion sans matchingRule:
(cn:=Betty Rubble)
Utilisation de la notation :oid:
(sn:dn:2.4.6.8.10:=Barney Rubble)
equality match, excepté que le DN devrait faire partie de l'entrée:
(o:dn:=Ace Industry)
exemples de matching rules:
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
utilisation du mécanisme d'échappement:
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
^
15 juillet 2013

htmlpdflatexmanmd




rfc4516

rfc4516

Uniform Resource Locator

   Ce document décrit le format des URL LDAP v3, ainsi que les mécanismes d'extensions d'URL

Définition d'URL


ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
    [SLASH dn [QUESTION [attributes]
    [QUESTION [scope] [QUESTION [filter]
    [QUESTION extensions]]]]]
    
scheme = "ldap"
dn = distinguishedName
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selector = attributeSelector
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid
exvalue = LDAPString
EXCLAMATION = %x21 ; exclamation mark ("!")
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
    
"ldap" indique une/des entrées accéssible depuis le serveur LDAP
‹dn› est un DN identifiant l'objet de base pour la recherche
‹attributes› indique quels attributs doivent être retournés
‹scope› spécifie le scope de la recherche
‹filter› spécifie le filtre de recherche
‹extensions› fournis un mécanisme d'extension, utilisé dans de futures extension des URL. préfix par '!' indique une extension critique

Percent-Encoding

une URL LDAP doit consister des jeux de caractères restreins dans une des production suivantes:(RFC3986)
‹reserved›
‹unpreserved›
‹pct-encoded›

Valeurs par défaut

‹port› 389
‹dn› DN vaut ''
‹attributes› renvois tous les attributs utilisateur
‹scope› base
‹filter› (objectClass=*)
‹extensions› par extensions

Exemples

Réfère à l'entrée université du Michigan, disponible sur un serveur LDAP
ldap:///o=University%20of%20Michigan,c=US
Idem, en précisant le serveur LDAP
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Idem en référant uniquement à l'attribut postalAddress
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US?postalAddress
spécifie le serveur:port et référant à toute entrée avec un cn="Babs Jensen" et récupérant tous les attributs
ldap://ldap1.example.net:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
Réfère à tous les enfants de c=GB
LDAP://ldap1.example.com/c=GB?objectClass?ONE
Récupère le mail de l'entrée o=Question%3f,c=US
ldap://ldap2.example.com/o=Question%3f,c=US?mail
Illustre l'interaction entre les mécanismes de filters-quoting des chaînes LDAP et les mécanisme d'URL-quoting
ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
Illustre l'interaction entre les macnismes de DN-quoting et d'URL-quoting
ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
Les 3 requêtes suivantes sont identiques et pointent sur le root DSE de ldap.example.net
ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?
Utilisation d'une extension expérimentale et hypothétique:
ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
^
28 septembre 2013

htmlpdflatexmanmd




rfc4517

rfc4517

Syntaxe et règles de correspondance

   Chaque attribut stocké dans un annuaire LDAP, dont les valeurs peuvent être transférés dans le protocole LDAP, a une syntaxe définie qui contraint la structure et le format de ces valeurs.

Productions ABNF communes:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
    
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
    
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
    
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
    
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (" ;")
LANGLE = %x3C ; left angle bracket ("‹")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket ("›")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace
RCURLY = %x7D ; right curly brace
    
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0)
    
OCTET = %x00-FF ; Any octet (8-bit data unit) SPACE = %x20 ; space (" ")

Définitions communes
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (" :")
QUESTION = %x3F ; question mark (" ?")

Attribute Type Description

Définition d'un type d'attribut. ex:
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )

La définition LDAP pour la syntaxe de la description du type attribut est:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

Bit String

séquence de chiffre binaire:
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"

exemple:
'0101111101'B
La définition LDAP pour la syntaxe chaine de bits:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

Boolean


Boolean = "TRUE" / "FALSE"

La définition LDAP pour la syntaxe booléen est:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

Country String

Code de 2 caractèresISO 3166 pour représenter un pays:
CountryString = 2(PrintableCharacter)

exemple:
US
AU
La définition LDAP pour la syntaxe Country String est:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )

Delivery Method

Séquence d'éléments qui indiquent, par ordre de préférence, les services par lesquels une entité est prête et/ou capable de recevoir des messages:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"

exemple:
telephone $ videotex
La définition LDAP pour la méthode de livraison est:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

Directory String

Chaîne de caractères arbitraire UCS (Universal Character Set). Une valeur nulle n'est pas permise:
DirectoryString = 1*UTF8

exemple:
This is a value of Directory String containing # !%#@.
La définition LDAP pour les chaînes d'annuaire est:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

DIT Content Rule Description

   La syntaxe est décrite dans la rfc 4512

exemple:
( 2.5.6.4 DESC 'content rule for organization' NOT ( x121Address $ telexNumber ) )
La définition LDAP pour la syntaxe DIT Content Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )

DIT Structure Rule Description

   La syntaxe est décrite dans la rfc 4512

exemple:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
La définition LDAP pour la DIT Structure Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' )

DN

   La syntaxe est définie dans la rfc 4514

exemples:
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
La définition LDAP pour la syntaxe DN est:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )

Enhanced Guide

consiste de combinaison de types d'attributs et opérateurs de recherche; à utiliser dans la construction de filtres pour rechercher des entrées de classe d'objet particulier
EnhancedGuide = object-class SHARP WSP criteria WSP
    SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
    
criteria = and-term *( BAR and-term )
and-term = term *( AMPERSAND term )
term = EXCLAIM term / attributetype DOLLAR match-type / LPAREN criteria RPAREN / true / false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = " ?true"
false = " ?false"
BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark (" !")

La définition LDAP de la syntaxe Enhanced Guide est:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
exemple:
person#(sn$EQ)#oneLevel

Facsimile Telephone Number


fax-number = telephone-number *( DOLLAR fax-parameter )
    telephone-number = PrintableString
    fax-parameter = "twoDimensional" / "fineResolution" / "unlimitedLength" / "b4Length" / "a3Width" / "b4Width" / "uncompressed"

La définition LDAP pour Facsimile Telephone Number est:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')

Fax

la définition LDAP de la syntaxe Fax est:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

Generalized Time

Chaîne représentant une date et heure. L'encodage LDAP est une restriction du format définis dans ISO8601
GeneralizedTime = century year month day hour
    [ minute [ second / leap-second ] ]
    [ fraction ]
    g-time-zone
    
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09" / ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09" / ( %x31-32 %x30-39 ) ; "10" to "29" / ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
    
second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60"
    
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z" / g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")

exemple:
199412161032Z
199412160532-0500
La définition LDAP pour Generalized Time est:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )

Guide

consiste de combinaison de types d'attributs et opérateurs de recherche ; à utiliser dans la construction de filtres pour rechercher des entrées de classe d'objet particulier. Obsolète.
Guide = [ object-class SHARP ] criteria

La définition LDAP pour la syntaxe Guide est:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )

IA5 String

   Chaîne de 0, un ou plusieurs caractères de l'alphabet International 5 (IA5)

La définition LDAP pour la syntaxe IA5 String est:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

Integer


Integer = ( HYPHEN LDIGIT *DIGIT ) / number

La définition LDAP pour la syntaxe Interger est:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

JPEG

   Image au format JFIF (JPEG File Interchange Format)

La définition LDAP de la syntaxe JPEG est:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )

LDAP Syntax Description

Description d'une syntaxe LDAP. La définition LDAP pour la syntaxe LDAP Syntaxe Description est:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )

Matching Rule Description

Définition d'un matching rule. La définition LDAP pour la syntaxe Matching Rule Description est:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
exemple:
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Matching Rule Use Description

La définition LDAP de la syntaxe Matching Rule Use Description est:
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' )
exemple:
( 2.5.13.16 APPLIES ( givenName $ surname ) )

Name and Optional UID

DN d'une entité optionnellement accompagnée par un id unique qui sert à différentier l'entité des autres avec un dn identique :
NameAndOptionalUID = distinguishedName [ SHARP BitString ]

exemple:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
La définition LDAP pour la syntaxe Name and Optional UID est:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )

Name Form Description

La définition LDAP pour la syntaxe Name Form Description est:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
exemple:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )

Numeric String

Séquence d'un ou plusieurs numéraires et espaces
NumericString = 1*(DIGIT / SPACE)

exemple:
15 079 672 281
La définition LDAP pour la syntaxe Numeric String est:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )

Object Class Description

exemple:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) )
La définition LDAP pour la syntaxe Object Class Description est:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

Octet String

Séquence de 0, 1 ou plusieurs octets arbitraire.
OctetString = *OCTET

La définition LDAP pour la syntaxe Octet String est :
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

OID

   Séquence de 2 ou plusieurs entiers non-négatifs qui identifie de manière unique certain objets ou spécifications.

exemple:
1.2.3.4
cn
La définition LDAP pour la syntaxe OID est:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )

Other Mailbox

Identifie une boite de messagerie électronique.
OtherMailbox = mailbox-type DOLLAR mailbox
    mailbox-type = PrintableString
    mailbox = IA5String

La définition LDAP pour la syntaxe Other Mailbox est:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

Postal Address

Séquence arbitraire d'un ou plusieurs caractères UCS, qui forment une adresse d'un système de messagerie physique
PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
    / (%x5C "24") ; escaped "$"
    / %x25-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-7F
    / UTFMB

exemple:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
La définition LDAP pour la syntaxe Postal Address est:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )

Printable String

   Chaîne d'un ou plusieurs caractères imprimable

exemple:
ceci est une chaîne imprimable
La définition LDAP pour la syntaxe Printable String est:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

Substring Assertion

Séquence de 0, 1 ou plusieurs caractères sous-chaîne utilisé comme argument pour les correspondance de sous-chaîne extensible.
SubstringAssertion = [ initial ] any [ final ]
    
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")
    
substring = 1*substring-character
substring-character = %x00-29
    / (%x5C "2A") ; escaped "*"
    / %x2B-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-7F
    / UTFMB

La définition LDAP pour la syntaxe Substring Assertion est:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )

Telephone Number

exemple:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830
La définition LDAP pour la syntaxe Telephone Number est:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

Teletex Terminal Identifier


teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-octet
    
ttx-value-octet = %x00-23
    / (%x5C "24") ; escaped "$"
    / %x25-5B
    / (%x5C "5C") ; escaped "\"
    / %x5D-FF

La définition LDAP pour la syntaxe Teletex Terminal Identifier est:
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )

Telex Number


telex-number = actual-number DOLLAR country-code
    DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString

La définition LDAP pour la syntaxe Telex Number est:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

UTC Time

Chaîne représentant une date et heure à une précision d'une minute ou une seconde.
UTCTime = year month day hour minute [ second ]
    [ u-time-zone ]
u-time-zone = %x5A ; "Z"
    / u-differential
u-differential = ( MINUS / PLUS ) hour minute

La définition LDAP pour la syntaxe UTC Time est:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )

Règles de correspondance

   Ces règles sont utilisées par les annuaires pour comparer des valeurs d'attribut avec des valeurs lors d'opérations de recherche et de comparaison. Elles sont utilisée également pour comparer un dn emprunté avec le nom d'une entrée. En modifiant des entrées, ces règles sont utilisées pour identifier des valeurs à supprimer et pour empêcher qu'un attribut ne contienne 2 valeurs égales.

   Un matching rule est appliqué à un attribut via un AttributeValueAssertion ou un MatchingRuleAssertion. Si une assertion est définie, le résultat de l'assertion est le résultat de l'application de la règle appliquée.

   La description de chaque règle indique si la règle est utilisable pour une égalité (EQUALITY), ordonnancement (ORDERING) ou sous-chaîne (SUBSTR) dans une définition de type d'attribut.

   Les serveurs doivent publier, dans l'attribut matchinRules, les définitions des règles référencées dans le même sous-schéma. Si le serveur supporte le filtre extensibleMatch, le serveur peut utiliser l'attribut matchingRuleUse pour indiquer cette capacité.

   Les comparaison de chaîne "caseIgnore" sont des comparaisons insensibles à la casse.

bitStringMatch

   Comparaison de chaîne de bits. (règle d'égalité)

La définition LDAP pour la règle bitStringMatch est:
( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

booleanMatch

   Comparer une valeur booléenne. (règle d'égalité)

La définition LDAP pour la règle booleanMatch est:
( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

caseExactIA5Match

   Comparaison d'une chaîne IA5. (règle d'égalité)

La définition LDAP pour la règle caseExactIA5Match est:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

caseExactMatch

   Comparaison de syntaxe Directory String. (règle d'égalité)

La définition LDAP pour la règle caseExactMatch est:
( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseExactOrderingMatch

   Comparaison d'une syntaxe Directory String. (règle d'ordonnancement)

La définition LDAP pour la règle caseExactOrderingMatch est:
( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseExactSubstringsMatch

   Compare une syntaxe Substring Assertion. (règle de substring)

La définition LDAP pour la règle caseExactSubstringsMatch est:
( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

caseIgnoreIA5Match

   Comparaison de chaîne IA5 (règle d'égalité)

La définition LDAP pour la règle caseIgnoreIA5Match est:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

caseIgnoreIA5SubstringsMatch

   Comparaison de substring IA5. (règle de substring)

La définition LDAP pour la règle caseIgnoreIA5SubstringsMatch est:
( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

caseIgnoreListSubstringsMatch

   Comparaison de substring d'une syntaxe Directory String. (règle de substring)

La définition LDAP pour la règle caseIgnoreListSubstringsMatch est:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

caseIgnoreMatch

   Comparaison de syntaxe Directory String. (règle d'égalité)

La définition LDAP pour la règle caseIgnoreMatch est:
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseIgnoreOrderingMatch

   Comparaison de syntaxe Directory String. (règle d'ordonnancement)

La définition LDAP pour la règle caseIgnoreOrderingMatch est:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

caseIgnoreSubstringsMatch

   Comparaison de substring syntaxe Directory String. (règle de substring)

La définition LDAP pour la règle caseIgnoreSubstringsMatch est:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

directoryStringFirstComponentMatch

   Comparaison de syntaxe Directory String dont la syntaxe est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle directoryStringFirstComponentMatch est:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

distinguishedNameMatch

   Comparaison de DN. (règle d'égalité)

La définition LDAP pour la règle distinguishedNameMatch est:
( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

generalizedTimeMatch

   Comparaison de syntaxe Generalized Time. (règle d'égalité)

La définition LDAP pour la règle generalizedTimeMatch est:
( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

generalizedTimeOrderingMatch

   Comparaison d'ordre de temps de syntaxe Generalized Time. (règle d'ordonnancement)

La définition LDAP pour la règle generalizedTimeOrderingMatch est:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

integerFirstComponentMatch

   Comparaison de valeur Integer dont le type est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle integerFirstComponentMatch est:
( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

integerMatch

   Comparaison de valeur entière. (règle d'égalité)

La définition LDAP pour la règle integerMatch est:
( 2.5.13.14 NAME 'integerMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

integerOrderingMatch

   Comparaison d'ordre de valeur entière. (règle d'ordonnancement)

La définition LDAP pour la règle integerOrderingMatch est:
( 2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

keywordMatch

   Comparaison de valeur de mot clé dans une syntaxe DirectoryString. (règle d'égalité)

La définition LDAP pour la règle keywordMatch est:
( 2.5.13.33 NAME 'keywordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

numericStringMatch

   Comparaison de chaîne numérique. (règle d'égalité)

La définition LDAP pour la règle numericStringMatch est:
( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

numericStringOrderingMatch

   Comparaison de syntaxe substring Assertion dans une valeur d'attribut de type NumericString. (règle d'égalité)

La définition LDAP pour la règle numericStringOrderingMatch est:
( 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

objectIdentifierFirstComponentMatch

   Comparaison d'OID dont le type est une séquence avec un premier composant obligatoire. (règle d'égalité)

La définition LDAP pour la règle objectIdentifierFirstComponentMatch est:
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

objectIdentifierMatch

   Comparaison d'OID. (règle d'égalité)

La définition LDAP pour la règle objectIdentifierMatch est:
( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

octetStringMatch

   Comparaison de syntaxe Octet String. (règle d'égalité)

La définition LDAP pour la règle octetStringMatch est:
( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

octetStringOrderingMatch

   Comparaison d'ordonnancement de chaîne d'octets. (règle d'ordonnancement)

La définition LDAP pour la règle octetStringOrderingMatch est:
( 2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

telephoneNumberMatch

   Comparaison de syntaxe TelephoneNumber. (règle d'égalité)

La définition LDAP pour la règle telephoneNumberMatch est:
( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

telephoneNumberSubstringsMatch

   Comparaison de substring de syntaxe TelephoneNumber. (règle de substring)

La définition LDAP pour la règle telephoneNumberSubstringsMatch est:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

uniqueMemberMatch

   Comparaison de syntaxe NameAndOptionalUID. (règle d'égalité)

La définition LDAP pour la règle uniqueMemberMatch est:
( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

wordMatch

   Comparaison de mot dans une valeur de syntaxe DirectoryString.

La définition LDAP pour la règle wordMatch est:
( 2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
^
07 juillet 2013

htmlpdflatexmanmd




rfc4519

rfc4519

Schema pour les applications utilisateurs

Attributs

businessCategory Décrit le type de business de l’entreprise
c countryName dans x500 (code à 2 lettres du pays)
cn commonName dans x500. Nom d’un objet
dc domainComponent, chaîne contenant un composant du domaine DNS
description Description de l’objet
destinationIndicator Contient la ville et le pays associé avec un objet nécessaire pour fournir le Public Telegram Service (ex : AASD)
distinguisedName type de base depuis lequel les type d’attributs utilisateur avec une syntaxe DN peuvent hériter
dnQualifier Contient des informations non-ambiguës à ajouter au RDN d’une entrée
enhancedSearchGuide Jeu d’informations utilisés par les client LDAP pour construire des filtres de recherche (ex : "person#(sn$APPROX)#wholeSubtree", ex : "organizationalUnit#(ou$SUBSTR)#oneLevel")
facsimileTelephoneNumber Numéro de téléphone (et optionnellement, les paramètres) pour les terminaux de télécopie
generationQualifier Contient généralement un suffixe du nom d’une personne (ex : "III", "3rd", "Jr.")
givenName Prénom d’une personne
houseIdentifier Identifiant d’un immeuble
initials Initial du prénom
internationalISDNNumber Adresses Integrated Service Digital Network.
l localityName dans X500. nom d’emplacement tel qu’un ville, un pays, région...
member Liste de DN d’objets
name supertype d’attribut depuis lequel les types d’attribut utilisateurs avec une syntaxe de nom peuvent hériter
o organizationName dans x500, contient les nom d’une organisation ( ex : Widget", "Widget, Inc.", "Widget, Incorporated.")
ou organizationalUnitName dans x500, contient les noms d’une unité organisationnelle (ex : "Finance", "Human Resources", "Research et "Development")
owner Contient le DN des objets qui sont responsable de cet objet
physicalDeliveryOfficeName Contient les noms qu’un service postal utilise pour identifier un bureau de poste (ex : Bremerhaven, Main" et "Bremerhaven, Bonnstrasse")
postalAddress Contient les adresses utilisées par un service postal pour effectuer des services pour l’objet (ex : "15 Main St.$Ottawa$Canada")
postalCode Contient les codes utilisés par le service postal pour identifier les zones de service postal ( ex : "22180")
postOfficeBox Contient les identifiant de boite postal (ex : "Box 45")
preferredDeliveryMethod Contient une indication de la méthode préférée pour envoyer un message à l’objet (ex : "mhs $ telephone")
registeredAddress Contient l’adresse postal pour la réception de télégrammes ou documents expédiés (ex : "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada")
roleOccupant Contient les DN des objets qui sont responsable d’un objet rôle
searchGuide Contient des jeux d’information à utiliser par des clients pour construire des filtres de recherche (ex : "person#sn$EQ")
seeAlso Contient les DN des objets liés au sujet de l’objet
serialNumber Contient les numéros de série des périphériques
sn surname dans X500. Nom de famille d’une personne
st stateOrProvinceName dans X500. nom des états ou provinces
street streetAddress dans X500. Adresses postales
telephoneNumber Numéros de téléphone qui respectent la recommandation ITU E.123 (ex : "+1 234 567 8901")
teletexTerminalIdentifier Le retrait de la recommandation F.200 a résulté du retrait de cet attribut
telexNumber Contient des jeux de numéro telex (ex : "12345$023$ABCDE")
title Titre d’une personne (ex : "Vice President", "Software Engineer", and "CEO")
uid Nom de connexion asocié avec l’objet
uniqueMember Contient les DN d’un objet qui sont dans une liste ou dans un groupe
userPassword Contient une chaîne utilisée pour l’authentification d’un objet
x121Address Adresse réseau tel que définis par la recommandation X.121 (ex : "36111222333444555")
x500UniqueIdentifier Chaîne binaire utilisé pour distinguer des objets quand un DN a été réutilisé

ObjectClass

applicationProcess Base d’une entrée qui représente une application s’exécutant sur une machine
country Base d’une entrée qui représente un pays
dcObject Permet à une entrée de contenir une composante de domaine
device Base d’une entrée qui représente une appliance, ordinateur ou élément réseau
groupOfNames Base d’une entrée qui représente un jeu d’objets nommés
groupOfUniqueNames Idem à groupOfNames excepté que les noms ne sont pas répétés ou réassigné dans un scope
locality Base d’une entrée qui représente une place dans le monde physique
organization Base d’une entrée qui représente un groupe de personne structuré
organizationalPerson Base d’une entrée qui représente une personne en relation à une organisation
organizationalRole Base d’une entrée qui représente un job, fonction ou position dans une organisation
organizationalUnit Base d’une entrée qui représente un pièce dans une organisation
person Base d’une entrée qui représente une personne
residentialPerson Base d’une entrée qui représente la résidence d’une personne dans la représentation de la personne
uidObject Permet à une entrée de contenir des information d’identification d’un utilisateur

Définition des attributs


attributetype ( 2.5.4.15 NAME ’businessCategory’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.6 NAME ’c’
    SUP name
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
    SINGLE-VALUE )
    
attributetype ( 2.5.4.3 NAME ’cn’
    SUP name )
    
attributetype ( 0.9.2342.19200300.100.1.25 NAME ’dc’
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )
    
attributetype ( 2.5.4.13 NAME ’description’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.27 NAME ’destinationIndicator’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.49 NAME ’distinguishedName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributetype ( 2.5.4.46 NAME ’dnQualifier’
    EQUALITY caseIgnoreMatch
    ORDERING caseIgnoreOrderingMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.47 NAME ’enhancedSearchGuide’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
    
attributetype ( 2.5.4.23 NAME ’facsimileTelephoneNumber’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
    
attributetype ( 2.5.4.44 NAME ’generationQualifier’
    SUP name )
    
attributetype ( 2.5.4.42 NAME ’givenName’
    SUP name )
    
attributetype ( 2.5.4.51 NAME ’houseIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.43 NAME ’initials’
    SUP name )
    
attributetype ( 2.5.4.25 NAME ’internationalISDNNumber’
    EQUALITY numericStringMatch
    SUBSTR numericStringSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
    
attributetype ( 2.5.4.7 NAME ’l’
    SUP name )
    
attributetype ( 2.5.4.31 NAME ’member’
    SUP distinguishedName )
    
attributetype ( 2.5.4.41 NAME ’name’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.10 NAME ’o’
    SUP name )
    
attributetype ( 2.5.4.11 NAME ’ou’
    SUP name )
    
attributetype ( 2.5.4.32 NAME ’owner’
    SUP distinguishedName )
    
attributetype ( 2.5.4.19 NAME ’physicalDeliveryOfficeName’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.16 NAME ’postalAddress’
    EQUALITY caseIgnoreListMatch
    SUBSTR caseIgnoreListSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
    
attributetype ( 2.5.4.17 NAME ’postalCode’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.18 NAME ’postOfficeBox’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.28 NAME ’preferredDeliveryMethod’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
    SINGLE-VALUE )
    
attributetype ( 2.5.4.26 NAME ’registeredAddress’
    SUP postalAddress
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
    
attributetype ( 2.5.4.33 NAME ’roleOccupant’
    SUP distinguishedName )
    
attributetype ( 2.5.4.14 NAME ’searchGuide’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
    
attributetype ( 2.5.4.34 NAME ’seeAlso’
    SUP distinguishedName )
    
attributetype ( 2.5.4.5 NAME ’serialNumber’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
    
attributetype ( 2.5.4.4 NAME ’sn’
    SUP name )
    
attributetype ( 2.5.4.8 NAME ’st’
    SUP name )
    
attributetype ( 2.5.4.9 NAME ’street’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.20 NAME ’telephoneNumber’
    EQUALITY telephoneNumberMatch
    SUBSTR telephoneNumberSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    
attributetype ( 2.5.4.22 NAME ’teletexTerminalIdentifier’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
    
attributetype ( 2.5.4.21 NAME ’telexNumber’
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
    
attributetype ( 2.5.4.12 NAME ’title’
    SUP name )
    
attributetype ( 0.9.2342.19200300.100.1.1 NAME ’uid’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributetype ( 2.5.4.50 NAME ’uniqueMember’
    EQUALITY uniqueMemberMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
    
attributetype ( 2.5.4.35 NAME ’userPassword’
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
    
attributetype ( 2.5.4.24 NAME ’x121Address’
    EQUALITY numericStringMatch
    SUBSTR numericStringSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
    
attributetype ( 2.5.4.45 NAME ’x500UniqueIdentifier’
    EQUALITY bitStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

Définition des classes d’objets

objectclass ( 2.5.6.11 NAME ’applicationProcess’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( seeAlso $ ou $ l $ description ) )
    
objectclass ( 2.5.6.2 NAME ’country’
    SUP top
    STRUCTURAL
    MUST c
    MAY ( searchGuide $ description ) )
    
objectclass ( 1.3.6.1.4.1.1466.344 NAME ’dcObject’
    SUP top
    AUXILIARY
    MUST dc )
    
objectclass ( 2.5.6.14 NAME ’device’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
    
objectclass ( 2.5.6.9 NAME ’groupOfNames’
    SUP top
    STRUCTURAL
    MUST ( member $ cn )
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
    
objectclass ( 2.5.6.17 NAME ’groupOfUniqueNames’
    SUP top
    STRUCTURAL
    MUST ( uniqueMember $ cn )
    MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
    
objectclass ( 2.5.6.3 NAME ’locality’
    SUP top
    STRUCTURAL
    MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
    
objectclass ( 2.5.6.4 NAME ’organization’
    SUP top
    STRUCTURAL
    MUST o
    MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $
    destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
    telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $
    postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
    
objectclass ( 2.5.6.7 NAME ’organizationalPerson’
    SUP person
    STRUCTURAL
    MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $
    telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $
    facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
    
objectclass ( 2.5.6.8 NAME ’organizationalRole’
    SUP top
    STRUCTURAL
    MUST cn
    MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
    teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $
    seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
    
objectclass ( 2.5.6.5 NAME ’organizationalUnit’
    SUP top
    STRUCTURAL
    MUST ou
    MAY ( businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationalISDNNumber $ l $
    physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $
    registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address ) )
    
objectclass ( 2.5.6.6 NAME ’person’
    SUP top
    STRUCTURAL
    MUST ( sn $
    cn )
    MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
    
objectclass ( 2.5.6.10 NAME ’residentialPerson’
    SUP person
    STRUCTURAL
    MUST l
    MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $
    telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $
    facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ st $ l ) )
    
objectclass ( 1.3.6.1.1.3.1 NAME ’uidObject’
    SUP top
    AUXILIARY
    MUST uid )

^
02 novembre 2013

htmlpdflatexmanmd




rfc4521

rfc4521

Extentions LDAP

Mécanisme de découverte

   LDAP ne fournis aucun mécanisme pour qu'un serveur découvre les capacité des clients. L'attribut supportedControl du RootDSE est utilisé pour avertir des opérations étendues supportées. l'attribut supportedFeatures est utilisé pour avertir des fonctionnalités. D'autres attributs du RootDSE peut être utilisés pour avertir d'autres capacités.

   LDAP est conçus pour supporter unicode. les options de tag de langue (rfc 3866) fournissent un mécanisme pour tag les valeurs avec des informations de langue.

Extensions d'opération LDAP

   Les extensions devraient utiliser les contrôles pour définir des extensions qui complémentent des opérations existantes, sinon, il est préférable de définir des opérations étendues.

Contrôles

   Les contrôles sont recommandés pour étendre de opérations existantes. Une opération existante peut être une opération de base, une opération étendue, une modification de mot de passe ou une opération définie comme extension d'une opération de base ou étendue.

   Les extensions ne devraient pas retourner de réponse à moins que le serveur sait que le client peut utiliser ce contrôle. Une opération existante peut être étendue pour retourner des messages IntermediateResponse. Les contrôles ne devraient pas définir de sémantique additionnelles à la criticité des contrôles.

Étendre l'opération Bind avec des contrôles

   Les contrôles attachés aux messages de requête et de réponse d'une opération Bind ne sont pas protégés par une couche de sécurité établie par l'opération bind.

Étendre l'opération StartTLS avec des contrôles

   Les contrôles attachés aux messages de requête et de réponse d'une opération StartTLS ne sont pas protégés par la couche de sécurité.

Étendre l'opération de recherche avec des contrôles

   L'opération de recherche a 2 phases:

- trouver l'objet de base
- Rechercher les objets à ou sous l'objet de base.

   Les contrôles étendant la recherche devraient clairement statuer sur quelle(s) phase(s) le contrôle s'applique.

Étendre les opérations update avec des contrôles

   Les opération update ont des propriétés d'atomicité, consistance, isolation et durabilité (ACID)

atomicité: tous ou aucun des changements demandés ont été fait
consistance: L'état DIT résultant doit être conforme au schéma et d'autres contraintes
isolation: les états intermédiaires ne sont pas exposés
durabilité: l'état DIT résultant est préservé jusqu'à une mise à jours ultérieure.

   En définissant un contrôle qui demande des changements additionnels, ces changements ne devraient pas être traités comme partie d'une transaction séparée

Réponses intermédiaires

   Les extensions devraient utiliser les messages IntermediateResponse au lieu des messages ExtendedResponse pour retourner des résultats intermédiaires.

Notifications non-sollicitées

   Les notifications non-sollicitées permettent à un serveur de notifier le client d'évènements non associés avec l'opération courante. Ces extensions doivent être conçues de manière à ce qu'un serveur n'envoie ces notification que s'il sait que le client peut utiliser ces notifications.

Code de résultat

   Les extensions qui spécifient de nouvelles opérations ou améliorent des opérations existantes ont souvent besoin de nouveaux code de résultat. L'extension doit être conçue de manière à ce qu'un client ait une indication clair de la nature du résultat.

Types de message LDAP

   Les extensions peuvent spécifier de nouveaux types de messages LDAP en étendant le choix protocolOp de la séquence LDAPMessage, mais c'est généralement inapproprié et non-nécessaire. Cependant, dans certains cas, de nouveaux mécanismes d'extensions devraient être définis.

Méthodes d'authentification

   Bind supporte 2 méthodes d'authentification, simple et SASL. Il est recommandé que les nouveau processus d'authentification soient définis comme mécanisme SASL.

Extension de schéma

   Les extensions définissant des éléments de schéma LDAP doivent fournir la définition de schéma conformément avec la syntaxe définie.

Syntaxes LDAP

   Chaque syntaxe LDAP est définie en terme d'ASN.1. Chaque extension détaillant une syntaxe LDAP doit spécifier les données ASN.1 associées avec la syntaxe.

Matching Rules

   3 types basique de règle de correspondance peuvent être associés avec un type d'attribut. En plus, LDAP fournis un mécanisme de règle extensible.

Autres mécanismes étendu

   Chaque option est identifiée par une chaîne de lettres, nombre et tirets. Cette chaîne devrait être courte.

   Les extensions interagissant avec des identité d'authorisation devraient supporter le format authzId. ce format est extensible.

   Les extensions d'URL LDAP sont identifiées par une chaîne courte, un descripteur, la chaîne devrait être courte.
^
03 novembre 2013

htmlpdflatexmanmd




rfc4523

rfc4523

Définition de schéma pour les certificats x.509

Syntaxes

certificate
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
CertificateList
( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
CertificatePair
( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
SupportedAlgorithm
( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'X.509 Supported Algorithm' )
CertificateExactAssertion
( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
CertificateAssertion
( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
CertificatePairExactAssertion
( 1.3.6.1.1.15.3 DESC 'X.509 Certificate Pair Exact Assertion' )
CertificatePairAssertion
( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
CertificateListExactAssertion
( 1.3.6.1.1.15.5 DESC 'X.509 Certificate List Exact Assertion' )
CertificateListAssertion
( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
AlgorithmIdentifier
( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )

Matching Rules

certificateExactMatch
( 2.5.13.34 NAME 'certificateExactMatch' DESC 'X.509 Certificate Exact Match' SYNTAX 1.3.6.1.1.15.1 )
certificateMatch
( 2.5.13.35 NAME 'certificateMatch' DESC 'X.509 Certificate Match' SYNTAX 1.3.6.1.1.15.2 )
certificatePairExactMatch
( 2.5.13.36 NAME 'certificatePairExactMatch' DESC 'X.509 Certificate Pair Exact Match' SYNTAX 1.3.6.1.1.15.3 )
certificatePairMatch
( 2.5.13.37 NAME 'certificatePairMatch' DESC 'X.509 Certificate Pair Match' SYNTAX 1.3.6.1.1.15.4 )
certificateListExactMatch
( 2.5.13.38 NAME 'certificateListExactMatch' DESC 'X.509 Certificate List Exact Match' SYNTAX 1.3.6.1.1.15.5 )
certificateListMatch
( 2.5.13.39 NAME 'certificateListMatch' DESC 'X.509 Certificate List Match' SYNTAX 1.3.6.1.1.15.6 )
algorithmIdentifierMatch
( 2.5.13.40 NAME 'algorithmIdentifier' DESC 'X.509 Algorithm Identifier Match' SYNTAX 1.3.6.1.1.15.7 )

Attributes

userCertificate
( 2.5.4.36 NAME 'userCertificate' DESC 'X.509 user certificate' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
cACertificate
( 2.5.4.37 NAME 'cACertificate' DESC 'X.509 CA certificate' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
crossCertificatePair
( 2.5.4.40 NAME 'crossCertificatePair' DESC 'X.509 cross certificate pair' EQUALITY certificatePairExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
certificateRevocationList
( 2.5.4.39 NAME 'certificateRevocationList' DESC 'X.509 certificate revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
authorityRevocationList
( 2.5.4.38 NAME 'authorityRevocationList' DESC 'X.509 authority revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
deltaRevocationList
( 2.5.4.53 NAME 'deltaRevocationList' DESC 'X.509 delta revocation list' EQUALITY certificateListExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
supportedAlgorithms
( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'X.509 supported algorithms' EQUALITY algorithmIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )

ObjectClass

pkiUser
( 2.5.6.21 NAME 'pkiUser' DESC 'X.509 PKI User' SUP top AUXILIARY MAY userCertificate )
pkiCA
( 2.5.6.22 NAME 'pkiCA' DESC 'X.509 PKI Certificate Authority' SUP top AUXILIARY MAY ( cACertificate $ certificateRevocationList $ authorityRevocationList $ crossCertificatePair ) )
cRLDistributionPoint
( 2.5.6.19 NAME 'cRLDistributionPoint' DESC 'X.509 CRL distribution point' SUP top STRUCTURAL MUST cn MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) )
deltaCRL
( 2.5.6.23 NAME 'deltaCRL' DESC 'X.509 delta CRL' SUP top AUXILIARY MAY deltaRevocationList )
strongAuthenticationUser (déprécié en faveur de pkiUser)
( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'X.521 strong authentication user' SUP top AUXILIARY MUST userCertificate )
userSecurityInformation
( 2.5.6.18 NAME 'userSecurityInformation' DESC 'X.521 user security information' SUP top AUXILIARY MAY ( supportedAlgorithms ) )
certificationAuthority (déprécié en faveur de pkiCA)
( 2.5.6.16 NAME 'certificationAuthority' DESC 'X.509 certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair )
certificationAuthority-V2 (déprécié en faveur de pkiCA)
( 2.5.6.16.2 NAME 'certificationAuthority-V2' DESC 'X.509 certificate authority, version 2' SUP certificationAuthority AUXILIARY MAY deltaRevocationList )
^
07 juillet 2013

htmlpdflatexmanmd




rfc4524

rfc4524

Schéma pour les projets pilote X.500 Internet et COSINE

Attributs

associatedDomain Spécifie les noms d’hôte DNS associé à un objet
associatedName Spécifie les noms des entrées dans le DIT organisationnel associé avec un domaine DNS
buildingName Spécifie les noms des immeubles où un organisation ou unité d’organisation est basée
co Friendly Country Name, Spécifie les noms des pays (ex : "Germany", "Federal Republic of Germany")
documentAuthor Spécifie les DN des auteurs d’un document
documentIdentifier Spécifie les identifiants unique pour un document.
documentLocation Spécifie les emplacements du document original
documentPublisher Personnes et/ou organisations qui ont publiés le document
documentTitle Spécifie les titres d’un document
documentVersion Spécifie la version d’un document
drink (favoriteDrink) Spécifie la boisson favorite d’un objet
homePhone (HomeTelephoneNumber) Numéro de téléphone d’une personne
homePostalAddress Spécifie l’adresse postale du domicile de l’objet
host Spécifie le nom d’hôte des ordinateurs
info Spécifie des informations spécifiques à l’objet
mail (rfc822mailbox) Contient les addresse mail Internet
manager Spécifie les DN des responsables d’un objet
mobile (mobileTelephoneNumber) spécifie les numéros de téléphone portable
organizationalStatus Spécifie des catégories par lesquelles une personne est référée dans l’entreprise
pager (pagerTelephoneNumber)
personalTitle Titres personnels pour une personne
roomNumber Numéro de salle
secretary Spécifie les secrétaire et/ou assistantes administratives de l’objet
uniqueIdentifier Identifiant unique pour un objet représenté dans l’annuaire
userClass Spécifie les catégories de machine ou application utilisateur

Classes d'objets

account Définis des entrées représentant des comptes machine. l’uid devrait être utilisé pour nommer l’entrée.
document Définis des entrées qui représente des documents
documentSeries Définis une entrée qui représente une série de documents
domain Définis des entrées qui représente des domaines DNS.
domainRelatedObject Définis des entrées qui représentent des domaines DNS qui sont équivalent à un domaine X.500
friendlyCountry Définis des entrées représentant des pays dans le DIT
rFC822LocalPart Définis des entrées qui représentent lapartie local des adresses email Internet
room Définis des entrées représentant des salles
simpleSecurityObject Utilisé pour avoir userPassword

Définition des attributs


attributeType ( 0.9.2342.19200300.100.1.37 NAME ’associatedDomain’
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
    
attributeType ( 0.9.2342.19200300.100.1.38 NAME ’associatedName’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.48 NAME ’buildingName’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.43 NAME ’co’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributeType ( 0.9.2342.19200300.100.1.14 NAME ’documentAuthor’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.11 NAME ’documentIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.15 NAME ’documentLocation’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.56 NAME ’documentPublisher’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
    
attributeType ( 0.9.2342.19200300.100.1.12 NAME ’documentTitle’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.13 NAME ’documentVersion’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.5 NAME ’drink’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.20 NAME ’homePhone’
    EQUALITY telephoneNumberMatch
    SUBSTR telephoneNumberSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    
attributeType ( 0.9.2342.19200300.100.1.39 NAME ’homePostalAddress’
    EQUALITY caseIgnoreListMatch
    SUBSTR caseIgnoreListSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
    
attributeType ( 0.9.2342.19200300.100.1.9 NAME ’host’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.4 NAME ’info’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.152048 )
    
attributeType ( 0.9.2342.19200300.100.1.3 NAME ’mail’
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26256 )
    
attributeType ( 0.9.2342.19200300.100.1.10 NAME ’manager’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.41 NAME ’mobile’
    EQUALITY telephoneNumberMatch
    SUBSTR telephoneNumberSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    
attributeType ( 0.9.2342.19200300.100.1.45 NAME ’organizationalStatus’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.42 NAME ’pager’
    EQUALITY telephoneNumberMatch
    SUBSTR telephoneNumberSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    
attributeType ( 0.9.2342.19200300.100.1.40 NAME ’personalTitle’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.6 NAME ’roomNumber’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.21 NAME ’secretary’
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
    
attributeType ( 0.9.2342.19200300.100.1.44 NAME ’uniqueIdentifier’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )
    
attributeType ( 0.9.2342.19200300.100.1.8 NAME ’userClass’
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15256 )

Définition des classes d'objets


objectclass ( 0.9.2342.19200300.100.4.5 NAME ’account’
    SUP top STRUCTURAL
    MUST uid
    MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
    
objectclass ( 0.9.2342.19200300.100.4.6 NAME ’document’
    SUP top STRUCTURAL
    MUST documentIdentifier
    MAY ( cn $ description $ seeAlso $ l $ o $ ou $ documentTitle $ documentVersion $ documentAuthor $
    documentLocation $ documentPublisher ) )
    
objectclass ( 0.9.2342.19200300.100.4.9 NAME ’documentSeries’
    SUP top STRUCTURAL
    MUST cn
    MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) )
    
objectclass ( 0.9.2342.19200300.100.4.13 NAME ’domain’
    SUP top STRUCTURAL
    MUST dc
    MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $
    preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
    internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) )
    
objectclass ( 0.9.2342.19200300.100.4.17 NAME ’domainRelatedObject’
    SUP top AUXILIARY
    MUST associatedDomain )
    
objectclass ( 0.9.2342.19200300.100.4.18 NAME ’friendlyCountry’
    SUP country STRUCTURAL
    MUST co )
    
objectclass ( 0.9.2342.19200300.100.4.14 NAME ’rFC822localPart’
    SUP domain STRUCTURAL
    MAY ( cn $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $
    physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
    seeAlso $ sn $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ x121Address ) )
    
objectclass ( 0.9.2342.19200300.100.4.7 NAME ’room’
    SUP top STRUCTURAL
    MUST cn
    MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
    
objectclass ( 0.9.2342.19200300.100.4.19 NAME ’simpleSecurityObject’
    SUP top AUXILIARY
    MUST userPassword )

^
26 septembre 2013

htmlpdflatexmanmd




rfc4525

rfc4525

Extension Modify-Increment

   Définit une extension de l’opération modify pour supporter les capacités d’incrémentation. Cette fonctionnalité est prévue pour être utilisée avec les extensions de contrôle pre-read et post-read (rfc 4527), et peut aussi être utilisée avec l’extension de contrôle d’assertion (rfc4528).

   Les implémentations de cette extension devraient supporter les opérations d’énumération de valeur incrémentale de l’opération ModifyRequest. La valeur de l’opération increment spécifie que des modifications de valeurs d’incrément sont demandés. Toutes les valeurs existantes de l’attribut modification doivent être incrémentés par la valeur listée. L’attribut modification doit être approprié pour la requête, et la modification doit fournir une seul valeur. Si l’attribut n’est pas approprié, une erreur constrainViolation ou autre est retournée. Si plusieurs valeurs sont fournies, protocolError est retourné.

   Les serveurs supportant cette fonctionnalité devraient publier l’OID 1.3.6.1.1.14 dans supportedFeatures dans le rootDSE.

Support LDIF

Pour représenter les requêtes Modify-Increment dans le format LDIF, la production ABNF est étendue comme suit:
mod-spec =/ "increment :" FILL AttributeDescription SEP attrval-spec "-"
SEP

Exemples

Par exemple:
# Increment uidNumber
dn : cn=max-assigned uidNumber,dc=example,dc=com
changetype : modify
increment : uidNumber
uidNumber : 1
^
28 septembre 2013

htmlpdflatexmanmd




rfc4526

rfc4526

Filtres True et False Absolue

   Définis le support des filtres vrai et faux basé sur les capacités similaires aux annuaires X500. Ce document étend également la représentation des chaîne des filtres de recherche LDAP pour supporter ces filtres. Dans les annuaires DAP, un filtre 'and' sans éléments évalue toujours True, et un 'or' sans éléments évalue toujours False. Ces filtres sont communément utilisés pour requêter les DSE qui n'ont pas nécessairement d'attributs objectClass.

   Les implémentations de cette extensions devraient permettre les choix 'and' et 'or' sans éléments de filtre.

- un filtre 'and' constitué d'un jeu vide de filtres devrait s'évaluer à TRUE. le filtre s'écrit "(&)"
- un filtre 'or' constitué d'un jeu vide de filtres devrait s'évaluer à FALSE. Le filtre s'écrit "(|)"

   Les serveurs supportant cette fonctionnalité devraient publier l'OID 1.3.6.1.4.1.4203.1.5.3 dans supportedFeatures.

^
28 septembre 2013

htmlpdflatexmanmd




rfc4527

rfc4527

Contrôles de lecture d'entrée

   Permet à un client de lire l'entrée cible d'une opération de mise à jours. Le client peut demander de lire l'entrée avant et/ou après que les modifications aient été appliquées. Ces lectures sont des parties atomiques de l'opération de mise à jours.

   L'extension utilise les contrôles attachés aux requêtes de mise à jours pour demander des copies en retour. Un contrôle de requête, appelé Pre-Read, indique qu'une copie de l'entrée avant l'application de la modification doit être retournée. Un autre contrôle, appelé Post-Read, indique qu'une copie de l'entrée après l'application de la modification doit être retournée. Chaque contrôle a un contrôle de réponse utilisé pour retourner l'entrée.

Contrôle pre-Read

   les contrôle de requête et de réponse Pre-Read sont identifiés par l'OID: 1.3.6.1.1.13.1. Les serveurs implémentant ce contrôle devrait publier cet OID dans supportedControl. Un contrôle de requête Pre-Read a controlType à 1.3.6.1.1.13.1 et controlValue est un AttributeSelection encodé BER qui indique quels attributs sont retournées dans la copie.

Contrôle pre-Read

   les contrôle de requête et de réponse Post-Read sont identifiés par l'OID: 1.3.6.1.1.13.2. Les serveurs implémentant ce contrôle devrait publier cet OID dans supportedControl. Un contrôle de requête Post-Read a controlType à 1.3.6.1.1.13.2 et controlValue est un AttributeSelection encodé BER qui indique quels attributs sont retournées dans la copie.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4528

rfc4528

Contrôle d'assertion

   Permet à un client de spécifier qu'une opération devrait seulement être traitée si une assertion appliquée à l'entrée cible est vraie. Cela permet de construire des opérations conditionnelles du type "test and set" ou "test and clear". Cela permet de spécifier une condition qui doit être vrai pour que l'opération soit effectuée.

   Pour les opérations Add, Compare et ModifyDN, la cible est indiquée par le champ entry dans la requête. Pour les opérations Modify, la cible est indiquée par le champ Object. Pour les opérations Delete, la cible est indiquée par le type DelRequest. Pour les opérations Compare et toutes les opérations update, l'évaluation de l'assertion doit être effectuée comme partie intégrale de l'opération. Pour les opérations de recherche, la cible est indiquée par le champ baseObject, et l'évaluation est faite après "finding", mais avant "searching".

   Les serveurs implémentant cette fonctionnalité devraient publier l'OID 1.3.6.1.1.12 dans supportedControl.

^
28 septembre 2013

htmlpdflatexmanmd




rfc4529

rfc4529

Requêter les attributs par classe d'objet

   LDAP permet aux clients de demander tous les attributs utilisateurs, tous les attributs opérationnels, et/ou tous les attributs sélectionné par leur description.

   2 descripteurs sont définis pour demander tous les attributs utilisateur "*", et tous les attributs opérationnels "+". Il n'y a cependant aucun mécanisme convenable pour demander un jeu d'attributs prédéfinis tel que le jeu d'attributs utilisé pour représenter une classe d'objet particulière. Le caractère '@' est utilisé pour distinguer un identifiant de classe d'objet des descriptions d'attributs.

Retour de tous les attributs d'une classe d'objet

Cette extension étend la production ‹attributeSelector›:
attributeSelector =/ objectclassdescription
objectclassdescription = ATSIGN oid options
ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)

   Les serveurs supportant cette fonctionnalité devraient publier l'OID 1.3.6.1.4.1.4203.1.5.2 dans supportedFeatures.
^
28 septembre 2013

htmlpdflatexmanmd




rfc4532

rfc4532

Opération Who Am I ?

   Remplace la RFC 3829. Définit un mécanisme pour les clients LDAP pour obtenir l'identité d'autorisation que le serveur a associé avec l'utilisateur. Who Am I ? peut être augmentée avec un Proxy Autorization Control pour déterminer l'identité d'autorisation que le serveur associe avec l'identité asséré dans le contrôle d'autorisation proxifié. Who Am I ? peut également être utilisé avant une opération Bind.

   Les serveurs associent souvent plusieurs identités d'autorisation avec le client, et chaque identité d'autorisation peut être représenté par plusieurs authzId. Cette opération retourne une authzId que le serveur considère comme principal. Dans cette spécification, l'identité d'autorisation et le authzId sont généralement l'identité d'autorisation principal et l'authzId principal, respectivement.

   L'opération étendue Who I Am ? est définie par l'OID 1.3.6.1.4.1.4203.1.11.3. Les serveur implémentant cette fonctionalité devrait le publier dans supportedExtension.

Request whoami

   La requête whoami est une extendedRequest avec requestName contenant 1.3.6.1.4.1.4203.1.11.3 et requestValue est absent.

Response whoami

   La réponse whoami est une ExtendedResponseresponseName est absent et le champ response, si présent, est un authzId.

Contrôle d'autorisation proxifié

   Ce contrôle est utilisé par les clients pour demander que l'opération soit attaché pour opérer sous l'autorisation d'une identité d'emprunt. Le client fournis l'identité d'emprunt dans le contrôle d'autorisation proxifié. Si le client est autorisé à emprunter l'identité demandée, le serveur exécute l'opération comme si l'identité demandée avait fournis l'opération.
^
05 octobre 2014

htmlpdflatexmanmd




rfc4533

rfc4533

LDAP Content Synchronization Operation

   Ce document définit l'opération lDAP Content Synchronization, ou Sync Operation, qui permet à un client de maintenir une copie synchronisée d'un fragment d'un DIT. Sync Operation est définis comme un jeu de contrôles et d'autres élément du protocole qui étendent l'opération de recherche.

   Pendant des années, plusieurs approches de synchronisation de contenu ont été suggérés pour utiliser les services d'annuaire LDAP. Ces approches sont inadéquates pour un ou plusieurs des raisons suivantes:

- Impossibilité de s'assurer d'un niveau de convergence raisonnable
- Impossibilité de détecter que la convergence ne peut pas être achevée (sans rechargement)
- Nécessite que le serveur maintienne un historique des changements passés dans le DIT et/ou les méta-informations
- Nécessite que le serveur maintienne un état de synchronisation sur un base par client; et/ou
- sont trop bavard

   Sync Operation fournis une convergence éventuelle du contenu synchronisé quand cela est possible et, sinon, une notification qu'un rechargement complet est nécessaire. Sync Operation ne nécessite par d'agrément pré-arrangé de synchronisation.

   Sync Operation ne nécessite pas que les serveurs maintiennent ou utilisent un historique des changements passés dans le DIT ou de méta-informations. Cependant, les serveurs peuvent maintenir et utiliser des historiques pour réduire le nombre de messages générés et pour réduire leur taille. Comme il n'est pas toujours faisable de maitenir et d'utiliser des historiques, l'opération peut être implémentée en utilisant un approche purement basé sur l'état. Sync Operation permet d'utiliser soit l'approche state-based, soit l'approche history-based pour balancer l'a taille de l'historique et la quantité du trafic. Sync Operation permet également de combiner l'utilisation de ces 2 approches.

   Sync Operation ne nécessite par que les serveur maintiennent d'état de synchronisation par client, cependant, les serveurs peuvent maitenir et utiliser un tel état d'information pour réduire le nombre de messages générés et la taille de tels messages.

   Un mécanisme de synchronisation peut être considéré trop bavard quand le trafic de synchronisation n'est pas raisonnable. Le trafic de Sync Operation est limité par la taille des mises à jours ou des nouvelles entrées et le nombre d'entrées inchangées dans le contenu. L'opération est conçue pour éviter des échanges complet de contenu, même quand les informations d'historique disponible au serveur est insuffisant pour déterminer l'état du client. L'opération est également conçue pour éviter la transmission d'information d'historique hors contenus, vu que sa taille n'est pas limitée par le contenu et il n'est pas toujours faisable de transmettre de telles informations d'historique dû à des raisons de sécurité.

Utilisation

   Sync Operation est conçu pour être utilisé dans les applications qui nécessitent une synchronisation de contenu éventuellement convergent. Une fois l'étape de chaque synchronisation de l'opération terminée, toutes les informations pour construire une copie client synchronisée a été fournie au client ou le client a été notifié qu'un rechargement complet est nécessaire. Excepté pour les incohérence transitoires dus au traitement simultané du serveur, la copie client est un reflet précis du contenu maintenu par le serveur. Les inconsistances transitoires seront résolues par des opérations de synchronisation ultérieurs.

  Des utilisations possibles incluent:

- Les applications de services page blanche
- Les moteurs de méta-informations
- Les services de proxy
- La réplication maître-esclave entre des serveurs d'annuaire hétérogènes.

   Ce protocole n'est pas conçus pour être utilisé avec des applications nécessitant une consistance de données transactionnelles. Vu que ce protocole transfère toutes les valeurs visibles des entrées appartenant au contenu courant au lieu d'un changement delta, ce protocole n'est pas approprié pour des applications à bande passante limitée ou des déploiements.

Vue d'ensemble

   Cette section fournie une vue d'ensemble sur la manière dont Sync Operation peut être utilisé pour maintenir une copie client synchronisée d'un fragment du DIT.

Polling for Changes (refreshOnly)

   Pour obtenir sa copie cliente initiale, le client envoie un requête Sync: une requête Search avec le contrôle Sync Request et mode à refreshOnly. Le serveur retourne le contenu correspondant au critère de recherche, Additionnellement, avec chaque entrée retournée, le serveur fournis un contrôle d'état de synchronisation indiquant l'état. Ce contrôle contient l'UUID de l'entrée. Le contenu initial est suivi par un SearchResultDone avec un contrôle Sync Done. Le Sync Done Contrôle fournis un syncCookie, qui représente un état de session.

   Pour interroger les mises à jours pour la copie client, le client renouvelle le Sync Operation avec le syncCookie précédemment retourné. Le serveur détermine quel contenu doit être à retourner comme si l'opération était une opération de recherche normale. Cependant, en utilisant le syncCookie, le serveur envoie les copies des entrées qui ont changé avec un Sync State Control indiquant l'état add. Pour chaque entrée changée, tous les attribut ( modifiés ou non ) appartenant au contenu sont envoyés.

   Le serveur peut effectuer une des 2 phases de synchronisations, ou les 2, qui sont distinguées par la manière de synchroniser les entrées supprimées du contenu: Les phases présent et delete. Quand le serveur utilise une seule phase pour l'étape de rafraîchissement, chaque phase est marquée comme terminée par un SearchResultDone avec un Sync Done Control. Une phase present est identifiée par une valeur refreshDeletes à FALSE dans le contrôle Sync Done. Une phase delete est identifiée par une valeur refreshDeletes à TRUE. La phase present peut être suivie par une phase delete. Les 2 phases sont délimitées par un message refreshPresent Sync Info avec la valeur refreshDone à FALSE. Dans le cas où les 2 phases sont utilisée, la phase present est utilisée pour apporte la copie client à jours après laquelle la phase delete peut commencer.

   Dans la phase present, le serveur envoie une entrée vide (ex: pas d'attributs) avec un Sync State Control indiquant l'état présent pour chaque entrée inchangée.

   La phase delete peut être utilisée quand le serveur peut déterminer avec certitude quelles entrées dans la précédente copie cliente ne sont plus présent dans le contenu et le nombre de telles entrées est inférieur ou égal au nombre d'entrées inchangées. Dans le mode delete, le serveur envoie une entrée vide avec un Sync State Control indiquant l'état delete pour chaque entrée qui n'est plus dans le contenu, au lieu de retourner une entrée vide avec l'état present pour chaque entrée présente.

   Le serveur peut envoyer des messages syncIdSet Sync Info Messages contenant le jeu d'UUID des entrées présentes non changées et les entrées supprimées, au lieu d'envoyer plusieurs messages individuels. Il refreshDeletes et syncIdSet sont FALSE, les UUID des entrées présente inchangées sont contenus dans le jeu syncUUID; si refreshDeletes de syncIdSet est à TRUE, l'UUID des entrées supprimées dans le contenu sont dans le jeu syncUUID. Un cookie optionnel peut être inclus dans le syncIdSet pour représenter l'état du contenu après avoir synchronisé la présence ou l'absence des entrées contenus dans le jeu syncUUID.

   La copie synchronisée du fragment du DIT est construit par le client.

   Si refreshDeletes de syncDoneValue est FALSE, la nouvelle copie inclue toutes les entrées changées retournées par le Sync Operation ré-émis, aussi bien que toutes les entrées non changées identifiée comme étant présentes par le Sync Operation ré-émis, mais dont le contenu est fournis par le Sync Operation précédent. Les entrées inchangées non identifiées qui sont présentées sont supprimées du contenu client. Ils ont été soit supprimés, déplacés, ou sortis du scope.

   Si refreshDeletes de syncDoneValue est TRUE, la nouvelle copie inclus toutes les entrées changées retournées par le Sync Operation ré-émis, aussi bien que toutes les autres entrées de la copie précédente excepté pour celles qui ont été identifiées comme ayant été supprimés du contenu.

   Le client peut, plus tard, re-demander les changements pour cette copie cliente synchronisée.

Listening for Changes (refreshAndPersist)

   Le Polling for changes peut être coûteux en terme de serveur, client et ressources réseaux. Le mode refreshAndPersist permet des mises à jours active des entrées changées dans le contenu.

   En sélectionnant le mode RefreshAndPersist, le client demande que le serveur envoie les mises à jours des entrées qui ont été changées après que le refresh initial aie été déterminé. Au lieu d'un SearchResultDone comme dans le polling, le serveur envoie un Sync Info Message au client indiquant que l'étape refresh est complet et qu'il peut ainsi entrer en mode persist. Une fois reçu ce Sync Info Message, le client va construire une copie synchronisée comme décris précédemment.

   Le serveur peut ainsi envoyer des notifications de changement en résultat de la requête de recherche Sync originale, qui maintenant reste persistante dans le serveur. Pour les entrées à ajouter au contenu retourné, le serveur envoie un SearchResultEntry ( avec les attributs ) avec un contrôle Sync State indiquant l'état add. Pour les entrées à supprimer du contenu, le serveur envoie un SearchResultEntry ne contenant aucun attribut et un contrôle Sync State indiquant l'état delete. Pour les entrées à modifier dans le contenu retourné, le serveur envoie un SearchResultEntry ( avec les attributs ) avec un contrôle Sync State indiquant l'état modify. Une fois la modification d'une entrée, tous les attributs (modifiés et non modifiés) appartenant au contenu sont envoyés.

   Noter que renommer une entrée du DIT peut causer en état add où l'entrée est renommée dans le contenu, un état delete où l'entrée est sortie du contenu, et un état modify où l'entrée reste dans le contenu. Noter également qu'une modification d'une entrée du DIT peut causer un état add, delete ou modify dans le contenu.

   Une fois une notification de changement reçue, le client met à jours sa copie du contenu.

   Si le serveur désire mettre à jours de syncCookie durant l'étape persist, il peut inclure le syncCookie et un Sync State Control ou un Sync Info Message retourné.

   L'opération persiste jusqu'à annulation par le client ou terminées par le serveur. Un contrôle Sync Done devrait être attaché au message SearchResultDone pour fournir un nouveau syncCookie.

Élements de Sync Operation

   Sync Operation est définis comme extension de l'opération ldap search où le DUA envoie un message SearchRequest avec un contrôle Sync Request et le DSA répond avec 0 ou plusieurs message SearchResultEntry, chacun avec un contrôle Sync State; 0 ou plusieurs messages intermédiaires Sync Info, et un message SearchResultDone avec un contrôle Sync Done.

   Pour permettre aux clients de découvrir le support pour cette opération, les serveurs implémentant cette opération devaient publier 1.3.6.1.4.1.4203.1.9.1.1 comme valeur dans supportedControl du rootDSE.

SyncUUID

Le type de données syncUUID est un OCTET STRING maintenant un identifiant unique 16-octets
syncUUID ::= OCTET STRING (SIZE(16))

syncCookie

   Le syncCookie est un outil de notation pour indiquer que, bien que le type syncCookie est encodé en OCTET STRING, sa valeur est une valeur opaque contenant des informations sur la session de synchronisation est son état. Généralement, les informations de session incluent un hash des paramètres de l'opération que le serveur impose de ne pas changer et les informations de synchronisation incluent un numéro de séquence d'envoie (log), un numéro de séquence de changement, ou un timestamp. Pour simplifier les descriptions, le term "aucun cookie" réfère soit à un cookie null, soit à un cookie avec un état de synchronisation pré-initialisé


syncCookie ::= OCTET STRING

Sync Request Control

Le contrôle Sync Request est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.1 et controlValue, un OCTET STRING, contient un BER de syncRequestValue:
syncRequestValue ::= SEQUENCE {
    mode ENUMERATED {
        -- 0 unused
        refreshOnly (1),
        -- 2 reserved
        refreshAndPersist (3)
    },
    cookie syncCookie OPTIONAL,
    reloadHint BOOLEAN DEFAULT FALSE
}

Sync State Control

Le contrôle Sync State est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.2 et controlValue, un OCTET STRING, contient un BER de syncStateValue:
syncStateValue ::= SEQUENCE {
    state ENUMERATED {
        present (0),
        add (1),
        modify (2),
        delete (3)
    },
    entryUUID syncUUID,
    cookie syncCookie OPTIONAL
}

   Le contrôle Sync State est seulement applicable aux messages SearchResultEntry et SearchResultReference.

Sync Done Control

Le contrôle Sync Done est un contrôle ldap où controlType est 1.3.6.1.4.1.4203.1.9.1.3 et controlValue, un OCTET STRING, contient un BER de syncDoneValue:
syncDoneValue ::= SEQUENCE {
    cookie syncCookie OPTIONAL,
    refreshDeletes BOOLEAN DEFAULT FALSE
}

   Le contrôle Sync Done est seulement applicable au message SearchResultDone.

Sync Info Message

Le message Sync Info est un message de réponse intermédiaire où responseName est 1.3.6.1.4.1.4203.1.9.1.4 et responseValue contient un BER de syncInfoValue:
syncInfoValue ::= CHOICE {
    newcookie [0] syncCookie,
    refreshDelete [1] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDone BOOLEAN DEFAULT TRUE
    },
    refreshPresent [2] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDone BOOLEAN DEFAULT TRUE
    },
    syncIdSet [3] SEQUENCE {
        cookie syncCookie OPTIONAL,
        refreshDeletes BOOLEAN DEFAULT FALSE,
        syncUUIDs SET OF syncUUID
    }
}

Sync Result Codes

Le resultCode ldap suivant est définis:
e-syncRefreshRequired (4096)

Content Synchronization

   Sync Operation est invoqué quand le client envoie un message SearchRequest avec un contrôle Sync Request.

   L'absence d'un cookie ou d'un état de synchronisation dans un cookie indique une requête pour un contenu initial, alors que la présence d'un cookie représentant un état d'une copie client indique un requête pour une mise à jours du contenu.

   Le mode est soit refreshOnly soit refreshAndPersist. refreshOnly consiste seulement d'une étape refresh, alors que refreshAndPersist consiste d'une étape refresh suivi d'une étape persist.

Synchronization Session

   Une séquence de Sync Operations où le dernier cookie retourné par le serveur pour une opération est fournie par le client dans la prochaine opération est dite appartenant à la même session de synchronisation.

   Le client doit spécifier les même paramètre de contrôle de contenu dans chaque Search Request de la session. Le client devrait également fournir chaque demande Sync d'une session sous la même association authentification et autorisation avec des des protections et intégrité équivalent. Si le serveur ne reconnaît pas le cookie ou si la requête est faite sous des associations différentes ou à des protections non-équivalentes, le serveur devrait retourner le contenu initial comme si aucun cookie n'avait été fournis ou retourner un contenu vide avec le code de résultat e-syncRefreshRequired. La décision entrée le retour du contenu initial et le retour du contenu vide avec le code de résultat e-syncRefreshRequired peut être basé sur le reloadHint dans le contrôle de requête Sync du client. Si le serveur reconnait le cookie comme représentant un état de synchronisation initial ou vide de la copie cliente, le serveur devrait retourner le contenu initial.

   Une session de synchronisation peut s'étendre sur plusieurs sessions entre le client et le serveur. Le client devrait fournir chaque demande Sync d'une session du même serveur.

Détermination du contenu

   Le contenu à fournir est déterminé par les paramètre de la requête search, comme décrit dans la rfc4511, et possiblement d'autres contrôles. Les même paramètres de contenu devraient être utilisés dans chaque requête Sync d'une session. Si un contenu différent est demandé et que le serveur n'est pas en mesure de traiter la requête, le serveur devrait retourner le contenu initial comme si aucun cookie n'avait été retourné ou retourner un contenu vide avec le code e-syncRefreshRequired. La décision entrée les 2 peut être basé sur reloadHint du contrôle Sync Request du client.

   Le contenu peut ne pas nécessairement inclure toutes les entrées ou références qui seraient retournées par une opération de recherche normale, ni, pour les entrées inclues, tous les attributs retournés par une recherche normale. Quand le serveur ne peut pas fournir de synchronisation pour un attribut pour un jeu d'entrées, le serveur doit traiter tous les composants de filtre qui matchent ces attributs comme indéfinis et ne doit pas retourner ces attributs dans les réponses SearchResultEntry.

   Les serveurs devraient supporter la synchronisation pour tous les attributs utilisateurs non-collectifs pour toutes les entrées. Le serveur peut également retourner des références de continuation aux autres serveurs et à lui-même. Ce dernier est permis vu que le serveur peut partitionner les entrées qu'il maintient dans des contextes de synchronisation séparés. Le client peut poursuivre toutes ou certaines continuations, chacune comme une session de synchronisation de contenu séparés.

Mode refreshOnly

   Une requête Sync avec le mode refreshOnly et sans cookie est un sondage pour un contenu initial. Une requête Sync avec le mode refreshOnly et avec un cookie représentant un état de synchronisation est un sondage pour une mise à jours de contenus.

Initial Content Poll

   Une fois reçu la requête, le serveur fournis le contenu initial en utilisant un jeu de 0 ou plusieurs messages SearchResultEntry et SearchResultReference suivs par un message SearchResultDone.

   Chaque message SearchResultEntry devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Chaque message SearchResultReference devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID associé avec là référence ( normalement l'UUID de l'objet référant nommé associé ), et aucun cookie. Le message searchResultDone devrait inclure un contrôle Sync Done avec refreshDeletes à FALSE.

   Une valeur resultCode à success indique que l'opération a été complétée avec succès. Sinon, le resultCode indique la nature de l'échec. Le serveur peut retourner le resultCode e-syncRefreshRequired dans le sondage de contenu initial s'il est sûre de le faire quand il n'est pas en mesure d'effectuer l'opération. reloadHint est mis à FALSE dans le message SearchRequest nécessitant l'initial content poll.

   Si l'opération est un succès, un cookie représentant l'état synchronisé de la copie cliente devrait être retournée pour être utilisé dans d'autres Sync Operations.

Content Update Poll

   Une fois la requête reçue, le serveur fournis la mise à jours du contenu en utilisant un jeu de 0 ou plusieurs messages SearchResultEntry et SearchResultReference suivi par un message SearchResultDone. Le serveur doit:

a) Fournir la séquence des messages nécessaire pour une convergence éventuelle de la copie cliente au contenu de la copie du serveur
b) Traiter la requête comme demande de contenu initial ( ignore le cookie ou l'état de synchronisation )
c) Indiquer que la convergence incrémentale n'est pas possible en retournant e-syncRefreshRequired
d) Retourner un resultCode autre que success ou e-syncRefreshRequired

   Un Sync Operation peut consister d'une simple phase present, une simple phase delete, ou une phase present suivi par une phase delete.

   Dans chaque phase, pour chaque entrée ou référence qui a été ajouté au contenu ou a été changé depuis le Sync Operation précédent indiqué par le cookie, le serveur retourne un message SearchResultEntry ou SearchResultReference, respectivement, chacun avec un contrôle Sync State consistant de l'état add, un entryUUID contenant l'UUID de l'entrée ou de la référence, et aucun cookie. Chaque message SearchResultEntry représente l'état courant d'une entrée changée. Chaque message searchResultReference représente l'état courant d'une référence changée.

   Dans la phase present, pour chaque entrée qui n'a pas été changée depuis le Sync Operation précédent, un SearchResultEntry vide est retourné dont l'objectName reflète le DN courant de l'entrée, dont le champ attributes est vide, et dont le contrôle Sync State consiste de l'état present, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Pour chaque référence qui n'a pas été changé depuis le Sync Operation précedent, un SearchResultReference vide contenant une sequence de LDAPURL vide est retournée avec un contrôle Sync State consistant le l'état present, un entryUUID contenant l'UUID de l'entrée, et aucun cookie. Aucun message n'est envoyé pour les entrées ou références qui ne sont plus dans le contenu.

   De multiples entrées vides avec un contrôle Sync State à l'état present devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDeletes à FALSE. syncUUID contient un jeu d'UUID d'entrées et références inchangées depuis le dernier Sync Operation. syncUUID peut être vide. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Dans la phase delete, pour chaque entrée qui n'est plus dans le contenu, le serveur retourne un SearchResultEntry dont l'objectName reflète un DN passé de l'entrée ou vide, dont le champ attributes est vide, et dont le contrôle Sync State a un état delete, un entryUUID contenant l'UUID de l'entrée supprimée, et aucun cookie. Pour chaque référence qui n'est plus dans le contenu, un SearchResultReference contenant une séquence de LDAPURL vide est retourné avec un contrôle Sync State à l'état delete, un entryUUID contenant l'UUID de la référence supprimée, et aucun cookie.

   De multiples entrées vides avec un contrôle Sync State à l'état delete devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDelete à TRUE. syncUUID contient un jeu d'UUID d'entrées et références supprimées du contenu depuis le dernier Sync Operation. syncUUID peut être vide. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Quand une phase present est suivie par une phase delete, le 2 phases sont délimitées par un message Sync Info contenant syncInfoValue de refreshPresent, qui peut contenir un cookie représentant l'état après avoir complété la phase present. Le refreshPresent contient refreshDone, qui est toujours FALSE dans le mode refreshOnly parce qu'il est suivi par une phase delete.

   Si un Sync Operation consiste en un simple phase, chaque phase et par conséquent le Sync Operation sont marqués comme terminés par un message SearchResultDone avec le contrôle Sync Done, qui devrait contenir un cookie représentant l'état du contenus après avoir complété le Sync Operation. Le contrôle Sync Done contient refreshDeletes, qui est à FALSE pour la phase present et à TRUE pour la phase delete.

   Si un Sync Operation consiste d'une phase present suivie par une phase delete, le Sync Operation est marqué comme terminé à la fin de la phase delete par un message SearchResultDone avec le contrôle Sync Done, qui devrait contenir un cookie représentant l'état du contenu après avoir complété le Sync Operation. Le contrôle Sync Done contient refreshDeletes, qui est à TRUE.

   Le client peut spécifier s'il préfère recevoir un contenu initial en fournissant reloadHint à TRUE ou recevoir un e-syncRefreshRequired en fournissant reloadHint à FALSE ( donc absent ), dans ce cas le serveur détermine s'il est impossible ou inéfficace d'achever la convergence éventuelle en continuant le thread de synchronisation incrémentale courant.

   Une valeur resultCode de success indique que l'opération est complétée avec succès. Un resultCode de e-syncRefreshRequired indique qu'un refresh complet ou partiel est nécessaire. Sinon, le resultCode indique la nature de l'erreur. Un cookie est fournis dans le contrôle Sync Done pour l'utiliser dans les Sync Operations suivantes pour une synchronisation incrémentale.

Mode refreshAndPersist

   Une requête Sync avec le mode refreshAndPersist demande le contenu initial ou la mise à jours courante (durant l'étape refresh) suivie par des notifications de changement (durant l'étape persist).

Étape refresh

   Le contenu refresh est fourni comme décris précédemment, excepté que le refresh du contenu complété avec succès est indiqué en envoyant un message Sync Info de refreshDelete ou refreshPresent avec une valeur refreshDone à TRUE au lieu d'un message SearchResultDone avec un resultCode success. Un cookie devrait être retourné dans le message Sync Info pour représenter l'état du contenu après avoir firi l'état refresh du Sync Operation.

Étape persist

   Des notifications de changement sont fournis durant l'étape persist. Lorsqu'un changement est fait dans le DIT, le serveur notifie le client des changements du contenu. Les mises à jours du DIT peut causer des entrées et références qui sont ajoutées, supprimées ou modifiées dans le contenu.

   Là où des mises à jours du DIT implique qu'une entrée a été ajoutée au contenu, le serveur fournis un message SearchResultEntry qui représente l'entrée telle qu'elle apparaît dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID de l'entrée et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est ajoutée au contenu, le serveur fournis un message SearchResultReference qui représente la référence dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état add, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une entrée a été modifiée dans le contenu, le serveur fournis un message SearchResultEntry qui représente l'entrée telle qu'elle apparaît dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état modify, un entryUUID contenant l'UUID de l'entrée, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est modifiée dans le contenu, le serveur fournis un message SearchResultReference qui représente la référence dans le contenu. Le message devrait inclure un contrôle Sync State avec l'état modify, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une entrée a été supprimée du contenu, le serveur fournis un message SearchResultEntry sans attributs. Le message devrait inclure un contrôle Sync State avec l'état delete, un entryUUID contenant l'UUID de l'entrée, et un cookie optionnel.

   Là où des mises à jours du DIT implique qu'une référence est supprimée du contenu, le serveur fournis un message SearchResultReference avec un LDAPURL vide. Le message devrait inclure un contrôle Sync State avec l'état delete, un entryUUID contenant l'UUID associée avec la référence, et un cookie optionnel.

   plusieurs entrées vides avec un contrôle Sync State delete devraient être fusionnés en un ou plusieurs message Sync Info de valeur syncIdSet avec refreshDeletes à TRUE. syncUUID contient un jeu d'UUID des entrées et références qui ont été supprimés du contenu. Le message Sync Info de syncIdSet peut contenir un cookie pour représenter l'état du contenu après avoir effectué la synchronisation des entrées dans le jeu.

   Avec chacun de ces messages, le serveur peut fournir un nouveau cookie pour être utilisé dans les Sync Operation suivants. Additionnellement, le serveur peut également retourner des messages Sync Info avec un newCookie pour fournir un nouveau cookie. Le client devrait utiliser le dernier cookie qu'il a reçu du serveur pour les Sync Operation suivants.

Paramètres de requête de recherche

   Comme vu plus haut, le client devrait spécifier les même paramètres de contrôle de contenu dans chaque requête de recherche de la session. Tous les champs du message SearchRequest sont considérés comme des paramètres de contrôle de contenu excepté pour sizeLimit et timeLimit.

baseObject

   Comme avec une opération de recherche normale, les étapes refresh et persist ne sont pas isolés des changement du DIT. Il est possible que l'entrée référé par le baseObject soit supprimé, renommé, ou déplacé. Il est également possible que l'objet alias utilisé pour trouver l'entrée référée par le baseObject soit changé de telle sorte que le baseObject réfère à une entrée différente.

   Si le DIT est mis à jours durant le traitement du Sync Operation d'une manière qui cause le baseObject à ne plus référer à une entrée ou dans une manière qui change l'entrée auquel il fait référence, le serveur devrait retourner un resultCode approprié, tel que noSuchObject, aliasProblem, aliasDereferencingProblem, referral, ou e-syncRefreshRequired.

derefAliases

   Cette opération ne supporte pas le déréférencement d'alias durant la recherche. Le client doit spécifier neverDerefAliases ou derefFindingBaseObj pour le paramètre derefAliases du SearchRequest. Le serveur devrait traiter les autres valeurs ( ex: derefInSearching, derefAlways) comme des erreurs de protocole.

sizeLimit

   sizeLimit s'applique seulement aux entrées (sans regarder leur état dans le contrôle Sync State) retourné durant l'opération refreshOnly ou l'étape refresh de l'opération refreshAndPersist.

timeLimit

   pour un Sync Operation, le timeLimit s'applique à toute l'opération. Pour une opération refreshAndPersist, e timeLimit s'applique seulement à l'étape refresh incluant la génération du message Sync Info avec une valeur refreshDone à TRUE.

filtre

   Le client devrait éviter les filtres qui s'appliquent aux valeurs des attributs utilisés par le serveur comme maintenant les meta-informations.

objectName

   Le Sync Operation utilise les valeurs entryUUID fournis dans le contrôle Sync State comme clé primaire aux entrées. Le client doit utiliser ces entryUUID pour corréler les messages de synchronisation.

   Dans certaines circonstances, le DN retourné peut ne pas refléter le DN courant de l'entrée. En particulier, quand l'entrée a été supprimée du contenu, le serveur peut fournir un DN vide si le serveur ne désire pas informer du DN courant de l'entrée( ou, si supprimé du DIT, le dernier DN de l'entrée).

   Noter également que le DN de l'entrée peut être vue comme une méta-information (voir plus bas).

Annuler le Sync Operation

   Les serveurs doivent implémenter l'opération ldap Cancel et supporter l'annulation des opérations de synchronisation. Pour annuler le Sync Operation en cour, le client fournis une opération ldap Cancel.

   Si à un moment le serveur n'est plus en mesure de continuer l'opération, le serveur devrait retourner un SearchResultDone avec un resultCode indiquant la raison de l'arrêt de l'opération

   Que ce soit le client ou le serveur qui initie la fin, le serveur peut fournir un cookie dans le contrôle Sync Done pour l'utiliser dans les Sync Operation suivants.

Refresh Required

   Pour accomplir la synchronisation à convergence éventuelle, le serveur peut terminer le Sync Operation dans les étapes refresh ou persist en retournant un resultCode e-syncRefreshRequired au client. Si aucun cookie n'est fournis, un refresh complet est nécessaire. Si un cookie représentant un état synchronisé est fournis dans cette réponse, un refresh incrémental est nécessaire.

   Le serveur peut choisir de fournir une copie complète dans l'étape refresh (ex: en ignorant le cookie ou l'état de synchronisation représenté dans le cookie) au lieu de fournir un refresh incrémentale pour accomplir la convergence éventuelle.

   La décision entre le retour du contenu initial et le retour du resultCode e-syncRefreshRequired peut être basé sur le reloadHint dans le contrôle Sync Request du client.

   Dans le cas de l'étape persist, le serveur retourne le resultCode e-syncRefreshRequired au client pour indiquer que le client doit ré-émettre un nouveau Sync Operation pour obtenir une copie synchronisée du contenu. Si aucun cookie n'est fournis, un refresh complet est nécessaire. Si un cookie représentant un état synchronisé est fournis, un refresh incrémental est nécessaire.

   Le serveur peut également retourner un e-syncRefreshRequired s'il détermine qu'un refresh serait plus efficace qu'envoyer tous les messages requis pour la convergence.

   Noter que le client peut recevoir un ou plusieurs messages SearchResultEntry, SearchResultReference, et/ou des Sync Info avant qu'il reçoive un message SearchResultDone avec le resultCode e-syncRefreshRequired.

Considérations diverses

   Le serveur doit s'assurer que le nombre de messages générés pour refresh le contenu client n'excède pas le nombre d'entrées présentes dans le contenu. Bien qu'il n'y ait pas de pré-requis pour les serveurs de maintenir des informations d'historique, si le serveur a un historique suffisant pour déterminer avec certitude quelles entrées dans la copie client ne sont plus présentes dans le contenu et que le nombre de telles entrées est inférieur ou égal au nombre d'entrées inchangées, le serveur devrait générer des messages delete au lieu de message d'entrées présentes.

   Quand la quantité d'historique maintenu dans le serveur n'est pas suffisant pour que les clients puissent les refreshOnly peut fréquents, c'est généralement que le serveur a des informations d'historique incomplets.

   Le serveur ne devrait pas recourir à un reload complet quand les informations d'historique ne sont pas suffisants pour générer des message d'entrées supprimées. Le serveur devrait générer soit des messages d'entrée présentes uniquement ou des messages d'entrées présentes suivis par les messages d'entrée supprimées pour ramener la copie client à l'état courant. Dans le dernier cas, les messages d'entrées présentes apporte la copie cliente à un état couvert par les informations d'historique maintenus dans le serveur.

   Le serveur devrait maintenir suffisamment (courant et historique) d'information d'état (tel qu'un horodatage de dernière modification à l'échelle du contexte) pour déterminer si aucun changement n'a été fait dans le contexte depuis que le refresh a été fournis et, quand aucun changement n'a été fait, ne génère aucun message d'entrée supprimée au lieu de messages présents.

   Le serveur ne devrait pas utiliser les informations d'historique quand son utilisation ne réduit pas le trafic de synchronisation ou quand sont utilisation peut exposer des informations sensibles non permises par le client.

   L'implémenteur du serveur devrait également considérer les problèmes de bavardage qui s'étendent sur plusieurs opérations de synchronisation d'une session. Comme noté plus haut, le serveur peut retourner e-syncRefreshRequired s'il détermine qu'un reload sera plus efficace que continuer l'opération courante. Si reloadHint dans le Sync Request est TRUE, le serveur peut initier un reload sans diriger le client pour demander un reload.

   Le serveur devrait transférer un nouveau cookie fréquemment pou éviter d'avoir à transférer des informations déjà fournies au client. Même où les changement du DIT n'impliquent pas de changements dans la synchronisation du contenu à transférer, il peut être avantageux de fournir un nouveau cookie en utilisant un message Sync Info. Cependant, le serveur devrait éviter de surcharger le client ou le réseau avec des messages Sync Info.

   Durant le mode persist, le serveur devrait fusionner les messages de mises à jours de la même entrée. Le serveur peut retarder la génération de la mise à jours d'une entrée en anticipation de changements ultérieurs que cette entrée qui pourraient être fusionnés. La longueur du delai devrait être suffisamment long pour permettre de fusionner les demandes de mises à jours émises mais suffisamment court pour que l'inconsistance transitoire induite par le délai soit corrigé.

   Le serveur devrait utilise le message Sync Info syncIdSet quand il y a plusieurs messages delete ou present pour réduire la quantité de trafic de synchronisation.

   Noter également qu'il peut y avoir plusieurs clients intéressés par le changement particulier, et que ces serveurs qui tentent de tous les desservir en même temps peuvent causer des congestion sur le réseau. Les problèmes de congestion sont intensifiés quand les changements nécessitent un gros transfert pour chaque client intéressé. Les implémenteurs et déployeurs de serveur devraient prendre en compte les étapes pour empêcher et gérer la congestion du réseau.

Multiplexer les opérations

   Le protocole LDAP permet de multiplexer les opérations dans une simple session LDAP. Les clients ne devraient pas maintenir plusieurs sessions LDAP avec le même serveur. Les serveurs devraient s'assurer que les réponses des opérations traité concurrentiellement sont entrelacés de façon équitable.

   Les clients devraient combiner les Sync Operation dont le jeu de résultat est largement chevauché. Les clients ne devraient pas combiner les Sync Operation dont les jeux de résultat sont largement non-chevauchés. Cela s'assure que dans le cas d'une réponse e-syncRefreshRequired peut être limitée à quelques jeux de résultats.

Entry DN

   Le DN de l'entrée est construite depuis son RDN et le DN de son parent, il est dont souvent vu comme une méta-information. renommer ou déplacer à un nouveau supérieur, le DN de l'entrée est changé, ce changement ne devrait pas, par lui-même, causer de message de synchronisation à envoyer pour cette entrée. Cependant, Si le renommage ou le déplacement ajoute ou supprime l'entrée du contenu, les messages de synchronisation appropriés devraient être générés pour l'indiquer au client.

   Quand un serveur traite le DN de l'entrée comme méta-information, le serveur devrait soit:

- Évaluer tous MatchingRuleAssertions à TRUE si matche une valeur d'un attribut de l'entrée, sinon Undefined, ou
- Évaluer tous MatchingRuleAssertions avec dnAttributes à TRUE comme Undefined.

   Le dernier choix est offert pour simplifier l'implémentation de serveurs.

Attributs Opérationnels

   Lorsque les valeurs d'un attribut opérationnel sont déterminés par les valeurs non maintenues dans l'entrée, l'attribut opérationnel ne devrait pas supporter la synchronisation de cet attribut.

   Les serveurs devraient supporter la synchronisation des attributs opérationnels suivants: createTimestamp, modifyTimestamp, creatorsName, modifiersName. Les serveurs peuvent supporter la synchronisation d'autres attributs opérationnels.

Attributs collectifs

   La modification d'un attribut collectif affecte généralement le contenu de plusieurs entrées, qui sont les membres de la collection. Il n'est pas efficace d'inclure les valeurs des attributs collectifs visible dans les entrées de la collection, vu que la modification d'un simple attribut collectif nécessite la transmission de plusieurs SearchResultEntry ( un pour chaque entrées dans la collection que la modification affecte )

   Les serveurs ne devraient pas synchroniser les attributs collectifs apparaissant dans les entrées d'une collection. Les serveur peuvent supporter la synchronisation des attributs collectifs apparaissant dans les attributs collectif des subentries.

Accès et autres contrôle administratifs

   Les entrées sont communément sujets à accès et autres contrôles administratifs. Bien que des portions d'information de stratégie gouvernant une entrée particulière peuvent être maintenus dans l'entrée, les informations de stratégies sont souvent maintenus ailleurs. À cause de cela, les changement d'information de stratégie rendent plus difficile la vérification de convergence éventuel durant la synchronisation incrémentale.

   Lorsqu'il n'est pas possible ou infaisable de générer des changement de contenu résultant d'un changement d'information de stratégie, les serveurs peuvent opter pour retourner e-syncRefreshRequired ou pour traiter le Sync Operation comme requête de contenu initial.

Intéraction avec d'autres contrôles

   Le Sync Operation peut être utilisé avec:

- ManageDsaIT
- Subentries Control

ManagesDsaIT

   Le Contrôle ManageDsaIT indique que l'opération agit sur le DIT et force les objets spéciaux à être traités comme des entrées.

Subentries Control

   Le contrôle Subentries est utilisé avec l'opération de recherche pour contrôler la visibilité des entrées et des subentries qui sont dans le scope. Quand utilisé avec le Sync Operation, le contrôle subentries et d'autres facteurs sont utilisés pour déterminer si une entrée ou un subentry apparait dans le contenu.

Shadowing

   Certains serveurs peuvent maintenir des copies shadow des entrées qui peuvent être utilisée pour répondre à des requêtes search et compare. De tels serveurs peuvent également supporter les requêtes de synchronisation de contenu.

Shadowing

   Bien qu'un client peut connaître plusieurs serveurs qui sont capables d'être utilisé pour obtenir un contenu d'annuaire particulier, un client ne devrait pas assumer qui chacun de ces serveurs est capable de continuer une session de synchronisation de contenu. Le client devrait fournir chaque requête Sync d'une session Sync au même serveur.

   Cependant, via le nom de domaine ou les redirections d'adresse IP ou d'autres techniques, plusieurs serveurs physiques peuvent être fait pour apparaître comme un serveur logique à un client. Seuls les serveurs qui sont également capable en ce qui concerne leur support de Sync Operation et qui maintienne également des copies complètes des entrées devraient être faits pour apparaître comme un serveur logique. En particulier, chaque serveur physique agissant comme un serveur logique devrait être également capable de continuer une synchronisation de contenu basé sur des cookies fournis par un autre serveur physique sans nécessiter un full reload. Parce qu'il n'y pas de mécanisme de shadowing ldap standard, la spécification de la manière d'implémenter cette capacité est laissé à de futures documents.

   Noter qu'il peut être difficile pour le serveur de déterminer avec certitude quel contenu a été fournis au client par un autre serveur, spécifiquement dans les environnement Shadowing qui permet aux évènements shadowing d'être fusionnés. Pour ces serveurs, l'utilisation de la phase delete peut ne pas être applicable.

Considérations de sécurité

   Pour maintenir une copie synchronisée du contenu, un client doit supprimer les informations de sa copie du contenu comme décris plus haut. Cependant, le client peut maintenir les connaissances des informations qui lui sont communiquées par le serveur séparé de sa copie du contenu utilisé pour la synchronisation. La gestion de ces connaissances est hors du scope de ce document. Les serveurs devraient faire attention à ne pas communiquer les informations du contenu que le client n'a pasle droit de connaître.

   Bien que les informations fournies par une série de Sync Operation refreshOnly est similaire à celles fournies par une série d'opération de recherche, l'étape persist peur communiquer des informations additionnelles. Un client peut être capable de discerner les informations sur la séquence d'opérations de mises à jours particulière qui à causé le changement de contenu.

   Les implémenteurs devraient prendre des précautions contre le contenu de cookie malicieux, incluant les cookies malformés ou les cookies valides utilisé avec différentes protections et/ou associations de sécurité pour tenter d'obtenir un accès non autorisé aux informations. Les serveurs peuvent inclure une signature numérique dans le cookie pour détecter la falsification.

   L'opération peut être la cible d'attaque DOS direct. Les implémenteurs devraient fournir des protections contre ça. Les serveurs peuvent placer le contrôle d'accès ou d'autres restrictions contre l'utilisation de cette opération.

   Noter que même les petites mises à jours peuvent causer une quantité significative de trafic. Un utilisateur pourrait abuser de ses privilèges de mise à jours pour monter un DOS indirecte.

Considérations d'implémentation basé sur CSN

   Cet appendix discute de l'implémentation de l'opération ldap de synchronisation de contenu associé avec l'approche basé sur le numéro de séquence de changement.

   Cet approche est ciblée pour l'utilisation dans des serveurs qui ne maintiennent pas d'information d'historique sur les changements faits dans le DIT et ainsi doit s'assurer de l'état de l'annuaire courant et un état de synchronisation minimal embraqué dans le Sync Cookie. Les serveurs qui implémentent des informations d'historique devraient considérer d'autres approches qui exploitent ces informations d'historique.

   Un CSN est effectivement un timestamp qui a la granularité suffisante pour s'assurer que la relation de précedence dans le temps de 2 mises à jours sur le même objet peut être déterminer. Les CSN ne doivent pas être confondus avec les Commit Sequence Number ou Commit Log Record Number. Un Commit Sequence Number permet de déterminer comment 2 envoies (sur le même objet ou différents) sont liés l'un à l'autre dans le temps. Un Change Sequence Number associé avec des entrées différentes pour être envoyés dans le désordre. Dans le reste de cet appendix, le terme CSN réfère toujours au Change Sequence Number.

   Dans ces approches, le serveur ne maintient pas seulement un CSN pour chaque entrée de l'annuaire mais maintient également une valeur qui l'on appel le context CSN. Ce context CSN est le plus grand entry CSN envoyé qui n'est pas supérieur à une entry CSN exceptionnelle (non validée) pour toutes les entrées dans le contexte de l'annuaire. Les valeurs du context CSN sont utilisée dans les valeurs syncCookie comme indicateurs d'état de synchronisation.

   Vu que les opérations de recherche ne sont pas isolées des mises à jours d'annuaire individuels et les opérations de mises à jours individuels ne peuvent pas assumer être sérialisés, on ne peut pas assumer que le contenu retourné incorpore chaque changement dont le CSN est inférieur ou égal au plus grand entryCSN dans le contenu. Le contenu incorpore tous les changements dont les CSN sont inférieurs ou égal au contextCSN avec de traiter la recherche. Le contenu peut également incorporer un sous-jeu de changements dont le CSN est supérieur au contextCSN avant chaque traitement de recherche mais inférieur ou égal au contextCSN après le traitement de la recherche. Le contenu n'incorpore pas les changements dont le CSN est supérieur au contextCSN après le traitement de la recherche.

   Une implémentation de serveur simple pourrait utiliser la valeur du contextCSN avec de traiter la recherche pour indiquer l'état. Une telle implémentation embarquerai cet valeur dans chaque syncCookie retourné. On appel çà le cookie CSN. Quant un refresh est demandé, le serveur va simplement générer des messages de mises à jours pour tous les entrées dans le contenu dont le CSN est supérieur au cookieCSN fournis et générer des messages present pour toutes les autres entrées dans le contenu. Cependant, si le contextCSN courant est le même que le cookieCSN, le serveur devrait générer 0 updates et 0 delete et indiquer un refreshDeletes à TRUE, vu que l'annuaire n'a pas changé.

   L'implémentation devrait également considérer l'impact des changements des méta-informations, tel que les contrôles d'accès, qui affecte la détermination du contenu. Un approche est pour le serveur de maitenir un CSN meta. Ce metaCSN serait mis à jours quand une méta-information affectant la détermination du contenu a été changée. Si la valeur du metaCSN est supérieur au cookieCSN, le serveur devrait ignorer le cookie et traiter la demande comme requête initial pour le contenu.

   Additionnellement, les serveurs peuvent vouloir maintenir des information d'historique par session pour réduire le nombre de messages nécessaires à transférer durant les refresh incrémentales. Spécifiquement, un serveur pourrait enregistrer les informations sur les entrées qui ont quitté le scope d'une session sync déconnectée et l'utiliser ultérieurement pour générer des informations delete au lieu de messages present.

   Quand les informations d'historique sont tronqués, le CSN de la dernière information d'historique tronquée peut être enregistrée comme CSN tronquée de l'information d'historique. Le CSN tronqué peut être utilisé pour déterminer si la copie client peut être couvert par les informations d'historique en les comparant à l'état de synchronisation contenu dans le cookie fournis par le client.

   quand il y a un grand nombre de sessions, il peut être censé de maintenir un tel historique seulement pour le clients sélectionnés. De même, les serveurs utilisant cette approche nécessitent de considérer les problèmes de consommation de ressource pour s'assurer de performance raisonnable et éviter les abus. Il peut être approprié de restreindre ce mode d'opération par stratégie.
^
21 juillet 2014

htmlpdflatexmanmd




rfc4556

rfc4556

PKINIT

   Ce document décrit des extensions au protocole Kerberos. Ces extensions fournissent une méthode pour intégrer le clé de chiffrement publique dans l'échange d'authentification initiale, en utilisant les clé asymétrique pour les algorithmes de chiffrement et/ou de signature dans les champs de donnée de pré-authentification.

   La pierre angulaire de Kerberos 5 sont le ticket et l'authenticator. Un ticket encapsule une clé symétrique ( la clé de session ) dans un enveloppe ( un message publique ) à destination d'un service spécifique. Le contenu de ce ticket est chiffré avec une clé secrète partagée entre le principale de service et le KDC. La partie chiffrée du ticket contient le nom du principal du client, et d'autre éléments. Un authenticator est un enregistrement qui est généré en utilisant la clé de session du ticket associé. La clé de session est connue du client qui demande le ticket. Le contenu de l'authenticator est chiffré avec cette clé de session et contient un timestamp et le nom du principal du client.

   Le protocole Kerberos 5 consiste des échanges de messages suivant, entre le client et le KDC, et le client et les services d'application:

- L'échange d'AS, où le client obtient un ticket initial, les TGT.
- L'échange TGT, où le client utilise sont TGT pour s'authentifier et demander des tickets de service.
- L'échange AP, où le client faite des demandes avec des messages consistant d'un ticket de service et d'un authenticator qui certifie que le client possède la clé de session du ticket. Le serveur peut optionnellement y répondre. Ces échange négocient généralement des clé de session symétriques.

Généralement, l'AS et le TGS sont intégrés dans un seul périphérique, appelé le KDC.
___________________+- - - - - - - +
________+- - - - -›|__KDC_________|
AS-REQ_/___+- - - -|______________|
______/___/________+- - - - - - - +
_____/___/__________^___________|
____/____|AS-REP___/____________|
___|_____|________/_TGS-REQ_____+_TGS-REP
___|_____|_______/_____________/
___|_____|______/_____________/
___|_____|_____/___+- - - - -+
___|_____|____/___/
___|_____|___/___/
___|_____|__/___/
___|_____v_/___v
__++- - -+- - - - +_____________+- - - - - - - - -+
__|__Client_______+- - - - - - ›|__Application____|
__|_______________|____AP-REQ___|__Server_________|
__|_______________|‹- - - - - - |_________________|
__+- - - - - - - -+____AP-REP___+- - - - - - - - -+

   Dans l'échange AS, la réponse du KDC contient la clé de session du ticket, avec d'autres éléments, qui est chiffré en utilisant une clé partagée entre le client et le KDC. La clé de réponse AS est généralement dérivée du mot de passe du client. Cependant, pour les personnes physiques, la force du protocole Kerberos est sujette à la force du mot de passe.

   L'utilisation d'une clé asymétrique sous la forme d'un certificat X.509 permet de faciliter l'authentification de l'origine des données et la préservation du secret. Un PKI fournis une gestion et des mécanismes de distribution des clés qui peuvent être utilisé pour établir une authentification et une communication sûre.

   L'avantage du TGT Kerberos est que le client expose sa clé à long-terme secrète seulement une fois. Le TGT est ses clé de session associés peuvent être utilisées pour d'autres demandes de ticket. Cela permet à toutes les autres authentification d'être indépendant de la méthode d'authentification initiale. En plus, l'utilisation de clé symétrique après l'authentification initial est préférable pour des raisons de performance.

Extensions

   Cette section décris les extensions pour supporter le chiffrement à clé publique dans la requête initiale pour un ticket. Brièvement, cet document définis les extensions suivantes:

- Le client indique l'utilisation d'une authentification à clé publique en incluant un pré-authentifiant spécial dans la demande initiale. Ce pré-authentifiant contient la clé publique du client et une signature.
- Le KDC teste la demande du client avec sa stratégie d'authentification et les autorités de certification de confiance.
- Si le demande passe les tests de vérification, le KDC répond normalement, mais la réponse est chiffrée en utilisant soit:

        - Un clé générée avec l'échange DH avec le client, signé avec la clé de signature du KDC; ou
        - Un clé de chiffrement symétrique, signée avec la clé de signature du KDC est chiffrée en utilisant la clé publique du client.

- Le client valide la signature du KDC, obtient la clé de chiffrement, déchiffre la réponse, et traite la suite normalement.

Algorithmes requis

   Toutes les implémentations PKINIT doivent supporter les algorithmes suivant:

- l'enctype de la réponse AS: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
- L'algorithme de signature: sha-1WithRSAEncryption
- La méthode de livraison de la clé de la réponse AS: La méthode DH.

   En plus, les implémentations de cette spécification doivent être capable de traiter l'extension EKU et le id-pkinit-san otherName de l'extention SAN dans les certificat X.509.

Algorithmes recommandés

   Toutes les implémentations PKINIT devraient supporter les algorithmes suivant:

- La méthode de livraison de la clé de la réponse AS: voir la section Utiliser le chiffrement à clé publique

   Pour les implémentations qui supporte le chiffrement à clé publique pour les méthodes de livraison de clé, Les algorithmes suivant doivent être supportés:

- Les algorithmes de transport de clé identifiés dans le champ keyEncryptionAlgorithm du type KeyTransRecipientInfo pour le chiffrement de clé temporaire dans le champ encryptedKey avec un clé publique: rsaEncryption.
- Les algorithmes de chiffrement de contenu identifiés dans le champ contentEncryptionAlgorithm du type EncryptedContentInfo pour le chiffrement de la clé de réponse AS avec la clé temporaire contenue dans le champ encryptedKey du type KeyTransRecipientInfo: des-ede3-cbc

Messages définis et types de chiffrement

PKINIT utilise les types de pré-auhentification suivants:
PA_PK_AS_REQ 16
PA_PK_AS_REP 17
PKINIT utilisé les types de données d'autorisation suivants:
AD_INITIAL_VERIFIED_CAS 9
PKINIT introduit les nouveaux codes d'erreurs suivants:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
PKINIT utilise les type de données suivant pour les erreurs:
TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109

Type de chiffrement Kerberos pour CMS Algorithm Identifiers

   PKINIT définis les numéros de type de chiffrement Kerberos, qui peut être utilisé dans le champ etype du message AS-REQ pour indiquer au KDC l'acceptation du client les algorithmes correspondant ( incluant les algorithmes de transport de clé algorithmes de chiffrement de contenu, et algorithmes de signature ). Les type de chiffrement dans le champ etype sont dans l'ordre décroissant de préférence du client. La présent de chacun de ces types de chiffrement dans le champ etype est équivalent à la présence du l'OID l'algorithme correspondant la le champ supportedCMSTypes, et l'ordre de préférence dans le champ supportedCMSTypes a précédence sur l'ordre de préférence dans le champ etype.


Kerberos Encryption Type Name____Num____Corresponding Algorithm OID
=============================____===____===============================
id-dsa-with-sha1-CmsOID__________ 9_____id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID______10_____md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID____11_____sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID___________________12_____rc2-cbc [RFC3370]
rsaEncryption-EnvOID_____________13_____rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID_____________14_____id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID______________15_____des-ede3-cbc [RFC3370]

   Les numéros de type de chiffrement ci-dessus sont seulement utilisé pour indiquer le support des algorithmes correspondant dans PKINIT; ils ne correspondant pas aux types de chiffrement Kerberos actuels et ne doivent pas être utilisé dans le champ etype. L'assignation des numéros de type de chiffrement Kerberos pour indiquer le support pour les algorithmes CMS est déprécié, et les nouveaux numéros ne devraient pas être assignés dans ce but. À la place, le champ supportedCMSTypes devrait être utilisé pour identifier les algorithmes supportés par le client et l'ordre de préférence du client.

   Pour une intéropérabilité maximiale, cependant, les clients PKINIT désirant indiquer au KDC le support pour un ou plusieur algorithmes listés ci-dessus devraient inclure les numéros dans le champ etype de l'AS-REQ.

Syntaxe et utilisation de la pré-authentification PKINIT

   Cette section définie la syntaxe et l'utilisation des champs de pré-authentification utilisés par PKINIT.

Génération d'une demande client

   La demande d'authentification initilale ( AS-REQ ) est envoyée avec un élément de pré-authentification, dont le padata-type est PA PK_AS_REQ et dont padata-value contient le DER du type PA-PK-AS-REQ.


PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack    [0] IMPLICIT OCTET STRING
    trustedCertifiers [1] SEQUENCE OF ExternalPrincipalIdentifier OPTIONAL
    kdcPkId [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
    subjectName [0] IMPLICIT OCTET STRING OPTIONAL
    issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL
    subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
AuthPack ::= SEQUENCE {
    pkAuthenticator [0] PKAuthenticator,
    clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
    supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL
    clientDHNonce [3] DHNonce OPTIONAL
    ...
}
PKAuthenticator ::= SEQUENCE {
    cusec [0] INTEGER (0..999999)
    ctime [1] KerberosTime
    nonce [2] INTEGER (0..4294967295)
    paChecksum [3] OCTET STRING OPTIONAL
    ...
}

signedAuthPack Contient un CMS type ContentInfo. Le champ contentType est id-signedData (1.2.840.113549.1.7.2), et le champ tontent est un SignedData. le Champ eContentType pour le type SignedData est id-pkinit-authData (1.3.6.1.5.2.3.1), et le champ eContent contient le DER du type AuthPack
trustedCertifiers Liste de CA, trusté par le client qui peuvent être utilisés pour certifier le KDC.
kdcPkId Contient un CMS type SignerIdentifier. Identifie, si présent, une clé publique d'un KDC particulier que le client a déjà.
subjectName Conient un nom de type PKIX. Identifie le sujet du certificat par le nom distinct du sujet.
issuerAndSerialNumber Contient un type CMS IssuerAndSerialNumber. Identifie un certificat du sujet.
subjectKeyIdentifier Identifie la clé publique du sujet par une ID de clé.
clientPublicValue Spécifie les paramètres de domaine DH et la valeur de clé publique du client.
supportedCMSTypes Liste d'algorithmes CMS qui identifie les algorithmes de transport de clé ou de signature supportés par le client, par ordre de préférence.
clientDHNonce Présent seulement si le client indique qu'il souhaite ré-utiliser les clés DH ou autoriser le KDC à le faire.
paChecksum Contient le checksum SHA1.

eContentType ce champ pour le type SignedData est id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }
eContent Ce champ pour le type SignedData contient le DER du type AuthPack
signerInfos Ce champ pour le type SignedData contient un simple signerInfo, qui contient la signature du type AuthPack.
AuthPack Cette structure contient un PKAuthenticator, les informations de clé publique client, les type de chiffrement CMS supportés et un DHNonce.

        pkAuthenticator certifie au KDC que le client a une connaissance récente de la clé de signature qui authentifie le client.
        clientPublicValue spécifie les paramètre de domaine DH et la valeur de clé publique du client. La valeur de clé publique SH est encodée en BIT STRING.
        clientPublicValue est présent seulement si le client désire utilisé DH.
        supportedCMSTypes spécifie la liste des ID d'algorithmes CMS qui sont supportés par le client et peut être utilisé pour identifier un algorithme de signature ou un algorithme de transport de clé dans le champ keyEncryptionAlgorithm de type KeyTransRecipientInfo, ou un algorithme de chiffrement de contenu dans le champ contentEncryptionAlgorithm de type EncryptedContentInfo.
        clientDHNonce est décrit plus bas

ctime dans la structure PKAuthenticator contient l'heure courante dans l'hôte du client, et le champ cusec est la partie micro-secondes. Ils sont utilisé ensemble pour spécifier un timestamp suffisamment précis. le champ nonce est choisi au hasard. le champ paChechsum doit être présent et contient un checksum SHA1. Pour faciliter les migrations futures de l'utilisation de SHA1, le champ paChecksum est optionnel: quand la demande est étendue à la négociation d'algorithmes de hash, le nouveau client qui souhaite ne pas utiliser SHA1 va envoyer la demande sans ce champ. Le KDC ce conformant à cette spécification doivent retourner KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Cela permet à un nouveau client de retenter avec SHA1 si permis par la stratégie locale.
certificates de type SignedData, contient les certificats utilisés pour la construction du chemin de certification, pour que le KDC puisse vérifier la signature sur le type AuthPack. Cet certificats devraient être suffisants pour construire au moins chemin de certification depuis le certificat client. Le client doit être capable d'inclure un tel jeu de certificats s'il est configuré pour le faire. Le champ certificates ne doit pas contenir de certificat CA root.
clientPublicValue La valeur public Diffie-Hellman est inclues si le client veut utiliser la méthode DH. Les paramètres de domaine DH pour la clé public du client sont spécifiés dans le champ algorithm du type SubjectPublicKeyInfo, et la valeur de clé publique DH du client est mapppé à un ubjectPublicKey. En utilisant la méthode d'agrément de clé DH, les implémentations doivent supporter Oakley 1024-bits Modular Exponential (MODP) group 2 et OakleOakley 2048-bits Modular Exponential (MODP) group 14 et devraient supporter OakleOakley 4096-bits Modular Exponential (MODP) group 16.

   La structure ExternalPrincipalIdentifier est utilisée dans ce document pour identifier la clé publique du sujet. Cette structure est construite comme suit:

subjectName Contient un nom de type PKIX encodé en accord avec la rfc3280. Ce champ identifie le sujet du certificat par un nom de sujet distinct. Ce champ est requis quand il y a un distinguished subject name présent dans le certificat utilisé.
issuerAndSerialNumber Contient un type CMS encodé. Ce champ identifie un certificat du sujet. Il est requis pour TD-INVALID-CERTIFICATES et TD-TRUSTED-CERTIFIERS
subjectKeyIdentifier Identifie la clé publique du sujet par une key identifier. Quand un certificat X.509 est référencé, cette Key Identifier matche la valeur d'extention subjectKeyIdentifier. Quand d'autres fomats de certificat sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclurent les détails du match de key identifier au champ de certificat approprié.

   Le champ trustedCertifiers du type PA-PK-AS-REQ contient une liste de CA, trustés par le client, qui peut être utilisé pour certifier le KDC. Chaque ExternalPrincipalIdentifier identifie une CA ou un certificat CA. Le champ kdcPkId du type PA-PK-AS-REQ contient un type CMS SignerIdentifier encodé. Ce champ identifie, si présent, une clé publique d'un KDC particulier que le client possède.

Réception de la demande client

   Une fois reçu la demande du client, le KDC la valide. Le KDC vérifie la signature du client dans le champ signedAuthPack. Si, pendant la validation du certificat du client, le KDC ne peut pas construire un chemin de validation, il retourne un KRB-ERROR avec le code KDC_ERR_CANT_VERIFY_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_TRUSTED_CERTIFIERS, et contient le DER du type TD-TRUSTED-CERTIFIERS:


TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Identifies une liste de CA trustés par le KDC.
    -- Chaque ExternalPrincipalIdentifier identifies une CA
    -- ou un certificat CA

   Une fois ce message d'erreur reçu, le client devrait retenter seulement s'il a un jeu de certificats différent qui forment un chemin de certification acceptable pour le KDC.

   Si, pendant le traitement du chemin de certification, de KDC détermine qu'une signature dans le champ signedAuthPack est invalide, il retourne KRB-ERROR avec le code KDC_ERR_INVALID_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_INVALID_CERTIFICATES, et contient le DER du type TD-INVALID-CERTIFICATES:

TD-INVALID-CERTIFICATES ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Chaque ExternalPrincipalIdentifier identifie un
    -- Certificat (envoyé par le client) avec une signature invalide

   Si plus d'une signature est invalide, le KDC peut inclure un IssuerAndSerialNumber par signature invalide dans le TD-INVALID-CERTIFICATES. Le certificat X.509 du client est validé en accord avec la rfc3280.

   En fonction de la stratégie locale, le KDC peut également vérifier si un certificat X.509 dans le chemin de certification a été révoqué. Si c'est le cas, le KDC doit retourner un message d'erreur avec le code KDC_ERR_REVOKED_CERTIFICATE. Si le KDC tente de déterminer le statut de révocation mais n'est pas en mesure de le faire, il devrait retourner un message d'erreur avec le code KDC_ERR_REVOCATION_STATUS_UNKNOWN. Le ou les certificats affectés sont identifiés comme pour le code d'erreur KDC_ERR_INVALID_CERTIFICATE.

   Noter que les données d'erreur TD_INVALID_CERTIFICATES est uniquement utilisé pour identifier les certificats invalides envoyés par le client dans le demande.

   La clé publique du client est ainsi utilisée pour vérifier la signature. Si la vérification de la signature échoue, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INVALID_SIG. Il n'y a pas de e-data pour ce message d'erreur.

   En plus de la validation de la signature du client, le KDC doit également vérifier que la clé publique du client utilisée pour vérifier la signature est liée au principal du client comme suit:

1. Si le KDC a sa propre liaison entre la clé publique du client ou le certificat du client et le nom du principal du client, il utilise cette liaison.
2. Sinon, si le certificat X.509 du client contient un SAN avec un KRB5PrincipalName dans le champ otherName de type GeneralName, il lie le certificat du client à ce nom.

Le type de champ otherName est AnotherName. Le champ type-id du type AnotherName est id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    x509SanAN (2) }

Et le champ valeur du type AnotherName est un KRB5PrincipalName:
KRB5PrincipalName ::= SEQUENCE {
    realm [0] Realm,
    principalName [1] PrincipalName
    }

   Si le nom du client dans le AS-REQ ne matche pas un nom lié par le KDC, ou s'il n'y a aucune liaison trouvée par le KDC, le KDC doit retourner un message d'erreur avec le code KDC_ERR_CLIENT_NAME_MISMATCH. Il n'y a pas de e-data pour ce type d'erreur.

   Même si le chemin de certification est validée et que le certificat est mappé au nom principal du client, le KDC peut décider de ne pas accepter le certificat du client, en fonction de la stratégie locale.

Le KDC peut imposer la présence du EKU KeyPurposeId id-pkinit-KDClientAuth dans le champ extensions du certificat du client:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    pkinit(3) keyPurposeClientAuth(4) }
    -- PKINIT client authentication.
    -- Key usage bits that MUST be consistent:
    -- digitalSignature.

   Le bit d'utilisation de clé digitalSignature doit être présent quand le but du certificat du client est restreins avec le id-pkinit-KDClientAuth.

   Si ce EKU KeyPusposeId est requis mais n'est pas présent, ou si le certificat du client est restreins à ne pas l'utiliser pour PKINIT, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INCONSISTENT_KEY_PURPOSE. Il n'y a pas de e-data pour cette erreur. Les KDC implémentant ce requis devraient également accepter le EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2), vu que de nombreux certificats déployés pour PKINIT ont ce EKU.

   En conséquence de la stratégie locale, le KDC peut décider de rejeter les demandes sur la base de l'absence ou la présence d'autres EKU spécifiques.

   Si l'algorithme digest utilisé pour générer la signature CA pour la clé publique dans un certificat de la demande n'est pas acceptable, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. Le e-data doit être un TYPED-DATA encodé, bien que rien n'est définis.

   Si la clé publique du client n'est pas acceptée pour des raisons autre que ceux spécifiés, le KDC retourne un message KRB-ERROR avec le code KDC_ERR_CLIENT_NOT_TRUSTED. Il n'y a pas de e-data dans ce message.

   Le KDC doit vérifier le timestamp pour s'assurer que la demande n'est pas rejouée, et que la plage de temps est dans la limite acceptable. Si la vérification échoue, le KDC doit retourner un code d'erreur KRB_AP_ERR_REPEAT ou KRB_AP_ERR_SKEW, respectivement.

   Si clientPublicValue est remplis, indiquant que le client désire utiliser la méthode d'agrément de clé DH, le KDC devrait vérifier si les paramètres satisfont sa stratégie. Si ce n'est pas le cas, il doit retourner un message d'erreur avec le code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont le data-type est TD-DH--PARAMETERS:


TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
    -- Chaque AlgorithmIdentifier spécifie un jeu de
    -- paramètres de domaine Diifie-Hellman. Cette liste
    -- est dans l'ordre de préférence décroissante.

   La structure AlgorithmIdentifier est définie dans la rfc3280 et est renseigné en accord avec la rfc3279. Si le client inclus un champ kdcPkId dans le PA-PK-AS-REQ et que le KDC ne possède pas la clé correspondante, le KDC doit ignorer le kdcPkId comme si le client ne l'avait pas inclus.

   Si l'algorithme digest utilisé par le id-pkinit-authData n'est pas acceptable par le KDC, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. Le e-data qui l'accompagne doit être encodé en TYPED-DATA, bien que rien n'est définis.

Génération de la réponse KDC

   Si le paChechsum dans la demande n'est pas présente, le KDC se conformant a cette spécification doivent retourner un KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Le e-data qui l'accompagne doit être encodé dans un TYPED-DATA.

   En assumant que la demande du client a été validée, le KDC procède comme dans la rfc4120, excepté ce qui suit.

Le KDC doit mettre le flag initial et inclure un élément de donnée d'autorisation de ad-type AD_INITIAL_VERIFIED_CAS dans le ticket fournis. Le champ ad-data contient le DER du type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF ExternalPrincipalIdentifier
    -- Identifie le chemin de certification avec lequel le certificat
    -- client a été validé. Chaque ExternalPrincipalIdentifier
    -- identifie une CA ou un certificat CA

   Noter que la syntaxe pour les données d'autorisation AD-INITIAL-VERIFIED-CAS ne permet pas d'encoder des SEQUENCES vides. De tels séquences vides peuvent uniquement être utilisée si le KDC garantis lui-même le certificat du client.

   l'AS enveloppe toute donnée AD-INITIAL-VERIFIED-CAS dans des conteneur AD-IF-RELEVANT si la liste des CA satisfait la stratégie locale de l'AS. De plus, tout TGS doit copier de telles données d'autorisation depuis les tickets utilisé dans un PA-TGS-REQ du TGS-REQ dans le ticket résultant. Si la liste des CA satisfait la stratégie de domaine du KDC, le TGS peut envelopper les données dans le AD-IF-RELEVANT; sinon, il peut sortir les données d'autorisation du conteneur AD-IF-RELEVANT.

   Les serveurs d'application qui comprennent ce type de données d'autorisation devraient appliquer la stratégie locale pour déterminer si un ticket donné comportant un tel type non contenu dans un conteneur AD-IF-RELEVANT est acceptable. ( Cela correspond au serveur AP qui vérifie le champ transited quand le flag TRANSITED-POLICY-CHECKED n'est pas mis). Si un tel type de donnée est contenu dans un conteneur AD-IF-RELEVANT, les serveurs AP peuvent appliquer la stratégie locale pour déterminer si les données d'autorisation sont acceptables.

Un élément de donnée de pré-authentification, dont padata-type est PA_PK_AS_REP et dont padata-value contient le DER du type PA-PK-AS-REP, est inclus dans le AS-REP.
PA-PK-AS-REP ::= CHOICE {
    dhInfo [0] DHRepInfo,
    -- Sélectionné quand l'échange de clé DH est utilisé
    encKeyPack [1] IMPLICIT OCTET STRING,
    -- Sélectionné quand le chiffrement par clé publique est utilisé
    -- Contient un type CMS ContentInfo encodé
    -- le champ contentType de type ContentInfo est id-envelopedData (1.2.840.113549.1.7.3)
    -- Le champ content est un EnvelopedData
    -- le champ contentType pour le type EnvelopedData est id-signedData (1.2.840.113549.1.7.2)
    -- le champ eContentType pour le type SignedData est id-pkinit-rkeyData (1.3.6.1.5.2.3.3)
    -- et le champ eContent contient le DER du type ReplyKeyPack
}
KDCDHKeyInfo ::= SEQUENCE {
    subjectPublicKey [0] BIT STRING,
    -- La clé publique DH du KDC
    -- la clé publique DH est encodée en BIT STRING
    nonce [1] INTEGER (0..4294967295),
    -- Contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. 0 sinon.
    dhKeyExpiration [2] KerberosTime OPTIONAL,
    -- Temp d'expiration pour la paire de clé du KDC, présent si est seulement si les clé DH sont réutilisées
    -- Si présent, la clé publique DH du KDC ne doit pas être utilisé passé cette expiration
    -- Si ce champ est omis, le champ serverDHNonce doit également être utilisé.
}

   Le contenu de AS-REP est inchangé sinon. Le KDC chiffre la réponse normalement, mais pas avec la clé long-terme du client. À la place, il le chiffre avec soit une clé partagée dérivée d'un échange DH, ou une clé de chiffrement générée. Le contenu de PA-PK-AS-REP indique quelle méthode de livraison de clé est utilisé.

   Si le client ne souhaite pas utiliser la méthode DH ( le champ clientPublicValue n'est pas présent dans la demande ) et que le KDC ne supporte pas la méthode de livraison de clé de chiffrement à clé publique, le KDC doit retourner un message d'erreur avec le code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. Il n'y a pas de e-data accompagnant ce message d'erreur.

   En plus, la durée de vie du ticket retourné par le KDC ne doit pas excéder celle de la paire de clé du client.

Utiliser l'échange de clé Diffie-Hellman

   Dans ce cas, le PA-PK-AS-REP contient une structure SHRepInfo. La structure ContentInfo pour le champ shSignedData est remplis comme suis:

1. Le champ contentType du type ContentInfo est id-signedData, et le champ content est un SignedData
2. Le champ eContentType pour le type SignedData est l'OID pour id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
3. Le champ eContent pour le type SignedData contient le DER du type KDCDHKeyInfo.
4. La structure KDCDHKeyInfo contient la clé publique du KDC, un nonce, et optionnellement l'expiration de la clé DH du KDC qui est réutilisée. Le champ subjectPublicKey du type KDCDHKeyInfo identifie la clé publique DH du KDC. Ce clé est encodée en BIT STRING. Le champ nonce contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. La valeur de ce champ nonce est 0 si les clés DH sont réutilisées. Le champ dhKeyExpiration est prisent si et seulement si les clé DH sont réutilisées. Si le champ dhKeyExpiration est présent, la clé publique DH du KDC dans cette structure KDCDHKeyInfo ne doit pas être utilisée passé ce temps. Si ce champ est omis, le champ serverDHNonce doit également être omis.
5. Le champ signerInfo du type SignedData contient un simple signerInfo, qui contient la signature pour le type KDCDHKeyInfo.
6. Le champ certificat du type SignedData contient les certificats prévus pour faciliter la construction du chemin de certification, pour que le client puisse vérifier la signature du KDC pour le type KDCDHKeyInfo. Les informations contenus dans le trustedCertifiers dans la demande devraient être utilisés par le KDC pour l'aider dans sa sélection d'une chaîne de certificats approprié à retourner au client. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Le KDC doit être capable d'inclure un tel jeu de certificat s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Si le client inclus le champ clientDHNonce, le KDC peut choisir de réutiliser ses clés DH, et doit inclure un temps d'expiration. Quand le serveur réutilise les clé DH, il doit inclure un serverDHNonce au moins aussi long que la longueur des clé pour le système de chiffrement symétrique utilisé pour chiffrer la réponse AS. Noter qu'inclure le serverDHNonce change la manière dont le client et le serveur calculent le clé à utiliser pour chiffrer la réponse. Le KDC ne dervait pas réutiliser les clé DH sauf si clientDHNonce est présent dans la demande.

   La réponse AS est dérivée comme suit:

1. Le KDC et le client calculent la clé partagée comme suit: Quand MODP Diffie-Hellman est utilisé, les DHSharedSecret être la valeur de clé secrète. DHSharedSecret est la valeur ZZ, et est remplis avec des 0 pour la taille en octets soit la même que le modulo, et représente une chaîne d'octet dans l'ordre big-endian.
2. Laisse K être la source de génération de clé de la réponse AS.
3. Définie la fonction octetstring2key() comme suis:


octetstring2key(x) == random-to-key(K-truncate(
    SHA1(0x00 | x) |
    SHA1(0x01 | x) |
    SHA1(0x02 | x) |
    ...
    ))

   où x est une chaîne d'octets, | est l'opérateur de concaténation, 0x00, etc. sont représentés comme octet simple, random-to-key() est une opération qui génère une clé de protocole depuis un bitstring de longueur K; et K-truncate tronque son entrée au premiers K bits.

4. Quand les clé DH sont réutilisées, laisse n_c être le clientDHNonce et n_k être le serverDHNonce, sinon ils sont vides.
5. La clé de réponse AS est: k = octetstring2key(DHSharedSecret | n_c | n_k)

Utiliser le chiffrement à clé publique

   Dans ce cas, le PA-PK-AS-REP contient le champ encKeyPack où la clé de réponse AS est chiffrée. La structure ContentInfo pour le champ encKeyPack est construit comme suit:

1. Le champ contentType du type ContentInfo est id-envelopedData, et le champ content est un EnvelopedData
2. Le champ contentType pour le type EnvelopedData est id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
3. Le champ eContentType pour le type SignedData ( quand déchiffré depuis le champ EncryptedContent pour le type EnvelopedData) est id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
4. Le champ eContent pour le type SignedData contient le DER du type ReplyKeyPack
5. Le champ signerInfos du type SignedData contient un simple signerInfo, qui contient la signature pour le type ReplyKeyPack.
6. Le champ certificates pour le type SignedData contient les certificats pour construire le chemin de certification, pour que le client puisse vérifier la signature du KDC pou le type ReplyKeyPack. Les informations contenues dans le trustedCertifiers dans la demande devraient être utilisés par le KDC comme guide dans sa sélection d'une chaîne de certification appropriée. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Sinon, pour la validation du chemin, ces certificats devraient être suffisant pour construire au moins un chemin de certification depuis le certificat du KDC. Le KDC doit être capable d'inclure un tel jeu s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Le champ recipientInfos du type EnvelopedData est un jeu qui doit contenir exactement un membre du type KeyTransRecipientInfo. Le encryptedKey de ce membre contient la clé temporaire qui est chiffrée en utilisant la clé publique du client.
8. Les champs unprotectedAttrs ou originatorInfos du type EnvelopedData peut être présent.

   S'il y a un champ supportedCMSTypes dans le AuthPack, le KDC doit vérifier s'il supporte un des types listés. S'il supporte plus d'un type, le KDC devrait utilisé le premiers qui listé. S'il n'en supporte aucun, le KDC doit retourner un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP.

   Le KDC calcule le checksum du AS-REQ dans la demande du client. Ce checksum est effectué sur le type AS-REQ, et la clé de protocole de l'opération checksum est le replyKey, et le numéro d'utilisation de clé est 6. Si le enctype de replyKey est "newer", l'opération checksum est l'opération checksum requise de ce enctype:


ReplyKeyPack ::= SEQUENCE {
    replyKey [0] EncryptionKey,
    -- contient la clé de session utilisé pour chiffrer le
    -- champ enc-part dans le AS-REP. par ex: la clé de réponse AS
    asChecksum [1] Checksum,
    -- Contient le checksum du AS-REQ correspondant au AS-REP
    -- Le checksum est effectué sur le type AS-REQ.
    ...
    }

   Les implémentations de cette méthode de livraison de clé de chiffrement RSA devraient supporter les clé RSA d'au moins 2048-bits.

Réception de la réponse du KDC

   Une fois la réponse du KDC reçus, le client procède comme suit. Si le PA-PK-AS-REP contient le champ dhSignedData, le client dérive le clé de réponse AS en utilisant la même procédure utilisée par le KDC. Sinon, le message contient le champ encKeyPack, et le client déchiffre de extrait la clé temporaire dans le champ encryptedKey du membre KeyTransRecipientInfo et l'utilise comme clé de réponse AS. Si la méthode de chiffrement à clé publique est utilisé, le client doit vérifier le asChecksum dans le ReplyKeyPack.

   Dans tous les cas, le client doit vérifier la signature dans le SignedData. En plus, sauf si le client peut vérifier que la clé publique utilisée pour vérifier la signature du KDC est liée au KDC du domaine cible, le certificat du KDC doit contenir un SAN ayant un AnotherName dont type-id est id-pkinit-san et dont la valeur est un KRB5PrincipalName qui correspond au nom du TGS du domaine cible.

À moins que le client connaisse par d'autres moyens que le certificat du KDC est prévu pour un KDC, le client doit imposer que le certificat du KDC contienne le EKU KeyPurposeId id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) keyPurposeKdc(5) }

   Le bit d'utilisation de clé digitalSignature doit être mis quand le but du certificat du KDC est restreins avec le EKU id-pkinit-KPKdc. Si le certificat du KDC contient le nom du TGS encodé en SAN id-pkinit-san, ce certificat est certifié par la CA qui l'a délivré, et donc l'EKU id-pkinit-KPKdc n'est pas requis. Si toutes les vérifications applicables sont satisfaites, le client déchiffre le champ enc-part du KDC-REP dans le AS-REP, utilisant la clé de réponse AS, puis procède normalement.

Prérequis d'intéropérabilité

   Le client doit être capable d'envoyer un jer de certificats suffisant pour permettre au KDC de construire un chemin de certification pour le certificat du client, si le jeu correct de certificat est fournis via la configuration ou la stratégie. Si le client envoie tous les certificats X.509 dans un chemin de certification en une chaîne acceptable pour le KDC, et si le KDC ne peut par vérifier la clé publique du client, le KDC doit être capable de traiter la validation pour le certificat du client basé sur les certificats dans le demande.

Indication du support PKINIT

   Si la pré-authentification est requise mais n'est pas présente dans la requête, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILED est retourné, et un objet METHOD-DATA sera présent dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Le KDC peut ainsi indiquer le support de PKINIT en incluant un élément vide dont le padata-type est PA_PK_AS_REQ dans l'objet METHOD-DATA.

   Sinon s'il est requis par la stratégie local du KDC que le client doive être pré-authentifié en utilisant le mécanisme de pré-authentification spécifié dans ce document, mais qu'aucune pré-authentification PKINIT n'est présent dans la requête, une message d'erreur avec le code d'erreur KDC_ERR_PREAUTH_FAILED devrait être retourné.

   Le KDC doit laisser le champ padata-value de l'élément PA_PK_AS_REQ dans le METHOD-DATA du KRB-ERROR vide, et les clients doivent l'ignorer. De futures extensions de ce protocole peuvent spécifier d'autres données à envoyer au lieu d'un OCTET STRING vide.
^
06 novembre 2013

htmlpdflatexmanmd




rfc4876

rfc4876

Schéma de profile de configuration pour les agents basés sur LDAP

preferredServerList Liste d'adresses et ports de serveurs que le DUA doit contacter, dans l'ordre.
defaultServerList Doit être examiné seulement si preferredServerList n'est pas fournis.
defaultSearchBase Quand un DUA doit requêter le DSA pour des informations, cet attribut fournis la base de recherche.
authenticationMethod Liste par ordre de préférence de méthodes bind. (peut être none, simple, sasl et tls)


authMethod = method *(";" method)
method = none / simple / sasl / tls
none = "none"
simple = "simple"
sasl = "sasl/" saslmech [ ":" sasloption ]
sasloption = "auth-conf" / "auth-int"
tls = "tls:" (none / simple / sasl)
saslmech = SASL mechanism name

credentialLevel Type de crédentials que le DUA doit utiliser en contactant le DSA (anonymous, proxy, self)


credentialLevel = level *(SP level)
level = self / proxy / anonymous
self = "self"
proxy = "proxy"
anonymous = "anonymous"

serviceSearchDescriptor Définis comment et où un DUA devrait rechercher les informations pour un service particulier.


serviceSearchList = serviceID ":" serviceSearchDesc *(";" serviceSearchDesc)
serviceSearchDesc = confReferral / searchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] [" ?" [filter]]]
confReferral = "ref :" distinguishedName
base = distinguishedName / relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
filter = UTF-8 encoded string

Exemple

defaultSearchBase: dc=mycompany,dc=com
serviceSearchDescriptor: email:ou=people,ou=org1,?
one;ou=contractor,?one;
ref:cn=profile,dc=mycompany,dc=com

   Dans cet exemple, le DUA doit rechercher dans "ou=people,ou=org1,dc=mycompany,dc=com" en premier. Ensuite il devrait rechercher dans "ou=contractor,dc=mycompany,dc=com", et finalement il devrait rechercher dans d'autres emplacement comme spécifié dans le profile décris à "cn=profile,dc=mycompany,dc=com"

attributeMap Mapping d'attributs pour toutes les opérations LDAP effectuées pour un service qui a une entrée attributeMap. Parce que le mapping est spécifique à chaque service dans le DUA, un serviceID est requis dans la syntaxe.


attributeMap = serviceID ":" origAttribute "=" attributes
origAttribute = attribute
attributes = wattribute *( SP wattribute )
wattribute = WSP newAttribute WSP
newAttribute = descr / "*NULL*"
attribute = descr

   exemple: supposons qu'un DUA agis comme un service mail. Par défaut, le service email utilise "mail", "cn" et "sn" pour découvrir les adresses emails. Cependant, le service email a été déployé dans un environnement qui utilise "employeeName" au lieu de "cn". également, au lieu d'utiliser "mail", l'attribut utilisé est "email":

attributeMap: email:cn=employeeName
attributeMap: email:mail=email

searchTimeLimit Définis le temps maximum en secondes que le DUA devrait permettre pour une requête search.
bindTimeLimit Définis le temps maximum en secondes que le DUA devrait permettre pour les opérations bind.
followReferrals à TRUE, le DUA devrait suivre les référants. a FALSE, ne doit pas les suivre.
dereferenceAliases à TRUE, le DUA devrait permettre le déréférencement d'alias. A FALSE, ne doit pas déréférencer les alias.
profileTTL Définis la fréquence à laquelle le DUA devrait recharger et se reconfigurer.
objectclassMap Un DUA peut effectuer un mappage de classe d'objet pour toutes les opérations LDAP effectuées pour un service


objectclassMap = serviceID ":" origObjectclass "=" objectclass
origObjectclass = objectclass
objectclass = keystring

   exemple: supposons qu'un DUA agit comme un service mail. Par défaut le service "email" utilise "mail", "cn" et "sn" pour découvrir les adresses email dans les entrées créée en utilisant la classe d'objet inetOrgPerson. Cependant, le service mail a été déployé dans un environnment qui utilise les entrées crééer en utilisant la classe d'objet "employee". Dans ce cas, "cn" peut être mappé à "employeeName", et "inetOrgPerson" peut être mappé à "employee":

attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee

defaultSearchScope Fournis le scope de recherche pour le DUA. Peut être écrasé par serviceSearchDescriptor



scopeSyntax = "base" / "one" / "sub"

serviceAuthenticationMethod Définis par ordre de préférence de méthodes bind à utiliser pour contacter un DSA pour un service particulier.



svAuthMethod = serviceID ":" method *(";" method)

serviceCredentialLevel Définis quel types de crédentials le DUA devrait utiliser en contacta,t le DSA pour un service particulier.



svCredentialLevel = serviceID ":" level *(SP level)

Exemple

serviceCredentialLevel: email:proxy anonymous

Schéma


( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' DESC 'List of default servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' DESC 'Default base for searches' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC 'List of preferred servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' DESC 'Maximum time an agent or service allows for a search to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' DESC 'Maximum time an agent or service allows for a bind operation to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' DESC 'An agent or service does or should follow referrals' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' DESC 'Identifies the types of authentication methods either used, required, or provided by a service or peer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' DESC 'Time to live, in seconds, before a profile is considered stale' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' DESC 'Attribute mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials either used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' DESC 'Object class mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' DESC 'Default scope used when performing a search' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' DESC 'Specifies the type of credentials either used, required, or supported by a specific service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' DESC 'Specifies search descriptors required, used, or supported by a particular service or agent' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' DESC 'Specifies types authentication methods either used, required, or supported by a particular service' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases' DESC 'Specifies if a service or agent either requires, supports, or uses dereferencing of aliases.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )


( 1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile'
    SUP top STRUCTURAL
    DESC 'Abstraction of a base configuration for a DUA'
    MUST ( cn )
    MAY ( defaultServerList $ preferredServerList $
    defaultSearchBase $ defaultSearchScope $
    searchTimeLimit $ bindTimeLimit $
    credentialLevel $ authenticationMethod $
    followReferrals $ dereferenceAliases $
    serviceSearchDescriptor $ serviceCredentialLevel $
    serviceAuthenticationMethod $ objectclassMap $
    attributeMap $ profileTTL ) )

Exemples

   Dans cette section, on décris un DUA fictif qui fournis un service appelé "email". Ce service est configuré de manière à trouver les utilisateurs avec un adresse email avec la classe d'objet inetOrgPerson, Le nom dans "cn" et le mail dans "mail"

   Le filtre de recherche par défaut pour le service email est "(objectclass=inetOrgPerson)". Le service email définis également que quand il effectue une découverte nom/adresse, il va construire le filtre avec:

  (&(‹filter›)(cn=‹name string›))

ou, si "cn" a été mappé vers d'autres attributs:
(&(‹filter›)(attr1=‹token1›)(attr2=‹token2›)...)

   L'exemple ci-dessous montre comment le service email construit sa recherche, basé sur un profile définis. Dans tous les cas, defaultSearchBase est "o=airius.com", et defaultSearchScope n'est pas définis.

exemple 1:
serviceSearchDescriptor:email:"ou=marketing,"
    
base: ou=marketing,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn=Jane Hernandez))

exemple 2:
serviceSearchDescriptor:email:"ou=marketing,"?one?(&(objectclass=inetOrgPerson)(c=us))
attributeMap:email:cn=2.5.4.42 sn

   Note: 2.5.4.42 est l'OID qui représente "givenName"

Dans cet exemple, le service email effectue une recherche ‹name string› comme décris plus haut pour générer un filtre de recherche complexe. L'exemple suivant résulte d'une recherche:
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))(2.5.4.42=Jane)(sn=Hernandez))

Exemple 3:
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap:email:cn=name

   Cet exemple est invalide parce que soit les guillemets devraient être échappé, soit il devrait y avoir des "

exemple 4:
serviceSearchDescriptor:email:ou=\\mar\\\\keting,\\"?base
attributeMap:email:cn=name
    
base:ou=\\mar\\keting,"
scope:base
filter: (&(objectclass=inetOrgPerson)(name=Jane Hernandez))

exemple 5:
serviceSearchDescriptor:email:ou="marketing",o=supercom

   Cet exemple est invalide parce que les " doivent être échappés

Exemple 6:
serviceSearchDescriptor:email:??(&(objectclass=person)(ou=Org1\\\\(temporary\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1\\(Temporary\\)))(cn=Jane Henderson)))

Exemple 7:
serviceSearchDescriptor : email :"ou=funny ?org,"
    
base: ou=funny?org,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn=Jane Hernandez))

^
18 août 2015

htmlpdflatexmanmd




rfc5019

rfc5019

Profile OCSP pour les environnements à haut volume

   OCSP spécifie un mécanisme utilisé pour déterminer le statut des certificats numériques, au lieu d'utiliser les CRL. Depuis sa définition en 1999, il a été déployé dans de nombreux environnements et prouvé son utilité.

   À ce jour, de nombreux déploiements on été utilisé pour s'assurer les informations de statut de certificats de manière sécurisé et en temps pour les transactions électroniques ou hautement sensibles, tels que les environnements financiers. Un tel environnement exige un répondeur OCSP en temps réel. De plus, ces déploiements ont opérés dans des environnements où l'utilisation de la bande passante n'est pas un problème, et fonctionnement sur des systèmes client et serveur où la charge de traitement n'est pas une contrainte.

   Vu que l'utilisation d'une PKI continue de grandir et d'aller dans divers environnements, on n'a donc besoin d'un mécanisme de statut de certificat efficace. Bien qu'OCSP a été définis et déployé dans de nombreuses petites et moyennes PKI qui opèrent sur des systèmes puissants et sur des réseaux câblés, il y a une limite sur l'agrandissement des déploiements. Les environnements mobiles, où la bande passante peut être une des principales contraintes, il exige une attention particulière de l'utilisation d'OCSP pour minimiser l'utilisation de la bande passante et la complexité de traitement côté client.

   Les PKI continuent d'être déployés dans des environnements où des millions voir des centaines de millions de certificats ont été émis. Dans beaucoup de ces environnements, un aussi grand nombre d'utilisateurs on besoins de s'assurer que le certificat qu'ils souhaitent utiliser n'a pas été révoqué. Il est important que OCSP soit utilisé de manière à s'assurer que la charge des répondeurs OCSP et que l'infrastructure réseaux soient utilisés au minimum.

   Ce document adresse les problèmes d'évolution inhérents en utilisant OCSP dans des environnements PKI décrits ci-dessus en définissant un profile de message et en clarifiant le comportement du client et du répondeur OCSP qui va permettre de:

1) pré-produire et distribuer des réponse OCSP
2) Réduire la taille de message OCSP pour réduire la bande passante
3) Le caching des messages de réponse dans le réseaux et dans le client

   Il est prévu que les exigences définies dans ce profile soit adopté par les clients et les répondeurs OCSP opérant dans des environnements PKI à très grand volume ou les environnements PKI qui exigent une solution légère pour minimiser la bande passante de le traitement côté client. Vu que OCSP n'a pas de moyen de signaler les capacités du répondeur dans le protocole, les clients doivent différencier les réponses OCSP produites par les répondeurs conforme avec ce profile et ceux qui n'ont pas besoin de s'appuyer sur des mécanismes externe pour déterminer quand une réponse opère en accord avec ce profile et, quand les exigences de ce profile s'appliquent. Dans le cas où des mécanismes tiers ne sont pas disponible entre un client OCSP 2560 et un répondeur qui opère dans un mode décrit dans cette spécification.

Profile de demande OCSP

Structure OCSPRequest

   OCSPRequest conforme a ce profile doit inclure seulement une Request dans la structure OCSPRequest.RequestList

   Les clients ne doivent pas utiliser SHA1 comme algorithme de hash pour les valeurs CertID.issuerNameHash et CertID.issuerKeyHash.

   Les clients ne doivent pas inclure la structure singleRequestExtensions

   Les clients ne devraient pas inclure la structure requestExtensions. Si une structure requestExtensions est inclue, ce profile recommande qu'il ne contienne seulement que l'extension nonce (id-pkix-ocsp-nonce).

OCSPRequests signées

   Les clients ne doivent pas envoyer d'OCSPRequests signés. Les répondeurs peuvent ignorer la signature dans les requêtes OCSPRequests.

   Si OCSPRequest est signé, le client devrait spécifier son nom dans le champ OCSPRequest.requestorName, sinon, les clients ne devraient pas inclure le champ requestorName dans OCSPRequest. Les serveurs OCSP doivent être préparés à recevoir des requêtes OCSP non-signés qui contiennent le champ requestorName, mais doivent réaliser que la valeur fournie n'est pas authentifiée.

Profile de réponse OCSP

Structure OCSPResponse

   Les répondeurs doivent générer un BasicOCSPResponse comme identifié par l'OID BasicOCSPResponse. Les OCSPResponses conformes à ce profile devraient inclure seulement un SingleResponse dans la structure ResponseData.responses, mais peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération de réponse ou l'efficacité des caches.

   Le répondeur ne devrait pas inclure responseExtensions. Comme spécifié dans OCSP, les clients doivent ignorer les responsesExtensions non-critiques dans la réponse.

   Dans le cas où un répondeur n'a pas la possibilité de répondre à une demande OCSP contenant une option non supportée par le serveur, il devrait retourner la réponse la plus complète qu'il peut. Par exemple, dans le cas où un répondeur ne supporte que les réponses pré-produites et n'a pas la possibilité de répondre à une demande OCSP contenant a nonce, il devrait retourner une réponse qui n'inclut pas un nonce.

   Les clients devraient tenter de traiter une réponse même si la réponse n'inclue pas un nonce.

   Les répondeurs qui n'ont pas la capacité de répondre aux requêtes OCSP qui contiennent une option non-supportée telle que nonce peuvent renvoyer la requête à un répondeur OCSP qui en a la capacité.

   Le répondeur peut inclure la structure d'extensions singleResponse.singleResponse.

OCSPResponses signés

   Les clients doivent valider la signature de l'OCSPResponse retourné. Si la réponse est signée par un délégué de l'autorité de certification émettrice, un certificat de répondeur valide doit être référencé dans la structure BasicOCSPResponse.certs.

   Il est recommandé que le certificat du répondeur OCSP contienne l'extension id-pkix-ocsp-nocheck, comme définis dans OCSP, pour indiquer au client qu'il ne doit pas vérifier le statut du certificat. De plus, il est recommandé que ni une extension authorityInfoAccess ni une extension cRLDistributionPoints ne soit inclus dans le certificat du répondeur OCSP. En accord avec ça, le certificat de signature du répondeur devrait être relativement de courte durée et renouvelé régulièrement.

   Les clients doivent être capable d'identifier les certificats de répondeur OCSP en utilisant les chois ResponseData.ResponderID byName et byKey. Les répondeur devraient utiliser byKey pour réduire ensuite la taille de la réponse dans les scénarios où la réduction de la bander passante est un problème.

Valeurs OCSPResponseStatus

   Tant que l'infrastructure OCSP a des enregistrements autoritatifs pour un certificat particulier, un OCSPResponseStatus "Success" sera retourné. Quand l'accès aux enregistrements autoritatifs pour un certificat particulier n'est pas disponible, le répondeur doit retourner un OCSPResponseStatus "unautorized". Ce profile étend la rfc2560 de "unauthorized" comme suit:

           La réponse "unauthorized" est retournée dans le cas où le client n'est pas autorisé à faire cette demande à ce serveur ou quand le serveur n'est pas capable de répondre de manière autoritative.

   Par exemple, les répondeurs OCSP qui n'ont pas accès aux enregistrements autoritatifs pour un certificat, tel que ceux qui génèrent et distribuent les réponses OCSP à l'avance et donc n'ont pas la capacité de répondre correctement avec une réponse "success" ni "unknown", vont répondre avec un OCSPResponseStatus "unauthorized". Également, pour s'assurer que la base d'information de révocation ne grandis pas indéfiniment dans le temps, le répondeur peut supprimer les enregistrements des certificats expirés. Les demandes des clients pour les certificat dont l'enregistrement a été supprimé vont résulter dans un OCSPResponseStatus "unauthorized".

thisUpdate, nextUpdate, et producedAt

   En pré-produisant les messages OCSPResponse, le répondeur doit définir les temps thisUpdate, nextUpdate et producedAt comme suit:

thisUpdate La date à laquelle le statut indiqué est connu comme étant correcte
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles sur le statut des certificats. Les répondeur doivent toujours inclure cette valeur pour aider dans le caching des réponses.
producedAt La date à laquelle la réponse OCSP a été signée

   Note: Dans de nombreux cas la valeur de thisUpdate et producedAt seront les même.

   Pour ce profile, les valeurs GeneralizedTime encodé ASN.1 pour thisUpdate, nextUpdate et producedAt doivent être exprimés en GMT et doivent inclure les secondes, même quand le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Comportement du client

Découverte du répondeur OCSP

   Les clients doivent supporter l'extension authorityInfoAccess comme définis dans PKIX et doivent reconnaître la méthode d'accès id-ad-ocsp. Cela permet d'informer les clients sur la manière de contacter le service OCSP.

   Dans le cas où un client vérifie le statut d'un certificat qui contient une extension authorityInformationAccess pointant vers un répondeur OCSP et une extension cRLDistributionPoints pointant vers une CRL, le client devrait tenter de contacter le répondeur OCSP en premier. Les clients peuvent tenter de récupérer la CRL si aucune OCSPResponse n'est reçu du répondeur.

Envoyer une demande OCSP

   Pour éviter le trafic réseaux inutile, les applications doivent vérifier la signature d'une donnée signée avant de demander à un client OCSP de vérifier le statut des certificats utilisé pour vérifier la donnée. Si la signature est invalide ou l'application n'est pas capable de la vérifier, une vérification OCSP ne doit pas être tentée.

   Similairement, une application doit valider la signature dans les certificats dans une chaîne, avant de demander à un client OCSP de vérifier le statut d'un certificat. Si la signature du certificat est invalide ou que l'application n'est pas capable de le vérifier, une vérification OCSP ne doit pas être faite. Les clients ne devraient pas faire de demande de statut des certificats expirés.

S'assure qu'un OCSPResponse est récent

   Pour s'assurer qu'un client n'accepte pas de réponse expirée qui indique un statut 'good' il y a une réponse plus récente qui spécifie un statut 'revoked', un client doit s'assurer que les réponses qu'ils reçoivent sont récentes.

   En général, 2 mécanismes sont disponibles aux clients pour s'assurer qu'une réponse est récente. La première utilise nonces, et la seconde est basée sur la date. Pour que les mécanismes basés sur les dates fonctionnent, les clients et les répondeurs doivent avoir accès à une source de temps précise.

   Parce que ce profile spécifie que les clients ne devraient pas inclure une structure requestExtensions dans OCSPRequests, les clients doivent être capable de déterminer que OCSPResponse est récent basé sur une source de temps précise. Les clients qui optent pour inclure un nonce dans le demande ne doivent pas rejeter une OCSPResponse correspondante seulement sur la base de la non-existance du nonce attendu, mais doivent valider l'OCSPResponse basé sur le temps.

   Les clients qui n'incluent pas un nonce dans la requête doivent ignorer tout nonce qui peut être présent dans la réponse.

   Les clients doivent vérifier l'existence du champ nextUpdate et doivent s'assurer de la date courante, exprimée en temps GMT, qui doit être entre le thisUpdate et le nextUpdate. Si le champ nextUpdate est absent, le client doit rejeter la réponse.

   Si le champs nextUpdate est présent, le client doit s'assurer qu'il n'est pas antérieur la date courante. Si la date courante dans le client est ultérieur au temps spécifié dans le champ nextUpdate, le client doit rejeter la réponse. Les clients peuvent autoriser la configuration d'une petite période de tolérance pour accepter des réponses après nextUpdate pour gérer les différences mineurs d'horloge relative aux répondeurs et aux caches. Cette période de tolérance devrait être choisis sur la précision de la technologie de synchronisation de temps disponible dans l'environnement de l'application appelante. Par exemple, les paires internet avec connexion à faibles latences s'attendent à une synchronisation du temps NTP avec une précision élevée; les environnements à haute latence ou quand un NTP n'est pas disponible peuvent avoir besoin d'une tolérance plus élevée.

Profile de transport

   Le répondeur OCSP doit supporter les requêtes et réponses sur HTTP. En envoyant les requêtes qui sont inférieur ou égal à 255 octets au total (après encodage) incluant le schéma et les délimiteurs (http://), le nom du serveur et la structure OCSPRequest encodé en base 64, les clients doivent utiliser la méthode GET (pour permettre le caching de réponse OCSP). Les requêtes OCSP supérieurs à 255 octets devraient être envoyés en utilisant la méthode POST. Dans tous les cas, les clients doivent suivre les descriptions définis dans la norme OCSP en construisant leurs messages.

En construisant un message GET, les clients OCSP doivent encoder en base 64 la structure OCSPRequest et l'ajouter à l'URI spécifiée dans l'extension authorityInfoAccess. Les clients ne doivent pas inclure les caractères CR ou LF dans la chaîne encodée base 64. Les clients doivent encoder l'url proprement, par exemple:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D

En réponse aux OCSPRequests formatés proprement qui sont capable d'être mis en cache (par exemple, les réponses qui contiennent une valeur nextUpdate), le répondeur va inclure la valeur binaire de l'encodé DER de l'OCSPResponse précédé par l'en-tête HTTP suivant:
content-type: application/ocsp-response
content-length: ‹OCSP response length›
last-modified: ‹producedAt [HTTP] date›
ETag: "‹strong validator›"
expires: ‹nextUpdate [HTTP] date›
cache-control: max-age=‹n›, public, no-transform, must-revalidate
date: ‹current [HTTP] date›

Recommandations de mise en cache

   La capacité de mise en cache des réponses OCSP via le réseaux est un facteur important dans les déploiements à haut volume. Cette section discute de comportement de la mise en cache des clients OCSP et des proxy HTTP et les étapes qui devraient être faites pour minimiser le nombre de fois que les clients OCSP utilisent le réseaux. De plus, le concept de réponses OCSP incluses dans les échanges de protocole ( stapling ou piggybacking), tel que définis dans TLS, sont également discutés.

Mise en cache par le client

   Pour minimiser l'utilisation de la bande passante, les clients doivent mettre en cache localement les réponses OCSP autoritatives (ex: une réponse avec une signature qui a été validée avec succès et qui indique un OCSPResponseStatus 'successful').

   Beaucoup de clients OCSP vont envoyer des OCSPRequests à ou près du temps nextUpdate (quand une réponse mise en cache expire). Pour éviter des pointes importantes dans la charge des répondeurs qui peuvent se produire quand de nombreux clients rafraîchissent les réponses en cache pour un certificat populaire, les répondeurs peuvent indiquer quand le client devrait chercher une réponse OCSP mise à jours en utilisant la directive cache-control:max-age. Pour s'assurer que les clients reçoivent une réponse mises à jours, les répondeurs OCSP doivent rafraîchir la réponse OCSP avant le temps max-age.

Proxy HTTP

   Le répondeur devrait définir l'en-tête HTTP dans la réponse OCSP de manière à permettre une utilisation intelligente des serveurs proxy intermédiaire. Voir la norme HTTP pour la définition de ces en-têtes et le format correcte.

HTTP Header___Description
date La date et l'heure à laquelle le serveur OCSP a généré la réponse HTTP.
last-modified Cette valeur spécifie la date et l'heure à laquelle le répondeur OCSP à modifié la réponse. Cette date sera la même que thisUpdate dans la requête elle-même.
expires Spécifie la durée de à laquelle la réponse est considérée comme récente. Cette date est la même que nextUpdate dans la réponse OCSP.
ETag Une chaîne qui identifie une version particulière de la donnée associée. Ce profile recommande que la valeur ETag soit une représentation hexa ASCII du hash SHA1 de la structure OCSPResponse
cache-control Contient des directives de mise en cache:

        * max-age=‹n› où n est la valeur de temps ultérieur à thisUpdate mais inférieur à nextUpdate.
        * public rend la réponse non cachable
        * no-transform Spécifie qu'une proxy cache ne peut pas changer le type, longueur, ou encodage du contenu de l'objet.
        * must-revalidate empêche les caches de retourner des réponses périmées intentionnellement

   Les répondeurs OCSP ne doivent pas inclure d'en-tête "Pragma: no-cache", "Cache-Control: no-cache", ou "Cache-Control: no-store" dans les réponses OCSP autoritatives. Les répondeurs OCSP devraient inclure un ou plusieurs de ces en-têtes dans les réponses non-autoritatives.

Par exemple, supposons une réponse OCSP ayant les horodatages suivant:
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT

Et que les clients demandent la réponse le 2 may 2005 01:00:00 GMT. Dans ce scénario, la réponse HTTP peut ressembler à ceci:
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
‹...›

   Les clients OCSP ne doivent pas inclure d'en-tête no-cache dans les demandes, sauf si le client rencontre une réponse expirée qui peut être le résultat d'une donnée périmée d'un proxy cache. Dans cette situation, les clients devraient renvoyer le demande en spécifiant que les proxy devraient être bypassés en incluant un en-tête HTP approprié dans la demande (ex. Pragma: no-cache ou Cache-Control: no-cache).

Mise en cache des serveurs

   Dans certains scénarios, il est avantageux d'inclure les information de réponse OCSP dans le protocole utilisé entre le client et le serveur. En incluant les réponses OCSP de cette manière a quelques effet désirable.

   D'abord, il permet la mise en cache des réponses OCSP dans le serveur diminuant ainsi le nombre de requêtes au répondeur.

   Ensuite, il permet la validation de certificat dans le cas où le client n'est pas connecté à un réseaux et donc élimine le besoin pour les clients d'établir une nouvelle session HTTP avec le répondeur.

   Il réduit le nombre d'aller-retours que le client a besoin pour compléter un handshake

   Enfin, il simplifie l'implémentation OCSP côté client en permettant une situation où le client n'a seulement besoin de la capacité de parser et reconnaître les réponses OCSP.

   Cette fonctionnalité a été spécifiée comme extension du protocole TLS, mais peut être appliqué à tout protocole client-serveur.

   Ce profile recommande que les clients et les serveurs TLS implémentent le mécanisme d'extension de demande de statut de certificat pour TLS.

   D'autres informations sur les problèmes de mise en cache peuvent être obtenus depuis la rfc3143.

Considérations de sécurité

   Les considérations suivantes s'appliquent en plus des considérations de sécurité spécifié dans la norme OCSP.

Attaques Replay

   Puisque l'utilisation de nonce dans ce profile est optionnel, il y a possibilité qu'une réponse OCSP périmée puisse être rejouée, causant le client à accepter une réponse 'good' quand en fait il a été révoké. Pour réduire cette attaque, les clients doivent avoir accès à une source de temps précise et s'assurer que les réponses OCSP qu'ils reçoivent sont suffisamment récentes.

   Les clients qui n'ont pas de source de temps précise sont vulnérables. Par exemple, un client avec une horloge suffisamment rapide peut rejeter une réponse OCSP récente et accepter une réponses valide qui est expirée pour des certificat qui sont en fait révoqués.

   De future versions du protocole OCSP peuvent fournir une manière pour le client de savoir si le serveur supporte nonce ou non. Si un client peut déterminer que le serveur supporte nonce, il doit rejeter une réponse qui ne contient pas le nonce attendu. Sinon, les client qui optent pour inclure un nonce dans la demande ne devraient pas rejeter l'OCSPResponse correspondant uniquement sur la base de la non-existance du nonce, mais doivent également valider OCSPResponse sur la base du temps.

Attaques Man-In-The-Middle

   Pour réduire les risques associés avec ce type d'attaque, le client doit valider correctement la signature de la réponse. L'utilisation de réponses signées dans OCSP sert à authentifier l'identité du répondeur OCSP et de vérifier qu'il est autorisé à signer les réponses de la CA.

Attaques pas usurpation d'identité

   L'utilisation de réponses signées dans le serveur OCSP sert à authentifier l'identité du répondeur OCSP. Comme détaillé dans OCSP, les clients doivent valider correctement la signature de la réponse OCSP et la signature du certificat du signataire OCSP pour s'assurer que le répondeur est autorisé.

Attaques pas deni de service

   Les répondeurs OCSP devraient prendre des mesures pour empêcher ou réduire les attaques par déni de service. Vu que ce profile spécifie l'utilisation de OCSPRequests non-signés, l'accès au répondeur peut être donné implicitement par toute personne qui souhaite envoyer une demande à un répondeur, et ainsi la capacité de monter des attaques par déni de service via des demandes en rafales. Par exemple, un répondeur peut limiter le taux de demande entrante pour une adresse IP particulière si un comportement douteux est détecté.

Modification des en-têtes HTTP

   Les valeurs incluses dans les en-têtes HTTP ne sont pas protégées cryptographiquement; elles peuvent être manipulées par un attaquant. Les clients devraient utiliser ces valeurs pour la mise en cache seulement après s'assurer que les valeurs sont présentes dans le OCSPResponse signé. Les clients ne devraient pas valider les réponses au-delà de la date nextUpdate.

Authentification et autorisation des demandes

   La suggestion d'utiliser des demandes non-signée dans cet environnement supprime une option qui permet au répondeur de déterminer l'authenticité de la requête entrante. Donc, l'accès au répondeur peut être implicitement donné à toute personne qui peut envoyer une demande à un répondeur. Les environnement où l'autorisation explicite pour accéder au répondeur OCSP est nécessaire peuvent utiliser d'autres mécanismes pour authentifier les demandeurs, ou restreindre le service.
^
27 octobre 2013

htmlpdflatexmanmd




rfc5020

rfc5020

Attribut opérationnel entryDN

Cet attribut contient une copie du DN de l'entrée pour l'utiliser dans les assertions de valeur.
( 1.3.6.1.1.20 NAME 'entryDN'
    DESC 'DN of the entry'
    EQUALITY distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    SINGLE-VALUE
    NO-USER-MODIFICATION
    USAGE directoryOperation )

^
26 novembre 2014

htmlpdflatexmanmd




rfc5208

rfc5208

Syntaxe et conteneur pour les informations de clé privée

Définitions

   Les informations de clé privée incluent une clé privée pour un algorithme à clé publique spécifié, et un jeu d'attributs. La syntaxe de message cryptographique, dénifis dans la rfc5652, peut être utilisé pour signer numériquement, hasher, authentifier ou chiffrer le type de contenu de clé asymétrique.

   La liste suivante sont les mises à jours de la rfc5208:

- PrivateKeyInfo a été changé en OneAsymmetricKey. Cela reflète l'ajout du champ publicKey pour permettre aux 2 parties de la clé asymétrique d'être transportés séparément.
- Définition du type de contenu CMS asymmetric Key Package
- Suppression de la redondance IMPLICIT des attributs
- Ajout de publicKey à OneAsymmetricKey et mise à jour du numéro de version
- Ajout du support des attributs PKCS #9
- Ajout d'une discussion sur la compatibilité avec d'autres formats de clé privée
- Ajout des pré-requis pour le jeu de règle d'encodage
- Changement des imports depuis PKCS #5
- Remplacement de ALGORITHM-IDENTIFIER avec ALGORITHM depuis la rfc 5912
- Enregistrement du type de média application/pkcs8 et de l'extension de fichier .p8

Asymmetric Key Package CMS Content Type

   Le type de contenu CMS paquet de clé asymétrique est utilisé pour transférer une ou plusieurs clé asymétrique d'un partie à un autre. Un paquet de clé asymétrique peut être encapsulé dans un ou plusieurs types de contenu CMS de protection. Les anciennes versions de cette spécification de spécifiaient pas de jeu de règle d'encodage particulier, mais les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER.

Ce type de contenu a la syntaxe suivante:
ct-asymmetric-key-package CONTENT-TYPE ::=
    { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
    
id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
    { joint-iso-itu-t(2) country(16) us(840) organization(1)
        gov(101) dod(2) infosec(1) formats(2)
        key-package-content-types(78) 5
    }
    
AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
    
OneAsymmetricKey ::= SEQUENCE {
    version Version,
    privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
    privateKey PrivateKey,
    attributes [0] Attributes OPTIONAL,
    ...,
    [[2: publicKey [1] PublicKey OPTIONAL ]],
    ...
}
    
PrivateKeyInfo ::= OneAsymmetricKey
    
    -- PrivateKeyInfo est utilisé par [P12]. Si un élément taggé en version 2 est utilisé,
    -- La version doit être v2, sinon la version devrait être 1. Quand v1 est utilisé,
    -- PrivateKeyInfo est le même que dans la [RFC5208].
    
Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)
    
PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
    { PUBLIC-KEY,
        { PrivateKeyAlgorithms } }
    
PrivateKey ::= OCTET STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé
    
PublicKey ::= BIT STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé
    
Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } }

   AsymmetricKeyPackage contient un ou plusieurs élément OneAsymmetricKey.

   La syntaxe de OneAsymmetricKey accueille un numéro de version, une indication de l'algorithme asymétrique à utiliser avec la clé privée, une clé privée, des attributs optionnels ( par ex. userCertificate de X.520 ), et une clé publique optionnelle. En général, doit la clé publique, soit le certificat est présent. Dans de très rare cas les 2 sont présents, vu qu'ils incluent chacun une copie de la clé publique. OneAsymmetricKey renomme la syntaxe PrivateKeyInfo définie dans la rfc5208. Le nouveau nom reflète mieux la capacité de s'occuper des composant clé publique et privée. La compatibilité avec PrivateKeyInfo est préservée via le numéro de version. Les champs dans OneAsymmetricKey sont utilisé comme suit:

version Identifie la version de OneAsymmetricKey. Si publicKey est présent, la version est v2 sinon v1.
privateKeyAlgorithm Identifie l'algorithme de clé privée et optionnellement les paramètres associés avec la paire de clé asymétrique. L'algorithme est identifiée par un OID et le format des paramètres dépend de cet OID, mais le jeu d'objets privateKeyAlgorithms restreins les OID permis. La valeur placée dans PrivateKeyAlgorithmIdentifier est la valeur d'un algorithme utilisé avec la clé privée.
privateKey Est une chaîne d'octets qui contiennent la valeur de la clé privée. L'interprétation du contenu est définis dans l'enregistrement de l'algorithme de clé privée. Par exemple, une clé DSA est un entier, une clé RSA est représentée en RSAPrivateKey comme définis dans la rfc3447, et une clé ECC est représentée comme ECPrivateKey comme définie dans la rfc5915.
attributes est optionnel et contient les informations correspondantes à la clé publique (par ex: les certificats). Les champs attributes utilise la classe ATTRIBUTE qui est restreins par le jeu d'objet OneAsymmetricKeyAttributes. Les attributs de la rfc2985 peuvent être supportés.
publicKey est optionnel. Si présent, il contient la clé publique encodée en chaîne de bits. L structure dans cette chaîne dépend de privateKeyAlgorithm. Par exemple, une clé DSA est un entier. Noter que les clé publiques RSA sont inclues dans RSAPrivateKey, comme dans rfc 3447, et les clé publiques ECC sont inclues dans ECPrivateKey, comme dans rfc 5915.

Informations de clé privée chiffrée

Cette section donne la syntaxe pour les informations de clé privée chiffrée qui sont utilisées par [P12]:
EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm EncryptionAlgorithmIdentifier,
    encryptedData EncryptedData }
    
EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    { CONTENT-ENCRYPTION,
        { KeyEncryptionAlgorithms } }
    
EncryptedData ::= OCTET STRING

encryptionAlgorithm Identifie l'algorithme sous lequel les informations de clé privée sont chiffrées.
encryptedData Est le résulta du chiffrement des informations de clé privée.

   Le processus de chiffrement est constitué des étapes suivantes:

1. Les informations de clé privée sont encodées. Les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER
2. Le résultat de la première étape est chiffré avec la clé secrète pour donner une chaîne d'octets, le résultat du processus de chiffrement.

Protection de AsymmetricKeyPackage

   Les types de contenu de protection CMS peuvent être utilisés pour fournir une sécurité à AsymmetricKeyPackage:

SignedData Peut être utilisé pour appliquer une signature numérique à AsymmetricKeyPackage
EncryptedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire partagent déjà la clé de chiffrement nécessaire.
EnvelopedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire ne partagent pas la clé de chiffrement nécessaire.
AuthenticatedData Peut être utilisé pour protéger AsymmetricKeyPackage avec MAC, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.
AuthEnvelopedData Peut être utilisé pour protéger AsymmetricKeyPackage avec des algorithmes qui supportent de chiffrement authentifié, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.

Considérations d'autres format de clé privée

   Ce document définis la syntaxe et les sémantiques pour un type de contenu qui échange des clé privées asymétriques. Il y a 2 autres formats qui ont été utilisés pour le transport de clé privée asymétiques:

Personal Information Exchange Est une syntaxe transfert pour les informations d'identité personnelle, incluant les clés privées, certificats, divers autres secrets, et des extensions. OneAsymmetricKey, PrivateKeyInfo, et EncryptedPrivateKeyInfo peuvent être inclus dans un message p12. Les informations de clé privée, OneAsymmetricKey et PrivateKeyInfo, sont inclus dans le KeyBag BAG-TYPE P12. EncryptedPrivateKeyInfo est inclu dans le pkcs8ShroudedKeyBag BAG-TYPE P12. Dans les implémentations courantes, les extensions pfx et p12 peuvent être utilisées.
Microsoft's private-key l'extension pvk est utilisé pour des stockages locaux. pvk et p12 ne sont pas interchangeables.

   Pour extraire les information de clé privée du AsymmetricKeyPackage les couches d'encapsulations doivent être enlevées. Au minimum, la couche ContentInfo doit être enlevée. Si le AsymmetricKeyPackage est encapsulée dans une donnée signée, puis les couches SignedData et EncapsulatedContentInfo doivent également être supprimées. C'est la même chose pour EnvelopedData, EncryptedData, et AuthenticatedData. Une fois toutes les couches supprimées, il y a autant de jeux d'information de clé privée qu'il y a de structure OneAsymmetricKey. OneAsymmetricKey et PrivateKeyInfo ont la même structure, donc peuvent être sauvées en tant que fichier p8 ou copiés dans un BAG-TYPE KeyBag p12. Supprimer les couches de sécurité encapsulantes va invalider toute signature et peut exposer la clé.

Les fichiers p8 sont parfois encodés PEM, et dans ce cas utilisent l'extension pem. L'encodage PEM est soit l'encodage Base64 ou de type EncryptedPrivateKeyInfo encodé DER inclus entre:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

ou l'encodage Base64 du PrivateKeyInfo encodé DER entre:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

Media application/pkcs8

Type name: application
Subtype name: pkcs8
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographic private key
Interoperability considerations: The PKCS #8 object inside this media type MUST be DER-encoded PrivateKeyInfo.
Published specification: RFC 5958
Applications which use this media type: Any MIME-compliant transport that processes asymmetric keys.
Additional information: Magic number(s): None
File extension(s): .p8
Macintosh File Type Code(s): Person & email address to contact for further information: Sean Turner ‹turners@ieca.com›
Restrictions on usage: none
^
06 mars 2015

htmlpdflatexmanmd




rfc5280

rfc5280, rfc6818

Profile de certification et de liste de révocation de certificat d'infrastructure à clé publique X.509

Introduction

   Cette spécification fait partie d'une famille de standards pour les infrastructures à clé publique X.509 pour l'Internet.

   Cette spécification profile le format et les sémantiques des certificats et des listes de révocation de certificat pour les PKI Internet. Les procédures sont décrites pour traiter les chemins de certification dans l'environnement Internet. Finalement, les modules ASN.1 sont fournis dans l'appendice pour toutes les structures de données définies ou référencées.

La section "Exigences et hypothèses" décris les pré-requis de PKI Internet et les hypothèses qui affectent le périmètre de ce document.
La section "Aperçu de l'approche" Présentent un modèle d'architecture qui décrivent ses relations aux précédant standards IETF et ISO/IEC/ITU-T. En particulier, la relation de ce document avec les spécification PEM IETF et les document ISO/IEC/ITU-T X.509 sont décris.
La section "Profile de certificat et d'extensions de certificat" profile les certificats X.509 version 3.
La section "Profile de CRL et d'extensions de CRL" profile les CRL X.509 v2.
La section "Validation de chemin de certification" inclus les procédures de validation de chemin de certification. Ces procédures sont basée sur la définition ISO/IEC/ITU-T.

   Les procédures pour l'identification et l'encodage des clés publiques et des signatures numérique sont définis dans la rfc3279, la rfc 4055, et la rfc4491. Les implémentations de cette spécification ne sont pas obligés d'utiliser un algorithme crypto-graphique particulier. Cependant, les implémentations conformes qui utilisent les algorithmes identifiés dans la rfc3279,la rfc 4055, et la rfc 4491 doivent identifier en encoder la clé publique et les signatures numérique comme décris dans ces spécifications.

   Finalement, 2 appendices sont fournis pour aider les implémenteurs.

  Cette spécification obsolète la rfc 3280. Les différences sont résumées ici:

- Support amélioré pour les noms internationalisés, avec des règles pour l'encodage et la comparaison de noms de domaines internationalisés, Identifiant de ressources internationalisés (IRI), et de noms distinct. Ces règles sont alignés avec les règles de comparaison établies dans les rfc courantes, incluant la rfc3490, rfc3987 et la rfc 4518.
- Les section "Issuer" et "Subject" incorporent les conditions pour l'utilisation continue de schémas d'encodage de texte existant qui ont été spécifiés dans la rfc4630. Là où c'est utilisé par les PKI établies, la transition vers UTF8String pourrait poser des problème DOS basés sur les erreurs de chaînage de nom ou des traitement incorrecte de contraintes de nom.
- La section qui spécifie l'extension de certificat privateKeyUsagePeriod de la rfc 3280, mais déprécie son utilisant, a été supprimée. L'utilisation de cette extension standards ISO n'est plus dépréciée ni recommandée pour l'utilisation dans les PKI de l'Internet.
- La section Policy Mappings recommande de marquer l'extension de contraintes de stratégie comme critique. La rfc 3280 nécessitait que l'extension de mappage de stratégie soit marquée non critique.
- La section Policy Constraints nécessite que l'extension de contraintes de stratégie soit critique. la rfc 3280 permettait cette extension d'être critique ou non.
- L'extension de CRL AIA, comme spécifié dans la rfc 4325, a été ajoutée.
- Les sections extensions de CRL et extensions d'entrée de crl clarifient les règles pour manipuler les extensions de CRL et d'entrée de CRL non-reconnues, respectivement.
- La section qui spécifie l'extension d'entrée de CRL holdInstructionCode dans la rfc 3280 a été supprimée.
- L'algorithme de validation de chemin ne suit plus la criticité des extensions de stratégie de certificat dans une chaîne de certificats. Dans la rfc 3280, cette information était retourné à un tier de confiance.
- La section de considérations de sécurité adresse les risques de dépendances circulaires se produisant lors de l'utilisation de schémas https ou similaire dans les points de distribution de CRL, AIA, ou extension d'accès aux informations du sujet.
- La section de considérations de sécurité adresse les risques associés aves l'ambiguïté des noms
- La section de considérations de sécurité référence les rfc 4210 pour les procédures pour signaler les changements dans les opération de CA.

Pré-requis et hypothèses

   Le but de cette spécification est de développer un profil pour faciliter l'utilisation des certificats X.509 dans les applications Internet pour les communautés qui souhaitent utiliser la technologie X.509. De telles applications peuvent inclure WWW, les messageries électroniques, l'authentification utilisateur, et IPSec. Afin de soulager certains obstacles à l'utilisation des certificat X.509, cet document définis un profile pour promouvoir le développement de systèmes de gestion de certificat, le développement d'outils applicatifs, et d'interopérabilité déterminé par stratégie.

   Un utilisateur de certificat devrait revoir la stratégie de certificat générée par l'autorité de certification avant de faire confiance aux services d'authentification et de non-répudiation associés avec la clé publique dans un certificat particulier. À cette fin, ce standards ne prescrit pas de règles juridiques contraignantes ou de droits.

   Vu que les outils d'autorisation supplémentaires et de gestions d'attributs émergent, tels que les certificats d'attributs, il peut être approprié de limiter les attributs authentifiés qui sont inclus dans un certificat. Ces autres outils de gestion peuvent fournir des méthodes plus appropriés de transport de nombreux attributs authentifiés.

Communication et topologie

   Les utilisateurs de certificat vont opérer dans une grande variété d'environnements en respect de leur topologie de communication, spécialement les utilisateurs de messagerie électronique. Ce profile supporte les utilisateurs à faible bande passante, connectivité IP temps-réel, ou connexion à haute disponibilité. En plus, le profile permet la présence de firewall ou autre communication filtrée.

   Ce profil n'assume pas le déploiement d'un système d'annuaire X.500 ou LDAP. Le profile n'interdit pas leur utilisation; cependant, tout moyen de distribuer des certificats et CRL peut être utilisé.

Critère d'acceptabilité

   Le but d'une PKI est de répondre aux besoins de fonctions déterministes, d'identification automatisée, d'authentification, de contrôle d'accès, et d'autorisation. Le support pour cet services détermine les attributs contenus dans le certificat aussi bien que les information de contrôle auxiliaire dans le certificat tel que les données de stratégie et contraintes de chemin de certification.

Attentes des utilisateurs

   Les utilisateurs de PKI Internet sont des gens et des processus qui utilisent des clients logiciel et sont les sujets nommés dans les certificats. Ces utilisations incluent les lecteurs et rédacteurs de messages électroniques, les clients pour les navigateurs web, les serveurs web, et le gestionnaire de clé pour IPSec dans un routeur. Ce profile reconnaît les limitations des plate-formes que les utilisateurs utilisent et les limitations de la sophistication et de l'attention des utilisateurs eux-même. Cela se manifeste dans la responsabilité minimale de la configuration utilisateur (ex: les clé de CA de confiance, les règles), les contraintes d'utilisation des plate-formes explicites dans le certificat, les contraintes de chemin de certification qui protège l'utilisateur les actions malicieuses, et les applications qui automatise sensiblement les fonction de validation.

Attentes des administrateurs

   Comme avec les attentes des utilisateurs, le profile PKI de l'Internet est structuré pour supporter les individus qui opèrent généralement les CA. Fournir aux administrateurs des choix illimités augmente les chances qu'une erreur subtile d'administrateur de CA résulte en un large compromission. En outre, des choix illimités compliquent grandement le logiciel qui traite et valide les certificats crées par la CA.

Présentation de l'approche

   Ceci est une vue simplifiée du modèle architecturel assumé par les infrastructures à clé publique utilisant les spécification X.509 ( PKIX ). Les composants dans ce modèle sont:

end entity L'utilisateur de certificats PKI et/ou le système utilisateur final qui est le sujet d'un certificat.
CA Autorité de certification
RA Autorité d'enregistrement, ex. un système opérationnel pour lequel une CA délègue certaines fonctions de gestion.
CRL issuer Un système qui génère et signe les CRL
repository Un système ou une collection de systèmes distribués qui stockent les certificats et les CRL et sert de moyen de distribution aux end entity

   Les CA sont responsables de l'indication du statut de révocation des certificats qu'elles fournissent. Les informations de statut de révocation peuvent être fournis en utilisant OCSP, CRL, ou d'autres mécanismes. En général, quand les informations de statut de révocation sont fournis en utilisant les CRL, la CA est également le CRL issuer. Cependant, une CA peut déléguer cette responsabilité à une entité différente.

Noter qu'un Attribute Authority ( AA ) peut également choisir de déléguer la publication des CRL à un CRL issuer.
___+---+
___|_C_|_______________________+------------+
___|_e_|_‹--------------------›|_End_entity_|
___|_r_|_______Operational_____+------------+
___|_t_|_______transactions__________^
___|_i_|______and_management_________|__Management
___|_f_|_______transactions__________|__transactions________PKI
___|_i_|_____________________________|_____________________users
___|_c_|_____________________________v
___|_a_|_=======================__+--+------------+__==============
___|_t_|__________________________^_______________^
___|_e_|__________________________|_______________|_________PKI
___|___|__________________________v_______________|______management
___|_&_|_______________________+------+___________|_______entities
___|___|_‹---------------------|__RA__|‹----+_____|
___|_C_|__Publish_certificate__+------+_____|_____|
___|_R_|____________________________________|_____|
___|_L_|____________________________________|_____|
___|___|____________________________________v_____v
___|_R_|________________________________+------------+
___|_e_|_‹------------------------------|_____CA_____|
___|_p_|___Publish_certificate__________+------------+
___|_o_|___Publish_CRL_____________________^______^
___|_s_|___________________________________|______|__Management
___|_i_|________________+------------+_____|______|__transactions
___|_t_|_‹--------------|_CRL_Issuer_|‹----+______|
___|_o_|___Publish_CRL__+------------+____________v
___|_r_|______________________________________+------+
___|_y_|______________________________________|__CA__|
___+---+______________________________________+------+

Certificat X.509 Version 3

   Les utilisateurs d'une clé publique nécessitent la confidentialité de la clé privée associée qui est possédée par le bon sujet ( personne ou système ) avec laquelle un mécanisme de chiffrement ou de signature numérique sera utilisé. Cette confidentialité est obtenue via l'utilisation de certificats à clé publique, qui sont des structures de donnée qui lie des valeurs de clés publique à des sujets. La liaison est affirmée en ayant un CA de confiance qui signe numériquement chaque certificat. La CA peut baser cette affirmation sur les moyens techniques (ex: preuve de possession via un protocole de challenge/réponse), la présentation de la clé privée, ou sur une affirmation par le sujet. Un certificat a une durée de vie limitée, qui est indiquée dans son contenu signé. Parce que la signature du certificat et la du validité peuvent être vérifiés indépendamment par un client, les certificats peuvent être distribués via des communication et des systèmes serveurs non-sûres, et peuvent être mis en cache dans des stockages dans des systèmes non-sûres.

   l'ITU-T X.509 ou l'ISO/IEC 9594-8, qui a été publié en 1988 comme partie des recommandations des annuaires X.500, définis un format de certificat standard. Le format de certificat dans le standard 1988 est appelé le format version 1 (v1). Quand X.500 a été révisé en 1993, 2 champs ont été ajoutés, résultant en un format version 2 (v2).

   Les rfc PEM, publiés en 1993, incluent les spécifications pour une infrastructure à clé publique basés sur X.509 v1 (rfc 1422). L'expérience a montré que les déploiement rfc 1422 faits avec les formats v1 et v2 étaient défaillant dans de nombreux aspects. Plus important, de nombreux champs étaient nécessaires pour gérer les information que le concept et l'implémentation de PEM a démontré la nécessité. En réponse, l'ISO/IEC, l'ITU-T, et ANSI X9 on développés le format de certificat version 3 (v3). Il étend le format v2 en ajoutant les champs d'extension additionnels. Les types de champ d'extension particulier peuvent être spécifiés dans des standards ou peuvent être définis et enregistrés par une organisation ou une communauté. En Juin 1996, la standardisation du format de base v3 a été complété.

   L'ISO/IEC, l'ITU-T, et ANSI X9 ont également développés des extensions standard développés pour l'utilisation dans le champs d'extensions v3. Ces extensions peuvent transmettre des données telles des informations d'identification de sujet additionnels, des information d'attribut de clé, informations de stratégie, et de contraintes de chemin de certification.

   Cependant, les extensions standard e l'ISO/IEC, l'ITU-T, et de l'ANSI X9 étaient très générales dans leur utilisation. Pour développer des implémentations intéropérable des système X.509 v3 pour l'Internet, il est nécessaire de spécifier un profile pour utiliser les extensions X.509 v3 adaptés pour l'Internet. C'est un des objectifs de ce document pour spécifier un profile pour WWW, les messages électroniques, et les application IPSec. Les environnements avec les pré-requis additionnels peuvent construire par-dessus ce profil pour le remplacer.

Chemins de certification et confiance

   Un utilisateur d'un service de sécurité nécessitant la connaissance d'une clé publique, a besoin généralement d'obtenir et de valider un certificat contenant la clé publique requise. Si l'utilisateur de clé publique ne possède pas une copie fiable de la clé publique de la CA qui a signé le certificat, le nom de la CA et les information liées (tel que la période de validité, ou les contraintes de nom), alors il peut nécessiter un certificat additionnel pour obtenir la clé publique. En général, une chaîne de plusieurs certificats peuvent être nécessaires, comprenant un certificat du propriétaire de la clé publique ( l'entité finale) signée par une CA, et 0 ou plusieurs certificats de CA signés par d'autres CA. De telles chaînes, appelées chemin de certification, sont requis parce qu'un utilisateur de clé publique est seulement initialisé avec un nombre limité de clé publique de CA.

   Les CA peuvent être configurées de différentes manières pour que les utilisateurs de clé publique soient capable de trouver les chemins de certification. Pour PEM, la rfc 1422 définis une structure hiérarchique rigide de CA. Il y a 3 types d'autorité de certification PEM:

(a) Internet Policy Registration Authority (IPRA): cette autorité, qui opère sous les auspices de l'Internet Society, agit comme le niveau racine de la hiérarchie de certification PEM, au niveau 1. Il fournis des certificats uniquement pour le niveau suivant d'autorités, les PCA. Tous les chemins de certification commencent avec l'IPRA.
(b) Policy Certification Authorities (PCAs): les PCA sont au niveau 2 de la hiérarchie, chaque PCA est certifié par l'IPRA. Un PCA devrait établir et publier un état de sa stratégie, avec respect de certifier des utilisateurs ou des autorités de certification subordonnés. Des PCA distincts ont pour objectifs de satisfaire différents besoins utilisateurs. Par exemple, un PCA peut supporter les besoins de messages électroniques des organisations commerciales, et un autre PCA peut avoir une stratégie plus stricte conçue pour satisfaire les besoins légaux des signatures numériques.
(c) Les autorités de certification (CA): les CA sont au niveau 3 de la hiérarchie et peuvent également être à des niveaux inférieurs. Ceux de niveau 3 sont certifiés par les PCA. Les CA représentent, par exemple, des organisations particulières, les unités organisationelles particulières, ou des zones géographiques particulières.

   La rfc 1422 a en outre une règle de subordination de nom, qui nécessite qu'une CA peut seulement fournir des certificats pour des entités dont les noms sont subordonnés au nom de la CA elle-même, le trust associé avec un chemin de certification PEM est impliqueé par le nom du PCA. La règle de subordination de nom s'assure que les CA sous le PCA sont contraint sensiblement au jeu d'entité subordonnés qu'ils peuvent certifier. Les systèmes d'utilisateurs de certificat sont capable de vérifier mécaniquement que la règle de subordination de nom a été suivie.

   La rfc 1422 utilise le format de certificat X.509 v1. Les limitations de cette version impose de nombreuses restrictions structurelles pour associer clairement les information de stratégie ou restreindre l'utilité des certificats. Ces restrictions incluent:

(a) Un hiérarchie "top-down", avec tous les chemins de certifications commençant depuis IPRA
(b) Une règle de subordination de nom qui restreints les noms des sujets des CA
(c) L'utilisation du concept PCA, qui nécessite la connaissance de tous les PCA individuells pour construire la logique de vérification de la chaîne de certification.

   Avec X.509 v3, la plupart des pré-requis adressés par la rfc1422 peuvent être adressés en utilisant les extensions de certificats, sans avoir à restreindre les structures CA utilisées. En particulier, les extensions de certificat liées aux stratégies de certificat évitent les besoins de PCA et les extensions de contraintes évitent les besoins de règle de subordination de nom. En résultat, ce document supporte une architecture plus flexible, incluant:

(a) Les chemins de certification commencent avec une clé publique d'une CA dans le domaine de l'utilisateur, ou avec la clé publique de la racine d'une hiérarchie. Commencer avec la clé publique d'une CA dans le domaine de l'utilisateur a certains avantages. Dans certains environnements, le domaine local est le plus sûr.
(b) Les contraintes de nom peuvent être imposés via l'inclusion explicite d'une extension de contrainte de noms dans un certificat, mais n'est pas requis.
(c) Les extensions de stratégie et les mappages de stratégie remplacent le concept de PCA, qui permet un plus haut degré d'automatisation. L'application peut determiner si le chemin de certification est acceptable basé sur le contenu du certificat au lieu d'un connaissance à priori des PCA. Cela permet d'automatiser le traitement des chemins de certification.

   X.509 v3 inclus également une extension qui identifie le sujet d'un certificat comme étant une CA ou une entité finale, réduisant la dépendance sur les informations out-of-band démandé dans PEM.

   Cette spécification couvre 2 classes de certificats: les certificats CA et les certificats d'entité finale. Les certificats CA peuvent être divisés en 3 classes: cross-certificats, certificats auto-fournis et certificat auto-signés.

        Les Cross-certificats sont des certificats CA dans lequel le fournisseur et les sujets sont des entités différentes. Les Cross-certificats décrivent une relation de confiance entre les 2 CA.
        Les certificats auto-fournis sont des certificat CA dans lequel le fournisseur et le sujet sont la même entité. Les certificats auto-fournis sont générés pour supporter les changements dans la stratégie ou les opérations.
        Les certificats auto-signés sont des certificat auto-fournis où la signature numérique peut être vérifiée par la clé publique lié dans le certificat. Les certificats auto-signés sont utilisé pour transporter une clé publique à utiliser au début des chemins de certification.

   Les certificats d'entité finale sont fournis aux sujets qui ne sont pas autorisés à fournir de certificats.

Révocation

   Quand un certificat est fournis, il est prévu pour être utilisé pour toute sa période de validité. Cependant, diverses circonstances peuvent causer un certificat à devenir invalide avant l'expiration de la période de validité. De telles circonstances incluent le changement de nom, changement d'association entre le sujet et la CA (ex: un employé termine sont emploie avec une organisation ), et la compromission de la clé privée associée. Dans de telles circonstances, la CA doit révoquer le certificat.

   X.509 définis une méthode de révocation de certificat. Cette méthode implique que chaque CA fournis périodiquement une structure de données appelée une liste de statut de révocation. Une CRL est une liste horodatée identifiant les certification révoqués. qui est signée par une CA ou un fournisseur de CA et est librement accessible dans de dépôt publique. Chaque certificat révoqué est identifié dans une CRL par son numéro de série. Quand un système utilisant les certificats utilise un certificat ( par exemple pour vérifier la signature numérique d'un utilisateur ), ce système ne vérifie pas seulement la signature et la validité du certificat mais récupère également une CRL utilisable et récente et vérifie que le numéro de série n'est pas dans cette CRL

   La signification de "utilisable et récente" peut varier avec la stratégie locale, mais signifie généralement la plus récente CRL fournis. Une nouvelle CRL est fournie sur une base régulière. Une entrée est ajoutée à la CRL comme partie de la prochaine mise à jours suivant la notification de la révocation. Une entrée ne doit pas être supprimée de la CRL jusqu'à ce qu'elle apparaisse dans une dans une CRL régulière fournie au-delà de la période de validité du certificat.

   Un avantage de cette méthode de révocation est que les CRL peuvent être distribués exactement de la même manière que les certificats eux-mêmes, via des serveurs et des communications non-sûres.

   Une limitation de la méthode de révocation CRL, utilisant des communications et des serveurs non sûrs, et que la granularité de temps de révocation est limitée à la période d'émission de la CRL. Par exemple, si une révocation est reportée maintenant, cette révocation ne sera pas notifiée tant qu'une nouvelle CRL n'est pas générée.

   Comme avec le format de certificat X.509 v3, pour pouvoir faciliter l'interopérabilité des implémentation, le format de CRL v2 X.509 doit être profilé pour l'utilisation sur l'Internet. C'est un des objectifs de ce document. Cependant, ce profile ne nécessite pas l'émission des CRL. Les formats de message et les protocoles supportant les notification de révocation on-line sont définis dans d'autres spécifications PKIX. Les méthodes on-line de notification de révocation peuvent être applicables dans certains environnements comme une alternative à la CRL X.509. La vérification de révocation On-line peut significativement réduire la latence entre une révocation et la distribution de l'information. Une fois que la CA acceptes une révocation comme authentique et valide, toute requête au service on-line va refléter correctement l'information de révocation.

   Cependant, ces méthodes imposent de nouveaux pré-requis de sécurité: le validateur de certificat a besoin de faire confiance au service de validation on-line, alors que le dépôt n'a pas besoin de l'être.

Protocoles opérationnels

   Les protocoles opérationnels sont requis pour délivrer les certificats et les CRL ( ou les informations de statut ) aux système client qui utilisent les certificats. Des dispositions sont nécessaires pour divers moyens de délivrer des certificats et les CRL, incluant les procédures de distribution basées sur LDAP, HTTP, FTP, et X.500. Les protocoles opérationnels supportant ces fonctions sont définies dans d'autres spécification PKIX. Ces spécifications peuvent inclurent les définition de formats de message et des procédures pour supporter tous les environnements opérationnel, incluant les définitions et les référence aux types de contenu MIME appropriés.

Protocoles de gestion

   Les protocoles de gestion sont requis pour supporter les interactions on-line entre les utilisateurs de PKI et les entités de gestion. Par exemple, un protocole de gestion peut être utilisé entre une CA et un système client avec lequel une paire de clé est associée, ou entre 2 CA qui se cross-certifient entre-eux. Le jeu de fonctions qui nécessite potentiellement d'être supportés par les protocoles de gestion incluent:

(a) Enregistrement: c'est la procédure par laquelle un utilisateur se fait connaître à la CA ( directement, ou via un RA ), avec que la CA ne lui fournisse un ou plusieurs certificats.
(b) Initialisation: Avant qu'un système client puisse opérer de manière sécurisé, il est nécessaire d'installer les clés qui ont la relation appropriée avec les clés stockées ailleurs dans l'infrastructure. Par exemple, le client a besoin d'être initialisée de manière sécurisée avec la clé publique et d'autres informations des CA de confiance, pour être utilisées dans les validation de chemins de certification. De plus, un client a généralement besoin d'être initialisé avec ses propres paires de clés.
(c) Certification: C'est le processus dans lequel une CA fournie un certificat pour une clé publique de l'utilisateur, et retourne ce certificat au système client de l'utilisateur et/ou poste ce certificat dans un dépôt.
(d) Récupération de paire de clé: En option, les clés du client (ex: la clé privée de l'utilisateur ) peut être sauvegardée par une CA ou un système de sauvegarde de clé. Si un utilisateur a besoin de récupérer ces clés ( par exemple lors de la perte du mot de passe ou la perte de la clé ), un protocole d'échange on-line peut être nécessaire pour de telles récupérations.
(e) Mise à jours de paires de clé: toutes les paires de clé ont besoin d'être mises à jours régulièrement, par ex. remplacées avec une nouvelle paire de clé, et de nouveaux certificats fournis.
(f) Demandes de révocation: Une personne autorisée avertit une CA d'une situation anormale nécessitant la révocation d'un certificat.
(g) cross-certification: 2 CA échangent des informations utilisées pour établir une certification croisée. Un cross-certificat est un certificat fournis par une CA à une autre qui contient une clé de signature CA utilisée pour fournir des certificats.

   Noter que les protocoles on-line ne sont pas la seul manière d'implémenter les fonction ci-dessus. Pour toutes les fonctions, il y a des méthodes off-line pour accomplir de même résultat, et cette spécification ne mandate pas l'utilisation des protocoles on-line. Par exemple, quand des jetons hardware sont utilisés, beaucoup de fonctions peuvent être faites comme partie de la livraison du jeton physique. De plus, certaines fonctions ci-dessus peuvent être combinées dans un seul protocole d'échange. En particulier, les fonctions d'enregistrement, d'initialisation et de certification peuvent être combinés en un seul protocole d'échange.

   Les séries PKIX des spécifications définissent un jeu de formats de messages standard pour supporter les fonction ci-dessus. Les protocoles pour transporter ces messages dans différents environnement (ex: email, transfert de fichier, et www ) sont décris dans ces spécifications.

Profile de certificat et d'extensions de certificat

   Cette section présente un profile pour les certificats à clé publique qui favorisent l'interopérabilité et une PKI ré-utilisable. Cette section est basée sur le format de certificat X.509 v3 et les extensions de certificats standards définis dans X.509. Les document ISO/IEC et ITU-T utilisent la version 1997 de ASN.1; alors que ce document utilise la syntaxe ASN.1 1988, le certificat et les extensions standard encodés sont équivalents. Cette section définis également des extensions privées nécessaires pour supporter une PKI pour la communauté Internet.

   Les certificats peuvent être utilisés dans une grande variété d'applications et d'environnements couvrant un large spectre d'interopérabilité et de pré-requis opérationnel et d'assurance. Le but de ce document est d'établir une base commune pour des applications générique nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation des certificats X.509 v3 pour les messages électronique, IPSec, et les applications web.

Champs de certificat de base

La syntaxe de base des certificats X.509 v3 est comme suit. Pour le calcule de la signature, les données à signer sont encodés en utilisant DER. L'encodage DER ASN.1 est un système d'encodage de tag, longueur, et valeur pour chaque élément.
Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }
    
TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3.
    subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3
    extensions [3] EXPLICIT Extensions OPTIONAL
        -- Si présent, version doit être v2 ou v3
}
    
    Version ::= INTEGER { v1(0), v2(1), v3(2) }
    
CertificateSerialNumber ::= INTEGER
    
Validity ::= SEQUENCE {
    notBefore Time,
    notAfter Time }
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }
    
UniqueIdentifier ::= BIT STRING
    
SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    subjectPublicKey BIT STRING }
    
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
    
Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING
         -- contient l'encodé DER d'une valeur ASN.1 correspondant au type d'extension identifié par extnID
}

Champs de certificat

   Certificate est une séquence de 3 champs requis. Les champs sont décris en détail dans les section suivantes.

tbsCertificate Le champ contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, et d'autres informations associées. Les champs sont décris plus bas. tbsCertificate inclue généralement des extensions, qui sont décris plus bas également.
signatureAlgorithm Le champ signatureAlgorithm contient l'identifiant pour l'algorithme cryptographique utilisé par la CA pour signer ce certificat. les rfc 3279, rfc 4055, et rfc 4491 listent les algorithmes de signature supportés, mais d'autres algorithmes peuvent être également supportés.

Un identifiant d'algorithme est définis par la structure ASN.1 suivante:
AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameters ANY DEFINED BY algorithm OPTIONAL }

   L'identifiant d'algorithme est utilisé pour identifier un algorithme cryptographique. L'identifiant d'objet identifie l'algorithme (tel que DSA avec SHA-1). Le contenu des paramètres optionnels varient en fonction de l'algorithme identifié. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertificate.

signatureValue Le champ signatureValue contient une signature numérique calculée sur l'encodé DER ASN.1 de tbsCertificate, qui est utilisé en entrée de l'algorithme de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signature. Les détails de ce processus sont spécifiés pour chaque algorithme listés dans les rfc3279, rfc4055, et rfc4491.

   En générant cette signature, une CA certifie la validité de l'information dans le champ tbsCertificate. En particulier, la CA certifie la liaison entre la clé publique et le sujet du certificat.

TBSCertificate

   La séquence TBSCertificate contient les informations associées avec le sujet du certificat et la CA qui l'a fournie. Tous TBSCertificate contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, un numéro de version, et un numéro de série; certains peuvent optionnellement contenir des champs d'identifiant unique. Le reste de cette section décris la syntaxe et les sémantiques de ces champs. Un TBSCertificate inclus généralement des extensions. Les extensions pour les PKI de l'Internet sont décris plus bas.

Version

   Ce champ décris la version du certificat encodé. Quand les extensions sont utilisée, comme prévu dans ce profile, la version doit être 3 (valeur 2). Si aucune extension n'est présente, mais qu'un UniqueIdentifier est présent, la version devrait être 2 (valeur 1); cependant, la version peut être 3. Si seul les champs de base sont présents, la version devrait être 1 ( la valeur est omise du certificat); cependant, la version peut être 2 ou 3.

   Les implémentations devraient être préparés à accepter n'importe quel numéro de version. Au minimum, les implémentations conformes doivent reconnaître la version 3. La génération de certificats version 2 n'est pas prévue pour les implémentations de ce profile.

Serial Number

   Le numéro de série doit être un entier positif assigné par la CA pour chaque certificat. Il doit être unique pour chaque certificat fournis par une CA donnée (ex: le nom du fournisseur et le numéro de série identifie un certificat de manière unique ). Les CA doivent forcer le serialNumber à être un entier non-négatif.

   Les numéros de série peuvent être prévus pour contenir des entiers long. Les utilisateurs de certificat doivent être capable de manipules des valeurs jusqu'à 20 octets. Les CA conformes ne doivent pas utiliser de valeur serialNumber supérieur à 20 octets.

   Note: les CA non-conforme peuvent fournir des certificats avec des numéro de série négatifs ou 0. Les utilisateurs de certificat devraient être préparés à manipuler de tels certificats.

Signature

   Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé par la CA pour signer le certificat. Ce champ doit contenir le même identifiant d'algorithme que le champ signatureAlgorithm dans la séquence Certificate. Le contenu du champ optionnel parameters varie en fonction de l'algorithme.

Issuer

Le champ issuer identifie l'entité qui a signé et fournis le certificat. Le champ issuer doit contenir un dn non-vide. Le champ issuer est définis comme nom de type X.501. Le nom est définis par les structures ASN.1 suivantes:
Name ::= CHOICE { -- un seul possible --
    rdnSequence RDNSequence }
    
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
    
RelativeDistinguishedName ::=
    SET SIZE (1..MAX) OF AttributeTypeAndValue
    
AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue }
    
AttributeType ::= OBJECT IDENTIFIER
    
AttributeValue ::= ANY -- DEFINED BY AttributeType
    
DirectoryString ::= CHOICE {
    teletexString TeletexString (SIZE (1..MAX)),
    printableString PrintableString (SIZE (1..MAX)),
    universalString UniversalString (SIZE (1..MAX)),
    utf8String UTF8String (SIZE (1..MAX)),
    bmpString BMPString (SIZE (1..MAX)) }

   Le nom décris un nom hiérarchique composé d'attributs, tel que le nom du pays, et les valeurs correspondantes, tel que US. Le type du composant AttributeValue est déterminé par le AttributeType; en général il sera un DirectoryString.

   Le type DirectoryString est définis comme choix de PrintableString, TeletexString, BMPString, UTF8String, et UniversalString. Les CA conformes à ce profile doivent utiliser l'encodage de DirectoryString soit PrintableString soit UTF8String, avec 2 exceptions. Quand les CA on précédemment fournis des certificats avec les champs issuer avec attributs encodés en utilisant TeletexString, BMPString, ou UniversalString, alors la CA peut continuer à utiliser ces encodages de DirectoryString pour préserver la compatibilité en arrière. Également, les nouvelles CA qui sont ajoutée à un domaine où des CA existantes fournissent des certificat avec les champs issuer avec des attribut utilisant TeletexString, BMPString, ou UniversalString peuvent encoder les attributs qu'ils partagent avec les CA existantes en utilisant les même encodages que les CA existantes.

   Comme mentionné plus haut, les dn sont composés d'attributs. Cette spécification ne restreint pas le jeu de type d'attribut qui peuvent apparaître dans le nom. Cependant, les implémentations conformes doivent être préparées à recevoir des certificats avec des noms de fournisseur contenant le jeu de type d'attributs définis ci-dessous. Cette spécification recommande le support pour des type d'attributs additionnels.

   Les jeux standard d'attributs ont été définis dans X.520. Les Implémentations de cette spécification doit être préparée à recevoir les types d'attribut standard suivant dans le noms de fournisseur et du sujet:

- country
- organization
- organizational unit
- distinguished name qualifier
- state or province name
- common name (ex: "Susan Housley")
- serial number

   En plus, les implémentations de cette spécification devraient être préparés à recevoir le type d'attributs standard suivant dans les noms de fournisseur et de sujet:

- locality
- title
- surname
- given name
- initials
- pseudonym
- generation qualifier (ex: "Jr.", "3rd", ou "IV")

   La syntaxe et les identifiant d'objets associés pour ces types d'attribut sont fournis dans les modules ASN.1 dans l'appendice A. En plus, les implémentations de cette spécification doivent être préparées à recevoir l'attribut domainComponent, comme définis dans la rfc4519. Le DNS founis un système de label de ressource hiérarchique. Cet attribut fournis un mécanisme pour les organisations qui souhaitent utiliser les DN en parallèle à leurs noms DNS. Ce n'est pas un remplacement pour le composant dNSName des extensions de nom alternative. Les implémentations ne sont pas obligés de convertir de tels noms en noms DNS. La syntaxe et OID associé pour cet type d'attribut sont fournis dans les modules ASN.1 dans l'appendice 1. Les règles pour l'encodage des noms de domaines internationalisés à utiliser avec le type d'attribut domainComponent sont spécifiés plus bas.

   Les utilisateurs de certificat doivent être préparés à traiter les champs issuer et subject pour effectuer un chaînage de nom pour la validation de chemin de certification. Le chaînage de noms est effectué en faisant correspondre le dn issuer dans un certificat avec le sujet dans un certificat CA. Les règles pour comparer les dn sont spécifiés plus loin dans ce document. Si les noms dans les champ issuer et subject dans un certificat correspond aux règles spécifiés plus bas, le certificat est auto-signé.

Validity

   La période de validité de certificat est un intervalle de temps durant lequel la CA garantie qu'elle va maintenir les informations sur le statut du certificat. Le champ est représenté comme séquence de 2 dates: la date à laquelle la période de validité commence (notBefore) et la date à laquelle la période de validité se termine (notAfter). Ces 2 dates peuvent être encodés en UTCTime ou GeneralizedTime.

   Les CA conformes à ce profile doivent toujours encoder les dates de validité de certificat jusqu'à l'année 2049 en UTCTime; les de date en 2050 ou ultérieur en GeneralizedTime. Les applications conformes doivent être capable de traiter les dates de validité qui sont encodés en UTCTime ou en GeneralizedTime.

   La période de validité pour un certificat est la période de temps depuis notBefore jusqu'à notAfter, inclus.

   Dans certaines situations, les périphériques donnent des certificats pour lesquels aucune date d'expiration correcte ne peut être assignée. Par exemple, un périphérique pourrait fournir un certificat qui lie son modèle et un numéro de série à sa clé publique; un tel certificat est prévu pour être utilisé pour toute la durée de vie du périphérique.

   Pour indiquer qu'un certificat n'a pas de date d'expiration, notAfter devrait être assigné à la valeur GeneralizedTime 99991231235959Z.

   Quand le fournisseur n'est pas capable de maintenir les informations de statut jusqu'à la date notAfter (incluant le cas où notAfter vaut 99991231235959Z), le fournisseur doit s'assurer qu'aucun chemin de certification valide n'existe pour le certificat après que la maintenance du statut d'information soit terminée. Cela peut être fait par l'expiration ou la révocation de tous les certificats CA contenant la clé publique utilisée pour vérifier la signature dans le certificat et d'arrêter d'utiliser la clé publique utilisée pour vérifier la signature dans le certificat.

UTCTime

   Le type de temps universelle UTCTime, est un type ASN.1 standard prévu pour représenter les dates et le temps. UTCTime spécifie l'année via 2 chiffres et le temps est spécifié avec une précision d'une minute ou une seconde. UTCTime inclus soit Z (pour Zulu, ou Greenwich Mean Time) ou un temps différentiel.

   Pour ce profile, les valeurs UTCTime doivent être exprimées en GMT ( Zulu ) et doivent inclurent les secondes ( YYMMDDHHMMSSZ ), même que le nombre de secondes est 0. Les systèmes conforme doivent interpréter le champ année comme suit:

- Si YY est supérieur ou égale à 50, l'année devrait être interprété comme 19YY.
- Si YY est inférieur à 50, l'année dervait être interprété comme 20YY.

GeneralizedTime

   Le type de temps généralisé, GeneralizedTime, est un type ASN.1 standard pour des représentation à précision variable du temps. Optionnellement, le champ GeneralizedTime peut inclure une représentation du temps différentiel entre GMT et la local.

   Pour ce profile, les valeurs GeneralizedTime doivent être exprimées en GMT (Zulu) et doivent inclure les secondes (YYYYMMDDHHMMSSZ), même si le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Subject

   Le champ subject identifie l'entité associée avec la clé publique stockée dans le champ de clé publique. Le nom du sujet peut être placé dans le champ subject et/ou dans l'extension SubjectAltName. Si le sujet est une CA (ex: l'extension de contraintes de base et présent et la valeur de cA est TRUE), alors le champ subject doit être renseigné avec un dn non-vide corrspondant au contenu du champs issuer dans tous les certificats émis par la CA. Si le sujet est un fournisseur de CRL (ex: l'extension utilisation de clé est présent et la valeur de cRLSign est TRUE), alors le champ subject doit être populé avec un dn non-vide correspondant au contenu du champ issuer dans toutes les CRL émise par le fournisseur de CRL. Si les informations de nommage du sujet sont présent seulement dans l'extension subjectAltName ( ex: une clé liée seulement à une adresses email ou une URI), alors le sujet doit être une séquence vide et l'extension subjectAltName doit être critique.

   Quand il est non-vide, le champ subject doit contenir un dn X.500. Le dn doit être unique pour chaque entité sujet certifié par une CA comme définie dans le champ issuer. Une CA peut fournir plus d'un certificat avec le même dn à la même entité sujet.

   Le champ subject est définis comme nom de type X.501. Les pré-requis d'implémentation pour ce champ sont ceux définis pour le champ issuer. Les implémentations de cette spécification doivent être préparés à recevoir des noms de sujet contenant les types d'attributs requis pour le champ issuer. Les implémentations de cette spécification devraient être préparés à recevoir des noms de sujet contenant les types d'attributs recommandés pour le champ issuer. La syntaxe et les identifiant d'objet associés pour ces types d'attributs sont fournis dans les modules ASN.1 en appendice 1.

   Les implémentations de cette spécification peuvent utiliser les règles de comparaison pour traiter les types d'attributs non-familier (ex: pour le chaînage de noms) dont les valeurs d'attributs utilisent une des options d'encodage de DirectoryString. Les comparaisons binaires devraient être utilisées quand les type d'attribut non-familiers incluent des valeurs d'attribut avec des options d'encodage autre que ceux trouvés dans DirectoryString. Cela permet aux implémentations de traiter les certificats avec des attributs non-familier dans le sujet.

   En encodant des valeurs d'attribut de type DirectoryString, les CA conformes doivent utiliser PrintableString ou UTF8String, avec les exceptions suivant:

(a) Quand le sujet du certificat est une CA, le champ subject doit être encodé de la même manière que s'il est encodé dans le champ issuer dans tous les certificat qu'elle fournis. Donc, si la CA encode les attributs dans les champs issuer des certificat qu'elle fournis en utilisant TeletexString, BMPString, ou UniversalString, alors le champ subject des certificats fournis par cette CA doit utiliser le même encodage.
(b) Quand le sujet du certificat est un fournisseur de CRL, le champ subject doit être encodé de la même manière qu'il est encodé dans le champ issuer dans toutes les CRL fournies par le fournisseur de CRL.
(c) TeletexString, BMPString, et UniversalString sont inclus pour la compatibilité en arrière, et ne devraient pas être utilisés pour les certificats pour les nouveaux sujets. Cependant, ces types peuvent être utilisés dans les certificats où le nom a été précédemment établit, incluant les cas dans lequel un nouveau certificat est fournis à un nouveau sujet où les attributs à encoder ont été précédemment établis dans les certificats fournis à d'autres sujets. Les certificats utilisateur devraient être préparés à recevoir les certificats avec ces types.

   Les implémentations anciennes existent où une adresse de messagerie électronique est embarquée dans le sujet comme emailAddress (rfc2985). La valeur d'attribut pour emailAddress est de type IA5String pour permettre l'inclusion du caractère '@' qui ne fait pas partie du jeu de caractère PrintableString. Les valeurs de l'attribut emailAddress sont sont pas sensibles à la casse.

   Les implémentations conformes générant de nouveaux certificat avec des adresse email doivent utiliser le rfc822Name dans l'extension de nom alternative du sujet pour décrire de telles identités. L'inclusion simultanée de l'attribut emailAddress dans le sujet pour supporter les anciennes implémentations est dépréciée, mais permise.

Subject Public Key Info

   Ce champ est utilisé pour gérer la clé publique et identifier l'algorithme avec lequel la clé est utilisée (ex: RSA, DSA, ou DH). L'algorithme est identifié en utilisant la structure AlgorithmIdentifier. Les identifiant d'objet pour les algorithmes supportés et les méthodes pour l'encodage de la clé publique (clé publique et paramètres) sont spécifiés dans les rfc3279, rfc4055, et rfc4491.

Unique Identifiers

   Ces champs doivent seulement apparaître si la version est 2 ou 3. Les identifiant uniques du sujet et du fournisseur sont présent dans le certificat pour gérer la possibilité de réutiliser les noms du sujet et/ou fournisseur dans le temps. Ce profile recommande que les noms ne soient pas réutilisés pour différentes entités et que les certificats Internet n'utilisent pas les identifiant uniques. Les CA conformes à ce profile ne doivent pas générer de certificats avec des identifiants uniques. Les applications conformes à ce profile doivent être capable de lire les certificats qui incluent des identifiants uniques, mais il n'y a pas de pré-requis de traitement associés avec les identifiant uniques.

Extensions

   Ce champ doit seulement apparaître si la version est 3. Si présent, ce champ est une séquence d'une ou plusieurs extensions de certificat.

Extensions de certificat

   Les extension définies pour les certificats X.509 v3 fournissent une méthode pour associer des attributs additionnels avec les utilisateurs ou les clés publiques et pour gérer les relations entre les CA. Le format de certificat X.509 v3 permet également aux communautés de définir des extensions privées pour gérer l'unicité des informations de ces communautés. Chaque extension dans un certificat peut être soit critique soit non-critique. Un système utilisant les certificats doit rejeter le certificat s'il rencontre une extension critique qu'il ne reconnaît pas ou une extension critique qui contient des informations qu'il ne peut pas traiter. Une extension non-critique peut être ignorée si elle n'est pas reconnue, mais doit être traitée si elle est reconnue. Les section suivantes présentent les extensions recommandées utilisée avec les certificats Internet et les emplacements standards pour les informations.

   Les communautés peuvent choisir d'utiliser des extensions additionnels, cependant, la prudence doit être de mise en adoptant des extension critiques dans les certificats qui peuvent empêcher leur utilisation dans un contexte général.

   Chaque extension inclus un OID et une structure ASN.1. Quand une extension apparaît dans un certificat, l'OID apparaît comme champ extnID et l'a structure encodée DER ASN.1 est la valeur de la chaîne d'octets extnValue. Un certificat ne doit pas inclure plus d'une instance d'une extension particulière. Par exemple, un certificat peut contenir seulement une extension d'identifiant de clé d'autorité. Une extension inclus le booléen critical, avec une valeur par défaut à FALSE. Le texte pour chaque extension spécifie les valeurs acceptable pour le champ critical pour les CA conformes à ce profile.

   Les CA conformes doivent supporter les identifiant de clé, les contraintes de base, l'utilisation de clé, et les stratégie de certificat. Si les CA fournissent des certificats avec une séquence vide pour le champ sujet, la CA doit supporter l'extension de noms alternatifs du sujet. Le support pour les extensions restantes est optionnel. Les CA conformes peuvent supporter les extension qui ne sont pas identifiés dans cette spécification; les fournisseurs de certificats sont prévenus que marquer de telles extensions comme critique peut inhiber l'interopérabilité.

   Au minimum, les applications conformes à ce profile doivent reconnaître les extensions suivantes: utilisation de clé, stratégie de certificat, contraintes de base, contraintes de nom, contraintes de stratégie, utilisation de clé étendue, et inhibit anyPolicy. En plus, les applications conformes à ce profile devraient reconnaître les extensions d'identifiant de clé du sujet et de l'autorité, et les mappages de stratégie.

Extensions standard

Cette section identifie les extensions de certificat standard définis dans X.509 pour l'utilisation dans les PKI de l'Internet. Chaque extension est associée avec un OID définis dans X.509. Ces OID sont membres de id-ce arc, qui est définis:
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Authority Key Identifier

   L'extension d'identifiant de clé de l'autorité fournis un moyen d'identifier la clé publique correspondant à la clé privée utilisée pour signer un certificat. Cette extension est utilisée où un fournisseur a plusieurs clé de signature (soit dû à plusieurs paires de clé concurrentes, soit à cause d'un changement de clé). L'identification peut être basée sur l'identifiant de clé ( le subject key identifier dans le certificat du fournisseur ) ou le nom du fournisseur et un numéro de série.

   Le champ keyIdentifier de l'extension authorityKeyIdentifier doit être inclus dans tous les certificats générés par les CA conformes pour faciliter la construction de chemin de certification. Il y a une exception: là où une CA distribue sa clé publique sous la forme d'un certificat auto-signé, l'identifiant de clé d'autorité peut être omise. La signature d'un certificat auto-signé est générée avec la clé privée associée avec la clé publique du sujet du certificat. Dans ce cas, le sujet et les identifiants de clé d'autorité seraient identiques, mais seul l'identifiant de clé du sujet est nécessaire pour construire le chemin de validation.

   La valeur du champ keyIdentifier devrait être dérivé de la clé publique utilisée pour vérifier la signature du certificat ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis une clé publique sont décris dans la section suivante. Là où un identifiant de clé n'a pas été précédemment établis, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou l'utilisation de méthodes similaires qui utilisent un algorithme de hashage différent. Là où un identifiant de clé a été précédemment établis, la CA devrait utiliser l'identifiant établis précédemment.

Ce profile recommande le support pour la méthode d'identifiant de clé par tous les utilisateurs de certificat. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
    
AuthorityKeyIdentifier ::= SEQUENCE {
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    authorityCertIssuer [1] GeneralNames OPTIONAL,
    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
    
KeyIdentifier ::= OCTET STRING

Subject Key Identifier

   L'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats qui contiennent une clé publique particulière.

   Pour simplifier la construction de chemin de certification, cette extension doit apparaître dans tous certificats CA conformes, c'est à dire, tous les certificats incluant l'extension de contraintes de base où la valeur de cA est TRUE. Dans les certificats de CA conformes, la valeur de l'identifiant de clé du sujet doit être la valeur placée dans le champ d'identifiant de clé de l'extension de clé d'autorité des certificats fournis par le sujet de ce certificat. Les applications ne sont pas obligées de vérifier que les identifiants de clé correspondent en validant le chemin de certification.

   Pour les certificats de CA, les identifiants de clé du sujet devraient être dérivés de la clé publique ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis la clé publique sont:

(1) keyIdentifier est composé d'un hash SHA-1 160-bits de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).
(2) keyIdentifier est composé d'un champ de type 4-bits avec la valeur 0100, suivis par au moins 60bits de hash SHA-1 de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).

   D'autres méthodes pour générer des nombres uniques sont également acceptables.

   Pour un certificat d'entité finale, l'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats contenant la clé publique particulière utilisée dans une application. Quand une entité finale a obtenu plusieurs certificats, spécialement depuis plusieurs CA, l'identifiant de clé du sujet fournis un moyen de rapidement identifier le jeu de certificats contenant une clé publique particulière. Pour assister les applications à identifier le bon certificat, cette extension devrait être incluse dans tous les certificats d'entité finale.

   Pour les certificats d'entité finale, les identifiants de clé du sujet devraient être dérivés de la clé publique. 2 méthodes communes pour générer des identifiants de clé depuis la clé publique sont identifiés ci-dessus.

   Quand un identifiant de clé n'a pas été établis précédemment, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou utiliser une méthodes similaire qui utilise un algorithme de hash différent. Quand un identifiant de clé a été précédemment établis, la CA devrait utilise cet identifiant.

Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
    
SubjectKeyIdentifier ::= KeyIdentifier

Key Usage

   L'extension d'utilisation de clé définis le but (ex: le chiffrement, la signature, signature de certificat) de la clé contenue dans le certificat. La restriction d'utilisation peut être employée quand une clé qui pourrait être utilisée pour plus d'une opération doit être restreindre. Par exemple, quand une clé RSA devrait être utilisée seulement pour vérifier les signatures sur des objets autre que des certificats à clé publique et les CRL, les bits digitalSignature et/ou nonRepudiation devraient être mis. De même, quand une clé RSA devrait être utilisée seulement pour la gestion de clé, le bit keyEncipherment devrait être mis.

   Les CA conformes doivent inclure cette extension dans les certificats qui contiennent des clés publiques qui sont utilisée pour valider les signatures numériques dans d'autre certificats à clé publique ou des CRL. Quand il est présent, les CA conformes devraient marquer cette extension comme critique.


id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
    
KeyUsage ::= BIT STRING {
    digitalSignature (0),
    nonRepudiation (1), -- Les éditions récentes de X.509 ont renommé ce bis en contentCommitment
    keyEncipherment (2),
    dataEncipherment (3),
    keyAgreement (4),
    keyCertSign (5),
    cRLSign (6),
    encipherOnly (7),
    decipherOnly (8) }

digitalSignature est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numériques, autre que les signature des certificats et des CRL, telles que celles utilisées dans les services d'authentification d'entité, services d'authentification de l'origine des données, et/ou services d'intégrité.
nonRepudiation est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numérique, autre que les signatures des certificats et des CRL, utilisé pour fournir un service de non-répudiation qui protège contre l'entité signataire niant à tord certaines actions. Dans le cas de conflits ultérieurs, un tiers de confiance peut déterminer l'authenticité des données signées.
keyEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer des clés secrètes ou privée, par exemple, pour le transport de clé. Par exemple, ce bit devrait être mis quand une clé publique RSA est utilisée pour chiffrer une clé de déchiffrement de contenu symétrique ou une clé privée asymétrique.
dataEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer directement les donnée brutes de l'utilisateur sans l'utilisation de clé symétrique intermédiaire. Noter que l'utilisation de ce bit est extrêmement peu commun; la plupart des applications utilisent le transport de clé pour l'agrément de clé pour établir une clé symétrique.
keyAgreement est mis quand la clé publique est utilisée pour la gestion de clé. Par exemple, quand une clé Diffie-Hellman est utilisée pour la gestion de clé, alors ce bit est mis.
keyCertSign Est mis quand la clé publique est utilisée pour vérifier les signatures des certificats à clé publique. Si keyCertSign est mis, alors le bit cA dans l'extension de contrainte de base doit également être mis.
cRLSign est mis quand la clé publique est utilisée pour vérifier les signatures dans les listes de révocation de certificat.
encipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour chiffrer les données en effectuant un agrément de clé.
decipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour déchiffrer les données en effectuant un agrément de clé.

   Si l'extension keyUsage est présent, alors la clé publique du sujet ne doit pas être utilisée pour vérifier les signatures dans le certificats ou les CRL à moins que les bits correspondants ne soient mis. Si la clé publique du sujet est seulement utilisée pour vérifier les signatures dans les certificats et/ou les CRL, alors les bits digitalSignature et nonRepudiation ne devraient pas être mis. Cependant, digitalSignature et/ou nonRepudiation peuvent être mis en plus de keyCertSign et/ou cRLSign si la clé publique du sujet est utilisée pour vérifier les signatures dans les certificats et/ou les CRL et également dans d'autres objets.

   Combiner le bit nonRepudiation dans l'extension de certificat keyUsage avec d'autres bits d'utilisation de clé peut avoir des implications de sécurité en fonction du contexte dans lequel le certificat est utilisé. D'autres distinction entre digitalSignature et nonRepudiation peuvent être fournis dans des stratégies de certificat spécifiques.

   Ce profil ne restreins pas les combinaisons de bits qui peuvent être mis dans une extension keyUsage. Cependant, des valeurs appropriées pour keyUsage pour des algorithmes particuliers sont spécifiés dans les rfc3279, rfc4055, et rfc4491. Quand l'extension keyUsage apparaît dans un certificat, au moins un bit doit être mis.

Certificate Policies

   L'extension de stratégie de certificat contient une séquence d'un ou plusieurs termes d'informations de stratégie, chacun consistant d'un identifiant d'objet et d'un qualifiant optionnel. Les qualifiants optionnel, qui peuvent être présents, ne sont pas prévus pour changer la définition de la stratégie. Un OID de stratégie de certificat ne doit pas apparaître plus d'une fois dans une extension de stratégie de certificat.

   Dans un certificat d'entité finale, ces informations de stratégie indique la stratégie sous laquelle le certificat a été émis et le but pour lequel le certificat peut être utilisé. Dans un certificat CA, ces stratégies limitent le jeu de stratégie pour les chemins de certification qui incluent ce certificat. Quand une CA ne souhaite pas limiter le jeu de stratégies pour les chemins de certification qui incluent ce certificat, elle peut indiquer une stratégie spéciale anyPolicy, qui a la valeur { 2 5 29 32 0 }.

   Les applications avec des besoins de stratégie spécifiques sont censés avoir une liste de ces stratégies qu'elles vont accepter et pour comparer les OID de stratégie dans le certificat à cette liste. Si cette extension est critique, le logiciel de validation de chemin doit être capable d'interpréter cette extension (incluant le qualifiant optionnel), ou doivent rejeter le certificat.

   Pour promouvoir l'interopérabilité, ce profile recommande que les termes d'informations de stratégie consistent de seulement un OID. Quand un OID seul n'est pas suffisant, ce profile recommande fortement que l'utilisation des qualifiants soient limités à ceux identifiés dans cette section. Quand les qualifiants sont utilisé avec le stratégie spéciale anyPolicy, ils doivent être limités aux qualifiants identifés dans cette section. Seul ces qualifiants retournés en résultat de la validation de chemin sont considérés.

   Cette spécification définis 2 types de qualifiants de stratégie à utiliser avec les concepteurs de stratégie de certificat. Les types de qualifiants sont le CPS Pointer et User Notice.

   Le CPS Pointer contient un pointer vers un Certification Practice Statement ( CPS ) publié par la CA. Le pointeur est sous la forme d'un URI. Les pré-requis de traitement pour ce qualifiant sont définis localement. Aucune action n'est mandatée par cette spécification sans regarder la criticité de cette extension.

   User notice est prévu pour afficher un tier de confiance quand un certificat est utilisé. Seuls les consignes utilisateurs retournés en résultat de la validation de chemin sont prévus pour l'affichage à l'utilisateur. Si une consigne est dupliqué, seul une copie est affichée. Pour empêcher une telle duplication, ce qualifiant devrait seulement être présent dans les certificats d'entité finaux et les certificats de CA fournis à d'autres organisations.

   La consigne utilisateur a 2 champs optionnels: noticeRef et explicitText. Les CA conformes ne devraient pas utiliser l'option noticeRef.

   Le champ noticeRef, si utilisé, nomme une organisation et identifie, par un nombre, une déclaration textuelle particulière préparée par cette organisation. Par exemple, il peut identifier l'organisation "CertsRUs" et un numéro de consigne 1. Dans une implémentation typique, l'application aura un fichier de consigne contenant le jeu de textes dans un fichier et l'affichera. Les messages peuvent être multi-langue.

   Le champ explicitText inclus la déclaration textuel directement dans le certificat. Ce champ est une chaîne avec un maximum de 200 caractères. Les CA conformes devraient utiliser l'encodage UTF8String, mais peuvent utiliser IA5String. Les CA conformes ne doivent pas encoder explicitText en VisibleString ou BMPString. La chaîne explicitText ne devrait pas inclure de caractères de contrôle. Encodé en UTF8String, toutes les séquences de caractère devraient être normalisés en accord avec Unicode Normalization form C (NFC).

   Si les 2 options sont inclues dans un qualifiant et si l'application peut localiser le texte indiqué par noticeRef, alors ce texte devrait être affiché; sinon, la chaîne explicitText devrait être affichée.

   Note: bien que explicitText a une taille maximum de 200 caractères, certaines CA non-conformes dépassent cette limite. Cependant, les utilisateurs de certificat devrait gérer ce champ avec plus de 200 caractères.


id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
    
    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
    
    certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
    
    PolicyInformation ::= SEQUENCE {
        policyIdentifier CertPolicyId,
        policyQualifiers SEQUENCE SIZE (1..MAX) OF
         PolicyQualifierInfo OPTIONAL }
    
    CertPolicyId ::= OBJECT IDENTIFIER
    
    PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId PolicyQualifierId,
        qualifier ANY DEFINED BY policyQualifierId }
    
    -- policyQualifierIds for Internet policy qualifiers
    
    id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
    id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
    id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
    
    PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
    
    Qualifier ::= CHOICE {
        cPSuri CPSuri,
        userNotice UserNotice }
    
    CPSuri ::= IA5String
    
    UserNotice ::= SEQUENCE {
        noticeRef NoticeReference OPTIONAL,
        explicitText DisplayText OPTIONAL }
    
    NoticeReference ::= SEQUENCE {
        organization DisplayText,
        noticeNumbers SEQUENCE OF INTEGER }
    
    DisplayText ::= CHOICE {
        ia5String IA5String (SIZE (1..200)),
        visibleString VisibleString (SIZE (1..200)),
        bmpString BMPString (SIZE (1..200)),
        utf8String UTF8String (SIZE (1..200)) }

Policy Mappings

   Cette extension est utilisée dans les certificats CA. Elle liste une ou plusieurs paires d'OID; chacune incluant un issuerDomainPolicy et un subjectDomainPolicy. Le jumelage indique que la CA émettrice considère son issuerDomainPolicy équivalent au subjectDomainPolicy de la CA.

   Les utilisateurs de la CA émettrice peuvent accepter un issuerDomainPolicy pour certaines applications. Le mappage de stratégie définie la liste des stratégies associées avec le sujet CA qui peuvent être acceptés comme comparable à issuerDomainPolicy.

   Chaque issuerDomainPolicy nommé dans l'extension de mappage de stratégies devrait également être mis dans une extension de stratégie de certificat dans le même certificat. Les stratégies ne doivent pas être mappés soit pour ou depuis la valeur spéciale anyPolicy.

   En général, les stratégies de certificat qui apparaissent dans le champ issuerDomainPolicy de l'extension de mappage de stratégie ne sont pas considérées comme stratégie acceptable pour l'inclusion dans le certificats sous-jacents dans le chemin de certification. Dans certaines circonstances, une CA peut souhaiter mapper une stratégie (p1) à une autre (p2), mais veut que le issuerDomainPolicy (p1) soit considéré comme acceptable pour l'ajout dans les certificat sous-jacents. Cela peut se produire, par exemple, si la CA est dans le processus de transition d'e l'utilisation de la stratégie p1 vers l'utilisation de la stratégie p2 et a des certificats valides qui ont été émis sous chaque stratégie. Une CA peut indiquer cela en incluant 2 mappage de stratégie dans les certificats CA qu'elle fournis. Chaque mappage de stratégie aura un issuerDomainPolicy de p1; un mappage de stratégie aura subjectDomainPolicy de p1 et l'autre aura le subjectDomainPolicy de p2.

Cette extension peut être supportée par les CA et/ou les applications. Les CA conformes devraient marquer cette extension comme critique.
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
    
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    issuerDomainPolicy CertPolicyId,
    subjectDomainPolicy CertPolicyId }

Subject Alternative Name

   L'extension subject alternative name permet aux identités d'être liées au sujet du certificat. Ces identités peuvent être inclues en plus ou à la place e l'identité dans le champ subject du certificat. Les options définies incluent une adresse de messagerie électronique, un nom DNS, une adresse IP, et une URI. D'autres options existent, incluant les définitions complètement locales. Plusieurs formes de nom, et plusieurs instances de chaque forme de nom peuvent être inclus. Quand de telles identités sont liées dans un certificat, l'extension subject alternative name (ou issuer alternative name) doit être utilisée; cependant, un nom DNS peut également être représenté dans le champ subject en utilisant l'attribut domainComponent. Noter que quand de tels noms sont représentés dans le champ subject, les implémentation ne sont pas obligées de les convertir en noms DNS.

   Puisque le nom alternatif du sujet est considéré comme lié définitivement à la clé publique, toutes les parties doivent être vérifiés par la CA.

   De plus, si la seul identité du sujet inclue dans le certificat est une forme de nom alternative, alors le nom distinct du sujet doit être vide, et l'extension subjectAltName doit être présent. Si le champ subject contient une séquence vide, alors la CA émettrice doit inclure une extension subjectAltName marquée comme critique. En incluant l'extension subjectAltName dans un certificat qui a un sujet non-vide, les CA conformes devraient marque l'extension subjectAltName comme non-critique.

   Quand l'extension subjectAltName contient une adresse email, cette adresse doit être stockée dans le rfc822Name. Le format d'un rfc822Name est un Mailbox comme définis dans la rfc 2821. Une Mailbox a la forme "local-part@Domain". Noter qu'une Mailbox n'a pas de phrase (cet un nom commun) avant lui, et n'est pas entouré de "‹" et "›". Les règles d'encodage des adresses email qui incluent des noms de domaines internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une iPAdress, l'adresse doit être stockée dans la chaîne d'octets dans "network byte order", comme spécifié dans la rfc791. Le LSB de chaque octet est le LSB de l'octet correspondant dans l'adresse réseau. Pour les IPv4, comme spécifié dans la rfc791, la chaîne d'octets doit contenir exactement 4 octets. Pour la version IPv6, comme spécifié dans la rfc2460, la chaîne d'octets doit contenir exactement 16 octets.

   Quand l'extension subjectAltName contient un nom de domaine, le nom de domaine doit être stocké dans le dNSName ( un IA5String ). Le nom doit être en "preferred name syntax", comme spécifié dans la rfc1034 et modifié dans la rfc1123. Noter que bien que les lettres majuscules et minuscules sont permises dans les noms de domaines, la casse n'est pas prise en compte. En plus, alors que la chaîne " " est un nom de domaine légal, les extensions subjectAltName avec un dNSName de " " ne doivent pas être utilisé. Finalement, l'utilisation de la représentation DNS pour les adresses mail ne doivent pas être utilisées, de telles identités sont encodées en rfc822Name. Les règles pour l'encodage des noms de domaine internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une URI, le nom doit être stocké dans un uniformResourceIdentifier (un IA5String). Le nom ne doit pas être une URI relative, et doit suivre la syntaxe URI et les règles d'encodage spécifiés dans la rfc3986. Le nom doit inclure à la fois un schéma (ex: http ou ftp) et une partie spécifique au schéma. Les URI qui incluent une autorité doivent inclure un nom pleinement qualifié ou une adresse IP comme hôte. Les règles pour l'encodage des Internationalized Resource Identifiers (IRI) sont spécifiées plus bas.

   Comme spécifié dans la rfc3986, le schema n'est pas sensible à la casse ( ex: http est équivalent à HTTP ). La partie hôte, si présent, est également insensible à la casse, mais les autres composant de la partie spécifique au schéma peut être sensible à la casse. Les règles pour comparer les URI sont spécifiées plus bas.

   Quand l'extension subjectAltName contient un DN dans le directoryName, les règles d'encodage sont les mêmes qui ceux spécifiés pour le champ issuer. Le DN doit être unique pour chaque entité sujet certifiée par une CA comme définie par le champ issuer. Une CA peut émettre plus d'un certificat vec le même DN au même sujet.

   Le subjectAltName peut gérer des types de noms additionnel via l'utilisation du champ otherName. Le format et les sémantiques de nom sont indiqués via l'identifiant d'objet dans le champ type-id. Le nom lui-même est acheminé comme valeur de champ dans otherName. Par exemple un OID de nom principal Kerberos peut être encodé comme séquence du Realm et du PrincipalName.

   Les noms alternatifs du sujet peuvent être contraints de la même manière que les noms distinct du sujet en utilisant une extension de contrainte de nom.

   Si l'extension subjectAltName est présent, la séquence doit contenir au moins une entrée. À la différence du champ subject, les CA conformes ne doivent pas fournir de certificats avec un subjectAltName contenant des champs GeneralName vides. Par exemple, un rfc822Name est représenté en IA5String. Alors qu'une chaîne vide est un IA5String valide, un tel rfc822Name n'est pas permis par ce profile. Le comportement des client qui rencontrent un tel certificat en traitant un chemin de certification n'est pas définis par ce profile.

   Finalement, les sémantiques des noms alternatifs du sujet qui incluent des caractères wilcards ne sont pas adressés par cette spécification. Les applications avec des requis spécifiques peuvent utiliser de tels noms, mais elles doivent définir les sémantiques.


id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
    
SubjectAltName ::= GeneralNames
    
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
    
GeneralName ::= CHOICE {
    otherName [0] OtherName,
    rfc822Name [1] IA5String,
    dNSName [2] IA5String,
    x400Address [3] ORAddress,
    directoryName [4] Name,
    ediPartyName [5] EDIPartyName,
    uniformResourceIdentifier [6] IA5String,
    iPAddress [7] OCTET STRING,
    registeredID [8] OBJECT IDENTIFIER }
    
OtherName ::= SEQUENCE {
    type-id OBJECT IDENTIFIER,
    value [0] EXPLICIT ANY DEFINED BY type-id }
    
EDIPartyName ::= SEQUENCE {
    nameAssigner [0] DirectoryString OPTIONAL,
    partyName [1] DirectoryString }

Issuer Alternative Name

Comme pour la section précédente, cette extension est utilisée pour associer des identité de style Internet avec des fournisseurs de certificats. Le nom alternatif du fournisseur doit être encodé comme dans la section précédente. Les noms alternatifs du fournisseur ne sont pas traités comme partie de l'algorithme de validation de chemin de certification. ( ils ne sont pas utilisé dans le chaînage et les contraintes de noms ne sont pas forcées ). Quand présent, les CA conformes devraient marquer cette extension non-critique.
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
    
IssuerAltName ::= GeneralNames

Subject Directory Attributes

L'extension d'attributs d'annuaires du sujet est utilisée pour transmettre des attributs d'identification (ex: nationalité) du sujet. L'extension est définie comme une séquence d'un ou plusieurs attributs. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
    
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Basic Constraints

   L'extension de contraintes de base identifie si le sujet du certificat est une CA et la profondeur maximale des chemins de certification valides qui incluent ce certificat.

   Le booléen cA indique si la clé publique certifiée peut être utilisée pour vérifier le signatures de certificat. Si le booléen cA n'est pas présent, alors le bit keyCertSign de l'extension d'utilisation de clé ne doit pas être présent. Si l'extension de contraintes de base n'est pas présent dans un certificat v3, ou l'extension est présent mais le booléen cA n'est pas mis, alors la clé publique certifiée ne doit pas être utilisée pour vérifier les signatures de certificat.

   Le champ pathLenConstraint a une signification seulement si cA est mis et l'extension d'utilisation de clé, si présent, à le bit keyCertSign mis. Dans ce cas, il donne le nombre maximum de certificats intermédiaires non auto-fournis qui peuvent suivre ce certificat dans le chemin de certification. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire, et n'est pas inclus dans cette limite. Généralement, le dernier certificat est un certificat d'entité finale, mais peut être un certificat de CA). Un pathLenConstraint de 0 indique qu'aucun certificat de CA intermédiaire non auto-fournis ne peut suivre dans un chemin de certification valide. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal à 0. Quand pathLenConstraint n'apparaît pas, aucune limite n'est imposée.

   Les CA conformes doivent inclure cette extension dans tous les certificats CA qui contiennent une clé publique utilisée pour valider les signatures numérique dans les certificat et doivent marquer cette extension comme critique. Cette extension peut apparaître comme critique ou non dans les certificats CA qui contiennent des clés publiques utilisée exclusivement pour d'autres but que la validation des signatures numérique dans les certificats. De tels certificats de CA incluent ceux qui contiennent des clé publique utilisées exclusivement pour valider les signatures numérique dans les CRL et ceux qui contiennent des clés publique de gestion de clé utilisées avec les protocoles d'inscription de certificat.

Les CA ne doivent pas inclure le champ pathLenConstraint sauf si le booléen cA est mis et que l'extension d'utilisation ed clé a le bit keyCertSign mis.
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
    
BasicConstraints ::= SEQUENCE {
    cA BOOLEAN DEFAULT FALSE,
    pathLenConstraint INTEGER (0..MAX) OPTIONAL }

Name Constraints

   L'extension de contrainte de noms, qui doit être utilisé seulement dans un certificat de CA, indique un espace de noms dans lequel tous les noms de sujet dans les certificats sous-jacent dans un chemin de certification doivent être localisés. Les restrictions d'appliquent aux dn du sujet et aux noms alternatifs du sujet. Les restrictions s'appliquent seulement quand la forme de nom spécifié est présente. Si aucun nom du type n'est dans le certificat, le certificat est acceptable.

   Les contraintes de nom ne sont pas appliquées aux certificats auto-fournis ( à moins que le certificat est un certificat final dans le chemin ). ( Cela peut empêcher les CA qui utilisent les contraintes de noms d'employer des certificats auto-fournis pour implémenter du remplacement de clé).

   Les restrictions sont définies en termes de subtrees de noms permis ou exclus. Tout nom correspondant à une restriction dans le champ excludedSubtrees est invalide sans regarder les informations apparaîssant dans permittedSubtrees. les CA conformes doivent marquer cette extension comme critique et ne devraient pas imposer de contraintes de nom sur les formes de noms x400Address, ediPartyName, ou registeredID. Les CA conformes ne doivent pas fournir de certificats où les contraintes de nom est une séquence vide, le champ permittedSubtrees ou excludedSubtrees doit être présent.

   Les applications conformes à ce profile doivent être capable de traiter les contraintes de noms qui sont imposées dans le forme de nom directoryName et devraient être capable de traiter les contraintes de nom qui sont imposées dans les formes de nom rfc822Name, uniformResourceIdentifier, dNSName, et iPAddress. Si une extension de contraintes de nom qui est marqué critique impose des contraintes sur une forme de nom particulier, et une instance de cette forme de nom apparaît dans le champ subject ou dans l'extension subjectAltName. d'un certificat sous-jacent, alors l'application doit traiter la contrainte ou rejeter le certificat.

   Dans ce profile, les champs minimum et maximum ne sont pas utilisé pour les formes de nom, donc, le minimum doit être 0, et maximum doit être absent. Cependant, si une application rencontre une extension de contraintes de noms critique qui spécifie d'autres valeurs pour minimum et maximum pour une forme de nom qui apparaît dans un certificat sous-jacent, l'application doit traiter ces champs ou rejeter le certificat.

   Pour les URI, la contrainte s'applique à la partie hôte du nom. La contrainte doit être spécifiée en fqdn et peut spécifier un hôte ou un domaine. Quand la contrainte commance avec un point, elle peut être étendue avec un ou plusieurs labels. Par exemple, ".example.com" est satisfait par host.example.com, et my.host.example.com. Cependant, la contrainte .example.con n'est pas satisfait par example.com. Quand la contrainte ne commence pas avec un point, elle spécifie un hôte. Si une contrainte est appliquée à une forme de nom URI et qu'un certificat sous-jacent inclue une extension subjectAltName avec une URI qui n'inclue pas un composant d'autorité avec un nom d'hôte spécifié en fqdn, alors l'application doit rejeter le certificat.

   Une contrainte de nom pour les adresses email de l'Internet peut spécifier une boîte mail particulière, toutes les adresses dans un hôte particulier, ou toutes les boîtes mail dans un domaine. Pour indiquer une boîte mail particulière, la contrainte est l'adresse mail complète. Pour indiquer toutes les adresses mail dans un hôte particulier, la contrainte est spécifiée comme nom d'hôte. Pour spécifier toutes les adresse mail dans un domaine, la contrainte est spécifiée avec un point, comme avec une URI ( .example.com indique toutes les adresse mail du domaine example.com, mail pas les adresses internet de l'hôte example.com ).

   Les restrictions des noms DNS sont exprimées en host.example.com. Tous nom DNS qui peut être construit en ajoutant simplement 0 ou plusieurs labels à la partie gauche du nom satisfont la contrainte de nom. Par exemple, www.host.example.com satisfait la contrainte mais pas host1.example.com.

   Les anciennes implémentations existent où une adresse mail est embarquée dans le sujet dans une attribut de type emailAddress. Quand les contraintes sont imposée sur la forme de nom rfc822Name, mais que le certificat n'inclut pas une extension subjecAltName, la contrainte rfc822Name doit être appliquée à l'attribut de type emailAdress dans le sujet. La syntaxe ASN.1 pour emailAddress et l'OID correspondant sont fournis en appendix A.

   Les restrictions de la forme directoryName doivent être appliqués au champ subject dans le certificat ( quand le certificat inclus un champ de sujet non-vide ). et à tous noms de type directoryName dans l'extension subjectAltName. Les restrictions de la form x400Address doivent être appliquées à tous les noms de type x400Address dans l'extension subjectAltName.

   La syntaxe de iPAddress doit être comme décris précédemment avec les ajouts suivant spécifiquement pour les contraintes de noms. Pour les adresses IPv4, le champ IPv4 de GeneralName doit contenir 8 cotets, encodés dans le style rfc4632 (CIDR) opur représenter une plage d'adresses. Pour les adresses IPv6, le champ iPAddress doit contenir 32 octets encodés similairement. Par exemple, une contrainte de nom un sous-réseaux de classe C 192.0.2.0 est représenté pas les octets C0 00 02 00 FF FF FF 00, représentant la notation CIDR 192.0.2.0/24.

   Des règles additionnelles pour l'encodage et le traitement des contraintes de noms sont spécifiées plus bas. La syntaxe et les sémantiques pour les contraintes de noms pour otherName, ediPartyName, et registeredID ne sont pas définies par cette spécification. Cependant, la syntaxe et les sémantiques pour les contraintes de nom pour d'autres formes de nom peuvent être spécifiés dans d'autres documents.


id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
    
NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }
    
    GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
    
GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0..MAX)

Policy Constraints

   L'extension de contrainte de stratégie peut être utilisée dans les certificats fournis aux CA. Cette extension contraint la validation de chemin de 2 manières. Elle peut être utilisée pour interdire le mappage de stratégie ou nécessiter que chaque certificat dans le chemin contienne un identifiant de stratégie acceptable.

   Si le champ inhibitPolicyMapping est présent, la valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant que le mappage de stratégie ne soit plus permis. Par exemple, une valeur indique que le mappage de stratégie peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

   Si le champ requireExplicitPolicy est présent, sa valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant qu'une stratégie explicite soit requise pour tous le chemin. Quand une stratégie explicite est requise, il est nécessaire pour tous les certificats dans le chemin de contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Un identifiant de stratégie acceptable est l'identifiant d'une stratégie requise par l'utilisateur du chemin de certification ou l'identifiant d'une stratégie qui a été déclarée équivalente via le mappage de stratégie.

   Les applications conformes doivent être capable de traiter le champ requireExplicitPolicy et devraient être capable de traiter le champ inhibitPolicyMapping. Les application qui supportent le champ inhibitPolicyMapping doivent également implémenter le support pour l'extension policyMappings. Si l'extension policyConstraints est marquée critique et que le champ inhibitPolicyMapping est présent, les applications qui n'implémentent pas le support pour inhibitPolicyMapping doivent rejeter le certificat.

   Les CA conformes ne doivent pas fournir de certificats où la contrainte de stratégie est une séquence vide. inhibitPolicyMapping ou requireExplicitPolicy doit être présent. Le comportement des clients qui rencontrent un champ de contrainte de stratégie vide n'est pas adressé dans ce document.

Les CA conformes doivent marquer cette extension critique.
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
    
PolicyConstraints ::= SEQUENCE {
    requireExplicitPolicy [0] SkipCerts OPTIONAL,
    inhibitPolicyMapping [1] SkipCerts OPTIONAL }
    
SkipCerts ::= INTEGER (0..MAX)

Extended Key Usage

Cette extension indique un ou plusieurs buts pour lequel la clé publique certifiées peut être utilisée, en plus ou à la place de l'extension d'utilisation de clé. En général, cette extension apparaît seulement dans les certificats d'entité finales. Cette extension est définie:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
    
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
    
KeyPurposeId ::= OBJECT IDENTIFIER

   Les identifiants d'objet utilisés pour identifier le but de clé doivent être assignés en accord avec les recommandations de l'IANA ou l'ITU-T X.660. Cette extension peut être critique ou non.

   Si l'extension est présente, alors le certificat doit seulement être utilisé pour un des buts indiqué. Si plusieurs buts sont indiqués l'application n'a pas besoin de reconnaître tous les buts indiqués, tant que le but prévus est présent. Les applications utilisant les certificats peuvent nécessiter que l'extension d'utilisation de clé soit présente et qu'un but particulier soit indiqué pour que le certificat soit accepté par l'application.

   Si une CA inclus les utilisations de clé pour satisfaire de telles applications, mais ne souhaite pas restreindre les utilisations de clé, la CA peut inclure le KeyPurposeId spécicial anyExtendedKeyUsage en plus des buts particuliers requis par les applications. Les CA conformes ne devraient pas maquer cette extension critique si anyExtendedKeyUsage est présent. Les applications qui nécessitent la présence d'un but particulier peuvent rejeter les certificats qui incluent anyExtendedKeyUsage mais par l'OID particulier attendus pour l'application.

   Si un certificat contient à la fois l'extension d'utilisation de clé et une extension d'utilisation de clé étendue, les 2 extensions doivent être traitées indépendamment et le certificat doit seulement être utilisé pour un but consistant avec les 2 extensions. S'il n'y a pas de but consistant avec les 2 extensions, alors le certificat ne doit pas être utilisé.

Les buts d'utilisation de clé suivants sont définis:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
    
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
    
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
    -- Authentification serveur www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, keyEncipherment ou keyAgreement
    
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
    -- Authentification client www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, et/ou keyAgreement
    TLS WWW client authentication
    
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
    -- Signature de codes exécutables téléchargeables
    -- Utilisations de clé qui peuvent être consistant: digitalSignature
    
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
    -- Protection d'email
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, nonRepudiation, et/ou (keyEncipherment ou keyAgreement)
    
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
    -- Lier le hash d'un objet à une date
    -- Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation
    
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
    -- Signature de réponses OCSP
    - Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation

CRL Distribution Points

   L'extension de point de distribution de CRL identifie comment les informations de CRL sont obtenus. L'extension devrait être non-critique, mais ce profile recommande le support pour cette extension par les CA et les application.

   L'extension cRLDistributionPoints est une séquence de DistributionPoint. Un DistributionPoint consiste de 3 champs, chacun d'entre-eux est optionnels: distributionPoint, reasons, et cRLIssuer. Bien que chacun de ces champs est optionnel, un DistributionPoint ne doit pas consister du seul champ reasons; distributionPoint ou cRLIssuer doit être présent. Si le fournisseur de certificat n'est pas le fournisseur de CRL, alors le champ cRLIssuer doit être présent et contient le nom du fournisseur de CRL. Si le fournisseur de certificat est également le fournisseur de CRL, les CA conformes doivent omettre le champ cRLIssuer et doivent inclure le champ distributionPoint.

   Quand le champ distributionPoint est présent, il contient soit une séquence de noms ou une simple valeur, nameRelativeToCRLIssuer. Si le DistributionPointName contient plusieurs valeurs, chaque nom décris un mécanisme différent pour obtenir la même CRL. Par exemple, la même CRL pourrait être disponible via LDAP et HTTP.

   Si le champ distributionPoint contient un directoryName, l'entrée pour ce directoryName contient la CRL courante pour les raisons associées et la CRL est fournie par le cRLIssuer associé. La CRL peut être stockée dans soit certificateRevocationList ou authorityRevocationList. La CRL est obtenus par l'application en fonction de la configuration locale du serveur d'annuaire. Le protocole que l'application utilise pour accéder à l'annuaire et un choix local.

   Si DistributionPointName contient un nom général de type URI, les sémantiques suivante doivent être assumées: l'URI est un pointer vers la CRL courante pour les raisons associées et sera fournis par le cRLIssuer associé. Quand les schémas d'URI HTTP ou FTP sont utilisés, l'URI doit pointer vers une CRL simple encodé DER comme spécifié dans la rfc2585. Les implémentations de serveur HTTP accèdés via l'URI devraient spécifier le type de media application/pkix-crl dans le champ d'en-tête content-type de la réponse.

   Quand le schéma d'URI LDAP est utilisé, l'URI doit inclure un champ dn contenant le nom distinct de l'entrée maintenant la CRL, doit inclure un simple attrdesc qui contient une description d'attribut appropriée pour l'attribut qui maintient la CRL (rfc4523), et devrait inclur un hôte (ex: ‹ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?certificateRevocationList;binary›). Omettre l'hôte (ex: ‹ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary›) implique de s'appuyer sur la connaissance du client du serveur approprié. Quand présent, DistributionPointName devrait inclure au moins une URI LDAP ou HTTP.

   Si DistributionPointName contient un simple valeur nameRelativeToCRLIssuer, la valeur fournis un fragment de nom distinct. Le fragment est ajouté au nom distinct X.500 du fournisseur de CRL pour obtenir le nom du point de distribution. Si le champ cRLIssuer dans le DistributionPoint est présent, alors le fragment est ajouté au nom distinct qu'il contient, sinon le fragment est ajouté au nom distinct du fournisseur de certificat. Les CA conformes ne devraient pas utiliser nameRelativeToCRLIssuer pour spécifier les noms des points de distributions. Le DistributionPointName ne doit pas utiliser un nameRelativeToCRLIssuer relatif quand cRLIssuer contient plus d'un nom distinct.

   Si DistributionPoint omet le champ reasons, la CRL doit inclure des informations de révocation pour toutes les raisons. Ce profile recommande d'éviter la segmentation de CRL par code de raison. Quand une CA conforme inclus une extension cRLDistributionPoints dans un certificat, elle doit inclure au moins un DistributionPoint qui pointe vers une CRL qui couvre le certificat pour toutes les raisons.

   cRLIssuer identifie l'entité qui signe et fournis la CRL. Si présent, cRLIssuer doit seulement contenir le nom distinct du champ issuer de la CRL pointé par le DistributionPoint. L'encodage du nom dans le champ cRLIssuer doit être exactement le même que l'encodage dans le champ issuer de la CRL. Si le champ cRLIssuer est inclus et le dn dans ce champ ne correspond par à une entrée X.500 ou LDAP où la CRL est localisée, alors les CA conformes doivent inclure le champ distributionPoint.


id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
    
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
    
DistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    reasons [1] ReasonFlags OPTIONAL,
    cRLIssuer [2] GeneralNames OPTIONAL }
    
DistributionPointName ::= CHOICE {
    fullName [0] GeneralNames,
    nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
    
ReasonFlags ::= BIT STRING {
    unused (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    privilegeWithdrawn (7),
    aACompromise (8) }

Inhibit anyPolicy

   L'extension inhibit anyPolicy peut être utilisée dans les certificats fournis aux CA. Elle indique que l'OID spéciale anyPolicy { 2 5 29 32 0 }, n'est pas considérée comme une correspondance explicite pour les autres stratégies de certificat excepté quand elle apparaît dans un certificat CA auto-fournis intermédiaire. La valeur indique le nombre de certificats non auto-fournis additionnels qui peuvent apparaître dans le chemin avant que anyPolicy ne soit plus permis. Par exemple, une valeur de 1 indique que anyPolicy peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

Les CA conformes doivent marquer cette extension critique
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
    
InhibitAnyPolicy ::= SkipCerts
    
SkipCerts ::= INTEGER (0..MAX)

Freshest CRL

l'extension freshest CRL identifie comment les informations de CRL delta sont obtenus. Cette extension doit être marquée non critique. La même syntaxe est utilisée pour cette extension et l'extension cRLDistributionPoints. Les même conventions d'appliquent aux 2 extensions
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
    
FreshestCRL ::= CRLDistributionPoints

Extensions Internet privées

   Cette section définis 2 extensions à utiliser dans les infrastructures à clé publique de l'Internet. Ces extensions peuvent être utilisées pour diriger les applications vers des informations en ligne sur le fournisseur ou le sujet. Chaque extension contient une séquence de méthodes d'accès et d'emplacements d'accès. La méthode d'accès est un identifiant d'objet qui indique le type d'informations qui sont disponibles. L'emplacement d'accès est un GeneralName qui spécifie implicitement l'emplacement et le format des informations et la méthode pour obtenir ces informations.

Les identifiants d'objet sont définis pour les extensions privées. Les identifiants d'objet associés avec les extensions privées sont définies sous l'arc id-pe dans l'arc id-pkix. Toutes extensions futures définies pour la PKI Internet seront définis également sous cet arc id-pe.
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
    
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

Authority Information Access

   L'extension d'accès aux informations d'autorité indique comment accéder aux informations et services pour le fournisseur du certificat dans lequel l'extension apparaît. Les informations et services peuvent inclure des services de validation en ligne et les données de stratégie de CA. ( L'emplacement des CRL n'est pas spécifié dans cette extension). Cette extension peut être inclus dans les certificat d'entité finale ou de CA. Les CA conformes doivent marquer cette extension non-critique.


id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
    
AuthorityInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription
    
AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }
    
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
    
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
    
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   Chaque entrée dans la séquence AuthorityInfoAccessSyntax décris le format et l'emplacement d'informations additionnelles fournies par le fournisseur du certificat dans lequel cette extension apparaît. Le type et le format des informations sont spécifiées par le champ accessMethod; le champ accessLocation spécifie l'emplacement des informations. Le mécanisme de récupération peut être déduit par accessMethod ou spécifié par accessLocation.

   Ce profile définis 2 OID d'accessMethod: id-ad-caIssuers et id-ad-ocsp.

   Dans un certificat à clé publique, l'OID id-ad-caIssuers est utilisé quand les informations additionnelles listent les certificats qui ont été fournis à la CA qui a fournis le certificat contenant cette extension. La description de fournisseurs CA référencés est destiné à aider les utilisateurs de certificat dans la sélection d'un chemin de certification qui se termine au point validé par le certificat utilisateur.

   Quand id-ad-caIssuers apparaît comme accessMethod, le champ accessLocation décris le serveur de description référencé et le protocole d'accès pour obtenir la description référencée. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application en fonction du serveur d'annuaire configuré localement. L'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifié dans la rf4523. Le protocole que les applications utilisent pour accéder à l'annuaire est une décision locale.

   Quand l'information est disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui maintient la liste des descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paire le cross-certificats, et devraient inclure un hôte ( ex ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

   Quand les informations sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer sur soit un simple certificat encodé DER comme spécifié dans la rfc2585, ou une collection de certificats dans message CMS "certs-only" encodé DER ou BER, comme spécifié dans la rfc2797.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de noms d'accessLocation id-ad-caIssuers ne sont pas définis.

   Une extension authorityInfoAccess peut inclure plusieurs instances de l'accessMethod id-ad-caIssuers. Les différentes instances peut spécifier différentes méthodes d'accès à la même information ou peut pointer vers différentes informations. Quant l'accessMethod id-ad-caIssuers est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-ocsp est utilisé quand les informations de révocation pour le certificat contenant cette extension est disponible en utilisant OCSP (rfc2560). Quand id-ad-ocsp apparaît comme accessMethod, le champ accessLocation est l'emplacement du répondeur OCSP, en utilisant les conventions spécifiées dans la rfc2560.

   Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécification PKIX.

Subject Information Access

   L'extension d'accès aux informations du sujet indique comment accéder aux informations et services pour le sujet du certificat dans lequel l'extension apparaît. Quand le sujet est une CA, les informations et services peuvent inclure des services de validation de certificat et une donnée de stratégie CA. Quand le sujet est une entité finale, les informations décrivent le type de services offerts et comment y accéder. Dans ce cas, le contenu de cette extension est définis dans les spécifications du protocole pour les services supportés. Cette extension peut être inclue dans des certificats CA ou d'entité finale. Les CA conformes doivent marquer cette extension non-critique.


id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
    
SubjectInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription
    
AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }

   Chaque entrée dans la séquence SubjectInfoAccessSyntax décris le format et l'emplacement des informations additionnelles fournies par le sujet du certificat dans lequel cette extension apparaît. Le type et le format de l'information sont spécifiés par le champ accessMethod; le champ accessLocation spécifie l'emplacement de l'information. Le mécanisme de récupération peut être implicite via accessMethod ou accessLocation.

   Ce profile définis une méthode d'accès à utiliser quand le sujet est une CA et une méthode d'acces utilisée quand le sujet est une entité finale. Des méthodes d'accès additionnels peuvent être définis dans de futures spécification de protocole pour d'autres services.

   L'OID id-ad-caRepository est utilisé quand le sujet est une CA qui publie les certificat quelle fournis dans un annuaire. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenue par l'application depuis le serveur d'annuaire configuré localement. Quand l'extension est utilisée pour pointer vers des certificats CA, l'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifiés dans la rfc4523. Le protocole que l'application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI ldap doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devraient inclure un hôte. ( ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary› ). Omettre l'hôte implique que le client connaît le serveur approprié à contacter.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer soit vers un simple certificat encodé DER ou une collection de certificats dans un message CMS "certs-only" encodés DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificat encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations de serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de nom accessLocation id-ad-caRepository ne sont pas définies.

   Une extension subjectInfoAccess peut inclure plusieurs instances de accessMethod id-ad-caRepository. Les instances différentes peuvent spécifier des méthodes différentes pour accéder à la même information ou peuvent pointer vers différentes informations. Quand accessMethod id-ad-caRepository est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-timeStamping est utilisé quand le sujet offre des services de timestamping utilisant le TSP (rfc3161). Quand les services de timestamping sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier. Quand les services de timestamping sont disponibles via les messages électroniques, accessLocation doit être un rfc822Name. Quand les services de timestamping sont disponibles en utilisant TCP/IP, les formes de noms dNSName ou iPAddress peuvent être utilisés. Les sémantiques d'autres formes de nom de accessLocation (quand accessMethod est id-ad-timeStamping) ne sont pas définis par cette spécification.

Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécifications PKIX.
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
    
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
    
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

Profile de CRL et d'extensions de CRL

   Comme discuté plus haut, un des but de ce profile de CRL X.509 v2 est de favoriser la création d'une ICP Internet interopérable et réutilisable. Pour cela, des lignes directrices pour l'utilisation des extensions sont spécifiée, et certaines hypothèses sont faites sur la nature des informations inclues dans la CRL.

   Les CRL peuvent être utilisée dans un grande variété d'applications et d'environnement couvrant un large spectre de pré-requis opérationnels et d'assurance. Ce profile établis une ligne de base commune pour les applications génériques nécessitant une grande interopérabilité. Ce profile définis un jeu d'informations qui peuvent être prévus dans toutes les CRL. Également, le profile définis des emplacements communs dans la CRL pour les attributs fréquemment utilisés et les représentations communes pour ces attributs.

   Les fournisseurs de CRL fournissent les CRL. Le fournisseur de CRL est soit la CA ou une entité qui a été autorisée par la CA pour fournir les CRL. Les CA publient les CRL pour fournir des informations de statut sur les certificats qu'elles émettent. Cependant, une CA peut déléguer cette responsabilité à une autre autorité de confiance.

   Chaque CRL a un périmètre particulier. Le scope de CRL est le jeu de certificats qui peuvent apparaître dans une CRL donnée. Par exemple, le scope pourrait être "tous les certificats émis par la CA X", "Tous les certificats de CA fournis par la CA X", "tous les certificats émis par la CA X qui ont été révoqués pour une raison de compromission de clé et de CA compromise", ou un jeu de certificats basés sur des informations locales arbitraire, tels que "tous les certificats fournis aux employés NIST localisé à Boulder.

   Une CRL complète liste tous les certificat non-expirés, dans son scope, qui ont été révoqués pour une des raisons de révocation couverts par le scope de la CRL. Une CRL pleine et complète liste tous les certificats non-expirés fournis par une CA qui a été révoqué pour une raison. (Noter que vu que les CA et les fournisseurs de CRL sont identifiés par nom, le scope d'une CRL n'est pas affectée par la clé utilisée pour signer la CRL ou les clés utilisées pour signer les certificats).

   Si le scope de la CRL inclus un ou plusieurs certificats fournis par une entité autre que le fournisseur de CRL, alors c'est une CRL indirecte. Le scope d'une CRL indirect peut être limitée aux certificats fournis par une simple CA ou peut inclure les certificats fournis par plusieurs CA. Si le fournisseur de la CRL indirecte est une CA, alors le scope de la CRL indirecte peut également inclure les certificats inclus par le fournisseur de cette CRL.

   Le fournisseur de CRL peut également générer des CRL delta. Une CRL delta liste seulement les certificats, dans son scope, dont le statut de révocation a changé depuis l'émission de la dernière CRL de complète référencée. Le scope d'une CRL delta doit être la même que a CRL de base qu'elle référence.

   Ce profile définis une extension de CRL Internet privée mais ne définis pas d'extensions d'entrée de CRL privée.

   Les environnements avec de besoins spéciaux ou additionnels peuvent se baser sur ce profile ou le remplacer.

   Les CA conformes ne sont pas obligés de fournir des CRL si d'autre mécanismes de statut de révocation ou de certificat sont fournis. Quand les CRL sont fournis, les CRL doivent être des CRL v2, doivent inclure la date à laquelle la prochaine CRL sera fournie dans le champ nextUpdate, doivent inclure l'extension de numéro de CRL, et doivent inclure l'extension d'identifiant de clé d'autorité. Les applications conformes qui supportent les CRL doivent traiter les CRL v1 et v2 qui fournissent des informations de révocation pour tous les certificats fournis par une CA. Les applications conformes ne sont pas obligés de supporter le traitement des CRL delta, des CRL indirect, ou des CRL avec un scope autre que tous les certificats fournis par une CA.

Champs de CRL

La syntaxe de CRL X.509 v2 est la suivante. Pour le calcule de signature, la donnée qui est signée est encodée ASN.1 DER. Un encodage ASN.1 DER est un système d'encodage ayant un tag, une longueur, et une valeur pour chaque élément.
CertificateList ::= SEQUENCE {
    tbsCertList TBSCertList,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }
    
TBSCertList ::= SEQUENCE {
    version Version OPTIONAL, -- si présent, doit être v2
    signature AlgorithmIdentifier,
    issuer Name,
    thisUpdate Time,
    nextUpdate Time OPTIONAL,
    revokedCertificates SEQUENCE OF SEQUENCE {
        userCertificate CertificateSerialNumber,
        revocationDate Time,
        crlEntryExtensions Extensions OPTIONAL -- si présent, doit être v2
    } OPTIONAL,
    crlExtensions [0] EXPLICIT Extensions OPTIONAL -- si présent, doit être v2
}
    
-- Version, Time, CertificateSerialNumber, et les Extensions
-- sont tous définis dans la section "champs de certificat de base"
-- AlgorithmIdentifier est décris dans la section signatureAlgorithm

Champs CertificateList

   CertificateList est une séquence de 3 champs requis. Les champs sont décris en détail ci-dessous.

tbsCertList

   Le premier champ dans la séquence est le tbsCertList. Ce champ est lui-même une séquence contenant le nom du fournisseur, une date d'émission, une date d'émission de la prochaine liste, la liste optionnelle des certificats révoqués, et les extensions de CRL optionnels. Quand il n'y a pas de certificats révoqués, la liste des certificats révoqués est absent. Quand un ou plusieurs certificats sont révoqués, chaque entrée dans la liste de certificat révoqués est définie par une séquence de numéro de série de certificat utilisateur, d'une date de révocation, et des extensions d'entrée de CRL optionnels.

signatureAlgorithm

   Le champ signatureAlgorithme contient l'identifiant pour l'algorithme utilisé par le fournisseur de CRL pour signer le CertificateList. Le champ est de type AlgorithmIdentifier, mais d'autres algorithmes de signatures peuvent être supportés. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertList.

signatureValue

   Le champ signatureValue contient une signature numérique calculée sur le tbsCertList encodé DER ASN.1, qui est utilisé en entrée de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signatureValue de la CRL. Les détails de ce processus sont spécifiés pour chacun des algorithmes supportés dans les rfc3279, rfc4055, et rfc 4491.

   Les CA qui sont également fournisseurs de CRL peuvent utiliser une seul clé privée pour signer numériquement les certificats et les CRL, ou peuvent utiliser des clé privées séparées. Quand des clés privées séparés sont utilisées, chaque clé publique associée avec les clés ces clés privée sont placées dans un certificat séparé, une avec le bit keyCertSign mis dans l'extension d'utilisation de clé, et une avec le bit cRLSign mis dans l'extension d'utilisation de clé. Quand des clés privée séparés sont utilisés, les certificats émis par la CA contiennent un seul identifiant de clé d'autorité, et les CRL correspondantes contiennent un identifiant de clé d'autorité différent.

   L'utilisation de certificats CA séparés pour la validation des signature de certificat et de CRL peut offrir de caractéristiques de sécurité améliorés; cependant, cela impose une charge dans les applications, et peut limiter l'interopérabilité. De nombreuses application construisent un chemin de certification, puis le valide. La vérification de CRL nécessite un chemin de certification séparé pour la validation de la signature de la CRL. Les applications qui vérifient la CRL doivent supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec la même clé privée, et devraient supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec des clé différentes.

Certificate List To Be Signed

   La liste de certificat signée, ou TBSCertList, est une séquence de champs requis et optionnels. Les champs requis identifient le fournisseur de la CRL, l'algorithme utilisé pour signer la CRL, et la date d'émission de la CRL.

   Les champs optionnels incluent la date à laquel le fournisseur de CRL va émettre la prochaine CRL, les listes de certificats révoqués, et les extensions de CRL. La liste de certificats révoqués est optionnel pour supporter le cas où une CA n'a pas de certificats révoqué. Ce profile nécessite que les fournisseurs de CRL conformes incluent le champ nextUpdate et les extensions de CRL d'identifiant de clé d'autorité et de numéro.

Version

   Ce champ optionnel décris la version de la CRL encodée. Quand les extensions sont utilisées, comme requis par ce profile, ce champ doit être présent et doit spécifier la version 2 (valeur 1).

Signature

   Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé pour signier la CRL. la rfc3279, rfc4055, et rfc 4491 listent les OID pour les algorithmes de signature les plus populaires utilisés dans les PKI de l'Internet.

Issuer Name

   Le nom du fournisseur identifie l'entité qui a signé et fournis la CRL. L'identité du fournisseur est placé dans le champ issuer. Les formes de noms Alternatives peuvent également apparaître dans l'extension issuerAltName. Le champ issuer doit contenir un DN X.500 non-vide. Le champ issuer est définis comme nom de type X.501, et doit suivre les rêgles d'encodage pour le champs du nom du fournisseur dans le certificat.

This Update

   Ce champ indiques la date d'émission de cette CRL. thisUpdate peut être encodé en UTCTime ou GeneralizedTime. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en UTCTime pour les dates avant 2050. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en GeneralizedTime pour des dates après 2049. Les application conformes doivent être capable de traiter les dates qui sont encodé en UTCTime ou GeneralizedTime.

   Quand encodé en UTCTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Next Update

   Ce champ indique la date à laquelle la prochaine CRL sera fournie. La prochaine CRL pourrait être fournie avant cette date, mais ne sera pas fournis après cette date. Les fournisseurs de CRL devraient fournir les CRL avec un temps nextUpdate égale à ou supérieurs à tous les CRL précédentes. nextUpdate peut être encodé en UTCTime ou GeneralizedTime.

   Les fournisseurs de CRL conformes doivent inclure le champ nextUpdate dans toutes les CRL. Noter que la syntaxe ASN.1 de TBSCertList décris ce champ comme optionnel, qui est consistant avec la structure ASN.1 définis dans X.509. Le comportement des clients traitant les CRL qui omettent nextUpdate n'est pas définis par ce profile.

   Les fournisseurs de CRL conformes à ce profile doivent encoder nextUpdate en UTCTime pour les dates avant 2050 et en GeneralizedTime pour les dates après 2049. Les application conformes doivent être capable de traiter les dates encodés en UTCTime ou GeneralizedTime.

   Quand encodé en UTCTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Revoked Certificates

   Quand il n'y a pas de certificats révoqués, la liste des certificats révoqué doit être absent. Sinon, les certificats révoqués sont listés par leur numéro de série. Les certificats révoqués par la CA sont identifiés de manière unique par ce numéro de série. La date à laquelle la révocation se produit est spécifiée. La date pour revocationDate doit être exprimée comme décris dans la section thisUpdate. Des informations additionnelles peuvent être fournis dans les extensions d'entrée de CRL.

Extensions

   Ce champ peut seulement apparaître si la version est 2. Si présent, ce champ est une séquence d'une ou plusieurs extensions de CRL.

Extensions de CRL

   Les extensions définis par ANSI X9, ISO/IEC, et l'ITU-T pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec les CRL. Le format de CRL X.509 v2 permet également des extensions privées. Chaque extension dans une CRL peut être conçue comme critique ou non. Si une CRL contient une extension critique que l'application en peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions non-critiques non reconnus. Les sections suivantes présentent ces extensions utilisées avec les CRL de l'internet. Les communautés peuvent choisir d'inclure des extensions dans les CRL qui ne sont pas définies dans cette spécification. Cependant, une attention particulière doit être faite pour l'adoptions d'extensions critiques dans les CRL qui pourraient être utilisées dans un contexte général.

   Les fournisseurs de CRL conformes doivent inclure les extensions d'identifiant de clé d'autorité et de numéro de CRL dans toutes les CRL émises.

Authority Key Identifier

   L'extension d'identifiant de clé d'autorité fournis un moyen d'identifier la clé publique correspondante à la clé privée utilisée pour signer une CRL. L'identification peut être basée sur l'identifiant de clé (l'identifiant de clé du sujet dans le certificat du signataire de la CRL) ou le nom et le numéro de série du fournisseur. Cette extension est spécialement utile où un fournisseur a plus d'une clé de signature, soit dû à plusieurs paires de clé concurrentes, ou dû à un changement.

   Les fournisseurs de CRL conformes doivent utiliser la méthode d'identifiant de clé, et doivent inclure cette extension dans toutes les CRL émise. La syntaxe pour cette extension de CRL est définie dans la section Authority Key Identifier.

Issuer Alternative Name

   L'extension de nom alternatif de fournisseur permet d'associer des identités alternatives avec le fournisseur de CRL. Les options définies incluent une adresse de messagerie électronique (rfc822Name), un nom DNS, une adresse IP, et une URI. Plusieurs instances d'une forme de nom et plusieurs formes de noms peuvent être inclus. Quand de telles identités sont utilisées, l'extension de nom alternatif de fournisseur doit être utilisé; cependant, un nom DNS peut être représenté dans le champ issuer en utilisant l'attribut domainComponent décris dans la section Issuer.

   Les fournisseurs de CRL conformes devraient marquer l'extension issuerAltName comme non-critique. L'OID et la syntaxe pour cette extension de CRL sont définis dans la section Issuer Alternative Name précédente.

CRL Number

   Le numéro de CRL est une extension de CRL non-critique qui transmet un numéro de séquence croissant monotone pour un scope de CRL et un fournisseur de CRL donné. Cette extension permet aux utilisateurs de facilement déterminer quand une CRL particulière remplace une autre CRL. Les numéros de CRL supportent également l'identification de CRL complètes et de CRL delta complémentaires. Les fournisseurs de CRL conformes à ce profile doivent inclure cette extension dans toutes les CRL et doivent marquer cette extension non-critique.

   Si un fournisseur de CRL génère des CRL delta en plus de CRL complètes pour un scope donné, les CRL complète et delta doivent partager une séquence de numéro. Si une CRL delta et une CRL couvrant le même scope sont émis en même temps, elles doivent avoir le même numéro de CRL et fournir la même information de révocation. C'est à dire, la combinaison de la CRL delta et une CRL complète acceptable doivent fournir la même information de révocation que la CRL complète.

   Si un fournisseur de CRL génère 2 CRL ( 2 CRL complètes, 2 CRL delta, ou une CRL complète et une CRL delta) pour le même scope à des moments différents, les 2 CRL ne doivent pas avoir le même numéro de CRL, c'est à dire, si le champ thisUpdate dans les 2 CRL ne sont pas identiques, les numéros de CRL doivent être différents.

En considération, les numéro de CRL peuvent être de long entiers. Les vérificateurs de CRL doivent être capable de gérer des valeur CRLNumber jusqu'à 20 octets. Les fournisseurs de CRL conformes ne doivent pas utiliser de valeurs CRLNumber plus long que 20 octets.
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
    
CRLNumber ::= INTEGER (0..MAX)

Delta CRL Indicator

   L'indicateur de CRL delta est une extension de CRL critique qui identifie qu'une CRL est une CRL delta. Les CRL delta contiennent des mises à jours d'information de révocation précédemment distribuée. L'utilisation de CRL delta peut significativement réduire la charge réseaux et le temps de traitement dans certains environnements. Les CRL delta sont généralement plus petites que les CRL qu'elles mettent à jours, donc les applications qui obtiennent les CRL delta consomment moins de bande passante que les applications qui obtiennent les CRL complètes correspondantes. Les applications qui stockent les informations de révocation dans un format autre que la structure CRL peuvent ajouter les nouvelles information de révocation dans la base locale sans retraiter les informations.

   L'extension d'indication de CRL delta contient une valeur simple de type BaseCRLNumber. Le numéro de CRL identifie la CRL, complète pour un scope donné, qui a été utilisé comme point de départ dans la génération de cette CRL delta. Un fournisseur de CRL conforme doit publier la CRL de base référencée ou une CRL complète. La CRL delta contient toutes les mises à jours de statut de révocation pour ce même scope. La combinaison d'une CRL delta et de la CRL de base référencée est équivalente à une CRL complète, pour le périmètre applicable, au moment de la publication de la CRL delta.

   Quand un fournisseur de CRL conforme génère une CRL delta, la CRL delta doit inclure une extension d'indication de CRL delta.

   Quand une CRL delta est émise, elle doit couvrir le même jeu de raisons et le même jeu de certificats qui sont couverts par la CRL de base qu'elle référence. C'est à dire que le scope de la CRL delta doit être le même que le scope de la CRL complète référencée comme base. La CRL de base référencée et la CRL delta doivent omettre l'extension de point de distribution d'émission ou doivent contenir des extensions de point de distribution d'émission identique. De plus, le fournisseur de CRL doit utiliser la même clé privée pour signer la CRL delta et toute CRL complète qui peut être utilisée pour les mises à jours.

   Une application qui supporte les CRL delta peuvent construire une CRL qui est complète pour un scope donné en combinant une CRL delta pour ce scope avec soit une CRL émise qui est complète pour ce scope ou une CRL construite localement, qui est complète pour ce scope.

   Quand une CRL delta est combinée avec une CRL complète ou une CRL construite localement, la CRL construite localement résultante a le numéro de CRL spécifié dans l'extension de numéro de CRL trouvé dans la CRL delta utilisée dans sa construction. En plus, le CRL construite localement résultante a les temps thisUpdate et nextUpdate spécifiés dans les champs correspondant de la CRL delta utilisés dans sa construction. En plus, la CRL construite localement hérite du point de distribution d'émission de la CRL delta.

   Une CRL complète et une CRL delta peuvent être combinés si les 4 conditions suivantes sont satisfaites:

(a) La CRL complète et la CRL delta ont le même fournisseur
(b) La CRL complète et la CRL delta ont le même périmètre. Les 2 CRL ont le même périmètre si une des conditions suivantes est satisfaite:

        (1) L'extension issuingDistributionPoint est omis de la CRL complète et de la CRL delta
        (2) L'extension issuingDistributionPoint est présente dans la CRL complète et la CRL delta est sont identiques.

(c) Le numéro de CRL de la CRL complète est égale ou supérieur au BaseCRLNumber spécifié dans la CRL delta. C'est à dire que la CRL complète contient (au minimum) toutes les informations de révocation maintenus par la CRL de base référencée.
(d) Le numéro de CRL de la CRL complète est inférieur au numéro de CRL de la CRL delta. C'est à dire, la CRL delta suit la CRL complète dans la séquence de numérotation.

   Les fournisseurs de CRL doivent s'assurer que la combinaison d'une CRL delta et toute CRL complète appropriée réflète précisément le statut de révocation. Le fournisseur e CRL doit inclure une entrée dans la CRL delta pour chaque certificat dans le scope de la CRL delta dont le status a changé depuis la génération de la CRL de base référencée:

(a) Si le certificat est révoqué pour une raison inclue dans le scope de la CRL, liste le certificat révoqué.
(b) Si le certificat est valide et a été listé dans la CRL de base référencée ou toute CRL suivantes avec un code de raison certificatHold est inclus dans le scope de la CRL, liste le certificat avec le code de raison removeFromCRL.
(c) Si le certificat est révoqué pour une raison hors du scope de la CRL, mais que le certificat a été listé dans la CRL de base référencée ou toute CRL suivante avec un code de raison inclus dans le scope de cette CRL, liste le certificat comme révoqué mais omet le code de raison.
(d) Si le certificat est révoqué pour une raison hors du scope de la CRL est que le certificat n'est ni listé dans la CRL de référence ni dans les CRL suivantes avec un code un code de raison inclus dans le scope de cette CRL, ne pas lister le certificat dans cette CRL.

   Le statut d'un certificat est considéré comme ayant changé s'il est révoqué (pour n'importe quelle raison, incluant certificateHold), s'il est libéré de l'attente, ou si sa raison de révocation change.

   Il est approprié de lister un certificat avec un code de raison removeFromCRL dans une CRL delta même si le certificat n'était pas en attente dans la CRL de base référencée. Si le certificat a été placé en attente dans une CRL émise après la base mais avant cette CRL delta puis relachée, il doit être listé dans le CRL delta avec une raison de révocation removeFromCRL.

   Un fournisseur de CRL peut optionnellement lister un certificat dans une CRL delta avec le code de raison removeFromCRL si le temps notAfter spécifié dans le certificat précède le temps thisUpdate spécifié dans la CRL delta et que le certificat était listé dans la CRL de base référencée. ou dans toute CRL émise après la base mais avant cette CRL delta.

   Si une révocation de certificat apparaît dans une CRL delta, il est possible pour que la période de validité du certificat expire avant la prochaine CRL complète pour le même scope. Dans ce cas, La notification de révocation doit être inclue dans toutes les CRL delta suivantes jusqu'à ce que la notification de révocation soit inclue dans au moins une CRL complète émise pour ce scope.

   Une application qui supporte les CRL delta doit être capable de construire une CRL complète courante en combinant une CRL complète et la CRL delta la plus récente. Une application qui supporte les CRL delta peut également être capable de construire une CRL complète courante en combinant une CRL complète construite localement et la CRL delta courante. Une CRL delta est considérée courante si le date courante est entre les temps contenus dans thisUpdate et nextUpdtae. Sous certaines circonstances, le fournisseur de CRL peut publier une ou plusieurs CRL avant le temps indiqué par le champ nextUpdate. Si plus d'une CRL delta courante est rencontré pour un scope donné, l'application devrait être considérée celle ayant la valeur thisUpdate la plus récente comme courante.


id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
    
BaseCRLNumber ::= CRLNumber

Issuing Distribution Point

   Le point de distribution d'émission est une extension de CRL critique qui identifie le point de distribution de CRL et le scope pour une CRL particulière, et indique si la CRL couvre la révocation des certificat d'entités finaux uniquement, des certificats CA uniquement, ou un jeu limité de codes de raisons. Bien que cette extension soit critique, les implémentations conformes ne sont pas obligés de supporter cette extension. Cependant, les implémentations qui ne supportent pas cette extension doivent soit traiter le statut des certificats non listés dans cette CRL comme inconnu ou localiser une autre CRL qui ne contient pas d'extensions critique non-reconnues.

   La CRL est signée en utilisant la clé privée du fournisseur. Les points de distribution de CRL n'ont pas leur propre paires de clé. Si la CRL est stockée dans un annuaire X.500, elle est stockée dans l'entrée d'annuaire correspondant au point de distribution e CRL, qui peut être différent de l'entrée d'annuaire du fournisseur de CRL.

   Les codes de raison associées avec un point de distribution doivent être spécifiés dans onlySomeReasons. Si onlySomeReasons n'apparaît pas, le point de distribution doit contenir les révocation pour tous les codes de raison. Les CA peuvent utiliser les points de distribution de CRL pour partitionner la CRL sur la base de révocation de routine et de compromission. Dans ce cas, les révocations avec le code de raison keyCompromise, cACompromise, et aACompromise apparaissent dans un point de distribution, et les révocations avec d'autres codes de raison apparaissent dans un autre point de distribution.

   Si une CRL inclus une extension issuingDistributionPoint avec onlySomeReasons présent, alors tout certificat dans le scope de la CRL qui est révoqué doit être assigné à un code de raison autre qui unspecified. La raison de révocation assignées est utilisée pour déterminer dans quelle CRL lister le certificat révoqué, cependant, il n'est pas requis d'inclure l'extension d'entrée de CRL reasonCode dans l'entrée de CRL correspondant.

   La syntaxe et les sémantiques pour le champ distributionPoint sont les même que pour le champ distributionPoint dans l'extension cRLDistributionPoints. Si le champ distributionPoint est présent, alors il doit inclure au moins un des noms du distributionPoint correspondant de l'extension cRLDistributionPoints de tout certificat qui est dans le scope de cette CRL. L'encodage identique doit être utilisé dans les champs distributionPoint du certificat et de la CRL.

   Si le champ distributionPoint est absent, le CRL doit contenir des entrées pour tous les certificats révoqués non-expirés fournis par le fournisseur de CRL, dans le scope de la CRL.

   Si le scope de la CRL inclus uniquement les certificats émis par le fournisseur de CRL, alors le booléen indirectCRL doit être FALSE. Sinon, si le scope de la CRL inclus des certificats fournis par une ou plusieurs autres autorités, indirectCRL doit être à TRUE. L'autorité responsable pour chaque entrée est indiquée par le fournisseur de certificat de l'extension d'entrée de CRL.

   Si le scope de la CRL inclus uniquement des certificats à clé publique d'entité final, alors onlyContainsUserCerts doit être à TRUE. Si le scope de la CRL inclus seulement des certificats CA, alors onlyContainsCACerts doit être à TRUE. Si onlyContainsUserCerts ou onlyContainsCACerts est à TRUE, alors le scope de la CRL ne doit pas inclure de certificats version 1 ou version 2. Les fournisseurs de CRL conformes doivent définir le booléen onlyContainsAttributeCerts à FALSE.

   Les fournisseurs de CRL conformes ne doivent pas émettre de CRL où l'encodage DER de l'extension de point de distribution du fournisseur est une séquence vide. C'est à dire que si onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, et onlyContainsAttributeCerts sont à FALSE, alors soit le champ distributionPoint soit le champ onlySomeReasons doit être présent.


id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
    
IssuingDistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
    onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
    onlySomeReasons [3] ReasonFlags OPTIONAL,
    indirectCRL [4] BOOLEAN DEFAULT FALSE,
    onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
    
     -- au moins un parmis onlyContainsUserCerts, onlyContainsCACerts, et onlyContainsAttributeCerts doit être à TRUE.

Freshest CRL

   L'extension freshest CRL identifie comment les informations de CRL delta pour cette CRL complète est obtenue. Les fournisseurs conformes doivent marquer cette extension non-critique. Cette extension ne doit pas apparaître dans les CRL delta.

   La même syntaxe est utilisée pour cette extension que dans l'extension de certificat cRLDistributionPoints. Cependant, seul le champ de point de distribution est significatif dans ce contexte. Les champs raison et cRLIssuer doivent être omis de cette extension de CRL.

Chaque nom de point de distribution fournis l'emplacement auquel une CRL delta pour cette CRL complète peut être trouvée. Le scope de ces CRL delta doit être le même que le scope de la CRL complète. Le contenu de cette extension de CRL est seulement utilisé pour localiser les CRL delta; le contenu n'est pas utilisé pour valider la CRL ou les CRL delta.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
    
    FreshestCRL ::= CRLDistributionPoints

Authority Information Access

   Cette section définis l'utilisation de l'extension d'accès aux informations d'autorité dans une CRL. La syntaxe et les sémantiques définis pour l'extension de certificat du même nom sont également utilisé pour l'extension de CRL. Cette extension de CRL doit être marquée non-critique.

   Quand présent dans une CRL, cette extension doit inclure au moins un AccessDescription spécifiant l'id-ad-caIssuers comme accessMethod. L'OID id-ad-caIssuers est utilisé quand l'information disponible liste les certificats qui peuvent être utilisés pour vérifier la signature dans la CRL (par exemple, les certificats qui ont un nom de sujet qui correspond à la clé privée utilisé pour signer la CRL). Les types de méthode d'accès autre que id-ad-caIssuers ne doivent pas être inclus. Au moins une instance de AccessDescription devrait spécifier un URI accessLocation HTTP ou LDAP.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer vers soit un simple certificat encodé DER soit une collection de certificats dans une message CMS "certs-only" encodé en DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats individuels encodés DER et devraient être capable d'accepter les messages CMS "certs-only".

   Les implémentations de serveurs HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert dans le champ dans le champ d'en-tête content-type de la réponse pour un simple certificat encodé DER et devraient spécifier le type de média application/pkcs7-mime dans le champ d'en-tête content-type de la réponse pour les message CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir un suffix ".cer" et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir le suffix ".p7c". Les client peuvent utiliser le type de média ou l'extension de fichier comme indicateur de contenu, mais ne devraient pas s'en contenter.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application via le serveur configuré localement. Quand une clé publique de CA est utilisée pour valider les signatures dans les certificats et CRL, le certificat de CA désiré est stocké dans les attributs crossCertificatePair et/ou cACertificate. quand différentes clé publique sont utilisées pour valider les signatures dans les certificats et les CRL, le certificat désiré est stocké dans l'attribut userCertificate. Donc, les implémentations qui supportent la forme directoryName de accessLocation doivent être préparés à trouver le certificat nécessaire dans n'importe lequel de ces attributs. Le protocole qu'une application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponibles via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant de nom distinct de l'entrée maintenant les certificats, doit inclure un champ attributes qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devrait inclure un hôte (ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

CRL Entry Extensions

   Les extensions d'entrée de CRL définis par l'ISO/IEC, ITU-T, et ANSI X9 pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec des entrées de CRL. Le format de CRL X.509 v2 permet également aux communautés de définir des extensions d'entrée de CRL privées pour gérer les informations spécifiques de ces communautés. Chaque extension dans une entrée de CRL peut être désignée comme critique ou non. Si une CRL contient une extension d'entrée de CRL critique qui l'application ne peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions d'entrées de CRL non-critique non reconnus.

   Le support pour les extensions d'entrée de CRL définis dans cette spécification est optionnel pour les fournisseurs de CRL et les applications conformes. Cependant, les fournisseurs de CRL devraient inclure des codes de raison et des dates d'invalidité quand cette information est disponible.

Reason Code

   Le reasonCode est une extension d'entrée de CR non-critique qui identifie la raison pour la révocation du certificat. Les fournisseurs de CRL sont fortement encouragés à inclure des codes de raison significatifs dans les entrées de CRL. Cependant, l'extension d'entrée de CRL de code de raison devrait être absent au lieu d'utiliser la valeur reasonCode unspecified.

   La valeur de reasonCode removeFromCRL peut seulement apparaître dans les CRL delta, et indique qu'un certificat à été supprimé de la CRL soit parce qu'il a expiré, soit parce qu'il n'est plus en attente. Toutes les autres raisons peuvent apparaître dans les CRL et indique que le certificat spécifié devrait être considéré révoqué.


id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
    
    -- reasonCode ::= { CRLReason }
    
CRLReason ::= ENUMERATED {
    unspecified (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    -- La valeur 7 n'est pas utilisée
    removeFromCRL (8),
    privilegeWithdrawn (9),
    aACompromise (10) }

Invalidity Date

   La date d'invalidité est une extension d'entrée de CRL non-critique qui fournis la date à laquelle on sait, ou on suspecte qui la clé privée a été compromise ou que le certificat est devenu invalide. Cette date peut être antérieur à la date de révocation dans l'entrée de CRL, qui est la date à laquelle la CA a procédé à la révocation. Quand une révocation est postées d'abord par un fournisseur de CRL dans une CRL, la date d'invalidité peut précéder la date d'émission des premières CRL, mais la date de révocation ne devrait pas précéder la date d'émission des premières CRL. Quand cette information est disponible, les fournisseurs de CRL sont fortement encouragés à la partager avec les utilisateurs de CRL.

Les valeurs GeneralizedTime inclus dans ce champ doit être exprimés en GMT, et doivent être spécifiés et interprétés comme définis dans la section "GeneralizedTime".
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
    
InvalidityDate ::= GeneralizedTime

Certificate Issuer

   Cette extension d'entrée de CRL identifie le fournisseur de certificat associé avec une entrée dans une CRL indirecte, c'est à dire, une CRL qui a l'indicateur indirectCRL mis dans sont extension de point de distribution d'émission. Quand présent, l'extension d'entrée de CRL de fournisseur de certificat inclus un ou plusieurs noms du champ issuer et/ou de l'extension de noms alternatif du sujet du certificat qui correspond à l'entrée de la CRL. Si cette extension n'est pas présente dans la première entrée dans une CRL indirecte, le fournisseur de certificat par défaut est le fournisseur de CRL. Dans les entrées suivantes, si cette extension n'est pas présente, le fournisseur de certificat pour l'entrée est la même que pour l'entrée précédente. Ce champ est définis comme suit:


id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
    
CertificateIssuer ::= GeneralNames

   Les fournisseurs de CRL conformes doivent inclure dans cette extension le dn du champ issuer du certificat qui correspond à cette entrée de CRL. L'encodage du DN doit être identique à l'encodage utilisé dans le certificat.

   Les fournisseurs de CRL doivent marquer cette extension critique vu que l'implémentation qui ignore cette extension ne peut pas correctement attribuer les entrées de CRL aux certificats. Cette spécification recommande que les implémentations reconnaissent cette extension.

Validation de chemin de certification

   Les procédures de validation de chemin de certification pour les PKI de l'Internet sont basés sur l'algorithme fournis dans X.509. Le traitement des chemins de certification vérifie la liaison entrée le nom distinct du sujet et/ou le nom alternatif du sujet et la clé publique du sujet. La liaison est limitée par les contraintes qui sont spécifiées dans les certificats qui comprennent le chemin et les entrées qui sont spécifiés par les tiers de confiance. Les extensions de contraintes de base et de contraintes de stratégie permettent à la logique de traitement de chemin de certification d'automatiser le processus de prise de décision.

   Cette section décris un algorithme pour valider les chemins de certification. Les implémentations conformes de cette spécification ne sont pas obligés d'implémenter cet algorithme, mais doivent fournir une fonctionnalité équivalente au fonctionnement résultant de cette procédure. Tout algorithme peut être utilisé par une implémentation particulière tant qu'elle dérive le résultat correcte.

   Dans la section suivante, le texte décris la validation basique de chemin . Les chemins valides commencent avec des certificats fournis par une entité de confiance. L'algorithme nécessite la clé publique de la CA, le nom de la CA, et toutes les contraintes sur le jeu de chemins qui peuvent être validés en utilisant cette clé.

   La sélection d'une entité de confiance est une décision de stratégie locale: il peut être le CA supérieur dans une PKI hiérarchique, la CA qui a fournis le certificat du vérificateur, ou toute autre CA dans le réseau PKI. La procédure de validation de chemin est la même quelque soit l'entité de confiance. En plus, différentes applications peuvent faire confiance à plusieurs entités, ou peuvent accepter des chemins qui commencent avec un jeu d'entité de confiance.

Validation de chemin basique

   Ce texte décris un algorithme pour le traitement de chemin X.509. Une implémentation conforme doit inclure une procédure de traitement de chemin X.509 qui est fonctionnellement équivalente à la sortie de cet algorithme. Cependant, le support pour certains extensions de certificat traités dans cet algorithme sont optionnels pour les implémentations conformes. Les clients qui ne supportent pas ces extensions peuvent omettre les étapes correspondantes dans l'algorithme de validation de chemin.

   Par exemple, les clients ne sont pas obligés de supporter l'extension de mappage de stratégie. Les clients qui ne supportent pas cette extension peuvent omettre les étapes de validation de chemin où le traitement du policy mappings sont traités. Noter que les clients doivent rejeter le certificat s'il contient une extension critique non-supportée.

   Bien que les profiles de certificat et de CRL spécifiés dans ce document spécifient des valeurs pour les champs et les extensions de certificat et de CRL considérés appropriés pour les PKI de l'Internet, l'algorithme présenté dans cette section n'est pas limité à accepter les certificats et CRL qui se conforment à cet profiles. Cependant, l'algorithme inclus uniquement les vérifications de chemint de certification valide en accord avec X.509 et n'inclus pas les vérifications de conformité des certificats et CRL avec ce profile. Bien que l'algorithme pourrait être étendu pour inclure des vérifications de conformité avec les profiles de ce document, ce profile recommande de ne pas inclure de telles vérification.

   L'algorithme présenté dans cette section valide le certificat en respectant l'horodatage courant. Un application conforme peut également supporter la validation en respectant un point dans le passé. Noter que les mécanismes ne sont pas disponible pour valider un certificat en dehors de sa période de validité.

   L'entité de confiance est une entrée de l'algorithme. Il n'y a pas d'obligation que la même entité de confiance soit utilisée pour valider tous les chemins de certification. Plusieurs entités de confiance peuvent être utilisés pour valider différents chemins.

   Le but premier de la validation de chemin est de vérifier le lien entre un nom distinct du sujet ou un nom alternatif du sujet et la clé publique du sujet, tel que représenté dans le certificat cible, basé sur la clé publique de l'entité de confiance. Dans la plupart des cas, le certificat cible sera un certificat d'entité finale, mais le certificat cible peut être un certificat de CA tant que la clé publique du sujet est utilisée dans un but autre que vérifier la signature dans certificat à clé publique. Vérifier le lien entre le nom et la clé publique nécessite d'obtenir une séquence de certificats qui supportent ce lien. La procédure effectuée pour obtenir cette séquence de certificat est hors du scope de cette spécification.

   Dans ce but, le processus de validation de chemin vérifie, entre autre, qu'un chemin de certification éventuel ( une séquence de n certificats ) satisfait les conditions suivantes:

(a) Pour tout x dans { 1, ..., n-1 }, le sujet des certificats x est le fournisseur du certificat x+1
(b) le certificat 1 est fournis par l'entité de confiance
(c) Le certificat n est le certificat à valider
(d) Pour tout x dans { 1, ..., n }, le certificat était valide à l'époque en question

   Un certificat ne doit pas apparaître plus d'une fois dans une chemin de certification éventuel.

   Quand l'entité de confiance est fournis sous la forme d'un certificat auto-signé, ce certificat n'est pas inclus comme partie du chemin de validation éventuel. Les informations sur l'entité de confiance est fournis en entrée de l'algorithme de validation de chemin de certification.

   Un chemin de validation de certification particulier ne peut pas, cependant, être approprié pour toutes les applications. Une application peut augmenter cet algorithme pour limiter le jeu de stratégie de certificat qui sont valides pour ce chemin, basé sur l'extension de stratégies de certificat, l'extension de mappage de stratégie, l'extension de contraintes de stratégie, et inhiber l'extension anyPolicy. Pour accomplir cela, l'algorithme de validation de chemin construit une arborescence de stratégie valide. Si le jeu de stratégies de certificat qui sont valides pour ce chemin n'est pas vide, alors le résultat sera une arborescence de stratégie valide de profondeur n, sinon le résultat sera une arborescence de stratégie valide null.

   Un certificat est auto-fournis si le même DN apparaît dans les champs sujets et fournisseur. En général, le fournisseur et le sujet des certificat qui constituent un chemin sont différents pour chaque certificat. Cependant, une CA peut fournir un certificat à elle-même pour supporter le changement de clé ou de stratégies de certificat. Ces certificats auto-fournis ne sont pas comptés dans l'évaluation de la longueur de chemin ou les contraintes de nom.

   Cette section présente l'algorithme en 4 étapes de base: initialisation, traitement de certificats de base, préparation pour le certificat suivant, et la conclusion. Les étapes 1 et 4 sont effectuées exactement 1 seule fois, l'étape 2 est effectuée pour tous les certificats dans le chemin, et l'étape 3 est effectuée pour tous les certificats dans le chemin excepté le certificat final. La figure suivante fournis une vue générale de cet algorithme:


___________________________+- - - -+
___________________________|_START_|
___________________________+- - - -+
_______________________________|
_______________________________V
_______________________+- - - - - - - - +
_______________________|_Initialization_|
_______________________+- - - - - - - - +
_______________________________|
_______________________________+‹- - - - - - - - - - +
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+- - - - - - - - +____________|
_______________________|__Process_Cert__|____________|
_______________________+- - - - - - - - +____________|
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+================+____________|
_______________________|__IF_Last_Cert__|____________|
_______________________|____in_Path_____|____________|
_______________________+================+____________|
_________________________|____________|______________|
____________________THEN_|____________|_ELSE_________|
_________________________V____________V______________|
______________+- - - - - - - - +_+- - - - - - - - +__|
______________|____Wrap_up_____|_|__Prepare_for___|__|
______________+- - - - - - - - +_|___Next_Cert____|__|
______________________|__________+- - - - - - - - +__|
______________________V_______________|______________|
__________________+- - - -+___________+- - - - - - - +
__________________|_STOP__|
__________________+- - - -+

Entrées

   Cet algorithme assume que les 9 entrées suivantes sont fournis au traitement de chemin:

(a) Une chemin de certification éventuel de longueur n
(b) La date et heure courante
(c) user-initial-policy-set, nommant les stratégies qui sont acceptables pour l'utilisateur de certificat. Le user-initial-policy-set contient la valeur spéciale any-policy si l'utilisateur n'est pas concerné par les stratégies de certificat.
(d) Informations de l'entité de confiance qui incluent:

        (1) Le nom du fournisseur de confiance
        (2) L'algorithme de clé publique de confiance
        (3) La clé publique de confiance
        (4) Optionnellement, les paramètres de clé publique associés à la clé publique.

   Les informations de l'entité de confiance peuvent être fournis à la procédure de traitement de chemin sous la forme d'un certificat auto-signé. Quand les information de l'entité de confiance sont fournies sous la fourme d'un certificat, le nom dans le champ subject est utilisé comme nom de fournisseur de confiance et le contenu du champ subjectPublicKeyInfo est utilisé comme source de l'algorithme de clé publique de confiance et la de clé publique de confiance. Les informations d'entité de confiance sont de confiance parce qu'elles ont été délivrées à la procédure de traitement de chemin par une procédure digne de confiance. Si l'algorithme de clé publique de confiance nécessite des paramètres, alors les paramètres sont fournis avec la clé publique de confiance.

(e) initial-policy-mapping-inhibit, qui indique si le mappage de stratégie est permis dans le chemin de certification.
(f) initial-explicit-policy, qui indique si le chemin doit être valide pour au moins une des stratégie de certificat dans le user-initial-policy-set.
(g) initial-any-policy-inhibit, qui indique si l'OID anyPolicy devrait être traité s'il est inclus dans un certificat
(h) initial-permitted-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescences dans lequel tous les noms du sujet dans tous les certificats dans le chemin de certification doivent aller. Cette entrée doit inclure un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut consister d'une simple sous-arborescence qui inclus tous les noms de ce type de nom ou une ou plusieurs sous-arborescence qui chacune spécifie un sous-jeu de noms de ce type de nom, ou le jeu peut être vide. Si le jeu pour un type de nom est vide, alors le chemin de certification sera considéré invalide dans tous les certificats dans le chemin de certification qui inclus un nom de ce type de nom.
(i) initial-excluded-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats du chemin de certification ne peut aller. Cette entrée inclus un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut être vide ou peut consister d'une ou plusieurs sous-arborescences qui spécifient chacun un sous-jeu des noms de ce type de nom. Si le jeu pour un type de nom est vide, aucun nom de ce type de nom n'est exclus.

Initialization

   Cette phase d'initialisation établis 11 variables d'état basés sur les 9 entrées:

(a) valid_policy_tree: Une arborescence de stratégies de certificats avec leurs qualifiants optionnels; chaque branche de l'arborescence représente une stratégie valide à ce stade de la validation du chemin de certification. Si des stratégie valides existent à ce stade dans la validation du chemin de certification, la profondeur de l'arbre est égal au nombre de certificats dans la chaîne qui a été traitée. Si des stratégies valides n'existent pas à ce stade, l'arbre est null. Une fois l'arbre mis à NULL, le traitement de stratégie s'arrête.

        (1) valid_policy est un simple OID de stratégie représentant une stratégie valide pour le chemin de longueur x.
        (2) qualifier_set est un jeu de qualifiants de stratégie associés avec la stratégie valide dans le certificat x.
        (3) expected_policy_set contient un ou plusieurs OID de stratégie qui satisferait cette stratégie dans le certificat x+1.

   La valeur initiale de valid_policy_tree est un nœud simple avec pour valid_policy anyPolicy, un qualifier_set vide, et un expected_policy_set avec la seule valeur anyPolicy. Ce nœud a une profondeur de 0.

La figure suivante est une représentation graphique de l'état initial de valid_policy_tree. Les figures additionnelles vont utiliser ce format pour décrire les changement dans le valid_policy_tree durant le traitement du chemin.
______________+- - - - - - - - +
______________|___anyPolicy____|___‹- - _valid_policy
______________+- - - - - - - - +
______________|_______{}_______|___‹- - _qualifier_set
______________+- - - - - - - - +
______________|__{anyPolicy}___|___‹- - _expected_policy_set
______________+- - - - - - - - +

(b) permitted_subtrees: un jeu de noms racine pour chaque type de nom définissant un jeu de sous-arborescence dans lequel tous les noms du sujet dans les certificats suivant dans le chemin de certificat doivent tomber. Cette variable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-permitted-subtrees.
(c) excluded_subtrees: un jeu de noms racines pour chaque type de nom définissant un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats suivant dans le chemin de certification ne peut tomber. Cette valiable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-excluded-subtrees.
(d) explicit_policy: Un entier qui indique si un valid_policy_tree non-null est requis. L'entier indique le nombre de certificats non auto-fournis à traiter avant que ce requis soit imposé. Une fois définis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin requière un valid_policy_tree non-null, un certificat ultérieur ne peut pas supprimer ce requis. Si initial-explicit-policy est mis, alors la valeur initiale est 0, sinon la valeur initiale est n+1.
(e) inhibit_anyPolicy: un entier qui indique si l'identifiant de stratégie anyPolicy est considéré comme un match. L'entier indique le nombre de certificats non auto-fournis à traiter avant que l'OID anyPolicy, si indiqué dans un certificat autre qu'un certificat intermédiaire auto-fournis, est ignoré. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin inhibe le traitement de anyPolicy, un certificat ultérieur ne peut pas le permettre. Si initial-any-policy-inhibit est mis, alors la valeur initial est 0, sinon la valeur initial est n+1.
(f) policy_mapping: un entier qui indique si le mappage de stratégie est permis. L'entier indique le nombre de certificat non auto-fournis à traiter avant que le mappage de stratégie soit inhibé. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémenté. C'est à dire,, si un certificat dans le chemin spécifie que le mappage de stratégie n'est pa permis, il ne peut pas écrasé par un certificat ultérieur. Si initial-policy-mapping-inhibit est mis, la valeur initiale est 0, sinon la valeur est n+1.
(h) working_public_key: La clé publique utilisée pour vérifier la signature d'un certificat. working_public_key est initialiée depuis la clé publique de confiance fournis dans les informations de l'entité de confiance.
(i) working_public_key_parameters: Les paramètres associés avec la clé publique courante qui peut être requise pour vérifier une signature ( en fonction de l'algorithme). working_public_key_parameters est initialisée avec les paramètres de clé publique de confiance fournis dans les informations de l'entité de confiance.
(j) working_issuer_name: Le dn du fournisseur prévu dans le prochain certificat dans la chaîne. working_issuer_name est initialisé avec le dn du founisseur fournis la les informations de l'entité de confiance.
(k) max_path_length: Cet entier est initialisé à n, est décrémenté pour chaque certificat non auto-fournis dans le chemin, et peut être réduit à la valeur dans le champ de contrainte de longueur de chemin dans l'extension de contraintes de base d'un certificat de CA.

   Une fois ces étapes d'initialisation complétées, effectue les étapes de traitement de certificat de base.

Traitement de certificat de base

   Les actions de traitement de chemin de base à effectuer pour le certificat i ( pour tout i dans [1..n] ) sont les suivantes:

(a) Vérifie les informations de certificat de base. Le certificat doit satisfaire chacun des points suivants:

        (1) La signature dans le certificat peut être vérifié en utilisant working_public_key_algorithm, working_public_key, et working_public_key_parameters.
        (2) La période de validité du certificat inclus l'heure courante
        (3) Actuellement, le certificat n'est pas révoqué. Cela peut être déterminé en obtenant le CRL appropriée, par information de statut, ou par des mécanismes tiers.
        (4) Le nom du fournisseur de certificat est le working_issuer_name.

(b) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet est dans un des permitted_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs dans l'extension subjectAltName (critique ou non-critique) est dans un des permitted_subtrees pour ce type de nom.
(c) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet n'est pas dans le excluded_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs n'est pas dans un des excluded_subtrees pour ce type de nom.
(d) Si l'extension de stratégies de certificats est présent dans le certificat et le valid_policy_tree n'est pas null, traite les information de stratégie en effectuant les étapes suivantes dans l'ordre:

        (1) Pour chaque stratégie P non égal à anyPolicy dans l'extension de stratégie de certificat, P-OID dénote l'OID pour la stratégie P et P-Q dénote le jeu de qualifiant pour la stratégie P. Effectue les étapes suivantes dans l'ordre:

                (i) Pour chaque nœud de profondeur i-1 dans le valid_policy_tree où P-OID est dans le expected_policy_set, crée un nœud enfant comme suit: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, White}. Les stratégies de certificat Gold et Silver apparaissent dans l'extension de stratégie de certificat du certificat i. La stratégie Gold est matchée, mais la stratégie Silver ne l'est pas. Cette règle va générer un nœud enfant de profondeur i pour la stratégie Gold:
_____________________________+- - - - - - - - -+
_____________________________|_______Red_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i-1
_____________________________|__{Gold,_White}__|
_____________________________+- - - - - - - - -+
______________________________________|
______________________________________|
______________________________________|
______________________________________V
_____________________________+- - - - - - - - -+
_____________________________|______Gold_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i
_____________________________|_____{Gold}______|
_____________________________+- - - - - - - - -+

                (ii) S'il n'y avait pas de correspondance dans l'étape (i) et valid_policy_tree incluais un nœud de profondeur i-1 avec valid_policy anyPolicy, génère un nœud enfant avec les valeurs suivantes: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où valid_policy est anyPolicy. Les stratégie de certificat Gold et Silver apparaîssent dans l'extension de stratégies de certificat du certificat i. La stratégie Gold n'a pas de qualifiant, mais la stratégie Silver a le qualifiant Q-Silver. Si Gold et Silver ne correspondent pas dans (i), cette règle va générer 2 nœuds enfants de profondeur i, une pour chaque stratégie:
__________________________________+- - - - - - - - -+
___________________________________|____anyPolicy____|
___________________________________+- - - - - - - - -+
___________________________________|_______{}________|
___________________________________+- - - - - - - - -+_node_of_depth_i-1
___________________________________|___{anyPolicy}___|
___________________________________+- - - - - - - - -+
______________________________________/___________\
_____________________________________/_____________\
____________________________________/_______________\
___________________________________/_________________\
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|______Gold_______|__________|_____Silver______|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|_______{}________|__________|___{Q-Silver}____|
_____________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_____________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+

        (2) Si l'extension de stratégies de certificat inclus la stratégie anyPolicy avec le qualifiant AP-Q et soit (a) inhibit_anyPolicy est plus grand que 0 ou (b) i‹n et le certificat est auto-fournis, alors: Pour chaque nœud dans valid_policy_tree de profondeur i-1, pour chaque valeur dans expected_policy_set (inclant anyPolicy) qui n'apparaît pas dans un nœud enfant, crée un nœud enfant avec les valeurs suivantes: définis valid_policy à la valeur de expected_policy_set dans le nœud parent, définis qualifier_set à AP-Q, et définis expected_policy_set à la valeur dans valid_policy de ce nœud.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, Silver}. anyPolicy apparaît dans l'extension de stratégie de certificat i sans qualifiant de stratégie, mais Gold et Silver n'apparaît pas. Cette règle va générer 2 nœuds enfant de profondeur i, une pour chaque stratégie:
_______________________________+- - - - - - - - -+
_______________________________|______Red________|
_______________________________+- - - - - - - - -+
_______________________________|_______{}________|
_______________________________+- - - - - - - - -+_node_of_depth_i-1
_______________________________|__{Gold,_Silver}_|
_______________________________+- - - - - - - - -+
__________________________________/___________\
_________________________________/_____________\
________________________________/_______________\
_______________________________/_________________\
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|______Gold_______|__________|_____Silver______|
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|_______{}________|__________|_______{}________|
_________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_________________+- - - - - - - - -+__________+- - - - - - - - -+

        (3) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœud de profondeur i-1 ou moins dans enfant. Par exemple, on considère valid_policy_tree ci-dessous. Les 2 nœuds à la profondeur i-1 qui sont marqués avec un 'X' n'ont pas d'enfant, et sont supprimés. Appliquer cette règle à l'arbre résultant va cause le nœud à la profondeur i-2 qui est marqué avec un 'Y' d'être supprimé. Dans l'arbre résultant, il n'y a pas de nœuds de profondeur i-1 ou moins dans enfant, et cette étape est complète.

(e) Si l'extension de stratégies de certificat n'est pas présent, définis valid_policy_tree à NULL.
(f) Vérifie que soit explicit_policy est supérieur à 0 soit valid_policy_tree n'est pas égal à NULL

   Si une des étapes (a), (b), (c), ou (f) échoue, la procédure se termine, retournant une erreur indiquant un raison appropriée.

Si i n'est pas égal à n, continue en effectuant le étapes préparatoires listées dans la section suivante. Si i est égal à f, effectue les étapes listés dans la section d'après.
_________________________________+- - - - - -+
_________________________________|___________|_node_of_depth_i-3
_________________________________+- - - - - -+
_________________________________/_____|_____\
________________________________/______|______\
_______________________________/_______|_______\
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+
___________________|___________|_|___________|_|_____Y_____|_nodes_of
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+_depth_i-2
___________________/___\_______________|_____________|
__________________/_____\______________|_____________|
_________________/_______\_____________|_____________|
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|_____X_____|_|___________|_|____X______|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i-1
____________|______________________/____|____\
____________|_____________________/_____|_____\
____________|____________________/______|______\
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|___________|_|___________|_|___________|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i

Préparation pour le certificat i+1

   Pour préparer le traitement du certificat i+1, effectuer les étapes suivantes pour le certificat i:

(a) Si une extension de mappage de stratégie est présente, vérifie que la valeur spéciale anyPolicy n'apparaît pas comme un issuerDomainPolicy ou un subjectDomainPolicy.
(b) Si une extension de mappage de stratégie est présente, pour chaque issuerDomainPolicy ID-P dans l'extension de mappage de stratégie:

        (1) Si la variable policy_mapping est supérieur à 0, pour chaque nœud dans valid_policy_tree de profondeur i où ID-P est le valid_policy, définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiées comme équivalent à ID-P par l'extension de mappage de stratégie.
        Si aucun nœud de profondeurs i dans valid_policy_tree n'a un valid_policy à anyPolicy, génère un nœud enfant du nœud de profondeur i-1 qui a un valid_policy de anyPolicy comme suit:

                (i) Définis valid_policy à ID-P
                (ii) Définis qualifier_set au jeu de qualifiant de stratégie anyPolicy dans l'extension de stratégie de certificat du certificat i
                (iii) Définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiés comme équivalent à ID-P par l'extension de mappage de stratégie.

        (2) Si policy_mapping est égal à 0:

                (i) Supprime chaque nœud de profondeur i dans valid_policy_tree où ID-P est le valid_policy
                (ii) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœuds de profondeur i-1 ou moins sans enfant.

(c) Assigne le nom du sujet du certificat au working_issuer_name
(d) Assigne le subjectPublicKey du certificat au working_public_key
(e) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres non-null, assigne les paramètres à la variable working_public_key_parameters. Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres null ou les paramètres sont omis, compare l'algorithme subjectPublicKey au working_public_key_algorithm. Si l'algorithme subjectPublicKey du certificat et le working_public_key_algorithm sont différent, définis working_public_key_parameters à null.
(f) Assigne l'algorithme de subjectPublicKey du certificat à la variable working_public_key_algorithm
(g) Si une extension de contrainte de noms est inclue dans le certificat, modifie permitted_subtrees et excluded_subtrees comme suit:

        (1) Si permittedSubtrees est présent dans le certificat, définis la variable d'état permitted_subtrees à l'intersection de sa précédente valeur et de la valeur indiquée dans le champ de l'extension. Si permittedSubtrees n'inclus pas un type de nom particulier, la variable d'état permitted_subtrees est inchangée pour ce type de nom. Par exemple, l'intersection de example.com et foo.example.com est foo.example.com. Et l'intersection de example.com est example.net est un jeu vide.
        (2) Si excludedSubtrees est présent dans le certificat, définis la variable d'état excluded_subtrees à l'union de sa valeur précédente valeur et la valeur indiquée dans le champ de l'extension. si excludedSubtrees n'inclus par un type de nom particulier, la variable d'état excluded_subtrees n'est pas changée pour ce type de nom. Par exemple, l'union de l'espace de nom example.con et foo.example.com est example.com. Et l'union de example.com et example.net est les 2 espaces de nom.

(h) Si le certificat i n'est pas auto-fournis:

        (1) Si explicit_policy n'est pas 0, décrémente de 1
        (2) Si policy_mapping n'est pas 0, décrémente de 1
        (3) Si inhibit_anyPolicy n'est pas 0, décrémente de 1

(i) Si une extension de containte de stratégie est inclue dans le certificat, modifie les variables d'état explicit_policy et policy_mapping comme suit:

        (1) Si requireExplicitPolicy est présent et est inférieur à explicit_policy, définis explicit_policy à la valeur de requireExplicitPolicy
        (2) Si inhibitPolicyMapping est présent et est inférieur à policy_mapping, définis policy_mapping à la valeur de inhibitPolicyMapping

(j) Si l'extension inhibitAnyPolicy est inclus dans le certificat et est inférieur à inhibit_anyPolicy, définis inhibit_anyPolicy à la valeur de inhibitAnyPolicy
(k) Si le certificat i est un certificat v3, vérifie que l'extension basicConstraints est présent et que cA est mis à TRUE. ( Si le certificat i est un v1 ou v2, l'application doit vérifier que le certificat i est un certification CA via un moyen externe ou rejeter le certificat. Les implémentations conformes peuvent choisir de rejeter tous les certificat intermédiaire v1 et v2)
(l) Si le certificat n'est pas auto-fournis, vérifie que max_path_length est supérieur à 0 et le décrémente de 1
(m) Si pathLenConstraint est présent dans le certifiat et est inférieur à max_path_length, définis max_path_length à la valeur de pathLenConstraint
(n) Si une extension d'utilisation de clé est présente, vérifie que le bit keyCertSign est mis.
(o) Reconnaît et traite toute autre extension critique présent dans le certificat. Traite tout autre extension non critique présente dans le certificat qui a sont importance dans le traitement du chemin.

   Si les vérification (a), (k), (l), (n), ou (o) échouent, la procédure se termine, retournant une indication d'erreur et une raison appropriée.

  si (a), (k), (l), (n), et (o) sont complétées avec succès, incrémente i et effectue le traitement de certificat de base spécifié dans la section précédente.

Procédure Wrap-Up

   Pour compléter le traitement du certificat cible, effectue les étapes suivantes pour le certificat n:

(a) Si explicit_policy n'est pas 0, décrément explicit_policy de 1
(b) Si une extension de contrainte de stratégie est inclue dans le certificat et requireExplicitPolicy est présent et a une valeur de 0, définis la variable d'état explicit_policy à 0.
(c) Assigne le certificat subjectPublicKey à working_public_key
(d) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec un paramètre non-null, assigne les paramètres à la variable working_public_key_parameters.
Si le champ subjectPublicKeyInfo du certificat contient un champ algorithm avec des paramètre null ou des paramètre omis, compare l'algorithme subjectPublicKey avec working_public_key_algorithm. S'ils sont différents, définis working_public_key_algorithm à nul.
(e) Assigne l'algorithme subjectPublicKey à la variable working_public_key_algorithm.
(f) Reconnaît et traite toute autre extension critique présente dans le certificat n. Traite tout autre extension non critique présente qui a sont importance dans le traitement du chemin.
(g) Calcule l'intersection de valid_policy_tree et user-initial-policy-set, comme suit:

        (i) si valid_policy_tree est null, l'intersection est null.
        (ii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, l'intersection est tout le valid_policy_tree
        (iii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, calcule l'intersection de valid_policy_tree et de user-initial-policy-set comme suit:

                1. Détermine le jeu de nœuds de stratégies dont les nœuds parent ont un valid_policy à anyPolicy. C'est le valid_policy_node_set.
                2. Si valid_policy d'un nœud dans valid_policy_node_set n'est pas dans le user-initial-policy-set et n'est pas anyPolicy, supprime ce nœud et tous ses enfants.
                3. Si valid_policy_tree inclus un nœuds de profondeur n avec valid_policy anyPolicy et user-initial-policy-set n'est pas any-policy, effectue les étapes suivantes:

                        a. Définis P-Q au qualifier_set dans le nœud de profondeur n avec valid_policy anyPolicy
                        b. Pour chaque P-OID dans user-initial-policy-set qui n'est pas le valid_policy d'un nœud dans valid_policy_node_set, crée un nœud enfant dont le parent est le nœud de profondeur n-1 avec valid_policy anyPolicy. Définis les valeurs dans le nœud enfant comme suit: définis valid_policy à P-OID, définis le qualifier_set à P-Q, et définis le jeu expected_policy à {P-OID}.
                        c. Supprime le nœud de profondeur n avec le valid_policy anyPolicy.

                4. S'il y a un nœud dans valid_policy_tree de profondeur n-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ai plus de nœud de profondeur n-1 ou moins sans enfant.

   Si (1) la valeur de explicit_policy est supérieur à 0 ou (2) valid_policy_tree n'est pas null, le traitement du chemin a réussit.

Sorties

   Si le traitement du chemin réussit, la procédure se termine, retournant une indication de succès avec la valeur finale de valid_policy_tree, working_public_key, working_public_key_algorithm, et working_public_key_parameters.

Utiliser l'algorithme de validation de chemin

   L'algorithme de validation de chemin décris le processus de validation d'un simple chemin de certification. Bien que chaque chemin de certification commence avec une ancre de confiance, il n'y a pas de pré-requis pour tous les chemins de certification validés par un système particulier qui partage une seul ancre de confiance. La sélection d'une ou plusieurs CA de confiance comme ancre de confiance est une décision locale. Un système peut fournir une de ses CA de confiance comme ancre de confiance pour un chemin particulier. L'entrée dans l'algorithme de validation de chemin peut être différent pour chaque chemin. Les entrées utilisées pour traiter un chemin peuvent refléter des pré-requis spécifique à une application ou les limitations dans la confiance accordée à une ancre de confiance particulière. Par exemple, une CA de confiance peut seulement être approuvée pour une stratégie de certificat particulier. Cette restriction peut être exprimée via les entrées de la procédure de validation de chemin.

   Une implémentation peut augmenter l'algorithme présenté plus haut pour limiter le jeu de chemins de certification valide qui commencent avec une ancre de confiance particulière. Par exemple, une implémentation peut modifier l'algorithme pour appliquer une contrainte le longueur de chemin pour une ancre de confiance spécifique durant la phase d'initialisation, ou l'application peut nécessite la présence d'une forme de nom alternative particulière dans le certificat cible, ou l'application peut imposer des pré-requis dans les extensions spécifiques à l'application. L'algorithme de validation de chemin présenté dans ce document définis les conditions minimum pour qu'un chemin soit considéré valide.

   Quand une CA distribut des certificat auto-signés pour spécifier des informations d'ancre de confiance, les extensions de certificat peuvent être utilisé pour spécifier les entrées recommandées à la validation de chemin. Par exemple, une extension de contrainte de stratégie pourrait être inclus dans le certificat auto-signé pour indiquer que le chemin commençant avec cet ancre de confiance devrait être validé seulement pour les stratégies spécifiées. Similairement, une extension de contrainte de nom pourrait être inclus pour indiquer que les chemins commençant avec cet ancre de confiance devraient être validés seulement pour les espaces de nom spécifiés. L'algorithme de validation de chemin présenté dans ce document n'assume pas que les informations de l'ancre de confiance est fournie dans des certificats auto-signés et ne spécifie pas les règles de traitement pour les informations additionnelles inclus dans de tels certificats.

   Cependant, la rfc 5914 définis de nombreux formats pour représenter des informations d'ancre de confiance, incluant des certificats auto-signés, et la rfc 5937 fournis un exemple sur comment de telles informations peuvent être utilisées pour initialiser les entrées de validation de chemin. Les implémentations sont libre d'utiliser les informations additionnelles qui sont inclus dans la représentation de l'ancre de confiance, ou des les ignorer.

Validation de CRL

   Cette section décris les étapes nécessaires pour déterminer is un certificat est révoqué quand les CRL sont le mécanisme de révocation utilisé par le fournisseur de certificat. Les implémentations conformes qui supportent les CRL ne sont pas obligés d'implémenter cet algorithme, mais elles doivent être fonctionnellement équivalente à cette procédure. Tout algorithme peut être utilisé par une implémentation tant qu'elle dérive un résultat correcte.

   Cet algorithme assume que toutes les CRL nécessaire sont disponible dans un cache local. De plus, si le temps nextUpdate d'une CRL a passé, l'algorithme assume un mécanisme pour chercher une CRL courante et la placer dans le cache de CRL local.

   Cet algorithme définis un jeu d'entrées, un jeu de variables d'états, et des étapes de traitement qui sont effectués pour chaque certificat dans le chemin. La sortie de l'algorithme est le statut de révocation du certificat.

Entrées de révocation

   Pour supporter le traitement de la révocation, l'algorithme nécessite 2 entrées:

(a) certificate: l'algorithme nécessite le numéro de série du certificat et le nom du fournisseur pour déterminer si un certificat est dans une CRL particulière. L'extension basicConstraints est utilisé pour déterminer si le certificat fournis est associé avec un CA ou une entité finale. Si présent, l'algorithme utilise les extensions cRLDistributionPoints et freshestCRL pour déterminer de statut de révocation.
(b) use-delta: ce booléen détermine si des CRL delta sont appliquées aux CRL.

Variables d'état d'initialisation et de révocation

   Pour supporter le traitement des CRL, l'algorithme nécessite les variable d'état suivants:

(a) reasons_mask: Cette variable contient le jeu de raisons de révocation supportés par les CRL et les CRL délta. Les membres légaux de ce jeu sont les valeurs de raison possible moins ceux non-spécifiés: La valeur spéciale all-reasons est utilisée pour dénoter le jeu de tous les membres légaux. Cette variable est initialisée à un jeu vide.
(b) cert_status: cette variable contient le statut du certificat. Cette variable peut être assignée à une des valeurs suivantes: unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, la valeur spéciale UNREVOKED, ou la valeur spéciale UNDETERMINED. Cette variable est initialisée à UNREVOKED.
(c) interim_reasons_mask: contient le jeu de raisons de révocation supportés par le CRL ou la CRL delta actuellement traitée.

   Note: Dans certains environnements, il n'est pas nécessaire de vérifier tous les codes de raison. Par exemple, certains environnement sont seulement concernés par cACompromise et keyCompromise pour les certificats CA. Cet algorithme vérifie tous les codes de raison. Un traitement et des variables d'état additionnel peuvent être nécessaires pour limiter la vérification d'un sous-jeu de codes de raison.

Traitement de CRL

   Cet algorithme commence par supposer que le certificat n'est pas révoqué. L'algorithme vérifie une ou plusieurs CRL jusqu'à ce que soit le statut du certificat est déterminé être révoqué soit que suffisamment de CRL ont été vérifiée pour couvrir tous les codes de raison.

   Pour chaque point de distribution dans l'extension de points de distribution de CRL du certificat, pour chaque CRL correspondant dans le cache de CRL local, tant que ((reasons_mask n'est pas all-reasons) et (cert_status est UNREVOKED)), effectue les étapes suivantes:

(a) Met à jour le cache de CRL local en obtenant une CRL complète, une CRL delta, ou les 2:

        (1) Si la date courante est après la valeur du champ nextUpdate de la CRL, effectue une des étapes suivantes:

                (i) Si use-deltas et mis et que soit le certificat ou la CRL contient l'extension freshest CRL, obtient une CRL delta avec la valeur nextUpdate qui est après la date courante et peut être utilisée pour mettre à jours la CRL en cache local.
                (ii) Met à jour le cache de CRL local avec une CR complète courante, vérifie que la date courante est avant le champ nextUpdate dans la nouvelle CRL. Si use-deltas est mis et soit le certificat soit la CRL contient l'extension freshest CRL, obtient la CRL delta courante qui peut être utilisée pour mettre à jours la nouvelle CRL complète en cache.

        (2) Si la date courante est avant la valeur du champ nextUpdate, use-deltas est mis, et soit le certificat ou la CRL contient l'extension freshest CRL, puis obtient la CRL delta courante qui peut être utilisée pour mettre à jour la CRL complète en cache.

(b) Vérifie le fournisseur et le scope de la CRL complète comme suit:

        (1) Si le point de distribution (DP) inclus cRLIssuer, alors vérifie que le champ issuer dans la CRL complète correspond au cRLIssuer dans le DP et que la CRL complète contient une extension de point de distribution de fournisseur avec le booléen indirectCRL inséré. Sinon, vérifie que le fournisseur de CRL correspond au fournisseur de certificat.
        (2) Si la CRL complète inclus une extension de point de distribution de fournisseur (IDP), vérifie les étapes suivante:

                (i) Si le nom du point de distribution est présent dans l'extension de CRL IDP et que le champ de distribution est présent dans le DP, alors vérifie qu'un des noms dans le IDP correspond à un des noms dans le DP. Si le point de distribution est présent dans l'extension de CRL IDP et que le champ distribution est omis du DP, vérifie qu'un des noms dans le IDP correspond à un des noms dans le champ cRLIssuer du DP.
                (ii) Si le booléen onlyContainsUserCerts est mis dans l'extension de CRL IDP, vérifie que le certificat n'inclus pas l'extension de contrainte de base avec le booléen cA mis.
                (iii) Si le booléen onlyContainsCACerts est mis dans l'extension de CRL IDP, vérifie que le certificat inclus l'extension de contraintes de base avec le booléen cA mis.
                (iv) Vérifie que le booléen onlyContainsAttributeCerts n'est pas mis.

(c) Si use-deltas est mis, vérifie le fournisseur et le scope de la CRL delta comme suit:

        (1) Vérifie que le fournisseur de CRL delta correspond au fournisseur de CRL complète.
        (2) Si la CRL complète inclus une extension de CRL IDP, vérifie que la CRL delta contient une extension de CRL IDP correspondant à l'extension de CRL IDP. Si la CRL complète omet une extension de CRL IDP, vérifie que la CRL delta omet également une extension de CRL IDP.
        (3) Vérifie que l'extension d'identifiant de clé d'autorité de CRL delta correspond à l'extension d'identifiant de clé d'autorité de la CRL complète.

(d) Calcule interim_reasons_mask pour cette CRL comme suit:

        (1) Si l'extension de CRL IDP est présent et inclu onlySomeReasons et que DP inclus des raisons, définis interim_reasons_mask à l'intersection des raisons dans le DP et onlySomeReasons dans l'extension de CRL IDP.
        (2) Si l'extension de CRL IDP inclus onlySomeReasons mais que DP omet les raisons, alors définis interim_reasons_mask à la valeur de onlySomeReasons dans l'extension de CRL IDP.
        (3) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons mais que DP inclus des raisons, définis interim_reasons_mask à la valeur de reasons DP.
        (4) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons et que DP omet les raisons, définis onlySomeReasons à la valeur spéciale all-reasons.

(e) Vérifie que interim_reasons_mask inclus une ou plusieurs raisons qui ne sont pas inclus dans le reasons_mask.
(f) Obtient et valide le chemin de certification pour le fournisseur de CRL complète. L'ancre de confiance pour le chemin de certification doit être la même que l'ancre de confiance utilisée pour valider le certificat cible. Si une extension d'utilisation de clé est présente dans le certificat du fournisseur de CRL, vérifie que le bit cRLSign est mis.
(g) Valide la signature dans le CRL complète en utilisant la clé publique validée dans l'étape (f).
(h) Si use-delta est mis, valide la signature dans la CRL delta en utilisant la clé publique validée dans l'étape (f)
(i) Si use-deltas et mis, alors recherche le certificat dans la CRL delta. Si une entrée est trouvée qui correspond au fournisseur de certificat et numéro de série, met la variable cert_status à la raison indiquée comme suit:

        (1) Si l'extension d'entrée de CRL de code de raison est présent, définis la variable cert_status à la valeur de l'extension d'entrée de CRL de code de raison.
        (2) Si l'extension d'entrée de CRL de code de raison n'est pas présent, définis va variable cert_status à la valeur unspecified.

(j) Si (cert_status est UNREVOKED), alors cherche le certificat dans la CRL complète. Si une entrée est trouvée qui correspond au fournisseur et numéro de série du certificat, définis la variable cert_status à la raison indiquée comme décris dans l'étape (i).
(k) Si (cert_status est removeFromCRL), définis cert_status à UNREVOKED.
(l) Définis la variable d'état reasons_mask à l'union de ses précédentes valeurs et de la valeur de la variable d'état interim_reasons_mask.

   Si ((reason_mask est all-reasons) OU (cert_status n'est pas UNREVOKED)), le status de révocation a été determiné, donc retourne cert_status.

   Si le status de révocation n'a pas été déterminé, répète le processus avec toutes les CRL disponible non spécifiées dans un point de distribution, mais fournis par le fournisseur e certificat. Pour le traitement de telles CRL, assume un DP avec champs reasons et cRLIssuer omis et un nom de point de distribution du fournisseur de certifiat. C'est à dire la séquence de noms dans fullName est générée depuis le champ issuer du certificat aussi bien que l'extension issuerAltName du certificat. Après traitement de telles CRL, si le status de révocation n'a pas été déterminé, retourne cert_status à UNDETERMINED.

Traitement des règles pour les noms internationalisés

   Les noms internationalisés peuvent être rencontrés dans de nombreux champs et extensions de certificat et de CRL, incluant des noms distinct, noms de domaine internationalisés, adresses de messagerie électronique, et IRI. Le stockage, comparaison, et présentation de tels noms nécessite un attention particulière. Certains caractères peuvent être encodés de plusieurs manières. Les même nom peuvent être représentés dans plusieurs encodage. Cette section établis les pré-requis de conformité pour le stockage ou la comparaison de chacune de ces formes de nom.

Noms internationalisés dans les noms distinct

   Les attribut de nommage standard tels les noms communs, employent le type DirectoryString, qui supporte les noms internationalisés via une variété d'encodage de langues. Les implémentation conformes doivent supporter UTF8String et PrintableString. La rfc3280 requière seulement une comparaison binaire des valeurs d'attributs encodés en UTF8String, cependant, cette spécification requière une manipulation plus compréhensible. Les implémentations peuvent rencontrer des certificats et des CRL avec des noms encodés en utilisant TeletexString, BMPString, ou UniversalString, mais leur support est optionnel.

   Les implémentations conformes doivent utiliser le profile LDAP StringPrep (rfc4518) comme base pour la comparaison des attributs de noms distinct encodés avec PrintableString ou UTF8String. Les implémentations conforme doivent supporter la comparaison de noms en utilisant caseIgnoreMatch. Le support pour les types d'attributs qui utilisent d'autres règles de correspondance d'égalité est optionnel.

   Avant de comparer les noms en utilisant la règle de correspondance caseIgnoreMatch, les implémentation doivent effectuer l'algorithme de conformité en 6 étapes décrit dans la rfc4518 pour chaque attribut de type DirectoryString, avec les clarifications suivantes:

- Dans l'étape 2, le mapparge devrait inclure de cas spécifié dans la rfc3454 Appendix B.2.
- Dans l'étape 6, La suppression des caractères insignifiant, effectue la compression des espaces blanc comme spécifié dans la section Insignificant Space Handling de la rfc 4518.

   En effectuant l'algorithme de préparation de chaîne, les attributs doivent être traités comme valeurs stockées.

   2 attributs de nommage correspondent si les types d'attributs sont les même et les valeurs des attributs sont un exact match après traitement avec l'algorithme de préparation de chaîne. 2 noms distincts relatifs RDN1 et RDN2 correspondent s'ils ont le même nombre d'attributs de nommage pour chaque attribut de nommage dans RDN1, il y a un attribut de nommage correspondant dans RDN2, et les RDN apparaissent dans le même ordre. Un DN1 est dans le subtree définis dans DN2 si DN1 contient au moins autant de RDN que DN2, et DN1 et DN2 correspondent quand les DNS restants dans DN1 sont ignorés.

Noms de domaine internationalisés dans GeneralName

   Les noms de domaine internationalisés (IDN) peuvent être inclus dans les certificats et les CRL dans les extensions subjectAltName et issuerAltName, les extensions de contraintes de nom, extensions d'accès aux informations d'autorité, extensions d'accès aux informations du sujet, extensions de point de distribution de CRL, et les extensions de point de distribution de fournisseur. Chacune de ces extensions utilise le type GeneralName; Un choix dans GeneralName est le champ dNSName, qui est définis comme type IA5String.

   IA5String est limité au jeu de caractères ASCII. Pour adapter les noms de domaine internationalisés dans la structure courante, les implémentations conformes doivent convertir les noms de domaine internationalisés au format ASCII Compatible Encoding (ACE) comme spécifié dans la rfc 3490 avant de stocker le champ dNSName. Spécifiquement, les implémentations conformes doivent effectuer les opérations de conversion spécifiés dans la rfc 3490, avec les clarifications suivantes:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToASCII"
- Dans l'étape 5, change tous les séparateurs de label à U+002E.

   En comparant les noms DNS pour l'égalité, les implémentations conforme doivent effectuer une correspondance sensible à la casse exacte sur tout le nom DNS. En évaluant les contraintes de nom, les implémentations conformes doivent effectuer une correspondance sensible à la casse exacte sur une base label par label. Comme spécifié dans la section "name constraints", tous nom DNS que peut être construit en ajoutant des labels à gauche du nom de domaine donné comme contrainte est considéré être dans le subtree indiqué.

   Les implémentations devraient convertir les IDN en Unicode avant affichage. Spécifiquement, les application conformes devraient effectuer l'opération de conversion spécifiée dans la rfc3490, avec les clarifications suivante:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToUnicode"
- Saute l'étape 5.

   Note: les implémentations doivent autoriser l'augmentation de l'espace requis pour les IDN. Un label IDN ACE va commencer avec les 4 caractères additionnels "xn--" et peut nécessiter jusqu'à 5 caractères ASCII pour spécifier un simple caractère internationalisé.

Noms de domaine internationalisés dans les noms distincts

   Les noms de domaine peuvent également être représentés en noms distinct, en utilisant des composantes domaine dans le champ subject, issuer, l'extension subjectAltName, ou issuerAltName. Comme avec dNSName dans le type GeneralName, la valeur de cet attribut est définis comme IA5String. Chaque attribut domainComponent représente un simple lable. Pour représenter un label depuis un IDN en nom distinct, l'implémentation doit effectuer la conversion de label "ToASCII" spécifié dans la rfc3490. Le label devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.

   Les implémentations conformes devraient convertir les labels ACE en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer l'opération de conversion "ToUnicode" spécifiée dans la rfc3490, sur chaque label ACE avant affichage.

Identifiants de ressources internationalisés

   Les IRI sont le complément internationalisé des URI. Les IRI sont des séquences de caractères Unicode, alors que les URI sont des séquences de caractères ASCII. La rfc3987 définis un mappage des IRI en URI. Bien que les IRI ne sont pas encodés directement dans les champs et extensions de certificat et CRL, leur version mappé URI peuvent êrte inclus dans les certificats et CRL. Les URI peuvent apparaître dans les extensions subjecAltName, issuerAltName, contraintes de noms, accès aux informations de l'autorité, accès aux informations du sujet, point de distribution de fournisseur et de CRL. Chacune de ces extensions utilisent le type GeneralName, les URI sont encodés dans le champ uniformResourceIdentifier dans GeneralName, qui est défini en type IA5String.

   Pour représenter les IRI dans la structure courante, les implémentations courantes doivent mapper les IRI en URI comme spécifiés dans la rfc 3987, avec les clarifiations suivantes:

- Dans l'étape 1, génère une séquence de caractère UCS du format IRI original normalisant en accord au NFC comme spécifié dans la variante b
- Effectue l'étape 2 en utilisant la sortie de l'étape 1.

   Les implémentations ne doivent pas convertir le composant ireg-name avant d'effectuer l'étape 2.

   Avant que les URI puissent être comparés, les implémentations conformes doivent effectuer une combinaison des techniques de normalisation basé sur la syntaxe et sur le schéma décris dans la rfc3987. Spécifiquement, les implémentations conformes doivent préparer les URI pour les comparaisons comme suit:

Étape 1 Quand les IRI permettent l'utilisation d'IDN, ces noms doivent être convertis en ACE comme spécifié plus haut
Étape 2 Le schéma et l'hôte sont normalisés en minuscule comme spécifié dans la rfc3987
Étape 3 Effectue une normalisation percent-encoding, comme spécifié dans la rfc3987
Étape 4 Effectue une normalisation de segment de chemin, comme spécifié dans la rfc3987
Étape 5 Si reconnus, L'implémentation doit effectuer une normalisation basée sur le schéma, comme spécifié dans la rfc3987

   Les implémentations conformes doivent reconnaître et effectuer une normalisation basée sur les schéma pour les schéma suivant: ldap, http, https, et ftp. Si le schéma n'est pas reconnu, l'étape 5 est omise.

   En comparant les URI pour l'équivalence, les implémentations conformes devraient effectuer une correspondance d'égalité sensible à la casse.. Les implémentations devraient convertir les URI en Unicode avant affichaqe.

Adresses de messagerie électronique internationalisées

   Les adresses de messagerie électronique peuvent être inclus dans les certificats et les CRL dans les extension subjecAltName et issuerAltName, contraintes de noms, accès aux information d'autorité et du sujet, et point de distribution du fournisseur et de CRL. chacune de ces extensions utilise la construction GeneralName; GeneralName inclus rfc822Name, qui est définis comme type IA5String. Pour spécifier des adresses email avec des noms de domaine internationalisés en utilisant la structure courante, les implémentations conforme doivent convertir les adresses en représentation ASCII.

   Quand la partie hôte (le domaine de la boîte mail) contient un nom internationalisé, le nom de domaine doit être convertis depuis un IDN en ACE. 2 adresses email correspondent si:

1) La partie locale du chaque nom est un exact match, et
2) la partie hôte de chaque nom correspond en utilisant une comparaison ASCII insensible à la casse.

   Les implémentations devraient convertir la partie hôte des adresses email internationalisés spécifiés dans ces extension en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer la conversion de la partie hôte de la boîte mail comme décris dans la section des IDN dans GeneralName.

Considérations de sécurité

   Vu que les certificats et les CRL sont signés numériquement, aucun service d'intégrité additionnel n'est nécessaire, ni de conserver les certificats ou les CRL secrets, et les accès non-restreins et anonymes aux certificats et CRL n'a pas d'implication de sécurité.

   Cependant, des facteurs de sécurité en dehors du scope de cette spécification affectent l'assurance fournie par les certificats utilisateurs. Cette section met en avant les problèmes de sécurité hautement critique à considérer par les implémenteurs, administrateurs et les utilisateurs.

   L'utilisation d'une simple paire de clé pour la signature et d'autres buts est fortement découragée. L'utilisation de paires de clé séparés pour la signature et la gestion de clé fournis de nombreux bénéfices aux utilisateurs. Les ramifications associées avec la pertes ou la divulgation d'une clé de signature sont différents de la perte ou la divulgation d'une clé de gestion de clé. Utiliser des paires de clé différente permet une réponse balancée et différente. Similairement, différentes périodes de validité ou longueur de clé pour chaque paire de clé peuvent être approprié dans certains environnements. Malheureusement, certaines applications utilisent une simple paire de clé pour la signature et la gestion de clé.

   La protection des clés privées conférée aux clés privées est un facteur critique. À petite échelle, les utilisateurs qui ne protègent pas leurs clés privée va permettre à un attaquant de les usurper ou déchiffrer leurs informations personnelles. À plus grande échelle, la clé privée de signature d'une CA compromise peut avoir un effet catastrophique. Si un attaquant obtient une clé privée, il peut émettre de faux certificats et CRL. L'existance de faux certificats et CRL va détruire la confidence dans le système. Si un tel compromis est détecté, tous les certificats émis par la CA compromise doivent être révoqués, bloquant les services entre ses utilisateurs et les utilisateurs d'autres CA. Reconstruire après un tel compromis sera problématique, donc les CA doivent implémenter une combinaison de mécanismes fort et de procédures de gestion appropriés (ex: séparation des privilèges) pour éviter un incident.

   La perte d'une clé de signature privée de CA peut également être problématique. La CA ne sera pas capable de produire de CRL ou d'effectuer des remplacements de clé. Les CA devraient maintenir une sauvegarde sûre pour les clés de signature. La sécurité des procédures de sauvegarde de clé est un facteur critique pour éviter la compromission de clé.

   La disponibilité des informations de révocation affecte le degré d'assurance qui est placé dans un certificat. Bien que les certificats expirent naturellement, des évènements peuvent se produire durant sa durée de vie qui supprime la liaison entre le sujet et sa clé publique. Si l'information de révocation n'est pas disponible, l'assurance avec la liaison est clairement réduite. Les parties de confiance peuvent ne pas être capable de traiter toutes les extensions critiques qui peuvent apparaître dans une CRL. Les CA devraient faire très attention créant des informations de révocation uniquement disponibles via des extensions critiques, particulièrement si le support pour ces extensions n'est pas mandaté par ce profile.

   Par exemple, si les informations de révocation sont fournis en utilisant une combinaison de CRL delta et le CRL complètes, et que la CRL delta est fournie plus fréquemment que les CRL complètes, les parties de confiance qui ne peuvent pas manipuler les extensions critiques liées au traitement de la CRL delta ne seront pas capable d'obtenir les informations de révocations les plus récentes. Alternativement, il une CRL complète est fournis au même moment qu'une CRL delta, Les informations de révocation seront disponibles à toutes les parties. Similairement, les implémentations du mécanisme de validation de chemin de certification qui omettent la vérification de révocation fournissent moint d'assurance qui celles qui le supporte.

   L'algorithme de validation de chemin de certification dépend de la connaissance des clé publiques ( et autres informations ) sur une ou plusieurs CA de confiance. La décision de la confiance en un CA est une décision importante vu qu'elle détermine la confiance accordée à un certificat. La distribution authentifiée de clés publique de CA (généralement sous la forme de certificat auto-signé) est un processus à part critique qui est en dehors de cette spécification.

   En plus, quand une clé est compromise ou qu'une CA en peut plus être de confiance, l'utilisateur doit modifier les informations fournies à la routine de validation de chemin. Sélectionner trop de CA de confiance rend cette maintenance difficile.

   La qualité des implémentations qui traitent les certificats affectent également le degré d'assurance fournis. L'algorithme de validation de chemin s'assure de l'intégrité des informations de CA de confiance, et spécialement l'intégrité des clés publiques associées avec ces CA. En substituant les clés publiques pour lequel un attaquant a la clé privée lui permet de faire accepter de faux certificats à un utilisateur.

   La liaison entre une clé et le sujet du certificat ne peut pas être plus fort que l'implémentation du module cryptographique et des algorithmes utilisés pour générer la signature. Des longueurs de clé courtes ou des algorithmes de hashage faible limitent l'utilité des certificats. Les CA sont encouragés à noter les progrès en cryptologie afin d'employer des techniques cryptographiques fortes. De plus, les CA devraient refuser de fournir des certificats à de CA ou des entités finales qui génèrent des signatures faibles.

   Une application inconsistante de règle de comparaison de nom peut résulter dans l'acceptation de chemins de certification invalides ou le rejet de chemins valides. Les séries de spécification X.500 définissent des règles pour comparer les noms distincts qui nécessitent la comparaison de chaînes sans regarder là casse, le jeu de caractère, espaces blancs multi-caractères, ou espaces blancs en début ou fin. Cette spécification relaxe ces requis, nécessitant le support d'une comparaison binaire au minimum.

   Les CA doivent encoder les noms distinct dans le champ sujet d'un certificat CA identiquement au nom distinct dans le champ issuer dans les certificats fournies par cette CA. Si les CA utilisent des encodages différents, les implémentations peuvent échouer à reconnaître les chaînes de nom pour les chemins qui incluent ce certificat. En conséquence, les chemins valides pourraient être rejetés.

   En plus, les contraintes de nom pour les noms distincts doivent être identiques à l'encodage utilisé dans le champ subjet ou l'extension subjectAltName. Sinon, les contraintes de noms définis comme excludedSubtrees ne matcheront pas et les chemins invalides seront acceptés et les contraintes de noms exprimés comme permittedSubtrees ne vont pas matcher et les chemins valides seront rejeter. Pour éviter d'accepter les chemins invalides, les CA devraient définir les contraintes de noms pour les noms distincts comme permittedSubtrees si possibles.

   En général, utiliser l'extension nameConstraints pour contraindre une forme de nom n'offre pas de protection contre l'utilisation d'autre formes de nom.

   Bien que X.509 mandate que les noms soient non ambigus, il y a un risque que 2 autorités non liées fournissent des certificats et/ou des CRL sous le même nom de fournisseur. Un moyen de réduire ces problèmes et les problèmes de sécurité liés aux collisions de nom de fournisseur, les noms de CA et de fournisseurs de CRL devraient être formé d'une manière qui réduit la probabilité des collisions de noms. Les implémenteurs devraient prendre en compte l'existence possible de multiples CA et fournisseurs de CRL avec le même nom. Au minimum, les implémentations validant les CRL doivent s'assurer que le chemin de certification d'un certificat et du chemin de certification du fournisseur de CRL utilisés pour valider ce certificat se terminent à l'ancre de confiance.

   Bien que la partie locale d'une adresse de messagerie électronique est sensible à la casse, les valeurs de l'attribut emailAddress sont insensibles à la casse. Il y un risque que 2 adresses emails différentes soient traitées comme des adresse identiques. Les implémenteurs ne devraient pas inclure une adresses email dans l'attribut emailAddress si le serveur de messagerie traite la partie locale des adresses email comme sensible à la casse.

   Les implémenteurs devraient s'assurer des risques liés si les points de distribution de CRL ou les extensions d'accès aux informations d'autorité de certificats ou de CRL corrompus contiennent les liens vers du code malicieux. Les implémenteurs devraient toujours prendre les étapes consistant à valider les données extraites afin de s'assurer que les données sont correctement formées.

   Quand les certificats incluent une extension cRLDistributionPoints avec une URI https ou un schéma similaire, des dépendances circulaires peuvent être introduits. Le tier de confiance est forcé d'effectuer une validation de chemin additionnel pour obtenir la CRL requise pour compléter la validation de chemin initiale. Des conditions similaires peuvent égalemente être créés avec une URI https dans les extensions authorityInfoAccess ou subjectInfoAccess.

   Les CA ne devraient pas inclure d'URI qui spécifient https, ldaps, ou des schémas similaires dans les extensions. Les CA qui incluent une de ces extension doivent s'assurer que le certificat du serveur peut être validé dans utiliser d'informations pointé par l'URI. Les tiers de confiance qui choisissent de valider le certificat du serveur en obtenant les informations pointés par une URI https dans les extensions cRLDistributionPoints, authorityInfoAccess, ou subjectInfoAccess doivent être préparés pour cette possibilité.

   Les certificats auto-fournis fournissent des CA avec un mécanisme automatisé pour indiques les changements dans les opération de la CA. En particulier, les certificat auto-signés peuvent être utilisés pour implémenter un changement de paire de clé non-compromis à un autre. Les procédures détaillée pour la mise à jours de clé de CA sont spécifiés dans la rfc4210, où la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice versa en utilisa 2 certificats auto-fournis. Les implémentations client conformes vont traiter le certificat auto-signé et déterminer si les certificats fournis sous la nouvelle clé peut être trusté. Les certificats auto-fournis peuvent être utilisé pour supporter d'autres changements dans les opérations de CA, tel que l'ajout de stratégies, en utilisant des procédures similaires.

   Certaines anciennes implémentations supportent les noms encodés en ISO 8859-1 (Latin1String) mais les tag en TeletexString. TeletexString encode un jeu de caractère plus grand que ISO 8859-1, mais il encode certains caractères différemment. Les règles de comparaison spécifiée plus haut assument que les TeletexStrings sont encodés comme décris dans le standard ASN.1. En comparant les noms encodés en Latin1String, de faux positifs et négatifs sont possibles.

   Quand des chaînes sont mappées depuis des représentations interne vers de représentation visuelle, 2 chaînes différentes peuvent parfois avoir la même représentation visuelle. Cela peut se produire pour plusieurs raisons, incluant l'utilisation de glyphes similaires et l'utilisation de caractères composés. Les fournisseurs de certificats et les tiers de confiance doivent gérer cette situation.
^
27 novembre 2014

htmlpdflatexmanmd




rfc5652

rfc5652

Syntaxe de message cryptographique

Définitions

   Ce document décris la syntaxe de message cryptographique (CMS). Cette syntaxe est utilisée pour signer, hasher, authentifier ou chiffrer numériquement du contenu de message arbitraire.

   Le CMS décris une syntaxe d'encapsulation pour la protection des données. Il supporte les signatures et chiffrement numérique. La syntaxe permet plusieurs encapsulations; un enveloppe d'encapsulation peut être imbriquée dans une autre. Également, une partie peut signer une donnée précédemment encapsulée. Il peut également des attributs arbitraires, telle que la date de signature.

   Le CMS peut supporter divers architectures pour la gestion de clé basé sur les certificats, tes que celui définis par le groupe de travail PKIX.

   Les valeurs CMS sont générées en utilisant ASN.1, utilisant l'encodage BER. Les valeurs sont typiquement représentées comme chaîne d'octets. Bien que de nombreux systèmes sont capable de transmettre des chaînes d'octet arbitraires de manière sûre, il est bien connu que les systèmes de messagerie électronique ne le sont pas. Ce document n'adresse pas les mécanismes pour encoder les chaînes d'octets pour une transmission sûre dans de tels environnements.

Évolution de CMS

   Le CMS est dérivé de PKCS#7 version 1.5, qui est documenté dans la rfc 2315. PKCS#7 a été publié à l'origine comme note technique des laboratoires RSA en novembre 1993. IETF a depuis repris la responsabilité pour le développement et la maintenance du CMS. Aujourd'hui, de nombreux protocoles IETF utilisent CMS. Cette section décris les changement que l'IETF a fait de CMS dans chaque version publiée.

Changements depuis PKCS#7 version 1.5

   la rfc 2630 [CMS1] était la première version de CMS. Quand cela est possible, la compatibilité avec PKCS#7 a été préservée; cependant, des changements fait pour accueillir le transfert de l'attribut certificat version 1 et pour supporter la gestion de clé indépendamment de l'algorithme. PKCS#7 version 1.5 incluait le support seulement pour le transport des clé. la rfc 2630 ajoute le support pour l'accord de clé et les techniques de chiffrement de clé symétrique distribués précédemment.

Changements depuis la rfc 2630

   La rfc 3369 [CMS2] remplace la rfc 2630 et la rfc 3211. La gestion de clé basé sur des mots de passe est inclue dans la spécification CMS et un mécanisme d'extension pour supporter de nouveau schémas de gestion de clé dans avoir à changer le CMS est spécifié. La compatibilité avec la rfc 2630 et la rfc3211 est préservée. Cependant, le transfert d'attribut de certificat version 2 est ajouté, et l'utilisation des attributs de certificat version 1 est déprécié.

   Les signatures S/MIME v2, qui sont basées sur PKCS#7 v1.5, sont compatibles avec les signature S/MIME v3 et v3.1. Cependant, il y a quelques problème subtiles de compatibilité avec les signatures basées sur PKCS#7 v1.5.

   Les algorithmes de chiffrement spécifiques ne sont pas discutés dans ce document, mais ont été discutés dans la rfc 2630. La discussion des algorithmes de chiffrement on été placés dans les document séparés.

Changements depuis la rfc 3369

   La rfc 3852 [CMS3] remplace la rfc 3369. Comme discuté dans la précédente section, la rfc 3369 a introduit un mécanisme d'extension pour supporter de nouveaux schémas de gestion de clé. La rfc 3852 introduit un mécanisme d'extension similaire pour supporter des formats de certificats additionnels et les formats d'information de status de révocation.

Changement depuis la rfc 3852

   Ce document remplace la rfc 3852. La raison principale pour la publication de ce document est de faire progresser le CMS avec la maturité des standards. Ce document inclus la clarification qui était originellement publiée dans la rfc 4853 concernant la manipulation correcte du type de contenu SignedData quand plus d'une signature numérique est présente.

Numéros de version

   Chacune des structures de donnée majeur inclus un numéro de version comme premier élément de la structure. Les numéros de version. Les numéro de version sont prévus pour éviter les erreurs de décodage ASN.1. Certaines implémentations ne vérifient pas le numéro de version avant de tenter un décodage, et si une erreur est rencontrée, le numéro de version est vérifié. C'est une approche raisonnable.

   La plupart des numéros de version initiales ont été assignés dans PKCS#7 v1.5. D'autre ont été assignés quand la structure a été créée initialement. Quand une structure est mise à jours, un numéro de version supérieur est assigné. Cependant, pour s'assurer d'une interopérabilité maximale, le numéro de version supérieur est uniquement utilisé quand une nouvelle syntaxe est employée.

Vue générale

   Le CMS est suffisamment généraliste pour supporter de nombreux types de contenu différents. Ce document définis une protection de contenu, ContentInfo. ContentInfo encapsule un type de contenu identifié simple, et le type identifié peut fournir d'autres encapsulations. Ce document définis 6 types de contenu: donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée authentifiée. Des types de contenu additionnels peuvent être définis en dehors de ce document.

   Une implémentation qui se conforme à cette spécification doit implémenter le contenu de protection, ContentInfo, et doit implémenter les types de contenu donnée, donnée hashé donnée chiffrée, et donnée authentifiée. Les autres type de contenu peuvent être implémentés.

   Comme philosophie de design générale, chaque type de contenu permet un traitement en une seule passe en utilisant l'encodage BER à longueur indéfinie. L'opération single-pass est spécifiquement utile si le contenu est grand, stocké sur cassettes, ou pipé depuis un autre processus. Une opération simple passe a un inconvénient important: il est difficile d'effectuer des opérations d'encodage en utilisant DER dans une simple passe vu que les longueurs des divers composants peuvent ne pas être connus à l'avance. Cependant, les attributs signés dans le type de contenu donnée signée et les attributs authentifiés dans le type de contenu donnée authentifiée doivent être transmis sous la forme DER pour s'assurer que le destinataire puisse vérifier un contenu qui contiendrait un ou plusieurs attributs non-reconnus. Les attributs signés et les attributs authentifiés sont les seuls types de donnée utilisées dans le CMS qui nécessitent un encodage DER.

Syntaxe générale

Les identifiants d'objet suivants identifient le type d'information de contenu:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

Le CMS associe un identifiant de type de contenu avec un contenu. La syntaxe doit avoir le type ASN.1 ContentInfo:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }
    
    ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu associé. C'est un identifiant d'objet; c'est une chaîne unique d'entiers assignés par une autorité qui définie le type de contenu.
content Est le contenu associé. Le type de contenu peut être déterminé de manière unique par le contentType. Les types de contenus pour donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée chiffrée sont définies dans ce document. Si d'autres types de contenu sont définis dans d'autres documents, le type ASN.1 définis ne devrait pas être un type CHOICE.

Type de contenu donnée

L'identifiant d'objet suivant identifie le type de contenu donnée:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   Le type de contenu donnée est prévu pour référer à des chaînes d'octets arbitraires, tels que des fichiers texte ASCII; l'interprétation est laissée à l'application. De telles chaînes n'ont pas besoin de structure interne ( bien qu'ils peuvent avoir leur propre définition ASN.1 ou d'autre structure ). S/MIME utilis id-data pour identifier le contenu encodé MIME. L'utilisation de cet identifiant de contenu est spécifié dans la rfc 2311 pour S/MIME v2, rfc 2633 pour S/MIME v3, et rfc 3851 pour S/MIME v3.1. Le type de contenu donnée est généralement encapsulée dans un type de contenu donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée, ou donnée authentifiée.

Type de contenu donnée signée

   Le type de contenu donnée signée consiste d'un contenu de n'importe quel type et 0 ou plusieurs valeurs de signatures. Plusieurs signataires en parallèle peuvent signer un type de contenu.

   L'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu d'un type de contenu donnée. Une autre application typique est la diffusion de certificats et le listes de révocation de certificats. Le processus par lequel une donnée signée est construite est composé des étapes suivantes:

1. Pour chaque signataires, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. Si le signataire signe une information autre que le contenu, le hash du contenu et les autres informations sont hashées avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash est signé numériquement en utilisant la clé privée du signataire.
3. Pour chaque signataire, la valeur de signature et d'autres informations spécifiques au signataire sont collectées dans une valeur SignerInfo. Les certificats et CRL pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectées dans cette étape.
4. Les algorithmes de hash et les valeurs SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire calcule de manière indépendante le hash. Ce hash est la clé publique du signataire sont utilisés pour vérifier la valeur de la signature. La clé publique du signataire est référencée d'un des 2 manières. Elle peut être référencée par un dn de fournisseur avec un numéro de série de fournisseur pour identifier de manière unique le certificat qui contient la clé publique. Alternativement, elle peut être référencéé par un identifiant de clé du sujet, qui reçoit les clé publiques certifiés et non-certifiés. Bien qui ce ne soit pas requis, le certificat du signataire peut être inclu dans le champ des certificates du SignedData.

   Quand plus d'une signature est présente, la réussite de la validation d'une signature associée avec un signataire donné est généralement traitée comme une signature réussie dans le signataire. Cependant, il y a certaines application où d'autres règles sont nécessaires. Une application qui emploie une règle autre qu'une signature valide pour chaque signataire doit spécifier ces règles. Également, là où une simple correspondance de l'identifiant du signataire n'est pas suffisant pour déterminer si les signatures ont été générées par le même signataire, l'application doit décrire comment déterminer quelles signatures ont été générées par le même signataire. Le support de différentes communautés des bénéficiaires est la principale raison qui les signataires choisissent d'inclure plus d'une signature.

   Par exemple, le type de contenu donnée signée peut inclure des signatures générées avec l'algorithme de signature RSA et avec l'algorithme de signature à courbe elliptique (ECDSA). Celà permet aux destinataires de vérifier la signature associée avec un algorithme ou l'autre.

   Cette section est divisée en 6 parties. La première décris le type SignedData, la seconde décris EncapsulatedContentInfo, la troisième décris les information par signataire SignerInfo, la quatrième, cinquième et sixième décrivent le calcule du hash, génération de signature, et processus de vérification de signature.

Type SignedData

L'identifiant d'objet suivant identifie le type de contenu donnée signée:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Le type de contenu donnée signée devrait avoir le type ASN.1:
SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }
    
    DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
    SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. La valeur appropriée dépend des certificats, eContentType et SignerInfo. a version doit être assignée comme suit:


IF ((certificates is present) AND
    (any certificates with a type of other are present)) OR
    ((crls is present) AND
    (any crls with a type of other are present))
THEN version MUST be 5
ELSE
    IF (certificates is present) AND
        (any version 2 attribute certificates are present)
    THEN version MUST be 4
    ELSE
        IF ((certificates is present) AND
            (any version 1 attribute certificates are present)) OR
            (any SignerInfo structures are version 3) OR
            (encapContentInfo eContentType is other than id-data)
        THEN version MUST be 3
        ELSE version MUST be 1

digestAlgorithm Est une collection d'identifiant d'algorithme de hash. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Chaque élément identifie l'algorithme de hash, avec leur paramètres associés, utilisés par un ou plusieurs signataires. La collection est prévue pour lister les algorithmes de hash employées par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification de signature en une passe. Les implémentations peuvent échouer la validation des signatures qui utilisent un algorithme qui n'est pas inclus dans ce set.
encapContentInfo Est le contenu signé, consistant d'un identifiant de type de contenu et le contenu lui-même.
certificates Est une collection de certificats. Il est prévu que ce jeu de certificat soit suffisant pour contenir les chemins de certification depuis un root reconnus vers tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats qui nécessaire, et il peut y avoir suffisamment de certificats pour contenir les chemins de certification depuis 2 ou plusieurs autorités de certification racine indépendante. Il peut y avoir moins de certificats qui nécessaire, s'il est prévu que les destinataires ont un moyen alternatif pour les obtenir. Le certificat du signataire peut être inclus. L'utilisation de la version 1 de l'attribut certificates est fortement découragée.
crls Est une collection d'information de status de révocation. Il est prévu qui la collection contienne les information suffisantes pour déterminer si les certificats dans le champ certificates sont valides, mais une telle correspondance n'est pas nécessaire. Les CRL sont la principale source d'information de status de révocation. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl qui nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Quand la collection représente plus d'une signature, la réussite de la validation d'une signature d'un signataire donné doit être traitée comme une signature réussie par le signataire. Cependant, il y a certaines applications où d'autres règles sont nécessaire. Vu que chaque signataire peut employer une technique de signature différente, et de futures spécifications peut mettre à jours la syntaxe, toutes les implémentations doivent manipuler les versions non-implémentées de SignerInfo. De plus, toutes les implémentations doivent manipuler les algorithmes de signature non-implémentées quand elles sont rencontrées.

Type EncapsulatedContentInfo

Le contenu est représenté dans le type EncapsulatedContentInfo:
EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }
    
    ContentType ::= OBJECT IDENTIFIER

eContentType Est un identifiant d'objet.
eContent Est le contenu lui-même, il n'a pas besoin d'être encodé DER.

   L'omission optionnelle de eContent avec le champ EncapsulatedContentInfo rend possible la contruction de signatures externes. Dans le cas de signatures externes, le contenu à signer est absent de la valeur EncapsulatedContentInfo inclus dans le type de contenu donnée signée. Si la valeur eContent dans EncapsulatedContentInfo est absent, signatureValue est calculée et le eContentType est assignée comme si la valeur eContent était présente.

   Dans le cas dégénéré où il n'y a pas de signataires, la valeur EncapsulatedContentInfo à signer est sans importance. Dans ce cas, le type de contenu avec la valeur EncapsulatedContentInfo à signer doit être id-data, et le champ content de la valeur EncapsulatedContentInfo doit être omise.

Compatibilité avec PKCS#7

   Cette section contient un mot d'alerte pour les implémenteurs qui souhaites supporter les type de contenu SignedData CMS et PKCS#7. CMS et PKCS#7 identifient le type de contenu encapsulé avec un identifiant d'objet, mais le type ASN.1 du contenu lui-même est variable dans le type de contenu SignedData PKCS#7.

PKCS#7 définis le contenu:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
Le CMS définis eContent:
eContent [0] EXPLICIT OCTET STRING OPTIONAL

   La définition de CMS est plus facile à utiliser dans la plupart des applications, et est compatible avec S/MIME v2 et v3. les messages signés S/MIME utilisant CMS et PKCS#7 sont compatibles parce que les format de message signés identique sont spécifiés dans les rfc 2311, 2633 et 3851. S/MIME v2 encapsule le contenu MIME dans un type Data ( un OCTET STRING ) dans le contenu contentInfo de SignedData, et S/MIME v2 le porte dans le eContent encapContentInfo SignedData. Cependant, dans S/MIME v2, v3 et v3.1, le contenu MIME est placé dans un OCTET STRING et le hash est calculé sur les portions identiques de contenu.

   Il y a des incompatibilités entre les type SignedData de CMS et PKCS#7 qui le contenu encapsulé n'est pas formaté en utilisant le type Data. Par exemple, qui un reçu signé rfc3634 est encapsulé dans le type SignedData CMS, le Receipt SEQUENCE est encodé dans le SignedData encapContentInfo eContent OCTET STRING et le hash est calculé en utilisant tous l'encodage Receipt SEQUENCE ( incluant le tag, longueur et octets de valeurs). Cependant, si un reçu signé rfc2634 est encapsulé dans le type SignedData PKCS#7, alors le Receipt SEQUENCE est encodé DER dans le contenu SignedData contentInfo (une SEQUENCE, par un OCTET STRING). Cependant, le hash est calculé en utilisant seulement les octets de valeur de l'encodage de Receipt SEQUENCE.

   La stratégie suivante peut être utilisée pour la compatibilité avec PKCS#7 en traitant les type de contenu SignedData. Si l'implémentation n'est pas capable de décoder l'ASN.1 du type SignedData en utilisant la syntaxe CMS SignedData encapContentInfo eContent OCTET STRING, alors l'implémentation peut tenter de décoder le type SignedData en utilisant une syntaxe de contenu PKCS#7 SignedData contentInfo et calculer le hash.

   La stratégie suivante peut être utilisé pour la compatibilité avec PKCS#7 en créant un type de contenu SignedData dans lequel le contenu encapsulé n'est pas formaté en utilisant le type Data. Les implémentations peuvent examiner la valeur de eContentType, et ainsi ajuster l'encodage DER attendu de eContent basé sur la valeur de l'identifiant d'objet. Par exemple pour supporter MSAC, les informations suivantes peuvent être inclus:


    eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
    
    eContent contains DER-encoded Authenticode signing information

Type SignerInfo

Les information par signataire sont représentés dans le type SignerInfo:
SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
    
SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }
    
AttributeValue ::= ANY
    
SignatureValue ::= OCTET STRING

version Est le numéro de version de syntaxe. Si SignerIdentifier est le choix issuerAndSerialNumber, la version doit être 1. Si SignerIdentifier est sibjectKeyIdentifier, la version doit être 3.
sid Spécifie le certificat du signataire ( et donc sa clé publique). La clé publique du signataire est nécessaire au destinataire pour vérifier la signature.

   SignerIdentifier fournis 2 alternatives pour spécifier la clé publique du signataire. L'alternative issuerAndSerialNumber identifie le certificat du signataire par le dn du fournisseur et le numéro de série du certificat; le subjectKeyIdentifier identifie le certificat du signataire par un identifiant de clé. Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extention subjectKeyIdentifier. Quand d'autres formats de certificats sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclure les détails sur le matching d'identifiant de clé du champ certificat approprié. Les implémentations doivent supporter la réception des formes issuerAndSerialNumber et subjectKeyIdentifier.

   En générant un SignerIdentifier les implémentations peuvent supporter une des formes ( soit issuerAndSerialNumber soit subjectKeyIdentifier) et toujours l'utiliser, ou les implémentations peuvent arbitrairement mixer les 2 formes. Cependant, subjectKeyIdentifier doit être utilisé pour référer à une clé publique contenue dans un certificat non-X.509.

digestAlgorithm Identifie l'algorithme de hash, et ses paramètres associés, utilisés par le signataire. Le hash est calculé sur soit le contenu à signer soit le contenu et les attributs signés en utilisant le processus décris plus bas. l'algorithme de hash devrait être listé dans le champ digestAlgorithms du SignerData associé. Les implémentations peuvent échouer si ce n'est pas le cas.
signedAttrs Est une collection d'attributs qui sont signés. Le champ est optionnel, mais il doit être présent si le type de contenu de la valeur EncapsulatedContentInfo à signer n'est pas id-data. SignedAttributes doit être encodé DER, même si le reste de la structure set encodée BER. Les types d'attributs utiles, tels qu'une date de signature, sont définis plus loin dans ce document. Si le champ est présent, il doit contenir, au minimum, les 2 attributs suivants:

        content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo à signer. Cependant, cet attribut ne doit pas être utilisé comme partie d'un attribut contersignatures non-signé
        message-digest ayant comme valeur le hash du contenu.

signatureAlgorithm identifie l'algorithme de signature, et ses paramètres associés, utilisé par le signataire pour générer la signature numérique.
signature Est le résultat de la génération de la signature, en utilisant le hash et la clé privée du signataire.
unsignedAttrs Est une collection d'attributs qui ne sont pas signés. Ce champ est optionnel.

   Les champs de type SignedAttributes et UnsignedAttributes ont la signification suivante:

attrType Indique le type d'attribut, c'est un identifiant d'objet.
attrValues Est un jeu de valeurs pour cet attribut.

Processus de calcul du hash

   Le processus de calcul du hash calcule un hash sur soit le contenu à signer, soit le contenu et les attributs signés. Dans tous les cas, l'entrée initiale du processus est la valeur du contenu encapsulé à signer. Spécifiquement, l'entrée initiale est la chaîne d'octets eContent de encapContentInfo auquel le processus de signature est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent sont entrés dans l'algorithme de hashage, et non le tag ou les octets de longueur.

   Le résultat du processus de calcul du hash dépend de la présence ou non du champ signedAttrs. Quand le champ est absent, le résultat est simplement le hash du contenu. Quand le champ est présent, cependant, le résultat est le hash de l'encodage DER complet de la valeur SignedAttrs contenu dans le champ signedAttrs. Vu que la valeur SignedAttrs, quand présent, doit contenir les attributs de type de contenu et de hash, ces valeurs sont indirectement incluses dans le résultat. L'attribut content-type ne doit pas être inclus dans un attribut non signé countersignature. Un encodage séparé du champ signedAttrs est effectué pour le calcul du hash. Le IMPLICIT [0] tag dans signedAttrs n'est pas utilisé pour l'encodage DER, et EXPLICIT SET OF tag est utilisé, et doit donc être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur SignedAttributes.

   Quand le champ signedAttrs est absent, seul les octets compris dans la valeur de la chaîne d'octets eContent de encapContentInfo du SignedData sont entrés dans le calcul du hash. Cela a l'avantage que la longueur du contenu à signer n'a pas besoin d'être connus à l'avance.

   Bien que le les octets de tag et de longueur de la chaîne d'octets eContent de encapContentInfo ne sont pas inclus dans le calcul du hash, ils sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme.

Processus de génération de signature

   L'entrée du processus de génération de signature inclus le résultat du processus de calcul du hash et la clé privée du signataire. Les détails de la génération de la signature dépend de l'algorithme de signature employé. L'identifiant d'objet, avec ses paramètres, qui spécifient l'algorithme de signature employé par le signataire sont placés dans le champ signatureAlgoritm. La valeur de la signature générée par le signataire doit être encodé en chaîne d'octets et placés dans le champ signature.

Processus de vérification de signature

   L'entrée du processus de vérification de signature inclus le résultat du processus de calcul du hash et la clé publique du signataire. Le destinataire peut obtenir la bonne clé publique pour le signataire par tous moyens, mais la méthode préférée est depuis un certificat obtenu depuis le champ certificates de SignedData. La sélection et la validation de la clé publique du signataire peut être basée sur la validation du chemin de certification aussi bien que d'autres contextes externes, mais c'est au-delà du scope de ce document. Les détails de la vérification de la signature dépendent de l'algorithme de signature employé.

   Le destinataire ne doit pas s'appuyer sur les valeurs de hash calculés par l'auteur. Si le signerInfo de SignedData inclus un SignedAttributes, alors le hash doit être calculé comme décris plus haut. Pour que la signature soit valide, la valeur du hash calculée par le destinataire doit être la même que la valeur de l'attribut messageDigest inclus dans le signedAttributes du signerInfo du SignedData.

   Si signerInfo du SignedData inclus signedAttributes, alors la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo du signedData.

Type de contenu Enveloped-data

   Le type de contenu donnée enveloppée consiste d'un contenu chiffré et de clé de chiffrement de contenu chiffrés pour un ou plusieurs destinataires. La combinaison du contenu chiffré et un clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Tout type de contenu peut être enveloppé pour un nombre arbitraire de destinataires utilisant tout type de technique de gestion de clé supportés pour chaque destinataire.

   L'application typique du type de contenu donnée enveloppée représente une ou plusieurs enveloppes numérique de destinataires sur le contenu des type de de contenu donnée et donnée signée. Enveloped-data est construit par les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu est généré aléatoirement.
2. La clé de chiffrement de contenu est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé, mais 4 techniques générales sont supportées:

        transport de clé La clé de chiffrement de contenu est chiffrée dans la clé publique clé publique du destinataire.
        agrément de clé La clé publique du destinataire est la clé privée de l'émetteur sont utilisé pour générer une clé symétrique, puis la clé de chiffrement de contenu est chiffré dans la clé symétrique.
        Clé de chiffrement symétrique La clé de chiffrement de contenu est chiffré dans un clé de chiffrement de clé symétrique distribuée précédemment.
        mot de passes La clé de chiffrement de contenu est chiffrée dans une clé de chiffrement de contenu qui est dérivée d'un mot de passe ou autre valeur de secret partagée.

3. Pour chaque destinataire, la clé de chiffrement de contenu chiffré et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Le contenu est chiffré avec la clé de chiffrement de contenu. Le chiffrement de contenu peut nécessiter qui le contenu soit padded à un multiple d'une taille de block.
5. Les valeurs RecipientInfo pour tous les destinataires sont collectés ensemble avec le contenu chiffré pour former une valeur enveloppée.

   Un destinataire ouvre l'enveloppe numérique en déchiffrant celle qui contient les clé de chiffrement de contenu chiffrés puis déchiffre le contenu chiffré avec la clé de chiffrement de contenu récupéré.

   Cette section est divisée en 4 parties. La première partie décris le type EnvelopedData, la seconde partie décris le type d'information par destinataire RecipientInfo, et les troisième et quatrième partie décrivent le chiffrement de contenu et les processus de chiffrement de clé.

Type EnvelopedData

L'identifiant d'objet suivant identifie le type de contenu enveloped-data suivant:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Le type donnée enveloppée devrait avoir le type ASN.1 suivant:
EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
    
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING
    
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

version Est le numéro de version de la syntaxe. La valeur appropriée dépend de originatorInfo, RecipientInfo, et unprotectedAttrs. La version doit être assignée comme suit:


IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 4
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present)) OR
        (any RecipientInfo structures include pwri) OR
        (any RecipientInfo structures include ori)
    THEN version is 3
    ELSE
        IF (originatorInfo is absent) AND
            (unprotectedAttrs is absent) AND
            (all RecipientInfo structures are version 0)
        THEN version is 0
        ELSE version is 2

originatorInfo Fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion des clés. Il peut contenir des certificats et des crls:

        certs est une collection de certificats. certs peut contenir les certificats d'expéditeur associés avec de nombreux algorithmes de gestion de clés. certs peut également contenir des certificats d'attribut associés avec l'expéditeur. Les certificats contenus dans certs sont prévus pour être suffisants pour tous les destinataires pour construire des chemin de validation depuis un root reconnu. Cependant, certs peut contenir plus de certificats que nécessaire, et il peut y avoir les certificats nécessaire pour créer les chemins de validation de 2 ou plusieurs autorité de certification racine. Alternativement, il est prévu que les destinataires aient un moyen alternatif pour obtenir les certificats nécessaires.
        crls est une collection de CRL. Il est prévu que ce jeu contienne les informations suffisantes pour déterminer si les certificats dans le champ certs sont valides ou non. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl que nécessaire.

recipientInfos est une collection d'information par destinataire, il doit y avoir au moins un élément dans la collection.
encryptedContentInfo Est l'information de contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Le champ est optionnel.
EncryptedContentInfo Les champs ont la signification suivante:

        contentType Indique le type de contenu
        contentEncryptionAlgorithm identifie l'algorithme de chiffrement de contenu, et ses paramètres associés, utilisés pour chiffrer le contenu. Le même algorithme de chiffrement de contenu et la clé de chiffrement de contenu sont utilisé pour tous les destinataires.

Type RecipientInfo

   Les informations par destinataire sont représentés dans le type RecipientInfo. RecipientInfo a un format différent pour chacune des techniques de gestion de clés supportés. Tout type de technique de gestion de clé peut être utilisé pour chaque destinataire de même contenu chiffré. Dans tous les cas, la clé de chiffrement de contenu chiffrée est transféréeà un ou plusieurs destinataires.

   Vu que toutes les implémentations ne vont pas supporter tous les algorithmes de gestion de clés possibles, toutes les implémentations doivent gérer les algorithmes non-implémentés quand ils sont rencontrés. Par exemple, si un destinataire reçoit une clé de chiffrement de contenu chiffrée avec leur clé publique RSA en utilisant RSA-OAEP et que l'implémentation ne supporte que RSA PKCS#1 v1.5, alors l'échec doit être implémentée.

   Les implémentations doit supporter le transport de clé, l'agrément de clé, et les clé de chiffrement de clé symétriques distribués précédemment, comme représentés par ktri, kari, et kekri, respectivement. Les implémentations peuvent supporter la gestion de clé basé sur mot de passe comme représenté par pwri. Les implémentations peuvent supporter d'autres technique de gestion de clé comme représenté par ori. Vu que chaque destinataire peut employer une technique de gestion de clé différente et que les spécifications futures peuvent définir des technique supplémentaires, toutes les implémentation doit manipuler les alternatives non-implémentées, les versions non-implémentées et les ori inconnues.


RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientinfo,
    ori [4] OtherRecipientInfo }
    
    EncryptedKey ::= OCTET STRING

Type KeyTransRecipientInfo

Les informations par destinataire utilisant le transport de clé sont représentés dans le type KeyTransRecipientInfo. Chaque instance de KeyTransRecipientInfo transfert la clé de chiffrement de contenu à un destinataire.
KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

version Est le numéro de version de la syntaxe. Si RecipientIdentifier est issuerAndSerialNumber, la version doit être 0. Si c'est subjectKeyIdentifier, la version doit être 2.
rid Spécifie le certificat ou la clé du destinataire qui a été utilisé par l'émetteur pour protéger la clé de chiffrement de contenu. RecipientIdentifier fournis 2 alternatives pour spécifier le certificat du destinataire, et donc la clé publique du destinataire. Le certificat du destinataire doit contenir une clé publique de transport de clé. Donc, un certification X.509v3 d'un destinataire qui contient un extension d'utilisation de clé doit avoir le bin keyEncipherment. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par le dn du fournisseur et le numéro de série du certificat; le sibjectKeyIdentifier identifie le certificat du destinataire par un identifiant de clé.

           Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension subjectKeyIdentifier X.509. Quand d'autres formats de certificat sont référencés, les documents qui spécifient le format du certificat et son utilisation avec le CMS doit inclure les détails sur la correspondance le l'identifiant de clé. Pour le traitement du destinataire, les implémentations doivent supporter ces alternatives pour spécifier le certificat du destinataire. Pour l'émetteur, les implémentations doivent supporter au moins un de ces alternatives.

keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisés pour chiffrer la clé de chiffrement de contenu pour le destinataire.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu pour le destinataire.

Type KeyAgreeRecipientInfo

Les informations de destinataire utilisant l'accord de clé est représenté dans le type KeyAgreeRecipientInfo. Chaque instance de KeyAgreeRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui utilisent le même algorithme d'accord de clé et les paramètres de domaine pour cet algorithme.
KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }
    
OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }
    
OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }
    
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
    
RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }
    
KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
SubjectKeyIdentifier ::= OCTET STRING

version Est le numéro de version de la syntaxe. Doit toujours être 3.
originator Est un choix avec 3 alternatives spécifiant la clé publique de l'accord de clé de l'émetteur. L'émetteur utilise la clé privée correspondant et la clé publique du destinataire pour générer une clé paire. La clé de chiffrement de contenu est chiffrée dans la clé paire. L'alternative issuerAndSerialNumber identifie le certificat de l'émetteur, et donc sa clé publique, par dn de fournisseur et numéro de série. l'alternative subjectKeyIdentifier identifie le certificat de l'émetteur par identifiant de clé.

           Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension X.509 subjectKeyIdentifier. Quand d'autres format de certificat sont référencés, les documents qui spécifient le format de certificat et son utilisation avec le CMS doit inclure les détails sur le matche d'identifiant de clé. L'alternative originatorKey inclus l'identifiant d'algorithme et la clé publique d'accord de clé de l'émetteur. Cette alternative permet à l'auteur l' anonymité vu que la clé publique n'est pas certifiée. Les implémentations doivent suppporter les 3 alternatives pour spécifier la clé publique de l'émetteur.

ukm est optionnel. Avec certains algorithmes d'accord de clé, l'émetteur fournis un User Keying Material (UKM) pour s'assurer qu'une clé différente est générée chaque fois que les même 2 parties génèrent une clé paire. Les implémentations doivent accepter une séquence KeyAgreeRecipientInfo qui inclus un champ ukm. Les implémentations qui ne supportent par les algorithmes d'accord de clé qui utilisent UKM doivent manipuler correctement la présence des UKM.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
recipientEncryptedKeys Inclus un identifiant de destinataire et une clé chiffrée pour un ou plusieurs destinataires. le KeyAgreeRecipientIdentifier est un choix avec 2 alternatives spécifiant le certificat du destinataire, et donc sa clé publique, qui a été utilisée par l'émetteur pour générer un clé de chiffrement de clé paire. Le certificat du destinataire doit contenir une clé publique d'accord de clé. Donc, un certificat X.509 v3 d'un destinataire qui contient une utilisation de clé étendue doit avoir le bit keyAgreement. La clé de chiffrement de contenu est chiffrée dans la clé de chiffrement de clé paire. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par dn du fournisseur et numéro de série. encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé paire générée en utilisa l'algorithme d'accord de clé. Les implémentations doivent supporter ces alternatives en spécifiant le certificat du destinataire.
subjectKeyIdentifier Identifie le certificat du destinataire par identifiant de clé.
date est optionnel. Quand présent, la date spécifie celle du précédent UKM distribué précédemment qui a été utilisé par l'émetteur.
other est optionnel. Quand présent, ce champ contient des informations additionnels utilisé par le destinataire pour localiser l'UKM utilisé par l'émetteur.

Type KEKRecipientInfo

Les informations de déstinataire utilisant les clés symétriques précédemment distribuées sont représentés dans le type KEKRecipientInfo. Chaque instance de KEKRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui ont la clé de chiffrement de clé distribuée précédemment.
KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

version est le numéro de version de la syntaxe. Doit être 4.
kekid spécifie un clé de chiffrement de clé symétrique qui a été distribué précédemment à l'émetteur en un ou plusieurs destinataires.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé.
keyIdentifier identifie la clé de chiffrement de clé qui a été précédemment distribuée à l'émetteur et un ou plusieurs destinataires.
date optionnel. Quand présent, la date spécifie un clé de chiffrement de clé simple depuis un jeu qui a été distribué précédemment.
other optionnel. Quand présent, ce champ contient des informations optionnelles utilisées par le destinataire pour déterminer la clé de chiffrement de clé utilisée par l'émetteur.

Type PasswordRecipientinfo

Les information de destinataire utilisant un mot de passe ou une valeur secrète partagée est représentée dans le type PasswordRecipientinfo. Chaque instance de PasswordRecipientinfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui possède un mot de passe ou une valeur secrète partagée. Le type PasswordRecipientinfo est définie dans la rfc3211:
PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- Always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
     OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

version est le numéro de version de la syntaxe. Doit être 0.
keyDerivationAlgorithm identifie l'algorithme de dérivation de clé et ses paramètres associés, utilisé pour dériver la clé de chiffrement de clé du mot de passe ou de la valeur secrète partagée. Si ce champ est absent, la clé de chiffrement de clé est fournie depuis une source externe, par example, un jeton cryptographique physique tel qu'une carte à puce.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu avec la clé de chiffrement de clé.

Type OtherRecipientinfo

Les information de destinataire pour les techniques de gestion de clé additionnels sont représentés dans le type OtherRecipientInfo. Le type OtherRecipientInfo permet aux technique de gestion de clé au delà des type précédemment définis d'être spécifiés dans de futures documents. Un identifiant d'objet identifie de manière unique de telles techniques de gestion de clé.
OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType }

oriType identifie la technique de gestion de clé
oriValue contient les éléments de données du protocole nécessaire pour un destinataire utilisant la technique de gestion de clé identifiée.

Processus de chiffrement de contenu

   La clé de chiffrement de contenu pour l'algorithme de chiffrement de contenu désiré est généré aléatoirement. La donnée à protéger est padded comme décris plus bas, puis cette donnée est chiffrée en utilisant la clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets arbitraire (la donnée) en une autre chaîne d'octets (le texte chiffré) sous le contrôle d'une clé de chiffrement de contenu. La donnée chiffrée est inclue dans encryptedContent de encryptedContentInfo du EnvelopedData.

Certains algorithmes de chiffrement de contenu assument que la longueur d'entrée est un multiple de k octets, où k est supérieur à 1. Pour de tels algorithmes, l'entrée devrait être complétée à la fin avec des octets k-(lth mod k) ayant pour valeur (k-lth mod k), où lth est la longueur de l'entrée. En d'autres termes, l'entrée est complétées à la fin avec une des chaînes suivantes:
__________01 -- if lth mod k = k-1
_______02 02 -- if lth mod k = k-2
__________.
__________.
__________.
k k ... k k -- if lth mod k = 0

   Le padding peut être supprimé de manière non ambigu vu que toute l'entrée est paddée, incluant les valeurs d'entrée qui sont déjà un multiple de la taille de block, et aucune chaîne de padding n'est un suffix d'un autre. Cette méthode de padding est définie si et seulement si k est inférieur à 256.

Processus de chiffrement de clé

   L'entrée du processus de chiffrement de clé -- la valeur fournie à l'algorithme de chiffrement de clé du destinataire -- est simplement la valeur de la clé de chiffrement de contenu.

   N'importe quelle technique de gestion de clé mentionnées dans ce document peuvent être utilisées pour chaque destinataire de même contenu chiffré.

Type de contenu Digested-Data

   Le type de contenu donnée hashée consiste d'un contenu de n'importe quel type et un hash du contenu. Typiquement, le type de contenu donnée hashée est utilisé pour fournir une intégrité de contenu, et le résultat devient généralement un entrée au type de contenu donnée enveloppée. Les étapes suivantes construisent une donnée hashée:

1. Un hash est calculé sur le contenu avec un algorithme de hashage.
2. L'algorithme de hashage et le hash sont collectés ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant le hash à un hash calculé indépendamment.

L'identifiant d'objet suivant identifie le type de contenu digested-data:
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Le type de contenu digested-data devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING

version est le numéro de version de la syntaxe. Si le type de contenu incapsulé est id-data, la valeur doit être 0, 2 sinon.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés.
encapContentInfo est le contenu qui est hashé
digest est le résultat du processus de hashage.

   L'ordre des champs rend possible le traitement d'un valeur DigestedData en une seule passe.

Type de contenu Encrypted-data

   Le type de contenu donnée chiffrée consiste d'un contenu de n'importe quel type, chiffré. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire, ni clé de chiffrement de contenu. Les clé doivent être gérées par un autre moyen.

   L'application typique du type de contenu chiffré est de chiffré le contenu du type de contenu donnée pour un stockage local, où la clé de chiffrement est dérivée d'un mot de passe.

L'identifiant d'objet suivant identifie le type de contenu encrypted-data:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Le type de contenu encrypted-data devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

version est le numéro de version de la syntaxe. si unprotectedAttrs est présent, la version doit être 2, 0 sinon.
encryptedContentInfo est le contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Ce champ est optionnel.

Type de contenu Authenticated-data

   Le type de contenu donnée authentifiée consiste d'un contenu de n'importe quel type, un MAC, et de clés d'authentification chiffrés pour un ou plusieurs destinataires. La combinaison du MAC et d'une clé d'authentification chiffrée pour un destinataire est nécessaire pour que ce destinataire puisse vérifier l'intégrité du contenu. Tout type de contenu peut être protégé pour l'intégrité pour plusieurs destinataires.

  Le processus par lequel un donnée authentifiée est construite est faite des étapes suivantes:

1. Une clé d'authentification de message pour un algorithme d'authentification de message particulier est généré aléatoirement.
2. La clé d'authentification de message est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé.
3. Pour chaque destinataire, la clé d'authentification de message chiffrée et les autres information spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Un utilisant la clé d'authentification de message, l'auteur calcul une valeur MAC sur le contenu. Si l'auteur authentifie une information en plus du contenu, un hash est calculé sur le contenu, le hash du contenu est les autres informations sont authentifiées en utilisant la clé d'authentification de message, et le résultat devient la valeur MAC.

Type AuthenticatedData

L'identifiant d'objet suivant identifie le type de contenu authenticated-data:
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Le type de contenu authenticated-data devrait avoir le type ASN.1:
AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
    
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
MessageAuthenticationCode ::= OCTET STRING

version est le numéro de version de la syntaxe. La version doit êtré assignée comme suit:

IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 3
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present))
    THEN version is 1
    ELSE version is 0

originatorInfo fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion de clé. Il peut contenir des certificats, des attributs de certificat, et des CRLs.
recipientInfos Est une collection d'information par destinataire. Il doit y avoir au moins un élément dans la collection.
macAlgorithm est un identifiant d'algorithme MAC. Il identifie l'algorithme MAC et ses paramètres associés, utilisé par l'auteur.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés, utilisé pour calculer un hash sur le contenu encapsulé si des attributs authentifiés sont présents. Si ce champ est présent, authAttrs doit l'être également.
authAttrs est une collection d'attributs authentifiés. La structure AuthAttributes doit être encodé DER, même si le reste du la structure est encodée BER. Si cet attribut est présent, il doit contenir au minimum ces 2 attributs:

        content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo qui est authentifée.
        message-digest ayant comme valeur le hash du contenu.

mac est le message authentication code
unauthAttrs est une collection d'attributs non authentifiés. Ce champ est optionnel.

Génération du MAC

   Le processus de calcul du MAC calcule un code d'authentification de message sur soit le contenu à authentifier soit un hash du contenu à authentifier avec les attributs authentifié de l'auteur.

   Si le champ authAttrs est absent, l'entrée du processus de calcul MAC est la valeur de la chaîne d'octets de eContent dans encapContentInfo. Seul les octets comprenant la valeur de eContent sont entrées dans l'algorithme MAC; le tag et les octets de longueur sont omis. Cela a l'avantage que la longueur du contenu à authentifier n'a pas besoin d'être connu à l'avance.

   Si le champ authAttrs est présent, les attributs content-type et message-digest doivent être inclus, et l'entrée dans le processus de calcul du mac est l'encodé DER de authAttrs. Un encodage séparé du champ authAttrs est effectué pour un calcul de hash. Le tag implicite dans le champ authAttrs n'est pas utilisé pour l'encodage DER, un jeu explicite de tag est utilisé à la place. ce qui signifie que l'encodé DER du jeu de tag, au lieu du tag implicite, doit être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur authAttrs.

   Le processus de calcule du hash calcul un hash sur le contenu à authentifier. L'entrée initiale du processus de calcul du hash est la valeur du contenu encapsulé à authentifier. Spécifiquement, l'entrée est la chaîne d'octets de eContent de encapContentInfo pour lequel le processus d'authentification est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent de encapContentInfo sont entrés dans l'algorithme de hashage, pas le tag ni les octets de longueur. Cela a l'avantage que la longueur du contenu n'a pas besoin d'être connu à l'avance. Bien que le tag et les octets de longueur ne sont pas inclus dans le calcul du hash, il sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme de hashage.

   L'entrée du processus de calcul MAC inclus la donnée d'entrée MAC définie précédemment, et une clé d'authentification transportée dans une structure recipientInfo. Les détails du calcul MAC dépend de l'algorithme utilisé. L'identifiant d'objet et ses paramètres, qui spécifie l'algorithme employé par l'auteur est placé dans le champ macAlgorithm. La valeur MAC générée par l'auteur est encodé en chaîne d'octet dans le champ mac.

Vérification du MAC

   L'entrée du processus de vérification du MAC inclus les donnée d'entrée ( déterminées sur la présence ou non du champ authAttrs), et la clé d'authentification dans recipientInfo. Les détails du processus de vérification du MAC dépend de l'algorithme MAC employé.

   Le destinataire ne doit pas se fier aux valeurs MAC et hash de l'auteur. Pour que l'authentification réussisse, la valeur MAC calculée par le destinataire doit être la même que la valeur du champ mac. Similairement, pour que l'authentification réussisse quand le champ authAttrs est présent, le hash du contenu calculé par le destinataire doit être le même que le hash inclus dans l'attribut message-digest.

   Si AuthenticatedData inclus authAttrs, la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo de AuthenticatedData.

Types utiles

   Cette section est divisée en 2 parties. La première définis les identifiants d'algorithme, et la seconde définie d'autres type utiles.

DigestAlgorithmIdentifier

   Le type DigestAlgorithmIdentifier identifie un algorithme de hashage. (ex: SHA-1, MD2, et MD5). Un algorithme de hashage mappe un chaîne d'octets ( le contenu ) en une autre chaîne d'octets ( le hash ).

  DigestAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureAlgorithmIdentifier

   Le type SignatureAlgorithmIdentifier identifie un algorithme de signature, et peut également identifier un algorithme de hashage. (ex: RSA, DSA, DSA avec SHA-1, ECDSA, et ECDSA avec SHA-256). Un algorithme de signature supporte les opérations de génération et de vérification de signature. L'opération de génération de signature utilise le hash et la clé privée du signataire pour générer une valeur signature. L'opération de vérification de signature utilise le hash et la clé publique du signataire pour déterminer si la signature est valide.

  SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier

   Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé pour chiffrement une clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets ( la clé ) en une autre chaîne d'octets ( la clé chiffrée ) sous le contrôle de la clé de chiffrement. L'opération de déchiffrement est l'inverse de l'opération de chiffrement. Les détails du chiffrement et du déchiffrement dépendent de l'algorithme de gestion de clé utilisé.

  KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier

   Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu. (ex: Triple-DES et RC2). Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le texte en clair ) en une autre chaîne d'octets ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse de l'opération de chiffrement.

  ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

MessageAuthenticationCodeAlgorithm

KeyDerivationAlgorithmIdentifier

   Le type KeyDerivationAlgorithmIdentifier est spécifié dans la rfc 3211. Les algorithmes de dérivation de clé convertissent un mot de passe ou une valeur de clé secrète en une clé de chiffrement de clé.

  KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

RevocationInfoChoices

   Le type RevocationInfoChoices donne un jeu d'informations de statut de révocation alternatif. Il est prévu que le jeu contienne les informations suffisantes pour déterminer si les certificats et les attributs de certificat avec lequel le jeu est associé sont révoqués. Cependant, il peut y avoir plus d'informations de statut de révocation que nécessaire. Les listes de révocation de certificats X.509 sont la principale source d'informations de statut de révocation, mais tout autre format d'information de révocation peut être supporté. L'alternative OtherRevocationInfoFormat est fournis pour supporter tout autre format de révocation sans modification du CMS.

   CertificateList peut contenir un CRL, une ARL, un Delta CRL, ou un attribut CRL. Toutes ces listes partagent une syntaxe commune. Le type CertificateList donne une CRL. les CRL sont spécifiés dans X.509, et sont prévus pour être utilisés sur l'Internet.

La définition de CertificateList est prise de X.509:
RevocationInfoChoices ::= SET OF RevocationInfoChoice
    
RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }
    
OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }

CertificateChoices

Le type CertificateChoices donne soit un certificat étendus PKCS#6, un ACv1, ACv2, ou tout autre format. L'alternative OtherCertificateFormat est fournis pour supporter tout autre format de certificat sans modification du CMS.
CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }
    
OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }

CertificateSet

   Le type CertificateSet fournis un jeu de certificats. Il est prévu que le jeu soit suffisant pour contenir des chemins de certification depuis une autorité racine vers tour les certificats de l'émetteur avec lequel le jeu est associé. Cependant, il peut y avoir plus de certificats que nécessaire, ou moins que nécessaire.

   La signification précise d'un chemin de certification est hors du scope de ce document. Certaines applications peuvent imposer des limites maximales sur la longueur d'un chemin de certification; d'autre peuvent forcer certaines relations entre les sujets et les fournisseurs de certificats dans un chemin de certification.

  CertificateSet ::= SET OF CertificateChoices

IssuerAndSerialNumber

   Le type IssuerAndSerialNumber identifie un certificat, et donc une entité et une clé publique, par le nom distinct du fournisseur du certificat et un numéro de série de certificat spécifique au fournisseur.

La définition de Name vient de X.501-88 et de CertificateSerialNumber vient de X.509-97:
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }
    
CertificateSerialNumber ::= INTEGER

CMSVersion

   Le type CMSVersion donne un numéro de version de syntaxe, pour la compatibilité avec de futures révisions de cette spécification.

  CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

UserKeyingMaterial

   Le type UserKeyingMaterial donne une syntaxe pour UKM. Certains agréments de clé nécessitent UKM pour s'assurer qu'une clé différente est générée à chaque fois que les même 2 parties génèrent une clé pairée. L'émetteur fournis un UKM à utiliser avec un algorithme d'agrément de clé spécifique.

  UserKeyingMaterial ::= OCTET STRING

OtherKeyAttribute

Le type OtherKeyAttribute donne une syntaxe pour inclure d'autres attributs de clé qui permettent au destinataire de sélectionner la clé utilisé par l'émetteur. L'identifiant d'objet d'attribut doit être enregistré avec la syntaxe de l'attribut lui-même. L'utilisatino de cette structure devrait être évité vu qu'il peut entraver l'intéropérabilité
OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

Attributs utiles

   Cette section définis les attributs qui peuvent être utilisés avec signed-data, enveloped-data, encrypted-data, ou authenticated-data. La syntaxe de l'attribut est compatible avec X.501. Certains des attributs définis dans cette section ont été définis à l'origine dans PKCS#9; d'autres ont été définis dans une précédente version de cette spécification. Les attributs ne sont pas listés dans un ordre particulier.

   D'autres attributs sont définis ailleurs, notamment dans S/MIME v3.1 et dans ESS, qui inclus également des recommandations sur le placement de ces attributs.

Content Type

   Le type d'attribut content-type spécifie le type de contenu de ContentInfo dans une donnée signée ou une donnée authentifié. L'attribut content-type doit être présent quand des attributs signés sont présents dans une donnée signée ou que des attributs authentifiés sont présents dans une donnée authentifiée. La valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo dans la donnée signée ou la donnée authentifiée.

   L'attribut content-type doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'identifiant d'objet suivant identifie l'attribut content-type:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

Les valeurs d'attribut content-type ont le type ASN.1:
ContentType ::= OBJECT IDENTIFIER

   Même si la syntaxe est définie comme un jeu d'AttributeValue, un attribut content-type doit avoir un simple valeur d'attribut. 0 ou plusieurs instances de AttributeValue ne sont pas permis.

   Les syntaxe SignedAttributes et AuthAttributes sont chacun définis comme un jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut content-type. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut content-type.

Message Digest

   Le type d'attribut message-digest spécifie la hash de la chaîne d'octet eContent de encapContentInfo à signer dans une donnée signée, ou à authentifier dans une donnée authentifiée. pour une donnée signée, le hash est calculé en utilisant l'algorithme de hashage du signataire. Pour une donnée authentifiée, le hash est calculé en utilisant l'algorithme de hashage de l'auteur.

   Dans une donnée signée, le type d'attribut signé message-digest doit être présent quand il y a des attributs signés. dans une donnée authentifiée, le type d'attribut authentifié message-digest doit être présent quand il à des attribut authentifiés.

   L'attribut message-digest doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'indentifiant d'objet suivant identifie l'attribut message-digest:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

Les valeurs d'attribut message-digest ont le type ASN.1:
MessageDigest ::= OCTET STRING

   Un attribut message-digest doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme un jeu d'AttributValue. Il ne doit pas y avoir 0 ou plusieurs instances de AttributeValue.

   La syntaxe SignedAttributes et AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo doit inclure seulement une instance de l'attribut message-digest. Similairement, AuthAttributes dans un AuthenticatedData doit inclure seulement une instance de l'attribut message-digest.

Signing Time

   Le type d'attribut signing-time spécifie la date à laquelle le signataire a effectué la signature. Le type d'attribut signing-time est prévu pour être utilisé dans une donnée signée. Il doit être un attribut signé, ou un attribut authentifié.

L'identifiant d'objet suivant identifie l'attribut signing-time:
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Les valeurs de l'attribut signing-time ont le type ASN.1:
SigningTime ::= Time
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalizedTime GeneralizedTime }

   Note: la définition de Time matche celui spécifié dans la version 1997 de X.509. Les dates entre le 1 janvier 1950 et le 31 décembre 2049 (inclus) doit être encodé en UTCTime. Toutes dates en dehors de cette plage doivent être encodés en GeneralizedTime.

   Les valeurs UTCTime doivent être exprimés en Coordinated Universal Time ( GMT ) et doivent inclure les secondes ( YYMMDDHHMMSSZ), même où le nombre de secondes est 0. Minuit doit être représenté "YYMMDD000000Z". L'information du siècle est implicit, et le siècle doit être interprété comme suit:

        - où YY est supérieur ou égal à 50, l'année doit être interprétée en 19YY
        - où YY est inférieur ou égal à 50, l'année doit être interprétée en 20YY.

   Les valeurs GeneratizedTime doivent être exprimées en GMT et doivent inclure les secondes ( YYYYMMDDHHMMSSZ ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure des fractions de secondes.

   Un attribut signing-time doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme jeu d'AttributeValue. Il ne doit pas y avoir 0 ou plusieurs instances d'AttributeValue.

   La syntaxe SignedAttributes et la syntaxe AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut signing-time. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut signing-time.

   Aucun prérequis n'est imposé concernant l'exactitude de la date de signature, et l'acceptation d'une date de signature est laissée à la discretion du destinataire. Il est prévu, cependant, que certains signataires, tels que les serveurs time-stamp, vont l'approuver implicitement.

Countersignature

   Le type d'attribut Countersignature spécifie une ou plusieurs signatures sur les octets de contenu de la chaîne d'octets signature dans une valeur signerInfo d'une donnée signée. C'est à dire que le hash est calculé sur les octets comprenant la valeur de la chaîne d'octets, sans inclure le tag ni les octets de longueur. Donc, le type d'attribut countersignature contre-signe ( signe en série) une autre signature.

   L'attribut countersignature doit être un attribut non signé, il ne doit pas être un attribut signé, un attribut authentifié, un attribut non-authentifié, ou un attribut non-protégé.

L'identifiant d'objet suivant identifie l'attribut countersignature:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

Les valeurs d'attribut countersignature ont le type ASN.1:
Countersignature ::= SignerInfo

   Les valeurs countersignature ont la même signification que les valeurs SignerInfo pour les signatures ordinaires, excepté:

        1. le champ signedAttributes ne doit pas contenir un attribut content-type, il n'y a pas de type de contenu pour les contre-signatures
        2. Le champ signedAttributes doit contenir un attribut message-digest s'il contient d'autres attributs
        3. L'entrée du processus de hashage sont les octets de contenu de l'encodé DER du champ signatureValue de la valeur SignerInfo avec lequel l'attribut est associé.

   Un attribut countersignature peut avoir plusieurs valeurs d'attribut. La syntaxe est définie comme jeu d'AttributeValue, et il doit y avoir au moins une valeur présente.

   La syntaxe UnsignedAttributes est définie comme un jeu d'attributs. UnsignedAttributes dans un SignerInfo peut inclure plusieurs instances de l'attribut countersignature.

   Un countersignature, vu qu'il a le type SignerInfo, peut lui-même contenir un attribut countersignature. Donc, il est possible de construire arbitrairement une longue série de contre-signatures.

Modules ASN.1

   Cette section contient le module ASN.1 pour le CMS, et la section suivante contient le module ASN.1 pour l'attribut certificat version 1.

Module ASN.1 CMS


CryptographicMessageSyntax2004
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
    
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    
-- EXPORTS All
-- Les types et valeurs définies dans ce module sont exportés pour l'utilisation dans
-- d'autres modules ASN.1. D'autres applications peuvent les utiliser pour leur propre usage.
    
IMPORTS
    
    -- Imports de la RFC 5280, Appendix A.1
        AlgorithmIdentifier, Certificate, CertificateList,
        CertificateSerialNumber, Name
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }
    
    -- Imports de la RFC 3281, Appendix B
        AttributeCertificate
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) }
    
    -- Imports de l'Appendix B de ce document
        AttributeCertificateV1
            FROM AttributeCertificateVersion1
                { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } ;
    
-- Cryptographic Message Syntax
    
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }
    
ContentType ::= OBJECT IDENTIFIER
    
SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }
    
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
SignerInfos ::= SET OF SignerInfo
    
EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }
    
SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
    
SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }
    
AttributeValue ::= ANY
    
SignatureValue ::= OCTET STRING
    
EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
    
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING
    
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientInfo,
    ori [4] OtherRecipientInfo }
    
EncryptedKey ::= OCTET STRING
    
KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }
    
OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }
    
OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }
    
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
    
RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }
    
KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }
    
RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
SubjectKeyIdentifier ::= OCTET STRING
    
KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType }
    
DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING
    
EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
    
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
MessageAuthenticationCode ::= OCTET STRING
    
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
    
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
    
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
    
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
    
RevocationInfoChoices ::= SET OF RevocationInfoChoice
    
RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }
    
OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }
    
CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }
    
AttributeCertificateV2 ::= AttributeCertificate
    
OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }
    
CertificateSet ::= SET OF CertificateChoices
    
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }
    
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
    
UserKeyingMaterial ::= OCTET STRING
    
OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
    
-- Content Type Object Identifiers
    
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
    
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
    
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
    
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
    
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
    
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
    
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }
    
-- The CMS Attributes
    
MessageDigest ::= OCTET STRING
    
SigningTime ::= Time
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }
    
Countersignature ::= SignerInfo
    
-- Attribute Object Identifiers
    
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
    
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
    
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
    
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
    
-- Obsolete Extended Certificate syntax from PKCS #6
    
ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate }
    
ExtendedCertificate ::= SEQUENCE {
    extendedCertificateInfo ExtendedCertificateInfo,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature Signature }
    
ExtendedCertificateInfo ::= SEQUENCE {
    version CMSVersion,
    certificate Certificate,
    attributes UnauthAttributes }
    
Signature ::= BIT STRING
    
END -- of CryptographicMessageSyntax2004

Module ASN.1 Certificat d'attribut version 1


AttributeCertificateVersion1
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
    
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
    
-- EXPORTS All
    
IMPORTS
    
    -- Imports from RFC 5280 [PROFILE], Appendix A.1
        AlgorithmIdentifier, Attribute, CertificateSerialNumber,
        Extensions, UniqueIdentifier
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }
    
    -- Imports from RFC 5280 [PROFILE], Appendix A.2
        GeneralNames
            FROM PKIX1Implicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-implicit(19) }
    
    -- Imports from RFC 3281 [ACPROFILE], Appendix B
        AttCertValidityPeriod, IssuerSerial
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) } ;
    
    -- Définition extraite de X.509-1997, mais des noms de type différents sont utilisés pour éviter les collisions
    
AttributeCertificateV1 ::= SEQUENCE {
    acInfo AttributeCertificateInfoV1,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING }
    
AttributeCertificateInfoV1 ::= SEQUENCE {
    version AttCertVersionV1 DEFAULT v1,
    subject CHOICE {
        baseCertificateID [0] IssuerSerial,
            -- associé avec un certificat à clé publique
        subjectName [1] GeneralNames },
            -- associé avec un nom
    issuer GeneralNames,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL }
    
AttCertVersionV1 ::= INTEGER { v1(0) }
    
END -- of AttributeCertificateVersion1

^
21 décembre 2014

htmlpdflatexmanmd




rfc5755

rfc5755

Profil de certificat d'attribut Internet pour l'autorisation

Introduction

   Les certificats à clé publique X.509 (PKCs) lien une identité et une clé publique. Un certificat d'attribut (AC) est une structure similaire à PKC; la principale différence est que AC ne contient pas de clé publique. Un AC peut contenir des attributs qui spécifie l'appartenance à un groupe, un rôle, habilitation, ou d'autres informations d'autorisation associés avec le titulaire de l'AC.

   La syntaxe pour AC est définie dans Recommendation X.509, rendant le terme "X.509 Certificate' ambigus.

   Certaines personnes confondent constamment PKCs et ACs. Un analogie peut rendre la distinction plus claire. An PKC peut être considéré comme un passeport: il identifie le titulaire, tend à durer longtemps, et ne devrait pas être trivial à obtenir. Un AC est plus comme un visa d'entrée: il est typiquement utilisé par une autorité différente et ne dure pas très longtemps.

   Les informations d'autorisation peuvent être placés dans une extension PKC ou placé dans un certificat d'attribut séparé. Le placement des informations d'autorisation dans les PKCs est généralement indésirable pour 2 raisons. D'abord, les informations d'autorisation n'ont pas la même durée de vie que la liaison de l'identité et de la clé publique. Ensuite, le fournisseur PKC n'a généralement pas autorité pour les informations d'autorisation.

   Pour ces raisons, il est souvent meilleur de séparer les informations d'autorisation des PKC. Les informations d'autorisation doivent également être liées a une identité. Un AC fournis cette liaison; c'est simplement une identité signé ou certifiée numériquement et un jeu d'attributs.

   Un AC peut être utilisé avec divers services de sécurité, incluant le contrôle d'accès, authentification de l'origine des données, et la non-répudiation.

   les PKCs peuvent fournir une identité à des fonctions de contrôle d'accès. Cependant, dans de nombreux contextes, l'identité n'est pas le critère qui est utilisé pour les décisions de contrôle d'accès, mais plutôt le rôle ou l'appartenance à un groupe. De tels schémas de contrôles d'accès sont appelé RBAC.

   En créant des décisions de contrôle d'accès basé sur un AC, une fonction de décision de contrôle d'accès peut nécessiter de s'assurer que le titulaire de l'AC approprié est l'entité qui a demandé l'accès. Une manière de lier la demande ou l'identité et l'AC peut être accomplie par l'inclusion d'une référence à un PKC dans l'AC et l'utilisation de la clé privée correspondante au PKC pour l'authentification dans la demande d'accès.

   Les AC peuvent également être utilisés dans le contexte de service d'authentification de l'origine des données et de non-répudiation. Dans ces contextes, les attributs contenus dans l'AC fournis des informations additionnels sur l'identité du signataire. Cet information peut être utilisée pour s'assurer que l'identité est autorisée à signer la donnée. Ce genre de vérification dépend soit du contexte dans lequel la donnée est échangée soit sur la donnée qui a été signée numériquement.

Délégation de chemin d'AC

   Le standard X.509 définis l'autorisation comme le "transport de privilège d'une entité qui détient ce privilège, à une autre identité.". Un AC est un mécanisme d'autorisation.

   Une séquence ordonnée d'AC pourrait être utilisée pour vérifier l'authenticité des privilège du déclarant. De cette manière, les chaînes et chemins d'AC pourraient être employés pour déléguer l'autorisation.

   Vu que l'administration est le traitement associé avec de telles chaînes AC est complexe et que l'utilisation des AC dans l'Internet aujourd'hui est limitée, il est recommandé que les implémentations de cette spécification n'utilisent pas les chaînes d'AC. D'autres futures spécifications peuvent adresser l'utilisation de chaînes d'AC. Cette spécification s'occupe de cas simples, où une autorité gère tous les AC pour un jeu d'attributs particuliers. Cependant, cette simplification n'exclus par l'utilisation de plusieurs autorités différentes, chacune d'entre elles gérant un jeu d'attributs différents. Par exemple, l'appartenance à un groupe peut être inclus dans un AC fournis par une autorité, et les habilitations de sécurité peuvent être inclus dans un autre AC par une autre autorité.

   Cela signifie que les implémentations conformes doivent seulement être capable de traiter un simple AC à la fois. Le traitement de plus d'un AC, un après l'autre, peut être nécessaire. Noter cependant, que la validation d'un AC peut nécessiter une validation d'une chaîne de PKCs.

Distribution de certificat d'attributs

   Comme discuté plus haut, les AC fournissent un mécanisme pour fournir de manière sécurisé des informations d'autorisation pour, par exemple, des fonctions de décision de contrôle. Cependant, il y a un nombre de chemins de communication possible pour les AC.

   Dans certains environnements, il est possible pour un client de "pousser" un AC à un serveur. Cela signifie qu'il n'y a pas de nouvelle connexion entre le client et le serveur. Ce la signifie également qu'aucune charge de recherche n'est imposée sur les serveurs, ce qui améliore les performances et le vérificateur d'AC est seulement présenté avec ce que l'on a besoin de connaître. Le modèle "push" est préférable spécialement dans les cas inter-domaines où les droits des client devraient être assignés dans le domaine du client.

   Dans d'autres cas, il est préférable pour un client de simplement s'authentifier auprès du serveur et de lui demander ( "pull" ) l'AC du client depuis un fournisseur d'AC. Un bénéfice majeur est du modèle "pull" est qu'il peut être implémenté sans changements sur le client ou dans le protocole. Le modèle "pull" est préférable spécialement pour les cas inter-domaines où les droits du client devraient être assignés dans le domaine du serveur.

   Il y a un certain nombre d'échanges possibles impliquant 3 entités: Le client, le serveur, et le fournisseur d'AC. En plus, un service d'annuaire ou d'autres annuaire pour la récupération d'AC peuvent être supportés.

La Figure 1 montre un vue abstraite des échanges qui peuvent se produire. Ce profile ne spécifie pas de protocole pour ces échanges:
______+--------------+__________________________________________
______|______________|________Server_Acquisition________________
______|__AC_issuer___+‹---------------------------+_____________
______|______________|____________________________|_____________
______+--+-----------+____________________________|_____________
_________^________________________________________|_____________
_________|_Client_________________________________|_____________
_________|_Acquisition____________________________|_____________
_________v________________________________________v_____________
______+--+-----------+_________________________+--+------------+
______|______________|_______AC_"push"_________|_______________|
______|___Client_____+‹------------------------|____Server_____|
______|______________|_(part_of_app._protocol)_|_______________|
______+--+-----------+_________________________+--+------------+
_________^________________________________________^_____________
_________|_Client_________________________________|_Server______
_________|_Lookup________+--------------+_________|_Lookup______
_________|_______________|______________|_________|_____________
_________+--------------›+__Repository__+‹--------+_____________
_________________________|______________|_______________________
_________________________+--------------+_______________________
_
____________________________Figure_1:_AC_Exchanges______________

Terminologie

   Par simplicité, on utilise les termes client et serveur dans cette spécification. Cela n'est pas prévu pour indiquer que les AC sont seulement utilisé dans des environnements client/serveur. Par exemple, les AC peuvent être utilisé dans un contexte S/MIME v3.2, où le MUA serait à la fois client et serveur dans le sens des termes utilisés ici.

AA Attribute Autority, l'entité qui fournis l'AC, synonyme dans cette spécification avec "fournisseur de CA"
AC Attribute Certificate
AC user Une entité qui parse ou traite un AC
AC verifier Une entité qui vérifie la validité d'un AC et utilise le résultat
AC issuer L'entité qui signe l'AC: synonyme de AA
Client L'entité qui demande l'action pour laquelle les vérifications d'autorisation doivent êtes faites
Proyxing Dans cette spécification, le proxying est utilisé pour signifier la situation où un serveur d'application agit comme application cliente à la demande de l'utilisateur.
PKC Public Key Certificates - utilise les certificats de type ASN.1 définis dans X.509 et profilé dans la rfc5280.
Server L'entité qui nécessite qu'une vérification d'autorisation soit faite.

Pré-requis

   Ce profile AC à les pré-requis suivants:

1. Support pour les AC à durée de vie courte et longue. Une période de validité courte typique peut se mesurer en heures, en mois pour les PKC. Les périodes de validité courtes permettent aux AC d'être utiles sans mécanisme de révocation.
2. Les fournisseurs d'AC devraient être capable de définir leur propres types d'attributs à utiliser dans les domaines fermés.
3. Certains types d'attributs standard, qui peuvent être contenus dans les AC devraient être définis. Par exemple "access identity", "group", "role", "clearance", "audit identity", et "charging identity".
4. Les type d'attributs standard devraient être définis d'une manière qui permette à un AC verifier de distinguer l'utilisation de mêmes attributs dans des domaines différents. Par exemple, "Administrators group" comme définis par "Baltimore" et "Administrators group" définis par "SPYRUS" devraient être facilement distincts.
5. Il devrait être possible de cibler un AC à un ou un petit nombre de serveurs. Cela signifie qu'un serveur non-ciblé sera rejeté par les décisions d'autorisation d'AC.
6. Les AC devaient être définis pour qu'il puissent être soit "pushed" par le client au serveur, ou "pulled" par le serveur depuis un dépôt ou un service réseaux, incluant un fournisseur d'AC online.

Profile de certificat d'attribut

   Les AC peuvent être utilisés dans un large éventail d'applications et d'environnements, couvrant un large spectre de besoins opérationnels et d'assurances. Le but de ce document est d'établir une base commune pour des applications génériques nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation de certificats d'attributs pour les messages électroniques, IPsec, et les applications www.

   Cette section présente un profile pour les AC qui va favoriser l'interopérabilité. Cette section définis également certaines extensions pour la communauté internet.

  Alors que les documents ISO/IEC/ITU utilisent la version 1993 (ou ultérieur) de ASN.1, ce document utilise la syntaxe ASN.1 1988, comme pour les PKCs.

Définition de certificat d'attribut X.509

X.509 contient la définition d'un AC donné ci-dessous. Tous les types qui ne sont pas définis dans ce document peuvent être trouvés dans la rfc 5280.
AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}
    
AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}
    
AttCertVersion ::= INTEGER { v2(1) }
    
Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- le issuer et serial number du titulaire du certificat à clé publique
    entityName [1] GeneralNames OPTIONAL,
        -- le nom du demandeur ou du rôle
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- Utilisé pour authentifier directement le titulaire, par exemple, un exécutable.
}
    
ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes ne doit pas être utilisé dans ce profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}
    
AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- ne doit pas être utilisé dans ce profile
    v2Form [0] V2Form -- v2 only
}
    
V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName doit être présent dans ce profile
        -- baseCertificateID et objectDigestInfo ne doivent pas être présents dans ce profile
}
    
IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}
    
AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}

Bien que la syntaxe d'attribut soit définis dans la rfc 5280, on répète la définition ici par commodité:
Attribute ::= SEQUENCE {
    type AttributeType,
    values SET OF AttributeValue
        -- Au moins une valeur est requise
}
    
AttributeType ::= OBJECT IDENTIFIER
    
AttributeValue ::= ANY DEFINED BY AttributeType

   Les implémenteurs devraient noter que l'encodage DER des valeurs de jeu nécessitent d'ordonner l'encodage des valeurs. Bien que cette question se pose avec les dn, et doit être géré avec l'implémentation rfc 5280, il est plus important dans ce contexte, vu que les valeurs multiples sont plus courantes dans les AC.

Profile des champs standards

   GeneralName offre une grande flexibilité. Pour parvenir à l'interopérabilité, en dépit de cette souplesse, ce profile impose des contraintes à l'utilisation de GeneralName.

   Les implémentations doivent être capable de supporter dNSName, directoryName, uniformResourceIdentifier, et iPAddress. C'est compatible avec les pre-requis de GeneralName dans la rfc 5280. Les implémentations doivraient également supporter SRVName, et ne doivent pas utiliser x400Address, ediPartyName et registeredID.

   Les implémentations peuvent utiliser otherName pour transmettre les formes de nom définis dans les standards Internet. Par exemple, le format kerberos des noms peut être encodé dans otherName, en utilisant l'OID du nom principal kerberos v5 et une séquence de domaine et du PrincipalName.

Version

   Le champ version doit avoir la valeur v2. Le champ version est présent dans l'encodage DER.

  Note: cette version n'est pas compatible avec les précédentes définition des certificats d'attribut du standard X.509-1997, mais est compatible avec la définition v2 X.509-2000.

Holder

   Le champ Holder est une séquence permettant 2 syntaxes optionnelles différentes: baseCertificateID, entityName, et objectDigestInfo. Où seul une option est présente, la signification du champ Holder est claire.

   Cependant, quand plus d'une option est utilisée, il y a une confusion possible, laquelle est normative, laquelle est une allusion, etc. Vu que la position correcte n'est pas claire dans X.509-2000, cette spécification recommande que seule une de ces options soit utilisée dans un AC donné.

   Pour tout environnement où l'AC est passée dans un message authentifié ou une session et où l'authentification est basée sur l'utilisation d'un PKC X.509, le champ Holder devrait être le baseCertificateID.

   Avec l'option baseCertificateID, le serialNumber et issuer du PKC du titulaire doit être identique au champ Holder de l'AC. Le fournisseur PKC doit avoir un dn non vide qui doit être présent comme simple valeure de la construction holder.baseCertificateID.issuer dans le champ directoryName. Le champ holder.baseCertificateID.issuerUID de l'AC doit seulement être utilisé si le PKC du titulaire contient un champ issuerUniqueID. Si le champs holder.baseCertificateID.issuerUID de l'AC et le champ issuerUniqueID du PKC sont présents, la même valeur doit être présente dans ces 2 champs. Donc, baseCertificateID est seulement utilisable avec les profiles PKC qui mandatent que le champ issuer du PKC contient une valeur dn non-vide.

   Note: un dn vide est un dn où la séquence de dn relatifs à une longueur de 0. Dans un encodage DER, il a la valeur '3000'H.

   Si le champ Holder utilise l'option entityName et que l'authentification sous-jacent est basée sur un PKC, entityName doit être le même que le champ subject du PKC ou une des valeurs de subjectAltName du PKC ( si présent ). Noter que la rfc 5280 mandate que l'extension subjectAltName soit présente si le sujet du PKC est un dn vide.

   Dans tous les cas où le champ Holder utilise l'option entityName, seul un nom devrait être présent.

   Les implémentations se conformant à ce profile ne sont pas obligés de supporter l'utilisation du champ objectDigest.

   Tout protocole se conformant à ce profile devrait spécifier quel option de titulaire de l'AC doit être utilisé et comment cela s'intègre avec les schémas d'authentification supportés définis dans ce protocole.

Issuer

   Les AC se conformant à ce profile doivent utiliser le choix v2Form, qui doit contenir un et un seul GeneralName dans le issuerName, qui doit contenir un dn non-vide dans le champ directoryName. Cela signifie que tous les fournisseurs d'AC doivent avoir des noms distincts non-vide. Les AC se conformant à ce profile doivent omettre les champs baseCertificateID et objectDigestInfo.

   Une des raisons d'utiliser v2Form contenant seulement un issuerName et que cela le fournisseur n'a pas à connaître quel PKC l'AC verifier va utiliser. Utiliser le champ baseCertificateID pour référencer le fournisseur d'AC signifie que l'AC verifier doit faire confiance au PKC que le fournisseur d'AC choisis pour lui à la création de l'AC.

Signature

   Contient l'identifiant d'algorithme utilisé pour valider la signature AC. Doit être un des algorithmes de signature définis dans les rfc3279, rfc4055, rfc5480, et rfc5756, ou définis dans une mise à jour approuvée par l'ietf de ces rfc. Les implémentations conformes doivent honorer toutes les déclarations MUST/SHOULD/MAY des algorithmes de signature.

SerialNumber

   Pour tout AC conforme, la paire issuer/serialNumber doit former une combinaison unique, même si les AC ont une durée de vie très courte. Les fournisseurs d'AC doivent s'assure que le serialNumber est un nombre positif, qui est, le bit de signe dans l'encodage DER de la valeur integer doit être 0. Cela peut être fait en ajoutant un '00'H gauche si nécessaire. Cela supprime une ambiguïté dans le mappage entre une chaîne d'octets et une valeur entière.

   En donnant un timing et une unicité requise, les numéros de série peuvent contenir des entiers longs. Les utilisateurs d'AC doivent être capable de manipuler les valeurs de serialNumber supérieurs à 4 octets. Les AC conformes ne doivent pas contenir de valeurs serialNumber supérieurs à 20 octets.

   Il n'y a pas de pré-requis pour que le numéro de série utilisé par un fournisseur d'AC suive un ordre particulier. En particulier, ils nécessitent de ne pas être incrémentés monotoniquement avec le temp. Chaque fournisseur d'AC doit s'assurer que chaque AC qu'il fournis contient un numéro de série unique.

Période de validité

   Le champ attrCertValidityPeriod spécifie la période pour laquelle le fournisseur d'AC certifie que le lien entre le titulaire et les champs d'attributs sont valides.

   Le type GeneralizedTime est un type ASN.1 standard pour représenter le temps. Ce champ peut optionnellement inclure une représentation du temps différentiel entre la zone de temps local et GMT.

   Pour ce profile, les valeurs GeneralizedTime doivent être exprimés en UTC et doivent inclure les secondes (ex: YYYYMMDDHHMMSSZ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

   Les utilisateurs d'AC doivent être capable de manipuler un AC que, au moment du traitement, a des parties de sa période de validité ou toute sa période de validité dans le passé ou dans le future. C'est valide pour certaines applications, tels que les backups.

Attributes

   Le champ attributes donne des informations sur le titulaire de l'AC. Quand l'AC est utilisé pour l'autorisation, il contient souvent un jeu de privilèges.

   Le champ attributes contient une séquence d'attributs. chaque attribut contient le type de l'attribut et un jeu de valeurs. Pour un AC donné, chaque identifiant d'object AttributeType dans la séquence doit être unique, mais peut être multi-valué.

   Les utilisateurs d'AC doivent être capable de manipuler plusieurs valeurs pour tous les types d'attributs. Un AC doit contenir au moins un attribut, c'est à dire une séquence d'Attributes de longueur non-zéro.

Issuer Unique Identifier

   Ce champ ne doit pas être utilisé à moins qu'il est également utilisé dans le PKC du fournisseur d'AC, auquel cas il doit être utilisé. Noter que la rfc5280 indique que ce champ ne devrait pas être utilisé par les autorités de certification conformes, mais ces applications devraient être capable de gérer les PKCs contenant ce champ.

Extensions

   Le champ extensions donne généralement des informations sur l'AC, en opposé aux informations sur le titulaire de l'AC.

   Un AC qui n'a pas d'extensions est conforme avec ce profile. Cependant les sections suivantes définissent des extensions qui peuvent être utilisé avec ce profile, et indique s'ils sont à marquer critiques. Si une autre extension critique est utilisé, l'AC n'est pas conforme à ce profile. Cependant, si une autre extension non-critique est utilisée, l'AC est conforme à ce profile.

   Les extensions définie pour les AC fournissent des méthodes pour associer les attributs additionnels avec les titulaires. Ce profile permet aux communautés de définir des extensions privées pour les informations unique à ces communautés. Chaque extension dans un AC peut être désigné comme critique ou non-critique. Un system utilisant les AC doit rejeter un AC s'il rencontre une extension critique qu'il ne reconnaît pas; cependant, une extension non-critique peut être ignorée s'il ne la reconnaît pas.

Audit Identity

   Dans certaines circonstances, il est requis ( par ex: protection des données ) que chemins d'audit ne contiennent pas d'enregistrement qui identifie directement les individus. Cette circonstance peut rendre le champ Holder inutilisable dans les chemins d'audit.

   Pour permettre de tels cas, un AC peut contenir une extension d'identité d'audit. Idéalement, il devrait être impossible de dériver l'identité du titulaire depuis la valeur de l'identité d'audit sans la coopération du fournisseur d'AC.

   La valeur de l'identité d'audit, avec le issuer/serial, devrait être utilisé dans un but d'audit/logging. Si la valeur de l'identité d'audit est bien choisis, un serveur/administrateur de service peut utiliser les traces d'audit pour tracer le comportement du titulaire de l'AC sans être capable d'identifier ce titulaire.

   Le serveur/administrateur de service en combinaison avec le fournisseur d'AC doit être capable d'identifier le titulaire de l'AC dans les cas où des problèmes sont détectés. Cela signifie que le fournisseur d'AC doit être capable de déterminer l'identité actuelle du titulaire de l'AC depuis l'identité d'audit.

   Bien évidemment, l'audit pourrait être basée sur la paire issuer/serial; cependant, cette méthode ne permet pas de tracer le même titulaire avec plusieurs AC. Donc, une identité d'audit n'est utile que si elle dure plus longtemps que la durée de vie typique d'un AC. L'audit pourrait également être basée sur le issuer/serial du PKC du titulaire de l'AC; cependant, cela permet souvent au serveur/administrateur de service d'identifier le titulaire de l'AC.

   Un AC verifier peut sinon utiliser holder ou d'autres valeur identifiant pour un but d'audit, cette extension doit être critique quand elle est utilisée.

   Les protocoles qui utilisent les AC vont souvent exposer l'identité du titulaire. Dans de tels cas, une identité d'audit opaque n'utilise pas d'AC anonyme; il s'assure simplement que les traces d'audit ne contiennent pas d'information d'identification.

La valeur d'une identité d'audit doit être plus longue que 0 octet. La valeur d'une identité d'audit ne doit pas être plus longue que 20 octets.
name id-pe-ac-auditIdentity
OID { id-pe 4 }
syntax OCTET STRING
criticality MUST be TRUE

AC Targeting

   Pour cibler un AC, l'extension d'information de cible, importé depuis X.509-2000, peut être utilisé pour spécifier un nombre de serveurs/services. Le but est que l'AC devrait seulement être utilisable sur les serveurs/services spécifiés. Un AC verifier ( honnête ) qui n'est pas parmi les serveurs/services nommés doit rejeter l'AC.

   Si cette extension n'est pas présente, l'AC n'est pas ciblée et peut être accepté par n'importe quel serveur. Dans ce profile, les informations de cible consiste simplement d'une liste de cibles nommés, ou de groupes.

La syntaxe suivante est utilisée pour représenter les informations de cible:
Targets ::= SEQUENCE OF Target
    
Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}
    
TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}

   Le choix targetCert dans la structure Target est seulement présente pour permettre de futures compatibilités avec X.509-2000 et ne doit pas être utilisé.

   Les vérifications de cible réussissent si le serveur courant ( le destinataire ) est un des champs targetName dans la séquence Targets, ou si le serveur courant est un membre d'un des champs targetGroup dans la sequence Targets. Dans ce cas, le serveur courant est dit "correspondre" à l'extension de ciblage.

   La manière de déterminer si la cible est dans un targetGroup n'est pas déterminés ici. Il est assumé que la cible donnée connaît les noms des targetGroups pour lequel il appartient ou peut déterminer ses membres. Par exemple, le targetGroup spécifie un domaine DNS, et l'AC verifier connaît le domaine DNS auquel il appartient. Pour un autre exemple, targetGroup spécifie "PRINTERS" et l'AC verifier sait s'il est ou non une imprimante ou un serveur d'impression.

   Note: X.509-2000 définis la syntaxe d'extension comme une séquence de target. Les implémentations de fournisseur d'AC conformes doivent seulement produire un élément Targets. Les utilisateurs d'AC doivent être capable d'accepter une sequence de Targets. Si plus d'un élément Targets est trouvé dans l'AC, l'extension doit être traitée comme si tous les éléments Target avaient été trouvés dans un élément Targets.


name id-ce-targetInformation
OID { id-ce 55 }
syntax SEQUENCE OF Targets
criticality MUST be TRUE

Authority Key Identifier

   L'extension authorityKeyIdentifier, comme profilé dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de la signature de l'AC. La description de la rfc 5280 devrait être lue comme si CA signifiait AC issuer. Comme avec les PKC, cette extension devrait être incluse dans les AC.

Note: Un AC, où le champ issuer utilisant le choix baseCertificateID, ne nécessite pas l'extension authorityKeyIdentifier, vu qu'il est explicitement lié à la clé dans le certificat référé. Cependant, l'AC doit utiliser la v2Form avec le choix issuerName, cette duplication ne se produit pas.
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE

Authority Information Access

   l'extension authorityInfoAccess, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de statut de révocation de l'AC. Le support pour id-ad-caIssuers accessMethod est optionnel par ce profile vu que les chaînes d'AC ne sont pas attendus.

L'accessMethod suivante est utilisée pour indiquer que la vérification de statut de révocation est fournie pour cet AC, en utilisant OCSP:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

accessLocation doit contenir une URI, et l'URI doit contenir une URL HTTP qui spécifie l'emplacement d'un répondeur OCSP. Le fournisseur d'AC doit, bien sûr, maintenir un répondeur OCSP à cet emplacement.
name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE

CRL Distribution Points

   l'extension crlDistributionPoints, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification du statut de révocation de l'AC.

Si l'extension crlDistributionPoints est présent, un seul point de distribution doit être présent. l'extension crlDistributionPoints doit utiliser l'option DistributionPointName, qui doit contenir un nom complet, qui doit contenir une forme nom simple. Ce nom doit contenir soit un nom distinct soit une URI. L'URI doit être soit une URL HTTP soit une URL LDAP.
name id-ce-cRLDistributionPoints
OID { id-ce 31 }
syntax CRLDistributionPoints
criticality MUST be FALSE

No Revocation Available

   L'extension noRevAvail, définis dans X.509-2000, permet à un fournisseur d'AC d'indiquer qu'aucune information de révocation n'est disponible pour cet AC.

Cette extension doit être non-critique. Un AC vérifier qui ne comprend par cette extension doit être capable de trouver une liste de révocation du fournisseur d'AC, mais la liste de révocation n'inclura jamais l'AC.
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e., '0500'H is the DER encoding)
criticality MUST be FALSE

Types d'attributs

   Certains attributs définis ci-dessous utilisent le type IetfAttrSyntax, également définis ci-dessous. Les raisons d'utiliser ce type sont:

1. Il permet une séparation entre le fournisseur d'AC et l'autorité de stratégie d'attributs. C'est utile pour les situations où une seule autorité de stratégie (par exemple une organisation) alloue des valeurs d'attributs, mais où plusieurs fournisseurs d'AC sont déployés pour les raisons de performances, ou autre.
2. Les syntaxes permises pour les valeurs sont restreintes à des chaînes d'octets, identifiant d'objet, et UTF8String, qui réduit significativement la complexité associée avec les syntaxes plus générales. Tous les attributs multi-valués utilisant cette syntaxe sont restreints pour que chaque valeur utilise le même choix de syntaxe de valeur. Par exemple, le fournisseur d'AC ne doit pas utiliser une valeur avec un oid et une autre valeur avec une chaîne.


IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}

   Dans la description ci-dessous, chaque type d'attribut est soit marqué "Multiple Allowed" ou "One Attribute value only; multiple values within the IetfAttrSyntax". Cela réfère au jeu d'AttributeValues; le AttributeType ne se produit qu'une seul fois.

Service Authentication Information

   L'attribut SvceAuthInfo identifie le titulaire de l'AC au serveur/service par un nom, et l'attribut peut inclure des information optionnelles d'authentification spécifiques au service. Typiquement, il contient une paire nom/mot de passe.

   Cet attribut fournis des informations qui peuvent être présentés par l'AC verifier pour être interprété et authentifié par une application séparée dans le système cible. Noter que c'est une utilisation différente de ce qui est prévu pour l'attribut accessIdentity.

Ce type d'attribut est typiquement chiffré quand le champ authInfo contient des information sensibles, tel qu'un mot de passe.
name id-aca-authenticationInfo
OID { id-aca 1 }
syntax SvceAuthInfo
values Multiple allowed
    
SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}

Access Identity

   L'attribut accessIdentity identifie le fournisseur d'AC au serveur/service. Pour cet attribut le champ authInfo ne doit pas être présent.

Cet attribut est prévu pour fournir des informations sur le titulaire d'AC, qui peut être utilisé par l'AC verifier ( ou un grand système dans lequel l'AC verifier est un composant ) pour autoriser les actions du titulaire dans le système de l'AC verifier. Noter que c'est une utilisation différente que l'attribut svceAuthInfo.
name id-aca-accessIdentity
OID { id-aca 2 }
syntax SvceAuthInfo
values Multiple allowed

Charging Identity

L'attribute chargingIdentity identifie le titulaire de l'AC dans un but de charge. En général, l'identité de charge sera différent des autres identités du titulaire. Par exemple, la compagnie du titulaire peut être chargé pour un service.
name id-aca-chargingIdentity
OID { id-aca 3 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Group

L'attribut group gère les informations d'appartenance du titulaire à des groupes.
name id-aca-group
OID { id-aca 4 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Role

L'attribut role, spécifié dans X.509-2000, gère les informations sur l'allocation de rôle du titulaire de l'AC. La syntaxe utilisée pour cet attribut est:
RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}

   Le champ roleAuthority peut être utilisé pour spécifier l'autorité de délivrance de certificat de spécification de rôle. Il n'y a pas de pré-requis pour qu'un certificat de spécification de rôle existe nécessairement pour le roleAuthority. Cela diffère de X.500-2000, où le champ roleAuthority est assumé au nom du fournisseur du certificat de spécification de rôle. Par exemple, pour distinguer le rôle administrateur comme définis par Baltimore de ce qui est définis par SPYRUS, on pourrait placer la valeur "urn:administrator" dans le champ roleName et la valeur "Baltimore" ou "SPYRUS" dans le champ roleAuthority.

Le champ roleName doit être présent, et roleName doit utiliser le choix uniformResourceIdentifier de GeneralName:
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values Multiple allowed

Clearance

   L'attribut clearance, spécifié dans X.501-1993, gère les informations de clairance ( associé avec les labels de sécurité ).

   Le champ policyId est utilisé pour identifier la stratégie de sécurité pour lequel la clairance est liée. policyId indique les sémantiques des champs classList et securityCategories.

   Cette spécification inclus le champ classList exactement comme spécifié dans X.501-1993. Des valeurs additionnelles de classification de sécurité, et leur position dans la hiérarchie de classification, peuvent être définis par une stratégie de sécurité au niveau local ou par accord bilatéral. La hiérarchie de classification de sécurité de base est, dans l'ordre ascendant: unmarked, unclassified, restricted, confidential, secret, et top-secret.

   Une organisation peut développer ses propres stratégies de sécurité qui définissent les valeurs de classification de sécurité et leur signification. Cependant, les positions 0 à 5 de la chaîne de bits sont réservés pour la hiérarchie de classification de sécurité de base.

   Si présent, le champ securityCategory fournis d'autres information d'autorisation. La stratégie de sécurité identifié par le champ policyId indique les syntaxes qui sont permises dans le jeu securityCategories. Un identifiant d'objet identifie chaque syntaxe permise. Quand une de ces syntaxe est présente dans le jeu securityCategories, l'identifiant d'objet associé avec cette syntaxe est réalisé dans le champ securityCategory.type.

L'identifiant d'objet pour l'attribut clearance de la rfc3281 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
    clearance (55) }

La syntaxe a été corrigée depuis la rfc3281, pour restaurer la conformité avec X.509-1997:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

L'identifiant d'objet pour l'attribut clearance de X.509-1997 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }

La syntaxe associée est la suivante:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

Les implémentations doivent supporter l'attribut clearance comme définis dans X.501-1997. Les implémentations devraient supporter le décodage de la syntaxe clearance de la rfc3281. Les implémentations ne doivent pas générer d'attribut clearance comme définis dans la rfc3281.
ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}
    
SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4) clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed

Profile du PKC du AC Issuer

   Le PKC du fournisseur doit être conforme à la rfc5280, et l'extension keyUsage dans le PKC ne doit pas explicitement indiquer que la clé publique du fournisseur d'AC ne peut pas être utilisée pour valider une signature numérique. Pour éviter toute confusion dans les numéros de série et les révocations, un fournisseur d'AC ne doit pas être en même temps un PKC Issuer. Donc le PKC du fournisseur d'AC ne doit pas avoir une extension basicConstraints avec cA à TRUE.

Validation de certificat d'attribut

   Cette section décrit un jeu de règles de base que tout AC valide doit satisfaire. Certaines vérifications additionnelles sont également décrites, que l'AC verifier peut choisir d'implémenter. Pour être valide, un AC doit satisfaire tous les points suivant:

1. Là où le titulaire utilise un PKC pour s'authentifier auprès de l'AC verifier, le PKC du titulaire de l'AC doit être trouvé, et tout le chemin de certification de ce PKC doit être vérifié en accord avec la rfc5280. Comme mentionné dans la section Considération de Sécurité, si un autre schémas de sécurité est utilisé, les AC verifier doivent être très attentifs au mappage des identités.
2. La signature de l'AC doit être cryptographiquement correcte, et tout le chemin de certification du PKC du fournisseur d'AC doit être vérifié en accord avec la rfc5280.
3. Le PKC du fournisseur d'AC doit également être conforme au profile spécifié dans la section précédente.
4. Le fournisseur d'AC doit être directement considéré comme un fournisseur d'AC.
5. Le temps pour lequel l'AC est évalué doit être dans la validité de l'AC. Si l'évaluation est égal à soit notBeforeTime soit notAfterTime, la vérification réussit. Noter que dans certaines applications, l'évaluation du temps peut ne pas être la même que l'heure courante.
6. La vérification de l'AC targeting doit passe comme spécifié dans la section AC Targeting.
7. Si l'AC contient une extension critique non-supportée, l'AC doit être rejetée.

   Le support pour une extension dans ce contexte signifie:

1. L'AC verifier doit être capable de lire la valeur de l'extension
2. Là où la valeur de l'extension implique de rejeter l'AC, l'AC verifier doit rejeter l'AC.

   Vérifications additionnelles:

1. L'AC peut être rejetée sur la base d'une configuration de l'AC verifier. Par exemple, un AC verifier peut être configuré pour rejeter les AC qui contiennent ou qui n'ont pas certains attributs.
2. Si l'AC verifier fournis une interface qui permet aux applications de requêter le contenu de l'AC, alors l'AC verifier peut filtrer les atributs de l'AC en fonction de sa configuration. Par exemple, un AC verifier pourrait être configuré pour ne pas retourner certains attributs pour certains serveurs.

Révocation

   Dans de nombreux environnements, la période de validité d'un AC est inférieure au temps requis pour fournir et distribuer les informations de révocation. Les AC à durée de vie courte ne nécessitent pas de support de révocation. Cependant, les AC à durée de vie longue et les environnements où les AC permettent les transaction à forte valeur, le support de la révocation peut être requise.

   2 schémas de révocation sont définis, et le fournisseur d'AC devrait élire celui qui est le plus adapté à l'environnement dans lequel l'AC sera employé.

Schéma "Never revoke": Les AC peuvent être marqués pour que les parties comprennent qu'aucune information de statut de révocation ne sera rendu disponible. L'extension NoRevAvail doit être présent dans l'AC pour indiquer l'utilisation de ce schéma. Si cette extension n'est pas présente, le fournisseur d'AC statut qu'une vérification du statut de révocation est suppportée, et certaines méthodes de révocation doivent être fournis pour permettre aux AC verifiers d'établir le statut de révocation de l'AC.
Schéma "Pointer in AC": Les AC peuvent "pointer" sur la source d'information de statut de révocation, en utilisant soit l'extension authorityInfoAccess ou l'extension crlDistributionPoints dans l'AC.

   Pour les utilisateurs d'AC, le schéma "never revoke" doit être supporté, et le "pointer in AC" devrait être supporté. Si seul le premier est supporté, tous les AC qui ne contiennent pas l'extension noRevAvail doivent être rejetés.

   Un AC ne doit pas contenir à la fois l'extension noRevAvail et un "pointer in AC".

  Un AC verifier peut utiliser toute information de statut de révocation de l'AC.

Fonctionnalités optionnelles

   Cette section spécifie les fonctionnalités qui peuvent être implémentées. La conformité avec ce profile n'impose pas de supporter ces fonctionnalités; cependant, si ces fonctionnalités sont supportées, elles doivent le faire tel que décris ici.

Chiffrement d'attribut

   Les attributs d'AC peuvent nécessiter d'être chiffrés si l'AC est transporté dans le protocole d'application en clair ou contient des informations sensibles ( par ex: username/password ).

   Quand un jeu d'attributs doit être chiffré dans un AC, le CMS EnvelopedData est utilisé pour transporter le texte chiffré et les informations par destinataire associés.

   Ce type de chiffrement d'attribut est ciblé. Avant que l'AC soit signé, les attributs sont chiffrés pour un jeu de destinataires prédéterminés.

Dans l'EnvelopedData, encapsulatedContentInfo identifie le type de contenu transporté dans le texte chiffré. Dans ce cas, le champ contentType de encapsulatedContentInfo doit contenir id-ct-attrCertEncAttrs, qui a la valeur suivante:
attrCertEncAttrs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-ct(1) 14 }

   Le texte chiffré est inclus dans l'AC comme valeur d'un attribut encAttrs. Seul un attribut encAttrs peut être présent dans un AC; cependant, l'attribut encAttrs peut être multi-valué, et chacune de ses valeurs contient un EnvelopedData indépendant.

   Chaque valeur peut contenir un jeu d'attributs ( chaque pouvant être multi-valué ) chiffré pour un jeu de déstinataires prédéterminés.

Le texte en clair qui est chiffré a le type:
ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}

   L'encodé DER de la structure ACClearAttrs est utilisée comme champ encryptedContent de EnvelopedData. L'encodé DER doit être embarqué dans une chaîne d'octets.

   Les champs acIssuer et acSerial sont présents pour empêcher le vol du texte chiffré. Quand un AC verifier a déchiffré un attribut chiffré avec succès, il doit ensuite vérifier que les champs acIssuer et acSerial contiennent les même valeur. Cela empêche un fournisseur d'AC malicieux de copier le texte chiffré d'un autre AC.

   La procédure pour un fournisseur d'accès pour chiffrer des attributs est illustré par les étapes suivantes ( tout autre procédure qui donne le même résultat peut être utilisé ):

1. Identifier les jeux d'attributs qui doivent être chiffrés pour chaque jeu de destinataires.
2. Pour chaque jeu d'attribut qui doit être chiffré:

        2.1. Créer une structure EnvelopedData pour les données pour ce jeu de destinataires
        2.2. Encoder ContentInfo contenant le EnvelopedData comme valeur de l'attribut encAttrs
        2.3. S'Assurer que les attributs en texte clair ne sont pas présents dans l'AC à signer

3. Ajouter encAtrs ( avec ses multiples valeurs ) à l'AC.

   Noter qu'il peut y avoir plus d'un attribut de même type ( le même identifiant d'objet ) après de déchiffrement. C'est à dire, un AC peut contenir le même type d'attribut à la fois en clair et chiffré ( et de nombreuses fois si différents destinataires sont associés avec plus d'un EnvelopedData ). Par exemple, un AC pourrait contenir un attribut clearance en texte claire indiquant que le titulaire est autorisé à SECRET, et , en plus, un attribut clearance chiffré dont la valeur est une clairance supérieure qui ne doit pas être connus par tout le monde. Une approche peut choisir de fusionner les valeurs d'attributs après déchiffrement pour rétablir la contrainte "once only".


name id-aca-encAttrs
OID { id-aca 6}
syntax ContentInfo
values Multiple Allowed

   Si un AC contient des attributs apparemment chiffrés pour l'AC verifier, un échec du processus de déchiffrement doit impliquer le rejet de l'AC.

Proxying

   Quand un serveur agit comme un client pour un autre serveur de la part du titulaire, le serveur peut nécessiter proxyfier un AC. Un tel proxy peut être fait sous le contrôle du fournisseur d'AC, pour que tous les AC ne soient pas proxyfiables et qu'un AC proxyfié puisse l'être de façon ciblée. Le support pour les chaînes de proxy ( avec plus d'un serveur intermédiaire ) peut également être requis. Noter que cela n'implique pas une chaîne d'AC.

   Pour ce pré-requis, on définis une autre extension, ProxyInfo, similaire à l'extension targeting.

   Quand cette extension est présente, l'AC verifier doit vérifier que l'entité depuis lequel l'AC a été reçus était autorisé à l'envoyer et que l'AC est autorisé à être utilisé par l'AC verifier.

   Les informations de proxying est une liste dans laquelle chaque élément est une liste d'informations de ciblage. Si le verifieur et l'émetteur de l'AC sont nommés dans la même liste de proxy, l'AC peut alors être accepté ( la règle exacte est donnée plus bas ).

   L'effet est que le titulaire de l'AC peut envoyer l'AC à une cible valide qui peut ainsi seulement proxyfier aux cibles qui sont dans une des même listes que lui.

La structure de donnée suivante est utilisée pour représenter les information de targeting/proxying:
ProxyInfo ::= SEQUENCE OF Targets

   Les Targets sont expliqués dans la section AC Targeting. Comme dans le cas du targeting, le choix targetCert ne doit pas être utilisé.

   Une vérification de proxy réussie si une des conditions suivantes est rencontrée:

1. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond au champ Holder de l'AC, et le serveur courant correspond à un nom dans les jeux proxy.
2. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond à un des jeux proxy ( appelons le jeu A ), et le serveur courant est un des champs targetName dans le jeu A, ou le serveur courant est un membre d'un des champs targetGroup dans le jeu A.

   Quand un AC est proxyfié plus d'une fois, un nombre de cibles seront sur le chemin du client original, qui est normalement, mais pas toujours, le titulaire de l'AC. Dans de tels cas, la prévention du vol d'AC nécessite que l'AC verifier vérifie toujours que toutes les cibles dans le chemin sont dans le jeu proxy. Il est de la responsabilité du protocole utilisant d'AC de s'assurer qu'une liste de cibles de confiance dans le chemin soit disponible à l'AC verifier.


name id-pe-ac-proxying
OID { id-pe 10 }
syntax ProxyInfo
criticality MUST be TRU

Utilisation de ObjectDigestInfo

   Dans certains environnements, il peut être requis que l'AC ne soit pas lié soit à une identité ( via entityName ) ou à un PKC ( via baseCertificateID ). Le choix objectDigestInfo dans le champ Holder permet de le gérer.

   Si le titulaire est identifié avec le champ objectDigestInfo, alors le champ version de l'AC doit contenir v2 ( l'entier 1 ).

   L'idée est de lier l'AC à un objet en plaçant un hash de cet objet dans le champ Holder de l'AC. Par exemple, cela permet la production d'AC qui sont liés aux clés publiques au lieu de leur noms. Cela permet également la production d'AC qui contiennent des privilèges associés avec un objet exécutable telle qu'une classe java au travers d'une clé publique ou un PKC. Les AC conformes ne doivent pas utiliser de valeur otherObjectTypes pour le digestedObjectType.

   Pour lier un AC à une clé publique, le hash doit être calculé sur la présentation de cette clé publique, qui pourrait être présente dans un PKC, spécifiquement, l'entrée pour l'algorithme de hash doit être l'encodé DER d'une représentation SubjectPublicKeyInfo de la clé.

   Note: cela inclus l'AlgorithmIdentifier aussi bien que la chaîne de bit. Les règles donnée dans les algorithmes PKIX ( rfc3279, rfc4055, rfc5480, et rfc5756 ) pour encoder les clés doivent être suivies. Dans ce cas, le digestedObjectType doit être publicKey et le champ otherObjectTypeID ne doit pas être présent.

   Noter que si la valeur de la clé publique utilisé en entrée de la fonction de hashage a été extraite d'un PKC, il est possible que le SubjectPublicKeyInfo de ce PKC ne soit pas la valeur qui devrait être hashé. Cela peut se produire si les Dss-parms de DSA sont hérités comme décris dans la section 2.3.2 de la rfc3279. L'entrée correcte pour le hashage dans ce contexte inclus la valeur des paramètres hérités du PKC de la CA, et donc peut différer du SubjectPublicKeyInfo présent dans le PKC.

   Les implémentations qui supportent cette fonctionnalité doivent être capable de gérer les représentations de clé publique pour les algorithmes spécifiés dans la section 2.3 de la rfc3279.

   Pour lier un AC à un PKC via un hash, le hash doit être calculé sur l'encodé DER de tout le PKC, incluant la valeur de signature. Dans ce cas, digestedObjectType doit être publicKeyCert et otherObjectTypeID ne doit pas être présent.

Contrôles AA

Durant la validation d'AC, un partie de confiance doit répondre à la question: est-ce que ce fournisseur d'AC est valide pour fournir des ACs avec cet attribut? L'extension AAControls est prévu pour être utilisé dans les CA et les fournisseurs d'AC
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
    
AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}
    
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

   L'extension AAControls est utilisé comme suit:

PathLenConstraint si présent,, est interprété comme dans la rfc5280. Il restreint la distance permise entre le AA CA ( une CA directement validé pour inclure les AAControls dans ses PKCs), et le fournisseur d'AC.
permittedAttrs spécifie une liste de types d'attributs que tout fournisseur d'AC sous ce AA CA est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement permis.
excludedAttrs spécifie une liste de types d'attributs qu'aucun fournisseur d'AC sous ce AA CA n'est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement interdis.
permitUnSpecified spécifie comment manipuler les types d'attributs qui ne sont pas présents dans les champs permittedAttrs ou excludedAttrs. TRUE ( par défaut ) signifie qu'un type d'attribut non-spécifié est autorisé dans les AC, et FALSE, qu'il ne l'est pas.
- Quand AAControls est utilisé, les vérifications additionnelles suivantes sur la chaîne de PKC d'AA doit tous réussir pour que l'AC soit valide:

        1. Certaines CA dans le chemin de certification de l'AC doivent être directement trustés pour fournir des PKCs qui précède le fournisseur d'AC dans le chemin de certification; appelons cette CA le "AA CA".
        2. Tous les PKC dans le chemin depuis le AA CA, incluant le PKC du fournisseur d'AC, doivent contenir l'extension AAControls; cependant, le PKC du AA CA n'a pas besoin de contenir cette extension.
        3. Seul les attributs dans l'AC qui sont permis, en accord avec toutes les valeurs d'extension AAControls dans tous les PKC depuis le AA CA jusqu'au fournisseur d'AC, peuvent être utilisé pour les décisions d'autorisation; tous les autres attributs doivent être ignorés. Cette vérification doit être appliquée à la liste des attributs suivant le déchiffrement d'attributs, et le type id-aca-encAtrs doit être également vérifié.


name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE

Considérations de sécurité

   La protection offerte pour les clés privées est un facteur critique pour maintenir la sécurité. Si les fournisseurs d'AC ne parviennent pas à protéger leur clé privée, un attaquant pour les utiliser, potentiellement pour générer de faux AC ou statut de révocation. Si le système est compromis, tous les AC fournis par le fournisseur d'AC doivent être révoqués. La reconstruction sera problématique, donc les fournisseurs d'AC doivent implémenter une combinaison de techniques fortes ( ex: modules cryptographique inviolable ) et de procédures de gestion appropriés ( ex: séparation des fonctions ) pour éviter un tel incident.

   La perte d'une clé privée d'un fournisseur d'AC peut également être problématique. Le fournisseur d'AC ne sera plus capable de produire de status de révocation ou de renouvellement d'AC. Les fournisseur d'AC doivent maintenir une sauvegarde sécurisée de leur clé de signatue. La sécurité des procédures de sauvegarde de clé est un facteur critique.

   La disponibilité et la "fraîcheur" du status de révocation va affecter le degré d'assurance qui serai placé dans un AC long terme. Bien que les AC long-terme expirent naturellement, des évènements peuvent se produire durant sa durée de vie. Si le status de révocation est non-timé ou non-disponible, l'assurance associée avec le lien entre le titulaire de l'AC et les attributs est clairement réduit.

   La liaison entrée un titulaire d'AC et les attributs ne peut pas être plus forte que l'implémentation cryptographique et les algorithmes utilisé pour générer la signature. Des clé courtes ou des algorithmes faibles limitent l'utilité d'un AC.

   Les applications qui sont inconsistant lors de la comparaison des noms peut engendrer l'acceptation de cibles ou proxy invalides, ou le rejet de certains valides. Les séries X.500 de spécifications définissent des règles pour comparer les noms distincts. Ces règles nécessitent la comparaison de chaînes sans regarder la casse, le jeu de caractères, les espace blancs multi-caractères, ou les espaces blanc de début et de fin. Cette spécification relaxe ces pré-requis, nécessitant une comparaison binaire au minimum.

   Les fournisseurs d'AC doivent encoder le nom distinct dans le champ holder.entityName de l'AC identiquement au nom distinct dans le PKC du titulaire. Si des encodages différents sont utilisé, les implémentations de cette spécifiaciton peuvent échouer dans la reconnaissance de l'AC et du PKC appartenant à la même entité.

   Si un certificat d'attribut est lié au PKC du titulaire un utilisant le composant baseCertificateID du champ Holder et la PKI utilisée inclue un faux CA avec le même nom de fournisseur spécifié dans le composant baseCertificateID, ce faux CA pourrait fournir un PKC à un paire malicieux, en utilisant le même nom de fournisseur et numéro de série que le PKC du titulaire. Ainsi, le paire malicieux pourrait utiliser ce PKC en conjonction avec l'AC. Ce scénario devrait être évité en gérant et en configurant proprement la PKI pour qu'il ne puisse pas y avoir 2 CA avec le même nom.

   Une autre alternative est de lier les AC aux PKC en utilisant le type publicKeyCert dans le champ ObjectDigestInfo. Les AC verifier doivent établir ( en utilisant d'autres moyens ) que les collisions potentiels ne peuvent pas se produire, par exemple, le Certificate Practice Statements (CPSs) des CA impliqués peuvent préciser qu'une collision de nom ne puisse se produire.

   Les implémenteurs doivent s'assurer qu'en suivant la validation d'un AC, seuls les attributs dont le fournisseur est autorisé à fournir sont utilisés dans les décisions d'autorisation. Les autres attributs, qui peuvent être présents doivent être ignorés. L'extension PKC AAControls est optionnel, et les informations de configuration peuvent être une alternative. Cela devient très important si un AC verifier trust plus d'un fournisseur d'AC.

   Il est souvent requis de mapper l'authentification fournie par un protocole de sécurité particulier ( ex: TLS, S/MIME ) et l'identité du titulaire de l'AC. Si l'authentification utilise les PKC, alors le mapping est simple. Cependant, il est envisagé que les AC sont également utilisés dans des environnement où le titulaire peut être authentifié en utilisant d'autres moyens. Les implémenteurs devraient prendre en charge le mapping d'identité d'authentification qui ne proviennent pas de certificats à clé publique.

Appendix A - Object Identifiers

   Cet appendix liste les nouveaux identifiant d'objet qui sont définis dans cette spécification. Certains sont requis uniquement pour le support de fonctionnalités optionnels et ne sont pas obligatoire pour se conformer à ce profile.

Les OID suivant sont importés depuis les rfc de profile PKIX:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Le nouvel OID de mode ASN.1 suivant est définis:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }

Les OID d'extension d'AC suivant sont définis:
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }

Les OID d'extension PKC suivants sont définis:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

Les OID d'attributs suivant sont définis:
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) clearance (55) }

Appendix B - Module ASN.1

Cet appendix décrit les objects utilisé par les composant de PKI conformes dans une syntaxe ASN.1-like, un hybrid des syntaxe 1988 et 1993 d'ASN.1.
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-attribute-cert-v2(61) }
    
DEFINITIONS IMPLICIT TAGS ::=
    
BEGIN
    
-- EXPORTS ALL --
    
IMPORTS
    
-- Les OID des modules IMPORTés peuvent changer si les rfc de profile PKIX changent les extensions de certificat PKIX.
    
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
    FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-explicit-88(18) }

GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
    AuthorityInfoAccessSyntax, CRLDistributionPoint
        FROM PKIX1Implicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-implicit-88(19) }
    
ContentInfo
    FROM CryptographicMessageSyntax2004
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
            smime(16) modules(0) cms-2004(24) }
    
;
    
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
    
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
    
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
    
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
    
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
    
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
    
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
    
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
    
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
    
-- { id-aca 5 } is reserved
    
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
    
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
    
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
    
-- Décommenter la déclaration suivante et commenter la ligne au dessus pour utiliser
-- l'attribut id-at-clearance comme définis dans la rfc3281.
    
-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }
    
-- Uncomment this if using a 1988 level ASN.1 compiler
    
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
    
AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}
    
AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}
    
AttCertVersion ::= INTEGER { v2(1) }
    
Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- the issuer and serial number of
        -- the holder's Public Key Certificate
    entityName [1] GeneralNames OPTIONAL,
        -- the name of the claimant or role
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- used to directly authenticate the
        -- holder, for example, an executable
}
    
ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes MUST NOT
    -- MUST NOT be used in this profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}
    
AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- MUST NOT be used in this profile
    v2Form [0] V2Form -- v2 only
}
    
V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName MUST be present in this profile
        -- baseCertificateID and objectDigestInfo MUST
        -- NOT be present in this profile
}
    
IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}
    
AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}
    
Targets ::= SEQUENCE OF Target
    
Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}
    
TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}
    
IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}
    
SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}
    
RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}
    
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}
    
-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.
    
-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- }
    
ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}
    
SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}
    
-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.
    
AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}
    
AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
    
ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}
    
ProxyInfo ::= SEQUENCE OF Targets
    
END
^
27 octobre 2013

htmlpdflatexmanmd




rfc5803

rfc5803

Schéma LDAP pour stocker les secrets SCRAM

   Ce mémo décris comment l'attribut LDAP authPassword peut être utilisé pour stocker des secrets utilisés par le mécanisme SCRAM dans SASL. La partie "scheme" de authPassword est le nom du mécanisme SCRAM. La partie "authInfo" est le compteur d'itération suivi par un ":" et un salt encodé base64. La partie "authValue" est la clé encodée en base64, suivi par ":" et la clé serveur encodé en base 64. La syntaxe de l'attribut peut être:


scram-mech = "SCRAM-SHA-1" / scram-mech-ext
scram-authInfo = iter-count ":" salt
scram-authValue = stored-key ":" server-key
iter-count = %x31-39 *DIGIT
salt = ‹base64-encoded value›
stored-key = ‹base64-encoded value›
server-key = ‹base64-encoded value›
scram-mech-ext = "SCRAM-" 1*9mech-char
mech-char = ‹Defined in RFC 4422›

   Noter que authPassword est multivalué

^
06 novembre 2013

htmlpdflatexmanmd




rfc5805

rfc5805

Transactions LDAP

   Les opérations de modifications LDAP tels que Add, Delete et Modify ont des propriétés ACID (Atomic, Consistency, Isolation, Durability). Chacune des ces modifications agissent sur une seule entrée à la fois. Il est souvent désirable de modifier plusieurs entrées en une seule unité d'intéraction, une transaction. Les transactions sont nécessaires pour supporter certaines applications, tel que le provisionning. Cette extension consiste de 2 opérations étendue, un contrôle, et une notification non-sollicitée. l'opération Start Transaction est utilisé pour obtenir un identifiant de transaction.

Requête et réponse Start Transaction

   Une requête Start Transaction est un LDAPMessage de CHOICE extendedReqrequestName est 1.3.6.1.1.21.1 et requestValue est absent.

  Une réponse Start Transaction est un LDAPMessage de CHOICE extendedRes envoyé en réponse à une requête Start Transaction avec responseName absent.

Contrôle Transaction Specification

   C'est un LDAPControl où controlType est 1.3.6.1.1.21.2, la criticité à TRUE, et controlValue est un ID de transaction. Ce contrôle est approprié pour les requêtes de modification tels que Add, Delete, Modify, ModifyDN et Password Modify.

Requête et réponse End Transaction

Une requête End Transaction est un LDAPMessage de CHOICE extendedReq où requestName est 1.3.6.1.1.21.3 et requestValue contient un txnEndReq encodé BER:
txnEndReq ::= SEQUENCE {
    commit BOOLEAN DEFAULT TRUE,
    identifier OCTET STRING }

   commit à TRUE, indiwue une requête pour envoyer la transaction identifiée par identifier. à FALSE indique une requête d'abandon de la transaction identifiée.

Une réponse End Transaction est un LDAPMessage envoyé en réponse à un requête End Transaction. Le nom de réponse est absent. responseValue si présent, contient un txEndRes encodé BER:
txnEndRes ::= SEQUENCE {
    messageID MessageID OPTIONAL,
    — msgid associated with non-success resultCode
    updatesControls SEQUENCE OF updateControls SEQUENCE {
    messageID MessageID,
    — msgid associated with controls
    controls Controls
    } OPTIONAL
}

   MessageID fournis l'id de message de la requête de mise à jours associée avec une réponse autre que success. messageID est absent quand un resulCode est success. updatesControls fournis une facilité pour retourner les contrôles de réponse qui normalement (en l'absence de transactions) seraient retournés dans une réponse de mise à jours.

Transaction annulée

   Le Aborted Transaction Notice est un message de notification non-sollicité où responseName est 1.3.6.1.1.21.4 et responseValue est présent et contient un id de transaction.

Découverte d'extension

   Les serveurs implémentant cette spécification devraient publier 1.3.6.1.1.21.1 et 1.3.6.1.1.21.3 dans supportedExtension et 1.3.6.1.1.21.2 dans supportedControl

Démarrer une transaction

   Un client qui souhaite effectuer une séquence de modifications dans l'annuaire envoie une requête Start Transaction. Le serveur envoie une réponse Start Transaction avec un ID de transaction et un resultCode success.

Spécifications d'une transaction

   Le client peut fournir une ou plusieurs requêtes de modifications, chacune avec un contrôle Transaction Specification contenant l'ID de transaction indiquant les modifications à traiter. Chacune de ces requêtes doivent avoir une valeur messageID différente. Si le serveur ne peut pas traiter l'opération demandée, il retourne immédiatement le resultCode adéquat, sinon il retourne success. Si le serveur ne peut plus continue la transaction, il fournis un Aborted Transaction Notice avec un resultCode adéquat.

Règlement de transaction

   Un client demande le règlement de la transaction en fournissant une requête End Transaction, indiquant son désire que la transaction soit traitée ou annulée.

  Une fois reçu une annulation de transaction, le serveur annule l'ID de transaction et abandonne toutes les opérations de la transaction.

  Une fois reçu une fin de transaction, le serveur traite toutes les opérations de la transaction. Le serveur retourne une réponse End Transaction avec resultCode à success et sans responseValue pour indiquer que toutes les modifications ont été appliquées. Sinon, le serveur retourne un resultCode adéquat. Si l'échec est associé avec un requête particulière, le txnEndRes.messageID dans responseValue est l'id de message de cette demande de modification. Si l'échec n'est pas associé à une requête de modification, aucun messageID n'est retourné.

Divers problèmes

   Les transactions ne peuvent pas être imbriquées. Chaque transaction doit être initiée, spécifiée et terminé avec un contexte de sécurité stable.

Intéraction avec d'autres extensions

Contrôle d'assertion Le contrôle Assertion est approprié pour les requête de modification dans une transaction. Il n'est pas approprié avec les opérations Start Transaction et End Transaction.
Contrôle ManageDsaIT Le contrôle ManageDsaIT est approprié pour les requête de modification dans une transaction. Il n'est pas approprié avec les opérations Start Transaction et End Transaction.
Contrôle d'autorisation proxifié Ce contrôle est approprié avec l'opération étendue Start Transaction, mais pas End Transaction.
Contrôle Read Entry Les contrôles Pre- et Post-Read sont appropriés avec des requêtes de modification dans une transaction. L'entrée est retournée dans txnEndRes.updatesControls et responseValue d'une réponse End Transaction.
^
26 octobre 2016

htmlpdflatexmanmd




rfc5905

rfc5905

Network Time Protocol v4

   npv4 est largement utilisé pour synchroniser les horloges système via un jeu de serveurs de temps distribué et de clients. Ce document décris l'architecture, le protocole, les états machine, les structures de données et les algorithmes.

   Le modèle de sous-réseau NTP inclus des serveurs de temps primaire largement accessibles, synchronisés par ondes radio ou filaires. Le but du protocole NTP est de transmettre les informations de temps depuis ces serveurs primaires vers des serveurs de temps secondaires et les clients via des réseaux privées et Internet. Les algorithmes d'ajustement de précision mitigent les erreurs qui peuvent résulter de problèmes réseaux, erreurs de serveurs, et d'actions hostiles possibles. Les serveurs et clients sont configurés tel que les valeurs atteignent le client depuis les serveurs primaires via le branchement de serveurs secondaires.

   Le design NTPv4 surmonte les lacunes importantes de NTPv3, corrige certains bugs, et incorpore de nouvelles fonctionnalités. En particulier, Les définitions d'horodatage NTP étendus encouragent l'utilisation des types de données à virgule flottante double via l'implémentation. En résultat, la résolution de temps est meilleur qu'une nanoseconde, et la résolution de fréquence est inférieur à une nanoseconde par seconde.

   Des améliorations supplémentaires incluent un nouvel algorithme de discipline qui est plus réactif aux fluctuations de fréquence hardware des horloges système. Les serveur primaire utilisant des machines modernes sont précis de l'ordre ed quelques dizaines de microsecondes. Les serveurs secondaires et clients sur les LAN rapide sont précis de l'ordre de quelques centaines de microsecondes avec des intervals d'interrogation de 1024 secondes, qui était le maximum avec NTPv3. Avec NTPv4, les serveurs et les clients sont précis de l'ordre de quelques dizaines de millisecondes avec des intervals d'interrogation jusqu'à 36 heures.

Modes d'opération

   Une implémentation NTP opère comme serveur primaire, secondaire, ou client. Un serveur primaire est synchronisé sur une horloge de référence directement traçable en UTC (ex: GPS, Galileo, etc.). Tous les serveurs et clients qui sont pleinement conforme NTPv4 doivent implémenter toute la suite d'algorithmes décris dans ce document. Pour maintenir la stabilité dans de grands réseaux NTP, les serveurs secondaires devraient être pleinement conforme NTPv4. Les algorithmes alternatifs peuvent être utilisés, mais leur sortie doit être identique aux algorithmes décris dans cette spécification.

Modes de protocole

   Il y a des variantes de protocole NTP: symétrique, client/serveur, et broadcast. Chacun est associé avec un mode d'association (une description de la relation entre 2 protagonistes NTP). De plus, les associations persistante sont mobilisées au démarrage et ne sont jamais démobilisées. Les associations éphémères sont mobilisées à l'arrivée d'un paquet et sont démobilisées au timeout ou sur erreur.


+-------------------+-------------------+------------------+
|__Association_Mode_|_Assoc._Mode_Value_|_Packet_Mode_Value|
+-------------------+-------------------+------------------+
|_Symmetric_Active__|_________1_________|_1_or_2___________|
|_Symmetric_Passive_|_________2_________|_1________________|
|_Client____________|_________3_________|_4________________|
|_Server____________|_________4_________|_3________________|
|_Broadcast_Server__|_________5_________|_5________________|
|_Broadcast_Client__|_________6_________|_N/A______________|
+-------------------+-------------------+------------------+

   Dans la variante client/serveur, un client persistant envoie des paquets mode 4 à un serveur qui retourne des paquets mode 3. Les serveurs fournissent la synchronisation à un ou plusieurs clients, mais n'acceptent pas la synchronisation depuis ces derniers. Un serveur peut également être une horloge de référence qui obtient son temp directement depuis une source de temps standard tel qu'un recepteur GPS ou un modem.

   Dans la variante symétrique, un paire opère comme client et serveur en utilisant une association symétrique passive ou active. Une association symétrique active envoie des paquets mode 1 à un paire symétrique actif associé. Alternativement, une association passive symétrique éphémère peut être mobilisée jusqu'à l'arrivée d'un paque symétrique actif sans association. Cette association envoie des paquets mode 2 et persiste jusqu'à une erreur ou un timeout. Les paires envoient et reçoivent la synchronisation entre-eux. Pour ce document, un paire opére comme un client, donc les références à un client implique un paire également.

   Dans la variante broadcast, une association serveur broadcast persistante envoie périodiquement des paquets mode 5 qui peuvent être reçus par plusieurs clients. À la réception d'un tel paquet sans association correspondante, une association client broadcast éphémère (mode 6) est mobilisée et persiste jusqu'à une erreur ou un timeout. Il est utile de fournir un initial quand le client opère en mode client et échange de nombreux paquets avec le serveur, donc pour calibrer le délai de propagation et pour lancer le protocole Autokey security, après lequel le cient revient en mode client broadcast. Un serveur broadcast pousse la synchronisation aux clients et autres serveurs.

   En suivant les conventions établies par l'industrie du téléphone, le niveau de chaque serveur dans la hiérarchie est définis par un numéro de strate. Les serveurs primaires sont assignés au strate 1. Plus le niveau de strate augmente, plus sa précision se dégrade, dépendant de la qualité du réseau et de la stabilité de l'horloge. Les erreurs, mesurés par les distances de synchronisation, augmentent approximativement en proportion aux numéro de strate et délais mesurés.

   Comme pratique standard, timer la topologie réseau devrait être organisé pour éviter les boucles de temps et minimiser la distance de synchronisation. Dans NTP, la topologie de sous-réseau est déterminée en utilisant une variante de l'algortihme de routage distribué Bellman-Ford, qui calcule le chemin de plus cours partant des serveurs primaires. L'algorithme réorganise automatiquement le sous-réseau, pour produire le temps de plus précis et le plus fiable, même quand il y a des erreurs dans le timing du réseaux

Découverte de serveur dynamique

   Il y a 2 associations spéciales, les clients manycast, et les serveurs manycast, qui fournissent une fonction de découverte de serveur dynamique. Il y a 2 types d'association de client manycast: persistant et éphémère. Le client manycast persistant envoie des paquets client mode 3 à une adresse multicast ou broadcast IPv4 ou IPv6. Si un serveur est utilisable pour la synchronisation, il retourne un paquet serveur (mode 4) en utilisant l'adresse unicast du client. À la réception du paquet, le client mobilise une association client éphémère (mode 3). L'association persiste jusqu'à erreur ou timeout.

   Un client manycast continue d'envoyer des paquets pour rechercher un nombre minimum d'associations. Il commence avec un TTL égal à 1 et incrémente jusqu'à ce qu'à la valeur minimale d'associations soient atteinte ou quand le TTL atteint la valeur max. Si la valeur max est atteinte et qu'il n'y a pas suffisamment d'associations, le client stoppe la transmission pendant un certain temps, efface toutes les associations mobilisées, et répète le cycle de recherche. Si un nombre minimum d'associations ont été mobilisés, le client commence à transmettre un paquet par période pour maitenir les associations. Le champ constraints limite la valeur minimum à 1 et max 255. Ces limites peuvent être définis individuellements.

   Les associations éphémères sont en concurence entre-elles. À mesure que des associations éphémères sont mobilisées, le client lance les algorithme d'aténuation pour les meilleurs candidats, les associations éphémère restantes sont démobilisées. De cette manière, la population inclus seulement les meilleurs candidats qui ont répondus le plus récemment avec un paquet NTP.

Définitions

   Certains termes technique sont définis dans cette section. Un timescale est une trame de référence où de temps est exprimé comme valeur d'un compteur binaire augmentant monotoniquement avec un nombre indéfinis de bits. Il compte en secondes et fractions de secondes, quand un point décimal est employé. Le timescale UTC est définis par ITU-R TF.460.

   UTC représente le temps solaire tel que disséminé par les laboratoires standards nationaux. Le temps système est représenté par l'horloge système maintenu par le hardware et le système d'exploitation. Le but des algorithmes NTP est de minimiser la différence de temps et la fréquence entre UTC et l'horloge système. Quand ces différences sont réduites sous la tolérance nominale, l'horloge système est dite synchronisée à UTC.

   La tade d'un événement est le temp UTC auquel l'événement UTC prend place. Les dates sont des valeur éphémères désignées pavec T majuscule. Le temps courant est un autre timescale qui coïncide avec la fonction de synchronisation NTP.

Un timestamp T(t) représente soit la date UTC ou un décalage de temps depuis UTC au temps t. Disons T(t) étant l'offset de temp, R(t) l'offset de fréquence, et D(t) l'âge moyen (d'abord dérivé de R(t) en respect de t). Alors, si T(t_0) est l'offset de temps UTC déterminé à t = t_0, l'offset de temps UTC au temps t est:
T(t) = T(t_0) + R(t_0)(t-t_0) + 1/2    *    D(t_0)(t-t_0)^2 + e

   où e est une erreur stochastique discuté ultérieurement. Bien que D(t) est important en caractérisant les oscilateurs de précision, il est ordinairement négligé pour les oscilateurs des ordinateurs. Dans ce document, toutes les valeurs de temps sont en seconde (s) et toutes les fréquences sont en secondes-par-secondes (s/s). C'est souvent convenable pour exprimer les offsets de fréquence en part-par-million (ppm), où 1 ppm est égal à 10^(-6) s/s

   Il est important dans les application de gestion de temps d'évaluer les performance de la fonction de timekeeping. Le modèle de performance NTP inclus 4 statistiques qui sont mis à jours chaque fois qu'un cilent fait une mesure avec un serveur. L'offset (theta) représente l'offset de temp maximum de l'horloge serveur relatif à l'horloge système. Le délai (delta) représente le délai entre le client et le serveur. La dispersion (epsilon) représente l'erreur maximum inhérente à la mesure. Cela augmente à un taux égal au maximum de tolérance de fréquence de l'horloge système disciplinée (PHI), typiquement 15 ppm. Le jitter (psi) est définis comme moyenne root-mean-square (RMS) des différences d'offset les plus récents, et représente l'erreur nominale en estimant l'offset.

   Bien que les statistiques theta, delta, epsilon, et psi représentent des mesures d'horloge système relatives à chaque serveur de temps séparémment, le protocole NTP inclus des mécanismes pour combiner les statistiques de nombreux serveurs pour une discipline plus précise et pour calibrer l'horloge système. L'offset système (THETA) représente l'offset max estimé pour la population serveur. Le jitter système (PSI) représente l'erreur nominale en estimant l'offset système. Les statistiques delta et epsilon sont accumulées à chaque niveau de strate depuis l'horloge de référence pour produire le délai racine (DELTA) et la dispersion racine (EPSILON). La distance de synchronisation (LAMBDA) égal à EPSILON + DELTA / 2 représente l'erreur maximum du à toutes les causes.

Modèle d'implémentation

La figure ci-dessous montre l'architecture d'une implémentation multi-threadée typique. Elle inclus 2 processus dédiés à chaque serveur, un processus paire pour reçevoir les messages du serveur ou de l'horloge de référence, et un processus d'intérrogation pour transmettre des messages au serveur ou à l'horloge de référence.
.....................................................................
._Remote___.___Peer/Poll__.______________System__________.__Clock___.
._Servers__.___Processes__.______________Process_________.Discipline.
.__________.______________.______________________________._Process__.
.+--------+._+-----------+._+------------+_______________.__________.
.|________|-›|___________|._|____________|_______________.__________.
.|Server_1|__|Peer/Poll_1|-›|____________|_______________.__________.
.|________|‹-|___________|._|____________|_______________.__________.
.+--------+._+-----------+._|____________|_______________.__________.
.__________._______^______._|____________|_______________.__________.
.__________._______|______._|____________|_______________.__________.
.+--------+._+-----------+._|____________|__+-----------+.__________.
.|________|-›|___________|._|_Selection__|-›|___________|._+------+_.
.|Server_2|__|Peer/Poll_2|-›|____and_____|__|_Combine___|-›|_Loop_|_.
.|________|‹-|___________|._|_Cluster____|__|_Algorithm_|._|Filter|_.
.+--------+._+-----------+._|_Algorithms_|-›|___________|._+------+_.
.__________._______^______._|____________|__+-----------+.____|_____.
.__________._______|______._|____________|_______________.____|_____.
.+--------+._+-----------+._|____________|_______________.____|_____.
.|________|-›|___________|._|____________|_______________.____|_____.
.|Server_3|__|Peer/Poll_3|-›|____________|_______________.____|_____.
.|________|‹-|___________|._|____________|_______________.____|_____.
.+--------+._+-----------+._+------------+_______________.____|_____.
....................^.........................................|......
____________________|____________________________________.____V_____.
____________________|____________________________________._+-----+__.
____________________+--------------------------------------|_VFO_|__.
_________________________________________________________._+-----+__.
_________________________________________________________.__Clock___.
_________________________________________________________.__Adjust__.
_________________________________________________________.__Process_.
_________________________________________________________............

   Ces processus opèrent sur une structure de données commune, appelée association, qui contient les statistiques décrites plus haut, ainsi que d'autres données décrites dans la section "Peer Process". Un client envoie des paquets à un ou plusiers serveurs et traite les paquets retournés à leur réception. Le serveur interchange les adresses source et de destination et les ports, change certains champs dans le paquet et le retourne immédiatement (dans le mode client/serveur) ou ultérieurement (dans les modes symétriques). Comme chaque NTP message est reçu, l'offset theta entre l'horloge du paire et l'horloge système est calculée avec les statistiques associées delta, epsilon, et psi.

   Le processus système inclus la sélection, cluster, et les algorithmes de combinaison qui mitigent les différents serveurs et horloges de référence pour déterminer le candidat le plus fiable et le plus précis pour synchroniser l'horloge système. L'algorithme de sélection utiliser les principes de détection de faut Byzantine pour supprimer les candidats présumés incorrects appelés "falsetickers" de la population, laissant seulement les bons candidats appelés les "truechimers". Un truechimer est une horloge qui maintient un timekeeping précis d'un standard précédemment publié et validé, alors qu'un falseticker est une horloge qui montre un temps inconsistant. L'algorithme cluster utilise les principes statistiques pour trouver le jeu de truechimers les plus précis. L'algorithme combine calcule l'offset d'horloge final en créant une moyenne statistique des truechimers.

   Le processus de discipline d'horloge est un processus système qui contrôle le temps et la fréquence de l'horloge système, ici représenté comme un oscilateur à fréquence variable (VFO). Les timestamps données par le VFO ferment la boucle qui maintient le temps système. Associé avec le processus de discipline d'horloge on trouve le processus d'ajustement d'horloge, qui se lance une fois par secondes pour injecter un offset de temps calculé et maintient la fréquence constante. La moyenne RMS de la différence d'offset de temps passé représente l'erreur nominale (system clock jitter). La moyenne RMS des différences d'offset de fréquence passées représente l'échelonnement de fréquence de l'oscilateur (frequency wander).

   Un client envoie des messages à chaque serveur avec un interval d'interrogation de 2^tau secondes, comme déterminé par l'exposant d'interrogation pau. Dans NTPv4, les plages tau vont de 4 (16s) à 17 (36h). La valeur de tau est déterminée par l'algorithme de discipline d'horloge pour correspondre à la constante de boucle de temps T_c = 2^tau. Dans le mode client/serveur, le serveur répond immédiatement; cependant, dans les modes symétriques, chacun des 2 paires gèrent tau comme une fonction de l'offset de temps système et de jitter système, donc ils ne peuvent pas être d'accord avec la même valeur. Il est important que le comportement dynamique de l'algorithme de discipline d'horloge soit contrôlé pour maintenir la stabilité dans le sous-réseau NTP. Cela exige que les paires soient d'accord sur un tau commun égal à l'exposant d'interrogation minimum de tous les paires.

   Le modèle d'implémentation inclus des moyens pour définir et ajuster l'horloge système. Le système d'exploitation est supposé fournir 2 fonctions: une pour définir le temps directement, par exemple, la fonction Unix settimeofday(), et une autre pour ajuster le temps en petits incréments avançant ou retardant le temps par une quantité définie, par exemple, la fonction Unix adjtime(). Dans ce design le processus de discipline d'horloge utilise la foncion adjtime() si l'ajustement est inférieur au seuil définis, et la fonction settimeofday() au delà.

Types de données

   Toutes les valeurs de temps NTP sont représentées au format complément de 2, avec les bits numérotés en big-endian. Il y a 3 formats de temps NTP, un format de date 128bits, un format d'horodatage 64bits, et un format cours 32bits. Le format de date 128 bits est utilisé quand un stockage suffisant et la taille de mots sont disponibles. Il inclus le champs des secondes 64 bits signés couvrant 584 milliards d'années et un champs 64bits de fraction résolvant .05 attosecond. Par convention dans le mappage entre les formats, le champs secondes est divisé en un champ 32 bits Era Number, et nu champ 32 bits Era Offset. Les ères ne peuvent pas être produites par NTP directement, et il n'est pas nécessaire de le faire. Si nécessaire, ils peuvent être dérivés par des moyens externes, tel que le système de fichier ou un hardware dédié.


_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________Seconds______________|___________Fraction____________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_
_________________________NTP_Short_Format
_
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________________________Seconds____________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________________________Fraction___________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_
_______________________NTP_Timestamp_Format
_
_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________________________Era_Number__________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________________________Era_Offset__________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
|___________________________Fraction____________________________|
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Le format 64bits est utilisé dans les en-têtes de paquet et d'autres emplacement avec une taille de mot limitée. Il inclus un champ 32 bits non-signé des secondes couvrant 126 ans et un champ 32 bits fractionnel résolvant 232 picosecondes. Le format cours 32 bits est utilisé dans les champs d'en-tête delay et dispersion où la résoluction complète n'est pas justifiée. Il inclus un champ 16 bits non-signé des secondes, et un champ 16 bits de fraction.

   Dans les formats de date et d'horodatage, L'époque, ou la date de base de l'ère 0 est 0 h 1 Janvier 1900 UTC, quand tous les bits sont à zéro. Il devrait être noté que strictement parlant, UTC n'existait pas avant le 1 Janvier 1972, mais il est convenable de supposer qu'il à toujours existé. Les dates sont relatives à cette époque; les valeurs supérieurs à 0 représentent le temps après cette date; les valeurs inférieurs à 0 représentent les dates avant cette date.. Noter que le champ Era Offset du format date et le champ Seconds du format timestamp ont la même interprétation.

   Les timestamp sont des valeurs non-signées, et les opérations sur elles produisent un résultat dans la même ère ou ère adjacente. L'ère 0 inclus les dates de l'époque premier jusqu'à une date en 2036, quand le champ timestamp entoure la date de base pour l'ère 1 est établie. Dans ces format, un valeur 0 est un cas spécial représentant un temps inconnu ou désynchronisé. La figure ci-dessous montre des dates NTP historiques avec leur Jours au calendrier Julien modifié (MJD), l'ère NTP, et l'horodatage NTP:


+-------------+------------+-----+---------------+------------------+
|_Date________|_MJD________|_NTP_|_NTP_Timestamp_|_Epoch____________|
|_____________|____________|_Era_|_Era_Offset____|__________________|
+-------------+------------+-----+---------------+------------------+
|_1_Jan_-4712_|_-2,400,001_|_-49_|_1,795,583,104_|_1st_day_Julian___|
|_1_Jan_-1____|_-679,306___|_-14_|_139,775,744___|_2_BCE____________|
|_1_Jan_0_____|_-678,491___|_-14_|_171,311,744___|_1_BCE____________|
|_1_Jan_1_____|_-678,575___|_-14_|_202,939,144___|_1_CE_____________|
|_4_Oct_1582__|_-100,851___|_-3__|_2,873,647,488_|_Last_day_Julian__|
|_15_Oct_1582_|_-100,840___|_-3__|_2,874,597,888_|_First_day________|
|_____________|____________|_____|_______________|_Gregorian________|
|_31_Dec_1899_|_15019______|_-1__|_4,294,880,896_|_Last_day_NTP_Era_|
|_____________|____________|_____|_______________|_-1_______________|
|_1_Jan_1900__|_15020______|_0___|_0_____________|_First_day_NTP____|
|_____________|____________|_____|_______________|_Era_0____________|
|_1_Jan_1970__|_40,587_____|_0___|_2,208,988,800_|_First_day_UNIX___|
|_1_Jan_1972__|_41,317_____|_0___|_2,272,060,800_|_First_day_UTC____|
|_31_Dec_1999_|_51,543_____|_0___|_3,155,587,200_|_Last_day_20th____|
|_____________|____________|_____|_______________|_Century__________|
|_8_Feb_2036__|_64,731_____|_1___|_63,104________|_First_day_NTP____|
|_____________|____________|_____|_______________|_Era_1____________|
+-------------+------------+-----+---------------+------------------+

   Disons P le nombre de bits significatifs dans une fraction de secondes. La résolution d'horloge est définis avec 2^(-p), en secondes. Pour minimiser le biais et aider à rendre les horodatages non-prédictibles par un intrus, les bits non-signifiants devraient être mis à une chaîne aléatoire non-biaisée. La précision d'horloge est définis comme temps courant pour lire l'horloge système, en secondes. Noter que la précision définis de cette manière peut être supérieure ou inférieur à la résolution. Le terme rho, représentant la précision utilisée dans le protocole, est le plus grand des 2.

   La seule opération arithmétique permise sur les dates et horodatage est la soustraction en complément de 2, Donnant un résultat 127bits ou 63bits signé. Il est important de noter que l'arithmétique en complément de 2 ne distingue pas les valeurs signées et non-signées (bien que les comparaisons puissent prendre en compte le signe); seule les instructions de branchement conditionnels le font. Ainsi, bien que la distinction est faite entre les dates signées et non-signées, elles sont traitées de la même manière. Une perception hasardeuse avec les calculs d'horodatage 64-bits dans une ère, tels qu'il sera possible en 2036, peut résulter par un dépassement. En fait, si le client est définis dans les 68 ans du serveur avant que le protocole soit démarré, les valeurs correctes sont obtenues même si le client et le serveur sont dans des ères adjacentes.

   Certaines valeurs de temps sont représentées au format exposant, incluant la précition, constante de temp, et interval d'interrogation. Il y a un entier signé 8-bits en log2 (log base 2) secondes. Les seules opérations arithmétiques permises sur eux sont l'incrément et le décrément. Dans ce document, pour simplifier la présentation, une référence à une de ces variables par nom signifie la valeur exponentielle, par exemple, l'intervalle d'interrogation est 1024 secondes, alors que la référence par nom et exposant signifie la valeur actuelle, par exemple, l'exposant d'interrogation est 10.

   Pour convertir le système de temps en un autre format que NTP, il est nécessaire que le nombre de secondes s depuis l'époque première vers le temps système soit déterminé. Pour déterminer l'ère et l'horodatage s,

  era = s / 2^(32) et timestamp = s - era * 2 ^(32)

  qui fonctionne pour les dates positives et négatives. Pour déterminer s en donnant l'ère et le timestamp,

  s = era * 2^(32) + timestamp

   La conversion NTP et temps système peut être un peut désordonné, et est au-delà du périmètre de ce document. Noter que le nombre de jours dans l'ère 0 est plus que le nombre de jours dans la plupart des autres ères, et cela ne se reproduira pas jusqu'en 2400 dans l'ère 3.

   Dans la description des variables d'état qui suivent, une référence explicite au type entier implique un entier non-signé 32 bits. Cela simplifie la vérification des limites, vu que seul la limite supérieure doit être définie. Sans référence explicite, le type par défaut est 64-bits double flottante.

Structures de données

   Les machines d'état NTP sont définies dans les sections suivantes. Les variables d'état sont séparées en classes en accord avec leur fonction dans les en-têtes de paquet, processus paires et d'interrogation, le processus système, et le processus de discipline d'horloge. Les variables de paquet représentent les variables d'en-tête NTP dans les paquets transmis et reçus. Les variables des paires et d'interrogation représentent le contenu de l'association pour chaque serveur séparément. Les variables systèmes représente l'état du serveur tel que vu pas ses clients dépendants. Les variables de discipline d'horloge représentent le travail interne de l'algorithme de discipline d'horloge.

Conventions de structure

   Pour distinguer les différentes variables de même nom, mais utilisé dans différents processus, la convention de nommage ci-dessous est adoptée. Une variable d'un paquet reçu v est un membre de la structure de paquet r avec le nom pleinement qualifié r.v. De manière similaire, x.v est une variable de paquet transmise, p.v est une variable paire, s.v une variable système, et c.v une variable de discipline d'horloge. Il y a un jeu de variables paire pour chaque association; il y a seulement un jeu de variable d'horloge et système.


+------+---------------------------------+
|_Name_|_Description_____________________|
+------+---------------------------------+
|_r.___|_receive packet header variable__|
|_x.___|_transmit packet header variable_|
|_p.___|_peer/poll variable______________|
|_s.___|_system variable_________________|
|_c.___|_clock discipline variable_______|
+------+---------------------------------+

Paramètres globaux

En plus de ces classes de variable, un monbre de paramètres globaux sont définis dans ce document, incluant ceux affichés avec des valeurs ci-dessous:
+-----------+-------+----------------------------------+
|_Name______|_Value_|_Description______________________|
+-----------+-------+----------------------------------+
|_PORT______|_123___|_NTP_port_number__________________|
|_VERSION___|_4_____|_NTP_version_number_______________|
|_TOLERANCE_|_15e-6_|_frequency_tolerance_PHI_(s/s)____|
|_MINPOLL___|_4_____|_minimum_poll_exponent_(16_s)_____|
|_MAXPOLL___|_17____|_maximum_poll_exponent_(36_h)_____|
|_MAXDISP___|_16____|_maximum_dispersion_(16_s)________|
|_MINDISP___|_.005__|_minimum_dispersion_increment_(s)_|
|_MAXDIST___|_1_____|_distance_threshold_(1_s)_________|
|_MAXSTRAT__|_16____|_maximum_stratum_number___________|
+-----------+-------+----------------------------------+

   Bien que des paramètres globaux sont nécessaires pour l'interopérabilité, une collection plus grande est nécessaire dans une implémentation. L'appendix A.1.1 contient ceux utilisés par le squelette pour les algorithme d'atténuation, de discipline d'horloge, et des fonctions dépendante de l'implémentation. Certaines valeurs de paramètres sont gravés dans la pierre, comme le port NTP assigné par l'IANA et le numéro de version assigné NTPv4.

   Bien qu'affiché avec des valeurs fixées dans ce document, certaines implémentations peuvent ajuster ces variables.

Variables de l'en-tête de paquet

   Les variables d'état les plus importantes d'un point de vue externe sont les variables d'en-tête de paquet. L'en-tête NTP consiste d'un numéro entier 32bits dans l'ordre d'octet réseaux. Le format du paquet consiste de 3 composants: l'en-tête lui-même, un ou plusieurs champs d'extension, et un MAC optionnel. L'en-tête est identique à l'en-tête NTPv3. Les champs d'extensions sont utilisées par les algorithmes cryptographiques à clé publique Autokey décris dans la rfc5906. Le MAC est utilisé par Autokey et l'algorithme à clé symétrique définis dans cette rfc.


+-----------+------------+-----------------------+
|_Name______|_Formula____|_Description___________|
+-----------+------------+-----------------------+
|_leap______|_leap_______|_leap_indicator_(LI)___|
|_version___|_version____|_version_number_(VN)___|
|_mode______|_mode_______|_mode__________________|
|_stratum___|_stratum____|_stratum_______________|
|_poll______|_poll_______|_poll_exponent_________|
|_precision_|_rho________|_precision_exponent____|
|_rootdelay_|_delta_r____|_root_delay____________|
|_rootdisp__|_epsilon_r__|_root_dispersion_______|
|_refid_____|_refid______|_reference_ID__________|
|_reftime___|_reftime____|_reference_timestamp___|
|_org_______|_T1_________|_origin_timestamp______|
|_rec_______|_T2_________|_receive_timestamp_____|
|_xmt_______|_T3_________|_transmit_timestamp____|
|_dst_______|_T4_________|_destination_timestamp_|
|_keyid_____|_keyid______|_key_ID________________|
|_dgst______|_dgst_______|_message_digest________|
+-----------+------------+-----------------------+

Le paquet NTP est un datagramme UDP. Certains champs utilisent plusieurs mots et d'autres sont empaquetés dans des champs plus petits dans un mot. L'en-tête de paquet NTP ci-dessous a 12 mots suivi par des champs d'extension optionnels et finalement un MAC consistant du champ Key Identifier et du champ Message Digest
_0___________________1___________________2___________________3__
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI_|_VN__|Mode_|____Stratum_____|_____Poll______|__Precision___|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Root_Delay____________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Root_Dispersion_______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________________________Reference_ID_________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+_____________________Reference_Timestamp_(64)__________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+______________________Origin_Timestamp_(64)____________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+______________________Receive_Timestamp_(64)___________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+______________________Transmit_Timestamp_(64)__________________+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
._______________________________________________________________.
.____________________Extension_Field_1_(variable)_______________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
._______________________________________________________________.
.____________________Extension_Field_2_(variable)_______________.
._______________________________________________________________.
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________________________Key_Identifier_______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
|____________________________dgst_(128)_________________________|
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Les champs d'extension sont utilisé pour ajouter de capacités optionnelles, par exemple, le protocole de sécurité Autokey. Le format du champ d'extension est présenté dans l'ordre pour que le paquet soit parcouru sans connaissance des fonctions du champ d'extension.

   Excepté pour une variation mineur en utilisant la famille d'adresse IPv6, ces champs sont compatibles avec NTPv3. Les champs d'en-tête de paquet s'appliquent aux paquets transmis et reçus. Les champs et variables de paquet associés (entre parenthèses) sont interprétés comme suit:

LI Leap Indicator (leap): Entier 2-bits d'indication d'alerte d'une seconde à insérer ou supprimer dans la dernière minute du mois courant:

Valeur_Signification
0______pas d'alerte
1______la dernière minute a 61 secondes
2______la dernière minute a 59 secondes
3______inconnu (horloge désynchronisée)

VN Numéro de version sur 3bits, actuellement 4
Mode: entier 3bits représentant le mode:

Valeur_Signification
0______Réservé
1______Actif symétrique
2______Passif symétrique
3______client
4______server
5______broadcast
6______Message de contrôle NTP
7______Réservé

Stratum: Entier 8bits représentant la strate:

Valeur_Signification
0______Non-spécifié ou invalide
1______Serveur primaire, équipé avec un récepteur GPS
2-15___serveur secondaire (via NTP)
16_____Désynchronisé
17-255_Réservé

   Il est courant de mapper la valeur de strate 0 dans les paquets reçus à MAXSTRAT (16) dans la variable paire p.stratum et de mapper les valeurs p.stratum de MAXSTRAT ou supérieur à 0 dans les paquets transmis. Cela permet aux horloges de référence, qui normalement apparaîssent à la strate 0, d'être convenablement mitigée en utilisant les même algorithmes de sélection d'horloge utilisé pour les sources externe.

Poll Entier signé 8-bits représentant l'interval maximum entre les messages successifs, en secondes log2. Les limites suggérées pour ces interval minimun et maximum sont 6 et 10.
Precision: Entier 8-bits représentant la précision de l'horloge système, en secondes log2. Par exemple, une valeur de -18 correspond à une précision d'environ une microseconde. La précision peut être déterminée quand le service démarre d'abord au temps minimum des nombreuses itérations pour lire l'horloge système.
Root Delay Délai total pour l'horloge de référence, au format NTP court
Root Dispersion Dispersion totale de l'horloge de référence, au format NTP court.
Reference ID Code 32-bits identifiant le serveur particulier ou l'horloge de référence. L'interprétation dépend de la valeur dans le champ stratum. Pour les paquets de strate 0, c'est une chaîne ASCII 4 caractères, apperé le 'kiss code', utilisé pour débugger ou superviser. Pour un strate 1, c'est une chaîne ASCII 4 octets assigné à l'horloge de référence. La liste des identifiants de référence est maintenue par l'IANA:


+------+----------------------------------------------------------+
|_ID___|_Clock_Source_____________________________________________|
+------+----------------------------------------------------------+
|_GOES_|_Geosynchronous_Orbit_Environment_Satellite_______________|
|_GPS__|_Global_Position_System___________________________________|
|_GAL__|_Galileo_Positioning_System_______________________________|
|_PPS__|_Generic_pulse-per-second_________________________________|
|_IRIG_|_Inter-Range_Instrumentation_Group________________________|
|_WWVB_|_LF_Radio_WWVB_Ft._Collins,_CO_60_kHz_____________________|
|_DCF__|_LF_Radio_DCF77_Mainflingen,_DE_77.5_kHz__________________|
|_HBG__|_LF_Radio_HBG_Prangins,_HB_75_kHz_________________________|
|_MSF__|_LF_Radio_MSF_Anthorn,_UK_60_kHz__________________________|
|_JJY__|_LF_Radio_JJY_Fukushima,_JP_40_kHz,_Saga,_JP_60_kHz_______|
|_LORC_|_MF_Radio_LORAN_C_station,_100_kHz________________________|
|_TDF__|_MF_Radio_Allouis,_FR_162_kHz_____________________________|
|_CHU__|_HF_Radio_CHU_Ottawa,_Ontario_____________________________|
|_WWV__|_HF_Radio_WWV_Ft._Collins,_CO_____________________________|
|_WWVH_|_HF_Radio_WWVH_Kauai,_HI__________________________________|
|_NIST_|_NIST_telephone_modem_____________________________________|
|_ACTS_|_NIST_telephone_modem_____________________________________|
|_USNO_|_USNO_telephone_modem_____________________________________|
|_PTB__|_European_telephone_modem_________________________________|
+------+----------------------------------------------------------+

   Sous une strate 1 ( les serveurs secondaires et clients), c'est l'identifiant de référence du serveur et peut être utilisé pour détecter les boucles de temps. Avec IPv4, l'identifiant est une adresse IPv4. Avec IPv6, ce sont les 4 premiers octets du hash MD5 de l'adresse IPv6.

Reference Timestamp Temps quand l'horloge système a été définie ou corrigée, au format timestamp NTP
Origin Timestamp Temps auquel le client à envoyé la requête au serveur, au format timestamp NTP.
Receive Timestamp Temp auquel le serveur a reçu la requête du client
Transmit Timestamp Temp auquel le serveur en émit la réponse au client
Destination Timestamp Temp auquel le client a reçu la réponse du serveur

   Note: le champ Destination Timestamp n'est pas inclus comme champ d'en-tête, il est déterminé à l'arrivée du paquet et disponible dans la structure de données du tampon du paquet.

   Si NTP a accès à la couche physique, les timestamp sont associés avec le début du symbole après le début de la trame. Sinon, les implémentations devraient tenter d'associer le timestapm au premier point accessible dans la trame.

   Le MAC consiste de l'identifiant de clé suivi par le Hash. Le hash, ou cryptosum, est calculé comme dans la rfc1321 sur tous les en-têtes NTP et les extensions de champ optionnels, mais pas le MAC lui-même

Extension Field n Voir plus bas pour une description du format de ce champ
Key Identifier Entier non-signé 32-bits utilisé par le client et le serveur pour désigner une clé MD5 128-bits secrète
Message Digest Hash MD5 128-bits calculé

   Il devrait être noté que le calcule MAC utilisé ici diffère de ceux définis dans les rfc1305 et rfc4330, mais est consistant avec la manière dont les implémentations existantes génèrent un MAC.

Paquet Kill-o'-Death

   Si le champ stratum est 0, le champ Reference Identifier peut être utilisé pour transporter des messages utiles pour reporter le status et le contrôle d'accès. Ils sont appelés des paquets KoD (Kiss-o'-Death) et les messages ASCII qu'ils transportent sont appelés des codes Kiss. Les paquets KoD prennent leur nom de leur première utilisation qui consistait à dire à un client d'arrêter d'envoyer des paquets qui violent les contrôles d'accès au serveur. Les codes Kiss peuvent fournir des informations utiles pour un client intelligent, soit NTPv4 soit SNTPv4. Les codes Kiss sont encodés en chaînes ASCII 4 caractères. Une liste de codes définis est donné ci-dessous. Les destinataires des Kiss codes doivent les inspecter et, dans les cas suivants, effectuer ces actions:

        a. Pour DENY ou RSTR, le client doit démobiliser toutes associations avec ce serveur et arrêter d'envoyer des paquets à ce serveur.
        b. Pour RATE, le client doit immédiatement réduit sont interval d'intérrogation vers ce serveur et continuer à le réduire chaque fois qu'il reçoit un RATE
        c. Les Kiss codes commençant avec X sont pour des expérimentation et développement et doivent être ignorés s'ils ne sont pas retenus
        d. Autre que les conditions ci-dessus, les paquets KoD n'ont pas de signification de protocole et sont supprimés après inspection


+------+------------------------------------------------------------+
|_Code_|___________________________Meaning__________________________|
+------+------------------------------------------------------------+
|_ACST_|_The association belongs to a unicast server._______________|
|_AUTH_|_Server authentication failed.______________________________|
|_AUTO_|_Autokey sequence failed.___________________________________|
|_BCST_|_The association belongs to a broadcast server._____________|
|_CRYP_|_Cryptographic authentication or identification failed._____|
|_DENY_|_Access denied by remote server.____________________________|
|_DROP_|_Lost peer in symmetric mode._______________________________|
|_RSTR_|_Access denied due to local policy._________________________|
|_INIT_|_The association has not yet synchronized for the first_____|
|______|_time.______________________________________________________|
|_MCST_|_The association belongs to a dynamically discovered server.|
|_NKEY_|_No key found. Either the key was never installed or is_____|
|______|_not trusted._______________________________________________|
|_RATE_|_Rate exceeded. The server has temporarily denied access____|
|______|_because the client exceeded the rate threshold.____________|
|_RMOT_|_Alteration of association from a remote host running_______|
|______|_ntpdc._____________________________________________________|
|_STEP_|_A step change in system time has occurred, but the_________|
|______|_association has not yet resynchronized.____________________|
+------+------------------------------------------------------------+

   Le Receive Timestamp et Transmit Timestamp ne sont pas définis dans un paquet KoD et ne doivent pas être considéré par les clients.

Format de champ d'extension NTP

   Dans NTPv4, un ou plusieurs champs d'extension peuvent être insérés après l'en-tête et avant le MAC, qui est toujours présent quand un champ d'extension est présent. Ce document ne définis que le format du champ, pas son contenu. Un champ d'extension contient une requête ou un message de réponse au format:


_0___________________1___________________2___________________3___
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________Field_Type___________|____________Length_____________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
._______________________________________________________________.
.____________________________Value______________________________.
._______________________________________________________________.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________Padding_(as_needed)_____________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Tous les champs d'extension sont remplis avec des 0 à des limites word (4 octets). Le champ de type de champ est spécifique à la fonction définie et n'est pas élaborée ici. Bien que la longueur de champ minimum contenant les champs requis est de 4 words, une longueur maximum reste à établir.

   Le champ Length est un entier 16-bits non-signé indiquant la longueur du champs d'extension en octets, incluant le padding.

Protocol On-Wire

   Le cœur du protocole NTP on-wire est le mécanisme core qui échange les valeurs de temps entre les serveurs, paires, et client. Il est résistant à la perte de paquets ou de paquets dupliqués. L'intégrité des données est fournie par les checksums IP et UDP. Aucun contrôle de flux ou de facilité de retransmition ne sont fournis ou nécessaires. Le protocole utilise les timestamp, qui sont soit extraits des en-tête de paquet ou pris depuis l'horloge système une fois reçu ou envoyés. Les timestamps sont des données de précision et devrait être frappés en acs de retransmition L2 et corriger le temps de calcule du MAC à transmettre.

   Les messages NTP utilisent 2 modes de communication différents, one-to-one, et one-to-many, communément référré à unicast et broadcast. Pour ce document, le terme broadcast est interprété comme mécanisme one-to-many. Pour IPv6, c'est équivalent au broadcast IPv4 et au multicast IPv4. Pour IPv6 c'est équivalent au multicast IPv6. L'IANA a alloué l'adresse de multicast IPv4 224.0.1.1 et l'adresse multicast IPv6 se terminant par :101, avec le préfix déterminé par les règle de scoping. Tout autre adresse multicast non-allouée peut être également utilisée en plus de ces adresses multicast.

   Le protocole on-wire utilise 4 horodatages numérotés t1 à t4 et 3 variables d'état org, rec, et xmt. La figure ci-dessous montre le cas le plus général où chacun des paires, A et B, mesurent indépendamment l'offset et le delais relatif à l'autre. Pour l'illustration, Les horodatages de paquet sont affichés en minuscule, et les variables d'état sont affichés en majuscule. Les variables d'état sont copiées des horodatages de paquet à l'arrivée et au départ d'un paquet.


_____________t2____________t3___________t6____________t7
________+---------+___+---------+___+---------+___+---------+
________|____0____|___|____t1___|___|___t3____|___|____t5___|
________+---------+___+---------+___+---------+___+---------+
________|____0____|___|____t2___|___|___t4____|___|____t6___|__Packet
________+---------+___+---------+___+---------+___+---------+_Timestamps
________|___t1____|___|t3=clock_|___|___t5____|___|t7=clock_|
________+---------+___+---------+___+---------+___+---------+
________|t2=clock_|_________________|t6=clock_|
________+---------+_________________+---------+
_______________________________________________________________Peer_B
________+---------+___+---------+___+---------+___+---------+
___org__|___T1____|___|____T1___|___|_t5‹›T1?_|___|____T5___|
________+---------+___+---------+___+---------+___+---------+___State
___rec__|___T2____|___|____T2___|___|___T6____|___|____T6___|_Variables
________+---------+___+---------+___+---------+___+---------+
___xmt__|____0____|___|____T3___|___|__t3=T3?_|___|____T7___|
________+---------+___+---------+___+---------+___+---------+
    
__________________t2______t3_________________t6__________t7
________---------------------------------------------------------
_________________/\_________\_________________/\____________\
_________________/___________\________________/______________\
________________/_____________\______________/________________\
_______________/_______________\/___________/_________________\/
________---------------------------------------------------------
_____________t1________________t4_________t5__________________t8
    
____________t1____________t4____________t5_____________t8
________+---------+___+---------+___+---------+___+---------+
________|____0____|___|____t1___|___|___t3____|___|____t5___|
________+---------+___+---------+___+---------+___+---------+
________|____0____|___|____t2___|___|___t4____|___|____t6___|__Packet
________+---------+___+---------+___+---------+___+---------+_Timestamps
________|t1=clock_|___|____t3___|___|t5=clock_|___|____t7___|
________+---------+___+---------+___+---------+___+---------+
______________________|t4=clock_|_________________|t8=clock_|
______________________+---------+_________________+---------+
_______________________________________________________________Peer_A
________+---------+___+---------+___+---------+___+---------+
___org__|____0____|___|__t3‹؎?_|___|___T3____|___|_t7‹›T3?_|
________+---------+___+---------+___+---------+___+---------+___State
___rec__|____0____|___|____T4___|___|___T4____|___|____T8___|_Variables
________+---------+___+---------+___+---------+___+---------+
___xmt__|___T1____|___|__t1=T1?_|___|___T5____|___|__t5=T5?_|
________+---------+___+---------+___+---------+___+---------+

   Le premier paquet transmis par A contient seulement le temps d'origine t1, qui est copié dans T1. B reçoit le paquet au temps t2 et copie t1 dans T1 et le temps reçu t2 dans T2. À cet instant ou ultérieurement à t3, B envoie un paquet à A contenant t1 et t2 et le temps t3. Les 3 horodatages sont copiés dans les variables d'état correspondants. A reçoit le paquet à t4 contenant les 3 horodatages t1, t2 et t3 et le temps de destination t4. Ces 4 horodatages sont utilisés pour calculer l'offset et le délai de B relatif à A, comme décris plus bas.

   Avant de mettre à jours les variables d'état xmt et org, 2 vérifications sont effectuées pour éviter les duplicats, bugs, ou paquets relayés. Dans l'échange ci-dessus, un paquet est dupliqueé ou rejouté si le temps t3 correspond à la variable d'état T3. Un paquet est buggé si t1 dans le paquet ne correspond pas à la variables d'état xmt T1. Pour protéger les replay du dernier paquet transmis, la variable d'état xmt est mises à 0 immédiatement après la vérification réussie.

Les 4 horodatages les plus récents, T1 à T4, sont utilisés pour calculer l'offset de B relatif à A.
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]
et le délai
delta = T(ABA) = (T4-T1) - (T3-T2).

   Noter que les quantités dans les parenthèses sont calculées depuis des horodatages non-signés 64-bits et résulte en valeurs signées avec 63 bits significatifs plus le signe. Ces valeurs peuvent représenter les dates de 68 ans dans le passé à 68 ans dans le future. Cependant, l'offset et le délai sont calculés comme somme et différences de ces valeurs, qui contiennent 62 bits signifiants et 2 bits de signe, donc il peuvent représenter des valeurs non ambigües de 34 ans dans le passé à 34 ans dans le future. En d'autre termes, le temps du client doit être définis dans les 34 ans du serveur avant que le service soit démarré. C'est une limitation fondammentale avec l'arithmétique entier 64-bits.

   Dans les implémentations où l'arithmétique double flottante est disponible, les différence de premier ordre peuvent être convertis en double flottant et les sommes de second ordre peuvent être calculés dans cet arithmétique. Vu que les termes de second ordre sont typiquement très petits relatifs aux magnitudes d'horodatage, il n'y a pas de perte de signification, ni de plage ambigüe restaurée depuis 34 ans à 68 ans.

   Dans certains scénarios où l'offset de fréquence initial du client est relativement grand et que la propagation de temps et petite, il est possible que le délai de calcul devienne négatif. Par exemple, si la différence de fréquence est de 100 ppm et que l'interval T4-T1 est de 64 s, le délai apparent est -6,4ms. Vu que les valeurs négatives sont mal gérés dans les calculs suivants, la valeur du delta devrait être ramené à au moins s.rho, où s.rho est la précision système, exprimée en secondes.

   La discution ci-dessus assume le cas le plus général où 2 paires symétriques mesurent indépendamment les offsets et délais entre-eux. Dans le cas d'un serveur sans état, le protocole peut être simplifié. Un serveur sans état copie T3 et T4 du paquet client dans T1 et T2 du paquet serveur et construit à T3 avant de l'envoyer au client.

   Noter que le protocole on-wire tel que décris résiste aux replay d'un paquet réponse serveur. Cependant, il ne résiste pas aux replay d'un paquet request client, qui peut résulter en une réponse serveur avec de nouvelles valeurs de T2 et T3 et résulter dans des offsets et délais incorrect. Cette vulnérabilité peut être évitée en définissant la variable d'état xmt à 0 après avoir calculé l'offset et le délai.

Processus paire

   Les déscriptions de processus à suivre incluent un listing des variables d'état importantes suivies par une vue générales des opérations implémentées comme routines. Il est fait fréquemment référence au squelette dans l'appendice. Ce squelette inclus des fragments C qui décrivent les fonctions plus en détail. Il inclus les paramètres, variables, et déclarations nécessaires pour une implémentation NTPv4 conforme. Cependant, de nombreuses variables additionnelles et routines peuvent être nécessaire dans une implémentation fonctionnelle.

   Le processus paire est appelé à l'arrivée d'un paquet serveur ou paire. Il lance le protocole on-wire pour déterminer le décalage l'horloge et le délai et calcule des statistiques utilisées par les processus systèmes et d'intérrogation. Les variables paire sont instanciées dans la structure de données d'association quand la structure est initialisée et mis à jours dans les paquets arrivants. Il y a un processus paire, un processus d'interrogation, et un processus d'association pour chaque serveur.

Variables de processus paire

   Les figures ci-dessous sommarisent les noms commun, noms de formule, et description courte des variables paires. Ces noms commun et noms de formule sont interchangeable; les noms de formules sont prévus pour augmenter la lisibilité des équations dans cette spécification. Sauf mention, toutes les variables paire ont le préfix p.

Variables de configuration de processus paire
+---------+----------+-----------------------+
|_Name____|_Formula__|_Description___________|
+---------+----------+-----------------------+
|_srcaddr_|_srcaddr__|_source_address________|
|_srcport_|_srcport__|_source_port___________|
|_dstaddr_|_dstaddr__|_destination_address___|
|_dstport_|_destport_|_destination_port______|
|_keyid___|_keyid____|_key_identifier_key_ID_|
+---------+----------+-----------------------+

Variables de paquet de processus paire
+-----------+------------+---------------------+
|_Name______|_Formula____|_Description_________|
+-----------+------------+---------------------+
|_leap______|_leap_______|_leap_indicator______|
|_version___|_version____|_version_number______|
|_mode______|_mode_______|_mode________________|
|_stratum___|_stratum____|_stratum_____________|
|_ppoll_____|_ppoll______|_peer_poll_exponent__|
|_rootdelay_|_delta_r____|_root_delay__________|
|_rootdisp__|_epsilon_r__|_root_dispersion_____|
|_refid_____|_refid______|_reference_ID________|
|_reftime___|_reftime____|_reference_timestamp_|
+-----------+------------+---------------------+

Variables d'horodatage de processus paire
+------+---------+--------------------+
|_Name_|_Formula_|_Description________|
+------+---------+--------------------+
|_org__|_T1______|_origin_timestamp___|
|_rec__|_T2______|_receive_timestamp__|
|_xmt__|_T3______|_transmit_timestamp_|
|_t____|_t_______|_packet_time________|
+------+---------+--------------------+

Variables de statistique de processus paire
+--------+---------+-----------------+
|_Name___|_Formula_|_Description_____|
+--------+---------+-----------------+
|_offset_|_theta___|_clock_offset____|
|_delay__|_delta___|_round-trip_delay|
|_disp___|_epsilon_|_dispersion______|
|_jitter_|_psi_____|_jitter__________|
|_filter_|_filter__|_clock_filter____|
|_tp_____|_t_p_____|_filter_time_____|
+--------+---------+-----------------+

   Les variables de configuration suivantes sont normalement initialisées quand l'association est mobilisée, soit depuis un fichier de configuration ou à l'arrivée du premier paquet pour une association inconnue.

srcaddr adresse IP du serveur distant ou de l'horloge de référence. Devient l'adresse IP de destination dans les paquets envoyés depuis cette association.
srcport Numéro de port UDP du serveur ou de l'horloge de référence. Devient de port de destination dans les paquets envoyés depuis cette association.
dstaddr Adresse IP du client. Devient l'IP source dans les paquets envoyés depuis cette association
dstport Port client, généralement 123. Devient le port source dans les paquets émis depuis cette association.
keyid ID de clé symétrique pour la clé MD5 128-bits utilisés pour générer et vérifier le MAC. Le client et le serveur ou le paire peuvent utiliser différentes valeurs, mais elles doivent mapper la même clé

   Les variables de paquet de processus paire sont mis à jours depuis les en-tête de paquet quand ils arrivent. Elles sont interprétés de la même manière que les variables de paquet de même nom. Il est préférable pour le traitement ultérieur de convertir les valeurs au format NTP court r.rootdelay et r.rootdisp en double flottantes comme variables paires.

   Les variables d'horodatage de processus paire incluent les horodatages échangés par le protocole on-wire. La variable t est le compteur de secondes c.t associé avec ces valeurs. La variable c.t est maintenu par le processus d'ajustement d'horloge décrit plus bas. Il compte les secondes depuis que le service a démarré. Les variables de statistiques incluent les statistiques calculés par la routine clock_filter() décris dans la section suivante. La variable tp est le compteur de seconde associé avec ces valeurs.

Opération de processus paire

   La routine de réception définis le flux de processus jusqu'à l'arrivée d'un paquet. Il n'y a pas de méthode requise pour le contrôle d'accès, bien qu'il est recommandé que les implémentations incluent un tel schéma, qui est similaire à de nombreux autres largement utilisés. La routine access() dans l'appendice décris une méthode d'implémentation des restrictions d'accès en utilisant une ACL. La vérification de format nécessite des longueur de champs et d'alignement corrects, un numéro de version acceptable, et une syntaxe de champs d'extension correct, si présent.

   Il n'y a pas de pré-requis spécifique pour l'authentification; cependant, si l'authentification est implémentée, l'algorithme de hashage MD5 doit être supporté.

   Ensuite, la table d'association est parcouru à la recherche d'une adresses et port source, par exemple en utilisant la routine find_assoc() dans l'appendice. Le tableau ci-dessous est une table dispatch où les colonnes correspondent au mode de paquet et les lignes correspondent au mode d'association. L'intersection de l'association et des modes de paquets dispatche le traitement à une des étapes suivantes.


+------------------+---------------------------------------+
|__________________|______________Packet_Mode______________|
+------------------+-------+-------+-------+-------+-------+
|_Association_Mode_|___1___|___2___|___3___|___4___|___5___|
+------------------+-------+-------+-------+-------+-------+
|_No_Association_0_|_NEWPS_|_DSCRD_|_FXMIT_|_MANY__|_NEWBC_|
|_Symm._Active___1_|_PROC__|_PROC__|_DSCRD_|_DSCRD_|_DSCRD_|
|_Symm._Passive__2_|_PROC__|_ERR___|_DSCRD_|_DSCRD_|_DSCRD_|
|_Client_________3_|_DSCRD_|_DSCRD_|_DSCRD_|_PROC__|_DSCRD_|
|_Server_________4_|_DSCRD_|_DSCRD_|_DSCRD_|_DSCRD_|_DSCRD_|
|_Broadcast______5_|_DSCRD_|_DSCRD_|_DSCRD_|_DSCRD_|_DSCRD_|
|_Bcast_Client___6_|_DSCRD_|_DSCRD_|_DSCRD_|_DSCRD_|_PROC__|
+------------------+-------+-------+-------+-------+-------+

DSCRD Indique une violation non-fatale du protocole résultant d'une erreur de programmation, d'un paquet très retardé, ou paquet rejoué. Le processus paire supprime le paquet s'il existe.
ERR Indique une violation fatale du protocole. Le paire supprime le paquet, démobilise l'association passive symétrique, et quitte.
FXMIT Indique un paquet client (mode 3) ne matchant aucune association (mode 0). Si l'adresse de destination n'est pas une adresse de broadcast, le serveur construit un paquet serveur (mode 4) et le retourne au client sans états retenu. L'en-tête du paquet serveur est construit. Un exemple est décris par la routine fast_xmit() en appendice. L'en-tête est assemblé depuis le paquet reçu et les variables système sont affichés ci-dessous. Si les variables système s.rootdelay et s.rootdisp sont stockés en double flottante, elles doivent être converties au format NTP court avant.


       
+-----------------------------------+
|_Packet_Variable_--›___Variable____|
+-----------------------------------+
|_r.leap________--›_____p.leap______|
|_r.mode________--›_____p.mode______|
|_r.stratum_____--›_____p.stratum___|
|_r.poll________--›_____p.ppoll_____|
|_r.rootdelay___--›_____p.rootdelay_|
|_r.rootdisp____--›_____p.rootdisp__|
|_r.refid_______--›_____p.refid_____|
|_r.reftime_____--›_____p.reftime___|
|_r.keyid_______--›_____p.keyid_____|
+-----------------------------------+

           Noter que si l'authentification échoue, le serveur retourne un message spécial appelé un crypto-NAK. Ce message inclus l'en-tête NTP normal, mais avec un MAC consistant de 4 octets à 0. Le client peut accepter ou rejeter les données dans le message. À la fin de ces actions, le processus paire se termine.

           Si l'adresse de destination est une adresse multicast, l'émetteur opère en mode client manycast. Si le paquet est valide et la strate serveur est inférieur à la strate client, le serveur envoie un paquet serveur ordinaire (mode 4), mais avec sont adresses de destination unicast. Un crypto-NAK n'est pas présent si l'authentification échoue. À la fin de ces actions, le processus paire se termine.

MANY Indique un paquet serveur (mode 4) qui ne matche pas une association. Ordinairement, cela ne se produit qu'en résultat d'un serveur manycast répondant à un paquet client multicast. Si le paquet est valide, une association client ordinaire (mode 3) est mobilisée et l'opération continue comme si l'association était mobilisée par le fichier de configuration.
NEWBC Indique un paquet broadcast (mode 5) ne correspondant pas à une association. Le client mobilise soit une association client (mode 3) ou client broadcast (mode 6). Le paquet est ensuite validée et les variables paires initialisées.

           Si l'implémentation ne supporte pas de sécurité supplémentaire ou de fonctions de calibration, le mode d'association est mis à client broadcast (mode 6), et le processus paire quitte. Les implémentations supportant l'authentification à clé publique peuvent lancer Autokey ou un protocole de sécurité équivalent. Les implémentations devraient définir le mode d'association à 3 et lancer un court échange client/serveur pour déterminer le délai de propagation. En suivant l'échange, le mode d'association est mis à 6 et le processus paire continue en mode écoute uniquement. Noter la distinction entre un paquet mode 6, qui est réservé pour la supervision NTP et aux fonctions de contrôle, et une association mode 6.

NEWPS Indique un paquet actif symétrique (mode 1) ne matchant aucune association. Le client mobilise une association passive symétrique (mode 2). Le traitement continue dans la section PROC
PROC Indique un paquet matchant une association existante. Les horodatages du paquet sont vérifiés pour éviter les paquets invalides, dupliqués ou buggés. Noter que tous les paquets, incluant un crypto-NAK, sont considérés valides seulement s'ils survivent à ces tests.

Vérification d'erreurs de paquet
+--------------------------+----------------------------------------+
|_Packet_Type______________|_Description____________________________|
+--------------------------+----------------------------------------+
|_1_duplicate_packet_______|_The_packet_is_at_best_an_old_duplicate_|
|__________________________|_or_at_worst_a_replay_by_a_hacker.______|
|__________________________|_This_can_happen_in_symmetric_modes_if__|
|__________________________|_the_poll_intervals_are_uneven._________|
|_2_bogus_packet___________|________________________________________|
|_3_invalid________________|_One_or_more_timestamp_fields_are_______|
|__________________________|_invalid._This_normally_happens_in______|
|__________________________|_symmetric_modes_when_one_peer_sends____|
|__________________________|_the_first_packet_to_the_other_and______|
|__________________________|_before_the_other_has_received_its______|
|__________________________|_first_reply.___________________________|
|_4_access_denied__________|_The_access_controls_have_blacklisted___|
|__________________________|_the_source.____________________________|
|_5_authentication_failure_|_The_cryptographic_message_digest_does__|
|__________________________|_not_match_the_MAC._____________________|
|_6_unsynchronized_________|_The_server_is_not_synchronized_to_a____|
|__________________________|_valid_source.__________________________|
|_7_bad_header_data________|_One_or_more_header_fields_are_invalid._|
+--------------------------+----------------------------------------+

   Le traitement continue en copiant la variables de paquet dans les variables paire. Le protocole on-wire calcul le décalage d'horloge theta et le délay delta depuis les 4 horodatages les plus récents tels que décris précédemment. Bien qu'il est en principe possible de faire tous les calculs excepté les différences d'horodatage de premier ordre dans une arithmétique à point fixe, il est plus facile de convertir les différences de premier ordre en double flottante et de faire le reste des calculs avec cette arithmétique.

   Ensuite, le registre p.reach (8-bits) dans le processus d'interrogation est utilisé pour déterminer si le serveur est accessible et que les données sont fraîches. Le registre est décalé à gauche de 1 bit quand un paquet est envoyé et le bit de plus à droite est mis à 0. Quand un paquet valide arrive, le bit de plus à droite est mis à 1. Si le registre contient des bits non-zéro, le serveur est considéré comme accessible; sinon, il est inaccessible. Vu que l'intervalle d'interrogation paire peut avoir changé depuis le dernier paquet, l'intervalle d'interrogation hôte est revu.

La statistique de dispersion epsilon(t) représente l'erreur maximum dûe à la tolérance de fréquence et le temps depuis que le dernier paquet a été envoyé. Il est initialisé:
epsilon(t_0) = r.rho + s.rho + PHI    *    (T4-T1)

   Quand la mesure est faite à t_0 en accord avec le compteur de secondes. Ici, r.rho est la précision de paquet et s.rho est la précision système, exprimés en secondes. Ces termes sont nécessaire pour compter les incertitudes en lisant l'horloge système dans le serveur et le client.

   La dispersion grandit ainsi au taux constant PHI; en d'autres termes, au temp t, epsilon(t) = epsilon(t_0) + PHI addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo (t-t_0). Avec la valeur par défaut PHI = 15 ppm, cette quantité est d'environ 1,3 secondes par jour. L'argument t sera supprimé et la dispersion représentée simplement avec epsilon. Les statistiques restantes sont calculées par l'algorithme de filtre d'horloge décris dans la section suivante.

Algorithme de filtre d'horloge

   L'algorithme de filtre d'horloge fait partie du processus paire. Il gère le flux de données on-wire pour sélectioner les échantillons le mieux possible pour représenter le temps précis. L'algorithme produit les variables affiché dans le tableau des variables de statistiques de processus paire, incluant offset (theta), délai (delta), dispersion (epsilon), jitter (psi), et le temps d'arrivée (t). Ces données sont utilisées par les algorithmes de mitigation pour déterminer le meilleur offset final utilisé pour la discipline d'horloge. Elles sont également utilisées pour déterminer la santé du serveur et s'il est acceptable pour la synchronisation.

   L'algorithme de filtre d'horloge sauve l'échantillon le plus récent (theta, delta, epislon, t) dans la structure de filtre, qui fonctionne comme un registre 8 étapes. Ces échantillons sont sauvé dans l'ordre d'arrivée des paquets. Ici, t est le temps auquel le paquet est arrivé en accord avec le compteur de seconde et ne devrait pas être confondu avec la variable paire tp.

   Le schéma suivant est utilisé pour s'assurer que les échantillons suffisants sont dans le filtre et que les anciennes données sont enlevées. Initialement, ces échantillons sont par défaut (0, MAXDISP, MAXDISP, 0). Quand un paquet valide arrive, les données dons décalés dans le filtre. Si les 3 bits LSB du registre sont à 0, indiquant 3 intervals d'interrogation, sont expirés sans paquet valide reçus, le processus paire appel l'algorithme de filtre d'horloge avec un faux échantillon. Se cela persiste pour 8 intervals d'interrogation, le registre retourne à la condition initiale.

   Dans l'étape suivante, les étapes son copiés dans une liste temporaire et la liste triée en augmentant le delta. Disons i index des étapes commençant avec le delta le plus bas. Si le premier échantillon epoch t_0 n'est pas ultérieur au denier sampe valide epoch tp, la routine quitte sant affecter les variables de paire courant. Sinon, donnons epsilon_i la dispersion de la i-ème entrée, donc:


_______________i=n-1
_______________---_____epsilon_i
epsilon_=_______\_____----------
________________/________(i+1)
_______________---_____2
_______________i=0

   Est la dispersion paire p.disp.

   noter que si toutes les étapes contiennent l'échantillon par défaut avec la dispersion MAXDISP, la dispersion calculée est un peu inférieur à 16 secondes. Chaque fois qu'un échantillon valide est décalé dans le registre, la dispersion se réduit par un peut moins que la moitié, en fonction de la dispersion valide. Après 4 paquets valides la dispersion est généralement inférieur à 1 seconde.

   Il est important de noter que, à la différence de NTPv3, les associations NTPv4 n'affichent pas de condition de timeout en définissant la strate à 16 et l'indicateur leap à 3. Les variables d'association retiennent les valeurs déterminées à l'arrivée du dernier paquet.

Processus système

   Vu que chaque échantillon (theta, delta, epsilon, jitter, t) est produit par l'algorithme de filtre d'horloge, tous les processus paire sont scannés par les algorithmes de mitigation consistant des algorithme de sélection, cluster, combinaison, et de discipline d'horloge dans le processus système. L'algorithme de sélection scanne toutes les associations et suppriment les sources de temps incorrect. Dans une série de cycles, l'algorithme cluster supprime l'association statistiquement la plus éloignée du barycentre jusqu'au nombre minimum de survivant. L'algorithme combine produit les meilleurs statistiques finales. L'offset final est passé à l'algorithme de discipline d'horloge pour diriger l'horloge système au temps correct.

   L'algorithme cluster sélectionne un des survivants comme paire système. Les statistiques associées (theta, delta, epsilon, jitter, t) sont utilisées pour construire les variables système héritées pas les serveurs et clients dépendants et sont disponibles aux autres applications tournant sur la même machine.

Variables de processus système

Les noms communs, noms de formules et descriptions courte de chaque variables système sont:
+-----------+------------+------------------------+
|_Name______|_Formula____|_Description____________|
+-----------+------------+------------------------+
|_t_________|_t__________|_update time____________|
|_p_________|_p__________|_system peer identifier_|
|_leap______|_leap_______|_leap indicator_________|
|_stratum___|_stratum____|_stratum________________|
|_precision_|_rho________|_precision______________|
|_offset____|_THETA______|_combined offset________|
|_jitter____|_PSI________|_combined jitter________|
|_rootdelay_|_DELTA______|_root delay_____________|
|_rootdisp__|_EPSILON____|_root dispersion________|
|_v_________|_v__________|_survivor list__________|
|_refid_____|_refid______|_reference ID___________|
|_reftime___|_reftime____|_reference time_________|
|_NMIN______|_3__________|_minimum survivors______|
|_CMIN______|_1__________|_minimum candidates_____|
+-----------+------------+------------------------+

   Excepté pour les variables t, p, offset, et jitter et pour les constantes NMIN et CMIN, les variables ont le même format et interprétation que les variables paires de même nom. Les paramètres NMIN et CMIN sont utilisées par les algorithme de sélection et de cluster décris dans la section suivante.

   La variable t est le compteur de secondes au temps de la dernière mises à jours. La variable p est l'identifiant du paire système déterminé par la routine cluster() plus bas dans ce document. La variable precision est définie aussi large que la résolution et de temps pour lire l'horloge, en unité log2. Par exemple, la précision de l'horloge à fréquence courante s'incrémentant à 60Hz est 16ms, même quand le hardware est en nanosecondes.

   Les variables offset et jitter sont déterminée par l'algorithme combine. Ces valeurs représentent le meilleur offset finals et le jitter utilisé pour la discipline d'horloge système. Initialement, toutes les variables sont à 0, puis le leap est mis à 3 (désynchronisé), et la strate est à MAXSTRAT (16). Se rappeler que MAXSTRAT est mappé à 0 dans le paquet transmit.

Opérations de processus système

   La figure ci-dessous décris les opérations du processus système effectué par la routine de sélection d'horloge. L'algorithme de sélection produit une clique de majorité des candidats présumés correcte (truechimers) basés sur les principes d'agréments. L'algorithme cluster supprime les aberrants pour produire les survivants les plus précis. L'algorithme combine fournis le meilleur offset final pour l'algorithme de discipline d'horloge. Si l'algorithme de sélection ne peut pas produire une clique de majorité, ou s'il ne peut pas produire au moins CMIN survivants, le processus système s'arrête sans discipliner l'horloge. En cas de succès, l'algorithme cluster sélectionne le meilleur candidat comme paire système et ses variables sont hérités comme variables système.

Routine de sélection d'horloge:
_______________________+-----------------+
_______________________|_clock_select()__|
_______________________+-----------------+
................................|...........
._______________________________V__________.
.______yes_+---------+_+-----------------+_.
._______+--|_accept?_|_|_scan_candidates_|_.
._______|__+---------+_|_________________|_.
._______V________no_|__|_________________|_.
.__+---------+______|__|_________________|_.
.__|_add_peer|______|__|_________________|_.
.__+----------______|__|_________________|_.
._______|___________V__|_________________|_.
._______+----------›--›|_________________|_.
.______________________|_________________|_.
._Selection_Algorithm__+-----------------+_.
.................................|..........
_________________________________V
____________________no_+-------------------+
_________+-------------|_____survivors?____|
_________|_____________+-------------------+
_________|_______________________|_yes
_________|_______________________V
_________|_____________+-------------------+
_________|_____________|_Cluster_Algorithm_|
_________|_____________+-------------------+
_________|_______________________|
_________|_______________________V
_________V_________yes_+-------------------+
_________|‹------------|_____n_‹_CMIN?_____|
_________|_____________+-------------------+
_________V_______________________|
__+-----------------+____________V_no
__|___s.p_=_NULL____|__+-------------------+
__+-----------------+__|___s.p_=_v_0.p_____|
_________|_____________+-------------------+
_________V_______________________|
__+-----------------+____________V
__|_return_(UNSYNC)_|__+-------------------+
__+-----------------+__|___return_(SYNC)___|
_______________________+-------------------+

Algorithme de sélection

   Noter que les algorithmes de sélection et de cluster sont décris séparemment, mais combinés dans un code squelette. L'algorithme de sélection opère pour trouver un interval d'intersection contenant une clique de majorité de truechimers en utilisant les principes d'accord Bisantine originellement proposé par Marzullo, mais modifié pour améliorer la précision.

   D'abord, les serveurs non utilisable en accord avec les règles du protocole sont détectés et supprimés. Ensuite, un jeu de tuples (p, type, edge) est généré pour les candidats restants. Ici, p est l'identifiant d'association et le type identifie les point supérieur (+1), moyen (0) et inférieur (-1) d'un interval de correction centré sur theta pour ce candidat. Ces 3 tuples lowpoint (p, -1, theta - lambda), midpoint (p, 0, theta) et highpoint (p, +1, theta + lambda), où lambda est la distance de synchronisation root. Les étapes de l'algorithme sont:

1. Pour chaque associations de m, place 3 tuples comme définis ci-dessus dans la liste des candidats
2. Trie les tuples dans la liste par le composant edge. Définis le nombre de falsetickers f = 0
3. Définis le nombre de midpoints d = 0, définis c = 0. Scanne du endpoint le plus bas vers le plus haut. Ajoute 1 à c pour chaque lowpoint, soustrait 1 pour chaque highpoint, ajoute 1 à d pour chaque midpoint. Is c ›= m - f, stoppe, définis l = lowpoint courant.
4. Définis c = 0. Scanne du endppoint le plus haut vers le plus bbas. Ajoute 1 à c pour chaque endpoint, soustrait 1 pour chaque lowpoint, ajoute 1 à d pour chaque midpoint. Si c ›= m - f, stop, définis u = highpoint courant.
5. Est-ce que d = f et l ‹ u ? Si oui, passe à l'étable 5A, sinon 5B
5A L'interval d'intersection est [ l, u ]
5B Ajoute 1 à f. f ‹ ( m / 2 )? si oui retourne à l'étape 3, sinon va à l'étape 6
6 Erreur, une clique de majorité ne peut être trouvé.

   Noter que l'algorithme démarre avec la supposition qu'il n'y a pas de falsetickers ( f = 0 ) et tente de trouver un interval d'intersection non-vide contenant les midpoint de tous les serveurs correctes, par ex. truechimers. Si un interval non-vide ne peut être trouvé, il augmente le nombre de falsetickers de 1 et retente. Si un interval non-vide est trouvé et que le nombre de falsetickers est inférieurs au nombre de truechimers, une clique de majorité a été trouvé et le midpoint de chaque truechimers (theta) représente les candidats disponibles à l'algorithme cluster.

   Si une clique de majorité n'est pas trouvée, ou si le nombre de truechimers est inférieur à CMIN, il y a une insuffisance de candidats. CMIN définis le nombre mininum de serveurs consistants avec les pré-reques de correction. Les opérateurs suspicieux peuvent définir CMIN pour s'assurer que plusieurs serveurs redondants soient disponibles pour les algorithmes de mitigation. Cependant, pour des raisons historiques, la valeur par défaut de CMIN est 1.

Algorithme cluster

   Les candidats du clique de majorité sont placés dans la liste de survivant v sous la forme de tuples (p, theta_p, psi_p, lambda_p), où p est un identifiant d'association, theta_p, psi_p, et stratum_p l'offset, jitter et strate courant de l'association p, respectivement, et lambda_p est un facteur de mérite égal à stratum_p addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo MAXDIST + lambda, où lambda est la distance de synchronisation root pour l'association p. La liste est traitée par l'algorithme cluster:

1. donnons (p, theta_p, psi_p, lambda_p) représentant un candidat survivant
2. Trie les candidats en augmentant lambda_p. n est le nombre de candidats et NMIN le nombre minimum requis de survivants
3. Pour chaque candidat, calculer le jitter de sélection psi_s:


________+-----_______________________-----+^1/2
________|________n-1______________________|
________|________---______________________|
________|___1____\_____________________2__|
psi_s_=_|_----_*_/__(theta_s_-_theta_j)___|
________|__n-1___---______________________|
________|________j=1______________________|
________+-----_______________________-----+

4. Sélectionne psi_max comme candidat avec psi_s maximum
5. Sélection psi_min comme candidat avec psi_p minimum
6. psi_max ‹ psi_min ou n ‹= NMIN ? Si oui, passe à 6A, sinon 6B
6A. Fait. Les candidats suivants dans la liste survivor sont placés dans l'ordre de préférence. La première entrée représente le paire système; ses variables sont utilisée pour mettre à jours les variables système.
6B. Supprime les candidats avec psi_max; réduit n de 1 et retourne à l'étape 3.

Algorithme Combine

   L'algorithme traite les survivants restants pour produire la meilleur donnée finale pour l'algorithme de discipline d'horloge. La routine traite l'offset paire et les statistiques jitter pour produire l'offset système THETA et le jitter paire système PSI_p, où chaque statistique serveur a un poids par le réciproque de la distance de synchronisation root et le résultat est normalisé.

   Le THETA combiné est passé à la routine de mise à jours d'horloge. Le premier candidat dans la liste de survivants est nomminé comme paire système avec l'identifiant p. Le jitter paire système PSI_p est un composant du jitter système PSI. Il est utilisé avec le jitter de sélection PSI_s pour produire le jitter système: PSI = [(PSI_s)^2 + (PSI_p)^2]^1/2

   Chaque fois qu'une mise à jours est reçue du paire système, la routine de mise à jours de l'horloge est appelée. Par règle, une mise à jours est supprimée si son temps d'arrivée p.t n'est pas strictement ultérieur à la dernière mise à jours s.t. Les labels IGNOR, PANIC, ADJ et STEP réfèrent aux codes de retour de la routine d'horloge locale décrite dans la section suivante.

   IGNORE signifie que la mise à jours a été ignorée. PANIC signifie que l'offset est supérieur à seuil PANICT (1000 s) et devrait forcer le programme à quitter avec un message de diagnostique. STEP signifie que l'offset est inférieur au seuil de panique, mais supérieur au seuil d'étape (125 ms). Dans ce cas, l'horloge est décalé à l'offset correcte, mais vu que cela signifie que toute les données paire ont été invalidées, toutes les associations doivent être réinitialisées et le client recommande à l'état initial.

   ADJ signifie que l'offset est inférieur au seuil d'étape et donc une mise à jours valide. Dans ce cas, les variables système sont mises à jours depuis les variables paire:


+-------------------------------------------+
|_System_Variable_‹--_System_Peer_Variable__|
+-------------------------------------------+
|_s.leap______‹--_p.leap____________________|
|_s.stratum___‹--_p.stratum_+_1_____________|
|_s.offset____‹--_THETA_____________________|
|_s.jitter____‹--_PSI_______________________|
|_s.rootdelay_‹--_p.delta_r_+_delta_________|
|_s.rootdisp__‹--_p.epsilon_r_+_p.epsilon_+_|
|_________________p.psi_+_PHI_*_(s.t_-_p.t)_|
|_________________+_|THETA|_________________|
|_s.refid_____‹--_p.refid___________________|
|_s.reftime___‹--_p.reftime_________________|
|_s.t_________‹--_p.t_______________________|
+-------------------------------------------+

   Il y a un détail important non affiché. L'incrément de dispersion (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) est délimité par le bas par MINDISP. Dans les sous-réseaux avec des processeurs très rapide et des réseaux avec des délais et une dispersion très petits cela force un augmentation monotonique dans s.rootdisp (EPSILON), qui évite les boucle entre les paires opérants dans la même strate.

   Les variables système sont disponible aux programmes d'application comme statistiques de performance nominale. L'offset système THETA est l'offset d'horloge relative aux sources de synchronisation disponibles. Le jitter système PSI est une estimation de l'erreur en déterminant cette valeur, appelé ailleurs l'erreur attendue. Le délais root DELTA est le délais round-trip total relatif au serveur primaire. La dispersion root EPSILON est la dispersion accumulée sur le réseau depuis le serveur primaire. Finalement, la distance de synchronisation root est définie

  LAMBDA = EPSILON + DELTA / 2

  qui représente l'erreur maximum du à toutes les causes et est désignée comme étant la distance de synchronisation root.

Algorithme de discipline d'horloge

   L'algorithme de discipline d'horloge, racourcis à discipline dans la suite, fonctionne comme une combinaison de 2 sytèmes de contrôle de feedback philosophiquement différents. Dans un boucle phase-locked (PLL), la mise à jours de phase périodique aux intervals de mises à jours mu secondes sont utilisés directement pour minimiser l'erreur de temps et indirectement l'erreur de fréquence. Dans une boucle frequency-locked (FLL), les mises à jours de fréquence périodiques aux intervals mu sont utilisé directement pour minimiser l'erreur de fréquence et indirectement l'erreur de temps. PLL fonctionne généralement mieux quand le jitter réseau domine, alors que FLL dessine de fonctionnement de NTPv4.

   La discipline est implémentée comme système de contrôle feedback. La variable theta_r représente l'offset de l'algorithme combine (phase référence) et theta_c l'offset VFO (phase contrôle). Chaque mise à jours produit un signal V_d représentant la différence de phase instantannée theta_r -theta_c. Le filtre d'horloge pour chaque serveur fonctionne comme une ligne de retard, avec la sortie prise au retard sélectionné par l'algorithme de filtre d'horloge. Les algorithmes de sélection, cluster, et combine combinent les données depuis plusieurs filtres pour produire le signal V_s. Le filtre loop, avec réponse impulsionnelle F(t), produit le signal V_c, qui contrôle la fréquence VFO omega_c et donc l'intégral de la phase theta_c qui ferme la boucle. Le signal V_c est généré par le processus d'ajustement d'horloge.


____theta_r_+_+---------\________+----------------+
NTP_---------›|__Phase___\__V_d__|________________|_V_s
____theta_c_-_|_Detector__------›|__Clock_Filter__|----+
____+--------›|__________/_______|________________|____|
____|_________+---------/________+----------------+____|
____|__________________________________________________|
__-----________________________________________________|
_/_____\_______________________________________________|
_|_VFO_|_______________________________________________|
_\_____/_______________________________________________|
__-----____......................................._____|
____^______.____________Loop_Filter______________._____|
____|______._+---------+___x__+-------------+____._____|
____|_V_c__._|_________|‹-----|_____________|____._____|
____+------.-|__Clock__|___y__|_Phase/Freq__|‹---------+
___________._|_Adjust__|‹-----|_Prediction__|____.
___________._|_________|______|_____________|____.
___________._+---------+______+-------------+____.
___________.......................................

   Ordinairement, la boucle feedback pseudo-linéaire décrite ci-dessus opère pour discipliner l'horloge système. Cependant, il y a des cas où un algorithme non-linéaire offre une amélioration considérable. Un cas est quand la discipline commence sans connaissance de la fréquence d'horloge intrinsèque. La boucle pseudo-linéaire prend des heures pour développer une mesure précise et durant ce temps l'interval d'intérrogation ne peut être être augmenté. La boucle non-linéaire décrite ci-dessous le fait en 15 minutes. Un autre cas est quand les salves occasionnelles de grand jitters sont présent à cause de liens réseaux congestionnés. L'état machine décrite ci-dessous résiste à ces erreus restant inférieur à 15 minutes.

   Ce tableau contient un sommaire des variables et paramètres incluant le nom de variable (minuscule) ou paramètre (majuscule), nom de formule, et description courte. Sauf mention, toutes variables ont le préfixe assumé c. Les variable t, tc, state, hyster, et count sont des entier; le reste des double flottants. La fonction de chacun est expliqué dans les descriptions d'algorithme dessous.


+--------+------------+--------------------------+
|_Name___|_Formula____|_Description______________|
+--------+------------+--------------------------+
|_t______|_timer______|_seconds_counter__________|
|_offset_|_theta______|_combined_offset__________|
|_resid__|_theta_r____|_residual_offset__________|
|_freq___|_phi________|_clock_frequency__________|
|_jitter_|_psi________|_clock_offset_jitter______|
|_wander_|_omega______|_clock_frequency_wander___|
|_tc_____|_tau________|_time_constant_(log2)_____|
|_state__|_state______|_state____________________|
|_adj____|_adj________|_frequency_adjustment_____|
|_hyster_|_hyster_____|_hysteresis_counter_______|
|_STEPT__|_125________|_step_threshold_(.125_s)__|
|_WATCH__|_900________|_stepout_thresh(s)________|
|_PANICT_|_1000_______|_panic_threshold_(1000_s)_|
|_LIMIT__|_30_________|_hysteresis_limit_________|
|_PGATE__|_4__________|_hysteresis_gate__________|
|_TC_____|_16_________|_time_constant_scale______|
|_AVG____|_8__________|_averaging_constant_______|
+--------+------------+--------------------------+

   Le processus se termine immédiatement si l'offset est supérieur au seuil panic PANICT (1000 s). Le tableau suivant montre la fonction de transition d'état utilisé par la routine rstclock() décrite en annexe. Elle a 4 colonnes montrant respectivement le nom d'état, prédicat et action si l'offset theta est inférieur au seuil d'étape, le prédicat et les actions sinon, et finalement des commentaires.


+-------+---------------------+-------------------+--------------+
|_State_|_theta_‹_STEP________|_theta_›_STEP______|_Comments_____|
+-------+---------------------+-------------------+--------------+
|_NSET__|_-›FREQ______________|_-›FREQ____________|_no_frequency_|
|_______|_adjust_time_________|_step_time_________|_file_________|
+-------+---------------------+-------------------+--------------+
|_FSET__|_-›SYNC______________|_-›SYNC____________|_frequency____|
|_______|_adjust_time_________|_step_time_________|_file_________|
+-------+---------------------+-------------------+--------------+
|_SPIK__|_-›SYNC______________|_if_‹_900_s_-›SPIK_|_outlier______|
|_______|_adjust_freq_________|_else_-›SYNC_______|_detected_____|
|_______|_adjust_time_________|_step_freq_________|______________|
|_______|_____________________|_step_time_________|______________|
+-------+---------------------+-------------------+--------------+
|_FREQ__|_if_‹_900_s_-›FREQ___|_if_‹_900_s_-›FREQ_|_initial______|
|_______|_else_-›SYNC_________|_else_-›SYNC_______|_frequency____|
|_______|_step_freq___________|_step_freq_________|______________|
|_______|_adjust_time_________|_adjust_time_______|______________|
+-------+---------------------+-------------------+--------------+
|_SYNC__|_-›SYNC______________|_if_‹_900_s_-›SPIK_|_normal_______|
|_______|_adjust_freq_________|_else_-›SYNC_______|_operation____|
|_______|_adjust_time_________|_step_freq_________|______________|
|_______|_____________________|_step_time_________|______________|
+-------+---------------------+-------------------+--------------+

   Dans les entrées de la table, l'état suivant est identifié par la flèche -› avec les action listées en dessous. Les actions tel que ajuster le temps et ajuster la fréquence sont implémentée par la boucle feedback PLL/FLL dans la routine local_clock(). Une action étape d'horloge est implémentée en définissant l'horloge directement, mais c'est fait seulement après que le seuil stepout WATCH (900s) quand l'offset est supérieur au seui d'étape STEPT (.125s). Cela résiste aux étapes d'horloge sous conditions de congestion réseau extrême.

   Les statistiques jitter (psi) et wander (omega) sont calculées en utilisant une moyenne exponentielle avec un facteur de poit AVG. L'exposant de constante de temps (tau) est déterminée en comparant psi avec la magnitude de l'offset courant theta. Si l'offset est supérieur à PGATE (4) fois le jitter d'horloge, le compteur hysteresis est réduit par 2; sinon, il est incrémenté de 1. Si hyster augmente à la limite supérieur LIMIT (30), tau est incrémenté de 1; s'il est diminué à la limite basse -LIMIT (-30), tau est décrémenté de 1. Normalement, tau plane autour de MAXPOLL, mais diminue rapidement si un pique de température provoque un saut de fréquence.

Processus l'ajustement d'horloge

   Le processus d'ajustement d'horloge tourne à interval d'une seconde pour ajouter une correction de fréquence et un pourcentage fixé d'offset theta_r résiduel. theta_r est la décroissance exponentielle de la valeur theta produite par le filtre loop à chaque mise à jours. Le paramètre TC échelonne la constante de temps pour correspondre à l'interval d'interrogation. Noter que la dispersion EPSILON augmente de PHI à chaque seconde.

   Le processus d'ajustement d'horloge inclus une facilité d'interruption de timer pilotant le compteur de secondes c.t. Il commence à 0 quand le service démarre et augmente à chaque seconde. À chaque interruption, la routine chock_adjust() est appelée pour incorporer les ajustement de temps et de fréquence de discipline d'horloge, puis les associations sont scannées pour déterminer si le compteur de secondes égal ou excède la variable d'état p.next définis dans la section suivante. Si c'est le cas, le processus d'interrogation est appelé pour envoyer un paquet et calculer la prochaine valeur p.next.

Processus d'interrogation

   Chaque association supporte un processus d'interrogation qui est lancé à interval régulier pour construire et envoyer des paquets dans les associations symétrique, client, et serveur broadcast. Il tourne en continue, que le serveur soit accessible ou non pour pouvoir gérer le filtre d'horloge.

Variables de processus d'interrogation

   Le tableau ci-dessous décris les noms communs, noms de formule, et une courte description des variables de processus paire et paramètres. Sauf mention, toutes les variables sont assumé avec le préfixe p.


+---------+---------+--------------------+
|_Name____|_Formula_|_Description________|
+---------+---------+--------------------+
|_hpoll___|_hpoll___|_host_poll_exponent_|
|_last____|_last____|_last_poll_time_____|
|_next____|_next____|_next_poll_time_____|
|_reach___|_reach___|_reach_register_____|
|_unreach_|_unreach_|_unreach_counter____|
|_UNREACH_|_24______|_unreach_limit______|
|_BCOUNT__|_8_______|_burst_count________|
|_BURST___|_flag____|_burst_enable_______|
|_IBURST__|_flag____|_iburst_enable______|
+---------+---------+--------------------+

   Les variables sont allouées dans la structure de données d'association avec les variables de processus paire. La suite est une description détaillée de ces variables.

hpoll entier signé représentant l'exposant d'interrogation, en secondes log2
last Entier représentant le compteur de secondes quand le paquet le plus récent a été envoyé
next Entier représentant le compteur de secondes quand le prochain paquet doit être envoyé
reach registre entier 8-bits partagé par les processus paire et d'interrogation.
unreach Entier représentant le nombre de secondes que le serveur a été inaccessible

Opérations du processus d'interrogation

   Comme décris précédemment, une fois par seconde le processus d'ajustement d'horloge est apperé. Cette routine appel la routine d'interrogation pour chaque association en retour. Si le temps du message poll suivant est supérieur au compteur de secondes, la routine retourne immédiatement. Les associations symétriques ( modes 1,2), client (mode 3) et serveur broadcast (mode 5) envoient des paquets de façon routinière. Une association client broadcast (mode 6) lance la routine pour mettre à jours les variables reach et unreach, mais n'envoient pas de paquets. Le processus d'interrogation appel le processus de transmission pour envoyer un paquet. Si c'est dans un burst (burst › 0), rien d'autre n'est fait excepté l'appel à la routine de mise à jours d'interrogation pour définis le prochain interval d'interrogation.

   Si ce n'est pas dans un burst, la variable reach est décalée à gauche de 1 bit avec un 0 remplaçant le bit de plus à droite. Si le serveur n'a pas été entendu les 3 derniers intervals d'interrogation, la routine de filtre d'horloge est appelée pour augmenter la dispersion.

   Si le flag BURST est mis et le serveur est accessible et une source valide de synchronisation est disponible, le client envoie un burst de BCOUNT (8) paquets à chaque interval d'interrogation. L'interval entre les paquets dans le burst est de 2 secondes. C'est utile pour mesurer le jitter précisément avec les intervals d'interrogation long. Si le flag IBURST est mis et que c'est le premier paquet envoyé quand le serveur a été inaccessible, le client envoie un burst. C'est utile pour rapidement réduire la distance de synchronisation sous le seuil de distance et synchroniser l'horloge.

   Si le flag P_MANY est mis dans le mot p.flags de l'association, c'est une association client manycast. Les associations client manycast envoyent des paquets mode client pour désigner des adresses de groupe multicast à l'interval MINPOLL. L'association commence avec un TTL de 1. Si au moment de l'interrogation suivante il y a moins de MINCLOCK serveurs mobilisés, le ttl est augmenté de 1. Si le ttl atteint la limite TTLMAX, sans trouver MINCLOCK serveurs, l'interval d'interrogation est augmenté jusqu'à atteindre BEACON.

   La routine poll() inclus une fonctionnalité qui revient à l'interval de poll si le serveur devient indisponible. Si reach est non-zéro, le serveur est accessible et unreach est mis à 0; sinon, unreach est incrémenté de 1 pour chaque interrogation jusqu'au max UNREACH. Ensuite, pour chaque interrogation hpoll est augmenté de 1, qui double l'interval de poll jusqu'au maximum MAXPOLL déterminé par la routine poll_update(). Quand le serveur redevient accessible, unreach est mis à 0, hpoll est réinitialisé à la variable système tc, et l'opération reprend normalement.

   Un paquet est envoyé par de processus de transmission. Certaines valeurs d'en-tête sont copiées depuis la variable paire laissée par le paquet précédent et d'autres depuis les variables système. Le tableau ci-dessous montre quelles valeurs sont copiées pour chaque champ d'en-tête. Dans ces implémentations, en utilisant les types de données double flottante pour le délai root et la dispersion root, elles doivent être converties au format court NTP. Tous les autres champs sont soit copiés tels quels depuis le paire et les variables système ou marqués comme horodatage depuis l'horloge système.


+-----------------------------------+
|_Packet_Variable_‹--___Variable____|
+-----------------------------------+
|_x.leap________‹--_____s.leap______|
|_x.version_____‹--_____s.version___|
|_x.mode________‹--_____s.mode______|
|_x.stratum_____‹--_____s.stratum___|
|_x.poll________‹--_____s.poll______|
|_x.precision___‹--_____s.precision_|
|_x.rootdelay___‹--_____s.rootdelay_|
|_x.rootdisp____‹--_____s.rootdisp__|
|_x.refid_______‹--_____s.refid_____|
|_x.reftime_____‹--_____s.reftime___|
|_x.org_________‹--_____p.xmt_______|
|_x.rec_________‹--_____p.dst_______|
|_x.xmt_________‹--_____clock_______|
|_x.keyid_______‹--_____p.keyid_____|
|_x.digest______‹--_____md5_digest__|
+-----------------------------------+

   La routine de mise à jours d'interrogation est appelée quand un paquet valide est reçus et immédiatement après qu'un message poll ait été envoyé. Si dans un burst, l'intervalle d'interrogation est fixé à 2 secondes; sinon, l'exposant de poll de l'hôte hpoll est mis au minimum de ppoll depuis le dernier paquet reçu et hpoll depuis la routine d'interrogation, mais entre MINPOLL et MAYPOLL. Donc, la discipline d'horloge peut être suréchantillonée mais pas sous-échantillonée. C'est nécessaire pour préserver le fonctionnement dynamique de sous-réseaux et pour protéger contre les erreurs de protocole.

   L'exposant poll est convertis à un interval, qui, quand ajouté à la variable de dernier temps d'interrogation, détermine la valeur de la variable de temps de prochain interrogation. Finalement, la variable de temps de dernière interrogation est mis au compteur de secondes courante.

Simple NTP

   Les serveur primaires et les clients conforme avec un sous-jeu de NTP, appelé SNTPv4 (rfc4330), n'ont pas besoin d'implémenter les algorithmes de mitigation. SNTP est prévu pour les serveurs primaires équipés avec une seule référence d'horloge, et les clients avec un seul serveur et sans clients dépendants. L'implémentation NTPv4 est prévue pour les serveurs secondaires avec plusieurs serveurs montants et plusieurs clients descendants ou clients. Un serveur primaire SNTP implémentant le protocole on-wire n'a pas de serveurs upstream excepté une seule horloge de référence. En principe, c'est indistinguable d'un serveur primaire NTP qui a les algorithmes de mitigation et donc capable de mitiger entre plusieurs horloges de référence.

   À la réception d'une requête cliente, un serveur primaire SNTP construit et envoie le paquet de réponse décris ci-dessous. Noter que le champs dispersion dans l'en-tête de paquets doit être mis à jours:


+-----------------------------------+
|_Packet_Variable_‹--___Variable____|
+-----------------------------------+
|_x.leap________‹--_____s.leap______|
|_x.version_____‹--_____r.version___|
|_x.mode________‹--_____4___________|
|_x.stratum_____‹--_____s.stratum___|
|_x.poll________‹--_____r.poll______|
|_x.precision___‹--_____s.precision_|
|_x.rootdelay___‹--_____s.rootdelay_|
|_x.rootdisp____‹--_____s.rootdisp__|
|_x.refid_______‹--_____s.refid_____|
|_x.reftime_____‹--_____s.reftime___|
|_x.org_________‹--_____r.xmt_______|
|_x.rec_________‹--_____r.dst_______|
|_x.xmt_________‹--_____clock_______|
|_x.keyid_______‹--_____r.keyid_____|
|_x.digest______‹--_____md5_digest__|
+-----------------------------------+

   Un client SNTP implémentant le protocole on-wire a un simple serveur et aucun client dépendants. Il peut opérer avec un sous-jeu du protocole NTP on-wire, l'approche la plus simple en utilisant seulement la date de transmission du paquet serveur et en ignorant tous les autres champs. Cependant, la complexité additionnelle pour implémenter le protocole on-wire est minimale donc l'implémentation complète en encouragée.

Considérations de sécurité

   Les exigences de sécurité NTP sont plus stricts que d'autres services distribués. D'abord, l'opération du mécanisme d'authentification et le mécanisme de synchronisation de temps sont inextricablement liés. La synchronisation de temps fiable exige des clé cryptographiques qui sont valides seulement dans un interval de temps définis; mais, les intervals de temps peuvent être forcés seulement quand les serveurs et client participants sont synchronisés à UTC.

   Un client NTP peut prétendre avoir un temps authentique pour les applications dépendantes seulement si tous les serveurs dans le chemin vers les serveurs primaires sont authentifiés. Dans NTP chaque serveur NTP authentifie les serveurs de strate inférieur. Il est important de noter que l'authentification dans le contexte de NTP n'implique pas nécessairement que le temps est correct. Un client NTP mobilise un nombre d'associations concurrentes avec des serveurs différents et utilise un algorithme d'accord pour supprimer les serveurs non viables.

   La spécification NTP assume que le but d'une intrusion est d'injecter des valeurs de temps fausses, perturber le protocole, ou obstruer le réseau, serveurs, ou clients. Il y a des mécanismes de défense déjà présents dans l'architecture NTP, protocole, et algorithmes. L'échange on-wire est résistant au spoofing, perte de paquet, et attaques replay. Les algorithmes de filtre d'horloge, sélection, et cluster sont conçus pour défendre contre les mauvais cliques de traitres byzantins. Cependant, ces mécanismes n'identifient pas ni n'authentifie de manière sûr les serveurs auprès des clients. Sans d'autres protections, un attaquant peut injecter une de ces attaques:

1. Intercepter et archiver des paquets, et toutes les valeurs publique générées et transmises sur le réseau.
2. Génerer des paquets plus vite que le serveur, réseau, ou client en peut les traiter
3. Dans une attaque wiretap, l'attaquant peut intercepter, modifier, et rejouer un paquet. Cependant il ne peut pas empêcher la transmission du paquet original.
4. Dans une attaque MITM ou masquerade, l'attaquant est positionné entre le serveur et le client, donc il peut intercepter, modifier, et rejouer un paquet et empêcher la transmission du paquet original. Cependant, il ne possède pas le clés privées.

   Le modèle de sécurité NTP assume les limitation possibles suivantes:

1. Le temps de fonctionnement pour les algorithmes à clé publique sont relativement longs et variables. En général, les performances de synchronisation de temps sont dégradés si ces algorithmes doivent être utilisé pour chaque paquet NTP.
2. Dans certains modes d'opération, il n'est pas possible pour un serveur de conserver les variables d'état pour chaque client. Il est cependant possible de les régénérer pour un client à l'arrivée d'un paquet de ce client.
3. La durée de vie des valeurs cryptographiques doivent être renforcés, qui nécessite un source d'horloge fiable. Cependant, les sources qui synchronisent l'horloge système doivent être trustés. Cette interdépendance circulaire nécessite une gestion particulière
4. Les fonctions de sécurité client doivent impliquer seulement des valeurs publiques transmis sur le réseaux. Les valeurs privées ne doivent pas être révélés en dehors de la machine qui les a créés, excepté dans le cas d'un agent de confiance spécial.

   À la différence du modèle de sécurité SSH, où le client doit être authentifié au serveur, dans NTP le serveur doit être authentifié auprès du client. Dans SSH, chaque adresse d'interface différente peut être liée à un nom différent, tel que retourné par une requête DNS inversée. Dans ce concept, des paires de clé publique/privée peuvent être requis. Un avantage de ce design est que la sécurité peuvent être différente pour chaque interface.

   Dans le cas de NTP, les client broadcast sont vulnérables à la perturbation par mauvaise conduite ou des serveur broadcast hostiles. Le filtrage peut être employés pour limiter l'accès aux clients NTP aux serveurs de confiance. L'authentification cryptographique au niveau de client permet d'accepter seulement les messages signés.
^
05 novembre 2016

htmlpdflatexmanmd




rfc5906

rfc5906

NTPv4 - Spécification Autokey

   Un service réseau distribué nécessite un provisionnement sûr, non-ambigus et survivable pour empêcher des accidents ou des attaques malicieuses sur les serveurs et clients dans le réseau ou sur les valeurs échangées. La fiabilité nécessite que les clients puissent déterminer que les paquets reçus sont authentiques; c'est à dire, envoyés pas le serveur attendu qu'un client peut valider l'authenticité en utilisant des informations publiques uniquement.

   Ce mémo décris une méthodologie à utiliser dans NTPv4. Les divers schémas d'agréments de clé proposés nécessitent des variables d'état par association, qui contredisent les principes du paradigme RPC dans lequel les serveurs ne conservent aucun état pour une population possiblement très grande. Une évaluation du modèle PKI et des algorithmes, par ex, tel qu'implémenté dans tout paquet NTP pour gérer une signature numérique PKI résulte dans des performances de temps inacceptablement pauvre.

   Le protocole Autokey est basé sur une combinaison de PKI et une séquence pseudo-aléatoire générée par des hashs répétés d'une valeur cryptographique impliquant des composants publiques et privées. Ce schéma a été implémenté, testé, et déployé dans l'Internet d'aujourd'hui. Une description détaillée du modèle de sécurité, principes de design, et d'implémentation sont présentés dans ce mémo.

Modèle de sécurité NTP

   Les exigences de sécurité NTP sont plus stricts que la plupart des services distribués. D'abord, l'opération du mécanisme d'authentification et le mécanisme de synchronisation de temps sont inextricablement liés. La synchronisation de temps fiable exige des clés cryptographiques qui sont valides seulement quand les serveurs participants et les clients sont synchronisés en UTC.

   Un client peut se prétendre authentique aux applications dépendantes seulement si tous les serveurs dans le chemin depuis les serveurs primaires sont authentiques. Afin de souligner cette exigence, dans ce mémo, la notion d'authentique est remplacée par proventique, un adjectif dérivé de provenance. Dans NTP, chaque serveur authentifie la strate inférieur et proventique les serveurs de strate inférieur.

   Il est important de noter que la notion de proventique n'implique pas nécessairement que le temps est correct. Un client NTP mobilise des associations concurrentes avec différents serveurs et utilise un algorithme d'accord pour sélectionner les truechimers. Une association particulière est proventique si le certificat serveur est l'identité ont été vérifiés. Cependant, la déclaration "le client est synchronisé à des sources proventiques" signifie que l'horloge système est définie en utilisant des valeurs de temps d'une ou plusieurs associations proventiques et en accord avec les algorithmes de mitigation NTP.

   Pendant des années IETF a définis et amélioré l'infrastructure IPsec pour la protection des données et l'authentification de la source dans l'Internet. L'infrastructure inclus ESP (rfc4303) et AH (rfc4302) pour IPv4 et IPv6. Les algorithmes cryptographiques qui utilisent ces en-têtes incluent ceux développés pour la PKI, incluant des algorithmes de hash, signature et d'agréments. Ce mémo ne prend pas position sur les algorithmes utilisés. C'est établis par un profile pour chaque communauté d'utilisateurs.

Approche

   Le protocole Autokey est conçus pour répondre aux objectifs suivants:

1. Il doit interropérer avec le modèle d'architecture NTP existant et le design du protocole. En particulier, il doit supporter le schéma de clé symétrique décris dans la rfc1305.
2. Il doit fournir une collection de valeurs cryptographiques et de valeurs de temps indépendants.
3. Il ne doit pas significativement dégrader la précision potentielle des algorithmes de synchronisation NTP.
4. Il doit être résistant aux attaques cryptographiques
5. Il doit permettre une large palette d'algorithmes cryptographiques.
6. Il doit fonctionner dans tous les modes supportés par NTP.

Cryptographie Autokey

   La cryptographie Autokey est basée sur les algorithems PKI communément utilisés dans les applications SSH et SSL. Comme dans ces applications, Autokey utilise les message digest pour détecter les modifications de paquet, les signatures numérique pour vérifier les accréditifs, et les certificats publiques pour fournir une autorité traçable. e qui rend Autokey cryptographiquement unique est la manière dans laquelle les algorithmes sont utilisés pour dévier les attaquants tout en maintenant l'intégrité et la précision des fonction de synchronisation de temps.

   Autokey, comme de nombreuses autres protocoles RPC dépendent des messages digest pour l'authentification de base; cependant, il est important de comprendre que les messages digest sont également utilisés par NTP quand Autokey n'est pas disponible ou non configuré. La sélection de l'algorithme de hashage est une fonction de NTP est est transparent à Autokey.

   Le design de protocole et l'implémentation de référence supporte les algorithmes de hashage 128-bit et 160-bits, chacun avec un ID de clé 32-bit. Pour rester compatible avec NTPv3, l'ID de clé NTPv4 est scindé en 2 parties.

   La cryptographie à clé symétrique et à clé publique authentifient comme décris dans le schéma ci-dessous. Le serveur recherche la clé associée avec l'ID de clé et calcule le hash. L'ID de clé est le hash forment le MAC inclus dans le message. Le client fait le même calcule en utilisant sa copie local de la clé et compare le résultat avec le hash dans le MAC. Si les valeurs concordent, le message est authentique


+------------------+
|_NTP_Header_and___|
|_Extension_Fields_|
+------------------+___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
______|_______|________|___Message_Authentication_Code_|
_____\|/_____\|/_______+______________(MAC)____________+
********************___|_+-------------------------+___|
*___Compute_Hash___*‹----|_Key_ID_|_Message_Digest_|___+
********************___|_+-------------------------+___|
__________|____________+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
_________\|/________________________\|/
+------------------+_______+-------------+
|__Message_Digest__|------›|___Compare___|
+------------------+_______+-------------+

   Autokey utilise des clés de session artificielles, appelés autokeys, et une séquence pseudo-aléatoire précalculée d'autokeys qui sont sauvés dans la liste autokey. Le protocole Autokey opère séparément pour chaque association, donc il peut y avoir de nombreuses séquences autokey opérant indépendemment à la fois.


+-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+

   Une autokey est calculée depuis 4 champs dans l'ordre des octets réseaux. Les 4 valeurs sont hashés en utilisant l'algorithme MD5 pour produire la valeur autokey 128-bits, qui est stocké avec l'ID de clé dans un cache utilisé pour les clés symétriques comme les autokeys. Les clés sont récupérées depuis le cache par key ID en utilisant les tables de hash et un algorithme de recherche rapide.

   Avec IPv4, les champs Src Address et Dst Address contiennent 32bits; avec IPv6 ces champs contiennent 128-bits. Dans les 2 cas, les champs Key ID et Cookie contiennent 32 bits. Donc, une autokey IPv4 à 4 mots de 32 bits et IPv6 à 10 mots de 32 bits. Seul le champs cookie n'est pas visible dans le paquet.

   Le format de paquet NTP a été augmenté pour inclure un ou plusieurs champs d'extensions entre l'en-tête NTP et le MAC. Pour les paquets sans champs d'extension, le cookie est une valeur privée partagée. Pour les paquets avec des champs d'extension, le cookie a une valeur publique par défaut de 0, vu que ces paquets sont validés indépendamment en utilisant les signatures numériques.

   Il y a certains scénarios où l'utilisation d'adresse IP terminal peut être difficile ou impossible. Cela inculs les configuration où un NAT est utilisé ou quand les adresse sont changées durant la durée de vie d'une association. Pour Autokey, la seule restriction est que les champs d'adresse qui sont visibles dans le paquet transmis doivent être les même que celles utilisées pour construire la liste autokey et que ces champs soient les même que ceux visible dans le paquet reçus.


+-----------+-----------+------+------+___+---------+__+-----+------+
|Src_Address|Dst_Address|Key_ID|Cookie|--›|_________|__|Final|Final_|
+-----------+-----------+------+------+___|_Session_|__|Index|Key_ID|
_____|___________|_________|________|_____|_Key_ID__|__+-----+------+
____\|/_________\|/_______\|/______\|/____|__List___|_____|_______|
___*************************************__+---------+____\|/_____\|/
___*__________COMPUTE_HASH_____________*_____________*******************
___*************************************_____________*COMPUTE_SIGNATURE*
_____|____________________Index_n____________________*******************
____\|/_______________________________________________________|
___+--------+_________________________________________________|
___|__Next__|________________________________________________\|/
___|_Key_ID_|___________________________________________+-----------+
___+--------+___________________________________________|_Signature_|
___Index_n+1____________________________________________+-----------+

   Cette illustration montre comment la liste autokey et les valeurs autokey sont calculés. Les Key ID utilisé dans la liste autokey consiste d'une séquence avec un 32bits aléatoire supérieur ou égal au pivot du premier key ID. Le premier autokey est calculé comme ci-dessus en utilisant le cookie donné et autokey a l'index assigné 0. Les premiers 32 bits du résultat dans l'ordre d'octet réseau deviennent le prochain Key ID. Le hash MD5 d'autokey est la valeur de clé sauvée dans le cache de clé avec le Key ID. Les premiers 32 bits de la clé deviennent le Key ID pour la prochaine autokey assignée avec l'index 1.

   Les opérations continuent pour générer la liste entière. Il peut arriver qu'un nouveau Key ID généré soit inférieur au pivot ou entre en collision avec un autre déjà généré. Quand cela se produit, la liste de clé est terminée à ce point. La durée de vie de chaque clé est définie pour expirer à un interval d'interrogation après sont utilisation. Dans l'implémentation de référence, la liste est terminée quand la durée de vie maximum de clé est d'environ une heure, donc pour les intervals d'interrogation supérieur à une heure, une nouvelle liste de clé contenant seulement une seule entrée est regénérée à chaque poll.


+------------------+
|__NTP_Header_and__|
|_Extension_Fields_|
+------------------+
_____|_______|
____\|/_____\|/_____________________+---------+
__****************____+--------+____|_Session_|
__*_COMPUTE_HASH_*‹---|_Key_ID_|‹---|_Key_ID__|
__****************____+--------+____|__List___|
__________|________________|________+---------+
_________\|/______________\|/
+-----------------------------------+
|_Message_Authentication_Code_(MAC)_|
+-----------------------------------+

   L'index de la dernière autokey dans la liste est sauvée avec l'id de clé pour cette entrée, collectivement appelée les valeurs autokey. Les valeurs autokey sont ensuite signées pour une utilisation ultérieure. La liste est utilisée dans l'ordre inverse pour que la première autokey utilisé soit la dernière générée.

   Le protocole Autokey inclus un message pour récupérer les valeurs autokey et vérifier la signature, donc les paquets suivants peuvent être validés en utilisant un ou plusieurs hash qui éventuellement matchent le dernier Key ID (valide) ou excède l'index (invalide). C'est appelé le test autokey dans la suite et est effectué pour chaque paquet, incluant ceux avec et sans champs d'extension. Dans l'implémentation de référence le Key ID le plus récent est sauvé pour comparaison avec les premiers 32 bits dans l'ordre d'octets réseau de la valeur de clé suivante. Cela minimise le nombre d'opérations de hash dans le cas où un paquet est perdu.

   Le protocole Autokey inclus des échanges requête/réponse qui doivent être complétés dans l'ordre. Dans chaque échange, un client envoie une requête et attend un message de réponse d'une serveur. Les requêtes et les réponses sont contenus dans les champs d'extension. Un paquet NTP peut contenir un message requête et un ou plusieurs messages réponse. La suite liste ces messages.

Échange de paramètres La requête inclus le nom d'hôte du client et le status; la réponse inclus le nom d'hôte du serveur et le status. Le status spécifie le schéma digest/signature à utiliser et le schéma d'intentité supportés.
Échange d'identité Le chemin du certificat n'est généralement pas considéré comme une protection suffisante contre les attaquets MITM sauf si une protection additionnelle tels qu'un schéma de preuve de possession (rfc2875) est disponible, mais c'est coûteux est exige que les serveurs retiennent l'état.
Échange de cookie La requête inclus la clé publique du serveur. La réponse inclus le cookie du serveur chiffré avec cette clé. Le client utilise cette valeur en construisant la liste de clé. La fin de cet échange active le bit COOK.
Échange Autokey La requête inclus soit aucune donnée ou les valeurs autokey en modes symétriques. La réponse inclus les valeurs autokey du serveur. Ces valeurs sont utilisées pour vérifier la séquence autokey. La fin de cet échange active le bit AUT
échange de signature Cet échange est exécuté seulement quand le client est synchronisé à une source proventique. La requête inclus le certificat client auto-signé. Le serveur agit comme une CA interprète le certificat comme requête de certificat X.509v3. Il extrait le sujet, émetteur, et les champs d'extension, construit un nouveau certificat avec un numéro de série et dates de validité, puis le signe avec sa clé privée et l'inclus dans la réponse. Le client utilise le certificat signé dans son propre rôle comme serveur pour des clients dépendants. La fin de cet échange active le bit SIGN.
Échange leapseconds Cet échange est exécuté seulement quand le client a été synchronisé à une source proventique. Cet échange se produit quand le serveur a les valeurs leapseconds, comme indiqué dans le status de l'hôte. Si c'est le cas, le client demande les valeurs et les compare avec ses propres valeurs, si disponible. Si les valeurs serveur sont plus récents que les valeurs client, le client remplace ses valeurs avec celles du serveur. Le client, agissant comme serveur, peut maintenant fournir les valeurs les plus récentes à ses clients. La fin de cet échange active le bit LPT.

   Une fois le certificat et l'identitié validés, les paquets suivants sont validés par des signature numérique et la séquence autokey. L'association est maintenant proventique, mais n'est pas encore sélectionnable pour discipliner l'horloge système. Les associations accumulent les valeurs de temps, et les algorithmes de mitigation continuent de manière normale. Quand ces algorithmes ont supprimés les falsetickers et que cluster a au moins 3 survivants, l'horloge système est synchronisée à une source proventique.

   Les valeurs de temps pour les sources truechimers forment un ordre partiel proventique relatif aux horodatages de signatures applicable. Cela soulèves le problème intéressant de comme différentier entre les horodatages des différentes associations. Il peut arriver, par exemple, que le timestamp d'un message Autokey soit est en devant l'horloge système. Pour cette raison, les comparaisons d'horodatage entre les différentes associations et entre les associations et les horloges système sont évités, excepté dans l'intersection NTP et les algorithmes cluster et en déterminant si un certificat a expiré.

Groupe sécurisé NTP

   Les groupes de sécurité NTP sont utilisés pour définir des compartiments cryptographique et des hiérarchies sécurisés. Un groupe sécurisé consiste d'un nombre d'hôtes dynamiquement assemblés dans une forêt avec des racines d'hôtes de confiance (THs = Trusted Hosts) à la strate la plus basse du groupe. Les THs n'ont pas à être, mais le sont souvent, des serveurs primaires (strate 1). Une autorité de confiance (TA), pas nécessairement un hôte de groupe, génère des clé d'identité privée pour les serveurs et les clé d'identité publique pour les clients à la fin de la forêt. Le TA déploie les clés serveur aux THs et d'autres serveurs en utilisant des moyens sécurisés et poster les clés clients dans un site web publique.

   Pour Autokey, tous les hôtes appartiennent à un groupe sécurisé ayant le même nom de groupe mais différents noms d'hôte, par nécessairement liés aux noms DNS. Le nom de groupe est utilisé dans les champs subject et issuer des certificats TH; le nom d'hôte est utilisé dans ces champs pour tous les hôtes. Donc, tous les certificats d'hôtes sont auto-signés. Durant l'utilisation d'Autokey, un client demande que le serveur signe son certificat et cache le résultat. Un chemin de certificat est construit par chaque hôte, possiblement via des hôtes intermédiaires et se terminant à un TH. Donc, chaque hôte dans le chemin récupère tout le chemin de ses serveurs et le fournis plus son propre certificat autosigné à ses clients.

   Les groupes sécurisés peuvent être configurés comme hiérarchies où un TH d'un groupe peut être un client d'un ou plusieurs autres groupes opérant à une strate inférieure. Dans un scénario, les TH pour les groupes RED et GREEN peuvent être cryptographiquement distincts, mais sont tous 2 clients du groupe BLUE opérant à une strate inférieur. Dans un autre scénario, les TH pour le groupe CYAN peuvent être clients de plusieurs groupes YELLOW et MAGENTA, tous 2 opérants a une strate inférieure. Il y a de nombreux autres scénarios, mais tous doivent être configurés pour inclure seulement les chemins de certificat acycliques.

   Dans la figure suivante, le groupe Alice consiste des TH Alice, qui est également le TA, et Carol. Les serveurs dépendants Brenda et Denise on configuré Alice et Carol, respectivement, comme sources de temps. Le serveur de strate 3 Eileen a configuré Brenda et Denise comme source de temps. Les certificats publique sont identifiés par le sujet et signés par l'émetteur. Noter que les clé du groupe de serveur a été précédemment installé sur Brenda et Denise et les clé du groupe client installés sur toutes les machines.


__________________+-------------+ +-------------+ +-------------+
__________________| Alice Group | |____Brenda__ | |____Denise__ |
__________________|____Alice____| |____________ | |____________ |
__________________| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
Certificate_______| | Alice |__ | | | Brenda|__ | | | Denise|__ |
+-+-+-+-+-+_______| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
| Subject |_______| | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+_______| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
| Issuer__| S_____|____________ | |____________ | |____________ |
+-+-+-+-+-+_______| +=======+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
__________________| ||Alice|| 3 | | | Alice |__ | | | Carol |__ |
Group Key________| +=======+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
+=========+_______+-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S_____| Alice Group | | +-+-+-+-+__ | | +-+-+-+-+__ |
+=========+_______|____ Carol__ | |____________ | |____________ |
__________________| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
S = step_________| | Carol |__ | | | Brenda|__ | | | Denise|__ |
_*_= trusted______| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
__________________| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
__________________| +-+-+-+-+__ | | +-+-+-+-+__ | | +-+-+-+-+__ |
__________________|____________ | |____________ | |____________ |
__________________| +=======+__ | | +=======+__ | | +=======+__ |
__________________| ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
__________________| +=======+__ | | +=======+__ | | +=======+__ |
__________________+-------------+ +-------------+ +-------------+
_____________________Stratum 1________________Stratum 2


+---------------------------------------------+
|__________________Eileen_____________________|
|_____________________________________________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Eileen|__ | Eileen|_____________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Brenda| 4 | Carol | 4___________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|_____________________________________________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Alice |__ | Carol |_____________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Alice*| 2 | Carol*| 2___________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|_____________________________________________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Brenda|__ | Denise|_____________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|___________| Alice | 2 | Carol | 2___________|
|___________+-+-+-+-+__ +-+-+-+-+_____________|
|_____________________________________________|
|_________________+-+-+-+-+___________________|
|_________________| Eileen|___________________|
|_________________+-+-+-+-+___________________|
|_________________| Eileen| 1_________________|
|_________________+-+-+-+-+___________________|
|_____________________________________________|
|_________________+=======+___________________|
|_________________||Alice|| 3_________________|
|_________________+=======+___________________|
+---------------------------------------------+
__________________Stratum 3

   Les étapes dans le parcours des chemins de certificat et la vérification d'identité sont comme suit. Noter que le nombre d'étapes dans la description correspond au nombre d'étapes dans la figure.

1. Les filles commencent par charger la clé hôte, la clé de signature, le certificat autosigné, et la clé de groupe. Chaque client et serveur agissant comme client démarre le protocole Autokey en récupérant le nom d'hôte du serveur et le digest/signature en utilisant l'échange ASSOC.
2. Elles continuent à charger les certificats récursivement jusqu'à ce qu'un certificat de confiance auto-signé soit trouvé. Brenda et Denise trouvent immédiatement les certificats de confiance pour Alice et Carol, respectivement, mais Eileen va boucler parce que ni Brenda ni Denise n'ont leur propre certificat signé par soit Alice ou Carol. C'est fait en utilisant l'échange CERT.
3. Brenda et Denise continuent avec les schémas d'identité sélectionnés pour vérifier que Alice et Carol ont le groupe de clé correct précédemment généré par Alice. C'est fait en utilisant les schéma d'identité IFF, GQ, ou MV. En cas de réussite, continuer à l'étape 4.
4. Brenda et Denise présentent leur certificats pour la signature en utilisant l'échange SIGN. En cas de réussite, Brenda et Denise peuvent maintenant fournir ces certificats signés à Eileen. Eileen peut maintenant vérifier le chemin via soit Brenda ou Denise pour les certificats de confiance pour Alice et Carol. Une fois fait, Eileen peut compléter le protocole comme Brenda et Denise.

   Pour diverses raisons, il peut être pratique pour un serveur d'avoir les clés client pour plus d'un groupe. Par exemple, la figure ci-dessous montre 3 groupes sécurisés Alice, Helen, et Carol arrangés dans une hiérarchie. Les hôtes A, B, C, et D appartiennent à Alice avec A et B comme THs. Les hôtes R et S appartiennent à Helen avec R comme TH. Les hôte X et Y appartiennent à Carol avec X comme TH. Noter que le TH pour un groupe est toujours la strate la plus faible et que les hôtes des groupes combinés forment un graphe cyclique. Noter également que le chemin de certificat pour chaque groupe se termine dans un TH pour ce groupe.


_________________________*****_____*****____ @@@@@
__________ Stratum 1_____*_A_*_____*_B_*____ @ R @
_________________________*****_____*****____ @@@@@
____________________________ \____ /________ /
______________________________\__ /________ /
______________________________*****____ @@@@@________________*********
__________________ 2__________*_C_*____ @ S @________________*_Alice_*
______________________________*****____ @@@@@________________*********
______________________________/__ \____ /
____________________________ /____ \__ /____________________ @@@@@@@@@
_________________________*****____ #####____________________ @ Helen @
__________________ 3_____*__D*____ # X #____________________ @@@@@@@@@
_________________________*****____ #####
__________________________________ /__ \____________________ #########
__________________________________/____ \____________________# Carol #
______________________________#####____ #####________________#########
__________________ 4__________# Y #____ # Z #
______________________________#####____ #####

   Le but de ce scénario est de fournir une séparation de sécurité, pour que les serveurs ne puissent pas se cacher comme clients dans d'autres groupes et les clients ne peut pas se cacher comme serveur. Supposons, par exemple, que Alice et Helen appartiennent aux laboratoires standards nationaux et leur clé serveur sont utilisés pour confirmer l'identité entre les membres de chaque groupe. Carol est une société de premier plan recevant des produits standards et exige une authentification cryptographique. Éventuellement sous contrat, l'hôte X appartenant à Carol a les clés client pour Alice et Helen et les clé serveurs pour Carol. Le protocole Autokey opère pour chaque groupe séparément tout en préservant la séparation de sécurité. L'hôte X peut prouver l'identité dans Carol aux clients Y et Z, mais ne peut pas prouver qu'il appartient à Alice ou Helen.

Schéma d'identité

   Un schéma de signature numérique fournis une authentification sûre de serveur, mais ne fournis pas de protection contre le masquerade, sauf si l'identité du serveur est vérifié par d'autres moyens. Le modèle PKI permet au client de prouver l'identifité du serveur en validant le chemin de certificat. Bien qu'Autokey supporte ce modèle par défaut, dans un réseau hiérarchique, spécialement avec les schémas de découverte de serveur comme manycast NTP, prouver l'identité dans le chemin doit être une capacité intrinsèque de Autokey lui-même.

   Le schéma d'identité décrit dans la rfc2875 est basé sur une infrastructure Diffie-Hellman, il est coûteux à générer et à utiliser comparé aux autres décrits dans l'annexe B. En principe, un schéma de clé publique ordinaire peut être conçus pour ce but, mais le design plus strict d'Autokey exige que chaque challenge, même s'il est dupliqué, résulte en une réponse différente acceptable.

1. Le schéma doit avoir une durée de vie relativement longue, certainement plus longue qu'un certificat typique, et n'a pas de durée de vie spécifique ou de date d'expiration. Au moment où le schéma est utilisé, l'hôte n'est pas encore synchronisé, donc le schéma ne peut pas dépendre du temps.
2. Comme le schéma peut être utilisé plusieurs fois où les données peuvent être exposées à des intrus potentiels, les données doivent être soit nonce ou nonce chiffré.
3. Le schéma devrait permettre aux serveurs de prouver leur identité aux clients, mais ne permet pas d'agir comme serveurs pour prouver l'identité aux clients indépendants.
4. Dans la mesure du possible, le schéma devrait représenter une preuve 0 connaissance; c'est à dire que le client devrait être capable de vérifier que le serveur a une clé de groupe correct, mais sans connaître la clé elle-même.

   Il y a 5 schémas implémentés dans l'implémentation de référence NTPv4 pour prouver l'identitié: 1. certificat privée (PC), 2. Certificat de confiance (TC), 3. un algorithme Schnorr modifié (IFF - Identify Friendly ou Foe), 4. Un algorithme Guillou-Quisquater modifié (GQ), et 5. un algorithme Mu-Varadharajan modifié (MV). Ils n'offrent pas tous le même niveau de protection, et TC ne fournis aucune protection mais est inclus pour comparaison. La suite est une brève description de chacun.

   Le schéma PC implique un certificat privée comme clé de groupe. Le certificat est distribué à tous les membres du groupe par des moyen sécurisés et n'est jamais révélé en dehors du groupe. En effet, le certificat privée est utilisé comme clé symétrique. Ce schéma est utilisé principalement pour des tests et n'est pas recommandé pour une utilisation régulière et n'est pas considéré dans la suite de ce mémo.

   Tous les autres schémas impliquent un chemin de certificat conventionnel comme décris dans la rfc5280. C'est le schéma par défaut quand un schéma d'identité n'est pas requis. Bien que les schéma d'identité restants incorporent TC, il n'est pas lui-même considéré dans la suite de ce mémo.

   Les 3 schémas restants, IFF, GQ et MV impliquent un échange challenge/response cryptographiquement fort où un intrus ne peut pas déduire la clé serveur, même après avoir répété les observations de plusieurs échanges. De plus, le schéma MV est décris comme une preuve 0 connaissance propre, parce que le client peut vérifier que le serveur a la clé de groupe correct sans que le serveur ou le client n'ait connaissance de sa valeur. Ces schémas commencent quand le client envoie un nonce au serveur, qui envoie ensuite son propre nonce, effectue une opération mathématique et envoie le résultat au client. Le client effectue une autre opération mathématique et vérifie que les résultats sont corrects.

Timestamps et Filestamps

   Bien que les signatures à clé publique fournissent une protection forte contre les mauvaises représentation de source, les calculer est très coûteux. Cela donne l'opportunité à un intrus d'obstruer le client ou le serveur en rejouant d'anciens messages ou des messages buggés. Un client recevant de tels messages peuvent être forcés de vérifier une signature invalide et consommer des ressources significatives. Pour déjouer de telles attaques, tout message Autokey gère un timestamp sous la forme de secondes NTP auquel il a été créé. Si l'horloge système est synchronisé à une source proventique, une signature est produite avec un timestamp valide. Sinon, il n'y a pas de signature et le timestamp est invalide (0). Le protocole détecte et supprime les champs d'extension avec d'anciens timestamps ou dupliqués, avant que toutes valeurs ou signature soient vérifiées.

   Les signatures sont calculées seulement quand les valeurs cryptographiques sont créé ou modifiées, qui n'est pas très fréquent par design. Les champs d'extension copient ces signatures dans le messages si nécessaire, mais les signature ne sont pas recalculées. Il y a 3 types de signature:

1. Cookie Signature/timestamp Le cookie est signé à la création par le serveur et envoyé au client.
2. Autokey signature/timestamp Les valeurs autokey sont signées quand la liste de clé est créée
3. Public signature/timestamp La clé publique, certificat, et leapseconds sont signés au moment de la génération, qui se produit quand l'horloge système est synchronisée la première fois à une source proventique, quand les valeurs ont été changées et une fois par jours ensuite.

   Le timestamp le plus récent reçus de chaque type est sauvé pour comparaison. Une fois qu'une signature avec un timestamp valid a été reçue, les messages avec des timestamp invalide ou des timestamp valides antérieur du même type sont rejetés avant de vérifier la signature. C'est plus important en mode broadcast, qui peut être vulnérable à des attaque par engorgement sans ce test.

   Toutes les valeurs cryptographiques utilisées par le protocole sont sensible a temps et sont régulièrement rafraîchis. En particulier, les fichiers contenant des valeurs cryptographiques utilisées par les algorithmes de signature et de chiffrement sont regénérés de temps en temps. L'intention est que les régénérations de fichier se produisent sans avertissement préalable et sans nécessiter la distribution préalable du contenu du fichier. Bien que les fichiers de données cryptographiques ne sont pas signés spécifiquement, tout fichier est associé avec un filestamp montrant les secondes NTP depuis l'epoch de sa création.

   Les filestamp et timestamp peuvent être comparés et utilisent la même convention. Il est nécessaire de les comparer de temps en temps pour déterminer lequel est ultérieure ou antérieur. Vu que ces quantités ont une granularité de seulement une seconde, de telles comparaisons sont ambiguës si les valeurs sont dans la même seconde.

   Il est important que les filestamps soient des données proventique. Donc, ils ne peuvent pas être produit sauf si le producteur a été synchronisé à une source proventique. Ainsi, les filestamps dans le sous-réseau NTP représente un ordre partiel de toute créations epochs et sert de moyen d'effacer d'anciennes données et s'assurer que les nouvelles données sont consistantes. Comme les données sont envoyées du serveur au client, les filestamps sont préservés, incluant celles pour les certificats et leapseconds. Les paquets avec d'anciens filestamps sont détruits avant de vérifier la signature.

Opérations Autokey

   Le protocole NTP a 3 modes principaux d'opération: client/serveur, symétrique, et broadcast et chacun a son propre programme Autokey, ou danse. Une chorégraphie Autokey est conçue pour être non-intrusive et n'exige pas de paquets additionnels autre que pour les opération NTP normales. Les protocoles NTP et Autokey opèrent simultanément et indépendamment. Quand la dase est terminée, les paquets suivants sont validés par la séquence Autokey et donc considérés comme proventique. Autokey assume que les clients NTP interrogent les serveur à fréquence relativement basse, comme une fois par minute ou moins. En particulier, il assume qu'une requête envoyée à une opportunité d'interrogation résulte normalement en une réponse avant la prochaine opportunité d'interrogation; cependant, le protocole est robuste contre une réponse manquée ou dupliquée.

   Le serveur ne conserve pas d'état pour chaque client, mais utilise un algorithme rapide et une valeur privée aléatoire 32bits pour régénérer le cookie à l'arriée d'un paquet client. Le cookie est calculé comme 32 premiers bits de l'autokey calculé depuis les adresses client et serveur, Key ID 0, et le serveur envoie le cookie. Le cookie est utilisé pour le calcul autokey par le client et le serveur et est donc spécifique à chaque client séparémment.

   Dans la danse serveur, le client utilise le cookie et chaque key ID dans la liste de clé puis récupère la autokey et génère le MAC. Il génère ainsi le MAC pour la réponse en utilisant les même valeurs, mais en échangeant les adresses client et serveur. Le client génère le message digest et vérifie que le MAC corresponde. Pour déjouer les rejeux anciens, le client vérifie que le key ID correspond au dernier envoyé. Dans cette danse, la structure séquentielle de la liste de clé n'est pas exploitée, mais cela simplifie et régularise l'implémentation tout en évitant la possibilité qu'un intrus ne devine le prochain key ID.

   Dans la danse broadcast, les clients n'envoient normalement pas les paquets au serveur, excepté pour le premier démarrage. À ce moment, le client lance la danse serveur pour vérifier les accréditifs du serveur et calibrer le délai de propagation. La danse nécessite l'ID d'association de l'association serveur particulier, vu qu'il y a plus d'un opérant dans le même serveur. Dans ce but, le paquet serveur inclus l'ID d'association dans chaque réponse et en envoyant le premier paquet après avoir généré une nouvelle liste de clé, il envoie les valeurs autokey. Une fois les valeurs autokey obtenues et vérifiées, aucun champ d'extension n'est nécessaire et le client vérifie les autres paquets serveur en utilisant la séquence autokey.

   La danse symétrique est similaire à la danse serveur et nécessite seulement une petite quantité d'état entre l'arrivée d'une demande et le départ de la réponse. La liste de clé pour chaque direction est générée séparément par chaque paire et utilisé indépendamment, mais chacun est généré avec le même cookie. Le cookie est transporté de la même manière que la danse serveur, excepté que le cookie est un simple nonce. Il existe une condition possible où chaque paire envoie une demande de cookie avant de recevoir la réponse cookie de l'autre paire. Dans ce cas, chaque paire se termine par 2 valeurs, une est générée et l'autre générée par l'autre paire. L'ambiguité est résolue simplement en calculant le cookie comme le EXOR des 2 valeurs.

   Une fois la danse Autokey completée, il est normalement dormant. Excepté pour la danse broadcast, les paquets sont normalement envoyés sans champs d'extension, sauf si le paquet est le premier envoyé après avoir généré une nouvelle liste de clé ou à moins que le client ait demandé le cookie ou les valeurs Autokey. Si pour une raison ou une autre l'horloge client est stepped au lieu d'être slewed, toutes valeurs cryptographique et de temps pour toutes les associations sont purgées et les danses dans toutes les associations redémarrent depuis le début. Celà permet de s'assurer que les valeurs périmées ne se propagent pas au-delà d'un step d'horloge.

Message de protocol Autokey

   L'unité de donnée du protocole Autokey est le champ d'extension, un ou plusieurs qui peuvent être empruntés dans le paquet NTP. Un champ d'extension contient soit une requête avec des données optionnelles ou une réponse avec les données optionnelles. Pour éviter les impasses, plusieurs réponses peuvent être inclus dans un paquet, mais seulement une requête peut l'être. Une réponse est générée pour chaque requête, même si le demandeur n'est pas synchronisé à une source proventique, mais la plupart contiennent des données significatives seulement si le répondeur est synchronisé à une source proventique. Certaines requêtes et beaucoup de réponse gèrent les signatures horodatées. La signature couvre le champ d'extension entier, incluant le timestamp et filestamp, si applicable. Seulement si le paquet est correct, format, longueur et hash, la signature est vérifié.

Il y a actuellement 8 requêtes Autokey et 8 réponses correspondantes:
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|___Code____|__Field_Type___|____________Length_____________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Association_ID________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________________________Timestamp___________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________________________Filestamp___________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|__________________________Value_Length_________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\_______________________________________________________________/

/_____________________________Value_____________________________\
\_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|________________________Signature_Length_______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\_______________________________________________________________/
/___________________________Signature___________________________\
\_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\_______________________________________________________________/
/______________________Padding_(if_needed)______________________\
\_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Un ou plusieurs champs d'extension suivent l'en-tête NTP et le dernier est suivi par le MAC. Le parser de champ d'extension initialise un pointeur au premier octet au-delà de l'en-tête de paquet NTP et calcule le nombre d'octets restant à la fin du paquet. Il le reste fait 20 (128-bit de hash + 4 octets de Key ID) ou 22 (160-bit de hash + 4 octets de Key ID), les données restantes sont le MAC. Supérieur à 22, un champ d'extension est présent. Si la longueur restante est inférieur à 8 ou n'est pas un multiple de 4, une erreur de format s'est produite et le paquet est détruit.

   Dans Autokey le champ du type de champ 8-bit est interprété comme numéro de version, actuellement 2. Le champ Code 6 bits spécifie l'opération de requête ou de réponse. Il y a 2 bits de flag: le bit 0 est le flag de réponse (R) et le bit 1 est flag d'erreur (E).

   Dans la plupart des opération du protocole, un client envoie une requête à un serveur avec un code d'opération spécifié dans le champ Code avec les bits R et E mis. Le serveur retourne une réponse avec le même code d'opération dans le champ Code et efface le bit R. Le serveur peut également effacer E en cas d'erreur. Noter que ce n'est pas nécessairement une erreur de protocole d'envoyer une réponse non-solicitée dans requête correspondante. Si le bit R est mis, le client définis le champ Association ID à l'id d'association du client, que le serveur retourne pour vérification. Si les 2 valeurs ne correspondent pas, la réponse est détruite. Si le bit R est mit, le champ Association ID est mis à l'Association ID du serveur obtenu dans l'échange initial. Si le champ Association ID ne correspond pas à un association ID mobilisé, la requête est détruite.

   Dans certains cas, tous les champs de sont pas présents. Pour les requêtes, jusqu'à ce qu'un client se soit synchronisé à une source proventique, les signatures ne sont pas valides. Dans de tels cas, le champ Timestamp et le champ Signature Length sont à 0 et le champ Signature est absent. Certaines requêtes et messages de réponse d'erreur ne placent aucune valeur dans les champs de signature, donc dans ces messages seul les 2 premiers mots sont présent (8 octets)

   Les Timestamp et Filestamp gèrent le second champ d'un timestamp NTP. Le timestamp établis la signature epoch du champ de données dans le message, alors que filestamp établis la génération epoch du fichier qui a produit la donnée qui est signée.

   Une signature et timestamp sont valide seulement quand l'hôte signant est synchronisé à une source proventique; sinon, le timestamp est 0. Un fichier de données cryptographique peut seulement être généré si une signature est possible; sinon, le filestamp est zéro, excepté dans le messages de réponse ASSOC, où il contient le status du serveur.

No-Operation

   Une requête No-operation (Code 0) ne fait rien excepté retourner une réponse vide, qui peut être utilisée comme crypo-ping.

Assiociation Message (ASSOC)

   Un Association Message (Code 1) est utilisé dans l'échange de paramètre pour obtenir le nom d'hôte et le status. La requête contient le status client dans le champ Filestamp et le nom d'hôte Autokey dans le champ Value. La réponse contient le status serveur dans le champ Filestamp et le nom d'hôte Autokey dans le champ Value. Le nom d'hôte Autokey n'est pas nécessairement le nom d'hôte DNS. Une réponse valide met le bit ENAB et éventuellement d'autres dans le status d'association.

   Quand plusieurs schémas d'identité sont supportés, le status détermine lesquels sont disponible. En mode serveur et symétrique, le status de réponse contient les bits correspondant aux schémas supportés. Dans tous les modes, le schéma est sélectionné en fonction des paramètre d'identité du client qui sont chargés au démarrage.

Certificate Message (CERT)

   Un Certificate Message (Code 2) est utilisé dans l'échange de certificat pour obtenir un certificat par nom du sujet. Le requête contient le nom du sujet; la réponse contient le certificat encodé au format X.509.

   Si le nom du sujet dans la réponse ne match pas le nom de l'émetteur, l'échange continue avec le nom de l'émetteur replaçant le sujet dans la requête. L'échange continue jusqu'à ce que certificat autosigné de confiance soit trouvé et met le bit CERT dans le status.
   Le Cookie Message (Code 3) est utilisé dans en mode serveur et symétrique pour obtenir le cookie serveur. La requête contient la clé publique encodée avec ASN.1. La réponse contient le cookie chiffré par la clé publique dans la requête. Une réponse valide met le bit COOKIE dans le status d'association.

Autokey Message (AUTO)

   Le Autokey Message (Code 4) est utilisé pour obtenir les valeurs autokey. La requête ne contient pas de valeur pour un client ou les valeurs Autokey pour un paire symétrique. a réponse contient 2 mots 32bits, le premier est le Key ID final, et le second est l'index du Key ID final. Une réponse valide met le bit AUTO dans le status d'association.

Leapseconds Values Message (LEAP)

   Le Leapseconds Values Message (Code 5) est utilisé pour obtenir les valeurs leapseconds comme parcouru dans la table leapseconds du NIST. La requête ne contient pas de valeurs. La réponse contient 3 entiers 32bits. Le premier sont les secondes NTP du dernier évènement leap suivi par les secondes NTP quand la dernière table NIST expire puis l'offset TAI suivant l'évènement leap. Une réponse valide met le bit LEAP dans le status d'association.

Sign Message (SIGN)

   Le Sign Message (Code 6) demande que le serveur signe et retourne un certificat présenté dans la requêt. La requête contient le certificat client au format X.509. La résponse contient le certificat client signé par la clé privée du serveur. Une réponse valide met de bit SIGN dans le status d'association.

Identity Messages (IFF, CQ, MV)

   Les Identity Messages (Code 6 - IFF, 8 - GQ, ou 9 - MV) contiennent le challenge client, généralement un nonce 160 ou 512 bits. La réponse contient le résultat de l'opération mathématique. Une réponse valide met le bit VRFY dans le status d'association.

Autokey State Machine

   Le serveur implémente un mot de status d'hôte, alors que chaque client implémente un mot de status d'association. Ces mots ont le format et le contenu définis ci-dessous. Les 16bits LSB définissent l'état de la danse Autokey, alors que les 16bits MSB spécifie le NUD tel que généré par la librairie OpenSSL de l'OID pour un des schémas de hashage/signature définis dans la rfc3279. Les valeurs NID (Numerical Identifier) pour les algorithmes de hashage/signature sont les suivants:


+------------------------+----------------------+-----+
|________Algorithm_______|_OID__________________| NID |
+------------------------+----------------------+-----+
|_________pkcs-1_________| 1.2.840.113549.1.1__ |___2 |
|___________md2__________| 1.2.840.113549.2.2__ |___3 |
|___________md5__________| 1.2.840.113549.2.5__ |___4 |
|______rsaEncryption_____| 1.2.840.113549.1.1.1 |___6 |
|__md2WithRSAEncryption__| 1.2.840.113549.1.1.2 |___7 |
|__md5WithRSAEncryption__| 1.2.840.113549.1.1.4 |___8 |
|_________id-sha1________| 1.3.14.3.2.26_______ |__64 |
|_sha-1WithRSAEncryption_| 1.2.840.113549.1.1.5 |__65 |
|_____id-dsa-wth-sha1____| 1.2.840.10040.4.3___ |_113 |
|_________id-dsa_________| 1.2.840.10040.4.1___ |_116 |
+------------------------+----------------------+-----+

   Les bits 24-31 sont réservés pour le serveur, les bits 16-23 sont réservés pour le client. Dans la portion hôte, les bits 24-27 spécifient les schémas d'identité disponibles, et les bits 28-31 spécifient les capacités serveur. Il y a 2 bits additionnels implémentés séparément.

Status Word
_____________________1___________________2___________________3
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____Digest_/_Signature_NID_____|____Client_____|_Ident_|__Host_|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Le mot de status d'hôte est inclus dans la requête ASSOC et les messages de réponse. Le client copie ce mot dans le mot de status d'association et met les bits additionnels à mesure que la danse progresse. Une fois établis, ces bits ne sont jamais effacés sauf en cas d'erreur, auquel cas le protocole est redémarré depuis le début.

  Les bits de status d'hôte sont définis comme suit:

ENAB (31) Mis si le serveur implémente le protocole Autokey
LVAL (30) Mis si le serveur a installé les valeurs leapseconds
Bits (28-29) Réservés
Bits 24-27 Sélection les schémas d'identité serveur disponible

        Aucun Schéma de certificat de confiance TC (défaut)
        27 Schéma de certificat privée PC
        26 Schéma IFF
        25 Schéma GQ
        24 Schéma MV

- Le schéma PC est exclus. IFF, GQ, et MV peuvent être combinés

   Les bits de status d'association sont définis comme suit:

CERT (23) Mis quand le certificat d'hôte de confiance et la clé publique sont validés
VRFY (22) Mis quand les accréditifs d'identifité de l'hôte de confiance sont confirmés
PROV (21) Mis quand la signature serveur est vérifiée en utilisant sa clé publique et ses accréditifs d'identité. Également appelé le bit proventique.
COOK (20) Mis quand le cookie est reçus et validé
AUTO (19) Mis quand les valeurs autokey sont reçues et validées.
SIGN (18) Mis quand le certificat hôte est signé par le serveur
LEAP (17) Mis quand les valeurs leapseconds sont reçus et validés.
Bit 16 Réservé

   Il y a 3 bits additionnels: LIST, SYNC, et PEER non inclus dans le mot de status d'association. LIST est mis quand la liste de clé est régénénée et effacée quand les valeurs d'autokey ont été transmis. SYNC est mis quand le client est synchronisé à une source proventique. PEER est mis quand le serveur a été synchronisé, comme indiqué dans l'en-tête NTP.

Variable d'état de l'hôte

Host Name Le nom de l'hôte, par défaut la chaîne retournée par la librairie Unix gethostname()
Host Status Word Initialisé quand l'hôte démarre.
Host Key Paire de clé RSA utilisé pour chiffrer/déchiffrer les cookies. C'est également la clé de signature par défaut
Sign Key La paire de clé RSA ou DSA utilisé pour les signatures quand la clé hôte n'est pas utilisée pour cela
Sign Digest Algorithme de hashage utilisé pour calculer le hash avant chiffrement
IFF Parameters Paramètres utilisés dans le schéma d'identité IFF
GQ Parameters Paramètres utilisés dans le schéma d'identité GQ
MV Paramèters Paramètres utilisés dans le schéma d'identité MV
Server Seed Valeur privée hashée avec les adresses IP et l'identifiant de clé pour construire le cookie
CIS Certificat Information Structure. Cette structure inclus certains champs d'informations d'un certificat X.509v3, avec le certificat lui-même. Les champs extraits incluent le sujet et émetteur, clé publique et algorithme de hashage, et le début et fin de validité en secondes NTP.

   Le certificat lui-même est stocké comme champ d'extension pour qu'il puisse être copié tel quel dans le message. La structure est signée en utilisant la clé de signature et gère les timestamp au moment de la signature et le filestamp du fichier certificat originel. La structure est utilisé par la réponse CERT et les demande et réponse SIGN.

   Un champ flags dans CIS détermine le status du certificat. Le champ est encodé comme suit:

        TRUST (0x01) Le certificat a été signé par un émetteur de confiance. Si le certificat est auto-signé et contient trustRoot dans le champ d'utilisation de clé étendu, ce bit est mis.
        SIGN (0x02) La signature de certificat a été vérifiée. Si le certificat est auto-signé et vérifié en utilisant la clé publique contenue, ce bit est mis.
        VALID (0x04) Le certificat est valide et peut être utilisé pour vérifier les signatures. Ce bit est mis quand un certificat de confiance a été troué dans un chemin de certification.
        PRIV (0x08) Le certificat est privé et ne doit pas être révélé. Si le certificat est auto-signé et contient Private dans le champ d'utilisation de clé étendue, ce bit est mis.
        ERROR (0x80) Le certificat est défectueux est ne doit pas être utilisé

Certificate List Les structures CIS sont stockées dans la liste de certificat dans l'ordre d'arrivée, avec le CIS le plus récent placé en premier dans la liste. La liste est initialisée avec le CIS pour le certificat hôte, qui est lus depuis le fichier certificat d'hôte. Additionnellement les entrées CIS qui sont ajoutées à la liste comme certificats sont obtenue depuis les serveurs durant l'échange de certificat. Les entrées CIS sont supprimées si elles sont remplacées par de nouvelles.
Host Name Values C'est utilisé pour envoyer des requêtes/réponses ASSOC. Elle contient le status hôte et le nom d'hôte.
Public Key Values Utilisé pour envoyer des requêtes COOKIE. Elle contient la clé publique de chiffrement utilisé pour la réponse COOKIE
Leapseconds Values Utilisé pour envoyer le message de réponse LEAP. Elle contient les valeurs leapseconds dans la description du message LEAP.

Variables d'état client (tous les modes)

Association ID L'id d'association utilisé dans les réponses. Il est assigné quand l'association est mobilisée.
Associations Status Word Le status copié de la réponse ASSOC, éventuellement modifié par l'état machine.
Subject Name Le nom d'hôte du serveur copié depuis la réponse ASSOC
Issuer Name Le nomb d'hôte de signature de certificat. Extrait du certificat serveur
Server Public Key La clé publique utilisé pour déchiffrer les signatures. Extrait du certificat hôte serveur.
Server Message Digest La schéma de hash/signature déterminé dans l'échange de paramètres
Group Key Un jeu de valeurs utilisées par l'échange d'identité. Identifie le compartiment cryptographique partagé par le serveur et le client.
Receive Cookie Values Le cookie retourné dans une réponse COOKIE, avec ses timestamp et filestamp
Receive Autokey Values Les valeurs autokey retournées dans une réponse AUTO, avec ses timestamp et filestamp
Send Autokey Values Les valeurs autokey avec la signature et les timestamp
Key List Une séquence de Key ID commençant avec l'autokey de départ, et chacun pointant vers le suivant. Il est calculé, timestampé, et signé à la prochaine opportunité d'interrogation quand la liste de clé devient vide.
Current Key Number L'index d'entrée dans la liste de clés.

Transitions d'état du protocole

   L'état machine du protocole est simple mais robuste. L'état est déterminé par le status client. Les transitions d'état des 3 danses sont affichés ci-dessous.

Danse serveur

   La danse serveur commence quand le client envoie une requête ASSOC au serveur. L'horloge est mis à jours quand PREV est mis et la danse se termine quand LEAP est mis. Dans cette danse, les valeurs autokey ne sont pas utilisée, donc un échange autokey n'est pas nécessaire. Noter que les requêtes SIGN et LEAP ne sont pas émises tant que le client n'est pas synchronisé à une source proventique. Les paquets suivants sans champs d'extension sont validé par la séquence autokey. Cet exemple et d'autres assument le schéma d'identité IFF.

Danse serveur
while (1) {
    wait_for_next_poll;
    make_NTP_header;
    if (response_ready)
        send_response;
    if (!ENB) /*_parameter exchange_*/
        ASSOC_request;
    else if (!CERT) /*_certificate exchange_*/
        CERT_request(Host_Name);
    else if (!IFF) /*_identity exchange_*/
        IFF_challenge;
    else if (!COOK) /*_cookie exchange_*/
        COOKIE_request;
    else if (!SYNC) /*_wait for synchronization_*/
        continue;
    else if (!SIGN) /*_sign exchange_*/
        SIGN_request(Host_Certificate);
    else if (!LEAP) /*_leapsecond values exchange_*/
        LEAP_request;
    send packet;
}

   Si le serveur rafraîchis le seed privé, le cookie devient invalide. Le serveur répond à un cookie invalide avec un message crypto-NAK, qui force le client à redémarrer le protocole depuis le début.

Danse broadcast

   La dance broadcast est similaire à la danse serveur avec l'échange cookie remplacée par l'échange de valeurs autokey. La danse broadcast commence quand le client reçoit un paquet broadcast incluant une réponse ASSOC avec l'association ID serveur. Cela mobilise une association client pour proventiquer la source et calibrer le délai de propagation. La danse se termine quand le bit LEAP est mis, après quoi le client n'envoie plus de paquets. Normalement, le serveur broadcast inclus une réponse ASSOC dans chaque paquet transmis. Cependant, quand le serveur génère une nouvelle liste de clé, il inclus une réponse AUTO à la place.

   Dans la danse broadcast, les champs d'extension sont utilisé avec chaque paquet, donc le cookie est toujours 0 et aucun échange de cookie n'est nécessaire. Comme dans la danse serveur, l'horloge est mise à jours quand PREV est mis et la danse se termine quand LEAP est mis. Noter que les requêtes SIGN et LEAP ne sont pas émis tant que le client n'a pas été synchronisé à une source proventique. Les paquets suivants sans champs d'extension sont validés par la séquence Autokey.


while (1) {
    wait_for_next_poll;
    make_NTP_header;
    if (response_ready)
        send_response;
    if (!ENB) /*_parameters exchange_*/
        ASSOC_request;
    else if (!CERT) /*_certificate exchange_*/
        CERT_request(Host_Name);
    else if (!IFF) /*_identity exchange_*/
        IFF_challenge;
    else if (!AUT) /*_autokey values exchange_*/
        AUTO_request;
    else if (!SYNC) /*_wait for synchronization_*/
        continue;
    else if (!SIGN) /*_sign exchange_*/
        SIGN_request(Host_Certificate);
    else if (!LEAP) /*_leapsecond values exchange_*/
        LEAP_request;
    send NTP_packet;
}

   Si un paquet est perdu et la séquence autokey est cassée, le client hash l'autokey courant jusqu'à ce qu'il matche l'autokey précédent ou le nombre de hashs excède le compteur donné dans les valeurs autokey. Le client envoie plus tard une requête AUTO pour récupérer les valeurs autokey. Si le client reçoit un crypto-NAK durant la danse ou si l'association ID change, le client redémarre le protocole depuis le début.

Danse symétrique

   La danse symétrique est une chorégraphie complexe. Elle commence quand le paire actif envoie une requête ASSOC au paire passif. Le paire passif mobilise une association et les 2 paires démarrent une danse 3 voies où chaque paire complète un échange de paramètre avec l'autre. Quand un des paire soit synchronisé à une source proventique et puisse signer des messages, les autres paires bouclent en attente d'un timestamp valide dans la réponse CERT.


while (1) {
    wait_for_next_poll;
    make_NTP_header;
    if (!ENB) /*_parameters exchange_*/
        ASSOC_request;
    else if (!CERT) /*_certificate exchange_*/
        CERT_request(Host_Name);
    else if (!IFF) /*_identity exchange_*/
        IFF_challenge;
    else if (!COOK && PEER) /*_cookie exchange_*/
        COOKIE_request);
    else if (!AUTO) /*_autokey values exchange_*/
        AUTO_request;
    else if (LIST) /*_autokey values response_*/
        AUTO_response;
    else if (!SYNC) /*_wait for synchronization_*/
        continue;
    else if (!SIGN) /*_sign exchange_*/
        SIGN_request;
    else if (!LEAP) /*_leapsecond values exchange_*/
        LEAP_request;
    send NTP_packet;
}

   Une fois qu'un paire a été synchronisé à une source proventique, il inclus les signatures horodatées dans ses messages. l'autre paire, qui attend des horodatages valides, peuvent finir la danse. Il récupère le cookie non-zéro en utilisant un échange de cookie et met à jours les valeurs autokey en utilisant un échange autokey.

   Comme dans la danse broadcast, si un paquet est perdu et la séquence autokey cassée, le paire hash l'autokey courant jusqu'à ce qu'il matche l'autokey précédent ou que le nombre de hash excède le compteur dans les valeurs autokey. Le client envoie plus tard une requête AUTO pour récupérer les valeurs autokey. Si le client reçoit un crypto-NAK durant la danse ou si l'association ID change, le client redémarre le protocole depuis le début.

Récupération d'erreur

   L'état machine du protocole Autokey inclus un provisionning pour diverses conditions d'erreur qui peuvent se produire à cause de fichiers manquants, données corrompues, violations de protocole, et perte de paquet et désordonnés, sans mentionner les intrusions hostiles. Cette section décrit comme le protocole réponds aux évenements d'accessibilité et timeouts qui peuvent se produire à cause de telles erreurs.

   Une association NTP persistante est mobilisée par une entrée dans le fichier de configuration, alors qu'une association éphémère est mobilisée à l'arrivée d'un paquet broadcast ou symétrique actif sans association correspondant. En conséquence, un reset général réinitialise toutes les variables d'association à l'état initial quand il est mobilisé. De plus, si l'association est éphémère, l'association est démobilisée et toutes les ressources acquises sont retournée au système.

   Toute association NTP a 2 variables qui maintiennent l'état du protocole, le registre 8 bits reach et le compteur unreach. À chaque interval d'interrogation, le registre reach est décalé à gauche, et LSB est mis à 0. À ce moment, le compteur unreach est incrémenté de 1. Si un paquet arrivant passe l'authentification et les vérifications de santé, le LSB est mis et le compteur unreach est effacé. Si un bit dans le registre reach est mis, le serveur est accessible, sinon il est inaccessible.

   Quand la première interrogation est envoyée depuis une association, le registre reach et le compteur unreach sont mis à 0. Si le compteur unreach atteind 16, l'interval d'interrogation est doublé. De plus, si l'association est persistante, elle est démobilisée. Cela réduit la charge réseau pour les paquets qui sont peu susceptibles de susciter une réponse.

   À chaque état dans le protocole, le client attend une réponse particulière du serveur. Une requête est inclus dans le paquet NTP envoyé à chaque interval d'interrogation jusqu'à ce qu'une réponse valide soit reçue ou un reset général se produise, auquel cas le protocole redémarre depuis le début. Un reset général se produit également pour une association quand une erreur de protocole irrécupérable se produit. Un reset général se produit pour toutes les associations quand l'horloge système est d'abord synchronisée ou stepped ou quand le l'envoie serveur est rafraîchis.

   Il y a des cas spéciaux conçus pour rapidement répondre à des association cassées, comme quand un serveur redémarre ou rafraîchis les clés. Vu que le cookie client est invalidé, le serveur rejète la requête client suivante et retourne un crypto-NAK. Vu que le crypto-NAK n'a pas de MAC, le problème pour le client est de déterminer s'il est légitime ou le résultat d'un intrus. Pour réduire la vulnérabilité dans de tels cas, le crypto-NAK, comme toutes les autres réponses, est validé seulement s'il est le résultat d'un paquet précédent envoyé par le client et pas un rejeux, comme confirmé par le protocole on-wire.

   Il y a des situations où certains évènements se produisant causent les autokey restant dans la liste à devenir invalide. Quand une de ces situations se produit, la liste de clé est les autokeys associées dans le cache de clé sont purgés. Une nouvelle liste de clé, signature, et timestamp sont générés quand le prochain message NTP est envoyé, en supposant qu'il y en ait un. La liste de ces situation est:

1. Quand la valeur d'un cookie change pour une raison ou une autre
2. Quand l'interval d'interrogation est changé. Dans ce cas, les temps d'expiration pour les clé deviennent invalides
3. Si un problème est détecté quand une entrée est récupérée depuis la liste de clé. Cela peut se produire si la clé a été marqué non-trusted ou timeout, ce qui peut impliquer un bug logiciel.

Considérations de sécurité

   Bien que le protocole n'a pas été sujet à une analyse formelle, quelques affirmations préliminaires peuvent être faites. Dans les danses client/serveur et symétrique, le protocole on-wire est résistant à la perte, duplication, et paques buggés, même si l'horloge n'est pas synchronisée, donc le protocole n'est pas vulnérable à une attaque wiretapper. Le protocole on-wire est résistant aux replays de paquet de requête client et de réponse serveur. Une attaque MITM, même si elle peut simuler un cookie valide, ne peut pas prouver l'identité.

   Dans la danse broadcast, le client commence en mode client/serveur pour obtenir les valeurs autokey et signature, donc a le même niveau de protection que dans ce mode. En continuant en mode réception uniquement, un wiretapper ne peut pas produire une liste de clés avec des valeurs autokey signées valides. S'il rejoue un ancien paquet, le client le rejète par vérification du timestamp. Le mieux qu'il peut faire est de fabriquer un paquet future forçant le client à répéter les opérations de hashage autokey jusqu'à excéder le nombre maximum de clé. Si cela ce produit le client broadcast revient temporairement en mode client pour rafraîchir les valeurs autokeys.

   Par supposition, un attaquant MITM qui intercepte un paquet ne peut pas casser le fil ou délai dans un paquet intercepté. Si cette supposition est supprimée, le MITM pourrait intercepter un paquet broadcast et remplacer les données et le hash sans détection par les clients.

   Comme mentionné précédemment, le schéma d'identité TC est vulnérable à une attaque MITM où un intrus peut créer un chemin de certificat buggé. Pour déjouer ce type d'attaque, les schémas PC, IFF, GQ ou MV doivent être utilisés.

   Un client instancie les variables cryptographiques seulement si le serveur est synchronisé à une source proventique. Un serveur ne signe pas de valeurs ou ne génère de fichiers de données cryptographiques sauf s'il est synchronisé à une source proventique. Cela soulève un problème intéressant: comment un client génère des fichiers cryptographiques proventique avant qu'il ait été synchronisé à une source proventique? En principe, ce paradoxe est résolus en assumant que les serveurs primaires sont proventiqués par des moyens externes.

Vulnérabilité Clogging

   Un incident clogging auto-induit ne peut pas se produire, vu que les signatures sont calculées seulement quand les données ont changées et les données ne changent pas très souvent. Par exemple, les valeurs autokey sont signées seulement quand la liste de clé est regénérée, se qui se produit une fois par heure, alors que les valeurs publiques sont signées seulement quand une d'entre elles est mise à jours durant une danse ou un seed serveur est rafraîchis, se qui se produit un fois par jour.

   Il y a 2 vulnérabilités d'obstruction exposés dans le protocole: une attaque de chiffrement où l'intrus espère obstruer le serveur avec des calculs cryptographiques inutiles, et une attaque par déchiffrement où l'intrus tente d'obstruer le client avec des calculs cryptographiques inutiles. Autokey utilise une clé publique et les algorithmes qui effectuent ces fonctions consomment beaucoup de ressource.

   Dans les danse client/serveur et paire, un hasard cryptographique existe quand un wiretapper rejoue d'anciens messages de requête de cookie rapidement. Il n'y a pas de moyen de déjouer de telles attaques, vu que le serveur ne retient pas d'état entre les requêtes. Les replays des requêtes ou réponse cookie sont détectées et supprimées par le protocole on-wire client.

   En mode broadcast, un hasard de déchiffrement existe quand un wiretapper rejoue des messages réponse autokey rapidement. Une fois synchronisé à une source proventique, un champs d'extension légitime avec timestamp identique ou antérieur au plus récent reçus est immédiatement détruit. Cela met en évidente une attaque MITM cup-and-paste en utilisant une réponse antérieure, par exemple. en champ d'extension légitime avec timestamp dans le future est peu probable vu qu'il requière de prédire la séquence autokey. Cependant, cela force le client à rafraîchir et vérifier les valeurs autokey et la signature.

   Un attaquant déterminé peut déstabiliser le protocole on-wire ou une danse autokey de diverses manières en rejouant d'anciens messages avant que le client ou le paire se soit synchronisé pour la première fois. Par exemple, rejouer un ancien message en mode symétrique avant que les paires se soient synchronisés empêche les paires de se synchroniser. Rejouer les messages Autokey dans le désordre durant une danse peut empêcher de completer la danse. Il n'y a rien de nouveau dans ce type d'attaques; une vulnérabilité similaire existe dans TCP.
^
05 août 2015

htmlpdflatexmanmd




rfc5914

rfc5914

Format d'ancre de confiance

   Ce document décris une structure pour représenter les informations d'ancre de confiance. Une ancre de confiance est une entité autoritative représentée par une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'information ou actions pour lesquelles l'ancre de confiance a autorité. Les structures définies dans ce document sont prévus pour satisfaire les exigences liées au format définis dans les exigencse de gestion d'ancre de confiance.

   Les ancres de confiance sons largement utilisées pour vérifier les signatures numériques et valider les chemins de certification. Ils sont requis pour valider les chemins de certification. Bien que largement utilisés, il n'y a pas de format standard pour représenter les informations d'ancre de confiance. ce document décris la structure TrustAnchorInfo. Cette structure est prévue pour satisfaire les exigences liées au format exprimées dans les exigences de gestion d'ancre de confiance ( rfc6024 ) et est exprimée en utilisant ASN.1. Il peut fournir une alternative plus compact aux certificats X.509 pour échanger les informations d'ancre de confiance et fournir un moyen d'associer des contraintes additionnelles ou alternatives avec les certificats sans casser la signature dans le certificat.

Syntaxe d'information d'ancre de confiance

Cette section décris la structure TrustAnchorInfo:
TrustAnchorInfo ::= SEQUENCE {
    version TrustAnchorInfoVersion DEFAULT v1,
    pubKey SubjectPublicKeyInfo,
    keyId KeyIdentifier,
    taTitle TrustAnchorTitle OPTIONAL,
    certPath CertPathControls OPTIONAL,
    exts [1] EXPLICIT Extensions OPTIONAL,
    taTitleLangTag [2] UTF8String OPTIONAL }
    
TrustAnchorInfoVersion ::= INTEGER { v1(1) }

Version

   La version identifie la version de TrustAnchorInfo. De futures mises à jours de ce document peuvent inclure des changements dans cette structure, auquel cas le numéro de version devrait être incrémenté. Cependant, la valeur par défaut, v1, ne peut pas être changée.

Clé publique

   pubKey identifie la clé publique et l'algorithme associé avec l'ancre de confiance en utilisant la structure SubjectPublicKeyInfo (rfc5280). La structure SubjectPublicKeyInfo contient l'identifiant d'algorithme suivi par la clé publique elle-même. Le champ algorithm est un AlgorithmIdentifier, qui contient un identifiant d'objet et des paramètres optionnels. L'identifiant d'objet nomme l'algorithme de clé publique et indique la syntaxe des paramètres, si présent, aussi bien que le format de la clé publique. La clé publique est encodée en chaîne de bits.

Titre de l'ancre de confiance


TrustAnchorTitle ::= UTF8String (SIZE (1..64))

   taTitle est optionnel. Si présent, il fournis un nom compréhensible pour l'ancre de confiance. Le texte est encodé en UTF-8. Le champ taTitleLangTag identifie la langue utilisée pour exprimer le taTitle. Quand taTitleLangTag est absent, l'englais ("en") est utilisé. La valeur de taTitleLangTag devrait être un tag de langue comme décris dans la rfc5646.

Contrôles de chemin de certification


CertPathControls ::= SEQUENCE {
    taName Name,
    certificate [0] Certificate OPTIONAL,
    policySet [1] CertificatePolicies OPTIONAL,
    policyFlags [2] CertPolicyFlags OPTIONAL,
    nameConstr [3] NameConstraints OPTIONAL,
    pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}

   certPath est optionnel. Si présent, il fournis les contrôles nécessaires pour initialiser une implémentation d'algorithme de validation de certification X.509. Si absent, l'ancre de confiance ne peut pas être utilisée pour valider la signature dans un certificat X.509.

   taName fournis le nom distinct X.500 associé avec l'ancre de confiance, et ce nom distinct est utilisé pour construire et valider un chemin de certification X.509. Le nom ne doit pas être une séquence vide.

   certificate fournis un certificat X.509 optionnel, qui peut être utilisé dans certains environnements pour représenter l'ancre de confiance dans le développement et la validation du chemin de certification. Si le certificat est présent, le nom du sujet dans le certificat doit correspondre exactement le nom distinct X.500 fournis dans le champ taName, la clé publique doit correspondre exactement à la clé publique dans le champ pubKey, et l'extension subjectKeyIdentifier, si présent, doit correspondre exactement l'identifiant de clé dans le champ keyId. La description complète de la syntaxe et les sémantiques du certificat sont fournis dans la rfc5280. Les contraintes définies dans les champs policySet, policyFlags, nameConstr, pathLenConstraint, et exts dans TrustAnchorInfo remplacent les valeurs contenues dans un certificat ou fournissent des valeurs pour les extensions non présente dans le certificat. Les valeurs définies dans ces champs TrustAnchorInfo sont toujours forcés. Les extensions inclues dans un certificat sont forcés seulement s'il n'y a pas de valeur correspondante dans le TrustAnchorInfo. La correspondance entre les extensions dans le certificat et les champs TrustAnchorInfo sont définis comme suit:

- une extension de certificat id-ce-certificatePolicies correspond au champ CertPathControls.policySet
- une extension de certificat id-ce-policyConstraints correspond au champ CertPolicyFlags.inhibitPolicyMapping et CertPolicyFlags.requireExplicitPolicy
- Une extension de certificat id-ce-inhibitAnyPolicy correspond au champ CertPolicyFlags.inhibitAnyPolicy
- Une extension de certificat id-ce-nameConstraints correspond au champ CertPathControls.nameConstr
- Le champ pathLenConstraint d'une extension de certificat id-ce-basicConstraints correspond au champ CertPathControls.pathLenConstraint ( La présence d'une structure CertPathControls correspond à une valeur TRUE dans le champ cA de l'extension BasicConstraints )
- Toute autre extension de certificat correspond au même type d'extension dans le champ TrustAnchorInfo.exts


CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
    
PolicyInformation ::= SEQUENCE {
    policyIdentifier CertPolicyId,
    policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }
    
CertPolicyId ::= OBJECT IDENTIFIER

   policySet est optionnel. Si présent, il contient une séquence d'identifiant de stratégie de certificat fournis en entrée de l'algorithme de validation de chemin de certification. Si absent, la valeur spéciale any-policy est fournie comme entrée de l'algorithme de validation de chemin de certification. La description complète de la syntaxe et des sémantiques de CertificatePolicies sont fournis dans la rfc5280, incluant la syntaxe PolicyInformation. Dans ce contexte, la structure optionnelle policyQualifiers ne doit pas être inclue.


CertPolicyFlags ::= BIT STRING {
    inhibitPolicyMapping (0),
    requireExplicitPolicy (1),
    inhibitAnyPolicy (2) }

   policyFlags est optionnel. Si présent, 3 valeurs booléennes pour l'entrée dans l'algorithme de validation de chemin de certification sont fournis dans un BIT STRING. Si absent, l'entrée de l'algorithme de validation de chemin de certification est { FALSE, FALSE, FALSE }, qui représente le paramètre le plus libéral de ces flags. Ces 3 bits sont utilisés comme suit:

- inhibitPolicyMapping indique si le mappage de stratégie est autorisé dans le chemin de certification. Quand mis à TRUE, le mappage de stratégie n'est pas permis. Cette valeur représente la valeur d'entrée initial-policy-mapping-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.
- requireExplicitPolicy indique si le chemin de certification doit être valide pour au moins une des stratégies de certificat dans le policySet. À TRUE, tous les certificats dans le chemin de certification doivent contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Cette valeur représente la valeur d'entrée initial-explicit-policy dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Un identifiant de stratégie acceptable est un membre du policySet ou l'identifiant d'une stratégie qui est déclarée équivalente via le mappage de stratégie. Ce bit doit être à FALSE si policySet est absent.
- inhibitAnyPolicy indique si l'identifiant de stratégie anyPolicy, avec la valeur { 2 5 29 32 0 }, est considéré un match explicite pour d'autres stratégies de certificat. Cette valeur représente la valeur d'entrée initial-any-policy-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.


NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }
    
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
    
GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0..MAX)

   nameConstr est optionnel. Il a la même syntaxe et sématiques que l'extension de certificat de contrainte de noms, qui inclue une liste de noms permis et une liste de noms exclus. La définition de GeneralName peut être trouvée dans la rfc5280. Quand il est présent, les contraintes sont fournies sur les noms (incluant les noms alternatifs) qui doivent apparaître dans le certificats X.509 sous-jacents dans un chemin de certification. Ce champ est utilisé pour définir les valeurs d'entrée initial-permitted-subtrees et d'initial-excluded-subtrees dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Quand ce champ est absent, la variable initial-permitted-subtrees n'est pas limitée et la variable initial-excluded-subtrees est vide.

   Le champ pathLenConstraint donne le nombre maximum de certificats intermédiaire non-auto-émis qui peuvent suivre ce certificat dans un chemin de certification valide. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire et n'est pas inclus dans cette limite. Généralement, le dernier certificat est en certificat EE, mais il peut être un certificat CA). Un pathLenConstraint de 0 indique qu'aucun certificat d'autorité de certification intermédiaire non-auto-émis ne peut suivre dans le chemin de certification. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal àl 0. Quand il n'apparaît pas, aucune limite n'est imposée.

   Quand l'ancre de confiance est utilisée pour valider un chemin de certification, CertPathControls fournis les limitations dans le chemins de certification qui seront validés avec succès. Une application qui valide un chemin de certification ne devrait pas ignorer ces limitations, mais l'application peut imposer des limitations additionnelles pour s'assurer que le chemin de certification validé est approprié pour le contexte applicatif prévu. Comme entrée de l'algorithme de validation de chemin de certification, une application peut:

- Fournir un sous-jeu de stratégies de certification fournies dans le policySet
- Fournir une valeur TRUE, si approprié, pour les flags dans le policyFlags
- Fournir un sous-jeu de noms permis fournis dans nameConstr
- Fournir des noms exclus additionnels à ceux fournis dans le nameConstr
- Fournir une valeur plus petite pour pathLenConstraint

Extensions

   exts est optionnel. Si présent, il peut être utilisé pour associer des informations additionnelles avec l'ancre de confiance en utilisant la structure Extensions standard. Les extensions qui sont prévus pour être largement utilisé ont été inclus dans la structure CertPathControls pour éviter une surchage associée avec l'utilisation de la structure Extensions. Pour éviter la duplication avec le champ CertPathControls, les types d'extensions suivants ne doivent pas apparaître dans le champ exts et sont ignorés s'il n'apparaissent: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce-inhibitAnyPolicy, et id-ce-nameConstraints.

Liste d'ancre de confiance

   TrustAnchorInfo permet la représentation d'une simple ancre de confiance. Dans de nombreux cas, il est préférable de représenter une collection d'ancre de confiance. La structure TrustAnchorList est définie dans ce but. TrustAnchorList est définis comme une séquence d'un ou plusieurs objects TrustAnchorChoice. TrustAnchorChoice fournis 3 options pour représenter une ancre de confiance. L'option certificat permet d'utiliser un certificat sans contraintes additionnelles. L'option tbsCert permet d'associer des contraintes en supprimant un signature dans un certificat et en changeant le champ extensions. L'option taInfo permet d'utiliser une structure TrustAnchorInfo définis dans ce document.


TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice
    
TrustAnchorChoice ::= CHOICE {
    certificate Certificate,
    tbsCert [1] EXPLICIT TBSCertificate,
    taInfo [2] EXPLICIT TrustAnchorInfo }
    
trust-anchor-list PKCS7-CONTENT-TYPE ::= { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }

   La structure TrustAnchorList peut être protégée en utilisant la structure SignedData définis dans CMS. L'identifiant d'objet id-ct-trustAnchorList a été définis pour représenter le payloads TrustAnchorList avec les structure CMS.

Considérations de sécurité

   La compromission d'une clé privée d'ancre de confiance permet à des tiers non-autorisés d'usurper l'ancre de confiance, avec des conséquences potentiellement sévères. Quand des contraintes basés sur TA sont forcés, une personne non-autorisée ayant la clé privée sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans les champs certPath et exts. Par exemple, les contraintes de nom dans l'ancre de confiance vont déterminer l'espace de nom qui sera accepté dans le certificats qui sont validés en utilisant l'ancre de confiance compromise. Le recours à une clé publique d'un ancre de confiance inapproprié ou incorrect a des conséquences potentiellement sévères.

   La compromission d'une clé privée de CA a le même type de problème que la compromission de clé privée d'une ancre de confiance. Une entité non autorisée possédant la clé privée de la CA sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans le champ certPath ou comme extension.

   L'utilisation d'un certificat indépendant de la structure TrustAnchorinfo qui l'enveloppe doit être géré avec prudence pour éviter de violer les contraintes exprimées dans le TrustAnchorInfo. En enveloppant un certificat dans une structure TrustAnchorinfo, les valeurs inclues dans le certificat devraient être évalués pour s'assurer qu'il n'y a pas de confusion ou de conflit avec les valeurs dans la structure TrustAnchorinfo.
^
05 août 2015

htmlpdflatexmanmd




rfc5937

rfc5937

Utilisation des contraintes d'ancre de confiance durant le traitement de chemin de certification

   Ce document décris comment utiliser les informations utilisée avec une clé publique d'ancre de confiance lors de la validation de chemin de certification. Cette information peut être utilisée pour contraindre l'utilisation d'une ancre de confiance. Typiquement, les contraintes sont utilisées pour limiter les stratégies de certificat et les noms qui peuvent apparaître dans les chemins de certification validés en utilisant une ancre de confiance.

   Les ancres de confiance sons largement utilisés pour vérifier les signatures numérique et la validation de chemin de certification (rfc5280). Il sont requis pour la validation de chemin de certification. La spécification du format de l'ancre de confiance (rfc5914) définis un moyen pour limiter le périmètre dans lequel une ancre de confiance peut être utilisée. La rfc5280 décris comment valider un chemin de certification. L'algorithme exige de traiter le nom et la clé depuis une ancre de confiance. L?utilisation d'autres informations, incluant le renforcement de contraintes, est permis mais non requis, et le traitement des règles ne sont pas spécifiés.

   Ce document définis un mécanisme pour identifier les contraintes qui devraient être forcés et les règles de traitement supplémentaires. Les règles supplémentaires spécifient une entrée additionnels et étendent les procédures d'initialisation dans l'algorithme de validation de chemin (rfc5280), les étapes de traitement post-initialisation ne sont pas affectés.

Identifier le contraintes d'ancre de confiance

   TAF supporte 3 formats pour représenter les informations d'ancre de confiance: TrustAnchorInfor, Certificate, et TBSCertificate. Dans les 3 cas, les contraintes d'ancre de confiance peut être représentée comme extensions. Dans la structure TrustAnchorInfor, les stratégies de certificat, contraintes de stratégie, les contraintes de noms, inhibitAnyPolicy, et les contraintes de bases n'apparaîssent pas comme extensions et apparaîssent dans le champ CertPathControls.

   Les extensions peuvent être marquées critique ou non. Quand les contraintes d'ancre de confiance sont forcées, les clients doivent rejeter les chemins de certification contenant une ancre de confiance avec des extensions critique non-reconnues. Quand les contraintes d'ancre de confiance ne sont pas forcées, les clients peuvent accepter les chemins de certification contenant une ancre de confiance avec les extensions critique non-reconnues. Les informations apparaissant dans le champ CertPathControls d'un objet TrustAnchorInfo doit être traité, pour s'assurer que les contraintes indiquées par ce champ sont forcés dans tous les cas.

   Pour certains types de contrainte d'ancre de confiance, il y a un manque de concordance entre les paramètres pour l'algoritme de validation de chemin de certification et l'extension qui contient la contrainte. L'algorithme de validation de chemin de certification définis essentiellement l'initial-any-policy-inhibit, initial-policy-mapping-inhibit et initial-explicit-policy comme valeurs booléennes. les extensions inhibitAnyPolicy et policyConstraints qui correspondent à ces entrées sont exprimées en valeurs entières. Dans les étapes décrites ci-dessous, la présence de l'extension inhibitAnyPolicy résulte dans la valeur initial-any-policy-inhibit à TRUE. Si une extension policyConstraints est présente et contient un champ requireExplicitPolicy, la valeur initial-explicit-policy est à TRUE. Si une extension policyConstraints est présente et contient un champ inhibitPolicyMapping, la valeur initial-policy-mapping-inhibit est à TRUE.

Utiliser les contraintes durant le traitement de chemin de certification

   Cet algorithme assume que les 9 entrées définies dans la rfc5280 sont fournis au traitement de chemin, plus une variable additionnelle:

enforceTrustAnchorConstraints Indique si les contraintes de l'ancre de confiance devraient être forcés

   Les implémentations conformes ne sont pas obligés de supporter ce paramètre. Si une implémentation ne supporte pas le paramètre de ce flag, il doit valider tous les chemins de certification en utilisant une valeur de TRUE pour enforceTrustAnchorConstraints.

Initialisation

   Si enforceTrustAnchorConstraints vaut false, aucune étape additionnelle n'est requise. Si enforceTrustAnchorConstraints vaut true, les étapes additionnelles suivante doivent être effectuées. Ces étapes (ou équivalentes) doivent être effectuées avant les étapes d'initialisation décrites dans la rfc5280.

- Si aucun nom distinct du sujet n'est associé avec l'ancre de confiance, la validation de chemin échoue. Le nom peut apparaître dans le champ subject d'un certification ou une structure TBSCertificate ou dans le champ taName de CertPathControls dans une structure TrustAnchorInfo.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-permitted-subtrees égale à l'intersection des permitted subtrees de l'ancre de confiance et de l'uinitial-permited-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable initial-permited-subtrees est définis à la valeur qui est disponible. Si aucun n'est fournis, la variable est définie à un jeu infinis.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-excluded-subtrees égal à l'union des excluded subtrees de l'ancre de confiance et de l'initial-excluded-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournis, la variable est mis à la valeur qui est disponible. Si aucune n'est fournis, la variable est définie à un jeu vide.
- Si les stratégies de certificat sont associées avec l'ancre de confiance, définis la variable user-initial-policy-set égal à l'intersection des stratégies de certificat associés avec l'ancre de confiance et le user-initial-policy-set fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable est définie à la valeur qui est disponible. Si aucune de ces valeurs n'est fournie, définis la variable à any-policy.
- Si une valeur inhibitAnyPolicy à TRUE est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension inhibitAnyPolicy) et que la valeur initial-any-policy-inhibit vaut false, définis la valeur initial-any-policy-inhibit à true.
- Si une valeur de stratégie explicite requise est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension policyConstraints) et que la valeur initial-explicite-policy vaut false, définis la valeur initial-explicit-policy à true.
- Si une valeur de mappage d'inhibition de stratégie est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension PolicyConstraints) et que la valeur initial-policy-mapping-inhibit vaut false, définis la valeur initial-policy-mapping-inhibit à true.
- Si une extension de contrainte de base est associée avec l'ancre de confiance et contient une valeur pathLenConstraint, défins la variable d'état max_path_length égal à la valeur pathLenConstraint de l'extension de contrainte de base.

Traitement de certificat de base

   Ce document n'exige pas d'augmentation d'étapes de traitement de certificat de base. Cepenadnt, certains types de contraintes d'ancre de confiance peuvent avoir définis des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Préparation pour le certificat i+1

   Ce document ne nécessite aucune augmentation des étapes pour préparer le traitement du certificat i+1. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Procédure wrap-up

   Ce document ne nécessite pas d'augmentation d'étapes de procédure d'enveloppement. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Relations à la rfc5280

   Le traitement décris ci-dessous peut être incorporé dans une implémentation rfc5280 ou être implémenté comme pré-traitement aux entrées rfc5280 et post-traitement des sorties rfc5280.

   Pour les contraintes de nom et les contraintes liées aux stratégies, le pré-traitement peut être utilisé, fournissant à l'implémentation rfc5280 la configuration des valeurs d'entrée user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, et initial-excluded-subtrees. La rfc5280 ne définis pas d'entrée pour les contraintes de longueur de chemin, donc les contraintes de bases ne peuvent pas être implémentées en utilisant un pré-traitement. Il peut être implémenté comme post-traitement.

   Certains types de contraintes d'ancre de confiance peuvent imposer des exigences additionnelles à l'implémentation rfc5280 pour supporter le pré-traitement et le post-traitement pour forcer les contraintes des ancres de confiance.

Considérations de sécurité

   Les implémentations qui ne forcent par les contraintes d'ancre de confiance peuvent accepter certains chemins de certification rejetés par les implémentations qui imposent les contraintes d'ancre de confiance. Par exemple, une application qui ne force pas une contrainte de stratégie de certificat inclus dans une ancre de confiance peut accepter les certificats émis sous une stratégie de certificat qui fournis un niveau d'assurance plus faible que le niveau requis.

   Les informations d'ancre de confiance doivent être stockées de manière sécurisée. Les changements d'information d'ancre de confiance peut impliquer l'acceptation de certificat qui devraient être rejetés. Par exemple, si une définition d'ancre de confiance est altérée pour supprimer une contrainte de noms, les applications peuvent accepter les certificats contenant les noms qui n'auraient été validés que dans des certificats validés par une ancre de confiance différente. Similairement, l'ajout d'ancres de confiance inapproprié à un dépôt d'ancre de confiance peut résulter en une validation de certificats via une ancre de confiance différente et avec des contraintes différente.

   La rfc5914 et rfc5934 fournissent des considérations de sécurité additionnelles au regard de la préparation, le stockage, et l'utilisation d'ancres de confiance. La rfc5280 fournis des considérations de sécurité additionnelles au regard de l'utilisation des contraintes de nom.
^
05 août 2015

htmlpdflatexmanmd




rfc6024

rfc6024

Exigences de gestion d'ancre de confiance

   Une ancre de confiance représente une entité autoritative via une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'informations pour lesquelles l'ancre de confiance a autorité. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique en utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance. Ce document décris certains problèmes associées avec le manque de mécanisme de gestion d'ancre de confiance et définis les exigences pour les formats de données et les protocoles conçus pour adresser ces problèmes.

   Les signatures numériques sont utilisées dans de nombreuses applications. Pour que les signatures numériques fournissent l'intégrité et d'authentification, la clé publique utilisée pour vérifier la signature numérique doit être "trustée", par exemple, accepté par un tiers de confiance comme utilisation appropriée dans le contexte donné. Une clé publique utilisée pour vérifier une signature doit être configurée comme une ancre de confiance ou contenue dans un certificat qui peut être vérifiée par une chemin de certification se terminant à l'ancre de confiance. Une ancre de confiance est une clé publique et ses données associées utilisée par un tiers de confiance pour valider une signature sur un objet signé où l'objet est soit:

- Un certificat à clé publique qui commence un chemin de certification terminé par un certificat de signature ou un certificat de chiffrement.
- Un objet, autre qu'un certificat à clé publique ou liste de révocation de certificat, qui ne peut pas être validé via l'utilisation d'un chemin de certification.

   Les ancres de confiance ont seulement une signification locale, par exemple, chaque tiers de confiance (RP) est configuré avec un jeu d'ancres de confiance, soit par le RP ou par l'entité qui gère les TA dans le contexte dans lequel le RP opère. Les données associées définissent le périmètre d'une ancre de confiance en imposant des contraintes sur les signatures qui peuvent être vérifiés en utilisant l'ancre de confiance. Par exemple, si une ancre de confiance est utilisée pour vérifier les signatures dans le certificats X.509, ces contrainte peuvent inclure une combinaison d'espace de noms, de stratégie de certificat, ou de types d'application/utilisation.

   Une utilisation des signatures numérique est la vérification des signatures dans les packages de firmware chargés dans les modules hardware, tels que les modules cryptographiques, boitiers de cables, routeurs, etc. Vu que de tels périphériques sont souvent gérés à distance, les périphériques doivent être capable d'authentifier la source d'interaction de gestion et peuvent utiliser les ancres de confiance pour effectuer cette interaction. Cependant, les ancres de confiance nécessitent également une gestion. D'autres applications nécessitant une gestion d'ancre de confiance incluent les navigateurs web ( qui utilisent les ancres de confiance en authentifiant les serveurs web) et les clients mail ( qui utilisent les ancres de confiance en validant les email signés et en authentifiant les bénéficiaires des mails chiffrés ).

   Toutes les applications qui valident les signatures numériques valide les moyens de gérer un ou plusieurs jeux d'ancre de confiance. Chaque jeu d'ancre de confiance est référé dans ce document à un magasin d'ancres de confiance. Souvent, la manière de gérer les magasins d'ancre de confiance est spécifique à l'application et compte sur des moyens tiers pour établir et maintenir la fiabilité. Une application peut utiliser plusieurs magasins d'ancre de confiance, et un magasin d'ancre de confiance peut être utilisé par plusieurs applications. Chaque magasin d'ancre de confiance est gérée par au moins un gestionnaire TA; un gestionnaire TA peut gérer plusieurs magasins TA.

   Les exigences statuées dans ce document ont été préparés avant la publication des rfc5914 et rfc5934. Le document n'a pas été publié à ce moment pour permettre des changement dans les exigences durant le développement des spécification technique associées. Les exigences décrites ci-dessous sont celles qui ont été considérées durant le développement des rfrc5914 et rfc5934.

   Cette section fournis une introduction et définis la terminologie de base. La section suivante décris les problèmes avec les méthodes de gestion d'ancre de confiance actuelles. Les sections suivantes décrivent les exigences et considérations de sécurité pour une solution de gestion d'ancre de confiance.

Terminologie

   Les termes suivants sont définis pour pouvoir fournir un vocabulaire pour les exigences décrites pour la gestion des ancres de confiance.

Trust Anchor Une ancre de confiance représente une entité autoritative via une clé publique et ses données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisées pour contraindre les types d'information pour lesquels l'ancre de confiance est autoritative. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance.
Trust Anchor Manager Un gestionnaire d'ancre de confiance est une entité responsable de la gestion du contenu d'un magasin d'ancre de confiance. Tout au long de ce document, chaque gestionnaire d'ancre de confiance est assumé être représenté comme, ou délégué par une ancre de confiance distincte.
Trust Anchor Store Un magasin d'ancre de confiance est un jeu d'une ou plusieurs ancres de confiance stockés dans un périphérique. Un magasin d'ancre de confiance peut être géré par un ou plusieurs gestionnaire d'ancre de confiance. Un périphérique peut avoir plus d'un magasin d'ancre de confiance, chaque pouvant être utilisé par une ou plusieurs applications.

Énoncé des problèmes

   Les ancres de confiance sont utilisées pour supporter de nombreux scénarios d'application. Beaucoup de navigateurs internet et le clients mail utilisent les ancres de confiance lors de l'authentification de sessions TLS, en vérifiant les mails signés, et en générant des mails chiffrés en validant un chemin de certification avec le certificat du serveur, le certificat de l'émetteur d'un mail, ou le certificat du destinataire d'un mail. De nombreuses distributions de logiciels sont signées numériquement pour permettre l'authentification des sources du logiciel avant l'installation. Les ancres de confiance qui supportent ces application sont typiquement installés comme partie de l'OS ou application, installés durant un système de gestion de configuration de l'entreprise, ou installé directement par un OU ou une utilisateur.

   Les ancres de confiance sont généralement stockés dans des magasins d'ancre de confiance spécifique à l'application ou spécifique à l'OS. Souvent, une simple machine peut avoir de nombreux magasins d'ancre de confiance qui ne peuvent pas être synchronisés. Examiner le contenu d'un magasin d'ancre de confiance particulier implique généralement l'utilisation d'un outil propriétaire qui interagi avec un type particulier de magasin.

   La présence d'une ancre de confiance dans un magasin particulier véhicule souvent l'autorisation implicite de valider les signatures pour tous les contextes pour lequel le magasin est accédé. Par exemple, la clé publique d'une autorité d'horodatage peut être installée dans un magasin pour valider les signatures dans les horodatages. Cependant, si le magasin contenant ce TA est utilisé par plusieurs applications qui servent différents bit, la même clé pourrait être utilisée de manière inappropriée pour valider d'autres types d'objets tels que les certificats ou les réponses OCSP. Avant la publication de la rfc5914, il n'y avait pas de mécanisme standard pour limiter le périmètre d'une ancre de confiance. Une pratique commune pour adresser ce problème est de placer différents TA dans différents magasins et de limiter le jeu d'application qui accèdent à un magasin TA donné.

   La relation de confiance entre les PKI sont négociées par des autorité de stratégie. Les négociations exigent fréquemment un temps significatif pour s'assurer que toutes exigences des parties participantes sont satisfaites. Ces exigences sont exprimées, dans une certaine mesure, dans les certificats à clé publique via les contraintes de stratégie, les contraintes de noms, etc. Pour pouvoir forcer ces exigences, les magasins d'ancre de confiance doivent être gérés en accord avec les intensions d'autorité de stratégie. Sinon, les contraintes définies dans un cross-certificat pourrait être contournées en reconnaissant le sujet du cross-certificat comme ancre de confiance, qui permettrait d'implémenter des traitement de chemin qui évitent le cross-certificat.

   Les ancres de confiance sont souvent représentés comme des certificats autos-signés, qui ne fournissent généralement aucun moyen d'établir la validité de l'information contenu dans le certificat. La confiance dans l'intégrité d'une ancre de confiance est généralement établie via un moyen externe, souvent en vérifiant l'empreinte du certificat auto-signé avec une source autoritative. Les Opérations de routine d'ancre de confiance nécessitent généralement de telles vérifications externe, si la livraison de la clé d'une ancre de confiance est supportée par CMP. Idéalement, seul le jeu initial d'ancres de confiance qui sont installés dans un magasin de confiance particulier nécessitent une vérification tiers proportionnée avec les exigences de sécurité des applications en utilisant le magasin.

   Malgré d'utilisation répandue des ancres de confiance, il n'y a ni standard pour la découverte du jeu d'ancres de confiance installés dans un magasin particulier ni de moyen standard de gérer ces ancres de confiance. Le reste de ce document décris les exigences pour une solution à ce problème avec certaines considérations de sécurité.

Exigences

   Cette section décris les exigences pour un protocole de gestion d'ancre de confiance. Les exigences sont fournies pour le contenu d'une ancre aussi bien que les opération de gestion des magasins.

Indépendance de transport

   Une solution générale pour la gestion des ancres de confiance doit être indépendant du transport pour pouvoir s'appliquer à divers environnements de communication. Il doit fonctionner dans des environnements orientés session et store-and-forward aussi bien que dans les modèles push and pull. Pour répondre à tous ces modèles de manière uniforme, l'intégrité sans connexion et l'authentification de l'origine des données pour les transaction TA doivent être fournis au niveau applicatif. La confidentialité peut être fournie pour de telles transactions.

Raisonnement

   Tous les périphériques qui utilisent les ancres de confiance ne sont pas disponible pour des opérations de gestion online; certains périphériques peut nécessiter une interaction manuelle pour la gestion des ancres de confiance. L'authentification de l'origine des données et l'intégrité sont requis pour s'assurer que la transaction n'a pas été modifiée en route. Seul l'intégrité sans connexion est requise, pour compatibilité avec les contextes store-and-forward.

pré-requis fonctionnels

   Au minimum, un protocole utilisé pour la gestion d'ancre de confiance doit permettre à un gestionnaire d'ancre de confiance d'effectuer les opérations suivantes:

- Déterminer quels ancres de confiance sont installées dans un magasin particulier
- Ajouter une ou plusieurs ancres de confiance à un magasin
- Supprimer une ou plusieurs ancres de confiance d'un magasin
- Remplacer tout un magasin

   Un protocole le gestion d'ancre de confiance doit fournir un support pour ces opérations basiques; cependant, toutes les implémentations ne supportent pas chaque options. Par exemple, certaines implémentations peuvent supporter seulement le remplacement des magasins.

   Ces exigences décrivent les opérations requises pour gérer le contenu d'un magasin d'ancre de confiance. Une opération d'édition a été omise pour des raisons de simplicité, avec des suppressions consécutives et opérations d'ajouts utilisés dans ce but. Une simple opération d'ajout ou suppression peut agir sur plus d'une ancre de confiance pour éviter les aller-retours inutiles et sont fournis pour éviter le besoins de toujours remplacer tout un magasin. Le remplacement d'un magasin peut être utile comme une opération alternative aux opérations d'ajouts et suppression.

Gestion des cibles

   Une protocole pour la gestion TA doit permettre à une transaction TA d'être dirigée vers:

- Tous les magasins TA dont le manager est responsable
- Une liste énumérée d'un ou plusieurs groupes nommés de magasins
- un magasin d'ancre de confiance individuel

   Les connexions entre les PKI peuvent être accomplies en utilisant différents moyens. La cross-certification unilatérale ou bilatérale peut être effectuée, ou une communauté peut simplement élire pour accepter explicitement une ancre de confiance depuis une autre communauté. Généralement, ces décisions se font dans l'entreprise. Dans certains scénarios, il peut être utile d'établir ces connexions pour une petite communauté dans une entreprise. Les mécanismes des grandes entreprises, tel que les cross-certificats sont mal adaptés à cet effet vu que la révocation du certificat affecte l'ensemble de l'entreprise.

   Un protocole de gestion d'ancre de confiance peut adresser ce problème en supportant l'installation limitée des ancres de confiance (ex, l'installation des TA dans des sous-jeux de communauté d'utilisateurs de l'entreprise), et en supportant l'expression des contraintes dans l'utilisation des ancres de confiance par des tiers de confiance. L'installation limitée nécessite la capacité d'identifier les membre de la communauté qui sont destinés à s'appuyer sur une ancre de confiance particulière, et la capacité de vérifier et reporter le contenu des magasins. Les contraintes d'ancre de confiance peuvent être utilisés pour représenter les limitations qui peuvent être exprimées dans un cross-certificat, et l'installation limitée assure que la reconnaissance de l'ancre de confiance ne comprend par nécessairement toute une entreprise.

   Les configuration d'ancre de confiance peuvent être uniforme dans une entreprise, ou peuvent être unique à une simple application ou un petit jeu d'applications. De nombreux périphériques et certaines application utilisent plusieurs magasins. En fournissant un moyen d'adresser un magasin spécifique ou une collection de magasins, un protocole de gestion d'ancre de confiance peut permettre une gestion efficace de tous les magasins sous le contrôle d'un gestionnaire d'ancre de confiance.

Délégation de l'autorité du gestionnaire TA

   Un protocole de gestion d'ancre de confiance doit permettre un transfert sécurité du contrôle d'un magasin d'ancre de confiance d'une manager à un autre. Il devrait également permettre la délégation pour les opérations spécifiques sans nécessiter de délégation de toutes les capacités de gestion d'ancres de confiance.

   Le renouvellement de clé du gestionnaire d'ancre de confiance est un type de transfert qui doit être supporté. Dans ce cas, la nouvelle clé sera assignée aux mèmes privilèges que l'ancienne clé.

   La création des ancres de confiance pour des buts spécifiques, tels que la signature de firmware, est un autre exemple de délégation. Par exemple, un gestionnaire d'ancre de confiance peut déléguer seulement d'autorité de signer des firmware à une entité, mais interdit d'autres délégations de ce privilège, ou le gestionnaire d'ancre de confiance peut autorisé la délégation à d'autres autorités de signature de firmwares délégués à d'autres entités.

Support rfc 5280

   Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui seront utilisé pour valider les chemins de certification et les CRL en accord avec les rfc5280 et rfc5055. Un format d'ancre de confiance doit permettre la représentation de contraintes qui influencent la validation de chemin de certification ou l'établissement de périmètre d'utilisation de la clé publique de l'ancre de confiance. Des exemples de telles contraintes sont les contraintes de noms, les stratégies de certificat, et l'utilisation de clé.

   La validation de chemin de certification est une des applications d'ancre de confiance les plus communes. Les règles pour utiliser les ancres de confiance pour la validation de chemin sont établis dans la rfc5280. La rfc5055 décris l'utilisation des ancres de confiance pour la validation de chemin déléguée. Les ancres de confiance utilisée pour valider les chemins de certification sont responsable de la livraison, possiblement via une délégation, des informations de statut de révocation des certificats qu'il émet; c'est souvent accomplis en signant une CRL.

Autres supports

   Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui peuvent être utilisé pour d'autres buts que la validation de chemin de certification, incluant les ancres de confiance qui ne peuvent pas être utilisé pour la validation de chemin de certification. Il devrait être possible d'autoriser une ancre de confiance à déléguer l'autorité (à d'autres TA ou propriétaires de certificat) et d'empêcher une ancre de confiance d'être délégué.

   Les ancres de confiance sont utilisées pour valider une variété d'objets signés, pas seulement les certificats à clé publique et les CRL. Par exemple, une ancre de confiance peut être utilisée pour vérifier les packages de firmware (rfc5108), les réponses OCSP (rfrc2560), les réponses SCVP (rfc5055), ou les horodatages (rfc3161). Les TA qui sont autorisées pour l'utilisation de certains de ces types d'opérations ne peuvent pas être autorisés pour vérifier les certificats à clé publique ou les CRL. Donc, il est important d'être capable d'imposer des contraintes sur la manière dont un TA donné est employé.

Format d'ancre de confiance

   Au minimum, un protocole de gestion d'ancre de confiance doit supporter la gestion des ancres de confiances représentés comme certificats auto-signés et les ancres de confiance représentés comme un nom distinct, informations de clé publique, et, optionnellement, les données associées. La définition d'une ancre de confiance doit inclure une clé publique, un algorithme de clé publique, et, si nécessaire, les paramètres de la clé publique. Quand la clé publique est utilisée pour valider les chemins de certification ou les CRL, un nom distinct doit également être inclus (rfc5280). Un format d'ancre de confiance doit permettre la spécification d'un identifiant de clé publique pour permettre à d'autres applications d'ancre de confiance, par exemple, la vérification des données signées en utilisant la structure SignedData (CMS - rfc5652). Un format d'ancre de confiance devrait également permettre la représentation des contraintes qui peuvent être appliquées pour restreindre l'utilisation d'une ancre de confiance.

   Avant la publication de la rfc5914, il n'y avait pas de format d'ancres de confiance. Les certificats X.509 auto-signés sont généralement utilisés, mais la rfc5280 ne mandate par la représentation d'ancre de confiance particulier. Elle exige seulement que les information de clé publique de l'ancre de confiance et le nom distinct soit disponible durant la validation du chemin de certification. CMS est largement utilisé pour protéger divers types de contenu en utilisant les signatures numériques, incluant le contenu qui peut être vérifié directement en utilisant une ancre de confiance, tels que les packages de firmware. Les contraintes peuvent inclure une périodes de validité, des contraintes sur la validation de chemin de certification, etc.

Authentification

   Une entité reçevant une donnée de gestion d'ancre de confiance doit être capable d'authentifier l'identité du partie en fournissant les informations et doit être capable de confirmer que le partie est autorisé à fournir ces informations.

   Un gestionnaire d'ancre de confiance doit être capable d'authentifier quel magasin d'ancre correspond à un listing du contenu du magasin et être capable de confirmer que le contenu du listing n'a pas été altéré.

   L'authentification de l'origine des données et l'intégrité sont requis pour supporter les opération de gestion à distance, même quand les transaction de gestion des TA sont effectuées via des communications store-and-forward.

Réduire la dépendance des mécanimes tiers

   En effectuant des opérations d'ajout, un protocole de gestion d'ancre de confiance devrait permettre de vérifier automatiquement l'intégrité des TA par un tiers de confiance sans s'appuyer sur des mécanismes tiers.

   Traditionnellement, une ancre de confiance est distribuée via un mécanisme tiers avec vérification manuelle de l'intégrité avant l'installation. L'installation est généralement effectuée par quelqu'un avec suffisamment de privilèges administratifs dans le système recevant l'ancre de confiance. La fiabilité des mécanismes de confiance tiers est un problème avec les approches de gestion des ancre de confiance actuelles, et la réduction du besoin de mécanismes tiers est une motivation principale pour le développement de mécanismes de gestion d'ancre de confiance. Idéalement, les mécanismes tiers sont requis seulement durant l'initialisation du magasin.

Détection des répétitions

   Un protocole de gestion d'ancre de confiance doit permettre aux participants engagés dans l'échange du protocole de gestion de détecter les attaques replay. Un mécanisme de détection de replay qui n'introduit pas d'exigence pour une source sûre de temps doit être disponible. Les mécanismes qui ne nécessitent pas de source sûre de temps peuvent être disponibles.

   La détection de replay des transactions de gestion d'ancre de confiance est requise pour supporter les opérations de gestion distantes. Le replay d'anciennes transaction pourraient résulter en la réintroduction d'ancres de confiance compromises. Certains périphériques qui utilisent les ancres de confiance n'ont pas accès à une source de temps sûre, donc un mécanisme de détection de replay qui nécessite une source de temps sûre est insuffisant.

Compromission ou récupération après sinistre

   Un protocole de gestion d'ancre de confiance doit permettre la récupération lors de la compromission ou la perte de la clé privée d'une ancre de confiance, incluant la clé privée autorisée à service de gestion d'ancre de confiance, sans nécessiter la ré-initialisation du magasin.

   La compromission ou la perte d'une clé privée correspondant à une ancre de confiance peut avoir des conséquences négatives significatives. Actuellement, dans certains cas, la ré-initialisation de tous les magasin affectés est requise pour récupérer lors d'une perte ou d'une compromission d'une clé d'ancre de confiance. À cause du coût associés avec la ré-initialisation, un protocole de gestion d'ancre de confiance devrait supporter les options de récupération qui ne nécessitent pas de ré-initialisation du magasin.

Considérations de sécurité

   La clé publique utilisé pour authentifier une transaction de gestion TA peut avoir été placée dans le client comme résultat d'une première transaction de gestion TA ou durant une configuration initiale. Dans de nombreux scénarios, au moins une clé publique autorisé pour la gestion d'ancre de confiance doit être placée dans chaque magasin d'ancre de confiance. Cette clé publique peut être transporté et vérifiée en utilisant des moyens tiers. Dans tous les scénarios, sans regarder le mécanisme d'authentification, au moins un gestionnaire d'ancre de confiance doit être établis pour chaque magasin d'ancre de confiance durant la configuration initiale du magasin.

   La compromission d'une clé privée d'une ancre de confiance peut résulter en de nombreux problèmes de sécurité, incluant l'émission de sécurité compromis ou des ancres de confiance volé.

   L'utilisation de contraintes basées sur l'ancre de confiance nécessite une grande attention en définissant les ancres de confiance. Des erreurs de la part d'un gestionnaire pourrait résulter des déni de service ou des conséquences de sécurité sérieuses. Par exemple, si une contrainte de nom pour une ancre de confiance qui sert de racine d'une PKI inclus une faute de frappe, il en résulte un déni de service pour les propriétaires de certificats. Si un gestionnaire d'ancre de confiance délègue par inadvertance tous ses privilège et les délégations suppriment le gestionnaire d'ancre de confiance des magasins d'ancre de confiance sous son contrôle, la récupération peut nécessiter la ré-initialisation de tous les magasins d'ancre de confiance affectés.

   La rfc5280 nécessite que la validation de chemin de certificat soit initialisée avec un nom du sujet TA et une clé publique, mais n'exige pas le traitement d'autres information, tels quel les contraintes de nom. L'inclusion de contraintes dans les ancres de confiance est optionnelle. Quand des contraintes sont explicitement incluse par un gestionnaire d'ancre de confiance en utilisant un protocole de gestion d'ancre de confiance, on s'attend à ce que l'algorithme de validation de chemin de certification utilise ces contraintes. Les propriétaires d'application doivent confirmer l'implémentation de traitement de chemin supportant le traitement des contraintes basées sur TA, si requis.

   De nombreuses considération de sécurité de la rfc5280 sont également applicable à la gestion des ancres de confiance.
^
02 novembre 2013

htmlpdflatexmanmd




rfc6171

rfc6171

Contrôle Don't Use Copy

   Cette extension peut être attachées au requêtes pour indiquer que les informations copiées (répliquées ou cachées) ne sont pas utilisés pour fournis des services. Il est principalement utilisé quand un client demande que le service soit fournis depuis la données originale (master).

   Ce contrôle est un contrôle LDAP dont controlType est 1.3.6.1.1.22 et controlValue est absent. La criticité doit est spécifiée. Le contrôle est approprié pour les opérations compare et search, mais pas pour les autres. Quand le contrôle est attaché à une requête, l'opération ne doit pas être effectuée sur une opération copiée. Si l'information originale n'est pas disponible, le serveur doit retourner un référant qui redirige le client vers un serveur capable de réponse à la requête ou retourner un code approprié (ex: unwillingToPerform).

   Quand un client est redirigé vers un référant, il doit fournir dontUseCopy avec la requête qu'il fait au référant.

^
14 août 2015

htmlpdflatexmanmd




rfc6960

rfc6960

Online Certificate Status Protocol - OCSP

   Ce document spécifie un protocole utile pour déterminer le statut courant d'un certificat numérique sans nécessiter de CRL. Des mécanismes additionnels adressant les exigences opérationnelles PKIX sont spécifiés dans des documents séparés.

   À la place de, ou en supplément de, vérifier avec une CRL périodique, il peut être nécessaire d'obtenir des informations rapide du status de révocation des certificats. Le protocole de statut de certificat en ligne (OCSP) permet aux applications de déterminer l'état d'un certificat identifié. OCSP peut être utilisé pour satisfaire certaines exigences opérationnelles en fournissant des informations de révocation plus récente qu'il est possible avec les CRL et peut également être utilisé pour obtenir des informations de statut additionnels. Un client OCSP émet une demande de statut à un répondeur OCSP et suspend l'acceptation des certificats en question jusqu'à ce que le répondeur fournir une réponse.

   Ce protocole spécifie les données qui doivent être échangées entre une application vérifiant le statut d'un ou plusieurs certificat le serveur fournissant le statut correspondant.

Requête

   Une demande OCSP contient les données suivantes:

- Une version de protocole
- Une demande de service
- Un identifiant du certificat cible
- Des extensions optionnelles, qui peuvent être traitées par le répondeur OCSP

   Une fois le demande reçue, un répondeur OCSP détermine si:

1. Le message est bien formé
2. Le répondeur est configuré pour fournir le service demandé
3. La demande contient les informations nécessaire.

   Si une de ces conditions n'est pas rencontrée, le répondeur OCSP produit un message d'erreur; sinon, il retourne une réponse définitive.

Réponse

   Les réponses OCSP peuvent être de différents types. Une réponse OCSP consiste d'un type de réponse et les octets de la réponse. Il y a un type de base de réponse OCSP qui doit être supporté par tous les serveur et clients OCSP. Le reste de cette section concerne seulement ce type de réponse de base.

   Tous les messages de réponse définitives doivent être signés numériquement. La clé utilisée pour signer la réponse doit appartenir à un parmi:

- La CA qui a émis le certificat en question
- Un répondeur trusté dont la clé publique est validé par le demandeur
- Un Répondeur désigné par la CA (Répondeur autorisé) qui maintient un certificat spécialement marqué émis directement par la CA, indiquant que le répondeur peut émettre des réponses OCSP pour cette CA.

   Un message de réponse définitive est composée de:

- La version de la syntaxe de la réponse
- L'identifiant du répondeur
- L'horodatage de la génération de la réponse
- Les réponses pour chaque certificat dans la demande
- Des extensions optionnelles
- L'OID de l'algorithme de signature
- La signature calculée par un hash de la réponse

   La réponse pour chaque certificat dans la demande consiste de:

- L'identifiant de certificat cible
- La valeur du statut du certificat
- L'interval de validité de la réponse
- Des extensions optionnelles.

   Cette spécification définis les indicateurs de la réponse définitive à utiliser dans la valeur de statut de certificat:

- good
- revoked
- unknown

   L'état "good" indique une réponse positive. Au minimum, cette réponse positive indique qu'aucun certificat avec le numéro de série demandé dans son interval de validité n'est révoqué. Cet état ne signifie pas nécessairement que le certificat a été émis ou que l'heure à laquelle la réponse a été produite est dans un intervalle de validité du certificat. Les extensions de réponse peuvent être utilisés pour transporter des informations additionnelles sur l'affirmation faite par le répondeur au regard du statut du certificat, tels que la déclaration positive sur l'émission, la validité, etc.

   L'état 'revoked' indique que le certificat a été révoqué, soit temporairement (certificateHold) soit de manière permanente. Cet état peut également être retourné si la CA associée n'a pas d'enregistrement de certificat émis avec le numéro de série du certificat dans la demande, en utilisant la clé courante ou précédente (référé à un certificat 'non-émis' dans ce document).

   L'état 'unknown' indique que le répondeur ne connaît pas le certificat demandé, généralement parce que le demandeur indique un émetteur non connus qui ne sert par ce répondeur.

   NOTE: Le statut 'revoked' indique qu'un certificat avec le numéro de série demandé devrait être rejeté, alors que le statut 'unknown' indique que le statut ne peut pas être déterminé par ce répondeur, permettant ainsi au client de décider s'il veut tenter une autre source d'information de statut (tel qu'une CRL). Cela rend la réponse 'revoked' prévue pour les certificats non-émis où l'intention du répondeur est de forcer le client à rejeter le certificat au lieu de tenter une autre source. Le statut 'revoked' est optionnel pour les certificats non-émis pour pouvoir maintenir la compatibilité avec les déploiements rfc2560. Par exemple, le répondeur peut ne pas avoir connaissance si un numéro de série demandé a été assigné à un certificat émis, ou le répondeur peut fournir des réponses pré-produites en accord avec la rfc5019 et, pour cette raison, il n'est pas capable de fournir une réponse signée pour tous les numéro de série non-émis.

   Quand un répondeur envoie une réponse 'revoked' à une demande de statut pour un certificat non-émis, le répondeur doit inclure l'extension de réponse de définition révoqué étendue dans la réponse, indiquant que le répondeur OCSP supporte la définition étendue de l'état 'revoked' pour couvrir également les certificats non-émis. En plus, le SingleResponse lié à ce certificat non-émis:

- Doit spécifique la raison de révocation certificateHold
- Doit spécifier le revocationTime au 1 Janvier 1970
- Ne doit pas inclure une extension de référence de CRL ou une extension d'entrée de CRL.

Exceptions

   En cas d'erreurs, le répondeur OCSP peut retourner un message d'erreur. Ces messages ne sont pas signés. Les erreurs peuvent être d'un des types suivant:

- malformedRequest
- internalError
- tryLater
- sigRequired
- unauthorized

   Un serveur produit la réponse 'malformedRequest' si la requête reçue n'est pas conforme à la syntaxe OCSP.

   La réponse 'internalError' indique que le répondeur OCSP a atteins un état inconsistant. La demande devrait être retentée potentiellement avec un autre répondeur.

   Dans le cas ou le répondeur OCSP est opérationnel mais incapable de retourner un status pour le certificat demandé, la réponse 'tryLater' peut être utilisée pour indiquer que le service existe mais est temporairement en incapacité de répondre.

   La réponse 'sigRequired' est retournée dans le cas où le serveur exige que le client signe la demande pour pouvoir construire la réponse.

   La réponse 'unauthorized' est retournée dans les cas où le client n'est pas autorisé à faire cette demande à ce serveur ou le serveur n'est pas capable de répondre autoritativement.

Sémantiques thisUpdate, nextUpdate, et produceAt

   Les réponses définies dans ce document peuvent contenir 4 dates -- thisUpdate, nextUpdate, producedAt, et revocationTime. La sémantique de ces champs est:

thisUpdate La date la plus récente à laquelle le statut est connu du répondeur pour être correct.
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles
producedAt La date à laquelle le répondeur a signé cette réponse
revocationTime La date à laquelle le certificat a été révoqué.

Pré-production de réponse

   Les répondeurs OCSP peuvent pré-produire des réponses signées spécifiant le statut des certificats à une date spécifiée. La date à laquelle le statut est connu pour être correct doit être refléter dans le champ thisUpdate de la réponse. La date à ou avant laquelle la nouvelle information sera disponible est reflété dans le champ nextUpdate, alors que la date à laquelle la réponse a été produite apparaît dans le champ producedAt de la réponse.

Délégation de l'autorité de signature OCSP

   La clé qui signe les informations de statut de certificat n'a pas besoin d'être la même que celle qui a signé le certificat. Un émetteur de certificat peut explicitement déléguer l'autorité de signature OCSP en émettant un certificat contenant une valeur unique pour l'extension d'utilisation de clé étendue dans le certificat du signataire OCSP. Ce certificat doit être émis directement au répondeur par la CA.

Clé CA compromise

   Si un répondeur OCSP sait qu'une clé privé de CA particulière a été compromise, il peut retourner l'état 'revoked' pour tous les certificats émis par cette CA.

Contenu du certificat

   Pour transporter aux clients OCSP un point d'accès aux informations, les CA doivent fournir la capacité d'inclure l'extension d'information d'accès de l'autorité dans les certificats qui peuvent être vérifiés en utilisant OCSP. Alternativement, l'accessLocation pour le fournisseur OCSP peut être configuré localement dans le client OCSP.

   Les CA qui supportent un service OCSP, soit maintenus localement ou fournis par un répondeur autorisé, doivent fournir un URI accessLocation et l'OID id-ad-ocsp pour l'accessMethod dans la séquence AccessDescription.

   La valeur du champ accessLocation dans le certificat du sujet définis le transport (ex: HTTP) utilisé pour accéder au répondeur OCSP et peut contenir d'autres informations dépendantes du transport (ex: une URL).

Exigence pour l'acceptation de réponse signée

   Avant d'accepter une réponse signée pour un certificat particulier comme valid, les clients OCSP doivent confirmer que:

1. Le certificat identifié dans la réponse reçue correspond au certificat qui a été identifié dans la demande correspondant
2 La signature dans la réponse est valide
3. L'identité du signataire correspond au destinataire prévu de la demande
4. Le signataire est actuellement autorisé à fournir une réponse pour le certificat en question
5. La date à laquelle le statut a été indiqué est correct est suffisamment récente
6. Si disponible, la date à laquelle ou avant laquelle de nouvelles informations seront disponible est supérieurs à la date courante.

Détails du protocole

   La syntaxe ASN.1 importe les termes définis dans la rfrc5280. Pour le calcul de la signature, la donnée à signer est encodée en utilisant DER. Le tagging explicite ASN.1 est utilisé comme défaut sauf si le contraire est mentionné. Les termes importés d'ailleurs sont Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, et CRLReasons.

Syntaxe de la demande

   Cette section spécifie la spécification ASN.1 pour une demande de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc).

La structure ASN.1 correspondant à OCSPRequest est:
OCSPRequest ::= SEQUENCE {
    tbsRequest TBSRequest,
    optionalSignature [0] EXPLICIT Signature OPTIONAL }
    
TBSRequest ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    requestorName [1] EXPLICIT GeneralName OPTIONAL,
    requestList SEQUENCE OF Request,
    requestExtensions [2] EXPLICIT Extensions OPTIONAL }
    Signature ::= SEQUENCE {
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}
    
Version ::= INTEGER { v1(0) }
    
Request ::= SEQUENCE {
    reqCert CertID,
    singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
    
CertID ::= SEQUENCE {
     AlgorithmIdentifier,
    issuerNameHash OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash OCTET STRING, -- Hash of issuer's public key
    serialNumber CertificateSerialNumber }

- tbsRequest est la demande OCSP optionnellement signée
- optionalSignature contient l'identifiant d'algorithme et ses paramètres associés dans signatureAlgorithm; la valeur de la signature dans signature; et optionnellement les certificat que le serveur a besoin pour vérifier la signature.
- version indique la version du protocole, qui est v1 (0) pour ce document.
- requestorName est optionnel est indique le nom du demandeur OCSP
- requestList contient une ou plusieurs demande de statut de certificat.
- requestExtensions est optionnel et inclus des extensions applicable aux demandes trouvées dans reqCert.
- reqCert contient l'identifiant d'un certificat cible
- singleRequestExtensions est optionnel et inclus des extensions applicable à cette demande de statut de certificat.
- hashAlgorithm est l'algorithme de hashage utilisé pour générer les valeurs issuerNameHash et issuerKeyHash.
- serialNumber est le numéro de série du certificat pour lequel le statut est demandé

Notes sur les demandes OCSP

   La principale raison d'utiliser la hash de la clé publique de la CA en plus du hash de nom de la CA pour identifier l'émetteur est qu'il est possible qui 2 CA choisissent d'utiliser le même nom. 2 CA ne vont jamais, cependant, avoir la même clé publique sauf si les CA on choisis d'utiliser la même clé explicitement, ou si une des clés de CA est compromise.

   Le support pour une extension spécifique est optionnel. Le flag de criticité ne devrait pas être utilisé. Les extensions non-reconnus doivent être ignorés, sauf si la criticité est définie.

   Le demandeur peut choisir de signer la demande OCSP. Dans ce cas, la signature est calculée sur la structure tbsRequest. Si la demande est signée, le demandeur doit spécifier son nom dans le champ requestorName. Également, pour les demandes signées, le demandeur peut inclure les certificats qui aident le répondeur OCSP à vérifier la signature de demandeur dans le champ certs de Signature.

Syntaxe de la réponse

   Cette section spécifie la spécification ASN.1 pour une réponse de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport.

Une réponse OCSP consiste au minimum d'un champ responseStatus indiquand le traitement du statut de la demande. Si la valeur de responseStatus est une des conditions d'erreur, le champ responseBytes n'est pas mis.
OCSPResponse ::= SEQUENCE {
    responseStatus OCSPResponseStatus,
    responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
    
OCSPResponseStatus ::= ENUMERATED {
    successful (0), -- Response has valid confirmations
    malformedRequest (1), -- Illegal confirmation request
    internalError (2), -- Internal error in issuer
    tryLater (3), -- Try again later
            -- (4) is not used
    sigRequired (5), -- Must sign the request
    unauthorized (6) -- Request unauthorized
}

La valeur pour responseBytes consiste d'un identifiant d'objet et d'une syntaxe response identifiée par cet OID encodé comme chaîne d'octets.
ResponseBytes ::= SEQUENCE {
    responseType OBJECT IDENTIFIER,
    response OCTET STRING }

Pour un répondeur OCSP basique, responseType sera id-pkix-ocsp-basic
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

   Les répondeurs OCSP doivent être capable de produire des réponses de type id-pkix-ocsp-basic. Les clients OCSP doivent être capable de recevoir et traiter les réponse de type id-pkix-ocsp-basic.

La valeur pour la réponse doit être un encodé DER de BasicOCSPResponse
BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData ResponseData,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

La valeur pour la signature doit être calcurée sur le hash de l'encodé DER de ResponseData. Le répondeur peut inclure des certificats dans le champs certs pour aider le client OCSP à vérifier le signature du répondeur. Si aucun certificat n'est inclus, alors certs devrait être absent.
ResponseData ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    responderID ResponderID,
    producedAt GeneralizedTime,
    responses SEQUENCE OF SingleResponse,
    responseExtensions [1] EXPLICIT Extensions OPTIONAL }
    
    ResponderID ::= CHOICE {
    byName [1] Name,
    byKey [2] KeyHash }
    
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)
    
SingleResponse ::= SEQUENCE {
    certID CertID,
    certStatus CertStatus,
    thisUpdate GeneralizedTime,
    nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
    singleExtensions [1] EXPLICIT Extensions OPTIONAL }
    
CertStatus ::= CHOICE {
    good [0] IMPLICIT NULL,
    revoked [1] IMPLICIT RevokedInfo,
    unknown [2] IMPLICIT UnknownInfo }
    
RevokedInfo ::= SEQUENCE {
    revocationTime GeneralizedTime,
    revocationReason [0] EXPLICIT CRLReason OPTIONAL }
    
UnknownInfo ::= NULL

Notes sur les réponses OCSP

   Les réponses peuvent contenir 4 dates -- thisUpdate, nextupdate, producedAt, et revocationTime. Les sémantiques de ces champs sont définis plus haut. Le format pour GeneralizedTime est définis dans la rfc5280.

   Les champs thisUpdate et nextUpdate définissent un intervalle de validité recommandé. Cet intervalle corresponds à l'interval {thisUpdate, nextUpdate} dans les CRL. Les réponses dont la valeur nextUpdate est avant l'heure système local devraient être considérés comme non sûr. Les réponses dont thisUpdate est ultérieur à la date système local devraient être considérés comme non-sûr.

   Si nextUpdate n'est pas mis, le répondeur indique que de nouvelles informations sont disponible tout le temps.

Répondeurs autorisés

   La clé qui signe les informations de statut d'un certificat n'a pas besoin d'être la même clé que celle qui a signé le certificat. Il est nécessaire, cependant, de s'assurer que l'entité qui signe ces informations est autorisée à le faire. Ainsi, un émetteur de certificat doit faire une des opérations suivantes:

- Signer les réponses OCSP lui-même
- Désigner explicitement cette autorité à une autre entité.

   La délégation de signature OCSP doit être désignée en incluant id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue inclue dans le certificat du répondeur OCSP. Ce certificat doit être émis directement par la CA qui est identifiée dans la requête.

   La CA devrait utiliser la même clé pour émettre un certificat de délégation que celle utilisée pour signer le certificat à vérifier. Les systèmes s'appuyant sur les réponses OCSP doivent reconnaître un certificat de délégation comme étant émis par la CA qui a émis le certificat en question seulement si le certificat de délégation et le certificat à vérifier ont été signés par la même clé.

Note: Pour des raisons de compatibilité avec la rfc2560, il n'est pas interdit d'émettre un certificat pour un répondeur autorisé en utilisant une clé différente que la clé utilisée pour émettre le certificat à vérifier. Cependant, une telle pratique est fortement découragée, vu que les clients ne sont pas obligés de reconnaître un répondeur avec un tel certificat comme répondeur autorisé.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Les systèmes ou applications qui reposent sur les réponses OCSP doivent être capable de détecter et forcer l'utilisation de la valeur id-kp-OCSPSigning comme décris plus haut. Ils peuvent fournir un moyen de configurer localement une ou plusieurs autorités de signature OCSP et d-e spécifier un jeu de CA pour lesquelles chaque autorité de signature est validée. Ils doivent rejeter la réponse si le certificat exige de valider la signature dans la réponse qui ne rencontre pas un des critères suivants:

1. Correspond à une configuration locale de l'autorité de signature OCSP pour le certificat en question
2. Est le certificat de la CA qui a émis le certificat en question
3. Inclus une valeur id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue et est émis par la CA qui a émis le certificat en question comme statué plus haut.

   D'autre critères d'acceptation ou de rejet peuvent d'appliquer à la réponse ou au certificat utilisé pour valider la signature dans la réponse.

Vérification de révocation d'un répondeur autorisé

   Vu qu'un répondeur OCSP autorisé fournis des informations de statut pour une ou plusieurs CA, les clients OCSP doivent savoir comment vérifier que le certificat d'un répondeur autorisé n'a pas été révoqué. Les CA peuvent choisir de répondre à ce problème d'une des 3 manières suivantes:

- Une CA peut spécifier qu'un client OCSP peut truster un répondeur pour la durée de vie du certificat du répondeur. La CA le fait en incluant l'extension id-pkix-ocsp-nocheck. Cette extension devrait être non-critique. La valeur de l'extension doit être null. Les CA émettant un tel certificat doivent réaliser qu'une clé de répondeur compromise est aussi sérieux que la compromission de la clé de la CA. utilisée pour signer les CRL, au moins pour la période de validité de ce certificat. Les CA peuvent choisir d'émettre ce type de certificat avec une durée de vie très courte et le renouveler fréquemment.
- Une CA peut spécifier comment le certificat du répondeur est vérifié pour la révocation. Cela peut être fait en utilisant les points de distribution de CRL si la vérification devrait être faite en utilisant les CRL, ou en utilisant les accès d'information de l'autorité si la vérification devrait être faite d'une autre manière.
- Une CA peut choisir de ne pas spécifier de méthode de vérification de révocation pour le certificat du répondeur, auquel cas il sera du ressort de la stratégie de sécurité locale du client OCSP de décider si ce certificat devrait être vérifié pour la révocation ou non.

Réponse de base

   Le type de réponse de base contient:

- La version de la syntaxe de réponse, qui doit être v1 (0) pour ce document
- Soit le nom du répondeur ou un hash de la clé publique du répondeur dans ResponderID.
- La date à laquelle la réponse a été générée.
- Les réponses pour chaque certificats dans une requête
- Des extensions optionnelles
- Une signature calculée via un hash de la réponse
- L'OID de l'algorithme de signature.

   Le but de l'information ResponderID est de permettre aux clients de trouver le certificat utilisé pour signer une réponse OCSP signée. Cependant, l'information doit correspondre au certificat qui a été utilisé pour signer la réponse. Le répondeur peut inclure des certificats dans le champ certs de BasicOCSPResponse qui aide le client OCSP à vérifier la signature du répondeur.

- Un identifiant du certificat pour lequel les informations de statut de révocation sont fournies
- Le statut de révocation du certificat (good, revoked, ou unknown); si révoqué, il indique la date à laquelle le certificat a été révoqué et, optionnellement, la raison de la révocation.
- L'intervalle de validité de la réponse
- Des extensions optionnelles.

   La réponse doit inclure un SingleResponse pour chaque certificat dans la demande. La réponse ne devrait pas inclure d'élément SingleResponse additionnels, mais, par exemple, les répondeurs OCSP qui pré-génèrent les réponses peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération des réponses ou l'efficacité des cache.

Algorithmes cryptographiques obligatoires et optionnels

   Les clients qui requièrent les services OCSP doivent être capable de traiter les réponses signées en utilisant RSA avec SHA-256 (OID sh256WithRSAEntryption - rfc4055). Les clients devraient être également capable de traiter les réponses signées en utilisant RSA avec SHA-1 et DSA avec SHA-1. Les client peuvent supporter d'autres algorithmes.

Extensions

   Cette section définis des extensions standards, basées sur le modèle d'extension employé dans le certificats X.509v3. Le support pour toutes les extensions est optionnel pour les clients et les répondeurs. Pour chaque extension, la définition indique sa syntaxe, le traitement effectué par le répondeur, et les extensions qui sont incluses dans la réponse correspondante.

Nonce

Le nonce lie cryptographiquement une demande et une réponse pour empêcher les attaques replay. Le nonce est inclus comme une des requestExtensions dans les demandes, et est inclus dans les réponses comme une des responseExtensions. Dans la demande et la réponse, nonce sera identifié par l'identifiant d'objets id-pkix-ocsp-nonce, alors que extnValue est la valeur de nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
    
Nonce ::= OCTET STRING

CRL References

Il peut être désirable pour un répondeur OCSP d'indiquer la CRL dans laquelle un certificat revoqué ou onHold est trouvé. Cela peut être utile quand OCSP est utilisé entre des dépôts, et également comme mécanisme d'audit. La CRL peut être spécifiée par une URL, un numéro de CRL, ou une date de création de la crl. Ces extensions sont spécifiés comme singleExtensions. L'identifiant pour cette extension est ip-pkix-ocsp-crl, et la valeur est CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
    
CrlID ::= SEQUENCE {
    crlUrl [0] EXPLICIT IA5String OPTIONAL,
    crlNum [1] EXPLICIT INTEGER OPTIONAL,
    crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }

   Pour le choix crlUrl, l'IA5String va spécifier l'URL à laquelle la CRL est disponible. Pour crlNum, l'INTEGER spécifique la valeur de l'extension crlNumber. Pour crlTime, le GeneralizedTime indique la date à laquelle la crl a été émise.

Type de réponse acceptable

Un client OCSP peut souhaiter spéifier le type de réponse qu'il comprend. Pour cela, il devrait utiliser une extension avec l'OID id-pkix-ocsp-response et la valeur AcceptableResponses. Cette extensio est inclue comme une des requestExtensions dans les demandes. Les OID inclus dans AcceptableResponses sont les OID des types de réponse que ce client peut accepter.
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
    
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   Comme noté plus haut, les répondeurs OCSP doivent être capable de répondre avec les réponses de type ip-pkix-ocsp-basic. Les clients OCSP doivent être capable de reçevoir et de traiter ce type de réponse également.

Archive Cutoff

   Un répondeur OCSP peut choisir de retenir les informations de révocation au-delà de l'expiration du certificat. La date obtenue en soustrayant cet intervalle de rétention de producedAt dans une réponse est définie comme la date "archive cutoff" du certificat.

   Les applications qui utilisent OCSP utilisent la date d'archive cutoff pour contribuer à une preuve qu'une signature numérique était ( ou n'était pas ) fiable à la date à laquelle elle a été produite même si sa signature a expiré depuis longtemps.

Les serveurs OCSP qui fournissent le support pour un tel historique devraient inclure l'extension Archive cutoff dans les réponses. Si inclus, cette valeur devrait être fournie comme extension singleExtensions idenitifié par id-pkix-ocsp-archive-cutoff et de syntaxe GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
    
ArchiveCutoff ::= GeneralizedTime

   Pour illustrer, si un serveur opère avec une stratégie de rétention de 7 ans et le statut a été produit au temp t1, alors la valeur ArchiveCutoff dans la réponse sera ( t1 -7 ans ).

Extensions d'entrée CRL

   Toutes les extensions spécifiées comme extensions d'entrée de CRL sont également supportés comme singleExtensions.

Service Locator

Un serveur OCSP peut être opéré dans un mode par lequel le serveur reçoit une demande et la route vers le serveur OCSP qui est connu pour avoir autorité pour le certificat identifié. L'extension de demande serviceLocator est définie dans ce but. Cette extension est inclue comme singleRequestExtensions dans le demandes
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
    
ServiceLocator ::= SEQUENCE {
    issuer Name,
    locator AuthorityInfoAccessSyntax OPTIONAL }

   Les valeurs pour ces champs sont obtenus depuis leur champs correspondants dans le certificat du sujet.

Algorithmes de signature préférés

   Vu que les algorithmes autre que ceux qui sont mandatoire sont permis, et vu qu'un client n'a pas de mécanisme pour indiquer ses préférences d'algorithme, il y a toujours un risque qu'un serveur choisisse un algorithme non obligatoire pour générer une réponse que le client ne supporte pas.

   Bien qu'un répondeur OCSP peut appliquer des règles pour la sélection d'algorithme, par exemple, en utilisant l'algorithme de signature employé par la CA pour signer les CRL et certificats, de telles règles peut échouer dans des situations communes:

- L'algorithme utilisé pour signer les CRL et les certificats ne peuvent pas être consistent avec la paire de clé utilisée par le répondeur OCSP pour signer les réponses.
- Une demande pour un certificat inconnu ne fournis pas de base pour qu'un répondeur sélectionne parmis plusieurs algorithmes.

   Le dernier critère ne peut pas être résolu via les information disponible en utilisant le protocole rfc2560 sans modifier le protocole.

   De plus, un répondeur OCSP peut souhaiter employer des algorithmes de signature différents de celui utilisé par la CA pour signer les certificats et les CRL pour 2 raisons:

- Le répondeur peut employer un algorithme qui est moins gourmand en calcul que pour la signature des certificats.
- Une implémentation peut souhaiter se prémunir de la possibilité d'un algorithme de signature compromis en employant 2 algorithmes de signature séparés.

   Cette section décrit une extension qui permet à un client d'indiquer le jeu d'argorithmes de signature préféré, et les règles pour la sélection de l'algorithme de signature qui maximise la probabilité de succès dans le cas où aucun algorithme préféré n'est spécifié.

Syntaxe d'extension

Un client peut déclarer un jeu d'algorithmes préféré dans une demande en incluant une extension d'algorithme de signature préféré dans requestExtensions de OCSPRequest:
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
    
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
    
PreferredSignatureAlgorithm ::= SEQUENCE {
    sigIdentifier AlgorithmIdentifier,
    pubKeyAlgIdentifier SMIMECapability OPTIONAL
}

   La syntaxe de AlgorithmIdentifier est définis dans la rfc5280. La syntaxe de SMIMECapability est définie dans la rfc5751.

   sigIdentifier spécifie l'algorithme de signature que le client préfère, par exemple, algorithm=ecdsa-with-sha256. Les paramètres sont absent pour la plupart des algorithmes de signatures communs.

   pubKeyAlgIdentifier spécifie l'identifiat d'algorithme de clé publique que le client préfère dans le certificat du serveur utilisé pour valider la réponse OCSP, par exemple, algorithm=id-ecPublicKey et parameters=secp256r1.

   pubKeyAlgIdentifier est optionnel et fournis un moyen de spécifier les paramètres nécessaires pour distinguer entre les différents usages d'un algorithme particulier, par exemple, il peut être utilisé par le client pour spécifier que courbe il supporte pour un algorithme à courbe elliptique.

   Le client doit supporter chacun des algorithmes de signature préférés spécifiés, et le client doit spécifier les algorithmes dans l'ordre de préférence.

Sélection de l'algorithme de signature

   La rfc2560 ne spécifie pas de mécanisme pour décider de l'algorithme de signature à utiliser dans une réponse OCSP. Cela ne fournis pas de niveau suffisant de certitude quant à l'algorithme choisi pour faciliter l'interopérabilité.

Réponse dynamique

   Un répondeur peut maximiser le potentiel pour assurer l'interopérabilité en sélectionnant un algorithme de signature supporté en utilisant l'ordre de préférence suivant. tant que l'algorithme sélectionné rencontre toutes les exigences de sécurité du répondeur OCSP, où le premier mécanisme sélectionné à la plus haute précédence:

1. Sélectionne un algorithme spécifié comme algorithme de signature préféré dans le demande du client
2. Sélectionne l'algorithme de signature utilisé pour signer une liste de révocation de certificat émis par l'émetteur du certificat en fournissant les informations de statut pour le certificat spécifié par CertID
3. Sélectionne l'algorithme de signature utilisé pour signer le OCSPRequest
4. Sélectionne un algorithme de signature qui a été déclaré comme algorithme de signature par défaut pour le service de signature en utilisant un mécanisme externe.
5. Sélectionne un algorithme obligatoire ou recommandé spécifié pour la version d'OCSP utilisé.

   Un répondeur devrait toujours appliquer le mécanisme de sélection ayant le plus faible numéro qui résulte dans la sélection d'un algorithme connu et supporté qui répond aux critères du répondeur pour la force de l'algorithme cryptographique.

Réponse statique

   Dans un but d'efficacité, un répondeur OCSP est autorisé à générer des réponses statiques à l'avance. Le cas ne permet pas au répondeur d'utiliser la demande du client durant la génération de la réponse; cependant, le répondeur devrait utiliser les données de la demande du client durant la sélection de la réponse pré-générée à retourner. Les répondeurs peuvent utiliser les demandes historiques du client comme partie de la décision de l'algorithme à utiliser pour signer les réponses pré-générées.

Définition de révocation étendue

   Cette extension indique que le répondeur supporte la définition étendue du statut "révoqué" pour inclure également les certificats non-émis. Un des buts premier est de permettre des audits pour déterminer le type d'opération du répondeur. Les clients n'ont pas à regarder cette extension pour déterminer le statut des certificats dans la réponse.

   Cette extension doit être incluse dans la réponse OCSP quand cette réponse contient un statut "révoqué" pour un certificat non-émis. Cette extension peut être présente dans d'autres réponses pour signaler que le répondeur implémente la définition révoqué étendue. Quand inclus, cette extension doit être placée dans responseExtensions, et ne doit pas apparaître dans singleExtensions.

Cette extension est identifiée par l'identifiant d'objet id-pkix-ocsp-extended-revoke
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

   La valeur de l'extension doit être null. Cette extension ne doit pas être marquée critique.

Considérations de sécurité

   Pour que ce service soit effectif, les systèmes utilisant les certificat doivent se connecter au fournisseur de service de statut du certificat. Dans le cas où une telle connexion ne peut être obtenue, ces systèmes peuvent implémenter le traitement de CRL.

   Une vulnérabilité à un DOS est évident. La production d'une signature cryptographique affecte significativement le temps de cycle de génération de signature. Les erreurs de réponses non-signées ouvrent le protocole à une autre attaque DOS, où l'attaquant envoie des réponses non-signées.

   L'utilisation de réponses pré-calculées permet de rejouer des attaques dans lequel une ancienne bonne réponse est rejouée avant sa date d'expiration mais après que le certificat ait été révoqué. Les déploiements d'OCSP devraient évaluer le bénéfice des réponses pré-calculées avec la probabilité d'une attaque replay et le coùt associé avec son exécution.

   Les requêtes ne contiennent pas le répondeurs auquels ils sont redirigés. Cela permet à un attaquant pour rejouer une demande à d'autres répondeurs OCSP

   La dépendance à l'égard de la mise en cache HTTP dans certains scénarios peut résulter en des résultats inattendus si les serveurs intermédiaires sont incorrectement configurés ou ont des fautes de gestion de cache. Les implémenteurs doivent s'assurer que les mécanismes de cache HTTP sont pris en compte en déployant OCSP sur HTTP.

   En répondant avec un état 'revoked' à un certificat qui n'a jamais été émis peut permettre à une personne d'obtenir une réponse de révocation pour une certificat qui n'a jamais été émis, mais qui sera bientôt émis, si le numéro de certificat du certificat qui sera émis peut être prédis ou deviné par le demandeur. Une telle prédiction est facile pour une CA qui émet des certificats en utilisant l'assignement de numéro de série séquentiel. Ce risque est géré dans la spécification en exigant des implémentations conformes à l'utilisation du code de raison certificateHold, qui évite de révoquer des numéros de série. Pour les CA qui supportent les réponses "revoked" pour les certificats non-émis, une manière d'éviter ce problème est d'assigner des numéros de série aléatoirement avec une forte entropy.

Algorithmes de signature préféré

   Le mécanisme utilisé pour choisir l'algorithme de signature de réponse doit être considéré comme suffisamment sécure contre les attaques pas cryptanalyse pour l'application prévue.

   Dans beaucoup d'applications, l'algorithme de signature au moins aussi sécurisé que l'algorithme utilisé pour signer le certificat original est suffisant. Cependant, ce critère ne peut pas être retenu dans des applications d'archivage à long terme, dans lequel le statut d'un certificat est demandé pour date dans le passé, longtemps après que l'algorithme de signature a cessé d'être considéré comme sûr.

Utilisation d'algorithmes non sécure

   Il n'est pas toujours possible pour un répondeur de générer une réponse que le client s'attend à comprendre et qui correspond aux standards contemporains pour la sécurité cryptographique. Dans de tels cas, un opération de répondeur OCSP doit jouer entre le risque d'employer une solution de sécurité compromise et le coùt d'une mise à jours, incluant le risque que l'alternative choisis par les utilisateurs finaux offre moins de sécurité ou aucune sécurité.

   Dans les applications d'archivage, il est possible qu'un répondeur OCSP ait une demande de répondre de la validité d'un certificat dans le passé. Un tel certificat peut employer une méthode de signature qui n'est plus considéré comme sécurisée. Dans de telles circonstances, le répondeur ne doit pas générer une signature en utilisant un mécanisme de signature qui n'est pas considérée comme suffisamment sûre.

   Un client doit accepter un algorithme de signature dans une réponse qui est spécifiée comme un algorithme de signature préféré dans la demande. Un client ne doit pas spécifier d'algorithme de signature préféré qu'il ne supporte pas ou ne considère pas comme suffisamment sûre.

Attaques MITM

   Le mécanisme pour supporter l'indication client des algorithmes de signature préférés n'est pas protégé contre les attaques par dégradation MITM. Cette contrainte n'est pas considéré comme un problème de sécurité significatif, vu que le répondeur OCSP ne doit pas signer les réponses en utilisant des algorithmes faibles même si demandé par le client. En plus, le client peut rejeter les réponses qui ne rencontrent pas ses critères.

Attaques DOS

   Les mécanismes d'algorithme définis dans ce document introduit une surface d'attaque légèrement meilleur pour les attaques DOS où la demande client est altérée pour exiger des algorithmes qui ne sont pas supportés par le serveur. Les considérations DOS discutées dans la rfc4732 sont pris en compte pour ce document.

Appendice A. OCSP sur HTTP

   Cette section décrit le formattage qui sera fait à la demande et la réponse pour supporter HTTP.

Demande

   Les demandes OCSP basées sur HTTP peut utiliser soit la méthode GET soit POST pour envoyer leurs demandes. Pour permettre le caching HTTP, des petites demandes (qui après encodage font moins de 255 octets) peut être envoyés en utilisant la méthode GET. Si le caching HTTP n'est pas important ou si la demande est supérieur à 255 octets, la demande devrait être envoyé via POST. Où la confidentialité est une exigence, les transactions OCSP en utilisant HTTP peut être protégés en utilisant SSL/TLS ou d'autre protocoles.

Une demande OCSP en utilisant la méthode GET est construite comme suit:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}

   Où {url} peut être dérivé de la valeur de l'extension d'information d'accès à l'autorité dans le certificat à vérifier, ou d'autres configurations locales du client OCSP.

   Une demande OCSP en utilisant la méthode POST est construite comme suit: le header Content-Type a la valeur "application/ocsp-request", alors que le body du message est une valeur binaire de l'encodage DER du OCSPRequest.

Réponse

   Une réponse OCSP basé sur HTTP est composée des en-tête HTTP appropriés, suivis par la valeur binaire de l'encodé DER du OCSPResponse. Le header Content-Type a la valeur "application/ocsp-response". Le header Content-Length devrait spécifier la longueur de la réponse. D'autres en-tête HTTP peut être présents et peuvent être ignorés s'ils ne sont pas compris par le demandeur.
^
09 mai 2016

htmlpdflatexmanmd




rfc7299

rfc7299

OID pour le groupe de travail PKIX

Quand le groupe de travail PKIX a démarré, un arc OID a été alloué par l'IANA. Ce document décris les identifiants assignés dans cet arc, et établis les stratégies d'allocation pour tout assignement dans cet arc. l'arc OID pkix est :
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

Arcs OID subordonnés

   25 arcs OID subordonnés ont été utilisé, de 0 à 23 et 48. De plus, il y a 7 arcs subordonnée. Ils ont été assignés comme suit:

Identifiants de module id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
Extensions de certificat PKIX id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
Type de qualifiant de stratégie id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
Identifiant de clé étendue id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
Type d'information CMP id-it OBJECT IDENTIFIER ::= { id-pkix 4 }
Enregistrement CRMF id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
Contrôles d'enregistrement CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkix 5 1 }
Informations d'enregistrement CRMF id-regInfo OBJECT IDENTIFIER ::= { id-pkix 5 2 }
Algorithmes id-alg OBJECT IDENTIFIER ::= { id-pkix 6 }
Contrôles CMC id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
Requêtes et réponses CMC GLA id-cmc-glaRR OBJECT IDENTIFIER ::= { id-pkix 7 99 }
Autres formes de nom id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
Attribut personnel id-pda OBJECT IDENTIFIER ::= { id-pkix 9 }
Attribut de certificat d'attributs id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
Déclarations de certificat qualifié id-qcs OBJECT IDENTIFIER ::= { id-pkix 11 }
Types de contenu CMC id-cct OBJECT IDENTIFIER ::= { id-pkix 12 }
OID pour test uniquement id-TEST OBJECT IDENTIFIER ::= { id-pkix 13 }
Stratégies de certificat id-cp OBJECT IDENTIFIER ::= { id-pkix 14 }
Type d'erreur CMC id-cet OBJECT IDENTIFIER ::= { id-pkix 15 }
Types d'information de révocation id-ri OBJECT IDENTIFIER ::= { id-pkix 16 }
Types de retour SCVP id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }
Stratégies de validation SCVP id-svp OBJECT IDENTIFIER ::= { id-pkix 19 }
Erreurs de stratégie de validation de nom SCVP id-nvae OBJECT IDENTIFIER ::= { id-pkix 19 2 }
Erreurs de stratégie de validation de base SCVP id-bvae OBJECT IDENTIFIER ::= { id-pkix 19 3 }
Erreurs de stratégie de validation de nom distinct SCVP id-dnvae OBJECT IDENTIFIER ::= { id-pkix 19 4 }
Autres identifiants logotype id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
Langages de stratégie de certificat proxy id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
Rêgles de correspondance id-mr OBJECT IDENTIFIER ::= { id-pkix 22 }
Sémantiques d'identifiant de clé du sujet id-skis OBJECT IDENTIFIER ::= { id-pkix 23 }
Descripteurs d'accès id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
OCSP id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix 48 1 }

   L'IANA a mis à jours une table d'enregistrement et créé 33 tables additionnelles. Les mises à jours dans les nouvelles tables sont faites en accord avec la spécification définie dans la rfc5226.

1.3.6.1.5.5.7

Decimal Description References
------- ------------------------------------ ----------
0_______Module identifiers_____________________[RFC7299]
1_______PKIX certificate extensions____________[RFC7299]
2_______Policy qualifier types_________________[RFC7299]
3_______Extended key purpose identifiers_______[RFC7299]
4_______CMP information types__________________[RFC7299]
5_______CRMF registration______________________[RFC7299]
6_______Algorithms_____________________________[RFC7299]
7_______CMC controls___________________________[RFC7299]
8_______Other name forms_______________________[RFC7299]
9_______Personal data attribute________________[RFC7299]
10______Attribute certificate attributes_______[RFC7299]
11______Qualified certificate statements_______[RFC7299]
12______CMC content types______________________[RFC7299]
13______OIDs for TESTING ONLY__________________[RFC7299]
14______Certificate policies___________________[RFC7299]
15______CMC error types________________________[RFC7299]
16______Revocation information types___________[RFC7299]
17______SCVP check type________________________[RFC7299]
18______SCVP want back types___________________[RFC7299]
19______SCVP validation policies_______________[RFC7299]
20______Other logotype identifiers_____________[RFC7299]
21______Proxy certificate policy languages_____[RFC7299]
22______Matching rules_________________________[RFC7299]
23______Subject key identifier semantics_______[RFC7299]
48______Access descriptors_____________________[RFC7299]

1.3.6.1.5.5.7.0

Decimal Description References
------- ------------------------------- ---------------------
1________id-pkix1-explicit-88_____________[RFC2459]
2________id-pkix1-implicit-88_____________[RFC2459]
3________id-pkix1-explicit-93_____________[RFC2459]
4________id-pkix1-implicit-93_____________[RFC2459]
5________id-mod-crmf______________________[RFC2511]
6________id-mod-cmc_______________________[RFC2797]
7________id-mod-kea-profile-88____________[RFC2528]
8________id-mod-kea-profile-93____________[RFC2528]
9________id-mod-cmp_______________________[RFC2510]
10_______id-mod-qualified-cert-88_________[RFC3039]
11_______id-mod-qualified-cert-93_________[RFC3039]
12_______id-mod-attribute-cert____________[RFC3281]
13_______id-mod-tsp_______________________[RFC3161]
14_______id-mod-ocsp______________________[RFC3029]
15_______id-mod-dvcs______________________[RFC3029]
16_______id-mod-cmp2000___________________[RFC4210]
17_______id-mod-pkix1-algorithms__________[RFC3279]
18_______id-mod-pkix1-explicit____________[RFC3280]
19_______id-mod-pkix1-implicit____________[RFC3280]
20_______id-mod-user-group________________Reserved and Obsolete
21_______id-mod-scvp______________________[RFC5055]
22_______id-mod-logotype__________________[RFC3709]
23_______id-mod-cmc2002___________________[RFC5272]
24_______id-mod-wlan-extns________________[RFC3770]
25_______id-mod-proxy-cert-extns__________[RFC3820]
26_______id-mod-ac-policies_______________[RFC4476]
27_______id-mod-warranty-extn_____________[RFC4059]
28_______id-mod-perm-id-88________________[RFC4043]
29_______id-mod-perm-id-93________________[RFC4043]
30_______id-mod-ip-addr-and-as-ident______[RFC3779]
31_______id-mod-qualified-cert____________[RFC3739]
32_______id-mod-crmf2003__________________Reserved and Obsolete
33_______id-mod-pkix1-rsa-pkalgs__________[RFC4055]
34_______id-mod-cert-bundle_______________[RFC4306]
35_______id-mod-qualified-cert-97_________[RFC3739]
36_______id-mod-crmf2005__________________[RFC4210]
37_______id-mod-wlan-extns2005____________[RFC4334]
38_______id-mod-sim2005___________________[RFC4683]
39_______id-mod-dns-srv-name-88___________[RFC4985]
40_______id-mod-dns-srv-name-93___________[RFC4985]
41_______id-mod-cmsContentConstr-88_______[RFC6010]
42_______id-mod-cmsContentConstr-93_______[RFC6010]
43_______id-mod-pkixCommon________________Reserved and Obsolete
44_______id-mod-pkixOtherCerts____________[RFC5697]
45_______id-mod-pkix1-algorithms2008______[RFC5480]
46_______id-mod-clearanceConstraints______[RFC5913]
47_______id-mod-attribute-cert-02_________[RFC5912]
48_______id-mod-ocsp-02___________________[RFC5912]
49_______id-mod-v1AttrCert-02_____________[RFC5912]
50_______id-mod-cmp2000-02________________[RFC5912]
51_______id-mod-pkix1-explicit-02_________[RFC5912]
52_______id-mod-scvp-02___________________[RFC5912]
53_______id-mod-cmc2002-02________________[RFC5912]
54_______id-mod-pkix1-rsa-pkalgs-02_______[RFC5912]
55_______id-mod-crmf2005-02_______________[RFC5912]
56_______id-mod-pkix1-algorithms2008-02___[RFC5912]
57_______id-mod-pkixCommon-02_____________[RFC5912]
58_______id-mod-algorithmInformation-02___[RFC5912]
59_______id-mod-pkix1-implicit-02_________[RFC5912]
60_______id-mod-pkix1-x400address-02______[RFC5912]
61_______id-mod-attribute-cert-v2_________[RFC5755]
62_______id-mod-sip-domain-extns2007______[RFC5924]
63_______id-mod-cms-otherRIs-2009-88______[RFC5940]
64_______id-mod-cms-otherRIs-2009-93______[RFC5940]
65_______id-mod-ecprivatekey______________[RFC5915]
66_______id-mod-ocsp-agility-2009-93______[RFC6277]
67_______id-mod-ocsp-agility-2009-88______[RFC6277]
68_______id-mod-logotype-certimage________[RFC6170]
69_______id-mod-pkcs10-2009_______________[RFC5912]
70_______id-mod-dns-resource-record_______[Abley]
71_______id-mod-send-cert-extns___________[RFC6494]
72_______id-mod-ip-addr-and-as-ident-2____[RFC6268]
73_______id-mod-wlan-extns-2______________[RFC6268]
74_______id-mod-hmac______________________[RFC6268]
75_______id-mod-enrollMsgSyntax-2011-88___[RFC6402] [Err3860]
76_______id-mod-enrollMsgSyntax-2011-08___[RFC6402]
77_______id-mod-pubKeySMIMECaps-88________[RFC6664]
78_______id-mod-pubKeySMIMECaps-08________[RFC6664]
79_______id-mod-dhSign-2012-88____________[RFC6955]
80_______id-mod-dhSign-2012-08____________[RFC6955]
81_______id-mod-ocsp-2013-88______________[RFC6960]
82_______id-mod-ocsp-2013-08______________[RFC6960]
83_______id-mod-TEST-certPolicies_________[RFC7229]
84_______id-mod-bgpsec-eku________________[BGPSEC]

1.3.6.1.5.5.7.1

Decimal Description References
------- ------------------------------ ---------------------
_______1________id-pe-authorityInfoAccess_______[RFC2459]
_______2________id-pe-biometricInfo_____________[RFC3039]
_______3________id-pe-qcStatements______________[RFC3039]
_______4________id-pe-ac-auditIdentity__________[RFC3281]
_______5________id-pe-ac-targeting______________Reserved and Obsolete
_______6________id-pe-aaControls________________[RFC3281]
_______7________id-pe-ipAddrBlocks______________[RFC3779]
_______8________id-pe-autonomousSysIds__________[RFC3779]
_______9________id-pe-sbgp-routerIdentifier_____Reserved and Obsolete
_______10_______id-pe-ac-proxying_______________[RFC3281]
_______11_______id-pe-subjectInfoAccess_________[RFC3280]
_______12_______id-pe-logotype__________________[RFC3709]
_______13_______id-pe-wlanSSID__________________[RFC4334]
_______14_______id-pe-proxyCertInfo_____________[RFC3820]
_______15_______id-pe-acPolicies________________[RFC4476]
_______16_______id-pe-warranty__________________[RFC4059]
_______17_______id-pe-sim_______________________Reserved and Obsolete
_______18_______id-pe-cmsContentConstraints_____[RFC6010]
_______19_______id-pe-otherCerts________________[RFC5697]
_______20_______id-pe-wrappedApexContinKey______[RFC5934]
_______21_______id-pe-clearanceConstraints______[RFC5913]
_______22_______id-pe-skiSemantics______________Reserved and Obsolete
_______23_______id-pe-nsa_______________________[RFC7169]

1.3.6.1.5.5.7.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-qt-cps_______________________[RFC2459]
2________id-qt-unotice___________________[RFC2459]
3________id-qt-textNotice________________Reserved and Obsolete
4________id-qt-acps______________________[RFC4476]
5________id-qt-acunotice_________________[RFC4476]

1.3.6.1.5.5.7.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-kp-serverAuth________________[RFC2459]
2________id-kp-clientAuth________________[RFC2459]
3________id-kp-codeSigning_______________[RFC2459]
4________id-kp-emailProtection___________[RFC2459]
5________id-kp-ipsecEndSystem____________Reserved and Obsolete
6________id-kp-ipsecTunnel_______________Reserved and Obsolete
7________id-kp-ipsecUser_________________Reserved and Obsolete
8________id-kp-timeStamping______________[RFC2459]
9________id-kp-OCSPSigning_______________[RFC2560]
10_______id-kp-dvcs______________________[RFC3029]
11_______id-kp-sbgpCertAAServerAuth______Reserved and Obsolete
12_______id-kp-scvp-responder____________Reserved and Obsolete
13_______id-kp-eapOverPPP________________[RFC4334]
14_______id-kp-eapOverLAN________________[RFC4334]
15_______id-kp-scvpServer________________[RFC5055]
16_______id-kp-scvpClient________________[RFC5055]
17_______id-kp-ipsecIKE__________________[RFC4945]
18_______id-kp-capwapAC__________________[RFC5415]
19_______id-kp-capwapWTP_________________[RFC5415]
20_______id-kp-sipDomain_________________[RFC5924]
21_______id-kp-secureShellClient_________[RFC6187]
22_______id-kp-secureShellServer_________[RFC6187]
23_______id-kp-sendRouter________________[RFC6494]
24_______id-kp-sendProxiedRouter_________[RFC6494]
25_______id-kp-sendOwner_________________[RFC6494]
26_______id-kp-sendProxiedOwner__________[RFC6494]
27_______id-kp-cmcCA_____________________[RFC6402]
28_______id-kp-cmcRA_____________________[RFC6402]
29_______id-kp-cmcArchive________________[RFC6402]
30_______id-kp-bgpsec-router_____________[BGPSEC]

1.3.6.1.5.5.7.4

Decimal Description References
------- ------------------------------ ---------------------
1________id-it-caProtEncCert_____________[RFC2510]
2________id-it-signKeyPairTypes__________[RFC2510]
3________id-it-encKeyPairTypes___________[RFC2510]
4________id-it-preferredSymmAlg__________[RFC2510]
5________id-it-caKeyUpdateInfo___________[RFC2510]
6________id-it-currentCRL________________[RFC2510]
7________id-it-unsupportedOIDs___________[RFC4210]
8________id-it-subscriptionRequest_______Reserved and Obsolete
9________id-it-subscriptionResponse______Reserved and Obsolete
10_______id-it-keyPairParamReq___________[RFC4210]
11_______id-it-keyPairParamRep___________[RFC4210]
12_______id-it-revPassphrase_____________[RFC4210]
13_______id-it-implicitConfirm___________[RFC4210]
14_______id-it-confirmWaitTime___________[RFC4210]
15_______id-it-origPKIMessage____________[RFC4210]
16_______id-it-suppLangTags______________[RFC4210]

1.3.6.1.5.5.7.5

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl______________________[RFC2511]
2________id-regInfo______________________[RFC2511]
3________id-regEPEPSI____________________[RFC4683]

1.3.6.1.5.5.7.5.1

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl-regToken_____________[RFC2511]
2________id-regCtrl-authenticator________[RFC2511]
3________id-regCtrl-pkiPublicationInfo___[RFC2511]
4________id-regCtrl-pkiArchiveOptions____[RFC2511]
5________id-regCtrl-oldCertID____________[RFC2511]
6________id-regCtrl-protocolEncrKey______[RFC2511]
7________id-regCtrl-altCertTemplate______[RFC4210]
8________id-regCtrl-wtlsTemplate_________Reserved and Obsolete
9________id-regCtrl-regTokenUTF8_________Reserved and Obsolete
10_______id-regCtrl-authenticatorUTF8____Reserved and Obsolete

1.3.6.1.5.5.7.5.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-regInfo-utf8Pairs____________[RFC2511]
2________id-regInfo-certReq______________[RFC2511]

1.3.6.1.5.5.7.6

Decimal Description References
------- ------------------------------ ---------------------
1________id-alg-des40________________________________Reserved and Obsolete
2________id-alg-noSignature__________________________[RFC2797]
3________id-alg-dh-sig-hmac-sha1_____________________[RFC2875]
4________id-alg-dhPop-sha1___________________________[RFC2875]
5________id-alg-dhPop-sha224_________________________[RFC6955]
6________id-alg-dhPop-sha256_________________________[RFC6955]
7________id-alg-dhPop-sha384_________________________[RFC6955]
8________id-alg-dhPop-sha512_________________________[RFC6955]
15_______id-alg-dhPop-static-sha224-hmac-sha224______[RFC6955]
16_______id-alg-dhPop-static-sha256-hmac-sha256______[RFC6955]
17_______id-alg-dhPop-static-sha384-hmac-sha384______[RFC6955]
18_______id-alg-dhPop-static-sha512-hmac-sha512______[RFC6955]
25_______id-alg-ecdhPop-static-sha224-hmac-sha224____[RFC6955]
26_______id-alg-ecdhPop-static-sha256-hmac-sha256____[RFC6955]
27_______id-alg-ecdhPop-static-sha384-hmac-sha384____[RFC6955]
28_______id-alg-ecdhPop-static-sha512-hmac-sha512____[RFC6955]
    
Note: id-alg-dhPop-sha1 est également appelé id-alg-dh-pop.
Note: id-alg-dh-sig-hmac-sha1 est également appelé id-alg-dhPop-static-sha1-hmac-sha1 et id-dhPop-static-hmac-sha1.

1.3.6.1.5.5.7.7

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-statusInfo_______________[RFC2797]
2________id-cmc-identification___________[RFC2797]
3________id-cmc-identityProof____________[RFC2797]
4________id-cmc-dataReturn_______________[RFC2797]
5________id-cmc-transactionId____________[RFC2797]
6________id-cmc-senderNonce______________[RFC2797]
7________id-cmc-recipientNonce___________[RFC2797]
8________id-cmc-addExtensions____________[RFC2797]
9________id-cmc-encryptedPOP_____________[RFC2797]
10_______id-cmc-decryptedPOP_____________[RFC2797]
11_______id-cmc-lraPOPWitness____________[RFC2797]
15_______id-cmc-getCert__________________[RFC2797]
16_______id-cmc-getCRL___________________[RFC2797]
17_______id-cmc-revokeRequest____________[RFC2797]
18_______id-cmc-regInfo__________________[RFC2797]
19_______id-cmc-responseInfo_____________[RFC2797]
21_______id-cmc-queryPending_____________[RFC2797]
22_______id-cmc-popLinkRandom____________[RFC2797]
23_______id-cmc-popLinkWitness___________[RFC2797]
24_______id-cmc-confirmCertAcceptance____[RFC2797]
25_______id-cmc-statusInfoV2_____________[RFC5272]
26_______id-cmc-trustedAnchors___________[RFC5272]
27_______id-cmc-authData_________________[RFC5272]
28_______id-cmc-batchRequests____________[RFC5272]
29_______id-cmc-batchResponses___________[RFC5272]
30_______id-cmc-publishCert______________[RFC5272]
31_______id-cmc-modCertTemplate__________[RFC5272]
32_______id-cmc-controlProcessed_________[RFC5272]
33_______id-cmc-popLinkWitnessV2_________[RFC5272]
34_______id-cmc-identityProofV2__________[RFC5272]
35_______id-cmc-raIdentityWitness________[RFC6402]
36_______id-cmc-changeSubjectName________[RFC6402]
37_______id-cmc-responseBody_____________[RFC6402]
99_______id-cmc-glaRR____________________[RFC5275]
    
Note: id-cmc-statusInfo est également appelé id-cmc-cMCStatusInfo.

1.3.6.1.5.5.7.7.99

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-gla-skdAlgRequest________[RFC5275]
2________id-cmc-gla-skdAlgResponse_______[RFC5275]

1.3.6.1.5.5.7.8

Decimal Description References
------- ------------------------------ ---------------------
1________id-on-personalData______________Reserved and Obsolete
2________id-on-userGroup_________________Reserved and Obsolete
3________id-on-permanentIdentifier_______[RFC4043]
4________id-on-hardwareModuleName________[RFC4108]
5________id-on-xmppAddr__________________[RFC3920]
6________id-on-SIM_______________________[RFC4683]
7________id-on-dnsSRV____________________[RFC4985]

1.3.6.1.5.5.7.9

Decimal Description References
------- ------------------------------ ---------------------
1________id-pda-dateOfBirth______________[RFC3039]
2________id-pda-placeOfBirth_____________[RFC3039]
3________id-pda-gender___________________[RFC3039]
4________id-pda-countryOfCitizenship_____[RFC3039]
5________id-pda-countryOfResidence_______[RFC3039]

1.3.6.1.5.5.7.10

Decimal Description References
------- ------------------------------ ---------------------
1________id-aca-authenticationInfo_______[RFC3281]
2________id-aca-accessIdentity___________[RFC3281]
3________id-aca-chargingIdentity_________[RFC3281]
4________id-aca-group____________________[RFC3281]
5________id-aca-role_____________________Reserved and Obsolete
6________id-aca-encAttrs_________________[RFC3281]
7________id-aca-wlanSSID_________________[RFC4334]

1.3.6.1.5.5.7.11

Decimal Description References
------- ------------------------------ ---------------------
1________id-qcs-pkixQCSyntax-v1__________[RFC3039]
2________id-qcs-pkixQCSyntax-v2__________[RFC3739]

1.3.6.1.5.5.7.12

Decimal Description References
------- ------------------------------ ---------------------
1________id-cct-crs______________________Reserved and Obsolete
2________id-cct-PKIData__________________[RFC2797]
3________id-cct-PKIResponse______________[RFC2797]

1.3.6.1.5.5.7.13

Decimal Description References
------- ------------------------------ ---------------------
1________id-TEST-certPolicyOne___________[RFC7229]
2________id-TEST-certPolicyTwo___________[RFC7229]
3________id-TEST-certPolicyThree_________[RFC7229]
4________id-TEST-certPolicyFour__________[RFC7229]
5________id-TEST-certPolicyFive__________[RFC7229]
6________id-TEST-certPolicySix___________[RFC7229]
7________id-TEST-certPolicySeven_________[RFC7229]
8________id-TEST-certPolicyEight_________[RFC7229]

1.3.6.1.5.5.7.14

Decimal Description References
------- ------------------------------ ---------------------
1________id-cp-sbgpCertificatePolicy_____Reserved and Obsolete
2________id-cp-ipAddr-asNumber___________[RFC6484]

1.3.6.1.5.5.7.15

Decimal Description References
------- ------------------------------ ---------------------
1________id-cet-skdFailInfo______________[RFC5275]

1.3.6.1.5.5.7.16

Decimal Description References
------- ------------------------------ ---------------------
1________id-ri-crl_______________________[RFC5940]
2________id-ri-ocsp-response_____________[RFC5940]
3________id-ri-delta-crl_________________[RFC5940]
4________id-ri-scvp______________________[RFC5940]

1.3.6.1.5.5.7.17

Decimal Description References
------- ------------------------------------------------------ ---------------------
1________id-stc-build-pkc-path___________________________________[RFC5055]
2________id-stc-build-valid-pkc-path_____________________________[RFC5055]
3________id-stc-build-status-checked-pkc-path____________________[RFC5055]
4________id-stc-build-aa-path____________________________________[RFC5055]
5________id-stc-build-valid-aa-path______________________________[RFC5055]
6________id-stc-build-status-checked-aa-path_____________________[RFC5055]
7________id-stc-status-check-ac-and-build-status-checked-aa-path_[RFC5055]

1.3.6.1.5.5.7.18

Decimal Description References
------- ------------------------------ ---------------------
1________id-swb-pkc-best-cert-path_______[RFC5055]
2________id-swb-pkc-revocation-info______[RFC5055]
3________id-swb-pkc-cert-status__________Reserved and Obsolete
4________id-swb-pkc-public-key-info______[RFC5055]
5________id-swb-aa-cert-path_____________[RFC5055]
6________id-swb-aa-revocation-info_______[RFC5055]
7________id-swb-ac-revocation-info_______[RFC5055]
8________id-swb-ac-cert-status___________Reserved and Obsolete
9________id-swb-relayed-responses________[RFC5055]
10_______id-swb-pkc-cert_________________[RFC5055]
11_______id-swb-ac-cert__________________[RFC5055]
12_______id-swb-pkc-all-cert-paths_______[RFC5055]
13_______id-swb-pkc-ee-revocation-info___[RFC5055]
14_______id-swb-pkc-CAs-revocation-info__[RFC5055]
15_______id-swb-partial-cert-path________[RFC5276]
16_______id-swb-ers-pkc-cert_____________[RFC5276]
17_______id-swb-ers-best-cert-path_______[RFC5276]
18_______id-swb-ers-partial-cert-path____[RFC5276]
19_______id-swb-ers-revocation-info______[RFC5276]
20_______id-swb-ers-all__________________[RFC5276]

1.3.6.1.5.5.7.19

Decimal Description References
------- ------------------------------ ----------
1________id-svp-defaultValPolicy_________[RFC5055]
2________id-svp-nameValAlg_______________[RFC5055]
3________id-svp-basicValAlg______________[RFC5055]
4________id-svp-dnValAlg_________________[RFC5055]

1.3.6.1.5.5.7.19.2

Decimal Description References
------- ------------------------------ ----------
1________id-nvae-name-mismatch___________[RFC5055]
2________id-nvae-no-name_________________[RFC5055]
3________id-nvae-unknown-alg_____________[RFC5055]
4________id-nvae-bad-name________________[RFC5055]
5________id-nvae-bad-name-type___________[RFC5055]
6________id-nvae-mixed-names_____________[RFC5055]

1.3.6.1.5.5.7.19.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-bvae-expired_________________[RFC5055]
2________id-bvae-not-yet-valid___________[RFC5055]
3________id-bvae-wrongTrustAnchor________[RFC5055]
4________id-bvae-noValidCertPath_________[RFC5055]
5________id-bvae-revoked_________________[RFC5055]
9________id-bvae-invalidKeyPurpose_______[RFC5055]
10_______id-bvae-invalidKeyUsage_________[RFC5055]
11_______id-bvae-invalidCertPolicy_______[RFC5055]
12_______id-bvae-invalidName_____________Reserved and Obsolete
13_______id-bvae-invalidEntity___________Reserved and Obsolete
14_______id-bvae-invalidPathDepth________Reserved and Obsolete

1.3.6.1.5.5.7.20

Decimal Description Reference
------- ------------------------------ ---------
1________id-logo-loyalty_________________[RFC3709]
2________id-logo-background______________[RFC3709]
3________id-logo-certImage_______________[RFC6170]

1.3.6.1.5.5.7.21

Decimal Description Reference
------- ------------------------------ ---------
0________id-ppl-anyLanguage______________[RFC3820]
1________id-ppl-inheritAll_______________[RFC3820]
2________id-ppl-independent______________[RFC3820]

1.3.6.1.5.5.7.22

Decimal Description References
------- ------------------------------ ---------------------
1________id-mr-pkix-alphanum-ids_________Reserved and Obsolete

1.3.6.1.5.5.7.23

Decimal Description References
------- ------------------------------ ---------------------
1________id-skis-keyHash_________________Reserved and Obsolete
2________id-skis-4BitKeyHash_____________Reserved and Obsolete
3________id-skis-keyInfoHash_____________Reserved and Obsolete

1.3.6.1.5.5.7.48

Decimal Description References
------- ------------------------------ ---------------------
1________id-ad-ocsp______________________[RFC2459]
2________id-ad-caIssuers_________________[RFC2459]
3________id-ad-timestamping______________[RFC3161]
4________id-ad-dvcs______________________[RFC3029]
5________id-ad-caRepository______________[RFC3280]
6________id-ad-http-certs________________[RFC4387]
7________id-ad-http-crls_________________[RFC4387]
8________id-ad-xkms______________________Reserved and Obsolete
9________id-ad-signedObjectRepository____Reserved and Obsolete
10_______id-ad-rpkiManifest______________[RFC6487]
11_______id-ad-signedObject______________[RFC6487]
12_______id-ad-cmc_______________________[RFC6402]

1.3.6.1.5.5.7.48.1

Decimal Description References
------- ------------------------------ ----------
1________id-pkix-ocsp-basic______________[RFC2560]
2________id-pkix-ocsp-nonce______________[RFC2560]
3________id-pkix-ocsp-crl________________[RFC2560]
4________id-pkix-ocsp-response___________[RFC2560]
5________id-pkix-ocsp-nocheck____________[RFC2560]
6________id-pkix-ocsp-archive-cutoff_____[RFC2560]
7________id-pkix-ocsp-service-locator____[RFC2560]
8________id-pkix-ocsp-pref-sig-algs______[RFC6277]
9________id-pkix-ocsp-extended-revoke____[RFC6960]

^
17 mars 2010

htmlpdflatexmanmd




rfc768

rfc768

User Datagram Protocol

   User Datagram Protocol est un protocole de la couche transport. Le rôle de ce protocole est de transmettre des paquets de manière très simplement. Contrairement au protocole TCP, il travaille en mode non connecté. Il n'y a donc aucun moyen de vérifier le bon acheminement des paquets, ni l'ordre dans lequel ils arrivent. Il n'y a pas non plus de contrôle de flux ni de contrôle de congestion, il est considéré comme étant un protocole non fiable. Il possède cependant un checksum pour assurer la validité de chaque datagramme. Un datagramme UDP est encapsulé dans un paquet IP.

Structure d'un segment UDP


Port Source (16 bits)___Port destination (16 bits)
Longueur (16 bits)______Somme de contrôle (16 bits)
_______Données (longueur variable)________________

Port source Indique depuis quel port le paquet a été envoyé
Port de destination indique à quel port est destiné le paquet
Longueur Longueur totale du segment UDP (en-tête + données)). La longueur minimale est donc de 8 octets (taille de l'en-tête)
Somme de contrôle Permet de s'assurer de l'intégrité du paquet reçu. Calculé sur l'ensemble de l'en-tête UDP et des données, mais également sur un pseudo en-tête (extrait de l'en-tête IP)

   Champs utilisés pour le calcul de la somme de contrôle UDP. ( les champs en orange correspondent au pseudo en-tête IP), le tout additionné d'un octet nul, éventuellement, afin que le nombre total d'octets soit pair.


Bits | 0- 7____8 – 15____16 – 23____24 – 31
_____|_________Adresse Source______________
_____|_______Adresse Destination___________
_____|_Zéros_|_Protocole_|__Taille UDP_____
_____|____Port source____|_Port Destination
_____|_______Taille______|____Checksum_____
_____|_______________Data__________________

   UDP est généralement utilisé quand il est nécessaire de transmettre des données rapidement, et où la perte d'une partie de ces données n'a pas grande importance. Il est, par exemple, utilisé dans es transaction TFTP, communications DNS, VOIP etc.....
^
09 juin 2010

htmlpdflatexmanmd




rfc951

rfc951

bootp

   BOOTP est un protocole d'amorçage permettant à une machine sans disque dur de découvrir sa propre adresse IP, l'adresse d'un hôte serveur, et le nom d'un fichier à charger en mémoire pour exécution. Une telle opération d'amorçage se déroule en 2 phases. La première permet de déterminer l'adresse puis le fichier à télécharger, et la 2eme phase consiste à transférer ce fichier via TFTP généralement, mais n'est pas une obligation, il est possible d'utiliser FTP ou SFTP. TFTP est préféré puisque les 2 phases résident dans la PROM du client. Le logiciel PROM devrait fournit un moyen d'effectuer un amorçage complet sans intervention de l'utilisateur. Un mécanisme devrait cependant permettre à l'utilisateur de fournir manuellement l'adresse et le nom de fichier, permettant de passer outre le protocole BOOTP et d'entrer directement dans la phase de transfert de fichier.

Aperçu du protocole

- Un seul échange de paquets est effectué. Des temporisateurs sont utilisés pour la retransmission jusqu'à la réception d'une réponse. La même composition de paquet est utilisée dans les 2 directions. Des champs de longueur fixée à un maximum raisonnable sont utilisés pour simplifier la définition de structure et l'analyse syntaxique.
- Un champ Opcode existe et comprend 2 valeurs. Le client diffuse un paquet bootrequest, le serveur répond avec un paquet bootreply. La requête d'amorçage contient l'adresse matérielle du client et son IP, s'il la connait.
- La requête peut optionnellement contenir le nom du serveur à partir duquel le client veut obtenir une réponse. C'est prévu afin que le client puisse exiger l'amorçage depuis un hôte spécifique.
- La requête peut optionnellement contenir le nom de fichier « générique » à partir duquel démarrer.
- Dans le cas d'un client qui ne connait pas son adresse IP, le serveur doit également disposer d'une base de données associant adresses matérielles et adresses IP. Cette IP est ensuite placée dans un champ de la requête d'amorçage.
- Il est possible d'utiliser des agents relai, permettant aux clients de démarrer depuis des serveurs situés sur une autre réseau.

Format des paquets

   Un paquet BOOTP est encapsulé dans un datagramme UDP. Dans l'en-tête IP d'une requête d'amorçage, le client fournit sa propre adresse IP s'il la connaît, ou zéro sinon. Quand l'adresse du serveur est inconnue, l'adresse IP destination sera l'adresse de diffusion 255.255.255.255. L'en-tête UDP contient les numéros de port source et destination. Le protocole BOOTP utilise le port 68 « client BOOTP » et le port 67 « serveur BOOTP ». Le client envoie une requête en utilisant le port 67 en port de destination et 68 en port source.

op (1 octet) Type de message/code opératoire du paquet: 1= BOOTREQUEST, 2= BOOTREPLY
htype (1 octet) Type d'adresse matérielle voir la RFC « Assigned Numbers » section ARP.
hlen (1 octet) Longueur de l'adresse matérielle (ex : 6 pour Ethernet)
hops (1 octet) Fixé par le client à 0 ; peut être utilisé par des passerelles lors d'amorçages au travers de passerelles
xid (4 octets) ID de transaction : nombre aléatoire utilisé pour associer cette requête de démarrage avec la réponse qu'elle génère.
secs (2 octets) Rempli par le client, secondes aléatoire utilisé pour associer cette requête de démarrage avec la réponse qu'elle génère.
ciaddr (4 octets) Adresse IP du client ; remplie par le client dans la requête d'amorçage si elle est connue
yaddr (4 octets) Votre adresse IP (Client) ; remplie par le serveur si le client ne connait pas sa propre adresse (si ciaddr valait 0)
siaddr (4 octets) Adresse IP du serveur ; renvoyée dans une réponse d'amorçage par le serveur.
giaddr (4 octets) Adresse IP de la passerelle utilisée dans l'amorçage au travers de passerelles optionnel
chaddr (16 octets) Adresse matérielle du client ; remplie par le client
sname (64 octets) Nom de l'hôte serveur
file (128 octets) Nom du fichier de démarrage
vend (64 octets) Zone optionnelle spécifique au vendeur.

   Si aucune réponse n'est reçue durant une certaine période de temps, le client devrait retransmettre la requête.

Utilisation du serveur bootpd

En général boopd est lancé par /etc/inetd, grâce aux lignes suivante du fichier /etc/inetd.conf :
bootps dgram udp wait root /etc/bootpd bootpd
bootpd est alors lancé uniquement lorsqu'une requête de démarrage arrive. A son démarrage, bootpd lit le fichier de configuration ( par défaut /etc/bootptab). Les ports utilisés sont spécifiés dans /etc/services
-c répertoire
Force bootpd à travailler dans le répertoire

Configuration

   Le fichier de configuration de bootpd a un format dans lequel des symboles sensibles à la casse de deux caractères sont utilisé pour représenter les paramètres des hôtes. Ces déclarations de paramètres sont séparés par des « : ». Le format général est:

  hôte:tg=valeur:tg=valeur:tg=valeur

bf Fichier de démarrage
bs Taille du fichier de démarrage en bloc de 512 octets
bc Liste des adresse des serveurs de cookies
ds Liste des serveurs de nom de domaine
gw Liste des adresses de passerelles
ha Adresse matérielle de l'hôte
hd Répertoire racine du fichier de démarrage
hn Envoi le nom de l'hôte
ht Type de matériel de l'hôte
im Liste des adresses des serveurs d'impression
ip Adresse IP de l'hôte
ig Liste des adresses des serveurs de journalisation
lp Liste des adresses lpr
ns Liste des adresses des serveurs de noms IEN-116
rl Liste des adresses des serveurs de protocole de localisation des ressources
sm Masque de sous-réseau de l'hôte
tc Suite de table
to Décalage horaire en secondes par rapport à UTC
ts Liste d'adresses de serveurs d'heure
vm Sélecteur de cookie magique du revendeur.

   Il existe également le relai bootp: bootpgw qui utilise les même options sauf -c. bootptest est un utilitaire permettant de tester bootpd et bootpgw.
^
30 juin 2010

htmlpdflatexmanmd




rm

rm

Supprime des fichiers, par défaut ne supprime pas les répertoires.

   Si -I est donnés et qu'il y'a plus de 3 fichiers, ou que -r est donné, rm demande à l'utilisateur avant de traiter l'opération entière. Une tentative de supprimer '.' ou '..' est toujours rejetée.

OPTIONS

-f, --force Ignore les fichiers non-existant.
-i Demande confirmation à l'utilisateur pour supprimer chaque fichier.
-I Demande Confirmation 1 fois pour traiter la commande entière.
--interactive [=WHEN] Spécifie quand demande confirmation. :

        never ne prompt jamais
        once demande une fois
        always demande pour chaque fichier

--one-file-system En supprimant une hiérarchie récursivement, ne supprime pas les répertoire qui ont un système de fichier différent.
--preserve-root Echoue lors d'une tentative de supprimer le répertoire root '/' avec -r. c'est le mode par défaut.
--no-preserve-root Permet de supprimer '/' avec -r
-r, -R, --recursive Supprime Les répertoires listés et leur contenu, récursivement.
-v, --verbose Affiche le nom de chaque fichier avant de le supprimer.

   Une question commune est comment supprimer un fichier commençant par '-'. Il faut utiliser '--', pour indiquer que la suite de la ligne de commande ne sont pas des options : rm -- -f ou encore rm ./-f
^
02 juillet 2010

htmlpdflatexmanmd




rmdir

rmdir

Supprimer les répertoires vides

OPTIONS

--ignore-fail-on-non-empty Ignore les échecs dûs à des répertoires non vides
-p, --parents Supprime le répertoire, puis essaye de supprimer chaque composant du répertoire. Par exemple : rmdir -p a/b/c est similaire à rmdir a/b/c a/b a.
-v, --verbose Donne un diagnostique pour chaque suppression réussie.
^
28 mars 2016

htmlpdflatexmanmd




rmmod

rmmod

Supprime un module du kernel Linux

OPTIONS

-v, --verbose mode verbeux
-f, --force Peut être très dangereuse : n’a pas d’effet sauf si CONFIG_MODULE_FORCE_UNLOAD est mis à la compilation du kernel
-w, --wait Normalement rmmod refuse de décharger des module en cours d’utilisation. Avec cette option, isole le module et attend que le module ne soit plus utilisé.
-s, --syslog Envoie les erreurs à syslog ou l’erreur standard
^
14 septembre 2010

htmlpdflatexmanmd




rndc

rndc

Contrôle les opérations du serveur de noms

OPTIONS

-b source-address adresse source pour la connexion au serveur
-c config-file Spécifie le fichier de configuration à utiliser (défaut /etc/rndc.conf).
-k key-file utilise le fichier de clé spécifié au lieu de /etc/rndc.key par défaut.
-s server nom ou adresse sur serveur de noms.
-p port Port TCP pour la connection au serveur de noms.
-q Mode silencieux. N'affiche que les erreurs
-v mode verbeux
-y key_id utilise la clé spécifié dans le fichier de configuration

Commandes

reload recharge la configuration et les zones
reload zone [class [view]] Recharge une simple zone
refresh zone [class [view]] Effectue une maintenance pour la zone
retransfer zone [class [view]] Retransfert une simple zone sans vérifier le numéro de série
sign zone [class [view]] Prend les clé DNSSEC pour la zone donnée dans le répertoire de clés. Si elles sont dans leur période de publication, les fusionne dans le RRset DNSKEY de la zone. Si ce RRset est changé, la zone est automatiquement re-signée avec le nouveau jeu de clé. Cette commande requière l'option de zone auto-dnssec à allow ou maintain, ainsi que la permission de mise à jours dynamique
loadkeys zone [class [view]] Prend les clé DNSSEC pour la zone donnée dans le répertoire de clés. Si elles sont dans leur période de publication, les fusionne dans le RRset DNSKEY de la zone. la zone n'est pas immédiatement re-signée par les nouvelles clés.
freeze [zone [class [view]]] Suspend les updates pour une zone dynamique ou toutes les zones
thaw zone [class [view]] Active les updates pour une zone dynamique ou toutes les zones
scan Scanne la liste d'interfaces réseaux à la recherche de changement, sans effectuer une reconfiguration complète ou attendre le timer interface-interval.
sync [-clean] [zone [class [view]]] Synchronise les changements dans le fichier journal pour une zone dynamique dans le fichier master. -clean supprime également le fichier journal.
notify zone [class [view]] Renvoie les messages NOTIFY pour la zone
reconfig Recharge le fichier de configuration et les nouvelles zones uniquement
zonestatus [zone [class [view]]] Affiche le status de la zone donnée, incluant le nom du fichier maître et les fichier include, la date de dernière lecture, le numéro de série, nombre de nœuds, si la zone est DDNS, DNSSEC, DNSSEC automatique, etc.
stats Écrit les statistiques du serveur dans le fichier de statistiques.
querylog [on|off] Active le logging des requêtes.
dumpdb [-all|-cache|-zones] [view ...] Dump les caches dans le fichier dump
secroots [view ...] Dump les security roots du serveur dans le fichier secroots pour les vues spécifiées.
stop -p Sauve les updates en cours et stop le serveur. -p retourne le PID du processus.
halt -p Stop le serveur sans sauver les updates en cours. -p retourne le PID du processus.
trace level Change le niveau de debug. (sans spécifier de level, incrémente le niveau de debug de 1)
notrace Définit le niveau de debuggage à 0.
flush Vide le cache du serveur
flushname name [view] Vide le nom donné du cache du serveur DNS et, si applicable, dans la base d'adresse de serveur de nom du serveur ou du cache bad-server
flushtree [-all] name [view] Vide le nom donné, et tous ses sous-domaines, depuis le cache DNS du serveur, la base d'adresse ou le cache bad-server
status Affiche le status du serveur.
recursing Dump les requêtes qui sont recursives
validation (on|off|check) [view] Active/desactive la validation DNSSEC. dnssec-enable doit être à yes ou auto.
tsig-list Liste les noms de toutes les clés TSIG actuellement configurées pour l'utilisation par named dans chaque vue.
tsig-delete keyname [view] Supprime un clé TKEY du serveur. Ne s'applique pas aux clé configurées statiquement.
addzone zone [class [view]] configuration Ajoute une zone à chaud. Nécessite allow-new-zones à yes. La configuration est sauvée dans un fichier appelé hash.nzf où hash est le hash du nom de la vue.
delzone [-clean] zone [class [view]] Supprime un zone à chaud
signing [( -list | -clear keyid/algorithm | -clear all | -nsec3param ( parameters | none )] Liste, édite, ou supprime les enregistrement d'état de signature DNSSEC pour la zone spécifiée. Le status des opérations DNSSEC sont stockés sous la forme de RR de type sig-signing-type. -list convertis ces records dans un format lisible.

Exemples

Ajouter une zone
$rndc addzone example.com ’{ type master; file "example.com.db"; };’
^
18 mars 2016

htmlpdflatexmanmd




rndc-confgen

rndc-confgen

Outil de génération de clé rndc

   rndc-confgen génère des fichiers de configuration pour rndc.

OPTIONS

-a Génère automatiquement une configuration rndc.
-a algorithm Spécifie l'algorithme à utiliser pour la clé TSIG
-b keysize Spécifie la taille de la clé d'authentification en bits
-c keyfile Utilisé avec -a pour spécifier un emplacement alternatif à rndc.key
-k keyname Spécifie le nom de la clé d'authentification. Défaut: rndc-key
-r randomfile Source de données aléatoire pour la génération de l'authorisation
-s address Adresse IP où named écoute pour les connection rndc
-t chrootdir Utilisé avec -a pour spécifier un répertoire où named est chrooté
-u user Utilisé avec -a pour définir le propriétaire de fichier rndc.key généré.
^
14 septembre 2010

htmlpdflatexmanmd




rndc.conf

rndc.conf

Fichier de configuration pour rndc. Il utilise 3 déclarations: options, server, et key

Déclaration options

default-server Spécifie le nom ou l'adresse du serveur de noms.
default-key Spécifie le nom d'un clé, identifiée par une déclaration key
default-port Définit le port de connexion au serveur.
default-source-address Définit l'interface local utilisé pour se connecter au serveur
default-source-address-v6 Idem pour IPv6

Déclaration server

key Spécifie le nom d'un clé, identifiée par une déclaration key
port définit le port de connection au serveur.
addresses Spécifie l'adresse du serveur de nom et optionnellement le port.

Déclaration key

algorithm identifie l'algorithme utilisé
secret Contient le secret partagé.

Exemples

options {
    default-server localhost;
    default-key samplekey;
};
    
server localhost {
    key    samplekey;
};
    
server testserver {
    key     testkey;
    addresses { localhost port 5353; };
};
    
key samplekey {
    algorithm    hmac-sha256;
    secret    "6FMfj43Osz4lyb24OIe2iGEz9lf1llJO+lz";
};
    
key testkey {
    algorithm    hmac-sha256;
    secret    "R3HI8P6BKw9ZwXwN3VZKuQ==";
};

^
31 mars 2016

htmlpdflatexmanmd




rngd

rngd

Vérifie et remplis le pool d'entropie du kernel depuis une source d'entropie

   rngd fonctionne sur des blocks de 20000bits à la fois en utilisant les tests FIPS 140-2 pour vérifier le caractère aléatoire des données. Si la donnée est bien aléatoire, le block est envoyée, random-step*8bits à la fois dans le pool d'entropie du kernel, jusqu'à ce que le poot soit plein.

OPTIONS

-b, --background met en tâche de fond
-f, --foreground Ne fork pas ni ne détache du terminal
-R, --rng-driver=name Pilote de source d'entropie. 'stream' est un pilote d'entrée de flux Unix généraliste capable de reçevoir des données depuis un fichier, un pipe donné, ou un périphérique caractère Unix. 'viapadlock' est un pilote de l'espace utilisateur pour TRNG embarqué sur certains CPU VIA qui ont le moteur de sécurité VIA PadLock
-o, --random-device=file Périphérique pour la sortie de l'entropie. Défaut: /dev/random
-r, --rng-device=file Pilote kernel, fifo ou fichier utilisé pour l'entrée d'entropie. Défaut: /dev/hwrng
--hrng=name Sélectionne un HRNG connu. help liste les HRNG connus.
-H, --rng-entropy=n.n Entropie par bit de donnée d'entrée. C'est un nombre à virgule flottante entre 0 et 1. Défaut: 1.0
-Q, --rng-quality=quality Sélectionne la qualité de la donnée aléatoire qu'une source d'entropie génère. 'default', 'low', 'medium' ou 'high'. N'utiliser que high si la donnée aléatoire est obtenue directement.
-B, --rng-buffers=n Nombre de tampons 20000bits à utiliser. Défaut: 3
-s, --random-step=n Nombre d'octets écris dans le périphérique aléatoire à la fois, entre 8 et 2500. Défaut: 64
-W, --fill-watermark=n[%] Remplis le pool d'entropie jusqu'à atteindre % de données d'entropie dans le pool. Défaut: 50%
-t, --feed-interval=n non-zéro, rngd force en remplir le pool même si celui-ci est plein
-T, --rng-timeout=n Temps à attendre les donnée pour démarrer. 0 attend indéfiniment. Défaut: 10
-p, --pidfile=file Fichier contenant le pid du processus

   rngd dump certaines statistiques dans son canal de sortie chaque heure, et à la reception de SIGUSR1. Ce canal est soit stderr en mode foreground, ou syslog en mode background.

Codes de sortie

0 aucune erreur ne s'est produite
1 La source a un problème
10 problème de paramètres, ou rngd échoue à bloque son pidfile, ou le périphérique ne peut être ouvert
11 Une erreur d'entrée/sortie s'est produite
12 Une erreur de ressource ou de l'os s'est produite
^
31 mars 2016

htmlpdflatexmanmd




rngtest

rngtest

Vérifie le caractère aléatoire des données en utilisant les tests FIPS 140-2

   rngtest travail sur des blockes de 20000bits à la fois, en utilisant les tests FIPS 140-2 pour vérifier le caractère aléatoire du block de données. Il affiche des statistiques sur stderr, et optionnellement affiche les blocks sur stdout.

OPTIONS

-p, --pipe Active le mode pipe. Tous les blockes de données qui passe les test FIPS sont sortis dans stdout, et rngtest opère en mode silencieux
-c, --blockcount=n Quitte après le traitement de n bocks. Défaut: 0
-b, --blockstats=n dump des statistiques tous les n blocks. Défaut: 0
-t, --timedstats=n Dump des statistiques toutes les n secondes. Défaut: 0

Codes de sortie

0 Pas d'erreur
1 Par d'erreur, mais au moins un block a échoué les tests FIPS
10 Problèmes de paramètres
11 Erreur d'E/S
12 Erreur de ressource ou de l'OS
^
17 mars 2010

htmlpdflatexmanmd




route

route

Utilitaire pour afficher et manipuler la table de routage IP du noyau

OPTIONS

-v affiche le mode verbeux
-A famille utilise la famille d'adresse spécifiée (ex : inet, inet6)
-n  Affiche les adresses numériques au lieu des nom d'hôtes.
-e  Utilise netstat pour l'affichage de la table de routage -ee génère une très longue ligne avec tous les paramètres à partir de la table de routage.
-net la cible est un réseau
-host la cible est un hôte
-F Affiche la table de routage FIB du noyau. (FIB: Forwarding Information Base à différencier de RIB: routing Information Base)
-C Affiche le cache de routage du noyau
del Supprime une route
add Ajoute une route

   L'hôte ou le réseau de destination peut être spécifié avec une IP en notation décimale pointée ou un nom d'hôte à ajouter

netmask spécifie le masque de sous-réseau
gw indique le tronçon suivant pour la route
metric Affecte la métric pour la route
mss spécifie le MSS (Maximum Segment Size) de TCP pour les connexions passant par cette route.
window définit la taille de de fenêtre TCP (en octets) pour les connexions passant par cette route.
irtt définis le iRTT initial (round trip time) pour les connexions TCP sur cette route.(en msec)
reject Installe une route bloquante, qui forcera l'échec d'une recherche. utilisé pour masquer les réseaux avant d'utiliser la route par défaut.
mod, dyn, reinstate installe une route dynamique ou modifiée. ne sert que pour des besoins de diagnostique
dev Force la route à être associée au périphérique spécifié.

Exemples

ajoute l'entrée loopback normale
route add -net 127.0.0.0
ajoute une route vers le réseau 192.168.1.0.
route add -net 192.168.1.0 nemask 255.255.255.0 dev eth0
spécifie un réseau et l'adresse de tronçon suivant.
route add -net 192.168.1.0/24 gw 192.168.1.1
ajoute la route par défaut
route add default gw livebox
force le multicast à passer par eth0
route add 224.0.0.0 netmask 240.0.0.0 dev eth0
supprimer une route
route del -net 10.0.0.0/8 gw passerelle

Affichage

les indicateurs possibles sont:
U (la route est active = up)
H (la cible est un hôte)
G (utilise comme passerelle)
R (rétablit la route pour le routage dynamique)
D (dynamiquement configurée par le démon ou par redirect)
M (modifiée par le démon de routage ou par redirect)
(rejète la route)
^
05 décembre 2016

htmlpdflatexmanmd




rpc.idmapd

rpc.idmapd

Mappage de nom/ID nfsv4

   rpc.idmapd est le service de mappage nom ‹-› ID NFSv4. Il fournis cette fonctionnalité aux clients et serveurs en traduisant les UID/GID en noms, et vice versa.

   Le système dérive la partie de la chaîne en effectuant une recherche password ou group. Le mécanisme de recherche est configuré dans /etc/idmapd.conf. Par défaut, la partie de la chaîne est le nom de domaine du système.

   Noter que seul les serveurs NFSv4 utilisent rpc.idmapd. Les clients NFSv4 utilisent nfsidmap, sauf en cas de problème

OPTIONS

-v Mode verbeux. Peut être spécifié plusieurs fois
-F Ne lance pas en tâche de fond
-p path Emplacement du pipefs RCP. Défaut: /var/lib/nfs/rpc_pipefs
-c path Fichier de configuration à utiliser
-C Client uniquement: n'effectue pas de mappage
-S Serveur uniquement: n'effectue pas de mappage
^
09 septembre 2019

htmlpdflatexmanmd




rpm

rpm

Gestionnaire de paquets pour Red-Hat

   rpm est un gestionnaire de paquet qui peut être utilisé pour construire, installer, requêter, vérifier, mettre à jours des paquets Un paquet consiste en une archive de fichiers et de méta-données utilsés pour installer et effacer les fichiers. Les méta-données incluent des scripts helpers, des attributs de fichier, et d'informations descriptive du paquet.

Options générales

--version Affiche la vension de rpm
--quiet Affiche seulement les messages d'erreur
-v, --verbose AFfiche plus d'informations
-vv mode encore plus verbeux
--rcfile FILELIST Liste des fichiers de configuration à lire, séparés pas des ':'. Défaut: /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc
--macro FILELIST Liste des fichiers macro à charger, séparé par des ':'. Défaut: /usr/lib/rpm/macros:/usr/lib/rpm/macros.d/macros.*:/usr/lib/rpm/platform/%{_target}/macros:/usr/lib/rpm/fileattrs/*.attr:/usr/lib/rpm/redhat/macros:/etc/rpm/macros.*:/etc/rpm/macros:/etc/rpm/%{_target}/macros:~/.rpmmacros
--pipe CMD pipe la sortie de RPM avec la commande spécifiée
--dbpath DIR Utilise la base dans le répertoire spécifié. Défaut: /var/lib/rpm
--root DIR Utilise le répertoire spécifié comme racine pour toutes les opérations. Noter que la base utilisé se trouve dans ce répertoire.
-D, --define='MACRO EXPR' Définie la MACRO à la valeur EXPR
--undefine='MACRO' indéfini une macro
-E, --eval='EXPR' Affiche l'expansion de l'expression
--predefine='MACRO EXPR' idem -D, mais avant de charger les fichiers macro
--color [never|auto|always] Utilise les couleurs du terminal
--nocontexts Désactive le plugin SELinux
--noglob N'utilise pas le file globing en installant des fichiers
--nocaps Ne vérifie pas les capabilities des fichiers
--excludeconfigs, --noconfigs N'installe pas les fichiers de configuration
--nohdrchk Ne vérifie pas les en-tête de la base

Options de debuggage

-d, --debug Mode debug
--deploops Affiche les boucles de dépendance en warning
--fsmdebug Affiche des informations de debuggage du code de gestion du payload
--rpmfcdebug Affiche des informations sur les entrées/sortie de fichier
--stats Affiche des statistics temps-réel sur les fonctions utilisées

Options d'installation et de mise à jours

-i, --install Install un nouveau paquet
-U, --upgrade Met à jours ou install un paquet
-F, --freshen Met à jours les package, mais seulement ceux qui ont une version précédente installée

        --reinstall Réinstall un précédent paquet
        --allfiles Install ou met à jours tous les fichiers missingok dans le paquet, sans regarder s'ils existent
        --badreloc avec --relocate, permet la relocation de tous les chemins de fichiers, pas seulement ceux inclus dans OLDPATH
        --excludepath OLDPATH N'install pas les fichier dont le nom commence pas OLDPATH
        --excludedocs N'install pas les fichiers qui sont marqués comme documentation
        --force idem à --replacepkgs --replacefiles et --oldpackage
        -h, --hash Affiche 50 hash quand l'archive est dépaquée. avec -v pour un meilleur affichage
        --ignoresize Ne vérifie pas l'espace disque du système de fichier avant d'installer ce paquet
        --ignorearch install ou met à jour même si l'architecture ne correspond pas
        --ignoreos install ou met à jour même si l'os ne correspond pas
        --includedocs Install les fichiers de documentation (défaut)
        --justdb Met à jour la base de donnée uniquement, pas les fichiers
        --nodigest Ne vérifie pas les digest d'en-tête ou du paquet à sa lecture
        --nomanifest Ne traite pas les fichiers non-package comme manifests
        --nosignature Ne vérifie pas la signature
        --nodeps Ne vérifie pas les dépendances à l'installation/mise à jours
        --nocaps Ne définis pas les capabilities
        --noorder ne réordonne pas les paquets pour une installation. La liste des paquets est normalement réordonnée pour satisfaire les dépendances
        --noplugins Ne charge pas les plugins
        --noscripts, --notriggerin, --notriggerun, --notriggerprein, --notriggerpostun Désactive l'exécution des scriptlets correspondants
        --oldpackage Autorise une mise à jour pour remplacer un paquet avec une version plus ancienne
        --percent Affiche un pourcentage à mesure que les fichiers sont dépaqués
        --prefix NEWPATH Pour les paquets relogeable, traduit tous les chemins de fichier qui commencent avec le préfixe d'installation avec NEWPATH
        --relocate OLDPATH=NEWPATH Pour les paquets relogeable, traduit tous les chemins de fichier qui commencent par OLDPATH avec NEWPATH
        --replacefiles Install les paquets même s'ils remplacent des fichiers d'autres paquets déjà installés
        --replacepkgs Install les paquets même si certains d'entre eux sont déjà installés dans le système
        --test N'install pas le paquet, effectue simplement une vérification et reporte les conflits potentiels

Options d'effacement

-e, --erase Supprime un paquet

        --allmatches Supprime toutes les versions de paquet correspondant au nom donné. Normalement une erreur est donnée si le nom correspond à plusieurs paquets
        --justdb Met à jour la base de données uniquement
        --nodeps Ne vérifie pas les dépendance avant de désinstaller les paquets
        --noscripts, --nopreun, --nopostun N'execute pas les scriptlets correspondant
        --notriggers, --notriggerun, --notriggerpostun N'exécute pas les scriptlets correspondant
        --test N'effectue qu'un test, utile avec -vv

Option de recherche

-q, --query Recherche des paquets
--qf, --queryformat QUERYFMT les formats de recherche sont des versions modifiées du formattage printf(3). Le format est fait de chaînes statiques et de formatteurs type printf(3). Les formats alternatifs avec un tag suivant:

                :armor Ajoute une clé publique en ASCII
                :arraysize Nombre d'élément dans les tags
                :base64 Encode en base64
                :date utilise strftime(3) "%c"
                :day utilise strftime(3) "%a %b %d %Y"
                :depflags Formatte l'opérateur de comparaison de dépendance
                :deptype Formatte de type de dépendance
                :expand Expansion de macro
                :fflags Formatte les flags de fichier
                :fstate Formatte l'état des fichiers
                :fstatus Formatte de status de vérification de fichier
                :hex Formatte en hexa
                :octal Formatte en octal
                :humaniec Nombre human readable en IEC 80000
                :humansi Nombre human readable en SI
                :perms Formatte les permissions de fichier
                :pgpsig Affiche la signature et la date
                :shescape Échappe les guillemets simple
                :triggertype Affiche le suffix trigger
                :vflags Flags de vérification de fichier
                :xml Imbrique dans un balisage XML

Options de sélection de paquet

        PACKAGE_NAME Requête le paquet installé spécifié. Pour spécifier un paquet plus précisemment le paquet peut être suivi pas la version ou version et release, séparés par un ':', ou une architecture séparé par un '.'

        -a, --all [SELECTOR] Requête tous les paquets installés
        --dupes Liste les paquets dupliqués
        -f, --files FILE Recherche les paquets possedant le fichier spécifié
        --filecaps liste les noms de fichier avec las capabilities POSIX1.e
        --fileclass Liste les noms de fichier avec leur classes
        --filecolor Liste les fichier avec leur couleurs (0 noarch, 1 32bits, 2 64bits)
        --fileprovide Liste les noms de fichiers et ce qu'ils fournissent
        --filerequire Liste les noms de fichiers et leur requis
        -g, --group GROUP Recherche les paquets avec les groupe spécifié
        --hdrid SHA1 Recherche des paquets contenant un identifiant d'en-tête donné.
        -p, --package PACKAGE_FILE Recherche un paquet désinstallé
        --pkgid MD5 Recherche un paquet qui contient l'identifiant donné
        --querybynumber HDRNUM Recherche le numéro d'entrée dans la base directement
        --specfile SPECFILE Recherche SPECFILE comme si c'était un paquet. Permet d'extraire des informations sur les spécificité d'un fichier sans avoir à écrire un parser spécifique
        --tid TID Requête les paquets qui ont l'identifiant de transaction spécifié. Un horodatage unix est actuellement utilisé Tous les paquets installé ou effacés dans une seule transaction ont le même identifiant
        --triggeredby PACKAGE_NAME Recherche les paquet qui ont été déclenchés par le paquet spécifié
        --whatobsoletes CAPABILITY Recherche les paquets qui obsolètent la capabilitie pour fonctionner correctement
        --whatprovides CAPABILITY Recherche les paquets qui fournissent la capabilitie
        --whatrequires CAPABILITY Recherche tous les paquet qui nécessitent la capabilitie
        --whatconflicts CAPABILITY Recherche tous les paquets qui sont en conflit avec la capabilitie
        --whatrecommends CAPABILITY Recherche tous les paquets qui recommandent la capabilitie
        --whatsuggests CAPABILITY Recherche tous les paquets qui suggèrent la capabilitie
        --whatsupplements CAPABILITY Recherche tous les paquets qui impléments la capabilitie
        --whatenhances CAPABILITY Recherche tous les paquets qui améliorent la capabilitie

Options de recherche de paquet

        -d, --artifactfiles Liste seulement les artefacts (implique -l)
        --changelog Affiche des informations sur un paquet
        --changes Affiche des informations sur un paquet avec horodatages complets
        -c, --configfiles Liste seulement les fichiers de configuration (implique -l)
        --conflicts Liste les capabilitie qui sont en conflit avec ce paquet
        -d, --docfiles Liste seulement les fichiers de documentation (implique -l)
        --dump Dump les informations de fichier: path size mtime digest mode owner group isconfig isdoc rdev symlink
        --enhances Liste les capabilitie améliorés par ce paquet
        --filesbypkg Liste tous les fichiers dans chaque paquet sélectionné
        --filetriggers Liste tous les scriptlets filetrigger des paquets
        -i, --info Affiche des informations sur le paquet
        --last Ordonne les paquets par date d'installation, du plus récent au plus ancien
        -L, --licensefiles Liste seulement les fichiers de license (implique -l)
        -l, --list Liste les fichiers dans le paquet
        --obsoletes Liste les paquets qui obsolètent ce paquet
        --provides Liste les capabilities que ce paquet fournis
        --recommends Liste les capabilities recommandées par ce paquet
        -R, --requires Liste les capabilities dont ce paquet dépend
        --suggests Liste les capabilities suggérées par ce paquet
        --supplements Liste les capabilitie supplémenté par ce paquet
        --scripts Liste les scriptlets spécifique au paquet qui sont utilisés durant l'installation/désinstallation
        -s, --state Affiche l'état des fichiers dans le paquet (implique -l): normal, not installed, ou replaced
        --triggers, --triggerscripts Affiche les scripts triggers contenus dans le paquet
        --noartifact N'affiche pas les fichier artefacts
        --noghost N'affiche pas les fichiers fantôme.
        --noconfig N'affiche pas les fichiers de configuration
        --xml Formatte les en-têtes en XML

Options de vérification

-V, --verify Vérifie un paquet

        --nodepts Ne vérifie pas les dépendances
        --nodigest Ne vérifie pas le hash des en-tête
        --nofiles Ne vérifie pas les attributs des fichiers
        --noghost Ne vérifie pas le fichiers fantôme
        --noconfig Ne vérifie pas les fichiers de configuration
        --noscripts N'exécute pas le scriptlet %verifyscript.
        --nosignature Ne vérifie pas le paquet ou les signatures d'en-tête
        --nolinkto
        --nofiledigest
        --nosize
        --nouser
        --nogroup
        --nomtime
        --nomode
        --nordev Ne vérifie pas ces attributs de fichier
        --nocaps Ne vérifie pas les capabilitie des fichiers

           Le format de sortie est une chaîne de 9 caractères, un marqueur possible parmis:

                c %config Fichier de configuration
                d %doc Fichier documentation
                g %ghost Fichier dont le contenu n'est pas inclus dans le payload du paquet
                l %license Fichier de license
                r %readme Fichier readme

           Depuis l'en-tête du paquet, suivi par le nom du fichier. Chacun des 9 caractères dénote le résultat d'une comparaison des attributs du fichier à la valeur des attributs enregistrés dans la base. Un '.' signifie que le test est passé, '?' indique que le test ne peut pas être effectué. Sinon, un B denote un echecdans le test correspondant:

                S La taille du fichier diffère
                M Les permissions diffèrent
                5 Le hash md5 diffère
                D Le numéro majeur/mineur diffère
                L Le chemin du lien diffère
                U Le propriétaire diffère
                G Le groupe propriétaire diffère
                T le mTime diffère
                P Les capabilities diffèrent

Options diverses

--showrc Affiche les valeurs que prm utilise pour toutes les options, définies dans les fichiers rpmrc et macro
--setperms, --setugids, --setcaps, --restore Définis le éléments spécifiés des fichiers dans le paquet donné. Préférer --restore, qui restaure tout. mutuellement exclusifs

Options FTP/HTTP

   rpm peut agir comme client ftp ou http. Les url sont sous la forme:

  ftp://USER:PASSWORD@HOST:PORT/path/to/package.rpm

  Si :PASSWORD est omis, il est demandé. Si l'utilisateur et le mot de passe sont omis, utilise ftp anonyme est utilisé. Dans tous les cas, un transfert FTP passif est effectué.

        --ftpproxy HOST Spécifie le proxy ftp à utiliser
        --ftpport PORT Spécifie le port TCP à utiliser
        --httpproxy HOST Spécifie le proxy http à utiliser
        --httpport PORT Spécifie le port http à utiliser

Fichiers

/usr/lib/rpm/rpmrc
/usr/lib/rpm/redhat/rpmrc
/etc/rpmrc
~/.rpmrc Configuration rpmrc
/usr/lib/rpm/macros
/usr/lib/rpm/redhat/macros
/etc/rpm/macros
~/.rpmmacros configuration macro
/var/lib/rpm/Basenames
/var/lib/rpm/Conflictname
/var/lib/rpm/Dirnames
/var/lib/rpm/Group
/var/lib/rpm/Installtid
/var/lib/rpm/Name
/var/lib/rpm/Obsoletename
/var/lib/rpm/Packages
/var/lib/rpm/Providename
/var/lib/rpm/Requirename
/var/lib/rpm/Sha1header
/var/lib/rpm/Sigmd5
/var/lib/rpm/Triggername Base de données
/var/tmp/rpm* Temporaire

Format de requêtes

   rpm permet de spécifie quelles informations afficher et commment les formater. Toutes les informations d'un paquet, hormis les signatures et les fichiers sont des headers. Chaque élément dans le header a un tag associé. La liste des tags peut être obtenue avec rpm --querytags. Un tag consiste d'un élément ou un tableau d'éléments. Chaque élément peut être une chaîne ou un nombre.

  une format de requête est passé après --queryformat similaire à printf(2), mais sans spécifier le type de données à afficher.

        Pour afficher les noms et taille des paquets installés dans le système:
        rpm -qa --queryformat "%{NAME} %{SIZE}\n"
        Pour utiliser les formateurs printf, max 30 caractères du nom et aligner la taille à droite:
        rpm -qa --queryformat "%-30{NAME} %10{SIZE}\n"
        RPM utilise de nombreux tableaux en interne. Par exemple la taille des fichiers et leur nom sont conservés dans des tableaux. Pour itérer dans un jeu de tableaux, utiliser le format:
        rpm -q --queryformat "[%-50{FILENAMES} %10{FILESIZES}\n]" less
        Pour affiche les noms des paquets installés suivis par le nom des fichiers qu'ils contiennt, un par ligne:
        rpm -qa --queryformat "[%{NAME}\n[ %-60{FILENAMES} %10{FILESIZES}\n]]"
        Pour lister les fichiers d'un paquet, avec pour chaque ligne, le nom du paquet suivi du fichier, utiliser le '=' avant NAME afin d'utiliser toujours le premier item de NAME:
        rpm -qa --queryformat "[%{=NAME} %{FILENAMES}\n]" less
        Une des faiblesses avec les formats de recherche est qu'il ne sait pas afficher le tag INSTALLTIME (entre autre) au format date au lieu d'un nombre. Il est possible de spécifier un autre format:
        rpm -q --queryformat "%{NAME} %{INSTALLTIME:date}\n" less
        rpm -q --queryformat "[%{FILEMODES:perms} %{FILENAMES}\n]" less
        rpm -q --queryformat "[%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]" less
        Une simple condition peut être évaluée via les expression, délimités par %[...]. pour afficher present si un tag est présent, missing sinon:
        %|SOMETAG?{present}:{missing}|

Récupération de la base

   Si une commande rpm bloque ou ne se comporte pas correctement, la première chose à vérifier est l'état des fichiers de lock:

  cd /var/lib/rpm && /usr/lib/rpm/rpmdb_stat -CA

  Sous les sections Locks grouped by lockers et Locks grouped by object, il ne devrait pas y avoir d'entrée.

  Le format de la base permet à de nombreux processus d'être en concurrence sur la db, donc il n'y a pas de manière sûr pour une commande RPM d'identifier et de supprimer les locks de manière sûre. Les locks sont maintenus par des fichiers nommés avec 2 '_' initiaux. La meilleurs manière de supprimer les locks est en mode single. Si ce n'est pas possible, utiliser:

  lsof | grep /var/lib/rpm

  pour trouver les programmes qui utilisent la base de données avant de supprimer les locks

Récupérer une base de données corrompue

Si la base de données semble corrompue, le fichier qui doit être reconstruit est le fichier /var/lib/rpm/Packages, puis les index doivent être regénérés. Avant d'effectuer une action potentiellement destructrice, toujours backuper la db:
cd /var/lib && tar zcvf /var/preserve/rpmdb-`date +"%d%m%Y"`.tar.gz rpm
Puis vérifier l'intégrité du fichier Packages:
cd /var/lib/rpm && rm -f __db* && /usr/lib/rpm/rpmdb_verify Packages
Si une erreur est reportée, un dump est requis. Une fois le dump effectué, vérifier l'intégrité du nouveau fichier Package:
mv Packages Packages.orig && /usr/lib/rpm/rpmdb_dump Packages.orig | /usr/lib/rpm/rpmdb_load Packages && /usr/lib/rpm/rpmdb_verify Packages
Si le fichier Packages a passé les vérifications, une vérification supplémentaire vérifie les en-tête dans la db, et recherche tout message envoyés sur stderr:
rpm -qa 1› /dev/null
Si la requête passe sans afficher de message, il est temps de reconstruire les index:
rpm -v --rebuilddb
à ce point, la base devrait être fonctionnelle. Dans le cas contraire, un bug doit être reporté

Macros

   RPM supporte les fichiers de macro. Les macro font de la substitution de texte. Les macro paramétrisés incluent un champ options et effectuent un traitement argc/argv. Durant l'expansion de macro, les flags et arguments sont disponibles comme macro et sont supprimés à la fin de l'expansion. Les macros peuvent être utilisé n'importe où dans un fichier spec, et en particulier dans les listes de fichiers inclus (ceux lus en utilisant %files -f ‹file›. De plus les macros peuvent être imbriqués.

Définir une macro

   Pour définir une macro:

  %define ‹name›[(opts)] ‹body›

  Les noms peuvent être composés de caractères alphanumériques et du caractère '_', 3 caractères minimum. Une macro sans options est simple: une simple expansion récursive est effectuée. Une macro paramétrisée contient le champ options et est passé exactement à getopt(3) pour traiter argc/argv au début de l'appel de la macro. "-" peut être utilisé pour séparer les options des arguments. Durant l'expansion, les macros suivantes sont disponibles:

        %0 Le nom de la macro invoqué
        %* Tous les arguments sans les flags traités
        %** Tous les arguments et flags traités
        %# Le nombre d'arguments
        %{-f} Si présent à l'invocation, le flag f lui-même
        %{-f*} Si présent à l'invocation, l'argument du flag f
        %1, %2 Les arguments eux-même

   À la fin de l'invocation d'une macro paramétrisée, ces macros sont supprimées

Écrire une macro

   Dans le corps d'une macro, il y'a de nombreuses constructions qui permettent de tester la présence de paramètres optionnels. La construction la plus simple, ${-f} s'étend à -f si -f a été mentionnée quand la macro a été invoquée. Il y a également un provisioning pour inclure du texte si le flag est présent %{-f:X}. Cette macro étend à X si le flag est présent. La forme négative est: %{!-f:X}

  En plus de la forme %{...}, l'expansion shell peut être effectuée avec %(shell command) en utilisant /bin/sh. Par exemple: %(date +%%y%%m%%d) étend la date.

Macros intégrées

   Il existe des macro intégrées:

        %trace Affiche des informations de debuggage avant/après l'expansion
        %dump Affiche la table macro active
        %getncpus Nombre de cpu disponibles pour le traitement
        %verbose Si rpm est en mode verbeux
        %dnl ignore la ligne suivante, sans l'étendre
        %{echo:...} Affiche ... sur stdout
        %{warn:...} Affiche ... sur stderr
        %{error:...} Affiche ... sur stderr et génère une erreur
        %define Définis une macro
        %undefine Supprime une macro
        %global Définie une macro dont le corp est disponible dans le contexte global
        %{load:...} Charge un fichier macro
        %{expand:...} Comme eval, étend ... à ‹body› et re-étend ‹body›
        %{shrink:...} Supprime tous les espaces blanc et réduit tous les espaces blanc intermédiaire à un seul espace
        %{quote:...} Met entre guillemets un argument de macro paramétrique
        %{lua:....} Étend avec l'interpréteur lua embarqué
        %{uncompress:...} Étend ... au fichier et test pour voir si le fichier compressé. L'expansion est

                cat ‹file› si non compressé
                gzip -dc Si gzipé
                bzip2 -dc Si bzipé

        %{basename:...} similaire à basename(1)
        %{dirname:...} similaire à dirname(1)
        %{suffix:...} Étend la partie suffixe d'un nom de fichier
        %{url2path:...} Convertit une url à un chemin local
        %{getenv:...} Étend le répertoire home rpm (défaut: /usr/lib/rpm)
        %{S:...} Étend ... au nom de fichier source
        %{P:...} Étend ... au nom de fichier patch
        %{F:...} Étend ... au nom de fichier file

   Noter que %define diffère de %global, pas seulement dans le scope: le corp de %define est étendu plus simplement, mais le corp de %global est étendu au moment de la définition. Il est possible d'utiliser %%- pour forcer l'expansion de %global plus simplement.

  Les macros peuvent être automatiquement étendus s'ils sont dans /usr/lib/rpm/macros.

Interpreteur LUA

rpm embarque un interpréteur LUA et peut être utilisé comme interpréter des scriplets (%pre, %post, etc)
%pre -p ‹lua›
print('Hello from lua")
Les scriptlets sont traités dans le contexte du processus rpm au lieu de forker un nouveau processus. Celà a un avantage sur un scriptlet /bin/sh: plus rapide, pas de dépendances requise, et il peut créer de nouvelles macros par exemple.
À l'initialisation, rpm exécute le script /usr/lib/rpm/init.lua.

Exemples

Installer un paquet
rpm -i less
mettre à jour un paquet
rpm -U less
Lister tous les paquets installés
rpm -qa
Savoir si un paquet est installé
rpm -q vsftpd
Lister les dépendances d'un paquet
rpm -qR audit
Afficher des informations sur un paquet installé
rpm -qi audit
Afficher les fichiers installés et leur état
rpm -qls audit
Pour revenir à une ancienne version d'un paquet:
rpm -Uvh --oldpackage less
Importer une clé GPG afin de valider les paquets téléchargés
rpm --import /mnt/cdrom/RPM_GPGKEY
Voir les clé installées:
rpm -qa gpg-pubkey*
Vérifier un paquet:
rpm -K /tmp/audit-2.7.8-1.fc26.x86_64.rpm
^
09 septembre 2019

htmlpdflatexmanmd




rpm2cpio

rpm2cpio

Extrait une archive cpio depuis le gestionnaire de paquet RPM

   rpm2cpio convertis un fichier rpm en archive cpio sur la sortie standard. Si un '-' est donné en argument, lit l'entrée standard

rpm2cpio glint-1.0-1.i386.rpm | cpio -dium
cat glint-1.0-1.i386.rpm | rpm2cpio - | cpio -tv

^
09 septembre 2019

htmlpdflatexmanmd




rpmdb

rpmdb

Outil de base de données rpm

   rpmdb est un utilitaire de manipulation de base de données rpm.

OPTIONS

--initdb Créé une nouvelle base de données si elle n'existe pas.
--rebuilddb Reconstruit les indices de la base de données

Options communes à tous les utilitaires rpm

-D, --define='MACRO EXPR' Définie la MACRO à la valeur EXPR
--undefine='MACRO' indéfini une macro
-E, --eval='EXPR' Affiche l'expansion de l'expression
--target=CPU-VENDOR-OS Spécifie la plateforme
--noplugins Ne charge pas les plugins
--nodigest Ne vérifie pas le hash des en-tête
--nosignature Ne vérifie pas le paquet ou les signatures d'en-tête
--rcfile FILELIST Liste des fichiers de configuration à lire, séparés pas des ':'. Défaut: /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc
--dbpath DIR Emplacement de la base de données
--root DIR Spécifie le répertoire racine
--querytags Afficher les tags de requête connus
--showrc Affiche les valeurs que prm utilise pour toutes les options, définies dans les fichiers rpmrc et macro
--quiet Affiche seulement les messages d'erreur
-v, --verbose AFfiche plus d'informations
^
09 septembre 2019

htmlpdflatexmanmd




rpmkeys

rpmkeys

Gestion de clés rpm

   Utilitaire d'import et de vérification de clé pgp pour rpm

OPTIONS

--import PUBKEY ... Importe une clé publique dans la base rpm
-K, --checksig Vérifie les signatures et digest contenu dans le paquet pour s'assurer de l'integrité et de l'origine du paquet.
--test N'importe rien, test simplement l'import

Options communes à tous les utilitaires rpm

-D, --define='MACRO EXPR' Définie la MACRO à la valeur EXPR
--undefine='MACRO' indéfini une macro
-E, --eval='EXPR' Affiche l'expansion de l'expression
--target=CPU-VENDOR-OS Spécifie la plateforme
--noplugins Ne charge pas les plugins
--nodigest Ne vérifie pas le hash des en-tête
--nosignature Ne vérifie pas le paquet ou les signatures d'en-tête
--rcfile FILELIST Liste des fichiers de configuration à lire, séparés pas des ':'. Défaut: /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc
--dbpath DIR Emplacement de la base de données
--root DIR Spécifie le répertoire racine
--querytags Afficher les tags de requête connus
--showrc Affiche les valeurs que prm utilise pour toutes les options, définies dans les fichiers rpmrc et macro
--quiet Affiche seulement les messages d'erreur
-v, --verbose AFfiche plus d'informations

Exemples

Toutes les clé importée peuvent être affichées avec:
rpm -qa gpg-pubkey*
Afficher des détails sur une clé importée:
rpm -qi pgp-pubkey-db42a60e
Supprimer une clé pgp de la base:
rpm -e gpg-pubkey-db42a60e
^
24 décembre 2016

htmlpdflatexmanmd




rquotad

rquotad, rcp.rquotad

Serveur de quota distant

   rpc.rquotad est un serveur rpc qui retourne les quotas d'un utilisateur d'un système de fichier local qui est monté par une machine distante via NFS. Il permet également de définir les quotas dans les systèmes de fichiers NFS. En résultat, quota affiche les quotas utilisateurs pour les systèmes de fichiers distants et edquota permet de le définir. rquotad utilise tcp-wrappers qui permet de spécifier les hôtes autorisés à utiliser le service.

OPTIONS

-s, --no-setquota Ne permet pas de définis les quotas.
-S, --setquota Permet de définir les quotas
-F, --foreground Ne lance pas en tâche de fond
-I, --autofs N'ignore pas les points de montage autofs
-p port, --port port Port d'écoute alternatif
-x path, --xtab path Fichier d'export nfs alternatif. Utilisé pour déterminer le pseudoroot des exports NFSv4. Le pseudoroot est ainsi ajouté à chaque chemin relatifs reçus dans une requête RPC quota
^
20 juillet 2017

htmlpdflatexmanmd




rsync

rsync

Outil de copie de fichier

   rsync est un outils de copie de fichier versatile. Il peut copier localement, depuis/vers un autre autre via un shell distant, ou vers/depuis un service rsync distant. Il offre un grand nombre d'options qui contrôle tous les aspects de son fonctionnement, et permet de spécifier de manière très flexible le jeu de fichiers à copier. Il à un algorithme de transfert delta, qui réduit la quantité de données envoyées sur le réseau en envoyant seulement les différences entre les fichiers sources et les fichiers existants dans la destination. rsync est largement utilisé pour les sauvegardes et le mirroring et comme commande de copie améliorée.

   rsync trouve les fichiers qu'il doit transférer en utilisant un algorithme vérification rapide (par défaut) qui recherche les fichier qui ont changé en taille ou de mtime. Tout changement dans les autres attributs préservés (comme requis par les options) sont fait dans le fichier de destination directement quand la vérification rapide indique que les données du fichiers n'ont pas besoin d'être mis à jours.

   rsync copies les fichier depuis ou vers un hôte distant, ou localement. Il y a 2 manières différentes pour rsync pour contacter un système distant: utiliser un shell distant (tel que ssh ou rsh), ou contacter un service rsync directement via TCP. le transport par shell distant est utilisé quand le chemin source ou de destination contient un séparateur ":" après la spécification de l'hôte. Contacter un service rsync se fait en spécifiant le séparateur '::' après la spécification de l'hôte, ou quand une url rsync:// est spécifiée.

   Un cas spéciale, si un argument de source simple est spécifié dans destination, les fichiers sont listés dans un format de sortie similaire à 'ls -l'.

   Comme attendu, si ni le chemin source ni de destination ne spécifie d'hôte distant, la copie se produit localement.

   rsync réfère au côté local comme le 'client' et le côté distant comme le 'serveur', à ne pas confondre avec le service rsync, qui est toujours un serveur, mais un serveur qui peut être soit un service ou un processus lancé par un shell distant.

Utilisation

   Il est possible d'utiliser rsync de la même manière que rcp, à l'exception que rsync n'accepte qu'un seul hôte distant.

La meilleur manière d'expliquer la syntaxe est avec certains exemples:
rsync -t *.c foo:src/
Cela transfert tous les fichiers correspondant au motif *.c du répertoire courant vers un répertoire src sur la machine foo. Si un des fichiers existe déjà sur le système distant, le protocole de mise à jours distant de rsync est utilisé pour mettre à jours le fichie en envoyant seulement les données différente. Noter que l'expansion du wildcard sur la ligne de commande en une liste de fichiers est gérée par le shell avant de lancer rsync.
rsync -avz foo:src/bar /data/tmp
Transfert récursivement tous les fichiers du répertoire src/bar dans la machine foo dans le répetoire local /data/tmp/bar. Les fichiers sont transférés

OPTIONS

-v, --verbose Augmente la quantité d'informations données durant le transfert. Peut être spécifié plusieurs fois.
--info=FLAGS Permet de spécifier plus finement les informations à afficher. Utiliser --info=help pour voir les flags disponibles. les flags sont séparés par des ","
--debug=FLAGS Idem mais avec des informations plus verbeuses.
--msgs2stderr Envoie sa sortie sur stderr au lieu de stdout. Principalement pour debug.
-q, --quiet Mode silencieux, utile avec cron
--no-motd Affecte les informations qui sont affichés au démarrage du transfert du service. Il supprime le mot du jours et la liste des modules.
-I, --ignore-times Normalement rsync saute les fichiers qui existent déjà avec la même taille et le même mtime. Cette option désactive le mode vérification rapide, forçant tous les fichiers à être mis à jours.
--size-only Modifie l'algorithme de vérification rapide pour trouver les fichiers qui doivent être transférés. Seuls les fichiers avec une taille différente sont mis à jours. Utile pour utiliser rsync avec un système de mirroring qui ne préserve pas les timestamps.
--modify-window En comparant 2 timestamps, rsync traite les timestamps comme étant égaux s'ils diffèrent par moins que la valeur modify-window. C'est par défaut 0. En particulier, en transférant depuis ou vers un système de fichier FAT qui a une précision à 2 secondes, --modify-window=1 est utile.
-c, --checksum Change la manière dont rsync vérifie si les fichiers ont été changés et ont besoin d'être transférés. Sans cette options, rsync utilise la vérification rapide. Ce option compare un checksum 128-bits pour chaque fichier. La génération des checksums signifie que le client et le serveur vont consommer plus de lecture disque, ce qui peut ralentir les choses significativement.
-a, --archive C'est équivalent à -rlptgoD. C'est une manière rapide de dire que vous souhaiter une récursion et préserver tout. La seul exception par rapport à l'équivalence et quand --files-from est spécifié, auquel cas -r n'est pas induit. Noter que -a ne préserve pas les liens hard, utiliser -H.
--no-OPTION Permet de désactiver une option en préfixant le nom de l'option avec -no. Toutes les options ne peut pas être préfixé de cette manière, seules les options qui sont sous-entendues par d'autres options (ex: --no-D, --no-perms) ou ont des valeurs par défaut en fonction des circonstances (ex: --no-whole-file, --no-blocking-io, --no-dirs). Note: l'ordre des options est importante
-r, --recursive Dit à rsync de copier les répertoires récursivement. La récusivité est incrémentale, le transfert commence avant que tous les répertoires aient été scannés. certaines options nécessite un scan complet et désactivent la récursivité incrémentale.
-R, --relative Utilise les chemins relatifs. Le chemin complet spécifié sur la ligne de commande est envoyé au serveur au lieu de simplement envoyer la dernière partie des noms de fichiers.
--no-implied-dirs Affecte le comportement de l'option --relative. Si spécifié, les attributs des répertoires implicites des noms sources ne sont pas inclus dans le transfert. Cela signifie que les éléments de chemins sur la destination ne sont pas changé, et les répertoires créés le sont avec des attributs par défaut.
-b, --backup Avec cette option, des fichiers de destination pré-existant sont renommé quand le fichier est transféré ou supprimé.
--backup-dir=DIR Avec --backup, indique où stocker les backup. Peut être utilisé pour les backups incrémentals.
--suffix-SUFFIX Permet de changer le suffixe backup par défaut pour l'option --backup. Défaut: "~" ou vis si --backup-dir a été spécifié
-u, --update Force rsync à ignorer tout fichier existant dans la destination
--inplace Chanqe la méthode de transfert d'un fichier quand les données sont mis à jours. Au lieu de créer une nouvelle copie du fichier et en le déplaçant une fois complété, rsync écrit directement dans le fichier de destination
--append Met à jours un fichier en ajoutant les données à la fin du fichier, ce qui suppose que les données déjà existante dans la destination est identique avec le début du fichier.
--append-verify Similaire à --append, mais les données existant sont inclus dans le checksum de vérification.
-d, --dirs Indique à l'émetteur d'inclure tous les répertoire rencontrés. À la différence de --recursive, le contenu des répertoires ne sont pas copiés sauf si le nom du répertoire est "." ou se termine par "/". --recursive a précédence.
-l, --links Quand les liens sont rencontrés, recréé les liens dans la destination
-L, --copy-links Quand des liens sont rencontrés, l'élément pointé est copié au lieu du lien.
--copy-unsafe-links Copie la référence des liens symboliques en dehors de l'arborescence copiée.
--safe-links Ignore les liens symboliques pointant en dehors de l'arborescence copiée.
--munge-links Modifie tous les liens symbolique reçu pour les rendre inutilisable, mais récupérable, ou réactive les liens stockés dans un état munge. rsync désactive les lients en les préfixant avec la chaîne /rsync-munged/. Celà empêche d'utiliser les liens tant que ce répertoire n'existe pas.
-k, --copy-dirlinks Traite les liens vers un répertoire comme si c'est un vrai répertoire
-K, --keep-dirlinks idem à -k, mais seulement s'il matche un vrai répertoire de l'émetteur.
-H, --hard-links Recherche les liens hard dans la source et les lies ensemble aux fichiers correspondant dans la destination.
-p, --perms Copie les permissions
-E, --executability Préserve la permission 'x' des fichiers réguliers quand --perms n'est pas activé.
-A, --acls Met à jours les ACL. Implique également --perms
-X, --xattrs met à jours les attributs étendus
--chmod Applique un ou plusieurs modes de permission aux fichiers transférés.
-o, --owner Définis le propriétaire du fichier de destination
-g, --group Définis le groupe propriétaire du fichier de destination
--devices Transfert les fichiers caractère et block
--specials transfert les fichiers spéciaux tels que les fichiers sockets et fifo
-D = --devices --spécials
-t, --times Transfert les horodatages de modification des fichiers
-O, --omit-dir-times Omet les répertoire avec --times. Utile avec NFS sur des répertoires partagés
-J, --omit-link-times Omet les liens symboliques en préservant les dates de modifications (--times)
--super Tente les activités root même si le receveur n'est par root: --owner, --groups et --devices.
--fake-super Simule les activités root en sauvant/restaurant les attributs privilégiés via des attributs étendus spéciaux attachés à chaque fichier (si nécessaire). Gère également --acls et --xattrs s'ils sont spécifiés
-S, --sparse Tente de gérer les fichiers sparses efficacement pour qu'ils prennent moins d'espace sur la destination. Est en conflit avec --inplace
--preallocate Indique au reçeveur d'allouer chaque fichier de destination avant d'écrire les données. rsync utilise le support de préallocation du système de fichier via fallocate(2). Avec cette options les gros fichier peuvent ne pas être contigüs.
-n, --dry-run Effectue une simulation qui ne change rien. Utile avec --verbose et/ou --itemize-change
-W, --whole-file Désactive l'algorithme de transfert delta de rsync. Peut être plus rapide si la bande passante entre la source et la destination est supérieure à la bande passante du disque.
--checksum-choice=STR Change l'algorithme de checksum. (auto, md4, md5, none)
-x, --one-file-system Ne traverse pas les systèmes de fichier lors des récursion. Si cette option est répétée, rsync omet tous les répertoires de point de montage qu'il rencontre
--existing, --ignore-non-existing Saute la création de fichiers et répertoires qui n'existent pas dans la destination. Combinée avec --ignore-existing, aucun fichier n'est mis à jours.
--ignore-existing Met à jours les fichiers qui existent déjà dans la destination.
--remove-source-files Indique à rsync de supprimer les fichiers envoyés qui font partie du transfert et ont été dupliqués avec succès
--delete Supprime les fichiers dans le receveur (ceux qui n'ont pas été envoyés), mais uniquement pour les répertoires qui sont synchronisés
--delete-before Demande que la suppression de fichiers dans le receveur soit fait avant que le tranfert commence.
--delete-during, --del Demande que la suppression de fichiers dans le receveur soit fait incrémentalement durant le transfert
--delete-delay Demande que la suppression de fichiers dans le receveur soit calculé durant le transfert, puis supprimé à la fin du transfert
--delete-after Demande que la suppression de fichiers dans le receveur soint fait une fois le transfert complété.
--delete-excluded En plus de supprimer les fichiers dans le receveur qui ne sont pas dans l'émetteur, indique de supprimer également tous fichier dans le receveur qui sont exclus
--ignore-missing-args Quand rsync traite d'abord les fichiers sources demandés explicitement (ex --files-from), si le fichier n'est pas trouvé, ne génère pas d'erreur et ne tente pas de transférer le fichier.
--delete-missing-args Idem, mais chaque argument manquant devient une requête de suppression
--ignore-errors --delete supprime les fichier quand il y a des erreurs d'entrées/sorties
--force Supprime un répertoire non-vide quand il est remplacé par un non-répertoire.
--max-delete=NUM Indique de ne pas supprimer plus de NUM fichiers/répertoires. Au delà, toutes les suppressions sont ignorées. rsync retourne avec un code d'erreur 25
--max-size=SIZE Évite les transferts de fichiers supérieurs à la taille spécifiée.
--min-size=SIZE Évite les transferts de fichiers inférieurs à la taille spécifiée.
-B, --block-size=BLOCKSIZE Force la taille de block utilisé dans l'algorithme de transfert delta à une taille fixe.
-e, --rsh=COMMAND Permet de choisir un shell distant alternatif à utiliser pour la communication.
--rsync-path=PROGRAM Spécifie le programme à lancer sur la machine distante pour démarrer rsync.
-M, --remote-option=OPTION Utilisé pour limiter certains effets sur le transfert, comme --log-file et --fake-super
-C, --cvs-exclude Raccourci utile pour exclure un grande plage de fichier. la liste d'exclusion est: RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/ .git/ .hg/ .bzr/
-f, --filter=RULE Ajoute une règle d'exclusion de fichier
-F Raccourci pour ajouter 2 --filter, la première fois est un raccourci à --filter='dir-merge /.rsync-filter', qui indique de recherche les fichiers .rsync-filter dans les répertoire et d'utiliser leurs règles.
--exclude=PATTERN Forme simplifiée de l'option --filter
--exclude-from=FILE Cette option est liée à --exclude, mais spécifie un fichie qui contient des motifs d'exclusion.
--include=PATTERN Forme simpifiée de --filter qui créé une règle d'inclusion
--include-from=FILE Liée à --include, mais spécifie un fichier qui contient des motifs d'inclusion
--files-from=FILE Spécifie la liste exacte de fichiers à transférer. Il personnalise également le comportement de rsync:

        -R, --relative Implicite, et préserve les informations de chemin qui sont spécifiés pour chaque éléments dans le fichier.
        -d, --dirs Implicite, qui créé les répertoires spécifiés dans la liste dans la destination
        -a, --archive n'implique pas --recursive

-O, --fromO Les règles/noms de fichiers lus depuis un fichier sont terminés par un caractère null (\0). Affecte --exclude-from, --include-from, --files-from, et tous fichiers fusionnés spécifiés dans une règle --filter
-s, --protect-args Envoie tous les noms de fichier et les options au rsync distant sans permettre au shell distant de les interpréter.
-T, --temp-dir=DIR Utiliser le répertoire comme répertoire scratch en créant des copies temporaires des fichiers transférés. Le comportement par défaut est de créer chaque fichier temporaire dans le même répertoire que le fichier de destination associé
-y, fuzzy Indique à rsync qu'il doit rechercher un fichier de base pour tout fichier de destination manquant. l'algorithme actuel recherche dans le même répertoire que le fichier de destination un fichier qui a une taille et un mtime identique, ou un fichier de même nom. Si trouvé, rsync utilise le fichier pour accélerer le transfert. Si cette option est répétée, le fuzzy scan également tous les répertoires de destination correspondant qui sont spécifié via --compare-dest, --copy-dest ou --link-dest
--compare-dest=DIR Utilise le répertoire dans la destination comme hiérarchie additionnelle pour comparer les fichiers de destination. Si un fichier est trouvé dans ce répertoire qui est identique au fichier à envoyer, le fichier n'est pas transféré
--copy-dest=DIR Identique à --compare-dest, mais rsync copie également les fichiers inchangés trouvés dans ce répertoire. Peut être spécifié plusieurs fois
--link-dest=DIR identique à --copy-dest, mais les fichiers inchangés sont hardlinked depuis ce répertoire .
-z, --compress Compresse les données envoyée
--compress-level=NUM Niveau de compression
--skip-compress=LIST Liste de suffixe de fichier qui ne sont pas compressés. La liste par défaut est: 7z ace avi bz2 deb gpg gz iso jpeg jpg lz lzma lzo mov mp3 mp4 ogg png rar rpm rzip tbz tgz tlz txz xz z zip
--numeric-ids Transfert les UID/GID au lieu d'utiliser les noms d'utilisateur/groupe.
--usermap-STRING, --groupmap=string Spécifie les utilisateurs et groupe qui doivent être mappés à d'autres valeurs dans le receveur. Le chaîne consiste d'une ou plusieurs paires de FROM:TO.
--chown=USER:GROUP Force tous les fichiers à être possédés par l'utilisateur et groupe spécifiés
--timeout=TIMEOUT Permet de définir un timeout d'E/S maximum, en secondes. Si aucune données n'est transférée durant ce laps de temps, rsync quitte.
--contimeout Délais d'attente pour une connexion avant de quitter
--address Spécifie une adresse IP de connexion
--port=PORT Port TCP pour la connexion. Défaut: 873
--sockopts Fournis des options de socket. voir setsockopt(2)
--blocking-io Utilise les E/S bloquant en lançant un shell distant. Si le shell distant est rsh ou remsh, rsync l'utilise par défaut
--outbuf=MODE Définis le mode de buffering par défaut. Peut être None, Line, ou Block
-i, --itemize-changes Demande une simple liste itemisée de changement qui sont faits à chaque fichier, incluant les changements d'attributs. Identique à --out-format='%i %n%L'.
--out-format=FORMAT Spécifie ce que le client rsync affiche à l'utilisateur sur une base par mise à jours. Défaut: "%n%L" si --info ou -v est spécifié.
--log-file=FILE log les opérations dans un fichier
--log-file-format=FORMAT Format des messages loggés Défaut: '%i %n%L'
--stats Affiche un jeu de statistiques durant le tranfert. Cette option est équivalente à --info=stats2 ou --info=stats3.
-8, -8-bit-output laisse les caractères 8-bits non échappé dans la sortie au lieu de les tester pour voir s'ils sont valides dans la locale courante
-h, --human-readable Affiche les nombre au format human-readable
--partial par défaut, rsnyc supprime tout fichier partiellement transféré si le transfert a été interrompu. cette option permet de conserver le fichier partiel pour accélérer les transferts suivants
--partial-dir=DIR Spécifie un répertoire utilisé pour maintenir les données partielles
--delay-updates Place le fichier temporaire de chaque fichier mis à jours dans un répertoire jusqu'à la fin du transfert, puis tous les fichiers sont renommés. Cela rend les mises à jours un peu plus atomiques mais utilise plus de mémoire
-m, --prune-empty-dirs Indique au receveur de gérer les répertoires vide depuis la liste des fichier, incluant les répertoires imbriqués qui ont des enfant non-répertoire. C'est utile pour éviter la création d'un grand nombre de répertoires inutiles
--progress Affiche la progression du transfert
-P Équivalent à --partiel --progress
--password-file=FILE Permet de fournir un mot de passe pour accéder au service rsync via un fichier ou via l'entrée standard avec '-'.
--list-only Liste les fichiers sources au lieu de les transférer
--bwlimit=RATE Limite le taux de transfert
--write-batch=FILE Enregistre un fichier qui peut être appliqué ultérieurement à une autre destination identique avec --read-batch.
--only-write-batch=FILE Similaire à --write-batch, excepté qu'aucune mise à jours n'est faite dans le système de destination en créant le batch
--read-batch=FILE Applique tous les changements stockés dans le fichier précédemment généré par --write-batch
--protocol=NUM Permet de forcer une ancienne version de protocole. Utile avec --write-batch
--iconv=CONVERT_SPEC Convertis les noms de fichier entre les jeux de caractères. '.' indique à rsync de regarder le jeu de caractère par défaut
-4, --ipv4, -6, --ipv6 Socket à utiliser
--checksum-seed=NUM Définis le checksum d'envoie. Ce checksum de 4 octets est inclus dans chaque block et chaque calcul MD4 (MD5 n'utilise pas de seed).

Options pour le mode service

--daemon Lance rsync en mode service. Le service devient accessible en utilisant host::module ou rsync://host/module/
--address IP d'écoute du service
--bwlimit=RATE Permet de spécifier le taux de transfert maximum pour les données que le service envoie
--config=FILE Spécifie le fichier de configuration
-M, --dparam=OVERRIDE Définis un paramètre de configuration spécifique au service
--no-detach Ne détache pas le service en tâche de fond
--port=PORT Spécifie le port TCP d'écoute
--log-file=FILE Remplace le paramètre log file dans la configuration
--log-file-format=FORMAT Remplace le paramètre log format dans la configuration
--sockopts Remplace le paramètre socket options dans la configuration
-v, --verbose mode verbeux
-4, --ipv4, -6, --ipv6 Spécifie la famille d'adresse d'écoute

Règles de filtrage

   Les règles de filtrage permet une sélection flexible des fichiers à transférer et à exclure. Les règles spécifient soit directement des motifs d'inclusion/exclusion pour spécifie une manière d'acquérir plus de motifs (par ex en lisant un fichier)

Vu que la liste des fichiers/répertoires est construite, rsync vérifie chaque nom à transférer avec la liste, et le premier match est acté. rsync construit une liste ordonnée de règles de filtrage tel que spécifié dans la ligne de commande. Les règles de filtrage ont la syntaxe suivante:
RULE [PATTERN_OR_FILENAME]
RULE,MODIFIERS [PATTERN_OR_FILENAME]

   Le motif ou nom de fichier qui suit, si présent, doit venir après soit un simple espace, ou un '_'. Les préfixes de règles disponibles sont:

exclude, - spécifie un motif d'exclusion
include, + Spécifie un motif d'inclusion
merge, . Spécifie un fichier où liste plus de règles
dir-merge, : Spécifie un fichier par répertoire
hide, H Spécifie un motif pour cacher des fichiers du transfert
show, S Spécifie un motif pour afficher des fichiers
protect, P Spécifie un motif pour protéger les fichiers de la suppression
risk, R Ces fichier ne sont pas protégés
clear, ! effaces la liste d'inclusion/exclusion courante, n'a pas d'argument.

   Noter que les options --include/--exclude ne permettent pas tous les préfixes, ils autorisent seulement les motifs d'inclusion/exclusion, et '!' pour effacer la liste. Si un motif ne commence pas avec "- " ou "+ ", la règle est interprétée comme si "+ " (pour une option include), ou "- " (pour une option exclude). Une option --filter doit toujours contenir un nom de règle court ou long au début de la règle.

Règles de motif d'exclusion/inclusion

   Pour inclure et exclure des fichier, utiliser "+", "-", etc. Les règles spécifient un motif qui est matché avec les noms des fichiers qui doivent être transférés. Ces motifs peuvent prendre plusierus forme:

- Si le motif commence avec un '/', il est attaché à un emplacement particulier dans la hiérarchie des fichiers, sinon il est matché avec la fin d'un nom de chemin. C'est similaire à un '^' de début dans les expressions régulières. donc /foo matche un nom foo soit à la racine du transfert ou dans le répertoire dans le cas d'un merge-file.
- Si le motif se termine avec un /, il ne matche qu'un répertoire, pas un fichier régulier, ni lien ni périphérique.
- rsync choisi entre faire un simple match et un match wildcard en vérifiant si le motif contient un des caractères wildcard '*', '?', et '['
- un '*' matche tous composant de chemin, mais il s'arrête aux '/'
- addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo Match tout, incluant les '/'
- ? Matche tout caractère excepté '/'
- [ introduit une classe de caractères
- Dans un motif wildcard, un '\' permet d'échapper un caractère wildcard.
- Si le motif contient un '/' (sans compter le '/' final) ou un '**', il est matché avec le chemin complet. Si le motif ne contient pas de '/' ou '**', il est matché seulement avec le composant final du nom de fichier.
- un 'dir_name/***' final match le répertoire et tout ce qu'il contient.

   Noter que, en utilisant --recursive, qui est implicite avec -a, tous les sous-répertoires de tous les chemins sont visités de gauche à droite, chaque répertoire ayant une chance d'être exclus avant son contenu. De cette manière les motifs d'inclusion/exclusion sont appliqués récursivement au nom de fichier de chaque nœud dans le système de fichier. Les motifs d'exclusion court-circuitent l'étape de parcours du répertoire.

Par exemple, pour inclure /foo/bar/baz, les répertoires /foo et /foo/bar ne doivent pas être exclus. Exclure un de ces parent empêche d'examiner son contenu. Le concept d'exclusion est particulièrement important en utilisant un '*' final, par exemple, ceci ne fonctionne pas:
+ /some/path/this-file-will-not-be-found
+ /file-is-included
-    *

Une solution est de demander à tous les répertoires dans la hiérarchie d'être inclus en utilisant une simple règle "+ */", et utiliser l'option --prune-empty-dirs. Une autre solution est d'ajouter des règles d'inclusion spécifiques pour tous les répertoires parents qui doivent être visités:
+ /some/
+ /some/path/
+ /some/path/this-file-is-found
+ /file-also-included
-    *

'- *.o' Excluse tous les nom matchant *.o
'- /foo' Exclus un fichier ou répertoire nommé foo dans le répertoire racine du transfert
'- foo/' Exclus tout répertoire nommé foo
'- foo/*/bar' Exclus tout fichier nommé bar 2 ou plusieurs niveaux sous un répertoire nommé foo
'+ */', '+ *.c', '- *' La combinaison de ces motifs incluent tous les répertoires et les fichiers source C mais rien d'autre (voir également l'option -prine-empty-dirs)
'+ foo/', '+ foo/bar.c', '- *' La combinaison de ces motifs incluent seulement le répertoire foo et foo/bar.c

   Les modifiers suivants sont acceptés après un '+' ou '-':

- un '/' spécifie que la règle d'inclusion/exclusion doit matcher le chemin absolu de l'élément. Par exemple, '-/ /etc/password' exclus le fichier /etc/passwd, et '-/ subdir/foo' exclus toujours foo quand il est dans un répertoire nommé subdir.
- un '!' spécifie que l'inclusion/exclusion prend effet si le motif échoue au matche. Par exemple, '-! */' exclus tous les non-répertoires
- un 'C' est utilisé pour indiquer que toutes les règles d'exclusion CVS globales devraient être insérés comme exclusion à la place de '-C'. n'a pas d'argument
- un 's' est utilisé pour indiquer que la règle s'applique côté émetteur. Quand une règle affecte l'émetteur, il empêche les fichiers d'être transférés. Par défaut, un règle affecte les 2 côté sauf avec --delete-excluded, auquel cas seul l'émetteur est affecté.
- un 'r' est utilisé pour indiquer que la règle s'applique au receveur. Quand une règle affecte le receveur, il empêche la suppression des fichiers.
- un 'p' indique qu'une règle est périssable, signifiant qu'elle est ignorée dans les répertoires qui sont supprimés. Par exemple, les règles -C qui excluent des éléments tels que CVS et *-o sont marqués comme périssable, et n'empêchent pas un répertoire qui a été supprimé dans la source d'être supprimé dans la destination

Règles de filtre merge-file

   Il est possible de fusionner tous les fichiers dans des règles de filtrage en spécifiant soit une règle de filtre merge (.), ou un dir-merge (:). Un fichier est est lus une seule fois, et ses règles sont incorporées dans la liste de filtre à la place de la règle '.'. pour les fichiers merge par répertoire, rsync scanne chaque répertoire qu'il traverse à la recherche du fichier, et fusionne son contenu dans la liste courante des règles héritées. Ces règles par répertoire doient être crées côté émetteur.

Par exemple:
merge /etc/rsync/default.rules
. /etc/rsync/default.rules
dir-merge .per-dir-filter
dir-merge,n- .non-inherited-per-dir-excludes
:n- .non-inherited-per-dir-excludes

   Les modifiers suivants sont acceptés après une règle merge ou dir-merge:

- un '-' spécifie que le fichier devrait consister seulement de motifs d'exclusion
- un '+' spécifie que le fichier devrait consister seulement de motifs d'inclusion
- un 'C' est une manière de spécifie que le fichier devrait être lu à la manière d'un CSV. Celà active 'n', 'w', et '-', mais autorise également le jeton '!'.
- un 'e' exclus le nom du merge-file du transfert
- un 'n' spécifie que les règles ne sont pas hérités par les sous-répertoires
- un 'w' spécifie que les règle sont séparés par un espace blanc au lieu d'être séparés par des newline. Cela désactive les commantaires

   Les règles sont hérité sauf si 'n' est spécifié. Chaque règles de sous-répertoire a une priorité supérieur aux règles héritées. Quand la règle d'effacement de liste est lu dans un fichier par-répertoire, il efface seulement les règles héritées. Une autre manière d'empêcher l'héritage d'une règle est de l'attacher avec un '/'. Ces règles sont relatives au répertoire du merge-file, dont un motif '/foo' ne match que le fichier foo dans le répertoire.

Exemple de fichier de filtre qui peut être spécifié via --filter="file"
merge /home/user/.global-filter
- *.gz
dir-merge .rules
+ *.[ch]
- *.o

   Cela fusionne le contenu du fichier /home/user/.global-filter au début de la liste et active le fichier .rules comme filtre par répertoire. Toutes les règles lues avant le début du scan de répertoire suivent la règle globales.

Si un merge-file par répertoire est spécifié avec un chemin qui est un répertoire parent du premier répertoire, rsync scan tous les répertoires parents depuis le point de départ à la recherche du fichier par-répertoire. Par exemple:
--filter=': /.rsync-filter'

Indique à rsync de scanner ce fichier dans tous les répertoire depuis la racine vers le répertoire parent du transfert avant de commencer le scan de répertoire normal. Quelques exemples de ce pré-scan:
rsync -avF /src/path/ /dest/dir
rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir
rsync -av --filter=': .rsync-filter' /src/path/ /dest/dir

   Les 2 premières commandes recherchent .rsync-filter dans '/' et '/src' avant que le scan normal commence à regarder dans /srv/path et ses sous-répertoires. La dernière commande évite le scan de répertoire parent et ne recherche que les fichiers .rsync-filter dans chaque répertoire qui font partie du transfert.

Pour inclure le contenu d'un .cvsignore dans les motifs, il faut utiliser la règle ':C', qui créé un dir-merge de fichier .cvsignore, mais parsé d'une manière compatible cvs. On peut l'utiliser pour affecter, quand l'inclusion de l'option -C du fichier .cvsignore par-répertoire est placé dans les règle avec ':C'. Sans celà, rsync ajoute la règle dir-merge pour le fichier .cvsignore à la fin de toutes les autres règles. Par exemple:
cat ‹‹EOT | rsync -avC --filter='. -' a/ b
+ foo.o
:C
- *.old
EOT
rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b

   Ces commandes sont identiques. Chacune va fusionner les règles .cvsignore par-répertoire au milieu de la liste au lieu de la fin. Cela permet aux règle par répertoire de remplacer les règles qui suivent le :C au lieu d'être subordonné à toutes les règles. Pour affecter les autres règles CVS d'exclusion (par ex. la liste d'exclusion par défaut, le contenu de $HOME/.cvsignore, et la valeur de $CVSIGNORE) il faut omettre -C et insérer un règle '-C' dans les règles de fitre; par ex: --filter=-C

Règle de filtre d'effacement le liste

   Pour effacer la liste d'inclusion/exclusion, utiliser la règle '!'. La liste courante est soit la liste globale de règle (si la règle est rencontrée en parsant les options de filtre), ou un jeu le règle par répertoire (qui sont hérités dans leur propre sous-liste, donc un répertoire peut l'utiliser pour effacer les règle parent)

Motifs include/exclude attachés

   Comme mentionné plus haut, les motifs include/exclude globaux sont attachés à la racine du transfert. Cette racine gouverne les motifs commençant par un '/'. Parce que le matching est relatif à cette racine, changer le slash dans le chemin source ou changer l'utilisation de l'option --relative affecte le chemin à utiliser dans les match. Les exemples suivant le démontrent.

Disont que l'on souhaite matcher 2 fichiers sources, un avec un chemin absolue "/home/me/foo/bar" et un avec un chemin "/home/you/bar/baz". Voici divers choix de commande qui diffèrent pour un transfert:
#› rsync -a /home/me /home/you /dest
+/- pattern: /me/foo/bar
+/- pattern: /you/bar/baz
Target file: /dest/me/foo/bar
Target file: /dest/you/bar/baz
    
#› rsync -a /home/me/ /home/you/ /dest

+/- pattern: /foo/bar (note missing "me")
+/- pattern: /bar/baz (note missing "you")
Target file: /dest/foo/bar
Target file: /dest/bar/baz
    
#› rsync -a --relative /home/me/ /home/you /dest
+/- pattern: /home/me/foo/bar (note full path)
+/- pattern: /home/you/bar/baz (ditto)
Target file: /dest/home/me/foo/bar
Target file: /dest/home/you/bar/baz
    
#› cd /home; rsync -a --relative me/foo you/ /dest
+/- pattern: /me/foo/bar (starts at specified path)
+/- pattern: /you/bar/baz (ditto)
Target file: /dest/me/foo/bar
Target file: /dest/you/bar/baz

Règles par-répertoire et suppression

Sans option delete, les règles par-répertoire sont seulement significatif du côté de l'émetteur, donc on peut exclure les fichiers merge eux-même sans affecter le transfert. Pour simplifier, le modifier 'e' ajoute cette exclusion:
rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest
rsync -av --filter=':e .excl' host:src/dir /dest

Cependant, pour faire une suppression dans l'émetteur et exclure certains fichiers de la suppression, il faut s'assurer que le receveur connaisse les fichiers à exclure. La manière la plus simple est d'inclure les fichiers merge dans le transfert et utiliser --delete-after, parce que cela s'assure que le recerveur à toutes les règles d'exclusion avant de tenter quoi que ce soit:
rsync -avF --delete-after host:src/dir /dest

Cependant, si les fichiers merge ne font pas partie du transfert, il faut spécifier des règles d'exclusion globales, ou maintenir les fichiers merge par répertoire côté receveur. Par exemple:
rsync -av --filter=': .rules' --filter='. /my/extra.rules' --delete host:src/dir /dest

Le fichier extra.rules peut affecter les 2 côtés du transfert, mais côté emeteur les règles sont subordonnés aux règles fusionnées depuis les fichiers .rules. Dans un dernier exemple, le distant exclus les fichiers .rsync-filter du transfert, mais on souhaite utiliser les fichiers .rsync-filter pour contrôler ce qui est supprimé. Pour cela il faut spécifiquement exclure les fichiers de merge par répertoire et placer les règles dans les fichiers locaux pour contrôler ce qui ne devrait jamair être supprimé:
rsync -av --filter=':e /.rsync-filter' --delete host:src/dir /dest
rsync -avFF --delete host:src/dir /dest

Mode batch

   Le mode batch peut être utilisé pour appliquer le même jeu de mises à jours à de nombreux systèmes identiques. Supposons une arborescence qui est répliquée dans plusieurs hôtes. Supposons que certains changements ont été fait dans cette arborescence et doivent être propagés sur tous les hôtes. Pour faire celà en mode batch, rsync est lancé avec l'option write-batch, qui stocke toutes les informations dans un fichier.

   En générant le fichier batch une fois effectue le status de fichier, checksum et génération de block de données. Les protocoles de transport multicast peuvent être utilisés pour transférer les fichiers de mises à jours batch en parallèle.

   Pour appliquer les changements enregistrés dans une autre arborescence de destination, lancer rsync avec l'option read-batch, en spécifiant le nom du fichier et de l'arborescence. Un fichier script peut également être créé quand l'option write-batch est utilisé: il est nommé avec le même nom que le fichier batch avec l'extension '.sh'. Ce script contient une ligne de commande utilisable pour mettre à jour une arborescence de destination en utilisant le fichier batch associé.

Exemples:
$ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
$ scp foo* remote:
$ ssh remote ./foo.sh /bdest/dir/
    
$ rsync --write-batch=foo -a /source/dir/ /adest/dir/
$ ssh remote rsync --read-batch=- -a /bdest/dir/ ‹foo

   Dans ces exemples, rsync est utilisé pour mettre à jours /adest/dir/ depuis /source/dir/ et les information sont stockés dans 'foo' et 'foo.sh'. L'hôte distant peut ainsi être mis à jours avec les données batchés pour le répertoire /bdest/dir. La différence entre les 2 exemples révèlent une certaine flexibilité sur la manière de gérér les batchs:

- Le premier exemple montre que la copie initiale n'a pas à être locale, on peut pousser ou envoyer les données depuis/vers un hôte distant en utilisant un shell distant ou le service rsync
- Le premier exemple utiliser le fichier foo.sh pour obtenir les options rsync en lancant la commande read-batch sur l'hôte distant.
- Le second exemple lit le batch via l'entrée standard donc le batch n'a pas à être copié dans la machine distante. Cet exemple évite le fichier foo.sh.

   L'option read-batch s'attend à ce que l'arborescence de destination qui est mise à jours soit identique à l'arborescence de destination utilisée pour créer le batch. Quand une différence est trouvée la mise à jour n'est pas effectuée avec une alerte (si le fichier apparaît être déjà à jour) ou tenté et donc, si le fichier échoue la vérification, la mise à jour n'est pas effectuée avec une erreur. Cela signifie que relancer l'opération est sûre si la commande est interrompue. Pour forcer la mise à jour à toujours tenter sans regarder la taille et les données, utiliser l'option -I. Si une erreur se produit, l'arborescence de destination va probablement être dans un état de mise à jour partielle. Dans ce cas, rsync peut être utilisé dans son mode régulier non-batch pour fixer la destination.

   La version rsync utilisé dans toutes les destinations doit être au moins aussi récente que celle qui a été utilisée pour générer le batch. rsync s'arrête si la version du protocole dans le batch est trop récent.

   En lisant un batch, rsync force la valeur de certaines options pour matcher les données dans le fichier batch si elles ne sont pas définies à la même valeur que la commande write-batch. D'autres options peuvent être changées. Par exemple, --write-batch changé en --read-batch, --files-from est supprimé, et les options --filter/--include/--exclude ne sont pas nécessaires à moins qu'une option --delete soit spécifiée

   Le code qui créé le batch.sh transforme toutes les options filter/include/exclude en une simple liste qui est ajoutée comme un "here" document dans le script shell. Tout utilisateur avancé peut l'utiliser pour modifier la liste si un changement est désiré avec --delete.

Liens symboliques

   3 comportements sont possible quand rsync rencontre un lien symbolique dans le répertoire source. Par défaut les liens symbolique ne sont pas transférés du tout. Un message 'skipping non-regular" est émis. Si --links est spécifié, les symlinks sont recréés avec la même cible. Si --copy-links est spécifié, leur référant est copié au lieu du lien. rsync peut également distinguer les liens sûres et non-sûres. Par exemple, cela peut être utilisé pour un site web mirroir pour s'assurer que le module rsync qui est copié n'inclus pas les liens symboliques vers des fichier qui pointent sur la destination. --safe-links omet les liens non-sûres.

   Les liens symboliques sont considérés comme non-sûres s'ils sont des liens absolus (commençant par '/'), vides, ou s'ils contiennent suffisamment de '..'. Voici un sommaire des options de liens et leur interprétation. Cette liste est dans l'ordre de précédence:

--copy-links Transforme tous les liens en fichiers normaux
--links, --copy-unsafe-links Transforme tous les liens non-sûres en fichier et duplique tous les liens sûrs.
-copy-unsafe-links Transforme tous les liens non-sûres en fichier, et ignore les liens sûres
--links, --safe-links Duplique les liens sûres et ignore les non-sûres
--links Duplique tous les liens

Diagnostique

rsync produit occasionnellement des messages d'erreur qui peuvent être difficile à comprendre, tel que "protocol version mismatch - is your shell clean?". Ce message est généralement généré par les scripts de démarrage ou shell distant produisant des données incorrectes dans le flux que rsync utilise pour son transport. Pour diagnostiquer ce problème, lancer un shell distant commen:
ssh remotehost /bin/true › out.dat
et lire ce fichier. Si tout est correcte, il devrait être vide.

Codes de sortie

0 succès
1 Erreur de syntaxe ou d'utilisation
2 Incompatibilité de protocole
3 Erreurs en sélectionnant les fichiers/répertoires d'entrée/sortie
4 Action demandée non supportées
5 Erreur en démarrage le protocole
6 Service incapable d'ajouter dans le fichier de log
10 Erreur d'E/S socket
11 Erreur d'E/S dans le fichier
12 Erreurs avec les diagnostiques
14 Erreur dans le code IPC
20 SIGUSR1 ou SIGINT reçu
21 Erreurs retournées par waitpid()
22 Erreur en allouant les buffers mémoire
23 Transfert partiel à cause d'erreur
24 Transfert partiel à cause de fichiers sources disparus
25 Limite --max-delete atteint
30 Timeout dans l'envoie/reception des données
35 Timeout durant la connexion avec le service

Variables d'environnement

CVSIGNORE Définie les fichiers .cvsignore
RSYNC_ICONV Spécifie le paramètre --iconv
RSYNC_PROTECT_ARGS Spécifie un valeur non-zéro pour activer l'option --protect-args
RSYNC_RSH Définis le shell par défaut utilisé comme transport pour rsync
RSYNC_PROXY Redirige le client rsync pour utiliser un proxy web
RSYNC_PASSWORD Mot de passe pour lancer une connection authentifiée
USER nom de l'utilisateur
LOGNAME Nom de l'utilisateur
HOME Répertoire personnel de l'utilisateur pour trouver le fichier .cvsignore
^
20 juillet 2017

htmlpdflatexmanmd




rsyncd.conf

rsyncd.conf

Fichier de configuration pour le mode service de rsync

Lancer le service

   Le service rsync est lancée avec l'option --daemon. Le service doit être lancé avec les privilèges root si l'on souhaite utiliser chroot, pour utiliser un port inférieur à 1024, ou pour définir les propriétaires des fichier. Sinon, il doit simplement avoir la permission de lire et écrire les données appropriées, logs, et fichiers de lock.

Le service peut être lancé via inetd, comme service standalone, ou depuis un client rsync via un shell distant. Via inetd, une ligne dans /etc/services:
rsync 873/tcp
et une ligne dans /etc/inetd.conf:
rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon

Paramètres globaux

   Les premiers paramètres dans le fichier, avant tout [module], sont les paramètres globaux. rsync autorise également l'utilisation d'en nom de module [global]. Il est possible d'inclure des paramètres de modules dans la partie globale auquel cas la valeur remplace la valeur par défaut pour ce paramètre

   Il est possible de référencer des variables d'environnement dans les valeurs des paramètres, sous la forme %VAR%.

motd_file Permet de spécifier un message du jour à afficher au client.
pid file Écris le pid dans le fichier
port Port d'écoute du service
address Address d'écoute du service
socket options Options socket pasés à setsockopt()
listen backlog Valeur backlog quand le service écoute les connexions. Défaut: 5

Paramètres de module

comment Spécifie une description pour le module
path Répertoire disponible dans ce module
use chroot à true, rsync chroot dans le path avant de commencer le transfert de fichier
numeric ids Désactive le mappage des utilisateurs et groupe pou le module
numge symlinks modifie les liens comme --munge-links
charset Jeu de caractère avec lequel les noms des fichiers du module sont stockés. Utiles avec --iconv
max connections Spécifie le nombre de connexions simultanné maximum
log file Log les messages dans le fichier au lieu de syslog
syslog facility facilité syslog (auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0-7)
max verbosity Niveau de verbosité (de 1 à 4)
lock file spécifie le fichier à utiliser pour supporter le paramètre max connections. Défaut: /var/run/rsyncd.lock
read only Détermine si les clients sont capables d'uploader des fichiers ou non.
write only Détermine si les clients sont capables de télécharger des fichiers ou non.
list Détermine si ce module est listé quand le client demande un listing des modules disponibles. De plus, à false, le service prétend que le module n'existe pas quand un client est refusé par hosts allow|deny.
uid uid pour le service rsync
gid gid pour le service rsync
fake super à yes, le service fonctionne comme avec l'option --fake-super
filter Le service possède sa propre chaîne de filtre qui determine quels fichiers le client peut accéder
exclude Liste de motifs d'exclusion
include Liste de motifs d'inclusion
exclude from Fichier contenant des motifs d'exclusion
include from Fichier contenant des motifs d'inclusion
incoming chmod Permet de spécifier un jeu de chaînes chmod qui affectent les permissions de tous les fichiers entrants. Ces changements se produisent après tout les autres calculs de permission
outgoing chmod Permet de spécifier un jeu de chaînes chmod qui affectent les permissions de tous les fichiers sortants. Ces changements se produisent en premier, les permissions apparaîssent différentes de celles stockées dans le système de fichier
auth users Spécifie une liste de règles d'autorisations. Cela peut être une liste d'utilisateurs et peut contenir des caractères wildcard shell. Les usernames et passwords sont stockés dans le fichier spécifié par le paramètre secrets file. Utiliser '@' pour spécifier un groupe. Chaque utilisateur et groupe peut être suffixé par :‹deny|ro|rw› pour restreindre les accès. Pour spécifier un utilisateur ou groupe avec un espace dans le nom, commencer la liste avec une ','
secrets file Spécifie le fichier qui contient les paires username:password et/ou @group:password utilisés pour l'authentification du module.
strict modes Détermine si les permissions dans le fichier secret sont vérifiés. à true, le fichier ne doit pas être lisible par tout le monde
hosts allow Spécifie une liste de motifs qui sont matchés avec l'ip ou hostname des clients. Si aucun motif ne match, la connexion est rejetée
hosts deny Spécifie une liste de modifs qui sont matchés avec l'ip ou hostname des clients. si un motif match, la connexion est refusée
reverse lookup Effectue une recherche inversée sur l'ip du client pour déterminer le nom d'hôte
forward lookup Effectue une recherche sur les hôtes spécifiés dans les paramètre host allow/deny.
ignore errors Ignore les erreurs d'E/S dans le service en décidant s'il lance la phase delete du transfert.
ignore nonreadable Ignore complètement les fichiers qui ne sont pas lisibles par l'utilisateur.
transfer logging Active le logging par fichier dans un format similaire à celui utilisé par les services ftp. Le service log toujours le transfert à la fin, donc si le transfert est annulé, rien n'est mentionné dans le fichier de log.
log format Spécifie le format utilisé pour logger les transferts de fichier. l'apostrophe permet d'indiquer que la valeur doit être au format human-readable.

        %a IP distante (mode service uniquement)
        %b Nombre d'octets transférés
        %B Bits de permissions du fichier
        %c Taille totale des checksums de block reçus (seulement pour l'envoie)
        %C Checksum du fichier complet
        %f Nom du fichier
        %G GID du fichier
        %h Nom d'hôte distant (uniquement pour le mode service)
        %i Liste itemizée de ce qui est mis à jours
        %l Longueur en octets du fichier
        %L La chaîne -› SYMLINK", " =› HARDLINK", ou ""
        %m Nom du module
        %M mtime du fichier
        %n nom du fichier, forme courte
        %o L'opétation (recv, send, ou del)
        %p PID du service
        %P Chemin du module
        %T Date courante
        %u L'utilisateur authentifié
        %U uid du fichier

timeout Remplace le choix du timeout du client.
refuse options Spécifie une liste d'options qui son refusées par le service. Si une de ces options est reçue, le service affiche un message d'erreur et quite.
dont compress motifs spécifiant les fichiers qui ne sont pas compressés
pre-xfer exec, post-xfer exec Commande à lancer avant et/ou après le transfert. si pre-xfer exec échoue, le transfert est annulé. Les variables d'environnement suivantes sont définies:

        RSYNC_MODULE_NAME Nom du module accédé
        RSYNC_MODULE_PATH Chemin configuré du module
        RSYNC_HOST_ADDR IP du client
        RSNYC_HOST_NAME Nom d'hôte du client
        RSYNC_USER_NAME Nom de l'utilisateur
        RSYNC_PID Identifiant unique pour ce transfert
        RSYNC_REQUEST pre-xfer uniquement: module/chemin spécifié par l'utilisateur
        RSYNC_ARG# Arguments
        RSYNC_EXIT_STATUS post-xfer uniquement: Valeur de sortie côté serveur.
        RSYNC_RAW_STATUS post-xfer uniquement: Valeur brut de sortie pour waitpid()

Directives config

   Il y a 2 directives disponibles qui permettent à un fichier de configuration d'incorporer le contenu d'autres fichiers: &include et &merge. Elles permettent de référencer un fichier ou un répertoire. Elles diffèrent dans la manière dont le contenu des fichiers sont considérés.

   &include traite chaque fichier plus distinctement, chacun héritant des défaut du fichier parent, en commençant par traitres les défaut/globaux, et laissant les défauts inchangés pour le parsing du reste du fichier parent

   &merge traite chaque fichier comme s'il était simplement inséré à la place de la directive

   L'avantage de &inclade est que l'on peut définir un ou plusieurs modules dans un fichier séparé sans s'inquiéter des effets inattendus entre les fichiers de modules auto-contenus. L'avantage de &merge et que l'on peut charger des snippets qui peuvent être inclus dans plusieurs définitions de modules, et que l'on peut définir des valeurs globales qui affectent les connections

Authentification forte

   Le protocole d'authentification utilisé dans rsync est un système de challenge réponse MD4 128bits. C'est une protection faible. Il est donc recommandé de lancer rsync dans ssh.
^
14 juillet 2010

htmlpdflatexmanmd




runcon

runcon

Lance une commande dans le contexte de sécurité SELinux spécifié

   Si aucune option n'est spécifiée, le premier argument est utilisé comme contexte complet. Sans options ni commande, affiche le contexte de sécurité courant.

OPTIONS

-c, --compute Calcule le contexte de transission du processus avant de le modifier
-u USER, --user=USER Définis l'utilisateur dans le contexte de sécurité cible.
-r ROLE, --role=ROLE Définis le role dans le contexte de sécurité cible
-t TYPE, --type=TYPE Définis le type dans le contexte de sécurité cible
-l RANGE, --range=RANGE Définit la plage dans le contexte de sécurité cible
^
19 octobre 2013

htmlpdflatexmanmd




saslauthd

saslauthd

Service qui manipule les authentifications plaintext basé sur la librarie Cyrus SASL

OPTIONS

-a authmech Spécifie le mécanime à utiliser
-O option Options spécifiques au mécanisme, incluant l'hôte à contacter
-m path Chemin du socket pour les connexions (défaut : /var/state/saslauthd) sans "/mux"
threads Nombre de threads à traiter (défaut : 5)
-s size Taille de la table de hash en Ko
-t timeout temps d'expiration du cache d'authentification en secondes
-T' Honore les restriction de connection time-of-day
-c' Active le cache des crédentials
-l' Désactive l'utilisation d'un file lock pour contrôller l'accès à accept()
-r' Combine le roaume avec le login.
-d' Mode debug

Mécanismes d'authentification

getpwent Authentifie avec un fichier password local
kerberos4 Authentification kerberos v4
kerberos5 Authentification kerberos v5
pam' Utilise PAM
rimap' Remote IMAP server.
shadow' Utilise le fichier shadow local
sasldb' Authentifie avec la base SASL
ldap' Authentifie avec un serveur LDAP
sia' Authentifie en utilisant SE Linux
^
22 mars 2016

htmlpdflatexmanmd




sbattach

sbattach

Outil de signature détachée de boot sécurisé UEFI

OPTIONS

--attach ‹sigfile› Définis sigfile comme table de signature d'image de boot
--detach ‹sigfile› Copie la tabe de signature de l'image de boot dans sigfile
--remove Supprime la table de signature d'image de boot du fichier original
^
22 mars 2016

htmlpdflatexmanmd




sbkeysync

sbkeysync

Met à jours la base de clé EFI

OPTIONS

--efivars=path ‹dir› Point de montage efivars
--verbose Mode verbeux
--pk Définis PK
--keystore ‹dir› Lis les clé depuis le répertoire spécifié
--no-default-keystores Ne lit pas le clé depuis le keystore par défaut
--dry-run Ne met pas à jours la base de clé
^
22 mars 2016

htmlpdflatexmanmd




sbsiglist

sbsiglist

Crée une base de signature EFI_SIGNATURE_LIST

OPTIONS

--owner ‹guid› GID propriétaire de la signature
--type ‹type› Type de signature (sha256)
--output ‹type› Écris la donnée signé dans le fichier
^
22 mars 2016

htmlpdflatexmanmd




sbsign

sbsign

Outil de signature de boot sécurisé UEFI

OPTIONS

--key ‹keyfile› Clé de signature (RSA au format PEM)
--cert ‹certfile› Certificat x509
--detached Écrire une signature détaché, au lieu d'un binaire signé
--output ‹file› Écrit la donnée signé dans le fichier.
^
22 mars 2016

htmlpdflatexmanmd




sbvarsign

sbvarsign

Outil de signature de variable authentifié UEFI

OPTIONS

--key ‹keyfile› Clé de signature (RSA au format PEM)
--cert ‹certfile› Certificat x509
--include-attrs Inclus les attributs au début du fichier de sortie
--guid ‹GUID› GUID EFI pour la variable
--attr ‹attrs› Variable (NON_VOLATILE, BOOTSERVICE_ACCESS, RUNTIME_ACCESS, TIME_BASED_AUTHENTICATED_WRITE_ACCESS, APPEND_WRITE)
--output ‹file› Écris la donnée signé dans le fichier
^
22 mars 2016

htmlpdflatexmanmd




sbverify

sbverify

Outil de vérification de boot sécurisé UEFI

OPTIONS

--cert ‹certfile› Certificat x509
--no-verify Ne vérifie pas le certificat
--detached lit la signature depuis le fichier
^
30 juin 2014

htmlpdflatexmanmd




sclient

sclient

Application client exemple

   sclient est une application d'exemple, principalement pour des tests. Il contacte un serveur d'exemple, sserver, et s'authentifie en utilisant un ticket Kerberos, puis affiche la réponse du serveur.

^
31 mars 2017

htmlpdflatexmanmd




scomes

scomes

Outil d'analyse des ressources système

   scomes est un script systemtap pour regarder l'activité d'un processus. compteur d'appels système, ticks userspace et kernelspace, octets lus et écris, octets reçus et transmis, et interrogation syscalls.

OPTIONS

binary fichier binaire à exécuter
timer affiche des statistiques toutes les n secondes
^
15 juin 2017

htmlpdflatexmanmd




scp

scp

Secure CoPy

   scp copie des fichiers entre les hôtes dans un réseau. Il utilise ssh pour le transfert de données, et utilise la même authentification et fournis la même sécurité que ssh. scp demande les mots de passe si nécessaire

   Les noms de fichier peuvent contenir une spécification hôte et user pour indiquer que le fichier est copié depuis/vers cet hôte. Les noms de fichiers locaux peuvent être explicite avec des chemins absolus ou relatifs.

OPTIONS

-3 Les copies entre 2 hôtes distant sont transférrée via l'hôte local. Sans cette option la copie est directe entre les 2 hôtes distants.
-4 Force l'utilisation des adresses IPv4 uniquement
-6 Force l'utilisation des adresses IPv6 uniquement
-C Active la compression. cette options est passée à ssh
-c cipher Sélectionne le chiffrement à utiliser pour chiffrer le tranfert de données. cette options est passée à ssh
-F ssh_config Spécifie un fichier de configuration alternatif pour ssh. cette options est passée à ssh
-i identity_file Sélectionne la clé privée pour l'authentification à clé publique. cette options est passée à ssh
-l limit Limite la bande passante utilisée, spécifiée en Kbit/s
-o ssh_option Passe des options à ssh, au format ssh_config
-P port port de connection sur l'hôte distant
-p Préserve les atime et mtime et les modes des fichiers originaux
-q Mode silencieux. N'affiche pas de progression
-r Copie récursivement les répertoires. Noter que scp suit les liens symboliques
-S program Nom du programme à utiliser pour chiffrer la connexion. Le programme doit comprendre les options ssh
-v mode verbeux
^
08 mai 2017

htmlpdflatexmanmd




secolor.conf

secolor.conf

Fichier de configuration de couleur SELinux

Ce fichier contrôle la couleur associée aux composants de contexte associés au context raw passé par selinux_raw_context_to_color(3). Quand les informations lié au contexte sont affichées en couleur par une application compatible SELinux. Le fichier a le format suivant:
color color_name = #color_mask
[...]
    
[...]
context_component string    *    fg_color_name bg_color_name

color Le mot clé color
color_name nom de la couleur (ex: red)
color_mask Masque de couleur avec un # qui décris les couleurs RGB hexadécimal. black = #000000 et white = #ffffff
context_component Nom du composant de contexte (user, role, type ou range)
string change context_component qui matche le contexte raw. un '=' peut être utilisé pour matcher toute les types.
fg_color_name nom de couleur utilisé pour le texte
bg_color_name Nom de couleur utilisé pour le fond

Exemples

Exemple 1:
color black = #000000
color green = #008000
color yellow = #ffff00
color blue = #0000ff
color white = #ffffff
color red = #ff0000
color orange = #ffa500
color tan = #D2B48C
user * = black white
role * = white black
type * = tan orange
range s0-s0:c0.c1023 = black green
range s1-s1:c0.c1023 = white green
range s3-s3:c0.c1023 = black tan
range s5-s5:c0.c1023 = white blue
range s7-s7:c0.c1023 = black red
range s9-s9:c0.c1023 = black orange
range s15:c0.c1023 = black yellow
Exemple 2:
color black = #000000
color green = #008000
color yellow = #ffff00
color blue = #0000ff
color white = #ffffff
color red = #ff0000
color orange = #ffa500
color tan = #D2B48C
user unconfined_u = #ff0000 green
role unconfined_r = red #ffffff
type unconfined_t = red orange
user user_u = black green
role user_r = white black
type user_t = tan red
user xguest_u = black yellow
role xguest_r = black red
type xguest_t = black green
user sysadm_u = white black
range s0:c0.c1023 = black white
user * = black white
role * = black white
type * = black white
^
05 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/securetty_types

/etc/selinux/‹SELINUXTYPE›/contexts/securetty_types

Fichier de configuration de type tty sécurisé SELinux

   Ce fichier contient une liste de types associés aux type tty qui est définis dans la stratégie utilisée par les application. Chaque ligne dans ce fichier contient un type définis dans la stratégie pour les périphériques tty sécurisés

Exemple

sysadm_tty_device_t
user_tty_device_t
staff_tty_device_t
^
18 octobre 2016

htmlpdflatexmanmd




sed

sed

Éditeur de flux, utilisé pour effectuer des transformations de texte basiques

OPTIONS

-n, --quiet, --silent Par défaut, sed affiche le motif à la fin de chaque cycle. Cette option désactive cet affichage.
-e SCRIPT, --expression=SCRIPT Ajoute les commandes dans le script au jeu de commandes à lancer durant le traitement de l'entrée
-f SCRIPTFILE, --file=SCRIPTFILE AJoute les commandes contenues dans le script au jeu de commande à lancer durant le traitement de l'entrée
-i[SUFFIX], --in-place[=SUFFIX] Spécifie que les fichiers sont à éditer sur place. Sed créé un fichier temporaire et envoie la sortie dans ce fichier au lieu de stdout. Cette option implique '-s'. Quand la fin du fichier est atteinte, il est renommé au fichier d'origine. L'extension, si fournie, est utilisé pour renommer l'ancien fichier.
-l N, --line-length=N Spécifie la longueur de ligne par défaut pour la commande 'l'. 0 signifie de ne jamais couper les lignes. Défaut: 70.
--posix Se conforme à POSIX. identique à définir POSIXLY_CORRECT.
-b, --binary Pour les OS faisant la distinction entre les fichiers binaire et fichiers textes, comme MS-DOS, Windows.
--follow-symlinks Seulement avec -i. Si le fichier spécifié est un lien symbolique, sed suit le lien et édite la cible.
-r, --regexp-extended Utilise les expressions régulières étendues au lieu des expressions régulières de base.
-s, --separate Par défaut, sed considère les fichiers spécifiés comme un seul long flux. Cette option permet à l'utilisateur de les considérer comme flux séparés. Les numéros de ligne sont relatifs au début de chaque fichier, '$' réfère à la dernière ligne de chaque fichier, et les fichiers invoqués depuis des commandes 'R' sont remis au début de chaque fichier
-u, --unbuffered Met en tampon l'entrée et la sortie aussi minimal que pratique. Particulièrement utile si l'entrée via depuis des commandes comme tail -f, et que vous souhaitez voir la sortie transformée le plus vite possible.
-z, --null-data, --zero-terminated Traite l'entrée comme jeu de ligne, chacune terminée par un ASCII NUL au lieu d'une nouvelle ligne.

Fonctionnement

   sed maintient 2 tampons: l'espace _pattern_ actif, et l'espace auxiliaire _hold_. Ils sont vide à l'initialisation. sed opères en effectuant le cycle suivant sur chaque ligne d'entrée: d'abord, sed lit une ligne depuis le flux d'entrée, supprime tout newline de fin, et la place dans l'espace pattern. Les commandes sont ensuite exécutées; chaque commande peut avoir une adresse associée: les adresses osnt un type de code de condition, et une commande est seulement exécutée si la condition est vérifiée avant d'exécuter la commande.

   Quand la fin du script est atteint, sauf si l'option -n est utilisé, le contenu de l'espace pattern est affiché dans le flux de sortie, en ajoutant un newline à la fin s'il avait été supprimé. Puis le cycle démarre pour la ligne suivante.

   Sauf pour les commandes spéciales (comme 'D'), l'espace pattern est supprimé entre 2 cycles. L'espace hold, conserve ses données entre les cycles (voir les commandes h, H, x, g, G pour se déplacer entre les tampons)

Expressions régulières

   Les adresses dans un script sed peut être une des formes suivantes:

NUMBER Spécifie un numéro de ligne qui va matcher seulement cette ligne dans l'entrée.
FIRST~ STEP Match chaque ligne par pas en commençant avec le ligne FIRST. Par exemple, pour sélectionner les lignes impaires: 1~2.
$ Matche la dernière ligne du dernier fichier d'entrée, ou la dernière ligne de chaque fichier quand -i ou -s sons spécifiés
/REGEXP/ Sélectionne les lignes qui matchent l'expression régulière. L'expresion vide (//) répète la dernière expression régulière qui a matché.
\%REGEXP% Matche l'expression régulière, mais permet d'utiliser un autre délimiteur que '/'
/REGEXP/I, \%REGEXP%I l'expression régulière matche en étant insensible à la casse.
/REGEXP/M, \%REGEXP%M matche l'expression régulière en mode multi-ligne. '^ matche également la chaîne vide aprèse un newline, '$' la chaîne vide avant un newline. '\`' et '\'' matchent toujours le début ou la fin du tampon. ',' ne matche pas un caractère newline en mode multi-ligne
0,/REGEXP/ Un numéro de ligne 0 peut être utilisé dans une spécification d'adresse pour que sed tente de matcher l'expression régulière dans la première ligne d'entrée également. En d'autres termes, 0,/REGEXP/ est similaire à 1,/REGEXP/, excepté que si ADDR2 matche la première ligne de l'entrée, 0,/REGEXP/ la considère à la fin de la plage.
ADDR1,+N Matche ADDR1 et les N lignes suivantes
ADDR1,~ N Matche ADDR1 et les lignes suivantes jusqu'à la prochaine ligne dont le numéro de ligne soit un multiple de N
! Ajouter ! à la fin d'une spécification d'adresse inverse le sense du match.

Syntaxe des expressions régulières

CHAR Un simple caractère ordinaire correspondant à lui-même
Correspond à une séquence de 0 ou plusieurs instances de correspondances pour l'expression réguière précédante, qui doit être un caractère ordinaire, un caractère spéciale, un regexp groupé, une une expression entre crochet.
\+ comme * mais matche un ou plusieurs
\? comme * mais matche exactement I séquences (I est un entier décimal entre 0 et 255)
\{I,J\} Matche entre I et J, inclusifs, séquences
\{I,\} Matche plus que ou égal à I séquences
\(REGEXP\) Groupe le REGEXP interne dans son ensemble
. Matche n'importe quel caractère, incluant newline
^ Matche la chaîne null au début de l'espace pattern
$ Idem à ^ mais réfère à la fin de l'espace pattern
[LIST], [^LIST] Matche tout caractère simple dans LIST. Par exemple, [aeiou] matche toutes les voyelles. ^ inverse le sense de la liste
REGEXP1\|REGEXP2 Matche soit REGEXP1 ou REGEXP2. Utilise les parenthèses pour utilise des expressions régulières alternative complexes.
REGEXP1REGEXP2 Matche la concaténation de REGEXP1 et REGEXP2.
\DIGIT Matche la n-ième sous-expression \(...\) dans l'expression régulière
\n Matche le caractère newline
\CHAR Matche CHAR où CHAR est '$', '*', '.', '[', '\', ou '^'.

Exemples

Matche abcdef
abcdef
matche 0 ou plusieurs a, suivi par un caractère b:
a*b
Matche b ou ab
a\?b
matche un ou plusieurs a, suivi par un ou plusiuers b
a\+b\+
Matchent tous les caractères dans une chaîne, incluant une chaîne vide
.* 
Matchent tous les caractères dans une chaîne, d'au moins un caractère
.\+
Matche un chaîne commençant avec 'main' suivi par une parenthèse ouvrante et fermante. n, ( et ) ne doivent pas être adjacents
^main.*(.*)
Matche une chaîne commençant avec #
^#
matche une chaîne se terminant avec un \
\\$
Matche une chaîne consisant d'un simple signe dollar
\$
Matche les lettres ASCII ou les chiffres
[a-zA-Z0-9]
(ici ‹TAB› est un simple caractère). Matche une chaîne d'un ou plusieurs caractères, aucun d'entre eux n'est un espace ou une tabulation. Généralement, celà signifie un mot
[^ ‹TAB›]\+
Matche une chaîne consistant de 2 sous-chaînes égales, séparées par un newline
^\(.*\)\n\1$
Matche 9 caractères suivis par un A
.\{9\}A$
Matche le début d'une chaîne qui contient 16 caractères, le dernier est un A
^.\{15\}A

commande usuelles

# Aucune adresse permise. Commence un commentaire, qui contient jusqu'au prochain newline.
q [EXIT-CODE] Quitte sed dans traiter plus de commandes ou entrée, et retourne le code donné
d Supprime l'espace pattern; démarrant immédiatement un nouveau cycle
p Affiche l'espace pattern sur stdout. généralement utilisé avec l'option -n
n Si auto-print est actif, affiche l'espace pattern, puis remplace l'espace pattern avec la ligne suivante.
{ COMMANDS } Un groupe de commandes peut être enfermé dans des accolades.

commande s

   La syntaxe de la commande s (s pour substitute) est 's/REGEXP/REPLACEMENT/FLAGS' Les caractères '/' peuvent être uniformément remplacés par un autre caractère. La commande s est probablement la plus importante de sed. sed tente de correspondre l'espace pattern avec REGEXP, et si le match réussit, remplace la portion de l'espace pattern qui matche avec REPLACEMENT.

   REPLACEMENT peut contenir \N (N étant un nombre de 1 à 9) références aux portion de matche entre \( et \) dans REGEXP. REPLACEMENT peut contenir '&' qui réfère au match comple. Les séquences suivantes peuvent être inculs:

        \L Active le remplacement en minuscule jusqu'à un \U ou \E
        \l Met le prochain caractère en minuscule
        \U Active le remplacement en majuscule jusqu'à un \L ou \E
        \u Met le prochain caractère en majuscule
        \E Stop la conversion démarrée par \L ou \U

Flags

g Applique le remplacement de tous les matches au REGEXP, pas simplement le premier
NUMBER Applique le remplacement seulement au NUMBER-ième matche
p Si la substitution est effective, affiche le nouvel espace pattern
w FILE-NAME Si la substitution est effective, écris le résultat dans le fichier nommé.
e Permet à un pipe d'entrée depuis une commande shell dans l'espace pattern. Si une substitution est effective, la commande trouvée dans l'espace pattern est exécutée et l'espace pattern est remplacée avec sa sortie.
I, i I match de manière insensible à la casse.
M, m M matche les expressions régulière en mode multi-ligne

Commandes moins usuelles

y/SOURCE-CHARS/DEST-CHARS/ Traduit tous caractères dans l'espace pattern qui matche un des SOURCE-CHARS avec le caractères correspondant DEST-CHARS
a\, TEXT Accèpte 2 adresses. Met en file les lignes de texte qui suivent cette commande (chacune sauf celles se terminant avec un '\', qui sont supprimés de la sortie) sur la sortie à la fin du cycle courant, ou quand la ligne suivante est lue.
i\, TEXT Affiche immédiatement les lignes de texte qui suivent cette commande (chacune sauf celles se terminant avec un \, qui sont supprimées de la sortie).
c\, TEXT Supprime les lignes matchant l'adresse ou la plage d'adresse, et sort les lignes de texte qui suivent cette commande à la place de la dernière ligne ( ou à la place de chaque ligne, si aucune adresse n'est spécifiée). Un nouveau cycle est démarré après cette commande vu que l'espace pattern sera supprimé.
= Affiche le numéro de ligne d'entrée avec un newline
l N Affiche l'espace pattern dans une forme non ambigüe: les caractères non-imprimables sont affiché dans une forme échappé style C. N définis la longueur de ligne. 0 ne coupe pas les lignes.
r FILENAME Accèpte 2 adresses. Met en file le contenu de FILENAME à lire et à insérer dans le flux de sortie à la fin du cycle courant, ou quand la prochaine ligne d'entrée est lue. Si FILENAME ne peut pas être lu, il est traité comme si c'était un fichier vide, sans erreur.
w FILENAME écrit l'espace pattern dans FILENAME.
D Si l'espace pattern ne contient pas de newline, démarre un nouveau cycle normal comme si la commande d avait été donnée. Sinon, supprime le texte dans l'espace pattern jusqu'au newline, et redémarre le cycle avec l'espace pattern résultant, sans lire un newline d'entrée
N Ajoute un newline à l'espace pattern, puis ajoute la ligne suivante de l'entrée dans l'espace pattern.
P Affiche la portio de l'espace pattern jusqu'au newline
h Remplace le contenu de l'espace hold avec le contenu de l'espace pattern
H Ajoute un newline au contenu de l'espace hold, puis y ajoute le contenu de l'espace pattern.
g Remplace le contenu de l'espace pattern avec le contenu de l'espace hold
G Ajoute un newline au contenu de l'espace pattern, puis y ajoute le contenu de l'espace hold.
x Échange le contenu des espace pattern et hold.

Commande avancées

   Dans la plupart des cas, il est préférrable d'utiliser des commandes comme awk ou perl au lieu de ces commandes

: LABEL Aucune adresse permise. Spécifie l'emplacement d'un LABEL pour les commandes de branchement.
b LABEL Branche inconditionneles à LABEL.
t LABEL Branche à LABEL seulement s'il a été substitué depuis que la dernière ligne d'entrée a été lue ou qu'un branchement conditionnel a été fait.

Commandes spécifiques à GNU sed

e [COMMAND] Permet de pipe une entrée depuis une commande shell dans l'espace pattern. Sans paramètres, cette commande exécute la commande trouvée dans l'espace pattern et remplace l'espace pattern avec la sortie; et supprime tout newline de fin. Avec un paramètre, cette commande interprète comme commande et envoie sa sortie sur le flux de sortie.
F Affiche le nom du fichier du fichier d'entrée
L N Remplis et joint les lignes dans l'espace pattern pour produire des lignes en sortie de (au plus) N caractères, comme fmt. Si N est omis, le défaut tel que spécifié sur la ligne de commande est utilisé.
Q [EXIT-CODE] n'accepte qu'une seule adresse. fonctionne comme 'q'
R FILENAME Met en file une ligne de FILENAME et l'insert dans le flux de sortie à la fin du cycle courant, ou quand la prochaine ligne est lue. Si FILENAME ne peut pas être lu, ou si la fin est atteind, aucune ligne n'est ajoutée.
T LABEL Brachement sur LABEL uniquement si la substitution n'a pas réussit.
v VERSION Ne fait rien, mais échoue si sed n'a pas les extensions GNU.
W FILENAME Écrit dans le fichier la portion de l'espace pattern jusqu'à un newline.
z Vide le contenu de l'espace pattern. Générallement identique 's/.*//', mais est plus efficate.

Extensions GNU pour les échappements dans les expressions régulières

\a alert
\f form feed
\n nouvelle ligne
\r retour charriot
\t tabulation horizontale
\v Tabulation verticale
\cX Matche CONTROL-X, ou X est un caractère.
\dXXX Caractère ASCII où XXX est la valeur décimale
\oXXX Caractère ASCII où XXX est la valeur octale
\xXXX Caractère ASCII où XXX est la valeur héxadécimale
\b caractère \
\w Matche tout caractère 'word' (lettre, chiffre ou _)
\W Matche tout caractère non word
\b Matche une fin de mot, qui matche si le caractère à gauche est un caractère word, et le caractère à droite est un caractère non-word
\B Matche tout sauf une fin de mot.
\` Matche seulement au début de l'espace pattern. Différent de ^ en mode multi-ligne
\' Matche seulement la fin de l'espace pattern. Différent de $ en mode multi-ligne
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/sepgsql_context

/etc/selinux/‹SELINUXTYPE›/contexts/sepgsql_context

Fichier de configuration et labeling SELinux pour les objects RDBMS

   Le format est object_type object_name context

object_type Est la représentation du type d'objet:

        db_database object_name spécifie le nom d'une base de données
        db_schema object_name spécifie le nom d'un objet schéma
        db_table object_name spécifie le nom d'une table
        db_column object_name spécifie le nom d'une colonne
        db_tuple object_name spécifie le nom d'une table qui contient les tuples à relabéliser
        db_procedure object_name spécifie le nom d'une procédure
        db_sequence object_name spécifie le nom d'une séquence
        db_blob object_name spécifie le nom d'un grand objet. Noter qu'un grand objet n'a pas de nm, il est identifié par sa valeur identifiant
        db_view object_name spécifie le nom d'une vue
        db_language object_name spécifie le nom d'un langage
        db_exception object_name spécifie le nom d'une exception
        db_datatype object_name spécifie le nom d'un type ou domaine

Exemples


db_database my_database system_u:object_r:sepgsql_db_t:s0
db_database *     system_u:object_r:sepgsql_db_t:s0
db_schema generator.php system_u:object_r:sepgsql_schema_t:s0
db_tuple row_low system_u:object_r:sepgsql_table_t:s0
db_tuple row_high system_u:object_r:sepgsql_table_t:s0:c1023
db_tuple *.*.* system_u:object_r:sepgsql_table_t:s0
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/files/file_contexts

/etc/selinux/‹SELINUXTYPE›/contexts/files/file_contexts, file_contexts.local, file_contexts.homedirs, file_contexts.subs, file_contexts.subs_dist

Fichier de configuration et labeling SELinux pour les backend de contexte de fichier

   Le backend de contextes de fichier mappe depuis les combinaisons pathname/mode en contextes de securité. C'est utilisé pour trouver le contexte approprié pour chaque fichier en relabélisant un système de fichier. Le format est pathname [file_type] context. Les fichiers de substitution (.subs, et .subs_dist) ont le format subs_pathname pathname

pathname Une entrée qui définis le chemin qui peut être sous la forme d'une expression régulière. Pour les fichiers de substitution, matche un ou plusieurs fichier de configuration de stratégie de contexte de fichier
file_type type de fichier: -b, -c, -d, -p, -d, -l, -s, --.
subs_pathname Le chemin qui est considéré comme équivalent avec pathname par le processus de recherche.

Exemple

Exemple de fichier file_contexts
/. /.. /.config /.hcwd /.local system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/tmp/.* ‹‹none››

Exemple de fichier file_contexts.subs
/myweb /var/www
/myspool /var/spool/mail
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/files/media

/etc/selinux/‹SELINUXTYPE›/contexts/files/media

Fichier de configuration pour le backend de contexte de média

   Le backend de contextes de média mappe les noms de périphériques tel que 'cdrom' ou 'floppy' en contextes de sécurité. Il est utilisé pour trouver le contexte approprié puor établir les contextes au montage de ces périphériques. Le format de ce fichier est device_name context

device_name l'identifiant de média, par ex. cdrom, floppy, disk et usb

Exemple


cdrom system_u:object_r:removable_device_t
floppy system_u:object_r:removable_device_t
disk system_u:object_r:fixed_disk_device_t
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/x_context

/etc/selinux/‹SELINUXTYPE›/contexts/x_context

Fichier de configuration et labeling SELinux pour les objects X Window System

   Le backend de contexte X mappe les noms d'objets X en contextes de sécurité. Il est utilisé pour trouver le contexte approprié pour les objets X Window System dont la signification et/ou l'utilisation sont déterminés par nom. Le format est object_type object_name context

object_type Est la représentation du type d'objet:

        property object_name spécifie le nom d'une propriété de fenêtre, tel que "WM_NAME"
        selection object_name spécifie le nom d'une sélection, tel que "PRIMARY"
        extension object_name spécifie le nom d'une extension de protocole, tel que "RENDER"
        event object_name spécifie le nom d'un type d'évènement, tel que "X11:ButtonPress"
        client object_name est ignoré, cependant il devrait être mis à soit '*', ou une entrée spécifique tel que "remote".
        poly_property idem à property, mais vérifie que la propriété est marguée comme polyinstanciée.
        poly_selection idem à selection, mais vérifie que la sélection est marquée comme polyinstanciiée.

Exemple


selection PRIMARY system_u:object_r:clipboard_xselection_t:s0
selection *     system_u:object_r:xselection_t:s0
client *     system_u:object_r:remote_t:s0
^
16 mai 2017

htmlpdflatexmanmd




SELinux

SELinux

SElinux est un mécanisme de contrôle d'accès obligatoire (MAC) pour les distributions GNU/Linux. C'est un développement dans la continuité de FLASK

Répertoires

/sys/fs/selinux Le système de fichier SELinux qui interface avec le service de sécurité du kernel.
/etc/selinux La configuration pour selinux
/var/lib/selinux/‹SELINUXTYPE›/module Modules de stratégie SELINUX

Utilité

- Si SELinux est activé, la stratégie définie quels accès aux ressource et les opérations sur ces ressources (ex: read, write) sont autorisés. C'est un mécanisme MAC
- Le concept de stratégie, l'implémentation et les tests avec une stratégie de sécurité définie ou les pre-requis sont importants.
- SELinux pour confiner une application avec son propre domaine et lui permettre d'avoir les privilèges minimum pour faire son job. Si l'application nécessite un accès aux réseaux ou d'autres application (ou leur données), alors cet accès est donné.
- Si une application 'fait quelque chose" qui n'est pas permis par stratégie, SELinux peut stopper ces actions
- Si une application fait quelque chose qui est permis par stratégie, SELinux peut contenir tout dégât qui peut être fait intentionnellement ou non. Par exemple, si une application est autorisée à supprimer tout ses fichiers de données ou entrées de base de données et qu'un bug, virus ou utilisateur gagne ces privilèges, il peut faire la même chose, cependant, si cette stratégie confine l'application et les données, toutes les autres données ne seront pas touchées.
- Les sessions login utilisateur peuvent être confinés dans leur propre domaine. Cela permet aux clients qu'ils lancent d'avoir seulement les privilèges nécessaires. Cela confine/limite également tout dommage ou fuite de données.
- Certaines applications sont difficiles à confiner parce qu'elles sont généralement conçues pour avoir un accès total à toutes les ressources. SELinux peut généralement gérer ce problème en fournissant des services sandboxing.
- SELinux ne stoppe pas les fuites mémoire, ou débordement de tampon, cependant il peut contenir les dommages qui peuvent être faits.
- SELinux ne stop pas tous les virus/malware dans le système, cependant il devrait limiter les dégats ou fuites qu'ils causent.
- SELinux ne stop pas les vulnérabilités, cependant, il peut limiter leurs effets.
- Il est facile d'ajouter de nouvelles règles à une stratégie SELinux en utilisant des outils tels que audit2allow(1) si un utilisateur a les permissions nécessaires.
- SELinux ne peut pas stopper ce qui est autorisé par stratégie, donc un bon design est important.

Composants du cœur SELinux

- Un sujet qui doit être présent pour déclencher une action à prendre par un objet.
- Un gestionnaire d'objet qui connaît les actions requises pour la ressource particulière et peut forcer ces actions
- Un serveur de sécurité qui prend les décisions au regard des droits du sujet pour effectuer l'action requise sur l'objet, basé sur les règles de stratégie de sécurité
- Une Stratégie de sécurité qui décris les règles utilisant le language de stratégie SELinux
- Un cache de vecteur d'accès qui améliore les performances système.

Composants haut niveau du cœur SELinux
Architecture SELinux haut-niveau
   Le schéma ci-dessus montre un diagramme plus complexe du kernel et userspace avec les services support qui sont utilisés pour gérer l'environnement SELinux. En partant du bas:

- Dans l'implémentation actuelle de SELinux le serveur de sécurité est embarqué dans le kernel et les stratégies sont chargées depuis le userspace via une série de fonctions contenues dans la librairie libselinux. Le gestionnaire d'objet (OM) et le cache de vecteur d'accès (AVC) peuvent résider dans:

        kernelspace Cette gestion d'objet est pour les services kernel tel que les fichiers, répertoires, socket, IPC, etc. et sont fournis par des hooks dans le sous-système SELinuyx via le framework LSM. Le service AVC du kernel est utilisé pour maintenir en cache les réponses du serveur de sécurité.
        userspace Cette gestion d'objet est fournie avec l'application ou service qui nécessite un support pour MAC et sont des applications "SELinux-aware". Par exemple, X-Windows, D-bus, PostgreSQL, nscd, et passwd. Généralement, ces OM utilisent les services AVC construits dans la librairie SELinux, cependant il peuvent fournir leur propre AVC si besoin.

- La stratégie de sécurité SELinux et ses fichiers de configuration sont contenus dans /etc/selinux. Ce répertoire contient le fichier de configuration principal qui a le nom du la stratégie à charger et le mode d'application de la stratégie au chargement.
SELinux supporte une stratégie modulaire, ce qui signifie qu'une stratégie n'a pas à être une grande stratégie, mais peut être construite avec des modules. Une stratégie modulaire consiste d'une stratégie de base qui contient les informations obligatoires, et 0 ou plusieurs modules de stratégie où chacune supporte une application particulière ou service. Ces modules sont compilés, liés et maintenus dans un magasin de stratégie. -
Pour être capable de construire la stratégie, une source de stratégie est requise, qui peut être fournie de 3 manières:

        - Un code source écrit en langage de stratégie SELinux.
        - En utilisant la statégie référence, qui a des macros haut-niveau pour définir les règles.
        - En utilisant CIL (Common Intermediate Language).
       

- Pour pouvoir compiler les sources de stratégie puis les charger dans le serveur de sécurité, un certains nombre d'outils sont requis
- Pour permettre à un administrateur de gérer les stratégies, l'environnement SELinux et les systèmes de fichier labélisés, outils et commandes gnu/linux modifiés sont utilisées.
- Pour s'assurer que les évènements de sécurité sont loggés, gnu/linux a un service d'audit qui capture les violations de stratégie.
- SELinux supporte les services réseaux.

Mandatory Access Control (MAC)

   MAC est un type de contrôle d'accès dans lequel le système d'exploitation est utilisé pour contraindre un utilisateur ou processus (le sujet) de l'accès ou un opération sur un objet (tel qu'un fichier, mémoire, etc.). Chaque sujet et objet a un jeu d'attributs de sécurité qui peuvent être interrogés par l'os pour vérifier si l'opération demandée peut être effectuée ou non. Pour SELinux:

- Les sujets sont des processus
- Les objets sont des ressources système tels que des fichiers, sockets, etc.
- Les attributs de sécurité sont des contextes de sécurité
- Le serveur de sécurité dans le kernel autorise l'accès ou non en utilisant la stratégie de sécurité qui décris les règles définies.

   Noter que le sujet ne peut pas décider de bypasser les règles de stratégie définie par la stratégie MAC avec SELinux. En contraste avec DAC de Linux, qui gouverne également la capacité des sujets à accéder aux objets, cependant il permet aux utilisateurs de décider de la stratégie. Les étapes dans les décisions DAC et MAC:

Traitement d
   SELinux supporte 2 formet de MAC:

Type Enforcement Où les traitements lancés dans les domaines et les actions sur les objets sont contrôlés par la stratégie. C'est l'implémentation utilisée pour MAC dans SELinux avec RBAC
Multi-Level Security C'est une implémentation basée sur le modèle BLP, et utilisée par les organisations où différents niveaux d'accès sont requis pour que les informations restreintes soient séparées des informations classifiée pour maintenir la confidentialité.

   Les services MLS/MCS sont utilisés pour maintenir une séparation d'applications, par exemple:

- Les machines virtuelles utilisent les catégories MCS pour permettre à chaque VM de se lancer dans son propre domaine.
- Les périphériques Android utilisent les catégories MCS pour qu'une application qui tourne à la demande d'un utilisateur ne puisse pas lire ou écrire des fichiers créé par la même application à la demande d'un autre utilisateur.

Utilisateurs SELinux

   Les utilisateur dans gnu/linux sont généralement associés avec des utilisateurs humain (comme Alice et Bob) ou des fonctions d'opérateur/système (comme admin), bien que celà puisse être implémenté dans SELinux, les noms d'utilisateur SELinux sont généralement des groupes ou des classes d'utilisateur. Par exemple, tous les utilisateurs système standard peuvent être assignés à un nom d'utilisateur user_u et l'équipe d'administration sous staff_u.

   Il y a un utilisateur SELinux spécial définis qui ne doit jamais être associé à un utilisateur gnu/linux vu qu'il est une identité spéciale pour les processus et objets système, cet utilisateur est system_u.

   Le nom d'utilisateur SELinux est le premier composant d'un contexte de sécurité et par convention les noms d'utilisateur SELinux se terminent en '_u', cependant ce n'est pas obligatoire.

   Il est possible d'ajouter des contraintes et limites dans les utilisateurs SELinux.

RBAC

   Pour contrôler l'accès aux domaines, TE SELinux utilise RBAC. Cette fonctionnalité permet aux utilisateurs de SELinux d'être associés à un ou plusieurs rôles, où chaque rôle est ainsi associé à un ou plusieurs types de domaine.

   Le nom du rôle SELinux est le second composant d'un contexte de sécurité, et par convention les rôle SELinux se terminent par '_r'.

   Il est possible d'ajouter des contraintes et limites sur les rôles.

RBAC

Type Enforcement

   SElinux utilise un style spécifique de technologie TE pour forcer le contrôle d'accès obligatoire. Pour SELinux cela signifie que tous les sujets et objets ont un identifiant de type associé avec eux qui peut être utilisé pour forcer les règles établies par stratégie.

   L'identifiant de type SELinux est une simple chaîne de longueur variable qui est définie dans la stratégie et associée à un contexte de sécurité. Il est également utilisé dans la majorité des règles et déclaration du langage SELinux utilisés pour construire un stratégie qui va, une fois chargée dans le serveur de sécurité, forcer la stratégie via les gestionnaires d'objet.

   Parce que l'identifiant de type (ou simplement type) est associé à tous les sujets et objets, il peut parfois être difficile de distinguer le type actuellement associé. Il revient de comprendre comment ils sont alloués dans la stratégie elle-même et comment ils sont utilisé par les services SELinux.

   Basiquement si l'identifiant de type est utilisé pour référencer un sujet il réfère à un processus Linux ou une collection de processus (un domaine ou un type de domaine). Si l'identifiant de type est utilisé pour référencer un objet alors il spécifie son type d'objet (ex: type de fichier).

   Bien que SELinux réfère à un sujet comme étant un processus actif qui est associé à un type de domaine, le périmètre d'un domaine TE SELinux peut varier largement. Par exemple dans la stratégie simple construite dans le répertoire basic-selinux-policy des sources, tous les processus dans le système tournent dans le domaine unconfined_t, et donc tout processus est de type unconfined_t (qui signifie qu'il peut faire ce qu'il veut dans les limites de la stratégie DAC Linux vu que tous les accès sont autorisés par SELinux).

   C'est seulement quand des déclarations de stratégie additionnelles sont ajoutées à cette stratégie simple que les zone commencent à être confinées. Par exemple, un passerelle externe est lancée dans son propre domaine isolé (ext_gateway_t) qui ne peut pas interférer avec un processus unconfined_t (excepté pour lancer ou transiter le processus gateway dans son propre domaine). Ce scénario est similaire à la stratégie targeted livrée en standard dans Hed Hat Fedora où la majorité des processus en userspace tournent dans le domaine unconfined_t.

   Le type SELinux est le troisième composant d'un contexte de sécurité et par convention les types SELinux se terminent par '_t'.

Contraintes

Il est possible d'ajouter des contraintes sur les utilisateurs, rôles, types, et plages MLS, par exemple dans un environnement TE, la manière dont les sujets sont autorisés à accéder à un objet se fait via une règle allow, par exemple:
allow unconfined_t ext_gateway_t : process transition;

Cela status qu'un processus tournant dans le domaine unconfined_t a la permission de transiter un processus au domaine ext_gateway_t. Cependant on pourrait souhaiter contraindre cela et statuer que cela se produit seulement si le rôle du domaine source est le même que le rôle du domaine cible:
constrain process transition ( r1 == r2 );

   Qui status qu'une transition de processus peut seulement se produire si le rôle source est le même que le rôle cible, cependant un contrainte est une condition qui doit être satisfaite pour une ou plusieurs permission à autoriser ( une contrainte impose des restrictions additionnelles aux règles TE). Noter que la contrainte est basée sur une classe d'objet (un processus dans ce cas), et une ou plusieurs de ses permissions.

Limites

   Il est possible d'ajouter des limites aux utilisateurs, rôles, et types, cependant actuellement les types sont forcés par le kernel en utilisant la règle typebounds.

Contexte de sécurité

   SELinux exige un contexte de sécurité à associer avec tout processus ( ou sujet) et objet qui sont utilisé par le serveur de sécurité pour décider si l'accès est autorisé ou non comme définis par la stratégie.

   Le contexte de sécurité est également connu comme un label de sécurité, ou simplement label qui peut créer la confusion vu qu'il y a de nombreux types de labels dépendants du contexte.

Dans SELinux, un contexte de sécurité est représenté comme un chaîne de longueur variable qui définis l'utilisateur SELinux, son rôle, un identifiant de type et une plage de sécurité MCS/MLS optionnel:
user:role:type[:range]


user L'identité de l'utilisateur SELinux. Peut être associé à un ou plusieurs rôles que l'utilisateur SELinux est autorisé à utiliser
role Le rôle SELinux. Cela peut être associé à un ou plusieurs types que l'utilisateur SELinux est autorisé à accéder
type Quand un type est associé avec un processus, il définis quels processus ( ou domaines ) l'utilisateur SELinux ( le sujet ) peut accéder.
range Ce champ peut également être appelé level et est seulement présent si la stratégie supporte MCS ou MLS. L'entrée peut consister de :

        - Un niveau de sécurité simple qui contient le niveau de sensibilité et 0 ou plusieurs catégories (ex: s0, S1:c0, s7:c10.c15
        - Une plage qui consiste de 2 niveaux de sécurité (un faible et un élevé) séparés par un '-' (ex: s0 - s15:c0.c1023)

   Cependant, noter que:

1 les décisions d'accès au regard du sujet utilisent tous les composant du contexte de sécurité.
2 Les décisions d'accès à un objet utilise les composant comme suit:

        a) L'utilisateur est soit un jeu d'utilisateur spécial appelé system_u ou définis à un utilisateur SELinux du processus créant. Il est possible d'ajouter des contraintes sur les utilisateurs dans la stratégie basée sur leur classe d'objet (un exemple de cela est la stratégie de référence UBAC)
        b) Le rôle est générallement définis à un rôle SELinux interne spécial object_r, bien que la stratégie supporte les transitions de rôle dans toute classe d'objet. Il est ainsi possible d'ajouter des contraintes dans les rôles dans la stratégie basée sur leur classe d'objet.

L'exemple ci-dessous montre les contextes de sécurité pour les processus, répertoires et fichier ( noter que la stratégie ne supporte pas MCS ou MLS )
LABEL                PID    TTY    CMD
unconfined_u:unconfined_r:unconfined_t 2539 pts/0 bash
unconfined_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server
unconfined_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server
unconfined_u:unconfined_r:unconfined_t 3146 pts/0 ps

Exemple de contexte de sécurité d'objet:
system_u:object_r:in_queue_t /usr/message_queue/in_queue
system_u:object_r:out_queue_t /usr/message_queue/out_queue

Il y a les contextes de sécurité d'objet de file de message pris depuis la commande ls -Z:
/usr/message_queue/in_queue:
unconfined_u:object_r:in_file_t Message-1
unconfined_u:object_r:in_file_t Message-2
/usr/message_queue/out_queue:
unconfined_u:object_r:out_file_t Message-10
unconfined_u:object_r:out_file_t Message-11

Sujets

   Un sujet est une entité active généralement sous la forme d'une personne, processus, ou périphérique qui cause l'information de transiter dans les objets, ou changent l'état système.

   Dans SELinux un sujet est un processus actif et a un contexte de sécurité qui lui est associé, cependant un processus peut également être réferré à un objet en fonction du contexte dans lequel il est pris, par exemple:

1. Un processus en cours de fonctionnement est un sujet parce il créé un flux d'informations ou peut changer l'état système
2. Le processus peut également être réferré à un objet parce que chaque processus a une classe objet associé appelé process. Cet objet process définis quelles permissions la stratégie est autorisée à donner ou refuser dans le processus actif.

   Dans SELinux les sujets peuvent être:

trusted Généralement ce sont des commandes, applications, etc. qui ont été écrits ou modifiés pour supporter SELinux. Cependant, il peut également couvrir toute application qui est trusté considéré comme faisant partie du système. Bien que - en fonction de votre niveau de paranoïa - la meilleur stratégie est de ne rien truster tant que la conformité avec la stratégie n'a pas été vérifiée. Généralement ces application trustées se lancent soit dans leur propre domaine (ex le service audit peut être sous auditd_t) ou groupés ensemble (ex semanage et semodule sont groupés sous semanage_t).
untrusted Tout le reste

Objets

   Dans SELinux un objet est une ressource telle que des fichiers, sockets, pipes, ou interfaces réseaux qui sont accédés via les processus (les sujets). Ces objets sont classés en accord avec la ressource qu'ils fournissent avec les permissions d'accès significatif pour leur but (ex: lire, reçevoir et écrire), et assigné à un contexte de sécurité.

Classes objet et permissions

   Chaque objet consiste d'un identifiant de classe qui définis son but (ex: file, socket) avec un jeu de permissions qui décrivent quels services l'objet peut gérer. Quand un objet est instantié, un nom et un contexte de sécurité lui sont alloués.

Classe objet =
   L'objectif de la stratégie est de permettre à l'utilisateur de l'objet (le sujet) d'accéder aux permissions minimum nécessaires pour accomplir la tâche.

   Ces classes d'objet et leur permissions associées sont construits dans le kernel GNU/Linux et les gestionnaires d'objet en userspace et sont donc généralement mis à jours par ceux qui écrivent les stratégies.

   Ces classes d'objet consistent de classes objet kernel (pour gérer les fichiers, sockets, etc) plus les classes d'objet en userspace pour les gestionnaires d'objet userspace (pour les services tels que X-Window ou dbus). Le nombre de classes d'objet et leur permissions peut varier en fonction des fonctionnalité configurées dans GNU/Linux.

Autoriser un processus à accéder aux ressources

   C'est un simple exemple qui tente d'expliquer 2 points:

1. Comment un processus reçois la permission d'utiliser une ressource
2. En utilisant la classse objet 'process', montrer qu'un processus peut être décris comme un processus ou un objet.

   Une stratégie contient de nombreuses règles et déclaration, la majorité sont les règle allow qui autorise les permissions d'accès à des processus sur des ressources.

La règle allow suivante illustre une processus qui peut être également un objet vu qu'il permet aux processus dans le domaine unconfined_t, la permission transition de l'application gateway externe dans la domaine ext_gateway_t une fois qu'il a été exécuté:
allow Rule | source_domain | target_type : classs | permission
allow unconfined_ ext_gateway_t : process transition;

allow Défini une règle allow
unconfined_t Le domaine source (ou sujet) dans ce cas le shell qui souhaite exécuter l'application gateway
ext_gateway_t L'objet cible, l'instance objet du processus gateway
process La classe objet de la cible
transition La permission est donné au domaine source dans l'objet cible. Dans ce cas, le domaine a la permission transition dans l'objet process ext_gateway_t

labeliser les objets

   Dans un système GNU/Linux, labéliser les objets est géré par le système et généralement caché aux utilisateurs. Vu que les processus et les objets sont créés et détruits, soit:

1. Ils héritent leur labels du processus ou objet parent
2. Le type de stratégie, rôle et plage de transition permettent un label différent.
3. Les applications gérant SELinux peuvent forcer un nouveau label (avec approbation des stratégies) en utilisant les fonctions de l'API libselinux
4. Un gestionnaire d'objet (OM) peut forcer un label par défaut qui peut soit être construit dans l'OM ou obtenu via un fichier de configuration
5. Utiliser un identifiant de sécurité initial (ou initial SID). Il sont définis dans toute stratégie de base et monolitiques et sont utilisé pour définis soit un contexte initial durant le processus de boot, ou si un objet nécessite un défaut.

   Le langage de stratégie SELinux supporte les déclaration de labélisation pour les services fichier et réseau.

   La labélisation des systèmes de fichier qui implémentent les attributs étendus sont supportés par SELinux en utilisant:

1. La déclaration fs_use_xattr dans la stratégie pour identifier quels système de fichier utilisent les attributs étendus. Cette déclaration est utilisée pour informer le serveur de sécurité de la manière de labéliser le système de fichier.
2. Un fichier 'file contexts' qui définis quels contexts initiaux devraient être pour chaque fichier et répertoires dans le système de fichier.
3. Une méthode pou initialiser le système de fichier avec des attributs étendus. fixfiles et setfiles sont utilisés pour celà. Il y a également des commandes comme chcon, restorecon, et restorecond.

   Les attributs étendus contenant le contexte SELinux d'un fichier peut être vu par les commande ls -Z et getfattr.

Copier et déplacer des fichiers

   En assumant que les permissions ont été données correctement par la stratégie, les effets dans le contexte de sécurité d'un fichier quand il est copié ou déplacé sont:

Copie d'un fichier - prend le label du nouveau répertoire
Déplacement d'un fichier - Conserve le label du fichier

   Cependant, si le service restorecond fonctionne et que le fichier restorecond.conf est configuré correctement, d'autres contextes de sécurité peuvent être associés au fichier dans ces cas. Noter qu'il y a également la commande install qui supporte -Z pour spécifier le contexte.

Labéliser des sujets

   Dans un système GNU/Linux, les processus héritent du contexte de sécurité du processus parent. Si le nouveau processus lancé a la permission de changer son contexte, une transition de type est autorisé. Le langage de stratégie supporte plusieurs déclaration pour assigner les composant aux contextes de sécurité tel que des déclarations user, role, et type, et gère leur scope role_allow, et constrain, et gère leur transition type_transition, role_transition et range_transition.

Réutilisation d'objet

   GNU/Linux créé des instances des objets et gère les informations qu'ils contiennent (read, write, modify, etc.) sous le contrôle des processus, et à certaines étapes ces objets peuvent être supprimés ou relâchés permettant à la ressource d'être de nouveau disponible.

   GNU/Linux gère la réutilisation d'objet en s'assurant que quand une ressource est ré-allouée elle est correcte. Cela signifie que quand un processus relâche une instance d'objet (par exemple relâcher de la mémoire allouée dans le pool, supprimer une entrée répertoire ou fichier), Il peut y avoir des informations restantes. Si c'est un problème, le processus lui-même devrait effacer ou détruire les informations avant de relâcher l'objet.

Calculer les contextes de sécurité

   SELinux utilise des déclarations de langage de stratégie et les fonctions de libselinux pour calculer un contexte de sécurité via le serveur de sécurité.

   Quand les contextes de sécurité sont calculés, le kernel, outils en userspace et versions de stratégie peuvent influencer la sortie. À cause des patches qui ont été appliqués pendant des années qui donnent une grande flexibilité dans le calcul des contextes. Le contexte de sécurité est calculé pour un objet en utilisant les composants suivants: un contexte source, un contexte cible et une classe objet.

Calcule de contexte de sécurité pour les objets Kernel

   La tâche initiale commence avec le contexte de sécurité kernel, mais le processus 'init' va typiquement faire une transition dans son propre contexte unique (ex: init_t), quand le binaire init est exécuté après que la stratégie ait été chargée. Certains programmes init se ré-exécutent eux-même après avoir chargé la stratégie, alors que dans d'autres cas le chargement de la stratégie initiale est effectuée par le script initrd/initramfs avant de monter le vrai root et exécuter le vrai init.

   Les processus héritent de leur contexte de sécurité comme suit:

1. Lors d'un fork, un processus hérite du contexte de sécurité de son créateur/parent
2. Lors de l'exécution, un processus peut transiter vers un autre contexte de sécurité basé sur les déclarations de stratégie: type_transition, range_transition, role_transition, default_user, default_role, default_range et default_type ou si un processus compatible SELinux appel setexeccon(3) si autorisé par la stratégie avant d'invoquer exec.
3. À tout moment, un processus compatible SELinux peut invoquer setcon(3) pour basculer son contexte de sécurité (si permis) bien que cette pratique soit généralement découragée.

   Le comportement par défaut pour le label de fichier (actuellement les inodes qui consistent des classes suivantes:

1. Le composant utilisateur est hérité du processus créateur
2. Le composant rôle est généralement par défaut object_r
3. Le composant type est par défaut au type du répertoire parent si aucune règle type_transition n'est spécifiée dans la stratégie
4. Le composant range/level est par défaut au niveau bas/courant du processus créateur si aucune règle range_transition n'est spécifié dans la stratégie

   Les applications compatibles SELinux peuvent changer ce comportement par défaut en appelant setfscreatecon(3) avant de créer le fichier, si permis par la stratégie.

   Pour les fichiers existants le label est déterminé depuis la valeur xattr associée avec le fichier. S'il n'y a pas de valeur xattr définie dans le fichier, le fichier est traité comme s'il était labélisé avec le contexte de sécurité par défaut pour le système de fichier. Par défaut, c'est le SID "file" initial, qui est mappé à un contexte par la stratégie. Ce défaut peut être écrasé via l'option de montage defcontext=.

Descripteurs de fichier

   Hérite du label de son créateur/parent.

Systèmes de fichier

   Les systèmes de fichier sont labélisé en utilisant la déclaration de langage de stratégie kernel fs_use quand ils sont monté, et sont basés sur le nom du type de système de fichier (ex: ext4) et leur comportement (ex: xattr). Par exemple si la stratégie spécifie:

  fs_use_task pipefs system_u:object_r:fs_t:s0

  lorsque le système de fichier pipefs est monté, le hook de sécurité LSM SELinux selinux_set_mnt appelle security_fs_use qui va:

a) Rechercher le nom du système de fichier dans la stratégie (pipefs)
b) Si présent, obtenir sont comportement (fs_use_task)
c) Puis obtenir le contexte de sécurité alloué (system_u:object_r:fs_t:s0)

   si le comportement est définis par fs_use_task, alors le système de fichier sera labélié comme suit:

   Notes:

1. Les systèmes de fichier qui supportent les attributs étendus xattr peuvent être identifiés via la commande mount, le mot clé seclabel est présent
2. Il y a des points de montages pour allouer différents types de contexte: context=, fscontext=, defcontext= et rootcontext=

nfsv4

   Si le label NFS est implémenté via le support xattr, la création des inodes sont créés comme décris ci-dessus

sockets INET

   Si un socket est créé par l'appel socket(3), il est labélisé comme suit:

1. Le composant utilisateur hérite du processus créateur
2. Le composant rôle hérite du processus créateur
3. Le composant type hérite du processus créateur si aucune règle type_transition n'est spécifié dans la stratégie
4. Le composant range/level hérite du processus créateur si aucune règle range_transition n'est spécifié dans la stratégie

IPC

   Hérite le label de son processus d'envoie. Cependant si l'envois d'un message est non labélisé, calcule un nouveau label basé sur le processus courant et met le message en queue comme suit:

1. Le composant utilisateur hérite du processus émetteur
2. Le composant rôle hérite du processus émetteur
3. Le composant type hérite du processus émetteur si aucune règle type_transition n'est spécifiée dans la stratégie
4. Le composant range/level hérite du processus émetteur si aucune règle range_transition n'est spécifiée dans la stratégie

Sémaphores

   Hérite du label de son créateur/parent

Mémoire partagée

   Hérite du label de son créateur/parent

Clés

   Hérite du label de son créateur/parent

Transition d'objet et de domaine

   La déclaration type_transition est utilisée pour:

1. La transition d'un processus d'un domaine à un autre (une transition de domaine)
2. La transition d'un objet d'un type à un autre (une transition d'objet)

Transition de domaine

   Une transition de domaine se produit lorsqu'un processus dans un domaine démarre un nouveau processus dans un autre domaine sous un contexte de sécurité différent. Il y a 2 manière de définir une transition de domaine:

1. En utilisant une déclaration type_transition, où l'appel système exec va exécuter automatiquement la transition de domaine pour les programmes non compatible SELinux. C'est la méthode la plus commune:
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

2. Les applications compatible SELinux peuvent spécifier le domaine du nouveau processus en utilisant libselinux. Pour cela, l'application doit avoir la permission setexec:
allow crond_t self : process setexec;

   Cependant, avant toute transition de domaine la stratégi doit spécifier que:

1. Le domaine source a la permission de transiter dans le domaine cible
2. Le binaire de l'application doit être exécutable dans le domaine source
3. Le binaire de l'application doit avoir un point d'entrée dans le domaine cible

La déclaration type_transition suivante est un exemple pour expliquer le processus de transition:
type_transition | source_domain | target_type | class | target_domain;
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

   Cette déclaration type_transition status que lorsqu'un processus dans le domain unconfined_t exécute un fichier labélisé secure_services_exec_t, le processus doivent être changé en ext_gateway_t si permis par la stratégie.

   Cependant, comme statué plus haut, pour être capable de transiter dans le domaine ext_gateway_t, les permissions minimum suivantes doivent être donnés dans la stratégie en utilisant les règles alow, où:

1. Le domaine nécessite la permission de transiter dans le domaine ext_gateway_t:
allow unconfined_t : process transition;
2. Le fichier exécutable doit être exécutable dans le domaine unconfined_t, et donc nécessite également que le fichier soit lisible: allow unconfined_t secure_services_exec_t : file { execute read getattr };
3. Le fichier exécutable doit avoir un point d'entrée dans le domaine ext_gateway_t:
allow ext_gateway_t secure_services_exec_t : file entrypoint;

   Comme affiché ci-dessous où unconfined_t fork un processus enfant, le nouveau programme transite dans ext_gateway_t. Noter qu'à cause de la déclaration type_transition utilisée, la transition est automatiquement géré par le kernel.

Transition de domaine

Règles de type forcé

En construisant les modules ext_gateway.conf et int_gateway.conf l'intention était d'avoir ces transitions et leur domaines respectifs via les déclarations type_transition. La déclaration ext_gateway_t serait:
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

et la déclaration int_gateway_t serait:
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;

Cependant, en liant ces 2 modules dans la stratégie, l'erreur suivante se produit:
semodule -v -s modular-test -i int_gateway.pp -i ext_gateway.pp
Attempting to install module 'int_gateway.pp':
Ok: return value of 0.
Attempting to install module 'ext_gateway.pp':
Ok: return value of 0.
Committing changes:
libsepol.expand_terule_helper: conflicting TE rule for (unconfined_t,
secure_services_exec_t:process): old was ext_gateway_t, new is int_gateway_t
libsepol.expand_module: Error during expand
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!

Celà se produit parce que les règles de type forcé ne permettent qu'un seul type par défaut pour une source et cible donnée. Dans la cas ci-dessus il y a 2 déclaration type_transition avec la même source et cible, mais différents domaines par défaut. Le module ext_gateway.conf a les déclarations suivantes:
allow unconfined_t ext_gateway_t : process { transition };
allow unconfined_t secure_services_exec_t : file { read execute getattr };
allow ext_gateway_t secure_services_exec_t : file { entrypoint };
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;

et le module int_gateway_t a les déclarations suivantes:
allow unconfined_t int_gateway_t : process { transition };
allow unconfined_t secure_services_exec_t : file { read execute getattr };
allow int_gateway_t secure_services_exec_t : file { entrypoint };
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;

   Alors que les règles allow sont valides pour permettre les transitions, les 2 déclarations type_transition ont des types par défaut différents (ou domaines cible), qui cassent la règle de type forcé.

   Pour résoudre cela, il a été décidé:

1. Conserver la règle type_transition pour le type par défaut de ext_gateway_t, et autoriser le processus serveur à être exécuté depuis unconfined_t, en lançant simplement la commande depuis le prompts comme suit: secure_server 99999
2. Utiliser la commande runcon pour s'assurer que la gateway interne se lance dans le domaine corecte en lançant runcon depuis le prompte comme suit: runcon -t int_gateway_t -r message_filter_r secure_server 1111

   La commande runcom utilise libselinux pour vérifier le contexte courant et définir le nouveau contexte.

   d'autres manières de résoudre ce problème sont:

1. Utiliser la commande runcon pour lancer les 2 gateway pour transiter dans leur domaine respectifs. Les déclarations type_transition sont donc non requis.
2. Utiliser des noms différents pour les fichiers exécutables du serveur et s'assurer qu'ils ont un type différent
3. Implémenter la stratégie sur le modèle de la section templace macro.

Transition d'objet

Une transition d'objet se produit lorsqu'un nouvel objet nécessite un label différent de celui de son parent. Par exemple un fichier créé qui nécessite un label différent de son répertoire parent. la déclaration type_transition permet de le faire:
type_transition ext_gateway_t in_queue_t:file in_file_t;

Les détails suivants d'une transition d'objet utilisée dans le module ext_gateway.conf où par défaut, les fichiers sont labélisés in_queue_t quand ils sont créés par l'application gateway vu que ce label est attaché au répertoire parent:
ls -Za /usr/message_queue/in_queue
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .
drwxr-xr-x root root system_u:object_r:unconfined_t ..

Cependant il est requis que les fichiers dans ce répertoire soient labélisés in_file_t. Pour celà les fichiers créé doivent être relabélisés dans in_file_t en utilisant un type_transition:
type_transition | source_domain | target_domain : object | default_type;
type_transition ext_gateway_t in_queue_t : file in_file_t;

   Cette déclaration type_transition status que lorsqu'un processus tournant dans le domaine ext_gateway_t (le domaine source) souhaite créer un objet fichier dans le répertoire qui est labélisé in_queue_t, le fichier devrait être relabélisé in_file_t si permis par la stratégie.

   Cependant, comme décris plus haut, pour être capable de créer le fichier, les permissions minimum suivantes doivent être données dans la stratégie en utilisant les règle allow, où:

1. le domaine source a la permission d'ajouter des entrées fichier dans le répertoire:
allow ext_gateway_t in_queue_t : dir { write search add_name );
2. Le domaine source a la permission de créer des entrées fichiers:
allow ext_gateway_t in_file_t : file ( write create getattr );
3. La stratégie peut ainsi s'assurer que les fichiers créé dans in_queue sont relabélisés:
type_transition ext_gateway_t in_queue_t : file in_file_t;
Un exemple de sortie d'un répertoire:
ls -Za /usr/message_queue/in_queue
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .
drwxr-xr-x root root system_u:object_r:unconfined_t ..
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-1
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-2

MLS et MCS

   Comme définis dans la section MAC et TE, SELinux supporte également MLS et MCS en ajoutant une entrée optionnelle level ou range dans le contexte de sécurité. Cette section donne une brève introduction à MLS et MCS.

   Le schéma ci-dessous montre un diagramme simple où les niveaux de sécurité représentent la classification des fichiers dans un serveur de fichier. Les niveaux de sécurité sont strictement hiérarchiques et conformes au modèle Bell-La & Padula dans le fait qu'un processus (tournant au niveau Confidential) peut lire/écrire à son niveau courant, mais ne peut que lire dans les niveaux inférieurs ou seulement écrire dans les niveaux supérieurs.

   Celà s'assure de la confidentialité vu que le processus peut copier un fichier au nieau secret, mais ne peut jamair relire son contenu sauf si le processus s'élève à ce niveau. Le processus ne peut pas écrire les fichiers à des niveaux inférieurs au niveau confidential.

Nivaux de sécurité et flux de données
   Pour accomplir ce niveau de contrôle, les extensions MLS de SELinux utilisent les contraintes similaires à ceux décris dans la section contraintes des types forcés, excepté que la déclaration est appelée mlsconstrain.

   Cependant, comme la vie n'est pas simple:

1. Les processus et objets peuvent avoir une plage qui représente les niveaux de sécurité faible et élevés
2. Le niveau de sécurité peut être plus complexe, en cela que c'est une sensibilité hiérarchique et 0 ou plusieurs catégories
3. Permettre à un processus d'accéder à un objet est géré par des règles de dominance appliqués aux niveaux de sécurité.
4. Les processus trustés peuvent avoir des privilèges qui les autorisent à bypasser les règles BLP.
5. Certains objets ne supportent pas les fonctions de lecture/écriture séparés vu qu'ils nécessitent de lire/répondre dans les ce cas comme les réseaux.

   Les sections qui suivent discutent du format d'un niveau de sécurité et de la plage, et la manière dont elles sont gérées par les mécanismes de contrainte dans SELinux en utilisant les règles de dominance.

Niveaux de sécurité

   Les éléments ci-dessous montrent les composants qui créent un niveau de sécurité et comment 2 niveaux de sécurité depuis une plage de pour le quatrième et options [:range].

   Le niveau de sécurité consiste d'une sensibilité ou 0 ou plusieurs entrées catégories: sensitivity [: category;...]. Noter que SELinux utilise les niveaux, la sensibilité et la catégorisation dans les déclarations de langage, cependant les termes suivants peuvent également être utilisés: labels, classification, et compartiment.

   Dans une plage, low, pour un processus, un sujet ou un objet constitue le niveau ou la sensibilité courante. SystemLow est le niveau ou la classification la plus faible pour le système. (pour SELinux, c'est généralement s0, noter qu'il n'y a pas de catégories).

   Dans une plage, high, pour un processus ou un sujet est l'autorisation. Pour un objet, c'est la plage maximum. SystemHigh est le niveau ou la classification la plus haute (pour SELinux c'est généralement s15:c0,c255)

Les composants suivants sont utilisés pour définir les niveaux de sécurité MLS/MCS dans le contexte de sécurité:
user:role:type:sensibilité[:catégorie,...] - sensibilité[:catégorie,...]

   où:

Sensibilité Les niveaux de sensibilité sont hiérarchiques avec (traditionnellement) s0 étend le plus faible. Ces valeurs sont définies en utilisant la déclaration sensitivity. Pour définir leur hiérarchie, la déclaration dominance est utilisée. Pour les systèmes MLS la sensibilité la plus haute est la dernière définie dans la déclaration dominance. Traditionnellement le maximum pour les système MLS est s15. Pour les système MCS il y a seulement une sensibilité définie, s0.
Catégorie Les catégories sont optionnelles et forment une liste non-ordonnée et non-liées de compartiments. Ces valeurs sont définies en utilisant la déclaration category, où par exemple c0.c3 représente une plage et c0,c3,c7 représente une liste. Traditionnellement les valeurs sont entre c0 et c255.
level Le niveau est une combinaison de valeurs de sensibilité et catégorie qui forment le niveau actuel de sécurité. Ces valeurs sont définies en utilisant une déclaration level.

Traduire les niveaux

   En écrivant des stratégie pour MS/MCS on utilise généralement une forme abbréviée tel que s0, s1, etc. pour représenter la sensibilité et c0, c1, etc. pour représenter les catégories. Cela permet de conserver de l'espace dans les attributs étendus des fichiers, et également en mémoire. Donc pour que ces labels puissent être représentés au format compréhensible, un service de traduction est fournis via le fichier setrans.conf qui est utilisé par le services mcstransd. Par exemple s0 = Unclassified, s15 = Top Secret et c0 = Finance, c100 = Spy Stories. La commande semanage peut être utilisée pour utiliser cette traduction.

Gérer les niveaux de sécurité via les règles de dominance

   Comme statué plus haut, autoriser un processu à accéder à un objet est géré par des règles de dominance appliqués aux niveaux de sécurité. Ces règle sont les suivantes:

L1 domine L2 Si la sensibilité de L1 est égal ou supérieur à la sensibilité de L2 et que les catégories de L1 sont les même ou un super-jeu des catégories de L2
L2 domine L1 Si la sensibilité de L1 est égal ou inférieur à la sensibilité de L2 et que les catégories de L1 sont un sous-jeu des catégories de L2
L1 équivaut à L2 Si la sensibilité de 1 et égal à L2 et les catégories de L1 et L2 sont les même.
L1 est incomparable à L2 Si les catégories de L1 et L2 ne peuvent être comparés.

   Pour illustrer l'utilisation de ces règles, la table ci-dessous liste les attributs de niveau de sécurité pour montrer des fichiers qui ont été labélisés comme s3:c0. Le processus qui accède à ces fichiers (ex: un éditeur) tourne avec une plage s0 - s3:c1.c5 et a accès aux fichiers en gras.

   Vu que la déclaration dominance MLS est utilisée pour forcer la hiérarchie de sensibilité, les niveaux de sécurité suivent maintenant la séquence (faible = s0 à élevé = s3) avec les catégories étant des listes de compartiments. Pour autoriser le processus à accéder aux fichiers dans son scope et avec les règles de dominance, le processus sera contraint en utilisant la déclaration mlsconstrain.

Niveaux de sécurité MLS
Déclarations mlsconstain
1. Pour autoriser write-up, le niveau source (l1) doit être dominé par le niveau cible (l2)
2. Pour autoriser read-down, le niveau source (l1) doit dominer le niveau cible (l2)

   Cependant, dans le monde réel la stratégie de référence MLS n'autorise pas le write-up sauf si le processus a un privilège spécial (en ayant le type de domaine ajouté à un attribut), bien qu'il autorise le read-down. Le défaut est d'utitilesr l1 et l2. Le fichier source policy/mls montre ces déclaration mlsconstrain.

Certification Common Criteria

   Bien que le processus de certification Common Criteria est au delà du scope de ce document, Il est à souligner que des versions de logiciel RedHat, tournant sur des plateformes hardware spécifiques avec SELinux/MLS ont passé le processus d'évaluation Common Criteria. Noter que pour l'évaluation et le déploiement de logiciel et hardware sont liés, quand une mise à jours est nécessaire, une mise à jours de la certifiation doit être obtenue.

Types de stratégie SELinux

   Cette section décris les différents types de stratégie. Le type de stratégie SELinux peut être décris de plusieurs manières.

Stratégie exemple

   La stratégie exemple est le nom utilisée pour décrir le source utilisé pour construire une stratégie monolitique produite par le NSA et désormais remplacé par le stratégie de référence.

Stratégie référence

   Le stratégie référence est le startégie standard utilisée pour construire des stratégies SELinux, et son but est de fournir une arborescence simple avec une documentation support qui peut être utilisé pour construire des stratégie pour différents cas tel que confiner des services importants, supporter MLS/MCS et bloquer les systèmes pour que tous les processus soient sous le contrôle de SELinux.

   La stratégie référence est utilisée par toutes les distributions Linux, cependant, chaque distribution effectue des propres changements.

Fonctionnalité de stratégie basé sur le nom ou le type

   Généralement une stratégie est installée avec un nom donné tel que targeted, mls, refpolicy ou minimum qui tente de décrire ses fonctionnalités. Ce nom devient ainsi l'entrée dans:

1. Le répertoire pointant à l'emplacement de la stratégie (ex: si le nom est targeted, la stratégie est installée dans /etc/selinux/targeted)
2. L'entrée SELINUXTYPE dans /etc/selinux/config quand c'est la stratégie active (ex: si le nom est targeted, l'entrée est SELINUXTYPE=targeted).

Stratégie Monolitique

   Une stratégie monolitique est une stratégie SELinux qui est compilée depuis un fichier source appelé par convention policy.conf. Il n'utilise pas les déclaration de module chargeable et est prévu pour les systèmes embarqués.

Stratégie à module chargeable

   L'infrastructure à module chargeable permet de gérer une stratégie sur une base modulaire, il y a un module de stratégie de base qui contient tous les composants du corp de la stratégie, et 0 ou plusieurs modules qui peuvent être chargés et déchargés si requis. Il y a plusieurs composants qui forment l'infrastructure:

1. Le source de la stratégie qui est construite pour une stratégie modulaire avec un module de base et des modules chargeables optionnels
2. Des utilitaires pour compiler et lier les modules et les placer dans un magasin de stratégie
3. Des utilitaires pour gérer les modules et les fichiers de configuration associés dans le magasin de stratégie

Stratégie optionnelle

   L'infrastructure de stratégie à module supporte également une déclaration optionnelle qui permet de définir des règsles qui sont activées eulement dans la stratégie binaire une fois les conditions satisfaites.

Stratégie conditionnelle

   Les stratégie conditionnelles peuvent être implémentées dans des stratégies monolitiques ou à module et permet d'activer des parties de la stratégie en fonction de l'état d'un flag en temps-réel. Les flags sont maintenus dans le kernel et peuvent être changés avec setsebool.

   Les déclaration de langage de stratégie conditionnelle sont des déclaration bool qui définissent l'identifiant de flag et son status initial, et la déclaration if qui permet à certaines règles d'être exécutées en fonction de l'état des valeur booléennes.

Stratégie binaire

   Également connu sous le nom de stratégie kernel, c'est le fichier de stratégie qui est chargé dans le kernel et est localisé à /etc/selinux/‹SELINUXTYPE›/policy/policy.‹version›.

Versions de stratégie

   SELinux a une base de stratégie (définie dans libsepol) qui décris le format des données gérée dans une stratégie binaire, cependant, si de nouvelles fonctionnalités sont ajoutées à SELinux, il peut y avoir un changement dans la base. sestatus affiche la version maximum supportée par le kernel.

Mode permissif et forcé

   SELinux a 3 modes d'opération majeurs:

Enforcing SELinux impose la stratégie chargée
Permissive SELinux charge la stratégie, mais ne l'impose pas. Généralement utilisé pour les tests
Disabled SELinux n'est pas activé.

   Ces flags sont définis dans /etc/selinux/config. Il y a une autre méthode pour exécuter des domaines spécifique en mode permissif en utilisant la déclaration permissive. Cela peut être utilisé dans un module utilisateur ou semanage génère le module approprié et le charge en utilisant l'exemple suivant: semanage permissive -a unconfined_t

   Il est également possible de définir un mode permissif dans le gestionnaire d'objet userspace en utilisant libselinux. sestatus affiche le mode courant, cependant, il n'affiche pas le domaine individuel ou les modes du gestionnaire d'objet.

Auditer les évènements SELinux

   Pour SELinux il y a 2 types principaux d'évènements d'audit:

1. Les évènement AVC - Ils sont générés par le sous-système AVC en résultat à des accès refusés, ou quand des évènements spécifique sont demandés.
2. Évènements d'applications - Ils sont générés par les services kernel SELinux et les applications compatibles SELinux.

   Les messages d'évènement et d'audit sont généralement stockés dans un de ces logs:

1. Le évènement SELinux du boot kernel sont loggés dans /var/log/dmesg
2. /var/log/messdages contient les messages générés par SELinux avant que le système d'audit soit chargé
3. /var/log/audit/audit.log contient les évènements qui prennent place une fois le service d'audit chargé.

Notes

a) Il n'est pas obligatoire pour les applications SELinux d'auditer les évènements ni de les logger.
b) Le format des messages d'audit n'a pas besoin de se conformer à un format, cependant, si possible les applications devraient utiliser la fonction audit_log_user_avc_message(3)
c) Le fonctions de librairie SELinux affichent des messages également sur stderr par défaut. Cependant celà peut être changé avec selinux_set_callback(3).

Évènements d'audit AVC

   Cette section décris le format général des messages d'audit AVC dans audit.log.

type type peut être AVC pour les évènements kernel, ou USER_AVC pour les évènement des gestionnaires d'objet userspace. Une fois l'évènement AVC loggé, le type SYSCALL peut suivre et contient des informations supplémentaires
msg Contient le mot clé 'audit' avec un numéro de référence
avc Soit denied soit granted
pid|comm Si c'est une tâche, log le pid et le nom de l'exécutable
capability Si c'est un évènement de capability, log l'identifiant
path|name|dev|ino Si c'est en évènement de système de fichier, log les informations spécifique
laddr|lport|faddr|fport Si c'est un évènement socket, log les adresses/port source/destination
path Si c'est un évènement de fichier socket, log le chemin
saddr|src|daddr|dest|netif Si un évènement réseau, log les adresses/port source/destination
sauid|hostname|addr|terminal Identifiant d'association de sécurité IPSec
resid|restype Type et ID de ressource X-Windows
scontext Le contexte de sécurité de la ressource ou sujet
tcontext Le contexte de sécurité de la cible ou objet
tclass La classe objet de la cible ou objet

Évènements d'audit SELinux général

   Cette section montre une sélection d'évènements d'audits de service non AVC pris depuis audit.log. Pour une liste d'entrée "type=" valides, les fichiers include suivant devraient être consultés: include/libaudit.h et include/linux/audit.h.

   Noter qu'il peut y avoir plusieurs évènements générés pour le même évènement. Par exemple, le serveur de sécurité kernel génère une évènement MAC_POLICY_LOAD pour indiquer que la stratégie a été rechargée, mais chaque gestionnaire d'objet userspace peut également générer un USER_MAC_POLICY_LOAD pour indiquer qu'il a également traité l'évènement.

MAC_POLICY_LOAD, USER_MAC_POLICY_LOAD - ces évènements sont générés quand la stratégie est rechargée:
type=MAC_POLICY_LOAD msg=audit(1336662937.117:394): policy loaded auid=0 ses=2
type=SYSCALL msg=audit(1336662937.117:394): arch=c000003e syscall=1 success=yes exit=4345108 a0=4 a1=7f0a0c547000 a2=424d14 a3=7fffe3450f20 items=0 ppid=3845 pid=3848 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=2 comm="load_policy" exe="/sbin/load_policy" subj=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 key=(null)
type=USER_MAC_POLICY_LOAD msg=audit(1336662938.535:395): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xserver_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) : exe="/usr/bin/Xorg" sauid=0 hostname=? addr=? terminal=?'

MAC_STATUS - Généré quand le mode SELinux est changé:
type=MAC_STATUS msg=audit(1336836093.835:406): enforcing=1 old_enforcing=0
auid=0 ses=2
type=SYSCALL msg=audit(1336836093.835:406): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffe743f9e0 a2=1 a3=0 items=0 ppid=2047 pid=5591 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

MAC_CONFIG_CHANGE - Généré quand setsebool a été lancé pour changer un booléen.
type=MAC_CONFIG_CHANGE msg=audit(1336665376.629:423): bool=domain_paste_after_confirm_allowed val=0 old_val=1 auid=0 ses=2
type=SYSCALL msg=audit(1336665376.629:423): arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=7fff42803200 a2=2 a3=7fff42803f80 items=0 ppid=2015 pid=4664 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="setsebool" exe="/usr/sbin/setsebool" subj=unconfined_u:unconfined_r:setsebool_t:s0-s0:c0.c1023 key=(null)

MAC_UNLBL_STCADD - Généré quand un label statique non-mappé est ajouté
type=MAC_UNLBL_STCADD msg=audit(1336664587.640:413): netlabel: auid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 netif=lo src=127.0.0.1 sec_obj=system_u:object_r:unconfined_t:s0-s0:c0,c100 res=1
type=SYSCALL msg=audit(1336664587.640:413): arch=c000003e syscall=46 success=yes exit=96 a0=3 a1=7fffde77f160 a2=0 a3=666e6f636e753a72 items=0 ppid=2015 pid=4316 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="netlabelctl" exe="/sbin/netlabelctl" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

SELINUX_ERR - Généré par le serveur de sécurité kernel suite à des privilège de anon-webapp_t supérieur à celui donné au processus qui a lancé le thread
type=SELINUX_ERR msg=audit(1311948547.151:138): op=security_compute_av reason=bounds scontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200 tcontext=system_u:object_r:security_t:s0 tclass=dir perms=ioctl,read,lock
type=SELINUX_ERR msg=audit(1311948547.151:138): op=security_compute_av reason=bounds scontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200 tcontext=system_u:object_r:security_t:s0 tclass=file perms=ioctl,read,write,getattr,lock,append,open

Généré par le serveur de sécurité kernel quand une application compatible SELinux tente d'utiliser setcon pour créer un nouveau thread
type=SELINUX_ERR msg=audit(1311947138.440:126): op=security_bounded_transition result=denied oldcontext=system_u:system_r:httpd_t:s0-s0:c0.c300 newcontext=system_u:system_r:anon_webapp_t:s0-s0:c0,c100,c200
type=SYSCALL msg=audit(1311947138.440:126): arch=c000003e syscall=1 success=no exit=-1 a0=b a1=7f1954000a10 a2=33 a3=6e65727275632f72 items=0 ppid=3295 pid=3473 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0-s0:c0.c300 key=(null)

USER_ROLE_CHANGE - newrole(1) a été utilisé pour définir un nouveau rôle qui n'est pas valide
type=USER_ROLE_CHANGE msg=audit(1336837198.928:429): pid=0 uid=0 auid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='newrole: old-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 new-context=?: exe="/usr/bin/newrole" hostname=? addr=? terminal=/dev/pts/0 res=failed'

Support de la poly-instanciation

   GNU/Linux supporte la poly-instanciation des répertoires qui peuvent être utilisé par SELinux via PAM. La poly-instanciation des objets est également supporté pour les sélections X-Windows. Noter que les sockets ne sont pas encore supportés. Pour clarifier le support de la polyinstanciation:

1. SELinux a des fonctions libselinux et une règle de stratégie pour supporter la poly-instanciation
2. La poly-instanciation des répertoires est une fonction de GNU/Linux
3. La poly-instanciation des sélections X-Windows et des propriétés est une fonction du gestionnaire d'objet XSELinux et le support du service XACE

Objects poly-instanciés

   Déterminer un contexte poly-instancié pour un objet est supporté par SELinux en utilisant la déclaration type_member et les fonctions avc_compute_member et security_compute_member. Ce n'est pas limité à des classes d'objets spécifique, cependant seul les objets dir, x_selection et x_property sont actuellement supportés.

Support de la poly-instanciation dans PAM

   PAM supporte la poly-instanciation (namespaces) des répertoires à la connexion en utilisant les services d'arborescence partagée/espaces de noms disponibles dans GNU/Linux (voir namespace.conf) Noter que PAM et les services d'espace de nom sont compatibles SELinux.

   L'installation par défaut de F-20 n'active pas les répertoires poly-instanciés par défaut, cependant cette section montre la configuration requise pour activer cette fonctionnalité et quelques exemples.

   Pour implémenter les répertoires poly-instanciés PAM exige que les fichiers suivants soient configurés:

1. Une entrée pour le module pam_namespace. F-20 a déjà ces entrées dans /etc/pam.d/gdm-password.
2. Les entrées sont ajoutées dans /etc/security/namespace.conf et définissent les répertoires à poly-instancier par PAM.

   Une fois ces fichiers configurés et qu'un utilisateur se log, pam_namespace départage l'espace de nom cournat de son parent et monte les espaces de nom en accord avec les règles définies dans namespace.conf. F-20 inclus également le script /etc/security/namespace.init. qui est utilisé pour initialiser l'espace de nom chaque fois qu'une nouvelle instance de répertoire est définis. Ce script reçois 4 paramètres: le chemin du répertoire poly-instancié, le chemin de l'instance du répertoire, un flag pour indiquer si une nouvelle instance, et un nom d'utilisateur. Si une nouvelle instance est définie, les permissions du répertoire sont définis et restorecon(8) est lancé pour définir le contexte de fichier.

Fichier de configuration namespace.conf

Chaque ligne dans namespace.conf est formaté comme suit:
polydir instance_prefix method list_of_uids
où:

        polydir Chemin absolu du répertoire à poly-instancier. $USER et $HOME sont remplacés
        instance_prefix Un préfixe utilisé pour construire le chemin pour le répertoire poly-instancié. $USER et $HOME sont remplacés
        method Détermine a méthode de la poly-instanciation:

                user La poly-instanciation est basée sur les noms d'utilisateur
                level La poly-instanciation est basée sur le nom d'utilisateur et le niveau MLS
                context La poly-instanciation est basée sur le nom d'utilisateur et le contexte de sécurité

           Liste de noms d'utilisateurs qui n'ont pas de répertoires poly-instanciés. Si vide, tous les utilisateurs poly-instanciés. Si la liste est précédée par '-', seul les utilisateurs dans la liste ont des répertoires poly-instanciés.

Exemple de configuration

   Cette section montre 2 exemple de configuration namespace.conf, le premier utilise la méthode user, et l'autre context. Noter que tant que la poly-instanciation est activée, les noms de chemins complet ne sont pas visible, c'est seulement quand la poly-instanciation est désactivée que les répertoires deviennent visible.

Exemple 1 - method=user:
#polydir instance-prefix method list_of_uids
/tmp /tmp-inst/ user root,adm
/var/tmp /var/tmp/tmp-inst/ user root,adm
$HOME $HOME/$USER.inst/ user

Se connecter en tant qu'utilisateur normal. Le processus PAM va construire les répertoires poly-instanciés suivant:
# /tmp
/tmp/tmp-inst/myuser
# /var/tmp
/var/tmp/tmp-inst/myuser
# $HOME
/home/myuser/myuser.inst/myuser

Exemple 2 - method=context
#polydir instance-prefix method list_of_uids
/tmp /tmp-inst/ context root,adm
/var/tmp /var/tmp/tmp-inst/ context root,adm
$HOME $HOME/$USER.inst/ context

Se connecter en tant qu'utilisateur normal. Le processus PAM va construire les répertoires poly-instanciés suivant:
# /tmp
/tmp/tmp-inst/unconfined_u:unconfined_r:unconfined_t_myuser
# /var/tmp
/var/tmp/tmp-inst/unconfined_u:unconfined_r:unconfined_t_myuser
# $HOME
/home/myuser/myuser.inst/unconfined_u:unconfined_r:unconfined_t_myuser

Support dans la stratégie référence

   Les modules files.te et files.if supportent la poly-instanciation. Il y a également un booléen allow_polyinstanciation qui peut être utilisé pour activer cette fonctionnalité durant le login. Défaut: false.

Processus de login PAM

   Les application utilisées pour fournir des services de login (comme gdm ou ssh) utilisent PAM pour fournir les services suivants:

Gestion de compte: Ce service gère les services tels que l'expiration des mots de passe, et les services de login autorisés
Gestion de l'authentification Authentifie l'utilisateur ou le sujet et définis les accréditifs
Gestion des mots de passe Gère les mises à jours de mot de passe
Gestion de session Gère les service qui doivent être invoqués avant que le processus de login se complète et/ou quand le processus de login de termine.

Il y a également des fichiers de configuration PAM liés à SELinux dans la section file de /etc/security/sepermit.conf. Les services core sont fournis par PAM, cependant d'autres moules peuvent être écris pour gérer les services spécifiques tel que le support pour SELinux. Les modules SELinux utilisent libseliinux pour obtenir la configuration:

pam_selinux_permit.so Autorise à des utilisateurs prédéfinis la capacité de se logger sans fournir de mot de passe
pam_selinux.so open Définis un contexte de sécurité pour l'utilisation au login.
pam_selinux.so close Réinitialise le contexte des programme login au contexte par défaut

LSM et SELinux

   LSM est le framework de sécurité Linux qui autorise à des mécanisme de contrôle d'accès tier d'être liés dans le kernel GNU/Linux. Actuellement il y a 5 services qui utilisent LSM:

1. SElinux
2. AppArmor
3. SMACK
4. Tomoyo
5. Yama

   L'idée de base derrière LSM est de:

- Insérer des hooks de fonction de sécurité et des structures de données de sécurité dans les divers services kernel.
- Autoriser l'enregistrement et l'initialisatio des services pour les modules tiers de sécurité
- Les attributs de sécurité de processus sont disponibles aux services userspace en étendant le système de fichier /proc avec un espace de nom de sécurité
- Supporter des systèmes de fichier qui utilisent les attributs étendus
- Consolider les capacités Linux dans un module optionnel

   Il devrait être noté que LSM ne fournis aucun service de sécurité, seulement les hooks et structures pour supporter des modules tiers. S'il n'y a pas de module tiers chargé, les capacités deviennent le module par défaut autorisant le modèle DAC standard

Les services kernel où LSM implémente les hooks et structures sont:
exécution de programme
opérations de fichier
Réseaux de domaine Unix
Opérations de gestion de clé
Sémaphores
Syslog
Opérations de système de fichier
Opérations sur les tâches
Opérations sur les sockets
Opérations IPC
Capability
Audit
Opérations sur les inodes
Messagerie Netlink
Opérations XFRM
Segments mémoire
Sysctl

   Fichiers /proc/self/attr/ utilisé par les services kernel et libselinux:

current (-rw-rw-rw) - Contient le contexte de sécurité du processus
exec (-rw-rw-rw) - Définis le contexte de sécurité pour le prochain appel exec
fscreate (-rw-rw-rw) - Définis le contexte de sécurité des nouveaux fichiers créés
keycreate (-rw-rw-rw) - Définis le contexte de sécurité pour les clés qui sont en cache dans le kernel
prev (-r--r--r-) - Contient le précédent contexte de sécurité
sockcreate (-rw-rw-rw) - Définis le contexte de sécurité pour les nouveaux sockets créés

Support réseau

   SELinux supporte les types suivans de label réseau:

Label interne C'est où les objets réseaux sont labélisés et gérés en interne dans une seule machine: SECMARK et NetLabel
Réseau labélisé Lorsque les labels sont passé aux systèmes distant où ils peuvent être interprétés: IPSec et CIPSO

   Il y a 2 options de capability de stratégie qui peuvent être définis dans la stratégie en utilisant la déclaration policycap qui affecte la configuration réseau:

network_peer_controls Toujours activé dans la stratégie référence
always_use_network Cette capacité est normalement à false. À true, SECMARK et NetLabel sont toujours activés même s'il n'y a pas de règles configurés. Celà force la vérification de la classe packet pour protéger le système.

   Les paramètres de capability de stratégie sont disponible en userspace via les systèmes de fichiers SELinux. Pour supporter le label paire et CIPSO, les outils NetLabel doivent être installés (package netlabel_tools)

   Pour supporter IPSec labélisé, les outils IPSec doivent être installés (package ipsec-tools)

   Il est également possible d'utiliser un service IPSec labélisé alternatif, LibreSwan

   Il est important de noter que le kernel doit être configuré pour supporter ces services. Le package iproute a la commande de statistique socket ss(8) qui affiche le contexte SELinux des processus réseaux et les sockets réseaux. Noter que les contextes sockets sont pris depuis les inodes associés au socket et non de la structure socket kernel.

SECMARK

   SECMARK utilise le framework NetFilter du kernel. NetFilter inspecte automatiquement tous les paquets entrants et sortants et peut placer des contrôles dans les interfaces, les adresse IP et ports avec un suivi de connexion. L'extension SECMARK permet d'ajouter des contextes de sécurité aux paquets (SECMARK) ou aux session (CONNSECMARK).

   Le framework NetFilter inspecte et tag les paquets avec des labels tel que définis dans iptables puis utilise le framework de sécurité (ex: SELinux) pour forcer les règles de stratégie. La structure de base est comme suit:

- Un table appelée 'security table' est utilisée pour définir les paramètres qui identifient et marque les paquets qui peuvent ainsi être suivis à mesure que le paquet voyage dans le sous-système réseaux. Ces marques sont appelées SECMARK et CONNSECMARK.
- Un SECMARK est placé sur un paquet s'il matche une entrée dans la table de sécurité qui applique un label qui peut ensuite être utilisé pour forcer la stratégie dans le paquet.
- Un CONNSECMARK maque tous les paquets dans une session avec le label approprié qui peut ensuite être utilisé pour forcer la stratégie.

Exemple d'entrée dans la table security. Marquer tous les paquets:
iptables -t security -A INPUT -i -lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0
Ces règles remplacent le contexte précédent avec la gateway interne ou externe si le port 9999 ou 1111 est trouvé:
iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save
# Flux de sortie
iptables -t security -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0
iptables -t security -A OUTPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A OUTPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A OUTPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A OUTPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save

NetLabel - Fallback labeling

   le labeling peut optionnellement être implémenté dans un système si IPSec ou CIPSO labelisé n'est pas utilisé (falback labeling). Si IPSEC ou CIPSO labelisé est utilisé, il a précédence. Le contrôle du paire réseau a été étendu pour supporter une classe object additionnelles 'peer' qui est activé par défaut dans la stratégie F-20 si network_peer_controls dans /sys/fs/selinux/policy_capabilities est à 1.

NetLabel - CIPSO

   Pour permettre de passer des niveaux de sécurité dans un réseau entre des systèmes MLS, Le protocole CIPSE est utilisé. C'est définis dans draft-ietf-cipso-ipsecurity-01. Le protocole définis comment les labels de sécurité sont encodés dans l'en-tête IP.

   Noter que seul le composant de niveau du contexte de sécurité est passé sur le réseau. L'exception est le mode loopback. Le protocole est implémenté par le service NetLabel et peut être utilisé par d'autres modules de sécurité qui utilisent l'infrastructure LSM. L'implémentation NetLabel supporte:

1. 1 bit de type de tag qui autorise un maximum de 256 niveaux et 240 catégories
2. Une option non-traductible où les labels sont passés depuis/vers les systèmes de manière inchangée.
3. Une option de traduction où la sensibilité et la catégories peuvent être mappés pour les systèmes qui ont des définitions différentes.

IPsec labélisé

   IPSec labélisé a été construit dans les service IPSec GNU/Linux. La figure ci-dessous montre les composants de base qui forment le service basé sur les outils IPSec généralement utilisés pour chiffrer un tunnel entre 2 machines ou une session de transport chiffré. Les extensions décrive comment le contexte de sécurité est configuré et négocié entre les 2 systèmes (appelé Associations de Securité (SA) dans la terminologie IPSec).

Communications IPSec
   Basiquement il se produit:

1. La base de stratégie de sécurité (SPD) définis les caractéristiques de communication sécurisé à utiliser entre les 2 systèmes. C'est complété en utilisant setkey
2. Le SA a ses paramètres de configuration tel que les protocoles utilisé pour sécuriser les paquets, les algorithmes de chiffrement et la durée de validité des clés dans la base d'association de sécurité (SAD). Pour IPSec labélisé le contexte de sécurité est également définis dans SAD. Les SA peuvent être négociés entre les 2 systèmes en utilisant racoon ou pluto qui vont automatiquement populer SAD et manuellement avec setkey.
3. Une fois les SA négociés et validés, le lien devrait être actif.

   Noter que ces SA sont unidirectionnels, ainsi quand 2 systèmes communiquent, un système aura un SA. SAout pour traiter les paquets sortant, et un autre SAin pour traiter les paquets entrants. L'autre système devrat également créer 2 SA pour traiter ses paquets.

   Chaque SA partage les même paramètres cryptographiques tels que les clés et protocoles ESP et AH.

   La classe objet utilisée pour l'association d'un SA est 'association' et les permissions disponibles comme suit:

polmatch Matche le contexte SPD (-ctx) à un domaine SELinux (qui est contenu dans l'entrée -ctx SAD)
recvfrom Reçu depuis une association IPSec
sendto Envoyé à une association IPSec
setcontext Définis le contexte d'une association IPSec à la création.

   En lançant IPSec labélisé il est recommandé que les systèmes utilisent le même type/version de stratégie pour éviter tout problème.

Exemples de configuration

   Il y a 2 solutions disponibles:

Outils IPSec - setkey et racoon
LibreSwan - ipsec et pluto

   Tous fonctionnent de la même manière mais utilisent différents fichiers de configuration. Le point qu'ils ont en commun est qu'ils démarrent une session en utilisant IKE, setkey doit être utilisé pour initialiser les labels dans la SPD dans chaque machine

   Un autre point à noter est que si racoon et pluto sont interopérables, les valeurs d'attributs d'association de sécurité sont différents:

- racoon a cette valeur à 10
- pluto est configurable avec par défaut 32001. Pour intéropérer avec racoon, ipsec.conf doit avoir: secctx_attr_value = 10

   L'exemple suivant montre la configuration setkey commune pour définir les entrées SPD et en exemple de configuration supportant racoon et pluto:

Ajouter un label/contexte au SPD pour la boucle locale:
flush;
spdflush;
spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0" -P out ipsec esp/transport//require;
spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0" -P in ipsec esp/transport//require;
spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0" -P out ipsec esp/transport//require;
spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0" -P in ipsec esp/transport//require;

Configuration racoon:
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";
    
sainfo anonymous
{
    lifetime time 1 hour ;
    encryption_algorithm 3des, blowfish 448, rijndael ;
    authentication_algorithm hmac_sha1, hmac_md5 ;
    compression_algorithm deflate ;
}

Configuration LibreSwan/pluto:
version 2.0
config setup
    plutorestartoncrash=false
    protostack=netkey
    plutodebug="all"
    secctx_attr_value = 32001
conn labeled_loopback_test
    auto=start
    rekey=no
    authby=secret
    type=transport
    left=127.0.0.1
    right=127.0.0.1
    ike=3des-sha1
    phase2=esp
    phase2alg=aes-sha1
    loopback=yes
    labeled_ipsec=yes
    policy_label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0
    leftprotoport=tcp
    rightprotoport=tcp

Support des machines virtuelles

   Le support de SELinux est disponible dans KVM/QEMU et Xen. Actuellement le principal support SELinux pour la virtualisation se fait via libvirt qui est une API de virtualisation open-source utilisée pour charger dynamiquement les VM. Les extensions de sécurité ont été ajoutés dans le projets Svirt et l'implémentation pour QEMU/KVM. Les sections qui suivent donnent une introduction à QEMU/KVM, puis libvirt.

Support QEMU/KVM

   KVM est un module kernel qui utilise le kernel Linux comme hyperviseur et utilise un QEMU modifié pour supporter l'émulation hardware. Le support SELinux pour les VM est implémenté par le sous-système libvirt qui est utilisé pour gérer les images VM en utilisant un VMM, et comme KVM est basé sur Linux il a le support SELinux par défaut. Il y a également des module de stratégie référence pour supporter l'infrastructure générale.

Support libvirt

   Le projet Svirt a ajouté des hooks de sécurité dans la librairie libvirt qui est utilisée par le service libvirtd. Le fournisseur de VM peut implémenter des mécanismes de sécurité qui nécessite d'utiliser un pilote libvirt spécifique qui va charger et gérer les images. L'implémentation SELinux supporte 4 méthodes de label des images VM, processus et leur ressources associées supporté dans le module modules/services/virt.* de la stratégie référence. Pour supporter le labeling, libvirt nécessite une stratégie MCS ou MLS vu que le level du contexte de sécurité est utilisé (user:role:type:level).

Labéliser les images VM

   Le labeling dynamique, Le mode par défaut, lorsque chaque VM est lancé dans son propre domaine configuré dynamiquement et donc isole les VM entre-elles (chaque fois que la VM est lancée un label MCS différent et unique est généré). Ce mode est implémenté comme suit:

        a) Un contexte initial pour le processus est obtenu depuis /etc/selinux/‹SELINUXTYPE›/contexts/virtual_domain_context (défaut: system_u:system_r:svirt_tcg_t:s0)
        b) UN contexte initial pour le fichier image est obtenu depuis /etc/selinux/‹SELINUXTYPE›/contexts/virtual_image_context (defaut: system_u:system_r:svirt_image_t:s0 qui autorise la lecture/écriture des fichiers image)
        c) Quand l'image est utilisée pour démarrer la VM, un niveau MCS est généré et ajouté au contexte du processus et au contexte du fichier image. Le processus et les fichiers images sont transités dans le contexte via setfilecon et setexeccon.

   Si l'image disque doit être partagé, le niveau dynamiquement alloué sera généré par chaque instance du processus VM, cependant il y aure une seule instance de l'image disque (image partagée).

La ressource XML pour le contenu de ‹disk› doit inclure ‹shareable/›. Avec la stratégie targeted de F-20, l'option shareable donne une erreur, il est donc nécessaire d'activer la mémoire partagée:
setsebool -P virt_use_execmem on

   Maintenant que l'image a été configurée comme partageable, le processus d'initialisation commence:

        a) Un contexte initiale pour le processus est obtenu depuis /etc/selinux/‹SELINUXTYPE›/contexts/virtual_domain_context (défaut: system_u:system_r:svirt_tcg_t:s0)
        b) Un contexte initial pour le lable du fichier image est obtenu depuis /etc/selinux/‹SELINUXTYPE›/contexts/virtual_image_context. Défaut: system_r:system_r:svirt_image_t:s0)
        c) Quand l'image est utilisée pour démarrer la VM un niveau MCS aléatoire est généré et ajouté au contexte du processus (mais pas le fichier image). Le processus est transité au contexte approprié par les appels setfilecon et setexeccon.

   Il est possible de définir les labels statiques, cependant en conséquence l'image ne peut pas être clonée en utilisant le VMM. C'est la méthoide utilisée pour configurer les VM dans les systèmes MLS via qu'il y a un label connu qui définis le niveau de sécurité. Avec cette méthode il est également possible de configurer 2 ou plusieurs VM avec le même contexte de sécurité pour qu'elles puissent partager des ressources.

Dans la ressource XML, ajouter:
...
‹/devices›
‹seclabel type='static' model='selinux' relabel='no'›
    ‹label›system_u:system_r:avirt_t:s0:c1022,c1023‹/label›
‹/seclabel›
    
    ‹/domain›

Services Sandbox

   Fedora supporte les 3 type de service sandbox:

1. sandboxing non-GUI.
2. Sandboxing GUI utilisant le serveur Xephyr. Il permet l'isolation d'application X via des serveurs Xephyr imbriqués.

   Ces services sandbox sont définis dans sandbox(3) et sont disponibles dans le package policycoreutils. Ils utilisent seunshare(8), qui permet de lancer des commandes dans un home alternatif. sandbox.conf permet de configurer le nom, cpu et utilisation mémoire.

   Noter que les services sandbox nécessitent le support MCS vu que les catégories sont utilisées pour isoler les multiples sandbox.

3. sandboxing pour la virtualisation des application en utilisant soit QEMU/KVM ou LXC. ce service est disponible dans le package libvirt-sandbox et fournis une API et des services en ligne de commande pour démarrer des sessions.

   Le package est construit sur Svirt qui fournis la virtualisation avec SELinux et QEMU/KVM ou LXC pour fournir un environnement de virtualisation. Si le support de KVM n'est pas disponible dans la machine, LXC est l'alternative à utiliser.

Support X-Windows

   L'implémentation XSELinux fournis un contrôle d'accès fin à la majorité des objets X-server en utilisant une extension X-Windows ajissant comme gestionnaire d'objet. Le nom de l'extension est 'SELinux'.

   Dans Fedora XSELinux est désactivé dans la stratégie ciblée, mais activée dans la stratégie MLS, dû au fait que Red-Hat préfère utiliser le sandboxing avec Xephyr pour isoler les fenêtres.

   Il est important de noter que l'OM X-Windows opère sur les objets bas niveau du serveur X. Un gestionnaire comme Gnome ou twm s'appuie dessus, cependant ils ne connaissent pas la stratégie forcée par SELinux.

X-Server et le gestionnaire d
   Les composant majeur qui forment XSELinux sont:

la stratégie La stratégie référence a été mise à jours, cependant dans Fedora l'OM est activé pour mls uniquement. (xserver-object-manager).
libselinux La libairie fournie les interfaces nécessaire entre l'OM les services userspaces SELinux, et les services kernel.
fichier x_contexts Contient les informations de configuration de contexte par défaut qui sont requis par l'OM pour labéliser certains objets. L'OM le lit via selabel_lookup(3)
XSELinux Object Manager C'est une extension pour X-server qui agit comme médiateur pour les décisions d'accès entre X-server (via XACE) et le serveur de sécurité SELinux. l'OM est initialisé avant que les X-clients se connectent au X-server.
XACE X Access Control Extension peut être utilisé par d'autres extensions de sécurité de contrôle d'accès, pas seulement SELinux.
X-server Le cœur du serveur X-Windows qui gère les requêtes et réponses depuis/vers les clients X en utilisant le protocole X. l'OM XSELinux intercepte ces requêtes/réponses via XACE et force les décisions de la stratégie
X-clients Ils se connectent au serveur X et sont généralement des gestionnaires de fenêtre comme Gnome ou KDE.

Polyinstanciation

   Les services OM/XACE supportent la polyinstanciation des propriétés et séléctions permettant d'être groupés dans différentes zones d'appartenance pour qu'un groupe ne connaisse pas l'existance des autres. Pour implémenter la polyinstanciation, le mot clé poly_ est utilisé dans le fichier x_context pour les séléctions et propriétés requises. Il devrait y avoir une règle type_member dans la stratégie pour forcer la séparation en calculant un nouveau context avec soit security_compute_member ou avc_compute_member

   Noter que la stratégie référence actuelle n'implémente pas la polyinstanciation, mais la stratégie MLS utilise les règles mlsconstrain pour limiter le périmètre des propriétés et sélections.

Information de configuration

   La stratégie référence a un booléen xserver_object_manager qui active/désactive le module de stratégie X-Server.

   Le gestionnaire d'objet est traité comme une extension X-server et son opcode majeur peut être requêté avec la fonction Xlib XQueryExtension.

Si l'OM X-server doit tourner dans un mode SELinux spécifique, l'option peut être ajoutée dans le fichier xorg.conf (SELInux mode disabled|permissive|enforcing). S'il n'y a pas d'entrée, l'OM suit le mode courant
Section "Module"
    SubSection "extmod"
        Option "SELinux mode enforcing"
    EndSubSection
EndSection

   Le fichier x_contexts contient les informations de contexte par défaut requis par l'OM pour initialiser le service et labéliser les objets quand ils sont créés. La stratégie nécessite également de connaître ces informaions de contexte pour forcer la stratégie ou la transition des nouveaux objets. Une entrée typique est comme suit:

# object_type object_name context
selection PRIMARY system_u:object_r:clipboard_xselection_t:s0
ou pour la polyinstanciation
poly_selection PRIMARY system_u:object_r:clipboard_xselection_t:s0

   object_name peut contenir '*' pour any ou '?' pour substitue. les entrées object_type sont client, property, poly_property, extension, selection, poly_selection et events.

   Les entrées object_name peuvent être tout nom de ressource X qui sont définis dans le code source du serveur X et peuvent être trouvé dans protocol.txt et le fichier source BuildInAtoms.

  Notes:

1) La manière dont le code XSELinux foncion est que les entrées non-poly sont recherchés en premier, si une entrée n'est pas trouvée, cherche une entrée poly. La raison de ce comportement est qu'en opérant dans un environnement sécurisé tous les objets sont polyinstanciés sauf s'il y des exception pour certains objets.
2) Pour les systèmes utilisant la stratégie référence tous les clients X se connectant à distance reçoivent un contexte de sécurité depuis le fichier x_contexts.

SE-PostgreSQL

   L'extension sepgsql permet de labéliser les objets de base PostgreSQL. Le labéling au niveau des entrées n'est plus supporté.

   l'extension segpsql ajoute SELinux aux objets de base de données tels que les tables, colonnes, views, fonctions, schemas et séquences.

Information de contexte de sécurité de base de données
   Pour utiliser SE-PostgreSQL chaque utilisateur GNU/Linux doit avoir un rôle de base de données valide (à ne pas confondre avec un rôle SELinx). L'installation par défaut ajoute automatiquement un utilisateur pgsql avec un rôle de base de données adapté.

   Si un client se connecte à distance et qu'un label réseau est requis, il est possible d'utiliser IPSec ou NetLabel. Dans l'illustration ci-dessous, l'application cliente se connecte à une base et exécute les commandes SQL. vu que les commandes SQL sont traités par PostgreSQL, chaque opération effectuées sur un objet est vérifié par l'OM pour voir si l'opération est permise

Services SE-PostgreSQL
La commande sql SECURITY LABEL a été ajoutée à PostgreSQL pour autoriser les fournisseurs de sécurité à labéliser ou changer un label dans les objets de base de données. Le format de la commande est:
SECURITY LABEL [ FOR provider ] ON
{
    TABLE object_name |
    COLUMN table_name.column_name |
    AGGREGATE agg_name (agg_type [, ...] ) |
    DATABASE object_name |
    DOMAIN object_name |
    EVENT TRIGGER object_name |
    FOREIGN TABLE object_name
    FUNCTION function_name ( [ [ argmode ] [ argname ] argtype
[, ...] ] ) |
    LARGE OBJECT large_object_oid |
    [ PROCEDURAL ] LANGUAGE object_name |
    ROLE object_name |
    SCHEMA object_name |
    SEQUENCE object_name |
    TABLESPACE object_name |
    TYPE object_name |
    VIEW object_name
} IS 'label'

Quelques exemples:
SECURITY LABEL ON SCHEMA test_ns IS 'unconfined_u:object_r:sepgsql_schema_t:s0:c10';
SECURITY LABEL ON TABLE test_ns.info IS 'unconfined_u:object_r:sepgsql_table_t:s0:c20';
SECURITY LABEL ON COLUMN test_ns.info.user_name IS 'unconfined_u:object_r:sepgsql_table_t:s0:c30';
SECURITY LABEL ON COLUMN test_ns.info.email_addr IS 'unconfined_u:object_r:sepgsql_table_t:s0:c40';

Fonctions SQL additionnelles

   les fonctions suivantes ont été ajoutées:

sepgsql_getcon Retourne le contexte de sécurité du client
sepgsql_mcstrans_in(text con) Traduit la plage du contexte en format brut fournis par mcstransd
sepgsql_restorecon(text specfile) Définis les contextes de sécurité dans tous les objets de base de données en accord avec specfile. Normalement utilisé à l'initialisation

postgresql.conf

   Le fichier postgresql.conf supporte les entrées additionnelles suivante pour permettre et gérer SE-PostgreSQL:

Cette entrée est obligatoire pour active l'extension sepgsql
shared_preload_libraries = 'sepgsql'
Permet de personnaliser les entrées sepgsql
custom_variable_classes = 'sepgsql'
Permet de lancer sepgsql en mode permissive
sepgsql.permissive = on
ACtive les messages d'audit sans regarder les paramètres de la stratégie
sepgsql.debug_audit = on

pour voir ces paramètres, la déclaration SHOW peut être utilisée:
SHOW sepgsql.permissive;
SHOW sepgsql.debug_audit;

   SE-PostgreSQL gère ses propres entrées d'audit AVC dans les logs standard PostgreSQL dans /var/lib/pgsql/data/pg_log, et par défaut seul les erreurs sont loggés. 'sepgsql.debug_audit = on' peut être spécifié pour logger tous les évènements d'audit.

   Pour supporter les opérations de base de données PostgreSQL a des tables internes dans le catalogue système qui maintient les informations sur les bases, tables, etc. Cette section discute de la table pg_seclabel qui maintient les labels de sécurité et autres références.

objoid L'OID de l'objet pour lequel ce label est pertinent
classoid L'OID du catalogue système dans lequel cet objet apparaît
objsubid Pour un label de sécurité dans une colonne, c'est le numéro de colonne. Pour tous les autres objets cette colonne est 0.
provider Fournisseur de label associé avec ce label. Actuellement seul SELinux est supporté
lael Label de sécurité appliqué à cet objet

Ce sont des entrées prises depuis un 'SELECT * FROM pg_seclabel;' d'une base de test:
objoid | classoid | objsubid | provider | label
-------+----------+----------+----------+----------------------------------------------
16390 | 2615 | 0 | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10
16391 | 1259 | 0 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20
16391 | 1259 | 1 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30
16391 | 1259 | 2 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40

La première entrée est le schéma, le second la table elle-même, et les 2 dernières sont les colonnes 1 et 2. Il y a également une vue intégrée pour afficher des détails sur les labels de sécurité appelés pg_seclabels. 'SELECT * FROM pg_seclabels;' pour l'afficher:
objoid | classoid | objsubid | objtype | objnamespace | objname | provider | label
-------+----------+----------+---------+--------------+---------+----------+----------------------------
16390 | 2615 | 0 | schema | 16390 | test_ns | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10
16391 | 1259 | 0 | table | 16390 | test_ns.info | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20
16391 | 1259 | 1 | column | 16390 | test_ns.info.user_name | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30
16391 | 1259 | 2 | column | 16390 | test_ns.info.email_addr| selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40

Support Apache

   Les serveurs Apache sont supportés par SELinux en utilisant les modules de stratégie Apache de la stratégie référence (les modules httpd), cependant il n'y a pas de gestionnaire d'objet Apache. Il y a une librairie partagée qui permet un contrôle d'accès fin en utilisant Apache avec les threads. Le module additionel est appelé mod_selinux.so et supporte le module de stratégie appelé mod_selinux.pp

   mod_selinux utiliser la déclaration typebounds qui a été introduit dans la version 24 de la stratégie. Il permets les threads dans une application multi-thread comme apache d'être lié dans un jeu de permissions définis et le domaine enfant ne peut pas avoir plus de permissions que le domaine parent.

   Ces composants sont connus sous le nom Apache/SELinux Plus. L'objectif de ces services addon Apache est de créer une pile web compatible SELinux. Par exemple, la pile LAPP (Linux, Apache, PostgreSQL, PHP/Perl/Python) a le support suivant:

L Linux support SELinux
A Apache a un support partiel de SELinux
P PostgreSQL supporte SELinux avec SE-PostgreSQL
P PHP/Perl/Python ne sont pas actuellement compatible SELinux, cependant PHP et Python ont un support pour les fonctions de la libselinux: php-pecl-selinux et libselinux-python.

mod_selinux

   Ce module autorise une application web d'être lancé par Apache avec un contexte de sécurité basé sur la stratégie au lieu que le serveur web le traite lui-même. par exemple:

1. Un utitisateur envoie une requête HTTP à Apache qui nécessite les services d'une application web
2. Apache reçois la requête et lance l'instance de l'application web pour effectuer la tâche:

        a) Sans mod_seliunx activé le contexte de sécurité des applications web sont identique au processus apache, il n'y a pas de restriction de privilèges
        b) Avec mod_selinux activé, l'application web est lancée avec le contexte de sécurité définis dans mod_selinux.conf

   L'application web quitte, redonnant le contrôle au serveur web qui répond avec la réponse HTTP.

Limites

Parce que plusieurs threads partagent le même segment mémoire, SELinux ne peut pas vérifier les flux d'informations entre ces différents threads en utilisant setcon(3) avant le kernel 2.6.28. Pour résoudre ce problème la déclaration typebounds a été introduite qui stoppe un thread enfant ayant des privilèges supérieur au thread parent. par exemple la déclaration typebounds et les règles allow:
typebounds httpd_t httpd_child_t;
allow httpd_t etc_t : file { getattr read };
allow httpd_child_t etc_t : file { read write };

   Déclare que le domaine parent (httpd_t) a les permissions file : { getattr read }. Cependant le domaine enfant (httpd_child_t) a les permission file : { read write }. Cela ne sera pas permis par le kernel parce que le parent n'a pas les permissions write, et s'assure que le domaine enfant aura toujours les même permissions ou moins de permissions que le parent.

   Quand setcon(3) est utilisé pour définir un contexte différent dans un nouveau thread sans une déclaration typebounds associée, l'appel retourne 'Operation not permitted' et une entrée SELINUX_ERR est ajoutée au logs d'autid indiquant 'op=security_bounded_transition result_denied' avec les ancien et nouveau contexte.

   S'il y a une déclaration typebounds valide et que le domaine enfant tente d'obtenir un privilège supérieur que le domaine parent est refusé avec une entrée SELINUX_ERR ajoutée dans les log d'audit indiquant 'op=security_compute_av reason=bounds'.

   Le document d'exemple contient 2 démonstrations utilisant setcon(3) avec les threads et comment la déclaration typebounds est utilisée pour autoriser un thread à être exécuté. Il sont localisés dans libselinux/examples et sont:

a) setcon_thread1_example.c - qui appelle setcon dans le processus principal et lance un thread. Si le module setcon_example.conf est chargé et qu'une contexte "unconfined_u:unconfined_r:user_t:s0" est sélectionné, un message d'erreur est affiché: "setcon_raw - ERROR: Operation not permitted"
b) setcon_thread2_example.c - ces fonctions sont similaire, cependant il appel setcon depuis un thread

Fichiers de configuration de SELinux

   Cette section explique chaque fichier de configuration SELinux. Les fichiers de configuration sont classés comme suit:

configuration globale - affecte la stratégie active et les application supportant SELinux, utilitaires et commandes
configuration de stratégie - utilisés par une stratégie active
configuration kernel - localisé sous /sys/fs/selinux et reflète la configuration courante

Migration du magasin de stratégie

   Quand les distributions sont passés à la version 2.4 de libsemanage, libsepol et policycoreutils, le magasin de module de stratégie a été déplacé vers /var/lib/selinux/‹SELINUXTYPE›. Une fois les librairies mis à jours, tous les magasins doivent être migrés avant que toute commande soit exécutée. Une fois la migration complétée, il est possible de construire les stratégies contenant un mix des modules de stratégie référence, modules de langage de stratégie kernel et modules écris en CIL comme dans l'exemple suivant:

Compiler et installer une base et 2 modules écrits en langage kernel
checkmodule -o base.mod base.conf
semodule_package -o base.pp base.mod -f base.fc
checkmodule -m ext_gateway.conf -o ext_gateway.mod
semodule_package -o ext_gateway.pp -m ext_gateway.mod -f gateway.fc
checkmodule -m int_gateway.conf -o int_gateway.mod
semodule_package -o int_gateway.pp -m int_gateway.mod
semodule -s modular-test --priority 100 -i base.pp ext_gateway.pp int_gateway.pp
Compiler et installer un module écrit en CIL
semodule -s modular-test --priority 400 -i custom/int_gateway.cli
Affiche la liste des modules:
semodule -s modular-test --list-modules=full
affiche un listing standard des modules
semodule -s modular-test --list-modules=standard

   Noter l'utilisation de --priority disponible après migration de semodule. Les priorités permettent d'avoir plusieurs modules avec le même nom dans le magasin de stratégie. Le module ayant la priorité la plus haute est incluse dans le binaire kernel final, les autres sont ignorés.

/etc/selinux/config

   Ce fichier est obligatoire, sans lui, ou corrompu, aucune stratégie SELinux n'est chargée et SELinux est désactivé.

/etc/selinux/semanage.conf

   Ce fichier contrôle la configuration et les actions de semanage et semodule.

/etc/selinux/restorecond[-user].conf

   Ces fichiers contient les fichiers et répertoire que restorecond surveille afin de corriger le contexte de sécurité

/etc/selinux/newrole_pam.conf

   Ce fichier est utilisé par la commande newrole et mappe les applications ou commandes en fichiers de configuration PAM. Chaque ligne contient le nom du fichier exécutable suivi par le nom d'un fichier de configuration pam qui existe dans /etc/pam.d

/etc/sestatus.conf

   Utilisé par sestatus pour lister les fichiers et processus dont le contexte de sécurité doit être affiché avec -v.

/etc/security/sepermit.conf

   Fichier de configuration pour le module PAM pam_sepermit

Fichiers de configuration du magasin de stratégie

   /var/lib/selinux/‹policy_name›/modules. Noter qu'il peut y avoir plusieurs magasins de stratégie dans un système, chaque fichier décris dans cette section est relatif à ./‹policy_name›. Ces fichiers sont installés, mis à jours ou construit par semodule et semanage. Les fichiers résultant sont soit copiés dans le répertoire, ou utilisés pour reconstruire la stratégie binaire kernel dans /etc/selinux/‹policy_name›/policy.

modules/ le magasin a 2 fichiers de lock utilisés par libsemanage pour gérer les magasin (semanage.read.LOCK et semanage.trans.LOCK)
modules/active/base.pp Package de stratégie de base qui contient les modules obligatoires et les composants de stratégie tels que les classe objets, déclarations de permission et SID initiaux.
modules/active/base.linked Seulement présent si save-linked vaut TRUE dans semanage.conf. Il contient les modules qui ont été liés avec semodule_link
modules/active/commit_num Fichier binaire utilisé par libsemanage pour gérer les mises à jours dans le magasin.
modules/active/file_contexts.template Contient une copie de toutes les entrées de module 'Labeling Policy File' qui ont été extraits de base.pp et les modules chargeables dans le répertoire modules/active/modules. Ces entrées sont utilisées pour construire les fichiers suivants:

        homedir_template Utilisé pour produire le fichier file_contexts.homedirs qui devient ensuite le fichier contexts/files/file_contexts.homedirs
        file_contexts Qui devient ensuite le fichier contexts/files/file_contexts

   Noter que dans le processus de construction de semanage, ces 2 fichiers on également les fichiers file_contexts.bin et file_contexts.homedirs.bin présents dans contexts/files, dû au fait que semanage nécessite des expression régulière Perl (PCRE). Ils sont générés par sefcontext_compile.

   homedir_template
   file_contexts

Le format du fichier file_contexts.template est comme suit:
pathname_regexp [file_type] opt_security_context

pathname_regexp Une entrée qui définis le chemin qui peut être une expression régulière
file_type Une des entrées optionnelles suivante: -b|c|d|p|l|s|-.
opt_security_context Cette entrée peut être soit le contexte de sécurité, incluant le niveau et plage MLS/MCS, ou la valeur ‹‹none›› pour indiquer que les fichiers qui matchent ne devraient pas être relabélisés

   Les mots clé qui peuvent être dans ce fichier sont:

HOME_ROOT Remplacé par le répertoire racine des répertoires personnels, normalement /home.
HOME_DIR Répertoire des répertoires personnels utilisateurs, défaut /home.
USER Remplacé par le user id
ROLE Remplacé par l'entrée 'prefix' du fichier de configuration users_extra qui correspond au user id des utilisateurs SELinux.

Exemple de file_contexts.template


/. /.. /.config /.hcwd /.local system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0
/nsr(/.*)? system_u:object_r:var_t:s0
/sys(/.*)? system_u:object_r:sysfs_t:s0
...
/etc/ntop.* system_u:object_r:ntop_etc_t:s0
HOME_DIR/.+ system_u:object_r:user_home_t:s0
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0
...
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0
...
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0
...
HOME_ROOT/\.journal ‹‹none››

modules/active/file_contexts Ce fichier devient les fichiers de stratégie contexts/files/file_contexts et est construit depui modules/active/file_contexts.template. Il est ensuite utilisé par les utilitaires de labéling de fichier pour s'assurer que les fichiers et répertoires sont labélisés en accord avec la stratégie.
modules/active/homedir_template Ce fichier est construit depuis les entrées dans le fichier file_contexts.template et utilisé par genhomedircon,semanage login, et semanage user pour générer des entrées utilisateurs dans le fichier file_contexts.homedirs
modules/active/file_contexts.homedirs Ce fichier devient le fichier de stratégie contexts/files/file_contexts.homedirs en construisant la stratégie. Il est ensuite utilisé par les utilitaires de label de fichier pour s'assurer que les répertoires home sont labélisés en accord avec la stratégie.
modules/active/netfilter_contexts & netfilter.local Ces fichiers ne sont pas utilisés pour le moment. Contiennent du code pour produire un fichier netfilter_contexts à utiliser par le services iptables.
modules/active/policy.kern Ce fichier binaire construite pas semanage ou semodule, qui devient la stratégie binaire policy/policy.[ver] qui sera chargé dans le kernel
modules/active/seusers.final & seusers Le fichier seusers.final mappe les utilisateurs GNU/Linux en utilisateurs SELinux et devient le fichier seusers. seusers.final est construit ou modifié en construisant une stratégie ou un fichier optionnel seusers est inclus dans le package de base ou par la commande semanage login.
modules/active/users_extra, users_extra.local, users.local users_extra et users_extra.local sont utilisés pour mapper un préfixe en répertoires personnels utilisateurs, où il est utilisé pour remplacer le mot clé ROLE. Le préfixe est lié à un utilisateur SELinux et devrait refléter le rôle de l'utilisateur. La commande semanage user permet d'ajouter un préfixe. users_extra contient toutes les entrées de préfixe de stratégie, et users_extra.local contient ceux générés par semanage user. users.local est utilisé pour ajouter de nouveaux utilisateurs SELinux à la stratégie sans éditer la stratégie.
modules/active/booleans.local Ce fichier est créé et mis à jours par semanage boolean et maintient les booléens
modules/active/file_contexts.local Ce fichier est créé et mis à jours par semanage fcontext et maintient les informations de contexte de fichiers et répertoires qui ne sont pas fournis par la stratégie core (ex: ne sont pas définis dans des fichiers .fc)
modules/active/interfaces.local Ce fichier est créé et mis à jours par la commande semanage interface et maintient les informations d'interface réseaux qui ne sont pas fournies par la stratégie core (ex: ne sont pas définis dans le fichier base.conf). Les nouvelles informations sont ensuite construites dans la stratégie par la commande semanage. Chaque ligne contient une déclaration netifcon.
modules/active/nodes.local Ce fichier est créé ni mis à jours par la commande semanage node et maintient des informations sur les adresses réseaux qui ne sont pas fournies par la stratégie core (ne sont pas définis dans base.conf). Ces informations sont ensuite construite dans la stratégie par la commande semanage. Chaque ligne contient une déclaration nodecon.
modules/active/ports.local Ce fichier est créé et mis à jours par semanage port et maintient les informations sur les port réseaux qui n'ont pas été fournis par la stratégie core. Chaque ligne contient une déclaration portcon
modules/active/preserve_tunables Ce fichier n'existe que si la stratégie construite préserve les personnalisations.
modules/active/disable_dontaudit Ce fichier n'existe que si la stratégie construite en ayant désactivé les règles dontaudit
modules/active/modules Ce répertoire contient des modules chargeable (‹module_name›.pp ou ‹module_name›.pp.disabled si désactivé) qui ont été construits par la commande semodule_package et placées dans le magasin par les commande semodule ou semanage module -a.

Fichiers de configuration de stratégie

   Chaque fichier dans cette section est relatif à /etc/selinux/‹policy_name›. La majorité des fichiers sont installés par la stratégie référence, semanage ou semodule. Il est possible de construire des stratégie monolitiques personnalisée qui utilisent seulement les fichiers installés dans cette zone (ex: n'utilise pas semanage ou semoduleè).

policy/policy.29 Stratégie binaire chargée dans le kernel
context/files/file_contexts Pour permettre au système de fichier d'être relabelisé
context/dbus_contexts Pour permettre au service de messagerie dbus à fonctionner sous SELinux
context/x_contexts Pour autoriser le service X-Windows à fonctionner sous SELinux

fichier seusers

   Le fichier seusers est utilisé par les programes login et par les utilisateurs GNU/Linux en utilisateurs SELinux. Une séquence de connexion serait:

- En utiliser le userid GNU/Linux, recherche re selinux_id dans ce fichier. S'il n'est pas trouvé, utilise l'entrée __default__
- Pour déterminer le contexte à utiliser, lit contexts/users/[seuser_id]. S'il n'est pas présent:

        - Recherche un contexte par défaut dans contexts/default_contexts. Si aucun contexte par défaut n'est trouvé, lit contexts/failsafe_context pour autoriser un contexte sûr.

   Noter que l'utilisateur system_u est définis dans ce fichier, cependant il ne doit pas y avoir d'utilisateur GNU/Linux system_u dans le système.

Fichiers booleans et booleans.local

   Dépréciés et généralement non présent, ces fichiers gèrent les booléens.

booleans.subs_dist

   Ce fichier, si présent, permet d'allouer de nouveaux noms de booléens dans la stratégie active. Ce fichier a été ajouté parce que beaucoup d'anciennes booléennes commençaient avec 'allow' qui rendait difficile à déterminer ce qu'ils faisaient. Par exemple allow_console_login et plus compréhensible avec login_console_enabled. Si ce fichier est présent, les 2 noms peuvent être utilisés. Chaque ligne est sous la forme policy_bool_name new_name.

setrans.conf

   Ce fichier est utilisé par mcstrands pour traduire les niveaux de stratégies MCS/MLS en labels user friendly.

secolor.conf

   secolor.conf contrôle la couleur associée avec les composant d'un contexte quand les informations sont affichées par SELinux par une application gérant les couleurs.

policy/policy.

   Fichier de stratégie binaire qui est chargé dans le kernel pour forcer la stratégie et est construit par checkpolicy ou semodule. Par convention l'extention du nom de fichier est la version de la base de stratégie utilisée pour construire la stratégie.

contexts/customizable_types

   Ce fichier contient une liste de types qui ne sont pas relabélisés par setfiles ou restorecon. Les commandes vérifient ce fichier avant de relabéliser et exclus ceux dans cette liste sauf si -F est utilisé.

contexts/default_contexts

   Ce fichier est utilisé par les application compatible SELinux pour définir un contexte de sécurité pour les processus utilisateurs (généralement les applications login) où l'identité de l'utilisateur GNU/Linux doit être connu par l'application.

contexts/dbus_contexts

   Ce fichier est pour le service de messagerie dbus qui est utilisé par certaines applications comme KDE. Si SELinux est activé, ce fichier doit exister pour que ces applications puissent fonctionner.

contexts/default_type

   Le fichier permet aux applications comme newrole de sélectionner un type par défaut pour un rôle si aucun n'est fournis.

contexts/failsafe_context

   Le fichier failsafe_context est utilisé quand un process login ne peut déterminer un contexte par défaut à utiliser. Le contenu du fichier est utilisé pour permettre à un administrateur d'accéder au système.

contexts/initrc_context

   Utilisé par la commande run_init pour permettre de démarrer les services système dans le même contexte de sécurité que init.

contexts/lxc_contexts

Ce fichier supporte le labéling des conteneurs lxc dans la librairie libvirt. Le format est le suivant:
process = "security_context"
file = "security_context"
content = "security_context"

process Une entrée qui contient le contexte de sécurité de domaine lxc
file contient le contexte de sécurité de fichier lxc
content Une entrée qui contient le contexte de sécurité de contenu lxc
sandbox_kvm_process
sandbox_lxc_process Ces entrées peuvent être présents

contexts/netfilter_contexts

   Ce fichier supporte le labeling Secmark pour netfilter/iptable. Il n'est pas utilisé actuellement.

contexts/removable_context

   Ce fichier contient un label par défaut pour les périphérique hot-plug qui ne sont pas définis dans contexts/files/media.

contexts/securetty_types

   Utilisé par newrole pour trouver le type à utiliser avec les périphériques tty en changeant les rôles ou niveaux.

contexts/sepgsql_contexts

   Ce fichier contient les contextes de sécurité par défaut pour les objets de base SE-PostgreSQL, décrit dans selabel_db

contexts/systemd_contexts

Ce fichier contient les contextes de fichiers utilisé par les tâches lancées via systemd. Le format est service_class = security_context.Exemple:
runtime=system_u:object_r:systemd_runtime_unit_file_t:s0

contexts/userhelper_context

   Ce fichier contient le contexte de sécurité par défaut utilisé par les applications system-config-*, lancés en root.

contexts/virtual_domain_context

   Ce fichier est utilisé par libvirt et fournis les contextes de domaine qemu disponibles dans la stratégie. Il peut y avoir 2 entrées dans ce fichier, la deuxième étant un contexte alternatif.

contexts/virtual_image_context

   Ce fichier est utilisé par libvirt et fournis les contextes d'image qui sont disponibles dans la stratégie. La première entrée est le contexte de fichier image et la seconde est le contexte du contenu de l'image.

contexts/x_contexts

   Ce fichier fournis les contextes de sécurité par défaut pour l'extension de sécurité SELinux, décris dans selabel_x.

contexts/files/file_contexts

   Ce fichier est géré par semodule et semanage et ne devrait pas être édités. Ce fichier est utilisé par des commandes comme setfiles, fixfiles, matchpathcon, restorecon pour relabéliser parties ou tout un système de fichier.

contexts/files/file_contexts.local

   Ce fichier est géré par semanage fcontext.

contexts/files/file_contexts.homedirs

   Ce fichier est géré par semodule et semanage et ne devrait pas être édité. Il est généré par genhomedircon et utilisé pour définir les contextes de sécurité dans les répertoires personnels.

contexts/files/file_contexts.subs[_dist]

   Ces fichiers permettent des substitutions de noms de fichier pour les fonctions matchpatchcon(3) et selabel_lookup(3).

contexts/files/media

   Ce fichier est utilisé pour mapper les types de média en un contexte de fichier.

contexts/users/[seuser_id]

   Ces fichiers optionnels sont nommés d'après les utilisateurs SELinux qu'ils représentent. Chaque fichier est utilisé pour assigner le contexte de sécurité correct à l'utilisateur, généralement durant le login.

logins/

   Ces fichier optionnels sont utilisés par les application de login pour obtenir un username SELinux et un niveau basé sur l'UID GNU/Linux et le nom du service.

users/local.users

   Généralement le fichier local.users n'est pas présent si semanage est utilisé pour gérer les utilisateurs. Ce fichier contient les définitions des utilisateurs locaux sous la forme de déclarations user.

Langage de stratégie SELinux

   Cette section est une référence des déclarations règles de langage de stratégie.

Langage de stratégie kernel

   Il y a 3 types de base de fichier source de stratégie qui peuvent contenir des déclarations et règle de langage. Ces 3 type sont:

monolitique Simple fichier source qui contient toutes les déclarations. Par convention, il est appelé policy.conf et est compilé par checkpolicy.
base Fichier source obligatoire qui supporte l'infrastructure modulaire. Toute la stratégie système peut être contenu dans ce fichier, cependant il est plus courant d'avoir des fichiers sources de modules chargeable séparés. Par convention ce fichier est appelé base.conf
module Ces fichiers sources optionnels peuvent être chargés dynamiquement dans le magasin de stratégie. Par convention ces fichiers sont nommés d'après le module qu'ils représentent.

   Le tableau ci-dessous affiche l'ordre dans lequel les déclarations devraient apparaître dans les fichiers sources

Déclarations de base et modules
La grammaire du langage définis les déclaration et règles qui peuvent être utilisées dans les types de fichier source. Pour souligner ces règles une indication est incluse dans chaque déclaration et règle pour montrer dans quelles circonstances elle est valide dans un fichier de stratégie source:
Monolithic | Base | Module
Yes/No | Yes/No | Yes/No

Règles de déclaration conditionnelle, optionnelle et requise

La grammaire spécifie quelles déclaration et règles peuvent être incluses dans les déclarations conditionnelles, optionnelles et requise. Pour souligner ces règles une indication est incluse dans chaque déclaration et règle pour montrer dans quelles circonstances chacune est valide dans un fichier de stratégie source:
if | optional | require
Yes/No | Yes/No | Yes/No

Déclarations MLS et composants MLS optionnels

   Quand MLS est activé, il y a d'autres déclaration qui nécessitent le composant MLS comme argument.

Informations générales

1 Les identifiant peuvent généralement être de n'importe quelle longueur mais devraient être restreints aux caractères suivant: [a-zA-Z0-9_]
2 Un '#' indique le début d'un commentaire
3 Toutes les déclarations disponible dans la stratégie version 29 ont été incluses
4 Quand plusieurs entrées source et cible sont affichés en une seul déclaration ou règle, le compilateur étend ces déclaration ou règles individuelles.
5 Certaines déclarations peuvent être ajoutées à une stratégie via le magasin de stratégie en utilisant semanage.
6 Les mots réservés sont:


alias allow and attribute attribute_role auditallow
auditdeny bool category cfalse class clone
common constrain ctrue dom domby dominance
dontaudit else equals false filename filesystem
fscon fs_use_task fs_use_trans fs_use_xattr genfscon h1
h2 identifier if incomp inherits iomemcon
ioportcon ipv4_addr ipv6_addr l1 l2 level
mlsconstrain mlsvalidatetrans module netifcon neverallow nodecon
not notequal number object_r optional or
path pcidevicecon permissive pirqcon policycap portcon
r1 r2 r3 range range_transition require
role roleattribute roles role_transition sameuser sensitivity
sid source t1 t2 t3 target true type typealias
typeattribute typebounds type_change type_member types type_transition
u1 u2 u3 user validatetrans version_identifier
xor default_user default_role default_type default_range low
high low_high

7 La table ci-dessous indique quelles déclarations et règles sont permises dans chaque type de fichier source, et si la déclaration est valide dans une construction if/else, optional {rule_list}, ou require {rule_list}

déclarations et règles de langage permis dans chaque type de fichier source - 1
déclarations et règles de langage permis dans chaque type de fichier source - 2

policycap

Permet d'activer/désactiver de nouvelles capacibility dans le kernel via la stratégie. La déclaration de la définition est:
policycap ‹capability›
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

default_user

Sélectionne l'utilisateur par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
default_user ‹class› ‹source|target›
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

default_role

Sélectionne le rôle par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
default_role ‹class› ‹source|target›
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

default_type

Sélectionne le type par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
default_type ‹classe› ‹source|target›
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

default_range

Sélectionne la plage ou le niveau depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
default_range ‹class› ‹source|target› ‹low,high,low_high›
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

user

La déclaration user déclare un identifiant utilisateur SELinux dans la stratégie et l'associe à un ou plusieurs rôles. La déclaration permet également un niveau ou plage MLS pour contrôler le niveau de sécurité utilisateur. Il est également possible d'ajouter l'id de l'utilisateur SELinux en dehors de la stratégie avec 'semanage user' qui va associer l'utilisateur avec les rôles précédemment déclarés dans la stratégie. La déclaration est:
user ‹seuser_id› roles ‹role_id›
ou pour une stratégie MCS/MLS:
user ‹seuser_id› roles ‹role_id› level ‹mls_level› range ‹mls_range›
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|No|No

role

La déclaration role déclare un identifiant de rôle ou associe un identifiant de rôle à un ou plusieurs types. Lorsqu'il y a plusieurs déclaration role déclarant le même rôle, le compilateur associe les types additionnels avec le rôle. La déclaration est:
role ‹role_id›
role ‹role_id› types ‹type_id›
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes

attribute_role

Déclare un identifiant d'attribut de rôle qui peut être utilisé pour référrer à un groupe de rôles. La déclaration est:
attribute_role attribute_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes

roleattribute

Permet l'association de rôles précédemment déclarés et un ou plusieurs attribute_roles précédemment déclarés. La déclaration est:
roleattribute role_id attribute_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

allow

allow vérifie si une requête pour changer de rôle est permise, si c'est le cas, peut ensuite être suivie par un role_transition. La déclaration est:
allow from_role_id to_role_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

role_transition

Spécifie qu'une transition de rôle est requise. La déclaration est:
role_transition current_role_id type_id : class new_role_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

type

Déclare l'identifiant de type et des identifiants optionnels alias ou attribute associés. La déclaration est:
type type_id [alias alias_id] [, attribute_id];
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|No|Yes

attribute

Déclare un identifiant qui peut ensuite être utilisé pour référrer à un groupe d'identifiant de type. La déclaration est:
attribute attribute_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes

typeattribute

Permet l'association des types précédemment déclarés à un ou plusieurs attributs déclarés. La déclaration est:
typeattribute type_id attribute_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

typealias

Permet l'association d'un type précédemment déclaré à un ou plusieurs identifiants alias (la déclaration type est une alternative). La déclaration est:
typealias type_id alias alias_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

permissive

Permet au domaine nommé d'être lancé en mode permissive au lieu de lancer tous les domaines SELinux en mode permissive. La déclaration est:
permissive type_id;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

type_transition

Spécifie le type par défaut à utiliser pour la transition de domaine ou la création d'objet. Noter qu'une règle allow doit être utilisée pour autoriser la transition. La déclaration est:
type_transition source_type target_type : class default_type object_name;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

type_change

Spécifie un type par défaut en relabélisant un objet existant. Noter qu'une règle allow doit être utilisée pour autoriser l'accès. La déclaration est:
type_change source_type target_type : class change_type;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

type_member

Spécifie un type par défaut en créant un objet polyinstancié. Noter qu'une règle allow doit être utilisée pour autoriser l'accès. La déclaration est:
member_type source_type target_type : class member_type;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

typebounds

Définis une relation hiérarchique entrée les domaines où le domaine lié ne peut pas avoir plus de permission que son domaine parent. La déclaration est:
typebounds bounding_domain bounded_domain;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

allow

Vérifie si l'opération entre le source_type et target_type sont permis pour la classe et les permissions définies. La déclaration est:
allow source_type target_type : class perm_set;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

dontaudit

Stoppe l'audit des messages de refus. Celà aide à gérer les audits en excluant des évènements connus. La déclaration est:
dontaudit source_type target_type : class perm_set;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

auditallow

Audit l'évènement comme un enregistrement utile pour l'audit. Noter que cette règle ne fait qu'auditer l'évènement. Une règle allow est requise. La déclaration est:
auditallow source_type target_type : class perm_set;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No

neverallow

Spécifie qu'une règle allow ne doit pas être générée pour l'opération, même si elle a été autorisée précédemment. La déclaration est:
neverallow source_type target_type : class perm_set;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

class

Hérite et/ou associe les permisdsion à une classe précédemment déclarées. Les classe sont déclarée comme suit:
class class_id
puis
class class_id [ inherits common_set ] [ { perm_set } ]
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes

common

Déclare un identifiant commun et associe une ou plusieurs permissions communes. La déclaration est:
common common_id { perm_set }
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

bool

Définis un identifiant booléen et son état initial utilisable dans une déclaration if. La déclaration est:
bool bool_id default_value;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes

if

Utilisé pour former un block conditionnel de déclaration et règles qui sont forcés en fonction d'un ou plusieurs identifiants booléen. La déclaration est:
if (conditional_expression) { true_list } [ else { false_list } ]
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

constrain

permet de restreindre les permissions pour les classes objet spécifiés en utilisant des expressions booléenness couvrant les types, role et users source et cible. La déclaration est:
constrain class perm_set expression;
    
expression est définis comme suit:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_op r2
| t1 op t2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
    
u1, r1, t1 = user, role, type source
u2, r2, t2 = user, role, type cible
    
op : == | !=
role_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

validatetrans

Seul les classes objets lié au fichier sont supportés par cette déclaration et est utilisée pour contrôler la capacité de changer le contexte de sécurité des objets. La déclaration est:
validatetrans class expression;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

mlsconstrain

Permet de restreindre les permissions pour les classes objets spécifiés en utilisant des expressions booléennes couvrant les types, rôle, utilisateurs source et cible et les niveaux de sécurité. La déclaration est:
mlsconstrain cluss perm_set expression;
    
expression est définis comme suit:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_mls_op r2
| t1 op t2
| l1 role_mls_op l2
| l1 role_mls_op h2
| h1 role_mls_op l2
| h1 role_mls_op h2
| l1 role_mls_op h1
| l2 role_mls_op h2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
    
u1, r1, t1, l1, h1 = user, role, type, low level, high level source
u2, r2, t2, l2, h2 = user, role, type, low level, high level cible
    
op : == | !=
role_mls_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

mlsvalidatetrans

Équivalent MLS de validatetrans et est seulement utilisé pour les classes objets liées aux fichiers, et permet de contrôler la capacité de changer le contexte de sécurité des objets. La déclaration est:
mlsvalidatetrans class expression;
    

expression est définis comme suit:
( expression : expression )
| not expression
| expression and expression
| expression or expression
| u1 op u2
| r1 role_mls_op r2
| t1 op t2
| l1 role_mls_op l2
| l1 role_mls_op h2
| h1 role_mls_op l2
| h1 role_mls_op h2
| l1 role_mls_op h1
| l2 role_mls_op h2
| u1 op names
| u2 op names
| r1 op names
| r2 op names
| t1 op names
| t2 op names
| u3 op names
| r3 op names
| t3 op names
    
u1, r1, t1, l1, h1 = ancien user, role, type, low level, high level
u2, r2, t2, l2, h2 = nouveau user, role, type, low level, high level
u3, r3, t3, l3, h3 = Processus user, role, type, low level, high level
    
op : == | !=
role_mls_op : == | != | eq | dom | domby | incomp
names : name | { name_list }
name_list : name | name_list name
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

Déclarations MLS

L'extension de stratégie MLS ajoute un composant de contexte de sécurité additionnel qui consiste des entrées suivantes:
user:role:type:sensitivity[:category,...]= sensitivity [:category,...]

   Ils consistent d'une sensibilité hiérarchique obligatoire et de catégories non-hiérarchiques. La combinaison des 2 comprennent un niveau ou un niveau de sécurité. En fonction des circonstances, cela peut être un niveau définis ou une plage.

   Pour que les niveaux de sécurité soient plus significatifs, il est possible d'utiliser le service setransd pour les traduire au format humain.

sensitivity

Définis la sensibilité de stratégie MLS et les alias optionnels. La déclaration est:
sensitivity sens_id [alias sensitivityalias_id ...];
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes

dominance

Quand plus d'une déclaration sensitivity sont définies dans une stratégie, une déclaration dominance est requise pour définir la hiérarchie actuelle entre toutes les sensibilités. La déclaration est:
dominance { sensitivity_id ... }
    
La liste est dans l'ordre du plus faible au plus haut.
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

category

La déclaration category définis les identifiants de catégorie de stratégie MLS et les alias optionnels. La déclaration est:
category category_id [alias categoryalias_id ... ];
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes

level

Permet de combiner des sensibilité et les catégories précédemment déclarées en un niveau de sécurité. Noter qu'il doit y avoir seulement une déclaration level pour chaque déclaration sensitivity. La déclaration est:
level sensetivity_id [ :category_id ];
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

range_transition

Principalement utilisée par le processus init ou les commandes d'administration pour s'assurer que les processus fonctionnent avec leur plage MLS correct. La déclaration est:
range_transition source_type target_type : class new_range;
    
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No

sid

Déclare l'identifiant SID actuel et est définis au démarrage d'un fichier source. la délaration sert également à initialiser un contexte de sécurité au SID. La déclaration est:
sid sid_id
sid sid_id context
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

fs_use_xattr

Utilisé pour allouer un contexte de sécurité aux systèmes de fichiers qui supportent l'attribut étendu security.selinux. Le labéling est persistant pour les systèmes de fichiers qui supportent ces attributs étendus, et le contexte de sécurité est ajouté à ces fichiers et répertoires par les commandes SELinux. La déclaration est:
fs_use_xattr fs_name fs_context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

fs_use_task

Utilisé pour allouer un contexte de sécurité à un pseudo système de fichier qui supporte les services liés aux tâches tels que les pipes et les sockets. La déclaration est:
fs_use_task fs_name fs_context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

fs_use_trans

Utilisé pour allouer un contexte de sécurité à des pseudo systèmes de fichier tels que les pseudo terminaux et les objets temporaires. Le contexte assigné est dérivé du processus créateur et du type de systèmed de fichier basé sur les règles de transition. La déclaration est:
fs_use_trans fs_name fs_context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

genfscon

Utilisé pour allouer un contexte de sécurité aux systèmes de fichiers qui ne supportent pas d'autres déclaration de labéling. Généralement un système de fichier a un seul contexte de sécurité par défaut assigné par genfscon depuis '/' qui est ensuit hérité par tous les fichiers et répertoires dans ce système de fichier. /proc est l'exception où les répertoires peuvent être labélisés avec un contexte spécifique. La déclaration est:
genfscon fs_name partial_path fs_context
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

netifcon

Utilisé pour labéliser les objets d'interface réseaux (ex: eth0). La déclaration est:
netifcon netif_id netif_context packet_context
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

nodecon

Utilisé pour labéliser les objets d'adresse réseaux qui représentent des adresse IPv4 et IPv6 et des masques réseaux. La déclaration est:
nodecon subnet netmask node_context
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

portcon

Utilisé pour labéliser les ports udp ou tcp. La déclaration est:
portcon protocol port_number port_context
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

module

Cette déclaration est obligatoire pour les modules chargeables et doit être la première ligne d'un fichier source de stratégie. L'identifiant ne doit pas être en conflit avec d'autres noms de module dans la stratégie. La déclaration est:
module module_name version_number;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

require

La déclaration require est utilisée pour 2 raisons. La première est dans les fichiers sources de module pour indiquer quels composants de stratégie sont requis depuis un fichier de sources externe. Ensuite dans un fichier source de stratégie de base, si précédé par "optional", indique quels composants de stratégie sont requis depuis un fichier source externe. La déclaration est:
require { rule_list }
    
Monolithic | Base | Module: No|Yes|Yes
if | optional | require: Yes|Yes|No

optional

UTilisé pour indiquer quelles déclarations de startégie peuvent ou non être présent dans la stratégie compilée finale. Les déclarations seront inclus dans la stratégie seulement si toutes les déclarations optional peuvent être étendues, ce qui est généralement accomplis en utilisant une déclaration require. La déclaration est:
optional { rule_list } [ else { rule_list } ]
    
Monolithic | Base | Module: No|Yes|Yes
if | optional | require: Yes|Yes|Yes

iomemcon

La déclaration sid déclare l'identifiant SID actuel et est définis au début d'un fichier source de stratégie. La déclaration est:
iomemcon addr context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

ioportcon

La déclaration est:
ioportcon port context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

pcidevicecon

La déclaration est:
pcidevicecon pci_id context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No

pirqcon

la déclaration est:
pirqcon irq context;
    
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/config

/etc/selinux/config



   Ce fichier contrôle l'état de SELinux:

        1. Le status d'application de la stratégie
        2. Le nom de la stratégie et le type qui forment un chemin vers la stratégie à charger
        3. Le comportement au regard des utilisateurs quand la stratégie est chargée
        4. Comment les applications login compatibles SELinux doivent se comporter si aucun utilisateur SELinux n'est configuré
        5. Si le système doit être relabélisé ou non.

OPTIONS

SELINUX Cette entrée indique l'application de la stratégie: enforcing, permissive, ou disabled
SELINUXTYPE Identifie le type de stratégie et doit être le nom d'un répertoir e sous /etc/selinux.
REQUIREUSERS (bool) Permet d'échouer un login s'il n'y a pas de match en d'entrée par défaut dans le fichier seusers
AUTORELABEL (bool) à 0, s'il existe un fichier .autorelabel dans le répertoire racine, alors le loader donne un shell où root peut manuellement relabéliser le système de fichier. À 1 et un fichier .autorelabel, le système relabélise automatiquement en utilisant fixfiles -F restore
^
04 mai 2017

htmlpdflatexmanmd




semanage

semanage

Outil de gestion de stratégie SELinux

   semanage est utilisé pour configurer certains éléments de la stratégie SELinux sant nécessiter de modification ou recompilation. Cela inclus le mappage des usernames linux en user SELinux et les mappages de contexte de sécurité pour divers types d'objet. semanage possède les sous-commandes suivantes:

import Importer des personnalisations locales
export Exporte des personnalisations locales
login Gérer les mappages entre les users Linux et SELinux
port Gérer les définitions de type de port réseau
interface Gérer les définitions de type d'interface réseau
module Gérer les modules de stratégie SELinux
node Gérer les définitions de type de nœud réseau
fcontext Gérer les définitions de mappage de contexte de fichier
boolean Gérer les booléens pour activer des fonctionnalités
permissive Gérer le mode d'enforcement
dontaudit Active/désactive les rèoles dontaudit dans la stratégie

^
04 mai 2017

htmlpdflatexmanmd




semanage-boolean

semanage-boolean

Gestion des booléen SELinux

   semanage boolean contrôle les paramètres booléens dans la stratégie SELinux.

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-1, --on active le booléen
-0, --off Désactive le booléen

Exemples

Active le booléen apache peut envoyer un mail
semanage boolean -m --on httpd_can_sendmail
lister les booléens personnalisés
semanage boolean -l -C
^
04 mai 2017

htmlpdflatexmanmd




semanage-dontaudit

semanage-dontaudit

Gestion dontaudit

   semanage dontaudit active/désactive les règles dontaudit dans la stratégie. Désactiver les règles dontaudit permet de vois si le kernel bloque un accès

OPTIONS

-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif

Exemples

Désactiver les règles dontaudit:
semanage dontaudit off
^
04 mai 2017

htmlpdflatexmanmd




semanage-export

semanage-export

Exporter des modifications SELinux

   semanage import et export peuvent être utilisés pour extraire les modifications SELinux d'une machine et les appliquer sur une autre.

OPTIONS

-S STORE, --store STORE Magasin alternatif
-f OUTPUT_FILE, --output_file OUTPUT_FILE Fichier de sortie

Exemples

Appliquer les modification à une autre machine:
semanage export -f semanage.mods
scp semanag.mod remodemachine:
ssh remodemachine
semange -import -f semanage.mods
^
04 mai 2017

htmlpdflatexmanmd




semanage-fcontext

semanage-fcontext

Gestion des contextes de fichier

   semanage fcontext est utilisé pour gérer les labels de système de fichier par défaut dans un système SELinux. Cette commande mappe les chemins de fichier en utilisant des expressions régulières en labels SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-e EQUAL, --equal EQUAL Substitue le chemin cible avec le sourcepath en générant le label par défaut.
-f [{a,f,d,c,b,s,l,p}], --ftype [{a,f,d,c,b,s,l,p}] Type de fichier.
-s SEUSER, --seuser SEUSER Nom de l'utilisateur SELinux
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS

Exemples

Ajoute un contexte de fichie pour tous les fichiers sous /web
semanage fcontext -a -t httpd_sys_content_t "/web[/.*)?"
restorecon -R -v /web
Substituer /home1 avec /home en définissant le contexte de fichier
semanage fcontext -a -e /home /home1
restorecon -R -v /home1
Pour les répertoires personnels sou le répertoire racine (ex: /disk6/home), exécuter les commandes suivantes:
semanage fcontext -a -t home_root_t "/disk6"
semanage fcontext -a -e /home /disk6/home
restorecon -R -v /disk6
^
04 mai 2017

htmlpdflatexmanmd




semanage-import

semanage-import

Importer des modifications SELinux

   semanage import et export peuvent être utilisés pour extraire les modifications SELinux d'une machine et les appliquer sur une autre.

OPTIONS

-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif
-f INPUT_FILE, --input_file INPUT_FILE Fichier d'entrée
^
04 mai 2017

htmlpdflatexmanmd




semanage-interface

semanage-interface

Outil de gestion d'interface réseaux

   semanage interface contrôle les labels assignés aux interfaces réseaux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
^
04 mai 2017

htmlpdflatexmanmd




semanage-login

semanage-login

Gestion des mappages des utilisateurs Linux et SELinux

   semanage login contrôle le mappage entre un utilisateur Linux et un utilisateur SELinux. Il peut être utilisé pour activer des utilisateurs confinés. Par exemple on peurrait définis qu'un utilisateur particulier ou un groupe d'utilisateurs vont se logger dans un système en tant que user_u. Préfixer un nom de groupe avec '%'.

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-s SEUSER, --seuser SEUSER Nom d'utilisateur SELinux
-r RANGE, --range RANGE plage MLS/MCS

Exemples

Modifier l'utilisateur default dans le système en guest_u
semanage login -m -s guest_u __default__
assigner à l'utilisateur gijoe dans une machine MLS une plage et l'utilisateur staff_u
semanage login -a -s staff_u -rSystemLow-Secret gijoe
assigner tous les utilisateurs du groupe engineering à l'utilisateur staff_u
semanage login -a -s staff_u %engineering
^
04 mai 2017

htmlpdflatexmanmd




semanage-module

semanage-module

Installe, supprime et désactive les modules de stratégie SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-r, --remove Supprime le module spécifié
-d, --disable Désactive le module spécifié
-e, --enable Active le module spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
^
04 mai 2017

htmlpdflatexmanmd




semanage-node

semanage-node

Contrôle les adresses IP en définition de type de nœud

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
-p PROTO, --proto PROTO Protocole pour le port spécifié (tcp|udp) ou version du protocole internet pour le nœud spécifié (ipv4|ipv6)
-M NETMASK, --netmask NETMASK Masque de sous-réseau
^
04 mai 2017

htmlpdflatexmanmd




semanage-permissive

semanage-permissive

Gestion des mappages permissifs

   semanage permissive ajoute ou supprime un module permissif de stratégie SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié

Exemples

Lister tous les modules permissifs
semanage permissive -l
faire de httpd_t un domaine permissif
semanage permissive -a httpd_t
^
04 mai 2017

htmlpdflatexmanmd




semanage-port

semanage-port

Outil de gestion de mappage de port

   semanage port contrôle le numéro de port en définitions de type de port

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
-p PROTO, --proto PROTO Protocole pour le port spécifié (tcp|udp) ou version du protocole internet pour le nœud spécifié (ipv4|ipv6)

Exemples

Lister toutes les définitions de port
semanage port -l
autoriser Apache à écouter sur tcp port 81
semanage port -a -t http_port_t -p tcp 81
autoriser sshd à écouter sur le port tcp 8991
semanage port -a -t ssh_port_t -p tcp 8991
^
04 mai 2017

htmlpdflatexmanmd




semanage.conf

semanage.conf

Fichier de configuration global pour la libraire de gestion SELinux

OPTIONS

module-store Spécifie comment la libraire interagit avec le magasin de stratégie SELinux

        direct Écris directement dans le magasin de stratégie (défaut)
        ‹socket path› Chemin absolu vers un socket utilisé pour se connecter au serveur de gestion de stratégie
        ‹server name› Nom et port d'un serveur de gestion de stratégie utilisé sur TCP.

root Chemin racine alternatif pour le magasin. Défaut: /
store-root Chemin racine du magasin alternatif. Défaut: /var/lib/selinux
compiler-directory Répertoire alternatif contenant les compilateurs HLL vers CIL. Défaut: /usr/libexec/selinux/hll
ignore-module-cache true|false ignore ou non le cache des modules CIL compilés depuis HLL. Défaut: false.
policy-version en générant la stratégie, semanage défini POLICYDB_VERSION_MAX tel que définis dans ‹sepol/policydb/policydb.h›. Ce paramètre permet de définir une autre versions
target-platform 0|1 Vérifie ou non les règles neverallow en exécutant la commande semanage. Défaut: 1
file-mode Par défaut le mode de permission pour les fichiers de stratégie temps-réer est à 0644
save-previous true|false Contrôle si le répertoire du module précédent est sauvé après être validé avec succès dans le magasin de stratégie. Défaut: false (la version précédente est supprimée)
save-linked true|false Contrôle si le module lié précédent est sauvé (avec le nom base.linked) une fois correctement chargé dans le magasin de stratégie. Défaut: false (le module précédent est supprimé)
ignoredirs Liste de répertoires séparés par des ';' de répertoires à ignorer en définisant les répertoires personnels utilisateur.
usepasswd true|false Active l'utilisation de getpwent() pour obtenir une liste de répertoire home à labéliser. défaut: true
disable-genhomedircon true|false Contrôle si la fonction genhomedircon est exécutée avec la commande semanage. Défaut: false
handle-unknown deny|reject|allow Contrôle le comportement du kernel pour gérer les permisssions définies dans le kernel, mais manquante dans la stratégie courante.
bzip-blocksize [0-9] 0-pas de compression. Défaut: 9
bzip-small true|false indique si l'algorithme bzip tente de réduire son utilisation mémoire. Défaut: false
remove-hll true|false à true, les fichiers HLL seront supprimés après recompilation dans CIL.
^
07 mai 2017

htmlpdflatexmanmd




semodule

semodule

Gérer les modules de stratégie SELinux

   semodule est l'outil utilisé pour gérer les modules de stratégie SELinux, incluant l'installation, la mise à jours, le listing et la suppression des modules. semodule peut également être utilisé pour reconstruire une stratégie depuis un magasin de module et/ou forcer à recharger une stratégie sans effectuer d'autre transactions. semodule agit sur les paquets de module créés par semodule_package. Par convention, ces fichiers ont un suffixe .pp (policy package).

OPTIONS

-R, --reload Force à recharger une stratégie
-B, --build Force à reconstruire une stratégie (recharge également sauf si -n)
-D, --disable_dontaudit Supprime temporairement dontaudits de la stratégie
-i, --install=MODULE_PKG Install/remplace un paquet module
-r, --remove=MODULE_NAME Supprime un module existant
-l[KIND], --liste-modules[=KIND] Affiche une liste des modules installés
-E, --extract=MODULE_PKG Extrait un module du magasin comme fichier HLL ou CIL dans le répertoire courant.

KIND

        standard Liste la plus haut priorité
        full Liste tous les modules

-X,--priority=PRIORITY Définis la priorité pour les opérations qui suivent (1-999)
-e, --enabled=MODULE_NAME Active un module
-d, --disable=MODULE_NAME désactive un module
-s, --store Nom du magasin à utiliser pour les opérations
-n, --noreload, -N ne pas recharger la stratégie
-p, --preserve_tunables préserve tunables in policy
-C, --ignore-module-cache Recompile les module CIL construis depuis les fichiers HLL
-p, --path Chemin alternatif pour la racine de stratégie
-S, --store-path Chemin alternatif pour la racine du magasin de stratégie
-v, --verbose mode verbeux
-c, --cil Extrait le module comme fichier CIL
-H, --hll Extrait le module comme fichier HLL

Exemples

Installer ou remplacer un paquet de stratégie de base
semodule -b base.pp
installer ou remplacer un paquet de stratégie non base
semodule -i httpd.pp
Lister les module non de base
semodule -l
Activer tous les messages AVC pour lesquels SELinux est actuellement en 'dontaudit'
semodule -DB
Réapplique les règles 'dontaudit'
semodule -B
Installer ou remplacer tous les modules non-base dans le répertoire courant
semodule -i *.pp
Installer ou remplacer tous les modules dans le répertoire courant
ls *.pp | grep -Ev "base.pp|enableaudit.pp" | xargs /usr/sbin/semodule -b base.pp -i
Désactiver un module
semodule -d alsa
Installer un module avec une priorité spcifique
semodule -X 100 -i alsa.pp
Lister tous les modules
semodule --list=full
Définir un chemin alternatif pour la racine des stratégie
semodule -B -p "/tmp"
Écris la version HLL de puppet et la version CIL de wireshark
semodule -X 400 -E puppet --cil -E wireshark
^
08 mai 2017

htmlpdflatexmanmd




/etc/security/sepermit.conf

/etc/security/sepermit.conf

fichier de configuration pour pam_sepermit

   Les lignes sont sous la forme ‹user›[:‹option›:‹option›...]. Un utilisateur peut être un username, un @group, ou un utilisateur SELinux (%seuser)

OPTIONS

exclusive Seul une session login est permise pour l'utilisateur et les processus de l'utilisateur seront tués au logout
ignore Le module ne retourne jamais PAM_SUCCESS pour l'utilisateur. Il retourne PAM_IGNORE si SELinux est en mode enforcing, PAM_AUTH_ERR sinon. Utile pour supporter les utilisateurs invités sans mot de passe et des utilisateurs confinés sans mot de passe simultanément.
^
15 juillet 2010

htmlpdflatexmanmd




seq

seq

Affiche une séquence numérique sur stdout

   seq affiche les nombres du premier au dernier, par incrément. Si l'incrément n'est pas spécifié, le défaut est 1. Si un seul argument est spécifié, il commence à 1, par incrément de 1, jusqu'à la valeur spécifiée.

OPTIONS

-f FORMAT, --format=FORMAT Affiche tous les nombres en utilisant le format spécifié. Il doit contenir des conversion style printf : %a, %e, %f, %g, %A, %E, %F, %G. Le % peut être suivie par des flags parmis : '-+=0' et une largeur optionnelle, et enfin une précision consistant d'un '.' suivi optionnellement par une valeur. le format par défaut est %.Pf
-s STRING, --separator=STRING Sépare les nombres par la chaîne spécifiée. newline par défaut. La sortie se termine toujours par un newline.
-w, --equal-width Affiche tous les nombres avec la même largeur

Exemples

Affiner la sortie avec -f:
seq -f '(%9.2E)' -9e5 1.1e6 1.3e6
Afficher la sortie en hexad:
printf '%x\n' `seq 1048575 1024 1050623`
pour les très longues liste de nombre, utiliser xargs pour éviter les limitations système sur la longueur de la liste des arguments:
seq 1000000 | xargs printf '%x\n' | tail -n 3
^
15 mars 2010

htmlpdflatexmanmd




Serveur de dépôt de paquets deb

Serveur de dépôt de paquets deb

Création d'un serveur de dépôt

   Pour créer un serveur de dépôt, il est nécessaire d'avoir un serveur web. Créer une arborescence pour le dépôt:

Exemple

/var/www/debian/dists/lenny/main/binary-i386
/var/www/debian/dists/lenny/main/source

Si vous possédez les fichiers suivant pour un programme:
paquet.orig.tar.gz
pauet.diff.gz
paquet.dsc
paquet.changes
paquet.deb

placer les fichiers paquet.dsc et paquet.deb dans binary-i386
placer les fichiers paquet.dsc, paquet.diff.gz et paquet.orig.tar.gz dans source

Il faut ensuite générer 2 fichiers, Packages.gz et Sources.gz:
cd /var/www/debian/dists/lenny/main
dpkg-scanpackages binary-i386 /dev/null dists/lenny/main/ | gzip -f9 › binary-i386/Packages.gz
dpkg-scansources source /dev/null dists/lenny/main/ | gzip -f9 › source/Sources.gz

   ensuite il faut créer 2 fichiers de description pour le dépôt. Ils sont identiques, et pour chaque paquet:

dans binary-i386/Realease
Archive: stable
Version: 5.0.4
Component: main
Origin: paquet
Label: paquet
Architecture: i386

et dans lenny/Release, le fichier est identique. ici un exemple plus complet:
Archive: stable
Version: 5.0.4
Codename: lenny
Component: main source contrib non-free
Origin: paquet
Label: paquet
Architecture: i386 amd64
Description: Debian 5.0.4 Released 2010

Pour que les client puissent utiliser ce dépôt, ajouter dans /etc/apt/sources.list:
deb http://www.mon-site.com/debian lenny main
deb-src http://www.site.mon-site.com/debian lenny main

^
07 mai 2017

htmlpdflatexmanmd




service_seusers

service_seusers

Fichiers de configuration de mappage d'utilisateur et service en utilisateur SELinux

   Ces fichiers sont optionnels et permettent aux services de définir un utilisateur SELinux à l'authentification. Il y a un fichier pour chaque utilisateur GNU/Linux qui est requis pour lancer un service avec un username SELinux spécifique. Chaque ligne a le format service:seuser[:range]

service Le nom du service utilisé par l'application
seuser Le nom d'utilisateur SELinux
range La plage MCS/MLS

Exemple


# ./logins/root
ipa:user_u:s0
this_service:unconfined_u:s0
    
# ./logins/rch
ipa:unconfined_u:s0
that_service:unconfined_u:s0
^
01 janvier 2014

htmlpdflatexmanmd




sessreg

sessreg

Programme pour gérer les entrées utmp/wtmp et lastlog pour les sessions xdm

OPTIONS

-w wtmp-file Fichier wtmp alternatif au lieu de /var/log/wtmp. "none" désactive l'écriture dans le fichier
-u utmp-file Fichier utmp alternatif au lieu de /var/log/utmp. "none" désactive l'écriture dans le fichier
-L lastlog-file Fichier lastlog alternatif au lieu de /var/log/lastlog. "none" désactive l'écriture dans le fichier
-l line-name Décris le nom de ligne de l'entrée. Pour les sessions terminal, c'est le nom du périphérique (ex: ttyd0). pour les sessions X, devrait être le nom de l'afficheur local (ex: 0)
-x Xservers-file Contient pour chaque afficheur, le slot-number (nombre de lignes dans le ttys-file) et l'index dans ce fichier où line-name est trouvé
-t ttys-file Fichier alternatif qui -x utilisé pour compter le nombre de sessions terminal sur un hôte
-a Cette session devrait être ajoutée au utmp/wtmp
-d Cette session devrait être supprimée de utmp/wtmp
^
07 mai 2017

htmlpdflatexmanmd




sestatus

sestatus

Outils de status SELinux

   sestatus est utilisé pour obtenir le status d'un système avec SELinux

OPTIONS

-v Affiche les fichiers de contexte des fichiers et processus listés dans /etc/sestatus.conf
-b Affiche l'état courant des booléens
^
07 mai 2017

htmlpdflatexmanmd




/etc/sestatus.conf

/etc/sestatus.conf

Fichier de configuration pour sestatus

   sestatus -v utilise ce fichier pour déterminer quel contexte de sécurité de fichier et processus devraient être affichés. Le fichier consiste de 2 sections optionnelles [files] et [process].

[files] Début d'une liste de fichier
file_name Un ou plusieurs noms de fichiers complet, chacun sur une ligne, dont le contexte sera affiché. Si le fichier n'existe pas il est ignoré. Si c'est un lien symbolique, affihe le contexte de la cible
[process] Début d'une liste de processus
executable_file_name Un ou plusieurs fichiers exécutable complet qui devraient être dans un processus actif, et dont le contexte sera affiché.

Exemples


[files]
/etc/passwd
/etc/shadow
/bin/bash
/bin/login
/lib/libc.so.6
/lib/ld-linux.so.2
/lib/ld.so.1
    
[process]
/sbin/mingetty
/sbin/agetty
/usr/sbin/sshd
^
05 septembre 2015

htmlpdflatexmanmd




setcap

setcap

Définir les capabilities d'un fichier

   En l'absence de l'option -v, setcap définis les capabilities de chaque fichier spécifié avec les capabilities spécifiées. L'options -v est utilisé pour vérifier que les capabilities sont actuellement associées avec le fichier

   Les capabilities sont spécifiées sous la forme décrite dans cap_from_text(3)

   La chaîne de capabilities spéciale '-' peut être utilisé pour indiquer que les capabilities sont lues depuis l'entrée standard. Dans de tels cas, le jeu de capabilities est terminé avec une ligne blanche.

   La chaîne de capabilities spéciale 'r' est utilisé pour supprimer un jeu de capabilities d'un fichier

   le flag -q est utilisé pour augmenter la verbosité de la sortie.

^
29 août 2015

htmlpdflatexmanmd




setfacl

setfacl

Définis les listes de contrôle d'accès des fichiers

   Cet utilitaire définis les ACL des fichiers et répertoires. Sur la ligne de commande, une séquence de commande est suivie par une séquence de fichiers (qui peut être suivis par une autre séquence de commandes, ...).

   Les options -m et -x s'attendent à une ACL sur la ligne de commande. Plusieurs entrées d'acl sont séparés par des ','. Les options -M et -X lisent une ACL depuis un fichier ou l'entrée standard.

   Les options --set et --set-file définissent l'ACL d'un fichier ou un répertoire. L'ACL précédente est remplacée. Les entrées d'ACL pour cette opération doivent inclure les permissions.

   Les options -m (--modify) et -M (--modify-file) modifient l'ACL d'un fichie ou répertoire. Les entrées d'ACL pour cette opération doivent inclure les permissions.

   les options -x (--remove) et -X (--remove-file) suppriment les entrée d'ACL. Ce n'est pas une erreur de supprimer une entrée qui n'existe pas. Seules les entrées d'ACL dans le champ perms sont acceptés, sauf si POSIXLY_CORRECT est définis.

   En lisant les fichiers avec les options -M et -X, setfacl accepte les productions de getfacl. Il y a plus d'une entrée d'ACL par ligne.

   Si setfacl est utilisé dans un système de fichier qui ne supporte pas les ACL, setfacl opère sur les bits de permission des fichiers. Si l'ACL ne contient pas tous les bits de permission, setfacl modifie les bits de permission pour refléter les ACL le plus proche possible, écrit un message sur stderr, et retourne avec un status supérieur à 0.

Permissions

   Le propriétaire du fichier et les processus capable de CAP_FOWNER ont le droit de modifier les ACL d'un fichier. C'est analogue aux permissions requises pour accéder au mode de fichier. (dans les système Linux, root est le seul utilisateur avec la capacité CAP_FOWNER)

OPTIONS

-b, --remove-all Supprime toutes les entrée d'ACL étendues. Les entrées d'ACL de base du propriétaire, groupe et autre sont conservés.
-k, --remove-default Supprime toutes les ACL par défaut.
-n, --no-mask Ne recalcule pas le masque de permissions effectives
--mask Recalcule le masque de permissions effectives, même si une entrée de mask a été explicitement donné.
-d, --default Toutes les opérations s'appliquent sur l'ACL par défaut. Les entrées d'ACL régulières dans le jeu d'entrée sont transformés en entrée d'ACL par défaut.
--restore-file Restaure un backup de permissions créé par getfacl -R ou similaire. Toutes les permissions de l'arborescence sont restaurés en utilisant ce mécanisme. Si l'entrée contient le propriétaire et le groupe, setfacl tente de restaurer le propriétaire et le groupe. Si l'entrée contient des flags (qui définissent le setuid, setgid, et sticky bits), setfacl définis ces 3 bits en fonction; sinon il est supprime.
--test Mode simulation. Liste les ACL résultantes.
-R, --recursive Applique les opérations à tous les fichiers et répertoires récursivement. Cette option ne peut pas être mixé avec --restore.
-L, --logical Mode logique, traverse les liens symboliques. Seulement avec -R. ne peut pas être utilisé avec --restore.
-P, --physical Mode physique, ne traverse pas les liens symboliques. Seulement avec -R. ne peut pas être utilisé avec --restore.
-- Fin des options de la ligne de commande
Si un paramètre est un '-', lis depuis l'entrée standard

Entrées d'ACL

   L'utilitaire setfacl reconnaît les formats d'entrée d'ACL suivantes (de blanc ont été inséré pour plus de clarté):

Permissions d'un utilisateur nommé. Permissions du propriétaire du fichier si l'uid est vide
[d[efault]:] [u[ser]:]uid [:perms]
Permissions du groupe nommé. Permissions du groupe propriétaire si gid est vide
[d[efault]:] g[roup]:gid [:perms]
Masque de droits effectifs
[d[efault]:] m[ask][:] [:perms]
Permissions pour les autres
[d[efault]:] o[ther][:] [:perms]

   Les espaces blanc entre les caractères de délimitation sont ignorés. Les entrée d'ACL propre incluant les permissions sont utilisées dans les opérations modify et set. (les options -m, -M, --set et --set-file). Les entrées sans le champ perms sont utilisé pour la suppression des entrées (options -x et -X).

   Pour uid et gid, vous pouvez spécifier soit un nom, soit un nombre.

   Le champ perms est une combinaison des caractères qui indiquent les permissions: read (r), write (w), execute (x). perms peut également être un chiffre octal.

Entrées créées automatiquement

   Initialement, les fichiers et répertoires ne contiennent que les 3 entrées d'ACL de base. Il y a certaines règles qui doivent être satisfaites pour une ACL soit valide:

- Les 3 entrées de base ne peuvent pas être supprimés.
- Quand une ACL contient des entrées d'utilisateurs nommés ou des groupes nommés, elle doit également contenir un masque de droits effectifs.
- Quand une ACL contient des entrées d'ACL par défaut, les 3 entrées de base doivent également exister.
- Quand une ACL par défaut contient des entrées user et group nommés, elle doit également contenir un masque de droits effectifs.

   Pour aider l'utilisateur à s'assurer de ses règles, setfacl créé des entrées des entrées existantes sous certaines conditions.

- Si une ACL contient des entrées user et group nommés, et qu'aucun mask n'existe, une entrée mask contient les même permission que l'entrée group créé. Sauf si -n est donné, les permission de l'entrée mask sont ensuite ajustés pour inclure l'union de toutes les permissions affectées par l'entrée de mask.
- Si une ACL par défaut est créé, et qu'elle ne contient pas de propriétaire, groupe, ou other, une copie de l'ACL sont ajoutés à l'ACL par défaut.
- Si une ACL par défaut contient des entrées utilisateur ou groupes nommés, et qu'aucun mask n'existe, une entrée mask contenant les même permissions que que l'entrée de groupe de l'ACL par défaut est ajouté. Sauf si -n est donné, les permission de l'entrée mask sont ensuite ajustés pour inclure l'union de toutes les permissions affectées par l'entrée de mask.

Exemples

Ajouter un droit de lecture à un utilisateur
setfacl -m u:lisa:r file
révoquer l'accès en écriture à tous les groupes et tous les utilisateurs nommés en utilisant le masque de droits effectifs
setfacs -m m::rx file
Supprimer une entrée de groupe nommé de l'ACL du fichier
setfacl -x g:staff file
Copier l'ACL d'un fichier dans un autre
getfacl file1 | setfacl --set-file=- file2
copier l'ACL d'accès dans l'ACL par défaut
getfacl --access dir | serfacl -d -M- dir
^
05 septembre 2015

htmlpdflatexmanmd




setfattr

setfattr

Définit les attributs étendus des objets de système de fichier

OPTIONS

name, --name=name Spécifie le nom de l'attribut étendu à définir
-v value, --value=value Spécifie la nouvelle valeur de l'attribut étendu. Il y a 3 méthodes disponible pour encoder la valeur. Si la chaîne est entre guillemets, la chaîne est traité comme texte. Dans ce cas, les '\' et guillemets ont une signification spéciale et doivent être échappés. Si la chaîne commence par 0x ou 0X, elle est exprimée en hexadécimal. Si la chaîne commence pas 0s ou 0S, elle est considérée comme base64.
-x name, --remove=name Supprime l'attribut nommé entièrement
-h, --no-dereference Ne suit pas les liens.
--restore=file Restaure les attributs étendus du fichier. Le fichier doit être au format généré par la commande getfatr avec l'option --dump. Si l'argument est un '-', lit depuis l'entrée standard.
^
28 août 2015

htmlpdflatexmanmd




setquota

setquota

Définis les quotas disque

   setquota est un éditeur en ligne de commande. Le système de fichier, nom d'utilisateur/groupe et les nouveaux quotas pour ce système de fichier peuvent être spécifié sur la ligne de commande.

OPTIONS

-r, --remote Édite également les quota non-locaux en utilisant rpc.rquotad sur le serveur distant. Cette option est disponible seulement si les outils de quotas ont été compilés avec le support sur RPC.
-m, --no-mixed-pathnames Actuellement, les chemins des points de montage NFS4 sont envoyés sans le dernier '/'. rpc.rquotad l'utilise pour reconnaître les montages NFS4. Cette option envoie toujours des chemin avec le dernier '/'.
-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-g, --group Manipule les quotas utilisateur
-u, --user Manipule les quotas de groupe
-p, --prototype=protoname Duplique les quotas de l'utilisateur de prototype spécifié pour chaque utilisateur spécifié. C'est le mécanisme normal utilisé pour initialiser les quotas pour les utilisateurs et les groupes.
--always-resolve Tente toujours de traduire les user/group en uid/gid même si le nom est composé de chiffre uniquement.
-b, --batch Lit les informations pour définis depuis stdin (le format d'entrée est: name block-softlimit block-hardlimit inode-softlimit inode-hardlimit ).
-c, --continue-batch En parsant une ligne d'entrée en mode batch, continue le traitement avec la prochaine ligne.
-t, --edit-period Période de grâce pour les utilisateurs/groupes.
-T, --edit-times Altère les temps, pour les utilisateurs/groupes individuels quand softlimit est forcé.
-a, --all Traverse tous les systèmes de fichier avec les quota dans /etc/mtab.

   Pour désactiver un quota, définir le paramètre correspondant à 0. Seul root peut éditer les quotas.
^
08 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/setrans.conf

/etc/selinux/‹SELINUXTYPE›/setrans.conf

Fichier de configuration de traduction pour les systèmes SELinux MCS/MLS

   Ce fichier spécifie la manière dont les labels MCS/MLS sont traduits sous forme lisible par l'homme par les service mcstransd. Les stratégies par défaut ne supportent que 16 niveaux de sensibilité (s0 à s15) et 1024 catégories (c0 à c1023). Plusieurs catégories peuvent être séparés par des ',' et une plage de catégorie peut être raccourcie en utilisant un '.'

Mots clés

Base Une fois une base déclarée, les définitions de label suivant possèderont tous ces modificateurs durant la traduction.
Default Définit le bit de plage de catégorie utilisé pour les bits inverses
Domain Créé un nouveau domaine avec le nom fournis
Include Lit et traite le contenu du fichier de configuration spécifié
Join Définis un caractère utilisé pour séparer les membres d'un ModifierGroup
ModifierGroup Un moyen de grouper des définitions de bit de catégorie par la manière dont ils modifient le label de sensibilité
Prefix Mot(s) préfixe qui peuvent précéder les membres d'un modifiergroup
Suffix Mot(s) suffixe qui peuvent suivre les membres d'un modifiergroup
Whitespace Définis le jeu de caractère d'espace blanc acceptables qui peuvent être utilisé dans les labels traduits

Exemples de définition de niveau de sensibilité
s0=SystemLow
Définis une traduction de s0 (le niveau de sensibilité la plus faible) sans catégorie.
s15:c0.c1023=SystemHigh
Définis une traduction de s15:c0.c1023 en system SystemHigh. c0.c1023 est un raccourcis pour toutes les catégories.
s0-s15:c0.c1023=SystemLow-SystemHigh
Définis une traduction de s0-s15:c0.c1023 en SystemLow-SystemHigh.
s0:c0=PatientRecord
Définis une traduction de la sensibilité s0 avec la catégorie c0 en PatientRecord
s0:c1*Accounting
Définis une traduction de la sensibilité s0 avec la catégorie c1 en Accounting
s2:c1,c2,c3=Confidential3Categories
s2:c1.c3=Confidential3Categories
Définissent une traduction de la sensibilité s2 avec les catégories c1, c2 et c3 en Confidential3Categories
s5=TopSecret
Définis une traduction de la sensibilité s5 sans catégorie en TopSecret

Exemples de contraintes
c0!c1 Si les bits de catégorie 0 et 1 sont mis, la contrainte échoue et le contexte original est retourné
c5.c9›c1
Si les bits 5 à 9 sont mis et le niveau de sensibilité s1, la contrainte échoue
s1!c5,c9
Si les bits 5 et 9 sont mis et le niveau de sensibilité est s1, la contrainte échoue.
^
03 février 2016

htmlpdflatexmanmd




setsid

setsid

Lancer un programme dans une nouvelle session

-c, --ctty Définis le terminal de contrôle à celui actuel
-w, --wait Attends la fin de l'exécution du programme, puis renvoyer le code de retour de ce programme comme valeur de retour de setsid

^
01 janvier 2014

htmlpdflatexmanmd




setxkbmap

setxkbmap

Map le clavier pour utiliser le layout déterminé par les options spécifiés sur la ligne de commande.

   Un XKB keymap est construit depuis un nombre de composants qui sont compilés seulement si nécessaire. La source pour tous les composants sont dans /usr/share/X11/xkb

OPTIONS

-compat Spécifie le nom du composant de map de compatibilité utilisé pour construire un layout.
-config file Spécifie le nom d'un fichier de configuration xkb qui décrit le clavier à utiliser
-device device Spécifie l'id du périphérique à mettre à jours
-display display Nom du serveur X à utiliser
-geometry name Spécifie le nom de géométrie utilisé pour construire le layout
-l directory Ajoute un répertoire à la liste de répertoires à utiliser pour rechercher un keyboard layout
-keycodes name Spécifie le nom des keycodes utilisés pour construire le layout
-keymap name Spécifie le nom d'une description keymap utilisé pour construire le layout
-layout name Spécifie le nom d'un layout utilisé pour déterminer les composants qui créent le keyboard description
-model name Spécifie le nom du modèle de clavier utilisé pour déterminer le composant qui créé le keyboard description
-option name Nom d'une option pour déterminer les composants qui créent le keyboard description
-print Affiche les noms des composants dans un format acceptable pour xkbcomp et quitte
-query Affiche le nom des fichiers de règle utilisés pour résoudre le layout demandé
-rule file Spécifie le nom d'un fichier de règles utilisés pour résoudre la requête demandée
-symbols name Spécifie le nom d'un composant symbols utilisé pour construire un layout
-sync Force la synchronisation pour les requêtes X
-type name Spécifie la variant de layout à utiliser
-verbose|-v [level] Verbosité ( de 0 à 10 )
^
08 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/seusers

/etc/selinux/‹SELINUXTYPE›/seusers

Fichier de configuration de mappage des utilisateurs GNU/Linux en utilisateurs SELinux

   Ce fichier est utilisé par les application de connexions compatible SELinux. selinux_usersconf_path(3) retourne le chemin de la stratégie active vers ce fichier. getseuserbuname(3) lit ce fichier pour maper un utilisateur ou groupe en un utilisateur SELinux. Chaque ligne consiste des champs suivants [%group_id]|[user_id]:seuser_id[:range]

group_id|user_id Le GID/UID GNU/Linux. une entrée __default__ peut être fournis.
seuser_id L'identité utilisateur SELinux
range Niveau ou plage optionnelle pour une stratégie MLS/MCS

Exemple


__default__:user_u:s0
system_u:system_u:s0-s15:c0.c255
root:root:s0-s15:c0.c255
fred:user_u:s0
%user_group:user_u:s0
^
15 juin 2017

htmlpdflatexmanmd




sftp

sftp

Programme de transfert de fichier sécurisé

- sftp est un programme de tranfert de fichier interactif, similaire à ftp, qui effectue toutes les opérations via un transport ssh chiffré. Il peut également utiliser de nombreuses fonctionnalités de ssh, tel que l'authentification à clé publique, et la compression. sftp se connecte dans l'hôte spécifié, puis entre en mode interfactif.
- L'autre format d'utilisation va récupérer les fichiers automatiquement si une authentification non-interactive est utilisée.
- La troisième utilisation permet à sftp de démarrer dans un répertoire distant
- La dernière utilisation permet d'automatiser les sessions. Dans ce cas, il est nécessaire de configurer une authentification non-interactive.

OPTIONS

-4 Force l'utilisation des adresses IPv4 uniquement
-6 Force l'utilisation des adresses IPv6 uniquement
-a Tente de continuer les transferts interrompus au-lieu d'écraser l'existant
-B buffer_size Spécifie la taille du tampon utilisé pour le tranfert de fichiers.
-b batchfile Le mode batch lit une série de commandes depuis ce fichier au lieu de stdin.
-C Active la compression. cette options est passée à ssh
-c cipher Sélectionne le chiffrement à utiliser pour chiffrer le tranfert de données. cette options est passée à ssh
-D path Se connecte directement au serveur sftp local au lieu d'utiliser ssh
-F ssh_config Spécifie un fichier de configuration alternatif pour ssh. cette options est passée à ssh
-i identity_file Sélectionne la clé privée pour l'authentification à clé publique. cette options est passée à ssh
-l limit Limite la bande passante utilisée, spécifiée en Kbit/s
-o ssh_option Passe des options à ssh, au format ssh_config
-P port port de connection sur l'hôte distant
-p Préserve les atime et mtime et les modes des fichiers originaux
-q Mode silencieux. N'affiche pas de progression
-R num_requests Spécifie le nombre de requêtes simultannés
-r Copie récursivement les répertoires. Noter que sftp ne suit pas les liens symboliques
-S program Nom du programme à utiliser pour chiffrer la connexion. Le programme doit comprendre les options ssh
-s subsystem|sftp_server Spécifie le sous-système ssh2 ou le chemin d'un serveur sftp dans l'hôte distant.
-v mode verbeux

Commandes

bye Quitte sftp
cd path Change le répertoire distant
chgrp grp path Change le groupe du fichier
chmod mode path Change les permissions du fichier
chown own path Change le propriétaire du fichier
df [-hi] [path] Affiche des informations d'utilisation du système de fichier
exit Quitte sftp
get [-afPpr] remote-path [local-path] Récupère le remote-path et le stocke dans la machine locale. -a tente de relance un transfert partiel, -f utilise fsync(2), -P ou -p copie les permissions, atime et ctime. -r copie récursivement
lcd path Change de répertoire local
lls [ls-options [path]] Liste le répertoire local
lmkdir path Créé un répertoire local
ln [-s] oldpath newpath Créé un lien
lpwd Affiche le répertoire de travail local
ls [-1afhlnrSt] [path] Liste le répertoire distant. Les flags suivants sont reconnus:

        -1 Produit une soltien à une seule colonne
        -a Affiche également les fichiers cachés
        -f Ne trie pas les fichiers
        -h Utilisé avec le format long, utilise des suffixes d'unité
        -l Affiche des détails
        -n  ne résoud pas les uid/gid
        -r Inverse l'ordre de trie
        -S Trie la liste par taille
        -t Trie par date de denière modification

lumask umask Définis le umask local
mkdir path Créer un répertoire
progress affiche/cache la barre de progression
put [afPpr] local-path [remote-path] upload le chemin local vers l'hôte distant. les options sont les même que get
pwd Affiche le répertoire de travail distant
quit Quitte sftp
reget [-Ppr] remote-path [local-path] Relance un téléchargement. Équivalent à get -a
reput [-Ppr] [local-path] remote-path Relance un upload. Équivalent à put -a
rename oldpath newpath Renomme un fichier distant
rm path supprime un fichier distant
rmdir path Supprime un répertoire distant
symlink oldpath newpath Créé un lien symbolique
version Affiche la version du protocol sftp
!command Exécute la commande dans le shell local
! Échappe vers le shell local
^
15 juin 2017

htmlpdflatexmanmd




sftp-server

sftp-server

sous-système serveur SFTP

   sftp-server est directement appelé par sshd en utilisant l'option Subsystem

   Les flags de ligne de commande de sftp-server doivent être spécifiés dans la déclaration Subsystem.

OPTIONS

-d start_directory Spécifie un répertoire de démarrage alternatif pour les utilisateurs. Défaut: utilise le répertoire personnel de l'utilisateur
-e  affiche des informations sur stderr au-lieu de syslog
-f log_facility Facilité syslog: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
-l log_level Niveau de log: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, et DEBUG3.
-P blacklisted_requests Spécifie une liste de requêtes SFTP bannis par le serveur.
-p whitelisted_requests Spécifie une liste de requêtes SFTP permises par le serveur
-Q protocol_feature Affiche les fonctionnalités supportés par sftp-server
-R Place l'instance sftp-server en mode lecture seule.
-u umask Définis le umask explicite pour les fichiers créés.
^
03 novembre 2011

htmlpdflatexmanmd




sg

sg

Exécuter une commande avec un autre identifiant de groupe

   Il fonctionne comme newgrp, mais prend une commande en paramètre. Cette commande sera exécutée par /bin/sh. Une autre différence est que certains interpréteurs de commande traitent newgrp de façon particulière, en se remplaçant eux-mêmes par une nouvelle instance d’un interpréteur que newgrp créé. Ceci n’est pas le cas avec sg, ce qui permet de retrouver le groupe précédent à la sortie de sg.

OPTIONS

-c commande à exécuter

   sg utilise des variables dans /etc/login.defs
^
07 juin 2010

htmlpdflatexmanmd




sha1sum

sha1sum, sha224sum, sha256sum, sha384sum, sha512sum

Calcul un checksum pour chaque fichier spécifié

   sha1sum calcul un checksum 160, 224, 256, 384 et 512-bits respectivement pour chaque fichier spécifié. les options sont les même que md5sum.

OPTIONS

-b, --binary Traite chaque fichier en binaire, en le lisant en mode binaire, préfixe le nom du fichier par '*'. Principalement utile sur les systèmes MS-DOS.
-c, --check Lit les informations de checksum et de nom de fichier dans le fichier et report si le checksum correspond avec le fichier nommé. Le format du fichier d'entrée est généralement le format de sortie d'un md5sum précédent.
--quiet Cette option est utile seulement quand on vérifie les checksums. Ne génère pas de 'OK' pour chaque message vérifié avec succès.
--status Cette option est utile seulement quand on vérifie les checksums. Ne génère pas de diagnostic et ne sort pas d'alerte en cas d'erreur.
-t, --text Traite chaque fichier en entrée comme texte. Utile pour les systèmes de type MS-DOS.
-w, --warn En vérifiant les checksums, alerte sur les ligne de checksums MD5 mal formatés.
^
03 novembre 2011

htmlpdflatexmanmd




shadowconfig

shadowconfig

Active ou désactive les mots de passe cachés

   Ne prend que 2 valeurs, on et off. Désactiver puis réactiver les mots de passe permet de supprimer les informations d’âge des mots de passe.

^
07 février 2015

htmlpdflatexmanmd




sheep

sheep

Système de stockage block distribué pour KVM

Description

   sheepdog est un système de stockage distribué pour KVM/QEMU. Il fournis une haute disponibilité des volumes de stockages au niveau block aux machines virtuelles. Sheepdog supporte la gestion avancée des volumes tel que les snapshots, clonage, et provisioning. L'architecture de Sheepdog est pleinement symétrique; il n'y a pas de nœud central tel qu'un serveur de méta-données. Le service est appelé sheep. Un utilitaire en ligne de commande est disponible via collie. Les machines virtuelles QEMU/KVM utilisent le service sheep via un pilote block disponible dans qemu.

OPTIONS

-P, --pidfile Créé un fichier pid
-p, --port Spécifie le port de communication
-f, --foreground Empêche le service de passe en tâche de fond
-d, --debug Affiche des message de debuggage
-D, --directio Active l'E/S direct en accédant au cache d'objet
-z, --zone Spécifie l'id de zone de disponibilité
-c, --cluster Spécifie le pilote du cluster
-g, --gateway L'instance sheep fonctionne en mode gateway
-l, --loglevel Spécifie le niveau de log
-o, --stdout Les logs sont envoyé sur stdout
-s, --disk-space Spécifie l'espace disque disponible en Mo
-w, --enable-cache size[,mode] Active le cache d'objets et spécifie la taille max du cache en Mo et son mode (writethrough ou writback)
-y, --myaddr Spécifie l'adresse IP d'annonce aux autres sheep

path

   Un système LSB stocke les fichiers dans /var/lib/sheepdog. Le script init utilise ce répertoire par défaut. Le répertoire doit être sur un système de fichier avec le support xattr. Dans le cas de ext3, user_xattr devrait être ajouté aux options de montage. mount -o remount,user_xattr /var/lib/sheepdog.
^
07 février 2015

htmlpdflatexmanmd




sheepfs

sheepfs

Pseudo système de fichier qui exporte l'état interne de sheepdog et le stockage sheepdog.

Description

   sheepfs est un pseudo système de fichier basé sur FUSE pour accéder à l'état interne de sheepdog, et au stockage. L'idée ici est qu'il est parfois utile d'envisager une interaction avec un objet Sheepdog en terme de structure de répertoire et les opérations du système de fichiers.

OPTIONS

-a, --address Spécifie l'adresse du service. Défaut: localhost
-p, --port Spécifie le port du service. Défaut: 7000
-d, --debug Affiche des message de debuggage
-f, --foreground Empêche le service de passe en tâche de fond
-k, --pagecache Utilise le cache de page du kernel pour accéder au volume
-n, --noobjectcache Désactive le cache d'objet des volumes attachés
^
03 novembre 2011

htmlpdflatexmanmd




shells

shells

Fichier texte contenant le chemin complet des shells valides

   /etc/shells contient la listes de shells valides, chemin complet inclus, un par ligne.

^
05 janvier 2014

htmlpdflatexmanmd




showfont

showfont

Showfont affiche des informations sur une police de caractère qui matche le pattern donné.

OPTIONS

-server servername Serveur X à contacter
-fn name Font à afficher
-lsb L'ordre des bits de la font est LSB en premier
-msb L'ordre des bits de la font est MSB en premier
-LSB L'ordre des octets de la font st LSB en premier
-MSB L'ordre des octets de la font st MSB en premier
-ext[ents_only] Seule les extensions de caractère sont affiché, pas les bitmaps
-start char Le début de la plage de caractères à afficher (char est un nombre)
-end char La fin de la plage de caractères à afficher (char est un nombre)
-unit n scanline unit de la font (8, 16, 32 ou 64)
-pad n scanpad unit de la font (8, 16, 32 ou 64)
-b[itmap_pad] n Le bitmap padding de la font (0 - ImageRectMin, 1 - ImageRectMaxWidth et 2 - ImageRectMax)
-noprops N'affiche pas les propriétés de la font
^
03 décembre 2016

htmlpdflatexmanmd




showmount

showmount

Afficher les informations de montage d'un serveur NFS

OPTIONS

-a, --all Liste le hostname et l'ip du client et les répertoires montés. Ne devrait pas être considéré comme fiable
-d, --directories Liste seulement les répertoires montés par certains clients
-e, --exports Affiche la liste d'export du serveur
--no-headers N'affiche pas l'en-tête dans la sortie
^
30 juin 2010

htmlpdflatexmanmd




shred

shred

Écrase des périphériques ou des fichiers, pour éviter la possibilité de récupérer des données.

   Ordinairement, quand on supprime un fichier, les données ne sont pas supprimées, seul l'index est supprimé, et l'espace est déclaré disponible.

OPTIONS

-f, --force modifie les permissions de fichier si nécessaire pour pouvoir écraser.
-NUMBER, -n NUMBER, --iterations=NUMBER par défaut shred utilise 3 passes. après 25 passes, tous les motifs internes seront utilisés au moins une fois.
--random-source=FILE Utilise FILE comme source de données aléatoire
-s BYTES, --size=BYTES efface les premier BYTES octets du fichier. efface le fichier entier par défaut. La taille peut être spécifié avec un multiplicateur
-u, --remove après avoir écrasé un fichier, le tronque si possible puis le supprime. Si le fichier a de multiples liens, seul les liens nommés seront supprimés.
-v, --verbose affiche sur l'erreur standard tous les status du processus.
-x, --exact Par défaut, shred arrondis la taille d'un fichier régulier jusqu'au prochain multiple de taille de block du système de fichier pour écraser complètement le dernier block. Utiliser --exact annule ce mode.
-z, --zero Normalement, la dernière passe est faite de données aléatoires. çà peut être ambigue (peut ressembler à un fichier crypté), cette options permet de remplir le fichier de 0 pour la dernière passe.

Exemples

Effacer toute trace d'un fichier système crée sur une disquette. Cette commande prend environ 20 minutes pour effacer 1.44MB
shred --verbose /dev/fd0
similairement, effacer toutes les données sur une partition d'un disque dur
shred --verbose /dev/sda5
^
21 juillet 2010

htmlpdflatexmanmd




shuf

shuf

Permuter aléatoirement les lignes d'entrée

   shuf a 3 modes d'opération qui affecte où il obtient ses lignes en entrée. Par défaut il lit sur l'entrée standard.

OPTIONS

-e, --echo Traite chaque opérande de la ligne de commande comme ligne d'entrée.
-i LO-HI, --input-range=LO-HI Agit comme si l'entrée venait d'un fichier contenant la plage d'entiers décimales non-signés, un par ligne.
LINES, --head-count=COUNT Sort COUNT lignes. par défaut toutes les lignes sont sorties.
-o OUTPUT-FILE, --output=OUTPUT-FILE Écrit la sortie dans le fichier spécifié.
--random-source=FILE Utilise le fichier spécifié comme source de données aléatoire.
-z, --zero-terminated Délimite les items avec un octet zéro au lieu d'un newline.
^
31 mai 2010

htmlpdflatexmanmd




shutdown

shutdown

Arrêter les services

   shutdown s'occupe d'arrêter le système de façon sûre. Tous les utilisateurs encore loggés sont notifiés que le système va s'arrêter et, dans les 5 dernières minutes de TIME, les nouveaux loggés sont prévenus. Une fois TIME passé, shutdown envoie une requête à init pour arrêter le système dans le runlevel approprié.

OPTIONS

-r demande que le système soit redémarré et non pas arrêté
-h demande que le système soit éteindre ou arrêté une fois le système terminé.
-H Demande que le système soit arrêté après que le système s'est terminé
-P Demande que le système soit éteind après que le système se soit terminé.
-c Annule un shutdown en cours. TIME n'est pas spécifié avec cette option. Le premier argument est MESSAGE.
-k Envoie seulement les messages d'alerte et désactive les logs. N'arrête pas le système.
^
27 mai 2016

htmlpdflatexmanmd




sig-list-to-certs

sig-list-to-certs

Outils de conversion des listes de signature EFI en certificats openssl

   Prend un fichier de liste de signature EFI et le convertis en certificats x509 au format DER.

Exemples

Voir quels certificats le système UEFI possède:
dmpstore PK › PK.uc16
Ce fichier n'est pas compréhensible à cause du format UC-16, donc pour le convertir:
iconv -f utf-16 PK.uc16 › PK.txt
Puis supprimer l'en-tête. Le dump hexa peut être convertis avec:
xxd -r PK.txt › pk.esl
Et enfin extraire les certificats avec
sig-list-to-certs PK.esl PK
Finallement, voir le certificat:
openssl x509 -text -inform DER -in PK.0
^
27 mai 2016

htmlpdflatexmanmd




sign-efi-sig-list

sign-efi-sig-list

Outils de signature de variables

   Produit un fichier de sortie avec un en-tête d'authentification pour mettre à jours une variable. Cette sortie peut être signée par les clés usuelles directement ou peut être splité pour une signature externe en utilisant les options -o et -i.

OPTIONS

-r Le certificat est rsa2048 au lieu de x509
-m Utilise un compteur monotonique au lieu d'un timestamp
-a Prépare la variable pour APPEND_WRITE au lieu d'un remplacement
-o Ne signe pas, mais sort un fichier du bundle exact à signer
-t timestamp utiliser le timestamp spécifié.
-i Prend une signature détachée au format PEM produit pas -o et complète la création de la mise à jours
-g guid Utilise le guid comme guid propriétaire de la signature
-c crt Le certificat de signature au format PEM

Exemples

Pour signer une simple mise à jours dans db qui a été préparé comme liste de signature EFI dans DB.esl et sort le résultat avec l'en-tête d'authentification dans DB.auth
sign-efi-sig-list -a -c KEK.crt -k KEK.key db DB.esl DB.auth
Pour faire une signature détachée:
sign-efi-sig-list -a -t 'Jul 21 09:39:37 BST 2012' -o db DB.esl DB.forsig
Signer le fichier DB.forsig à la manière openssl. Noter que les standards imposent sha256
openssl smime -sign -binary -in DB.forsig -out DB.signed -signer KEK.crt -inkey KEK.key -outform DER -md sha256
Qui produit une signature PKCS7 détachée dans DB.signed. Maintenant le placer dans le programme:
sign-efi-sig-list -a -i DB.signed -t 'Jul 21 09:39:37 BST 2012' db DB.auth
Pour supprimer une clé, simplement signer un fichier de liste de signature, donc pour produire une mise à jours de variable qui va supprime le PK:
› null.esl
Puis le signer:
sign-efi-sig-list -c PK.crt -k PK.key PK null.esl PK.auth
Utiliser UpdateVars.efi pour l'appliquer:
UpdateVars [-a] db DB.auth
où le flag -a doit être présent si le fichier DB.auth a été créé comme ajout, et absent s'il remplace la variable.
^
23 mai 2010

htmlpdflatexmanmd




Signaux - présentation

Signaux - présentation

Introduction aux signaux sous linux

   Ceci est une présentation très sommaire des signaux sous linux, je ne détail ici que les signaux standard. Linux supporte supporte à la fois les signaux POSIX classiques ("signaux standards") et les signaux POSIX temps-réel. Chaque signal a une disposition courante, qui détermine comment le processus agit quand il reçoit le signal. Les entrées dans la colonne action des tables ci-dessous spécifient la disposition par défaut pour chaque signal:

Term L'action par défaut est de terminer le processus
Ign L'action par défaut est d'ignorer le signal
Core L'action par défaut est de termine le processus et dumper le core
Stop L'action par défaut est de stopper le processus
Cont L'action par défaut est de continuer un processus qui est stoppé.

   Un processus peut changer la disposition d'un signal. La disposition d'un signal est un attribut par processus : dans une application multi-thread, la disposition d'un signal particulier est le même pour tous les thread.

Signaux standard

Linux supporte les signaux standard ci-dessous. De nombreux signaux dépendent de l'architecture.
Signal_____Valeur_____Action_____Commentaire
SIGHUP_______1________Term_______Raccrochement (déconnexion) sur terminal de contrôle, ou mort du processus de contrôle
SIGINT_______2________Term_______Interruption depuis le clavier.
SIGQUIT______3________Core_______Demande 'Quitter' depuis le clavier.
SIGILL_______4________Core_______Instruction illégale.
SIGABRT______6________Core_______Signal d'arrêt depuis abort(3).
SIGFPE_______8________Core_______Erreur mathématique virgule flottante.
SIGKILL______9________Term_______Signal 'KILL'.
SIGSEGV_____11________Core_______Référence mémoire invalide.
SIGPIPE_____13________Term_______Ecriture dans un tube sans lecteur.
SIGALRM_____14________Term_______Temporisation alarm(2) écoulée.
SIGTERM_____15________Term_______Signal de fin.
SIGUSR1_____10________Term_______Signal utilisateur 1.
SIGUSR2_____12________Term_______Signal utilisateur 2.
SIGCHLD_____17________Ign________Fils arrêté ou terminé.
SIGCONT_____18________Cont_______Continuer si arrêté.
SIGSTOP_____19________Stop_______Arrêt du processus.
SIGTSTP_____20________Stop_______Stop invoqué depuis tty.
SIGTTIN_____21________Stop_______Lecture sur tty en arrière-plan.
SIGTTOU_____22________Stop_______Ecriture sur tty en arrière-plan.

D'autres signaux divers


Signal_____Valeur_____Action_____Commentaire
SIGBUS_______7_________Core_______Erreur de Bus.
SIGPOLL________________Term_______Synonyme de SIGIO (System V).
SIGPROF_____27_________Term_______Profile alarm clock.
SIGSYS_________________Core_______Mauvais argument de routine (SVID).
SIGTRAP______5_________Core_______Trace/breakpoint trap
SIGURG______23_________Ign________Condition urgente sur socket (4.2 BSD).
SIGVTALRM___26_________Term_______Alarme virtuelle (4.2 BSD).
SIGXCPU_____24_________Core_______Limite de temps CPU dépassée (4.2 BSD).
SIGXFSZ_____25_________Core_______Taille de fichier excessive (4.2 BSD).
SIGIOT_______6_________Core_______Arrêt IOT. Un synonyme de SIGABRT.
SIGEMT_________________Term_______
SIGSTKFLT___16_________Term_______Erreur de pile sur coprocesseur.
SIGIO_______29_________Term_______E/S à nouveau possible(4.2 BSD).
SIGCLD_________________Ign________Synonyme de SIGCHLD.
SIGPWR______30_________Term_______Chute d'alimentation (System V).
SIGINFO___________________________Synonyme de SIGPWR
SIGLOST________________Term_______Perte de verrou de fichier.
SIGWINCH____28_________Ign________Fenêtre redimensionnée (4.3 BSD, Sun).
SIGUNUSED___31_________Term_______Signal inutilisé.

   Note: La valeur correspond aux architectures ia32, ia64, ppc s390 arm et sh

Signaux temps réel

   Linux supporte 32 signaux temps réels, numérotés de 33 à 64. À la différence des signaux standard, les signaux temps réels n'ont pas de signification prédéfinis, ils sont définis par les applications.
^
23 mai 2010

htmlpdflatexmanmd




skill

skill, snice

Obsolète, préférer killall, pkill ou pgrep

skill envoie un signal à un processus
snice modifie la priorité d'un processus

   le signal par défaut est TERM. Utiliser -l ou -L pour lister les signaux disponibles. la priorité par défaut pour snice est +4.

OPTIONS

-f fast mode
-i utilisation interactif : demande confirmation avant chaque action
-v mode verbeux
-n  n'affiche que les ID de processus

Options de délection de processus

   les critères de sélection peuvent être: terminal, user, pid, command. les options ci dessous peuvent être utilisés pour s'assurer de l'interprétation correcte.

-t l'argument suivant est un terminal
-u l'argument suivant est un username
-p l'argument est un ID de processus
-c l'argument suivant et un nom de commande
^
08 septembre 2013

htmlpdflatexmanmd




slapacl

slapacl

Vérifie l’accès à une liste d’attributs en vérifiant dans la configuration de slapd

OPTIONS

-b DN Spécifie le DN dont l’accès est demandé.
-d debug_level Active le débug
-D authcDN Spécifie un DN à utiliser comme identité pour le test
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-o option[=value] Spécifie une option slapd ( syslog=‹subsystems›, syslog-level=‹level›, syslog-user=‹user›, et authzDN,domain,peername,sasl_ssf,sockname,sockurl,ssf,tls_ssf,transport_ssf)
-u Ne pas chercher l’entrée dans la base de données
-U authcID Spécifie un ID à mapper au DN comme par authz-regexp ou authz-rewrite.
-v mode verbeux
-X authzID Spécifie un ID d’autorisation à mapper au DN comme avec authz-regexp ou authz-rewrite.

Exemples

Test si bjorn peut accéder à l’attribut ’o’ de l’entrée o=University of Michigan,c=US en lecture
/usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -v -U bjorn -b "o=University of Michigan,c=US" "o/read:University of Michigan"
^
08 septembre 2013

htmlpdflatexmanmd




slapadd

slapadd

Ajouter des entrées dans une base slapd. toutes les entrées ajoutées appartiennent à l’identité sous laquelle slapadd fonctionne, il est donc nécessaire de l’exécuter sous la même identité que slapd

OPTIONS

-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-j lineno Saute à la ligne spécifiée dans le fichier LDIF avant de traiter les entrées.
-l ldif-file Fichier d’entrée
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-q mode rapide (peut de vérifications)
-s Désactive la vérification du schéma
-S SID ID du serveur à utiliser en générant entryCSN. également pour contextCSN si -w.
-u dry-run n’écrit pas dans le backend
-v mode verbeux
-w Écrit les information de contexte syncrepl. après que les entrées soient ajoutées, met à jour le contextCSN

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slapauth

slapauth

Vérifie une liste d’ID pour authc/authz

OPTIONS

-d debug-level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-M mech Spécifier un mécanisme
-o option[=value] Spécifie une option slapd ( syslog=‹subsystems›, syslog-level=‹level›, syslog-user=‹user›)
-R realm Spécifier un royaume
-U authcID Spécifier un ID à utiliser
-X authzID Spécifie un ID à utiliser
-v mode verbeux

Exemples

Test si l’utilisateur bjorn peut assumer l’identité de bjesen tel que définis par les directives
authz-policy from authz-regexp "^uid=([^,]+).*,cn=auth$" "ldap :///dc=example,dc=net ??sub ?uid=$1"
/usr/local/sbin/slapauth -f //usr/local/etc/openldap/slapd.conf -v -U bjorn -X u:bjensen
^
08 septembre 2013

htmlpdflatexmanmd




slapcat

slapcat

Utilitaire de génération de fichier LDIF

OPTIONS

-a filter Dump seulement les entrées correspondant au filtre
-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-H URI
-l ldif-file Écrit la sortie dans le fichier spécifié
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-s subtree-dn Dump seulement les entrées dans la sous-arborescence spécifiée par ce DN

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slapd

slapd

Serveur LDAP

OPTIONS

-4 IPv4 uniquement
-6 IPv6 uniquement
-T tool Mode tool. tool sélectionne s’il tourne en tant que : slapadd, slapcat, slapdn, slapindex, slappasswd, slapschema,slaptest. ces programmes sont généralement des liens symbolique vers slapd.
-d debug-level Active le débug
-s syslog-level niveau de debug à logger
service-name Nom du service (défaut : slapd)
-l syslog-local-user syslog facility (LOCAL0 à LOCAL7, USER, DAEMON)
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-h URLlist liste d’url d’écoute du serveur (défaut : ldap :///)
-r directory Répertoire où slapd va se chrooter
-u user Utilisateur du service
-g group Groupe du service
-c cookie Fournis un cookie pour la réplication syncrepl sous la forme d’une liste de nom=valeur (rid, sid, csn)
-o option[=value] Spécifie une option slapd (slp=on|off|slp-attrs gère le SLP. (ex : "slp=(tree=production),(server-type=OpenLDAP),(server-version=2.4.15)"
^
22 septembre 2013

htmlpdflatexmanmd




slapd-access

slapd-access

Configuration d'accès pour slapd

Structure

   access to ‹what› [ by ‹who› [ ‹access› ] [ ‹control› ] ]+

   Donne accès à un jeu d'entrées et/ou attributs (what) par des demandeurs (who). Les ACL sont évaluées dans l'ordre auxquelles elles apparaissent. lors qu'un what match, who est vérifié. puis les clauses access et control sont évaluées

Le champ WHAT

Spécifie l'entité à laquelle cette ACL s'applique. Il peut avoir les formes suivante:
dn[.‹dnstyle›]=‹dnpattern›
filter=‹ldapfilter›
attrs=‹attrlist›[ val[/matchingRule][.‹attrstyle›]=‹attrval›]

avec:
‹dnstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children}
‹attrlist›={‹attr›|[{!|@}]‹objectClass›}[,‹attrlist›]
‹attrstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children}

dn=‹dnpattern› Sélectionne les entrées basées sur leur contexte de nommage
‹dnstyle› (optionnel). Base (synonymes de baseObject) ou exact (alias de base) indique l'entrée dont le DN est égal à ‹dnpattern›. one (synonyme de onelevel) indique toutes les entrées immédiatement sous le ‹dnpattern›, sub (synonyme de subtree) indique toutes les entrées dans la sous-arborescence de ‹dnpattern›, children indique toutes les entrées subordonnées à ‹dnpattern› Si dnstyle est un regex, ‹dnpattern› est une expression étendue POSIX et match une représentation du DN.
filter=‹ldapfilter› Sélectionne les entrées basée sur un filtre LDAP
attrs=‹attrlist› sélectionne les attributs auxquels la règle s'applique. Le signe + indique l'accès à l'entrée elle-même. children indique l'accès à l'entrée de l'enfant. Les classes d'objet peuvent être spécifiés également. Les noms préfixés par '@' sont directement traités comme nom de classe d'objet. un nom préfixé par '!' et traité comme classe d'objet mais la règle affecte les attributs non requis ni permis. sans cette liste, assume attrs=@extensibleObject
attrs=‹attrlist›[ val[/matchingRule][.‹attrstyle›]=‹attrval›] Cette forme spécifie un accès à une valeur particulière d'un simple attribut. seul l'attribut est donnée.
dn, filter, attrs sont additifs. les sous-match résultant de regex peuvent être dé-référencés dans ‹who› avec la syntaxe ${v_n_} où _n_ est le numéro de sous-match.

Le champ WHO

Indique à qui la règle s'applique. Plusieurs who peuvent apparaîtrent dans l'acl. Il a la forme:
*    
anonymous
users
self[.‹selfstyle›]
    
dn[.‹dnstyle›[,‹modifier›]]=‹DN›
dnattr=‹attrname›
    
realanonymous
realusers
realself[.‹selfstyle›]
    
realdn[.‹dnstyle›[,‹modifier›]]=‹DN›
realdnattr=‹attrname›
    
group[/‹objectclass›[/‹attrname›]][.‹groupstyle›]=‹group›
peername[.‹peernamestyle›]=‹peername›
sockname[.‹style›]=‹sockname›
domain[.‹domainstyle›[,‹modifier›]]=‹domain›
sockurl[.‹style›]=‹sockurl›
set[.‹setstyle›]=‹pattern›
    
ssf=‹n›
transport_ssf=‹n›
tls_ssf=‹n›
sasl_ssf=‹n›
    
dynacl/‹name›[/‹options›][.‹dynstyle›][=‹pattern›]

avec:
‹style›={exact|regex|expand}
‹selfstyle›={level{‹n›}}
‹dnstyle›={{exact|base(object)}|regex|one(level)|sub(tree)|children|level{‹n›}}
‹groupstyle›={exact|expand}
‹peernamestyle›={‹style›|ip|ipv6|path}
‹domainstyle›={exact|regex|sub(tree)}
‹setstyle›={exact|expand}
‹modifier›={expand}
‹name›=aci ‹pattern›=‹attrname›]

Indique tout le monde
realanonymous Les mots clé préfixés par real agissent comme leur homologue non préfixés. La vérification se produit avec le DN authentification et le DN authorisation
anonymous référence les clients non authentifiés
users Références les clients authentifiés
self Référence l'entrée elle-même (l'entrée demandée et l'entrée qui requête doit correspondre). Accepte le style level{‹n›}, où _n_ indique que l'ancêtre du DN est utilisé dans le match. Une valeur positive indique que le ‹n›-ième ancêtre du DN de l'utilisateur est considéré; une valeur négative indique que le ‹n›-ième ancêtre de la cible doit être considéré. (ex: "by self.level{1} ..." matche quand l'objet "dc=example,dc=com" est accédé par cn=User,dc=example,dc=com") (ex: "by self.level{-1} ..." matche quand le même user accède à "ou=Address Book,cn=User,dc=example,dc=com"
dn=‹DN› L'accès est donnée au DN qui matche.
dnstyle (optionnel) autorise le même choix que pour WHAT. le style regex exploit la substitution de sous-match dans le dn.regex de WHAT en utilisant la forme $‹digit›, de 0 à 9 où 0 match toute la chaîne. ${‹digit›+} pour les sous-matches › 9, ${v‹digit›+} pour la substitution de chaîne de valeur d'attributs. le $ de fin de chaîne doit être spécifié par '$$'

access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$" by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$" by dn.exact,expand="uid=$2,dc=example,dc=com" write
access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$" by dn.exact,expand="uid=$2,dc=$3,dc=com" write

level{n} est une extension de la forme onelevel, où l'ancêtre n est le pattern. Donc level{1} est équivalent à onelevel et level{0} vaut base
dnattr=‹attrname› L'accès est donné aux requêtes dont le DN est listé dans l'entrée accédée sous l'attribut ‹attrname›
group=‹group› L'accès est donné aux requêtes dont le DN est listé dans l'entrée group dont le DN est donné par ‹group› ‹objectclass› et ‹attrname› donnent la classe objet et l'attribut des membres.(défaut: groupOfNames et member). ‹style› peut être expand qui signifie que ‹group› sera étendu comme remplacement (mais non comme expression régulière), et exact, qui signifie que le match exacte sera utilisé. Pour des groupes statiques, le type d'attribut spécifié doit avoir la syntaxe DN ou NameAndOptionalUID. pour les groupes dynamiques, le type d'attribut doit être un sous-type de labeledURI
peername=‹peername› L'IP de l'hôte contactant (sous la forme IP=‹ip›:‹port› ou IP=[‹ipv6›]:‹port›) ou le nom de l'hôte contactant (PATH=‹path›)
sockname=‹sockname› Le nom du fichier de pipe nommé
domain=‹domain› Le nom d'hôte du contactant
sockurl=‹sockurl› l'URL du contactant, sont comparés avec le pattern pour déterminer l'accès. Le style décrit pour group et regex s'appliquent. Le cas spécial pour ip: ‹peername›=‹ip›[%‹mask›][{‹n›}] où n est le nom du port optionnel (ex: peername.ip=192.168.1.16%255.255.255.240{9009}). (ex: domain.subtree=example.com match www.example.com)
set=‹pattern›
dynacl/‹name›[/‹options›][.‹dynstyle›][=‹pattern›] Indique que la vérification de l'accès est déléguée à une méthode définies indiquée par ‹name›, qui peut être enregistrée en temps réel au moyen de déclarations moduleload. ‹options›, ‹dynstyle› et ‹pattern› sont optionnels et sont passés directement à la routine de parsing enregistrée
dynacl/aci[=‹attrname›] Signifie que le contrôle d'accès est déterminé par les valeurs dans attrnames de l'entrée elle-même. ‹attrname› indique quel type d'attribut maintient l'ACI dans l'entrée. Par défaut, OpenLDAPaci est utilisé
ssf=‹n›
transport_ssf=‹n›
tls_ssf=‹n›
sasl_ssf=‹n› Définissent le SSF minimum pour obtenir l'accès

Le champ ACCESS

Optionnel. Détermine le niveau d'accès ou le privilège que who aura. Il a la forme:
‹access› ::= [[real]self]{‹level›|‹priv›}
où:
‹level› ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
‹priv› ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+

self Permet des opération spéciales pour le DN autorisé
realself Réfère au DN authentifié
level ce modèle d'accès s'assure d'une interprétation incrémentale des privilèges. Les niveaux possibles sont none (aucun accès, disclose ( divulgation d'information en cas d'erreur), auth (permettre l'authentification), compare, search, read, write (add+delete) et manage (inclus des accès administratifs).
priv le modèle d'accès priv se base sur des paramètres explicites de privilèges pour chaque clause. = réinitialise les accès définis précédemment, + et - ajoute/supprime des privilèges. m (manage), w (write), a (add), z (delete), r (read), s (search), c (compare), x (authentification), d (disclose), 0 ( aucun privilège) (défaut: +0)

Le champ Control

   Optionnel. Contrôle le flux de règles d'accès. Peut être:

stop Stop en cas de match
continue Permet à d'autres clause ‹who› dans le même ‹access› d'être considérés
break Permet à d'autres clauses ‹access› qui matchent la même cible d'être traités

exemple break:
access to dn.subtree="dc=example,dc=com" attrs=cn by * =cs break
access to dn.subtree="ou=People,dc=example,dc=com" by * +r
exemple continue:
access to dn.subtree="dc=example,dc=com" attrs=cn by * =cs continue by users +r

Scopes

base correspond seulement à l'entrée avec le DN fournit
one correspond aux entrées dont le parent est le DN fournit
subtree correspond à toutes les entrées dans l'arbre dont le root est le DN fournit
children correspond à toutes les entrées sous le DN (mais pas l'entrée nommée par le DN)

Par exemple, si l'annuaire contient les entrées nommées :
o=suffix
cn=Manager,o=suffix
ou=people,o=suffix
uid=kdz,ou=people,o=suffix
cn=addresses,uid=kdz,ou=people,o=suffix
uid=hyc,ou=people,o=suffix

alors:
dn.base="ou=people,o=suffix" match 2 ;
dn.one="ou=people,o=suffix match 3, and 5 ;
dn.subtree="ou=people,o=suffix match 2, 3, 4, and 5 ; and
dn.children="ou=people,o=suffix match 3, 4, and 5.

cibles


*__________________________All, including anonymous and authenticated users
anonymous__________________Anonymous (non-authenticated) users
users______________________Authenticated users
self_______________________User associated with target entry
dn[.‹basic-style›]=‹regex›_Users matching a regular expression
dn.‹scope-style›=‹DN›______Users within scope of a DN

Correspondance des droits

Level_____Privileges______Description
none______0_______________no access
disclose__d_______________needed for information disclosure on error
auth______dx______________needed to authenticate (bind)
compare___cdx_____________needed to compare
search____scdx____________needed to apply search filters
read______rscdx___________needed to read search results
write_____wrscdx__________needed to modify/rename
manage____mwrscdx_________needed to manage

Opérations requises

   Les opérations nécessitent différents privilèges sur différentes portions d'entrées.

add nécessite le privilège add sur le pseudo-attribut de l'entrée à ajouter, et add sur le pseudo-attribut children du parent de l'entrée.
bind quand les accréditifs sont stockés dans l'annuaire, nécessite les privilèges auth sur l'attribut où sont stockés ces accréditifs.
Compare nécessite compare sur l'attribut à comparer
delete nécessite delete sur le pseudo-attribut de l'entrée à supprimer et sur le pseudo-attribut children du parent de l'entrée
modify nécessite write (add pour ajouter, delete pour supprimer, les 2 pour modifier)
modrdn nécessite write sur le pseudo-attribut de l'entrée à supprimer, delete sur le pseudo-attribut Children de l'ancien parent de l'entrée, et add sur le pseudo-attribut Children du nouveau parent de l'entrée. delete est aussi requis sur les attributs qui sont présent dans l'ancien RDN si deleteoldrdn et à 1.
search nécessite search sur le pseudo-attribut entry du searchBase. Les entrées résultantes sont ensuite testé sur read sur le pseudo-attribut entry et sur chaque valeurs de chaque attribut demandé pour chaque referral utilisé pour générer des références continues, read sur le pseudo-attribut entry et les attributs du referral.
authzID, proxyAuthz necessitent auth sur tous les attributs présents dans la recherche et sur authzTo et/ou authzFrom de l'identité autorisant.

Exemples

Pour matcher la sous-arborescence désirée, la règle serait:
access to dn.regex="^(.+,)?dc=example,dc=com$" by ...
Pour des raisons de performance, il est mieux d'écrire:
access to dn.subtree="dc=example,dc=com" by ...
En écrivant des règles submatch, il peut être préférable d'éviter l'utilisation de ‹dnstyle›:
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.regex="^uid=$2,dc=example,dc=com$$" write
by ...
Cependant, c'est plus efficace:
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$2,dc=example,dc=com" write
by ...
^
19 octobre 2013

htmlpdflatexmanmd




slapd-bdb

slapd-bdb, slapd-hdb

Backend bdb,hdb

   S'appuie sur Oracle Berkeley DB. Il utilise intensivement le cache et l'indexation pour accélérer l'accès aux données. hdb est une variante de bdb qui utilise une base de données hiérarchique avec le support de renommage des sous-arborescences Il est plus rapide et nécessite moins d'espace pour stocker les données.

Configuration

   Ces options sont prévues pour complémenter le jeu d'options dans le fichier d'environnement DB_CONFIG

cachesize _integer_ Spécifie la taille du cache d'entrée en mémoire (défaut : 100 entrées)
cachefree _integer_ Spécifie le nombre d'entrées à libérer du cache quand la limite est atteinte (défaut 1)
checkpoint _kbyte_ _min_ Spécifie la fréquence de vérification des log transactionnels de la base. cette opération vide les tampons sur disques et écrit un enregistrement de checkpoint dans les logs Il se produit si _kbyte_ données on été écrits ou _min_ minutes se sont écoulés
checksum Active la validation de checksum des pages quand elles sont lues depuis le disque. Peut seulement être configuré avant la création des fichiers de la base
cryptfile _file_ Spécifie le chemin d'un fichier contenant la clé de chiffrement à utiliser
cryptkey _key_ Spécifie une clé de chiffrement à utiliser (si cryptfile _file_ n'est pas désiré)
dbconfig _Berkeley-DB-setting_ Spécifie une directive de configuration à placer dans le fichier DB_CONFIG de l'annuaire (ex: dbconfig set_cachesize 0 1048576 0, dbconfig set_lg_bsize 2097152 )
dbnosync Spécifie que le contenue de la base sur disque ne devrait pas être synchronisé immédiatement avec les changement en mémoire.
dbpagesize _dbfile_ _size_ Spécifie la taille de page à utiliser pour un fichier de base particulier en unité de 1024bits. défault pour id2entry est 16, pour les autres 4 ou 8. (max : 64)
directory _directory_ Spécifie le répertoire où réside les fichiers de la base et les index associés
dirtyread Permet la lecture des données modifiée mais non committed.
dncachesize _integer_ Spécifie le nombre max de DN en mémoire
idlcachesize _integer_ Spécifie la taille d'index en mémoire, en slot d'index
index {_attrlist_|default} [pres,eq,approx,sub,_special_] Spécifie les index à maintenir en mémoire pour certains attributs
linearindex Dit à slapindex d'indexer un attribut à la fois. Améliore les performances quand la base dépasse dbcache.
lockdetect {oldest|youngest|fewest|random|default} Spécifie quelle transaction annuler quand un deadlock est détecté (défaut : random)
mode _integer_ Spécifie le mode de protection des fichiers d'index nouvellement créés (défaut : 0600)
searchstack _depth_ Spécifie la profondeur de la pile utilisé pour les filtres de recherche. Chaque pile utilise 512 Ko. La pile par défaut est 16, donc 8Mo par thread.
shm_key _integer_ Spécifie une clé pour un environnement BDB à mémoire partagée.
^
22 septembre 2013

htmlpdflatexmanmd




slapd-config

slapd-config

Backend de configuration de slapd

Options de configuration globale

   Ces options sont spécifiées dans l'entrée cn=config. Elle doit avoir un objectClass olcGlobal.

cn =config
olcAllows Spécifie un jeu de fonctionnalités à autoriser. bind_anon_cred permet un bind anonyme quand les crédentials ne sont pas vide, bind_anon_dn permet un bind non-authentifié quand le DN n'est pas vide et proxy_authz_anon permet un contrôle d'autorisation proxy non-authentifié
olcArgsFile Chemin d'un fichier qui maintient la ligne de commande du serveur slapd
olcAttributeOptions Définis le tagging d'options d'attributs ou des préfixes tag/range. un préfixe se termine par '-'.
olcAuthIDRewrite Utilisé par le framework d'authentification pour convertir un simple nom en DN utilisé pour l'autorisation. Son but est analogue à olcAuthzRegexp. Ce jeu de règle est analogue à ceux décrit dans slapo-rwm
olcAuthzPolicy Spécifie quelles règles utiliser pour l'autorisation proxy. none désactive, from utilise les règles dans authzFrom, to utilise celles dans authzTo, any, et all (toutes les autorisations doivent réussir)
olcAuthzRegexp Utilisé par le framework d'authentification pour convertir un simple nom en DN utilisé pour l'autorisation.
olcConcurrency Spécifie un niveau de concurrence.
olcConnMaxPending Nombre maximum de requêtes en attente pour une session anonyme
olcConnMaxPendingAuth Spécifie le nombre maximum de requêtes en attente pour une session authentifiée.
olcDisallows Spécifie un jeu de fonctionnalités à désactiver. bind_anon n'accèpte plus les requêtes bind anonymes. bind_simple désactive le simple bind. tls_2_anon désactive les sessions forcées en status anonyme une fois l'opération StartTLS reçue. tls_authc désactive es opérations StartTLS si authentifié.
olcGentleHUP a TRUE, SIGHUP ne fait qu'une tentative d'arrêt. slapd n'accèpte plus les nouvelle connexions, mais attend que les connexions en cours se terminent.
olcIdleTimeout Nombre de secondes avant de fermer une session client non active. ( 0 désactive)
olcIndexIntLen Longueur de clé pour les indices entier ordonnés. Le MSB d'un binaire entier sera utilisé pour indexer les clés.
olcIndexSubstrIfMaxLen Longueur max des indices subinitial et subfinal.
olcIndexSubstrIfMinLen Longueur mini des indices subinitial et subfinal. Une valeur d'attribut doit avoir au moins cette longueur pour être traitée
olcIndexSubstrAnyLen Longueur utilisée pour les indices subany. Une valeur d'attribut doit avoir au moins cette longueur pour être traitée. est utilisé pour les indices subinitial et subfinal quand le filtre est supérieur à olcIndexSubstrIfMaxlen
olcIndexSubstrAnyStep Spécifie les étapes utilisée dans les recherchée d'index subany. définis l'offset pour les segments d'une chaîne de recherche
olcListenerThreads Spécifie le nombre de threads à utiliser pour le gestionnaire de connexion
olcLocalSSF Spécifie le Security Strength Factor (SSF) pour les sessions LDAP locales.
olcLogFile Fichier où enregistrer les logs
olcLogLevel Niveau de log
olcPasswordCryptSaltFormat Spécifie le format du salt passé à crypt(3) en générant les mots de passe {CRYPT}. Doit être au format sprintf(3) et peut inclure une conversion %s
olcPidFile Chemin absolu du fichier PID
olcPluginLogFile Chemin absolu d'un fichier contenant les logs pour le plugin SLAPI
olcReferral Spécifie les referrals à passer quand slapd ne peut pas trouver une base à utiliser pour une requête
olcReverseLookup Active/désactive la recherche inversée d'un nom de client
olcRootDSE Nom d'un fichier ldif contenant les attributs utilisateur pour le root DSE
olcSaslAuxprops Spécifie quels plugins auxprop utiliser pour les recherches d'authentification.
olcSaslHost fqdn utilisé pour le traitement SASL
olcSaslRealm Royaume SASL
olcSaslSecProps Spécifie les propriétés de sécurité pour cyrus SASL. none efface les flags "noanonymous,noplain". noplain désactive les mécanismes sujets à attaques passives. noactive désactive les mécanismes sujet à attaques actives. nodict désactive les mécanismes sujets à attaque passive par dictionnaire. noanonymous désactive le support des login anonymes. forwardsec nécessite un renvoie de secret entre les sessions. passcred nécessite un mécanisme qui passe les crédentials clients. minssf=‹factor› spécifie le SSF minimum acceptable. maxssf=‹factor› spécifie le SSF maximum acceptable. maxbufsize=‹size› spécifie la taille de tampon max.
olcServerID Spécifie un ID de 0 à 4096 pour ce serveur.
olcSockbufMaxIncoming Taille de PDU LDAP maximum entrante pour les sessions anonymes.
olcSockbufMaxIncomingAuth Taille de PDU LDAP maximum entrante pour les sessions authentifiées.
olcTCPBuffer Taille du tampon TCP. Une valeur globale est définie, et des valeur pour la lecture et l'écriture peuvent être spécifiés
olcThreads Taille maximum du pool de thread primaire.
olcToolThreads Nombre de thread maximum à utiliser en mode tool. ne devrait pas être supérieur au nombre de CPU.
olcWriteTimeout Nombre de secondes à attendre avant de fermer une connexion avec une écriture en cours. permet une récupération face à divers problèmes réseau

Options TLS

olcTLSCipherSuite Permet de configurer les chiffrement acceptés et l'ordre de préférence.
olcTLSCACertificateFile Fichier contenant les certificats pour toutes les CA que slapd reconnaît
olcTLSCACertificatePath Chemin d'un répertoire contenant les certificats CA
olcTLSCertificateFile Fichier contenant le certificat du server ldap
olcTLSCertificateKeyFile Fichier contenant la clé privée du serveur ldap
olcTLSDHParamFile Spécifie le fichier contenant les paramètres pour les échanges de clé Diffie-Hellman. "!AH" devrait être ajouté à la suite de chiffrements si des chiffrements sont spécifiés et utilisent les échanges de clé DH anonymes.
olcTLSRandFile Fichier pour obtenir des données aléatoires quand /dev/urandom n'est pas disponible
olcTLSVerifyClient Spécifie quelle vérification exécuter sur les certificats clients. never ne demande pas de certificat, allow nécessite un certificat. try le certificat est demandé, mais non obligatoire. demand|hard|true sont équivalent
olcTLSCRLCheck Spécifie si la CRL doit être utilisée pour vérifier les certificats clients. none ne vérifie pas la CRL. peer vérifie dans la CRL. all vérifie toute la chaîne dans le CRL.
olcTLSCRLFile Spécifie le fichier contenant la CRL à vérifier

Options de modules dynamique

   Chaque module a une entrée nommée cn=module{x},cn=config

olcModuleLoad Spécifie le nom d'un module dynamique
olcModulePath Spécifie une liste de répertoires où chercher les modules.

Options de schéma

   Les définitions de schéma sont créées en tant qu'entrée dans cn=schema,cn=config

olcAttributeTypes Spécifie une type d'attribut utilisant la syntaxe LDAPv3
olcDitContentRules Spécifie un DIT Content Rule utilisant la syntaxe LDAPv3
olcObjectClasses Spécifie une classe d'objet en utilisant la syntaxe LDAPv3
olcObjectIdentifier Définis une nom équivalent à l'OID donné

Options général de backend

   Chaque backend est définies dans une entrée nommée: olcBackend=‹databasetype›,cn=config

Options de base de données

   Les options de base de données sont définies dans des entrées nommées olcDatabase={x}‹databasetype›,cn=config. La base frontend spéciale est toujours numérotée {-1} et la base de configuration est toujours numérotée {0}

   Ces options peuvent être définies dans le frontend et doivent avoir l'objet olcFrontEndConfig

olcAccess Définis l'accès à une base de données
olcDefaultSearchBase Spécifie le dn de bas de recherche par défaut à utiliser quand les clients ne spécifient pas de base de recherche
olcExtraAttrs Liste les attributs devant être ajoutés aux requêtes de recherche. Les backend locaux retournent toute l'entrée, le frontend ne retourne que celles autorisées par les ACL.
olcPasswordHash Configure les hash à utiliser lors de la génération de mots de passe dans l'attribut userPassword. {SSHA}, {SHA}, {MD5}, {SMD5}, {CRYPT}, {CLEARTEXT}
olcReadOnly Place la base de donnée en lecture seule
olcRequires Spécifie un jeu de conditions requis. Peut être spécifié globalement et/ou par base de données (additive). authc nécessite une authentification avant toute opération, SASL nécessite une authentification SASL, strong nécessite une authentification forte. none ne spécifie aucune condition
olcRestrict Spécifie une liste d'opérations interdites. Peut être spécifié globalement et/ou par base de données (superseed). add, bind, compare, delete, extended[=‹OID›], modify, rename, search, read, write
olcSchemaDN Spécifie le DN de la sous-entrée du sous-schéma qui contrôle les entrées sur ce serveur.
olcSecurity Spécifie un jeu de SSF. Peut être spécifié globalement et/ou par base de données. ssf=‹n› Spécifie le SSF général. transport=‹cn› spécifie le transport SSF. tls=‹n› spécifie le TLS SSF. update_ssf=‹n› spécifie le SSF général pour les updates. update_transport=‹n› spécifie le transport SSF pour les updates. update_tls=‹n› spécifie les TSL SSF pour les updates. update_sasl=‹n› spécifie le SASL SSF pour les updates. simple_bind=‹n› requière une authentification simple
olcSizeLimit Spécifie le nombre maximum d'entrées à retourner lors d'une recherche.
olcSortVals Spécifie une liste d'attributs multi-valués qui seront toujours maintenus en ordre trié. Permet aux opération modify, compare et aux filtres d'évaluation d'être traités plus efficacement. frontend only.
olcTimeLimit Spécifie le temps maximum en secondes pour une réponse à une recherche

Options de base de données générales

olcAddContentAcl Contrôle si les opérations Add vont effectuer une vérification d'ACL sur le contenu de l'entrée ajoutée.
olcHidden Contrôle si la base sera utilisée pour répondre aux requêtes
olcLastMod Contrôle si slapd maintient automatiquement les attributs modifiersName, modifyTimestamp, creatorsName, et createTimestamp pour les entrées. Contrôle aussi entryCSN et entryUUID
olcLimits Spécifie les limites de temps et de taille basé sur l'initiateur de l'opération ou base DN.
olcMaxDerefDepth Nombre maximum d'aliase à déréférencer en essayant de résoudre une entrée.
olcMirrorMode à TRUE, place un réplica de base en mode mirroir. les updates sont accèptées par tout utilisateur. La base doit être en syncrepl
olcPlugin Configure le plugin SLAPI
olcRootDN Spécifie le DN qui n'est pas sujet à contrôle d'accès ou restrictions administratives
olcRootPW Mot de pas du RootDN
olcSubordinate Spécifie que le backend est subordonné à un autre backend. une base subordonnée peut avoir une seul suffix. Utile pour accoler plusieurs suffix dans un simple contexte de nommage. TRUE, FALSE, advertise (si spécifié, le contexte de nommage de cette base est indiquée dans le rootDSE)
olcSuffix Spécifie le suffix DN des requêtes passée au backend
olcSyncUseSubentry Stocke le contextCSN syncrepl dans une sous-entrée au lieu de l'entrée context de la base
olcSyncrepl Spécifie la base courante comme réplica d'un contenu master
olcUpdateDN applicable uniquement pour les base esclaves. Spécifie le DN autorisé à updater la base
olcUpdateRef Spécifie les référants à passer quand slapd reçoit le demande de modifier une base local répliquée.

Overlays

   Un overlay est une code qui intercepte les opérations de la base dans le but de les étendre ou les changer. Les overlays doivent être configurés comme entrées enfant d'une base spécifique le RDN de l'entrée doit avoir l'objectClass olcOverlayConfig

Exemple

L'exemple suivant, s'il est copié dans le fichier config.ldif, la commande suivante va initialiser la configuration:
slapadd -F /usr/local/etc/openldap/slapd.d -n 0 -l config.ldif


dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /usr/local/var/run/slapd.pid
olcAttributeOptions: x-hidden lang-
    
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
    
include: file:///usr/local/etc/openldap/schema/core.ldif
    
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# Subtypes of "name" (e.g. "cn" and "ou") with the
# option ";x-hidden" can be searched for/compared,
# but are not shown. See slapd.access(5).
olcAccess: to attrs=name;x-hidden by    *    =cs
# Protect passwords. See slapd.access(5).
olcAccess: to attrs=userPassword by    *    auth
# Read access to other attributes and entries.
olcAccess: to    *    by    *    read
    
# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcAccess: to    *    by    *    none
    
dn: olcDatabase=bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: bdb
olcSuffix: "dc=our-domain,dc=com"
# The database directory MUST exist prior to
# running slapd AND should only be accessible
# by the slapd/tools. Mode 0700 recommended.
olcDbDirectory: /usr/local/var/openldap-data
# Indices to maintain
olcDbIndex: objectClass eq
olcDbIndex: cn,sn,mail pres,eq,approx,sub
    
# We serve small clients that do not handle referrals,
# so handle remote lookups on their behalf.
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: ldap
olcSuffix: ""
olcDbUri: ldap://ldap.some-server.com/

Limite de taille et de temps


olcLimits: ‹selector› ‹limit› [‹limit› [...]]
selector: anonymous|users|[‹dnspec›=]‹pattern›|group[/oc[/at]]=‹pattern›
‹dnspec› ::= dn[.‹type›][.‹style›]
‹type› ::= self | this
‹style› ::= exact | base | onelevel | subtree | children | regex | anonymous

unchecked définie une limite sur le nombre de candidats qu'une recherche est autorisé à examiner
size[.{soft|hard|unchecked}]=‹integer›
Contrôle pageResult total permis de retourner:
size.prtotal={‹integer›|unlimited|disabled}
contrôle pageResult:
size.pr={‹integer›|noEstimate|unlimited}

integer Taille de page maximum si aucune limite explicite n'est définies.
noEstimate ne retourne pas d'estimation du nombre d'entrée qui peuvent être retournées

olcSyncrepl

   olcSyncrepl: rid=‹replicaID› provider=ldap[s]://‹hostname›[:port] searchbase=‹baseDN› [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[‹retry interval› ‹# of retries›]+] [filter=‹filterstr›] [scope=sub|one|base|subord] [attrs=‹attrlist›] [exattrs=‹attrlist›] [attrsonly] [sizelimit=‹limit›] [timelimit=‹limit›] [schemachecking=on|off] [network-timeout=‹seconds›] [timeout=‹seconds›] [bindmethod=simple|sasl] [binddn=‹dn›] [saslmech=‹mech›] [authcid=‹identity›] [authzid=‹identity›] [credentials=‹passwd›] [realm=‹realm›] [secprops=‹properties›] [keepalive=‹idle›:‹probes›:‹interval›] [starttls=yes|critical] [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_crlcheck=none|peer|all] [suffixmassage=‹real DN›] [logbase=‹base DN›] [logfilter=‹filterstr›] [syncdata=default|accesslog|changelog]

rid ID qui identifie la directive syncrepl dans le site de réplication.
provider Spécifie le fournisseur de réplication contenant le contenu master
searchbase, scope, filter, attrs, attrsonly, sizelimit, timelimit servent de spécification pour filtrer le contenu du réplica
refreshOnly la prochaine opération de recherche de synchronisation est re-planifiée à intervalle définis par interval.
refreshAndPersist la synchronisation est persistante
retry Si la connexion est perdue, retente avec des pair de valeur ‹retry inval› et ‹# of retries›. ex: retry"60 10 300 3". + vaut indéfinis
schemachecking Force la vérification du schéma.
network-timeout Définis le temps d'établissement d'une connexion réseau avec le fournisseur
timeout Détermine le temps que le client attend que la requête Bind initiale soit complétée
bindmethod simple, sasl
binddn DN pour un simple bind
saslmech requis pour SASL
authcid Identité et/ou crédentials pour l'authentification sasl
authzid identité d'authorisation
credentials Crédentials pour le bind
realm Royaume SASL
secprops Définis les propriétés de sécurité spécifiques
keepalive Définis les valeurs de idle (temps avant un TCP keepalive), probes (nombre max de keepalive avant de fermer la connexion) et intervalles (temps entre les keepalive)
starttls Spécifie l'utilisation de l'opération étendue StartTLS pour établir une session TLS.
tls_cert Certificat pour la connexion TLS
tls_key Clé privée
tls_cacert Fichier contenant les certificats CA
tls_cacertdir Répertoire contenant les certificats CA
tls_reqcert Spécifie si le certificat est requis
tls_ciphersuite Spécifie la suite de chiffrement et l'ordre à utiliser
tls_crlcheck Vérifie les certificat dans la CRL
suffixmassage Permet au client de pousser des entrée depuis un annuaire distant dont le suffixe DN diffère de l'annuaire local Les entrée qui matche le searchbase seront remplacé avec ce DN
logbase Fichier où écrire les logs
logfilter Filtre pour les logs
syncdata accesslog, les logs sont conforme à slapo-accesslog. changelog les logs sont conforme au format changelog (obsolète). default, les paramètres de logs sont ignorés
^
19 octobre 2013

htmlpdflatexmanmd




slapd-dnssrv

slapd-dnssrv

Backend dnssrv

   Backend servant de référant basé sur des enregistrements SRV dans le DNS. Il n’a pas de backend, ni d’option spécifique. Il n’honore aucune ACL. Il n’implément que l’opération search quand le contrôle manageDSAit est utilisé.

^
19 octobre 2013

htmlpdflatexmanmd




slapd-ldap

slapd-ldap

Backend ldap

   Ce backend n'est pas une base, il agit comme proxy pour transférer des requêtes entrantes à un autre serveur LDAP. Les référants sont pleinement traités au lieu d'être retournés au client. Les sessions qui Bind explicitement avec ce backend créent toujours leur propre connexion privée au serveur LDAP distant. Les sessions anonymes vont partager une seule connexion anonyme. Pour les sessions liées avec d'autres mécanismes, toutes les sessions avec le même DN vont partager la même connexion. Celà permet d'améliorer l'efficacité du proxy.

   La base ldap peut aussi agir comme service d'information, par ex. l'identité des clients authentifiés localement est affirmé sur le serveur distant, possiblement sous une forme modifiée. Dans ce but, le proxy bind au serveur distant avec une identité administrative, et, si requis, authorise l'identité fournie.

   L'instance proxy de slapd doit contenir le schéma pour les attributs et les classes d'object utilisé dans les requêtes. slapd doit être configuré avec le support des threads, et le paramètre threads adapté.

Configuration

uri ‹ldapurl› Serveur LDAP à utiliser. Plusieurs URI peuvent être spécifiés (ex: uri "ldap://host/ ldap://backup-host/")
acl-bind bindmethod=simple|sasl [binddn=‹simple DN›] [credentials=‹simple password›] [saslmech=‹SASLmech›]
[secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›] [authzId=‹authorization ID›]
[starttls=no|yes|critical] [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisé par le proxy pour collecter les informations liées au contrôle d'accès L'identité définie par cette directive doit avoir l'accès read sur le serveur cible aux attributs utilisés sur le proxy pour la vérification des ACL.
cancel {ABANDON|ignore|exop[-discover]} Définis comment manipuler les annulations d'opérations. abandon (abandonne immédiatement l'opération), ignore (aucune action et la réponse est ignorée), exop (une opération cancel est envoyée au serveur distant), exop-discover (supporte l'opération étendue cancel)
chase-referrals {YES|no} Active/désactive le repérage de référence automatique, qui est déléguée à libldap, avec un rebind éventuel si la directive rebind-as-user est utilisée défaut : yes
conn-ttl ‹time› Force la suppression d'une connexion en cache et la recrée après le ttl donné, sans regarder s'il elle est active ou non.
idassert-authzFrom ‹authz-regexp› Sélectionne quelles identités locales sont autorisées à exploiter la fonction d'assertion d'identité
idassert-bind bindmethod=none|simple|sasl [binddn=‹simpleDN›] [credentials=‹simple password›]
[saslmech=‹SASL mech›] [secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›]
[authzId=‹authorization ID›] [authz=native|proxyauthz] [mode=‹mode›] [flags=‹flags›] [starttls=no|yes|critical]
[tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisée en interne par le proxy pour autoriser les connexions qui sont authentifiées par d'autres bases de données. L'identité définie doit avoir l'accès auth sur le serveur cible sur les attributs utilisés et doit avoir le droit d'authoriser d'autres users (proxyAuth sur tout le DN, ex: authzTo=dn.subtree:"") et le serveur distant doit avoir authz-policy mis à to ou both.
‹mode› := {legacy|anonymous|none|self} legacy implique que le proxy va effectuer un simple bind (authcDN) ou SASL (authcID) et assert l'identité du client quand il n'est pas anonyme. Anonymous et self, assert une chaîne vide ou l'identité du client, respectivement.
‹flag› := {override|[non-]prescriptive|proxy-authz-[non-]critical} override, l'assertion de l'identité prend place même quand la base est autorisée pour l'identité du client. Quand prescriptive est utilisé, les opérations échouent avec inappropriateAuthentication pour les identités dont l'assertion n'est pas permise par le motif idassert-authzFrom. non-prescriptive, les opérations sont effectuées anonymement pour les identités dont l'assertion n'est pas permise par le pattern idassert-authzFrom. proxy-authz-non-critical, le contrôle proxyAuthz contrôle n'est pas marqué comme critique, en violation de la RFC 4370. il est recommandé d'utiliser proxy-authz-critical
idassert-passthru ‹authz-regexp› Si définis, sélectionne quelle identité local bypasse l'assertion d'identité. ces identités doivent être connues par l'hôte distant. la chaîne authz-regexp suit les règles définies pour authzFrom
idle-timeout ‹time› Force une connexion en cache à être supprimée puis recrée après une timeout
keepalive ‹idle›:‹probes›:‹interval› Définis les valeurs de idle, probes et interval utilisés pour certifier si un socket est actif. idle est le nombre de secondes avant qu'une connexion non-active reçoive un keepalive. probes et le nombre maximum de keepalive, et interval est le nombre de seconde entre chaque keepalive.
network-timeout ‹time› Définis la valeur timeout réseau après que poll(2)/select(2) suivant un retour connect(2) en cas d'inactivité, en seconde
norefs ‹NO|yes› à yes, ne retourne pas de réponse de référence de recherche. (défaut : NO, sauf si LDAPv2)
noundeffilter ‹NO|yes› à yes, retourne success au lieu de rechercher si un filtre est indéfinis ou contient des portions indéfinies. Par défaut, la recherche est propagée après avoir remplacé les portions indéfinies avec (!(objectClass=*)), qui correspond à un résultat vide.
onerr {CONTINUE|stop} Permet de sélectionner le mode en cas d'erreur retourné par le serveur distant durant une recherche. à Continue, retourne un success. à stop, l'erreur est retournée au client.
protocol-version {0,2,3} Indique quel protocole utiliser pour contacter le serveur distant (0, le protocole utilisé est le même que celui utilisé par le client)
proxy-whoami NO|yes Active le proxy de l'opération WhoAmI, back-ldap va remplacer la routine whoami de slapd avec le sien.
quarantine ‹interval›,‹num›[ ;‹interval›,‹num›[...]] Met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE. retente seulement à interval seconde depuis la dernière tentative, pour exactement num fois ; puis utilise le prochain pattern. si num vaut +, retente indéfiniment.
rebind-as-user {NO|yes} à yes, les crédential du client sont mémorisés pour rebind, en tentant de re-établir une connexion perdue, ou lors de la poursuite d'aiguillage si chase-referrals est à yes.
session-tracking-request {NO|yes} Ajoute un contrôle de traçage de session pour toutes les requêtes. l'IP/hostname du client et l'identité associée à chaque requête sont envoyés au serveur distant pour information. Est incompatible avec protocol-version 2.
single-conn {NO|yes} Annule toute connexion en cache si le client se rebind
t-f-support {NO|yes|discover} Active le support des filtres absolus des serveurs distant (RFC4526).
timeout [‹op›=]‹val› [...] Permet de définir des timeouts par opération. ‹op› ::= bind, add, delete, modrdn, modify, compare, search
tls {[try-]start|[try-]propagate|ldaps} [tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand] [tls_ciphersuite=‹ciphers›] [tls_crlcheck=none|peer|all] Spécifie l'utilisation de TLS pour l'initialisation des connexions.
use-temporary-conn NO|yes Créé une connexion temporaire en compétition avec d'autres threads pour une connexion partagée. Sinon, attent jusqu'à ce qu'une connexion partagée soit disponible.
^
19 octobre 2013

htmlpdflatexmanmd




slapd-ldif

slapd-ldif

Backend ldif

   Le backend LDIF est un backend basique qui stocke les entrées dans un fichier texte ldif, et exploite le système de fichier pour créer la structure de l’arborescence de la base de données.

Configuration

directory ‹dir› le Répertoire où placer la base de données. Le répertoire doit exister

ACL

   ce backend n’honore aucune acl. Seul read est honoré
^
19 octobre 2013

htmlpdflatexmanmd




slapd-mdb

slapd-mdb

Backend mdb

   Lightning Memory-Mapped DB est similaire au backend hdb.

Configuration

checkpoint _kbyte_ _min_ Spécifie la fréquence pour vider les tampons disque de la db.
dbnosync Spécifie que le contenu sur disque de la db ne devrait pas être immédiatement synchronisé avec les changements en mémoire
directory _directory_ Spécifie le répertoire où placer la db
envflags {nosync,nometasync,writemap,mapasync} Spécifie les flags opératoire:

        nosync idem à dbnosync
        nometasync Vide les données sur envoie, mais saute la synchro des page meta. légèrement plus rapide qu’un full sync
        writemap Utilise un map mémoire en écriture. accélère les opérations d’écriture, mais rend la base vulnérable aux corruptions
        mapasync En utilisant une map mémoire en écriture et en effectuant un flush sur chaque envoie, utilise un flush asynchrone

index {_attrlist_|default} [pres,eq,approx,sub,_special_] Spécifie les index à maintenir pour les attributs donnés
maxreaders _integer_ Spécifie le nombre maximum de threads concurrent en lecture sur la db. (défaut : 126)
maxsize _bytes_ Taille max de la db en octets. (défaut 10485760). Peut être augmenté ultérieurement
mode _integer_ Spécifie le mode de protect des fichiers (défaut : 0600)
searchstack _depth_ Spécifie la profindeur de la pile utiliséepour les évaluations de filtre de recherche, 512Ko par niveau. (défaut : 16, soit 8Mo par thread)
^
20 octobre 2013

htmlpdflatexmanmd




slapd-meta

slapd-meta

Backend meta

   Effectue un proxy LDAP en respectant un jeu de serveurs LDAP distant, appelés target. Les informations contenues par ces serveurs peuvent être présentés comme appartenant à un simple DIT. Il a été conçu comme un amélioration de slapd-ldap. Ces 2 backends partagent de nombreuses fonctionnalités. L'instance proxy doit contenir le schéma pour les attributs et objectClass utilisés dans les filtres. Il doit également avoir le schéma pour les données retournées par les serveurs proxifiés

Directives de configuration spécial

conn-ttl ‹time› Force la suppression d'une connexion en cache et la recrée après le ttl donné, sans regarder s'il elle est active ou non.
default-target none Force le backend à rejeter toutes les opérations qui doivent être résolues à un simple target dans le cas ou aucun ou plusieurs target sont sélectionnés. Cette directive permet également de marquer un target spécifique comme défaut.
dncache-ttl {DISABLED|forever|‹ttl›} Définis le TTL du cache de DN. (0 désactive le cache)
onerr {CONTINUE|report|stop} Mode en cas d'erreur retournée par une target durant un recherche. Continue, continue la recherche et tente de retourner le plus de données possible. Stop, stop la recherche et retourne une erreur. report, la recherche se poursuit mais si une target retourne une erreur, le premier code d'erreur retourné est envoyé au client.
norefs ‹NO|yes› à yes, ne retourne pas de référence de recherche
noundeffilter ‹NO|yes› à yes, retourne success au lieu de rechercher si un filtre est indéfinis ou contient des portions indéfinies. Par défaut, la recherche est propagée après avoir remplacée les portions indéfinies avec (!(objectClass=*)), qui correspond à un résultat vide.
protocol-version {0,2,3} Indique quel protocole utiliser pour contacter le serveur distant (0, le protocole utilisé est le même que celui utilisé par le client)
pseudoroot-bind-defer {YES|no} à yes, l'authentification sur le serveur distant avec une identité pseudo-root (idassert-bind) est déférée jusqu'à ce qu'il soit nécessaire. Sinon, tous les binds root sont propagés aux target.
quarantine ‹interval›,‹num›[ ;‹interval›,‹num›[...]] Met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE. retente seulement à interval seconde depuis la dernière tentative, pour exactement num fois ; puis utilise le prochain pattern. si num vaut +, retente indéfiniment.
rebind-as-user {NO|yes} à yes, les crédentials du client sont mémorisés pour rebind, en tentant de re-établir une connexion perdue, ou lors de la poursuite d'aiguillage si chase-referrals est à yes.
session-tracking-request {NO|yes} Ajoute un contrôle de traçage de session pour toutes les requêtes. l'IP/hostname du client et l'identité associée à chaque requête sont envoyés au serveur distant pour information. Est incompatible avec protocol-version 2.
single-conn {NO|yes} Annule toute connexion en cache si le client se rebind
use-temporary-conn {NO|yes} Créé une connexion temporaire en compétition avec d'autres threads pour une connexion partagée. Sinon, attend jusqu'à ce qu'une connexion partagée soit disponible.

Spécification de target

uri ‹protocol›://[‹host›]/‹naming context› [...] naming context est mandatoire pour la première uri, et omis pour les autres
acl-authcDN ‹administrative DN for access control purposes› DN utilisé pour requêter le serveur distant pour vérifier les ACL. Doit avoir les accès read sur le serveur cible sur les attributs utilisés dans le proxy pour la vérification des acl.
acl-passwd ‹password› Mot de passe utilisé avec acl-authcDN
bind-timeout ‹microseconds› Timeout en micro-secondes, utilisé lors du vote pour la réponse après une connexion bind asynchrone. L'appel initial à ldap_result(3) est effectué avec un timeout de 100000us. Si le résultat excède ce timeout, les appels suivants utilisent la valeur de bind-timeout.
chase-referrals YES|no Active/désactive le repérage de référence automatique, qui est déléguée à libldap, avec un rebinding éventuel si la directive rebind-as-user est utilisée. défaut: yes
client-pr {accept-unsolicited|DISABLE|‹size›} Permet d'utiliser le contrôle paged result en requêtant un target. Le client n'est pas soumis à ce contrôle.
default-target [‹target›] Sans argument, indique que le target courant est le défaut. target est un numéro du target par défaut.
filter ‹pattern› regex pour indiquer quels termes de filtre de recherche sont servis par le target.
idassert-authzFrom ‹authz-regexp› Sélectionne quels identités local sont autorisées à exploiter la fonctionnalité d'assertion d'identité. l'expressions suit la règle définis pour authzFrom
idassert-bind bindmethod=none|simple|sasl [binddn=‹simpleDN›] [credentials=‹simple password›]
[saslmech=‹SASL mech›] [secprops=‹properties›] [realm=‹realm›] [authcId=‹authenticationID›]
[authzId=‹authorization ID›] [authz=native|proxyauthz] [mode=‹mode›] [flags=‹flags›] [starttls=no|yes|critical]
[tls_cert=‹file›] [tls_key=‹file›] [tls_cacert=‹file›] [tls_cacertdir=‹path›] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›] [tls_protocol_min=‹version›] [tls_crlcheck=none|peer|all] Permet de définir les paramètres de la méthode d'authentification utilisée en interne par le proxy pour autoriser les connexions qui sont authentifiées par d'autres bases de données. L'identité définie doit avoir l'accès auth sur le serveur cible sur les attributs utilisés et doit avoir le droit d'authoriser d'autres users (proxyAuth sur tout le DN, ex : authzTo=dn.subtree :"") et le serveur distant doit avoir authz-policy mis à to ou both.
‹mode› := {legacy|anonymous|none|self} legacy implique que le proxy va effectuer un simple bind (authcDN) ou SASL (authcID) et assert l'identité du client quand il n'est pas anonyme. Anonymous et self, assert une chaîne vide ou l'identité du client, respectivement.
‹flag› := {override|[non-]prescriptive|proxy-authz-[non-]critical} override, l'assertion de l'identité prend place même quand la base est autorisée pour l'identité du client. Quand prescriptive est utilisé, les opérations échouent avec inappropriateAuthentication pour les identités dont l'assertion n'est pas permise par le motif idassert-authzFrom. non-prescriptive, les opérations sont effectuées anonymement pour les identité dont l'assertion n'est pas permise par le pattern idassert-authzFrom. proxy-authz-non-critical, le contrôle proxyAuthz contrôle n'est pas marqué comme critique, en violation de la RFC 4370. il est recommandé d'utiliser proxy-authz-critical
idle-timeout ‹time› Force une connexion en cache à être supprimée puis recrée après une timeout
keepalive ‹idle›:‹probes›:‹interval› Définis les valeurs de idle, probes et interval utilisés pour cérifier si un socket est actif. idle est le nombre de seconde avant qu'une connexion non-active reçoive un keepalive. probes et le nombre maximum de keepalive, et interval est le nombre de seconde entre chaque keepalive.
map {attribute|objectclass ‹local name› ‹foreign name›|*} Map des classes d'objet et des attributs comme dans le backend ldap
network-timeout ‹time› Définis la valeur timeout réseau après que poll(2)/select(2) suivant un retour connect(2) en cas d'inactivité, en seconde
nretries {forever|never|‹nretries›} Définis le nombre de fois qu'un bind doit être retenté en cas d'échec temporaire. (défaut : 3)
rewrite*... Permet de réecrire des requêtes
subtree-{exclude|include} ‹rule› Permet d'indiquer quels subtrees sont actuellement servis par un target. Peut être spécifié plusieurs fois. les syntaxes supportées sont:

        ‹rule›: [dn[.‹style›]:]‹pattern›
        ‹style›: subtree|children|regex style est soit subtree, children ou un regexp. pattern est un DN qui doit être dans le contexte de nommage servis par le target, ou un regex si style vaut regex. Si dn.‹style› est omis, dn.subtree est implicite
        Dans la forme subtree-exclude, si le DN demandé match au moins une règle, la cible n'est pas considérée pour remplir la requête.
        Dans la forme subtree-include, si le DN demandé match au moins une règle, la cible est considérée basée sur la valeur du request DN.

suffixmassage ‹virtual naming context› ‹real naming context› Toutes les directives commençant par "rewrite" obsolète par slapo-rwm.
t-f-support {NO|yes|discover} Permet le support des filtres absolus des serveur distant
timeout [‹op›=]‹val› [...] Définis un timeout par opération. Les opérations peuvent être : ‹op› ::= bind, add, delete, modrdn, modify, compare, search
tls {[try-]start|[try-]propagate} Exécute StartTls quand la connexion est initialisée. Ne fonctionne qu'avec ldaps://

scénarios

1. 2 serveurs partagent 2 niveaux de contexte de nommage, "dc=a,dc=foo,dc=com" et "dc=b,dc=foo,dc=com". Un meta annuaire peut être configuré comme:
database meta
suffix "dc=foo,dc=com"
uri "ldap://a.foo.com/dc=a,dc=foo,dc=com"
uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
Les opérations dirigées vers un target spécifique peuvent facilement être résolus parce qu'il n'y pas d'ambiguïté. La seule opération qui peut résoudre plusieurs target est une recherche avec une base "dc=foo,dc=com". qui résulte de 2 recherches dans les targets.

2. 2 serveurs ne partagent aucune portion du contexte de nommage, mais ils se présentent en un simple DIT. "dc=bar,dc=org" et "o=Foo,c=US" qui apparaissent comme des branches de "dc=foo,dc=com", disons "dc=a,dc=foo,dc=com" et "dc=b,dc=foo,dc=com". On doit configurer le backend meta comme suit:
database meta
suffix "dc=foo,dc=com"
uri "ldap ://a.bar.com/dc=a,dc=foo,dc=com"
suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap ://b.foo.com/dc=b,dc=foo,dc=com"
suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"
De même, les opérations peuvent être résolus sans ambiguïté, bien qu'une réécriture soit requise. Noter que le contexte de nommage de chaque cible est une branche du contexte de nommage de la base. lors d'une recherche avec la base "dc=foo,dc=com" et un scope base, une erreur no such object est générée. Si le scope est one, les 2 targets sont contactés.

3. En utilisant le scénario précédent avec 2 serveurs partageant le même contexte de nommage:
database meta
suffix "dc=foo,dc=com"
uri "ldap ://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap ://b.foo.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "o=Foo,c=US"
Toutes les considérations précédente sont maintenues, excepté que maintenant il n'y a plus d'ambiguïté pour résoudre un DN

ACL

   Vous pouvez ajouter toutes les ACL au backend meta. Cependant, la signification d'un ACL sur un proxy peut nécessiter certaines considérations.

- Le serveur distant dicte les permissions ; le proxy passe simplement ce qu'il reçoit au serveur distant
- Le serveur distant dévoile tout, le proxy est responsable de la protection des accès non autorisés.

rewriting

   La syntaxe et le fonctionnement est le même que slapo-rwm
^
20 octobre 2013

htmlpdflatexmanmd




slapd-monitor

slapd-monitor

Backend monitor

   Ce backend n’est pas une base de données, il ne peut en exister qu’un seul sur un serveur. Il est automatiquement généré et maintenu par slapd. Pour inspecter toutes les informations monitorées, fournir une recherche dans un subtree avec la base cn=monitor. Il produit principalement des attributs opérationnels.

pour activer ce backend:
database monitor
Ajouter des acl à cette base:
access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none

   Monitor honore les acl. Il n’honore pas les limites dans les opérations de recherche

^
20 octobre 2013

htmlpdflatexmanmd




slapd-ndb

slapd-ndb

Backend ndb

   Backend utilisant l’API NDB de MySQL cluster

OPTIONS

dbhost ‹hostname› Nom du serveur MySQL
dbuser ‹username› User MySQL
dbpasswd ‹password› Mot de passe du compte MySQL
dbname ‹database name› Base de données à utiliser
dbport ‹port› Port d’écoute du serveur MySQL
dbsocket ‹path› Socket à utiliser pour se connecter à un serveur local
dbflag ‹integer› Flags client pour la session MySQL
dbconnect ‹connectstring› Nom du cluster manager
dbconnections ‹integer› Nombre de connections cluster à établir, jusqu’à 4 (défaut : 1)

Configuration du schéma

attrlen ‹attribute› ‹length› Spécifie la longueur de colonne à utiliser pour un attribut particulier (défaut : 128 octets). Max 1024
index ‹attr[,attr...]› Liste d’attributs pour lesquels maintenir un index
attrset ‹set› ‹attrs› Liste d’attributs à traiter comme jeu d’attributs. Créé une table set qui contiend tous ces attributs. Normalement, un attribut réside dans une table nommée par une classe d’objet qui utilise l’attribut. Cependant les attributs sont seulement permis dans une seule table. Ce jeu d’attribut permet de placer des attributs dans une table qui sont définis pour plusieurs classes d’objet.

ACL

   ndb honore la plupart des ACL
^
08 septembre 2013

htmlpdflatexmanmd




slapd-null

slapd-null

Backend null

   Backend conçus à des fins de test. Les recherches et les mises à jours retournent un success, les comparaison retournent compareFalse.

OPTIONS

bind Autorise les binds à ce backend.

Contrôle d'accès

   ce backend ne respecte aucune ACL
^
08 septembre 2013

htmlpdflatexmanmd




slapd-passwd

slapd-passwd

Backend passwd

   Backend /etc/passwd

OPTIONS

file ‹filename› Fichier passwd alternatif.

Contrôle d'accès

   ce backend ne respecte aucune ACL
^
20 octobre 2013

htmlpdflatexmanmd




slapd-perl

slapd-perl

Backend perl

   Backend embarquant un interpréteur perl. Il faut créer une méthode pour chacune de ces actions:

new Appelé quand le fichier de configuration rencontre une ligne perlmod. Plusieurs instances de cet objet peuvent être instanciés
search Ses arguments sont les suivants:

        référence objet
        base DN
        scope
        stratégie de déréférencement des alias
        size limit
        time limit
        Filtre
        Flag attribut uniquement
        liste des attributs à retourner

compare ses arguments sont: référence objet, dn, attribut assertion
modify ses arguments sont: référence objet, dn, une liste formatée comme suis : ({ "ADD" | "DELETE" | "REPLACE" }, attributetype, value...)...
add ses arguments sont: référence objet, Entrée au format chaîne
modrdn ses arguments sont: référence objet, dn, new rdn, flag delete old
delete ses arguments sont: référence objet, dn
config Appelé une fois pour chaque perlModuleConfig dans le fichier de configuration. ses arguments sont: référence objet, tableau des arguments
init Appelé après que le backend est été initialisé. ses arguments sont: référence objet

OPTIONS

perlModulePath /path/to/libs Ajouter le chemin de la variable @INC
perlModule ModName Utilise le module spécifié
filterSearchResults Les résultat de recherche sont candidats qui doivent être filtré (avec le filtre de la requête).
perlModuleConfig ‹arguments› invoque la méthode config du module avec les arguments donnés

ACL

   Ce backend n’honore aucune ACL. Seul read sur les attributs est géré par le frontend
^
20 octobre 2013

htmlpdflatexmanmd




slapd-relay

slapd-relay

Backend relay

   backend relay. Il permet de mapper un contexte de nommage, avec manipulation d'attributs et classes d'objet. Il nécessite l'overlay slapo-rwm

OPTIONS

relay ‹real naming context› Le contexte de nommage qui sera présenté sous un contexte de nommage virtuel.

ACL

   Un problème important est que les règles d'accès sont basés sur l'identité qui a soumis l'opération. Après le massaging du contexte de nommage, le frontend vois les opérations effectuées par l'identité du vrai contexte de nommage. En concéquence, le base doit fournir ses propre règles.

  relay n'honore aucune ACL, il délègue les règles aux bases distantes.

Exemples

Pour implémenter un mappage de contexte de nommage qui réfère à une simple base:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Pour implémenter un mappage de contexte de nommage qui recherche le vrai contexte de nommage pour chaque opération:
database relay
suffix "dc=virtual,dc=naming,dc=context"
overlay rwm
rwm-suffixmassage "dc=real,dc=naming,dc=context"
Une configuration identique mais en remplaçant suffixmassage par une réécriture explicite:
database relay
suffix "dc=virtual,dc=naming,dc=context"
relay "dc=real,dc=naming,dc=context"
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext default
rwm-rewriteRule "dc=virtual,dc=naming,dc=context" "dc=real,dc=naming,dc=context" ":@"
rwm-rewriteContext searchFilter
rwm-rewriteContext searchEntryDN
rwm-rewriteContext searchAttrDN
rwm-rewriteContext matchedDN
Configuration des règles d'accès:
database bdb
suffix "dc=example,dc=com"
# skip...
access to dn.subtree="dc=example,dc=com"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by * read
database relay
suffix "o=Example,c=US"
relay "dc=example,dc=com"
overlay rwm
rwm-suffixmassage "dc=example,dc=com"
# skip ...
access to dn.subtree="o=Example,c=US"
by dn.exact="cn=Supervisor,dc=example,dc=com" write
by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
by * read
^
20 octobre 2013

htmlpdflatexmanmd




slapd-shell

slapd-shell

Backend shell

   Backend qui exécute des programmes externe pour implémenter les opérations

OPTIONS

add ‹pathname› ‹argument›...
ADD
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
‹entry in LDIF format›

bind ‹pathname› ‹argument›...
BIND
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
method: ‹method number›
credlen: ‹length of ‹credentials››
cred: ‹credentials›

compare ‹pathname› ‹argument›...
COMPARE
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
‹attribute›: ‹value›

delete ‹pathname› ‹argument›...
DELETE
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›

modify ‹pathname› ‹argument›...
MODIFY
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
‹repeat {
‹"add"/"delete"/"replace"›: ‹attribute›
‹repeat { ‹attribute›: ‹value› }›
-
}›

modrdn ‹pathname› ‹argument›...
MODRDN
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹DN›
newrdn: ‹new RDN›
deleteoldrdn: ‹ 0 or 1 ›
‹if new superior is specified: "newSuperior: ‹DN›"›

search ‹pathname› ‹argument›...
SEARCH
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
base: ‹base DN›
scope: ‹ 0-2, see ldap.h ›
deref: ‹ 0-3, see ldap.h ›
sizelimit: ‹size limit›
timelimit: ‹time limit›
filter: ‹filter›
attrsonly: ‹ 0 or 1 ›
attrs: ‹"all" or space-separated attribute list›

unbind ‹pathname› ‹argument›...
UNBIND
msgid: ‹message id›
‹repeat { "suffix:" ‹database suffix DN› }›
dn: ‹bound DN›

ACL

   Ce backend n'honore pas toutes les ACL. en général les acl sur les objets sont vérifiés en utilisant un objet factice qui contient seulement le DN, donc les règles d'accès qui s'occupent du contenu de l'objet ne sont pas honorés

l'opération add ne nécessite pas write sur children de l'entrée parent.
l'opération bind nécessite auth sur entry
l'opération compare nécessite read sur entry
l'opération delete ne nécessite pas write sur children de l'entrée parent
l'opération modify nécessite write sur children de l'entrée parent
l'opération modrdn ne nécessite pas write sur children de l'entrée parent
l'opération search ne nécessite pas l'accès search sur entry

Limitations

   Ce backend ne supporte pas les environnement multi-threadés. slapd doit être construit avec --without-threads
^
27 octobre 2013

htmlpdflatexmanmd




slapd-sql

slapd-sql

Backend sql

   Backend SQL pour slapd. Il permet de présenter les informations stockées dans un RDBMS sous forme d’entrée LDAP.

options - Configuration de source de données

dbname ‹datasource name› Le nom de la source ODBC à utiliser
dbhost ‹hostname›
dbpasswd ‹password›
dbuser ‹username› Informations de connections à la source ODBC

options - Configuration de scope

subtree_cond ‹SQL expression› template where-clause pour former une condition de recherche de subtree (dn="(.+,) ?‹dn›$"). (ex: "‹upper_func›(ldap_entries.dn) LIKE CONCAT(’%’, ?)")
children_cond ‹SQL expression› template where-clause pour former une condition de recherche enfant (dn=".+,‹dn›$"). (ex: "‹upper_func›(ldap_entries.dn) LIKE CONCAT(’%,’, ?)")
use_subtree_shortcut YES Ne pas utiliser de condition de subtree quand la base de recherche est le suffix de la base.

options - Configuration de déclarations

oc_query ‹SQL expression› requête utilisée pour collecter le mapping des objectClass depuis la table ldap_oc_mappings. (défaut : "SELECT id, name, keytbl, keycol, create_proc, delete_proc, expect_return FROM ldap_oc_mappings")
at_query ‹SQL expression› requête utilisée pour collecter le mapping des attributeType depuis la table ldap_attr_mappings
id_query ‹SQL expression› requête utilisée pour mapper un DN à une entrée dans la table ldap_entries (défaut : "SELECT name, sel_expr, from_tbls, join_where, add_proc, delete_proc, param_order, expect_return FROM ldap_attr_mappings WHERE oc_map_id= ?") )
insentry_stmt ‹SQL expression› requête utilisée pour insérer une nouvelle entrée dans la table ldap_entries (défaut : "INSERT INTO ldap_entries (dn, oc_map_id, parent, keyval) VALUES (?, ?, ?, ?)" )
delentry_stmt ‹SQL expression› requête utilisée pour supprimer une entrée existante depuis la table ldap_entries (défaut : "DELETE FROM ldap_entries WHERE id= ?")
delobjclasses_stmt ‹SQL expression› requête utilisée pour supprimer l’ID d’une entrée dans la table ldap_objclasses. (défaut : "DELETE FROM ldap_entry_objclasses WHERE entry_id= ?"

options - Configuration helper

upper_func ‹SQL function name› Spécifie le nom d’un fonction qui convertit une valeur en majuscule (ex : UCASE, UPPER)
upper_needs_cast NO Définis si upper_func doit explicitement être utilisé sur des chaînes littérales.
strcast_func ‹SQL function name› Spécifie le nom d’une fonction qui convertis une valeur donnée en chaîne pour l’ordonnancement. Utilisé dans SELECT DISTINCT.
concat_pattern ‹pattern› Définis le pattern utilisé pour concaténer les chaînes. le pattern doit contenir 2 ’ ?’ qui seront remplacés par 2 chaînes à concaténer. (défaut : CONCAT(?, ?), PostfreSQL : ?|| ? )
aliasing_keyword ‹string› Définis le mot clé d’alias. défaut : AS
aliasing_quote ‹string› Définis le caractère de quoting pour les mots clé d’alias. défaut : aucun.
has_ldapinfo_dn_ru NO Informe explicitement le backend si la colonne dn_ru (DN sous forme majuscule inversé) est présent dans la table ldap_entries.
fail_if_no_mapping NO Force les opérations d’écriture d’attribut à échouer si aucun mapping approprié n’est disponible. uniquement pour les attributs. N’a pas d’impacte sur les classec d’objet.
allow_orphans NO Permet d’ajouter des entrées orphelines.
baseObject [ ‹filename› ] Instruit la base de créer et gérer une entrée baseObject en mémoire au lieu d’en chercher un dans le RDBMS. Si filename est fournis, l’entrée est lue depuis ce ldif. Utile quand les informations ldap_entries sont stockés dans une vue et union n’est pas supporté pour les vues
create_needs_select NO Instruit la base si la création d’entrée dans la table ldap_entries a besoin d’un select pour collecter l’ID assigné automatiquement, au lieu d’être retourné par une procédure stockée.
fetch_attrs ‹attrlist›
fetch_all_attrs NO Le premier état permet de fournir un liste d’attributs qui doivent toujours être remplis en plus de ceux requis par un opération spécifique. Pour l’instant, tous les attributs utilisés dans les ACL devraient être listés ici. Le second état est un raccourci pour tous les atributs
check_schema YES Instruit la base de vérifier l’adhérence des entrées au schéma après modification.
sqllayer ‹name› [...] Charge la couche name dans la pile d’helpers qui sont utilisés pour mapper les DN de LDAP vers la représentation SQL et inversement. Les arguments suivants sont passés à la routine de configuration.
autocommit NO Active l’autocommit. défaut : off

Exemples

Supposons que l’on stocke des informations sur des personnes travaillant dans notre organisation dans 2 tables:
PERSONS PHONES
-------------
id integer id integer
first_name varchar pers_id integer references persons(id)
last_name varchar phone
middle_name varchar
...
Une personne peut avoir plusieurs téléphones, phone peut contenir plusieurs enregistrements avec le pers_id correspondant, ou aucun. Une classe d’objet LDAP pourrait présenter de tels informations comme ceci:
person
MUST cn
MAY telephoneNumber $ firstName $ lastName
...
Pour renseigner toutes les valeurs cn, on construit la requête:
SELECT CONCAT(persons.first_name,’ ’,persons.last_name) AS cn FROM persons WHERE persons.id= ?
Pour telephoneNumber on peut utiliser:
SELECT phones.phone AS telephoneNumber FROM persons,phones WHERE persons.id=phones.pers_id AND persons.id= ?
Si on veut des requêtes LDAP avec des filtres tels que (telephoneNumber=123*), on peut construire :
SELECT ... FROM persons,phones WHERE persons.id=phones.pers_id AND persons.id= ? AND phones.phone like ’%1%2%3%’
On a donc les informations sur quelles tables contiennent les valeurs de chaque attribut, comment joindre ces tables et arranger les valeurs, on pourrait essayer de générer automatiquement de tels déclaration, et traduire les filtres de recherche en clause WHERE.
Pour stocker de tels informations, on ajoute 3 tables de plus à notre schéma:
ldap_oc_mappings (some columns are not listed for clarity)
^
26 septembre 2013

htmlpdflatexmanmd




slapd.conf

slapd.conf

Fichier de configuration de slapd (ancien format)

   Le fichier de configuration (slapd.conf) consiste de 3 types d'information de configuration: global, backend et database. Les informations globales sont spécifiées en premier, suivis par les informations associées avec un type de backend particulier, puis les informations associées avec un type particulier de base. Les directives globales peuvent être écrasées par des directives de base ou de backend, et les directives backend peuvent être écrasées par les directives de base de données.

  Les lignes blanches et les lignes de commentaire commençant par un # et sont ignorées. Si une ligne commence par un espace blanc, il est considéré comme la suite de la ligne précédente (même si la précédente ligne est un commentaire).

Format général


# Directives de configuration globale:
‹global config directives›
    
# backend definition
backend ‹typeA›
‹backend-specific directives›
    
# first database definition & config directives
database ‹typeA›
‹database-specific directives›
    
# second database definition & config directives
database ‹typeB›
‹database-specific directives›
    
# second database definition & config directives
database ‹typeA›
‹database-specific directives›
    
# subsequent backend & database definitions & config directives
...

Directives Global

   Les directives décrites dans cette section s'appliquent à tous les backend et bases.

access to ‹what› [ by ‹who› [‹accesslevel›][‹control›]]+ Cette directive donne accès spécifié par accesslevel à un set d'entrée et/ou d'attributs spécifiés par what, par un ou plusieurs utilisateurs spécifiés par who. note: si aucune directive access n'est spécifié, la politique est access to * by * read.
attributetype ‹rfc4512 Attribute Type Description› cette directive définit un type d'attribut.
idletimeout ‹integer› Spécifie le nombre de secondes à attendre avant de forcer la fermeture de la connexion d'un client. à 0, désactive la fonction.
include ‹filename› Spécifie une fichier à lire, contenant d'autres informations de configuration. Généralement utilisé pour inclure les spécification de schéma.
loglevel ‹integer› Cette directive spécifie le niveau de log (actuellement placé dans syslogd LOG_LOCAL4). Le loglevel peut être spécifié sous forme d'entier ou par mot clé.

level_keyword________Description
-1____any____________enable all debugging
0____________________no debugging
1_____(0x1 trace)____trace function calls
2_____(0x2 packets)__debug packet handling
4_____(0x4 args)_____heavy trace debugging
8_____(0x8 conns)____connection management
16____(0x10 BER)_____print out packets sent and received
32____(0x20 filter)__search filter processing
64____(0x40 config)__configuration processing
128___(0x80 ACL)_____access control list processing
256___(0x100 stats)__stats log connections/operations/results
512___(0x200 stats2)_stats log entries sent
1024__(0x400 shell)__print communication with shell backends
2048__(0x800 parse)__print entry parsing debugging
16384_(0x4000 sync)__syncrepl consumer processing
32____(0x8000 none)___only messages that get logged whatever log level is set

on peut additionner les valeurs:
loglevel 129
loglevel 0x81
loglevel 128 1
sont équivalent:
loglevel 0x80 0x1
et
loglevel acl trace

objectclass ‹rfc4512 Object Class Description› Cette directive définit une classe objet
referral ‹URI› Cette directive spécifie le référant quand slapd ne peut trouver une base locale pour manipuler les requêtes.
sizelimit ‹integer› Cette directive spécifie le nombre maximum d'entrée à retourner pour une opération de recherche. défaut: sizelimit 500
timelimit ‹integer› Cette directive spécifie le nombre maximum de seconde que slapd va passer à répondre à une requete. Au delà, il envoie un exceeded timelimit. defaut: timelimit 3600

Directives Backend

   Les directives dans cette section s'appliquent uniquement au backend dans lequel elles sont définies. Elles sont supportées par tous les types de backend. Les directives d'un backend s'appliquent à toutes les instances de base du même type.

backend ‹type› Cette directive marque le début d'une déclaration backend. ‹type› peut être un des types supportés:

Types___Description
bdb_____Berkeley DB transactional backend
dnssrv__DNS SRV backend
hdb_____Hierarchical variant of bdb backend
ldap____Lightweight Directory Access Protocol (Proxy) backend
meta____Meta Directory backend
monitor_Monitor backend
passwd__Provides read-only access to passwd(5)
perl____Perl Programmable backend
shell___Shell (extern program) backend
sql_____SQL Programmable backend

Directives générales de bases de données

   Les directives dans cette section s'appliquent uniquement à la base dans laquelle elles sont définies

database ‹type› Cette directive marque le début d'une déclaration d'instance de base. ‹type› doit être un des type de backend supporté.
limits ‹who›‹limit›[‹limit›[...]] spécifie les limites de temps et de taille sur qui initie une opération
readonly on|off Cette directive place la base en lecture seule
rootdn ‹DN› Cette directive spécifie le DN qui n'est pas sujet aux restriction de limites administratives et de contrôle d'accès pour les opérations sur cette base. le DN doit référer à une entrée dans l'annuaire. Le DN peut référer à une identité SASL. (ex: rootdn "cn=Manager,dc=example,dc=com", avec sasl: rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth")
rootpwd ‹password› Cette directive spécifie le mot de passe pour le rootdn. Il est possible d'utiliser slappasswd -s pour générer un hash.
suffix ‹dn suffix› Cette directive spécifie le suffixe DN des requêtes qui seront passé à cette base. Plusieurs lignes peuvent être spécifiées, et au moins une est requise pour chaque définition de base.(ex: suffix "dc=example,dc=com" # les requêtes avec un DN se terminant avec "dc=Example,dc=com" seront passées à ce backend)
syncrepl
syncrepl rid=‹replica ID›
provider=ldap[s] ://‹hostname›[:port]
type=refreshOnly
[interval=dd:hh:mm:ss]
[retry=[‹retry interval› ‹# of retries›]+]
searchbase=‹base DN›
[filter=‹filter str›]
[scope=sub|one|base]
[attrs=‹attr list›]
[attrsonly]
[sizelimit=‹limit›]
[timelimit=‹limit›]
schemachecking=on
bindmethod=simple
[binddn=‹DN›]
[saslmech=‹mech›]
[authcid=‹identity›]
[authzid=‹identity›]
[credentials=‹passwd›]
[realm=‹realm›]
[secprops=‹properties›]
starttls=yes
[tls_cert=‹file›]
[tls_key=‹file›]
[tls_cacert=‹file›]
[tls_cacertdir=‹path›]
[tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=‹ciphers›]
[tls_crlcheck=none|peer|all]
[logbase=‹base DN›]
[logfilter=‹filter str›]
[syncdata=default|accesslog|changelog] Cette directive spécifie la base courante comme réplique du contenu d'un master en utilisant le moteur de réplication syncrepl.

provider indique le master. spécifie un schéma, un hôte et un port
rid est utilisé pour l'identification de la directive syncrepl courante dans le serveur de réplication.
searchbase n'a pas de valeur par défaut et doit toujours être spécifié.
scope est à sub par défaut
filter est à (objectclass=*) par défaut
attrs à "*,+" par défaut pour répliquer tous les utilisateurs et tous les attributs optionnels
attrsonly est désactivé par défaut
sizelimit est à unlimited par défaut
timelimit est à unlimited par défaut

   Le protocole de synchronisation de contenu LDAP à 2 types d'opérations: refreshOnly et refreshResultEntry. Avec RefreshOnly, la synchronisation est périodique. l'interval est spécifié par le paramètre interval. Par défaut il est à 1 jour. Avec refreshAndPersist, la synchronisation est persistante.

   Si une erreur se produit durant la réplication, le réplicateur tente de se reconnecter en accord avec le paramètre retry, qui est une liste de paire de paramètres ‹retry interval› et ‹# of retries›. Par exemple, retry "60 10 300 3" tente de se reconnecter toutes les 60 secondes, 10 fois, puis retente toutes les 300 secondes, 3 fois, avant de stopper la tentative de reconnexion.

   La vérification de schéma peut être renforcée avec le paramètre schemachecking. Activé, toute entrée répliquée sera vérifié pour ce schéma avant de le stocker. Le paramètre binddn donne le DN à lier pour la recherche syncrepl. Il doit être un DN qui a les droits d'accès en lecture.

   bindmethod est simple ou sasl, en fonction si l'authentification par mot de passe est simple pour sasl. L'authentification simple ne devrait pas être utilisé a moins que l'intégrité des données des protections de confidentialité soient en place (par exemple: TLS ou IPsec) L'authentification simple requière les paramètres binddn et credentials. L'authentification SASL requière la spécification d'un mécanisme utilisant le paramètre saslmech. authcid et credential peuvent être spécifiés pour l'identité d'authentification et le credential. authzid peut être utilisé pour spécifier l'identité d'autorisation.

   le paramètre realm spécifie un domaine. le paramètre secprops spécifie les propriétés de sécurité Cyrus SASL.

  starttls spécifie l'utilisation de TLS. Si l'argument critical est spécifié, la session sera abordée si la requête StartTLS échoue. Sinon la session SyncRepl continu sans TLS.

   Au lieu de répliquer toutes les entrées, le réplicateur peut chercher les logs de modification de données. Ce mode d'opération s'appel delta syncrepl. En plus des paramètres ci-dessus, les paramètres logbase et logfilter doivent être spécifiés pour les logs à utiliser. Le paramètre syncdata doit être soit à "accesslog" si le log est conforme au format slapo-accesslog ou "changelog". Si le paramètre syncdata est omis ou à "default", les paramètres de log seront ignorés. La réplication syncrepl est supportées par bdb et hdb.

updateref ‹URL› Cette directive est seulement applicable dans un slave. Il spécifie l'URL à retourner aux clients qui envoient des requêtes de mise à jours sur la réplique. Peut être spécifié plusieurs fois.
directives de base BDB et HDB Ces directives s'appliquent uniquement aux bases BDB et HDB.
directory ‹directory› Cette directive spécifie le dossier où les fichiers contenant la base et indices associés sont stockés.

Exemple de fichier de configuration

L'exemple suivant définit 2 bases pour manipuler différentes parties d'un arbre x500. Les 2 bases sont des instances BDB.
# example config file - global configuration section
include /usr/local/etc/schema/core.schema # inclue un fichier de définition de schéma
referral ldap ://root.openldap.org # les requêtes non local sur une des bases définies vont référer au server LDAP à l'hôte root.openldap.org
access to    *    by    *    read # Contrôle d'accès global.
    
# BDB definition for the example.com
database bdb
suffix "dc=example,dc=com" # suffix DN pour cette base
directory /usr/local/var/openldap-data # dossier où se trouve les fichiers de cette base.
rootdn "cn=Manager,dc=example,dc=com" # rootdn pour cette base
rootpw secret # mdp du rootdn
# indexed attribute definitions
index uid pres,eq # indique les indices pour maintenir divers attributs
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
# database access control definitions
access to attrs=userPassword # Spécifier le controle d'accès pour les entrées dans cette base.
by self write
by anonymous auth
by dn.base="cn=Admin,dc=example,dc=com" write
by    *    none
access to    *
by self write
by dn.base="cn=Admin,dc=example,dc=com" write
by    *    read
    
# BDB definition for example.net
database bdb
suffix "dc=example,dc=net"
directory /usr/local/var/openldap-data-net
rootdn "cn=Manager,dc=example,dc=com"
index objectClass eq
access to    *    by users read

^
08 septembre 2013

htmlpdflatexmanmd




slapdn

slapdn

Vérifie une liste de DN basé sur une définition de schéma dans la configuration de slapd

OPTIONS

-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-N Affiche seulement une forme normalisée des DN, incompatible avec -P
-o option[=value] Spécifie une option slapd
-P Affiche seulement une forme édulcorée du DN
-v mode verbeux
^
08 septembre 2013

htmlpdflatexmanmd




slapindex

slapindex

Réindex les entrées dans une base slapd

OPTIONS

-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug-level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
dbnum Génère une sortie pour la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-q mode rapide (peu de vérifications)
-t active le tronquage. uniquement en mode rapide
-v mode verbeux

limitations

   slapd ne devrait pas être en cours de fonctionnement, ou au moins en lecture seule.

Exemples

pour régénérer l’index pour un attribut spécifique
slapindex uid
^
28 septembre 2013

htmlpdflatexmanmd




slapo-accesslog

slapo-accesslog

Overlay accesslog

   Overlay de log des accès. Il permet d'enregistrer tous les accès à la base de données dans une autre base.

Configuration

logdb ‹suffix› Spécifie le suffix d'une base de données à utiliser pour stocker les enregistrements.
logops ‹operations› Spécifie quel types d'opérations logger. (abandon, add, bind, compare, delete, extended, modify, modrdn, search, unbind, et les alias writes (add, delete, modify, modrdn), reads (compare, search), session (abandon, bind, unbind) et all (toutes les opérations) )
logbase ‹operations›‹baseDN› Spécifie un jeu d'opérations qui seront loggés uniquement s'ils se produisent dans une arborescence spécifique de la base, et délimités par le caractère '|'
logold ‹filter› Spécifie un filtre pour matcher les entrées supprimées et modifiées. Si l'entrée match le filtre, l'ancienne entrée sera loggées avec la requête en cour.
logoldattr ‹attr› Spécifie une liste d'attributs loggés.
logpurge ‹age›‹interval› Spécifie la durée maximal pour les entrées à maintenir dans la base. et la fréquence de scan de la base pour les anciennes entrées. le format de date est [ddd+]hh:mm[:ss]. ex: logpurge 2+00:00 1+00:00 pour un scan quotidien avec suppression des entrées de plus de 2 jours.
logsuccess TRUE | FALSE à TRUE, les enregistrement seront loggés uniquement si la requête produit un succès. défaut : FALSE

Schéma

   accesslog utilise le schéma audit décrit ici. ce schéma est conçu spécifiquement pour cet overlay.

auditObject 2 classes en sont dérivés : auditReadObject et auditWriteObject.
reqStart
reqEnd Fournissent l'heure de début et de fin de l'opération.
reqType Décrit le type d'opération qui est loggée.
reqSession Identifiant commun à toutes les opérations associées avec la même session LDAP
reqDN DN de la cible de l'opération
reqAuthzID DN de l'utilisation qui a effectué l'action
reqControls
reqRespControls Gèrent les contrôles envoyés par le client dans la requête et retourné par le serveur.
reqResult Code de résultat LDAP de l'opération
reqMessage message d'erreur s'il y'en a un
reqReferral Gère les référrant qui ont été retournés avec le résultat de la requête.


( 1.3.6.1.4.1.4203.666.11.5.2.1 NAME 'auditObject' DESC 'OpenLDAP request auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession ) MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $ reqResult $ reqMessage $ reqReferral ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.4 NAME 'auditAbandon' DESC 'Abandon operation' SUP auditObject STRUCTURAL MUST reqId )
    
( 1.3.6.1.4.1.4203.666.11.5.2.5 NAME 'auditAdd' DESC 'Add operation' SUP auditWriteObject STRUCTURAL MUST reqMod )
    
( 1.3.6.1.4.1.4203.666.11.5.2.6 NAME 'auditBind' DESC 'Bind operation' SUP auditObject STRUCTURAL MUST ( reqVersion $ reqMethod ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.7 NAME 'auditCompare' DESC 'Compare operation' SUP auditObject STRUCTURAL MUST reqAssertion )
    
( 1.3.6.1.4.1.4203.666.11.5.2.8 NAME 'auditDelete'
DESC 'Delete operation' SUP auditWriteObject STRUCTURAL MAY reqOld )
    
( 1.3.6.1.4.1.4203.666.11.5.2.9 NAME 'auditModify' DESC 'Modify operation' SUP auditWriteObject STRUCTURAL MAY reqOld MUST reqMod )
    
( 1.3.6.1.4.1.4203.666.11.5.2.10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY ( reqNewSuperior $ reqOld ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.11 NAME 'auditSearch' DESC 'Search operation' SUP auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $ reqAttrsOnly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $ reqTimeLimit ) )
    
( 1.3.6.1.4.1.4203.666.11.5.2.12 NAME 'auditExtended' DESC 'Extended operation' SUP auditObject STRUCTURAL MAY reqData )

^
12 septembre 2014

htmlpdflatexmanmd




slapo-acl

slapo-acl

Module de contrôle d'accès

acl-posixgroup

   posixgroup est un exemple qui implémente un contrôle d'accès basé sur l'appartenance des posixGroup. Pour utiliser acl-posixgroup, charger le module puis créer une règle du type:

access to ‹what› by dynacl/posixGroup[.{exact,expand}]=‹dnpat› {‹level›|‹priv(s)}

acl-gssacl

   Exemple d'implémentation de contrôle d'accès basé sur les attributs d'extension de nommage GSS:

access to ‹what› by dynacl/gss/‹attribute›.[.{base,regex,expand}]=‹valpat› {‹level›|‹priv(s)›}
^
12 septembre 2014

htmlpdflatexmanmd




slapo-addpartial

slapo-addpartial

Module de contrôle d'opération Add

   addpartial intercepte les requêtes add, détermine si l'entrée existe, et détermine quels attributs, s'ils existent, ont changés, et modifie ces attributs. Si l'entrée n'existe pas, procède normalement. Si l'entrée existe mais qu'aucun changement n'a été détecté, le client reçoit LDAP_SUCCESS.

   Quand un changement est trouvé, toutes les valeurs de l'attribut sont remplacés (si un attribut n'existe pas dans la nouvelle entrée, mais existe dans l'entrée dans la base, une replace sera fait avec une liste vide de valeurs).

   Une fois qu'une modification est effectuée, l'overlay syncprov va traiter le changement si addpartial est le dernier overlay dans la liste pour être sûr qu'il sera le premier overlay à être traité.

   Le but de cet overlay est de faciliter les enregistrements répliqués depuis une source qui n'est pas une instance LDAP. L'overlay est également utile quand il est plus facile de créer des entrées complètes au lieu de comparer une entrée avec une entrée à retrouver depuis un base LDAP existant pour trouver les changements.

^
12 septembre 2014

htmlpdflatexmanmd




slapo-allop

slapo-allop

Module All Operational Attributes

   L'overlay All Operational Attributes est conçus pour retourner tous les attributs opérationnels pour les clients qui n'utilisent pas le '+' de la rfc3673 dans la liste des attributs demandés.

Exemple:
overlay allop
allop-URI "ldap:///??sub"

^
12 septembre 2014

htmlpdflatexmanmd




slapo-allowed

slapo-allowed

Ajoute des valeurs aux entrées retournées par les opérations de recherche

   Ajoute aux entrées retournées par les opérations de recherche la valeur des attributs allowedAttributes, allowedAttributesEffective, allowedChildClasses et allowedChildClassesEffective.

  Aucune autre utilisation n'est faite de ces attributs: Ils ne peuvent pas être comparés, utilisé dans des filtres de recherche, ou utilisé dans les ACL.

Exemples

dn: olcOverlay={0}allowed,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {0}allowed
^
12 octobre 2013

htmlpdflatexmanmd




slapo-auditlog

slapo-auditlog

Overlay auditlog

   Permet d’enregistrer tous les changements dans une base donnée dans un fichier de log. Les changements sont loggés au format LDIF.

Configuration

auditlog ‹filename› Chemin du fichier de log

Exemples


dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /tmp/auditlog.ldif

^
12 septembre 2014

htmlpdflatexmanmd




slapo-autogroup

slapo-autogroup

Automatise l'appartenance aux groupes

   Permet d'automatiser les mises à jours de l'appartenance des groupes qui matche un filtre contenu dans la définition du groupe. À chaque fois qu'un objet est ajouté, supprimé ou modifié, il est testé avec les filtres et les appartenance de groupe sont mis à jours en conséquence. Si la partie attribut de l'URI est présente, l'entrée groupe est remplie avec les valeurs de cet attribut dans les entrées résultant de la recherche.

Configuration

Le schéma dyngroup doit être modifié, en ajoutant l'attribut member:
objectClass ( NetscapeLDAPobjectClass:33 NAME 'groupOfURLs' SUP top STRUCTURAL MUST cn MAY ( memberURL $ businessCategory $ description $ o $ ou $ owner $ seeAlso $ member) )
autogroup-attrset ‹group-oc› ‹URL-ad› ‹member-ad›
cette directive peut être spécifiée plusieurs fois. group-oc est le nom de la classe d'objet qui représente le groupe. URL-ad est le nom de attributeDescription qui contient l'URI qui est convertis en filtres. Doit être un sous-type de labeledURI. member-ad est le nom de l'attribut qui spécifie l'attribut de membre. La modification de cet attribut est désactivé.
autogroup-memberof-ad ‹memberof-ad›
Définis l'attribut memberOf utilisé par l'overlay memberOf pour stocker les noms des groupes dont l'entrée est membre. Doit être de type DN.

   Cet ovelay nécessite l'overlay memberof
^
12 octobre 2013

htmlpdflatexmanmd




slapo-chain

slapo-chain

Overlay chain

   Permet le repérage de références automatique. A chaque fois qu'un référant est retourné (excepté pour les opérations Bind), il est poursuivi en utilisant une instance du backend LDAP. Si les opérations sont effectués avec une identité, cette identité peut être affirmée tout en poursuivant les référants au moyen de l'identity assertion de back-ldap, qui est essentiellement basé sur le contrôle d'autorisation proxifié. la poursuite des référrant peut être contrôlée par le client en fournissant le contrôle chaining.

OPTIONS

overlay chain Ajoute l'overlay chain au backend courant
chain-cache-uri FALSE met en cache les connections des URIs utilisé pour les référants. ces URI héritent des propriétés configurées pour le backend slapd-ldap avant toute occurence de la directive chain-uri.
chain-chaining [resolve=‹r›] [continuation=‹c›] [critical] Active le contrôle chaining avec le mode de résolution et de continuation désiré. resolv réfère au mode de découverte d'une ressource, continuation réfère au comportement face aux réponses intermédiaires. les valeurs r et c peuvent être chainingPreferred, chainingRequired, referralsPreferred, referralsRequired. critical affecte la criticité du contrôle.
chain-max-depth ‹n› Si un référant est retourné durant la poursuite de référrant, indique la profondeur de poursuite.
chain-return-error FALSE|true Si une poursuite échoue, la vrai erreur est retournée au lieu du référrant orginal.
chain-uri ‹ldapuri› Instancie une nouvelle base ldap et instruit quels URI contacter pour poursuivre les référrants. Seul une URI peut apparaitre après cette directive. toutes les autres directives réfèrent à cette instance spécifique d'un serveur distant

Exemples


overlay chain
chain-rebind-as-user FALSE
    
chain-uri "ldap://ldap1.example.com"
chain-rebind-as-user TRUE
chain-idassert-bind bindmethod="simple"
    binddn="cn=Auth,dc=example,dc=com"
    credentials="secret"
    mode="self"
    
chain-uri "ldap://ldap2.example.com"
chain-idassert-bind bindmethod="simple"
    binddn="cn=Auth,dc=example,dc=com"
    credentials="secret"
    mode="none"

   Toute directive valide pour la base ldap peut être utilisée (voir slapd-ldap). plusieurs occurence de chain-uri peuvent être spécifiées. Toutes les URI non listées sont chaînées anonymement. Toutes les occurences slapd-ldap qui apparaissent avant la première occurence de chain-uri sont héritée par toutes les URI, moins de spécifiquement écraser dans chaque configuration d'URI.
^
12 septembre 2014

htmlpdflatexmanmd




slapo-cloak

slapo-cloak

Cacher des attributs non demandés

   Permet au serveur de cacher des attributs spécifiques sauf s'ils sont explicitement demandés par le client. Cela améliore les performances quand un client demande tous les attributs. Désactivé quand manageDSAit est utilisé.

Configuration

attribute est le nom de l'attribut qui sera caché, class restreint le masquage aux entrées de la classe spécifiée
cloak-attr ‹attribute› [‹class›]
^
12 octobre 2013

htmlpdflatexmanmd




slapo-collect

slapo-collect

Overlay collect

   Overlay d'Attributs collectifs.

OPTIONS

collectinfo ‹DN› ‹attrlist› Spécifie le DN de l'entrée de l'ancêtre et le jeu d'attributs collectifs.
^
12 septembre 2014

htmlpdflatexmanmd




slapo-comp_match

slapo-comp_match

Component Matching on X.509 certificates

Contient un module de correspondance. Exemple de filtre de recherche:
"(userCertificate:componentFilterMatch:=item:{ component\"toBeSigned.serialNumber\", rule integerMatch, value 2 })"
Configurer les index, vous pouvez générer des indices sur chaque composant d'un attribut dont les valeurs sont soit GSER soit BER. par exemple:
index userCertificate eq
index userCertificate.toBeSigned.issuer.rdnSequence eq
index userCertificate.toBeSigned.serialNumber eq
index userCertificate.toBeSigned.version eq

^
12 octobre 2013

htmlpdflatexmanmd




slapo-constraint

slapo-constraint

Overlay constraint

   Overlay de contrainte d'attributs. Permet de s'assurer que les valeurs d'attribut matchent certaines contraintes au-delà de la syntaxe de base LDAP. Les attributs peuvent avoir plusieurs contraintes et toute doivent être satisfaites.

OPTIONS

constraint_attribute ‹attribute_name›[,...] ‹type› ‹value› [‹extra›[...]] Spécifie la contrainte qui devrait s'appliquer à la liste d'attributs spécifiés dans le premier paramètre. 5 types de contraintes sont actuellement supportés: regex (regex unix), size (permet de forcer une limite de taille), count (nombre de valeurs max d'un attribut), uri ( uri évaluée en interne) et set (interprétée en accord avec le jeu d'acl). Le paramètre extra permet de restreindre l'application de la restriction à la partie base, scope et filter d'un URI)

Exemples

Rejète tout mail qui n'a pas le format ‹alpha-numeric string›@mydomain.com›. Rejète tout titre dont les valeurs ne sont pas listées dans l'attribut title d'une entrée titleCatalog dans le scope donné. Nécessite que les valeurs de cn soit construites avec sn et givenName séparés par un espace, mais uniquement pour les objets dérivés de la classe inetOrgPerson:
overlay constraint
constraint_attribute jpegPhoto size 131072
constraint_attribute userPassword count 3
constraint_attribute mail regex ^ [1]+@mydomain.com$
constraint_attribute title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" restrict="ldap:///ou=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)"

^
12 octobre 2013

htmlpdflatexmanmd




slapo-dds

slapo-dds

Overlay dds

   Overlay de services d'annuaire dynamique. implémente la rfc 2589 et permet de définir des objets dynamique, caractérisés par la classe d'objet dynamicObject.

OPTIONS

dds-max-ttl ‹ttl› TTL max ( de 86400 à 31557600 )
dds-min-ttl ‹ttl› TTL minimum pour les opérations de refresh.
dds-default-ttl ‹ttl› TTL par défaut pour les nouveaux objets créés
dds-interval ‹ttl› Interval entre les vérifications d'expiration
dds-tolerance ‹ttl› Spécifie une durée suplémentaire à ajouter au timer qui attend pour supprimer les objets expirés
dds-max-dynamicObjects ‹num› Spécifie le nombre max d'objets dynamiques qui peuvent exister simultanément dans un contexte de nommage.
dds-state TRUE|false Spécifie si la fonctionnalité est activée ou non. Les proxy non pas besoin de gérer ces objets mais necessitent d'informer le frontend du support de ces objets.

Contrôle d'accès

   cet overlay restreint l'opération refresh en nécessitant l'accès manage sur l'attribut entryTtl. Vu que c'est un attribut NO-USER-MODIFICATION, aucune écriture directe n'est possible. l'overlay convertit donc l'opération refresh en une modification interne pour modifier entryTtl avec le jeu de contrôle relax.

La rfc 2589 recommande que les clients anonymes ne devraient pas être autorisés à refresh un objet dynamique:
access to attrs=entryTtl by users manage by * read
Restreindre refresh au créateur de l'objet:
access to attrs=entryTtl by dnattr=creatorsName manage by * read
Assument que Meetings est un attribut de DN valides, permettant aux utilisateurs de commencer une conférence et rafraîchir; empêcher les participant de refresh, et seul le créateur peut le supprimer:
access to dn.base="cn=Meetings" attrs=children by users write
access to dn.onelevel="cn=Meetings" attrs=entry by dnattr=creatorsName write by * read
access to dn.onelevel="cn=Meetings" attrs=participant by dnattr=creatorsName write by users selfwrite by * read
access to dn.onelevel="cn=Meetings" attrs=entryTtl by dnattr=participant manage by * read

Réplication

   Cette implémentation fournie une implémentation réduite de la réplication. Seul les masters peuvent manipuler l'expiration des objets. En répliquant ces objets, on peut explicitement inclure la classe dynamicObjet et l'attribut entryTtl. cette implémentation introduit un nouvel attribut opérationnel, entryExpireTimestamp, qui contient le timestamp d'expiration. Il doit être exclus de la réplication avec:

syncrepl ...
exattrs=entryTtl,entryExpireTimestamp
^
14 septembre 2014

htmlpdflatexmanmd




slapo-denyop

slapo-denyop

Refuser des opérations

   Cet overlay fournis une manière rapide de refuser des opérations. Il est moins consomateur que les ACL parce que son évaluation se produit avant tout backend.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-dsaschema

slapo-dsaschema

Charger un schéma DSA depuis un fichier

   Ce module permet de charger un schéma DSA depuis des fichiers de configuration, incluant des attributs opérationnels.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-dupent

slapo-dupent

LDAP Control for a Duplicate Entry Representation of Search Results

   Ce module implémente le draft LDAP Control for a Duplicate Entry Representation of Search Results

^
12 octobre 2013

htmlpdflatexmanmd




slapo-dyngroup

slapo-dyngroup

Overlay dyngroup

   Overlay de groupes dynamiques. Permet aux clients d'utiliser les opérations compare pour tester l'appartenance à un groupe dynamique.

OPTIONS

attrpair ‹memberAttr› ‹URLattr› Spécifie l'attribut à comparer. une opération de comparaison de memberAttr va évaluer URLattr

Exemples

database bdb
...
overlay dyngroup
attrpair member memberURL
^
12 octobre 2013

htmlpdflatexmanmd




slapo-dynlist

slapo-dynlist

Overlay dynlist

   Overlay de liste dynamique. Permet d'étendre les groupes dynamiques et plus. A chaque fois qu'une entrée avec une classe objet spécifique est retournée, les occurences de valeurs d'URI sont retournés et étendus en entrées correspondantes.

   Vu que le résultat est construit dynamiquement, il n'existe pas tant que la construction n'est pas retournée. En conséquence, les attributs ajoutés dynamiquement ne participent pas dans la partie de match des filtres de recherche. Filtrer des attributs dynamique échouent toujours.

dynlist-attrset ‹group-oc› [‹URI›] ‹URL-ad› [[‹mapped-ad› :]‹member-ad›...] group-oc est le nom de la classe d'objet pour l'extension dynamique. URI restreint l'expensions, URL-ad est l'attribut qui contient l'URI qui est étendue, doit être de type labeledURI. member-ad liste le DN des entrées resultant de la recherche Interne. Si présent la partie attrs des URI dans URL-ad doit être absent. mapped-ad peut être utilisé pour remapper les attributs obtenus.

Autorisation

   Par défaut les expansions sont effectuées en utilisant l'identité de l'utilisateur courant. Cette identité peut être remplacée avec l'attribut dgIdentity dans l'entrée du groupe. Dans ce cas, le dgIdentity sera utilisé. si dgItentity est vide, l'expansion est faite anonymement. Le schéma dyngroup doit être chargé avant d'utiliser cet attribut. si dgAuthz est présent dans l'entrée du groupe, ses valeurs sont utilisées pour déterminer quelles identités sont autorisées à utiliser le dgIdentity pour expandre le groupe.

Exemple

dynlist-attrset groupOfURLs memberURL
Ajouter une entrée:
dn: cn=Dynamic List,ou=Groups,dc=example,dc=com
objectClass: groupOfURLs
cn: Dynamic List
memberURL: ldap:///ou=People,dc=example,dc=com?mail?sub?(objectClass=person)
exemple avec dgIdentity:
dn: cn=Dynamic Group,ou=Groups,dc=example,dc=com
objectClass: groupOfURLs
objectClass: dgIdentityAux
cn: Dynamic Group
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(objectClass=person)
dgIdentity: cn=Group Proxy,ou=Services,dc=example,dc=com
^
14 septembre 2014

htmlpdflatexmanmd




slapo-kinit

slapo-kinit

Demander un TGT

   Ce module permet à slapd de demander un TGT et de le conserver tant que le serveur fonctionne. Ce module accèpte 2 arguments, le principal pour lequel demander le TGT (défaut: ldap/‹hostname›@‹DEFAULTREALM›) et chemin du fichier keytab.

^
14 septembre 2014

htmlpdflatexmanmd




slapo-lastbind

slapo-lastbind

Enregistrer l'heure du dernier bind

   Permet d'enregistrer l'heure du dernier bind réussi des entrées dans l'annuaire, dans l'attribut authTimestamp. L'overlay peut être configuré pour mettre à jour ce timestamp seulement si sa valeur est supérieur à la valeur donnée. Cela réduit le nombre d'écritures.

Configuration

lastbind-precision ‹seconds› La valeur est le nombre de secondes après laquelle mettre à jours l'attribut dans une entrée.
^
14 septembre 2014

htmlpdflatexmanmd




slapo-lastmod

slapo-lastmod

Maintient une entrée de modifications

   Cet overlay crée une entrée de service au suffixe de la base de données, qui maintient le DN, le type de modification, le modifiersName et le modifyTimestamp de la dernière opération d'écriture dans la base. Toutes les opérations ciblant le DN de l'entrée est rejetée, excepté read.

Configuration

lastmod-rdnvalue ‹RDN value› Spécifie le RDN utilisé pour l'entrée de service
lastmod-enabled {yes|no} Active ou non l'overlay


objectClass:
( 1.3.6.1.4.1.4203.666.3.13 " NAME 'lastmod' DESC 'OpenLDAP per-database last modification monitoring' STRUCTURAL SUP top MUST ( cn $ lastmodDN $ lastmodType ) MAY ( description $ seeAlso ) )
attributes:
( 1.3.6.1.4.1.4203.666.1.30 NAME 'lastmodEnabled' DESC 'Lastmod overlay state' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE )
( 1.3.6.1.4.1.4203.666.1.28 NAME 'lastmodDN' DESC 'DN of last modification' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE directoryOperation )
( 1.3.6.1.4.1.4203.666.1.29 NAME 'lastmodType' DESC 'Type of last modification' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

^
12 octobre 2013

htmlpdflatexmanmd




slapo-memberof

slapo-memberof

Overlay memberof

   Overlay de group membership.

OPTIONS

memberof-group-oc group-oc Nom de la classe d'objet contenant les members.
memberof-member-ad member-ad Nom de l'attribut contenant les members
memberof-memberof-ad memberof-ad Nom de l'attribut qui contiendra le groupes d'appartenance.
memberof-dn dn DN utilisé comme modifierName pour les modifications interne effectuées pour la mettre à jours le membership.
memberof-dangling [ignore, drop, error] Détermine l'action de l'overlay quand une référence non résolue est rencontrée.
memberof-dangling-error error-code si memberof-dangling est à error, permet de modifier le code de réponse retourné. (défaut: constraint violation)
memberof-refint true Détermine si l'overlay tente de préserver l'intégrité des référentiels. Quand une entrée contenant les valeurs de l'attribut "is member of" est modifié, les groupes correspondant son modifiés également.

   L'attribut "memberOf" n'est pas répliqué, chaque serveur doit configurer cet overlay pour maintenir cet attribut.
^
17 septembre 2014

htmlpdflatexmanmd




slapo-noopsrch

slapo-noopsrch

Implémente le contrôle noop

   Ce module implémente le contrôle no-op.

^
17 septembre 2014

htmlpdflatexmanmd




slapo-nops

slapo-nops

Suppression d'opérations null

   Overlay de suppression d'opération null. Certains clients implémentent les modifications comme opération de remplacement où tous les attributs sont remplacés, la plupart du temps par les même valeurs. Cela augmente la charge. Cet overlay détecte les opérations de ce type et les filtres. Cet overlay n'a pas de configuration.

^
17 septembre 2014

htmlpdflatexmanmd




slapo-nssow

slapo-nssow

Requêtes NSS et PAM via un socket unix

   Il utilise le même protocole IPC que nss-pam-ldapd de Arthur de Jong. Utiliser un protocole IPC séparé pour les demandes NSS et PAM élimine les dépendance libldap dont souffrent les solutions pam_ldap/nss_ldap. Cet overlay s'exécute dans slapd, profitant d'un cache sophistiqué, sans les faiblesses de nscd. Une base LDAP distante peut être accédée en utilisant back-ldap avec un proxy-cache. Un autre bénéfice est que toutes les stratégies de sécurité sont administrées centralement via LDAP.

Configuration

nssov-ssd ‹service› ‹url› Configure un Service Search Descriptor (SSD) pour chaque service NSS qui sera utilisée.
ldap:///[‹basedn›][??[‹scope›][?‹filter›]] Le suffixe de la base, scope et filtre de recherche.
nssov-map ‹service› ‹orig› ‹new› Si la base locale est un proxy, certains mappages du schéma peuvent être nécessaire. Cette directive permet une substitution d'attribut simple.
nssov-pam ‹option› [...] Détermine le nombre de mode PAN. Les options valides sont:

        userhost Vérifie l'attribut host dans l'entrée pour l'autorisation
        userservice Vérifie l'attribut authorizedService dans l'entrée pour l'autorisation
        usergroup Vérifie que l'utilisateur est membre d'un groupe spécifique pour l'autorisation.
        hostservice Vérifie l'attribut authorizedService dans l'entrée pour l'autorisation
        authz2dn Utilise authz-regexp pour mapper l'uid à un DN ldap.
        uid2dn Utilise le SSD passwd NSS pour mapper un uid à un DN ldap.

nssov-pam-defhost ‹hostname› Spécifie un hostname par défaut pour vérifier si une entrée ipHost pour le nom d'hôte courant ne peut pas être trouvé
nssov-pam-group-ad ‹attribute› Spécifie de DN d'un groupe LDAP pour vérifier l'autorisation. L'utilisateur LDAP doit être membre de ce group pour être autorisé à s'authentifier. Il n'y a pas de valeurs par défaut.
nssov-pam-group-ad ‹attribute› Spécifie l'attribut à utiliser pour la vérification au groupe.
nssov-pam-min-uid ‹integer› Spécifie un uid minimum autorisé au login
nssov-pam-max-uid ‹integer› Spécifie un uid maximum autorisé au login
nssov-pam-template-ad ‹attribute› Spécifie un attribut à vérifier dans l'entrée utilisateur pour un template de nom de login.
nssov-pam-template ‹name› Spécifie un nom d'utilisateur pas défaut si aucun attribut template n'est trouvé dans l'entrée utilisateur.
nssov-pam-session ‹service› Spécifie un nom de service PAM dont les sessions seront enregistrés.
nssov-pam-password-prohibit-message ‹message› Désactive le service de changement de mot de passe et retourne le message spécifié aux utilisateurs
nssov-pam-pwdmgr-dn ‹dn› Spécifie le dn du responsable des mots de passe
nssov-pam-pwdmgr-pwd ‹pwd› Spécifie le mot de passe du responsable des mots de passe

loginStatus

   Attribut opérationnel de l'entrée utilisateur. Les valeurs de l'attribut sont sous la forme ‹generalizedTime› ‹host› ‹service› ‹tty› (‹ruser@rhost›). À la déconnexion, la valeur correspondante est supprimée. Cela permet de vérifier si des utilisateur sont loggés sur tous les hôtes du réseau via un ldapsearch. Le rootdn de la base est utilisée pour effectuer les mises à jours de cet attribut, donc un rootdn doit toujours être configuré pour que cette fonctionnalité fonctionne.

  Les fonctions PAM supportent LDAP password Policy également. Si l'overlay password policy est utilisé, les informations de stratégie peuvent être retournés au client PAM en résultat de l'authentification, gestion du compte, et demande de changement de mot de passe.

Exemple:
dn: olcOverlay={0}nssov,ocDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcNssOvConfig
olcOverlay: {0}nssov
olcNssSsd: passwd ldap:///ou=users,dc=example,dc=com??one
olcNssMap: passwd uid accountName
olcNssPam: hostservice uid2dn
olcNssPamDefHost: defaulthost
olcNssPamMinUid: 500
olcNssPamMaxUid: 32000
olcNssPamSession: login
olcNssPamSession: sshd

^
12 octobre 2013

htmlpdflatexmanmd




slapo-pbind

slapo-pbind

Overlay pbind

   Permet de forwarder les simple binds sur une base local à un serveur LDAP distant au lieu de les traiter localement.

OPTIONS

uri ‹ldapurl› Serveur ldap à utiliser
tls ‹TLS parameters› Paramètres TLS à utiliser
network-timeout ‹time› Timeout en secondes
quarantine ‹quarantine parameters› met en quarantaine les URI qui ont retourné LDAP_UNAVAILABLE
^
12 octobre 2013

htmlpdflatexmanmd




slapo-pcache

slapo-pcache

Overlay pcache

   Overlay de proxy cache. Permet de mettre en cache les requêtes LDAP dans une base locale. Pour chaque requêtes, il détermine si elle correspond à un template.

OPTIONS

pcache ‹database› ‹max_entries› ‹numattrsets› ‹entry_limit› ‹cc_period› Active le proxy cache dans la base courante Un backend ‹database› sera utilisé en interne pour maintenir les entrées. ‹max_entries› écrase le cache quand le nombre d'entrées est atteint. numattrsets devrait être égal au nombre de directives pcacheAttrset. Les requêtes sont en cache uniquement si elles matchent un template et que le résultat retourné est inférieur à entry_limit. La vérification de consistance est effectuée toutes les cc_period en seconde.
pcacheAttrset ‹index› ‹attrs...› Utilisé pour associer un jeu d'attributs avec un index. Chaque jeu d'attribut est associé avec un entier de 0 à numattrsets-1. Ces indices sont utilisé par pcacheTemplate pour définir les templates cachable. (un jeu d'attribut de "1.1" spécifie que seul la présence de l'entrée en mise en cache)
pcacheMaxQueries ‹queries› Spécifie le nombre max de requêtes à mettre en cache.
pcacheValidate TRUE | FALSE Vérifie sur les résultats en cache peuvent être retournés du cache par le proxy. a TRUE, s'assure de la consistance avec le schéma connu du proxy.
pcacheOffline TRUE | FALSE Définis le cache en mode offline. La vérification de la consistance est stoppée et aucune expiration ne se produit.
pcachePersist TRUE | FALSE Spécifie si les résultats en cache devraient être sauvegardés entre les redémarrages.
pcacheTemplate ‹template_string› ‹attrset_index› ‹ttl› [‹negttl›[‹limitttl› [‹ttr›]]] Spécifie un template de mise en cache, et un TTL. negttl peut être utilisé pour spécifier que les résultats négatifs devraient également être mis en cache. limitttl peut être utilisé pour spécifier que les résultat qui atteignent le limitttl devraient aussi être mis en cache. un ttr optionnel peut être utilisé que les résultats en cache devraient seulement être rafraîchis après un certain temps. Les entrées sont rafraichis seulement s'ils n'ont pas expirés, dont ttl doit être plus grand que ttr.
pcacheBind ‹filter_template› ‹attrset_index› ‹ttr› ‹scope› ‹base› Spécifie un template pour cacher les crédentials simple bind basé sur un pcacheTemplate existant. filter_template est similaire à template_string excepté qu'il peut avoir certaines valeurs présentes.
pcachePosition head | tail Spécifie si la réponse devrait être placé en bas ou en haut de la liste d'appel. Celà affecte la manière dont cet overlay interagis avec d'autres.

Contraintes

   Toutes les valeurs doivent être positives entry_limit devrait être définies en utilisant la directive pcacheAttrset tous les jeux d'attributs devraient être référencés par au moins une directive pcacheTemplate.

Exemple

Ajouter un template avec une chaîne de recherche ($(sn=)(givenName=)) et les attributs mail, postalAddress, telephoneNumber et un TTL de 1 heure:
pcacheAttrset 0 mail postaladdress telephonenumber
pcacheTemplate (&(sn=)(givenName=)) 0 3600
^
12 octobre 2013

htmlpdflatexmanmd




slapo-ppolicy

slapo-ppolicy

Overlay ppolicy

   Overlay de stratégie de mot de passe. Il intercepte et applique des contrôles de mot de passe.

OPTIONS

ppolicy_default ‹policyDN› DN de l'objet pwdPolicy à utiliser quand aucune stratégie n'est définie dans l'entrée de l'utilisateur.
ppolicy_forward_updates Spécifie que les changements d'état de stratégie qui résultent des opérations bind devraient être forwardés à un master au lieu d'être écrit directement dans la base local.
ppolicy_hash_cleartext Spécifie que les mots de passe en clair devraient être hashés. celà viole le modèle d'information X500 mais peut être utile pour les clients qui n'utilisent pas l'opération étendue Password Modify.
ppolicy_use_lockout Un client reçoit toujours une réponse InvalidCredentials lors d'un bind avec un compte bloqué. Cette option change le code de réponse pour inclure AccountLocked. Noter que ce code fournis des informations à un attaquant.

Schéma

pwdPolicy utilisé par l'overlay
pwdPolicyChecker Utilisé pour vérifier la qualité des mots de passe.
pwdAttribute Contient le nom de l'attribut où la stratégie de mot de passe s'applique. (accèpte uniquement userPassword)
pwdMinAge Secondes minimum entre chaque modifications permises
pwdMaxAge Secondes maximum entre chaque modifications permises
pwdInHistory Nombre d'historique de mots de passe à conserver.
pwdCheckQuality Indique si et comment la syntaxe de mot de passe sera vérifiée. 0 pas de vérification, 2, vérifie la syntaxe et si le serveur ne peut pas le vérifier, dû à un mot de passe hashé, il sera accepté. 2 le serveur doit pouvoir vérifier la syntaxe.
pwdMinLength Nombre minimum de caractère du mot de passe
pwdExpireWarning secondes avant expiration où le serveur envoie un message d'avertissement
pwdGraceAuthnLimit Nombre de fois q'un mot de passe expiré peut être utilisé pour authentifier un utilisateur
pwdLockout Action à prendre quand un utilisateur a échoue l'authentification pwdMaxFailure fois. a TRUE, l'utilisateur ne pourra plus s'authentifier.
pwdLockoutDuration Durée en seconde pendant laquelle l'utilisateur ne peut pas s'authentifier après pwdMaxFailure échecs d'authentification.
pwdMaxFailure Nombre d'authentifications consécutives échouées.
pwdFailureCountInterval Secondes avant que le comptes d'échec d'authentification soit purgé.
pwdMustChange A TRUE, spécifie que l'utilisateur doit changer son mot de passe une fois authentifié.
pwdAllowUserChange Spécifie si l'utilisateur peut changer son mot de passe ou non. ( les ACL devraient être utilisés à la place de cet attribut)
pwdSafeModify a TRUE, le mot de passe et le nouveau mot de passe doivent être envoyés en même temps.
pwdCheckModule Nomme un module qui doit instancier la fonction check_password().
userPassword (opérationnel) Contient le mot de passe de l'utilisateur
pwdPolicySubentry (opérationnel) réfère directement à pwdPolicy
pwdChangedTime (opérationnel) Date de dernier changement de mot de passe
pwdAccountLockedTime (opérationnel) date à laquelle le compte a été bloqué. (000001010000Z indique que le compte est bloqué de manière permanente).
pwdFailureTime (opérationnel) Date de chaque échec d'authentification.
pwdHistory (opérationnel) Contient l'hitorique des derniers mots de passe utilisés.
pwdGraceUseTime (opérationnel) Date des logins effectués après que le mot de passe ait expiré.
pwdReset (opérationnel) Indique que le mot de passe a été réinitialisé par un administateur (il doit être changé à la prochaine authentification)


( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' AUXILIARY SUP top MUST ( pwdAttribute ) MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthnLimit $ pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
    
( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' AUXILIARY SUP top MAY ( pwdCheckModule ) )
    
( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
    
( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthnLimit' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInterval' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
    
( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
    
( 1.3.6.1.4.1.42.2.27.8.1.23 NAME 'pwdPolicySubentry' DESC 'The pwdPolicy subentry in effect for this object' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.16 NAME 'pwdChangedTime' DESC 'The time the password was last changed' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.17 NAME 'pwdAccountLockedTime' DESC 'The time an user account was locked' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.19 NAME 'pwdFailureTime' DESC 'The timestamps of the last consecutive authentication failures' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch NO-USER-MODIFICATION USAGE directoryOperation )
    
( 1.3.6.1.4.1.42.2.27.8.1.20 NAME 'pwdHistory' DESC 'The history of user passwords' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 EQUALITY octetStringMatch NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.21 NAME 'pwdGraceUseTime' DESC 'The timestamps of the grace login once the passwordhas expired' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch NO-USER-MODIFICATION USAGE directoryOperation)
    
( 1.3.6.1.4.1.42.2.27.8.1.22 NAME 'pwdReset' DESC 'The indication that the password has been reset' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation)

^
12 octobre 2013

htmlpdflatexmanmd




slapo-refint

slapo-refint

Overlay refint

   Overlay d'intégrité de référentiel. Permet de maintenir une cohérence d'un schéma avec des attributs référence. Il permet de mettre à jours la base lors d'opérations modrdn ou delete.

OPTIONS

refint_attributes ‹attribute› [...] Spécifie les attributs où l'intégrité doit être maintenue.
refint_nothing ‹string› Spécifie une valeur arbitraire à utiliser lors d'une suppression dans un attribut qui impose d'avoir une valeur.
refint_modifiersname ‹DN› DN à utiliser comme modifierName des modifications internes effectuées par l'overlay.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-retcode

slapo-retcode

Overlay retcode

   Utile pour des tests, les réponses sont générées en accord avec différentes stratégies. Dans le premier cas, pour toutes les opérations ciblées dans une sous-arborecence, la recherche est effectuées et vérifiée pour le code de retour, plus un message textuel optionnel. Les codes de réponse connus sont fournis dans retcodes.conf. Dans le second cas, les classes d'objet qui héritent de errAbsObject comme errObject ou errAuxObject, retournent un code dicté par ce contenu. Un Troisième cas recherche l'objet dans une base pour découvrir si leur classe hérite de errAbsObject. Dans ce cas, leur contenu est utilisé pour calculer la réponse correspondante. Désactivé en utilisant le contrôle manageDSAit.

OPTIONS

retcode-parent ‹DN› Définis le DN parent où les entrées générées dynamiquement résident.
retcode-item ‹RDN› ‹errCode› [op=‹oplist›] [text=‹message›] [ref=‹referral›] md
[unsolicited=‹OID›[ :‹data›]] [flags=[pre|post-]disconnect[,...]] Une entrée générée dynamiquement sous retcode-parent. errCode est le numéro du code de réponse. oplist est une liste d'opérations qui génère la génération du code. matched est le DN matché qui est retourné avec l'erreur. text est le message optionnel, ref est permis pour le code referral. sleeptime secondes avant de traiter l'opération. unsolicited peut être utilisé pour forcer un message de réponse unsolicited rfc4511. OID si non 0, génère une réponse étendue avec data ajouté. flags contient disconnect ou pre-disconnect (fore la déconnection sans notification) ou post-disconnect (déconnection après avoir envoyé la réponse)
retcode-indir Active l'exploitation de errAbsObject.
retcode-sleep [-]‹n› Secondes d'attente avant de manipuler les opérations. une valeur négative indique une valeur aléatoire entre 0 et la valeur indiquée.

Schéma

Le code d'erreur:
( 1.3.6.1.4.1.4203.666.11.4.1.1 NAME ( 'errCode' ) DESC 'LDAP error code' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

L'opération qui déclenche le code de réponse:
( 1.3.6.1.4.1.4203.666.11.4.1.2 NAME ( 'errOp' ) DESC 'Operations the errObject applies to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

le message textuel:
( 1.3.6.1.4.1.4203.666.11.4.1.3 NAME ( 'errText' ) DESC 'LDAP error textual description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

Temps d'attente avant de retourner la réponse:
( 1.3.6.1.4.1.4203.666.11.4.1.4 NAME ( 'errSleepTime' ) DESC 'Time to wait before returning the error' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

DN retourné au client:
( 1.3.6.1.4.1.4203.666.11.4.1.5 NAME ( 'errMatchedDN' ) DESC 'Value to be returned as matched DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )

OID retourné comme réponse étendue unsolicited responses:
( 1.3.6.1.4.1.4203.666.11.4.1.6 NAME ( 'errUnsolicitedOID' ) DESC 'OID to be returned within unsolicited response' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE )

Chaîne d'octet à retourner comme donnée de réponse étendue:
( 1.3.6.1.4.1.4203.666.11.4.1.7 NAME ( 'errUnsolicitedData' ) DESC 'Data to be returned within unsolicited response' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )

Mode de déconnexion:
( 1.3.6.1.4.1.4203.666.11.4.1.8 NAME ( 'errDisconnect' ) DESC 'Disconnect without notice' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

Déclencheur de l'overlay:
( 1.3.6.1.4.1.4203.666.11.4.3.0 NAME ( 'errAbsObject' ) SUP top ABSTRACT MUST ( errCode ) MAY ( cn $ description $ errOp $ errText $ errSleepTime $ errMatchedDN ) )
    
( 1.3.6.1.4.1.4203.666.11.4.3.1 NAME ( 'errObject' ) SUP errAbsObject STRUCTURAL )
    
( 1.3.6.1.4.1.4203.666.11.4.3.2 NAME ( 'errAuxObject' ) SUP errAbsObject AUXILIARY )

Exemples

retcode.conf se trouve dans tests/data/
include ./retcode.conf
Attendre 10 secondes, puis retourner un succès (0x00)
retcode-item "cn=Success after 10 seconds" 0x00 sleeptime=10
Attendre 10 secondes, puis retouner timelimitExceeded (0x03)
retcode-item "cn=Timelimit after 10 seconds" 0x03 sleeptime=10
^
12 octobre 2013

htmlpdflatexmanmd




slapo-rwm

slapo-rwm

Overlay rwm

   Overlay rewrite/remap. Permet d'effectuer des réécritures basiques de DN données et des mapping d'attribut/classe d'objet.

Mapping

rwm-map {attribute | objectclass} ‹local name› {‹foreign name› | *} Map les attributeTypes et les objectClasse.
rwm-normalize-mapped-attrs {yes|no} à yes, rwm tente de normaliser les valeurs des attributs mappés (utile lors que les attributs distant sont inconnus du serveur)
rwm-drop-unrequested-attrs {yes|no} à yes, rwm drop les attributs qui ne sont pas explicitement demandés par une opération de recherche.

Suffix Massaging

   Permet de mapper un contexte de nommage réel et virtuel. Permet par exemple de créer des vues virtuelles.

rwm-suffixmassage [‹virtual naming context›] ‹real naming context› Réecriture de contexte de nommage.

Rewriting

   Une chaîne est réécrite en fonction d'un jeu de règles, appelé un contexte de réécriture. Les règles sont basé sur des expressions régulières étendue POSIX avec correspondance de sous-chaîne.

‹rewrite context›::= ‹rewrite rule› [...]
‹rewrite rule›::= ‹pattern› ‹action› [‹flags›]

Passes

   Une chaîne entrante est matchée avec un jeu de rewriteRules. Les règles sont faites de regex match pattern, un substitution pattern et un jeu d'actions, décris par un jeu de flags optionnels. En cas de correspondance, la réécriture de chaîne est effectuée en accord avec le motif de substitution qui permet de référer à une sous-chaîne matchée dans la chaîne. Chaque règle est exécutée récursivement Un mappage est un objet générique qui map un motif de substitution à une valeur. Les flags sont divisés en "Pattern Matching Flags" et en "Action Flags".

Pattern Matching Flags

C respecte la casse
R Utilise les expressions régulière POSIX standard.
M{n} Ne permet pas plus de n récursion pour un règle.

Action Flags

: Applique la règle une seule fois (pas de récursion)
@ Arrête d'appliquer une règle en cas de correspondance
# Stop l'opération courante si la règle correspond et retourne un unwilling to perform
G{n} Saute n règles en arrière
I Ignore les erreurs dans les règles
U{n} Utilise n comme code de retour si la règle match.

Substitution Pattern Syntax

   Tout ce qui commence avec '$' nécessite une substitution. La seule exception est '$$', qui est retourné en un simple '$'. La substitution de base est '$‹d›', où ‹d› est un chiffre; 0 signifie toute la chaîne, de 1 à 9 pour des submatch.

un '$' suivi d'un '{' invoque une substitution avancée:
'$' '{' [ ‹operator› ] ‹name› '(' ‹substitution› ')' '}'

‹name›::= [a-z][a-z0-9]* (case insensitive)
‹operator›::= '›' '|' '&' '&&' '*' '**' '$'

‹substitution› doit être un motif de substitution valide, sans limite de niveau d'imbrication. les opérateurs sont:

        Invocation de sous-contexte
        | Invocation de commande externe
        & Assignement de variable
        Déréferencement de variable
        $ Déréférencement de paramètre

Rewrite Context

   Un contexte de réécriture est un jeu de règles qui sont appliquées en séquence. Quand une réécriture de chaîne est requise, on invoque le contexte de réécriture appropriée. Chaque opération serveur de base est associée à un contexte de réécriture, ils sont divisés en 2 groupes principaux: client -› serveur et serveur -› client:

Client->serveur

(default) Si définis et sans contexte spécifique
bindDN bind
searchDN search
searchFilter search
searchFilterAttrDN search
compareDN compare
compareAttrDN compare AVA
addDN add
addAttrDN add AVA (DN portion of "ref" excluded)
modifyDN modify
modifyAttrDN modify AVA (DN portion of "ref" excluded)
referralAttrDN add/modify DN portion of referrals
renameDN modrdn (the old DN)
newSuperiorDN modrdn (the new parent DN, if any)
newRDN modrdn (the new relative DN)
deleteDN delete
exopPasswdDN password modify extended operation DN

Serveur->client

searchEntryDN search (seulement si défini, pas de défaut, agis sur le DN des entrées recherchées)
searchAttrDN search AVA (seulement si défini, défaut sur searchEntryDN, agis sur les attributs type DN des entrées recherchées)
matchedDN all ops (Seulement si applicable; défaut à searchEntryDN)
referralDN all ops (Seulement si applicable; défaut: none)

Basic Configuration Syntax

rwm-rewriteEngine { on | off } Autorise la réécriture
rwm-rewriteContext ‹context name› [ alias ‹aliased context name› ] ‹Context Name› est le nom qui identifie le contexte, par ex le nom utilisé par l'application pour référer au jeu de règles qu'il contient. Un contexte peut être un alias d'un autre. Dans ce cas il ne contient pas de règle.
rwm-rewriteRule ‹regex match pattern› ‹substitution pattern› [ ‹flags› ] Détermine comment une chaîne peut être réécrite si un motif est matché.

Additional Configuration Syntax

rwm-rewriteMap ‹map type› ‹map name› [ ‹map attrs› ] Permet de définir un map qui transforme des réécritures en quelque chose d'autre. Le map est référencé dans le motif de substitution d'une règle.
rwm-rewriteParam ‹param name› ‹param value› Définis une valeur avec un scope global, qui peut être dé-référencé par la commande ${$paramName}
rwm-rewriteMaxPasses ‹number of passes› [‹number of passes per rule›] Définis un nombre maximum de réécritures totales en une seul opération de réécriture.

Maps

   les mappages supportés sont:

LDAP ‹URI› [bindwhen=‹when›] [version=‹version›] [binddn=‹DN›] [credentials=‹cred›] Étend la valeur en effectuant une simple recherche LDAP. bindwhen détermine quand la connection est établie (now - créée au démarrage, later - quand nécessaire, everytime - a chaque fois).
slapd ‹URI› étend une valeur en effectuant une recherche LDAP interne.

Exemple

activer le rewriting
rwm-rewriteEngine on
Tous les flux de données du client vers le serveur référrant au DN
rwm-rewriteContext default
rwm-rewriteRule "(.+,)?‹virtualnamingcontext›$" "$1‹realnamingcontext›" ":"
Règle de filtre vide
rwm-rewriteContext searchFilter
Tous les flux de données du serveur vers le client
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.+,)?‹realnamingcontext›$" "$1‹virtualnamingcontext›" ":"
rwm-rewriteContext searchAttrDN alias searchEntryDN
rwm-rewriteContext matchedDN alias searchEntryDN
Diverses règles vides
rwm-rewriteContext referralAttrDN
rwm-rewriteContext referralDN
Tout ce qui est définis ici va dans le contexte default. Change le contexte de nommage de tout ce qui est envoyé
rwm-rewriteRule "(.+,)?dc=home,[ ]?dc=net$" "$1dc=OpenLDAP, dc=org" ":"
Commence un nouveau contexte (termine l'entrée du précédent) Ajoute un blanc entre les parties du DN si non présent
rwm-rewriteContext addBlanks
rwm-rewriteRule "(.*),([^ ].*)" "$1, $2"
Celui-ci supprime les blanc:
rwm-rewriteContext eatBlanks
rwm-rewriteRule "(.*), (.*)" "$1,$2"
Chaque contrôle revient au context default, les règles sont ajoutée à celles existantes, et pipe dans addBlanks:
rwm-rewriteContext default
rwm-rewriteRule ".*" "${›addBlanks($0)}" ":"
Réecrit la base de recherche sur les règles default:
rwm-rewriteContext searchDN alias default
Les résultats de recherche avec un DN openldap sont réecris avec dc=home,dc=net.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.*[^ ],)?[ ]?dc=OpenLDAP,[ ]?dc=org$" "${›eatBlanks($1)}dc=home,dc=net" ":"
Bind avec le mail au lieu du DN. on fait un map ldap qui transforme les attributs en DN
rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"
puis on détecte le DN fait d'un simple email.
rwm-rewriteContext bindDN
rwm-rewriteRule "^mail=[^,]+@[^,]+$" "${attr2dn($0)}" ":@I"
exemple plus sophistiqué
rwm-rewriteContext bindDN
rwm-rewriteRule ".+" "${&&binddn($0)}$0" ":"
# A search filter containing 'uid=' is rewritten only if an appropriate DN is bound. To do this, in the first rule the bound DN is
# dereferenced, while the filter is decomposed in a prefix, in the value of the 'uid=‹arg›' AVA, and in a suffix. A tag '‹›' is appended to the DN.
# If the DN refers to an entry in the 'ou=admin' subtree, the filter is rewritten OR-ing the 'uid=‹arg›' with 'cn=‹arg›'; otherwise it is left as is. This could be
# useful, for instance, to allow apache's auth_ldap-1.4 module to authenticate users with both 'uid' and 'cn', but only if the request comes from a possible
# 'cn=Web auth,ou=admin,dc=home,dc=net' user.
rwm-rewriteContext searchFilter
rwm-rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)" "${**binddn}‹›${&prefix($1)}${&arg($2)}${&suffix($3)}" ":I"
rwm-rewriteRule "^[^,]+,ou=admin,dc=home,dc=net$" "${*prefix}|(uid=${*arg})(cn=${*arg})${*suffix}" ":@I"
rwm-rewriteRule ".*‹›$" "${*prefix}uid=${*arg}${*suffix}" ":"
# This example shows how to strip unwanted DN-valued attribute values from a search result; the first rule matches DN values below "ou=People,dc=example,dc=com";
# in case of match the rewriting exits successfully. The second rule matches everything else and causes the value to be rejected.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule ".+,ou=People,dc=example,dc=com$" "$0" ":@"
rwm-rewriteRule ".*" "" "#"

Exemple de mapping

map objectclass groupOfNames groupOfUniqueNames
map attribute uniqueMember member
Jeu d'attribut limité, map cn, sn, manager, description a eux-même, tous les autres sont supprimés.
map attribute cn *
map attribute sn *
map attribute manager *
map attribute description *
map attribute *
^
12 octobre 2013

htmlpdflatexmanmd




slapo-sssvlv

slapo-sssvlv

Overlay sssvlv

   Implémente la RFC2891 et le contrôle de liste virtuelle. Remplace également l'implémentation de la RFC2696 pour s'assurer qu'il fonctionne bien avec le trie.

OPTIONS

sssvlv-max ‹num› Nombre maximum de requêtes de trie simultané permis parmis toutes les connections
sssvlv-maxkeys ‹num› Nombre maximum de requêtes triées simultanées parmis toutes les connections.
sssvlv-maxperconn ‹num› Nombre maximum de recherche paginée simultanées par connection.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-syncprov

slapo-syncprov

Overlay syncprov

   Implémente la RFC4533 et le support pour la réplication syncrepl. Peut être utilisé avec tout backend qui supporte entryCSN et entryUUID. Il créé également un attribut contextCSN dans l'entrée root de la base. le contextCSN est mis à jours à chaque opération d'écriture effectuée dans la base. Pour réduire les accès, la mise à jours n'est effectuée qu'en ram. des checkpoints peuvent être configurés pour écrire dans la base.

OPTIONS

syncprov-checkpoint ‹ops› ‹minutes› délay d'écriture du contextCSN au bout de ops opérations ou au bout de minutes écoulés
syncprov-sessionlog ‹ops› Configure un log de session en mémoire pour enregistrer les informations d'écriture faites dans la base. ops est le nombre d'opération enregistrées dans la base.
syncprov-nopresent TRUE | FALSE spécifie sie la phase Present du rafraichissement doit être ignorée. Utile seulement pour une instance syncprov au dessus d'une base de log.
syncprov-reloadhint TRUE | FALSE Spécifie que l'overlay devrait honorer le flag reloadHint dans le contrôle Sync.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-translucent

slapo-translucent

Overlay translucent

   Proxy transparent. Les entrées récupérées depuis un serveur distant peuvent avoir certains attributs remplacés, ou ajoutés par des entrées dans la base locale avant d'être présentés au client. Une opération compare va effectuer une comparaison avec des attributs définis dans une base locale avant toute comparaison avec une donnée distante.

OPTIONS

translucent_strict par défaut, les tentatives de supprimer des attributs sont ignorés silencieusement. cette directive renvoie une constraint Violation
translucent_no_glue Désactive la création automatique des records "glue" pour une opération add ou modrdn tel que tous parents d'une entrée ajoutée à la base locale doit être créée à la main. ces enregistrements sont toujours créés pour une opération modify.
translucent_local ‹attr[,attr...]› Spécifie une liste d'attributs qui devraient être recherchés dans la base locale quand ils sont utilisés dans un filtre de recherche. par défaut, les filtres de recherche ne sont manipulés que par les serveurs distant.
translucent_remote ‹attr[,attr...]› Spécifie une liste d'attributs qui devraient être recherchés dans une base distante quand ils sont utilisés dans un filtre de recherche. par défaut, les filtres de recherche ne sont manipulés que par les serveurs distant
translucent_bind_local Permet de chercher les crédentials stockés localement pour les simple bind quand les bind distant échouent.
translucent_pwmod_local Permet les opérations étendu de modification de mot de passe sur les crédentials stockés localement. Ne s'applique qu'aux entrées présent dans la base distante.

Contrôle d'accès

   Le contrôle d'accès est délégué soit au DSA distant ou au backend local pour les opération auth et write. Il est délégué au DSA distant et au frontend pour les opérations read. Cet overlay va désactiver la vérification du schéma dans la base local, les entrées ayant des attributs d'overlay doivent adhérer au schéma complet.
^
12 octobre 2013

htmlpdflatexmanmd




slapo-unique

slapo-unique

Overlay unique

   Permet de forcer l'unicité de certains attributs dans un scope.

OPTIONS

unique_uri ‹[strict ][ignore ]URI[URI...]...› (olcUniqueURI) Configure la base, les attributs, scope et filtre pour la vérification de l'unicité. Plusieurs URI peuvent être spécifiés. ignore permet de vérifier l'unicité sur tous les attribut excepté ceux définis. strict force l'unicité, même pour les valeurs null. (ex: ldap:///?cn?sub?(sn=e*) vérifie l'unicité de cn pour tous les objets dont sn commence par un e)
^
12 octobre 2013

htmlpdflatexmanmd




slapo-valsort

slapo-valsort

Overlay valsort

   Permet de trier les valeurs des attributs multi-valués.

OPTIONS

valsort-attr ‹attribute› ‹baseDN› (‹sort-method› | weighted [‹sort-method›]) Configure une méthode de trie pour l'attribut spécifié. sort-method peut être alpha-ascend, alpha-descend, numeric-ascend ou numeric-descend. Si la methode spécial weighted est spécifiée, une 2eme méthode peut aussi être spécifiée.

Exemples

overlay valsort
valsort-attr member ou=groups,dc=example,dc=com alpha-ascend
Pour invoquer ldapsearch avec ce contrôle, la valeur doit être définie. Les octets suivant représentent l'encodage désiré:
0x30 0x03 0x01 0x01 0xff
le contrôle peut être envoyé en utilisant la valeur encodé en base 64:
ldapsearch -E 1.3.6.1.4.1.4203.666.5.14=::MAMBAf8=
^
08 septembre 2013

htmlpdflatexmanmd




slappasswd

slappasswd

Utilitaire de gestion de mot de passe openldap. Il permet de générer des valeurs userPassword, rootpw ou olcRootPW

OPTIONS

-v mode verbeux
-u Génère des valeurs RFC23077
-s secret Le secret à hasher
-g génère le secret
-T "file" Hash le contenu du fichier
-h "scheme" Si -h, un des schemas RFC2307 peut être utilisé: CLEARTEXT,CRYPT,MD5,SMD5,SSHA,etSHA
-c crypt-salt-format Spécifie le format du salt passé à crypt(3). Cette chaîne doit être au format sprintf(3) et peut inclure un %s. (ex : ’%.2s’ fournis un salt à 2 caractères, et ’$1$%.8s’ demande d’utiliser MD5 avec 8 caractères aléatoire.) défaut pour %s : 31 caractères de salt
-n  Omet les nouvelles lignes
-o option[=value] Spécifie une option slapd (module-path=‹pathspec› et module-load=‹filename›)

limitations

   Stocker les mots de passe dans userPassword viole la RFC4519. Utiliser authPassword (rfc3112).
^
08 septembre 2013

htmlpdflatexmanmd




slapschema

slapschema

Vérifie le schéma in-database de slapd

OPTIONS

-a filter Dump seulement les entrées correspondant au filtre
-b suffix Utilise le suffix spécifié pour déterminer quelle base utiliser
-c Ignore les erreurs et continue
-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
-g Désactive le gluing subordonné. Seul la base spécifiée sera traitée et non ses subordonnées attachés
-H URI
-l ldif-file Écrit la sortie dans le fichier spécifié
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration. Ne peut pas être utilisé avec -b
-o option[=value] Spécifie une option slapd
-s subtree-dn Dump seulement les entrées dans la sous-arborescence spécifiée par ce DN
-v mode verbeux

limitations

   Pour certains types de backend, slapd ne devrait pas être en cours de fonctionnement, du moins en lecture seule.
^
08 septembre 2013

htmlpdflatexmanmd




slaptest

slaptest

Vérifie la configuration de slapd

OPTIONS

-d debug_level Active le débug
-f slapd.conf Spécifie le fichier de configuration à utiliser
-F confdir Spécifie le répertoire contenant la configuration slapd
dbnum Ajoute des entrées dans la dbnum-ième base listée dans la configuration.
-o option[=value] Spécifie une option slapd
-Q Mode très silencieux
-u dry-run n’échoue pas si la base ne peut pas être ouverte
-v mode verbeux
^
15 juillet 2010

htmlpdflatexmanmd




sleep

sleep

Effectue un pause

   sleep effectue une pause pendant un temps spécifié. La valeur peut être suffixé par:

s secondes
m minutes
h heures
d jours

^
13 février 2012

htmlpdflatexmanmd




smartcard_list.txt

smartcard_list.txt

Correspondance ATR - type de carte

   Ce fichier contient les référence entre un ATR et un type de carte. La liste la plus récente peut être téléchargée à http://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt

Syntaxe

Pour une association ATR - type de carte:
ATR sous la forme d'une expression régulière
[tab] Texte descriptif
[tab] Texte descriptif
[tab] Texte descriptif
ligne vide
^
21 juillet 2010

htmlpdflatexmanmd




sort

sort

Trie, fusionne ou compare toutes les lignes des fichiers spécifiés ou l'entrée standard

   Une paire de lignes est comparé comme suit: sort compare chaque paire de champs, dans l'ordre spécifié sur la ligne de commande, en accord avec les options d'ordre associés, jusqu'à ce qu'une différence soit trouvée ou qu'il ne reste plus aucun champ. Si aucun champ clé n'est spécifié sort utilise une ligne entière comme clé par défaut. Finalement, sort compare les lignes entières comme si aucune option d'ordre autre que --reverse n'était spécifié. L'option stable désactive la dernière comparaison, tout comme l'option --unique.

OPTIONS

-c, --check, --check=diagnose-first Vérifie si le fichier donné est déjà trié. Si ce n'est pas le cas, affiche un la première ligne qui n'est pas dans l'ordre.
-C, --check=quiet, --check=silent Quitte avec succès si le fichier donné est déjà trié, avec un status de 1 le cas contraire. Identique à -c, mais n'affiche rien.
-m, --merge fusionne les fichiers en les triant ensemble. chaque fichier d'entrée doit déjà être triés individuellement.
-b, --ignore-leading-blanks Ignore les blancs pendant la recherche des clés triés dans chaque ligne.
-d, --dictionnary-order Trie de type annuaire téléphonique: ignore tous les caractères excepté les lettres, chiffres et les blanc.
-f, --ignore-case Ignore la casse lors du trie.
-g, --general-numeric-sort,--sort=general-numeric Trie numérique, converti un préfixe de chaque ligne en nombre virgule flottante double précision.
-i, --ignore-nonprinting Ignore les caractères non imprimables
-M, --month-sort, --sort=month Une chaîne initiale, consistant d'une quantité de blanc, suivi par une abréviation de mois, comparé dans l'ordre JANFEB...DEC
-n, --numeric-sort, --sort=numeric Trie numérique. Les nombres commencent chaque ligne et consistent de blanc options, un '-' optionnel et 0 ou plusieurs chiffres, qui peuvent être séparés par des séparateurs de millier, et optionnellement suivi par une partie décimale. Un nombre vide est traité comme '0'. La locale 'LC_NUMERIC' spécifie le caractère décimal et le séparateur de milliers. par défaut, un blanc est un espace ou une tabulation, mais LC_CTYPE peut changer çà.
-V, --version-sort Trie par strverscmp. Comparaison normal de chaîne excepté que les nombres décimaux sont triés par valeur numérique.
-r, --reverse Renverse le résultat de la comparaison.
-R, --random-sort, --sort=random Sort de manière aléatoire.
--compress-program=PROG Compresse les fichiers temporaires avec le programme spécifié. sans argument, il doit compresser l'entrée standard sur la sortie standard, et si -d est donné, il doit décompresser l'entrée standard sur la sortie standard.
--files0-from=FILE Désactive le traitement des fichiers nommés sur la ligne de commande, et traite ceux nommés dans FILE. chaque fichier est séparé par un ASCII NUL. si FILE vaut - , lit l'entrée standard.
-k POS1[,POS2], --key=POS1[,POS2] Spécifie le champ de trie qui consiste de la partie de la ligne entre POS1 et POS2 ou la fin de la ligne si POS2 n'est pas spécifié. Par exemple pour trier le 2eme champs, utiliser --key=2,2
--batch-size=NMERGE mélange au moins NMERGE entrées en une seule.
-o OUTPUT-FILE, --output=OUTPUT-FILE Écrit la sortie dans le fichier spécifié.
--random-source=FILE Utilise FILE comme source de données aléatoires.
-s, --stable désactive la comparaison de dernier recours.
-S SIZE, --buffer-size=SIZE Utilise un buffer de trie de la taille spécifiée. Par défaut SIZE est en unité de 1024 octets. Ajouter un '%' interprète la taille en pourcentage de la mémoire physique. Ajouter un 'K' pour Kilo-octets, M, G etc... b pour octets
-t SEPARATOR, --field-separator=SEPARATOR Spécifie le caractère de séparation des champs. Par défaut c'est un espace ou une tabulation, mais 'LC_CTYPE' peut changer çà.
-T TEMPDIR, --temporary-directory=TEMPDIR utilise TEMPDIR comme répertoire temporaire.
-u, --unique Normalement, sort seulement le premier d'une séquence de lignes qu'il trouve égal.
-z, --zero-terminated Délimite les items avec un octet zéro au lieu d'un newline

Exemples

trie numérique descendant
sort -n -r
trie alphabétique, en omettant les 2 premiers champs et le blanc au début du troisième champ.
sort -k 3b
trie numérique sur le second champ et tente de trier alphabétiquement le 3ème et le 4ème caractère du 5ème champ.
sort -t : -k 2,2n -k 5.3,5.4
trie le fichier password sur le 5ème champ et ignore les blancs. Trie les lignes avec des valeurs égales dans le 5ème champ sur le user ID dans le 3ème champ. les champs sont séparés par un ':'
sort -t : -k 5b,5 -k 3,3n /etc/passwd
sort -t : -n -k 5b,5 -k 3,3 /etc/passwd
sort -t : -b -k 5,5 -k 3,3n /etc/passwd

Codes de sortie

0 si pas d'erreur
1 si invoqué avec -c ou -C est que l'entrée n'a pas été triée
2 si une erreur s'est produite.
^
15 mars 2010

htmlpdflatexmanmd




/etc/apt/sources.list

/etc/apt/sources.list

Liste des sources de paquets debian

   La liste des sources de paquets indique où trouver les archives du système de distribution de paquets utilisés. ce fichier est /etc/apt/sources.list.

   Le format de chaque ligne est: type uri args. Le premier élément, type, détermine le format des args. uri est un identifiant universel de ressources (URI), qui est un sur-ensemble du plus spécifique et bien connu repère universel de ressources, ou URL. La fin de la ligne peut être un commentaire commençant par un caractère #.

sources.list.d

   /etc/apt/sources.list.d permet de lister des sources de paquets dans des fichiers distincts qui se terminent par .list. Leur format est le même que celui du fichier sources.list.

deb et deb-src

   Le type deb décrit une archive Debian classique à deux niveaux, distribution/composant. distribution peut prendre l´une des valeurs suivantes: stable, unstable, ou testing, et composant: main, contrib, non-free, ou non-us.

   Le type deb-src décrit le code source pour une distribution Debian dans le même format que le type deb. Une ligne deb-src est nécessaire pour récupérer les index des sources.

   Le format d´une entrée dans sources.list utilisant les types deb et deb-src est de la forme: deb uri distribution [composant1] [composant2] [...]

   distribution peut aussi contenir une variable $(ARCH), qui sera remplacée par l´architecture Debian (i386, m68k, powerpc, ...) sur laquelle s´exécute le système. Il est important d´indiquer les sources par ordre de préférence, la source principale apparaissant en premier.

Spécification des URI

file Le procédé file permet qu´un répertoire arbitraire au sein du système de fichier soit considéré comme une archive. On s´en sert avec les montages NFS, les miroirs et les archives locaux.
cdrom Le procédé cdrom permet l´utilisation d´un lecteur de cédérom avec la possibilité de changer de media. Utilisez le programme apt-cdrom(8) pour créer des entrées dans la liste des sources.
http Si une variable d´environnement http_proxy (au format http://server:port/) existe, le serveur mandataire indiqué par http_proxy est utilisé. Quand un serveur mandataire HTTP/1.1 demande une authentification, on peut utiliser la chaîne http://user:pass@server:port/.
ftp Le fonctionnement en mode ftp est largement configurable ; On remarquera qu´on peut indiquer un mandataire ftp avec la variable d´environnement ftp_proxy. On peut aussi spécifier un mandataire http (les serveurs mandataires http comprennent souvent les URL ftp) en utilisant cette méthode et SEULEMENT cette méthode. Les mandataires ftp utilisant http et qui sont spécifiés dans le fichier de configuration seront ignorés.
copy Le procédé copy est identique au procédé file excepté que les paquets sont copiés dans le cache du répertoire au lieu d´être utilisés directement depuis leur emplacement. C´est utile aux gens qui utilisent un disque zip pour recopier des fichiers avec APT.
rsh, ssh Le procédé rsh/ssh utilise rsh/ssh pour se connecter à une machine distante en tant que tel utilisateur donné et pour accéder aux fichiers. Aucune authentification par mot de passe n´est possible : il faut au préalable régler ce problème avec des clés RSA ou bien rhosts. Pour l´accès aux fichiers de la machine distante et le transfert, on utilise les commandes standard find et dd.
^
13 mars 2010

htmlpdflatexmanmd




Spanning-Tree Protocol

Spanning-Tree Protocol

Spanning-Tree Protocol and Algorithm

Introduction

   Le Spanning-Tree offre une solution de détection de boucles dans des LAN commutés, et offre également la possibilité de maintenir des redondance alternatives de lien pour prévenir d'éventuelle pannes.

  La première version du Spanning-Tree (STP, 802.1d) demandait un certain temps lors de la reconfiguration de la topologie, il a été remplacé par le Rapid Spanning-Tree Protocol (RSTP 802.1w) et le Multiple Spanning-Tree Protocol (MSTP, 802.1s).

  RSTP est donc une extension de STP, réduisant les temps de (re)configuration de la topologie active à 2sec contre 30 pour STP.

Bridge

   Par Bridge (= pont), on désigne tout appareil permettant de relier 2 segments d'un réseau, cela peut être un routeur, un concentrateur, un commutateur, etc. Étant donné que le STP s'utilise plus généralement sur un commutateur, j'utilise ici le terme commutateur pour représenter le terme Bridge.

Fonctionnement d'un commutateur

   Un commutateur est un appareil possédant au minimum 2 ports et qui permet de diriger les trames Ethernet.

  Chaque port du commutateur transmet et reçoit des trames depuis et vers le LAN sur lequel il est attaché. Un commutateur utilise une base de donnée appelée Filtering Database dans lequel sont enregistrées les adresses MAC associées à chaque port, c'est ce qui permet au commutateur de savoir ou diriger les trames dans un réseau.

  Lorsqu'une trame est reçue avec une adresse MAC de destination qui n'est pas incluse dans sa Filtering Database, le commutateur envoie la trame sur tous ses ports actifs. De même les trames émises en diffusion sont émise sur tous les ports actifs.

  Lorsqu'une boucle est présente, les trames sont re-émises et l'on obtient rapidement une tempête de diffusion. Afin de détecter ces boucles et d'éviter les tempêtes de diffusion, les commutateurs utilisent le protocole et l'algorithme Spanning-Tree.

Les boucles sur un réseau Ethernet

Exemple de boucles réseau

État et rôle des ports

   Chaque port d'un commutateur possède à un instant donné, un état, ainsi qu'un rôle.

  RSTP définit 3 états de port :

        Discarding indique que le port est exclu de la topologie active et n'enregistre pas d'adresse Mac. En fonction de son rôle il peut cependant rester en écoute pour intercepter les information STP.
        Learning est en mode écoute et enregistre les adresses MAC dans la Filtering Database.
        Forwarding correspond à un mode pleinement fonctionnel d'un port, il reçoit et émet des trames.

   RSTP définit également 4 rôle de port :

        Root un commutateur ne peut en avoir qu'un, il s'agit du chemin le plus court vers le commutateur Root. A noter qu'un commutateur Root n'en a pas.
        Designated Par défaut tout port qui n'est ni Root, Alternate ou Backup est un port Designated. Pour faire plus simple, un port Designated est un port qui envoie les trames en direction du port Root d'un commutateur.
        Alternate un port qui possède un chemin vers le port root, mais qui n'a pas été retenu, il s'agit d'une route alternative.
        Backup un port connecté au port Alternate d'un autre commutateur.

Principe du STP

   Pour qu'une topologie active soit construite, un commutateur va être élu Root, chaque commutateur utilisera le chemin le plus court vers ce commutateur pour propager les trames et éviter ainsi les boucles. Une fois la topologie active construite, les commutateurs vont s'envoyer des informations Spanning-Tree à intervalle régulier afin de garantir que la topologie active n'est pas modifiée. L'absence de réception d'informations Spanning-Tree de la part d'un commutateur peut signifier un lien coupé ou une panne, il sera alors nécessaire de redéfinir la topologie active.

  Les informations Spanning-Tree sont diffusées dans des RST BPDU (Bridge Protocol Data Unit). Ces trames sont émises en multicast à une adresse 01-80-C2-00-00-0[0 à F] suivant le type de protocole.

  Ces trames contiennent plusieurs informations :

Nb Octets Champ
2 Protocol Identifier
1 Protocol Version Identifier
1 BPDU Type
1 Flags
8 Root Identifier
4 Root Path Cost
8 Bridge Identifier
2 Port Identifier
2 Message Age
2 Max Age
2 Hello Time
2 Forward Delay
1 Version 1 Length

Protocol Identifier Il prend la valeur 0000 0000 0000 0000, qui identifie le RSTP et les versions antérieures de Spanning-Tree.
Protocol Version Identifier Prend la valeur 0000 0010 (0000 0000 pour les versions précédentes à RSTP)
BPDU Type Ce champ prend la valeur 0000 0010 qui dénote une configuration RST BPDU. (0000 0000 pour un configuration STP)
Flags Ces flags indiquent l'état de la topologie active ainsi que l'état et le rôle du port par lequel est envoyé le BPDU.

Flags STP
Note En jaune, ces flags ne sont disponible qu'à partir de RSTP, il sont inutilisés dans des BPDU compatible STP.
Version 1 Length Prend la valeur 0000 0000, il a été ajouté pour permettre de distinguer des versions future de STP qui pourraient inclure des informations supplémentaire.

Commutateur root

   Pour construire une topologie active sans boucle, un commutateur Racine doit être élu. Par défaut tous les commutateurs se considèrent root, il émettent alors leurs BPDU sur tout leur ports. Tous les commutateurs recevrons donc le BPDU de tous les commutateurs. Ainsi, chaque commutateur saura qui a été élu root. Pour déterminer le commutateur Root, chaque commutateur possède un identifiant. Celui ci est composé de l'adresse MAC du commutateur, plus un Identifiant de priorité, sur 2 octets (32768 par défaut, modifiable par pas de 4096). Cet identifiant est paramétrable et permet d'influencer l'élection du commutateur Root si on le souhaite.

  Cet identifiant est sous la forme ID : MAC

  Le commutateur ayant le plus petit identifiant est alors élu comme commutateur Root. Lorsqu'un commutateur reçoit un BPDU avec un Root Identifier plus petit que celui qu'il a enregistré, il le remplace et le mémorise. Tous les autres commutateurs vont alors converger leur trafic en direction de ce commutateur Root.

Root Path Cost

   Afin de déterminer le plus court chemin vers le commutateur Root, une valeur est calculée par chaque commutateur et transmises aux autres commutateurs directement reliés. Ainsi, chaque commutateur pourra déterminer son chemin le plus court.

  Le commutateur Root aura donc un Root Path Cost de 0. Les autres commutateurs vont donc calculer leur valeur en fonction du Root Path Cost reçu, plus le coût du port, permettant de déterminer quel sera le meilleur chemin vers le commutateur Root.

  Les valeurs correspondantes au niveau de priorité de port sont :

Bandes passante recommandées

Bridge Identifier

   L'identifiant du commutateur, comme nous l'avons vu, se compose d'une valeur de priorité suivie de l'adresse MAC du commutateur.

Port Identifier

   Chaque port possède un numéro unique sur un commutateur. Chaque port possède également un niveau de priorité. Ce niveau de priorité est paramétrable est permet donc de modifier la priorité d'un port administrativement.

  L'identifiant d'un port est donc la somme du niveau de priorité + le numéro du port.

  Le niveau de priorité d'un port va de 0 à 240 (128 par défaut), modifiable par pas de 16.

Message Age

   Ce champ est incrémenté à chaque commutateur traversé. Si ce champ devient supérieur au champ Max Age, le PBDU est détruit.Les 3 paramètres suivant servent à détecter les pannes :

Max Age Fixe le délai à partir duquel un commutateur n'ayant pas reçu de BPDU sur son port racine considère qu'un problème est posé.
Hello Time Lorsque la topologie active a atteint un état stable, le commutateur Root se met alors à émettre des BPDU à intervalle régulier. Ces BPDU sont ensuite retransmis de proche en proche vers tous les autres commutateurs. Ce mécanisme permet de garantir que la topologie active est toujours la même, et permet à un commutateur de détecter une panne lorsqu'il ne reçoit plus de BPDU sur un port au bout d'un temps donné.Par défaut le commutateur Root émet ces BPDU toutes les 2 secondes, il est possible de modifier cette valeur administrativement.
Forward Delay Fixe le délai à respecter pour que le port d'un commutateur passe d'un état bloqué à un état actif.

Cheminement de l'élection Root et de l'arbre

Vecteur de priorité

           Le vecteur de priorité est le vecteur de priorité Spanning-Tree maintenu pour un port donné. Il se présente sous la forme :

  Port priority vector = RootBrigeID : RootPathCost : DesignatedBridgeID : DesignatedPortID : BridgePortID

  Ce vecteur permet de déterminer le rôle de chaque port dont notamment le port root.

  Un commutateur A recevant un message de configuration sur un port PA d'un port désigné PB d'un commutateur B proclamant un Identifiant Root et un RootPathCost de RPCB :

  message priority vector = RB : RPCB : B : PB : A

Diffusion de son BPDU

           Le commutateur A va donc diffuser sur ses autres ports un BPDU en fonction des informations qu'il a reçu. Ainsi, si B est bien Root, il conservera son identifiant, va ajouter son Root Path Cost, son identifiant, et l'identifiant de son port d'émission. Ainsi un commutateur C qui reçoit son BPDU sur un port PC d'un port PA du commutateur A sera :

  message priority vector = RB : RPCB+PPCA : A : PA : PC

  Lorsqu'un commutateur B se proclame Root le vecteur de priorité root sera : B : 0 : B : 0 : 0

  donc son BPDU sera :

  message priority vector = B : 0 : B : PB : PB

Assignation du rôle des ports

   Grâce au vecteur de priorité root, un commutateur est en mesure de déterminer le port le plus proche du commutateur Root. Ce port sera donc son Port Root. Si ce commutateur a d'autres lien vers le commutateur root, mais qui n'ont pas été élus root, ces ports sont des Port Alternate. Ils seront à l'état Disabled.

  Un commutateur dont un port est relié à un port Root est un Port Designated, il est à l'état Forwarding.

  Un commutateur dont le port est relié à un port Alternate est un port Backup, il est à l'état Forwarding.

Détection et changement de la topologie

   Lorsqu'un changement dans la topologie est détectée, de nouveaux messages de type TCN (Topologie Change Notification) sont transmis au travers du réseau pour indiquer qu'il est nécessaire d'opérer les modifications de topologie.

Exemple

Exemple de topologie
   C1 étant le root, il émet toutes les 2sec des BPDU sur ses ports désignés. Ces paquets sont retransmis sur tous les ports désignés des autres commutateurs. Les PBDU sont également transmis sur les ports alternatifs pour indiquer que la connexion existe toujours.

  Si le lien entre C2 et C4 est rompu, les BPDU ne seront plus transmis. Ainsi après le délai MaxAge passé sans avoir reçu de BPDU, C4 va :

        - Considérer que sont port 2 n'est plus son port root.
        - Étant donné qu'il possède un port alternatif, il va le nommer port root.
        - Il vide sont cache MAC associé au port 2.
        - Ce port 2 devient un port désigné.

   puis C3 :

        - Après un délai MaxAge dépassé sans avoir reçu de BPDU, il va décider que sont port 2 ne remplis plus son rôle de port Backup.
        - Il va le passer en port désigné.
        - Il le passe d'abord à l'état d'écoute.
        - Il supprime les entrées MAC de son port Root.
        - Après un premier Forward Delay son port 2 passe à l'état d'apprentissage
        - Puis après un nouveau Forward Delay, le port devient actif.

   C3 ayant vidé son cache associé à son port Root, il transmet l'information à C1, qui à son tour va vider son port 2, et enfin C2 fera de même.

  Une fois fois la topologie active redéfinie, le commutateur Root recommence à émettre des BPDU à intervalle régulier.

Vidage des adresses MAC

   Lorsqu'un changement de topologie opère, certains commutateurs doivent vider les adresses MAC apprise sur certains ports. Ainsi, le port Root de C4, relié au port désigné C2, ne reçoit plus de BPDU, changera son port Root, il lui sera nécessaire de vider les adresse MAC apprise par son ancien port Root. Le port désigné du C2 devra également vider ses adresses MAC associés, puis remonter l'information en direction du commutateur Root, afin que tous les commutateurs intermédiaire vident leur adresses MAC associé à leur port désigné ou root qui menait vers le C4.

MSTP

   MSTP est une variante de RSTP. RSTP est unique sur un commutateur, ainsi lorsque plusieurs vlan existent, il n'est pas possible de mettre en place RSTP sur chaque vlan. MSTP a été conçu pour pouvoir disposer d'un Spanning-Tree par vlan.

Exemple mstp

Problèmes de sécurité lié à STP

   Plusieurs problèmes de sécurités ont été découvert avec STP. Il est ainsi très facile d'émettre des BPDU avec un identifiant de commutateur inférieur au Root, et de décrémenter l'identifiant de priorité toutes les secondes, une fois à 0, on repars à sa valeur initial et on recommence. On crée ainsi une reconfiguration permanente, certains port même, n'arriverons jamais à atteindre un état Forwading, Paralysant une partie du réseau.

   Il existe de nombreuses façon de détourner STP, une attaque des plus redoutable est de créer un MITM. Une machine attaquante est connecté d'un coté sur un commutateur A et de l'autre un commutateur B. Il émet un STP proclamant le Root, de nouvelles élections sont faite, il devient le root, tous les commutateurs convergents vers l'attaquant, il peut ainsi espionner le trafic qui passe entre 2 commutateurs.


        Illustration
----------------------------------------------------------
_______Clients_segment_________________Server_segment_____
.------------------------._________.----------------------.
|__Switch_w/_STP_#1__|------X_X--------|_Switch_w/_STP_#2_|
.____________________._________________'__________________'
__|________________|______________________|_|_____________
__|________________|______________________|_|___.___._____
__|________________|______________________|_|___|___|_____
__|.....___________|___.------.___________|_|___|_==|_____
_.------,__________|__|________|__________|_|___|_==|_____
_|Client_|'________|__|Attacking__________|__\_,|__-|_____
_|_PC____|_________\__|___PC___|_________/______|___|_____
_\------_/__________\_========_,________/_______|___|_____
__======/____________|_________|--------'______-------____
_______________________________________________Server_____

   Il est difficile de détecter des attaques de ce genre. On pourrait par exemple utiliser un IDS qui compare la topologie active avec une topologie de référence, mais cela impliquerai qu'on ne peut pas changer la topologie sans devoir modifier la topologie de référence, de plus une attaque pourrait être menée au même moment que la topologie change, ainsi la topologie de référence serait alors faussée.

   Spanning-Tree devrait donc être désactivé partout où il n'est pas nécessaire. De plus pour améliorer la sécurité, il est préférable d'utiliser des Routeurs, ou des switch/routeurs, de segmenter son réseau et d'utiliser des protocoles comme OSPF. Ce protocole gère bien mieux la topologie du réseau, et la segmentation adéquat du réseau en sous-réseau permet d'éviter de nombreuses attaques, notamment de type MITM.

^
07 juin 2010

htmlpdflatexmanmd




split

split

Crée des fichiers contenant des sections consécutives de l'entrée

   Par défaut, split place 1000 lignes de l'entrées, dans chaque fichier de sortie. Le nom des fichiers de sortie consiste en un PREFIX ('x' par défaut) suivi par un groupe de caractères ('aa', 'ab', ... par défaut).

OPTIONS

-l LINES, --lines=LINES Place LINES lignes dans chaque fichier
-b SIZE, --bytes=SIZE Place SIZE octets dans chaque fichier de sortie. SIZE accèpte un suffixe multiplicateur.
-C SIZE, --line-bytes=SIZE Place dans chaque fichier autant de lignes complètes que possible sans excéder SIZE octets.
-a LENGTH --suffix-length=LENGTH Spécifie la longueur des suffixes. (défaut : 2)
-d, --numeric-suffixes Utilise des chiffres dans les suffixes au lieu de lettres.
--verbose Écrit un diagnostique juste après que chaque fichier de sortie soit ouvert.
^
27 juin 2014

htmlpdflatexmanmd




sserver

sserver

Serveur de démonstration

   sserver et sclient sont de simples progammes client/serveur de démonstration. Quand sclient se connecte à sserver, il effectue une authentification Kerberos, et le serveur retourne le principal Kerberos qui a été utilisé. Le nom de service utilisé par sserver et sclient est sample. sserver nécessite que l'entrée sample/hostname.domain.name@REALM.NAME dans le keytab. Ce keytab est généré en utilisant le programme kadmin. L'option -S permet d'utiliser un keytab différent de celui par défaut.

   Vu que sample n'a normalement pas de port définis dans /etc/services, il faut généralement ajouter:

  sample 13135/tcp

  En utilisant sclient, il faut d'abord avoir une entrée dans la base Kerberos, en utilisant kadmin, et obtenir des tickets Kerbeors avec kinit.

Exemple de réponse en utilisant sclient:
sendauth succeeded, reply is:
reply len 32, contents:
You are nlgilman@JIMI.MIT.EDU

^
15 juin 2017

htmlpdflatexmanmd




ssh

ssh

programme de connexion distante

OPTIONS

-4 Force l'utilisation d'IPv4 uniquement
-6 Force l'utilisation d'IPv6 uniquement
-A Autorise le forwarding de l'agent d'authentification. Peut être spécifié par hôte dans un fichier de configuration.
-a Désactive le forwarding de l'agent d'authentification
-b bind_address Utilise l'adresse locale spécifiée pour la connexion
-C Demande la compression des données. Utile pour les connexions lentes, mais ralentit le traffic dans les réseaux rapide
-c cipher_spec Liste de chiffrements dans l'ordre de préférence pour le chiffrement de la session
-D [bind_address:]port Spécifie un port forwarding locale dynamique. Cela fonctionne en allouant un socker d'écoute sur le port côté local, optionnellement lié à l'adresse spécifiée. Quand une conexion est faite sur ce port, la connexion est envoyés au canal sécurisé, et le protocole d'application est ainsi utilisé pour déterminer où se connection depuis la machine distante. Actuellement les protocoles SOCKS4 et SOCKS5 sont supportés, et ssh agit comme un serveur SOCKS.
-E log_file Ajoute les logs débug à log_file au lieu de l'erreur standard
-e escape_char Définis le caractère d'échappement pour les sessions avec un pty (défaut: ~). Ce caractère est seulement reconnu au début d'une ligne. Ce caractère suivi par un '.' ferme la connexion. Suivi par control-Z suspend la connexion, et suivi par lui-même envoie le caractère échappé une fois.
-F configfile Spécifie un fichier de configuration par utilisateur alternatif. Défaut: ~/.ssh/config
-f ssh se place en tâche de fond juste avant l'exécution
-G Affiche sa configuration après avoir évalué Host et Match, puis quitte
-g Autorise les hôte distants à se connecter aux ports forwardés. Si utilisé dans une connexion multiplexée, cette option doit être spécifiée dans le processus maître
-I pkcs11 Spécifie la librairie PKCS#11 utilisé pour communiquer avec un jeton pkcs#11
-i identity_file Fichier contenant la clé privée. Défaut: ~/.ssh/id_dsa, ~/.ssh-id_ecdsa, ~/.ssh/id_ed25519, et ~/.ssh/id_rsa.
-J [user@]host[:port] Se connecte à l'hôte spécifié en créant d'abord un saut vers cet hôte, et en établissant un forwarding TCP vers la destination. Plusieurs sauts peuvent être spécifiés séparés par des ','
-K Active l'authentification GSSAPI et le forwarding GSSAPI
-k Désactive le forwarding GSSAPI
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket Spécifie que les connexion au port TCP ou socket unix donné dans l'hôte locla doivent être forwardés à l'hôte:port, ou socket unix donné
-l login_name Spécifie l'utilisation de connexion sur la machine distante.
-M Place le client ssh en mode master pour le partage de connexion. Peut être spécifié plusieurs fois pour ajouter une confirmation avant que les connexions esclaves soient acceptée
-m mac_spec Liste d'algorithmes MAC, dans l'ordre de préférence.
-N Ne pas exécuter une commande à distance. Utile pour un simple port forwarding
-n  Redirige stdin depuis /dev/null. Doit être utilisé quand ssh tourne en tâche de fond.
-O ctl_cmd Contrôle une connexion active multiplexant un processus maître. ctl_md est interprété et passé au processus maître. (check, forwald, cancel, exit, stop)
-o option Spécifie une option tel que trouvé dans le fichier de configuration
-p port Port de connexion sur l'hôte distant
-Q query_option Affiche les algorithmes supportés pour sshv2. (cipher, cipher-auth, mac, kex, key, key-cert, key-plain, protocol-version)
-q mode silencieux
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket Spécifie que les connexions au port TCP ou socket unix donné dans l'hôte distant doivent être forwardés à l'hôte:port ou socket unix donné, localement. Cela foncionne en alouant un socket pour écouter soit un port TCP ou un socket unix dans l'hôte distant. Quand une connexion est fait, elle est forwardée dans un canal sécurité, et une connexion est faite à l'hôte:port ou au socket, depuis la machine locale.
-S ctl_path Spécifie l'emplacement d'un socket de contrôle pour le partage de connexion, ou 'none' pour désactiver le partage de connexion
-s Peut être utilisé pour demander l'invocation d'un sous-système dans le système distant. Les sous-système facilitent l'utilisation de SSH comme transport sécurisé pour d'autres application.
-T Désactive l'allocation d'un pseudo-terminal
-t Force l'allocation d'un pseudo-terminal.
-v mode verbeux
-W host:port Demande que l'entrée et la sortie standard dans le client soient forwardés à l'hôte:port via un canal sécurisé. Implique -N, -T, ExitOnForwardFailure et ClearAllForwarding
-w local_tun[:remote_tun] Demande un forwarding avec le tunnel spécifié entre le client et le serveur
-X Active le forwarding X11.
-x Désactive le forwarding X11
-Y Active le forwarding X11 trusté, qui ne sont pas sujets aux extensions de contrôle X11 SECURITY
-y Envoie des informations en utilisant syslog, au lie de stderr

Authentification

   Les méthodes disponibles pour l'authentification sont: authentification basée sur GSSAPI, authentification basé sur l'hôte, authentification à clé publique, authentification par challenge-response, et authentification par mot de passe.

   L'authentification basé sur l'hôte fonctionne comme suit: si la machine sur laquelle l'utilisateur se log est listé dans /etc/hosts.equiv ou /etc/shosts.equiv dans la machine distante, et que les noms d'utilisateur sont les même des 2 côté, ou si les fichiers ~/.rhosts ou ~.shosts existent dans le répertoire personnel de l'utilisation dans la machine distante et contient une ligne contenant le nom de la machine cliente et le nom de l'utilisation dans cette machine, l'utilisateur est autorisé. Additionnellement, le serveur doit être capable de vérifie la clé hôte du client. Cette méthode d'authentification est peut sécurisé à cause de l'IP spoofing, DNS spoofing, et routing spoofing.

   L'authentification à clé publique fonctionne comme suit: Le schéma est basé sur la cryptographie à clé publique, en utilisant les cryptosystems où le chiffrement et le déchiffrement sont fait en utilisant des clés séparées, et il est impossible de dériver la clé de déchiffrement depuis la clé de chiffrement. L'idée et que chaque utilisateur créé une paire de clé publique/privée pour l'authentification. Le serveur connaît la clé publique, et seul l'utilisateur connaît la clé privée. ssh supporte les algorithmes DSA, ECDSA, Ed25519 et RSA.

   Le fichier ~/.ssh/authorized_keys liste les clés publiques qui sont permisses pour le logging. Quand l'utilisateur se log, ssh indique au serveur quel paire de clé utiliser pour l'authentification. Le client prouve qu'il a accès à la clé privéue et le sereur vérifie que la clé correspondante est autorisée à accéder au compte

   L'utilisateur créé sa paire de clé avec ssh-keygen, stocke la clé privée dans ~/.ssh/id_dsa, /.ssh/id_ecdsa, ~/.ssh/id_ed25519, ou ~/.ssh/id_rsa. et stocke la clé publique dans ~/.ssh/id_dsa.pub, ~/.ssh/id_ecdsa.pub, ~/.ssh/id_ed25519.pub, ou ~/.ssh/id_rsa.pub. L'utilisateur doit ensuite copier la clé publique dans ~/.ssh/authosized_keys dans le répertoire distant dans la machine distante. Ce fichier correspond au fichier rhosts conventionnel, et a une clé par ligne. Après ça, l'utilisateur peut se connecter sans donner de mot de passe

   Une variation de l'authentification à clé publique est disponible sous la forme d'une authentification par certificat. Au lieu de définir des clés publique/privées, des certificats signés sont utilisé. La manière la plus simple d'utilisation cette méthode d'authentification est avec un agent d'authentification, comme ssh-agent et optionnellement a directive AddKeysToAgent.

   L'authentification par challenge-réponse fonctionne comme suit: Le serveur envoie un challenge arbitraire, et demande une réponse. Des examples d'authentification par challenge-réponse incluent l'authentification BSD et PAM.

   Finallement, si d'autres méthodes d'authentification échouent, ssh demande un mot de passe. Le mot de passe est envoyé à l'hôte distant pour vérification; cependant, vu que toutes les communications sont chiffrées, le mot de passe ne peut pas être vu par quelqu'un qui écoute le réseau.

   ssh maintient et vérifie automatiquement une base d'identification pour tous les hôte qu'il à vu. Les clés d'hôte sont stockés dans ~/.ssh/known_hosts. De plus, /etc/ssh/ssh_known_hosts est automatiquement vérifié pour les hôtes connus. Tout nouvel hôte est automatiquement ajouté au fichier de l'utilisateur. Si l'identification d'un hôte change, ssh alerte et désactive l'authentification par mot de passe. L'option StrictHostKeyChecking peut être utilisée pour contrôler les login sur les machine dont la clé hôte n'est pas connue ou a changé.

   Quand l'identité d'un utilisateur a été acceptée par le serveur, le serveur exécute soit la commande donnée dans une session non-interactive ou, si aucune commande n'est spécifiée, donne un shell. Toute communication avec la commande distante ou le shell sont automatiquement chiffrés

   Si un pseudo-terminal a été alloué l'utilisateur peut utiliser les caractèse d'échappement ci-dessous

   Si aucun pseudo-terminal n'a été alloué, la session est transparent et peut être utilisée pour transférer des données binaire. Dans la plupart des systèmes, définis le caractère d'échappement à none va créer une session transparente même si un tty est utilisé

   La session se termine quand la commande ou le shell se termine et que toutes les connexions TCP et X11 ont été fermées.

Caractères d'échappement

   Quand un pseudo-terminal est demandé, ssh supporte certaines fonctions utilisées via un caractère d'échappement:

~. Déconnexion
~^Z mise en tâche de fond
~# Lister les connexions forwardées
~& mise en tâche de fond à la déconnexion en attendant que la connexion forwardée/session X11 se termine
~? Affiche la liste des caractères d'échappement
~ B Envoie un BREAK au système distant
~ C Ouvre une ligne de commande. Actuellement, ajoute le port forwarding en utilisant les options -L, -R, et -D. Permet également d'annuel un port forwarding existant avec -KL[bind_address:]port, -KR[bind_address:]port et -KD[bind_address:]port. !command permet à l'utilisateur d'exécuter une commande locale si PermitLocalCommand est autorisée
~ R rekeying de la connexion
~ V Diminue la verbosité
~ v Augmente la verbosité

TCP forwarding

   Le forwarding des connexions TCP via un canal sécurisé peut être spécifié soit sur la ligne de commande ou dans un fichier de configuration. Une application possible est une connexion sécurisé pour un serveur de messagerie.

   Dans l'exemple ci-dessous, on cherche à chiffrer les communications entre un client IRC et un serveur, même si le serveur IRC ne supporte pas directement le chiffrement des communication. Cela foncion comme suit: l'utilisateur se connecte à l'hôte distant en utilisant ssh, en spécifiant un port à utiliser pour forwarder les connexions au serveur distant. Après ça, il est possible de démarrer le service qui est chiffré dans la machine client, en se connectant au même port local, et ssh chiffre et forward la connexion.

L'exemple suivante tunnelise une session IRC depuis la machine cliente 127.0.0.1 sur le serveur distant server.example.com:
ssh -f -L 1234:localhost:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1

   Cela tunnélise une connexion au serveur IRC server.example.com, en joignant le canal #users, avec le pseudo pinky sur le port 1234. Le port n'est pas important du moment qu'il est supérieur à 1023, et qu'il n'est pas en conflit avec un port déjà utilisé. La connexion est redirigée au port 6667 sur le serveur distant.

   L'option -f met ssh en tâche de fond et la comande distant sleep 10 est spécifiée pour permettre de démarrer le service tunnélisé.

X11 Forwarding

   Si la variable ForwardX11 est à yes, et que l'utilisateur utilis X11 (la variable DISPLAY doit être définie), la connexion à l'affichage X11 est automatiquement forwardée dans le canal chiffré, et la connexion au vrai serveur X est faite depuis la machine locale.

   La valeur DISPLAY définie pas ssh va pointer vers le serveur, mais avec un numéro d'affichage supérieur à 0. C'est normal parce que ssh créé un serveur X proxy sur la machine serveur pour forwarder les connexions.

   ssh définis également autematiquement Xauthority sur le serveur. Il génère un cookie d'autorisation aléatoire, le stocke dans Xauthority et vérifie que toutes les connexions forwardée connaissent ce cookie et le remplace par le vrai cookie quand la connexion est ouverte. Le vrai cookie d'authentification n'est jamais envoyé au serveur.

   Si la variable ForwardAgent est à yes, et que l'utilisateur utilise un agent d'authentification, la connexion à l'agent est automatiquement forwardée au serveur.

Vérifier les clés hôte

En se connectant à un serveur pour la première fois, une empreinte de la clé publique est présentée à l'utilisateur (sauf si StrictHostKeyChecking a été désactivé). Les empreintes peuvent être déterminés par ssh-keygen:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

   Si l'empreinte est déjà connue, elle est matchée et la clé peut être acceptée ou rejetée. Si seul les empreintes MD5 sont disponibles, ssh-keygen -E peut être utilisé pour adapter l'algorithme de l'empreinte.

   Vu qu'il est difficile de comparer des clé hôte en regardant simplement les empreintes, il y a également un support pour comparer les clé hôte visuellement, en utilisant un moyen aléatoire. Avec VisualHostKey à yes, un petit graphique ASCII est affiché à chaque login au serveur. En apprenant le motif qu'un serveur connu produit, un utilisateur peut facilement voir qu'une clé a changé quand un motif complètement différent est affiché. Ces motifs pouvant être ambigûes, un motif qui semble être similaire ne donne qu'une bonne probabilité que la clé hôte soit la même, sans garantie.

Pour obtenir une liste des empreintes avec leur motif aléatoire:
ssh-keygen -lv -f ~/.ssh/known_hosts

   Si l'empreinte est inconnue, une méthode alternative de vérification est disponible: les empeintes SSH vérifiés par DNS. Un enregistrement de ressource (RR), SSHFP, est ajouté à un fichier de zone et le client est capable de matche l'empreinte avec la clé présentée.

Dans cet exemple, un client se connecte au serveur, host.example.com. Le RR SSHFP doit être présent dans le fichier de zone:
ssh-keygen -r host.example.com
Les lignes affichées sont ajoutées dans la zone. Pour vérifier que la zone réponde à la demande d'empreinte:
dig -t SSHFP host.example.com
Finalement le client se connecte
ssh -o "VerifyHostKeyDNS ask" host.example.com
Voir l'option VerifyHostKeyDNS

VPN basés sur SSH

   ssh support les tunnels VPN en utilisant les périphériques tun, permetant à 2 réseaux d'être joint de manière sécurisé. L'option PermitTunnel contrôle si le serveur le supporte et quel niveau.

L'exemple suivant connecte un réseaux client 10.0.50.0/24 avec un réseau distant 10.0.99.0/24 en utilisant une connection point-à-point de 10.1.1.1 vers 10.1.1.2, le serveur ssh dans la gateway vers le réseau distant 192.168.1.15, l'autorise. Dans le client:
ssh -f -w 0:1 192.168.1.15 true
ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
route add 10.0.99.0/24 10.1.1.2
Dans le serveur:
ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
route add 10.0.50.0/24 10.1.1.1
L'accès client peut être personnalisé plus finement via /root/.ssh/authorized_keys et l'option serveur PermitRootLogin. L'entrée suivante permet les connexions dans tun1 par l'utilisateur jane, et dans tun2 par john, si PermitRootLogin est à forced-commands-only:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Variables d'environnement

   ssh définis les variables d'environnement suivants:

DISPLAY Emplacement du serveur X11, automatiquement définis par ssh
HOME Répertoire personnel de l'utilisateur
LOGNAME Nom de l'utilisateur
MAIL Emplacement de la boite mail de l'utilisateur
PATH PATH par défaut, tel que spécifié à la compilation de ssh
SSH_ASKPASS Si définis, exécute le programme spécifié et ouvre une fenêtre X11 pour lire la passphrase
SSH_AUTH_SOCK Identifie le chemin d'un socket UNIX utilisé pour communiquer avec l'agent
SSH_CONNECTION Identifie le client et le serveur de la connexion. Contient 4 valeurs: IP, port client, IP, port serveur.
SSH_ORIGINAL_COMMAND Contient la ligne de commande originale si une commande forcée est exécutée.
SSH_TTY Définis le nom du tty associé avec le shell ou la commande courante
TZ Affecte le timezone utilisé
USER nom de l'utilisateur

   Additionnellement, ssh lit ~/.ssh/environment, voir PermitUserEnvironment

Fichiers

~/.rhosts Utilisé pour l'authentification basé sur l'hôte
~/.shosts idem .rhosts, mais sans login permit avec rlogin/rsh
~/.ssh/ Répertoire de configuration par défaut pour le utilisateurs
~/.ssh/authorized_keys Liste des clés publiques qui peuvent être utilisé pour se connecter avec cet utilisateur.
~/.ssh/config Fichier de configuration de l'utilisateur
~/.ssh/environment Contient des définitions additionnels pour les variables d'environnement
~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519
~/.ssh/id_rsa Clé publique pour l'authentification.
~/.ssh/known_hosts Contient une liste de clés hôte pour tous les hôtes sur lesquels l'utilisateur s'est connecté
~/.ssh/rc Exécuté par ssh quand l'utilisateur se logs, juste avant de lancer le shell ou la commande
/etc/hosts.equiv Fichier pour l'authentification basé sur l'hôte. doit être writable par root uniquement
/etc/shosts.equiv idem sans autoriser rlogin/rsh
/etc/ssh/ssh_config Fichier de configuration global.
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key Contient la clé privée de l'hôte
/etc/ssh/ssh_known_hosts Liste globale de clés hôtes connus. Ce fichier devrait être préparé par l'administrateur système
/etc/ssh/sshrc Exécuté par ssh quand l'utilisateur se log, juste avant de lancer le shell ou la commande.

Code de sortie

   ssh quitte avec le statut de sortie de la commande distante, ou avec 255 si une erreur s'est produite.
^
15 juin 2017

htmlpdflatexmanmd




ssh-add

ssh-add

Ajouter des clé privées à l'agent d'authentification

   ssh-add ajoute des identité à l'agent d'authentification. Sans arguments, il ajoute ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519. Une fois chargés, ssh-add tente de charger les certificats correspondants. Alternativement, les fichiers peuvent être donnés sur la ligne de commande.

   Si un fichier nécessite une passphrase, ssh-add la demande à l'utilisateur.

OPTIONS

-c Indique que les identités ajoutées sont sujet à confirmation avant d'être utilisé pour l'authentification. La confirmation est effectuée par ssh-askpass.
-D Supprime toutes les identités de l'agent
-d Supprime les identité de l'agent.
-E fingerprint_hash md5|sha256 Spécifie l'algorithme de hashage utilisé pour afficher les empreintes de clé.
-e pkcs11 Supprime les clé fournie par les librairies partagées PKCS#11
-k Traite les clé privée uniquement et ignore les certificats
-L Liste les paramètres de clé publique de toutes les identités représentés par l'agent
-l Liste les empreinte de toutes les identité représentés par l'agent
-s pkcs11 Ajoute les clés fournies par la librairie partagée PKCS#11
-t life Définis la durée de vie des identité ajoutées à l'agent
-X Déverrouille l'agent
-x Verrouille l'agent avec un mot de passe

Variables d'environnement

DISPLAY Spécifie l’affichage X11 à utiliser
SSH_ASKPASS programme utilisé pour demander la passphrase. Défaut: ssh-askpass
SSH_AUTH_SOCK Socket unix utilisé pour communiquer avec l'agent
^
15 juin 2017

htmlpdflatexmanmd




ssh-agent

ssh-agent

Agent d'authentification

   ssh-agent maintient les clé privées utilisées pour l'authentification à clé publique. ssh-agent est généralement démarré au début d'une session X ou d'une session login, et toutes les autres fenêtres ou programmes sont démarrés comme client du programme ssh-agent. Via l'utilisation de variables d'environnement l'agent peut être localisé et utilisé automatiquement pour l'authentification en se connectant dans d'autres machines via ssh.

OPTIONS

-a bind_address Lie l'agent au socket UNIX. Défaut: $TMPDIR/ssh-XXXXXXXXXX/agent.‹ppid›
-c Génère des commande C-shell sur stdout.
-D Ne bascule pas en tâche de fond
-d mode debug
-E fingerprint_hash md5|sha256 Spécifie l'algorithme de hashage utilisé en affichant les empreintes de clé.
-k Termine l'agent en cours (donné par $SSH_AGENT_PID)
-P pkcs11_whitelist Spécifie une liste de motif de chemins acceptables pour les libraires PKCS#11 qui peuvent être ajoutés en utilisant l'option -s. Défaut: /usr/lib/, /usr/local/lib/
-s Génère des commandes bash sur stdout. Mode par défaut si le shell n'est pas csh
-t life Durée de vie des identités ajoutées à l'agent.

   Si une ligne de commande est donnée, elle est exécutée comme sous-processus de l'agent. Quand la commande se termine, l'agent également. L'idée est que l'agent est lancé sur la machine de l'utilisateur. Les données d'authentification n'ont pas besoin d'être stockées dans d'autres machines, et les passphrases d'authentification ne sont jamais envoyés sur le réseau. Cependant, la connexion à l'agent est forwardée via les logins distants, et l'utilisateur peut donc utiliser les privilèges donnés par les identités dans le réseau de manière sécurisée.

   Il y a 2 manières de définir l'agent: la première est que l'agent démarre une nouvelle sous-commande dans laquelle certaines variables sont exportée. La seconde est que l'agent affiche les commandes shell nécessaire. ssh recherche ensuite ces variables et les utilise pour établir une connexion à l'agent.

   L'agent n'envoie jamais de clé privée, les opérations qui nécessitent une clé privée sont gérés par l'agent, et le résultat est retourné au demandeur. Un socket unix est créé et le nom de ce socket est stocké dans SSH_AUTH_SOCK. Ce socket est accessible à l'utilisateur courant.
^
15 juin 2017

htmlpdflatexmanmd




ssh-keygen

ssh-keygen

Générateur, gestionnaire et convertisseur de clé d'authentification

- ssh-keygen génère des clés utilisables par le protocole sshv2. ssh-keygen peut également être utilisé pour générer des groupes à utiliser dans les échanges Diffie-Hellman.
- ssh-keygen peut être utilisé pour générer et mettre à jours des listes de révocation de clé, et pour tester si les clés données ont été révoquées.
- Normallement chaque utilisateur souhaitant utiliser ssh avec une authentification par clé publique le lance une fois pour créer la clé d'authentification dans ~/ .ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa. Additionnellement, les administrateurs système peuvent l'utiliser puor générer des clé hôte, comme dans /etc/rc.
- Normallement ce programme génère la clé et demande un nom de fichier pour stocker la clé privée. La clé publique est stockée dans un fichier de même nom suffixé avec ".pub". Le programme demande également une passphrase.
- Il n'y a pas de manière de récupérer une passphrase perdue. Si la passphrase est perdue ou oubliée, une nouvelle clé doit être générée et la clé publique correspondante copiée dans les autres machines
- Pour les clés stockées dans le nouveau format openssh, il y a également un champs commentaire pour aider à identifier la clé.

OPTIONS

-A Pour chaque types de clé (rsa,-sa,ecdsa et ed25519) pour laquelle les clés hôte n'existent pas, génère les clés hôte avec le fichiers spécifié, une passphrase vide, la taille par défaut, et le commentaire par défaut.
-a rounds En sauvant une clé privée au nouveau format, spécifie le nombre de KDF (fonction de dérivation de clé) utilisé.
-B Affiche le digest de la clé privée spécifiée
-b bits Taille de la clé à créer
-C comment Fournis un nouveau commentaire
-D pkcs11 Charge les clés publique fournis par la librairie pkcs#11. Utilisé avec -s, indique qu'une clé CA réside dans le jeton PKCS#11.
-E md5|sha256 Spécifie l'algorithme de hashage en affichant les empreintes de clé
-e  Lit une clé privée ou publique OpenSSH et l'affiche sur stdout dans un des formats de l'option -m
-F hostname Recherche le nom d'hôte spécifié dans un fichier known_hosts.
-f filename Spécifie le nom du fichier de clé
-G output_file Génère des premiers candidats pour DH-GEX.
-g Utilise le format DNS pour afficher les enregistrements de ressource d'empreinte en utilisant -r
-H Hash le fichier known_hosts. Remplace les hostnames et adresses avec les représentations hashés.
-h En signant une clé, créé un certificat hôte au lieu d'un certificat utilisateur.
-l certificate_identity Spécifie l'identité de clé en signant une clé publique.
-i Cette option lit une clé privée ou publique non-chiffrée au format spécifié par -m et l'affiche au format compatible OpenSSH sur stdout.
-J num_lines Quitte après n ligne pendant l'exécution du screening des candidats DH en utilisant l'option -T.
-j start_line Défarre le screening à la ligne spécifiée
-K checkpt Écris la dernière ligne traitée dans le fichier spécifié en effectuant le screening de candidat DH.
-k Génère un fichier KRL
-L Affiche le contenu d'un ou plusieurs certificats
-l Affiche l'empreinte du fichier de clé publique spécifié.
-M memory Quantité de mémoire à utiliser (en Mo) en générant le moduli candidat pour DH-GEX
-m RFC4716|PKCS8|PEM Format de clé pour -i et -e
-N new_passphrase Fournis une nouvelle passphrase
-n principals Spécifie un ou plusieurs principaux à inclure dans un certificat en signant une clé.
-O option Spécifie une option de certificat, en signant une clé. Peut être spécifié plusieurs fois. Les options valides sont:

        clear Efface toutes les permissions permises
        critical:name[=contents]
        Extension:name[=contents] Inclus une option ou une extension arbitraire
        force-command=command Force l'exécution de la commande au lieu d'un shell ou de la commande spécifié par l'utilisateur quand le certificat est utilisé pour l'authentification
        no-agent-forwarding Désactive le forwarding ssh-agent
        no-port-forwarding Désactive le forwarding de port
        no-pty Désactive l'allocation pty
        no-user-rc Désactive l'exécution -e ~/.ssh/rc
        no-x11-forwarding Désactive le forwarding X11
        permit-agent-forwarding Autorise le forwarding ssh-agent
        permit-port-forwarding Autorise le port forwarding
        permit-pty Autorise l'allocation pty
        permit-user-rc Autorise l'exécution de ~/.ssh/rc
        permit-x11-forwarding Autorise le forwarding X11
        source-address=address_list Restreint les adresses sources depuis lequel le certificat est considéré valide.

-o Sauve la clé privée en utilisant le nouveau format au lieu de PEM
-P passphrase Fournis l'ancienne passphrase
-p Demande de changer la passphrase de la clé privée au lieu de créer une nouvelle clé
-Q Teste si les clé ont été révoqués
-q mode silencieux
-R hostname Supprime toutes les clé appartenant à hostname dans known_hosts
-r hostname Affiche le RR SSHFP pour la clé publique spécifiée
-S start Spécifie le point de départ en hexa en générant un moduli candidat pour DH-GEX
-s ca_key Signe un clé publique en utilisant la clé CA spécifiée
-T output_file Teste les premiers candidats à l'échange DH
-t dsa|ecdsa|ed25519|rsa Spécifie le type de clé à créer
-u Met à jours une KRL
-V validity_interval Spécifie un interval de validité en signant un certificat.
-v mode verbeux
-W generator Spécifie le générateur souhaité en testant le moduli pour DH-GEX
-y Lit une clé privée au format OpenSSH et affiche une clé publique sur stdout
-z serial_number Spécifie un numéro de série à embarquer dans le certificat.

Génération de moduli

ssh-keygen peut être utilisé pour générer des groupes pour le protocole de groupe d'échange Diffie-Hellman (DH-GEX). Générer ces groupes se fait en 2 étapes: Les premiers candidats sont générés en utilisant un processus rapide mais consommateur de mémoire. La génération des premiers sont effectués en utilisant -G:
ssh-keygen -G moduli-2048.candidates -b 2048
Par défaut, la recherche des premiers commence au point aléatoire dans la plage de longueur souhaitée, mais peut être changé avec -S. Une fois un jeu de candidats généré, ils doivent être screené, avec l'option -T. Dans ce mode, ssh-keygen lit les candidats depuis l'entrée standard, ou depuis un fichier avec -f, par exemple:
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Par défaut, chaque candidat est sujet à 100 test de primalité. Cela peut être changé avec -a. La valeur de générateur DH est choisie automatiquement pour le premier en considération. -W permet de choisir un générateur spécifique. Les valeur de générateur sont 2, 3 et 5.

   Les groupes DH screenés peuvent être installés dans /etc/moduli. Il est important que ce fichier contienne le moduli d'une plage de longueur de bit et que les partis d'une connections partage un moduli commun.

Certificats

   ssh-keygen suppporte la signature de clé pour produire des certificats qui peuvent être utilisés pour l'authentification utilisateur et hôte. Les certificats consistent d'une clé publique, des informations d'identité, 0 ou plusieurs principaux et un jeu d'options qui sont signés par une clé d'autorité de certification. Les clients ou serveurs peuvent ainsi truster seulement la clé CA et vérifier la signature des certificats. Noter que les certificats OpenSSH sont différents et plus simple que les certificats X.509.

sh-keygen support 2 types de certificats: utilisateur et hôte. Les certificats utilisateur authentifient les utilisateurs auprès des serveurs, et les certificats hôte authentifient les serveurs auprès des utilisateurs. Pour générer un certificat utilisateur:
ssh-keygen -s /path/to/ca.key -I key_id /path/to/user_key.pub
Le certificat résultant sera placé dans /path/to/user_key-cert.pub. Un certificat hôte nécessite l'option -h:
ssh-keygen -s /path/to/ca_key -I key_id -h /path/to/host_key.pub
Il est possible de signer en utilisant une clé CA stockée dans un jeton PKCS#11 en fournissant la librairie avec -D
ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id user_key.pub
Dans tous les cas, key_id est un identifiant de clé qui est loggé par le serveur quand le certifica est utilisé pour l'authentification. Les certificats peuvent être limités pour être valide pour un jeu de principaux. Par défaut, les certificats générés sont valides pour tous les utilisateurs et tous les hôte. Pour générer un certificat pour un jeu spécifié de principaux:
ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub
ssh-keygen -s ca_key -I key_id -h -n host.domain host_key.pub

   Des limitation aditionneles sur la validité et l'utilisation des certificats utilisateur peuvent être spécifiés. L'option -V permet de spécifier les dates de validité.

KRL

   ssh-key est capable de gérer des listes de révocation de clé. Ces fichiers binaire spécifient des clés ou certificats qui sont révoqués en utilisant un format compacte.

   Les KRL peuvent être générés en utilisant le flag -k. Cette option lit un ou plusieurs fichiers depuis la ligne de commande et génère une nouveau KRL. Les fichiers peuvent contenir une spécification KRL, ou des clé publique, listées une par ligne. Les clés publique sont révoquées en listant leur hash ou leur contenu dans la KRL et les certificats révoqués par numéro de série ou ID de clé.

   Révoquer les clé en utilisant une spécification KRL offre un contrôle explicite sur les types d'enregistrements utilisés pour révoquer les clé et peut être utilisé pour révoquer directement les certificats par numéro de série ou ID de clé sans avoir le certificat original complet. Une spécification KRL consiste de lignes contenant une des directives suivantes:

serial: serial_number[-serial_number] Révoque un certificat avec le numéro de série spécifié
id: key_id Révoque un certificat avec l'ID de clé spécifié
key: public_key Révoque la clé spécifiée
sha1: public_key Révoque la clé spécifiée par son hash sha1

   Les KRL peuvent être mises à jours avec -u. Qunad cette option est spécifiée, les clés listées via la ligne de commande sont fusionnées dans la KRL. Il est également possible de tester si un clé particulière est révoquée avec -Q.
^
15 juin 2017

htmlpdflatexmanmd




ssh-keyscan

ssh-keyscan

rassembler les clé publiques ssh

   ssh-keyscan permet de rassembler les clé hôtes. Il a été conçu pour aider à construire et vérifier les fichiers ssh_known_hosts.

OPTIONS

-4 Force l'utilisation d'adresses IPv4 uniquement
-6 Force l'utilisation d'adresses IPv6 uniquement
-c Demande les certificats depuis les hôtes cible au-lieu des clés
-f file List les hôtes ou les paires "addrlist namelist" depuis le fichier spécifié, un par ligne
-H Hash tous les noms d'hôtes et les adresses dans la sortie.
-p port Port de connexion à l'hôte distant
-T timeout timeout pour les tentatives de connexion
-t dsa|ecdsa|ed25519|rsa Type de clé à récupérer dans les hôtes scannés
-v mode verbeux

Sécurité

   Si un fichier ssh_known_hosts est construit avec ssh-keyscan sans vérifier les clés, les utilisateurs seront vulnérables aux attaques MITM. D'une autre manière, si le modèle de sécurité permet un tel risque, ssh-keyscan peut aider à detecter les fichiers de clé altérés ou les attaques MITM qui ont commencés après que le fichiers ssh_known_hosts ait été créé

Fichiers

Format d'entrée
1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4
Format de sortie pour RSA, DSA, ECSDA et Ed25519:
host-or-namelist keytype base64-encoded-key
où keytype est “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” ou “ssh-rsa”

Exemples

Affiche la clé hôte rsa pour la machine "hostname":
ssh-keyscan hostname
Trouver tous les hôte depuis le fichier ssh_hosts qui ont une clé différente:
ssh-keyscan -t rsa,dsa,ecdsa,ed25519 -f ssh_hosts | sort -u - ssh_known_hosts | diff ssh_known_hosts -
^
15 juin 2017

htmlpdflatexmanmd




ssh-keysign

ssh-keysign

Helper pour l'authentification basées sur l'hôte

   ssh-keysign est utilisé par ssh pour accéder aux clés d'hôte local et génère la signature numérique requise durant l'authentification basées sur l'hôte. ssh-keysign est désactivé par défaut et peut seulement être activé dans la configuration client globale avec EnableSSHKeysign yes. ssh-keysign est invoqué par ssh.

^
15 juin 2017

htmlpdflatexmanmd




sshd

sshd

Service ssh

OPTIONS

-4 Force l'utilisation d'adresses IPv4 uniquement
-6 Force l'utilisation d'adresses IPv6 uniquement
-C con_spec Spécifie les paramètres de connexion à utiliser pour le mode test étendu -T. Si fournis, toute directive Match dans la configuration qui s'applique à l'utilisateur, hôte, et adresse spécifié sont définis avant d'écrire la configuration sur stdout.
-c host_certificate_file Spécifie le chemin du certificat. Il doit matcher un fichier de clé hôte spécifié par -h ou HostKey
-d Ne lance pas en tâche de fond
-d mode debug
-E log_file Ajoute les logs de debuggage à ce fichier au lieu des logs système
-e  Écrit les logs de debuggage sur stderr au lieu des logs système
-f config_file Spécifie le nom d'un fichier de configuration. Défaut: /etc/ssh/sshd_config.
-g login_grace_time Délai de grâce pour que les clients puissent s'authentifier. Défaut: 120 secondes. 0 = aucune limite.
-h host_key_file Fichier depuis lequel la clé hôte est lue. Doit être donné si sshd ne tourne pas en root. Défaut: /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key.
-i Spécifie que sshd est lancé depuis inetd
-o option Peut être utilisé pour donner des options au format utilisé dans le fichier de configuration
-p port Port d'écoute. Défaut: 22. Plusieurs ports sont permis. Si spécifié, la directive Port est ignorée. Les ports spécifié en utilisant ListenAddress remplace les ports de la ligne de commande
-q Mode silencieux. N'envoie rien aux logs système
-T Mode test étendu. Vérifie la validité du fichier de configuration, affiche la configuration effective sur stdout puis quitte.
-t Mode test. Vérifie la validité du fichier de configuration et les clés.
-u len Spécifie la taile du champs dans la structure utmp qui maintient le nom d'hôte distant. Si le nom d'hôte résolu est supérieur à len, la valeur décimale est utilisé à la place. Cela permet aux hôtes avec un nom d'hôte très long d'être identifiés de manière unique.

Authentification

   sshd support le protocole ssh v2 uniquement. Chaque hôte a une clé spécifique, utilisée pour identifier l'hôte. Quand un client se connecte, le service répond avec sa clé hôte publique. Le client compare la clé avec sa base pour vérifier qu'elle n'a pas changé. Un agrément de clé Diffie-Hellman est utilisé pour générer une clé de session partagée. Le reste de la session est chiffrée en utilisant un chiffrement symétrique, actuellement AES-128, Blowfish, 2DES, CAST128, Arcfour, AES-192, ou AES-256. Le client sélectionne l'alogrithme à utiliser parmis ceux offerts par le serveur. Additionnellement, l'intégrité de session est fournie via un code MAC (hmac-md5, hmac-sha1, umac-64, umac-128, hmac-sha2-256 ou hmac-sha2-512).

   Finalement, le serveur et le client entrent dans un dialogue d'authentification. Le client tente de s'authentifier lui-même en utilisant une authentification basé sur l'hôte, authentification à clé publique, authentification par challenge-réponse, ou authentification par mot de passe. Si le client réussi à s'authentifier, il entre en préparation d'ouverture de session. À ce moment le client peut demander des éléments tel qu'un pseudo-tty, des connexions de forwarding X11, connexions forwarding TCP, ou forwarder la connexion de l'agent d'authentification via le canal sécurisé.

   Après cela, le client demande soit un shell, ou l'exécution d'une commande. Les partis entrent en mode session. Dans ce mode, un des partis peut envoyer des données, donc les données sont envoyer depuis/vers le shell ou la conmmande dans le serveur, et le terminal côté client. Quand le programme utilisateur se termine et que toutes les connexions sont fermées, le serveur envoie un status de sortie au client, et les 2 parties se terminent.

Processus de connexion

   Quand un utilisateur se connecte, sshd effectue les étapes suivantes:

1. si le login est dans un tth, et qu'aucune commande n'a été spécifiée, affiche la date de dernière connection et /etc/motd
2. Si le login est dans un tth, enregistre l'horodatage de connexion
3. Véfirie /etc/nologin; s'il existe, affiche son contenu et quitte (sauf root)
4. Change pour s'exécuter avec des privilèges utilisateurs normaux
5. Définis un environnement basique
6. Lit ~/.ssh/environment, s'il existe, et les utilisateurs sont autorisés à changer leur environnement.
7. Change le répertoire personnel de l'utilisateur
8. Si ~/.ssh/rc existe, et que l'option PermitUserRC est définis, le lance, sinon si /etc/ssh/sshrc exist, le lance, sinon lance xauth.
9. Lance le shell ou la commande de d'utilisateur. Toutes les commandes sont lancées sous le shell de login de l'utilisateur.

sshrc

   Si le fichier ~/.ssh/rc existe, sh le lance après avoir lu les fichiers d'environnement, mais avant de lancer la commande ou le shell de l'utilisateur. Il ne doit pas produire de sortie sur stdout; stderr doit être utilisé à la place. Si le forwarding X11 est utilisé, il reçoit la paire "proto cookie" dans son entrée standard. Le script doit appeler xauth parce que sshd ne lance pas xauth automatiquement pour ajouter les cookies X11.

   Le but premier de ce fichier est de lancer des routines d'initialisation qui peuvent être nécessaires avant que le répertoire personnel de l'utilisateur devienne accessible. AFS est un exemple particulier d'un tel environnement.

Ce fichier contient probablement du code d'initialisation suivi par quelquechose de similaire à:
if read proto cookie && [ -n "$DISPLAY" ]; then
    if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
        # X11UseLocalhost=yes
        echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie
    else
        # X11UseLocalhost=no
        echo add $DISPLAY $proto $cookie
    fi | xauth -q -
fi

   Si ce fichier n'existe pas, /etc/ssh/sshrc est lancé, et s'il n'existe pas, xauth est utilisé pour ajouter le cookie.

Fichier authorized_keys

   AuthorizedKeysFile spécifie les fichiers contenant les clé publique pour l'authentification. Si cette option n'est pas spécifiée, le défaut est ~/.ssh/autorized_keys et ~/.ssh/authorized_keys2. Chaque ligne du fichier contient une clé. Les clé publiques consistent des champs suivants: options, keytype, base64-encoded key, comment. Le champ option est optionnel. Le keytype est “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” ou “ssh-rsa”.

   Noter que chaque ligne peut faire des centaines d'octets de longs, jusqu'à une limite de 8Ko, ce qui permet des clé DSA jusqu'à 8Ko, et des clé RSA jusqu'à 16Ko.

   sshd force une clé RSA minimal de 768 bits. Les options, si présentes, sont séparés par ','. Aucun espace n'est permis, excepté entre guillemets double. Les options suivantes sont supportés:

agent-forwarding Autorise le forwarding de l'agent d'authentification précédemment désactivé par l'option restrict
cert-autority Spécifie que la clé est une autorité de certification qui sert à valider les certificats utilisateurs
command="command" Cmmande exécutée quand cette clé est utilisée. Peut être utile pour restreindre une clé a effectuer une opération spécifique.
environment="NAME=value" Définie une variable d'environnement
from="pattern-list" Spécifie que le nom canonique de l'hôte distant ou son IP doivent être présents dans cette liste.
no-agent-forwarding Interdit le forwarding de l'agent d'authentification
no-port-forwarding Interdit le forwarding TCP
no-pty Empêche l'allocation tty
no-user-rc Désactive l'exécution de ~/.ssh/rc
no-X11-forwarding Interdit le forwarding X11
permitopen="host:port" Limite le forwarding de port de ssh -L, à l'hôte:port spécifié.
port-forwarding Active le forwarding précédemment désactivé par l'option restrict
principals="principals" Liste de principaux pour l'authentification
pty Autorise l'allocation tty précédemment désactivé par l'option restrict
restrict Active toutes les restrictions, forwarding, pty, ~/.ssh/rc.
tunnel="n" Force un périphérique tun dans le serveur
user-rc Autorise l'exécution de ~/.ssh/rc précédemment désactivé par l'option restrict
X11-forwarding Autorise le forwarding X11 précédemment désactivé par l'option restrict

Fichier ssh_known_hosts

   Les fichier /etc/ssh/ssh_known_hosts et ~/.ssh/known_hosts contiennent les clés publiques pour tous les hôtes connus. Le fichier global devrait être préparé par l'administrateur, et le fichier par utilisateur est maintenu automatiquement. Chaque ligne dans ces fichier contient les champs suivants: marquer, nom d'hôte, type de clé, clé encodé en base64, commentaire. Les champs sont séparés par des espaces.

   Le marqueur est optionnel, mais s'il est présent il doit être sous la forme '@cert-authority' pour indiquer que la ligne contient un certificat d'autorité, ou '@revoked' pour indiquer que la clé contenu dans la ligne est révoquée.

   Les noms d'hôte sont une liste de motifs séparé par ','; chaque pattern est matché avec le nom canonique de l'hôte (en authentifiant un client) ou avec le nom du l'utilisateur (en authentifiant un serveur). A pattern peut inclure '*', '?', et '!' pour la négation.

   Alternativement, les noms d'hôte peuvent être stockés de manière hashé pour cacher les noms d'hôte ou les adresse.

   Le type de clé et la clé encodé en base64 sont pris directement depuis la clé hôte; ils peuvent être obtenus, par exemple, depuis /etc/ssh/ssh_host_rsa_key.pub.

   Il est permis, mais non recommandé, d'avoir plusieurs lignes ou différentes clés hôte pour le même nom. Cela se produit quand des formes courte de noms d'hôte pour différents domaines sont placés dans le fichier. Il est possible que les fichiers contenant des informations en conflit acceptent l'authentification si l'information valide peut être trouvée dans le fichier.

Exemple de fichier ssh_known_hosts:
# Comments allowed at start of line
closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# A hashed hostname
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# A revoked key
@revoked addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo ssh-rsa AAAAB5W...
# A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

Fichiers

~/hushlogin Supprime l'affichage de la date de dernière connexion et /etc/motd
~/.rhosts Utilisé pour l'authentification basé sur l'hôte
~/.shosts idem .rhosts, mais sans login permit avec rlogin/rsh
~/.ssh/ Répertoire de configuration par défaut pour le utilisateurs
~/.ssh/authorized_keys Liste des clés publiques qui peuvent être utilisé pour se connecter avec cet utilisateur.
~/.ssh/environment Ce fichier est lu dans l'environnement au login
~/.ssh/known_hosts Contient une liste de clés hôte pour tous les hôtes sur lesquels l'utilisateur s'est connecté
~/.ssh/rc Exécuté par ssh quand l'utilisateur se logs, juste avant de lancer le shell ou la commande
/etc/hosts.equiv Fichier pour l'authentification basé sur l'hôte. doit être writable par root uniquement
/etc/shosts.equiv idem sans autoriser rlogin/rsh
/etc/moduli Contient les groupes Diffie-Hellman utilisé pour l'échange de clé DH.
/etc/motd Message Of The Day
/etc/nologin Si ce fichier existe, sshd refuse la connexion excepté pour root
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key Contient la clé privée de l'hôte
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub Contient la partie publique de la clé de l'hôte
/etc/ssh/ssh_known_hosts Fichier système listant les clé hôte connues
/etc/ssh/sshd_config Fichier de configuration pour sshd
/etc/ssh/sshrc Similaire à ~/.ssh/rc
/var/empty Répertoire chroot utilisé par sshd durant la séparation de privilège dans la phase de préauthentification. Ce répertoire ne devrait pas contenir de fichiers et doit être possédé par root.
/var/run/sshd.pid fichier pid du processus sshd.
^
15 juin 2017

htmlpdflatexmanmd




sshd_config

sshd_config

Fichier de configuration pour sshd

AcceptEnv Spécifie quelles variables d'environnement envoyées par le client sont copiées dans l'environnement de la session. Voir SendEnv dans ssh_config
AddressFamily any|inet|inet6 Spécifie quelles familles d'adresse sont utilisés par sshd
AllowAgentForwarding yes|no Spécifie si le forwarding ssh-agent est permis. Noter que le désactiver n'améliore pas la sécurité sauf si les utilisateur se voient refuser un accès shell, vu qu'ils peuvent installer leur propre forwarders.
AllowGroups Liste de pattern de nom de groupe autorisé à se connecter
AllowStreamLocalForwardings yes|all|no|local|remote Spécifie si le forwarding StreamLocal (socket Unix) est permis
AllowTcpForwarding yes|all|no|local|remote Spécifie si le forwarding TCP est permis
AlowUsers Liste de noms d'utilisateurs autorisés à se connecter
AuthenticationMethods Spécifie les méthodes d'authentification qui doit être complétée pour autoriser l'accès à un utilisateur. 'any' indique toutes les méthodes.
AuthorizedKeysCommand Spécifie un programme à utiliser pour rechercher les clés publique de l'utilisateur. Le programme doit être possédé par root, pas en écriture pour le groupe et les autres. Le programme doit sortir 0 ou plusieurs ligne au format authorized_keys.
AuthorizedKeysCommandUser Spécifie l'utilisateur sous lequel AuthorizedKeysCommand est lancé.
AuthorizedKeysFile Spécifie le fichier qui contient les clés publique utilisées pour l'authentification utilisateur.
AuthorizedPrincipalsCommand Spécifie un programe à utiliser pour générer une liste de principaux.
AuthorizedPrincipalsCommandUser Spécifie l'utilisateur sous lequel la commande AuthorizedPrincipalsCommand est lancée
AuthorizedPrincipalsFile Spécifie un fichier qui liste les noms principaux qui sont acceptés pour l'authentification par certificat.
Banner Le contenu de ce fichier est affiché à l'utilisateur avant l'authentification.
ChallengeResponseAuthentication yes|no Spécifie si l'authentification par challenge/réponse est authorisée
ChrootDirectory Spécifie le chemin d'un répertoire pour chroot après l'authentification.
Ciphers Liste des chiffrements permis.
ClientAliveCountMax Définis le nombre de messages alive client qui peuvent être envoyés sans reçevoir de réponse du client. Si ce seuil est atteint, le client est déconnecté.
ClientAliveInterval timeout en secondes après lequel si aucune données n'a été reçue du client, sshd envoie un message alive. 0 = désactivé
Compression yes|no Spécifie si la compression est autorisé une fois l'authentification réussie.
DenyGroups Liste de groupes autorisés à se connecter
DenyUsers Liste d'utilisateurs non autorisés à se connecter
DisableForwarding Désactive toutes les fonctionnalités de forwarding
FingerprintHash md5|sha1256 Spécifie l'algorithme de hashage utilisé pour les empreintes de clé le login
ForceCommand Force l'exécution de la commande spécifié, ignorant toute commande fournie par le client et ~/.ssh/rc.
GatewayPorts yes|no|clientspecified Spécifie si les hôte distant sont autorisés à se connecter aux port forwardés pour le client.
GSSAPIAuthentication yes|no Spécifie si l'authentification basée sur GSSAPI est permis
GSSAPICleanupCredentials yes|no Spécifie si le cache d'accréditifs utilisateurs est automatiquement détruit à la déconnexion
GSSAPIStrictAcceptorCheck yes|no Détermine si l'acceptation de l'identité GSSAPI est stricte.
HostbasedAcceptedKeyTypes Spcifie les types de clé acceptés pour l'authentification basé sur l'hôte.
HostbasedAuthentication yes|no Spécifie si l'authentification rhosts ou /etc/hosts.equiv avec la clé publique cliente est permise
HostbasedUsesNameFromPacketOnly Spéifie si le serveur tente d'effectuer une recherche inversée en matchant les noms dans ~/.shosts, ~/.rhosts et /etc/hosts.equiv.
HostCertificate Spécifie un fichier contenant un certificat hôte publique.
HostKey Spécifie un fichier contenant une clé privée hôte.
HostKeyAgent Identifie le socket Unix utilisé pour communiquer avec un agent que a accès aux clés privées
HostKeyAlgorithms Spécifie les algorithmes de clé hôte que le serveur offre.
IgnoreRhosts yes|no Spécifie que les fichiers .rhosts, et .shosts ne sont pas utilisé dans HostbasedAuthentication
IgnoreUserKnownHosts yes|no Spécifie si sshd doit ignorer le fichier ~/.ssh/known_hosts de l'utilisateur durant HostbasedAuthentication.
IPQoS Spécifie le type de service IPv4 ou la classe DSCP pour les connexions. aff11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay, throughput, reliability, ou une valeur numérique.
KbdInteractiveAuthentication yes|no Utilise l'authentification interactive au clavier.
KerberosAuthentication yes|no Spécifie si le mot de passe fournis par l'utilisateur pour PasswordAuthentication est validé auprès du KDC.
KerberosGetAFTToken yes|no Si AFS est actif et l'utilisateur a un TGT, tente d'acquérir un jeton AFS avant d'accéder au répertoire home.
KerberosOrLocalPasswd yes|no Si l'authentification kerberos échoue, le mot de passe est validé avec un mécanisme local.
KerberosTicketCleanup yes|no Spécifie si le cache de ticket de l'utilisateur est automatiquement détruit à la déconnexion.
KeyAlgorithms Spécifie les algorithmes d'échange de clé permis.
ListenAddress Spécifie les adresses locales d'écoute
LoginGraceTime Délay au delà duquel le serveur déconnecte si l'utilisateur n'a pas réussi la connexion. 0 = pas de limite.
LogLevel Niveau de verbosité des logs. QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3.
MACs Spécifie les algorithmes MAC dans l'ordre de préférence
Match Introdui un block conditionnel. Si tous les critères sont satisfaut, les mots clés suivant remplacent la section globale. Les critèrse sont User, Group, Host, LocalAddress, LocalPort, et Address. Les mots clés suivants sont permis après un match: AcceptEnv, AllowAgentForwarding, AllowGroups, AllowStreamLocalForwarding, AllowTcpForwarding, AllowUsers, AuthenticationMethods, AuthorizedKeysCommand, AuthorizedKeysCommandUser, AuthorizedKeysFile, AuthorizedPrincipalsCommand, AuthorizedPrincipalsCommandUser, AuthorizedPrincipalsFile, Banner, ChrootDirectory, ClientAliveCountMax, ClientAliveInterval, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAcceptedKeyTypes, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, IPQoS, KbdInteractiveAuthentication, KerberosAuthentication, LogLevel, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC, PubkeyAcceptedKeyTypes, PubkeyAuthentication, RekeyLimit, RevokedKeys, StreamLocalBindMask, StreamLocalBindUnlink, TrustedUserCAKeys, X11DisplayOffset, X11Forwarding et X11UseLocalHost.
MaxAuthTries Spécifie le nombre maximum de tentatives d'authentification permise par connexion. Une fois ce nombre atteint, des erreurs additionnels sont loggés.
MaxSessions Nombre de shell, login, ou de sessions sous-système (ex sftp) par connexion réseaux Plusieurs sessions peuvent être établies par les clients qui supportent le multiplexage de connexion. 1 = désactive le multiplexage, 0 = empêche toute session.
MaxStartups Nombre de connexions non-authentifiée concurrentes permises. Alternativement, un format "start:rate:full" va refuser les tentatives de connexion avec un aux de rate/100, s'il y a start connections non-authentifiées concurrentes. La probabilité augmente de manière linéaire et toutes les tentatives de connexion sont refusés si le nombre de connexions non-authentifiées atteint 'full' (Défaut: 10:30:100)
PasswordAuthentication yes|no Spécifie si l'authentification par mot de passe est permise
PermitEmptyPasswords yes|no Quand l'authentification par mot de passe est permis, spécifie si le serveur autorise le login aux comptes sans mot de passe.
PermitOpen [hostname|IP]:port [...] Spécifie les destinations pour lesquels le port forwarding TCP est permis. 'any' supprime toute restriction.
PermitRootLogin yes|prohibit-password|without-password|forced-commands-only|no prohibit-password ou without-password, l'authentification par mot de passe et au clavier sont désactivés. À forced-commands-only, la connexion root avec clé publique est autorisées mais seulement si l'option command a été spécifiée.
PermitTTH yes|no Spécifie si l'allocation pty est permise
PermitTunnel yes|point-to-point|ethernet|no Spécifie si le forwarding de périphérique tun est permis
PermitUserEnvironment yes|no Spécifie si ~/.ssh/environment dans dans le fichier ~/.ssh/authorized_keys sont traités par sshd.
PermitUserRC yes|no Spécifie si le fichier ~/.ssh/rc est exécuté
PidFile Fichier pid du service, on 'none' pour désactiver l'écriture de ce fichier
Port Spécifie le numéro de port d'écoute de sshd. Défaut: 22. Peut être spécifié plusieurs fois
PrintLastLog yes|no Spécifi si sshd affiche la date de dernière connexion de l'utilisateur
PrintMotd yes|no Spécifie si sshd doit afficher /etc/motd quand l'utilisateur se log.
PubkeyAcceptedKeyTypes Spécifie les types de clé acceptés pour l'authentification à clé publique
PubkeyAuthentication Spécifie si l'authentification par clé publique est permise
RekeyLimit Quantité maximum d-e données transmises avant que la clé de session soit renégociée, optionnellement avec un suffix 'K', 'M', ou 'G'.
RevokedKeys Spécifie le fichier de clés révoquées
StreamLocalBindMask umask de création de fichier utilisé en créant le socket unix. Défaut: 0177.
StreamLocalBindUnlink yes|no Spécifie si un fichier socket unix existant doit être supprimé avant d'en créer un nouveau.
StrictModes yes|no Vérifie les permissions et propriétaire des fichiers utilisateur et répertoire home avant d'accepter la connexion
Subsystem Configure un sous-système externe (ex: sftp)
SyslogFacility DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
TCPKeepAlive yes|no Spécifie si le système envoie des messages TCP keepalive.
TrustedUserCAKeys Spécifie un fichier contenant les clé publiques d'autorité de certification utilisés pour signer les certificats utilisateurs
UseDNS yes|no Recherche les noms d'hôte distants via DNS.
VersionAddendum Spécifie un texte additionnel à ajouter au protocole Banner envoyé par le serveur.
X11DisplayOffset Spécifie le premier affichage disponible pour le forwarding X11.
X11Forwarding yes|no Autorise le forwarding X11
X11UseLocalHost yes|no Spécifie si sshd lie le forwarding X11 à l'adresse de boucle locale ou l'adresse wildcard.
XAuthLocation Chemin complet du programme xauth

Formats de temps

   Les options qui s'expriment sous la forme 'time[qualifier], ou time est un entier positif, et qualifier est:

        (none) secondes
        s|S secondes
        m|M minutes
        h|H Heures
        d|D jours
        w|W Semaines

Jetons

   Les arguments de certains mots clé peuvent utilise des jetons, étendus comme suit:

%% le caractère %
%F l'enpreinte de la clé CA
%f l'empreinte de la clé ou du certificat
%h Répertoire personnel de l'utilisateur
%I ID de clé dans le certificat
%K Clé CA base64
%k clé ou certificat base64 pour l'authentification
%s Numéro de série du certificat
%T Type de clé CA
%t Type de clé ou certifiat
%u Nom de l'utilisateur

   Les mots clés qui accèptent les jetons sont:

AuthorizedKeysCommand %%, %f, %h, %k, %t, %u
AuthorizedKeysFile %%, %h, %u.
AuthorizedPrincipalsCommand %%, %F, %f, %h, %i, %K, %k, %s, %T, %t, %u.
AuthorizedPrincipalsFile %%, %h, %u.
ChrootDirectory %%, %h, %u.
^
15 juin 2017

htmlpdflatexmanmd




ssh_config

ssh_config

Fichier de configuration pour ssh

   ssh obtient sa configuration depuis les sources suivantes, dans l'ordre:

        1. Options de ligne de commande
        2. fichier de configuration utilisateur
        3. Fichier de configuration du système

   Pour chaque paramètre, la première valeur obtenue est utilisée. Les fichiers de configuration contiennent des sections séparés par des spécifications Host, qui ne s'appliquent qu'aux hôte qui matchent un des patterns donnés dans la spécification.

OPTIONS

Host Restreint les déclarations suivantes aux hôtes qui matchent le motif donné. '*' peut être utilisé comme section par défaut. '!' peut être utilisé pour inverser le match.
Match Restreint les déclarations suivantes seulement quand les conditions spécifiées sont satisfaites:

        canonical matche seulement quand le fichier de configuration est reparcouru après la canonisation du nom d'hôte (voir l'option CanonicalizeHostname).
        exec Exécute la commande spécifié dans le shell de l'utilisateur. Si la commande retourne un code de sortie 0, la condition est vrai
        host Les critères sont matchés avec le nom d'hôte de la cible, après substitution par les options Hostname ou CanonicalizeHostname
        originalhost Matche avec le nom d'hôte tel que spécifié sur la ligne de comande.
        user Matche le nom d'utilisateur cible dans l'hôte distante
        localuser Matche e nom de l'utilisateur local qui lance ssh
        all Match tout

AddKeysToAgent yes|ask|confirm|no Spécifie si le clés devraient être automatiquement ajoutés à un ssh-agent en cours de fonctionnement. Si cette option est à yes, et qu'une clé est chargée depuis un fichier, la clé et sa passphrase sont ajoutés à l'agent avec la durée de vie par défaut, comme avec ssh-add. Si cette option est à ask, ssh demande confirmation en utilisant le programme SSH_ASKPASS. à confirm, chaque utilisation de la clé doit être confirmée. à no, aucune clé n'est ajoutée
AddressFamily any|inet|inet6 Spécifie quelle famille d'adresse utiliser pour la connexion
BatchMode yes|no à yes, la demande de mot de passe est désactivée
BindAddress Utilise l'adresse spécifié dans la machine locale comme adresse sources de la connexion. Ne fonctionne pas si UsePrivilegedPort est à yes
CanonicalDomains Activé, spécifie la liste de suffixes de domaines dans lequel rechercher l'hôte de destination
CanonicalizeFallbackLocal yes|no à yes, tente de rechercher le nom d'hôte non qualifié en utilisant les règles de recherche du résolveur. à no, ssh échoue immédiatement si CanonicalizeHostname est activé et que la cible n'est pas trouvé dans les domaines spécifiés par CanonicalDomains
CanonicalizeHostname yes|no Effectue une canonicalisation de nom d'hôte. à no, laisse le résolver rechercher les noms d'hôte, à yes, pour les connexion qui n'utilisent pas ProxyCommand, ssh tente de canoniser le nom d'hôte.
CanonicalizeMaxDots Nombre de points maximum dans le nom d'hôte avant de désactiver la canonicalisation.
CertificateFile Spécifie le certificat de l'utilisateur
ChallengeResponseAuthentication yes|no Active l'authentification challenge-response
CheckHostIP yes|no à yes, effectue une vérification additionnelle de l'adresse IP dans le fichier known_hosts. Permet de détecter si une clé hôte a changé dû à un DNS spoofing
Ciphers Spécifie les chiffrements permet, dans l'ordre de préférence (ssh -Q cipher pour obtenir une liste de chiffrements disponibles)
ClearAllForwardings yes|no Spécifie que tous les ports forwarding local, distant et dynamique spécifiés sont effacés. Utile pour scp et sftp qui les définissent automatiquement.
Compression yes|no Utilise la compression
ConnectionAttempts Nombre de tentatives (1 par secondes) avant de quitter. Défaut: 1
ConnectTimeout Spécifie le timeout en secondes utilisé pour se connecter au serveur ssh, au lieu d'utiliser le timeout TCP du système. Cette valeur est utilisé quand la cible est indisponible, pas quand elle refuse la connexion
ControlMaster yes|no|ask|autoask Active le partage de plusieurs sessions dans une seule connexion réseaux. à yes, ssh écoute les connexions dans un socket de contrôle ControlPath
ControlPath Spécifie le socket contrôle utilisé pour le partage de connexion
ControlPersist yes|no Spécifie que la connexion master de rester en tâche de fond pour de future connexions client, après que la connexion cliente initiale a été fermée
DynamicForward [bind_address:]port Spécifie qu'un port TCP dans la machine locale est forwardée dans le canal sécurisé, et le protocole d'application est ainsi utilisé pour déterminer où se connecter depuis la machine distante
EnableSSHKeySign yes|no à yes, active l'utilisation de ssh-keysign durant HostbaseddAuthentication
EscapeChar Définis le caractère d'échappement (défaut: ~)
ExitOnForwardFailure yes|no Indique si ssh termine la connexion s'il ne peut pas définir les ports forwardings dynamique, local, tunnel, et distant
FingerprintHash md5|sha256 Spécifie l'algorithme de hashage utilisé pour afficher les empreintes de clé
ForwardAgent yes|no Spécifie si la connexion à l'agent d'authentification est forwardée à la machine distante.
ForwardX11 yes|no Spécifie si les connexions X11 sont automatiquement redirigés dans la canal sécurisé.
ForwardX11Timeout timeout pour le forwarding X11 utilisant le format de temps. Les connexions après ce délai sont refusés
ForwardX11Trusted yes|no à yes, les clients X11 distants ont un accès complet à l'affichage X11 original. à no, les clients sont considérés comme non-sûres et bloqués pour éviter le vol ou la falsification des données des clients X11 de confiance.
GatewayPorts yes|no Spécifie si les hôtes distant sont autorisés à se connecter aux ports forwardés locaux. par défaut, ces ports sont liés à l'adresse de bouclage. Cela empêche d'autres hôtes de se connecter aux ports forwardés. Cette option peut être utilisée pour spécifier que ssh lie le port forwarding à l'adresse wildcard.
GlobalKnownHostsFile Spécifie un ou plusieurs fichiers à utiliser pour la base de clé hôte globale, séparé par ' '. Défaut: /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2
GSSAPIAuthentication yes|no Spécifie si l'authentification basée sur GSSAPI est permise
GSSAPIDelegateCredentials yes|no Forward les accréditifs au serveur
HashKnownHosts yes|no Indique que ssh doit hasher les noms d'hôte et les adresses quand elles sont ajoutées à ~/.ssh/known_hosts.
HostbasedAuthentication yes|no Spécifie si l'authentification à clé publique basée sur l'hôte est permise
HostbasedKeyTypes Spécifie la liste des types de clé qui sont utilisé pour l'authentification basé sur l'hôte.
HostKeyAlgorithms Spécifie les algorithmes de clé hôte à utiliser par le client, dans l'ordre de préférence.
HostKeyAlias Spécifie un alias qui doit être utilisé à la place du vrai nom d'hôte en recherchant ou en sauvegardant la clé hôte dans les fichiers de base de clé hôte.
HostName Spécifie le nom d'hôte réel de connexion. Défaut: le nom spécifié sur la ligne de commande
IdentitiesOnly yes|no Spécifie que ssh devrait seulement utiliser l'identité d'authentification et les fichiers de certificat explicitement configurés dans ssh_config ou passés sur la ligne de commande, même si ssh-agent ou un PKCS11Provider offfre plus d'identitiés.
IdentityAgent Spécifie le socket unix utilisé pour communiquer avec l'agent d'authentification
IdentityFile Spécifie un fichier depuis lequel l'identité d'authentification DSA, ECDSA, Ed25519, ou RSA de l'utilisation est lu. Défaut: ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519, ~/.sdsh/id_rsa.
IgnoreUnknown Spécifie une liste de motifs d'options inconnue à ignorer s'ils sont rencontrés dans la configuration
Include Inclus les fichiers de configuration spécifiés. Plusieurs fichiers peuvent être spécifié et peuvent contenir un wildcard
IPQoS Spécifie le type de service IPv4 ou la classe DSCP pour les connexions. aff11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay, throughput, reliability, ou une valeur numérique.
KbdInteractiveAuthentication yes|no Utilise l'authentification interactive au clavier.
KbdInteractiveDevices Spécifie la liste des méthodes à utiliser dans l'authentification interactive.
KexAlgorithms Spécifie les algorithmes d'échange de clé permis
LocalCommand Spécifie une commande à exécuter dans la machine locale après s'être connecté au serveur.
LocalForward [bind_address:]port Spécifie qu'un port TCP dans la machine local est forwardé via le canal sécurisé vers l'hôte:port distant. Seul root peut forwarder des ports privilégiés Par défaut, le port local est lié en accord avec GatewayPorts, si bind_address n'est pas spécifié
LogLevel Niveau de verbosité des logs. QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3.
MACs Spécifie les algorithmes MAC dans l'ordre de préférence
NoHostAuthenticationForLocalhost yes|no Peut être utilisé si le répertoire hôte est partagé. Dans ce cas localhost réfère à une machine différente dans chaque machine et l'utilisateur a des alerts sur les clés d'hôte changés. Cette option désactive l'authentification pour localhost.
NumberOfPasswordPrompts Spécifie le nombre de demande de mot de passe maximume. Défaut: 3
PasswordAuthentication yes|no Indique si l'authentification par mot de passe est permise.
PermitLocalCommand yes|no Autorise l'exécution de commande locale via l'option LocalCommand
PKCS11Provider Spécifie le fournisseur PKCS#11 à utiliser.
Port Spécifie le port de connexion. Défaut: 22
PreferredAuthentications Spécifie l'ordre des méthodes d'authentification
ProxyCommand Spécifie la commande à utiliser pour se connecter au serveur. La chaîne s'étend à la fin de la ligne et est exécuté en utiisant exec
ProxyJump Spécifie un ou plusieurs sauts proxy. Plusieurs proxy peuvent être spécifié, et sont visités séquentiellement. Noter que cette option est en concurrence avec ProxyCommand, c'est le premier spécifié qui est utilisé
ProxyUseFdpass yes|no Spécifie que ProxyCommand passe un descripteur de fichier connecté à ssh au lieu de continuer à exécuter et passe des données.
PubkeyAcceptedKeyTypes Spécifie les types de clé utilisés pour l'authentification à clé publique
PubkeyAuthentication yes|no Indique si l'authentification à clé publique est permise
RekeyLimit Spécifie la quantité maximum de données qui peuvent être transmis avant que la clé de session soit renégociée, optionnellement suivant par un délay. La taille peut être préfixé(K, M, G), le délay utilise le format de temps.
RemoteCommand Spécifie une commande à exécuter dans la machine distante une foi connecté au serveur. La chaîne s'étend à la fin de la ligne, et est exécuté avec le shell de l'utilisateur.
RemoteForward [bind_address:]port Spécifie qu'un port TCP dans la machine distante est forwardée dans le canal sécurisé à l'hôte:port dans la machine locale.
RequestTTY yes|auto|force|no Demande un pseudo-tty pour la session.
RevokedHostKeys Spécifie le clés publiques révoquées. Les clés listées dans ce fichier seront refusés pour l'authentification de l'hôte. Ce fichier peut être un fichier texte listant une clé publique par ligne, ou comme une liste de révocation de clé OpenSSH, tel que généré pa ssh-keygen.
SendEnv Spécifie quelles variables de l'environnement local sont envoyés au serveur. Le serveur doit également le supporter et doit les accepter Noter que TERM est toujours envoyé. Voir AcceptEnv dans sshd_config
ServerAliveCountMax Définis le nombre de message alive serveur qui peuvent être envoyés sans que ssh ne reçoive de réponse du serveur, terminant la session. Il est important de noter que ces messages sont différents de TCPKeepAlive, qui est spoofable. Défaut: 3
ServerAliveInterval Intervalle en secondes sans avoir reçu de données avant d'envoyer une requête au serveur. Défaut: 0 (désactivé)
StreamLocalBindMask umask utilisé en créant le socket unix. Utilisé uniquement pour le port forwarding vers un socket unix. Défaut: 0177
StreamLocalBindUnlink yes|no Spécifie si le socket unix est supprimé avant d'en créer un nouveaux.
StrictHostKeyChecking yes|ask|no à yes, ssh n'ajoute jamais automatiquement les clés hôte dans ~/.ssh/known_hosts, et refuse de se connecter si la clé hôte a changé.
SyslogFacility DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
TCPKeepAlive yes|no Spécifie si le système envoie des tcp keepalive.
Tunnel yes|point-to-point|ethernet|no Demande un périphérique tun entre le client et le serveur.
TunnelDevice local_tun[:remote_tun] Spécifie le périphérique tun à ouvrir. Les périphériques peuvent être spécifiés par ID ou le mot clé any qui utiliser le premier périphérique disponible
UpdateHostKeys yes|no|ask Spécifie si ssh accepte les notification de clé hôtes additionnels du serveur une fois l'authentification réussie et le ajoute à UserKnownHostsFile.
UsePrivilegedPort yes|no Spécifie l'utilisation d'un port privilégié pour les connexions sortantes. ssh doit être setuid root
User Spécifie l'utilisateur pour la connexion
UserKnownHostsFile Spécifie un ou plusieurs fichiers à utiliser pour la base de clé d'hôte utilisateur. Défaut: "~/.ssh/known_hosts ~/.ssh/known_hosts2"
VerifyHostKeyDNS yes|no|ask Indique si la clé distante est vérifié en utilisant DNS et les enregistrement SSHFP.
VisualHostKey yes|no À yes, une réprésentation ASCII de l'empreinte de la clé distante est affichée au login pour les clés hôte inconnues.
XAuthLocation Chemin du programme xauth. Défaut: /usr/X11R6/bin/xauth

Motifs

   Un pattern consiste de 0 ou plusieurs caractères non-blanc '*' ou '?'. Par exemple, pour spécifier un jeu de déclarations pour un hôte dans le domaine .co.uk:

  Host *.co.uk

  Pour matcher un hôte dans le réseau 192.168.0.[0-9]:

  Host 192.168.0.?

  Un pattern-list est une liste de patterns. les patterns peuvent être inversé avec '!'. Par exemple, pour autoriser une clé excepté depuis le pool dialup, l'entrée suivante dans authorized_keys:

  from="!*.dialup.example.com,*.example.com"

Jetons

   Les arguments de certains mots clé peuvent utilise des jetons, étendus comme suit:

%% le caractère %
%C Raccourcis pour %I%h%p%r
%d home de l'utilisateur
%h Nom de l'hôte distant
%I UID local
%L Nom de l'hôte local
%I FQDN de l'hôte local
%n Nom de l'hôte distant, tel que donné sur la ligne de commande
%p Le port distant
%r Nom de l'utilisateur distant
%u Nom de l'utilisateur local

   Les mots clés qui accèptent les jetons sont:

jetons permis

Match exec %%, %h, %L, %l, %n, %p, %r, %u.
CertificateFile %%, %d, %h, %l, %r, %u.
ControlPath %%, %C, %h, %i, %L, %l, %n, %p, %r, %u.
HostName %%, %h.
IdentityAgent
IdentityFile %%, %d, %h, %l, %r, %u.
LocalCommand %%, %C, %d, %h, %l, %n, %p, %r, %u.
ProxyCommand %%, %h, %p, %r.
RemoteCommand %%, %C, %d, %h, %l, %n, %p, %r, %u.

fichiers

~/.ssh/config Fichier de configuration de l'utilisateur. Ce fichier doit avoir les permissions suivantes: rw pour l'utilisateur, aucun pour les autres.
/etc/ssh/ssh_config Fichier de configuration système.
^
01 janvier 2014

htmlpdflatexmanmd




startkde

startkde

Script pour lancer KDE, généralement lancé par le gestionnaire de connexion.

   Il lance en retour ksmserver, qui démarre la dernière session, ou une session par défaut. Il utilise ~/.kde pour démarrer les sessions précédemment sauvegardées. Les scripts dans ~/.kde/env/*.sh peuvent être utilisés pour définir des variables d'environnement qui seront disponible pour tous les programmes KDE. Pour tout le reste, utiliser ~/.kde/Autostart/. À la fin de la session, ~/.kde/shutdown/ sera exécuté

^
04 juillet 2010

htmlpdflatexmanmd




stat

stat

Affiche des informations sur les fichiers spécifiés

   Sans options, stat reporte toutes les informations sur le fichier donné. Il peut aussi être utilisé pour afficher des informations sur le système de fichier où se trouve le fichier. Si les fichiers sont des liens, stat peut aussi donner des informations sur les fichiers pointés.

OPTIONS

-L, --dereference Agit sur la référence des liens et non sur les lien eux-même.
-f, --file-system affiche des informations sur le système de fichier où se trouve le fichier au lieu des informations sur le fichier.
-c, --format=FORMAT utilise FORMAT au lieu du format par défaut. FORMAT est automatique terminé par un newline. ex stat --format=%d :%i affiche 2050:2
--printf=FORMAT idem, mais interprète '\' et ne rajoute pas de newline à la fin (ou \n)
-t, --terse affiche des informations brut pour être utilisé par d'autres programmes.

Directives de FORMAT

%a droits d'accès en octal
%A droits d'accès suffixé
%b nombre de block alloué
%B la taille en octet de chque block reporté par %b
%d Device number en décimal
%D device number en hexa
%f raw mode en hexa
%F type de fichier
%g GID
%G groupname
%h nombre de liens durs
%i numéro d'inode
%n nom du fichier
%N nom entre "'" avec déréférence si lien symbolique
%o taille de block I/O
%s taille total en ocets
%t Major device type en hexa
%T Minor device type en hexa
%u UID
%U username
%x atime
%X atime en sec
%y mtime
%Y mtime en sec
%z ctime
%Z ctime en sec

   En listant les informations sur le système de fichier FORMAT peut prendre:

%a block disponible aux non-root
%b blocks de données total dans le système de fichier.
%c noeud de fichier total dans le système de fichier.
%d noeud de fichier libres dans le système de fichier
%f block disponibles dans le système de fichier
%i ID du système de fichier en hexa
%l longueur maximum dans les noms de fichiers.
%n noms de fichier.
%s taille de block (pour la rapidité des transferts)
%S tailles de block fondamental (pour le compteur de block)
%t type en hexa
%T type
^
11 février 2015

htmlpdflatexmanmd




stonithd

stonithd

Options disponibles pour les ressources stonith

OPTIONS

stonith−timeout = time [60s] Délai d'attente pour que l'action stonith se termine par périphérique stonith
priority = integer [0] La priorité de la ressource stonith. Les périphériques sont tentés dans l'ordre de priorité la plus haut à la plus faible.
pcmk_host_argument = string [port] Paramètre alternatif pour fournir le port.
pcmk_host_map = string [] Un mappage de noms d'hôtes vers des numéro de port pour les périphériques qui ne supportent pas les noms d'hôte (ex: node1:1,node2:2,3)
pcmk_host_list = string [] Une liste de machines contrôlées par ce périphérique
pcmk_host_check = string [dynamic−list] Comment déterminer quelle machine sont contrôlées par ce périphérique (dynamic-list, static-list, none)
pcmk_reboot_action = string [reboot] Commande alternative à lancer au lieu de reboot
pcmk_reboot_timeout = time [60s] Délai alternatif à utiliser pour les action de reboot au lieu de stonith-timeout.
pcmk_reboot_retries = integer [2] Nombre maximum de tentative de reboot dans la période timeout
pcmk_off_action = string [off] Commande alternative à lancer au lieu de off
pcmk_off_timeout = time [60s] délai alternatif pour les actions off
pcmk_off_retries = integer [2] Nombre de tentatives de la commande off dans la période timeout
pcmk_list_action = string [list] Commande alternative à lancer au lieu de 'list'
pcmk_list_timeout = time [60s] délai alternatif pour la commande list
pcmk_list_retries = integer [2] Nombre de tentatives de la commande list dans la période timeout
pcmk_monitor_action = string [monitor] Commande alternative à la commande monitor
pcmk_monitor_timeout = time [60s] délai alternatif pour la commande monitor
pcmk_monitor_retries = integer [2] Nombre de tentatives de la commande monitor dans la période timeout
pcmk_status_action = string [status] Commande alternative à la commande status
pcmk_status_timeout = time [60s] délai alternatif pour la commande status
pcmk_status_retries = integer [2] Nombre de tentatives de la commande status dans la période timeout
^
08 février 2015

htmlpdflatexmanmd




stonith_admin

stonith_admin

Permet d'ajouter/supprimer/lister/vérifier les périphériques et le status des hôtes.

OPTIONS

-V, --verbose Augmente la verbosité
-q, --quiet mode silencieux

Commandes

-l, --list=value Liste les périphériques qui peuvent terminer l'hôte spécifié
-L, --list-registered Liste tous les périphériques enregistrés
-I, --list-installed Liste les périphériques installés
-M, --metadata Vérifie les méta-données du périphérique
-Q, --query=value Vérifie le status du périphérique
-F, --fence=value Enlève l'hôte nommé
-U, --unfence=value Remet l'hôte nommé
-B, --reboot=value Reboot l'hôte nommé
-C, --confirm=value Confirme que l'hôte nommé s'est arrête proprement
-H, --history=value Récupère les opérations de fencing
-R, --register=value Enregistre le périphérique stonith nommé
-D, --deregister=value Dé-enregistre le périphérique stonith nommé
-r, --register-level=value Enregistre un niveau stonith pour l'hôte nommé.
-d, --deregister-level=value Dé-enregistre un niveau stonith pour l'hôte nommé.

Options et modifiers

-a, --agent=value L'agent à instancier avec --register (ex fence_xvm)
-e, --env-option=value
-o, --options=value
-v, --device=value Un périphérique à associer avec un hôte donné et un niveau stonith
-i, --index=value Le niveau stonith (1-9)
-t, --timeout=value Timeout d'opération en seconde
--tolerance=value Ne fait rien si une requête équivalente à --fence a réussis moins de N secondes plus tôt.
-L, --list-all Alias pour --list-registered
^
12 juillet 2010

htmlpdflatexmanmd




stty

stty

Affiche ou change les caractéristiques du terminal

   Sans argument, affiche le baud rate, le line discipline number, et les paramètres de ligne. Par défaut, le mode de lecture et les paramètres sont effectués sur la ligne tty connecté sur l'entrée standard, mais peut être modifié avec --file

OPTIONS

-a, --all Affiche tous les paramètres courant sous forme compréhensible. Cette option ne peut pas être utilisée avec un paramètre de ligne
-F device, --file=device Définit la ligne ouverte par le nom de fichier au lieu de la ligne connecté sur l'entrée standard
-g, --save Affiche tous les paramètres courant sous une forme qui peut être utilisé en arguments à une autre commande stty pour restaurer les paramètres courant

   Beaucoup de paramètres peuvent être désactivés en le précédent par un "-". Certains paramètres ne sont pas disponibles sur tous les systèmes POSIX, vu qu'ils utilisent des extensions.

Paramètres de contrôle

parenb génère un bit de parité en sortie et attend un bit de parité en entrée.
parodd définit un parité impaire ( même si désactivé)
cs5, cs6, cs7, cs8 Définis la taille de caractère à 5, 6, 7 ou 8 bits
hup, hupcl envoie un signal hangup quand le dernier processus ferme le tty.
cstopb Utilise 2 bits de stop par caractères (un seul si désactivé)
cread autorise de recevoire en entrée.
clocal désactive les signaux de controle de modem.
crtscts Autorise le contrôle de flux RTS/CTS . Non-POSIX

Paramètres d'entrée

   Ces paramètres contrôlent les opérations sur les données reçues depuis le terminal

ignbrk Ignore les caractères break.
brkint Les breaks génère un signal d'interruption.
ignpar Ignore les caractères avec des erreurs de parité
parmrk marque les erreurs de parité (avec une sequence de caractère 255-0)
inpck active le contrôle de parité en entrée.
istrip efface le bit de poid fort des caractères en entrée.
inlcr traduit les newline en retour charriot
igncr ignore les retour charriot
icrnl traduit les retour charriot en newline
iutf8 Assume que les caractères en entrées sont codés en UTF8
ixoff, ixon active le contrôle de flux XON/XOFF (CTRL-S, CRTL-Q)
tandem Active l'envoie du caractère stop quand le buffer d'entrée est plein et le caractère start quand il s'est vidé.
iuclc Traduit les caractères majuscule en minuscule. Non-POSIX
ixany Permet à un caractère de redémarrer la sortie (seulement le caractère start si désactive) Non-POSIX
imaxbel Active le beeping et ne vide pas le tampon d'entrée si un caractère arrive quand le buffer d'entrée est plein. Non-POSIX

Paramètres de sortie

opost post traitement de la sortie
olcuc Traduit les caractère minuscule en majuscule. Non-POSIX
ocrnl Traduit les newlien en retour charriot + newline. Non-POSIX
onocr N'affiche par de retour charriot dans la première colonne. Non-POSIX
onlret Newline effectue un retour charriot. Non-POSIX
ofill Utilise les caractères de remplissage au lieu de timer les délays.
ofdel Utilise les caractères ASCII DEL pour remplir au lieu des caractères ADCII NUL
nl1, nl0 style de délai newline. Non-POSIX
cr3, cr2, cr1, cr0 Retour style de délai charriot Non-POSIX
tab3, tab2, tab1, tab0 style de délai tabulation horizontal. Non-POSIX
bs1, bs0 style de déali backspace. Non-POSIX
vt1, vt0 Style de délai tabulation vertical. Non-POSIX
ff1, ff0 Form feed delay style. Non-POSIX

Paramètres locaux

isig Autorise les caractères spéciaux 'interrupt', 'quit' et 'suspend'.
icanon autorise les caractères 'erase', 'kill', 'werase' et 'print'
iexten Autorise les caractères spéciaux non-POSIX
echo répète les caractères d'entrée
echoe
crterase Répète les caractères 'erase' comme backspace-space-backspace.
echok répète un newline après un caractère 'kill'
echonl répète un newline même si ne répète pas d'autres caractères
noflsh désactive le flushing après les caractères spéciaux 'interrupt' et 'quit'
xcase autorise l'entrée et la sorite des caractères majuscules en précédant leur équivalent minuscule avec \, quand icanon est défini. Non-POSIX
tostop stop les tâches de fond qui essayend d'écrire dans le terminal. Non-POSIX
echoprt prterase Répète les caractères effacés en arrière, entre \ et/. Non-POSIX
echoctl
ctlecho Répète les caractères de contrôle en notation (^C) au lieu de litéral. Non-POSIX
echoke
crtkill Répète le caractère spécial 'kill' en effaçant chaque caractère sur la ligne comme indiqué par echoprt et echoe, au lieu de par echoctl et echok. Non-POSIX

Paramètres de combinaison

evenp
parity Identique à parenb -parodd cs7. si inversé, identique à -parenb cs8
oddp identique à parenb parodd cs7. si inversé, identique à -parenb cs8
nl identique à -icrnl -onlcr. si inversé, identique à icrnl -inlcr onlcr -ocrnl -onlret
ek reset les caractères spéciaux 'erase' et 'kill' à leur valeur par défaut.
sane identique à cread -ignbrk brkint -inlcr -igncr icrnl -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke et définit les caractères spéciaux à leur valeur par défaut.
cooked identique à brkint ignpar istrip icrnl ixon opost isig icanon, et définis les caractères eos et eol à leur valeurs par défaut si elles sont les memes que les caractères min et time. inversé, est indentique à raw
raw identique à -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -isig -icanon -xcase min 1 time 0. si inversé, identique à cooked.
cbreak identique à -icanon. si inversé, identique à icanon
pass8 identique à -parenb -istrip cs8. Si inversé, identique à parenb istrip cs7
litout identique à -parenb -istrip -opost cs8. Si inversé, identique à parenb istrip opost cs7
decctlq identique à -ixany. Non-POSIX
tabs identique à tab0. Non-POSIX si inversé, identique à tab3
lcase
LCASE identique à xcase iuclc olcuc. Non-POSIX.
crt identique à echoe echoctl echoke
dec identique à echoe echoctl echoke -ixany intr ^C erase ^ ? kill C-u

Caractères spéciaux

   Les valeurs par défaut des caractères spéciaux varient d'un système à un autre. ils sont défini avec la syntaxe nom valeur.

`intr' Envoie un signal d'interruption
`quit' Envoie un signal quit
`erase' Efface le dernier caractère tapé
`kill' Efface la ligne courante
`eof' Envoie un 'end of file'
`eol' End the line.
`eol2' Caractère alternatife pour end the line. Non-POSIX.
`swtch' Switch to a different shell layer. Non-POSIX.
`start' Redémarre la sortie après l'avoir stoppé
`stop' Stop la sortie
`susp' Envoie un signal stop terminal
`dsusp' Envoie un terminal stop signal après avoir vidé l'entrée. Non-POSIX.
`rprnt' Redéssine la ligne Non-POSIX.
`werase' Efface le dernier mot tapé Non-POSIX.
`lnext' Entre le prochain caractère tapé littérallement, même si c'est un caractère spécial Non-POSIX.

Paramètres spéciaux

min N Définit le nombre minimum de caractèresqui vont satisfaire une lecture jusqu'au moment ou la valeur expire quand -icanon est définit.
time N défini le nombre de dixièmes de secondes avant que la lecture se termine si le nombre de caractère minimum n'a pas été lus quand -icanon est définit.
ispeed N Définis la vitesse d'entrée
ospeed N Définis la vitesse de sortie
rows N Dit au pilote tty du kernel que le terminal a N lignes
cols N
columns N Dit au pilote tty du kernel que le terminal a N colonnes. Non-POSIX
size affiche le nombre de lignes et de colonne que le kernel pense que le terminal a. Non-POSIX
line N Use line discipline N. Non-POSIX
speed Affiche la vitesse du terminal

   N Définit la vitesse de l'entrée et la sortie. N peut être : 0 50 75 110 134 134.5 150 200 300 600 1200 1800 2400 4800 9600 19200 38400 `exta' `extb'. `exta' est identique à 19200 ; `extb' est identique à 38400. Certains systèmes supportent les vitesses élevées : 57600, 115200, 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000, 2500000, 3000000, 3500000, ou 4000000.
^
15 juillet 2010

htmlpdflatexmanmd




su

su

Changer temporairement d'utilisateur

   su autorise un utilisateur à devenir temporairement un autre utilisateur. Il lance une commande (souvent un shell interactif) avec le real et l'effective user ID, group ID et les groupes supplémentaires d'un utilisateur donné. Si aucun utilisateur n'est donné, l'utilisateur par défaut est root. Par défaut su ne change pas le répertoire courant, mais il définit les variables HOME et SHELL, et si l'utilisateur n'est pas root, définis USER et LOGNAME. Par défaut, le shell n'est pas un login shell.

OPTIONS

-c COMMAND, --command=COMMAND passe la commande, une simple ligne de commande à lancer, au shell avec l'option -c au lieu de démarrer un shell interactif.
-f, --fast passe l'option -f au shell. N'a de sens que si le shell est csh ou tcsh, qui empêche la lecture de .cshrc au démarrage.
-, -l, --login transforme le shell en login shell. Ce qui supprime les variables d'environnement sauf TERM, HOME, SHELL, USER et LOGNAME et définis PATH à une valeur par défaut.
-m, -p, --preserve-environment Ne change pas les variables d'environnement HOME, USER, LOGNAME ou SHELL
-s SHELL, --shell=SHELL Permet de lancer le SHELL spécifié.
^
11 septembre 2016

htmlpdflatexmanmd




subscriptions.conf

subscriptions.conf

Fichier de configuration des abonnements pour cups

   Le fichier subscriptions.conf définis les abonnements aux notifications d'événements locaux qui sont actifs. Il est normalement dans /etc/cups et est maitenu par cupsd. Ce fichier n'est pas prévu pour être édité ou géré manuellement..

^
03 juillet 2017

htmlpdflatexmanmd




sudo

sudo, sudoedit

Exécute une commande sous un autre utilisateur

   sudo autorise un utilisateur à exécuter une commande en tant que super-utilisateur ou un autre utilisateur. L'utilisateur réel est utilisé pour déterminer le nom de l'utilisateur avec lequel vérifier la stratégie de sécurité

   sudo support une architecture à plugin pour les stratégies de sécurité et le logging. La stratégie de sécurité détermine quels privilèges un utilisateur a en lançant sudo. La stratégie peut exiger que l'utilisateur s'authentifie. La stratégie de sécurité par défaut est sudoers, qui est configuré via /etc/sudoers, ou via LDAP.

   Les stratégie de sécurité peuvent supporter le cache d'accréditifs pour permettre à l'utilisateur de lancer sudo pendant un certain temps sans retaper son mot de passe.

OPTIONS

-A, --askpass Normalement, si sudo exige un mot de passe, il le lis depuis le teminal de l'utilisateur. -A lance un helper
-b, --background Dans la commande en tâche de fond
-C, --close-from=num Ferme tous les descripteurs de fichier supérieur ou égal à ‹num› avant d'exécuter une commande. Les valeurs inférieur à 3 ne sont pas permises
-E, --preserve-env Indique à la stratégie de sécurité que l'utilisateur souhaite préserver ses variables d'environnement.
-e, --edit Édite un ou plusieurs fichiers
-g group, --group=group Lance la commande avec le groupe primaire spécifié au lieu du groupe primaire de l'utilisateur cible
-H, --set-home Demande que la stratégie définisse la variable HOME au répertoire spécifié par l'utilisateur cible
-h, --host=host Lance la commande sur l'ĥôte spécifié si le plugin de startégie de sécurité supporte les commandes distantes.
-i, --login Lance le shell de l'utilisateur cible. Cela signifie que les fichiers comme .profile ou .login sont lus. Si aucune commande n'est spécifiée, un shell interactif est lancé
-k, --reset-timestamp Utilisé sans commande, invalide les accréditifs cachés de l'utilisateur. En d'autres termes, la prochaine commande sudo nécessitera un mot de passe. Utilisé avec une autre option ou une commande, ignore les accréditifs en cache.
-K, --remove-timestamp Similaire à -k, excepté qu'il supprime les accréditifs cachés de l'utilisateur et ne peut pas être utilisé en conjonction avec une commande ou autre option
-l, --list Sans commande, liste les commandes permises (ou interdites) pour l'utilisateur invoquant, ou -U. Si une commande est spécifié et permise par la stratégie, le chemin comple de la commande est affichées avec les arguments.
-n, --non-interactive Empêche l'utilisateur d'entrer quoi que ce soit.
-P, --preserve-groups Préserve le groupe de l'utilisateur invoquant
-p, --prompt=prompt Utilise un prompt de mot de passe personnalisé:

        %H Étend le nom d'hôte incluant le nom de domaine
        %h Étend un nom d'hôte local sans le domaine
        %p Étend le nom de l'utilisateur dont le mot de passe est demandé
        %U Étend le nom de login de l'utilisateur cible
        %u Étend le nom de login de l'utilisateur invoquant
        %% le caractère '%'

-r, --role=role Lance la commande avec le contexte SELinux qui inclus le rôle spécifié
-S, --stdin Écrit le prompt sur stderr et lit le mot d-e passe depuis stdin au lieu du terminal
-s, --shell Lance le shell spécifié par la variable d'environnement SHELL si définie, ou le shell de l'utilisateur invoquant
-t, --type=type Lance la commande avec le contexte de sécurité SELinux qui inclus le type spécifié. Non spécifié, le type par défaut est dérivé du rôle
-U, --other-user=user avec -l, liste les privilèges de l'utilisateur
-T, --command-timeout=timeout Définis un timeout pour la commande
-u, --user=user Lance la commande sous cet utilisateur
-v, --validate Met à jours les accréditifs en cache de l'utilisateur
-- Indique la fin des arguments


   Les variables d'environnement à définir pour la commande peuvent également être passés sur la ligne de commande sous la forme VAR=value, sujettes à restriction.

Exécution de commande

   Quand sudo exécute une commande, la stratégie de sécurité spécifie l'environnement d'exécution pour la commande. Typiquement, l'uid et gid réel et effectif sont définis pour correspondre à l'utilisateur cible, tel que spécifié dans la base de comptes, et le vecteur groupe est initialisé avec la base de groupes.

  Les paramètres suivants peuvent être spécifiés par la stratégie de sécurité:

        UID effectif et réel
        GID effectif et réel
        GID supplémentaires
        La liste d'environnement
        Répertoire de travail courant
        Masque de création de fichier
        Role et type SELinux
        Priorité (nice)

   Quand sudo lance une commande, il se fork, définis l'environnement d'exécution, et appel execve dans le processus enfant. Le processus sudo principal attend que la commande soit complétée, puis passe le status de sortie de la commande à la fonction de fermeture de la stratégie de sécurité et quitte. Si un plugin de loggin est configuré ou si la stratégie de sécurité le demande explicitement, un nouveau pseudo-terminal est créé et un second process sudo est utilisé pour relayer les signaux de contrôle de job entre le pty de l'utilisateur et le nouveau pty. Ce processus rend possible, par exemple, se suspendre et résumer la commande. Sans cela, la commande dans un groupe de processus orphelin et ne reçevrai aucun signal de contrôle de job. Un cas spécial, si le plugin de stratégie ne définis pas de fonction close et aucun pty n'est requis, sudo exécute la commande directement au lieu de fork. le plugin sudoers ne définis une fonction close quand quand le loggin I/O est activé, un pty requis, ou les options pam_session ou pm_setcred sont activés.

Gestion des signaux

   Quand la commande est lancée comme enfant du processus sudo, sudo relai les signaux qu'il reçoit à la commande. Les signaux SIGINT et SIGQUIT sont seulement relayés quand la commande est lancées dans un nouveau pty ou quand le signal a été envoyé par un processus utilisateur, pas le kernel. Cela évite que la commande reçoive 2 fois SIGINT chaque fois que l'utilisateur utilise Contrôle-C. Certains signaux comme SIGSTOP et SIGKILL, ne peuvent être relayés à la commande. SIGTSTP doit être envoyé au lieu de SIGSTOP pour suspendre une commande.

   Un cas spécial, sudo ne relai pas les signaux qui sont envoyés par la commande lancée. Cela empêche la commande de se tuer elle-même. Dans certains systèmes, reboot(8) envoie SIGTERM à tous les processus non-système autre que lui-même avant de redémarrer le système. Celà empêche sudo de relayer SIGTERM, qui peut quitter avant que le système soit redémarré. En résultat, lancer un script qui appel reboot ou shutdown via sudo peut terminer le système dans un état indéfinis sauf si reboot ou shutdown sont lancés avec exec() au lieu de system().

   Si aucun plugin de loggin n'est chargé et que la stratégie n'a pas définis de fonction close, définir un timeout de commande ou que la commande soit lancé dans un nouveau pty, sudo peut exécuter la commande directement.

Plugins

   Les plugins peuvent être spécifiés via les directives Plugin dans sudo.conf. Ils peuvent être chargés comme objets partagés dynamiques ou compilés directement dans sudo. sudoers est le plugin par défaut

Valeur de sortie

   Le code de sortie de sudo est le code de sortie de la commande exécutée. Si la commande s'est terminée à cause d'un signal, sudo envoie lui-même le signal qui termine la commande.

   Sinon, sudo quitte avec une valeur de 1 s'il y a un problème de configuration/permission ou si sudo ne peut pas exécuter la commande. Dans le dernier cas, la chaîne d'erreur est affichée sur stderr. Si sudo ne peut pas stat(2) une ou plusieurs entrées dans le PATH de l'utilisateur, une erreur est affichée sur stderr.

Notes de sécurité

   Sudo tente d'être sûre en exécutant des commandes externes. Pour éviter le spoofing de commande, sudo vérifie "." et "" en dernier en recherchant une commande dans le PATH de l'utilisateur. Noter cependant que la variable PATH n'est pas modifée et est passée inchangée au programme que sudo exécute.

   Les utilisateurs ne devrait jamais obtenir des privilèges pour exécuter des fichiers qui sont en écriture par l'utilisateur ou qui résident dans un répertoire en écriture par l'utilisateur. Si l'utilisateur peut modifier ou remplacer la commande il n'y a pas de limite à ce qui peut être lancé.

   Noter que sudo normalement ne log que les commandes explicitement lancées. Si un utilisateur lance une commande telle que sudo su ou sudo sh, les commandes suivantes ne sont plus sujettes à la stratégie sudo. De même pour les commandes qui offrent des échappement shell. Si le loggin I/O est activé, les commandes suivantes sont loggées, mais il n'y a pas des logs traditionnels pour ces commandes. À cause de celà, une attention particulière doit être portée sur l'accès des utilisateurs aux commandes via sudo pour vérifier que la commande ne donne pas par inadvertance un shell root.

   Pour éviter la fuite d'information potentiellement sensible, sudo désactive les coredumps par défaut durant l'exécution.

Variables d'environnement

EDITOR Nom de l'éditeur par défaut pour -e (sudoedit), si SUDO_EDITOR ou VISUAL ne sont pas définis
MAIL Emplacement de la boite mail de l'utilisateur
HOME Répertoire personnel de l'utilisateur
LOGNAME Nom de l'utilisateur
PATH Les chemins de recherche pour les commandes
SHELL Shell courant de l'utilisateur
SUDO_ASKPASS Spécifie le chemin du helper pour lire le mot de passe si aucun terminal n'est disponible ou avec -A
SUDO_EDITOR Éditeur par défaut pour -e (sudoedit)
SUDO_GID GID de l'utilisateur qui a invoqué sudo
SUDO_PROMPT prompt pour les mots de passe
SUDO_PS1 valeur PS1 pour le programme à exécuter
SUDO_UID UID de l'utilisateur qui a invoqué sudo
SUDO_USER nom de login de l'utilisateur qui a invoqué sudo
USER nom de l'utilisateur
USERNAME idem à USER
VISUAL Éditeur par défaut pour -e (sudoedit) si SUDO_EDITOR n'est pas définis

Exemples

obtenir une liste des répertoire non-lisible:
sudo ls /usr/local/protected
Liste le répertoire personnel de l'utilisateur yaz dans une machine où le système de fichier maintenant ~ yaz n'est pas exporté en root
sudo -u yaz ls ~ yaz
Éditer index.html en tant qu'utilisateur www
sudoedit -u www ~ www/htdocs/index.html
Voir les logs système uniquement accessibles par root
sudo -g adm more /var/log/syslog
Lancer un éditeur en tant que jim avec un groupe primaire différent
sudoedit -u jim -g audio ~ jim/sound.txt
Éteindre la machine
sudo shutdown -r +15 "quick reboot"
^
03 juillet 2017

htmlpdflatexmanmd




sudo.conf

sudo.conf

Fichier de configuration de sudo

   sudo.conf supporte les directive 'Plugin', 'Path', 'Set', 'Debug'.

Plugin

Une ligne Plugin définis un module et son chemin, suivi de paramètres optionnels. Peut être spécifié plusieurs fois
Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so sudoers_mode=0440

Path

   Path définis les chemins vers divers librairies/programmes nécessaire. Si une ligne Path ne contient pas de chemin, la fonctionnalité est considérée désactivée:

        askpass chemin du helper pour lire les mots de passe quand aucun terminal n'est disponible
        noexec Chemin de la librairie wrappers pour les fonctions execl(), execle(), execlp(), exect(), execv(), execve(), execvP(), execvp(), execvpe(), fexecve(), popen(), posix_spawn(), posix_spawnp(), system(), et wordexp() qui empêche l'exécution d'autres commandes. Utilisé pour implémenter la foncionnalité noexec dans les systèmes qui supportent LD_PRELOAD ou son équivalent.
        plugin_dir Répertoire de recherche des plugins spéficier sans chemin complet.
        sesh Chemin de sesh. Utilé quand sudo est compilé avec le support SELinux

Set

disable_coredump true|false Par défaut sudo désactive le coredump pour éviter toute fuite de données sensible
group_source sudo passe la liste des groupes de l'utilisateur invoquant à la stratégie et les plugins I/O. Dans la plupart des système, il y a une limite du nombre de groupes (généralement 16). si la liste de groupe dépasse la limite kernel, sudo consulte lui-même la liste des groupes:

        static Utilise la liste de groupe statique que le kernel retourne
        dynamic Requête toujours la base de groupe. C'est dynamique dans le sens où les changements fait dans la base de groupe après que l'utilisateur se soit loggé sont reflétés dans la liste des groupe.
        adaptive Ne requête la pase que si la liste des groupes retournés par le kernel a atteind la limite des entrées.

max_groups Nombre maximum de groupes utiliateur à récupérer dans la base de groupe lorsque sudo requête la base de groupe directement
probe_interfaces Par défaut, sudo sont les interfaces réseaux du système et passe l'IP à chaque interface activée au plugin de stratégie. Cela simplifie les règles de match basé sur l'IP sans avoir à requêter DNS.

Debug

Une ligne Debug consiste du mot clé Debug, suivi par le nom du programme ou plugin à débugger (sudo, visudo, sudoreplay, sudoers), le nom du fichier de dibug et une liste de flags. Par exemple:
Debug sudo /var/log/sudo_debug all@warn,plugin@info

        all Match tous les sous-systèmes
        args traitement des arguments de la ligne de commande
        conv Conversation utilisateur
        edit sudoedit
        event Sous-système d'évènement
        exec exécution de commande
        main Fonction main de sudo
        netif Gestion des interfaces réseaux
        pcomm Communication avec le plugin
        pty Code lié au pty
        selinux gestion SELinux
        util Fonctions utilitaires
        utmp Gestion utmp
^
03 juillet 2017

htmlpdflatexmanmd




sudoers

sudoers

plugin de stratégie de sécurité de sudo par défaut

   Ce plugin détermine les privilèges sudo de l'utilisateur en lisant la stratégie dans /etc/sudoers. sudo consulte le fichier sudo.conf pour déterminer quelle stratégieet plugin charger.

   Les arguments du plugins sont les suivants:

ldap_conf=‹path› emplacement du fichier ldap.conf alternatif
ldap_secret=‹path› emplacement du fichier ldap.secret alternatif
sudoers_file=‹path› fichier sudoers alternatif
sudoers_uid=‹uid› UID du propiétaire du fichier sudoers
sudoers_gid=‹gid› GID du fichier sudoers
sudoers_mode=‹mode› mode du fichier sudoers en octal

Authentification Utilisateur

   La stratégie de sécurité sudoers nécessite que la plupart des utilisateurs s'authentifient eux-même avant d'utiliser sudo. Un mot de passe n'est pas requis si l'utilisateur invoquant est root, si l'utilisateur cible est le même que l'utilisateur invoquant, ou si la startégie a désactivé l'authentification pour la commande utilisateur ou pour l'utilisateur. À la différence de su, quand sudoers exige une authentification, il valide les accréditifs de l'utilisateur, pas de l'utilisateur cible. Cela peut être changé avec rootpw, targetpw et runaspw.

   Si un utilisateur qui n'est pas listé dans la stratégie tente de lancer une commande via sudo, un mail est envoyé aux autorités définies.

   Noter qu'aucun mail n'est envoyé si un utilisateur non-autorisé tente de lancer sudo avec -l ou -v sauf en cas d'erreur d'authentification. Cela permet aux utilisateurs de déterminer s'ils sont autorisés ou non à utiliser sudo. Toute tentative d'utiliser sudo est loggé.

   Si sudo est lancé par root, et que la variable SUDO_USER est définie, la stratégie sudoers utilise cette valeur pour déterminer qui est l'utilisateur actuel. Cela peut être utilisé par un utilisateur pour logger des commandes via sudo même quand un shell root a été invoqué.

   sudoers utilise des fichiers horodatés par utilisateur pour le caching d'accrédifits. Une fois un utilisateur authentifié, un enregistrement est écrit contenant l'uid utilisé pour s'authentifier, l'id de session du terminal et un horodatage. L'utilisateur peut ainsi utiliser sudo sans mot de passe pour une courte période de temps. Par défaut, sudoers utilise un enregistrement séparé pour chaque tty, qui signifie que les sessions login de l'utilisateur sont authentifiés séparément.

Logging

   sudoers peut logger toutes les tentatives, réussies ou non et les erreurs dans syslog, un fichier de log, ou les 2. sudoers est également capable de lancer une commande dans un pseudo-tty et logger toutes les entrées/sorties. L'entrée standard, la sortie standard, et l'erreur standard peuvent être loggés même s'ils ne sont pas associés avec un terminal. Le logging d'E/S n'est pas activé par défaut.

Environnement de commande

   vu que les variables d'environnement peuvent influencer le comportement des programmes, sudoers fournis un moyen de restreindre les variables de l'environnement utilisateur hérités par la commande à lancer. Il y a 2 manières distincts de gérer ces variables.

   Par défaut, l'option env_reset est activée, les commandes sont donc lancées dans un environnement minimal. Dans les systèmes Linux sans environnement PAM, l'environnement est initialisé avec le contenu de /etc/environment. Le nouvel environnement contient TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME et les variables SUDO_* en plus des variables de processus invoquant permis par env_check et env_keep. C'est une liste blanche de variables d'environnement. Les variables commençant pas () sont supprimées sauf si le nom et la valeur sont matché par env_keep ou env_check, vu qu'elles sont interprétées comme des fonctions par d'anciennes versions de bash

   Si, cependant, l'option env_reset est désactivé, toute variable non explicitement refusée par env_check et env_delete sont héritées depuis le processus invoquant. Dans ce cas, env_check et env_delete deviennet comme une blacklist. Les variable commençant pas () sont toujours supprimées. Vu qu'il n'est pas possible de blacklister toutes les variables d'environnement potentiellement dangereuses, le mode env_reset est préférable.

   Par défaut, les variables d'environnement sont matchés par leur nom. Cependant, si le motif inclus le signe '=', les noms des variables et leur valeur sont matchés.

   La liste complète des variables d'environnement que sudo autorise ou refuse est contenue dans la sortie de sudo -V quand lancé en root.

   Dans les systèmes qui supportent PAM où le module pam_env est activé pour sudo, les variables dans l'environnement PAM peuvent être fusionnées dans l'environnement. Si une variable dans l'environnement PAM est déja présente, la valeur est remplacée seulement si la variable n'était pas préservées par sudoers. quand env_reset est activé, les variables préservées depuis l'environnement de l'utilisateur invoquant par la liste env_keep a précédence sur l'environnement PAM. Quand env_reset est désactivé, les variables de l'environnement utilisateur ont précédence sur l'environnement PAM sauf en cas de match de la liste env_delete.

   Un cas spécial, si -i est spécifié, sudoers initialise l'environnement sans regarder la valeur de env_reset. DISPLAY, PATH et TERM ne sont pas changés; HOME, MAIL, SHELL, USER et LOGNAME sont basés sur l'utilisateur cible. Dans les systèmes Linux sans PAM, le contenu de /etc/environment est également inclus.

   Finalement, restricted_env_file et env_files sont appliqués, si présents. Les variables dans restricted_env_file sont appliqués en premier, et sont sujets aux même restrictions que l'environnement de l'utilisateur invoquant. Les variables env_file sont appliquées en dernier et ne sont pas sujettes à ces restrictions. Dans tous les cas, les variables présentes dans les fichiers ne sont définis à leur valeur spécifiées que si elles ne sont pas en conflit avec une variable d'environnement existante

Format du fichier sudoers

   Le fichier sudoers est composé de 2 types d'entrées: les alias et les utilisateurs. Quand plusieurs entrées correspondent à un utilisateur, elles sont appliquées dans l'ordre. En cas de multiple match, le dernier est utilisé.

Syntaxe EBNF

   EBNF contient les opérateurs suivants:

        ? Signifie que le symbole ou groupe de symbole précédent est optionnel, c'est à dire qu'il peut apparaître une fois ou pas du tout
        Signifie que le symbole ou groupe de symbole précédent peut apparaître 0 ou plusieurs fois
        + Signifie que le symbole ou groupe de symbole précédent peut apparaître une ou plusieurs fois

Aliases

Il y a 4 types d'alias: User_Alias, Runas_Alias, Host_Alias et Cmnd_Alias:
Alias ::= 'User_Alias' User_Alias (':' User_Alias)* |
    'Runas_Alias' Runas_Alias (':' Runas_Alias)* |
    'Host_Alias' Host_Alias (':' Host_Alias)* |
    'Cmnd_Alias' Cmnd_Alias (':' Cmnd_Alias)*
    
User_Alias ::= NAME '=' User_List
    
Runas_Alias ::= NAME '=' Runas_List
    
Host_Alias ::= NAME '=' Host_List
    
Cmnd_Alias ::= NAME '=' Cmnd_List
    
NAME ::= [A-Z]([A-Z][0-9]_)*

Une liste d'utilisateur consiste de noms d'utilisateurs, UID (préfixé avec '#'), groupes système et GID (préfixés avec '%' et '%#'), netgroups (préfixés par '+'), groupes non-unix (préfixés avec '%:' et '%:#') et de User_Alias. Chaque liste peut être préfixée avec '!'. les " permettent d'éviter le besoin d'échapper les caractères spéciaux, sinon ils doivent être spécifiés en hexa (ex: \x20)
User_List ::= User |
        User ',' User_List
    
User ::= '!'* user name |
        '!'* #uid |
        '!'* %group |
        '!'* %#gid |
        '!'* +netgroup |
        '!'* %:nonunix_group |
        '!'* %:#nonunix_gid |
        '!'* User_Alias

Une liste Runas_Alias est similaire à une User_List.
Runas_List ::= Runas_Member |
        Runas_Member ',' Runas_List
    
Runas_Member ::= '!'* user name |
        '!'* #uid |
        '!'* %group |
        '!'* %#gid |
        '!'* %:nonunix_group |
        '!'* %:#nonunix_gid |
        '!'* +netgroup |
        '!'* Runas_Alias

Une liste d'hôtes est faite d'un ou plusieurs noms d'hôte, adresses IP, réseaux, +netgroups, et d'autres alias.
Host_List ::= Host |
        Host ',' Host_List
    
Host ::= '!'* host name |
        '!'* ip_addr |
        '!'* network(/netmask)? |
        '!'* +netgroup |
        '!'* Host_Alias

   Une liste de commande est une liste d'un ou plusieurs nom de commandes, répertoires, et autres alias. Un nom de commande est un nom complet de fichier qui peut inclure des wildcard shell. Un simple nom de fichier permet de lancer une commande avec des arguments. Cependand, il est possible de spécifier les arguments (incluant des wildcard), ou "" pour indiquer que la commande peut seulement être lancée sans arguments. Un répertoire est un chemin complet se terminant par '/', et l'utilisateur pout exécuter tout fichier dans ce répertoire, mais pas dans les sous-répertoires

Si un Cmnd est associé avec des arguments de ligne de commande, les arguments dans Cmnd doivent matcher exactement avec ceux donnés par l'utilisateur. Noter que les caractères suivants doivent être échappés: ',’, ':’, '=’, '\’. La commande intégrée sudoedit est utilisée pour permettre à un utilisateur de lancer sudo avec -e. Il peut prendre des arguments. Noter que sudoedit est une commande intégrée dans sudo et doit être spécifié dans le fichier sudoers sans chemin.
digest ::= [A-Fa-f0-9]+ |
        [[A-Za-z0-9+/=]+
    
Digest_Spec ::= "sha224" ':' digest |
        "sha256" ':' digest |
        "sha384" ':' digest |
        "sha512" ':' digest
    
Cmnd_List ::= Cmnd |
        Cmnd ',' Cmnd_List

command name ::= file name |
        file name args |
        file name '""'
    
Cmnd ::= Digest_Spec? '!'* command name |
        '!'* directory |
        '!'* "sudoedit" |
        '!'* Cmnd_Alias

   Si un nom de commande est préfixé avec un Hash, la commande ne match que si le hash SHA2 est vérifié. Les formats suivants sont supportés: sha224, sha256, et sha512. La chaîne peut être spécifiée en hexa ou en base64.

Default

Certaines options de configuration ont une valeur par défaut qui peut être changé en temps réel via une ou plusieurs lignes Default_Entry. Cela peut affecter tous les utilisateurs dans tous les hôtes, tous les utilisateurs sur un hôte spécifique, un utilisateur spécifique, une commande spécifique, ou des commandes lancées par un utilisateur spécifiques.
Default_Type ::= 'Defaults' |
        'Defaults' '@' Host_List |
        'Defaults' ':' User_List |
        'Defaults' '!' Cmnd_List |
        'Defaults' '›' Runas_List
    
Default_Entry ::= Default_Type Parameter_List
    
Parameter_List ::= Parameter |
        Parameter ',' Parameter_List
    
Parameter ::= Parameter '=' Value |
        Parameter '+=' Value |
        Parameter '-=' Value |
        '!'* Parameter

   += et -= sont utilisés pour ajouter ou supprimer des éléments d'une liste. Les entrées sont parsée dans l'ordre suivant: generic, host, user, et runas, command. S'il y a plusieurs paramètres Default de même type, le dernier match est utilisé. Les paramètres Defaults suivant sont parsé avant tous les autres vu qu'ils affectent les entrées suivantes: fqdn, group_plugin, runas_default, sudoers_locale.

Spécification d'utilisateur


User_Spec ::= User_List Host_List '=' Cmnd_Spec_List \
        (':' Host_List '=' Cmnd_Spec_List)*
    
Cmnd_Spec_List ::= Cmnd_Spec |
        Cmnd_Spec ',' Cmnd_Spec_List
    
Cmnd_Spec ::= Runas_Spec? Option_Spec* Tag_Spec* Cmnd
    
Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')'
    
Option_Spec ::= (SELinux_Spec | Solaris_Priv_Spec | Date_Spec | Timeout_Spec)
    
SELinux_Spec ::= ('ROLE=role' | 'TYPE=type')
    
Solaris_Priv_Spec ::= ('PRIVS=privset' | 'LIMITPRIVS=privset')
    
Date_Spec ::= ('NOTBEFORE=timestamp' | 'NOTAFTER=timestamp')
    
Timeout_Spec ::= 'TIMEOUT=timeout'
    
Tag_Spec ::= ('EXEC:' | 'NOEXEC:' | 'FOLLOW:' | 'NOFOLLOW' |
        'LOG_INPUT:' | 'NOLOG_INPUT:' | 'LOG_OUTPUT:' |
        'NOLOG_OUTPUT:' | 'MAIL:' | 'NOMAIL:' | 'PASSWD:' |
        'NOPASSWD:' | 'SETENV:' | 'NOSETENV:')

   Une spécification d'utilisateur détermine quelles commandes un utilisateur peut lancer (et sous quel utilisateur). dans les hôte spécifiés. Par défaut, les commandes sont lancées en root. La structure de base est who where = (as_whom] what

Runas_Spec

   un Runas_Spec détermine l'utilisateur et/ou le groupe sous laquelle une commande peut être lancée. un Runas_Spec pleinement spécifié consiste de 2 Runas_List séparés par ':' et entre parenthèses. Le premier Runas_List indique sous quels utilisateurs la commande peut être lancée (comme avec sudo -u). Le second définis une liste de groupes qui peuvent être spécifié via sudo -g. Si les 2 Runas_List sont spécifié, la commande peut être lancée avec n'importe quelle combinaison d'utilisateurs et groupes listés dans leur Runas_list respectifs. Si seul le premier est listé, la commande peut être lancée par n'importe quel utilisateur dans la liste mais -g ne peut pas être spécifié. Si le premier Runas_List est vide, mais le second est spécifié, tous les utilisateurs peuvent lancer la commande avec le groupe définis à un listé. Si les 2 sont vides, la commande ne peut être lancée que sous l'utilisateur invoquant. Si Runas_Spec n'est pas spécifiée, la commande peut être lancée en root et aucun groupe ne peut être spécifié.

l'utilisateur dbg peut lancer ces 3 commandes, mais seulememt comme operator:
dgb boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm
Il est également possible de remplacer Runas_Spec dans une entrée:
dgb boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm
On peut l'étendre peut permettre à dbg de lancer /bin/ls avec soit l'utilisateur soit le groupe à operator:
dgb boulder = (operator : operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm
Noter que bien que la portion groupe permet à l'utilisateur de lancer la commande avec ce groupe, il ne force pas l'utilisateur à le faire. Si aucun groupe n'est spécifié, la commande sera lancée avec le groupe listé dans l'entrée de la base de mot de passe de l'utilisateur. Exemple de ce qui est permis par l'entrée ci-dessus:
sudo -u operator /bin/ls
sudo -u operator -g operator /bin/ls
sudo -g operator /bin/ls
Dans l'exemple suivant, l'utilisateur tcm peut lancer des commandes qui accèdent à un périphérique modem avec le groupe dialer
tcm boulder = (:dialer) /usr/bin/tip, /usr/bin/cu, /usr/local/bin/minicom
Seul le groupe est définis, la commande est lancée avec l'utilisateur tcm
sudo -g dialer /usr/bin/cu
Plusieurs utilisateurs et groupeg peuvent être présents dans un Runas_Spec, auquel cas l'utilisateur peut sélectionner une combinaison d'utilisateurs et groupes via -u et -g
alan ALL = (root, bin : operator, system) ALL
alan peut lancer une commande soit en root, soit bin, optionnellement en définissant le groupe operator ou system

Option_Spec

   un Cmnd peut avoir 0 ou plusieurs options. En fonction du système, les options peuvent consister de rôle/types SELinux, ou timeouts. Une fois une option définis pour une Cmnd, les Cmnd suivantes dans Cmnd_Spec_List héritent de cette option, sauf remplacé par une autre option.

   les règles sudoers peuvent spécifier une date de début et de fin via les paramètres NOTBEFORE et NOTAFTER. L'horodatage peut être spécifié en temps généralisé, rfc4517 (yyymmddHHMSSZ). Il est également possible de spécifier un offset en heures et minutes UTC. Par exemple '-0500' correspond à l'heure Eastern Standard aux US.

   Une commande peut avoir un timeout. S'il expire avant que la commande ne se soit terminées, la commande est terminées. Le timeout peut être spécifié en jours, heures, minutes et secondes (ex: 7d8h30m10s, 14d, 8h30m, 600s, 3600).

   Une commande peut avoir 0 ou plusieurs tags. Les valeurs de tag supportés sont: EXEC, NOEXEC, FOLLOW, NOFOLLOW, LOG_INPUT, NOLOG_INPUT, LOG_OUTPUT, NOLOG_OUTPUT, MAIL, NOMAIL, PASSWD, NOPASSWD, SETENV, et NOSETENV. Une fois un tag définis dans une Cmnd, les Cmnd suivants dans la Cmnd_Spec_List héritent de ce tag sauf si remplacé par le tag opposé.

        [NO]EXEC autorise à lancer un exécutable lié dynamiquement
        [NO]FOLLOW autorise à suivre les liens symboliques pour sudoedit uniquement
        [NO]LOG_INPUT Remplace l'option log_input
        [NO]LOG_OUTPUT Remplace l'option log_output
        [NO]MAIL Remplace la valeur de l'option mail_all_cmnds. N'a pas d'effet avec -l ou -v
        [NO]PASSWD Exige que l'utilisateur s'authentifie lui-même avant de lancer une commande
        [NO]SETENV Remplace la valeur de l'option SETENV

Wildcard

   sudo autorise les wildcard style shell dans les noms d'hôte, noms de chemins, et arguments de ligne de commande dans le fichier sudoers:

        Matche un jeu de 0 ou plusieurs caractères
        ? Matche un simple caractère
        [...] Matche un des caractères
        [!...] Matche tout caractère non listé
        \x pour spécifier les caractères '*','?','[' et ']'

Inclure d'autres fichiers

   Il est possible d'inclure d'autres fichiers sudoers avec les directives #include et #includedir.

Autres caractères spéciaux et mots réservés

   '#' est utilisé pour indiquer un commentaire (excepté pour #include et #includedir ou dans le contexte d'un nom d'utilisateur suivi par un ou plusieurs chiffres).

   Le mot réservé ALL est un alias intégré qui implique qu'un match réussi toujours.

   '!' peut être utilisé comme opérateur NOT dans une liste.

Options sudoers

   sudo peut être modifié par des lignes Default_Entry:

always_query_group_plugin (bool) si un group_plugin est configuré, l'utilise pour résoudre les groupe sous la forme %group tant que ce n'est pas également un groupe système. Normalement, seules les groupes sous la forme %#group sont passé au group_plugin
always_set_home (bool) activé, sudo définis HOME au répertoire home de l'utilisateur cible
authenticate (bool) définis, les utilisateurs doivent s'authentifier eux-même avant de lancer des commandes
closefrom_override (bool) définis, l'utilisateur peut utiliser sudo -C qui remplace le point de départ par défaut auquel sudo commence à fermer les descripteurs de fichier.
compress_io (bool) définis, si sudo est configuré pour logger l'entrée ou la sortie d'une commande, les logs I/O sont compressés avec zlib.
exec_background (bool) par défaut, sudo lance une commande en foreground tant que sudo est lui-même en foreground. à on et la commande lancé dans un pty (dû au logging I/O ou du flag use_pty), la commande est lancées en tâche de fond.
env_editor (bool) Définis, visudo utilise la valeur de EDITOR ou VISUAL comme liste d'éditeur par défaut
env_reset (bool) définis, lance la commande dans un environnement minimal
fast_glob (bool) utilise la fonction fnmatch(3) au lieu de glob(3) pour le globbing, ce qui est plus rapide, mais n'est pas capable de matcher les chemins relatifs
fqdn (bool) place les noms ftdn dans le fichiers sudoers quand le nom d'hôte local ne contient pas de nom de domaine.
ignore_audit_errors (bool) autorise à lancer les commandes même si sudoers ne peut écrire dans le log d'audit
ignore_dot (bool) définis, ignore "." ou "" dans la variable PATH
ignore_iolog_errors (bool) autorise à lancer des commandes même si sudoers ne peut écrire dans le fichier de log E/S
ignore_logfile_errors (bool) autorise à lancer des commandes même si sudoers ne peut écrire dans le fichier de log
ignore_local_sudoers (bool) Si définis via LDAP, ne parse pas /etc/sudoers
ignore_unknown_defaults (bool) ne produit pas d'alerte si une entrée Defaut inconnue est rencontrée, ou une options sudoOptions dans LDAP.
insults (bool) insulte les utilisateurs quand ils entrent un mot de passe incorrect
log_host (bool) Définis, le nom d'hôte est loggé
log_input (bool) Définis, log l'entrée utilisateur
log_output (bool) Définis, log la sortie envoyée à l'écran
log_year (bool) Définis, log l'année au format yyyy
long_otp_prompt (bool) En validant un schéma OTP, un prompt à 2 lignes est utilisé pour simplifier le copier/coller du challenge.
mail_all_cmnds (bool) Envoie un mail à chaque tentative d'exécution d'une commande (excepté avec -l ou -v et une authentification réussie)
mail_always (bool) envoie un mail à chaque fois qu'un utilisateur lance sudo.
mail_badpass (bool) Envoie un mail en cas de mot de passe incorrect
mail_no_host (bool) définis, envoie un mail si l'utilisateur invoquant existe dans le fichier sudoers mais n'est pas autorisé à lancer les commandes dans l'hôte courant.
mail_no_perms (bool) Définis, envoie un mail si l'utilisateur invoquant est autorisé à utiliser sudo, mais n'a pas l'autorisation de lancer la commande
mail_no_user (bool) Définis, envoie un mail si l'utilisateur invoquant n'est pas dans le fichier sudoers
match_group_by_gid (bool) par défaut, sudoers recherche chaque groupe dont l'utilisateur est membre par son GID pour déterminer le nom du groupe. Dans les systèmes ou la recherche des groupes est longue, cette option évite de résoudre les GID en noms de groupe
netgroup_tuple (bool) Définis, la recherche de netgroup est effectuée en utilisant les triplets netgroup
noexec (bool) Définis, toutes les commande lancées via sudo fonctionne comme avec le tag NOEXEC
pam_session (bool) Créé une nouvelle session PAM pour la commande à lancer
pam_setcred (bool) tente d'obtenir les accréditifs de l'utilisateur cible
passprompt_override (bool) Demande le mot de passe spécifié par passprompt est seulement utilisé si le prompt fournis par PAM match la chaîne "Password:". si definis, passprompt est toujours utilisé.
path_info (bool) informe quand la commande ne peut pas être trouvée dans le PATH.
preserve_groups (bool) par défaut, sudo initialise le vecteur de groupe à la liste des groupes de l'utilisateur cible. Définis, le vecteur de groupe de l'utilisateur n'est pas altéré. Le GID réel et effectif continuent de matcher l'utilisateur cible
pwfeedback (bool) Fournis un retour visuel en tapant un mot de passe
requiretty (bool) définis, sudo n'est lancé que si l'utilisateur est loggé dans un vrai tty.
root_sudo (bool) Définis, root est autorisé à lancer sudo. Désactivé, empêche sudoedit
rootpw (bool) Définis, sudo demande le mot de passe root au lieu du mot de passe de l'utilisateur invoquant
runaspw (bool) Définis, sudo demande le mot de passe de l'utilisateur définis par runas_default au lieu du mot de passe de l'utilisateur invoquant
set_home (bool) Définis et sudo invoqué avec -s, HOME est définis au home de l'utilisateur cible
set_logname (bool) Définis LOGNAME. Cependant pour certains programmes (incluant RCS) utilisent LOGNAME pour déterminer la vrai identité de l'utilisateur.
set_utmp (bool) Activé, sudo créé une entrée dans utmp ou utmpx quand un pseudo tty est alloué.
setenv (bool) Autorise l'utilisateur à désactiver l'option env_reset avec l'option -E
shell_noargs (bool) Définis et sudo est invoqué sans arguments, agit comme avec -s: lance un shell en root
stay_setuid (bool) Normalement, quand sudo exécute une commande, les UID réel et effectifs sont définis à l'utilisateur cible. Cette option laisse l'UID réel à l'utilisateur invoquant
sudoedit_checkdir (bool) Définis, sudoedit vérifie tous les composants répertoire du chemin à éditer pour vérifier s'il est en écriture par l'utilisateur. Les liens symboliques ne sont pas suivis et sudoedit refuse d'éditer un fichier localisé dans un répertoire accessible en écriture. Non effectif pour root.
sudoedit_follow (bool) Suit les liens symboliques en ouvrant les fichiers.
targetpw (bool) Définis, demande le mot de passe de l'utilisateur spécifié par -u au lieu du mot de passe de l'utilisateur invoquant
tty_tickets (bool) Définis, les utilisateurs doivent s'authentifier pour chaque tty
umask_override (bool) Définis, sudo définis le umask spécifié dans le fichier sudoers sans modification
use_netgroups (bool) Définis, les netgroups peuvent être utilisé à la place d'un utilisateur ou hôte
use_pty (bool) Définis, sudo lance la commande dans un pseudo-tty même si aucun plugin I/O n'est définis
user_command_timeouts (bool) Définis, l'utilisateur peut spécifier un timeout sur la ligne de commande
utmp_runas (bool) Définis, sudo stocke le nom de l'utilisateur runas en mettant à jours utmp au lieur du nom de l'utilisateur invoquant
visiblepw (bool) par défaut, sudo refuse de s'exécuter si l'utilisateur doit entrer un mot de passe mais qu'il n'est pas possible de désactiver l'écho dans le terminal. Cela permet de lancer des commande comme "ssh somehost sudo ls" vu que ssh n'alloue pas de tty par défaut en lançant une commande.
closefrom (int) Avant d'exécuter une commande, sudo ferme tous descripteur de fichier ouvert autre que 0-2. Spécifie un fd à partir duquel fermer les fd.
command_timeout (int) Délai maximum pour l'exécution d'une commande.
maxseq (int) Numéro de séquence maximum qui est substitué pour l'échappement "%{seq}" dans le fichier de log I/O.
passwd_tries (int) Nombre maximum de tentative pour entrer en mot de passe
syslog_maxlen (int) Par défaut, sudoers créé des messages de log jusqu'à 980 octets. Pour éviter de tronquer les messages, sudoers split les message supérieurs à syslog_maxlen.
loglinelen (int) Nombre de caractères par ligne de log. n'a pas d'effet pour syslog.
timestamp_timeout (int) Nombre de minutes avant de redemander un mot de passe.
umask (int) umask pour la création des fichier
badpass_message (string) Message affiché si un utilisateur entre un mot de passe incorrect
editor (string) Liste d'éditeurs autorisé pour visudo.
iolog_dir (string) Répertoire parent où construire le nom de chemin pour le répertoire de log I/O. Seulement utilisé si log_input et log_output sont activés. Les échappements suivants sont permis:

        %{seq} Étendu pour augmenter le numéro de séquence en base 36
        %{user} Étendu au login de l'utilisateur invoquant
        %{group} Étendu au GID réel de l'utilisateur invoquant
        %{runas_user} Étendu au login de l'utilisateur qui exécute la commande
        %{runas_group} Étendu au groupe qui exécute la commande
        %{hostname} Étendu au nom de l'hôte local sans le nom de domaine
        %{command} Étendu au nom de la commande lancée

iolog_file (string) Chemin du fichier de log, relatif à iolog_dir pour les logs I/O. Accepte les séquences d'échappement de iolog_dir
iolog_flush (string) Définis, sudo vide les données de log sur disque après chaque écriture au lieu de le même en tampon. Permet de voir les logs en temps réel.
iolog_group (string) Nom du groupe pour la créations des répertoires et fichiers de log I/O
iolog_mode (string) mode à utiliser pour créer les fichiers de log I/O
iolog_user (string) Propriétaire des répertoires et fichiers de log I/O
lecture_status_dir (string) Répertoire dans lequel sudo stocke les fichiers de status par utilisateur. Défaut: /var/adm/sudo/lectured
mailsub (string) Sujet du mail envoyé. %h étend au nom d'hôte
pam_login_service (string) Nom du service utilisé avec -i. Défaut: sudo
pam_service (string) Nom du service que PAM applique. Défaut: sudo
passprompt (string) Prompt par défaut à utiliser en demandant le mot de passe. Les échappements suivants sont supportés:

        %H Nom d'hôte local fqdn
        %h Nom d'hôte local
        %p utilisateur correspondant au mot de passe demandé
        %U Nom de l'utilisateur cible
        %u nom de l'utilisateur invoquant
        %% le caractère %

role (string) Rôle SELinux par défaut à utiliser en construisant un nouveau contexte de sécurité pour lancer la commande.
runas_default (string) Utilisateur par défaut pour lancer les commande.
sudoers_locale (string) Locale à utiliser pour parser le fichier sudoers, les commandes de logging, et l'envoie de mail.
timestampdir (string) Répertoire dans lequel sudo stocke ses fichiers d'horodatage.
timestampowner (string) Propriétaire du répertoire de status de lecture, d'horodatage et tous les fichiers qui y sont stockés.
type (string) Type SELinux par défaut pour construire un nouveau contexte SELinux
env_file (string) Spécifie le chemin complet d'un fichier contenant les variables d'environnement à définir pour le programme à lancer.
exempt_group (string) Les utilisateurs dans ce groupe sont exemptés du mot de path et des exigences PATH.
fdexec (string) Détermine si sudo exécute une commande par son chemin ou par un fd ouvers. always|never exécute ou non par fd, digest_only n'exécute par fd que si la commande a un digest associé.
group_plugin (string) plugin group sudoers avec des arguments optionnels.
lecture (string) Contrôle quand une lecture courte est affichée avec le prompt. always|never|once.
lecture_file (string) Fichier contenant le message à afficher au lieu du message embarqué
listpw (string) Contrôle quand un mot de passe est requis quand un utilisateur lance sudo -l:

        all Toutes les entrées de l'utilisateur pour l'hôte courant dans le fichier sudoers doivent avoir le flag NOPASSWD pour éviter d'entrée le mot de passe
        always L'utilisateur doit entrer un mot de passe pour utiliser -l
        any Au moins une entrée de l'utilisateur dans sudoers doit avoir le flag NOPASSWD pour ne pas entrer de mot de passe
        never L'utilisateur ne doit jamais entrer un mot de passe pour utiliser l'option -l
       

logfile (string) Chemin du fichier de log sudo.
mailerflags (string) flags à utiliser en invoquant mailer Défaut: -t
mailerpath (string) Chemin du programme pour envoyer les mails.
mailfrom (string) Adresse du champ From
mailto (string) Adresse de destination de mail
restricted_env_file (string) Fichier contenant les variables à définir dans l'environnement. Ces variables de manière similaires à l'environnement de l'utilisateur invoquant.
secure_path (string) Chemin de toutes les commandes lancées par sudo
syslog (string) facilité syslog pour les logs
syslog_badpri (string) Priorité sysloge quand l'utilisateur n'est pas autorisé à lancer une commande ou en cas d'echec de l'authentification
syslog_goodpri (string) Priorité syslog à utiliser quand l'utilisateur est autorisé à lancer une commande et que l'authentification a réussie.
verifypw (string) Contrôle quand un mot de passe est requis avec sudo -v:

        all Toutes les entrées dans le fichiers sudoers doivent avoir NOPASSWD pour éviter d'entrer un mot de passe.
        always L'utilisateur doit toujours entrer sont mot de passe pour utiliser l'option -v
        any Au moins une entrée dans le fichier sudoers pour l'utilisateur doit avoir le flag NOPASSWD pour éviter d'entrer un mot de passe
        never L'utilisateur n'a jamais besoin d'entrer un mot de passe

env_check (string) Variables d'environnement à supprimer sauf si elles sont sûres. Pour toutes les variables excepté TZ, sûre signifie que la valeur de la variable ne contient pas de '%' ou '/'
env_delete (string) Variables d'environnement à supprimer de l'environnement de l'utilisateur quand env_reset n'est pas effectif.
env_keep (string) Variables d'environnements à préserver de l'environnement de l'utilisateur quand env_reset est effectif

Plugins group

   sudoers supporte sa propre interface de plugin pour permettre de rechercher des groupes non-Unix dans une source autre que la base de groupe Unix standard. Celà permet d'implémenter la syntaxe nonunix_group.

   Les plugins group sont spécifiés via le paramètres group_plugin. Les plugins group suivants sont installés par défaut:

group_file.so Supporte un fichier de groupes alternatif qui utilise la même syntaxe que /etc/group. Le chemin du fichier doit être spécifié en arguments
system_group.so Supporte la recherche de groupe via getgrnam() et getgrid(). Il peut être utilisé dans le cas où des utilisateurs appartiennent à des groupes non-présents dans le vecteur groupe supplémentaire de l'utilisateur. Ce plugin n'a pas d'options

Format de log

   sudoers peut logger des évènements en utilisant syslog(3) ou un simple fichier. Le format est pratiquement identique dans les 2 cas.

Les commandes que sudo lance sont loggés en utilisant le format suivant:
date hostname progname: username : TTY=ttyname ; PWD=cwd ; USER=runasuser ; GROUP=runasgroup ; TSID=logid ; ENV=env_vars COMMAND=command

        date Date et heure à laquelle la commande a été lancée au format "MMM,DD,HH:MM:SS". Via syslog, le format de date est contrôllé par syslog. log_year permet d'inclure l'année
        hostname Le nom de l'hôte où sudo a été lancé. Seulement présent via syslog
        progname Le nom du programme, généralement sudo ou sudoedit. Seulement présent via syslog
        username Nom de login de l'utilisateur invoquant
        ttyname Nom court du terminal
        cwd Répertoire de travail courant
        runasuser Utilisateur sous lequel la commande est lancée
        runasgroup Groupe sous lequel la commande est lancée
        logid Identifiant de log I/O qui peut être utilisé pour rejouer la sortie des commande (log_input ou log_output doit être activé)
        env_vars variables d'environneent spécifiés sur la ligne de commande.
        command La commande exécutée

Entrées de log des commandes refusées

   Si l'utilisateur n'est pas autorisé à lancer la commande, la raison du refus suit le nom de l'utilisateur. Les raisons possibles sont:

        user NOT insudoers L'utilisateur n'est pas listé dans le fichie sudoers
        user NOT authorized on host L'utilisateur est listé dans le fichier sudoers mais n'est pas autorisé à lancer les commandes sur cet hôte
        command not allowed L'utilisateur est listé dans le fichier sudoers mais n'est pas autorisé à lancer la commande spécifiée
        3 incorrect password attemps L'utilisateur a échoué "passwd_trie" fois
        a password is required sudo -n a été spécifié, mais un mot de passe est requis
        sorry, you are not allowed to set the following environment variables L'utilisateur a spécifié des variables d'environnement sur la ligne de commande qui ne sont pas autorisés par sudoers

Entrées de log d'erreur

   Si une erreur se produit, sudoers log un message et, dans la plupart des cas, envoie un message à l'administrateur local via email. Les erreurs possibles incluent:

        parse error in /etc/sudoers near line N Erreur dans la configuration
        problem with defaults entries Options Defaults inconnus. N'empêche pas sudo de fonctionner
        timestamp owner (username): No such user l'utilisateur spécifié dans timestampowner n'a pas été trouvé dans la base de compte
        unable to open/read /etc/sudoers le fichier sudoers n'est pas accessible
        unable to open/read /etc/sudoers Le fichier /etc/sudoers n'existe pas
        /etc/sudoers is not a regular file Le fichier existe mais n'est pas un fichier régulier ou un lien symbolique
        /etc/sudoers is owned by uid N, should be 0 Le fichier n'est pas possédé par root
        /etc/sudoers is world writable Le fichier est accessible en écriture par tout le monde. Normalement il devrait être 0440
        /etc/sudoers is owned by gid N, should be 1 le fichier n'a pas le bon groupe.
        unable to open /var/run/sudo/ts/username sudoers n'arrive pas à lire ou créer le fichier d'horodatage pour l'utilisateur. Le répertoire parent doit être 0711
        unable to write to /var/run/sudo/ts/username sudoers n'arrive pas à écrire dans le fichier d'horodatage de l'utilisateur
        /var/run/sudo/ts is owned by uid X, should be Y Le répertoire ts est possédé par un utilisateur autre que timestampowner.
        /var/run/sudo/ts is group writable Le répertoire ts est accéssible en écriture par le groupe. Doit être 0700

Notes sur syslog

   Par défaut, sudoers log les messages via syslog. date, hostname et progname sont ajoutés par syslog, et non sudoers. ces informations peuvent donc varier d'un système à l'autre. La taille maximum des messages syslog varie également d'un système à l'autre. syslog_maxlen peut être utilisé pour changer la valeur par défaut de 980octets.

Notes sur le fichier de log

   Si logfile est activé, sudoers log dans un fichier local. sudoers utilise un format similaire à syslog, avec quelques différences importantes:

        - progname et hostname ne sont pas présents
        - si log_year est activé, l'année est incluse
        - Les lignes plus longue que loglinelen sont coupées et continées sur la ligne suivantes

Fichier de log d'E/S

   Quand le logging I/O est activé, sudo lance la commande dans un pseudo-tty et log toutes les E/S de l'utilisateur dans "iolog_dir" en utilisant un ID de session unique qui set inclus dans les logs, préfixé par "TSID=". Chaque log I/O est stocké dans un répertoire séparé qui contient les lignes suivantes:

        log Un fichier text contenant la date à laquelle la commande a été lancée, le nom de l'utilisateur invoquant, le nom de l'utilisateur cible, le nom du groupe cible, le terminal, le nombre de lignes et colonnes du terminal, le répertoire courant où la commande a été lancée et le chemin de la commande avec ses arguments.
        timing Un log de la quantité de temps, et le nombre d'octets, entre chaque entrées de log I/O.
        ttyin Entrée depuis le tty de l'utilisateur
        stdin Entrée depuis un pipe ou un fichier
        ttyout Sortie du pseudo-tty
        stdout Sortie standard dans un pipe ou redirigé dans un fichier
        stderr Erreur standard vers un pipe ou redirigé dans un fichier

   Tous les fichiers autre que log sont compressé au format gzip sauf si compress_io est désactivé. À cause du tampon, il n'est pas possible d'afficher les logs I/O en temps réel sauf si iolog_flush est utilisé.
  

   Vu que le log E/S de chaque session utilisateur est stocké dans un répertoire séparé, les utilitaires de rotation de log traditionnels ne peuvent pas être utilisés pour limiter le nombre de logs E/S. La manière la plus simple est d'utiliser l'option maxseq. Une fois la sequence atteinte, il est réinitialisé à 0 est sudoers tronque et réutilise les logs E/S existants.

Fichiers

/etc/sudo.conf Fichier de configuration de sudo
/etc/sudoers Fichier de stratégie de sudoers
/etc/group Fichier de groupes locaux
/etc/netgroup Liste des netgroups
/var/log/sudo-io Fichiers de log d'E/S
/var/run/sudo/ts Répertoire contenant les timestamps pour la stratégie de sécurité sudoers
/var/adm/sudo/lectured Répertoire contenant les fichiers de status de lecture pour la stratégie de sécurité sudoers
/etc/environment Environnement initial pour les système sans PAM

Notes de sécurité

- l'opération '!' ne doit pas être utilisé pour soustraire des commandes depuis AL, vu qu'il n'empêche pas d'exécuter ces commandes via un autre nom.
- fast_glob ne permet pas d'utiliser '!' correctement quand le chemin inclus du globbing.

Empêcher les échappements du shell

   Quand sudo exécute un programme, ce programme est libre de faire ce qu'il veut, incluant de lancer d'autres programmes. Cela peut être un problème de sécurité vu qu'il n'est pas commun pour un programme d'autoriser les échappements du shell, qui laisse un utilisateur bypasser le contrôle d'accès à sudo. Les programmes communs qui permettent les échappement du shell incluent les éditeurs, paginateurs, mails et terminaux. Il y a 2 approches à ce problème:

restrict Éviter de donner accès aux commande qui autorise un utilisateur à lancer des commandes arbitraires. De nombreux éditeurs ont des modes restreints qui désactive les échappements, bien que sudoedit est une meilleur solution aux éditeurs lancés via sudo.
noexec De nombreux systèmes qui supportent les librairies partagées ont la capacité de remplacer les fonctions par défaut en pointant une variable d'environnement (ex LD_PRELOAD) vers une librairie alternative. Dans de tels systèmes, la fonctionnalité noexec de sudo peut être utilisée pour éviter de lancer un programme qui exécute d'autres programmes.

Édition sécurisée

   Le plugin sudoers inclus sudoedit qui permet aux utilisateurs d'éditer les fichiers de manière sécurisée avec l'éditeur de leur choix. sudoedit est une commande intégrée et doit être spécifié dans le fichier sudoers dans chemin. Cependant, il peut prendre des arguments de ligne de commande. À la différence des autres commandes sudo, l'éditeur est lancé avec les permissions de l'utilisateur invoquant et avec l'environnement non-modifié.

   Les utilisateurs ne devraient jamais avoir les permissions sudoedit pour éditer un fichier qui réside dans un répertoire auquel l'utilisateur a accès en écriture, soit directement, ou via wildcard. Si l'utilisateur à ces droits, il peut remplacer le fichier avec un lien vers un autre fichier. Pour éviter cela, les liens symbolique ne sont pas suivis dans les répertoires en écriture (option sudoedit_checkdir).

Vérification du fichier timestamp

   sudoers vérifie le propriétaire de son répertoire d'horodatage et ignore le contenu du répertoire s'il n'est pas possédé par root, ou s'il est accessible en écriture par un utilisateur non-root.

   Bien que ce répertoire devrait être effacé au reboot, tous les systèmes ne contiennent pas de répertoire /var/run. Pour éviter de potentielles problèmes sudo ignore les fichiers timestamps antérieur au boot système.

   Certains systèmes avec des environnements graphiques permettent à des utilisateurs non-privilégiés de changer l'heure système. Vu que sudoers s'assure de l'horloge système pour la validation des horodatages, il peut être possible dans de tels systèmes qu'un utilisateur qui lance sudo pour une durée supérieur à timestamp_timeout en reculant l'horloge. Pour combattre cela, sudoers utilise une horloge monolitique pour ses horodatages si le système le supporte.

   Vu que les fichiers d'horodatage résident dans le système de fichier, ils peuvent survire à une session utilisateur. En résultat, un utilisateur peut être capable de se logger, lancer une commande avec sudo après s'être authentifié, se déconnecter, se reconnecter, et lancer sudo sans s'authentifier tant que l'horodatage est dans les 5 minutes. Quand l'option tth_tickets est activé, l'horodatage inclus le numéro de périphérique du terminal de l'authentification. Cela fournis une granularité par tth mais les horodatages continue à survivre entre les sessions. L'enregistrement d'horodatage inclus également l'ID de session du processus qui a été authentifié en dernier. Cela empêche les processus dans des session terminal différents d'utiliser le même enregistrement d'horodatage. Cela aide également à réduire les chances qu'un utilisateur soit capable de lancer sudo sans entrer un mot de passe en se déconnectant et revenant dans le même terminal.

Debuggage

   Le plugin sudoers support un framework de debuggage qui peut aider à suivre ce qu'il fait en interne s'il y a un problème. Cela peut être configuré dans le fichier sudo.conf

   sudoers utilise le même format de flag de debug que sudo. "subsystem@priority". Les priorités sont crit, err, warn, notice, diag, info, trace, debug. Les sous-systèmes suivant sont utilisés par sudoers:

alias traitements User_Alias, Runas_Alias, Host_Alias et Cmnd_Alias
all Match tous les sous-systèmes
audit Code d'audite Linux
auth Authentification utilisateur
defaults Paramètres Defaults
env Gestion de l'environnement
ldap sudoers basé sur LDAP
logging Support du logging
match Match des utilisateurs, groupes, hôtes et netgroups dans le fichier sudoers
netif Gestion des interfaces réseaux
nss Gestion nss dans sudoers
parser Parsing de fichier sudoers
perms Définition des permissions
plugin Équivalent de main pour le plugin
pty Code lié au pseudo-tty
rbtree redblack tree interne
sssd Sudoers basé sur sssd
util Fonctions utilitaires
^
03 juillet 2017

htmlpdflatexmanmd




sudoers.ldap

sudoers.ldap

Configuration LDAP sudo

   En plus du fichier standard sudoers, sudo peut être configuré via LDAP. sudo n'a plus besoin de lire sudoers.

   La configuration sudoers est contenue dans le conteneur LDAP ou=SUDOers. Sudo recherche d'abord l'entrée cn=defaults dans le conteneur et parcours les attributs sudoOption.

   L'équivalent d'un sudoers dans LDAP est un sudoRole. Il consiste des attributs suivants:

sudoUser Un nom d'utilisateur valide, #‹UID›, %‹group›, %#‹GID›, +‹netgroup›, ou %:‹groupe non unix› %:#‹ID de groupe non unix›
sudoHost Nom d'hôte, IP, réseau ou +‹netgroup d'hôte›. ALL match tous les hôte.
sudoCommand Nom d'une commande et ses arguments, optionnellement préfixé par '!'
sudoOption Identique aux options globales, mais spécifiques au sudoRole
sudoRunAsUser user sous lequel la commande est lancée
sudoRunAsGroup Groupe sous lequel la commande est lancée
sudoNotBefore horodatage de début de validité du sudoRole
sudoNotAfter horodatage de fin de validité du sudoRole
sudoOrder Les entrées sudoRole LDAP n'ont pas d'ordre. sudoOrder est un entier utilisé pour trier les entrées qui matchent.

Anatomie de la recherche LADP sudoers

   En recherchant un sudoer utilisant LDAP il y a seulement 2 ou 3 requêtes LDAP par invocation. La première requête sert à parcourir les options globales. Le second sert à matche le nom de l'utilisateur et les groupes auquel l'utilisateur appartient. Si aucun match n'est retourné pour l'utilisateur ou les groupes, une 3ème requête retourne toutes les entrées contenant les netgroups de l'utilisateur et les groupes non-unix et vérifie si l'utilisateur appartient à l'un d'entre-eux.

   Si les entrées timées sont activées avec la directive SUDOERS_TIMED, les requêtes LDAP incluent un sous-filtre qui limite la recherche aux entrées qui satisfont les contraintes de temps.

   Si la directive NETGROUP_BASE est présente, les requêtes sont effectuées pour déterminer la liste des netgroups auquel l'utilisateur appartient avant la requête sudoers. Cela permet d'inclure la liste des netgroups dans les requêtes sudoers de la même manière qu'avec les groupes unix. La 3ème requête n'est pas effectuées sauf si un plugin group est également effectuée. Les requêtes LDAP sont effectuées par sudo comme suit:

1. Match tous les enregistrement nisNetgroup avec un nisNetgroupTriple contenant l'utilisateur, l'hôte et le domaine NIS. La requête matche les entrées nisNetgroupTriple avec la forme courte ou longue du nom de domaine ou aucun nom d'hôte. Si le domaine NIS est définis, la requête matche seulement les entrées qui incluent de domaine ou pour lequel il n'y a pas de domaine présent. Si le domaine NIS n'est pas définis, un wildcard est utilisé pour matcher tous domaine pas prend en compte que le schéma NIS utilisé par les serveurs LDAP peuvent ne pas supporter les wildcard pour nisNetgroupTriple.
2. Les requêtes répétées sont effectuées pour trouver tout enregistrement nisNetgroup imbriqués avec une entrée memberNisNetgroup qui réfère à un enregistrement déjà matché.

Différence entre les sudoers LDAP et non-LDAP

   Il y a quelques subtiles différences dans la comportement de sudoers utilisant LDAP. La plus grosse différence étant l'ordre des entrées et attributs retournés, qui sont contrôlés par sudoOrder.

Configurer ldap.conf

   sudo lit le fichier /etc/ldap.conf. Seuls ces options sont supportés par sudo:

BIND_TIMELIMIT Spécifie le temps en secondes d'attente de connection à un serveur LDAP.
BINDDN Identité, sous la formate d'un DN, à utiliser pour effectuer les opérations LDAP
BINDPW Mot de passe de BINDDN
DEREF Spécifie comment déréférencer les alias
HOST Nom du serveur LDAP
KRB5_CCNAME Chemin du cache d'accréditifs Kerberos 5
LDAP_VERSION Version du protocole LDAP
NETGROUP_BASE DN de base pour les recherches des netgroups
NETGROUP_SEARCH_FILTER Filtre de recherche des netgroupes
PORT Port du serveur LDAP
ROOTBINDDN DN pour les opérations LDAP privilégiées
ROOTUSE_SASL Active l'authentification SASL pour les traitements privilégiés
SASL_AUTH_ID utilisateur SASL pour la connection LDAP
SASL_MECH Liste de mécanismes SASL à utiliser
SASL_SECPROPS Propriétés de sécurité SASL
SSL Active TLS pour les communications LDAP
SUDOERS_BASE DN de base pour les recherches SUDO
SUDOERS_DEBUG Niveaux de débuggage pour les requêtes sudo
SUDOERS_SEARCH_FILTER Filtre de recherche pour les requêtes sudo
SUDOERS_TIMED Spécifie si sudoNotBefore et sudoNotAfter sont évalués
TIMELIMIT Délai en secondes d'attente d'une réponse LDAP
TIMEOUT Délai en secondes d'attente d'une réponse depuis divers API LDAP
TLS_CACERTFILE Certificat de l'autorité
TLS_CACERTDIR Répertoire contenant les certificats d'autorité
TLS_CERT Certificat client
TLS_CHECKPEER Vérifie le certificat du serveur
TLS_KEY Clé privée du client
TLS_CIPHERS Liste d'algorithmes de chiffrement TLS à utiliser
TLS_KEYPW Mot de passe pour déchiffrer la clé privée. Peut être en base64 (base64:dGVzdA==)
TLS_RANDFILE Source d'entropie
URI URI du serveur LDAP
USE_SASL Active l'authentification SASL
ROOTSASL_AUTH_ID Utilisateur SASL à utiliser avec ROOTUSE_SASL

Configurer nsswitch.conf

   sudo consulte nsswitch.conf puor spécifie l'ordre de recherce sudoers. sudo recherche une ligne commençant par sudoers: et l'utilise pour déterminer l'ordre de recherche. Noter que sudo n'arrête pas sa recherche après le premier match et le dernier match a précédence. Les sources suivantes sont reconnus:

files Lit le fichier /etc/sudoers
ldap Lit sudoers depuis LDAP

   De plus, l'entrée [NOTFOUND=return] court-circuite la recherche si l'utilisateur n'a pas été trouvé dans la source précédente

Intergration avec sssd

   Dans les systèmes avec System Security Service Daemon il est possible d'utiliser SSSD pour cacher les règles sudoers LDAP. pour utiliser sssd, il faut utiliser sssd au lieu de ldap dans l'entrées sudoers dans /etc/nsswitch.conf. Noter que /etc/ldap.conf n'est pas utilisé par sssd.
^
03 juillet 2017

htmlpdflatexmanmd




sudoreplay

sudoreplay

Rejouer les logs de session sudo

   sudoreplay rejout ou liste les logs créés par sudo. Il peut jouer les sessions en temps réel, ou en ajustant la vitesse.

   L'ID doivrait être une séquence à 6 chiffres et lettres majuscules, ou un motif matchant l'option iolog_file. Quand une commande est lancée via sudo avec log_output activée dans le fichier sudoers, la chaîne TSID=ID est loggée via syslog ou dans le fichier de log. L'ID peut également être déterminé en mode list.

   En mode list, sudoreplay peut être utilisé pour trouver un ID de session basé sur des critères tels que l'utilisateur, le tty ou la commande lancée:

\n, \r Saute au prochain évènement, utile pour les longues pauses
' ' Met en pause la sortie, appuyer un n'importe quelle touche pour relancer
Réduit la vitesse par 2
Double la vitesse

OPTIONS

-d, --directory=dir Répertoire des logs de session au lieu du défaut /var/log/sudo-io
-f, --filter=[stdin|stdout,stderr,ttyin,ttyout] Sélection quels types E/S afficher.
-l, --list [expr] Active le mode liste. Dans ce mode, sudoreplay liste les sessions disponibles dans un format similaire au format de log sudo, trié par nom de fichier ou séquence de nombre. Si une expression de recherche est spécifiée, restreint les ID qui sont affichés. Une expression est composée des prédicats suivants:

        command ‹pattern› Évalue à vrai si la commande match le motif spécifié
        cwd ‹dir› Évalue à vrai si la commande a été lancée dans le répertoire spécifié
        fromdate ‹date› Évalue à vrai si la commande a été lancée à ou après cette date
        group ‹runas_group› Évalue à vrai si la commande a été lancée sous le groupe spécifié
        runas ‹runas_user› Évalue à vrai si la commande a été lancée sous l'utilisateur spécifié
        todate ‹date› Évalue à vrai si la commande a été lancée avant la date spécifiée
        tty ‹tty› Évalue à vrai si la commande a été lancée dans le terminal spécifié
        user ‹user› Évalue à vrai si la commande a été lancée par l'utilisateur spécifié

           Les prédicats peuvent être combinées en utilisant les opérateurs and, or et !, ainsi que les parenthèses.

-m, --max-wait Spécifie une limite maximum d'attente entre les frappes de touche ou la sortie de données.
-s, --speed Spécifie le facteur de vitesse.

Format de date

   La date et l'heure peuvent être spécifié de plusieurs manières: HH:MM:SS am MM/DD/CCYY timezone, HH:MM:SS am Month, Day Year timezone, CCYY-MM-DD HH:MM:SS, DD Month CCYY HH:MM:SS

   Les dates suivantes sont valides:

now
tomorrow
yesterday il y a 24 heure
2 hours ago
next Friday
last week
a fortnight ago L'heure courante, mais il y a 14 jours
10:01 am 9/17/2009
10:01 am
10 10 heure du matin
9/17/2009
10:01 am Sep 17, 2009

Exemples

Lister les sessions lancées par millert
sudoreplay -l user millert
Lister les sessions lancées par bob avec une commande contenant la chaîne vi
sudoreplay -l user bob command vi
Lister les sessions lancées par jeff qui match l'expression régulière
sudoreplay -l user jeff command '/bin/[a-z]*sh'
Lister les sessions lancées par jeff ou bob dans la console
sudoreplay -l ( user jeff or user bob ) tty console
^
07 juin 2010

htmlpdflatexmanmd




sum

sum

Calcul un checksum 16-bits pour chaque fichier donné. Affiche le checksum suivi par le nombre de blocks dans le fichier

OPTIONS

-r Utilise l'algorithme par défaut (compatible BSD) si -s est omis, n'a aucun effet.
-s, --sysv Calcul le checksum en utilisant un algorithme compatible system V.
^
05 novembre 2016

htmlpdflatexmanmd




swapon

swapon, swapoff

Activer/désactiver les périphérique et fichiers pour le paging et le swapping

   swapon est utilisé pour spécifier les périphériques dans lesquels le paging et le swapping sont placés. swapon est généralement lancé au boot. swapoff désactive des périphériques et fichiers spécifiés. Avec -a, désactive tous les périphériques swap connus (tel que trouvé dans /proc/swaps ou /etc/fstab)

OPTIONS

-a, --all Tous les périphériques marqués en 'swap' dans /etc/fstab disponibles, excepté ceux avec l'option noauto.
-d, --discard[=policy] Active l'abandon de swap, si le périphérique hébergeant le swap le supporte. Cela permet d'améliorer les performances dans certains disques SSD. 2 stratégies sont disponibles: 'once' effectue une opération discard en une seule fois pour tout le swap au swapon, 'pages' discard de manière asynchrone les pages de swaps libérés. Défaut: les 2 types sont activés. les options discard, discard=once, ou discard=pages peuvent être également utilisé dans /etc/fstab.
-e, --ifexists Ignore silencieusement les périphériques qui n'existent pas. l'option nofail dans fstab peut également être utilisé.
-f, --fixpgrz Réinitialise l'espace swap (mkswap) si la taille de page ne correspond pas au kernel courant.
-L label Utilise la partition qui a le label spécifié. (peut nécessiter l'accès à /proc/partitions)
-o, --options opts Spécifie les options swap au format fstab.
-p, --priority priority Spécifie la priorité du périphérique swap, entre -1 et 32767. idem à pri=value dans fstab
-s, --summary Affiche un sommaire d'utilisation du swap par périphérique. Équivalent à cat /proc/swaps. Déprécié en faveur de --show.
--show[=column] Affiche un table personnalisable des zones de swap.
--noheadings N'affiche pas d'en-tête dans la sortie de --show
--raw Affiche --show sans aligner les colonnes
--bytes Affiche la taille swap en octets dans --show
-U uuid Utilise la partition qui a l'uuid spécifié
-v, --verbose mode verbeux

Variables d'environnement

LIBMOUNT_DEBUG =all Activer la sortie de débogage de libmount.
LIBBLKID_DEBUG =all Activer la sortie de débogage de libblkid

Exemples

Créer un fichier d'1Gio:
dd if=/dev/zero of=/mnt/SWAP bs=1024 count=1048576
Initialiser le fichier
mkswap /mnt/SWAP
définis les permissions et propriétaires
chmod 0600 /mnt/SWAP
chown root:root /mnt/SWAP
Activer le swap avec une priorité de 5000
swapon -p 5000 /mnt/SWAP
^
04 juillet 2010

htmlpdflatexmanmd




sync

sync

Écrit les données en buffer sur le disque.

   Celà peut inclure les superblock modifiés, les inodes modifiés, les lecture/écriture retardées, ... sync effectue un simple appel système sync

^
03 février 2014

htmlpdflatexmanmd




sysctl

sysctl

Configuration du kernel en temp réel

OPTIONS

variable[=value] Définis une variable du kernel. nécessite l'option -w
-n, --values Affiche uniquement les valeurs
-e, --ignore Ignore les erreurs sur les clé inconnues
-N, --names Affiche uniquement les noms
-q, --quiet N'affiche pas les valeurs sur stdout
-w, --write Change une valeur
-p[FILE], --load[=FILE], -f[FILE] Charge les paramètres sysctl depuis le fichier spécifié (défaut: /etc/sysctl.conf)
-a, -A, --all, -X Affiche toutes les valeurs disponibles
--deprecated Inclus les paramètres dépréciés à --all
-b, --binary Affiche les valeurs sans newline
--system Charge les paramètres depuis les fichiers de configuration système
--pattern pattern Applique uniquement les paramètres qui matchent le pattern

Exemples

/sbin/sysctl -a
/sbin/sysctl -n kernel.hostname
/sbin/sysctl -w kernel.domainname="example.com"
/sbin/sysctl -p/etc/sysctl.conf
/sbin/sysctl -a --pattern forward
/sbin/sysctl -a --pattern forward$
/sbin/sysctl -a --pattern 'net.ipv4.conf.(eth|wlan)0.arp'
/sbin/sysctl --system --pattern '^net.ipv6'

Fichiers

/etc/sysctl.conf Fichier de configuration de systcl
/etc/sysctl.d/50-libreswan.conf /etc/sysctl.d/99-sysctl.conf Fichiers de configuration de systcl
/run/sysctl.d/*.conf Fichiers système de configuration de sysctl
/usr/local/lib/sysctl.d/*.conf Fichiers système de configuration de sysctl
/usr/lib/sysctl.d/10-default-yama-scope.conf /usr/lib/sysctl.d/50-coredump.conf /usr/lib/sysctl.d/50-default.conf /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf /usr/lib/sysctl.d/97-kde-baloo-filewatch-inotify.conf Fichiers système de configuration de sysctl
/lib/sysctl.d/10-default-yama-scope.conf /lib/sysctl.d/50-coredump.conf /lib/sysctl.d/50-default.conf /lib/sysctl.d/50-libkcapi-optmem_max.conf /lib/sysctl.d/97-kde-baloo-filewatch-inotify.conf Fichiers système de configuration de sysctl
^
03 février 2014

htmlpdflatexmanmd




sysctl.conf

sysctl.conf

Fichier de configuration de sysctl

   sysctl.conf est un fichier contenant des valeurs sysctl. La syntaxe est la suivante:

  #comment

  ; comment

  token = value

Exemple

Exemple de ligne dans sysctl.conf
kernel.modprobe = /sbin/modprobe
^
31 mars 2016

htmlpdflatexmanmd




systemd processus de démarrage

systemd processus de démarrage

Processus de démarrage du système

   Plusieurs composants sont impliqués dans le démarrage du système. Immédiatement après la mise sous tension, le BIOS fait une initialisation hardware minimale, et donne la main au chargeur de boot stocké dans un périphérique de stockage. Ce chargeur va ainsi invoquer un Kernel. Dans le cas de Linux, ce kernel extrait (optionnellement) et exécute une image disque initiale en RAM (initrd), tel que généré par dracut(8), qui recherche le système de fichier racine (possiblement en utilisant systemd). Une fois trouvé et monté, l'initrd donne le contrôle au gestionnaire du système (tel que systemd), qui est ensuite responsable pour gérer tout le harware restant, en montant tous les système de fihier nécessaires et en lancant tous les services configurés.

   Lors de l'arrêt, le gestionnaire stop tous les services, démonte tous les systèmes de fichiers, et optionnellement saute dans le code initrd qui démonte le système racine. Enfin, le système est arrêté.

Gestionnaire système au démarrage

   Au démarrage, le gestionnaire système dans l'image OS est responsable d'initialiser les systèmes de fichier, services et pilotes requis, qui sont nécessaires pour le système. Dans les systèmes systemd, ce processus est splitté en divers étapes qui sont exposés en tant qu'unités cible. Le processus de boot est hautement parallélisé pour que l'ordre dans lequel les unités cible soient atteints ne soit pas déterministe, mais adhère à une structure ordonnée limitée.

   Quand systemd démarre le système, il active toutes les unités qui sont des dépendances de default.target. Généralement, default.target est simplement un alias de graphical.target, ou multi-user.target, en fonction de la configuration du système. Pour forcer un ordre minimal entre les unités, un nombre d'unité cible sont disponibles.

   Le tableau suivant est une vue structurelle des unités et leur position dans le boot. Les unité en haut sont démarrées avant les unité plus bas.

schéma du démarrage du système
   Les unités cible qui sont communément utilisées comme cible de boot sont en italique. Ces unités sont un bon choix comme cible principal, par exemple en passant au kernel l'option systemd.unit=. en en lien default.target.

   timers.target est poussé par basic.targe de manière asynchrone. Cela permet aux unités timer de dépendre de services qui deviennent disponible plus tard.

Démarrage dans l'initrd

   L'implémentation du Ram disk initial peut être définis en utilisant systemd. Dans ce cas, le démarrage dans l'initrd suit la structure suivante.

   La cible par défaut dans l'initrd est initrd.target. Le processus de boot commence de la mème manière que le démarrage du gestionnaire système jusqu'à ce qu'il atteigne basic.target. De là, systemd approche la cible spéciale initrd.target. Si le périphérique root peut être monté dans /sysroot, l'unité sysroot.mount devient active et initrd-root-fs.target est atteinte. Le service initrd-parse-etc.service scanne /sysroot/etc/fstab pour un point de montage possible de /usr et les entrées additionnelles marquées avec l'option x-initrd.mount. Toutes les entrées trouvées sont montées sous sysroot, et initrd-fs.target est atteind. Le service initrd-cleanup.service isole vers initrd-switch-root.target, où les services de nettoyage peuvent être lancés. En dernier, initrd-switch-root.service est activé, causant le système à switch sont root.

schéma du initrd

Arrêt du système

   L'extinction du système avec systemd consiste également de divers unités cible avec une structure minimale:

arrêt du système
^
31 mars 2016

htmlpdflatexmanmd




systemd-journal-gatewayd

systemd-journal-gatewayd, systemd-journal-gatewayd.service, systemd-journal-gatewayd.socket

serveur http pour les événements journaux

   systemd-journal-gatewayd dessert les événements journaux sur le réseaux. Les clients doivent se connecter en utilisant HTTP, sur le port 19531 par défaut. Le programme est démarré par systemd et attend de reçevoir un simple socket. utiliser systemctl start systemd-journal-gatewayd.socket pour démarrer le service, et systemctl enable systemd-journal-gatewayd.socket

OPTIONS

--cert= Spécifie le chemin vers un fichier contenant un certificat serveur au format PEM.
--key= Spécifie le chemin vers un fichier contenant un clé serveur au format PEM.

URL supportées

/browse Naviguer interactivement
/entries[?option1&option2=value...] Récupérer les événements dans divers format. La partie Accept: de l'en-tête http détermine le format. La partie Range: de l'en-tête http détermine la plage d'événements retournés. Les paramètres GET peuvent être utilisés pour modifier les événements à retourner.
/machine Retourne une structure JSON décrivant la machine

Exemple:
{ "machine_id" : "8cf7ed9d451ea194b77a9f118f3dc446",
"boot_id" : "3d3c9efaf556496a9b04259ee35df7f7",
"hostname" : "fedora",
"os_pretty_name" : "Fedora 19 (Rawhide)",
"virtualization" : "kvm",
...}

/fields/FIELD_NAME Retourne une liste de valeurs de ce champs présent dans les logs

En-tête Accept

Accept: format Reconnaît les formats suivants:

        text/plain (défaut). sortie texte style syslog (comme journalctl --output short)
        application/json Entrées formattées en structures de données JSON (comme journalctl --output json)
        application/event-stream Entrées sérialisées en un flux binaire pour les sauvegardes et les transferts réseaux (comme journalctl --output export)

En-tête Range

Range: entries=cursor[[:num_skip]:num_entries] où cursor est une chaîne curseur, num_skip est un entier, num_entries est un entier non-signé.

Paramètres GET

follow Attend les nouveaux événements (comme journalctl --follow, excepté que le nombre d'evénements retourné n'est pas limité)
discrete Teste si le curseur spécifié réfère à une entrée dans le journal. Retourne simplement l'entrée
boot Limite les événements au boot courant du système (comme journalctl --this--boot)
KEY=match Matche les champs du journal.

Exemples

Récupère les événements du boot courant depuis le journal courant au format export
curl --silent -H'Accept: application/vnd.fdo.journal' 'http://localhost:19531/entries?boot'
Écoute pour les coredumps
curl 'http://localhost:19531/entries?follow&MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1'
^
31 mars 2016

htmlpdflatexmanmd




systemd-journal-remote

systemd-journal-remote

journaux sur le réseaux

   systemd-journal-remote est une commande pour recevoir les événements journaux et les stocker dans le journal. Les flux d'entrées sont au format export. Pour le transport sur le réseau, ce flux sérialisé est généralement transporté sur HTTPS.

Sources

   Les sources peuvent être soit actives ( systemd-journal-remote demande et pousse les données), ou passives (systemd-remote-journal attend une connexion puis reçoit les événements).

   systemd-journal-remote peut lire plus d'un flux à la fois. Il seront entrelacés dans le fichier de sortie. Dans le cas de connexions actives, chaque source est un flux, et dans le cas de connexions passives, chaque connexion peut résulter en un flux séparé. Les sockets peuvent être configurés en mode "accept" (seulement une connexion), ou "listen" ( plusieurs connexions).

   Quand il n'y a plus de connexions, et plus aucune ne peut être créée, systemd-journal-remote se termine.

   Les sources actives peuvent être spécifiées de la manière suivante:

- quand - est donné comme argument positionnel, les événements sont lus depuis d'entrée standard. Les autres arguments seront traités comme noms de fichier.
--url=ADDRESS Les événements sont récupérés en utilisant HTTP depuis ADDRESS. Cet url dervrait référer à la racine d'une instance systemd-journal-gatewayd.

   Les sources passives peuvent être spécifiées de la manière suivante:

--listen-raw=ADDRESS ADDRESS doit être une adresse utilisable pour ListenStream=.
--listen-http=ADDRESS, --listen-https=ADDRESS ADDRESS doit être soit un entier négatif, auquel cas il est interprété comme le numéro de descripteur de fichier, ou une adresse utilisable par ListenStream=. Dans le premier cas, le fd doit être hérité via $LISTEN_FDS/$LISTEN_PID. Dans le second cas, un serveur HTTP ou HTTPS sera lancé sur ce port.
$LISTEN_FDS systemd-journal-remote supporte le protocole $LISTEN_FDS/$LISTEN_PID. Les sockets ouverts hérités via l'activation socket se comportent comme ceux ouverts avec --listen-raw= décris plus haut, sauf s'il sont spécifiés pour lancer un serveur http(s).

Sinks

   L'emplacement du journal de sortie peut être spécifié avec -o out --output=. Pour les sources actives, cette options est requise.

--output=FILE Fichier journal à écrire. Le nom du fichier doit se terminer par .journal. Il sera créé s'il n'existe pas.
--output=DIR Créé les fichiers journaux sous le répertoire spécifié. Le répertoire doit exister.

   Si --output n'est pas utilisé, utilise /var/log/journal/remote. Dans le cas où le fichier de sortie n'est pas spécifié, les fichiers journaux seront créés dans le répertoire séléctionné. Les fichiers seront appelés remote-‹hostname›.journal. Dans le cas de sources active, le fichier de sortie doit toujours être donné explicitement.

OPTIONS

--split-mode (none ou host). Au départ, seul un fichier journal est utilisé. Pour la suite, un fichier séparé est utilisé, basé sur le nom d'hôte. Dans le cas de sources actives, le fichier de sortie doit toujours être donné explicitement et seul none est permis.
--compress, --no-compress Compresse les données dans le journal avec xz
--seal, --no-seal Signe périodiquement les données dans le journal en utilisant FSS
--getter=PROG --option1 --option2 Programme à invoquer pour récupérer les données. Le flux d'événements doit être généré sur la sortie standard (ex: --getter='curl "-HAccept: application/vnd.fdo.journal" https://some.host:19531/', ex: --getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://some.host:19531/' )

Exemples

Copier les événements journaux locaux dans un répertoire différent
journalctl -o export | systemd-journal-remote -o /tmp/dir -
Récupérer les événements depuis systemd-journal-gatewayd et les stocker dans /var/log/journal/some.host/remote-some-host.journal
systemd-journal-remote --url http://some.host:19531/
^
31 mars 2016

htmlpdflatexmanmd




systemd-journald

systemd-journald, systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-journald-audit.socket

Service de journalisation

   systemd-journald est un service système qui collecte et stocke des données de log. Il créé et maintient des journaux indexés basés sur les informations de logging qui sont reçus depuis une variété de sources:

- Logs du kernel, via kmsg
- Logs système simple, via syslog(3)
- Logs système structurés via l'api native sd_journal_print(4)
- Sortie est erreur standard des services système
- Enregistrements d'audit, via le sous-système d'audit

   Le service collecte implicitement de nombreux champs de métadonnées pour chaque messages de log de manière sécurisé et inaltérable. Les données de log collectées sont principalement du texte, mais peuvent également inclure des données binaire. Tous les objets stockés dans le journal peuvent avoir une taille allant jusqu'à 2^64-1 octets

   Par défaut, le journal stocke les données de logs dans /run/log/journal/. Vu que /run est volatile, les données de log sont perdue au redémarrage. Pour que les données soient persistantes, il suffit de créer /var/log/journal/, où systemd-journal va stocker les données:


mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal

Signaux

SIGUSR1 Demande au journal de vider /run dans /var. journalctl --flush utilise ce signal.
SIGUSR2 Demande une rotation immédiate des fichiers journaux. journalctl --rotate utilise ce signal.
SIGRTMIN+1 Demande que toutes les données de log non-écrite le soient sur disque. journalctl --sync utilise ce signal.

Kernel Command Line

   Quelques paramètre de configuration de journald.conf peuvent être passés sur la ligne de commande du kernel:

systemd.journald.forward_to_syslog=
systemd.journald.forward_to_kmsg=
systemd.journald.forward_to_console=
systemd.journald.forward_to_wall= Active/désactive la collecte des messages dans syslog, kmsg, la console système, ou wall

Contrôle d'accès

   Les fichiers journaux sont par défaut possédés et lisible par le groupe systemd-journal mais ne sont pas accessible en écriture. Ajouter un utilisateur à ce groupe lui permet de lire ces fichiers journaux.

   Par défaut, chaque utilisateur loggé a sont propre jeu de fichiers journaux dans /var/log/journal. Ces fichiers ne sont pas possédés par l'utilisateur, cependant, pour éviter que l'utilisateur puisse y écrire directement. Au lieu de ça, les ACL sont utilisées pour s'assurer que l'utilisateur a les accès en lecture seule.

Des utilisateurs et groupes additionnels peuvent obtenir l'accès aux fichiers journaux via les ACL. Par exemple, pour donner l'accès aux membres de wheel et adm:
setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/

   Noter que cette commande va mettre à jours les ACL pour les fichiers journaux existants et pour les futures fichiers journaux créés dans /var/log/journal/

Fichiers

/etc/systemd/journald.conf Configure le comportement de systemd-journald
/run/log/journal/machine-id/*.journal
/run/log/journal/machine-id/*.journal~
/var/log/journal/machine-id/*.journal
/var/log/journal/machine-id/*.journal~ systemd-journald écrit les entrées dans les fichiers avec le suffix .journal. Si le service n'est pas stoppé proprement, ou si des fichiers sont corrompus, il sonts renommés en utilisant le suffix .journal~, et systemd-journald écrit un nouveau fichier.
/dev/kmsg
/dev/log
/run/systemd/journal/dev-log
/run/systemd/journal/socket
/run/systemd/journal/stdout Sockets et autres chemins que systemd-journald écoute qui sont visible dans le système de fichier. De plus, journald peut écouter les évènements d'audit en utilisant netlink.
^
31 mars 2016

htmlpdflatexmanmd




systemd.journal-fields

systemd.journal-fields

Champs de journaux spéciaux

Champs utilisateurs

   Les champs utilisateur sont des champs qui sont directement passés par les clients et stockés dans le journal

MESSAGE= Message de l'entrée.
MESSAGE_ID= Identifiant 128bits pour reconnaître certains types de message.
PRIORITY= Une valeur de priorité entre 0 "emerg" et 7 "debug" formatté en chaîne.
CODE_FILE=
CODE_LINE=
CODE_FUNC= Code de l'emplacement qui a généré cette entrée, si connu. Contient le fichier source, le numéro de ligne et le nom de la fonction.
ERRNO= Numéro d'erreur Unix qui a causé cette entrée, s'il y a un. Contient la valeur numérique de errno(3) formattée en chaîne.
SYSLOG_FACILITY=
SYSLOG_IDENTIFIER=
SYSLOG_PID= Champs de compatibilité syslog contenant la facilité, l'identifiant et le PID du client

Champs de confiance

   Les champs préfixés par un '_' sont des champs de confiance, et sont ajoutés implicitement pas le journal et ne peuvent pas être altérés par le code client

_PID=
_UID=
_GID= Process, user et group ID du processus ayant généré l'entrée.
_COMM=
_EXE=
_CMDLINE= Nom, chemin de l'exécutable, et ligne de commande du processus ayant généré l'entrée
_CAP_EFFECTIVE= Les capacités effectives du processus ayant généré l'entrée
_AUDIT_SESSION=
_AUDIT_LOGINUID= Le session et login UID du processus ayant généré l'entrée, comme maintenu par le sous-système d'audit du kernel
_SYSTEMD_CGROUP=
_SYSTEMD_SESSION=
_SYSTEMD_UNIT=
_SYSTEMD_USER_UNIT=
_SYSTEMD_OWNER_UID=
_SYSTEMD_SLICE= Le chemin du cgroup dans la hiérarchie systemd, l'ID de session systemd, le nom de l'unité, le nom de l'unité de session utilisateur, l'UID propriétaire de la session systemd et l'unité slice systemd du processus ayant généré l'entrée
_SELINUX_CONTEXT= Le contexte de sécurité SELinux du processus ayant généré l'entrée
_SOURCE_REALTIME_TIMESTAMP= La date du message, s'il est connu, qui est différent de la date de réception par le journal, en microsecondes depuis epoch
_BOOT_ID= Le kernel boot ID
_MACHINE_ID= L'ID de machine de l'hôte, comme affiché dans machine-id(5)
_HOSTNAME= Le nom de l'hôte
_TRANSPORT= Décris comment l'entrée a été reçue

        audit Lus depuis le sous-système d'audit du kernel
        driver Pour les messages générés en interne
        syslog Reçus via le socket syslog local avec le protocole syslog
        journal Reçus via le protocole journal natif
        stdout Lu depuis la sortie standard ou l'erreur standard d'un service
        kernel Lus depuis le kernel

Champs du kernel

   Ces champs sont utilisés par les messages provenant du kernel

_KERNEL_DEVICE= Nom du périphérique kernel.
_KERNEL_SUBSYSTEM= Nom du sous-système du kernel
_UDEV_SYSNAME= Nom du périphérique kernel tel qu’affiché dans /sys
_UDEV_DEVNODE= Node du périphérique dans /dev
_UDEV_DEVLINK= Nom du lien pointant vers le node dans /dev

Champs à la demande d'un autre programme

   Les champs dans cette section sont utilisé par les programmes pour spécifier qu'ils sont loggés à la demande d'un autre programme ou unité.

COREDUMP_UNIT=
COREDUMP_USER_UNIT= Champs utilisés par systemd-coredump. Utilisé pour annoter les messages contenant les coredumps des unités system et session.
OBJECT_PID=PID PID du programme concerné par ce message
OBJECT_UID=
OBJECT_GID=
OBJECT_COMM=
OBJECT_EXE=
OBJECT_CMDLINE=
OBJECT_AUDIT_SESSION=
OBJECT_AUDIT_LOGINUID=
OBJECT_SYSTEMD_CGROUP=
OBJECT_SYSTEMD_SESSION=
OBJECT_SYSTEMD_OWNER_UID=
OBJECT_SYSTEMD_UNIT=
OBJECT_SYSTEMD_USER_UNIT= Champs additionnels ajoutés automatiquement par systemd-journald. Leur signification est similaire à leur homologue sans 'OBJECT', excepté que c'est le PID dans PID qui est décris, au lieu du processus qui a loggés le message

Champs adresse

   Durant la sérialisation dans les formats externe, tel que le format export ou JSON, les adresses des entrées du journal sont sérialisés dans des champs préfixés avec un double '__'.

__CURSOR= Le curseur pour l'entrée. Un curseur est un chaîne opaque qui décrit de manière unique la position d'une entrée dans le journal et est portable entre les machines, plateformes et fichiers journaux.
__REALTIME_TIMESTAMP= le wallclock time (CLOCK_REALTIME) où l’entrée a été reçue
__MONOTONIC_TIMESTAMP= Le temps monotonic (CLOCK_MONOTONIC) où l’entrée a été reçue
^
31 mars 2016

htmlpdflatexmanmd




table-incrontab

table-incrontab

tables pour incron

   un fichier incrontab contient des instructions pour le service incrond et a la forme générale: "lance cette commande sur ces événements fichier". Il y a 2 catégories de table: les tables système et les tables utilisateurs.

   Les tables système sont par défaut sous /etc/incron.d. Chaque utilisateur a sa propre table, et les commandes sont exécutés sous cet utilisateur. Les utilisateurs système peuvent avoir leur propre incrontab. Les fichiers incrontab sont lus quand le service incrond démarre et après tout changement.

   La forme générale est la suivante: ‹path› ‹mask› ‹command›

  où

path est un chemin absolu
mask est un masque d'événements (sous la forme symbolique ou numérique)
command Est une commande à exécuter

Symboles d'événements

IN_ACCESS accès au fichier
IN_ATTRIB Changement des méta-données
IN_CLOSE_WRITE Ficher ouvert en écriture fermé
IN_CLOSE_NOWRITE Fichier non ouvert en écriture fermé
IN_CREATE Fichier créé sous le répertoire
IN_DELETE Fichier supprimé sous le répertoire
IN_DELETE_SELF Fichier supprimé
IN_MODIFY Fichier modifié
IN_MOVE_SELF Fichier déplacé
IN_MOVED_FROM Ancien emplacement du fichier déplacé
IN_MOVED_TO Nouvel emplacement du fichier déplacé
IN_OPEN Fichier ouvert
IN_AL_EVENTS Tous les événements
IN_MOVE = ( IN_MOVED_FROM | IN_MOVED_TO )
IN_CLOSE = ( IN_CLOSE_WRITE | IN_CLOSE_NOWRITE )
IN_DONT_FOLLOW Ne pas déréférencer le chemin si c'est un lien symbolique
IN_ONESHOT surveille pour un seul événement
IN_ONLYDIR Surveille seulement si c'est un répertoire

Variables

   Les variables suivantes peuvent être utilisées dans le commandes:

$$ le caractère '$'
#@ Chemin surveillé
$# Événement
$% Flags d'événements (textuel)
$& Flags d'événements (numérique)

Exemples

Surveille tous les événements dans /tmp
/tmp IN_ALL_EVENTS abcd $@/$# $%
Supervise les accès dans /usr/bin
/usr/bin IN_ACCESS,IN_NO_LOOP abcd $#
Suprrvise les nouveaux fichiers créés sous home
/home IN_CREATE /usr/local/bin/abcd $#
Exemple en utilisant un masque numérique
/var/log 12 abcd $@/$#
^
05 juin 2010

htmlpdflatexmanmd




tac

tac

Copie chaque fichier ou l'entrée standard sur la sortie standard en renversant le contenus, les lignes par défaut.

   Les records sont séparés par des instances d'une chaîne (newline par défaut). Par défaut ce séparateur est attaché à la fin du record qui suit dans le fichier.

OPTIONS

-b, —before Le séparateur est attaché au début du record précédant dans le fichier
-r, —regex Traite la chaine séparateur comme expression régulière.
-s SEPARATOR, —separator=SEPARATOR Utilise SEPARATOR au lieu de newline
^
07 juin 2010

htmlpdflatexmanmd




tail

tail

Affiche la dernière partie de chaque fichier - 10 lignes par défaut

   Si plusieurs fichiers sont spécifiés, head affiche un en-tête d'un ligne affichant le nom du fichier sous la forme:

  ==› FILE NAME ‹==

OPTIONS

-c N, --bytes=N Affiche les N derniers octets au lieu de lignes. Si N commence avec un '+', affiche tout sauf les premières N octets de chaque fichier. N accepte un suffixe multiplicateur.
-f, --follow[=HOW] Boucle en continue la lecture des fichiers et affiche les caractères ajoutés. Il y'a 2 manières de spécifier comment vous voulez tracker des fichiers avec cette option, mais la différence est visible seulement si ces fichiers sont renommés ou supprimés :

        descriptor Continue de tracker la fin d'un fichiers même après qu'il soit 'unlinked', ne détecte pas si un fichier a été supprimé. C'est le mode par défaut.
        name Le fichier est réouvert périodiquement pour voir s'il a été supprimé ou recréer par d'autres programmes (utile pour les log gérés par logrotate). Si un fichier a été supprimé, il affiche un message.

OPTIONS

-F Correspond à --follow=name --retry
--retry Cette option est utile principalement avec l'option --follow=name. il réessaye d'ouvrir un fichier s'il a été supprimé.
--sleep-interval=NUMBER Change la durée d'attente entre les itérations,en secondes. A chaque itération, chaque fichier est vérifié pour voir si sa taille à changé.
--pid=PID Avec -f, permet de spécifier le PID
--max-unchanged-stats=N Si un fichier a été N ( défaut 5) itérations consécutives et que le fichier n'a pas changé, alors il 'open/fstat' le fichier pour déterminer si ce nom de fichier est encore associé avec la même paire device/inode-number.
N, --lines=N Sort les dernières N lignes. Identique à l'options -c
-q, --quiet, --silent N'affiche pas les en-têtes
-v, --verbose affiche toujours les en-têtes
^
07 mai 2016

htmlpdflatexmanmd




tailf

tailf

monitor un fichier de log

   Il fonctionne de manière similaire à tail -f, mais n'accède pas à un fichier quand il ne grandit pas. Cela a pour effet de ne pas mettre à jours la date d'accès du fichier, donc un flush du système de fichier ne se produit pas périodiquement quand aucune activité ne se produit.

OPTIONS

-n, --lines=‹number›, -‹number› Affiche les number dernière lignes. Défaut: 10
^
08 décembre 2016

htmlpdflatexmanmd




targets.conf

targets.conf

Configuration pour tgt-admin

include Permet d'inclure d'autres configurations
default-driver Pilote par défaut. Défaut: iscsi
iSNSServerIP 192.168.111.222 ip du serveur iSNS
iSNSServerPort 3205 Port du serveur iSNS
iSNSAccessControl On Active le contrôle d'accès iSNS
iSNS On ACtive le support de iSNS
ignore-errors Continue même si tgtadm quitte avec un code non-zéro
‹target qn.2008-09.com.example:server.target1› Définir un target

        backing-store|direct-store /dev/LVM/somedevice Spécifie le périphérique. Chaque ligne backing|direct-store déclare un LUN, dans l'ordre. Direct-store lis les paramètres du disque avec la commande sg_inq. Dans le cas de mix, les backing-store sont traitées avant les direct-store.
        initiator-address 192.168.100.1 Autorise les connections depuis l'ip spécifiée. Peut être spécifié plusieurs fois, uniquement global et non par LUN
        write-cache on|off Active le cache d'écriture
        incominguser someuser secretpass12 Définis un user/password
        outgoinguser userA secretpassA Définis un utilisateur sortant
        controller_tid 10 tid du contrôleur
        vendor_id MyCompany Inc. Spécifie un vendeur
        product_id Spécifie un produit
        product_rev Spécifie une révision produit
        MaxRecvDataSegmentLength 8192
        MaxXmitDataSegmentLength 8192
        HeaderDigest None
        DataDigest None
        InitialR2T Yes
        MaxOutstandingR2T 1
        ImmediateData Yes
        FirstBurstLength 65536
        MaxBurstLength 262144
        DataPDUInOrder Yes
        DataSequenceInOrder Yes
        ErrorRecoveryLevel 0
        IFMarker No
        OFMarker No
        DefaultTime2Wait 2
        DefaultTime2Retain 20
        OFMarkInt Reject
        IFMarkInt Reject
        MaxConnections 1 Paramètres supplémentaires, définis au niveau global et non par LUN
        ‹direct-store|backing-store /dev/sda› Permet de spécifier les paramètres par LUN

                vendor_id,product_id,product_rev Spécifie les informations du vendeur
                lun 1 Spécifie l'id pour le lun
                device-type cd Spécifie le type de périphérique
                write-cache on Active le cache d'écriture
                mode_page 8:0:18:0x10:0:0xff....
                bs-type aio type de backing-store (rdwr, aio, etc). Défaut: rdwr
                params element_type=4,start_address=500,quantity=3,media_home=/root/tapes
                params element_type=4,address=500,tid=1,lun=1 Paramètres supplémentaires pour le LUN
                scsi_id
                scsi_sn multipath-10
                sense_format
                removable
                online
                readonly
                path
                allow-in-user yes

        ‹/direct-store|backing-store›

‹/target›

^
03 février 2016

htmlpdflatexmanmd




taskset

taskset

Récupérer ou définir l'affinité processeur d'un processus

   taskset est utilisé pour récupérer ou définir l'affinité processeur d'un processus en cours d'exécution ou pour lancer une nouvelle commande avec une affinité processeur. L'affinité processeur est une propriété de l'ordonnanceur qui lie un processus à un ensemble de processeurs donné sur un système. L'ordonnanceur de Linux respectera l'affinité processeur et le processus ne s'exécutera sur aucun autre processeur. Notez que l'ordonnanceur Linux gère également l'affinité processeur dite naturelle: l'ordonnanceur essaie de maintenir les processus sur le même processeur tant que cela a du sens pour des raisons de performances. Ainsi, forcer une affinité processeur spécifique n'est utile que dans certaines applications.

   L'affinité du processeur est représentée par un masque binaire, avec le LSB correspondant au premier processeur logique et le MSB au dernier processeur logique. Tous les processeurs peuvent ne pas exister dans un système donné, mais un masque peut indiquer plus de processeurs que ceux qui sont présents. Un masque récupéré n'aura que les bits correspondants aux processeurs présents physiquement sur le système. Si un masque erroné est fourni (c'est-à-dire, un masque qui correspond à un processeur absent sur le système actuel) une erreur est alors renvoyée. Les masques sont généralement codés en hexadécimal.

Exemples

0x00000001 correspond au processeur n°0
0x00000003 correspond aux processeurs n°0 et 1
0xFFFFFFFF correspond au prosseurs n°0 à 31

OPTIONS

-a, --all-tasks Définis ou récupère l'affinité processeur de toutes les tâches (threads) d'un PID donné
-p, --pid Spécifie un PID existant
-c, --cpu-list Indisque une liste numérique de processeurs au lieu d'unn masque binaire. ex: 0,5,7,9-11

Permissions

   Un utilisateur peut modifier l'affinité d'un processus lui appartenant, mais doit posséder la capacité CAP_SYS_NICE pour modifier l'affinité d'un processus des autres utilisateurs. Un utilisateur peut récupérer l'affinité de n'importe quel processus.
^
31 mars 2016

htmlpdflatexmanmd




tayga

tayga

Service NAT64 sans état

   TAYGA est un service NAT64 sans état pour linux. En utilisant le pilote TUN, TAYGA reçoit les paquets IPv6 et IPv6 depuis la pile réseaux de l'hôte, les traduit dans l'autre protocole, puis envoie les paquets traduits à l'hôte en utilisant la même interface TUN.

   La traduction est conforme Internet-Draft draft-ietf-behave-v6v4-xlate-23, et le mappage d'adresse conforme à la rfc6052. Optionnellement, TAYGA peut être configuré pour mapper dynamiquement les hôte IPv6 en adresses conçues depuis un pool d'ipv4.

   En tant que NAT sans état, TAYGA nécessite un mappage un-à-un entre les adresse IPv4 et IPv6. Mapper plusieurs IPv6 en une simple IPv4 peut être fait en mappant les adresses IPv6 en adresse privées IPv4 avec TAYGA et en utilisant ensuite un NAT44 à état (tel que la cible MASQUERADE iptables) pour mapper les adresses privées IPv4 en une seule adresse IPv4.

   Sans --mktun ou rmtun, tayga se lance en tant que service. Les options --mktun et --rmtun instruisent TAYGA de créer ou détruire, respectivement, son périphérique TUN puis quitte immédiatement. Les périphériques TUN restent présents même quand TAYGA n'est pas lancé. Cela permet de configurer le réseau et le firewall avant de commencer la traduction d'adresses.

OPTIONS

-c, --config configfile Lit la configuration dans le fichier spécifié. Défaut: /etc/tayga.conf
-d mode debug, implique -n
-n, --nodetach Ne se détache pas du terminal
-u, --user userid uid après l'initialisation
-g, --group groupid gid après l'initialisation
-r, --chroot chroot dans le répertoire spécifié dans le fichier de configuration
-p, --pidfile pidfile Écrit son PID dans le fichier spécifié
^
31 mars 2016

htmlpdflatexmanmd




tayga.conf

tayga.conf

Fichier de configuration pour tayga

   À l'exception de la directive map, une seule instance de chaque directive ne peut apparaître dans ce fichier

tun-device device Nom de l'interface réseaux à créer par le kernel. Ce périphérique doit être créé avec tayga --mktun, par exemple
ipv4-addr ipv4_address Adresse IPv6 utilisé comme adresse source pour les erreurs ICMPv4 générés par le processus de traduction. Utilisé également pour les réponses aux ping
ipv6-addr ipv6_address Adresse IPv6 utilisé comme adresse source pour les erreurs ICMPv6 générés par le processus de traduction. Utilisé également pour les réponses aux ping
prefix ipv6_address/length Préfix NAT64 pour mapper les adresse IPv4 dans l'espace d'adressage IPv6. TAYGA effectue la traduction d'adresse comme spécifié dans la rfc6052, et seul les longueurs de préfixs permis dans ce documents sont permis
map ipv4_address ipv6_address Céé un mappage statique entre une adresse ipv4 et une adresse ipv6
dynamic-pool ipv4_address/length préfixe d'adresse contenant les adresses disponible à assigner aux hôte ipv6. length doit être 31 ou moins.
data-dir path Chemin absolus d'un répertoire où TAYGA devrait stocker ses fichiers de données. Également utilisé pour le chroot
strict-frag-hdr on|off|true|false|1|0 Flag pour contrôler si tayga ajoute les en-tête fragments aux paquets ipv6 qui ne nécessitent pas la fragmentation. la rfc6145 stipule que l'en-tête de fragmentation devrait être ajoutée à tous les paquets traduits quand l'émetteur n'a pas mis le flag DF, pour indiquer que l'émetteur permet la fragmentation et peut supporter Path MTU Discovery. strict-frag-hdr à true|on|1, l'en-tête est ajouté.

^
26 mai 2017

htmlpdflatexmanmd




teamd

teamd

Service de contrôle de périphérique réseau team

   teamd est un service qui contrôle un périphérique réseau team en temps réel. Il utilise libteam pour communiquer avec l'intance du périphérique team kernel via les sockets Netlinks.

OPTIONS

-d, --daemonise Met en tâche de fond
-k, --kill Termine une instance en cours de fonctionnement
-e, --check Retourne 0 si le service est déjà en cours de fonctionnement
-f filename, --config-file filename Fichier de configuration alternatif
-c text, --config text Utilise le format de configuration JSON. Si présent, -f est ignoré
-p filename, --pid-file filename Fichier PID à utiliser
-g, --debug Mode debug
-r, --force-recreate Force à re-créer le périphérique team s'il existe déjà
-o, --take-over Prend le contrôle du périphérique s'il existe déjà
-N, --no-quit-destroy S'assure que le périphérique team n'est pas supprimé une fois que teamd se termine
-t devicename, --team-dev devicename Utilise le périphérique team spécifié (remplace l'option device dans la configuration)
-n, --no-ports Démarre sans ports, même s'ils sont listés dans la configuration
-D, --dbus-enable Active l'interface D-Bus
-z address, --zmq-enable address Active l'interface ZMQ. Les formats possibles sont 'tcp://ip:port', 'ipc://path' et d'autres.
-U, --usock-enable Active l'interface socket UNIX. Activé par défaut
-u, --usock-disable Désactive l'interface socket UNIX
^
26 mai 2017

htmlpdflatexmanmd




teamd.conf

teamd.conf

Fichier de configuration de teamd

OPTIONS

device Nom du périphériques du nouveau périphérique team
debug_level Niveau de debug. 0 = désactivé
hwadr Adresse MAC souhaitée pour le nouveau périphérique
runner.name Nom du périphérique team:

        broadcast transmets les paquets via tous les ports
        roundrobin mode de transmission round-robin
        activebackup Sélection un port actif
        loadbalance load balancing passif, utilise une fonction de hashage BPF pour déterminer le port pour la transmission des paquets
        lacp. Pour un load balancing actif, les hash sont placés sur les ports disponible en tentant d'atteindre la balance parfaite Implément le protocole 802.3ad.

notify_peers.count Nombre de NA non-solicités et ARP gratuitous envoyés après qu'un port ait été activé/désactivé
notify_peers.interval interval en ms entre les bursts de paquets notify-peer
mcast_rejoin.count Monbre de bursts de requêtes rejoin de groupe multicast envoyés une fois qu'un port soit activé/désactivé
mcast_rejoin.interval Interval en ms entre les bursts des requêtes rejoin de groupe multicast
link_watch.name | ports.PORTIFNAME.link_watch.name Nom du surveillant de lien à utiliser:

        ethtool Utilise libteam pour obtenir les changements d'état de port
        arp_ping Les requêtes ARP sont envoyés via un port. Si une réponse ARP, le lien est considéré up
        nsna_ping Similaire, mais utilise Neighbor Solicitation/Advertisement IPv6.

ports Liste des ports, périphériques réseaux, à utiliser dans le périphérique team
ports.PORTIFNAME.queue_id ID de file auquel ce port doit être mappé

Options spécifiques au mode active-backup

runner.hwaddr_policy Définis la stratégie pour définis les adresses hardware et les périphériques ports du périphérique team durant sa durée de vie:

        same_all Tous les ports ont toujours la même adresse hardware
        by_active le team adopte l'adresse hardware du port actif
        only_active Seul le port actif adopte de l'adresse hardware du team

ports.PORTIFNAME.prio Priorité du port
ports.PORTIFNAME.sticky Flag indiquant sile port est sticky, ce port n'est pas désélectionné si un autre port avec une priorité plus élevée ou de meilleurs paramètres deviennent disponibles

Options spécifiques au mode load-balance

runner.tx_hash Liste des types de fragment qui devraient être utilisés pour le calcul du hash Tx du paquet:

        ethtool Utilise les adresses MAC source et destination
        vlan Utilise l'id de vlan
        ipv4 Utilise les adresses IPv4 source et destination
        ipv6 Utilise les adresses IPv6 source et destination
        ip Utilise les adresse IPv4 et IPv6 source et destination
        l3 idem
        tcp Utilise les ports TCP source et destination
        udp Utilise les ports UDP source et destination
        sctp Utilise les ports SCTP source et destination
        l4 Utilise les ports TCP, UDP, et SCTP source et destination

runner.tx_balancer.name Nom du balancer tx actif. (actuellement seulement 'basic')
runner.tx_balancer.balancing_interval En dixième de seconde. Interval périodique entre le rebalancing

Options spécifiques au mode lacp

runner.active Si active est true, les frames LACPDU sont envoyés avec les liens configurés périodiquement.
runner.fast_rate Spécifie le taux auquel demander au partenaire du lien de retransmettre les paquets LACPDU. À true, les paquets sont envoyés une fois par seconde, sinon, une fois toutes les 30 secondes
runner.tx_hash Idem pour le runner load-balancer
runner.tx_balancer.name idem
runner.tx_balancer.balancing_interval idem
runner.sys_prio priorité système (0-65535)
runner.min_ports Nombre minimum de ports qui doivent être actifs avant d'affirmer le porteur dans l'interface maître. 1-255
runner.agg_select_policy Sélection la stratégie de séléction de l'aggrégateur

        lacp_prio Aggrégrateur avec haute priorité en accord avec le standard LACP
        lacp_prio_stable Idem, mais ne remplace pas l'aggrégateur séléctionné s'il est utilisable
        bandwidth Aggrégateur avec la bande passante la plus élevée
        count Aggrégateur avec le plus grand nombre de ports
        port_config Aggréateur en accord avec les options prio et sticky.

ports.PORTIFNAME.lacp_prio priorité de port en accord avec le standard LACP
ports.PORTIFNAME.lacp_key Clé de port en accord avec le standard LACP

Options du surveillant ethtool

link_watch.delay_up | ports.PORTIFNAME.link_watch.delay_up délay en ms entre le lien devenant up, et la notification au runner
link_watch.delay_down | ports.PORTIFNAME.link_watch.delay_down Délai en ms entre le lien devenant down et la notification au runner

Options du surveillant arp ping

link_watch.interval | ports.PORTIFNAME.link_watch.interval Interval en ms entre les requêtes ARP
link_watch.init_wait | ports.PORTIFNAME.link_watch.init_wait délai en ms entre l'initialisation du surveilant et le premier ARP
link_watch.missed_max | ports.PORTIFNAME.link_watch.missed_max Nombre de réponse ARP non reçu max avant de reporter le lien down
link_watch.source_host | ports.PORTIFNAME.link_watch.source_host hostname source pour l'envoie des requêtes ARP
link_watch.target_host | ports.PORTIFNAME.link_watch.target_host hostname auquel envoyer les requêtes ARP
link_watch.validate_active | ports.PORTIFNAME.link_watch.validate_active Valide les paquets arp dans le ports actifs, sinon, tous les paquets entrants sont considéré comme de bonnes réponses
link_watch.validate_inactive | ports.PORTIFNAME.link_watch.validate_inactive Valide les paquets reçus sur les ports inactif. Sinon, tous les paquets entrants sont considérés comme de bonnes réponses
link_watch.send_always | ports.PORTIFNAME.link_watch.send_always Permet d'envoyer des requêtes arp également sur les ports inactifs

Options du surveillant NS/NA

link_watch.interval | ports.PORTIFNAME.link_watch.interval Interval en ms entre les envoies de paquets NS
link_watch.init_wait | ports.PORTIFNAME.link_watch.init_wait délai en ms entre l'initialisation du surveillant et le premier NS envoyé
link_watch.missed_max | ports.PORTIFNAME.link_watch.missed_max Nombre de NA manqué maximum, avant de reporter le lien down
link_watch.target_host | ports.PORTIFNAME.link_watch.target_host hostname auquel envoyer les paquets NS

Exemples


{
    "device": "team0",
    "runner": {"name": "roundrobin"},
    "ports": {"eth1": {}, "eth2": {}}
}

Configuration très basique
{
    "device": "team0",
    "runner": {"name": "activebackup"},
    "link_watch": {"name": "ethtool"},
    "ports": {
        "eth1": {
            "prio": -10,
            "sticky": true
        },
        "eth2": {
            "prio": 100
        }
    }
}

Cette configuration utilise le runner active-backup avec surveillant ethtool. le port eth2 a la plus haute priorité, mais le flag sticky s'assure que eth1 reste active.
{
    "device": "team0",
    "runner": {"name": "activebackup"},
    "link_watch": {
        "name": "ethtool",
        "delay_up": 2500,
        "delay_down": 1000
    },
    "ports": {
        "eth1": {
            "prio": -10,
            "sticky": true
        },
        "eth2": {
            "prio": 100
        }
    }
}

Similaire au précédent, mais les changements de lien ne sont pas propagés au runner immédiatement
{
    "device": "team0",
    "runner": {"name": "activebackup"},
    "link_watch": {
        "name": "arp_ping",
        "interval": 100,
        "missed_max": 30,
        "target_host": "192.168.23.1"
    },
    "ports": {
        "eth1": {
            "prio": -10,
            "sticky": true
        },
        "eth2": {
            "prio": 100
        }
    }
}

Cette configuration utilise un surveillant ARP
{
"device": "team0",
"runner": {"name": "activebackup"},
"link_watch": [
    {
        "name": "arp_ping",
        "interval": 100,
        "missed_max": 30,
        "target_host": "192.168.23.1"
    },
    {
        "name": "arp_ping",
        "interval": 50,
        "missed_max": 20,
        "target_host": "192.168.24.1"
    }
],
"ports": {
    "eth1": {
        "prio": -10,
        "sticky": true
    },
    "eth2": {
        "prio": 100
        }
    }
}

Similaire, mais 2 surveillant sont utilisés
{
    "device": "team0",
    "runner": {
        "name": "loadbalance",
        "tx_hash": ["eth", "ipv4", "ipv6"]
    },
    "ports": {"eth1": {}, "eth2": {}}
}

Configuration passive hash-based
{
    "device": "team0",
    "runner": {
        "name": "loadbalance",
        "tx_hash": ["eth", "ipv4", "ipv6"],
        "tx_balancer": {
            "name": "basic"
        }
    },
    "ports": {"eth1": {}, "eth2": {}}
}

Configuration active load-balancing
{
    "device": "team0",
    "runner": {
        "name": "lacp",
        "active": true,
        "fast_rate": true,
        "tx_hash": ["eth", "ipv4", "ipv6"]
    },
    "link_watch": {"name": "ethtool"},
    "ports": {"eth1": {}, "eth2": {}}
}
^
26 mai 2017

htmlpdflatexmanmd




teamdctl

teamdctl

Outil de contrôle du service team

   teamdctl permet d'interagir avec une instance teamd. Il utilise par défaut un socket de domaine unix, mais utilise également D-Bus pour s'assurer des opérations dans tous les environnements

OPTIONS

-v, --verbosity Mode verbeux
-o, --oneline Force la sortie sur une seule ligne si possible
-D, --force-dbus Force l'utilisation de D-Bus
-Z address, --force-zmq address Force l'utilisation de l'interface ZMQ ("tcp://ip:port", "ipc://path" etc.)
-U, --force-usock Force l'utilisation du socket UNIX.

Commandes

config dump Dump la config JSON teamd
config dump noports idem sans la section ports
config dump actual Dump la config JSON actuelle
state dump | state dump le document d'état JSON de teamd
state view Affiche l'état de teamd depuis de document d'état JSON
state item get state_item_path Affiche l'élément
state item set state_item_path value Définis un paramètre. N'est valable que pour les éléments suivants:

        setup.debug_level Niveau de débuggage
        ports.PORTIFNAME.runner.aggregator.selected Disponible pour lacp. permet de sélectionner l'aggrégateur.
        runner.active_port pour activebackup, sélectionne le port actif

port add portdev Ajouter un périphérique au team
port remove portdev Supprime un périphérique au team
port present portdev Vérifie la présence d'un périphérique au team
port config update portdev portconfig_string Met à jours la configuration de périphérique du team
port config dume portdev Dump la configuration du périphérique sur stdout
^
26 mai 2017

htmlpdflatexmanmd




teamnl

teamnl

Outil d'interface Netlink

   teamnl est un outil permettant l'interaction avec un périphérique team via l'interface Netlink du pilote team. cet outil sert principalement pour debugger.

OPTIONS

-p ifname, --port-name ifname Sélectionne les options par port
-a index, --array_index index Sélectionne l'option de l'index fournis

Commandes

port Dump les ports du team
option dump les options du team
getoption opt_name Affiche l'option spécifiée
setoption opt_name opt_value Définis l'option spécifiée
monitor opt_style Supervise les changements faits dans les options, ports, et interfaces. Style peut être 'changed' ou 'all'
^
07 juillet 2010

htmlpdflatexmanmd




tee

tee

Copie stdin sur stdout et dans des fichiers

   tee copie l'entrée standard sur la sortie standard et également dans les fichiers donnés. Si un fichier n'existe pas, il est créé. Si un fichier existe déjà, les données qu'il contient sont écrasés sauf si -a est spécifié. Un argument de fichier - envois une autre copie de stdin sur stdout.

OPTIONS

-a, --append Ajoute les données à la fin des fichiers donnés au lieu d'écraser leur contenu
-i, --ignore-interrupts ignore les signaux d'interruption

Exemples

télécharger un iso, et calculer son checksum e, le sauvegardant dans un fichier
wget -O - http://example.com/dvd.iso | tee ›(sha1sum › dvd.sha1) › dvd.iso
ou
wget -O - http://example.com/dvd.iso | tee dvd.iso | sha1sum › dvd.sha1
la même commande mais étend le calcul pour les checksum md5 et sha1 en parallèle
wget -O - http://example.com/dvd.iso | tee ›(sha1sum › dvd.sha1) ›(md5sum › dvd.md5) › dvd.iso
créer une copie compréssée du contenu d'un pipe et affichage avec un outil graphique sans tee
du -ak | gzip -9 › /tmp/du.gz ; gzip -d /tmp/du.gz | xdiskusage -a
avec tee
du -ak | tee ›(gzip -9 › /tmp/du.gz) | xdiskusage -a
^
31 mai 2010

htmlpdflatexmanmd




telinit

telinit

Lié à init. Signal à init d'effectuer une action

OPTIONS

0,1,2,3,4,5,6 dit à init de passer au runlevel spécifié
a,b,c dit à init de traiter seulement les entrées de /etc/inittab ayant un runlevel a, b ou c.
Q, q dit à init de relire /etc/inittab
S, s dit à init de passer mode simple utilisateur
U, u dit à init de se ré-exécuter lui même. Il ne ré-examine pas /etc/inittab. Le runlevel doit être un de Ss0123456 sinon la requête est ignorée.
-t telinit peut dire à init combien de temps il devrait attendre entre l'envoie de SIGTERM et de SIGKILL.(5 secondes par défaut)
-e  dit à init de changer d'environnement pour les processus qu'il gère. L'argument soit sous la forme VAR=VAL, ou sous la forme VAR, qui supprime la variable VAR.
^
06 juillet 2010

htmlpdflatexmanmd




test

test

Évaluation d'expressions

   test retourne un status de 0 ou 1 en fonction de l'évaruation de l'expression. Chaque partie de cette expression doit être un argument séparé. test a une forme alternative qui utilise [ et ] au lieu de test.

test sans argument retourne false
test avec un seul argument qui vaut null retourne false, true sinon

Test des types de fichier

-b FILE vrai si FILE existe et est un périphérique spécial block
-c FILE vrai si FILE existe et est un périphérique spécial caractère
-d FILE vrai si FILE existe et est un répertoire
-f FILE vrai si FILE existe et est un fichier régulier
-h FILE
-L FILE vrai si FILE existe et est un lien symbolique, ce test ne déréférence pas FILE.
-p FILE vrai si FILE existe et est un pipe
-S FILE vrai si FILE existe et est un socket
-t FD vrai si FD est un descripteur de fichier qui est associé avec un terminal

Test des permissions d'accès

-g FILE vrai si FILE existe et a son bit set-group-ID mit
-k FILE vrai si FILE existe et a son sticky bit mis
-r FILE vrai si FILE existe et le droit en lecture
-u FILE vrai si FILE existe et et son bit set-user-ID mis
-w FILE vrai si FILE existe et le droit en écriture
-x FILE vrai si FILE existe et le droit en exécution
-O FILE vrai si FILE existe et et son propriétaire est l'utilisation courant
-G FILE vrai si FILE existe et et son group propriétaire est le group courant.

Test des caractéristiques de fichier

FILE vrai si FILE existe
-s FILE vrai si FILE existe et a une taille supérieur à 0
FILE1 -nt FILE2 vrai si FILE1 est plus récent que FILE2, ou si FILE1 existe mais pas FILE2 (basé sur le mtime)
FILE1 -ot FILE2 vrai si FILE1 est plus ancien que FILE2, ou si FILE2 existe mais pas FILE1 (basé sur le mtime)
FILE1 -ef FILE2 vrai si FILE1 et FILE2 ont le même numéro d'inode et de périphérique (ex : lien dur)

Test de chaînes

-Z STRING vrai si la longueur de STRING est 0
STRING vrai si la longueur de STRING est différente de 0
STRING1 = STRING2 vrai si les 2 chaînes sont équivalentes
STRING1 != STRING2 vrai si les 2 chaînes sont différentes

Test numérique

ARG1 -eq ARG2
ARG1 -ne ARG2
ARG1 -lt ARG2
ARG1 -le ARG2
ARG1 -gt ARG2
ARG1 -ge ARG2

Connections pour test

! EXPR vrai si EXPR est faux
EXPR1 -a EXPR2 vrai si les 2 sont vrai
EXPR1 -o EXPR2 vrai si l'une des 2 est vrai
^
19 juillet 2010

htmlpdflatexmanmd




tftp

tftp

Client tftp simple

   tftp est un client tftp simple. il accepte une option, l'adresse du serveur tftp. Une fois lancé, il reconnais les options suivante:

? commande-name Affiche une aide sur la commande
ascii mode ascii
binary mode binaire
connect host-name [port] Spécifie le serveur tftp et le port.
get filename
get remotename localname
get file1 file2 ... fileN lit un ou plusieurs fichiers. Peut être spécifié également sous la forme hosts:filename
mode Mode de transfert: ascii ou binary. defaut : binary
put file
put localfile remotefile
put file1 file2 ... fileN remote-directory Écrit un ou plusieurs fichier sur le serveur. Peut être spécifié également sous la forme hosts:filename.
quit termine un éventuel transfert et quit.
rexmt retransmission-timeout Définit le timeout de retransmission en secondes.
status Affiche le status courant
timeout total-transmission-timeout Définit le time de transmission total, en secondes
verbose mode verbeux

^
19 juillet 2010

htmlpdflatexmanmd




tftp-hpa

tftp-hpa

Client tftp

OPTIONS

-4 Connexion IPv4 uniquement
-6 connexion IPv6 uniquement
-c command exécute la commande.
-l mode littéral par défaut. utilisé pour éviter de traitement spécial de ':' dans les noms de fichier
-m mode mode de transfert
-R port:port force le port à être dans la plage spécifié
-v mode verbeux
-V affiche le numéro de version et la configuration courante.

Commandes

? commande-name Affiche une aide sur la commande
help affiche une aide sur les commandes
ascii mode ascii
binary mode binaire
connect host-name [port] Spécifie le serveur tftp et le port.
get filename
get remotename localname
get file1 file2 ... fileN lit un ou plusieurs fichiers. Peut être spécifié également sous la forme hosts:filename
literal passe en mode literal.
mode Mode de transfert: ascii ou binary. defaut : binary
put file
put localfile remotefile
put file1 file2 ... fileN remote-directory Écrit un ou plusieurs fichier sur le serveur. Peut être spécifié également sous la forme hosts:filename.
quit termine un éventuel transfert et quit.
rexmt retransmission-timeout Définit le timeout de retransmission en secondes.
status Affiche le statut courant
timeout total-transmission-timeout Définit le time de transmission total, en secondes
verbose mode verbeux
^
19 juillet 2010

htmlpdflatexmanmd




tftpd

tftpd

Serveur tftp simple

   tftpd est un serveur tftp simple. Sa configuration se trouve dans /etc/inetd.conf. Sont répertoire root est /tftpboot par défaut.

OPTIONS

-n  supprimer les acknowledgement négatifs des requêtes pour les noms de fichiers qui n'existent pas.
-s Tous les noms de fichier absolus sont traités comme s'ils étaient précédées par le premier argument de répertoire, ou /tftpboot sinon.
Pour les paramètres de tftpd dans /etc/ined.conf, voir inetd
^
19 juillet 2010

htmlpdflatexmanmd




tftpd-hpa

tftpd-hpa

Serveur tftp

   in.tftpd est un serveur tftp lancé patr inetd ou en démon.

OPTIONS

-l Lance le serveur en mode démon.
-L similaire à -l mais le place en tâche de fond
-a [address][:port] Spécifie l'adresse:port d'écoute. écoute sur toutes les interfaces par défaut.
-c Autorise de créer des nouveaux fichiers.
-s Définit le répertoire racine
-u user Définit l'identité du serveur.défaut nobody
-U umask Définit le umask pour les fichiers crées. défaut : 0
-p ne vérifie pas les permissions
-t timeout Détermine le timeout par défaut avant de terminer une connexion. défaut : 900 secondes
-T timeout détermine le timeout en microsecondes avant que le premier paquet soit retransmis. défaut : 1000000 (1sec)
-m remap-file Spécifie l'utilisation du remappage de fichier. remap-file est un fichier contenant les règles de remappage.
-v définit le niveu de log. peut être spécifié plusieurs fois pour augmenter la verbosité.
-r tftp-option indique que l"option donné spécifique RFC2347 ne doit jamais être accepté.
-B max-block-size Spécifie la taille de block maximum permise. de 512 à 65464. Il est recommandé de définir cette valeur la plus proche de MTU - 32. pour un MTU de 1500 : 1468.
-R port:port force le port du serveur à être dans la plage spécifiée.
-V affiche la version et la configuration courante.

Négociation d'option rfc2347

blksize définit la taille de block maximum
blksize2 idem mais restreint la réponse possible en puissance de 2 (max 32768)
tsize Reporte la taille du fichier qui est transféré
timeout définit le temps avant de retransmettre un paquet, en secondes.
utimeout idem mais en microsecondes

Remappage de fichier

   l'option -m spécifie un fichier contenant des règles de remappage. Chaque ligne qui ne commençant pas par un '#' contenant un opération; une expressions régulière style egrep; et optionnellement un pattern de remplacement. L'opération est effectuée si l'expression correspond.

  L'opération peut être une combinaison des lettres suivantes:

r remplace la sous-chaîne qui correspond à regex par le pattern de remplacement.
g répète cette règle tant que le règle correspond. toujour utilisé avec r
i insensible à la casse. défaut : sensible à la casse
si cette règle correspond, termine le traitement de la règle après avoir exécuté la règle.
a si cette règle correspond, refuse la requête
G cette règle s'applique à GET uniquement
P Cette règle s'applique à PUT uniquement
inverse le sense de la règle

   Les séquences d'échappement suivant sont reconnus pour le pattern de remplacement:

\0 la chaîne entière correspondant par l'expression
\1 à \9 les chaînes correspondantes des 9 premières sous-expressions entre parenthèses, \( ... \)
\i l'adresse IP du client sous la forme 192.168.0.1
\x idem en hexa. exemple : C00002A9
\witespace espace litéral
\# '#'
\U met en majuscule toutes les lettres suivantes
\L met en minuscule toutes les lettres suivantes
\E Annule l'effet de \L et \U

Sécurité

   Dû au manque de sécurité de tftp, le serveur autorise seulement les fichier accessible en lecture a tous (o+r) à moins que -p ne soit spécifié. les fichiers ne peuvent être écrit que s'ils existent déjà et sont accessible en écriture par tous, à moins que -c ne soit spécifié. s'il est compilé pour, le serveur va vérifier la base hosts_access pour les informations de contrôle d'accès, ce qui peut être lent.

  Le serveur devrait être lancé sous un utilisateur avec le moins de privilèges possibles. Un répertoire racine devrait être également spécifié.

Exemples

exemple de configuration (/etc/default/tftpd-hpa):
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot -u nobody -t 100 -v"
^
08 décembre 2016

htmlpdflatexmanmd




tgt-admin

tgt-admin

Outil de configuration de target SCSI

OPTIONS

-e, --execute Lit /etc/tgt/targets.conf et exécute les commandes tgtadm. Si le target existe déjà, ne le traite pas.
-d, --delete ‹value› Supprime les targets séléctionnés ou tous les targets. Le target n'est enlevé qui si aucun initiator n'est connecté
--offline Définis les targets spécifiés à l'état offline
--ready Définis les targets spécifiés à l'état ready
--update ‹value› Met à jours tous les targets ou les targets spécifiés. Uniquement si aucun initiateur n'est connecté
-s, --show Afficher tous les targets
-C, --control-port ‹NNNN› Spécifie le port de contrôle de l'instance tgtd à utiliser
--ignore-errors Continue même si tgtadm quitte avec un code non-zéro
-f, --force Force certaines opérations même si le target est utilisé
--dump Dump la configuration tgtd courante (n'inclus pas les paramètres détaillés)
-v, --verbose Mode verbeux (affiche le commandes tgtadm utilisées)

Fichiers

/etc/tgt/targets.conf Fichier de configuration de tgt-admin
^
08 décembre 2016

htmlpdflatexmanmd




tgt-setup-lun

tgt-setup-lun

script helper qui créé un target, ajoute un périphérique au target, et définis les initiators qui peuvent s'y connecter

Créer un target qui utilise /dev/sdb1 et autorise les connexions depuis 192.168.10.81
tgt-setup-lun -d /dev/sdb1 -n my_target 192.168.10.81
Créer un target qui utiliser /dev/sdb1 et autorise les connexions depuis 192.168.10.81 et 192.168.10.82
tgt-setup-lun -d /dev/sdb1 -n my_target 192.168.10.81 192.168.10.82

^
08 décembre 2016

htmlpdflatexmanmd




tgtadm

tgtadm

Utilitaire d'administration de target SCSI

OPTIONS

-C, --control-port ‹port› Port de connexion à tgtd
-v, --blocksize ‹size› Spécifie la taille de block sur laquelle opérer
-Y, --device-type ‹type› En créant un LUN, spécifie le type de périphérique à créer. Défaut: disk

        disk Émule un périphérique disque
        tape Émule un lecteur cassette
        ssc alias de tape
        changer Émule un périphérique changeur
        pt type passthrough pour exporter un périphérique /dev/sg

-E, --bstype ‹type› En créant un LUN, spécifie le type de stockage à utiliser:

        rdwr Utiliser l'E/S normal.
        aio Mode E/S asynchrone
        rbd Utilise un périphérique block RADOS Ceph
        sg type spécial pour les périphériques passthrough
        ssc Type spécial pour l'émulation tape

--lld ‹driver› --op new --mode target --tid ‹id› --targetname ‹name› ajoute un nouveau target
--lld ‹driver› --op delete --mode target --tid ‹id› Supprime le target ‹id›.
--lld ‹driver› --op delete --force --mode target --tid ‹id› Force la suppression du target ‹id›
--lld ‹driver› --op show --mode target Affiche toutes les target
--lld ‹driver› --op show --mode target --tid ‹id› Affiche les paramètres du target ‹id›
--lld ‹driver› --op new --mode logicalunit --tid ‹id› --lun ‹lun› --backing-store ‹path› --bsopts=‹backing store options› Ajoute un lun au target ‹id›. ‹path› doit être des périphériques block ou des fichiers ou une image RBD. lun0 est réservé par un périphérique spécial automatiquement créé
--lld ‹driver› --op delete --mode logicalunit --tid ‹id› --lun ‹lun› Supprime le LUN qu'un target ‹id› possède
--lld ‹driver› --op bind --mode target --tid ‹id› --initiator-address ‹address› Ajoute l'adresse à la liste d'accès au target ‹id›. Les initiators avec l'adresse peuvent accéder au target. ALL autorise l'accès à tous les initiators
--lld ‹driver› --op bind --mode target --tid ‹id› --initiator-name ‹name› Ajoute le nom de l'initiator à la liste d'accès du target ‹id›. Les initiators avec ces noms peuvent y accéder
--lld ‹driver› --op unbind --mode target --tid ‹id› --initiator-address ‹address› Supprime l'adresse d'une liste d'accès du target
--lld ‹driver› --op unbind --mode target --tid ‹id› --initiator-name ‹name› Supprime le nom de l'initiator de la liste d'accès du target
--lld ‹driver› --op update --mode target --tid ‹id› --name=‹parameter› --value=‹value› Définis/change la valeur d'un ou plusieurs paramètres de target
--lld ‹driver› --op update --mode logicalunit --tid ‹id› --lun ‹id› --params parameter=value‹,...› Définis/change la valeur d'un ou plusieurs paramètres LUN
--lld ‹driver› --op start --mode lld Démarre le lld spécifié sans redémarrer le processus tgtd.

Paramètres LUN

   Ces paramètres sont seulement applicables avec "--mode logicalunit"

vendor_id=‹string› Définis le Vendor Identification reporté par un LUN dans une donnée INQURY
product_id=‹string› Définis le Product Identification reporté par un LUN dans une donnée INQURY
product_rev=‹string› Définis le Product Revision reporté par un LUN dans une donnée INQURY
removable=‹ 0|1 › Peut être utilisé pour changer le paramètre par défaut pour le flag removable.
sense_format=‹ 0|1 › Contrôle le format du sens des données que le périphérique retourne. 0 = classique, 1 = descripteur Support
online=‹ 0|1 › Contrôle si le périphérique est en ligne ou non
mode_page=‹byte-string› Définis les pages de mode spécifique pour le périphérique et le contenu de page de mode.
readonly=‹ 0|1 › Définis le flag read-only d'un LUN
thin_provisioning=‹ 0|1 › Contrôle le provisionning pour le LUN. Ne s'applique qu'aux périphérique disk. Uniquement pour les LUN stockés dans des systèmes de fichier qui supportent FALLOC_FL_PUNCH_HOLE

Paramètres LUN SMC

   Ces paramètres ne s'appliquent qu'aux lun qui sont de type "changer".

element_type=‹ 1|2|3|4 › Contrôle le type d'élément d'un slot dans le jukebox/vtl.

        1 Medium Transport
        2 Storage Element
        3 Import/Export Element
        4 Data Transfer device (CD drive, tape drive, MO drive etc)

address=‹ 1-65535 › Utilisé pour créer/opérer sur un slot particulier
start_address=‹ 1-65535 ›,quantity=‹ 1--65535 › Utilisé pour créer/opérer sur une plage de slots.
sides=‹ 1|2 › Spécifie si le média a 1 ou 2 faces pour maintenir les données.
clear_slot=‹ 1 › Effacer un élément de stockage et supprimer tout média présent. Une fois terminé, le stockage est marqué vide.
barcode=‹string› Utilisé pour assigner un code barre à un élément. max 10 caractères
volume_tag=‹string› Permet d'assigner un tag à un volume. max 32 caractères
media_home=‹string› Spécifie un répertoire où le média virtuel pour les éléments périphérique dvd/tape sont stockés

Périphériques passthrough

   En plus de l'émulation de périphérique TGTD supporte également d'utilisation de périphériques sg sur l'hôte et l'export via un type de périphérique spécial passthrough

--bstype=sg Spécifie qu'un périphérique SG est utilisé
--device-type=pt Spécifie que le type passthrough est utilisé
--backing-store=‹/dev/sg4› Spécifie quel périphérique exporter via TGTD
--bsoflags={direct|sync} Spécifie des flags supplémentaire lors de la création d'un LUN à utiliser en ouvrant le fichier. O_DIRECT est spécifié par 'direct' et 0_SYNC par 'sync'

Hash d'en-tête et de données

   Les hash d'en-tête ed de donées peuvent être définis dans un paramètre par target. TGTD supporte 2 modes. None et CRC32C. Quand le hash est à None, tgtd négocie pour ne pas utiliser les hash, et quand CRC32C est définis, tgtd force la connection à utiliser un hash

Pour voir les paramètres courant pour le hashage
tgtadm --op show --mode target --tid 1
Pour définis le hash d'en-tête à CRC32C
tgtadm --op update --mode target --tid 1 -n HeaderDigest -v CRC32C
Pour le désactiver pour les données
tgtadm --op update --mode target --tid 1 -n DataDigest -v None

Authentification CHAP

   L'authentification CHAP est supportée pour exiger une authentification avant qu'un initiator soit autorisé à se logger et accéder aux périphériques. La passphrase est définie au niveau target. Pour créer une authentification CHAP, il faut créer un compte avec son mot de passe, puis lier le compte à un ou plusieurs target

Créer un utilisateur et le lier au target 1
tgtadm --lld iscsi --op new --mode account --user ronnie --password password
tgtadm --lld iscsi --op bind --mode account --tid 1 --user ronnie
Lister tous les comptes qui ont été créés
tgtadm --lld iscsi --op show --mode account
Aficher si un target nécessite une authentification
tgtadm --lld iscsi --op show --mode target

Sondes NOP-OUT

   tgtd peut envoyer des sondes NOP-OUT aux initiateurs connectés pour déterminer quand un initiateur est mort et quand stopper la connexion TCP. Cela peut être définis au niveau global ou par target.

Afficher les paramètres NOP-OUT
tgtadm --lld iscsi --op show --mode target
Définis NOP-OUT pour un target
tgtadm --op update --mode target --tid 1 -n nop_count -v 5
tgtadm --op update --mode target --tid 1 -n nop_interval -v 5

Portails iSCSI

   Les portails iSCSI peuvent être listés, ajoutés ou supprimés

Lister les portails définis sur le target
tgtadm --lld iscsi --op show --mode portal
Ajouter un portail
tgtadm --lld iscsi --op new --mode portal --param portal=10.1.1.101:3260
Supprimer un portail
tgtadm --lld iscsi --op delete --mode portal --param portal=10.1.1.101:3260

Connexions iSCSI

   Les connexions iSCSI peuvent être listées et fermées de force en temps réel

Lister toutes les connexions actives pour un target
tgtadm --lld iscsi --op show --mode conn --tid 1
Fermer une connexion existante
tgtadm --lld iscsi --op delete --mode conn --tid 1 --sid 2 --cid 0

Status online/offline

   Les LUN tgtd peuvent être online ou offline. Les LUN qui sont offline peut se comporter différemment d'un type de périphérique à l'autre. Les périphériques offline se comportent comme si aucun média n'était disponible et toute opération d'accès au média échoue avec une erreur. Les périphériques ne peuvent pas être mis en mode offline s'il y a des locks "PREVENT ALLOW MEDIUM REMOVAL" dans le périphérique. Similairement les média online ne peuvent pas être ejectés par logiciel quand de tels locks sont présent dans le périphérique.

Afficher le status
tgtadm --lld iscsi --mode target --op show
Changer un LUN en offline
tgtadm --tid 1 --lun 2 --op update --mode logicalunit -P Online=No

Paramètres iSNS

   La configuration iSNS pour un target se fait via tgtadm

Définis l'adresse du serveur iSNS. tgtd ne supporte qu'un serveur iSNS
tgtadm --op update --mode sys --name iSNSServerIP --value 192.168.11.133
Active/désactive iSNS
tgtadm --op update --mode sys --name iSNS --value On
Port à utiliser pour iSNS
tgtadm --op update --mode sys --name iSNSServerPort --value 3205
Active/désactiver le contrôle d'accès pour iSNS
tgtadm --op update --mode sys --name iSNSAccessControl --value Off

Exemple de création d'un jukebox DVD

Créer un jukebox DVD avec 8 tiroirs, et 2 DVD-R vides. Créer un target
tgtadm --lld iscsi --mode target --op new --tid 1 --targetname iqn.2007-03:virtual-dvd:`hostname`
Créer un lecteur DVD et lui donner un nom. Le dvd démarre sans fichier de stockage
tgtadm --op new --mode logicalunit --tid 1 --lun 1 --device-type cd
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 1 --params vendor_id=STGT_DVD,product_id=DVD101,product_rev=0010,scsi_sn=STGTDVD01,removable=1
Il faut un fichier de stockage backend pour le changeur:
if [ ! -f $HOME/smc ]; then dd if=/dev/zero of=$HOME/smc bs=1k count=1; fi
Créer le périphérique SMC et lui donner un nom:
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 --backing-store $HOME/smc --device-type changer
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params vendor_id=STK,product_id=L700,product_rev=0010,scsi_sn=XYZZY_0,removable=1
Ajouter un périphérique de transfert de donnnées:
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=4,start_address=1,quantity=1
Spécifier que le DVD (LUN 1) est le périphérique de transfert de données à créer
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=4,address=1,tid=1,lun=1
Medium Transport Elements
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=1,start_address=16,quantity=1
Définir le chemin du média virtuel
VTL=${HOME}/vtl
mkdir -p ${VTL}
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params media_home=${VTL}
Éléments de stockages - 8 commençant à l'adresse 1024
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=2,start_address=1024,quantity=8
Ajouter 'media' au slots 1 et 2 et laisser les autres vides
tgtimg --op new --device-type cd --type dvd+r --file ${VTL}/DISK_001
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=2,address=1024,barcode=DISK_001,volume_tag="A blank disk",sides=1
Et pour le slot 2:
tgtimg --op new --device-type cd --type dvd+r --file ${VTL}/DISK_002
tgtadm --lld iscsi --mode logicalunit --op update --tid 1 --lun 2 --params element_type=2,address=1025,barcode=DISK_002,volume_tag="My second blank disk",sides=1
Permettre à tous les initiateurs de se connecter à ce target:
tgtadm --lld iscsi --mode target --op bind --tid 1 --initiator-address ALL
Afficher le résultat
tgtadm --lld iscsi --mode target --op show
^
25 novembre 2016

htmlpdflatexmanmd




tgtd

tgtd

Service de target SCSI

   tgtd est un service de target SCSi. Il peut être utilisé pour fournir un service de target SCSI sur un réseau, comme iSCSI. tgtd fournis le support pour des périphériques émulé et réel. tgtd peut émuler les types de périphériques suivants:

        disk Disque normal. Émule un disque SCSI
        tape Périphérique tape. Émule un lecteur cassette SCSI
        cd Périphérique CD. Émule un graveur DVD SCSI
        changer Émule un périphérique changeur pour une librairie cassette virtuel ou un jukebox DVD

OPTIONS

-d, --debug ‹INTERGER› Mode debug
-f, --foreground Ne met pas en tâche de fond
-C, --control-port ‹INTERGER› port de contrôle à utiliser pour cette instance.
--iscsi ‹...› Options spécifiques à ISCSI.

Options iSCSI

portal=‹ip-address[:port]› lie tgtd à un ip/portail et/ou port. par défaut tgtd écoute sur toutes les adresse sur le port 3260.
nop_interval=‹integer› Définis l'interval par défaut pour envoyer NOP-OUT pour sonder les initiateurs connectés. Ne contrôle que la valeur par défaut pour les targets. Défaut: 0 = désactivé
nop_count=‹integer› Nombre de NOP-OUT échoués avant de considérer l'initiateur mort et fermer la session. Défaut: 0

Variables d'environnement

TGT_IPC_SOCKET=‹path› Définis, tgtd et tgtadm utilisent le socket IPC spécifié au lieu de /var/run/tgtd/socket.0
^
08 décembre 2016

htmlpdflatexmanmd




tgtimg

tgtimg

Utilitaire de fichier image target scsi

   tgtimg est un utilitaire pour initialiser des fichiers image avec métadonnées additionnelles, tel qu'un code barre, taille total, etc. que l'émulation tgtd a besoin

OPTIONS

-o, --op {new|show} Opération.
-Y, --device-type ‹type› Spécifie le type de fichier image (cd, disk, tape)
-t, --type ‹media-type› En créant une nouvelle image, spécifie le type de média à émuler:

        dvd+r Créé un DVD+R vide
        disk Créé un disque vide
        data Créé une cassette normale
        clean Créé une cassette de nettoyage
        worm Créé un worm

-b, --barcode ‹barcode› En créant une nouvelle image, spécifie le barcode à utiliser.
-s, --size ‹size› En créant une nouvelle image, spécifie la taille en Mio pour l'image tape virtuelle
-f, --file ‹path› Le nom du fichier
-T, --thin-provisioning Rend l'allocation de l'image thin.

Exemples

Créer un nouveau disque 100Mo
tgtimg --op new --device-type disk --type disk --size 100 --file /data/hd001.raw
Créer une nouvelle image tape
tgtimg --op new --device-type tape --barcode 12345 --size 100 --type data --file /data/tape001.img
Voir le contenu d'une image existante
tgtimg --op show --device-type tape --file /data/tape001.img
Créer une nouvelle image DVD-R blanche
tgtimg --op new --device-type cd --type dvd+r --file /data/dvd001.iso
^
25 avril 2017

htmlpdflatexmanmd




thin_check

thin_check

Valide les métadonnées de provisionnement léger dans un périphérique ou fichier

   thin_check vérifie les métadonnées de provisionning créé par DM dans un périphérique ou un fichier

OPTIONS

-q, --quiet mode silencieux
--clear-needs-check-flag efface le flage needs_check-flag au cas où la vérification a réussie.
--super-block-only Ne vérifie que la présence du superbloc
--skip-mappings ne vérifie pas le mappage de block qui constitue la majeur partie des métadonnées
--ignore-non-fatal-errors Ignore certaines erreurs non-fatales
^
25 avril 2017

htmlpdflatexmanmd




thin_dump

thin_dump

dump les métadonnées de provisionnement léger sur stdout

   thin_dump dump les métadonnées de provisionnement légier créé par la cible de provisionnement léger device-mapper sur stdout pour l'analyse ou post-traitement au format XML ou human-readable. Cet outil ne peut pas être lancé sur des métadonnées live sauf si --metadata-snap est utilisé.

OPTIONS

-f, --format {xml|human-readable} Format de sortie
-r, --repair Répare les métadonnée durant le dump
-m, --matadata-snap [block#] dump le snapshot de métadonnées.
^
25 avril 2017

htmlpdflatexmanmd




thin_metadata_size

thin_metadata_size

calculateur de taille de périphérique de métadonnées de provisionnement léger

   thin_metadata_size calcule la taille des métadonnées de provisionnement léger basé sur la taille de block des périphériques de provisionnement léger. La taille du pool et le nombre maximum de tous les périphériques provisionnés et snapshots. Parce que les pools de provisionnement léger maintiennent une grande variété de variables, cet outil est nécessaire pour fournir une taille initiale par défaut.

OPTIONS

-b, --block-size BLOCKSIZE[bskKmMgGtTpPeEzZyY] Taille de block des périphériques.
-s, --pool-size POOLSIZE[bskKmMgGtTpPeEzZyY] Taille du pool
-m, --max-thins #[bskKmMgGtTpPeEzZyY] Somme maximum de tous les périphériques et snapshots
-u, --unit {bskKmMgGtTpPeEzZyY} Unité à afficher pour la sortie
-n, --numeric-only [short|long] Limite la sortie à la taille avec optionnellement l'unité

Exemples

Calculer la taille pour une taille de block de 64Kio, une taille de pool de 1Tio et un nombre max de périphériques et snapshots de 1000:
thin_metadata_size -b64k -s1t -m1000
avec les options longues pour une taille de block de 1Gio, taille de pool de 1Po et un nombre max de périphériques et snapshots de 1 million:
thin_metadata_size --block-size=1g --pool-size=1P --max-thins=1M --unit=G --numeric-only
Idem avec les unités complètes
thin_metadata_size --block-size=1gibi --pool-size=1petabytes --max-thins=1mega --unit=G --numeric-only=short
avec une chaîne spécifiant l'unité
thin_metadata_size --block-size=1gibi --pool-size=1petabytes --max-thins=1mega --unit=G -nlong
^
25 avril 2017

htmlpdflatexmanmd




thin_repair

thin_repair

Répare les métadonnées de provisionnement léger

   thin_repair lit les métadonnées de provisionnement léger, les répares et les écrit dans un autre périphérique ou fichier. Cet outil ne peut être lancé sur des metadonnées live

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées

Exemples

Lit les métadonnées dans le fichier metadata, le répare et l'écrit dans /dev/vg/metadata:
thin_repair -i metadata -o /dev/vg/metadata
^
25 avril 2017

htmlpdflatexmanmd




thin_restore

thin_restore

Restore les métadonnées de provisionnement léger d'un fichier vers un périphérique ou fichier

   thin_restore restaure les métadonnées de provisionnement léger créés par la cile DM dumpée au format XML, peut optionnellement être pré-traité avant de le restaurer.

OPTIONS

-q, --quiet mode silencieux
-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




thin_rmap

thin_rmap

Affiche un map inversé d'une région de provisionnement léger de blocks depuis le périphérique de métadonnées

OPTIONS

--region ‹block range› Affiche la map inversée

Exemples

Affiche la map inversé pour les blocks de pool 5..45 (==5..44 inclusif)
thin_rmap --region 5..45 /dev/pool-metadata
^
23 mai 2017

htmlpdflatexmanmd




tiger

tiger

Analyseur de sécurité UNIX

   Tiger est un package consistant de scripts shell, code C, et de fichiers de données utilisées pour vérifier les problèmes de sécurité dans un système UNIX. Il scanne les fichiers de configuration système, les systèmes de fichiers, et les fichiers de configuration utilisateur pour de possible problèmes de sécurité et les affiche.

  tiger peut être configuré en ajustant les variables Tiger_ dans le fichier de configuration tigerrc. Pour chaque module disponible, il y a une variable qui determine si le module est lancé.

OPTIONS

-B tigerdir Spécifie le répertoire où tiger est installé.
-l logdir|@logserver Spécifie le nom du répertoire où tiger écrit le rapport de sécurité, ou le nom d'un serveur de log tiger.
-w workdir Spécifie un répertoire à utiliser pour créer des fichiers scratchs.
-b bindir Spécifie le répertoire qui contient les binaires générés depuis les modules C.
-c tigerrc Spécifie l'emplacement du fichier tigerrc
-e  Insert des explication dans les rapports de sécurité suivant chaque message.
-E  Créé un rapport explicatif séparé
-G Génère les signatures (hashs MD5 et permissions de fichier) pour les fichiers binaires système
-H Formatte le rapport en html
-S Indisque qu'une vérification des fichiers de configuration des clients sans disque servis par cette machine devraient être vérifiés en même temps.
-q Supprime les messages pour être le plus silencieux possible
-A arch Spécifie l'architecture au lieu de laisser tiger l'obtenir
-O os Spécifie l'os au lieu de laisser tiger l'obtenir
-R release Spécifie la version de l'os au lieu de laisser tiger l'obtenir

Modules

   Tiger est composé d'une série de modules. Chacun de ces modules vérifie les problèmes de sécurité liés aux systèmes UNIX. Les modules peuvent être exécutés seul, depuis cron ou via le programme tiger.

check_accounts Vérifie les comptes fournis dans le système, recherche les comptes désactivés avec cron, rhosts, .forward et les shells valides
check_aliases Effectue une vérification pour les alias mail et les configuration non-correct
check_anonftp Vérifie si le service FTP anonyme est configuré correctement
check_cron Valide les entrées cron dans le système
check_embedded Détermine si les chemins embarqués sont configurés correctement
check_exports Analyse les fichiers de configuration des exports NFS
check_group Vérifis les groupes UNIX disponible dans le système
check_inetd Vérifie le fichier de configuration inetd
check_known Recherche les signes d'intrusion connus, incluant les backdoors et les mail spools.
check_netrc Vérifie si le fichiers netrc des utilisateurs sont configurés correctement
check_nisplus Recherche les erreurs de configuration dans les entrées NIS+
check_path Valide les binaires dans le PATH de l'utilisateur, et les définitions PATH utilisés par les scripts pour déterminer les définitions non-sécurisé
check_perms Vérifie les permissions de fichiers et les inconsistances
check_printcap analyses la configuration pour le fichier de contrôle d'imprimante
check_rhosts Vérifie les fichiers rhosts pour vois si la configuration utilisateur laisse le système ouvers à des attaques
check_sendmail Vérifie les fichiers de configuration sendmail
check_signatures Compares les signatures des fichiers binaires avec ceux stockés dans la base locale (fournie avec le programme)
check_system Ce module appelle les modules spécifique de l'os dans /usr/lib/tiger/systems/
check_apache Vérifie la configuration Apache
check_devices Vérifie les permissions des périphérique
check_exrc Analyse les fichiers .exrc qui ne sont pas dans les répertoires home.
check_finddeleted Vérifie si les fichiers supprimés sont utilisé par un processus dans le système
check_ftpusers Analyse /etc/ftpusers et détermine si les admins sont dans ce fichier
check_issue Vérifie /etc/issue et /etc/issue.net pour déterminer s'ils contiennent le contenu approprié
check_logfiles Vérifie l'existence de fichiers de log (wtmp, btmp, lastlog, et utmp). Vérifie le umask
check_lilo Analyse les fichiers de configuration de lilo et grub
check_listeningprocs Vérifie les processus écoutant sur des sockets TCP/IP dans le système et les utilisateurs qui les lances
check_passwdformat Vérifie le format de /etc/passwd pour déterminer les inconsistances indiquant une intrusion ou une mauvaise configuration
check_patches Vérifie si les patchs sont disponibles pour le système. Utilise autorpm ou apt-get.
check_root Vérifie si le login root distant est autorisé
check_rootdir Vérifie les permission de /root
check_rootkit Tente de trouver les systèmes rootkités, en recherchant les commandes ls et find qui sont des trojans. inclus également un wrapper pour chkrootkit
check_single Vérifie si le système est configuré correctement et interdit l'accès single-user.
check_release Analyse la version de l'os et détermine s'il n'est plus à jours.
check_runprocs Vérifie si les processus configurés dans tigerrc sont lancés dans le système.
check_services Vérifie quils services sont configurés dans le système (généralement /etc/services) et ceux qui devraient être configurés
check_tcpd Test l'existance de tcp-wrappers et change la configuration et détermine quels services tournent sous tcp-wrappers
check_umask Vérifie le paramètre umask dans les fichiers de configuration
check_xinetd Vérifie si les services xinetd sont activés ou non
crack_run Lance une installation locale du programme Crack qui peut être utilisé pour déterminer si les mots de passe locaux sont trop simple
tripwire_run
aide_run
Integrit_run Wrappers pour des vérificateurs d'intégrité, ces programmes améliore le support de tiger pour les signatures binaires MD5 et SHA1 et les vérifications de permission de fichier.
deb_checkadvisories Vérifie une liste d'avertissement de sécurité pour voir si le système a des paquets installés dont la version peut être sujet à une vulnérabilité
deb_checkmd5sums Compare les MD5 des fichiers binaires avec ceux fournis après l'installation.
deb_nopackfiles Recherche les fichiers installés dans les répertoires système qui ne sont pas fournis par un package Debian
^
23 mai 2017

htmlpdflatexmanmd




tigercron

tigercron

Utilitaire cron pour tiger

   tigercron est utilisé pour lancer périodiquement les vérifications de tiger. tigercron lit un fichier de contrôle qui est généralement utilisé dans cronrc. -B permet d'indiquer où tiger est installé. tigercon lance les vérifications et compare les rapports avec les précédents. Puis il envoie le résultat par mail définis dans tigerrc.

OPTIONS

   tigercron utilise les même options que tiger.
^
23 mai 2017

htmlpdflatexmanmd




tigerrc

tigerrc

Fichier de configuration pour tiger

   Ce fichier est pré-traité, et ne peut contenir que des assignements de variables et des commentaires

TigerNoBuild=Y Les fichiers C sont corrompus
Tiger_Check_PASSWD=Y Rapide
Tiger_Check_PASSWD_FORMAT=N Non nécessaire dans les systèmes avec pwck
Tiger_Check_PASSWD_SHADOW=Y le temps dépend du nombre d'utilisateurs
Tiger_Check_PASSWD_NIS=N idem
Tiger_Check_GROUP=Y rapide
Tiger_Check_ACCOUNTS=Y le temps dépend du nombre d'utilisateurs
Tiger_Check_RHOSTS=Y idem
Tiger_Check_NETRC=Y idem
Tiger_Check_ALIASES=Y rapide
Tiger_Check_CRON=Y rapide
Tiger_Check_ANONFTP=Y rapide
Tiger_Check_EXPORTS=Y rapide
Tiger_Check_INETD=Y rapide pour inetd, varie pour xinetd
Tiger_Check_SERVICES=Y assez rapide
Tiger_Check_KNOWN=Y rapide
Tiger_Check_PERMS=Y assez rapide
Tiger_Check_SIGNATURES=N plusieurs minutes
Tiger_Check_FILESYSTEM=Y Dépend de la taille du système de fichier. peut prendre des heures
Tiger_Check_ROOTDIR=Y Rapide
Tiger_Check_ROOT_ACCESS=Y Rapide
Tiger_Check_PATH=Y rapide pour root.
Tiger_Check_EMBEDDED=Y Plusieurs minutes
Tiger_Check_BACKUPS=Y Rapide
Tiger_Check_LOGFILES=Y Rapide
Tiger_Check_USERUMASK=Y Rapide
Tiger_Check_ETCISSUE=N Rapide, doit être personnalisé
Tiger_Check_STRICTNW=Y Rapide
Tiger_Check_LISTENING=Y Rapide
Tiger_Check_SYSTEM=Y Dépend des vérification du système
Tiger_Check_RUNPROC=N rapide, doit être personnalisé
Tiger_Check_DELETED=N Dépend du nombre de processus dans le système
Tiger_Check_APACHE=N Rapide
Tiger_Check_SSH=Y Rapide
Tiger_Check_SENDMAIL=N Rapide
Tiger_Check_PRINTCAP=Y Rapide
Tiger_Check_EXRC=N Dépend de la taille du système de fichier
Tiger_Check_ROOTKIT=Y Lent si chkrootkit est disponible
Tiger_Check_FTPUSERS=Y Rapide
Tiger_Check_OMNIBACK=N Rapide
Tiger_Check_NTP=Y Rapide
Tiger_Check_PATCH=N dépend de la connexion réseaux
Tiger_Check_SINGLE=Y Rapide
Tiger_Check_BOOT=Y Rapide
Tiger_Check_INITTAB=Y Rapide
Tiger_Check_RCUMASK=Y Rapide
Tiger_Check_NEVERLOG=Y Rapide
Tiger_Check_OS=Y Rapide
Tiger_Check_NETWORKCONFIG=Y Rapide
Tiger_Cron_SendOKReports=N Indique si les rapports sans informations sont envoyés à cron
TigerCron_Log_Keep_Max=10 Nombre de rapports à conserver pour chaque vérification lancé depuis crontab
Tiger_Cron_Template=N Indique si les rapports sont comparés avec un template, si disponible
Tiger_Cron_CheckPrev=Y Indique si les rapports sont comparés avec un précédent rapport, si disponible
Tiger_Show_INFO_Msgs=N Indique si les massages taggés INFO sont affichés
Tiger_Run_CRACK=N lance Crack
Tiger_CRACK_LOC_OVERRIDE=/mnt/cdrom/crack/Crack Emplacement du binaire Crack
Tiger_CRACKREPORTER_LOC_OVERRIDE=/mnt/cdrom/crack/Reporter
Tiger_CRACKDIR_LOC_OVERRIDE=/usr/local/crack Doit être accessible en écriture
Tiger_Output_FQDN=Y Indique si les fqdn sont utilisés
Tiger_Run_TRIPW=N Lance le vérification d'intégrité Tripwire
Tiger_TRIPW_LOC_OVERRIDE=/mnt/cdrom/tripw/tripwire Emplacement du binaire tripwire
Tiger_Run_AIDE=N Lance le vérification d'intégrité de fichier AIDE
Tiger_Run_AIDE_VERBOSE=1 Rapport verbeux (pas encore implémenté)
Tiger_AIDE_LOC_OVERRIDE=/mnt/cdrom/aide/aide.bin Emplacement du binaire aide
Tiger_AIDE_CFG_OVERRIDE=/mnt/cdrom/aide/aide.conf Emplacement de la configuration de aide
Tiger_AIDE_DB_OVERRIDE=/mnt/cdrom/aide/in.db Emplacement de la base de données de aide
Tiger_Run_INTEGRIT=N Lance le vérificateur d'intégrité de fichier Integrit
Tiger_INTEGRIT_CFG=/etc/integrit/integrit.conf Emplacement de la configuration d'integrit
Tiger_INTEGRIT_LOC_OVERRIDE=/mnt/cdrom/integrit/integrit.bin Emplacement du binaire integrit
Tiger_Output_Width=79 Pour le formattage de la sortie
Tiger_CRON_Output_Width=0 Largeur de la sortie quand utilisé via tigercron
Tiger_Global_PATH="/etc/profile /etc/csh.login" PATH global
Tiger_Passwd_Constraints="PASS_MIN_DAYS PASS_MAX_DAYS PASS_WARN_AGE PASS_MIN_LEN" Vérifications opérées sur les mots de passe
Tiger_Passwd_Hashes='crypt3|md5|sha512' Type de hash de mot de passe acceptés
Tiger_Dormant_Limit=60 Nombre de jours des fichiers non-modifiés dans le répertoire home avant d'être considéré comme dormants
Tiger_Admin_Accounts='adm|bin|daemon|games|lp|mail|news|operator|sync|sys|uucp|man|proxy|majordom|postgres|www-data|operator|irc|gnats Comptes autres que root considérés comme administratifs (non utilisés par des humains, et dont sans mot de passe)
Tiger_Embed_Max_Depth=3 Si un chemin embarqué réfère à un fichier exécutable, il est vérifié. cela continue récursivement jusqu'à ce qu'il n'y ait plus de nouveaux exécutables trouvé, ou une profondeur max atteinte.
Tiger_Embed_Check_Exec_Only=Y Ne recherche que les exécutables dans les chemins embarqués
Tiger_Embed_Check_SUID=Y Vérifie les exécutables setuid trouvés
Tiger_Embed_Report_Exec_Only=Y Ne reporte que les exécutables qui sont en écriture ou non possédés par root
Tiger_Embedded_OK_Owners='root|bin|uucp|sys|daemon' Qui est autorisé à posséder des fichiers système
Tiger_Embedded_OK_Group_Write='root|bin|uucp|sys|daemon' Quels groupes peuvent accéder en écriture aux fichiers systèmes
Tiger_Check_PATHALL=N Spécifie si le PATH de tous les utilisateurs doivent être vérifiés. Peut potentiellement être dangereux
Tiger_ROOT_PATH_OK_Owners='root|uucp|bin|news|sys|daemon|lp' Qui peut posséder les exécutables dans /root?
Tiger_ROOT_PATH_OK_Group_Write='root|uucp|bin|sys|daemon' Quels groupes peuvent accéder en écriture dans /root
Tiger_PATH_OK_Owners=$Tiger_ROOT_PATH_OK_Owners Qui peut posséder quelque chose dans les PATH utilisateurs
eval Tiger_PATH_OK_Group_Write='$Tiger_ROOT_PATH_OK_Group_Write' Quels groupes peuvent avoir un accès en écriture sur les exécutables dans le PATH utilisateur (non-root)
Tiger_Collect_CRACK=Y Indique si tiger doit attendre que Crack se termine.
Tiger_Crack_Local=Y Lance Crack dans les sources de mot de passe locaux uniquement
Tiger_Mail_FROM="root@`uname -n`" Nom de l'émetteur pour l'envoie de la sortie de tigercron
Tiger_Mail_RCPT=root Destinataire de la sortie de tigercron
Tiger_Files_of_Note="..[!.]*/.* */.*   */.[!.]/.log/.FSP*" Liste de globs de nom de fichier à regarder dans le système de fichier
Tiger_FSScan_Setuid=N Vérifie les exécutables setuid
Tiger_FSScan_Setgid=N Vérifie les exécutables setgid
Tiger_FSScan_Devs=Y Vérifie les fichiers de périphérique
Tiger_FSScan_SymLinks=Y Vérifie les liens symboliques étranges
Tiger_FSScan_ofNote=Y Vérifie les noms de fichier étranges
Tiger_FSScan_WDIR=N Vérifie les répertoire accessible en écriture par tout le monde
Tiger_FSScan_Unowned=Y Vérifie les fichiers avec un propriétaire/groupe non-définis
Tiger_FSScan_WarnUnknown=Y Alerte sur les systèmes de fichier inconnus utilisés
Tiger_FSScan_Local='' Système de fichiers considérés comme local dans le système
Tiger_FSScan_NonLocal='' Systèmes de fichiers considérés comme non-local.
Tiger_FSScan_ReadOnly=N Spécifie si les systèmes de fichiers en lecture seul sont scannés
USERDOTFILES=".alias .kshrc .cshrc .profile .login .mailrc .exrc .emacs .forward .tcshrc .zshenv .zshrc .zlogin .zprofile .rcrc .bashrc .bash_profile .inputrc .xinitrc .fvwm2rc .Xsession .Xclients .less" Liste de fichiers cachés communéments trouvés dans les répertoires home qui sont vérifiés par check_accounts
RHOST_SITES='*.tamu.edu|jupiter' Site Rhost qui sont attendus dans .rhosts. Tout ce qui ne matche pas est reportés
Tiger_Accounts_Trust=999 Quels uid ne doivent pas générer d'alerte pour les shells valides
Tiger_SSH_Protocol='1|2' Version de SSH attendue
Tiger_SSH_RhostsAuthentication='no' variable sshd_config attendue
Tiger_SSH_PasswordAuthentication='no' variable sshd_config attendue
Tiger_Listening_Every=Y Indisque si une alerte est données pour les services qui écoutent sur toutes les interfaces
Tiger_Listening_ValidUsers='root' Indique quel utilisateur est autorisé à avoir des processus en écoute pour les connections entrantes
Tiger_Listening_ValidProcs='' Quels processus sont toujours considérés comme valides, sans regarder s'il écoutent les connections entrantes dans le système.
Tiger_Running_Procs='syslogd cron atd klogd' Quels processus doivent être vérifiés par tiger. Les processus de cette liste qui ne sont pas vu dans la table de processus génère un FAIL
Tiger_DPKG_Optimize=Y Indisque si les vérification DPKG sont optimisés
Tiger_CHKROOTKIT_ARGS="-q" Arguments utilisé pour chkrootkit.

^
23 mai 2017

htmlpdflatexmanmd




tigexp

tigexp

Générateur d'explication des vérificateurs

   tigexp est utilisé pour générer des explications sur la sortie du tiger. Dans la première forme, tigexp va générer une explication pour chaque id de message listés. Dans la seconde forme, le rapport est scanné, et les explications sont générées.

OPTIONS

-f Génère une explication pour chaque id de message unique
-F affiche le rapport de sécurité avec les explications insérées après chaque entrée dans le rapport


   Il y a 5 niveaux de message produits par tiger:

ALERT Un message de ce niveau indique que tiger a détecté une possible tentative d'intrusion, ou une mauvaise configuration qui est un problème de sécurité
FAIL Indique une violation de la stratégie de sécurité, ou une possible intrusion.
WARN Indique un problème de sécurité qui devrait être vérifié et peut indiquer une exposition à une vulnérabilité
INFO Message pas nécessairement un problème de sécurité, mais peut être utile pour l'administrateur
ERROR Erreur dans l'exécution de tiger.
CONFIG Ces message informent des étapes dans les processus de configuration de tiger.
^
06 mai 2017

htmlpdflatexmanmd




timedatectl

timedatectl

Contrôle le temps système et la date

   timedatectl permet d'afficher et changer l'horloge système et ses paramètres

OPTIONS

--no-ask-password Ne demande pas l'authentification utilisateur pour les opérations privilégiées
--adjust-system-clock Si set-local-rtc est invoqué avec cette option, l'horloge système est synchronisée avec RTC, sinon RTC est synchronisé depuis l'horloge système
-H, --host= Exécute l'opération à distance
--no-pager Ne pipe pas dans un pager
-M, --machine= Exécute l'opération dans le conteneur spécifié

Commandes

status Affiche le status courant
set-time [TIME] Définis l'horloge système au format "2012-10-30 18:17:16"
set-timezone [TIMEZONE] Définis le timezone
list-timezones Liste les timezones disponibles
set-local-rtc [BOOL] à 0, le système est configuré pour maintenir RTC en temps universelle. À 1, le système maintient RTC en temps local.
set-ntp [BOOL] Contrôle si ntp est actif. Celà démarre systemd-timesyncd.service.

Variables d'environnement

SYSTEMD_PAGER Pager à utiliser. Vide, ou 'cat' est équivalent à --no-pager
SYSTEMD_LESS Remplace les options par défaut de less ('FRSXMK')
^
15 juillet 2010

htmlpdflatexmanmd




timeout

timeout

Lance la commande spécifiée et la termine au delà du temps spécifié.

   timeout lance la commande spécifiée et la termine si elle continue de fonctionner une fois le temps spécifié écoulé. La durée peut être préfixé par:

s secondes
m minutes
h heures
d jours

OPTIONS

-s SIGNAL, --signal=SIGNAL Envoie le signal spécifé à la commande au timeout, au lieu du signal par défaut TERM.
^
24 mai 2010

htmlpdflatexmanmd




top

top

Surveillance du système

   L'utilitaire top fournis une vue temps-réel du système. Il peut afficher des informations sommaire sur le système, et une liste des tâches en cours. Les informations qu'il affiche sont configurable.

  Le programme fournis une interface interactive limitée pour la manipulation des processus et une interface étendue pour une configuration étendue.

Options de ligne de commande

-b mode batch. Utile pour envoyer la sortie à d'autres programmes ou dans un fichier. Dans ce mode, top n'accèpte pas d'entrée et s'arrête après la limite d'itération définie par -n, ou jusqu'à ce qu'il soit tué.
-c affiche la ligne de commande.
-d Délai (format ss.tt = secondes.dixièmes) Spécifie le délai entre chaque mise à jour d'écran
-h affiche une aide et quitte
-H Threads. activé, les threads seront affichés, sinon top affiche un sommaire de tous les threads courant.
-i Idle. Désactivé, les tâches qui sont au repos ou zombie ne sont pas affichées
-n  Nombre d'itération. Spécifie le nombre maximum d'itération ou frames, que top devrait produire avant de se terminer.
-u Monitor. Monitor seulement les processus avec l'uid ou l'utilisateur spécifié
-U Monitor. Idem pour les UID et utilisateur réel, effectifs, sauvegardés et UID de système de fichier.
-p Monitor. Monitor seulement les processus avec le(s) process ID spécifié(s). Cette options peut être spécifiée jusqu'à 20 fois.
-s Mode sécurisé. Lance top en mode sécurisé forcé, même pour root. Ce mode est contrôlé par le fichier de configuration.
-S Mode temps cumulatif. chaque processus est listé avec le temps cpu qu'il a utilisé ainsi que que ses enfants mort.
-v affiche la version et quitte

Champs/colonnes

PID l'ID du processus
PPID l'ID du processus parent
RUSER Le vrai propriétaire de la tâche
UID L'ID effectif du propriétaire de la tâche
USER le nom effectif du propriétaire de la tâche
GROUP Le groupe effectif du propriétaire dela tâche
TTY Le nom du terminal qui contrôle la tâche.
PR La priorité de la tâche
NI valeur nice
P Le dernier processeur utilisé.
%CPU Utilisation CPU, exprimé en % du temps CPU total
TIME Temps CPU. Temps total de CPU que la tâche a utilisé depuis qu'elle a démarré
TIME+ Temps CPU. en centièmes de secondes
%MEM Utilisation mémoire
VIRT Image virtuelle. Quantité totale de mémoire virtuelle utilisée par la tâche.
SWAP Taille swap. Portion de la mémoire virtuelle de la tâche en swap
RES Resident size. Taille de la mémoire physique non swappée de la tâche
CODE Taille de la mémoire virtuelle de code
DATA Taille de la mémoire virtuelle de données+pile
SHR Taille mémoire partagée. Quantité de mémoire partagée utilisée par la tâche
nFLT Page fault count. nombre de page fault majeur qui se sont produite pour une tâche.
nDRT Dirty page count. nombre de pages qui ont été modifiées depuis la dernière écriture sur disque.
S Status du processus :

        D uninterruptible sleep
        R running
        S sleeping
        T traced or stopped
        Z zombie

Command Ligne de commande ou nom du programme
WCHAN Sleeping in function. En fonction de la disponibilité du kernel link map (System.map), ce champs affiche le nom ou l'adresse de la fonction kernel dans laquelle la tâche est actuellement endormie.
Flags Task Flags. voir ‹linux/shed.h›

Sélectionner et ordonner les colonnes

   Après avoir utilisé les commandes 'f' (Fields select) ou 'o' (Order fields), un écran permet de sélectionner et ordonner les colonnes.

Etats CPU

Les états CPU sont affichés au dessus de la liste des tâches.
up User CPU time. Temps que le cpu a passé à faire tourner les processus de l'utilisateur qui ne sont pas nicé
sy System CPU time. Temps que le cpu a passé à faire tourner le kernel et ses processus
ni Nice CPU time. Temps que le cpu a passé à faire tourner les processus de l'utilisateur qui on été nicé.
wa iowait. Temps que le cpu a attendu que les I/O s'achèvent
hi Hardware IRQ. Temps que le cpu a servis les interruptions hardware.
si Software interrupt. Temps que le cpu a servis les interruptions logiciel.
st Steal time. quantité de CPU 'volé' de cette machine virtuelle par l'hyperviseur.

Commandes intéractives globales

elles sont toujours disponible en mode plein écran et en mode d'affichage alternatif, mais certaines ne sont pas disponibles en mode securité.
‹Enter›,‹Space› Rafraîchit l'affichage.
‹ ?›,‹h› affiche l'aide
‹=› Supprime les restrictions sur quelles tâches sont affichées.
‹A› Switch entre le mode plein écran et le mode alternatif
‹B› Active la mise en gras des valeurs du sommaire.
‹d›,‹s› Change l'interval de rafraîchissement.
‹G› Permet de choisir entre 4 'vues' différentes
‹I› switcher entre le mode Irix et le mode Solaris
‹ u › Permet de définir un utilisateur (nom ou UID effectif) pour filter les tâches à afficher
‹U› Permet de définir un utilisateur (nom ou UID réel) pour filter les tâches à afficher
‹k› Permet d'envoyer un signal à une tâche
‹q› quitter top
‹r› Renice une tâche
‹W› Sauvegarde vos options dans le fichier de configuration.
‹Z› change les couleurs d'affichage

Commandes du sommaire

‹l› affiche ou non la ligne affichant la charge moyenne
‹m› affiche ou non les information sur l'utilisation de la mémoire
‹t› affiche ou non l'état des CPU et des tâches
‹ 1 › affiche ou non l'état de chaque CPU

Commandes de la zone des tâches

‹ b › change la façon dont 'x' et 'y' seront affichés
‹x› surligne la colonne de trie.
‹y› surligne les tâche 'runing'
‹z› switch entre le mode monochrome ou le mode couleur.

Contenue de la fenêtre des tâches

‹c› switch entre le nom du programme et la commande dans la colonne commande
‹f›,‹o› Permet de sélectionner des champs et des les ordonner.
‹S› Basculer vers le mode de temps cumuatif.
‹ u › afficher les tâche appartenant à l'utilisateur spécifié

Taille de la fenêtre des tâches

‹ i › Affiche toutes les tâche ou seulement les tache actives
‹n›,‹#› Permet de spécifier le nombre de tâches à afficher.

Trie de la fenêtre des tâches

M %MEM
N PID
P %CPU
T TIME+
 ‹  la colonne à gauche de la colonne de trie devient la colonne de trie.
 ›  la colonne à droite de la colonne de trie devient la colonne de trie.
‹F›,‹ 0 › permet de changer le champs utilisé pour trier les entrées.
‹R› switch de trie croissant/décroissant

Couleurs

En utilisant 'Z' vous pouvez changer les couleurs.
S sommaire
M message/prompt
H en-tête de colonne
T Tâches
0 - 7 sélectionner la couleur
a/w choisir entre 4 thème de couleur.
B switch de mise en gras
b Switch surligner/gras
z couleur/monochrome

mode d'affichage alternatif

Dans ce mode les 4 groupes d'affichage sont affichés simultanément.
‹-› affiche ou non l'affichage des tâches
‹_› idem mais pour toutes les vues.
‹=› force l'affichage de la liste des tâches
‹+› idem mais pour toutes les vues.
‹A› permet de passer en mode alternatif
‹a›,‹w› permet de changer la vue de la fenêtre courante
‹G› Idem
‹g› Permet de renommer la vue courante

Fichiers

/etc/toprc Ce fichier permet de limiter les fonctionnalités autorisées aux utilisateurs.
/$HOME/.toprc Fichier de configuration top personnel. Utiliser 'W' pour le créer ou le mettre à jours.

Exemple

s # line 1 : 'secure' mode switch
5.0 # line 2 : 'delay' interval in seconds
^
03 juillet 2010

htmlpdflatexmanmd




touch

touch

Change le atime et/ou le mtime des fichiers spécifiés

   un argument '-' est manipulé spécialement et force touch à changer le temps des fichiers associés avec l'entrée standard. Le temps est spécifié par la variable d'environnement TZ, ou par les règles par défaut du système si elle n'est pas définie.

OPTIONS

-a, --time=atime, --time=access, --time=use Change le atime uniquement.
-c, --no-create Ne crée pas de fichier s'il n'existe pas
-d, --date=TIME Utilise TIME au lieu du temps courant. exemple : --date="2004-02-27 14:19:13.489392193 +0530" spécifie l'instant de temps qui est 489 392 193 nano-secondes après le 27 février 2004 a 2h19:13 PM dans une zone qui est 5 heures 30 minutes EST d'UTC.
-m, --time=mtime, --time=modify Change le mtime uniquement
-r FILE --reference=FILE utilise le temps de FILE comme référence. Si cette option est combinée ) --date, le temps de FILE est l'origine et TIME est le temps relatif.
-t [[CC]YY]MMDDHHMM[.SS] Utilise l'argument au lieu du temps courant. si l'année est spécifiée avec 2 chiffres : ‹ 69 = 20xx sinon 19xx.
^
24 juin 2010

htmlpdflatexmanmd




tr

tr

Traduit et réduit les caractères

   tr copie l'entrée standard sur la sortie standard, en effectuant un de ces opérations :

- Traduit, et optionnellement réduit les caractères répétés dans le résultat.
- Réduit les caractères répétés.
- Supprimer des caractères
- Supprimer des caractères, puis réduit les caractères répétés dans le résultat.

Jeux de caractères

   Les arguments SET1 et SET2 définissent les jeux de caractères ordonnés.

  Le format de SET1 et SET2 ressemble au format des expressions régulières ; cependant ce ne sont pas des expressions régulières, seulement des listes de caractères.

  Caractères spéciaux reconnus :

        \a Control-G
        \b Control-H
        \f Control-L
        \n Control-J
        \r Control-M
        \t Control-I
        \v Control-K
        \000 Représente la valeur en octal d'un caractère.
        \\ backslash

Plages

   une plage est sous la forme M-N

Caractères répétés

   La notation [C*N] dans SET2 étend N copies du caractère C. donc [y*6] revient à yyyyyy.

Classes de caractères

   La notation [:CLASS :] s'étend à tous les caractères de la classe prédéfinie CLASS.

        alnum Lettres et chiffres
        alpha Lettres
        blank Espaces horizontaux
        cntrl Caractères de contrôle
        digit Chiffres
        graph Caractères imprimables, mais pas les espaces
        lower Lettres minuscules
        print Caractères imprimables
        punct Caractères de ponctuation
        space Espaces horizontaux et verticaux
        upper Lettre majuscules
        xdigits Chiffres Hexadécimaux

Traduction

   tr effectue une traduction quand SET1 et SET2 sont données et que l'option --delete n'est pas donné. tr traduit chaque caractère de l'entrée qui est listé dans SET1 par le caractère spécifié dans SET2.

Exemple

Tout mettre en majuscule
tr a-Z A-Z ou tr '[:lower:]' '[:upper:]'

Réduire

   En donnant juste l'option --delete ou -d, tr supprime tous caractère listé dans SET1.

  En donnant juste l'option --squeeze-repeats ou -s, tr remplace chaque séquence de caractères répété et listé dans SET1, par un seul.

  En utilisant ces 2 options, tr supprime d'abord en utilisant SET1, puis réduit en utilisant SET2. -s peut être utilisé avec la traduction.

Exemples

supprimer tous les octets 0
tr -d '\0'
convertit tous les caractère non-alphanumérique en newline, puis réduit les newlines répétés
tr -cs '[:alnum :]' '[\n*]'
supprimer les newlines consécutifs
tr -s '\n'
trouver les occurrences doublées de mots dans un document
#! /bin/sh
cat -- "$@" | tr -s '[:punct:][:blank:]' '[\n*]' | tr '[:upper:]' '[:lower:]' | uniq -d
^
06 juillet 2010

htmlpdflatexmanmd




true

true

Retourner un code de sortie de 0

   true ne fait rien excepté retourner un code de sortie de 0.

^
04 juillet 2010

htmlpdflatexmanmd




truncate

truncate

Réduit ou étend la taille d'un fichier. Si un fichier est plus grand que la taille spécifiée, les données en trop sont perdues. A l'inverse, le fichier est remplis de 0.

OPTIONS

-c, --no-create Ne créer pas de fichier s'il n'existe pas
-o, --io-blocks traite la taille comme nombre de blocks I/O du fichier au lieu d'octets
-r RFILE, --reference=RFILE définis la taille des fichiers à la même taille que RFILE
-s SIZE, --size=SIZE définit la taille de chaque fichier. peut être suffixé avec un multiplier et/ou:

+ étend de
- réduit de
au plus
au moins
/ arrondis au multiple inférieur de
% arrondis au multiple supérieur de
^
21 juillet 2010

htmlpdflatexmanmd




tsort

tsort

Trie topologique

Exemples

tsort ‹‹EOF
a b c
d
e f
b c d e
EOF
produira:
a
b
c
d
e
f
^
12 juillet 2010

htmlpdflatexmanmd




tty

tty

Affiche le nom du fichier du terminal connecté sur l'entrée standard

OPTIONS

-s, --silent, --quiet N'affiche rien, retourne uniquement le code de sortie

Codes de sortie

0 si l'entrée standard est un terminal
1 si l'entrée standard n'est pas un terminal
2 si l'argument donné est incorrect
3 si une erreur d'écriture s'est produite
^
02 novembre 2016

htmlpdflatexmanmd




tune2fs

tune2fs

Paramétrer un système de fichier ext2/3/4

   tune2fs permet d'ajuster divers paramètres de système de fichier. Les valeurs courantes de ces options peuvent être affichés en utilisant l'option -l ou avec dumpe2fs.

OPTIONS

-c max-mount-counts Ajuste le nombre de montage avant que le système de fichier ne soit vérifié par e2fsck. à 0 ou -1 désactive la vérification.
-C mount-count Définis le nombre de fois que le système de fichier a été monté. À une valeur supérieur à max-mount-counts, e2fsck vérifie le système de fichier au prochain reboot.
-e error-behavior Comportement du kernel en cas d'erreur. (continue, remount-ro, panic)
-E extended-options Définis les options étendues pour le système de fichier. Les options étendues sont séparés par ',' et peuvent prendre un argument avec '='. Les options étendues suivantes sont supportés:

        clear_mmp Reset le block MMP à un état propre.
        mmp_update_interval=interval ajuste l'interval de mise à jours MMP initial. À 0, utilise l'interval par défaut.
        stride=stride-size Configure le système de fichier pour un RAID des blocks de stride-size.
        stripe_width=stripe-width Configure de système de fichier pour un RAID avec des blocks de stripe-width par stripe.
        hash_alg=hash-alg Définis l'algorithme de hashage utilisé pour les systèmes de fichiers avec des répertoires b-tree hashés (legacy, half_md4 et tea)
        mount_opts=mount_option_string Jeu d'options de montage par défaut, utilisé quand le système de fichier est monté. Cette chaîne est stockée dans le superblock.
        test_fs Met un flag dans le superblock indiquant qu'il peut être monté en utilisant le code expérimental du kernel.
        ^test_fs Efface le flag test_fs.

-f Force les opérations même en cas d'erreur. Utile pour supprimer has_journal d'un système de fichier avec un journal externe.
-g group Définis le groupe qui peut utiliser les blocks de système de fichier réservés.
-i interval-between-checks[d|m|w] Ajuste le temps max entre 2 vérification du système de fichier avec le suffix d(jour), m(mois), w(semaine).
-I Change la taille d'inode utilisée par le système de fichier. Nécessite de re-écrire la table d'inode.
-j Ajoute un journal ext3 au système de fichier. Si utilisé dans un système de fichier monté, un fichier immuable .journal est créé. À la vérification du système de fichier, les fichiers .journal sont plasé dans l'inode journal réservé.
-J journal-options Définis ou change les paramètres de journal. Les options suivantes sont supportées:

        size=journal-size Créé un journal stocké dans le système de fichier de taille spécifiée en Mio. entre 1024 et 10 240 000 blocks de système de fichier.
        location=journal-location Spécifie l'emplement du journal. Peut être un numéro de block, ou l'offset depuis le début du fs en suffixant par une unité (M, G, etc)
        device=external-journal Attache le système de fichier au périphérique block jounal spécifié. Le journal doit déjà avoir été créé avec mke2fs -O journal_dev external-journal

-l Liste le contenu du superblock du système de fichier.
-L volume-label Définis le label du volume.
-m reserved-blocks-percentage Définis le pourcentage du système de fichier allouable seulement pour les processus root.
-M last-mounted-directory Définis le dernier répertoire de montage pour le système de fichier
-o [^]mount-option[,...] Définis ou efface les options de montage par défaut dans le système de fichier. Les options de montage peuvent être changés par les options dans /etc/fstab ou avec mount. Les options peuvent être effacées avec '^' ou ajoutés avec '+'. Les options suivantes peuvent être ajustées:

        debug Active le code de debuggage
        bsdgroups Émule le comportement BSD en créant de nouveaux fichiers: il prennent le GID du répertoire dans lequel il a été créé.
        user_xattr Active les attributs étendus
        acl Active les ACL posix
        uid16 Désactive les UID/GID 32bits.
        journal_data Quand le système de fichier est mounté avec la journalisation, toutes les données sont envoyées dans le journal avant d'être écrites dans le système de fichier
        journal_data_ordered Quand la journalisation est active, toutes les données sont écrite directement dans le système de fichier avant que ses métadonnées ne soient envoyées au journal
        journal_data_writeback Quand la journalisation est active, les données peuvent être écrite dans le système de fichier après que ses métadonnées aient été envoyées au journal.
        nobarrier Le système de fichier est monté avec des opération barrière dans le journal désactivé.
        block_validity Le système de fichier sera monté avec l'option de validité de block activé, qui créé des vérifications supplémentaires après chaque lecture/écriture. Empêche la corruption des métadonnées. Augmente la charge CPU et mémoire
        discard Le système de fichier sera monté avec l'option de montage discard. Force le pilote à tenter d'utiliser les fonctionnalité trim/discard de certains stockages (SSD) pour informer le périphérique que des blocks appartenant à des fichiers supprimés peuvent être réutilisés
        nodelalloc Le système de fichier sera monté avec l'option nodelalloc, qui désactive l'allocation retardée.

-O [^]feature[,...] Définis ou efface les fonctionnalités dans le système de fichier. Les fonctionnalités peuvent être effacées avec '^' ou ajoutés avec '+'. Les fonctionnalités suivantes peuvent être ajustées:

        dir_index Utilise des b-trees hashés pour accélérer la recherche de nom dans les grands répertoires.
        dir_nlink Autorise plus de 65000 sous-répertoires par répertoire
        encrypt Chiffrement au niveau du système de fichier des blocks de données et des noms de fichier. les métadonnées d'inode (timestamps, taille de fichier, user/groupe, etc) ne sont pas chiffrés
        extent Permet le mappage des numéros de blocks logiques pour un inode particulier vers des blocks physique dans le périphériques de stockage à stocker en utilisant un extent tree, qui est une structure de données plus efficace que le schéma de block indirect traditionnel utilisé par ext2 et ext3. Cela diminue la charge de block de métadonnées, améliore les performances et diminue le besoin de lancer e2fsck sur le système de fichier.
        extra_isize Réserve un quantité d'espace spécifique dans chaque inode pour les métadonnées étendues tels que les timestamps nanoseconde et la date de création de fichier, même si le kernel n'a pas besoin d'un tel espace. Sans cette option, le kernel réserve de l'espace quand il en a besoin. Utile quand la taille d'inode fait au moins 256 octets.
        filetype Active le stockage des information de type de fichier dans le entrées de répertoire.
        flex_bg Permet aux métadonnées de groupes par block (bitmaps d'allocation et tables d'inodes) d'être placés n'importe où. De plus, mke2fs plase ces métadonnées ensemble en commençant au premier groupe de block de chaque "flex_bg group". La taille du groupe flex_bg peut être spécifié avec l'option -G
        has_journal Créé un journal qui s'assure de la consistance du système de fichier même entre les arrêt non-propre. Équivalent à utiliser l'option -j avec mke2fs ou tune2fs.
        huge_file Permet des fichiers supérieurs à 2Tio
        large_file Définis automatiquement quand un fichier supérieur à 2Gio est créé.
        metadata_csum Stocke un checksum pour protéger le contenu de chaque block de métadonnées
        mmp Fournis une protection de montage multipoint. Utile dans les environnements de stockage partagés
        project Fournis le support des quotas de projet. Avec cette fonctionnalité, le project ID de l'inode est géré quand le système de fichier est monté.
        quota Créé des inodes quota (inode #3 pour usrquota, #4 pour grpquota) et les définis dans le superblock. Avec cette fonctionnalité, les quotas sont activés automatiquement quand le système de fichier est monté.
        read-only Force le kernel à mounter le système en lecture-seule
        resize_inode indique que de l'espace a été réservé pour que la table de descripteur de groupe de block puisse être étendue en redimmensionnant un système de fichier monté. L'opération de redimensionnement online est géré par le kernel, piloté par resize2fs. Nécessite également sparse_super.
        sparse_super Indique que les copies backup du superblock et les descripteurs de groupe de block sont présent seulement dans quelques groupes de block, pas tous.
        uninit_bg Indique que les descripteurs de groupe de block sont protégés en utilisant des checksums, permettant à mke2fs de créer un système de fichier sans initialiser tous les groupes de block. Accélère la création des systèmes de fichier.

-p mmp_check_interval Définis l'interval de vérification MMP. Défaut: 5 secondes
-r reserved-blocks-count Définis le nombre de blocks réservés dans le système de fichiers
-Q quota-options Définis les quota dans le superblock:

        [^]usrquota Définis/indéfinis le quota d'inode utilisateur dans le superblock
        [^]grpquota Définis/indéfinis le quota d'inode de groupe dans le superblock
        [^]prjquota Définis/indéfinis le quota d'inode de projet dans le superblock

-T time-last-checked Définis la date de dernière vérification en utilisant e2fsck. Utilise le timezone local.
-u user Définis l'utilisateur qui peut utiliser les blocks réservés.
-U UUID Définis l'UUID du système de fichier. peut être 'clear' (supprime l'UUID), 'random', ou 'time'.
-z undo_file Avant d'écraser un block, écris son contenu dans un fichier undo.
^
31 mars 2017

htmlpdflatexmanmd




tuned

tuned

Service de personnalisation système dynamique

   tuned est un service de personnalisation du système dynamique qui paramètre le système en fonction de l'utilisation

OPTIONS

-c CONFFILE, --conffile=CONFFILE Fichier de configuration. Défaut: /etc/tuned.conf
-d, --daemon Lance en tâche de fond
-d, --debug Mode debug
-l [LOG], --log[=LOG] Log dans le fichier spécifié. Défaut: /var/log/tuned/tuned.log
--no-dbus N'attache pas à DBus
-P [PID], --pid[=PID] Écris le pid dans le fichier spécifié. Défaut: /run/tuned/tuned.pid
-p PROFILE, --profile PROFILE Profile à activer
^
31 mars 2017

htmlpdflatexmanmd




tuned-adm

tuned-adm

Outil d'administration de gestion des profiles

   Cette commande permet de sélectionner les profiles. De nombreux profiles prédéfinis sont déjà inclus, et sont stockés dans /usr/lib/tuned, les profiles utilisateur sont dans /etc/tuned.

OPTIONS

list Liste les profiles disponible
active Affiche le profile courant
profile PROFILE Sélectionne le profile à utiliser
verify Vérifie le profile courant avec les paramètres du système et affiche si les informations correspondent
recommend Affiche le profile recommandé pour le système. Actuellement seul une détection statique est implémentée
off Décharge les paramètres
^
10 mai 2017

htmlpdflatexmanmd




tuned-main.conf

tuned-main.conf

fichier de configuration globale tuned

OPTIONS

daemon=BOOL définis si tuned est utilisé comme service ou non.
dynamic_tuning=bool Définis si le tuning dynamique est activé
sleep_interval=INT délai entre chaque réveil de tuned et de vérification des évènements
update_interval=INT Délai de mise à jour dynamique
recommend_command=BOOL Contrôle si la fonctionnalité recommend est permise ou non
reapply_sysctl=BOOL Contrôle si les paramètres sysctl sont réappliqués depuis /etc/sysctl.conf et les autres emplacement de configuration de sysctl.
default_instance_priority=INT Priorité de l'instance par défaut (défaut: 0)
^
31 mars 2017

htmlpdflatexmanmd




tuned.conf

tuned.conf

Définition de profile tuned

   Les profiles sont stockés dans /etc/tuned/‹profile name›/tuned.conf ou /usr/lib/tuned/‹profile name›/tuned.conf.

[main]

include= Inclus le fichier de configuration spécifié.

PLUGINS

   Toutes les autres sections définissent un plugin. Le nom de la section est le nom du plugin et est utilisé dans les logs. Il ne peut y avoir qu'un plugin de type particulier. Toutes les sections plugin peut contenir les éléments suivants:

        type= type de plugin. (audio, bootloader, cpu, disk, eeepc_she, mounts, net script, selinux, scheduler, sysctl, sysfs, usb, video, vm.
        devices= liste de périphérique qui doivent être paramétrés par ce plugin
        replace=1 S'il y a conflit entre 2 plugins, définis le poid qui permet de choisir le plugin à utiliser
^
11 novembre 2011

htmlpdflatexmanmd




udev

udev

Gestion des périphériques dynamiques

Description

   udev fournis un système d'évènements périphériques, de gestion des permissions des nœuds périphériques, et peut créer des liens symboliques additionnels dans /dev, ou renommer des interfaces réseaux. Le kernel assigne simplement des noms de périphériques basés sur l'ordre de découverte.

  udevd reçois les uevents directement du kernel quand un périphérique est ajouté ou enlevé du système, ou quand son état change. Quand udev reçois un évènement périphérique, il regarde si des règles dans sa configuration correspondent, peut fournir des informations additionnelles à stocker dans la base de données udev, ou des informations pour créer des noms de liens. Tous les processus d'information de périphériques sont stockés dans la base de données udev et envoyés au souscripteur d'évent.

Configuration

   Les fichiers de configuration sont dans /etc/udev et /lib/udev. Toutes les lignes vides, ou commençant par '#' seront ignorés

Fichier de configuration

   Le fichier de configuration principal est /etc/udev/udev.conf. Il consiste de variables permettant à l'utilisateur d'écraser les valeurs

udev par défaut. Les variables sont :
udev_root Spécifie où placer les nœuds de périphériques dans le système de fichier (défaut /dev)
udev_log Le logging priority.

Fichiers de règles

   Les règles par défaut de udev sont lues depuis les fichiers dans /lib/udev/rule.d/, les fichiers personnalisés dans /etc/udev/rules.d/, et les fichiers temporaires dans /dev/.udev/rules.d/. Tous les fichiers de règles sont triés et traités dans l'ordre lexical, sans regarder dans quel répertoire ils sont. Les fichiers dans /etc/udev/rules.d ont une précédence sur les fichiers de même nom dans /lib/udev/rules.d.

   Les fichiers de règles doivent se terminer par .rules, sinon ils sont ignorés. Chaque ligne dans un fichier de règle contient au moins une paire de clé/valeur. Il y'a 2 types de clé, les clés de correspondance et les clés d'assignement. Si toutes les clés de correspondance correspondent avec leurs valeurs, la règle s'applique et les clés d'assignement reçoivent la valeur spécifiée. Une règle de correspondance peut renommer une interface réseau, ajouter les liens pointant vers des nœuds de périphériques, ou lancer un programme spécifique.

   Une règle consiste d'une ou plusieurs paires de clé/valeur séparés par un ','. Chaque clé a une opération distincte, dépendant de l'opérateur utilisé

Opérateurs

== compare l'égalité
!= Compare l'inégalité
= Assigne une valeur à une clé. Les clés qui représentent une liste, sont réinitialisées avec cette valeur simple.
+= Ajoute la valeur à une clé qui maintient une liste
:= Assigne une valeur à une clé, puis empêche de modifier cette valeur ultérieurement.

   Les noms des clés peuvent être utilisés pour faire correspondre les propriétés des périphériques. Certains périphériques matchent également des clés avec les propriétés des périphériques parent dans sysfs. Si plusieurs clés qui match un périphérique parent sont spécifié dans une simple règle, toutes ces clés doivent matcher à un et le même périphérique parent.

ACTION Match le nom de l'action
DEVPATH Match le devpath du périphérique
KERNEL Match le nom du périphérique
NAME Match le nom du nœud ou de l'interface réseau
SYMLINK Match le nom d'un lien ciblant le nœud
SUBSYSTEM Match le nom du pilote du périphérique
ATTR{filename} Match les valeurs d'attribut sysfs du périphérique.
KERNELS Cherche le devpath supérieur pour un nom de périphérique correspondant
SUBSYSTEMS Cherche le devpath supérieur pour un nom de sous-système de périphérique correspondant
DRIVERS Cherche le devpath supérieur pour un nom de pilote de périphérique correspondant
ATTRS{filename} Cherche le devpath supérieur pour un périphérique qui match les valeurs d'attributs sysfs. Si plusieurs ATTRS sont spécifiés, tous doivent matcher sur le même périphérique.
ENV{key} Match avec une valeur de propriété de périphérique.
TAG Match avec un tag de périphérique
TEST{masque octal} Test l'existence d'un fichier. Un masque octal peut être spécifié.
PROGRAM Exécute un programme. La clé est vraie, si le programme retourne un succès. Les propriétés du périphérique sont disponibles pour le programme. La sortie du programme affichée dans stdout est redirigée dans la clé RESULT
RESULT Match la chaîne retournée par un appel PROGRAM.

   De nombreux champs supportent les motifs type shell:

Match aucun, ou un certain nombre de caractères
Match un simple caractère
[] Match un simple caractère spécifié dans les crochets.

   Les clés suivantes peuvent être assignées :

NAME Le nom du nœud de périphérique. Généralement, le kernel définis le nom du nœud par défaut, ou créé et supprime le nœud avant que udev reçoive l'event. Changer le nom du nœud créés des inconsistances et n'est pas supportées. Si le kernel et NAME spécifient des noms différents, une erreur sera loggée. Udev ne modifie que les permissions des nœuds et crée des liens additionnels, qui est une bonne manière pour renommer un nœud. Les liens ne doivent jamais être en conflit avec des noms de nœud.
SIMLINK Le nom de lien ciblant un nœud. Chaque règle qui match va ajouter cette valeur à la liste des liens à créer. Plusieurs liens peuvent être créés en les séparant par un espace. Si plusieurs périphériques demandent le même nom de lien, le lien pointera toujours vers le périphérique avec la plus haute link_priority. Si ce périphérique est supprimé, le lien sera réévalué. Sans link_priority spécifié, le périphérique obtenant le lien ne peut être prédit.
OWNER, GROUP, MODE Les permissions pour le nœud périphérique.
ATTRKEY La valeur qui devrait être écrite dans un attribut sysfs du périphérique de l'évènement
ENVKEY Définis une valeur de propriété du périphérique. Les noms de propriété avec un '.' ne sont pas stockés dans la base ou exportés vers les outils externes ou évènements.
TAG Attache un tag à un périphérique. C'est utilisé pour filtrer les évènements pour les utilisateurs de la fonctionnalité de monitoring de libudev. L'implémentation peut seulement fonctionner efficacement si seulement quelques tags sont attachés aux périphériques.
RUN Ajoute un programme à la liste des programmes à exécuter pour un périphérique spécifique. Cela peut seulement être utilisé pour des tâche très courtes. Les tâches longues bloquent le processus d'évènement. Si RUNfail_event_on-error est spécifié, et que le programme ne retourne pas 0, l'évènement sera marqué comme échoué. Sans chemin absolu, le programme doit être dans /lib/udev. Les chemins avec des espaces peuvent être spécifié entre ''
LABEL Label nommé où un GOTO peut sauter
GOTO Saute à LABEL
IMPORT{type} Importe des variables comme propriétés de périphérique, en fonction de son type:

        program Exécute un programme externe.
        file Importe un fichier texte comme valeur assignée, qui doit être au format de clé d'environnement
        db Importe une simple propriété spécifiée comme valeur assignée la base du périphérique courrant. Ne fonctionne que si la base est déjà remplie par un précédent évènement.
        cmdline Importe une simple propriété depuis la ligne de commande du kernel. Pour de simples flags la valeur de la propriété sera à 1.
        parent Import les clés stockées du périphérique parent.

Sans option, udev choisis entre program et file en fonction du bit exécutable des permissions de fichier
WAIT_FOR Attend qu'un fichier devienne disponible ou 10sec. Le chemin est relatif au périphérique sysfs. Sans chemin spécifié, attend qu'un attribut apparaisse.

Options

link_priority=value Spécifie la priorité des liens crées. (Défaut: 0)
event_timeout= Nombre de seconde qu'un event attend les opérations avant de se terminer de lui-même.
string_escape=none|replace Les caractères non-sûres et de contrôle sont remplacés dans les chaînes utilisé pour le nommage des périphériques.
static_node= Applique les permissions spécifiée dans cette règle à un nœud de périphérique statique avec le nom spécifié. Les nœuds statique peuvent être des modules kernel, ou copiés depuis /lib/udev/devices. Ces nœuds peuvent ne pas avoir de module kernel correspondant au moment où udev est démarré, et permet de piloter les modules chargeable du kernel.
watch Recherche un nœud avec inotify, quand il est fermé après avoir été ouvert en écriture, un uevent de changement sera synthétisé.
nowatch Désactive la recherche de nœud avec inotify

   Les champs NAME, SYMLINK, PROGRAM, OWNER, GROUP, MODE et RUN supportent les substitutions de chaîne dans le style printf. Les substitutions sont:

Options

$kernel, %k Le nom kernel pour ce périphérique
$number, %n Le numéro kernel pour ce périphérique. Par exemple 'sda3' a comme nombre kernel 3.
$devpath, %p Le devpath du périphérique
$id, %b Le nom du périphérique matché pendant la recherche de devpath supérieur pour SUBSYSTEMS, KERNELS, DRIVERS et ATTRS
$driver Le nom du pilote du périphérique matché pendant la recherche du devpath supérieur pour SUBSYSTEMS, KERNELS, DRIVERS et ATTRS
$attrfile, %sfile La valeur d'un attribut sysfs trouvé au périphérique, où toutes les clés de la règle ont matchés.
$envkey, %Ekey Une valeur de propriété de périphérique
$major, %M Le numéro majeur kernel pour le périphérique
$minor, %m Le numéro mineur kernel pour le périphérique
$result, %c La chaîne retournée par le programme externe lancé avec PROGRAM. Une seule partie de la chaîne peut être sélectionnée en spécifiant le numéro comme attribut %cN. Si le numéro est suivi d'un '+', cette partie + plus celles restantes sont substituées.
$parent, %P Le nom du nœud parent
$name Le nom courant du nœud
$links La liste des liens courants, séparés par un espace.
$root, %r La valeur udev_root
$sys, %S Le point de montage sysfs
$tempnode, %N Le nom d'un nœud créé temporairement pour fournir l'accès au périphérique depuis un programme externe avant que le vrai nœud soit créé.
%% Le caractère %
$$ Le caractère $
^
11 novembre 2011

htmlpdflatexmanmd




udevadm

udevadm

Utilitaire de gestion udev

Description

   Utilitaire de gestion d'udev. Il attend un commande et des options spécifiques et contrôle udev en temps réel, les requêtes d'event kernel, gère la queue d'event et fournit des mécanismes de debuggage.

udevadm info

   Requête la base udev pour les informations de périphérique. Peut également requêter les propriétés d'un périphérique dans sa représentation sysfs pour aider à créer des règles udev.

--query=type Requête la base pour un type spécifié de périphérique de données. Nécessite --path ou --name pour identifier le périphérique. Les requêtes valides sont name, symlink, path, property et all.
--path=devpath le devpath du périphérique à requêter
--name=file Le nom du nœud ou du symlink
--root Le répertoire root udev : /dev. Utilisé avec name ou symlink, la requête retourne le chemin absolu.
--attribut-walk Affiche toutes les propriétés sysfs qui peuvent être spécifiés dans les règles udev. Affiche tous les périphériques dans la chaîne, jusqu'à la racine de sysfs.
--device-id-of-file=file Affiche les numéros majeur/mineur du périphérique.
--export-db Exporte le contenu de la base udev

udevadm trigger

   Requête les events de périphérique du kernel. Principalement utilisé pour rejouer les event lors du branchement à froid.

--verbose Affiche la liste des périphériques qui sont pilotés
--dry-run ne pas piloter l'event actuel
--type=type Pilote un type spécifique de périphérique. Les types valides sont : devices, subsystems, failed (défaut : devices)
--action=action Type d'event à piloter. Défaut : change
--subsystem-match=subsystem Pilote les events pour les périphériques appartenant à un sous-systèmes. Peut-être spécifié plusieurs fois et support les motifs type shell.
--subsystem-nomatch=subsystem Ne pilote pas les event pour les périphérique qui appartiennent à un subsystem. Peut-être spécifié plusieurs fois et support les motifs type shell.
--attr-match=attribute=value Pilote les events pour les périphériques qui match un attribut sysfs. Si une valeur est spécifiée, vérifie avec la valeur de l'attribut. Non spécifié, vérifie l'existence de l'attribut. peut-être spécifié plusieurs fois.
--attr-nomatch=attribute=value Ne pilote pas les events pour les périphériques qui match un attribut sysfs. Si une valeur est spécifiée, vérifie avec la valeur de l'attribut. Non spécifié, vérifie l'existence de l'attribut. peut-être spécifié plusieurs fois.
--property-match=property=value Pilote les events pour les périphériques qui match une propriété. Peut-être spécifié plusieurs fois et supporte les motifs type shell
--tag-match=property Pilote les events pour les périphériques qui match le tag. Peut-être spécifié plusieurs fois.
--sysname-match=name Pilote les events pour les périphériques qui match un nom de périphérique. Peut-être spécifié plusieurs fois et supporte les motifs type shell.

udevadm settle

   Regarde la queue d'event udev, qui quitte si tous les events actuels sont handlés.

--timeout=seconds Nombre de seconde max à attendre que la queue d'event soit vide (défaut 180). A 0, retourne immédiatement.
--seq-start=seqnum Attend seulement les event après le numéro de séquence donné.
--seq-end=seqnum Attend seulement les events avant le numéro de séquence donné.
--exit-if-exists=file stop l'attente de l'existence du fichier
--quiet mode silencieux

udevadm control

   Modifie l'état interne de udevd

--log-priority=value Définis le niveau de log. peut être défini sous forme numérique ou err, info et debug.
--stop-exec-queue Signal à udevd de stopper l'exécution des nouveaux events. Les nouveaux events seront mis en queue
--start-exec-queue Signal à udevd d'exécuter les events
--reload-rules Recharge les fichiers de règles. Peu utile vu qu'udevd détecte automatiquement les changements
--property=KEY=value Définis une propriété global pour tous les events
--children-max=value Définis le nombre maximum d'events que udevd va manipuler simultanément.

udevadm monitor

   Écoute les events et les uevents kernels sortis par une règle udev et affiche le devpath de l'event. Peut être utilisé pour analyser le timing d'event, en comparant le timestamps des uevent kernel et des events udev.

--kernel Affiche les uevents kernel
--udev Affiche les events udev après le traitement des règles
--property Affiche également les propriétés de l'event
--subsystem-match=string[/string] Filtre les events par sous-système[type de périphériques]. Seuls les event udev avec un sous-système correspondant vont passer.
--tag-match=string Filtre les events par propriété. Seul les event udev avec le tag donné vont passer.
udevadm test simule un event udev pour un périphérique donné, le devpath doit être spécifié après les options
--action=string La chaîne action
--subsystem=string La chaîne sous-système
^
11 novembre 2011

htmlpdflatexmanmd




udevd

udevd

Service de gestion des périphériques dynamiques

Description

   udevd écoute les évènements kernel. Pour chaque évènement, udevd exécute les instructions correspondant spécifiées dans les règles udev. Au démarrage, le contenu de /lib/udev/devices est copié dans /dev. Si les modules kernel spécifient des noeuds de périphériques statiques, ces nœuds sont créés même sans un périphérique kernel correspondant, permettant un chargement à la demande de ces modules. Les permissions qui match dans les règles udev sont appliquées à ces nœuds de périphérique statiques.

  Le mode de fonctionnement d'udevd peut être changé avec udevadm control

OPTIONS

--daemon daemonise udevd
--debug Mode debug
--children-max= Nombre max d'évènements exécutés en parallèles
--exec-delay= Nombre de secondes d'exécution des instructions RUN.
--resolve-names= Spécifie quand udev devrait résoudre les noms des utilisateurs et des groupes. À early (défaut) les noms sont résolus quand les règles sont parcourues. À late, résout pour chaque event, à never, ne résout jamais les noms et tous les périphériques seront possédés par root.
^
14 décembre 2016

htmlpdflatexmanmd




udiskd

udiskd

Service système udisks

   Le programme udisksd fournis le nom org.freedesktop.UDisks2 dans D-Bus. Les utilisateurs ou administrateurs ne devraient jamais le démarrer vu qu'il est démarré automatiquement par dbus-daemon ou systemd.

OPTIONS

--replace Remplace un service existant
--no-debug N'affiche pas les messages de debug sur stdout/stderr
--no-sigint Ne gère pas SIGINT pour les extinctions contrôlées
^
14 décembre 2016

htmlpdflatexmanmd




udisks

udisks

Gestionnaire de disque

   udisks fournis les interfaces pour énumérer et effectuer des opérations sur les périphériques disques. Toute application (incluant celles privilégiées) peuvent accéder à udisksd via org.freedesktop.UDisks2 dans le D-Bus. De plus, libudisks2 est également fournis. Cette librairie peut être utilisée depuis C/C++ et tout langage haut niveau avec le support de GObjectIntrospection(2).

Contrôle d'accès

   Par défaut, les utilisateurs loggés dans une session active sont autorisés à effectuer des opérations dans les périphériques attachés à leur session. Le contrôle d'accès est basé sur polkit. Noter que l'option x-udisks-auth peut être utilisée dans /etc/fstab et /etc/crypttab pour spécifier quelles autorisations sont requises pour le montage.

Configuration de pilote

   Au démarrage et quand un disque est connecté, udisksd applique la configuration dans /etc/udisks2/IDENTIFIER.conf où IDENTIFIER est la valeur de Drive:Id du périphérique. Si le fichier change sur disque son nouveau contenu sera également appliqué au lecteur. Généralement, les utilisateurs ou administrateurs n'ont jamais besoin d'éditer les fichiers de configuration vu qu'ils sont gérés graphiquement.

Groupe ATA

   Le groupe ATA sert pour les paramètres qui s'appliquent aux disques utilisant le jeu de commande ATA. Les clés suivantes sont supportées:

StandbyTimeout Le timeout de standby. 0 pour le désactiver. entre 1 et 240 spécifie un multiple de 5 secondes. Entre 241 et 251 spécifie de 1 à 11 unités de 30 minutes. 252 signifie un timeout de 21minutes. 253 définis un timeout définis par le vendeur entre 8 et 12 heures, et 254 est réservé. 255 = 21 minutes et 15 secondes.
APMLevel Niveau le gestion de puissant avancée. Une valeur faible signifie un gestion aggréssive, et une valeur élevée offre de meilleurs performances. de 1 à 127 (Autorise le spin-down), 128 à 254 (n'autorise pas le spin-down). Le meilleur niveau de gestion de puissance est obtenue avec 1 et les meilleurs performances E/S avec 254. 255 désactive APM.
AAMLevel Niveau de gestion acoustique automatique. Les disques les plus modernes ont la capacité de réduire la vitesse du mouvement de la tête pour réduire le bruit. Les valeurs vont de 0 à 254. 128 est le plus silencieux et 254 le plus fort. La plupart des disques on 3 options off (0), quiet (128) et fast (254).
WriteCacheEnabled (Bool) spécifie si le cache d'écriture est activé.
ReadLookaheadEnabled (bool) Spécifie si la pré-lecture est activée.

Information de périphérique

   udisks s'appuis sur les versions récentes de udev et du kernel. Les propriétés influençable dans udev incluent:

UDISKS_SYSTEM Définis, remplace la propriété HintSystem
UDISKS_IGNORE Définis, remplace la propriété HintIgnore
UDISKS_AUTO Définis, remplace la propriété HintAuto
UDISKS_CAN_POWER_OFF Définis, remplace la propriété CanPowerOff
UDISKS_NAME Nom à utiliser pour le périphérique en le présentant à une interface utilisateur. Correspond à la propriété HintName
UDISKS_ICON_NAME Icône à utiliser pour le périphérique en le présentant à une interface utilisateur.
UDISKS_SYMBOLIC_ICON_NAME L'icône à utiliser pour le périphérique en le présentant à une interface utilisateur en utilisant un icône symbolique
UDISKS_FILESYSTEM_SHARED à 1, le système de fichier dans le périphérique sera monté dans un répertoire partagé (ex: /media/VolumeName) au lieu d'un répertoire privé (ex: /run/media/$USER/VolumeName) quand la méthode Filesystem.Mount() est utilisée.
ID_SEAT Le siège physique où le périphérique est attaché. Si non définis, seat0 est supposé.
^
14 décembre 2016

htmlpdflatexmanmd




udisksctl

udisksctl

Outil de contrôle udisks

   udisksctl est un programme utilisé pour interragir avec udisksd

Commandes

status Affiche des information sur les disques et périphériques blocks
info Affiche des information détaillées
mount Monte un périphérique dans /media
unmount Démonte un périphérique
unlock Débloque un périphérique chiffré. La passphrase sera demandé et le périphérique déchiffré est affiché sur stdout
lock Bloque un périphérique
loop-setup Définis un périphérique loop
loop-delete Supprime un périphérique loop
power-off Arrange le disque pour être supprimé proprement
smart-simulate Définis les données SMART depuis libatasmart donné par le fichier spécifié. Utilisé à des fins de debuggage
monitor Monitore les évènements du service
dump Affiche l'état courant du service

Options communes

--no-user-interaction Ne demande pas d'interaction utilisateur.
^
14 décembre 2016

htmlpdflatexmanmd




umount.udisks2

umount.udisks2

Démonter les systèmes de fichier qui ont été montés par udisks

   umount.udisks2 est un helper pour le programme umount. Son but est de nettoyer automatiquement les répertoires créés au moment du montage du système de fichier. Il ne devrait pas être appelé directement.

^
14 juillet 2010

htmlpdflatexmanmd




uname

uname

Affiche des informations dur la machine et le système d'exploitation

   uname affiche des informations sur la machine et le système d'exploitation. Sans options, uname agit comme uname -s. Si plusieurs options ou -a sont donnés, les informations sont affichés dans l'ordre:

  KERNEL-NAME NODENAME KERNEL-RELEASE KERNEL-VERSION MACHINE PROCESSOR HARDWARE-PLATFORM OPERATING-SYSTEM

OPTIONS

-a, --all affiche toutes les informations, excèpté le type de processeur et le nom hardware.
-i, --hardware-plateform Affiche le nom de la plateforme hardware.
-m, --machine Affiche le nom hardware de la machine
-n, --nodename Affiche le hostname
-p, --processor Affiche le type de processeur
-o, --operating-system Affiche le nom du système d'exploitation
-r, --kernel-release affiche la version du kernel
-s, --kernel-name Nom du kernel
-v, --kernel-version Affiche la version du kernel
^
15 mars 2010

htmlpdflatexmanmd




unattended-upgrade

unattended-upgrade

Outil de mise à jour de sécurité automatique

   Cet utilitaire installe automatiquement les mises à jour de sécurité. Il est lancé quotidiennement par un cron.

   Il peut télécharger et installer les mises à jour de sécurité automatique, en n'installant que les paquets depuis les sources APT configurés. La sortie est loggé dans /var/log/unattended-upgrades.log Ce script est un utilitaire pour l'option APT::Periodic::Unattended-Upgrade et est conçu pour être lancé par cron via /etc/cron.daily/apt. Il ne possède qu'une seule option: --dry-run qui simule l'installation, mais ne fait rien d'autre.

  La configuration est faite via apt, par défaut dans /etc/apt/apt.conf.d/50unattended-upgrades

^
24 juin 2010

htmlpdflatexmanmd




unexpand

unexpand

Convertit les espaces en tabulation

OPTIONS

-t TAB1[,TAB2]...' , --tabs=TAB1[,TAB2]...' Si seul TAB1 est donné, définit le nombre d'espaces par tabulation (défaut 8). Sinon, définit les espaces TAB1, TAB2, ... au delà, laisse les blancs tels quels.
-a, --all Convertit aussi toute séquence de 2 ou plusieurs blancs juste avant un fin de tabulation, même s'il sont après des caractères non-blanc dans une ligne.
^
21 juillet 2010

htmlpdflatexmanmd




uniq

uniq

Écrit les lignes uniques. Par défaut, écrit les lignes d'entrée, excepté qu'il ignore toutes les lignes adjacentes sauf la première.

OPTIONS

-f N, --skip-fileds=N Ignore N champs sur chaque ligne avant de vérifier les lignes uniques. ces champs ne contiennent pas d'espace ni de tabulation et sont séparés par au moins un espace ou tabulation.
-s N, --skip-chars=N Ignore N caractères sur chaque ligne avant de vérifier les lignes uniques. Si vous utiliser -f et -n, les champs sont ignorés en premier.
-c, --count Affiche le nombre de fois que chaque ligne est trouvé.
-i, --ignore-case Ignore la casse
-d, --repeated Ignore les lignes qui ne sont pas répétées. Il copie la première ligne de chaque ligne répétée.
-D, --all-repetead[=DELIMIT-METHOD] N'ignore pas les lignes répétées, mais ignore les lignes qui ne sont pas répétées. Cette options est utile avec d'autres option pour par exemple ignorer la casse ou comparer certains champs. optionnellement, on peut spécifier comment délimiter les groupes de lignes répétées:

        none Ne délimite pas les groupes de lignes répétées.
        prepend Sort une ligne avant chaque groupe de lignes répétées.
        separate sépare les groupes de lignes répétées avec un simple newline. identique à prepend mais n'insert pas de délimiteur avec le premier groupe.

-u, --unique Ignore la première ligne répétée. affiche les lignes unique.
-e, --zero-terminated Délimite les items avec un octet zéro au lieu d'un newline.
^
02 juillet 2010

htmlpdflatexmanmd




unlink

unlink

Supprimer des liens symboliques

   unlink supprime un simple nom de fichier spécifié via l'appel système unlink.

^
31 mai 2010

htmlpdflatexmanmd




update-rc.d

update-rc.d

Met à jour les liens des scripts init

   Met à jour les liens des scripts init du système dans /etc/rcX.d/ qui ciblent les script dans /etc/init.d/. update-rc.d a 2 modes d'opération pour installer les scripts dans la séquence de boot. Un mode legacy où les arguments de la ligne de commande sont utilisés pour décider la configuration de runlevel; et un mode par défaut où les informations de runlevel et de dépendance sont récupérés depuis l'en-tête du script.

   Si un fichier dans /etc/rcX.d/ existe, update-rc.d ne fait rien. Supprimer les liens manuellement dans les dossiers /etc/rcX.d/ est une erreur commune parce qu'à la prochaine mise à jours du programme, le script postinstall va pré-exécuter update-rc.d qui va recréer les liens. La bonne démarche est de désactiver le service dans tous les runlevels.

   Si default est utilisé, update-rc.d va créer des liens pour démarrer les services dans les runlevels 2345 et de les stopper dans les runlevels 016. Par défaut, tous les liens ont le numéro de séquence de 20, mais peut changer en fonction des dépendances.

   Les script kill sont appelés en premier. En général, le numéro de séquence pour stopper un lien devrait être 100 moins le numéro de séquence pour le démarrer, ce qui force les services à être stoppés dans l'ordre inverse qu'ils ont été démarré. Par contre le numéro de séquence par défaut pour stopper un lien reste 20 par défaut, il s'agit d'un bug historique.

   Le script doit exister dans /etc/init.d/ avant d'utiliser update-rc.d pour créer les liens. Le script doit être supprimé de /etc/init.d/ avant d'utiliser update-rc.d pour supprimer les liens

OPTIONS

-n  Ne fait rien, affiche seulement ce qu'il aurait fait.
-f Force la suppression des liens même si le script existe encore.

Exemples

Inserér les liens en utilisant defaults:
update-rc.d foobar defaults
l'équivalent en utilisant les arguments explicites:
update-rc.d foobar start 20 2 3 4 5 . stop 20 0 1 6 .
Une commande plus courante:
update-rc.d foobar start 30 2 3 4 5 . stop 70 0 1 6 .
Insérer les liens dans les runlevels par défaut quand B requièreA
update-rc.d script_for_A defaults 80 20
update-rc.d script_for_B defaults 90 10
Insérer un lien d'un service qui n'est pas nécessaire à un autre service:
update-rc.d top_level_app defaults 98 02
Insérer un lien qui requière un service qui se lance/se termine avec un numéro de séquence de 20:
update-rc.d script_depends_on_svc20 defaults 21 19
Supprimer tous les liens d'un script (il doit avoir été supprimé avant)
update-rc.d foobar remove
Exemple pour désactiver un service:
update-rc.d -f foobar remove
update-rc.d foobar stop 20 2 3 4 5 .
exemple d'une commande pour installer un script d'initialisation et d'arrêt du système:
update-rc.d foobar start 45 S . stop 31 0 6 .
Exemple d'une commande pour désactiver un script d'initialisation et d'arrêt du système:
update-rc.d -f foobar remove
update-rc.d foobar stop 45 S .
^
13 février 2012

htmlpdflatexmanmd




update-reader.conf

update-reader.conf

Outil pour générer reader.conf

   Outil pour regénérer /etc/reader.conf. Il tente de générer le fichier de configuration depuis les fichiers inclus dans /etc/reader.conf.d/. l’ancienne version est backupée dans /etc/reader.conf.old

OPTIONS

force Si le /etc/reader.conf ne contient pas de tag spécial sur la première ligne, il annule la régénération. Ce paramètre le force à continuer.
^
14 juillet 2010

htmlpdflatexmanmd




uptime

uptime

Affiche l'utilisation du système

   uptime affiche l'heure courante, le nombre d'utilisateurs loggés, et la charge moyenne. Si un fichier est spécifié, uptime lis ce fichier pour voir le nombre d'utilisateurs loggés.

^
29 octobre 2011

htmlpdflatexmanmd




useradd

useradd

Créé ou modifie un utilisateur

   Créé un nouvel utilisateur ou modifie les informations par défaut appliquées aux nouveaux utilisateurs. il s'agit d'un utilitaire bas-niveau, préférer adduser. Invoqué sans -D, créé un nouveau compte utilisateur. Par défaut, un groupe sera également créé pour le nouvel utilisateur.

OPTIONS

-b, --base-dir Répertoire de base par défaut du système si -d n'est pas spécifié. Est concatené avec le nom du compte pour définir le répertoire personnel. Doit exister si -m n'est pas spécifié. Non spécifié, utilise le contenu de la variable HOME dans /etc/default/useradd ou /home par défaut.
-c, --comment Description du compte. Utilisé pour le nom complet de l'utilisateur.
-d, --home Répertoire de l'utilisateur.
-D, --defaults Modifier les valeurs par défaut, voir plus bas.
-e, --expiredate Date d'expiration du compte, au format AAAA-MM-JJ. Non spécifié, utilise la valeur dans /etc/default/useradd, ou vide.
-f, --inactive Nb de jours suivant la fin de validité d'un mot de passe après lequel le compte est définitivement désactivé. -1 désactive cette fonction. Non spécifié, utilise INACTIVE dans /etc/default/useradd, ou -1.
-g, --gid Nom ou gid du groupe initial de connexion de l'utilisateur (quand -N/--no-user-group est utilisé ou quand USERGROUPS_ENAB est à no dans /etc/login.defs). Ce groupe doit exister. Défini GROUP dans /etc/default/useradd.
-s, --shell Nom du shell de l'utilisateur. défini SHELL dans /etc/default/useradd.

Notes

   L'administrateur système doit se charger de placer les fichiers dans /etc/skel, ou tout autre répertoire spécifié dans /etc/default/useradd ou sur la ligne de commande. Vous ne pouvez pas ajouter un utilisateur à un groupe NIS ou LDAP. Il est généralement recommandé d'utiliser des noms qui commencent par une lettre minuscule ou un '_', suivi par des lettre minuscules, chiffres, '_' ou '-'. Peut finir par un '$' en expression régulière: [a-z_][a-z0-9_-]*[$] ?. Sous Debian, ne peut pas commencer par '-', ':' ou un espace blanc (space, end of line, \n, tabulation, \t, etc). Les noms d'utilisateurs sont limités à 16 caractères.

Configuration

   Les variables de /etc/login.defs modifient le comportement de cet outil:

CREATE_HOME indique si le répertoire personnel doit être créé ou non. Ne s'applique pas pour les utilisateurs systèmes, peut être annulé sur la ligne de commande
GID_MAX GID_MIN Plage de GID que useradd, groupadd et newusers peuvent utiliser pour la création des groupes.
MAIL_DIR répertoire d'attente des mails.
MAIL_FILE Emplacement des boîtes aux lettres des utilisateurs
MAX_MEMBERS_PER_GROUP Nombre maximum de membres par entrée de groupe. Une fois la limite atteinte une nouvelle entrée dans /etc/group avec le même nom, mdp et GID est créé. A 0, pas de limite (défaut). Permet de limiter la longueur des lignes dans le fichier de groupes (utile pour NIS).
PASS_MAX_DAYS Nb max de jour de validité d'un mot de passe. (-1 désactive cette option)
PASS_MIN_DAYS nb mini de jours autorisés avant la modification d'un mot de passe. (-1 désactive cette option)
PASS_WARN_AGE Nombre de jours durant lesquels l'utilisateur recevra un avertissement avant que son mot de passe n'arrive à expiration. (valeur négative désactive cette option).
SYS_GID_MAX SYS_GID_MIN Plage de GID utilisé pour la création des groupes systèmes.
SYS_UID_MAX SYS_UID_MIN Plage d'UID pour la création des utilisateurs systèmes
UID_MAX UID_MIN Plage d'UID pour la création d'utilisateurs normaux.
UMASK Masque de mode pour la création de fichiers. (défaut : 022)
USERGROUPS_ENAB à yes, userdel supprimera le groupe de l'utilisateur s'il ne contient pas d'autres membres et useradd créera par défaut un groupe portant le nom de l'utilisateur.

Valeurs de retour

0 succès
1 impossible de mettre à jour le fichier des mots de passe
2 erreur de syntaxe
3 paramètre non valable pour l'option
4 UID déjà utilisé
6 le groupe n'existe pas
9 Nom d'utilisateur déjà utilisé
10 impossible de mettre à jours le fichier des groupes
12 impossible de créer le répertoire personnel
13 impossible de créer le répertoire d'attente des courriels
^
29 octobre 2011

htmlpdflatexmanmd




userdel

userdel

Supprime un utilisateur et les fichiers associés. userdel est un utilitaire bas niveau, préférer deluser.

OPTIONS

-f, --force Force la suppression de l'utilisateur, même s'il est encore connecté. force également à supprimer son répertoire personnel ou sa file d'attente des mails. commande dangereuse et pouvant laisser le système dans un état incohérent.
-r, --remove les fichiers dans le home de l'utilisateur seront supprimés avec le répertoire lui-même et le répertoire des mails.

Configuration

les variables dans /etc/login.defs:
MAIL_DIR
MAIL_FILE
MAX_MEMBERS_PER_GROUP
USERDEL_CMD Cette commande est exécutée lors de la suppression d'un utilisateur.
USERGROUPS_ENAB

Avertissement

   userdel ne permet pas la suppression d'un compte si des processus actifs lui appartiennent encore.
^
29 octobre 2011

htmlpdflatexmanmd




usermod

usermod

Modifie un compte utilisateur.

OPTIONS

-a, --append Ajoute l'utilisateur aux groupes supplementaires. ne l'utiliser qu'avec -G
-c, --comment Modifier le commentaire. Généralement modifié avec chfn.
-d, --home Change le répertoire de l'utilisateur
-e, --expiredate Date de désactivation du compte au format AAAA-MM-JJ
-f, --inactive Nb de jours suivant la fin de validité d'un mot de passe après lequel le compte est désacivé.
-g, --gid Nom du groupe principal de l'utilisateur. Le groupe doit exister. Tous les fichiers dans le répertoire home de l'utilisateur seront modifié avec ce nouveau groupe.
-G, --groups liste des groupes supplémentaire séparés par des ','. Si un groupe dont il fait partie n'est pas listé, il sera supprimé de ce groupe, sauf avec -a.
-l, --login Change le nom de connexion.
-L, --lock Vérrouiller le mot de passe d'un utilisateur. Ajoute un ' !' devant le mot de passe chiffré. ne peut pas être utilisé avec -p ou -U
-m, --move-home déplace le contenu du répertoire personnel.
-o, --non-unique Avec -u, permet de changer le UID vers une valeur déjà utilisée.
-p, --password mot de passe chiffré, comme renvoyé par crypt.
-s, --shell Nom du nouveau shell de l'utilisateur.
-u, --uid UID de l'utilisateur. la boite aux lettre et le contenu de son home seront automatiquement modifiés.
-U, --unlock Dévérouiller le mot de passe de l'utilisateur. Supprime le ' !' devant le mot de passe chiffré.
-Z, --selinux-user Identifiant SELinux du nouvel utilisateur. vide par défaut.

Configuration

Variable utilisée dans /etc/login.defs
MAIL_DIR
MAIL_FILE
MAX_MEMBERS_PER_GROUP
^
13 juillet 2010

htmlpdflatexmanmd




users

users

Affiche une liste d'utilisateurs loggés sur l'hôte

   users affiche sur une ligne une liste des utilisateurs actuellement loggés sur l'hôte. Chaque nom d'utilisateur correspond à une session, donc un utilisateur peut apparaitre plusieurs fois.

  Sans argument, users extrait ses informations depuis /var/run/utmp ou /etc/utmp. Si un fichier est donné en argument, users utilise ce fichier à la place ex: /var/log/wtmp.

^
07 mai 2017

htmlpdflatexmanmd




/etc/selinux/<SELINUXTYPE>/contexts/users/<se_user>

/etc/selinux/‹SELINUXTYPE›/contexts/users/‹se_user›

Fichiers contenant les entrées qui permettent de déterminer le contexte d'un utilisateur à l'ouverture d'une session

   Il y a un fichier pour chaque utilisateur SELinux configuré dans le système. Chaque ligne dans le fichier de configuration a le format login_process user_login_process

login_process consiste d'une entrée role:type[:range] qui représente le contexte du processus de login
user_login_process consiste d'une entrée role:type[:range] qui représente le contexte du processus de login de l'utilisateur

Exemple


system_r:crond_t:s0 xguest_r:xguest_t:s0
system_r:initrc_t:s0 xguest_r:xguest_t:s0
system_r:local_login_t:s0 xguest_r:xguest_t:s0
system_r:remote_login_t:s0 xguest_r:xguest_t:s0
system_r:sshd_t:s0 xguest_r:xguest_t:s0
system_r:xdm_t:s0 xguest_r:xguest_t:s0
xguest_r:xguest_t:s0 xguest_r:xguest_t:s0
^
31 mars 2017

htmlpdflatexmanmd




varnetload

varnetload

Outil pour créer un trafficvarnetload réseau

   varnetload est un script python pour créer un traffic réseau reproductible. Pour l'utiliser correctement, il faut un serveur http présent sur le réseau LAN où on peut envoyer des fichiers. Uploader un grand fichier sur le serveur http.

OPTIONS

delay Délai entre les téléchargements individuels en ms. Défaut: 1000
time to run Définis le temps total d'exécution en secondes. Défaut: 60
url url de la ressource. Défaut: http://myhost.mydomain/index.html
^
21 mars 2017

htmlpdflatexmanmd




vblade

vblade, vbladed

Export des données via ATA sur Ethernet

   La commande vblade démarre un processus qui utilise des sockets raw pour effectuer de l'AOE, agissant comme un EtherDrive virtuel blade. le script vbladed peut être utilisé pour mettre le processus vblade en tâche de fond.

OPTIONS

-b ‹count› Compteur de tampon, spécifie le nombre max de messages que le serveur peut mettre en file d'attente de traitement
-d sélectionne le mode O_DIRECT pour l'accès au périphérique block
-s Sélectionne le mode O_SYNC pour l'accès au périphérique block
-r Restreint l'export du périphérique en lecture-seule
-m ‹MAC›[,MAC...] Liste d'adresses MAC autorisées à accéder au service
-o ‹num› Nombre de secteurs au début du fichier exporté qui sont exclus de l'export
-l ‹num› Nombre de secteurs à exporter
‹shelf› Adresse AOE majeur du périphérique à créer
‹slot› Adresse AOE mineur du périphérique à créer
‹netif› Nom de l'interface réseau à utiliser pour les communications
‹filename› Périphérique à exporter

Exemples

vblade 11 1 eth0 /dev/sdb
^
17 mars 2010

htmlpdflatexmanmd




vconfig

vconfig

Utilitaire de configuration de VLANs

   Il permet de créer et supprimer des périphériques-vlan. Les périphériques-vlan sont des périphérique ethernet virtuels qui représentent les réseaux virtuels sur un réseau physique.

OPTIONS

add [interface-nome] [vlan-id] Crée un périphérique-vlan sur l'interface.
rem [vlan-device] supprimer un périphérique-vlan
set_flag [vlan-device] 0 | 1 À 1 les en-tête ethernet sont activés, dumper l'interface va apparaître comme une trame non taguée.
set_egress_map [vlan-device] [skb-priority] [vlan-qos] tague les trames sortantes avec un skb-priority particulier avec la priorité vlan skb-qos.
set_ingress_map [vlan-device] [skb-priority] [vlan-qos] tague les trames entrantes avec un skb-priority particulier avec la priorité vlan skb-qos.
set_name_type VLAN_PLUS_VID | VLAN_PLUS_VID_NO_PAD | DEV_PLUS_VID | DEV_PLUS_VID_NO_PAD Règle la manière dont les noms des périphérique vlan sont crées.
^
03 février 2016

htmlpdflatexmanmd




vcs

vcs, vcsa

Mémoires des consoles virtuelles

   /dev/vcs0 est un périphérique caractère de numéro majeur 7 et mineur 0, avec les permissions 0644 et un propriétaire root:tty. Il correspond à la mémoire d'affichage de la console virtuelle en cours d'utilisation.

   /dev/vcs[1-63] sont des périphériques caractères représentant la mémoire d'affichage des consoles virtuelles. Ils ont un numéro majeur 7 et mineurs de 1 à 63. Ils ont généralement un mode d'accès 0644 et un propriétaire root:tty. Les /dev/vcsa[0-63] sont équivalents mais utilisent des entiers non-signés court (dans l'ordre des octets de l'hôte) qui incluent les attributs, et sont préfixés avec 4 octets indiquant les dimensions de l'écran et la position du curseur: lines, columns, x, x, (x = y = 0 en haut à gauche).

   Lorsqu'une police à 512 caractères est chargée, la position du 9e bit peut être extraite en appliquant l'opration ioctl(2) VT_GETHIFONTMASK sur /dev/tty[1-63]; la valeur est renvoyée dans l'entier de type non-signé court pointé par le troisième paramètre de ioctl(2).

   Ces périphériques remplacent les opérations ioctl(2) screedump des console(4), ainsi l'administrateur peut contrôler les accès en utilisant les permissions du système de fichiers.

Les périphériques pour les 8 premières consoles virtuelles peuvent être créés ainsi:
for x in 0 1 2 3 4 5 6 7 8; do
    mknod -m 644 /dev/vcs$x c 7 $x;
    mknod -m 644 /dev/vcsa$x c 7 $[$x+128];
done
chown root:tty /dev/vcs*

Exemple

On peut faire un screendump de la console vt3 en basculant sur vt1 et en tapant:
cat /dev/vcs3 ›foo
Noter que la sortie ne contient pas de caractères de retour-chariot, quelques manipulations peuvent être nécessaires comme:
old -w 81 /dev/vcs3 | lpr
ou
xetterm -dump 3 -file /proc/self/fd/1

Ce programme affiche le caractère et l'attribut d'écran sous le curseur de la seconde console virtuelle, puis y change la couleur de fond:
#include ‹unistd.h›
#include ‹stdlib.h›
#include ‹stdio.h›
#include ‹fcntl.h›
#include ‹sys/ioctl.h›
#include ‹linux/vt.h›
    
int
main(void)
{
    int fd;
    char *device = "/dev/vcsa2";
    char *console = "/dev/tty2";
    struct {unsigned char lines, cols, x, y;} scrn;
    unsigned short s;
    unsigned short mask;
    unsigned char ch, attrib;
    
    fd = open(console, O_RDWR);
    if (fd ‹ 0) {
        perror(console);
        exit(EXIT_FAILURE);
    }
    if (ioctl(fd, VT_GETHIFONTMASK, &mask) ‹ 0) {
        perror("VT_GETHIFONTMASK");
        exit(EXIT_FAILURE);
    }
    (void) close(fd);
    fd = open(device, O_RDWR);
    if (fd ‹ 0) {
        perror(device);
        exit(EXIT_FAILURE);
    }
    (void) read(fd, &scrn, 4);
    (void) lseek(fd, 4 + 2*(scrn.y*scrn.cols + scrn.x), 0);
    (void) read(fd, &s, 2);
    ch = s & 0xff;
    if (attrib & mask)
        ch |= 0x100;
    attrib = ((s & ~ mask) ›› 8);
    printf("ch='%c' attrib=0x%02x\n", ch, attrib);
    attrib ^= 0x10;
    (void) lseek(fd, -1, 1);
    (void) write(fd, &attrib, 1);
    exit(EXIT_SUCCESS);
}

^
24 mars 2016

htmlpdflatexmanmd




veritysetup

veritysetup

Gère les volumes dm-verity

   veritysetup est utilisé pour configurer les mappages device-mapper dm-verity. Les cibles verity fournissent une vérification d'intégrité transparente des périphériques block utilisant l'API crypto kernel. Les périphériques dm-verity sont toujours lecture-seule.

Opérations

format ‹data_device› ‹hash_device› Calcule et stocke Les données de vérification de hash de manière permanente pour le périphérique. La zone de hash peut être localisée sur le même périphérique après que les données soient spécifiées par l'option --hash-offset. Il est nécessaire de fournir la chaîne de hash root pour la vérification du périphérique ou l'activation. Le hash root doit être trusté. Les argument hash et data peuvent être un périphérique block ou un fichier image. Si le périphérique de hash n'existe pas il sera créé
create ‹name› ‹data_device› ‹hash_device› ‹root_hash› Créé un mappage du nom sur le périphérique donné en utilisant le hash pour la vérification par le kernel. root_hash est une chaîne hexadécimale.
verify ‹data_device› ‹hash_device› ‹root_hash› Vérifie a donnée dans le périphérique en utilisant les blocks de hash stocké dans hash_device. Cette commande effectue une vérification dans l'espace utilisateur, aucun périphérique kernel n'est créé.
remove ‹name› Supprime le mappage existant spécifié
status ‹name Affiche le status pour la mappage verity actif spécifié
dump ‹hash_device› Repporte les paramètres du périphérique verity depuis le superblock stocké sur disque

OPTIONS

-v, --verbose mode verbeux
--debug Mode debug
--no-superblock Créé ou utilise dm-verify sans superblock sur disque permanent
--format=number Spécifie le type de hash (actuellement: 1)
--data-block-size=bytes Utilise la taille de block spécifiée pour le périphérique de donnée.
--hash-block-size=bytes Utilise la taille de block spécifiée pour le périphérique de hash
--data-blocks=blocks Taille du périphérique de donnée utilisée pour la vérification. Non spécifié, tout le périphérique est utilisé
--hash-offset=bytes Offset de la zone de hash dans le périphérique de hash. La valeur doit être alignée à l'offset du secteur disque
--salt=hex string Salt à utiliser pour le formattage ou la vérification. Format est une chaîne hexadécimale
--uuid=UUID Utilise l'UUID fournis pour la commande format au lieu d'en générer un nouveau

Codes de retour

0 L'opération s'est déroulé avec succès
1 Mauvais paramètres
2 N'a pas les permissions
3 Out of memory
4 Mauvais périphérique spécifié
5 Le périphérique existe déjà
^
23 mai 2016

htmlpdflatexmanmd




vgcfgbackup

vgcfgbackup

Sauvegarde l'aire descripteur du volume group

   Permet de backuper les métadonnées des volumes group. Sans nom de volume group, tous sont sauvegardés. Dans une installation par défaut, chaque volume group et sauvegardé dans un fichier séparé portant le nom du volume group dans /etc/lvm/backup.

OPTIONS

-f, --file spécifie un fichier alternatif pour le backup. Sans nom de vg spécifié, %s est remplacé par le nom du VG.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule tel que lvchange -ay et vgchange -ay même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgcfgrestore

vgcfgrestore

Restaure l'aire de descripteur de volume group

   vgcfgrestore permet de restaurer les métadonnées du volumes group depuis un fichier de sauvegarde produit par vgcfgbackup. Si aucun backup n'est spécifié, le plus récent est utilisé. Utiliser --list pour lister les sauvegardes disponible et les fichiers archives

OPTIONS

-l, --list Liste les fichiers de sauvegarde et archive pertinent pour le VG spécifié.
-f, --file filename Nom d'un fichier de sauvegarde, généralement créé avec vgcfgbackup.
--force Nécessaire pour restaurer les métadonnées avec les volumes thin. note: de nombreux changements ne peut pas être inversé dans les métadonnées thin, on peut perdre des données si la restoration ne matche par les métadonnées du pool thin précisemment.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-M|--metadatatype 1|2 Spécifie quel type de métadonnée utiliser
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Remplacer des volumes physiques

   vgdisplay --partial --verbose affiche les UUID et tailles de tout PV qui ne sont plus présents. Si un PV dans le VG est perdu et que l'on souhaite substituer un autre de même taille, utiliser vpcreate --restorefile filename --uuid uuid pour l'initialiser avec le même UUID que le PV manquant. Puis utiliser vgcfgrestore --file filename pour restaurer les métadonnées du VG.
^
08 juin 2016

htmlpdflatexmanmd




vgchange

vgchange

Changer les attributs d'un volume group

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-a|--activate [a|e|s|l] {y|n} Contrôle la disponibilité des volumes logiques dans le volume groupe. Si l'autoactivation est utilisée (-aay), chaque volume logique est activé seulement s'il match un élément dans le jeu activation/auto_activation_volume dans lvm.conf. L'activation d'un volume logique créé un lien /dev/VolumeGroupName/LogicalVolumeName pointant vers le nœud. Ce lien est supprimé à la désactivation. Dans un VG clusterisé, clvmd est utilisé pour l'activation, -aey active le LV en mode exclusive, permettant à un seul nœud d'activer le LV. -asy active le LV en mode partagé. -ay, active le LV en mode partagé si le type de LV permet l'accès concurrent, sinon en mode exclusif. Avec -an, clvmd tente de désactiver le LV sur tous les nœuds. -aly active le LV seulement sur le nœud local.
--activationmode {complete|degraded|partial} Le mode d'activation détermine si les volumes logiques sont autorisés à être activés quand il y a des volumes physiques manquant. complete est le plus restrictif. degraded autorise les LV RAID même si des PV sont manquant (mirror n'est pas considéré comme LV raid). partial permet d'activer tout LV même si des portions sont manquants
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
--monitor {y|n} Démarre/arrête la supervision d'un volume logique mirroré ou snapshot avec dmeventd, si installé. Si un périphérique utilisé par un mirroir supervisé reporte une erreur d'E/S, l'erreur est gérée en accord avec mirror_image_fault_policy et mirror_log_fault_policy dans lvm.conf
--poll {y|n} Sans le polling de transformation en tâche de fond d'un volume logique le processus ne se complète jamais. S'il y a un pvmove ou lvconvert incomplet, utiliser --poll y pour relancer le processus.
-c|--clustered {y|n} Si le lock clustered est activé, indique si ce VG est partagé avec d'autres nœuds dans le cluster ou s'il contient seulement des disques locaux non visible aux autres nœuds.
-u|--uuid Génère un nouvel UUID aléatoire pour les volumes groups spécifiés
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--deltag Tag Supprime le tag spécifié
--detachprofile Détache tous les profiles de configuration de métadonnées attachés aux VG donnés.
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés.
--sysinit Indique que vgchange est invoqué à l'initialisation du système, avant que les systèmes de fichier soient accessibles. Est équivalent à --ignorelockingfailure --ignoremonitoring --poll n et définir la variable d'environnement LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--lock-start Démarrare le lockspace du VG partagé dans lvmlockd. les locks lvmlockd deviennent disponibles pour le VG, permettant à LVM d'utiliser le vg.
--lock-stop Stop le lockspare du VG partagé dans lvmlockd.
--lock-type LockType Change le type de lock VG
-l|--logicalvolume MaxLogicalVolumes Change le nombre maximum de LV d'un VG inactif
-p|--maxphysicalvolumes MaxPhysicalVolumes Change le nombre maximum de volumes physiques qui peuvent appartenir à ce VG. Pour les VG avec un format de métadonnées lvm1, la limite est 255. Au format lvm2, 0 supprime cette restriction.
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-P|--partial Définis, les outils fond de leur mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement. Quand un partie d'un volume logique est manquant, /dev/ioerror est substitué, et dmsetup peut être utilisé pour retourner les erreurs I/O.
-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] Change la taille d'extent physique dans les volumes physiques de ce VG. Avant d'augmenter la taille d'extent, utiliser lvresize, pvresize et/ou pvmove.
-S|--select Selection Critère de sélection
--systemid SystemID Change le system_id du VG.
--refresh Si un volume logique dans le volume group est actif, recharge ses métadonnées. Ce n'est pas nécessaire dans une opération normale, mais est utile si quelque-chose ne va pas ou en faisant un cluster manuellement.
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-x|--resizeable {y|n} Active/désactive l'extension/réduction de ce volume group avec/par les volumes physique

Exemples

Active tous les VG connus dans le système
vgchange -a y
Change le nombre maximum de volumes logique du VG inactif vg00 à 128
vgchange -l 128 /dev/vg00
^
23 mai 2016

htmlpdflatexmanmd




vgck

vgck

Vérifie les métadonnées de volume group

   vgck vérifie les métadonnées LVM pour chaque VG.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgconvert

vgconvert

Convertisseur de format des métadonnées

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
--labelsector Par défaut, 4 secteurs du volume physique sont scannés pour un label LVM, en commençant au secteur 0. Ce paramètre permet de spécifier un secteur différent de départ
--bootloaderareasize size Créé une zone bootloader séparée à la taille spécifiée à côté de la zone de données
-M|--metadatatype type Spécifie quel type de métadonnée à utiliser
--pvmetadatacopies NumberOfCopies Nombre de zones de métadonnées à définir dans chaque PV (0,1 ou 2)
--metadatasize size Quantité d'espace approximative à définir pour chaque zone de métadonnées. La taille peut être arrondie.

Exemples

Convertis le volume group vg1 du format LVM1 vers LVM2:
vgconvert -M2 vg1

Récupération

   Utiliser pvscan pour voir quels PV ont perdu leur métadonnées. Lancer pvcreate avec --uuid et --restorefile dans chaque PV pour le reformater, en utilisant le fichier archive que vgconvert a créé au début de la procédure. Finalement, lancer vgcfgrestore avec ce fichier archive pour restaurer les métadonnées d'origine.
^
08 juin 2016

htmlpdflatexmanmd




vgcreate

vgcreate

Créer un volume group

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-c|--clustered {y|n} Si le locking est activé, est à yes par défaut, indiquant que ce volume group est partagé avec d'autres nœuds dans le cluster.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-l|--maxlogicalvolumes MaxLogicalVolumes Définis le nombre maximum de LV du VG
-M|--metadatatype type Spécifie quel type de métadonnée utiliser
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
-p|--maxphysicalvolumes MaxPhysicalVolumes Définis le nombre maximum de volumes physiques qui peuvent appartenir à ce VG. Pour les VG avec un format de métadonnées lvm1, la limite est 255. Au format lvm2, 0 supprime cette restriction.
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] Définis la taille d'extent physique dans les volumes physiques de ce VG
--shared Créé un VG partagé en utilisant lvmlockd
--systemid SystemID Définis le system_id du VG.
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Créer un VG "test_vg" utilisant les volumes physiques /dev/sdk1 et /dev/sdl1 avec une taille d'extents physique par défaut de 4Mio
vgcreate test_vg /dev/sdk1 /dev/sdl1
^
24 mai 2016

htmlpdflatexmanmd




vgdisplay

vgdisplay

Affiche les attributs des volume group

   vgdisplay permet de voir les attributs des volumes group avec ses volumes logiques et physique et leur taille. vgs est une alternative qui fournis les même informations dans le style de ps.

OPTIONS

-A|--activevolumegroups Ne sélectionne que les volumes groupe actifs. Le volume group est considéré actif si au moins un de ses volume logique est actif.
-c|--colon Affiche la sortie en colonne.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-s|--short Donne un listing court affichant l'existance du volume group
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-C|--columns Sortie séparée par des ':'
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field1[,Field2...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. gv_all sélectionne toutes les colonnes de volume group.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
^
23 mai 2016

htmlpdflatexmanmd




vgexport

vgexport

Créer des volumes inconnus du système

   vgexport permet de créer des Volumes Group inactifs inconnus du système. Il permet ainsi de déplacer tous les volumes physiques dans ce VG vert un système différent pour un import ultérieur (vgimport). La plupart des outils LVM2 ignorent les VG exportés. vgexport efface l'ID système et vgimport le définis.

OPTIONS

-a, --all Exporte tous les VG inactifs
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
^
06 juin 2016

htmlpdflatexmanmd




vgextend

vgextend

Ajouter des volumes physiques à un groupe de volume

   vgextend permet d'ajouter des volumes physiques à des volumes groupe pour l'étendre. De plus, il permet de ré-ajouter un volume physique qui était manquant dû à une erreur.

   Si le chemin du périphérique physique n'a pas été précédemment configuré pour LVM avec pvcreate, le périphérique est initialisé avec les même valeurs par défaut qu'utilisées par pvcreate. Si d'autres valeurs sont souhaitées, elles peuvent être données sur la ligne de commande avec les même options de pvcreate. Noter que les options de restauration ne sont pas disponibles. Si une opération de restauration est nécessaire, utilise pvcreate et vgcfgrestore.

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--command-profile ProfileName Sélectionne le profile de configuration de commande à utiliser
--restoremissing Permet de réajouter un volume physique sans le ré-initialiser
-f|--force Ne demande pas confirmation
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Options d'initialisation du périphérique

   Les options de suivis sont disponible pour l'initialisation des périphériques physique dans le volume groupe.

-f, --force Ne demande pas confirmation
-y, --yes Répond oui à toutes les questions
-Z, --zero {y|n} Spécifie les 4 premiers secteurs (2048octets) du périphérique devraient être supprimés
--labelsector sector Permet d'utiliser un secteur différent près du début du disque (entre 0 et 3) où placer l'identifiant LVM2 du PV
--metadatasize size Quantité d'espace approximative d'espace à définir pour chaque zone de métadonnée (la taille peut être arrondie)
--metadataignore {y|n} Ignore les zones de métadonnée sur le volume physique
--pvmetadatacopies copies Nombre de zones de métadonnées à définir dans chaque PV (0, 1 ou 2)
--dataalignment alignment Aligne le début des données à un multiple de ce nombre.
--dataalignmentoffset alignment_offset Décale de début de la zone de données par l'offset spécifié

Exemples

Étendre le volume group vg00 en ajoutant /dev/sda4 et /dev/sdn1
vgextend vg00 /dev/sda4 /dev/sdn1
^
23 mai 2016

htmlpdflatexmanmd




vgimport

vgimport

les volumes group exportés sont connus du système

   vgimport permet de créer un volume group qui a été précédemment exportés avec vgexport et les rend connus du système. vgexport supprime l'ID système VG et vgimport de définis.

OPTIONS

-a, --all importe tous les VG exportés
--force Importe les VG exportés même s'il y a des volumes physique manquant.
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgimportclone

vgimportclone

importe et renomme des volumes group dupliqués

   vgimportclone est utilisé pour importer un VG dupliqué (ex: un snapshot hardware). Les VG et PV dupliqués ne peuvent pas être utilisés tant qu'ils ne peuvent pas coexister avec les VG et PV d'origine. vgimportclone renome le VG associé avec les PV spécifiés et change les uuid de VG et PV associés.

OPTIONS

-n, --basevgname VolumeGroupName Par défaut le snapshot VG sera renommé au nom original + un suffixe numérique. Cette option spécifie un autre nom.
-i, --import Importe les VG exportés. Sinon les VG qui ont été exporté ne seront pas changés (ni leur PV associés)

Variables d'environnement

LVM_BINARY Le binaire LVM2 à utiliser. Défaut: lvm

Exemples

le VG d'origine vg00 a les PV d'origine /dev/sda et /dev/sdb, et les snapshots respectifs sont /dev/sdc et /dev/sdd. Pour renommer le VG associé en vg00_snap:
vgimportclone --basevgname vg00_snap /dev/sdc /dev/sdd
^
23 mai 2016

htmlpdflatexmanmd




vgmerge

vgmerge

fusionne 2 volumes groupes

   Le second volume group spécifié inactif sera fusionné dans le premier si la taille d'extent physique sont identiques et que les sommaires de volume physique et logique des 2 volumes groupe rentrent dans les limites.

OPTIONS

-l, --list Affiche le volume fusionné comme vgdisplay -v
-t, --test Fait un test sans effecter de changement
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug définis le niveau de débug, de 1 à 6 fois pour augmenter les détails.è
-v|--verbose Mode verbeux

Exemples

fusionne le volume inactif 'my_vg' dans le volume group 'database':
vgmerge -v databases my_vg
^
23 mai 2016

htmlpdflatexmanmd




vgmknodes

vgmknodes

recréé un répertoire VG et les fichiers spéciaux LV

   Vérifie les fichiers spéciaux LVM2 dans /dev qui sont nécessaire pour les volumes logiques actifs et créé ceux qui manque et supprime ceux inutilisés.

OPTIONS

--refresh Si un volume logique dans le volume group est actif, recharge ses métadonnées. Ce n'est pas nécessaire dans une opération normale, mais est utile si quelque-chose ne va pas ou en faisant un cluster manuellement.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgreduce

vgreduce

Réduire un volume group

   vgreduce permet de supprimer un ou plusieurs volumes physiques non-utilisés d'un volume group

OPTIONS

-a|--all Supprime tous les volume physiques vide si aucun n'est donné sur la ligne de commande
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--removemissing Supprime tous les volumes physique manquant du volume group, s'il n'y a pas de volumes logique alloué dessus. Cela permet de retourner en mode d'opération normal pour le volume group.
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

   S'il n'est pas possible de spécifier les volumes physiques manquant avec --removemissing et qu'on ne peut/veut pas les supprimer manuellement, on peut lancer cette option avec --force pour supprimer tous LV partiel.

  Tous volumes logique et snapshots dépendants qui font partie de disques manquant sont supprimés completement. Cela inclus ces parties qui sont présent sur les disques qui sont présents.

  Si vos volumes logiques sont répartis sur de nombreux disques incluant ceux qui sont perdus, vous pourriez souhaiter essayer de sauver les données en activant les volumes logiques avec --partial.
^
23 mai 2016

htmlpdflatexmanmd




vgremove

vgremove

Supprimer un volume group

   vgremove permet de supprimer un ou plusieurs volume group. Si un ou plusieurs volumes physiques dans le volume group sont perdus, utiliser vgreduce --removemissing pour recréer une consistance des métadonnées. S'il y a des volumes logique qui existent dans le volume group, un confirmation est demandée.

OPTIONS

-f, --force Force la suppression de la confirmation si des LV existent dans le VG
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-f|--force Ne demande pas confirmation
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-S|--select Selection Ne traite que les lignes qui matchent le critère donné
-t|--test Lance en mode test
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgrename

vgrename

Renommer un volume group

   vgrename renomme un volume group existant. Tous les volumes group visible au système doivent avoir un nom différent. Sinom de nombreuses commandes LVM2 vont refuser de fonctionner.

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Renomme le volume group vg02 en my_volume_group:
vgrename /dev/vg02 /dev/my_volume_group
ou
vgrename vg02 my_volume_group
Changer le nom du volume group avec un uuid en VolGroup00_tmp
vgrename Zvlifi-Ep3t-e0Ng-U42h-o0ye-KHu1-nl7Ns4 VolGroup00_tmp
^
24 mai 2016

htmlpdflatexmanmd




vgs

vgs

Affiche des informations sur les volumes group

OPTIONS

--all Inclus tous les volumes group
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. gv_all sélectionne toutes les colonnes de volume group.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--rows Affiche les colonnes brutes
^
23 mai 2016

htmlpdflatexmanmd




vgscan

vgscan

Scanne tous les disques à la recherche des volumes group et reconstruit les caches

   vgscan scanne tous les disques SCSI, (E)IDE, md et d'autres types de disques dans le système à la recherche de volumes physiques LVM et de volumes groupe. Définir un filtre dans lvm.conf pour restreindre le scanne et éviter un cd-rom par exemple. Dans LVM2, vgscan est automatique, mais il peut être nécessaire de le lancer après un changement hardware.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--mknodes Vérifie également le fichiers spéciaux LVM dans /dev qui sont nécessaires pour les volumes logiques actifs et créé tous ceux qui manques et supprime ceux non-nécessaire
--notifydbus Envoie une notification à d-bus
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--cache scanne le périphériques à la recherche de volumes physique et de volume groupe et instruit lvmetad de mettre à jours son état en cache en fonction.
^
08 juin 2016

htmlpdflatexmanmd




vgsplit

vgsplit

split un volume group en 2

   vgsplit déplace un ou plusieurs volumes physique depuis un VG vers un autre. Le volume physque déplacé explicitement ou implicitement avec -n ‹lvname›, auquel cas seules les PV sous-jacents au LV spécifié seront déplacés.

   Si le VG de destination n'existe pas, un nouveau volume group est créé. Les attributs par défaut peuvent être spécifiés avec --alloc, --clustered, --maxlogicalvolumes, --metadatatype, --maxphysicalvolumes et --[vg]metadatacopies. Si une de ces options n'est pas spécifiée, sa valeur est prise du VG source. Si un type de métadonnée non-lvm2 (ex: lvm1) est utilisé, il faut utiliser l'option -M pour spécifier le type de métadonnées directement.

   Si le VG de destination existe, il est vérifié pour sa compatibilité avec le VG source avant que les volumes physiques soient déplacés. Les volumes logiques ne peuvent pas être splittés entre les volumes groupe. vgsplit ne déplace que les volumes physiques complet. Utiliser pvmove si nécessaire. un vgsplit dans un VG existant garde la valeur vgmetadatacopies du VG existant. Utiliser vgchange pour changer cette valeur.

   Les volumes logique ne peuvent pas être splittés entre les volumes groups, vgsplit ne déplace que les volumes physiques complet: Pour déplacer une partie d'un volume physique, utiliser pvmove. Chaque volume logique existant doit être entièrement sur les volumes physique formant soit la source soit la destination. Pour cette raison, vgsplit peut échouer avec une erreur si un split résulte en un volume logique splité entre les volumes groupe.

   Un vgsplit en un vg existant retient la valeur du vg existant de vgmetadatacopies. Pour changer la valeur de vgmetadatacopies, utiliser vgchange.

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-c|--clustered {y|n} Si le locking est activé, est à yes par défaut, indiquant que ce volume group est partagé avec d'autres nœuds dans le cluster.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-l|--maxlogicalvolumes MaxLogicalVolumes Définis le nombre maximum de LV du VG
-M|--metadatatype type Spécifie quel type de métadonnée utiliser
-p|--maxphysicalvolumes MaxPhysicalVolumes Définis le nombre maximum de volumes physiques qui peuvent appartenir à ce volume group. 0 = illimité
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-n|--name LogicalVolumeName Spécifie le nom du volume logique au lieu du chemin du volume physique (seuls les volumes physiques sous le LV spécifié sont déplacés)
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
^
03 juillet 2017

htmlpdflatexmanmd




visudo

visudo

Éditer le fichier sudoers

   visudo édite le fichier sudoers de manière sûre, analogue à vipw. visudo lock le fichier et fournis des vérifications de base.

   Il y a une liste hardcodée d'un ou plusieurs éditeur que visudo utilise qui peut être remplacés par le paramètre editors. Cette liste est par défaut à 'vi'. Normalement, visudo n'honore pas VISUAL et EDITOR sauf si elles contiennent un éditeur dans la liste des éditeurs mentionnés.

   visudo parse le fichier sudoers après l'édition et ne sauve les changement que s'il n'y a pas d'erreur de syntaxe.

OPTIONS

-c, --check Mode vérification, vérifie la syntaxe, propriétaire et mode.
-f, --file=sudoers Spécifie l'emplacement du fichier sudoers
-q, --quiet mode silencieux
-s, --strict Vérification stricte. Si un alias est référencé mais n'est pas définis, ou s'il y a une boucle d'alias, génère une erreur.
-x, --export=output_file Exporte un sudoers dans un format JSON dans le fichier spécifié ou stdin si '-'
^
26 janvier 2015

htmlpdflatexmanmd




votequorum

votequorum

configuration pour votequorum

L'extrait corosync.conf suivant va activer le service votequorum avec corosync:
quorum {
    provider: corosync_votequorum
}

   votequorum lis sa configuration depuis corosync.conf. Certaines valeurs peuvent être changé en temps réel, d'autres sont seulement lues au lancement de corosync. Il est très important que ces valeurs soient consistantes entre tous les nœuds participant au cluster.

   votequorum requière une valeur expected_votes pour fonctionner, qui peut être fait de 2 manières. Le nombre de votes attendus sera automatiquement calculé quand la section nodelist est présente dans corosync.conf, ou expected_votes peut être spécifié dans la section quorum. Le manque des 2 définissions désactive votequorum. Si les 2 sont présents, la valeur de la section quorum a précédence.

Exemple (sans nodelist) d'un cluster de 8 nœuds (chaque nœud a 1 vote):
quorum {
    provider: corosync_votequorum
    expected_votes: 8
}

Exemple (avec nodelist) d'un cluster de 3 nœuds (chaque nœud a 1 vote):
quorum {
    provider: corosync_votequorum
}
    
nodelist {
    node {
        ring0_addr: 192.168.1.1
    }
    node {
        ring0_addr: 192.168.1.2
    }
    node {
        ring0_addr: 192.168.1.3
    }
}

Fonctionnalités spéciales

   two_node: 1 active les opération de cluster à 2 nœuds (défaut: 0). Ce mode est un cas qui nécessite une considération spéciale. Avec un cluster à 2 nœuds, chaque nœud avec un simple vote, il y a donc 2 votes dans le cluster. Utiliser le calcule de majorité (50% de vote + 1) pour calculer le quorum implique que le quorum est de 2. Cela signifie que les 2 nœuds doivent toujours être en fonction pour que le quorum soit opérationnel.

Activer le two_node, le quorum est définis artificiellement à 1:
quorum {
    provider: corosync_votequorum
    expected_votes: 2
    two_node: 1
}

ou:
quorum {
    provider: corosync_votequorum
    two_node: 1
}
    
nodelist {
    node {
        ring0_addr: 192.168.1.1
    }
    node {
        ring0_addr: 192.168.1.2
    }
}

   Notes: activer le two_node active automatiquement wait_for_all. Il reste possible de changer wait_for_all dans la configuratio. Si plus de 2 nœuds sont joins au cluster, l'option two_node est automatiquement désactivé.

   wait_for_all: 1 (défaut: 0). le fonctionnement général de votequorum est de basculer d'un état 'inquorate' à un état 'quorate' dès que possible. Par exemple, dans un cluster à 8 nœuds, où tous les nœuds ont un vote à 1, expected_votes est à 8, et quorum est à 5 ( 50% + 1 ). Dès qu'au moins 5 nœuds sont visibles entre-eux, la partition d'au moins 5 devient 'quorate' et peut commencer à opérer. Quand WFA est activé, le cluster attend que tous les nœuds sont visibles au moins un fois. C'est utile combiné avec last_man_standing.

Exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    wait_for_all: 1
}

   last_man_standing: 1 / last_man_standing_window: 10000. Active le LMS (Last Man Standing), défaut: 0. Le fonctionnement général de votequorum est de définir expected_votes et quorum au démarrage et d'utiliser ces valeurs durant toute la duées du cluster. En utilisant l'exemple d'un cluster 8 nœuds où chaque nœud a 1 vote, expected_votes est définis à 8 et quorum à 5. Cette condition permet un total de 3 pannes. Si une 4ème panne se produit, le cluster devient 'inquorate' et il va stopper les services. LMS permet au cluster de recalculer dynamiquement expected_votes et quorum sous des conditions spécifiques. Il est essentiel d'active WFA en utilisant LMS. En utilisant un cluster à 8 nœud, LMS permet de poursuivre le quorum opérant en perdant en cascade, jusqu'à 6 nœuds.

Exemple

- Le cluster est pleinement opérationnel avec 8 nœuds ( expected_votes: 8, quorum: 5)
- 3 nœuds tombent en panne, le cluster reste en quorum avec 5 mœuds
- Après last_man_standing_window millisecondes, expected_votes et quorum sont recalculés: expected_votes: 5 quorum: 3.
- À ce point, 2 nœuds supplémentaires peuvent être en panne et le quorum est maintenu avec 3 nœuds.
- Encore une fois, les valeurs sont recalculées: expected_votes: 3 quorum: 2
- À ce point, 1 nœud peut tomber en panne et le quorum est maintenu avec 2 nœuds
- Une fois de plus: expected_votes: 2 quorum: 2

   Notes: pour que le cluster descende automatiquement de 2 nœuds à 1 nœuds, auto_tie_breaker doit également être activé.

Exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    last_man_standing: 1
}

ou (augmente le timeout à 20 secondes):
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    last_man_standing: 1
    last_man_standing_window: 20000
}

   auto_tie_breaker: 1 active ATB (Auto Tie Breaker), défaut: 0. Le fonctionnement général de votequorum permet de perdre simultanément 50% -1 nœud, assumant que chaque nœud a 1 vote. Quand ATB est activé, le cluster pour perdre jusqu'à 50% de nœuds en même temps. Par défaut le cluster, ou le jeu de nœuds qui sont en contacte avec le nœud qui a le nodeid le plus faible restera en quorum. Les autres nœuds deviennent 'inquorate'. Ce mode peut être changé avec:

   auto_tie_breaker_node: lowest|highest|‹list of node IDs› 'lowest' est le défaut. Alternativement il est possible de spécifier un id de nœud qui sera requis pour maintenir le quorum. Si une liste de nœud est donnée, les nœuds sont évalués dans l'ordre, donc si le premier est présent il sera utilisé pour déterminer la partition 'quorate', si ce nœud n'est pas disponible, le second est vérifié.

exemple de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    auto_tie_breaker: 1
    auto_tie_breaker_node: lowest
}

autre exemple:
quorum {
    provider: corosync_votequorum
    expected_votes: 8
    auto_tie_breaker: 1
    auto_tie_breaker_node: 1 3 5
}

   allow_downscale: 1, active l'AD (Allow Downscale), défaut: 0. Votequorum ne descend jamais les votes du quorum. Avec AD activé, les expected_votes et quorum sont recalculés quand un nœud quitte le cluster dan un état clean.

1) Un cluster de N nœuds ( N est supérieur à 3).
2) expected_votes est à 3
3) Seul 3 nœuds fonctionnent
4) l'admin souhaite augmenter le traitement et ajouter 10 nœuds
5) expected_votes est automatiquement définis à 13
6) expected_votes minimum est de 3 (définis dans la configuration)
- À ce point, le votequorum fonctionne normalement.
7) L'admin souhaite supprimer des nœuds du cluster
8) En utilisant un shutdown ordonné, l'admin peut réduire la taille du cluster automatiquement jusqu'à 3, mais pas en dessous.

Exemples de configuration:
quorum {
    provider: corosync_votequorum
    expected_votes: 3
    allow_downscale: 1
}

   expected_votes_tracking: 1 Active l'EVT (Expected Votes Tracking), défaut: 0. l'EVT stocke la plus haute valeur vue des votes attendus sur disque et l'utilise comme valeur minimum pour les votes attendus en l'absence d'une haute autorité. C'est utile quand un groupe de nœuds devient détaché du cluster principal et après un redémarrage pouvant avoir suffisamment de votes pour fournir un quorum, qui peut se produire en utilisant allow_downscale. Noter que même si la version en mémoire de expected_votes est réduite, par exemple en utilisant corosync-quorumtool, la valeur stockée supérieur à la valeur vue, qui n'est jamais réduite. La valeur est maintenue dans le fichier /var/lib/corosync/ev_tracking qui peut être supprimée si vous n'avez pas besoin d'expected_votes.

Notes

- WFA / LMS / ATB / AD peuvent être combinés ensembles
- Pour changer les votes par défau pour un nœud il y a 2 options:

nodelist:
nodelist {
    node {
        ring0_addr: 192.168.1.1
        quorum_votes: 3
    }
    ....
}

ou quorum (déprécié):
quorum {
    provider: corosync_votequorum
    expected_votes: 2
    votes: 2
}

   Dans le cas où votes dans nodelist et quorum sont définis, la valeur de nodelist est utilisée.

  Seul votes, quorum_votes, expected_votes et two_node peuvent être changé en temps réels. Le reste nécessite de redémarrer le cluster.
^
27 juillet 2016

htmlpdflatexmanmd




vsftpd

vsftpd

Service ftp orienté sécurité

   vsftpd est un service FTP trés sécurisé. Le serveur peut être lancé via un super-server tel que inetd ou xinetd, ou peut être lancé de manière autonome.

OPTIONS

-v affiche la version et quitte
-ooption=value Définis une option

Exemples

Lancer vsftpd avec listen àNO, puis charge /etc/vsftpd.conf, qui peut éventuellement remplacer cette option, puis définis ftpd_banner:
vsftpd -olisten=NO /etc/vsftpd.conf -oftpd_banner=blah
^
27 juillet 2016

htmlpdflatexmanmd




vsftpd.conf

vsftpd.conf

Configuration pour vsftpd

options booléennes

allow_anon_ssl Seulement si ssl_enable est actif. à YES, les utilisateurs anonymes sont autorisés à utiliser des connections sécurisé SSL. Défaut: NO
anon_mkdir_write_enable À yes, les utilisateurs anonymes sont autorisés à créer de nouveaux répertoires sous certaines conditions. Pour que celà fonctionne, l'option write_enable doit être activé, et l'utilisateur ftp anonyme doit avoir les permissions d'écritures sur le répertoire parent. Défaut: NO
anon_other_write_enable À yes, les utilisateurs anonymes sont autorisés à effectuer des opérations d'écriture autre que upload et créer des répertoires, tel que la suppression et le renommage.
anon_upload_enable À yes, les utilisateurs anonymes sont autorisés à uploader des fichier sous certaines conditions. write_enable doit être activé, et l'utilisateur ftp anonyme doit avoir les permissions d'écriture à l'emplacement désiré. Ce paramètre est également requis pour les utilisateurs virtuels.
anon_world_readable_only Contrôle si les logins anonymes sont autorisés ou non. Si permis, les usernames ftp et anonymous sont reconnus comme logins anonymes.
ascii_download_enable Activé, le mode de transfert ASCII est permis pour les téléchargements.
ascii_upload_enable Activé, le mode de transfert ASCII est permis pour les uploads.
async_abor_enable Activé, la commande spéciale "async ABOR" est autorisée.
background Lance vsftpd en mode listen en tâche de fond
chmod_enable Activé, autorise l'utilisation de la commande SITE CHMOD. Ne s'applique qu'aux utilisateurs locaux.
chown_uploads Activé, tous les fichiers uploadés de manière anonymes seront changés à l'utilisateur spécifié par chown_username.
chroot_list_enable Activé, fournis une liste d'utilisateurs locaux qui sont placés dans un chroot() dans leur home une fois loggé. La signification est légèrement différence si chroot_local_user est à YES. Dans ce cas, la liste devient une liste d'utilisateurs qui ne sont pas placés dans un chroot(). Par défaut, le fichier contenant cette liste est /etc/vsftpd.chroot_list, et peut être changé avec chroot_list_file.
chroot_local_user À YES, les utilisateurs locaux sont placés par défaut dans un chroot dans leur home une fois loggé.
connect_from_port_20 Contrôle si la connection des données utilise le port 20 (ftp-data) sur le serveur.
debug_ssl À yes, les diagnostiques de connection openssl sont dumpés dans les logs vsftpd.
delete_failed_uploads À yes, tout upload de fichiers échoué est supprimé.
deny_email_enable Activé, permet de fournir une liste de réponses par email de mot de passe anonyme qui sont refusés. Par défaut, le fichier contenant cette liste est /etc/vsftpd.banned_emails, mais peut être changé avec banned_email_file.
dirlist_enable À no, toutes les commandes de listage de répertoire sont refusées
dirmessage_enable Permis, les utilisateurs peuvent reçevoir des messages quand ils entrent dans un nouveau répertoire. Affiche le contenu du fichier .message, ou la valeur de message_file.
download_enable À no, toutes demande de téléchargement sont refusés.
dual_log_enable À yes, 2 fichiers de log sont générés en parallèle, /var/log/xferlog et /var/log/vsftpd.log.
force_dot_files À YES, les fichiers et répertoires cachés sont affichés dans le listing même si le flag 'a' n'est pas utilisé. n'inclus par '.' et '..'.
force_anon_data_ssl Uniquement si ssl_enable est activé. tous les logging anonymes sont obligés d'utiliser une connection SSL pour le transfert de données.
force_anon_logins_ssl Uniquement si ssl_enable est activé. tous les logging anonymes sont obligés d'utiliser une connection SSL pour envoyer le mot de passe.
force_local_data_ssl Uniquement si ssl_enable est activé. tous les logging non-anonymes sont obligés d'utiliser une connection SSL pour le transfert de données.
force_local_logins_ssl Uniquement si ssl_enable est activé. tous les logging non-anonymes sont obligés d'utiliser une connection SSL pour envoyer le mot de passe.
guest_enable À yes, tous les logins non-anonymes sont classé en login guest. un login guest est remappé à l'utilisateur spécifié dans guest_username
hide_ids Activé, toutes les informations d'utilisateurs et groupes dans les listings de répertoire sont affiché en 'ftp'
implicit_ssl Si activé, un handshake SSL est la première chose attendue pour toutes les connections (FTPS).
listen Si activé, vsftpd fonctionne en mode standalone.
listen_ipv6 comme listen, mais vsftpd écoute sur un socket IPv6. listen et listen_ipv6 sont mutuellement exclusifs.
local_enable Contrôle si les logins locaux sont autorisé ou non. Si activé, les comptes dans /etc/passwd ou via PAM peuvent être utilisé pour se logger.
lock_upload_files Activé, tous les uploads sont traités avec un write lock sur le fichier uploadé. Tous les download sont traité avec un read lock partagé.
log_ftp_protocol Activé, toutes les requêtes et réponses FTP sont loggés.
ls_recurse_enable Autorise l'utilisation de ls -R.
mdtm_write Activé, autorise MDTM à changer la date de modification de fichier.
no_anon_password Activé, empêche vsftpd de demander un mot de passe anonyme.
no_log_lock Activé, empêche vsftpd de prendre un lock en écrivant les fichiers de log.
one_process_model Kernel 2.4, permet d'utiliser un modèle de sécurité qui utilise un processus par connection. Un peu moins sécurisé, mais améliore les performances.
passwd_chroot_enable Activé, avec chroot_local_user, un chroot() peut être spécifié sur une base par utilisateur, dérivé du home dans /etc/passwd.
pasv_addr_resolve À YES, permet d'utiliser un nom d'hôte dans l'option pasv_address
pasv_enable Active la méthode passive.
pasv_promiscuous À yes, permet de désactiver la vérification de sécurité PASV qui s'assure que la connection des données vient bien de la même IP que la connection de contrôle.
port_enable À no, désactive la méthode PORT pour obtenir une connexion des données
port_promiscuous À yes, désactive la vérification de sécurité PORT qui s'assure que les connexions de données sortantes peuvent seulement se connecter au client.
require_cert À yes, toutes les connexions SSL client doivent présenter un certificat client.
require_ssl_reuse À yes, toutes les connections de données doivent présenter une session SSL réutilisable.
run_as_launching_user À yes, vsftpd tourne sous l'utilisateur qui a lancé de service.
secure_email_list_enable Contrôle si vsftpd tente de maintenir les sessions pour les logins. si vsftpd maintient les sessions il tente de mettre à jours wtmp et utmp. Il ouvre également un pam_session et se termine seulement au logout.
setproctitle_enable Si activé, vsftpd affiche les informations de status de session dans le listing de processus système.
ssl_enable Active le support SSL
ssl_request_cert Activé, vsftpd demande un certificat pour les connexions SSL.
ssl_sslv2 Active SSL v2
ssl_sslv3 ACtive SSL v3
ssl_tlsv1 Active TLS v1
strict_ssl_read_eof Activé, Les upload SSL doivent se terminer via SSL et non en EOF sur le socket.
strict_ssl_write_shutdown Activé, les download SSL doivent se terminer via SSL et non en EOF sur le socket
syslog_enable Log via syslog
tcp_wrappers Active le contrôle d'accès tcp_wrappers
text_userdb_names Par défaut, les ID sont affichés dans les champs user et group des listings des répertoires. Cette option affiche les noms.
tilde_user_enable Activé, vsftpd tente de résoudre les nom de chemin tels que ~ chris/pics.
use_localtime Activé, vsftpd affiche les listings avec le timezone local (défaut: affiche GMT). les temps retournés par les commandes MDTM FTP sont également affectés par cette option
use_sendfile Paramètre interne pour tester le bénéfice de sendfile()
userlist_deny si userlist_enable est activé, à NO, seul les utilisateurs explicitement listés dans userlist_file sont autorisé.
userlist_enable À yes, charge une liste de usernames depuis le fichier userlist_file.
validate_cert À yes, tous les certificats client SSL reçus doivent être valides.
virtual_use_local_privs Activé, les utilisateurs virtuels utilisent les même privilèges que les utilisateurs locaux. Par défaut ils utilisent les même privilèges que les utilisateurs anonymes, qui tend à être plus restrictif.
write_enable Contrôle si les commandes FTP qui changent le système de fichier sont permis.
xferlog_enable Activé, un fichier de log sera maintenu détaillant les uploads et downloads. par défaut /var/log/vsftpd.log ou la valeur de vsftpd_log_file
xferlog_std_format À yes, le fichier de log de transfert est écrit au format standard utilisé par wu-ftpd.

options numériques

accept_timeout timeout en secondes pour l'établissement d'une connection de données PASV. défaut: 60s.
anon_max_rate Taux maximum de transfert de donnée en octets par seconde pour les clients anonymes.
anon_umask umask pour la création de fichiers pour les utilisateurs anonymes. défaut: 077
chown_upload_mode mode de fichier à forcer pour les uploads anonymes. défaut: 0600
connect_timeout timeout en secondes de réponse d'un client pour une connexion de données PORT
data_connection_timeout Timeout en secondes, pour les transfert de données sans progression. défaut: 300
delay_failed_login Nombre de secondes de pause avant de reporter un login échoué. Défaut: 1
delay_successful_login Nombre de secondes de pause avant de reporter un login réusss. Défaut: 0
file_open_mode permission pour la création des fichier uploadés. défaut: 0666
ftp_data_port Pour pour les connexions PORT. défaut: 20
idle_session_timeout Timeout en secondes, qu'un client distant passe entre 3 commandes. défaut: 300
listen_port En mode standalone, port d'écoute pour les connexions entrantes. défaut: 21
local_max_rate Taux de transfert max permis, en octets par secondes, pour les utilisateurs authentifiés. défaut: 0
local_umask umask pour la création de fichier pour les utilisateurs locaux. défaut: 077
max_clients En mode standalone, nombre maximum de clients qui peuvent être connectés simultannément. défaut: 0
max_login_fails nombre de logins échoué avant de tuer la session. Défaut: 3
max_per_ip En mode standalone, nombre de clients max par ip. défaut: 0.
pasv_max_port port max pour les connexions de données PASV. défaut: 0
pasv_min_port port min pour les connexions de données PASV. défaut: 0
trans_chunk_size défaut: 0

options chaîne

anon_root Représente un répertoire root pour vsftpd pour les login anonyme
banned_email_file Nom d'un fichier contenant une liste de mots de passe emails anonymes non autorisés. default: /etc/vsftpd.banned_emails
banner_file fichier contenant le texte à afficher à la connexion au serveur.
ca_certs_file nom du fichier contenant les certificats d'autorité pour valider les certificats client.
chown_username nom de l'utilisateur les fichiers uploadé anonymement.
chroot_list_file nom d'un fichier contenant une liste d'utilisateurs locaux à placer dans un chroot. Défault: /etc/vsftpd.chroot_list
cmds_allowed liste de commandes autorisées (post login. USER, PASS et QUIT sont toujours autorisés)
cmds_denied Liste de commandes FTP refusées. Prend précédence sur cmds_allowed.
deny_file permet de définis un jeu de pattern de noms de fichier inaccessibles.
dsa_cert_file certificat DSA
dsa_private_key_file Clé privée DSA
email_password_file fichier pour secure_email_list_enable. défaut: /etc/vsftpd.email_passwords
ftp_username Nom de l'utilisateur pour le ftp anonyme. défaut: ftp.
ftpd_banner Bannière affichée par vsftpd au début de connexion.
guest_username username pour l'option guest_enable
hide_file Permet de définir un pattern de noms de fichier cachés dans les listings des répertoires.
listen_address adresse d'écoute du service
listen_address6 adresse d'écoute en ipv6
local_root Répertoire que vsftpd change après un login non-anonyme.
message_file nom du fichier à afficher en entrant dans un répertoire. Défaut: .message.
nopriv_user nom de l'utilisateur utilisé par vsftpd quand il souhaite être totalement non privilégié. devrait être utilisateur dédié. défaut: nobody
pam_service_name nom du service pam à utiliser. Défaut: ftp.
pasv_address IP utilisée pour répondre à la commande PASV.
rsa_cert_file certificat RSA
rsa_private_key_file clé privée rsa
secure_chroot_dir nom d'un répertoire vide, non accessible en écriture par l'utilisateur ftp, utilisé comme chroot sécurisé quand vsftpd n'a pas besoin d'accès au système de fichier.
ssl_ciphers Chiffrements autorisés pour les connexions SSL. Défaut: DES-CBC3-SHA
user_config_dir Répertoire contenant des fichiers de configuration par utilisateur.
user_sub_token utilisé pour générer automatiquement un home pour chaque utilisateur virtuel, basé sur un template.
userlist_file fichier chargé quand l'option userlist_enable est active. défaut: /etc/vsftpd.user_list
vsftpd_log_file fichier de log
xferlog_file nom du fichier où écrire les log de transfert style wu-ftpd
^
17 janvier 2012

htmlpdflatexmanmd




wall

wall

Écrit un message aux utilisateurs

   Il affiche le contenus d'un fichier spécifié ou, par défaut, son entrée standard, sur les terminaux de tous les utilisateurs courant. Seul root peut écrire sur les terminaux de tous les utilisateurs qui ont choisis d'ignorer les messages. Lire depuis un fichier est refusé quand l'invoqueur n'est pas root et le programme est suid ou sgid.

^
28 août 2015

htmlpdflatexmanmd




warnquota

warnquota

Envoie un mail aux utilisateurs sur les quotas

   warnquota vérifie le quota disque des systèmes de fichiers spécifiés et envois des mails d'alerte aux utilisateurs qui ont atteind leur softlimit.

OPTIONS

-F, --format=format-name Affiche le quota au format spécifié: vfsold (16-bits UID), vfsv0 (32bits UID), vfsv1 (format 64bits) rpc (quota sur NFS), xfs (quota sur les système XFS).
-q, --quota-tab=quotatab Utilise le fichier spécifié au lieu de /etc/quotatab avec les chaînes de description de périphérique.
-c, --config=configfile Utilise le fichier spécifié au lieu de /etc/warnquota.conf comme fichier de configuration
-a, --admins-file=adminsfile Utilise le fichier spécifié au lieu de /etc/quotagrpadmins comme fichier avec les administrateurs de groupes.
-u, --user Vérifie les quotas utilisateur
-g, --group Vérifie les quotas de groupe
-s, --human-readable Affichage au format automatique
-i, --no-autofs ignore les points de montage montés par automounter
-d, --no-details N'attache pas de rapport de quota dans le mail.
^
28 août 2015

htmlpdflatexmanmd




/etc/warnquota.conf

/etc/warnquota.conf

fichier de configuration des alertes de quota, utilisé par warnquota

OPTIONS

CC_BEFORE Envoie en CC seulement quand un utilisateur a moins que la période de grâce spécifiée.
CC_TO Adresses email en cc
CHARSET Jeu de caractère à utiliser dans le mail
FROM adresse email de l'expéditeur
GROUP_MESSAGE Un texte envoyé comme corps du mail si un groupe excède sa limite
GROUP_SIGNATURE Texte de signature ajoutée à la fin du corps du mail
LDAP_BASEDN Base de recherche LDAP
LDAP_BINDDN Compte de connexion LDAP
LDAP_BINDPW Mot de passe du compte LDAP
LDAP_DEFAULT_MAIL_DOMAIN Domaine recherché
LDAP_HOST Serveur ldap à contacter si LDAP_URI n'est pas définis
LDAP_MAIL (Bool) contrôle si LDAP doit être utilisé pour rechercher les adresses email
LDAP_MAIL_ATTRIBUTE Spécifie l'attribut contenant l'email de l'utilisateur
LDAP_PORT Port du serveur LDAP si LDAP_URI n'est pas définis
LDAP_SEARCH_ATTRIBUTE L'attribut qui maintient l'ID de l'utilisateur
LDAP_URI L'URI du serveur LDAP à contacter
MESSAGE Corps du message à envoyer si un utilisateur dépasse ses limites
MAIL_CMD Commande à exécuter pour envoyer des mails
MAILDEV Périphérique avec quota disque à exclure des notification.
PHONE Un téléphone de contact
SIGNATURE La fin du corps du message
SUBJECT Le sujet du mail
SUPPORT Le contact du support informatique de l'utilisateur

caractères interprétés dans les chaînes

%d domain name
%h host name
%i, %s user or group name
%% literal % character
| new-line character
^
12 février 2015

htmlpdflatexmanmd




watchdog

watchdog

service watchdog

Description

   Le noyau linux peut réinitialiser le système si des problèmes sérieux sont détectés. Cela peut être implémenté via le hardware spécial watchdog, ou via un watchdog logiciel légèrement moins fiable dans le kernel. Dans tous les cas, un service doit dire au kernel que tout va bien. Si le service ne le fait plus, le système est réinitialisé.

   Watchdog est un service qui ouvre /dev/watchdog, et maintient une écriture aussi souvent que possible pour empêcher le noyau de se réinitialiser, au moins une fois par minute. Chaque écriture retarde le temps de reboot d'une minute. Au bout d'une minute d'inactivité, le système est réinitialisé. Dans le cas d'un watchdog logiciel, la capacité de rebooter le système dépend de l'état de la machines et des interruptions.

   Le service watchdog peut être stoppé sant reboot si le périphérique /dev/watchdog est fermé correctement, sauf si le kernel a été compilé avec l'option CONFIG_WATCHDOG_NOWAYOUT.

Tests

   Le service Watchdog effectue de nombreux tests pour vérifier le status du système:

- Est-ce que la table des processus est pleine?
- Y'a t'il suffisamment de mémoire vive?
- Y'a t'il suffisamment de mémoire allouable?
- Est-ce que certains fichiers sont accessibles?
- Est-ce que certains fichiers ont changés dans l'intervalle de temps donné?
- Est-ce que la charqe système est trop élevée?
- Est-ce qu'un débordement de table de fichier se produit?
- Est-ce qu'un processus fonctionne (identifié par un fichier pid)?
- Est-ce qu'une adresse IP répond aux ping?
- Est-ce que les interfaces réseaux reçoivent du trafic?
- Est-ce que la température est trop élevée?
- Exécute une commande utilisateur pour effectuer des tests arbitraires.
- Exécute une commande de test/réparation.

   Si une de ces vérifications échouent, le système s'éteind. Si un de ces tests, excepté les commandes utilisateurs, dépassent une minute, la machine est redémarrée.

OPTIONS

-v, --verbose mode verbeux
-s, --sync tente de synchroniser le système de fichier à chaque fois que le processus et réveillé.
-b, --softboot soft boot le système si une erreur se produit durant la boucle principale. par ex, si un fichier n'est pas accessible via l'appel stat(). Ne s'applique pas à /dev/watchdog et /proc/loadavg.
-F, --foreground Ne passe pas en tâche de fond
-f, --force Force l'utilisation de l'intervalle donné ou la charge moyenne maximale dans la configuration.
-c config-file, --config-file config-file Spécifie le fichier de configuration au lieu du défaut /etc/watchdog.conf
-q, --no-action Ne reboot pas et n'arrête pas la machine.

Fonctions

   Une fois watchdog démarré, il se place en tâche de fond et tente toutes les vérifications spécifiées dans sa configuration. Entre chaque test il écris dans le périphérique kernel pour empêcher un reset. Une fois tous les tests terminés, watchdog s'endors un certain temps. Le périphérique kernel s'attend à une écriture par minute pour empêcher un reset. Par défaut, watchdog est lancé toutes les secondes pour gérer le périphérique le plus tôt possible.

   Sous de forte charges système, watchdog peut avoir été swappé et peut échouer à revenir à temps. Dans ce cas le kernel va réinitialiser la machine. l'option realtime s'assure qu'il ne sera jamais swappé. Sur les systèmes n'ayant plus de mémoire vive disponible, le kernel va tenter de libérer de la mémoire en tuant des processus. watchdog est exempt de ce système.

   Watchdog tente également périodiquement de se forker lui-même pour voir si la table des processus n'est pas pleine. Ce processus va laisser un processus zombie jusqu'à ce que watchdog de réveil, c'est un fonctionnement normal.

Soft reboot

   Un soft reboot (shutdown et reboot contrôlé) est initié pour toute erreur qui est trouvée. Vu qu'il peut ne plus y avoir d'autres processus disponible, watchdog fait tout par lui-même. Cela signifie:

1. Tuer tous les processus avec un SIGTERM
2. Tuer tous les processus restant avec un SIGKILL
3. Enregistre un shutdown dans wtmp
4. Sauve la valeur aléatoire de /dev/urandom si possible
5. Désactive l'accounting
6. Désactive les quota et le swap
7. Démonte toutes les partitions sauf /
8. Remonte root en lecture-seule
9. Éteins toutes les interfaces réseaux
10. Reboot

Binaire de vérification

   Si le code de retour du binaire de vérification n'est pas 0, watchdog assume une erreur et reboot le système. Les valeurs de retour suivants ont une signification particulière:

255 Reboot le système.
254 Réinitialise le système
253 Surcharge système
252 Température trop élevée
251 /proc/loadavg ne contient pas de données ( ou trop peu)
250 Le fichier donné n'a pas été changé dans l'intervalle donné
249 /proc/meminfo contient des données invalides
248 Processus enfant tué par un signal
247 Processus enfant n'a pas retourné dans le temps impartis
246 libre pour une utilisation spécifique
245 Réservé pour un résultat inconnu.

Binaire repair

   Le binaire repair est lancé avec un paramètre: le numéro d'erreur qui a causé watchdog d'initier le processus de boot. Après avoir tenté de réparer le système le binaire devrait quitter avec le code 0 si le système à été réparé avec succès, sinon watchdog reboot. Le code de retour devrait être le code d'erreur qui cause watchdog a rebooter.

Répertoire test

   Les exécutables dans le répertoire de test sont découverts par watchdog au démarrage et sont automatiquement exécutés. Ces exécutables sont appelé soit avec "test" comme premier argument ( si un test est effectué ), ou "repair" (si une réparation pour un test précédent doit être effectué). Si une opération de test échoue, le même exécutable est appelé avec l'argument repair avec le code de retour de l'opération précédente en tant que second argument.

Fichiers

/etc/watchdog.conf Fichier de configuration de watchdog
/etc/watchdog.d répertoire contenant les commandes test ou repair.
^
12 février 2015

htmlpdflatexmanmd




watchdog.conf

watchdog.conf

fichier de configuration pour le service watchdog

OPTIONS

interval = ‹interval› Définis l'interval le plus grand possible entre 2 écritures dans le périphériques watchdog. Le périphérique est piloté après chaque vérification sans regarder le temps qu'il a mis. Défaut: 1 seconde. Le pilote attend une écriture par minute, sinon le système est redémarré. Pour un intervalle supérieur à 1 minute, utiliser l'option -f
logtick = ‹logtick› Si les logs verbeux sont activés, un message est écris dans le syslog ou un fichier de log. Il n'est pas nécessaire d'avoir un message toutes les 10 secondes. logtick ajuste l'interval entre 2 messages.
max-load-1 = ‹load1› Définis la charge maximale permise pour 1 minute. Une fois cette charge atteinte le système est redémarré. Défaut: 0 (désactivé)
max-load-5 = ‹load5› Définis la charge maximale permise pour 5 minutes. Une fois cette charge atteinte le système est redémarré. Défaut: 3/4*max-load-1.
max-load-15 = ‹load15› Définis la charge maximale permise pour 15 minutes. Une fois cette charge atteinte le système est redémarré. Défaut: 1/2*max-load-1.
min-memory = ‹minpage› définis la quantité maximale de mémoire virtuelle qui doit rester libre, en pages. Défaut: 0
allocatable-memory = ‹minpage› Définis la quantité maximale de mémoire allouable libre dans le système, en pages. Défaut: 0
max-temperature = ‹temp› Température maximale permise. Défaut: 120. Watchdog emet une alerte une fois que la température atteins 90%, 95% et 98%.
watchdog-device = ‹device› Nom du périphérique watchdog.
watchdog-timeout = ‹timeout› timeout du périphérique watchdog au démarrage.
temperature-device = ‹temp-dev› Nom du périphérique de température.
file = ‹filename› Définis le nom du fichier pour le mode fichier. Peut être spécifié plusieurs fois.
change = ‹mtime› définis l'intervalle de temps de changement pour le mode fichier. Cette options appartient toujours au fichier actif. On ne peut pas spécifier de ligne change = avant une ligne file =.
pidfile = ‹pidfilename› fichier pid pour le mode de test serveur. Peut être spécifié plusieurs fois.
ping = ‹ip-addr› Adresse IP pour le mode ping. Peut être spécifié plusieurs fois
interface = ‹if-name› Interface réseaux pour le mode réseaux. Peut être spécifié plusieurs fois
test-binary = ‹testbin› Exécute le binaire donné pour certains tests utilisateurs
test-timeout = ‹timeout in seconds› timeout pour les tests utilisateurs
repair-binary = ‹repbin› Exécute le binaire en cas de problème au lieu d'éteindre le système
repair-timeout = ‹timeout in seconds› La commande repair peut seulement durer le temps spécifié (0 pour illimité)
admin = ‹mail-address› Adresse email pour envoyer un mail.
realtime = ‹yes|no› Block watchdog en ram, donc il n'est jamais swappé
priority = ‹schedule priority› priorité pour le mode temps réel
test-directory = ‹test directory› Définis le répertoire où lancer les scripts utilisateurs/repair. Défaut: /etc/watchdog.d.
log-dir = ‹log directory› Répertoire de log pour les binaire repair et test. Défaut: /var/log/watchdog.
^
07 juin 2010

htmlpdflatexmanmd




wc

wc

Compte le nombre d'octets, de caractères et de mots pour chaque fichier donné. Par défaut, wc affiche 3 compteurs - nombre de lignes, nombre de mots et nombre d'octets

OPTIONS

-c, --bytes Affiche seulement le compteur d'octets
-m, --chars Affiche seulement le compteur de caractères
-w, --words Affiche seulement le compteur de mots
-l, --lines Affiche seulement le compteur de newlines
-L, --max-line-length Affiche seulement la longueur de ligne maximum.
--files0-from=FILE Désactive le traitement des fichiers donnés sur la ligne de commande, et traite les fichiers nommés dans FILE. chaque nom est terminé par un ASCII NUL. Permet de traiter un grand nombre de fichiers.

Exemples

Trouver le longueur de la ligne la plus longue dans un fichier .c ou .h dans la hiérarchie courante
find . -name '*.[ch]' -print0 | wc -L --files0-from=- | tail -n1
^
07 mai 2016

htmlpdflatexmanmd




wdctl

wdctl

Affiche le status du watchdog hardware

   Le périphérique par défaut est /dev/watchdog. Si plus d'un périphérique est spécifié alors la sortie est séparée par une ligne blanche

OPTIONS

-f, --flags list Affiche seulement les flags spécifiés
-F, --noflags N'affiche pas les informations sur les flags
-I, --noident N'affiche les informations d'identité watchdog
-n, --noheadings N'affiche pas une ligne d'en-tête pour la table de flags.
-o, --output list Définis les colonnes à afficher
-O, --oneline affiche toutes les informations sur une seule ligne au format clé="valeur"
-r, --raw Utilise le format brute
-s, -settimeout seconds Définis le timeout watchdog en secondes
-T, --notimeouts N'affiche pas les timeouts watchdog
-x, --flags-only Idem à -I -T
^
12 février 2015

htmlpdflatexmanmd




wd_identify

wd_identify

Service watchdog logiciel simplifié

Description

   Cet utilitaire ouvre /dev/watchdog et récupère la chaîne identifiant du watchdog qui est affiché. Le périphérique est ensuite fermé. Cet utilitaire peut seulement être utilisé sans causer de reboot si le kernel est compilé avec CONFIG_WATCHDOG_NOWAYOUT.

OPTIONS

-c config-file, --config-file config-file Fichier de configuration
^
12 février 2015

htmlpdflatexmanmd




wd_keepalive

wd_keepalive

Service watchdog logiciel simplifié

Description

   Version simplifié de watchdog. Il est configuré pour qu'il ouvre simplement /dev/watchdog, et continue d'écrire dedans suffisamment souvent pour que le système ne redémarre pas. Sous de hautes charges, ce service peut être swappé et échouer à revenir à temps, s'assurer pour cela que la variable realtime est définie.

OPTIONS

-c config-file, --config-file config-file Fichier de configuration
^
01 février 2014

htmlpdflatexmanmd




whatis

whatis

Affiche les descriptions des pages de manuel

OPTIONS

-d, --debug Mode debug
-v, --verbose mode verbeux
-r, --regex Interprète chaque mot clé comme expression régulière
-w, --wildcard Interprète chaque mot clé comme motif contenant des wildcard style shell.
-l, --long Ne tronque pas la sortie.
-s list, --sections list, --section list Recherche uniquement dans ces sections
-m system[,...], --systems=system[,...] Permet d'accéder à des page de manuel d'autres OS.
-M path, --manpath=path Spécifie un jeu de chemin de man alternatifs au lieu de lire $MANPATH
-L locale, --locale=locale Remplace l'appel setlocale(3)
-C file, --config-file=file Spécifie le fichier de configuration à utiliser au lieu de ~/.manpath

Variables d'enironnement

SYSTEM Si le système a accès à des pages de manuel d'autres OS, permet de les inclure
MANPATH Chemin de recherche pour les pages de manuel
MANWIDTH Longueur de ligne (défaut: 80)
^
13 juillet 2010

htmlpdflatexmanmd




who

who

Affiche des informations sur les utilisateurs loggés

   who affiche des informations sur les utilisateurs qui sont actuellement loggés. Sans argument, who affiche pour chaque utilisateur loggé : le nom de login, le terminal, le temps loggé et l'hôte distant ou l'écran X. S'il a un argument non-option, who utilise ce fichier au lieu de /var/run/utmp ou /etc/utmp. S'il 2 arguments non-option sont donnés, who affiche seulement l'entrée pour l'utilisateur courant, précédé par le nom d'hôte. Traditionnellement les 2 arguments sont am i.

OPTIONS

-a, --all Identique à -b -d --login -p -r -t -T -u
-b, --boot affiche la date et l'heure du dernier boot système
-d, --dead affiche les informations correspondant aux processus mort
-H, --heading affiche une ligne d'en-tête de colonnes.
-l, --login liste seulement les entrées qui correspondent au processus via lequel le systèmes attend qu'un utilisateur se log.le nom d'utilisateur est toujours LOGIN.
--lookup Tente de canoniser les noms d'hôtes
-m identique à who am i
-p, --process liste les processus actifs spawnés par init
-q, --count affiche unsiquement les noms de login et le nombre d'utilisateurs loggés.
-r, --runlevel affiche le run-level courant
-t, --time affiche le dernier changement d'heure système
-u après le temps de log, affiche le nombre d'heures et de minutes que l'utilisateur était absent. un '.' indique que l'utilisateur était actif durant la dernière minute. 'old' signifie que l'utilisateur est absent depuis plus de 24heures.
-w, -T, --mesg, --message, --writable Après chaque login name, affiche un caractère indiquant le message de status des utilisateurs:

        + permet d'écrire des messages
        - ne peut pas écrire de messages
        ? ne peut pas trouver de périphérique terminal
^
13 juillet 2010

htmlpdflatexmanmd




whoami

whoami

Affiche le nom de l'utilisateur

   whoami affiche le nom d'utilisation associé avec l'effective user ID courant. identique à id -un

^
16 mai 2017

htmlpdflatexmanmd




wine

wine

Exécuter des programmes Windows sous Unix

   Le nom du programme peut être spécifié au format DOS ou au format UNIX. Les caractères spéciaux sont protégés par '\'

Variables d'environnement

WINEPREFIX si définis, nom du répertoire où sont stockés les données (défaut : $HOME/.wine)
WINESERVER Chemin de wineserver (défaut : /usr/local/bin/wineserver)
WINELOADER Chemin de wine (défaut : /usr/local/bin/wine)
WINEDEBUG Active/désactive les messages de deboggage. (syntaxe : [classe][+|-]canal[,[classe2][+|-]canal2])
WINEDLLPATH Chemins où rechercher les dll intégrées et les applications Winelib, séparés par des ’ :’ (défaut : /usr/local/lib/wine)
WINEDLLOVERRIDES Définis le type d’emplacement et l’ordre de chargement des DLL utilisée lors du processus de chargement d’une DLL. le type peut être n( native) ou b (builtin) (ex : WINEDLLOVERRIDES="comdlg32,shell32=n,b", ex : WINEDLLOVERRIDES="comdlg32=b,n ;shell32=b ;comctl32=n ;oleaut32=")
WINEARCH Spécifie l’architecture Windows (win32 ou win64)
DISPLAY Spécifie l’affichage X11 à utiliser
AUDIODEV défaut : /dev/dsp
MIXERDEV défaut : /dev/mixer
MIDIDEV défaut : /dev/sequencer
^
16 mai 2017

htmlpdflatexmanmd




Wine - présentation

Wine - présentation

Wine est une implémentation des librairies Windows, agissant comme un pont vers les librairies linux

Fonctionnalités de Wine

- Support pour les applications win16, win32 et win64
- utilisation de fichiers dll
- Affichage graphique X11
- Support de DirectX
- Support pour les pilotes son tel que OSS et ALSA
- Support pour des périphériques d’entrée tels que les tablettes graphiques
- Pilote PostScript pour l’impressions
- support modem série
- Winsock TCP/IP networking
- Support des interfaces scsi ASPI pour les scanner, graveurs cd, etc.
- Support unicode et support de langues avancé
- Débugger intégré et avancé

Compiler Wine


wget http://downloads.sourceforge.net/project/wine/Source/wine-1.7.0.tar.bz2
tar -xjf wine-1.7.0.tar.bz2
cd wine-1.7.0
./configure
make depend
make
make install

Exécuter Wine

   Les applications sont installées sous Wine de la même manière qu'elles le sont sous Windows : en exécutant l’installeur. Pour désinstaller un programme, lancer le programme uninstaller (généralement dans programs/uninstaller/) : wine uninstaller.

  Certains programmes associent une applet dans le panneau de contrôle : wine control

Variables d’environnement

WINEDEBUG=[channels] permet d’activer des cannaux de debug. 4 classes peuvent être définies, trace, fixme, warn, err, +all, -‹class›. (ex : WINEDEBUG=warn+heap wine program_name)
WINEDLLOVERRIDES=[DLL Overrides] Permet d’utiliser les DLL natives au lieu de celles intégrées (ex : WINEDLLOVERRIDES="comdlg32=b,n ;shell32=b ;comctl32=n ;oleaut32=" wine program_name)
WINEARCH Spécifie l’architecture Windows à supporter
AUDIODEV défaut : /dev/dsp
MIXERDEV défaut : /dev/mixer
MIDIDEV défaut : /dev/sequencer

Options de wineserver

-d‹n› Définis le niveau de debug à sortir dans le terminal
-k[n] Kill le wineserver courrant avec le signal spécifié
-p[n] rend winserver persistant, optionnellement pour n secondes
-w wineserver attend jusqu’à ce que l’instance winserver active se termine

Définir les variables d’environnement Windows/DOS

export MYENVIRONMENTVAR=myenvironmentvarsetting

   Pour certaines variables d’environnement comme PATH, SYSTEM ou TEMP, pour ne pas altérer l’environnement linux, il est nécessaire de les déclarer dans le registre avec regedit ( HKEY_CURRENT_USER/Environment)

Programmes en mode texte (CUI)

   Il y’a 3 manières différentes de lancer un tel programme:

bare streams Pas de support supplémentaire de wine qui map la console Windows à une console unix
wineconsole with user backend Utilise wineconsole
wineconsole with curse backend Utilise wineconsole

   Quand wineconsole est utilisé, de nombreuses options de configuration sont disponibles. Wine les stock sur une base par application dans le registre. Seul le backend user permet d’éditer ces options. Les options de configurations de wineconsole permettent de choisir entre Default (paramètres partagés par toutes les applications) ou properties (édition par application).

Configurer Wine avec winecfg

   Wine stock toute sa configuration dans le registre.

Applications Wine a la capacité de mimer différentes version de Windows. Pour chaque application, Wine permet de spécifier quelle version de windows simuler.
Bibliothèques Certaines applications nécessitent des librairies spécifiques. Wine reproduit les librairies système Windows avec des versions complètement conçues de manière à fonctionner de la même manière, mais sans nécessiter de licence Microsoft. Il est possible de spécifier une DLL Native de remplacement dans le cas où les DLL intégrées ne fonctionnent pas correctement.
Affichage 5 paramètres de base permettent de déterminer le mode d’affichage des applications
Lecteurs Permet de gérer les lecteurs Windows. Tous les lecteurs résident dans /.wine/dosdevices Chaque lecteur est un lien vers l’emplacement où il réside.
Audio Wine Peut fonctionner avec différents sous-systèmes audio, définissable ici.
intégration avec le bureau Wine peut charger des thèmes Windows

Utiliser le registre et regedit

system.reg contient HKLM
user.reg contient HKCU
userdef.reg contien HKUSERS\.Default

   Ces fichiers sont créés la toute première fois que wine est lancé

Autres configuration

   La configuration des ports série et parallèle est très similaire à la configuration des lecteurs, un lien dans .wine/dosdevices (ex : ln -s /dev/ttyS0 com1 et ln -s /dev/lp0 lpt1)

Partages réseaux Les partages réseaux peuvent être mappés dans le répertoire unc (ex : ln -s /mnt/smb/myserver/some unc/myserver/some )
police de caractères Les fonts .ttf sont placées dans c :\windows\fonts
Imprimantes Wine peut interagir avec CUPS pour trouver les imprimantes disponibles
Scanner Dans Windows, les scanner utilisent le TWAIN API pour accéder au hardware. la version intégrée de Wine forwards simplement les requêtes aux librairies Linux SANE
Base de données ODBC le système ODBC dans Wine, est conçu pour hook dans le système unix. Au lieu de s’assurer que le code Winodws fonctionne sous wine, il utilise un fournisseur ODBC Unix, tel que UnixODBC.
^
16 mai 2017

htmlpdflatexmanmd




wineserver

wineserver

Service qui fournis à Wine les même services que le noyau Windows. Il est lancé automatiquement par wine

OPTIONS

−d[n], --debug[=n] Définis le niveau de débug
−f, --foreground Laisse le serveur au premier plan
−k[n], --kill[=n] envoie un signal au wineserver courant
−p[n], --persistent[=n] Délai de persistance après que tous les processus client soient terminés
−w, --wait Attend que le wineserver courant se termine avec de se lancer

Variables d'environnement

WINEPREFIX si définis, nom du répertoire où sont stockés les données (défaut : $HOME/.wine)
WINESERVER Chemin de wineserver (défaut : /usr/local/bin/wineserver)
^
16 mai 2017

htmlpdflatexmanmd




winetricks

winetricks

Utilitaire pour travailler facilement autour des problèmes dans Wine

OPTIONS

   Sans argument, affiche une interface utilisant soit zenity soit kdialog

Variables d'environnement

WINEPREFIX si définis, nom du répertoire où sont stockés les données (défaut : $HOME/.wine)
WINE Chemin de wine
XDG_CACHE_HOME Cache de données utilisateur du système (défaut : $HOME/.cache)
W_CACHE Cache de winetricks ( défaut : $XDG_CACHE_HOME/winetricks)
^
07 octobre 2011

htmlpdflatexmanmd




wipefs

wipefs

Efface la signature d'un système de fichier ou d'un raid sur un périphérique (magic string) pour le rendre invisible pour libblkid

   Il n'efface pas le système de fichier ni les données du périphérique. Sans les options -a ou -o, il liste tous les système de fichiers et offsets de leurs signatures.

-a, --all Efface toutes les signatures disponibles
-n, --no-act Exécute tout sauf l'appel write()
-o, --offset offset Spécifie l'emplacement (en octet) de la signature qui devrait être effacée. Peut inclure le préfixe 0x. Peut être spécifié plusieurs fois.
-p, --parsable Affiche un format parsable au lieu d'un format imprimable. Encode tous les caractères non sûr d'une chaîne à sa valeur hexa correspondante et préfixée par '\x'

^
01 janvier 2014

htmlpdflatexmanmd




X

X

X Window System est un système de fenêtrage qui tourne sur des ordinateurs avec écran. Le serveur distribut l'entrée utilisateur et accepte les demandes de sortie pour divers programmes clients au travers de différents canaux de communication inter-process. Les clients peuvent être lancés de manière transparente depuis d'autres machines. X supporte le sous-fenêtrage hiérarchique et les opérations graphique et texte, sur des afficheurs couleur et monochrome.

Démarrage

   Il y'a 2 principaux moyen de démarrer un serveur X et un jeu d'applications clients initial:

  Display Manager: xdm, gdm ou kdm. Ce programme est typiquement lancé par le système au boot et gère le serveur et les connexions utilisateur.

  xinit: Utilisé pour démarrer le serveur et un premier client X sur des systèmes qui ne peuvent démarrer directement X depuis /etc/init ou dans des environnements qui utilisent plusieurs système de fenêtrage.

Noms d'affichage

   Du point de vue d'un utilisateur, tout serveur X a un nom d'affichage sous la forme hostname:displaynumber.screennumber

  Cette information est utilisée par l'application pour déterminer comment il devrait se connecter au serveur et quel écran il devrait utiliser.

  hostname Spécifie le nom de la machine où l'affichage est physiquement connecté

  displaynumber réfère à une collection de moniteur qui partagent un jeu commun de périphériques d'entrée. chaque affichage est numéroté en partant de 0

  screennumber Spécifie le moniteur. Chaque moniteur est numéroté en partant de 0.

  Sur les systèmes POSIX, le nom d'affichage est stocké dans la variable DISPLAY. Pour se logger sur une autre machine sur le réseau, il faut définir manuellement cette variable pour pointer sur votre afficheur. ssh peut être utilisé pour lancer des programmes X à distance, il définis correctement cette variable.

   X écoute les connections sur différents canaux de communication. pour déterminer le type de canal, il utilise le hostname. X supporte généralement les types de connexion suivants:

local La partie hostname devrait être vide. (exemple :0, :0.1)
tcpip Le hostname devrait être un nom d'hôte ou une IP. ex: x.org:0, expo:0, [::1]:0, 198.112.45.11:0, bigmachine:1, et hydra:0.1)

Contrôle d'accès

   Un serveur X peut utiliser plusieurs types de contrôle d'accès:

  MIT-MAGIC-COOKIE-1 Cookie en plain/text

  XDM-AUTHORIZATION-1 Clé privé, DES.

  xdm initialise le contrôle d'accès pour le serveur et place les informations dans un fichier accessible à l'utilisateur. Normalement la liste des hôtes depuis lesquels les connexions sont toujours acceptés devrait être vide, donc seul les clients explicitement autorisé peuvent se connecter. En ajoutant une liste d'hôte avec xhost, le serveur n'effectue plus aucune autorisation depuis ces machines.

  Le fichier depuis lequel Xlib extrait les autorisations peut être spécifié avec la variable XAUTHORITY, défaut: .Xauthority dans le home de l'utilisateur. Pour gérer les fichier d'autorisation, utiliser xauth. Les fichiers sont indépendant des machine, ce qui simplifie l'utilisation de nombreuses machine avec des home partagés.

Spécification de géométrie

   De nombreux programmes X ont l'option -geometry WIDTHxHEIGHT+XOFF+YOFF pour spécifier une taille préférée et un emplacement dans la fenêtre principale. la syntaxe est la suivante:

+XOFF Le coté gauche de la fenêtre est placé à XOFF pixel du bord gauche de l'écran
-XOFF Le coté droit de la fenêtre est placé à XOFF pixel du bord droit de l'écran
+YOFF Le coté haut de la fenêtre est placé à YOFF pixel du bord haut de l'écran
-YOFF Le coté bas de la fenêtre est placé à YOFF pixel du bord bas de l'écran

   Les offsets doivent être donné en paire:

+0+0 Coin supérieur gauche
-0+0 Coin supérieur droit
-0-0 Coin inférieur droit
+0-0 Coin inférieur gauche

Exemple de placement de fenêtres au milieu de l'écran:
xterm -fn
6x10 -geometry 80x24+30+200 &
xclock -geometry 48x48-0+0 &
xload -geometry 48x48-96+0 &
xbiff -geometry 48x48-48+0 &

Gestionnaire de fenêtre

   La couche de fenêtres à l'écran est contrôlée par un programme spécial appelé le window manager. Xorg fournis twm.

Noms de fonts

   Les collections de caractères pour afficher du texte et des symboles dans X sont des fonts. Un font contient généralement des images qui partagent une apparence commune. Similairement, une collection de fonts sont une base de type commun ( les variations sont généralement appelé roman, bold, italic, bold italic, etc.)
   le serveur X peut obtenir les fonts depuis des fichiers individuels dans un répertoire du système, ou depuis un ou plusieurs serveurs de font, ou un mixe des 2 (peut se changer avec xset).
   Les fichiers de font bitmap sont créés en compilant une description de font textuelle en forme binaire en utilisant bdftopcf. Les bases de font sont créé en lançant mkfontdir dans le répertoire contenant la source ou les version compilé des fonts. Par exemple pour ajouter un font dans un répertoire privé, les commandes suivantes peuvent être utilisées:

  cp newfont.pcf ~/myfonts

  mkfontdir ~/myfonts

  xset fp rehash

  xfontsel et xlsfonts peuvent être utilisés pour naviguer dans les fonts disponibles sur un serveur. le serveur supporte les wildcard des noms de font, donc:

  -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1

  peut être abbrégé en:

  -*-courier-medium-r-normal--*-100-*-*-*-*-iso8859-1

Serveur de fonts

   Une des forme suivantes peuvent être utilisé pour nommer un serveur de font qui accepte les connexions TCP:

  tcp/hostname:port

  tcp/hostname:port/cataloguelist

  exemple: tcp/x.org:7100, tcp/198.112.45.11:7100/all

colorName

   Beaucoup d'applications fournissent une manière d'adapter les couleurs de divers éléments dans le texte et graphiques qu'ils affichent. Une couleur peut être spécifiée par un nom de couleur abstraite (red, blue), ou par une représentation numérique (RGB). Les noms abstraits de couleur peuvent être recherchés dans une base de donnée. Xlib recherche des bases côté client, ou dans la base de données du serveur (/usr/share/X11/rgb.txt).

  une spécification de couleur numérique consiste d'un espace de nom de couleur et un jeu de valeur:

  ‹color_space_name›:‹value›/.../‹value›

  Une spécification de Périphérique RGB est identifié par le préfixe "rgb:" et a la syntaxe suivante:

  rgb:‹red›/‹green›/‹blue›

  ‹red›, ‹green›, ‹blue› := h | hh | hhh | hhhh

  où h est une valeur héxadécimale

  Les 8 couleurs primaires peuvent être représentés:

black rgb:0/0/0
red rgb:ffff/0/0
green rgb:0/ffff/0
blue rgb:0/0/ffff
yellow rgb:ffff/ffff/0
magenta rgb:ffff/0/ffff
cyan rgb:0/ffff/ffff
white rgb:ffff/ffff/ffff

   une intensité RGB est représentée par le préfix "rgbi": rgbi:‹red›/‹green›/‹blue›

  Les valeurs des couleur sont des virgules flottantes entre 0.0 et 1.0.

Claviers

   Le modèle de clavier X est dispatché en 2 couches: les codes spécifiques au serveur (keycodes) qui représentent les touches physiques, et les symboles indépendant du serveur (keysyms) qui représentent les lettres qui apparaissent sur les touches. 2 tables sont conservés sur le serveur pour convertir les keycodes en keysyms:

  modifier list: certaines clés ( Shift, Control, Caps lock) sont des modifieur et sont utilisés pour sélectionner différents symboles qui sont attachés à une touche. Quand une touche est enfoncée ou relâchée, le serveur génère un event qui contient le keycode de la clé indiquée et un masque qui spécifie le modifier key.

  keymap table: les applications traduisent les events keycode et modifier masks en keysyms en utilisant une table de keysyms qui contient une colonne pour chaque keycode est une colonne pour divers modifieurs. la sémantique exacte de l'interprétation de la table pour produire le keysyms dépends du programme, librairie et langage utilisé.

OPTIONS

Les programmes X acceptent automatiquement les options suivantes:
-display display Nom du serveur X à utiliser
-geometry geometry Taille et emplacement initiale de la fenêtre
-bg color, -background color Spécifie la couleur à utiliser pour la fond de la fenêtre
-bd color, -bordercolor color Spécifie la couleur à utiliser pour la bordure de la fenêtre
-bw number, -borderwidth number Largeur en pixel de la bordure de la fenêtre
-fg color, -foreground color Couleur à utiliser pour les textes et graphiques
-fn font, -font font Font à utiliser pour les textes à afficher
-iconic Lance la fenêtre réduite
-name Spécifie le nom sous lequel les ressources de l'application devraient être trouvés.
-rv, -reverse Simule le mode vidéo reverse si possible
+rv Indique que le programme ne devrait pas simuler le mode vidéo reverse.
-selectionTimeout Timeout en milliseconde pour 2 applications communicante doivent se répondre pour une requête de sélection
-synchronous Indique que les requêtes au server X devraient être envoyé synchrone. Utile pour le débuggage
-title string Titre utilisé pour la fenêtre
-xnllanguage language[_territory][.codeset] Spécifie la langue, territoire et codeset pour aider à résoudre les ressources et autres noms de fichier
-xrm resourcestring Nom et valeur de ressource pour remplacer les valeurs par défaut. Utile pour les paramètres qui n'ont pas d'options de ligne de commande.

Ressources

   Pour simplifier l'adaptation des applications aux préférences utilisateurs, X fournis un mécanisme pour stocker les valeurs par défaut pour les programmes, qui sont utilisés par les programmes qui utilisent X toolkit (les programmes utilisant GTK et QT toolkit utilisent des mécanismes de configuration autre). Les ressources sont spécifiés en tant que chaîne. Les composants de programme sont nommés de manière hiérarchique où chaque noeud est identifié par une classe et un nom d'instance. En haut se trouve la classe et le nom de l'application elle-même. Par convention, la nom nom de la classe et le nom de l'application, mais avec la première lettre en majuscule. La syntaxe pour les ressources est:

  ResourceLine = Comment | IncludeFile | ResourceSpec | ‹empty line›

   Comment = "!" {‹any character except null or newline›}

  IncludeFile = "#" WhiteSpace "include" WhiteSpace FileName WhiteSpace

  FileName = ‹valid filename for operating system›

  ResourceSpec = WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value

  ResourceName = [Binding] {Component Binding} ComponentName

  Binding = "." | "*"

  WhiteSpace = {‹space› | ‹horizontal tab›}

  Component = "?" | ComponentName

  ComponentName = NameChar {NameChar}

  NameChar = "a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"

  Value = {‹any character except null or unescaped newline›}

   Les programmes basés sur X toolkit obtiennent les ressources depuis les sources suivantes:

RESOURCE_MANAGER root window property Toutes les ressources globales disponibles pour les clients sur toutes les machines sont stockées dans la propriété RESOURCE_MANAGER de la fenêtre root du premier écran en utilisant xrdb.
SCREEN_RESOURCES root window property Toutes les ressources spécifiques à un écran donné disponible au client sur toutes les machines sont stockées dans la propriété SCREEN_RESOURCES de la fenêtre root de cet écran
application-specific files Les répertoires nommés par la variable d'environnement XUSERFILESEARCHPATH ou XAPPLRESDIR (qui nomment un seul répertoire et doit se terminer par /), et les répertoires standard (généralement dans /usr/share/X11, mais peut être changé avec XFILESEARCHPATH) sont parsés pour des ressources spécifique à une application
XENVIRONMENT Toutes ressources spécifique à une application ou un utilisateur peuvent être spécifiés dans XENVIRONMENT à un nom de fichier de ressource à charger par toutes les applications. Si elle n'est pas définie, un fichier nommé $HOME/.Xdefaults-hostname est recherché.
-xrm resourcestring Les ressources peuvent être spécifiées sur la ligne de commande. peut être spécifié plusieurs fois.

   Les ressources des programmes sont organisés en groupes appelés classes, les collections de ressources individuels (chacune appelée instance) peuvent être spécifiés en une fois. Par convention, le nom de l'instance commence avec une lettre minuscule et le nom de la classe avec une lettre majuscule. Les applications auront au moins les ressources suivantes:

background (class Background) Cette ressource spécifie la couleur à utiliser pour le fond de la fenêtre.
borderWidth (class BorderWidth) Cette ressource spécifie la largeur en pixel de la bordure de la fenêtre.
borderColor (class BorderColor) Cette ressource spécifie la couleur à utiliser pour la bordure de la fenêtre.

   En combinant les classes et instances, les préférences peuvent être définies rapidement et facilement. Par exemple:

bitmap*Dashed: off
XTerm*cursorColor: gold
XTerm*multiScroll: on
XTerm*jumpScroll: on
XTerm*reverseWrap: on
XTerm*curses: on
XTerm*Font: 6x10
XTerm*scrollBar: on
XTerm*scrollbar*thickness: 5
XTerm*multiClickTime: 500
XTerm*charClass: 33:48,37:48,45-47:48,64:48
XTerm*cutNewline: off
XTerm*cutToBeginningOfLine: off
XTerm*titeInhibit: on
XTerm*ttyModes: intr ^c erase ^? kill ^u
XLoad*Background: gold
XLoad*Foreground: red
XLoad*highlight: black
XLoad*borderWidth: 0
emacs*Geometry: 80x65-0-0
emacs*Background: rgb:5b/76/86
emacs*Foreground: white
emacs*Cursor: white
emacs*BorderColor: white
emacs*Font: 6x10
xmag*geometry: -0-0
xmag*borderColor: white
Si ces ressources étaient stockées dans un fichier nommé .Xresources dans le home, elles peuvent être ajoutées à des ressources existantes dans le serveur avec la ligne de commande:
% xrdb -merge $HOME/.Xresources

Variables d'environnement

DISPLAY Pointe vers un serveur X.
XAUTHORITY Pointe vers un fichier qui contient des données d'autorisation (défaut: $HOME/.Xauthority)
ICEAUTHORITY Pointe vers un fichier qui contient des données d'autorisation (défaut: $HOME/.ICEauthority)
LC_ALL, LC_CTYPE, LANG La première valeur non vide détermine les information de localité actuelles.
XMODIFIERS Contient des informations importantes pour la locale courante. (généralement: @im=‹input-method›)
XLOCALEDIR Pointe vers un répertoire contenant le fichier locale.alias et les hiérarchies de fichiers Compose et XLC_LOCALE pour toutes les locales. (défaut: /usr/share/X11/locale)
XENVIRONMENT Poine vers un fichier contenant les ressources X locales (défaut: $HOME/.Xdefaults-‹hostname›)
XFILESEARCHPATH doit contenir une liste de templates de paths, séparés par une ',' défaut:

        /usr/etc/X11/%L/%T/%N%C%S:\
        /usr/etc/X11/%L/%T/%N%C%S:\
        /usr/etc/X11/%T/%N%C%S:\
        /usr/etc/X11/%L/%T/%N%S:\
        /usr/etc/X11/%L/%T/%N%S:\
        /usr/etc/X11/%T/%N%S:\
        /usr/share/X11/%L/%T/%N%C%S:\
        /usr/share/X11/%L/%T/%N%C%S:\
        /usr/share/X11/%T/%N%C%S:\
        /usr/share/X11/%L/%T/%N%S:\
        /usr/share/X11/%L/%T/%N%S:\
        /usr/share/X11/%T/%N%S:\
        /usr/lib/X11/%L/%T/%N%C%S:\
        /usr/lib/X11/%L/%T/%N%C%S:\
        /usr/lib/X11/%T/%N%C%S:\
        /usr/lib/X11/%L/%T/%N%S:\
        /usr/lib/X11/%L/%T/%N%S:\
        /usr/lib/X11/%T/%N%S
        un template est transformé en sustituant:

        %D Chemin par défaut spécifique à l'implémentation
        %N nom (basename) de recherche
        %T type (dirname) de recherche
        %S suffix de recherche
        %C Valeur de la ressource "customization"
        %L Nom de locale
        %l Langue de la locale
        %t Térritoire de la locales
        %c Encodage de la locale

XUSERFILESEARCHPATH Liste de templates de path, où libXt recherche les fichiers de ressources dépendant de l'utilisateur. défaut:

        $XAPPLRESDIR/%L/%N%C:\
        $XAPPLRESDIR/%L/%N%C:\
        $XAPPLRESDIR/%N%C:\
        $HOME/%N%C:\
        $XAPPLRESDIR/%L/%N:\
        $XAPPLRESDIR/%L/%N:\
        $XAPPLRESDIR/%N:\
        $HOME/%N

XAPPLRESDIR Pointe vers un répertoire où l'utilisateur stocke ses fichiers de ressource dépendant des applications (défaut: $HOME") uniquement si XUSERFILESEARCHPATH n'est pas définis
XKEYSYMDB Pointe vers un fichier contenant des définitions de keysym non-standard (défaut: /usr/share/X11/XKeysymDB)
XCMSDB Pointe vers fichier de base de données de noms de couleur. (défaut: /usr/lib/X11/Xcms.txt)
RESOURCE_NAME Sert d'identifiant principal pour les ressources appartenant à exécuter. (défaut: le basename du pathname du programme)
SESSION_MANAGER Spécifie le gestionnaire de session
XF86BIGFONT_DISABLE si non vide, désactive l'extension XFree86-Bigfont.
XKB_FORCE Influence l'extension X Keyboard
XKB_DISABLE Influence l'extension X Keyboard
XKB_DEBUG Influence l'extension X Keyboard
_XKB_CHARSET Influence l'extension X Keyboard
_XKB_LOCALE_CHARSETS Influence l'extension X Keyboard
_XKB_OPTIONS_ENABLE Influence l'extension X Keyboard
_XKB_LATIN1_LOOKUP Influence l'extension X Keyboard
_XKB_CONSUME_LOOKUP_MODS Influence l'extension X Keyboard
_XKB_CONSUME_SHIFT_AND_LOCK Influence l'extension X Keyboard
_XKB_IGNORE_NEW_KEYBOARDS Influence l'extension X Keyboard
_XKB_CONTROL_FALLBACK Influence l'extension X Keyboard
_XKB_COMP_LED _XKB_COMP_FAIL_BEEP Influence l'extension X Keyboard

Exemples

Lignes de commande fréquemment utilisés:
% xrdb $HOME/.Xresources
% xmodmap -e "keysym BackSpace = Delete"
% mkfontdir /usr/local/lib/X11/otherfonts
% xset fp+ /usr/local/lib/X11/otherfonts
% xmodmap $HOME/.keymap.km
% xsetroot -solid ’rgbi:.8/.8/.8’
% xset b 100 400 c 50 s 1800 r on
% xset q
% twm
% xmag
% xclock -geometry 48x48-0+0 -bg blue -fg white
% xeyes -geometry 48x48-48+0
% xbiff -update 20
% xlsfonts ’*helvetica*’
% xwininfo -root
% xdpyinfo -display joesworkstation:0
% xhost -joesworkstation
% xrefresh
% xwd | xwud
% bitmap companylogo.bm 32x32
% xcalc -bg blue -fg magenta
% xterm -geometry 80x66-0-0 -name myxterm $*
^
18 janvier 2014

htmlpdflatexmanmd




x11perf

x11perf

Programme de test de performance du serveur X11. x11perf mesure les performances du gestionnaire de fenêtre et des performances graphiques.

OPTIONS

-display host:dpy Affichage à utiliser
-sync Lance le test en mode synchrone. Utile pour debugger
-pack Lance les tests de rectangle pour qu'ils soients packés à côtés. Utile pour débugger
-repeat ‹n› Répète chaque test n fois (défaut:5)
-time ‹s› Durée de chaque test en seconde (défaut: 5 secondes)
-all Lance tous les tests
-range ‹test1›[,‹test2›] Lance tous les tests depuis test1 à test2
-labels Génère seulement les labels descriptifs pour chaque test spécifié. voir x11perfcomp
-fg color-or-pixel Spécifie la couleur du fond à utiliser
-bg color-or-pixel Spécifie la couleur à utiliser
-clips default Nombre de fenêtres par défaut
-ddbg color-or-pixel Couleur à utiliser pour dessiner les segments impaires d'une ligne double ou arc.
-rop ‹rop0 rop1 ...› Spécifie les ops au lieu de GXcopy. Ne concerne que les repères graphiques dans lequel la fonction est utilisée
-pm ‹pm0 pm1 ...› Utilise les planemasks spécifiés. Affecte seulement les graphiques dans lequel le planemask est utilisée
-depth ‹depth› Utilise un visuel avec depth plan par pixel
-vclass ‹vclass› Utilise un visuel avec la classe spécifiée (StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, or DirectColor
-reps ‹n› Compteur de répétition
-subs ‹s0 s1 ...› Nombre de sous-fenêtres à utiliser dans la fenêtre de tests (défaut: 4, 16, 25, 50, 75, 100 et 200)
-v1.2 Effectue les tests avec la sémantique x11perf v1.2
-v1.3 Effectue les tests avec la sémantique x11perf v1.3
-su Définis l'attribut save_under de la fenêtre à True sur toutes les fenêtre créées
-bs ‹backing_store_hint› Définis l'attribut backing_store de la fenêtre à la valeur donnée sur toutes les fenêtres créées.
-noop X protocol NoOperation
-atom GetAtomName
-pointer QueryPointer
-prop GetProperty
-gc Change graphics context
-create Create child window and map using MapSubwindows
-ucreate Create unmapped window
-map Map child window via MapWindow on parent
-unmap Unmap child window via UnmapWindow on parent
-destroy Destroy child window via DestroyWindow parent
-popup Hide/expose window via Map/Unmap popup window
-move Move window
-umove Moved unmapped window
-movetree Move window via MoveWindow on parent
-resize Resize window
-uresize Resize unmapped window
-circulate Circulate lowest window to top
-ucirculate Circulate unmapped window to top
-dot Dot.
-rect1 1x1 solid-filled rectangle.
-rect10 10x10 solid-filled rectangle.
-rect100 100x100 solid-filled rectangle.
-rect500 500x500 solid-filled rectangle.
-srect1 1x1 transparent stippled rectangle, 8x8 stipple pattern.
-srect10 10x10 transparent stippled rectangle, 8x8 stipple pattern.
-srect100 100x100 transparent stippled rectangle, 8x8 stipple pattern.
-srect500 500x500 transparent stippled rectangle, 8x8 stipple pattern.
-osrect1 1x1 opaque stippled rectangle, 8x8 stipple pattern.
-osrect10 10x10 opaque stippled rectangle, 8x8 stipple pattern.
-osrect100 100x100 opaque stippled rectangle, 8x8 stipple pattern.
-osrect500 500x500 opaque stippled rectangle, 8x8 stipple pattern.
-tilerect1 1x1 tiled rectangle, 4x4 tile pattern.
-tilerect10 10x10 tiled rectangle, 4x4 tile pattern.
-tilerect100 100x100 tiled rectangle, 4x4 tile pattern.
-tilerect500 500x500 tiled rectangle, 4x4 tile pattern.
-oddsrect1 1x1 transparent stippled rectangle, 17x15 stipple pattern.
-oddsrect10 10x10 transparent stippled rectangle, 17x15 stipple pattern.
-oddsrect100 100x100 transparent stippled rectangle, 17x15 stipple pattern.
-oddsrect500 500x500 transparent stippled rectangle, 17x15 stipple pattern.
-oddosrect1 1x1 opaque stippled rectangle, 17x15 stipple pattern.
-oddosrect10 10x10 opaque stippled rectangle, 17x15 stipple pattern.
-oddosrect100 100x100 opaque stippled rectangle, 17x15 stipple pattern.
-oddosrect500 500x500 opaque stippled rectangle, 17x15 stipple pattern.
-oddtilerect1 1x1 tiled rectangle, 17x15 tile pattern.
-oddtilerect10 10x10 tiled rectangle, 17x15 tile pattern.
-oddtilerect100 100x100 tiled rectangle, 17x15 tile pattern.
-oddtilerect500 500x500 tiled rectangle, 17x15 tile pattern.
-bigsrect1 1x1 stippled rectangle, 161x145 stipple pattern.
-bigsrect10 10x10 stippled rectangle, 161x145 stipple pattern.
-bigsrect100 100x100 stippled rectangle, 161x145 stipple pattern.
-bigsrect500 500x500 stippled rectangle, 161x145 stipple pattern.
-bigosrect1 1x1 opaque stippled rectangle, 161x145 stipple pattern.
-bigosrect10 10x10 opaque stippled rectangle, 161x145 stipple pattern.
-bigosrect100 100x100 opaque stippled rectangle, 161x145 stipple pattern.
-bigosrect500 500x500 opaque stippled rectangle, 161x145 stipple pattern.
-bigtilerect1 1x1 tiled rectangle, 161x145 tile pattern.
-bigtilerect10 10x10 tiled rectangle, 161x145 tile pattern.
-bigtilerect100 100x100 tiled rectangle, 161x145 tile pattern.
-bigtilerect500 500x500 tiled rectangle, 161x145 tile pattern.
-eschertilerect1 1x1 tiled rectangle, 215x208 tile pattern.
-eschertilerect10 10x10 tiled rectangle, 215x208 tile pattern.
-eschertilerect100 100x100 tiled rectangle, 215x208 tile pattern.
-eschertilerect500 500x500 tiled rectangle, 215x208 tile pattern.
-seg1 1-pixel thin line segment.
-seg10 10-pixel thin line segment.
-seg100 100-pixel thin line segment.
-seg500 500-pixel thin line segment.
-seg100c1 100-pixel thin line segment (1 obscuring rectangle).
-seg100c2 100-pixel thin line segment (2 obscuring rectangles).
-seg100c3 100-pixel thin line segment (3 obscuring rectangles).
-dseg10 10-pixel thin dashed segment (3 on, 2 off).
-dseg100 100-pixel thin dashed segment (3 on, 2 off).
-ddseg100 100-pixel thin double-dashed segment (3 fg, 2 bg).
-hseg10 10-pixel thin horizontal line segment.
-hseg100 100-pixel thin horizontal line segment.
-hseg500 500-pixel thin horizontal line segment.
-vseg10 10-pixel thin vertical line segment.
-vseg100 100-pixel thin vertical line segment.
-vseg500 500-pixel thin vertical line segment.
-whseg10 10-pixel wide horizontal line segment.
-whseg100 100-pixel wide horizontal line segment.
-whseg500 500-pixel wide horizontal line segment.
-wvseg10 10-pixel wide vertical line segment.
-wvseg100 100-pixel wide vertical line segment.
-wvseg500 500-pixel wide vertical line segment.
-line1 1-pixel thin (width 0) line.
-line10 10-pixel thin line.
-line100 100-pixel thin line.
-line500 500-pixel thin line.
-dline10 10-pixel thin dashed line (3 on, 2 off).
-dline100 100-pixel thin dashed line (3 on, 2 off).
-ddline100 100-pixel thin double-dashed line (3 fg, 2 bg).
-wline10 10-pixel line, line width 1.
-wline100 100-pixel line, line width 10.
-wline500 500-pixel line, line width 50.
-wdline100 100-pixel dashed line, line width 10 (30 on, 20 off).
-wddline100 100-pixel double-dashed line, line width 10 (30 fg, 20 bg).
-orect10 10x10 thin rectangle outline.
-orect100 100-pixel thin vertical line segment.
-orect500 500-pixel thin vertical line segment.
-worect10 10x10 wide rectangle outline.
-worect100 100-pixel wide vertical line segment.
-worect500 500-pixel wide vertical line segment.
-circle1 1-pixel diameter thin (line width 0) circle.
-circle10 10-pixel diameter thin circle.
-circle100 100-pixel diameter thin circle.
-circle500 500-pixel diameter thin circle.
-dcircle100 100-pixel diameter thin dashed circle (3 on, 2 off).
-ddcircle100 100-pixel diameter thin double-dashed circle (3 fg, 2 bg).
-wcircle10 10-pixel diameter circle, line width 1.
-wcircle100 100-pixel diameter circle, line width 10.
-wcircle500 500-pixel diameter circle, line width 50.
-wdcircle100 100-pixel diameter dashed circle, line width 10 (30 on, 20 off).
-wddcircle100 100-pixel diameter double-dashed circle, line width 10 (30 fg, 20 bg).
-pcircle10 10-pixel diameter thin partial circle, orientation and arc angle evenly distributed.
-pcircle100 100-pixel diameter thin partial circle.
-wpcircle10 10-pixel diameter wide partial circle.
-wpcircle100 100-pixel diameter wide partial circle.
-fcircle1 1-pixel diameter filled circle.
-fcircle10 10-pixel diameter filled circle.
-fcircle100 100-pixel diameter filled circle.
-fcircle500 500-pixel diameter filled circle.
-fcpcircle10 10-pixel diameter partial filled circle, chord fill, orientation and arc angle evenly distributed.
-fcpcircle100 100-pixel diameter partial filled circle, chord fill.
-fspcircle10 10-pixel diameter partial filled circle, pie slice fill, orientation and arc angle evenly distributed.
-fspcircle100 100-pixel diameter partial filled circle, pie slice fill.
-ellipse10 10-pixel diameter thin (line width 0) ellipse, major and minor axis sizes evenly distributed.
-ellipse100 100-pixel diameter thin ellipse.
-ellipse500 500-pixel diameter thin ellipse.
-dellipse100 100-pixel diameter thin dashed ellipse (3 on, 2 off).
-ddellipse100 100-pixel diameter thin double-dashed ellipse (3 fg, 2 bg).
-wellipse10 10-pixel diameter ellipse, line width 1.
-wellipse100 100-pixel diameter ellipse, line width 10.
-wellipse500 500-pixel diameter ellipse, line width 50.
-wdellipse100 100-pixel diameter dashed ellipse, line width 10 (30 on, 20 off).
-wddellipse100 100-pixel diameter double-dashed ellipse, line width 10 (30 fg, 20 bg).
-pellipse10 10-pixel diameter thin partial ellipse.
-pellipse100 100-pixel diameter thin partial ellipse.
-wpellipse10 10-pixel diameter wide partial ellipse.
-wpellipse100 100-pixel diameter wide partial ellipse.
-fellipse10 10-pixel diameter filled ellipse.
-fellipse100 100-pixel diameter filled ellipse.
-fellipse500 500-pixel diameter filled ellipse.
-fcpellipse10 10-pixel diameter partial filled ellipse, chord fill.
-fcpellipse100 100-pixel diameter partial filled ellipse, chord fill.
-fspellipse10 10-pixel diameter partial filled ellipse, pie slice fill.
-fspellipse100 100-pixel diameter partial filled ellipse, pie slice fill.
-triangle1 Fill 1-pixel/side triangle.
-triangle10 Fill 10-pixel/side triangle.
-triangle100 Fill 100-pixel/side triangle.
-trap1 Fill 1x1 trapezoid.
-trap10 Fill 10x10 trapezoid.
-trap100 Fill 100x100 trapezoid.
-trap300 Fill 300x300 trapezoid.
-strap1 Fill 1x1 transparent stippled trapezoid, 8x8 stipple pattern.
-strap10 Fill 10x10 transparent stippled trapezoid, 8x8 stipple pattern.
-strap100 Fill 100x100 transparent stippled trapezoid, 8x8 stipple pattern.
-strap300 Fill 300x300 transparent stippled trapezoid, 8x8 stipple pattern.
-ostrap1 Fill 10x10 opaque stippled trapezoid, 8x8 stipple pattern.
-ostrap10 Fill 10x10 opaque stippled trapezoid, 8x8 stipple pattern.
-ostrap100 Fill 100x100 opaque stippled trapezoid, 8x8 stipple pattern.
-ostrap300 Fill 300x300 opaque stippled trapezoid, 8x8 stipple pattern.
-tiletrap1 Fill 10x10 tiled trapezoid, 4x4 tile pattern.
-tiletrap10 Fill 10x10 tiled trapezoid, 4x4 tile pattern.
-tiletrap100 Fill 100x100 tiled trapezoid, 4x4 tile pattern.
-tiletrap300 Fill 300x300 tiled trapezoid, 4x4 tile pattern.
-oddstrap1 Fill 1x1 transparent stippled trapezoid, 17x15 stipple pattern.
-oddstrap10 Fill 10x10 transparent stippled trapezoid, 17x15 stipple pattern.
-oddstrap100 Fill 100x100 transparent stippled trapezoid, 17x15 stipple pattern.
-oddstrap300 Fill 300x300 transparent stippled trapezoid, 17x15 stipple pattern.
-oddostrap1 Fill 10x10 opaque stippled trapezoid, 17x15 stipple pattern.
-oddostrap10 Fill 10x10 opaque stippled trapezoid, 17x15 stipple pattern.
-oddostrap100 Fill 100x100 opaque stippled trapezoid, 17x15 stipple pattern.
-oddostrap300 Fill 300x300 opaque stippled trapezoid, 17x15 stipple pattern.
-oddtiletrap1 Fill 10x10 tiled trapezoid, 17x15 tile pattern.
-oddtiletrap10 Fill 10x10 tiled trapezoid, 17x15 tile pattern.
-oddtiletrap100 Fill 100x100 tiled trapezoid, 17x15 tile pattern.
-oddtiletrap300 Fill 300x300 tiled trapezoid, 17x15 tile pattern.
-bigstrap1 Fill 1x1 transparent stippled trapezoid, 161x145 stipple pattern.
-bigstrap10 Fill 10x10 transparent stippled trapezoid, 161x145 stipple pattern.
-bigstrap100 Fill 100x100 transparent stippled trapezoid, 161x145 stipple pattern.
-bigstrap300 Fill 300x300 transparent stippled trapezoid, 161x145 stipple pattern.
-bigostrap1 Fill 10x10 opaque stippled trapezoid, 161x145 stipple pattern.
-bigostrap10 Fill 10x10 opaque stippled trapezoid, 161x145 stipple pattern.
-bigostrap100 Fill 100x100 opaque stippled trapezoid, 161x145 stipple pattern.
-bigostrap300 Fill 300x300 opaque stippled trapezoid, 161x145 stipple pattern.
-bigtiletrap1 Fill 10x10 tiled trapezoid, 161x145 tile pattern.
-bigtiletrap10 Fill 10x10 tiled trapezoid, 161x145 tile pattern.
-bigtiletrap100 Fill 100x100 tiled trapezoid, 161x145 tile pattern.
-bigtiletrap300 Fill 300x300 tiled trapezoid, 161x145 tile pattern.
-eschertiletrap1 Fill 1x1 tiled trapezoid, 216x208 tile pattern.
-eschertiletrap10 Fill 10x10 tiled trapezoid, 216x208 tile pattern.
-eschertiletrap100 Fill 100x100 tiled trapezoid, 216x208 tile pattern.
-eschertiletrap300 Fill 300x300 tiled trapezoid, 216x208 tile pattern.
-complex10 Fill 10-pixel/side complex polygon.
-complex100 Fill 100-pixel/side complex polygon.
-64poly10convex Fill 10x10 convex 64-gon.
-64poly100convex Fill 100x100 convex 64-gon.
-64poly10complex Fill 10x10 complex 64-gon.
-64poly100complex Fill 100x100 complex 64-gon.
-ftext Character in 80-char line (6x13).
-f8text Character in 70-char line (8x13).
-f9text Character in 60-char line (9x15).
-f14text16 2-byte character in 40-char line (k14).
-tr10text Character in 80-char line (Times-Roman 10).
-tr24text Character in 30-char line (Times-Roman 24).
-polytext Character in 20/40/20 line (6x13, Times-Roman 10, 6x13).
-polytext16 2-byte character in 7/14/7 line (k14, k24).
-fitext Character in 80-char image line (6x13).
-f8itext Character in 70-char image line (8x13).
-f9itext Character in 60-char image line (9x15).
-f14itext16 2-byte character in 40-char image line (k14).
-f24itext16 2-byte character in 23-char image line (k24).
-tr10itext Character in 80-char image line (Times-Roman 10).
-tr24itext Character in 30-char image line (Times-Roman 24).
-scroll10 Scroll 10x10 pixels vertically.
-scroll100 Scroll 100x100 pixels vertically.
-scroll500 Scroll 500x500 pixels vertically.
-copywinwin10 Copy 10x10 square from window to window.
-copywinwin100 Copy 100x100 square from window to window.
-copywinwin500 Copy 500x500 square from window to window.
-copypixwin10 Copy 10x10 square from pixmap to window.
-copypixwin100 Copy 100x100 square from pixmap to window.
-copypixwin500 Copy 500x500 square from pixmap to window.
-copywinpix10 Copy 10x10 square from window to pixmap.
-copywinpix100 Copy 100x100 square from window to pixmap.
-copywinpix500 Copy 500x500 square from window to pixmap.
-copypixpix10 Copy 10x10 square from pixmap to pixmap.
-copypixpix100 Copy 100x100 square from pixmap to pixmap.
-copypixpix500 Copy 500x500 square from pixmap to pixmap.
-copyplane10 Copy 10x10 1-bit deep plane.
-copyplane100 Copy 100x100 1-bit deep plane.
-copyplane500 Copy 500x500 1-bit deep plane.
-putimage10 PutImage 10x10 square.
-putimage100 PutImage 100x100 square.
-putimage500 PutImage 500x500 square.
-putimagexy10 PutImage XY format 10x10 square.
-putimagexy100 PutImage XY format 100x100 square.
-putimagexy500 PutImage XY format 500x500 square.
-shmput10 PutImage 10x10 square, MIT shared memory extension.
-shmput100 PutImage 100x100 square, MIT shared memory extension.
-shmput500 PutImage 500x500 square, MIT shared memory extension.
-shmputxy10 PutImage XY format 10x10 square, MIT shared memory extension.
-shmputxy100 PutImage XY format 100x100 square, MIT shared memory extension.
-shmputxy500 PutImage XY format 500x500 square, MIT shared memory extension.
-getimage10 GetImage 10x10 square.
-getimage100 GetImage 100x100 square.
-getimage500 GetImage 500x500 square.
-getimagexy10 GetImage XY format 10x10 square.
-getimagexy100 GetImage XY format 100x100 square.
-getimagexy500 GetImage XY format 500x500 square.
^
18 janvier 2014

htmlpdflatexmanmd




x11perfcomp

x11perfcomp

Comparaison de performance serveur X

   x11perfcomp fusionne la sortie de nombreux résultats de x11perf dans un format utile. Il utilise le premier fichier donné pour déterminer quel tests spécifiques il doit reporter, ce fichier doit donc contenir un superset des tests reportés dans les autres fichiers, sinon x11perfcomp échoue.

OPTIONS

-r Spécifie que la sortie doit également inclure les performances relatives
-ro Spécifie que la sortie doit uniquement inclure les performances relatives
-l label_file Spécifie un label à utiliser
^
17 octobre 2016

htmlpdflatexmanmd




xargs

xargs

Construire et exécuter des commandes depuis l'entrée standard

   xargs lit des éléments depuis l'entrée standard, délimité par des espaces blancs, et exécute la commande spécifié une ou plusieurs fois. La ligne de commande pour la commande est construite jusqu'à ce quelle atteigne une limite définie par le système (sauf si -n et -L sont utilisés). La commande spécifiée sera invoquée autant de fois que nécessaire pour utiliser la liste des éléments d'entrée.

OPTIONS

-0, --null Les éléments d'entrée sont terminés par un caractère null au lieu d'un espace blanc, et les ' et \ ne sont pas spéciaux
-a file, --arg-file=file Lis les éléments depuis le fichier au lieu de l'entrée standard.
eof-str Définis la chaîne EOF.
-e[eof-str], --eof[=eof-str] Idem à -E. -E est conforme POSIX alors que cette option ne l'est pas. Si eof-str est omis, il n'y a pas de chaîne EOF.
-I replace-str Remplace les occurences de replace-str dans les arguments initials avec les noms lus depuis l'entrée standard.
-L max-lines Utilise au moins max-lines lignes d'entrées non-blancs par ligne de commande.
max-args, --max-args=max-args Utilise au moins max-args arguments par ligne de commande.
-P max-procs, --max-procs=max-procs Lance jusqu'à max-procs processus à la fois. Défaut: 1. À 0, xargs lance autant de processus que possible à la fois.
-p, --interactive Demande à l'utilisateur s'il lance chaque ligne de commande et lit une ligne depuis le terminal. Implique -t
--process-slot-var=name Définis une variable d'environnement.
-r, --no-run-if-empty Si l'entrée standard ne contient rien de non blanc, ne lance pas la commande.
-s max-chars, --max-chars=max-chars Utilise au moins max-chars caractères par ligne de commande, incluant la commande est les arguments initiaux et la caractère null terminant la chaîne d'arguments.
--show-limits Affiche les limites de la longueur de la ligne de commande imposée par l'OS.
-t, --verbose Affiche la ligne de commande sur l'erreur standard avant de l'exécuter
-x, --exit Quitte si la taille (-s) est dépassée

Exemples

Trouve les fichiers nommés core dans /tmp et les supprime
find /tmp -name core -type f -print | xargs /bin/rm -f
Trouve les fichiers nommés core dans /tmp et les supprime, en gérant les espaces dans les noms de fichier
find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f
Trouve les fichiers nommés core dans /tmp et les supprime, mais plus efficacement que dans l'exemple précédent (on évite d'utiliser fork(2) et exec(2) pour lancer rm)
find /tmp -depth -name core -type f -delete
Génère un listing compacte de tous les utilisateurs dans le système
cut -d: -f1 ‹ /etc/passwd | sort | xargs echo
Lance le nombre de copies minimum d'Emacs nécessaire, une après l'autre, pour éditer les fichiers listés dans l'entrées xargs:
xargs sh -c 'emacs "$@" ‹ /dev/tty' emacs

Codes de sortie

0 succès
123 une des commandes invoquée s'est terminé par un code entre 1 et 125
124 La commande s'est terminée par un code 255
125 La commande a été tuée par un signal
126 La commande ne peut pas être lancée
127 Commande non trouvée
1 Une autre erreur s'est produite
^
19 janvier 2014

htmlpdflatexmanmd




xauth

xauth

Utilitaire de fichier authority

   xauth est utilisé pour éditer et afficher les informations d'autorisation utilisé pour se connecter à un serveur X. Il est générallement utilisé pour extraire les enregistrements d'autorisation d'une machine et les fusionner sur une autre. Les commandes peuvent être entrées sur la ligne de commande ou interactivement. Ce programme ne contact pas le serveur X excepté quand la commande generate est utilisée. Normalement il n'est pas utilisé pour créer de fichier autorisation, c'est le programme qui lance X qui s'en charge.

OPTIONS

-f authfile Spécifie le nom du fichier à utiliser (défaut: utilise le fichier spécifié dans la variable XAUTHORITY, ou .Xauthority dans le home de l'utilisateur)
-q mode silencieux. N'affiche pas de messages de status non sollicité.
-v Augmente la verbosité
-i Ignore les locks sur les fichiers d'autorisation
-b Tente de casser tout lock sur le fichier avant de le traiter
-n  Tente de résoudre les noms d'hôte

COMMANDES

add displayname protocolname hexkey Ajoute au fichier le display avec le protocole et la clé spécifié.
generate displayname protocolname [trusted|untrusted] [timeout seconds] [group group-id] [data hexdata] Similaire à add, mais au lieu de spécifier les données, il se connecte au serveur spécifié et utilise l'extension SECURITY pour obtenir les données de clé à stocker dans le fichier d'autorisation. trusted: les clients qui se connectent avec cette autorisation auront accès à l'affichage. timeout: nombre de secondes de validité de cette autorisation. group: groupe de connexion. data: Donnée que le serveur doit utiliser pour générer l'autorisation.
[n]extract filename displayname... Les entrées d'autorisation pour chaque affichage spécifié sont écris dans le fichier spécifié
[n]list [displayname...] Affiche les entrées d'autorisation pour les affichages spécifiés
[n]merge [filename...] Les entrées d'autorisation du fichier spécifié sont lus et fusionnés dans la base d'autorisation
remove displayname Les entrées d'autorisation correspondant à l'écran spécifié sont supprimés
source filename Le fichier spécifié est traité comme un script contenant les commandes xauth
info Informations décrivant le fichier d'autorisation
exit Ecrit les modifications et quitte
quit Quitte en ignorant les modifications
? Liste les commandes disponibles

Exemples

Extraire l'entrée de l'affichage courant, le copie sur une autre machine, et le fusionne dans le fichier authority de l'utilisateur sur la machine distante
xauth extract - $DISPLAY | ssh otherhost xauth merge -
Contact le serveur :0 pour créer une autorisation en utilisant le protocole MIT-MAGIC-COOKIE-1. Les clients qui se connectent avec cette autorisation ne seront pas trustés
xauth generate :0

Variables d'environnement

XAUTHORITY Pointe vers un fichier qui contient des données d'autorisation (défaut: $HOME/.Xauthority)
HOME Répertoire personnel de l'utilisateur
^
19 janvier 2014

htmlpdflatexmanmd




xbacklight

xbacklight

Ajuste la luminosité en utilisant l'extension RandR

OPTIONS

-get Affiche la luminosité courante de chaque sortie
-set percent Définis la luminosité au niveau spécifié
-inc percent Augmente la luminosité par la quantité spécifiée
-dec percent Diminue la luminosité par la quantité spécifiée
-time milliseconds durée de la transition entre la luminosité courante et la nouvelle valeur (défaut: 200)
-steps number Nombre de pas durant la transition (défaut: 20)
^
19 janvier 2014

htmlpdflatexmanmd




xcmsdb

xcmsdb

Utilitaire de caractérisation de couleur pour X Color Management System

   xcmsdb est utilisé pour charger, requêter, ou supprimer des données de caractérisation de couleur de périphérique stockés dans les propriétés de la fenêtre root. Ces données font partie du système de gestion de couleur X de Xlib (Xcms), nécessaire pour convertir les spécifications de couleur entre les formes dépendante et indépendantes des périphériques. Xcms utilise une matrice 3x3 stockée dans la propriété XDCCC_LINEAR_RGB_MATRICES pour convertir les couleurs entre les intensités CIEXYZ et RGB. Xcms utilise ensuite les informations de gamma stockées dans XDCCC_LINEAR_RGB_CORRECTION pour convertir les spécifications de couleur entre RGBi et les périphériques RGB. Xcms permet aux clients d'enregistrer des jeux de fonctions en plus de celles intégrées pour les moniteurs CRT.

OPTIONS

-query tente de lire les propriétés XDCCC de la fenêtre root et transforme la données en format plus lisible
-remove tente de supprimer les propriétés XDCCC de la fenêtre root
-format 32|16|8 Spécifie le format de la propriété pour XDCCC_LINEAR_RGB_CORRECTION (défaut: 32)

Variable d'environnement

DISPLAY Numéro d'affichage et hôte par défaut
^
19 janvier 2014

htmlpdflatexmanmd




xcursorgen

xcursorgen



   xcursorgen lit le fichier spécifié pour trouver une liste d'images de curseur. Il les convertis au forma xcursor et les écrit dans le fichier de sortie. Chaque ligne du fichier de configuration a le format suivant:

  ‹size› ‹xhot› ‹yhot› ‹filename› ‹ms-delay›

  Plusieurs images avec la même taille sont utilisés pour créer des curseurs animés.

OPTIONS

-p dir, --prefix dir Trouve les images de curseur dans le répertoire spécifié. Non spécifié, utilise le répertoire courant.
^
26 janvier 2014

htmlpdflatexmanmd




xdmx

xdmx

Serveur X Multi-head distribué

   xdmx est un serveur proxy X qui utilise un ou plusieurs autres serveurs X comme périphérique d'affichage. Il fournis des fonctionnalités multi-head pour les affichages qui peuvent être localisés sur différentes machines. xdmx communique avec les serveurs X en utilisant le protocole X11 standard, et/ou les extensions communes disponibles.

OPTIONS

-display display-name Nom du serveur X back-end auquel se connecter. Peut être spécifié plusieurs fois. Le premier est utilisé comme écran 0, le suivant l'écran 1, etc. Si omis, utilise $DISPLAY
-xinput input-source Spécifie la source à utiliser pour les extensions de périphériques xinput. Les choix sont les mêmes que pour input, excepté que les périphériques sur les serveurs back-end ne peuvent pas être traités comme tel.
-input input-source Spécifie la source à utiliser pour le périphériques d'entrée core. les choix sont:

        dummy Un jeu de pilotes d'entrée factice à utiliser. Ne génèrent jamais d'events d'entrée.
        local Utilise le clavier et pointeur local. une liste de pilotes peut être ajoutée (ex: -input local,kbd,ps2)
        display-name Si le nom d'affichage est un serveur back-end, les events d'entrées sont pris depuis le serveur spécifié. Sinon, une fenêtre console sera ouverte sur l'affichage spécifié.
        Si display-name des suivi par ",xi" alors les pérphériques XInput sur l'affichage sont utilisés comme périphérique XInput Xdmx. Si display-name est suivi par ",noxi" alors les périphériques XInput sur l'affichage ne seront par utilisés comme périphériques XInput Xdmx,
        Si display-name est suivi par ",console" et que display-name réfère à un affichage qui est utilisé comme affichage backend, alors une fenêtre console sera ouverte sur cet affichage et sera traité comme affichage backend. Si display-name est suivi par ",noconsole", l'affichage sera traité purement comme backend ou affichage console.
        Si display-name est suivi par ",windows", alors les outlines dans les fenêtres dans le backend seront affichés dans la fenêtre console. Si display-name est suivi par ",nowindows", la fenêtre console n'affichera par les outlines des fenêtres backend.
        Si display-name est suivi par ",xkb", les 1 à 3 paramètres suivant vont spécifier les keycodes, symboles et géométrie du clavier pour ce périphérique d'entrée. Ex: ",xkb,xfree86,pc104" spécifie que les keycodes xfree86 et les symboles "pc104" devraient être utilisés pour initialiser le clavier. Une liste le keycodes, symboles et géométries se trouvent dans /usr/share/X11/xkb.

   Si cette option n'est pas spécifisé, la source d'entrée est le premier serveur backend (celui utilisé pour l'écran 0). La fenêtre console affiche le layout des affichage backend et les events dans la fenêtre console seront utilisés comme périphériques d'entrée core. De nombreuses touches de fonction sont actives, en fonction de la source d'entrée

        Ctrl-Alt-q Termine le serveur Xdmx dans tous les modes
        Ctrl-Alt-g Bascule un serveur grab en mode console
        Ctrl-Alt-f Bascule en fine-grain motion en mode console.
        Ctrl-Alt-F1 à F12 Switch sur un autre VC en mode local.

-shadowfb Active le support pour le shadow frame buffer
-noshadowfb Désactive le support pour le shadow frame buffer
-nomulticursor Désactive de support pour l'affichage de plusieurs curseurs sur des affichages backend chevauchés.
-fontpath Chemin des fonts par défaut du serveur xdmx
-configfile filename Fichier de configuration à lire. Si -display est spécifié, le fichier de configuration est ignoré.
-config name Spécifie une configuration à utiliser, name est le nom du virtual dans le fichier de configuration
-stat interval screens Active les statistique de performances de l'affichage.
-syncbatch interval Définis l'interval en millisecondes pour XSync() batching.
-nooffscreenopt Désactive l'optimisation offscreen.
-nowindowopt Désactive l'optimisation de création de fenêtre
-nosubdivprims Désactive l'optimisation les subdivisions de primitives
-noxkb Désactive l'utilisation les extensions XKB pour communiquer avec les affichages backend.
-depth int Définis la profondeur par défaut de la fenêtre root.
-norender Désactive l'extension RENDER
-noglxproxy Désactive les proxy GLX.
-noglxswapgroup Désactive le groupe swap et les extension de swap dans le proxy GLX
-glxsyncswap Active la synchronisation après un swap buffer.
-glxfinishswap Active la synchronisation après un swap buffer.
-ignorebadfontpaths Ignore les chemins de fonts non disponibles sur tous les backend.
-param Spécifie les paramètres sur la ligne de commande. Actuellement, seul les paramètres pour XKEYBOARD sont supportés.

Grammaire de fichier de configuration

   Les mots suivants sont réservés:

  virtual display wall option param { } ; #

  La grammaire est comme suit:

        virtual-list ::= [ virtual-list ] | virtual
        virtual ::= virtual [ name ] [ dim ] { dw-list }
        dw-list ::= [ dw-list ] | dw
        dw ::= display | wall | option
        display ::= display name [ geometry ] [ / geometry ] [ origin ] ;
        wall ::= wall [ dim ] [ dim ] name-list ;
        option ::= option name-list ;
        param ::= param name-list ;
        param ::= param { param-list }
        param-list ::= [ param-list ] | name-list ;
        name-list ::= [ name-list ] | name
        name ::= string | double-quoted-string
        dim ::= integer x integer
        geometry ::= [ integer x integer ] [ signed-integer signed-integer ]
        origin ::= @ integer x integer

Exemple de fichier de configuration

2 affichage sont utilisés pour un bureau
virtual example0 {
display d0:0 1280x1024 @0x0;
display d1:0 1280x1024 @1280x0;
}
virtual example1 {
display d0:0 1280x1024;
display d1:0 @1280x0;
}
virtual example2 {
display "d0:0";
display "d1:0" @1280x0;
}
virtual example3 { wall 2x1 d0:0 d1:0; }
Un Mur 4x4 de 16 affichages peut être spécifié comme suit
virtual example4 {
wall d0:0 d1:0 d2:0 d3:0
d4:0 d5:0 d6:0 d7:0
d8:0 d9:0 da:0 db:0
dc:0 dd:0 de:0 df:0;
}

Chemins de fonts

   Le font path utilisé par le serveur Xdmx est propagé à chaque serveur backend, ce qui nécessite que chaque serveur backend ait accès au même chemin de fonts que le serveur frontend. Cela peut se faire en utilisant un serveur de fonts ou en montant les chemins de fonts sur chaque serveur. Par exemple, si on spécifie un font path avec la commande suivante:

  xdmx :1 -display d0:0 -fontpath /usr/fonts/75dpi/ -fontpath /usr/fonts/Type1/ +xinerama

  alors /usr/fonts/75dpi/ et /usr/fonts/Type1/ doivent être valide pour tous les serveurs.

  Les serveurs de fonts peuvent être spécifiés avec l'option -fontpath:

  Xdmx :1 -display d0:0 -display d1:0 -fontpath tcp/d0:7100 +xinerama

Exemples

les machines backend sont d0 et d1, core input vient des périphériques attachés à d0, les clients réfèrent à :1 en ouvrant les fenêtres
Xdmx :1 -display d0:0 -display d1:0 +xinerama
Idem, excepté que le core input vient de d1
Xdmx :1 -display d0:0 -display d1:0 -input d1:0 +xinerama
Idem, excepté avec core input depuis une fenêtre console sur l'affichage local
Xdmx :1 -display d0:0 -display d1:0 -input :0 +xinerama
Idem, excepté avec core input depuis le clavier et la souris locale
Xdmx :1 -display d0:0 -display d1:0 -input local,kbd,ps2 +xinerama
Utilise la configuration affiché dans la section précédente
Xdmx :1 -input :0 +xinerama -configfile filename -config example2
Avec cette ligne du fichier de configuration
option -input :0 +xinerama;
La ligne de commande peut être raccourci
Xdmx :1 -configfile filename -config example2
^
23 janvier 2014

htmlpdflatexmanmd




xdmxconfig

xdmxconfig

Outil de configuration graphique pour les fichiers de configuration Xdmx

   xdmxconfig lit, édite et écrits des fichiers de configuration pour le serveur xdmx. La grammaire pour la configuration est spécifiée dans xdmx. Pour démarrer from scratch, créer un "New Global" et spécifier le nom et les dimensions pour la configuration. Utiliser ensuite "New Display" pour entrer des affichages.

^
23 janvier 2014

htmlpdflatexmanmd




xdpyinfo

xdpyinfo

xdpyinfo affiche des informations sur un serveur X. Il est utilisé pour examiner les capacités du serveur, les valeurs prédéfinies pour divers paramètres, et les différents types d'écrans et visuels disponible.

OPTIONS

-display display Nom du serveur X à utiliser
-queryExtensions Affiche les extensions de protocole
-ext entension-name Affiche des informations détaillées sur une extension

Variables d'environnement

DISPLAY Le nom d'affichage associé
^
23 janvier 2014

htmlpdflatexmanmd




xdriinfo

xdriinfo

xdriinfo peut être utilisé pour requêter des informations des pilotes de rendu direct.

OPTIONS

-display display Nom du serveur X à utiliser
nscreens Affiche le nombre d'écrans
driver screen Affiche le nom du pilote de rendu direct pour l'écran spécifié
options screen|driver Affiche en XML les options de configuration du pilote spécifié

Variables d'environnement

DISPLAY Le nom d'affichage associé
^
01 janvier 2014

htmlpdflatexmanmd




xev

xev

Xev créé une fenêtre et demande au serveur X de lui envoyer les events qui se produisent sur cette fenêtre. On peut également attacher une fenêtre existante.

OPTIONS

-display display Nom du serveur X à utiliser
-geometry geom Spécifie la taille et la position de la fenêtre
-bw pixels Spécifie la lareur de bordure pour la fenêtre
-bs {NotUseful,WhenMapped,Always} Spécifie le genre de fond à donner à la fenêtre. Le backing store réfère aux pixels sauvé off-screen quand le serveur X maintient le contenu d'une fenêtre. NotUseful, le défaut, signifie que le process xev va redéssiner sont ontenu lui-même si nécessaire
-id id Spécifie la taille et la position de la fenêtre
-root Utilise la fenêtre root
-s Spécifie que le save-unders devrait être actif sur la fenêtre. similaire au backing strore, mais réfère aux pixels sauvé off-screen quand la fenêtre courante obscurci d'autres fenêtres.
-name string Spécifie le nom à assigner à la fenêtre créée
-rv Inverse le foreground et background
^
23 janvier 2014

htmlpdflatexmanmd




xhost

xhost

Programme de contrôle d'accès serveur pour X

   xhost est utilisé pour ajouter et supprimer des noms d'hôte et noms d'utilisateurs à la liste permise pour les connexions au serveur X. Dans le cas des hôtes, il fournis une forme rudimentaire de contrôle et de sécurité. C'est suffisant uniquement pour un environnement de station de travail (simple utilisateur). Sans argument, un message indique le contrôle d'accès est actif ou non.

OPTIONS

[+]name Ajoute le nom à la liste permise à se connecter au serveur X. Peut être un nom d'hôte ou un nom complet.
+ L'accès est donné à tout le monde, même s'ils ne sont pas dans la liste
L'accès est restreinte aux noms dans la liste

NOMS

   Un nom complet a la syntaxe family:name, où les familles sont:

        inet IPv4
        inet6 IPv6
        dnet Hôte DECnet
        nis Nom réseau RPC
        krb Principal Kerberos
        local Contient seulement un nom, la chaîne vide
        si Server Interpreted

   Le format des noms varie avec la famille. Pour Secure RPC, c'est le netname réseau (nis:unix.uid@domainname). La famille local spécifie toutes les connexions locales. Cependant, les adresses interprétées peuvent être utilisés pour spécifier un simple utilisateur (si:localuser:username)

  La liste de contrôle d'accès initiale pour l'affichage n peut être définis par le fichier /etc/Xn.hostsn est le numéro d'affichage du serveur.

Variables d'environnement

DISPLAY Numéro d'affichage et hôte par défaut
^
01 janvier 2014

htmlpdflatexmanmd




xinput

xinput

Utilitaire pour lister les périphériques d'entrée et changer les paramètres

OPTIONS

--list [--short || --long || --name-only || --id-only] [device] Sans argument, liste tous les périphériques d'entrée. Si un argument est donné, affiche toutes les fonctionnalité du périphérique.
--get-feedbacks device Affiche le feedback du périphérique
--set-mode device ABSOLUTE|RELATIVE Définit le mode du périphérique
--set-ptr-feedback device threshold num denom Change l'accélération de pointer du périphérique
--set-integer-feedback device index value Change la valeur d'un feedback entier du périphérique
--set-button-map device map_button_1 [map_button_2 [...]] Change le mappage des boutons
--query-state device Demande l'état du périphérique
--list-props device [device [...]] Liste les propriétés qui peuvent être définis
--set-prop [--type=atom|float|int] [--format=8|16|32] device property value [...] Définis une propriété à la valeur donnée
--watch-props device Affiche la propriété du périphérique
--test [-proximity] device Enregistre tous les events étendus du périphérique et entre dans une boucle affichant les évents reçus
--test-xi2 [device] Enregistre les events XI2 et les affiche
--create-master prefix [sendCore] [enable] Créé une nouvelle paire de péripéhrique maître su un server XI2 avec le préfix donné. Le serveur va créer un pointeur maître nommé "‹prefix› pointer" ou "‹prefix› keyboard". Si sendCore est 1, cette paire est définis pour envoyer les events core. Si enable vaut 1, cette paire sera activé immédiatement
--remove-master master [Floating|AttachToMaster] [returnPointer] [returnKeyboard] Supprime le master et ses paires. Les slaves attachés sotn flottant si Floatong est spécifié. Si AttachToMaster, returnPointer/returnKeboard spécifie le pointer master où attacher les slaves.
--reattach slave master Ré-attache slave à master
--float slave Supprime slave de son master
--set-cp window master Définis le ClientPointer pour le client propriétaire de la window au master (doit être un pointeur maître)
--map-to-output device crtc Restreins les mouvements du périphérique absolue au RandR crtc.
--enable device Active le périphérique (idem à xinput --set-prop device "Device Enabled" 1)
--disable device Désactive le périphérique (idem à xinput --set-prop device "Device Enabled" 0)
^
23 janvier 2014

htmlpdflatexmanmd




xkbbell

xkbbell

Utilitaire utilisateur de l'extension XKB - Bell

OPTIONS

-display display Nom du serveur X à utiliser
-synch Active la synchronisation
-dev ‹id› Spécifie quel périphérique utiliser
-force Force le bell audible
-nobeep Supprime le bell
-bf ‹id› Spécifie quel bell feedback utiliser
-kf ‹id› Spécifie quel keyboard feedback utiliser
-v ‹volume› Volume du bell
-w ‹id› Spécifie quelle fenêtre utiliser
^
01 janvier 2014

htmlpdflatexmanmd




xkbcomp

xkbcomp

Convertis une description d'un keymap XKB en un des nombreux formats.

   Il permet de créer un fichier keymap compilé (.xkm) qui peut être lu directement par un serveur X.

OPTIONS

-a Affiche toutes les informations de clavier. Affecte seulement le format xkb
-C Produit un fichier header C
-dflts Calcule les composants manquant
-l‹dir› Spécifie le répertoire de recherche des fichiers inclus par le keymap description (défaut: /usr/lib/X11/xkb)
-i deviceid si la source ou la destination est un affichage X valide, charge le keymap depuis/vers ce périphérique
-l Liste les maps qui spécifient le motif map dans tout fichier listé sur la ligne de commande
-m name Spécifie un map à compiler depuis un fichier à multiple entrées
-merge Fusionne les informations compilées avec la map du serveur
-o name Spécifie un nom pour le fichier créé
-opt parts Liste de parties optionnels
-R‹dir› Répertoire root pour les noms relatifs
-sync Force la synchronisation pour les requêtes X
-w lvl Contrôle le reporting des alertes durant la compilation (de 0 à 10)
-xkb Génère un fichier de description de clavier
-xkm Génère un fichier keymap compilé
^
23 janvier 2014

htmlpdflatexmanmd




xkbevd

xkbevd

Service d'évènements XKB

   xkbevd écoute les évènements XKB et exécute les commandes demandées. Le fichier de configuration consiste en une liste d'évènements en paire spécification/action et/ou définitions de variables.

OPTIONS

-cfg file Fichier de configuration à lire (défaut: ~/.xkb/xkbevd.cf ou $(LIBDIR)/xkb/xkbevd.cf)
-sc cmd Spécifie la commande à utiliser pour jouer les sons
-sd dir Répertoire pour les fichiers de son
-display display Nom du serveur X à utiliser
-bg Dit à xkbevd de se forker.
-synch Force la synchronisation de toutes les requêtes X (plus lent)
-v Affiche des informations supplémentaires. Peut être spécifié plusieurs fois
^
22 janvier 2014

htmlpdflatexmanmd




xkbvleds

xkbvleds

Utilitaire utilisateur pour l'extension XKB. Il permet d'afficher l'état des leds d'un clavier XKB.

OPTIONS

-indpy ‹name› Masque des leds à regarger
-watch ‹leds› Active la synchronisation
[-|+]automatic Regarde les LEDs automatiques
[-|+]explicit Regarde les LEDs explicites
[-|+]name Regarde les LEDs nommées
[-|+]real Regarde les vrai LEDs
[-|+]virtual Regards les LEDs virtuelles
-intersection Regarde seulement les LED dans le jeu désiré
-union Regarde les LEDs dans tous les jeux désirés
^
23 janvier 2014

htmlpdflatexmanmd




xkbwatch

xkbwatch

Utilitaire utilisateur pour l'extension XKB - État clavier.

   Il permet d'afficher les changements dans les composants fondamentaux de l'état clavier XKB et l'état de compatibilité effective.

^
02 février 2014

htmlpdflatexmanmd




XKeyboard-config

XKeyboard-config

Fichiers de description de données XKB

   xkeyboard-config fournis les fichiers de description pour l'extension XKB. Les options de configuration décrite ici sont généralement appliquées avec setxkbmap.

  La manière la plus simple pour spécifier un mappage clavier est d'utiliser le composant rules, qui décris des règles générales pour combiner toutes les pièces en un mappage clavier complet. Les paramètres sont:

        XkbRules Fichier de règles à utiliser pour la composition du mappage clavier
        XkbModel Nom du modème du clavier
        XkbLayout Layout à utiliser
        XkbVariant Variante du LayOut à utiliser
        XkbOptions Options supplémentaires

   Le fichier de règles utilisé dépend de votre système. Les règles communément utilisés sont fournis par le projet xkeyboard-config. Pour chaque fichier de règle, un fichier de description nommé ‹vendor-rules›.lst est dans le même répertoire rules.

Configuration basique


       
Section "InputClass"
    Identifier "keyboard defaults"
    MatchIsKeyboard "on"
    
    Option "XkbModel" "pc104"
    Option "XkbLayout" "us"
    Option "XKbOptions" ""
EndSection
    
est équivalent à
setxkbmap -model pc104 -layout us -option ""

   Si l'on veut rajouter la séquence Ctrl+Alt+Backspace pour terminer le serveur X, on peut rajouter:

Configuration basique


       
Section "InputClass"
    Identifier "keyboard defaults"
    MatchIsKeyboard "on"
    
    Option "XKbOptions" "terminate:ctrl_alt_bksp"
EndSection
    
qui est équivalent à:
setxkbmap -option "terminate:ctrl_alt_bksp"
    

Configuration avancée

   On peut utiliser la configuration xkb multi-layout. Celà permet de charger 4 layout différents en même temps. Chaque SubLayout réside dans son propre groupe. Il est possible de basculer d'un group à l'autre facilement en utilisant une combinaison de touches. Exemple, un clavier Logitech sans fil à utiliser en langue us, czech et german, et en basculant d'une disposition à l'autre en utilisant Alt+Shift:


       
Section "InputClass"
    Identifier "Logitech Cordless"
    MatchIsKeyboard "on"
    
    Option "XkbModel" "logicordless"
    Option "XkbLayout" "us,cz,de"
    Option "XKbOptions" "grp:alt_shift_toggle"
EndSection
    
qui est équivalent à:
setxkbmap -model logicordless -layout "us,cz,de" -option "grp:alt_shift_toggle"
    

^
23 janvier 2014

htmlpdflatexmanmd




xkill

xkill

Xkill force le serveur X à fermer les connexions au clients.

OPTIONS

-display display Nom du serveur X à utiliser
-id id Spécifie la fenêtre cible
-button number Spécifie le numéro de bouton de pointeur à utiliser pour sélectionner une fenêtre à tuer, ou 'any'.
-all Termine tous les clients avec des fenêtre top-level sur l'écran
-frame Ignore les conventions standard pour trouver les fenêtre top-level
^
23 janvier 2014

htmlpdflatexmanmd




xlsatoms

xlsatoms

Liste les atoms internes définis sur le serveur Par défaut, ils commencent à 1.

OPTIONS

-display display Nom du serveur X à utiliser
-format string Chaîne style printf à utiliser pour lister chaque pair d'atom (défaut: %ld\t%s)
-range [low]-[high] Spécifie la plage de valeur d'atom à vérifier
-name string Nom d'un atom à lister

Variables d'environnement

DISPLAY Numéro d'affichage et hôte par défaut
^
23 janvier 2014

htmlpdflatexmanmd




xlsclients

xlsclients

Liste les applications clients qui tournent dans un affichage. Il peut être utilisé pour générer un script représentant un snapshot de la session courante de l'utilisateur

OPTIONS

-display display Nom du serveur X à utiliser
-a Liste tous les clients sur tous les écrans
-l Liste au format long: nom de fenêtre, nom de l'icône, classe, nom de la machine et commande
-m maxcmdlen Spécifie le nombre maximum de caractères dans une commande à afficher (défaut: 10000)

Variables d'environnement

DISPLAY Numéro d'affichage et hôte par défaut
^
22 janvier 2014

htmlpdflatexmanmd




xmark

xmark

Sommarise les résultats x11perf

   Script shell qui lit le fichier indiqué et affiche le résultat. Il écrit 3 nombres:

  un poid de performance pour les résultat x11perf

  un point de performance pour un standard SparcStation 1

  Le Xmark, qui est un ratio des 2 nombres précédent.

Exemples

Le fichier de données doit être produit de cette manière
x11perf -display display -v1.3 -rop GXcopy GXxor -all › datafile
Il est possible de lancer les tests GXcopy et GXxor séparémment, tant qu'il sont concaténés sur la même sortie
x11perf -display display -v1.3 -rop GXcopy -all › datafile
x11perf -display display -v1.3 -rop GXxor -all ›› datafile
ou
x11perf -display display -v1.3 -rop GXxor -all › datafile
x11perf -display display -v1.3 -rop GXcopy -all ›› datafile
^
16 février 2014

htmlpdflatexmanmd




xmessage

xmessage

Affichage de message dans une fenêtre X

   xmessage affiche une fenêtre contenant un message de la ligne de commande, d'un fichier, ou de l'entrée standard. Ce programme est typiquement utilisé par les scripts shell pour afficher des informations à l'utilisateur ou pour demander des informations.

OPTIONS

-buttons button,button,... Crée un ou plusieurs boutons. chaque bouton consiste d'un label optionnellement suivi une ',' et un code de sortie.
-default label Définis le bouton par défaut, utilisé en pressant la touche entrée.
-file filename Fichier à afficher. '-' lit l'entrée standard.
-print Affiche le label du bouton pressé sur la sortie standard.
-center Affiche la fenêtre au milieu de l'écran
-nearmouse Affiche la fenêtre près de la souris
-timeout secs Quitte avec de status 0 après secs secondes.

Hiérarchie de Widget

Connaître le nom et la position dans la hiérarchie de chaque widget est utile pour spécifier les ressources pour eux:
Xmessage (xmessage)
        Form form
                Text message
                Command (label1)
                Command (label2)
                .
                .
                .

Resources

file Une chaîne spécifiant le fichier à afficher
buttons Une chaîne spécifiant le bouton à afficher
defauleButton Un chaîne spécifiant le bouton par défaut
printValue (Bool) Spécifie si le label du bouton pressé est affiché sur la sortie standard.
center (Bool) Spécifie si la fenêtre doit être centré à l'écran
nearMouse (Bool) Spécifie si la fenêtre doit s'afficher près de la souris
timeout Nombre de secondes après lesquels quitter avec le code de sortie 0
maxHeight (class Maximum) Hauteur maximum de la partie texte de la fenêtre en pixels, utilisé si aucune taille de géométrie n'a été spécifiée
maxWidth (class Maximum) Largeur maximum de la partie texte de la fenêtre en pixels, utilisé si aucune taille de géométrie n'a été spécifiée

Actions

exit(value) quitte immédiatement avec le code de sortie spécifié
default-exit() quitte immédiatement avec le code de sortie du bouton par défaut
^
25 janvier 2014

htmlpdflatexmanmd




xmodmap

xmodmap

Utilitaire pour modifier les keymaps et mappages de bouton de pointeur dans X

OPTIONS

-display display Nom du serveur X à utiliser
-grammar Affiche la grammaire des expressions utilisé avec -e
-verbose Augmente les messages en sortie
-quiet N'affiche pas les logs
-n  Indique qui xmodmap ne devrait pas changer les mappings.
-e expression Expression à exécuter. Peut être spécifié plusieurs fois
-pm Affiche le modifier map courant
-pk Affiche la table keymap
-pke Affiche le table keymap sous la forme d'expressions qui peuvent être envoyés à xmodmap
-pp Affiche le pointer map
Utilise l'entrée standard comme fichier d'entrée

Grammaire des expressions

   xmodmap lit une liste d'expressions et tente de les exécuter. Celà permet de référer à des keysym qui ont été redéfinis de manière naturelle san s'occuper des conflits de nom. La liste des noms de keysym peut être trouvé dans le fichier ‹X11/keysymdef.h›, plus la base de keysym /usr/share/X11/XKeysymDB/. les keysyms qui matchent des caractères unicodes peuvent être spécifiés par "U0020" à "U°°7E" et "U00A0" à "U10FFFF"

keycode NUMBER = KEYSYMNAME ... La liste des keysyms est assigné au keycode indiqué (en décimal,hex, octal et peut être déterminé avec xev). Jusqu'à 8 keysyms peuvent être attachés à une touche, cependant les 4 derniers ne sont pas utilisés par la plupart des serveurs X. Le premier keysym est utilisé sans modificateur, Le second avec Shift, le troisième avec Mode_Switch, et le quatrième avec Mode_Switch est Shift.
keycode any = KEYSYMNAME ... Si aucune touche existante n'a la liste de keysym spécifiée, une touche spare sur le clavier est sélectionnée et les keysyms lui sont associé.
keysym KEYSYMNAME = KEYSYMNAME ... Le KEYSYMNAME à gauche est traduite en keycode correspondant utilisé pour faire le jeu d'expression keycode correspondant.
clear MODIFIERNAME Supprime toutes les entrées pour le modifier donné, où les noms valide sont: Shift, Lock, Control, Mod1, Mod2, Mod3, Mod4, et Mod5. ex: "clear Lock" supprime toutes les touches liées au modifieur shift lock.
add MODIFIERNAME = KEYSYMNAME ... Ajoute toutes les clés contenant les keysyms donnés au modifier map indiqué.
remove MODIFIERNAME = KEYSYMNAME ... Supprime toutes les clés contenant les keysyms donnés au modifier map indiqué.
pointer = default Définis le mappage du pointeur à ses valeurs par défaut.
pointer = NUMBER ... Définis le mappage du pointeur pour contenir les codes de bouton indiqué.

Exemples

Définis les boutons de la souris pour un gaucher:
xmodmap -e "pointer = 3 2 1"
De nombreuses applications supportent la notion de Meta keys (similaire aux touches Control excepté que Meta est maintenu enfoncé). Cependant, certains serveurs n'ont pas de keysym Meta dans la table de mappage par défaut. La commande suivante attache Meta à la touche Multi-language (parfois appelé le caractère Compose).
% xmodmap -e "keysym Multi_key = Multi_key Meta_L"
Similairement, certains clavier ont une touche ALT, mais pas de touche Meta. Dans ce cas
xmodmap -e "keysym Alt_L = Meta_L Alt_L"
Définir la touche "rubout" du clavier pour générer un keysym alternatif. Généralement implique d'échange Backspace avec Delete pour plus de confort. Is la ressource ttyModes est définie, tous les émulateur de terminal vont utiliser la même touche pour le caractère Erase.
% xmodmap -e "keysym BackSpace = Delete"
% echo "XTerm*ttyModes: erase ^?" | xrdb -merge
Certains claviers ne génèrent pas automatiquement les caractères supérieur à et inférieur à quand les touches comma et period sont shiftés. On peut y remédier avec
keysym comma = comma less
keysym period = period greater
Inverser les touches Shift Lock et Control
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
Assigner le même keysym à plusieurs keycodes. Définis BackSpace pour générer Delete, vide les liens caps lock existants, défini CapsLock en touche Control, définis F5 en Escape, et définis Break/Reset en Shift Lock
keycode 101 = Delete
keycode 55 = Control_R
clear Lock
add Control = Control_R
keycode 89 = Escape
keycode 15 = Caps_Lock
add Lock = Caps_Lock
^
19 janvier 2015

htmlpdflatexmanmd




xnbd-bgctl

xnbd-bgctl

Permet de se connecter au canal de contrôle d'un serveur xnbd-server et de le piloter.

OPTIONS

--cache-all Si le serveur distant agit comme proxy, l'instruit de cacher tous les blocks et ses blocks disques associés. Une fois terminé, l'instance maintient toutes les données depuis l'instances originale, et il n'est plus nécessaire d'agir comme proxy.
--cache-all2 Idem, mais détache le processus du terminal et utilise une connexion dédiée pour le transfert de données.
--query Récupère des données statistiques de l'instance proxy.
--reconnect Récupère une connexion perdue avec le serveur originale.
--switch Stop le proxy et le redémarre en mode target. toutes les sessions client sont préservés
--exportname NAME Si le serveur supporte l'accès aux périphériques par identifiant, utilise NAME pour demander l'accès à un volume particulier. Utile avec xnbd-wrapper.
--progress Affiche une barre de progression sur stderr.
--force Ignore les risques.

Arguments positionnels

CONTROL_SOCKET Socket UNIX sur lequel xnbd-server écoute.
^
19 janvier 2015

htmlpdflatexmanmd




xnbd-register

xnbd-register

Restaure les sessions xNBD au boot basés sur un fichier de configuration.

OPTIONS

--start Démarre les périphériques configurés dans les fichiers de configuration.
--status Récupère le statut de wrapper depuis une commande xnbd-wrapper en cours de fonctionnement.
--stop Stop toutes les connexions xnbd.
--restart Relance les instances xnbd.
--config FILE Emplacement du fichier de configuration. Défaut: /etc/xnbd.conf
--quiet mode silencieux

Fichiers

/etc/xnbd.conf Fichier de configuration pour xnbd-register.
^
19 janvier 2015

htmlpdflatexmanmd




xnbd-server

xnbd-server

Dessert un périphérique block à d'autre machines via le protocole NBD

Description

   xnbd-server est un service NBD. Il exporte un fichier image aux clients nbd sur le réseau. Un client peut accéder au fichier exporté viar une interface block-level I/O; il est possible de créer des aires de swap dessus ou de créer des systèmes de fichier.

   xNBD offre des avantages supplémentaires par rapport à l'implémentation NBD originale. xNBD offre de meilleurs performances, supporte le copy-on-write (distribué), les snapshots, migration à chaud pour les machines virtuelles, et l'IPv6.

xnbd-server peut opérer en 3 modes: le mode target, le mode target copy-on-write, et le mode proxy.
xnbd-server --target exporte des images disques aux clients
xnbd-server --cow-target exporte des images disque de base aux clients. Les opérations d'écriture ne sont pas envoyés sur le disque de base, mais dans un fichier séparé, qui est supprimé à la déconnexion du client.
xnbd-server --proxy agit comme proxy pour un serveur xnbd-server distant. Le serveur proxy reçoit les requêtes de lecture/écriture les clients comme un serveur d'image fait normalement, mais cache les blocks disque, et récupère les blocks depuis le serveur distant si nécessaire. Aucune opération d'écriture ne se produit sur le serveur distant. Il peut être utilisé pour accélérer les accès distants, partages une image disque lecture-seule, et répliquer une image exportée à un autre nœud de manière transparente. Il fonctionne également pour la migration à chaud.

   Attention: plusieurs clients peut accéder simultanément à une seule instance du serveur. xnbd-server n'offre pas de mécanisme de lock ou de synchronisation. Dans ces cas, vous devez utiliser un système de fichier clusterisé dans les images disque exportés pour éviter tout dommage à vos données.

OPTIONS

--daemonize Lance le service en tâche de fond
--inetd Lance le service via inetd
--logpath FILE Log les messages dans le fichier au lieu de stderr/syslog
--syslog Log les messages dans syslog
--lport PORT Écoute les connexions entrante sur le port donné. Défaut: 8520.
--readonly Export le fichier image en lecture seule. Si une opération d'écriture est reçu du client, il est déconnecté. Si utilisé en mode proxy, xnbd-server rejète les requêtes d'écriture.
--connected-fd NUMBER Utilise le descripteur de fichier NUMBER comme canal bi-directionnel, pré-négocié pour un simple client. Utilisé avec xnbd-wrapper à l'invocation de xnbd-server, en interne.

Options du mode proxy

--target-exportname NAME Définis le nom de l'export pour requêter puis une cible xnbd-wrapper
--clear-bitmap Efface le fichier bitmat existant. Par défaut, l'état précédent est ré-utilisé
--max-queue-size NUMBER Limite le nombre total de requêtes en file d'attente. Si ce nombre est atteins, le serveur retarde la reception des nouvelles requêtes. Défaut: 0 (pas le limitation)
--max-buf-size NUMBER Limite l'utilisation du tampon interne à approximativement NUMBER octets. Si cette limite est atteinte, le serveur retarde les nouvelles requêtes. Défaut: 0 (pas le limitation)

Signaux

SIGUSR1 Prend un snapshot du fichier image. Seulement en mode target
SIGUSR2 Change le mode proxy en mode target. Utiliser xnbd-bgctl --switch au lieu d'utiliser ce signal.
^
19 janvier 2015

htmlpdflatexmanmd




xnbd-wrapper

xnbd-wrapper

Gère plusieurs fichiers à exporter comme périphérique block à d'autre machines.

Description

   xnbd-wrapper est un super-serveur pour xnbd-server. Son but est de gérer plusieurs images exportés en une fois. Un client peut se connecter à ce super-serveur et il sera redirigé vers le serveur xnbd fournissant la ressource demandée.

   xnbd-wrapper est utile si vous désirez exporter plusieurs fichiers ou périphériques block sur un hôte. Au lieu de démarrer plusieurs instances de xnbd-server et de se rappeler des ports exportés pour chacun, xnbd-wrapper recherche le fichier automatiquement et le mappe au serveur correspondant.

OPTIONS

--daemonize Lance le service en tâche de fond
--imgfile IMAGE Export le fichier image via xnbd-wraper. Peut être spécifié plusieurs fois
--laddr ADDRESS L'adresse d'écoute du wrapper.
--logpath FILE Log les messages dans le fichier au lieu de stderr/syslog
--syslog Log les messages dans syslog
--lport PORT Écoute les connexions entrante sur le port donné. Défaut: 8520.
--socket PATH le wrapper peut être contrôlé via un socket de contrôle. Défaut: /var/run/xnbd-wrapper.ctl
--xnbd-bgctl COMMAND Spécifie le chemin de l'exécutable xnbd-bgctl. La commande peut être un nom de fichier ou une commande pour résoudre le nom du fichier.
--xnbd-server COMMAND Spécifie le chemin de l'exécutable xnbd-server.
--cow Invoque xnbd-server --cow-target
--readonly invoke xnbd-server --readonly
--max-queue-size NUMBER Paramètre transféré au mode proxy à l'invocation
--max-buf-size Paramètre transféré au mode proxy à l'invocation
^
19 janvier 2015

htmlpdflatexmanmd




xnbd-wrapper-ctl

xnbd-wrapper-ctl

Permet de se connecter au canal de contrôle de xnbd-wrapper et de le piloter.

OPTIONS

--add-target FILE instruit xnbd-wrapper d'ajouter le fichier donné comme périphérique exporté.
--add-proxy TARGET_HOST TARGET_PORT CACHE_IMAGE BITMAP_IMAGE CONTROL_SOCKET_PATH instruit xnbd-wrapper d'ajouter un proxy au serveur cible donné
--list|-l Liste les noms de fichier exportés
--remove-by-file FILE instruit xnbd-wrapper de supprimer le volume exporté comme fichier de la liste des périphériques exportés.
--remove-by-exportname NAME instruit xnbd-wrapper de supprimer le volume exporté comme nom de la liste des périphériques exportés.
--socket|-s SOCKETPATH Se connecte au socket. Défaut: /var/run/xnbd-wrapper.ctl
--target-exportname NAME Définis le nom de l'export de requête depuis la cible xnbd-wrapper proxifié. Utilisé seulement avec --add-proxy et --bgctl-reconnect
--bgctl-cache-all
--bgctl-query
--bgctl-reconnect REMOTE_HOST REMOTE_PORT
--bgctl-switch Voir xnbd-bgctl pour les détails.

Arguments positionnels

FILE L'emplacement du fichier disque
LOCAL_EXPORTNAME Export le nom au procéssus xnbd-wrapper en cours de fonctionnement
REMOTE_HOST Hôte cible de connexion.
REMOTE_PORT Port TCP de connexion.
CACHE_IMAGE Emplacement du fichier disque (cache)
BITMAP_IMAGE Emplacement du fichier bitmap d'état du cache
CONTROL_SOCKET_PATH Socket UNIX sur lequel xnbd-server écoute.
^
19 janvier 2015

htmlpdflatexmanmd




xnbd.conf

xnbd.conf

Fichier de configuration pour xnbd-register

Description

   Ce fichier est une configuration semi-structurée, décrivant les connexions client/wrapper qui sont supposés être restorés au démarrage du système. La syntaxe de ce fichier est une structure de données JSON. 2 types d'objets sont reconnus: les volumes xnbd et une instance wrapper. les volumes xnbd sont indexés par le nom des périphériques supposé. C'est à dire, pour restaurer /dev/nbd° un objet nommé nbd0 doit être configuré. Les arguments valides sont les hôte, noms et port. Donc par exemple, pour configurer /dev/nbd0 en se connectant à localhost sur le port 8520. Si présent, identifie le périphérique partagé par le nom logique configuré:


"nbd0": {
    "host": "127.0.0.1",
    "port": 8520,
    "name": "name"
}

   Similairement, une instance wrapper configure un xnbd-wrapper. Les options valides sont:

address Adresse d'écoute
port Port d'écoute
socket socket pour les canaux de contrôle
logpath chemin pour la redirection des log
volumes Un mappage de volumes qui sont exportés. Les clés de mappage sont les noms d'export, les valeurs de mappage sont les chemin des images disque.


"wrapper": {
    "address": "127.0.0.1",
    "port": 8520,
    "socket": "/var/run/xnbd.ctl",
    "logpath": "/var/log/xnbd.log",
    "volumes": {
        "one": "/dev/volume",
        "two": "/dev/sdb1",
        "three": "/var/lib/image.file",
    }
}

^
23 janvier 2014

htmlpdflatexmanmd




xnest

xnest

xnest est à la fois un client et un serveur X. xnest est un client d'un vrai serveur X qui gère les requêtes de fenêtres et graphiques à la volée. xnest est un serveur de ses propre clients.

OPTIONS

-display display Nom du serveur X à utiliser
-sync Synchronise ses fenêtre et graphique avec le vrai serveur. Utile pour débugger.
-full Utilise la régénération complète des objets du vrai serveur et ré-ouvre une nouvelle connexion chaque fois que le serveur imbriqué est régénéré.
-class string Classe visuelle du serveur imbriqué. similaire à -cc du jeu d'options standard excepté qu'il accepte une chaîne au lieu d'un numéro. (StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, ou DirectColor).
-depth int Profondeur visuelle du serveur imbriqué. Doit être supporté par le vrai serveur.
-sss Utilise l'écran de veille logiciel. par défaut xnest utilise l'écran de veille qui correspond au hardware du vrai serveur.
-geometry WxH+X+Y Spécifie les paramètres de géométrie de la fenêtre top-level de xnest.
-bw int Largeur de la fenêtre top-level de xnest
-name string Nom de la fenêtre top-level de xnest
-scrns int Nombre d'écrans à créer dans le serveur xnest. Pour chaque écran, xnest créé une fenêtre top-level séparée. Chaque écran est référencé par le numéro avec le '.' dans le nom d'affichage (ex: xterm -display :1.1 ouvre xterm dans xnest avec l'affichage numéro :1 et sur le second écran)
-install xnest effectue sa propore installation de mappage de couleur en bypassant le vrai gestionnaire de fenêtre.
-parent window_id Dit à xnest d'utiliser windows_id comme fenêtre root au lieu de créer une fenêtre.
^
22 janvier 2014

htmlpdflatexmanmd




Xorg

Xorg

Xorg est un serveur X. Il supporte les connexions locales via socket UNIX et TCP/IP (ports 6000+n où n est le numéro d'affichage)

OPTIONS

Xserver Xorg supporte toutes les options normales de Xserver plus les options suivantes
vtXX XX spécifie le terminal virtuel à utiliser.
-allowMouseOpenFail Permet au serveur de démarrer même si le périphérique souris ne peut être ouvert.
-allowNonLocalXvidtune Permet l'extension VidMode aux clients distants. Permet aux clients xvidtune de se connecter à distance.
-bgamma value Définis la correction de gamma bleu (de 0.1 à 10)
-config file Fichier de configuration alternatif
-configure Permet de serveur de créer un xorg.conf initial basé sur ce qui a été détecté
-depth n Définis la profondeur de couleur par défaut (1, 4, 8, 15, 16 et 24)
-disableVidMode Désactive l'extension VidMode
-fbbpp n Nombre de framebuffer bitds per pixel. (1, 8, 16, 24, 32)
-flipPixels Swap les valeurs par défaut pour les pixels blanc et noir
-gamma value Niveau de correction gamma (entre 0.1 et 10) appliqué a R, G et B.
-ggamma value Définis la correction de gamma vert (de 0.1 à 10)
-ignoreABI Xorg ignore la vérification de version des modules qu'il charge
-isolateDevice bus-id Restreinds les resets de périphériques au bus-id (format: bustype:bus:device:function -( ex: PCI:1:0:0).
-keeptty Empêche le serveur de détacher son terminal initial
-keyboard keyboard-name Utilise la section InputDevice spécifié du xorg.conf
-layout layout-name Utilise la section layout spécifiée du xorg.conf
-logfile filename Fichier de log pour xorg. défaut: /usr/var/log/Xorg.n.log. uniquement si le serveur est root
-logverbose [n] Définis le niveau de verbosité dans le fichier de log.
-modulepath searchpath Liste de répertoire où rechercher les modules serveur. uniquement si le serveur est root
-nosilk Désactive le supporte Silken Mouse
-novtswitch Désactive le passage automatique au VT qui a lancé le serveur en cas de reset ou shutdown
-pixmap24 Format pixap à 24bits/pixel
-pixmap32 Format pixap à 32bits/pixel
-pointer pointer-name Utilise la section InputDevice donné dans xorg.conf comme core pointer. Ignoré quand le Layout spécifie un core pointer
-quiet Supprime les plupart des messages au démarrage
-rgamma value Définis la correction de gamma rouge (de 0.1 à 10)
-sharevts Partages les terminaux virtuels avec un autre serveur X
-screen screen-name Utilise la section Screen donné dans xorg.conf.
-showconfig Idem à -version
-showDefaultModulePath Affiche le chemin par défaut des modules
-showopts Pour chaque pilote installé, affiche la liste des options.
-weight nnn Définis le poid à 16bpp. défaut: 565
-verbos [n] Augmente les informations affichées sur stderr
-version Affiche les informations de version

Clavier

   Le serveur est normalement configuré pour reconnaître diverses combinaisons de touches qui instruise le serveur d'effectuer certaines actions. Ces actions dépendent du XKB keymap chargé pour un clavier particulier. Les combinaisons suivantes font généralement partie du XKB keymap par défaut.

Ctrl+Alt+Backspace Termine immédiatement le serveur (désactivé avec DontZap)
Ctrl+Alt+Keypad-Plus Passe au mode vidéo suivant dans la liste spécifiée dans xorg.conf (désactivé avec DontZoom)
Ctrl+Alt+Keypad-Minus Passe au mode vidéo précédent dans la liste spécifiée dans xorg.conf (désactivé avec DontZoom)
Ctrl+Alt+F1...F12 Passe des terminaux virtuels 1 à 12. (désactivé avec DontVTSwitch)

Configuration

   Xorg utilise le fichier de configuration xorg.conf et les fichiers de configuration avec le suffix .conf dans le répertoire xorg.conf.d pour son paramétrage initial. Xorga un mécanisme pour générer automatiquement une configuration quand aucun fichier de configuration n'est trouvé.

Fichiers

/etc/X11/xorg.conf Fichier de configuration de xorg
/etc/xorg.conf Fichier de configuration de xorg
/usr/etc/xorg.conf Fichier de configuration de xorg
/usr/lib/X11/xorg.conf Fichier de configuration de xorg
/etc/X11/xorg.conf.d répertoire de configuration de xorg
/etc/xorg.conf.d répertoire de configuration de xorg
/usr/etc/xorg.conf.d répertoire de configuration de xorg
/usr/lib/X11/xorg.conf.d répertoire de configuration de xorg
/usr/var/log/Xorg.n.log Fichier de log pour l'affichage n
/usr/share/fonts/X11/ Fonts
/usr/share/X11/XErrorDB Base de données des messages d'erreurs
/usr/lib/X11/app-defaults/ Spécifications de ressource clients
/etc/Xn.hosts ACL initial pour l'affichage n
^
30 janvier 2014

htmlpdflatexmanmd




xorg.conf

xorg.conf

Fichier de configuration pour Xorg

   Xorg supporte de nombreux mécanismes pour obtenir une configuration et des paramètres temps réels: la ligne de commandes, les variables d'environnement, les fichiers xorg.conf et xorg.conf.d et l'auto-détection. Quand la même information est fournie de plusieurs manières, un mécanisme de précédence est utilisé. Le fichier xorg.conf ou les fichiers *.conf dans le répertoire xorg.conf.d sont recherchés dans l'ordre (lancé sous un utilisateur normal):

        /etc/X11/‹cmdline›
        /usr/etc/X11/‹cmdline›
        /etc/X11/$XORGCONFIG
        /usr/etc/X11/$XORGCONFIG
        /etc/X11/xorg.conf
        /etc/xorg.conf
        /usr/etc/X11/xorg.conf.‹hostname›
        /usr/etc/X11/xorg.conf
        /usr/lib/X11/xorg.conf.‹hostname›
        /usr/lib/X11/xorg.conf

   où ‹cmdline› est un chemin relatif au chemin spécifié par -config ou $XORGCONFIG.

   Quand le serveur est lancé en root, le fichier de configuration est recherché dans cet ordre:

        ‹cmdline›
        /etc/X11/‹cmdline›
        /usr/etc/X11/‹cmdline›
        $XORGCONFIG
        /etc/X11/$XORGCONFIG
        /usr/etc/X11/$XORGCONFIG
        /etc/X11/xorg.conf
        /etc/xorg.conf
        /usr/etc/X11/xorg.conf.‹hostname›
        /usr/etc/X11/xorg.conf
        /usr/lib/X11/xorg.conf.‹hostname›
        /usr/lib/X11/xorg.conf

   Des fichiers de configuration additionnels sont recherchés dans les répertoires suivants quand le serveur est lancé sous un utilisateur normal:

        /etc/X11/‹cmdline›
        /usr/etc/X11/‹cmdline›
        /etc/X11/xorg.conf.d
        /usr/etc/X11/xorg.conf.d

   Finalement, les fichiers de configuration sont également recherchés dans les répertoires réservés au système:

        /usr/share/X11/xorg.conf.d
        /usr/share/X11/xorg.conf.d

Structure du fichier

   Les fichiers de configuration sont composés de sections qui peuvent être présenté dans n'importe quel ordre, ou omis pour utiliser la configuration par défaut. Chaque section a la forme:

        Section "SectionName"
        SectionEntry
        ...
        EndSection

        Les noms de section sont:
        Files Chemins de fichier
        ServerFlags Flags serveur
        Module Chargement de module dynamiques
        Extensions Activation d'extensions
        InputDevice Description de prériphérique d'entrée
        InputClass Description de classe d'entrée
        Device Description de périphériques graphique
        VideoAdaptor Description d'adaptateur vidéo Xv
        Monitor Description de moniteur
        Modes Descriptions de modes vidéo
        Screen Configuration d'écran
        ServerLayout Couche générale
        DRI Configuration spécifique à DRI
        Vendor Configuration spécifique au vendeur

   Les sections ServerLayout sont les plus haut niveau, ils lient ensembles les entrées et sorties qui seront utilisés dans une session. Les périphériques d'entrées sont décris dans les sections InputDevice. les périphériques de sortie consistent de plusieurs composants et sont liés entre eux dans les sections Screen.

  Les mos clé du fichier de configuration sont insensible à la casse et les caractères "_" sont ignorés. Chaque entrée dans le fichier consiste d'un mot clé et d'un ou plusieurs arguments. les types d'arguments sont:

        Interger Un nombre entier en décimal, hexadécimal (0x) ou octal (0)
        Real Un nombre à virgule flottante
        String Une chaîne de caractère entre guillemets

   Un mot clé spécial Option peut être utilisé pour fournir des données libre aux divers composants du serveur. Il prend jusqu'à 2 arguments, le premier est le nom de l'option et le deuxième, sa valeur.

        Les entrées suivantes sont équivalentes
        Option "Accel" "Off"
        Option "NoAccel"
        Option "NoAccel" "On"
        Option "Accel" "false"
        Option "Accel" "no"

Section Files

   La section Files est utilisée pour spécifier certains chemins requis par le serveur. Certains de ces chemins peuvent aussi être définis depuis la ligne de commande. Les entrées qui peuvent apparaître dans cette section sont:

FontPath "path" Définis les chemins de recherche des fonts. Peut être spécifié plusieurs fois. Peut être des chemins absolus, des répertoires de catalogue ou un id de serveur de font.

        Répertoires de catalogue Peuvent être spécifié en utilisant le préfixe catalogue:. Le répertoire peut être remplis de liens pointant vers les vrai répertoire de font, en utilisant la syntaxe ‹identifier›:[attribute]:pri=‹priority› où identifier est un id alphanumerique, attribute est passé au FPE et priority est le numéro utilisé pour l'ordre des fonts FPE. (ex:

                75dpi:unscaled:pri=20 -› /usr/share/X11/fonts/75dpi
                gscript:pri=60 -› /usr/share/fonts/default/ghostscript
                misc:unscaled:pri=10 −› /usr/share/X11/fonts/misc

        Identifiants de serveur de fonts A la forme ‹trans›/‹hostname›:‹port−number›, où trans est le type de transport.

ModulePath "path" Définis les chemins de recherche pour les modules du serveur. Peut être spécifié plusieur fois. (défaut: /usr/lib/xorg/modules)
XkbDir "path" Définis le répertoire de base pour les fichiers layout de clavier. (défaut: /usr/share/X11/xkb)

Section ServerFlags

   ServerFlags est utilisé pour spécifier certains options gloçbales à Xorg. Toutes les entrées dans cette section sont des Options. Les options spécifiées dans cette section, à l'exceptionde l'option DefaultServerLayout peuvent être écrasés par les Options dans la section ServerLayout active.

        Option "DefaultServerLayout" "layout-id" Spécifie la section Layout à utiliser par défaut
        Option "NoTrapSignals" "boolean" Empêche Xorg de récupérer des signaux fatals inatendus et de quitter proprement.
        Option "UseSIGIO" "boolean" Contrôle si Xorg demande que les évents depuis les périphériques d'entrée soient reportés via un signal SIGIO (aussi connu comme SIGPOLL), ou seulement reporté via la boucle select(3) standard.
        Option "DontVTSwitch" "boolean" Désactive l'utilisation des séquences Ctrl+Alt+Fn
        Option "DontZap" "boolean" Désactive l'utilisation de l'action XKB Terminate_Server (généralement Ctrl+Alt+Backspace)
        Option "DontZoom" "boolean" Désactive l'utilisation des séquences Ctrl+Alt+Keypad-Plus et Ctrl+Alt+Keypad-Minus pour contrôler les modes vidéo
        Option "DisableVidModeExtension" "boolean" Désactive les parties de l'extension VidMode utilisés par le client xvidtune qui peut être utilisé pour changer les modes vidéo.
        Option "AllowNonLocalXvidtune" "boolean" Permet aux client xvidtune (et autres clients qui utilise l'extension VidMode) à se connecter depuis un hôte distant.
        Option "AllowMouseOpenFail" "boolean" Dit aux pilotes mousedrv et vmmouse de ne pas reporter d'erreur si la souris ne peut pas être ouverte/initialisée. N'a pas d'effet sur evdev.
        Option "BlankTime" "time" Définis le temps d'inactivité de la phase blank de l'écran de veille. le temps est en minute. défaut: 10minutes
        Option "StandbyTime" "time" Définis le temps d'inactivité pour la phase standby du mode DPMS. time est en minutes. Défaut: 10minutes.
        Option "SuspendTime" "time" Définis le temps d'inactivité pour la phase suspend du mode DPMS. time est en minute défaut: 10minutes
        Option "OffTime" "time" Définis le temps d'inactivité de la phase off du mode DPMS. time est en minute défaut: 10minutes
        Option "Pixmap" "bpp" Définis le format pixmap à utiliser pour la profondeur 24 (24 ou 32, défaut: 32)
        Option "NoPM" "boolean" Désactive le Power Management.
        Option "Xinerama" "boolean" Active l'extension Xinerama (défaut: False)
        Option "AIGLX" "boolean" Active l'extension AIGLX (défaut: True)
        Option "DRI2" "boolean" Active l'extension DRI2 (défaut: True)
        Option "GlxVisuals" "string" Contrôle le nombre de visuels GLX définir. (typical, minimal, all - défaut: typical)
        Option "UseDefaultFontPath" "boolean" Inclus les chemins par défaut des paths de fonts.
        Option "IgnoreABI" "boolean" Autorise les modules construits pour une version différente et potentiellement incompatible du serveur X.
        Option "AutoAddDevices" "boolean" à False, aucun périphérique ne sera ajouté depuis le backend HAL ou udev.
        Option "AutoEnableDevices" "boolean" Désactivé, les périphériques seront ajoutés, mais non activés.
        Option "Log" "string" Contrôle si le log est vidé et/ou synchronisé sur disque après chaque message. (flush ou sync)

Section Module

   le module Section est utilisé pour psécifier quels modules serveur doivent être chargés. Cette section est ignorée quand le serveur est construit en static. La plupart des modules sont chargés automatiquement quand ils sont nécessaires. Cette section est optionnelle. Les entrées dans cette section peut avoir 2 formes.:

        Load "modulename" Dit au serveur de charger le module. Doit être le nom standard du module, pas son nom de fichier. le nom est sensible à la casse et ne doit pas inclure le préfixe "lib" ou le suffix ".a", ".o", ou ".so" ex: Load "dri"
        Disable "modulename" Dit au serveur de ne pas charger le module. le mot clé Load a la précédence.

   La seconde forme est une SubSection dont le nom de la subsection est le nom du module. Le contenu de la subsection sont des Options à passer au module.

  Les modules d'extension "extmod", "dbe", "dri", "dri2", "glx" et "record" sont chargé automatiquement par défaut.

Section Extensions

   La section Extensions est utilisé pour spécifier ques extensions de protocole X11 doivent être activés ou non. Cette section est optionnelle. Les entrées dans cette section sont des Options avec le nom de l'extensions comme premier argument, et une valeur booléennes en deuxième. Le nom de l'extension est sensible à la casse, et correspond à la forme affichée par la sortie de Xorg -extension ?

  Exemple:

        Section "Extensions"
        Option "MIT-SHM" "Disable"
        EndSection

Section InputDevice

   Le fichier de configuration peut avoir plusieurs sections InputDevice. Les serveurs réçent utilisent HAL ou udev pour l'énumération des périphériques d'entrée. Il n'est pas nécessaire de fournie de sections InputDevice. Si le hotplugging est utilisé, les sections InputDevice utilisant les pilotes mouse, kbd et vmmouse seront ignorés. Si le hotplugging est désactivé, il y'a normalement au moins 2 sections InputDevice, un pour le clavier et un pour la souris. Si les 2 sont manquant, une configuration par défaut est utilisée. En l'absence de périphérique d'entrée core spécifié, le premier InputDevice marqué CorePointer ou CoreKeyboard est utilisé. Si rien ne correspond, le premier InputDevice qui utilise le driver mouse ou kbd est utilisé. Les sections InputDevice ont la forme suivante:

        Section "InputDevice"
        Identifier "name"
        Driver "inputdriver"
        options
        ...
        EndSection

   Les entrées Identifier et Driver sont requis dans toutes les sections InputDevice. Toutes les autres entrées sont optionnelles.Identifier spécifie le nom unique du périphérique d'entrée. Driver spécifie le nom du pilote à charger pour ce périphérique. Une section InputDevice est considérée active si elle est référencée par une section ServerLayout active, s'il est référencé par les options de ligne de commande -keyboard ou -pointer, ou s'il est sélectionné implicitement coomme core pointer ou core keyboard en l'absence de référence explicite. Le pilote le plus courant est evdev. Les sections InputDevice reconnaît certaines options indépendante du driver, qui sont décris ici.

        Option "AutoServerLayout" "boolean" Ajoute toujours le périphérique à la section ServerLayout utilisé par cette instance de ce serveur.
        Option "Floating" "boolean" Activé, le périphérique d'entrée est définis comme flottant et ne reporte pas d'évent au périphérique maître. Le périphérique est seulement disponible en utliisant X Input Extension. Inverse le sens des options dépréciées CorePointer, CoreKeyboard, AlwaysCore, et SendCoreEvents
        Option "TransformationMatrix" "a b c d e f g h i" Spécifie la matrice de transformation 3x3 pour les périphériques d'entrées absolus. Le périphérique sera lié à la zone donnée dans la matrice. Dans la plupart des cas, a et e spécifient la largeur et la hauteur de la zone, et c et f spécifie l'offset x et y de la zone. la plage de valeur va de 0 à 1, où 1 représente la largeur et la hauteur de la fenêtre root.
        Option "AccelerationProfile" "integer" Sélectionne le profil d'accélération:

                0 Le plus compatible
                -1 Seul une décélération est appliquée
                1 Dépendant du périphérique
                2 Fonction polynamiale
                3 Pente douce, puis linaire
                4 Simple, normal quand lent, sinon accélère
                5 Fonction power
                6 Linéaire, plus de vitesse = plus d'accélération
                7 Limité. comme linéaire, mais plus de seuil

        Option "ConstantDeceleration" "real" Ralentis le temps de décélération. Plus utile pour les périphériques haute résolution
        Option "AdaptiveDeceleration" "real" Séléctionne le schéma (predictable, lightweight, none)
        Option "AccelerationNumerator" "integer"
        Option "AccelerationDenominator" "integer" Définis le numérateur et le dénominateur du facteur d'accélération. Le facteur d'accélération est un rationnel qui, ensemble avec le seuil, peuvent être utilisés pour personnaliser le profile. Les profiles simple et limited l'utilisent directement. typiquement, 1 n'a pas d'acélération, et › 5 est sensible.
        Option "AccelerationThreshold" "integer" Définis le seuil, qui est à peu près la vitesse (générallement en unité de périphérique par 10ms) requis pour que l'accélération devient effective.

Section InputClass

   Le fichier de configuration peut avoir plusieurs sections InputClass. Ces sections sont optionnelles et sont utilisés pour fournir une configuration pour une classe de périphériques d'entrée qui sont automatiquement ajoutés. Un périphérique d'entrée peut matcher plusieurs section InputClass. Chaque classe peut écraser les paramètres d'une classe précédente, donc le mieux est d'arranger les sections avec une liste de match généric. Les sections InputClass ont le format suivant:

        Section "InputClass"
        Identifier "name"
        entries
        ...
        options
        ...
        EndSection

           Identifier spécifie le nom unique de la classe. Driver spécifie le nom du pilote à utiliser pour ce périphérique d'entrée. Quand un périphérique est ajouté automatiquement, ses caractéristiques sont vérifiés avec les sections InputClass. Chaque section peut contenir des entrées additionnelles pour cibler la correspondance de la classe. Il y'a 2 types d'entrées de correspondance. La première permet divers jetons à matcher les attributs du périphérique. Une entrée peut être construite pour matcher des attributs de différents périphériques en séparant les arguments avec un caractère "|". Plusieurs entrées peuvent être fournies pour ajouter plusieurs conditions de correspondance sur le même attribut. par exemple:

                Section "InputClass"
                Identifier "My Class"
                MatchProduct "example"
                MatchProduct "gizmo|gadget"
                ...
                EndSection

        MatchProduct "matchproduct" Match le product name
        MatchVendor "matchvendor" Match le vendor name
        MatchDevicePath "matchdevice" Matche le fichier du périphérique
        MatchOS "matchos" Vérifie l'OS fournis par uname(2)
        MatchPnPID "matchpnp" ID Plug and Play du périphérique
        MatchUSBID "matchusb" ID USB du périphérique fournis par lsusb
        MatchDriver "matchdriver" Match le pilote du périphérique
        MatchTag "matchtag" Matche les tags
        MatchLayout "matchlayout" Match le ServerLayout actif

           Le second type d'entrée est utilisé pour matcher des type de périphériques:

                MatchIsKeyboard "bool"
                MatchIsPointer "bool"
                MatchIsJoystick "bool"
                MatchIsTablet "bool"
                MatchIsTouchpad "bool"
                MatchIsTouchscreen "bool"

           Quand un périphérique d'entrée est matché avec une section InputClass, les entrées Option sont appliqués au périphérique. Voir InputDevice pour les entrées Option. Un entrée Option spécifique à la section InputClass est:

                Option "Ignore" "boolean" Spécifie que le périphérique devrait être ignoré entièrement, et non ajouté au serveur. Peut être utile quand le périphérique est géré par un autre programme.

Section Device

   Le fichier de configuration peut avoir plusieurs section Device.Il doit y'en avoir au moins une, pour la carte vidéo à utiliser. La section Device a le format suivant:

        Section "Device"
        Identifier "name"
        Driver "driver"
        entries
        ...
        EndSection

   Identifier spécifie le nom unique pour un périphérique graphique. Driver spécifie le nom du pilote à utiliser. Les sections Device reconnaissent les entrées indépendante du pilote et les entrées Options.

        BusID "bus-id" Spécifie l'emplacement du bus de la carte graphique. Pour les cartes PCI/AGP, bus-id a la forme PCI:bus:device:function (ex: PCI:1:0:0 peut être approprié pour une carte AGP). Ce champ dans une configuration single-head en utilisant la carte graphique principal. Dans les configurations multi-head, l'entrée est mandatoire. Son but premier est de créer des connexions non ambigües entre les sections device et le hardware qu'il représente. Cette information peut être trouvée par scanpci
        Screen number mandatoire pour les cartes une seule entité PCI peut piloter plus d'un affichage. Une section Device est requise pour chaque tête, et ce paramètre détermine à quelle tête la section Device s'applique.
        Chipset "chipset" Généralement optionnel, spécifie le chipset utilisé dans la carte graphique. Dans la plupart cette entrée n'est pas requise parce que les pilotes vont sonder les cartes pour déterminer le type de chipset.
        Ramdac "ramdac-type" Optionnel. Spécifie le type de RAMDAC utilisé sur la carte graphique. Utilisé par quelques pilotes.
        DacSpeed speed
        DacSpeed speed-8 speed-16 speed-24 speed-32 Optionnel. Spécifie la vitesse du RAMDAC en Mhz.
        Clocks clock ... Les horloges sont en MHz et peuvent être spécifié en virgule flottante. Peut être spécifié plusieurs fois.
        ClockChip "clockchip-type" Spécifie le type d'horloge sur les cartes graphiques qui ont un générateur d'horloge programmable.
        VideoRam mem Spécifie la quantité de mémoire vidéo sur la carte graphique
        BiosBase baseaddress Spécifie l'adresse de base du bios pour les cartes VGA.
        MemBase baseaddress Spécifie l'adresse de base mémoire d'un frame buffer linéraire d'une carte graphique.
        IOBase baseaddress Spécifie l'adresse de base d'entrée/sortie. Pour les cartes PCI, c'est généralement le device ID.
        ChipRev rev Numéro de révision du chipset
        TextClockFreq frep Fréquence d'horloge utilisé pour le mode texte régulier
        Option "ModeDebug" "boolean" Active l'affichage d'informations additionnels sur le serveur de logs.
        Options Permet de spécifier des paramètres spécifiques au pilote.

Section Monitor

   Le fichier de configuration peut avoir plusieurs sections Monitor. Il doit y'en avoir au moins une. La section Monitor a le format suivant:

        Section "Monitor"
        Identifier "name
        entries
        ...
        EndSection

   Identifier est mandatoire et spécifie le nom unique pour ce moniteur. Avec les pilotes RandR 1.2, les sections Monitor peuvent être liés à des sorties spécifiques de carte vidéo. En utilisant le nom de la sortie définies par le pilote vidéo et l'identifier d'une section monitor, on associe une section monitor avec une sortie en ajoutant un option à la section Device au format:

  Option "Monitor-outputname" "monitorsection"

  (ex: Option "Monitor-VGA" "VGA monitor" pour une sortie VGA). Spécifier les modes vidéo est optionnel parce que le serveur va utiliser DDC ou d'autres informations fournies par le moniteur pour configurer la liste des modes disponibles.

        VendorName "vendor" Spécifie le vendeur du moniteur
        ModelName "model" Spécifie le modèle du moniteur
        HorizSync horizsync−range Donne la plage de fréquences de synchronisation horizontal supportés par le moniteur
        VertRefresh vertrefresh−range Donne la plage de fréquences de rafraîchissement vertical supportés par le moniteur
        DisplaySize width height Donne la largeur et hauteur en du moniteur en mm.
        Gamma gamma-value
        Gamma red−gamma green−gamma blue−gamma Définis les corrections gamma pour le moniteur (valeurs de 0.1 à 10.0)
        UseModes "modesection-id" Inclus un jeu de modes listés dans la section Modes nommée modesection-id. Cela définis tous les modes disponibles pour ce moniteur
        Mode "name" Entrée multiligne qui peut être utilisée pour fournir des définitions pour les modes vidéo. la description du Mode se termine par EndMode Les entrées sont:

                DotClock clock dot clock rate
                HTimings hdisp hsyncstart hsyncend htotal Timing horizontal
                VTimings vdisp vsyncstart vsyncend vtotal Timing vertival
                Flags "flag" ... Jeu de flags optionnels:

                        Interface Indique que le mode est entrelacé
                        DoubleScan Indique un mode où chaque scanline est doublée
                        +HSync
                        -HSync Spécifient la polarité du signal HSync
                        +VSync
                        -VSync Spécifient la polarité du signal VSync
                        Composite Spécifie une synchronisation composite hardware.
                        +CSync
                        -CSync Sélectionne la polarité du composite

                HSkew hskew Nombre de pixels (vers le bord droit de l'écran), par lesquels l'affichage permet au signal d'être faussé
                VScan vscan Spécifie le nombre de fois que chaque scanline est repaint à l'écran.

        ModeLine "name" mode−description Version plus compacte de Mode. mode-description est en 4 sections (DotClock; "hdisp, hsyncstart, hsyncend, et htotal"; "vdisp, vsyncstart, vsyncend, et vtotal"; Flags)
        Option "DPMS" "bool" Détermine si le serveur doit activer l'extension DPMS pour cet écran
        Option "SyncOnGreen" "bool" Contrôle si la carte vidéo devrait piloter la synchro du signal sur le pin de couleur verte.
        Option "Primary" "bool" Spécifie que le moniteur devrait être traité comme moniteur primaire (RandR 1.2 uniquement)
        Option "PreferredMode" "name" Spécifie un mode inital préféré (RandR 1.2 uniquement)
        Option "Position" "x y" Spécifie la position du moniteur dans un écran X (RandR 1.2 uniquement)
        Option "LeftOf" "output" Spécifie que le moniteur devrait être positionné à gauche de la sortie donnée (RandR 1.2 uniquement)
        Option "RightOf" "output" Spécifie que le moniteur devrait être positionné à droite de la sortie donnée (RandR 1.2 uniquement)
        Option "Above" "output" Spécifie que le moniteur devrait être positionné au dessus de la sortie donnée (RandR 1.2 uniquement)
        Option "Below" "output" Spécifie que le moniteur devrait être positionné au dessous de la sortie donnée (RandR 1.2 uniquement)
        Option "Enable" "bool" Spécifie si le moniteur devrait être actif au lancement au démarrage. (RandR 1.2 uniquement)
        Option "DefaultModes" "bool" Spécifie si le serveur devrait supporter les modes par défaut de la liste de mode offert sur le moniteur (RandR 1.2 uniquement)
        Option "MinClock" "frequency" Spécifie le dot clock minimum en KHz
        Option "MaxClock" "frequency" Spécifie le dot clock maximum en KHz
        Option "Ignore" "bool" Spécifie que le moniteur devrait être ignoré (RandR 1.2 uniquement)
        Option "Rotate" "rotation" Spécifie la rotation initiale du moniteur (RandR 1.2 uniquement)

Section Modes

   Le fichier de configuration peut avoir plusieurs sections Modes. Ces sections fournissent une manière de définir des modes vidéo indépendamment des sections Monitor. Les entrées Mode et ModeLine sont décris dans la section Monitor. Les sections Modes ont le format suivant:

        Section "Modes"
        Identifier "name"
        entries
        ...
        EndSection

Section Screen

   Le fichier de configuration peut avoir plusieurs sections Screen, et doit y'en avoir au moins une. un "screen" représente la liaison d'une carte graphique (section Device) et un moniteur (section Monitor). Une section Screen est considérée active si elle est référencée par une section ServerLayout active ou par l'option -screen. Les sections Screen ont le format suivant:

        Section "Screen"
        Identifier "name"
        Device "devid"
        Monitor "monid"
                ...
        SubSection "Display"
        entries
        ...
        EndSubSection
        ...
        EndSection

   Identifier spécifie le nom unique pour ce screen et est mandatoire. Device est mandatoire.

        Device "device−id" Spécifie la section Device à utiliser pour ce screen
        Monitor "monitor−id" Spécifie une section Monitor à utiliser pour ce screen
        VideoAdaptor "xv−id" Spécifie un adaptateur video Xv optionnel à utiliser avec cet écran
        DefaultDepth depth Spécifie la profondeur de couleur. Généralement 8
        DefaultFbBpp bpp Spécifie quel couche framebuffer utiliser par défaut.
        Options Divers flags peuvent être spécifiés dans la section Screen.
        Option "Accel" Active XAA (X Acceleration Architecture), un mécanisme qui rend disponible l'accélération hardware 2D disponible au serveur X.
        Option "InitPrimary" "boolean" Utilise le module Int10 pour initialiser la carte graphique principal. Normalement seul les cartes secondaire sont démarré avec Int10.
        Option "NoInt10" "boolean" Désactive le module Int10, un module qui utilise le call int10 du bios de la carte graphique pour l'initialiser.
        Option "NoMTRR" Désactive le support MTRR (Memory Type Range Register), une fonctionnalité des processeurs modernes qui peuvent améliorer les performances vidéo.
        Option "XaaNoCPUToScreenColorExpandFill" Disables accelerated rectangular expansion blits from source patterns stored in system memory (using a memory−mapped aperture).
        Option "XaaNoColor8x8PatternFillRect" Disables accelerated fills of a rectangular region with a full−color pattern
        Option "XaaNoColor8x8PatternFillTrap" Disables accelerated fills of a trapezoidal region with a full−color pattern.
        Option "XaaNoDashedBresenhamLine" Disables accelerated dashed Bresenham line draws.
        Option "XaaNoDashedTwoPointLine" Disables accelerated dashed line draws between two arbitrary points.
        Option "XaaNoImageWriteRect" Disables accelerated transfers of full−color rectangular patterns from system memory to video memory (using a memory−mapped aperture).
        Option "XaaNoMono8x8PatternFillRect" Disables accelerated fills of a rectangular region with a monochrome pattern.
        Option "XaaNoMono8x8PatternFillTrap" Disables accelerated fills of a trapezoidal region with a monochrome pattern.
        Option "XaaNoOffscreenPixmaps" Disables accelerated draws into pixmaps stored in offscreen video memory.
        Option "XaaNoPixmapCache" Disables caching of patterns in offscreen video memory.
        Option "XaaNoScanlineCPUToScreenColorExpandFill" Disables accelerated rectangular expansion blits from source patterns stored in system memory (one scan line at a time).
        Option "XaaNoScanlineImageWriteRect" Disables accelerated transfers of full−color rectangular patterns from system memory to video memory (one scan line at a time).
        Option "XaaNoScreenToScreenColorExpandFill" Disables accelerated rectangular expansion blits from source patterns stored in offscreen video memory.
        Option "XaaNoScreenToScreenCopy" Disables accelerated copies of rectangular regions from one part of video memory to another part of video memory.
        Option "XaaNoSolidBresenhamLine" Disables accelerated solid Bresenham line draws.
        Option "XaaNoSolidFillRect" Disables accelerated solid−color fills of rectangles.
        Option "XaaNoSolidFillTrap" Disables accelerated solid−color fills of Bresenham trapezoids.
        Option "XaaNoSolidHorVertLine" Disables accelerated solid horizontal and vertical line draws.
        Option "XaaNoSolidTwoPointLine" Disables accelerated solid line draws between two arbitrary points.

   Chaque section Screen peut optionellement contenir une ou plusieurs sections Display qui fournissent des configuration depth/fbbpp et le choix dépend des paramètres spécifiés dans la section Screen. Le format de la sous section Display est décrite dans la section suivante.

Sous-section Display

   Chaque section Screen peut avoir plusieurs sous sections Display. La sous-section active est la première correspondance avec les valeurs depth/fbbpp ou la première qui n'a aucune de ces valeurs spécifiées. Display a leformat suivant:

        SubSection
        "Display"
        Depth depth
        entries
        ...
        EndSubSection

Depth depth Profondeur de couleur à utiliser (8, 15, 16 et 24)
FbBpp bpp Format du framebuffer utilisé. nécessaire uniquement en fournissant une profondeur de 24 bits (24 ou 32 bpp)
Weight red−weight green−weight blue−weight Poid relatif à utiliser pour un écran de profondeur 16bits.
Virtual xdim ydim Résolution de l'écran virtuel à utiliser
ViewPort x0 y0 Définis le coin supérieur gauche de l'affichage initial. utile quand la résolution de l'écran virtuel est différente de la résolution du mode vidéo initial.
Modes "mode−name" ... Liste de modes vidéo à utiliser. Chaque mode vidéo doit être entre guillemets.
Visual "visual−name" Définis le visuel par défaut. pour depht=8: StaticGray, GrayScale, StaticColor, PseudoColor (défaut), TrueColor , DirectColor; pour depth=15, 16 et 24: TrueColor (défaut), DirectColor.
Black red green blue Permet de spécifier la couleur noir. uniquement pour les profondeur 1. (défaut: black)
White red green blue Permet de spécifier la couleur blanc. uniquement pour les profondeur 1. (défaut: white)
Options Permet de spécifier des paramètres spécifiques ou non au pilote

Section ServerLayout

   Le fichier de configuration peut avoir plusieurs sections ServerLayout. un ServerLayout représente la liaison d'un ou plusieurs écrans (Screen) et un ou plusieurs périphériques (InputDevice) pour former une configuration complète. Dans les configurations multi-head, il spécifie également le layout relatif des heads. Une seule section ServerLayout peut être active. les sections ServerLayout ont le format suivant:

        Section "ServerLayout"
        Identifier "name"
        Screen "screen−id"
        ...
        InputDevice "idev−id"
        ...
        options
        ...
        EndSection

   Identifier spécifie le nom unique pour ce ServerLayout et est mandatoire. Au moins une entrée Screen est obligatoire

Screen screen−num "screen−id" position−information Pour chaque écran utilisé pour la session, l'id démarre de 0 et doivent être consécutifs. position-information peut être:

        Absolute x y Spécifie l'emplacement absolue de l'écran. x ety représente les coordonnées du coin supérieur gauche
        RightOf "screen−id"
        LeftOf "screen−id"
        Above "screen−id"
        Below "screen−id"
        Relative "screen−id" x y Spécifient l'emplacement relatifs de l'écran

InputDevice "idev−id" "option" ... Permet de spécifier les sections InputDevice à utiliser.
Options Permet d'ajouter les optionsde la sections ServerFlags
Option "IsolateDevice" "bus−id" Restrains les resets de périphériques au bus-id spécifié. uniquement pour les périphériques PCI.
Option "SingleCard" "boolean" Comme IsolateDevice, excèpté quie le busID du premier périphérique dans le layout est utilisé
^
01 janvier 2014

htmlpdflatexmanmd




xprop

xprop

Afficheur de propriété pour X. Affiche les propriétés d'affichage et de font dans un X server

OPTIONS

-grammar Affiche une grammaire détaillée pour toutes les options de ligne de commande
-id id Spécifie la fenêtre cible
-name Spécifie le nom sous lequel les ressources de l'application devraient être trouvés.
-root Utilise la fenêtre root
-font font Afficher les propriétés de la font
-display display Nom du serveur X à utiliser
-len n Spécifie qu'au moins n octets d'une propriété devrait être lu ou affichée
-notype Spécifie que le type de chaque propriété ne devrait pas être affiché
-fs file Spécifie que le fichier devrait être utilisé comme source de format pour les propriétés
-frame Spécifie qu'en spécifiant une fenêtre manuellement, regarde la frame de gestionnaire de fenêtre au lieu de rechercher la fenêtre client.
-remove property-name Spécifie le nom d'un propriété à supprimer de la fenêtre indiquée
-set property-name value Définit une propriété
-spy Surveille en permanence les propriétés de la fenêtre
-f name format [dformat] Spécifie que le format pour name devrait être format et que le dformat pour name devrait être dformat. Si dformat est manquant, utilise " = $0+\n"

DESCRIPTION

   Pour chacune de ces propriétés, ses valeurs sont affichés en utilisant les informations format fournis. Sinon, le format interne est utilisé. Une fenêtre peut être sélectionné de 4 manières. En utilisant -root, en utilisant sont id (obtenus avec xwininfo) ou par nom. Sans ces options, laisse sélectionner la fenêtre.

   Normallement chaque propriété en affichant son nom puis ses types entre parenthèse. Le format des informations pour une propriété consiste de 2 parties, un format et un dformat. Le format spécifie le formattage de la propriété et le dformat spécifie comment la propriété devrait être affichée.

   Un format consiste de 0, 8, 16 ou 32 suivi par une séquence d'un ou plusieurs caractères. La première valeur spécifie combien de bits par champs il y a dans la propriété. 0 utilise les informations de taille associé avec la propriété elle-même. 8 signifie que la propriété est une séquence d'octets. 16 signifie que la propriété est une séquence de mots. Une fois la taille spécifiée, il est nécessaire de spécifier le type de chaque champs. (ex: 32ica)

a le champs maintient un nombre atomique
b le champs est un booléen
c la champs est un nombre non-signé
m la champs est un jeu de bits
o la champs est un tableau d'icônes, en séquence de nombres 32bits consistant de largeur, hauteur et ARGB.
s séquence d'octets
t format caractères
u chaîne UTF-8
x nombre héxadécimal

   dformat ne doit pas commencer par une lettre ou un "-". C'est ce qui permet de le distinguer d'un format. Un dformat est une chaîne contenant des caractères spéciaux indiquant l'affichage des champs d'une manière similaire à printf. Par exemple, " is ( $0, $1 \)\n" rend le POINT 3, -4 qui a un format de 32ii comme " is ( 3, -4 )\n".

   \n pour insérer un newline, $ suivie d'un nombre n affiche le champ n. ? est utilisé pour définir une expression inconditionnelle. ?exp(text) va afficher text si ext est non-0. exemples:

Afficher le champ 3 avec un label count si le flag numéro 3 est on.
?m3(count: $3\n)
Afficher la valeur inversée du champ 2 comme booléen
?$2=0(True)?!$2=0(False)

Le format des fichiers référés par -fs et $XPROPFORMATS a la forme suivant:
name format [dformat]
Si dformat n'est pas présent, utilise " = $0+\n"

EXEMPLES

Afficher le nom de la fenêtre root
xprop -root WM_NAME
Afficher le hints gestionnaire de fenêtre pour l'horloge
xprop -name xclock WM_HINTS
Afficher le début du tampon cut
xprop -root -len 100 CUT_BUFFER0
Afficher la taille de font
xprop -font fixed POINT_SIZE
Afficher toutes les propriétés de la fenêtre 0x200007
xprop -id 0x200007
Définir une simple propriété
xprop -root -format MY_ATOM_NAME 8s -set MY_ATOM_NAME "my_value"

VARIABLE D'ENVIRONNEMENT

DISPLAY Numéro d'affichage et hôte par défaut
XPROPFORMATS Nom d'un fichier avec des formats additionnels
^
28 août 2015

htmlpdflatexmanmd




xqmstats

xqmstats

Affiche les statistiques de gestion de quota depuis /proc

   Affiche les statistiques de dquot XFS avec les éléments suivant:

- Reclaims
- Missed reclaims
- Dquot dups
- Cache misses
- Cache hits
- Dquot wants
- Shake reclaims
- Inact reclaims

^
13 janvier 2014

htmlpdflatexmanmd




xrandr

xrandr

Interface pour l'extension RandR

   Xrandr est utilisé pour définir la taille, l'orientation et/ou la réflexion des sorties pour un écran. Il peut également définir la taille de l'écran. Invoqué sans option, il dump l'état des sorties, affiche les modes existant pour chacun d'entre eux, avec un '+' pour le mode préféré et un '*' après le mode courant.

OPTIONS

--verbose augmente la quantité d'informations affichées
-q, --query Affiche l'état courant du système
--dryrun Effectue toutes les actions spécifiées exceptée qu'aucun changement n'est fait
--nograb Applique les modifications sans saisir l'écran. Évite de bloquer d'autre applications durant la mise à jour, mais en cas de redimensionnement, les applications qui détectent la taille de l'écran peuvent recevoir les anciennes valeurs.
-d, -display name Affichage à utiliser
--screen snum Séléctionne l'écran à manipuler
--q1 Force l'utilisation de RandR version 1.1
--q12 Force l'utilisation de RandR version 1.2

OPTIONS version 1.3

--current Retourne la configuration de l'écran courant
--noprimary Ne définis par de sortie primaire
--panning widthxheight[+x+y[/track_widthxtrack_height+track_x+track_y[/border_left/border_top/border_right/border_bottom]]] Définis les paramètres de panning. Les 4 premiers paramètres spécifient le panning total, les 4 suivant, l'aire de suivi du pointeur (qui sont les même par défault). Les 4 derniers spécifient la bordure. Généralement cette option est définie en même temps que la taille de l'écran (--fb)
--transform a,b,c,d,e,f,g,h,i Spécifie une matrice de transformation à appliquer sur la sortie. Un filtre bilinéaire est automatiquement sélectionné. La transformation est basée sur des coordonnées homogènes. La matrice multipliée par le vecteur de coordonnées d'un pixel de la sortie donne le vecteur de coordonnées transformée. Le vecteur (x,y) du pixel de sortie est étendu à 3 valeurs ( x y w ), avec 1 comme coordonnées w et multipliée avec la matrice. Les coordonnées finales du pixel sont ainsi calculés avec une division homogène par la coordonnée w transformée. En d'autres termes, les coordonnées (x' y') du pixel transformé sont:

        x’ = (ax + by + c) / w’ et
        y’ = (dx + ey + f) / w’ ,
        avec w’ = (gx + hy + i)

           Typiquement, a et e correspondent à l'échelle sur les axes X et Y, c et f correspondent à la translation sur ces axes, et g, h et i sont respectivement 0, 0 et 1. La matrice peut aussi être utilisée pour exprimer des transformations plus complexes tels qu'une correction keystone, ou une rotation. pour une rotation, cette formule peut être utilisée:

        cos T -sin T 0
        sin T cos T 0
        0 0 1

--scale xxy Change les dimensions de l'image de sortie. Les valeurs supérieur à 1 compressent l'écran, des valeurs inférieur créent un zoom dans la sortie. Cette option est une version raccourci de l'option --transform
--primary Définis la sortie comme primaire. Elle sera triée d'abord dans Xinerama et RANDR.

OPTIONS version 1.2

--prop, --properties Affiche les propriétés de chaque sortie.
--fb widthxheight Reconfigure l'écran à la taille spécifiée
--fbmm widthxheight Définis les valeurs reportées pour la taille physique de l'écran.
--dpi dpi Définis également la taille physique de l'écran. Il utilise le dpi spécifié pour calculer la taille approprié
--newmode name mode De nouveaux modelines peuvent être ajoutés au serveur et associés avec les sorties. mode est spécifié en utilisant la syntaxe ModeLine de xorg.conf
--rmmode name supprime un mode du serveur
--addmode output name Ajoute un mode au jeu de modes valides pour une sortie
--delmode output name Supprime un mode du jeu de modes valide pour une sortie
--output output Séléctionne une sortie à configurer
--auto Pour les sorties désactivées mais connectées, les active et utilisant leur mode préféré. Pour les sorties activées mais déconnectées, les désactive.
--mode mode Sélectionne un mode
--preferred Sélectionne le même mode que --auto, sans activer ni désactiver les sorties.
--pos xxy Positionne la sortie dans l'écran en utilisant les coordonnées pixel. En cas de réflexion ou rotation, la translation est appliquée après les effets
--rate rate Marque une préférence pour le taux de rafraîchissement proche des valeurs spécifiées.
--reflect reflection Peut être normal, x, y, ou xy. Force le contenu de la sortie d'être réflechis au travers des axes spécifiés
--rotate rotation Peut être normal, left, right, ou inverted.
--left-of, --right-of, --above, --below, --same-as another-output Positionne la sortie relative à la position d'une autre sortie.
--set property value Définis une propriété de sortie.
--off Désactive une sortie
--crtc crtc Utilise le crtc spécifié (soit comme index dans la liste de crtc, soit XID)
--gamma red:green:blue Définis les valeurs point flottant comme correction gamma sur le crtc actuellement attaché à cette sortie. Il n'est pas possible de définir 2 valeurs différentes pour des sorties ayant le même crtc (ex: des sorties clonées) et passer une sortie à un autre crtc ne change pas les correction gamma.
--brightness brightness Multiplie les valeurs gamma sur le crtc actuellement attaché à la sortie aux valeurs spécifiées.

OPTIONS version 1.1

-s, --size size-index, --size widthxheight Définis la taille d'écran
-r, --rate, --refresh rate Définis le taux de rafraîchissement au plus proche de la valeur spécifiée
-o, --orientation rotation Définis l'orientation de l'écran (normal, inverted, left, right)
-x Réflète sur l'axe X
-y Réflète sur l'axe Y

Exemples

Définis une sortie appelée LVDS à son mode préféré, et à sa droite, place une sortie appelée VGA au mode préféré d'un écran qui a été physiquement pivoté dans le sens des aiguilles d'une montre:
xrandr --output LVDS --auto --rotate normal --pos 0x0 --output VGA --auto --rotate left --right-of LVDS
Force l'utilisation du mode 1024x768 sur une sortie appelée VGA:
xrandr --newmode "1024x768" 63.50 1024 1072 1176 1328 768 771 775 798 -hsync +vsync
xrandr --addmode VGA 1024x768
xrandr --output VGA --mode 1024x768
Active le panning sur un desktop 1600x768 tout en affichant un mode 1024x768 sur une sortie appelée VGA:
xrandr --fb 1600x768 --output VGA --mode 1024x768 --panning 1600x0
Un écran LVDS 1280x800 affichant une version réduite d'un desktop 3200x2000, et un grand écran VGA affichant la souris à une taille normale
xrandr --fb 3200x2000 --output LVDS --scale 2.5x2.5 --output VGA --pos 0x0 --panning 3200x2000+0+0/3200x2000+0+0/64/64/64/64
Afficher la sortie VGA en trapèze pour que le keystone soit corrigé quand le projecteur est légèrement au-dessus de l'écran
xrandr --fb 1024x768 --output VGA --transform 1.24,0.16,-124,0,1.24,0,0,0.000316,1
^
11 janvier 2014

htmlpdflatexmanmd




xrdb

xrdb

Utilitaire de base de données de ressource X

   xrdb est utilisé pour définir et lire le contenu des propriétés du RESOURCE_MANAGER sur la fenêtre root de l'écran 0, ou les propriétés de SCREEN_RESOURCES sur la fenêtre root d'un ou tous les écrans.

  Le fichier spécifié, ou l'entrée standard est passé au préprocesseur C avec les symboles suivants définis:

SERVERHOST=hostname Portion hostname de l'afficheur
SRVR_name id légal basé sur SERVERHOST (ex: my-dpy.lcs.mit.edu devient SRVR_my_dpy_lcs_mit_edu)
HOST=hostname idem à SERVERHOST
DISPLAY_NUM=num Numéro d'afficheur sur le serveur
CLIENTHOST=hostname Le nom de l'hôte sur lequel xrdb tourne
CLNT_name id légal basé sur CLIENTHOST (ex: expo.lcs.mit.edu devient CLNT_expo_lcs_mit_edu)
RELEASE=num le numéro du vendeur du serveur
REVISION=num version mineur du protocol X supporté par ce serveur
VERSION=num Version majeur du protocol X supporté par ce serveur
VENDOR="vendor" vendeur du serveur
VNDR_name id légal basé sur VENDOR
EXT_name Un symbole est définis pour chaque extension du protocol supporté par le serveur. Chaque nom est ur id légal (ex: X3D-PEX devient EXT_X3D_PEX )
NUM_SCREENS=num Le nombre d'écrans (depuis 0)
BITS_PER_RGB=num Nombre de bits dans une spécification de couleur RGB.
CLASS=visualclass Classe visuelle de la fenêtre root: StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, DirectColor.
CLASS_visualclass=visualid La classe visuelle de la fenêtre root. La valeur est l'id du visuel
COLOR Définis seulement si CLASS vaut StaticColor, PseudoColor, TrueColor ou DirectColor.
CLASS_visualclass_depth=num Un symbole est définis pour chaque visuelle supporté pour l'écran. Le symbole inclus la classe et sa profondeur.
HEIGHT=num Hauteur de la fenêtre root en pixels
WIDTH=num Largeur de la fenêtre root en pixels
PLANES=num Profondeur de la fenêtre root en pixels
X_RESOLUTION=num Résolution X de l'écran en pixels par mètre
Y_RESOLUTION=num Résolution Y de l'écran en pixels par mètre
! string Utilisé comme commentaire dans le fichier

OPTIONS

-display display Nom du serveur X à utiliser
-all Les opérations doivent être effectuées sur RESOURCE_MANAGER et SCREEN_RESOURCES.
-global Les opérations doivent être effectuées sur RESOURCE_MANAGER
-screen Les opérations doivent être effectuées sur SCREEN_RESOURCES de l'écran par défaut de l'affichage
-screens Les opérations doivent être effectuées sur SCREEN_RESOURCES de chaque écran de l'affichage
-n  Indique que les changements doivent être affichés à l'écran
-quiet N'affiche pas les alertes
-cpp filename Chemin du préprocesseur C à utiliser
-nocpp N'utilise pas de préprocesseur avant de les charger dans les propriétés
-symbols Les symboles qui sont définis pour le préprocesseur devraient être affichés
-query Affiche les propriétés
-load L'entrée devrait remplacer les propriétés existantes
-override L'entrée est ajoutée aux propriétés existantes
-merge Fusionne et trie lexicographiquement l'entrée
-remove Les propriétés spécifiées sont supprimées
-retain Le serveur ne devrait pas se réinitialiser si xrdb est le premier client
-edit filename Les propriétés spécifiées devraient être éditées dans le fichier données
-backup string Spécifi un suffix à ajouter au fichier utilisé avec -edit pour générer une sauvegarde
-Dname[=value] Cette option est passée au préprocesseur et est utilisé pour définir les symboles à utiliser avec des conditionnel tels que #ifdef
-Uname Cette option est passée au préprocesseur et est utilisé pour supprimer les définitions de symbole
-ldirectory Cette option est passée au préprocesseur et est utilisé pour spécifier un répertoire de recherche de fichier référencé avec #include

Variables d'environnement

DISPLAY Le nom d'affichage associé
^
07 janvier 2014

htmlpdflatexmanmd




xrefresh

xrefresh

Rafraîchis tout ou partie de l'écran

OPTIONS

-white Utilise un fond blanc
-black Utilise un fond noir
-solid color Définis la couleur du fond.
-root Utilise la fenêtre root
-none Repeint toutes les fenêtres
-display display Nom du serveur X à utiliser

Variables d'environnement

DISPLAY Le nom d'affichage associé
^
26 janvier 2014

htmlpdflatexmanmd




Xsecurity

Xsecurity

Contrôle d'accès aux affichages X. X fournis un mécanisme pour implémenter de nombreux systèmes de contrôles d'accès. L'implémentation actuelle inclus 5 mécanismes.

Host Access Simple host-based access control
MIT-MAGIC-COOKIE-1 Shared plain-text "cookies"
XDM-AUTHORIZATION-1 Secure DES based private-keys
SUN-DES-1 Based on Sun’s secure rpc system
Server Interpreted Server-dependent methods of access control

Description des systèmes d'accès

Host Access Tout client sur un hôte dans la liste est autorisé à accéder au serveur X.
MIT-MAGIC-COOKIE-1 Le client envoie un coockie 128bits avec les informations d'initialisation de connexion. Si le coockie match celui que le serveur a, l'accès est donné.
XDM-AUTHORIZATION-1 Similaire au précédent mais utilise une clé 56bits DES et une donnée aléatoire 64bits.
SUN-DES-1 SunOS supporte un système RPC à clé public.
Server Interpreted Fournis 2 chaînes au serveur. La première représente le type d'entrée, et le second contient la valeur de l'entrée.

Le fichier d'autorisation

   Excepté pour les mécanismes Host Access est Server Interpreted, chaque système utilise des données dans le fichier .Xauthority pour générer les informations d'autorisation à passer au serveur X lors de la connexion. MIT-MAGIC-COOKIE-1 et XDM-AUTHORIZATION-1 stockent des données secrètes dans ce fichier, donc tout ceux qui peuvent lire ce fichier peuvent avoir accès au serveur. Chaque entrée dans le fichier .Xauthority match une famille de connexion (TCP/IP, DECnet ou local) et le nom de l'affichage X (hostname et la numéro d'affichage). Une famille spéciale, FamilyWild (valeur 65535) force une entrée à matcher tout affichage, permettant l'entrée d'être utilisée pour toutes les connexions.

   Le serveur X, lorsqu'il fonctionne sur une station de travail, lit les informations depuis le fichier passé sur la ligne de commande avec l'option -auth. Les entrées d'autorisation dans ce fichier sont utilisés pour contrôler les accès au serveur. Dans chaque schéma listé ci-dessous, les données nécessaire au serveur pour initialiser un schéma d'autorisation sont identique aux données nécessaires au client pour générer les informations d'autorisation. Le même fichier peut être utilisé par les 2 processus.

MIT-MAGIC-COOKIE-1 Ce système utilise 128bits de données partagées entre l'utilisateur et le serveur X, Une collection le bits peut être utilisé, Xdm génère ces clés en utilisant un générateur de nombre pseudo-aléatoire, donc la prochaine clé de session ne peut pas être calculée depuis la clé de session courante.
XDM-AUTHORIZATION-1 Ce système utilise 2 informations. 64bits de données aléatoires, et une clé DES 56bits (donnée aléatoire). Xdm génère ces clés en utilisant le même générateur de nombre pseudo-aléatoire que MIT-MAGIC-COOKIE-1.
SUN-DES-1 Ce système nécessite une représentation chaîne du principal qui identifie le serveur X associé. Cette information est utilisée pour chiffrer les informations d'autorisation du client quand elles sont envoyées au serveur. Quand xdm démarre X, il utilise le principal root de la machine sur lequel il tourne (ex: unix.hostname@domain) En plaçant le nom principal correcte dans le fichier .Xauthority, Xlib génère les informations d'autorisation en utilisant la librairie secure RPC.

Types d'accès Server interpreted

IPv6 Une adresse IPv6
hostname Le nom d'hôte
localuser & localgroup Sur les systèmes qui peuvent déterminer les acréditations d'un processus client, ces méthodes fournissent un accès basés sur ces acréditations. Le format des valeurs fournis est spécifique à la plateforme.
^
05 janvier 2014

htmlpdflatexmanmd




Xserver

Xserver

X est le nom générique pour le serveur d'affichage X Window System. C'est généralement un lien vers le serveur approprié. Il est généralement lancé par le gestion d'affichage xdm. Tous les serveurs X acceptent les options décrites ci-dessous.

Options de tous les serveurs X

:displaynumber X server se lance sous le displaynumber donné, qui est par défaut 0.
-a number Définis l'accélération du pointer.
-ac Désactive les mécanisme de contrôle d'accès basé sur l'hôte. Permet l'accès pour tout hôte, et leur permet de modifier la liste de contrôle d'accès.
-audit level Niveau d'audit. (défaut 1 - audit les connections rejetées, 2 - audit les connections acceptées, 4 - active les message de sécurité, 0 - désactive).
-auth authorization-file Spécifie un fichier qui contient une collection d'enregistrement d'autorisation utilisés pour les autorisations d'accès.
-background none Demande au pilote de ne pas effacer le fond au lancement.
-br Définit la fenêtre root en noir par défaut
-bs Désactive le support du backing store sur tous les écrans
-c Désactive les key-click
c volume Définis le volume key-clic (de 0 à 100)
-cc class Définis la classe visuelle pour la fenêtre root des écrans couleur.
-core Génère un core dump sur erreur fatale
-deferglyphs whichfonts Spécifie le type de fonts que le serveur doit tenter d'utiliser. whichfonts peut être all fonts, no fonts ou 16.
-dpi resolution Définis la résolution pour tous les écrans, un point par pouce, utile si le serveur ne peut pas le déterminer lui-même
dpms Active le dpms (Display Power Management Services).
-dpms Désactive le dpms
-extensionextensionName Désactive l'extension spécifiée (sans argument, affiche la liste)
+extensionextensionName Active l'extension spécifiée (sans argument, affiche la liste)
-f volume Définis le volume du bell (0 à 100)
-fc cursorFont Définis la font du curseur par défaut
-fn font Définis la font par défaut
-fp fontPath Chemins de recherche pour les fonts
-l Ignore tous les arguments suivant
-maxbigreqsize size Définis la plus grosse requête à la taille en Mo spécifiée
-nocursor N'affiche pas le curseur
-nolisten trans-type Désactive un type de transport.
-noreset Empêche un reset serveur quand la dernière connexion client est fermée
-p minutes Durée du cycle de l'écran de veille, en minutes
-pn le serveur continue de fonctionner s'il échoue à établir tous les connexions socket, mais en établit au moins une.
-nopn Echoue si le serveur ne peut pas établir toutes les connexions socket
-r Désactive l'auto-repeat
r Active l'auto-repeat
-retro Commence avec le curseur et les pointillés visibles.
-s minutes Définis le timeout de l'écran de veille, en minutes
-su Désactive le support sauver sous sur tous les écrans
-seat seat Site où fonctionner. Permet de n'exposer qu'une partie des périphériques connectés au système
-t number Définis le seuil d'accélération du pointeur (après combien de pixel l'accélération prend effet)
-terminate Le serveur se termine au server reset
-to seconds timeout de connexion en secondes
-tst Désactive toutes les extensions de test
v Définis les préférences d'écran de veille (video-off)
-v Définis les préférences d'écran de veille (video-on)
-wm Force le backing-store par défaut de toutes les fenêtres d'être WhenMapped
-wr Définis le fnêter root en blanc
-x extension Charge les extensions spécifiées à l'initialisation
[+-]xinerama Active/désactive l'extension xinerama

Options dépendante du serveur

-ld kilobytes Limite d'espace de données du server (-1 laisse la limite inchangée)
-lf files Limite du nombre de fichiers ouverts (-1 laisse la limite inchangée)
-ls kilobytes Définis la limite d'espace de pile (-1 laisse la limite inchangée)
-render default|mono|gray|color Définis la politique d'allocation de couleur utilisé par l'extension de rendu
-dumbSched Désactive le smart scheduling
-schedInterval interval Définis l'interval du smart scheduling, en milliseconde

Options XDMCP

-query hostname Active XDMCP est envoie des paquets query à l'hôte spécifié
-broadcast Active XDMCP et broadcast des paquets BroadcastQuery sur le réseau. Le premier gestionnaire d'affichage qui répond sera choisi pour la session.
-multicast [address[hop count]] Active XDMCP et multicast des paquets BroadcastQuery sur le réseau.
-indirect hostname active XDMCP et envoie des paquets IndirectQuery au hostname spécifié
-port port-number Utilise le port spécifié pour les paquets XDMCP. Doit être spécifié avant -query, -broadcast, -multicast, ou -indirect.
-from local-address Spécifie l'adresse locale de connexion. Utile pour les hôtes ayant plusieurs interfaces réseaux.
-once Le serveur détermine quand la session XDMCP prend fin
-class display-class XDMCP a un qualifier additionnel utilisé pour la recherche des options spécifique à l'affichage. (défaut: MIT-Unspecified)
-cookie xdm-auth-bits En testant XDM-AUTHENTICATION-1, une clé privée est partagée entre le serveur et le manageur. Cette option définie la valeur de la donnée privée.
-displayID display-id Permet au gestionnaire d'affichage d'identifier chaque affichage pour qu'il puisse localiser la clé partagé.

Options XKeyboard

Les serveur X qui supportent l'extension XKEXBOARD supportent ces options. Tous les fichiers layout spécifiés sur la ligne de commande doivent être localisés dans le répertoire de base XKB (/usr/lib/X11/xkb)
[+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask ] ] ] ] Active/désactive les séquences de clé AccessX
-xkbdir directory Répertoire de base pour les fichiers de couche clavier. Non disponible lorsque les uid effectifs et réel sont différents
-ardelay milliseconds Définis le délay d'auto répétition, en millisecondes.
-arinterval milliseconds Définis l'interval d'au-répétition, en millisecondes.
-xkbmap filename Charge les descriptions de clavier dans le fichier spécifié dans le serveur au démarrage.

Accès

   X server implémente un sous-jeu des protocoles d'autorisation suivants: MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1, XDM-AUTHORIZATION-2, SUN-DES-1, et MIT-KERBEROS-5.

  Les données requises par les protocoles sont passés au serveur dans un fichier privé nommé avec l'option -auth. chaque fois que le serveur doit accepter la première connexion après un reset ou quand le serveur démarre, il lit ce fichier. Si ce fichier contient des autorisations, seul les clients qui envoient une enregistrement listé dans ce fichier aura l'accès. Le serveur utilise également une liste d'accès basé sur l'hôte. Cette liste consiste de l'hôte sur lequel le serveur tourne et toutes les machines listées dans /etc/Xn.hosts, où n est le numéro d'affichage du serveur. exemple:

joesworkstation
corporate.company.com
star::
inet:bigcpu
local:

Signaux

SIGHUP Le serveur ferme toutes les connexions, libère les ressources et restaure tous les défauts.
SIGTERM Force le serveur à se terminer correctement.
SIGUSR1 Quand le serveur démarre, il vérifie s'il a hérité SIGUSR1 en tant que SIG_IGN au lieu de SIG_DFL. Dans ce cas, le serveur envoie SIGUSR1 à son process parent une fois qu'il s'est initialisé. Xdm l'utilise pour savoir quand la connexion au serveur est possible.

Fonts

   Le serveur peut obtenir des fonts depuis des répertoires et/ou des serveurs parent. La liste de ces path est contrôlé par les fonts path (/usr/share/fonts/X11/misc/, /usr/share/fonts/X11/TTF/, /usr/share/fonts/X11/OTF/, /usr/share/fonts/X11/Type1/, /usr/share/fonts/X11/100dpi/, /usr/share/fonts/X11/75dpi/). Un type spécial de répertoire peut être spécifié en utilisant le préfix catalogue: ces répertoires peuvent contenir des liens vers de vrai répertoires.

FONTPATH.D

   La forme spécial catalogue:‹dir› contient des liens et chaque lien sera ajouté comme font FPE. Le lien peut être suffixé par des attributs comme unscaled. pri est utilisé pour ordonner les paths de fonts spécifiés par les liens. Exemple de configuration:

75dpi:unscaled:pri=20 -› /usr/share/X11/fonts/75dpi
ghostscript:pri=60 -› /usr/share/fonts/default/ghostscript
misc:unscaled:pri=10 -› /usr/share/X11/fonts/misc
type1:pri=40 -› /usr/share/X11/fonts/Type1
type1:pri=50 -› /usr/share/fonts/default/Type1

   Va ajouter /usr/share/X11/fonts/misc comme premier FPE avec l'attribut 'unscaled', le FPE suivant sera /usr/share/X11/fonts/75dpi, unscaled également, etc. C'est équivalent à définir les pathsuivants:

/usr/share/X11/fonts/misc:unscaled,
/usr/share/X11/fonts/75dpi:unscaled,
/usr/share/X11/fonts/Type1,
/usr/share/fonts/default/Type1,
/usr/share/fonts/default/ghostscript

Fichiers

/etc/Xn.hosts ACL initial pour l'affichage numéro n
/usr/share/fonts/X11/misc Répertoires des fonts bitmap
/usr/share/fonts/X11/75dpi Répertoires des fonts bitmap
/usr/share/fonts/X11/100dpi Répertoires des fonts bitmap
/usr/share/fonts/X11/TTF Répertoires des fonts outline
/usr/share/fonts/X11/Type1 Répertoires des fonts outline
/tmp/.X11-unix/Xn Socket unix pour l'affichage numéro n
/usr/adm/Xnmsgs Fichier de logs d'erreurs pour l'affichage n
/usr/lib/X11/xdm/xdm-errors Fichier de log d'erreurs si le serveur est lancé sous xdm.
^
22 janvier 2014

htmlpdflatexmanmd




xset

xset

Utilitaire de préférences utilisateur

OPTIONS

-display display Nom du serveur X à utiliser
b Contrôle le volume bell, sa durée et hauteur sous la forme: [on|off]-‹hauteur en hertz›-‹durée en millisecondes›
[-]bc bug compatibility
[-]c Contrôle le key click (on, off 0-100)
−dpms Désactive DPMS
+dpms Active DPMS
dpms flags... Permet de définir les paramètres DPMS (Energy Star)? Peut prendre 3 valeurs numériques, ou force suivi par un état DPMS (standby, suspend, off, on). Ls 3 valeurs correspondent à la periode d'inactivité en unité de secondes avant que les 3 modes soient activés. une valeur 0 désactive le mode.
fp=path,... Définis le chemin de fonts. Interprété par le serveur, et non le client.
fp default Réinitialise le chemin de fonts du serveur à la valeur par défaut
fp rehash Réinitialise le chemin de fonts du serveur à la valeur courante et force le serveur à relire sa base de fonts. Générallement utilisé lors de l'ajout de nouvelles fonts.
-fp, fp- Supprime les éléments du path de fonts courant
+fp, fp+ Ajoute les éléments au path de fonts courant
led, -led Contrôle les leds du clavier. le premier paramètre est le numéro de led, ou "named" si le serveur supporte l'extension XKB, dans ce cas, le mot clé de la led est donné (ex: xset led named "Scroll Lock"
mouse Contrôle les paramètres de la souris. Peut s'adapter à tout périphérique de pointage. Les paramètres sont acceleration et threshold. L'accélération peut être spécifié par un entier ou une fraction. Le seuil est un entier. Les paramètres s'appliquent à tous les pointeurs connectés.
p Contrôle les valeurs de couleur de pixel. Les paramètres sont le numéro d'entrée de map de couleur en décimal, et une spécification de couleur. les couleurs de fond de la fenêtre root peut être changée en altérant les entrées pour BlackPixel et WhitePixel.
r Contrôle l'auto-répétition. -r, ou r off désactive l'auto-répétition (de 0 à 255). ex: xset -r 10 désactive l'auto-répétition pour la touche 1 de la première rangée d'un clavier IBM PC.
s Permet de définir les paramètres d'écran de veille. Accèpte jusqu'à 2 paramètres numériques. blank/noblank (définit un motif ou un écran blanc), expose/noexpose (permet l'exposition de la fenêtre ou désactive l'écran de veille si le serveur peut regénérer les écrans sans causer d'event d'expositions), on/off (active/désactive l'écran de veille), activate/reset (force l'activation de l'écran de veille même si l'écran est éteind/désactive l'écran de veille s'il est actif), ou default.
q Donne des informations sur les paramètres courant
^
05 janvier 2014

htmlpdflatexmanmd




xsetroot

xsetroot

Définit les paramètre de la fenêtre root

OPTIONS

-def Réinitialise les paramètres non spécifiés à leur valeurs par défaut.
-cursor cursorfile maskfile Permet de changer le pointeur quand il est en dehors de toute fenêtre. Le curseur et les fichiers de masque sont des bitmaps.
-cursor_name cursorname Change le pointeur à un des curseurs standard depuis la font cursor.
-xcf cursorfile cursorsize Change le pointeur à un chargé depuis un fichier Xcursor, à la taille spécifiée
-bitmap filename Utilise l'image comme motif de fenêtre.
-mod x y De 1 à 16.
-gray Fond gris (meilleur visuel)
-grey Fond gris
-fg color Spécifie la couleur à afficher pour le bit 1 dans l'image
-bg color Spécifie la couleur à afficher pour le bit 0 dans l'image
-rv Inverse le foreground et background
-solid color Définis la couleur du fond.
-name string Spécifie le nom à assigner à la fenêtre root
-display display Nom du serveur X à utiliser
^
04 janvier 2014

htmlpdflatexmanmd




xvfb

xvfb

Server X virtuel pour X

   xvfb est un serveur X qui se lance sur des machines sans affichage physique ni périphérique d'entrée. Il émule un framebuffer en utilisant la mémoire virtuelle.

OPTIONS

en plus des options normales de Xserver
-screen screennum WxHxD Créé un écran et lui définit ses propriétés (défaut: :0 1280x1024x8)
-pixdepths list-of-depths Spécifie une liste de pixmap depths que le serveur devrait supporter
-fbdir framebuffer-directory Spécifie le répertoire qui lequel les fichiers mappés en mémoire contenant le framebuffer devraient être créés.
-shmem Spécifie que le framebuffer devrait être placé en mémoire partagée.
-linebias n Spécifie comment ajuster la pixelisation des lignes.
-blackpixel pixel-value, -whitepixel pixel-value Spécfie les valeurs des pixels blanc et noir à utiliser.

FICHIERS

framebuffer-directory/Xvfb_screen‹n› Créés si -fbdir est spécifié, un par screen. Est au format xwd.

Exemples

Ecoute les connections en tant que serveur n°1, écran 0
Xvfb :1 -screen 0 1600x1200x32
Ecoute les connections en tant que serveur n°1, écran 1
Xvfb :1 -screen 1 1600x1200x16
Ecoute les connections en tant que serveur n°0, avec support de différents
depth.
Xvfb -pixdepths 3 27 -fbdir /var/tmp
Affiche l'écran 0 du serveur démarré par l'exemple précédent:
xwud -in /var/tmp/Xvfb_screen0
^
04 janvier 2014

htmlpdflatexmanmd




xvinfo

xvinfo

Affiche des informations sur l'adapteur d'extension X-Video

OPTIONS

-display display Nom du serveur X à utiliser
-short Affiche moins de détails

Variables d'environnement

DISPLAY Le nom d'affichage associé
^
01 janvier 2014

htmlpdflatexmanmd




xwd

xwd

Dump une image d'une fenêtre X

OPTIONS

-display display Nom du serveur X à utiliser
-nobdrs N'inclus pas la bordure de la fenêtre dans le dump
-out file Spécifie le nom du fichier à créer
-xy format XY au lieu du format Z (affichage couleur uniquement)
-add value Spécifie une valeur signée à ajouter à chaque pixel
-frame La frame du gestionnaire de fenêtre devrait être inclus en sélectionnant manuellement la fenêtre
-root La fenêtre root est dumpé
-id id Dump la fenêtre d'id spécifiée
-name Spécifie le nom sous lequel les ressources de l'application devraient être trouvés.
-icmap utilise le premier colormap installé au lieu d'obtenir les valeurs RGB
-screen Capture depuis la fenêtre root. Permet d'avoir les autres fenêtres, menu, etc.
-silent Pas de bell après le dump.

Variables d'environnement

DISPLAY Pointe vers un serveur X.
^
01 janvier 2014

htmlpdflatexmanmd




xwininfo

xwininfo

Affiche des informations sur les fenêtres

OPTIONS

-id id Spécifie la fenêtre cible
-name Spécifie le nom sous lequel les ressources de l'application devraient être trouvés.
-root Utilise la fenêtre root
-int Spécifie que les id devraient être des valeurs entières et non en héxa.
-children Affiche les id de fenêtre root, parent et enfant
-tree Comme -children mais affiche les enfant récursivement
-stats Affiche des informations utiles sur la fenêtre
-bits Affiche des informations utiles sur la fenêtre
-events Affiche les events désiré par le masque d'event de la fenêtre
-size Affiche des informations sur la taille de la fenêtre
-wm Affiche les windows manager hints
-shape Affiche des informations utiles sur la fenêtre
-frame Spécifie qu'en spécifiant une fenêtre manuellement, regarde la frame de gestionnaire de fenêtre au lieu de rechercher la fenêtre client.
-metric Affiche toutes les valeurs en millimètre et pixel
-english Affiche toutes les valeurs en pouce et pixel
-all Affiche toutes les informations possible
-display display Nom du serveur X à utiliser

Variables D'Environnement

DISPLAY Le nom d'affichage associé
^
01 janvier 2014

htmlpdflatexmanmd




xwud

xwud

Afficheur d'images pour X

OPTIONS

--bg color, --background color Spécifie la couleur à utiliser pour la fond de la fenêtre
-display display Nom du serveur X à utiliser
-dumpheader Affiche des informations d'en-tête XWD
--fg color, --foreground color Couleur à utiliser pour les textes et graphiques
-geometry geom Spécifie la taille et la position de la fenêtre
-in file Spécifie le fichier à lire
-new Force la création d'un nouveau colormap pour afficher l'image
-noclick Empêche de fermer la fenêtre au clic
-plane number Sélectionne un single bit plane de l'image pour l'afficher avec cette option.
-raw Force à afficher l'image avec les valeurs de couleur qui existe à l'écran
-rv, -reverse Simule le mode vidéo reverse si possible
-scale Permet de redimensionner l'image
-std maptype Affiche l'image en utilisant une Standard Colormap spécifié. (best, default, gray, ...)
-vis vis-type-or-id Permet de spécifier une classe visuelle. défaut: best. Peut être StaticGray, GrayScale, StaticColor, PseudoColor, DirectColor, TrueColor ou Match.

Variables d'environnement

DISPLAY Pointe vers un serveur X.
^
05 juillet 2010

htmlpdflatexmanmd




yes

yes

Affiche les arguments en boucle

   yes affiche les arguments, séparés par des espaces, et suivis par un newline, en boucle jusqu'à ce qu'il soit tué. Sans argument, yes affiche 'y' suivie par un newline.

^
16 janvier 2015

htmlpdflatexmanmd




zdb

zdb

Debugger ZFS

Description

   Cette commande est utilisée pour diagnostiquer les erreurs et autres statistiques. Vu que ZFS est toujours consistant su le disque et s'auto-répare, zdb devrait seulement être lancé sous la direction d'un ingénieur. Sans argument, zdb effectue une vérification de consistance dans le pool et les datasets associés, et reporte tout problème détecté. Les options sont interne à Sun et sont sujets à changement.

Codes de sortie

0 Le pool est consistant
1 Une erreur a été détectée
2 Options de ligne de commande invalides.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-____Unstable

^
25 janvier 2015

htmlpdflatexmanmd




zfs

zfs

Configure des systèmes de fichiers ZFS

Description

   La commande zfs configure des datasets ZFS dans des pools de stockage ZFS. Un dataset est identifié par un chemin unique dans l'espace de nom ZFS. par exemple pool/{filesystem,volume,snapshot} où la longueur maximum d'un nom de dataset est MAXNAMELEN (256octets). Un dataset peut être un des suivants:

filesystem Un dataset ZFS de type filesystem peut être monté dans l'espace de nom système standard et fonctionne comme tout autre système de fichier. Bien que les système de fichiers ZFS sont conçus pour être conforme POSIX, des problème connus existent qui empêche la conformité dans certains cas. Les applications qui dépendent des conformités standard peut échouer lors de la vérification de l'espace disque disponible.
volume Un volume logique exporté comme périphérique block ou brute. Ce type de dataset devrait seulement être utilisé sous des circonstances particulière. Les systèmes de fichier sont typiquement utilisé dans la plupart des environnements.
snapshot Une version lecture seul d'un filesystem ou volume à un point donné dans le temps. C'est spécifié en filesystem@name ou volume@name.

Hiérarchie des systèmes de fichier

   Un pool de stockage ZFS est une collection logique de périphériques qui fournissent de l'espace pour les datasets. Un pool de stockage est également la racine de la hiérarchie de système de fichiers ZFS. La racine du pool peut être accédé comme système de fichier, tel que monter et démonter, prendre des snapshots, et définir des propriétés. Les caractéristiques de stockage physique, cependant, sont gérés par la commande zpool.

Snapshots

   Un snapshot est une copie lecture seul d'un système de fichier ou un volume. Les snapshots peuvent être crées extrêment rapidement, et ne consomment initialement aucun espace dans le pool. Comme les données dans le dataset actif changent, le snapshot consomme plus de données et qui sont partagés avec le dataset actif. Les snapshots peuvent avoir des noms arbitraires. Les snapshots de volumes peut être clonés ou annulés, mais ne peuvent pas être accédés indépendamment.

   Les snapshots de filesystem peuvent être accédés sous le répertoire .zfs/snapshot dans le système de fichier racine. Les snapshots sont automatiquement montés à la demande et peuvent être démontés à intervalles réguliers. La visibilité du répertoire .zfs peut être contrôlé par la propriété snapdir.

Clones

   Un clone est un volume en écriture ou un système de fichier dont le contenu initial est le même qu'un autre dataset. Comme avec les snapshots, créer un clone est presque instantané, et ne consomme pas d'espace disque initialement.

   Les clones peuvent seulement être créés depuis un snapshot. Quand un snapshot est cloné, il créé une dépendance implicit entre le parent et l'enfant. Même quand un clone est créé ailleurs dans la hiérarchie de dataset, le snapshot original ne peut pas être détruit tant qu'un clone existe. La propriété origin expose cette dépendance, et la commande destroy liste de telles dépendances, si elles existent.

   La relation de dépendance des parent/enfant des clones peut être renversé en utilisant la sous-commande promote. Le système de fichier "origin" devient un clone du système de fichier spécifié, qui rend possible de détruire le système de fichier depuis lequel le clone avait été créé.

Points de montage

   Créer un système de fichier ZFS est une opération simple, donc le nombre de systèmes de fichier par système est susceptible d'être nombreux. Pour faire face à cela, ZFS gère automatiquement le montage et le démontage des systèmes de fichiers sans avoir besoin d'éditer /etc/vfstab. Tous les systèmes de fichiers gérés automatiquement sont montés par ZFS au boot.

   Par défaut, les systèmes de fichiers sont montés sous /path, où path est le nom du système de fichier dans l'espace de nom ZFS. Les répertoires sont créés et détruis si nécessaires.

   Un système de fichier peut également avoir un point de montage dans la propriété mountpoint. Ce répertoire est créé si nécessaire, et ZFS monte automatiquement le système de fichier quand zfs mount -a est invoqué (sans éditer /etc/vfstab). mountpoint peut être hérité, donc si pool/home a un point de montage de /export/stuff, alors le pool/home/user hérite automatiquement d'un point de montage /export/stuff/user.

   Une propriété mountpoint de système de fichier à none empêche le système de fichier d'être monté. Si nécessaire, les systèmes de fichiers ZFS peuvent également être gérés avec les outils traditionnels. Si un point de montage de système de fichier est mis à legacy, ZFS ne tente pas de gérer le système de fichier.

Zones

   Un système de fichiers ZFS peut être ajouté à une zone non-globale en utilisant la sous-commande zonecfg add fs. Un système de fichier ZFS qui est ajouté à une zone non-globale doit avoir sa propriété mountpoint à legacy.

   Les propriétés physiques d'un système de fichier ajouté sont contrôlé par l'administrateur global. Cependant, l'administrateur de zone peut créer, modifie, ou détruire des fichiers dans le système de fichier ajouté, en fonction de la manière dont le système de fichier est monté.

   Un dataset peut également être délégué dans une zone non-globale en utilisant la sous-commande zonecfg add dataset. Vous ne pouvez pas déléguer un dataset à une zone et l'enfant du même dataset à une autre zone. L'administrateur de zone peut changer les propriétés du dataset ou un de ses enfant. Cependant, la propriété quota est contrôlée par l'administrateur global.

   Un volume ZFS peut être ajouté comme périphérique à une zone non-globale en utilisant la sous-commande zonecfg add device. Cependant, ses propriétés physiques peuvent être modifiées seulement par l'administrateur global.

   Après qu'un dataset est délégué à une zone non-globale, la propriété zoned est automatiquement définie. Un système de fichier zoned ne peut pas être monté dans la zone globale, vu que l'administrateur de zone peut avoir définis le point de montage à des valeurs inacceptables.

   L'administrateur global peut effacer la propriété zoned, bien que cela devrait être fait avec une extrême attention. L'administrateur global devrait vérifier que tous les points de montage sont acceptable avant d'effacer cette propriété.

Déduplication

   La déduplication est un processus pour supprimer les données redondantes au niveau block, réduisant la quantité globale de données stockée. Si un système de fichier a la propriété dedup, les blocks de données dupliqués sont supprimés de manière synchrone. Le résultat est que seul une donnée unique est stockée et les composants communs sont partagés entre les fichiers.

Propriétés natives

   Les propriétés sont divisées en 2 types, les propriétés natives et les propriétés définis par l'utilisateur ( user ). Les propriétés natives exportent des statistiques internes ou contrôle le fonctionnement de ZFS. En plus, les propriétés natives sont soit éditables, soit lecture-seul. Les propriété user n'ont pas d'effet sur le fonctionnement de ZFS, mais peuvent être utilisés pour annoter les datasets d'une manière significative dans l'environnement.

   Tout dataset a un jeu de propriété qui exporte des statistiques sur le dataset aussi bien que contrôles divers modes. Les propriétés sont hérités du parent sauf s'ils sont spécifiés dans l'enfant. Certaines propriétés s'appliquent uniquement à certains type de datasets.

   Les valeurs des propriétés numériques peuvent être spécifié en utilisant des suffixes human-readable (ex: k, KB, M, Gb, etc.). Les valeurs de propriétés non-numériques sont sensibles à la casse et doivent être en minuscule, sauf pour mountpont, sharenfs, et sharesmb.

   Les propriétés natives suivantes consistent de statistiques lecture-seules sur le dataset. Ces propriétés ne peuvent être ni des jeux, ni hérités. Les propriétés natives s'appliquent à tous les types de dataset sauf mention contraire.

available La quantité d'espace disponible dans le dataset et tous ses enfants, assumant qu'il n'y a pas d'autre activité dans le pool. Parce que l'espace est partagé dans le pool, la disponibilité peut être limité par plusieurs facteurs, incluant la taille physique du pool, quotas, reservations, ou d'autres datasets dans le pool.
compressratio Le ratio de compression pour ce dataset, exprimé en multiplicateur. La compression peut être activée avec zfs set compression=on. Défaut: off.
creation La date de création du dataset
defer_destroy Cette propriété est on si le snapshot a été marqué pour une destruction déférée en utilisant la commande zfs destroy -d. Sinon, la propriété est off.
origin Pour les systèmes de fichier ou les volumes clonés, le snapshot depuis lequel le clone a été créé. L'origine ne peut pas être supprimé tant qu'un clone existe.
referenced La quantité de donnée qui est accessible par ce dataset, qui peut être partagé ou non avec d'autre datasets dans le pool. Quan un snapshot ou un clone est créé, il référence initialement la même quantité d'espace que le système de fichier ou le snapshot depuis lequel il a été créé, vu que son contenu est identique.
type le type de dataset: filesystem, volume, ou snapshot
used La quantité d'espace disque consommé par ce dataset et tous ses descendants. C'est la valeur qui est comparée au quota et à la réservation du dataset. L'espace utilisé n'inclus pas cette réservation du dataset, mais prend en compte les réservations de tous les dataset descendants. La quantité d'espace qu'un dataset consomme depuis son parent, aussi bien que la quantité d'espace qui sont libérés si ce dataset est détruit récursivement, est supérieur à son espace utilisé et sa réservation.

   Quand des snapshots sont créés, leur espace est initialement partagé entre le snapshot et le système de fichier, et possiblement avec les snapshots précédents. Vu que le système de fichier change, l'espace qui a été précédemment partagé devient unique au snapshot, et compté dans l'espace utilisé du snapshot. Additionnellement, supprimer les snapshots peut augmenter la quantité d'espace unique à ( et utilisé par ) d'autre shapshots.

   La quantité d'espace utilisé, disponible, ou référencé ne prend pas en compte les changements en attente, Ces changements en attente sont généralement pris en comptes dans les secondes qui suivent. Envoyer un changement au disque avec fsync ou O_SYNC ne garantit pas nécessairement que les informations d'utilisation de l'espace est mis à jours immédiatement.

usedby*  Les propriétés usedby* décomposent les propriétés used dans les diverses raisons pour lequel l'espace est uilisé. Spécifiquement, used = usedbychildren + usedbydataset + usedbyrefreservation +, usedbysnapshots. Ces propriétés sont seulement disponible pour les datasets créés dans des pools version 13.
usedbychildren La quantité d'espace utilisé par l'enfant de ce dataset, qui serait libéré si tous le dataset de l'enfant était détruit.
usedbydataset La quantité de l'espace utilisé par ce dataset lui-même, qui serait libéré si le dataset était détruit.
usedbyrefreservation La quantité d'espace utilisé par un refreservation définis dans ce dataset, qui serait libéré si refreservation était supprimé.
usedbysnapshots La quantité d'espace consommé par les snapshots de ce dataset. En particulier, c'est la quantité d'espace qui aurait été libéré si tous les snapshots de ce dataset étaient supprimés. Noter que ce n'est pas simplement la somme des propriétés used des snaphots parce que l'espace peut être partagé par plusieurs snapshots.
userused@user La quantité d'espace consommé par l'utilisateur spécifié dans ce dataset. L'espace est calculé pour le propriétaire de chaque fichier, tel qu'affiché par ls -l. La quantité d'espace est affiché par du et ls -s.

   Les utilisateurs non-privilégiés peuvent accéder seulement à leur propre espace. L'utilisateur root, ou un utilisateur qui a obtenu le privilège userused avec zfs allow, peut accéder à l'utilisation de tout le monde.

   userused@... n'est pas affiché par zfs get all. Le nom de l'utilisateur doit être ajouté après les @, en utilisant un des formes suivantes:

        - Nom POSIX ( ex: joe )
        - ID numérique POSIX (ex: 789)
        - Nom SID (ex: joe.smith@mydomain)
        - ID numérique SID (ex: S-1-123-456-789)

userrefs Cette propriété est définie au nombre d'utilisateurs dans ce snapshot, définis par la commande zfs hold.
groupused@group La quantité d'espace consommée par le groupe spécifié dans ce dataset. L'espace est calculé au groupe de chaque fichier, comme affiché par la commande ls -l. Les utilisateurs non-privilégiés peuvent seulement accéder à l'espace de leur propre groupe. L'utilisateur root, ou un utilisateur qui a obtenu le privilège groupused peuvent accéder à l'utilisation de tous les groupes.
volblocksize=blocksize Pour les volumes, spécifie la taille de block du volume. blocksize en peut pas être changé une fois le volume écrit, donc il doit être définis à la création. Défaut: 8Koctets. Tout puissance de 2 de 512o à 128Ko sont valides.

   Les propriété natives suivantes peuvent être utilisée pour changer le comportement d'un dataset:

aclinherit=discard | noallow | restricted | passthrough | passthrough-x Contrôle comment les entrées d'ACL sont hérités quand des fichiers et des répertoires sont créés. Un système de fichier avec une propriété aclinherit à discard n'hérite d'aucune entrée ACL. Un système de fichier avec une propriété aclinherit à noallow hérite uniquement des ACL héritables qui spécifient des permissions "deny". La valeur "restricted" (le défaut) supprime les permissions write_acl et write_owner quand l'entrée d'ACL est héritée. Un système de fichier avec une propriété aclinherit à passthrough hérite de toutes les entrées d'ACL héritables sans modification. passthrough-x à la même signification, excepté que les ACE owner@, group@ et everyone@ héritent des permissions d'exécution uniquement si le mode de création de fichier demande également le bit d'exécution.

   Quand la valeur de propriété est définie à passthrough les fichiers sont créés avec un mode déterminé par les ACE héritables. Si aucune ACE héritable n'existe qui affecte ce mode, alors le mode est définis en accord avec le mode demandé depuis l'application.

aclmode=discard | groupmask | passthrough Contrôle comment une ACL est modifiée durant un chmod. Un système de fichier avec une propriété aclmode à discard supprime toutes les entrées ACL qui ne représentent pas le mode du fichier. Une propriété aclmode a groupmask (le défaut) réduit les permissions utilisateur ou groupe. Les permission sont réduit, tel qu'ils ne sont pas supérieurs que les bits de permissions du groupe, sauf si c'est une entrée utilisateur qui a le même UID que le propriétaire du fichier ou répertoire. Dans ce cas, les permissions d'ACL sont réduites pour qu'elle ne soient pas supérieurs aux bits de permission du propriétaire. Un système de fichier avec une propriété aclmode à passthrough indique qu'aucun changement n'est fait aux ACL autre que générer les entrées ACL nécessaires pour représenter le nouveau mode du fichier ou répertoire.
atime=on | off Contrôle si la date d'accès pour les fichiers est mis à jours quand ils sont lus. Désactiver cette propriété évite de produire du trafic d'écriture en lisant des fichiers et peut augmenter les performances d'écritures. Défaut: on.
canmount=on | off | noauto À off, le système de fichier ne peut pas être monté, et est ignoré par zfs mount -a. C'est similaire à définir mountpoint à none, excepté que le dataset aura une propriété mountpoint définie, qui peut être hérité. Définir cette propriété à off permet aux datasets d'être utilisé seulement comme mécanisme d'héritage de propriété. Un exemple est d'avoir 2 datasets avec le même nountpoint, donc l'enfant des 2 datasets apparaît dans le même répertoire, mais peut avoir des caractéristiques hérités différents.

   Quand l'option noauto est définis, un dataset peut seulement être monté de démonté explicitement. Le dataset n'est pas monté automatiquement quand le dataset est créé ou importé, ni n'est monté par zfs mount -a ou démonté par zfs umount -a. Cette propriété n'est pas héritée.

checksum=on | off | fletcher2,| fletcher4 | sha256 Contrôle le checksum utilisé pour vérifier l'intégrité des données. La valeur par défaut est on, qui sélectionne automatiquement un algorithme approprié ( actuellement, fletcher4). Changer cette propriété n'affecte que les données nouvellement écrites.
compression=on | off | lzjb | gzip | gzip-N | zle Contrôle l'algorithme de compression utilisé pour ce dataset. L'algorithme lzjb est optimisé pour les performances tout en proposant un taux de compression correct. on équivaut à lzjb. Changer cette propriété n'affecte que les données nouvellement écrites.
copies=1 | 2 | 3 Contrôle le nombre de copies de données stockées pour ce dataset. Ces copies sont en plus de toute redondances fournies par le pool. Les copies sont stockée sur différents disques, si possible. Changer cette propriété n'affecte que les données nouvellement écrites. Cependant, définir cette propriété à la création du système de fichier en utilisant l'option -o copies=N
dedup=on | off | verify | sha256[,verify] Contrôle si la déduplication est en effet pour un dataset. Défaut: off. Le checksum utilisé pour la déduplication est sha256. Quand activé, l'algorithme de checksum écrase la propriété checksum. Définir la valeur à verify est équivalent à spécifier sha256,verify. À verify, quand 2 blocks ont la même signature, ZFS fait une comparaison supplémentaire bit à bit.
devices=on | off Contrôle si les périphérique peuvent être ouvert dans ce système de fichier. Défaut: on.
exec=on | off Contrôle si les processus peuvent être exécutés depuis ce système de fichier. Défaut: on.
mlslabel=label | none Label de sensibilité qui détermine si un dataset peut être monté dans une zone dans le système avec Trusted Extensions activé. Si le dataset labelisé correspond à la zone labelisée, la dataset peut être monté et accédé depuis la zone labélisée.

   Quand cette propriété n'est pas définie, la valeur par défaut est none. Définir à none est équivalent à supprimer cette propriété.

   Cette propriété peut être modifiée seulement quand Trusted Extensions est activé et seulement avec les privilèges appropriés. Les droits de le modifier ne peut pas être délégué. En changeant un label à un label supérieur ou en définissant le label initial, le privilège {PRIV_FILE_UPGRADE_SL} est requis. En changeant un label à un label inférieur ou à none, le privilège {PRIV_FILE_DOWNGRADE_SL} est requis. Changer le dataset à des labels autre que none peut être fait seulement quand le dataset n'est pas monté. Quand un dataset avec le label none est monté dans une zone labélisée, l'opération de montage définis automatiquement le mlslabel au label de cette zone.

mountpoint=path | none | legacy Contrôle le point de montage utilisé pour ce système de fichier. quand mountpoint est changé pour un système de fichier, le système de fichier et ses enfants qui héritent du point de montage sont démontés. Si la nouvelle valeur est legacy, alors ils restent démontés. Sinon, ils sont automatiquement remontés dans le nouvel emplacement si la propriété était précédemment legacy ou none, ou s'ils étaient montés avant que la propriété a été changée. En plus, tous système de fichiers partagé sont départagés et partagés dans le nouvel emplacement.
nbmand=on | off Contrôle si le système de fichier devrait être monté avec nbmant (Non Blocking mandatory locks). C'est utilisé pour les clients CIFS. Changer cette propriété prend effet seulement quand le système de fichier est démonté et remonté.
primarycache=all | none | metadata Contrôle ce qui est caché dans le cache primaire (ARC). Si cette propriété est à all, les données utilisateur et les métadonnées sont cachées. Si cette propriété est à none, rien n'est caché. Si cette propriété est définie à metadate, seul les metadate sont cachés. Défaut: all.
quota=size | none Limite la quantité d'espace qu'un dataset et ses descendants peuvent consommer. Cette propriété force une limite hard dans la quantité d'espace utilisée. Cela inclus tout l'espace consommé par ses descendants, incluant les systèmes de fichiers et les snapshots. Définir un quota dans un descendant d'un dataset qui a déjà un quota n'écrase par le quota de l'ancêtre, mais impose une limite additionnelle. Les quota ne peuvent pas être définis dans les volumes, vu que volsize agit comme quota implicite.
userquota@user=size | none Limite la quantité d'espace consommée par l'utilisateur spécifié. Similairement à la propriété refquota, le calcul de l'espace userquota n'inclus pas l'espace qui est utilisé par les datasets descendant, tel les snapshots et les clones. La consommation d'espace de l'utilisateur est identifié par la propriété userspace@suser.

   Forcer les quotas utilisateur peut être retardé de quelques secondes. Ce délai signifie qu'un utilisateur peut excéder son quota avec que le système notifie qu'il est hors quota. Le système va commencer à refuser les écritures additionnelles avec le message d'erreur EDQUOT.

   Les utilisateurs non-privilégiés peut seulement accéder à l'utilisation de l'espace de leur propre groupe. L'utilisateur root, ou un utilisateur qui a obtenu le privilège userquota avec zfs allow peut obtenir et définir le quota pour tout le monde.

   Cette propriété n'est pas disponible pour les volumes, et dans les systèmes de fichier avant v4 et les pools avant v15. Les propriétés userquota ne sont pas affichés par zfs get all. Le nom de l'utilisateur doit être ajouté après les @, en utilisant un des formes suivantes:

groupquota@group=size|none Limite la quantité d'espace consommé par le groupe spécifié.
readonly=on|off Contrôle si le dataset peut être modifié. Défaut: off.
recordsize=size Spécifie une taille de block suggérée pour les fichiers dans le système de fichier. Cette propriété est conçue pour être utilisé avec des bases de données qui accèdent à des enregistrement de taille fixe.
refquota=size|none Limite la quantité d'espace qu'un dataset peut consommer. Cette propriété force une limite hard sur la quantité d'espace utilisé. Cette limite n'inclue pas l'espace utilisé par les descendants, incluant les systèmes de fichier et les snapshot.
refreservation=size|none La quantité minimum d'espace garantit pour un dataset, n'incluant pas ses descendants. Quand la quantité d'espace utilisé est inférieur à cette valeur, le dataset est traité comme s'il prenait cette espace. Si refreservation est définis, un snapshot est seulement permis s'il y a suffisamment d'espace disponible dans le pool en dehors de cette réservation.
reservation=size|none Quantité minimum garantie pour un dataset et ses descendants. Quand la quantité d'espace utilise est inférieur à cette valeur, le dataset est traité comme s'il prenait cet espace.
secondarycache=all|none|metadata Contrôle ce qui est mis en cache secondaire (L2ARC). Si cette propriété est définie à all, les données utilisateurs et les métadonnées sont cachés.
setuid=on|off Contrôle si le bit set-uid est respecté pour le système de fichier. Défaut: on
shareiscsi=on|off Comme sharenfs, indique si un volume ZFS est exporté comme target iSCSI. Les valeurs peuvent être on, off, et type=disk. Défaut: off.
sharesmb=on|off|opts Contrôle si le système de fichier est partagé en utilisant le service Solaris CIFS, et quelles options sont utilisée.
sharenfs=on|off|opts Contrôle si le système de fichier est partagé via nfs, et quelles options sont utilisée. Un système de fichier avec la propriété sharenfs à off est géré via les outils traditionnels tel share, unshare, et dfstab. Sinon, le système de fichier est automatiquement partagé via zfs share et zfs unshare. Quand sharenfs est changé pour un dataset, le dataset et ses enfants héritant de la propriété sont partagés avec de nouvelles options, seulement si la propriété était précédemment off, ou s'il étaient partagés avant que la propriété soit changé.
logbias = latency | throughput Fournis une astuce à ZFS sur la manipulation des requêtes dans ce dataset. Si logbias est à latency (par défaut), ZFS utilise les périphériques de log du pool (si configuré) pour manipuler les requête à faible latence. À throughput, ZFS n'utilise pas les périphérique de log du pool. À la place, ZFS optimise les opérations synchrone pour le pool et l'utilisation efficace des ressources.
snapdir=hidden | visible Contrôle si le répertoire .zfs est caché ou visible dans le root du système de fichier. Défaut: hidden.
version=1 | 2 | current La version de ce système de fichier, qui est indépendant de la version du pool. Cette propriété peut seulement être définie pour les dernières versions supportées.
volsize=size Pour les volumes, spécifie la taille logique du volume. Par défaut, créer un volume établis une réservation de taille égale. Pour les pools de stockage avec un numéro de version 9 ou plus, un refreservation est définis à la place.
vscan=on | off Contrôle si les fichiers régulier devraient être scannés pour les virus quand un fichier est ouvert et fermé. En plus d'activer ce service, le service de scan de virus doit également être activé. Défaut: off.
xattr=on | off Contrôle si les attributs étendus sont activés pour ce système de fichier. Défaut: on
zoned=on | off Contrôle si le dataset est géré depuis une zone non-globale. Défaut: off.

   Les 3 propriétés suivantes ne peuvent pas être changée après la création du système de fichier. Si les propriétés ne sont pas définies avec les commandes zfs create et zpool create, ces propriété sont héritées du dataset parent.

casesensitivity=sensitive | insensitive | mixed Indique si l'algorithme de correspondance de nom de fichier utilisé par le système de fichier devrait être sensible à la casse.mixed indique que le système de fichier supporte les requêtes pour les 2 cas. Traditionnellement, les systèmes de fichiers UNIX et POSIX ont des noms de fichier sensible à la casse.
normalization = none | formC | formD | formKC | formKD Indique si le système de fichier devrait effectuer une normalisation unicode des noms de fichier quand 2 noms de fichier sont comparés. Si cette propriété est définie à une valeur autre que none et que la propriété utf8only n'est pas spécifiée, cette dernière est automatiquement mis à on. Défaut: none.
utf8only=on | off Indique si le système de fichier devrait rejeter les noms de fichier qui incluent des caractères qui ne sont pas présents dans le jeu UTF8.

Propriétés de point de montage temporaire

Quand un système de fichier est monté, soit via mount ou via zfs mount, ses options de montage sont définis en accord avec ses propriétés. La corrélation entre les propriété et les options de montage sont comme suit:
PROPERTY__________MOUNT OPTION
devices___________devices/nodevices
exec______________exec/noexec
readonly__________ro/rw
setuid____________setuid/nosetuid
xattr_____________xattr/noxattr

   En plus, ces options peuvent être définis sur une base par montage en utilisant l'option -o, sans affecter la propriété qui est stockée sur disque. Les valeurs spécifiées sur la ligne de commande écrasent celle stockées dans le dataset. L'option -nosuid est un alias pour nodevices,nosetuid.

Propriétés utilisateur

   En plus des propriétés natives standard, ZFS supporte les propriétés utilisateurs arbitraires. Les propriétés utilisateur n'ont pas d'effet sur le fonctionnement de ZFS, mais les applications et les administrateurs peut les utiliser pour annoter les datasets.

   Les noms de propriété utilisateur doivent contenir un caractère ':' pour les distinguer des propriétés natives. Ils peuvent contenis les lettre minuscules, des nombres, et les caractères: ':', '-', '.', '_'. La convention attendue est que le nom de propriété est divisée en 2 portions tel que module:property, mais cet espace de nom n'est pas forcé par ZFS. Les noms de propriété utilisateur ne peuvent pas avoir plus de 256 caractères, et ne peuvent pas commencer par un '-'.

   En utilisant des propriétés utilisateur, il est fortement suggéré d'utiliser reverse DNS pour le composant module pour réduire les chances que 2 packages indépendants utilisent le même nom de propriété pour différents buts. Les noms de propriété commençant avec com.sun. sont réservés.

   Les valeurs des propriétés utilisateur sont des chaînes arbitraires, sont toujours hérités, et ne sont jamais validées. Tous les commandes qui opèrent sur les propriétés peuvent être utilisé pour manipuler les propriétés utilisateurs également. Utiliser la commande zfs inherit pour supprimer des propriétés utilisateur. Si la propriété n'est pas définie dans un dataset parent, il est supprimé entièrement. Les valeur de propriétés sont limitées à 1024 caractères.

Volumes ZFS comme Swap ou périphériques de Dump

   Durant une installation initiale ou une mise à jours depuis un système de fichier UFS, un périphérique de swap et un périphérique de dump sont créés dans le pool root des volume ZFS. Par défaut, la taille de la zone de swap est basée sur la moitié de la mémoire physique jusqu'à 2Go. La taille du périphérique de dump dépend des prérequis du kernel à l'installation. Des volumes ZFS séparés doivent être utilisés pour les périphérique swap et dump. Ne pas swapper dans un fichier dans un système de fichier ZFS. Une configuration de fichier swap ZFS n'est pas supportée. Si vous devez changer votre zone de swap ou dump un fois le système installé, utiliser les commandes swap et dumpadm.

Sous Commandes

   Toutes les sous-commandes qui modifient l'état sont loggés de manière persistante dans le pool sous leur forme originelle.

zfs create [-p] [-o property=value] ... filesystem Crée un nouveau système de fichie zfs. Le système de fichier est automatiquement monté en accord avec les propriété mountpoint héritées du parent.

        -p Crée tous les datasets parent non-existant. les Datasets créés de cette manière sont automatiquement montés en accord avec le mountpoint hérité de leur parent. Toute propriété spécifié sur la ligne de commande est ignorée. Si le système de fichier cible existe déjà, l'opération se termine avec succès.
        -o property=value Définis la propriété spécifiée. Peut être spécifié plusieurs fois

zfs create [-ps] [-b blocksize] [-o property=value] ... -V size volume Crée un volume à la taille donnée. Le volume est exporté comme périphérique block dans /dev/zvol/{dsk,rdsk}/path, où path est le nom du volume dans l'espace de nom zfs. La taille représente la taille logique tel qu'exporté par le périphérique. Par défaut, une réservation de taille égal est créée.

        -p Crée tous les datasets parent non-existant. les Datasets créés de cette manière sont automatiquement montés en accord avec le mountpoint hérité de leur parent. Toute propriété spécifié sur la ligne de commande est ignorée. Si le système de fichier cible existe déjà, l'opération se termine avec succès.
        -s Créer un volume sparse sans réservation.
        -o property=value Définis la propriété spécifiée. Peut être spécifié plusieurs fois
        -b blocksize Équivaleunt à -o volblocksize=blocksize.

zfs destroy [-rRf] filesystem|volume Détruit le dataset donné. Par défaut, la commande départage tous systèmes de fichier partagé, démonte tous les systèmes de fichier actuellement monté, et refuse de détruire un dataset qui a une dépendance active (enfant ou clone).

        -r Détruit récursivement tout enfant
        -R Détruit récursivement toutes les dépendances, incluant les clones en dehors de la hiérarchie cible.
        -f Force à démonter les systèmes de ficiher en utilisant umount -f. N'a d'effet que sur les systèmes de fichier, et montés.

zfs destroy [-rRd] snapshot Détruit le snapshot donné si et seulement si la commande zfs destroy l'aurait détruit sans l'option -d. Si le snapshot n'est pas qualifié pour une destruction immédiate, il est marqué pour une suppression déferrée. Dans cet état, il est utilisable et visible jusqu'à ce que les conditions pour sa suppression soient rencontrées.

        -d Défère la suppression
        -r Détruit ou marque pour suppression tous les snapshots avec ce nom dans le système de fichier descendant.
        -R Détruit récursivement toutes les dépendances.

zfs snapshot [-r] [-o property=value] ... filesystem@snapname|volume@snapname Créer un snapshot avec le nom donné. Toutes les modifications précédente dans le système de fichier font partie du snaphot.

        -r Créer des snapshot récursivement pour tous les datasets descendants. Les snapshots sont pris automatiquement, donc tous les snapshots pris correspondent au même moment dans le temps.
        -o property=value Définis la propriété spécifiée.

zfs rollback [-rRf] snapshot Applique un précédent snapshot a un dataset. Par défaut, la commande refuse d'appliquer un snapshot autre que le plus récent. Les options -rR ne détruisent pas récursivement les snapshots enfant. Seul le snapshot récurisf top-level est détruit par une de ces options. pour appliquer un snapshot récursif complet, il faut l'appliquer individuellement aux snapshots enfant.

        -r Détruit récursivement tous snapshots plus récent que celui spécifié
        -R Détruit récursivement tous des snapshots plus récent, ainsi que les clones de ces snapshots.
        -f Utilisé avec -R force à démonter tous systèmes de fichier clone qui doivent être détruits

zfs clone [-p] [-o property=value] ... snapshot filesystem|volume Crée un clone d'un snapshot donné.

        -p créé tous les datasets parent non-existants. Les datasets crées de cette manière sont automatiquement montés en accord avec la propriété mountpoint héritée de leur parent.
        -o property=value Définis la propriété spécifiée.

zfs promote clone-filesystem Détache un clone de système de fichier de son snapshot original. Cela permet de détruire le système de fichier depuis lequel ce clone a été créé. La relation de dépendance de clone parent-enfant est réservée, donc le système de fichier d'origine devient un clone du système de fichier spécifié. Le snapshot qui a été cloné, et tous les snapshots précédents à ce snapshot, sont désormais possédés par le clone promus. L'espace qu'ils utilisent se déplace du système de fichier original avec le clone promus, il doit donc y avoir suffisamment d'espace pour ces snapshots. Aucun nouvel espace n'est consommé par cette opération, mais l'espace est ajusté. Le clone promu ne doit pas avoir de conflits de noms de snapshot.
zfs rename filesystem|volume|snapshot filesystem|volume|snapshot
zfs rename [-p] filesystem|volume filesystem|volume Renomme le dataset donné. La nouvelle cible peut être localisée n'importe où dans la hiérarchie ZFS, à l'exception des snapshots. Les snapshots peuvent seulement être renommés dans le système de fichier parent ou les volumes. En renommant un snapshot, le système de fichier parent du snapshot n'a pas besoin d'être spécifié comme partie du second argument. Les système de fichie renomés peuvent hériter de nouveaux points de montage, auquel cas ils sont démonté et remontés dans le nouveau point.

        -p Crée tous les datasets parent non-existant. Les datasets ainsi créés de cette manière sont automatiquement montés en accord avec la propriété mountpoint hérité du parent.

zfs rename -r snapshot snapshot Renome récursivement les snapshots de tous les datasets descendants. Les snapshots sont les seuls datasets qui peuvent être renommés récursivement.
zfs list [-r|-d depth] [-H] [-o property[,...]] [ -t type[,...]] [ -s property ] ... [ -S property ] ... [filesystem|volume|snapshot] ...Liste les informations de propriété pour les datasets donnés sous forme de tableau. Si spécifié, vous pouvez lister les informations de propriétés par chemin absolu ou relatif. Par défaut, tous les systèmes de fichier et volumes sont affichés.

        -H Utilisé pour le scripting. N'affiche pas les en-têtes, et sépare les champs par une simple tabulation.
        -r Affiche récursivement les enfants du dataset.
        -d depth Affiche récursivement les enfants du dataset, en limitant la profondeur de la récursion.
        -o property Liste de propriétés à afficher. Peut être une propriété native, utilisateur, name pour affichier le nom du dataset, et space pour afficher l'utilisation disque.
        -s property Une propriété pour le trie dans l'ordre ascendant basée sur la valeur de la propriété..
        -S property Idem mais dans l'ordre descendant.
        -t type Liste de type à affichier ( filesystem, snapshot, volume ou all).

zfs set property=value filesystem|volume|snapshot ... Définis la propriété à la valeur donnée pour chaque dataset.
zfs get [-r|-d depth] [-Hp] [-o all | field[,...] [-s source[,...]] all | property[,...] filesystem|volume|snapshot ... Affiche les propriété pour les datasets donné. si aucun dataset n'est donné, affiche les propriétés pour tous les datasets.

        -r Affiche les propriétés des enfants du dataset.
        -d depth Affiche récursivement les enfants du dataset, en limitant la profondeur de la récursion.
        -H Sort dans un format plus facile à parser par les scripts
        -o field Définis les champs à afficher, parmi: name,property,value,received,source,all
        -s source Liste de sources à afficher. chaque source doit être un parmi: local,default,inherited,temporary,received,none
        -p Affiche les nombres en valeurs parsable (exactes)

zfs inherit [-rS] property filesystem|volume|snapshot ... Efface les propriétés spécifiée, forcant l'héritage du parent.

        -r Hérite récursivement de la propriété donnée pour tous les enfants
        -S Revient à la valeur de propriété reçue si possible.

zfs upgrade [-v] affiche une liste de systèmes de fichiers qui ne sont pas à la dernière version
zfs upgrade [-r] [-V version] [-a | filesystem] Met à jours les systèmes de fichiers à une version plus récente. En générale, la version est dépendante de la version du pool.

        -a Met à jours tous les systèmes de fichier dans tous les pools importés
        filesystem Met à jours le système de fichier spécifié
        -r Met à jours le système de fichier spécifié et tous ses descendants.
        -V version Met à jours à la version spécifiée.

zfs userspace [-niHp] [-o field[,...]] [-sS field]... [-t type [,...]] filesystem | snapshot Affiche l'espace consommé, et les quotas, de chaque utilisateur dans le système de fichier spécifié ou le snapshot. Cela correspond aux propriétés userused@user et userquota@user

         -n Affiche l'ID numérique au lieu du nom
        -H Sort dans un format plus facile à parser par les scripts
        -p Affiche les nombres en valeurs parsable (exactes)
        -o field Définis les champs à afficher, parmi: type,name,used,quota. Défaut: affiche tous les champs
        -s field Trie la sortie par ce champs. Peut être spécifié plusieurs fois.
        -S field idem, mais trie dans l'ordre inverse
        -t type[,...] Affiche seulement les types spécifiés du jeu suivant: all,posixuser,smbuser,posixgroup,smbgroup. Défaut: posixuser,smbuser
        -i Traduit SID en POSIX ID.

zfs groupspace [-niHp] [-o field[,...]] [-sS field]... [-t type [,...]] filesystem | snapshot Affiche l'espace consommé, et les quotes, pour chaque groupe dans le système de fichier spécifié ou le snapshot. Cette sous commande est identique à zfs userspace, excepté que le type d'affichage pas défaut est -t posixgroup,smbgroup
zfs mount Affiche tous les systèmes de fichiers montés
zfs mount [-vO] [-o options] -a | filesystem Monte les systèmes de fichiers ZFS. Invoqué automatiquement durant le processus de démarrage

        -o options liste d'options de montage à utiliser temporairement
        -O montage overlay
        -v Reporte la progression du montage
        -a Monte tous les systèmes de fichiers zfs disponible.
        filesystem Monte le système de fichier spécifié

zfs unmount [-f] -a | filesystem|mountpoint Démonte les systèmes de fichiers zfs. Invoqué automatiquement durant le processus d'arrêt

        -f Force à démonter tous les systèmes
        -a Démonte tous les systèmes de fichiers zfs
        filesystem|mountpoint Démonte le système de fichier spécifié.

zfs share -a | filesystem Partage un système de fichier zfs

        -a Partage tous les systèmes de fichier zfs. Invoqué automatiquement durant le processus de démarrage
        filesystem Partage le systèmes de fichier en accord avec les propriétés sharenfs et sharesmb.

zfs unshare -a | filesystem|mountpoint Ne partage plus les systèmes de fichier zfs. Invoqué automatiquement durant le processus d'arrêt

        -a dé-partage tous les systèmes de fichier zfs
        filesystem|mountpoint dé-partage le système de fichier spécifié

zfs send [-DvRp] [-[iI] snapshot] snapshot Créé une représentation flux du second snapshot, qui est écris sur la sortie standard. La sortie peut être redirigée dans un fichier ou sur un système différent.

        -D Effectue un traitement dedup sur le flux.
        -i snapshot génère un flux incrémentale depuis le premier snapshot dans le second. La source incrémentale (le premier snapshot) peut être spécifié comme dernier composant du nom du snapshot (par exemple, la partie après le @ ), et il est assumé être du même système de fichier que le second snapshot. Si la destination est un clone, la source peut être le snapshot d'origine, qui doit être spécifié en entier (ex: pool/fs@origin).
        -I snapshot Génère un package flux qui envoie tous les snapshots intermédiaire depuis le premier snapshot jusqu'au second.
        -R Génère un package flux de réplication, qui va répliquer le système de fichier spécifié, et tous les systèmes de fichier descendants, jusqu'au snapshot nommé. Toutes les propriétés, snapshots, systèmes de fichiers descendants et clones sont préservés. Si -i et -I sont utilisé avec -R, un flux de réplication incrémentale est généré.
        -p Envoie les propriétés
        -v Affiche des informations sur le flux généré.

zfs receive [-vnFu] filesystem|volume|snapshot
zfs receive [-vnFu] [-d | -e] filesystem Crée un snapshot dont le contenu est spécifié dans le flux fournis sur l'entrée standard. Si un flux complet est reçu, le nouveau système de fichier est créé également.
Si un flux incrémentale est reçu, le système de destination doit déjà exister, et son snapshot le plus récent doit matcher la source du flux incrémentale. Pour les zvols, le lien du périphérique de destination est détruit et recréé, ce qui signifie que le zvol ne peut être accédé durant l'opération.
Quand un flux de réplication de snapshot généré par zfs send -R est reçu, tout snapshot qui n'existent pas dans l'emplacement d'origine est détruit via zfs destroy -d.
Le nom du snapshot (et du système de fichier, si un flux complet est reçu) que cette sous-commande créé dépends du type d'argument et des options -d ou -e.
Si l'argument est un nom de snapshot, il est créé. Si l'argument est un système de fichier ou un nom de volume, un snapshot avec le même nom que le snapshot envoyé est créé dans le système de fichier ou le volume spécifié. Si l'option -e ou -d est spécifiée, le nom du snapshot est déterminé en ajoutant le nom du snapshot au système de fichier spécifié. Si -d est spécifié, tous sauf le nom du pool du snapshot envoyé est ajouté. (ex: b/c@1 ajouté depuis a/b/c@1), et si -e est spécifié, seul la fin du chemin est ajouté (ex: c@1).

        -d Utilise tout sauf le premier élément du chemin du snapshot envoyé pour déterminer le nom du nouveau snapshot.
        Utilise le dernier élément du chemin du snapshot envoyé pour déterminer le nom du nouveau snapshot.
        -u Le système de fichier qui est associé avec le flux reçu n'est pas monté
        -v Affiche des informations sur le flux et le temps requis pour effectuer l'opération.
         -n Ne reçoit pas le flux. Utile avec -v pour vérifier le nom.
        -F Force le rollback du système de fichier au snapshot le plus récent avant d'effectuer l'opération.

zfs allow filesystem | volume Affiche les permissions qui ont été délégués dans le système de fichier spécifié ou le volume.
zfs allow [-ldug] "everyone"|user|group[,...] perm|@setname[,...] filesystem| volume
zfs allow [-ld] -e perm|@setname[,...] filesystem | volume Délègue les permissions d'administration ZFS pour les systèmes de fichier à des utilisateurs non-privilégiés.

        [-ug] "everyone"|user|group[,...] Spécifie à que des autorisation sont déléguées. Plusieurs entités peuvent être spécifiées. Si -u et -g n'est pas spécifié, l'argument est interprété préférentiellement pour tout le monde, puis comme nom d'utilisateur, et enfun comme nom de groupe. Pour spécifier un utilisateur ou un groupe nommé "everyone", utiliser -u ou -g. Pour spécifier un groupe avec le même nom que l'utilisateur, utiliser l'option -g.
        [-e] perm|@setname[,...] Spécifie les permissions à déléguer à "everyone". Plusieurs permissions peuvent être spécifiée. Les noms de permission sont les même que la même sous-commande ZFS ou nom de propriété. Voir la liste plus bas. Les noms de jeu de propriété, qui commencent par @, peuvent être spécifiés.
        [-ld] filesystem|volume Spécifie où les permissions sont déployées. Si -l et -d n'est pas pécifié, ou les 2 le sont, les permissions sont permises pour le système de fichier ou le volume, et tous ses descendants. Il seul -l est utilisé, c'est permis localement seulement pour le système de fichier spécifié. Si seul -d est utilisé, c'est permis seulement pour les systèmes de fichiers descendants.

Les permissions sont généralement la capacité d'utiliser une sous-commande ou changer une propriété zfs. Les permissions suivantes sont permises:
NAME_____________TYPE__________ NOTES
allow____________subcommand_____Doit également avoir la permission qui est permise
clone____________subcommand_____Doit également avec la capacité 'create' et 'mount' dans le système de fichier d'origine
create___________subcommand_____Doit également avoir la capacité 'mount'
destroy__________subcommand_____Doit également avoir la capacité 'mount'
hold_____________subcommand_____Permet d'ajouter un utilisateur maintenu dans un snapshot
mount____________subcommand_____Permet de monter/démonter des datasets
promote__________subcommand_____Doit également avoir les capacités 'mount' et 'promote' dans le système de fichie d'origine
receive__________subcommand_____Doit également avoir les capacités 'mount' et 'create'
release__________subcommand_____Permet d'enlever un user qui peut détuire le snapshot
rename___________subcommand_____Doit également avec la capacité 'create' et 'mount' dans le nouveau parent
rollback_________subcommand
send_____________subcommand
share____________subcommand_____Permet de partager des systèmes de fichier sur NFS ou SMB
snapshot_________subcommand
groupquota_______other__________Permet d'accéder à toutes les propriétés groupquota@...
groupused________other__________Permet de lire toutes les propriété groupused@...
userprop_________other__________Permet de changer toute propriété utilisateur
userquota________other__________Permet d'accéder à toutes les propriétés les userquota@...
userused_________other__________Permet de lire toutes les propriétés userused@...
aclinherit_______property
aclmode__________property
atime____________property
canmount_________property
casesensitivity__property
checksum_________property
compression______property
copies___________property
dedup____________property
devices__________property
exec_____________property
logbias__________property
mlslabel_________property
mountpoint_______property
nbmand___________property
normalization____property
primarycache_____property
quota____________property
readonly_________property
recordsize_______property
refquota_________property
refreservation___property
reservation______property
secondarycache___property
setuid___________property
shareiscsi_______property
sharenfs_________property
sharesmb_________property
snapdir__________property
utf8only_________property
version__________property
volblocksize_____property
volsize__________property
vscan____________property
xattr____________property
zoned____________property

zfs allow -c perm|@setname[,...] filesystem|volume Définis les permission "create time". Ces permission sont données localement au créateur d'un nouveau système de fichier descendant créé.
zfs allow -s @setname perm|@setname[,...] filesystem|volume Définis ou ajoute des permissions à un jeu de permission. Le jeu peut être utilisé par d'autres commande zfs allow pour le système de fichier spécifié et ses descendants. Les jeux sont évalués dynamiquement, donc changer un set est reflété dynamiquement. Les jeux de permission suivent les même restrictions de nommage que les systèmes de fichiers ZFS, mais le nom doit commencer par '@' et ne peut pas faire plus de 64 caractères.
zfs unallow [-rldug] "everyone"|user|group[,...] [perm|@setname[, ...]] filesystem|volume
zfs unallow [-rld] -e [perm|@setname [,...]] filesystem|volume
zfs unallow [-r] -c [perm|@setname[,...]] filesystem|volume Supprime les permissions qui ont été données avec la commande zfs allow. Aucune permissions n'est explicitement refusée, donc les permissions données restent effectives. Si aucune permission n'est spécifiée, toutes les permissions pour l'utilisateur, groupe, ou everyone sont supprimés. Spécifier everyone ou l'option -e supprime seulement les permissions qui ont été donnée à everyone.

        -r Supprime récursivement les permissions dans le système de fichier et ses descendants

zfs unallow [-r] -s @setname [perm|@setname[,...]] filesystem|volume Supprime les permissions d'un jeu de permissions. Si aucune permission n'est spécifiée, supprime toutes les permissions et supprime le jeu.
zfs hold [-r] tag snapshot... Ajoute une référence simple, nommée avec l'argument tag, au snapshot ou aux snapshots spécifiés Chaque snapshot a son propre espace de nom de tag, et les tags doivent être unique dans cet espace. Si un hold existe dans un snapshot, tenter de détruire ce snapshot en utilisant zfs destroy retourne EBUSY.

        -r Spécifie qu'un hold avec le tag donné est appliqué récursivement aux snapshots de tous les systèmes de fichiers descendants.

zfs holds [-r] snapshot... Liste toutes les références utilisateurs existant pour un snapshot donné

        -r Liste les holds qui sont définis dans les snapshots descendants nommés, en plus de lister les holds dans le snapshot nommé.

zfs release [-r] tag snapshot... Supprime une simple référence, nommée avec l'argument tax, du ou des snapshots spécifiés. Le tag doit déjà exister.

        -r Supprime récursivement un hold dans les snapshots et tous les système de fichier descendants.

Exemples

Créer une hiérarchie de système de fichier zfs:
zfs create pool/home
zfs set mountpoint=/export/home pool/home
zfs create pool/home/bob
Créer un snapshot ZFS. Ce snapshot est monté à la demande dans le .zfs/snapshot dans le système de fichier pool/home/bob:
zfs snapshot pool/home/bob@yesterday
Créer et détruire plusieurs snapshots:
zfs snapshot -r pool/home@yesterday
zfs destroy -r pool/home@yesterday
Désactive et active la compression de système de fichier
zfs set compression=off pool/home
zfs set compression=on pool/home/anne
Lister les datasets
zfs list
Définir un quota dans un système de fichier
zfs set quota=50G pool/home/bob
Lister les propriétés ZFS:
zfs get all pool/home/bob
Lister une simple propriété
zfs get -H -o value compression pool/home/bob
Liste toutes les propriété avec les paramètres locaux:
zfs get -r -s local -o name,property,value all pool/home/bob
Rollback un système de fichier
zfs rollback -r pool/home/anne@yesterday
Créer un clone:
zfs clone pool/home/bob@yesterday pool/clone
Détacher un clone:
zfs create pool/project/production
zfs snapshot pool/project/production@today
zfs clone pool/project/production@today pool/project/beta
zfs promote pool/project/beta
zfs rename pool/project/production pool/project/legacy
zfs rename pool/project/beta pool/project/production
zfs destroy pool/project/legacy
Hériter des propriétés ZFS:
zfs inherit checksum pool/home/bob pool/home/anne
Répliquer les données ZFS à distance:
zfs send pool/fs@a | ssh host zfs receive poolB/received/fs@a
poolB doit contenir le système de fichier poolB/received et ne doit pas contenir initialement pooB/received/fs
zfs send -i a pool/fs@b | ssh host zfs receive poolB/received/fs
Utiliser zfs receive -d
zfs send poolA/fsA/fsB@snap | ssh host zfs receive -d poolB/received
Définir les propriétés utilisateurs:
zfs set com.example:department=12345 tank/accounting
Créer un volume ZFS comme target iSCSI:
zfs create -V 2g pool/volumes/vol1
zfs set shareiscsi=on pool/volumes/vol1
iscsitadm list target
Maintenir un historique de snapshots dans un schéma de nommage consistant:
zfs destroy -r pool/users@7daysago
zfs rename -r pool/users@6daysago @7daysago
zfs rename -r pool/users@5daysago @6daysago
zfs rename -r pool/users@yesterday @5daysago
zfs rename -r pool/users@yesterday @4daysago
zfs rename -r pool/users@yesterday @3daysago
zfs rename -r pool/users@yesterday @2daysago
zfs rename -r pool/users@today @yesterday
zfs snapshot -r pool/users@today
Définis la propriété sharenfs dans un système de fichier zfs:
zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home
Déléguer les permissions d'administration dans un dataset:
zfs allow cindys create,destroy,mount,snapshot tank/cindys
zfs allow tank/cindys
Parce que les permissions du point de montage tank/cindys est à 755 par défaut, cindys ne sera pas capable de monter les systèmes de fichier sous tank/cindys. Définir une ACL similaire à la syntaxe suivante:
chmod A+user:cindys:add_subdirectory:allow /tank/cindys
Déléguer la permission create time dans un dataset:
zfs allow staff create,mount tank/users
zfs allow -c destroy tank/users
zfs allow tank/users
Définir et donner un jeu de permission dans un dataset:
zfs allow -s @pset create,destroy,snapshot,mount tank/users
zfs allow staff @pset tank/users
zfs allow tank/users
Déléguer les permissions de propriété dans un dataset:
zfs allow cindys quota,reservation users/home
zfs allow users/home
Supprimer les permissions déléguer dans un dataset:
zfs unallow staff snapshot tank/users
zfs allow tank/users
^
16 janvier 2015

htmlpdflatexmanmd




zfs-fuse

zfs-fuse

Service de système de fichier ZFS

OPTIONS

-p filename --pidfile filename Écris le PID du service dans filename. Ignoré si --no-daemon est passé.
-n, --no-daemon Ne passe pas en tâche de fond.
--no-kstat-mount Ne monte pas kstats dans /zfs-kstat
--disable-block-cache Active les opération disque direct E/S. Désactive complètement les caches de lecture et d'écriture dans le cache de block du kernel.
--disable-page-cache Désactive le cache de page pour les fichiers résidant dans les systèmes de fichiers ZFS. Non recommandés, ralentis les opération.
-a SECONDS --fuse-attr-timeout SECONDS Définis le timeout pour le cache des attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 40%
 -e SECONDS --fuse-entry-timeout SECONDS Définis le timeout pour le cache d'attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 10000%, mais crées de problèmes de sécurité dans la vérification des permissions de fichier.
--log-uberblocks Logs uberblocks de tous les systèmes de fichiers montés dans syslog
-m MB --max-arc-size MB Force la taille maximum ARC ( en mégaoctets). (de 16 à 16384)
-o OPT... --fuse-mount-options OPT,OPT,OPT... Définis les options de montage FUSE pour tous les systèmes de fichiers.
-u MIN --min-uberblock-txg MIN Saute les uberblocks avec un TXG ‹ MIN en montant les fs
-v MB --vdev-cache-size MB Ajuste la taille du cache vdev. défaut 10.
--zfs-prefetch-disable Désactive le cache prefetch de haut niveau dans zfs. peut consommer jusqu'à 150Mo de ram, voir plus.
--stack-size=size Limite la taille de pile des threads en Kb. Défaut: pas de limite (8Mo pour Linux)
-x --enable-xattr Active le support pour les attributs étendus. Généralement non recommandé parce que cela impacte significativement les performances.

Notes

   Les paramètres passés sur la ligne de commande ont précédence sur ceux fournis dans /etc/zfs/zfsrc.
^
16 janvier 2015

htmlpdflatexmanmd




zfsrc

zfsrc

Fichier de configuration pour zfs-fuse

vdev-cache-size Ajuste la taille du cache vdev. défaut 10.
max-arc-size Force la taille maximum ARC ( en mégaoctets). (de 16 à 16384)
zfs-prefetch-disable Désactive le cache prefetch de haut niveau dans zfs. peut consommer jusqu'à 150Mo de ram, voir plus.
disable-block-cache Active les opération disque direct E/S. Désactive complètement les caches de lecture et d'écriture dans le cache de block du kernel.
disable-page-cache Désactive le cache de page pour les fichiers résidant dans les systèmes de fichiers ZFS. Non recommandés, ralentis les opération.
enable-xattr Active le support pour les attributs étendus. Généralement non recommandé parce que cela impacte significativement les performances.
fuse-attr-timeout Définis le timeout pour le cache des attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 40%
fuse-entry-timeout Définis le timeout pour le cache d'attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 10000%, mais crées de problèmes de sécurité dans la vérification des permissions de fichier.
fuse-mount-options Définis les options de montage FUSE pour tous les systèmes de fichiers.
stack-size Limite la taille de pile des threads en Kb. Défaut: pas de limite (8Mo pour Linux)

^
16 janvier 2015

htmlpdflatexmanmd




zpool

zpool

Configure des pools de stockage ZFS

Description

   Un pool de stockage est une collection de périphériques qui fournissent un stockage physique et une réplication de données pour les datasets ZFS. Tous les datasets dans un pool de stockage partagent le même espace.

   Un périphérique virtuel (vdev) décrit un simple périphérique ou une collection de périphériques organisés en accord avec certaines caractéristiques de performances et panne. Les périphériques virtuels suivants sont supportés:

disk Un périphérique block, typiquement localisé sous /dev/dsk. ZFS peut utiliser individuellement des slices ou des partitions, mais le mode d'opération recommandé est d'utiliser des disques entiers. Un dique peut être spécifié par un chemin complet, ou il peut être un nom cour ( la partie relative à /dev/dsk). Un disque entier peut être spécifié en omettant le slice ou la partition. par exemple, "c0t0d0" est équivalent à "/dev/dsk/c0t0d0s2". En donnant un disque entier, ZFS lablel automatiquement le disque, si nécessaire.
file Un fichier régulier. L'utilisation de disques régulier est fortement découragé. Il est conçu principalement à des fins expérimentaux.
mirror Un mirroir de 2 ou plusieurs disques. Les données sont répliquées de manière identique dans tous les composant d'un mirroir. Un mirroir avec N disques et taille X peut maintenir X octets et peut résister à N-1 panne de périphériques avant que l'intégrité des données soient compromise.
raidz
raidz1
raidz2
raidz3 Une variation du RAID-5 qui permet une meilleur distribution de la parité et élimine les trous d'écriture des RAID-5 (dans lequel les données et la parité deviennent inconsistants avec une coupure de courant). Les données et la parité sont placés dans tous les disques dans un groupe raidz.
Un groupe raidz peut avoir une parité simple, double ou triple, signifiant que le groupe raidz peut survivre à 1, 2, ou 3 erreurs, respectivement, sans perte de données. raidz est un alias de raidz1.
Un group raidz avec N disques de taille X avec P disques de parité peut maintenir approximativement (N-P)*X octets et peut résister à P pannes de périphériques avec que l'intégrité des données soit compromise. Le nombre minimum de périphériques dans un group raidz est un de plus que le nombre de disque de parité. Le nombre recommandé est entre 3 et 9 pour améliorer les performances.
spare Un pseudo vdev spécial qui conserve la trace de disques de rechange à chaud pour un pool.
log Un périphérique de log séparé. Si plus d'un périphérique de log sont spécifiés, les écritures sont load-balancés entre les disques. Les périphériques de log peuvent être en mirroir. Cependant, les vdev raidz ne sont pas supportés.
cache Un périphérique utilisé comme cache de données. Un périphérique cache ne peut pas être configuré comme mirroir ou groupe raidz.

   Les périphériques virtuels ne peuvent pas être imbriqués, donc un périphérique mirroir ou raidz ne peut contenir que les fichiers et des disques. Les mirroirs de mirroirs ou d'autres combinaisons ne sont pas permises.

   Un pool peut avoir n'importe quel nombre de périphériques virtuels en haut de la configuration ( "root vdevs" ). Les données sont dynamiquement distribués dans tous les périphériques de haut niveau pour load-balancer dans les périphériques. Comme avec les nouveaux périphériques virtuels, ZFS place automatiquement les données dans les nouveaux périphériques disponibles.

   Les périphériques virtuels sont spécifié une à la fois dans la ligne de commande, séparés par des espaces blancs. Les mots clé "mirror" et "raidz" sont utilisé pour distinguer où un groupe se termine et où un autre commence.

Par exemple, pour créer 2 vdev root, chaque en mirroir de 2 disques:
zpool create mypool mirror c0t0d0 c0t1d0 mirror c1t0d0 c1t1d0

Erreur disque et récupération

   ZFS supporte plusieurs mécanismes pour gérer les erreurs disques et la corruption de données. Toutes les métadonnées et les données sont hashé, et ZFS répare automatiquement les mauvaises données depuis une bonne copie quand une corruption est détectée.

   Pour pouvoir utiliser ces fonctionnalités, un pool doit utiliser une certaine forme de redondance, en utilisant soit des groupes mirroir ou raidz. Bien que ZFS supporte les configuration non-redondantes, où chaque vdev root est simplement un disque ou un fichier, c'est fortement découragé.

   Le status de santé d'un pool est décris par un de ces 3 états: online, degraded, faulted. Un pool online a tous ses périphériques fonctionnant normalement. Un pool dégradé est un pool dans lequel un ou plusieurs périphériques sont en échec, mais les données continuent d'être disponibles grâce à la configuration de la redondance. Un pool faulted est un pool qui a une corruption de méta-données, un ou plusieurs périphériques en erreur, et des réplicas insuffisant pour continuer à fonctionner.

   La santé du vdev top-level, tel un mirror ou un raidz, est potentiellement impacté par l'état de ses vdev associés, ou ses périphériques. Un vdev top-level ou un composant périphérique est dans un de ces états:

DEGRADED

- Un ou plusieurs vdev top-level sont en état dégradés à cause d'un ou plusieurs composants périphérique offline. Des réplicas suffisants existent pour continuer à fonctionner.
- Un ou plusieurs composants périphérique et est en état dégradé ou faulted, mais des réplicas suffisants existent pour continuer à fonctionner. Les conditions sous-jacentes sont les suivantes:

        - Le nombre d'erreurs de checksums excède le niveau acceptable et le périphérique est dégradé en indication que quelque chose ne va pas. ZFS continue d'utiliser le périphérique si nécessaire.
        - Le nombre d'erreur E/S excède le niveau acceptable. Le périphérique ne pourrait pas être marqué en faulted parce qu'il y'a suffisamment de réplicas pour continuer à fonctionner.

FAULTED

- Un ou plusieurs vdev top-level sont à l'état faulted à cause d'un ou plusieurs composants périphérique offline. Les réplicas existant sont insuffisant pour continuer à fonctionner.
- Un ou plusieurs composant périphérique sont à l'état faulted, et des réplicas existant sont insuffisant pour continuer à fonctionner. Les conditions sous-jacentes sont les suivantes:

        - Le périphérique peut être ouvert, mais son contenu ne matche par les valeurs attendues
        - Le nombre d'erreur d'E/S excède un niveau acceptable et le périphérique est faulted pour empêcher son utilisation.

OFFLINE

- Le périphérique a été explicitement mis offline par la commande zpool offline

ONLINE

- Le périphérique est online et fonctionnel

REMOVED

- Le périphérique a été physiquement supprimé alors que le système fonctionnait. La détection de la suppression de disque est dépendant du hardware et peut ne pas être supporté par toutes les plateformes.

UNAVAIL

- Le périphérique ne peut pas être ouvert. Si un pool est importé quand un périphérique est indisponible, le périphérique sera identifié par un identifiant unique au lieu de son chemin vu que le chemin n'est jamais correct.

   Si un périphérique est supprimé puis ré-attaché plus tard dans le système, ZFS tente de placer le périphérique automatiquement en online. La détection de périphérique attaché est dépendant du hardware et peut ne pas être supporté par toutes les plateformes.

Hot Spares

   ZFS permet aux périphériques d'être associés avec des pools en hot spare avec la commande zpool add et supprimés avec la commande zpool remove. Une fois un spare initialisé, un nouveau vdev spae est créé dans la configuration qui va rester jusqu'à ce que le périphérique original soit remplacé. À ce point, le hot spare deviendra disponible si un autre périphérique échoue.

   Si un pool a un spare partagé qui est actuellement utilisé, le pool ne peut pas être exporté vu que d'autre pools peuvent utiliser ce spare partagé.

   Tout spare en progression de remplacement peut être annulé en détachant le hot spare. Si le périphérique faulted est détaché, le hot spare assume sa place dans la configuration, et est supprimé de la liste de spare pour tous les pools actifs.

   Les spares ne peuvent pas replacer les périphériques logs

Intent Log

   ZFS Intent Log (ZIL) satisfait les pré-requis POSIX pour les transactions synchrones. Actuellement, les bases de données nécessitent que leur transactions soient sur des périphériques de stockage stables en retournant depuis un appel système. NFS et d'autres applications peuvent également utilis fsync() pour s'assurer de la stabilité des données. Par défaut, le intent log est alloué dans les blocks du pool principal. Cependant, il peut être possible d'obtenir de meilleurs performances en utilisant des périphériques séparés pou les logs tel que NVRAM ou un disque dédié.

Par exemple:
zpool create pool c0d0 c1d0 log c2d0

   Plusieurs périphériques de log peuvent également être spécifiés, et ils peuvent être mirrorés. Les périphériques de log peuvent être ajoutés, remplacés, attachés, détachés, et importés/exportés comme partie d'un grand pool. Les logs mirrorés peuvent être supprimés en spécifiant le mirror top-level pour les logs.

Cache Devices

   Des périphériques peuvent être ajoutés à un pool de stockage comme périphérique de cache. Ces périphériques fournissent une couche additionnelle de cache entre la mémoire principale et le disque. Pour des opérations de lecture intensive, utiliser des périphériques cache fournis les meilleurs performances.

Pour créer un pool avec des périphériques cache, spécifier un vdev cache avec des périphériques. par exemple:
zpool create pool c0d0 c1d0 cache c2d0 c3d0

   Les périphériques cache ne peuvent pas être mirrorés dans une configuration raidz. Si une erreur de lecture est rencontrée dans un périphérique cache, cette lecture est refaite dans le pool originale, qui peut faire partie d'une configuration mirror ou raidz. Le contenu des périphériques cache est considéré volatile.

Processus

   Chaque pool importé a un processus associé, nommé zpool-‹poolname›, les threads dans ce processus sont les threads de traitement E/S du pool, qui manipulent la compression, checsums, et d'autre tâches pour toutes les opération d'E/S associées avec le pool. Ce processus existe pour fournir un visibilité dans l'utilisation CPU. L'existence de ce processus est une interface instable.

Propriétés

   Chaque pool a de nombreuses propriétés. Certaines propriétés sont des statistiques lecture-seule alors que d'autre sont configurables. Les propriétés lecture-seules sont:

alloc Quantité d'espace de stockage dans le pool qui a été physiquement alloué.
capacity % de l'espace du pool utilisé.
deduplication Ration de déduplication spécifié pour un pool, exprimé comme multiplicateur. ex: 1.76 indique que 1.76 unité de donnée sont stockés mais seulement 1 unité de l'espace disque est consommé.
free Nombre de blocks dans le pool qui ne sont pas alloués.
guid Identifiant unique pour le pool
healt Santé actuel du pool.
size Taille totale du pool de stockage

   Ces propriétés d'utilisation de l'espace reportent l'espace physique actuellement disponible dans le pool. l'espace physique peut être différent de la taille totale d'espace que tout datasets peut utiliser actuellement. La quantité d'espace utilisé dans une configuration raidz dépend de ses caractéristiques. En plus, ZFS réserve de l'espace en interne que la commande zfs prend en compte, mais pas la commande zpool. Pour les pools non-pleins d'une taille raisonnable, ces effets devraient être invisibles. pour les petits pools, ou les pools qui sont presques pleins, ces écart peuvent devenir plus perceptibles.

   Les propriétés suivantes peuvent être définis à la création:

ashift Exposant de taille de secteur du pool, en puissance de 2. Les opérations I/O seront alignés à cette taille. Additionnellement La taille d'écriture disque minimum sera définis à la taille spécifiée, ce qui représente un compromis espace/performance. Le cas typique pour définir cette propriété est quand les performances sont importante et que les disques utilisent des secteurs 4KiB mais reportent des secteurs de 512 octets à l'OS pour des raisons de compatibilité; dans ce cas, définis ashift=12 ( 1‹㙘 == 4096 ). Vu que les grands disques ont des secteurs 4K depuis 2011, ZFS utilise ashift=12 par défaut pour tous les disques supérieurs à 512Go. Pour des raisons de performances, la taille de secteur devrait être égal ou supérieur à la taille de secteur.

   Les propriétés suivantes peuvent être définis à la création et à l'import:

altroot Répertoire root alternatif. Si définis, ce répertoire est ajouté à tout point de montage dans le pool. Cela peut être utilisé en examinant un pool inconnu où les points de montage ne peuvent pas être validés, ou dans un environnement de boot alternatif, où les chemins typiques ne sont pas valides. altroot n'est pas une propriété persistante. Elle est valide seulement quand le système est up.

   Les propriétés suivantes peuvent être définis à la création, à l'import et avec la command zpool set:

autoexpand=on | off Contrôle l'expansion automatique du pool quand le LUN sous-jacent grandis. À on, le pool sera redimmensionné en accord avec la taille du périphérique étendu. Si le périphérique fait partie d'un mirror ou un raidz, tous les périphériques dans le groupe doivent être étendus avant que le nouvel espace soit disponible dans le pool. (défaut: off).
autoreplace=on | off Contrôle le remplacement automatique du périphérique. À off, le remplacement de disque doit être initialisé par l'administrateur en utilisant zpool replace. à on, tout nouveau périphérique trouvé dans le même emplacement physique que l'ancien disque appartenant au pool est remplacé et formaté automatiquement. (défaut: off)
bootfs=pool/dataset Identifie le dataset bootable par défaut pour le pool root. Cette propriété est prévue pour être définie principalement par les programmes d'installation et de mise à jours.
cachefile=path | none Contrôle l'emplacement où la configuration du pool est cachée. Découvrir tous les pools au démarrage du système nécessite une copie cachée des données de configuration stockée dans le système de fichier racine. Tous les pools dans ce cache sont automatiquement importés au boot du système. Certains environnements, tels que l'installation et le clustering, nécessitent de cacher cette information dans un emplacement différent et ces pools ne sont pas automatiquement importés. Définir cette propriété met en cache la configuration du pool dans un emplacement différent et peut être importé ultérieurement avec zpool import -c. Définir la valeur spécial none créé un pool temporaire qui n'est jamais cacé, et la valeur spéciale "" utilise l'emplacement par défaut. Pluiseurs pools peuvent partager le même fichier de cache, mais le kernel détruis et recrée ce fichier quand les pools sont ajoutés ou recréés. quand le dernier poor utilisant cachefile est exporté ou supprimé, ce fichier est supprimé.
delegation=on | off Contrôle si un utilisateur non-privilégié à accès basé sur les permissions de dataset définis dans le dataset.
failmode=wait | continue | panic Contrôle le comportement du système dans l'éventualité d'une erreur catastrophique du pool. Cette condition est typiquement un résultat d'un perte de connectivité aux disques sous-jacents, ou une erreur de tous les disques dans le pool. Le comportement est déterminé comme suit:

        wait Bloque les accès E/S au pool jusqu'à ce que la connectivité au disque soit récupéré et que les erreurs aient été validés. Un pool reste en wait jusqu'à ce que le problème du périphérique soit résolu. C'est le mode par défaut.
        continue Retourne EIO à toute nouvelle demande d'écriture mais permet de lire tous périphérique en cour de fonctionnement.
        panic Affiche un message à la console et génère un crash dump système.

listsnaps=on | off Contrôle si les informations sur les snapshots associés avec ce pool sont affichés quand zfs list est lancé sans l'option -t. ( défaut: off ).
version=version Version courante du pool. Peut être augmenté, mais pas diminué. La méthode préférée pour mettre à jours les pools est avec la commande zpool upgrade. Cette propriété peut être tout nombre entre 1 et la version courante reportée par zpool ugrade -v.

Sous-commandes

   Toutes les sous-commandes qui modifient l'état sont loggés de manière persistante dans le pool dans leur forme original.

zpool add [-fn] [-o property=value] pool vdev ... Ajoute les périphériques virtuel spécifiés dans le pool donné.

        -f Force l'utilisation de vdev, même s'il apparaît en utilisation ou spécifie un conflit au niveau de la réplication.
         -n Affiche la configuration qui serai utilisée sans ajouter le vdev.
        -o property=value Définis les propriétés du pool donné (ashift). N'ajoute pas de disque qui est actuellement configuré comme périphérique quorum à un zpool. Une fois un disque dans le pool, ce disque peut être configuré comme périphérique quorum

zpool attach [-f] [-o property=value] pool device new_device Attache un nouveau périphérique à un zpool existant. Le périphérique existant ne peut pas faire partie d'une configuration raidz. Si device ne fait pas partie actuellement d'une configuration mirror, device se transforme automatiquement en mirror 2-way de device et new_device. Si device fait partie d'un mirror 2-way, attache new_device et créé un mirror 3-way, et ainsi de suite.

        -f Force l'utilisation de new_device, même s'il apparaît en cours d'utilisation.
        -o property=value Définie les propriété du pool donné (ashift).

zpool clear [-F [-n]] pool [device] ... Efface les erreurs disques dans un pool. Si aucun argument n'est spécifié, toutes les erreurs périphériques seront effacés. Si un ou plusieurs périphériques sont spécifiés, n'efface les erreurs que de ces périphériques.

        -F Initie le mode récupération pour un pool inouvrable. Tente d'annuler les dernières transactions dans le pool pour le retourner à un état normal. Tous les pools endommagé ne peuvent pas être récupérés avec cette option.
         -n Utilisé en combinaison avec -F. Vérifie si les transactions annulées renderaient le pool ouvrable, mais n'annule rien.

zpool create [-fn] [-o property=value] ... [-O file-system-property=value] ... [-m mountpoint] [-R root] pool vdev ... Créé un pool contenant les périphériques virtuels spécifié dans la ligne de commande. Le nom du pool doit commencer avec une lettre, et peut contenir des caractères alphanumériques, "_", "-" et ".". Les noms de pool mirror, raidz, spare et log sont réservés, comme les noms commençant par c[0-9]. La commande vérifie que chaque périphérique est accessible et non utilisés.
La commande vérifie également que la stratégie de réplication pour le pool est consistante. Une tentative de combiner des stockage redondant et non-redondants dans un seul pool, ou de mixer des disques et des fichier, cause une erreur sauf si -f est spécifié. L'utilisation de disques de taille différentes dans un simple raidz ou mirror est aussi marqué en erreur sauf si -f est spécifié.
Le point de montage par défaut est /‹pool›. Le point de montage ne doit pas exister ou doit être vide.

        -f Force l'utilisation des vdev, même s'ils apparaissent utilisé ou en conflit de niveau de réplication.
         -n Affiche la configuration qui serait utilisée sans créer le pool.
        -o property=value [-o property=value] ... Définis une propriété du pool
        -O file-system-property=value
        [-O file-system-property=value] ... Définis des propriétés de système de fichier dans le système de fichier root du pool.
        -R root Équivalent à "-o cachefile=none,altroot=root"
        -m mountpoint Définis le point de montage pour de dataset root. Le point de montage doit être un chemin absolu, legacy, ou none.

zpool destroy [-f] pool Détruit le pool donné, libérant les périphériques pour d'autres utilisations. Cette commande tente de démonter tout dataset actif avant de détruire le pool.

        -f Force un dataset actif contenu dans le pool à être démonté.

zpool detach pool device Détache device d'un mirroir. Cette opération est refusé s'il n'y a pas d'autre replica valide.
zpool export [-f] pool ... Exporte les pools donnés du système. Tous les périphériques sont marqués comme exporté, mais sont considérés en utilisation par d'autre sous-systèmes. Les périphériques peuvent être déplacés entre les systèmes et importés tant que le nombre de périphériques suffisant sont disponible.
Avant d'exporter le pool, tous les datasets dans le pool sont démontés. Un pool ne peut pas être exporté s'il a un spare partagé qui est actuellement utilisé. Pour que les pools soient portables, vous devez donner à zpool des disques entiers, pas seulement les slices, pour que zfs puisse labeliser les disques avec des labels EFI portables.

        -f Force à démonter les datasets.

zpool get "all" | property[,...] pool ... Récupère la liste donnée de propriété pour les pools spécifiés. Ces propriétés sont affichés avec les champs suivant:

        name Nom du pool
        property nom de la propriété
        value valeur de la propriété
        source Source de la propriété.

zpool history [-il] [pool] ... Affiche l'historique des commandes des pools spécifiés.

        -i Affiche les évènement ZFS loggé en interne en plus des évènements initiés par l'utilisateur.
        -l Affiche les logs au format long

zpool import [-d dir | -c cachefile] [-D] Liste les pool disponible à l'import. Si l'option -d n'est pas spécifié, cette commande recherche les périphériques dans /dev/dsk. Si le périphérique apparaît comme faisant partie d'un pool exporté, cette commande affiche des informations sur le pool. Les pools détruits, les pools qui ont été précédemment détruis avec zpool destroy, ne sont pas listés sauf si -D est spécifié.

        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou fichiers dans dir. Peut être spécifié plusieurs fois.
        -D Liste les pools détruis uniquement.

zpool import [-o mntopts] [ -o property=value] ... [-d dir | -c cachefile] [-D] [-f] [-R root] [-F [-n]] -a Importe tous les pools trouvés dans les répertoirs de recherche. Identiquement à la commande précédante, excepté que tous les pools avec un nombre suffisant de périphériques sont importés. Les pools détruis, les pools qui ont été précédemment détruis par zpool destroy, ne sont pas importés sauf si -D est spécifié.

        -o mntopts Liste séparée par des ',' d'options de montages à utiliser en montant les datasets dans le pool.
        -o property=value Définis les propriétés spécifiées dans le pool importé.
        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou les fichiers dans dir. Peut être spécifié plusieurs fois. Incompatible avec -c
        -D Importe les pools détruis uniquement. -f est requis
        -f Force l'import, même si le pool apparaît potentiellement actif.
        -F Mode récupération pour un pool non-importable. Tente de retourner le pool à un état importable en annulant les dernière transactions
        -a Recherche et importe tous les pools trouvés
        -R root Définis la propriété cachefile à none, et altroot à root.
         -n Utilisé avec -F. Détermine si un pool non-importable peut être importable, mais ne tente pas la récupération.

zpool import [-o mntopts] [ -o property=value] ... [-d dir | -c cachefile] [-D] [-f] [-R root] [-F [-n]] pool | id [newpool] Import un pool spécifique. Un pool peut être identifié par son nom ou l'identifiant numérique. Si newpool est spécifié, le pool est importé en utilisant le nom newpool. Sinon, il est importé avec le même nom que son nom exporté.
Si un périphérique est supprimé de son système sans utiliser zpool export avant, le périphérique apparaît comme potentiellement actif. Il ne peut pas être déterminé si c'était un export échoué, ou si le périphérique est vraiment en utilisation dans un autre hôte. Pour importer un pool dans cet état, l'option -f est requise.

        -o mntopts Liste séparée par des ',' d'options de montages à utiliser en montant les datasets dans le pool
        -o property=value Définis les propriétés spécifiées dans le pool importé.
        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou les fichiers dans dir. Peut être spécifié plusieurs fois. Incompatible avec -c
        -D Importe les pools détruis uniquement. -f est requis
        -f Force l'import, même si le pool apparaît potentiellement actif.
        -F Mode récupération pour un pool non-importable. Tente de retourner le pool à un état importable en annulant les dernière transactions
        -a Recherche et importe tous les pools trouvés
        -R root Définis la propriété cachefile à none, et altroot à root.
         -n Utilisé avec -F. Détermine si un pool non-importable peut être importable, mais ne tente pas la récupération.

zpool iostat [-T u | d] [-v] [pool] ... [interval[count]] Affiche des statistiques d'E/S pour les pool donnés. En donnant un interval, rafraîchis toutes les interval secondes. Si aucun pool n'est spécifié, affiche pour tous les pools dans le système. Si count est spécifié, la commande se termine après count reports.

        -T u | d Affiche un horodatage.
        -v Statistiques plus complètes.

zpool list [-H] [-o props[,...]] [pool] ... Liste les pools donnés avec un status de santé et d'utilisation de l'espace. Sans argument, tous les pool dans le système sont listés.

        -H Mode scripté. N'affiche pas les headers, et sépare les champs pas une tabulation.
        -o props Liste séparée par des ',' de propriétés à afficher. (name, size, allocated, free, capacity, health, altroot).

zpool offline [-t] pool device ... Place les disques spécifié offline. Cette commande n'est pas applicable pour les caches et spares.

        -t Temporaire. Au reboot, le disque sera replacé à son état précédent.

zpool online [-e] pool device... Place un disque online. Cette commande n'est pas applicable pour les caches et spares.

         -e  Étend le périphérique pour utiliser tous l'espace disque disponible. Si le disque fait partie d'un mirror ou d'un raidz, tous les périphériques doivent être étendus avec que l'espace soit disponible dans le pool.

zpool remove pool device ... Supprime un périphérique du pool. Cette commande supporte seulement la suppression des hot spare, cache, et log.
zpool replace [-f] pool old_device [new_device] Remplace old_device avec new_device. C'est équivalent à attacher new_device, et détacher old_device. La taille de new_device doit être supérieur ou égal à la taille minimum de tous les périphériques dans un mirror ou raidz.
new_device est requis si le pool n'est pas redondant. Si new_device n'est pas spécifié, son défaut est old_device. Cette forme de remplacement est utile après qu'un disque existant ait crashé et a été physiquement remplacé. Dans ce cas, le nouveau disque peut avoir le même /dev/dsk que l'ancien périphérique, même s'il a une taille différente.

        -f Force l'utilisation de new_device, même s'il apparaît en utilisation.

zpool scrub [-s] pool ... Commence un scrub. Le scrub examine toutes les données dans les pools spécifiés pour vérifier qu'ils checksums correctement. Pour les périphériques répliqués, ZFS répare automatiquement tout dommage découvert durant le scrub. zpool status reporte la progression du scrub et affiche des informations sur son avancement.
Le scrubbing et le resilvering sont des opérations très similaires. La différence est que le resilvering examine seulement les données que ZFS sait être hors date (par exemple, en attachant un nouveau disque à un mirroir ou en replaçant un périphérique existantè), alors que le scrubbing examine toutes les données pour découvrir des erreurs dûs à des erreurs matériels ou disque.
Vu que le scrubbing et le resilvering sont des opération d'E/S intensifs, ZFS permet seulement un à la fois. Si un scrub est déjà en progression, zpool scrub se termine et recommence un nouveau scrub. Si un resilver est un progression, ZFS ne permet pas de démarrer un scrub.

        -s Stop le scrubbing

zpool set property=value pool Définis une propriété au pool spécifié.
zpool split [-R altroot] [-n] [-o mntopts] [-o property=value] pool newpool [device ...] Coupe un disque de chaque vdev top-level mirroré en un pool et crée un nouveau pool avec les disques splittés. Le pool original doit être fait d'un ou plusieurs mirroirs et ne doit pas être dans un processus de resilvering. Cette commande choisi le dernier périphérique dans chaque vdev mirror sauf spécification dans la ligne de commande.
En utilisant un argument device, split inclus les périphériques spécifiés dans un nouveau pool, si des périphériques restent non précisés, assigne le dernier périphérique de chaque mirroir vdev à ce pool, comme il le fait normallement. Si vour n'êtes pas certain de la sortie de spécit, utiliser -n pour s'assure que votre command aura l'effet attendus.

        -R altroot Import automatiquement le pool nouvellement créé avec le split, en utilisant le paramètre altroot spécifié.
         -n Affiche ce qu'il va faire, mais ne fait rien
        -o property=value Définis les propriétés spécifiées dans le pool importé.

zpool status [-xv] [pool] ... Affiche des status détaillés sur l'état de santé des pools donnés. Si aucun pool n'est spécifié, alors le status de chaque pool dans le système est affiché. Si un scrub ou un resilver est en cours, cette commande reporte le pourcentage fait et le temps estimé.

        -x Affiche seulement le status des pools qui ont des erreurs ou sont indisponible.
        -v Affiche plus d'information sur les erreurs.

zpool upgrade Affichue tous les pools formattés en utilisant une version ZFS différente. Les anciennes version peuvent continuer à être utilisée mais certaines fonctionnalité ne seront pas disponible. Ce pools peuvent être upgradé en utilisant zpool upgrade -a. Les pools qui sont formatés avec une version plus récente sont également affichés, bien que ces pool sont inaccessible au système.
zpool upgrade -v Affiche les versions ZFS supportés par le logiciel courant. Les versions ZFS courantes et tous les versions précédentes supportées sont affichées.
zpool upgrade [-V version] -a | pool ... Upgrade à a dernière version. Une fois fait le pool ne sera plus accessible aux système fonctionnant avec des versions plus anciennes.

        -a Upgrade tous les pools
        -V version Upgrade à la version spéifiée.

Exemples

Créer un Pool RAID-Z de 6 disques:
zpool create tank raidz c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0
Créer un pool avec 2 mirroirs de 2 disques chacuns.
zpool create tank mirror c0t0d0 c0t1d0 mirror c0t2d0 c0t3d0
Créer un pool en utilisant des slices:
zpool create tank /dev/dsk/c0t0d0s1 c0t1d0s4
Créer un pool en utilisant des fichiers:
zpool create tank /path/to/file/a /path/to/file/b
ajouter un mirroir à un pool:
zpool add tank mirror c1t0d0 c1t1d0
Lister les pools disponibles:
zpool list
Affiche toutes les propriété d'un pool:
zpool get all pool
Détruit un pool
zpool destroy -f tank
Exporte un pool:
zpool export tank
Importe un pool:
zpool import
zpool import tank
Upgrader les pools à la dernière version:
zpool upgrade -a
Gérer un spare:
zpool create tank mirror c0t0d0 c0t1d0 spare c0t2d0
Si un des disques échoue, le pool sera réduit à un état dégradé. le disque défectueux peut être remplacé avec:
zpool replace tank c0t0d0 c0t3d0
Une fois les donnée resilvered, le spare est automatiquement supprimé et de nouveau disponible. Le spare peut être supprimé de manière permanente avec:
zpool remove tank c0t2d0
Créer un pool avec les logs séparés:
zpool create pool mirror c0d0 c1d0 mirror c2d0 c3d0 log mirror c4d0 c5d0
Ajouter des disques cache à un pool:
zpool add pool cache c2d0 c3d0
Une fois ajoutés, les disques cache se remplissent avec le contenu de la mémoire principale. En fonction de la taille des disques, cela peut prendre des heures pour les remplir. La capacité et les lectures peuvent être supervisés avec iostat:
zpool iostat -v pool 5
Supprimer un périphérique log:
zpool remove tank mirror-2
récupérer un pool en faulted, récupérer un pool cache:
zpool clear -F data
sinon utiliser:
zpool import -F data

Codes de sortie

0 succès
1 Une erreur s'est produite
2 Options de ligne de commande invalide.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-Committed

^
16 janvier 2015

htmlpdflatexmanmd




zstreamdump

zstreamdump

Filtre de données dans le flux zfs send

Description

   Lit depuis la sortie de zfs send, et affiche les en-tête et des statistiques.

OPTIONS

-C Supprime la validation des checksums
-v Dump tous les headers, pas seulement les headers de début et de fin.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-____Uncommited