server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0)
by Mikael Kermorgant
Hello,
We've recently migrated our old FDS 1.0.2/FC4 setup to a new one
hosted on a xen virtualised FC10. The dom0 is centos 5.3 and 389
server version is 1.2.1.
It has been working about a week, but we have recently faced some crashes.
First ones were the day after a schema modification on the master
which had not been weel propagated on the slaves. This could be the
explanation but I'm not really sure as it worked well several hours.
The last one was today when using the console.
Problem is we have no logs. Server suddenly freezes and is no more
available via ssh , vnc or xen console.
Would somebody have an idea about which steps to debug this situation ?
Could it be that virtualizing FC1 on Centos 5.3 was a bad idea ?
Regards,
--
Mikael Kermorgant
14 years, 6 months
Result of replication
by Emmanuel BILLOT
Hi,
We monitor replication between 389DS servers and AD servers. What does
this filed real mean ?
What does those numbers mean ?
Number of changes : 1:130/0
BR,
--
==========================================
Emmanuel BILLOT
IRD - Orléans
Délégation aux Systèmes d'Information (DSI)
tél : 02 38 49 95 88
==========================================
14 years, 6 months
Windows Sync
by Emmanuel BILLOT
Hi,
Windows Sync does not work.
We use administrtor account to bind.
Extract from log :
02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state
before 4ac618150001:1254496277:0:0
[02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state
after 4ac6181a0000:1254496282:0:0
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin -
ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000000010000
into pending list
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin -
csn=4ac6181a000000010000 process postop: canceling operation csn
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of
entry uid=zizou,ou=People,ou=orleans,dc=ird,dc=fr returned: 32
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: CN=Duplicateurs,CN=Builtin,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: CN=Administrateurs de l'entreprise,CN=Users,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: CN=jean bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry
matching AD entry [CN=jean bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr]
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by
guid [6615b9abafd05c4da997ca3c89b7ab1b]
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by uid
[bon]
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: problem looking for username: -1
[02/Oct/2009:17:11:22 +0200] - Windows sync entry: Adding new local
entry dn: uid=bon,ou=People,ou=orleans,dc=ird,dc=fr
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDeleteAccount: true
uid: bon
sn: bon
givenName: jean
cn: jean bon
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: bon
ntUniqueId: 6615b9abafd05c4da997ca3c89b7ab1b
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin -
ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000100010000
into pending list
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin -
csn=4ac6181a000100010000 process postop: canceling operation csn
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of
entry uid=bon,ou=People,ou=orleans,dc=ird,dc=fr returned: 32
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry
matching AD entry [OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr]
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by
guid [6bb1176df971904f9e2ea760d58ac3b3]
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): map_entry_dn_inbound: AD entry has no username!
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): windows_process_dirsync_entry: failed to map inbound
entry OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr - rc is -1 dn is [null].
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: CN=Administrateurs du schéma,CN=Users,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: CN=Admins du domaine,CN=Users,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from
dirsync: OU=ORLEANS,DC=maqird,DC=fr
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Beginning linger on the connection
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): windows_tot_run: failed to obtain data to send to
the consumer; LDAP error - 32
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): No linger to cancel on the connection
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Disconnected from the consumer
[02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): State: start -> ready_to_acquire_replica
[02/Oct/2009:17:11:22 +0200] - acquire_replica, supplier RUV:
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier:
{replicageneration} 4a1e8d0b000000010000
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier: {replica
1 ldap://obiwan:389} 4a1e9575000000010000 4ac616f7000100010000 4ac616f8
[02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV:
[02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV = null
[02/Oct/2009:17:11:23 +0200] - acquire_replica, supplier RUV is newer
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Trying secure slapi_ldap_init_ext
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): binddn = cn=administrateur,cn=Users,dc=maqird,dc=fr,
passwd = {DES}NfWmOGRvsgfwJqTMBJagtA==
[02/Oct/2009:17:11:23 +0200] - windows_conn_connect : detected Win2k3 peer
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): No linger to cancel on the connection
[02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state
before 4ac6181a0002:1254496282:0:0
[02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state
after 4ac6181b0000:1254496283:0:0
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin -
windows_acquire_replica returned success (101)
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): State: ready_to_acquire_replica -> sending_updates
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Replica has no update vector. It has never been
initialized.
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Beginning linger on the connection
[02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x"
(maqsvrdc0001:636): Linger timeout has expired on the connection
--
==========================================
Emmanuel BILLOT
IRD - Orléans
Délégation aux Systèmes d'Information (DSI)
tél : 02 38 49 95 88
==========================================
14 years, 6 months
Upgrading OS from FC9 to FC10
by James Roman
I am attempting to upgrade my FreeIPA server from Fedora 9 (Fedora-ds-base 1.2.0-4) to Fedora 10 (389-ds-base 1.2.2-1). I have been running into problems with the directory server during the upgrade.
Prior to the upgrade process I am stopping the directory server and using chkconfig to ensure that it does not start after the upgrade. The oS upgrade goes seemingly without a hitch. At first boot, the FC9 directory server packages are still installed. I perform a "yum update" which indicates that the fedora-ds-package will be replaced with the 389 package (Not sure if this means upgrade or not, but the fedora-ds-base package is definitely removed).
When I try to manually start the directory server I receive the following errors:
[04/Oct/2009:19:40:35 -0400] - All database threads now stopped
[04/Oct/2009:19:41:37 -0400] - slapd shutting down - signaling operation threads
[04/Oct/2009:19:41:37 -0400] - slapd shutting down - closing down internal subsystems and plugins
[04/Oct/2009:19:41:38 -0400] - Waiting for 4 database threads to stop
[04/Oct/2009:19:41:38 -0400] - All database threads now stopped
[04/Oct/2009:19:41:38 -0400] - slapd stopped.
389-Directory/1.2.2 B2009.237.206
directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM)
[05/Oct/2009:01:46:34 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up
[05/Oct/2009:01:46:34 -0400] - Clean up db environment and start from archive.
[05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6
[05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6
[05/Oct/2009:01:46:36 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES
[05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init
[05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher AES in attrcrypt_init
[05/Oct/2009:01:46:37 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES
[05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init
[05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher 3DES in attrcrypt_init
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - Upgrading from bdb/4 to bdb/4.7/libreplication-plugin is successfully done (/var/lib/dirsrv/slapd-REALM-COM/cldb)
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:01:46:37 -0400] - Error: Failed to resolve plugin dependencies
[05/Oct/2009:01:46:37 -0400] - Error: object plugin Legacy Replication Plugin is not started
[05/Oct/2009:01:46:37 -0400] - Error: object plugin Multimaster Replication Plugin is not started
389-Directory/1.2.2 B2009.237.206
directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM)
[05/Oct/2009:01:58:17 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up
[05/Oct/2009:01:58:17 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database.
[05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES
[05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init
[05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher AES in attrcrypt_init
[05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES
[05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init
[05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher 3DES in attrcrypt_init
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:01:58:19 -0400] - Error: Failed to resolve plugin dependencies
[05/Oct/2009:01:58:19 -0400] - Error: object plugin Legacy Replication Plugin is not started
[05/Oct/2009:01:58:19 -0400] - Error: object plugin Multimaster Replication Plugin is not started
Fedora-Directory/1.2.0 B2009.118.167
directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM)
[05/Oct/2009:02:49:56 -0400] - Fedora-Directory/1.2.0 B2009.118.167 starting up
[05/Oct/2009:02:49:56 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database.
[05/Oct/2009:02:49:57 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES
[05/Oct/2009:02:49:57 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init
[05/Oct/2009:02:49:57 -0400] - Failed to initialize cipher AES in attrcrypt_init
[05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:02:49:57 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument
[05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog
[05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb
[05/Oct/2009:02:49:58 -0400] - Failed to start object plugin Multimaster Replication Plugin
[05/Oct/2009:02:49:58 -0400] - Error: Failed to resolve plugin dependencies
[05/Oct/2009:02:49:58 -0400] - Error: object plugin Legacy Replication Plugin is not started
[05/Oct/2009:02:49:58 -0400] - Error: object plugin Multimaster Replication Plugin is not started
I have two replica servers installed, one a FC10 DS 1.2.2 and one a windows domain controller.
I have backed up basically everything in multiple formats (db2bak, ldif, tar). I am going to have to roll the server back to FC9 for the evening. Anyone have any ideas how to eliminate the errors, or perform the upgrade in a way that avoids them? Do I need to remove the replication agreements first?
James Roman
Sr. Network Administrator
TerraNet, Inc. on Contract to SSAI
14 years, 6 months
389 certificate issues...
by Trey Sheldon
Hello all,
I've been evaluating and prepping to deploy 389 for a couple months
now and while working on my final deployment I've run into a snag...
I created two servers and successfully enabled SSL on them. I'm
attempting to create a third using the exact same procedure and can't
seem to get SSL enabled.
I used the admin-gui to install the request / install the certs and
roots.
##WORKING
#certutil -L -d .
Certificate Nickname Trust
Attributes
SSL,S/
MIME,JAR/XPI
Metaweb Root Certificate CT,,
Metaweb Host Root Certificate CT,,
server-cert u,u,u
# certutil -L -d . -n server-cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 88 (0x58)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: ........ <full certificate>
## NOT WORKING
# certutil -L -d .
Certificate Nickname Trust
Attributes
SSL,S/
MIME,JAR/XPI
Metaweb Root Certificate CT,,
Metaweb Host Root Certificate CT,,
server-cert u,u,u
# certutil -L -d . -n server-cert
certutil: Could not find: server-cert
: security library: bad database.
These systems are automatically deployed and configured and should
have identical package revisions and configurations. I'm at a blank
to what is causing the problem. Any insight that people have would
be *greatly* appreciated.
Sincerely,
Trey SHeldon
14 years, 6 months
posixGroup and 389 DS
by Andreas Andersson
Hi!
I have a question related to Linux authentication and authorization
against 389 DS.
Hope someone out there has experience about connecting Linux Server to
389 DS.
What I have done is creating posixAccounts, default account groups and
several groups used for admin rights.
First I tried using uniqueMember=<dn> as member reference attribute on
each posix group. It only works with less than 600 users and isn't
ideal as nss_ldap seems to treat the attribute uniqueMember as an
account _or_ a group and runs additional queries on each uniqueMember
found within the group.
Instead I have tested to use memberUid=<uid>. Works much better! No
additional queries. But... I would prefer using full DN as reference
within the directory.
Now over to my questions:
Has anyone successfully used uniqueMember as member attribute for
linux authentication? With several thousands of users ?
Are there any documented "best practices" to setup linux
authentication and authorization against 389? I may have missed them
on Google :) ?
Anyone with experience... I need all feedback I can get right now and
are looking for a long-term working solution.
Best Regards - Andreas
Examples of my idea of using posixGroups (that doesn't do the the
additional queries using memberUid):
# Account:
dn: uid=aandersson,ou=People,dc=domain,dc=com
objectClass: top
objectClass: organizationalPerson
objectClass: person
objectClass: posixaccount
gidNumber: 1000
homeDirectory: /home/aandersson
uidNumber: 1000
gecos: Andreas Andersson
loginShell: /bin/bash
givenName: Andreas
uid: aandersson
cn: Andreas Andersson
sn: Andersson
Default Group:
#dn: cn=aandersson,ou=Groups,dc=domain,dc=com
objectClass: posixGroup
objectClass: top
gidNumber: 1000
cn: aandersson
description: Default group for 'aandersson'
Member Group:
#dn: cn=adminmembers,ou=Groups,dc=domain,dc=com
memberUid: aandersson
memberUid: jdoe
memberUid: jsmith
gidNumber: 1002
description: Linux Administrators
objectClass: top
objectClass: posixGroup
cn: adminmembers
14 years, 6 months
one-way winsync
by Prashanth Sundaram
Dear 389-ds community,
I have a question about windows sync agreement. Here¹s the scenario:
two Windows DC¹s and two 389-ds servers as below.
Question1: Can I setup a one-way winsync i.e from windows to ldap? I have
tried it and it was like hit or miss. I did this by not giving the ³write²
permissions to AD for ³CN=Sync Manager². Is this valid way of sync-ing one
way? I have error messages ³Replica has no update vector. It has never been
initialized². I did a full-resynchronization and it went well without
errors. But I am not seeing any entry updates.
Question2: If I have windows sync on both the 389-ds sync-ing to a diferent
DC. Does it cause any loop or issues. The problem I am facing is, that I
have different OU¹s in AD like ou=Marketing, ou=Finance, ou=Customers and
only one ³ou=People² in 389-ds.
I want only one-way sync. AD-->389-ds
Topology I am trying to make work. Please share your comments.
|--------| |------- |
| DC-1 | <---replication----> | DC-2 |
|--------| |--------|
| |
winsync Winsync
| |
|---------| |-------- |
| 389-1 | <---replication----> | 389-2 |
|---------| |---------|
Thanks,
Prashanth
14 years, 6 months
389 unusable on F11?
by Kevin Bowling
Hi,
I have been running FDS/389 on a F11 xen DomU for several months. I use
it as the backend for UNIX username/passwords and also for redMine (a
Ruby on Rails bug tracker) for http://www.gnucapplus.org/.
This VM would regularly lock up every week or so when 389 was still
called FDS. I've since upgraded to 389 by issuing 'yum upgrade' as well
as running the 'setup-...-.pl -u' script and now it barely goes a day
before crashing. When ldap crashes, the whole box basically becomes
unresponsive.
I left the Xen hardware console open to see what was up and the only
thing I could conclude was that 389 was crashing (if I issued a service
start it came back to life). Doing anything like a top or ls will
completely kill the box. Likewise, the logs show nothing at or before
the time of crash. I suspected too few file descriptors but changing
that to a very high number had no impact.
I was about to do a rip and replace with OpenLDAP which I use very
sucesessfully for our corporate systems but figured I ought to see if
anyone here can help or if I can submit any kind of meaningful bug
report first. I assume I will need to run 389's slapd without
daemonizing it and hope it spits something useful out to stderr. Any
advice here would be greatly appreciated, as would any success stories
of using 389 on F11.
I'm not subscribed to the list so please CC.
Regards,
Kevin Bowing
14 years, 6 months