June 2012 - 389-users - Fedora Mailing-Lists

by Chris Bryant

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 years, 1 month

3
2
0 / 0

CoS plugin and country related fields

by Vlad

Hello, I'm trying to configure classic CoS plug-in to fill automatically "Country" ("c") and "Friendly Country" ("co") based on "countrycode" attribute. While classic CoS works perfectly fine with some ather attributes, I can't get it working with the country related fields I mentioned above. I'd appreciate any help! Thanks in advance, Vladimir.

11 years, 2 months

2
2
0 / 0

Replication broken after each service restart

by Wes Hardin

To preface this, my issue began after upgrading from 1.2.5.x to 1.2.10.4 about a month ago, but I did not immediate recognize the severity at that time. Upon upgrading, it was discovered that replication had ceased to replicate. I got a message saying the "suffix was not enabled". I assume(d) this meant replication was not enabled for the suffix and that I needed to enable it. From the 389-console, the "Enable Replica" box was checked and the Replica Role was "Single Master." I couldn't see any reason for the sudden failure and the continued resistance against my attempts to synchronize my consumers. Eventually, I unchecked "Enable Replica" and (automatically) deleted all my replication agreements. I re-enabled the replica and began recreating all my agreements. Replication resumed normal operation. It wasn't until today that I realized the problem still exists. I rebooted my single master yesterday and today found that replication had stopped again. I exported all my agreements to an LDIF then nuked and rebuilt all my replication settings as I'd done after the upgrade. Replication resumed. Just to test my theory, I then restarted the server again and once again broke replication. Luckily I was prepared this time and was quickly able to recover. Here are some messages showing the rejected attempt to replicate. The first is an update, the second is an initialize. Both seem to indicate replication is not enabled despite evidence to the contrary. [28/Jun/2012:08:35:37 -0500] NSMMReplicationPlugin - Replication agreement for agmt="cn=ausldap001" (ausldap001:389) could not be updated. For replication to take place, please enable the suffix and restart the server [28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - Total update aborted: Replication agreement for "agmt="cn=mfnldap002" (mfnldap002:389)" can not be updated while the replica is disabled [28/Jun/2012:09:31:00 -0500] NSMMReplicationPlugin - (If the suffix is disabled you must enable it then restart the server for replication to take place). I have noticed that I have a lot of entries whose DNs include escaped characters, which I don't remember seeing before. That is, \3D instead of '=' or \2C instead of ','. For example: dn: cn=replica,cn=dc\3Dmaxim-ic\2C dc\3Dcom,cn=mapping tree,cn=config objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=maxim-ic,dc=com nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaId: 7777 nsds5ReplicaPurgeDelay: 604800 cn: replica nsState:: YR4AAAAAAADogOxPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== nsDS5ReplicaName: 240eb382-c13b11e1-bf5ef100-4e39c57a nsds5ReplicaChangeCount: 0 nsds5replicareapactive: 0 But based on the following link, I guess that's to be expected. http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format There also seems to be some inconsistency in how my root is referenced. Sometimes it has a space between the two domain components, sometimes it does not. You can actually see that in the example above. The DN value has a space, the nsDS5ReplicaRoot value has no space. I'm rather inexperienced in the management of LDAP. My upgrade from 1.2.5 to 1.2.10 was just a simple "yum upgrade". I hadn't seen the link about about the DN format or any other upgrade guide. I'm fully willing to allow that I failed to take some required step at the time of the upgrade. Many thanks in advance for any help you can provide. -- /* Wes Hardin */ UNIX/Linux Systems Administrator, IT Engineering Support Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com

11 years, 3 months

2
2
0 / 0

Schema changes from 389 1.2.5

by Moisés Barba Pérez

Hi, I would like to upgrade 389 from 1.2.5 to the last version before the changes in the schema. I mean, In some version of 389 the syntax of some attributes had change and I can't upgrade to that version yet, but I don't know which is that version to upgrade to the previous one. Could you help me? Regards, Moses.

11 years, 3 months

2
1
0 / 0

Evaluating 1.2.11.6 on Fedora17: nsds5ReplicaEnabled

by Juan Carlos Camargo

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

11 years, 3 months

2
1
0 / 0

Announcing 389 Directory Server versions 1.2.10.11 and 1.2.11.6 Testing

by Rich Megginson

The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.11 and 1.2.11.6 for Testing. 1.2.10.11 and 1.2.11.6 contain a fix for a password security issue: #378 unhashed#user#password field https://fedorahosted.org/389/ticket/378 NEW: Platform Support Pre-built RPMs of 1.2.11 and later are only available on Fedora 17 and later. 1.2.10 is still supported on Fedora 16 and earlier and will continue to get important updates. Reminder: Issue Tracking System We have moved our ticket tracking system from the Red Hat Bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora Hosted Trac https://fedorahosted.org/389. This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 This link shows all of the issues fixed in the 1.2.11 branch - https://fedorahosted.org/389/report/13 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 389-dsgw 389-adminutil # 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 389-dsgw 389-adminutil 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(a)lists.fedoraproject.org Reporting Issues https://fedorahosted.org/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

11 years, 3 months

1
0
0 / 0

How To Enable Track when password was last modified passwordTrackUpdateTime

by Tom Jalbert

I need this feature but I'm unsure where/how to turn it on. Could someone point me in the right direction? Thanks, -Tom >From "New Features in 1.2.11 lists" Track when password was last modified passwordTrackUpdateTime - if this is set to "on", the server will keep track of the last password update time pwdUpdateTime - new operational attribute in entries holds the last password update time if passwordTrackUpdateTime is enabled

11 years, 3 months

2
2
0 / 0

Problem after disabling anonymous binds

by Jeroen van Meeuwen

Hi there, I'm curious as to whether anyone else has experienced this problem before; Disabling anonymous binds causes the 389-console to be unable to locate the entry corresponding to the user name used to login with (or so it seems). In other words, disabling anonymous binds causes 389-console to be rendered disfunctional ;-) I'd like to learn if this is a known problem, and/or whether there is a known workaround for the issue. Thank you in advance, Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08

11 years, 3 months

3
4
0 / 0

Announcing 389 Directory Server versions 1.2.10.10 and 1.2.11.5 Testing

by Rich Megginson

The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.10 and 1.2.11.5 for Testing. 1.2.10.10 contains a fix for a crashing issue: #390 [abrt] 389-ds-base-1.2.10.6-1.fc16: slapi_attr_value_cmp: Process /usr/sbin/ns-slapd was killed by signal 11 (SIGSEGV) https://fedorahosted.org/389/ticket/390 1.2.11.5 is the first stable release of 1.2.11. 1.2.11 contains many, many new features and bug fixes. Please see the Release Notes for more details. NEW: Platform Support Pre-built RPMs of 1.2.11 and later are only available on Fedora 17 and later. 1.2.10 is still supported on Fedora 16 and earlier and will continue to get important updates. Reminder: Issue Tracking System We have moved our ticket tracking system from the Red Hat Bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora Hosted Trac https://fedorahosted.org/389. This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 This link shows all of the issues fixed in the 1.2.11 branch - https://fedorahosted.org/389/report/13 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 389-dsgw 389-adminutil # 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 389-dsgw 389-adminutil 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(a)lists.fedoraproject.org Reporting Issues https://fedorahosted.org/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

11 years, 3 months

1
0
0 / 0

Proxying authentication

by Alberto Suárez

Hello! Can I use the Pass-Through Authentication pluging to forward my user's credentials (login name and password) to a non 389ds LDAP server when the user tries to bind to the directory server and use the response of that back-end server to allow or deny the bind operation? Thank you. Alberto Suárez.

11 years, 3 months

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users June 2012