Issue with memberOf Plugin
by Christopher Westerfield
Hi,
I hope someone here can help me.
I’m having the same issue on two other managed systems.
So first of all Distribution: Debian
Installed 389 LDAP Server: 1.3.3.5
Installed with Kolab Groupware Server
My Problem is, that I can’t Query against the memberOf Flag
This would be the Query that I need to get Working
(&(uid=cwest)(memberOf=cn=general-users,ou=Groups,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld))
But I don’t get any results on the query.
This would be the group data:
# LDIF Export for cn=General-Users,ou=Groups,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
# Server: Saila (ldap://localhost <ldap://localhost>)
# Search Scope: base
# Search Filter: (objectClass=*)
# Total Entries: 1
#
# Generated by phpLDAPadmin (http://phpldapadmin.sourceforge.net <http://phpldapadmin.sourceforge.net/>) on July 9, 2015 6:17 pm
# Version: 1.2.3
version: 1
# Entry 1: cn=General-Users,ou=Groups,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
dn: cn=General-Users,ou=Groups,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
cn: General-Users
objectclass: top
objectclass: groupofuniquenames
uniquemember: uid=saicher,ou=People,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
uniquemember: uid=thoralf,ou=People,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
uniquemember: uid=cwesterfield,ou=People,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
uniquemember: uid=freygeist,ou=People,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
uniquemember: uid=requiem,ou=People,ou=Domain.com <http://domain.com/>,dc=ldap,dc=treedomain,dc=tld
And this is the Plugin Configuration from the cn=config database:
# LDIF Export for cn=MemberOf Plugin,cn=plugins,cn=config
# Server: Saila (ldap://localhost <ldap://localhost>)
# Search Scope: base
# Search Filter: (objectClass=*)
# Total Entries: 1
#
# Generated by phpLDAPadmin (http://phpldapadmin.sourceforge.net <http://phpldapadmin.sourceforge.net/>) on July 9, 2015 6:20 pm
# Version: 1.2.3
version: 1
# Entry 1: cn=MemberOf Plugin,cn=plugins,cn=config
dn: cn=MemberOf Plugin,cn=plugins,cn=config
cn: MemberOf Plugin
memberofattr: memberOf
memberofgroupattr: member
nsslapd-plugin-depends-on-type: database
nsslapd-plugindescription: memberof plugin
nsslapd-pluginenabled: on
nsslapd-pluginid: memberof
nsslapd-plugininitfunc: memberof_postop_init
nsslapd-pluginpath: libmemberof-plugin
nsslapd-plugintype: betxnpostoperation
nsslapd-pluginvendor: none
nsslapd-pluginversion: none
objectclass: top
objectclass: nsSlapdPlugin
objectclass: extensibleObject
I need this feature really bad as several of the connected Software need the memberOf flag to work properly.
I hope somebody can help me with this.
My openldap Servers don’t have this issue, but they don’t use replication and skaling.
thx
Chris
--
Mit freundlichen Grüßen
Christopher Westerfield
Tel: +49-(0)8161 - 49-24-09-8
Fax: +49-(0)8161 - 91-05-07-2
Mobil: +49-(0)176-985-845-77
Internet: http://www.dsws.biz <http://www.dsws.biz/>
Anschrift:
Thalhauser Strasse 23a
85354 Freising
Bayern
Deutschland
Büro Zeiten:
Termine nur nach Vereinbarung/Anmeldung
Email:
Buchhaltung: buchhaltung(a)dsws.biz <mailto:buchhaltung@dsws.biz>
Support: support(a)dsws.biz <mailto:support@dsws.biz>
Abuse: abuse(a)dsws.biz
8 years, 9 months
Regarding 389-ds on centos 7 seup
by Md. Hasan
Hi, All
I have installed and configured 389 ds on centos 7 successfully, All
services are running successfully, but i am not to access it , #
centos-idm-console & , but no output saying command not found , i also
tried 389-consol but no output. Please help me out how can i access gui of
389 ds.
-: Regards :-
MD. Hasan
8 years, 9 months
Re: [389-users] winsyncsubtreepair
by Mark Boyce
Rich,
I’d prefer to email you directly… nothing personal… mark.boyce(a)ucop.edu
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
415 20th Street
Oakland, CA 94612
Office: 510.987.9681
Cell: 209.851.0196
From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 4:53 PM
To: 389-users(a)lists.fedoraproject.org
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 05:35 PM, Mark Boyce wrote:
Rich,
I am able to get the core dump and it appears to be a segmentation fault when modifying the replication agreement… anything specific from the dump that would be helpful?
Not sure. Can you provide the full stack trace? Be sure to obscure/remove any sensitive information first. If you don't feel comfortable about that, just email me the stack trace.
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 10:59 AM
To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 11:49 AM, Mark Boyce wrote:
Rich,
The version of 389-ds-base is 1.3.3.10-1.fc22.x89-64 and it’s the same behavior running the agreement against AD 2003 or AD 2012.
By “two pairs” in mean to indicate that I have two winsyncsubtree pair attributes; i.e ou=people,dc=example,dc=org:cn=Users,dc=ad,dc=example,dc=org and ou=people,dc=example,dc=org:ou=administrators,dc=ad,dc=example,dc=org
I can either modify the sync agreement using ldapmodify or from the GUI with “Initialize Full Re-synchronization” and as soon as I hit enter after adding another winsyncsubtreepair value the server can’t be contacted and must be restarted.
That sounds like a crash - http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
By “in-scope”, I mean to say that I cannot use a single windows subtree in the agreement; i.e. cn=Users,dc=ad,dc=example,dc=org.
Does that add clarity?
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 9:22 AM
To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 10:07 AM, Mark Boyce wrote:
Good Morning,
Has anyone else seen this behavior; after configuring Winsync I add one or perhaps two “pairs” to the sync agreement (ds:AD)
Firstly - what version of 389-ds-base? rpm -q 389-ds-base
What version of Windows/AD? 2012 R2?
I don't know what you mean by 'two "pairs"'.
and run a full sync successfully. Upon subsequent attempt to add another pair the dirsrv abends (nothing in the logs)
What commands are you running? How do you know the dirsrv abends? That is, if there is nothing in the logs, what commands are you running to see the failure?
and the modify operation fails (either via CLI or GUI). This is critical to our org as the AD structure doesn’t lend it’s self to a single “in-scope” OU…
Also not sure what you mean by "single in-scope OU".
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
415 20th Street
Oakland, CA 94612
Office: 510.987.9681
Cell: 209.851.0196
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 9 months
Re: [389-users] winsyncsubtreepair
by Mark Boyce
Rich,
I am able to get the core dump and it appears to be a segmentation fault when modifying the replication agreement… anything specific from the dump that would be helpful?
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 10:59 AM
To: 389-users(a)lists.fedoraproject.org
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 11:49 AM, Mark Boyce wrote:
Rich,
The version of 389-ds-base is 1.3.3.10-1.fc22.x89-64 and it’s the same behavior running the agreement against AD 2003 or AD 2012.
By “two pairs” in mean to indicate that I have two winsyncsubtree pair attributes; i.e ou=people,dc=example,dc=org:cn=Users,dc=ad,dc=example,dc=org and ou=people,dc=example,dc=org:ou=administrators,dc=ad,dc=example,dc=org
I can either modify the sync agreement using ldapmodify or from the GUI with “Initialize Full Re-synchronization” and as soon as I hit enter after adding another winsyncsubtreepair value the server can’t be contacted and must be restarted.
That sounds like a crash - http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
By “in-scope”, I mean to say that I cannot use a single windows subtree in the agreement; i.e. cn=Users,dc=ad,dc=example,dc=org.
Does that add clarity?
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 9:22 AM
To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 10:07 AM, Mark Boyce wrote:
Good Morning,
Has anyone else seen this behavior; after configuring Winsync I add one or perhaps two “pairs” to the sync agreement (ds:AD)
Firstly - what version of 389-ds-base? rpm -q 389-ds-base
What version of Windows/AD? 2012 R2?
I don't know what you mean by 'two "pairs"'.
and run a full sync successfully. Upon subsequent attempt to add another pair the dirsrv abends (nothing in the logs)
What commands are you running? How do you know the dirsrv abends? That is, if there is nothing in the logs, what commands are you running to see the failure?
and the modify operation fails (either via CLI or GUI). This is critical to our org as the AD structure doesn’t lend it’s self to a single “in-scope” OU…
Also not sure what you mean by "single in-scope OU".
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
415 20th Street
Oakland, CA 94612
Office: 510.987.9681
Cell: 209.851.0196
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 9 months
Re: [389-users] winsyncsubtreepair
by Mark Boyce
Rich,
The version of 389-ds-base is 1.3.3.10-1.fc22.x89-64 and it’s the same behavior running the agreement against AD 2003 or AD 2012.
By “two pairs” in mean to indicate that I have two winsyncsubtree pair attributes; i.e ou=people,dc=example,dc=org:cn=Users,dc=ad,dc=example,dc=org and ou=people,dc=example,dc=org:ou=administrators,dc=ad,dc=example,dc=org
I can either modify the sync agreement using ldapmodify or from the GUI with “Initialize Full Re-synchronization” and as soon as I hit enter after adding another winsyncsubtreepair value the server can’t be contacted and must be restarted. By “in-scope”, I mean to say that I cannot use a single windows subtree in the agreement; i.e. cn=Users,dc=ad,dc=example,dc=org.
Does that add clarity?
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, July 07, 2015 9:22 AM
To: 389-users(a)lists.fedoraproject.org
Subject: Re: [389-users] winsyncsubtreepair
On 07/07/2015 10:07 AM, Mark Boyce wrote:
Good Morning,
Has anyone else seen this behavior; after configuring Winsync I add one or perhaps two “pairs” to the sync agreement (ds:AD)
Firstly - what version of 389-ds-base? rpm -q 389-ds-base
What version of Windows/AD? 2012 R2?
I don't know what you mean by 'two "pairs"'.
and run a full sync successfully. Upon subsequent attempt to add another pair the dirsrv abends (nothing in the logs)
What commands are you running? How do you know the dirsrv abends? That is, if there is nothing in the logs, what commands are you running to see the failure?
and the modify operation fails (either via CLI or GUI). This is critical to our org as the AD structure doesn’t lend it’s self to a single “in-scope” OU…
Also not sure what you mean by "single in-scope OU".
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
415 20th Street
Oakland, CA 94612
Office: 510.987.9681
Cell: 209.851.0196
--
389 users mailing list
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 9 months
winsyncsubtreepair
by Mark Boyce
Good Morning,
Has anyone else seen this behavior; after configuring Winsync I add one or perhaps two "pairs" to the sync agreement (ds:AD) and run a full sync successfully. Upon subsequent attempt to add another pair the dirsrv abends (nothing in the logs) and the modify operation fails (either via CLI or GUI). This is critical to our org as the AD structure doesn't lend it's self to a single "in-scope" OU...
Thanks,
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
415 20th Street
Oakland, CA 94612
Office: 510.987.9681
Cell: 209.851.0196
8 years, 9 months
Unit testing LDAP acis for fun and profit
by William
Hi,
I am going to publish this as a blog post in the next few days on
http://firstyear.id.au
However, as it's relevant for this audience I decided to re-post it
here.
My workplace is a reasonably sized consumer of 389ds. We use it for
storing pretty much all our most important identity data from allowing
people to authenticate, to group and course membership, to email
routing and even internet access.
As a result, it's a really important service to maintain. We need to
treat it as one of the most security sensitive services we run. The
definition of security I always come back to is "availability,
integrity and confidentiality". Now, we have a highly available
environment, and we use TLS with our data to ensure confidentiality of
results and queries. Integrity however, is the main target of this
post.
LDAP allows objects that exist with in the directory to "bind"
(authenticate) and then to manipulate other objects in the directories.
A set of ACIs (Access Control Instructions) define what objects can
modify other objects and their attributes.
ACIs are probably one of the most complex parts in a directory server
environment to "get right" (With the exception maybe of VLV).
I noticed during a security review of our directories ACIs that took
the following pattern.
aci: (targetattr !="cn")(version 3.0;acl "Self write all but cn";allow
(write)(userdn = "ldap:///self");)
aci: (targetattr !="sn")(version 3.0;acl "Self write all but sn";allow
(write)(userdn = "ldap:///self");)
Now, the rules in question we had were more complex and had more rules,
but at their essence looked like this. Seems like an innocuous set of
rules. "Allow self write to everything but sn" and "Allow self write to
everything but cn".
So at the end we expect to see we can write everything but sn and cn.
Lets use the ldap effective permissions capability to check this:
/usr/lib64/mozldap/ldapsearch -D 'cn=Directory Manager' -w - -b
'cn=test,ou=people,dc=example,dc=net,dc=au' -J
"1.3.6.1.4.1.42.2.27.9.5.2:false:dn:
cn=test,ou=people,dc=example,dc=net,dc=au" "(objectClass=*)"
version: 1
dn: cn=test,ou=People,dc=example,dc=net,dc=au
objectClass: top
objectClass: person
cn: test
sn: test
userPassword:
entryLevelRights: v
attributeLevelRights: objectClass:rscwo, cn:rscwo, sn:rscwo,
userPassword:wo
What! Why does cn have r[ead] s[search] c[ompare] w[rite] o[bliterate]?
That was denied? Same for SN.
Well, LDAP treats ACIs as a positive union.
So we have:
aci 1 = ( objectclass, sn, userpassword)
aci 2 = ( objectclass, cn, userpassword)
aci 1 U aci 2 = ( objectclass, sn, cn, userpassword )
As a result, our seemingly secure rules, actually were conflicting and
causing our directory to be highly insecure!
So, easy to change this: First we invert the rules (be explicit in all
things) to say targetattr = "userpassword" for example. We shouldn't
use != rules because they can even conflict between groups and self.
How do we detect these issues though?
I wrote a python library called usl (university simple ldap). In this I
have a toolset for unit testing our ldap acis.
We create a py.test testcase, that states for some set of objects, they
should have access to some set of attributes on a second set of
objects. IE group admins should have rscwo on all other objects.
We can then run these tests and determine if this is or isn't the case.
For example, if we wrote two test cases for the above to test that
"self has rscwo to all attributes or self except sn which should be
rsc" and a second test "self has rscwo to all attributes or self except
cn which should be rsc". Our test cases would have failed, and we would
be alerted to these issues.
As a result of these tests for our acis I was able to find many more
security issues: Such as users who could self modify groups, self
modify acis, account lockouts of other users, or even turn themselves
into a container object and create children. At the worst one aci
actually allowed objects to edit their own aci's which would have
allowed them to give themself more access potentially. The largest
offender were rules that defined targetattr != rules: Often these were
actually allowing access to write attributes that administrators would
over look.
For example, the rule above allowing all write except cn, would
actually allow access to nsAccountLock, nsSizeLimit and other object
attributes that don't show up on first inspection. The complete list is
below. (Note the addition of the '+' )
/usr/lib64/mozldap/ldapsearch -D 'cn=Directory Manager' -w - -b
'cn=test,ou=people,dc=example,dc=net,dc=au' -J
"1.3.6.1.4.1.42.2.27.9.5.2:false:dn:
cn=test,ou=people,dc=example,dc=net,dc=au" "(objectClass=*)" '+'
version: 1
dn: cn=test,ou=People,dc=example,dc=net,dc=au
entryLevelRights: v
attributeLevelRights: nsPagedLookThroughLimit:rscwo,
passwordGraceUserTime:rsc
wo, pwdGraceUserTime:rscwo, modifyTimestamp:rscwo,
passwordExpWarned:rscwo,
pwdExpirationWarned:rscwo, internalModifiersName:rscwo, entrydn:rscwo,
dITCo
ntentRules:rscwo, supportedLDAPVersion:rscwo, altServer:rscwo,
vendorName:rs
cwo, aci:rscwo, nsSizeLimit:rscwo, attributeTypes:rscwo,
acctPolicySubentry:
rscwo, nsAccountLock:rscwo, passwordExpirationTime:rscwo,
entryid:rscwo, mat
chingRuleUse:rscwo, nsIDListScanLimit:rscwo, nsSchemaCSN:rscwo,
nsRole:rscwo
, retryCountResetTime:rscwo, tombstoneNumSubordinates:rscwo,
supportedFeatur
es:rscwo, ldapSchemas:rscwo, copiedFrom:rscwo,
nsPagedIDListScanLimit:rscwo,
internalCreatorsName:rscwo, nsUniqueId:rscwo, lastLoginTime:rscwo,
creators
Name:rscwo, passwordRetryCount:rscwo, dncomp:rscwo,
vendorVersion:rscwo, nsT
imeLimit:rscwo, passwordHistory:rscwo, pwdHistory:rscwo,
objectClasses:rscwo
, nscpEntryDN:rscwo, subschemaSubentry:rscwo, hasSubordinates:rscwo,
pwdpoli
cysubentry:rscwo, structuralObjectClass:rscwo, nsPagedSizeLimit:rscwo,
nsRol
eDN:rscwo, createTimestamp:rscwo, accountUnlockTime:rscwo,
dITStructureRules
:rscwo, supportedSASLMechanisms:rscwo, supportedExtension:rscwo,
copyingFrom
:rscwo, nsLookThroughLimit:rscwo, nsds5ReplConflict:rscwo,
modifiersName:rsc
wo, matchingRules:rscwo, governingStructureRule:rscwo, entryusn:rscwo,
nssla
pd-return-default-opattr:rscwo, parentid:rscwo, pwdUpdateTime:rscwo,
support
edControl:rscwo, passwordAllowChangeTime:rscwo, nsBackendSuffix:rscwo,
nsIdl
eTimeout:rscwo, nameForms:rscwo, ldapSyntaxes:rscwo,
numSubordinates:rscwo,
namingContexts:rscwo
As a result of unit testing our ldap aci's we were able to find many
many loop holes in our security, and then we were able to
programatically close them all down. Reading the ACI's by hand revealed
some issues, but by testing the "expected" aci versus actual behaviour
highlighted our edge cases and the complex interactions of LDAP
systems.
I will clean up and publish the usl tool set in the future to help
other people test their own LDAP secuity controls.
--
William <william(a)firstyear.id.au>
8 years, 9 months
Paged searches return several pages without any content
by Marcio Costa
Hello everybody. In our company we have an environment with four directory servers (389-ds-base version 1.2.11.15) with multi-master replication and every master replicates to other six directory servers (389-ds-base version 1.2.11.15) slaves. Our servers have a suffix and several sub-suffixes so that we have a root base for the root suffix and several bases and each sub-suffixes has its base. We are used Owncloud as cloud storage solution that authenticates and searches in the master servers. Certain operations for the Ownclould performs paged searches in directory servers. It turns out that when we point the Owncloud to the root suffix paged searches return several pages without any content and others with content. If we point to one of our sub-suffixes the paged search return correctly. The nsslapd-pagedsizelimit attributes, nsslapd-pagedlookthroughlimit and nsslapd-pagedidlistscanlimit are not configured for any base. The configuration of these attributes can solve the problem of empty pages in paged searches? If not, is there any other configuration that can be done to correct paged searches with empty content? (Below the output for the command rpm -qa | grep 389-*)
[root@dfcdsrvv1445 ~]# rpm -qa | grep 389-*
389-admin-1.1.34-1.el6.x86_64
389-ds-console-doc-1.2.7-1.el6.noarch
389-ds-base-1.2.11.15-48.el6_6.bz1161909.x86_64
389-ds-console-1.2.7-1.el6.noarch
389-admin-console-doc-1.1.8-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
389-ds-base-libs-1.2.11.15-48.el6_6.bz1161909.x86_64
389-adminutil-1.1.17-1.el6.x86_64
Thanks a lot
--
Marcio Costa
-
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
8 years, 9 months
changelog configuration in MMR environment
by William
Hi,
Do the settings under cn=changelog5,cn=config (such as nsslapd
-changelogmaxage) have an effect on newer MMR environments? The
documentation seems to indicate that the values under cn=changelog5 are
only related to the older replication mechanisms.
If this is the case, where are the changelog configurations for MMR?
--
William <william(a)firstyear.id.au>
8 years, 10 months
