The 389 Project team is pleased to announce the release of 389-ds-base-1.2.9.6. This release has fixes for bugs found in 1.2.9 testing and bugs from earlier releases.
NEW: EL6 support
Beginning with RHEL 6.1, the 389-ds-base package is included in the base OS. It is the same as the upstream, except that it has no replication nor windows sync functionality. That has been split off into a new channel - Enterprise Identity Replication - and a new package - ds-replication. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions.
However, the 389 Project will still make the full 389-ds-base package, including replication/winsync, available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information.
Installation
yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds setup-ds-admin.pl
Upgrade
yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console # or for EPEL yum upgrade --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates * In the Search box in the upper right hand corner, type in the name of the package * In the list, find the version and release you are using (if you're not sure, use rpm -qi <package name> on your system) and click on the release * On the page for the update, scroll down to "Add a comment" and provide your input
Or just send us an email to 389-users@lists.fedoraproject.org
Reporting Bugs
If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389
More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download
On 08/16/2011 02:04 PM, Rich Megginson wrote:
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.9.6. This release has fixes for bugs found in 1.2.9 testing and bugs from earlier releases.
Just a warning, I had trouble with the 1.2.9.6 upgrade as I had an aci setup where I removed the default anonymous read,search,compare access at the root (dc=messinet,dc=com), but allowed access via ip or dns in lower ou=* statements. In 1.2.9.6, this caused the server to lockup completely.
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
This was a showstopper for me though as it no longer gives me the ability to control access at lower levels of the DIT without explicit deny aci's which are toucher to manager as they always override allow aci's.
-A
On 08/16/2011 02:23 PM, Anthony Messina wrote:
On 08/16/2011 02:04 PM, Rich Megginson wrote:
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.9.6. This release has fixes for bugs found in 1.2.9 testing and bugs from earlier releases.
Just a warning, I had trouble with the 1.2.9.6 upgrade as I had an aci setup where I removed the default anonymous read,search,compare access at the root (dc=messinet,dc=com), but allowed access via ip or dns in lower ou=* statements. In 1.2.9.6, this caused the server to lockup completely.
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
Indeed, yes, please let us know asap.
This was a showstopper for me though as it no longer gives me the ability to control access at lower levels of the DIT without explicit deny aci's which are toucher to manager as they always override allow aci's.
-A
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 08/16/2011 03:25 PM, Rich Megginson wrote:
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
Indeed, yes, please let us know asap.
Sure. If you know the settings I need to enable to increase logging, as well as what you would need for this type of problem, etc., please let me know as this will greatly speed up my ability to provide useful information. -A
On 08/16/2011 03:33 PM, Anthony Messina wrote:
On 08/16/2011 03:25 PM, Rich Megginson wrote:
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
Indeed, yes, please let us know asap.
Sure. If you know the settings I need to enable to increase logging, as well as what you would need for this type of problem, etc., please let me know as this will greatly speed up my ability to provide useful information. -A
If it is aci related, there are two: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting 128 Access control list processing (very detailed!) 262144 ACI summary information
probably the latter for starters. Otherwise, just a way to reproduce the problem in a few steps. If you do get the server to hang, follow the steps at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except that, instead of a core file, pass in the process id of the running slapd.
On 08/16/2011 04:40 PM, Rich Megginson wrote:
On 08/16/2011 03:33 PM, Anthony Messina wrote:
On 08/16/2011 03:25 PM, Rich Megginson wrote:
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
Indeed, yes, please let us know asap.
Sure. If you know the settings I need to enable to increase logging, as well as what you would need for this type of problem, etc., please let me know as this will greatly speed up my ability to provide useful information. -A
If it is aci related, there are two: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting 128 Access control list processing (very detailed!) 262144 ACI summary information
probably the latter for starters. Otherwise, just a way to reproduce the problem in a few steps. If you do get the server to hang, follow the steps at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except that, instead of a core file, pass in the process id of the running slapd.
I've tried to reproduce this issue in a virtual host and I can reproduce it, when logging error logging is basically off. Using either 128 or 262144 slows things down, but I don't get the server hang.
Steps to reproduce: 1) Install 389-ds-base and admin-serv with setup-ds-admin.pl, option 2.
2) Remove the "Allow anonymous access" ACI from the root entry
3) Starting doing some searches.
Wait for the server to stop accepting requests. Again, with nsslapd-errorlog-level set to > 0, I cannot reproduce the problem.
Does anyone else remove the "Allow anonymous" ACI from the root entry?
My goal is to only allow anonymous access to hosts from inside the LAN using dns= or ip= entries.
On 08/22/2011 02:51 PM, Anthony Messina wrote:
On 08/16/2011 04:40 PM, Rich Megginson wrote:
On 08/16/2011 03:33 PM, Anthony Messina wrote:
On 08/16/2011 03:25 PM, Rich Megginson wrote:
I havent filed a bug yet as I am working on a virtual environment to test, which I'm sure you'll want me to, in order to be able to replicate the issue ;)
Indeed, yes, please let us know asap.
Sure. If you know the settings I need to enable to increase logging, as well as what you would need for this type of problem, etc., please let me know as this will greatly speed up my ability to provide useful information. -A
If it is aci related, there are two: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting 128 Access control list processing (very detailed!) 262144 ACI summary information
probably the latter for starters. Otherwise, just a way to reproduce the problem in a few steps. If you do get the server to hang, follow the steps at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except that, instead of a core file, pass in the process id of the running slapd.
I've tried to reproduce this issue in a virtual host and I can reproduce it, when logging error logging is basically off. Using either 128 or 262144 slows things down, but I don't get the server hang.
Steps to reproduce:
Install 389-ds-base and admin-serv with setup-ds-admin.pl, option 2.
Remove the "Allow anonymous access" ACI from the root entry
Starting doing some searches.
Wait for the server to stop accepting requests. Again, with nsslapd-errorlog-level set to> 0, I cannot reproduce the problem.
I'm using the latest code on RHEL 6.1 x86_64. This is what I did: setup-ds.pl - use suffix dc=example,dc=com
after the server starts, use ldapmodify: dn: dc=example,dc=com changetype: modify delete: aci aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
Then did a bunch of subtree scope searches from dc=example,dc=com - as directory manager and as root
No hang. How long does it take for you to see hangs? You say "Wait for the server to stop accepting requests" - how long do you wait? Any chance you could use gdb to get a stack trace of the server while it is hung? Basically, following the directions at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except do ps -ef|grep ns-slapd to get the pid, then use gdb /usr/sbin/ns-slapd $pid
Does anyone else remove the "Allow anonymous" ACI from the root entry?
My goal is to only allow anonymous access to hosts from inside the LAN using dns= or ip= entries.
On 08/22/2011 05:40 PM, Rich Megginson wrote:
I'm using the latest code on RHEL 6.1 x86_64. This is what I did: setup-ds.pl - use suffix dc=example,dc=com
after the server starts, use ldapmodify: dn: dc=example,dc=com changetype: modify delete: aci aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
Then did a bunch of subtree scope searches from dc=example,dc=com - as directory manager and as root
No hang. How long does it take for you to see hangs? You say "Wait for the server to stop accepting requests" - how long do you wait? Any chance you could use gdb to get a stack trace of the server while it is hung? Basically, following the directions at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except do ps -ef|grep ns-slapd to get the pid, then use gdb /usr/sbin/ns-slapd $pid
Thanks for giving it a shot, Rich. I'll give it another good go this upcoming weekend. For me, I didn't need to wait long on my core server as this is the one that gets all the requests from SSSD and EGroupWare.
On my virtual host, it took many many tries to reproduce.
I'll set aside some time to do as you request. -A
On 08/22/2011 04:55 PM, Anthony Messina wrote:
On 08/22/2011 05:40 PM, Rich Megginson wrote:
I'm using the latest code on RHEL 6.1 x86_64. This is what I did: setup-ds.pl - use suffix dc=example,dc=com
after the server starts, use ldapmodify: dn: dc=example,dc=com changetype: modify delete: aci aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
Then did a bunch of subtree scope searches from dc=example,dc=com - as directory manager and as root
No hang. How long does it take for you to see hangs? You say "Wait for the server to stop accepting requests" - how long do you wait? Any chance you could use gdb to get a stack trace of the server while it is hung? Basically, following the directions at http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes except do ps -ef|grep ns-slapd to get the pid, then use gdb /usr/sbin/ns-slapd $pid
Thanks for giving it a shot, Rich. I'll give it another good go this upcoming weekend. For me, I didn't need to wait long on my core server as this is the one that gets all the requests from SSSD and EGroupWare.
On my virtual host, it took many many tries to reproduce.
Ok. I'll just keep trying. Does it matter who you do the search as? That is, do you use directory manager, anonymous, or a regular user?
I'll set aside some time to do as you request. -A
On 08/22/2011 06:37 PM, Rich Megginson wrote:
Ok. I'll just keep trying. Does it matter who you do the search as? That is, do you use directory manager, anonymous, or a regular user?
Most of the queries were run anonymously (internal to the LAN) for SSSD.
I'll set aside some time to do as you request. -A
I'll see about moving up my schedule to reproduce this. If it helps, my structure was as follows:
dc=messinet,dc=com (anonymous perms removed, all other defaults intact) | +-ou=People (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Groups (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Special Users (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Computers (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=eGW (allowed dns=localhost,messinet.com,*.messinet.com)
-A
On 08/22/2011 11:00 PM, Anthony Messina wrote:
On 08/22/2011 06:37 PM, Rich Megginson wrote:
Ok. I'll just keep trying. Does it matter who you do the search as? That is, do you use directory manager, anonymous, or a regular user?
Most of the queries were run anonymously (internal to the LAN) for SSSD.
I'll set aside some time to do as you request. -A
I'll see about moving up my schedule to reproduce this. If it helps, my structure was as follows:
Can you provide the exact aci you used below?
dc=messinet,dc=com (anonymous perms removed, all other defaults intact) | +-ou=People (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Groups (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Special Users (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Computers (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=eGW (allowed dns=localhost,messinet.com,*.messinet.com)
-A
On 08/23/2011 09:26 AM, Rich Megginson wrote:
Can you provide the exact aci you used below?
dc=messinet,dc=com (anonymous perms removed, all other defaults intact) | +-ou=People (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Groups (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Special Users (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Computers (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=eGW (allowed dns=localhost,messinet.com,*.messinet.com)
-A
Attached, find the original ACIs I used prior to 389-ds-base-1.2.9.6-1.fc15.i686
Since the upgrade, I have needed to leave the following default in place:
aci: (targetattr != "userPKCS12 || userPassword")(version 3.0;acl "Enable anon ymous access"; allow (read,compare,search)(userdn = "ldap:///anyone");)
But as you can see, the makes it incredibly difficult to restrict acces based on tree structure as everyone already has read access. -A
On 08/23/2011 04:26 PM, Anthony Messina wrote:
On 08/23/2011 09:26 AM, Rich Megginson wrote:
Can you provide the exact aci you used below?
dc=messinet,dc=com (anonymous perms removed, all other defaults intact) | +-ou=People (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Groups (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Special Users (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=Computers (allowed dns=localhost,messinet.com,*.messinet.com) | +-ou=eGW (allowed dns=localhost,messinet.com,*.messinet.com)
-A
Attached, find the original ACIs I used prior to 389-ds-base-1.2.9.6-1.fc15.i686
Since the upgrade, I have needed to leave the following default in place:
aci: (targetattr != "userPKCS12 || userPassword")(version 3.0;acl "Enable anon ymous access"; allow (read,compare,search)(userdn = "ldap:///anyone");)
But as you can see, the makes it incredibly difficult to restrict acces based on tree structure as everyone already has read access. -A
Thanks. It seems to have something to do with the number and type of acis being used.
I don't have all of the schema for these, but this revealed another bug - https://bugzilla.redhat.com/show_bug.cgi?id=733103 - but I don't think you are running into this problem - do you ever get syntax errors attempting to add acis? Do you ever have the problem while adding acis?
Even after fixing this bug, I'm still unable to reproduce the problem. I've tried something like this: $ ii=0; while [ $ii -lt 10000 ] ; do ldapsearch -x -LLL -h localhost -p 1389 -b "ou=people,dc=example,dc=com" > /dev/null & ii=`expr $ii + 1` ; done
Perhaps it has something to do with the search base, scope, filter, and attrs your application uses?
At
On 08/24/2011 02:21 PM, Rich Megginson wrote:
Thanks. It seems to have something to do with the number and type of acis being used.
I don't have all of the schema for these, but this revealed another bug
- https://bugzilla.redhat.com/show_bug.cgi?id=733103 - but I don't think
you are running into this problem - do you ever get syntax errors attempting to add acis? Do you ever have the problem while adding acis?
Even after fixing this bug, I'm still unable to reproduce the problem. I've tried something like this: $ ii=0; while [ $ii -lt 10000 ] ; do ldapsearch -x -LLL -h localhost -p 1389 -b "ou=people,dc=example,dc=com" > /dev/null & ii=`expr $ii + 1` ; done
Perhaps it has something to do with the search base, scope, filter, and attrs your application uses?
Again, thanks. I don't think I've run into #733103, but I've CC'd myself there. Fuynny, I used the same method to try to crash the server, which didn't work on my VM.
One thing that was running queries against the server at or around the upgrade was SSSD.
The other was EGroupWare, which uses a base of "ou=eGW,dc=messinet,dc=com"
I'll keep trying little things through the week, but don't have time to fix a major crash until the weekend. -A
On 08/24/2011 02:21 PM, Rich Megginson wrote:
Thanks. It seems to have something to do with the number and type of acis being used.
I don't have all of the schema for these, but this revealed another bug
- https://bugzilla.redhat.com/show_bug.cgi?id=733103 - but I don't think
you are running into this problem - do you ever get syntax errors attempting to add acis? Do you ever have the problem while adding acis?
Even after fixing this bug, I'm still unable to reproduce the problem. I've tried something like this: $ ii=0; while [ $ii -lt 10000 ] ; do ldapsearch -x -LLL -h localhost -p 1389 -b "ou=people,dc=example,dc=com" > /dev/null & ii=`expr $ii + 1` ; done
Perhaps it has something to do with the search base, scope, filter, and attrs your application uses?
Rich, I'm going to wait to retry this issue with your latest updates-testing build: https://admin.fedoraproject.org/updates/389-ds-base-1.2.9.8-1.fc15
On 08/31/2011 05:10 PM, Anthony Messina wrote:
On 08/24/2011 02:21 PM, Rich Megginson wrote:
Thanks. It seems to have something to do with the number and type of acis being used.
I don't have all of the schema for these, but this revealed another bug
- https://bugzilla.redhat.com/show_bug.cgi?id=733103 - but I don't think
you are running into this problem - do you ever get syntax errors attempting to add acis? Do you ever have the problem while adding acis?
Even after fixing this bug, I'm still unable to reproduce the problem. I've tried something like this: $ ii=0; while [ $ii -lt 10000 ] ; do ldapsearch -x -LLL -h localhost -p 1389 -b "ou=people,dc=example,dc=com" > /dev/null & ii=`expr $ii + 1` ; done
Perhaps it has something to do with the search base, scope, filter, and attrs your application uses?
Rich, I'm going to wait to retry this issue with your latest updates-testing build: https://admin.fedoraproject.org/updates/389-ds-base-1.2.9.8-1.fc15
Thanks to Rich, this issue is resolved with: https://admin.fedoraproject.org/updates/389-ds-base-1.2.9.9-1.fc15
389-users@lists.fedoraproject.org
-
Anthony Joseph Messina -
Rich Megginson