[Freeipa-devel] [PATCH] Prompt correctly for required Password params.
Required Password params were prompted for like any other non-Password params,
resulting in the password being displayed on the command line and there was no
confirmation.
Ticket #361
Pavel
From f8451a7b94f226f3e5b4181f464de52e2dfbad2d Mon Sep 17 00:00:00 2001
From: Pavel Zuna 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
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.
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.
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
-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.
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.
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
-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.
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
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.
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
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
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
-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
-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?
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
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
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?
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
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
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
Hello, It is well known that with IPA we want to try to move people from the netgroups to host groups but many companies currently use netgroups as hostgroups. To simplify migration I suggest that we by default always create a managed nisnetgroup entry that would map 1-1 to the host group using managed entry plugin. The logic would work the following way: 1) When the host group is created the netgroup also will be created with the same name and memberHost attribute pointing to the DN of the newly created host group 2) The deletion of the host group will automatically remove managed netgroup 3) The rename of the host group (if allowed) should cause the managed group to be renamed too. In the UI/CLI we will filter out managed netgroups in all cases related to identity part of the server (list of netgroups, users members of the netgroup, hosts members of netgroup, ect.). The netgroups will be available only in the special cases like SUDO plugin. The work will consist of: 1) Defining the managed entry plugin config for this case 2) Adding this configuration to the installation sequence 3) Updating netgroup searches to filter out managed entries 4) Allow all netgroups in SUDO plugin (I think this is already the case). If this proposal looks reasonable I will open a ticket. JR will you be able to provide a patch that does all of this since this is not exactly what we originally planned? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
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
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
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
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
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
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
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
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
