389 console is blank

List overview All Threads
Download

newer

older

Multi-Master tutorial

Installing the console

JESSE LUNT

30 Aug 2018 30 Aug '18

3:09 p.m.

Hi all,

We are experiencing a blank screen when logging into the 389-console.

Any ideas?

[image: image.png]

thanks,

Jesse

Jesse Lunt Director of Network and User Services Office of Information Services North Shore Community College (978)-762-4014

Attachments:

attachment.html (text/html — 701 bytes)
image.png (image/png — 126.0 KB)

Show replies by date

Mark Reynolds

30 Aug 30 Aug

3:42 p.m.

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

On 08/30/2018 09:09 AM, JESSE LUNT wrote:

...

Hi all,

We are experiencing a blank screen when logging into the 389-console.

Any ideas?

image.png

thanks,

Jesse

Jesse Lunt Director of Network and User Services Office of Information Services North Shore Community College (978)-762-4014

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Cassandra Reed

9:07 p.m.

Hi Mark,

You are correct, it does appear that the o=netscaperoot suffix was removed. 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@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

On 08/30/2018 09:09 AM, JESSE LUNT wrote:

Hi all,
We are experiencing a blank screen when logging into the 389-console.
Any ideas?

[image: image.png]

thanks,

Jesse

Jesse Lunt Director of Network and User Services Office of Information Services North Shore Community College (978)-762-4014

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Mark Reynolds

9:20 p.m.

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 http://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 http://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 http://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 http://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@redhat.com mailto:mreynolds@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

Cassandra Reed

9:35 p.m.

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:

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...

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@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@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

JESSE LUNT

10:14 p.m.

Hey All,

So if you haven't figured it out today Cassie and I work together and double team this environment. I ran the following and did get a response back.

ldapsearch -D "uid=onecampus,ou=Tools,dc=northshore,dc=edu" -w "northshore-2018" -H ldap://389ds1.northshore.edu:389 -x -b "cn=config,o=netscaperoot" "objectclass=*"

[image: image.png]

On Thu, Aug 30, 2018 at 3:36 PM Cassandra Reed creed@northshore.edu 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:

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...

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@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@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

-- Jesse Lunt Director of Network and User Services Office of Information Services North Shore Community College (978)-762-4014

Mark Reynolds

10:19 p.m.

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@redhat.com mailto:mreynolds@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
<http://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
<http://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
<http://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
<http://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@redhat.com <mailto:mreynolds@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Cassandra Reed

31 Aug 31 Aug

3:49 p.m.

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 :)

[image: image.png]

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@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@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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Mark Reynolds

4:01 p.m.

:-) 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.2/h...

http://www.port389.org/docs/389ds/design/console-remote-reg-design.html

On 08/31/2018 09:49 AM, Cassandra Reed wrote:

...

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@redhat.com mailto:mreynolds@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 <http://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@redhat.com <mailto:mreynolds@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
    <http://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
    <http://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
    <http://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
    <http://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@redhat.com <mailto:mreynolds@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@lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to389-users-leave@lists.fedoraproject.org
<mailto:389-users-leave@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.fedoraproject.org

Cassandra Reed

4 Sep 4 Sep

9:35 p.m.

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@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.2/h...

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@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@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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Mark Reynolds

9:41 p.m.

Can you provide the Directory Server's access log (/var/lod/dirsrv/slapd-YOUR_INSTANCE/access) content from the time you ran the register script?

Worse case scenario, you can delete o=netscaperoot, and run the script again and it will create it from scratch. Since your setup is corrupted that might be best. Make sure to remove any replication agreements for the o=netscaperoot first.

Thanks, Mark

On 09/04/2018 03:35 PM, Cassandra Reed wrote:

...

Hi Again,

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@redhat.com mailto:mreynolds@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.2/html/Installation_Guide/register-ds-admin.html

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@redhat.com <mailto:mreynolds@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 <http://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@redhat.com <mailto:mreynolds@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
        <http://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
        <http://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
        <http://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
        <http://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@redhat.com <mailto:mreynolds@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@lists.fedoraproject.org
    <mailto:389-users@lists.fedoraproject.org>
    To unsubscribe send an email to389-users-leave@lists.fedoraproject.org
    <mailto:389-users-leave@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.fedoraproject.org

Cassandra Reed

10:02 p.m.

Hi Mark,

Here are the log entries from one of the attempts from today:

[04/Sep/2018:15:32:26 -0400] conn=1352070 op=2 fd=104 closed - U1 [04/Sep/2018:15:32:27 -0400] conn=1352071 fd=101 slot=101 connection from 127.0.0.1 to 127.0.0.1 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 BIND dn="" method=128 version=3 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 BIND dn="uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" method=128 version=3 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 SRCH base="o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 SRCH base="cn= 389ds1.northshore.edu,ou=northshore.edu,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 RESULT err=32 tag=101 nentries=0 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 SRCH base="cn= 389ds1.northshore.edu,ou=northshore.edu,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=5 ADD dn="cn= 389ds1.northshore.edu,ou=northshore.edu,o=NetscapeRoot" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot" [04/Sep/2018:15:32:28 -0400] conn=1352071 op=5 RESULT err=32 tag=105 nentries=0 etime=1 csn=5b8eddcb000007b30000 [04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 UNBIND [04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 fd=101 closed - U1

Cassandra Reed 978-762-4222 EDP Systems Analyst III North Shore Community College 1 Ferncroft Road, Danvers MA 01923

On Tue, Sep 4, 2018 at 3:41 PM Mark Reynolds mreynolds@redhat.com wrote:

...

Can you provide the Directory Server's access log (/var/lod/dirsrv/slapd-YOUR_INSTANCE/access) content from the time you ran the register script?

Worse case scenario, you can delete o=netscaperoot, and run the script again and it will create it from scratch. Since your setup is corrupted that might be best. Make sure to remove any replication agreements for the o=netscaperoot first.

Thanks, Mark

On 09/04/2018 03:35 PM, Cassandra Reed wrote:

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@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.2/h...

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@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@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@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....

Mark Reynolds

10:13 p.m.

Okay, I think you should remove the o=netscaperoot backend, and rerun the register script. It's not finding your domain ou=northshore.edu in o=netscaperoot http://northshore.edu

First remove the suffix and database configuration:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht... http://northshore.edu

Stop the server, and then delete this directory: /var/lib/dirsrv/slapd-YOUR_INSTANCE/db/Netscaperoot

Start the server and run the register script.

Thanks,

Mark

On 09/04/2018 04:02 PM, Cassandra Reed wrote:

...

Hi Mark,

Here are the log entries from one of the attempts from today:

[04/Sep/2018:15:32:26 -0400] conn=1352070 op=2 fd=104 closed - U1 [04/Sep/2018:15:32:27 -0400] conn=1352071 fd=101 slot=101 connection from 127.0.0.1 to 127.0.0.1 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 BIND dn="" method=128 version=3 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 BIND dn="uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" method=128 version=3 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 SRCH base="o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 SRCH base="cn=389ds1.northshore.edu http://389ds1.northshore.edu,ou=northshore.edu http://northshore.edu,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=3 RESULT err=32 tag=101 nentries=0 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 SRCH base="cn=389ds1.northshore.edu http://389ds1.northshore.edu,ou=northshore.edu http://northshore.edu,o=NetscapeRoot" scope=0 filter="(objectClass=*)" attrs="* aci aci" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [04/Sep/2018:15:32:27 -0400] conn=1352071 op=5 ADD dn="cn=389ds1.northshore.edu http://389ds1.northshore.edu,ou=northshore.edu http://northshore.edu,o=NetscapeRoot" [04/Sep/2018:15:32:27 -0400] conn=1352071 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot" [04/Sep/2018:15:32:28 -0400] conn=1352071 op=5 RESULT err=32 tag=105 nentries=0 etime=1 csn=5b8eddcb000007b30000 [04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 UNBIND [04/Sep/2018:15:32:28 -0400] conn=1352071 op=6 fd=101 closed - U1

Cassandra Reed 978-762-4222 EDP Systems Analyst III North Shore Community College 1 Ferncroft Road, Danvers MA 01923

2206

Age (days ago)

2211

Last active (days ago)

389-users@lists.fedoraproject.org

12 comments

3 participants

tags (0)

participants (3)

Cassandra Reed
JESSE LUNT
Mark Reynolds