• Sun / Oracle DSEE
• 389DS / Red Hat Directory Server
• Oracle OUD
• Sun OpenDS / Wren DS
• Forgerock OpenDJ
• Ping Directory.

• On traverse le DIT depuis la racine de l'annuaire jusqu'à l'entrée que l'on tente d'accéder
• On collecte toutes les

Depuis quelques temps, je trouve que le temps de démarrage de mon PC sous Ubuntu est bien long... alors que le disque principal est un SSD.

Identifier le temps total de démarrage

Sur les O.S. qui utilisent systemd, il existe une commande permettant de connaître le temps nécessaire au démarrage : systemd-analyze.

Sans option, cette commande donne juste le temps total nécessaire au démarrage, ainsi que le temps après lequel on arrive à l'écran de connexion. Exemple :

Suite au rachat (déjà ancien) de Sun par Oracle, l'annuaire LDAP Sun DSEE, devenu Oracle DSEE depuis, arrive en fin de support. Ce produit a eu ses beaux jours en entreprise, à l'époque c'était probablement l'un des meilleurs, capable de gérer des centaines de milliers d'entrées, avec une architecture assez simple.

Les annuaires LDAP sont principalement utilisés pour gérer 2 types d'objets :

• les comptes utilisateurs (qui vont permettre une authentification centralisée)
• des groupes d'utilisateurs (qui vont permettre une gestion de droits).

D'autres objets annexes sont souvent ajoutés, qui ont un rôle de "listes de valeurs".

Nous allons voir dans cet article les différents types de groupes qui peuvent être utilisés, sachant que selon les RFC LDAP 4519, seuls les premiers sont vraiment standardisés.

Lorsqu'on installe un annuaire LDAP, on crée un compte (souvent "cn=Directory Manager" par défaut) qui a tous les privilèges, qui n'est pas soumis aux ACI, bref, un superAdmin avec tous les privilèges.

Il vaut donc mieux éviter d'utiliser ce compte pour des opérations. On peut toujours utiliser des comptes "utilisateurs", mais dans ce cas, le DN du compte change selon le baseDN.

Si on veut industrialiser le monitoring de l'annuaire, par exemple, il est intéressant d'avoir toujours le même compte, quel que soit l'instance et donc le baseDN.

Petit rappel pour l'ajout d'index sur Sun DSEE

Symptômes

Machine très lente. Dans le log errors :

Contexte

Lors d'une formation sur PingDirectory, le 'lab' sur la sauvegarde / restauration est très simple : on lance une sauvegarde avec l'utilitaire backup, puis une sauvegarde avec restore, sans avoir modifié les données. Trouvant l'exercice peut représentatif, j'ai testé la restauration en ayant au préalable supprimé des entrées. Et, ô surprise, les données n'ont pas été restaurées.

Il ne s'agit pas d'un problème sur le produit, mais d'un problème de processus.

Note : Le problème arrive dans un cas bien particulier, uniquement si on veut faire du multi-instances avec OpenLDAP sur une machine, qui tourne avec un O.S. Ubuntu (testé à partir de 16.04).

Les mêmes actions sur un serveur sous Debian se passent correctement.

Contexte

La configuration et les données sont dans une arborescence :

Pré-requis

Installer sur une distribution Red Hat Enterprise Server 6.x (6.8 dans notre cas). Mode Basic Server

Attention : même sur un système 64 bits, Sun DSEE fonctionne en mode 32 bits. Il faut donc s'assurer d'avoir installé les librairies compatibles.

Pré-requis logiciels

Installer les paquets :

• unzip
• wget
• compat-glibc
• compat-gcc-32
• compat-libstdc++
• libstdc++
• zlib.i686

On utilise yum pour installer tout cela :