Re: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services
Adam Young wrote: On 07/30/2010 04:02 PM, Adam Young wrote: On 07/22/2010 02:25 PM, Rob Crittenden wrote: Make sure that the host behind new host and service records is actually a resolvable DNS A record. There is a --force flag if you know what you are doing (or just feel like charging ahead anyway). We use a lot of made-up names in the self-tests, had to add the force flag to all of them. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I can't get this patch to apply: [ayo...@ayoung freeipa]$ git apply ~/Documents/IPA/freeipa-490-dns.patch error: patch failed: ipalib/util.py:28 error: ipalib/util.py: patch does not apply I've tried it both with and without patch 484 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OK, disregard that, I was able to apply it on top of 484, build and deploy. I'd give it an ACK except that I can't figure out how to work around service-add where the service is not yet resolvable. I understand that this is not desired, but I'm fairly certain that not being able to do this will mess up someone. ipa service-add-host --force --hosts=web.example.com HTTP/web.example.com Usage: ipa [global-options] service-add-host PRINCIPAL ipa: error: no such option: --force Good catch, this was an oversight. The add-host option is for adding hosts that are allowed to manage this service (keytab, certificate). I completely forgot to disable enforcement of DNS on that. I'll resubmit the patch once I get that worked out. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services
Dmitri Pal wrote: Adam Young wrote: On 07/30/2010 04:02 PM, Adam Young wrote: On 07/22/2010 02:25 PM, Rob Crittenden wrote: Make sure that the host behind new host and service records is actually a resolvable DNS A record. There is a --force flag if you know what you are doing (or just feel like charging ahead anyway). We use a lot of made-up names in the self-tests, had to add the force flag to all of them. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I can't get this patch to apply: [ayo...@ayoung freeipa]$ git apply ~/Documents/IPA/freeipa-490-dns.patch error: patch failed: ipalib/util.py:28 error: ipalib/util.py: patch does not apply I've tried it both with and without patch 484 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OK, disregard that, I was able to apply it on top of 484, build and deploy. I'd give it an ACK except that I can't figure out how to work around service-add where the service is not yet resolvable. I understand that this is not desired, but I'm fairly certain that not being able to do this will mess up someone. ipa service-add-host --force --hosts=web.example.com HTTP/web.example.com Usage: ipa [global-options] service-add-host PRINCIPAL ipa: error: no such option: --force The --force should be an option. And if it does not resolve but internal DNS is used then there should be an option to add it to the DNS. So I guess the logic should be: 1) No options and the host resolves - success 2) No options and the host does not resolve - failure 3) --force is specified and the host resolves - success (force is ignored) 4) --force is specified and the host does not resolve - host is added as is 5) --dns is specified but we do not use internal DNS - failure invalid parameter 6) --dns is specified and we use internal DNS and the host resolves - host is added to the hosts and host is not added to dns since it is already there 7) --dns is specified and we use internal DNS and the host does not resolve - host is added to the hosts and to dns NACK for now. No, I don't want to interweave DNS in this way right now. DNS is more complex than automatically adding hosts would handle (an A record with no PTR is worse than no A record IMHO). This was merely an option I didn't explicitly test so it got past me. I'll make sure --force works with service-add-host. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services
On 08/05/2010 08:45 AM, Rob Crittenden wrote: Adam Young wrote: On 07/30/2010 04:02 PM, Adam Young wrote: On 07/22/2010 02:25 PM, Rob Crittenden wrote: Make sure that the host behind new host and service records is actually a resolvable DNS A record. There is a --force flag if you know what you are doing (or just feel like charging ahead anyway). We use a lot of made-up names in the self-tests, had to add the force flag to all of them. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I can't get this patch to apply: [ayo...@ayoung freeipa]$ git apply ~/Documents/IPA/freeipa-490-dns.patch error: patch failed: ipalib/util.py:28 error: ipalib/util.py: patch does not apply I've tried it both with and without patch 484 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OK, disregard that, I was able to apply it on top of 484, build and deploy. I'd give it an ACK except that I can't figure out how to work around service-add where the service is not yet resolvable. I understand that this is not desired, but I'm fairly certain that not being able to do this will mess up someone. ipa service-add-host --force --hosts=web.example.com HTTP/web.example.com Usage: ipa [global-options] service-add-host PRINCIPAL ipa: error: no such option: --force Good catch, this was an oversight. The add-host option is for adding hosts that are allowed to manage this service (keytab, certificate). I completely forgot to disable enforcement of DNS on that. I'll resubmit the patch once I get that worked out. rob Are these the only two permutations (Host, Service ) X (Force , No Force) or are there others? Is there something I should test with the --dns option? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patch] Simple-plugin-for-reflecting-user-principal
On 2010-08-04 01:49, Adam Young wrote: This is a required patch for the UI code. Basically, the Kerberos authentication method does not provide any way for the web ui to know who logged in. With this patch, we can do the equivalent of 'ipa whoami' that returns the user principal in the summary field. There are some unnecessary imports, but that's a very minor remark, so ACK. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposal to reset master branch
On 08/03/2010 01:53 PM, Adam Young wrote: Proposal to reset master branch to last known good commit prior to the merge of the web UI code. Since the push on Friday complicates the source tree unnecessarily, making it difficult to track actual change4s done as well as to reproduce the current state of the tree, I propose the following. The current master branch gets tagged as webui-details on commit 47d4fcdd8178ec4b8403efa4f80eaa009c32d78b We then reset the HEAD of master to commit d4adbc8052faf18fb31e7b1865037aa107067d4b (Add container and initial ACIs for entitlement support) The impact would be minimal: it would only affect active developers that have pulled from the FreeeIPA git repo since the push happened. Since there has been a reversing commit on top of that, any code that they have should rebase equally well on top of either branch, since the code they expose is identical. Here are the git commands that would be executed on the repository. This would be run on the server where the git repo is hosted in order to have the desired effect, so they would be manipulating local branches, not remote. git --git-dir=$REPODIR branch -m master webui-details git --git-dir=$REPODIR branch master d4adbc8052faf18fb31e7b1865037aa107067d4b | | Please respond to support or reject this proposal. Nothing will happen until I have project sign-off. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Unless someone objects, I am going to reset the master branch to the commit d4adbc8052faf18fb31e7b1865037aa107067d4b at 2 PM Eastern Time today ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposal to reset master branch
On 08/05/2010 12:00 PM, Adam Young wrote: On 08/03/2010 01:53 PM, Adam Young wrote: Proposal to reset master branch to last known good commit prior to the merge of the web UI code. Since the push on Friday complicates the source tree unnecessarily, making it difficult to track actual change4s done as well as to reproduce the current state of the tree, I propose the following. The current master branch gets tagged as webui-details on commit 47d4fcdd8178ec4b8403efa4f80eaa009c32d78b We then reset the HEAD of master to commit d4adbc8052faf18fb31e7b1865037aa107067d4b (Add container and initial ACIs for entitlement support) The impact would be minimal: it would only affect active developers that have pulled from the FreeeIPA git repo since the push happened. Since there has been a reversing commit on top of that, any code that they have should rebase equally well on top of either branch, since the code they expose is identical. Here are the git commands that would be executed on the repository. This would be run on the server where the git repo is hosted in order to have the desired effect, so they would be manipulating local branches, not remote. git --git-dir=$REPODIR branch -m master webui-details git --git-dir=$REPODIR branch master d4adbc8052faf18fb31e7b1865037aa107067d4b || This has been executed. Please do a git fetch from origin in order to see the result. Any local branches that had previously been set up to track origin/master should now show that they have 200+ commits more than master. My suggestion is to rename these branches to old master using the commands (these assume the old local branch was named master): git fetch origin git checkout master git branch -m oldmaster git branch --track master origin/master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
Hello, It occurred to me that we can have a compromise. We can have two ways and let the admins to decide which model to follow. So the schema will look like this: The sudo rule entry will have a string attribute to put a command verbatim as it is designed now and an attribute that contains a DN of a group of the commands (or points to commands individually). It seems though that instead of having separate objects for a command with just one attribute (the command itself) and then have an group of commands object with pointer to individual commands we can have just a command group object with a multi value attribute for commands entered verbatim. This way we probably even do not need to have two attributes as I proposed above. Sorry for designing on the fly. So options are: 1) Leave as designed - does not provide a good role management (Nack) 2) Revert to original - too complex and limiting (Nack) 3) Have a hybrid of 1) 2) represented by two attributes 4) Make the rule reference an object named command group. The command group object will have a mv attribute with the commands IMO the last one is the simple compromise that addresses both concerns. Thanks Dmitri ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 495 user/group name validation
On 07/27/2010 04:38 PM, Rob Crittenden wrote: Add optional error message to pattern validator and enforces valid user/group names. The pattern validator by default displays the pattern that is being matched against. This isn't helpful, particularly for very hairy patterns. This adds a new parameter, pattern_errmsg, that is displayed on errors if set. ticket #11 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 496 fix RPC tests
On 07/27/2010 04:40 PM, Rob Crittenden wrote: Fix the RPC tests. The method name comes back as a unicode from xmlrpclib.loads(). With this and a fix in patch 495 all tests should now pass. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 499 show failures when adding/removing members from all group types
On 08/02/2010 06:14 PM, Rob Crittenden wrote: Properly show the members when an add/remove operation fails. The remove member function in baseldap was not returning failures at all. The add member function was only showing them in the group object. Most of the magic is handled in baseldap. Each plugin just needs to define object_name and object_name_plural. object_name must be all lower-case because fake-attributes are created so membership can be broken out per-object type. I left the plural name lower case as well. ticket 85 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ack ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 493 skip lang test if not built
On 08/04/2010 03:56 PM, Adam Young wrote: On 07/26/2010 06:01 PM, Rob Crittenden wrote: The i18n tests were failing if the language wasn't built. Skip it in this case and inform the user what to run to get the test to execute. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Can't quite ACK yet. While this change does what it says, If I do: pushd install/po/ make test_lang And then re-run the test, I get the same test skipped: Test gettext translation ... SKIP: Test language not available, run make test_lang in install/po ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Actually, I'll ack it, but we should open another ticket, or keep the ticket open, for the make command. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Patch] Simple-plugin-for-reflecting-user-principal
On 08/05/2010 11:01 AM, Pavel Zůna wrote: On 2010-08-04 01:49, Adam Young wrote: This is a required patch for the UI code. Basically, the Kerberos authentication method does not provide any way for the web ui to know who logged in. With this patch, we can do the equivalent of 'ipa whoami' that returns the user principal in the summary field. There are some unnecessary imports, but that's a very minor remark, so ACK. Pavel Pushed to master, with extra imports removed (and retested). ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
