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 likeipa dnsrecord-aaaa-add --ip-address=IPAddressBENEFITS 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:64If 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 aboveI 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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
