Sauvegarde et restauration Ping Directory dans une topologie répliquée

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.

OpenDJ : mise en place du suivi des connexions

Par défaut, il n'est pas possible de déterminer la date de dernière connexion réussie sur un annuaire LDAP (last login time). Seules les erreurs de connexion peuvent être détectées dans les politiques de mots de passe.

Parfois cependant, il est intéressant de connaître la date de dernière connexion, afin de pouvoir supprimer - ou bloquer - des comptes inutilisés depuis plusieurs mois.

Installation Sun DSEE sur Red Hat

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 :

OpenLDAP : mise en place de la réplication

Mise en place de la réplication dans OpenLDAP

La plupart du temps, les annuaires LDAP sont paramétrés avec une réplication entre deux serveurs, afin d'apporter une meilleure disponibilité ou permettre une montée en charge horizontale, via la mise en place d'un répartiteur de charge en frontal.

Situation de base

Un serveur installé en tant que master : openldap1.arciam.fr. Il écoute sur le port 389. L'overlay syncprov a été chargé en tant que module , via la configuration :

Mise en place de Splunk sur des logs LDAP

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.

Changer le nom du site (URL) de Wordpress

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.

Wordpress : utiliser WP-CLI pour gére wordpress en ligne de commande

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.

Les ACL dans OpenLDAP

Principes généraux

Les ACL dans OpenLDAP peuvent se trouver à 2 niveaux, database ou backEnd, sachant qu'il est assez courant d'avoir un backend par database (ou vice-versa).

Les ACL sont donc généralement positionnées dans la configuration de la database.

Syntaxe

La syntaxe globale est :

olcAccess: to [ressource]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]

Un exemple de base, qui limite l'accès à l'attribut userPassword :