Install client fails in Ubuntu 22.04
by Gustavo Berman
Hello there!
Ubuntu 18.04 (and previous ones) works just fine
In Ubuntu 22.04 I'm trying to execute ipa-client install but it fails with:
root@fisica75:~# ipa-client-install
This program will set up IPA client.
Version 4.9.8
WARNING: conflicting time&date synchronization service 'ntp' will be
disabled in favor of chronyd
Discovery was successful!
Do you want to configure chrony with NTP server or pool address? [no]:
Client hostname: fisica75.fisica.cabib
Realm: FISICA.CABIB
DNS Domain: fisica.cabib
IPA Server: ipaserver.fisica.cabib
BaseDN: dc=fisica,dc=cabib
Continue to configure the system with these values? [no]: yes
Synchronizing time
No SRV records of NTP servers found and no NTP server or pool address was
provided.
Using default chrony configuration.
Attempting to sync time with chronyc.
Time synchronization was successful.
User authorized to enroll computers: tavo
Password for tavo(a)FISICA.CABIB:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=FISICA.CABIB
Issuer: CN=Certificate Authority,O=FISICA.CABIB
Valid From: 2014-01-14 12:56:57
Valid Until: 2034-01-14 12:56:57
Enrolled in IPA realm FISICA.CABIB
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm FISICA.CABIB
cannot connect to 'https://ipaserver.fisica.cabib/ipa/json': [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch,
certificate is not valid for 'ipaserver.fisica.cabib'. (_ssl.c:997)
The ipa-client-install command failed. See /var/log/ipaclient-install.log
for more information
root@fisica75:~#
There is no Hostname mismatch for the server certificate. It has been
working just fine for years with multiple distros as clients. I can access
the website with the same URL and cert is just fine.
Any ideas?
Thanks!
--
Gustavo Berman
1 month, 1 week
FreeIPA CA failing to login with new admin user
by Stasiek Michalski
Hello,
I installed FreeIPA replica on 4.8.4 on CentOS 8 from 4.4.4 from Fedora
25 with `ipa-replica-install --setup-dns --auto-forwarders`, without
`--setup-ca` due to errors, which went fine. I do want to install CA
though, which failed when I did `--setup-ca` and then later
`ipa-ca-install` with the following error:
```
[4/29]: creating installation admin user
Unable to log in as uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca on ldap://freeipa.infra.opensuse.org:389
[hint] tune with replication_wait_timeout
[error] NotFound: uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca did not replicate to ldap://freeipa.infra.opensuse.org:389
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
```
Obviously I did try try extending the timeout based on that, but I don't
think that was helpful in the end, considering the logs produced by the
old server:
httpd access_log
```
192.168.47.90 - - [23/Jul/2020:00:25:36 +0000] "GET /ca/rest/account/login HTTP/1.1" 401 994
```
server process in journal
```
SSLAuthenticatorWithFallback: Authenticating with BASIC authentication
Invalid Credential.
at com.netscape.cmscore.authentication.PasswdUserDBAuthentication.authenticate(PasswdUserDBAuthentication.java:167)
at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:63)
at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:78)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:94)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:37)
at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:98)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:47)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:579)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502)
at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:877)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1539)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1495)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority"
SSLAuthenticatorWithFallback: Fallback auth return code: 401
SSLAuthenticatorWithFallback: Result: false
```
and from pki logs
```
Failed to authenticate as admin UID=admin-freeipa2.infra.opensuse.org. Error: netscape.ldap.LDAPException: error result (49)
```
I don't particularly know how to proceed from here, since those errors
don't mean much to me. I see however it's not just me having issues with
`ipa-ca-install` at least similar to this one (although by the looks of
it, the reason is already different ;)
Thanks in advance for trying,
LCP [Stasiek]
https://lcp.world/
1 month, 2 weeks
'transportCert cert-pki-kra' mix up
by GH
I've got two ancient (3.1?) IPA servers that have been upgraded over time. Last January things got really goofy with certificates and I got it all sorted. However, now I've got an old issue creeping back in. The 'transportCert cert-pki-kra' is mismatched between the CS.cfg and the tracked certificate. This is a multi-master setup. The signing master seems to be the one that's off. It's tracking the updated original 'transportCert cert-pki-kra' certificate. However, the "secondary" master is tracking a newly generated 'transportCert cert-pki-kra', which is also what both CS.cfg's are referencing. Neither one of the certificates is expired. Everything else seems to be in working order. Here is ipa-healthcheck's only relevant error:
"source": "ipahealthcheck.dogtag.ca",
"kw": {
"msg": "Certificate 'transportCert cert-pki-kra' does not match the value of ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"directive": "ca.connector.KRA.transportCert",
"key": "transportCert cert-pki-kra"
},
So, what should I copy where to get this sorted? It seems like the updated original 'transportCert cert-pki-kra' should be copied into the CS.cfg and then manually scp the NSS files from "primary" to "secondary"? What commands would you use to do this? I've got a lot of commands noted and am beginning to get confused as to which ones should be used to get this sorted. Thanks.
2 months
IPA-Error 903: InternalError on Certificate page
by Nico Maas
Dear all,
I am using FreeIPA, Version: 4.8.4 on CentOS 8
ipa-client.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-client-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-healthcheck-core.noarch 0.4-4.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server.x86_64 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server-common.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
ipa-server-dns.noarch 4.8.4-7.module_el8.2.0+374+0d2d74a1 @AppStream
Whenever I open the "Authentication" tab in the freeIPA webserver, I get the error
"IPA-Error 903: InternalError. An internal error has happend".
Retry does not help, within Authentication I can use all tabs, except from the Authentication -> Certificate -> Certificate one. This one gives the error. I can also not search for a certificate. The other areas of Authentication -> Certificate (Certificate Profiles, CA ACLS, Certificate Authorities) work without problems.
As a test I cloned the machine and updated it to the latest CentOS 8 version with a newer freeIPA version on it, but that did not solve the problem and I scrapped this vm and idea again.
Any idea on how to resolve the issue / what could be broken?
Which logs and things would be useful to look into?
Thanks a lot for your help and have a nice day
Nico
2 months, 3 weeks
LoadBalancer vs. DNS
by Ronald Wimmer
IPA heavily relies on DNS entries. In my opinion, this design makes it
more difficult to quickly disable one or more IPA servers - especially
when using IPA in combination with external DNS (managed by a different
department).
Would it be possible to put all relevant DNS entries on a Loadbalancer
VIP and let the LB resolve to all IPA servers?
e.g. instead of having 8 DNS entries for
_kerberos-master._tcp.linux.oebb.at for every of our 8 IPA servers I
would have just one _kerberos-master._tcp.linux.oebb.at entry. The LB
would distribute requests in such a setup.
Is it possible to do that or would it break some IPA functionality?
Cheers,
Ronald
3 months
Ubuntu 20.04 client can't find names for some group IDs
by Ranbir
Hi Everyone,
I migrated an Ubuntu 20.04 client from NIS authentication to an
AlmaLinux 9 IdM domain. I purged the NIS package, installed the
freeipa-client, successfully enrolled it into the domain and now when I
login via ssh, I get these messages:
groups: cannot find name for group ID 1762200513
groups: cannot find name for group ID 1762213360
groups: cannot find name for group ID 1762225405
groups: cannot find name for group ID 1762243097
groups: cannot find name for group ID 1762243100
groups: cannot find name for group ID 1762263161
groups: cannot find name for group ID 1762313267
groups: cannot find name for group ID 1762313342
groups: cannot find name for group ID 1762313405
groups: cannot find name for group ID 1762358745
I can lookup the group names from an idm server. Also, I think this
groups lookup problem is the cause of slow logins on this Ubuntu
client.
On other clients, I get similar messages when I use the "groups"
command to see which groups I'm a member of.
I've never experienced this before in an idm environment. What's
causing the issue?
--
Ranbir
5 months, 3 weeks
IdM with trust relationship with Samba AD DC - User accounts with passwords expired
by Mateo Duffour
Hi,
We currently have an IdM installation with a trust relationship with a Samba AD DC. Our user accounts reside on Samba AD DC, we dont have user accounts on IdM.
We are having a problem with Samba user acounts that have its passwords expired.
When we try to login with an ubuntu IdM client with one of those accounts, it fails and asks again for password.
The behaviour we are expecting is that Ubuntu should ask for a password change.
Thanks, best regards.
Lic. Mateo Duffour
Unidad Informática
2901.40.91
[ http://maps.apple.com/?q=18%20de%20julio%20985%20-%20Piso%204,Montevideo,... | 18 de julio 985 - Piso 3, Montevideo, Uruguay ]
[ http://www.fnr.gub.uy/ | ]
No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y la información adjunta al mismo está dirigido exclusivamente a su destinatario. Puede contener información confidencial, privilegiada o de uso restringido, protegida por las normas. Si Ud. recibió este e-mail por error, por favor, sírvase notificarle a quien se lo envió y borrar el original. Cualquier otro uso del e-mail por Ud. está prohibido.
5 months, 4 weeks
Potential API change for FreeIPA plugin writers
by Alexander Bokovoy
Hi,
as you have probably noticed in a thread we had with Leo on
freeipa-users@ about FreeIPA plugin development, we hadn't had
consistency in handling boolean types between LDAP and IPA Python API
level. A change is coming that would make 'native' boolean types used in
both worlds. If your plugins rely on Bool() parameter handling in
FreeIPA, your code might be affected. If your scripts using output of
IPA API rely on case-sensitive output, you might need to adjust your
code.
If not, you can skip this email.
Pull request https://github.com/freeipa/freeipa/pull/6294 turns handling
of boolean types to be native to each side:
- in LDAP, TRUE and FALSE strings used to represent the values
- in Python, native True and False constants of bool type will be used
to represent an LDAP boolean.
Prior to PR#6294, when an LDAP attribute with a boolean syntax was read
from LDAP, its representation in IPA Python code was either 'TRUE'
or 'FALSE' string. This created a bit of inconvenience:
- Python code had to explicitly compare a value to 'TRUE' or 'FALSE',
- Web UI JavaScript code had to use a radio-box where a simple checkbox
would be enough
- JavaScript plugin code would need to handle all types of 'TRUE',
'FALSE', 1, 0, true, false, none in every place where a boolean type
would be enough
After PR#6294 is merged, IPA Python code will use Python bool type.
JSON-RPC response to an IPA API command request would produce a simple
'true' or 'false' instead of ["TRUE"] or ["FALSE"] elements. This means,
for example, that in the following command
ipa dnszone-show ipa.test
instead of
"idnsallowdynupdate": [
"TRUE"
],
one would get
"idnsallowdynupdate": [
true
],
and the output of 'ipa dnszone-show ipa.test' would have 'True' instead
of 'TRUE' (and False instead of 'FALSE'):
$ ipa dnszone-show ipa.test
Zone name: ipa.test.
Active zone: True
Authoritative nameserver: idm.ipa.test.
Administrator e-mail address: hostmaster.ipa.test.
SOA serial: 1654159048
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
BIND update policy: grant IPA.TEST krb5-self * A; grant IPA.TEST krb5-self * AAAA; grant IPA.TEST krb5-self * SSHFP;
Dynamic update: True
Allow query: any;
Allow transfer: none;
If your scripts rely on the case-sensitive output, you'd need to fix
them. IPA tools already able to handle the changes so they are
backward-compatible.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
6 months
Dnssec rejected by Cloudflair, Google, accepted by Verizon, AT&T
by Harry G. Coin
I have a dnssec enabled domain that passes all the verisign and related
dnssec tests (all green, no errors) and dns sources like AT&T and
Verizon. But it fails at some popular dns servers like google and
cloudflair. I'd appreciate what anyone can make of that, there are no
obvious debugging directions when verisgn says 'all good'. If I turn
on the 'cdflag' most all of https://dnschecker.org/#A/quietfountain.com
works. Turn it off, and some report problems. Some clues most welcome!
Harry Coin
Here's Quad9, for example:
[root@registry1 ~]# dig @9.9.9.9 quietfountain.com
; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @9.9.9.9 quietfountain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45758
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;quietfountain.com. IN A
;; ANSWER SECTION:
quietfountain.com. 43200 IN A 147.135.121.120
quietfountain.com. 43200 IN A 51.81.131.192
;; Query time: 1463 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Tue Jul 26 17:53:39 CDT 2022
;; MSG SIZE rcvd: 78
But, here's cloudflair and google:
[root@registry1 ~]# dig @1.1.1.1 quietfountain.com
; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @1.1.1.1 quietfountain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64113
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for
quietfountain.com.)
;; QUESTION SECTION:
;quietfountain.com. IN A
;; Query time: 2197 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jul 26 17:51:22 CDT 2022
;; MSG SIZE rcvd: 103
[root@registry1 ~]# dig @8.8.8.8 quietfountain.com
; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @8.8.8.8 quietfountain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;quietfountain.com. IN A
;; Query time: 2303 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jul 26 17:51:35 CDT 2022
;; MSG SIZE rcvd: 46
6 months
Ubuntu uses /etc/apache2/nssdb instead of the /etc/httpd/alias service and the certificate store.
by roy liang
> I made the following soft link
> ln -s /etc/apache2/nssdb /etc/httpd/alias
> But return code 77 as well, so what do I need to do?
>
> root@migration-ipa-65-186:/.ipa/log# tailf renew.log
> 2022-04-09T16:02:13Z 21810 MainThread ipa DEBUG stderr=* Trying
> 10.12.65.186...
> * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates
> will not work.
> * Closing connection 0
> GET
> "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro..."
> code = 77
> code_text = "Problem with the SSL CA cert (path? access rights?)"
> results = "(null)"
>
> 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Initializing principal
> host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab
> /etc/krb5.keytab
> 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG using ccache
> /var/run/certmonger/tmp-FYfJPZ/ccache
> 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Attempt 1/1: success
> 2022-04-09T16:02:22Z 21811 MainThread ipa DEBUG Loading StateFile from
> '/var/lib/ipa/sysrestore/sysrestore.state'
> 2022-04-09T16:02:23Z 21811 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache
> 2022-04-09T16:02:23Z 21811 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG retrieving schema for SchemaCache
> url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389
> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f307a537290>
> 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG Starting external process
> 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG
> args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv
> 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG Process finished, return
> code=3
> 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG stdout=Error 77 connecting
> to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...:
> Problem with the SSL CA cert (path? access rights?).
>
> 2022-04-09T16:02:24Z 21811 MainThread ipa DEBUG stderr=* Trying
> 10.12.65.186...
> * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates
> will not work.
> * Closing connection 0
> GET
> "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro..."
> code = 77
> code_text = "Problem with the SSL CA cert (path? access rights?)"
> results = "(null)"
>
> 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Initializing principal
> host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab
> /etc/krb5.keytab
> 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG using ccache
> /var/run/certmonger/tmp-svWgpP/ccache
> 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Attempt 1/1: success
> 2022-04-09T16:02:32Z 21809 MainThread ipa DEBUG Loading StateFile from
> '/var/lib/ipa/sysrestore/sysrestore.state'
> 2022-04-09T16:02:33Z 21809 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache
> 2022-04-09T16:02:33Z 21809 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG retrieving schema for SchemaCache
> url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389
> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fbd8bfd6f80>
> 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG Starting external process
> 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG
> args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv
> 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG Process finished, return
> code=3
> 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG stdout=Error 77 connecting
> to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...:
> Problem with the SSL CA cert (path? access rights?).
>
> 2022-04-09T16:02:34Z 21809 MainThread ipa DEBUG stderr=* Trying
> 10.12.65.186...
> * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates
> will not work.
> * Closing connection 0
> GET
> "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro..."
> code = 77
> code_text = "Problem with the SSL CA cert (path? access rights?)"
> results = "(null)"
>
> 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Initializing principal
> host/migration-ipa-65-186.hiido.host.yydevops.com(a)YYDEVOPS.COM using keytab
> /etc/krb5.keytab
> 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG using ccache
> /var/run/certmonger/tmp-DSagx_/ccache
> 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Attempt 1/1: success
> 2022-04-09T16:02:42Z 21812 MainThread ipa DEBUG Loading StateFile from
> '/var/lib/ipa/sysrestore/sysrestore.state'
> 2022-04-09T16:02:43Z 21812 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG flushing ldap://migration-ipa-65-186.hiido.host.yydevops.com:389 from SchemaCache
> 2022-04-09T16:02:43Z 21812 MainThread ipa.ipapython.ipaldap.SchemaCache
> DEBUG retrieving schema for SchemaCache
> url=ldap://migration-ipa-65-186.hiido.host.yydevops.com:389
> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f1c70811b00>
> 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG Starting external process
> 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG
> args=/usr/lib/certmonger/dogtag-ipa-renew-agent-submit -vv
> 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG Process finished, return
> code=3
> 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG stdout=Error 77 connecting
> to https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro...:
> Problem with the SSL CA cert (path? access rights?).
>
> 2022-04-09T16:02:44Z 21812 MainThread ipa DEBUG stderr=* Trying
> 10.12.65.186...
> * Connected to migration-ipa-65-186.hiido.host.yydevops.com (10.12.65.186) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates
> will not work.
> * Closing connection 0
> GET
> "https://migration-ipa-65-186.hiido.host.yydevops.com:8443/ca/agent/ca/pro..."
> code = 77
> code_text = "Problem with the SSL CA cert (path? access rights?)"
> results = "(null)"
>
> root@migration-ipa-65-186:/.ipa/log# ll /etc/httpd/alias
> lrwxrwxrwx 1 root root 18 Apr 10 00:00 /etc/httpd/alias -> /etc/apache2/nssdb
hello
Can I get some attention?
Using Ubuntu install freeipa is an addition left by the company, I also feel very sorry. If I fix the expiration problem, I will migrate to centos, but I need to solve the certificate expiration problem first, Ubuntu does not use /etc/httpd/alias service and certificate store./etc/apache2/nssdb /apache2/nssdb /etc/apache2/nssdb
6 months
