[PATCH] doxygen: Fix path to header file ipa_hbac.h
by Lukas Slebodnik
ehlo,
Small issue after moving libiba_hbac to new location.
Warning: tag INPUT: input source `src/providers/ipa/ipa_hbac.h' does not exist
warning: source src/providers/ipa/ipa_hbac.h is not
a readable file or directory... skipping.
LS
7 years, 9 months
[PATCH] FO: Set port to NOT_WORKING when trying a next server
by Jakub Hrozek
Hi,
attached is a patch that I think is correct and it did solve a bug I was
seeing, but I'm not sure if it's the right thing to do since the code
was stable since 2009..
What I was seeing was a scenario where an LDAP server was listening on port
389, so we were able to connect there with a socket, but then all searches
timed out during rootDSE discovery.. What happened in the sdap_id_ops.c
code was that we hit this part:
810 switch (retval) {
811 case EIO:
812 ---> case ETIMEDOUT:
813 /* this currently the only possible communication error after connection is established */
814 communication_error = true;
815 break;
816
817 default:
818 communication_error = false;
819 break;
820 }
821
And then we went here, because the connection was already established:
822 if (communication_error && current_conn != 0
823 && current_conn == op->conn_cache->cached_connection) {
824 /* do not reuse failed connection */
825 op->conn_cache->cached_connection = NULL;
826
827 DEBUG(SSSDBG_FUNC_DATA,
828 "communication error on cached connection, moving to next server\n");
829 ----> be_fo_try_next_server(op->conn_cache->id_conn->id_ctx->be,
830 op->conn_cache->id_conn->service->name);
831 }
But I admit I don't understand why does be_fo_try_next_server() set the
port status to NEUTRAL. That caused the connection code to run again,
hit the same timeout issue and then cycle again and again..
Can anyone parse from the code why do we set the port to neutral instead
of not_working in be_fo_try_next_server() ?
7 years, 9 months
[PATCH] SYSDB: Fixing DB update
by Petr Cech
Hi,
there is patch for #3023 attached.
Reason for this patch is explained in commit message.
I am open to discussion. In my opinion we don't need to connect sysdb
pointer with domain structure because it is not used in other upgrade
functions too.
Regards
--
Petr^4 Čech
7 years, 9 months
[PATCH] PAM: Allow to configure pam services for smartcards
by Lukas Slebodnik
ehlo,
attached patch should fix ticket #2926
The default case (no adding, no removing services) is tested
by pam-srv-tests.
If the patch is not ready for stable branch sssd-1-13
then we might merge this case with GPO code which uses slightly
modified way using hash tables.
LS
7 years, 9 months
Announce - SSSD 1.13 is the new LTM branch
by Jakub Hrozek
Hi,
the SSSD upstream supports some selected branches for a longer time, to
make life easier for long-term supported distributions such as Red Hat
Enterprise Linux, Ubuntu LTM or Suse Enterprise Linux.
Since the sssd-1.13 branch is quite stable and already used in several
long-term supported distributions, we decided to formally proclaim it as
a LTM (Long-Term Maintenance) release. We will be backporting important
fixes to the branch and release updates as appropriate.
Packagers and maintainers of stable distributions are encouraged to use
the sssd-1.13 releases. Please let us know (by filing a ticket or sending a
mail to sssd-devel) if you need any fixes backported to the sssd-1-13 branch.
I've updated the SSSD Trac front page:
https://fedorahosted.org/sssd/wiki/WikiStart
and the Releases page:
https://fedorahosted.org/sssd/wiki/Releases
to reflect that.
7 years, 9 months
Re: RFC - 1.13 should be our upstream LTM
by Howard Guo
Good morining Jakub.
Thanks very much for the info, 1.13 has been performing extremely well in my tests, it is a very good release.
Have a lovely weekend.
Kind regards,
Howard
On Fri, 8 Jul 2016, Jakub Hrozek wrote:
> Hi,
>
> our upstream front page still lists 1.9 as LTM, which is maybe true
> technically, because we haven't proclaimed any other release as LTM, but
> 1.9 is also very old and upstream we really just tell users to upgrade to
> 1.13.
>
> So I think we should just name 1.13 as our LTM. We already backport all
> important fixes to sssd-1-13 branch anyway. RHEL-6 is (probably) going
> to stick with 1.13 for the rest of its lifetime, but I wonder if this
> would play well with Suse and Ubuntu..Howard, Timo, are your long-term
> maintenance distributions using 1.13 and would sticking with 1.13 for them
> also make sense for you?
>
>
7 years, 9 months