389-users October 2009

389-users@lists.fedoraproject.org

38 participants
49 discussions

Read data immediately after write
by Ankur Agarwal 13 Oct '09

13 Oct '09

Hi, I have a master-slave set-up with write operations always being done to the master node. Now there is an issue where i need to read some data immediately after write, and my read request goes to the slave. It fails in cases when replication hasnt happened from master to slave before this read operation. Is there a LDAP level configuration to handle this situation? Can chaining help in this case? Any help would be appreciated. Cheers, Ankur

3 5

db2ldif as non root user
by Mitja Mihelič 13 Oct '09

13 Oct '09

Greetings all fellow Fedora Directory Server users! Is it possible to dump the database to an LDIF file as a non-root user ? I have no problem doing this as root. I would like to run /usr/lib/dirsrv/slapd-example/db2ldif -a /tmp/dbdump.ldif -n userRoot from a remote machine via ssh and I would really like to avoid connecting to the machine as root. Has anyone had any experience in doing this if it is at all possible ? Thank you.

2 3

Re: [389-users] Windows Sync precision
by Emmanuel BILLOT 13 Oct '09

13 Oct '09

Emmanuel BILLOT a écrit : > Hi, > > I'm currently on fight with AD replication and synchronization. I need > to know if a non default synchronization (as it is porposed in the > agrment assistant) is possible. > I mean, is it possible to synchronize > > - users in this case : > ou=people,dc=toutou,dc=tagada,dc=org (DS) with > ou=utilisateurs,ou=toutou,dc=tagada,dc=fr (AD) > > and groups like this > ou=group,dc=toutou,dc=tagada,dc=org (DS) with > ou=groupes,ou=toutou,dc=tagada,dc=fr (AD) > > Note that OU are different, suffix are different too. > > I had ti create two different agrements because of OU naming (people > vs utilisateurs and group vs groupes), so one agrement for each object > type. > I succeed in synchronizing users, but for groups, i have an error : > > dn="<GUID=2313f95309633645bd2396aa959bea46>" or > dn="CN=pfffff,OU=groupes,OU=ORLEANS,DC=maqird,DC=fr" > [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - > agmt="cn=orl_group" (maqsvrdc0001:636): windows_replay_update: > Processing modify operation local > dn="cn=pfffff,ou=group,dc=orleans,dc=ird,dc=fr" remote > dn="<GUID=2313f95309633645bd2396aa959bea46>" > [12/Oct/2009:11:58:03 +0200] - map_dn_values: this entry is not ours > uid=aubertin,ou=People,dc=orleans,dc=ird,dc=fr > [12/Oct/2009:11:58:03 +0200] agmt="cn=orl_group" (maqsvrdc0001:636) - > clcache_load_buffer: rc=-30989 > [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - > agmt="cn=orl_group" (maqsvrdc0001:636): No more updates to send > (cl5GetNextOperationToReplay) > > It seems that the agrement does not recognize the user entry because > it is stored in a different subtree (the subtree for agrement is > ou=group,dc=orleans,dc=ird,dc=fr, the subtree for user is > ou=people,dc=orleans,dc=ird,dc=fr). > > Is it right ? > Users and Group synch is it only possible when users and groups are in > the same agrement ? > If true, how can we do if OU naming is so different ? > > I hope somebody will answer, > > BR, > > > I had no answer, somebody have an idea ? -- ========================================== 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 precision
by Emmanuel BILLOT 12 Oct '09

12 Oct '09

Hi, I'm currently on fight with AD replication and synchronization. I need to know if a non default synchronization (as it is porposed in the agrment assistant) is possible. I mean, is it possible to synchronize - users in this case : ou=people,dc=toutou,dc=tagada,dc=org (DS) with ou=utilisateurs,ou=toutou,dc=tagada,dc=fr (AD) and groups like this ou=group,dc=toutou,dc=tagada,dc=org (DS) with ou=groupes,ou=toutou,dc=tagada,dc=fr (AD) Note that OU are different, suffix are different too. I had ti create two different agrements because of OU naming (people vs utilisateurs and group vs groupes), so one agrement for each object type. I succeed in synchronizing users, but for groups, i have an error : dn="<GUID=2313f95309633645bd2396aa959bea46>" or dn="CN=pfffff,OU=groupes,OU=ORLEANS,DC=maqird,DC=fr" [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - agmt="cn=orl_group" (maqsvrdc0001:636): windows_replay_update: Processing modify operation local dn="cn=pfffff,ou=group,dc=orleans,dc=ird,dc=fr" remote dn="<GUID=2313f95309633645bd2396aa959bea46>" [12/Oct/2009:11:58:03 +0200] - map_dn_values: this entry is not ours uid=aubertin,ou=People,dc=orleans,dc=ird,dc=fr [12/Oct/2009:11:58:03 +0200] agmt="cn=orl_group" (maqsvrdc0001:636) - clcache_load_buffer: rc=-30989 [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - agmt="cn=orl_group" (maqsvrdc0001:636): No more updates to send (cl5GetNextOperationToReplay) It seems that the agrement does not recognize the user entry because it is stored in a different subtree (the subtree for agrement is ou=group,dc=orleans,dc=ird,dc=fr, the subtree for user is ou=people,dc=orleans,dc=ird,dc=fr). Is it right ? Users and Group synch is it only possible when users and groups are in the same agrement ? If true, how can we do if OU naming is so different ? I hope somebody will answer, 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 with multiple sub DIT
by Emmanuel BILLOT 09 Oct '09

09 Oct '09

Hi, We use 389DS and AD with a Winsync method. Our LDAP DIT : * dc=toutou,dc=fr ** dc=orleans,dc=toutou,dc=fr *** ou=people,dc=orleans,dc=toutou,dc=fr *** ou=group,dc=orleans,dc=toutou,dc=fr ** dc=bondy,dc=toutou,dc=fr *** ou=people,dc=bondy,dc=toutou,dc=fr *** ou=group,dc=bondy,dc=toutou,dc=fr Our AD DIT : * dc=toutou,dc=org ** ou=orleans,dc=toutou,dc=org *** ou=utilisateurs, ou=toutou, dc=ird,dc=org *** ou=groupes, ou=toutou,dc=ird,dc=org One can see some OU names are different, such as DIT root. So we cretaed a sync agrement as ou=people,dc=orleans,dc=toutou,dc=fr --- ou=utilisateurs, ou=toutou, dc=ird,dc=org All seems to be ok. However, we need to sync other subtrees, like ou=people,dc=bondy,dc=toutou,dc=fr It seems 389DS wants to syncronize high level entries which are not specified in the agrement. As it tries to do it for each sub agrement, failure occurs with a duplicate value error. How can we do ? Log [08/Oct/2009:15:26:31 +0200] NSMMReplicationPlugin - agmt="cn=win bdy" (maqsvrdc0001:636): Replica has no update vector. It has never been initialized. [08/Oct/2009:15:26:33 +0200] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=win bdy" (maqsvrdc0001:636)". [08/Oct/2009:15:26:33 +0200] - add value "" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=toutou,DC=org" failed: duplicate new value [08/Oct/2009:15:26:34 +0200] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=win bdy" (maqsvrdc0001:636)". Sent 0 entries. -- ========================================== Emmanuel BILLOT IRD - Orléans Délégation aux Systèmes d'Information (DSI) tél : 02 38 49 95 88 ==========================================

2 2

Announcing testing release of 389 1.2.3
by Rich Megginson 09 Oct '09

09 Oct '09

The 389 team is pleased to announce that the 389 Directory Server version 1.2.3 is available for testing. The packages are available from the testing repositories, not the official release repositories yet. We are seeking feedback. The two new packages available for testing are: * 389-ds-base-1.2.3 * 389-admin-1.1.9 Instructions for installing these from the testing repositories: yum install --enablerepo=updates-testing 389-ds # Fedora new install yum upgrade --enablerepo=updates-testing 389-ds-base 389-admin 389-console # Fedora upgrade or EL5 yum install --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing 389-ds # new install yum upgrade --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing 389-ds-base 389-admin 389-console # upgrade See http://directory.fedoraproject.org/wiki/Download for more information about setting up yum access. Release Notes: http://directory.fedoraproject.org/wiki/Release_Notes Install Guide: http://directory.fedoraproject.org/wiki/Install_Guide Download: http://directory.fedoraproject.org/wiki/Download === Notes === NOTE: If using the FC6 (EL5) packages, _you must update your yum repo files_ - the URLs have changed. See http://directory.fedoraproject.org/wiki/Download for more information. NOTE: Fedora versions below 10 are no longer supported. If you are running Fedora 9 or earlier, you should upgrade. NOTE: This release is branded as '''389'''. All of the RPMs have been marked as obsoleting their Fedora DS counterparts. When upgrading via yum, you must use yum '''upgrade''' (not update) so that the obsoletes will be processed. NOTE: If you are using the console, after installing the updates, you must run '''setup-ds-admin.pl -u''' to refresh your console and admin server configuration with the new version information. 1.2.3 fixes some bugs related to update - it will remove old Fedora servers from the console, and will preserve TLS/SSL configuration. See the buglist below. NOTE: '''389-console''' is the command to run the console. This replaces fedora-idm-console. === New features === * Ability to set resource limits (sizelimit, timelimit, look through limit) specifically for anonymous connections ** This is useful when you want to have different limits for regular users and anonymous users ** Set the attribute '''nsslapd-anonlimitsdn''' in cn=config to the DN of the entry that you want to use as the "template" entry. This is a dummy entry that you have to create. Then you set whatever resource limits you want to apply to anonymous to that dummy entry, and those limits will apply to anonymous users. * Access based on the security strength of the connection ** There is a new ACI keyword - '''minssf''' - this allows you to set access control based on how secure the connection is ** There is a global server setting in cn=config - '''nsslapd-minssf''' - that allows you to reject operations based on how secure the connection is * Ability to shut off anonymous access ** This adds a new config switch in cn=config - '''nsslapd-allow-anonymous-access''' - that allows one to restrict all anonymous access. When this is enabled, the connection dispatch code will only allow BIND operations through for an unauthenticated user. The BIND code will only allow the operation through if it's not an anonymous or unauthenticated BIND. === Bugs Fixed === This release contains several bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.3 release - [https://bugzilla.redhat.com/showdependencytree.cgi?id=519216&hide_resolved=0 https://bugzilla.redhat.com/showdependencytree.cgi?id=519216&hide_resolved=0]

1 0

Problem creating new Organizational Unit
by Anthony M. Farrell 07 Oct '09

07 Oct '09

389 DS 1.2.2 on RHEL 5.4 xen virtualguest This is a new installation. When using the console to try and create a new OU entry the process fails with the output message: netscape.LDAPException error result (65); unknown object class "posixuser"; Object class violation Where does "posixuser" come from? Everything else is working fine. I would appreciate any ideas on how to resolve this? TF -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 6

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

07 Oct '09

Trying again? I am attempting to upgrade my 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 OS 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 -- 389 users mailing list 389-users(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users

2 1

GOsa on 389 Directory Server
by Greg Miller 07 Oct '09

07 Oct '09

This is my first foray into LDAP, so please be gentle... I am attempting to install GOsa over the top of a fresh 389 install on CentOS 5.3. It seems that GOsa provides a simple way to administer virtually every aspect of a Linux network with an LDAP server. Maybe 389's own tools can do this, too, and I just don't know it. Anyway, I have copied the GOsa schema files into the 389 Directory Server's schema directory. I renamed all of the GOsa schema files to begin with "90", so that 389 would load them. When I restart 389, I receive numerous error messages in the log: [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=gofax,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=gofon,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=gosa-samba2,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=gosa-samba3,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=goserver,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=gosystem,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=goto-mime,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=goto,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=rfc2307bis,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=samba,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=samba3,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] <https://oss.gonicus.de/labs/gosa/changeset/02/Oct/2009%3A06%3A00%3A26%20-05…> - Entry "cn=trust,cn=schema,cn=config" has unknown object class "olcSchemaConfig" From the little info I can find on the Internet, olcSchemaConfig seems to be an OpenLDAP-specific setting. I can't seem to find a comparable setting for 389 Directory Server in any of 389's schema files. I have posted this question to GOsa's forums, but nobody there uses 389. Does anyone have any advice for me on this matter? Thanks!

2 1

Deleting entries that are not modified recently
by Kimmo Koivisto 05 Oct '09

05 Oct '09

Hello I'm using fedora-ds-1.0.4-1.RHEL4 and I have an application that creates and modifies entries located in FDS. Application does not remote old entries, and I cannot change how application works. I would like to delete entries that are not modified recently with either plain ldapsearch+ldapdelete or using some FDS tools, perl scipt etc. So, my question is, what is the easiest way to delete entries, for example older that 3 months? Regards, Kimmo

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2009