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] [PATCH] 881 don't log OTP in client install log
On Thu, 2011-09-22 at 11:55 -0400, Rob Crittenden wrote: Obfuscate the one-time password in the client installer log. rob NACK. You missed a case when OTP is interactively prompted (-W parameter is passed). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 879 ensure ssl socket is shut down
On Mon, 2011-09-19 at 17:32 -0400, Rob Crittenden wrote: httplib makes a copy of the nss file descriptor but doesn't close it when the response code != 200 so we need to close it ourselves. rob ACK. I saw that jdennis agreed with this solution in Trac comments as well. 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] 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] FreeIPA and per-machine views
On Thu, 2011-09-22 at 21:55 -0400, Dmitri Pal wrote: 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. I was thinking on similar lines, but rather than have an extra option on the client, it would be better if we could configure the IPA server so that SSSD client could request the set of bases that it needs to use. For example, right now we're able to auto-detect our standard search base by asking the RootDSE for the namingContexts attribute. What we could do on the IPA server side is, in the cn=config tree or somewhere more appropriate, add a record that provides ordered naming contexts for each client (or hostgroup). Something like: cn=override1,cn=searchbases,cn=config memberOf: cn=hostgroup1,cn=hostgroups,... memberOf: cn=hostA,cn=hosts,... searchBaseList: search_base?scope?filter priority: 100 Then at online connection, SSSD could issue a search request in the cn=searchbases tree for any override specification for which this host or its hostgroups are a member. They would order by priority and then include the standard search base as the last in the list. There are two advantages to this approach: 1) It can take advantage of the same multiple search base work I'm doing for standard LDAP 2) It's centrally-managed and can be updated on any going_online event on the client. The alternative however is to create and support group aliases and use group aliases as names. But before we go into all of this
Re: [Freeipa-devel] [PATCH] 281 Fixed problem on combobox with search limit.
On 09/20/2011 11:18 PM, Endi Sukma Dewata wrote: The IPA.combobox_widget has been modified such that if the drop-down list doesn't contain the stored value (due to search limit) it will not select anything from the list. The widget has also been modified not to select the value that matches the filter automatically because that might not be the user's intention. Ticket #1819 ACK -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 881 don't log OTP in client install log
Martin Kosek wrote: On Thu, 2011-09-22 at 11:55 -0400, Rob Crittenden wrote: Obfuscate the one-time password in the client installer log. rob NACK. You missed a case when OTP is interactively prompted (-W parameter is passed). Martin Nice catch, updated patch rob From b0a9c855899dea0b6ebaa75543093d76d7c41129 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 |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 44c2f5fbc40c9f3a6d5f4378d91e048b63bf0e7a..eab35674a40f309f59034d6962457b3f5a225d8b 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,9 +928,11 @@ 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: +nolog = (options.password,) if options.unattended: print Password must be provided in non-interactive mode return CLIENT_INSTALL_ERROR @@ -940,7 +941,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] FreeIPA and per-machine views
On Thu, 2011-09-22 at 21:55 -0400, Dmitri Pal wrote: 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. I think we can have overrides for users too, but like for group I am absolutely against them being normal objects. Overrides should be clearly identifiable as such and should generally not be usable as regular users/groups in software that is not explicitly built to understand them, otherwise chaos will ensue. 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] 881 don't log OTP in client install log
On Fri, 2011-09-23 at 09:07 -0400, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-09-22 at 11:55 -0400, Rob Crittenden wrote: Obfuscate the one-time password in the client installer log. rob NACK. You missed a case when OTP is interactively prompted (-W parameter is passed). Martin Nice catch, updated patch rob Umh, nice try. I think you wanted to read nolog password from getpass.getpass output and not options.password. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 6 Add admin SIDs
Hi, this patch extends the ipa-adtrust-install utility by adding SIDs to the IPA admin user and the admins group. bye, Sumit From 9d24a20c8d81440398f38e71efd024320b20577d Mon Sep 17 00:00:00 2001 From: Sumit Bose sb...@redhat.com Date: Fri, 23 Sep 2011 15:11:23 +0200 Subject: [PATCH] Add admin SIDs The admin SID DOMAIN-SID-500 will be assigned to the IPA admin user and the admin group SID DOMAIN-SID-512 to the admins group. --- ipaserver/install/adtrustinstance.py | 62 ++--- 1 files changed, 56 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 1bd37d4eb1f93db6609f8c9a06ac02923e9db20b..f525d2d3861bab46b89594935d5e4003087e0b09 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -125,26 +125,72 @@ class ADTRUSTInstance(service.Service): sub_ids = struct.unpack(LLL, os.urandom(12)) return S-1-5-21-%d-%d-%d % (sub_ids[0], sub_ids[1], sub_ids[2]) +def __add_admin_sids(self): +admin_dn = uid=admin,cn=users,cn=accounts,%s % self.suffix +admin_group_dn = cn=admins,cn=groups,cn=accounts,%s % self.suffix + +try: +dom_entry = self.admin_conn.getEntry(self.smb_dom_dn, \ + ldap.SCOPE_BASE) +except errors.NotFound: +print Samba domain object not found +return + +dom_sid = dom_entry.getValue(sambaSID) +if not dom_sid: +print Samba domain object does not have a SID +return + +try: +admin_entry = self.admin_conn.getEntry(admin_dn, ldap.SCOPE_BASE) +except: +print IPA admin object not found +return + +try: +admin_group_entry = self.admin_conn.getEntry(admin_group_dn, \ + ldap.SCOPE_BASE) +except: +print IPA admin group object not found +return + +if admin_entry.getValue(sambaSID) or \ + admin_group_entry.getValue(sambaSID): +print Admin SID already set, nothing to do +return + +try: +self.admin_conn.modify_s(admin_dn, \ +[(ldap.MOD_ADD, objectclass, sambaSamAccount), \ + (ldap.MOD_ADD, sambaSID, self.dom_sid + -500)]) +except: +print Failed to modify IPA admin object + +try: +self.admin_conn.modify_s(admin_group_dn, \ +[(ldap.MOD_ADD, objectclass, sambaSidEntry), \ + (ldap.MOD_ADD, sambaSID, self.dom_sid + -512)]) +except: +print Failed to modify IPA admin group object + def __create_samba_domain_object(self): -trust_dn = cn=trusts,%s % self.suffix -smb_dom_dn = cn=ad,%s % trust_dn try: -self.admin_conn.getEntry(smb_dom_dn, ldap.SCOPE_BASE) +self.admin_conn.getEntry(self.smb_dom_dn, ldap.SCOPE_BASE) print Samba domain object already exists return except errors.NotFound: pass try: -self.admin_conn.getEntry(trust_dn, ldap.SCOPE_BASE) +self.admin_conn.getEntry(self.trust_dn, ldap.SCOPE_BASE) except errors.NotFound: -entry = ipaldap.Entry(trust_dn) +entry = ipaldap.Entry(self.trust_dn) entry.setValues(objectclass, [nsContainer]) entry.setValues(cn, trusts) self.admin_conn.add_s(entry) -entry = ipaldap.Entry(smb_dom_dn) +entry = ipaldap.Entry(self.smb_dom_dn) entry.setValues(objectclass, [sambaDomain, nsContainer]) entry.setValues(cn, ad) entry.setValues(sambaDomainName, self.netbios_name) @@ -247,6 +293,9 @@ class ADTRUSTInstance(service.Service): self.smb_dn = uid=samba,cn=sysaccounts,cn=etc,%s % self.suffix self.smb_dn_pwd = ipautil.ipa_generate_password() +self.trust_dn = cn=trusts,%s % self.suffix +self.smb_dom_dn = cn=ad,%s % self.trust_dn + self.__setup_sub_dict() @@ -261,6 +310,7 @@ class ADTRUSTInstance(service.Service): self.step(writing samba config file, self.__write_smb_conf) self.step(setting password for the samba user, self.__set_smb_ldap_password) self.step(Adding cifs Kerberos principal, self.__setup_principal) +self.step(Adding admin(group) SIDs, self.__add_admin_sids) self.step(configuring smbd to start on boot, self.__enable) self.step(starting smbd, self.__start) -- 1.7.6 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 271 Modified dialog to use sections.
On 9/23/2011 4:31 AM, Petr Vobornik wrote:
On 09/22/2011 09:15 PM, Endi Sukma Dewata wrote:
I've split the patch into two: 4a is the revised original patch,
ACK
4b is the additional cleanup for the undo.
you missed: dns.js:562 and host.js:406 . Beside this it's OK.
Fixed. We actually don't need the custom widget for force anymore, but
this can be cleaned up again later.
Pushed to master and ipa-2-1.
--
Endi S. Dewata
From 3812066719901993737b5b7ae000414f1dc8300e Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Thu, 22 Sep 2011 11:44:41 -0500
Subject: [PATCH] Removed undo flags from dialog field specs.
Since the undo flag is now automatically set to false in dialogs,
it's no longer necessary to specify it in the field specs.
Ticket #1394
---
install/ui/aci.js | 40 ++--
install/ui/automount.js | 19 +--
install/ui/dns.js | 29 -
install/ui/entitle.js | 16 +---
install/ui/group.js |1 -
install/ui/host.js | 16 +---
install/ui/policy.js|3 +--
install/ui/service.js |9 +++--
install/ui/sudo.js |3 +--
install/ui/user.js | 11 +--
10 files changed, 51 insertions(+), 96 deletions(-)
diff --git a/install/ui/aci.js b/install/ui/aci.js
index 13fbc7d139e5ef69f6974b9b4d32b160a2eeebc5..929e13d4b3af3303c32d2122d8f2147afb99b185 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -69,22 +69,18 @@ IPA.entity_factories.permission = function() {
{
name: 'general',
fields: [
-{
-name: 'cn',
-undo: false
-},
+'cn',
{
factory: IPA.rights_widget,
name: 'permissions',
-join: true, undo: false
+join: true
}
]
},
{
factory: IPA.target_section,
name: 'target',
-label: IPA.messages.objects.permission.target,
-undo: false
+label: IPA.messages.objects.permission.target
}
]
}).
@@ -173,8 +169,7 @@ IPA.entity_factories.selfservice = function() {
'aciname',
{factory:IPA.attributes_widget,
object_type:'user',
- name:'attrs',
- undo: false
+ name:'attrs'
}]
}).
build();
@@ -218,21 +213,20 @@ IPA.entity_factories.delegation = function() {
factory: IPA.entity_select_widget,
name: 'group',
other_entity: 'group',
-other_field: 'cn',
-undo: false
+other_field: 'cn'
},
{
factory: IPA.entity_select_widget,
name: 'memberof',
other_entity: 'group',
other_field: 'cn',
-join: true,
-undo: false
+join: true
},
{
-factory:IPA.attributes_widget,
-name: 'attrs', object_type: 'user',
-join: true, undo: false
+factory: IPA.attributes_widget,
+name: 'attrs',
+object_type: 'user',
+join: true
}]
}).
build();
@@ -400,7 +394,6 @@ IPA.target_section = function(spec) {
spec = spec || {};
var that = IPA.details_section(spec);
-that.undo = typeof spec.undo == 'undefined' ? true : spec.undo;
var target_types = [
{
@@ -504,31 +497,26 @@ IPA.target_section = function(spec) {
var init = function() {
that.filter_text = IPA.text_widget({
name: 'filter',
-undo: that.undo,
entity: spec.entity
});
that.subtree_textarea = IPA.textarea_widget({
entity: spec.entity,
name: 'subtree',
-cols: 30, rows: 1,
-undo: that.undo
+cols: 30, rows: 1
});
that.group_select = IPA.entity_select_widget({
entity: spec.entity,
name: 'targetgroup',
other_entity: 'group',
-other_field: 'cn',
-undo: that.undo
+other_field: 'cn'
});
that.type_select = IPA.select_widget({
entity: spec.entity,
-name: 'type',
-undo: that.undo
+name: 'type'
});
that.attribute_table =
Re: [Freeipa-devel] [PATCH] 281 Fixed problem on combobox with search limit.
On 9/23/2011 7:46 AM, Petr Vobornik wrote: On 09/20/2011 11:18 PM, Endi Sukma Dewata wrote: The IPA.combobox_widget has been modified such that if the drop-down list doesn't contain the stored value (due to search limit) it will not select anything from the list. The widget has also been modified not to select the value that matches the filter automatically because that might not be the user's intention. Ticket #1819 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] 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
[Freeipa-devel] [PATCH] 017 Fixed: Column header for attributes table should be full, width
https://fedorahosted.org/freeipa/ticket/1841
The column header for the attributes table (IPA.attributes_widget) does
not cover the entire width of the table. This problem appears in the
adder dialog and details page for permissions, self-service permissions,
and delegations.
Note:
* span element is added in order to set padding for cell text
because parent th element has css-hacked width. Tbody's use of
overflow is the cause of used hacks.
--
Petr Vobornik
From 6d5429191f5f530d5aae6b689a2326404ef4f126 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 23 Sep 2011 17:49:46 +0200
Subject: [PATCH] Fixed: Column header for attributes table should be full
width
https://fedorahosted.org/freeipa/ticket/1841
The column header for the attributes table (IPA.attributes_widget) does not cover the entire width of the table. This problem appears in the adder dialog and details page for permissions, self-service permissions, and delegations.
Note:
* span element is added in order to set padding for cell text because parent th element has css-hacked width. Tbody's use of overflow is the cause of used hacks.
---
install/ui/aci.js | 17 ++---
install/ui/ipa.css | 19 ---
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/install/ui/aci.js b/install/ui/aci.js
index 929e13d4b3af3303c32d2122d8f2147afb99b185..868b51ebf7efa4eb3cf67f8acb8fade48e906c05 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -257,25 +257,28 @@ IPA.attributes_widget = function(spec) {
var tr = $('tr/tr').appendTo($('thead', that.table));
tr.append($('th/', {
-style:height:2em; vertical-align:bottom;,
-html:$('input/',{
+'class': 'aci-select-column',
+html: $('input/', {
type: checkbox,
-click: function(){
+click: function() {
$('.aci-attribute', that.table).
attr('checked', $(this).attr('checked'));
that.set_dirty(that.test_dirty());
}
})
-})).append($('th/', {
-'class': 'aci-attribute-column',
-html: IPA.messages.objects.aci.attribute
}));
+var th = $('th/', {
+'class': 'aci-attribute-column'
+}).appendTo(tr);
+$('span/', {
+html: IPA.messages.objects.aci.attribute
+}).appendTo(th);
if (that.undo) {
that.create_undo(container);
}
-if (that.object_type){
+if (that.object_type) {
that.populate(that.object_type);
}
};
diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index 7876da355edcd8a160c51bdcb1b2db2798192b0f..6d6ab9c84b61b6b0bcc2a7c3400f9bb6ea77d391 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -969,7 +969,9 @@ span.main-separator{
}
-.aci-attribute-table thead{
+.aci-attribute-table thead,
+.aci-attribute-table thead tr,
+.aci-attribute-table thead th{
display: block;
}
@@ -982,12 +984,23 @@ span.main-separator{
display: block;
}
+.aci-attribute-table th.aci-select-column{
+height:2em;
+float: left;
+}
+
.aci-attribute-table th.aci-attribute-column{
-width: 20.5em;
+height:2em;
+width: auto;
+line-height: 2em;
+}
+
+.aci-attribute-table th.aci-attribute-column span{
+padding: 0 0.5em;
}
.entity-views{
- list-style-type:none;
+list-style-type:none;
}
.entity-views li {
--
1.7.6
___
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
[Freeipa-devel] [PATCH] 883 display failed service/service group members in hbacrule membership
When trying to add/remove services and service groups as members of an
hbacrule failures were not being displayed due to a missing label.
Tickets show how to duplicate and test patch.
rob
From a015ccfcb5a22677cb648ba61578d4e2f1a2e2e1 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 23 Sep 2011 16:39:30 -0400
Subject: [PATCH] Include failed service and service groups in hbac rule
management
hbacrule-service-add/remove failures weren't being displayed because
no label was defined.
https://fedorahosted.org/freeipa/ticket/1863
https://fedorahosted.org/freeipa/ticket/1865
---
ipalib/plugins/baseldap.py |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index bd4f083..11cd72c 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -159,6 +159,9 @@ global_output_params = (
Str('memberuser',
label=_('Failed users/groups'),
),
+Str('memberservice',
+label=_('Failed service/service groups'),
+),
Str('managedby',
label=_('Failed managedby'),
),
--
1.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
