Re: [Freeipa-devel] [PATCH] 271 Modified dialog to use sections.
On 09/21/2011 10:10 PM, Endi Sukma Dewata wrote: On 9/21/2011 6:50 AM, Petr Vobornik wrote: Fixed. The dialog fields don't need undo, so the text() needs to be overridden to disable undo. This can be improved again later. The override isn't necessary because it wasn't there before and all (at least I hope) fields in add dialogs specify undo: false. This feature can save some time though. Problem of current implementation is that it overrides only the default created section, not the sections specified in spec object. But as you wrote - this can be improved later. 4) host.js:208,217: we should avoid using purely visual inline css styles. They should be replaced by class (if cannot be achieved by other selector) and styled in css file. This doesn't concern functional styles (animations, resizing, hiding, showing). Fixed. Yes, we should have a ticket to remove all inline CSS styles. Are you sure the 'name' attribute is the right way to go? Wouldn't be 'class' or 'id' (in this case) better? For table data 'name' attribute isn't even in HTML spec http://dev.w3.org/html5/spec/Overview.html#the-td-element. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 125 Remove checks for ds-replication plugin
On Wed, 2011-09-21 at 10:29 -0400, Rob Crittenden wrote: Martin Kosek wrote: The replication plugin is no longer shipped as a separate package. Remove the code checking its existence. https://fedorahosted.org/freeipa/ticket/1815 ACK Pushed to master, ipa-2-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 44 Fix parameter validation
On Wed, 2011-09-21 at 15:31 -0400, Rob Crittenden wrote: Jan Cholasta wrote: On 25.8.2011 18:21, Jan Cholasta wrote: What this patch does: * Make sure arguments are validated and default values are filled in before calling a command. * Add new parameter flag validate_search to force validation on search arguments. * Fix validation of IP network parameters in the DNS plugin. https://fedorahosted.org/freeipa/ticket/1627 Honza Redone the patch and split it to 3 parts: I haven't tested these yet, these comments are just from reading the patches. * [PATCH 46] Add IP address and IP network parameter types Adds two new parameter types, IPAddress and IPNetwork (which replaces the validate_search flag, as it was just a hack). A param type looks like the way to go. There are other IPaddress parameters, such in host, should this be expanded to cover that? Not sure about replacing List with Str types. It may make no difference since I'm not sure how a List could be passed for some of these. Can you make sure there is no possibility that on the wire someone couldn't pass these as a list and actually do something reasonable in the server? I suspect they can't but this is a rather major datatype change. * [PATCH 44] Fix parameter validation Changes Command.get_default so that default_from parameters are validated before they are used to create the default value. Just a heads-up but this will conflict big time with my password patch. It throws away the ordering that the parameters had. This could impact the order in which interactive prompting happens. Did you verify that it still works sanely? * [PATCH 47] Remove create_default Removes create_default, as it does exactly the same thing as default_from, but without the advantage of knowing what parameters are used to create the default value. All uses of create_default are replaced by default_from with no arguments, because that's all create_default is currently used for in IPA. I'm not sure why you want to remove this, is it causing problems with validation? In general the patch comments need more details. This patch e-mail has more information on what each patch does than the patches themselves, including lacking ticket info. rob Hm, by the way I am not very excited about adopting this sort of changes to framework that close to the 6.2 rebase. Are we sure enough that this won't cause any collateral damage? If possible, I would prefer to integrate it to 3.0 branch so that we have enough time to validate it and fix bugs. 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] [PATCH] include stdint.h for uintptr_t
On Wed, 2011-09-21 at 10:28 -0400, Rob Crittenden wrote: Marko Myllynen wrote: Hi, stdint.h must be included for uintptr_t at least on Ubuntu Oneiric, without it ipa-client compilation fails. There is an ipa-client make target that should make things somewhat easier as it doesn't need to build the entire tree. sure, but gcc bails out with an error when compiling ipa-join.c without this patch. And while at it I added the fix also to daemons/ipa-slapi-plugins/common/util.h not just for ipa-client/ipa-client-common.h. Cheers, Ok, opened https://fedorahosted.org/freeipa/ticket/1831 Ack and pushed to master. 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] [PATCH] #1814 Enforce old password requirement in ldappasswd operations
Simo Sorce wrote: Although we were properly checking that the user successfully authenticated (either through a password bind or a GSSAPI bind) we were not enforcing the requirement to provide us with the old password, and this is better security hygiene. Fixes: https://fedorahosted.org/freeipa/ticket/1814 Tested and works for me. Properly requires old password for self password changes. Do not require it for admin password changes. Simo. ack, pushed to master and ipa-2-1 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 881 don't log OTP in client install log
Obfuscate the one-time password in the client installer log. rob From e454f840460b6703d8327a235844adcbc310f48d Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Thu, 22 Sep 2011 11:52:58 -0400 Subject: [PATCH] Don't log one-time password in logs when configuring client. https://fedorahosted.org/freeipa/ticket/1801 --- ipa-client/ipa-install/ipa-client-install |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 44c2f5fbc40c9f3a6d5f4378d91e048b63bf0e7a..413e2d2909aed4990905e70579d9a86c07193fe9 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -23,17 +23,15 @@ try: import sys import os -import stat import time import socket import logging import tempfile import getpass -import re from ipaclient import ipadiscovery import ipaclient.ipachangeconf import ipaclient.ntpconf -from ipapython.ipautil import run, user_input, CalledProcessError, file_exists, install_file +from ipapython.ipautil import run, user_input, CalledProcessError, file_exists import ipapython.services as ipaservices from ipapython import ipautil from ipapython import dnsclient @@ -888,6 +886,7 @@ def install(options, env, fstore, statestore): return CLIENT_INSTALL_ERROR if not options.on_master: +nolog = tuple() # First test out the kerberos configuration try: (krb_fd, krb_name) = tempfile.mkstemp() @@ -929,6 +928,7 @@ def install(options, env, fstore, statestore): print stdout return CLIENT_INSTALL_ERROR elif options.password: +nolog = (options.password,) join_args.append(-w) join_args.append(options.password) elif options.prompt_password: @@ -940,7 +940,7 @@ def install(options, env, fstore, statestore): join_args.append(password) # Now join the domain -(stdout, stderr, returncode) = run(join_args, raiseonerr=False, env=env) +(stdout, stderr, returncode) = run(join_args, raiseonerr=False, env=env, nolog=nolog) if returncode != 0: print sys.stderr, Joining realm failed: %s % stderr, -- 1.7.6 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 279 Fixed problem enrolling member with the same name.
On 09/20/2011 02:19 AM, Endi Sukma Dewata wrote: The IPA.association_adder_dialog has been modified to use an exclusion list to hide entries that are already enrolled. The IPA.adder_dialog has been modified to store the columns directly in the available selected tables. Ticket #1797 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Don't remove /tmp when removing temp cert dir
Marko Myllynen wrote: Hi, If /tmp happens to be empty os.removedirs() happily removes it... Seen on Ubuntu Oneiric. Cheers, https://fedorahosted.org/freeipa/ticket/1843 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 279 Fixed problem enrolling member with the same name.
On 9/22/2011 11:14 AM, Petr Vobornik wrote: On 09/20/2011 02:19 AM, Endi Sukma Dewata wrote: The IPA.association_adder_dialog has been modified to use an exclusion list to hide entries that are already enrolled. The IPA.adder_dialog has been modified to store the columns directly in the available selected tables. Ticket #1797 ACK Pushed to master and ipa-2-1. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 276 Fixed problem enabling/disabling DNS zone.
On 9/22/2011 6:59 AM, Petr Vobornik wrote:
On 09/17/2011 12:18 AM, Endi Sukma Dewata wrote:
The details facet for DNS zone has been modified to use dnszone-
enable/disable for idnszoneactive and dnszone-mod for other fields.
Ticket #1813
ACK
Pushed to master and ipa-2-1.
Btw it doesn't matter (besides performance) if you move 'if
(!field.is_dirty()) continue;' in sudo and hbac facet couple lines lower
because to execute member_operation you have to fulfil two conditions,
which won't be never reached - name of the association fields changed so
'if (categories[field.name])' will be never true. Even if it would be
the next condition ('values[0] == 'all) won't be either because of weird
implementation of table_widget.save method.
Anyway if it would be functional it would be IMO bad - checking line
doesn't imply that user wants it to be deleted right now. Even if
marking the line could be used only for deletion.
This code should be cleaned in the future (erased or fixed).
As mentioned on IRC, this fixes a regression in the UI when changing the
category. The two conditions (remove_values and has_values) are set by
different fields (category and table), that's why the logic is kind of
complicated. The server side will be fixed in ticket #1440. Once that's
fixed we no longer need this code so it can be cleaned up.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 871 add hostname regex
Rob Crittenden wrote:
Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Tue, 13 Sep 2011, Jan Cholasta wrote:
What about IDN hosts? With this change we would require them to be
always in Punycode?
Oh, hadn't considered that, I was just following the relevent RFCs. Is
there a way we can easily support those as well?
The easiest way would probably be:
normalizer=lambda value: unicode(value.encode('idna'))
That's one part. Another one is visualizing such content -- for both
Web UI and CLI we would need to run encodings.idna.ToUnicode().
Finally, make sure whatever we pass to external applications is
properly formatted as well -- all of them should be able to work with
xn-Punycode form.
The UI also links the DNS hostname to the host entries so I'd think the
names must be matchable in some way. If DNS can only store punycode
names I think the regex will be fine.
I think we're going to need a bit more time to get this right. What I
propose for the short term is to encode in puny code, do the validation,
and reject as required. We still store in full unicode.
Note that special characters may not work that will now but validating
characters won't make it any worse.
rob
As it turns out Kerberos doesn't support this type of hostname so my
original patch stands for now. We can't allow non-ascii hostnames. I'll
open a 3.0 ticket to investigate further.
rob
___
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 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] FreeIPA and per-machine views
On 09/21/2011 10:07 PM, Stephen Gallagher wrote: I've ben working on the multiple search base feature in SSSD and I've had some thoughts that might be relevant to the FreeIPA v3 core effort. The idea behind multiple search bases is fairly simple; instead of simply checking one subtree for user or group information, you check several in series, stopping at the first match. I was looking into this to identify the primary reasons why a deployment might use such an approach and I came up with two important use-cases. 1) This is a fairly simple way to extend a network you don't fully control. A classic example might be a Computer Science department at a university. They would want to use the campus user accounts (probably provided by the university IT department), but also add new groups for sharing or access control on CS department machines. This could be done with multiple search bases by setting the first base to the CS department subtree and the second base to a replicated university subtree. I do not think we want to deal with multiple subtrees of users in the same IPA instance. We already decided against it in the past when we flattened the tree. At least I am not convinced that this is actually needed. I am actually aware of one more use case why people do different subtrees for users. It is because they have duplication of the uid/gid. Though it is bad it is a reality that people deal with. And they deal with it by having subtrees in DS. But it will not help in our case as IPA is built with the notion of the unified uid/gid namespace. The only thing will help in both cases is different IPA domains with trust relations so I suggest we focus on that part rather than support of multiple subtrees for users. If IPA trusts still do not work for the user may be staying with a free from DS server is a better choice. 2) The second important use-case is for dealing with third-party applications with hard-coded groups. For a hypothetical example, let's say that a closed-source database program requires a user to be in the group 'dbadmins' in order to access a shell for editing the database. However, there may be more than one such database deployed in the network, possibly among different teams. Having multiple search bases allows different machines to have different views of this group. That is an interesting use case. But rather than creating views I would suggest a different approach. In IPA we create a way to specify alternative location for specific override groups. For example we now have cn=groups, cn=accounts,... where all groups live. we can have cn=overridegroups, cn=accounts,... and allow creation of the special subtrees like we do with locations for maps. UI and CLI can be modified to allow to manage these areas. I do not think that would be a rocket science. On the SSSD side we can have an sssd_group_override_base parameter that would define an override base for that machine. The logic in the SSSD will be to read groups from override base first (it is expected that there will be a small subset of groups that are used by specific app like DB for example) and then the normal groups from the search base but discard the groups that already have been fetched from the override location (or something like this. I bet it is more complex and I will leave it to you to define actual implementation, but I hope it illustrates good enough what I am trying to propose). May be Jan's delete group functionality would be really handy for this use case. The alternative however is to create and support group aliases and use group aliases as names. But before we go into all of this we need to realize that contemporary versions of software most likely would allow configurable groups. Id it is an old software than SSSD might not be in the picture anyways so it should be a pure server side solution so may be we should just allow alternative subtrees for groups but then how we are going to deal with gids or it does not matter for the apps? I think it's definitely worth discussing how we might address these same use-cases in FreeIPA v3. My thought was that we might want to implement custom views of LDAP based on the hostgroups to which a client belongs. I can see a lot of implementation difficulties with this, however. Alternate ideas are most welcome. ___ 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 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
