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?
Cassandra Reed
978-762-4222
EDP
Systems Analyst III
North Shore Community College
1 Ferncroft Road, Danvers MA 01923
:-) 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
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
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
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
|
