Version-Release number of selected component: freeipa-server-4.1.4-1.fc21 Additional info: reporter: libreport-2.3.0 cmdline: /usr/bin/python /usr/libexec/ipa/ipa-dnskeysyncd dso_list: freeipa-python-4.1.4-1.fc21.i686 executable: /usr/libexec/ipa/ipa-dnskeysyncd kernel: 3.19.5-200.fc21.i686+PAE runlevel: unknown type: Python uid: 978 Truncated backtrace: ipautil.py:1208:kinit_hostprincipal:StandardError: Error initializing principal ipa-dnskeysyncd/bramha.gaans.in in /etc/ipa/dnssec/ipa-dnskeysyncd.keytab: (-1765328228, 'Cannot contact any KDC for requested realm') Traceback (most recent call last): File "/usr/libexec/ipa/ipa-dnskeysyncd", line 68, in <module> ipautil.kinit_hostprincipal(KEYTAB_FB, WORKDIR, PRINCIPAL) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1208, in kinit_hostprincipal raise StandardError('Error initializing principal %s in %s: %s' % (principal, keytab, str(e))) StandardError: Error initializing principal ipa-dnskeysyncd/bramha.gaans.in in /etc/ipa/dnssec/ipa-dnskeysyncd.keytab: (-1765328228, 'Cannot contact any KDC for requested realm') Local variables in innermost frame: ccachedir: '/tmp' e: Krb5Error(-1765328228, 'Cannot contact any KDC for requested realm') princ: <krb5.Principal instance at 0xb6777eac: ipa-dnskeysyncd/bramha.gaans.in> krbcontext: <krbV.Context instance at 0xb632f0cc> ccache: <krbV.CCache instance at 0xb66d6f4c> ccache_file: 'FILE:/tmp/ccache' keytab: '/etc/ipa/dnssec/ipa-dnskeysyncd.keytab' ktab: <krbV.Keytab instance at 0xb6471c8c> principal: 'ipa-dnskeysyncd/bramha.gaans.in'
Created attachment 1036449 [details] File: backtrace
Created attachment 1036450 [details] File: environ
KDC could have been down, or there was something wrong with network setup, if the target KDC was on different server, so that KDC could not be contacted. This situation might happen. But should be rare because the ipa-dnskeysyncd service failed on it's initialization which should happen shortly after KDC is started(assuming it's started by 'ipactl start') The wrong thing here is that the daemon fails with a traceback. It should exit more gracefully. We would need more information if this issue happens regularly to fix the root cause.
ipa-dnskeysyncd was meant as a temporary tool which will be replaced soon. Therefore a fix is not planned.
WONTFIX is a better result I think, given no upstream ticket was opened.
Apparently this happens a lot so we should fix it: http://retrace.fedoraproject.org/faf/reports/bthash/d995d4a56728f4aeae7323ee16a7c4e4b842ae01/
Fixed upstream master: https://fedorahosted.org/freeipa/changeset/33bc9e7faca55497e00a3f6c08f4bff7262e290c ipa-4-1: https://fedorahosted.org/freeipa/changeset/6f9d16fd0014427db223fe82f021b12f4db2fe37
freeipa-4.2.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update freeipa' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4abcc8b937
freeipa-4.2.2-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.