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 :

Dans une architecture LDAP de production, on met généralement en place plusieurs instances d'annuaires, qui sont répliquées entre elles. L'inconvénient dans ce cas est que les logs sont répartis sur chaque serveur, et qu'il devient difficile d'avoir une vue d'ensemble des opérations.

Il existe cependant des solutions de centralisation, aggrégation et visualisation de données. Les plus connues étant Splunk et ELK.

Contrairement à Drupal, Wordpress stocke dans sa base de données l'URL complète du site. Ceci inclut également le protocole (http ou https).

Du coup, en cas de passage d'un site en https, ou du transfert d'un site de développemnt en production (avec changement d'URL, par exemple de dev.monsupersite.org en www.monsupersite.org), on perd une grande partie du contenu (média, éventuellement CSS).

Il est possible de résoudre le problème, avec Search-Replace-DB-master. C'est un ensemble de scripts php.

Autant pour Drupal, l'outil drush est très connu et permet de simplifier et d'accélérer les choses (installation de modules, mises à jour, nettoyage du cache), autant il semble que l'utilisation de la ligne de commande pour Wordpress n'est pas très répandu.

Cependant, il existe un outil wp-cli, qui fournit des fonctionnalités relativement semblables.

Je ne reprends pas ici toutes les commandes, vous pouvez vous référer au site d'origine.