Re: [Freeipa-devel] [PATCH 0159] ipatests: test_trust: Change expected home directories for
On 03/23/2014 10:34 PM, Alexander Bokovoy wrote: On Thu, 20 Mar 2014, Tomas Babej wrote: Hi, Information from the AD about the home directories is not leveraged at all, but is generated from the username and domain. Fix the assumptions in the tests. Also changes 'Subdomain Test User' to 'Subdomaintest User' to be more consistent. https://fedorahosted.org/freeipa/ticket/4184 ACK. Thanks both to Jakub and Alexander for review. Pushed to master, ipa-3-3. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added
On Fri, 21 Mar 2014 13:06:21 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 12:58 PM, Martin Kosek wrote:
On 03/21/2014 12:38 PM, Petr Viktorin wrote:
On 03/21/2014 12:00 PM, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 10:33:00 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 10:29 AM, Petr Viktorin wrote:
On 03/20/2014 04:22 PM, Misnyovszki Adam wrote:
On Thu, 20 Mar 2014 14:19:51 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Fri, 14 Mar 2014 13:26:15 -0400
Rob Crittenden rcrit...@redhat.com wrote:
Misnyovszki Adam wrote:
Hi,
automember-rebuild uses asynchronous 389 task, and returned
success even if the task didn't run. This patch fixes this
issue adding a --nowait parameter to 'ipa
automember-rebuild', defaulting to False, thus when the
script runs without it, it waits for the 'nstaskexitcode'
attribute, which means the task has finished, according to
http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation.
Old usage can be enabled using --nowait.
https://fedorahosted.org/freeipa/ticket/4239
Request for comments:
- Should I add a parameter to specify the polling time? (now
1ms)
- Should I add a parameter to specify the maximum polling
number? Now if something fails about creating the task, it
polls forever.
- Obviously, if these parameters should be added, there
should be a reasonable default for them (~ Required=False,
Default=X).
I don't think you need a polling time, esp since this is
hidden from the user, but I think that is probably too short
and you may end up hammering the LDAP server.
I also wonder if there should be some maximum wait time. I
don't like loops that can never exit. I'm at a loss for what
that time should be though. And we'd need to spell out that
we gave up waiting, not that the task necessarily failed. So
rather than having a polling time option, rename nowait into
wait_for=20, so wait for 20 seconds. Or something like that.
I'd suggest using get_entry since you already know the full
DN and there is only ever one. It would make this much more
readable.
I wonder if some top-level documentation should be added to
flesh this out some more. This does, for example, return
False in one case. The meaning for that should be spelled
out.
rob
Hi,
personally I would keep --no-wait, with a delay of 1 seconds,
and a maximum waiting time for 60 seconds. Questions is, do
we need to parameterize with other parameters(wait-for to the
maximum time, and/or poll-delay for the delay time, both not
required), or it is not a case which worth to develop?
Greets
Adam
Hi,
here are the corrections Petr asked, also the other patch
conatins the plugin registration refactor.
Thanks!
You forgot an alternate summary for the --no-wait case. (Make
sure to output the DN in this case, so it's possible to poll
for it.)
Instead of `task['nstaskexitcode'][0]` please use
`task.single_value['nstaskexitcode']`.
There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it
in a variable would be better?)
Here:
raise errors.DatabaseError(
desc=_(Automember rebuild membership task failed),
info=_(nstaskexitcode = '%s' %
str(task['nstaskexitcode'][0])))
there's no need to call str() on %'s argument.
Also, use natural language (like Task exit code: %s),
otherwise there's no need to mark the message for translation.
And one more thing: Please bump the minor version in the VERSION
file when API.txt changes.
Hi,
everything is corrected!
Greets
Adam
Sorry for dragging this so long, but:
The DN should not be a part of the summary, because that makes it
hard to parse when using the API. It should be returned as a part
of the result. To do that, you'd need to change the output type:
has_output = output.standard_entry
has_output_params = (
DNParam(
'dn',
label=_('Task automember'),
doc=_('DN of the started task'),
),
)
and provide a dict in result, instead of True. (And with
--no-wait, add the dn to that dict.)
Do really want to use 'dn' for the DNParam? dn is already used for
standard entry DN when --all is used, right? automembertaskdn may
be better.
Well, I think DN of the added entry is exactly what this is.
Also, Task automember label sounds strange to me, would
Automember task DN be better?
I meant Task DN, sorry for the thinko.
One more thing, which came to my mind after reviewing the code for
myself once again, if the task fails with an exit code other than 0,
there is a DatabaseError raised, which is just fine. But in the info,
should I specify not only the exit code, but also the DN of the task,
or is it unnecessary?
Thanks
Adam
___
Re: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs
On 23.3.2014 22:17, Alexander Bokovoy wrote:
On Mon, 10 Feb 2014, Nathaniel McCallum wrote:
Patch attached.
From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 10 Feb 2014 12:07:51 -0500
Subject: [PATCH] Fix generation of invalid OTP URIs
---
ipalib/plugins/otptoken.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index
5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da
100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate):
)
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys,
**options):
+# These are values we always want to write to LDAP. So if
they are
+# specified as a value that evaluates to False (i.e. None),
delete them
+# and fill in the defaults below.
+for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep',
+ 'ipatokenotpalgorithm', 'ipatokenotpdigits',
+ 'ipatokenotpkey'):
+if attr in entry_attrs and not entry_attrs[attr]:
+del entry_attrs[attr]
+
# Set defaults. This needs to happen on the server side
because we may
# have global configurable defaults in the near future.
options.setdefault('type', TOKEN_TYPES[0])
ACK.
Since this patch rotted a bit, attaching rebased version.
IMO we should not push this patch.
Wasn't it superseded by:
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=21ff4f920e4ff7c1e2870024f007f067fc3cf6c8
?
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs
On Mon, 24 Mar 2014, Petr Vobornik wrote:
On 23.3.2014 22:17, Alexander Bokovoy wrote:
On Mon, 10 Feb 2014, Nathaniel McCallum wrote:
Patch attached.
From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 10 Feb 2014 12:07:51 -0500
Subject: [PATCH] Fix generation of invalid OTP URIs
---
ipalib/plugins/otptoken.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index
5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da
100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate):
)
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys,
**options):
+# These are values we always want to write to LDAP. So if
they are
+# specified as a value that evaluates to False (i.e. None),
delete them
+# and fill in the defaults below.
+for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep',
+ 'ipatokenotpalgorithm', 'ipatokenotpdigits',
+ 'ipatokenotpkey'):
+if attr in entry_attrs and not entry_attrs[attr]:
+del entry_attrs[attr]
+
# Set defaults. This needs to happen on the server side
because we may
# have global configurable defaults in the near future.
options.setdefault('type', TOKEN_TYPES[0])
ACK.
Since this patch rotted a bit, attaching rebased version.
IMO we should not push this patch.
Wasn't it superseded by: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=21ff4f920e4ff7c1e2870024f007f067fc3cf6c8
?
I knew I missed one of patches when looking up. Thanks!
This one can be ignored then.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Talking json/rpc with java client
On 03/21/2014 04:52 PM, Massimiliano Perrone (tirasa.net) wrote:
On 03/20/2014 02:09 PM, Simo Sorce wrote:
On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote:
On Thu, 20 Mar 2014, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Thu, 20 Mar 2014, Massimiliano Perrone (example.com) wrote:
On 03/18/2014 05:26 PM, Alexander Bokovoy wrote:
On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote:
The difference between the two calls is on the last TGS_REQ;
because the first one is on ldap/olmo.example@example.com
and
it's OK whereas the second one is on
HTTP/olmo.example@example.com that returns a 401 (I
suppose).
Where's the error?
Am I correct that you have a user connecting to
HTTP/ebano.example.com
and then HTTP/ebano.example.com wants to talk to
HTTP/olmo.example.com
using credentials of the user?
FreeIPA uses constraint delegation of the credentials, with the
help of
S4U2Proxy extension. You need to allow HTTP/ebano.example.com to
delegate
credentials to HTTP/olmo.example.com.
I have written an article how to do that:
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html
Hi Alexander, thanks for your reply.
I read carefully your interesting post and I follow it to delegate
HTTP/ebano.example.com credentials to HTTP/olmo.example.com.
Now, two questions:
1) How can I check that my configuration, now is ok? Because this
ldapsearch returns result: 0
ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b
cn=s4u2proxy,cn=etc,dc=example,dc=com
cn=ipa-http-delegation-targets dn
You need to create these delegation entries yourself, like the
article
says. Note that your app talks to IPA server's HTTP service, so
create
dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com
objectClass: ipaKrb5DelegationACL
objectClass: groupOfPrincipals
objectClass: top
cn: ebano-http-delegation
memberPrincipal: HTTP/ebano.example@example.com
ipaAllowedTarget:
cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
This entry says: HTTP/ebano.example.com is allowed to delegate
users'
credentials to whatever Kerberos principal is a member of
cn=ebano-http-delegation-targets group
Now, this is the group:
dn:
cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
objectClass: groupOfPrincipals
objectClass: top
cn: ebano-http-delegation-targets
memberPrincipal: HTTP/olomo.example@example.com
With these two entries we would have HTTP/ebano.example.com
allowed to
delegate users' credentials to HTTP/olomo.example.com
Hi Alexander, thanks for your patience.
I followed your suggestions but the result is always the same.
Trying with curl, of course, it works.
My doubt now is why curl generates this log on kerberos server
mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1
etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes
{rep=18
tkt=18 ses=18}, ad...@example.com for krbtgt/example@example.com
mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime
1395301975,
etypes {rep=18 tkt=18 ses=18}, ad...@example.com for
ldap/olmo.example@example.com
This is effect of S4U extension working correctly.
whereas java generates this other one
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH:
HTTP/ebano.example@example.com for
krbtgt/example@example.com,
Additional pre-authentication required
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes
{rep=18 tkt=18 ses=18}, HTTP/ebano.example@example.com for
krbtgt/example@example.com
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449,
etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example@example.com
for
HTTP/olmo.example@example.com
As you can see, the first one uses admin on ldap service, the second
one uses HTTP/ebano.example.com on HTTP service.
This means your Java application doesn't use S4U extension or doesn't
know about that.
Can I do the same call with Java?
At this point we need to set clear what Java are you using.
http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html
tells that S4U extensions (we use S4U2Proxy here) was added in
Java SE 8.
The client doesn't do the S4U2Proxy work though, so this shouldn't
matter, right?
My point is that the client will not do what he expects unless
S4U2Proxy
is used in Java and that requires Java 8 platform, released on March
18th 2014.
I think you can use earlier Java versions but tell them to use the
native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in
the back for fun.
Here I'm again :)
I wrote a GSSClient [1] obtaining:
###
Re: [Freeipa-devel] Talking json/rpc with java client
On 03/24/2014 12:35 PM, Massimiliano Perrone (tirasa.net) wrote:
On 03/21/2014 04:52 PM, Massimiliano Perrone (tirasa.net) wrote:
On 03/20/2014 02:09 PM, Simo Sorce wrote:
On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote:
On Thu, 20 Mar 2014, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Thu, 20 Mar 2014, Massimiliano Perrone (example.com) wrote:
On 03/18/2014 05:26 PM, Alexander Bokovoy wrote:
On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote:
The difference between the two calls is on the last TGS_REQ;
because the first one is on
ldap/olmo.example@example.com and
it's OK whereas the second one is on
HTTP/olmo.example@example.com that returns a 401 (I
suppose).
Where's the error?
Am I correct that you have a user connecting to
HTTP/ebano.example.com
and then HTTP/ebano.example.com wants to talk to
HTTP/olmo.example.com
using credentials of the user?
FreeIPA uses constraint delegation of the credentials, with the
help of
S4U2Proxy extension. You need to allow HTTP/ebano.example.com to
delegate
credentials to HTTP/olmo.example.com.
I have written an article how to do that:
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html
Hi Alexander, thanks for your reply.
I read carefully your interesting post and I follow it to
delegate
HTTP/ebano.example.com credentials to HTTP/olmo.example.com.
Now, two questions:
1) How can I check that my configuration, now is ok? Because this
ldapsearch returns result: 0
ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b
cn=s4u2proxy,cn=etc,dc=example,dc=com
cn=ipa-http-delegation-targets dn
You need to create these delegation entries yourself, like the
article
says. Note that your app talks to IPA server's HTTP service, so
create
dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com
objectClass: ipaKrb5DelegationACL
objectClass: groupOfPrincipals
objectClass: top
cn: ebano-http-delegation
memberPrincipal: HTTP/ebano.example@example.com
ipaAllowedTarget:
cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
This entry says: HTTP/ebano.example.com is allowed to delegate
users'
credentials to whatever Kerberos principal is a member of
cn=ebano-http-delegation-targets group
Now, this is the group:
dn:
cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com
objectClass: groupOfPrincipals
objectClass: top
cn: ebano-http-delegation-targets
memberPrincipal: HTTP/olomo.example@example.com
With these two entries we would have HTTP/ebano.example.com
allowed to
delegate users' credentials to HTTP/olomo.example.com
Hi Alexander, thanks for your patience.
I followed your suggestions but the result is always the same.
Trying with curl, of course, it works.
My doubt now is why curl generates this log on kerberos server
mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1
etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes
{rep=18
tkt=18 ses=18}, ad...@example.com for
krbtgt/example@example.com
mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime
1395301975,
etypes {rep=18 tkt=18 ses=18}, ad...@example.com for
ldap/olmo.example@example.com
This is effect of S4U extension working correctly.
whereas java generates this other one
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH:
HTTP/ebano.example@example.com for
krbtgt/example@example.com,
Additional pre-authentication required
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes
{rep=18 tkt=18 ses=18}, HTTP/ebano.example@example.com for
krbtgt/example@example.com
mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6
etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime
1395307449,
etypes {rep=18 tkt=18 ses=18},
HTTP/ebano.example@example.com for
HTTP/olmo.example@example.com
As you can see, the first one uses admin on ldap service, the
second
one uses HTTP/ebano.example.com on HTTP service.
This means your Java application doesn't use S4U extension or
doesn't
know about that.
Can I do the same call with Java?
At this point we need to set clear what Java are you using.
http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html
tells that S4U extensions (we use S4U2Proxy here) was added in
Java SE 8.
The client doesn't do the S4U2Proxy work though, so this shouldn't
matter, right?
My point is that the client will not do what he expects unless
S4U2Proxy
is used in Java and that requires Java 8 platform, released on March
18th 2014.
I think you can use earlier Java versions but tell them to use the
native GSSAPI library (and perhaps sprinkle a little bit of
GSS-Proxy in
the back for fun.
Here I'm again :)
I wrote a GSSClient [1]
Re: [Freeipa-devel] Talking json/rpc with java client
On Mon, 24 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: As you can see in the row indicated by the arrow there's: Entered Krb5Context.initSecContext with state=STATE_NEW Service ticket not found in the subject --- Is this right? Hi guys, sorry for the noise... Maybe this informations can help us to understand the root cause of our problem. httpd access_log 192.168.0.176 - HTTP/ebano.tirasa@tirasa.net [24/Mar/2014:12:21:57 +0100] POST /ipa/json HTTP/1.1 500 272 httpd error_log [Mon Mar 24 12:21:57.971182 2014] [:error] [pid 24462] ipa: ERROR: 500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment Other question/information... I don't know if I'm saying something wrong but.. Reading [1] at line 980 I noticed that kinit method sets KRB5CCNAME variable [skip] Is possible that LoginContext method of Java Kerberos libraries doesn't do the same thing? I don't think so. What the code above is not related. KRB5CCNAME is set by the mod_auth_kerb before handing over request processing to WSGI module. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On Wed, 2014-03-19 at 17:37 +0200, Alexander Bokovoy wrote: On Fri, 21 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-21 at 00:08 +0200, Alexander Bokovoy wrote: On Thu, 20 Feb 2014, Nathaniel McCallum wrote: There is an error in libotp's find() function which assumes that get_basedn() always returns non-NULL value. This is not true for at least cn=Directory Manager. Patch attached. More fixes required, now that Thierry produced the fix for 389-ds ticket 47699 which allows to re-arrange schema-compat and ipa-pwd-extop plugins. I'm getting crash in find() in libotp.c for internal search in some other conditions but at least user dn now is the correct one. Stay tuned. OK, finally I've got it working -- my last patch had error which could be attributed to the late night time. New patch is attached to fix libotp to work properly with empty base dn (such as cn=Directory Manager). Also I'm attaching the patch that sets precedence of schema-compat plugin to 49 (less than default 50). With this patch and 389-ds with patch from ticket 47699 compat tree binds work with OTP. When updated 389-ds-base will be released, we'll need to add Requires: to our RPM spec to depend on it. Without the updated 389-ds-base compat tree binds will not work with OTP but the rest will be working fine. Finally, ACK to all OTP patches. ACK to both of these patches. I've merged the first patch here -- https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html I just realized the second patch shouldn't be ACK'd until we have a new 389DS release with the fix. When that happens, reissue this patch with an update versioned require. No, it can be safely merged as 389DS will use default precedence (50) unless the fix is there. So the worst we get is the same as now -- OTP binds will not work over compat tree. And when 389DS will be upgraded, they will start working after 389DS restart. But this patch doesn't actually do anything until we get the new version of 389DS. If we are ever going to add a versioned dependency on the new 389DS for this feature, it should go in this patch. Otherwise, it is an ACK from me. New 389-DS is in Fedora 20 updates stable and Rawhide already. 389-ds-base-1.3.2.16-1.fc20. Also, selinux-policy 3.12.1-135 is now in Fedora 20 updates testing, providing multiple policy enhancements that make possible Apache process to work with kernel-based credentials caches. Attached patch makes use of the new packages. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source
On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: Hi, Makes ipa-client-install configure SSSD as the data provider for the sudo service by default. This behaviour can be disabled by using --no-sudo flag. https://fedorahosted.org/freeipa/ticket/3358 Ack. Applied against ipa-client-3.0.0-37.el6.x86_64, tried without --no-sudo and sudo was added to sssd.conf's services list and sudoeers added to /etc/nsswitch.conf. Rerun with --uninstall and run again with the --no-sudo parameter, those settings were not longer there. -- 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] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source
On 03/24/2014 02:47 PM, Jan Pazdziora wrote: On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: Hi, Makes ipa-client-install configure SSSD as the data provider for the sudo service by default. This behaviour can be disabled by using --no-sudo flag. https://fedorahosted.org/freeipa/ticket/3358 Ack. Applied against ipa-client-3.0.0-37.el6.x86_64, tried without --no-sudo and sudo was added to sssd.conf's services list and sudoeers added to /etc/nsswitch.conf. Rerun with --uninstall and run again with the --no-sudo parameter, those settings were not longer there. Did you also do the functional test? To ack and push this ticket, following scenario needs to work: 1) IPA clients enroll against IPA server without --no-sudo 2) IPA client user logs in, types sudo -l, gets all allowed commands (prerequisite is of course to have sudo commands defined on the IPA server) 3) IPA client reboots, IPA client user logs in, types sudo -l, gets all allowed commands For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done For 3) to work, related systemd service preserving NIS domain name setting needs to be enabled Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 564 webui-ci: fix test_rebuild_membership_hosts on server without DNS
On 03/21/2014 03:17 PM, Petr Vobornik wrote: Host adder dialog differs on installations with and without DNS. Previous test used values for adding hosts which were suitable only for IPA servers installed with DNS. Thanks for the fix. It looks OK and should fix the CI failure I was seeing. ACK. Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source
On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: On 03/24/2014 02:47 PM, Jan Pazdziora wrote: On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: Hi, Makes ipa-client-install configure SSSD as the data provider for the sudo service by default. This behaviour can be disabled by using --no-sudo flag. https://fedorahosted.org/freeipa/ticket/3358 Ack. Applied against ipa-client-3.0.0-37.el6.x86_64, tried without --no-sudo and sudo was added to sssd.conf's services list and sudoeers added to /etc/nsswitch.conf. Rerun with --uninstall and run again with the --no-sudo parameter, those settings were not longer there. Did you also do the functional test? No. I do not want to get dragged into the discussion of having the correct sssd and sudo and glibc versions and SELinux and stuff. The ticket explicitly talk about setting configuration in config files, which the patch does. To ack and push this ticket, following scenario needs to work: Consumption of those configuration changes is really different story, isn't it? 1) IPA clients enroll against IPA server without --no-sudo 2) IPA client user logs in, types sudo -l, gets all allowed commands (prerequisite is of course to have sudo commands defined on the IPA server) 3) IPA client reboots, IPA client user logs in, types sudo -l, gets all allowed commands For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done For 3) to work, related systemd service preserving NIS domain name setting needs to be enabled With the commit message only talking about configuring sssd, I assume the NIS domain name mentioned in the ticket will be done by some other patch. To me, the patch does what is advertised in the commit message, and is in line with what the ticket asks to be done. -- 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] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source
On 03/24/2014 03:27 PM, Jan Pazdziora wrote: On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: On 03/24/2014 02:47 PM, Jan Pazdziora wrote: On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: Hi, Makes ipa-client-install configure SSSD as the data provider for the sudo service by default. This behaviour can be disabled by using --no-sudo flag. https://fedorahosted.org/freeipa/ticket/3358 Ack. Applied against ipa-client-3.0.0-37.el6.x86_64, tried without --no-sudo and sudo was added to sssd.conf's services list and sudoeers added to /etc/nsswitch.conf. Rerun with --uninstall and run again with the --no-sudo parameter, those settings were not longer there. Did you also do the functional test? No. I do not want to get dragged into the discussion of having the correct sssd and sudo and glibc versions and SELinux and stuff. The ticket explicitly talk about setting configuration in config files, which the patch does. To ack and push this ticket, following scenario needs to work: Consumption of those configuration changes is really different story, isn't it? 1) IPA clients enroll against IPA server without --no-sudo 2) IPA client user logs in, types sudo -l, gets all allowed commands (prerequisite is of course to have sudo commands defined on the IPA server) 3) IPA client reboots, IPA client user logs in, types sudo -l, gets all allowed commands For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done For 3) to work, related systemd service preserving NIS domain name setting needs to be enabled With the commit message only talking about configuring sssd, I assume the NIS domain name mentioned in the ticket will be done by some other patch. To me, the patch does what is advertised in the commit message, and is in line with what the ticket asks to be done. To me, it is not. I see your point that the commit message does not promise that FreeIPA client sudo would work after this change, but as this is the sole purpose of https://fedorahosted.org/freeipa/ticket/3358 and these patches are the final umbrella patches, let us assume that. To sum it up, I would prefer to push all these related patches and close this ticket when it actually works. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0473-0477+0497 Managed permission updater, part 1
On 03/14/2014 04:27 PM, Petr Viktorin wrote: On 03/13/2014 02:01 PM, Petr Viktorin wrote: On 03/07/2014 10:45 AM, Martin Kosek wrote: On 03/05/2014 01:48 PM, Petr Viktorin wrote: On 03/03/2014 04:10 PM, Petr Viktorin wrote: On 02/28/2014 02:47 PM, Petr Viktorin wrote: On 02/28/2014 02:12 PM, Martin Kosek wrote: On 02/26/2014 10:44 AM, Petr Viktorin wrote: Hello, Here are a few fixes/improvements, and the first part of a managed permission updater. The patches should go in this order but don't need to be ACKed/pushed all at once. Design: http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 This part is a preview of sorts, to get the basic mechanism and the metadata format reviewed before I add all of the default read permissions. It implements the first section of Default Permission Updater in the design; Replacing legacy default permissions and Removing the global anonymous read ACI is left for later. Metadata is added for the netgroup plugin* for starters [...] 1) 476: Typo in test name: +desc='Search fo rnonexisting permission with : in the name', Will fix. Fixed 2) 477: do we want to log anything when permission is up to date? +try: +ldap.update_entry(entry) +except errors.EmptyModlist: +return I don't think that's needed, after all that's the expected behavior in all but the first upgrade. But I'll be happy to add it if you think it would be better. I've added a DEBUG message here. [...] 4) I have been quite resilient to the prefixes for the permissions, but it seems it is the easier possible approach to fix conflicts with user permissions without having to check that later for every upgrade or doing more complex stuff like multiple RDNs or different container for system and user permissions. I am now just thinking about the prefixing. Now you use this name: ipa:Read Netgroups Would it be nicer to use: IPA:Read Netgroups or IPA: Read Netgroups or even [IPA] Read Netgroups ? :-) Bikeshedding time! Everyone on the list, please chime in! Bikeshedding results from today's meeting: ipa: pviktori++ System: mkosek++ simo+ ab++ Builtin: simo++ pvo+ Default: The winner is System: , so I'll go and change to that. Done. Thanks. The patch set looks good now, I just see that the update process may not be optimal After I run the upgrade second time, it still tries to update the ACI even though there was no change done to the permission object and should thus raise errors.EmptyModlist and skip the ACI update: 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory)(targetfilter = (objectclass=ipanisnetgroup))(version 3.0;acl permission:System: Read Netgroups;allow (read,compare,search) userdn = ldap:///all;;)' from cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory)(targetfilter = (objectclass=ipanisnetgroup))(version 3.0;acl permission:System: Read Netgroups;allow (read,compare,search) userdn = ldap:///all;;)' to cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z INFO No changes to ACI 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroup Membership Any idea what could cause this? Ah, you're right. The updater tried to remove the 'top' objectclass, since it found that in the permission but it wasn't in permission.object_class. I added 'top' to the list in a new patch. There was a minor conflict with master; I'm attaching the whole rebased patchset for convenience. Rebased again. I see the last issue I found is fixed - works fine. ACK for all patches after you fix another VERSION file conflict. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0498 permission plugin: Do not add the ipapermissionv2 for output
On 03/17/2014 05:21 PM, Petr Viktorin wrote:
This fixes an extra objectclass being added to legacy permissions in
permission-{show,find} output. For the other attributes, we want to show what
would be there if the permission was upgraded, but for objectclass and flags
we
want to show exactly what is in LDAP.
https://fedorahosted.org/freeipa/ticket/4257
For all the tests to pass, apply this on top of my patch 0475
ACK. Pushed to master: 3dcad00b946e72733cccf279ec00b426d902c867
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added
On 03/24/2014 11:42 AM, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 13:06:21 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 12:58 PM, Martin Kosek wrote:
On 03/21/2014 12:38 PM, Petr Viktorin wrote:
On 03/21/2014 12:00 PM, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 10:33:00 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 10:29 AM, Petr Viktorin wrote:
On 03/20/2014 04:22 PM, Misnyovszki Adam wrote:
On Thu, 20 Mar 2014 14:19:51 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Fri, 14 Mar 2014 13:26:15 -0400
Rob Crittenden rcrit...@redhat.com wrote:
Misnyovszki Adam wrote:
Hi,
automember-rebuild uses asynchronous 389 task, and returned
success even if the task didn't run. This patch fixes this
issue adding a --nowait parameter to 'ipa
automember-rebuild', defaulting to False, thus when the
script runs without it, it waits for the 'nstaskexitcode'
attribute, which means the task has finished, according to
http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation.
Old usage can be enabled using --nowait.
https://fedorahosted.org/freeipa/ticket/4239
Request for comments:
- Should I add a parameter to specify the polling time? (now
1ms)
- Should I add a parameter to specify the maximum polling
number? Now if something fails about creating the task, it
polls forever.
- Obviously, if these parameters should be added, there
should be a reasonable default for them (~ Required=False,
Default=X).
I don't think you need a polling time, esp since this is
hidden from the user, but I think that is probably too short
and you may end up hammering the LDAP server.
I also wonder if there should be some maximum wait time. I
don't like loops that can never exit. I'm at a loss for what
that time should be though. And we'd need to spell out that
we gave up waiting, not that the task necessarily failed. So
rather than having a polling time option, rename nowait into
wait_for=20, so wait for 20 seconds. Or something like that.
I'd suggest using get_entry since you already know the full
DN and there is only ever one. It would make this much more
readable.
I wonder if some top-level documentation should be added to
flesh this out some more. This does, for example, return
False in one case. The meaning for that should be spelled
out.
rob
Hi,
personally I would keep --no-wait, with a delay of 1 seconds,
and a maximum waiting time for 60 seconds. Questions is, do
we need to parameterize with other parameters(wait-for to the
maximum time, and/or poll-delay for the delay time, both not
required), or it is not a case which worth to develop?
Greets
Adam
Hi,
here are the corrections Petr asked, also the other patch
conatins the plugin registration refactor.
Thanks!
You forgot an alternate summary for the --no-wait case. (Make
sure to output the DN in this case, so it's possible to poll
for it.)
Instead of `task['nstaskexitcode'][0]` please use
`task.single_value['nstaskexitcode']`.
There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it
in a variable would be better?)
Here:
raise errors.DatabaseError(
desc=_(Automember rebuild membership task failed),
info=_(nstaskexitcode = '%s' %
str(task['nstaskexitcode'][0])))
there's no need to call str() on %'s argument.
Also, use natural language (like Task exit code: %s),
otherwise there's no need to mark the message for translation.
And one more thing: Please bump the minor version in the VERSION
file when API.txt changes.
Hi,
everything is corrected!
Greets
Adam
Sorry for dragging this so long, but:
The DN should not be a part of the summary, because that makes it
hard to parse when using the API. It should be returned as a part
of the result. To do that, you'd need to change the output type:
has_output = output.standard_entry
has_output_params = (
DNParam(
'dn',
label=_('Task automember'),
doc=_('DN of the started task'),
),
)
and provide a dict in result, instead of True. (And with
--no-wait, add the dn to that dict.)
Do really want to use 'dn' for the DNParam? dn is already used for
standard entry DN when --all is used, right? automembertaskdn may
be better.
Well, I think DN of the added entry is exactly what this is.
Also, Task automember label sounds strange to me, would
Automember task DN be better?
I meant Task DN, sorry for the thinko.
One more thing, which came to my mind after reviewing the code for
myself once again, if the task fails with an exit code other than 0,
there is a DatabaseError raised, which is just fine. But in the info,
should I specify not only the exit code, but also the DN of the task,
or is it unnecessary?
Thanks
Adam
DS tasks usually have the error in some of their attributes, so if there is
such attribute, I would report what the error is. It is
Re: [Freeipa-devel] OTP work, what's left?
On Sun, 2014-03-23 at 23:26 +0200, Alexander Bokovoy wrote: Hi! I've updated my COPR repo with current git master versions of FreeIPA and SSSD with few added patches on top that close OTP gaps (Nathaniel's patch 0038 and Jakub Hrozek's patch for password changes). With these patches we currently lack following parts of the OTP work: - OTP sync client. Still in development, patches and approach need additional review/discussion on the list - Password change in WebUI fails when OTP token exist for the user. More detailed examination is needed, I'm getting ACIError. http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ https://fedorahosted.org/freeipa/query?component=OTPstatus=!closed That should be a list of the open bugs, including feature requests. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
