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.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 <mreyno...@redhat.com
<mailto:mreyno...@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
<mreyno...@redhat.com <mailto:mreyno...@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
<mreyno...@redhat.com <mailto:mreyno...@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
<mreyno...@redhat.com <mailto:mreyno...@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-le...@lists.fedoraproject.org
<mailto:389-users-le...@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
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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
