Re: [Freeipa-devel] Structured DNS record API proposal
On Thu, Sep 22, 2011 at 08:25:01AM +0200, Jan Cholasta wrote: > On 21.9.2011 23:55, Dmitri Pal wrote: > >On 09/21/2011 10:27 AM, Adam Young wrote: > >>On 09/20/2011 11:11 AM, Martin Kosek wrote: > >>>On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote: > This discussion got me thinking, always a dangerous proposal: > > We are currently exposing record add with the lie that when you add a > record, it has a type. THe reality is that a record is just this big > collection of multi value attributes, and each of those is the "type" > of the record. > >>>The way I see it is that we have different types of Resource Records > >>>with a (domain) name that can be shared. > >>> > > If all of the 'records' have the same idnsname, then they really fall > under the same Record object in LDAP. > >>>Yes. > >>> > What if we focuses on the attribtutes themselves, and add the type info > there. > >>>I thought we do this already. > >>> > > Pie in the sky proposal. Treat it as a starting point: > > From the webui perspective > dnsrecord-add allows the case where it just has the the idnsname with > no "records" > > dnsrecordattr-mod takes record type specific values. > > To add a location entry: > > ipa dnsrecordattr-mod --append location --lat-deg=INT --lat-min=INT > --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT > --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT > --v-precision=FLOAT > > > And to remove it > > ipa dnsrecordattr-mod --remove location --lat-deg=INT --lat-min=INT > --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT > --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT > --v-precision=FLOAT > >>>So if user would want to remove a LOC record, he would have to pass all > >>>these attributes to refer which attribute value to remove? > >>I think that is the case anyway. Since a DNS record is really just an > >>multivalue attribute, you would now have to do a dns-record-mod > >>with the list of all LOC records that you don't want to delete. I > >>used this as an example because it is the most complex case. > >> > >>Just thinking it through...I'm not certain I like the "one command per > >>record type" as it changes a lot of other assumptions. DNS is a > >>wierd beast already. > >> > >>I've spent a lot of time on the DNS ui, and it is pretty tricky to > >>get right. I'm trying to balance the PI against efficient usage. > >> > >>What we really need for the fields is a way to specify the format for > >>a given field, much like the format strings used for group names. For > >>example, the LOC record is really > >> > >> LOC d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] > >>{"E"|"W"} > >> alt["m"] [siz["m"] [hp["m"] [vp["m" > >> > >> > >>And all the WebUI needs is a way to specify that format to validate. > >> > > > >Can we use augeas for this? > >Augeas lenses use this kind of the validation and there is python > >binding so may be we should use augeas as an inspiration or ask for an > >augeas Javascript solution? > > We can't. Augeas knows how to manipulate config files and only that, > there is no API for anything else. > Some time ago I wrote a patch to extend Augeas to operate on arbitrary strings. I never had time to push it upstream, but I think I still have is somewhere. Not sure if this approach would help us anyway, we would still have to wait until this feature made it to RHEL and solve the JS bindings as well ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 275 Use editable combobox for service type.
On 09/16/2011 07:16 PM, Endi Sukma Dewata wrote: The service type field in the service adder dialog has been modified to use an editable combobox. Ticket #1633. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 44 Fix parameter validation
On 21.9.2011 21:31, Rob Crittenden wrote: Jan Cholasta wrote: On 25.8.2011 18:21, Jan Cholasta wrote: What this patch does: * Make sure arguments are validated and default values are filled in before calling a command. * Add new parameter flag "validate_search" to force validation on search arguments. * Fix validation of IP network parameters in the DNS plugin. https://fedorahosted.org/freeipa/ticket/1627 Honza Redone the patch and split it to 3 parts: I haven't tested these yet, these comments are just from reading the patches. * [PATCH 46] Add IP address and IP network parameter types Adds two new parameter types, IPAddress and IPNetwork (which replaces the validate_search flag, as it was just a hack). A param type looks like the way to go. There are other IPaddress parameters, such in host, should this be expanded to cover that? All of them are covered in the patch already. Not sure about replacing List with Str types. It may make no difference since I'm not sure how a List could be passed for some of these. Can you make sure there is no possibility that on the wire someone couldn't pass these as a list and actually do something reasonable in the server? I suspect they can't but this is a rather major datatype change. I think my patch breaks dnsrecord-add example.com test --a-rec 192.0.2.122,203.0.113.45 and the like. This TODO item should be implemented to fix that: * All "comma-separated list of..." parameters should really be changed to multivalue and have a flag that tells the CLI whether a multivalue should be parsed as comma-separated. The List type currently satisfy this, but it would be nice to have a comma-separated multivalue of any type. * [PATCH 44] Fix parameter validation Changes Command.get_default so that default_from parameters are validated before they are used to create the default value. Just a heads-up but this will conflict big time with my password patch. Yes, I've noticed that. It throws away the ordering that the parameters had. This could impact the order in which interactive prompting happens. Did you verify that it still works sanely? What kind of sanity do you have in mind? The ordering isn't much different, just extra care is taken to order parameters with default_from right. I guess I can store the ordering somewhere else and leave the params namespace ordering in its original form. * [PATCH 47] Remove create_default Removes create_default, as it does exactly the same thing as default_from, but without the advantage of knowing what parameters are used to create the default value. All uses of create_default are replaced by default_from with no arguments, because that's all create_default is currently used for in IPA. I'm not sure why you want to remove this, is it causing problems with validation? It could, if it was actually used to dynamically create default value from existing parameter values (there is no such use of it in IPA ATM), because we don't know in advance which parameters it might use and thus don't know how to order the parameter properly. I'm not sure why we should keep it in, I can't think of any use of it that can't be done with default_from. Isn't getting rid of redundant stuff OK? In general the patch comments need more details. This patch e-mail has more information on what each patch does than the patches themselves, including lacking ticket info. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 271 Modified dialog to use sections.
On 09/21/2011 10:10 PM, Endi Sukma Dewata wrote: > On 9/21/2011 6:50 AM, Petr Vobornik wrote: > > Fixed. The dialog fields don't need undo, so the text() needs to be > overridden to disable undo. This can be improved again later. The override isn't necessary because it wasn't there before and all (at least I hope) fields in add dialogs specify undo: false. This feature can save some time though. Problem of current implementation is that it overrides only the default created section, not the sections specified in spec object. But as you wrote - this can be improved later. > >> 4) host.js:208,217: we should avoid using purely visual inline css >> styles. They should be replaced by class (if cannot be achieved by other >> selector) and styled in css file. This doesn't concern functional styles >> (animations, resizing, hiding, showing). > > Fixed. Yes, we should have a ticket to remove all inline CSS styles. Are you sure the 'name' attribute is the right way to go? Wouldn't be 'class' or 'id' (in this case) better? For table data 'name' attribute isn't even in HTML spec http://dev.w3.org/html5/spec/Overview.html#the-td-element. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 125 Remove checks for ds-replication plugin
On Wed, 2011-09-21 at 10:29 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > The replication plugin is no longer shipped as a separate package. > > Remove the code checking its existence. > > > > https://fedorahosted.org/freeipa/ticket/1815 > > ACK > Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 44 Fix parameter validation
On Wed, 2011-09-21 at 15:31 -0400, Rob Crittenden wrote: > Jan Cholasta wrote: > > On 25.8.2011 18:21, Jan Cholasta wrote: > >> What this patch does: > >> > >> * Make sure arguments are validated and default values are filled in > >> before calling a command. > >> * Add new parameter flag "validate_search" to force validation on search > >> arguments. > >> * Fix validation of IP network parameters in the DNS plugin. > >> > >> https://fedorahosted.org/freeipa/ticket/1627 > >> > >> Honza > >> > > > > Redone the patch and split it to 3 parts: > > I haven't tested these yet, these comments are just from reading the > patches. > > > > > * [PATCH 46] Add IP address and IP network parameter types > > Adds two new parameter types, IPAddress and IPNetwork (which replaces > > the validate_search flag, as it was just a hack). > > A param type looks like the way to go. There are other IPaddress > parameters, such in host, should this be expanded to cover that? > > Not sure about replacing List with Str types. It may make no difference > since I'm not sure how a List could be passed for some of these. Can you > make sure there is no possibility that on the wire someone couldn't pass > these as a list and actually do something reasonable in the server? I > suspect they can't but this is a rather major datatype change. > > > > > * [PATCH 44] Fix parameter validation > > Changes Command.get_default so that default_from parameters are > > validated before they are used to create the default value. > > Just a heads-up but this will conflict big time with my password patch. > > It throws away the ordering that the parameters had. This could impact > the order in which interactive prompting happens. Did you verify that it > still works sanely? > > > * [PATCH 47] Remove create_default > > Removes create_default, as it does exactly the same thing as > > default_from, but without the advantage of knowing what parameters are > > used to create the default value. All uses of create_default are > > replaced by default_from with no arguments, because that's all > > create_default is currently used for in IPA. > > I'm not sure why you want to remove this, is it causing problems with > validation? > > In general the patch comments need more details. This patch e-mail has > more information on what each patch does than the patches themselves, > including lacking ticket info. > > rob > Hm, by the way I am not very excited about adopting this sort of changes to framework that close to the 6.2 rebase. Are we sure enough that this won't cause any collateral damage? If possible, I would prefer to integrate it to 3.0 branch so that we have enough time to validate it and fix bugs. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 276 Fixed problem enabling/disabling DNS zone.
On 09/17/2011 12:18 AM, Endi Sukma Dewata wrote: The details facet for DNS zone has been modified to use dnszone- enable/disable for idnszoneactive and dnszone-mod for other fields. Ticket #1813 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Btw it doesn't matter (besides performance) if you move 'if (!field.is_dirty()) continue;' in sudo and hbac facet couple lines lower because to execute member_operation you have to fulfil two conditions, which won't be never reached - name of the association fields changed so 'if (categories[field.name])' will be never true. Even if it would be the next condition ('values[0] == 'all) won't be either because of weird implementation of table_widget.save method. Anyway if it would be functional it would be IMO bad - checking line doesn't imply that user wants it to be deleted right now. Even if marking the line could be used only for deletion. This code should be cleaned in the future (erased or fixed). -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 44 Fix parameter validation
On 22.9.2011 13:27, Martin Kosek wrote: On Wed, 2011-09-21 at 15:31 -0400, Rob Crittenden wrote: Jan Cholasta wrote: On 25.8.2011 18:21, Jan Cholasta wrote: What this patch does: * Make sure arguments are validated and default values are filled in before calling a command. * Add new parameter flag "validate_search" to force validation on search arguments. * Fix validation of IP network parameters in the DNS plugin. https://fedorahosted.org/freeipa/ticket/1627 Honza Redone the patch and split it to 3 parts: I haven't tested these yet, these comments are just from reading the patches. * [PATCH 46] Add IP address and IP network parameter types Adds two new parameter types, IPAddress and IPNetwork (which replaces the validate_search flag, as it was just a hack). A param type looks like the way to go. There are other IPaddress parameters, such in host, should this be expanded to cover that? Not sure about replacing List with Str types. It may make no difference since I'm not sure how a List could be passed for some of these. Can you make sure there is no possibility that on the wire someone couldn't pass these as a list and actually do something reasonable in the server? I suspect they can't but this is a rather major datatype change. * [PATCH 44] Fix parameter validation Changes Command.get_default so that default_from parameters are validated before they are used to create the default value. Just a heads-up but this will conflict big time with my password patch. It throws away the ordering that the parameters had. This could impact the order in which interactive prompting happens. Did you verify that it still works sanely? * [PATCH 47] Remove create_default Removes create_default, as it does exactly the same thing as default_from, but without the advantage of knowing what parameters are used to create the default value. All uses of create_default are replaced by default_from with no arguments, because that's all create_default is currently used for in IPA. I'm not sure why you want to remove this, is it causing problems with validation? In general the patch comments need more details. This patch e-mail has more information on what each patch does than the patches themselves, including lacking ticket info. rob Hm, by the way I am not very excited about adopting this sort of changes to framework that close to the 6.2 rebase. Are we sure enough that this won't cause any collateral damage? If possible, I would prefer to integrate it to 3.0 branch so that we have enough time to validate it and fix bugs. Martin I concur. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On Wed, 2011-09-21 at 11:22 +0200, Martin Kosek wrote: > On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote: > > On 9/20/2011 6:15 AM, Martin Kosek wrote: > > >>> ACK. Proposal looks like it will work fairly easily with the UI. > > >>> We'll have to make some chagnes due to the Add doing something > > >>> different based on the type, but that is the case anyway. > > >> > > >> Yes, I was thinking how can we integrate this new API to WebUI. AFAIK > > >> you use dnsrecord-add $ZONE $REC --a-rec=... --mx-rec=... for adding a > > >> new DNS record and dnsrecord-mod $ZONE $REC --mx-rec=... when for > > >> example the mx record is being modified. All MX values (even the > > >> unmodified ones) are passed to dnsrecord-mod. > > >> > > >> 1) I was wondering how the new dnsrecord--add commands can be > > >> used. I suppose WebUI will know a list of DNS record types with these > > >> new structured commands and offer the user new window to add a record > > >> for these types instead of typing them directly to the text box as it is > > >> now. > > > > When adding a DNS record the user will specify the name and the type, > > then the UI will show a set of fields based on the selected record type. > > > > So instead of a generic 'data' field like below (click Add): > > > > http://edewata.fedorapeople.org/freeipa/install/ui/index.html#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=ayoung.boston.devel.redhat.com > > > > it will be similar to Permissions (click Add): > > > > http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permission&ipaserver=rolebased&navigation=ipaserver > > > > The UI will use the type to pick the correct dnsrecord--add > > command and each parameter in that command will have a corresponding > > field to enter the value. > > Yes, I think this will work fine. Would it make sense to create > dnsrecord--add commands also for non-structured DNS records? I > mean for example for A, , PTR, CNAME, ... record, which have just > one simple value or let plain old dnsrecord-add --a-rec=... handle it? > > > > > >> 2) But my main concern here is how the modification of current DNS > > >> records should work. Say, we have 2 MX records for example.com. How can > > >> we modify one of it in a new structured interface? > > >> > > >> We would have to implement dnsrecord-mx-show method so that you can fill > > >> all the text areas (preference, mailserver). Question is how to refer > > >> the value we want to show since DNS records are multivalued. We could > > >> pass --dnsrecord="..." with DNS record value, e.g. "0 mx.example.com." > > >> and then use the same value for dnsrecord-mx-mod. The whole command > > >> sequence would look this way: > > >> > > >> dnsrecord-find example.com -- get all DNS records for example.com > > >> dnsrecord-show example.com @-- show DNS records directly in the zone > > >> NS: "ns.example.com" > > >> MX: "0 mx1.example.com." > > >> MX: "1 mx2.example.com."<< user wants to modify this one -> new window > > > > I think for each record value the primary keys are the zone name, record > > name, and the value itself. To simplify operations, we should use the > > value as a single string. For CLI, users can copy & paste the value more > > easily. > > Agreed. As Adam Tkac suggested, we can simplify this with interactive > prompt so that user doesn't have to copy&paste, but just choose a record > to -show/-mod. > > > > > For UI it depends whether (1) we're going to keep the current edit page > > where all records with the same name are considered a single entry, or > > whether (2) we're going to edit each record value in a separate page. > > See ticket #1478. > > > > If we stay with (1), the link to the edit page consists of zone name and > > record name only. But if we pick (2) the link consists of zone name, > > record name, value, and type (which can be obtained from -find output). > > This is more of a UXD decision, server API will remain intact. I just > see 2 issues here: > > 1) If you let user edit multiple structured DNS records, you would have > to call dnsrecord--show multiple times so that you can populate > all the fields. This can slow down things. > > 2) Some DNS records may be pretty large. MX record data is small, but > for example CERT records have an entire certificate stored in it. > Wouldn't there be a problem if we place the large DNS record in URL? > > > > > >> dnsrecord-mx-show example.com --dnsrecord="1 mx1.example.com." > > >> PREFERENCE: 1<< user modifies this to 0 > > >> MAILSERVER: mx2.example.com. > > > > For consistency, the record value should be specified as an argument > > instead of an option (like in automount). So it will be like this: > > > > dnsrecord-mx-show "example.com" "@" "1 mx1.example.com." > > PREFERENCE: 1 > > MAILSERVER: mx2.example.com > > This can be done. > > > > > If we stay with (1) the UI will have to call the dnsrecord--show
Re: [Freeipa-devel] Structured DNS record API proposal - summary
Martin Kosek wrote: On Wed, 2011-09-21 at 11:22 +0200, Martin Kosek wrote: On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote: On 9/20/2011 6:15 AM, Martin Kosek wrote: ACK. Proposal looks like it will work fairly easily with the UI. We'll have to make some chagnes due to the Add doing something different based on the type, but that is the case anyway. Yes, I was thinking how can we integrate this new API to WebUI. AFAIK you use dnsrecord-add $ZONE $REC --a-rec=... --mx-rec=... for adding a new DNS record and dnsrecord-mod $ZONE $REC --mx-rec=... when for example the mx record is being modified. All MX values (even the unmodified ones) are passed to dnsrecord-mod. 1) I was wondering how the new dnsrecord--add commands can be used. I suppose WebUI will know a list of DNS record types with these new structured commands and offer the user new window to add a record for these types instead of typing them directly to the text box as it is now. When adding a DNS record the user will specify the name and the type, then the UI will show a set of fields based on the selected record type. So instead of a generic 'data' field like below (click Add): http://edewata.fedorapeople.org/freeipa/install/ui/index.html#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=ayoung.boston.devel.redhat.com it will be similar to Permissions (click Add): http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permission&ipaserver=rolebased&navigation=ipaserver The UI will use the type to pick the correct dnsrecord--add command and each parameter in that command will have a corresponding field to enter the value. Yes, I think this will work fine. Would it make sense to create dnsrecord--add commands also for non-structured DNS records? I mean for example for A, , PTR, CNAME, ... record, which have just one simple value or let plain old dnsrecord-add --a-rec=... handle it? 2) But my main concern here is how the modification of current DNS records should work. Say, we have 2 MX records for example.com. How can we modify one of it in a new structured interface? We would have to implement dnsrecord-mx-show method so that you can fill all the text areas (preference, mailserver). Question is how to refer the value we want to show since DNS records are multivalued. We could pass --dnsrecord="..." with DNS record value, e.g. "0 mx.example.com." and then use the same value for dnsrecord-mx-mod. The whole command sequence would look this way: dnsrecord-find example.com -- get all DNS records for example.com dnsrecord-show example.com @-- show DNS records directly in the zone NS: "ns.example.com" MX: "0 mx1.example.com." MX: "1 mx2.example.com."<< user wants to modify this one -> new window I think for each record value the primary keys are the zone name, record name, and the value itself. To simplify operations, we should use the value as a single string. For CLI, users can copy& paste the value more easily. Agreed. As Adam Tkac suggested, we can simplify this with interactive prompt so that user doesn't have to copy&paste, but just choose a record to -show/-mod. For UI it depends whether (1) we're going to keep the current edit page where all records with the same name are considered a single entry, or whether (2) we're going to edit each record value in a separate page. See ticket #1478. If we stay with (1), the link to the edit page consists of zone name and record name only. But if we pick (2) the link consists of zone name, record name, value, and type (which can be obtained from -find output). This is more of a UXD decision, server API will remain intact. I just see 2 issues here: 1) If you let user edit multiple structured DNS records, you would have to call dnsrecord--show multiple times so that you can populate all the fields. This can slow down things. 2) Some DNS records may be pretty large. MX record data is small, but for example CERT records have an entire certificate stored in it. Wouldn't there be a problem if we place the large DNS record in URL? dnsrecord-mx-show example.com --dnsrecord="1 mx1.example.com." PREFERENCE: 1 << user modifies this to 0 MAILSERVER: mx2.example.com. For consistency, the record value should be specified as an argument instead of an option (like in automount). So it will be like this: dnsrecord-mx-show "example.com" "@" "1 mx1.example.com." PREFERENCE: 1 MAILSERVER: mx2.example.com This can be done. If we stay with (1) the UI will have to call the dnsrecord--show for each value to get the value of each fields. The UI will need to implement a new widget (or section) that can handle multiple fields which will be duplicated for each value. Ah, yes - as I wrote above. This would also take more time to process. The edit page for (2) is much simpler since it only needs to handle a single type at a time. The output of the -show command will be used to populate each field. dnsrecord-
Re: [Freeipa-devel] FreeIPA and per-machine views
On 09/21/2011 10:07 PM, Stephen Gallagher wrote: I've ben working on the multiple search base feature in SSSD and I've had some thoughts that might be relevant to the FreeIPA v3 core effort. The idea behind multiple search bases is fairly simple; instead of simply checking one subtree for user or group information, you check several in series, stopping at the first match. Seems like a good idea to me. I presume it would not be a list of search bases to be applied to just one server but rather a list of tuples. As an implementation and use issue I would think you would want some mechanism by which the was returned with the result so that some business logic could be applied based on which base produced the result. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 123 Fix /usr/bin/ipa dupled server list
Martin Kosek wrote: Fix get_url_list() so that the configured master server is there just once. This fix lets /usr/bin/ipa try connecting to all IPA masters just once and not print confusing server list with dupled master. https://fedorahosted.org/freeipa/ticket/1817 ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 123 Fix /usr/bin/ipa dupled server list
On Thu, 2011-09-22 at 09:05 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > Fix get_url_list() so that the configured master server is there > > just once. This fix lets /usr/bin/ipa try connecting to all IPA > > masters just once and not print confusing server list with > > dupled master. > > > > https://fedorahosted.org/freeipa/ticket/1817 > > ACK Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] #1812 Fixes segfault in ipa-pwd-extop plugin
Simo Sorce wrote: While investigating ticket 1808 Rob found this issue. Patch attached. Fixes: https://fedorahosted.org/freeipa/ticket/1812 Tested and solves the problem here. Simo. ack, pushed to master and ipa-2-1 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA and per-machine views
On Thu, 2011-09-22 at 09:04 -0400, John Dennis wrote: > On 09/21/2011 10:07 PM, Stephen Gallagher wrote: > > I've ben working on the multiple search base feature in SSSD and I've > > had some thoughts that might be relevant to the FreeIPA v3 core > > effort. The idea behind multiple search bases is fairly simple; > > instead of simply checking one subtree for user or group information, > > you check several in series, stopping at the first match. > > Seems like a good idea to me. > > I presume it would not be a list of search bases to be applied to just > one server but rather a list of tuples. > > As an implementation and use issue I would think you would want some > mechanism by which the was returned with the result so > that some business logic could be applied based on which base produced > the result. I wanted to do this for a while, esp to make migrations simpler when you are trying to aggregate multiple old domains (like NIS domains) into a single directory. Other products do similar things with AD already. The idea would be not only to have additional users/groups but also to be able to override only single attributes of a user/group like for example only the name, only the uid/gid, only the home directory etc... But ti requires quite some effort to do it right and in a way that will not make things go easily out of control, so it has always been deferred. I think this sort of functionality could also be easily implemented by a third, interested, party under supervision of the IPA architecture team. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] include for uintptr_t
On Wed, 2011-09-21 at 10:28 -0400, Rob Crittenden wrote: > Marko Myllynen wrote: > > Hi, > > > >>> stdint.h must be included for uintptr_t at least on Ubuntu Oneiric, > >>> without it ipa-client compilation fails. > >> > >> There is an ipa-client make target that should make things somewhat > >> easier as it doesn't need to build the entire tree. > > > > sure, but gcc bails out with an error when compiling ipa-join.c without > > this patch. And while at it I added the fix also to > > daemons/ipa-slapi-plugins/common/util.h not just for > > ipa-client/ipa-client-common.h. > > > > Cheers, > > > > Ok, opened https://fedorahosted.org/freeipa/ticket/1831 Ack and pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 876 normalize user principal
On Wed, 2011-09-21 at 10:47 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2011-09-16 at 10:16 -0400, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Normalize and validate user principals in user and passwd plugins. The > >>> uid in the principal should be lower-case. > >>> > >>> rob > >> > >> With updated API.txt > >> > >> rob > > > > This works fine. I would just suggest improving the way how we handle > > realm case mismatch: > > > > # ipa user-add --first=Foo --last=Bar > > --principal=fb...@idm.lab.bos.redhat.com FBar3 > > ipa: ERROR: The realm for the principal does not match the realm for this > > IPA server > > [root@vm-120 ~]# ipa user-add --first=Foo --last=Bar > > --principal=fb...@idm.lab.bos.redhat.com FBar3 > > -- > > Added user "fbar3" > > -- > >User login: fbar3 > >First name: Foo > >Last name: Bar > >Full name: Foo Bar > >Display name: Foo Bar > >Initials: FB > >Home directory: /home/fbar3 > >GECOS field: Foo Bar > >Login shell: /bin/sh > >Kerberos principal: fb...@idm.lab.bos.redhat.com > >UID: 6365 > >GID: 6361 > >Keytab: False > >Password: False > > > > I think we should force it to uppercase in split_principal() as we do in > > service.py. > > > > Martin > > > > Done since we require upper-case realms in the installer. > > rob ACK. Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] #1814 Enforce old password requirement in ldappasswd operations
Simo Sorce wrote: Although we were properly checking that the user successfully authenticated (either through a password bind or a GSSAPI bind) we were not enforcing the requirement to provide us with the old password, and this is better security hygiene. Fixes: https://fedorahosted.org/freeipa/ticket/1814 Tested and works for me. Properly requires old password for self password changes. Do not require it for admin password changes. Simo. ack, pushed to master and ipa-2-1 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 881 don't log OTP in client install log
Obfuscate the one-time password in the client installer log. rob >From e454f840460b6703d8327a235844adcbc310f48d Mon Sep 17 00:00:00 2001 From: Rob Crittenden Date: Thu, 22 Sep 2011 11:52:58 -0400 Subject: [PATCH] Don't log one-time password in logs when configuring client. https://fedorahosted.org/freeipa/ticket/1801 --- ipa-client/ipa-install/ipa-client-install |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 44c2f5fbc40c9f3a6d5f4378d91e048b63bf0e7a..413e2d2909aed4990905e70579d9a86c07193fe9 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -23,17 +23,15 @@ try: import sys import os -import stat import time import socket import logging import tempfile import getpass -import re from ipaclient import ipadiscovery import ipaclient.ipachangeconf import ipaclient.ntpconf -from ipapython.ipautil import run, user_input, CalledProcessError, file_exists, install_file +from ipapython.ipautil import run, user_input, CalledProcessError, file_exists import ipapython.services as ipaservices from ipapython import ipautil from ipapython import dnsclient @@ -888,6 +886,7 @@ def install(options, env, fstore, statestore): return CLIENT_INSTALL_ERROR if not options.on_master: +nolog = tuple() # First test out the kerberos configuration try: (krb_fd, krb_name) = tempfile.mkstemp() @@ -929,6 +928,7 @@ def install(options, env, fstore, statestore): print stdout return CLIENT_INSTALL_ERROR elif options.password: +nolog = (options.password,) join_args.append("-w") join_args.append(options.password) elif options.prompt_password: @@ -940,7 +940,7 @@ def install(options, env, fstore, statestore): join_args.append(password) # Now join the domain -(stdout, stderr, returncode) = run(join_args, raiseonerr=False, env=env) +(stdout, stderr, returncode) = run(join_args, raiseonerr=False, env=env, nolog=nolog) if returncode != 0: print >>sys.stderr, "Joining realm failed: %s" % stderr, -- 1.7.6 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 279 Fixed problem enrolling member with the same name.
On 09/20/2011 02:19 AM, Endi Sukma Dewata wrote: The IPA.association_adder_dialog has been modified to use an exclusion list to hide entries that are already enrolled. The IPA.adder_dialog has been modified to store the columns directly in the available & selected tables. Ticket #1797 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Don't remove /tmp when removing temp cert dir
Hi, If /tmp happens to be empty os.removedirs() happily removes it... Seen on Ubuntu Oneiric. Cheers, -- Marko Myllynen >From 296dd30279503c2f6891cf5916a1a6e56c9512d4 Mon Sep 17 00:00:00 2001 From: Marko Myllynen Date: Thu, 22 Sep 2011 19:41:50 +0300 Subject: [PATCH] Don't remove /tmp when removing temp cert dir If /tmp happens to be empty os.removedirs() happily removes it... --- ipa-client/ipaclient/ipadiscovery.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py index ecd8275..9d909fd 100644 --- a/ipa-client/ipaclient/ipadiscovery.py +++ b/ipa-client/ipaclient/ipadiscovery.py @@ -280,7 +280,7 @@ class IPADiscovery: finally: os.remove("%s/ca.crt" % temp_ca_dir) -os.removedirs(temp_ca_dir) +os.rmdir(temp_ca_dir) def ipadnssearchldap(self, tdomain): -- 1.7.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Don't remove /tmp when removing temp cert dir
Marko Myllynen wrote: Hi, If /tmp happens to be empty os.removedirs() happily removes it... Seen on Ubuntu Oneiric. Cheers, https://fedorahosted.org/freeipa/ticket/1843 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 279 Fixed problem enrolling member with the same name.
On 9/22/2011 11:14 AM, Petr Vobornik wrote: On 09/20/2011 02:19 AM, Endi Sukma Dewata wrote: The IPA.association_adder_dialog has been modified to use an exclusion list to hide entries that are already enrolled. The IPA.adder_dialog has been modified to store the columns directly in the available & selected tables. Ticket #1797 ACK Pushed to master and ipa-2-1. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 276 Fixed problem enabling/disabling DNS zone.
On 9/22/2011 6:59 AM, Petr Vobornik wrote: On 09/17/2011 12:18 AM, Endi Sukma Dewata wrote: The details facet for DNS zone has been modified to use dnszone- enable/disable for idnszoneactive and dnszone-mod for other fields. Ticket #1813 ACK Pushed to master and ipa-2-1. Btw it doesn't matter (besides performance) if you move 'if (!field.is_dirty()) continue;' in sudo and hbac facet couple lines lower because to execute member_operation you have to fulfil two conditions, which won't be never reached - name of the association fields changed so 'if (categories[field.name])' will be never true. Even if it would be the next condition ('values[0] == 'all) won't be either because of weird implementation of table_widget.save method. Anyway if it would be functional it would be IMO bad - checking line doesn't imply that user wants it to be deleted right now. Even if marking the line could be used only for deletion. This code should be cleaned in the future (erased or fixed). As mentioned on IRC, this fixes a regression in the UI when changing the category. The two conditions (remove_values and has_values) are set by different fields (category and table), that's why the logic is kind of complicated. The server side will be fixed in ticket #1440. Once that's fixed we no longer need this code so it can be cleaned up. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 871 add hostname regex
Rob Crittenden wrote: Rob Crittenden wrote: Alexander Bokovoy wrote: On Tue, 13 Sep 2011, Jan Cholasta wrote: What about IDN hosts? With this change we would require them to be always in Punycode? Oh, hadn't considered that, I was just following the relevent RFCs. Is there a way we can easily support those as well? The easiest way would probably be: normalizer=lambda value: unicode(value.encode('idna')) That's one part. Another one is visualizing such content -- for both Web UI and CLI we would need to run encodings.idna.ToUnicode(). Finally, make sure whatever we pass to external applications is properly formatted as well -- all of them should be able to work with xn- form. The UI also links the DNS hostname to the host entries so I'd think the names must be matchable in some way. If DNS can only store punycode names I think the regex will be fine. I think we're going to need a bit more time to get this right. What I propose for the short term is to encode in puny code, do the validation, and reject as required. We still store in full unicode. Note that special characters may not work that will now but validating characters won't make it any worse. rob As it turns out Kerberos doesn't support this type of hostname so my original patch stands for now. We can't allow non-ascii hostnames. I'll open a 3.0 ticket to investigate further. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On 9/22/2011 7:24 AM, Martin Kosek wrote: 2) Some DNS records may be pretty large. MX record data is small, but for example CERT records have an entire certificate stored in it. Wouldn't there be a problem if we place the large DNS record in URL? This is how the DNS record list page could be redesigned: http://edewata.fedorapeople.org/images/dns-record-list-page.png It should resemble what you see in the zone file. The content can be obtained with a single dnsresource-find operation. If you click one of the data, it would open a dialog box for that particular record type. We will use the raw data as a primary key to execute the dnsresource--show command. Each attribute in this record type will be displayed in separate fields: http://edewata.fedorapeople.org/images/dns-record-edit-dialog.png When you save it will call dnsresource--mod and put the values in separate parameters. It will still use the original raw data as primary key, but we don't need to encode the new values into raw data. If we use a dialog box like this none of the attributes need to be added into the URL. It will be passed internally via variables. If we use a separate edit page (with a unique URL for each record), we might need to specify the entire raw data in the URL, but maybe we can find a workaround for CERT record. I'd prefer to use a dialog box because it can be used for both add and modify. OPEN QUESTION: should we implement these new commands also for discrete DNS records types to be consistent? I mean for example A, , CNAME, PTR, ... They would look like ipa dnsrecord--add --ip-address=IPAddress BENEFITS of this approach (command per RR type): - use can get all help for RR type by simply typing "ipa help dnsrecord-mx-add" - we would be able to implement helper methods consistently on one place, for example: dnsrecord--add --from-mac=00:1D:BA:06:37:64 If we have this for all record types the UI can use a generic code to figure out which command to use. Everything will be in this pattern: dnsrecord--add/mod/del [parameters*] OPEN QUESTION: should we implement also -find methods (dnsrecord-mx-find) so that UI can for example populate text fields for all (MX) records for one DNS name? Depending on the UI design, it might not be needed. But it won't hurt to have one in case the UI changes, for example suppose we want to have separate tabs for each record type. 4) -mod commands shall be implemented for structured RR types: API would be almost the same as with -add commands. User (WebUI) would just have to identify which record should be modified: a) by copy&passing the raw DNS value directly to the command: dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0 The Web UI will use the JSON-RPC version of this command. As discussed already, the non-interactive mode for CLI will be useful for writing scripts or other applications that will invoke the CLI/API. Being able to specify the attributes in separate parameters means that the client doesn't have to figure out how to encode the attributes into a single raw data. They will be encoded consistently by the server. b) (CLI only) by using an interactive wizard that would let user choose the modified record like this way: dnsrecord-mx-mod example.com @ --preference=0 Which record would you like to change? [1] 1 mx1.example.com. [2] 10 mx2.example.com. DNS record: The interactive mode will be useful for people who have to use text-based terminal. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA and per-machine views
On 09/21/2011 10:07 PM, Stephen Gallagher wrote: > I've ben working on the multiple search base feature in SSSD and I've had > some thoughts that might be relevant to the FreeIPA v3 core effort. The idea > behind multiple search bases is fairly simple; instead of simply checking one > subtree for user or group information, you check several in series, stopping > at the first match. > > I was looking into this to identify the primary reasons why a deployment > might use such an approach and I came up with two important use-cases. > > 1) This is a fairly simple way to extend a network you don't fully control. A > classic example might be a Computer Science department at a university. They > would want to use the campus user accounts (probably provided by the > university IT department), but also add new groups for sharing or access > control on CS department machines. This could be done with multiple search > bases by setting the first base to the CS department subtree and the second > base to a replicated university subtree. I do not think we want to deal with multiple subtrees of users in the same IPA instance. We already decided against it in the past when we flattened the tree. At least I am not convinced that this is actually needed. I am actually aware of one more use case why people do different subtrees for users. It is because they have duplication of the uid/gid. Though it is bad it is a reality that people deal with. And they deal with it by having subtrees in DS. But it will not help in our case as IPA is built with the notion of the unified uid/gid namespace. The only thing will help in both cases is different IPA domains with trust relations so I suggest we focus on that part rather than support of multiple subtrees for users. If IPA trusts still do not work for the user may be staying with a free from DS server is a better choice. > 2) The second important use-case is for dealing with third-party applications > with hard-coded groups. For a hypothetical example, let's say that a > closed-source database program requires a user to be in the group 'dbadmins' > in order to access a shell for editing the database. However, there may be > more than one such database deployed in the network, possibly among different > teams. Having multiple search bases allows different machines to have > different views of this group. That is an interesting use case. But rather than creating views I would suggest a different approach. In IPA we create a way to specify alternative location for specific override groups. For example we now have "cn=groups, cn=accounts,..." where all groups live. we can have "cn=overridegroups, cn=accounts,..." and allow creation of the special subtrees like we do with locations for maps. UI and CLI can be modified to allow to manage these areas. I do not think that would be a rocket science. On the SSSD side we can have an sssd_group_override_base parameter that would define an override base for that machine. The logic in the SSSD will be to read groups from override base first (it is expected that there will be a small subset of groups that are used by specific app like DB for example) and then the normal groups from the search base but discard the groups that already have been fetched from the override location (or something like this. I bet it is more complex and I will leave it to you to define actual implementation, but I hope it illustrates good enough what I am trying to propose). May be Jan's delete group functionality would be really handy for this use case. The alternative however is to create and support group aliases and use group aliases as names. But before we go into all of this we need to realize that contemporary versions of software most likely would allow configurable groups. Id it is an old software than SSSD might not be in the picture anyways so it should be a pure server side solution so may be we should just allow alternative subtrees for groups but then how we are going to deal with gids or it does not matter for the apps? > I think it's definitely worth discussing how we might address these same > use-cases in FreeIPA v3. My thought was that we might want to implement > custom "views" of LDAP based on the hostgroups to which a client belongs. I > can see a lot of implementation difficulties with this, however. Alternate > ideas are most welcome. > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal
On 09/22/2011 03:37 AM, Jakub Hrozek wrote: > On Thu, Sep 22, 2011 at 08:25:01AM +0200, Jan Cholasta wrote: >> On 21.9.2011 23:55, Dmitri Pal wrote: >>> On 09/21/2011 10:27 AM, Adam Young wrote: On 09/20/2011 11:11 AM, Martin Kosek wrote: > On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote: >> This discussion got me thinking, always a dangerous proposal: >> >> We are currently exposing record add with the lie that when you add a >> record, it has a type. THe reality is that a record is just this big >> collection of multi value attributes, and each of those is the "type" >> of the record. > The way I see it is that we have different types of Resource Records > with a (domain) name that can be shared. > >> If all of the 'records' have the same idnsname, then they really fall >> under the same Record object in LDAP. > Yes. > >> What if we focuses on the attribtutes themselves, and add the type info >> there. > I thought we do this already. > >> Pie in the sky proposal. Treat it as a starting point: >> >> From the webui perspective >> dnsrecord-add allows the case where it just has the the idnsname with >> no "records" >> >> dnsrecordattr-mod takes record type specific values. >> >> To add a location entry: >> >> ipa dnsrecordattr-mod --append location --lat-deg=INT --lat-min=INT >> --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT >> --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT >> --v-precision=FLOAT >> >> >> And to remove it >> >> ipa dnsrecordattr-mod --remove location --lat-deg=INT --lat-min=INT >> --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT >> --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT >> --v-precision=FLOAT > So if user would want to remove a LOC record, he would have to pass all > these attributes to refer which attribute value to remove? I think that is the case anyway. Since a DNS record is really just an multivalue attribute, you would now have to do a dns-record-mod with the list of all LOC records that you don't want to delete. I used this as an example because it is the most complex case. Just thinking it through...I'm not certain I like the "one command per record type" as it changes a lot of other assumptions. DNS is a wierd beast already. I've spent a lot of time on the DNS ui, and it is pretty tricky to get right. I'm trying to balance the PI against efficient usage. What we really need for the fields is a way to specify the format for a given field, much like the format strings used for group names. For example, the LOC record is really LOC d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] {"E"|"W"} alt["m"] [siz["m"] [hp["m"] [vp["m" And all the WebUI needs is a way to specify that format to validate. >>> Can we use augeas for this? >>> Augeas lenses use this kind of the validation and there is python >>> binding so may be we should use augeas as an inspiration or ask for an >>> augeas Javascript solution? >> We can't. Augeas knows how to manipulate config files and only that, >> there is no API for anything else. >> > Some time ago I wrote a patch to extend Augeas to operate on arbitrary > strings. I never had time to push it upstream, but I think I still have > is somewhere. > > Not sure if this approach would help us anyway, we would still have to > wait until this feature made it to RHEL and solve the JS bindings as > well > Yes I was thinking about this path at least as an inspiration. > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote: On 9/22/2011 7:24 AM, Martin Kosek wrote: 2) Some DNS records may be pretty large. MX record data is small, but for example CERT records have an entire certificate stored in it. Wouldn't there be a problem if we place the large DNS record in URL? This is how the DNS record list page could be redesigned: http://edewata.fedorapeople.org/images/dns-record-list-page.png It should resemble what you see in the zone file. The content can be obtained with a single dnsresource-find operation. If you click one of the data, it would open a dialog box for that particular record type. We will use the raw data as a primary key to execute the dnsresource--show command. Each attribute in this record type will be displayed in separate fields: http://edewata.fedorapeople.org/images/dns-record-edit-dialog.png When you save it will call dnsresource--mod and put the values in separate parameters. It will still use the original raw data as primary key, but we don't need to encode the new values into raw data. If we use a dialog box like this none of the attributes need to be added into the URL. It will be passed internally via variables. If we use a separate edit page (with a unique URL for each record), we might need to specify the entire raw data in the URL, but maybe we can find a workaround for CERT record. I'd prefer to use a dialog box because it can be used for both add and modify. OPEN QUESTION: should we implement these new commands also for discrete DNS records types to be consistent? I mean for example A, , CNAME, PTR, ... They would look like ipa dnsrecord--add --ip-address=IPAddress BENEFITS of this approach (command per RR type): - use can get all help for RR type by simply typing "ipa help dnsrecord-mx-add" - we would be able to implement helper methods consistently on one place, for example: dnsrecord--add --from-mac=00:1D:BA:06:37:64 If we have this for all record types the UI can use a generic code to figure out which command to use. Everything will be in this pattern: dnsrecord--add/mod/del [parameters*] We won't have it for all types, so we will need a map. Most will use the old API, and a few will use the pattern above OPEN QUESTION: should we implement also -find methods (dnsrecord-mx-find) so that UI can for example populate text fields for all (MX) records for one DNS name? Depending on the UI design, it might not be needed. But it won't hurt to have one in case the UI changes, for example suppose we want to have separate tabs for each record type. Find can return the original Data, and probably should. We only need the individual fields on edit, maybe on show. 4) -mod commands shall be implemented for structured RR types: API would be almost the same as with -add commands. User (WebUI) would just have to identify which record should be modified: a) by copy&passing the raw DNS value directly to the command: dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0 The Web UI will use the JSON-RPC version of this command. As discussed already, the non-interactive mode for CLI will be useful for writing scripts or other applications that will invoke the CLI/API. Being able to specify the attributes in separate parameters means that the client doesn't have to figure out how to encode the attributes into a single raw data. They will be encoded consistently by the server. b) (CLI only) by using an interactive wizard that would let user choose the modified record like this way: dnsrecord-mx-mod example.com @ --preference=0 Which record would you like to change? [1] 1 mx1.example.com. [2] 10 mx2.example.com. DNS record: The interactive mode will be useful for people who have to use text-based terminal. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On Thu, 2011-09-22 at 19:31 -0500, Endi Sukma Dewata wrote: > On 9/22/2011 7:24 AM, Martin Kosek wrote: > >> 2) Some DNS records may be pretty large. MX record data is small, but > >> for example CERT records have an entire certificate stored in it. > >> Wouldn't there be a problem if we place the large DNS record in URL? > > This is how the DNS record list page could be redesigned: > http://edewata.fedorapeople.org/images/dns-record-list-page.png > > It should resemble what you see in the zone file. The content can be > obtained with a single dnsresource-find operation. > > If you click one of the data, it would open a dialog box for that > particular record type. We will use the raw data as a primary key to > execute the dnsresource--show command. Each attribute in this > record type will be displayed in separate fields: > http://edewata.fedorapeople.org/images/dns-record-edit-dialog.png > > When you save it will call dnsresource--mod and put the values > in separate parameters. It will still use the original raw data as > primary key, but we don't need to encode the new values into raw data. > > If we use a dialog box like this none of the attributes need to be added > into the URL. It will be passed internally via variables. If we use a > separate edit page (with a unique URL for each record), we might need to > specify the entire raw data in the URL, but maybe we can find a > workaround for CERT record. I'd prefer to use a dialog box because it > can be used for both add and modify. I am not an UX designer, but I think this should work. Plus, as you said, we wouldn't have to deal with large DNS records in URL problem. > > > OPEN QUESTION: should we implement these new commands also for discrete > > DNS records types to be consistent? I mean for example A, , CNAME, > > PTR, ... They would look like > > > >> ipa dnsrecord--add --ip-address=IPAddress > > > > BENEFITS of this approach (command per RR type): > > - use can get all help for RR type by simply typing "ipa help > > dnsrecord-mx-add" > > - we would be able to implement helper methods consistently on one > > place, for example: > > dnsrecord--add --from-mac=00:1D:BA:06:37:64 > > If we have this for all record types the UI can use a generic code to > figure out which command to use. Everything will be in this pattern: > dnsrecord--add/mod/del [parameters*] So far, I didn't plan to implement also -del methods as deleting should take the raw value as its primary key. dnsrecord-del does that already. But if we find benefits of -del methods we can implement it. > > > OPEN QUESTION: should we implement also -find methods > > (dnsrecord-mx-find) so that UI can for example populate text fields for > > all (MX) records for one DNS name? > > Depending on the UI design, it might not be needed. But it won't hurt to > have one in case the UI changes, for example suppose we want to have > separate tabs for each record type. Lets start just with -show commands and implement -find if it is really needed. I want to keep the number of DNS commands as small as possible. > > > 4) -mod commands shall be implemented for structured RR types: > > API would be almost the same as with -add commands. User (WebUI) would > > just have to identify which record should be modified: > > a) by copy&passing the raw DNS value directly to the command: > > > >> dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0 > > The Web UI will use the JSON-RPC version of this command. As discussed > already, the non-interactive mode for CLI will be useful for writing > scripts or other applications that will invoke the CLI/API. > > Being able to specify the attributes in separate parameters means that > the client doesn't have to figure out how to encode the attributes into > a single raw data. They will be encoded consistently by the server. Yes, there shouldn't be problems to script it. > > > b) (CLI only) by using an interactive wizard that would let user choose > > the modified record like this way: > > > >> dnsrecord-mx-mod example.com @ --preference=0 > > Which record would you like to change? > > [1] 1 mx1.example.com. > > [2] 10 mx2.example.com. > > DNS record: > > The interactive mode will be useful for people who have to use > text-based terminal. > Yep. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote: > On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote: > >> OPEN QUESTION: should we implement these new commands also for discrete > >> DNS records types to be consistent? I mean for example A, , CNAME, > >> PTR, ... They would look like > >> > >>> ipa dnsrecord--add --ip-address=IPAddress > >> > >> BENEFITS of this approach (command per RR type): > >> - use can get all help for RR type by simply typing "ipa help > >> dnsrecord-mx-add" > >> - we would be able to implement helper methods consistently on one > >> place, for example: > >> dnsrecord--add --from-mac=00:1D:BA:06:37:64 > > > > If we have this for all record types the UI can use a generic code to > > figure out which command to use. Everything will be in this pattern: > > dnsrecord--add/mod/del [parameters*] > > We won't have it for all types, so we will need a map. Most will use > the old API, and a few will use the pattern above I think to make this all as consistent as possible, new API shall be implemented for all types (except unsupported and DNSSEC ones). Rob did agree with this approach too. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 881 don't log OTP in client install log
On Thu, 2011-09-22 at 11:55 -0400, Rob Crittenden wrote: > Obfuscate the one-time password in the client installer log. > > rob NACK. You missed a case when OTP is interactively prompted (-W parameter is passed). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel