[Freeipa-devel] [PATCH] build tweaks
The attached patch modifies autogen.sh so that it runs autoreconf with the -f flag, too, so that a source rpm package built on an F14 system will successfully build on a system which has older autotools versions. It also tells automake to run in its 'foreign' mode and dispenses with some workarounds for when we were running it in 'gnu' mode. Nalin >From 5bb5c58a0ac713069fbd44cb8b7906485648de13 Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Wed, 24 Nov 2010 17:39:46 -0500 Subject: [PATCH] build tweaks - use automake's foreign mode, avoid creating empty files to satisfy gnu mode - run autoreconf -f to ensure that everything matches --- autogen.sh | 13 + contrib/RHEL4/configure.ac |2 +- daemons/configure.ac |2 +- install/configure.ac |2 +- ipa-client/configure.ac|2 +- ipa.spec.in|4 6 files changed, 5 insertions(+), 20 deletions(-) diff --git a/autogen.sh b/autogen.sh index 99b4805..5eab4a4 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,14 +1,3 @@ #!/bin/sh - -# automake demands these files exist when run in gnu mode which is the default, -# automake can be run in foreign mode to avoid failing on the absence of these -# files, but unfortunately there is no way to pass the --foreign flag to -# automake when run from autoreconf. -for f in NEWS README AUTHORS ChangeLog; do -if [ ! -e $f ]; then -touch $f -fi -done - -autoreconf -i +autoreconf -i -f ./configure ${1+"$@"} diff --git a/contrib/RHEL4/configure.ac b/contrib/RHEL4/configure.ac index 83676a3..1fd3fd2 100644 --- a/contrib/RHEL4/configure.ac +++ b/contrib/RHEL4/configure.ac @@ -3,7 +3,7 @@ AC_INIT([ipa-client], [0.99.0], [http://www.freeipa.org/]) -AM_INIT_AUTOMAKE +AM_INIT_AUTOMAKE([foreign]) AC_SUBST(VERSION) diff --git a/daemons/configure.ac b/daemons/configure.ac index da86557..d959f98 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -6,7 +6,7 @@ AC_INIT([ipa-server], AC_CONFIG_HEADERS([config.h]) -AM_INIT_AUTOMAKE +AM_INIT_AUTOMAKE([foreign]) AM_MAINTAINER_MODE AC_PROG_CC diff --git a/install/configure.ac b/install/configure.ac index 5cdfb79..2424ef2 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -7,7 +7,7 @@ AC_INIT([ipa-server], #AC_CONFIG_SRCDIR([ipaserver/ipaldap.py]) AC_CONFIG_HEADERS([config.h]) -AM_INIT_AUTOMAKE +AM_INIT_AUTOMAKE([foreign]) AM_MAINTAINER_MODE #AC_PROG_CC diff --git a/ipa-client/configure.ac b/ipa-client/configure.ac index 95becd3..75544ae 100644 --- a/ipa-client/configure.ac +++ b/ipa-client/configure.ac @@ -9,7 +9,7 @@ AC_PROG_LIBTOOL AC_CONFIG_SRCDIR([ipaclient/__init__.py]) AC_CONFIG_HEADERS([config.h]) -AM_INIT_AUTOMAKE +AM_INIT_AUTOMAKE([foreign]) AM_MAINTAINER_MODE diff --git a/ipa.spec.in b/ipa.spec.in index b43aa8e..775c52e 100644 --- a/ipa.spec.in +++ b/ipa.spec.in @@ -223,10 +223,6 @@ administering radius authentication settings in IPA. export CFLAGS="$CFLAGS %{optflags}" export CPPFLAGS="$CPPFLAGS %{optflags}" make version-update -%if ! %{ONLY_CLIENT} -touch daemons/NEWS daemons/README daemons/AUTHORS daemons/ChangeLog -touch install/NEWS install/README install/AUTHORS install/ChangeLog -%endif cd ipa-client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd .. %if ! %{ONLY_CLIENT} cd daemons; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd .. -- 1.7.3.2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make the migration plugin more configurable
Jakub Hrozek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 04:21 PM, Jakub Hrozek wrote: On 11/22/2010 04:16 PM, Jakub Hrozek wrote: The code handles it (I just ran a quick test with --schema=RFC2307bis). It just iterates through all members of a group -- be it user member of group member, it's just a DN for the plugin. Jakub Sorry, I found another bug in the plugin. I'll send a new patch shortly, so please don't waste time reviewing this one. New patch is attached. It fixes two more bugs of the original plugin - determines whether a group member is a user or a nested group by checking the DN, not just the RDN attribute name and does not hardcode primary keys. Will this blow up in convert_members_rfc2307bis() if a member isn't contained in the users and groups containers? Should there be a failsafe to skip over things that don't match (along with appropriate reporting)? Or if one of users or groups search bases isn't provided? It definitely doesn't like this: # ipa migrate-ds --user-container='' --group-container='cn=groups,cn=accounts' ldap://ds.example.com:389 When passed the right set of options it does seem to do the right thing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] PATCH for whoami
Pushed under the 1 liner rule From 16b935169c556135dcab2908d102a884f803fda4 Mon Sep 17 00:00:00 2001 From: Adam Young Date: Wed, 24 Nov 2010 16:36:36 -0500 Subject: [PATCH] whoami fix recent changes to the scope mechanism weren't propigated to the whoami call --- ipalib/plugins/user.py |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 5b6e03b66805de807f4b6007a41f732db7a3c8bc..64120fd2bcc6cad49785402730858d0a3294cb42 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -253,8 +253,9 @@ class user_find(LDAPSearch): ) def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): if options.get('whoami'): -return "(&(objectclass=posixaccount)(krbprincipalname=%s))"%\ -getattr(context, 'principal') +return ("(&(objectclass=posixaccount)(krbprincipalname=%s))"%\ +getattr(context, 'principal'), base_dn, scope) + return (filter, base_dn, scope) def post_callback(self, ldap, entries, truncated, *args, **options): -- 1.7.2.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] admiyo-0103-navigation-format
On 11/24/2010 1:02 PM, Adam Young wrote: ACK and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] admiyo-0102-action-panel-formatting
On 11/24/2010 10:51 AM, Adam Young wrote: ACK and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 619 more aci target docs
I added some more documentation and examples to the aci plugin on targets. ticket 310 rob >From f155f75ce44e53bb8e6122e0eea9c2e308c7ab36 Mon Sep 17 00:00:00 2001 From: Rob Crittenden Date: Wed, 24 Nov 2010 14:48:51 -0500 Subject: [PATCH] Add more information and examples on targets. ticket 310 --- ipalib/plugins/aci.py | 25 ++--- 1 files changed, 22 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/aci.py b/ipalib/plugins/aci.py index 14c354a..fd2d8f9 100644 --- a/ipalib/plugins/aci.py +++ b/ipalib/plugins/aci.py @@ -50,6 +50,15 @@ The target is a set of rules that define which LDAP objects are being targetted. This can include a list of attributes, an area of that LDAP tree or an LDAP filter. +The targets include: +- attrs: list of attributes affected +- type: an object type (user, group, host, service, etc) +- memberof: members of a group +- targetgroup: grant access to modify a specific group. This is primarily meant to be able to allow users to add/remove members of a specific group only. +- filter: A legal LDAP filter used to narrow the scope of the target. +- subtree: this is meant as a fail-safe for the type object. It is meant as a +way to apply to a type of object (e.g. user, group, host, etc). + The permissions define what the ACI is allowed to do, they are one or more of: 1. write - write one or more attributes @@ -77,12 +86,22 @@ EXAMPLES: Show the new ACI: ipa aci-show "Secretaries write addresses" - Add an ACI that allows members of the "addusers" taskgroup to add new users: - ipa aci-add --type=user --taskgroup=addusers --permissions=add "Add new users" + Add an ACI that allows members of the "addusers" permission to add new users: + ipa aci-add --type=user --permission=addusers --permissions=add "Add new users" - Add an ACI that lets members of the edotors manage members of the admins group: + Add an ACI that lets members of the editors manage members of the admins group: ipa aci-add --permissions=write --attrs=member --targetgroup=admins --group=editors "Editors manage admins" + Add an ACI that lets members of the admin group manage the street and zipcode of those in the editors group: + ipa aci-add --permissions=write --memberof=editors --group=admins --attrs=street,postalcode "admins edit address of editors" + + Add an ACI that lets the admins group manage the street and zipcode of those who work for the boss: + ipa aci-add --permissions=write --group=admins --attrs=street,postalcode --filter="(manager=uid=boss,cn=users,cn=accounts,dc=example,dc=com)" "Edit the address of those who work for the boss" + + Add an entirely new kind of record to IPA that isn't covered by any of the --type options: + ipa aci-add --permissions=add --subtree="cn=*,cn=orange,cn=accounts,dc=example,dc=com" --permission=editsamba "Add Orange Entries" + + The show command shows the raw 389-ds ACI. IMPORTANT: When modifying the target attributes of an existing ACI you -- 1.7.2.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
John Dennis wrote: > On 11/24/2010 02:16 PM, Simo Sorce wrote: >> That said I am starting thing that having a grammar that is powerful >> enough to express all possible combinations an admin can think of is >> not possible to get done right w/o making it extremely complicated. > > When the HBAC rules first came up over a year ago I pointed out how > similar the issue was to the recurrence rules in ical and caldav. I > also pointed out how the committees involved struggled to get this > right and not fall victim to excessive complexity. The truth is, it's > a hard problem, it's no surprise we discover we're struggling with it > too. > > I haven't been following the whole discussion here so maybe I'm off > base but I continue to wonder why we aren't looking at open standards > that address many of the issues raised here with respect to localized > time recurrence and which also happen to have open source > implementations for evaluating the rules expressed in the grammar. We looked at ical and caldev but the grammar for those looked excessively complex. We hoped that we can reduce it to just the part we need to actually reduce the amount of work and potential errors. -- 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] [PATCH]admiyo-0094-xhtml-to-html
On 11/17/2010 08:58 PM, Adam Young wrote: On 11/17/2010 05:20 PM, Endi Sukma Dewata wrote: On 11/17/2010 2:06 PM, Adam Young wrote: This patch doesn't apply, the index.html is already created in patch #92. OK. Didn't realize I had done that, though it was in another branch. The index.html file is in the right form, though, so all that really needs to happen is removing the xhtml file ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mai lman/listinfo/freeipa-devel 0094 withdrawn 0095 ACKed and pushed ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
On 11/24/2010 02:16 PM, Simo Sorce wrote: That said I am starting thing that having a grammar that is powerful enough to express all possible combinations an admin can think of is not possible to get done right w/o making it extremely complicated. When the HBAC rules first came up over a year ago I pointed out how similar the issue was to the recurrence rules in ical and caldav. I also pointed out how the committees involved struggled to get this right and not fall victim to excessive complexity. The truth is, it's a hard problem, it's no surprise we discover we're struggling with it too. I haven't been following the whole discussion here so maybe I'm off base but I continue to wonder why we aren't looking at open standards that address many of the issues raised here with respect to localized time recurrence and which also happen to have open source implementations for evaluating the rules expressed in the grammar. -- John Dennis 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] Host groups and netgroups
>If this proposal looks reasonable I will open a ticket. >JR will you be able to provide a patch that does all of this since this >is not exactly what we originally planned? Your premise makes a lot of sense. This is very promising news Dmitri. Let me consider how I would accommodate the patch, and get back to you early next week with an official answer on commitment. -- Thanks! -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
> I need to think a bit more but I think we may want to radically > simplify the grammar instead by splitting single rules (as seen in the > UI) in multiple values. And use additional attributes to aid the UI, > like having a displayTZ attribute that tells the UI what is the > preferred timezone to look at a rule. > > Simo. > > It seems that may be we really took a wrong approach here. Let us see what Steve and Adam would come up. -- 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] [PATCH] Add new version of DNS plugin: complete rework with baseldap + unit tests.
On 2010-11-24 16:21, Adam Young wrote: On 11/24/2010 03:46 AM, Pavel Zuna wrote: On 11/24/2010 03:26 AM, Adam Young wrote: On 11/23/2010 09:37 AM, Pavel Zuna wrote: Finally managed to rewrite the DNS plugin again. Sorry, it took so long, we had training in the office and I also had a nasty bug in baseldap.py I couldn't find. Anyway, this version has it all: - changes we agreed on meeting, the "resource" abstraction is gone and we now only have zones and records = adding new record automatically updates and existing entry or creates it if it wasn't there and deleting the last record deletes the whole entry - all of it transparent to the user - unit tests - ipa help documentation Fixes tickets: #36 #450 I also closed bug #654412. It has a new patch sequence number, because it depends on another patch with a higher number and didn't want to create forward dependencies. Depends on my patches number: 35 (will repost if needed) 38 (posted a while ago on freeipa-devel) Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I keep getting an error when doing simple things like install and ipa help: [ayo...@ipa freeipa]$ ./ipa help dns2 ipa: ERROR: AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipalib/cli.py", line 962, in run api.finalize() File "/home/ayoung/devel/freeipa/ipalib/plugable.py", line 615, in finalize p.instance.finalize() File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 724, in finalize self._create_param_namespace('args') File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 350, in _create_param_namespace sort=False File "/home/ayoung/devel/freeipa/ipalib/base.py", line 407, in __init__ (self.__class__.__name__, name, self.__map[name], member) AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) ipa: ERROR: an internal error has occurred That's because you need my patch number 35 for it to work... Pavel OK, with that change, the patch applies and works. I've tested: creating a zone Creating an a record Adding an a record entry to an existing entry (calling ipa dnsrecord-add a second time with just a different ip address) Adding an record. Deleting one and multiple records One thing that is a little counter intuitive is that you have to specify which records to delete: just running ipa dnsrecord-del ayoung.test.ipa.redhat.com hiphop doesn't delete all records with the A name of hiphop. I think this is the right behavior, but it should be better documented. Ok, I'm going to add a few lines about it in the docstring (ipa help). Maybe we should have an option to delete all records associated with a resource name. For example when someone is deleting a host from DNS and wants all of its records gone. Have to hold off on pushing it due to F14: python-netaddr Isn't in F14, so we are adding a new python package with this plugin, too. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Patches and Thunderbird
On Wed, 24 Nov 2010 09:51:51 -0500 Adam Young wrote: > Thunderbird formatting of patches: > > Thunderbird has a nasty habit of prepending a '>' character to the > patch, messing up the format. While it is trivial to edit the > patch by hand to remove it, the patch sender can help out by > configuring Thurnderbird this way: > > * In Thunderbird Preferences, > * go to the Advanced->General tab. > * Select "Config Editor" > * Search for mail.file_attach_binary and > * set this value to true > > I've added this to the patch format page. > > https://fedorahosted.org/freeipa/wiki/PatchFormat > > I'm making an effort to keep track of the different patches that are > out there and their status, so the more consistent we are, the easier > it is to do. > > Please make sure at least the patch number is in the title of the > email you send out. There are so many patches, that when someone > refers to their patch 86 it makes it much faster to go and find that > patch. FWIW it seem like thunderbird is not at fault here, but something in between (probably mailman). We will try to get it fixed so that people do not have to care about this at all and we do not have to provide instructions for the gazillion MUAs around there. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH]admiyo-0103-navigation-format
From d0dd106cbc247fb451cdb8f6c4c3d454d914dd38 Mon Sep 17 00:00:00 2001 From: Adam Young Date: Tue, 23 Nov 2010 16:32:17 -0500 Subject: [PATCH] navigation format UXD guidance to cleanup navigation. adjusts the tab font --- install/static/Mainnav-background.png | Bin 233 -> 180 bytes install/static/Subnav-background.png | Bin 187 -> 141 bytes install/static/ipa.css| 31 +-- install/static/ipalogo.png| Bin 12071 -> 2447 bytes install/static/webui.js |2 +- 5 files changed, 18 insertions(+), 15 deletions(-) diff --git a/install/static/Mainnav-background.png b/install/static/Mainnav-background.png index 908903dddb33a723521ac3c59fc16f9f9275083d..37a9dc6a5bf8b78bde141f26d557a578b0400a7f 100644 GIT binary patch delta 165 zcmV;W09ya)0ki>-...@vh0ssi2lr7bipbvxqnq*un;cVTj606}DLVr3vnZDD6+ zQe|Oed2z{QJOBUyR!KxbRCwB4j=>GUFbD&&^QhEsm&qI*Fssr6LUr>%VEYIe_nI`b zsBvBg-Muvd)Qr~AkveAx7hbZGYlg~tul=2QiSj6XGyMMa%O3N#+=*Ar9svdb!iNP2 Tfu(j60NkvXXu0mjf0_;LS delta 218 zcmdnO_>ysgczqrR69WT7=GAwBK#H+A$lZxy-8q?;Kn`1yx4R3F27;f?yX%1zXMsm# zF#`j)FbFd;%$g$s6l5>)^mS#w#VsHrBeU`0&z...@oivfb5q)pR6Abx|IB+nh|LNNE z;otpu$62(AuOC{^`Q^3h>&n89 zTfdyWa`kTh)}4=I*GV0b`8Q#I^>O)u...@%(<<5V=Q`Saz~?%#C>d2cjv?>bqz=?u_T N22WQ%mvv4FO#qTiRk#2E diff --git a/install/static/Subnav-background.png b/install/static/Subnav-background.png index d7dd26bf1c0001103301835f2d4ec9866de7420f..c1baebffe6f1fd549e7289151a4fbfbe327e2470 100644 GIT binary patch delta 112 zcmdnZ*vmLUB~!A*HKHUqKdq!Zu_%?nF(p4krlzeif+dxxh8...@mnkd0|SG;r;B4q z#jPYiz5c|y!~YvRBV1;5cD7FJd}z-s%*_1OKv`M&^85JxGwls)SU3zAq>plDZhZB} Q9H^DS)78&qol`;+00y8a(*OVf delta 159 zcmeBW+|4*arJk`k$lZxy-8q?;3=9lxn#5=*49x14...@gd9?svi14-?iy0wwg+z8+ zVb&Z8pdfpRr>`sfEpARRB{t>D*Ovl?tUX;ELpZK4J-U(ifC0}Dhey_bcbsFpc}4j| z>uiZYu3iBqcB6OR4bSGCQlGkf?PiugNjlS?a=ErjJbHV%_78)o-hla!76...@o1ta JS?83{1OVuWHlzRm diff --git a/install/static/ipa.css b/install/static/ipa.css index b7654be00ea7f84549eda78d9569b75c2bf53bbf..63d8ef72ea14d0a2268a8e885d595fcec4e46494 100644 --- a/install/static/ipa.css +++ b/install/static/ipa.css @@ -13,15 +13,12 @@ body{ margin: 0; } - - .input_link {padding: .4em 1em .4em 1.5em;text-decoration: none;position: relative; cursor: pointer; } .input_link span.ui-icon {margin: 0 0.4em 0 0;position: absolute;left: .2em;top: 50%;margin-top: -8px;} /* Header */ div.header { -background-image: url(header_background.png); -height: 3.5em; +background-color:#0C3B00; width: 100%; } @@ -45,16 +42,18 @@ div.header span.header-logo { div.header span.header-logo a img { border: 0; -height: 3em; } div.header span.header-loggedinas { +width: 960px; color: #fff; -float: right; -line-height: 35px; -padding-right: 10px; +align: right; +padding-left: 600px; +padding-bottom: 0; } + + /* Navigation */ div.tabs { overflow: auto; @@ -186,7 +185,7 @@ span.attrhint { /*Navigation */ .tabs1 .ui-tabs-nav{ -padding-left: 3em; +padding-left: 5.5em; padding-top: 2em; margin: 0; border: none; @@ -203,7 +202,7 @@ span.attrhint { } .tabs1 .ui-tabs-nav li { -padding: 0.5em 0; + # padding: 0.5em 0; background-image: url(Mainnav-offtab.png); margin: 0; border-width: 0; @@ -212,17 +211,19 @@ span.attrhint { } .tabs1 .ui-tabs-nav li.ui-tabs-selected { -#padding: 0.5em 0; +padding: 0 0; background-image: url(Mainnav-ontab.png); text-align: center; margin: 0; } .tabs1 .ui-tabs-nav li a{ -width:10em; +width:5em; +padding: 0.2em 0; color: #7E7E7E; margin: 0 auto; text-align:center; +font-size:2em; } @@ -242,7 +243,7 @@ span.attrhint { } .tabs2 .ui-tabs-nav { -padding: 0.3em 6em 0 6em; +padding: 0.3em 6em 0 9em; margin: 0px; height: 2.5em; background-image: url(Subnav-background.png); @@ -264,10 +265,12 @@ span.attrhint { .tabs2 .ui-tabs-nav li a{ +width:auto; +padding: 0.2em 0.4em ; -moz-border-radius: 2em; border-radius: 2em; -background-image: url(Subnav-background.png); color: white; +font-size: 1em; } .tabs2 .ui-tabs-nav li > a:link, span.main-nav-off > a:visited{ diff --git a/install/static/ipalogo.png b/install/static/ipalogo.png index defa78cfdfe36f68bcf856b2dbcb52ecb5452d6b..7027e45f873fcecf7cd94d6b45e7ce21c028e091 100644 GIT binary patch delta 2435 zcmV-}34HdaUXK$YiBL{Q4GJ0xDNk~Le0001?R2nGNE02Bc4rI8^ge+e;3 zL_t(|+U%Qaa1+-R$N&4#t|VKsjF5R4zj(y14XIrMB*rbKBxxZb&}sXjon#=i6Q+}< zA^p@#!km...@5pav2hbr9x~l(Ue?Mh?W=c{ zb=a!15s#8iy=Q#1tE;Q)yv~fwf6q...@xnep!xp>jV4YRTg`CQ*k)w<|Fg`pRH!oT zXIr?qI&0tIbKiOCZv%(wkMutK)b_dpz5Oc2vCOjnFzO0QsKdqFQd-Xc^7p&fgk<-_ zy}`&g...@q`fbv&Sr9cb0hKPv5_?Vi)O`Ag)|V6)h#SEK>-...@j;pQaXWXvf4f$or~RNW z7+Pwl+E7{~z?DT~I5dj33l#iAvr*(LJiv{#{dCiY)u+k(q=`bb1)*hEg77otduGR< z?uoH8e%K$5*TkZonBhK;JD2(}nutM?qHyOh5Xt_T_6XiSQ36NS;_w`=xc!5-
[Freeipa-devel] Host groups and netgroups
Hello, It is well known that with IPA we want to try to move people from the netgroups to host groups but many companies currently use netgroups as hostgroups. To simplify migration I suggest that we by default always create a managed "nisnetgroup" entry that would map 1-1 to the host group using managed entry plugin. The logic would work the following way: 1) When the host group is created the netgroup also will be created with the same name and memberHost attribute pointing to the DN of the newly created host group 2) The deletion of the host group will automatically remove managed netgroup 3) The rename of the host group (if allowed) should cause the managed group to be renamed too. In the UI/CLI we will filter out managed netgroups in all cases related to identity part of the server (list of netgroups, users members of the netgroup, hosts members of netgroup, ect.). The netgroups will be available only in the special cases like SUDO plugin. The work will consist of: 1) Defining the managed entry plugin config for this case 2) Adding this configuration to the installation sequence 3) Updating netgroup searches to filter out managed entries 4) Allow all netgroups in SUDO plugin (I think this is already the case). If this proposal looks reasonable I will open a ticket. JR will you be able to provide a patch that does all of this since this is not exactly what we originally planned? -- 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] Other issues with HBAC calendar
On Wed, 24 Nov 2010 13:12:02 -0500 Dmitri Pal wrote: > Simo Sorce wrote: > > On Wed, 24 Nov 2010 11:26:05 -0500 > > Dmitri Pal wrote: > > > > > >> Steven, please think about the case when the rule needs to be > >> edited in UI and it has some value for DD - say 1. > >> What you display in UI then? If you do not allow to enter days and > >> you not allow more than 24 hours in the hour field you will fail to > >> translate the rule to the proposed UI. > >> The only option would be to show the raw rule in this case. IMO > >> this does not seem like the best option to me. > >> > > > > May not be the best but it is perfectly reasonable. > > > > > >> I think the DD is redundant and other means should be used to > >> schedule windows bigger than 2 days however the HH should IMO > >> allow 1-48 ours to allow specifying a week end outage like: > >> from 1AM Sat to 11PM Sun. If it is more than 2 days it is > >> reasonable to ask to split the rule into several slices. > >> > > > > I think this is not reasonable at all, it is an arbitrary limit due > > to the "current" thinking around the UI, if you change mind about > > the UI tomorrow, you will be left with the constraint in the > > grammar. This is just backwards. > > > > Simo. > > > > > Keeping in mind that we have just one shot at it, it is unreasonable > to think that the limitations that the UI imposes will ever go away. They changed many times since we started and will keep changing in time, I have no doubt about that. > Effectively what you and Steven say is that the grammar should dictate > the UI. It is the wrong approach. As well as the vice versa. The UI > should not dictate the grammar. No, what we say is that the UI is the flexible actor in this dram, the grammar is not flexible. The worst case for the UI is that it may have to display an ugly rule in raw grammar. The worst case for the grammar is that you cannot express a rule, and have to change it. > However the grammar also should not have constructs that would never > be expressed in UI because they are already identified as unusable. The grammar needs to be flaxible in what can be represented, the UI then can choose to allow only a subset to be set. The UI drives the game, the cases where an admin will try to change something at a low level via direct ldap calls is going to be rare, and in those cases the UI can very well degrade to a less than ideal mode and show raw rules, with the option to wipe them out and let the admin replace them with UI-friendly rules. > In other words the UI can be subset of what grammar supports but > all the options that grammar supports should be potentially > implementable in UI and usable. Everything is potentially implementable. > If the they never can be implemented in UI in usable way they > should not be in grammar. Given that in the worst case you show a rule by simply describing it in pseudo-natural language I think the UI has no real limits except the limits set forth by the specific implementation. That said I am starting thing that having a grammar that is powerful enough to express all possible combinations an admin can think of is not possible to get done right w/o making it extremely complicated. I need to think a bit more but I think we may want to radically simplify the grammar instead by splitting single rules (as seen in the UI) in multiple values. And use additional attributes to aid the UI, like having a displayTZ attribute that tells the UI what is the preferred timezone to look at a rule. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] admiyo-0103-navigation-format
From d0dd106cbc247fb451cdb8f6c4c3d454d914dd38 Mon Sep 17 00:00:00 2001 From: Adam Young Date: Tue, 23 Nov 2010 16:32:17 -0500 Subject: [PATCH] navigation format UXD guidance to cleanup navigation. adjusts the tab font --- install/static/Mainnav-background.png | Bin 233 -> 180 bytes install/static/Subnav-background.png | Bin 187 -> 141 bytes install/static/ipa.css| 31 +-- install/static/ipalogo.png| Bin 12071 -> 2447 bytes install/static/webui.js |2 +- 5 files changed, 18 insertions(+), 15 deletions(-) diff --git a/install/static/Mainnav-background.png b/install/static/Mainnav-background.png index 908903dddb33a723521ac3c59fc16f9f9275083d..37a9dc6a5bf8b78bde141f26d557a578b0400a7f 100644 GIT binary patch delta 165 zcmV;W09ya)0ki>-...@vh0ssi2lr7bipbvxqnq*un;cVTj606}DLVr3vnZDD6+ zQe|Oed2z{QJOBUyR!KxbRCwB4j=>GUFbD&&^QhEsm&qI*Fssr6LUr>%VEYIe_nI`b zsBvBg-Muvd)Qr~AkveAx7hbZGYlg~tul=2QiSj6XGyMMa%O3N#+=*Ar9svdb!iNP2 Tfu(j60NkvXXu0mjf0_;LS delta 218 zcmdnO_>ysgczqrR69WT7=GAwBK#H+A$lZxy-8q?;Kn`1yx4R3F27;f?yX%1zXMsm# zF#`j)FbFd;%$g$s6l5>)^mS#w#VsHrBeU`0&z...@oivfb5q)pR6Abx|IB+nh|LNNE z;otpu$62(AuOC{^`Q^3h>&n89 zTfdyWa`kTh)}4=I*GV0b`8Q#I^>O)u...@%(<<5V=Q`Saz~?%#C>d2cjv?>bqz=?u_T N22WQ%mvv4FO#qTiRk#2E diff --git a/install/static/Subnav-background.png b/install/static/Subnav-background.png index d7dd26bf1c0001103301835f2d4ec9866de7420f..c1baebffe6f1fd549e7289151a4fbfbe327e2470 100644 GIT binary patch delta 112 zcmdnZ*vmLUB~!A*HKHUqKdq!Zu_%?nF(p4krlzeif+dxxh8...@mnkd0|SG;r;B4q z#jPYiz5c|y!~YvRBV1;5cD7FJd}z-s%*_1OKv`M&^85JxGwls)SU3zAq>plDZhZB} Q9H^DS)78&qol`;+00y8a(*OVf delta 159 zcmeBW+|4*arJk`k$lZxy-8q?;3=9lxn#5=*49x14...@gd9?svi14-?iy0wwg+z8+ zVb&Z8pdfpRr>`sfEpARRB{t>D*Ovl?tUX;ELpZK4J-U(ifC0}Dhey_bcbsFpc}4j| z>uiZYu3iBqcB6OR4bSGCQlGkf?PiugNjlS?a=ErjJbHV%_78)o-hla!76...@o1ta JS?83{1OVuWHlzRm diff --git a/install/static/ipa.css b/install/static/ipa.css index b7654be00ea7f84549eda78d9569b75c2bf53bbf..63d8ef72ea14d0a2268a8e885d595fcec4e46494 100644 --- a/install/static/ipa.css +++ b/install/static/ipa.css @@ -13,15 +13,12 @@ body{ margin: 0; } - - .input_link {padding: .4em 1em .4em 1.5em;text-decoration: none;position: relative; cursor: pointer; } .input_link span.ui-icon {margin: 0 0.4em 0 0;position: absolute;left: .2em;top: 50%;margin-top: -8px;} /* Header */ div.header { -background-image: url(header_background.png); -height: 3.5em; +background-color:#0C3B00; width: 100%; } @@ -45,16 +42,18 @@ div.header span.header-logo { div.header span.header-logo a img { border: 0; -height: 3em; } div.header span.header-loggedinas { +width: 960px; color: #fff; -float: right; -line-height: 35px; -padding-right: 10px; +align: right; +padding-left: 600px; +padding-bottom: 0; } + + /* Navigation */ div.tabs { overflow: auto; @@ -186,7 +185,7 @@ span.attrhint { /*Navigation */ .tabs1 .ui-tabs-nav{ -padding-left: 3em; +padding-left: 5.5em; padding-top: 2em; margin: 0; border: none; @@ -203,7 +202,7 @@ span.attrhint { } .tabs1 .ui-tabs-nav li { -padding: 0.5em 0; + # padding: 0.5em 0; background-image: url(Mainnav-offtab.png); margin: 0; border-width: 0; @@ -212,17 +211,19 @@ span.attrhint { } .tabs1 .ui-tabs-nav li.ui-tabs-selected { -#padding: 0.5em 0; +padding: 0 0; background-image: url(Mainnav-ontab.png); text-align: center; margin: 0; } .tabs1 .ui-tabs-nav li a{ -width:10em; +width:5em; +padding: 0.2em 0; color: #7E7E7E; margin: 0 auto; text-align:center; +font-size:2em; } @@ -242,7 +243,7 @@ span.attrhint { } .tabs2 .ui-tabs-nav { -padding: 0.3em 6em 0 6em; +padding: 0.3em 6em 0 9em; margin: 0px; height: 2.5em; background-image: url(Subnav-background.png); @@ -264,10 +265,12 @@ span.attrhint { .tabs2 .ui-tabs-nav li a{ +width:auto; +padding: 0.2em 0.4em ; -moz-border-radius: 2em; border-radius: 2em; -background-image: url(Subnav-background.png); color: white; +font-size: 1em; } .tabs2 .ui-tabs-nav li > a:link, span.main-nav-off > a:visited{ diff --git a/install/static/ipalogo.png b/install/static/ipalogo.png index defa78cfdfe36f68bcf856b2dbcb52ecb5452d6b..7027e45f873fcecf7cd94d6b45e7ce21c028e091 100644 GIT binary patch delta 2435 zcmV-}34HdaUXK$YiBL{Q4GJ0xDNk~Le0001?R2nGNE02Bc4rI8^ge+e;3 zL_t(|+U%Qaa1+-R$N&4#t|VKsjF5R4zj(y14XIrMB*rbKBxxZb&}sXjon#=i6Q+}< zA^p@#!km...@5pav2hbr9x~l(Ue?Mh?W=c{ zb=a!15s#8iy=Q#1tE;Q)yv~fwf6q...@xnep!xp>jV4YRTg`CQ*k)w<|Fg`pRH!oT zXIr?qI&0tIbKiOCZv%(wkMutK)b_dpz5Oc2vCOjnFzO0QsKdqFQd-Xc^7p&fgk<-_ zy}`&g...@q`fbv&Sr9cb0hKPv5_?Vi)O`Ag)|V6)h#SEK>-...@j;pQaXWXvf4f$or~RNW z7+Pwl+E7{~z?DT~I5dj33l#iAvr*(LJiv{#{dCiY)u+k(q=`bb1)*hEg77otduGR< z?uoH8e%K$5*TkZonBhK;JD2(}nutM?qHyOh5Xt_T_6XiSQ36NS;_w`=xc!5-
Re: [Freeipa-devel] Where we are with SUDO?
JR Aquino wrote: > Progress! > > Ok, here is the latest data from the lab. > > The compat translation is almost there!!! > > * The sudoers container has correctly been moved out to the top of the > tree. I think it only needs 1 small final edit, the sudo ldap default is > to look for: ou=sudoers, rather than what is currently "cn=sudoers" > > Does this matter because the SUDO clients in your deployment look for "ou" rather than "cn" or it is a general convention? > * sudoUser correctly translates to a % > * sudoCommand: correctly translates to the individual members of the > ipaSudoCmdGroup > * sudoHost: is incorrectly enumerating the individual members of the > ipaHostgroup > > This similar to how sudoCommand is being populated. > > It wants to be like how sudoUser is being populated. > > sudoHost: +prod > > Here is the ldapsearch for the pieces that need adjustment. > > # prod, hostgroups, accounts, example.com > dn: cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com > objectClass: ipaobject > objectClass: ipahostgroup > objectClass: nestedGroup > objectClass: groupOfNames > objectClass: top > cn: prod > description: prod > ipaUniqueID: 15261e98-f7ee-11df-968e-8a3d259cb0b9 > member: > fqdn=auth3.ops.example.com,cn=computers,cn=accounts,dc=example,dc=com > > > # sudoers, example.com > dn: cn=sudoers, dc=example,dc=com > objectClass: extensibleObject > cn: sudoers > > # operations, sudoers, example.com > dn: cn=operations,cn=sudoers,dc=example,dc=com > objectClass: sudoRole > sudoUser: %ops > sudoHost: auth3.ops.example.com > sudoCommand: /usr/bin/less > cn: operations > > > Currently it functions as originally specified i.e. it expand the hosts when a host group is referenced directly. Please create a nis netgroup and add a host group into it manually. Point the sudo rule you created to the netgroup rather than to the host group directly In this case you should get what you are currently looking for i.e. +prod (if that would be the name of the netgroup). If that works the sudo part will be done and we would need to focus on one of the variants of keeping the netgroups and host groups in synch as was proposed in other thread. > Thank you very much for your help Nalin! > > > ___ > 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] Other issues with HBAC calendar
Simo Sorce wrote: > On Wed, 24 Nov 2010 11:26:05 -0500 > Dmitri Pal wrote: > > >> Steven, please think about the case when the rule needs to be edited >> in UI and it has some value for DD - say 1. >> What you display in UI then? If you do not allow to enter days and you >> not allow more than 24 hours in the hour field you will fail to >> translate the rule to the proposed UI. >> The only option would be to show the raw rule in this case. IMO this >> does not seem like the best option to me. >> > > May not be the best but it is perfectly reasonable. > > >> I think the DD is redundant and other means should be used to schedule >> windows bigger than 2 days however the HH should IMO allow 1-48 ours >> to allow specifying a week end outage like: >> from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable >> to ask to split the rule into several slices. >> > > I think this is not reasonable at all, it is an arbitrary limit due to > the "current" thinking around the UI, if you change mind about the UI > tomorrow, you will be left with the constraint in the grammar. > This is just backwards. > > Simo. > > Keeping in mind that we have just one shot at it, it is unreasonable to think that the limitations that the UI imposes will ever go away. Effectively what you and Steven say is that the grammar should dictate the UI. It is the wrong approach. As well as the vice versa. The UI should not dictate the grammar. However the grammar also should not have constructs that would never be expressed in UI because they are already identified as unusable. In other words the UI can be subset of what grammar supports but all the options that grammar supports should be potentially implementable in UI and usable. If the they never can be implemented in UI in usable way they should not be in grammar. -- 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] Other issues with HBAC calendar
On Wed, 24 Nov 2010 11:26:05 -0500 Dmitri Pal wrote: > Steven, please think about the case when the rule needs to be edited > in UI and it has some value for DD - say 1. > What you display in UI then? If you do not allow to enter days and you > not allow more than 24 hours in the hour field you will fail to > translate the rule to the proposed UI. > The only option would be to show the raw rule in this case. IMO this > does not seem like the best option to me. May not be the best but it is perfectly reasonable. > I think the DD is redundant and other means should be used to schedule > windows bigger than 2 days however the HH should IMO allow 1-48 ours > to allow specifying a week end outage like: > from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable > to ask to split the rule into several slices. I think this is not reasonable at all, it is an arbitrary limit due to the "current" thinking around the UI, if you change mind about the UI tomorrow, you will be left with the constraint in the grammar. This is just backwards. 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] Where we are with SUDO?
Progress! Ok, here is the latest data from the lab. The compat translation is almost there!!! * The sudoers container has correctly been moved out to the top of the tree. I think it only needs 1 small final edit, the sudo ldap default is to look for: ou=sudoers, rather than what is currently "cn=sudoers" * sudoUser correctly translates to a % * sudoCommand: correctly translates to the individual members of the ipaSudoCmdGroup * sudoHost: is incorrectly enumerating the individual members of the ipaHostgroup This similar to how sudoCommand is being populated. It wants to be like how sudoUser is being populated. sudoHost: +prod Here is the ldapsearch for the pieces that need adjustment. # prod, hostgroups, accounts, example.com dn: cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com objectClass: ipaobject objectClass: ipahostgroup objectClass: nestedGroup objectClass: groupOfNames objectClass: top cn: prod description: prod ipaUniqueID: 15261e98-f7ee-11df-968e-8a3d259cb0b9 member: fqdn=auth3.ops.example.com,cn=computers,cn=accounts,dc=example,dc=com # sudoers, example.com dn: cn=sudoers, dc=example,dc=com objectClass: extensibleObject cn: sudoers # operations, sudoers, example.com dn: cn=operations,cn=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ops sudoHost: auth3.ops.example.com sudoCommand: /usr/bin/less cn: operations Thank you very much for your help Nalin! ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
Stephen Gallagher wrote: > On 11/24/2010 11:15 AM, Dmitri Pal wrote: > > Stephen Gallagher wrote: > >> On 11/23/2010 04:32 PM, Simo Sorce wrote: > >>> On Tue, 23 Nov 2010 16:07:47 -0500 > >>> Rob Crittenden wrote: > I don't want to throw a wrench in, but what if you have multiple > replicas in various distant locations, WHICH server is the time > relative to? > >>> By server I think Steve meant the machine currently evaluation the > >>> access control decision. "Host" would have been a happier term. > >> > >> No, I was actually talking about the FreeIPA server in this situation, > >> but Rob is right that there is no guarantee in a multi-master situation > >> that the servers themselves are in the same timezone. > >> > >> Given this, I think the only sane thing to do here is to always use UTC > >> (and state clearly that this is what is happening) > >> > > I was always saying that the time should be in the UTC only when it is > > evaluated on the server . I do not think that "local" is a good > solution. > > But I think the whole idea with the timezones have been misinterpreted > > so let me try to explain one more time. > > He is the workflow that I have in mind: > > > 1) Admin creates a rule with time definition using UI and CLI > > 2) Rule is saved in the LDAP attribute > > 3) Rule gets replicated between IPA servers > > 4) SSSD fetches the rule from an IPA server > > 5) SSSD validates the rule > > > Let us say that the rule is entered, saved, transfered and interpreted > > on the client as UTC. Sounds reasonable and not that complex from the > > implementation POW. Good! > > The only issue I see is that the admin during step 1 does not think in > > terms of UTC as Ben pointed out. He thinks in user time or server time > > i.e. tries to relate the rule to some reasonable time markers (start of > > a shift, end of a working day, midnight at a special location etc.) > > So I was suggesting the following: > > 1) Allow admin to specify in what time zone he entered the time > > 2) Pass the time definition together with the time zone he selected to > > the server > > 3) Before saving the rule the server would convert the rule into UTC and > > stick the TZ info hint into the rule > > 4) When SSSD retrieves the attribute it will know that time is in UTC > > and will ignore any TZ hints stored in the rule > > 5) The TZ hint only need for UI/CLI when admin fetches the rule and > > looks at it. In this case the server will take attribute which is in > > UTC, extract a TZ hint from the rule and use that TZ to convert UTC > > value it has to the value in the specified TZ. This is what is sent to > > the client and displayed in the UI/CLI. > > > So TZ is needed only for the administrative purposes and not for SSSD. I > > hope it is clear now. > > I was also suggesting to save offset together with the TZ hint but I > > guess this can be dropped. > > Can we agree to keep the TZ as hint for the management purposes in > the rule? > > > Dmitri, this simply cannot work, because time zones are not static. You > can't tell the administrator he is defining something in the Eastern > time zone from 09:00-17:00 EST and then store that value as UTC. Because > when DST happens, suddenly this will be equivalent to 08:00-16:00 EDT. > And the meaning of the rule is lost. The may be we should store both the UTC and the time how it was entered by the user in the same rule. > > So if you want to define a timezone for a rule, it MUST be stored as > local time plus timezone identifier, so that when it is evaluated it > will use the appropriate offset for that moment in history. > > You can't just send a UTC value down to SSSD. Yes you can. This is what we all agree is the safest option. > > After lunch, I'm going to write up the completely new proposal that Adam > and I are suggesting to avoid the future upgrade issue for SSSD as well. > It will account for the problem you're trying to solve here. > > > I am all ears. -- 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] Other issues with HBAC calendar
Stephen Gallagher wrote: > On 11/24/2010 11:26 AM, Dmitri Pal wrote: > >>> Duration > >>> New grammar allows DDHHMM for the duration. UI proposes to limit the > >>> duration to less than 24 hours since more than 24 hour windows can > start > >>> overlapping and thus allowing to enter duration days was confusing to > >>> the users who tried the UI. We need to reconcile this a bit between > >>> what can be stored and what can be displayed. IMO it makes sense to > >>> allow windows more than 24 hours (regular service window over weekend > >>> for example). But on the other hand I see how having a separate field > >>> for number of duration days in the UI might be confusing. I would vote > >>> for not having days in the UI at all but allowing any numeric value to > >>> be entered into the hours field. This however rises a question whether > >>> we want to have the duration be in DDHHMM format in grammar or in just > >>> NMM format where N is any numeric value that represents unlimited > number > >>> of hours. Thoughts? > >> > >> I agree that we don't want to have > 24 hours in the UI. > >> > >> DDHHMM is easier to parse, and I can't come up with an example where a > >> window of longer than 99 days makes sense. Instead, it should be a > >> recurring event. > >> > >> > > Steven, please think about the case when the rule needs to be edited in > > UI and it has some value for DD - say 1. > > What you display in UI then? If you do not allow to enter days and you > > not allow more than 24 hours in the hour field you will fail to > > translate the rule to the proposed UI. > > The only option would be to show the raw rule in this case. IMO this > > does not seem like the best option to me. > > I think the DD is redundant and other means should be used to schedule > > windows bigger than 2 days however the HH should IMO allow 1-48 ours to > > allow specifying a week end outage like: > > from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to > > ask to split the rule into several slices. > > > > I don't want the internal representation to have arbitrary limitations > set by the WebUI. It's trivial for the WebUI to be designed to convert > hours to days and reverse. So we can store it in DDHHMM format and > display it in the WebUI as hours if we really want to. Sorry but you are completely wrong here. First this is not an arbitrarily limitation but a usability one. Second it is not trivial to design web UI especially to be usable. Current version of the proposed UI (I hope you have seen it) says: a) No day field b) Hours field can't accept more than 24 hours You agreed in the first email that these are reasonable UI limitations. So IMO it is completely unreasonable to store something that we can't ever represent in the UI (not because we do not have time, but because the internal grammar contradicts the suggested UI). I see three outcomes in current situation: 1) Allow schema to have DDHHMM as you proposed and have UI as Ben proposed and close eyes to all the ugliness it creates. IMO it is just wrong and will backfire in future. 2) Adjust UI to match proposed schema - this means we should either add a day field in the UI or allow the time field to store more than 24 hours 3) Adjust the schema to match the UI - IMO this is the path of least resistance and most reasonable thing to do. So to summarize I disagree and stick to my point. Please get together with Ben on Monday and come to consensus on 2) or 3). I do not care. 1) Is not an option. > > To someone writing a rule by hand, the DDHHMM representation is going to > be far more useful. > ___ 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] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 11:15 AM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 11/23/2010 04:32 PM, Simo Sorce wrote: >>> On Tue, 23 Nov 2010 16:07:47 -0500 >>> Rob Crittenden wrote: >> I don't want to throw a wrench in, but what if you have multiple replicas in various distant locations, WHICH server is the time relative to? >>> By server I think Steve meant the machine currently evaluation the >>> access control decision. "Host" would have been a happier term. >> >> >> No, I was actually talking about the FreeIPA server in this situation, >> but Rob is right that there is no guarantee in a multi-master situation >> that the servers themselves are in the same timezone. >> >> Given this, I think the only sane thing to do here is to always use UTC >> (and state clearly that this is what is happening) >> > > I was always saying that the time should be in the UTC only when it is > evaluated on the server . I do not think that "local" is a good solution. > But I think the whole idea with the timezones have been misinterpreted > so let me try to explain one more time. > He is the workflow that I have in mind: > > 1) Admin creates a rule with time definition using UI and CLI > 2) Rule is saved in the LDAP attribute > 3) Rule gets replicated between IPA servers > 4) SSSD fetches the rule from an IPA server > 5) SSSD validates the rule > > Let us say that the rule is entered, saved, transfered and interpreted > on the client as UTC. Sounds reasonable and not that complex from the > implementation POW. Good! > The only issue I see is that the admin during step 1 does not think in > terms of UTC as Ben pointed out. He thinks in user time or server time > i.e. tries to relate the rule to some reasonable time markers (start of > a shift, end of a working day, midnight at a special location etc.) > So I was suggesting the following: > 1) Allow admin to specify in what time zone he entered the time > 2) Pass the time definition together with the time zone he selected to > the server > 3) Before saving the rule the server would convert the rule into UTC and > stick the TZ info hint into the rule > 4) When SSSD retrieves the attribute it will know that time is in UTC > and will ignore any TZ hints stored in the rule > 5) The TZ hint only need for UI/CLI when admin fetches the rule and > looks at it. In this case the server will take attribute which is in > UTC, extract a TZ hint from the rule and use that TZ to convert UTC > value it has to the value in the specified TZ. This is what is sent to > the client and displayed in the UI/CLI. > > So TZ is needed only for the administrative purposes and not for SSSD. I > hope it is clear now. > I was also suggesting to save offset together with the TZ hint but I > guess this can be dropped. > Can we agree to keep the TZ as hint for the management purposes in the rule? > Dmitri, this simply cannot work, because time zones are not static. You can't tell the administrator he is defining something in the Eastern time zone from 09:00-17:00 EST and then store that value as UTC. Because when DST happens, suddenly this will be equivalent to 08:00-16:00 EDT. And the meaning of the rule is lost. So if you want to define a timezone for a rule, it MUST be stored as local time plus timezone identifier, so that when it is evaluated it will use the appropriate offset for that moment in history. You can't just send a UTC value down to SSSD. After lunch, I'm going to write up the completely new proposal that Adam and I are suggesting to avoid the future upgrade issue for SSSD as well. It will account for the problem you're trying to solve here. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztRXkACgkQeiVVYja6o6N4nwCeMQ5Rby7kGQADKbYj0EdEqfzi JDYAnRBS+A3rY/dg7kQVMeEB8CEHIcSr =G3lr -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 11:26 AM, Dmitri Pal wrote: > >> >>> Duration >> >>> New grammar allows DDHHMM for the duration. UI proposes to limit the >>> duration to less than 24 hours since more than 24 hour windows can start >>> overlapping and thus allowing to enter duration days was confusing to >>> the users who tried the UI. We need to reconcile this a bit between >>> what can be stored and what can be displayed. IMO it makes sense to >>> allow windows more than 24 hours (regular service window over weekend >>> for example). But on the other hand I see how having a separate field >>> for number of duration days in the UI might be confusing. I would vote >>> for not having days in the UI at all but allowing any numeric value to >>> be entered into the hours field. This however rises a question whether >>> we want to have the duration be in DDHHMM format in grammar or in just >>> NMM format where N is any numeric value that represents unlimited number >>> of hours. Thoughts? >> >> >> I agree that we don't want to have > 24 hours in the UI. >> >> DDHHMM is easier to parse, and I can't come up with an example where a >> window of longer than 99 days makes sense. Instead, it should be a >> recurring event. >> >> > > Steven, please think about the case when the rule needs to be edited in > UI and it has some value for DD - say 1. > What you display in UI then? If you do not allow to enter days and you > not allow more than 24 hours in the hour field you will fail to > translate the rule to the proposed UI. > The only option would be to show the raw rule in this case. IMO this > does not seem like the best option to me. > I think the DD is redundant and other means should be used to schedule > windows bigger than 2 days however the HH should IMO allow 1-48 ours to > allow specifying a week end outage like: > from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to > ask to split the rule into several slices. > I don't want the internal representation to have arbitrary limitations set by the WebUI. It's trivial for the WebUI to be designed to convert hours to days and reverse. So we can store it in DDHHMM format and display it in the WebUI as hours if we really want to. To someone writing a rule by hand, the DDHHMM representation is going to be far more useful. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztQ2EACgkQeiVVYja6o6McjgCfZ7RfnLM+wU4KUqXdKac9PuWE q50An07EzeToJV6YlhStTrBg1mDIkw8s =hO6C -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] admiyo-0102-action-panel-formatting
From 9bc3cc9897741ac720747ecd4a3b4d4f31de7232 Mon Sep 17 00:00:00 2001 From: Adam Young Date: Tue, 23 Nov 2010 22:24:50 -0500 Subject: [PATCH] action panel formatting Cleans up the indentation of the action panel Puts the sudo and HBAC entries in a consistent order --- install/static/details.js |4 +--- install/static/entity.js | 25 +++-- install/static/hbacsvc.js |5 - install/static/hbacsvcgroup.js | 15 +-- install/static/ipa.css | 10 +- install/static/search.js |3 +-- install/static/sudocmd.js |2 +- install/static/sudocmdgroup.js | 15 +-- 8 files changed, 53 insertions(+), 26 deletions(-) diff --git a/install/static/details.js b/install/static/details.js index 3b4edda6c5ac751cbaa4c897bf2ba34b2458a051..a989d9d4e3c163a4c9a136a7b6e082a3d5294bb5 100644 --- a/install/static/details.js +++ b/install/static/details.js @@ -457,9 +457,7 @@ function ipa_details_create(container) var action_panel = that.get_action_panel(); var ul = $('ul', action_panel); -var buttons = $('', { -'class': 'details-buttons' -}).prependTo(ul); +var buttons = $('.action-controls',action_panel); $('', { 'type': 'text', diff --git a/install/static/entity.js b/install/static/entity.js index 25a9fd3106c29d28679f6fc365f803d8d2e9e9d0..713dbf31d528970e7895cc2929fc4b3ae66824b2 100644 --- a/install/static/entity.js +++ b/install/static/entity.js @@ -1,6 +1,7 @@ /* Authors: *Pavel Zuna *Endi S. Dewata + *Adam Young * * Copyright (C) 2010 Red Hat * see file 'COPYING' for use and warranty information @@ -340,8 +341,6 @@ function ipa_entity_setup(container) { facet.refresh(); } - - function ipa_facet_create_action_panel(container) { var that = this; @@ -349,7 +348,9 @@ function ipa_facet_create_action_panel(container) { var action_panel = $('', { "class": "action-panel", -html: $('Actions') +html: $('',{ +text: IPA.metadata[entity_name].label +}) }).appendTo(container); function build_link(other_facet,label,other_entity){ @@ -387,9 +388,21 @@ function ipa_facet_create_action_panel(container) { var entity = IPA.get_entity(entity_name); var facet_name = ipa_current_facet(entity); -for (var i=0; i 0 ){ +main_facet.text( 'List ' + IPA.metadata[entity_name].label); +} +main_facet.appendTo(ul); + +ul.append($('')); +for (var i=1; i', { title: 'hbac', text: 'HBAC Rules' -}).appendTo(ul); +}).prependTo(ul); $('', { title: 'hbacsvcgroup', diff --git a/install/static/hbacsvcgroup.js b/install/static/hbacsvcgroup.js index 056c8fab1ef0d2503db45e4ca083321815847de7..121fad676b6130a3b34c15aa3a52da1f72701a2a 100755 --- a/install/static/hbacsvcgroup.js +++ b/install/static/hbacsvcgroup.js @@ -109,15 +109,18 @@ function ipa_hbacsvcgroup_search_facet(spec) { var ul = $('ul', action_panel); -$('', { -title: 'hbac', -text: 'HBAC Rules' -}).appendTo(ul); - +/*Note that we add these at the top of the action panel + so that the HBAC entities always show in the same order.*/ $('', { title: 'hbacsvc', text: 'HBAC Services' -}).appendTo(ul); +}).prependTo(ul); + +$('', { +title: 'hbac', +text: 'HBAC Rules' +}).prependTo(ul); + that.search_facet_create(container); diff --git a/install/static/ipa.css b/install/static/ipa.css index b7654be00ea7f84549eda78d9569b75c2bf53bbf..3b283610b931db56cb9e463de670783f541eb313 100644 --- a/install/static/ipa.css +++ b/install/static/ipa.css @@ -322,17 +322,24 @@ span.main-separator{ float: left; margin-top: 5em; margin-left: 2.5em; +padding-left: 0.5em; padding-bottom: 1em; width: 17.5em; } + +.action-panel ul { +list-style-type:none; +padding: 0; +} + .action-panel h3{ margin: 0; background: #e8e8e8; } .action-panel li { -height: 2em; +height: auto; padding: 0.2em; } @@ -346,6 +353,7 @@ span.main-separator{ color: black; text-decoration: underline; cursor: pointer; +margin-left:2em; } .action-panel li.entity-facet-disabled { diff --git a/install/static/search.js b/install/static/search.js index 03d4cac5a61c510943c79c545b95b93d24e9a1c1..5b42cf11a0411f1a479755f31d315086baa13ae9 100644 --- a/install/static/search.js +++ b/install/static/search.js @@ -54,8 +54,7 @@ function ipa_search_widget(spec) { var action_panel = that.facet.get_action_panel(); -var ul = $('ul', action_panel); -var li = $('').prependTo(ul); +var li = $('.action-controls',action_panel); var search_buttons = $('', { 'class': 'search-buttons' diff --git a/install/static/s
Re: [Freeipa-devel] Other issues with HBAC calendar
> > > Duration > > > New grammar allows DDHHMM for the duration. UI proposes to limit the > > duration to less than 24 hours since more than 24 hour windows can start > > overlapping and thus allowing to enter duration days was confusing to > > the users who tried the UI. We need to reconcile this a bit between > > what can be stored and what can be displayed. IMO it makes sense to > > allow windows more than 24 hours (regular service window over weekend > > for example). But on the other hand I see how having a separate field > > for number of duration days in the UI might be confusing. I would vote > > for not having days in the UI at all but allowing any numeric value to > > be entered into the hours field. This however rises a question whether > > we want to have the duration be in DDHHMM format in grammar or in just > > NMM format where N is any numeric value that represents unlimited number > > of hours. Thoughts? > > > I agree that we don't want to have > 24 hours in the UI. > > DDHHMM is easier to parse, and I can't come up with an example where a > window of longer than 99 days makes sense. Instead, it should be a > recurring event. > > Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. ___ 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] [PATCH] Add new version of DNS plugin: complete rework with baseldap + unit tests.
On 11/24/2010 10:21 AM, Adam Young wrote: On 11/24/2010 03:46 AM, Pavel Zuna wrote: On 11/24/2010 03:26 AM, Adam Young wrote: On 11/23/2010 09:37 AM, Pavel Zuna wrote: Finally managed to rewrite the DNS plugin again. Sorry, it took so long, we had training in the office and I also had a nasty bug in baseldap.py I couldn't find. Anyway, this version has it all: - changes we agreed on meeting, the "resource" abstraction is gone and we now only have zones and records = adding new record automatically updates and existing entry or creates it if it wasn't there and deleting the last record deletes the whole entry - all of it transparent to the user - unit tests - ipa help documentation Fixes tickets: #36 #450 I also closed bug #654412. It has a new patch sequence number, because it depends on another patch with a higher number and didn't want to create forward dependencies. Depends on my patches number: 35 (will repost if needed) 38 (posted a while ago on freeipa-devel) Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I keep getting an error when doing simple things like install and ipa help: [ayo...@ipa freeipa]$ ./ipa help dns2 ipa: ERROR: AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipalib/cli.py", line 962, in run api.finalize() File "/home/ayoung/devel/freeipa/ipalib/plugable.py", line 615, in finalize p.instance.finalize() File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 724, in finalize self._create_param_namespace('args') File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 350, in _create_param_namespace sort=False File "/home/ayoung/devel/freeipa/ipalib/base.py", line 407, in __init__ (self.__class__.__name__, name, self.__map[name], member) AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) ipa: ERROR: an internal error has occurred That's because you need my patch number 35 for it to work... Pavel OK, with that change, the patch applies and works. I've tested: creating a zone Creating an a record Adding an a record entry to an existing entry (calling ipa dnsrecord-add a second time with just a different ip address) Adding an record. Deleting one and multiple records One thing that is a little counter intuitive is that you have to specify which records to delete: just running ipa dnsrecord-del ayoung.test.ipa.redhat.com hiphop doesn't delete all records with the A name of hiphop. I think this is the right behavior, but it should be better documented. Have to hold off on pushing it due to F14: python-netaddr Isn't in F14, so we are adding a new python package with this plugin, too. Correction, Due to RHEL6. unwise to take on a new dependency this close to ship. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
Stephen Gallagher wrote: > On 11/23/2010 04:32 PM, Simo Sorce wrote: > > On Tue, 23 Nov 2010 16:07:47 -0500 > > Rob Crittenden wrote: > > >> I don't want to throw a wrench in, but what if you have multiple > >> replicas in various distant locations, WHICH server is the time > >> relative to? > > By server I think Steve meant the machine currently evaluation the > > access control decision. "Host" would have been a happier term. > > > No, I was actually talking about the FreeIPA server in this situation, > but Rob is right that there is no guarantee in a multi-master situation > that the servers themselves are in the same timezone. > > Given this, I think the only sane thing to do here is to always use UTC > (and state clearly that this is what is happening) > I was always saying that the time should be in the UTC only when it is evaluated on the server . I do not think that "local" is a good solution. But I think the whole idea with the timezones have been misinterpreted so let me try to explain one more time. He is the workflow that I have in mind: 1) Admin creates a rule with time definition using UI and CLI 2) Rule is saved in the LDAP attribute 3) Rule gets replicated between IPA servers 4) SSSD fetches the rule from an IPA server 5) SSSD validates the rule Let us say that the rule is entered, saved, transfered and interpreted on the client as UTC. Sounds reasonable and not that complex from the implementation POW. Good! The only issue I see is that the admin during step 1 does not think in terms of UTC as Ben pointed out. He thinks in user time or server time i.e. tries to relate the rule to some reasonable time markers (start of a shift, end of a working day, midnight at a special location etc.) So I was suggesting the following: 1) Allow admin to specify in what time zone he entered the time 2) Pass the time definition together with the time zone he selected to the server 3) Before saving the rule the server would convert the rule into UTC and stick the TZ info hint into the rule 4) When SSSD retrieves the attribute it will know that time is in UTC and will ignore any TZ hints stored in the rule 5) The TZ hint only need for UI/CLI when admin fetches the rule and looks at it. In this case the server will take attribute which is in UTC, extract a TZ hint from the rule and use that TZ to convert UTC value it has to the value in the specified TZ. This is what is sent to the client and displayed in the UI/CLI. So TZ is needed only for the administrative purposes and not for SSSD. I hope it is clear now. I was also suggesting to save offset together with the TZ hint but I guess this can be dropped. Can we agree to keep the TZ as hint for the management purposes in the rule? -- 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] [PATCH] Add new version of DNS plugin: complete rework with baseldap + unit tests.
On 11/24/2010 03:46 AM, Pavel Zuna wrote: On 11/24/2010 03:26 AM, Adam Young wrote: On 11/23/2010 09:37 AM, Pavel Zuna wrote: Finally managed to rewrite the DNS plugin again. Sorry, it took so long, we had training in the office and I also had a nasty bug in baseldap.py I couldn't find. Anyway, this version has it all: - changes we agreed on meeting, the "resource" abstraction is gone and we now only have zones and records = adding new record automatically updates and existing entry or creates it if it wasn't there and deleting the last record deletes the whole entry - all of it transparent to the user - unit tests - ipa help documentation Fixes tickets: #36 #450 I also closed bug #654412. It has a new patch sequence number, because it depends on another patch with a higher number and didn't want to create forward dependencies. Depends on my patches number: 35 (will repost if needed) 38 (posted a while ago on freeipa-devel) Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I keep getting an error when doing simple things like install and ipa help: [ayo...@ipa freeipa]$ ./ipa help dns2 ipa: ERROR: AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipalib/cli.py", line 962, in run api.finalize() File "/home/ayoung/devel/freeipa/ipalib/plugable.py", line 615, in finalize p.instance.finalize() File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 724, in finalize self._create_param_namespace('args') File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 350, in _create_param_namespace sort=False File "/home/ayoung/devel/freeipa/ipalib/base.py", line 407, in __init__ (self.__class__.__name__, name, self.__map[name], member) AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) ipa: ERROR: an internal error has occurred That's because you need my patch number 35 for it to work... Pavel OK, with that change, the patch applies and works. I've tested: creating a zone Creating an a record Adding an a record entry to an existing entry (calling ipa dnsrecord-add a second time with just a different ip address) Adding an record. Deleting one and multiple records One thing that is a little counter intuitive is that you have to specify which records to delete: just running ipa dnsrecord-del ayoung.test.ipa.redhat.com hiphop doesn't delete all records with the A name of hiphop. I think this is the right behavior, but it should be better documented. Have to hold off on pushing it due to F14: python-netaddr Isn't in F14, so we are adding a new python package with this plugin, too. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make the migration plugin more configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 04:21 PM, Jakub Hrozek wrote: > On 11/22/2010 04:16 PM, Jakub Hrozek wrote: >> The code handles it (I just ran a quick test with --schema=RFC2307bis). > >> It just iterates through all members of a group -- be it user member of >> group member, it's just a DN for the plugin. > >> Jakub > > Sorry, I found another bug in the plugin. I'll send a new patch shortly, > so please don't waste time reviewing this one. New patch is attached. It fixes two more bugs of the original plugin - determines whether a group member is a user or a nested group by checking the DN, not just the RDN attribute name and does not hardcode primary keys. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztK7sACgkQHsardTLnvCUdewCdECJneAALtFoe80bWgZqMUHJ2 FjIAn05ld9VSNwe8Xmhi7Y8R3g3Af/av =ZInN -END PGP SIGNATURE- From 7a12a608e5fee82713af6c9c318dbf6b3e98ef83 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Tue, 26 Oct 2010 16:10:42 -0400 Subject: [PATCH] Make the migration plugin more configurable This patch adds new options to the migration plugin: * the option to fine-tune the objectclass of users or groups being imported * the option to select the LDAP schema (RFC2307 or RFC2307bis) Also makes the logic that decides whether an entry is a nested group or user (for RFC2307bis) smarter by looking at the DNS. Does not hardcode primary keys for migrated entries. https://fedorahosted.org/freeipa/ticket/429 --- ipalib/plugins/migration.py | 131 +-- 1 files changed, 102 insertions(+), 29 deletions(-) diff --git a/ipalib/plugins/migration.py b/ipalib/plugins/migration.py index 6dc9934..48c8fa2 100644 --- a/ipalib/plugins/migration.py +++ b/ipalib/plugins/migration.py @@ -26,9 +26,10 @@ Example: Migrate users and groups from DS to IPA import logging import re +import ldap as _ldap from ipalib import api, errors, output -from ipalib import Command, List, Password, Str, Flag +from ipalib import Command, List, Password, Str, Flag, StrEnum from ipalib.cli import to_cli if api.env.in_server and api.env.context in ['lite', 'server']: try: @@ -44,8 +45,10 @@ from ipalib.text import Gettext # FIXME: remove once the other Gettext FIXME is _krb_err_msg = _('Kerberos principal %s already exists. Use \'ipa user-mod\' to set it manually.') _grp_err_msg = _('Failed to add user to the default group. Use \'ipa group-add-member\' to add manually.') +_supported_schemas = (u'RFC2307bis', u'RFC2307') -def _pre_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx): + +def _pre_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs): # get default primary group for new users if 'def_group_dn' not in ctx: def_group = config.get('ipadefaultprimarygroup') @@ -90,21 +93,30 @@ def _post_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx): # GROUP MIGRATION CALLBACKS AND VARS -def _pre_migrate_group(ldap, pkey, dn, entry_attrs, failed, config, ctx): -def convert_members(member_attr, overwrite=False): +def _pre_migrate_group(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs): +def convert_members_rfc2307bis(member_attr, search_bases, overwrite=False): """ Convert DNs in member attributes to work in IPA. """ new_members = [] entry_attrs.setdefault(member_attr, []) for m in entry_attrs[member_attr]: -col = m.find(',') -if col == -1: -continue -if m.startswith('uid'): -m = '%s,%s' % (m[0:col], api.env.container_user) -elif m.startswith('cn'): -m = '%s,%s' % (m[0:col], api.env.container_group) +try: +# what str2dn returns looks like [[('cn', 'foo', 4)], [('dc', 'example', 1)], [('dc', 'com', 1)]] +rdn = _ldap.dn.str2dn(m ,flags=_ldap.DN_FORMAT_LDAPV3)[0] +rdnval = rdn[0][1] +except IndexError: +raise ValueError('Malformed DN %s has no RDN?' % m) + +if m.lower().endswith(search_bases['user']): +m = '%s=%s,%s' % (api.Object.user.primary_key.name, + rdnval, + api.env.container_user) +elif m.lower().endswith(search_bases['group']): +m = '%s=%s,%s' % (api.Object.group.primary_key.name, + rdnval, + api.env.container_group) + m = ldap.normalize_dn(m) new_members.append(m) del entry_attrs[member_attr] @@ -112,15 +124,42 @@ def _pre_migrate_group(ldap, pkey, dn, entry_attrs, failed, config, ctx): entry_attrs['member'] = [] entry_attrs['member'] += new_members +def convert_members_rfc2307(mem
Re: [Freeipa-devel] [PATCH] 609 Reduce the number of attributes a host is allowed to write.
Simo Sorce wrote: On Wed, 17 Nov 2010 15:07:03 -0500 Rob Crittenden wrote: +aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbMKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || serverHostName || enrolledBy")(version 3.0; acl "Admin can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) Ah also forgot to say that I am not sure we want admin to be able to change krbPwdHistory and krbLastPwdChange. Also not sure about krbLastSuccessfulAuth and krbLastFailedAuth, while we might let admin write krbLoginFailedCount in order to unlock an automatically locked account that failed preauth too many times. We also probably do not want admin to be able to change ipaUniqueId. Simo. I was going to tackle krbLoginFailedCount when we finally got a way to unlock users across replicas. You're right on the other two, we want admins to reset passwords :-) ipaUniqueId needs to be writable so a UPG group can be detached. The write is "autogenerate", the plugin handles the rest of the access control. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Rename parent LDAPObject pkeys in child LDAPObject methods.
On 11/24/2010 03:48 AM, Pavel Zuna wrote: On 11/19/2010 04:23 PM, Jakub Hrozek wrote: On Tue, Nov 09, 2010 at 04:55:50AM +0100, Pavel Zůna wrote: If the parent and child entries have the same attribute as primary key (such as in the DNS schema), we need to rename the parent key to prevent a param name conflict. It has no side effects, because the primary key name is always taken from the LDAPObject params, never from the method params. Pavel Would you mind rebasing the patch on top of Rob's 593 which is already acked (not pushed yet as of now). Jakub Rebased patch number 35 attached - required by the new DNS plugin. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK and pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Patches and Thunderbird
Thunderbird formatting of patches: Thunderbird has a nasty habit of prepending a '>' character to the patch, messing up the format. While it is trivial to edit the patch by hand to remove it, the patch sender can help out by configuring Thurnderbird this way: * In Thunderbird Preferences, * go to the Advanced->General tab. * Select "Config Editor" * Search for mail.file_attach_binary and * set this value to true I've added this to the patch format page. https://fedorahosted.org/freeipa/wiki/PatchFormat I'm making an effort to keep track of the different patches that are out there and their status, so the more consistent we are, the easier it is to do. Please make sure at least the patch number is in the title of the email you send out. There are so many patches, that when someone refers to their patch 86 it makes it much faster to go and find that patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2010 04:32 PM, Simo Sorce wrote: > On Tue, 23 Nov 2010 16:07:47 -0500 > Rob Crittenden wrote: > >> I don't want to throw a wrench in, but what if you have multiple >> replicas in various distant locations, WHICH server is the time >> relative to? > > By server I think Steve meant the machine currently evaluation the > access control decision. "Host" would have been a happier term. No, I was actually talking about the FreeIPA server in this situation, but Rob is right that there is no guarantee in a multi-master situation that the servers themselves are in the same timezone. Given this, I think the only sane thing to do here is to always use UTC (and state clearly that this is what is happening) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztJaoACgkQeiVVYja6o6MPPgCglv9EY4OaQk6PaEEXhUIIdFu4 HVQAn1gqQom24AmJ/qMUoxWN/4mr/+M4 =hSe5 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 609 Reduce the number of attributes a host is allowed to write.
On Wed, 17 Nov 2010 15:07:03 -0500 Rob Crittenden wrote: > +aci: (targetattr != "userPassword || krbPrincipalKey || > sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || > krbPrincipalName || krbCanonicalName || krbUPEnabled || krbMKey || > krbTicketPolicyReference || krbPrincipalExpiration || > krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || > krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || > krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || > krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || > serverHostName || enrolledBy")(version 3.0; acl "Admin can manage any > entry"; allow (all) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) Ah also forgot to say that I am not sure we want admin to be able to change krbPwdHistory and krbLastPwdChange. Also not sure about krbLastSuccessfulAuth and krbLastFailedAuth, while we might let admin write krbLoginFailedCount in order to unlock an automatically locked account that failed preauth too many times. We also probably do not want admin to be able to change ipaUniqueId. 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] 609 Reduce the number of attributes a host is allowed to write.
Simo Sorce wrote: On Wed, 17 Nov 2010 15:07:03 -0500 Rob Crittenden wrote: aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";;) -aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || memberOf || serverHostName || enrolledBy")(version 3.0; acl "Admin can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) +aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbMKey || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || serverHostName || enrolledBy")(versi Nack. Some attributes are repeated multiple times in this chunk. (krbMKey for example). Simo. Gah, ok. What I did here was ran GER on the various objects and wonder "Gee, should those be writable?" I guess I did a poor job de-duping. I'll take another look. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 609 Reduce the number of attributes a host is allowed to write.
On Wed, 17 Nov 2010 15:07:03 -0500 Rob Crittenden wrote: > aci: (targetattr != "userPassword || krbPrincipalKey || > sambaLMPassword || sambaNTPassword || passwordHistory || > krbMKey")(version 3.0; acl "Enable Anonymous access"; allow (read, > search, compare) userdn = "ldap:///anyone";;) -aci: (targetattr != > "userPassword || krbPrincipalKey || sambaLMPassword || > sambaNTPassword || passwordHistory || krbMKey || memberOf || > serverHostName || enrolledBy")(version 3.0; acl "Admin can manage any > entry"; allow (all) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) +aci: > (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || > sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || > krbCanonicalName || krbUPEnabled || krbMKey || > krbTicketPolicyReference || krbPrincipalExpiration || > krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || > krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || > krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || > krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || > serverHostName || enrolledBy")(versi Nack. Some attributes are repeated multiple times in this chunk. (krbMKey for example). 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] 612 re-implimit permissions
On Thu, 18 Nov 2010 23:11:51 -0500 Rob Crittenden wrote: > Re-implement access control using an updated model. > > The new model is based on permissions, privileges and roles. Most > importantly it corrects the reverse membership that caused problems > in the previous implementation. You add permission to privileges and > privileges to roles, not the other way around (even though it works > that way behind the scenes). > > A permission object is a combination of a simple group and an aci. > The linkage between the aci and the permission is the description of > the permission. This shows as the name/description of the aci. > > ldap:///self and groups granting groups (v1-style) are not supported > by this model (it will be provided separately). > > ticket 445 > > WARNING. The patch is humongous and changes a whole slew of stuff. It > patches cleanly against the master right now but it is quite delicate > so the sooner this is reviewed (without pushing anything else) the > better. > > The self-tests all pass for me as well as some spot checking. > > Also note that I currently define a single role and it has no > privileges. We will need to fill that in soon. Sorry Rob, but before I can ACK a change of this proportion in the Security model I want a wiki page with the model explained clearly and in detail. I am vetoing this patch until we have that. Note, I am *not* saying the patch is wrong, only that reviewing it w/o a reference model is basically impossible and it touches sensitive security stuff so I can't just let it pass hoping we got everything right. 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] 602 verify --ip-address option during installation
On Tue, 09 Nov 2010 09:50:32 -0500 Rob Crittenden wrote: > Jakub Hrozek wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 11/04/2010 10:00 PM, Rob Crittenden wrote: > >> There was a corner case where the value of --ip-address was never > >> verified if you were also setting up DNS. > >> > >> Added this bit of information to the man page too. > >> > >> ticket 399 > >> > >> rob > >> > > > > Two questions: > > 1) is it intended to quit without printing an error message if > > verify_ip() fails? > > verify_ip_address() prints the message. > > > 2) I don't quite understand the manpage part - it says "and > > --setup-dns is *not* selected" - but the code checks for "if > > options.setup_dns:" > > You can only override the public IP address setting if you are > setting up your own DNS server. Perhaps I should make the text say > that... 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] 617 catch CA retrieval errors
On Wed, 24 Nov 2010 08:51:23 +0100 Jan Zelený wrote: > Rob Crittenden wrote: > > Catch when retrieving the CA chain from dogtag fails and report a > > friendlier error. Also don't try to free the XML document unless it > > has been created. > > > > To test this do an installation on F14 with a dogtag backend without > > fixing the symbolic link > > from /usr/share/java/xalan-j2-serializer.jar > > to /usr/share/tomcat5/common/lib/xalan-j2-serializer.jar > > > > rob > ACK > 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] 615 handle empty members
On Wed, 24 Nov 2010 08:49:36 +0100 Jan Zelený wrote: > Rob Crittenden wrote: > > If an empty member list was passed in we would crap out because we > > were trying to iterate over None. Add a test for this. > > > > ticket 486 > > > > rob > > ACK > 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] 614 Display user and host membership in netgroups.
On Wed, 24 Nov 2010 09:00:24 +0100 Jan Zelený wrote: > Rob Crittenden wrote: > > This uses an enhanced memberof plugin that allows multiple > > attributes to be configured to create memberOf attributes. > > > > This patch requires a new 389-ds-base, 1.2.7. This is currently only > > available in updates-testing. > > > > tickets 109 and 110 > > > > To validate: > > > > # ipa user-add --first=Jim --last=User juser > > # ipa netgroup-add --desc=netgroup net1 > > # ipa netgroup-add-member --users=juser --hosts=`hostname` net1 > > # ipa netgroup-show net1 (should have the host and user as members) > > # ipa user-show juser (should have Member of netgroups) > > # ipa host-show `hostname` (should have Member of netgroups) > > > > rob > > ACK > Ok pushed to master after rebasing the patch. Rob please check as one chunk had to be removed. I believe the change is correct but I prefer you to double-check. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Prompt correctly for required Password params.
Required Password params were prompted for like any other non-Password params, resulting in the password being displayed on the command line and there was no confirmation. Ticket #361 Pavel >From f8451a7b94f226f3e5b4181f464de52e2dfbad2d Mon Sep 17 00:00:00 2001 From: Pavel Zuna Date: Wed, 24 Nov 2010 08:01:31 -0500 Subject: [PATCH] Prompt correctly for required Password params. Ticket #361 --- ipalib/cli.py | 23 +-- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/ipalib/cli.py b/ipalib/cli.py index 41bee7a..3120e01 100644 --- a/ipalib/cli.py +++ b/ipalib/cli.py @@ -515,7 +515,7 @@ class textui(backend.Backend): try: if sys.stdin.isatty(): while True: -pw1 = getpass.getpass('%s: ' % label) +pw1 = getpass.getpass(u'%s: ' % unicode(label)) pw2 = getpass.getpass( unicode(_('Enter %(label)s again to verify: ') % dict(label=label)) ) @@ -887,16 +887,15 @@ class cli(backend.Executioner): ``self.env.prompt_all`` is ``True``, this method will prompt for any params that have a missing values, even if the param is optional. """ -for param in cmd.params(): -if param.password and ( -kw.get(param.name, False) is True or param.name in cmd.args -): -kw[param.name] = \ -self.Backend.textui.prompt_password(param.cli_name) -elif param.name not in kw: -if param.autofill: +for param in cmd.params(): +if (param.required and param.name not in kw) or self.env.prompt_all: +if param.password: +kw[param.name] = self.Backend.textui.prompt_password( +param.label +) +elif param.autofill: kw[param.name] = param.get_default(**kw) -elif param.required or self.env.prompt_all: +else: default = param.get_default(**kw) error = None while True: @@ -910,6 +909,10 @@ class cli(backend.Executioner): break except ValidationError, e: error = e.error +elif param.password and kw.get(param.name, False) is True: +kw[param.name] = self.Backend.textui.prompt_password( +param.label +) def load_files(self, cmd, kw): """ -- 1.7.1.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Rename parent LDAPObject pkeys in child LDAPObject methods.
On 11/19/2010 04:23 PM, Jakub Hrozek wrote: On Tue, Nov 09, 2010 at 04:55:50AM +0100, Pavel Zůna wrote: If the parent and child entries have the same attribute as primary key (such as in the DNS schema), we need to rename the parent key to prevent a param name conflict. It has no side effects, because the primary key name is always taken from the LDAPObject params, never from the method params. Pavel Would you mind rebasing the patch on top of Rob's 593 which is already acked (not pushed yet as of now). Jakub Rebased patch number 35 attached - required by the new DNS plugin. Pavel >From 6325523e8b01fe64ff24dbc1cd2fcb62038a56e3 Mon Sep 17 00:00:00 2001 From: Pavel Zuna Date: Mon, 8 Nov 2010 22:36:04 -0500 Subject: [PATCH] Rename parent LDAPObject pkeys in child LDAPObject methods. If the parent and child entries have the same attribute as primary key (such as in the DNS schema), we need to rename the parent key to prevent a param name conflict. It has no side effects, because the primary key name is always taken from the LDAPObject params, never from the method params. --- ipalib/plugins/baseldap.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 8f723b9..7039f1c 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -232,7 +232,11 @@ class LDAPObject(Object): for key in parent_obj.get_ancestor_primary_keys(): yield key if parent_obj.primary_key: -yield parent_obj.primary_key.clone(query=True) +pkey = parent_obj.primary_key +yield pkey.__class__( +parent_obj.name + pkey.name, required=True, query=True, +cli_name=parent_obj.name, label=pkey.label +) def has_objectclass(self, classes, objectclass): oc = map(lambda x:x.lower(),classes) -- 1.7.1.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add new version of DNS plugin: complete rework with baseldap + unit tests.
On 11/24/2010 03:26 AM, Adam Young wrote: On 11/23/2010 09:37 AM, Pavel Zuna wrote: Finally managed to rewrite the DNS plugin again. Sorry, it took so long, we had training in the office and I also had a nasty bug in baseldap.py I couldn't find. Anyway, this version has it all: - changes we agreed on meeting, the "resource" abstraction is gone and we now only have zones and records = adding new record automatically updates and existing entry or creates it if it wasn't there and deleting the last record deletes the whole entry - all of it transparent to the user - unit tests - ipa help documentation Fixes tickets: #36 #450 I also closed bug #654412. It has a new patch sequence number, because it depends on another patch with a higher number and didn't want to create forward dependencies. Depends on my patches number: 35 (will repost if needed) 38 (posted a while ago on freeipa-devel) Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I keep getting an error when doing simple things like install and ipa help: [ayo...@ipa freeipa]$ ./ipa help dns2 ipa: ERROR: AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipalib/cli.py", line 962, in run api.finalize() File "/home/ayoung/devel/freeipa/ipalib/plugable.py", line 615, in finalize p.instance.finalize() File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 724, in finalize self._create_param_namespace('args') File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 350, in _create_param_namespace sort=False File "/home/ayoung/devel/freeipa/ipalib/base.py", line 407, in __init__ (self.__class__.__name__, name, self.__map[name], member) AttributeError: cannot override NameSpace.idnsname value Str('idnsname', cli_name='name', doc=Gettext('Zone name (FQDN)', domain='ipa', localedir=None), label=Gettext('Zone name', domain='ipa', localedir=None), multivalue=False, normalizer=, primary_key=True, query=True, required=True) with Str('idnsname', attribute=True, cli_name='name', doc=Gettext('Record name', domain='ipa', localedir=None), label=Gettext('Record name', domain='ipa', localedir=None), multivalue=False, primary_key=True, query=True, required=True) ipa: ERROR: an internal error has occurred That's because you need my patch number 35 for it to work... Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel