[389-users] Difference between Start and End Replication Request
Hi, I have passed the lofconv.pl script and get a difference between the Start and End Replication Request. Does it make sense? - Extended Operations - 11874 2.16.840.1.113730.3.5.3 Start Replication Request (incremental update) 79622.16.840.1.113730.3.5.5 End Replication Request (incremental update) Regards, Moses. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Difference between Start and End Replication Request
ok, thanks. Moses 2013/1/2 Ludwig Krispenz lkris...@redhat.com Hi, a Start Replication Request is an attempt to start a replication session and to acquire a replica, but if the replica is currently updated by an other supplier, it returns replica busy and the attempt will be repeated. So it can be quite normal that start and end requests are not balanced. Ludwig On 01/02/2013 10:47 AM, Moisés Barba Pérez wrote: Hi, I have passed the lofconv.pl script and get a difference between the Start and End Replication Request. Does it make sense? - Extended Operations - 11874 2.16.840.1.113730.3.5.3 (incremental update) 79622.16.840.1.113730.3.5.5 End Replication Request (incremental update) Regards, Moses. -- 389 users mailing list389-users@lists.fedoraproject.orghttps://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] Search operation takes too much time for respond
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
Re: [389-users] Search operation takes too much time for respond
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 bala...@juniper.net 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] Client ACI question
On 01/02/2013 11:41 AM, Matti Alho wrote: What is the correct way to use allow/deny because if I use default deny on ou=Projects..., it overrides allows. deny always has precedence, it cannot be overridden by an allow rule. So you should model your acis with allow rules (defining exceptions from the default deny). So basically default allow and deny only entries that are confidential? 2. custom attribute Add a custom attribute somewhere and use that for ACI? I could use some concrete examples. I couldn't find any relevant guides or I'm just blind. :) Thanks for help. you could look at the examples here: http://port389.org/wiki/Howto:AccessControl Either use an attribute in the entries you want to allow to be modified and use a targetfilter to restrict the allow aci only to those entries. Or use a userattr rule, like in the manager example. How would that translate in practise? What kind of ACI I would need to achieve the following: uid=serveruser1,ou=ServerUsers,dc=domain,dc=com == has access to cn=Project1,ou=Projects,dc=domain,dc=com AND cn=Project2,ou=Projects,dc=domain,dc=com == deny access to other entries in ou=Projects,dc=domain,dc=com you could use targetfilter like: (targetfilter = (|(cn=Project1)(cn=Project2)) to restrict application of the aci to these entries and list several useers in the bind rules, or you could add na attribute like manager to hese entries, eg: cn=Project2,ou=Projects,dc=domain,dc=com ... manager: uid=serveruser1,ou=ServerUsers,dc=domain,dc=com and create an aci like: aci: (target=ldap:///dc=domain,dc=com;)(targetattr=*)(version 3.0;acl manag er-write; allow (all) userattr = manager#USERDN;) If the attribute you're using is multivalued, it should work defining several users. Ludwig If I add an attribute, can I define certain bind users as values? Thanks for helping out! -Matti -- 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] Client Config on CentOS 6
Hello On Wed, Jan 2, 2013 at 7:08 PM, Ali Jawad ali.ja...@splendor.net wrote: Hi All I am facing problems configuring a CentOS 6 server to act as an ldap client to my DS389 server. Does anyone know about a valid howto or can you please paste the sample configs to get it working ? Regards Are you using SSSD or NSLCD to configure Centos6 as a LDAP client, If you are using SSSD, You need to have TLS enabled on your LDAP server. Try this. Install nss-pam-ldapd pam_ldap # yum install nss-pam-ldapd pam_ldap Configure nslcd Using GUI. Authconfig will try to use sssd by default, in order to configure nslcd, enable FORCELEGACY option in authconfig as shown below. Edit /etc/sysconfig/authconfig, change FORCELEGACY option to yes FORCELEGACY=yes # authconfig --enableldap --enableldapauth --ldapserver=ldap01.example.com --ldapbasedn=dc=example,dc=com --enableforcelegacy --update Regards Arpit Tolani -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] AD - LDAP password expiration sync
Is it possible to synchronize password expiration times between AD and LDAP? We're just discovering that the AD sync to LDAP doesn't update shadowLastChange which we are currently using on the LDAP side. Should we use a different scheme for password expiration? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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 05:24), Jim Finn wrote: logconv.pl http://logconv.pl is your friend. What is the filter attributes you are searching? Are they indexed? Right. If you see notes=U in the slow search result (access log), the slowness could be coming from there. conn=65 op=1 RESULT err=0 tag=101 nentries=1 etime=0 *notes=U* Also, there is a known issue in the range search. https://fedorahosted.org/389/ticket/537 To work around the problem, we introduced a new config parameter nsslapd-rangelookthroughlimit, which is available on 389-ds-base-1.2.11.17 or newer. Thanks, --noriko On Jan 2, 2013, at 6:01 AM, Balaji P bala...@juniper.net mailto:bala...@juniper.net 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 mailto:us...@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] Client ACI question
uid=serveruser1,ou=ServerUsers,dc=domain,dc=com == has access to cn=Project1,ou=Projects,dc=domain,dc=com AND cn=Project2,ou=Projects,dc=domain,dc=com == deny access to other entries in ou=Projects,dc=domain,dc=com you could use targetfilter like: (targetfilter = (|(cn=Project1)(cn=Project2)) to restrict application of the aci to these entries and list several useers in the bind rules, or you could add na attribute like manager to hese entries, eg: cn=Project2,ou=Projects,dc=domain,dc=com ... manager: uid=serveruser1,ou=ServerUsers,dc=domain,dc=com and create an aci like: aci: (target=ldap:///dc=domain,dc=com;)(targetattr=*)(version 3.0;acl manag er-write; allow (all) userattr = manager#USERDN;) If the attribute you're using is multivalued, it should work defining several users. Thanks for the example! Now I'm starting to understand how it works. -Matti -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Client Config on CentOS 6
*Hi * *I am using NSLCD, does your suggestion still work ? I am not using TLS on the ldap server* *Regards* -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
