Hi Again,
Tried running the register script and we are getting an error message that
states "failed to register the configuration server info to the
Configuration Directory Server..." (Screenshot below). Any ideas?
[image: image.png]
Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923
On Fri, Aug 31, 2018 at 10:01 AM Mark Reynolds <mreynolds(a)redhat.com> wrote:
:-) There is no downtime it just does a bunch of ldapmodifies to add
the
o=netscapeoot suffix. You might need to restart the admin server, but not
DS.
Here are some useful links:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....
http://www.port389.org/docs/389ds/design/console-remote-reg-design.html
On 08/31/2018 09:49 AM, Cassandra Reed wrote:
Output it much better after including -x, screenshot below. If we run the
register-ds-admin, will there be any downtime to the server? I just need
to confirm that this will not affect the userroot database in any way,
since classes start next week and I value my job :)
Cassandra Reed
978-762-4222
EDP Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923
On Thu, Aug 30, 2018 at 4:19 PM Mark Reynolds <mreynolds(a)redhat.com>
wrote:
>
>
> On 08/30/2018 03:35 PM, Cassandra Reed wrote:
>
> Thanks, Mark. When executing the ldapsearch that you suggested, I am
> getting an error message: ldap_sasl_interactive_bind_s: Unknown
> authentication method (-6) additional info: SASL(-4): no mechanism
> available:
>
> Ugh sorry you need to add -x:
>
> ldapsearch -D "cn=directory manager" -W -x -b o=netscapeoot objectclass=*
> dn
>
>
> We have been replicating o=netscaperoot - I am not sure how up to date
> the replicas are, considering the trouble that we are having with the
> config db right now...
>
> That's the problem. If you are replicating o=netscaperoot to other
> servers that use the console, are you are basically hosing each one of
> those servers o=netscaperoot suffix. o=netscaperoot is specific to the
> host in which it was originally created. You should only replicate
> o=netscaperoot as backup technique, and it should not replicated to a
> server that uses the 389-console - otherwise the console won't work (e.g.
> blank screen)
>
> So the console will only work on the original server you started
> replication from.
>
> Now to fix it, assuming this is the case...
>
> You have to remove o=netscapeorot suffix, and run register-ds-admin.pl
> to recreate o=netscaperoot suffix for that server
>
> Regards,
> Mark
>
>
>
>
> Cassandra Reed
> 978-762-4222
> EDP Systems Analyst III
> North Shore Community College
> 1 Ferncroft Road, Danvers MA 01923
>
>
> On Thu, Aug 30, 2018 at 3:20 PM Mark Reynolds <mreynolds(a)redhat.com>
> wrote:
>
>>
>>
>> On 08/30/2018 03:07 PM, Cassandra Reed wrote:
>>
>> Hi Mark,
>>
>> You are correct, it does appear that the o=netscaperoot suffix was
>> removed.
>>
>> No, I think it's still there. Try this search:
>>
>> # ldapsearch -D "cn=directory manager" -W -b o=netscapeoot
>> objectclass=* dn
>>
>> Maybe try restarting the admin server:
>>
>> # restart-ds-admin
>>
>>
>> Are you replicating o=netscaperoot by any chance?
>>
>> Mark
>>
>>
>> Below is a bit of the access log file during the launch of the console.
>> We have two other servers that this Master was replicating to, is it
>> possible to export the netscaperoot from one of those other two servers and
>> import to the Master? What would this require and would it be service
>> impacting at all? (Reboot of the server/etc.) One of the servers hasn't
>> been replicating in some time, would an older version of netscaperoot have
>> any impact on the userroot directory?
>>
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 fd=79 slot=79 connection from
>> 127.0.0.1 to 127.0.0.1
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 BIND dn="cn=Directory
>> Manager" method=128 version=3
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=0 RESULT err=0 tag=97
>> nentries=0 etime=0 dn="cn=directory manager"
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 SRCH
>> base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
>> Preferences,ou=northshore.edu,o=NetscapeRoot" scope=0
>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=1 RESULT err=32 tag=101
>> nentries=0 etime=0
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 SRCH
>> base="cn=group,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
>> Preferences,ou=northshore.edu,o=NetscapeRoot" scope=0
>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=2 RESULT err=32 tag=101
>> nentries=0 etime=0
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 SRCH
>> base="cn=OU,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global
>> Preferences,ou=northshore.edu,o=NetscapeRoot" scope=0
>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=3 RESULT err=32 tag=101
>> nentries=0 etime=0
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 SRCH
>> base="cn=ResourceEditorExtension,ou=1.1,ou=admin,ou=Global Preferences,ou=
>> northshore.edu,o=NetscapeRoot" scope=1
>> filter="(objectClass=nsAdminResourceEditorExtension)" attrs=ALL
>> [30/Aug/2018:14:28:03 -0400] conn=1035324 op=4 RESULT err=32 tag=101
>> nentries=0 etime=0
>>
>>
>> Thank you,
>> -Cassie
>>
>> Cassandra Reed
>> 978-762-4222
>> EDP Systems Analyst III
>> North Shore Community College
>> 1 Ferncroft Road, Danvers MA 01923
>>
>>
>> On Thu, Aug 30, 2018 at 9:44 AM Mark Reynolds <mreynolds(a)redhat.com>
>> wrote:
>>
>>> Are you logging in as Directory Manager?
>>>
>>> If you are, perhaps the o=netscaperoot suffix was removed from DS? You
>>> need to look at the access log in this case and what it's doing when you
>>> log in.
>>>
>>> Mark
>>>
>>>
>>
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>
>
>