[Freeipa-users] Re: ipa-replica-install --setup-ca failing
On the web ui it says in “Managed Suffix” that the server is domain, ca but
when I go into the page it says:
It is strongly recommended to keep the following services installed on more
than one server:
CA
Which is really odd.
Regards
Per
> On 13 Nov 2019, at 17:33, Rob Crittenden via FreeIPA-users
> wrote:
>
> Per Qvindesland via FreeIPA-users wrote:
>> Hi
>>
>> I have a centos 7 with ipa server 4.7.1-11 installed.
>>
>> When I run ipa-replica-install --setup-ca it seems to be synchronising with
>> the ipa server but failing the ca setup part
>>
>> Has anyone seen this error before?
>
> You built these packages yourself I assume?
>
> You'll need to look at the ca-spawn and/or the CA debug log for more
> info. The CA setup is a black box to IPA so we just get a pass/fail from it.
>
> rob
>
>>
>> Regards
>> Per
>>
>>
>>
>>
>> Installation failed: server failed to restart
>>
>>
>> 2019-11-13T16:45:57Z DEBUG stderr=WARNING: Password was garbage collected
>> before it was cleared.
>> WARNING: Password was garbage collected before it was cleared.
>> WARNING: Password was garbage collected before it was cleared.
>> pkispawn : ERRORServer did not start after 60s
>> configuration : ERRORServer failed to restart
>> pkispawn : ERRORException: server failed to restart
>> File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 549,
>> in main
>>scriptlet.spawn(deployer)
>> File
>> "/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py",
>> line 672, in spawn
>>raise Exception("server failed to restart")
>>
>>
>> 2019-11-13T16:45:57Z CRITICAL Failed to configure CA instance:
>> CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f',
>> '/tmp/tmpwhuna0va'] returned non-zero exit status 1: 'WARNING: Password was
>> garbage collected before it was cleared.\nWARNING: Password was garbage
>> collected before it was cleared.\nWARNING: Password was garbage collected
>> before it was cleared.\npkispawn : ERRORServer did not start after
>> 60s\nconfiguration : ERRORServer failed to restart\npkispawn :
>> ERRORException: server failed to restart\n File
>> "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 549, in
>> main\nscriptlet.spawn(deployer)\n File
>> "/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py",
>> line 672, in spawn\nraise Exception("server failed to restart")\n\n')
>> 2019-11-13T16:45:57Z CRITICAL See the installation logs and the following
>> files/directories for more information:
>> 2019-11-13T16:45:57Z CRITICAL /var/log/pki/pki-tomcat
>> 2019-11-13T16:45:57Z DEBUG Traceback (most recent call last):
>> File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py", line
>> 164, in spawn_instance
>>ipautil.run(args, nolog=nolog_list)
>> File "/usr/lib/python3.6/site-packages/ipapython/ipautil.py", line 574, in
>> run
>>p.returncode, arg_string, output_log, error_log
>> ipapython.ipautil.CalledProcessError: CalledProcessError(Command
>> ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpwhuna0va'] returned
>> non-zero exit status 1: 'WARNING: Password was garbage collected before it
>> was cleared.\nWARNING: Password was garbage collected before it was
>> cleared.\nWARNING: Password was garbage collected before it was
>> cleared.\npkispawn : ERRORServer did not start after
>> 60s\nconfiguration : ERRORServer failed to restart\npkispawn :
>> ERRORException: server failed to restart\n File
>> "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 549, in
>> main\nscriptlet.spawn(deployer)\n File
>> "/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py",
>> line 672, in spawn\nraise Exception("server failed to restart")\n\n')
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>> File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line
>> 605, in start_creation
>>run_step(full_msg, method)
>> File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line
>> 591, in run_step
>>method()
>> File "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py",
>> line 674, in __spawn_instance
>>pki_pin)
>> File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py", line
>> 166, in spawn_instance
>>self.handle_setup_error(e)
>> File
>> "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py", line
>> 409, in handle_setup_error
>>raise RuntimeError("%s configuration failed." % self.subsystem)
>> RuntimeError: CA configuration failed.
>>
>> 2019-11-13T16:45:57Z DEBUG [error] RuntimeError: CA configuration failed.
>> 2019-11-13T16:45:57Z DEBUG Removing /root/.dogtag/pki-tomcat/ca
>> 2019-11-13T16:45:57Z DEBUG File
>> "/usr/lib/python3.6/sit
[Freeipa-users] Re: ipa-replica-install --setup-ca failing
On to, 14 marras 2019, Per Qvindesland via FreeIPA-users wrote:
On the web ui it says in “Managed Suffix” that the server is domain, ca but
when I go into the page it says:
It is strongly recommended to keep the following services installed on more
than one server:
CA
Which is really odd.
Do you have more than one CA deployed? They are not contradicting.
Since you are trying to deploy a second replica with CA but haven't
succeeded yet, there is no second CA, thus the warning.
As Rob said, there are dogtag logs in /var/log/pki-tomcat which need to
be investigated why the deployment did not succeed.
However, I have a different question. You said below that it is CentOS 7
with FreeIPA 4.7.1-11. Where did you get that version? RHEL 7 (and thus
CentOS 7) only has FreeIPA 4.6 version. Running FreeIPA 4.7 is not
supported on CentOS 7.
Regards
Per
On 13 Nov 2019, at 17:33, Rob Crittenden via FreeIPA-users
wrote:
Per Qvindesland via FreeIPA-users wrote:
Hi
I have a centos 7 with ipa server 4.7.1-11 installed.
When I run ipa-replica-install --setup-ca it seems to be synchronising with the
ipa server but failing the ca setup part
Has anyone seen this error before?
You built these packages yourself I assume?
You'll need to look at the ca-spawn and/or the CA debug log for more
info. The CA setup is a black box to IPA so we just get a pass/fail from it.
rob
Regards
Per
Installation failed: server failed to restart
2019-11-13T16:45:57Z DEBUG stderr=WARNING: Password was garbage collected
before it was cleared.
WARNING: Password was garbage collected before it was cleared.
WARNING: Password was garbage collected before it was cleared.
pkispawn : ERRORServer did not start after 60s
configuration : ERRORServer failed to restart
pkispawn : ERRORException: server failed to restart
File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 549, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py",
line 672, in spawn
raise Exception("server failed to restart")
2019-11-13T16:45:57Z CRITICAL Failed to configure CA instance: CalledProcessError(Command
['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpwhuna0va'] returned non-zero exit status 1: 'WARNING:
Password was garbage collected before it was cleared.\nWARNING: Password was garbage collected before it was
cleared.\nWARNING: Password was garbage collected before it was cleared.\npkispawn : ERRORServer did
not start after 60s\nconfiguration : ERRORServer failed to restart\npkispawn : ERRORException:
server failed to restart\n File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line
549, in main\nscriptlet.spawn(deployer)\n File
"/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py", line 672, in
spawn\nraise Exception("server failed to restart")\n\n')
2019-11-13T16:45:57Z CRITICAL See the installation logs and the following
files/directories for more information:
2019-11-13T16:45:57Z CRITICAL /var/log/pki/pki-tomcat
2019-11-13T16:45:57Z DEBUG Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
line 164, in spawn_instance
ipautil.run(args, nolog=nolog_list)
File "/usr/lib/python3.6/site-packages/ipapython/ipautil.py", line 574, in run
p.returncode, arg_string, output_log, error_log
ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f',
'/tmp/tmpwhuna0va'] returned non-zero exit status 1: 'WARNING: Password was garbage collected before it was
cleared.\nWARNING: Password was garbage collected before it was cleared.\nWARNING: Password was garbage
collected before it was cleared.\npkispawn : ERRORServer did not start after 60s\nconfiguration :
ERRORServer failed to restart\npkispawn : ERRORException: server failed to restart\n File
"/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 549, in main\n
scriptlet.spawn(deployer)\n File
"/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py", line 672, in
spawn\nraise Exception("server failed to restart")\n\n')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line
605, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py", line
591, in run_step
method()
File "/usr/lib/python3.6/site-packages/ipaserver/install/cainstance.py", line
674, in __spawn_instance
pki_pin)
File "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
line 166, in spawn_instance
self.handle_setup_error(e)
File "/usr/lib/python3.6/site-packages/ipaserver/install/dogtaginstance.py",
line 409, in handle_setup_error
[Freeipa-users] one-way AD trust with shared secret - does it really work in 4.6.5 version?
hi guys I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials. But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords! And this weird bit, I do: $ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk Shared secret for the trust: ... Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right? So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like. many thanks, L. pEpkey.asc Description: application/pgp-keys ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: one-way AD trust with shared secret - does it really work in 4.6.5 version?
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote: hi guys I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials. But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords! And this weird bit, I do: $ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk Shared secret for the trust: ... Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right? So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like. It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base. See https://bugzilla.redhat.com/show_bug.cgi?id=1757507 However, there is a catch. If you have more than one domain in your IPA deployment that is not subdomain of the primary IPA domain (e.g. example.test and anotherdomain.test where example.test is primary IPA domain), then GSSAPI authentication to anotherdomain.test would not work from Windows machines. This is because we don't yet have implementation of the APIs expected by Active Directory domain controllers to retrieve the forest topology from IPA side and we cannot update it on AD DC side from IPA without admin credentials. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: one-way AD trust with shared secret - does it really work in 4.6.5 version?
On 14/11/2019 11:44, Alexander Bokovoy wrote: > On to, 14 marras 2019, lejeczek via FreeIPA-users wrote: >> hi guys >> >> I've have AD trust work fine (gssapi), ssh & samba are password-less >> when the trust is establish with 'admin' credentials. >> >> But the strory is very different with 'shared secret'. Kerberos does not >> work, passwords are asked for and with Windows cifs - asks for username >> and no authentication even with passwords! >> >> And this weird bit, I do: >> >> $ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk >> --trust-secret --server=win8-vm.bec.private.mac.ac.uk >> >> Shared secret for the trust: >> >> ... >> >> Here, for the 'secret' I can punch in anything and IPA will say that the >> trust was added successfully - this surely must not be right, right? >> >> So, should 'secret' work for one-way incoming trust in IPA? To me, it >> does not seem like. > > It very much depends what RHEL/CentOS version do you use. What > ipa-server package version? You need RHEL 7.7 as a base. IPA version in the subject. I'm on Centos 7.7.1908. thanks, L. > > See https://bugzilla.redhat.com/show_bug.cgi?id=1757507 > > However, there is a catch. If you have more than one domain in your IPA > deployment that is not subdomain of the primary IPA domain (e.g. > example.test and anotherdomain.test where example.test is primary IPA > domain), then GSSAPI authentication to anotherdomain.test would not work > from Windows machines. This is because we don't yet have implementation > of the APIs expected by Active Directory domain controllers to retrieve > the forest topology from IPA side and we cannot update it on AD DC side > from IPA without admin credentials. > > > pEpkey.asc Description: application/pgp-keys ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Unable to authorize via HTTP
Hey guys,
I set up my very first FreeIPA installation and I'm currently dealing with an
issue I hope you can help me with.
I'm running FreeIPA version 4.7.1 on CentOS 8. I installed about 3 weeks ago,
had been working fine up until a few days ago (after a restart).
I'm encountering several symptoms:
The WebUI won't let me log in anymore
("Login failed due to an unknown reason.")
This was the first error I noticed... since it only happened for users not
already logged in, I suspected wrong password entries. After a server restart
everyone got locked out though.
Other post-restart commands that are not working any more:
certutil -L
certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad
database.
ipa
ERROR: cannot connect to 'https://ipa.**.**/ipa/json': [Errno 111] Connection
refused
ipa-getkeytab -p HTTP/*@*.* -s ipa.*.* -k /var/lib/ipa/gssproxy/http.keytab
Failed to load translations
SASL Bind failed Local error (-2) SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Ticket
expired)!
Failed to bind to server!
Retrying with pre-4.0 keytab retrieval method...
SASL Bind failed Local error (-2) SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Ticket
expired)!
Failed to bind to server!
Failed to get keytab
(works with binddn though)
kinit, klist and other kerberos/ldap logins are working fine!
Logfiles:
/var/log/httpd/error_log
[Thu Nov 14 16:38:43.894373 2019] [wsgi:error] [pid 22560:tid 140303294011136]
[remote *.*.*.*:*] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN:
i18n_messages(version='2.230'): SUCCESS
[Thu Nov 14 16:38:44.013990 2019] [:warn] [pid 24265:tid 140302572558080]
[client *.*.*.*:*] KRB5CCNAME file (/run/ipa/ccaches/*@*.*) lookup failed!,
referer: https://ipa.*.*/ipa/ui/
[Thu Nov 14 16:38:44.036125 2019] [:warn] [pid 24265:tid 140301800822528]
[client *.*.*.*:*] KRB5CCNAME file (/run/ipa/ccaches/*@*.*) lookup failed!,
referer: https://ipa.*.*/ipa/ui/
[Thu Nov 14 16:38:57.098920 2019] [wsgi:error] [pid 22560:tid 140303294011136]
[remote *.*.*.*:*] ipa: INFO: 401 Unauthorized:
HTTPConnectionPool(host='ipa.*.*', port=80): Max retries exceeded with url:
/ipa/session/cookie (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection
refused',))
/var/log/krb5kdc.log
Nov 14 17:14:34 ipa.*.* krb5kdc[22498](info): AS_REQ (8 etypes {18 17 20 19 16
23 25 26}) 127.0.0.1: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS@*.* for
krbtgt/*.*@*.*, Additional pre-authentication required
Nov 14 17:14:34 ipa.*.* krb5kdc[22498](info): closing down fd 12
Nov 14 17:14:34 ipa.*.* krb5kdc[22502](info): AS_REQ (8 etypes {18 17 20 19 16
23 25 26}) 127.0.0.1: ISSUE: authtime 1573748074, etypes {rep=18 tkt=18
ses=18}, WELLKNOWN/ANONYMOUS@*.* for krbtgt/*.*@*.*
Nov 14 17:14:34 ipa.*.* krb5kdc[22502](info): closing down fd 12
Nov 14 17:14:34 ipa.*.* krb5kdc[22506](info): AS_REQ (8 etypes {18 17 20 19 16
23 25 26}) 127.0.0.1: NEEDED_PREAUTH: *@*.* for krbtgt/*.*@*.*, Additional
pre-authentication required
Nov 14 17:14:34 ipa.*.* krb5kdc[22506](info): closing down fd 12
Nov 14 17:14:34 ipa.*.* krb5kdc[22506](info): AS_REQ (8 etypes {18 17 20 19 16
23 25 26}) 127.0.0.1: ISSUE: authtime 1573748074, etypes {rep=18 tkt=18
ses=18}, *@*.* for krbtgt/*.*@*.*
Nov 14 17:14:34 ipa.*.* krb5kdc[22506](info): closing down fd 12
Nov 14 17:14:34 ipa.*.* krb5kdc[22507](info): TGS_REQ (8 etypes {18 17 20 19 16
23 25 26}) 127.0.0.1: ISSUE: authtime 1573748074, etypes {rep=18 tkt=18
ses=18}, *@*.* for HTTP/ipa.*.*@*.*
Nov 14 17:14:34 ipa.eagleeye-film.de krb5kdc[22507](info): closing down fd 12
I'm suspecting some GSSAPI/certificate error... /run/ipa/ccaches is empty and
all non-http authorizations seem to work.
I have been working on a samba configuration for the same server; I have a
feeling that some of my experiments
(ipa-adtrust-install, authconfig, chmod on keytab, net sam provision)
messed with the rest of the system... I tried to backtrack/revert as much as I
could, but nothing helped so far. I also think the first WebUI errors occured
before already.
I'd be so happy if anyone could help! So far I've been able to find solutions
for every issue, but this seems to be a tough one.
Thanks!
-Tristan
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] FreeIPA fails to start on CentOS 8
I am trying to migrate to CentOS 8 in my home lab. And I have gotten FreeIPA installed. However I am using caprica.space as my domain name but I don't think bind/named likes me using that. Is this an issue the version in FreeIPA or did I do something wrong? I found this out because FreeIPA won't start. Fails on named. 14-Nov-2019 13:00:43.566 zone 100.51.198.IN-ADDR.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 113.0.203.IN-ADDR.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 255.255.255.255.IN-ADDR.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone D.F.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 8.E.F.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 9.E.F.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone A.E.F.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone B.E.F.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone 8.B.D.0.1.0.0.2.IP6.ARPA/IN: shutting down 14-Nov-2019 13:00:43.566 zone EMPTY.AS112.ARPA/IN: shutting down 14-Nov-2019 13:00:43.620 LDAP configuration for instance 'ipa' synchronized 14-Nov-2019 13:00:43.657 LDAP data for instance 'ipa' are being synchronized, please ignore message 'all zones loaded' 14-Nov-2019 13:00:43.669 managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted 14-Nov-2019 13:00:43.819 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.819 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.819 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.820 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.820 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.820 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.820 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.820 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.821 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.821 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.821 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.821 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.821 dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type 14-Nov-2019 13:00:43.822 zone 10.150.10.in-addr.arpa/IN: loaded serial 1573758043 14-Nov-2019 13:00:43.822 zone caprica.space/IN: NS 'freeipa01.asm.caprica.space' has no address records (A or ) 14-Nov-2019 13:00:43.822 zone caprica.space/IN: not loaded due to errors. 14-Nov-2019 13:00:43.822 1 master zones from LDAP instance 'ipa' loaded (2 zones defined, 0 inactive, 1 failed to load) 14-Nov-2019 13:00:43.824 zone caprica.space/IN: NS 'freeipa01.asm.caprica.space' has no address records (A or ) 14-Nov-2019 13:00:43.824 zone caprica.space/IN: not loaded due to errors. 14-Nov-2019 13:00:43.824 update_zone (syncrepl) failed for master zone DN 'idnsname=caprica.space.,cn=dns,dc=caprica,dc=space'. Zones can be outdated, run `rndc reload`: bad zone 14-Nov-2019 13:01:38.383 received control channel command 'stop' 14-Nov-2019 13:01:38.384 shutting down: flushing changes 14-Nov-2019 13:01:38.384 stopping command channel on 127.0.0.1#953 14-Nov-2019 13:01:38.384 stopping command channel on ::1#953 14-Nov-2019 13:01:38.385 unloading DynDB instance 'ipa' 14-Nov-2019 13:01:38.386 zone 10.150.10.in-addr.arpa/IN: shutting down 14-Nov-2019 13:01:38.387 no longer listening on ::#53 14-Nov-2019 13:01:38.387 no longer listening on 127.0.0.1#53 14-Nov-2019 13:01:38.387 no longer listening on 10.150.10.15#53 14-Nov-2019 13:01:38.404 exiting ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA fails to start on CentOS 8
Andrew Meyer via FreeIPA-users wrote: > I am trying to migrate to CentOS 8 in my home lab. And I have gotten FreeIPA > installed. However I am using caprica.space as my domain name but I don't > think bind/named likes me using that. Is this an issue the version in > FreeIPA or did I do something wrong? I found this out because FreeIPA won't > start. Fails on named. > I don't think IPA cares about the domain name you've chosen. Can you provide more details on how you installed this? Can we see the install log? rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA fails to start on CentOS 8
Sure. Give me a bit to gather that. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Unable to authorize via HTTP
Tristan Weis via FreeIPA-users wrote:
> Hey guys,
>
> I set up my very first FreeIPA installation and I'm currently dealing with an
> issue I hope you can help me with.
> I'm running FreeIPA version 4.7.1 on CentOS 8. I installed about 3 weeks ago,
> had been working fine up until a few days ago (after a restart).
>
> I'm encountering several symptoms:
>
> The WebUI won't let me log in anymore
> ("Login failed due to an unknown reason.")
> This was the first error I noticed... since it only happened for users not
> already logged in, I suspected wrong password entries. After a server restart
> everyone got locked out though.
>
> Other post-restart commands that are not working any more:
>
> certutil -L
> certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad
> database.
This is a red herring. certutil without a -d assumes ~/.netscape as the
database location (yes, that Netscape).
> ipa
> ERROR: cannot connect to 'https://ipa.**.**/ipa/json': [Errno 111] Connection
> refused
Suggests the web server isn't up at all.
What does ipactl status say?
> ipa-getkeytab -p HTTP/*@*.* -s ipa.*.* -k /var/lib/ipa/gssproxy/http.keytab
> Failed to load translations
> SASL Bind failed Local error (-2) SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure. Minor code may provide more information (Ticket
> expired)!
> Failed to bind to server!
> Retrying with pre-4.0 keytab retrieval method...
> SASL Bind failed Local error (-2) SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure. Minor code may provide more information (Ticket
> expired)!
> Failed to bind to server!
> Failed to get keytab
> (works with binddn though)
Are you just trying random commands?
> kinit, klist and other kerberos/ldap logins are working fine!
Based on above I'm guessing you didn't kinit first. I wouldn't use
ipa-getkeytab as a troubleshooting tool though.
> Logfiles:
> /var/log/httpd/error_log
> [Thu Nov 14 16:38:43.894373 2019] [wsgi:error] [pid 22560:tid
> 140303294011136] [remote *.*.*.*:*] ipa: INFO: [jsonserver_i18n_messages]
> UNKNOWN: i18n_messages(version='2.230'): SUCCESS
> [Thu Nov 14 16:38:44.013990 2019] [:warn] [pid 24265:tid 140302572558080]
> [client *.*.*.*:*] KRB5CCNAME file (/run/ipa/ccaches/*@*.*) lookup failed!,
> referer: https://ipa.*.*/ipa/ui/
> [Thu Nov 14 16:38:44.036125 2019] [:warn] [pid 24265:tid 140301800822528]
> [client *.*.*.*:*] KRB5CCNAME file (/run/ipa/ccaches/*@*.*) lookup failed!,
> referer: https://ipa.*.*/ipa/ui/
> [Thu Nov 14 16:38:57.098920 2019] [wsgi:error] [pid 22560:tid
> 140303294011136] [remote *.*.*.*:*] ipa: INFO: 401 Unauthorized:
> HTTPConnectionPool(host='ipa.*.*', port=80): Max retries exceeded with url:
> /ipa/session/cookie (Caused by
> NewConnectionError(' 0x7f9ae9039f60>: Failed to establish a new connection: [Errno 111] Connection
> refused',))
Not a lot of context. Knowing what services are running is more
important at this point.
> I'm suspecting some GSSAPI/certificate error... /run/ipa/ccaches is empty and
> all non-http authorizations seem to work.
> I have been working on a samba configuration for the same server; I have a
> feeling that some of my experiments
> (ipa-adtrust-install, authconfig, chmod on keytab, net sam provision)
> messed with the rest of the system... I tried to backtrack/revert as much as
> I could, but nothing helped so far. I also think the first WebUI errors
> occured before already.
Doesn't sound cert related and you said the KDC is working.
RHEL 8 uses authselect, not authconfig, but that probably wouldn't
affect the web server.
rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA fails to start on CentOS 8
Andrew Meyer via FreeIPA-users wrote: > Sure. Give me a bit to gather that. Could be related to: 2019-11-13T04:02:26Z INFO Checking DNS domain caprica.space., please wait ... 2019-11-13T04:02:26Z WARNING DNS zone caprica.space. already exists in DNS and is handled by server(s): dns2.registrar-servers.com., dns1.registrar-servers.com. Please make sure that the domain is properly delegated to this IPA server. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA fails to start on CentOS 8
Ok I have pointed the domain to my IP address (also setup DDNS with the registrar). Howevver BIND still fails. Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: starting BIND 9.11.4-P2-RedHat-9.11.4-17.P2.el8_0.1 (Extended Support Version) Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: running on Linux x86_64 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-pref> Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: running as: named-pkcs11 -u named -c /etc/named.conf Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: compiled by GCC 8.2.1 20180905 (Red Hat 8.2.1-3) Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: compiled with libxml2 version: 2.9.7 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: linked to libxml2 version: 20907 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: compiled with zlib version: 1.2.11 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: linked to zlib version: 1.2.11 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: threads support is enabled Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: BIND 9 is maintained by Internet Systems Consortium, Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: corporation. Support and training for BIND 9 are Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: available at https://www.isc.org/support Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: adjusted limit on open files from 4096 to 1048576 Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: found 1 CPU, using 1 worker thread Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: using 1 UDP listener per interface Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: using up to 21000 sockets Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: Configuration.cpp(94): Missing log.level in configuration. Using default value: INFO Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: ObjectStore.cpp(59): Failed to enumerate object store in /var/lib/ipa/dnssec/tokens Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: SoftHSM.cpp(507): Could not load the object store Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: initializing DST: PKCS#11 initialization failed Nov 14 20:46:28 freeipa01.asm.caprica.space named-pkcs11[23802]: exiting (due to fatal error) Nov 14 20:46:28 freeipa01.asm.caprica.space systemd[1]: named-pkcs11.service: Control process exited, code=exited status=1 Nov 14 20:46:28 freeipa01.asm.caprica.space systemd[1]: named-pkcs11.service: Failed with result 'exit-code'. Nov 14 20:46:28 freeipa01.asm.caprica.space systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. -- Subject: Unit named-pkcs11.service has failed -- Defined-By: systemd -- Support: https://access.redhat.com/support ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
