[389-users] Re: advice on 389 in production
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
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
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
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
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
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] Re: search inconsistencies
> On Nov 30, 2021, at 5:24 PM, William Brown wrote: > > > >> On 1 Dec 2021, at 07:26, Morgan Jones wrote: >> >> >> Can anyone provide insight on why the below might be happening, my best >> guess is a corrupt uniquemember index?? > > If you add the uniquemember index, but never trigger a reindex, the server > treats it as an empty result set until you do a reindex. > > So I'd say do a reindex and see if that resolves it. Understood: we did a full re-index. Thank you, will do. -morgan > >> >> 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 > > -- > 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] search inconsistencies
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
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
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
> 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
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
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 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
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
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ý > 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 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ý > > 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
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
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 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 : > >> 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 >>> 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 >&
[389-users] Re: Possible bug? - Silent install behaves differently from interactive
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 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 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 : > >> 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 generate
[389-users] Re: Possible bug? - Silent install behaves differently from interactive
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 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 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 >> --
[389-users] Re: Error after setting nsslapd-allow-anonymous-access:rootdse
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@lists.fedoraproject.org >>> T
[389-users] Re: jss and idm-console-framework conflict
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 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 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 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
Julian, Sorry on the name mix-up, typing quickly. -morgan > On Sep 15, 2017, at 12:56 PM, Morgan Jones 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 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 >&
[389-users] Re: Possible bug? - Silent install behaves differently from interactive
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-le...@lists.fedoraproject.org
[389-users] Re: jss and idm-console-framework conflict
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 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 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
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 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
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
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 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 wrote: >>> >>> >>> >>> On 08/23/2017 12:31 PM, Morgan Jones wrote: >>>>> 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? >>> 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
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 wrote: > > > > On 08/23/2017 12:31 PM, Morgan Jones wrote: >>> 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? > 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=0 tag=101 nentries=1 etime=0 [23/Aug/2017:12:55:17.5710
[389-users] Re: Console hang after 4th server install
> 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
> On Aug 23, 2017, at 12:11 PM, Mark Reynolds wrote: > > On 08/23/2017 11:40 AM, Morgan Jones wrote: >> I should add a few things: >> >> I tried installing Java from Oracle, there are reports of problems with the >> openjdk. > What problems? You should be using: java-1.8.0-openjdk I started there, I’ll go back. > Also, are you using SSL/TLS in your servers? Or are these just plain > installs? They’re plain installs so far. SSL/TLS is the next step though. -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
> On Aug 23, 2017, at 11:32 AM, Mark Reynolds 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
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 wrote: > > >> On Aug 22, 2017, at 2:15 PM, Mark Reynolds 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
> On Aug 22, 2017, at 2:15 PM, Mark Reynolds 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
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 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 >>> 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
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> /admin-serv/authent
[389-users] Console hang after 4th server install
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
Hello, I’m just checking in on this. Is no one using subtree based password policies in 389 directory? -morgan > On May 31, 2016, at 15:14, Morgan Jones wrote: > > 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 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 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
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 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
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 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
> 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
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 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
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?
On May 20, 2014, at 12:42 PM, Noriko Hosoi wrote: > >> On May 19, 2014, at 4:48 PM, Noriko Hosoi 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. > What does this config param value? > ldapserver ... -D -w -b "cn=config" -s base > nsslapd-syntaxlogging it is off. > > If "off", could you try the import with "on"? > > Do you get any extra info in the error log? On first blush that seems to have done it. I have to work through it but I like this output much better: [20/May/2014:17:06:01 -0400] Syntax Check - "uid=7739428,ou=students,dc=philasd,dc=org": (modifyTimestamp) value #0 invalid per syntax [20/May/2014:17:06:01 -0400] - import studentRoot: WARNING: skipping entry “uid=xxx,ou=students,dc=domain,dc=org" which violates attribute syntax, ending line 7527060 of file "/var/tmp/students_fixed.ldif” thanks for your help, -morgan -- 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
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 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
Re: [389-users] db2ldif vs ldapmodify: turn up debugging of db2ldif?
On May 19, 2014, at 5:57 PM, Lulzim KELMENI 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 >> >> >> 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?
On May 19, 2014, at 4:48 PM, Noriko Hosoi 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 >> >> >> 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
[389-users] db2ldif vs ldapmodify: turn up debugging of db2ldif?
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 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?
On Apr 4, 2014, at 3:20 PM, Rich Megginson wrote: > On 04/04/2014 01:04 PM, Morgan Jones wrote: >> On Apr 3, 2014, at 5:11 PM, Rich Megginson wrote: >> >>> On 04/03/2014 02:56 PM, Morgan Jones wrote: >>>> On Apr 3, 2014, at 3:39 PM, Rich Megginson 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] 1.2.11.29 prediction?
On Apr 3, 2014, at 5:11 PM, Rich Megginson wrote: > On 04/03/2014 02:56 PM, Morgan Jones wrote: >> On Apr 3, 2014, at 3:39 PM, Rich Megginson 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 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?
On Apr 3, 2014, at 3:39 PM, Rich Megginson 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. CentOS 6 includes centos-ds-base which is 1.2.11.15 and just includes the base directory server. Epel seems to contain all the accessory utilities (admin server, console, etc). However: On Apr 3, 2014, at 11:48 AM, Rich Megginson wrote: > And that problem is entirely due to running "bleeding edge" software - a new > patch/feature urgently requested to be in EL6.6 that we didn't completely > backport to epel6. If you were running the standard 389-ds-base in EL6.5 you > would not have seen this issue. The 389-ds-base in epel6 contains patches > intended for EL6.6 but which have not yet been fully tested. The only way > you could get into a real bind is if you have run into an issue due to be > fixed in EL6.6 that you urgently need and can't wait for it to be released > through the usual EL6.6 channels. I don't see 389-de-base in epel, just adimin server, console etc. 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? On Apr 3, 2014, at 10:53 AM, Michael Gettes 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? 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
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 wrote: > On Thu, Mar 6, 2014 at 12:19 PM, Chaudhari, Rohit K. > 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
On Mar 6, 2014, at 11:51 AM, Ludwig Krispenz 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] Some bind DNs sporadically can't search users
On Mar 6, 2014, at 11:32 AM, Ludwig Krispenz wrote: > > On 03/04/2014 11:10 PM, Morgan Jones wrote: >> >> >> On Mar 4, 2014, at 3:20 AM, Ludwig Krispenz 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"
Re: [389-users] Some bind DNs sporadically can't search users
On Mar 4, 2014, at 3:20 AM, Ludwig Krispenz 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
Re: [389-users] Some bind DNs sporadically can't search users
On Mar 3, 2014, at 11:07 AM, Ludwig Krispenz 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] Some bind DNs sporadically can't search users
On Mar 3, 2014, at 11:24 AM, Rich Megginson 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
[389-users] Some bind DNs sporadically can't search users
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] problems with password policies
I think I have this sorted. It looks like the problem is that the ns-newpwpolicy.pl uses '=' instead of its ascii value (\3D) in the rdn of the password policy itself and the costemplatedn attribute of the CoS specification. Below is what is working for me. -morgan check that nsslapd-pwpolicy-local is on $ ldapsearch -H ldaps://devsgldap01.domain.net -x -D cn=directory\ manager -y ~/Docs/.pass2 -LLLb cn=config -s base nsslapd-pwpolicy-local dn: cn=config nsslapd-pwpolicy-local: on $ top level container: $ ldapsearch -LLL -H ldaps://devsgldap01.domain.net -D cn=directory\ manager -x -y ~/Docs/.pass2 '(objectclass=nscontainer)' dn: cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org cn: nsPwPolicyContainer objectClass: top objectClass: nsContainer Password policy itself. Note that '=' has been replaced with '\3D' in the dn that is the rdn: $ ldapsearch -LLL -H ldaps://devsgldap01.domain.net -D cn=directory\ manager -x -y ~/Docs/.pass2 '(&(objectclass=ldapsubentry)(objectclass=passwordpolicy))' 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 The cos template that has the pwdpolicysubentry value point to the above nsPwPolicyEntry entry. pwdpolicysubentry is operational, ask for it separately: $ ldapsearch -LLL -H ldaps://devsgldap01.domain.net -D cn=directory\ manager -x -y ~/Docs/.pass2 '(&(objectclass=ldapsubentry)(objectclass=costemplate))' 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 $ ldapsearch -LLL -H ldaps://devsgldap01.domain.net -D cn=directory\ manager -x -y ~/Docs/.pass2 '(&(objectclass=ldapsubentry)(objectclass=costemplate))' pwdpolicysubentry dn: cn=cn\3DnsPwTemplateEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsP wPolicyContainer,ou=students,dc=domain,dc=org pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc \3Dorg,cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org CoS specification at the subtree level. Note that '=' has been replaced with '\3D' in costemplatedn: $ ldapsearch -LLL -H ldaps://devsgldap01.domain.net -D cn=directory\ manager -x -y ~/Docs/.pass2 '(&(objectclass=ldapsubentry)(objectclass=cossuperdefinition))' dn: cn=nsPwPolicy_cos,ou=students,dc=domain,dc=org costemplatedn: cn=cn\3DnsPwTemplateEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3 Dorg,cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org cn: nsPwPolicy_cos cosAttribute: pwdpolicysubentry default operational-default objectClass: top objectClass: LDAPsubentry objectClass: cosSuperDefinition objectClass: cosPointerDefinition On Aug 26, 2013, at 2:49 PM, Morgan Jones wrote: > > On Aug 23, 2013, at 4:02 AM, Ludwig Krispenz wrote: > >> Did you enable the global password policy and set nsslapd-pwpolicy-loca: on ? > > Yes, it is set > >> >> The admin guide (chapter 14.1.2) says that pwpolicy must be enabled >> globally before loacal policies are used. >> >> And I think your cos definition is incomplete: the costemplate needst hold a >> value for the cos attribute, >> pwdpolicysubentry: >> cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyCon >> tainer,ou=students,dc=domain,dc=org > > pwdpolicysubentry is set, it didn't show up on my search below because it's > apparently an operational attribute (I get it if I request it). It's set for > both of the templates--the one added by the command line and the one added by > the console: > > $ ldapsearch -H ldaps://devsgldapm01.domain.net -x -y ~/Docs/.pass2 -D > cn=directory\ manager -LLL > '(&(objectclass=costemplate)(objectclass=ldapsubentry))' pwdpolicysubentry > objectclass > dn: cn=cn=nsPwTemplateEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyC > ontainer,ou=students,dc=domain,dc=org > pwdpolicysubentry: cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,c > n=nsPwPolicyContainer,ou=students,dc=domain,dc=org > objectclass: top > objectclass: extensibleObject > objectclass: costemplate > objectclass: ldapsubentry > > dn: cn=cn\3DnsPwTemplateEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsP > wPolicyContainer,o
Re: [389-users] problems with password policies
On Aug 23, 2013, at 4:02 AM, Ludwig Krispenz wrote: > Did you enable the global password policy and set nsslapd-pwpolicy-loca: on ? Yes, it is set > > The admin guide (chapter 14.1.2) says that pwpolicy must be enabled globally > before loacal policies are used. > > And I think your cos definition is incomplete: the costemplate needst hold a > value for the cos attribute, > pwdpolicysubentry: > cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyCon > tainer,ou=students,dc=domain,dc=org pwdpolicysubentry is set, it didn't show up on my search below because it's apparently an operational attribute (I get it if I request it). It's set for both of the templates--the one added by the command line and the one added by the console: $ ldapsearch -H ldaps://devsgldapm01.domain.net -x -y ~/Docs/.pass2 -D cn=directory\ manager -LLL '(&(objectclass=costemplate)(objectclass=ldapsubentry))' pwdpolicysubentry objectclass dn: cn=cn=nsPwTemplateEntry\2Cou=students\2Cdc=domain\2Cdc=org,cn=nsPwPolicyC ontainer,ou=students,dc=domain,dc=org pwdpolicysubentry: cn=cn=nsPwPolicyEntry\2Cou=students\2Cdc=domain\2Cdc=org,c n=nsPwPolicyContainer,ou=students,dc=domain,dc=org objectclass: top objectclass: extensibleObject objectclass: costemplate objectclass: ldapsubentry dn: cn=cn\3DnsPwTemplateEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc\3Dorg,cn=nsP wPolicyContainer,ou=students,dc=domain,dc=org pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3Dstudents\2Cdc\3Ddomain\2Cdc \3Dorg,cn=nsPwPolicyContainer,ou=students,dc=domain,dc=org objectclass: extensibleObject objectclass: costemplate objectclass: ldapsubentry objectclass: top thanks, -morgan > > > Ludwig > > On 08/22/2013 11:06 PM, Morgan Jones wrote: >> 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
[389-users] problems with password policies
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] Problems setting up MMR
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
Re: [389-users] memberof plugin unreliable?
On Aug 12, 2013, at 2:55 PM, Justin Edmands wrote: > > > I am almost positive that fractional replication is required for that plugin. That's bad news as we can't get fractional replication working reliably. I'll revisit it but in our production environment fractional replication fails reliably within an hour of being initialized. Shouldn't it at least work on the masters? They are multi-masters though so I suppose could also be argued to be replicas. > > Anything in logs about unwilling to perform? as in err=34? No. When would I get the error? > The whole "unreliable at best" comment makes me think the new entries will > work but not existing. Is this true? Nope, I just tested it to be sure. I referred to it as unreliable at best as it was working Wednesday afternoon last week. I got a few hours into configuring software that depended on it and it was returning the results mentioned here. > > For existing entries, did you run the fix-up task mentioned in the link below? > > http://directory.fedoraproject.org/wiki/MemberOf_Plugin What would the filter be? I tried an individual user, objectclass=inetuser and objectclass=* none produced results or even activity on the server. Should the task look like this? That is the cn should match the rdn and the rdn need not have the trailing '2?' dn: cn=memberof task, cn=memberof task, cn=tasks, cn=config changetype: add objectClass: top objectClass: extensibleObject cn: memberof task basedn: dc=philasd,dc=org filter: (objectclass=inetuser) 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?
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