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 - 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
