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=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=ayoung.boston.devel.redhat.com
it will be similar to Permissions (click Add):
http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permission&ipaserver=rolebased&navigation=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, AAAA, 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 copy&paste, 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 to process.
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.
When I look at it, option (2) looks better for our case.
Martin
I think this entire discussion became too academic. I would like to make
it more down to earth :-) Adam proposed new complex attributes, IMHO it
should be discussed separately from this API proposal. I gave it some
thought and I just don't see the benefits that it would bring to DNS.
Personally, I would like to continue with API that was proposed so far.
Summary of the steps for new DNS types:
1) New API shall be implemented only for non-DNSSEC resource record (RR)
types that are supported by bind-dyndb-ldap.
DNSSEC RR types to be left unimplemented: DS, KEY, NSEC, RRSIG, SIG
Unsupported RR types to be removed at all: APL, DHCID, DLV, DNSKEY, HIP,
IPSECKEY, NSEC3, NSEC3PARAM, RP, TA, TKEY, TSIG
In future, DNSSEC attributes should be generated automatically. But let
us leave this discussion to the future.
2) -add commands shall be implemented for structured RR types:
ipa dnsrecord-afsdb-add --subtype=INT --hostname=STR
ipa dnsrecord-cert-add --type=ENUM --tag=INT --algorithm=ENUM --certificate=STR
ipa dnsrecord-kx-add --preference=INT --exchanger=STR
ipa dnsrecord-loc-add --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
ipa dnsrecord-mx-add --priority=INT --mailserver=STR
ipa dnsrecord-naptr-add --order=INT --preference=INT --flag=ENUM --service=STR
--regexp=STR --replacement=STR
ipa dnsrecord-srv-add --priority=INT --weight=INT --port=INT --target=STR
ipa dnsrecord-sshfp-add --algorithm=ENUM --type=ENUM --fingerprint=STR
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
3) -show commands shall be implemented for structured RR types:
These commands will let UI populate the (text) fields, ENUMs, etc. They
would look this way
ipa dnsrecord-mx-show ZONE NAME VALUE
For example:
dnsrecord-mx-show "example.com" "@" "1 mx1.example.com."
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?
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 copy&passing the raw DNS value directly to the command:
dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0
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>
I have already implemented an interactive wizard like this for
dnsrecord-del and it works fine.
Martin
