On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I can’t delete hosts. error_log show a bunch of python errors, ending in
Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call [Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = self.run(*args, **options) [Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run [Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return self.execute(*args, **options) [Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in execute [Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options) [Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in _ca_search [Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = self.api.Backend.ra [Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in __getattr__ [Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise AttributeError(repr(key) + ' ' + repr(self)) [Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' <ipalib.plugable.APINameSpace object at 0x7f16bdf4fa10>
(I modified the error to give more info, but without getting much useful.)
Any idea what’s going on. It looks like self.api.Backend doesn’t have ra set. It would take quite a while for me to find out where it’s supposed to be set.
Charles Hedrick via FreeIPA-users wrote:
On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I can’t delete hosts. error_log show a bunch of python errors, ending in
Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call [Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = self.run(*args, **options) [Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run [Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return self.execute(*args, **options) [Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in execute [Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options) [Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in _ca_search [Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = self.api.Backend.ra [Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in __getattr__ [Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise AttributeError(repr(key) + ' ' + repr(self)) [Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' <ipalib.plugable.APINameSpace object at 0x7f16bdf4fa10>
(I modified the error to give more info, but without getting much useful.)
Any idea what’s going on. It looks like self.api.Backend doesn’t have ra set. It would take quite a while for me to find out where it’s supposed to be set.
What are the contents of /etc/ipa/default.conf?
rob
looks like that was it.
was
enable_ra = False ra_plugin = None
now:
ra_plugin = dogtag dogtag_version = 10 enable_ra = True
works
I guess that was wrong from when it was originally set up?
On Aug 28, 2019, at 4:24 PM, Rob Crittenden rcritten@redhat.com wrote:
Charles Hedrick via FreeIPA-users wrote:
On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I can’t delete hosts. error_log show a bunch of python errors, ending in
Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call [Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = self.run(*args, **options) [Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run [Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return self.execute(*args, **options) [Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in execute [Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options) [Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in _ca_search [Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = self.api.Backend.ra [Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in __getattr__ [Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise AttributeError(repr(key) + ' ' + repr(self)) [Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' <ipalib.plugable.APINameSpace object at 0x7f16bdf4fa10>
(I modified the error to give more info, but without getting much useful.)
Any idea what’s going on. It looks like self.api.Backend doesn’t have ra set. It would take quite a while for me to find out where it’s supposed to be set.
What are the contents of /etc/ipa/default.conf?
rob
Charles Hedrick wrote:
looks like that was it.
was
enable_ra = False ra_plugin = None
now:
ra_plugin = dogtag dogtag_version = 10 enable_ra = True
works
I guess that was wrong from when it was originally set up?
Hard to know for sure. It looks like the upgrader will set that when uninstalling the old selfsign CA. That might still be in /var/log/ipaupgrade.log. Look for "Removing self-signed CA. Certificates will need to managed manually."
rob
On Aug 28, 2019, at 4:24 PM, Rob Crittenden rcritten@redhat.com wrote:
Charles Hedrick via FreeIPA-users wrote:
On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I can’t delete hosts. error_log show a bunch of python errors, ending in
Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call [Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = self.run(*args, **options) [Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run [Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return self.execute(*args, **options) [Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in execute [Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options) [Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in _ca_search [Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = self.api.Backend.ra [Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035] File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in __getattr__ [Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise AttributeError(repr(key) + ' ' + repr(self)) [Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' <ipalib.plugable.APINameSpace object at 0x7f16bdf4fa10>
(I modified the error to give more info, but without getting much useful.)
Any idea what’s going on. It looks like self.api.Backend doesn’t have ra set. It would take quite a while for me to find out where it’s supposed to be set.
What are the contents of /etc/ipa/default.conf?
rob
Yes "Removing self-signed CA.” is there.
Our configuration may have confused the upgrader.
We initially did a default install, which sets up certificate management with a self-signed cert. Then we moved to a commercial certificate, which was a documented procedure. So one of our 3 servers actually has a CA authority running, but as far as I know we don’t use it (unless it’s used for the self-signed certificates used by “kinit -a”). There were bugs with this particular pattern in previous releases. One of my replica installs was a mess and required lots of hand fixups, and one of the first upgrades did also. Maybe this is a remnant of that. I haven’t had any issues with upgrades in recent releases. I have no idea what at the next replica-install is going to look like. I guess I’ll have to do that when we move to Centos 8.
As long as we’re OK with
ra_plugin = dogtag dogtag_version = 10 enable_ra = True
and it won’t cause trouble for future upgrades, I’m fine. I took those lines from the other non-CA replica, so I assume it’s OK.
On Aug 28, 2019, at 4:38 PM, Rob Crittenden <rcritten@redhat.commailto:rcritten@redhat.com> wrote:
Hard to know for sure. It looks like the upgrader will set that when uninstalling the old selfsign CA. That might still be in /var/log/ipaupgrade.log. Look for "Removing self-signed CA. Certificates will need to managed manually."
Charles Hedrick wrote:
Yes "Removing self-signed CA.” is there.
Our configuration may have confused the upgrader.
We initially did a default install, which sets up certificate management with a self-signed cert. Then we moved to a commercial certificate, which was a documented procedure. So one of our 3 servers actually has a CA authority running, but as far as I know we don’t use it (unless it’s used for the self-signed certificates used by “kinit -a”). There were bugs with this particular pattern in previous releases. One of my replica installs was a mess and required lots of hand fixups, and one of the first upgrades did also. Maybe this is a remnant of that. I haven’t had any issues with upgrades in recent releases. I have no idea what at the next replica-install is going to look like. I guess I’ll have to do that when we move to Centos 8.
selfsign has a specific meaning in this case.
We originally hoped to have additional CA provider backends beyond just dogtag. In order to get the interfaces right we created an extremely simple backend named selfsign. This forked out to NSS commands to sign CSRs and kept a flat file to track the last serialno. It was not intended for production use but was handy during development because the 3-5 minutes install time for dogtag could be skipped :-)
It ended up causing a lot of confusion and people put it into production so we finally deprecated and removed it some time during 4.x.
Now, the only way that I can see where the upgrader would make this change is if the ra_plugin was set to selfsign. I don't know how this got set that way. I don't believe that upgrading from selfsign -> dogtag was possible but maybe.
And yeah, selfsign was kinda a dumb name since in dogtag it is generally a self-signed CA as well, but it's what was on my mind on that day I guess.
As long as we’re OK with
ra_plugin = dogtag dogtag_version = 10 enable_ra = True
and it won’t cause trouble for future upgrades, I’m fine. I took those lines from the other non-CA replica, so I assume it’s OK.
Looks fine to me assuming your CA works, etc.
rob
On Aug 28, 2019, at 4:38 PM, Rob Crittenden <rcritten@redhat.com mailto:rcritten@redhat.com> wrote:
Hard to know for sure. It looks like the upgrader will set that when uninstalling the old selfsign CA. That might still be in /var/log/ipaupgrade.log. Look for "Removing self-signed CA. Certificates will need to managed manually."
freeipa-users@lists.fedorahosted.org
-
Charles Hedrick -
Rob Crittenden