about 389 directory updates-testing repository
by Steven Li
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
14 years
case sensitivity and matching rules
by Christopher Wood
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.
14 years
Unregister a server
by Mister Anonyme
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
14 years
DNA plugin woes on a fresh centos-DS 8.1 install
by Daniel Maher
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/p...
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>
14 years
Announcing 389 Directory Server 1.2.6 Alpha 3
by Rich Megginson
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
14 years
Memory alloc error
by Techie
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
######
14 years
Random failures on startTLS
by Aaron Hagopian
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
14 years
Error when doing "add" and "modify" operation with SSHA passwords
by Fabio Isgrò
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ò
14 years