389-users October 2009

389-users@lists.fedoraproject.org

38 participants
49 discussions

server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0)
by Mikael Kermorgant 05 Oct '09

05 Oct '09

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

2 5

which platform to choose
by Mikael Kermorgant 05 Oct '09

05 Oct '09

Hello, After having used 389 directory server 1.2.1 in a virtualized environment based on a fedora core 11 xen domU over a centos 5.3 dom0, and faced some rare and random crashes, I'd like to change our setup. Our main distributions which we'd like to use are debian lenny, centos, and we're seriously testing xenserver 5.5 which supports both. I've read in the past that it was recommended to use FC6 binaries when using centos 5, but I can't find the page anymore. Moreover, I've found some howtos with different setups : * http://wiki.centos.org/HowTos/DirectoryServerSetup?action=show&redirect=How…. * http://www.linuxmail.info/389-directory-server-setup-howto-centos-5/ * http://www.howtoforge.com/centos-directory-server-on-centos5.2 >From what I've read, I prefer the first one as it comes from centos' own wiki. Any opinion against that ? Do you know if there are issues with replication with fedora ds on other fedora boxes ? Regards, -- Mikael Kermorgant

2 1

Result of replication
by Emmanuel BILLOT 05 Oct '09

05 Oct '09

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 ==========================================

1 0

Windows Sync
by Emmanuel BILLOT 05 Oct '09

05 Oct '09

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 ==========================================

1 1

Upgrading OS from FC9 to FC10
by James Roman 04 Oct '09

04 Oct '09

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

1 0

389 certificate issues...
by Trey Sheldon 02 Oct '09

02 Oct '09

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

3 2

posixGroup and 389 DS
by Andreas Andersson 01 Oct '09

01 Oct '09

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

1 0

one-way winsync
by Prashanth Sundaram 01 Oct '09

01 Oct '09

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

1 0

389 unusable on F11?
by Kevin Bowling 01 Oct '09

01 Oct '09

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

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2009