[389-users] Re: advice on 389 in production

[morgan jones]

My apologies for the delay but thank you AI and William, this is great info, I 
appreciate it.

I'm having good success building a Docker image using the 4teamwork github 
repo!  I'm presenting Monday to the team but I think it will be an easy sell as 
at least in testing it's working well:

https://github.com/4teamwork/389ds-docke

-morgan



On Thu, Jun 6, 2024, at 14:18, Ivanov Andrey (M.) wrote:
> Hi Morgan,
> 
> in our case we have ~60 000 entries,  ~10 000 accounts and ~5 000 large 
> groups (some containing  almost all users). Three 389ds in active-active 
> replication, extremely stable, performant, no problems at all. We are using 
> RHEL 9 clones (Oracle Linux or Alma Linux), latest OS patches (9.4 i think). 
> 389ds version 2.5 compiling from git branch (i think the latest one is 2.5.1, 
> maybe it is available as rpm). No complaints at all :)
> 
> Regards,
> 
> AI
> 
> 
> ----- Mail original -
> > De: "Morgan Jones" 
> > À: "General discussion list for the 389 Directory server, project." 
> > <389-users@lists.fedoraproject.org>
> > Envoyé: Mercredi 5 Juin 2024 22:25:14
> > Objet: [389-users] advice on 389 in production
> 
> > Hello Everyone,
> > 
> > What operating system and 389 version is everyone running in production?  
> > We are
> > finally updating our CentOS 7 servers in earnest.
> > 
> > We have almost 200,000 users and use 389 for our central ldap so stability 
> > is
> > preferred over features.
> > 
> > Based on release dates I'm leaning toward version 2.x.
> > 
> > I've sent the afternoon trying to find packages for Rocky Linux 9 with 
> > limited
> > success.
> > 
> > We switched to Ubuntu a few years ago so that would be my preference but I 
> > don't
> > see packages for ubuntu and I'd prefer to now maintain my own packages.
> > 
> > Is Docker a viable option for a production install?  I see there is an up to
> > date image which I've been able to start but it appears to be 3.x (see above
> > re: preferred production version).
> > 
> > Thanks,
> > 
> > -morgan
> > --
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 
--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] advice on 389 in production

[Morgan Jones]

Hello Everyone,

What operating system and 389 version is everyone running in production?  We 
are finally updating our CentOS 7 servers in earnest.

We have almost 200,000 users and use 389 for our central ldap so stability is 
preferred over features.

Based on release dates I'm leaning toward version 2.x.

I've sent the afternoon trying to find packages for Rocky Linux 9 with limited 
success.

We switched to Ubuntu a few years ago so that would be my preference but I 
don't see packages for ubuntu and I'd prefer to now maintain my own packages.

Is Docker a viable option for a production install?  I see there is an up to 
date image which I've been able to start but it appears to be 3.x (see above 
re: preferred production version).

Thanks,

-morgan
--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] 389 in Ubuntu 22.04

[morgan jones]

Hello,

We are moving to Ubuntu 22.04 across our servers: is there a recommended Ubuntu 
repo for 389 Directory?

On a related note is there an official Docker image?

We have about 250,000 users and currently have 6 replicas all running CentOS 7.

thanks,

-morgan___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: 389 scalability

[Morgan Jones]

Thanks for the info William and Thierry, this all makes sense.  

We'll start testing in the coming weeks and see how it goes.

-morgan


> On May 19, 2022, at 03:25, Thierry Bordaz  wrote:
> 
> 
> On 5/19/22 1:51 AM, William Brown wrote:
>> 
>>> On 19 May 2022, at 00:48, Morgan Jones  wrote:
>>> 
>>> Hello Everyone,
>>> 
>>> We are merging our student directory (about 200,000 entries) into our 
>>> existing employee directory (about 25,000 entries).
>>> 
>>> They're a pair of multi-master replicas on virtual hardware that can easily 
>>> be expanded if needed though hardware performance hasn't been an issue.
>>> 
>>> Does this  justify creating  separate database for students?  Aside from 
>>> basic tuning are here any big pitfalls we should look out for?
>> I think extra databases creates more administration overhead than benefit. 
>> The benefit to extra databases is "improved write performance" generally 
>> speaking. But the trade is subtree queries are more complex to eval for the 
>> server.
>> 
>> It's far easier for you the admin, and also support staff if you keep it as 
>> a single db. We have done huge amounts to improve parallel reads in recent 
>> years, so you should see large gains when you change from 1.3 to 1.4 or 2.0 
>> :)
>> 
>> 
> I fully agree with William points. Just a comment if you decide to merge the 
> students entries into the employee directory. Either you will have to ADD 
> 200K students entries into your existing directory and it will take several 
> hours. Either you will use import (e.g. merge employee/students ldifs and 
> reimport), that will require a reinit of the topology. The second option 
> would be the fastest as import + reinit of a db with 225K entries should be 
> fast.
>> 
>> 
>>> We're still on CentOS 7 for the time being:
>>> [root@prdds21 morgan]# rpm -qa|grep 389
>>> 389-admin-1.1.46-4.el7.x86_64
>>> 389-console-1.1.19-6.el7.noarch
>>> 389-dsgw-1.1.11-5.el7.x86_64
>>> 389-admin-console-1.1.12-1.el7.noarch
>>> 389-ds-1.2.2-6.el7.noarch
>>> 389-ds-base-libs-1.3.10.2-13.el7_9.x86_64
>>> 389-ds-base-1.3.10.2-13.el7_9.x86_64
>>> 389-adminutil-1.1.22-2.el7.x86_64
>>> 389-admin-console-doc-1.1.12-1.el7.noarch
>>> 389-ds-console-doc-1.2.16-1.el7.noarch
>>> 389-ds-console-1.2.16-1.el7.noarch
>>> [root@prdds21 morgan]#
>>> 
>>> thank you,
>>> 
>>> -morgan
>>> 
>>> 
>>> 
>>> ___
>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>>> Do not reply to spam on the list, report it: 
>>> https://pagure.io/fedora-infrastructure
>> --
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer,
>> Identity and Access Management
>> SUSE Labs, Australia
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
>> https://pagure.io/fedora-infrastructure
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] 389 scalability

[Morgan Jones]

Hello Everyone,

We are merging our student directory (about 200,000 entries) into our existing 
employee directory (about 25,000 entries).  

They're a pair of multi-master replicas on virtual hardware that can easily be 
expanded if needed though hardware performance hasn't been an issue.

Does this  justify creating  separate database for students?  Aside from basic 
tuning are here any big pitfalls we should look out for?

We're still on CentOS 7 for the time being:
[root@prdds21 morgan]# rpm -qa|grep 389
389-admin-1.1.46-4.el7.x86_64
389-console-1.1.19-6.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-libs-1.3.10.2-13.el7_9.x86_64
389-ds-base-1.3.10.2-13.el7_9.x86_64
389-adminutil-1.1.22-2.el7.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-console-1.2.16-1.el7.noarch
[root@prdds21 morgan]#

thank you,

-morgan



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] aci sanity check

[Morgan Jones]

Hello,

Would someone mind taking a look at the below and tell me what I am missing??  
I have a requirement to make a group readable by its members:



morgan@m1macbook ~ % ldapmodify -H ldaps://prdds22.domain.org -x -y pass.txt -f 
duo_aci_example.ldif
modifying entry "cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org"
ldap_modify: Invalid syntax (21)
additional info: ACL Syntax Error(-5):(target = 
\22cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org\22)(targetfilter = 
\22(objectclass=groupofuniquenames)\22)(version 3.0; acl \22duo access\22;allow 
(read, search, compare) groupdn = 
\22ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org\22;)


morgan@m1macbook ~ % 


duo_aci_example.ldif:
dn: cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org
changetype: modify
replace: aci
aci: (target = "cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org")
 (targetfilter = "(objectclass=groupofuniquenames)")
 (version 3.0; acl "duo access";
 allow (read, search, compare) groupdn = 
"ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org;;)


thank you!

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] search inconsistencies

[Morgan Jones]

Can anyone provide insight on why the below might be happening, my best guess 
is a corrupt uniquemember index??

I initially tried it as a user which also fails but switched to Directory 
Manager to rule out an access control issue.

We have identical prod, dev, and test environments and I only see this behavior 
in our production environment.

mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass  -D 
cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' 
'(&(objectClass=groupofuniquenames)(uniqueMember=*))'
mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass -D 
cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' 
'(uniqueMember= groupofuniquenames)'
mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass  -D 
cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' 
'(objectclass=*)'
dn: cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org
objectClass: top
objectClass: groupOfUniqueNames
cn: admin
uniqueMember: uid=u1,ou=employees,dc=domain,dc=org
uniqueMember: uid=u2,ou=employees,dc=domain,dc=org
uniqueMember: uid=u3,ou=employees,dc=domain,dc=org
description: FW Mgmt group

mmacbook:~ morgan$



mmacbook:~ morgan$ ldapsearch -x -y ~/Docs/.pass4 -D cn=directory\ manager 
-LLLb cn=config '(&(objectclass=nsindex)(cn=uniquemember))'
dn: cn=uniquemember,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,c
 n=config
objectClass: top
objectClass: nsIndex
cn: uniquemember
nsSystemIndex: false
nsIndexType: eq

dn: cn=uniquemember,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=co
 nfig
objectClass: top
objectClass: nsIndex
cn: uniquemember
nsSystemIndex: false
nsIndexType: eq

dn: cn=uniqueMember,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: uniqueMember
objectClass: top
objectClass: nsIndex
nsIndexType: eq
nsIndexType: sub
nsIndexType: pres
nsSystemIndex: false

mmacbook:~ morgan$ 


thank you!

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: 389 1.3 vs 1.4, CentOS 7

[Morgan Jones]

Thanks Thierry.  Does 389 1.3 have an end of life date?

We are a large school district and aren’t yet running Redhat 8 and may not for 
a bit—another team makes that call.

-morgan


> On Nov 10, 2021, at 4:45 AM, Thierry Bordaz  wrote:
> 
> Hi Morgan,
> 
> 389 1.3 and 1.4 are both advisable in production. You may hit some 
> dependencies difficulties building 1.4 on centos7, as 1.3 was released on 
> centos7 and 1.4 on centos8.
> 
> I would suggest that you upgrade to centos8 as 1.4 contains more features and 
> improvements but if you target centos7 then 1.3 is the version to go.
> 
> my 2cts
> 
> regards
> thierry
> 
> On 11/10/21 4:18 AM, Morgan Jones wrote:
>> Hello!
>> 
>> Is it advisable to run 389 1.3 in production?
>> 
>> If not is there a suggested way to install 1.4 in CentOS 7?  On first blush 
>> to install 389 from source  it’s looking like I’m going to need to install 
>> libicu from source, the version that ships is an older version:
>> 
>>> checking for ICU... no
>>> configure: error: Package requirements (icu-i18n >= 60.2) were not met:
>>> 
>>> Requested 'icu-i18n >= 60.2' but version of icu-i18n is 50.2
>> 
>> thank you,
>> 
>> -morgan
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
>> https://pagure.io/fedora-infrastructure
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] 389 1.3 vs 1.4, CentOS 7

[Morgan Jones]

Hello!

Is it advisable to run 389 1.3 in production?

If not is there a suggested way to install 1.4 in CentOS 7?  On first blush to 
install 389 from source  it’s looking like I’m going to need to install libicu 
from source, the version that ships is an older version:

> checking for ICU... no
> configure: error: Package requirements (icu-i18n >= 60.2) were not met:
> 
> Requested 'icu-i18n >= 60.2' but version of icu-i18n is 50.2


thank you,

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: passwordAdminDN help

[Morgan Jones]

> On Sep 28, 2021, at 6:09 PM, Mark Reynolds  wrote:
> 
> You are not, you set it up correctly.  One thing you did not list was that 
> you are supposed to add an aci that allows that group to update the 
> userpassword attribute, but that would not explain the constraint violation.  
> It could be a bug.
> 
> One quick question, are you also using a subtree/local password policy that 
> might be conflicting with the global password policy? Local policies override 
> the global policy.
> 
> Mark

Mark,

Thank you for the quick response!

I do have an aci set up and I can update passwords as 
uid=selectivesync389,ou=svc_accts,dc=domain,dc=org if I pass in a plain text 
password.   

I don’t believe we have a subtree/local policy but we did import this data from 
an ancient 389 install that we’re upgrading from.  Does this answer your 
question?  We dabbled a bit in local policies a few years ago but finally just 
set policies globally in cn=config.  That knowledge is old but my notes say 
this should return subtree/local policies:

morgan@woodrow-2 ~ % ldapsearch -LLL -H ldaps://tstds21.domain -D cn=directory\ 
manager -x -w pass '(objectclass=passwordpolicy)'  
morgan@woodrow-2 ~ % 

please correct me if my search is wrong.

thanks,

-morgan

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] passwordAdminDN help

[Morgan Jones]

May I have a sanity check here?  I am attempting to add pre-hashed passwords to 
users.  If I’ve read the documentation correctly this should work.  I’ve also 
tried putting uid=selectivesync389,ou=svc_accts,dc=domain,dc=org directly in 
passwordAdminDN:


morgan@woodrow-2 ~ % ldapsearch -H ldaps://tstds21.domain.org -x -w pass -D 
cn=directory\ manager -LLLb cn=config -s base objectclass=\*  passwordAdminDN
dn: cn=config
passwordAdminDN: cn=Passwd Admins,ou=groups,dc=domain,dc=org

morgan@woodrow-2 ~ % 


morgan@woodrow-2 ~ % ldapsearch -H ldaps://tstds21.domain.org -x -w pass -D 
cn=directory\ manager -LLLb dc=domain,dc=org cn=passwd\ admins
dn: cn=Passwd Admins,ou=groups,dc=domain,dc=org
description: password admins
objectClass: top
objectClass: groupofuniquenames
cn: Passwd Admins
uniqueMember: uid=selectivesync389,ou=svc_accts,dc=domain,dc=org

morgan@woodrow-2 ~ %


morgan@woodrow-2 ~ % ldapmodify -a  -w pass -D 
uid=selectivesync389,ou=svc_accts,dc=domain,dc=org -H ldaps://tstds21.domain.org
dn: uid=zimbratest06,ou=employees,dc=domain,dc=org
changetype: modify
replace: userpassword
userpassword: {SHA}hrJ6x38+yn2LiTm1qqkGjNXAh8I=

modifying entry "uid=zimbratest06,ou=employees,dc=domain,dc=org"
ldap_modify: Constraint violation (19)
additional info: invalid password syntax - passwords with storage 
scheme are not allowed

morgan@woodrow-2 ~ % 


We’re running 1.3.10 on CentOS 7.9:

[root@tstds21 morgan]# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)
[root@tstds21 morgan]# rpm -qa|grep 389
389-adminutil-1.1.22-2.el7.x86_64
389-ds-base-1.3.10.2-10.el7_9.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-base-libs-1.3.10.2-10.el7_9.x86_64
389-console-1.1.19-6.el7.noarch
389-ds-console-1.2.16-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-admin-console-doc-1.1.12-1.el7.noarch
389-admin-1.1.46-4.el7.x86_64
[root@tstds21 morgan]#



Am I missing something??  thank you!

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: Locating syntax violations

[Morgan Jones]

Thanks Mark, I should have been able to find that.  

Is there a downside to leaving this on all the time? 

-morgan


> On Oct 4, 2017, at 3:53 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> Hi Morgan,
> 
> On 10/04/2017 03:46 PM, Morgan Jones wrote:
>> I’m working on importing a Ldif from an older version of Redhat  and have a 
>> few dozen of the below: is there a way to increase debugging such that it 
>> tells me which attribute violates syntax? 
> Yes, set nsslapd-syntaxlogging to "on" under the cn=config entry
> 
> Regards,
> Mark
> 
> 
>> I’ve looked and can’t find anything.  We have a moderately complex custom 
>> schema and it’s tough to guess which attribute is a problem.
>> 
>> [02/Oct/2017:19:26:51.469805388 -0400] - WARN - import_producer - import 
>> userRoot: Skipping entry “uid=user1,ou=employees,dc=domain,dc=org" which 
>> violates attribute syntax, ending line 2988973 of file 
>> "/home/morgan/devldap03.ldif”
>> 
>> Thanks,
>> 
>> -morgan
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Locating syntax violations

[Morgan Jones]

I’m working on importing a Ldif from an older version of Redhat  and have a few 
dozen of the below: is there a way to increase debugging such that it tells me 
which attribute violates syntax?  I’ve looked and can’t find anything.  We have 
a moderately complex custom schema and it’s tough to guess which attribute is a 
problem.

[02/Oct/2017:19:26:51.469805388 -0400] - WARN - import_producer - import 
userRoot: Skipping entry “uid=user1,ou=employees,dc=domain,dc=org" which 
violates attribute syntax, ending line 2988973 of file 
"/home/morgan/devldap03.ldif”

Thanks,

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: dnsdomain schema missing in 389 Directory server - can not run PowerDNS LDAP backend

[Morgan Jones]

Tomas,

Can you convert the dnsdomain schema from OpenLDAP? I recognize it’s a 
potential rabbit hole as there may be schemas that depend on that that you have 
to convert and so on but it could be worth the effort rather than abandoning 
your 389 project.

-morgan


> On Sep 25, 2017, at 4:13 AM, Tomáš Brandýský <tomas.brandy...@gmail.com> 
> wrote:
> 
> Morgan,
> 
> there is no problem with converting the schema. 
> Like I wrote I managed to convert the PowerDNS schema but this schema is just 
> extending 'dnsdomain' schema which is actually part of OpenLDAP and was part 
> of 389 DS in the past. As dnsdomain schema is not part of 389 DS anymore all 
> other schemas trying to use it can't be loaded either.
> 
> This is how PowerDNS extends dnsdomain schema which doesn't exist in 389 DS:
> 
> objectClasses: (
>   1.3.6.1.4.1.2428.20.2
>   NAME 'dNSDomain2'
>   SUP 'dNSDomain'
>   STRUCTURAL
>   MAY ( DNSTTL $ DNSClass $ WKSRecord $ PTRRecord $  HINFORecord $ 
> MINFORecord $ TXTRecord $ RPRecord $  AFSDBRecord $ SIGRecord $ KEYRecord $ 
> GPOSRecord $  Record $ LOCRecord $ NXTRecord $ SRVRecord $  NAPTRRecord $ 
> KXRecord $ CERTRecord $ A6Record $  DNAMERecord $ APLRecord $ DSRecord $ 
> SSHFPRecord $  IPSECKEYRecord $ RRSIGRecord $ NSECRecord $  DNSKEYRecord $ 
> DHCIDRecord $ SPFRecord )
>   )
> 
> Tomas
> 
> 
> 
> On 24 September 2017 at 04:12, Morgan Jones <mor...@morganjones.org> wrote:
> Tomas,
> 
> It’s been a while since I’ve done it but I seem to remember it being 
> relatively straightforward to convert between OpenLDAP's and 389’s schema 
> formats.  Have you made an attempt to convert the PowerDNS schema?
> 
> -morgan
> 
> 
> > On Sep 22, 2017, at 6:13 AM, Tomáš Brandýský <tomas.brandy...@gmail.com> 
> > wrote:
> >
> > Hello,
> >
> > in our company we're working on project of migration multiple master-slave 
> > synchronized OpenLDAP servers to multi-master 389 DS servers configuration.
> >
> > We've been using OpenLDAP to store data of multiple applications such as 
> > DNS servers (PowerDNS), DHCP servers, Mail servers (Postfix, Amavis) 
> > etc..for at least 9 years.
> >
> > We need to use custom LDAP schemas to store the data of these applications 
> > in LDAP. These need to be converted from OpenLDAP format to RFC strict 389 
> > DS convenient format which actually works great for most of them.
> >
> > Unfortunately I didn't manage to use PowerDNS LDAP schema 
> > (https://doc.powerdns.com/authoritative/backends/ldap.html) with 389 DS. As 
> > I tried to google more information why this schema doesn't work with 389 DS 
> > I found out it uses 'dnsdomain' schema which comes with OpenLDAP 
> > (https://lists.fedoraproject.org/pipermail/389-users/2011-January/012721.html)
> >  and was removed from 389 DS many years ago.
> >
> > Could you please give me some advice what can I do to make PowerDNS backend 
> > work with 389 DS ?
> >
> > We're mid-sized company with many services using LDAP as their storage 
> > backend and to migrate all of them to new LDAP servers is priority number 
> > one. If there is no way to migrate PowerDNS LDAP data from OpenLDAP to 389 
> > DS the whole project of migration to 389 DS would need to be reconsidered. 
> > Nevertheless I don't understand why such a worldwide popular DNS server 
> > which PowerDNS surely is couldn't be used with 389 DS LDAP implementation 
> > which is also quite popular.
> >
> > Thank you
> >
> > Tomas Brandysky
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: dnsdomain schema missing in 389 Directory server - can not run PowerDNS LDAP backend

[Morgan Jones]

Tomas,

It’s been a while since I’ve done it but I seem to remember it being relatively 
straightforward to convert between OpenLDAP's and 389’s schema formats.  Have 
you made an attempt to convert the PowerDNS schema?

-morgan


> On Sep 22, 2017, at 6:13 AM, Tomáš Brandýský  
> wrote:
> 
> Hello,
> 
> in our company we're working on project of migration multiple master-slave 
> synchronized OpenLDAP servers to multi-master 389 DS servers configuration.
> 
> We've been using OpenLDAP to store data of multiple applications such as DNS 
> servers (PowerDNS), DHCP servers, Mail servers (Postfix, Amavis) etc..for at 
> least 9 years.
> 
> We need to use custom LDAP schemas to store the data of these applications in 
> LDAP. These need to be converted from OpenLDAP format to RFC strict 389 DS 
> convenient format which actually works great for most of them.
> 
> Unfortunately I didn't manage to use PowerDNS LDAP schema 
> (https://doc.powerdns.com/authoritative/backends/ldap.html) with 389 DS. As I 
> tried to google more information why this schema doesn't work with 389 DS I 
> found out it uses 'dnsdomain' schema which comes with OpenLDAP 
> (https://lists.fedoraproject.org/pipermail/389-users/2011-January/012721.html)
>  and was removed from 389 DS many years ago.
> 
> Could you please give me some advice what can I do to make PowerDNS backend 
> work with 389 DS ?
> 
> We're mid-sized company with many services using LDAP as their storage 
> backend and to migrate all of them to new LDAP servers is priority number 
> one. If there is no way to migrate PowerDNS LDAP data from OpenLDAP to 389 DS 
> the whole project of migration to 389 DS would need to be reconsidered. 
> Nevertheless I don't understand why such a worldwide popular DNS server which 
> PowerDNS surely is couldn't be used with 389 DS LDAP implementation which is 
> also quite popular.
> 
> Thank you
> 
> Tomas Brandysky
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Morgan Jones]

Julian,

I’m glad that resolved your issue.  It’s also nice to know I’m not the only one 
using Ansible with 389.

-morgan


> On Sep 20, 2017, at 3:37 AM, Julian Kippels <kipp...@hhu.de> wrote:
> 
> Hi Morgan,
> 
> your mail arrived one day late for me, it seems that the
> fedora mailman-server held it for some time before releasing it.
> 
> You seem to have found the solution. When I ran the setup interactively
> with --keepcache the SlapdConfigForMC option was not set at all for the
> slave. If I manually set it in the inf-file to "no" it all works as
> intended. I'm just curious as to why the --keepcache-option would
> produce an output that does not reproduce my input…
> 
> In the meantime I had it working with an except-script. If anyone for
> any reason would like to use this over a silent install I'm going to
> add my ansible template for it here:
> 
> #!/usr/bin/expect -f
> spawn setup-ds-admin.pl
> expect "continue with set up"
> send "yes\r"
> expect "Would you like to continue"
> send "yes\r"
> expect "Choose a setup type"
> send "2\r"
> expect "Computer name"
> send "\r"
> expect "System User"
> send "\r"
> expect "System Group"
> send "\r"
> expect "configuration directory server"
> {% if dirsrv_mode == "master" %}
> send "no\r"
> expect "administrator ID"
> send "\r"
> expect "Password"
> send "{{ vault_dirsrv_admin_server_password }}\r"
> expect "Password (confirm)"
> send "{{ vault_dirsrv_admin_server_password }}\r"
> expect "Administration Domain"
> send "\r"
> {% else %}
> send "yes\r"
> expect "Configuration directory server URL"
> send "ldap://{{ dirsrv_config_host }}:389/o=NetscapeRoot\r"
> expect "Configuration directory server admin ID"
> send "\r"
> expect "Configuration directory server admin password"
> send "{{ vault_dirsrv_admin_server_password }}\r"
> expect "Configuration directory server admin domain"
> send "\r"
> {% endif %}
> expect "Directory server network port"
> send "389\r"
> expect "Directory server identifier"
> send "\r"
> expect "Suffix"
> send "\r"
> expect "Directory Manager DN"
> send "\r"
> expect "Password"
> send "{{ vault_dirsrv_directory_manager_password }}\r"
> expect "Password (confirm)"
> send "{{ vault_dirsrv_directory_manager_password }}\r"
> expect "Administration port"
> send "\r"
> expect "Are you ready to set up your servers"
> send "\r"
> expect "Log file is"
> send_user "$expect_out(buffer)"
> exit 0
> 
> Julian
> 
> Am Mon, 18 Sep 2017 16:41:46 -0400
> schrieb Morgan Jones <mor...@morganjones.org>:
> 
>> Hello Julian et al,
>> 
>> I’ve resolved my unrelated issues and now I'm pretty sure the process
>> to install several servers with a common config host using inf files
>> is this.  I’d love some feedback from others if you feel this is
>> wrong, this is just from trial and error on my part and it’s not
>> particularly intuitive:
>> 
>> Do an install with setup-ds-admin.pl —keepcache
>> 
>> Take the resulting .inf and change:
>> SlapdConfigForMC = yes on the server you want to install the config
>> tree, SlapdConfigForMC = no on the rest, and
>> UseExistingMC = 0 on the server you want to install the config tree,
>> and UseExistingMC = 1 on the rest and
>> 
>> Also put adm.conf at /etc/dirsrv/admin-serv/adm.conf.
>> 
>> Here’s an update to the links below, I renamed the .inf template.
>> These should be immutable:
>> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/389_install.inf.j2
>> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/adm.conf.j2
>> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/install_389.yml
>> 
>> -morgan
>> 
>> 
>> 
>> 
>>> On Sep 15, 2017, at 12:56 PM, Morgan Jones <mor...@morganjones.org>
>>> wrote:
>>> 
>>> Hello Julia,
>>> 
>>> I’m troubleshooting this exact behavior.  So far I’ve found if you
>>> create an /etc/dirsrv/admin-serv/adm.conf before the silent install
>>> it works.

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Morgan Jones]

Julian,

Did you see my on-list response on the list  at 16:41pm eastern yesterday?  I 
didn’t see it make it to the list,  It’s quoted below.  The problem I was 
having was the first install would fail with an error connecting to the host 
that stores the config.  Setting SlapdConfigForMC and UseExistingMC 
appropriately fixed it for me.  What is SlapdConfigForMC and UseExistingMC set 
to on the server that stores that config and server(s) that don’t store?

I just got everything working cleanly with the below inf.  Can dig up a list of 
the variables I’m setting in my hosts.yml would you be willing to post a 
sanitized version of your inf so we can compare notes?

I agree expect is clunky, I’m curious to find out what your problem is as I’ve 
been living this issue for the last week or so.

-morgan



> On Sep 18, 2017, at 4:41 PM, Morgan Jones <mor...@morganjones.org> wrote:
> 
> Hello Julian et al,
> 
> I’ve resolved my unrelated issues and now I'm pretty sure the process to 
> install several servers with a common config host using inf files is this.  
> I’d love some feedback from others if you feel this is wrong, this is just 
> from trial and error on my part and it’s not particularly intuitive:
> 
> Do an install with setup-ds-admin.pl —keepcache
> 
> Take the resulting .inf and change:
> SlapdConfigForMC = yes on the server you want to install the config tree,
> SlapdConfigForMC = no on the rest, and
> UseExistingMC = 0 on the server you want to install the config tree, and
> UseExistingMC = 1 on the rest and
> 
> Also put adm.conf at /etc/dirsrv/admin-serv/adm.conf.
> 
> Here’s an update to the links below, I renamed the .inf template.  These 
> should be immutable:
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/389_install.inf.j2
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/adm.conf.j2
> https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/install_389.yml
> 
> -morgan




> On Sep 18, 2017, at 5:24 AM, Julian Kippels <kipp...@hhu.de> wrote:
> 
> Hi,
> 
> I have tested this and have found that any entries
> in /etc/dirsrv/admin-serv/adm.conf get overridden by the install
> script. I have adapted your template to work with my own ansible
> playbook and after setup-ds-admin.pl ran, the value for ldapurl has
> changed to the local hostname instead of the hostname for the config
> host. Additionaly the ConfigDirectoryLdapURL parameter from the
> inf-File seems to be ignored. Even if I set it to the correct config
> host hostname the local hostname is being used eventually.
> 
> My current plan is to ditch the silent install completely in favor of
> an expect-script that would send the input to an interactive run of
> setup-ds-admin.pl. However I think that this is a really clunky fix and
> I would really like to get it working with the silent install.
> 
> Julian
> 
> Am Fri, 15 Sep 2017 12:56:07 -0400
> schrieb Morgan Jones <mor...@morganjones.org>:
> 
>> Hello Julia,
>> 
>> I’m troubleshooting this exact behavior.  So far I’ve found if you
>> create an /etc/dirsrv/admin-serv/adm.conf before the silent install
>> it works.  However we just went through a host domain name change
>> (long story) and I’m having I think unrelated problems.  I hope to
>> resolve that shortly and then I might have a more definitive answer.
>> 
>> In the mean time this may be helpful to you:
>> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
>> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2
>> 
>> Here’s where they’re used if you are familiar with ansible:
>> https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml
>> 
>> -morgan
>> 
>> 
>>> On Sep 15, 2017, at 11:49 AM, Julian Kippels <kipp...@hhu.de> wrote:
>>> 
>>> Hi,
>>> 
>>> I was playing around with silent installs and found out that the
>>> final configuration differs from interactive installations. Here is
>>> what I did:
>>> 
>>> I installed two servers on different machines ds-1.localdomain and
>>> ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to
>>> use it as its configuration server.
>>> Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.
>>> 
>>> First I used setup-ds-admin.pl --keepcache interactively first on
>>> ds-1 and told it not to use an existing configuration server, then
>>> on ds-2 and told it to use ds-1. When I connect to ds-1 using

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Morgan Jones]

Hello Julian et al,

I’ve resolved my unrelated issues and now I'm pretty sure the process to 
install several servers with a common config host using inf files is this.  I’d 
love some feedback from others if you feel this is wrong, this is just from 
trial and error on my part and it’s not particularly intuitive:

Do an install with setup-ds-admin.pl —keepcache

Take the resulting .inf and change:
SlapdConfigForMC = yes on the server you want to install the config tree,
SlapdConfigForMC = no on the rest, and
UseExistingMC = 0 on the server you want to install the config tree, and
UseExistingMC = 1 on the rest and

Also put adm.conf at /etc/dirsrv/admin-serv/adm.conf.

Here’s an update to the links below, I renamed the .inf template.  These should 
be immutable:
https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/389_install.inf.j2
https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/templates/adm.conf.j2
https://github.com/morganllj/ansible-playbooks/blob/3bf0fa9ee5c69c10940eaa2163b6d69155767475/install_389.yml

-morgan




> On Sep 15, 2017, at 12:56 PM, Morgan Jones <mor...@morganjones.org> wrote:
> 
> Hello Julia,
> 
> I’m troubleshooting this exact behavior.  So far I’ve found if you create an 
> /etc/dirsrv/admin-serv/adm.conf before the silent install it works.  However 
> we just went through a host domain name change (long story) and I’m having I 
> think unrelated problems.  I hope to resolve that shortly and then I might 
> have a more definitive answer.
> 
> In the mean time this may be helpful to you:
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2
> 
> Here’s where they’re used if you are familiar with ansible:
> https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml
> 
> -morgan
> 
> 
>> On Sep 15, 2017, at 11:49 AM, Julian Kippels <kipp...@hhu.de> wrote:
>> 
>> Hi,
>> 
>> I was playing around with silent installs and found out that the final
>> configuration differs from interactive installations. Here is what I
>> did:
>> 
>> I installed two servers on different machines ds-1.localdomain and
>> ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to use
>> it as its configuration server.
>> Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.
>> 
>> First I used setup-ds-admin.pl --keepcache interactively first on ds-1
>> and told it not to use an existing configuration server, then on ds-2
>> and told it to use ds-1. When I connect to ds-1 using 389-console I can
>> see both ds-1 and ds-2.
>> Then I took the generated .inf-files, removed all traces from the
>> previous instances from both machines using remove-ds-admin.pl -a -f -y
>> and then ran setup-ds-admin.pl --silent --file=ds-1.inf and
>> --file=ds-2.inf respectively. When I connect to ds-1 now, I only see
>> ds-1, to see ds-2 I have to connect to ds-2 with 389-console.
>> 
>> The .inf-files look like this:
>> 
>> $ cat ds-1.inf
>> [General]
>> AdminDomain = localdomain
>> ConfigDirectoryAdminID = admin
>> ConfigDirectoryAdminPwd = XXX
>> ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
>> FullMachineName = ds-1.localdomain
>> ServerRoot = /usr/lib64/dirsrv
>> StrictHostCheck = true
>> SuiteSpotGroup = dirsrv
>> SuiteSpotUserID = dirsrv
>> [admin]
>> Port = 9830
>> ServerAdminID = admin
>> ServerAdminPwd = XXX
>> ServerIpAddress = 0.0.0.0
>> SysUser = dirsrv
>> [slapd]
>> start_server = 0
>> AddOrgEntries = Yes
>> AddSampleEntries = No
>> HashedRootDNPwd = XXX
>> InstScriptsEnabled = true
>> InstallLdifFile = suggest
>> RootDN = cn=Directory Manager
>> RootDNPwd = XXX
>> ServerIdentifier = ds-1
>> ServerPort = 389
>> SlapdConfigForMC = yes
>> Suffix = dc=localdomain
>> UseExistingMC = 0
>> bak_dir = /var/lib/dirsrv/slapd-ds-1/bak
>> bindir = /usr/bin
>> cert_dir = /etc/dirsrv/slapd-ds-1
>> config_dir = /etc/dirsrv/slapd-ds-1
>> datadir = /usr/share
>> db_dir = /var/lib/dirsrv/slapd-ds-1/db
>> ds_bename = userRoot
>> inst_dir = /usr/lib64/dirsrv/slapd-ds-1
>> ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif
>> localstatedir = /var
>> lock_dir = /var/lock/dirsrv/slapd-ds-1
>> log_dir = /var/log/dirsrv/slapd-ds-1
>> naming_value = rz
>> run_dir = /var/run/dirsrv
>> sbindir = /usr/sbin
>> schema_dir = /etc/dirsrv/slapd-ds-1/schema
>> sys

[389-users] Re: Error after setting nsslapd-allow-anonymous-access:rootdse

[Morgan Jones]

Patrick,

I have no experience using the admin console for access control or your 
particular problem but I can share what we did that I think accomplishes your 
goal as we similarly decided to block anonymous access.  To oversimplify we 
modified the stock acis with an explicit list of what users could see/do to 
themselves and defined a series of groups that could read/write to various 
attributes.  Here’s a stripped down example.  I’m happy to discuss further or 
share more details if this doesn’t make sense.

Disclaimer: we developed this years ago on a much older version of centos 
(redhat) directory but I imagine it will work in the latest 389.  We’re working 
on upgrading now.

dn: dc=domain,dc=org
changetype: modify
replace: aci
#
aci: (target = "ldap:///ou=employees,dc=domain,dc=org;)
 (targetattr = "userpassword")
 (version 3.0; acl "limited user self write";
 allow (write) userdn = "ldap:///self;;)
#
aci: (target = "ldap:///dc=domain,dc=org; )
 (targetattr = “attr1 || attr2”)
 (version 3.0; acl "self read"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self;)
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org; )
 (targetfilter = 
"(|(objectclass=objectclass1)(objectclass=objectclass2)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))")
 (targetattr = “attr1 || attr2 || attr3")
 (version 3.0; acl "general access, replaces anonymous access"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self;) or 
 (groupdn = "ldap:///cn=group1,ou=groups,dc=domain,dc=org;) or
 (groupdn = "ldap:///cn=group2,ou=groups,dc=domain,dc=org;)
;)

-morgan


> On Sep 7, 2017, at 8:55 PM, William Brown  wrote:
> 
> On Thu, 2017-09-07 at 11:28 -0500, Patrick Landry wrote:
>> OK. I guess no one has run into this one. 
>> 
>> Can anyone tell me what the impact of the admin server not being able to 
>> search the specified DIT is? 
>> Is this something to worry about or something which can be ignored? 
>> 
>> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952] 
>> populate_tasks_from_server(): Unable to search 
>> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server 
>> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636] 
>> 
> 
> I would think that you just can't edit entries in that DIT if you can't
> access it. 
> 
> TBH I would advise against using the admin server anyway, but that's
> just me.
> 
> 
>> - Original Message -
>> 
>>> From: "Patrick Landry" 
>>> To: 389-users@lists.fedoraproject.org
>>> Sent: Saturday, September 2, 2017 4:40:27 PM
>>> Subject: [389-users] Error after setting
>>> nsslapd-allow-anonymous-access:rootdse
>> 
>>> This is a fresh install on RHEL 7.
>> 
>>> 389-adminutil-1.1.21-2.el7.x86_64
>>> 389-admin-console-doc-1.1.12-1.el7.noarch
>>> 389-admin-console-1.1.12-1.el7.noarch
>>> 389-ds-base-libs-1.3.6.1-16.el7.x86_64
>>> 389-ds-console-1.2.16-1.el7.noarch
>>> 389-ds-1.2.2-6.el7.noarch
>>> 389-ds-base-1.3.6.1-16.el7.x86_64
>>> 389-ds-console-doc-1.2.16-1.el7.noarch
>>> 389-admin-1.1.46-1.el7.x86_64
>>> 389-console-1.1.18-1.el7.noarch
>>> 389-dsgw-1.1.11-5.el7.x86_64
>> 
>>> Installation went fine and I was able to secure the directory server and
>>> admin server with certificates and restrict access to secure connections
>>> only.
>> 
>>> But after I changed nsslapd-allow-anonymous-access:rootdse to prevent
>>> anonymous binds the admin server now complains at startup:
>> 
>>> [Sat Sep 02 15:53:14.402180 2017] [:crit] [pid 2640:tid 139788241741952]
>>> populate_tasks_from_server(): Unable to search
>>> [cn=admin-serv-ldap-prod1,cn=389 Administration Server,cn=Server
>>> Group,cn=SERVER,ou=DOMAIN,o=NetscapeRoot] for LDAPConnection [SERVER:636]
>> 
>>> I am still able to use the console and the error doesn't seem to affect
>>> operation.
>> 
>>> If I set nsslapd-allow-anonymous-access:on the error goes away.
>> 
>>> If I set nsslapd-allow-anonymous-access:off I get additional errors (which
>>> would be expected):
>> 
>>> [Sat Sep 02 16:18:36.559764 2017] [:error] [pid 3298:tid 139706415569024]
>>> Could not bind as []: ldap error 48: Inappropriate authentication
>>> [Sat Sep 02 16:18:36.559933 2017] [:warn] [pid 3298:tid 139706415569024]
>>> Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache.
>> 
>>> I did find an old issue in Pagure
>> 
>>> https://pagure.io/389-ds-base/issue/47850
>> 
>>> which was for a different issue related to setting
>>> nsslapd-allow-anonymous-access:rootdse
>>> In that issue Mark mentions adding a separate user entry to be used to 
>>> search
>>> o=netscaperoot
>>> but I can't find any other references to this solution (and don't know if it
>>> would solve this issue).
>> 
>>> --
>> 
>>> 
>> 
>>> Patrick Landry
>>> Director, UCSS
>>> University of Louisiana at Lafayette
>>> p...@louisiana.edu
>> 
>>> ___
>>> 389-users mailing list 

[389-users] Re: jss and idm-console-framework conflict

[Morgan Jones]

Mark,

I set up an account and gave it a +1.  If I need to do more don’t hesitate to 
ask.

Thanks for taking care of this.

-morgan



> On Sep 14, 2017, at 4:57 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> 
> 
> On 09/14/2017 04:12 PM, Morgan Jones wrote:
>> Awesome, thanks.  Apologies if this is well know 
> It was not, not for epel at least.
>> but how long is it likely to take to make it into epel?
> If you test the package and give it karma (via
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cec2fcb8ae) it
> usually happens within a week.
> 
> Mark
>> 
>> -morgan
>> 
>> 
>>> On Sep 14, 2017, at 3:36 PM, Mark Reynolds <marey...@redhat.com> wrote:
>>> 
>>> Morgan,
>>> 
>>> I just built idm-console-framework-1.1.17-4.el7  
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=21865518
>>> 
>>> Here is the bodhi link that requires "karma" to become an official
>>> update in epel7
>>> 
>>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cec2fcb8ae
>>> 
>>> Regards,
>>> Mark
>>> 
>>> On 09/14/2017 01:14 PM, Morgan Jones wrote:
>>>> Short term the solution appears to be installing idm-console-framework 
>>>> from Fedora Core:
>>>> https://www.rpmfind.net/linux/rpm2html/search.php?query=idm-console-framework
>>>> 
>>>> idm-console-framework-1.1.17-5.fc27.noarch.rpm in particular worked with 
>>>> me:
>>>> 
>>>> yum install java jss ldapjdk
>>>> rpm -Uvh idm-console-framework-1.1.17-5.fc27.noarch.rpm 
>>>> yum install 389-ds
>>>> 
>>>> -morgan
>>>> 
>>>> 
>>>>> On Sep 13, 2017, at 6:28 PM, Morgan Jones <mor...@morganjones.org> wrote:
>>>>> 
>>>>> As of just today a yum install 389-ds fails for me with 
>>>>> 
>>>>> --> Processing Conflict: jss-4.4.0-7.el7.x86_64 conflicts 
>>>>> idm-console-framework < 1.1.17-4
>>>>> --> Finished Dependency Resolution
>>>>> Error: jss conflicts with idm-console-framework-1.1.17-1.el7.noarch
>>>>> 
>>>>> It appears to be an update to jss in early August.  I’m not an expert on 
>>>>> how packages propagate but maybe it just took this long for it to get to 
>>>>> my local mirror?
>>>>> 
>>>>> This appears to be the issue, is there a work-around I’m not thinking of? 
>>>>>  It seems like this would make 389 installs from epel impossible.
>>>>> 
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1478547
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> -morgan
>>>>> ___
>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>>>> ___
>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Morgan Jones]

Julian,

Sorry on the name mix-up, typing quickly.

-morgan


> On Sep 15, 2017, at 12:56 PM, Morgan Jones <mor...@morganjones.org> wrote:
> 
> Hello Julia,
> 
> I’m troubleshooting this exact behavior.  So far I’ve found if you create an 
> /etc/dirsrv/admin-serv/adm.conf before the silent install it works.  However 
> we just went through a host domain name change (long story) and I’m having I 
> think unrelated problems.  I hope to resolve that shortly and then I might 
> have a more definitive answer.
> 
> In the mean time this may be helpful to you:
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
> https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2
> 
> Here’s where they’re used if you are familiar with ansible:
> https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml
> 
> -morgan
> 
> 
>> On Sep 15, 2017, at 11:49 AM, Julian Kippels <kipp...@hhu.de> wrote:
>> 
>> Hi,
>> 
>> I was playing around with silent installs and found out that the final
>> configuration differs from interactive installations. Here is what I
>> did:
>> 
>> I installed two servers on different machines ds-1.localdomain and
>> ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to use
>> it as its configuration server.
>> Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.
>> 
>> First I used setup-ds-admin.pl --keepcache interactively first on ds-1
>> and told it not to use an existing configuration server, then on ds-2
>> and told it to use ds-1. When I connect to ds-1 using 389-console I can
>> see both ds-1 and ds-2.
>> Then I took the generated .inf-files, removed all traces from the
>> previous instances from both machines using remove-ds-admin.pl -a -f -y
>> and then ran setup-ds-admin.pl --silent --file=ds-1.inf and
>> --file=ds-2.inf respectively. When I connect to ds-1 now, I only see
>> ds-1, to see ds-2 I have to connect to ds-2 with 389-console.
>> 
>> The .inf-files look like this:
>> 
>> $ cat ds-1.inf
>> [General]
>> AdminDomain = localdomain
>> ConfigDirectoryAdminID = admin
>> ConfigDirectoryAdminPwd = XXX
>> ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
>> FullMachineName = ds-1.localdomain
>> ServerRoot = /usr/lib64/dirsrv
>> StrictHostCheck = true
>> SuiteSpotGroup = dirsrv
>> SuiteSpotUserID = dirsrv
>> [admin]
>> Port = 9830
>> ServerAdminID = admin
>> ServerAdminPwd = XXX
>> ServerIpAddress = 0.0.0.0
>> SysUser = dirsrv
>> [slapd]
>> start_server = 0
>> AddOrgEntries = Yes
>> AddSampleEntries = No
>> HashedRootDNPwd = XXX
>> InstScriptsEnabled = true
>> InstallLdifFile = suggest
>> RootDN = cn=Directory Manager
>> RootDNPwd = XXX
>> ServerIdentifier = ds-1
>> ServerPort = 389
>> SlapdConfigForMC = yes
>> Suffix = dc=localdomain
>> UseExistingMC = 0
>> bak_dir = /var/lib/dirsrv/slapd-ds-1/bak
>> bindir = /usr/bin
>> cert_dir = /etc/dirsrv/slapd-ds-1
>> config_dir = /etc/dirsrv/slapd-ds-1
>> datadir = /usr/share
>> db_dir = /var/lib/dirsrv/slapd-ds-1/db
>> ds_bename = userRoot
>> inst_dir = /usr/lib64/dirsrv/slapd-ds-1
>> ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif
>> localstatedir = /var
>> lock_dir = /var/lock/dirsrv/slapd-ds-1
>> log_dir = /var/log/dirsrv/slapd-ds-1
>> naming_value = rz
>> run_dir = /var/run/dirsrv
>> sbindir = /usr/sbin
>> schema_dir = /etc/dirsrv/slapd-ds-1/schema
>> sysconfdir = /etc
>> tmp_dir = /tmp
>> 
>> $ cat ds-2.inf
>> [General]
>> AdminDomain = localdomain
>> ConfigDirectoryAdminID = admin
>> ConfigDirectoryAdminPwd = XXX
>> ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
>> FullMachineName = ds-2.localdomain
>> ServerRoot = /usr/lib64/dirsrv
>> StrictHostCheck = true
>> SuiteSpotGroup = dirsrv
>> SuiteSpotUserID = dirsrv
>> [admin]
>> Port = 9830
>> ServerAdminID = admin
>> ServerAdminPwd = XXX
>> ServerIpAddress = 0.0.0.0
>> SysUser = dirsrv
>> [slapd]
>> AddOrgEntries = Yes
>> AddSampleEntries = No
>> HashedRootDNPwd = XXX
>> InstScriptsEnabled = true
>> InstallLdifFile = suggest
>> RootDN = cn=Directory Manager
>> RootDNPwd = XXX
>> ServerIdentifier = ds-2
>> ServerPort = 389
>> Suffix = dc=localdomain
>> UseExistingMC = 1
>> bak_dir = /var/lib/dirsrv/slapd-ds-2/bak
>> bindir = /usr/bin
>

[389-users] Re: Possible bug? - Silent install behaves differently from interactive

[Morgan Jones]

Hello Julia,

I’m troubleshooting this exact behavior.  So far I’ve found if you create an 
/etc/dirsrv/admin-serv/adm.conf before the silent install it works.  However we 
just went through a host domain name change (long story) and I’m having I think 
unrelated problems.  I hope to resolve that shortly and then I might have a 
more definitive answer.

In the mean time this may be helpful to you:
https://github.com/morganllj/ansible-playbooks/blob/develop/templates/389_primary_master_setup.inf.j2
https://github.com/morganllj/ansible-playbooks/blob/develop/templates/adm.conf.j2

Here’s where they’re used if you are familiar with ansible:
https://github.com/morganllj/ansible-playbooks/blob/develop/install_389.yml

-morgan


> On Sep 15, 2017, at 11:49 AM, Julian Kippels  wrote:
> 
> Hi,
> 
> I was playing around with silent installs and found out that the final
> configuration differs from interactive installations. Here is what I
> did:
> 
> I installed two servers on different machines ds-1.localdomain and
> ds-2.localdomain. ds-1 is used as a master and ds-2 is supposed to use
> it as its configuration server.
> Both machines run RHEL 7.4 with the latest EPEL-builds of 389-ds.
> 
> First I used setup-ds-admin.pl --keepcache interactively first on ds-1
> and told it not to use an existing configuration server, then on ds-2
> and told it to use ds-1. When I connect to ds-1 using 389-console I can
> see both ds-1 and ds-2.
> Then I took the generated .inf-files, removed all traces from the
> previous instances from both machines using remove-ds-admin.pl -a -f -y
> and then ran setup-ds-admin.pl --silent --file=ds-1.inf and
> --file=ds-2.inf respectively. When I connect to ds-1 now, I only see
> ds-1, to see ds-2 I have to connect to ds-2 with 389-console.
> 
> The .inf-files look like this:
> 
> $ cat ds-1.inf
> [General]
> AdminDomain = localdomain
> ConfigDirectoryAdminID = admin
> ConfigDirectoryAdminPwd = XXX
> ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
> FullMachineName = ds-1.localdomain
> ServerRoot = /usr/lib64/dirsrv
> StrictHostCheck = true
> SuiteSpotGroup = dirsrv
> SuiteSpotUserID = dirsrv
> [admin]
> Port = 9830
> ServerAdminID = admin
> ServerAdminPwd = XXX
> ServerIpAddress = 0.0.0.0
> SysUser = dirsrv
> [slapd]
> start_server = 0
> AddOrgEntries = Yes
> AddSampleEntries = No
> HashedRootDNPwd = XXX
> InstScriptsEnabled = true
> InstallLdifFile = suggest
> RootDN = cn=Directory Manager
> RootDNPwd = XXX
> ServerIdentifier = ds-1
> ServerPort = 389
> SlapdConfigForMC = yes
> Suffix = dc=localdomain
> UseExistingMC = 0
> bak_dir = /var/lib/dirsrv/slapd-ds-1/bak
> bindir = /usr/bin
> cert_dir = /etc/dirsrv/slapd-ds-1
> config_dir = /etc/dirsrv/slapd-ds-1
> datadir = /usr/share
> db_dir = /var/lib/dirsrv/slapd-ds-1/db
> ds_bename = userRoot
> inst_dir = /usr/lib64/dirsrv/slapd-ds-1
> ldif_dir = /var/lib/dirsrv/slapd-ds-1/ldif
> localstatedir = /var
> lock_dir = /var/lock/dirsrv/slapd-ds-1
> log_dir = /var/log/dirsrv/slapd-ds-1
> naming_value = rz
> run_dir = /var/run/dirsrv
> sbindir = /usr/sbin
> schema_dir = /etc/dirsrv/slapd-ds-1/schema
> sysconfdir = /etc
> tmp_dir = /tmp
> 
> $ cat ds-2.inf
> [General]
> AdminDomain = localdomain
> ConfigDirectoryAdminID = admin
> ConfigDirectoryAdminPwd = XXX
> ConfigDirectoryLdapURL = ldap://ds-1.localdomain:389/o=NetscapeRoot
> FullMachineName = ds-2.localdomain
> ServerRoot = /usr/lib64/dirsrv
> StrictHostCheck = true
> SuiteSpotGroup = dirsrv
> SuiteSpotUserID = dirsrv
> [admin]
> Port = 9830
> ServerAdminID = admin
> ServerAdminPwd = XXX
> ServerIpAddress = 0.0.0.0
> SysUser = dirsrv
> [slapd]
> AddOrgEntries = Yes
> AddSampleEntries = No
> HashedRootDNPwd = XXX
> InstScriptsEnabled = true
> InstallLdifFile = suggest
> RootDN = cn=Directory Manager
> RootDNPwd = XXX
> ServerIdentifier = ds-2
> ServerPort = 389
> Suffix = dc=localdomain
> UseExistingMC = 1
> bak_dir = /var/lib/dirsrv/slapd-ds-2/bak
> bindir = /usr/bin
> cert_dir = /etc/dirsrv/slapd-ds-2
> config_dir = /etc/dirsrv/slapd-ds-2
> datadir = /usr/share
> db_dir = /var/lib/dirsrv/slapd-ds-2/db
> ds_bename = userRoot
> inst_dir = /usr/lib64/dirsrv/slapd-ds-2
> ldif_dir = /var/lib/dirsrv/slapd-ds-2/ldif
> localstatedir = /var
> lock_dir = /var/lock/dirsrv/slapd-ds-2
> log_dir = /var/log/dirsrv/slapd-ds-2
> naming_value = rz
> run_dir = /var/run/dirsrv
> sbindir = /usr/sbin
> schema_dir = /etc/dirsrv/slapd-ds-2/schema
> sysconfdir = /etc
> tmp_dir = /tmp
> 
> I think this unintended behaviour and should be fixed. Unless I did a
> mistake somewhere, but I can't see where…
> 
> Julian
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 

[389-users] Re: jss and idm-console-framework conflict

[Morgan Jones]

Awesome, thanks.  Apologies if this is well know but how long is it likely to 
take to make it into epel?

-morgan


> On Sep 14, 2017, at 3:36 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> Morgan,
> 
> I just built idm-console-framework-1.1.17-4.el7  
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21865518
> 
> Here is the bodhi link that requires "karma" to become an official
> update in epel7
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cec2fcb8ae
> 
> Regards,
> Mark
> 
> On 09/14/2017 01:14 PM, Morgan Jones wrote:
>> Short term the solution appears to be installing idm-console-framework from 
>> Fedora Core:
>> https://www.rpmfind.net/linux/rpm2html/search.php?query=idm-console-framework
>> 
>> idm-console-framework-1.1.17-5.fc27.noarch.rpm in particular worked with me:
>> 
>> yum install java jss ldapjdk
>> rpm -Uvh idm-console-framework-1.1.17-5.fc27.noarch.rpm 
>> yum install 389-ds
>> 
>> -morgan
>> 
>> 
>>> On Sep 13, 2017, at 6:28 PM, Morgan Jones <mor...@morganjones.org> wrote:
>>> 
>>> As of just today a yum install 389-ds fails for me with 
>>> 
>>> --> Processing Conflict: jss-4.4.0-7.el7.x86_64 conflicts 
>>> idm-console-framework < 1.1.17-4
>>> --> Finished Dependency Resolution
>>> Error: jss conflicts with idm-console-framework-1.1.17-1.el7.noarch
>>> 
>>> It appears to be an update to jss in early August.  I’m not an expert on 
>>> how packages propagate but maybe it just took this long for it to get to my 
>>> local mirror?
>>> 
>>> This appears to be the issue, is there a work-around I’m not thinking of?  
>>> It seems like this would make 389 installs from epel impossible.
>>> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1478547
>>> 
>>> Thanks,
>>> 
>>> -morgan
>>> ___
>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>> ___
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: jss and idm-console-framework conflict

[Morgan Jones]

Short term the solution appears to be installing idm-console-framework from 
Fedora Core:
https://www.rpmfind.net/linux/rpm2html/search.php?query=idm-console-framework

idm-console-framework-1.1.17-5.fc27.noarch.rpm in particular worked with me:

yum install java jss ldapjdk
rpm -Uvh idm-console-framework-1.1.17-5.fc27.noarch.rpm 
yum install 389-ds

-morgan


> On Sep 13, 2017, at 6:28 PM, Morgan Jones <mor...@morganjones.org> wrote:
> 
> As of just today a yum install 389-ds fails for me with 
> 
> --> Processing Conflict: jss-4.4.0-7.el7.x86_64 conflicts 
> idm-console-framework < 1.1.17-4
> --> Finished Dependency Resolution
> Error: jss conflicts with idm-console-framework-1.1.17-1.el7.noarch
> 
> It appears to be an update to jss in early August.  I’m not an expert on how 
> packages propagate but maybe it just took this long for it to get to my local 
> mirror?
> 
> This appears to be the issue, is there a work-around I’m not thinking of?  It 
> seems like this would make 389 installs from epel impossible.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1478547
> 
> Thanks,
> 
> -morgan
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] jss and idm-console-framework conflict

[Morgan Jones]

As of just today a yum install 389-ds fails for me with 

--> Processing Conflict: jss-4.4.0-7.el7.x86_64 conflicts idm-console-framework 
< 1.1.17-4
--> Finished Dependency Resolution
Error: jss conflicts with idm-console-framework-1.1.17-1.el7.noarch

It appears to be an update to jss in early August.  I’m not an expert on how 
packages propagate but maybe it just took this long for it to get to my local 
mirror?

This appears to be the issue, is there a work-around I’m not thinking of?  It 
seems like this would make 389 installs from epel impossible.

https://bugzilla.redhat.com/show_bug.cgi?id=1478547

Thanks,

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

Hello Mark et al,

This is a mea culpa—it turns out we’re running firewalld on our “new” centos 7 
systems and it was blocking port 389.  If I disable firewalld I can’t repeat 
the problem. 

Thanks for your help on this.

-morgan


> On Aug 23, 2017, at 4:24 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> 
> 
> On 08/23/2017 03:09 PM, Morgan Jones wrote:
>> Mark,
>> 
>> See attached.  The break in the log is where it hung and then came back to 
>> life.
> Odd, I don't see the connection being closed.  Looks like the client
> (the console) did not send any requests during that time, what about the
> other servers at that same time? 
> 
> 23/Aug/2017:12:56:13 <-->  23/Aug/2017:12:59:58
> 
> Also, did you try registering the servers in a different order?
> 
> Perhaps try and get a stack trace from the console during the hang using
> jstack (from Oracle java)
> 
> Thanks,
> Mark
>> 
>> I’m also going to follow up with our networking and security folks to see if 
>> we can find anything there.  These hosts are all on the same subnet for what 
>> it’s worth.
>> 
>> Thanks for the help.
>> 
>> -morgan
>> 
>> 
>>> On Aug 23, 2017, at 12:35 PM, Mark Reynolds <marey...@redhat.com> wrote:
>>> 
>>> 
>>> 
>>> On 08/23/2017 12:31 PM, Morgan Jones wrote:
>>>>> On Aug 23, 2017, at 12:17 PM, Mark Reynolds <marey...@redhat.com> wrote:
>>>>> 
>>>>> 
>>>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource 
>>>>>> temporarily unavailable)
>>>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource 
>>>>>> temporarily unavailable)
>>>>>> [pid 27442] poll([{fd=14, events=POLLRDNORM}, {fd=15, 
>>>>>> events=POLLRDNORM}], 2, 500 
>>>>>> [pid 27440] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed 
>>>>>> out)
>>>>>> [pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
>>>>> Sorry forgot to comment on this...
>>>>> 
>>>>> This explains the "hang" - connections to the remove server(s) are
>>>>> timing out.
>>>>> 
>>>>> Can you look at the DS access logs on a remote server during the hang
>>>>> (note there is a 30 sec log buffer with the access log).  Perhaps just
>>>>> tail the access log, reproduce the hang (wait 30 seconds), and provide
>>>>> the complete tail output.
>>>> Aha, ok, thanks.  Which access log do you want or do you want all of them?
>>> Just the access log from the server that triggers the initial hang.
>>>> -morgan
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

Mark,

See attached.  The break in the log is where it hung and then came back to life.

I’m also going to follow up with our networking and security folks to see if we 
can find anything there.  These hosts are all on the same subnet for what it’s 
worth.

Thanks for the help.

-morgan


> On Aug 23, 2017, at 12:35 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> 
> 
> On 08/23/2017 12:31 PM, Morgan Jones wrote:
>>> On Aug 23, 2017, at 12:17 PM, Mark Reynolds <marey...@redhat.com> wrote:
>>> 
>>> 
>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource 
>>>> temporarily unavailable)
>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource 
>>>> temporarily unavailable)
>>>> [pid 27442] poll([{fd=14, events=POLLRDNORM}, {fd=15, events=POLLRDNORM}], 
>>>> 2, 500 
>>>> [pid 27440] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed 
>>>> out)
>>>> [pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
>>> Sorry forgot to comment on this...
>>> 
>>> This explains the "hang" - connections to the remove server(s) are
>>> timing out.
>>> 
>>> Can you look at the DS access logs on a remote server during the hang
>>> (note there is a 30 sec log buffer with the access log).  Perhaps just
>>> tail the access log, reproduce the hang (wait 30 seconds), and provide
>>> the complete tail output.
>> Aha, ok, thanks.  Which access log do you want or do you want all of them?
> Just the access log from the server that triggers the initial hang.
>> 
>> -morgan
[23/Aug/2017:12:55:17.501774937 -0400] conn=17 fd=64 slot=64 connection from 
10.0.103.113 to 10.0.103.113
[23/Aug/2017:12:55:17.501928066 -0400] conn=17 op=0 BIND dn="cn=directory 
manager" method=128 version=3
[23/Aug/2017:12:55:17.502027844 -0400] conn=17 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Aug/2017:12:55:17.502270193 -0400] conn=17 op=1 UNBIND
[23/Aug/2017:12:55:17.502281347 -0400] conn=17 op=1 fd=64 closed - U1
[23/Aug/2017:12:55:17.514976137 -0400] conn=18 fd=65 slot=65 connection from 
10.0.103.113 to 10.0.103.113
[23/Aug/2017:12:55:17.523284111 -0400] conn=18 op=0 BIND dn="cn=directory 
manager" method=128 version=3
[23/Aug/2017:12:55:17.523393838 -0400] conn=18 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Aug/2017:12:55:17.527139162 -0400] conn=19 fd=64 slot=64 connection from 
10.0.103.113 to 10.0.103.113
[23/Aug/2017:12:55:17.527412491 -0400] conn=19 op=0 BIND dn="cn=directory 
manager" method=128 version=3
[23/Aug/2017:12:55:17.527481537 -0400] conn=19 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Aug/2017:12:55:17.542511884 -0400] conn=18 op=1 SRCH 
base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=domain.org,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[23/Aug/2017:12:55:17.542657820 -0400] conn=18 op=1 RESULT err=0 tag=101 
nentries=1 etime=0
[23/Aug/2017:12:55:17.548370699 -0400] conn=18 op=2 SRCH 
base="cn=group,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=domain.org,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[23/Aug/2017:12:55:17.548484545 -0400] conn=18 op=2 RESULT err=0 tag=101 
nentries=1 etime=0
[23/Aug/2017:12:55:17.549102890 -0400] conn=18 op=3 SRCH 
base="cn=OU,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=domain.org,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[23/Aug/2017:12:55:17.549188542 -0400] conn=18 op=3 RESULT err=0 tag=101 
nentries=1 etime=0
[23/Aug/2017:12:55:17.553767623 -0400] conn=18 op=4 SRCH 
base="cn=ResourceEditorExtension,ou=1.1,ou=admin,ou=Global 
Preferences,ou=domain.org,o=NetscapeRoot" scope=1 
filter="(objectClass=nsAdminResourceEditorExtension)" attrs=ALL
[23/Aug/2017:12:55:17.554119577 -0400] conn=18 op=4 RESULT err=0 tag=101 
nentries=6 etime=0
[23/Aug/2017:12:55:17.569773159 -0400] conn=18 op=5 SRCH 
base="cn=common,ou=Global Preferences,ou=domain.org,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[23/Aug/2017:12:55:17.569905377 -0400] conn=18 op=5 RESULT err=0 tag=101 
nentries=1 etime=0
[23/Aug/2017:12:55:17.570418148 -0400] conn=18 op=6 SRCH 
base="cn=common,ou=Global Preferences,ou=domain.org,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[23/Aug/2017:12:55:17.570479311 -0400] conn=18 op=6 RESULT err=

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

> On Aug 23, 2017, at 12:17 PM, Mark Reynolds  wrote:
> 
> 
>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily 
>> unavailable)
>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily 
>> unavailable)
>> [pid 27442] poll([{fd=14, events=POLLRDNORM}, {fd=15, events=POLLRDNORM}], 
>> 2, 500 
>> [pid 27440] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed out)
>> [pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
> Sorry forgot to comment on this...
> 
> This explains the "hang" - connections to the remove server(s) are
> timing out.
> 
> Can you look at the DS access logs on a remote server during the hang
> (note there is a 30 sec log buffer with the access log).  Perhaps just
> tail the access log, reproduce the hang (wait 30 seconds), and provide
> the complete tail output.

Aha, ok, thanks.  Which access log do you want or do you want all of them?

-morgan

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

> On Aug 23, 2017, at 11:32 AM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> 
> 
> On 08/23/2017 11:18 AM, Morgan Jones wrote:
>> 
>> I’m registering remote servers.  We have a total of 5.  It starts to hang 
>> after installing the 4th.
> Do you see a drop off in performance as you get close to the 4th?  Or
> everything is fine, then you add more server and its grinds to halt?

Everything seems fine with <=3.  Once I add the 4th it hangs after 3-10 clicks 
in the interface (expanding/closing items, selecting items).

> If you register the servers in a different order, is it still the 4th
> that causes issues?  Or is it one particular server?

Good question, I’m not sure--I’ll switch up the order and report back shortly.  
These are brand new CentOS 7 systems so in theory have no cruft.

Thanks,

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

I should add a few things:

I tried installing Java from Oracle, there are reports of problems with the 
openjdk.

Periodically the console does seem to return if I let it sit a few minutes.  
This is not consistent.

I tried an strace -f on the process.  I don’t see anything particularly 
interesting though it’s not completely hung, the below repeats more or less 
over and over:

[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
368271265}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
418417522}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
468582369}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
518770094}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
568927454}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
619067470},  
[pid 27466] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed out)
[pid 27466] futex(0x256b528, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27466] futex(0x256b554, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276467, 
583608758},  
[pid 27440] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
669235628}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
719425518}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
769587606}, ) = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27440] futex(0x7f38940cfd54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276466, 
819765324},  
[pid 27457] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed out)
[pid 27457] futex(0x7f389447ce28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 27457] futex(0x7f389447ce54, FUTEX_WAIT_BITSET_PRIVATE, 1, {1276467, 
792643143},  
[pid 27442] <... poll resumed> )= 0 (Timeout)
[pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 27442] poll([{fd=14, events=POLLRDNORM}, {fd=15, events=POLLRDNORM}], 2, 
500 
[pid 27440] <... futex resumed> )   = -1 ETIMEDOUT (Connection timed out)
[pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0

-morgan




> On Aug 23, 2017, at 11:18 AM, Morgan Jones <mor...@morganjones.org> wrote:
> 
> 
>> On Aug 22, 2017, at 2:15 PM, Mark Reynolds <marey...@redhat.com> wrote:
>> 
>> 
>> 
>> On 08/22/2017 01:36 PM, Morgan Jones wrote:
>>> Thanks—is there a trick to turning on admin-serv logging?  I don’t have one 
>>> and at least on first blush don’t see a means of enabling it.
>> The Admin Server (389-admin/389-adminutil) logs by default.  Are you
>> saying there is no /var/log/dirsrv/admin-serv/ directory?  Or that the
>> directory is empty
> 
> Oh, sorry, I do have an access and error log in /var/log/dirsrv/admin-serv.  
> The logs are sparse between startup and hang:
> ==> error <==
> [Wed Aug 23 11:15:13.941399 2017] [:notice] [pid 15780:tid 139865400174336] 
> [client 127.0.0.1:43150] admserv_check_authz(): passing 
> [/admin-serv/authenticate] to the userauth handler
> 
> ==> access <==
> 127.0.0.1 - cn=directory manager [23/Aug/2017:11:15:13 -0400] "GET 
> /admin-serv/authenticate HTTP/1.0" 200 329
> 
>> 
>> Also, just to clarify, you are doing all of this on same system
>> correct?  And when you create 4 server instances the console starts to
>> hang?  Or have you registered 4 remote servers instead of creating local
>> instances?
> 
> I’m registering remote servers.  We have a total of 5.  It starts to hang 
> after installing the 4th.
> 
> -morgan
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

> On Aug 22, 2017, at 2:15 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> 
> 
> On 08/22/2017 01:36 PM, Morgan Jones wrote:
>> Thanks—is there a trick to turning on admin-serv logging?  I don’t have one 
>> and at least on first blush don’t see a means of enabling it.
> The Admin Server (389-admin/389-adminutil) logs by default.  Are you
> saying there is no /var/log/dirsrv/admin-serv/ directory?  Or that the
> directory is empty

Oh, sorry, I do have an access and error log in /var/log/dirsrv/admin-serv.  
The logs are sparse between startup and hang:
==> error <==
[Wed Aug 23 11:15:13.941399 2017] [:notice] [pid 15780:tid 139865400174336] 
[client 127.0.0.1:43150] admserv_check_authz(): passing 
[/admin-serv/authenticate] to the userauth handler

==> access <==
127.0.0.1 - cn=directory manager [23/Aug/2017:11:15:13 -0400] "GET 
/admin-serv/authenticate HTTP/1.0" 200 329

> 
> Also, just to clarify, you are doing all of this on same system
> correct?  And when you create 4 server instances the console starts to
> hang?  Or have you registered 4 remote servers instead of creating local
> instances?

I’m registering remote servers.  We have a total of 5.  It starts to hang after 
installing the 4th.

-morgan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

Thanks—is there a trick to turning on admin-serv logging?  I don’t have one and 
at least on first blush don’t see a means of enabling it.

-morgan


> On Aug 17, 2017, at 3:16 PM, Mark Reynolds <marey...@redhat.com> wrote:
> 
> Sorry these logs look "normal", that message that keeps repeating is expected 
> when the console is idle (it's waiting for you to do something).
> 
> Perhaps there is something in the admin logs:
> 
> /var/log/dirsrv/admin-serv
> 
> Regards,
> Mark
> 
> On 08/16/2017 03:39 PM, Morgan Jones wrote:
>> Hello Mark,
>> 
>> See attached, "AbstractServerObject.StatusThread: waiting for change 
>> listeners to register” repeats presumably forever after it hangs.
>> 
>> Thanks,
>> 
>> -morgan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Aug 16, 2017, at 3:23 PM, Mark Reynolds <marey...@redhat.com>
>>>  wrote:
>>> 
>>> Hi Morgan,
>>> 
>>> We need more info.  Try running the console in debug mode:
>>> 
>>> 389-console -D 9
>>> 
>>> Also look at the configuration DS access log
>>> 
>>> Mark
>>> 
>>> On 08/16/2017 02:57 PM, Morgan Jones wrote:
>>> 
>>>> I’m in the process of installing 389 in CentOS 7 from epel (versions 
>>>> below) and find that the console becomes unresponsive after I install the 
>>>> 4th server.  I can open the console and expand a few servers but within 30 
>>>> seconds it consistently hangs.  I am storing configuration data in one 
>>>> server.
>>>> 
>>>> Has anyone else seen this or do you have any insight?
>>>> 
>>>> Thanks,
>>>> 
>>>> -morgan
>>>> 
>>>> 
>>>> 
>>>> [morgan@devldap03 ~]$ rpm -qa|grep 389
>>>> pcp-pmda-ds389log-3.11.3-4.el7.x86_64
>>>> 389-admin-console-1.1.12-1.el7.noarch
>>>> 389-dsgw-1.1.11-5.el7.x86_64
>>>> 389-adminutil-1.1.21-2.el7.x86_64
>>>> 389-admin-1.1.46-1.el7.x86_64
>>>> 389-ds-console-doc-1.2.16-1.el7.noarch
>>>> 389-ds-1.2.2-6.el7.noarch
>>>> 389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
>>>> 389-ds-base-1.3.5.10-21.el7_3.x86_64
>>>> 389-admin-console-doc-1.1.12-1.el7.noarch
>>>> 389-console-1.1.18-1.el7.noarch
>>>> pcp-pmda-ds389-3.11.3-4.el7.x86_64
>>>> 389-ds-console-1.2.16-1.el7.noarch
>>>> [morgan@devldap03 ~]$
>>>> ___
>>>> 389-users mailing list -- 
>>>> 
>>>> 389-users@lists.fedoraproject.org
>>>> 
>>>> 
>>>> To unsubscribe send an email to 
>>>> 
>>>> 389-users-le...@lists.fedoraproject.org
> 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Console hang after 4th server install

[Morgan Jones]

Hello Mark,

See attached, "AbstractServerObject.StatusThread: waiting for change listeners 
to register” repeats presumably forever after it hangs.

Thanks,

-morgan



java.util.prefs.userRoot=/home1/morgan/.389-console
java.runtime.name=OpenJDK Runtime Environment
sun.boot.library.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/amd64
java.vm.version=25.141-b16
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
path.separator=:
java.vm.name=OpenJDK 64-Bit Server VM
file.encoding.pkg=sun.io
user.country=US
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=unknown
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/home1/morgan
java.runtime.version=1.8.0_141-b16
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
java.endorsed.dirs=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/endorsed
os.arch=amd64
java.io.tmpdir=/tmp
line.separator=

java.vm.specification.vendor=Oracle Corporation
os.name=Linux
sun.jnu.encoding=UTF-8
java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
java.specification.name=Java Platform API Specification
java.class.version=52.0
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
os.version=3.10.0-514.26.2.el7.x86_64
user.home=/home1/morgan
user.timezone=America/New_York
java.awt.printerjob=sun.print.PSPrinterJob
file.encoding=UTF-8
java.specification.version=1.8
java.class.path=/usr/lib/java/jss4.jar:/usr/share/java/ldapjdk.jar:/usr/share/java/idm-console-base.jar:/usr/share/java/idm-console-mcc.jar:/usr/share/java/idm-console-mcc_en.jar:/usr/share/java/idm-console-nmclf.jar:/usr/share/java/idm-console-nmclf_en.jar:/usr/share/java/389-console_en.jar
user.name=morgan
java.vm.specification.version=1.8
sun.java.command=com.netscape.management.client.console.Console -D 9
java.home=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre
sun.arch.data.model=64
java.util.prefs.systemRoot=/home1/morgan/.389-console
user.language=en
java.specification.vendor=Oracle Corporation
awt.toolkit=sun.awt.X11.XToolkit
java.vm.info=mixed mode
java.version=1.8.0_141
java.ext.dirs=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/ext:/usr/java/packages/lib/ext
sun.boot.class.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.el7_3.x86_64/jre/classes
java.vendor=Oracle Corporation
file.separator=/
java.vendor.url.bug=http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding=UnicodeLittle
sun.cpu.endian=little
sun.cpu.isalist=
389-Management-Console/1.1.17 B2016.291.2035
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/nmclf/icons/Error.gif
RemoteImage: Create RemoteImage cache for loader1975012498
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/nmclf/icons/Inform.gif
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/nmclf/icons/Warn.gif
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/nmclf/icons/Question.gif
ResourceSet: NOT found in cache 
loader1975012498:com.netscape.management.client.components.components
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/client/theme/images/logo16.gif
RemoteImage: NOT found in cache 
loader1975012498:com/netscape/management/client/theme/images/login.gif
ResourceSet: NOT found in cache 
loader1975012498:com.netscape.management.client.util.default
ResourceSet: found in cache 
loader1975012498:com.netscape.management.client.util.default
JButtonFactory: button width = 54
JButtonFactory: button height = 19
JButtonFactory: button width = 54
JButtonFactory: button height = 19
JButtonFactory: button width = 90
JButtonFactory: button height = 19
JButtonFactory: button width = 90
JButtonFactory: button height = 19
JButtonFactory: button width = 72
JButtonFactory: button height = 19
JButtonFactory: button width = 72
JButtonFactory: button height = 19
JButtonFactory: button width = 54
JButtonFactory: button height = 19
JButtonFactory: button width = 90
JButtonFactory: button width = 72
CommManager> New CommRecord (http://localhost:9830/admin-serv/authenticate)
ResourceSet: found in cache 
loader1975012498:com.netscape.management.client.theme.theme
http://localhost:9830/[0:0] open> Ready
http://localhost:9830/[0:0] accept> 
http://localhost:9830/admin-serv/authenticate
http://localhost:9830/[0:0] send> GET  \
http://localhost:9830/[0:0] send> 

[389-users] Console hang after 4th server install

[Morgan Jones]

I’m in the process of installing 389 in CentOS 7 from epel (versions below) and 
find that the console becomes unresponsive after I install the 4th server.  I 
can open the console and expand a few servers but within 30 seconds it 
consistently hangs.  I am storing configuration data in one server.

Has anyone else seen this or do you have any insight?

Thanks,

-morgan



[morgan@devldap03 ~]$ rpm -qa|grep 389
pcp-pmda-ds389log-3.11.3-4.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
389-adminutil-1.1.21-2.el7.x86_64
389-admin-1.1.46-1.el7.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
389-ds-base-1.3.5.10-21.el7_3.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-console-1.1.18-1.el7.noarch
pcp-pmda-ds389-3.11.3-4.el7.x86_64
389-ds-console-1.2.16-1.el7.noarch
[morgan@devldap03 ~]$
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: subtree password policy woes

[Morgan Jones]

William,

nsslapd-pwpolicy-local was indeed not set however setting it doesn’t make a 
difference.  See below for details.

Thanks for the help with this.

thanks,

-morgan









larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D 
cn=directory\ manager -b cn=config -s base objectclass=\* nsslapd-pwpolicy-local
dn: cn=config
nsslapd-pwpolicy-local: off

larry:~ morgan$ ldapmodify  -x -w pass -H ldap://devldapm03.domain.net -D 
cn=directory\ manager
dn: uid=morgan,ou=employees,dc=domain,dc=org
changetype: modify
replace: userpassword
userpassword: 123

modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"

larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D 
cn=directory\ manager -b cn=config -s base objectclass=\* nsslapd-pwpolicy-local
dn: cn=config
nsslapd-pwpolicy-local: off

larry:~ morgan$ ldapmodify  -x -w pass -H ldap://devldapm03.domain.net -D 
cn=directory\ manager
dn: cn=config 
changetype: modify
replace: nsslapd-pwpolicy-local
nsslapd-pwpolicy-local: on

modifying entry "cn=config"

dn: uid=morgan,ou=employees,dc=domain,dc=org
changetype: modify
replace: userpassword
userpassword: 1234

modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"

larry:~ morgan$ ldapsearch -LLL -x -w pass -H ldap://devldapm03.domain.net -D 
cn=directory\ manager -b cn=config -s base objectclass=\* nsslapd-pwpolicy-local
dn: cn=config
nsslapd-pwpolicy-local: on

larry:~ morgan$




> On May 29, 2016, at 23:04, William Brown <wibr...@redhat.com> wrote:
> 
> On Mon, 2016-05-23 at 11:52 -0400, Morgan Jones wrote:
>> Hello William,
>> 
>> Is this what you’re looking for?  I’ve included the full entry below but it 
>> appears pwdPolicySubentry is operational.
>> 
> 
> 
> Hi,
> 
> Sorry to have taken so long.
> 
> Can you check:
> 
> cn=config
> nsslapd-pwpolicy-local: on
> 
> Without that setting, the fine grained password policy won't work,
> 
> Thanks,
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Brisbane
> 
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: subtree password policy woes

[Morgan Jones]

Hello William,

Is this what you’re looking for?  I’ve included the full entry below but it 
appears pwdPolicySubentry is operational.

[morgan@devldapm03 ~]$ ldapsearch -h localhost -D cn=directory\ manager -w pass 
-LLLb uid=morgan,ou=employees,dc=domain,dc=org pwdPolicySubentry
dn: uid=morgan,ou=employees,dc=domain,dc=org
pwdPolicySubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3Demployees\2Cdc\3Ddomain\2Cd
 c\3Dorg,cn=nsPwPolicyContainer,ou=employees,dc=domain,dc=org


dn: uid=morgan,ou=employees,dc=domain,dc=org
orgHomeOrg: TECHNOLOGY SERVICES
orgSponsorHomeOrg: TECHNICAL OPERATIONS
orgSponsorHomeOrgCD: x
orgAcceptedTermsofUse: FALSE
orgSponsorEIDN: x
orgGAFEOverrideOrgUnit: /STAFF/x/x
sambaSID: x
mail: mor...@domain.org
orgAccountActive: TRUE
homeDirectory: /home/morgan
gecos: Morgan Jones
loginShell: /bin/bash
uidNumber: x
gidNumber: x
orgEIDN: x
orgHomeOrgCD: x
givenName: Morgan
sn: Jones
cn: Morgan Jones
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: orgAssociate
objectClass: orgZimbraPerson
objectClass: shadowAccount
objectClass: inetUser
objectClass: ntUser
objectClass: sambaSamAccount
uid: morgan
ntUserDomainId: morgan
ntUserDeleteAccount: TRUE
ntUserCreateNewAccount: TRUE
orgAccountStatus: Active
sambaNTPassword: pass
orgDateAccountLastUpdated: 201407021744Z
userPassword: pass


thanks,

-morgan


> On May 22, 2016, at 19:10, William Brown <wibr...@redhat.com> wrote:
> 
> On Fri, 2016-05-20 at 18:30 -0400, Morgan Jones wrote:
>> uid=morgan,ou=employees,dc=domain,dc=org
> 
> I need to see the entry at this dn too, and looking for the attribute 
> pwdPolicySubentry thanks. 
> 
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Brisbane
> 
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: subtree password policy woes

[Morgan Jones]

> On May 19, 2016, at 19:04, William Brown  wrote:
> 
> It would be good to get a look at the object that is affected here. Can you 
> show me: pwdpolicysubentry from the affected user
> entry? 
> 
> Then can you also show the contents of the dn listed by that 
> pwdpolicysubentry?
> 
> 
> Is there anything in your error logs that looks suspicious? 



William,

I believe this is what you’re looking for:

dn: cn=cn\3DnsPwPolicyEntry\2Cou\3Demployees\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsPw
 PolicyContainer,ou=employees,dc=domain,dc=org
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
cn: cn=nsPwPolicyEntry,ou=employees,dc=domain,dc=org
passwordMustChange: off
passwordExp: off
passwordMinAge: 0
passwordChange: off
passwordCheckSyntax: on
passwordStorageScheme: ssha
passwordMaxRepeats: 0
passwordMinLength: 8
passwordMinAlphas: 0
passwordMinDigits: 0
passwordMinSpecials: 0
passwordMinLowers: 0
passwordMinCategories: 2
passwordMinUppers: 0
passwordMinTokenLength: 2
passwordMin8bit: 0



Here are some examples of setting passwords to shorter than 8 characters with 
corresponding logs.  There is nothing (new) in errors:


[root@devldapm03 slapd-devldapm03]# ldapmodify -h localhost -D cn=directory\ 
manager -w pass
dn: uid=morgan,ou=employees,dc=domain,dc=org
changetype: modify 
replace: userpassword
userpassword: 12345

modifying entry “uid=morgan,ou=employees,dc=domain,dc=org"

[root@devldapm03 slapd-devldapm03]#


[20/May/2016:18:16:42 -0400] conn=16 fd=68 slot=68 connection from 127.0.0.1 to 
127.0.0.1
[20/May/2016:18:16:42 -0400] conn=16 op=0 BIND dn="cn=directory manager" 
method=128 version=3
[20/May/2016:18:16:42 -0400] conn=16 op=0 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"
[20/May/2016:18:17:05 -0400] conn=16 op=1 MOD 
dn="uid=morgan,ou=employees,dc=domain,dc=org"
[20/May/2016:18:17:05 -0400] conn=16 op=1 RESULT err=0 tag=103 nentries=0 
etime=0domain





[root@devldapm03 slapd-devldapm03]# ldapmodify -h localhost -D 
uid=morgan,ou=employees,dc=domain,dc=org -w pass
dn: uid=morgan,ou=employees,dc=domain,dc=org
changetype: modify
replace: userpassword
userpassword: 123

modifying entry "uid=morgan,ou=employees,dc=domain,dc=org"
[root@devldapm03 slapd-devldapm03]#


[20/May/2016:18:26:29 -0400] conn=29 fd=68 slot=68 connection from 127.0.0.1 to 
127.0.0.1
[20/May/2016:18:26:29 -0400] conn=29 op=0 BIND 
dn="uid=morgan,ou=employees,dc=domain,dc=org" method=128 version=3
[20/May/2016:18:26:29 -0400] conn=29 op=0 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=morgan,ou=employees,dc=domain,dc=org"
[20/May/2016:18:26:51 -0400] conn=29 op=1 MOD 
dn="uid=morgan,ou=employees,dc=domain,dc=org"
[20/May/2016:18:26:51 -0400] conn=29 op=1 RESULT err=0 tag=103 nentries=0 
etime=0


thanks,

-morgan




--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: subtree password policy woes

[Morgan Jones]

I am following up in hopes that maybe this was just missed the first time 
around.  Is anyone using a subtree password policy in a recent version of 389 
and does it work?

thanks,

-morgan


> On May 11, 2016, at 16:51, Morgan Jones <mor...@morganjones.org> wrote:
> 
> 
> Hello,
> 
> We are configuring password policy in 389 directory.  We’re running what I 
> believe is the latest stable version form the Epel repository on CentOS 6:
> 
> [root@devldapm03 ~]# rpm -qa|grep 389
> 389-admin-1.1.35-1.el6.x86_64
> 389-console-1.1.7-1.el6.noarch
> 389-ds-console-doc-1.2.6-1.el6.noarch
> 389-ds-base-libs-1.2.11.15-72.el6_7.x86_64
> 389-admin-console-doc-1.1.8-1.el6.noarch
> 389-ds-base-1.2.11.15-72.el6_7.x86_64
> 389-adminutil-1.1.19-1.el6.x86_64
> 389-ds-1.2.2-1.el6.noarch
> 389-admin-console-1.1.8-1.el6.noarch
> 389-ds-console-1.2.6-1.el6.noarch
> 389-dsgw-1.1.11-1.el6.x86_64
> [morgan@devldapm03 ~]$ uname -a
> Linux devldapm03.philasd.net 2.6.32-573.26.1.el6.x86_64 #1 SMP Wed May 4 
> 00:57:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> [morgan@devldapm03 ~]$ cat /etc/redhat-release 
> CentOS release 6.7 (Final)
> [morgan@devldapm03 ~]$
> 
> I just did a yum update, rebooted and installed 389 anew.
> 
> The password policy works well if configured globally (from the Data node 
> under Configuration)
> However when I attempt to create a subtree level policy 
> (Directory->domain->employees, right click Manage Password Policy->for 
> subtree) under ou=employees,dc=domain,dc=org the effect is as if there is no 
> policy.  If I subsequently disable the subtree policy I cannot get the global 
> policy to take over.  In fact the only way I’ve been able to get the global 
> policy to work is to re-install from scratch.
> 
> I also tried command line configuration and was unable to get the policy 
> working at all though I have more confidence of my understanding of the 
> process via the console.
> 
> We’ve tried different policy settings but for testing purposes I’m just 
> setting a minimum password length of 8 characters.
> 
> Is there something I’m missing?
> 
> thanks,
> 
> -morgan
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] subtree password policy woes

[Morgan Jones]

Hello,

We are configuring password policy in 389 directory.  We’re running what I 
believe is the latest stable version form the Epel repository on CentOS 6:

[root@devldapm03 ~]# rpm -qa|grep 389
389-admin-1.1.35-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-libs-1.2.11.15-72.el6_7.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-base-1.2.11.15-72.el6_7.x86_64
389-adminutil-1.1.19-1.el6.x86_64
389-ds-1.2.2-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
[morgan@devldapm03 ~]$ uname -a
Linux devldapm03.philasd.net 2.6.32-573.26.1.el6.x86_64 #1 SMP Wed May 4 
00:57:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[morgan@devldapm03 ~]$ cat /etc/redhat-release 
CentOS release 6.7 (Final)
[morgan@devldapm03 ~]$

I just did a yum update, rebooted and installed 389 anew.

The password policy works well if configured globally (from the Data node under 
Configuration)
However when I attempt to create a subtree level policy 
(Directory->domain->employees, right click Manage Password Policy->for subtree) 
under ou=employees,dc=domain,dc=org the effect is as if there is no policy.  If 
I subsequently disable the subtree policy I cannot get the global policy to 
take over.  In fact the only way I’ve been able to get the global policy to 
work is to re-install from scratch.

I also tried command line configuration and was unable to get the policy 
working at all though I have more confidence of my understanding of the process 
via the console.

We’ve tried different policy settings but for testing purposes I’m just setting 
a minimum password length of 8 characters.

Is there something I’m missing?

thanks,

-morgan
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: [389-users] db2ldif vs ldapmodify: turn up debugging of db2ldif?

[Morgan Jones]

On May 19, 2014, at 4:48 PM, Noriko Hosoi nho...@redhat.com wrote:

 Could you send out an entry placed at ending line 5457262 of file 
 /var/tmp/students_fixed.ldif to the list?

Probably.  It’s k-1student data so always a sensitive topic.  I’ll work on 
getting approval.  

Our student records are ~70 or so attributes, many of them custom so I wouldn’t 
expect the list to troubleshoot problems with our schema/data.  I was able to 
resolve several violates attribute syntax” errors but adding the entries with 
ldapmodify which showed where the problem was—so far either empty attributes or 
data that doesn’t match the RFC.

I can, of course, work through it attribute by attribute but I’m surprised have 
to do that when usually the server logs the problem verbosely.

thanks,

-morgan


 
 
 Morgan Jones wrote:
 I am working on a move from CentOS Directory (8.2.8) on CentOS 5 to 389-ds 
 1.2.11 on CentOS 6.  I’m using a combination of the CentOS repositories and 
 epel as suggested here.
 
 I'm finding ldif2db rejects entries while if I add them via ldapmodify they 
 go in with no errors.  This is a problem as db2ldif does not give sufficient 
 debugging to identify the problem.  Below are examples.  Is there a way to 
 get more debugging out of ldif2db that I am missing?  Perhaps an error log 
 level I’m missing?  Has anyone else seen this behavior?
 
 I'm importing into a database other than userRoot if that makes a difference.
 
 thanks,
 
 -morgan
 
 
 
 [root@devldapm03 ~]# /usr/lib64/dirsrv/slapd-devldapm03/ldif2db  -n 
 studentRoot -i /var/tmp/students_fixed.ldif
 importing data ...
 [19/May/2014:15:53:48 -0400] - WARNING: Import is running with 
 nsslapd-db-private-import-mem on; No other process is allowed to access the 
 database
 [19/May/2014:15:53:48 -0400] - check_and_set_import_cache: pagesize: 4096, 
 pages: 2015405, procpages: 52243
 [19/May/2014:15:53:48 -0400] - Import allocates 3224648KB import cache.
 [19/May/2014:15:53:49 -0400] - import studentRoot: Beginning import job...
 [19/May/2014:15:53:49 -0400] - import studentRoot: Index buffering enabled 
 with bucket size 100
 [19/May/2014:15:53:49 -0400] - import studentRoot: Processing file 
 /var/tmp/students_fixed.ldif
 ...
 [19/May/2014:15:55:04 -0400] - import studentRoot: WARNING: skipping entry 
 uid=,ou=students,dc=domain,dc=org which violates attribute syntax, 
 ending line 5457262 of file /var/tmp/students_fixed.ldif
 ...
 #
 
 
 
 
 # ldapmodify -x -a -h devldapm03.domain.net -D cn=directory\ manager -w pass
 paste entry
 
 adding new entry uid=,ou=students,dc=domain,dc=org
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] db2ldif vs ldapmodify: turn up debugging of db2ldif?

[Morgan Jones]

On May 19, 2014, at 5:57 PM, Lulzim KELMENI lkelm...@mairie-saint-ouen.fr 
wrote:

 Hello,
 
 I may be wrong but i think there is a syntax problem in your ldif at line 
 5457262.

Yes, and 2000+ other lines.  Our entries are ~70 attributes a piece so I’ll 
need to work through each line one by one to find the problem which may be what 
I’m left with.

 
 8.2 instance is not complaining because syntax check is disable by default as 
 you can see here 
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Installation_Guide/upgrade.html#New-Machine
   (step 15)
 
 You can force the new instance (1.2.11.x) to accept your ldif by modifying 
 the nssldap-syntaxcheck value to off in your 
 /etc/dirsrv/slapd-devldapm03/dse.ldif (with this instance off) before using 
 the db2ldif command BUT i would strongly not recommend you to do this.
 
 The better approach is to correct your ldif before importing with db2ldif

I presume you mean ldif2db but, yes, agreed.

thanks,

-morgan

 
 This can help you to find syntax problem in you 8.2 existing instance 
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/syntax-validation.html#syntax-validation-script
 
 I dont know why the ldapmodify command succeded, maybe someone can answer 
 this.
 
  
 KELMENI Lulzim
 
 
 
 Le 19/05/2014 22:38, Morgan Jones a écrit :
 I am working on a move from CentOS Directory (8.2.8) on CentOS 5 to 389-ds 
 1.2.11 on CentOS 6.  I’m using a combination of the CentOS repositories and 
 epel as suggested here.  
 
 I'm finding ldif2db rejects entries while if I add them via ldapmodify they 
 go in with no errors.  This is a problem as db2ldif does not give sufficient 
 debugging to identify the problem.  Below are examples.  Is there a way to 
 get more debugging out of ldif2db that I am missing?  Perhaps an error log 
 level I’m missing?  Has anyone else seen this behavior?
 
 I'm importing into a database other than userRoot if that makes a difference.
 
 thanks,
 
 -morgan
 
 
 
 [root@devldapm03 ~]# /usr/lib64/dirsrv/slapd-devldapm03/ldif2db  -n 
 studentRoot -i /var/tmp/students_fixed.ldif
 importing data ...
 [19/May/2014:15:53:48 -0400] - WARNING: Import is running with 
 nsslapd-db-private-import-mem on; No other process is allowed to access the 
 database
 [19/May/2014:15:53:48 -0400] - check_and_set_import_cache: pagesize: 4096, 
 pages: 2015405, procpages: 52243
 [19/May/2014:15:53:48 -0400] - Import allocates 3224648KB import cache.
 [19/May/2014:15:53:49 -0400] - import studentRoot: Beginning import job...
 [19/May/2014:15:53:49 -0400] - import studentRoot: Index buffering enabled 
 with bucket size 100
 [19/May/2014:15:53:49 -0400] - import studentRoot: Processing file 
 /var/tmp/students_fixed.ldif
 ...
 [19/May/2014:15:55:04 -0400] - import studentRoot: WARNING: skipping entry 
 uid=,ou=students,dc=domain,dc=org which violates attribute syntax, 
 ending line 5457262 of file /var/tmp/students_fixed.ldif
 ...
 #
 
 
 
 
 # ldapmodify -x -a -h devldapm03.domain.net -D cn=directory\ manager -w pass
 paste entry
 
 adding new entry uid=,ou=students,dc=domain,dc=org
 --
 389 users mailing list
 
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Yum Update vs Yum Upgrade

[Morgan Jones]

The yum man page explains it: basically upgrade removes obsoleted packages.  I 
don’t know that it will affect the 389 packages but it’s always a good idea to 
use upgrade with caution.

-morgan


On May 20, 2014, at 1:00 PM, Rich Megginson rmegg...@redhat.com wrote:

 On 05/20/2014 10:58 AM, Fong, Trevor wrote:
 Hi Everyone,
  
 After taking over the LDAP service from a colleague, I updated the 389 DS 
 service to the latest release by issuing a “yum update …”.  Then when 
 searching around the 389-ds documentation, I came across the install page 
 that said that I must use “yum upgrade …” and not update. 
  
 My question is what’s the difference between yum update and upgrade?
 
 I think they are the same.  If someone knows any difference between yum 
 update and yum upgrade I'd like to hear it.
 
 Is it OK if I leave it like that or should I do the yum upgrade?
 
 It is OK to leave it like that.
 
 The service seems to be running OK after “yum update”, so far.
  
 I went from 1.2.11.15-14.el6_4 -- 1.2.11.29-1.el6
  
 Thanks,
 Trev
  
 -
 Trevor Fong – Senior Programmer Analyst
 Identity and Access Management Group
 University of British Columbia – Information Technology
 6356 Agricultural Road, Vancouver, BC, V6T 1Z2, Canada
 Ph: (604) 827-5247
 
  
 
 
 --
 389 users mailing list
 
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] db2ldif vs ldapmodify: turn up debugging of db2ldif?

[Morgan Jones]

I am working on a move from CentOS Directory (8.2.8) on CentOS 5 to 389-ds 
1.2.11 on CentOS 6.  I’m using a combination of the CentOS repositories and 
epel as suggested here.  

I'm finding ldif2db rejects entries while if I add them via ldapmodify they go 
in with no errors.  This is a problem as db2ldif does not give sufficient 
debugging to identify the problem.  Below are examples.  Is there a way to get 
more debugging out of ldif2db that I am missing?  Perhaps an error log level 
I’m missing?  Has anyone else seen this behavior?

I'm importing into a database other than userRoot if that makes a difference.

thanks,

-morgan



[root@devldapm03 ~]# /usr/lib64/dirsrv/slapd-devldapm03/ldif2db  -n studentRoot 
-i /var/tmp/students_fixed.ldif
importing data ...
[19/May/2014:15:53:48 -0400] - WARNING: Import is running with 
nsslapd-db-private-import-mem on; No other process is allowed to access the 
database
[19/May/2014:15:53:48 -0400] - check_and_set_import_cache: pagesize: 4096, 
pages: 2015405, procpages: 52243
[19/May/2014:15:53:48 -0400] - Import allocates 3224648KB import cache.
[19/May/2014:15:53:49 -0400] - import studentRoot: Beginning import job...
[19/May/2014:15:53:49 -0400] - import studentRoot: Index buffering enabled with 
bucket size 100
[19/May/2014:15:53:49 -0400] - import studentRoot: Processing file 
/var/tmp/students_fixed.ldif
...
[19/May/2014:15:55:04 -0400] - import studentRoot: WARNING: skipping entry 
uid=,ou=students,dc=domain,dc=org which violates attribute syntax, ending 
line 5457262 of file /var/tmp/students_fixed.ldif
...
#




# ldapmodify -x -a -h devldapm03.domain.net -D cn=directory\ manager -w pass
paste entry

adding new entry uid=,ou=students,dc=domain,dc=org
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 1.2.11.29 prediction?

[Morgan Jones]

On Apr 3, 2014, at 5:11 PM, Rich Megginson rmegg...@redhat.com wrote:

 On 04/03/2014 02:56 PM, Morgan Jones wrote:
 On Apr 3, 2014, at 3:39 PM, Rich Megginson rmegg...@redhat.com wrote:
 
 On 04/03/2014 01:35 PM, Michael Gettes wrote:
 Yeah, I hear what you’re saying.  47758 is due to running bleeding edge, i 
 get it.  but i had to go there cuz I was having problems with objects 
 getting messed up with .15 in production and even .25 in test and I went 
 to .28 which had the SASL fix on top of .26 which fixed all object 
 problems.  The object problems were the emails I sent to the list 
 indicating objects I couldn’t delete or modify and .28 fixed those 
 problems.  This is where i feel i was a little trapped and had to come 
 forward to the bleeding edge.  there was a method to my madness and didn’t 
 this just willy nilly and hence where i was hoping for .29 to i might have 
 a good mix of things - even if it was on the bleeding edge.  i hope this 
 makes sense.
 Yes, and we are working on fixing those issues in EL6.6.  So perhaps when 
 EL6.6 is released you will be able to use the OS packages.
 Rich et al,
 
 I've been following this thread with interest.   I am however a little 
 confused about the right place and version to get 389:
 
 you make a distinction between the source version (versions 1.2.11.28 and 
 1.3.1.16).  Both are stable, 1.3.1 is just newer and potentially more 
 bleeding edge?  1.3.1 also seems to not be available from either the OS or 
 epel repositories.
 
 1.2.11 branch is strictly maintenance - only the most critical patches.
 
 1.3.1 branch is less strict - it may get new features.
 
 1.3.1 is available for Fecdora 19.  1.3.1 will be in EL7.  We are not 
 planning to provide it in EPEL7 at this time.

Thanks, that makes sense.

 
 And if epel6 contains patches that have not been fully tested and I should 
 avoid it in production but how do I get the admin server, console etc?
 
 There is a distinction between epel6 and the official EPEL6.  What we call 
 389-ds-base in epel6 is not really the official EPEL6 repository.  It is 
 an individual developer provided and supported fedorapeople (and now copr) 
 repository strictly for those who want to (or must) be on the bleeding edge 
 of the 1.2.11 branch - those who absolutely require bug fixes or features 
 that are present in the upstream 1.2.11 branch, but are not yet in the 
 official EL6.5 389-ds-base package.

I understand.   I didn't catch the distinction between EPEL6 and epel6.  

Where is the (lowercase) epel6/copr repository?   I know I've seen the fedora 
people repository in the past but I can't for the life of me find it (or copr) 
now.  I see various pages but not the repository itself.

thanks for the clarifications,

-morgan



 On Apr 3, 2014, at 10:53 AM, Michael Gettes get...@gmail.com wrote:
 I recognize 389 is a community project and asking for timelines can be 
 problematic.  Right now, I am sorta stuck between a rock and a hard place.  
 In production, I am on 1.2.11.15 which has problems that are fixed by 
 1.2.11.28.  I have 1.2.11.28 in test and fixes all my prod problems but 
 introduces a new problem which makes it rather difficult to manage the 
 environment and it would appear this will be corrected in 1.2.11.29.  So, I 
 am a little curious as to when we might see 29.  I do see on the roadmap 29 
 has 4 closed and 5 active but no date set.
 
 Wouldn't this be a good time for Michael to consider 1.3.1?
 
 Sure, but we are not considering providing 1.3.1 rpms for EL6 at this time.  
 That means building/packaging/repository/updating manually.
 
 
 thanks,
 
 -morgan
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 1.2.11.29 prediction?

[Morgan Jones]

On Apr 4, 2014, at 3:20 PM, Rich Megginson rmegg...@redhat.com wrote:

 On 04/04/2014 01:04 PM, Morgan Jones wrote:
 On Apr 3, 2014, at 5:11 PM, Rich Megginson rmegg...@redhat.com wrote:
 
 On 04/03/2014 02:56 PM, Morgan Jones wrote:
 On Apr 3, 2014, at 3:39 PM, Rich Megginson rmegg...@redhat.com wrote:
 
 On 04/03/2014 01:35 PM, Michael Gettes wrote:
 Yeah, I hear what you’re saying.  47758 is due to running bleeding edge, 
 i get it.  but i had to go there cuz I was having problems with objects 
 getting messed up with .15 in production and even .25 in test and I went 
 to .28 which had the SASL fix on top of .26 which fixed all object 
 problems.  The object problems were the emails I sent to the list 
 indicating objects I couldn’t delete or modify and .28 fixed those 
 problems.  This is where i feel i was a little trapped and had to come 
 forward to the bleeding edge.  there was a method to my madness and 
 didn’t this just willy nilly and hence where i was hoping for .29 to i 
 might have a good mix of things - even if it was on the bleeding edge.  
 i hope this makes sense.
 Yes, and we are working on fixing those issues in EL6.6.  So perhaps when 
 EL6.6 is released you will be able to use the OS packages.
 Rich et al,
 
 I've been following this thread with interest.   I am however a little 
 confused about the right place and version to get 389:
 
 you make a distinction between the source version (versions 1.2.11.28 and 
 1.3.1.16).  Both are stable, 1.3.1 is just newer and potentially more 
 bleeding edge?  1.3.1 also seems to not be available from either the OS or 
 epel repositories.
 1.2.11 branch is strictly maintenance - only the most critical patches.
 
 1.3.1 branch is less strict - it may get new features.
 
 1.3.1 is available for Fecdora 19.  1.3.1 will be in EL7.  We are not 
 planning to provide it in EPEL7 at this time.
 Thanks, that makes sense.
 
 And if epel6 contains patches that have not been fully tested and I should 
 avoid it in production but how do I get the admin server, console etc?
 There is a distinction between epel6 and the official EPEL6.  What we 
 call 389-ds-base in epel6 is not really the official EPEL6 repository.  
 It is an individual developer provided and supported fedorapeople (and now 
 copr) repository strictly for those who want to (or must) be on the 
 bleeding edge of the 1.2.11 branch - those who absolutely require bug 
 fixes or features that are present in the upstream 1.2.11 branch, but are 
 not yet in the official EL6.5 389-ds-base package.
 I understand.   I didn't catch the distinction between EPEL6 and epel6.
 
 Where is the (lowercase) epel6/copr repository?   I know I've seen the 
 fedora people repository in the past but I can't for the life of me find it 
 (or copr) now.  I see various pages but not the repository itself.
 
 http://port389.org/wiki/Download

Oh.  I looked right over it.  Thanks.

-morgan


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

On Mar 6, 2014, at 11:32 AM, Ludwig Krispenz lkris...@redhat.com wrote:

 
 On 03/04/2014 11:10 PM, Morgan Jones wrote:
 
 
 On Mar 4, 2014, at 3:20 AM, Ludwig Krispenz lkris...@redhat.com wrote:
 
 Are groups involved in the acis and do these groups during these runs ?
 Yes, most of our ACIs use groups to determine access.  I'm not sure I 
 understand the second part of your question though.
 you can't, it was incomplete. I wanted to know if these groups are modified 
 during the runs when you see the failure.
  I do suspect this has something to do with access control though as it's 
 behaving exactly like the user is denied by the ACIs.
 No, groups were not modified.  They are relatively small as we're still 
 migrating to this environment--maybe 10-15 DNs per group and they're only 
 modified when we add/remove privileged accounts which isn't very often.
 
 Could you post your acis ?
 Probably.  I'm working on permission to do so.
 The compromise I came to with my management and security team is to 
 obfuscate the ACIs such that the attribute counts and structure are intact 
 but the names are changed.  Is the below useful?
 yes, but II can't see anything wrong with the acis.

Thanks for your input on the ACIs.

 One more question. Do the searches always match only one entry or one they 
 should see and some they shouldn't ?

In every case where we've seen this problem it's a search for one entry 
(uid=username) that the bind dn is able to see.

Thanks for your input, we're working on repeating it reliably in 389.

 
 # Employee LDAP Access Control
 #
 dn: dc=domain,dc=org
 changetype: modify
 replace: aci
 #
 aci: (target = ldap:///ou=employees,dc=domain,dc=org;)
  (targetattr = userpassword)
  (version 3.0; acl limited user self write;
  allow (write) userdn = ldap:///self;;)
 #
 aci: (target = ldap:///dc=domain,dc=org; )
  (targetfilter = 
 (|(objectclass=orgAssociate)(objectclass=orgEmployee)(objectclass=domain)
  
 (objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames)))
  (targetattr = attr1 || attr2 || ... || attr40)
  (version 3.0; acl general access, replaces anonymous access;
  allow (read, search, compare)
  (userdn = ldap:///self;) or
  (groupdn = ldap:///cn=orgGroup1,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup3,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
  ;)
 #
 aci: (target = ldap:///dc=domain,dc=org; )
  (targetfilter = (|(objectclass=orgExternalEmployee)(objectclass=domain)
  
 (objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames)))
  (targetattr = attr1 || attr2 || ... || attr40 )
  (version 3.0; acl general access, replaces anonymous access;
  allow (read, search, compare)
  (userdn = ldap:///self;) or
  (groupdn = ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
  ;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)
  (targetfilter = (|(objectclass=orgExternalEmployee)(objectclass=domain)
  
 (objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=orgServiceAccount)(objectclass=orgOrgAccount)))
  (targetattr = attr1 || attr2 || ... || attr40)
  (version 3.0; acl general access plus service and organizational accounts;
  allow (read, search, compare)
  (userdn = ldap:///self;) or
  (groupdn = ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
  ;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)(targetattr = attr1 ||
  attr2 || ... || attr30)
  (version 3.0; acl limited read access to non-public attributes for 
 delegated admins;
  allow (read, search, compare)
  (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or
  (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
  ;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)
  (targetattr = attr1 || attr2 || ... || attr28)
  (version 3.0; acl limited write access for delegated admins;
  allow (write) groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)
  (targetattr = *)(version 3.0; acl full access for delegated admins;
  allow (all) groupdn = ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org;;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)
  (targetfilter=(memberof=cn=orgGroup6,ou=Groups,dc=domain,dc=org))
  (targetattr=userpassword)
  (version 3.0; acl deny non-admin user write access to admin users' 
 passwords;
  deny (all) groupdn != ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org;
  ;)
 #
 aci: (target = ldap:///dc=domain,dc=org;)
  (targetattr = attr1

Re: [389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

On Mar 6, 2014, at 11:51 AM, Ludwig Krispenz lkris...@redhat.com wrote:

 One more question. Do the searches always match only one entry or one they 
 should see and some they shouldn't ?
 In every case where we've seen this problem it's a search for one entry 
 (uid=username) that the bind dn is able to see.
 what i was thinking of is a scenario where there is a cn=user1 in two 
 subtrees, the bound user should only see one. I remember a case where the 
 deny for the one entry was cached and the other entry was not returned

Oh, interesting.  That is not the case for us though.

 
 Thanks for your input, we're working on repeating it reliably in 389.
 That would be great

I'll see what I can do.

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Multi-Master Replication Issue

[Morgan Jones]

For testing I know TLS_REQCERT never works.

For production I use:
TLS_REQCERT demand
TLS_CACERT /path/to/ca_cert.pem

If TLS_REQCERT never works then there's something wrong with your cert most 
likely.  Though I'd expect a generic connection error if were just having a 
problem verifying the certificate.  Does ldapsearch/ldapmodify work for other 
operations?

Otherwise maybe send us the exact command you're running?

-morgan


On Mar 6, 2014, at 12:29 PM, Justin Edmands shockwav...@gmail.com wrote:

 On Thu, Mar 6, 2014 at 12:19 PM, Chaudhari, Rohit K. 
 rohit.chaudh...@jhuapl.edu wrote:
 Hi All,
 
 I am trying to create multi-master replication in 389.  But I am having
 trouble using ldapmodify to create a replication manager DN account
 
 I get the following error:
 
 Additional info: TLS error -8157: Certificate extension not found
 
 I went on the web and some people suggested I have a TLS_REQCERT=none line
 in /etc/openldap/ldap.conf, but this did not fix it either.
 
 My certificate in /etc/openldap/cacerts is called cacert.asc.
 
 Does anyone know how I can fix my problem?
 
 Thanks,
 
 R
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users
 
 Not totally sure, but don't use the =
 
 here is mine:
 
 URI ldaps://baldirsrv ldaps://hqdirsrv ldaps://stldirsrv
 BASE ou=People,dc=domain,dc=com
 TLS_CACERTDIR /etc/openldap/cacerts
 # TLS_CACERT /etc/openldap/cacerts/cacert.asc
 TLS_REQCERT allow
 
 you can set it to TLS_REQCERT never as well.
 
 Also consider setting the TLS_CACERTDIR and TLS_CACERT 
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

On Mar 4, 2014, at 3:20 AM, Ludwig Krispenz lkris...@redhat.com wrote:

 Are groups involved in the acis and do these groups during these runs ?
 Yes, most of our ACIs use groups to determine access.  I'm not sure I 
 understand the second part of your question though.
 you can't, it was incomplete. I wanted to know if these groups are modified 
 during the runs when you see the failure.
  I do suspect this has something to do with access control though as it's 
 behaving exactly like the user is denied by the ACIs.

No, groups were not modified.  They are relatively small as we're still 
migrating to this environment--maybe 10-15 DNs per group and they're only 
modified when we add/remove privileged accounts which isn't very often.

 Could you post your acis ?
 Probably.  I'm working on permission to do so.

The compromise I came to with my management and security team is to obfuscate 
the ACIs such that the attribute counts and structure are intact but the names 
are changed.  Is the below useful?

# Employee LDAP Access Control
#
dn: dc=domain,dc=org
changetype: modify
replace: aci
#
aci: (target = ldap:///ou=employees,dc=domain,dc=org;)
 (targetattr = userpassword)
 (version 3.0; acl limited user self write;
 allow (write) userdn = ldap:///self;;)
#
aci: (target = ldap:///dc=domain,dc=org; )
 (targetfilter = 
(|(objectclass=orgAssociate)(objectclass=orgEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames)))
 (targetattr = attr1 || attr2 || ... || attr40)
 (version 3.0; acl general access, replaces anonymous access; 
 allow (read, search, compare) 
 (userdn = ldap:///self;) or 
 (groupdn = ldap:///cn=orgGroup1,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=orgGroup3,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or 
 (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
 ;)
#
aci: (target = ldap:///dc=domain,dc=org; )
 (targetfilter = (|(objectclass=orgExternalEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames)))
 (targetattr = attr1 || attr2 || ... || attr40 )
 (version 3.0; acl general access, replaces anonymous access; 
 allow (read, search, compare) 
 (userdn = ldap:///self;) or 
 (groupdn = ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or 
 (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
 ;)
#
aci: (target = ldap:///dc=domain,dc=org;)
 (targetfilter = (|(objectclass=orgExternalEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=orgServiceAccount)(objectclass=orgOrgAccount)))
 (targetattr = attr1 || attr2 || ... || attr40)
 (version 3.0; acl general access plus service and organizational accounts; 
 allow (read, search, compare) 
 (userdn = ldap:///self;) or 
 (groupdn = ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org;) or
 (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or 
 (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
 ;)
#
aci: (target = ldap:///dc=domain,dc=org;)(targetattr = attr1 ||
 attr2 || ... || attr30)
 (version 3.0; acl limited read access to non-public attributes for delegated 
admins; 
 allow (read, search, compare)
 (groupdn = ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org;) or 
 (groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;)
 ;)
#
aci: (target = ldap:///dc=domain,dc=org;)
 (targetattr = attr1 || attr2 || ... || attr28)
 (version 3.0; acl limited write access for delegated admins; 
 allow (write) groupdn = ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org;;)
#
aci: (target = ldap:///dc=domain,dc=org;)
 (targetattr = *)(version 3.0; acl full access for delegated admins; 
 allow (all) groupdn = ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org;;)
#
aci: (target = ldap:///dc=domain,dc=org;)
 (targetfilter=(memberof=cn=orgGroup6,ou=Groups,dc=domain,dc=org))
 (targetattr=userpassword)
 (version 3.0; acl deny non-admin user write access to admin users' passwords;
 deny (all) groupdn != ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org;
 ;)
#
aci: (target = ldap:///dc=domain,dc=org;)
 (targetattr = attr1 || attr2 || ... || attr19)
 (version 3.0; acl access to posixaccount attributes for proxyagent;
 allow (read,search,compare) userdn = 
ldap:///uid=binddn1,ou=svc_accts,dc=domain,dc=org;;)

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

We're pulling our hair out over this issue and wondering if it rings a bell for 
anyone or perhaps there's a bug fix in a  later version of 389 that might 
resolve it.  I've looked and not found anything but it's also not the easiest 
issue to search for.  We are on CentOS DS now but can move to 389 of course but 
hesitate to put forth the effort if we aren't reasonably sure it will resolve 
our issue.

Certain bind DNs (so far only service accounts) are unable to search for users. 
 For instance:

[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 BIND 
dn=uid=copier,ou=employees,dc=domain,dc=org method=128 version=3
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 RESULT err=0 tag=97 nentries=0 
etime=0 dn=uid=copier,ou=employees,dc=domain,dc=org
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 SRCH 
base=ou=employees,dc=domain,dc=org scope=2 filter=(uid=user1) attrs=cn 
mail uid
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 RESULT err=0 tag=101 nentries=0 
etime=0

I did a search of the directory at the same time on the same replica as myself 
and other users with the same access level and was able to search uid=user1.

It sometimes only lasts a few minutes though in a few instances it was much 
longer.  In one case we resolved it by adding a service account with a 
different name but the same access level and moved the application to that 
account.  In another case where hundreds of copiers are configured with the 
binddn and thus changing the binddn wasn't practical we were able to resolve it 
by restoring the masters from a db2ldif and re-initializing the consumers. It's 
not isolated to once consumer--we've seen it on at least 2: one partial, one 
full.

Our environment is CentOS DS on CentOS 5.  We have ~35,000 entries in the 
directory, most of them users.  We only have 9 acis, most of which provide 
access via groups.  We have 2 multi-masters, 2 full consumers and until 
recently 2 partial replicas.  We converted the partial replicas to full 
replicas recently as we know there are/were issues with partial replication and 
wanted to rule that out.  We're at the latest version of CentOS DS:

[morgan@ldap01 ~]$ rpm -qa|grep centos-ds
centos-ds-admin-8.2.1-1.el5.centos
centos-ds-console-8.2.0-4.el5.centos
centos-ds-base-8.2.8-2.el5.centos
centos-ds-8.2.0-2.el5.centos
[morgan@ldap01 ~]$

This issue is killing us as it effectively denies access to a service for all 
users that use it.  This could be the VPN for instance which many users depend 
on all day for their work.

We are considering many options, primarily just moving to 389 on CentOS 6.  
That's a fairly big task for a site of our size so we'd like some confidence 
that we won't see a repeat of this issue.  There's talk of considering other 
products which no one wants to do but we're all edgy as this has caused a fair 
amount of downtime and about all I can do at the moment is monitor for it and 
re-initialize when it happens which doesn't inspire confidence.

thank you,

-morgan
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

On Mar 3, 2014, at 11:24 AM, Rich Megginson rmegg...@redhat.com wrote:

 On 03/03/2014 08:56 AM, Morgan Jones wrote:
 
 We're pulling our hair out over this issue and wondering if it rings a bell 
 for anyone or perhaps there's a bug fix in a  later version of 389 that 
 might resolve it.  I've looked and not found anything but it's also not the 
 easiest issue to search for.  We are on CentOS DS now but can move to 389 of 
 course but hesitate to put forth the effort if we aren't reasonably sure it 
 will resolve our issue.
...
 
 We are considering many options, primarily just moving to 389 on CentOS 6.  
 That's a fairly big task for a site of our size so we'd like some confidence 
 that we won't see a repeat of this issue.  There's talk of considering other 
 products which no one wants to do but we're all edgy as this has caused a 
 fair amount of downtime and about all I can do at the moment is monitor for 
 it and re-initialize when it happens which doesn't inspire confidence.
 
 I've never seen this problem, so I can't be sure that upgrading will solve 
 it.  However, it is almost impossible for us to support centos-ds 8.2, so we 
 are unlikely to be able to debug 8.2 and provide a patch for 8.2.

This is understandable.  Now that I have a better idea of how the community 
works I would not implement on CentOS-DS again.

 If you can reproduce the problem with 389-ds-base 1.2.11.x, it will be much 
 easier for us to debug and fix.

We are still unable to repeat it reliably but are working to do so in our dev 
environment.  I'll be in touch when/if we are able to do so in 389 1.2.11.x.

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Morgan Jones]

On Mar 3, 2014, at 11:07 AM, Ludwig Krispenz lkris...@redhat.com wrote:

 Hi,
 
 so you say that a search with a specific bind user sometimes succeeds and 
 sometimes doesn't ?

Correct.

 If so, could you run this withe aci logging enabled ?

Sure though we are still unable to repeat the problem reliably so haven't 
caught it happening with aci debugging turned on.  I'm going to work on various 
scenarios to do so in our dev environment.

 Are groups involved in the acis and do these groups during these runs ?

Yes, most of our ACIs use groups to determine access.  I'm not sure I 
understand the second part of your question though.  I do suspect this has 
something to do with access control though as it's behaving exactly like the 
user is denied by the ACIs.

 Could you post your acis ?

Probably.  I'm working on permission to do so.

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Problems setting up MMR

[Morgan Jones]

Louis,

Did you create cn=replication manager?  It looks like you did not.

Try this to see if it's there:
ldapsearch -H ldaps://ldap02 -D cn=directory\ manager -w pass -LLLb 
cn=replication manager,cn=config objectclass=\*

replace ldaps with ldap of course if you have not set up ssl.

I believe it's in dse.ldif as well.

-morgan


On Aug 22, 2013, at 3:17 PM, Louis Bohm wrote:

 I have 2 servers running cents 6.4 and the newest version of DS from the 
 repos.  Both serves have the same supplier DN.  On the second server (ldap02) 
 I go no errors when setting up the replication agreement.  However, on the 
 first server (ldap01) I got LDAP error: No such object.  Error code: 32.  
 The logs on ldap02 show this:
 
 [22/Aug/2013:15:14:17 -0400] conn=48 fd=71 slot=71 connection from 
 10.74.192.51 to 10.74.192.52
 [22/Aug/2013:15:14:17 -0400] conn=48 op=0 BIND dn=cn=replication 
 manager,cn=config method=128 version=3
 [22/Aug/2013:15:14:17 -0400] conn=48 op=0 RESULT err=32 tag=97 nentries=0 
 etime=0
 [22/Aug/2013:15:14:17 -0400] conn=48 op=1 UNBIND
 [22/Aug/2013:15:14:17 -0400] conn=48 op=1 fd=71 closed - U1
 
 I guess the first thing I need to do is prove that supplier DN is really 
 there and is the same.  But I have been unable to come up with an ldapsearch 
 that shows it.  Or is the only way to see it is to grep the dse.ldif file?
 
 Louis
 
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] problems with password policies

[Morgan Jones]

Either I'm missing something or password policies just don't work in Redhat 
(CentOS) directory 8.2.8.

I started by creating a subtree policy on the command line:

# ./ns-newpwpolicy.pl -D cn=directory\ manager -w pass -h localhost -S 
ou=students,dc=domain,dc=org
adding new entry cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org

adding new entry 
cn=cn=nsPwPolicyEntry\,ou=students\,dc=domain\,dc=org,cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org

adding new entry 
cn=cn=nsPwTemplateEntry\,ou=students\,dc=domain\,dc=org,cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org

adding new entry cn=nsPwPolicy_cos,ou=students,dc=domain,dc=org

modifying entry cn=config



The following were created:

dn: cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer

dn: cn=cn=nsPwTemplateEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyC
 ontainer,ou=students,dc=domain,dc=org
objectClass: top
objectClass: extensibleObject
objectClass: costemplate
objectClass: ldapsubentry
cosPriority: 1
cn: cn=nsPwTemplateEntry,ou=students,dc=domain,dc=org

dn: cn=nsPwPolicy_cos,ou=students,dc=domain,dc=org
objectClass: top
objectClass: LDAPsubentry
objectClass: cosSuperDefinition
objectClass: cosPointerDefinition
costemplatedn: cn=cn=nsPwTemplateEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=
 nsPwPolicyContainer,ou=students,dc=domain,dc=org
cosAttribute: pwdpolicysubentry default operational-default
cn: nsPwPolicy_cos

dn: cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyCon
 tainer,ou=students,dc=domain,dc=org
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,ou=students,dc=domain,dc=org




I added the policy attributes we're interested in:

dn: cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyCon
 tainer,ou=students,dc=domain,dc=org
passwordResetFailureCount: 600
passwordMaxFailure: 10
passwordLockout: on
passwordMinLength: 6
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,ou=students,dc=domain,dc=org



I then tried 11 ldapsearches as a user under ou=students,dc=domain,dc=org and 
the account was not locked out.



I then checked the console and the settings weren't there.  I set them and it 
added two additional entries:

dn: cn=cn\3DnsPwPolicyEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsPwP
 olicyContainer,ou=students,dc=domain,dc=org
passwordMaxFailure: 10
passwordResetFailureCount: 600
passwordLockout: on
passwordStorageScheme: ssha
passwordCheckSyntax: on
passwordChange: off
passwordMinAge: 0
passwordExp: off
passwordMustChange: off
passwordMinLength: 6
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
cn: cn=nsPwPolicyEntry,ou=students,dc=domain,dc=org

dn: cn=cn\3DnsPwTemplateEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsP
 wPolicyContainer,ou=students,dc=domain,dc=org
objectClass: extensibleObject
objectClass: costemplate
objectClass: ldapsubentry
objectClass: top
cosPriority: 1
cn: cn=nsPwTemplateEntry,ou=students,dc=domain,dc=org


However I still can't force a user to be locked out.

I did set passwordIsGlobalPolicy to on under cn=config though as far as I can 
tell that only affects replication of password policies.

Am I missing something?

thanks,

-morgan
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] memberof plugin unreliable?

[Morgan Jones]

Venkat et al,

Yes, well at least all of the users in the group do.  Though we provision 
programmatically so I'd guess all or at least the vast majority of our users do.

-morgan


On Aug 12, 2013, at 2:32 PM, Mahadevan, Venkat wrote:

 Do all of your user entries have the inetUser objectClass on them?
 
 cheers,
 
 VM
 --
 389 users mailing list
 389-users@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users