date:20110922


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

2011-09-22 Thread Jan Cholasta


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

2011-09-22 Thread Jan Cholasta


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

2011-09-22 Thread John Dennis


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

2011-09-22 Thread Simo Sorce

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

2011-09-22 Thread Simo Sorce

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

2011-09-22 Thread Marko Myllynen

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.

2011-09-22 Thread Endi Sukma Dewata


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.

2011-09-22 Thread Endi Sukma Dewata


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

2011-09-22 Thread Endi Sukma Dewata


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

2011-09-22 Thread Dmitri Pal

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

2011-09-22 Thread Dmitri Pal

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

2011-09-22 Thread Adam Young


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