On 7/2/21 9:39 AM, Collins, Brian (CAI - Atlanta) wrote:
Thanks Mark. That is now done.
https://github.com/389ds/389-ds-base/issues/4825
Thanks!
An interesting side note here: even if I remove the reference to
auth02 in my fixdeferral.ldif and re-apply it, the reference to auth02
returns. On a whim, I added a third nsslapd-referral and appied
that. After a reboot, we had just auth01 and auth02 again.
Once a backend/suffix is replicated, the replication plugin apparently
controls the referrals on the backends (which makes sense). I'm not
sure why we don't honor the agreement's configuration. There could be a
good reason for it, but we need to look into it closer...
Regards,
Mark
Not sure whether that's helpful, but it sure baffled me.
Thanks again for the help!
*From: *Mark Reynolds <mreyno...@redhat.com>
*Reply-To: *"General discussion list for the 389 Directory server
project." <389-users@lists.fedoraproject.org>
*Date: *Friday, July 2, 2021 at 9:00 AM
*To: *"Collins, Brian (CAI - Atlanta)" <brian.coll...@coxautoinc.com>,
"General discussion list for the 389 Directory server project."
<389-users@lists.fedoraproject.org>
*Subject: *[389-users] Re: Replica's nsslapd-referral uri is ldap:
instead of ldap:
On 7/2/21 8:35 AM, Collins, Brian (CAI - Atlanta) wrote:
Thanks for the quick reply, Mark.
Also, thank you to you and the folks at Red Hat for all the work
in the newer releases. Two things stand out: dsconf and not
having to run X. There is much more, but those two are a great
benefit.
Thanks, that's nice to hear! Wait until the UI rewrite is done ;-)
So I executed the following, named fixreferral.ldif
dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-referral
nsslapd-referral:
ldaps://auth01.example.com:636/dc%3Dexample%2Cdc%3Dcom
<ldaps://auth01.example.com:636/dc%3Dexample%2Cdc%3Dcom>
nsslapd-referral:
ldaps://auth02.example.com:636/dc%3Dexample%2Cdc%3Dcom
<ldaps://auth02.example.com:636/dc%3Dexample%2Cdc%3Dcom>
Using: ldapmodify -x -D "cn=Directory Manager" -W -H
ldaps://auth04 <ldaps://auth04> -f fixreferral.ldif
Then issued: systemctl restart dirsrv@auth04
When I checked, however, it had reverted to:
# grep nsslapd-referral dse.ldif
nsslapd-referral: ldap://auth01.example.com:389/dc%3Dexample%2Cdc
<ldap://auth01.example.com:389/dc%3Dexample%2Cdc>
nsslapd-referral: ldap://auth02.example.com:389/dc%3Dexample%2Cdc
<ldap://auth02.example.com:389/dc%3Dexample%2Cdc>
BUT... dse.ldif.startOK has this:
nsslapd-referral: ldaps://auth01.example.com:636/dc%3Dexample%2Cd
<ldaps://auth01.example.com:636/dc%3Dexample%2Cd>
nsslapd-referral: ldaps://auth02.example.com:636/dc%3Dexample%2Cd
<ldaps://auth02.example.com:636/dc%3Dexample%2Cd>
So it would appear to be reverting AFTER the restart. Which makes
me think it's something that it is receiving from the supplier
possibly?
Ugh, so the replication plugin is probably rewriting it. Odd that it
"worked" in 1.3.x because I don't recall any changes around referrals
in a long time. We will need investigate it. Can you open a github
issue describing the issue, and how it's blocking password updates?
https://github.com/389ds/389-ds-base/issues/new/choose
<https://urldefense.com/v3/__https:/github.com/389ds/389-ds-base/issues/new/choose__;!!Gh9pqc0J0AYYLQ!c-sQ54m9S8ingFdnckT8B6YSqccEdtmt_-nUXmAlk3vcKslQ0DOAmui3sCF6ylQlj2VxhA$>
Thanks,
Mark
Thanks again,
Brian
*From: *Mark Reynolds <marey...@redhat.com>
<mailto:marey...@redhat.com>
*Date: *Thursday, July 1, 2021 at 8:22 PM
*To: *"General discussion list for the 389 Directory server
project." <389-users@lists.fedoraproject.org>
<mailto:389-users@lists.fedoraproject.org>, "Collins, Brian (CAI -
Atlanta)" <brian.coll...@coxautoinc.com>
<mailto:brian.coll...@coxautoinc.com>
*Subject: *Re: [389-users] Replica's nsslapd-referral uri is ldap:
instead of ldap:
Hi Brian,
You can just change nsslapd-referral attribute to use ldaps
instead of ldap.
Now you "should" be able to do that in the console, but I just
found out that there is a bug in the console where we don't
actually grab the referrals from the mapping tree entry. <sigh>
Glad I found it now because the cockpit console is going through a
rewrite (to migrate to Patternfly 4). So I will fix that, but it
doesn't help you today.
So for now you will need to use ldapmodify to change the
nsslapd-referral attribute. I would say to use dsconf but it is
also broken for properly setting referrals <sigh again>. Once I
fix dsconf it would work like this:
#dsconf slapd-supplier1 backend suffix set userroot --del-referral
ldap://localhost:636 <ldap://localhost:636>
#dsconf slapd-supplier1 backend suffix set userroot --add-referral
ldaps://localhost:636 <ldaps://localhost:636>
Right now dsconf updates the referral on the wrong entry :-(
We'll get this all fixed up!
HTH,
Mark
On 7/1/21 6:04 PM, Collins, Brian (CAI - Atlanta) wrote:
Good day,
I am doing prep work for replacing our older 389 servers
(1.3.8) running on RHEL 7 with newer ones on RHEL 8 and 1.4.4.
I have the two RHEL 7 boxes in a multi-master replication setup.
For this phase of testing I have one read-only replica on
1.4.4, as a consumer to the two current servers. I set up a
Linux client to login using SSSD, bound to the consumer. It
works fine except when I want to change passwords. I was
getting "Operation requires a secure connection." After a lot
of digging, I think I found the culprit there: on the
consumer, in "dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config" the nsslapd-referral uri for my two current
servers is ldap: instead of ldaps:. Indeed, in the cockpit
console, the Remote RUV list shows both servers as ldap:.
But on the two suppliers, the old servers, the referral uri
is ldaps.
When I set up the replication agreement for the new consumer,
I did it just as I did for the current setup, so I don't feel
like that's where I went wrong.
Thanks in advance for any pointers,
Brian Collins
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1vE8XadpQ$>
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guidelines__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1s_zfh7yQ$>
List
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
<https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1ulQDpt-g$>
Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
<https://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1vN_sCmBg$>
--
Directory Server Development Team
--
Directory Server Development Team
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Directory Server Development Team
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
