Ecrit le 21-02-2009 (814 hits) ... section Services
Dans le cas où le service de OpenLDAP, à savoir slapd (sous /etc/init.d/slapd) refuse de démarrer avec une erreur de Berkeley DB (BDB).
Exemple, si on a le message:
 |
bdb_db_open: alock package is unstable
backend_startup_one: bi_db_open failed! (-1)
slapd stopped
|
Cela signifie que le programme ne parvient pas à obtenir l'accès aux fichiers de base de données.
C'est soit un problème de droit sur les fichiers de base de données (le owner n'est pas le user dédié à openldap), soit un problème de droit sur le répertoire lui-même.
Cela arrive par exemple si on crée la base LDAP en lançant le serveur slapd en console, sous un user comme root ;-) sous Debian, la commande
|
chown openldap /var/lib/ldap/*
|
résouds le problème, elle rétablit la propriété au user de slapd qui est "openldap".
/var/lib/ldap/ est le répertoire précisé dans l'option "database" dans le fichier /etc/ldap/slapd.conf.
Commenter (0 commentaire(s)) |
|
Ecrit le 21-02-2009 (1356 hits) ... section Services
Si on installe un service OpenLDAP et qu'on configure le serveur pour résoudre les noms d'utilisateurs et de groups sur la base LDAP (gràce à NSS via /etc/nsswitch.conf), il apparait des erreurs au cours du démarrage de la machine. Même si le service LDAP fonctionne parfaitement. Du genre (extraits de logs pris au hasard): > udevd[xxx]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1: Can't contact LDAP server
> udevd[xxx]: nss_ldap: could not search LDAP server - server is unavailable
> udevd[xxx]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)
> udevd[xxx]: nss_ldap: could not search LDAP server - Can’t contact LDAP server
> udevd[xxx]: lookup_group: error resolving group 'xxx': illegal seek
Ce problème apparait sur une Debian Etch, une Lenny, et je pense que c'est identique sous Ubuntu. Ci-dessous voici comment j'ai résolu le problème. Commenter (0 commentaire(s)) |
|
Lire la suite...
|
|
Ecrit le 27-01-2009 (787 hits) ... section Objets distribués
Comment réaliser des applications Corba (ou J2EE) qui fonctionnent à travers Internet, à travers des VPN, à travers des translations d'adresses NAT?
Il existe des solutions, la plus évidente est de réaliser un pont vers les Web services (SOAP sur HTTP), qui sont une réponse à la difficulté de déploiement d'application Corba sur Internet.
Il est possible également d'utiliser des tunnels SSL. Mais ceci ne résoud pas les problèmes liées aux translations d'adresses (NAT), car pour information l'adresse IP est contenue dans le nom unique IOR d'un objet Corba. Commenter (0 commentaire(s)) |
|
Lire la suite...
|
|
|
|
<< Début < Précédente 1 2 3 4 5 Suivante > Fin >>
|
| Résultats 1 - 13 sur 58 |
)
