On Fri, 2011-09-23 at 10:46 -0400, Adam Young wrote: > 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.
Ok, lets see... > > 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. > That's the benefit of command-per-type approach. We could implement some helpers to dnsrecord-cert-add when file upload is ready or we specify a way to cooperate with dogtag there. > > 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. > I agree - that's not pretty. On the server side, I would like to use services of python-netaddr package. This package is able to validate both A or AAAA records. I don't see the benefit of using own regex instead. > > > Lets deal with these issues, and hold the API explosion until later. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel