On Thu, Mar 19, 2015 at 05:50:50PM -0400, Prasun Gera wrote:
It's just that /var/lib/sss/db is not cleared between subsequent server
installs and uninstall, and that seems to be creating problems on the
server since the server is also a client. If you do
install-uninstall-install on the server
I'll open a ticket. It should probably be cleared, unless handled in some
other way, before installs too. This looks like more of a client side issue
than a server one. The database should be cleared when a client is
explicitly uninstalled, and also if the client tries to register to a
different
It's just that /var/lib/sss/db is not cleared between subsequent server
installs and uninstall, and that seems to be creating problems on the
server since the server is also a client. If you do
install-uninstall-install on the server with the same domain name for both
the installs, you cannot
I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I
think it's a pretty significant problem, probably from a security
standpoint too. The fact that it's trying to authenticate against something
stale and incorrect would imply that it might erroneously authenticate
against
On 19 Mar 2015, at 20:09, Prasun Gera prasun.g...@gmail.com wrote:
I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I
think it's a pretty significant problem, probably from a security standpoint
too. The fact that it's trying to authenticate against something
On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote:
getcert status
process 31282: arguments to dbus_message_new_method_call() were
incorrect, assertion path != NULL failed in file dbus-message.c line 1262.
This is normally a bug in some application using the D-Bus library.
I ran some more tests and I've found that it's a general sssd issue which
affects everything handled by sssd (pam, ssh, sudo). I see similar problems
with 'su - username'. I'm guessing that kinit works since it bypasses sssd.
Does anyone have any ideas on debugging this?
On Tue, Mar 17, 2015 at
No I haven't been using docker images. I was merely suggesting it as a way
of reproducing the failure consistently and passing it on. I have been
running everything natively. Barring external factors such as DNS, which
probably don't matter in this case, I think this should be reproducible on
an
I think I have figured it out. The contents of /var/lib/sss/db are not
cleared on uninstall. Stopping sssd, clearing that directory and restarting
sssd solves the problem. Is there a reason why this is not cleared on
uninstall?
On Wed, Mar 18, 2015 at 6:35 PM, Prasun Gera prasun.g...@gmail.com
On 03/17/2015 02:54 PM, Prasun Gera wrote:
Sorry, the message got sent accidentally earlier before I could
provide all the details.
Version: 4.1.0 on RHEL 7.1 x86_64
Steps:
1. ipa-server-install
2. service sshd restart
3. kinit admin - This always works
4. ssh admin@localhost -
Prasun Gera wrote:
How do I confirm that there are no certs left behind and that
cert-monger isn't tracking them? I'm a bit new to all the components
used by IPA. I do see that the /root/cacert.p12 file is never deleted.
Not clean but this shouldn't prevent re-install.
After an uninstall, I
How do I confirm that there are no certs left behind and that cert-monger
isn't tracking them? I'm a bit new to all the components used by IPA. I do
see that the /root/cacert.p12 file is never deleted.
After an uninstall, I see this:
getcert list
Number of certificates and requests being tracked:
Sorry, the message got sent accidentally earlier before I could provide all
the details.
Version: 4.1.0 on RHEL 7.1 x86_64
Steps:
1. ipa-server-install
2. service sshd restart
3. kinit admin - This always works
4. ssh admin@localhost - This works for the
13 matches
Mail list logo
