[Freeipa-devel] [PATCH] Prompt correctly for required Password params.

2010-11-24 Thread Pavel Zuna
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 pz...@redhat.com
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] 617 catch CA retrieval errors

2010-11-24 Thread Simo Sorce
On Wed, 24 Nov 2010 08:51:23 +0100
Jan Zelený jzel...@redhat.com wrote:

 Rob Crittenden rcrit...@redhat.com 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] 609 Reduce the number of attributes a host is allowed to write.

2010-11-24 Thread Rob Crittenden

Simo Sorce wrote:

On Wed, 17 Nov 2010 15:07:03 -0500
Rob Crittendenrcrit...@redhat.com  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.

2010-11-24 Thread Simo Sorce
On Wed, 17 Nov 2010 15:07:03 -0500
Rob Crittenden rcrit...@redhat.com 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] Other issues with HBAC calendar

2010-11-24 Thread Stephen Gallagher
-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 rcrit...@redhat.com 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] Rename parent LDAPObject pkeys in child LDAPObject methods.

2010-11-24 Thread Adam Young

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

Re: [Freeipa-devel] [PATCH] 609 Reduce the number of attributes a host is allowed to write.

2010-11-24 Thread Rob Crittenden

Simo Sorce wrote:

On Wed, 17 Nov 2010 15:07:03 -0500
Rob Crittendenrcrit...@redhat.com  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] Make the migration plugin more configurable

2010-11-24 Thread Jakub Hrozek
-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 jhro...@redhat.com
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 

Re: [Freeipa-devel] [PATCH] Add new version of DNS plugin: complete rework with baseldap + unit tests.

2010-11-24 Thread Adam Young

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=lambda,
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=lambda,
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] Other issues with HBAC calendar

2010-11-24 Thread Dmitri Pal
Stephen Gallagher wrote:
 On 11/23/2010 04:32 PM, Simo Sorce wrote:
  On Tue, 23 Nov 2010 16:07:47 -0500
  Rob Crittenden rcrit...@redhat.com 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.

2010-11-24 Thread Adam Young

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=lambda,
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=lambda,
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

2010-11-24 Thread Dmitri Pal


  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


[Freeipa-devel] [PATCH] admiyo-0102-action-panel-formatting

2010-11-24 Thread Adam Young


From 9bc3cc9897741ac720747ecd4a3b4d4f31de7232 Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
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 = $('li/', {
-'class': 'details-buttons'
-}).prependTo(ul);
+var buttons = $('.action-controls',action_panel);
 
 $('input/', {
 '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 pz...@redhat.com
  *Endi S. Dewata edew...@redhat.com
+ *Adam Young ayo...@redhat.com
  *
  * 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 = $('div/', {
 class: action-panel,
-html: $('h3Actions/h3')
+html: $('h3',{
+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; ientity.facets.length; i++) {
-var other_facet = entity.facets[i];
-var other_facet_name = other_facet.name;
+var other_facet = entity.facets[0];
+var other_facet_name = other_facet.name;
+var main_facet = build_link(other_facet,other_facet.label)
+
+/*assumeing for now that entities with only a single facet 
+  do not have search*/
+if (entity.facets.length  0 ){
+main_facet.text( 'List ' +  IPA.metadata[entity_name].label);
+}
+main_facet.appendTo(ul);
+
+ul.append($('lispan class=action-controls//li'));
+for (var i=1; ientity.facets.length; i++) {
+other_facet = entity.facets[i];
+other_facet_name = other_facet.name;
 
 if (other_facet.label) {
 ul.append(build_link(other_facet,other_facet.label));
diff --git a/install/static/hbacsvc.js b/install/static/hbacsvc.js
index 26a2e8a0a3be71ff23edb0c5c0dd5a6e31b77d29..7dca90ecf90a81f1aac06866386006afcf068f47 100755
--- a/install/static/hbacsvc.js
+++ b/install/static/hbacsvc.js
@@ -98,10 +98,13 @@ function ipa_hbacsvc_search_facet(spec) {
 
 var ul = $('ul', action_panel);
 
+/*Note that we add the rules at the top of the action panel
+  so that the HBAC entities always show in the same order.*/
+
 $('li/', {
 title: 'hbac',
 text: 'HBAC Rules'
-}).appendTo(ul);
+}).prependTo(ul);
 
 $('li/', {
 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);
 
-$('li/', {
-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.*/
 $('li/', {
 title: 'hbacsvc',
 text: 'HBAC Services'
-}).appendTo(ul);
+}).prependTo(ul);
+
+$('li/', {
+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 

Re: [Freeipa-devel] Other issues with HBAC calendar

2010-11-24 Thread Stephen Gallagher
-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


Re: [Freeipa-devel] Other issues with HBAC calendar

2010-11-24 Thread Stephen Gallagher
-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 rcrit...@redhat.com 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] Where we are with SUDO?

2010-11-24 Thread JR Aquino
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 %usergroup_name
* 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

2010-11-24 Thread Simo Sorce
On Wed, 24 Nov 2010 11:26:05 -0500
Dmitri Pal d...@redhat.com 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] Other issues with HBAC calendar

2010-11-24 Thread Dmitri Pal
Simo Sorce wrote:
 On Wed, 24 Nov 2010 11:26:05 -0500
 Dmitri Pal d...@redhat.com 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] Where we are with SUDO?

2010-11-24 Thread Dmitri Pal
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 %usergroup_name
 * 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


[Freeipa-devel] [PATCH] admiyo-0103-navigation-format

2010-11-24 Thread Adam Young


From d0dd106cbc247fb451cdb8f6c4c3d454d914dd38 Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
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^QhEsmqI*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`0z...@oivfb5q)pR6Abx|IB+nh|LNNE
z;otpu$62ldEuHmENnRse#J00o#AkF4vyNlfbI3l)(O$zS(AuOC{^`Q^3hn89
zTfdyWa`kTh)}4=I*GV0b`8Q#I^O)u...@%(5V=Q`Saz~?%#Cd2cjv?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)SU3zAqplDZhZB}
Q9H^DS)78qol`;+00y8a(*OVf

delta 159
zcmeBW+|4*arJk`k$lZxy-8q?;3=9lxn#5=*49x14...@gd9?svi14-?iy0wwg+z8+
zVbZ8pdfpRr`sfEpARRB{tD*Ovl?tUX;ELpZK4J-U(ifC0}Dhey_bcbsFpc}4j|
zuiZYu3iBqcB6OR4bSGCQlGkf?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$N4#t|VKsjF5R4zj(y14XIrMB*rbKBxxZb}sXjon#=i6Q+}
zA^pHO7hlNvG-1^DwqNvJbTIt7zLAP@#!km...@5pav2hbr9x~l(Ue?Mh?W=c{
zb=a!15s#8iy=Q#1tE;Q)yv~fwf6q...@xnep!xpjV4YRTg`CQ*k)w|Fg`pRH!oT
zXIr?qI0tIbKiOCZv%(wkMutK)b_dpz5Oc2vCOjnFzO0QsKdqFQd-Xc^7pfgk-_
zy}`g...@q`fbvSr9cb0hKPv5_?Vi)O`Ag)|V6)h#SEK-...@j;pQaXWXvf4f$or~RNW
z7+Pwl+E7{~z?DT~I5dj33l#iAvr*(LJiv{#{dCiY)u+k(q=`bb1)*hEg77otduGR

Re: [Freeipa-devel] Other issues with HBAC calendar

2010-11-24 Thread Simo Sorce
On Wed, 24 Nov 2010 13:12:02 -0500
Dmitri Pal d...@redhat.com wrote:

 Simo Sorce wrote:
  On Wed, 24 Nov 2010 11:26:05 -0500
  Dmitri Pal d...@redhat.com 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] Host groups and netgroups

2010-11-24 Thread Dmitri Pal
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


[Freeipa-devel] [PATCH]admiyo-0103-navigation-format

2010-11-24 Thread Adam Young


From d0dd106cbc247fb451cdb8f6c4c3d454d914dd38 Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
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^QhEsmqI*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`0z...@oivfb5q)pR6Abx|IB+nh|LNNE
z;otpu$62ldEuHmENnRse#J00o#AkF4vyNlfbI3l)(O$zS(AuOC{^`Q^3hn89
zTfdyWa`kTh)}4=I*GV0b`8Q#I^O)u...@%(5V=Q`Saz~?%#Cd2cjv?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)SU3zAqplDZhZB}
Q9H^DS)78qol`;+00y8a(*OVf

delta 159
zcmeBW+|4*arJk`k$lZxy-8q?;3=9lxn#5=*49x14...@gd9?svi14-?iy0wwg+z8+
zVbZ8pdfpRr`sfEpARRB{tD*Ovl?tUX;ELpZK4J-U(ifC0}Dhey_bcbsFpc}4j|
zuiZYu3iBqcB6OR4bSGCQlGkf?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$N4#t|VKsjF5R4zj(y14XIrMB*rbKBxxZb}sXjon#=i6Q+}
zA^pHO7hlNvG-1^DwqNvJbTIt7zLAP@#!km...@5pav2hbr9x~l(Ue?Mh?W=c{
zb=a!15s#8iy=Q#1tE;Q)yv~fwf6q...@xnep!xpjV4YRTg`CQ*k)w|Fg`pRH!oT
zXIr?qI0tIbKiOCZv%(wkMutK)b_dpz5Oc2vCOjnFzO0QsKdqFQd-Xc^7pfgk-_
zy}`g...@q`fbvSr9cb0hKPv5_?Vi)O`Ag)|V6)h#SEK-...@j;pQaXWXvf4f$or~RNW
z7+Pwl+E7{~z?DT~I5dj33l#iAvr*(LJiv{#{dCiY)u+k(q=`bb1)*hEg77otduGR

Re: [Freeipa-devel] Other issues with HBAC calendar

2010-11-24 Thread Dmitri Pal

 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] Host groups and netgroups

2010-11-24 Thread JR Aquino

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] [PATCH]admiyo-0094-xhtml-to-html

2010-11-24 Thread Adam Young

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

[Freeipa-devel] [PATCH] 619 more aci target docs

2010-11-24 Thread Rob Crittenden

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 rcrit...@redhat.com
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] [PATCH] admiyo-0102-action-panel-formatting

2010-11-24 Thread Endi Sukma Dewata

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 for whoami

2010-11-24 Thread Adam Young

Pushed under the 1 liner rule
From 16b935169c556135dcab2908d102a884f803fda4 Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
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] Make the migration plugin more configurable

2010-11-24 Thread Rob Crittenden

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] build tweaks

2010-11-24 Thread Nalin Dahyabhai
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 na...@redhat.com
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