Re: [Freeipa-devel] [PATCH] Enable filtering search results by member attributes.

2010-12-09 Thread Pavel Zuna 

On 12/08/2010 08:30 PM, Rob Crittenden wrote:

Pavel Zůna wrote:

On 2010-11-30 04:06, Rob Crittenden wrote:

Pavel Zůna wrote:

LDAPSearch base class has now the ability to generate additional
options for objects with member attributes. These options are
used to filter search results - search only for objects without
the specified members.

Any class that extends LDAPSearch can benefit from this functionality.
This patch enables it for the following objects:
group, netgroup, rolegroup, hostgroup, taskgroup

Example:
ipa group-find --no-users=admin

Only direct members are taken into account, but if we need indirect
members as well - it's not a problem.

Ticket #288

Pavel


This works as advertised but I wonder what would happen if a huge list
of members was passed in to ignore. Is there a limit on the search
filter size (remember that the member will be translated into a full dn
so will quickly grow in size).

Should we impose a cofigurable limit on the # of members to be excluded?

Is there a max search filter size and should we check that we haven't
exceeded that before doing a search?

rob


I tried it out with more than a 1000 users and was getting an unwilling
to perform error (search filter nested too deep).

After a little bit of investigation, I figured the filter was being
generated like this:

(((!(a=v))(!(a2=v2

We were going deeper with each additional DN!

I updated the patch to generate the filter like this instead:

(!(|(a=v)(a2=v2)))

Tried it again with more than 1000 users (~55Kb) - it worked and wasn't
even slow.

Updated patch attached.

I also had to fix a bug in ldap2 filter generator, as a result this
patch depends on my patch number 43.

Pavel


You'll need to rebase this against master but otherwise ACK.

It might be a small optimization to de-dupe the no-users list but it
isn't a priority.

rob


Re-based patch attached.

Pavel
From 871b9d2b52175a4209ba2d8bdb12fcc019d871e9 Mon Sep 17 00:00:00 2001
From: Pavel Zuna pz...@redhat.com
Date: Thu, 2 Dec 2010 19:24:11 -0500
Subject: [PATCH] Enable filtering search results by member attributes.

LDAPSearch base class has now the ability to generate additional
options for objects with member attributes. These options are
used to filter search results - search only for objects without
the specified members.

Example:
ipa group-find --no-users=admin

Only direct members are taken into account.

Ticket #288
---
 ipalib/plugins/baseldap.py  |   34 +-
 ipalib/plugins/group.py |2 ++
 ipalib/plugins/hostgroup.py |2 +-
 ipalib/plugins/netgroup.py  |1 +
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 6b7153b..9635f41 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -1124,6 +1124,9 @@ class LDAPSearch(CallbackInterface, crud.Search):
 
 Retrieve all LDAP entries matching the given criteria.
 
+member_attributes = []
+member_param_doc = 'exclude %s with member %s (comma-separated list)'
+
 takes_options = (
 Int('timelimit?',
 label=_('Time Limit'),
@@ -1151,6 +1154,33 @@ class LDAPSearch(CallbackInterface, crud.Search):
 def get_options(self):
 for option in super(LDAPSearch, self).get_options():
 yield option
+for attr in self.member_attributes:
+for ldap_obj_name in self.obj.attribute_members[attr]:
+ldap_obj = self.api.Object[ldap_obj_name]
+name = to_cli(ldap_obj_name)
+doc = self.member_param_doc % (
+self.obj.object_name_plural, ldap_obj.object_name_plural
+)
+yield List('no_%s?' % name, cli_name='no_%ss' % name, doc=doc,
+   label=ldap_obj.object_name)
+
+def get_member_filter(self, ldap, **options):
+filter = ''
+for attr in self.member_attributes:
+for ldap_obj_name in self.obj.attribute_members[attr]:
+param_name = 'no_%s' % to_cli(ldap_obj_name)
+if param_name in options:
+dns = []
+ldap_obj = self.api.Object[ldap_obj_name]
+for pkey in options[param_name]:
+dns.append(ldap_obj.get_dn(pkey))
+flt = ldap.make_filter_from_attr(
+attr, dns, ldap.MATCH_NONE
+)
+filter = ldap.combine_filters(
+(filter, flt), ldap.MATCH_ALL
+)
+return filter
 
 has_output_params = global_output_params
 
@@ -1192,8 +1222,10 @@ class LDAPSearch(CallbackInterface, crud.Search):
 search_kw[a] = term
 term_filter = ldap.make_filter(search_kw, exact=False)
 
+member_filter = self.get_member_filter(ldap, **options)
+
 filter = ldap.combine_filters(
-(term_filter,

Re: [Freeipa-devel] [PATCH/0027] Configure ntp as the first thing

2010-12-09 Thread Simo Sorce 
On Thu, 9 Dec 2010 10:37:47 +0100
Jan Zelený jzel...@redhat.com wrote:

 Simo Sorce sso...@redhat.com wrote:
  We must insure as much as possible that the time is correct on the
  system before installing any component to avoid bad dates in certs,
  ds entries and krb keys.
  
  Fixes bug #595
 
 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

[Freeipa-devel] [PATCH] Introduce new env variable, enable_dns=True, if IPA is managing DNS.

2010-12-09 Thread Pavel Zuna 

if api.env.enable_dns:
print DNS is managed by IPA



ipa env | grep enable_dns: True  /devnull  echo DNS is managed by IPA



Ticket #600

Pavel
From d6031a2bbb1bb5d4b0520d6d56fc4716c3ef2242 Mon Sep 17 00:00:00 2001
From: Pavel Zuna pz...@redhat.com
Date: Thu, 9 Dec 2010 13:10:36 -0500
Subject: [PATCH] Introduce new env variable. enable_dns=True, if IPA is managing DNS.

Ticket #600
---
 install/tools/ipa-server-install |5 -
 ipalib/constants.py  |1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index bed9add..6785acd 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -488,7 +488,8 @@ def main():
 cfg = dict(
 context='installer',
 in_server=True,
-debug=options.debug
+debug=options.debug,
+enable_dns=options.setup_dns,
 )
 
 if options.uninstall:
@@ -677,6 +678,8 @@ def main():
 fd.write(enable_ra=True\n)
 if not options.selfsign:
 fd.write(ra_plugin=dogtag\n)
+if options.setup_dns:
+fd.write(enable_dns=True\n)
 fd.close()
 
 api.bootstrap(**cfg)
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 32c6450..d0ab9fb 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -139,6 +139,7 @@ DEFAULT_CONFIG = (
 # Enable certain optional plugins:
 ('enable_ra', False),
 ('ra_plugin', 'selfsign'),
+('enable_dns', False),
 
 # 
 #  The remaining keys are never set from the values here!
-- 
1.7.1.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0025 Restructure startup code for IPA servers

2010-12-09 Thread Jakub Hrozek 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/07/2010 05:53 PM, Simo Sorce wrote:
 
 With this patch we stop relying on the system to init single ipa
 components and instead introduce a ipa init script that takes care of
 properly starting/stopping all relevant components.
 
 Components are listed with a generic label in LDAP, per server.
 At startup the ipa init script will always start drisrv, then use the
 local socket to query it anonymously[*] and get the list of service to
 start with a ordering paramater.
 
 And it will then proceed to start each single service.
 On failure it will shut them all down.
 
 On stoppping ti shuts them down in inverse order.
 
 Only the ipa service is enabled with chkconfig, all other handled
 services are off in chkconfig and started by the ipa service instead.
 
 [*] We can create an account if we think this is not good enough, but I
 would ask to have a separate ticket and handle this change as an
 additional patch if we feel the need to do that.
 
 Simo.

The patch seems to work fine, I just have one question: the script uses
#!/usr/bin/env python as the interpreter. While this is generally used
in python scripts to allow multiple interpreters, I recall it was
discouraged in Fedora (and I'm pretty sure[1] it is discouraged in RHEL,
although that could be solved by a RHEL-specific patch)

So do we prefer /usr/bin/python or /usr/bin/env python ?

Jakub

[1] https://bugzilla.redhat.com/show_bug.cgi?id=521940
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0A4PQACgkQHsardTLnvCUPWgCfbGF0DX6SD+S7njabAN0E/k8C
6qcAn3OqsH9XDq6AMV1l/xyZ+GTYQVNL
=BKpA
-END PGP SIGNATURE-

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0025 Restructure startup code for IPA servers

2010-12-09 Thread Simo Sorce 
On Thu, 09 Dec 2010 15:00:21 +0100
Jakub Hrozek jhro...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12/07/2010 05:53 PM, Simo Sorce wrote:
  
  With this patch we stop relying on the system to init single ipa
  components and instead introduce a ipa init script that takes
  care of properly starting/stopping all relevant components.
  
  Components are listed with a generic label in LDAP, per server.
  At startup the ipa init script will always start drisrv, then use
  the local socket to query it anonymously[*] and get the list of
  service to start with a ordering paramater.
  
  And it will then proceed to start each single service.
  On failure it will shut them all down.
  
  On stoppping ti shuts them down in inverse order.
  
  Only the ipa service is enabled with chkconfig, all other handled
  services are off in chkconfig and started by the ipa service
  instead.
  
  [*] We can create an account if we think this is not good enough,
  but I would ask to have a separate ticket and handle this change as
  an additional patch if we feel the need to do that.
  
  Simo.
 
 The patch seems to work fine, I just have one question: the script
 uses #!/usr/bin/env python as the interpreter. While this is
 generally used in python scripts to allow multiple interpreters, I
 recall it was discouraged in Fedora (and I'm pretty sure[1] it is
 discouraged in RHEL, although that could be solved by a RHEL-specific
 patch)
 
 So do we prefer /usr/bin/python or /usr/bin/env python ?
 
   Jakub
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=521940

I just copied that part from another of our scripts.
If you think we should change this, I would open a generic ticket and
go through all the python script and make a consistent change to all of
them.

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] 635 wait for memberof plugin when doing reverse members

2010-12-09 Thread Rob Crittenden 

Jan Zelený wrote:

Rob Crittendenrcrit...@redhat.com  wrote:

Give the memberof plugin time to work when adding/removing reverse members.

When we add/remove reverse members it looks like we're operating on
group A but we're really operating on group B. This adds/removes the
member attribute on group B and the memberof plugin adds the memberof
attribute into group A.

We need to give the memberof plugin a chance to do its work so loop a
few times, reading the entry to see if the number of memberof is more or
less what we expect. Bail out if it is taking too long.

ticket 560

rob


About that FIXME you got there: I'm not sure if it wouldn't be better to
handle the possible exception right in the wait_for_memberof method (I guess
it depends on what exception are we expecting and what are we going to do with
it?). If you want the exception to reach the calling function, I'd like to see
some kind of exception handling in that function - either to let the user know
that the error occurred during this waiting or maybe to disregard the
exception and continue normal operation.


The types of exceptions could run the gambit but I was wondering what 
would happen if we were looping and some other user deleted the role. 
The next search for it would fail with NotFound. Granted this isn't a 
very friendly message to return to someone after adding a member to the 
group but it does sort of make sense (someone deleted it concurrently). 
It seemed best to just let this filter up to the caller.




Some nitpicking: I'm confused - in the doc string you state that this will
loop for 6+ seconds and a couple lines below, you have a comment Don't sleep
for more that 6 seconds - is there a mistake ar are these two statements
unrelated?


Yeah, I was afraid that might be confusing. I'll wait .3 seconds 20 
times so 6 seconds. There are a few LDAP calls which take a bit of time 
as well, so it will be 6+ seconds if it goes the whole time.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 636 Properly handle multi-valued attributes when using setattr/addattr

2010-12-09 Thread Rob Crittenden 

Jan Zelený wrote:

Rob Crittendenrcrit...@redhat.com  wrote:

The problem was that the normalizer was returning each value as a tuple
which we were then appending to a list, so it looked like [(u'value1',),
(u'value2',),...]. If there was a single value we could end up adding a
tuple to a list which would fail. Additionally python-ldap doesn't like
lists of lists so it was failing later in the process as well.

I've added some simple tests for setattr and addattr.

ticket 565


One question? Why are you removing radiusprofile string in chunk #3? Other than
that the patch is fine.


I had removed it from the default user objectclasses in another patch 
and hadn't removed it here. I'm removing it now so the tests I added pass.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Introduce new env variable, enable_dns=True, if IPA is managing DNS.

2010-12-09 Thread Dmitri Pal 
Question:

Do we support situation when one replica has DNS and another does not?
In other words is DNS integration an instance property or a domain property?
I do not know is it a good or a bad thing but if it is per instance the UI/CLI 
from the same client will act differently depending on the DNS configuration of 
the instance.
Might be very confusing. At least we need to document it to set the right 
expectations. Otherwise if the CLI/UI failed over to not DNS enabled replica 
the admin would be puzzled why his command line stopped working or where the 
DNS panel in the UI.

Thoughts?

- Original Message -
From: Pavel Zuna pz...@redhat.com
To: freeipa-devel freeipa-devel@redhat.com
Sent: Thursday, December 9, 2010 8:52:42 AM GMT -05:00 US/Canada Eastern
Subject: [Freeipa-devel] [PATCH] Introduce new env variable, enable_dns=True, 
if IPA is managing DNS.

if api.env.enable_dns:
print DNS is managed by IPA



ipa env | grep enable_dns: True  /devnull  echo DNS is managed by IPA



Ticket #600

Pavel

___
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] [PATCH] Introduce new env variable, enable_dns=True, if IPA is managing DNS.

2010-12-09 Thread Adam Young 

On 12/09/2010 09:17 AM, Dmitri Pal wrote:

Question:

Do we support situation when one replica has DNS and another does not?
In other words is DNS integration an instance property or a domain property?
I do not know is it a good or a bad thing but if it is per instance the UI/CLI 
from the same client will act differently depending on the DNS configuration of 
the instance.
Might be very confusing. At least we need to document it to set the right 
expectations. Otherwise if the CLI/UI failed over to not DNS enabled replica 
the admin would be puzzled why his command line stopped working or where the 
DNS panel in the UI.

Thoughts?
   
In those cases, the LDAP values will get syncronized, but the DNS server 
just won't show them, right?


My understanding is that, In this patch, the value is put into the 
config file, and so it will reflect the state of the server, not the 
LDAP database.  Thus, this is the right approach.





- Original Message -
From: Pavel Zunapz...@redhat.com
To: freeipa-develfreeipa-devel@redhat.com
Sent: Thursday, December 9, 2010 8:52:42 AM GMT -05:00 US/Canada Eastern
Subject: [Freeipa-devel] [PATCH] Introduce new env variable, enable_dns=True, 
if IPA is managing DNS.

if api.env.enable_dns:
print DNS is managed by IPA



ipa env | grep enable_dns: True  /devnull  echo DNS is managed by IPA



Ticket #600

Pavel

___
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
   


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

2010-12-09 Thread JR Aquino 


On 12/9/10 10:03 AM, Dmitri Pal d...@redhat.com wrote:

Nalin Dahyabhai wrote:
 On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote:
   
 I guess the piece that is still missing then is:

 Instead of:

 sudoHost: hostname.com

 It should be:

 sudoHost: +production - which is the group assigned to the
ipasudorule.
 

 The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in
 the rule is a hostgroup but not a netgroup, so I think it's doing the
 right thing by resolving the group down to its members' names.

   
JR,

Can we check that we are running with the same test data set?
In the data set that Nalin uses the sudo rule points to a host group so
according to the rules it gets expanded.
Have you implemented a capability to add a netgroup to the the
memberHost in the SUDO plugin?
If you make a netgroup a member of the SUDO rule the compat plugin will
do what you expect.

Thanks
Dmitri

Dmitri, you were absolutely correct!!!

Thank you for setting me straight.

Changing the memberhost in the sudorole from a hostgroup to a netgroup
solved the issue.  It is representing correctly as +prod now!

Observation:

A ticket was created for me to design a 'Managed Entry' plugin which
automatically mirrored netgroups out of hostgroups which are created.

FreeIPA's implementation of sudo has thus far been separated between, an
IPAsudo object, and a compat translated sudo object.

Might it be a more lasting solution to have the compat and sudo plugin
refer to the hostgroup object and allow for the Managed Entry and 'NIS
Compat' pieces handle the sudo native translations?

That way we have a stand alone ipa centric model that allows us to
completely strip away the translation pieces when they are no longer
necessary (when sudo supports sssd).

Or would it make more sense to just modify the sudo plugin to allow for: a
single host, a hostgroup, and a netgroup as options for the memberHost
attr?

Thoughts?



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

2010-12-09 Thread Dmitri Pal 
JR Aquino wrote:
 On 12/9/10 10:03 AM, Dmitri Pal d...@redhat.com wrote:

   
 Nalin Dahyabhai wrote:
 
 On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote:
   
   
 I guess the piece that is still missing then is:

 Instead of:

 sudoHost: hostname.com

 It should be:

 sudoHost: +production - which is the group assigned to the
 ipasudorule.
 
 
 The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in
 the rule is a hostgroup but not a netgroup, so I think it's doing the
 right thing by resolving the group down to its members' names.

   
   
 JR,

 Can we check that we are running with the same test data set?
 In the data set that Nalin uses the sudo rule points to a host group so
 according to the rules it gets expanded.
 Have you implemented a capability to add a netgroup to the the
 memberHost in the SUDO plugin?
 If you make a netgroup a member of the SUDO rule the compat plugin will
 do what you expect.

 Thanks
 Dmitri
 

 Dmitri, you were absolutely correct!!!

 Thank you for setting me straight.

 Changing the memberhost in the sudorole from a hostgroup to a netgroup
 solved the issue.  It is representing correctly as +prod now!

 Observation:

 A ticket was created for me to design a 'Managed Entry' plugin which
 automatically mirrored netgroups out of hostgroups which are created.

 FreeIPA's implementation of sudo has thus far been separated between, an
 IPAsudo object, and a compat translated sudo object.

 Might it be a more lasting solution to have the compat and sudo plugin
 refer to the hostgroup object and allow for the Managed Entry and 'NIS
 Compat' pieces handle the sudo native translations?

 That way we have a stand alone ipa centric model that allows us to
 completely strip away the translation pieces when they are no longer
 necessary (when sudo supports sssd).

 Or would it make more sense to just modify the sudo plugin to allow for: a
 single host, a hostgroup, and a netgroup as options for the memberHost
 attr?

   
I think this is how it is designed right now.
The migration to host groups will be slow and painful.
I think that approach we planned covers all main use cases and provides
enough flexibility for administrators transition from old models and
concepts to the new ones.
There will be need to the compatibility for older clients for the years
to come.


 Thoughts?


   


-- 
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] sudo and netgroup schema compat updates

2010-12-09 Thread Dmitri Pal 
JR Aquino wrote:
 I think this is how it is designed right now.
 The migration to host groups will be slow and painful.
 I think that approach we planned covers all main use cases and provides
 enough flexibility for administrators transition from old models and
 concepts to the new ones.
 There will be need to the compatibility for older clients for the years
 to come.
 

 The design doc seems to disagree:
 http://freeipa.org/page/SUDO_Schema_Design

 objectclass: ipaSudoRule
 ...
 memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
 ...

 Just to review, so that I can make sure the patch is posted correctly:

 The current Sudo Compat Plugin functions as long as:
 An IPASudoRule can consist of:

 memberUser: Single_User|Group
 memberAllowCmd: Single_CMD|SudoCmdGroup
 memberDenyCmd: Single_CMD|SudoCmdGroup
 memberHost: Single_Host|ipaNetGroup ???

 ^ The Schema Design originally suggested that for an ipaSudoRule an
 ipaHostGroup would be used.
   

http://www.freeipa.org/page/SUDO_Schema_Design#Why_we_must_support_netgroups_in_the_SUDO_rules.3F
Last paragraph of the section. Also see last open question and answer to
it on the page :-)

However... read further...

 This ipaHostGroup would then be duplicated into a ipaNetGroup (Managed
 Entry). 
 This ipaNetGroup would then be translated into an ldap backed nisNetGroup
 (Compat).

 I am ok changing the sudorule plugin to point memberHost to an
 ipaNetgroup, however, I think we need to be correct and clear in all the
 previous references.
 There are a LOT of moving parts behind the scenes to make this work
 natively, so the chance for confusion is very high.

 What I was suggesting, was that perhaps its not necessary to change the
 sudorule plugin if the eventual end goal is to utilize hostgroups
 natively.  The compat pieces and Managed Entry pieces already handle the
 translation as elegantly as they can given the circumstances.

 Is there a negative aspect of having the SudoCompat piece look to an
 ipaHostgroup for its conversion?
   
I just talked to Nalin and you might be right we can eliminate the need
to support the netgroups in the sudo rule for hosts altogether.
Since each host group will have a corresponding netgroup (until it is
explicitly turned off by admin and it can be turned off only when the
clients do not need netgroups any more which will be many years from
now) the compat plugin can check if there is a corresponding netgroup,
and if there is, use netgroup notation in the generated SUDO rule
instead of expanding the rule to contain the host attributes verbatim.

This looks like a nice and elegant solution but this means that we
*require* the use of the host groups with netgroups. So if the
deployment  has a netgroup that has hosts A,B,C we require the hosts A,B
 C be put into a host group. If admin just creates a new netgroup with
hosts A, B, C in IPA he would not be able to use this netgroup in the
SUDO part at all. May be it is Ok. It will really discourage people from
using the netgroups. If we can require admins to always create a top
level host group for any netgroup they want to have for whatever reason
and this is acceptable then we can avoid allowing direct referencing
netgroups in the rule and thus do not need to add this capability to
SUDO plugin. It will actually save some future work on SSSD too since it
would not need to resolve the netgroups - just host groups.

After some thinking IMO the right approach would be:
1) Adjust the compat plugin as described above
2) Do not add capability to SODO mgmt plugin to point to the netgroup in
the SUDO rule
3) Document the considerations about the netgroups migration
(https://fedorahosted.org/freeipa/ticket/37)   

Thoughts?

 Thanks!

 -JR

   


-- 
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] 632 add migration cmd docs

2010-12-09 Thread Rob Crittenden 

Jakub Hrozek wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/07/2010 05:50 PM, Rob Crittenden wrote:

Add some documentation to the migrate-ds command.

rob



Ack


pushed to master

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 638 be smarter with alwaysask option

2010-12-09 Thread Rob Crittenden 

Jan Zelený wrote:

Rob Crittendenrcrit...@redhat.com  wrote:

The alwaysask option for params was meant to prompt for things that are
needed but not strictly required, like when adding members to a group.

We don't need to prompt if something is provided on the command-line
though.

ticket 604

rob


ACK



pushed to master

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

2010-12-09 Thread JR Aquino 


On 12/9/10 11:59 AM, Dmitri Pal d...@redhat.com wrote:
http://www.freeipa.org/page/SUDO_Schema_Design#Why_we_must_support_netgrou
ps_in_the_SUDO_rules.3F
Last paragraph of the section. Also see last open question and answer to
it on the page :-)

However... read further...

Ah Ha!

I just talked to Nalin and you might be right we can eliminate the need
to support the netgroups in the sudo rule for hosts altogether.
Since each host group will have a corresponding netgroup (until it is
explicitly turned off by admin and it can be turned off only when the
clients do not need netgroups any more which will be many years from
now) the compat plugin can check if there is a corresponding netgroup,
and if there is, use netgroup notation in the generated SUDO rule
instead of expanding the rule to contain the host attributes verbatim.

This looks like a nice and elegant solution but this means that we
*require* the use of the host groups with netgroups. So if the
deployment  has a netgroup that has hosts A,B,C we require the hosts A,B
 C be put into a host group. If admin just creates a new netgroup with
hosts A, B, C in IPA he would not be able to use this netgroup in the
SUDO part at all. May be it is Ok. It will really discourage people from
using the netgroups. If we can require admins to always create a top
level host group for any netgroup they want to have for whatever reason
and this is acceptable then we can avoid allowing direct referencing
netgroups in the rule and thus do not need to add this capability to
SUDO plugin. It will actually save some future work on SSSD too since it
would not need to resolve the netgroups - just host groups.

Agreed.
As a side note to think about:
Currently, with the proposed Managed Plungins, netgroups which are created
as a result of the hostgroup creation, are not searchable via the IPA Cli.
 This requested by Item #3 (https://fedorahosted.org/freeipa/ticket/543).

This generally means that by default, all hostgroups get an implied (but
invisible) netgroup.
The only netgroups that turn up in the search are those created directly
through the cli.

Not sure how this effects the greater world at large.


After some thinking IMO the right approach would be:
1) Adjust the compat plugin as described above
2) Do not add capability to SODO mgmt plugin to point to the netgroup in
the SUDO rule
3) Document the considerations about the netgroups migration
(https://fedorahosted.org/freeipa/ticket/37)

I agree, this sounds like the most sane path to follow.
I do think it would be courteous to the potential nis/netgroup users of
the world, for us to be very clear about the backend behavior regarding
the Managed Entries though.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

2010-12-09 Thread Nalin Dahyabhai 
On Thu, Dec 09, 2010 at 02:59:55PM -0500, Dmitri Pal wrote:
 1) Adjust the compat plugin as described above

Attached for testing.  Patch 0001 we've seen before; 0002's new.

Nalin
From 1afcb4d6163f5b8137cb1f2e832714e046345ca7 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 30 Nov 2010 18:25:33 -0500
Subject: [PATCH 1/2] sudo and netgroup schema compat updates
 - fix quoting of netgroup entries
 - don't bother looking for members of netgroups by looking for entries
   which list memberOf: $netgroup -- the netgroup should list them as
   member values
 - use newer slapi-nis functionality to produce cn=sudoers
 - drop the real cn=sudoers container to make room for the compat
   container

---
 install/share/bootstrap-template.ldif |6 -
 install/share/schema_compat.uldif |   37 
 ipa.spec.in   |2 +-
 3 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/install/share/bootstrap-template.ldif 
b/install/share/bootstrap-template.ldif
index 4f10f07..81eb5d6 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
 objectClass: nsContainer
 cn: sudorules
 
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
 dn: cn=etc,$SUFFIX
 changetype: add
 objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index 22e3141..52c8d5a 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -47,7 +47,6 @@ default:schema-compat-entry-attribute: objectclass=posixGroup
 default:schema-compat-entry-attribute: gidNumber=%{gidNumber}
 default:schema-compat-entry-attribute: memberUid=%{memberUid}
 default:schema-compat-entry-attribute: memberUid=%deref(member,uid)
-default:schema-compat-entry-attribute: 
memberUid=%referred(cn=users,memberOf,uid)
 
 dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
 add:objectClass: top
@@ -56,14 +55,42 @@ add:cn: ng
 add:schema-compat-container-group: 'cn=compat, $SUFFIX'
 add:schema-compat-container-rdn: cn=ng
 add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
 add:schema-compat-entry-rdn: cn=%{cn}
 add:schema-compat-entry-attribute: objectclass=nisNetgroup
 add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
-add:schema-compat-entry-attribute: 
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute: 
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute: 
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter: 
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%deref_f(\memberUser\,\(objectclass=posixAccount)\,\uid\))'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%deref_rf(\memberUser\,\((objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\,\member\,\(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\,\uid\))'
+add:schema-compat-entry-attribute: 
'sudoUser=%ifeq(userCategory,all,ALL,%%%deref_f(\memberUser\,\(objectclass=posixGroup)\,\cn\))'
+add:schema-compat-entry-attribute:

Re: [Freeipa-devel] [PATCH] SUDO adjustments

2010-12-09 Thread Adam Young 

On 12/09/2010 10:31 AM, Endi Sukma Dewata wrote:

Hi,

Please review the attached patch. Thanks!

https://fedorahosted.org/reviewboard/r/114/

The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.

The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.

The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.

The last section is currently not working because backend support is
not yet available.

The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.

The HBAC rule details facet has been updated as well.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

ACK.  Pushed to master


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Section header prefix update

2010-12-09 Thread Adam Young 

On 12/09/2010 11:54 AM, Endi Sukma Dewata wrote:

Hi,

Please review the attached patch. This should fix this ticket:

https://fedorahosted.org/freeipa/ticket/552

The '+' and '-' signs before the section headers in details facet
are now enclosed in square brackets. The section content is now
hidden/shown using slideToggle().

The ipa_details_create() and ipa_details_setup() have been moved
into ipa_details_facet.

Thanks!


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

ACK
pushed to master
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] Account activation adjustment

2010-12-09 Thread Endi Sukma Dewata 

Hi,

Please review the attached patch. This should fix this bug:

https://fedorahosted.org/freeipa/ticket/462

The user details facet has been modified such that when the account
is activated/deactivated the page will be reloaded.

Some methods in the framework have been changed:
 - The ipa_widget.clear() has been removed because it can be replaced
   by existing reset().
 - The ipa_widget.set_values() has been renamed into update().

Thanks!

--
Endi S. Dewata
From 424bc5785731a2862bbd8bd3dfcd751769d2c07f Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Thu, 9 Dec 2010 14:20:40 -0600
Subject: [PATCH] Account activation adjustment

The user details facet has been modified such that when the account
is activated/deactivated the page will be reloaded.

Some methods in the framework have been changed:
 - The ipa_widget.clear() has been removed because it can be replaced
   by existing reset().
 - The ipa_widget.set_values() has been renamed into update().
---
 install/static/add.js|2 +-
 install/static/associate.js  |2 +-
 install/static/details.js|   34 +---
 install/static/hbac.js   |   16 ++--
 install/static/test/details_tests.js |4 +-
 install/static/user.js   |  136 +++---
 install/static/widget.js |   55 +-
 7 files changed, 128 insertions(+), 121 deletions(-)

diff --git a/install/static/add.js b/install/static/add.js
index f2eebb8ac2992a5332f6aa929265b5c00898fb69..0048f4b105a2dcc38526a70a28e409b78c750aca 100644
--- a/install/static/add.js
+++ b/install/static/add.js
@@ -57,7 +57,7 @@ function ipa_add_dialog(spec) {
 var facet = entity.get_facet('search');
 var table = facet.table;
 table.refresh();
-that.clear();
+that.reset();
 }
 );
 });
diff --git a/install/static/associate.js b/install/static/associate.js
index 540b1a80f7ee36cbf647ecfdab83be2ad457a5b9..1e6d6b908116aeca75aff01e4922b27ee7e1048b 100644
--- a/install/static/associate.js
+++ b/install/static/associate.js
@@ -364,7 +364,7 @@ function ipa_association_table_widget(spec) {
 that.reset();
 };
 
-that.set_values = function(values) {
+that.update = function() {
 
 that.empty();
 
diff --git a/install/static/details.js b/install/static/details.js
index fcf04ffd1041ec5074e57e3f17c9076b5cd1a9c6..853635b13a67511530c05f2dd16b32786da27f68 100644
--- a/install/static/details.js
+++ b/install/static/details.js
@@ -40,13 +40,13 @@ function ipa_details_field(spec) {
 that.load = spec.load || load;
 that.save = spec.save || save;
 
-function load(result) {
-that.record = result;
-that.values = result[that.name];
+function load(record) {
+that.record = record;
+that.values = record[that.name];
 that.reset();
 }
 
-that.set_values = function(values) {
+that.update = function() {
 
 if (!that.record) return;
 
@@ -332,20 +332,28 @@ function ipa_details_list_section(spec){
 }
 };
 
-// This is to allow declarative style programming for details
-function input(spec){
-that.create_field(spec);
-return that;
-}
-
-that.input = input;
-
 return that;
 }
 
 // shorthand notation used for declarative definitions of details pages
 function ipa_stanza(spec) {
-return ipa_details_list_section(spec);
+
+spec = spec || {};
+
+var that = ipa_details_list_section(spec);
+
+// This is to allow declarative style programming for details
+that.input = function(spec) {
+that.create_field(spec);
+return that;
+};
+
+that.custom_input = function(input) {
+that.add_field(input);
+return that;
+};
+
+return that;
 }
 
 function ipa_details_facet(spec) {
diff --git a/install/static/hbac.js b/install/static/hbac.js
index 213dd3e4804e55de26232a19ad3c2acc7f89ae94..d0188fa5a7d00593441e61135798f8687462b552 100755
--- a/install/static/hbac.js
+++ b/install/static/hbac.js
@@ -806,25 +806,25 @@ function ipa_hbac_accesstime_widget(spec) {
 }
 };
 
-that.load = function(result) {
+that.load = function(record) {
 
-that.values = result[that.name] || [];
+that.values = record[that.name] || [];
 that.reset();
 };
 
-that.set_values = function(values) {
+that.update = function() {
 
-that.set_radio_value(that.container, values  values.length ? '' : 'all');
+that.set_category(that.container, that.values  that.values.length ? '' : 'all');
 
 that.table.tbody.empty();
-for (var i=0; values  ivalues.length; i++) {
+for (var i=0; that.values  ithat.values.length; i++) {
 var record = {};
-record[that.name] = values[i];
+record[that.name] = that.values[i];

[Freeipa-devel] [PATCH] admiyo-0114-Section-header-prefix-update

2010-12-09 Thread Adam Young 
This patch was mostly done by Kyle Baker.  I just rebased it by hand.  
Need to change the authorship on it.
From 0938fb70eeb69d7bcc0f54a99d7650c166a1a88d Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Thu, 9 Dec 2010 10:43:21 -0600
Subject: [PATCH] Section header prefix update

The '+' and '-' signs before the section headers in details facet
are now enclosed in square brackets. The section content is now
hidden/shown using slideToggle().

The ipa_details_create() and ipa_details_setup() have been moved
into ipa_details_facet.
---
 install/static/details.js |  220 +---
 1 files changed, 105 insertions(+), 115 deletions(-)

diff --git a/install/static/details.js b/install/static/details.js
index e3cee071fd7aa0652c708dc18c70e0c3b39b54e6..fcf04ffd1041ec5074e57e3f17c9076b5cd1a9c6 100644
--- a/install/static/details.js
+++ b/install/static/details.js
@@ -355,8 +355,8 @@ function ipa_details_facet(spec) {
 var that = ipa_facet(spec);
 
 that.is_dirty = spec.is_dirty || is_dirty;
-that.create = spec.create || ipa_details_create;
-that.setup = spec.setup || ipa_details_setup;
+that.create = spec.create || create;
+that.setup = spec.setup || setup;
 that.load = spec.load || load;
 that.update = spec.update || ipa_details_update;
 that.reset = spec.reset || reset;
@@ -405,6 +405,109 @@ function ipa_details_facet(spec) {
 return that.record[pkey_name][0];
 };
 
+that.get_section_header_prefix = function(visible) {
+if (visible) {
+return '[#8722;]';
+} else {
+return '[+]';
+}
+};
+
+function create(container) {
+
+container.attr('title', that.entity_name);
+
+var details = $('div/', {
+'class': 'content'
+}).appendTo(container);
+
+var action_panel = that.get_action_panel();
+
+var ul = $('ul', action_panel);
+var buttons = $('.action-controls',action_panel);
+
+$('input/', {
+'type': 'text',
+'name': 'reset'
+}).appendTo(buttons);
+
+$('input/', {
+'type': 'text',
+'name': 'update'
+}).appendTo(buttons);
+
+details.append('br/');
+details.append('hr/');
+
+for (var i = 0; i  that.sections.length; ++i) {
+var section = that.sections[i];
+
+$('h2/', {
+'name': section.name,
+'html': that.get_section_header_prefix(true) + ' ' + section.label
+}).appendTo(details);
+
+var div = $('div/', {
+'id': that.entity_name+'-'+that.name+'-'+section.name,
+'class': 'details-section'
+}).appendTo(details);
+
+section.create(div);
+
+details.append('hr/');
+}
+}
+
+function setup(container) {
+
+that.facet_setup(container);
+
+var button = $('input[name=reset]', that.container);
+that.reset_button = ipa_button({
+'label': 'Reset',
+'icon': 'ui-icon-refresh',
+'class': 'details-reset',
+'click': function() {
+that.reset();
+return false;
+}
+});
+button.replaceWith(that.reset_button);
+
+button = $('input[name=update]', that.container);
+that.update_button = ipa_button({
+'label': 'Update',
+'icon': 'ui-icon-check',
+'class': 'details-update',
+'click': function() {
+that.update();
+return false;
+}
+});
+button.replaceWith(that.update_button);
+
+for (var i = 0; i  that.sections.length; ++i) {
+var section = that.sections[i];
+
+var header = $('h2[name='+section.name+']', that.container);
+
+var div = $(
+'#'+that.entity_name+'-'+that.name+'-'+section.name,
+that.container
+);
+
+header.click(function(section, header, div) {
+return function() {
+var visible = div.is(:visible);
+header.html(that.get_section_header_prefix(!visible) + ' ' + section.label);
+div.slideToggle();
+}
+}(section, header, div));
+
+section.setup(div);
+}
+}
+
 function is_dirty() {
 var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
 return pkey != that.pkey;
@@ -450,103 +553,6 @@ function ipa_button(spec) {
 return button;
 }
 
-function ipa_details_create(container)
-{
-var that = this;
-
-if (!container) {
-alert('ERROR: ipa_details_create: Missing container argument!');
-return;
-}
-
-container.attr('title', that.entity_name);
-
-var details = $('div/', {
-'class': 'content'
-}).appendTo(container);

Re: [Freeipa-devel] [PATCH] Account activation adjustment

2010-12-09 Thread Endi Sukma Dewata 

On 12/9/2010 3:17 PM, Endi Sukma Dewata wrote:

Please review the attached patch. This should fix this bug:

https://fedorahosted.org/freeipa/ticket/462

The user details facet has been modified such that when the account
is activated/deactivated the page will be reloaded.

Some methods in the framework have been changed:
- The ipa_widget.clear() has been removed because it can be replaced
by existing reset().
- The ipa_widget.set_values() has been renamed into update().


Forgot to include the latest changes. Attached is a new patch. Thanks!

--
Endi S. Dewata
From 1f9b00ca8f04818e7da3f37298185f8280a0e60f Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Thu, 9 Dec 2010 14:20:40 -0600
Subject: [PATCH] Account activation adjustment

The user details facet has been modified such that when the account
is activated/deactivated the page will be reloaded.

Some methods in the framework have been changed:
 - The ipa_widget.clear() has been removed because it can be replaced
   by existing reset().
 - The ipa_widget.set_values() has been renamed into update().
---
 install/static/add.js|2 +-
 install/static/associate.js  |2 +-
 install/static/details.js|   34 +---
 install/static/hbac.js   |   16 ++--
 install/static/test/details_tests.js |4 +-
 install/static/user.js   |  136 +++---
 install/static/widget.js |   68 +++---
 7 files changed, 135 insertions(+), 127 deletions(-)

diff --git a/install/static/add.js b/install/static/add.js
index f2eebb8ac2992a5332f6aa929265b5c00898fb69..0048f4b105a2dcc38526a70a28e409b78c750aca 100644
--- a/install/static/add.js
+++ b/install/static/add.js
@@ -57,7 +57,7 @@ function ipa_add_dialog(spec) {
 var facet = entity.get_facet('search');
 var table = facet.table;
 table.refresh();
-that.clear();
+that.reset();
 }
 );
 });
diff --git a/install/static/associate.js b/install/static/associate.js
index 540b1a80f7ee36cbf647ecfdab83be2ad457a5b9..1e6d6b908116aeca75aff01e4922b27ee7e1048b 100644
--- a/install/static/associate.js
+++ b/install/static/associate.js
@@ -364,7 +364,7 @@ function ipa_association_table_widget(spec) {
 that.reset();
 };
 
-that.set_values = function(values) {
+that.update = function() {
 
 that.empty();
 
diff --git a/install/static/details.js b/install/static/details.js
index fcf04ffd1041ec5074e57e3f17c9076b5cd1a9c6..853635b13a67511530c05f2dd16b32786da27f68 100644
--- a/install/static/details.js
+++ b/install/static/details.js
@@ -40,13 +40,13 @@ function ipa_details_field(spec) {
 that.load = spec.load || load;
 that.save = spec.save || save;
 
-function load(result) {
-that.record = result;
-that.values = result[that.name];
+function load(record) {
+that.record = record;
+that.values = record[that.name];
 that.reset();
 }
 
-that.set_values = function(values) {
+that.update = function() {
 
 if (!that.record) return;
 
@@ -332,20 +332,28 @@ function ipa_details_list_section(spec){
 }
 };
 
-// This is to allow declarative style programming for details
-function input(spec){
-that.create_field(spec);
-return that;
-}
-
-that.input = input;
-
 return that;
 }
 
 // shorthand notation used for declarative definitions of details pages
 function ipa_stanza(spec) {
-return ipa_details_list_section(spec);
+
+spec = spec || {};
+
+var that = ipa_details_list_section(spec);
+
+// This is to allow declarative style programming for details
+that.input = function(spec) {
+that.create_field(spec);
+return that;
+};
+
+that.custom_input = function(input) {
+that.add_field(input);
+return that;
+};
+
+return that;
 }
 
 function ipa_details_facet(spec) {
diff --git a/install/static/hbac.js b/install/static/hbac.js
index 213dd3e4804e55de26232a19ad3c2acc7f89ae94..d0188fa5a7d00593441e61135798f8687462b552 100755
--- a/install/static/hbac.js
+++ b/install/static/hbac.js
@@ -806,25 +806,25 @@ function ipa_hbac_accesstime_widget(spec) {
 }
 };
 
-that.load = function(result) {
+that.load = function(record) {
 
-that.values = result[that.name] || [];
+that.values = record[that.name] || [];
 that.reset();
 };
 
-that.set_values = function(values) {
+that.update = function() {
 
-that.set_radio_value(that.container, values  values.length ? '' : 'all');
+that.set_category(that.container, that.values  that.values.length ? '' : 'all');
 
 that.table.tbody.empty();
-for (var i=0; values  ivalues.length; i++) {
+for (var i=0; that.values  ithat.values.length; i++) {
 var record = {};
-

[Freeipa-devel] [PATCH 5] managed entry hostgroup netgroup support

2010-12-09 Thread JR Aquino 
These 2 patches address all of the items within
(https://fedorahosted.org/freeipa/ticket/543)

Included are:

* ldif for the hostgroup -to- netgroup Managed Entry Plugin
* dsinstance modifications to correctly install the ldif
* management script (ipa-host-net-manage)
* man page for documentation
* Makefile mods for installation of management script and man page
* ipa.spec.in and ipa.1 to reflect inclusion

Please review.



freeipa-jraquino-0005-managed-entry-hostgroup-netgroup-support.patch
Description: freeipa-jraquino-0005-managed-entry-hostgroup-netgroup-support.patch


freeipa-jraquino-0006-managed-entry-hostgroup-netgroup-support.patch
Description: freeipa-jraquino-0006-managed-entry-hostgroup-netgroup-support.patch
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel