[389-users] Re: Error after setting nsslapd-allow-anonymous-access:rootdse
Thanks Morgan. I will take a look at those ACIs. - Original Message - > From: "Morgan Jones" > To: "General discussion list for the 389 Directory server project." > <389-users@lists.fedoraproject.org> > Sent: Friday, September 15, 2017 3:11:02 PM > Subject: [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 setti
[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
On 09/15/2017 03:30 PM, Morgan Jones wrote: > 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. Thank you for testing the package and adding karma! I'll move the build to the next phase. Mark > > -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 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
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 >> 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.fe
[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] Possible bug? - Silent install behaves differently from interactive
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
