Re: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts
On 11/13/2013 01:33 PM, Ana Krivokapic wrote: On 11/12/2013 01:27 PM, Ana Krivokapic wrote: On 10/30/2013 09:56 PM, Martin Kosek wrote: - Original Message - From: Simo Sorce s...@redhat.com To: Ana Krivokapic akriv...@redhat.com Cc: Martin Kosek mko...@redhat.com, freeipa-devel freeipa-devel@redhat.com Sent: Wednesday, October 30, 2013 7:11:20 PM Subject: Re: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts On Wed, 2013-10-30 at 19:01 +0100, Ana Krivokapic wrote: On 10/29/2013 02:04 PM, Simo Sorce wrote: On Tue, 2013-10-29 at 12:42 +0100, Martin Kosek wrote: On 10/29/2013 10:49 AM, Ana Krivokapic wrote: Hello, Patch 0080 adds userClass attribute for users to IPA CLI. Patch 0081 adds userClass attribute for users and hosts to the web UI. Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems Tickets: https://fedorahosted.org/freeipa/ticket/3588 https://fedorahosted.org/freeipa/ticket/3590 NACK to just extending posixAccount objectclass. This is a standard objectclass defined by RFC 2307 and we cannot just simply extend and overwrite it as we wish. Uhh indeed this is a big No-no. We will need to come up with some custom objectclass, like ipaUser. This is the reason why I wrote to ticket A second goal of this ticket is to review current objectClass hierarchy of users and do changes if needed. so that we can pick the best option where to place it. userClass is used in ipaHost, so I guess it could be instead add to an ipa objectclass. ipaObject might be used perhaps, otherwise we'll need a new ipaUser objectlass. Simo. If there are no objections to using the ipaObject objectclass, the attached patches implement this approach. After some thinking ipaObject is more generic than just users, not sure that attaching userClass there is appropriate. I think we really need ipaUser at this point. +1. I also do not think that ipaObject is the right OC to place the attribute, it is just too general. Let's go with the ipaUser objectClass, looking something like that: ( OID NAME 'ipaUser' AUXILIARY MUST ( uid ) MAY ( userClass ) X-ORIGIN 'IPA v3' ) We will need to add the OC when needed, we cannot just add it to default list. Ideally, we could also implement https://fedorahosted.org/freeipa/ticket/3922 in scope of this effort as this need to add additional OCs is piling up. Martin This implementation introduces a new objectclass 'ipaUser'. The web UI patch needed an update as well, as we need to allow writing the userClass attribute even when the ipaUser objectclass is not (yet) set on the user object. Thanks Petr for pointing it out. Attaching both patches again (the CLI patch has not changed since the last iteration). ACK for Web UI patch (81-03) 80-03 seems good to me as well, but I don't feel strong about my ability to judge correctness of ldap/ipalib part so I let somebody else to look at it. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0072-0074 Add automember rebuild membership to the web UI
On 10/29/2013 12:33 PM, Ana Krivokapic wrote:
On 10/24/2013 03:48 PM, Petr Vobornik wrote:
On 10/16/2013 11:37 PM, Ana Krivokapic wrote:
On 09/27/2013 04:38 PM, Petr Vobornik wrote:
On 09/25/2013 11:51 AM, Ana Krivokapic wrote:
Hello,
This patch set addresses ticket
https://fedorahosted.org/freeipa/ticket/3928.
Patch 0072 hooks the new automember-rebuild command to the web UI
(user and host
pages).
Patch 0073 adds some fixes to the web UI test driver, which are
necessary for
patch 0074.
Patch 0074 adds web UI integration tests for the new feature.
The patch set applies on top of my patches 0068-0071
patch 72: Me, Ana and Kyle discussed position of the actions and the
decision was to move them to action list.
`ipa automember-rebuild --type=hostgroup` can't be run from UI
(already discussed with Ana as well)
I'm thinking about adding/creating refresh facet policies for this
action so that appropriate facet would be marked as dirty and
therefore refreshed so user would not have click association facet
refresh button.
patch 73: Looks OK but some changes might not be needed.
patch 74: I would use different methods for certain actions to be
consistent with other tests and to make the test more robust against
Web UI refactoring:
1.
self.click_on_link('Refresh')
For buttons in .facet-controls use rather
`self.facet_button_click('refresh')` where 'refresh' is the button
name, not text.
2.
self.add_record(
'automember',
{'pkey': 'webservers', 'add': [
('selectbox', 'key', 'fqdn'),
('textbox', 'automemberinclusiveregex', '^web[1-9]+')
]},
facet='hostgrouprule',
facet_btn_css_class='widget',
navigate=False
)
use `add_table_record('automemberinclusiveregex', data, parent)`.
Example in test_dns.py:94.
3. A nitpick(or not even that): When working on one entity, I would
rather use `navigate_by_breadcrumb('link text') instead of direct
`navigate_to_record` call which changes url. It resembles user's
behavior more. But it depends on situation. Ie. when I'm on hostgroup
page and want to go to host search page, but the last host page was
some details or association I may just use `navigate_to_entity('host',
'search'). Anyway, the important thing is to avoid navigating to the
same url twice in a row - IE10 does not like that.
4. Do not use `wait(1)` for AJAX calls. The test will fail if there is
bigger delay. User rather `wait_for_request(n=X)` where X is number of
AJAX calls you want to wait for.
5. Instead of `click_on_link('Rebuild auto membership')` you should
use `action_panel_action(panel_name, action)` There is also similar
call for
executing action list action: `action_list_action(action_name)`.
6. Nitpick: you can reduce the cleanup code:
self.navigate_by_menu('identity/host')
self.delete('host', [{'pkey': host1}])
self.delete('host', [{'pkey': host2}])
Can be written as:
self.delete('host', [{'pkey': host1}, {'pkey': host2}])
or
self.navigate_by_menu('identity/host')
self.delete_record('host', [host1, host2])
`delete` is basically a shortcut for `navigate_to_entity` and
`delete_record` with CRUD data format.
All fixed, new patches attached.
Patch 72: ACK
Patch 73: existing UI_driver.select method has the same functionality as new
select_option method.
Patch 74: ACK
Oops, I missed the existing select() method. Thanks for poining it out. Updated
patch 73 drops the unnecessary select_option() and uses existing select().
ACK
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer
On 09/26/2013 10:28 AM, Tomas Babej wrote: +if options.no_nisdomain and not options.nisdomain: This should be `if options.no_nisdomain and options.nisdomain:`. +parser.error(--no-nisdomain cannot be used together with --nisdomain) Shouldn't we also revert the nisdomain authconfig setting on client uninstall? -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0082 Use EXTERNAL auth mechanism in ldapmodify
On 11/13/2013 05:45 PM, Tomas Babej wrote: On 11/05/2013 06:44 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3895. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership
On 11/13/2013 04:56 PM, Ana Krivokapic wrote:
On 11/13/2013 03:08 PM, Martin Kosek wrote:
On 10/29/2013 12:30 PM, Ana Krivokapic wrote:
On 10/15/2013 06:09 PM, Ana Krivokapic wrote:
On 09/30/2013 10:02 AM, Petr Viktorin wrote:
On 09/27/2013 03:12 PM, Martin Kosek wrote:
On 09/27/2013 03:00 PM, Jan Cholasta wrote:
On 23.9.2013 19:41, Ana Krivokapic wrote:
On 09/19/2013 03:29 PM, Ana Krivokapic wrote:
...
Patch 69:
I think the changes in the update file should be also done in the
right LDIF
files in install/share, though I don't know what is the recent
consensus on this.
Honza
Last time I checked, we used to do the change both in LDIF and update
file. Just to avoid the LDIF become obsolete.
Martin
Rob recently said his preference is to move everything from LDIF to
updates,
and out of the the LDIF files:
http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html
I would agree, having two places with the same information is redundant
and
error-prone.
Thanks Honza for the review.
I incorporated your suggestions in this updated patchset. I attached all
the
patches for more convenient reviewing, but only patches 68 and 70 have
changed.
I haven't done any changes in the LDIF files since the consensus seems to
be not
to do that.
Patch 70 needed a rebase, attaching the whole patchset again.
This works pretty fine, I have few comments though:
1) 0068: the task should be run only for users/hosts base DN - this is where
we
confine our automember and I think admin may be surprised that the rebuild
call
is does not respect it.
Fixed.
2) 0068: I am missing some examples for automember-rebuild in the help. At
least for running rebuild for all users/hosts and for running it for
specified
user/host.
I added some examples, as well as a general description of the new command.
3) 0068: I think that the labels/doc for the new command/options should be
improved. It is not obvious, that automember-rebuild can run for all
users/hosts, at least from following doc:
# ipa help automember
...
automember-rebuild Rebuild auto membership for specified
entries.
...
Maybe we should remove the for specified entries part?
As for the options, we now have this:
# ipa help automember-rebuild
Usage: ipa [global-options] automember-rebuild [options]
Rebuild auto membership for specified entries.
Options:
-h, --helpshow this help message and exit
--type=['group', 'hostgroup']
Grouping to which the rule applies --completely
stray
--users=STR Users for which the rebuild task will be run
--hosts=STR Hosts for which the rebuild task will be run
We should probably also do not mention specified entries here.
As for option help, maybe the following would better show that it can be run
for all entries?
--type=['group', 'hostgroup']
Rebuild membership for all members of a grouping
--users=STR Rebuild membership for specified users
--hosts=STR Rebuild membership for specified hosts
Agreed, labels fixed as per your suggestions.
This makes me thinking we may want to forbid entering both --type and
--users/--hosts - i.e. either rebuild all or just selected ones - to make the
selection even more clear. But I am open to discussion on this one.
Validation prevents any invalid combination of options (e.g. --type=group and
--hosts used together, or --type=hostgroup and --users used together). If, for
example, --users is specified, then --type=group is allowed but not required.
I
think it's clear enough.
4) 0069: Add Automember Export Updates Task is currently redundant. I think
we
should either have permissions for all 3 possible tasks or for just the one
we use.
I removed the unused permission.
5) 0069: permissions should be of SYSTEM type as the ACI is out of SUFFIX, so
that user does not try to modify them (will be able to in future versions).
Adding Petr3 to CC for heads up on this one.
Fixed.
Martin
Thanks for the review, the updated patchset is attached.
Looks good. Last thing I would like to get fixed is this part in 0068:
+types = {
+'group': ('user', 'users', 'users'),
+'hostgroup': ('host', 'hosts', 'computers'),
+}
+
+obj_name, opt_name, dn_part = types[gtype]
+basedn = DN(('cn', dn_part),('cn', 'accounts'), api.env.basedn)
+obj = self.api.Object[obj_name]
I know it works now, but if we sometime decide to maybe support different user
containers and not have it in cn=users,cn=accounts, it will help not user
hardcoded DNs like that, but rather standard
DN(api.env.container_users, api.env.basedn)
or
DN(api.env.container_hosts, api.env.basedn)
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Re: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership
On 11/14/2013 03:11 PM, Martin Kosek wrote:
On 11/13/2013 04:56 PM, Ana Krivokapic wrote:
On 11/13/2013 03:08 PM, Martin Kosek wrote:
On 10/29/2013 12:30 PM, Ana Krivokapic wrote:
On 10/15/2013 06:09 PM, Ana Krivokapic wrote:
On 09/30/2013 10:02 AM, Petr Viktorin wrote:
On 09/27/2013 03:12 PM, Martin Kosek wrote:
On 09/27/2013 03:00 PM, Jan Cholasta wrote:
On 23.9.2013 19:41, Ana Krivokapic wrote:
On 09/19/2013 03:29 PM, Ana Krivokapic wrote:
...
Patch 69:
I think the changes in the update file should be also done in the
right LDIF
files in install/share, though I don't know what is the recent
consensus on this.
Honza
Last time I checked, we used to do the change both in LDIF and update
file. Just to avoid the LDIF become obsolete.
Martin
Rob recently said his preference is to move everything from LDIF to
updates,
and out of the the LDIF files:
http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html
I would agree, having two places with the same information is redundant
and
error-prone.
Thanks Honza for the review.
I incorporated your suggestions in this updated patchset. I attached all
the
patches for more convenient reviewing, but only patches 68 and 70 have
changed.
I haven't done any changes in the LDIF files since the consensus seems to
be not
to do that.
Patch 70 needed a rebase, attaching the whole patchset again.
This works pretty fine, I have few comments though:
1) 0068: the task should be run only for users/hosts base DN - this is
where we
confine our automember and I think admin may be surprised that the rebuild
call
is does not respect it.
Fixed.
2) 0068: I am missing some examples for automember-rebuild in the help. At
least for running rebuild for all users/hosts and for running it for
specified
user/host.
I added some examples, as well as a general description of the new command.
3) 0068: I think that the labels/doc for the new command/options should be
improved. It is not obvious, that automember-rebuild can run for all
users/hosts, at least from following doc:
# ipa help automember
...
automember-rebuild Rebuild auto membership for specified
entries.
...
Maybe we should remove the for specified entries part?
As for the options, we now have this:
# ipa help automember-rebuild
Usage: ipa [global-options] automember-rebuild [options]
Rebuild auto membership for specified entries.
Options:
-h, --helpshow this help message and exit
--type=['group', 'hostgroup']
Grouping to which the rule applies --completely
stray
--users=STR Users for which the rebuild task will be run
--hosts=STR Hosts for which the rebuild task will be run
We should probably also do not mention specified entries here.
As for option help, maybe the following would better show that it can be run
for all entries?
--type=['group', 'hostgroup']
Rebuild membership for all members of a grouping
--users=STR Rebuild membership for specified users
--hosts=STR Rebuild membership for specified hosts
Agreed, labels fixed as per your suggestions.
This makes me thinking we may want to forbid entering both --type and
--users/--hosts - i.e. either rebuild all or just selected ones - to make
the
selection even more clear. But I am open to discussion on this one.
Validation prevents any invalid combination of options (e.g. --type=group and
--hosts used together, or --type=hostgroup and --users used together). If,
for
example, --users is specified, then --type=group is allowed but not
required. I
think it's clear enough.
4) 0069: Add Automember Export Updates Task is currently redundant. I think
we
should either have permissions for all 3 possible tasks or for just the one
we use.
I removed the unused permission.
5) 0069: permissions should be of SYSTEM type as the ACI is out of SUFFIX,
so
that user does not try to modify them (will be able to in future versions).
Adding Petr3 to CC for heads up on this one.
Fixed.
Martin
Thanks for the review, the updated patchset is attached.
Looks good. Last thing I would like to get fixed is this part in 0068:
+types = {
+'group': ('user', 'users', 'users'),
+'hostgroup': ('host', 'hosts', 'computers'),
+}
+
+obj_name, opt_name, dn_part = types[gtype]
+basedn = DN(('cn', dn_part),('cn', 'accounts'), api.env.basedn)
+obj = self.api.Object[obj_name]
I know it works now, but if we sometime decide to maybe support different user
containers and not have it in cn=users,cn=accounts, it will help not user
hardcoded DNs like that, but rather standard
DN(api.env.container_users, api.env.basedn)
or
DN(api.env.container_hosts, api.env.basedn)
Martin
Fixed, updated patch attached.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
[Freeipa-devel] idempotent installer [from LinuxAlt 2013]
Hello, there is an interesting idea that installers should be idempotent. I have heard it on LinuxAlt conference 2013 in Brno, Czech republic and it is implemented e.g. by project Chef [1] and it is used e.g. by OpenStack installer [2] (used e.g. by SUSE). What Wikipedia says about idempotence [3]: Idempotence is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application. ... And that is it :-) In reality, it means that you can re-run OpenStack installer on the same machine/set of machines (with the same configuration, of course!) and it will re-do everything again. You can re-run installer again and again without any harm! This solves case where something went wrong during the installation, the installation was aborted and the machine was left in some inconsistent state. Think about e.g. network failure during installation, improper configuration which prevented installation from finishing (crap in DNS), some intermittent and mysterious errors in Dogtag installer and so on. It does mean that you don't need to recycle whole machine if something went wrong during installation ... As a result, you don't need to have separate system for installation and for upgrade. (Obviously, it means installation steps has to be 'declarative' instead of 'imperative'.) I think that this is very interesting idea and it would be interesting to write new code with idempotence in mind. Eventually, we could end with fully idempotent installer :-) [1] http://www.opscode.com/chef/ [2] http://www.slideshare.net/mattray/deploying-openstack-with-chef [3] http://en.wikipedia.org/wiki/Idempotence -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA 3.3.latest failing tests: config_mod: Add/Remove the unrelated objectclass from ipauserobjectclasses
Hello, latest FreeIPA build from branch ipa-3-3 (built today on Fedora 20, latest bits) fails following tests: == ERROR: test_config[0]: config_mod: Try to add an unrelated objectclass to ipauserobjectclasses -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 283, in lambda func = lambda: self.check(nice, **test) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 301, in check self.check_output(nice, cmd, args, options, expected, extra_check) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 340, in check_output got = api.Command[cmd](*args, **options) File /tmp/git/ipalib/frontend.py, line 436, in __call__ ret = self.run(*args, **options) File /tmp/git/ipalib/frontend.py, line 761, in run return self.forward(*args, **options) File /tmp/git/ipalib/frontend.py, line 782, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /tmp/git/ipalib/rpc.py, line 712, in forward raise error(message=e.faultString) ValidationError: invalid 'ipauserobjectclasses': user default attribute ou would not be allowed! == ERROR: test_config[1]: config_mod: Remove the unrelated objectclass from ipauserobjectclasses -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 283, in lambda func = lambda: self.check(nice, **test) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 301, in check self.check_output(nice, cmd, args, options, expected, extra_check) File /tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py, line 340, in check_output got = api.Command[cmd](*args, **options) File /tmp/git/ipalib/frontend.py, line 436, in __call__ ret = self.run(*args, **options) File /tmp/git/ipalib/frontend.py, line 761, in run return self.forward(*args, **options) File /tmp/git/ipalib/frontend.py, line 782, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /tmp/git/ipalib/rpc.py, line 712, in forward raise error(message=e.faultString) AttrValueNotFound: ipauserobjectclasses does not contain 'ipahost' -- Ran 10 tests in 1.233s FAILED (errors=2) == FAILED under '/usr/bin/python2.7' Other tests from ipatests/test_xmlrpc/test_config_plugin.py are okay. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA 3.3.latest is failing tests: Find all certificates for this IPA server short name (exact)
Hello, latest FreeIPA build from branch ipa-3-3 (built today on Fedora 20, latest bits) fails following tests: == FAIL: Find all certificates for this IPA server short name (exact) -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /tmp/git/ipatests/test_xmlrpc/test_cert_plugin.py, line 264, in test_0006_find_this_short_host_exact assert 'count' in res and res['count'] == 0 AssertionError -- Ran 38 tests in 17.939s FAILED (failures=1) == FAILED under '/usr/bin/python2.7' Other tests from test_xmlrpc/test_cert_plugin.py are okay. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] idempotent installer [from LinuxAlt 2013]
As someone who has fought with using/modifying/QA'ing unstable FreeIPA installers from the nightly repos, I wholeheartedly second this motion! Make sure the oVirt guys get wind of this idea also! ;) PS: semi-related note — Can FreeIPA be made to consume the CSR that results from the ovirt-host-deploy hoster node installer? On Thursday, November 14, 2013, Petr Spacek wrote: Hello, there is an interesting idea that installers should be idempotent. I have heard it on LinuxAlt conference 2013 in Brno, Czech republic and it is implemented e.g. by project Chef [1] and it is used e.g. by OpenStack installer [2] (used e.g. by SUSE). What Wikipedia says about idempotence [3]: Idempotence is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application. ... And that is it :-) In reality, it means that you can re-run OpenStack installer on the same machine/set of machines (with the same configuration, of course!) and it will re-do everything again. You can re-run installer again and again without any harm! This solves case where something went wrong during the installation, the installation was aborted and the machine was left in some inconsistent state. Think about e.g. network failure during installation, improper configuration which prevented installation from finishing (crap in DNS), some intermittent and mysterious errors in Dogtag installer and so on. It does mean that you don't need to recycle whole machine if something went wrong during installation ... As a result, you don't need to have separate system for installation and for upgrade. (Obviously, it means installation steps has to be 'declarative' instead of 'imperative'.) I think that this is very interesting idea and it would be interesting to write new code with idempotence in mind. Eventually, we could end with fully idempotent installer :-) [1] http://www.opscode.com/chef/ [2] http://www.slideshare.net/mattray/deploying-openstack-with-chef [3] http://en.wikipedia.org/wiki/Idempotence -- Petr^2 Spacek ___ 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] idempotent installer [from LinuxAlt 2013]
PPS: you guys might be able to borrow oVirt's otopi installer engine, it seems to have been created to make install scripts more declarative. Although to the end-user otopi can seem dense, complicated, and mysterious (e.g., its weird .conf file syntax). They might need your help making otopi more sane. On Thursday, November 14, 2013, Derek Moore wrote: As someone who has fought with using/modifying/QA'ing unstable FreeIPA installers from the nightly repos, I wholeheartedly second this motion! Make sure the oVirt guys get wind of this idea also! ;) PS: semi-related note — Can FreeIPA be made to consume the CSR that results from the ovirt-host-deploy hoster node installer? On Thursday, November 14, 2013, Petr Spacek wrote: Hello, there is an interesting idea that installers should be idempotent. I have heard it on LinuxAlt conference 2013 in Brno, Czech republic and it is implemented e.g. by project Chef [1] and it is used e.g. by OpenStack installer [2] (used e.g. by SUSE). What Wikipedia says about idempotence [3]: Idempotence is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application. ... And that is it :-) In reality, it means that you can re-run OpenStack installer on the same machine/set of machines (with the same configuration, of course!) and it will re-do everything again. You can re-run installer again and again without any harm! This solves case where something went wrong during the installation, the installation was aborted and the machine was left in some inconsistent state. Think about e.g. network failure during installation, improper configuration which prevented installation from finishing (crap in DNS), some intermittent and mysterious errors in Dogtag installer and so on. It does mean that you don't need to recycle whole machine if something went wrong during installation ... As a result, you don't need to have separate system for installation and for upgrade. (Obviously, it means installation steps has to be 'declarative' instead of 'imperative'.) I think that this is very interesting idea and it would be interesting to write new code with idempotence in mind. Eventually, we could end with fully idempotent installer :-) [1] http://www.opscode.com/chef/ [2] http://www.slideshare.net/mattray/deploying-openstack-with-chef [3] http://en.wikipedia.org/wiki/Idempotence -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Include proposal to contrib (expired user accounts query tool)
Hi all, I have created the following https://bitbucket.org/bcow/freeipa-expired-user-accounts-query tool to mitigate a situation when users in directory never login to servers and therefore do not receive alerts about expiring passwords. My tool can be used to query the LDAP directory and list users that have expired passwords and/or users with passwords about to expire in given amount of days. External script can then be executed for each matching user to generate a warning for the user via selected medium, for example by email. -- Antti Peltonen | Homo sapiens | planet Earth blog http://bcow.me | email antti.peltonen@iki.f antti.pelto...@iki.fii irc bcow@IRCNet,Freenode ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Include proposal to contrib (expired user accounts query tool)
On 11/14/2013 12:08 PM, Antti Peltonen wrote: Hi all, I have created the following https://bitbucket.org/bcow/freeipa-expired-user-accounts-query tool to mitigate a situation when users in directory never login to servers and therefore do not receive alerts about expiring passwords. My tool can be used to query the LDAP directory and list users that have expired passwords and/or users with passwords about to expire in given amount of days. External script can then be executed for each matching user to generate a warning for the user via selected medium, for example by email. -- Antti Peltonen | Homo sapiens | planet Earth blog http://bcow.me | email antti.peltonen@iki.f mailto:antti.pelto...@iki.fii irc bcow@IRCNet,Freenode ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Thank you for the contribution! A quick look at the tool's command line indicates that it is probably not using any of the IPA framework and rather goes over LDAP. I am not sure that this is the best approach, let us discuss... For the tool to become a part of the IPA ecosystem it should probably take advantage of the framework. The framework would take care of things like --gssapi --server ipaserver.example.tld --basedn cn=users,cn=accounts,dc=example,dc=tld I think next steps would be: 1) Open a ticket for this RFE and describe the use case and need there. 2) Create a design page on the wiki, it should not be long but I suspect several paragraphs would help others to understand what is going on under the hood. The page would cover command line parameter, their use, authentication, examples of scripts, etc. Though may be instead of a script as an argument the command would allow piped output to a script. Just a thought... This is exactly a thing that should be discussed during a design review. 3) Send design for review Based on the design discussion it would become clearer what needs to change (if anything) for the tool to be accepted. Thanks again for the contribution! I think we have a huge lack of good reporting tools in FreeIPA. Would be great if someone can make a dent at them some day: https://fedorahosted.org/freeipa/ticket/3024 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio 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 0024] Add OTP support to ipalib CLI
On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote:
On 8.10.2013 16:35, Nathaniel McCallum wrote:
On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote:
+class Base32DecodeError(ExecutionError):
Is this really necessary? Are we going to add encodingDecodeError for
every kind of new encoding in IPA? Can't we just have generic
DecodeError? (This is not an issue in your patch per se, I'm just
wondering if we can do it better in the framework.)
I added the new error due to the existence of a Base64DecodeError. I
figured changing the existing error to be more generic would break api.
Nathaniel
I think you can use ConversionError instead. I don't see any reason why
base32/64 decoding errors should be special cased like this and would
like to see Base64DecodeError gone.
Fixed.
From de8e151270f4606da8eb950c5e1478bc07d8263b Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Tue, 1 Oct 2013 14:26:38 -0400
Subject: [PATCH] Add OTP support to ipalib CLI
https://fedorahosted.org/freeipa/ticket/3368
---
API.txt| 101 +-
VERSION| 2 +-
freeipa.spec.in| 2 +
ipalib/errors.py | 2 +-
ipalib/plugins/config.py | 2 +-
ipalib/plugins/otptoken.py | 330 +
ipalib/plugins/user.py | 10 +-
7 files changed, 441 insertions(+), 8 deletions(-)
create mode 100644 ipalib/plugins/otptoken.py
diff --git a/API.txt b/API.txt
index bee8db1fc218cd63dbb2196a38ce4086f9a4d7bb..c09335013fa3c4f62bc522fa46efdebcae636769 100644
--- a/API.txt
+++ b/API.txt
@@ -514,7 +514,7 @@ option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='s
option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=-1, multivalue=False, required=False)
option: Str('ipaselinuxusermapdefault', attribute=True, autofill=False, cli_name='ipaselinuxusermapdefault', multivalue=False, required=False)
option: Str('ipaselinuxusermaporder', attribute=True, autofill=False, cli_name='ipaselinuxusermaporder', multivalue=False, required=False)
-option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius'))
+option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius', u'otp'))
option: Str('ipauserobjectclasses', attribute=True, autofill=False, cli_name='userobjectclasses', csv=True, multivalue=True, required=False)
option: IA5Str('ipausersearchfields', attribute=True, autofill=False, cli_name='usersearch', multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2208,6 +2208,99 @@ option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
+command: otptoken_add
+args: 1,20,3
+arg: Str('ipatokenuniqueid', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=False)
+option: Str('addattr*', cli_name='addattr', exclude='webui')
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
+option: Bool('ipatokendisabled', attribute=True, cli_name='disabled', multivalue=False, required=False)
+option: Str('ipatokenmodel', attribute=True, cli_name='model', multivalue=False, required=False)
+option: Str('ipatokennotafter', attribute=True, cli_name='not_after', multivalue=False, required=False)
+option: Str('ipatokennotbefore', attribute=True, cli_name='not_before', multivalue=False, required=False)
+option: StrEnum('ipatokenotpalgorithm', attribute=True, cli_name='algo', multivalue=False, required=False, values=(u'sha1', u'sha256', u'sha384', u'sha512'))
+option: IntEnum('ipatokenotpdigits', attribute=True, cli_name='digits', multivalue=False, required=False, values=(6, 8))
+option: OTPTokenKey('ipatokenotpkey', attribute=True, cli_name='key', multivalue=False, required=False)
+option: Str('ipatokenowner', attribute=True, cli_name='owner', multivalue=False, required=False)
+option: Str('ipatokenserial', attribute=True, cli_name='serial', multivalue=False, required=False)
+option: Int('ipatokentotpclockoffset', attribute=True, cli_name='offset', multivalue=False, required=False)
+option: Int('ipatokentotptimestep', attribute=True, cli_name='interval', minvalue=5, multivalue=False, required=False)
+option: Str('ipatokenvendor', attribute=True, cli_name='vendor', multivalue=False, required=False)
+option: Flag('qrcode?', autofill=True, default=False)
+option: Flag('raw', autofill=True, cli_name='raw',
Re: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI
On Tue, 2013-10-29 at 10:18 -0400, Rob Crittenden wrote: Petr Vobornik wrote: On 10/04/2013 10:16 PM, Nathaniel McCallum wrote: This patch supersedes my patch 0017 and requires patches 0020-0023. I believe I have solved all of the outstanding issues from the review of patch 0017, unless otherwise noted: 1. I'm not actually sure what the format of the date parameters is. Could someone clarify this for me? Should I do something differently here? I think that date parameter is not used anywhere. IMO it should be designed soon since it will be needed in other tickets [1], [2] as well. [1] https://fedorahosted.org/freeipa/ticket/547 [RFE] Implement iCal based time managment in HBAC [2] https://fedorahosted.org/freeipa/ticket/3127 [RFE] Time-Based Account Lockout Policies in IPA FYI the original HBAC time class is still in ipalib/parameters.py::AccessTime. It is supposed to provide a generalized time-like API. Not saying it has to remain. I can't remember how much previous conversations about date/time handling were in mailing lists vs shouting matches on the phone, but it is quite a hard problem in a distributed system like IPA, particularly for the UI. Thar be dragons. Currently, the token entity uses two GeneralizedTime fields (notBefore and notAfter). I assume this information is correct: http://en.wikipedia.org/wiki/GeneralizedTime Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] idempotent installer [from LinuxAlt 2013]
On Thu, Nov 14, 2013 at 03:40:52PM +0100, Petr Spacek wrote: In reality, it means that you can re-run OpenStack installer on the same machine/set of machines (with the same configuration, of course!) and it will re-do everything again. You can re-run The point is that it should *not* redo everything again. installer again and again without any harm! This solves case where something went wrong during the installation, the installation was aborted and the machine was left in some inconsistent state. Think about e.g. network failure during installation, improper configuration which prevented installation from finishing (crap in DNS), some intermittent and mysterious errors in Dogtag installer and so on. It does mean that you don't need to recycle whole machine if something went wrong during installation ... I am not sure idempotence focuses on failures, really. It says that if your previous installer run passed, the subsequent run should detect that individual pieces of configuration are already in place and it should not re-run the steps to re-create them. The implication being that it should only configure the pieces missing. But if your installation is borked beyond repair for whatever reason, it does not mean that the setup will be self-healing. I think that our installers do a pretty decent job of cleaning after themselves if things fails (rolling back the changes) which I find much more important than leaving mess around with the intent of fixing it upon the next run. Leaving things in consistent state is higher value than idempotence. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] idempotent installer [from LinuxAlt 2013]
On Thu, Nov 14, 2013 at 11:41 AM, Derek Moore derek.p.mo...@gmail.com wrote: PPS: you guys might be able to borrow oVirt's otopi installer engine, it seems to have been created to make install scripts more declarative. If you like declarative, you should consider using my puppet-ipa module to install this. It doesn't solve the make the actual installer idempotent problem, but I think it's a good abstraction layer. As for the idempotentcy problem, I'm curious to know if the goals you're trying to achieve are something that the GNOME-continuous project by Colin Walters already solves. Under the hood package installs are atomic. I don't know a lot of the technical details, but he might be a good person to ask. Cheers, James Although to the end-user otopi can seem dense, complicated, and mysterious (e.g., its weird .conf file syntax). They might need your help making otopi more sane. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Include proposal to contrib (expired user accounts query tool)
Hi, On 14 November 2013 21:06, Dmitri Pal d...@redhat.com wrote: A quick look at the tool's command line indicates that it is probably not using any of the IPA framework and rather goes over LDAP. I am not sure that this is the best approach, let us discuss... Could you please point me towards to some documentation on howto implement this tool with IPA framework or should I just go and read some code? :) -- Antti Peltonen | Homo sapiens | planet Earth blog http://bcow.me | email antti.peltonen@iki.f antti.pelto...@iki.fii irc bcow@IRCNet,Freenode ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] idempotent installer [from LinuxAlt 2013]
On 15.11.2013 02:14, Jan Pazdziora wrote: On Thu, Nov 14, 2013 at 03:40:52PM +0100, Petr Spacek wrote: In reality, it means that you can re-run OpenStack installer on the same machine/set of machines (with the same configuration, of course!) and it will re-do everything again. You can re-run The point is that it should *not* redo everything again. Okay, may be that re-do is not the best description ever ;-) installer again and again without any harm! This solves case where something went wrong during the installation, the installation was aborted and the machine was left in some inconsistent state. Think about e.g. network failure during installation, improper configuration which prevented installation from finishing (crap in DNS), some intermittent and mysterious errors in Dogtag installer and so on. It does mean that you don't need to recycle whole machine if something went wrong during installation ... I am not sure idempotence focuses on failures, really. It says that if your previous installer run passed, the subsequent run should No, it says that you will reach the same state again and again - if the conditions are the same. It does not apply only to successful installations. detect that individual pieces of configuration are already in place and it should not re-run the steps to re-create them. The implication being that it should only configure the pieces missing. I agree, re-do wasn't the best wording. But if your installation is borked beyond repair for whatever reason, it does not mean that the setup will be self-healing. Sure, but you describe case when installation failed for whatever reason and you ran it again without any change. In that case it will fail again, idempotently :-) The point is that you have a chance to fix the problem (reconfigure firewall, DNS etc.), run the installer again and it will finish the installation or fail later on some other problem. It means that you don't need to start from scratch. (This is exactly what was described at the conference by the speaker.) Also, it allows you to reproduce the failure again and again (without any change to existing system) and dig towards the cause. This can be major advantage if you don't know why it failed. I think that our installers do a pretty decent job of cleaning after themselves if things fails (rolling back the changes) which I find much more important than leaving mess around with the intent of fixing it upon the next run. Leaving things in consistent state is higher value than idempotence. I think that this goes hand-in-hand. IMHO it is much harder to write and maintain uninstaller if you have just imperative installer, because you have to read it's code and manually write the uninstaller. I think you have much better position with declarative installer, because you can extract a lot of information from the 'declarations' and generate uninstaller from that. (I don't say that it will be 100% bullet proof, but I'm pretty sure that this will lower the chance that you added something to installer but forgot to add the same step to uninstaller.) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
