aserver-4.10.1-6.el9.noarch
>>> > python3-libipa_hbac-2.8.2-2.el9.x86_64
>>> > sssd-ipa-2.8.2-2.el9.x86_64
>>> >
>>> > current master versions
>>> > [nicholas.cross@ipa008 ~]$ rpm -qa | grep ipa |
gt; >
> > Hi,
> >
> > the replica-conncheck error means that a call to
> > server_conncheck reached the wrong server.
> > ipa-replica-conncheck performs multiple checks:
> >
ver-common-4.10.0-8.el9_1.noarch
>>>> ipa-server-dns-4.10.0-8.el9_1.noarch
>>>> libipa_hbac-2.7.3-4.el9_1.3.x86_64
>>>> python3-ipaclient-4.10.0-8.el9_1.noarch
>>>> python3-ipalib-4.10.0-8.el9_1.noarch
>>>> python3-ip
Replying to myself here and asking additional questions.
Knowing that the original issues were that 1. i could not conn-check
successfully and 2. kinit. The kinit issue was fixed with the SID/PAC fix.
i ran `ipa-ca-install --debug --skip-conncheck` just for the heck if it and
it tells me it
, another server is tried (in this case, the replica
>>> launches server_conncheck on itself), but there is a security that ensures
>>> the right server is handling the call.
>>> The logs shows that the connection fails because of SASL auth failure:
>>> 2023-05-22T18
he is empty)
>
> Are you able to do kinit -kt /etc/krb5.keytab host/@
> on the replica? And then kvno HTTP/@ ?
> flo
>
> On Tue, May 23, 2023 at 9:55 AM Nicholas Cross via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> That was the /var/l
Thanks, the kinit issue is now sorted.
These helped:
https://access.redhat.com/solutions/394763
ldapsearch -LLL -b "dc=ad,dc=companyx,dc=fm" "(objectclass=person)"
ipaNTSecurityIdentifier
ldapsearch -LLL -b "dc=ad,dc=companyx,dc=fm" "(objectclass=posixgroup)"
gidNumber
update one single group
icholas Cross via FreeIPA-users wrote:
> >Sorry i added far too much there.
> >
> >here is a slightly less when i grep for my name
> >
> >
> >
> >[root@ipa011 ~]# tail -f /var/log/krb5kdc.log | grep nicholas
> >May 23 10:55:47 ipa011.ad.companyx.f
Sorry i added far too much there.
here is a slightly less when i grep for my name
[root@ipa011 ~]# tail -f /var/log/krb5kdc.log | grep nicholas
May 23 10:55:47 ipa011.ad.companyx.fm krb5kdc[4304](info): AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20),
Flo, Thanks for this.
I rebuilt the server again. Did the ipa-replica-install with no DNS or CA
install, so just replica.
This installed fine. then ran your tests
[root@ipa011 ~]# kinit -V -kt /etc/krb5.keytab
host/ipa011.ad.companyx...@ad.companyx.fm
Using existing cache: 0
Using principal:
That was the /var/log/ipareplica-conncheck.log log file
it does looks like a DNs issue, but im not sure where.
dns resolves the host fine on the host
[root@ipa011 ~]# host ipa011
ipa011.ad.companyx.fm has address 10.32.225.7
[root@ipa011 ~]# grep ipa /etc/ipa/default.conf
host =
My apologies, it has been a long day trying to debug this.
pastebin link to debug logs. https://pastebin.com/U1igJWST
versions replica 4.10.1-6. master 4.10.0-8
# replica
[root@ipa011 ~]# rpm -qa | grep ipa | sort
almalinux-logos-ipa-90.5.1-1.1.el9.noarch
ipa-client-4.10.1-6.el9.x86_64
We are in the process of adding a new a CA replica.
We install in the following fashion:
1. ipa-replica-install
2. ipa-dns-install
3. ipa-ca-install
All goes well until step3. ipa-ca-install, where we get the error:
2023-05-22T16:51:30Z ERROR ERROR: Remote master check failed with following
We found that we have a cert profile that was deleted in the ui and then we
attempted to re-create it, but it will not.
ipa: ERROR: Request failed with status 409: Non-2xx response from CA REST API:
409. Unable to create profile: Profile already exists
The profile does not show in the UI or
Just an update on this.
Came back from the long weekend and 50% of our servers (3) were not responding,
the dirsrv was crashing everytime it had an update from the CA master (we could
not figure out why). If we closed the firewall between replica and CA master
the servers stayed up.
After a
Ah got it! Wonderful.
The trick as to run the topologysegement-del on the same server it was on.
It seems i am moving forward with this now - thanks.
#
# To remove the topology segment, which removed the replica agreement
#
#
# Show the bad replication agreement
#
# ipa-replica-manage list
Tested this again making sure that dirsrv is not running and the replica record
is back.
I am obviously doing something wrong. My steps are below. I appreciate your
time on this.
#
# check dirsrv is currently running
#
[root@ipa006 ~]# ps aux | grep dirsrv
dirsrv 3221639 31.4 5.4
Shutdown dirsrv
backed up dse.ldif
edited the ldif
restarted dirsrv
replication agreement came back!
Is it being sync'ed from some where else? another file?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an
Thanks for the tips. I'll run the trace on Monday.
Also i'll edit the ldif Monday too.
Distro: alma9
# rpm -qa | grep ipa | sort
almalinux-logos-ipa-90.5.1-1.1.el9.noarch
ipa-client-4.10.0-8.el9_1.x86_64
ipa-client-common-4.10.0-8.el9_1.noarch
ipa-common-4.10.0-8.el9_1.noarch
I think i have a handle on this now.
There are a number of issues that i am now aware of.
1. old replication agreement to oldbox1 on newbox6
2. corrupt RUVs, giving the impression of Ghost Replicas.
For #1 i normally can delete these fine with a ldap command. BUT! running
this crashes the
I am on a long journey upgrading from a mixture of different versions of
freeipa to the lastest and i am almost there, currently on 4.10.
After removing some older replicas yesterday, a new replica had a fault and
we had to restart dirsrv.
When it came back up we saw we have ghost replicas across
21 matches
Mail list logo
