April 2010 - 389-users - Fedora mailing-lists

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

changelogdb has gotten large...
by Hartmann, Tim 09 Sep '10

09 Sep '10

Hi, I've run into a situation where one of the files in /var/lib/dirsrv/<instance>/changelogdb has grown almost as large as the partition it's on. In my directory server configs, I noticed I was keeping an unlimited changelog, so I set that to what seems like a reasonably long amount of time (18 weeks) but didn't see any decrease in the file size. I'm wondering now about the best course of action. I can a) move the whole dirsrv directory to another partition with more space available and symlink the old location to the new, which worked when I tested it, but I wanted to make sure I wouldn't be hosing something up the next time I upgrade. b) find some means of manually shrinking the *.db ( can you even do that?) c) point dirsrv at a new location, and reinitialize the consumers (which doesn't seem all that desirable) Has anyone else found it necessary to shrink your changelogdb? Thanks -Tim

4 3

Strange behaviour - SAMBA is writing on a Dedicated Consumer Server
by Diretorio Livre 06 May '10

06 May '10

6 15

Windows sync stopped working
by Aaron Hagopian 30 Apr '10

30 Apr '10

I had everything setup to sync to my domain controller and things were working fine. Recently I saw this message in the logs: [30/Apr/2010:11:59:10 -0500] NSMMReplicationPlugin - agmt="cn=toto.hra.local" (10:636): windows_replay_update: Cannot replay add operation. So I thought maybe I would try to remove the agreement and re-add it and re-initalize. After doing this now I get this message again along with the every 5 seconds. [30/Apr/2010:12:01:31 -0500] NSMMReplicationPlugin - agmt="cn=toto.hra.local" (10:636): Replica has no update vector. It has never been initialized. This is on 389-ds 1.2.5 running on x86_64 RHEL 5.4 I think this all started when I added an ipHost entry to an OU that should not even be looked at for syncing purposes. Any ideas on how to clear this up so I can sync with windows again? I'm not using the create new users or groups, just trying to sync passwords.

2 3

Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 28 Apr '10

28 Apr '10

Rich, Migration completed, SSL enabled, console is working! I used the 25changefedorato389.pl as a guide. In NetscapeRoot.ldif: + converted all cn=Fedora to cn=389 + converted all fedora to 389 (this converted the jar files and nicknames). Thank you for your help, Craig Swanson On 04/28/2010 10:09 AM, Rich Megginson wrote: > Craig Swanson wrote: >> Rich, >> >> Thanks for the prompt reply. >> Ok, I'll not assume that SSL is the problem. >> >> My setup is: >> SSL is enabled in its original configuration on the source. >> updated autofs and mozilla ldif files. >> db2ldif to export the userRoot and NetscapeRoot databases. >> Modified just the source /opt/fedora-ds/admin-serv/config/adm.conf >> and local.conf to replace cn=Fedora with cn=389 >> >> The migration fails during migration of the Administration Server with: >> check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-punch, >> cn=389 Administration Server, cn=Server Group, >> cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error >> No such object > I think the main problem is that migration does not convert Fedora to > 389. That's why you get the errors like > +++check_and_add_entry: Entry not found cn=389 Administration Server, > cn=Server Group, cn=punch.midwest-tool.com, ou=midwest-tool.com, > o=NetscapeRoot error No such object > > Because the migrated NetscapeRoot.ldif file has cn=Fedora > Administration Server > > There is an upgrade scriptlet - > /usr/share/dirsrv/updates-admin/25changefedorato389.pl - if you are a > perl hacker, you could probably take that and use it to fix > NetscapeRoot.ldif before starting migration. > > If not, then your best bet is to dump the old NetscapeRoot to ldif and > fix it manually - be sure to use db2ldif -U so that the LDIF lines > won't be wrapped - if the lines are wrapped, it will make finding all > occurrances of "Fedora" quite difficult if not impossible with > something like sed/awk/perl. >> >> I'll send the debug log directly to you. >> >> Craig Swanson

1 0

Re: [389-users] Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 28 Apr '10

28 Apr '10

Rich, Thanks for the prompt reply. Ok, I'll not assume that SSL is the problem. My setup is: SSL is enabled in its original configuration on the source. updated autofs and mozilla ldif files. db2ldif to export the userRoot and NetscapeRoot databases. Modified just the source /opt/fedora-ds/admin-serv/config/adm.conf and local.conf to replace cn=Fedora with cn=389 The migration fails during migration of the Administration Server with: check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-punch, cn=389 Administration Server, cn=Server Group, cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error No such object I'll send the debug log directly to you. Craig Swanson Craig Swanson wrote: > I am hoping for guidance in migrating this SSL enabled directory to > 389-ds. > > From: fedora-ds 1.0.4 on fc6 i386 > To: 389-ds 1.1 on fedora 12 i386. The fedora 12 is on a new box > with the same IP address and hostname. > > SSL is enabled on the source directory and source admin server. > > I have read the SSL HowTo, so I understand that the certs are stored > differently under 1.1. > Is it possible to import the existing SSL certs and set up the > configuration so that the migration will succeed? migration is supposed to take care of all of that for you > If not, how do I correctly remove SSL from the source configuration? > I could set up SSL on the target after the migration. > > Thank you, > > Craig Swanson > > ----------Supporting information --------------------- > > So far I have done this 1.0.4 to 1.1 prep: > > I have modified the source schema to use the updated autofs and > mozilla ldif files. > I have run db2ldif to export the userRoot and NetscapeRoot databases. > I have modified the source /opt/fedora-ds/admin-serv/config/adm.conf > and local.conf to replace cn=Fedora with cn=389 adm.conf - ok local.conf - not so good - this is just a read-only copy of information stored in o=NetscapeRoot in the actual database. > Bad outcomes: > I ran the cross platform migration in order to pull from the modified > ldif files. > migrate-ds-admin.pl -d --crossplatform --oldsroot=/opt/fedora-ds.104 > --actualsroot=/opt/fedora-ds -f /opt/migratePunch.inf > > The migration failed because I had not dealt with the SSL. Debug output: > > +[27/Apr/2010:12:44:26 -0400] - 389-Directory/1.2.5 B2010.012.2035 > starting up > +[27/Apr/2010:12:44:26 -0400] - I'm resizing my cache now...cache was > 208736256 and is now 8388608 > +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher AES > +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES > in attrcrypt_cipher_init > +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in > attrcrypt_init > +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher 3DES > +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES > in attrcrypt_cipher_init > +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in > attrcrypt_init > +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher AES > +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES > in attrcrypt_cipher_init > +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in > attrcrypt_init > +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher 3DES > +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES > in attrcrypt_cipher_init > +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in > attrcrypt_init These errors are probably ok if you are not using the attribute encryption feature. You ideally should not have these errors, but this doesn't mean SSL won't work. > > Disabling SSL in the source: > I have tried to disable SSL on the source directory and admin server > via the console. Let's try to figure out what happened initially with migration first.

1 0

Migrate fedora-ds 1.0.4 SSL Enabled
by Craig Swanson 27 Apr '10

27 Apr '10

I am hoping for guidance in migrating this SSL enabled directory to 389-ds. From: fedora-ds 1.0.4 on fc6 i386 To: 389-ds 1.1 on fedora 12 i386. The fedora 12 is on a new box with the same IP address and hostname. SSL is enabled on the source directory and source admin server. I have read the SSL HowTo, so I understand that the certs are stored differently under 1.1. Is it possible to import the existing SSL certs and set up the configuration so that the migration will succeed? If not, how do I correctly remove SSL from the source configuration? I could set up SSL on the target after the migration. Thank you, Craig Swanson ----------Supporting information --------------------- So far I have done this 1.0.4 to 1.1 prep: I have modified the source schema to use the updated autofs and mozilla ldif files. I have run db2ldif to export the userRoot and NetscapeRoot databases. I have modified the source /opt/fedora-ds/admin-serv/config/adm.conf and local.conf to replace cn=Fedora with cn=389 Bad outcomes: I ran the cross platform migration in order to pull from the modified ldif files. migrate-ds-admin.pl -d --crossplatform --oldsroot=/opt/fedora-ds.104 --actualsroot=/opt/fedora-ds -f /opt/migratePunch.inf The migration failed because I had not dealt with the SSL. Debug output: +[27/Apr/2010:12:44:26 -0400] - 389-Directory/1.2.5 B2010.012.2035 starting up +[27/Apr/2010:12:44:26 -0400] - I'm resizing my cache now...cache was 208736256 and is now 8388608 +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in attrcrypt_init +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in attrcrypt_init +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher AES in attrcrypt_init +[27/Apr/2010:12:44:27 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES +[27/Apr/2010:12:44:27 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init +[27/Apr/2010:12:44:27 -0400] - Failed to initialize cipher 3DES in attrcrypt_init Disabling SSL in the source: I have tried to disable SSL on the source directory and admin server via the console. Next, I had attempted a migration. The migration completed, but, the console failed authentication on the resulting 1.1 server. http://myserver:64000 I went back to the source server. launching the console http://myserver:64000 also failed authentication.

2 1

Re: [389-users] 389-users Digest, Vol 59, Issue 21
by Aaron Mills 27 Apr '10

27 Apr '10

Thanks for your help all. it looks like CRYPT was the problem. I've changed passwords over to SSHA and everything works as designed. -Aaron From: Elías Halldór Ágústsson <elias(a)hi.is<mailto:elias@hi.is>> Date: April 26, 2010 6:18:45 PM MDT To: "389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>" <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>> Subject: Re: [389-users] Entire password not checked Reply-To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>> Aaron Mills skrifaði: However, whenever users authenticate via LDAP the server appears to check only the first 8 characters of their passwords. You're probably using the CRYPT password method. Other, newer and safer methods, such as SSHA, can store much longer passwords. <Digest Footer.txt> Aaron Mills Systems Administrator Return Path, Inc. aaron.mills(a)returnpath.net<mailto:aaron.mills@returnpath.net>

1 0

Entire password not checked
by Aaron Mills 26 Apr '10

26 Apr '10

Hi All, I have an FDS and 389 instance set up with a number of users, and password policy requiring minimum password length, some numbers, and some other characters. This all works well for mandating secure passwords. However, whenever users authenticate via LDAP the server appears to check only the first 8 characters of their passwords. For example if a user has a password of "foobar1234!" they can still login with "foobar12" or "foobar12bazbaz" I've tested this with unix client logins (via PAM) and directly via the ldapsearch command. Both exhibit the same behavior. Goo diligence hasn't really turned up anything, though it could be I'm missing the obvious. Has anyone run into this problem before? Is this possibly an issue with they way i'm storing passwords? -Aaron

3 2

disable SSL at startup
by Thomas Cameron 26 Apr '10

26 Apr '10

Howdy - Posting this to the list just because Google searches didn't tell me. Very possible I was asking the wrong question, but here's what I was searching for. How do you disable SSL at startup for Fedora Directory Server (389)? In /etc/dirsrv/slapd-[hostname]/dse.ldif, change the line: nsslapd-security: on to: nsslapd-security: off Back story: I was messing about with SSL certificates and I did something wrong. Not sure what yet, but since my cert was borked, after I installed it, 389 wouldn't start. Since the LDAP server wouldn't start, the admin server wouldn't allow me to log in. I was kind of screwed. Once I set the LDAP server to start without SSL, I was able to log in and now I can (hopefully) figure out what I did wrong with the certificate. The error I was getting was: /var/log/dirsrv/slapd-e510/errors:[24/Apr/2010:18:12:30 -0500] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert e510 server-cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8179 - Peer's Certificate issuer is not recognized.)

2 1

about 389 directory updates-testing repository
by Steven Li 23 Apr '10

23 Apr '10

Hi Team How can I set the repository for updates-testing? When I run yum upgrade --enablerepo=updates-testing 389-ds 389-ds-base 389-admin idm-console-framework 389-console 389-ds-console got error: "repository not found". I can't find url to set the repository for "updates-testing" Thanks Steven Li | System Engineer Skyworth Building Unit A501,Gaoxin Ave.1.S Nanshan District, Shenzhen | China | Post Code: 518057 Mobile CN: +86 13662557907 Telephone 0755-26010416

3 2

case sensitivity and matching rules
by Christopher Wood 20 Apr '10

20 Apr '10

I'm puzzling over case-sensitivity, attributes, and matching rules in 389. I have an attribute (oid slightly munged for privacy): attributeTypes: ( 1.2.3.4 NAME 'ldapAuthLogin' DESC 'Account login name' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) It doesn't look like there's a matching rule associated with this. How does 389 decide which matching rules to apply here? (In this case, per ldapsearch, it seems to be a case-insensitive string match.) My apologies if this is obviously answered somewhere, I've pored over the docs and the mailing list archives and haven't found it yet.

2 1

Unregister a server
by Mister Anonyme 19 Apr '10

19 Apr '10

Hi, A server crashed (physically, hardware failure) and we decided to no replace it. In the Configuration Server, I would like to remove the server from the server list in the console but I'm unable to do so. I tried with this command: ds_removal, but it needs to be run on the same the server that has to be removed. Is there any other way to 'unregister' a server from the console on the configuration server ? Thank you! _________________________________________________________________ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465

2 4

DNA plugin woes on a fresh centos-DS 8.1 install
by Daniel Maher 19 Apr '10

19 Apr '10

Hello, First off, my apologies if this is not an appropriate forum for asking questions related to the CentOS Directory Server. The 389-users archives contain numerous messages related to this platform, so... The situation : fresh install of CentOS 5.4 x86_64, installed the DS via yum from the standard repos : # yum install centos-ds centos-ds-base nss_ldap The DS is up and running. I can create groups and users, run queries, and so forth. I followed the following procedure to enable the DNA plugin : Main menu of Directory Server TAB: Servers and Applications <domain> -> <server> -> Server Group -> Directory Server TAB: Configuration <server> -> Plug-ins -> Distributed Numeric Assignment [X] Enable plug-in Save I then dutifully restarted DS afterwards. Finally, in the user creation menu, in the Posix User section, i checked Enable Posix User Attributes, but none of the fields were auto-populated. Initially, i tried adding the following ldif (i realise this is for the Fedora DNS, but hey, i thought it'd be worth a shot) : http://cvs.fedoraproject.org/viewvc/ldapserver/ldap/servers/plugins/dna/pos… Unsurprisingly (?), this did not work : ldap_add: DSA is unwilling to perform ldap_add: additional info: Not a valid DNA configuration entry. I read through a number of items on the subject, including the following notable items : http://www.directory.fedora.redhat.com/wiki/DNA_Plugin http://www.redhat.com/docs/manuals/dir-server/8.1/admin/dna.html In section 3.6.3.1 of the Red Hat document it outlines the steps to activate the plug-in. Steps 1 and 2 appear to have already been executed by the graphical manager, as the necessary changes are present in the configuration file : /etc/dirsrv/<server>/dse.ldif I attempted to perform step 3 (with appropriate modifications to the dc's). This did not work : adding new entry cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config ldap_add: DSA is unwilling to perform ldap_add: additional info: Not a valid DNA configuration entry. (It may be worth noting that the screenshot they include at the base of that page bears absolutely no resemblance to that of the actual plugin.) My questions are : 1. Is the expected behaviour of the DNA plug-in to auto-populate the Posix fields ? 2a. If so, how can i properly activate this functionality ? 2b. If not, does this functionality exist ? And as a corollary, what is the DNA plug-in for, exactly ? 3. Should i, in fact, be attempting to use the Fedora DS offering instead of that included in CentOS ? (I.e. is it « better » ?) I am happy to provide any logs, debug output, configuration elements, etc.. Thank you for your kind consideration, and keep up the great work ! -- Daniel Maher <dma + 389users AT witbe DOT net>

3 14

Announcing 389 Directory Server 1.2.6 Alpha 3
by Rich Megginson 19 Apr '10

19 Apr '10

Firstly, we would like to offer a big thanks to the 389 community for all of the issues you have found, and for being so patient with us while we investigated some of these problems. This is a big help in improving the quality of the project. The 389 team is pleased to announce the availability of Alpha 3 of version 1.2.6. This release contains the new feature Managed Entries (e.g. auto creation of the user private group entry when creating the user entry) - as well as many bug fixes. NOTE: Packages for Enterprise Linux are available from EPEL. We will no longer have a separate yum repo for these packages. NOTE: 1.2.6 alpha 1 and 2 had separate -selinux packages for 389-ds-base and 389-admin. These are gone in alpha 3, and instead, the selinux policy is provided by the base package. Upgrade is supposed to obsolete these -selinux packages - if it does not, you may have to manually delete them (yum erase 389-ds-base-selinux 389-admin-selinux). ***We need your help! Please help us test this software.*** It is an Alpha release, so it may have a few glitches, but it has been tested for regressions and for new feature bugs. The Fedora system strongly encourages packages to be in Testing until verified and pushed to Stable. If we don't get any feedback while the packages are in Testing, the packages will remain in limbo, or get pushed to Stable. The more testing we get, the faster we can release these packages to Stable. See the Release Notes for information about how to provide testing feedback (or just send an email to 389-users(a)lists.fedoraproject.org) The packages that need testing are: * 389-ds-base-1.2.6.a3 - 389-ds-base * 389-admin-1.1.11.a3 - 389-admin There are some new console/java packages too, and there is a new version of the 389-ds "meta" package - 1.2.1 * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download === New features === * Managed Entries - http://port389.org/wiki/Managed_Entry_Design ** Used, for example, to automatically create the user's group entry when adding a user entry === Bugs Fixed === This release contains a couple of bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.6 release - https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

1 0

Announcing 389 Directory Server 1.2.6 Alpha 2
by Rich Megginson 19 Apr '10

19 Apr '10

The 389 team is pleased to announce the availability of Alpha 2 of version 1.2.6. This release contains some major new features - Subtree Rename, SELinux policy, Matching Rules - as well as many bug fixes. NOTE: Packages for Enterprise Linux are available from EPEL. We will no longer have a separate yum repo for these packages. ***We need your help! Please help us test this software.*** It is an Alpha release, so it may have a few glitches, but it has been tested for regressions and for new feature bugs. The Fedora system strongly encourages packages to be in Testing until verified and pushed to Stable. If we don't get any feedback while the packages are in Testing, the packages will remain in limbo, or get pushed to Stable. The more testing we get, the faster we can release these packages to Stable. See the Release Notes for information about how to provide testing feedback (or just send an email to 389-users(a)lists.fedoraproject.org) The packages that need testing are: * 389-ds-base-1.2.6.a2 - 389-ds-base and 389-ds-base-selinux * 389-admin-1.1.11.a2 - 389-admin and 389-admin-selinux * 389-adminutil-1.1.10 - 389-adminutil * 389-ds-1.2.0 - 389-ds * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download === New features === * Subtree Rename and Entry Move (modifyDN with newSuperior) ** https://bugzilla.redhat.com/show_bug.cgi?id=429005 ** ability to rename a node that has children ** ability to move a node, with or without children, to another parent node * Security Enhancements ** [[SELinux_Policy|SELinux Policy]] *** https://bugzilla.redhat.com/show_bug.cgi?id=442228 * Matching rules ** support for all RFC 4517 matching rules (except the FirstComponent ones) === Bugs Fixed === This release contains a couple of bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. This release contains many bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.6 release - https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0 ** [https://bugzilla.redhat.com/show_bug.cgi?id=171338 171338] Enhancement: winsync modrdn not synced ** [https://bugzilla.redhat.com/show_bug.cgi?id=434735 434735] SASL ANONYMOUS is broken in x86_64 ** [https://bugzilla.redhat.com/show_bug.cgi?id=460162 460162] FedoraDS "with-FHS" installs init.d StartupScript in wrong location on non-RHEL/Fedora OS ** [https://bugzilla.redhat.com/show_bug.cgi?id=460168 460168] FedoraDS' adminutil requires non-existent "icu.pc" on non-RH/Fedora OS ** [https://bugzilla.redhat.com/show_bug.cgi?id=460209 460209] adminserver "./configure --help" error @ --with-apr-config ** [https://bugzilla.redhat.com/show_bug.cgi?id=498103 498103] [RFE] SELinux policy for the Directory Server ** [https://bugzilla.redhat.com/show_bug.cgi?id=506206 506206] problems linking with -z defs ** [https://bugzilla.redhat.com/show_bug.cgi?id=509201 509201] rhds81 hub with 71 master - err=32 on replica base search during replication ** [https://bugzilla.redhat.com/show_bug.cgi?id=516611 516611] 389 DS segfaults on libsyntax-plugin.so ** [https://bugzilla.redhat.com/show_bug.cgi?id=518084 518084] Out of order retro change log records ** [https://bugzilla.redhat.com/show_bug.cgi?id=519459 519459] Semi-hardcoded include and lib directories in db.m4 ** [https://bugzilla.redhat.com/show_bug.cgi?id=531929 531929] rhds8.1 seg fault on null bvals in syntax plug-in ** [https://bugzilla.redhat.com/show_bug.cgi?id=536703 536703] Red Hat Direct Directory Migration 7.1 -> 8.1 problems ** [https://bugzilla.redhat.com/show_bug.cgi?id=537466 537466] nsslapd-distribution-plugin should not require plugin name to begin with "lib" ** [https://bugzilla.redhat.com/show_bug.cgi?id=539618 539618] Replication bulk import reports Invalid read/write ** [https://bugzilla.redhat.com/show_bug.cgi?id=543080 543080] Bitwise plugin fails to return the exact matched entries for Bitwise search filter ** [https://bugzilla.redhat.com/show_bug.cgi?id=544089 544089] Referential Integrity Plugin does not take into account the attribute subtypes ** [https://bugzilla.redhat.com/show_bug.cgi?id=548115 548115] memory leak in schema reload ** [https://bugzilla.redhat.com/show_bug.cgi?id=548535 548535] memory leak in attrcrypt ** [https://bugzilla.redhat.com/show_bug.cgi?id=551198 551198] LDAPI: incorrect logging to access log ** [https://bugzilla.redhat.com/show_bug.cgi?id=552419 552419] 389-admin-1.1.10-0.2.a2.el5 fails to start ** [https://bugzilla.redhat.com/show_bug.cgi?id=552421 552421] Cannot log into admin server after upgrade (fedora-ds-admin-1.1.6 -> 389-admin-1.1.9 ** [https://bugzilla.redhat.com/show_bug.cgi?id=553027 553027] Support for nsUniqueId and alias for additional retro changelog attributes ** [https://bugzilla.redhat.com/show_bug.cgi?id=554841 554841] Unitialized mutex in Retro Changelog Plugin. ** [https://bugzilla.redhat.com/show_bug.cgi?id=554887 554887] Net::LDAP password modify extop breaks; msgid in response is 0xFF ** [https://bugzilla.redhat.com/show_bug.cgi?id=555970 555970] seg fault maybe on cos or nsview changes and replication? ** [https://bugzilla.redhat.com/show_bug.cgi?id=558518 558518] several spelling errors ** [https://bugzilla.redhat.com/show_bug.cgi?id=559315 559315] Searching some attributes are now case sensitive when they were previously case-insensitive ** [https://bugzilla.redhat.com/show_bug.cgi?id=560827 560827] Admin Server: DistinguishName validation fails ** [https://bugzilla.redhat.com/show_bug.cgi?id=564876 564876] FTBFS 389-ds-base-1.2.6-0.1.a1.fc13: ImplicitDSOLinking ** [https://bugzilla.redhat.com/show_bug.cgi?id=568196 568196] Install DS8.2 on Solaris fails

2 1

Memory alloc error
by Techie 18 Apr '10

18 Apr '10

Hello, I recently moved from 389 to RHDS. The system is 32 bit RHEL5 with 4GB of RAM. My instance of RHDS recently stopped suddenly. The error log shows the following.. [17/Apr/2010:22:28:27 -0700] memory allocator - calloc of 1 elems of 10664 bytes failed; OS error 12 (Cannot allocate memory) The server has probably allocated all available virtual memory. To solve this problem, make more virtual memory available to your server, or reduce one or more of the following server configuration settings: nsslapd-cachesize (Database Settings - Maximum entries in cache) nsslapd-cachememsize (Database Settings - Memory available for cache) nsslapd-dbcachesize (LDBM Plug-in Settings - Maximum cache size) nsslapd-import-cachesize (LDBM Plug-in Settings - Import cache size). Can't recover; calling exit(1). I have used FDS/389 for nearly 2 years and had not encountered this error so not sure where to start. The settings for the above mentioned parameters(cachesize,cachememsize,dbcachesize,import-cachesize) are identical to the setting on my instances of FDS/389. I am assuming these are the defaults and are not the cause of the problem. I read this thread http://osdir.com/ml/general/2010-04/msg00801.html This thread mentions having your nsslapd-cachememsize large enough to hold your db in memory. I don't know if this is relevant or not.. I do remember seeing that Fedora dynamically increased cache sizes on my boxes with FDS/389 instances in the past. I am not sure if RHEL does the same or if that is the issue. My nsslapd-cachememsize is set to .. nsslapd-cachememsize: 10485760 My id2entry.db4 sizes for each of my 3 DBs are.. 40MB, 22MB, and 6MB.. Is there some way to help me to identify what may have caused the issue? Perhaps a setting on RHEL5 as opposed to Fedora needs to be tweaked or set as far as the OS is concerned. My package info is below. Thank you Name : redhat-ds-admin Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 9.el5dsrv Build Date: Wed 08 Apr 2009 04:53:46 PM PDT Summary : Red Hat Administration Server (admin) ###### Name : redhat-admin-console Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 2.el5dsrv Build Date: Tue 03 Mar 2009 02:24:39 PM PST Summary : Red Hat Admin Server Management Console ###### Name : redhat-ds-console Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 5.el5dsrv Build Date: Wed 25 Mar 2009 04:44:52 PM PDT Summary : Red Hat Directory Server Management Console ###### Name : redhat-ds-base Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 0.14.el5dsrv Build Date: Tue 21 Apr 2009 11:32:00 AM PDT Summary : Red Hat Directory Server (base) ###### Name : redhat-ds Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 1.el5dsrv Build Date: Tue 17 Mar 2009 04:36:44 PM PDT Summary : Red Hat Directory, Administration, and Console Suite ###### Name : redhat-idm-console Relocations: (not relocatable) Version : 1.0.1 Vendor: Red Hat, Inc. Release : 1.el5idm Build Date: Wed 08 Apr 2009 09:34:10 AM PDT Summary : Red Hat Management Console ######

1 0

Random failures on startTLS
by Aaron Hagopian 17 Apr '10

17 Apr '10

I'm having an issue that seems somewhat random or maybe at least load related when trying to change or reset a user's password. We have some java code that creates an unencrypted connection, start's a TLS session, then sends a password change extended operation. This code seems to work fine in regular testing but sometimes randomly, the password change requests fail due to an odd error message When the failure occurs the error message received from the server is: [LDAP: error code 1 - Other operations are still pending on the connection.] Which made me think at first it was using a pooled connection but I have verified that it is not using a pooled connection. The connection is created new then the StartTLS request is made. Looking at the access log for one of these failed connections I see this (3008 is the conn): [14/Apr/2010:08:27:55 -0500] conn=3008 fd=66 slot=66 connection from 127.0.0.1 to 127.0.0.1 [14/Apr/2010:08:27:55 -0500] conn=3007 op=11 ABANDON targetop=NOTFOUND msgid=11 [14/Apr/2010:08:27:55 -0500] conn=3008 op=0 BIND dn="cn=Manager,dc=hranet,dc=org" method=128 version=3 [14/Apr/2010:08:27:55 -0500] conn=3008 op=1 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [14/Apr/2010:08:27:55 -0500] conn=3008 op=1 RESULT err=1 tag=120 nentries=0 etime=0 [14/Apr/2010:08:27:55 -0500] conn=3008 op=2 UNBIND [14/Apr/2010:08:27:55 -0500] conn=3008 op=2 fd=66 closed - U1 [14/Apr/2010:08:27:55 -0500] conn=3008 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=manager,dc=hranet,dc=org" Which looks like the startTLS failed but why would there be other operations still pending on the connection if that is the only operation that has even been requested. Is it possible the startTLS hasn't finished when the password request is being asked? A successful operation looks like this in the log: [14/Apr/2010:08:31:05 -0500] conn=3016 fd=66 slot=66 connection from 127.0.0.1 to 127.0.0.1 [14/Apr/2010:08:31:05 -0500] conn=3016 op=0 BIND dn="cn=Manager,dc=hranet,dc=org" method=128 version=3 [14/Apr/2010:08:31:05 -0500] conn=3016 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=manager,dc=hranet,dc=org" [14/Apr/2010:08:31:05 -0500] conn=3016 op=1 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [14/Apr/2010:08:31:05 -0500] conn=3016 op=1 RESULT err=0 tag=120 nentries=0 etime=0 [14/Apr/2010:08:31:05 -0500] conn=3016 SSL 128-bit RC4 [14/Apr/2010:08:31:05 -0500] conn=3016 op=2 BIND dn="uid=lyoung,ou=clients,ou=people,dc=hranet,dc=org" method=128 version=3 [14/Apr/2010:08:31:05 -0500] conn=3016 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=lyoung,ou=clients,ou=people,dc=hranet,dc=org" [14/Apr/2010:08:31:05 -0500] conn=3016 op=3 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" [14/Apr/2010:08:31:05 -0500] conn=3016 op=3 RESULT err=19 tag=120 nentries=0 etime=0 [14/Apr/2010:08:31:05 -0500] conn=3016 op=4 UNBIND [14/Apr/2010:08:31:05 -0500] conn=3016 op=4 fd=66 closed - U1 Is this just a bug with directory server? Any thoughts or ideas are welcomed. Thanks, Aaron Hagopian

3 12

Error when doing "add" and "modify" operation with SSHA passwords
by Fabio Isgrò 16 Apr '10

16 Apr '10

Hi to all, I'm using the lastest stable version of 389-ds and when I cut and paste an user from a branch to another or import an user with an SSHA password scheme I get this strange error uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain: netscape.ldap.LDAPException: error result (19); invalid password syntax - passwords with storage scheme are not allowed And it also happens when using Mozilla ldapmodify but with Openldap version everything goes fine. Here a specimen of an user entry > # entry-id: 41964 > dn: uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain > mail: testUser(a)domain.it > uid: testUser > givenName: testUser > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: testUser > cn: testUser > userPassword: {SSHA}Qm33jLgIeXUNOOdESn9g+fMeg59ecxRQnRPKMA== > creatorsName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > modifiersName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > createTimestamp: 20100205124926Z > modifyTimestamp: 20100205124926Z > nsUniqueId: c2d9a301-1dd111b2-80d0d492-e75cfaf > If can help you on the subtree the are some passwords policies applied. Some ideas ? Thanks in Advance Fabio Isgrò

2 1

Database link error management
by Francesco Fiore 16 Apr '10

16 Apr '10

2 1

Chaining database tuning
by Francesco Fiore 14 Apr '10

14 Apr '10

1 0

PasswordExpirationTime
by Mister Anonyme 12 Apr '10

12 Apr '10

Hi, I exported some databases into LDIF files (db2ldif) and imported them in DS8.1 freshly installed. Then, I went to the "o=" subtree and activated password policy like this "Users much change their passwords after 1 day". I took a user in this subtree and changed the password. Normally, I should see a new attribute "PasswordExpirationTime" but it seems not. So, as a test, I created a new o= subtree like this: o=TestPwd,dc=test,dc=net Then, I created a new user inside it: ebobo After, I activated a password policy, I saw that two entries were created in this subtree like this: cn=nSPwPolicyContainer,o=TestPwd,dc=test,dc=net (two entries inside) "cn=nsPwPolicyEntry,o=TestPwd,dc=test,dc=net" (I can see this attr: passwordexp on) "cn=nsPwTemplateEntry,o=TestPwd,dc=test,dc=net" cn=nsPwPolicy_CoS,o=TestPwd,dc=test,dc=net I changed ebobo's password and I still doesn't see the new attribute "PasswordExpirationTime" in "Advanced properties" in the console. If I check on "Show all Allowd Attributes", I can see this attribute but it isn't set. I tried to set the PasswordExpirationTime myself in ebobo's account in this format: 200901011223Z but this account isn't de-activated because of the expiration time, I can still log-on on some sites with this account. I took a look in access/error logs and there were not errors, only normal operations. I can provide it if needed. I'm wondering if there's any other step to successfully activate the max age password policy ? Thank you! _________________________________________________________________ Got a phone? Get Hotmail & Messenger for mobile! http://go.microsoft.com/?linkid=9724464

1 0

nsAIMpresence error
by Angelo Babudro 08 Apr '10

08 Apr '10

Greetings. I am a first-time user of the 389 DS -- version 1.1.3-6.el5 installed from the EPEL RPMs. When I try to enter my first user, using web interface, I keep running into an error when trying to enter people that says: An error occured while contacting the LDAP server. (Object class violation - unknown object class "nsaimpresence") I've scanned the files in /etc/dirsrv as well as /usr/share/dirsrv (grep -ri nsaim) but the only thing I see is nsaimid. There doesn't seem to be anyone else talking about this, which makes me think I must've done something wrong, but whatever it is I've done it again: after erasing and starting over I'm back at the same roadblock. I can enter groups, OUs, anything but people. I found a reference to 10presence.ldif being deprecated and an old schema from RHDS 6.2 docs, but trying to re-create that file got me nowhere. Can anyone tell me how to get past this problem? Thanks in advance for any assistance. -- Angelo

2 1

Referral and Read-Only Replica Consumer
by Chun Tat David Chu 08 Apr '10

08 Apr '10

Hi All, I have an issue on referral and read-only replica. My setup consists of two multi-master suppliers and 1 read-only replica consumer. MM1 <-> MM2 | | | | ---->C<----- The replication is configured to use SSL, port 636. I notice that the automatic referral is done via the unencrypted port 389. What do I need to do to ensure the referral is done over the SSL port 636 as well? Thanks, David

2 2

can the 389 directory substitute for active directory?
by Ralph Blach 08 Apr '10

08 Apr '10

Can 389 server substitute for a windows active directory server? Thanks Chip

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users April 2010