On 09/23/2011 02:02 AM, Martin Kosek wrote:
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, AAAA, CNAME,
PTR, ... They would look like

ipa dnsrecord-aaaa-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-aaaa-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-<rrtype>-add/mod/del<primary keys>  [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



Lets proceed with caution here. I think we can really complicate things with this approach.

From a UI perspective, we will have to tailor the control to be used for any DNS record type that gets more than a single field.

From what I've seen, and the types we have to deal with thus far, only the SRV and MX records are really used that much. Lets implement for them first and test it out.

For certificate based records, DNS and otherwise, we want to get file upload working, as cut and paste etc is a PITA. I'm not sure if we really need the Cert based records, but I suspect that, from a Dogtag perspective, there is a lot of things we could do with a tight integration of the two. I can even see an API where we generate a Cert based record from a Certificate Signing Request.


For A and AAAA records, we don't need a new API, we need a pattern. For A record that pattern is:

\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b


For AAAA records that is:
/^\s*((([0-9A-Fa-f]{1,4}:){7}([0-9A-Fa-f]{1,4}|:))|(([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}|((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){5}(((:[0-9A-Fa-f]{1,4}){1,2})|:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){4}(((:[0-9A-Fa-f]{1,4}){1,3})|((:[0-9A-Fa-f]{1,4})?:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){3}(((:[0-9A-Fa-f]{1,4}){1,4})|((:[0-9A-Fa-f]{1,4}){0,2}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){2}(((:[0-9A-Fa-f]{1,4}){1,5})|((:[0-9A-Fa-f]{1,4}){0,3}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){1}(((:[0-9A-Fa-f]{1,4}){1,6})|((:[0-9A-Fa-f]{1,4}){0,4}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(:(((:[0-9A-Fa-f]{1,4}){1,7})|((:[0-9A-Fa-f]{1,4}){0,5}:!
((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:)))(%.+)?\s*$/


Yep, they are nasty. But that is going to be the case regardless of whether we use the new API or not.



Lets deal with these issues, and hold  the API explosion  until later.










_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to