Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
btw my work in progress is here: https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/log/?h=subdomfo
On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
I agree that sdap_id_op should not change the status on its own and that it should be fixed with the refactoring planned for 1.14.
Nevertheless I wonder if you already have a patch which covers all the other cases if it wouldn't be an improvement to the current state to add it?
I would assume that most issue are caused by error during the DNS lookup, initial connect or authentication which iirc are not handled by sdap_id_op. I would assume that error during sdap_id_op, e.g. a server shutdown, are more rare and it would be acceptable to let those errors switch the whole backend to offline until the refactoring is done.
bye, Sumit
btw my work in progress is here: https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/log/?h=subdomfo _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Sep 02, 2015 at 10:11:46AM +0200, Sumit Bose wrote:
On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
I agree that sdap_id_op should not change the status on its own and that it should be fixed with the refactoring planned for 1.14.
Nevertheless I wonder if you already have a patch which covers all the other cases if it wouldn't be an improvement to the current state to add it?
I would assume that most issue are caused by error during the DNS lookup, initial connect or authentication which iirc are not handled by sdap_id_op.
The LDAP connection and the failover during the connection is handled by sdap_id_op. That's the crux of the problem I didn't realize when doing the initial design (frankly I didn't think the sdap operation was in the business of changing failover status and offline status for the backend..)
I would assume that error during sdap_id_op, e.g. a server shutdown, are more rare and it would be acceptable to let those errors switch the whole backend to offline until the refactoring is done.
Hmm perhaps you're right that we can try solve at least the use-cases while we have the code in mind. I think we mostly care about: - don't bring the whole AD backend offline if there are connection problems with discovering subdomains when AD client is connected to a subdomain - don't bring the whole IPA backend offline if there are connection problems with AD server in server mode - don't bring the while IPA backend offline if there are connection problems with AD server with IPA client
I think these are solvable without major hacks. I'll see about fixing these use-cases.
The rest needs to be fixed when I work on the LDAP code and Pavel Brezina works on the failover changes.
On Wed, Sep 02, 2015 at 12:42:17PM +0200, Jakub Hrozek wrote:
On Wed, Sep 02, 2015 at 10:11:46AM +0200, Sumit Bose wrote:
On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
I agree that sdap_id_op should not change the status on its own and that it should be fixed with the refactoring planned for 1.14.
Nevertheless I wonder if you already have a patch which covers all the other cases if it wouldn't be an improvement to the current state to add it?
I would assume that most issue are caused by error during the DNS lookup, initial connect or authentication which iirc are not handled by sdap_id_op.
The LDAP connection and the failover during the connection is handled by sdap_id_op. That's the crux of the problem I didn't realize when doing the initial design (frankly I didn't think the sdap operation was in the business of changing failover status and offline status for the backend..)
I would assume that error during sdap_id_op, e.g. a server shutdown, are more rare and it would be acceptable to let those errors switch the whole backend to offline until the refactoring is done.
Hmm perhaps you're right that we can try solve at least the use-cases while we have the code in mind. I think we mostly care about: - don't bring the whole AD backend offline if there are connection problems with discovering subdomains when AD client is connected to a subdomain - don't bring the whole IPA backend offline if there are connection problems with AD server in server mode - don't bring the while IPA backend offline if there are connection problems with AD server with IPA client
I think these are solvable without major hacks. I'll see about fixing these use-cases.
The rest needs to be fixed when I work on the LDAP code and Pavel Brezina works on the failover changes.
The patches are on list now. Given the changes, I no longer think the patches are out of scope for 1.13.x -- downstreams would really benefit from them -- but I don't think we should block 1.13.1 over the patches either, we should rather test them out well.
FreeIPA would like us to release 1.13.1 on Monday, so I'll concentrate on reviewing your patch for #2692 and respinning the patch for #2723 so that we can do the release on Mon.
On (04/09/15 14:38), Jakub Hrozek wrote:
On Wed, Sep 02, 2015 at 12:42:17PM +0200, Jakub Hrozek wrote:
On Wed, Sep 02, 2015 at 10:11:46AM +0200, Sumit Bose wrote:
On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
I agree that sdap_id_op should not change the status on its own and that it should be fixed with the refactoring planned for 1.14.
Nevertheless I wonder if you already have a patch which covers all the other cases if it wouldn't be an improvement to the current state to add it?
I would assume that most issue are caused by error during the DNS lookup, initial connect or authentication which iirc are not handled by sdap_id_op.
The LDAP connection and the failover during the connection is handled by sdap_id_op. That's the crux of the problem I didn't realize when doing the initial design (frankly I didn't think the sdap operation was in the business of changing failover status and offline status for the backend..)
I would assume that error during sdap_id_op, e.g. a server shutdown, are more rare and it would be acceptable to let those errors switch the whole backend to offline until the refactoring is done.
Hmm perhaps you're right that we can try solve at least the use-cases while we have the code in mind. I think we mostly care about: - don't bring the whole AD backend offline if there are connection problems with discovering subdomains when AD client is connected to a subdomain - don't bring the whole IPA backend offline if there are connection problems with AD server in server mode - don't bring the while IPA backend offline if there are connection problems with AD server with IPA client
I think these are solvable without major hacks. I'll see about fixing these use-cases.
The rest needs to be fixed when I work on the LDAP code and Pavel Brezina works on the failover changes.
The patches are on list now. Given the changes, I no longer think the patches are out of scope for 1.13.x -- downstreams would really benefit from them -- but I don't think we should block 1.13.1 over the patches either, we should rather test them out well.
FreeIPA would like us to release 1.13.1 on Monday, so I'll concentrate on reviewing your patch for #2692 and respinning the patch for #2723 so that we can do the release on Mon.
I would say more realistic is in the middle of next week.
tbabej found some issues with authenticating a newly created user to FreeIPA 4.2.
sssd-1.13.0 works fine; there is just a problem with sssd master
LS
On Fri, Sep 04, 2015 at 04:12:44PM +0200, Lukas Slebodnik wrote:
On (04/09/15 14:38), Jakub Hrozek wrote:
On Wed, Sep 02, 2015 at 12:42:17PM +0200, Jakub Hrozek wrote:
On Wed, Sep 02, 2015 at 10:11:46AM +0200, Sumit Bose wrote:
On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
Hi,
ssia...
I was working on implementing https://fedorahosted.org/sssd/ticket/2637 and while for most occurences it was quite easy to set domain status instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of a hackish way by accessing the be_ctx through sdap_id_ctx. It's not trivial to change the request to operate on domains, except changing sdap_id_op_create() to also accept domain as a parameter..but we already have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an error code and don't touch the backend status, but that's even more work -- we need to do that and it's something we need to do in the next weeks anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept domain in 1.13 or do refactor the sdap_id_op for 1.14? I would personally prefer the latter..
I agree that sdap_id_op should not change the status on its own and that it should be fixed with the refactoring planned for 1.14.
Nevertheless I wonder if you already have a patch which covers all the other cases if it wouldn't be an improvement to the current state to add it?
I would assume that most issue are caused by error during the DNS lookup, initial connect or authentication which iirc are not handled by sdap_id_op.
The LDAP connection and the failover during the connection is handled by sdap_id_op. That's the crux of the problem I didn't realize when doing the initial design (frankly I didn't think the sdap operation was in the business of changing failover status and offline status for the backend..)
I would assume that error during sdap_id_op, e.g. a server shutdown, are more rare and it would be acceptable to let those errors switch the whole backend to offline until the refactoring is done.
Hmm perhaps you're right that we can try solve at least the use-cases while we have the code in mind. I think we mostly care about: - don't bring the whole AD backend offline if there are connection problems with discovering subdomains when AD client is connected to a subdomain - don't bring the whole IPA backend offline if there are connection problems with AD server in server mode - don't bring the while IPA backend offline if there are connection problems with AD server with IPA client
I think these are solvable without major hacks. I'll see about fixing these use-cases.
The rest needs to be fixed when I work on the LDAP code and Pavel Brezina works on the failover changes.
The patches are on list now. Given the changes, I no longer think the patches are out of scope for 1.13.x -- downstreams would really benefit from them -- but I don't think we should block 1.13.1 over the patches either, we should rather test them out well.
FreeIPA would like us to release 1.13.1 on Monday, so I'll concentrate on reviewing your patch for #2692 and respinning the patch for #2723 so that we can do the release on Mon.
I would say more realistic is in the middle of next week.
tbabej found some issues with authenticating a newly created user to FreeIPA 4.2.
Do we have a ticket already?
sssd-1.13.0 works fine; there is just a problem with sssd master
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Sep 04, 2015 at 04:17:54PM +0200, Jakub Hrozek wrote:
I would say more realistic is in the middle of next week.
btw we need to do the release on Monday otherwise we can't rebase for Fedora 23 beta, sorry.
tbabej found some issues with authenticating a newly created user to FreeIPA 4.2.
Do we have a ticket already?
I just tested the simplest scenario and it works OK to me, so we need a ticket with logs or even better accesss to a machine where we can see the bug.
On (04/09/15 16:22), Jakub Hrozek wrote:
On Fri, Sep 04, 2015 at 04:17:54PM +0200, Jakub Hrozek wrote:
I would say more realistic is in the middle of next week.
btw we need to do the release on Monday otherwise we can't rebase for Fedora 23 beta, sorry.
I would rather have stable version in beta rather then broken version.
I do not see a reason why FreeIPA should require 1.13.1
tbabej found some issues with authenticating a newly created user to FreeIPA 4.2.
Do we have a ticket already?
I just tested the simplest scenario and it works OK to me, so we need a ticket with logs or even better accesss to a machine where we can see the bug.
I asked him to file a ticket.
LS
On Fri, Sep 04, 2015 at 04:34:35PM +0200, Lukas Slebodnik wrote:
On (04/09/15 16:22), Jakub Hrozek wrote:
On Fri, Sep 04, 2015 at 04:17:54PM +0200, Jakub Hrozek wrote:
I would say more realistic is in the middle of next week.
btw we need to do the release on Monday otherwise we can't rebase for Fedora 23 beta, sorry.
I would rather have stable version in beta rather then broken version.
yes..
I do not see a reason why FreeIPA should require 1.13.1
OK,then we need to talk to freeipa before they tag the new version. We can sit down on Monday and look at the fixes to backport.
tbabej found some issues with authenticating a newly created user to FreeIPA 4.2.
Do we have a ticket already?
I just tested the simplest scenario and it works OK to me, so we need a ticket with logs or even better accesss to a machine where we can see the bug.
I asked him to file a ticket.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Sumit Bose