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 :

Lors de l'envoi de mails à partir d'un domaine vers une adresse gmail, le message arrive dans les SPAMS.

Identification de la cause

Si on choisit "Afficher l'original" dans les options du message, on a quelque chose du type :

Introduction & contexte

Par défaut, les attributs d'un annuaire OpenLDAP ne sont pas indexés. Comme dans une base de données, ceci peut impacter les performances de l'annuaire, en introduisant des full scan qui balaient toutes les entrées. Il est possible, comme sur une base de données, de créer des index sur certains attributs, pour améliorer la vitesse de recherche.
Toutefois, les index ont également un inconvénient : lors des mises à jour, l'index doit être recalculé, et ceci peut être pénalisant, notamment lors de modifications en masse.

Par défaut, ITIM utilise la time-zone de WebSphere, qui n'étant pas définie, peut être différente de l'heure du serveur.

Nous avons eu le souci sur une installation en Russie : le paramétrage des réconciliations utilisait l'heure française :

Dans la série des overlays pour OpenLDAP, après le Password Policy, regardons l'accesslog.

Intérêt de l'overlay Accesslog

L'overlay Accesslog peut être utile pour récupérer dans une branche séparée de l'annuaire un ensemble d'opérations appliquée sur une database.

Le paramétrage distingue 4 sortes d'opérations :

Suite à une alerte de sécurité Drupal (PSA-2014-001), j'ai procédé à la mise à jour du module Media 7.1.x, et de File_entity, qui est compris dans ce module.

Problème en retournant sur les pages, une belle erreur :

Libération de la RAM utilisée pour le cache

Par défaut, Linux a tendance à utiliser toute la RAM pour accélérer ses opérations, et notamment pour y placer en cache ses données.

On peut donc arriver facilement à des situations où la RAM est utilisée à 90% ou plus, alors que les traitements n'en prennent que la moitié.

Par exemple, sur un serveur disposant de 7,5 Go de mémoire, la commande free -m donne :

Lors de l'installation d'une instance OwnCloud, j'ai pris les options par défaut, avec une base SQLite3.

Ceci est visible dans le fichier de configuration :

Modification de la longueur d'un attribut ITDS

Lors du lancement d'un traitement sur un annuaire IBM Tivoli Directory Server (ITDS), on remarque ceci dans les logs (ibmslapd.log) :

07/11/2013 03:26:23 PM GLPRDB069E Attribute IIRUSERATTRIB8 has a maximum value length of 240. Current attribute value is of length 242.

Voyons ce que dit le schéma de l'annuaire :