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-rrtype-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-rrtype-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-rrtype-add/mod/del primary keys [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 copypassing 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:user enters the number 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-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 ___ 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 Thu, Sep 22, 2011 at 09:59:01PM -0400, Dmitri Pal wrote:
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
owner TTL class 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.
OK, I've dug up and attached the patch.
Obviously it doesn't apply upstream anymore, but it is still a very good
starting point if someone wants to tackle this problem.
From 191110b81376f831b211e34f491a379d69c79cb0 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek jhro...@redhat.com
Date: Wed, 25 Mar 2009 17:04:54 +0100
Subject: [PATCH] aug_lens_get
---
src/augeas.c | 29 +++
src/augeas.h | 20
src/augeas_sym.version |1 +
src/augtool.c | 16 ++
src/internal.h |8 +++
src/transform.c| 121 +--
src/transform.h|4 ++
7 files changed, 173 insertions(+), 26 deletions(-)
diff --git a/src/augeas.c b/src/augeas.c
index 192a79a..291906e 100644
--- a/src/augeas.c
+++ b/src/augeas.c
@@ -978,6 +978,35 @@ int aug_print(const struct augeas *aug, FILE *out, const
char *pathin) {
return result;
}
+int aug_lens_get(augeas *aug, const char *path, const char *lens,
+ const char *txt, size_t txt_len) {
+char *text = NULL;
+int result = -1;
+
+/* append newline to the end of the string if needed */
+if (txt_len == 0 || txt[txt_len-1] != '\n') {
+if (ALLOC_N(text, txt_len+2) 0) {
+goto fini;
+}
+strcpy(text, txt);
+text[txt_len] = '\n';
+text[txt_len+1] = '\0';
+txt_len += 2;
+} else {
+text = (char *)
Re: [Freeipa-devel] Structured DNS record API proposal - summary
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, , 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-rrtype-add/mod/delprimary 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 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 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
Re: [Freeipa-devel] Structured DNS record API proposal - summary
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, , 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-rrtype-add/mod/delprimary 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 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 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 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
Re: [Freeipa-devel] Structured DNS record API proposal - summary
On 09/23/2011 11:52 AM, Rob Crittenden wrote: 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, , 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-rrtype-add/mod/delprimary 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 We need to be able to display even the unsupported types, as they might end up in the Database. We can work around that limitation. IMHO if we can't manage them we shouldn't show them. rob Yeah, probably. If you can guarantee it from the server side, I'm OK with that. ___ 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 Fri, 2011-09-23 at 13:17 -0400, Adam Young wrote: On 09/23/2011 11:52 AM, Rob Crittenden wrote: 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, , 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-rrtype-add/mod/delprimary 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 We need to be able to display even the unsupported types, as they might end up in the Database. We can work around that limitation. IMHO if we can't manage them we shouldn't show them. rob Yeah, probably. If you can guarantee it from the server side, I'm OK with that. I can. We don't have them allowed in the schema as bind-dyndb-ldap plugin does not support them. 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 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-rrtype-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=dnszoneidentity=dnsnavigation=identitydnszone-facet=defaultdnszone-pkey=ayoung.boston.devel.redhat.com it will be similar to Permissions (click Add): http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permissionipaserver=rolebasednavigation=ipaserver The UI will use the type to pick the correct dnsrecord-rrtype-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-rr-type-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 copypaste, 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-rr-type-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-rrtype-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
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-rrtype-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-rrtype-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-rrtype-add/mod/del primary keys [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 copypassing 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:user enters the number 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] 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
owner TTL class 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
On Wed, 2011-09-21 at 10:58 +0200, Adam Tkac wrote: On 09/16/2011 02:25 PM, Martin Kosek wrote: On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote: Whatever you do do not split this operation into a DEL+ADD, we want an atomic modify operation in any case. as you do not want to have a race where named may query the MX records and find them empty. That'd be much worse than returning one of them outdated. This means whatever the API we need to support a way to add all values at the same time. We can also have the more verbose API to make things more understandable, but we need this bulk API for the WebUI IMHO. I agree, the change shouldn't be split to del+add. My proposed API: dnsrecord-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 would do just one write to LDAP. Unfortunately, this is not so pretty for CLI, one would have to copypaste raw DNS value to be able to edit its components, but it should be simple for WebUI. Right now, I don't see some better way. I thought about this CLI proposal and it is definitely a good start. In the future we can consider to improve the CLI this way, for example: $ dnsrecord-mx-mod example.com --preference=0 Which record would you like to change? [1] 1 mx1.example.com. [2] 10 mx2.example.com. $ select the record This way will be more convenient for people which use CLI, especially when we start to support DNSSEC and resource record types which store certificates (CERT/SSHFP) get widely used. I doubt that someone likes copyingpasting SHA* hashes and RSA signatures every time when some record is modified. Regards, Adam Good idea! I already added some interactive prompt helpers to DNS plugin, you can check for example dnsrecord_del command, specifically its interactive_prompt_callback(). This can be also used for -mod/-show command which will make the command user-friendly for both CLI and WebUI users. 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
On 09/21/2011 01:58 AM, Adam Tkac wrote: On 09/16/2011 02:25 PM, Martin Kosek wrote: On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote: Whatever you do do not split this operation into a DEL+ADD, we want an atomic modify operation in any case. as you do not want to have a race where named may query the MX records and find them empty. That'd be much worse than returning one of them outdated. This means whatever the API we need to support a way to add all values at the same time. We can also have the more verbose API to make things more understandable, but we need this bulk API for the WebUI IMHO. I agree, the change shouldn't be split to del+add. My proposed API: dnsrecord-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 would do just one write to LDAP. Unfortunately, this is not so pretty for CLI, one would have to copypaste raw DNS value to be able to edit its components, but it should be simple for WebUI. Right now, I don't see some better way. I thought about this CLI proposal and it is definitely a good start. In the future we can consider to improve the CLI this way, for example: $ dnsrecord-mx-mod example.com --preference=0 Which record would you like to change? [1] 1 mx1.example.com. [2] 10 mx2.example.com. $select the record This way will be more convenient for people which use CLI, especially when we start to support DNSSEC and resource record types which store certificates (CERT/SSHFP) get widely used. I doubt that someone likes copyingpasting SHA* hashes and RSA signatures every time when some record is modified. Regards, Adam Interactive mode is useful in some case. But can people still script with this CLI? I hope this CLI can still offer non-interactive mode so it would be more script-friendly. BTW, I am a QA. Yi ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- ~ | Yi Zhang | | QA @ Mountain View, Calinfornia | | Cell: 408-509-6375| ~ ___ 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 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-rrtype-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=dnszoneidentity=dnsnavigation=identitydnszone-facet=defaultdnszone-pkey=ayoung.boston.devel.redhat.com it will be similar to Permissions (click Add): http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permissionipaserver=rolebasednavigation=ipaserver The UI will use the type to pick the correct dnsrecord-rrtype-add command and each parameter in that command will have a corresponding field to enter the value. 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. 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). 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 If we stay with (1) the UI will have to call the dnsrecord-rrtype-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. 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-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 When updating the value, option (1) is a bit more complicated because the UI will have to find the dirty record and then find the dirty field. Option (2) is simpler because it will only need to find the dirty field, but both will execute the following command: dnsrecord-mx-mod example.com @ 1 mx1.example.com. --preference=0 I think option (2) is more clear to users because we only have to introduce 2 concepts: zone and record (which is the individual value). With option (1) we will have to explain the underlying LDAP entry that will be deleted automatically when the last record value is deleted. -- Endi S. Dewata ___ 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/16/2011 09:51 AM, Martin Kosek wrote: On Thu, 2011-09-15 at 10:26 +0200, Adam Tkac wrote: Your proposal seems fine for me. However I would recommend not to expose routines for managing DNSSEC related records because DNSSEC is currently not supported in the bind-dyndb-ldap. This doesn't mean you should remove code which handles those records, just don't expose them to users, please. Routines can be reused in future, when we decide how to handle DNSSEC in FreeIPA. I checked the dnsrecord-rrtype-add list below and DNSSEC related records are DS, KEY, NSEC, RRSIG, SIG. Regards, Adam Since we don't know how DNSSEC records will be handled, I would rather don't implement the methods now and then reimplement them. When I was implementing DNS validators in patch 120 I noticed we provide API to add many RR types that are not supported via bind-dyndb-ldap at all. Any attempt to add them ends with missing LDAP schema attribute error. Since the new API is targeted for new FreeIPA major release I wouldn't be afraid to remove all these RR types from our API (they don't work anyway). This applies to these RR types: APL, DHCID, DLV, DNSKEY, HIP, IPSECKEY, NSEC3, NSEC3PARAM, RP, TA, TKEY, TSIG. IMO, we should then add there RR types _only_ when they are supported by bind-dyndb-ldap. Ack, this is the best for now. Regards, Adam ___ 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 Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote: On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote: On 09/14/2011 12:18 PM, Martin Kosek wrote: Attached in the txt file. If you have any comments or suggestions to this proposal, please let me know. https://fedorahosted.org/freeipa/ticket/1766 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel 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-rrtype-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. 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 dnsrecord-mx-show example.com --dnsrecord=1 mx1.example.com. PREFERENCE: 1 user modifies this to 0 MAILSERVER: mx2.example.com. dnsrecord-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 What do you think about this API for record modification? Although racy, isn't it simpler to just always replace the whole set ? 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] Structured DNS record API proposal
On Fri, 2011-09-16 at 14:04 +0200, Martin Kosek wrote: On Fri, 2011-09-16 at 07:58 -0400, Simo Sorce wrote: On Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote: On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote: On 09/14/2011 12:18 PM, Martin Kosek wrote: Attached in the txt file. If you have any comments or suggestions to this proposal, please let me know. https://fedorahosted.org/freeipa/ticket/1766 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel 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-rrtype-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. 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 dnsrecord-mx-show example.com --dnsrecord=1 mx1.example.com. PREFERENCE: 1 user modifies this to 0 MAILSERVER: mx2.example.com. dnsrecord-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 What do you think about this API for record modification? Although racy, isn't it simpler to just always replace the whole set ? Simo. How would that work? We are designing -add -show -mod commands for mutlivalued LDAP attribute values, we should have some reference what value we are modifying. Or did you mean the following command sequence for mod operation? dnsrecord-del example.com @ --mx-rec=0 mx1.example.com., 1 mx2.example.com. dnsrecord-mx-add example.com @ --priority=0 --mailserver=mx1.example.com. dnsrecord-mx-add example.com @ --priority=1 --mailserver=mx2.example.com. Oh I see, I thought we could add multuple values at the same time, but with this syntax it is not possible. Perhaps something like this: dnsrecord-mod example.com @ --replace --mx-rec=0 mx1.example.com., 1 mx2.example.com. This would replace any existing record with the list of 'raw' records provided. Whatever you do do not split this operation into a DEL+ADD, we want an atomic modify operation in any case. as you do not want to have a race where named may query the MX records and find them empty. That'd be much worse than returning one of them outdated. This means whatever the API we need to support a way to add all values at the same time. We can also have the more verbose API to make things more understandable, but we need this bulk API for the WebUI IMHO. 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] Structured DNS record API proposal
On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote: On Fri, 2011-09-16 at 14:04 +0200, Martin Kosek wrote: ... How would that work? We are designing -add -show -mod commands for mutlivalued LDAP attribute values, we should have some reference what value we are modifying. Or did you mean the following command sequence for mod operation? dnsrecord-del example.com @ --mx-rec=0 mx1.example.com., 1 mx2.example.com. dnsrecord-mx-add example.com @ --priority=0 --mailserver=mx1.example.com. dnsrecord-mx-add example.com @ --priority=1 --mailserver=mx2.example.com. Oh I see, I thought we could add multuple values at the same time, but with this syntax it is not possible. Perhaps something like this: dnsrecord-mod example.com @ --replace --mx-rec=0 mx1.example.com., 1 mx2.example.com. We have something similar already. Current implementation of dnsrecord-mod jus replaces whatever was in the multivalued attribute now with the new values. That's what WebUI uses now. Now, if you modify MX record priority in raw record, this is what is sent to IPA: dnsrecord-mod example.com @ --mx-rec=0 mx1.example.com.,1 mx2.example.com. This would replace any existing record with the list of 'raw' records provided. Yes, that is current state. The motivation for this new API, however, is an ability to edit the structured DNS records, not the raw ones. WebUI shouldn't generate raw DNS records from structured WebUI form and send them to server, server should do it. That was my motivation for the proposed API. Whatever you do do not split this operation into a DEL+ADD, we want an atomic modify operation in any case. as you do not want to have a race where named may query the MX records and find them empty. That'd be much worse than returning one of them outdated. This means whatever the API we need to support a way to add all values at the same time. We can also have the more verbose API to make things more understandable, but we need this bulk API for the WebUI IMHO. I agree, the change shouldn't be split to del+add. My proposed API: dnsrecord-mx-mod example.com --dnsrecord=1 mx1.example.com. --preference=0 would do just one write to LDAP. Unfortunately, this is not so pretty for CLI, one would have to copypaste raw DNS value to be able to edit its components, but it should be simple for WebUI. Right now, I don't see some better way. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
