OpenIDM, la solution de gestion des identités de Forgerock, va bientôt sortir en version 3.1, avec un grand changement par rapport aux versions précédentes : une interface d'administration / configuration.

Jusqu'ici, la configuration se faisait uniquement via des fichiers Json, ce qui avait l'avantage de pouvoir être facilement versionné, mais plaçait le produit loin de ses compétiteurs quant à l'aspect "interface d'admin".

Dorénavant, il est possible d'avoir une visu des ressources, en se connectant à http://localhost:8080/admin

La mise en place de SSL pour OpenLDAP permet de sécuriser les échanges, que ce soit en utilisant LDAPS ou START/TLS (dans ce dernier cas, la connexion démarre sur le port LDAP et passe ensuite en mode sécurisé).

En préalable, on aura généré une clé privée, récupéré un certificat, ainsi que celui de l'autorité de certification. (voir un article précédent sur le mémento OpenSSL ).

Les étapes pour la sécurisation sont :

J'ai récemment installé un serveur de développement / intégration sur une machine dédiée SP 128 OVH assez "costaud" :

• Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz, 6 cores, 12 threads,
• 128 Go de RAM,
• 2 x 2 To de disque.

La machine est installée avec une distribution linux Ubuntu 14.04 LTS.

Après avoir pas mal "joué" avec les certificats SSL ces derniers temps, pour des besoins de sécurisation d'accès à un annuaire LDAP entre autre, je me fais un petit mémo des commandes les plus utilisées.

OpenSSL permet de gérer les certificats utilisés dans les connexions SSL (https, ldaps, etc.). Sur les O.S. de type Unix/Linux, il est généralement présent dans les dépôts et s'installe facilement :

yum install openssl

ou encore

Par défaut, Drupal permet de "bannir" des adresses IP manuellement, via la console d'administration.

Ceci est une première étape, mais peut vite devenir ingérable sur un site fréquenté. De plus, les requêtes http vont quand même arriver jusqu'au CMS, puisque c'est lui qui gère ces exclusions.

Les droits d'accès sur les objets du DIT OpenLDAP sont contrôlés par des ACL (Access Control List), qui sont stockés au niveau du rootSuffix.

Par exemple, on peut récupérer les règles via une requête telle que :

On parle beaucoup depuis quelques temps de Docker et des containers Linux LXC (https://linuxcontainers.org/), qui permettent d'avoir une approche légère de la virtualisation.

La version 1.0 de LXC est sortie en février 2014, et est incluse dans la plupart des distributions Linux.

Il est très facile de créer une machine, la cloner, la lancer en mode éphémère (qui ne conserve pas les modifications), et la détruire via des commandes :

Redmine est un outil de gestion de projets / tickets Web, utilisant Ruby on Rails. C'est un outil très puissant, qui s'intègre bien avec les autres briques du SI, telles qu'un annuaire LDAP pour l'authentification centralisée et des gestionnaires de sources, tels que SVN ou GIT.

Il est assez facile de récupérer la consommation totale de mémoire sur un serveur Linux/Unix, via la commande free par exemple :

free -m
             total       used       free     shared    buffers     cached
Mem:          5963       3516       2446          0        194       1161
-/+ buffers/cache:       2160       3802
Swap:         4095          7       4088

On voit ici que l'on utilise 3516 Mo sur 5963 disponibles, mais que sans la mémoire utilisée par les buffers et caches, on n'en prend que 2160 (la deuxième colonne de la deuxième ligne).

En cas de souci d'espace disque sur certaines partitions, il est possible de déplacer des DataFiles oracle. La démarche étant la suivante (dans l'ordre) :

• Récupérer le nom du fichier utilisé par le tablespace
• Mettre le tablespace en mode Offline
• Copier le fichier de données dans son nouveau répertoire
• Modifier le tablespace pour renommer le fichier de données
• Remettre le tablespace en mode Online
• Supprimer le fichier d'origine

Ce qui se résume de la manière suivante :