Read data immediately after write
by Ankur Agarwal
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
14 years, 6 months
db2ldif as non root user
by Mitja Mihelič
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.
14 years, 6 months
Re: [389-users] Windows Sync precision
by Emmanuel BILLOT
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
==========================================
14 years, 6 months
Windows Sync precision
by Emmanuel BILLOT
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
==========================================
14 years, 6 months
Windows Sync with multiple sub DIT
by Emmanuel BILLOT
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
==========================================
14 years, 6 months
Announcing testing release of 389 1.2.3
by Rich Megginson
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]
14 years, 6 months
Problem creating new Organizational Unit
by Anthony M. Farrell
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.
14 years, 6 months
Upgrading OS from FC9 to FC10
by James Roman
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
14 years, 6 months
GOsa on 389 Directory Server
by Greg Miller
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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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-...>
- 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!
14 years, 6 months
Deleting entries that are not modified recently
by Kimmo Koivisto
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
14 years, 6 months