[Freeipa-users] Re: Untrusted Peer certificate after CA renewal
Thank you Flo. I confirmed that ldapsearch -LLL -D 'cn=directory manager' -W -b 'uid=ipara,ou=people,o=ipaca' and serial number are the same than the ra-agent.pem. [root@ds01 ~]# ldapsearch -LLL -D 'cn=directory manager' -W -b 'uid=ipara,ou=people,o=ipaca' Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser uid: ipara sn: ipara cn: ipara usertype: agentType userstate: 1 userCertificate:: MIIDbz[...]Aq+3Ah9Hw== description: 2;1342111857;CN=Certificate Authority,O=ARTERIS.COM;CN=IPA RA,O=ARTERIS.COM When we did ipa-certupdate, at the beginning of all of this, we got this: ### [root@ds01 ~]# ipa-certupdate trying https://ds01.EXAMPLE.com/ipa/session/json [try 1]: Forwarding 'schema' to json server 'https://ds01.EXAMPLE.com/ipa/session/json' trying https://ds01.EXAMPLE.com/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ds01.EXAMPLE.com/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ds01.EXAMPLE.com/ipa/json' failed to update EXAMPLE.COM IPA CA in /etc/dirsrv/slapd-EXAMPLE-COM: Command '/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' returned non-zero exit status 255 failed to update EXAMPLE.COM IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d /etc/httpd/alias -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255 failed to update EXAMPLE.COM IPA CA in /etc/ipa/nssdb: Command '/usr/bin/certutil -d /etc/ipa/nssdb -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/ipa/nssdb/pwdfile.txt' returned non-zero exit status 255 Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful ## And ended up updating the entries manually so IPA can start, otherwise it was failing to start Checking my notes, there is one certificate in LDAP that is different and seems to be the old CA certificate and could be the culprit: # [root@ds01 ~]# ldapsearch -x -D 'cn=Directory manager' -W -b 'cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # EXAMPLE.COM IPA CA, certificates, ipa, etc, EXAMPLE.com dn: cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com ipaConfigString: ipaCa ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.COM ipaKeyTrust: trusted cACertificate;binary:: MIID[..]1eAMZu0AaUw== ipaPublicKey:: MIIBIj[..]wIDAQAB ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;1 objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top cn: EXAMPLE.COM IPA CA ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4 ipaKeyExtUsage: 1.3.6.1.5.2.3.5 ipaKeyExtUsage: 1.3.6.1.5.2.3.4 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ## Looks like this one should be the new ca.crt. How do I get the public key that goes with new certificate? In the meantime, we are searching the log to see if we can find issues with IPA RA. Steph -Original Message- From: Florence Blanc-Renaud [mailto:f...@redhat.com] Sent: Monday, March 12, 2018 12:08 PM To: Stéphane Mehat ; FreeIPA users list Cc: Bhavin Vaidya Subject: Re: [Freeipa-users] Untrusted Peer certificate after CA renewal On 03/12/2018 06:52 PM, Stéphane Mehat wrote: > Thank you Flo! > > Yes I checked all certificates with "openssl x509 -noout -text" as suggested > in one of your post. We have most recent one. > > We did not check curl as we ran an rpm update to make sure we have all same > version of IPA across the board. > > [root@ds01 ~]# curl -V > curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.28.4 > zlib/1.2.7 libidn/1.28 libssh2/1.4.3 > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps > pop3 pop3s rtsp scp sftp smtp smtps telnet tftp > Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL > libz unix-sockets > > Looks like they have 7.58 now... we are going to give it a try. > > How do I know if connected to NSS? That is more likely connect to OpenSSL. Hi, the output of curl -V shows "NSS/3.28.4" meaning that is was compiled with NSS support, so you're good from this point of view. > > Thank you for confirming regarding ipaCert? We have both key and PEM. I am > removing that entry then. > Are we still supposed to have IPA CA agent certificates or those have been > removed? Certificate published at uid=admin,ou=people,o=ipaca are expired, > but I don't know how to renew these (assuming that would be the culprit, but > could be as this is the user we are using for the install). The e
[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000
Hi Harald,
What version of DS are you running ?
We have a reproducer (not systematic) for versions before
https://bugzilla.redhat.com/show_bug.cgi?id=1516309 but we have not
reproduced it since then, you may need to upgrade.
best regards
thierry
On 03/12/2018 05:10 PM, Ludwig Krispenz wrote:
Hi,
to get rid of this ruv entry with replicaid 7 you could try to run the
cleanallruv task directly. On any server (and onöy on one) run
ldapmodify . -D "cn=directory manager"
|dn: cn=clean 7, cn=cleanallruv, cn=tasks, cn=config changetype: add
objectclass: extensibleObject replica-base-dn:
replica-id: 7 replica-force-cleaning: yes |
|But I would like to understand how you did get in|to this state, we
have seen this occasionly, but have no reproducer. Unfortunately the
csn for replicaid 7 is from Jan, 19th 2017 11:01:16 - so you will
probably not remember
||
On 03/12/2018 03:55 PM, Harald Dunkel via FreeIPA-users wrote:
Hi folks,
somehow my ipa servers became out of sync. ipa4 has an
additional host entry, not known on the others. On
examining I stumbled over this:
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
These RUVs are dangling and will be removed:
Host: ipabak.ac.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa1.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa0.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa3.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa4.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa2.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Proceed with cleaning? [no]: yes
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Clean the Replication Update Vector for ipabak.ac.example.de:389
Background task created to clean replication data. This may take a
while.
This may be safely interrupted with Ctrl+C
Cleanup task created
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
No dangling RUVs found
[root@ipa0 ~]# ipa-replica-manage list-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090
The ruvs are the same on all 6 hosts (AFAICS), so I wonder how I could
fix this?
Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Using different distros
Thanks for the response, I don't think we will be issuing SSL certs from FreeIPA to systems in AWS running Amazon Linux 2. On Monday, March 12, 2018 10:54 AM, Rob Crittenden via FreeIPA-users wrote: Andrew Meyer via FreeIPA-users wrote: > I have emailed in previously fro issues w/ Amazon Linux 2 as a replica > server but I am wondering If I can use Amazon Linux 2 as a client > machine to FreeIPA. Will I run into the same issues with SSL (NSS vs > OpenSSL) that I did with the replica? Hard to say without knowing what their packaging looks like. That said the client is mostly a tool to help ensure the environment is sane and if so writes a bunch of configuration files. SSSD does all the heavy lifting post-install. So there is perhaps some more room for differences. I'll note that the client uses curl as well via xmlrpc-c during enrollment and using certmonger assuming you get a cert on this host. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000
Hi,
to get rid of this ruv entry with replicaid 7 you could try to run the
cleanallruv task directly. On any server (and onöy on one) run
ldapmodify . -D "cn=directory manager"
|dn: cn=clean 7, cn=cleanallruv, cn=tasks, cn=config
changetype: add
objectclass: extensibleObject
replica-base-dn:
replica-id: 7
replica-force-cleaning: yes
|
|But I would like to understand how you did get in|to this state, we
have seen this occasionly, but have no reproducer. Unfortunately the csn
for replicaid 7 is from Jan, 19th 2017 11:01:16 - so you will probably
not remember
||
On 03/12/2018 03:55 PM, Harald Dunkel via FreeIPA-users wrote:
Hi folks,
somehow my ipa servers became out of sync. ipa4 has an
additional host entry, not known on the others. On
examining I stumbled over this:
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
These RUVs are dangling and will be removed:
Host: ipabak.ac.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa1.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa0.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa3.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa4.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa2.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Proceed with cleaning? [no]: yes
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Clean the Replication Update Vector for ipabak.ac.example.de:389
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Cleanup task created
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
No dangling RUVs found
[root@ipa0 ~]# ipa-replica-manage list-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090
The ruvs are the same on all 6 hosts (AFAICS), so I wonder how I could
fix this?
Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Using different distros
Andrew Meyer via FreeIPA-users wrote: > I have emailed in previously fro issues w/ Amazon Linux 2 as a replica > server but I am wondering If I can use Amazon Linux 2 as a client > machine to FreeIPA. Will I run into the same issues with SSL (NSS vs > OpenSSL) that I did with the replica? Hard to say without knowing what their packaging looks like. That said the client is mostly a tool to help ensure the environment is sane and if so writes a bunch of configuration files. SSSD does all the heavy lifting post-install. So there is perhaps some more room for differences. I'll note that the client uses curl as well via xmlrpc-c during enrollment and using certmonger assuming you get a cert on this host. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: What does migration mode actually do?
Florence Blanc-Renaud via FreeIPA-users wrote: > On 03/09/2018 10:26 AM, Roderick Johnstone via FreeIPA-users wrote: >> On 09/03/2018 09:13, Florence Blanc-Renaud wrote: >>> On 03/09/2018 09:41 AM, Roderick Johnstone via FreeIPA-users wrote: Hi I'm using migration mode (ipa config-mod --enable-migration=true) to help migrate from one freeipa instance to another. I wasn't able to find any docs on what enabling migration mode actually does, exactly. Can anyone supply details please? Thanks. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org >>> >>> Hi, >>> >>> the migration mode allows to add an entry with a pre-hashed password. >>> >>> When this mode is disabled, this operation would be refused because >>> IPA needs a clear-text password in order to run password policy >>> checks and generate kerberos keys. >>> >>> HTH, >>> Flo >> >> Hi Flo >> >> So, why wouldn't you want to have that enabled all the time. >> >> ie are there any other consequences of having this enabled. >> > > When migration mode is enabled, the ldap server accepts to modify a > password using a pre-hashed value (the userPassword attribute of the > user entry). As the value is not clear-text, it is not possible to run > password policy checks (for instance does it contain enough characters, > was it already in the password history...) => not as secure as the > sysadmin intended. > > The second issue is that the kerberos keys (stored in the > krbprincipalkey of the user attribute) cannot be generated from a hash > value, the algorithm needs a clear value. As a consequence, kerberos > authentication would not succeed because it is based on krbprincipalkey. > > This is why the migration procedure requires to instruct users to login > to the migration web page, so that they enter a new password that will > re-generate their kerberos keys (see step 10 in [1]). > > Hope this clarifies, > Flo > > [1] > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/mig-ldap-to-idm SSSD also checks this value and will authenticate over LDAP then set the Kerberos credentials. This is similar in practice to using the web page but without requiring user intervention. Without this flag enabled having only and LDAP password will fail authentication. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: [SSSD-users] Re: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
TomK wrote: > On 3/7/2018 1:11 PM, Rob Crittenden wrote: > Hey Rob, > > When starting idmapd or stopping it, logs on the LDAP server don't > change. But UID and GID's change to nfsnobody when I set Nobody-User > and Nobody-Group to nfsnobody in /etc/idmapd.conf . I don't know that merely restarting the service is going to spark queries against LDAP. You'd probably need to do something to provoke that (like doing an ls). > [General] > Verbosity = 9 > Domain = nix.my.dom > [Mapping] > Nobody-User = nfsnobody > Nobody-Group = nfsnobody > [Translation] > [Static] > [UMICH_SCHEMA] > LDAP_server = idmipa01.nix.my.dom > LDAP_base = cn=accounts,DC=NIX,DC=MY,DC=DOM > LDAP_people_base = DC=NIX,DC=MY,DC=DOM > LDAP_group_base = DC=NIX,DC=MY,DC=DOM The people basedn should probably be cn=users,cn=accounts,... and the group base cn=groups,cn=accounts,... Unles it cleverly smashes that together with LDAP_base, I'm not sure what it does. The 389-ds access logs will tell you if it is trying at all (note the logs are write-buffered so you won't see immediate updates). If you have compat enabled then idmapd may be getting multiple entries, one from cn=compat and one from the main tree and that could be confusing it. rob > > Cheers, > Tom > >> TomK via FreeIPA-users wrote: >>> Hey Guy's, >>> >>> Getting below message which in turn fails to list proper UID / GID on >>> NFSv4 mounts from within an unprivileged account. All files show up with >>> owner and group as nobody / nobody when viewed from the client. >>> >>> Is there a way to structure /etc/idmapd.conf to allow for proper UID / >>> GID resolution? Or perhaps another solution? >>> >>> >>> [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" >>> [General] >>> Verbosity = 7 >>> Domain = nix.my.dom >>> [Mapping] >>> [Translation] >>> [Static] >>> [UMICH_SCHEMA] >>> LDAP_server = ldap-server.local.domain.edu >>> LDAP_base = dc=local,dc=domain,dc=edu >>> [root@client01 etc]# >>> >>> Mount looks like this: >>> >>> nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 >>> (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) >>> >>> >>> >>> /var/log/messages >>> >>> Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid >>> value: t...@my.dom@localdomain timeout 600 >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling >>> nsswitch->name_to_uid >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name >>> 't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname >>> '(null)' >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name >>> 't...@my.dom@localdomain' does not map into domain 'nix.my.dom' >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: >>> nsswitch->name_to_uid returned -22 >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return >>> value is -22 >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling >>> nsswitch->name_to_uid >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name >>> 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: >>> nsswitch->name_to_uid returned 0 >>> Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return >>> value is 0 >>> Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid >>> value: t...@my.dom@localdomain timeout 600 >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling >>> nsswitch->name_to_gid >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: >>> nsswitch->name_to_gid returned -22 >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return >>> value is -22 >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling >>> nsswitch->name_to_gid >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: >>> nsswitch->name_to_gid returned 0 >>> Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return >>> value is 0 >>> Mar 6 00:17:31 client01 systemd-logind: Removed session 23. >>> >>> >>> >>> >>> Result of: >>> >>> systemctl restart rpcidmapd >>> >>> /var/log/messages >>> --- >>> Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on >>> demand... >>> Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on >>> demand. >>> Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping >>> service... >>> Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS >>> configuration... >>> Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration. >>> Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping >>> service... >>> Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain: >>> nix.my.dom >>> Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list: >>> 'NIX.MY.DOM' >>> Mar 5 23:48:51 client01 rpc.idmapd: rp
[Freeipa-users] ipa-replica-manage: unable to decode: {replica 7} 58809c7c000300070000 58809c7c000300070000
Hi folks,
somehow my ipa servers became out of sync. ipa4 has an
additional host entry, not known on the others. On
examining I stumbled over this:
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
These RUVs are dangling and will be removed:
Host: ipabak.ac.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa1.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa0.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa3.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa4.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Host: ipa2.example.de
RUVs:
id: 11, hostname: ipabak.ac.example.de
CS-RUVs:
Proceed with cleaning? [no]: yes
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Clean the Replication Update Vector for ipabak.ac.example.de:389
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Cleanup task created
[root@ipa0 ~]# ipa-replica-manage clean-dangling-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
No dangling RUVs found
[root@ipa0 ~]# ipa-replica-manage list-ruv
unable to decode: {replica 7} 58809c7c00030007 58809c7c00030007
Replica Update Vectors:
ipa0.example.de:389: 12
ipa2.example.de:389: 5
ipa1.example.de:389: 4
ipa4.example.de:389: 8
ipa3.example.de:389: 6
ipabak.ac.example.de:389: 13
Certificate Server Replica Update Vectors:
ipa0.example.de:389: 1095
ipa2.example.de:389: 97
ipa1.example.de:389: 96
ipabak.ac.example.de:389: 1090
The ruvs are the same on all 6 hosts (AFAICS), so I wonder how I could
fix this?
Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Using different distros
I have emailed in previously fro issues w/ Amazon Linux 2 as a replica server but I am wondering If I can use Amazon Linux 2 as a client machine to FreeIPA. Will I run into the same issues with SSL (NSS vs OpenSSL) that I did with the replica? Thank you,Andrew___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
