Re: [Freeipa-devel] [Freeipa-users] errors when one ipa server down
On Mon, 2012-09-10 at 11:11 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Mon, 2012-09-10 at 16:36 +0200, Sumit Bose wrote: What about defining a task in the SSSD krb5 provider instead of pinging it from the locator plugin. The task can run at a configurable interval or never and checks if the current KDC is available. If not it tries the next until it goes offline if no reachable KDC can be found and updates or deletes the info file for the locator plugin.. This leave us with the question how to ping a KDC properly, but this we have to find out for either case. I am not a fan of generating load for the KDC unnecessarily. Simo. I tend to agree but this can be a real pain to debug because depending on the current state of sssd you have to either check krb5.conf or the sssd locator to see what KDC is configured. [moving to freeipa-devel] Yes but the solution is to do on-demand requests when something doesn't work. Because otherwise you still get the odd failure. Assume you check in 5 min intervals, and the KDC goes off 1 sec after the check, for 5 minutes you still have a wrong KDC in the locator and still get failures. So you loaded the KDC with ~300 request per day per client, and you still have high odds that on failure your locator file will still be 'wrong'. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1050 prevent replica orphans
Martin Kosek wrote:
On Thu, 2012-09-06 at 17:22 -0400, Rob Crittenden wrote:
Martin Kosek wrote:
On 08/31/2012 07:40 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
It was possible use ipa-replica-manage connect/disconnect/del to end up
orphaning or or more IPA masters. This is an attempt to catch and
prevent that case.
I tested with this topology, trying to delete B.
A - B - C
I got here by creating B and C from A, connecting B to C then deleting
the link from A to B, so it went from A - B and A - C to the above.
What I do is look up the servers that the delete candidate host has
connections to and see if we're the last link.
I added an escape clause if there are only two masters.
rob
Oh, this relies on my cleanruv patch 1031.
rob
1) When I run ipa-replica-manage del --force to an already uninstalled host,
the new code will prevent me the deletation because it cannot connect to it. It
also crashes with UnboundLocalError:
# ipa-replica-manage del vm-055.idm.lab.bos.redhat.com --force
Unable to connect to replica vm-055.idm.lab.bos.redhat.com, forcing removal
Traceback (most recent call last):
File /sbin/ipa-replica-manage, line 708, in module
main()
File /sbin/ipa-replica-manage, line 677, in main
del_master(realm, args[1], options)
File /sbin/ipa-replica-manage, line 476, in del_master
sys.exit(Failed read master data from '%s': %s % (delrepl.hostname,
str(e)))
UnboundLocalError: local variable 'delrepl' referenced before assignment
Fixed.
I also hit this error when removing a winsync replica.
Fixed.
2) As I wrote before, I think having --force option override the user inquiries
would benefit test automation:
+if not ipautil.user_input(Continue to delete?, False):
+sys.exit(Aborted)
Fixed.
3) I don't think this code won't cover this topology:
A - B - C - D - E
It would allow you deleting a replica C even though it would separate A-B and
D-E. Though we may not want to cover this situation now, what you got is
definitely helping.
I think you may be right. I only tested with 4 servers. With this B and
D would both still have 2 agreements so wouldn't be covered by the last
link test.
Everything looks good now, so ACK. We just need to push it along with
CLEANALLRUV patch.
Martin
Not to look a gift ACK In the mouth but here is a revised patch. I've
added a cleanup routine to remove an orphaned master properly. If you
had tried the mechanism I outlined in the man page it would have worked
but was less-than-complete. This way is better, just don't try it on a
live master.
I also added a cleanruv abort command, in case you want to kill an
existing task.
rob
From a8718439ac1f51d857a03ff27776850324c43cda Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 31 Aug 2012 11:56:58 -0400
Subject: [PATCH] When deleting a master, try to prevent orphaning other
servers.
If you have a replication topology like A - B - C and you try
to delete server B that will leave A and C orphaned. It may also
prevent re-installation of a new master on B because the cn=masters
entry for it probably still exists on at least one of the other masters.
Check on each master that it connects to to ensure that it isn't the
last link, and fail if it is. If any of the masters are not up then
warn that this could be a bad thing but let the user continue if
they want.
Add a new option to the del command, --cleanup, which runs the
replica_cleanup() routine to completely clean up references to a master.
Add a command to run the abort-clean-ruv task.
https://fedorahosted.org/freeipa/ticket/2797
---
install/tools/ipa-replica-manage | 115 -
install/tools/man/ipa-replica-manage.1 | 17 +
ipaserver/install/replication.py | 22 +++
3 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index c6ef51b7215164c9538afae942e3d42285ca860b..60d8ecbc22bfde66042b9ff4ea1068ad79566ed1 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -49,6 +49,7 @@ commands = {
re-initialize:(0, 0, , ),
force-sync:(0, 0, , ),
clean-ruv:(1, 1, Replica ID of to clean, ),
+abort-clean-ruv:(1, 1, Replica ID of to abort cleaning, ),
}
def convert_error(exc):
@@ -70,6 +71,8 @@ def parse_options():
help=provide additional information)
parser.add_option(-f, --force, dest=force, action=store_true, default=False,
help=ignore some types of errors)
+parser.add_option(-c, --cleanup, dest=cleanup, action=store_true, default=False,
+ help=DANGER: clean up references to a ghost master)
parser.add_option(--binddn, dest=binddn, default=None, type=dn,
help=Bind DN to use with remote server)
parser.add_option(--bindpw, dest=bindpw, default=None,
@@ -398,9 +401,80
Re: [Freeipa-devel] [PATCH] 211 Prevent opening of multiple dirty dialogs on navigation
On 9/7/2012 7:37 AM, Petr Vobornik wrote: Facets which performs AJAX call after update refresh (clear dirty state) after calling callback of dirty dialog. It might lead to multiple openings of dirty dialog. Assuming that calling dirty dialog's callback can be evaluated as dirty state is gone, we can call reset in the callback to prevent the issue. There will be an incorrect state in the facet for a moment. It will be fixed soon on execute of callback of the refresh AJAX call. It is not an issue because it will happen in background. User will be looking on different facet. https://fedorahosted.org/freeipa/ticket/2667 ACK. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1054 new default SELinux user map user
We've decided to change the default SELinux user map user to the OS default which is unconfined_u. It would be too drastic to go from one extreme to another. rob From 9b6c7cc0d9eb64ecb818fdde0ef32ba9ffa127f9 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Mon, 10 Sep 2012 17:07:54 -0400 Subject: [PATCH] Set SELinux default context to unconfined_u:s0-s0:c0.c1023 https://fedorahosted.org/freeipa/ticket/3045 --- install/share/bootstrap-template.ldif | 2 +- install/updates/50-ipaconfig.update | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index aac3f059ad30130e085bfcf37a7a1a6f1b49dc8c..24804e475427ad7e5b2ae7c69d6cfb54cafbef38 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -383,7 +383,7 @@ ipaDefaultEmailDomain: $DOMAIN ipaMigrationEnabled: FALSE ipaConfigString: AllowNThash ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 -ipaSELinuxUserMapDefault: guest_u:s0 +ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023 dn: cn=cosTemplates,cn=accounts,$SUFFIX changetype: add diff --git a/install/updates/50-ipaconfig.update b/install/updates/50-ipaconfig.update index b08df1806c4d2561fd5b24263e0f1c16f8b6f72f..0992db4ec92c3cc254bf8d05892dd4abd9988d8c 100644 --- a/install/updates/50-ipaconfig.update +++ b/install/updates/50-ipaconfig.update @@ -1,5 +1,5 @@ dn: cn=ipaConfig,cn=etc,$SUFFIX add:ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 -add:ipaSELinuxUserMapDefault: guest_u:s0 +add:ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023 add:ipaUserObjectClasses: ipasshuser -- 1.7.11.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1054 new default SELinux user map user
On Mon, Sep 10, 2012 at 05:38:47PM -0400, Rob Crittenden wrote: We've decided to change the default SELinux user map user to the OS default which is unconfined_u. It would be too drastic to go from one extreme to another. rob How does one set an empty default that the SSSD would treat as don't create any login file whatsoever ? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, Sep 10, 2012 at 04:58:40PM -0400, Rob Crittenden wrote: certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. That's the old port, alright, though I thought the upgrade process wasn't going to be converting already-installed Dogtag instances. Anyway, if your IPA configuration says dogtag_version = 10, certmonger's not going to notice it until version 0.60. I've just set the wheels in motion to push that version to Fedora 17 and later. HTH, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. The ipa package lacks any updated dogtag dependencies, so I abused it. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9-10. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. Is this cert renewal on a dogtag 10 instance? Or the upgraded dogtag 9? If its dogtag 10, perhaps you do not have the certmonger version that has the relevant fix? If its dogtag 9, then we need to figure out whats going on. That reminds me - I need to file a bug to allow certmonger to talk to the newly defined dogtag ports. Do you have selinux permissive? There is no man page for pkispawn/pkidestroy :-( According to the FHS these should not be in /bin but in /usr/sbin (not end-user commands). There is a trac ticket open for man pages for pkispawn and pkidestroy. We plan to complete this ticket by the time f18 is released. We'll look into the location of pkispawn/pkicreate. The output of pkicreate/pkisilent was really terrible and not usable at all so we didn't display it when failures occurred. It looks like that has been addressed, at least for the case where a CA is already configured and you try to install IPA. Perhaps we should capture stderr and display that instead of the command-line of pkispawn? Again, a man page would help with the integration. 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq 2012-09-10T20:51:45Z DEBUG stdout= 2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1 That may be a good idea. Of course. thats an IPA thing, right? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
