Re: [389-users] Error 53 setting up ChainOnUpdate

2013-04-12 Thread Jim Finn 
Below is what I did & works for me w/ 389-ds-base-1.2.9.9-1.el5 (x86_64).
I believe the plugin you are specifying is your issue.  I recall
encountering a similar issue when setting this up last year.

First make sure the chaining db is present & be sure to replace
_FARMSERVERS_ with your masters uri:

dn: cn=chainbe1, cn=chaining database, cn=plugins, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
cn: chainbe1
nsslapd-suffix: dc=sears,dc=com
nsfarmserverurl: _FARMSERVERS_
nsmultiplexorbinddn: cn=replication manager,cn=replication,cn=config
nsmultiplexorcredentials: **REPLICATOIN MANAGER CREDENTIALS GO HERE***
nsCheckLocalACI: on


Then modify your suffix..

dn: cn="dc=shared,dc=domainx,dc=com",cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-state
nsslapd-state: backend
-
add: nsslapd-backend
nsslapd-backend: chainbe1
-
add: nsslapd-distribution-plugin
nsslapd-distribution-plugin: libreplication-plugin.so
-
add: nsslapd-distribution-funct
nsslapd-distribution-funct: repl_chain_on_update





Thanks,
Jim Finn


On Fri, Apr 12, 2013 at 11:45 AM, Grzegorz Dwornicki wrote:

> Hi
>
> Each instance od ds uses access and error log by default. Can you provide
> error log? It should be in /var/log/dirsrv/instance_name. To make this more
> productive please try to generate error again, this way log will have it
> near its end
> 12 kwi 2013 18:41, "A Iqbal"  napisał(a):
>
>> Greetings,
>>
>> New to server 389 and am trying to set up chainonupdate so my consumers
>> can forward updates to master servers. Using the recipe at
>>
>>
>> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate#Problems_During_Implementation
>>
>> OS is CentOS 6.3
>>
>> 389 version in use is...
>>
>> 389-ds-1.2.2-1.el6.noarch
>> 389-ds-base-1.2.10.2-20.el6_3.x86_64
>>
>> No hubs involved, 4 masters and multiple consumers.
>>
>> Last step requires adding attributes as following,
>>
>> replace: nsslapd-state
>> nsslapd-state: backend
>>
>> add: nsslapd-backend
>> nsslapd-backend: chainbe1
>>
>> add: nsslapd-distribution-plugin
>> nsslapd-distribution-plugin: /serverroot/lib/replication-plugin.so # or
>> .sl (HPUX) or .dll (NT)
>>
>> add: nsslapd-distribution-funct
>> nsslapd-distribution-funct: repl_chain_on_update
>>
>> able to set first 2 , specific error is 53 when setting
>> 'nsslapd-distribution-funct' and 'nsslapd-distribution-plugin' which has
>> led me nowhere specific
>>
>> Somewhere in this, my consumer replica has wiped itself and refuses to be
>> restored, I am planning to rebuild the machine, adding as it might be of
>> relevance.
>>
>> Would appreciate anyone sharing any pointers or logs I can look into to
>> proceed.
>>
>> Kind Regards, A Iqbal.
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Fwd: passwordRetryCount not incrementing past 1

2013-04-12 Thread Jim Finn 
Are you using any kind of VIP or load balancer in front of the two
instances?


On Fri, Apr 12, 2013 at 12:15 PM, Eric Gingras  wrote:

> Hi,
>
> I have not received any input on this one, if you could kindly inform if
> some information is missing I'd like to get this resolved.
>
> Many thanks
> Eric
>
>
>
>  Original Message 
> Subject: passwordRetryCount not incrementing past 1
> Date: 2013-04-10 09:17
> From: Eric Gingras 
> To: <389-users@lists.**fedoraproject.org<389-users@lists.fedoraproject.org>
> >
>
> Hi,
>
> I have an issue with account lockout.
>
> Setup:
> 2-node in MMR config
> 389-Directory/1.2.10.26 B2013.023.2027 (from fedorapeople repo)
> RHEL 6.4 x86_64
>
> What I did (as per docs), doing this as a subtree or local policy:
>
> dn: cn=config
> changetype: modify
> replace: passwordIsGlobalPolicy
> passwordIsGlobalPolicy: on
>
> dn: cn=cn\=nsPwPolicyEntry\,ou\=**People\,dc\=\,dc\=**
> com,cn=nsPwPolicyContainer,ou=**People,dc=,dc=com
> changetype: modify
> replace: passwordExp
> passwordExp: on
> -
> replace: passwordMaxAge
> passwordMaxAge: 7862400
> -
> replace: passwordHistory
> passwordHistory: on
> -
> replace: passwordInHistory
> passwordInHistory: 3
> -
> replace: passwordCheckSyntax
> passwordCheckSyntax: on
> -
> replace: passwordMinDigits
> passwordMinDigits: 1
> -
> replace: passwordMinSpecials
> passwordMinSpecials: 1
> -
> replace: passwordMinLowers
> passwordMinLowers: 1
> -
> replace: passwordMinUppers
> passwordMinUppers: 1
> -
> replace: passwordMinLength
> passwordMinLength: 8
> -
> replace: passwordStorageScheme
> passwordStorageScheme: SSHA512
> -
> replace: passwordLockout
> passwordLockout: on
> -
> add: passwordMaxFailure
> passwordMaxFailure: 3
> -
> add: passwordUnlock
> passwordUnlock: off
>
> I also need to track loginTime (no time-based lockout), again as per doc:
>
> dn: cn=Account Policy Plugin,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginEnabled
> nsslapd-pluginEnabled: on
>
> dn: cn=Account Policy Plugin,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginarg0
> nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
>
> dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
> changetype: modify
> replace: alwaysrecordlogin
> alwaysrecordlogin: yes
> -
> add: stateattrname
> stateattrname: lastLoginTime
> -
> add: altstateattrname
> altstateattrname: createTimestamp
> -
> add: specattrname
> specattrname: acctPolicySubentry
> -
> add: limitattrname
> limitattrname: accountInactivityLimit
>
> Restarted:
>
> service dirsrv restart both nodes
>
> What I get (after purposely trying to bind with wrong pwd many times):
>
> No lockout, passwordRetryCount stays at 1
>
> dn: uid=,ou=People,dc=<**REMOVED>,dc=com
> passwordRetryCount: 1
> retryCountResetTime: 20130410130146Z
> lastLoginTime: 20130409193943Z
> passwordExpirationTime: 20130709182434Z
> userPassword:: 
> mail: 
> sn: 
> preferredLanguage: en
> cn: 
> uid: 
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> givenName: 
>
> I'm freshly out of ideas, thanks for helping.
>
> Eric
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.**org <389-users@lists.fedoraproject.org>
> https://admin.fedoraproject.**org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Search operation takes too much time for respond

2013-01-02 Thread Jim Finn 
logconv.pl is your friend.

What is the filter & attributes you are searching?  Are they indexed?


On Jan 2, 2013, at 6:01 AM, Balaji P  wrote:

  Hi All,

We are using 389 LDAP server which is having around <1000 objects. We have
a control script which is running as a separate process to perform the
search operation in the particular DN.. From the access log around 98%
Percentage the search operation estimation timeout value as 0 second. The
remaining 2% percentage we got different estimation timeout values like
(1-18) seconds. We did n’t observe any log error message in log file.  Also
we have some other java process running on the same machine.

Any idea what could be possible reason for search operation taking  more
time?  And how to debug this issue.

Thanks in advance,

With Regards,
Balaji P.


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Disable Inactive Users After 90 days

2012-05-09 Thread Jim Finn 
Actually, I just re-read what you are trying to do...

" Changetype: delete " is intended to delete the entire entry, not an
attribute.

You're receiving that error because there should be no further instruction
after a " Changetype: delete "

I believe what you are attempting to do is remove the lastLoginTime
attribute.  You would accomplish that like this:

dn: uid=username,ou=people,dc=domain,dc=local
changetype: modify
delete: lastLoginTime

Jim

On Wed, May 9, 2012 at 11:13 AM, Jim Finn  wrote:

> Are you doing this via an ldif file or stdin?
>
> Try
> echo -e "dn: uid=username,ou=people,dc=domain,dc=local\nchangetype:
> delete\ndelete: lastLoginTime\n\n" | ldapmodify -x -h yourhost
> -D"cn=directory manager" -wPaSsWoRd
>
> Jim
>
> On Wed, May 9, 2012 at 11:09 AM, Rich Megginson wrote:
>
>>  On 05/09/2012 10:09 AM, Ali Jawad wrote:
>>
>> Hi Rich
>> Seems I still got a problem, the users can't logon anymore, I did try to
>>
>>  dn: uid=username,ou=people,dc=domain,dc=local
>> changetype: delete
>> delete: lastLoginTime
>>
>>  But I keep getting
>>
>>  ldapmodify: extra lines at end (line 3 of entry
>> "uid=username,ou=people,dc=domain,dc=local")
>>
>>  I checked for whitespaces, extra lines..but still same issue
>>
>>  I did also check for lastLoginTime values in the users in the
>> interface, but the value is empty..so not sure if this is the problem at all
>>
>>
>> does ldapmodify -d 1 give any more useful information?
>>
>>
>>
>>  Regards
>>
>>
>>
>>
>>
>>  On Wed, May 9, 2012 at 5:26 PM, Ali Jawad wrote:
>>
>>> Hi Rich
>>> Your help is highly appreciated, I got it working, thanks for your
>>> patience.
>>> Regards
>>>
>>>
>>> On Wed, May 9, 2012 at 5:19 PM, Rich Megginson wrote:
>>>
>>>>  On 05/09/2012 08:17 AM, Ali Jawad wrote:
>>>>
>>>> Hi
>>>> Thanks Rich, just what I was searching for, I am facing a problem
>>>> though "ldapmodify: No such object (32) matched DN: dc=domain,dc=local"at :
>>>>
>>>>  [user@server ~]$ ldapmodify *-a* -D "cn=directory manager" -w secret -p 
>>>> 389 -h server.example.com -x
>>>>
>>>> dn: cn=Account Inactivation Policy,dc=example,dc=com
>>>>
>>>> objectClass: top
>>>> objectClass: ldapsubentry
>>>> objectClass: extensibleObject*objectClass: 
>>>> accountpolicy**accountInactivityLimit: 2592000*
>>>> cn: Account Inactivation Policy
>>>>
>>>>
>>>>  I am doing
>>>>
>>>>  [root@386-100-16 dirsrv]# ldapmodify -D "cn=directory manager" -w
>>>> password  -p 389 -h x.x.x.x   -x
>>>>
>>>>  dn: cn=Account Inactivation Policy,dc=domain,dc=local
>>>> objectClass: top
>>>> objectClass: ldapsubentry
>>>> objectClass: extensibleObject
>>>> objectClass: accountpolicy
>>>> accountInactivityLimit: 2592000
>>>> cn: Account Inactivation Policy
>>>> modifying entry "cn=Account Inactivation Policy,dc=domain,dc=local"
>>>>
>>>>  ldapmodify: No such object (32)
>>>> matched DN: dc=domain,dc=local
>>>>
>>>>
>>>> Right.  You are missing the ldapmodify -a - see the original
>>>> instructions
>>>>
>>>>
>>>>
>>>> On Wed, May 9, 2012 at 4:47 PM, Rich Megginson wrote:
>>>>
>>>>>   On 05/09/2012 07:45 AM, Ali Jawad wrote:
>>>>>
>>>>> Hi
>>>>> I have a requirement to disable inactive users after 90 days. I did
>>>>> read  http://directory.fedoraproject.org/wiki/Account_Policy_Design
>>>>> but I am not sure whether this is a design proposal or the
>>>>> actual implementation.
>>>>>
>>>>>  My DS version is :
>>>>>
>>>>>  rpm -qa | grep 389
>>>>> 389-admin-console-1.1.8-1.el5
>>>>> 389-ds-base-1.2.9.9-1.el5
>>>>> 389-dsgw-1.1.7-2.el5
>>>>> 389-console-1.1.7-3.el5
>>>>> 389-adminutil-1.1.14-1.el5
>>>>> 389-admin-1.1.23-1.el5
>>>>> 389-admin-console-doc-1.1.8-1.el5
>>>>> 389-ds-1.2.1-1.el5
>>>>> 389-ds-base-libs-1.2.9.9-1.el5
>>>>> 389-ds-console-1.2.6-1.el5
>>>

Re: [389-users] Disable Inactive Users After 90 days

2012-05-09 Thread Jim Finn 
Are you doing this via an ldif file or stdin?

Try
echo -e "dn: uid=username,ou=people,dc=domain,dc=local\nchangetype:
delete\ndelete:
lastLoginTime\n\n" | ldapmodify -x -h yourhost -D"cn=directory manager"
-wPaSsWoRd

Jim

On Wed, May 9, 2012 at 11:09 AM, Rich Megginson  wrote:

>  On 05/09/2012 10:09 AM, Ali Jawad wrote:
>
> Hi Rich
> Seems I still got a problem, the users can't logon anymore, I did try to
>
>  dn: uid=username,ou=people,dc=domain,dc=local
> changetype: delete
> delete: lastLoginTime
>
>  But I keep getting
>
>  ldapmodify: extra lines at end (line 3 of entry
> "uid=username,ou=people,dc=domain,dc=local")
>
>  I checked for whitespaces, extra lines..but still same issue
>
>  I did also check for lastLoginTime values in the users in the interface,
> but the value is empty..so not sure if this is the problem at all
>
>
> does ldapmodify -d 1 give any more useful information?
>
>
>
>  Regards
>
>
>
>
>
>  On Wed, May 9, 2012 at 5:26 PM, Ali Jawad  wrote:
>
>> Hi Rich
>> Your help is highly appreciated, I got it working, thanks for your
>> patience.
>> Regards
>>
>>
>> On Wed, May 9, 2012 at 5:19 PM, Rich Megginson wrote:
>>
>>>  On 05/09/2012 08:17 AM, Ali Jawad wrote:
>>>
>>> Hi
>>> Thanks Rich, just what I was searching for, I am facing a problem though
>>> "ldapmodify: No such object (32) matched DN: dc=domain,dc=local"at :
>>>
>>>  [user@server ~]$ ldapmodify *-a* -D "cn=directory manager" -w secret -p 
>>> 389 -h server.example.com -x
>>>
>>> dn: cn=Account Inactivation Policy,dc=example,dc=com
>>>
>>> objectClass: top
>>> objectClass: ldapsubentry
>>> objectClass: extensibleObject*objectClass: 
>>> accountpolicy**accountInactivityLimit: 2592000*
>>> cn: Account Inactivation Policy
>>>
>>>
>>>  I am doing
>>>
>>>  [root@386-100-16 dirsrv]# ldapmodify -D "cn=directory manager" -w
>>> password  -p 389 -h x.x.x.x   -x
>>>
>>>  dn: cn=Account Inactivation Policy,dc=domain,dc=local
>>> objectClass: top
>>> objectClass: ldapsubentry
>>> objectClass: extensibleObject
>>> objectClass: accountpolicy
>>> accountInactivityLimit: 2592000
>>> cn: Account Inactivation Policy
>>> modifying entry "cn=Account Inactivation Policy,dc=domain,dc=local"
>>>
>>>  ldapmodify: No such object (32)
>>> matched DN: dc=domain,dc=local
>>>
>>>
>>> Right.  You are missing the ldapmodify -a - see the original
>>> instructions
>>>
>>>
>>>
>>> On Wed, May 9, 2012 at 4:47 PM, Rich Megginson wrote:
>>>
   On 05/09/2012 07:45 AM, Ali Jawad wrote:

 Hi
 I have a requirement to disable inactive users after 90 days. I did
 read  http://directory.fedoraproject.org/wiki/Account_Policy_Design
 but I am not sure whether this is a design proposal or the
 actual implementation.

  My DS version is :

  rpm -qa | grep 389
 389-admin-console-1.1.8-1.el5
 389-ds-base-1.2.9.9-1.el5
 389-dsgw-1.1.7-2.el5
 389-console-1.1.7-3.el5
 389-adminutil-1.1.14-1.el5
 389-admin-1.1.23-1.el5
 389-admin-console-doc-1.1.8-1.el5
 389-ds-1.2.1-1.el5
 389-ds-base-libs-1.2.9.9-1.el5
 389-ds-console-1.2.6-1.el5
 389-ds-console-doc-1.2.6-1.el5

  I got

  [root@386-100-16 dirsrv]# ldapsearch -x -D "cn=Directory manager" -w
 Password -b "cn=config" -s base lastLoginTime
 # extended LDIF
 #
 # LDAPv3
 # base  with scope baseObject
 # filter: (objectclass=*)
 # requesting: lastLoginTime
 #

  # config
 dn: cn=config

  # search result
 search: 2
 result: 0 Success

  # numResponses: 2
 # numEntries: 1

  and

  [root@386-100-16 dirsrv]# grep -i lastlogintime
 /etc/dirsrv/slapd-386-100-16/schema/*
 /etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:## lastLoginTime
 holds login state in user entries (GeneralizedTime syntax)
 /etc/dirsrv/slapd-386-100-16/schema/60acctpolicy.ldif:attributeTypes: (
 2.16.840.1.113719.1.1.4.1.35 NAME 'lastLoginTime'

  I am not sure how to implement this though, please advice.


 http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/account-policy-plugin.html


  Regards



 --
 389 users mailing 
 list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users



>>>
>>>
>>>  --
>>> *Ali Jawad
>>> *
>>> *Information Systems Manager*
>>> *Splendor Telecom (www.splendor.net)
>>> Beirut, Lebanon
>>> Phone: +9611373725/ext 116
>>> FAX: +9611375554*
>>>
>>>
>>>
>>
>>
>>  --
>> *Ali Jawad
>> *
>> *Information Systems Manager*
>> *Splendor Telecom (www.splendor.net)
>> Beirut, Lebanon
>> Phone: +9611373725/ext 116
>> FAX: +9611375554*
>>
>>
>
>
>  --
> *Ali Jawad
> *
> *Information Systems Manager*
> *Splendor Telecom (www.splendor.net)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554*
>
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://a

Re: [389-users] how to keep in sync centos-ds in a dr scenario

2012-04-26 Thread Jim Finn 
Instead of having the same actual IP for each server, why not use virtual
IPs with something like heartbeat?  This way if replica-A@siteA goes down,
replica-A@siteB will take over.  This entirely depends on your network
topology, but may be a step in the right direction.

Having servers with the same IPs doens't seem to be the most elegant
solution; same with rsync'ing your database instead of using replication.

Jim

On Thu, Apr 26, 2012 at 7:03 AM, Paul Robert Marino wrote:

> Well that's not a great way to set that up but its workable. You will need
> to sync without ssl and do a destination nat betwean them
> On Apr 26, 2012 4:05 AM, "Maurizio Marini"  wrote:
>
>> I have a disaster recovery scenario:
>> on a remote location I have the same servers with the same hostnames and
>> the
>> same ip's, exactly all the same.
>> Nightly I use rsync to keep all the servers in sync.
>> One of this server is a CentOS5 with centos-ds and samba as pdc.
>> I cannot use replica between current and dr, as the 2 server have the
>> same ip
>> and hostname.
>> I am using ldap2db to import the nightly ldif backup.
>> /usr/lib/dirsrv/slapd-centos-ds/ldif2db -n userRoot -i
>> /tmp/backup-yyddmm.ldif
>> It seems work, it's dirty but does work.
>> Do u see any side-effects? Have u some suggestion?
>>
>> -m
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] request-que-backlog

2012-04-09 Thread Jim Finn 
With Sun/iPlanet directory server, we would monitor request-que-backlog
under the cn=monitor dn to give us an indication of overload & the need for
additional threads.  Does such a backlog exist within 389-ds?  If not, is
there something similar we can use?

Thanks,

Jim Finn
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Repair replication

2012-04-03 Thread Jim Finn 
This can be caused by replication dn having an expired password.

On Tue, Apr 3, 2012 at 4:55 PM, Herb Burnswell
wrote:

>
> -- Forwarded message --
> From: Rich Megginson 
>  Date: Mon, Apr 2, 2012 at 7:37 PM
> Subject: Re: [389-users] Fwd: Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users@lists.fedoraproject.org>
> Cc: Herb Burnswell 
>
>
>  On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>
>
>
> -- Forwarded message --
> From: Rich Megginson 
> Date: Mon, Apr 2, 2012 at 3:23 PM
> Subject: Re: [389-users] Repair replication
> To: "General discussion list for the 389 Directory server project." <
> 389-users@lists.fedoraproject.org>
> Cc: Herb Burnswell 
>
>
>  On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>
>
>
> On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson wrote:
>
>>  On 03/23/2012 11:09 AM, Herb Burnswell wrote:
>>
>> Thanks for the reply David.
>>
>> >> 1. How can I find out which system(s) is/are master, consumer, hub,
>> etc?
>> You should be able to determine the role of the Directory Server for
>> each
>> system by logging into the LDAP console under
>> "Configuration->Replication".  The role is either "Single Master",
>> "Hub" or
>> "Dedicated Consumer".
>>
>> >I was able to determine that we have two "Multiple Master" systems.
>> Let's call >them 'A' and 'B'.  System A has been the only system running
>> for what appears to >be several years (it is being backed up nightly).
>> System B has been off for some >time but is running now.
>>
>> >> 2. How do I confirm that the systems have the correct credentials for
>> >replication? (I am receiving: "Unable to acquire replica: Permission
>> >denied.")
>>>a. How can I change the bind dn "cn=replication,cn=config" credentials
>> >on each system to ensure replication will work?
>> You can do that on the console as well.  Just navigate down the
>> directory
>> tree and manually reset the password for the replication user account.
>> There's a possibility that your replication user account's password
>> expired.
>>
>> >I can navigate to the screen to reset the password for the replication
>> user account.  I >have not reset the passwords yet as I am reading
>> documentation to confirm that >system B will simply update it's data to
>> system A's upon resuming replication.
>>
>>  >When you change the password of the replication user on B, you'll also
>> have to update >those credentials in the replication agreement on A for the
>> agreement from A to B.
>>
>> >Note that if replication has been down for years, you will have to
>> perform a manual >replica initialization procedure - replication will not
>> automatically "catch up" if it has >been down that long.
>>
>>   Rich - Thank you for the response. I was diverted to another urgent
> issue but have come back to this replication fix.
>
> I've confirmed that there are two Dedicated Consumer's (C and D) to go
> along with the two Dual Master's (A and B). I want to replicate to one of
> the dedicated consumers, C, prior to syncing the dual master B. I changed
> the passwords for dn:cn=replication,cn=config on A via the Directory
> Manager console, and via ldapmodify on C. I am confident that the passwords
> are the same on both systems.
>
>
>  >What exactly did you do?
> >Note that you'll have to update the password in cn=replication,cn=config
> on the >consumer (C) and update the replication agreement on A for the
> replication agreement >between A and C.
>
> Thanks for the reply Rich.  Yes, I updated the password on A and C.  I
> apologize as I left out the link in my below reference to section 8.10.5.1:
>
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html.
> I used bak2db with backup files from A.  After which, I see: "Unable to
> acquire replica: permission denied. The bind dn "cn=replication,cn=config"
> does not have permission to supply replication updates to the replica. Will
> retry later." on system A's error logs..
>
> >I think doing the restore is resetting the password.  After doing the
> bak2db, change the >passwords.
>
> Well, I'm kind of at a loss here.  I've reset the passwords on A and C
> after doing the bak2db.  Same error:
>
>
> Unable to acquire replica: permission denied. The bind dn
> "cn=replication,cn=config" does not have permission to supply replication
> updates to the replica. Will retry later.
>
> Next, I removed and re-added the replication agreement on Master A to
> Consumer C, same error above.
>
> Is there any way that I can output the settings/password information for
> cn=replication,cn=config on both A and C via the command line to compare?
> I have read that there needs to be a 'person' entry on the consumer for
> cn=replication,cn=config that is used for the replication of the data.  Is
> there a way I can confirm this configuration to ensure it is set up
> correctly?
>
> I'm also seeing this error in the log

[389-users] Setup SSL with setup-ds-admin.pl INF

2012-03-27 Thread Jim Finn 
I'm trying to script the entire setup of new instances, and have had great
success with setup-ds-admin.pl with an inf.

I want to run nsslapd on both 389 and 636 - How can I configure both ports
and specify my cert within the INF?

Thanks!

Jim Finn
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DS ACLs - still

2012-03-06 Thread Jim Finn 
Have you set the following?
dn: cn=config
nsslapd-allow-anonymous-access: off

http://directory.fedoraproject.org/wiki/Anonymous_Access_Switch

Jim Finn

On Tue, Mar 6, 2012 at 12:24 PM, Karoly Czovek  wrote:

> Hi there,
>
> i faced into the following problem:
>
> installed one instance of 389ds to our DR site.
> Imported the databases
> Set up SSL
> Removed the anonymous read ACLs
> Restarted the dirsrv
>
> Replication is not set up.
>
> and I stil can pull the whole db, with a simple
>
> ldapsearch -x -LLL -h ds-drb -b "dc=foo,dc=bar"
>
> 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
> 389-admin-1.1.25-1.el6.x86_64
> 389-admin-console-doc-1.1.8-1.el6.noarch
> 389-console-1.1.7-1.el6.noarch
> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64
> 389-admin-console-1.1.8-1.el6.noarch
> 389-ds-console-doc-1.2.6-1.el6.noarch
> 389-dsgw-1.1.7-2.el6.x86_64
> 389-adminutil-1.1.14-2.el6.x86_64
> 389-ds-console-1.2.6-1.el6.noarch
> 389-ds-1.2.2-1.el6.noarch
>
> Any idea?
>
> --
> Karoly CZOVEK
> Senior Systems Administrator
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] dirsrv does not start anymore

2012-03-05 Thread Jim Finn 
What have you changed since the last successful startup?

Have you tried starting with the contents of
/etc/dirsrv/slapd-ldap1/dse.ldif.bak ?


On Mon, Mar 5, 2012 at 7:36 PM, Vasil Mikhalenya  wrote:

> Hi all,
>
> I can not solve the following issue. I can not start my master anymore.
>
> /var/log/dirsrv/slapd-ldap1/errors:
> [05/Mar/2012:19:43:06 +0300] - 389-Directory/1.2.10.2 B2012.054.1543
> starting up
> [05/Mar/2012:19:43:06 +0300] - Detected Disorderly Shutdown last time
> Directory Server was running, recovering database.
> [05/Mar/2012:19:43:06 +0300] - slapi_add_internal: add_values for type
> uniqueMember failed (rc: 20)
> [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type
> uniqueMember failed (rc: 20)
> [05/Mar/2012:19:43:07 +0300] - slapd started.  Listening on All
> Interfaces port 389 for LDAP requests
> [05/Mar/2012:19:43:07 +0300] - Listening on All Interfaces port 636
> for LDAPS requests
> [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send
> bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91
> (Can't connect to the LDAP server) -5961 (TCP connection reset by
> peer.) 115 (Operation now in progress)
> [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin -
> agmt="cn=eu2-ldap" (eu2-ldap:636): Replication bind with SIMPLE auth
> failed: LDAP error 91 (Can't connect to the LDAP server) ((null))
> [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send
> bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91
> (Can't connect to the LDAP server) -5961 (TCP connection reset by
> peer.) 115 (Operation now in progress)
> [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin -
> agmt="cn=us1-ldap" (us1-ldap:636): Replication bind with SIMPLE auth
> failed: LDAP error 91 (Can't connect to the LDAP server) ((null))
> [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type
> uniqueMember failed (rc: 20)
>
> CentOS release 5.7 (Final)
>
> Name   : 389-ds
> Arch   : noarch
> Version: 1.2.1
> Release: 1.el5
>
>
> Google says nothing.
>
> Thanks in advance.
>
> --
> Best regards,
> Vasil Mikhalenya
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] ChainOnUpdate

2012-03-05 Thread Jim Finn 
(resending w/ reply to all, 389-users)

I was using  "cn=directory manager" when attempting to make the updates.
 Using a user's credentials to do a MOD seemed to produced the desired
result.  Thanks!

As an aside, should it not be viewed as problematic that the database on a
consumer could be directly modified by "cn=directory manager" and those
changes are not reflected on the Master (or other masters, hubs, or
consumers, for that matter) ?

Hypothetically speaking...
"cn=directory manager" could bind to be1.foo.com and modify the following
dn..
dn: uid=jim,dc=foo,dc=com
changetype: modify
replace: sn
sn: changed on be1

I could then search be1.foo.com (Master) and be2.foo.com (consumer)
and find the value for "sn" on "uid=jim,dc=foo,dc=com" is "changed on be1"
on both servers

The above makes sense.

Now, If i were to  make the same change to be2...
"cn=directory manager" binds to be2.foo.com and modifies ..
changetype: modify
replace: sn
sn: changed on be2

I would then search be1.foo.com (Master) and find sn to have a value of
"changed on be1"
a search of be2.foo.com (Consumer) would show sn has a value of "changed on
be2"

It seems this could have a detrimental effect on the integrity of the
environment.

Thoughts?


Thanks again for your help!


On Mon, Mar 5, 2012 at 5:32 PM, Rich Megginson  wrote:

>  On 03/05/2012 03:55 PM, Jim Finn wrote:
>
> Note: I have searched through years past in 389-users and have found a few
> others experiencing the same problem, yet I could not find any resolution.
>
>
>  I am attempting to setup chain on update per
> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>
>
>  The packages installed are:
>
> 389-admin-console-1.1.8-1.el6.noarch
>
> 389-ds-1.2.2-1.el6.noarch
>
> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64
>
> 389-console-1.1.7-1.el6.noarch
>
> 389-admin-console-doc-1.1.8-1.el6.noarch
>
> 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
>
> 389-dsgw-1.1.7-2.el6.x86_64
>
> 389-ds-console-1.2.6-1.el6.noarch
>
> 389-ds-console-doc-1.2.6-1.el6.noarch
>
> 389-adminutil-1.1.14-2.el6.x86_64
>
> 389-admin-1.1.25-1.el6.x86_64
>
>
>  The justification for use of chain_on_update is that our clients are
> “dumb” and unable to follow referrals.
>
>
>  As a POC, I am testing with two servers: be1.foo.com (Master) and
> be2.foo.com (Consumer)
>
>
>  Prior to following the instructions in the Howto:ChainOnUpdate (linked
> above) the environment operated as follows:
>
>
>  Scenario A)
>
> Client.foo.com attempts to modify be1.foo.com -> Allowed
>
> Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com
>
> Ldapsearch of both searvers shows the item was properly replicated, value
> is the same on be1 and be2
>
> -
>
> Scenario B)
>
> Client.foo.com attempts to modify be2.foo.com -> Not allowed, given
> referral
>
>
>  Upon following the instructions in the aforementioned howto the
> environment operates as follows:
>
>
>  Scenario A)
>
> Client.foo.com attempts to modify be1.foo.com -> Allowed
>
> Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com
>
> Ldapsearch of both searvers shows the item was properly replicated, value
> is the same on be1 and be2
>
> -
>
> Scenario B)
>
> Client.foo.com attempts to modify be2.foo.com -> Allowed
>
> What credentials did you use?  Note that cn=directory manager is not
> chained because the directory manager credentials are local to each server.
>
> Change made by client.foo.com **SHOULD** have been handled by the
> chaining backend and modified on be1
>
> Ldapsearch of both servers shows the item was modified on be2 but not be1
> (be1 still has the old value)
>
>
>  It seems the writes from client.foo.com to be2.foo.com are being
> committed to be local database (userRoot) instead of being handled by the
> chaining backend (chainbe1).
>
>
>  As the howto suggests, I am using the replication manager for the proxy
> auth.  I have confirmed the credentials on all servers.
>
>
>  dn: cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> objectClass: nsMappingTree
>
> cn: "dc=foo,dc=com"
>
> nsslapd-state: backend
>
> nsslapd-backend: userRoot
>
> nsslapd-backend: chainbe1
>
> nsslapd-distribution-plugin: libreplication-plugin.so
>
> nsslapd-distribution-funct: repl_chain_on_update
>
>
>  dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> objectClass: nsBackendInstance
>
>

[389-users] ChainOnUpdate

2012-03-05 Thread Jim Finn 
Note: I have searched through years past in 389-users and have found a few
others experiencing the same problem, yet I could not find any resolution.


I am attempting to setup chain on update per
http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate


The packages installed are:

389-admin-console-1.1.8-1.el6.noarch

389-ds-1.2.2-1.el6.noarch

389-ds-base-1.2.9.14-1.el6_2.2.x86_64

389-console-1.1.7-1.el6.noarch

389-admin-console-doc-1.1.8-1.el6.noarch

389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64

389-dsgw-1.1.7-2.el6.x86_64

389-ds-console-1.2.6-1.el6.noarch

389-ds-console-doc-1.2.6-1.el6.noarch

389-adminutil-1.1.14-2.el6.x86_64

389-admin-1.1.25-1.el6.x86_64


The justification for use of chain_on_update is that our clients are “dumb”
and unable to follow referrals.


As a POC, I am testing with two servers: be1.foo.com (Master) and
be2.foo.com (Consumer)


Prior to following the instructions in the Howto:ChainOnUpdate (linked
above) the environment operated as follows:


Scenario A)

Client.foo.com attempts to modify be1.foo.com -> Allowed

Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com

Ldapsearch of both searvers shows the item was properly replicated, value
is the same on be1 and be2

-

Scenario B)

Client.foo.com attempts to modify be2.foo.com -> Not allowed, given referral


Upon following the instructions in the aforementioned howto the environment
operates as follows:


Scenario A)

Client.foo.com attempts to modify be1.foo.com -> Allowed

Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com

Ldapsearch of both searvers shows the item was properly replicated, value
is the same on be1 and be2

-

Scenario B)

Client.foo.com attempts to modify be2.foo.com -> Allowed

Change made by client.foo.com **SHOULD** have been handled by the chaining
backend and modified on be1

Ldapsearch of both servers shows the item was modified on be2 but not be1
(be1 still has the old value)


It seems the writes from client.foo.com to be2.foo.com are being committed
to be local database (userRoot) instead of being handled by the chaining
backend (chainbe1).


As the howto suggests, I am using the replication manager for the proxy
auth.  I have confirmed the credentials on all servers.


dn: cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config

objectClass: top

objectClass: extensibleObject

objectClass: nsMappingTree

cn: "dc=foo,dc=com"

nsslapd-state: backend

nsslapd-backend: userRoot

nsslapd-backend: chainbe1

nsslapd-distribution-plugin: libreplication-plugin.so

nsslapd-distribution-funct: repl_chain_on_update


dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config

objectClass: top

objectClass: extensibleObject

objectClass: nsBackendInstance

cn: userRoot

numSubordinates: 7

nsslapd-suffix: dc=foo,dc=com

nsslapd-cachesize: -1

nsslapd-cachememsize: 10485760

nsslapd-readonly: off

nsslapd-require-index: off

nsslapd-directory: /var/lib/dirsrv/slapd-be2/db/userRoot

nsslapd-dncachememsize: 10485760


dn: cn=replica,cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config

objectClass: nsDS5Replica

objectClass: top

nsDS5ReplicaRoot: dc=foo,dc=com

nsDS5ReplicaType: 2

nsDS5Flags: 0

nsds5ReplicaPurgeDelay: 604800

nsDS5ReplicaBindDN: cn=replication manager,cn=replication,cn=config

cn: replica

nsDS5ReplicaId: 6553

nsDS5ReplicaName: ((REDACTED FOR EMAIL THREAD))


dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config

objectClass: top

objectClass: extensibleObject

objectClass: nsBackendInstance

cn: chainbe1

nsslapd-suffix: "dc=foo,dc=com"

nsfarmserverurl: ldap://be1.foo.com/

nsmultiplexorbinddn: cn=replication manager,cn=replication,cn=config

nschecklocalaci: off

nsusestarttls: on

nsbindmethod:

nsmultiplexorcredentials: {DES}((REDACTED FOR EMAIL THREAD))


dn: cn=config,cn=chaining database,cn=plugins,cn=config

objectClass: top

objectClass: extensibleObject

cn: config

nstransmittedcontrols: 2.16.840.1.113730.3.4.2

nstransmittedcontrols: 2.16.840.1.113730.3.4.9

nstransmittedcontrols: 1.2.840.113556.1.4.473

nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12

nspossiblechainingcomponents: cn=resource limits,cn=components,cn=config

nspossiblechainingcomponents: cn=certificate-based
authentication,cn=component

s,cn=config

nspossiblechainingcomponents: cn=password policy,cn=components,cn=config

nspossiblechainingcomponents: cn=sasl,cn=components,cn=config

nspossiblechainingcomponents: cn=roles,cn=components,cn=config

nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config

nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config

nspossiblechainingcomponents: cn=referential integrity
postoperation,cn=plugin

s,cn=config

nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config



Any help in getting ChainOnUpdate to work with my 389 servers would be
greatly appreciated.


Thanks in advance!


Jim Finn
--
389 users mailing list
389-users@lists.fedoraproject.org