gmane.linux.redhat.fedora.directory.user

Using Wildcard SSL Certificate

Jeff Field — 2012-05-26T04:41:43

Hello,
I'm attempting to use a Wildcard SSL certificate for my domain with 389ds.
The certificate and the CA (godaddy) intermediate cert import fine into
both the admin server and the directory server, but attempts to use an
LDAPS:// URI with ldapmodify result in this error:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

curl gets this:

curl -vvv -3 https://myserver.ldap.mydomain.com:636
* About to connect() to myserver.ldap.mydomain.com port 636 (#0)
*   Trying x.x.x.x... connected
* Connected to myserver.ldap.mydomain.com (x.x.x.x) port 636 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL: certificate subject name '*.mydomain.com' does not match target host
name 'myserver.ldap.mydomain.com'
* NSS error -12276
* Closing connection #0
curl: (51) SSL: certificate subject name '*.mydomain.com' does not match
target host name 'myserver.ldap.mydomain.com'

Am I not able to use a wildcard SSL cert in this instance? If that is th

Re: Upgrade to fedora 16 with real CA fails

Rich Megginson — 2012-05-24T19:49:54

There's http://port389.org/wiki/Howto:SSL
and
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html

--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Upgrade to fedora 16 with real CA fails

Chris Cawley — 2012-05-24T19:20:38

I am looking for a step by step guide for the command line version of an SSL install.

I have some steps; however, I do not believe that they are correct.

-          Chris

From: Rich Megginson [mailto:rmeggins< at >redhat.com]
Sent: Wednesday, May 23, 2012 3:06 PM
To: General discussion list for the 389 Directory server project.
Cc: Chris Cawley
Subject: Re: [389-users] Upgrade to fedora 16 with real CA fails

On 05/23/2012 12:59 PM, Chris Cawley wrote:
Hello,

    I went through some of the docs/emails; however, it still seems like

    The NSS is not working correctly.

Not sure what you mean.

    On a separate, but related issue, it seems like you cannot use

    the GUI to generate a key with 2048 bits.

Right.  https://fedorahosted.org/389/ticket/362

In the meantime, use certutil to generate the CSR.

To get a real CA, some

    vendors ask for this.

        -          Thanks
        -          Chris

Chris Cawley
System Administrator
Washington Resear

About 389 cache and backend behavior

Roberto Polli — 2012-05-24T15:49:44

Hi all,

where can I find a brief description of the 389 communication between:
 - client
 - 389 cache
 - 389 backend
 - COS and VLV 

Is there a way to dwell into it without reading the code?

Thx+ Peace,
R.

Re: 389 vs Sun DS ldapmodify performance

Rich Megginson — 2012-05-23T20:32:25

ok - please file a ticket at  https://fedorahosted.org/389


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: 389 vs Sun DS ldapmodify performance

Russell Beall — 2012-05-23T20:11:10

I have not tried modrdn.

Very early in my testing I thought I was seeing unbounded growth by performing endless deletes (and re-adds).  That, I found out through your much-appreciated responses to this list, was causing an explosion in tombstone entries and thus the server was exploding in actual data requirements.

We don't actually place much importance on that use case because we hardly ever delete an entry, so the housekeeping process for tombstones is more than ample for that cleanup.

The ldapmodify use case is critical to us however, because we perform large quantities of ldapmodify operations every day.

This memory growth situation I have described here applies specifically and only to endless ldapmodify operations.

Regards,
Russ.

On May 23, 2012, at 12:34 PM, Rich Megginson wrote:


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: 389 vs Sun DS ldapmodify performance

Rich Megginson — 2012-05-23T19:34:14

Have you tried modrdn?  delete?  I was just wondering if the problem is 
specific to ldapmodify.


Ok, good to know.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: 389 vs Sun DS ldapmodify performance

Russell Beall — 2012-05-23T19:19:41

On May 23, 2012, at 9:36 AM, Rich Megginson wrote:


Yes.  I guess unbounded was the wrong word now that the ratio of the boundary seems to be shown.  The boundary of the memory growth seems to be (6 * cachememsize).

It doesn't grow unless it gets hit with ldapmodify operations.  It seems to correctly use the cachememsize and the dbcachesize when reading in all entries and doesn't grow if just hit with ldapsearch.


Ok.

Russ.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Upgrade to fedora 16 with real CA fails

Rich Megginson — 2012-05-23T19:05:45

Not sure what you mean.


Right.  https://fedorahosted.org/389/ticket/362

In the meantime, use certutil to generate the CSR.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Upgrade to fedora 16 with real CA fails

Chris Cawley — 2012-05-23T18:59:05

Hello,



    I went through some of the docs/emails; however, it still seems like

    The NSS is not working correctly.

    On a separate, but related issue, it seems like you cannot use

    the GUI to generate a key with 2048 bits.  To get a real CA, some

    vendors ask for this.

        -          Thanks
        -          Chris

Chris Cawley
System Administrator
Washington Research Library Consortium
301-390-2049
cawley< at >wrlc.org


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: 389 vs Sun DS ldapmodify performance

Rich Megginson — 2012-05-23T16:36:27

But based on what you say later in the post, it's not unbounded, it's 
just not bounded by what you set as the cache size?


Yes, please.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: 389 vs Sun DS ldapmodify performance

Russell Beall — 2012-05-23T16:27:44

Hi,

I've been doing a lot more testing to try to flesh out the issue here.  I upgraded to the latest stable version from the rmeggins repo, but found the same memory growth behavior in that instance.

I have a few more details which clarify much better what I'm experiencing.

Unbounded memory growth for an endless chain of ldapmodify operations is seen in both cases where the cache size limit is reached as well as when the maximum cache size is well above the total data size of all entries and all entries are loaded.

On the contrary, when I reduce the cachememsize to nothing, (which then is reset for me to the minimum value of 512000), I see no memory growth at all, and the only memory consumed is just slightly larger than the DB cache size set.

I found that I can use some cache and still get a stable configuration by setting a cache size of only 3GB, and then the memory usage reaches a plateau of 24G (including a DB cache size that I don't remember).

A similar ratio is seen when setting a cachememsize o

Re: Disable unhashed#user#password altogether

Lucas Sweany — 2012-05-22T22:19:51

Well I definitely don't need that. It looks like I will end up writing a
script to delete or overwrite the attribute for now.

Thanks,

-Lucas

On Tue, May 22, 2012 at 3:12 PM, Rich Megginson <rmeggins< at >redhat.com> wrote:

--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Rich Megginson — 2012-05-22T22:12:06

No.  You only need it if you sync passwords _to_ AD - AD requires the 
clear text password.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Lucas Sweany — 2012-05-22T22:09:47

I am syncing from an AD domain one way (onewaysync: fromWindows), and using
the Password Sync service on the domain controllers. Perhaps the Password
Sync service requires the attribute?  Even if so, it would be nice if the
plain text attribute were to go away once the password hash was stored.

-Lucas

On Tue, May 22, 2012 at 2:54 PM, Rich Megginson <rmeggins< at >redhat.com> wrote:

--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Rich Megginson — 2012-05-22T21:54:44

Unless you need to use Windows Sync, yes.  If you plan to use Windows 
Sync you'll have to replicate the unhashed#user#password to the server 
that has the windows sync agreement.


--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Mark Reynolds — 2012-05-22T21:54:01

Well I know it's needed for replicating with AD, but it appears it's 
added regardless if replication is in use.  I'm not too familiar with 
this though, but I'll update the ticket with this request.

Mark


On 05/22/2012 05:41 PM, Lucas Sweany wrote:
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Lucas Sweany — 2012-05-22T21:41:13

I am actually seeing the attribute being stored in the database, not just
in memory. Do you think the latest ticket will address that as well?

-Lucas

On Tue, May 22, 2012 at 2:37 PM, Mark Reynolds <mareynol< at >redhat.com> wrote:

--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: Disable unhashed#user#password altogether

Mark Reynolds — 2012-05-22T21:37:02

Lucas,

A fix was just made to hide it from the audit log:

https://fedorahosted.org/389/ticket/365

The following ticket is to hide it all together, but this has not been 
fixed yet:

https://fedorahosted.org/389/ticket/378

Mark

On 05/22/2012 05:32 PM, Lucas Sweany wrote:
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Disable unhashed#user#password altogether

Lucas Sweany — 2012-05-22T21:32:14

Is there a way to prevent the unhashed#user#password attribute from being
stored or used at all? I don't need it to be replicated anywhere--I presume
that the hashed password will be enough to authenticate users.

Thanks,

-Lucas
--
389 users mailing list
389-users< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

subtree stacking/subtree virtual views

Petr Spacek — 2012-05-22T17:18:53

Hello,

I'm looking for some way how to "stack" LDAP sub-trees one on top of another.

What I mean: Let's have two subtrees:
dc=lower  and  dc=upper

dc=lower contains objects:
cn=obj1
cn=obj2,attr A = 2
cn=obj3


dc=upper contains objects:
cn=obj2,attr A = 4
cn=obj4


Now I push dc=upper on top of dc=lower (let say it creates dc=stack)
Queries with base dc=stack will return:
cn=obj1 --> same object as in dc=lower
cn=obj2 --> same object as in dc=upper, attr A = 2
cn=obj3 --> same object as in dc=lower
cn=obj4 --> same object as in dc=upper

I saw overlays "relay" and "rwm" in OpenLDAP. Is there any support in 389 for 
this use case?


I need to override several records from "lower" subtree with object from 
"upper" subtree. Problem is, that subtree "lower" can contain 10 000 objects 
and I need to override only 5 of them. I'm searching for effective way how to 
accomplish this without copying whole subtree "lower" to "upper".


Thanks for your time.

Petr^2 Spacek
--
389 users mailing list
389-users< at >lists.f