From rcritten at redhat.com Mon Aug 2 20:32:14 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Aug 2010 16:32:14 -0400 Subject: [Freeipa-devel] Leap of faith: Merging in the new web UI In-Reply-To: <4C530950.3000604@redhat.com> References: <4C530950.3000604@redhat.com> Message-ID: <4C572B4E.40805@redhat.com> Adam Young wrote: > Rob commented earlier this week that the new Web UI code would require a > leap of faith for merging into the mainline. I've decided to make that > leap, and merged and pushed the code to master. > > > With the small exception of a the whoami plugin, this code does not make > any changes to the CLI, and should have small to non-existant effects to > any CLI code. > > We had already stripped out the old web UI in a different patch, so this > change doesn't conflict with that, either. > > > If you are working with development builds of FreeIPA, please take the > time to look at it and evaluate. I've reverted this patch since it didn't go through our normal review process. The reverted patch is attached, thanks to Stephen Gallagher for generating it. Adam acked the patch in #freeipa. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Revert-WebUI-changes.patch Type: application/mbox Size: 404859 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 2 22:14:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Aug 2010 18:14:08 -0400 Subject: [Freeipa-devel] [PATCH] 499 show failures when adding/removing members from all group types Message-ID: <4C574330.3060908@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-499-member.patch Type: application/mbox Size: 4732 bytes Desc: not available URL: From ayoung at redhat.com Tue Aug 3 17:53:37 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 13:53:37 -0400 Subject: [Freeipa-devel] Proposal to reset master branch Message-ID: <4C5857A1.8030809@redhat.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrixonline.com Tue Aug 3 22:35:38 2010 From: JR.Aquino at citrixonline.com (JR Aquino) Date: Tue, 3 Aug 2010 15:35:38 -0700 Subject: [Freeipa-devel] Sudoers schema Message-ID: ~ipaSudoComand~ I'd like to know what the group thinks about the possibility of using ipaSudoComand as a DN to an object containing sudoCommand attributes, rather than just being a static attribute itself. I believe this is already being done/suggested in a similar manor with memberUser and memberHost. We found here at Citrix Online that the Role's tend to reuse all 3 elements pretty heavily: userGroups, hostGroups, and commandGroups. For PCI-DSS reasons, it tends to make it a lot easier to say: "These groups of users have login rights to these groups of hosts, and are permitted to sudo these groups of commands." Rather then having to search for individual attribute entries in the role objects themselves. ~hostMask~ I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. ~Using memberUser as slight of hand over netgroups~ It's my understanding that the sudo source does a "getent netgroup" style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... ~users by uid and gid~ If by uid/gid he means numerical representation, then I say, I wouldn't worry about it. Fully spelled out alpha Username / Group entries seem sane. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 6500 Hollister Avenue | Goleta, CA 93117 From dpal at redhat.com Tue Aug 3 23:29:14 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Aug 2010 19:29:14 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: References: Message-ID: <4C58A64A.9060009@redhat.com> JR Aquino wrote: > ~ipaSudoComand~ > > I'd like to know what the group thinks about the possibility of using ipaSudoComand as a DN to an object containing sudoCommand attributes, rather than just being a static attribute itself. > > I believe this is already being done/suggested in a similar manor with memberUser and memberHost. > > We found here at Citrix Online that the Role's tend to reuse all 3 elements pretty heavily: userGroups, hostGroups, and commandGroups. > > For PCI-DSS reasons, it tends to make it a lot easier to say: > > "These groups of users have login rights to these groups of hosts, and are permitted to sudo these groups of commands." > > Rather then having to search for individual attribute entries in the role objects themselves. > > That was the original design, however I was told that this is not something people will be interested in. Thanks for you data point but to change it we probably need couple more data points and comments. > ~hostMask~ > > I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. > This will really be a relieve not to support it for now. > ~Using memberUser as slight of hand over netgroups~ > > It's my understanding that the sudo source does a "getent netgroup" style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... > > The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... > The problem is that it is reverse. Since for IPA the host groups are primary concepts and the netgroup is something we want to phase out the logic is the following: * Hosts are grouped into the host groups. * A netgroup is a shallow container around the host group. In our model host group can be a member of the netgroup not vice versa. But this is not related to the question at hand. The question regarding memberUser is that the sudo spec allows using a netgroup to refer to a set of users. This is really a atavism to use netgroups to reference a set of users instead of a direct user group. The question is: can we assume it to be an atavism and not support it. I updated the page so this point is more clear. > ~users by uid and gid~ > > If by uid/gid he means numerical representation, Yes this is number vs. string question. > then I say, I wouldn't worry about it. Fully spelled out alpha Username / Group entries seem sane. > Good! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino, GCIH | Information Security Specialist > Citrix Online | 6500 Hollister Avenue | Goleta, CA 93117 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Thank you for the comment. I think the only missing point is about "negating the whole rule" instead of per command. Do you agree that it would be more manageable as proposed? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Tue Aug 3 23:46:43 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 19:46:43 -0400 Subject: [Freeipa-devel] [Patch] Install infrastructure for new web UI. Message-ID: <4C58AA63.5080102@redhat.com> This patch is one of a series that are the web UI code broken out into 4 separate patches. This one contains the changes to the files used for the build and configure infrastructure code to support the new web ui. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0003-Changes-to-the-install-and-config-files-to-support-d.patch URL: From ayoung at redhat.com Tue Aug 3 23:49:32 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 19:49:32 -0400 Subject: [Freeipa-devel] [Patch] Simple-plugin-for-reflecting-user-principal Message-ID: <4C58AB0C.7040409@redhat.com> 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Simple-plugin-for-reflecting-user-principal-back-on-.patch URL: From ayoung at redhat.com Tue Aug 3 23:52:51 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 19:52:51 -0400 Subject: [Freeipa-devel] [Patch] Changes to the python infrastructure-supporting-the-web ui Message-ID: <4C58ABD3.3080107@redhat.com> This code contains the changes to the python code necessary to support the new web ui. It handles the changes to the baseldap code necessary to expose the meta data to the front end, as well as the installation support. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0004-Changes-to-the-python-infrastructure-supporting-the-.patch URL: From ayoung at redhat.com Tue Aug 3 23:51:01 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 19:51:01 -0400 Subject: [Freeipa-devel] [patch] The Javascript code for the new web ui Message-ID: <4C58AB65.4030007@redhat.com> This code is the javascript, html and sample data code at the heart of the new web UI. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-The-Javascript-code-for-the-new-web-UI.patch URL: From ayoung at redhat.com Wed Aug 4 00:03:24 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Aug 2010 20:03:24 -0400 Subject: [Freeipa-devel] [Patch] Images for the web UI Message-ID: <4C58AE4C.6030800@redhat.com> THis is the set of images for the web ui, pulled out into a separate patch to minimize the size of the non-binary patches. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0005-Images-for-the-new-web-ui.patch URL: From JR.Aquino at citrixonline.com Wed Aug 4 01:51:27 2010 From: JR.Aquino at citrixonline.com (JR Aquino) Date: Tue, 3 Aug 2010 18:51:27 -0700 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C58A64A.9060009@redhat.com> References: <4C58A64A.9060009@redhat.com> Message-ID: <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> > That was the original design, however I was told that this is not > something people will be interested in. Thanks for you data point but to > change it we probably need couple more data points and comments. I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! >> ~hostMask~ >> >> I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. >> > > This will really be a relieve not to support it for now. Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. > >> ~Using memberUser as slight of hand over netgroups~ >> >> It's my understanding that the sudo source does a "getent netgroup" style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... >> >> The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... >> > > The problem is that it is reverse. > Since for IPA the host groups are primary concepts and the netgroup is > something we want to phase out the logic is the following: > * Hosts are grouped into the host groups. > * A netgroup is a shallow container around the host group. > In our model host group can be a member of the netgroup not vice versa. > But this is not related to the question at hand. > > The question regarding memberUser is that the sudo spec allows using a > netgroup to refer to a set of users. This is really a atavism to use > netgroups to reference a set of users instead of a direct user group. > The question is: can we assume it to be an atavism and not support it. > I updated the page so this point is more clear. Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. From dpal at redhat.com Wed Aug 4 13:26:08 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Aug 2010 09:26:08 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> Message-ID: <4C596A70.9080500@redhat.com> JR Aquino wrote: >> That was the original design, however I was told that this is not >> something people will be interested in. Thanks for you data point but to >> change it we probably need couple more data points and comments. >> > > I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. > > I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). > > With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. > > With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. > > I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! > > I completely agree with you but the main opponent of the idea is on vacation now. It will be unfair to revert in his absence without a majority. Can someone else express his opinion on the matter? >>> ~hostMask~ >>> >>> I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. >>> >>> >> This will really be a relieve not to support it for now. >> > > Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. > > Sold! >>> ~Using memberUser as slight of hand over netgroups~ >>> >>> It's my understanding that the sudo source does a "getent netgroup" style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... >>> >>> The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... >>> >>> >> The problem is that it is reverse. >> Since for IPA the host groups are primary concepts and the netgroup is >> something we want to phase out the logic is the following: >> * Hosts are grouped into the host groups. >> * A netgroup is a shallow container around the host group. >> In our model host group can be a member of the netgroup not vice versa. >> But this is not related to the question at hand. >> >> The question regarding memberUser is that the sudo spec allows using a >> netgroup to refer to a set of users. This is really a atavism to use >> netgroups to reference a set of users instead of a direct user group. >> The question is: can we assume it to be an atavism and not support it. >> I updated the page so this point is more clear. >> > > Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. > > I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. > > > We will cross this bridge when time comes. We have some thoughts and considerations. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Aug 4 14:14:17 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Aug 2010 10:14:17 -0400 Subject: [Freeipa-devel] [PATCH] 500 configure nslcd and a host of other ldap files Message-ID: <4C5975B9.50206@redhat.com> Configure nslcd and a host of possible systems that use LDAP. We will update any/all of /etc/ldap.conf, /etc/nss_ldap.conf, /etc/libnss-ldap.conf and /etc/pam_ldap.conf. nslcd is the replacement for nss_ldap. ticket 50 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-500-client.patch Type: application/mbox Size: 5033 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 4 15:05:11 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 11:05:11 -0400 Subject: [Freeipa-devel] [patch] The Javascript code for the new web ui In-Reply-To: <4C58AB65.4030007@redhat.com> References: <4C58AB65.4030007@redhat.com> Message-ID: <4C5981A7.7060706@redhat.com> On 08/03/2010 07:51 PM, Adam Young wrote: > This code is the javascript, html and sample data code at the heart of > the new web UI. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Note that the files that begin with jquery are from the jquery project, and do not need an explicit review. These are: install/static/jquery.cookie.js and install/static/jquery.js. The file install/static/json2.js is from JSON.org, and provides JSON translation for older browsers. The remaining files are our original code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 4 15:09:28 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Aug 2010 11:09:28 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C596A70.9080500@redhat.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> Message-ID: <4C5982A8.6050000@redhat.com> Dmitri Pal wrote: > JR Aquino wrote: >>> That was the original design, however I was told that this is not >>> something people will be interested in. Thanks for you data point but to >>> change it we probably need couple more data points and comments. >>> >> I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. >> >> I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). >> >> With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. >> >> With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. >> >> I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! >> >> > I completely agree with you but the main opponent of the idea is on > vacation now. > It will be unfair to revert in his absence without a majority. > > Can someone else express his opinion on the matter? One was performance, memberOf isn't free. The second was complexity. Lets say you define command R and assign it to command groups A, B and C. The admin of group B needs to tweak the command a bit so he modifies R. This could have a negative impact on command groups A and C. So for simplicity he may make a command T instead. And the admins of groups A and C, having seem the problem of R changing make their own new commands as well. So now 3 (or 4) commands all do more or less the same thing. So the argument goes that for security and simplicity the admins will create their own rules every time they create an sudo rule (except perhaps in the initial config). rob > >>>> ~hostMask~ >>>> >>>> I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. >>>> >>>> >>> This will really be a relieve not to support it for now. >>> >> Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. >> >> > > Sold! > >>>> ~Using memberUser as slight of hand over netgroups~ >>>> >>>> It's my understanding that the sudo source does a "getent netgroup" style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... >>>> >>>> The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... >>>> >>>> >>> The problem is that it is reverse. >>> Since for IPA the host groups are primary concepts and the netgroup is >>> something we want to phase out the logic is the following: >>> * Hosts are grouped into the host groups. >>> * A netgroup is a shallow container around the host group. >>> In our model host group can be a member of the netgroup not vice versa. >>> But this is not related to the question at hand. >>> >>> The question regarding memberUser is that the sudo spec allows using a >>> netgroup to refer to a set of users. This is really a atavism to use >>> netgroups to reference a set of users instead of a direct user group. >>> The question is: can we assume it to be an atavism and not support it. >>> I updated the page so this point is more clear. >>> >> Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. >> >> I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. >> >> >> > We will cross this bridge when time comes. We have some thoughts and > considerations. > > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> > > From JR.Aquino at citrixonline.com Wed Aug 4 16:15:17 2010 From: JR.Aquino at citrixonline.com (JR Aquino) Date: Wed, 4 Aug 2010 09:15:17 -0700 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C5982A8.6050000@redhat.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> <4C5982A8.6050000@redhat.com> Message-ID: <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> > One was performance, memberOf isn't free. > > The second was complexity. Lets say you define command R and assign it > to command groups A, B and C. The admin of group B needs to tweak the > command a bit so he modifies R. This could have a negative impact on > command groups A and C. > > So for simplicity he may make a command T instead. And the admins of > groups A and C, having seem the problem of R changing make their own new > commands as well. So now 3 (or 4) commands all do more or less the > same thing. > > So the argument goes that for security and simplicity the admins will > create their own rules every time they create an sudo rule (except > perhaps in the initial config). > > rob I understand the scenario presented, but that depiction doesn't sound like ROLE based authorization... That sounds more like administrative group based authorization... Privilege escalation configuration is serious business and I would hope that a responsible centralized entity inside an organization is managing these rules... I.E. Web-Developers may need to have "sudo less, sudo grep, sudo netstat, sudo top" and perhaps Application-Developers need "sudo less, sudo netstat, sudo top, AND sudo custom_app.py"... You wouldn't create 1 flat rule and assign it to both groups... you would create multiple groups and stack them as necessary. So perhaps web-dev's get sudo_rule_read_tools, and the app-devs get BOTH sudo_rule_read_tools AND sudo_rule_cust_apps. Roles should clearly define what rights users have within the infrastructure... if they need to be 'tweaked' to accommodate others, then we are talking about a completely different organizational role, one that should be documented and separate from similar roles. If the cost of memberO if too expensive perhaps we should be writing native sudoRole Objects and utilizing just the netgroup translation if compat and native ipa is too costly for sudoers to exist in a new format. We have an opportunity here to innovate and create something really new for the community rather than just gluing pieces of existing technology together. As it stands, it sounds like the Role Base Authorization as it applies to 'can I login' and 'can I run tcpdump' are being thought of as 2 disparately separate concepts/objects in the directory when in reality there are very much components of the larger idea of RBAC/HBAC... Lets continue down the rabbit hole, it feels important to get this stuff right! ~Measure twice, cut once~ -Jr From ayoung at redhat.com Wed Aug 4 17:12:01 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 13:12:01 -0400 Subject: [Freeipa-devel] [PATCH] 451 fix i18n test In-Reply-To: <4BFE81B2.80604@redhat.com> References: <4BF6FC9A.4010307@redhat.com> <4BFE81B2.80604@redhat.com> Message-ID: <4C599F61.9000308@redhat.com> On 05/27/2010 10:29 AM, Pavel Zuna wrote: > On 05/21/2010 11:35 PM, Rob Crittenden wrote: >> Fix this test to work from source tree root >> >> It would work if you ran the test from its location in tests/test_ipalib >> but this isn't the most common method. If you want to run it >> individually >> you can do: >> >> $ ./make-test tests/test_ipalib/test_text.py >> >> rob >> > Maybe I'm doing something wrong, but I'm still getting this one error: > > ====================================================================== > ERROR: Test gettext translation > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, in > runTest > self.test(*self.arg) > File "/root/freeipa/tests/test_ipalib/test_text.py", line 89, in > test_gettext > msgid = get_msgid(test_file) > File "/root/freeipa/tests/test_ipalib/test_text.py", line 43, in > get_msgid > f = open(po_file) > IOError: [Errno 2] No such file or directory: 'install/po/test.po' > > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK From ayoung at redhat.com Wed Aug 4 17:19:36 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 13:19:36 -0400 Subject: [Freeipa-devel] [PATCH] 474 add missing version file In-Reply-To: <4C23CE92.1030803@redhat.com> References: <4C23CE92.1030803@redhat.com> Message-ID: <4C59A128.90803@redhat.com> On 06/24/2010 05:30 PM, Rob Crittenden wrote: > I missed adding a new file in the replication version plugin. I went > ahead and pushed it to fix the build. > > I also updated the minimum level of 389-ds-base to 1.2.6. This is > still in testing but the versioning plugin won't work without it. > > To pull this from Fedora do: > > # yum --enablerepo=updates-testing update 389-ds-base > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I went to test this, and found that patch would not apply. It looks like it was applied with commit: 97bd59d869a4eafb00574f26ba46ae5a4e0d465f -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Aug 4 17:54:42 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 13:54:42 -0400 Subject: [Freeipa-devel] [PATCH] 484 add framework for testing other cmdlines In-Reply-To: <4C3B8E53.9040804@redhat.com> References: <4C3B8E53.9040804@redhat.com> Message-ID: <4C59A962.9030802@redhat.com> On 07/12/2010 05:51 PM, Rob Crittenden wrote: > In order to test service-disable I needed a way to get a keytab. For > this we need to run ipa-getkeytab so I added some framework to be able > to run the non-ipa command-line utilities. > > Right now I'm just testing the very basics of ipa-getkeytab but it's a > start. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Aug 4 18:42:18 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 14:42:18 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C532FE1.4040907@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> Message-ID: <4C59B48A.4070508@redhat.com> 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > I can't get this patch to apply: > > [ayoung at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Aug 4 19:00:28 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 15:00:28 -0400 Subject: [Freeipa-devel] [PATCH] 491 Fix replacing a certificate in a service. In-Reply-To: <4C48A6B4.9070101@redhat.com> References: <4C48A612.5070409@redhat.com> <4C48A6B4.9070101@redhat.com> Message-ID: <4C59B8CC.80606@redhat.com> On 07/22/2010 04:14 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> When a service has a certificate and the CA backend doesn't support >> revocation (like selfsign) then we simply drop the old certificate in >> preparation for adding a new one. We weren't setting the >> usercertificate attribute to None so there was nothing to do in >> ldap_update(). >> >> Added a test case for this situation to ensure that re-issuing a >> certificate works. >> > > This patch relies on patch 490 to apply. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK From ayoung at redhat.com Wed Aug 4 19:44:00 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 15:44:00 -0400 Subject: [Freeipa-devel] [PATCH] 492 fix env plugin In-Reply-To: <4C4E0582.2030800@redhat.com> References: <4C4E0582.2030800@redhat.com> Message-ID: <4C59C300.401@redhat.com> On 07/26/2010 06:00 PM, Rob Crittenden wrote: > The env plugin was displaying just the number of entries in the > environment, not the values. Add an --all flag to print those, on by > default. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Aug 4 19:44:14 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Aug 2010 15:44:14 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> <4C5982A8.6050000@redhat.com> <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> Message-ID: <4C59C30E.8000503@redhat.com> JR Aquino wrote: >> One was performance, memberOf isn't free. >> >> The second was complexity. Lets say you define command R and assign it >> to command groups A, B and C. The admin of group B needs to tweak the >> command a bit so he modifies R. This could have a negative impact on >> command groups A and C. >> >> So for simplicity he may make a command T instead. And the admins of >> groups A and C, having seem the problem of R changing make their own new >> commands as well. So now 3 (or 4) commands all do more or less the >> same thing. >> >> So the argument goes that for security and simplicity the admins will >> create their own rules every time they create an sudo rule (except >> perhaps in the initial config). >> >> rob >> > > I understand the scenario presented, but that depiction doesn't sound like ROLE based authorization... That sounds more like administrative group based authorization... > > Privilege escalation configuration is serious business and I would hope that a responsible centralized entity inside an organization is managing these rules... > > I.E. Web-Developers may need to have "sudo less, sudo grep, sudo netstat, sudo top" and perhaps Application-Developers need "sudo less, sudo netstat, sudo top, AND sudo custom_app.py"... > > You wouldn't create 1 flat rule and assign it to both groups... you would create multiple groups and stack them as necessary. So perhaps web-dev's get sudo_rule_read_tools, and the app-devs get BOTH sudo_rule_read_tools AND sudo_rule_cust_apps. > > Roles should clearly define what rights users have within the infrastructure... if they need to be 'tweaked' to accommodate others, then we are talking about a completely different organizational role, one that should be documented and separate from similar roles. > > If the cost of memberO if too expensive perhaps we should be writing native sudoRole Objects and utilizing just the netgroup translation if compat and native ipa is too costly for sudoers to exist in a new format. > > We have an opportunity here to innovate and create something really new for the community rather than just gluing pieces of existing technology together. > > As it stands, it sounds like the Role Base Authorization as it applies to 'can I login' and 'can I run tcpdump' are being thought of as 2 disparately separate concepts/objects in the directory when in reality there are very much components of the larger idea of RBAC/HBAC... > > Lets continue down the rabbit hole, it feels important to get this stuff right! ~Measure twice, cut once~ > That was my vision too this is why I suggested the grouping of the commands in the first place. I actually agree will all your points since they were mine also. But I am not sure how to proceed with this. I am leaving for vacation for couple weeks on Tuesday I will try to update the page with the alternative suggestion and schema but final decision will probably be done when everybody is back. > -Jr > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Wed Aug 4 19:56:12 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Aug 2010 15:56:12 -0400 Subject: [Freeipa-devel] [PATCH] 493 skip lang test if not built In-Reply-To: <4C4E05BF.2090205@redhat.com> References: <4C4E05BF.2090205@redhat.com> Message-ID: <4C59C5DC.7030801@redhat.com> 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Aug 4 20:01:46 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Aug 2010 16:01:46 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C59B48A.4070508@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> Message-ID: <4C59C72A.3040407@redhat.com> 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 at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> I can't get this patch to apply: >> >> [ayoung at 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 at 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Aug 5 12:45:19 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Aug 2010 08:45:19 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C59B48A.4070508@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> Message-ID: <4C5AB25F.8090106@redhat.com> 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 at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> I can't get this patch to apply: >> >> [ayoung at 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 at 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 From rcritten at redhat.com Thu Aug 5 12:49:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Aug 2010 08:49:02 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C59C72A.3040407@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> <4C59C72A.3040407@redhat.com> Message-ID: <4C5AB33E.90905@redhat.com> 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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> I can't get this patch to apply: >>> >>> [ayoung at 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 at 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 From ayoung at redhat.com Thu Aug 5 14:22:08 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 10:22:08 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C5AB25F.8090106@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> <4C5AB25F.8090106@redhat.com> Message-ID: <4C5AC910.4060104@redhat.com> 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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> I can't get this patch to apply: >>> >>> [ayoung at 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 at 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? From rcritten at redhat.com Thu Aug 5 14:36:48 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Aug 2010 10:36:48 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C5AC910.4060104@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> <4C5AB25F.8090106@redhat.com> <4C5AC910.4060104@redhat.com> Message-ID: <4C5ACC80.2020505@redhat.com> Adam Young wrote: > 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 at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> I can't get this patch to apply: >>>> >>>> [ayoung at 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 at 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? > > No, that's about it. --force just says "don't bother with DNS lookup, user claims to know what they are doing." I looked into this and --force isn't needed with service-add-host. This adds hosts that are allowed to manage the service. The host needs to exist in IPA so therefore must already exist. Therefore --force isn't needed. What is lacking in the context of the patch is error reporting which hosts failed to add. This is addressed in part by patch 499. All that is needed is the following: diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 11fd18e..a17af89 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -615,6 +615,9 @@ class LDAPAddMember(LDAPModMember): Str('member', label=_('Failed members'), ), + Str('managedby', + label=_('Failed members'), + ), ) def execute(self, *keys, **options): @@ -720,6 +723,9 @@ class LDAPRemoveMember(LDAPModMember): Str('member', label=_('Failed members'), ), + Str('managedby', + label=_('Failed members'), + ), ) def execute(self, *keys, **options): I'll submit that as a separate patch shortly. rob From pzuna at redhat.com Thu Aug 5 15:01:09 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 05 Aug 2010 17:01:09 +0200 Subject: [Freeipa-devel] [Patch] Simple-plugin-for-reflecting-user-principal In-Reply-To: <4C58AB0C.7040409@redhat.com> References: <4C58AB0C.7040409@redhat.com> Message-ID: <4C5AD235.7060408@redhat.com> 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 From ayoung at redhat.com Thu Aug 5 16:00:39 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 12:00:39 -0400 Subject: [Freeipa-devel] Proposal to reset master branch In-Reply-To: <4C5857A1.8030809@redhat.com> References: <4C5857A1.8030809@redhat.com> Message-ID: <4C5AE027.5000100@redhat.com> 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 5 18:06:50 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 14:06:50 -0400 Subject: [Freeipa-devel] Proposal to reset master branch In-Reply-To: <4C5AE027.5000100@redhat.com> References: <4C5857A1.8030809@redhat.com> <4C5AE027.5000100@redhat.com> Message-ID: <4C5AFDBA.5060204@redhat.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 5 19:38:08 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Aug 2010 15:38:08 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C59C30E.8000503@redhat.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> <4C5982A8.6050000@redhat.com> <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> <4C59C30E.8000503@redhat.com> Message-ID: <4C5B1320.6060602@redhat.com> 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 From ayoung at redhat.com Thu Aug 5 19:49:26 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 15:49:26 -0400 Subject: [Freeipa-devel] [PATCH] 495 user/group name validation In-Reply-To: <4C4F43C4.4010201@redhat.com> References: <4C4F43C4.4010201@redhat.com> Message-ID: <4C5B15C6.9030800@redhat.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 5 19:50:05 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 15:50:05 -0400 Subject: [Freeipa-devel] [PATCH] 496 fix RPC tests In-Reply-To: <4C4F4423.4020008@redhat.com> References: <4C4F4423.4020008@redhat.com> Message-ID: <4C5B15ED.4060909@redhat.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 5 19:50:58 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 15:50:58 -0400 Subject: [Freeipa-devel] [PATCH] 497 check for command existence in tests In-Reply-To: <4C51966E.1060105@redhat.com> References: <4C51966E.1060105@redhat.com> Message-ID: <4C5B1622.4020701@redhat.com> On 07/29/2010 10:55 AM, Rob Crittenden wrote: > The command tests rely on the in-tree version of the command. If you > haven't done a 'make' in the tree the command won't exist so isn't > testable. This adds a test for command existence and raises a specific > error. It was previously failing with some pretty unhelpful error > messages. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 5 19:52:08 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 15:52:08 -0400 Subject: [Freeipa-devel] [PATCH] 499 show failures when adding/removing members from all group types In-Reply-To: <4C574330.3060908@redhat.com> References: <4C574330.3060908@redhat.com> Message-ID: <4C5B1668.4050308@redhat.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 5 19:52:53 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 15:52:53 -0400 Subject: [Freeipa-devel] [PATCH] 493 skip lang test if not built In-Reply-To: <4C59C5DC.7030801@redhat.com> References: <4C4E05BF.2090205@redhat.com> <4C59C5DC.7030801@redhat.com> Message-ID: <4C5B1695.5040403@redhat.com> 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 at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Aug 6 00:40:16 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Aug 2010 20:40:16 -0400 Subject: [Freeipa-devel] [Patch] Simple-plugin-for-reflecting-user-principal In-Reply-To: <4C5AD235.7060408@redhat.com> References: <4C58AB0C.7040409@redhat.com> <4C5AD235.7060408@redhat.com> Message-ID: <4C5B59F0.1090900@redhat.com> 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). From rcritten at redhat.com Fri Aug 6 02:50:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Aug 2010 22:50:39 -0400 Subject: [Freeipa-devel] [PATCH] 502 hosts can fetch keytabs Message-ID: <4C5B787F.5020905@redhat.com> Enable a host to retrieve a keytab for all its services. Using the host service principal one should be able to retrieve a keytab for other services for the host using ipa-getkeytab. This required a number of changes: - allow hosts in the service's managedby to write krbPrincipalKey - automatically add the host to managedby when a service is created - fix ipa-getkeytab to return the entire prinicpal and not just the first data element. It was returning "host" from the service tgt and not host/ipa.example.com - fix the display of the managedby attribute in the service plugin This led to a number of changes in the service unit tests. I took the opportunity to switch to the Declarative scheme and tripled the number of tests we were doing. This shed some light on a few bugs in the plugin: - if a service had a bad usercertificate it was impossible to delete the service. I made it a bit more flexible. - I added a summary for the mod and find commands - has_keytab wasn't being set in the find output This is for ticket 68 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-502-service.patch Type: application/mbox Size: 24551 bytes Desc: not available URL: From adam at younglogic.com Thu Aug 5 23:25:13 2010 From: adam at younglogic.com (Adam Young) Date: Thu, 05 Aug 2010 19:25:13 -0400 Subject: [Freeipa-devel] gitweb doesn't show the correct histroy for webui-details Message-ID: <4C5B4859.3060207@younglogic.com> The recent reset of the origin/master branch for FreeIPA has had the side effec that it left gitweb confused. I've noticed the same thing on both my personal gitweb and the fedorahosted.org server: webui-details seems to show the tree from the same place as master currently shows. However, a git checkout and viewing the log (or in gitk) shows the correct history. Thus, I think Gitweb is confused. From ayoung at redhat.com Fri Aug 6 15:35:21 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 11:35:21 -0400 Subject: [Freeipa-devel] [patch] The Javascript code for the new web ui In-Reply-To: <4C5981A7.7060706@redhat.com> References: <4C58AB65.4030007@redhat.com> <4C5981A7.7060706@redhat.com> Message-ID: <4C5C2BB9.805@redhat.com> On 08/04/2010 11:05 AM, Adam Young wrote: > On 08/03/2010 07:51 PM, Adam Young wrote: >> This code is the javascript, html and sample data code at the heart >> of the new web UI. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Note that the files that begin with jquery are from the jquery > project, and do not need an explicit review. These are: > install/static/jquery.cookie.js and install/static/jquery.js. > > The file install/static/json2.js is from JSON.org, and provides JSON > translation for older browsers. > > > The remaining files are our original code. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Here's an updated patch, with whitespace cleaned up -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-The-Javascript-code-for-the-new-web-UI.patch URL: From rcritten at redhat.com Fri Aug 6 15:46:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 11:46:58 -0400 Subject: [Freeipa-devel] [patch] The Javascript code for the new web ui In-Reply-To: <4C5C2BB9.805@redhat.com> References: <4C58AB65.4030007@redhat.com> <4C5981A7.7060706@redhat.com> <4C5C2BB9.805@redhat.com> Message-ID: <4C5C2E72.7050701@redhat.com> Adam Young wrote: > On 08/04/2010 11:05 AM, Adam Young wrote: >> On 08/03/2010 07:51 PM, Adam Young wrote: >>> This code is the javascript, html and sample data code at the heart >>> of the new web UI. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Note that the files that begin with jquery are from the jquery >> project, and do not need an explicit review. These are: >> install/static/jquery.cookie.js and install/static/jquery.js. >> >> The file install/static/json2.js is from JSON.org, and provides JSON >> translation for older browsers. >> >> >> The remaining files are our original code. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Here's an updated patch, with whitespace cleaned up > > There is still some whitespace in the .inc files but we'll address that in the future (probably by removing the files altogether). jquery has a ton of trailing whitespace in it but we'll just have to live with it. ack rob From rcritten at redhat.com Fri Aug 6 15:47:18 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 11:47:18 -0400 Subject: [Freeipa-devel] [Patch] Install infrastructure for new web UI. In-Reply-To: <4C58AA63.5080102@redhat.com> References: <4C58AA63.5080102@redhat.com> Message-ID: <4C5C2E86.40002@redhat.com> Adam Young wrote: > This patch is one of a series that are the web UI code broken out into 4 > separate patches. This one contains the changes to the files used for > the build and configure infrastructure code to support the new web ui. > ack From rcritten at redhat.com Fri Aug 6 15:47:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 11:47:38 -0400 Subject: [Freeipa-devel] [Patch] Images for the web UI In-Reply-To: <4C58AE4C.6030800@redhat.com> References: <4C58AE4C.6030800@redhat.com> Message-ID: <4C5C2E9A.1040904@redhat.com> Adam Young wrote: > THis is the set of images for the web ui, pulled out into a separate > patch to minimize the size of the non-binary patches. ack From rcritten at redhat.com Fri Aug 6 15:51:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 11:51:45 -0400 Subject: [Freeipa-devel] [Patch] Changes to the python infrastructure-supporting-the-web ui In-Reply-To: <4C58ABD3.3080107@redhat.com> References: <4C58ABD3.3080107@redhat.com> Message-ID: <4C5C2F91.7080005@redhat.com> Adam Young wrote: > This code contains the changes to the python code necessary to support > the new web ui. It handles the changes to the baseldap code necessary > to expose the meta data to the front end, as well as the installation > support. nack. About 75 tests are failing with this patch. I didn't investigate them in detail but it looks like memberof isn't being removed after a member attribute is converted. wsgi.py has a ton of imports added that aren't being used. There is an indention change in ipalib/frontend.py that doesn't seem necessary. The timelimit patch is gonig to conflict with a timelimit patch I had submitted previously (patch titled 'use time and search limit values from cn=ipaconfig'). Not even in terms of code but in forcing a default that does not tie into the global config. I think I'd rather have this as an optional argument do no default and autofill is needed. rob From ayoung at redhat.com Fri Aug 6 15:57:07 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 11:57:07 -0400 Subject: [Freeipa-devel] [Patch] Changes to the python infrastructure-supporting-the-web ui In-Reply-To: <4C5C2F91.7080005@redhat.com> References: <4C58ABD3.3080107@redhat.com> <4C5C2F91.7080005@redhat.com> Message-ID: <4C5C30D3.5000907@redhat.com> On 08/06/2010 11:51 AM, Rob Crittenden wrote: > Adam Young wrote: >> This code contains the changes to the python code necessary to >> support the new web ui. It handles the changes to the baseldap code >> necessary to expose the meta data to the front end, as well as the >> installation support. > > nack. > > About 75 tests are failing with this patch. I didn't investigate them > in detail but it looks like memberof isn't being removed after a > member attribute is converted. > > wsgi.py has a ton of imports added that aren't being used. > > There is an indention change in ipalib/frontend.py that doesn't seem > necessary. > > The timelimit patch is gonig to conflict with a timelimit patch I had > submitted previously (patch titled 'use time and search limit values > from cn=ipaconfig'). Not even in terms of code but in forcing a > default that does not tie into the global config. I think I'd rather > have this as an optional argument do no default and autofill is needed. > > rob I'm going to fob this work off on pzuna, as these are his changes that I just merged in. From ayoung at redhat.com Fri Aug 6 15:59:23 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 11:59:23 -0400 Subject: [Freeipa-devel] [Patch] Install infrastructure for new web UI. In-Reply-To: <4C5C2E86.40002@redhat.com> References: <4C58AA63.5080102@redhat.com> <4C5C2E86.40002@redhat.com> Message-ID: <4C5C315B.5070804@redhat.com> On 08/06/2010 11:47 AM, Rob Crittenden wrote: > Adam Young wrote: >> This patch is one of a series that are the web UI code broken out >> into 4 separate patches. This one contains the changes to the files >> used for the build and configure infrastructure code to support the >> new web ui. >> > > ack pushed to master From ayoung at redhat.com Fri Aug 6 15:59:39 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 11:59:39 -0400 Subject: [Freeipa-devel] [patch] The Javascript code for the new web ui In-Reply-To: <4C5C2E72.7050701@redhat.com> References: <4C58AB65.4030007@redhat.com> <4C5981A7.7060706@redhat.com> <4C5C2BB9.805@redhat.com> <4C5C2E72.7050701@redhat.com> Message-ID: <4C5C316B.1090400@redhat.com> On 08/06/2010 11:46 AM, Rob Crittenden wrote: > Adam Young wrote: >> On 08/04/2010 11:05 AM, Adam Young wrote: >>> On 08/03/2010 07:51 PM, Adam Young wrote: >>>> This code is the javascript, html and sample data code at the heart >>>> of the new web UI. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Note that the files that begin with jquery are from the jquery >>> project, and do not need an explicit review. These are: >>> install/static/jquery.cookie.js and install/static/jquery.js. >>> >>> The file install/static/json2.js is from JSON.org, and provides JSON >>> translation for older browsers. >>> >>> >>> The remaining files are our original code. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Here's an updated patch, with whitespace cleaned up >> >> > > There is still some whitespace in the .inc files but we'll address > that in the future (probably by removing the files altogether). jquery > has a ton of trailing whitespace in it but we'll just have to live > with it. > > ack > > rob pushed to master From rcritten at redhat.com Fri Aug 6 17:10:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:10:08 -0400 Subject: [Freeipa-devel] [PATCH] 501 report managedby errors Message-ID: <4C5C41F0.4050901@redhat.com> Report failures when adding/removing members to the managedby attribute (services and hosts). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-501-managedby.patch Type: application/mbox Size: 1037 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 6 17:10:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:10:52 -0400 Subject: [Freeipa-devel] [PATCH] 454 add su-l hbac service In-Reply-To: <4BFE8B47.50901@redhat.com> References: <4BFE88D5.9000600@redhat.com> <4BFE8B47.50901@redhat.com> Message-ID: <4C5C421C.4000208@redhat.com> Stephen Gallagher wrote: > On 05/27/2010 10:59 AM, Rob Crittenden wrote: >> Add another default hbac service, su-l. >> >> rob >> > > Ack > pushed to master From rcritten at redhat.com Fri Aug 6 17:11:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:11:22 -0400 Subject: [Freeipa-devel] [PATCH] 451 fix i18n test In-Reply-To: <4C599F61.9000308@redhat.com> References: <4BF6FC9A.4010307@redhat.com> <4BFE81B2.80604@redhat.com> <4C599F61.9000308@redhat.com> Message-ID: <4C5C423A.1010909@redhat.com> Adam Young wrote: > On 05/27/2010 10:29 AM, Pavel Zuna wrote: >> On 05/21/2010 11:35 PM, Rob Crittenden wrote: >>> Fix this test to work from source tree root >>> >>> It would work if you ran the test from its location in tests/test_ipalib >>> but this isn't the most common method. If you want to run it >>> individually >>> you can do: >>> >>> $ ./make-test tests/test_ipalib/test_text.py >>> >>> rob >>> >> Maybe I'm doing something wrong, but I'm still getting this one error: >> >> ====================================================================== >> ERROR: Test gettext translation >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, in >> runTest >> self.test(*self.arg) >> File "/root/freeipa/tests/test_ipalib/test_text.py", line 89, in >> test_gettext >> msgid = get_msgid(test_file) >> File "/root/freeipa/tests/test_ipalib/test_text.py", line 43, in >> get_msgid >> f = open(po_file) >> IOError: [Errno 2] No such file or directory: 'install/po/test.po' >> >> >> Pavel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 17:13:31 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:13:31 -0400 Subject: [Freeipa-devel] [PATCH] 492 fix env plugin In-Reply-To: <4C59C300.401@redhat.com> References: <4C4E0582.2030800@redhat.com> <4C59C300.401@redhat.com> Message-ID: <4C5C42BB.7040807@redhat.com> Adam Young wrote: > On 07/26/2010 06:00 PM, Rob Crittenden wrote: >> The env plugin was displaying just the number of entries in the >> environment, not the values. Add an --all flag to print those, on by >> default. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 17:13:34 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:13:34 -0400 Subject: [Freeipa-devel] [PATCH] 491 Fix replacing a certificate in a service. In-Reply-To: <4C59B8CC.80606@redhat.com> References: <4C48A612.5070409@redhat.com> <4C48A6B4.9070101@redhat.com> <4C59B8CC.80606@redhat.com> Message-ID: <4C5C42BE.3070007@redhat.com> Adam Young wrote: > On 07/22/2010 04:14 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> When a service has a certificate and the CA backend doesn't support >>> revocation (like selfsign) then we simply drop the old certificate in >>> preparation for adding a new one. We weren't setting the >>> usercertificate attribute to None so there was nothing to do in >>> ldap_update(). >>> >>> Added a test case for this situation to ensure that re-issuing a >>> certificate works. >>> >> >> This patch relies on patch 490 to apply. >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 17:13:37 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 13:13:37 -0400 Subject: [Freeipa-devel] [PATCH] 484 add framework for testing other cmdlines In-Reply-To: <4C59A962.9030802@redhat.com> References: <4C3B8E53.9040804@redhat.com> <4C59A962.9030802@redhat.com> Message-ID: <4C5C42C1.8010809@redhat.com> Adam Young wrote: > On 07/12/2010 05:51 PM, Rob Crittenden wrote: >> In order to test service-disable I needed a way to get a keytab. For >> this we need to run ipa-getkeytab so I added some framework to be able >> to run the non-ipa command-line utilities. >> >> Right now I'm just testing the very basics of ipa-getkeytab but it's a >> start. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK > pushed to master From ayoung at redhat.com Fri Aug 6 18:17:03 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 14:17:03 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C5ACC80.2020505@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> <4C5AB25F.8090106@redhat.com> <4C5AC910.4060104@redhat.com> <4C5ACC80.2020505@redhat.com> Message-ID: <4C5C519F.8070005@redhat.com> On 08/05/2010 10:36 AM, Rob Crittenden wrote: > Adam Young wrote: >> 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 at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> I can't get this patch to apply: >>>>> >>>>> [ayoung at 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 at 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? >> >> > > No, that's about it. --force just says "don't bother with DNS lookup, > user claims to know what they are doing." > > I looked into this and --force isn't needed with service-add-host. > This adds hosts that are allowed to manage the service. The host needs > to exist in IPA so therefore must already exist. Therefore --force > isn't needed. > > What is lacking in the context of the patch is error reporting which > hosts failed to add. This is addressed in part by patch 499. All that > is needed is the following: > > diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > index 11fd18e..a17af89 100644 > --- a/ipalib/plugins/baseldap.py > +++ b/ipalib/plugins/baseldap.py > @@ -615,6 +615,9 @@ class LDAPAddMember(LDAPModMember): > Str('member', > label=_('Failed members'), > ), > + Str('managedby', > + label=_('Failed members'), > + ), > ) > > def execute(self, *keys, **options): > @@ -720,6 +723,9 @@ class LDAPRemoveMember(LDAPModMember): > Str('member', > label=_('Failed members'), > ), > + Str('managedby', > + label=_('Failed members'), > + ), > ) > > def execute(self, *keys, **options): > > I'll submit that as a separate patch shortly. > > rob ACK From rcritten at redhat.com Fri Aug 6 19:33:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:33:10 -0400 Subject: [Freeipa-devel] [PATCH] 496 fix RPC tests In-Reply-To: <4C5B15ED.4060909@redhat.com> References: <4C4F4423.4020008@redhat.com> <4C5B15ED.4060909@redhat.com> Message-ID: <4C5C6376.8020306@redhat.com> Adam Young wrote: > 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 19:33:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:33:11 -0400 Subject: [Freeipa-devel] [PATCH] 495 user/group name validation In-Reply-To: <4C5B15C6.9030800@redhat.com> References: <4C4F43C4.4010201@redhat.com> <4C5B15C6.9030800@redhat.com> Message-ID: <4C5C6377.6000809@redhat.com> Adam Young wrote: > 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 19:33:14 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:33:14 -0400 Subject: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services In-Reply-To: <4C5C519F.8070005@redhat.com> References: <4C488D2C.2060505@redhat.com> <4C532FE1.4040907@redhat.com> <4C59B48A.4070508@redhat.com> <4C5AB25F.8090106@redhat.com> <4C5AC910.4060104@redhat.com> <4C5ACC80.2020505@redhat.com> <4C5C519F.8070005@redhat.com> Message-ID: <4C5C637A.7060201@redhat.com> Adam Young wrote: > On 08/05/2010 10:36 AM, Rob Crittenden wrote: >> Adam Young wrote: >>> 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 at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> I can't get this patch to apply: >>>>>> >>>>>> [ayoung at 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 at 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? >>> >>> >> >> No, that's about it. --force just says "don't bother with DNS lookup, >> user claims to know what they are doing." >> >> I looked into this and --force isn't needed with service-add-host. >> This adds hosts that are allowed to manage the service. The host needs >> to exist in IPA so therefore must already exist. Therefore --force >> isn't needed. >> >> What is lacking in the context of the patch is error reporting which >> hosts failed to add. This is addressed in part by patch 499. All that >> is needed is the following: >> >> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >> index 11fd18e..a17af89 100644 >> --- a/ipalib/plugins/baseldap.py >> +++ b/ipalib/plugins/baseldap.py >> @@ -615,6 +615,9 @@ class LDAPAddMember(LDAPModMember): >> Str('member', >> label=_('Failed members'), >> ), >> + Str('managedby', >> + label=_('Failed members'), >> + ), >> ) >> >> def execute(self, *keys, **options): >> @@ -720,6 +723,9 @@ class LDAPRemoveMember(LDAPModMember): >> Str('member', >> label=_('Failed members'), >> ), >> + Str('managedby', >> + label=_('Failed members'), >> + ), >> ) >> >> def execute(self, *keys, **options): >> >> I'll submit that as a separate patch shortly. >> >> rob > ACK pushed to master From rcritten at redhat.com Fri Aug 6 19:33:18 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:33:18 -0400 Subject: [Freeipa-devel] [PATCH] 493 skip lang test if not built In-Reply-To: <4C5B1695.5040403@redhat.com> References: <4C4E05BF.2090205@redhat.com> <4C59C5DC.7030801@redhat.com> <4C5B1695.5040403@redhat.com> Message-ID: <4C5C637E.4070106@redhat.com> Adam Young wrote: > 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 at 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 at 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. > pushed to master From rcritten at redhat.com Fri Aug 6 19:34:18 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:34:18 -0400 Subject: [Freeipa-devel] [PATCH] 497 check for command existence in tests In-Reply-To: <4C5B1622.4020701@redhat.com> References: <4C51966E.1060105@redhat.com> <4C5B1622.4020701@redhat.com> Message-ID: <4C5C63BA.1060506@redhat.com> Adam Young wrote: > On 07/29/2010 10:55 AM, Rob Crittenden wrote: >> The command tests rely on the in-tree version of the command. If you >> haven't done a 'make' in the tree the command won't exist so isn't >> testable. This adds a test for command existence and raises a specific >> error. It was previously failing with some pretty unhelpful error >> messages. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Fri Aug 6 19:34:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Aug 2010 15:34:21 -0400 Subject: [Freeipa-devel] [PATCH] 498 enforce 389-ds header existence In-Reply-To: <4C53193F.9090906@redhat.com> References: <4C519DB0.8010009@redhat.com> <4C53193F.9090906@redhat.com> Message-ID: <4C5C63BD.4060900@redhat.com> Nathan Kinder wrote: > On 07/29/2010 08:26 AM, Rob Crittenden wrote: >> We were checking for 389-ds headers but not enforcing their existence. >> I've also added a check for the new repl-session-plugin.h header. > ack pushed to master From ayoung at redhat.com Fri Aug 6 20:35:20 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 16:35:20 -0400 Subject: [Freeipa-devel] [Patch] 0001-Remove-search-field-on-group-button.patch Message-ID: <4C5C7208.1060603@redhat.com> In reusing the search functionality for the group listing, we don't want the search field or button. THis patch hides it, while also performing some initialization/cleanup for the Enroll button -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Remove-search-field-on-group-button.patch URL: From ayoung at redhat.com Fri Aug 6 20:36:40 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 16:36:40 -0400 Subject: [Freeipa-devel] [Patch] IPA-HTTPD-config-uses-usr-share-static-as-target- Message-ID: <4C5C7258.8030105@redhat.com> Changes the URI for the WebUI from ipa/static to ipa/ui, which makes the existing redirects work again. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-IPA-HTTPD-config-uses-usr-share-static-as-target-for.patch URL: From ayoung at redhat.com Fri Aug 6 22:01:36 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Aug 2010 18:01:36 -0400 Subject: [Freeipa-devel] [PATCH] use time and search limit values from cn=ipaconfig In-Reply-To: <4C24B2A5.2080805@redhat.com> References: <4C24B2A5.2080805@redhat.com> Message-ID: <4C5C8640.7060301@redhat.com> On 06/25/2010 09:44 AM, Rob Crittenden wrote: > Use the cn=ipaconfig time and search limit values, and cache cn=ipaconfig > > This reads cn=ipaconfig just once and uses that same entry for all > future requests. It gets re-read only if the entry is updated by our > config plugin. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 9 16:53:07 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 12:53:07 -0400 Subject: [Freeipa-devel] [PATCH] 501 report managedby errors In-Reply-To: <4C5C41F0.4050901@redhat.com> References: <4C5C41F0.4050901@redhat.com> Message-ID: <4C603273.30409@redhat.com> On 08/06/2010 01:10 PM, Rob Crittenden wrote: > Report failures when adding/removing members to the managedby > attribute (services and hosts). > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 9 17:26:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 13:26:56 -0400 Subject: [Freeipa-devel] [Patch] IPA-HTTPD-config-uses-usr-share-static-as-target- In-Reply-To: <4C5C7258.8030105@redhat.com> References: <4C5C7258.8030105@redhat.com> Message-ID: <4C603A60.6030405@redhat.com> Adam Young wrote: > Changes the URI for the WebUI from ipa/static to ipa/ui, which makes the > existing redirects work again. ack From rcritten at redhat.com Mon Aug 9 17:27:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 13:27:45 -0400 Subject: [Freeipa-devel] [Patch] 0001-Remove-search-field-on-group-button.patch In-Reply-To: <4C5C7208.1060603@redhat.com> References: <4C5C7208.1060603@redhat.com> Message-ID: <4C603A91.3040308@redhat.com> Adam Young wrote: > In reusing the search functionality for the group listing, we don't want > the search field or button. THis patch hides it, while also performing > some initialization/cleanup for the Enroll button ack rob From ayoung at redhat.com Mon Aug 9 19:08:42 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 15:08:42 -0400 Subject: [Freeipa-devel] [Patch] 0001-Remove-search-field-on-group-button.patch In-Reply-To: <4C603A91.3040308@redhat.com> References: <4C5C7208.1060603@redhat.com> <4C603A91.3040308@redhat.com> Message-ID: <4C60523A.5010505@redhat.com> On 08/09/2010 01:27 PM, Rob Crittenden wrote: > Adam Young wrote: >> In reusing the search functionality for the group listing, we don't >> want the search field or button. THis patch hides it, while also >> performing some initialization/cleanup for the Enroll button > > ack > > rob pushed to master From ayoung at redhat.com Mon Aug 9 19:08:57 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 15:08:57 -0400 Subject: [Freeipa-devel] [Patch] IPA-HTTPD-config-uses-usr-share-static-as-target- In-Reply-To: <4C603A60.6030405@redhat.com> References: <4C5C7258.8030105@redhat.com> <4C603A60.6030405@redhat.com> Message-ID: <4C605249.8090908@redhat.com> On 08/09/2010 01:26 PM, Rob Crittenden wrote: > Adam Young wrote: >> Changes the URI for the WebUI from ipa/static to ipa/ui, which makes >> the existing redirects work again. > > ack pushed to master From pzuna at redhat.com Mon Aug 9 19:12:20 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 21:12:20 +0200 Subject: [Freeipa-devel] [PATCH] 502 hosts can fetch keytabs In-Reply-To: <4C5B787F.5020905@redhat.com> References: <4C5B787F.5020905@redhat.com> Message-ID: <4C605314.2010704@redhat.com> On 2010-08-06 04:50, Rob Crittenden wrote: > Enable a host to retrieve a keytab for all its services. > > Using the host service principal one should be able to retrieve a keytab > for other services for the host using ipa-getkeytab. This required a > number of changes: > > - allow hosts in the service's managedby to write krbPrincipalKey > - automatically add the host to managedby when a service is created > - fix ipa-getkeytab to return the entire prinicpal and not just the > first data element. It was returning "host" from the service tgt > and not host/ipa.example.com > - fix the display of the managedby attribute in the service plugin > > This led to a number of changes in the service unit tests. I took the > opportunity to switch to the Declarative scheme and tripled the number > of tests we were doing. This shed some light on a few bugs in the plugin: > > - if a service had a bad usercertificate it was impossible to delete the > service. I made it a bit more flexible. > - I added a summary for the mod and find commands > - has_keytab wasn't being set in the find output > > This is for ticket 68 > > rob > ack. Pavel From pzuna at redhat.com Mon Aug 9 20:04:15 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 22:04:15 +0200 Subject: [Freeipa-devel] [PATCH] Make LDAPObject classes JSON serializable Message-ID: <4C605F3F.5050407@redhat.com> Allow LDAPObject classes (and sub-classes) to be serialized into a JSON string using: json.dumps(obj, default=ipalib.util.json_serialize) Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0006-json.patch URL: From pzuna at redhat.com Mon Aug 9 20:05:34 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 22:05:34 +0200 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters Message-ID: <4C605F8E.5000904@redhat.com> setattr and addattr can now be used both to set all values of ANY attribute. the last setattr always resets the attribute to the specified value and all addattr append to it. Examples: user-mod testuser --setattr=title=msc title: msc user-mod testuser --setattr=title=msb title: msb user-mod testuser --addattr=title=msc title: msb, msc user-mod testuser --setattr=title= title: user-mod testuser --setattr=title=msc --addattr=msb title: msc, msb user-mod testuser --setattr=title=ing --addattr=bc title: ing, bc user-mod testuser --setattr=title=doc title: doc It's not very user friendly, but it's going to be used very very rarely in special conditions in the CLI and we can use it to save lots of JSON-RPC roundtrips in the webUI. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0007-setaddattr.patch URL: From pzuna at redhat.com Mon Aug 9 20:08:38 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 22:08:38 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug: not found exc. handler was failing for singleton objects Message-ID: <4C606046.2000601@redhat.com> Very minor bug, that would probably never happen in production anyway, but why not fix it. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0008-notfoundfix.patch URL: From pzuna at redhat.com Mon Aug 9 20:10:40 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 22:10:40 +0200 Subject: [Freeipa-devel] [PATCH] Add new parameters to LDAPSearch: timelimit and sizelimit. Message-ID: <4C6060C0.2070406@redhat.com> Doesn't include Robs loading of default values from cn=ipaConfig. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0009-searchlimits.patch URL: From pzuna at redhat.com Mon Aug 9 20:12:50 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 22:12:50 +0200 Subject: [Freeipa-devel] [Patch] Changes to the python infrastructure-supporting-the-web ui In-Reply-To: <4C5C30D3.5000907@redhat.com> References: <4C58ABD3.3080107@redhat.com> <4C5C2F91.7080005@redhat.com> <4C5C30D3.5000907@redhat.com> Message-ID: <4C606142.60109@redhat.com> On 2010-08-06 17:57, Adam Young wrote: > On 08/06/2010 11:51 AM, Rob Crittenden wrote: >> Adam Young wrote: >>> This code contains the changes to the python code necessary to >>> support the new web ui. It handles the changes to the baseldap code >>> necessary to expose the meta data to the front end, as well as the >>> installation support. >> >> nack. >> >> About 75 tests are failing with this patch. I didn't investigate them >> in detail but it looks like memberof isn't being removed after a >> member attribute is converted. >> >> wsgi.py has a ton of imports added that aren't being used. >> >> There is an indention change in ipalib/frontend.py that doesn't seem >> necessary. >> >> The timelimit patch is gonig to conflict with a timelimit patch I had >> submitted previously (patch titled 'use time and search limit values >> from cn=ipaconfig'). Not even in terms of code but in forcing a >> default that does not tie into the global config. I think I'd rather >> have this as an optional argument do no default and autofill is needed. >> >> rob > > > I'm going to fob this work off on pzuna, as these are his changes that I > just merged in. > I split the baseldap.py changes into 4 patches and posted them on the list a few minutes ago. Pavel From ayoung at redhat.com Mon Aug 9 20:37:37 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 16:37:37 -0400 Subject: [Freeipa-devel] [PATCH] Web UI Group-add Message-ID: <4C606711.9070707@redhat.com> This patch adds the ability to add a new group. is Posix and group Id fields are passed on accordingly. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-webui-group-add.patch URL: From rcritten at redhat.com Mon Aug 9 20:47:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 16:47:21 -0400 Subject: [Freeipa-devel] [PATCH] 503 fix user tests Message-ID: <4C606959.1070704@redhat.com> Fix the failing user test. It was failing because the entry has a user-private group and were weren't accounting for it in the expected data. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-503-test.patch Type: application/mbox Size: 1449 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 9 20:47:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 16:47:49 -0400 Subject: [Freeipa-devel] [PATCH] 504 decouple user-private groups Message-ID: <4C606975.5050107@redhat.com> Allow decoupling of user-private groups. To do this we need to break the link manually on both sides, the user and the group. We also have to verify in advance that the user performing this is allowed to do both. Otherwise the user could be decoupled but not the group leaving it in a quasi broken state that only ldapmodify could fix. ticket 75 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-504-detach.patch Type: application/mbox Size: 9806 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 9 20:56:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 16:56:52 -0400 Subject: [Freeipa-devel] [PATCH] Make LDAPObject classes JSON serializable In-Reply-To: <4C605F3F.5050407@redhat.com> References: <4C605F3F.5050407@redhat.com> Message-ID: <4C606B94.7050600@redhat.com> Pavel Z?na wrote: > Allow LDAPObject classes (and sub-classes) to be serialized into a JSON > string using: > > json.dumps(obj, default=ipalib.util.json_serialize) > > Pavel ack From rcritten at redhat.com Mon Aug 9 21:00:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 17:00:10 -0400 Subject: [Freeipa-devel] [PATCH] Fix bug: not found exc. handler was failing for singleton objects In-Reply-To: <4C606046.2000601@redhat.com> References: <4C606046.2000601@redhat.com> Message-ID: <4C606C5A.9000400@redhat.com> Pavel Z?na wrote: > Very minor bug, that would probably never happen in production anyway, > but why not fix it. > Can you describe the situation this could occur in? How useful would the error be if the key isn't available? rob From rcritten at redhat.com Mon Aug 9 21:01:03 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 17:01:03 -0400 Subject: [Freeipa-devel] [PATCH] Add new parameters to LDAPSearch: timelimit and sizelimit. In-Reply-To: <4C6060C0.2070406@redhat.com> References: <4C6060C0.2070406@redhat.com> Message-ID: <4C606C8F.3030202@redhat.com> Pavel Z?na wrote: > Doesn't include Robs loading of default values from cn=ipaConfig. > > Pavel > ack for now. We're going to need to remove the built-in defaults at some point and have it default to the value in cn=ipaconfig. I still need to rework the patch I made that does this. rob From rcritten at redhat.com Mon Aug 9 21:17:30 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Aug 2010 17:17:30 -0400 Subject: [Freeipa-devel] [PATCH] Web UI Group-add In-Reply-To: <4C606711.9070707@redhat.com> References: <4C606711.9070707@redhat.com> Message-ID: <4C60706A.2080409@redhat.com> Adam Young wrote: > This patch adds the ability to add a new group. > > is Posix and group Id fields are passed on accordingly. > ack From ayoung at redhat.com Mon Aug 9 21:21:46 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 17:21:46 -0400 Subject: [Freeipa-devel] [PATCH] Web UI Group-add In-Reply-To: <4C60706A.2080409@redhat.com> References: <4C606711.9070707@redhat.com> <4C60706A.2080409@redhat.com> Message-ID: <4C60716A.9000005@redhat.com> On 08/09/2010 05:17 PM, Rob Crittenden wrote: > Adam Young wrote: >> This patch adds the ability to add a new group. >> >> is Posix and group Id fields are passed on accordingly. >> > > ack pushed to master From pzuna at redhat.com Mon Aug 9 21:27:23 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 09 Aug 2010 23:27:23 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug: not found exc. handler was failing for singleton objects In-Reply-To: <4C606C5A.9000400@redhat.com> References: <4C606046.2000601@redhat.com> <4C606C5A.9000400@redhat.com> Message-ID: <4C6072BB.3040707@redhat.com> On 2010-08-09 23:00, Rob Crittenden wrote: > Pavel Z?na wrote: >> Very minor bug, that would probably never happen in production anyway, >> but why not fix it. >> > > Can you describe the situation this could occur in? How useful would the > error be if the key isn't available? > > rob Well, I caught the bug thanks to a bad config file. The basedn was set to dc=example,dc=com and all searches were failing. The key isn't available on for singleton objects such as config, example: # ipa config-show ipa: ERROR: : configuration options not found Pavel From ayoung at redhat.com Mon Aug 9 21:53:11 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 17:53:11 -0400 Subject: [Freeipa-devel] [PATCH] 503 fix user tests In-Reply-To: <4C606959.1070704@redhat.com> References: <4C606959.1070704@redhat.com> Message-ID: <4C6078C7.3070608@redhat.com> On 08/09/2010 04:47 PM, Rob Crittenden wrote: > Fix the failing user test. It was failing because the entry has a > user-private group and were weren't accounting for it in the expected > data. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 9 21:59:39 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 17:59:39 -0400 Subject: [Freeipa-devel] [PATCH] 504 decouple user-private groups In-Reply-To: <4C606975.5050107@redhat.com> References: <4C606975.5050107@redhat.com> Message-ID: <4C607A4B.90904@redhat.com> On 08/09/2010 04:47 PM, Rob Crittenden wrote: > Allow decoupling of user-private groups. > > To do this we need to break the link manually on both sides, the user > and the group. > > We also have to verify in advance that the user performing this is > allowed to do both. Otherwise the user could be decoupled but not the > group leaving it in a quasi broken state that only ldapmodify could fix. > > ticket 75 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 9 22:03:02 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 09 Aug 2010 18:03:02 -0400 Subject: [Freeipa-devel] [PATCH] Add new parameters to LDAPSearch: timelimit and sizelimit. In-Reply-To: <4C606C8F.3030202@redhat.com> References: <4C6060C0.2070406@redhat.com> <4C606C8F.3030202@redhat.com> Message-ID: <4C607B16.6020104@redhat.com> On 08/09/2010 05:01 PM, Rob Crittenden wrote: > Pavel Z?na wrote: >> Doesn't include Robs loading of default values from cn=ipaConfig. >> >> Pavel >> > > ack for now. > > We're going to need to remove the built-in defaults at some point and > have it default to the value in cn=ipaconfig. I still need to rework > the patch I made that does this. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Lets get this in, and then get robs patch in, and then modify this code to use the defaults from Robs. The caching issue can wait.If someone really cares about that, they can always "service httpd restart" to force flush the cache. From rcritten at redhat.com Tue Aug 10 14:03:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 10:03:56 -0400 Subject: [Freeipa-devel] [PATCH] 505 make logging more configurable Message-ID: <4C615C4C.6060901@redhat.com> Make the server log level more configurable, not defaulting to debug. This disables debug output in the Apache log by default. If you want increased output create /etc/ipa/server.conf and set it to: [global] debug=True If this is too much output you can select verbose output instead: [global] debug=False verbose=True ticket 60 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-505-debug.patch Type: application/mbox Size: 1433 bytes Desc: not available URL: From jdennis at redhat.com Tue Aug 10 14:32:47 2010 From: jdennis at redhat.com (John Dennis) Date: Tue, 10 Aug 2010 10:32:47 -0400 Subject: [Freeipa-devel] [PATCH] 505 make logging more configurable In-Reply-To: <4C615C4C.6060901@redhat.com> References: <4C615C4C.6060901@redhat.com> Message-ID: <4C61630F.2070707@redhat.com> On 08/10/2010 10:03 AM, Rob Crittenden wrote: > Make the server log level more configurable, not defaulting to debug. > > This disables debug output in the Apache log by default. If you want > increased output create /etc/ipa/server.conf and set it to: > > [global] > debug=True > > If this is too much output you can select verbose output instead: > > [global] > debug=False > verbose=True > > ticket 60 This is good information for others to easily find. Can these types of "tips" be put on the FreeIPA Wiki somewhere so it's documented and easy to find? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Aug 10 14:43:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 10:43:33 -0400 Subject: [Freeipa-devel] [PATCH] 505 make logging more configurable In-Reply-To: <4C61630F.2070707@redhat.com> References: <4C615C4C.6060901@redhat.com> <4C61630F.2070707@redhat.com> Message-ID: <4C616595.1050801@redhat.com> John Dennis wrote: > On 08/10/2010 10:03 AM, Rob Crittenden wrote: >> Make the server log level more configurable, not defaulting to debug. >> >> This disables debug output in the Apache log by default. If you want >> increased output create /etc/ipa/server.conf and set it to: >> >> [global] >> debug=True >> >> If this is too much output you can select verbose output instead: >> >> [global] >> debug=False >> verbose=True >> >> ticket 60 > > This is good information for others to easily find. Can these types of > "tips" be put on the FreeIPA Wiki somewhere so it's documented and easy > to find? > Yes, added as part of the ticket: http://freeipa.org/page/IPAv2_config_files rob From rcritten at redhat.com Tue Aug 10 17:20:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 13:20:42 -0400 Subject: [Freeipa-devel] [PATCH] 506 correct ipa-server-install man page Message-ID: <4C618A6A.1070408@redhat.com> The ipa-server-install man page still referred to the deprecated --ca option to configure a dogtag instance. Drop that and include information on the --selfsign option. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-506-man.patch Type: application/mbox Size: 1758 bytes Desc: not available URL: From rcritten at redhat.com Tue Aug 10 17:24:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 13:24:59 -0400 Subject: [Freeipa-devel] [PATCH] 507 add support for ldap:///self bind rules in the aci plugin Message-ID: <4C618B6B.9050801@redhat.com> Add support for ldap:///self bind rules This is added mainly so the self service rules can be updated without resorting to ldapmodify. ticket 80 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-507-aci.patch Type: application/mbox Size: 6549 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:28:14 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:28:14 +0200 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. Message-ID: <4C618C2E.3090400@redhat.com> - Make it recursive. - Make Param classes serializable. - Take python native data types into account. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0010-json.patch Type: application/mbox Size: 2944 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:29:29 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:29:29 +0200 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. Message-ID: <4C618C79.2060202@redhat.com> This is required for the webUI, since we're dropping Genshi. *ehm* :) You can't use this command on the CLI. It takes one optional argument: the name of an IPA object. If not specified, meta-data for all objects are returned. Note: If you want to try it out on the CLI, just comment out the INTERNAL = True line. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0011-export.patch Type: application/mbox Size: 2776 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:30:10 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:30:10 +0200 Subject: [Freeipa-devel] [PATCH] Clean ipa.js and make it load plugin meta-data over JSON-RPC. Message-ID: <4C618CA2.8040808@redhat.com> What it means? Well, first I removed some development control variables from ipa.js. Namely useSampleData and sizelimit. I moved useSampleData to the top of index.xhtml. This way we won't forget about it when we don't need it anymore. sizelimit has nothing to do in ipa.js and be hardcoded for ALL commands! Some don't have this parameter and could fail. Since ipa_init now loads meta-data over JSON-RPC, we need to wait for it to finish its job. That's why I put a second parameter to ipa_init: on_win. ipa_init will call on_win when all data is loaded properly and we can start building the page. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0012-cleanipajs.patch Type: application/mbox Size: 4756 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:30:47 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:30:47 +0200 Subject: [Freeipa-devel] [PATCH] Clean details.js. Message-ID: <4C618CC7.6030909@redhat.com> What does it mean? I removed duplicate code, that was pasted here from the user details page. ipa_details_init doesn't call ipa_init anymore. ipa_details_create takes a second optional parameter, that can be set to a container element if we want to place the definition lists into a specific element instead of . In our case, we place stuff in
Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0013-cleandetailsjs.patch Type: application/mbox Size: 5880 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:31:33 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:31:33 +0200 Subject: [Freeipa-devel] [PATCH] Make user details work again in the webUI. Message-ID: <4C618CF5.8080104@redhat.com> Unfortunately we can't have any javascript in *.inc files, because the browser will strip them for security reasons. I moved all the attribute callbacks etc. to the only logical place: user.js. It's fine for now, but user.js is going to need some serious cleaning up in the future. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0014-userdetails.patch Type: application/mbox Size: 18141 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:33:22 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:33:22 +0200 Subject: [Freeipa-devel] [PATCH] Stretch content div and make Reset/Update buttons stick to right. Message-ID: <4C618D62.5010708@redhat.com> I know that the user details page still doesn't look exactly like the mockups, but it's getting there and it's mostly just a matter of moving elements around - easy. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0015-detailscss.patch Type: application/mbox Size: 776 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 10 17:34:34 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 10 Aug 2010 19:34:34 +0200 Subject: [Freeipa-devel] [PATCH] 506 correct ipa-server-install man page In-Reply-To: <4C618A6A.1070408@redhat.com> References: <4C618A6A.1070408@redhat.com> Message-ID: <4C618DAA.5080504@redhat.com> On 08/10/2010 07:20 PM, Rob Crittenden wrote: > The ipa-server-install man page still referred to the deprecated --ca > option to configure a dogtag instance. Drop that and include information > on the --selfsign option. > > rob > ack. Pavel From rcritten at redhat.com Tue Aug 10 19:05:25 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 15:05:25 -0400 Subject: [Freeipa-devel] [PATCH] 508 fix reference to _handle_errors Message-ID: <4C61A2F5.2010702@redhat.com> In remove_principal_key() we were calling self._handle_errors() rather than _handle_errors(). I've pushed this under the one-liner rule. rob >From 6befd08973183f0aa9b681a1d7fd0b9a3a89fe08 Mon Sep 17 00:00:00 2001 From: Rob Crittenden Date: Tue, 10 Aug 2010 15:03:11 -0400 Subject: [PATCH] Fix reference to _handle_errors() in remove_principal_key() It incorrectly was trying to call the class method _handle_errors() instead of the global function. --- ipaserver/plugins/ldap2.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py index 3c536e2..81c2aeb 100644 --- a/ipaserver/plugins/ldap2.py +++ b/ipaserver/plugins/ldap2.py @@ -839,7 +839,7 @@ class ldap2(CrudBackend, Encoder): try: self.conn.modify_s(dn, mod) except _ldap.LDAPError, e: - self._handle_errors(e, **{}) + _handle_errors(e, **{}) # CrudBackend methods -- 1.6.2.5 From rcritten at redhat.com Tue Aug 10 19:35:57 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 15:35:57 -0400 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C618C2E.3090400@redhat.com> References: <4C618C2E.3090400@redhat.com> Message-ID: <4C61AA1D.1060905@redhat.com> Pavel Zuna wrote: > - Make it recursive. > - Make Param classes serializable. > - Take python native data types into account. > > Pavel The code looks ok but export.py doesn't seem like it matches the functions the plugin provides (and is rather generic in nature). Can we rename this json.py or something? rob From rcritten at redhat.com Tue Aug 10 19:45:31 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 15:45:31 -0400 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C618C2E.3090400@redhat.com> References: <4C618C2E.3090400@redhat.com> Message-ID: <4C61AC5B.5020007@redhat.com> Pavel Zuna wrote: > - Make it recursive. > - Make Param classes serializable. > - Take python native data types into account. > > Pavel Oops, sorry, commented on wrong patch. This looks ok but you have a serious whitespace issue in the def __json__ method. ack if you fix that before pushing. rob From rcritten at redhat.com Tue Aug 10 19:47:00 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 15:47:00 -0400 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. In-Reply-To: <4C618C79.2060202@redhat.com> References: <4C618C79.2060202@redhat.com> Message-ID: <4C61ACB4.3020304@redhat.com> Pavel Zuna wrote: > This is required for the webUI, since we're dropping Genshi. *ehm* :) > > You can't use this command on the CLI. It takes one optional argument: > the name of an IPA object. If not specified, meta-data for all objects > are returned. > > Note: If you want to try it out on the CLI, just comment out the > INTERNAL = True line. > > Pavel The code looks ok but export.py doesn't seem like it matches the functions the plugin provides (and is rather generic in nature). Can we rename this json.py or something? rob From rcritten at redhat.com Tue Aug 10 19:50:55 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 15:50:55 -0400 Subject: [Freeipa-devel] [PATCH] Clean ipa.js and make it load plugin meta-data over JSON-RPC. In-Reply-To: <4C618CA2.8040808@redhat.com> References: <4C618CA2.8040808@redhat.com> Message-ID: <4C61AD9F.2070908@redhat.com> Pavel Zuna wrote: > What it means? > Well, first I removed some development control variables from ipa.js. > Namely useSampleData and sizelimit. I moved useSampleData to the top > of index.xhtml. This way we won't forget about it when we don't need > it anymore. sizelimit has nothing to do in ipa.js and be hardcoded > for ALL commands! Some don't have this parameter and could fail. > > Since ipa_init now loads meta-data over JSON-RPC, we need to wait for > it to finish its job. That's why I put a second parameter to ipa_init: > on_win. ipa_init will call on_win when all data is loaded properly and > we can start building the page. > > Pavel The thing about the limit is things are going to change on the backend so that the default isn't in the param but pulled from LDAP at some point. Not sure that makes a difference here. I guess this relies on your patch #11? Otherwise this looks ok, ack. rob From rcritten at redhat.com Tue Aug 10 20:13:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 16:13:56 -0400 Subject: [Freeipa-devel] [PATCH] Stretch content div and make Reset/Update buttons stick to right. In-Reply-To: <4C618D62.5010708@redhat.com> References: <4C618D62.5010708@redhat.com> Message-ID: <4C61B304.7060405@redhat.com> Pavel Zuna wrote: > I know that the user details page still doesn't look exactly like the > mockups, but it's getting there and it's mostly just a matter of moving > elements around - easy. > > Pavel ack From ayoung at redhat.com Tue Aug 10 20:25:50 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 10 Aug 2010 16:25:50 -0400 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. In-Reply-To: <4C61ACB4.3020304@redhat.com> References: <4C618C79.2060202@redhat.com> <4C61ACB4.3020304@redhat.com> Message-ID: <4C61B5CE.6000709@redhat.com> On 08/10/2010 03:47 PM, Rob Crittenden wrote: > Pavel Zuna wrote: >> This is required for the webUI, since we're dropping Genshi. *ehm* :) >> >> You can't use this command on the CLI. It takes one optional argument: >> the name of an IPA object. If not specified, meta-data for all objects >> are returned. >> >> Note: If you want to try it out on the CLI, just comment out the >> INTERNAL = True line. >> >> Pavel > > The code looks ok but export.py doesn't seem like it matches the > functions the plugin provides (and is rather generic in nature). Can > we rename this json.py or something? > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Shouldn't be JSON, should it, as it exports the plugin meta data in both json and in xml format based on how it is called. Can we call it metadata.py? From ayoung at redhat.com Tue Aug 10 20:30:47 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 10 Aug 2010 16:30:47 -0400 Subject: [Freeipa-devel] [PATCH] Clean ipa.js and make it load plugin meta-data over JSON-RPC. In-Reply-To: <4C61AD9F.2070908@redhat.com> References: <4C618CA2.8040808@redhat.com> <4C61AD9F.2070908@redhat.com> Message-ID: <4C61B6F7.5000307@redhat.com> On 08/10/2010 03:50 PM, Rob Crittenden wrote: > Pavel Zuna wrote: >> What it means? >> Well, first I removed some development control variables from ipa.js. >> Namely useSampleData and sizelimit. I moved useSampleData to the top >> of index.xhtml. This way we won't forget about it when we don't need >> it anymore. sizelimit has nothing to do in ipa.js and be hardcoded >> for ALL commands! Some don't have this parameter and could fail. >> >> Since ipa_init now loads meta-data over JSON-RPC, we need to wait for >> it to finish its job. That's why I put a second parameter to ipa_init: >> on_win. ipa_init will call on_win when all data is loaded properly and >> we can start building the page. >> >> Pavel > > The thing about the limit is things are going to change on the backend > so that the default isn't in the param but pulled from LDAP at some > point. Not sure that makes a difference here. > > I guess this relies on your patch #11? > > Otherwise this looks ok, ack. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel So the concept is that for a given collection, we load the meta-data in ipa-init, and then that is going to call load-object? From rcritten at redhat.com Tue Aug 10 20:41:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 16:41:11 -0400 Subject: [Freeipa-devel] [PATCH] 509 add BuildRequries for authconfig Message-ID: <4C61B967.9070102@redhat.com> In ipapython/dnsclient.py we import acutil which is provided by authconfig. This can get invoked by setup.py so we need to have it at build time. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-509-spec.patch Type: application/mbox Size: 893 bytes Desc: not available URL: From ayoung at redhat.com Tue Aug 10 20:42:02 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 10 Aug 2010 16:42:02 -0400 Subject: [Freeipa-devel] [PATCH] Make user details work again in the webUI. In-Reply-To: <4C618CF5.8080104@redhat.com> References: <4C618CF5.8080104@redhat.com> Message-ID: <4C61B99A.6020008@redhat.com> On 08/10/2010 01:31 PM, Pavel Zuna wrote: > Unfortunately we can't have any javascript in *.inc files, because > the browser will strip them for security reasons. I moved all the > attribute callbacks etc. to the only logical place: user.js. > > It's fine for now, but user.js is going to need some serious cleaning > up in the future. > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Agreed that user needs a clean up. The goal is to pull all of the non-user specific stuff into details.js. We might want to think about common things like the states dropdown, etc become custom components, too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 10 20:41:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 16:41:58 -0400 Subject: [Freeipa-devel] [PATCH] 503 fix user tests In-Reply-To: <4C6078C7.3070608@redhat.com> References: <4C606959.1070704@redhat.com> <4C6078C7.3070608@redhat.com> Message-ID: <4C61B996.5070601@redhat.com> Adam Young wrote: > On 08/09/2010 04:47 PM, Rob Crittenden wrote: >> Fix the failing user test. It was failing because the entry has a >> user-private group and were weren't accounting for it in the expected >> data. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Tue Aug 10 20:42:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 16:42:08 -0400 Subject: [Freeipa-devel] [PATCH] 504 decouple user-private groups In-Reply-To: <4C607A4B.90904@redhat.com> References: <4C606975.5050107@redhat.com> <4C607A4B.90904@redhat.com> Message-ID: <4C61B9A0.7070302@redhat.com> Adam Young wrote: > On 08/09/2010 04:47 PM, Rob Crittenden wrote: >> Allow decoupling of user-private groups. >> >> To do this we need to break the link manually on both sides, the user >> and the group. >> >> We also have to verify in advance that the user performing this is >> allowed to do both. Otherwise the user could be decoupled but not the >> group leaving it in a quasi broken state that only ldapmodify could fix. >> >> ticket 75 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK > pushed to master rob From rcritten at redhat.com Tue Aug 10 20:42:34 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Aug 2010 16:42:34 -0400 Subject: [Freeipa-devel] [PATCH] 506 correct ipa-server-install man page In-Reply-To: <4C618DAA.5080504@redhat.com> References: <4C618A6A.1070408@redhat.com> <4C618DAA.5080504@redhat.com> Message-ID: <4C61B9BA.8030502@redhat.com> Pavel Zuna wrote: > On 08/10/2010 07:20 PM, Rob Crittenden wrote: >> The ipa-server-install man page still referred to the deprecated --ca >> option to configure a dogtag instance. Drop that and include information >> on the --selfsign option. >> >> rob >> > > ack. > > Pavel pushed to master From pzuna at redhat.com Wed Aug 11 18:05:34 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Wed, 11 Aug 2010 20:05:34 +0200 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C61AC5B.5020007@redhat.com> References: <4C618C2E.3090400@redhat.com> <4C61AC5B.5020007@redhat.com> Message-ID: <4C62E66E.6060700@redhat.com> On 2010-08-10 21:45, Rob Crittenden wrote: > Pavel Zuna wrote: >> - Make it recursive. >> - Make Param classes serializable. >> - Take python native data types into account. >> >> Pavel > > Oops, sorry, commented on wrong patch. > > This looks ok but you have a serious whitespace issue in the def > __json__ method. > > ack if you fix that before pushing. > > rob Version with fixed whitespace attached. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0010-json.patch URL: From pzuna at redhat.com Wed Aug 11 18:07:35 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Wed, 11 Aug 2010 20:07:35 +0200 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. In-Reply-To: <4C61ACB4.3020304@redhat.com> References: <4C618C79.2060202@redhat.com> <4C61ACB4.3020304@redhat.com> Message-ID: <4C62E6E7.6020508@redhat.com> On 2010-08-10 21:47, Rob Crittenden wrote: > Pavel Zuna wrote: >> This is required for the webUI, since we're dropping Genshi. *ehm* :) >> >> You can't use this command on the CLI. It takes one optional argument: >> the name of an IPA object. If not specified, meta-data for all objects >> are returned. >> >> Note: If you want to try it out on the CLI, just comment out the >> INTERNAL = True line. >> >> Pavel > > The code looks ok but export.py doesn't seem like it matches the > functions the plugin provides (and is rather generic in nature). Can we > rename this json.py or something? > > rob I thought that we might use the file for other plugins that export data, but there probably won't be any for a while. Renamed it to internal.py as I'm sure we'll see more internal commands as we progress with the webUI. Patch attached. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pzuna-freeipa-0011-internal.patch URL: From pzuna at redhat.com Wed Aug 11 18:45:36 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Wed, 11 Aug 2010 20:45:36 +0200 Subject: [Freeipa-devel] [PATCH] 509 add BuildRequries for authconfig In-Reply-To: <4C61B967.9070102@redhat.com> References: <4C61B967.9070102@redhat.com> Message-ID: <4C62EFD0.7060701@redhat.com> On 2010-08-10 22:41, Rob Crittenden wrote: > In ipapython/dnsclient.py we import acutil which is provided by > authconfig. This can get invoked by setup.py so we need to have it at > build time. > > rob > ack. Pavel From rcritten at redhat.com Wed Aug 11 20:07:06 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 16:07:06 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 510 enable compat plugin by default Message-ID: <4C6302EA.4040704@redhat.com> originall sent to wrong list -------------- next part -------------- An embedded message was scrubbed... From: Rob Crittenden Subject: [Freeipa-users] [PATCH] 510 enable compat plugin by default Date: Wed, 11 Aug 2010 15:28:30 -0400 Size: 15223 URL: From rcritten at redhat.com Wed Aug 11 20:55:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 16:55:50 -0400 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C62E66E.6060700@redhat.com> References: <4C618C2E.3090400@redhat.com> <4C61AC5B.5020007@redhat.com> <4C62E66E.6060700@redhat.com> Message-ID: <4C630E56.70108@redhat.com> Pavel Z?na wrote: > On 2010-08-10 21:45, Rob Crittenden wrote: >> Pavel Zuna wrote: >>> - Make it recursive. >>> - Make Param classes serializable. >>> - Take python native data types into account. >>> >>> Pavel >> >> Oops, sorry, commented on wrong patch. >> >> This looks ok but you have a serious whitespace issue in the def >> __json__ method. >> >> ack if you fix that before pushing. >> >> rob > > Version with fixed whitespace attached. > > Pavel This isn't applying. I'm assuming there is some other patch I haven't pushed but I wasn't able to find it. rob From rcritten at redhat.com Thu Aug 12 02:46:03 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 22:46:03 -0400 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C605F8E.5000904@redhat.com> References: <4C605F8E.5000904@redhat.com> Message-ID: <4C63606B.8030402@redhat.com> Pavel Z?na wrote: > setattr and addattr can now be used both to set all values of > ANY attribute. the last setattr always resets the attribute to > the specified value and all addattr append to it. > > Examples: > user-mod testuser --setattr=title=msc > title: msc > user-mod testuser --setattr=title=msb > title: msb > user-mod testuser --addattr=title=msc > title: msb, msc > user-mod testuser --setattr=title= > title: > user-mod testuser --setattr=title=msc --addattr=msb > title: msc, msb > user-mod testuser --setattr=title=ing --addattr=bc > title: ing, bc > user-mod testuser --setattr=title=doc > title: doc > > It's not very user friendly, but it's going to be used very very > rarely in special conditions in the CLI and we can use it to save > lots of JSON-RPC roundtrips in the webUI. > > Pavel It was my intention when I added addattr and setattr that one couldn't set already-defined params this way. They were silently ignored. So you couldn't do: user-mod testuser --setattr=givenname=Jeff This would be possible with this patch. Was that intentional? BTW I have the start of a test suite for this functionality. rob From ayoung at redhat.com Thu Aug 12 03:50:37 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 11 Aug 2010 23:50:37 -0400 Subject: [Freeipa-devel] Changing the param scheme Message-ID: <4C636F8D.9000909@redhat.com> Pavel, I made a small change to the ipa.js:ipa_parse_qp that you should note: - qs = location.search.substring(1, location.search.length); + qs = location.hash.substring(1); Instead of searching for the ? it serach for the #. THis works much more cleanly with Javascript by allowing us to modify the URL without doing a roundtrip to the server. If we were to change either window.location or window.location.search, it bascially resubmits the http request. I've gone through and changed everywhere that was doing ? based params. One benefit from this is that we now can have bookmarkable searches. I made a new optional parameter for the search pages (criteria) if that is set when the page is loaded, it will execute a search with that criteria. I have to clean up the patch a little, and it is dependant on your changes going in, but it works. After this, I'll address the group details page, or you can. From pzuna at redhat.com Thu Aug 12 08:37:40 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 12 Aug 2010 10:37:40 +0200 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C63606B.8030402@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> Message-ID: <4C63B2D4.9080909@redhat.com> On 2010-08-12 04:46, Rob Crittenden wrote: > Pavel Z?na wrote: >> setattr and addattr can now be used both to set all values of >> ANY attribute. the last setattr always resets the attribute to >> the specified value and all addattr append to it. >> >> Examples: >> user-mod testuser --setattr=title=msc >> title: msc >> user-mod testuser --setattr=title=msb >> title: msb >> user-mod testuser --addattr=title=msc >> title: msb, msc >> user-mod testuser --setattr=title= >> title: >> user-mod testuser --setattr=title=msc --addattr=msb >> title: msc, msb >> user-mod testuser --setattr=title=ing --addattr=bc >> title: ing, bc >> user-mod testuser --setattr=title=doc >> title: doc >> >> It's not very user friendly, but it's going to be used very very >> rarely in special conditions in the CLI and we can use it to save >> lots of JSON-RPC roundtrips in the webUI. >> >> Pavel > > It was my intention when I added addattr and setattr that one couldn't > set already-defined params this way. They were silently ignored. So you > couldn't do: > > user-mod testuser --setattr=givenname=Jeff > > This would be possible with this patch. Was that intentional? > > BTW I have the start of a test suite for this functionality. > > rob Yes, it is intentional. I forgot to mention it in the description. I'm using setattr/addattr for everything in the webUI - it makes the code a lot simpler. Pavel From pzuna at redhat.com Thu Aug 12 08:40:47 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 12 Aug 2010 10:40:47 +0200 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C630E56.70108@redhat.com> References: <4C618C2E.3090400@redhat.com> <4C61AC5B.5020007@redhat.com> <4C62E66E.6060700@redhat.com> <4C630E56.70108@redhat.com> Message-ID: <4C63B38F.5050709@redhat.com> On 2010-08-11 22:55, Rob Crittenden wrote: > Pavel Z?na wrote: >> On 2010-08-10 21:45, Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> - Make it recursive. >>>> - Make Param classes serializable. >>>> - Take python native data types into account. >>>> >>>> Pavel >>> >>> Oops, sorry, commented on wrong patch. >>> >>> This looks ok but you have a serious whitespace issue in the def >>> __json__ method. >>> >>> ack if you fix that before pushing. >>> >>> rob >> >> Version with fixed whitespace attached. >> >> Pavel > > This isn't applying. I'm assuming there is some other patch I haven't > pushed but I wasn't able to find it. > > rob It depends on: [PATCH] Make LDAPObject classes JSON serializable (posted 2010-08-09) (pzuna-freeipa-0006-json.patch) Pavel From rcritten at redhat.com Thu Aug 12 12:38:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 08:38:42 -0400 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C63B2D4.9080909@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> Message-ID: <4C63EB52.8050600@redhat.com> Pavel Z?na wrote: > On 2010-08-12 04:46, Rob Crittenden wrote: >> Pavel Z?na wrote: >>> setattr and addattr can now be used both to set all values of >>> ANY attribute. the last setattr always resets the attribute to >>> the specified value and all addattr append to it. >>> >>> Examples: >>> user-mod testuser --setattr=title=msc >>> title: msc >>> user-mod testuser --setattr=title=msb >>> title: msb >>> user-mod testuser --addattr=title=msc >>> title: msb, msc >>> user-mod testuser --setattr=title= >>> title: >>> user-mod testuser --setattr=title=msc --addattr=msb >>> title: msc, msb >>> user-mod testuser --setattr=title=ing --addattr=bc >>> title: ing, bc >>> user-mod testuser --setattr=title=doc >>> title: doc >>> >>> It's not very user friendly, but it's going to be used very very >>> rarely in special conditions in the CLI and we can use it to save >>> lots of JSON-RPC roundtrips in the webUI. >>> >>> Pavel >> >> It was my intention when I added addattr and setattr that one couldn't >> set already-defined params this way. They were silently ignored. So you >> couldn't do: >> >> user-mod testuser --setattr=givenname=Jeff >> >> This would be possible with this patch. Was that intentional? >> >> BTW I have the start of a test suite for this functionality. >> >> rob > > Yes, it is intentional. I forgot to mention it in the description. I'm > using setattr/addattr for everything in the webUI - it makes the code a > lot simpler. Doesn't that invalidate all the validators we have in the plugins? This is why I disallowed it. rob From rcritten at redhat.com Thu Aug 12 13:05:44 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 09:05:44 -0400 Subject: [Freeipa-devel] [PATCH] Stretch content div and make Reset/Update buttons stick to right. In-Reply-To: <4C61B304.7060405@redhat.com> References: <4C618D62.5010708@redhat.com> <4C61B304.7060405@redhat.com> Message-ID: <4C63F1A8.3000005@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> I know that the user details page still doesn't look exactly like the >> mockups, but it's getting there and it's mostly just a matter of >> moving elements around - easy. >> >> Pavel > > ack pushed to master From rcritten at redhat.com Thu Aug 12 13:05:46 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 09:05:46 -0400 Subject: [Freeipa-devel] [PATCH] Add new parameters to LDAPSearch: timelimit and sizelimit. In-Reply-To: <4C606C8F.3030202@redhat.com> References: <4C6060C0.2070406@redhat.com> <4C606C8F.3030202@redhat.com> Message-ID: <4C63F1AA.1050702@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Doesn't include Robs loading of default values from cn=ipaConfig. >> >> Pavel >> > > ack for now. > > We're going to need to remove the built-in defaults at some point and > have it default to the value in cn=ipaconfig. I still need to rework the > patch I made that does this. > > rob pushed to master From rcritten at redhat.com Thu Aug 12 13:05:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 09:05:49 -0400 Subject: [Freeipa-devel] [PATCH] Fix bug: not found exc. handler was failing for singleton objects In-Reply-To: <4C6072BB.3040707@redhat.com> References: <4C606046.2000601@redhat.com> <4C606C5A.9000400@redhat.com> <4C6072BB.3040707@redhat.com> Message-ID: <4C63F1AD.2010401@redhat.com> Pavel Z?na wrote: > On 2010-08-09 23:00, Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Very minor bug, that would probably never happen in production anyway, >>> but why not fix it. >>> >> >> Can you describe the situation this could occur in? How useful would the >> error be if the key isn't available? >> >> rob > > Well, I caught the bug thanks to a bad config file. The basedn was set > to dc=example,dc=com and all searches were failing. The key isn't > available on for singleton objects such as config, example: > > # ipa config-show > ipa: ERROR: : configuration options not found > > Pavel ok, ack, pushed to master From rcritten at redhat.com Thu Aug 12 13:05:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 09:05:52 -0400 Subject: [Freeipa-devel] [PATCH] Make LDAPObject classes JSON serializable In-Reply-To: <4C606B94.7050600@redhat.com> References: <4C605F3F.5050407@redhat.com> <4C606B94.7050600@redhat.com> Message-ID: <4C63F1B0.20502@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Allow LDAPObject classes (and sub-classes) to be serialized into a >> JSON string using: >> >> json.dumps(obj, default=ipalib.util.json_serialize) >> >> Pavel > > ack pushed to master From rcritten at redhat.com Thu Aug 12 13:06:53 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Aug 2010 09:06:53 -0400 Subject: [Freeipa-devel] [PATCH] Improve serialization to JSON. In-Reply-To: <4C63B38F.5050709@redhat.com> References: <4C618C2E.3090400@redhat.com> <4C61AC5B.5020007@redhat.com> <4C62E66E.6060700@redhat.com> <4C630E56.70108@redhat.com> <4C63B38F.5050709@redhat.com> Message-ID: <4C63F1ED.1030206@redhat.com> Pavel Z?na wrote: > On 2010-08-11 22:55, Rob Crittenden wrote: >> Pavel Z?na wrote: >>> On 2010-08-10 21:45, Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> - Make it recursive. >>>>> - Make Param classes serializable. >>>>> - Take python native data types into account. >>>>> >>>>> Pavel >>>> >>>> Oops, sorry, commented on wrong patch. >>>> >>>> This looks ok but you have a serious whitespace issue in the def >>>> __json__ method. >>>> >>>> ack if you fix that before pushing. >>>> >>>> rob >>> >>> Version with fixed whitespace attached. >>> >>> Pavel >> >> This isn't applying. I'm assuming there is some other patch I haven't >> pushed but I wasn't able to find it. >> >> rob > > It depends on: > [PATCH] Make LDAPObject classes JSON serializable (posted 2010-08-09) > > (pzuna-freeipa-0006-json.patch) > > Pavel ok, ack, pushed to master From pzuna at redhat.com Thu Aug 12 13:35:45 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 12 Aug 2010 15:35:45 +0200 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C63EB52.8050600@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> Message-ID: <4C63F8B1.5030700@redhat.com> On 2010-08-12 14:38, Rob Crittenden wrote: > Pavel Z?na wrote: >> On 2010-08-12 04:46, Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> setattr and addattr can now be used both to set all values of >>>> ANY attribute. the last setattr always resets the attribute to >>>> the specified value and all addattr append to it. >>>> >>>> Examples: >>>> user-mod testuser --setattr=title=msc >>>> title: msc >>>> user-mod testuser --setattr=title=msb >>>> title: msb >>>> user-mod testuser --addattr=title=msc >>>> title: msb, msc >>>> user-mod testuser --setattr=title= >>>> title: >>>> user-mod testuser --setattr=title=msc --addattr=msb >>>> title: msc, msb >>>> user-mod testuser --setattr=title=ing --addattr=bc >>>> title: ing, bc >>>> user-mod testuser --setattr=title=doc >>>> title: doc >>>> >>>> It's not very user friendly, but it's going to be used very very >>>> rarely in special conditions in the CLI and we can use it to save >>>> lots of JSON-RPC roundtrips in the webUI. >>>> >>>> Pavel >>> >>> It was my intention when I added addattr and setattr that one couldn't >>> set already-defined params this way. They were silently ignored. So you >>> couldn't do: >>> >>> user-mod testuser --setattr=givenname=Jeff >>> >>> This would be possible with this patch. Was that intentional? >>> >>> BTW I have the start of a test suite for this functionality. >>> >>> rob >> >> Yes, it is intentional. I forgot to mention it in the description. I'm >> using setattr/addattr for everything in the webUI - it makes the code a >> lot simpler. > > Doesn't that invalidate all the validators we have in the plugins? This > is why I disallowed it. > > rob It does, but I see these options as something only experienced users, who need to set something we don't support directly, will use. Sometimes they might want to disable the validators, if they know what they're doing. We could also make the setattr/addattr handler in frontend.py detect if a there's a validator available and use it. Validators in the webUI is still something we need to figure out. Adam was proposing having validators in the form of regex strings, which is not a bad idea as it's easy to implement on any platform/language. On the other hand, I don't know if it's good enough for all parameters we have. Hmm. There's a lot to think about here actually. I'll make it my homework for the weekend. :) Pavel From ayoung at redhat.com Thu Aug 12 15:24:53 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 12 Aug 2010 11:24:53 -0400 Subject: [Freeipa-devel] [PATCH] 494 ipa command failover In-Reply-To: <4C4E05FF.8040400@redhat.com> References: <4C4E05FF.8040400@redhat.com> Message-ID: <4C641245.3050702@redhat.com> On 07/26/2010 06:02 PM, Rob Crittenden wrote: > Add failover to the ipa command. If the server defined in > /etc/ipa/default.conf is not available then each ldap SRV record in > DNS is tried until either one is found that works or none of the > available servers are responding. > > ticket #15 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Aug 12 18:36:31 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 12 Aug 2010 14:36:31 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0001-hash-params Message-ID: <4C643F2F.9060003@redhat.com> I'll try to use a patch naming structure similar to what Pavel's using: This patch fixes https://fedorahosted.org/freeipa/ticket/135. Instead of HTML Params starting with '?' we use the Hash '#' as the startgin point. This keeps the broswer from sending addition http requests to the server whenever we need to update the URL. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0001-hash-params.patch Type: text/x-patch Size: 18783 bytes Desc: not available URL: From ayoung at redhat.com Fri Aug 13 19:17:11 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Aug 2010 15:17:11 -0400 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. In-Reply-To: <4C62E6E7.6020508@redhat.com> References: <4C618C79.2060202@redhat.com> <4C61ACB4.3020304@redhat.com> <4C62E6E7.6020508@redhat.com> Message-ID: <4C659A37.5060200@redhat.com> On 08/11/2010 02:07 PM, Pavel Z?na wrote: > On 2010-08-10 21:47, Rob Crittenden wrote: >> Pavel Zuna wrote: >>> This is required for the webUI, since we're dropping Genshi. *ehm* :) >>> >>> You can't use this command on the CLI. It takes one optional argument: >>> the name of an IPA object. If not specified, meta-data for all objects >>> are returned. >>> >>> Note: If you want to try it out on the CLI, just comment out the >>> INTERNAL = True line. >>> >>> Pavel >> >> The code looks ok but export.py doesn't seem like it matches the >> functions the plugin provides (and is rather generic in nature). Can we >> rename this json.py or something? >> >> rob > > I thought that we might use the file for other plugins that export > data, but there probably won't be any for a while. > > Renamed it to internal.py as I'm sure we'll see more internal commands > as we progress with the webUI. Patch attached. > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Aug 13 20:21:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Aug 2010 16:21:45 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 512 track server certs with certmonger Message-ID: <4C65A959.4010100@redhat.com> I did it again :-( -------------- next part -------------- An embedded message was scrubbed... From: Rob Crittenden Subject: [Freeipa-users] [PATCH] 512 track server certs with certmonger Date: Fri, 13 Aug 2010 16:03:55 -0400 Size: 32324 URL: From rcritten at redhat.com Fri Aug 13 20:21:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Aug 2010 16:21:58 -0400 Subject: [Freeipa-devel] Fwd: Re: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent Message-ID: <4C65A966.1040001@redhat.com> I did it again :-( -------------- next part -------------- An embedded message was scrubbed... From: John Dennis Subject: Re: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent Date: Fri, 13 Aug 2010 16:15:54 -0400 Size: 1980 URL: From ayoung at redhat.com Fri Aug 13 20:24:54 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Aug 2010 16:24:54 -0400 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C63F8B1.5030700@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> <4C63F8B1.5030700@redhat.com> Message-ID: <4C65AA16.1090204@redhat.com> On 08/12/2010 09:35 AM, Pavel Z?na wrote: > On 2010-08-12 14:38, Rob Crittenden wrote: >> Pavel Z?na wrote: >>> On 2010-08-12 04:46, Rob Crittenden wrote: >>>> Pavel Z?na wrote: >>>>> setattr and addattr can now be used both to set all values of >>>>> ANY attribute. the last setattr always resets the attribute to >>>>> the specified value and all addattr append to it. >>>>> >>>>> Examples: >>>>> user-mod testuser --setattr=title=msc >>>>> title: msc >>>>> user-mod testuser --setattr=title=msb >>>>> title: msb >>>>> user-mod testuser --addattr=title=msc >>>>> title: msb, msc >>>>> user-mod testuser --setattr=title= >>>>> title: >>>>> user-mod testuser --setattr=title=msc --addattr=msb >>>>> title: msc, msb >>>>> user-mod testuser --setattr=title=ing --addattr=bc >>>>> title: ing, bc >>>>> user-mod testuser --setattr=title=doc >>>>> title: doc >>>>> >>>>> It's not very user friendly, but it's going to be used very very >>>>> rarely in special conditions in the CLI and we can use it to save >>>>> lots of JSON-RPC roundtrips in the webUI. >>>>> >>>>> Pavel >>>> >>>> It was my intention when I added addattr and setattr that one couldn't >>>> set already-defined params this way. They were silently ignored. So >>>> you >>>> couldn't do: >>>> >>>> user-mod testuser --setattr=givenname=Jeff >>>> >>>> This would be possible with this patch. Was that intentional? >>>> >>>> BTW I have the start of a test suite for this functionality. >>>> >>>> rob >>> >>> Yes, it is intentional. I forgot to mention it in the description. I'm >>> using setattr/addattr for everything in the webUI - it makes the code a >>> lot simpler. >> >> Doesn't that invalidate all the validators we have in the plugins? This >> is why I disallowed it. >> >> rob > > It does, but I see these options as something only experienced users, > who need to set something we don't support directly, will use. > Sometimes they might want to disable the validators, if they know what > they're doing. We could also make the setattr/addattr handler in > frontend.py detect if a there's a validator available and use it. > > Validators in the webUI is still something we need to figure out. Adam > was proposing having validators in the form of regex strings, which is > not a bad idea as it's easy to implement on any platform/language. On > the other hand, I don't know if it's good enough for all parameters we > have. > > Hmm. There's a lot to think about here actually. I'll make it my > homework for the weekend. :) > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Here's my version, that just calls the parameter prior to updating the attr. I tested it with: [root at ipa ~]# ipa user-mod --setattr uidnumber=555 kfrog --------------------- Modified user "kfrog" --------------------- User login: kfrog First name: Kermit Last name: Frog Home directory: /home/kfrog Login shell: /bin/sh UID: 555 Groups: ipausers [root at ipa ~]# ipa user-mod --setattr uidnumber=frog kfrog ipa: ERROR: invalid 'uidnumber': must be an integer -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0007-setaddattr.patch Type: text/x-patch Size: 5973 bytes Desc: not available URL: From ayoung at redhat.com Fri Aug 13 20:51:39 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Aug 2010 16:51:39 -0400 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C65AA16.1090204@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> <4C63F8B1.5030700@redhat.com> <4C65AA16.1090204@redhat.com> Message-ID: <4C65B05B.5070202@redhat.com> On 08/13/2010 04:24 PM, Adam Young wrote: > On 08/12/2010 09:35 AM, Pavel Z?na wrote: >> On 2010-08-12 14:38, Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> On 2010-08-12 04:46, Rob Crittenden wrote: >>>>> Pavel Z?na wrote: >>>>>> setattr and addattr can now be used both to set all values of >>>>>> ANY attribute. the last setattr always resets the attribute to >>>>>> the specified value and all addattr append to it. >>>>>> >>>>>> Examples: >>>>>> user-mod testuser --setattr=title=msc >>>>>> title: msc >>>>>> user-mod testuser --setattr=title=msb >>>>>> title: msb >>>>>> user-mod testuser --addattr=title=msc >>>>>> title: msb, msc >>>>>> user-mod testuser --setattr=title= >>>>>> title: >>>>>> user-mod testuser --setattr=title=msc --addattr=msb >>>>>> title: msc, msb >>>>>> user-mod testuser --setattr=title=ing --addattr=bc >>>>>> title: ing, bc >>>>>> user-mod testuser --setattr=title=doc >>>>>> title: doc >>>>>> >>>>>> It's not very user friendly, but it's going to be used very very >>>>>> rarely in special conditions in the CLI and we can use it to save >>>>>> lots of JSON-RPC roundtrips in the webUI. >>>>>> >>>>>> Pavel >>>>> >>>>> It was my intention when I added addattr and setattr that one >>>>> couldn't >>>>> set already-defined params this way. They were silently ignored. >>>>> So you >>>>> couldn't do: >>>>> >>>>> user-mod testuser --setattr=givenname=Jeff >>>>> >>>>> This would be possible with this patch. Was that intentional? >>>>> >>>>> BTW I have the start of a test suite for this functionality. >>>>> >>>>> rob >>>> >>>> Yes, it is intentional. I forgot to mention it in the description. I'm >>>> using setattr/addattr for everything in the webUI - it makes the >>>> code a >>>> lot simpler. >>> >>> Doesn't that invalidate all the validators we have in the plugins? This >>> is why I disallowed it. >>> >>> rob >> >> It does, but I see these options as something only experienced users, >> who need to set something we don't support directly, will use. >> Sometimes they might want to disable the validators, if they know >> what they're doing. We could also make the setattr/addattr handler in >> frontend.py detect if a there's a validator available and use it. >> >> Validators in the webUI is still something we need to figure out. >> Adam was proposing having validators in the form of regex strings, >> which is not a bad idea as it's easy to implement on any >> platform/language. On the other hand, I don't know if it's good >> enough for all parameters we have. >> >> Hmm. There's a lot to think about here actually. I'll make it my >> homework for the weekend. :) >> >> Pavel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Here's my version, that just calls the parameter prior to updating the > attr. I tested it with: > > [root at ipa ~]# ipa user-mod --setattr uidnumber=555 kfrog > --------------------- > Modified user "kfrog" > --------------------- > User login: kfrog > First name: Kermit > Last name: Frog > Home directory: /home/kfrog > Login shell: /bin/sh > UID: 555 > Groups: ipausers > [root at ipa ~]# ipa user-mod --setattr uidnumber=frog kfrog > ipa: ERROR: invalid 'uidnumber': must be an integer > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ Pushed to Master. ACKed in IRC by rcrit, and based on a pzuna patch reviewd by both myself and rcrit > freeipa-devel Since this was a diff to a Patch ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Aug 13 23:38:31 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Aug 2010 19:38:31 -0400 Subject: [Freeipa-devel] [PATCH] Add a new INTERNAL plugin that exports plugin meta-data into JSON. In-Reply-To: <4C659A37.5060200@redhat.com> References: <4C618C79.2060202@redhat.com> <4C61ACB4.3020304@redhat.com> <4C62E6E7.6020508@redhat.com> <4C659A37.5060200@redhat.com> Message-ID: <4C65D777.8090803@redhat.com> On 08/13/2010 03:17 PM, Adam Young wrote: > On 08/11/2010 02:07 PM, Pavel Z?na wrote: >> On 2010-08-10 21:47, Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> This is required for the webUI, since we're dropping Genshi. *ehm* :) >>>> >>>> You can't use this command on the CLI. It takes one optional argument: >>>> the name of an IPA object. If not specified, meta-data for all objects >>>> are returned. >>>> >>>> Note: If you want to try it out on the CLI, just comment out the >>>> INTERNAL = True line. >>>> >>>> Pavel >>> >>> The code looks ok but export.py doesn't seem like it matches the >>> functions the plugin provides (and is rather generic in nature). Can we >>> rename this json.py or something? >>> >>> rob >> >> I thought that we might use the file for other plugins that export >> data, but there probably won't be any for a while. >> >> Renamed it to internal.py as I'm sure we'll see more internal >> commands as we progress with the webUI. Patch attached. >> >> Pavel >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Sat Aug 14 02:20:42 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Aug 2010 22:20:42 -0400 Subject: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C65B05B.5070202@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> <4C63F8B1.5030700@redhat.com> <4C65AA16.1090204@redhat.com> <4C65B05B.5070202@redhat.com> Message-ID: <4C65FD7A.6080506@redhat.com> >> >> Here's my version, that just calls the parameter prior to updating >> the attr. I tested it with: >> >> [root at ipa ~]# ipa user-mod --setattr uidnumber=555 kfrog >> --------------------- >> Modified user "kfrog" >> --------------------- >> User login: kfrog >> First name: Kermit >> Last name: Frog >> Home directory: /home/kfrog >> Login shell: /bin/sh >> UID: 555 >> Groups: ipausers >> [root at ipa ~]# ipa user-mod --setattr uidnumber=frog kfrog >> ipa: ERROR: invalid 'uidnumber': must be an integer >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/ > Pushed to Master. ACKed in IRC by rcrit, and based on a pzuna patch > reviewd by both myself and rcrit > >> freeipa-devel > Since this was a diff to a Patch ACK > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Just ran the details patch on top of this, and the user details page does not work with it. If you submit the page even with a minor edit to the full name you get an error: 'login' is required. I've tested it out with the JSON and CURL: Here is the JSON it is sending: {"method":"user_mod","params":[["zoe"],{"all":true,"setattr":["cn=Zoe MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="],"addattr":[],"givenname":"Zoe","sn":"MacPhearson","uidnumber":"1044896486","homedirectory":"/home/zoe","sizelimit":100}],"id":4} The message 'login' is required is coming from the call I added to value = self.params[attr](value) As it is the message inside RequirementError, which gets called from parameters.py, specifically: def validate(self, value): """ Check validity of ``value``. :param value: A proposed value for this parameter. """ if value is None: if self.required: raise RequirementError(name=self.cli_name) My guess is the correct change is to skip this call if value is null, which seems to be what is happening. But I suspect we are sending in bogus values to setattr. Notice this part of the JSON "setattr":["cn=Zoe MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="] My guess is that the details page shouldn't send any unset values. "uid=" in particular is probably a mistake. REmoving that from the JSON gets us to: an internal error has occurred. Here's the stack trace: ipa: ERROR: non-public: TypeError: 'NoneType' object is not iterable Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipaserver/rpcserver.py", line 206, in wsgi_execute result = self.Command[name](*args, **options) File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 401, in __call__ ret = self.run(*args, **options) File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 674, in run return self.execute(*args, **options) File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line 431, in execute addset = set(get_attributes(options.get('addattr', []))) File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line 52, in get_attributes for attr in attrs: Again, this is from the __call__ code, which means it is from the code I added, although now I'm not sure which parameter, if any is tripped the code. I ran the full body of unit tests on the code as commited, and they all pass, as did the set of tests that Rob cobbled up (reminder: Lets get those added) so I don't think the call to self.params[attr](value) is wrong, but that it catches input errors that would have bitten us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 16 13:30:19 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 09:30:19 -0400 Subject: [Freeipa-devel] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C65FD7A.6080506@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> <4C63F8B1.5030700@redhat.com> <4C65AA16.1090204@redhat.com> <4C65B05B.5070202@redhat.com> <4C65FD7A.6080506@redhat.com> Message-ID: <4C693D6B.9080104@redhat.com> I'm going to top post this to make sure it gets seen. Just ran the details patch on top of this, and the user details page does not work with it. > > If you submit the page even with a minor edit to the full name you get > an error: 'login' is required. > > I've tested it out with the JSON and CURL: Here is the JSON it is > sending: > > {"method":"user_mod","params":[["zoe"],{"all":true,"setattr":["cn=Zoe > MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="],"addattr":[],"givenname":"Zoe","sn":"MacPhearson","uidnumber":"1044896486","homedirectory":"/home/zoe","sizelimit":100}],"id":4} > > > The message 'login' is required is coming from the call I added to > value = self.params[attr](value) > As it is the message inside RequirementError, which gets called from > parameters.py, specifically: > > def validate(self, value): > """ > Check validity of ``value``. > > :param value: A proposed value for this parameter. > """ > if value is None: > if self.required: > raise RequirementError(name=self.cli_name) > > > My guess is the correct change is to skip this call if value is null, > which seems to be what is happening. But I suspect we are sending in > bogus values to setattr. Notice this part of the JSON > > "setattr":["cn=Zoe > MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="] > > > My guess is that the details page shouldn't send any unset values. > "uid=" in particular is probably a mistake. REmoving that from the > JSON gets us to: an internal error has occurred. > > Here's the stack trace: > > ipa: ERROR: non-public: TypeError: 'NoneType' object is not iterable > Traceback (most recent call last): > File "/home/ayoung/devel/freeipa/ipaserver/rpcserver.py", line 206, > in wsgi_execute > result = self.Command[name](*args, **options) > File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 401, in > __call__ > ret = self.run(*args, **options) > File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 674, in run > return self.execute(*args, **options) > File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line > 431, in execute > addset = set(get_attributes(options.get('addattr', []))) > File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line > 52, in get_attributes > for attr in attrs: > > > Again, this is from the __call__ code, which means it is from the code > I added, although now I'm not sure which parameter, if any is tripped > the code. > > > I ran the full body of unit tests on the code as commited, and they > all pass, as did the set of tests that Rob cobbled up (reminder: Lets > get those added) so I don't think the call to self.params[attr](value) > is wrong, but that it catches input errors that would have bitten us. Thinking about it afterwards, I wondered if the extra information was messing it up. I tried it with just the following json and it seems to have worked. {"method":"user_mod","params":[["zoe"],{"all":true,"setattr":["cn=Zoe MacLeod","gidnumber=1044896486"],"sizelimit":100}],"id":4} So I think we need to identify values that have changed on the screen, and only send that subset in the setattr portion. Only send values in as addattr if they were previously unset. And avoid setting any values as parameters outside of setaddr or addattr. From rcritten at redhat.com Mon Aug 16 14:37:55 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 10:37:55 -0400 Subject: [Freeipa-devel] [PATCH] 494 ipa command failover In-Reply-To: <4C641245.3050702@redhat.com> References: <4C4E05FF.8040400@redhat.com> <4C641245.3050702@redhat.com> Message-ID: <4C694D43.2000502@redhat.com> Adam Young wrote: > On 07/26/2010 06:02 PM, Rob Crittenden wrote: >> Add failover to the ipa command. If the server defined in >> /etc/ipa/default.conf is not available then each ldap SRV record in >> DNS is tried until either one is found that works or none of the >> available servers are responding. >> >> ticket #15 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From ayoung at redhat.com Mon Aug 16 20:49:27 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 16:49:27 -0400 Subject: [Freeipa-devel] Change the behaviour of addattr/setattr parameters In-Reply-To: <4C693D6B.9080104@redhat.com> References: <4C605F8E.5000904@redhat.com> <4C63606B.8030402@redhat.com> <4C63B2D4.9080909@redhat.com> <4C63EB52.8050600@redhat.com> <4C63F8B1.5030700@redhat.com> <4C65AA16.1090204@redhat.com> <4C65B05B.5070202@redhat.com> <4C65FD7A.6080506@redhat.com> <4C693D6B.9080104@redhat.com> Message-ID: <4C69A457.2000508@redhat.com> On 08/16/2010 09:30 AM, Adam Young wrote: > I'm going to top post this to make sure it gets seen. > Just ran the details patch on top of this, and the user details page > does not work with it. >> >> If you submit the page even with a minor edit to the full name you >> get an error: 'login' is required. >> >> I've tested it out with the JSON and CURL: Here is the JSON it is >> sending: >> >> {"method":"user_mod","params":[["zoe"],{"all":true,"setattr":["cn=Zoe >> MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="],"addattr":[],"givenname":"Zoe","sn":"MacPhearson","uidnumber":"1044896486","homedirectory":"/home/zoe","sizelimit":100}],"id":4} >> >> >> >> The message 'login' is required is coming from the call I added to >> value = self.params[attr](value) >> As it is the message inside RequirementError, which gets called from >> parameters.py, specifically: >> >> def validate(self, value): >> """ >> Check validity of ``value``. >> >> :param value: A proposed value for this parameter. >> """ >> if value is None: >> if self.required: >> raise RequirementError(name=self.cli_name) >> >> >> My guess is the correct change is to skip this call if value is >> null, which seems to be what is happening. But I suspect we are >> sending in bogus values to setattr. Notice this part of the JSON >> >> "setattr":["cn=Zoe >> MacLeod","gidnumber=1044896486","title=","displayname=","initials=","uid=","mail=","street=","location=","postalcode=","ou=","carlicense="] >> >> >> >> My guess is that the details page shouldn't send any unset values. >> "uid=" in particular is probably a mistake. REmoving that from the >> JSON gets us to: an internal error has occurred. >> >> Here's the stack trace: >> >> ipa: ERROR: non-public: TypeError: 'NoneType' object is not iterable >> Traceback (most recent call last): >> File "/home/ayoung/devel/freeipa/ipaserver/rpcserver.py", line 206, >> in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 401, in >> __call__ >> ret = self.run(*args, **options) >> File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 674, in run >> return self.execute(*args, **options) >> File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line >> 431, in execute >> addset = set(get_attributes(options.get('addattr', []))) >> File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line >> 52, in get_attributes >> for attr in attrs: >> >> >> Again, this is from the __call__ code, which means it is from the >> code I added, although now I'm not sure which parameter, if any is >> tripped the code. >> >> >> I ran the full body of unit tests on the code as commited, and they >> all pass, as did the set of tests that Rob cobbled up (reminder: Lets >> get those added) so I don't think the call to >> self.params[attr](value) is wrong, but that it catches input errors >> that would have bitten us. > > Thinking about it afterwards, I wondered if the extra information was > messing it up. I tried it with just the following json and it seems to > have worked. > > {"method":"user_mod","params":[["zoe"],{"all":true,"setattr":["cn=Zoe > MacLeod","gidnumber=1044896486"],"sizelimit":100}],"id":4} > > > So I think we need to identify values that have changed on the screen, > and only send that subset in the setattr portion. Only send values in > as addattr if they were previously unset. And avoid setting any > values as parameters outside of setaddr or addattr. THe attached patch does this: when a field that has been changed loses focus, the new value is added to a collection (changed_detail). Then, when the user clicks "update" the values in the changed_detail collection is added to the setattr collection of the JSON request. I'm not too clear on the difference between setattr and addattr, so I suspect that the patch is incomplete. I just wanted to get the idea out there. THis patch should apply on top of pzuna's two outstanding UI patches. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-catch-update-for-setattr.patch Type: text/x-patch Size: 4637 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 16 21:09:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 17:09:56 -0400 Subject: [Freeipa-devel] [PATCH] 509 add BuildRequries for authconfig In-Reply-To: <4C62EFD0.7060701@redhat.com> References: <4C61B967.9070102@redhat.com> <4C62EFD0.7060701@redhat.com> Message-ID: <4C69A924.1010007@redhat.com> Pavel Z?na wrote: > On 2010-08-10 22:41, Rob Crittenden wrote: >> In ipapython/dnsclient.py we import acutil which is provided by >> authconfig. This can get invoked by setup.py so we need to have it at >> build time. >> >> rob >> > > ack. > > Pavel pushed to master From rcritten at redhat.com Mon Aug 16 21:14:12 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 17:14:12 -0400 Subject: [Freeipa-devel] [PATCH] 502 hosts can fetch keytabs In-Reply-To: <4C605314.2010704@redhat.com> References: <4C5B787F.5020905@redhat.com> <4C605314.2010704@redhat.com> Message-ID: <4C69AA24.4050202@redhat.com> Pavel Z?na wrote: > On 2010-08-06 04:50, Rob Crittenden wrote: >> Enable a host to retrieve a keytab for all its services. >> >> Using the host service principal one should be able to retrieve a keytab >> for other services for the host using ipa-getkeytab. This required a >> number of changes: >> >> - allow hosts in the service's managedby to write krbPrincipalKey >> - automatically add the host to managedby when a service is created >> - fix ipa-getkeytab to return the entire prinicpal and not just the >> first data element. It was returning "host" from the service tgt >> and not host/ipa.example.com >> - fix the display of the managedby attribute in the service plugin >> >> This led to a number of changes in the service unit tests. I took the >> opportunity to switch to the Declarative scheme and tripled the number >> of tests we were doing. This shed some light on a few bugs in the plugin: >> >> - if a service had a bad usercertificate it was impossible to delete the >> service. I made it a bit more flexible. >> - I added a summary for the mod and find commands >> - has_keytab wasn't being set in the find output >> >> This is for ticket 68 >> >> rob >> > ack. > > Pavel pushed to master From rcritten at redhat.com Mon Aug 16 21:15:06 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 17:15:06 -0400 Subject: [Freeipa-devel] [PATCH] 501 report managedby errors In-Reply-To: <4C603273.30409@redhat.com> References: <4C5C41F0.4050901@redhat.com> <4C603273.30409@redhat.com> Message-ID: <4C69AA5A.5090707@redhat.com> Adam Young wrote: > On 08/06/2010 01:10 PM, Rob Crittenden wrote: >> Report failures when adding/removing members to the managedby >> attribute (services and hosts). >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Mon Aug 16 21:27:25 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 17:27:25 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent Message-ID: <4C69AD3D.1010807@redhat.com> Ok, this time forward the e-mail with the patch. -------------- next part -------------- An embedded message was scrubbed... From: Rob Crittenden Subject: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent Date: Fri, 13 Aug 2010 16:03:50 -0400 Size: 11563 URL: From rcritten at redhat.com Mon Aug 16 21:56:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 17:56:23 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent In-Reply-To: <4C69AD3D.1010807@redhat.com> References: <4C69AD3D.1010807@redhat.com> Message-ID: <4C69B407.7030808@redhat.com> Rob Crittenden wrote: > Ok, this time forward the e-mail with the patch. Updated patch. There was a merge failure in ipa.spec.in. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-511-2-dogtag.patch Type: application/mbox Size: 5213 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 16 22:00:01 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 18:00:01 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 512 track server certs with certmonger In-Reply-To: <4C65A959.4010100@redhat.com> References: <4C65A959.4010100@redhat.com> Message-ID: <4C69B4E1.9000606@redhat.com> Rob Crittenden wrote: > I did it again :-( Updated patch that should apply cleanly. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-512-2-cert.patch Type: application/mbox Size: 14752 bytes Desc: not available URL: From ayoung at redhat.com Mon Aug 16 23:04:46 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 19:04:46 -0400 Subject: [Freeipa-devel] [PATCH] 505 make logging more configurable In-Reply-To: <4C615C4C.6060901@redhat.com> References: <4C615C4C.6060901@redhat.com> Message-ID: <4C69C40E.6000700@redhat.com> On 08/10/2010 10:03 AM, Rob Crittenden wrote: > Make the server log level more configurable, not defaulting to debug. > > This disables debug output in the Apache log by default. If you want > increased output create /etc/ipa/server.conf and set it to: > > [global] > debug=True > > If this is too much output you can select verbose output instead: > > [global] > debug=False > verbose=True > > ticket 60 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 00:54:06 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 20:54:06 -0400 Subject: [Freeipa-devel] [PATCH] 507 add support for ldap:///self bind rules in the aci plugin In-Reply-To: <4C618B6B.9050801@redhat.com> References: <4C618B6B.9050801@redhat.com> Message-ID: <4C69DDAE.3040502@redhat.com> On 08/10/2010 01:24 PM, Rob Crittenden wrote: > Add support for ldap:///self bind rules > > This is added mainly so the self service rules can be updated without > resorting to ldapmodify. > > ticket 80 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 00:58:09 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 20:58:09 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 510 enable compat plugin by default In-Reply-To: <4C6302EA.4040704@redhat.com> References: <4C6302EA.4040704@redhat.com> Message-ID: <4C69DEA1.7080607@redhat.com> On 08/11/2010 04:07 PM, Rob Crittenden wrote: > originall sent to wrong list > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 00:59:07 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 16 Aug 2010 20:59:07 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent In-Reply-To: <4C69B407.7030808@redhat.com> References: <4C69AD3D.1010807@redhat.com> <4C69B407.7030808@redhat.com> Message-ID: <4C69DEDB.20509@redhat.com> On 08/16/2010 05:56 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Ok, this time forward the e-mail with the patch. > > Updated patch. There was a merge failure in ipa.spec.in. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From pzuna at redhat.com Tue Aug 17 13:08:42 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 17 Aug 2010 15:08:42 +0200 Subject: [Freeipa-devel] [PATCH] Fix Update function on details page. Message-ID: <4C6A89DA.5040703@redhat.com> This is a fix to the setattr/addattr problem discussed in the thread: [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters The problem was that parameters with no values are automatically set to None by the framework and it wasn't handled properly in baseldap.py:get_attributes function. Also, there were two logical bugs in details.js: 1) atttribute callbacks to update values were called for input elements instead of dt elements 2) it was always trying to update the primary key I've seen Adam's fix. It's another way to do it, but I think it's better not to rely on things like element focus to make assumptions about data. There were also some logical bugs in the update code as mentioned above, so this patch is a little bit more complete. By the way; please use Reply All when replying to freeipa-devel threads. Pavel From pzuna at redhat.com Tue Aug 17 13:09:23 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 17 Aug 2010 15:09:23 +0200 Subject: [Freeipa-devel] [PATCH] Fix Update function on details page. In-Reply-To: <4C6A89DA.5040703@redhat.com> References: <4C6A89DA.5040703@redhat.com> Message-ID: <4C6A8A03.2000207@redhat.com> On 08/17/2010 03:08 PM, Pavel Zuna wrote: > This is a fix to the setattr/addattr problem discussed in the thread: > [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr parameters > > The problem was that parameters with no values are automatically > set to None by the framework and it wasn't handled properly in > baseldap.py:get_attributes function. Also, there were two logical > bugs in details.js: > 1) atttribute callbacks to update values were called for input elements > instead of dt elements > 2) it was always trying to update the primary key > > > I've seen Adam's fix. It's another way to do it, but I think it's better > not to rely on things like element focus to make assumptions about data. > There were also some logical bugs in the update code as mentioned above, > so this patch is a little bit more complete. > > By the way; please use Reply All when replying to freeipa-devel threads. > > Pavel Oups. Forgot to attach the patch. :) Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0016-updatefix.patch Type: application/mbox Size: 2528 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 17 13:23:51 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 17 Aug 2010 15:23:51 +0200 Subject: [Freeipa-devel] [PATCH] admiyo-0001-hash-params In-Reply-To: <4C643F2F.9060003@redhat.com> References: <4C643F2F.9060003@redhat.com> Message-ID: <4C6A8D67.4000301@redhat.com> On 08/12/2010 08:36 PM, Adam Young wrote: > I'll try to use a patch naming structure similar to what Pavel's using: > > > This patch fixes https://fedorahosted.org/freeipa/ticket/135. > > Instead of HTML Params starting with '?' we use the Hash '#' as the > startgin point. This keeps the broswer from sending addition http > requests to the server whenever we need to update the URL. > Sorry for a late review. I can't get this patch to apply, probably because of some other patches that were pushed in between. Please add me to CC on your patches, so they end up in my Inbox and I'll make sure to review them faster. Pavel From ayoung at redhat.com Tue Aug 17 13:35:47 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 09:35:47 -0400 Subject: [Freeipa-devel] [PATCH] Fix Update function on details page. In-Reply-To: <4C6A8A03.2000207@redhat.com> References: <4C6A89DA.5040703@redhat.com> <4C6A8A03.2000207@redhat.com> Message-ID: <4C6A9033.1080601@redhat.com> On 08/17/2010 09:09 AM, Pavel Zuna wrote: > On 08/17/2010 03:08 PM, Pavel Zuna wrote: >> This is a fix to the setattr/addattr problem discussed in the thread: >> [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr >> parameters >> >> The problem was that parameters with no values are automatically >> set to None by the framework and it wasn't handled properly in >> baseldap.py:get_attributes function. Also, there were two logical >> bugs in details.js: >> 1) atttribute callbacks to update values were called for input elements >> instead of dt elements >> 2) it was always trying to update the primary key >> >> >> I've seen Adam's fix. It's another way to do it, but I think it's better >> not to rely on things like element focus to make assumptions about data. >> There were also some logical bugs in the update code as mentioned above, >> so this patch is a little bit more complete. >> >> By the way; please use Reply All when replying to freeipa-devel threads. >> >> Pavel > > Oups. Forgot to attach the patch. :) > > Pavel ACK From ayoung at redhat.com Tue Aug 17 18:12:02 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 14:12:02 -0400 Subject: [Freeipa-devel] Extending Details, user and otherwise Message-ID: <4C6AD0F2.5000501@redhat.com> The structure of our details code is basciallt [categorid, categoryDisplay, atrrtibutes] and attributes are [attributeId, attributeDisplay, I've inlined the user details at the bottom as an example. In order to make these configuratble by the end user, here is a strawman proposal: Create a dir under /var/lib/ipa/details with code that will, at run time, get validated and then appended to the web code. This code, unlike the resources approach, will not be autogenerated. The code for the user details gets pre-populated there from a static copy somewhere under /usr/share/ipa. The end user can then customize it to add or remove fields. If they so desire, they can add in custom javascript code that will provide more advanced UI. An example might be a n interactive map for showing seat and parking assignments. IPA server install and uninstall will be aware of these files, and treat them gently. Doing an install will not over write the files if they are present, but will instead rename and back them up. Same with uninstall, unless an additional option is given ( for example --ultraclean) the is repsonbile for removing all vestiges of IPA from a system. The details pages will be named -details.js: user-details.js, group-details.js and so forth. As I said, this is a strawman. Please poke holes in it, and make better suggestions. var user_details_lists = [ ['identity', 'Identity Details', [ ['title', 'Title'], ['givenname', 'First Name'], ['sn', 'Last Name'], ['cn', 'Full Name'], ['displayname', 'Dispaly Name'], ['initials', 'Initials'] ] ], ['account', 'Account Details', [ ['call_a_status', 'Account Status'], ['uid', 'Login'], ['call_a_password', 'Password'], ['uidnumber', 'UID'], ['gidnumber', 'GID'], ['homedirectory', 'homedirectory'] ] ], ['contact', 'Contact Details', [ ['mail', 'E-mail Address'], ['call_a_numbers', 'Numbers'] ] ], ['address', 'Mailing Address', [ ['street', 'Address'], ['location', 'City'], ['call_a_st', 'State'], ['postalcode', 'ZIP'] ] ], ['employee', 'Employee Information', [ ['ou', 'Org. Unit'], ['call_a_manager', 'Manager'] ] ], ['misc', 'Misc. Information', [ ['carlicense', 'Car License'] ] ] ] From ayoung at redhat.com Tue Aug 17 19:07:37 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 15:07:37 -0400 Subject: [Freeipa-devel] [PATCH] Fix Update function on details page. In-Reply-To: <4C6A8A03.2000207@redhat.com> References: <4C6A89DA.5040703@redhat.com> <4C6A8A03.2000207@redhat.com> Message-ID: <4C6ADDF9.4080402@redhat.com> On 08/17/2010 09:09 AM, Pavel Zuna wrote: > On 08/17/2010 03:08 PM, Pavel Zuna wrote: >> This is a fix to the setattr/addattr problem discussed in the thread: >> [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr >> parameters >> >> The problem was that parameters with no values are automatically >> set to None by the framework and it wasn't handled properly in >> baseldap.py:get_attributes function. Also, there were two logical >> bugs in details.js: >> 1) atttribute callbacks to update values were called for input elements >> instead of dt elements >> 2) it was always trying to update the primary key >> >> >> I've seen Adam's fix. It's another way to do it, but I think it's better >> not to rely on things like element focus to make assumptions about data. >> There were also some logical bugs in the update code as mentioned above, >> so this patch is a little bit more complete. >> >> By the way; please use Reply All when replying to freeipa-devel threads. >> >> Pavel > > Oups. Forgot to attach the patch. :) > > Pavel ACK From ayoung at redhat.com Tue Aug 17 19:09:21 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 15:09:21 -0400 Subject: [Freeipa-devel] [PATCH] Fix Update function on details page. In-Reply-To: <4C6A8A03.2000207@redhat.com> References: <4C6A89DA.5040703@redhat.com> <4C6A8A03.2000207@redhat.com> Message-ID: <4C6ADE61.2000508@redhat.com> On 08/17/2010 09:09 AM, Pavel Zuna wrote: > On 08/17/2010 03:08 PM, Pavel Zuna wrote: >> This is a fix to the setattr/addattr problem discussed in the thread: >> [Freeipa-devel] [PATCH] Change the behaviour of addattr/setattr >> parameters >> >> The problem was that parameters with no values are automatically >> set to None by the framework and it wasn't handled properly in >> baseldap.py:get_attributes function. Also, there were two logical >> bugs in details.js: >> 1) atttribute callbacks to update values were called for input elements >> instead of dt elements >> 2) it was always trying to update the primary key >> >> >> I've seen Adam's fix. It's another way to do it, but I think it's better >> not to rely on things like element focus to make assumptions about data. >> There were also some logical bugs in the update code as mentioned above, >> so this patch is a little bit more complete. >> >> By the way; please use Reply All when replying to freeipa-devel threads. >> >> Pavel > > Oups. Forgot to attach the patch. :) > > Pavel Pushed to master From ayoung at redhat.com Tue Aug 17 19:11:10 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 15:11:10 -0400 Subject: [Freeipa-devel] [PATCH] Clean details.js. In-Reply-To: <4C618CC7.6030909@redhat.com> References: <4C618CC7.6030909@redhat.com> Message-ID: <4C6ADECE.8090805@redhat.com> On 08/10/2010 01:30 PM, Pavel Zuna wrote: > What does it mean? > I removed duplicate code, that was pasted here from the user details > page. > > ipa_details_init doesn't call ipa_init anymore. > > ipa_details_create takes a second optional parameter, that can be set to > a container element if we want to place the definition lists into a > specific > element instead of . In our case, we place stuff in
id="content"> > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 19:11:20 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 15:11:20 -0400 Subject: [Freeipa-devel] [PATCH] Clean ipa.js and make it load plugin meta-data over JSON-RPC. In-Reply-To: <4C618CA2.8040808@redhat.com> References: <4C618CA2.8040808@redhat.com> Message-ID: <4C6ADED8.7010300@redhat.com> On 08/10/2010 01:30 PM, Pavel Zuna wrote: > What it means? > Well, first I removed some development control variables from ipa.js. > Namely useSampleData and sizelimit. I moved useSampleData to the top > of index.xhtml. This way we won't forget about it when we don't need > it anymore. sizelimit has nothing to do in ipa.js and be hardcoded > for ALL commands! Some don't have this parameter and could fail. > > Since ipa_init now loads meta-data over JSON-RPC, we need to wait for > it to finish its job. That's why I put a second parameter to ipa_init: > on_win. ipa_init will call on_win when all data is loaded properly and > we can start building the page. > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 19:11:34 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 15:11:34 -0400 Subject: [Freeipa-devel] [PATCH] Make user details work again in the webUI. In-Reply-To: <4C618CF5.8080104@redhat.com> References: <4C618CF5.8080104@redhat.com> Message-ID: <4C6ADEE6.4010402@redhat.com> On 08/10/2010 01:31 PM, Pavel Zuna wrote: > Unfortunately we can't have any javascript in *.inc files, because > the browser will strip them for security reasons. I moved all the > attribute callbacks etc. to the only logical place: user.js. > > It's fine for now, but user.js is going to need some serious cleaning > up in the future. > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Aug 17 21:48:32 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 17 Aug 2010 17:48:32 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0001-hash-params In-Reply-To: <4C6A8D67.4000301@redhat.com> References: <4C643F2F.9060003@redhat.com> <4C6A8D67.4000301@redhat.com> Message-ID: <4C6B03B0.1080006@redhat.com> On 08/17/2010 09:23 AM, Pavel Zuna wrote: > On 08/12/2010 08:36 PM, Adam Young wrote: >> I'll try to use a patch naming structure similar to what Pavel's using: >> >> >> This patch fixes https://fedorahosted.org/freeipa/ticket/135. >> >> Instead of HTML Params starting with '?' we use the Hash '#' as the >> startgin point. This keeps the broswer from sending addition http >> requests to the server whenever we need to update the URL. >> > Sorry for a late review. I can't get this patch to apply, probably > because of some other patches that were pushed in between. Please add > me to CC on your patches, so they end up in my Inbox and I'll make > sure to review them faster. > > Pavel Here is an updated version. It applies on top of the pzuna patches that were pushed earlier. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0008-hash-params.patch Type: text/x-patch Size: 11788 bytes Desc: not available URL: From pzuna at redhat.com Wed Aug 18 12:35:05 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 18 Aug 2010 14:35:05 +0200 Subject: [Freeipa-devel] [PATCH] admiyo-0001-hash-params In-Reply-To: <4C6B03B0.1080006@redhat.com> References: <4C643F2F.9060003@redhat.com> <4C6A8D67.4000301@redhat.com> <4C6B03B0.1080006@redhat.com> Message-ID: <4C6BD379.2050108@redhat.com> On 08/17/2010 11:48 PM, Adam Young wrote: > On 08/17/2010 09:23 AM, Pavel Zuna wrote: >> On 08/12/2010 08:36 PM, Adam Young wrote: >>> I'll try to use a patch naming structure similar to what Pavel's using: >>> >>> >>> This patch fixes https://fedorahosted.org/freeipa/ticket/135. >>> >>> Instead of HTML Params starting with '?' we use the Hash '#' as the >>> startgin point. This keeps the broswer from sending addition http >>> requests to the server whenever we need to update the URL. >>> >> Sorry for a late review. I can't get this patch to apply, probably >> because of some other patches that were pushed in between. Please add >> me to CC on your patches, so they end up in my Inbox and I'll make >> sure to review them faster. >> >> Pavel > > > Here is an updated version. It applies on top of the pzuna patches that > were pushed earlier. > There are some trailing white spaces and you forgot to remove user-details.inc from install/static/Makefile.am (doesn't build). I tried it out in my browser and it's literally 10 times faster than before. Very nice. Let's hope that using # won't have any serious side effects. auto-ACK when you fix those minor things. Pavel From pzuna at redhat.com Wed Aug 18 12:43:42 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 18 Aug 2010 14:43:42 +0200 Subject: [Freeipa-devel] [PATCH] Add link to json2.js to index.xhtml. Message-ID: <4C6BD57E.9090209@redhat.com> Applies after Adam's 0008 patch (Hash params). Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0017-json2.patch Type: text/x-patch Size: 793 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 18 14:06:39 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 18 Aug 2010 10:06:39 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0001-hash-params In-Reply-To: <4C6BD379.2050108@redhat.com> References: <4C643F2F.9060003@redhat.com> <4C6A8D67.4000301@redhat.com> <4C6B03B0.1080006@redhat.com> <4C6BD379.2050108@redhat.com> Message-ID: <4C6BE8EF.5020706@redhat.com> On 08/18/2010 08:35 AM, Pavel Zuna wrote: > On 08/17/2010 11:48 PM, Adam Young wrote: >> On 08/17/2010 09:23 AM, Pavel Zuna wrote: >>> On 08/12/2010 08:36 PM, Adam Young wrote: >>>> I'll try to use a patch naming structure similar to what Pavel's >>>> using: >>>> >>>> >>>> This patch fixes https://fedorahosted.org/freeipa/ticket/135. >>>> >>>> Instead of HTML Params starting with '?' we use the Hash '#' as the >>>> startgin point. This keeps the broswer from sending addition http >>>> requests to the server whenever we need to update the URL. >>>> >>> Sorry for a late review. I can't get this patch to apply, probably >>> because of some other patches that were pushed in between. Please add >>> me to CC on your patches, so they end up in my Inbox and I'll make >>> sure to review them faster. >>> >>> Pavel >> >> >> Here is an updated version. It applies on top of the pzuna patches that >> were pushed earlier. >> > > There are some trailing white spaces and you forgot to remove > user-details.inc from install/static/Makefile.am (doesn't build). > > I tried it out in my browser and it's literally 10 times faster than > before. Very nice. Let's hope that using # won't have any serious side > effects. > > auto-ACK when you fix those minor things. > > Pavel I found a couple other things as well, so I'll resubmit the patch once it is done. Good catch on the .inc file, I should have caught that. From ayoung at redhat.com Wed Aug 18 14:07:55 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 18 Aug 2010 10:07:55 -0400 Subject: [Freeipa-devel] [PATCH] Add link to json2.js to index.xhtml. In-Reply-To: <4C6BD57E.9090209@redhat.com> References: <4C6BD57E.9090209@redhat.com> Message-ID: <4C6BE93B.8080309@redhat.com> On 08/18/2010 08:43 AM, Pavel Zuna wrote: > Applies after Adam's 0008 patch (Hash params). > > Pavel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK It should apply before mine, too, right? You can push this one, the merge will be trivial. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 18 18:18:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Aug 2010 14:18:22 -0400 Subject: [Freeipa-devel] [PATCH] 513 global size and time limit patch Message-ID: <4C6C23EE.9060901@redhat.com> Use the global time and size limits on searches if not user-provided. This removes the default settings for searching but the option is still there. I also added a test to ensure that the limit is properly enforced and the truncated flag is set. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-513-limit.patch Type: text/x-patch Size: 6060 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 18 19:39:40 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 18 Aug 2010 15:39:40 -0400 Subject: [Freeipa-devel] [PATCH] 513 global size and time limit patch In-Reply-To: <4C6C23EE.9060901@redhat.com> References: <4C6C23EE.9060901@redhat.com> Message-ID: <4C6C36FC.8090506@redhat.com> On 08/18/2010 02:18 PM, Rob Crittenden wrote: > Use the global time and size limits on searches if not user-provided. > > This removes the default settings for searching but the option is > still there. > > I also added a test to ensure that the limit is properly enforced and > the truncated flag is set. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Aug 18 20:59:51 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 18 Aug 2010 16:59:51 -0400 Subject: [Freeipa-devel] [PATCH] Hash Params Redux Message-ID: <4C6C49C7.8000204@redhat.com> The patch replaces the earlier Hash Params patch. It fixs the build issues, and fixes the group details page as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0009-hash-params.patch Type: text/x-patch Size: 21352 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 18 21:01:17 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 18 Aug 2010 17:01:17 -0400 Subject: [Freeipa-devel] [PATCH] Sample Metadata Message-ID: <4C6C4A1D.5050402@redhat.com> This is a trivial patch (despite its length) which is a snapshot of the output of the metadata plugin. This is required to do serverless development, but does not impact the deployed code. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0010-sample-metadata.patch Type: text/x-patch Size: 140562 bytes Desc: not available URL: From rcritten at redhat.com Wed Aug 18 23:08:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Aug 2010 19:08:11 -0400 Subject: [Freeipa-devel] [PATCH] 514 make ldap2 class work with clients Message-ID: <4C6C67DB.1000109@redhat.com> Make ldap2 class work as a client library as well. Move the user-private group caching code out of the global config and determine the value the first time it is needed. Renamed global_init() back to get_schema() and make it take an optional connection. This solves the problem of being able to do all operations with a simple bind instead of GSSAPI. Moved the global get_syntax() into a class method so that a schema can be passed in. If a schema wasn't loaded during the module import then it is loaded when the connection is created (so we have the credntials needed for binding). ticket 63 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-514-ldap.patch Type: text/x-patch Size: 8479 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 19 14:51:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 10:51:33 -0400 Subject: [Freeipa-devel] [PATCH] 505 make logging more configurable In-Reply-To: <4C69C40E.6000700@redhat.com> References: <4C615C4C.6060901@redhat.com> <4C69C40E.6000700@redhat.com> Message-ID: <4C6D44F5.7020904@redhat.com> Adam Young wrote: > On 08/10/2010 10:03 AM, Rob Crittenden wrote: >> Make the server log level more configurable, not defaulting to debug. >> >> This disables debug output in the Apache log by default. If you want >> increased output create /etc/ipa/server.conf and set it to: >> >> [global] >> debug=True >> >> If this is too much output you can select verbose output instead: >> >> [global] >> debug=False >> verbose=True >> >> ticket 60 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Thu Aug 19 14:51:36 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 10:51:36 -0400 Subject: [Freeipa-devel] [PATCH] 507 add support for ldap:///self bind rules in the aci plugin In-Reply-To: <4C69DDAE.3040502@redhat.com> References: <4C618B6B.9050801@redhat.com> <4C69DDAE.3040502@redhat.com> Message-ID: <4C6D44F8.1050102@redhat.com> Adam Young wrote: > On 08/10/2010 01:24 PM, Rob Crittenden wrote: >> Add support for ldap:///self bind rules >> >> This is added mainly so the self service rules can be updated without >> resorting to ldapmodify. >> >> ticket 80 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. pushed to master From rcritten at redhat.com Thu Aug 19 14:51:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 10:51:39 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent In-Reply-To: <4C69DEDB.20509@redhat.com> References: <4C69AD3D.1010807@redhat.com> <4C69B407.7030808@redhat.com> <4C69DEDB.20509@redhat.com> Message-ID: <4C6D44FB.10703@redhat.com> Adam Young wrote: > On 08/16/2010 05:56 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Ok, this time forward the e-mail with the patch. >> >> Updated patch. There was a merge failure in ipa.spec.in. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From rcritten at redhat.com Thu Aug 19 14:52:13 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 10:52:13 -0400 Subject: [Freeipa-devel] [PATCH] 513 global size and time limit patch In-Reply-To: <4C6C36FC.8090506@redhat.com> References: <4C6C23EE.9060901@redhat.com> <4C6C36FC.8090506@redhat.com> Message-ID: <4C6D451D.40509@redhat.com> Adam Young wrote: > On 08/18/2010 02:18 PM, Rob Crittenden wrote: >> Use the global time and size limits on searches if not user-provided. >> >> This removes the default settings for searching but the option is >> still there. >> >> I also added a test to ensure that the limit is properly enforced and >> the truncated flag is set. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master From ayoung at redhat.com Thu Aug 19 16:39:13 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 12:39:13 -0400 Subject: [Freeipa-devel] admiyo-freeipa-0011 const correctness in ipa-client Message-ID: <4C6D5E31.8080403@redhat.com> https://fedorahosted.org/freeipa/attachment/ticket/148/admiyo-freeipa-0011-const-correctness.patch made the data type for server consistent and correct across its usage. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0011-const-correctness.patch Type: text/x-patch Size: 1373 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 19 18:47:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 14:47:33 -0400 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C5B1320.6060602@redhat.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> <4C5982A8.6050000@redhat.com> <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> <4C59C30E.8000503@redhat.com> <4C5B1320.6060602@redhat.com> Message-ID: <4C6D7C45.4030400@redhat.com> Dmitri Pal wrote: > 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. A creative solution but I'd almost rather go with the complex way than this. If you wanted to change a command-line you'd have to manually go through all the groups and change them one at a time. I'm not 100% opposed to the command and group-of-commands interface I just wonder if in the typical case it isn't overkill. For those with thousands of sudo rules it may make a lot of sense. My initial objection was it seemed to be over-engineered, a Bentley when a Pinto would do :-) > > 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. Let me tell you how this would work on the command line. We'd likely have 3 plugins (I'm not married to these names, they are just illustrative): - sudo_cmds: CRUD for managing the individual commands - sudo_group: CRUD for grouping sudo_cmds into groups of commands - sudo_rules: CRUD for managing the rules themselves, the core of which assigning sudo_groups and/or sudo_cmds to it. I gather that a sudo command would use the memberOf plugin to be a member of a sudo group, right? Could that be skipped? It does help us know what groups use a given command but we can run a query to find that if necessary. That might alleviate Simo's concern that memberOf isn't free. The other problem with multi-value commands is we don't yet have a nice way on the command-line to manage them. You'd want to be able to do things like "delete the 3rd of these 5" or "modify the 7th one to this", etc. rob From sbose at redhat.com Thu Aug 19 19:30:37 2010 From: sbose at redhat.com (Sumit Bose) Date: Thu, 19 Aug 2010 21:30:37 +0200 Subject: [Freeipa-devel] Sudoers schema In-Reply-To: <4C6D7C45.4030400@redhat.com> References: <4C58A64A.9060009@redhat.com> <6EDF1298-3652-4BCA-BA79-0955CB92C06F@citrixonline.com> <4C596A70.9080500@redhat.com> <4C5982A8.6050000@redhat.com> <557F768E-DCC6-433E-A1CD-604FA6DDF320@citrixonline.com> <4C59C30E.8000503@redhat.com> <4C5B1320.6060602@redhat.com> <4C6D7C45.4030400@redhat.com> Message-ID: <20100819193037.GA2957@localhost.localdomain> On Thu, Aug 19, 2010 at 02:47:33PM -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > >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. > > A creative solution but I'd almost rather go with the complex way > than this. If you wanted to change a command-line you'd have to > manually go through all the groups and change them one at a time. > > I'm not 100% opposed to the command and group-of-commands interface > I just wonder if in the typical case it isn't overkill. For those > with thousands of sudo rules it may make a lot of sense. My initial > objection was it seemed to be over-engineered, a Bentley when a > Pinto would do :-) > > > > >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. > > Let me tell you how this would work on the command line. We'd likely > have 3 plugins (I'm not married to these names, they are just > illustrative): > > - sudo_cmds: CRUD for managing the individual commands > - sudo_group: CRUD for grouping sudo_cmds into groups of commands > - sudo_rules: CRUD for managing the rules themselves, the core of > which assigning sudo_groups and/or sudo_cmds to it. +1 if we want to have groups we should use this design, because this is the way other objects like hosts or services are handled in IPA. > > I gather that a sudo command would use the memberOf plugin to be a > member of a sudo group, right? Could that be skipped? It does help > us know what groups use a given command but we can run a query to > find that if necessary. That might alleviate Simo's concern that > memberOf isn't free. As Jakub mentioned earlier sudo creates search filters based on the user and his group memberships. So I think the memberOf plugin is not needed. bye, Sumit > > The other problem with multi-value commands is we don't yet have a > nice way on the command-line to manage them. You'd want to be able > to do things like "delete the 3rd of these 5" or "modify the 7th one > to this", etc. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From ayoung at redhat.com Thu Aug 19 21:01:49 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 17:01:49 -0400 Subject: [Freeipa-devel] [PATCH] admiyo 0012 ldap_initialize Message-ID: <4C6D9BBD.4040703@redhat.com> Gets rid of the last of our compiler warnings by removing a deprecated function call :ldap_init should be replaced with ldap_initialize. https://fedorahosted.org/freeipa/attachment/ticket/151/admiyo-freeipa-0012-ldap_initialize.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0012-ldap_initialize.patch Type: text/x-patch Size: 1822 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 19 21:45:04 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 17:45:04 -0400 Subject: [Freeipa-devel] [PATCH] admiyo 0012 ldap_initialize In-Reply-To: <4C6D9BBD.4040703@redhat.com> References: <4C6D9BBD.4040703@redhat.com> Message-ID: <4C6DA5E0.4050700@redhat.com> Adam Young wrote: > Gets rid of the last of our compiler warnings by removing a deprecated > function call :ldap_init should be replaced with ldap_initialize. > > https://fedorahosted.org/freeipa/attachment/ticket/151/admiyo-freeipa-0012-ldap_initialize.patch > > I think the scheme should be ldaps and not ldap in the port 636 case. I'm not sure you need/want to set errno either. rob From rcritten at redhat.com Thu Aug 19 21:48:29 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Aug 2010 17:48:29 -0400 Subject: [Freeipa-devel] [PATCH] Sample Metadata In-Reply-To: <4C6C4A1D.5050402@redhat.com> References: <4C6C4A1D.5050402@redhat.com> Message-ID: <4C6DA6AD.2050800@redhat.com> Adam Young wrote: > This is a trivial patch (despite its length) which is a snapshot of the > output of the metadata plugin. This is required to do serverless > development, but does not impact the deployed code. ACK I removed a slew of trailing whitespace and pushed this to master rob From pzuna at redhat.com Thu Aug 19 22:41:38 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 20 Aug 2010 00:41:38 +0200 Subject: [Freeipa-devel] [PATCH] Hash Params Redux In-Reply-To: <4C6C49C7.8000204@redhat.com> References: <4C6C49C7.8000204@redhat.com> Message-ID: <4C6DB322.6080402@redhat.com> On 2010-08-18 22:59, Adam Young wrote: > The patch replaces the earlier Hash Params patch. It fixs the build > issues, and fixes the group details page as well. > Git still reports white space errors, but that's hardly a show stopper. ACK. Pavel From pzuna at redhat.com Thu Aug 19 22:48:01 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 20 Aug 2010 00:48:01 +0200 Subject: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required. Message-ID: <4C6DB4A1.3090207@redhat.com> The paste server had some issues with it and end tags are required by the standard anyway. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0018-scripttags.patch Type: text/x-patch Size: 2075 bytes Desc: not available URL: From pzuna at redhat.com Thu Aug 19 22:50:30 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 20 Aug 2010 00:50:30 +0200 Subject: [Freeipa-devel] [PATCH] Add webUI application to lite-server. Message-ID: <4C6DB536.8080109@redhat.com> The web UI should now be available through the lite-server. For security purposes only files under install/static ending with extensions listed in lite-server:WebUIApp.EXTENSION_TO_MIME_MAP dict are served. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: pzuna-freeipa-0019-litewebui.patch Type: text/x-patch Size: 2451 bytes Desc: not available URL: From pzuna at redhat.com Thu Aug 19 22:51:39 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 20 Aug 2010 00:51:39 +0200 Subject: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required. In-Reply-To: <4C6DB4A1.3090207@redhat.com> References: <4C6DB4A1.3090207@redhat.com> Message-ID: <4C6DB57B.3020206@redhat.com> On 2010-08-20 00:48, Pavel Z?na wrote: > The paste server had some issues with it and end tags are required by > the standard anyway. > > Pavel I forgot to mention that this applies after Adam's 0009 patch (updated Hash Params). Pavel From ayoung at redhat.com Fri Aug 20 00:25:05 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:25:05 -0400 Subject: [Freeipa-devel] [PATCH] Sample Metadata In-Reply-To: <4C6DA6AD.2050800@redhat.com> References: <4C6C4A1D.5050402@redhat.com> <4C6DA6AD.2050800@redhat.com> Message-ID: <4C6DCB61.20006@redhat.com> On 08/19/2010 05:48 PM, Rob Crittenden wrote: > Adam Young wrote: >> This is a trivial patch (despite its length) which is a snapshot of the >> output of the metadata plugin. This is required to do serverless >> development, but does not impact the deployed code. > > ACK > > I removed a slew of trailing whitespace and pushed this to master > > rob Git white space errors are propbably worth ignoring for stuff like this. From ayoung at redhat.com Fri Aug 20 00:26:46 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:26:46 -0400 Subject: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required. In-Reply-To: <4C6DB57B.3020206@redhat.com> References: <4C6DB4A1.3090207@redhat.com> <4C6DB57B.3020206@redhat.com> Message-ID: <4C6DCBC6.3020909@redhat.com> On 08/19/2010 06:51 PM, Pavel Z?na wrote: > On 2010-08-20 00:48, Pavel Z?na wrote: >> The paste server had some issues with it and end tags are required by >> the standard anyway. >> >> Pavel > > I forgot to mention that this applies after Adam's 0009 patch (updated > Hash Params). > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Is this only a problem on the javascript tags, or are we going to see a problem on all of the xhtml that doesn't use closing tags? Either way, it should be filed as an upstream bug. From ayoung at redhat.com Fri Aug 20 00:31:56 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:31:56 -0400 Subject: [Freeipa-devel] [PATCH] admiyo 0012 ldap_initialize In-Reply-To: <4C6DA5E0.4050700@redhat.com> References: <4C6D9BBD.4040703@redhat.com> <4C6DA5E0.4050700@redhat.com> Message-ID: <4C6DCCFC.6020507@redhat.com> On 08/19/2010 05:45 PM, Rob Crittenden wrote: > Adam Young wrote: >> Gets rid of the last of our compiler warnings by removing a deprecated >> function call :ldap_init should be replaced with ldap_initialize. >> >> https://fedorahosted.org/freeipa/attachment/ticket/151/admiyo-freeipa-0012-ldap_initialize.patch >> >> >> > > I think the scheme should be ldaps and not ldap in the port 636 case. > I'm not sure you need/want to set errno either. > > rob I think you are right on "ldaps". I'm guesiing we don't havea test case for that/ As for errno, malloc will set it to ENOMEM, so we should probably leave it. I'll post an updated patch. From ayoung at redhat.com Fri Aug 20 00:40:18 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:40:18 -0400 Subject: [Freeipa-devel] [PATCH] admiyo 0012 ldap_initialize In-Reply-To: <4C6DCCFC.6020507@redhat.com> References: <4C6D9BBD.4040703@redhat.com> <4C6DA5E0.4050700@redhat.com> <4C6DCCFC.6020507@redhat.com> Message-ID: <4C6DCEF2.8050803@redhat.com> On 08/19/2010 08:31 PM, Adam Young wrote: > On 08/19/2010 05:45 PM, Rob Crittenden wrote: >> Adam Young wrote: >>> Gets rid of the last of our compiler warnings by removing a deprecated >>> function call :ldap_init should be replaced with ldap_initialize. >>> >>> https://fedorahosted.org/freeipa/attachment/ticket/151/admiyo-freeipa-0012-ldap_initialize.patch >>> >>> >>> >> >> I think the scheme should be ldaps and not ldap in the port 636 case. >> I'm not sure you need/want to set errno either. >> >> rob > > > I think you are right on "ldaps". I'm guesiing we don't havea test > case for that/ As for errno, malloc will set it to ENOMEM, so we > should probably leave it. > > I'll post an updated patch. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ldaps. Not setting errno -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0012-2-ldap_initialize.patch Type: text/x-patch Size: 1905 bytes Desc: not available URL: From ayoung at redhat.com Fri Aug 20 00:50:44 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:50:44 -0400 Subject: [Freeipa-devel] [PATCH] Hash Params Redux In-Reply-To: <4C6DB322.6080402@redhat.com> References: <4C6C49C7.8000204@redhat.com> <4C6DB322.6080402@redhat.com> Message-ID: <4C6DD164.7020100@redhat.com> On 08/19/2010 06:41 PM, Pavel Z?na wrote: > On 2010-08-18 22:59, Adam Young wrote: >> The patch replaces the earlier Hash Params patch. It fixs the build >> issues, and fixes the group details page as well. >> > > Git still reports white space errors, but that's hardly a show stopper. > > ACK. > > Pavel Removed white space errors and pushed to master From ayoung at redhat.com Fri Aug 20 00:51:29 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Aug 2010 20:51:29 -0400 Subject: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required. In-Reply-To: <4C6DCBC6.3020909@redhat.com> References: <4C6DB4A1.3090207@redhat.com> <4C6DB57B.3020206@redhat.com> <4C6DCBC6.3020909@redhat.com> Message-ID: <4C6DD191.8070904@redhat.com> On 08/19/2010 08:26 PM, Adam Young wrote: > On 08/19/2010 06:51 PM, Pavel Z?na wrote: >> On 2010-08-20 00:48, Pavel Z?na wrote: >>> The paste server had some issues with it and end tags are required by >>> the standard anyway. >>> >>> Pavel >> >> I forgot to mention that this applies after Adam's 0009 patch >> (updated Hash Params). >> >> Pavel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Is this only a problem on the javascript tags, or are we going to see > a problem on all of the xhtml that doesn't use closing tags? > Either way, it should be filed as an upstream bug. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. From rcritten at redhat.com Fri Aug 20 13:40:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Aug 2010 09:40:59 -0400 Subject: [Freeipa-devel] [PATCH] admiyo 0012 ldap_initialize In-Reply-To: <4C6DCEF2.8050803@redhat.com> References: <4C6D9BBD.4040703@redhat.com> <4C6DA5E0.4050700@redhat.com> <4C6DCCFC.6020507@redhat.com> <4C6DCEF2.8050803@redhat.com> Message-ID: <4C6E85EB.8080303@redhat.com> Adam Young wrote: > On 08/19/2010 08:31 PM, Adam Young wrote: >> On 08/19/2010 05:45 PM, Rob Crittenden wrote: >>> Adam Young wrote: >>>> Gets rid of the last of our compiler warnings by removing a deprecated >>>> function call :ldap_init should be replaced with ldap_initialize. >>>> >>>> https://fedorahosted.org/freeipa/attachment/ticket/151/admiyo-freeipa-0012-ldap_initialize.patch >>>> >>>> >>>> >>> >>> I think the scheme should be ldaps and not ldap in the port 636 case. >>> I'm not sure you need/want to set errno either. >>> >>> rob >> >> >> I think you are right on "ldaps". I'm guesiing we don't havea test >> case for that/ As for errno, malloc will set it to ENOMEM, so we >> should probably leave it. >> >> I'll post an updated patch. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ldaps. > Not setting errno ACK From rcritten at redhat.com Fri Aug 20 13:41:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Aug 2010 09:41:49 -0400 Subject: [Freeipa-devel] admiyo-freeipa-0011 const correctness in ipa-client In-Reply-To: <4C6D5E31.8080403@redhat.com> References: <4C6D5E31.8080403@redhat.com> Message-ID: <4C6E861D.2080105@redhat.com> Adam Young wrote: > https://fedorahosted.org/freeipa/attachment/ticket/148/admiyo-freeipa-0011-const-correctness.patch > > > made the data type for server consistent and correct across its usage. ACK From ayoung at redhat.com Fri Aug 20 13:52:13 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 20 Aug 2010 09:52:13 -0400 Subject: [Freeipa-devel] admiyo-freeipa-0011 const correctness in ipa-client In-Reply-To: <4C6E861D.2080105@redhat.com> References: <4C6D5E31.8080403@redhat.com> <4C6E861D.2080105@redhat.com> Message-ID: <4C6E888D.6050902@redhat.com> On 08/20/2010 09:41 AM, Rob Crittenden wrote: > Adam Young wrote: >> https://fedorahosted.org/freeipa/attachment/ticket/148/admiyo-freeipa-0011-const-correctness.patch >> >> >> >> made the data type for server consistent and correct across its usage. > > ACK pushed to master From ayoung at redhat.com Fri Aug 20 15:19:29 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 20 Aug 2010 11:19:29 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-freeipa-0013 Revert of the host details patch Message-ID: <4C6E9D01.80301@redhat.com> That patch got pushed by accident. Reverting. -------------- next part -------------- A non-text attachment was scrubbed... Name: admiyo-freeipa-0013-host-details-revert.patch Type: text/x-patch Size: 2990 bytes Desc: not available URL: From ayoung at redhat.com Fri Aug 20 17:10:26 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 20 Aug 2010 13:10:26 -0400 Subject: [Freeipa-devel] Object structure for UI Message-ID: <4C6EB702.60800@redhat.com> I've been working with the "add host " and "host details" pages for the past couple of days. It is getting time to refactor how we do add and details, to avoid cutting and pasting. Here's the general structure I'm approach on taking. For each collection (user, group, host, etc) there will be an instance of a SearchForm object that maps to that collection. This object will have a reference to at a minimum two other form objects, one for details, one for "add". Here's changes for the Search Form Objects * objects will be held in global scoped variables, not inside function scope as it is currently done now. * Search Forms will not contain any state. All state will be contianed in the primary key, the json responses, and the form params. * Instead of rendering the search form in the constructor, it will have a "build" function that performs the same actions. The same general approach will happen with the Add and Details approach. In general, each page will have an instance of some type of "Form" object. The difference between the user search form and the group search form is which instance all of the methods look for. so the Update button will be bound to function() { userDetailsForm.update() }; or function() { groupDetailsForm.update() }; appropriately. The goal here is to reduce duplicated code, and the corresponding copy-and-paste errors it introduces. Ideally I'd like to do something like: var activeDetailsForm; ... activeDetails = userDetailsForm; ... $("#addEdit").click( function() { activeDetailsForm.addEdit() }; ); my one concern is making sure that variables like activeDetailsForm get set correctly upon back-button. For now I am going to put the details work in the host.js file, as I don't want to get into a knarly merge with details.js. At some point, Pavel and I will coordinate moving it into details.js. I am considering adding add.js for that functionality, but am reluctant to add yet another file, as that increased the download time for initial view of the site. search, details, and add are all considered facets inside the code. If you look at the URL, you should see something like: #tab=user&facet=search or #tab=group&facet=details&pkey=ipausers Every collection will have these three facts, but will have a collection of 0 or more additional facets. For example, user will have a membership facet. This collection of facets will be used to create the links off of the details page at the top. The general trend is going to be to divide code up into one of three categories: Framework, Domain Objects, Wiring. Thus, things like search, details, and navigation in the abstract are framework, user and groups and so forth are domain objects, and wiring is the population of things like the navigation and facets. There is obviously some blurring between wiring and domain objects, but the guiding principal will be that wiring is for Fitting together the overall site, such as how the navigation is set up, where as Domain is for UI behavior specific to a collection. This will not be a single patch, but instead will be the target of several small refactorings as I implement features in the site. I've already started with the DetailsForm, but need to create the AddForm, and will do so as I implement add hosts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Aug 20 20:20:37 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Aug 2010 16:20:37 -0400 Subject: [Freeipa-devel] [PATCH] 515 F-14 compatibility patch Message-ID: <4C6EE395.2070908@redhat.com> F-14 introduced a number of changes including an updated krb5 server package and python 2.7. In krb5 the binaries moved from /usr/kerberos/* to /usr/* so some paths need to be adjusted. What I did was include a PATH in the env that covers both of these locations. Python 2.7 made some changes to xmlrpclib and httplib as well that aren't quite backwards compatible. I added some specific version checks so we can do the right thing internally. This is ticket 155 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-515-f14.patch Type: application/mbox Size: 7750 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 20 22:23:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Aug 2010 18:23:22 -0400 Subject: [Freeipa-devel] [PATCH] 516 remove passwords from logs Message-ID: <4C6F005A.8070300@redhat.com> This replaces the existing no password logging code. It only removed passwords sent on the command line, not those that may be in the stdout/stderr of the response from the command. I found a couple of invocations of ssl_get that weren't being cleaned properly, added scrubbing to that too. ticket 156 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-516-log.patch Type: application/mbox Size: 4935 bytes Desc: not available URL: From ayoung at redhat.com Mon Aug 23 00:32:36 2010 From: ayoung at redhat.com (Adam Young) Date: Sun, 22 Aug 2010 20:32:36 -0400 Subject: [Freeipa-devel] [PATCH] 516 remove passwords from logs In-Reply-To: <4C6F005A.8070300@redhat.com> References: <4C6F005A.8070300@redhat.com> Message-ID: <4C71C1A4.3070808@redhat.com> On 08/20/2010 06:23 PM, Rob Crittenden wrote: > This replaces the existing no password logging code. It only removed > passwords sent on the command line, not those that may be in the > stdout/stderr of the response from the command. > > I found a couple of invocations of ssl_get that weren't being cleaned > properly, added scrubbing to that too. > > ticket 156 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 23 00:38:19 2010 From: ayoung at redhat.com (Adam Young) Date: Sun, 22 Aug 2010 20:38:19 -0400 Subject: [Freeipa-devel] [PATCH] 515 F-14 compatibility patch In-Reply-To: <4C6EE395.2070908@redhat.com> References: <4C6EE395.2070908@redhat.com> Message-ID: <4C71C2FB.9000901@redhat.com> On 08/20/2010 04:20 PM, Rob Crittenden wrote: > F-14 introduced a number of changes including an updated krb5 server > package and python 2.7. > > In krb5 the binaries moved from /usr/kerberos/* to /usr/* so some > paths need to be adjusted. What I did was include a PATH in the env > that covers both of these locations. > > Python 2.7 made some changes to xmlrpclib and httplib as well that > aren't quite backwards compatible. I added some specific version > checks so we can do the right thing internally. > > This is ticket 155 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I think that in the explicit path construction you do vic of line 115, you want the kerberos subpath libraries to come before /usr/bin, otherwise it will find the non-kerberized versions of the function. I realize that testing on the Major/Minor is functional, but wouldn't it make more sense to test for the existanec of the newer call, use that if it was avaiable, as opposed to gating on version number? Seems like it would be less prone to breakage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Aug 23 02:12:59 2010 From: ayoung at redhat.com (Adam Young) Date: Sun, 22 Aug 2010 22:12:59 -0400 Subject: [Freeipa-devel] BA-BBQ Message-ID: <4C71D92B.40509@redhat.com> Pavel, Thoughts of jquery.ba-bbq have been marinating in the back of my brain. I know that the Back button doesn't work so well with hjashparams, and that BBQ purports to fix this, but I had some sort of mental shift I had to make. I think I have it now. BBQ, and in fact the whole AJAX approach works off of client side code, which means the whole hash params approach. What I didn't get was that the best approach to dealing with this was to drive the site off of the event that happens when the url hash changes. We need to do this. Bascially, navigation.js registers: $(window).bind( 'hashchange', function(e) { ... } This function gets called each time the URL hash changes, which happens on either a tab click or on a back button (lets start with those two, there will be more) So bascially, this function is our dispatach. Instead of having to register the onclick functions for each of the tabs, we know that they will all end up in this function, and then we let it parse the params for us. BBQ has the concept of a stack, where we can push and pop state. Thyis might be useful for pushing a query, going to the details page, and then popping the query afterwards. I'm still mulling this over. Note, we will want to replace the custom hash param working we are doing with JQuery.deparam and JQuery.param calls, as they are much more mature, and it is less code we have to debug. The thing I have to figure out now is what this will do to navigation on the details, add and groups pages. From pzuna at redhat.com Mon Aug 23 11:51:00 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 23 Aug 2010 13:51:00 +0200 Subject: [Freeipa-devel] BA-BBQ In-Reply-To: <4C71D92B.40509@redhat.com> References: <4C71D92B.40509@redhat.com> Message-ID: <4C7260A4.40708@redhat.com> On 08/23/2010 04:12 AM, Adam Young wrote: > Pavel, > > > Thoughts of jquery.ba-bbq have been marinating in the back of my brain. > I know that the Back button doesn't work so well with hjashparams, and > that BBQ purports to fix this, but I had some sort of mental shift I had > to make. I think I have it now. > > BBQ, and in fact the whole AJAX approach works off of client side code, > which means the whole hash params approach. What I didn't get was that > the best approach to dealing with this was to drive the site off of the > event that happens when the url hash changes. We need to do this. > > Bascially, navigation.js registers: > > $(window).bind( 'hashchange', function(e) { > ... > } > > This function gets called each time the URL hash changes, which happens > on either a tab click or on a back button (lets start with those two, > there will be more) > > > So bascially, this function is our dispatach. Instead of having to > register the onclick functions for each of the tabs, we know that they > will all end up in this function, and then we let it parse the params > for us. > > BBQ has the concept of a stack, where we can push and pop state. Thyis > might be useful for pushing a query, going to the details page, and then > popping the query afterwards. I'm still mulling this over. > > > Note, we will want to replace the custom hash param working we are doing > with JQuery.deparam and JQuery.param calls, as they are much more > mature, and it is less code we have to debug. Sure, from what I've read in jQuery docs, it looks more powerful than what we currently have. > The thing I have to figure out now is what this will do to navigation on > the details, add and groups pages. I don't think it will be a problem. Functional links (such as Reset, Update, Add, Remove) are only used to run javascript functions - the URL, query string or hash doesn't change. Most of these action are also "one way" only. We don't want the user to be able to go Back after he updated an entry. (Going back in this case should probably bring him back to the search page). Pavel From pzuna at redhat.com Mon Aug 23 12:28:00 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 23 Aug 2010 14:28:00 +0200 Subject: [Freeipa-devel] Extending Details, user and otherwise In-Reply-To: <4C6AD0F2.5000501@redhat.com> References: <4C6AD0F2.5000501@redhat.com> Message-ID: <4C726950.1070109@redhat.com> On 08/17/2010 08:12 PM, Adam Young wrote: > The structure of our details code is basciallt > > [categorid, categoryDisplay, atrrtibutes] > > and attributes are > > [attributeId, attributeDisplay, > > > I've inlined the user details at the bottom as an example. > > > In order to make these configuratble by the end user, here is a strawman > proposal: > > > Create a dir under /var/lib/ipa/details with code that will, at run > time, get validated and then appended to the web code. This code, unlike > the resources approach, will not be autogenerated. > The code for the user details gets pre-populated there from a static > copy somewhere under /usr/share/ipa. The end user can then customize it > to add or remove fields. > If they so desire, they can add in custom javascript code that will > provide more advanced UI. An example might be a n interactive map for > showing seat and parking assignments. > > > IPA server install and uninstall will be aware of these files, and treat > them gently. Doing an install will not over write the files if they are > present, but will instead rename and back them up. Same with uninstall, > unless an additional option is given ( for example --ultraclean) the is > repsonbile for removing all vestiges of IPA from a system. > > The details pages will be named -details.js: > user-details.js, group-details.js and so forth. > > > As I said, this is a strawman. Please poke holes in it, and make better > suggestions. > That's one possible way. I was thinking of something a little bit different, but similar from the user perspective. We could have the -details.js files under (for example) /etc/ipa/webui/ and /usr/share/ipa/static would have symlinks to them. It's basically the same thing Adam proposed, but in this case, we don't have to monitor, generate or append anything. We only need to make sure not to overwrite these files after installation. Take it as just another proposal, because I'm not sure if it's 100% compatible with the Linux file system philosophy. There might also be some security risks using symlinks to /etc/*, although I'm not aware of any. Pavel From rcritten at redhat.com Mon Aug 23 13:03:44 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Aug 2010 09:03:44 -0400 Subject: [Freeipa-devel] Fwd: Python 3.2a1 in rawhide Message-ID: <4C7271B0.50609@redhat.com> From the the Fedora devel list. Hopefully this will just be a minor packaging change. I filed ticket #157 to track this. rob -------------- next part -------------- An embedded message was scrubbed... From: David Malcolm Subject: Python 3.2a1 in rawhide Date: Sat, 21 Aug 2010 18:48:31 -0400 Size: 6095 URL: From ayoung at redhat.com Mon Aug 23 13:51:50 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 23 Aug 2010 09:51:50 -0400 Subject: [Freeipa-devel] Extending Details, user and otherwise In-Reply-To: <4C726950.1070109@redhat.com> References: <4C6AD0F2.5000501@redhat.com> <4C726950.1070109@redhat.com> Message-ID: <4C727CF6.2010704@redhat.com> On 08/23/2010 08:28 AM, Pavel Zuna wrote: > On 08/17/2010 08:12 PM, Adam Young wrote: >> The structure of our details code is basciallt >> >> [categorid, categoryDisplay, atrrtibutes] >> >> and attributes are >> >> [attributeId, attributeDisplay, >> >> >> I've inlined the user details at the bottom as an example. >> >> >> In order to make these configuratble by the end user, here is a strawman >> proposal: >> >> >> Create a dir under /var/lib/ipa/details with code that will, at run >> time, get validated and then appended to the web code. This code, unlike >> the resources approach, will not be autogenerated. >> The code for the user details gets pre-populated there from a static >> copy somewhere under /usr/share/ipa. The end user can then customize it >> to add or remove fields. >> If they so desire, they can add in custom javascript code that will >> provide more advanced UI. An example might be a n interactive map for >> showing seat and parking assignments. >> >> >> IPA server install and uninstall will be aware of these files, and treat >> them gently. Doing an install will not over write the files if they are >> present, but will instead rename and back them up. Same with uninstall, >> unless an additional option is given ( for example --ultraclean) the is >> repsonbile for removing all vestiges of IPA from a system. >> >> The details pages will be named -details.js: >> user-details.js, group-details.js and so forth. >> >> >> As I said, this is a strawman. Please poke holes in it, and make better >> suggestions. >> > > That's one possible way. I was thinking of something a little bit > different, but similar from the user perspective. > > We could have the -details.js files under > (for example) /etc/ipa/webui/ and /usr/share/ipa/static would have > symlinks to them. It's basically the same thing Adam proposed, but in > this case, we don't have to monitor, generate or append anything. We > only need to make sure not to overwrite these files after installation. > > Take it as just another proposal, because I'm not sure if it's 100% > compatible with the Linux file system philosophy. There might also be > some security risks using symlinks to /etc/*, although I'm not aware > of any. > > Pavel I think that, so long as you tell the Apache server that follow symlinks is OK, this should work. I think it is secure as well. In order to corrupt the apache server, you would need to be able to change what is at the far end of the symlink, which means you have root privs already. I'm OK with this approach. From rcritten at redhat.com Mon Aug 23 14:04:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Aug 2010 10:04:41 -0400 Subject: [Freeipa-devel] [PATCH] 515 F-14 compatibility patch In-Reply-To: <4C71C2FB.9000901@redhat.com> References: <4C6EE395.2070908@redhat.com> <4C71C2FB.9000901@redhat.com> Message-ID: <4C727FF9.1040007@redhat.com> Adam Young wrote: > On 08/20/2010 04:20 PM, Rob Crittenden wrote: >> F-14 introduced a number of changes including an updated krb5 server >> package and python 2.7. >> >> In krb5 the binaries moved from /usr/kerberos/* to /usr/* so some >> paths need to be adjusted. What I did was include a PATH in the env >> that covers both of these locations. >> >> Python 2.7 made some changes to xmlrpclib and httplib as well that >> aren't quite backwards compatible. I added some specific version >> checks so we can do the right thing internally. >> >> This is ticket 155 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > I think that in the explicit path construction you do vic of line 115, > you want the kerberos subpath libraries to come before /usr/bin, > otherwise it will find the non-kerberized versions of the function. Ok, it wouldn't affect the commands we're currently using but flipping the order will certainly help. I need to add /bin to it as well. > I realize that testing on the Major/Minor is functional, but wouldn't it > make more sense to test for the existanec of the newer call, use that if > it was avaiable, as opposed to gating on version number? Seems like it > would be less prone to breakage. I did that originally and it was extremely unreadable. Since xmlrpclib ships with core python testing the version seems adequate. rob From ayoung at redhat.com Mon Aug 23 14:41:44 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 23 Aug 2010 10:41:44 -0400 Subject: [Freeipa-devel] BA-BBQ In-Reply-To: <4C7260A4.40708@redhat.com> References: <4C71D92B.40509@redhat.com> <4C7260A4.40708@redhat.com> Message-ID: <4C7288A8.9010208@redhat.com> On 08/23/2010 07:51 AM, Pavel Zuna wrote: > On 08/23/2010 04:12 AM, Adam Young wrote: >> Pavel, >> >> >> Thoughts of jquery.ba-bbq have been marinating in the back of my brain. >> I know that the Back button doesn't work so well with hjashparams, and >> that BBQ purports to fix this, but I had some sort of mental shift I had >> to make. I think I have it now. >> >> BBQ, and in fact the whole AJAX approach works off of client side code, >> which means the whole hash params approach. What I didn't get was that >> the best approach to dealing with this was to drive the site off of the >> event that happens when the url hash changes. We need to do this. >> >> Bascially, navigation.js registers: >> >> $(window).bind( 'hashchange', function(e) { >> ... >> } >> >> This function gets called each time the URL hash changes, which happens >> on either a tab click or on a back button (lets start with those two, >> there will be more) >> >> >> So bascially, this function is our dispatach. Instead of having to >> register the onclick functions for each of the tabs, we know that they >> will all end up in this function, and then we let it parse the params >> for us. >> >> BBQ has the concept of a stack, where we can push and pop state. Thyis >> might be useful for pushing a query, going to the details page, and then >> popping the query afterwards. I'm still mulling this over. >> >> >> Note, we will want to replace the custom hash param working we are doing >> with JQuery.deparam and JQuery.param calls, as they are much more >> mature, and it is less code we have to debug. > Sure, from what I've read in jQuery docs, it looks more powerful than > what we currently have. > >> The thing I have to figure out now is what this will do to navigation on >> the details, add and groups pages. > I don't think it will be a problem. Functional links (such as Reset, > Update, Add, Remove) are only used to run javascript functions - the > URL, query string or hash doesn't change. Most of these action are > also "one way" only. We don't want the user to be able to go Back > after he updated an entry. (Going back in this case should probably > bring him back to the search page). > > Pavel I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to move to that as well? From rcritten at redhat.com Mon Aug 23 14:45:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Aug 2010 10:45:38 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-freeipa-0013 Revert of the host details patch In-Reply-To: <4C6E9D01.80301@redhat.com> References: <4C6E9D01.80301@redhat.com> Message-ID: <4C728992.3090703@redhat.com> Adam Young wrote: > That patch got pushed by accident. Reverting. > ACK From rcritten at redhat.com Mon Aug 23 14:49:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Aug 2010 10:49:08 -0400 Subject: [Freeipa-devel] Fwd: [Freeipa-users] [PATCH] 510 enable compat plugin by default In-Reply-To: <4C69DEA1.7080607@redhat.com> References: <4C6302EA.4040704@redhat.com> <4C69DEA1.7080607@redhat.com> Message-ID: <4C728A64.5090602@redhat.com> Adam Young wrote: > On 08/11/2010 04:07 PM, Rob Crittenden wrote: >> originall sent to wrong list >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK > Pushed to master From pzuna at redhat.com Mon Aug 23 15:01:06 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 23 Aug 2010 17:01:06 +0200 Subject: [Freeipa-devel] BA-BBQ In-Reply-To: <4C7288A8.9010208@redhat.com> References: <4C71D92B.40509@redhat.com> <4C7260A4.40708@redhat.com> <4C7288A8.9010208@redhat.com> Message-ID: <4C728D32.6000909@redhat.com> On 2010-08-23 16:41, Adam Young wrote: > On 08/23/2010 07:51 AM, Pavel Zuna wrote: >> On 08/23/2010 04:12 AM, Adam Young wrote: >>> Pavel, >>> >>> >>> Thoughts of jquery.ba-bbq have been marinating in the back of my brain. >>> I know that the Back button doesn't work so well with hjashparams, and >>> that BBQ purports to fix this, but I had some sort of mental shift I had >>> to make. I think I have it now. >>> >>> BBQ, and in fact the whole AJAX approach works off of client side code, >>> which means the whole hash params approach. What I didn't get was that >>> the best approach to dealing with this was to drive the site off of the >>> event that happens when the url hash changes. We need to do this. >>> >>> Bascially, navigation.js registers: >>> >>> $(window).bind( 'hashchange', function(e) { >>> ... >>> } >>> >>> This function gets called each time the URL hash changes, which happens >>> on either a tab click or on a back button (lets start with those two, >>> there will be more) >>> >>> >>> So bascially, this function is our dispatach. Instead of having to >>> register the onclick functions for each of the tabs, we know that they >>> will all end up in this function, and then we let it parse the params >>> for us. >>> >>> BBQ has the concept of a stack, where we can push and pop state. Thyis >>> might be useful for pushing a query, going to the details page, and then >>> popping the query afterwards. I'm still mulling this over. >>> >>> >>> Note, we will want to replace the custom hash param working we are doing >>> with JQuery.deparam and JQuery.param calls, as they are much more >>> mature, and it is less code we have to debug. >> Sure, from what I've read in jQuery docs, it looks more powerful than >> what we currently have. >> >>> The thing I have to figure out now is what this will do to navigation on >>> the details, add and groups pages. >> I don't think it will be a problem. Functional links (such as Reset, >> Update, Add, Remove) are only used to run javascript functions - the >> URL, query string or hash doesn't change. Most of these action are >> also "one way" only. We don't want the user to be able to go Back >> after he updated an entry. (Going back in this case should probably >> bring him back to the search page). >> >> Pavel > > I notice he uses JQuery.ui Tabs for his demo. I wonder if we want to > move to that as well? > http://benalman.com/code/projects/jquery-bbq/examples/fragment-jquery-ui-tabs/ You mean this example, right? It looks good and if it can simplify our code, why not. I'll take a look at the API a maybe play around with it a little. Pavel From rcritten at redhat.com Mon Aug 23 15:06:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Aug 2010 11:06:39 -0400 Subject: [Freeipa-devel] [PATCH] Add webUI application to lite-server. In-Reply-To: <4C6DB536.8080109@redhat.com> References: <4C6DB536.8080109@redhat.com> Message-ID: <4C728E7F.9010106@redhat.com> Pavel Z?na wrote: > The web UI should now be available through the lite-server. For security > purposes only files under install/static ending with extensions listed > in lite-server:WebUIApp.EXTENSION_TO_MIME_MAP dict are served. > > Pavel nack. This does seem to somewhat serve the UI through the lite server but it isn't quite functional. It should probably have a redirect from / to /ipa/ui/index.html, and perhaps look for index.xhtml if given a directory URI. In any case, the best I was able to get was the title bar to display along with the word Edit. rob From pzuna at redhat.com Mon Aug 23 15:08:16 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 23 Aug 2010 17:08:16 +0200 Subject: [Freeipa-devel] [PATCH] Fix script tags in index.xhtml. End tag is required. In-Reply-To: <4C6DCBC6.3020909@redhat.com> References: <4C6DB4A1.3090207@redhat.com> <4C6DB57B.3020206@redhat.com> <4C6DCBC6.3020909@redhat.com> Message-ID: <4C728EE0.7050406@redhat.com> On 2010-08-20 02:26, Adam Young wrote: > On 08/19/2010 06:51 PM, Pavel Z?na wrote: >> On 2010-08-20 00:48, Pavel Z?na wrote: >>> The paste server had some issues with it and end tags are required by >>> the standard anyway. >>> >>> Pavel >> >> I forgot to mention that this applies after Adam's 0009 patch (updated >> Hash Params). >> >> Pavel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Is this only a problem on the javascript tags, or are we going to see a > problem on all of the xhtml that doesn't use closing tags? > Either way, it should be filed as an upstream bug. > I think it's just the script tags. From wiki (http://en.wikipedia.org/wiki/XHTML): The format , rather than the more concise