[389-users] Announcing 389 Directory Server 1.4.3.18

[Mark Reynolds]

   389 Directory Server 1.4.3.18

The 389 Directory Server team is proud to announce 389-ds-base version 
1.4.3.18


Fedora packages are available on Fedora 32.

https://koji.fedoraproject.org/koji/taskinfo?taskID=59774017 
 - Fedora 32


https://bodhi.fedoraproject.org/updates/FEDORA-2021-19b143e4a5 
 - Bodhi


The new packages and versions are:

 * 389-ds-base-1.4.3.18-1

Source tarballs are available for download at Download 
389-ds-base Source 




 Highlights in 1.4.3.18

 * Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install the server use *dnf install 389-ds-base*

To install the Cockpit UI plugin use *dnf install cockpit-389-ds*

After rpm install completes, run *dscreate interactive*

For upgrades, simply install the package. There are no further 
steps required.


There are no upgrade steps besides installing the new rpms

See Install_Guide 
 for 
more information about the initial installation and setup


See Source  
for information about source tarballs and SCM (git) access.



 New UI Progress (Cockpit plugin)

The new UI is complete and QE tested.


 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 



If you find a bug, or would like to see a new feature, file it in our 
GitHub project: https://github.com/389ds/389-ds-base 



 * Bump version to 1.4.3.18
 * Issue 4513 - CI Tests - fix test failures
 * Issue 4528 - Fix cn=monitor SCOPE_ONE search (#4529)
 * Issue 4504 - insure that repl_monitor_test use ldapi (for RHEL) -
   fix merge issue (#4533)
 * Issue 4315 - performance search rate: nagle triggers high rate
   of setsocketopt
 * Issue 4504 - Insure ldapi is enabled in repl_monitor_test.py (Needed
   on RHEL) (#4527)
 * Issue 4506 - BUG - Fix bounds on fd table population (#4520)
 * Issue 4521 - DS crash in deref plugin if dereferenced entry exists
   but is not returned by internal search (#4525)
 * Issue 4418 - lib389 - fix ldif2db import_cl parameter
 * Issue 4384 - Separate eventq into REALTIME and MONOTONIC
 * Issue 4418 - ldif2db - offline. Warn the user of skipped entries
 * Issue 4414 - disk monitoring - prevent division by zero crash
 * Issue 4507 - Improve csngen testing task (#4508)
 * Issue 4486 - Remove random ldif file generation from import test (#4487)
 * Issue 4489 - Remove return statement from a void function (#4490)
 * Issue 4419 - Warn users of skipped entries during ldif2db online
   import (#4476)
 * Issue 4418 - ldif2db - offline. Warn the user of skipped entries
 * Issue 4504 - Fix pytest test_dsconf_replication_monitor (#4505)
 * Issue 4480 - Unexpected info returned to ldap request (#4491)
 * Issue 4373 - BUG - one line cleanup, free results in mt if ent 0 (#4502)
 * Issue 4500 - Add cockpit enabling to dsctl
 * Issue 4272 - RFE - add support for gost-yescrypt for hashing
   passwords (#4497)
 * Issue 1795 - RFE - Enable logging for libldap and libber in error
   log (#4481)
 * Issue 4492 - Changelog cache can upload updates from a wrong
   starting point (CSN)
 * Issue 4373 - BUG - calloc of size 0 in MT build (#4496)
 * Issue 4483 - heap-use-after-free in slapi_be_getsuffix
 * Issue 4315 - performance search rate: nagle triggers high rate of
   setsocketopt (#4437)
 * Issue 4243 - Fix test (4th): SyncRepl plugin provides a wrong (#4475)
 * Issue 4460 - BUG - add machine name to subject alt names in SSCA (#4472)
 * Issue 4284 - dsidm fails to delete an organizationalUnit entry
 * Issue 4243 - Fix test: SyncRepl plugin provides a wrong cookie (#4466)

--

389 Directory Server Development Team

___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

[389-users] Re: A bit help about ACI?

[Mark Reynolds]

On 8/23/19 11:34 AM, Mark Reynolds wrote:


Moving to the correct list (389-users)...

On 8/23/19 9:05 AM, Miljan Žugić wrote:


I apologize in advance if this is wrong address 😊

I build up 2 389 DS server, make replication and up till now, all 
looks fine.


But I have some issue about ACI. Where I can find good forum or site 
to get some real examples of ACI ?


Or if you can help me…I want something like this, to make “anonymous” 
can do read, search and compare for levels B and D, but deny to A and 
E (actually I have problem with level E, I can do deny to anyone to 
level E or deeper, but I need some specific accounts to access level 
E or deeper, so…I stuck how to do that) :



First you should really read the access control docs:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_access_control

In order to do what you want you need two kinds of aci, allow and deny.  
You need deny rules because when you set an aci on a subtree it applies 
to all its children.  So as you noted you can deny level E, but it 
denies everyone even if they previously had access.  So you need to add 
new aci's on level E that open up access to the users/groups you want to 
have access.  So you might end up with "duplicate" aci's at different 
levels in your tree.


So on level B you have your anonymous access aci's - this will apply to 
all lower branches.  On Level E must have a deny "anonymous/anyone" 
rule, and then you add new acis to level E that open it back up for 
those you want to have access.


HTH,

Mark



Anyhow, BR 😃

*Miljan Žugić*

Sistemski inženjer |  Systems engineer

Sistemska podrška**|  Corporate IT

**

*T*  +381 11 3306514

*M*+381 62 250 523

*E*miljan.zu...@halcom.rs

*Halcom a.d.*

Beogradska 39 |   11000 Beograd |   Srbija

*www.halcom.rs*


--

389 Directory Server Development Team

___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

[389-users] Re: A bit help about ACI?

[Mark Reynolds]

Moving to the correct list (389-users)...

On 8/23/19 9:05 AM, Miljan Žugić wrote:


I apologize in advance if this is wrong address 😊

I build up 2 389 DS server, make replication and up till now, all 
looks fine.


But I have some issue about ACI. Where I can find good forum or site 
to get some real examples of ACI ?


Or if you can help me…I want something like this, to make “anonymous” 
can do read, search and compare for levels B and D, but deny to A and 
E (actually I have problem with level E, I can do deny to anyone to 
level E or deeper, but I need some specific accounts to access level E 
or deeper, so…I stuck how to do that) :


Anyhow, BR 😃

*Miljan Žugić*

Sistemski inženjer |  Systems engineer

Sistemska podrška**|  Corporate IT

**

*T*  +381 11 3306514

*M*+381 62 250 523

*E*  miljan.zu...@halcom.rs

*Halcom a.d.*

Beogradska 39 |   11000 Beograd |   Srbija

*www.halcom.rs*


--

389 Directory Server Development Team

___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

[389-users] Re: Memberof Not populating

[Mark Reynolds]

Try the memberof fixup task [1]

Also, you don't add memberOf, you add a user to group and plugin adds 
memberOf to the entry (if the entry allows the memberOf attribute!  
So you need an objectclass that allows memberOf like the objectclass 
"inetAdmin")


HTH,

Mark

[1] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/perl_scripts#fixup-memberof.pl


On 10/1/18 6:01 PM, John Trump wrote:
I am using 389-ds on RHEL6. None of my users have the memberof 
attribute visible when I view their accounts via admin console. I 
added the attribute to my own account but it is not being 
auto-populated. How do I get the memberof attribute assigned to all of 
my users and have it auto-populated?


___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org
___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

[389-users] Re: password policy

[Mark Reynolds]

On 09/26/2018 04:15 PM, Mark Reynolds wrote:




On 09/26/2018 03:51 PM, Alberto Viana wrote:

Hi Mark,

I already have this configuration but stopped to working after I 
enabled my password policy. Another thing is the error changed, its 
not the same when was missing prehashed config and my password was 
set to off.


When you turn syntax checking on then Password Admin functionally 
breaks, correct?  If so, it sounds like a bug then.  Please file a 
ticket with the exact steps to reproduce the problem.
Actually I think you need to set (again) psswordAdminDN in each subtree 
policy.  Please try this and let me know if it works.


Thanks,
Mark


https://pagure.io/389-ds-base/new_issue

Thanks,
Mark


On Wed, Sep 26, 2018, 16:47 Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:


Hi Alberto,

Only Directory Manager or a Password Admin can add pre-hashed
passwords.  It has nothing to do with password policy settings. 
For more on password admins see:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/password_administrators

HTH,

Mark


On 09/26/2018 02:31 PM, Alberto Viana wrote:

I have a password applied  globally like this:

dn:
cn=cn\3DnsPwPolicyEntry\2CDC\3Dmy\2CDC\3Ddomain,cn=nsPwPolicyContainer,dc=
 my,dc=domain
passwordLockout: off
passwordGraceLimit: 50
passwordWarning: 86400
passwordInHistory: 3
passwordMinLength: 8
passwordMinCategories: 3
passwordStorageScheme: SSHA512
passwordChange: on
passwordMaxAge: 31536000
passwordCheckSyntax: on
passwordExp: on
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,DC=my,DC=domain

In a sub OU, I have this policy:

#
cn\3DnsPwPolicyEntry\2Cou\3DPOPS\2COU\3DEXTERNOS\2Cou\3Dmy\2Cdc\3Dmy\2Cdc\3
 Ddomain, nsPwPolicyContainer, POPS, EXTERNOS, my, my.domain
dn:
cn=cn\3DnsPwPolicyEntry\2Cou\3DPOPS\2COU\3DEXTERNOS\2Cou\3Dmy\2Cdc\3Dmy\
 
2Cdc\3Ddomain,cn=nsPwPolicyContainer,ou=POPS,OU=EXTERNOS,ou=my,dc=my,dc=domain
passwordLockout: off
passwordGraceLimit: 50
passwordStorageScheme: SSHA
passwordChange: on
passwordMaxAge: 31536000
passwordCheckSyntax: off
passwordExp: off
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,ou=POPS,OU=EXTERNOS,dc=my,dc=domain

But when I try to add a prehashed password on this sub OU, I see
this kind of error:
LDAP: error code 19 - invalid password syntax - passwords with
storage scheme are not allowed

Is this an expected behavior even if in sub OU I have an
password policy with passwordCheckSyntax set to off? If so, do I
have any way to disable this behavior? (but I can not disable my
global password policy)

PS: The password policy is respecting the fact of
passwordCheckSyntax is set to off when I try to add a simple
password like '1234'.


___
389-users mailing list --389-us...@lists.fedoraproject.org
<mailto:389-us...@lists.fedoraproject.org>
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
<mailto:389-users-le...@lists.fedoraproject.org>
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org




___
389-users mailing list --389-us...@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org




___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org


___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

[389-users] Re: password policy

[Mark Reynolds]

Hi Alberto,

Only Directory Manager or a Password Admin can add pre-hashed 
passwords.  It has nothing to do with password policy settings. For more 
on password admins see:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/password_administrators

HTH,

Mark


On 09/26/2018 02:31 PM, Alberto Viana wrote:

I have a password applied  globally like this:

dn: 
cn=cn\3DnsPwPolicyEntry\2CDC\3Dmy\2CDC\3Ddomain,cn=nsPwPolicyContainer,dc=

 my,dc=domain
passwordLockout: off
passwordGraceLimit: 50
passwordWarning: 86400
passwordInHistory: 3
passwordMinLength: 8
passwordMinCategories: 3
passwordStorageScheme: SSHA512
passwordChange: on
passwordMaxAge: 31536000
passwordCheckSyntax: on
passwordExp: on
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,DC=my,DC=domain

In a sub OU, I have this policy:

# 
cn\3DnsPwPolicyEntry\2Cou\3DPOPS\2COU\3DEXTERNOS\2Cou\3Dmy\2Cdc\3Dmy\2Cdc\3

 Ddomain, nsPwPolicyContainer, POPS, EXTERNOS, my, my.domain
dn: 
cn=cn\3DnsPwPolicyEntry\2Cou\3DPOPS\2COU\3DEXTERNOS\2Cou\3Dmy\2Cdc\3Dmy\

 2Cdc\3Ddomain,cn=nsPwPolicyContainer,ou=POPS,OU=EXTERNOS,ou=my,dc=my,dc=domain
passwordLockout: off
passwordGraceLimit: 50
passwordStorageScheme: SSHA
passwordChange: on
passwordMaxAge: 31536000
passwordCheckSyntax: off
passwordExp: off
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,ou=POPS,OU=EXTERNOS,dc=my,dc=domain

But when I try to add a prehashed password on this sub OU, I see this 
kind of error:
LDAP: error code 19 - invalid password syntax - passwords with storage 
scheme are not allowed


Is this an expected behavior even if in sub OU I have an password 
policy with passwordCheckSyntax set to off? If so, do I have any way 
to disable this behavior? (but I can not disable my global password 
policy)


PS: The password policy is respecting the fact of passwordCheckSyntax 
is set to off when I try to add a simple password like '1234'.



___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org


___
389-users mailing list -- 389-us...@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

Re: [389-users] custom object classes and attributes

[Mark Reynolds]

On 10/17/2014 10:25 AM, Chase Miller wrote:
> Hello,
>
> So I have a development ldap server up and running with all of my
> custom object classes and attributes.  Now, is there a way to export
> these and import them on my new production boxes, so I don't have to
> re-create all of them.
Chase,

All of our custom schema should be located in the file
/etc/dirsrv/slapd-INSTANCE/schema/99user.ldif

You can just copy this file to a new server instance and restart the
server(or run the schema-reload task

)

Regards,
Mark
>
> Chase
>
>
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

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

Re: [389-users] secure replication failing

[Mark Reynolds]

On 08/22/2014 10:34 AM, Elizabeth Jones wrote:
>> On 08/20/2014 03:58 PM, Elizabeth Jones wrote:
>>> additional info -
>>> I increased logging on my supplier and see this error now -
>>>
>>> TLS: hostname does not match CN in peer certificate
>>>
>>> When I created the replication agreement, it is giving me a default
>>> consumer, I don't know why. The default is ldap1.mycompany.com:389.
>>>
>>> The certificate from ldap1 has just ldap1 as the name.  I entered ldap1
>>> and port 636 when I created the agreement, but after I do this it
>>> becomes
>>> ldap1.mycompany.com:636.  Would this be why its failing, it wants the
>>> certificate to have ldap1.mycompany.com in it rather than ldap1?
>> Correct, you need to use the fully qualified domain name for certificates.
>>
>> Regards,
>> Mark
> ok - what is confusing to me is that another server is able to replicate
> successfully to this server using this cert.  I used the same script to
> generate the certs on all 4 servers, the setupssl2.sh script.
Hmm not sure, maybe /etc/hosts is different on each machine?  But, I
know you need to use the fully qualified domain name when doing anything
"SSL".  Might have to redo the SSL setup and make sure setupSSL2.sh is
using the fully qualified domain name.
>
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

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

Re: [389-users] Multi-Theading writes to the same 389 Master Server

[Mark Reynolds]

On 08/20/2013 10:39 PM, Jeffrey Dunham wrote:
We have a customer that has been multi-threading behind multiple 
servers and writing to our Master server.   These writes come in the 
form of heavy spikes (1k over 5 second intervals) very much burst 
traffic and all the writes are adding new items to the same ou. While 
we have plans to throttle them I had a few questions:


a) If they're writing to the same ou / updating the same indexes are 
they blocked on one items success before another succeeds?
Writing to the same the subtree is not an issue.  Trying to update the 
same entry at the same time might slow it down a bit.  The access log 
"etime" result(microsecond logging 
<https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Configuration_and_Command-Line_Tool_Reference/logs-reference.html#Access_Log_Content-Access_Logging_Levels>) 
will tell you more during these bulk updates.
So in this case multi threading behind multiple boxes does not give 
them any performance impact.  I would guess this is the case, but I 
want to be sure.  Because replication seems to be fine which goes 
through a single thread iirc.


b) are there any performance tweaks that can help?  I thought maybe 
looking at /nsslapd-threadnumber.

/
This setting usually doesn't need to be adjusted, as the performance 
impact is not related to the number of threads, but what is being 
updated in the db.  Look at the "cn=monitor" output for the backend(e.g. 
cn=monitor,cn=example,cn=ldbm database,cn=plugins,cn=config).  You 
really want the cacheHitRatios to be as close 99% as possible.  Then 
adjust the cache sizes if needed.


Regards,
Mark

/
/
-Jeff


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


--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] Password + anything works ?

[Mark Reynolds]

Also what password storage scheme are you using?  For example "crypt" 
only checks the first 8 characters of a password.


On 11/12/2012 11:18 AM, Dan Lavu wrote:
In regards to a password policy? Just 389 or are you using winsync 
with AD? Because the password policy from AD does not transfer over. 
Also they are some extra steps if you want to setup an OU based 
password policy but if you just do it for the entire directory 
through ‘configuration’ it works with no issues.

Dan
*From:* Ali Jawad mailto:ali.ja...@splendor.net>>
*Sent:* November 12, 2012 6:00 AM
*To:* General discussion list for the 389 Directory server project.
*Subject:* [389-users] Password + anything works ?
Hi
I just noticed that you can use the password+ANYLetters and it will 
work, I.e. if the password is xyz xyz99 or xyzABC will work as well, 
is this a misconfiguration on my part or a bug ?

Regards

*
*


--
389 users mailing list
389-us...@lists.fedoraproject.org 
<mailto:389-us...@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users


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


--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] ldap-agent

[Mark Reynolds]

On 10/18/2012 10:45 AM, Michael Mercier wrote:

Hi,

 From my original message:  ;)

Whoops :-)

[root@ipaserver ~]# rpm -qa|grep 389
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-base-1.2.10.2-20.el6_3.x86_64

I don't see the 1.2.11 package in epel or the CentOS repos yet, has it been 
released outside of fedora?
Only fedora, but it will be in rhel 6.4(which hasn't been released 
yet).  If you have a support contract with us then a patch/hotfix might 
be possible.


The only "workaround" is to define one ldap server in the conf file.  
Not much of a workaround though :-(


Regards,
Mark


Thanks,
Mike



On 2012-10-18, at 10:04 AM, Mark Reynolds wrote:


Hi Michael,

What version of 389 are you using?

This looks like  I known issue:

https://fedorahosted.org/389/ticket/319

This was fixed in 1.2.11

Mark

On 10/15/2012 04:00 PM, Michael Mercier wrote:

Hello,

I am trying to configure ldap-agent with no luck.  I have followed the 
instructions at:http://directory.fedoraproject.org/wiki/Howto:SNMPMonitoring

NOTE: This system is running 389 under FreeIPA on CentOS 6.3

[root@ipaserver ~]# rpm -qa|grep net-snmp
net-snmp-5.5-41.el6_3.1.x86_64
net-snmp-libs-5.5-41.el6_3.1.x86_64
[root@ipaserver ~]# rpm -qa|grep 389
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-base-1.2.10.2-20.el6_3.x86_64
[root@ipaserver ~]# more /etc/dirsrv/config/ldap-agent.conf
# The agentx-master setting defines how to communicate
# with the SNMP master agent using the AgentX protocol.
# The default is to use a UNIX domain socket.  If your
# master agent is listening on a tcp port for AgentX
# subagents, use a line like the following:
#
# agentx-master localhost:705
agentx-master /var/agentx/master

# The agent-logdir settings defines where the subagent
# will write it's logfile.
agent-logdir /var/log/dirsrv

# The server setting specifies a Directory Server
# instance that you want to monitor. You must use one
# server setting for each Directory Server instance. The
# subagent requires at least one server setting to be
# specified. The server setting
# should be set to the name of the Directory Server
# instance you would like to monitor. For example:
#
# server slapd-phonebook
#
# To monitor multiple Directory Server instances,  add
# an additional server parameter for each instance:
#
server slapd-MPLS-LOCAL
server slapd-PKI-IPA
# server slapd-phonebook
# server slapd-example
# server slapd-directory

[root@ipaserver ~]# ldap-agent /etc/dirsrv/config/ldap-agent.conf
/usr/sbin/ldap-agent: line 56: 17263 Segmentation fault  ${dir}/${COMMAND} 
"$@"

NOTE: -D provides the same output

snmpd.conf has been minimally modified...
[root@ipaserver snmp]# diff snmpd.conf snmpd.conf.orig
55,57c55,56
<   #viewsystemviewincluded   .1.3.6.1.2.1.1
<   #viewsystemviewincluded   .1.3.6.1.2.1.25.1.1
<   view systemview  included .1
---

viewsystemviewincluded   .1.3.6.1.2.1.1
viewsystemviewincluded   .1.3.6.1.2.1.25.1.1

97,98d95
<   ## enable agentx for 389
<   master agentx

Thanks,
Mike


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

--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com



--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] ACI question

[Mark Reynolds]

On 09/21/2012 07:26 AM, Matti Alho wrote:

Hi,

One ACI related question. I've been learning to use ACIs and read 
various documentation. Let's say we have the following structure.


...
cn=Customer1,ou=Sales,dc=domain,dc=com
cn=Customer2,ou=Sales,dc=domain,dc=com


Then we have servers authenticating using credentials.
...
uid=server1,cn=VirtualServers,ou=Servers,dc=domain,dc=com
uid=server2,cn=VirtualServers,ou=Servers,dc=domain,dc=com
...

Question: What kind of ACI is needed to limit server1 access to read 
Customer1 entry only?
Would I need to create an ACI for each server separately? I was 
wondering that one should limit the amount of ACIs, so is there some 
other way to achieve this? Thanks for help!
If you need something like:  s1 -> c1, s2 -> c2, s3 -> c3...  Then you 
have two options, add individual aci's, or macro aci's.  Macro aci's can 
be a litte tricky, so without knowing what your data looks like, I'm not 
sure if macro aci's can actually be used.


So the individual aci would look like:

aci: (targetattr = "*") (target = 
"ldap:///cn=Customer1,ou=Sales,dc=domain,dc=com";) (version 3.0;acl 
"TEST";allow (read,search,compare)
(userdn = 
"ldap:///uid=server1,cn=VirtualServers,ou=Servers,dc=domain,dc=com ");)


This is pretty basic, but adding thousands of aci's will impact 
performance.  There are many ways you could this, but they all require 
extra work.  Macro aci's are the best way to go(if possible), or you 
could use "filtered roles", and use roledn instead of userdn in the aci, 
but this isn't necessarily an easier approach as you might need to add 
"extra" attributes to your entries(for role filtering).  It's something 
to look into.


Regards,
Mark

--

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


--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] Evaluating 1.2.11.6 on Fedora17: nsds5ReplicaEnabled

[Mark Reynolds]

  
  
Hi Juan,

The attribute is not there by default, you need to add it:

ldapmodify 
dn: cn=to replicaA, cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
changetype: modify
replace: nsds5ReplicaEnabled
nsds5ReplicaEnabled: off

Enjoy,
Mark

On 06/25/2012 07:54 AM, Juan Carlos Camargo wrote:

  
  Hi
  there,


One of the
  features of version 1.2.11.6 that caught my eye was the
  ability to enable/disable replication agreements. I've
  installed a copy on one of my lab machines, install went on
  flawlessly, but I seem to be unable to find where to apply the
  nsds5ReplicaEnabled attribute. I've tried adding it to the
  nsds5ReplicationAgreement object (same way as when I add the
  onewaysync attr) but I cant find it. Has it already been
  implemented?  Not pushing, simply investigating :)

  Regards!


-- 

  




Juan Carlos Camargo
Carrillo  
 957-211157
, 650932877
  
  

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

    
    -- 
Mark Reynolds
Senior Software Engineer
Red Hat, Inc
mreyno...@redhat.com
  

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

Re: [389-users] How To Enable Track when password was last modified passwordTrackUpdateTime

[Mark Reynolds]

Hi Tom,

You edit dse.ldif(while the server is shutdown), and add this attribute 
value in the cn=config entry:


passwordTrackUpdateTime: on

Mark

On 06/22/2012 10:20 AM, Tom Jalbert wrote:
I need this feature but I'm unsure where/how to turn it on. Could 
someone point me in the right direction?


Thanks,
-Tom

From "New Features in 1.2.11 lists"

Track when password was last modified

passwordTrackUpdateTime - if this is set to "on", the server will keep 
track of the last password update time


pwdUpdateTime - new operational attribute in entries holds the last 
password update time if passwordTrackUpdateTime is enabled



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


--
Mark Reynolds
Senior Software Engineer
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] Problem after disabling anonymous binds

[Mark Reynolds]

Hi Jeroen,

This is a known problem in 8.2, but it has been fixed in 9.0.  There are 
plans to backport this to 8.2, but this has not been completed yet.


Mark

On 06/21/2012 10:03 AM, Jeroen van Meeuwen (Kolab Systems) wrote:


Hi there,

I'm curious as to whether anyone else has experienced this problem before;

Disabling anonymous binds causes the 389-console to be unable to 
locate the entry corresponding to the user name used to login with (or 
so it seems).


In other words, disabling anonymous binds causes 389-console to be 
rendered disfunctional ;-)


I'd like to learn if this is a known problem, and/or whether there is 
a known workaround for the issue.


Thank you in advance,

Kind regards,

Jeroen van Meeuwen

--

Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com

m: +44 74 2516 3817

w: http://www.kolabsys.com

pgp: 9342 BF08



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


--
Mark Reynolds
Senior Software Engineer
Red Hat, Inc
mreyno...@redhat.com

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

Re: [389-users] disabled user attribute

[Mark Reynolds]

Hi Alberto,

We use "roles" for activating/disabling entries:

When a user is disabled, it is added to "disabled group":  
cn=nsmanageddisabledrole,dc=example,dc=com


audit log:

dn: uid=scarter,ou=People,dc=example,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=nsmanageddisabledrole,dc=example,dc=com

So to find all disabled users you can just search on:  
"nsRoleDN=cn=nsmanageddisabledrole,dc=example,dc=com"


Mark

On 05/11/2012 10:51 AM, Alberto Viana wrote:
I have an 389 DS server 1.2.10 and I disabled/inactivated  a user just 
for test (via 389 console) but I could not find what attribute was 
modified with this change. I need to know how to identify a 
disabled/inactivated user.



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

Re: [389-users] Master index (?!) feature request?

[Mark Reynolds]

Deigo,

In the meantime, you should get a performance boost if your top "tree" 
suffix(dc=company,dc=com) has the same attributes indexed as all the 
other sub-suffixes(db's).  Even if the db is empty, this will still help 
when you search on the top node.


Mark

On 05/04/2012 10:15 AM, Rich Megginson wrote:

On 05/04/2012 07:44 AM, Diego Woitasen wrote:
On Fri, May 4, 2012 at 10:24 AM, Rich Megginson  
wrote:

On 05/04/2012 06:47 AM, Diego Woitasen wrote:

I didn't know how to title this mail. I think this should be a feature
request in Track when I want to discuss this here first.

I have 389DS with 150 DBs with an structure similar to this:

dc=company,dc=com
ou=Headquarters,dc=company,dc=com
ou=Branch1,dc=company,dc=com
ou=Branch2,dc=company,dc=com
.
.
.
ou=Branch150,dc=company,dc=com

Each one of this subtrees are in separate DBs because I have subtree
replication between the 150 branches of the companies.

80% of the objects are in the ou=HeadQuarters. I've noticed that the
performance is definetely better when I use base ou=Headquarters in my
applications.

I have indexes on each DB but I think that the problem is that 389DS
doesn't have a master index or something to improve the searchs in
scenarios like mine.


Can you explain more about what you mean by "master index"?

An index that includes all the DBs. May be "global index" is a better
name. Right now, when you search for something, 389DS queries all the
DBs, one by one and with 150 DBs is a problem. There should be a way
to avoid that.


Ok, I see.  Yes, might be useful too for doing simple paged searches, 
server side sorting, vlv, etc. across multiple databases.








May be the solution is to implemen another replication code that
doesn't required separate DBs for subtree replication.

Shall I file a ticket? Or there is a solution now?

Regards,
  Diego






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

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

Re: [389-users] How to tell when database backup has finished?

[Mark Reynolds]

Hi Brett,

I think running the ldapsearch, and checking for error 32 is the easiest 
option.


I know you're not hitting this, but there are times when the task will 
stick around for a minute after its completed.  In that case, you can 
search for the task, and request the attribute "nsTaskStatus".  Then 
grep the value for "Backup finished", or "Backup failed".


Regards,
Mark

On 04/05/2012 08:22 AM, MATON Brett wrote:


Oops, the ldapsearch –b is wrong I think the search should be

ldapsearch -x -H ${HOST} -D ${BINDAS} -b ' 
cn=backup,cn=tasks,cn=config' -y ${PWFILE} 'cn='


In short, if I immediately start the tar task after running db2bak.pl 
in my script, the target backup directory doesn’t exist.


So I need to check if the backup task has finished.

The DB is so small here though that that task has finished ( and the 
task deleted ) before I can run an ldapsearch to check the base and 
filter (even if I put it in the script before ‘tar’).


*From:*389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*MATON Brett

*Sent:* 05 April 2012 14:10
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] How to tell when database backup has finished?

Bit of a fiddle:

Execute the d2bak.pl script in verbose mode and extract the task name:

task=$(${BACKUPCMD} -v -D "${BINDAS}" ${BACKUPOPTS} -a ${DSBACKUPDIR} 
2> /dev/null | grep "^adding new entry" )


ERR=$?

task=${task#*\"}

taskDN=${task%?}

Syslog message and exit if script failed:

if [ $ERR -ne 0 ]; then

LogIt "FAILED (${ERR})." "user.err";

exit 1;

fi

Until “task” isn’t found ( 32 ) hang around here:

while [ ${ERR} != 32 ]; do

(ldapsearch -x -H ${HOST} -D ${BINDAS} -b '${taskDN}' -y 
${PWFILE} > /dev/null 2>&1 )


ERR=$?

if [ ${ERR} != 32 ]; then

sleep 5s

fi

done

Again any thoughts welcomed.

Brett

---

*GreeNRB**
*/NRB considers its environmental responsibility and goes for green IT./
/May we ask you to consider yours before printing this e-mail? /**

*NRB, daring to commit
*/This e-mail and any attachments, which may contain information that 
is confidential and/or protected by intellectual property rights, are 
intended for the exclusive use of the above-mentioned addressee(s). 
Any use (including reproduction, disclosure and whole or partial 
distribution in any form whatsoever) of their content is prohibited 
without prior authorization of NRB. If you have received this message 
by error, please contact the sender promptly by resending this e-mail 
back to him (her), or by calling the above number. Thank you for 
subsequently deleting this e-mail and any files attached thereto./


---

*GreeNRB
*/NRB considers its environmental responsibility and goes for green IT./
/May we ask you to consider yours before printing this e-mail? /**

*NRB, daring to commit
*/This e-mail and any attachments, which may contain information that 
is confidential and/or protected by intellectual property rights, are 
intended for the exclusive use of the above-mentioned addressee(s). 
Any use (including reproduction, disclosure and whole or partial 
distribution in any form whatsoever) of their content is prohibited 
without prior authorization of NRB. If you have received this message 
by error, please contact the sender promptly by resending this e-mail 
back to him (her), or by calling the above number. Thank you for 
subsequently deleting this e-mail and any files attached thereto./




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

Re: [389-users] continuously segfault: 389ds 1.2.10.2 - 1.el6

[Mark Reynolds]

Hi Roberto,

We actually just fixed this on Friday via Ticket 305.  Rich would know 
more about the next release that would contain this fix.


Regards,
Mark

On 03/05/2012 09:18 AM, Roberto Polli wrote:

Hi Rich | everybody,

We just experience a continuous segfault (each 20mins).

This is the interesting part:
#3 0x7f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6
#4 0x7f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at
ldap/servers/slapd/ch_malloc.c:363
#5 0x7f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0,
context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0,
test_this=0x0, result=0x0,

When exploring the dump, I found that:
   - everything happens in cache;
   - it crashes while freeing a string containing a DN;
   - gdb was able to print out the given string;
   - the "guilty" code strangely clones the given string, then frees the
original one with slapi_ch_free();

Two sample stack traces and rpm infos follow.

Do you have any hint?
Thx+Peace,
R.



= Version =

rpm -qi 389-ds-base
Name : 389-ds-base Relocations: (not relocatable)
Version : 1.2.10.2 Vendor: (none)
Release : 1.el6 Build Date: Thu 23 Feb 2012 05:13:45 PM CET
Install Date: Mon 27 Feb 2012 12:17:52 PM CET Build Host: vmhost
Group : System Environment/Daemons Source RPM: 389-ds-
base-1.2.10.2-1.el6.src.rpm
Size : 4847506 License: GPLv2 with exceptions
Signature : (none)
URL : http://port389.org/
Summary : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server. The base package includes
the LDAP server and command line utilities for server administration.



  = Trace 1 =
#0 0x7f8e6357f885 in raise () from /lib64/libc.so.6
#1 0x7f8e63581065 in abort () from /lib64/libc.so.6
#2 0x7f8e635bc7a7 in __libc_message () from /lib64/libc.so.6
#3 0x7f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6
#4 0x7f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at
ldap/servers/slapd/ch_malloc.c:363
#5 0x7f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0,
context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0,
test_this=0x0, result=0x0,
props=0x7f8d9c3f8a5c) at ldap/servers/plugins/cos/cos_cache.c:2393
#6 0x7f8e5cfea9aa in cos_cache_vattr_types (handle=,
e=0x7f8dc8016d00, type_context=0x7f8d9c3f8ad0, flags=)
at ldap/servers/plugins/cos/cos_cache.c:2199
#7 0x7f8e65b3ad90 in slapi_vattr_list_attrs (e=0x7f8dc8016d00,
types=0x7f8d9c3f8c78, flags=4, buffer_flags=0x7f8d9c3f8cbc) at
ldap/servers/slapd/vattr.c:1289
#8 0x7f8e65b1fc00 in send_all_attrs (pb=0x2987dc0, e=0x7f8dc8016d00,
ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0,
urls=0x0)
at ldap/servers/slapd/result.c:915
#9 send_ldap_search_entry_ext (pb=0x2987dc0, e=0x7f8dc8016d00,
ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0,
urls=0x0) at ldap/servers/slapd/result.c:1362
#10 0x7f8e65b2046c in send_ldap_search_entry (pb=,
e=, ectrls=, attrs=,
attrsonly=) at ldap/servers/slapd/result.c:814
#11 0x004208e2 in ps_send_results (arg=) at
ldap/servers/slapd/psearch.c:373
#12 0x7f8e63f516f3 in ?? () from /lib64/libnspr4.so
#13 0x7f8e638f57f1 in start_thread () from /lib64/libpthread.so.0
#14 0x7f8e6363292d in clone () from /lib64/libc.so.6

= Trace 2 =
#0 0x7f8e6357f885 in raise () from /lib64/libc.so.6
#1 0x7f8e63581065 in abort () from /lib64/libc.so.6
#2 0x7f8e635bc7a7 in __libc_message () from /lib64/libc.so.6
#3 0x7f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6
#4 0x7f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at
ldap/servers/slapd/ch_malloc.c:363
#5 0x7f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0,
context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0,
test_this=0x0, result=0x0,
  props=0x7f8d9c3f8a5c) at ldap/servers/plugins/cos/cos_cache.c:2393
#6 0x7f8e5cfea9aa in cos_cache_vattr_types (handle=,
e=0x7f8dc8016d00, type_context=0x7f8d9c3f8ad0, flags=)
  at ldap/servers/plugins/cos/cos_cache.c:2199
#7 0x7f8e65b3ad90 in slapi_vattr_list_attrs (e=0x7f8dc8016d00,
types=0x7f8d9c3f8c78, flags=4, buffer_flags=0x7f8d9c3f8cbc) at
ldap/servers/slapd/vattr.c:1289
#8 0x7f8e65b1fc00 in send_all_attrs (pb=0x2987dc0, e=0x7f8dc8016d00,
ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0,
urls=0x0)
  at ldap/servers/slapd/result.c:915
#9 send_ldap_search_entry_ext (pb=0x2987dc0, e=0x7f8dc8016d00,
ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0,
urls=0x0) at ldap/servers/slapd/result.c:1362
#10 0x7f8e65b2046c in send_ldap_search_entry (pb=,
e=, ectrls=, attrs=,
  attrsonly=) at ldap/servers/slapd/result.c:814
#11 0x004208e2 in ps_send_results (arg=) at
ldap/servers/slapd/psearch.c:373
#12 0x7f8e63f516f3 in ?? () from /lib64/libnspr4.so
#13 0x7f8e638f57f1 in start_thread () from /lib64/libpthread.so.0
#14 0x7f8e6363292d in clone () 

Re: [389-users] how to change tiemzone

[Mark Reynolds]

Hi Shouben,

The server uses the system function time() to get the time and converts 
it with localtime_r().  This all comes from the host machine.  You would 
need make timezone changes via the OS/environment.


Do you mean changing the logging format?

[02/Mar/2012:09:05:28 -0500]

to

[02/Mar/2012:09:05:28 -EST]

Mark

On 03/02/2012 01:34 PM, Shouben Zhou wrote:
The LDAP server by default uses the GMT. is it possible to configure 
it to local time zone such as EST zone?


Thanks


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