[389-users] Re: Question on EQUALITY on index and schema definition

[Mark Reynolds]

On 8/5/19 8:57 AM, Mark Reynolds wrote:



On 8/4/19 9:55 AM, Lutz Berger wrote:

Hello,

I've come across a web site
that claims that an "equality index" is only allowed for attributes
that have "EQUALITY" in their description, "otherwise terrible things
will happen".

For example
>> *attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xxx NAME 'abCLZ'  
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE X-ORIGIN 'user defined' )**

*
For the sake of correctness, I've tried to build an equality-index 
for an attribute missing such description, e.g.


*>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xyz NAME 'abID'  SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )*


So what is happening is that the first example has a "matching rule" 
defined:   EQUALITY caseIgnoreMatch.  If you define such an attribute 
with this syntax you MUST have an equality index for that attribute.  
Otherwise the server has to manually perform this matching - which is 
VERY expensive.  Hence why you see an etime of 26 seconds.  Once its 
indexed for equality the matching rule can efficiently be processed.


Sorry this is actually incorrect.  The matching rule is not the problem 
in the case, since you are not using the matching rule in the search 
filter.   See 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/finding_directory_entries-ldap_search_filters#using-matching-rules 
   So this is just an issue of basic indexing.  You are doing an 
equality search, so you need an equality index, otherwise the server has 
to sequentially scan the database for matching entries.


Regards,

Mark

But you do not NEED to use this matching rule: EQUALITY 
caseIgnoreMatch, unless you have a requirement for it.  But you should 
always index your attribute for how you plan to use it. In this case 
you are doing an equality search: = so you 
would want an equality index (regardless of the presence of a matching 
rule).


HTH,

Mark



*Withour EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=34" access
[03/Aug/2019:14:21:00 +0200] conn=34 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:21:00 +0200] conn=34 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:21:26 +0200] conn=34 op=1 RESULT err=0 tag=101 
nentries=1 etime=26 notes=A*

[03/Aug/2019:14:21:26 +0200] conn=34 op=2 UNBIND
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 fd=65 closed - U1
[root@ur1 slapd-ur1devims]#

*With EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=35" access
[03/Aug/2019:14:24:18 +0200] conn=35 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:24:18 +0200] conn=35 op=1 RESULT err=0 tag=101 
nentries=1 etime=0*

[03/Aug/2019:14:24:18 +0200] conn=35 op=2 UNBIND
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 fd=65 closed - U1

*My question is now, is the EQUALITY part of the schema description 
really necessary**
**for building equality-indexes on attributes, since I couldn't 
reproduce any**obvious

problem.*

From the access pattern I see in the access log, building such an 
index is

definitely beneficial in sense of performance.

Thanks for your efforts!

Best regards,
  Lutz


--
Dipl.-Inform. Univ. Lutz Berger
Email: lutz.ber...@multigrid.de

Multigrid-Logo <http://multigrid.de/>

___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-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-users@lists.fedoraproject.org

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraprojec

[389-users] Re: Question on EQUALITY on index and schema definition

[Mark Reynolds]

On 8/4/19 9:55 AM, Lutz Berger wrote:

Hello,

I've come across a web site
that claims that an "equality index" is only allowed for attributes
that have "EQUALITY" in their description, "otherwise terrible things
will happen".

For example
>> *attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xxx NAME 'abCLZ'  
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE X-ORIGIN 'user defined' )**

*
For the sake of correctness, I've tried to build an equality-index for 
an attribute missing such description, e.g.


*>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xyz NAME 'abID'  SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )*


So what is happening is that the first example has a "matching rule" 
defined:   EQUALITY caseIgnoreMatch.  If you define such an attribute 
with this syntax you MUST have an equality index for that attribute.  
Otherwise the server has to manually perform this matching - which is 
VERY expensive.  Hence why you see an etime of 26 seconds.  Once its 
indexed for equality the matching rule can efficiently be processed.  
But you do not NEED to use this matching rule: EQUALITY caseIgnoreMatch, 
unless you have a requirement for it.  But you should always index your 
attribute for how you plan to use it.  In this case you are doing an 
equality search:  = so you would want an 
equality index (regardless of the presence of a matching rule).


HTH,

Mark



*Withour EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=34" access
[03/Aug/2019:14:21:00 +0200] conn=34 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:21:00 +0200] conn=34 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:21:26 +0200] conn=34 op=1 RESULT err=0 tag=101 
nentries=1 etime=26 notes=A*

[03/Aug/2019:14:21:26 +0200] conn=34 op=2 UNBIND
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 fd=65 closed - U1
[root@ur1 slapd-ur1devims]#

*With EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=35" access
[03/Aug/2019:14:24:18 +0200] conn=35 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:24:18 +0200] conn=35 op=1 RESULT err=0 tag=101 
nentries=1 etime=0*

[03/Aug/2019:14:24:18 +0200] conn=35 op=2 UNBIND
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 fd=65 closed - U1

*My question is now, is the EQUALITY part of the schema description 
really necessary**
**for building equality-indexes on attributes, since I couldn't 
reproduce any**obvious

problem.*

From the access pattern I see in the access log, building such an index is
definitely beneficial in sense of performance.

Thanks for your efforts!

Best regards,
  Lutz


--
Dipl.-Inform. Univ. Lutz Berger
Email: lutz.ber...@multigrid.de

Multigrid-Logo 

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: ldif2db for single cn import

[Mark Reynolds]

On 7/30/19 12:16 PM, Ghiurea, Isabella wrote:


Hi List

I am looking how can I import a single user/cn entry  using lidf2db  
from an an export taken using db2ldif -s option



You can not import individual entries, but you can add it with ldapmodify:


ldapmodify -D "cn=directory manager" -W -a -f 
file_with_single_entry_in_it.ldif



HTH,
Mark


thank you

Isabella


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.26

[Mark Reynolds]

   389 Directory Server 1.4.0.26

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


Fedora packages are available on Fedora 29

Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=36350217 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-6957eea289 



The new packages and versions are:

 * 389-ds-base-1.4.0.26-1

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




 Highlights in 1.4.0.26

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*.

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

See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 New UI Progress (Cockpit plugin)

The new UI is fully functional. There are still parts that need to be 
converted to ReactJS, but it is fully functional.


Configuration Tab   FinishedWritten in ReachJS
Server Tab  Yes No
Security TabYes Yes
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.26
 * Issue 50499 - Fix audit issues and remove jquery from the whitelist
 * Issue 50355 - SSL version min and max not correctly applied
 * Issue 50325 - Add Security tab to UI
 * Issue 50177 - Add a new CI test case, also added fixes in lib389

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.6

[Mark Reynolds]

   389 Directory Server 1.4.1.6

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


Fedora packages are available on Fedora 30 and rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=36349721 
 - Rawhide


https://koji.fedoraproject.org/koji/taskinfo?taskID=36350813 
 - Fedora 30


Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2019-73802bbbc9 



The new packages and versions are:

 * 389-ds-base-1.4.1.6-1

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




 Highlights in 1.4.1.6

 * 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 fully functional. There are still parts that need to be 
converted to ReactJS, but it is fully functional.


Configuration Tab   FinishedWritten in ReactJS
Server Tab  Yes No
Security TabYes Yes
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.1.6
 * Issue 50355 - SSL version min and max not correctly applied
 * Issue 50497 - Port cl-dump.pl tool to Python using lib389
 * Issue 48851 - investigate and port TET matching rules
   filter tests(Final)
 * Issue 50417 - fix regression from previous commit
 * Issue 50425 - Add jemalloc LD_PRELOAD to systemd drop-in file
 * Issue 50325 - Add Security tab to UI
 * Issue 49789 - By default, do not manage unhashed password
 * Issue 49421 - Implement password hash upgrade on bind.
 * Issue 49421 - on bind password upgrade proof of concept
 * Issue 50493 - connection_is_free to trylock
 * Issue 50459 - Correct issue with allocation state
 * Issue 50499 - Fix audit issues and remove jquery from the whitelist
 * Issue 50459 - c_mutex to use pthread_mutex to allow ns sharing
 * Issue 50484 - Add a release build dockerfile and
   dscontainer improvements
 * Issue 50486 - Update jemalloc to 5.2.0

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Unable to login to admin console after upgrade

[Mark Reynolds]

On 7/18/19 1:53 PM, Leonard wrote:

Trying to use "admin"

{SUBJECT_DN=CN=LDAPSERVER, SUBJECT={CN=LDAPSERVER}, SERIAL=3572, AFTERDATE=Tue 
Jan 02 12:01:36 2029, ISSUER={CN=389 DS}, SIGNATURE=SHA256withRSA, 
BEFOREDATE=Wed Jan 02 12:01:36 2019, KEYTYPE=RSA, REASONS={}, VERSION=3, 
ISSUER_DN=CN=389 DS}
https://LDAPSERVER:9830/[0:0] open> Ready
https://LDAPSERVER:9830/[0:0] accept> 
https://LDAPSERVER:9830/admin-serv/authenticate
https://LDAPSERVER:9830/[0:0] send> GET  \
https://LDAPSERVER:9830/[0:0] send> /admin-serv/authenticate \
https://LDAPSERVER:9830/[0:0] send>  HTTP/1.0
https://LDAPSERVER:9830/[0:0] send> Host: LDAPSERVER:9830
https://LDAPSERVER:9830/[0:0] send> Connection: Keep-Alive
https://LDAPSERVER:9830/[0:0] send> User-Agent: 389-Management-Console/1.1.17
https://LDAPSERVER:9830/[0:0] send> Accept-Language: en
https://LDAPSERVER:9830/[0:0] send> Authorization: Basic  \
https://LDAPSERVER:9830/[0:0] send>  \
https://LDAPSERVER:9830/[0:0] send>
https://LDAPSERVER:9830/[0:0] send>
https://LDAPSERVER:9830/[0:0] recv> HTTP/1.1 200 OK
https://LDAPSERVER:9830/[0:0] recv> Date: Thu, 18 Jul 2019 17:44:35 GMT
https://LDAPSERVER:9830/[0:0] recv> Server: Apache/2.2
HttpChannel.invoke: admin version = 2.2
https://LDAPSERVER:9830/[0:0] recv> Admin-Server: 389-Administrator/1.1.38
HttpChannel.invoke: admin version = 1.1.38
https://LDAPSERVER:9830/[0:0] recv> Content-Length: 314
https://LDAPSERVER:9830/[0:0] recv> Connection: close
https://LDAPSERVER:9830/[0:0] recv> Content-Type: text/html
https://LDAPSERVER:9830/[0:0] recv>
https://LDAPSERVER:9830/[0:0] recv> Reading 314 bytes...
https://LDAPSERVER:9830/[0:0] recv> 314 bytes read
Console.replyHandler: adminVersion = 1.1.38

Trying to use "uid=admin, ou=Administrators, ou=TopologyManagement, 
o=NetscapeRoot"

CommManager> New CommRecord (https://LDAPSERVER:9830/admin-serv/authenticate)
CREATE JSS SSLSocket
https://LDAPSERVER:9830/[1:0] open> Ready
https://LDAPSERVER:9830/[1:0] accept> 
https://LDAPSERVER:9830/admin-serv/authenticate
https://LDAPSERVER:9830/[1:0] send> GET  \
https://LDAPSERVER:9830/[1:0] send> /admin-serv/authenticate \
https://LDAPSERVER:9830/[1:0] send>  HTTP/1.0
https://LDAPSERVER:9830/[1:0] send> Host: LDAPSERVER:9830
https://LDAPSERVER:9830/[1:0] send> Connection: Keep-Alive
https://LDAPSERVER:9830/[1:0] send> User-Agent: 389-Management-Console/1.1.17
https://LDAPSERVER:9830/[1:0] send> Accept-Language: en
https://LDAPSERVER:9830/[1:0] send> Authorization: Basic  \
https://LDAPSERVER:9830/[1:0] send>  \
https://LDAPSERVER:9830/[1:0] send>
https://LDAPSERVER:9830/[1:0] send>
https://LDAPSERVER:9830/[1:0] recv> HTTP/1.1 401 Authorization Required
https://LDAPSERVER:9830/[1:0] error> HttpException:
Response: HTTP/1.1 401 Authorization Required
Status:   401
URL:  https://LDAPSERVER:9830/admin-serv/authenticate
https://LDAPSERVER:9830/[1:0] close i/o stream
https://LDAPSERVER:9830/[1:0] close socket
https://LDAPSERVER:9830/[1:0] close> Closed

I am not seeing a bind attempt in the access log when specifying the full DN.


Are you sure?  I forgot to mention that there is log buffering. You have 
to wait 30 seconds before the action is actually written to disk for the 
access log.  Also what is in the Admin Server access and error logs?  
/var/log/dirsrv/admin-serv/



Also, have you tried logging in as "cn=directory manager"?


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Unable to login to admin console after upgrade

[Mark Reynolds]

On 7/18/19 12:09 PM, Leonard Lawton wrote:


On 7/18/19 9:05 AM, Mark Reynolds wrote:


On 7/18/19 11:35 AM, Leonard wrote:
After upgrading to the following versions, I cannot login to the 
console. I am presented with the error "error result (49): invalid 
credentials".


389-admin-1.1.38-1.3.amzn1.x86_64
389-ds-base-libs-1.3.8.4-18.60.amzn1.x86_64
389-adminutil-1.1.21-1.1.amzn1.x86_64
389-ds-base-1.3.8.4-18.60.amzn1.x86_64

I don't remember exactly what the versions were prior.

In the slapd access log, I see the following error associated with 
the login attempt "conn=160830 op=0 RESULT err=49 tag=97 nentries=0 
etime=0.0026096322 - No suffix for bind dn found"


Can you provide the complete access log clip showing the BIND and the 
RESULT lines?


Here's everything associated with the connection.

[18/Jul/2019:15:08:34.131169944 +] conn=160830 fd=145 slot=145 SSL 
connection from xx.xx.xx.xx to xx.xx.xx.xx

[18/Jul/2019:15:08:34.157152520 +] conn=160830 TLS1.2 256-bit AES
[18/Jul/2019:15:08:34.157225415 +] conn=160830 op=0 BIND 
dn="(anon)" method=128 version=3
[18/Jul/2019:15:08:34.157305053 +] conn=160830 op=0 RESULT err=49 
tag=97 nentries=0 etime=0.0026096322 - No suffix for bind dn found


Well there is a problem, "(anon)" is not A DN, so of course it is not 
found.


I think you are running into a known issue...

The latest version of 389-adminutil is 1.1.23, but you are on 
389-adminutil-1.1.21


The latest version of 389-admin is 1.1.46-1, but you are on 
389-admin-1.1.38-1.3.  The latest version of 389-admin does have a fix 
around authentication.


I suspect if you log into the console using the full DN "uid=admin, 
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot" it will work, 
but without the fix from 1.1.46 this is probably your only option.


If you are using the full DN and it's not working, then run the console 
in debug mode:   389-console -D 9   Then post that output and the access 
log output again.


Thanks,

Mark





What this errors means is that the bind DN provided does not exist.  
So we need to see the full log output to see what BIND DN was 
actually used.




I am using the username "admin" when logging in. I am however able 
to bind successfully as "uid=admin, ou=Administrators, 
ou=TopologyManagement, o=NetscapeRoot" when using ldapsearch, etc on 
the same host as running the console.


SSLv2/3 are disabled and only TLS 1.2 is enabled on the server.

adm.conf has:

sslVersionMax: TLS1.2
sslVersionMin: TLS1.2

ssl bits from console.conf:

NSSNickname Admin-Console
NSSCipherSuite 
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

NSSProtocol TLSv1.2
NSSVerifyClient none
NSSPassPhraseDialog file:/etc/dirsrv/admin-serv/pin.txt

certutil:
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI

Server-Cert u,u,u
CA Certificate CTu,u,u
Admin-Console u,u,u



So far I've tried running setup-ds-admin.pl -u, deleting my .389 
directory, and changing the password of "uid=admin, 
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot"

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org



___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Unable to login to admin console after upgrade

[Mark Reynolds]

On 7/18/19 11:35 AM, Leonard wrote:

After upgrading to the following versions, I cannot login to the console. I am presented 
with the error "error result (49): invalid credentials".

389-admin-1.1.38-1.3.amzn1.x86_64
389-ds-base-libs-1.3.8.4-18.60.amzn1.x86_64
389-adminutil-1.1.21-1.1.amzn1.x86_64
389-ds-base-1.3.8.4-18.60.amzn1.x86_64

I don't remember exactly what the versions were prior.

In the slapd access log, I see the following error associated with the login attempt 
"conn=160830 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0026096322 - No suffix for 
bind dn found"


Can you provide the complete access log clip showing the BIND and the 
RESULT lines?


What this errors means is that the bind DN provided does not exist.  So 
we need to see the full log output to see what BIND DN was actually used.




I am using the username "admin" when logging in. I am however able to bind successfully 
as "uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot" when using 
ldapsearch, etc on the same host as running the console.

SSLv2/3 are disabled and only TLS 1.2 is enabled on the server.

adm.conf has:

sslVersionMax: TLS1.2
sslVersionMin: TLS1.2

ssl bits from console.conf:

NSSNickname Admin-Console
NSSCipherSuite 
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
NSSProtocol TLSv1.2
NSSVerifyClient none
NSSPassPhraseDialog file:/etc/dirsrv/admin-serv/pin.txt

certutil:
Certificate Nickname Trust Attributes
  SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
CA Certificate   CTu,u,u
Admin-Consoleu,u,u



So far I've tried running setup-ds-admin.pl -u, deleting my .389 directory, and changing 
the password of "uid=admin, ou=Administrators, ou=TopologyManagement, 
o=NetscapeRoot"
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Recommended SLAPD cache sizes

[Mark Reynolds]

Hi Paul,


On 7/16/19 9:16 AM, Paul Whitney wrote:
Is there some formula or recommendation on determining what would be 
the optimal cache settings for a directory server (389-ds of course) 
with following sizes? I looked at the DS 10 Admin Guide online and am 
getting conflicting information.  But the manual shows a table and 
suggests that the max size for the cn=config dbcache is 512MB.
There is no limit on the cache size value besides what you are limited 
to by a unsigned long integer.  Do you have a link to where it says 512 
MB is a maximum?
  But I tried with 5GB and it appears to work fine with it, although 
over time start to see negative values (prob not enough cache) and 
roevicts while running the dbmon.sh script.


__db files = ~6GB
groupRoot = 1.5GB
userRoot = 20GB

What values would yield best performance for:

cn=config dbcache? currently set to 5GB but are still seeing lots of 
roevicts. As much


userRoot entry cache? currently set to 21GB (hit ratio so far at 95%)

groupRoot entry cache? currently set to 2GB (hit ration so far at 96%)

Virtual machine configured with 8CPU, 128GB RAM. Load is in the low 
20's with occasional spikes to high 20's.


If you have 128 GB available to you then I would continue to increase 
the cache sizes until you get to 99% hit ratio for the two entry caches, 
and the db cache.  Also make sure the DN and NDN caches also have a 99% 
cache hit ratio:



https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/tuning-dn-cache


https://www.port389.org/docs/389ds/design/normalized-dn-cache.html




I would also look into running the DB on a RAM disk since you have the 
resources to do so:



https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/tuning-db-cache#db-cache-on-ram-disk



HTH,

Mark




Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 


*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this 
facsimile message to the intended recipient, you are hereby notified 
that any dissemination, or copying of this communication is strictly 
prohibited. If this message contains non-public personal information 
about any consumer or customer of the sender or intended recipient, 
you are further prohibited under penalty of law from using or 
disclosing the information to any third party by provisions of the 
federal Gramm-Leach-Bliley Act. If you have received this facsimile or 
electronic message in error, please immediately notify us by telephone 
and return or destroy the original message to assure that it is not 
read, copied, or distributed by others.



___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Startup issue

[Mark Reynolds]

What platform are you on?  What version of 389-ds-base?  Please provide 
more information when asking questions on the mailing list otherwise 
most people will not respond to your questions - just an FYI.



Since I am somewhat familiar with the issue I will provide more 
background information for you...


[1] This is on Oracle Linux with 389-ds-base-1.3.8

[2] The problem happened after applying OS updates

As I had previously stated to your coworker, this seems related to 
systemd.  Was systemd updated as part of the OS update that broke 389?  
If it was then you might need a fix that is not present in 
389-ds-base-1.3.8.  Note - this fix does not apply to RHEL 7.x, and it 
would break FreeIPA if we did add it - which is why it was not included 
in 389-ds-base-1.3.8, and only in 389-ds-base-1.4.x



Options:

[1] Backout OS updates that broke 389 DS

[2] You can build your own hotfix to see if it solves the problem:

https://www.port389.org/docs/389ds/contributing.html#building-the-project 



Here are the exact steps to build the hotfix

# git clone https://pagure.io/389-ds-base.git 



# cd 389-ds-base

# git checkout 389-ds-base-1.3.8

# git cherry-pick 1088afbb3

---> You probably need to install a lot of packages to do the build.  
Start with this, but on Oracle LInux there could be more you need to 
install:


# yum install libtool libtalloc* libtevent* libevent* systemd-devel icu 
libicu* net-snmp-devel pcre* pam* libdb-devel mod_nss gdb gcc-c++ 
perl-Archive-Tar  rpm-build git gdb rsync libatomic gperftools doxygen 
nspr* nss-devel bzip2-devel cracklib-devel libtool automake autoconf 
krb5-devel npm libcmocka-devel


# make -f rpm.mk rpms

# cd dist/rpms

# sudo yum install *


HTH,

Mark


On 7/10/19 12:04 PM, harlan.whit...@us.fujitsu.com wrote:


When attempting to start 389 I get the following error.

[root@ openldap]# systemctl status dirsrv@slapd.service

● dirsrv@slapd.service - 389 Directory Server slapd.

   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; 
vendor preset: disabled)


   Active: failed (Result: resources)

Jul 10 09:19:21local systemd[1]: Unit dirsrv@slapd.service entered 
failed state.


Jul 10 09:19:21 local systemd[1]: dirsrv@slapd.service failed.

Jul 10 09:33:32 local systemd[1]: Failed to load environment files: No 
such file or directory


Jul 10 09:33:32 local systemd[1]: dirsrv@slapd.service failed to run 
'start-pre' task: No such file or directory


Jul 10 09:33:32 local systemd[1]: Failed to start 389 Directory Server 
slapd..


Jul 10 09:33:32 local systemd[1]: dirsrv@slapd.service failed.

Jul 10 09:39:47 local systemd[1]: Failed to load environment files: No 
such file or directory


Jul 10 09:39:47 local systemd[1]: dirsrv@slapd.service failed to run 
'start-pre' task: No such file or directory


Jul 10 09:39:47 loccal systemd[1]: Failed to start 389 Directory 
Server slapd..


Jul 10 09:39:47 local systemd[1]: dirsrv@slapd.service failed.

Any ideas on the reason?

Thanks,

Harlan Whitley

Unix System Administration


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.5

[Mark Reynolds]

   389 Directory Server 1.4.1.5

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


Fedora packages are available on Fedora 30 and rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=36139436 
 - Rawhide


https://koji.fedoraproject.org/koji/taskinfo?taskID=36137973 
 - Fedora 30


Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2019-cc5eaae53e 



The new packages and versions are:

 * 389-ds-base-1.4.1.5-1

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




 Highlights in 1.4.1.5

 * 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 broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReactJS
Server Tab  Yes No
Security TabNo (coming soon)No
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.1.5
 * Issue 50431 - Fix regression from coverity fix (crash in
   memberOf plugin)
 * Issue 49239 - Add a new CI test case
 * Issue 49997 - Add a new CI test case
 * Issue 50177 - Add a new CI test case, also added fixes in lib389
 * Issue 49761 - Fix CI test suite issues
 * Issue 50474 - Unify result codes for add and modify of repl5 config
 * Issue 50472 - memory leak with encryption
 * Issue 50462 - Fix Root DN access control plugin CI tests
 * Issue 50462 - Fix CI tests
 * Issue 50217 - Implement dsconf security section
 * Issue 48851 - Add more test cases to the match test suite.
 * Issue 50378 - ACI’s with IPv4 and IPv6 bind rules do not work for
   IPv6 clients
 * Issue 50439 - fix waitpid issue when pid does not exist
 * Issue 50454 - Fix Cockpit UI branding
 * Issue 48851 - investigate and port TET matching rules
   filter tests(index)
 * Issue 49232 - Truncate the message when buffer capacity is exceeded

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.25

[Mark Reynolds]

   389 Directory Server 1.4.0.25

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


Fedora packages are available on Fedora 29

Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=36138415 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-1bfca53248 



The new packages and versions are:

 * 389-ds-base-1.4.0.25-1

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




 Highlights in 1.4.0.25

Bug fix


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*.

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

See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 New UI Progress (Cockpit plugin)

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReachJS
Server Tab  Yes No
Security TabNo (coming soon)No
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.25
 * Issue 50431 - Fix regression from coverity fix (memberOf plugin crash)

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Admin server and Slapd server will not start

[Mark Reynolds]

John,

What was the previous version and what was the new version?  rpm -qa | 
grep 389-ds-base


This looks related to changes we made around systemd, but I need to know 
what versions, and platform, you are on to further investigate.


Thanks,
Mark

On 7/8/19 12:44 PM, john.ber...@us.fujitsu.com wrote:


FYI,

Our server team patch my Test 389 ldap server the other night and now 
both my Admin Server and Slapd server will not start up. Below is the 
errors we are getting.


Admin Server

[root@rtxldslt01 slapd-rtxldslt01-4]# systemctl status 
dirsrv@admin-serv -l


● dirsrv@admin-serv.service  - 389 
Directory Server admin-serv.


   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service 
; enabled; vendor 
preset: disabled)


   Active: failed (Result: resources)

Jul 08 11:34:32 rtxldslt01.fnc.net.local systemd[1]: Failed to load 
environment files: No such file or directory


Jul 08 11:34:32 rtxldslt01.fnc.net.local systemd[1]: 
dirsrv@admin-serv.service  failed to 
run 'start-pre' task: No such file or directory


Jul 08 11:34:32 rtxldslt01.fnc.net.local systemd[1]: Failed to start 
389 Directory Server admin-serv..


Jul 08 11:34:32 rtxldslt01.fnc.net.local systemd[1]: Unit 
dirsrv@admin-serv.service  entered 
failed state.


Jul 08 11:34:32 rtxldslt01.fnc.net.local systemd[1]: 
dirsrv@admin-serv.service  failed.


Slapd Server

[root@rtxldslt01 slapd-rtxldslt01-4]# systemctl status 
dirsrv@slapd-rtxldslt01-4 -l


● dirsrv@slapd-rtxldslt01-4.service 
 - 389 Directory Server 
slapd-rtxldslt01-4.


   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service 
; enabled; vendor 
preset: disabled)


   Active: failed (Result: resources)

Jul 08 11:33:05 rtxldslt01.fnc.net.local systemd[1]: Failed to load 
environment files: No such file or directory


Jul 08 11:33:05 rtxldslt01.fnc.net.local systemd[1]: 
dirsrv@slapd-rtxldslt01-4.service 
 failed to run 'start-pre' 
task: No such file or directory


Jul 08 11:33:05 rtxldslt01.fnc.net.local systemd[1]: Failed to start 
389 Directory Server slapd-rtxldslt01-4..


Jul 08 11:33:05 rtxldslt01.fnc.net.local systemd[1]: Unit 
dirsrv@slapd-rtxldslt01-4.service 
 entered failed state.


Jul 08 11:33:05 rtxldslt01.fnc.net.local systemd[1]: 
dirsrv@slapd-rtxldslt01-4.service 
 failed.


Unfortunately I am not a Linux persons and I do not have the access to 
do thing on the server myself so I have to work between you guys and 
our server guys. Hope someone can help.


Thanks,

John


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Windows Sync Agreement not copying all objects

[Mark Reynolds]

On 7/2/19 9:33 PM, William Brown wrote:



On 3 Jul 2019, at 02:16, Mark Reynolds  wrote:



On 7/2/19 12:09 PM, Abhisheyk Deb wrote:

Hi,

It turns out it was mistake from our end, we were checking too early before the 
actual replication was done completely. Now that works properly.

The direction of replication is from AD -> 389 DS

But now we have a new requirement which is to copy from multiple Source Subtree 
from Windows to Linux.

To get both subtrees I used the winSyncSubtreePair multivalued attribute.

This is the replication agreement we have right now

dn: cn=UsersSyncAgreement,cn=replica,cn=dc\=example\,dc\=com\,cn=mapping 
tree,cn=config
changetype: add
objectclass: top
objectclass: nsDSWindowsReplicationAgreement
cn: UsersSyncAgreement
winSyncSubtreePair: 
cn=Users,dc=adexample,dc=com:ou=userandgroups,dc=example,dc=com
winSyncSubtreePair: 
ou=ItalyGroups,dc=adexample,dc=com:ou=userandgroups,dc=example,dc=com
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: adexample.com
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost: adexample.com
nsDS5ReplicaPort: 389
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicaBindDN: cn=replication user,cn=Users,dc=adexample,dc=com
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: secret
winSyncInterval: 1200

We want to copy both subtrees  cn=Users  and ou=ItalyGroups from the AD to 389 
DS subtree ou=userandgroups,dc=example,dc=com.

Once the 389 Directory Server is installed, and this replication agreement is 
configured, I am able to access the 389 DS.

But once I initialize this replication agreement using the following

dn: cn=UsersSyncAgreement,cn=replica,cn=dc\=example\,dc\=com\,cn=mapping 
tree,cn=config
changetype: modify
replace: nsds5BeginReplicaRefresh
nsds5BeginReplicaRefresh: start

The dirsrv service crashes.


The server should not crash, can you please get a stack trace:

https://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes



Can you help me with this problem, Am I configuring something wrong in the 
above replication agreement?

What if you remove the second winSyncSubtreePair attribute?  I'm not 100% sure 
using more than one winSyncSubtreePair attribute works anyway (I need to 
investigate that)...

But if you don't mind please get a stack trace so we can at least fix the crash.

Hey there (looking mainly at Mark here), do we have build instructions for 
winsync code, and a how-to? I'm sure we do, but I'm curious to set this up at 
home now to see how it works ...


You mean passSync?

http://www.port389.org/docs/389ds/development/buildingpasssync.html

Winsync is built into the replication code, so the admin guide has 
everything you need to know about its usage.


Mark


Thanks mate!



Thanks,

Mark


Thank you
Abhishek Deb


On Sun, Jun 30, 2019 at 9:24 PM William Brown  wrote:



On 25 Jun 2019, at 05:09, Abhisheyk Deb  wrote:

Hi,

We have the following setup.

Active Directory Server in US.
389 DS Server in Italy.

We are able to access the Active Directory Server from 389 DS.
We installed the sync agreement. No body is touching the AD, the number of 
objects that should copied is 21. But every time we are running the replication 
agreement, the number of objects being copied is always different. How can that 
be if there is no change happening at the AD Server.

Is the replication done over UDP or TCP.

Also is it because of distance and delay that is causing the synchronization 
issues.

If some can elaborate in this issue, it would be really helpful.

Sorry for the very late reply,

Replication like this, can be partial - it may not send all objects or 
structures, just ones defined in the agreement.

I think we'll need to see your winsync agreement from cn=config to know more, 
and to see what kind of objects are being sent, and what is not.

Is it objects from 389 to AD or in the other direction that are/are not being 
synced?

Thanks,


Thank you
Abhishek Deb
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


___
389-users mailing list --

[389-users] Re: Windows Sync Agreement not copying all objects

[Mark Reynolds]

On 7/2/19 12:09 PM, Abhisheyk Deb wrote:

Hi,

It turns out it was mistake from our end, we were checking too early 
before the actual replication was done completely. Now that works 
properly.


The direction of replication is from AD -> 389 DS

But now we have a new requirement which is to copy from multiple 
Source Subtree from Windows to Linux.


To get both subtrees I used the winSyncSubtreePair multivalued attribute.

This is the replication agreement we have right now

dn: 
cn=UsersSyncAgreement,cn=replica,cn=dc\=example\,dc\=com\,cn=mapping 
tree,cn=config

changetype: add
objectclass: top
objectclass: nsDSWindowsReplicationAgreement
cn: UsersSyncAgreement
winSyncSubtreePair: 
cn=Users,dc=adexample,dc=com:ou=userandgroups,dc=example,dc=com
winSyncSubtreePair: 
ou=ItalyGroups,dc=adexample,dc=com:ou=userandgroups,dc=example,dc=com

nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: adexample.com 
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost: adexample.com 
nsDS5ReplicaPort: 389
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicaBindDN: cn=replication user,cn=Users,dc=adexample,dc=com
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: secret
winSyncInterval: 1200

We want to copy both subtrees  cn=Users  and ou=ItalyGroups from the 
AD to 389 DS subtree ou=userandgroups,dc=example,dc=com.


Once the 389 Directory Server is installed, and this replication 
agreement is configured, I am able to access the 389 DS.


But once I initialize this replication agreement using the following

dn: 
cn=UsersSyncAgreement,cn=replica,cn=dc\=example\,dc\=com\,cn=mapping 
tree,cn=config

changetype: modify
replace: nsds5BeginReplicaRefresh
nsds5BeginReplicaRefresh: start

The dirsrv service crashes.



The server should not crash, can you please get a stack trace:

https://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes




Can you help me with this problem, Am I configuring something wrong in 
the above replication agreement?


What if you remove the second winSyncSubtreePair attribute?  I'm not 
100% sure using more than one winSyncSubtreePair attribute works anyway 
(I need to investigate that)...


But if you don't mind please get a stack trace so we can at least fix 
the crash.


Thanks,

Mark



Thank you
Abhishek Deb


On Sun, Jun 30, 2019 at 9:24 PM William Brown > wrote:




> On 25 Jun 2019, at 05:09, Abhisheyk Deb mailto:abhisheyk...@gmail.com>> wrote:
>
> Hi,
>
> We have the following setup.
>
> Active Directory Server in US.
> 389 DS Server in Italy.
>
> We are able to access the Active Directory Server from 389 DS.
> We installed the sync agreement. No body is touching the AD, the
number of objects that should copied is 21. But every time we are
running the replication agreement, the number of objects being
copied is always different. How can that be if there is no change
happening at the AD Server.
>
> Is the replication done over UDP or TCP.
>
> Also is it because of distance and delay that is causing the
synchronization issues.
>
> If some can elaborate in this issue, it would be really helpful.

Sorry for the very late reply,

Replication like this, can be partial - it may not send all
objects or structures, just ones defined in the agreement.

I think we'll need to see your winsync agreement from cn=config to
know more, and to see what kind of objects are being sent, and
what is not.

Is it objects from 389 to AD or in the other direction that
are/are not being synced?

Thanks,

>
> Thank you
> Abhishek Deb
> ___
> 389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.24

[Mark Reynolds]

   389 Directory Server 1.4.0.24

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


Fedora packages are available on Fedora 29

Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=35826090 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-688ce6cf00 



The new packages and versions are:

 * 389-ds-base-1.4.0.24-1

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




 Highlights in 1.4.0.24

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*.

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

See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 New UI Progress (Cockpit plugin)

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReachJS
Server Tab  Yes No
Security TabNo  No
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.24
 * Issue 50052 - Fix rpm.mk according to audit-ci change
 * Issue 50276 - 389-ds-console is not built on RHEL8 if cockpit_dist
   is already present
 * Issue 50041 - Add the rest UI Plugin tabs - Part 1
 * Issue 50217 - Implement dsconf security section
 * Issue 49602 - Revise replication status messages
 * Issue 50431 - Fix regression from coverity fix
 * Issue 50431 - Fix covscan warnings
 * Issue 50426 - nsSSL3Ciphers is limited to 1024 characters
 * Issue 50428 - Log the actual base DN when the search fails with
   “invalid attribute request”
 * Issue 50329 - (2nd) Possible Security Issue: DOS due to
   ioblocktimeout not applying to TLS
 * Issue 50413 - ds-replcheck - Always display the Result Summary
 * Issue 50355 - NSS can change the requested SSL min and max versions

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.4

[Mark Reynolds]

   389 Directory Server 1.4.1.4

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


Fedora packages are available on Fedora 30 and rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=35621238 
 - Rawhide


https://koji.fedoraproject.org/koji/taskinfo?taskID=35620824 
 - Fedora 30


Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2019-ed262351ae 



The new packages and versions are:

 * 389-ds-base-1.4.1.4-1

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




 Highlights in 1.4.1.4

 * 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 broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReactJS
Server Tab  Yes No
Security TabNo  No
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.1.4
 * Issue 49361 - Use IPv6 friendly network functions
 * Issue 48851 - Investigate and port TET matching rules
   filter tests(bug772777)
 * Issue 50446 - NameError: name ‘ds_is_older’ is not defined
 * Issue 49602 - Revise replication status messages
 * Issue 50439 - Update docker integration to work out of source directory
 * Issue 50037 - revert path changes as it breaks prefix/rpm builds
 * Issue 50431 - Fix regression from coverity fix
 * Issue 50370 - CleanAllRUV task crashing during server shutdown
 * Issue 48851 - investigate and port TET matching rules
   filter tests(match)
 * Issue 50417 - Fix missing quote in some legacy tools
 * Issue 50431 - Fix covscan warnings
 * Revert “Issue 49960 - Core schema contains strings instead of
   numer oids”
 * Issue 50426 - nsSSL3Ciphers is limited to 1024 characters
 * Issue 50052 - Fix rpm.mk according to audit-ci change
 * Issue 50365 - PIDFile= references path below legacy directory /var/run/
 * Issue 50428 - Log the actual base DN when the search fails with
   “invalid attribute request”
 * Issue 50329 - (2nd) Possible Security Issue: DOS due to
   ioblocktimeout not applying to TLS
 * Issue 50417 - Revise legacy tool scripts to work with new
   systemd changes
 * Issue 48851 - Add more search filters to vfilter_simple test suite
 * Issue 49761 - Fix CI test suite issues
 * Issue 49875 - Move SystemD service config to a drop-in file
 * Issue 50413 - ds-replcheck - Always display the Result Summary
 * Issue 50052 - Add package-lock.json and use “npm ci”
 * Issue 48851 - investigate and port TET matching rules filter
   tests(vfilter simple)
 * Issue 50355 - NSS can change the requested SSL min and max versions
 * Issue 48851 - investigate and port TET matching rules
   filter tests(vfilter_ld)
 * Issue 50390 - Add Managed Entries Plug-in Config Entry schema
 * Issue 49730 - Remove unused Mozilla ldapsdk variables

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: help. directory manager bypassing password policies, alternatives?

[Mark Reynolds]

On 6/3/19 1:16 PM, Eric Freeman wrote:


Between 389 LDAP versions 1.2.11.15-33 and 1.2.11.15-97, we're finding 
that the Directory Manager account can bypass configured password 
policies and set user passwords to anything. I believe this is now by 
design, but is there a configuration file flag to revert to the 
previous behavior where Directory Manager needed to conform to the 
password policy?

Sorry there is not.


If not, how do we create a user account in 389 ldap server with rights 
to check and update user password hashes, and still enforce configured 
password policies?


You create a new user, and you add an ACI to the suffix to allow this 
user to update passwords.



Create a user, something like this

dn: uid=password update user,ou=people,dc=example,dc=com


Add "aci" to the suffix to allow this user rights to update userpassword

ldapmodify -D "cn=directory manager" -W
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "userPassword") (version 3.0; acl "Allow user to 
update passwords"; allow (write) (userdn = "ldap:///uid=password update 
user,ou=people,dc=example,dc=com");)



That should do it.

HTH,

Mark




Please advise

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.23

[Mark Reynolds]

   389 Directory Server 1.4.0.23

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


Fedora packages are available on Fedora 28, and 29

Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=35036509 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=35036511 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-5283c79c6b 



F28 https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef4d555898 



The new packages and versions are:

 * 389-ds-base-1.4.0.23-1

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




 Highlights in 1.4.0.23

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*.

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

See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 New UI Progress (Cockpit plugin)

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReachJS
Server Tab  Yes No
Security TabNo  
Database TabYes Yes
Replication Tab Yes No
Schema Tab  Yes No
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.23
 * Ticket 50041 - Add the rest UI Plugin tabs - Part 2
 * Ticket 50340 - 2nd try - structs for diabled plugins will not be freed
 * Ticket 50393 - maxlogsperdir accepting negative values
 * Ticket 50396 - Crash in PAM plugin when user does not exist
 * Ticket 50390 - Add Managed Entries Plug-in Config Entry schema
 * Ticket 50251 - clear text passwords visable in CLI verbose mode logging
 * Ticket 50378 - ACI’s with IPv4 and IPv6 bind rules do not work for
   IPv6 clients
 * Ticket 50370 - CleanAllRUV task crashing during server shutdown
 * Ticket 50340 - structs for disabled plugins will not be freed
 * Ticket 50363 - ds-replcheck incorrectly reports error out of order
   multi-valued attributes
 * Ticket 50329 - revert fix
 * Ticket 50340 - structs for diabled plugins will not be freed
 * Ticket 50327 - Add replication conflict support to UI
 * Ticket 50327 - Add replication conflict entry support to lib389/CLI
 * Ticket 50329 - Possible Security Issue: DOS due to ioblocktimeout
   not applying to TLS
 * Ticket 49990 - Increase the default FD limits
 * Ticket 50291 - Add monitor tab functionality to Cockpit UI
 * Ticket 50305 - Revise CleanAllRUV task restart process
 * Ticket 50303 - Add task creation date to task data
 * Ticket 50240 - Improve task logging

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.3

[Mark Reynolds]

   389 Directory Server 1.4.1.3

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


Fedora packages are available on Fedora 30 and rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=35035898 
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35035898> - Rawhide


https://koji.fedoraproject.org/koji/taskinfo?taskID=35035974 
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35035974> - Fedora 30


Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac3a8134ef 
<https://bodhi.fedoraproject.org/updates/FEDORA-2019-ac3a8134ef>


The new packages and versions are:

 * 389-ds-base-1.4.1.3-1

Source tarballs are available for download at Download 
389-ds-base Source 
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.3.tar.bz2>



 Highlights in 1.4.1.3

 * Bug fixes


 Installation and Upgrade

See Download <https://www.port389.org/docs/389ds/download.html> 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 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 
<https://www.port389.org/docs/389ds/howto/howto-install-389.html> for 
more information about the initial installation and setup


See Source <https://www.port389.org/docs/389ds/development/source.html> 
for information about source tarballs and SCM (git) access.



 New UI Progress (Cockpit plugin)

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


Configuration Tab   FinishedWritten in ReachJS  
Server Tab  Yes No  
Security TabNo  
Database TabYes Yes 
Replication Tab Yes  No 
Schema Tab  Yes No  
Plugin Tab  Yes Yes 
Monitor Tab Yes Yes 


 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 
Pagure project: https://pagure.io/389-ds-base


 * Fri May 24 2019 Mark Reynolds mreyno...@redhat.com
   <mailto:mreyno...@redhat.com> - 1.4.1.3-1
 * Bump version to 1.4.1.3
 * Issue 49761 - Fix CI test suite issues
 * Issue 50041 - Add the rest UI Plugin tabs - Part 2
 * Issue 50340 - 2nd try - structs for diabled plugins will not be freed
 * Issue 50403 - Instance creation fails on 1.3.9 using perl utils and
   latest lib389
 * Issue 50389 - ns-slapd craches while two threads are polling the
   same connection
 * Issue 48851 - investigate and port TET matching rules
   filter tests(scanlimit)
 * Issue 50037 - lib389 fails to install in venv under non-root user
 * Issue 50112 - Port ACI test suit from TET to python3(userattr)
 * Issue 50393 - maxlogsperdir accepting negative values
 * Issue 50112 - Port ACI test suit from TET to python3(roledn)
 * Issue 49960 - Core schema contains strings instead of numer oids
 * Issue 50396 - Crash in PAM plugin when user does not exist
 * Issue 50387 - enable_tls() should label ports with ldap_port_t
 * Issue 50390 - Add Managed Entries Plug-in Config Entry schema
 * Issue 50306 - Fix regression with maxbersize
 * Issue 50384 - Missing dependency: cracklib-dicts
 * Issue 49029 - [RFE] improve internal operations logging
 * Issue 49761 - Fix CI test suite issues
 * Issue 50374 - dsdim posixgroup create fails with ERROR
 * Issue 50251 - clear text passwords visable in CLI verbose mode logging
 * Issue 50378 - ACI’s with IPv4 and IPv6 bind rules do not work for
   IPv6 clients
 * Issue 48851 - investigate and port TET matching rules filter tests
 * Issue 50220 - attr_encryption test suite failing
 * Issue 50370 - CleanAllRUV task crashing during server shutdown
 * Issue 50340 - structs for disabled plugins will not be freed
 * Issue 50164 - Add test for dscreate to basic test suite
 * Issue 50363 - ds-replcheck incorrectly reports error out of order
   multi-valued attributes
 * Issue 49730 - MozLDAP bindings have been unsupported for a while
 * Issue 50353 - Categorize tests by tiers
 * Issue 50303 - Add creation date to task data
 * Issue 50358 - Create a Bitwise Plugin class in plugins.py
 * Remove the nss3 path prefix from the cert.h C preprocessor source
   file inclusion
 * Issue 50329 - revert fix
 * Issue 50112 - Port ACI test suit from TET to python3(keyaci)
 * Issue 50344 - tidy rpm vs build systemd flag handling
 * Issue 50067 - Fix krb5 dependency in a specfile
 * Issue 50340 - structs for diabled plugins will not be freed
 * Issue 50327 - Add replication conflict support to UI
 * Issue 50327 - Add replication conflict entr

[389-users] Re: acis in 99user.ldif and target on subtree

[Mark Reynolds]

On 5/23/19 12:38 PM, Angel Bosch Mora wrote:

Hi!

two more questions:

1- when migrating should I take care about ACIs in 99user.ldif? rightnow there 
are four entries:

aci: (target="ldap:///cn=schema;)(targetattr !="aci")(version 3.0;acl "anonymous, no 
acis"; allow (read, search, compare) userdn = "ldap:///anyone;;)
aci: (targetattr="*")(version 3.0; acl "Configuration Administrators Group"; allow (all) 
groupdn="ldap:///cn=Configuration Administrators,ou=Groups,ou=TopologyManagement,o=NetscapeRoot";)
aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (all) 
userdn="ldap:///uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot;;)
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = 
"ldap:///cn=slapd-hhh-ng,cn=389 Directory Server,cn=Server 
Group,cn=xx.yy.net,ou=xx.net,o=NetscapeRoot";)
modifiersname: cn=directory manager
modifytimestamp: 20101105155413Z

but I never did those.
These are default aci's that are mainly used for the 389-console (the 
o=NetscapeRoot aci's).   If you are using the console then I would keep 
them.



2- is it mandatory to specify target when setting an ACI in a subtree?


No.  If there is no target defined in the aci then the target becomes 
the entry the aci was added to.


HTH,

Mark






best regards,

abosch
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol 
fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i 
pot contenir informacio confidencial. En cap cas no heu de copiar aquest 
missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no 
sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) 
us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona 
remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: keeping internal attributes on export/import

[Mark Reynolds]

On 5/23/19 4:13 AM, Angel Bosch Mora wrote:

hi!

quick question: is there any reason to keep modifyTimestamp, modifiersName, 
createTimestamp, and creatorsName when reimporting on a migration?


These are important attributes about each each entry.  Knowing when an 
entry was created or modified can be very valuable.  It allows for some 
basic type of auditing, and these attributes are used by other things 
like the UI, and other products like Freeipa.


That being said, you don't need them (they are not required attributes 
via the schema definitions).  If you want to strip them from an LDIF 
file you are free to do so, and it will not cause a LDIF import to 
fail.  But stripping them permanently removes potentially useful 
information.  Sounds like you are not worried about that, but I wanted 
to make sure you were aware :-)


Mark




abosch

-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol 
fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i 
pot contenir informacio confidencial. En cap cas no heu de copiar aquest 
missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no 
sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) 
us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona 
remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: migrations

[Mark Reynolds]

On 4/17/19 10:47 AM, natan wrote:

Hi
Is any chance to import all from openldap ?

I install 389 Directory Server - from faq in webside + 389-console

Now I wanted to import db from openldap - I get root.ldif

My openldap have a "weird" root in tree

likes:

"dn: o=mydomain,c=pl
objectClass: top
objectClass: organization
o: iq
structuralObjectClass: organization
creatorsName: cn=admin,o=mydomain,c=pl
modifiersName: cn=admin,o=mydomain,c=pl
createTimestamp: 20040814001228Z
modifyTimestamp: 20040814001228Z
entryCSN: 20040814001228.00Z#01#000#00
contextCSN: 20190409221815.398628Z#00#000#00

dn: ou=accounts,o=mydoamin,c=pl
objectClass: top
objectClass: organizationalUnit
ou: accounts
structuralObjectClass: organizationalUnit
entryUUID: 5f134a08-81d2-1028-8595-ae63cd734628
creatorsName: cn=admin,o=mydomain,c=pl
modifiersName: cn=admin,o=mydomain,c=pl
createTimestamp: 20040814001228Z
modifyTimestamp: 20040814001228Z
entryCSN: 20040814001228.00Z#02#000#00"


I was looking in documentation 389 for how to add/import schema but I
nothing found
(qmail.schema)

can someone help me with import db and qmail.schema ?


Here is a very old wiki doc on the topic (I'm not sure this even works 
anymore):


http://www.port389.org/docs/389ds/howto/howto-openldapmigration.html

Basically you need to convert openldap schema to a syntax that 389 DS 
understands.  Here are the docs for 389 schema as a reference:


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

Once you get the schema straightened out and added to 389 DS, you should 
be able to import that ldif file into 389 DS.  Of course you first need 
to define the suffix:  o=mydomain,c=pl


For doing that see:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/configuring_directory_databases#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes

HTH,

Mark



  
--

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: [389-announce] Announcing 389 Directory Server 1.4.0.22

[Mark Reynolds]

Well RHEL/Centos are downstream, these particular releases are just 
upstream.  So 1.4.0 is for RHEL 8.0, and 1.4.1 is for RHEL 8.1, but for 
the layered product RHDS (with new cockpit UI) that is going to be in 
8.1.  So its going to be a while until you see these releases downstream...


On 4/3/19 5:59 PM, Vandenburgh, Steve Y wrote:


Are packages available for testing on RedHat/CentOS Linux?

Steve Vandenburgh

LDAP Directory Services/Identity Management

*From:*Mark Reynolds 
*Sent:* Friday, March 29, 2019 5:06 PM
*To:* 389-annou...@lists.fedoraproject.org; General discussion list 
for the 389 Directory server project. <389-users@lists.fedoraproject.org>

*Subject:* [389-announce] Announcing 389 Directory Server 1.4.0.22


*389 Directory Server 1.4.0.22*

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


Fedora packages are available on Fedora 28, and 29

Fedora 29

http://koji.fedoraproject.org/koji/buildinfo?buildID=1240342

Fedora 28

http://koji.fedoraproject.org/koji/buildinfo?buildID=1240341

Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-35ca2e35b3

F28 https://bodhi.fedoraproject.org/updates/FEDORA-2019-351b02e21e

The new packages and versions are:

  * 389-ds-base-1.4.0.22-1

Source tarballs are available for download at Download 389-ds-base 
Source 
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.22.tar.bz2>



  *Highlights in 1.4.0.22*

Bug fixes


  *Installation and Upgrade*

See Download <https://markdownlivepreview.com/download.html> for 
information about setting up your yum repositories.


To install, use **dnf install 389-ds-base**, then run **dscreate**. To 
install the Cockput UI plugin use "dnf install cockpit-389-ds"


See Install_Guide 
<https://markdownlivepreview.com/howto/howto-install-389.html> for 
more information about the initial installation, setup, and upgrade


See Source <https://markdownlivepreview.com/development/source.html> 
for information about source tarballs and SCM (git) access.



  *New UI Progress (Cockpit plugin)*

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


*Configuration Tab*



*Finished*



*Written in ReactJS*

Server tab



Yes



No

Security Tab



No



Database Tab



Yes



Yes

Replication Tab



Yes



No

Schema Tab



Yes



No

Plugins Tab



Yes



Yes

Monitor Tab



No




  *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 
Pagure project: https://pagure.io/389-ds-base


  * Bump version to 1.4.0.22
  * Ticket 50308 - Revise memory leak fix
  * Ticket 50308 - Fix memory leaks for repeat binds and replication
  * Ticket 49873 - (cont 3rd) cleanup debug log
  * Ticket 49873 - (cont 2nd) Contention on virtual attribute lookup
  * Ticket 50292 - Fix Plugin CLI and UI issues
  * Ticket 50289 - Fix various database UI issues
  * Ticket 50300 - Fix memory leak in automember plugin
  * Ticket 50265 - the warning about skew time could last forever
  * Ticket 50260 - Invalid cache flushing improvements
  * Ticket 49561 - MEP plugin, upon direct op failure, will delete
twice the same managed entry
  * Ticket 50077 - Do not automatically turn automember postop modifies on
  * Ticket 50282 - OPERATIONS ERROR when trying to delete a group with
automember members
  * Ticket 49873 - (cont) Contention on virtual attribute lookup
  * Ticket 50260 - backend txn plugins can corrupt entry cache
  * Ticket 50041 - Add CLI functionality for special plugins
  * Ticket 50273 - reduce default replication agmt timeout
  * Ticket 50234 - one level search returns not matching entry
  * Ticket 50232 - export creates not importable ldif file
  * Ticket 50215 - UI - implement Database Tab in reachJS
  * Ticket 50238 - Failed modrdn can corrupt entry cache
  * Ticket 50236 - memberOf should be more robust
  * Ticket 50151 - lib389 support cli add/replace/delete on objects
  * Ticket 50155 - password history check has no way to just check the
current password
  * Ticket 49873 - Contention on virtual attribute lookup
  * Ticket 49658 - In replicated topology a single-valued attribute
can diverge
  * Ticket 50177 - import task should not be deleted too rapidely
after import finishes to be able to query the status
  * Ticket 50165 - Fix issues with dscreate

This communication is the property of CenturyLink and may contain 
confidential or privileged information. Unauthorized use of this 
communication is strictly prohibited and may be unlawful. If you have 
received this communication in error, please immediately notify

[389-users] Re: MIssing schemas?

[Mark Reynolds]

Hi Deborah,

Yes things changed since 1.2.x, the standard schema was moved to:

/usr/share/dirsrv/schema/

Only custom schema gets added to the instance's schema directory.

Regards,

Mark

On 4/3/19 9:38 AM, Crocker, Deborah wrote:

I just loaded version 1.3.8.4 on a Centos7 system (yum install 389-ds, which 
brings it all in) and there are no schemas deployed with the directory. There 
is only 99user.ldif which has the skeleton entries.

  I've never seen this happen before. I don't see them as a separate package. I 
could bring over the full set of schema files from the directory setup we will 
be migrating from but those were on a 1.2 x directory and I don't know if 
something in the basic schemas has changed.

Any thoughts on how to get them?

Thanks

D. Crocker

Deborah Crocker, PhD
Systems Engineer III
Office of Information Technology
The University of Alabama
Box 870346
Tuscaloosa, AL 36587
Office 205-348-3758 | Fax 205-348-9393
deborah.croc...@ua.edu


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Production level 389 release

[Mark Reynolds]

Hi Jan,

On 4/2/19 5:11 AM, Jan Tomasek wrote:

Hi,

I'm preparing migration from 389 DS 1.2.5. I'm using single master and 4
replicas all on RedHat which I would like to abandon in favor Debian
which is my main platform.

My idea was to use 389-ds 1.4.x line on Debian/Buster, but there is
completely missing 389-admin package [1]. They ship cockpit-389-ds
1.4.0.21-1 which completely doesn't work on Debian. It declares that
389-ds-base isn't installed. It is installed and configured.


Well the cockpit UI plugin is not finished yet (but we are VERY close to 
wrapping it up).


And as I have mentioned multiple times on this mailing list the 
389-admin/console packages are deprecated and will completely removed in 
Fedora 31.  So I am afraid on Debian and other platforms that do not 
have "Cockpit" there will not be any kind of UI.




I tried Fedora 29, there is 1.4.0.21-1.fc29 and it works... somehow.
Schema editation is possible. But database management is broken, it
shows two suffixes dc=example,dc=com and o=ipaca.com which are not
present in 389-ds configuration dse.ldif file. And it is unable to
detect defined suffix. It looks nice, but it seems that many things
might not be working even on Fedora.


Yeah, so you are looking at "sample" data in the database tab. However, 
in 1.4.0.22-1 the database management tab is now complete!  That release 
is currently in testing, please see the email on this list with the 
subject:  "Announcing 389 Directory Server 1.4.0.22", you will find 
links to the builds, etc.  Try it out.




Is it possible to manage 389-ds 1.4.x with 389-admin 1.1.46 and
389-admin-console 1.1.12-5.fc29? This is combination Fedora 29 come with.
Yes, and it will work in Fedora 30 as well, but come Fedora 31 the old 
standalone java UI will be removed.


Or is it safer to stick with 389-ds 1.3.x which is shipped with RHEL 7 &
Debian/Stretch? And use 389-admin & 389-console for managing them?


Well like I said the new Cockpit UI is almost done, in 1.4.0.22 the only 
tabs that are "not" working are the Monitoring tab (which I will finish 
this week) and the "Security tab" - everything else is working now.


I expect/hope the new Cockpit UI will be 100% complete in the next two 
months (hopefully sooner).


Regards,

Mark


Thanks for responses

[1]
https://packages.debian.org/search?keywords=389-admin=names=all=all


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.22

[Mark Reynolds]

   389 Directory Server 1.4.0.22

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


Fedora packages are available on Fedora 28, and 29

Fedora 29

http://koji.fedoraproject.org/koji/buildinfo?buildID=1240342

Fedora 28

http://koji.fedoraproject.org/koji/buildinfo?buildID=1240341

Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-35ca2e35b3

F28 https://bodhi.fedoraproject.org/updates/FEDORA-2019-351b02e21e

The new packages and versions are:

 * 389-ds-base-1.4.0.22-1

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




 Highlights in 1.4.0.22

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. To 
install the Cockput UI plugin use "dnf install cockpit-389-ds"


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 New UI Progress (Cockpit plugin)

The new UI is broken up into a series of configuration tabs. Here is a 
table showing the current progress


*Configuration Tab* *Finished*  *Written in ReactJS*
Server tab
Yes
No
Security Tab
No

Database Tab
Yes
Yes
Replication Tab
Yes
No
Schema Tab
Yes
No
Plugins Tab
Yes
Yes
Monitor Tab
No



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.22
 * Ticket 50308 - Revise memory leak fix
 * Ticket 50308 - Fix memory leaks for repeat binds and replication
 * Ticket 49873 - (cont 3rd) cleanup debug log
 * Ticket 49873 - (cont 2nd) Contention on virtual attribute lookup
 * Ticket 50292 - Fix Plugin CLI and UI issues
 * Ticket 50289 - Fix various database UI issues
 * Ticket 50300 - Fix memory leak in automember plugin
 * Ticket 50265 - the warning about skew time could last forever
 * Ticket 50260 - Invalid cache flushing improvements
 * Ticket 49561 - MEP plugin, upon direct op failure, will delete twice
   the same managed entry
 * Ticket 50077 - Do not automatically turn automember postop modifies on
 * Ticket 50282 - OPERATIONS ERROR when trying to delete a group with
   automember members
 * Ticket 49873 - (cont) Contention on virtual attribute lookup
 * Ticket 50260 - backend txn plugins can corrupt entry cache
 * Ticket 50041 - Add CLI functionality for special plugins
 * Ticket 50273 - reduce default replication agmt timeout
 * Ticket 50234 - one level search returns not matching entry
 * Ticket 50232 - export creates not importable ldif file
 * Ticket 50215 - UI - implement Database Tab in reachJS
 * Ticket 50238 - Failed modrdn can corrupt entry cache
 * Ticket 50236 - memberOf should be more robust
 * Ticket 50151 - lib389 support cli add/replace/delete on objects
 * Ticket 50155 - password history check has no way to just check the
   current password
 * Ticket 49873 - Contention on virtual attribute lookup
 * Ticket 49658 - In replicated topology a single-valued attribute can
   diverge
 * Ticket 50177 - import task should not be deleted too rapidely after
   import finishes to be able to query the status
 * Ticket 50165 - Fix issues with dscreate

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.2

[Mark Reynolds]

   389 Directory Server 1.4.1.2

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


Fedora packages are available on Fedora 30 and rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=33820830 - Rawhide

https://koji.fedoraproject.org/koji/taskinfo?taskID=33820510 - Fedora 30

Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2019-caf75e133e

The new packages and versions are:

 * 389-ds-base-1.4.1.2-1

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



 Highlights in 1.4.1.2

 * Version change


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, to install the UI Cockpit 
plugin use *dnf install cockpit-389-ds* After 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 broken up into a series of configuration tabs. Here is a 
table showing the current progress


*Configuration Tab* *Finished*  *Written in ReactJS*
Server tab
Yes
No
Security Tab
No

Database Tab
Yes
Yes
Replication Tab
Yes
No
Schema Tab
Yes
No
Plugins Tab
Yes
Yes
Monitor Tab
No



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.1.2-1
 * Ticket 50308 - Revise memory leak fix
 * Ticket 50308 - Fix memory leaks for repeat binds and replication
 * Ticket 40067 - Use PKG/CHECK/MODULES to detect libraries
 * Ticket 49873 - (cont 3rd) cleanup debug log
 * Ticket 49873 - (cont 2nd) Contention on virtual attribute lookup
 * Ticket 50292 - Fix Plugin CLI and UI issues
 * Ticket 50112 - Port ACI test suit from TET to python3(misc and syntax)
 * Ticket 50289 - Fix various database UI issues
 * Ticket 49463 - After cleanALLruv, replication is looping on keep
   alive DEL
 * Ticket 50300 - Fix memory leak in automember plugin
 * Ticket 50265 - the warning about skew time could last forever
 * Ticket 50260 - Invalid cache flushing improvements
 * Ticket 49561 - MEP plugin, upon direct op failure, will delete twice
   the same managed entry
 * Ticket 50077 - Do not automatically turn automember postop modifies on
 * Ticket 50282 - OPERATIONS ERROR when trying to delete a group with
   automember members
 * Ticket 49715 - extend account functionality
 * Ticket 49873 - (cont) Contention on virtual attribute lookup
 * Ticket 50260 - backend txn plugins can corrupt entry cache
 * Ticket 50255 - Port password policy test to use DSLdapObject
 * Ticket 49667 - 49668 - remove old spec files
 * Ticket 50276 - 389-ds-console is not built on RHEL8 if cockpit_dist
   is already present
 * Ticket 50112 - Port ACI test suit from TET to python3(Search)
 * Ticket 50259 - implement dn construction test
 * Ticket 50273 - reduce default replicaton agmt timeout
 * Ticket 50208 - lib389- Fix issue with list all instances
 * Ticket 50112 - Port ACI test suit from TET to python3(Global Group)
 * Ticket 50041 - Add CLI functionality for special plugins
 * Ticket 50263 - LDAPS port not listening after installation
 * Ticket 49575 - Indicate autosize value errors and corrective actions
 * Ticket 50137 - create should not check in non-stateful mode for exist
 * Ticket 49655 - remove doap file
 * Ticket 50197 - Fix dscreate regression
 * Ticket 50234 - one level search returns not matching entry
 * Ticket 50257 - lib389 - password policy user vs subtree checks are
   broken
 * Ticket 50253 - Making an nsManagedRoleDefinition type in
   src/lib389/lib389/idm/nsrole.py
 * Ticket 49029 - [RFE] improve internal operations logging
 * Ticket 50230 - improve ioerror msg when not root/dirsrv
 * Ticket 50246 - Fix the regression in old control tools
 * Ticket 50197 - Container integration part 2
 * Ticket 50197 - Container init tools
 * Ticket 50232 - export creates not importable ldif file
 * Ticket 50215 - UI - implement Database Tab in reachJS
 * Ticket 50243 - refint modrdn stress test
 * Ticket 50238 - Failed modrdn can corrupt entry cache
 * Ticket 50236 - memberOf should be more robust
 * Ticket 50213 - fix list instance 

[389-users] Re: Change authentication for LDAP

[Mark Reynolds]

Hi,





On 3/22/19 9:46 AM, Zombie fork wrote:

Hi,
    We are trying to explore new methods of authentication. We want to 
move away from the traditional password based authentication to a more 
secure method like using Certificates , keys etc.


Is it possible to implement this? What alternatives do we have?


Yes, please check out the Admin guide


You can use SSL client certificate authentication:

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


Or, SASL/GSSAPI authentication:

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

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


HTH,

Mark



Can this be applied on a specific user, ou , subtree etc.

Is there any documentation around this?

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: creating root suffix from cockpit

[Mark Reynolds]

On 3/21/19 9:35 AM, Angel Bosch Mora wrote:

Hi,

I asked a broad question here:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/thread/7G2Y2ZYBYB7JNOCMIGV5WQMYDAWSD6VM/

but I would like to know specifically if root suffix can be created with 
cockpit.


During instance creation in the UI you can specify to create the "sample 
entries".   The CLI tool dscreate has an additional option to just 
create a bare root node (no aci's, etc), but that option is not 
currently present in the UI.


I am actually working on the UI right now, what exactly would you like 
in the UI?  Is creating "sample entries" sufficient for your needs, or 
do you actually need just a basic root node entry created?  Adding an 
option to create the root node is trivial, but I want to confirm what 
you are really looking for.


Thanks,

Mark



thanks,

abosch

-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol 
fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i 
pot contenir informacio confidencial. En cap cas no heu de copiar aquest 
missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no 
sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) 
us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona 
remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] [NOTICE] 389 admin console deprecation, removal, and web UI replacement

[Mark Reynolds]

In Fedora 30, all the old java console packages have been marked as 
deprecated:


389-console
389-ds-console
389-admin-console
389-admin
389-adminutil
389-dsgw

In Fedora 31 these packages will be removed.

Our new Cockpit [1] plugin (cockpit-389-ds) will be the UI replacement, 
but important to note is that the new UI will NOT have an LDAP browser 
for looking at and updating "user" entries. The new UI is strictly 
designed for server configuration/management.  Now there are other free 
LDAP browsers out there that can be used like Apache Directory Studio 
[2] for those that still need a UI for managing users and groups.  We 
hope to add a basic LDAP browser in the future, but this will not be 
ready for Fedora 31.


Feel free to voice any comments, concerns, or questions.

Regards,

389 Directory Server Development Team

[1] https://cockpit-project.org/

[2] https://directory.apache.org/studio/
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Samba & 389 Directory Server Integration

[Mark Reynolds]

On 2/22/19 12:42 PM, Janet Houser wrote:

Hi Folks,

I'm running DS-389 (version: 1.3.7.5 ; Build: 2018.178.1311) on a Cent 
OS 7 vs. 7.6.1810) system.  I've been working
through the Samba & 389 Directory Server Integration 
 
doc and I've hit a snag.   I've obtained my SID using the "net 
getlocalsid"

command, but when I create my .ldif file (see below):


[root]# cat sambaDomainName.ldif
dn: sambaDomainName=WORKGROUP,dc=test,dc=example,dc=com   (changed for 
security)

objectclass: sambaDomain
objectclass: sambaUnixIdPool
objectclass: top
sambaDomainName: WORKGROUP
sambaSID: S-1-5-21-x--xxx   (removed for security)
uidNumber: 550
gidNumber: 550


And attempt to import it into my DS server using:


/usr/lib64/dirsrv/slapd-/ldif2ldap  "cn=Directory manager" 
password ./sambaDomainName.ldif
/usr/lib64/dirsrv/slapd-/ldif2ldap  "cn=Directory 
manager,dc=test,dc=example,dc=com" password ./sambaDomainName.ldif


I get an error:

Options:
    -Z serverID  - Server instance identifier
    -D rootdn    - Directory Manager DN
    -w passwd    - Directory Manager password
    -f file  - File containing LDAP entries to add to the server
    -P protocol  - STARTTLS, LDAPS, LDAPI, LDAP
    -h   - Display usage


I tried modifying the command in various ways:

/usr/lib64/dirsrv/slapd-/ldif2ldap  -D "cn=Directory Manager" -w 
 -f /sambaDomainName.ldif


and I've even used the /usr/sbin/ldif2ldap executable and have only 
gotten errors about the usage.   From the messages it looks like I
don't need the -Z server ID in the command since I have only one 
instance running on the server.


I'm sure I'm missing the obvious but I was hoping an experienced eye 
might have an easier time finding it.
Perhaps try "-Z instance_name" anyway.  I just tried on 
389-ds-base-1.4.0 and it works for me, and I don't think we have changed 
it in a long time.


Any suggestions would be appreciated.

Thanks,

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Replicate 389DS with another LDAP server

[Mark Reynolds]

On 2/20/19 5:59 AM, Howard Chu wrote:

Date: Tue, 19 Feb 2019 13:50:11 +0100
From: wodel youchi 

Hi,

is it possible to create a replication matser/master or master/slave
between 389DS and another LDAP server openldap for example?

Regards.

Maybe. OpenLDAP has recently added support for replication using a retro 
changelog.
It has only been tested against Sun/Oracle DSEE so far


389's retro changelog should be the same as DSEE, so this would be an 
option.  Howard, does this new replication feature in OpenLDAP work in 
both directions?



but it may also work with
389DS/RHDS, and if it doesn't work at the moment it probably wouldn't take much 
to
make it work. I haven't examined the 389DS schema to see how closely it matches 
DSEE yet.


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: SHA1SUM incorrect on download website for Windows Console MSI files

[Mark Reynolds]

On 2/19/19 11:56 AM, Steve Kuervers wrote:

Good morning all,

I've been working with 389-ds RPMs from EPEL on CentOS 7.6, looking to 
replicate in a testing environment the capabilities of RH directory 
server.  First off, thanks for your work on all this great 389 project!

Thanks ;-)


I'm also doing some cross-testing with Windows clients for 
administrative purposes.  I noticed that the SHA1SUMS for the Windows 
Console MSI files on the download page are incorrect.


https://directory.fedoraproject.org/docs/389ds/download.htm

Specifically, the following downloads do not match the listed SHA1SUM 
(the text in these two lists was cut and pasted from the actual web page).


  Windows 2008/2012 32-bit
  389-Console-1.1.15-i386.msi
  772e4691daea66dcdef97cb220d9ae77ab9fbe78

  Windows 2008/2012 64-bit
  389-Console-1.1.15-x86_64.msi
  35ec5bad0d309c334ba8c5e8ac0ab183f004d7fd

I also note that there are 1.1.18 binaries in the following directory, 
but they do not match the posted SHA1SUMs.  I also note the double // 
in the link - which was copied directly from the link for 
389-Console-1.1.15-i386.msi on the Download page.


https://fedorapeople.org/groups/389ds//binaries/

My hope is that this is an administrative error - the web page needs 
to be updated with the confirmed binary SHA1SUMs. Of more concern, 
there is a possibility that the binaries have been replaced with 
modified MSI files.


If someone could look at this, it would be much appreciated.  My guess 
is the download web page needs to be updated for the 1.1.18 MSI 
binaries and SHA1SUM entries.


Sorry this is admin error on our part, and we are aware of it. It's on 
our list to correct, hopefully we can get to it soon...


I will report back to this list once we get it addressed.

Regards,

Mark



Steve Kuervers

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Setting an attribute value automatically according to some rule

[Mark Reynolds]

On 2/17/19 8:01 PM, William Brown wrote:

Yeah, I don’t think cos can do templating.
Right, COS can add pre-defined virtual values to an entry based on 
certain attribute values found in that entry, but it can not generate 
dynamic values like this.


If you would be willing Oliver, would you submit your code to the project, and 
allow it to be made generic? That could help quite a few people out with 
similar queries.


On 17 Feb 2019, at 00:20, Olivier JUDITH  wrote:

Hi ,

There is a way to add attribute to user entry automatically called CoS . You 
can take a look on this link
https://access.redhat.com/documwanentation/en-us/red_hat_directory_server/9.0/html/administration_guide/advanced_entry_management-assigning_class_of_service

But afaik you cannot add an email based on the uid except if CoS support macros 
like ACI. To do that you have to create your own plugin see 
:https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/html/plug-in_guide/
I did the same for another kind of attribute.
It works fine for me
  


Le sam. 16 févr. 2019 à 14:29, Rosario Esposito  a 
écrit :

Hello,
let's say whenever I create a new entry:

uid=myuser,ou=people,dc=example,dc=com

I would like this entry to have the attribute:

mail: myu...@example.com

(i.e. the value of 'mail' should be automatically set to the value of
'uid' + '@example.com')

Is there a way for 389ds to do this task automatically ?


Thanks,
--
Rosario Esposito
System Administrator
INFN - Napoli
Phone: +39 081 676170
Email: rosario.espos...@na.infn.it
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Update userpassword from consummer

[Mark Reynolds]

On 2/18/19 7:46 AM, wodel youchi wrote:

Hi,

I did a test, but unfortunately it didn't work for me.

This is my LAB:

  * 389DS Servers :
  o OS CentOS7 all updates
  o 389DS version 1.3.8.4-22
  o domain : dc=example,dc=com
  o users on : uid=%u,ou=people,dc=example,dc=com
  o One master server (idm01.example.com
) and one slave server
(idm02.example.com ).
  o Replication configured for userRoot database (dc=example,dc=com)
  o Replication uses this user cn=replication manager,cn=config
  o Password Policy is configured.
  * Mail server Zimbra 8.8.11
  o OS CentOS7 all updates
  o Zimbra FOSS 8.8.11.
  o External authentication configured  using LDAP server
  + Installation of ADPassword connector to allow change
password from Zimbra WebUI
  + External authentication was configured first on
idm01.example.com  to test that
change pass works correctly.
  + External authentication was modified to use
idm02.example.com  to test chain
modification.

Result :

  * Could not change user password using chain modification from
idm02.example.com 


Steps of configuration of chain modification :

  * On master 389DS server
  o Create a new ACI on dc=example,dc=com : *(targetattr =
"*")(version 3.0; acl "Proxied authorization for database links";
   allow (proxy) (userdn = "ldap:///cn=Replication
Manager,cn=config");)*
  o Create cn=replication manager,cn=config on the master after
getting this error from the slave's log :
  + [17/Feb/2019:14:31:30.151680780 +] - ERR -
slapi_ldap_bind - Error: could not bind id [cn=replication
manager,cn=config] authentication mechanism [SIMPLE]:
error 32 (No such object)

This means cn=replication manger does not exist on the slave server, but 
looks like you added it later...


  + [17/Feb/2019:14:31:30.153315712 +] - ERR - chaining
database - cb_get_connection - Can't bind to server
http://idm01.example.com>> port <636>.
(LDAP error 32 - No such object; Netscape Portable Runtime
error 0 - no error)
[17/Feb/2019:14:31:30.154527249 +] - ERR - chaining
database - chaining_back_modify - cb_get_connection failed
(-11) Connect error
  * On slave 389DS server
  o Create the chain entry with ldapadd -x -W -D "cn=Directory
Manager" -f chain.ldiff
  + dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
cn: *chainbe1 *
*nsslapd-suffix: dc=example,dc=com
nsfarmserverurl: ldaps://idm01.example.com:636

nsmultiplexorbinddn: cn=replication manager,cn=config*
nsmultiplexorcredentials: reppassword
nsCheckLocalACI: on
  o Modify the existing : *dn: cn="dc=example,dc=com",cn=mapping
tree,cn=config* or to be exact dn:
cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
  + The original Entry was :
  # dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
*nsslapd-state: referral on update*
nsslapd-backend: userRoot
nsslapd-referral:
ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom

  + The modified entry is :
  # dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
nsslapd-backend: userRoot
nsslapd-referral:
ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom

*nsslapd-state: backend
nsslapd-distribution-plugin:
/usr/lib64/dirsrv/plugins/libreplication-plugin.so
nsslapd-distribution-funct: repl_chain_on_update*

Errors :

  * From 389DS slave server :
  o Erorr Log
  + [17/Feb/2019:14:44:24.514362428 +] - ERR - chaining
database - chaining_back_modify - invalid password syntax
- passwords with storage scheme are not allowed

This means you, or some client, tried to add a 

[389-users] Announcing 389 Directory Server 1.4.0.21

[Mark Reynolds]

   389 Directory Server 1.4.0.21

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


Fedora packages are available on Fedora 28, and 29

Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=32370360 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=32370472 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-dfb56cca7b 



F28 https://bodhi.fedoraproject.org/updates/FEDORA-2019-201a3e 



The new packages and versions are:

 * 389-ds-base-1.4.0.21-1

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




 Highlights in 1.4.0.21

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.21
 * Ticket 50041 - CLI and WebUI - Add memberOf plugin functionality
 * Ticket 50079 - Fix for ticket 50059: If an object is nsds5replica,
   it must be cn=replica
 * Ticket 50125 - perl fix ups for tmpfiles
 * Ticket 50164 - Add test for dscreate
 * Ticket 50059 - If an object is nsds5replica, it must be cn=replica
 * Ticket 50169 - lib389 changed hardcoded systemctl path
 * Ticket 50165 - Fix dscreate issues
 * Ticket 50152 - Replace os.getenv(‘HOME’) with os.path.expanduser
 * Fix compiler warning in snmp main()
 * Fix compiler warning in init.c
 * Ticket 49540 - FIx compiler warning in ldif2ldbm
 * Ticket 50077 - Fix compiler warnings in automember rebuild task
 * Ticket 49972 - use-after-free in case of several parallel
   krb authentication
 * Ticket 50161 - Fixed some descriptions in “dsconf backend –help”
 * Ticket 50153 - Increase default max logs
 * Ticket 50123 - with_tmpfiles_d is associated to systemd
 * Ticket 49984 - python installer add option to create suffix entry
 * Ticket 50077 - RFE - improve automember plugin to work with modify ops
 * Ticket 50136 - Allow resetting passwords on the CLI
 * Ticket 49994 - Adjust dsconf backend usage
 * Ticket 50138 - db2bak.pl -P LDAPS does not work when
   nsslapd-securePort is missing
 * Ticket 50122 - Fix incorrect path spec
 * Ticket 50145 - Add a verbose option to the backup tools
 * Ticket 50056 - dsctl db2ldif throws an exception
 * Ticket 50078 - cannot add cenotaph in read only consumer
 * Ticket 50126 - Incorrect usage of sudo in test
 * Ticket 50130 - Building RPMs on RHEL8 fails
 * Ticket 50134 - fixup-memberof.pl does not respect protocol requested
 * Ticket 50122 - Selinux test for presence
 * Ticket 50101 - Port fourwaymmr Test TET suit to python3
 * Ticket 50091 - shadowWarning is not generated if passwordWarning is
   lower than 86400 seconds (1 day).
 * Ticket 50128 - NS Stress fails without ipv6
 * Ticket 49618 - Set nsslapd-cachememsize to custom value
 * Ticket 50117 - after certain failed import operation, impossible to
   replay an import operation
 * Ticket 4 - rpm.mk dist-bz2 should clean cockpit_dist first
 * Ticket 48064 - Fix various issues in disk monitoring test suite
 * Ticket 49938 - lib389 - Clean up CLI logging
 * Ticket 49761 - Fix CI test suite issues
 * Ticket 50056 - Fix UI bugs (part 2)
 * Ticket 48064 - CI test - disk_monitoring
 * Ticket 50099 - extend error messages
 * Ticket 50099 - In FIPS mode, the server can select an unsupported
   password storage scheme
 * Ticket 50041 - Add basic plugin UI/CLI wrappers
 * Ticket 50082 - Port state test suite
 * Ticket 49574 - remove index subsystem
 * Ticket 49588 - Add py3 support for tickets : part-5
 * Ticket 50095 - cleanup deprecated key.h includes

___
389-users mailing list -- 389-users@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: 

[389-users] Re: Import an ldif

[Mark Reynolds]

On 1/31/19 9:51 AM, john.ber...@us.fujitsu.com wrote:


Mark,

Thanks for the follow up.  I was able to change the schema value to 
off just fine.  However, when we edited the dse.ldif file for the DS 
that is running on port 389 (slapd-test) the nsslapd-syntaxcheck: 
offvalue was not in the file so we just added it and restarted the 
ldap server.  The import still failed to pull in the users that had 
values that were blank.


Most likely I am missing something or edited the wrong dse.ldif file.

This is why I said to use ldapmodify.  If you edit dse.ldif while the 
server is running those changes get overwritten.  If you want to 
directly edit dse.ldif, then stop the server first and then make your 
changes. Try that and let me know how it goes.


Thanks,

Mark

Please bear with me because I am not a Unix person at all, so many 
times things like this confuse me.


My apologies,

John

*From:*Mark Reynolds 
*Sent:* Wednesday, January 30, 2019 3:11 PM
*To:* General discussion list for the 389 Directory server project. 
<389-users@lists.fedoraproject.org>; Berger, John 


*Subject:* Re: [389-users] Import an ldif

On 1/30/19 3:58 PM, john.ber...@us.fujitsu.com 
<mailto:john.ber...@us.fujitsu.com> wrote:


We are trying to import an ldif file from our old Sun One
Directory Server 5.2. We have the 389 server set up and running. I
can initialize the database I want to import in and it seems to
work fine. However, we have a lot of users that do not get
imported in due a syntax error on certain attributes because they
are blank. Example:  We have an attribute called Title which was
never required so many of the users have it blank. These error on
import. *Is there a way to get the 389 server to disregard that
and load the user anyway? Basically we want to pull everything in
even if the fields are blank.*

Ideally you could write a script to strip those empty attributes from 
the LDIF.


Otherwise you can turn off schema checking (syntax checking might also 
need to be disabled)


cn=config
nsslapd-schemacheck: off
nsslapd-syntaxcheck: off

Use ldapmodify to set these attributes (same as Sun DS), and stop the 
server before you import.  After the import completes you should turn 
these settings back "on".


HTH,

Mark

*

*

Regards,

John



___

389-users mailing list --389-users@lists.fedoraproject.org  
<mailto:389-users@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  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwMD-g=09aR81AqZjK9FqV5BSCPBw=dWiGkhrpTYElk4V9q_NpSc2K8EN8z9bMIRnOec4Am_w=naZYpGxhTwE7AsgNJU3vObaAlrbU9lPeZ4ORnuHiv-o=HZmMTZh-cUHeN01DZp31xLFOdu73ibSYJ4OhvuqN3_Y=>

List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwMD-g=09aR81AqZjK9FqV5BSCPBw=dWiGkhrpTYElk4V9q_NpSc2K8EN8z9bMIRnOec4Am_w=naZYpGxhTwE7AsgNJU3vObaAlrbU9lPeZ4ORnuHiv-o=f37RmCFC-oLPMSkMMtddt-2AjIfNwxfpQPlage1IGbc=>

List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_389-2Dusers-40lists.fedoraproject.org=DwMD-g=09aR81AqZjK9FqV5BSCPBw=dWiGkhrpTYElk4V9q_NpSc2K8EN8z9bMIRnOec4Am_w=naZYpGxhTwE7AsgNJU3vObaAlrbU9lPeZ4ORnuHiv-o=Bf4gfFr9pP3P6M-4kkyTWwUA1ac-VU6qgqIoaTxVpTY=>

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.1.1

[Mark Reynolds]

   389 Directory Server 1.4.1.1

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


Fedora packages are available on Fedora 30 (rawhide).

https://koji.fedoraproject.org/koji/taskinfo?taskID=32348343 
 - Fedora 
30 (rawhide)


The new packages and versions are:

 * 389-ds-base-1.4.1.1-1

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




 Highlights in 1.4.1.1

 * Version change


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base cockpit-389-ds* After install 
completes, run *dscreate interactive*


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.



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.1.1
 * Ticket 50151 - lib389 support cli add/replace/delete on objects
 * Ticket 50041 - CLI and WebUI - Add memberOf plugin functionality
 * Rebased from 389-ds-base-1.4.0.20-1

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Import an ldif

[Mark Reynolds]

On 1/30/19 3:58 PM, john.ber...@us.fujitsu.com wrote:


We are trying to import an ldif file from our old Sun One Directory 
Server 5.2. We have the 389 server set up and running. I can 
initialize the database I want to import in and it seems to work fine. 
However, we have a lot of users that do not get imported in due a 
syntax error on certain attributes because they are blank. Example:  
We have an attribute called Title which was never required so many of 
the users have it blank. These error on import. *Is there a way to get 
the 389 server to disregard that and load the user anyway? Basically 
we want to pull everything in even if the fields are blank.*


Ideally you could write a script to strip those empty attributes from 
the LDIF.


Otherwise you can turn off schema checking (syntax checking might also 
need to be disabled)


cn=config
nsslapd-schemacheck: off
nsslapd-syntaxcheck: off

Use ldapmodify to set these attributes (same as Sun DS), and stop the 
server before you import.  After the import completes you should turn 
these settings back "on".


HTH,

Mark

*
*

*
*


**

Regards,

John


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Replication problems

[Mark Reynolds]

On 1/29/19 1:16 PM, Mitch Patenaude wrote:

On 1/29/19, 10:12 AM, "Mitch Patenaude"  wrote:
 additional info: Unknown attribute nsslapd-errorlog-loglevel will 
be ignored

Figured out that it was suppoed to be nsslapd-errorlog-level. I should have 
read the docs.

Me too :-/
 
 
 ___

 389-users mailing list -- 389-users@lists.fedoraproject.org
 To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
 Fedora Code of Conduct: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwIGaQ=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=uwP95n7G6saAVOL8hyRDlrKVHN7IjzLR_4Yg3Fdgmyg=a8ecu1-V72hzCYLA2Dzq3Xz_o8-9Dkvvzy_C38c615s=wbVxMTz2jFloO--WVqLEO-jSMBJlzzhWzyCSBucn6zg=
 List Guidelines: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=uwP95n7G6saAVOL8hyRDlrKVHN7IjzLR_4Yg3Fdgmyg=a8ecu1-V72hzCYLA2Dzq3Xz_o8-9Dkvvzy_C38c615s=QxX1LnIV35Vndh_t8hZYfa_PdZPi-hzSXpgSkqF_fF4=
 List Archives: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_389-2Dusers-40lists.fedoraproject.org=DwIGaQ=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=uwP95n7G6saAVOL8hyRDlrKVHN7IjzLR_4Yg3Fdgmyg=a8ecu1-V72hzCYLA2Dzq3Xz_o8-9Dkvvzy_C38c615s=OD2qyGsBsEj_79yg_zZowciVtds03ZlxfoF0CyQRdXc=
 


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Replication problems

[Mark Reynolds]

On 1/28/19 8:13 PM, Mitch Patenaude wrote:


On 1/28/19, 9:20 AM, "Mark Reynolds"  wrote:
[...]
 If that is not useful then turning on replication logging would be the
 next step.

Trying to track the CSN only yielded that the same CSN was tried *many* times 
without success.

I can't seem to figure how to turn on the replication logging.


ldapmodify -D "cn=directory manager" -W

dn: cn=config

changetype: modify

replace: nsslapd-errorlog-loglevel

nsslapd-errorlog-loglevel: 8192

Then reset it to zero to disable replication logging.

Hopefully something will be in there to explain the error 53.

Regards,

Mark



Thanks,
   -- Mitch

  

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Replication problems

[Mark Reynolds]

On 1/28/19 12:06 PM, Mitch Patenaude wrote:

I’ve got a somewhat complex replication arrangement.  There are 6 masters total.

09-11-13
  |\/ | \/|
  |/\ | /\|
10-12-14


So 11 and 12 replicate to all other servers, 09 and 10 replicate to each other and 
11 and 12, and 13 & 14 replication between themselves and 11 and 12.

I'm having a problem where 14 (also known as intdns2-02-lv) isn't getting 
updates from 11 and 12, and I'm seeing this in the logs:

[28/Jan/2019:08:48:57 -0800] NSMMReplicationPlugin - agmt="cn=intdns2-02-lv" 
(intdns2-02-lv:636): Consumer failed to replay change (uniqueid 
bd0d6e01-b1f411e7-81a1b88c-5005cb3e, CSN 5c4c6128000d): Server is unwilling to 
perform (53). Will retry later.

They're all Centos 6.x boxes, running 1.2.11.15-34.el6_5(9 through 12) or 
1.2.11.15-97.el6_10 (13 and 14).

Any idea where to look?


Start with the consumer that is rejecting the update (intdns2-02-lv).  
Check the access log and find the "err=53" and also check the errors log 
to see why the operation might have been rejected.  Also look through 
the access log for "csn=5c4c6128000d", prehaps on a retry it was 
successfully processed.


If that is not useful then turning on replication logging would be the 
next step.


HTH,

Mark



Thanks,
--- Mitch Patenaude  mpatena...@shutterfly.com

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 3:35 PM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 10:17 PM Mark Reynolds  wrote:


On 1/24/19 1:54 PM, Mihai Carabas wrote:

Hello,

[root@ldap ~]# dsctl slapd-ldap db2ldif --replication cursdb cursdb.ldif

cursdb.ldif doesn't seem to contain any replication related info. What
should contain related to replication?

You should at least see an entry with "dn: 
nsuniqueid=---", if you don't see this entry in the 
LDIF then it might not be working (sigh).  You can then use the legacy tool:


Is there. All is ok.

After exporting LDIF and importing again, the search still is buggy.


Yeah this is looking like a known bug that we will be working on soon...

Question, would you be willing to try a "special logging" build to see 
we can figure out why the reindex task is hanging?  The stacktraces did 
not show anything helpful, so we need to see which entry is causing the 
issue and the easiest way, besides walking you through using gdb (which 
I would be willing to do), would be to provide a special build that logs 
extra info to the errors log.   I know that is a lot to ask, so no 
worries if you aren't comfortable with it.


Thanks,
Mark
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 1:54 PM, Mihai Carabas wrote:

Hello,

[root@ldap ~]# dsctl slapd-ldap db2ldif --replication cursdb cursdb.ldif

cursdb.ldif doesn't seem to contain any replication related info. What
should contain related to replication?


You should at least see an entry with "dn: 
nsuniqueid=---", if you don't see this 
entry in the LDIF then it might not be working (sigh).  You can then use 
the legacy tool:


db2ldif -r -n userroot -a LDIF_FILE

Regards,

Mark



Thank you,
Mihai

On Thu, Jan 24, 2019 at 5:53 PM Mark Reynolds  wrote:


On 1/24/19 10:26 AM, Mihai Carabas wrote:

Also I used db2index on the stopped Directory Server. Should I have
used db2index.pl on the running one?

IMO, it's best to stop to the server when doing these types of operations.

Mark


Thanks,
Mihai

On Thu, Jan 24, 2019 at 5:24 PM Mihai Carabas  wrote:

Hello Mark,

On Thu, Jan 24, 2019 at 4:35 PM Mark Reynolds  wrote:

On 1/24/19 8:37 AM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 12:52 AM William Brown  wrote:

On 24 Jan 2019, at 00:50, Mihai Carabas  wrote:

=profesor
  42815 42818 42821 42824 42827 42830 42833 42836 42839 42842
42845 42848 43445 43450 45720 52253
=profesori
  7 68 3232 3648 5457 6259 6268 6270 6275 6278 6280 6282 6304
6308 6323 7098 21827

Can you also send me the output of :

ldapsearch -b …. -s sub ‘(ou=Profesori)’ entryid

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: ou=Profesori
# requesting: entryid
#

# Profesori, DPPD, People, curs.pub.ro
dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro
entryid: 3648

# search result
search: 2
result: 0 Success

I issued db2index and I have the following output:
the 50% threshold.
[24/Jan/2019:15:14:31.578343786 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 1 ...
[24/Jan/2019:15:14:31.781708885 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting for workers to finish...
[24/Jan/2019:15:14:32.05591 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers finished; cleaning up...
[24/Jan/2019:15:14:32.259020991 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers cleaned up.
[24/Jan/2019:15:14:32.262209501 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweeping files for merging
later...
[24/Jan/2019:15:14:33.674826562 +0200] - INFO - dblayer_instance_start
- Import is running with nsslapd-db-private-import-mem on; No other
process is allowed to access the database
[24/Jan/2019:15:14:33.975430948 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweep done.
[24/Jan/2019:15:14:33.982718069 +0200] - INFO - import_main_offline -
reindex cursdb: Beginning pass number 2
[24/Jan/2019:15:14:54.035041942 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
204521866.1/sec, recent rate 0.0/sec, hit ratio 0%

[24/Jan/2019:15:15:14.086428912 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
104755102.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:34.138688984 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
70409167.0/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:54.189761953 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
53024187.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:14.239427918 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
42524348.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:34.483660956 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
35495530.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:54.533827623 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
30460703.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:14.586325096 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
26676765.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:34.636106261 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
23729056.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:54.686551928 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
21367956.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:14.812847819 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
19434204.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:34.883738846 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
17821407.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 1:18 PM, Mihai Carabas wrote:

Hello,

In order to help you to help me ;), I've re-run db2index and collected
the attached stacktraces.


Did you see really high CPU?



Thank you,
Mihai

On Thu, Jan 24, 2019 at 5:52 PM Mark Reynolds  wrote:


On 1/24/19 10:24 AM, Mihai Carabas wrote:

Hello Mark,

On Thu, Jan 24, 2019 at 4:35 PM Mark Reynolds  wrote:

On 1/24/19 8:37 AM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 12:52 AM William Brown  wrote:

On 24 Jan 2019, at 00:50, Mihai Carabas  wrote:

=profesor
  42815 42818 42821 42824 42827 42830 42833 42836 42839 42842
42845 42848 43445 43450 45720 52253
=profesori
  7 68 3232 3648 5457 6259 6268 6270 6275 6278 6280 6282 6304
6308 6323 7098 21827

Can you also send me the output of :

ldapsearch -b …. -s sub ‘(ou=Profesori)’ entryid

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: ou=Profesori
# requesting: entryid
#

# Profesori, DPPD, People, curs.pub.ro
dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro
entryid: 3648

# search result
search: 2
result: 0 Success

I issued db2index and I have the following output:
the 50% threshold.
[24/Jan/2019:15:14:31.578343786 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 1 ...
[24/Jan/2019:15:14:31.781708885 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting for workers to finish...
[24/Jan/2019:15:14:32.05591 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers finished; cleaning up...
[24/Jan/2019:15:14:32.259020991 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers cleaned up.
[24/Jan/2019:15:14:32.262209501 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweeping files for merging
later...
[24/Jan/2019:15:14:33.674826562 +0200] - INFO - dblayer_instance_start
- Import is running with nsslapd-db-private-import-mem on; No other
process is allowed to access the database
[24/Jan/2019:15:14:33.975430948 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweep done.
[24/Jan/2019:15:14:33.982718069 +0200] - INFO - import_main_offline -
reindex cursdb: Beginning pass number 2
[24/Jan/2019:15:14:54.035041942 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
204521866.1/sec, recent rate 0.0/sec, hit ratio 0%

[24/Jan/2019:15:15:14.086428912 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
104755102.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:34.138688984 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
70409167.0/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:54.189761953 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
53024187.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:14.239427918 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
42524348.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:34.483660956 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
35495530.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:54.533827623 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
30460703.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:14.586325096 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
26676765.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:34.636106261 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
23729056.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:54.686551928 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
21367956.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:14.812847819 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
19434204.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:34.883738846 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
17821407.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:54.938178725 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
16455782.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:14.995408557 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
15284552.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.047817446 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
14221719.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.051470957 +0200

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 10:26 AM, Mihai Carabas wrote:

Also I used db2index on the stopped Directory Server. Should I have
used db2index.pl on the running one?


IMO, it's best to stop to the server when doing these types of operations.

Mark



Thanks,
Mihai

On Thu, Jan 24, 2019 at 5:24 PM Mihai Carabas  wrote:

Hello Mark,

On Thu, Jan 24, 2019 at 4:35 PM Mark Reynolds  wrote:


On 1/24/19 8:37 AM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 12:52 AM William Brown  wrote:



On 24 Jan 2019, at 00:50, Mihai Carabas  wrote:

=profesor
 42815 42818 42821 42824 42827 42830 42833 42836 42839 42842
42845 42848 43445 43450 45720 52253
=profesori
 7 68 3232 3648 5457 6259 6268 6270 6275 6278 6280 6282 6304
6308 6323 7098 21827

Can you also send me the output of :

ldapsearch -b …. -s sub ‘(ou=Profesori)’ entryid

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: ou=Profesori
# requesting: entryid
#

# Profesori, DPPD, People, curs.pub.ro
dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro
entryid: 3648

# search result
search: 2
result: 0 Success

I issued db2index and I have the following output:
the 50% threshold.
[24/Jan/2019:15:14:31.578343786 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 1 ...
[24/Jan/2019:15:14:31.781708885 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting for workers to finish...
[24/Jan/2019:15:14:32.05591 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers finished; cleaning up...
[24/Jan/2019:15:14:32.259020991 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers cleaned up.
[24/Jan/2019:15:14:32.262209501 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweeping files for merging
later...
[24/Jan/2019:15:14:33.674826562 +0200] - INFO - dblayer_instance_start
- Import is running with nsslapd-db-private-import-mem on; No other
process is allowed to access the database
[24/Jan/2019:15:14:33.975430948 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweep done.
[24/Jan/2019:15:14:33.982718069 +0200] - INFO - import_main_offline -
reindex cursdb: Beginning pass number 2
[24/Jan/2019:15:14:54.035041942 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
204521866.1/sec, recent rate 0.0/sec, hit ratio 0%

[24/Jan/2019:15:15:14.086428912 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
104755102.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:34.138688984 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
70409167.0/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:54.189761953 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
53024187.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:14.239427918 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
42524348.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:34.483660956 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
35495530.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:54.533827623 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
30460703.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:14.586325096 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
26676765.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:34.636106261 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
23729056.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:54.686551928 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
21367956.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:14.812847819 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
19434204.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:34.883738846 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
17821407.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:54.938178725 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
16455782.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:14.995408557 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
15284552.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.047817446 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
14221719.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.051470957

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 10:24 AM, Mihai Carabas wrote:

Hello Mark,

On Thu, Jan 24, 2019 at 4:35 PM Mark Reynolds  wrote:


On 1/24/19 8:37 AM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 12:52 AM William Brown  wrote:



On 24 Jan 2019, at 00:50, Mihai Carabas  wrote:

=profesor
 42815 42818 42821 42824 42827 42830 42833 42836 42839 42842
42845 42848 43445 43450 45720 52253
=profesori
 7 68 3232 3648 5457 6259 6268 6270 6275 6278 6280 6282 6304
6308 6323 7098 21827

Can you also send me the output of :

ldapsearch -b …. -s sub ‘(ou=Profesori)’ entryid

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: ou=Profesori
# requesting: entryid
#

# Profesori, DPPD, People, curs.pub.ro
dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro
entryid: 3648

# search result
search: 2
result: 0 Success

I issued db2index and I have the following output:
the 50% threshold.
[24/Jan/2019:15:14:31.578343786 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 1 ...
[24/Jan/2019:15:14:31.781708885 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting for workers to finish...
[24/Jan/2019:15:14:32.05591 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers finished; cleaning up...
[24/Jan/2019:15:14:32.259020991 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers cleaned up.
[24/Jan/2019:15:14:32.262209501 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweeping files for merging
later...
[24/Jan/2019:15:14:33.674826562 +0200] - INFO - dblayer_instance_start
- Import is running with nsslapd-db-private-import-mem on; No other
process is allowed to access the database
[24/Jan/2019:15:14:33.975430948 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweep done.
[24/Jan/2019:15:14:33.982718069 +0200] - INFO - import_main_offline -
reindex cursdb: Beginning pass number 2
[24/Jan/2019:15:14:54.035041942 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
204521866.1/sec, recent rate 0.0/sec, hit ratio 0%

[24/Jan/2019:15:15:14.086428912 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
104755102.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:34.138688984 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
70409167.0/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:54.189761953 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
53024187.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:14.239427918 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
42524348.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:34.483660956 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
35495530.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:54.533827623 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
30460703.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:14.586325096 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
26676765.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:34.636106261 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
23729056.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:54.686551928 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
21367956.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:14.812847819 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
19434204.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:34.883738846 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
17821407.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:54.938178725 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
16455782.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:14.995408557 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
15284552.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.047817446 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
14221719.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.051470957 +0200] - INFO - import_throw_in_towel
- reindex cursdb: Decided to end this pass because the progress rate
has dropped below the 50% threshold.
[24/Jan/2019:15:19:35.054926468 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 2

[389-users] Re: Problem with ldapsearch and scope one in 1.4.0.20

[Mark Reynolds]

On 1/24/19 8:37 AM, Mihai Carabas wrote:

On Thu, Jan 24, 2019 at 12:52 AM William Brown  wrote:




On 24 Jan 2019, at 00:50, Mihai Carabas  wrote:

=profesor
42815 42818 42821 42824 42827 42830 42833 42836 42839 42842
42845 42848 43445 43450 45720 52253
=profesori
7 68 3232 3648 5457 6259 6268 6270 6275 6278 6280 6282 6304
6308 6323 7098 21827

Can you also send me the output of :

ldapsearch -b …. -s sub ‘(ou=Profesori)’ entryid

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: ou=Profesori
# requesting: entryid
#

# Profesori, DPPD, People, curs.pub.ro
dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro
entryid: 3648

# search result
search: 2
result: 0 Success

I issued db2index and I have the following output:
the 50% threshold.
[24/Jan/2019:15:14:31.578343786 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 1 ...
[24/Jan/2019:15:14:31.781708885 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting for workers to finish...
[24/Jan/2019:15:14:32.05591 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers finished; cleaning up...
[24/Jan/2019:15:14:32.259020991 +0200] - INFO - import_monitor_threads
- reindex cursdb: Workers cleaned up.
[24/Jan/2019:15:14:32.262209501 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweeping files for merging
later...
[24/Jan/2019:15:14:33.674826562 +0200] - INFO - dblayer_instance_start
- Import is running with nsslapd-db-private-import-mem on; No other
process is allowed to access the database
[24/Jan/2019:15:14:33.975430948 +0200] - INFO -
import_sweep_after_pass - reindex cursdb: Sweep done.
[24/Jan/2019:15:14:33.982718069 +0200] - INFO - import_main_offline -
reindex cursdb: Beginning pass number 2
[24/Jan/2019:15:14:54.035041942 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
204521866.1/sec, recent rate 0.0/sec, hit ratio 0%

[24/Jan/2019:15:15:14.086428912 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
104755102.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:34.138688984 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
70409167.0/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:15:54.189761953 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
53024187.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:14.239427918 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
42524348.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:34.483660956 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
35495530.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:16:54.533827623 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
30460703.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:14.586325096 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
26676765.1/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:34.636106261 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
23729056.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:17:54.686551928 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
21367956.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:14.812847819 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
19434204.5/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:34.883738846 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
17821407.4/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:18:54.938178725 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
16455782.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:14.995408557 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
15284552.3/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.047817446 +0200] - INFO - import_monitor_threads
- reindex cursdb: Processed 8108 entries (pass 2) -- average rate
14221719.2/sec, recent rate 0.0/sec, hit ratio 0%
[24/Jan/2019:15:19:35.051470957 +0200] - INFO - import_throw_in_towel
- reindex cursdb: Decided to end this pass because the progress rate
has dropped below the 50% threshold.
[24/Jan/2019:15:19:35.054926468 +0200] - INFO - import_monitor_threads
- reindex cursdb: Ending pass number 2 ...
[24/Jan/2019:15:19:35.258101594 +0200] - INFO - import_monitor_threads
- reindex cursdb: Foreman is done; waiting 

[389-users] Re: Problem with userRoot cache (last one)

[Mark Reynolds]

On 1/16/19 12:42 PM, Paul Whitney wrote:


Mark,

Thank you for figuring out the issue we are having.  Question, is it 
possible for us to roll back/downgrade the 389-ds to a "previously" 
working version?


You'd have to go back to 389-ds-base-1.3.7, but I don't know if that's 
possible on CentOS 7.6, you'd probably have to go back to CentOS 7.5 as 
well I would think. :-(



Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 
<mailto:paul.whit...@chesapeake-it.com>

*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this 
facsimile message to the intended recipient, you are hereby notified 
that any dissemination, or copying of this communication is strictly 
prohibited. If this message contains non-public personal information 
about any consumer or customer of the sender or intended recipient, 
you are further prohibited under penalty of law from using or 
disclosing the information to any third party by provisions of the 
federal Gramm-Leach-Bliley Act. If you have received this facsimile or 
electronic message in error, please immediately notify us by telephone 
and return or destroy the original message to assure that it is not 
read, copied, or distributed by others.


----
*From:* Mark Reynolds 
*Sent:* Wednesday, January 16, 2019 12:16:19 PM
*To:* General discussion list for the 389 Directory server project.; 
Paul Whitney; William Brown

*Subject:* Re: [389-users] Re: Problem with userRoot cache (last one)


On 1/16/19 12:05 PM, Mark Reynolds wrote:



On 1/16/19 12:02 PM, Mark Reynolds wrote:


Hi Paul,


Okay I think I found the bug you are running into:


https://bugzilla.redhat.com/show_bug.cgi?id=1627512


https://pagure.io/389-ds-base/issue/49618


So sounds like you need to upgrade to:


389-ds-base-1.3.8.4-21 (RHEL/Centos 7.6)


Or build the upstream 1.3.7 server yourself using the commit found 
in the pagure ticket above.


Apologies, you are on 1.3.8, so yeah you need to get on 1.3.8.4-21 or 
higher.  Might have to wait for CentOS to pick up the latest builds?


Looks like 1.3.8.4-22 is going to be in RHEL(Centos) batch update 3.  
So it's not available yet, sorry, but should be next month (not sure 
how fast Centos picks up RHEL updates)



So in the meantime I would increase the autosize values to take 
advantage of your RAM.  See the wiki link I sent you earlier, and also 
checkout the admin guide:



https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/database_plug_in_attributes#nsslapd_cache_autosize


Good luck,

Mark



Regards,

Mark


On 1/16/19 11:38 AM, Mark Reynolds wrote:


Hey Paul,


On 1/16/19 10:14 AM, Paul Whitney wrote:


We were on version:  389-ds-base-1.3.7.5-24.


What OS?





The nsslapd-cache-autosize was set to 0.  We apply our own values.


To keep us afloat we have been forced to enable 
nsslapd-cache-autosize. However, our performance has degraded in 
response times and feel we are not able to better 
allocate/customize the cache settings as they relate to each database.



System: Virtual Machine

              8-CPU

             64GB RAM (of which 35G is free)


Two databases in the slapd instance:

userRoot = 21G

groupRoot = 1.8G


When we try to allocate anything above 50% for 
nsslapd-cache-autosize, the service fails to start stating values 
cannot exceed 100.



When we disable nsslapd-cache-autosize, and punch in our numbers:


nsslapd-cache-autosize = 0

nsslapd-dbcachesize = 1073741824

nsslapd-cachememsize = 2147483648 (groupRoot) and 23622320128 
(userRoot)



Service overwrites our settings and sets both databases to 
2147483648. While that is ok for groupRoot, it is not for userRoot.



Based on this information, is there a way/recommendation to:

 1. To force these values we enter to "stick"

Well setting autosize to zero and explicitly setting the cache 
attributes is all it should take for it to stick




 1. How can I better configure the auto cache sizing of these
entries?

Start here: 
http://www.port389.org/docs/389ds/design/autotuning.html   
(checkout the manual tuning section)



You can tune the autosizing to use more cache, but it is uniform 
across all backends:  groupRoot and userRoot would use the same values.






I would offer logs if I could, but we cannot get them off the 
system.  It is hosted in a disconnected environment.


The logs would say why the server thinks it needs to resize your 
caches (a bug?), but it sounds like autosizing is not the issue 
here since it is set to zero.

[389-users] Re: Problem with userRoot cache (last one)

[Mark Reynolds]

On 1/16/19 12:05 PM, Mark Reynolds wrote:



On 1/16/19 12:02 PM, Mark Reynolds wrote:


Hi Paul,


Okay I think I found the bug you are running into:


https://bugzilla.redhat.com/show_bug.cgi?id=1627512


https://pagure.io/389-ds-base/issue/49618


So sounds like you need to upgrade to:


389-ds-base-1.3.8.4-21 (RHEL/Centos 7.6)


Or build the upstream 1.3.7 server yourself using the commit found in 
the pagure ticket above.


Apologies, you are on 1.3.8, so yeah you need to get on 1.3.8.4-21 or 
higher.  Might have to wait for CentOS to pick up the latest builds?


Looks like 1.3.8.4-22 is going to be in RHEL(Centos) batch update 3.  So 
it's not available yet, sorry, but should be next month (not sure how 
fast Centos picks up RHEL updates)



So in the meantime I would increase the autosize values to take 
advantage of your RAM.  See the wiki link I sent you earlier, and also 
checkout the admin guide:



https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/database_plug_in_attributes#nsslapd_cache_autosize


Good luck,

Mark



Regards,

Mark


On 1/16/19 11:38 AM, Mark Reynolds wrote:


Hey Paul,


On 1/16/19 10:14 AM, Paul Whitney wrote:


We were on version:  389-ds-base-1.3.7.5-24.


What OS?





The nsslapd-cache-autosize was set to 0.  We apply our own values.


To keep us afloat we have been forced to enable 
nsslapd-cache-autosize. However, our performance has degraded in 
response times and feel we are not able to better 
allocate/customize the cache settings as they relate to each database.



System: Virtual Machine

          8-CPU

         64GB RAM (of which 35G is free)


Two databases in the slapd instance:

userRoot = 21G

groupRoot = 1.8G


When we try to allocate anything above 50% for 
nsslapd-cache-autosize, the service fails to start stating values 
cannot exceed 100.



When we disable nsslapd-cache-autosize, and punch in our numbers:


nsslapd-cache-autosize = 0

nsslapd-dbcachesize = 1073741824

nsslapd-cachememsize = 2147483648 (groupRoot) and 23622320128 
(userRoot)



Service overwrites our settings and sets both databases to 
2147483648. While that is ok for groupRoot, it is not for userRoot.



Based on this information, is there a way/recommendation to:

 1. To force these values we enter to "stick"

Well setting autosize to zero and explicitly setting the cache 
attributes is all it should take for it to stick




 1. How can I better configure the auto cache sizing of these entries?

Start here: http://www.port389.org/docs/389ds/design/autotuning.html 
(checkout the manual tuning section)



You can tune the autosizing to use more cache, but it is uniform 
across all backends:  groupRoot and userRoot would use the same values.






I would offer logs if I could, but we cannot get them off the 
system.  It is hosted in a disconnected environment.


The logs would say why the server thinks it needs to resize your 
caches (a bug?), but it sounds like autosizing is not the issue here 
since it is set to zero.  I'm not sure what else I can offer up 
without more log information.  I suspect the server is not properly 
detecting the 64gigs of memory, and thinks you have much less, which 
is why it's downsizing the cache values.  This is all speculation 
without being able to look at the errors log (during startup).  I 
find it very odd you can not get access to your own logs, it's such 
a vital part of the server, you should really get that addressed or 
else we can't really help you :(



Regards,

Mark



Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 
<mailto:paul.whit...@chesapeake-it.com>

*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message 
is confidential information intended for the use of the individual 
or entity named above. If the reader of this message is not the 
intended recipient, or an employee or agent responsible for 
delivering this facsimile message to the intended recipient, you 
are hereby notified that any dissemination, or copying of this 
communication is strictly prohibited. If this message contains 
non-public personal information about any consumer or customer of 
the sender or intended recipient, you are further prohibited under 
penalty of law from using or disclosing the information to any 
third party by provisions of the federal Gramm-Leach-Bliley Act. If 
you have received this facsimile or electronic message in error, 
please immediately notify us by telephone and return or destroy the 
original message to assure that it is not read, copied, or 
distributed by others.



*From:* William Brown 
*Sent:* Tuesday, January 15, 2019 7:22:18 PM
*To:* 389-users@lists.fedoraproject.org
*Cc:* Paul Whitney
*Subject:

[389-users] Re: Problem with userRoot cache

[Mark Reynolds]

On 1/16/19 12:02 PM, Mark Reynolds wrote:


Hi Paul,


Okay I think I found the bug you are running into:


https://bugzilla.redhat.com/show_bug.cgi?id=1627512


https://pagure.io/389-ds-base/issue/49618


So sounds like you need to upgrade to:


389-ds-base-1.3.8.4-21 (RHEL/Centos 7.6)


Or build the upstream 1.3.7 server yourself using the commit found in 
the pagure ticket above.


Apologies, you are on 1.3.8, so yeah you need to get on 1.3.8.4-21 or 
higher.  Might have to wait for CentOS to pick up the latest builds?



Regards,

Mark


On 1/16/19 11:38 AM, Mark Reynolds wrote:


Hey Paul,


On 1/16/19 10:14 AM, Paul Whitney wrote:


We were on version: 389-ds-base-1.3.7.5-24.


What OS?





The nsslapd-cache-autosize was set to 0.  We apply our own values.


To keep us afloat we have been forced to enable 
nsslapd-cache-autosize. However, our performance has degraded in 
response times and feel we are not able to better allocate/customize 
the cache settings as they relate to each database.



System: Virtual Machine

        8-CPU

       64GB RAM (of which 35G is free)


Two databases in the slapd instance:

userRoot = 21G

groupRoot = 1.8G


When we try to allocate anything above 50% for 
nsslapd-cache-autosize, the service fails to start stating values 
cannot exceed 100.



When we disable nsslapd-cache-autosize, and punch in our numbers:


nsslapd-cache-autosize = 0

nsslapd-dbcachesize = 1073741824

nsslapd-cachememsize = 2147483648 (groupRoot) and 23622320128 (userRoot)


Service overwrites our settings and sets both databases to 
2147483648. While that is ok for groupRoot, it is not for userRoot.



Based on this information, is there a way/recommendation to:

 1. To force these values we enter to "stick"

Well setting autosize to zero and explicitly setting the cache 
attributes is all it should take for it to stick




 1. How can I better configure the auto cache sizing of these entries?

Start here: http://www.port389.org/docs/389ds/design/autotuning.html 
(checkout the manual tuning section)



You can tune the autosizing to use more cache, but it is uniform 
across all backends:  groupRoot and userRoot would use the same values.






I would offer logs if I could, but we cannot get them off the 
system.  It is hosted in a disconnected environment.


The logs would say why the server thinks it needs to resize your 
caches (a bug?), but it sounds like autosizing is not the issue here 
since it is set to zero.  I'm not sure what else I can offer up 
without more log information.  I suspect the server is not properly 
detecting the 64gigs of memory, and thinks you have much less, which 
is why it's downsizing the cache values.  This is all speculation 
without being able to look at the errors log (during startup).  I 
find it very odd you can not get access to your own logs, it's such a 
vital part of the server, you should really get that addressed or 
else we can't really help you :(



Regards,

Mark



Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 
<mailto:paul.whit...@chesapeake-it.com>

*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the 
intended recipient, or an employee or agent responsible for 
delivering this facsimile message to the intended recipient, you are 
hereby notified that any dissemination, or copying of this 
communication is strictly prohibited. If this message contains 
non-public personal information about any consumer or customer of 
the sender or intended recipient, you are further prohibited under 
penalty of law from using or disclosing the information to any third 
party by provisions of the federal Gramm-Leach-Bliley Act. If you 
have received this facsimile or electronic message in error, please 
immediately notify us by telephone and return or destroy the 
original message to assure that it is not read, copied, or 
distributed by others.



*From:* William Brown 
*Sent:* Tuesday, January 15, 2019 7:22:18 PM
*To:* 389-users@lists.fedoraproject.org
*Cc:* Paul Whitney
*Subject:* Re: [389-users] Problem with userRoot cache


> On 16 Jan 2019, at 06:49, Mark Reynolds  wrote:
>
> What version were you previously on?
>
> Sounds like an issue with autocache sizing.  The errors log might 
give more info about why its being reset.

>
> Also check if "nsslapd-cache-autosize" is set under 
"cn=config,cn=ldbm database,cn=plugins,cn=config".  If it is, set it 
to zero to stop the autosizing.


Certainly is sounds like autosizing is still enabled here and is 
just resetting your values on you.


>
>
> On 1/15/19 3:42 PM, Paul W

[389-users] Re: Problem with userRoot cache

[Mark Reynolds]

Hi Paul,


Okay I think I found the bug you are running into:


https://bugzilla.redhat.com/show_bug.cgi?id=1627512


https://pagure.io/389-ds-base/issue/49618


So sounds like you need to upgrade to:


389-ds-base-1.3.8.4-21 (RHEL/Centos 7.6)


Or build the upstream 1.3.7 server yourself using the commit found in 
the pagure ticket above.



Regards,

Mark


On 1/16/19 11:38 AM, Mark Reynolds wrote:


Hey Paul,


On 1/16/19 10:14 AM, Paul Whitney wrote:


We were on version: 389-ds-base-1.3.7.5-24.


What OS?





The nsslapd-cache-autosize was set to 0.  We apply our own values.


To keep us afloat we have been forced to enable 
nsslapd-cache-autosize. However, our performance has degraded in 
response times and feel we are not able to better allocate/customize 
the cache settings as they relate to each database.



System: Virtual Machine

      8-CPU

     64GB RAM (of which 35G is free)


Two databases in the slapd instance:

userRoot = 21G

groupRoot = 1.8G


When we try to allocate anything above 50% for 
nsslapd-cache-autosize, the service fails to start stating values 
cannot exceed 100.



When we disable nsslapd-cache-autosize, and punch in our numbers:


nsslapd-cache-autosize = 0

nsslapd-dbcachesize = 1073741824

nsslapd-cachememsize = 2147483648 (groupRoot) and 23622320128 (userRoot)


Service overwrites our settings and sets both databases to 
2147483648. While that is ok for groupRoot, it is not for userRoot.



Based on this information, is there a way/recommendation to:

 1. To force these values we enter to "stick"

Well setting autosize to zero and explicitly setting the cache 
attributes is all it should take for it to stick




 1. How can I better configure the auto cache sizing of these entries?

Start here: http://www.port389.org/docs/389ds/design/autotuning.html 
(checkout the manual tuning section)



You can tune the autosizing to use more cache, but it is uniform 
across all backends:  groupRoot and userRoot would use the same values.






I would offer logs if I could, but we cannot get them off the 
system.  It is hosted in a disconnected environment.


The logs would say why the server thinks it needs to resize your 
caches (a bug?), but it sounds like autosizing is not the issue here 
since it is set to zero.  I'm not sure what else I can offer up 
without more log information.  I suspect the server is not properly 
detecting the 64gigs of memory, and thinks you have much less, which 
is why it's downsizing the cache values. This is all speculation 
without being able to look at the errors log (during startup).  I find 
it very odd you can not get access to your own logs, it's such a vital 
part of the server, you should really get that addressed or else we 
can't really help you :(



Regards,

Mark



Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 
<mailto:paul.whit...@chesapeake-it.com>

*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this 
facsimile message to the intended recipient, you are hereby notified 
that any dissemination, or copying of this communication is strictly 
prohibited. If this message contains non-public personal information 
about any consumer or customer of the sender or intended recipient, 
you are further prohibited under penalty of law from using or 
disclosing the information to any third party by provisions of the 
federal Gramm-Leach-Bliley Act. If you have received this facsimile 
or electronic message in error, please immediately notify us by 
telephone and return or destroy the original message to assure that 
it is not read, copied, or distributed by others.



*From:* William Brown 
*Sent:* Tuesday, January 15, 2019 7:22:18 PM
*To:* 389-users@lists.fedoraproject.org
*Cc:* Paul Whitney
*Subject:* Re: [389-users] Problem with userRoot cache


> On 16 Jan 2019, at 06:49, Mark Reynolds  wrote:
>
> What version were you previously on?
>
> Sounds like an issue with autocache sizing.  The errors log might 
give more info about why its being reset.

>
> Also check if "nsslapd-cache-autosize" is set under 
"cn=config,cn=ldbm database,cn=plugins,cn=config".  If it is, set it 
to zero to stop the autosizing.


Certainly is sounds like autosizing is still enabled here and is just 
resetting your values on you.


>
>
> On 1/15/19 3:42 PM, Paul Whitney wrote:
>> We recently updated to 389-ds-base-1.3.8.4-18. I am not sure I can 
attribute this issue to this update since we are now just discovering 
it.  But setting the nsslapd

[389-users] Re: Problem with userRoot cache

[Mark Reynolds]

Hey Paul,


On 1/16/19 10:14 AM, Paul Whitney wrote:


We were on version: 389-ds-base-1.3.7.5-24.


What OS?





The nsslapd-cache-autosize was set to 0.  We apply our own values.


To keep us afloat we have been forced to enable 
nsslapd-cache-autosize. However, our performance has degraded in 
response times and feel we are not able to better allocate/customize 
the cache settings as they relate to each database.



System: Virtual Machine

    8-CPU

   64GB RAM (of which 35G is free)


Two databases in the slapd instance:

userRoot = 21G

groupRoot = 1.8G


When we try to allocate anything above 50% for nsslapd-cache-autosize, 
the service fails to start stating values cannot exceed 100.



When we disable nsslapd-cache-autosize, and punch in our numbers:


nsslapd-cache-autosize = 0

nsslapd-dbcachesize = 1073741824

nsslapd-cachememsize = 2147483648 (groupRoot) and 23622320128 (userRoot)


Service overwrites our settings and sets both databases to 2147483648. 
While that is ok for groupRoot, it is not for userRoot.



Based on this information, is there a way/recommendation to:

 1. To force these values we enter to "stick"

Well setting autosize to zero and explicitly setting the cache 
attributes is all it should take for it to stick




 1. How can I better configure the auto cache sizing of these entries?

Start here: http://www.port389.org/docs/389ds/design/autotuning.html 
(checkout the manual tuning section)



You can tune the autosizing to use more cache, but it is uniform across 
all backends:  groupRoot and userRoot would use the same values.






I would offer logs if I could, but we cannot get them off the system.  
It is hosted in a disconnected environment.


The logs would say why the server thinks it needs to resize your caches 
(a bug?), but it sounds like autosizing is not the issue here since it 
is set to zero.  I'm not sure what else I can offer up without more log 
information.  I suspect the server is not properly detecting the 64gigs 
of memory, and thinks you have much less, which is why it's downsizing 
the cache values.  This is all speculation without being able to look at 
the errors log (during startup).  I find it very odd you can not get 
access to your own logs, it's such a vital part of the server, you 
should really get that addressed or else we can't really help you :(



Regards,

Mark



Paul M. Whitney, RHCSA, CISSP
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 
<mailto:paul.whit...@chesapeake-it.com>

*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this 
facsimile message to the intended recipient, you are hereby notified 
that any dissemination, or copying of this communication is strictly 
prohibited. If this message contains non-public personal information 
about any consumer or customer of the sender or intended recipient, 
you are further prohibited under penalty of law from using or 
disclosing the information to any third party by provisions of the 
federal Gramm-Leach-Bliley Act. If you have received this facsimile or 
electronic message in error, please immediately notify us by telephone 
and return or destroy the original message to assure that it is not 
read, copied, or distributed by others.



*From:* William Brown 
*Sent:* Tuesday, January 15, 2019 7:22:18 PM
*To:* 389-users@lists.fedoraproject.org
*Cc:* Paul Whitney
*Subject:* Re: [389-users] Problem with userRoot cache


> On 16 Jan 2019, at 06:49, Mark Reynolds  wrote:
>
> What version were you previously on?
>
> Sounds like an issue with autocache sizing.  The errors log might 
give more info about why its being reset.

>
> Also check if "nsslapd-cache-autosize" is set under 
"cn=config,cn=ldbm database,cn=plugins,cn=config".  If it is, set it 
to zero to stop the autosizing.


Certainly is sounds like autosizing is still enabled here and is just 
resetting your values on you.


>
>
> On 1/15/19 3:42 PM, Paul Whitney wrote:
>> We recently updated to 389-ds-base-1.3.8.4-18.  I am not sure I can 
attribute this issue to this update since we are now just discovering 
it.  But setting the nsslapd-cachememsize is reverting to a default 
value of 2GB.  I have attempted to restore the value through the 
console and restarting the instance. I have also tried by stopping 
instance and manually editing the dse.ldif file. In both cases, the 
value is replaced with 2GB value.

>>
>> Any suggestions?
>>
>> Paul M. Whitney
>> RHCSA, VCP, CISSP, Security+
>> Ches

[389-users] Re: Problem with userRoot cache

[Mark Reynolds]

What version were you previously on?


Sounds like an issue with autocache sizing.  The errors log might give 
more info about why its being reset.



Also check if "nsslapd-cache-autosize" is set under "cn=config,cn=ldbm 
database,cn=plugins,cn=config".  If it is, set it to zero to stop the 
autosizing.




On 1/15/19 3:42 PM, Paul Whitney wrote:


We recently updated to 389-ds-base-1.3.8.4-18.  I am not sure I can 
attribute this issue to this update since we are now just discovering 
it. But setting the nsslapd-cachememsize is reverting to a default 
value of 2GB.  I have attempted to restore the value through the 
console and restarting the instance. I have also tried by stopping 
instance and manually editing the dse.ldif file.  In both cases, the 
value is replaced with 2GB value.



Any suggestions?


Paul M. Whitney
RHCSA, VCP, CISSP, Security+
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732

Work: 443-492-2872
Cell:   410.493.9448
Email: paul.whit...@chesapeake-it.com 


*CONFIDENTIALITY NOTICE*
The information contained in this facsimile or electronic message is 
confidential information intended for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this 
facsimile message to the intended recipient, you are hereby notified 
that any dissemination, or copying of this communication is strictly 
prohibited. If this message contains non-public personal information 
about any consumer or customer of the sender or intended recipient, 
you are further prohibited under penalty of law from using or 
disclosing the information to any third party by provisions of the 
federal Gramm-Leach-Bliley Act. If you have received this facsimile or 
electronic message in error, please immediately notify us by telephone 
and return or destroy the original message to assure that it is not 
read, copied, or distributed by others.



___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.20

[Mark Reynolds]

   389 Directory Server 1.4.0.20

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


Fedora packages are available on Fedora 28, 29, and rawhide.

Rawhide

https://koji.fedoraproject.org/koji/taskinfo?taskID=31464161 



Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=31464159 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=31464058 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2018-0f3d7e9434 



F28 https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf250e9c09 



The new packages and versions are:

 * 389-ds-base-1.4.0.20-1

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




 Highlights in 1.4.0.20

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.20
 * Ticket 49994 - Add test for backend/suffix CLI functions
 * Ticket 50090 - refactor fetch_attr() to slapi_fetch_attr()
 * Ticket 50091 - shadowWarning is not generated if passwordWarning is
   lower than 86400 seconds (1 day)
 * Ticket 50056 - Fix CLI/UI bugs
 * Ticket 49864 - Revised replication status messages for transient errors
 * Ticket 50071 - Set ports in local_simple_allocate function
 * Ticket 50065 - lib389 aci parsing is too strict
 * Ticket 50061 - Improve schema loading in UI
 * Ticket 50063 - Crash after attempting to restore a single backend
 * Ticket 50062 - Replace error by warning in the state machine defined
   in repl5_inc_run
 * Ticket 50041 - Set the React dataflow foundation and add basic plugin UI
 * Ticket 50028 - Revise ds-replcheck usage
 * Ticket 50057 - Pass argument into hashtable_new
 * Ticket 50053 - improve testcase
 * Ticket 50053 - Subtree password policy overrides a user-defined
   password policy
 * Ticket 49974 - lib389 - List instances with initconfig_dir instead
   of sysconf_dir
 * Ticket 49984 - Add an empty domain creation to the dscreate
 * Ticket 49950 - PassSync not setting pwdLastSet attribute in Active
   Directory after Pw update from LDAP sync for normal user
 * Ticket 50046 - Remove irrelevant debug-log messages from CLI tools
 * Ticket 50022, 50012, 49956, and 49800: Various dsctl/dscreate fixes
 * Ticket 49927 - dsctl db2index does not work
 * Ticket 49814 - dscreate should handle selinux ports that are in a range
 * Ticket 49543 - fix certmap dn comparison
 * Ticket 49994 - comment out dev paths
 * Ticket 49994 - Add backend features to CLI
 * Ticket 48081 - Add new CI tests for password

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Force users to modify their passwords

[Mark Reynolds]

On 12/14/18 12:38 PM, wodel youchi wrote:

Hi,

We have 389DS as our main directory server, and we use it with many 
applications.
recently we moved our mail application to Zimbra. Zimbra can use an 
external LDAP server for authentication, and we did configure that and 
it works.


In 389DS, in password policy configuration, there is the check-box to 
force a user to change his password on the first login, we did try it 
but, without success.


Right, because after setting this you must reset all the passwords using 
directory manager(or some admin account).  Then the user is forced to 
change their password at next login. Basically a flag gets set in the 
entry after it is reset by an admin, but until its reset there is no 
flag to check - so users are not forced to reset their passwords.


HTH,
Mark



Could this parameter be used to force users to change their passwords?

Regards.

 
	Garanti sans virus. www.avast.com 
 




___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Multiple suppliers for a single consumer

[Mark Reynolds]

On 12/12/18 12:56 AM, Leonard Lawton wrote:
Let's say I have nodes A and B setup in a MMR 
configuration(providers). Is it possible to have node C configured as 
a consumer for both A and B? I am wanting to have a high availability 
setup so node C still receives updates if one of the providers goes down.

Yes it is perfectly normal to use that type of configuration.

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: 389 Replication from 389-ds-base 1.2.11 to 1.3.8

[Mark Reynolds]

On 12/10/18 2:55 PM, KONG, BOB wrote:


I have a simple question I hope…

We currently have a master 389 Directory Server on 1.2.11 and I was 
wondering if it is possible to replicate to a 389 Directory Server 
1.3.8 consumer? Has anyone done this?



Yes this should work just fine


Thanks in advance

Bob Kong


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Server Group empty in 389 Management Console for windows

[Mark Reynolds]

Hi Jason,

Are you logging in as Directory Manager?  If not, try that.

Now it could be possible that part of the "o=netscaperoot" suffix has 
been deleted(accidentally?).  That entire server group folder structure 
is o=netscaperoot, so the entries are either missing, or you don't have 
permissions to read them.  Logging in as Directory Manger bypasses all 
access controls rules - so that's one way rule out access control.


As for other console issues you can run it with debug logging to get 
more information about failures, etc:


# 389-console -D 9

Also to register instances, you run "register-ds-admin.pl", not 
"setup-ds-admin.pl -u".


HTH,

Mark

On 12/5/18 10:04 PM, Jason Jenkins wrote:


Hi,

I have 389 Management Console v1.1.6  installed on Windows and have 
been using it for some time without any problems. Today I logged in 
and found that after connecting to a host that there is nothing to be 
found under the Server Group folder.  I navigate the tree for my host 
and what used to be “Administration Server” & “Dirsrv Hostname” are 
both gone from the Server Group folder.


This is the same for any directory server host that I connect to. I’ve 
also reinstalled the version that I am using. And there is no 
difference. I tried installing a newer version of Management Console 
and it dies right after running what-ever it does in a command prompt. 
So I went back to v1.1.6.


I verified that nothing changed on the network end. I can telnet to 
ports 389, 636 and 9830. I can hit 9830 from a web browser on this 
windows host. I ran “setup-ds-admin.pl -u” to re-register and nothing 
has changed. No errors or anything new in the logs from what I have 
seen prior. Once again this is across all of my directory server hosts 
that I was able to manage in the past.



___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Mark Reynolds]

On 12/2/18 7:45 PM, Alistair Cunningham wrote:

This is all done and working. In the end, the changes I needed were:

dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: rootdse

dn: dc=example,dc=com
changetype: modify
delete: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable 
anonymous access"; allow (read, search, compare) 
userdn="ldap:///anyone;;)


dn: dc=example,dc=com
changetype: modify
add: aci
aci: 
(target="ldap:///($dn),dc=example,dc=com")(targetattr!="userPassword 
|| aci")(version 3.0;acl "aci";allow (read,search) 
userdn="ldap:///cn=*,[$dn],dc=example,dc=com;;)


This page was also useful:

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



Many thanks to Olivier Judith, Mark Raynolds, and Ludwig Krispenz for 
their help!


Glad you got working, and glad Ludwig mentioned macro aci's (these are 
often overlooked)!


Best Regards,

Mark
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Mark Reynolds]

On 11/27/18 8:15 PM, Alistair Cunningham wrote:

On 28/11/2018 12:08, Mark Reynolds wrote:

On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') 
in tenant1 can still see people (with objectClass 'inetOrgPerson') 
in tenant2. Presumably there needs to also be a blanket aci to 
forbid all telephones from viewing other tenants, that these 
tenant-specific allow acis then override?


There might be an aci that is allowing anonymous access to basic 
entries.  By default if there are no ACI's then access is completely 
blocked except for Directory Manager.  So some aci is allowing 
access. We need to see all the ACI's you have:


For example, this would list all the aci's under dc=example,dc=com:

# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" 
aci=* aci


I suspect there is an aci with a userdn that equals "anyone", but 
we'll see...


There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable 
anonymous ac

 cess"; allow (read, search, compare) userdn="ldap:///anyone;;)

That depends.  Do you have any clients that expect to have anonymous 
access to entries?  Removing this aci will block everyone from access to 
the database - then you need to add aci's to open up access to the 
users/groups of your choosing.


So to accomplish what you want in this email then yes delete it, but it 
could break clients that be expecting anonymous access to be allowed.  
So be careful :-)




$ ldapsearch -x -D "cn=Directory Manager" -w secret -b 
"dc=integrics,dc=com" "aci=*" aci

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: aci=*
# requesting: aci
#

# integrics.com
dn: dc=integrics,dc=com
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable 
anonymous ac

 cess"; allow (read, search, compare) userdn="ldap:///anyone;;)
aci: (targetattr="carLicense || description || displayName || 
facsimileTelepho
 neNumber || homePhone || homePostalAddress || initials || jpegPhoto 
|| labele
 dURI || mail || mobile || pager || photo || postOfficeBox || 
postalAddress ||
  postalCode || preferredDeliveryMethod || preferredLanguage || 
registeredAddr
 ess || roomNumber || secretary || seeAlso || st || street || 
telephoneNumber
 || telexNumber || title || userCertificate || userPassword || 
userSMIMECertif
 icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write 
for commo

 n attributes"; allow (write) userdn="ldap:///self;;)
aci: (targetattr ="*")(version 3.0;acl "Directory Administrators 
Group";allow
 (all) (groupdn = "ldap:///cn=Directory Administrators, 
dc=integrics,dc=com");

 )

# 2, integrics.com
dn: ou=2,dc=integrics,dc=com
aci: (target="ldap:///ou=2,dc=integrics,dc=com;)(targetattr=*)(version 
3.0;acl
  "aci2";allow (read,search) 
userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com;;)


# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Mark Reynolds]

On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in 
tenant1 can still see people (with objectClass 'inetOrgPerson') in 
tenant2. Presumably there needs to also be a blanket aci to forbid all 
telephones from viewing other tenants, that these tenant-specific 
allow acis then override?


There might be an aci that is allowing anonymous access to basic 
entries.  By default if there are no ACI's then access is completely 
blocked except for Directory Manager.  So some aci is allowing access.  
We need to see all the ACI's you have:


For example, this would list all the aci's under dc=example,dc=com:

# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci

I suspect there is an aci with a userdn that equals "anyone", but we'll 
see...




On 27/11/2018 10:31, Olivier JUDITH wrote:

Hi,

Give IT a try. It should work
aci: 
(target="ldap:///ou=tenant1,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci1";allow (read,search) 
userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com;;)
aci: 
(target="ldap:///ou=tenant2,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com;;)


Let me know

Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham 
mailto:acunning...@integrics.com>> a écrit :


    On 26/11/2018 18:59, Olivier JUDITH wrote:
 > Hi,
 >
 > I'm using the Redhat documentation on this link
 >
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/plug-in_guide/index

    That looks rather complex. It's a real shame that there's no way of
    limiting users to the same ou using a regular expression ACL.

 > Regards
 >
 >   lun. 26 nov. 2018 à 05:46, Alistair Cunningham
 > mailto:acunning...@integrics.com>
    >> a écrit :
 >
 >     On 25/11/2018 11:44, Olivier JUDITH wrote:
 >      >  From my point of view , the easiest way to solve this is
    to set
 >     a search filter on the OU corresponding to the tenant on each
    phone.
 >      > Can you modify the software on the phone ?
 >
 >     Unfortunately not. The telephone handset firmware is written
    by various
 >     third parties, and we have no access to it.
 >
 >     This would also be insecure. Anyone with the username and
    password of a
 >     telephone and who could use an LDAP client such as LDAP
    search could
 >     bypass the filter to see all the users in all the tenants 
(i.e.

 >     every ou).
 >
 >      > The other way could be by creating  a 389 plugin that 
add a

 >     filter on the good OU regarding the DN of user which make the
    call
 >     to the ldap.
 >
 >     That might be an option. Do you know where I can find
    documentation on
 >     how to do this?
 >
 >     --
 >     Alistair Cunningham
 >     +1 888 468 3111
 >     +44 20 799 39 799
 > https://enswitch.com/
 >
 >
 > ___
 > 389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
 >

    --     Alistair Cunningham
    +1 888 468 3111
    +44 20 799 39 799
    https://enswitch.com/
    ___
    389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org





___
389-users mailing list -- 389-users@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

[389-users] Re: Limiting access to same ou

[Mark Reynolds]

On 11/26/18 8:35 PM, Alistair Cunningham wrote:

On 27/11/2018 12:32, Mark Reynolds wrote:

On 11/26/18 7:44 PM, Alistair Cunningham wrote:

Thank you, I'll give that a go.

On a related topic, do you know why when I try to add a 
simpleSecurityObject, I get a 'attribute "cn" not allowed' error?


$ cat 1234567890.ldif
dn: cn=1234567890,ou=2,dc=integrics,dc=com
objectClass: simpleSecurityObject
userPassword: abcdef
$ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif
adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com"
ldap_add: Object class violation (65)
additional info: attribute "cn" not allowed


I've tried with "uid=1234567890" instead, and it tells me that uid 
is not allowed.
You need an objectclass that allows CN or UID, simpleSecurityObject 
only allows the userpassword attribute


I see, thank you. In that case, what DN should I use instead of 
"cn=1234567890,ou=2,dc=integrics,dc=com" for this 
simpleSecurityObject? If no DN, how do I specify the 
simpleSecurityObject's username?


You should add an objectclass that allows CN (or UID), for example:


dn: cn=1234567890,ou=2,dc=integrics,dc=com
objectclass: top
objectclass: person
objectClass: simpleSecurityObject
userPassword: abcdef
cn: 1234567890


Technically you don't even need simpleSecurityObject, just "person" 
alone will get you the entry that you need.


HTH,

Mark





___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Mark Reynolds]

On 11/26/18 7:44 PM, Alistair Cunningham wrote:

Thank you, I'll give that a go.

On a related topic, do you know why when I try to add a 
simpleSecurityObject, I get a 'attribute "cn" not allowed' error?


$ cat 1234567890.ldif
dn: cn=1234567890,ou=2,dc=integrics,dc=com
objectClass: simpleSecurityObject
userPassword: abcdef
$ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif
adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com"
ldap_add: Object class violation (65)
additional info: attribute "cn" not allowed


I've tried with "uid=1234567890" instead, and it tells me that uid is 
not allowed.
You need an objectclass that allows CN or UID, simpleSecurityObject only 
allows the userpassword attribute


On 27/11/2018 10:31, Olivier JUDITH wrote:

Hi,

Give IT a try. It should work
aci: 
(target="ldap:///ou=tenant1,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci1";allow (read,search) 
userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com;;)
aci: 
(target="ldap:///ou=tenant2,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com;;)


Let me know

Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham 
mailto:acunning...@integrics.com>> a écrit :


    On 26/11/2018 18:59, Olivier JUDITH wrote:
 > Hi,
 >
 > I'm using the Redhat documentation on this link
 >
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/plug-in_guide/index

    That looks rather complex. It's a real shame that there's no way of
    limiting users to the same ou using a regular expression ACL.

 > Regards
 >
 >   lun. 26 nov. 2018 à 05:46, Alistair Cunningham
 > mailto:acunning...@integrics.com>
    >> a écrit :
 >
 >     On 25/11/2018 11:44, Olivier JUDITH wrote:
 >      >  From my point of view , the easiest way to solve this is
    to set
 >     a search filter on the OU corresponding to the tenant on each
    phone.
 >      > Can you modify the software on the phone ?
 >
 >     Unfortunately not. The telephone handset firmware is written
    by various
 >     third parties, and we have no access to it.
 >
 >     This would also be insecure. Anyone with the username and
    password of a
 >     telephone and who could use an LDAP client such as LDAP
    search could
 >     bypass the filter to see all the users in all the tenants 
(i.e.

 >     every ou).
 >
 >      > The other way could be by creating  a 389 plugin that 
add a

 >     filter on the good OU regarding the DN of user which make the
    call
 >     to the ldap.
 >
 >     That might be an option. Do you know where I can find
    documentation on
 >     how to do this?
 >
 >     --
 >     Alistair Cunningham
 >     +1 888 468 3111
 >     +44 20 799 39 799
 > https://enswitch.com/
 >
 >
 > ___
 > 389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
 >

    --     Alistair Cunningham
    +1 888 468 3111
    +44 20 799 39 799
    https://enswitch.com/
    ___
    389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org





___
389-users mailing list -- 389-users@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: 

[389-users] Announcing 389 Directory Server 1.4.0.19

[Mark Reynolds]

   389 Directory Server 1.4.0.19

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


Fedora packages are available on Fedora 28, 29, and rawhide.

Rawhide

https://koji.fedoraproject.org/koji/taskinfo?taskID=30902290 



Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=30903702 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=30903727 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2018-84b6b36c4d 



F28 https://bodhi.fedoraproject.org/updates/FEDORA-2018-e9447b1910 



The new packages and versions are:

 * 389-ds-base-1.4.0.19-1

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




 Highlights in 1.4.0.19

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.19
 * Ticket 50026 - audit logs does not capture the operation where
   nsslapd-lookthroughlimit is modified
 * Ticket 50020 - during MODRDN referential integrity can fail
   erronously while updating large groups
 * Ticket 4 - Finish up the transfer to React
 * Ticket 50004 - lib389 - improve X-ORIGIN schema parsing
 * Ticket 50013 - Log warn instead of ERR when aci target does not exist.
 * Ticket 49975 - followup for broken prefix deployment
 * Ticket 4 - Add dist-bz2 target for Koji build system
 * Ticket 49814 - Add specfile requirements for python3-libselinux
 * Ticket 49814 - Add specfile requirements for python3-selinux
 * Ticket 4 - Integrate React structure into cockpit-389-ds
 * Ticket 49995 - Fix issue with internal op logging
 * Ticket 49997 - RFE: ds-replcheck could validate suffix exists and
   it’s replicated
 * Ticket 49985 - memberof may silently fails to update a member
 * Ticket 49967 - entry cache corruption after failed MODRDN
 * Ticket 49975 - Add missing include file to main.c
 * Ticket 49814 - skip standard ports for selinux labelling
 * Ticket 49814 - dscreate should set the port selinux labels
 * Ticket 49856 - Remove backend option from bak2db
 * Ticket 49926 - Fix various issues with replication UI
 * Ticket 49975 - SUSE rpmlint issues
 * Ticket 49939 - Fix ldapi path in lib389
 * Ticket 49978 - Add CLI logging function for UI
 * Ticket 49929 - Modifications required for the Test Case
   Management System
 * Ticket 49979 - Fix regression in last commit
 * Ticket 49979 - Remove dirsrv tests subpackage
 * Ticket 49928 - Fix various small WebUI schema issues
 * Ticket 49926 - UI - comment out dev cli patchs
 * Ticket 49926 - Add replication functionality to UI

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Configuring Account lockout policy for a individual user or a specific OU

[Mark Reynolds]

On 11/8/18 3:47 AM, Zombie fork wrote:

Hi,
    Today we have a global account lockout policy in 389 which is 
applied to a specific instance.


With many countries applying different compliance rules for securing 
personal data of their cititizen we see an increasing demand to have a 
seperate account lockout policy for special types of accounts or to be 
applied on a Country specific OU.


Example. If we want to have the accountlockoutduration set to 60 
minutes for a specific OU instead of the standard duration applied on 
a global policy , can it be done?
I can see we can apply different password policies but that doesnt 
cover the account Lockout policies.


Yes it does.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy#Configuring_the_Password_Policy-Configuring_SubtreeUser_Password_Policy_Using_the_Command_Line

Here is an example adding account lock settings out to an existing 
subtree password policy for "ou=FR,dc=example,dc=com":


# ldapmodify -D "cn=directory manager" -W

dn: 
cn="cn=nsPwPolicyEntry,ou=FR,dc=example,dc=com",cn=nsPwPolicyContainer,ou=FR,dc=example,dc=com

changetype: modify
replace: passwordLockout
passwordLockout: on
-
replace: passwordLockoutDuration
passwordLockoutDuration: 3600
-
replace: passwordResetFailureCount
passwordResetFailureCount: 1800
-
replace: passwordUnlock
passwordUnlock: on
-
replace: passwordMaxFailure
passwordMaxFailure: 4


HTH,

Mark



Any help would be appreciated.

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Unable to enable SSL using ldapmodify on 389-Directory/1.3.7.5

[Mark Reynolds]

On 11/6/18 4:43 PM, Jason Jenkins wrote:


Hi I’m in the process of migrating from 389-Directory/1.2.11.15 -> 
389-Directory/1.3.7.5. I’m trying to automate the setup. I’m finding 
that I can no longer enable SSL via the command line using ldapmodify. 
For V1.3.7.5 setup I followed 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/enabling_tls. 
After restarting the service, SSL is not enabled. I am able to use the 
Admin Console to enable SSL. I found that the following is missing 
from when I setup via ldapmodify vs Admin Console.


Following is missing even after following the RedHat documentation.

nsSSL3: on

nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+

sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+

,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp

56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128

_256_sha

^^^ This is not required, and in fact most of the ciphers seem outdated, 
but that should not be contributing to the problem.


nsKeyfile: alias/slapd-X-key3.db

nsCertfile: alias/slapd-X-cert8.db

# RSA, encryption, config

dn: cn=RSA,cn=encryption,cn=config

nsSSLToken: internal (software)

nsSSLPersonalitySSL: server-cert

nsSSLActivation: on

objectClass: top

objectClass: nsEncryptionModule

cn: RSA


This is mentioned in the admin guide link you provided


I do notice that when I make the changes via ldapmodify it says that 
the changes have been successfully made, but they don’t show up in a 
search before and after a service restart. Also “nsslapd-security” 
never changes from off to on via command line edit. Here is some info 
about my system.


Is there anything in the errors log after the restart?  FYI, I've never 
heard of config settings that get reverted after a restart.


One thing to try for debugging purposes is to enable the audit log to 
verify the server accepted the changes in the first place.


So I would start over again using ldapmodify (with the audit log 
enabled.)  When things get messed up after the restart please provide us 
the audit and errors log.


Thanks,

Mark


*OS*: CentOS Linux release 7.5.1804 (Core)

*389 packages installed*:

389-adminutil-1.1.21-2.el7.x86_64

389-admin-console-doc-1.1.12-1.el7.noarch

389-admin-console-1.1.12-1.el7.noarch

389-ds-base-libs-1.3.7.5-28.el7_5.x86_64

389-ds-console-1.2.16-1.el7.noarch

389-ds-1.2.2-6.el7.noarch

389-ds-base-1.3.7.5-28.el7_5.x86_64

389-ds-console-doc-1.2.16-1.el7.noarch

389-admin-1.1.46-1.el7.x86_64

389-console-1.1.18-1.el7.noarch

389-dsgw-1.1.11-5.el7.x86_64

*Version of Directory Server*: 389-Directory/1.3.7.5 B2018.269.1826

*Commands executing*:

ldapmodify -x -D "cn=Directory Manager" -w  << EOF

dn: cn=config

changetype: modify

replace: nsslapd-securePort

nsslapd-securePort: 636

-

replace: nsslapd-security

nsslapd-security: on

dn: cn=RSA,cn=encryption,cn=config

changetype: modify

replace: nsSSLToken

nsSSLToken: internal (software)

-

replace: nsSSLPersonalitySSL

nsSSLPersonalitySSL: server-cert

-

replace: nsSSLActivation

nsSSLActivation: on

EOF

systemctl restart dirsrv@X.service


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Allow filters through PTA Plugin

[Mark Reynolds]

On 11/6/18 4:04 AM, LHEUREUX Bernard wrote:

Hi all,

I'm pretty new in the usage of 389-DS and I would like to know if some of you 
could help me achieve a feature that would:

Have a 389-Directory server in front of AD Domain Controllers acting as "ldap 
proxy" to protect access to the DC but allowing to authenticate users with their 
LDAP AD account AND allowing to retrieve the list of Groups members (via filters) of the 
AD through PTA ?

Is that possible and how could achieve this ?


Yes, but you need to use SSSD as well:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/pam-pta#pam-pta-sssd

I personally have not done this, but it is documented in the 
Administration Guide


HTH,
Mark



Thanks for your help

Bernard Lheureux.
Ce message transmis par voie électronique ainsi que toutes ses annexes 
contiennent des informations qui peuvent être confidentielles ou protégées. Ces 
informations sont uniquement destinées à l’usage des personnes ou des entités 
précisées dans les champs ‘A’, ‘Cc’ et ‘Cci’. Si vous n’êtes pas l’un de ces 
destinataires, soyez conscient que toute forme, partielle ou complète, de 
divulgation, copie, distribution ou utilisation de ces informations est 
strictement interdite. Si vous avez reçu ce message par erreur, veuillez nous 
en informer par téléphone ou par message électronique et détruire les 
informations immédiatement. Ce message n’engage que son signataire et 
aucunement son employeur.
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: How to define templates and add an entry to the menu?

[Mark Reynolds]

On 11/2/18 5:38 PM, "Stefan Günther" wrote:

Hello,

when adding a new entry, the menu already contains entries like user, group or 
organizational unit, with preselected attributes.

Is possible to add further entries to this menu, e.g. a kopano user with 
attributes out of the already imported kopano schema?

Thanks for any hints in advance.


The 389-console is unfortunately pretty rigid, and does not do any kind 
of customization like that.


Or, you can take the open source code, modify it to your liking, and 
rebuild it.  There is some information on the wiki [1] if you actually 
want to pursue this approach.


Regards,

Mark

[1] https://www.port389.org -> search for "build console"



Regards,

Stefan
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: When binding non-anonymously, error code 48 - Anonymous access is not allowed

[Mark Reynolds]

On 11/2/18 11:17 AM, Graham Leggett wrote:

Hi all,

My Jira server just forgot all of it’s LDAP settings for no clear reason. While 
trying to put the settings back, Jira is logging into 389ds by binding as the user 
"cn=Atlassian,dc=x”.

389ds is in return responding as follows:

[LDAP: error code 48 - Anonymous access is not allowed]; nested exception is 
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - 
Anonymous access is not allowed]

[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 BIND dn="cn=Atlassian,dc=x" 
method=128 version=3
[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 RESULT err=48 tag=97 nentries=0 
etime=1
[02/Nov/2018:17:11:23 +0200] conn=140630 op=-1 fd=134 closed - B1

Why would 389ds complain that anonymous access is not allowed on a 
non-anonymous bind? What am I missing?


A password :-)

Error 48 usually means a password was not provided in the bind request.  
When that happens the bind is seen as anonymous, and apparently you have 
configured DS to not allow anonymous access.



HTH,

Mark



(389-ds-base-1.2.11.15-97.el6_10.x86_64 on RHEL6)

Regards,
Graham
—
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.3.9.0

[Mark Reynolds]

   389 Directory Server 1.3.9.0

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


Fedora packages are available on Fedora 27.

https://koji.fedoraproject.org/koji/taskinfo?taskID=30581994 



Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2018-8adbba96b5 



The new packages and versions are:

 * 389-ds-base-1.3.9.0-1

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




 Highlights in 1.3.9.0

 * Bug and security fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* if you have 389-admin installed, 
otherwise please run *setup-ds.pl* to set up your directory server.


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please 
run *setup-ds.pl* to update your directory server/admin 
server/console information.


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Branching 1.3.8 to 1.3.9
 * Ticket 49967 - entry cache corruption after failed MODRDN
 * Ticket 49968 - Confusing CRITICAL message: list_candidates - NULL
   idl was recieved from filter_candidates_ext
 * Ticket 49915 - fix compiler warnings (2nd)
 * Ticket 49915 - fix compiler warnings
 * Ticket 49915 - Master ns-slapd had 100% CPU usage after starting
   replication and replication cannot finish

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: issues with password encryption changes after upgrade

[Mark Reynolds]

On 10/31/18 1:25 PM, Ghiurea, Isabella wrote:


Hi list,

we upgrade from1.3.5.15-1.fc24, to  1.3.7.5-24.el7



What platform are you on now?  Do you see any errors in the errors log 
when the server starts up?



, this a multi master replication environment  we are seeing the paswd 
encryption for new users in new  389-DS  has been changed and is 
causing some grief , both version have the start of passwd same string 
:'e1NTSE"  , BUT  the latest  389-DS e has one additional new line . 
Is there anything we can do to have same encryption pattern ?




What do you mean by one additional line?


What is actually breaking and causing you grief?


What does this search return:


ldapsearch -D "cn=directory manager" -xLLL -W -b cn=config -s base 
objectclass=top passwordStorageScheme



It probably returns:


 passwordStorageScheme: PBKDF2_SHA256


This is a more secure hashing algorithm for user passwords than the 
previous default scheme "SSHA512".  You can change the 
passwordStorageScheme to any scheme you want, but it will be less secure 
than PBKDF2_SHA256.



Regards,

Mark




Thank you


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Adding additional optional attritubes

[Mark Reynolds]

Hi Tina,

Sounds like you want to add new/custom schema to the server.  So here in 
a link to the documentation on how to do it:


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

HTH,

Mark



On 10/31/18 10:25 AM, Tina Fora wrote:

Hi All,

I'm running 389-ds-1.2.2-1.el6. I would like to add two optional
attributes for something like Supervisor/Advisor Name and Email. This is
what I have now. Looking for some info on how to go about testing and
making this change.


# ldapsearch -xLLL uid=ldapfoo
dn: uid=ldapfoo,ou=People,dc=burr,dc=example,dc=edu
memberOf: cn=boss,ou=groups,dc=burr,dc=example,dc=edu
memberOf: cn=tgi,ou=groups,dc=burr,dc=example,dc=edu
uid: ldapuser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixAccount
objectClass: ldapPublicKey
objectClass: examplePerson
objectClass: systemQuotas
exampleEduPersonNetID: ldapfoo
cn: Foo Bar
gidNumber: 767
homeDirectory: /home/ldapuser
sn: Fora
givenName: Foo
loginShell: /bin/bash
mail: ldapu...@example.edu
quota: /home:10485760,10485760,0,0
uidNumber: 10170

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Track constraint violation due password policy

[Mark Reynolds]

On 10/31/18 10:37 AM, Alberto Viana wrote:

Hi Mark,

In access log the behavior is exactly how you said (small description):
"invalid password syntax"


Yeah a bit vague :-(

I opened this RFE ticket:

https://pagure.io/389-ds-base/issue/50002   -->  Feel free to add any 
comments, requests, or suggestions


I'm not sure what version this will land in, but what version of 
389-ds-base are you using?


Thanks,

Mark



I know that's related to password policy, but it's really bad not 
known which item exactly. In some cases the users could provide me the 
password and I can analyse, but in some cases not, so I think that 
should exist something in 389 to show to us(admin) that.


Thanks anyway for your help.


On Wed, Oct 31, 2018 at 11:27 AM Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:


Hi Alberto,

Did you check the access log?   There "should" be a small text
message that said what syntax was violated on the RESULT line in
the access log.  Just grep for err=19 in the access logs.  Let me
know if you find it.  But that's all there would be for
troubleshooting this.   Checking the current passwd policy code we
don't have any useful logging in there - we only send small
descriptions of the error back to the client.

So this inspires me to add a new error log level for tracking
password policy behavior.  I will open a new ticket for that RFE
shortly...

Thanks,

Mark

On 10/31/18 10:12 AM, Alberto Viana wrote:

Hi Guys,

There's any way  to log or track constraint violation reason?

Once We have 2 environments I need to track when an user could
change password on windows side but this password could not be
replicated to 389 due to password policy .

I can see this on passsync log:

10/30/18 18:43:38: Searching for (ntuserdomainid=my.user)
10/30/18 18:43:38: Ldap error in ModifyPassword
19: Constraint violation
10/30/18 18:43:38: Modify password failed for remote entry:
uid=my.user,ou=users,dc=my,dc=domain

But I need to know which item on password policy has been violated


Thanks

___
389-users mailing list --389-users@lists.fedoraproject.org  
<mailto:389-users@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-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Track constraint violation due password policy

[Mark Reynolds]

Hi Alberto,

Did you check the access log?   There "should" be a small text message 
that said what syntax was violated on the RESULT line in the access 
log.  Just grep for err=19 in the access logs.  Let me know if you find 
it.  But that's all there would be for troubleshooting this.   Checking 
the current passwd policy code we don't have any useful logging in there 
- we only send small descriptions of the error back to the client.


So this inspires me to add a new error log level for tracking password 
policy behavior.  I will open a new ticket for that RFE shortly...


Thanks,

Mark

On 10/31/18 10:12 AM, Alberto Viana wrote:

Hi Guys,

There's any way  to log or track constraint violation reason?

Once We have 2 environments I need to track when an user could change 
password on windows side but this password could not be replicated to 
389 due to password policy .


I can see this on passsync log:

10/30/18 18:43:38: Searching for (ntuserdomainid=my.user)
10/30/18 18:43:38: Ldap error in ModifyPassword
19: Constraint violation
10/30/18 18:43:38: Modify password failed for remote entry: 
uid=my.user,ou=users,dc=my,dc=domain


But I need to know which item on password policy has been violated


Thanks

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389-console 1.1.19

[Mark Reynolds]

   389 Console 1.1.19

The 389 Directory Server team is proud to announce 389-console version 
1.1.19


Fedora packages are available from the Fedora 28, Fedora 29 and 
Rawhide repositories.


Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=30316371 



Fedora 28 https://koji.fedoraproject.org/koji/taskinfo?taskID=30316405 



The new packages and versions are:

 * 389-console-1.1.19-1

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




 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-console*

To upgrade, use *dnf upgrade 389-console*

See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 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 
and following pages:


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://pagure.io/389-console/new_issue



 Detailed Changelog since 389-console-1.1.18

 * Add JSS’s dependencies to the classpath of 389-console

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Password policy not working

[Mark Reynolds]

That is the wrong package "389-ds", what is the version of "389-ds-base"?

Can you share what is in the server's access log when the password is 
changed (/var/log/dirsrv/slapd-YOUR_INSTACE/access)? There should be a 
few operations that occur during the password change so please make sure 
to provide a full clip from the log.


Thanks,

Mark


On 10/12/18 12:05 PM, Nick W. Harrison wrote:


Hello –

I have a password policy on the OU that contains all of my user 
accounts. This password policy is set on the subtree and the “user may 
change password” option is deselected. However, I’m still able to 
change my password if I use passwd on a LDAP client.


I’m running an older version of 389-ds…v.1.2.2-6…and am wondering if 
there is anything additional I need to put in place to prevent users 
from changing their passwords. My accounts and passwords are 
replicated over from AD with a unidirectional relationship, and the 
clients are doing simple binds.


Thanks for any thoughts.


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: can't start dirsrv-admin service after reboot

[Mark Reynolds]

: AH01575: loaded module setenvif_module from 
/usr/lib64/httpd/modules/mod_setenvif.so
[Wed Oct 10 05:43:20.527112 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module mime_module from 
/usr/lib64/httpd/modules/mod_mime.so
[Wed Oct 10 05:43:20.527200 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module negotiation_module from 
/usr/lib64/httpd/modules/mod_negotiation.so
[Wed Oct 10 05:43:20.527265 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module dir_module from 
/usr/lib64/httpd/modules/mod_dir.so
[Wed Oct 10 05:43:20.527330 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module alias_module from 
/usr/lib64/httpd/modules/mod_alias.so
[Wed Oct 10 05:43:20.527413 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module rewrite_module from 
/usr/lib64/httpd/modules/mod_rewrite.so
[Wed Oct 10 05:43:20.527484 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module cgi_module from 
/usr/lib64/httpd/modules/mod_cgi.so
[Wed Oct 10 05:43:20.527566 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module restartd_module from 
/usr/lib64/dirsrv/modules/mod_restartd.so
[Wed Oct 10 05:43:20.529672 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module nss_module from 
/usr/lib64/httpd/modules/libmodnss.so
[Wed Oct 10 05:43:20.561423 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module admserv_module from 
/usr/lib64/dirsrv/modules/mod_admserv.so
[Wed Oct 10 05:43:20.561453 2018] [:debug] [pid 3447] 
mod_admserv/mod_admserv.c(2607): [3447] create_server_config [0xbogus 
%p for (null)
[Wed Oct 10 05:43:20.561460 2018] [:debug] [pid 3447] 
mod_admserv/mod_admserv.c(2595): [3447] create_config [0xbogus %p for 
(null)
[Wed Oct 10 05:43:20.561599 2018] [so:debug] [pid 3447] 
mod_so.c(266): AH01575: loaded module mpm_worker_module from 
/usr/lib64/httpd/modules/mod_mpm_worker.so
[Wed Oct 10 05:43:20.561669 2018] [so:debug] [pid 3447:tid 
140517964691584] mod_so.c(266): AH01575: loaded module 
access_compat_module from /usr/lib64/httpd/modules/mod_access_compat.so
[Wed Oct 10 05:43:20.561737 2018] [so:debug] [pid 3447:tid 
140517964691584] mod_so.c(266): AH01575: loaded module 
authn_core_module from /usr/lib64/httpd/modules/mod_authn_core.so
[Wed Oct 10 05:43:20.561803 2018] [so:debug] [pid 3447:tid 
140517964691584] mod_so.c(266): AH01575: loaded module 
authz_core_module from /usr/lib64/httpd/modules/mod_authz_core.so
[Wed Oct 10 05:43:20.561862 2018] [so:debug] [pid 3447:tid 
140517964691584] mod_so.c(266): AH01575: loaded module 
authz_user_module from /usr/lib64/httpd/modules/mod_authz_user.so
[Wed Oct 10 05:43:20.561922 2018] [so:debug] [pid 3447:tid 
140517964691584] mod_so.c(266): AH01575: loaded module unixd_module 
from /usr/lib64/httpd/modules/mod_unixd.so
[Wed Oct 10 05:43:20.562517 2018] [mpm_worker:info] [pid 3447:tid 
140517964691584] AH00324: MaxClients is deprecated, use 
MaxRequestWorkers instead.
[Wed Oct 10 05:43:20.562678 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2668): [3447] Set [0xbogus 
%p [ADMCacheLifeTime] to 600
[Wed Oct 10 05:43:20.562683 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2686): [3447] Set [0xbogus 
%p [ADMServerVersionString] to 389-Administrator/1.1.46
[Wed Oct 10 05:43:20.562736 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2595): [3447] 
create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/*
[Wed Oct 10 05:43:20.562739 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2620): [3447] adminsdk 
[0xbogus %p flag 1
[Wed Oct 10 05:43:20.562753 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2595): [3447] 
create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/*
[Wed Oct 10 05:43:20.562756 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2620): [3447] adminsdk 
[0xbogus %p flag 1
[Wed Oct 10 05:43:20.562772 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2595): [3447] 
create_config [0xbogus %p for 
/*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$
[Wed Oct 10 05:43:20.562775 2018] [:debug] [pid 3447:tid 
140517964691584] mod_admserv/mod_admserv.c(2620): [3447] adminsdk 
[0xbogus %p flag 0


in output file there is pid of 3447, but I can't find this pid.


Sincerely,
--
DaV





On Tue, Oct 9, 2018, at 05:46, Mark Reynolds wrote:



On 10/2/18 10:47 PM, DaV wrote:

Hi guys,
I am facing an issue of can't start dirsrv-admin service after 
reboot 389ds server.

Can anyone help me? Thank in advance.
It seems that some files missing after 389ds server reboot.

OS:
CentOS Linux release 7.5.1804 (Core)

Packages:
389-ds-base-1.3.7.5-24.el7_5.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-adminutil-1.1.21-2.el7.x86_64
389-ds-base-libs-1.3.7.5-24.el7_5.x86_64
389-admin-1.1.46-1.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
3

[389-users] Announcing 389 Directory Server 1.3.8.10

[Mark Reynolds]

   389 Directory Server 1.3.8.10

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


Fedora packages are available on Fedora 27.

https://koji.fedoraproject.org/koji/taskinfo?taskID=30171199 



Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2018-a857a4758e 



The new packages and versions are:

 * 389-ds-base-1.3.8.10-1

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




 Highlights in 1.3.8.10

 * Bug and security fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* if you have 389-admin installed, 
otherwise please run *setup-ds.pl* to set up your directory server.


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please 
run *setup-ds.pl* to update your directory server/admin 
server/console information.


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.3.8.10
 * Ticket 49969 - DOS caused by malformed search operation (part 2)

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.18

[Mark Reynolds]

   389 Directory Server 1.4.0.18

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


Fedora packages are available on Fedora 28, 29, and rawhide.

Rawhide

https://koji.fedoraproject.org/koji/taskinfo?taskID=30170262 



Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=30170314 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=30170334 



Bodhi

F29 https://bodhi.fedoraproject.org/updates/FEDORA-2018-6bbce6f746 



F28 https://bodhi.fedoraproject.org/updates/FEDORA-2018-5a691f3035 



The new packages and versions are:

 * 389-ds-base-1.4.0.18-1

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




 Highlights in 1.4.0.18

Bug and security fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.18
 * Ticket 49968 - Confusing CRITICAL message: list_candidates - NULL
   idl was recieved from filter_candidates_ext
 * Ticket 49946 - upgrade of 389-ds-base could remove
   replication agreements.
 * Ticket 49969 - DOS caused by malformed search operation (part 2)

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.3.8.9

[Mark Reynolds]

   389 Directory Server 1.3.8.9

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


Fedora packages are available on Fedora 27.

https://koji.fedoraproject.org/koji/taskinfo?taskID=30150274 



Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2018-143c134572 



The new packages and versions are:

 * 389-ds-base-1.3.8.9-1

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




 Highlights in 1.3.8.9

 * Bug and security fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* if you have 389-admin installed, 
otherwise please run *setup-ds.pl* to set up your directory server.


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please 
run *setup-ds.pl* to update your directory server/admin 
server/console information.


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.3.8.9
 * Ticket 49969 - DOS caused by malformed search operation (security fix)
 * Ticket 49954 - On s390x arch retrieved DB page size is stored as
   size_t rather than uint32_t
 * Ticket 49937 - Log buffer exceeded emergency logging msg is not
   thread-safe (security fix)
 * Ticket 49932 - Crash in delete_passwdPolicy when persistent search
   connections are terminated unexpectedly

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.17

[Mark Reynolds]

   389 Directory Server 1.4.0.17

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


Fedora packages are available on Fedora 28, 29, and rawhide.

Rawhide

https://koji.fedoraproject.org/koji/taskinfo?taskID=30149568 



Fedora 29

https://koji.fedoraproject.org/koji/taskinfo?taskID=30149637 



Fedora 28

https://koji.fedoraproject.org/koji/taskinfo?taskID=30149769 



Bodhi

F28 https://bodhi.fedoraproject.org/updates/FEDORA-2018-2705a7bc42 



F29 https://bodhi.fedoraproject.org/updates/FEDORA-2018-017b0cf3dd 



The new packages and versions are:

 * 389-ds-base-1.4.0.17-1

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




 Highlights in 1.4.0.17

Bug and security fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.17-1
 * Ticket 49969 - DOS caused by malformed search operation (security fix)
 * Ticket 49943 - rfc3673_all_oper_attrs_test is not strict enough
 * Ticket 49915 - Master ns-slapd had 100% CPU usage after starting
   replication and replication cannot finish
 * Ticket 49963 - ASAN build fails on F28
 * Ticket 49947 - Coverity Fixes
 * Ticket 49958 - extended search fail to match entries
 * Ticket 49928 - WebUI schema functionality and improve CLI part
 * Ticket 49954 - On s390x arch retrieved DB page size is stored as
   size_t rather than uint32_t
 * Ticket 49928 - Refactor and improve schema CLI/lib389 part
   to DSLdapObject
 * Ticket 49926 - Fix replication tests on 1.3.x
 * Ticket 49926 - Add replication functionality to dsconf
 * Ticket 49887 - Clean up thread local usage
 * Ticket 49937 - Log buffer exceeded emergency logging msg is not
   thread-safe (security fix)
 * Ticket 49866 - fix typo in cos template in pwpolicy subtree create
 * Ticket 49930 - Correction of the existing fixture function names to
   remove test_ prefix
 * Ticket 49932 - Crash in delete_passwdPolicy when persistent search
   connections are terminated unexpectedly
 * Ticket 48053 - Add attribute encryption test cases
 * Ticket 49866 - Refactor PwPolicy lib389/CLI module
 * Ticket 49877 - Add log level functionality to UI

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: can't start dirsrv-admin service after reboot

[Mark Reynolds]

On 10/2/18 10:47 PM, DaV wrote:

Hi guys,
I am facing an issue of can't start dirsrv-admin service after reboot 
389ds server.

Can anyone help me? Thank in advance.
It seems that some files missing after 389ds server reboot.

OS:
CentOS Linux release 7.5.1804 (Core)

Packages:
389-ds-base-1.3.7.5-24.el7_5.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-adminutil-1.1.21-2.el7.x86_64
389-ds-base-libs-1.3.7.5-24.el7_5.x86_64
389-admin-1.1.46-1.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-console-1.1.18-1.el7.noarch
389-ds-console-1.2.16-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64

/var/log/dirsrv/admin-serv/error
[Mon Oct 01 04:41:14.628926 2018] [mpm_worker:notice] [pid 1515:tid 
139888393697408] AH00295: caught SIGTERM, shutting down
[Mon Oct 01 20:15:10.124133 2018] [:warn] [pid 1498:tid 
140057745549440] NSSSessionCacheTimeout is deprecated. Ignoring.
[Tue Oct 02 00:12:12.064065 2018] [:warn] [pid 1506:tid 
140717522962560] NSSSessionCacheTimeout is deprecated. Ignoring.
[Tue Oct 02 01:24:15.688367 2018] [:warn] [pid 1486:tid 
140470383057024] NSSSessionCacheTimeout is deprecated. Ignoring.
[Tue Oct 02 01:24:15.764891 2018] [:notice] [pid 1486:tid 
140470383057024] Access Host filter is: *.seczone.com
[Tue Oct 02 01:24:15.764904 2018] [:notice] [pid 1486:tid 
140470383057024] Access Address filter is: *
[Tue Oct 02 01:24:15.789117 2018] [:warn] [pid 1487:tid 
140470383057024] NSSSessionCacheTimeout is deprecated. Ignoring.
[Tue Oct 02 01:24:15.789651 2018] [mpm_worker:notice] [pid 1487:tid 
140470383057024] AH00292: Apache/2.4.6 (CentOS) configured -- resuming 
normal operations
[Tue Oct 02 01:24:15.789670 2018] [core:notice] [pid 1487:tid 
140470383057024] AH00094: Command line: '/usr/sbin/httpd -f 
/etc/dirsrv/admin-serv/httpd.conf'
[Tue Oct 02 01:24:15.793251 2018] [:notice] [pid 1489:tid 
140470383057024] Access Host filter is: *.seczone.com
[Tue Oct 02 01:24:15.793278 2018] [:notice] [pid 1489:tid 
140470383057024] Access Address filter is: *
[Tue Oct 02 02:05:48.933732 2018] [mpm_worker:notice] [pid 1487:tid 
140470383057024] AH00295: caught SIGTERM, shutting down



systemctl status dirsrv-admin -l
● dirsrv-admin.service - 389 Administration Server.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; 
enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-10-03 17:34:52 
CST; 1h 6min ago
  Process: 3290 ExecStart=/usr/sbin/httpd -k start -f 
/etc/dirsrv/admin-serv/httpd.conf (code=exited, status=1/FAILURE)


Oct 03 17:34:52 vdi-ds-1 systemd[1]: Starting 389 Administration 
Server
Oct 03 17:34:52 vdi-ds-1 httpd[3290]: httpd: Could not open 
configuration file /etc/dirsrv/admin-serv/httpd.conf: No such file or 
directory



Does this file exist (/etc/dirsrv/admin-serv/httpd.conf) ?

Not sure how this file could disappear, but if it's gone you will need 
to remove the "389-admin" package and reinstall it.


Regards,

Mark


Oct 03 17:34:52 vdi-ds-1 systemd[1]: dirsrv-admin.service: control 
process exited, code=exited status=1
Oct 03 17:34:52 vdi-ds-1 systemd[1]: Failed to start 389 
Administration Server..
Oct 03 17:34:52 vdi-ds-1 systemd[1]: Unit dirsrv-admin.service entered 
failed state.

Oct 03 17:34:52 vdi-ds-1 systemd[1]: dirsrv-admin.service failed.

Sincerely,
--
DaV




___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: password policy

[Mark Reynolds]

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.


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-users@lists.fedoraproject.org
<mailto:389-users@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-users@lists.fedoraproject.org




___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: repl-monitor.pl - monitoring user

[Mark Reynolds]

On 09/07/2018 04:14 AM, rai...@ultra-secure.de wrote:

Hi,

I'd like to define a special user just for monitoring the replication 
(instead of using the Directory Manager).


What kind of permissions does that user need?

Or does that user need to many privileges that I could use the 
Directory Manager anyway?
The user needs permission to read "cn=mapping tree,cn=config" in order 
to read the agreement information, and to read from your suffix's RUV 
entry under "dc=example,dc=com" for nsds50ruv & nsds5agmtmaxcsn





Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Making the console-GUI localhost-only

[Mark Reynolds]

On 09/07/2018 03:47 AM, rai...@ultra-secure.de wrote:

Hi,


so, the GUI is really served by a webserver, as it looks like?

In /etc/dirsrv/admin-serv/console.conf there is a listen directive.

I want to change that to 127.0.0.1 instead of 0.0.0.0. Can I edit that 
file directly or is there some command I have to run - and are there 
any other things that rely on that webserver being available on all 
interfaces, from all IPs.
You can edit it directly, but then restart the admin server: 
restart-ds-admin




Best Regards
Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Question about replication

[Mark Reynolds]

On 09/05/2018 12:36 PM, rai...@ultra-secure.de wrote:

Am 2018-09-04 17:39, schrieb Marc Muehlfeld:

Hi Rainer,


Yes it is a typo, it should be: 
cn=dc\=sub\,dc\=domain\,dc\=ch,cn=mapping tree,cn=config

thanks for finding the typo. I fix it and republished the guide:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-configuring-replication-cmd#Configuring-Replication-Consumers-cmd 






Thanks.
I wasn't sure if it was a silly question - but it surely stumped me.


However, I still can't get replication to work.
(Two hosts, multi-master)

I tried using the command-line only, but the 2nd host would not show 
as "multi-master" in the gui.



It's created the replication manager dn like this:

dn: cn=replication manager,cn=config
objectClass: top
objectClass: device
objectClass: simpleSecurityObject
cn: replication manager
userPassword:  password
nsIdleTimeout: 0


This I entered in the supplier dn dialog on both servers.

The referral url of server A is server B and vice-versa.

I've set different replica IDs.

In the replication-agreement, I again chose server B on server A and 
vice-versa.


I changed the password for the replication manager to be the same on 
both hosts just to be sure.


When I try to start replicating on server B, I get:


[05/Sep/2018:17:08:02.623414486 +0200] - ERR - NSMMReplicationPlugin - 
acquire_replica - agmt="cn=repl-agreement-t1" (serverA:636): Unable to 
acquire replica: permission denied. The bind dn "cn=replication 
manager,cn=config" does not have permission to supply replication 
updates to the replica. Will retry later.
Your replication manager is not configured in the main replication 
config entry.  Example:


dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config
changetype: add
add: nsds5ReplicaBindDN
nsds5ReplicaBindDN: cn=replication manager,cn=config

Do this on both masters

Regards,
Mark






What else do I need?


Server A already contains some data, will this replicate to server B 
upon initialization or do I have to do something special?






Best Regards
Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: 389 console is blank

[Mark Reynolds]

Okay, I think you should remove the o=netscaperoot backend, and rerun 
the register script.   It's not finding your domain ou=northshore.edu in 
o=netscaperoot 


First remove the suffix and database configuration:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/configuring_directory_databases#Maintaining_Suffixes-Deleting_a_Suffix


Stop the server, and then delete this directory: 
/var/lib/dirsrv/slapd-YOUR_INSTANCE/db/Netscaperoot


Start the server and run the register script.

Thanks,

Mark


On 09/04/2018 04:02 PM, Cassandra Reed wrote:

Hi Mark,

Here are the log entries from one of the attempts from today:

[04/Sep/2018:15:32:26 -0400] conn=1352070 op=2 fd=104 closed - U1
[04/Sep/2018:15:32:27 -0400] conn=1352071 fd=101 slot=101 connection 
from 127.0.0.1 to 127.0.0.1
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 BIND dn="" method=128 
version=3
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 BIND 
dn="uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" 
method=128 version=3
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 
dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot"
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 SRCH 
base="o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci"
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 RESULT err=0 tag=101 
nentries=1 etime=0
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 SRCH 
base="cn=389ds1.northshore.edu 
,ou=northshore.edu 
,o=NetscapeRoot" scope=0 
filter="(objectClass=*)" attrs="* aci aci"
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 RESULT err=32 tag=101 
nentries=0 etime=0
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 SRCH 
base="cn=389ds1.northshore.edu 
,ou=northshore.edu 
,o=NetscapeRoot" scope=0 
filter="(objectClass=*)" attrs="* aci aci"
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 RESULT err=32 tag=101 
nentries=0 etime=0
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=5 ADD 
dn="cn=389ds1.northshore.edu 
,ou=northshore.edu 
,o=NetscapeRoot"
[04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 
dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot"
[04/Sep/2018:15:32:28 -0400] conn=1352071 op=5 RESULT err=32 tag=105 
nentries=0 etime=1 csn=5b8eddcb07b3

[04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 UNBIND
[04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 fd=101 closed - U1


Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923




___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: 389 console is blank

[Mark Reynolds]

Can you provide the Directory Server's access log 
(/var/lod/dirsrv/slapd-YOUR_INSTANCE/access) content from the time you 
ran the register script?


Worse case scenario, you can delete o=netscaperoot, and run the script 
again and it will create it from scratch.  Since your setup is corrupted 
that might be best.  Make sure to remove any replication agreements for 
the o=netscaperoot first.


Thanks,
Mark

On 09/04/2018 03:35 PM, Cassandra Reed wrote:

Hi Again,

Tried running the register script and we are getting an error message 
that states "failed to register the configuration server info to the 
Configuration Directory Server..." (Screenshot below).  Any ideas?


image.png

Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Fri, Aug 31, 2018 at 10:01 AM Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:


:-)  There is no downtime it just does a bunch of ldapmodifies to
add the o=netscapeoot suffix.  You might need to restart the admin
server, but not DS.

Here are some useful links:


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Installation_Guide/register-ds-admin.html

http://www.port389.org/docs/389ds/design/console-remote-reg-design.html


On 08/31/2018 09:49 AM, Cassandra Reed wrote:

Output it much better after including -x, screenshot below.  If
we run the register-ds-admin, will there be any downtime to the
server?  I just need to confirm that this will not affect the
userroot database in any way, since classes start next week and I
value my job :)


Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 4:19 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:



On 08/30/2018 03:35 PM, Cassandra Reed wrote:

Thanks, Mark.  When executing the ldapsearch that you
suggested, I am getting an error message:
ldap_sasl_interactive_bind_s: Unknown authentication method
(-6) additional info: SASL(-4): no mechanism available:

Ugh sorry you need to add -x:

ldapsearch -D "cn=directory manager" -W -x -b o=netscapeoot
objectclass=* dn


We have been replicating o=netscaperoot - I am not sure how
up to date the replicas are, considering the trouble that we
are having with the config db right now...

That's the problem.  If you are replicating o=netscaperoot to
other servers that use the console, are you are basically
hosing each one of those servers o=netscaperoot suffix. 
o=netscaperoot is specific to the host in which it was
originally created.  You should only replicate o=netscaperoot
as backup technique, and it should not replicated to a server
that uses the 389-console - otherwise the console won't work
(e.g. blank screen)

So the console will only work on the original server you
started replication from.

Now to fix it, assuming this is the case...

You have to remove o=netscapeorot suffix, and run
register-ds-admin.pl <http://register-ds-admin.pl> to
recreate o=netscaperoot suffix for that server

Regards,
Mark





Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


    On Thu, Aug 30, 2018 at 3:20 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:



On 08/30/2018 03:07 PM, Cassandra Reed wrote:

Hi Mark,

You are correct, it does appear that the o=netscaperoot
suffix was removed.

No, I think it's still there.  Try this search:

    # ldapsearch -D "cn=directory manager" -W -b
o=netscapeoot objectclass=* dn

Maybe try restarting the admin server:

    # restart-ds-admin


Are you replicating o=netscaperoot by any chance?

Mark



Below is a bit of the access log file during the launch
of the console.  We have two other servers that this
Master was replicating to, is it possible to export the
netscaperoot from one of those other two servers and
import to the Master?  What would this require and
would it be service impacting at all?  (Reboot of the
server/etc.) One of the servers hasn't been replicating
in some time, would an older version of netscaperoot
have any impact on the userroot directory?

[30/Aug/2018:14:28:03 -0400] conn=1035324 fd=79 slot=79
connection from 127.0.0.1 to 127.0.0.1
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 BIND
dn="

[389-users] Re: Question about replication

[Mark Reynolds]

On 09/04/2018 10:13 AM, rai...@ultra-secure.de wrote:

Hi,


I'm trying to follow the handbook on creating a multi-master setup (2 
servers).


cat set_referral_on_t2.ldif

dn: cn=cn=dc\=sub\,dc\=domain\,dc\=ch,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-referral
nsslapd-referral: 
ldaps://ldap1.bla.domain.ch:636/dc\=sub\,dc\=domain\,dc\=ch

-
replace: nsslapd-state
nsslapd-state: referral on update


ldapmodify -D "cn=Directory Manager" -W -x -h 127.0.0.1 -v -a -f 
set_referral_on_t2.ldif


Enter LDAP Password:
replace nsslapd-referral:
ldaps://ldap1.bla.domain.ch:636/dc\=sub\,dc\=domain\,dc\=ch
replace nsslapd-state:
referral on update
modifying entry "cn=cn=dc\=sub\,dc\=domain\,dc\=ch,cn=mapping 
tree,cn=config"

ldap_modify: No such object (32)

This is from the manual
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/pdf/administration_guide/Red_Hat_Directory_Server-10-Administration_Guide-en-US.pdf 



page 387.


I've created the consumer on ldap1.
According to the same documentation


Though I always wondered if the cn=cn= part was a typo?
Yes it is a typo, it should be: 
cn=dc\=sub\,dc\=domain\,dc\=ch,cn=mapping tree,cn=config






Anybody got an idea?



Best Regards
Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Installing the console

[Mark Reynolds]

On 09/04/2018 10:01 AM, rai...@ultra-secure.de wrote:

Hi,

I setup several servers with setup-ds.pl, instead of setup-ds-admin.pl.

Now, the console is not configured.

How do I configure it after already configuring the actual 389 server?

When I run setup-ds-admin.pl it wants to re-install, even if I submit 
the --update flag.
No, just run register-ds-admin.pl after installing 389-admin* 
389-admin-console 389-ds-console


It will create the admin server and add the o=netscaperoot suffix to 
your DS, and you should be good to go.


Mark


Best Regards
Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: 389 console is blank

[Mark Reynolds]

:-)  There is no downtime it just does a bunch of ldapmodifies to add 
the o=netscapeoot suffix.  You might need to restart the admin server, 
but not DS.


Here are some useful links:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Installation_Guide/register-ds-admin.html

http://www.port389.org/docs/389ds/design/console-remote-reg-design.html


On 08/31/2018 09:49 AM, Cassandra Reed wrote:
Output it much better after including -x, screenshot below.  If we run 
the register-ds-admin, will there be any downtime to the server?  I 
just need to confirm that this will not affect the userroot database 
in any way, since classes start next week and I value my job :)



Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 4:19 PM Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:




On 08/30/2018 03:35 PM, Cassandra Reed wrote:

Thanks, Mark.  When executing the ldapsearch that you suggested,
I am getting an error message: ldap_sasl_interactive_bind_s:
Unknown authentication method (-6) additional info: SASL(-4): no
mechanism available:

Ugh sorry you need to add -x:

ldapsearch -D "cn=directory manager" -W -x -b o=netscapeoot
objectclass=* dn


We have been replicating o=netscaperoot - I am not sure how up to
date the replicas are, considering the trouble that we are having
with the config db right now...

That's the problem.  If you are replicating o=netscaperoot to
other servers that use the console, are you are basically hosing
each one of those servers o=netscaperoot suffix. o=netscaperoot is
specific to the host in which it was originally created.  You
should only replicate o=netscaperoot as backup technique, and it
should not replicated to a server that uses the 389-console -
otherwise the console won't work (e.g. blank screen)

So the console will only work on the original server you started
replication from.

Now to fix it, assuming this is the case...

You have to remove o=netscapeorot suffix, and run
register-ds-admin.pl <http://register-ds-admin.pl> to recreate
o=netscaperoot suffix for that server

Regards,
Mark





Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 3:20 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:



On 08/30/2018 03:07 PM, Cassandra Reed wrote:

Hi Mark,

You are correct, it does appear that the o=netscaperoot
suffix was removed.

No, I think it's still there.  Try this search:

    # ldapsearch -D "cn=directory manager" -W -b
o=netscapeoot objectclass=* dn

Maybe try restarting the admin server:

    # restart-ds-admin


Are you replicating o=netscaperoot by any chance?

Mark



Below is a bit of the access log file during the launch of
the console.  We have two other servers that this Master was
replicating to, is it possible to export the netscaperoot
from one of those other two servers and import to the
Master?  What would this require and would it be service
impacting at all?  (Reboot of the server/etc.)  One of the
servers hasn't been replicating in some time, would an older
version of netscaperoot have any impact on the userroot
directory?

[30/Aug/2018:14:28:03 -0400] conn=1035324 fd=79 slot=79
connection from 127.0.0.1 to 127.0.0.1
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 BIND
dn="cn=Directory Manager" method=128 version=3
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 RESULT err=0
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 SRCH
base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 RESULT err=32
tag=101 nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 SRCH

base="cn=group,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 RESULT err=32
tag=101 nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 SRCH
base="cn=OU,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
  

[389-users] Re: 389 console is blank

[Mark Reynolds]

On 08/30/2018 03:35 PM, Cassandra Reed wrote:
Thanks, Mark.  When executing the ldapsearch that you suggested, I am 
getting an error message: ldap_sasl_interactive_bind_s: Unknown 
authentication method (-6) additional info: SASL(-4): no mechanism 
available:

Ugh sorry you need to add -x:

ldapsearch -D "cn=directory manager" -W -x -b o=netscapeoot 
objectclass=* dn


We have been replicating o=netscaperoot - I am not sure how up to date 
the replicas are, considering the trouble that we are having with the 
config db right now...
That's the problem.  If you are replicating o=netscaperoot to other 
servers that use the console, are you are basically hosing each one of 
those servers o=netscaperoot suffix.  o=netscaperoot is specific to the 
host in which it was originally created.  You should only replicate 
o=netscaperoot as backup technique, and it should not replicated to a 
server that uses the 389-console - otherwise the console won't work 
(e.g. blank screen)


So the console will only work on the original server you started 
replication from.


Now to fix it, assuming this is the case...

You have to remove o=netscapeorot suffix, and run register-ds-admin.pl 
to recreate o=netscaperoot suffix for that server


Regards,
Mark





Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 3:20 PM Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:




On 08/30/2018 03:07 PM, Cassandra Reed wrote:

Hi Mark,

You are correct, it does appear that the o=netscaperoot suffix
was removed.

No, I think it's still there.  Try this search:

    # ldapsearch -D "cn=directory manager" -W -b o=netscapeoot
objectclass=* dn

Maybe try restarting the admin server:

    # restart-ds-admin


Are you replicating o=netscaperoot by any chance?

Mark



Below is a bit of the access log file during the launch of the
console.  We have two other servers that this Master was
replicating to, is it possible to export the netscaperoot from
one of those other two servers and import to the Master?  What
would this require and would it be service impacting at all? 
(Reboot of the server/etc.)  One of the servers hasn't been
replicating in some time, would an older version of netscaperoot
have any impact on the userroot directory?

[30/Aug/2018:14:28:03 -0400] conn=1035324 fd=79 slot=79
connection from 127.0.0.1 to 127.0.0.1
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 BIND
dn="cn=Directory Manager" method=128 version=3
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 RESULT err=0
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 SRCH
base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 RESULT err=32
tag=101 nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 SRCH
base="cn=group,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 RESULT err=32
tag=101 nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 SRCH
base="cn=OU,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 RESULT err=32
tag=101 nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 SRCH
base="cn=ResourceEditorExtension,ou=1.1,ou=admin,ou=Global
Preferences,ou=northshore.edu
<http://northshore.edu>,o=NetscapeRoot" scope=1
filter="(objectClass=nsAdminResourceEditorExtension)" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 RESULT err=32
tag=101 nentries=0 etime=0


Thank you,
-Cassie

Cassandra Reed
    978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 9:44 AM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:

Are you logging in as Directory Manager?

If you are, perhaps the o=netscaperoot suffix was removed
from DS?  You need to look at the access log in this case and
what it's doing when you log in.

Mark






___
389-users mailing list 

[389-users] Re: 389 console is blank

[Mark Reynolds]

On 08/30/2018 03:07 PM, Cassandra Reed wrote:

Hi Mark,

You are correct, it does appear that the o=netscaperoot suffix was 
removed.

No, I think it's still there.  Try this search:

    # ldapsearch -D "cn=directory manager" -W -b o=netscapeoot 
objectclass=* dn


Maybe try restarting the admin server:

    # restart-ds-admin


Are you replicating o=netscaperoot by any chance?

Mark


Below is a bit of the access log file during the launch of the 
console.  We have two other servers that this Master was replicating 
to, is it possible to export the netscaperoot from one of those other 
two servers and import to the Master?  What would this require and 
would it be service impacting at all?  (Reboot of the server/etc.)  
One of the servers hasn't been replicating in some time, would an 
older version of netscaperoot have any impact on the userroot directory?


[30/Aug/2018:14:28:03 -0400] conn=1035324 fd=79 slot=79 connection 
from 127.0.0.1 to 127.0.0.1
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 SRCH 
base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=northshore.edu <http://northshore.edu>,o=NetscapeRoot" 
scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 RESULT err=32 tag=101 
nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 SRCH 
base="cn=group,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=northshore.edu <http://northshore.edu>,o=NetscapeRoot" 
scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 RESULT err=32 tag=101 
nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 SRCH 
base="cn=OU,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=northshore.edu <http://northshore.edu>,o=NetscapeRoot" 
scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 RESULT err=32 tag=101 
nentries=0 etime=0
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 SRCH 
base="cn=ResourceEditorExtension,ou=1.1,ou=admin,ou=Global 
Preferences,ou=northshore.edu <http://northshore.edu>,o=NetscapeRoot" 
scope=1 filter="(objectClass=nsAdminResourceEditorExtension)" attrs=ALL
[30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 RESULT err=32 tag=101 
nentries=0 etime=0



Thank you,
-Cassie

Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923


On Thu, Aug 30, 2018 at 9:44 AM Mark Reynolds <mailto:mreyno...@redhat.com>> wrote:


Are you logging in as Directory Manager?

If you are, perhaps the o=netscaperoot suffix was removed from
DS?  You need to look at the access log in this case and what it's
doing when you log in.

Mark




___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] please review: PR 49933 - Crash in delete_passwdPolicy when persistent search connections are terminated unexpectedly

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49933
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: ds-privilege-name equivalent

[Mark Reynolds]

On 08/30/2018 12:04 PM, rai...@ultra-secure.de wrote:

Am 2018-08-30 00:48, schrieb William Brown:

On Wed, 2018-08-22 at 12:41 +0200, rai...@ultra-secure.de wrote:

Hi,

I have a few users in my open-ds dump that have the following
attribute:

ds-privilege-name: password-reset


Does something like this exist in 389-server or is it done purely on
an
ACI level?


If I recall correctly, if you have the write targetattr userPassword,
you can reset someone's password. I think this is a good example where
we need to document this better as password reset is a common
requriement.

I've CCed on our documentation wizard who may know where this is found,
or where it should be added.




Hi,

thanks for the feedback.

I used "Passwd Admins" feature.

dn: cn=Passwd Admins,dc=the,dc=domain,dc=ch
changetype: add
objectClass: top
objectClass: groupOfUniqueNames
cn: PasswordAdminsGroup
description: Users in this group can change passwords
uniqueMember: cn=TechUser,dc=the,dc=domain,dc=ch
uniqueMember: cn=reg,dc=appusers,dc=the,dc=domain,dc=ch


dn: cn=config
changetype: modify
replace: passwordAdminDN
passwordAdminDN: cn=Passwd Admins,dc=the,dc=domain,dc=ch


These two users had the ds-privilege-name: password-reset attribute

Is that correct?
Correct, the password admin feature gives a user or a group (like what 
you did) fulll unrestricted access for setting user passwords. They can 
reset passwords, add prehashed passwords, and add passwords that violate 
the server's password policy, etc.


http://www.port389.org/docs/389ds/design/password-administrator.html

Mark







Best Regards
Rainer
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.3.8.8

[Mark Reynolds]

   389 Directory Server 1.3.8.8

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


Fedora packages are available on Fedora 27.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1139178 



Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2018-ab880c1bc5 



The new packages and versions are:

 * 389-ds-base-1.3.8.8-1

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




 Highlights in 1.3.8.8

 * Bug fix and security fix


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* if you have 389-admin installed, 
otherwise please run *setup-ds.pl* to set up your directory server.


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please 
run *setup-ds.pl* to update your directory server/admin 
server/console information.


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.3.8.8
 * Revert “Ticket 49372 - filter optimisation improvements for
   common queries”
 * Revert “Ticket 49432 - filter optimise crash”

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.0.16

[Mark Reynolds]

   389 Directory Server 1.4.0.16

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


Fedora packages are available on Fedora 28, 29, and rawhide.

Rawhide

https://koji.fedoraproject.org/koji/buildinfo?buildID=1139175 



Fedora 29

https://koji.fedoraproject.org/koji/buildinfo?buildID=1139177 



Fedora 28

https://koji.fedoraproject.org/koji/buildinfo?buildID=1139176 



Bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2018-aaf73e583d 



The new packages and versions are:

 * 389-ds-base-1.4.0.16-1

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




 Highlights in 1.4.0.16

Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *dnf install 389-ds-base*, then run *dscreate*. For 
Cockput UI plugin use “dnf install cockpit-389-ds”


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


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



 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 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.0.16
 * Revert “Ticket 49372 - filter optimisation improvements for
   common queries”
 * Revert “Ticket 49432 - filter optimise crash”
 * Ticket 49887 - Fix SASL map creation when –disable-perl
 * Ticket 49858 - Add backup/restore and import/export functionality
   to WebUI/CLI

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

[389-users] Re: Documentation for 1.4

[Mark Reynolds]

On 08/26/2018 11:27 AM, Aleks wrote:

Dear 389 members.

I try to find some documentation about 1.4.0 version on
http://www.port389.org/docs/389ds/documentation.html is there one?

Is there a bigger information what's was changed in 1.4 as I haven't found any
informatin on http://www.port389.org/whats_new.html or
http://www.port389.org/docs/389ds/releases/release-1-4-0-0.html

Hi Aleks,

Sorry the documentation for 1.4.0 is lacking on the wiki.  It is 
something we need to work on, but here is an overview of what's going on 
in 1.4.0


- New Web UI (Cockpit plugin) - we are deprecating the 389-console in 
F28, and removing it in F29 (1.4.1)

    - Work is in progress

- New python CLI tools: dsctl, dsconf, dsidm, and dscreate - we are 
deprecating all the PERL tools (but for now they are available in 
389-ds-base-legacy-tools subpackage)

    - Work is in progress
    - http://www.port389.org/docs/389ds/design/dsadm-dsconf.html

- Ability to use other backend databases, like lmdb
    - Work is in progress.  This might not make 1.4.0 as this is a big 
change


- New Password Policy Syntax features:  Dictionary checks, sequences, 
custom list of bad words, etc, etc.  We basically added most of the 
pam_pwquality features to DS

    - Complete

- Improved internal operation logging in the access log (this is a debug 
feature)

    - Complete

Other than that it is just bug fixes.

Regards,
Mark



Best regards

Aleks
___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@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-users@lists.fedoraproject.org