Re: [SSSD] [PATCH] krb5: fix entry order in MEMORY keytab
On Fri, Jan 16, 2015 at 09:28:30PM +0100, Lukas Slebodnik wrote:
> On (15/01/15 11:15), Sumit Bose wrote:
> >Hi,
> >
> >this patch should fix https://fedorahosted.org/sssd/ticket/2557 . Please
> >see the commit message for details.
> >
> >bye,
> >Sumit
>
> realmd test (regression) passed.
> ldap + krb5 passed.
> ad passed.
>
> There are two tiny warnings from static analysers.
>
>
...
> >+&cursor)) == 0) {
> >+kerr = krb5_kt_add_entry(kctx, d_keytab, &entry);
> >+if (kerr != 0) {
> >+DEBUG(SSSDBG_OP_FAILURE, "krb5_kt_add_entry failed.\n");
> >+kt_err = krb5_kt_end_seq_get(kctx, s_keytab, &cursor);
> ^^
> this value is ignored
> >+return kerr;
> >+}
> >+
> >+kerr = sss_krb5_free_keytab_entry_contents(kctx, &entry);
> >+if (kerr != 0) {
> >+DEBUG(SSSDBG_MINOR_FAILURE, "Failed to free keytab entry.\n");
> >+kt_err = krb5_kt_end_seq_get(kctx, s_keytab, &cursor);
> ^^ this value is ignored
>
> Error: UNUSED_VALUE (CWE-563): [#def1]
> sssd-1.12.90/src/providers/krb5/krb5_keytab.c:49: returned_value: Value from
> "krb5_kt_end_seq_get(kctx, s_keytab, &cursor)" is assigned to "kt_err" here,
> but that stored value is not used.
>
> Error: UNUSED_VALUE (CWE-563): [#def2]
> sssd-1.12.90/src/providers/krb5/krb5_keytab.c:56: returned_value: Value from
> "krb5_kt_end_seq_get(kctx, s_keytab, &cursor)" is assigned to "kt_err" here,
> but that stored value is not used.
>
I skipped them intentionally, because they are of no use, but I forgot
about the analysers. Fixed.
> >+return kerr;
> >+}
> >+memset(&entry, 0, sizeof(entry));
> >+}
> >+
> >+kerr = krb5_kt_end_seq_get(kctx, s_keytab, &cursor);
> >+if (kerr != 0) {
> >+DEBUG(SSSDBG_CRIT_FAILURE, "krb5_kt_end_seq_get failed.\n");
> >+return kerr;
> >+}
> >+
...
> >@@ -153,10 +199,16 @@ krb5_error_code copy_keytab_into_memory(TALLOC_CTX
> >*mem_ctx, krb5_context kctx,
> > kerr = 0;
> > done:
> >
> >+talloc_free(tmp_mem_name);
> >+
> > if (kerr != 0) {
> > talloc_free(mem_name);
> > }
> >
> >+if (tmp_mem_keytab != NULL && krb5_kt_close(kctx, tmp_mem_keytab) != 0)
> >{
> >+DEBUG(SSSDBG_MINOR_FAILURE, "krb5_kt_close failed");
>
> You will be changing code anyway. So you can fix this as well :-)
> 4 spaces are enough
fixed
> >+}
> >+
> > if (keytab != NULL && krb5_kt_close(kctx, keytab) != 0) {
> > DEBUG(SSSDBG_MINOR_FAILURE, "krb5_kt_close failed");
> > }
>
>
> LS
Thank you for the checks and the review, new version attached.
bye,
Sumit
From cb449c569fe18f0a5fc150de4c6724ab0a3146e5 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Thu, 15 Jan 2015 10:38:33 +0100
Subject: [PATCH] krb5: fix entry order in MEMORY keytab
Since krb5_kt_add_entry() adds new entries at the beginning of a MEMORY
type keytab and not at the end a simple copy into a MEMORY type keytab
will revert the order of the keytab entries. Since e.g. the sssd_krb5
man page give hints about where to add entries into keytab files to help
SSSD to find a right entry we have to keep the order when coping a
keytab into a MEMORY type keytab. This patch fixes this by doing a
second copy to retain the original order.
Resolves https://fedorahosted.org/sssd/ticket/2557
---
src/providers/krb5/krb5_keytab.c| 118 +++-
src/tests/cmocka/test_copy_keytab.c | 82 +
2 files changed, 172 insertions(+), 28 deletions(-)
diff --git a/src/providers/krb5/krb5_keytab.c b/src/providers/krb5/krb5_keytab.c
index
0d6a85c0b8b02937fb2ee6b058174243b2e56114..e5af5de07b7983d408d6f678b50a12d219e2d8cd
100644
--- a/src/providers/krb5/krb5_keytab.c
+++ b/src/providers/krb5/krb5_keytab.c
@@ -25,20 +25,78 @@
#include "util/util.h"
#include "util/sss_krb5.h"
+static krb5_error_code do_keytab_copy(krb5_context kctx, krb5_keytab s_keytab,
+ krb5_keytab d_keytab)
+{
+krb5_error_code kerr;
+krb5_error_code kt_err;
+krb5_kt_cursor cursor;
+krb5_keytab_entry entry;
+
+memset(&cursor, 0, sizeof(cursor));
+kerr = krb5_kt_start_seq_get(kctx, s_keytab, &cursor);
+if (kerr != 0) {
+DEBUG(SSSDBG_CRIT_FAILURE, "error reading keytab.\n");
+return kerr;
+}
+
+memset(&entry, 0, sizeof(entry));
+while ((kt_err = krb5_kt_next_entry(kctx, s_keytab, &entry,
+&cursor)) == 0) {
+kerr = krb5_kt_add_entry(kctx, d_keytab, &entry);
+if (kerr != 0) {
+DEBUG(SSSDBG_OP_FAILURE, "krb5_kt_add_entry failed.\n");
+kt_err = krb5_kt_end_seq_get(kctx, s_keytab, &cursor);
+if (kt_err != 0) {
+DEBUG(SSSDBG_TRACE_ALL,
+ "krb5_k
Re: [SSSD] [PATCHES] AD: support for AD site override
On 01/15/2015 03:57 PM, Pavel Reichl wrote:
On 01/15/2015 11:21 AM, Pavel Březina wrote:
On 01/09/2015 04:56 PM, Pavel Reichl wrote:
On 01/08/2015 08:36 PM, Pavel Březina wrote:
On 01/07/2015 03:28 PM, Pavel Reichl wrote:
Please see attached patches.
Thanks.
Hi,
I know there is a design page I did not comment on but seeing the
patch now, does the option really have to be names ad_site_override?
Wouldn't simple ad_site be a better name?
I'd change the description to something like:
"Specify AD site client should try to connect to. If this option is
not set, the AD site will be auto-discovered."
We are using talloc_zero so the following code:
@@ -591,6 +593,14 @@ ad_srv_plugin_ctx_init(TALLOC_CTX *mem_ctx,
goto fail;
}
+if (ad_site_override == NULL) {
+ctx->ad_site_override = NULL;
+} else {
+ctx->ad_site_override = talloc_strdup(ctx,
ad_site_override);
+if (ctx->ad_site_override == NULL) {
+goto fail;
+}
+}
return ctx;
can be simplified to:
if (ad_site_override != NULL) {
ctx->ad_site_override = talloc_strdup(ctx, ad_site_override);
if (ctx->ad_site_override == NULL) {
goto fail;
}
}
> (please add an empty line here)
return ctx;
@@ -756,6 +766,19 @@ static void ad_srv_plugin_site_done(struct
tevent_req *subreq)
ret = ad_get_client_site_recv(state, subreq, &state->site,
&state->forest);
talloc_zfree(subreq);
+/* Ignore AD site found by dns discovery if specific site is
set in
+ * configuration file. */
+if (state->ctx->ad_site_override != NULL) {
+DEBUG(SSSDBG_TRACE_INTERNAL,
+ "Ignoring AD site found by DNS discovery: '%s', "
+ "using configured value: '%s' instead.\n",
+ state->site, state->ctx->ad_site_override);
+state->site = talloc_strdup(state,
state->ctx->ad_site_override);
+if (state->site == NULL) {
+ret = ENOMEM;
+goto done;
+}
+}
There is no need to strdup the site name if you make state->site
const.
man page:
Specify AD site client should try to connect to.
Specify AD site to which client should try to connect.
Which one sounds better?
I don't care much, maybe the second one. Should I prepare a new patch
or will you Jakub amend the patch while pushing it? Thanks.
Attached patch updates man page with Pavel's second suggestion.
Can I get the final ack? I would like to prepare scratch build for
customer ASAP.
Thanks!
Ack otherwise.
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>From 6b319c66f08a4458c7de1bc152cc4646f047c0a3 Mon Sep 17 00:00:00 2001
From: Pavel Reichl
Date: Wed, 7 Jan 2015 09:40:45 +
Subject: [PATCH 1/2] AD: add new option ad_site
This option overrides a result of the automatic site discovery.
Resolves:
https://fedorahosted.org/sssd/ticket/2486
---
src/config/SSSDConfig/__init__.py.in | 2 ++
src/config/etc/sssd.api.d/sssd-ad.conf | 1 +
src/man/sssd-ad.5.xml | 14 ++
src/providers/ad/ad_common.h | 1 +
src/providers/ad/ad_opts.h | 1 +
5 files changed, 19 insertions(+)
diff --git a/src/config/SSSDConfig/__init__.py.in b/src/config/SSSDConfig/__init__.py.in
index 500bd717fec7abcaafd5153ccca7847b91e208ad..ae00a2b7f9130725a6a766a4cbbba0a53f86dd7a 100644
--- a/src/config/SSSDConfig/__init__.py.in
+++ b/src/config/SSSDConfig/__init__.py.in
@@ -188,6 +188,8 @@ option_strings = {
'ad_gpo_map_permit' : _('PAM service names for which GPO-based access is always granted'),
'ad_gpo_map_deny' : _('PAM service names for which GPO-based access is always denied'),
'ad_gpo_default_right' : _('Default logon right (or permit/deny) to use for unmapped PAM service names'),
+'ad_site' : _('a particular site to be used by the client'),
+
# [provider/krb5]
'krb5_kdcip' : _('Kerberos server address'),
'krb5_server' : _('Kerberos server address'),
diff --git a/src/config/etc/sssd.api.d/sssd-ad.conf b/src/config/etc/sssd.api.d/sssd-ad.conf
index 3496fb4006697d380f7c9729ed9997272cbce2ea..5a5ea0c36b07d7497c1caa4208c7270d6de6dcc9 100644
--- a/src/config/etc/sssd.api.d/sssd-ad.conf
+++ b/src/config/etc/sssd.api.d/sssd-ad.conf
@@ -16,6 +16,7 @@ ad_gpo_map_service = str, None, false
ad_gpo_map_permit = str, None, false
ad_gpo_map_deny = str, None, false
ad_gpo_default_right = str, None, false
+ad_site = str, None, false
ldap_uri = str, None, false
ldap_backup_uri = str, None, false
ldap_search_base = str, None, false
diff --git a/src/man/sssd-ad.5.xml b/src/man/sssd-ad.5.xml
index 1b33f28ab601871fbd52c47a6a829a24b9b67302..461390fe3a82ed7744da3
Re: [SSSD] Config file ownership and cwrap tests
On Fri, Jan 16, 2015 at 10:55:37PM +0200, Nikolai Kondrashov wrote:
> On 01/16/2015 08:29 PM, Nikolai Kondrashov wrote:
> >On 01/16/2015 06:54 PM, Jakub Hrozek wrote:
> >>On Fri, Jan 16, 2015 at 06:40:51PM +0200, Nikolai Kondrashov wrote:
> >>>On 01/16/2015 02:48 PM, Lukas Slebodnik wrote:
> On (16/01/15 14:22), Nikolai Kondrashov wrote:
> >On 01/14/2015 08:09 PM, Lukas Slebodnik wrote:
> >>Using fakeroot is much better solution then adding hack with env
> >>variables.
> >>
> >>BTW fakeroot provides a fake root environment by means of LD_PRELOAD.
> >>The only disadvantage of fakeroot is that is not available on all
> >>platforms.
> >>(but there is not problem to prepare COPR repo)
> >>
> >>So basically there is not a big difference between fakeroot and other
> >>cwrap
> >>packages.
> >
> >Just an update: it's not all rainbows in the fakeroot land either. It's
> >not
> >wrapping open()/create(). That means that all files sssd creates belong
> >to
> >root under fakeroot (even though it can chown them to anything), which
> >is not
> >compatible with --with-sssd-user.
> >
> >I'm also having some problem starting sssd as root under fakeroot.
> >Something
> >to do with D-BUS sockets probably.
> We do not use dbus communication directly (execpt sssd_ifp.
> We use unix sockets and libdbus is used just for marshaling.
> >>>
> >>>Ah, yes, I think I can see that now.
> >>>
> >Will keep digging.
>
> Feel free to send mails to sssd-devel with any problem.
> >>>
> >>>Thank you, Lukas.
> >>>
> >>>I think this has something to do with my problems:
> >>>
> >>> stat("/root/.dbus-keyrings", 0x7fff248f2490) = -1 EACCES (Permission
> >>> denied)
> >>
> >>Which process does this? Can you post more context?
> >>
> >>The sbus communication is peer-to-peer..
> >
> >sssd and sssd_be. I've got all the logs and straces and whatever. Basically,
> >it seems D-Bus is trying to store its keyring in ~/.dbus-keyrings directory.
> >With user being root it naturally tries to store it in /root/.dbus-keyrings.
> >
> >Actually, as we have control of passswd database, we can put root's home
> >anywhere. I'll try that.
>
> Yep, that helped.
>
> However, I wonder does it really put its keyring into root's
> home during normal operation and if that's what we want.
To be honest, this is a detail of D-Bus I don't know. Colin Walters
might know better..
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] AD: support for AD site override
On Mon, Jan 19, 2015 at 09:39:41AM +0100, Pavel Reichl wrote: > >>man page: > >>Specify AD site client should try to connect to. > >>Specify AD site to which client should try to connect. > >> > >>Which one sounds better? > >I don't care much, maybe the second one. Should I prepare a new patch or > >will you Jakub amend the patch while pushing it? Thanks. Oops, sorry, this one slipped. > Attached patch updates man page with Pavel's second suggestion. > Can I get the final ack? I would like to prepare scratch build for customer > ASAP. I like the second form as well, I think it should say "the client". Could you ping some native speaker to help us out? btw go ahead and built the test package, I'm sure the customer is more interested in functionality rather than a typo in a man page.. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] AD: support for AD site override
On 01/19/2015 09:58 AM, Jakub Hrozek wrote: On Mon, Jan 19, 2015 at 09:39:41AM +0100, Pavel Reichl wrote: man page: Specify AD site client should try to connect to. Specify AD site to which client should try to connect. Which one sounds better? I don't care much, maybe the second one. Should I prepare a new patch or will you Jakub amend the patch while pushing it? Thanks. Oops, sorry, this one slipped. Attached patch updates man page with Pavel's second suggestion. Can I get the final ack? I would like to prepare scratch build for customer ASAP. I like the second form as well, I think it should say "the client". Could you ping some native speaker to help us out? Dan, can you help us with the man page description? btw go ahead and built the test package, I'm sure the customer is more interested in functionality rather than a typo in a man page.. OK, I'll do. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] krb5: fix entry order in MEMORY keytab
On (19/01/15 09:23), Sumit Bose wrote: >On Fri, Jan 16, 2015 at 09:28:30PM +0100, Lukas Slebodnik wrote: >> On (15/01/15 11:15), Sumit Bose wrote: >> >Hi, >> > >> >this patch should fix https://fedorahosted.org/sssd/ticket/2557 . Please >> >see the commit message for details. >> > >> >bye, >> >Sumit >> >> realmd test (regression) passed. >> ldap + krb5 passed. >> ad passed. >> >> There are two tiny warnings from static analysers. >> >> > > >Thank you for the checks and the review, new version attached. > >bye, >Sumit >From cb449c569fe18f0a5fc150de4c6724ab0a3146e5 Mon Sep 17 00:00:00 2001 >From: Sumit Bose >Date: Thu, 15 Jan 2015 10:38:33 +0100 >Subject: [PATCH] krb5: fix entry order in MEMORY keytab > >Since krb5_kt_add_entry() adds new entries at the beginning of a MEMORY >type keytab and not at the end a simple copy into a MEMORY type keytab >will revert the order of the keytab entries. Since e.g. the sssd_krb5 >man page give hints about where to add entries into keytab files to help >SSSD to find a right entry we have to keep the order when coping a >keytab into a MEMORY type keytab. This patch fixes this by doing a >second copy to retain the original order. > >Resolves https://fedorahosted.org/sssd/ticket/2557 >--- ACK++ http://sssd-ci.duckdns.org/logs/job/6/19/summary.html LS ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
On 01/18/2015 03:24 AM, Traiano Welcome wrote: Hi Dmitri On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal wrote: On 12/24/2014 01:04 AM, Traiano Welcome wrote: Hi List I have a large number of legacy hosts with upper-case host names, that I'd like to configure as IPA clients. However ipa client refuses to accept upper case hostnames during configuration time. I think this derives from the fact that the kerberos5 database stores host names in a case sensitive way and requires that the DNS hostname matches the server hostname case. My question is: Is it mandatory that the hostname be lower-cased, or is there a safe workaround that will allow IPA client to work with hosts that have upper case host names ? Thanks in advance! Traiano See man sssd-ipa ipa_hostname (string) Optional. May be set on machines where the hostname(5) does not reflect the fully qualified name used in the IPA domain to identify this host. AFAIR you use this setting for the cases when you want the actual machine name be different than the one IPA has. It looks like I would have to add this parameter in the sssd.conf before running the ipa client configuration. In that case, would the configurator not overwrite this parameter ? Or is there some way to provide this option to ipa-client-install initially? AFAIR then you have to configure it manually. But this question belongs more to SSSD list so I am moving it there. Also I think the option is to change the name of the host, enroll automatically, then change it back and update the configuration. But I would prefer SSSD gurus to confirm that. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project Thanks in advance, Traiano -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] krb5: fix entry order in MEMORY keytab
On Mon, Jan 19, 2015 at 10:29:08AM +0100, Lukas Slebodnik wrote: > On (19/01/15 09:23), Sumit Bose wrote: > >On Fri, Jan 16, 2015 at 09:28:30PM +0100, Lukas Slebodnik wrote: > >> On (15/01/15 11:15), Sumit Bose wrote: > >> >Hi, > >> > > >> >this patch should fix https://fedorahosted.org/sssd/ticket/2557 . Please > >> >see the commit message for details. > >> > > >> >bye, > >> >Sumit > >> > >> realmd test (regression) passed. > >> ldap + krb5 passed. > >> ad passed. > >> > >> There are two tiny warnings from static analysers. > >> > >> > > > > > >Thank you for the checks and the review, new version attached. > > > >bye, > >Sumit > > >From cb449c569fe18f0a5fc150de4c6724ab0a3146e5 Mon Sep 17 00:00:00 2001 > >From: Sumit Bose > >Date: Thu, 15 Jan 2015 10:38:33 +0100 > >Subject: [PATCH] krb5: fix entry order in MEMORY keytab > > > >Since krb5_kt_add_entry() adds new entries at the beginning of a MEMORY > >type keytab and not at the end a simple copy into a MEMORY type keytab > >will revert the order of the keytab entries. Since e.g. the sssd_krb5 > >man page give hints about where to add entries into keytab files to help > >SSSD to find a right entry we have to keep the order when coping a > >keytab into a MEMORY type keytab. This patch fixes this by doing a > >second copy to retain the original order. > > > >Resolves https://fedorahosted.org/sssd/ticket/2557 > >--- > > ACK++ > > http://sssd-ci.duckdns.org/logs/job/6/19/summary.html master: 576ad637181b80d39a4e136c9afbf34c57f76156 sssd-1-12: 24df1487413d13248dcc70d2548a763930da4c65 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
On Mon, Jan 19, 2015 at 07:38:54AM -0500, Dmitri Pal wrote: > On 01/18/2015 03:24 AM, Traiano Welcome wrote: > >Hi Dmitri > > > > > >On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal wrote: > >>On 12/24/2014 01:04 AM, Traiano Welcome wrote: > >>>Hi List > >>> > >>>I have a large number of legacy hosts with upper-case host names, that > >>>I'd like to configure as IPA clients. However ipa client refuses to > >>>accept upper case hostnames during configuration time. > >>> > >>>I think this derives from the fact that the kerberos5 database stores > >>>host names in a case sensitive way and requires that the DNS hostname > >>>matches the server hostname case. > >>> > >>>My question is: Is it mandatory that the hostname be lower-cased, or > >>>is there a safe workaround that will allow IPA client to work with > >>>hosts that have upper case host names ? > >>> > >>>Thanks in advance! > >>>Traiano > >>> > >>See man sssd-ipa > >> > >>ipa_hostname (string) > >>Optional. May be set on machines where the hostname(5) does not > >>reflect the fully qualified name used in the IPA domain to identify this > >>host. > >> > >>AFAIR you use this setting for the cases when you want the actual machine > >>name be different than the one IPA has. > > > > > >It looks like I would have to add this parameter in the sssd.conf > >before running the ipa client configuration. In that case, would the > >configurator not overwrite this parameter ? > >Or is there some way to provide this option to ipa-client-install initially? > > AFAIR then you have to configure it manually. > But this question belongs more to SSSD list so I am moving it there. > > Also I think the option is to change the name of the host, enroll > automatically, then change it back and update the configuration. > But I would prefer SSSD gurus to confirm that. Have you tried the --hostname option of ipa-client-install? From the help output: --hostname=HOSTNAME The hostname of this machine (FQDN). If specified, the hostname will be set and the system configuration will be updated to persist over reboot. By default a nodename result from uname(2) is used. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] MAKE: Don't include autoconf generated file to tarball
ehlo, simple patch is attached. LS ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] MAKE: Don't include autoconf generated file to tarball
I fail to see the patch, sorry. On 01/19/2015 03:57 PM, Lukas Slebodnik wrote: ehlo, simple patch is attached. LS ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] MAKE: Don't include autoconf generated file to tarball
On (19/01/15 15:57), Lukas Slebodnik wrote: >ehlo, > >simple patch is attached. And one more time with missing patch. LS >From c90524635bf2a517f1d9ef1b48870ad138798096 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 19 Jan 2015 14:25:15 +0100 Subject: [PATCH] MAKE: Don't include autoconf generated file to tarball --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index c14a50fc362938164ada3e976c35d2458a7bb6e6..ca8921bb132db6b7a57d9436a3219057d08b64c6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -381,7 +381,7 @@ AM_CPPFLAGS = \ -DSSS_SSH_SOCKET_NAME=\"$(pipepath)/ssh\" \ -DLOCALEDIR=\"$(localedir)\" -EXTRA_DIST = build/config.rpath +EXTRA_DIST = SSSD_RESPONDER_OBJ = \ src/responder/common/negcache.c \ -- 2.1.0 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] MAKE: Don't include autoconf generated file to tarball
On (19/01/15 15:59), Pavel Reichl wrote: >I fail to see the patch, sorry. >On 01/19/2015 03:57 PM, Lukas Slebodnik wrote: >>ehlo, >> >>simple patch is attached. >> Why is Bottom-posting better than Top-posting http://www.caliburn.nl/topposting.html LS ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
On 01/19/2015 09:22 AM, Jakub Hrozek wrote: On Mon, Jan 19, 2015 at 07:38:54AM -0500, Dmitri Pal wrote: On 01/18/2015 03:24 AM, Traiano Welcome wrote: Hi Dmitri On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal wrote: On 12/24/2014 01:04 AM, Traiano Welcome wrote: Hi List I have a large number of legacy hosts with upper-case host names, that I'd like to configure as IPA clients. However ipa client refuses to accept upper case hostnames during configuration time. I think this derives from the fact that the kerberos5 database stores host names in a case sensitive way and requires that the DNS hostname matches the server hostname case. My question is: Is it mandatory that the hostname be lower-cased, or is there a safe workaround that will allow IPA client to work with hosts that have upper case host names ? Thanks in advance! Traiano See man sssd-ipa ipa_hostname (string) Optional. May be set on machines where the hostname(5) does not reflect the fully qualified name used in the IPA domain to identify this host. AFAIR you use this setting for the cases when you want the actual machine name be different than the one IPA has. It looks like I would have to add this parameter in the sssd.conf before running the ipa client configuration. In that case, would the configurator not overwrite this parameter ? Or is there some way to provide this option to ipa-client-install initially? AFAIR then you have to configure it manually. But this question belongs more to SSSD list so I am moving it there. Also I think the option is to change the name of the host, enroll automatically, then change it back and update the configuration. But I would prefer SSSD gurus to confirm that. Have you tried the --hostname option of ipa-client-install? From the help output: --hostname=HOSTNAME The hostname of this machine (FQDN). If specified, the hostname will be set and the system configuration will be updated to persist over reboot. By default a nodename result from uname(2) is used. This is not what the person wants. He wants to use short names instead of the FQDNs. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] SPEC: Use libnl3 for epel6
ehlo,
RHEL/CentoOS 6.6 already contains libnl3.
LS
>From c1ba55900dacc47424348ad7aa57bdaa8b3f7bff Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik
Date: Mon, 19 Jan 2015 15:58:44 +0100
Subject: [PATCH] SPEC: Use libnl3 for epel6
RHEL6.6 contains libnl3.
---
contrib/sssd.spec.in | 4
1 file changed, 4 deletions(-)
diff --git a/contrib/sssd.spec.in b/contrib/sssd.spec.in
index
bea68f1bbceac232f4ca019111b6262dca3380eb..37d1b963dc2745a22efb3f93d78e7b505343e132
100644
--- a/contrib/sssd.spec.in
+++ b/contrib/sssd.spec.in
@@ -118,11 +118,7 @@ BuildRequires: libcmocka-devel
BuildRequires: uid_wrapper
BuildRequires: nss_wrapper
%endif
-%if (0%{?fedora} || 0%{?rhel} >= 7)
BuildRequires: libnl3-devel
-%else
-BuildRequires: libnl-devel
-%endif
%if (0%{?use_systemd} == 1)
BuildRequires: systemd-devel
%endif
--
2.1.0
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] AD: support for AD site override
Sure, I'm behind (More than I would like) on some of my automation, but I will take care of it in a couple of days. Dan Lavu Red Hat, Inc. Senior Quality Engineer 571.449.RMRF (7673) mobile d...@redhat.com - Original Message - From: "Pavel Reichl" To: sssd-devel@lists.fedorahosted.org, d...@redhat.com Sent: Monday, January 19, 2015 4:07:01 AM Subject: Re: [SSSD] [PATCHES] AD: support for AD site override On 01/19/2015 09:58 AM, Jakub Hrozek wrote: > On Mon, Jan 19, 2015 at 09:39:41AM +0100, Pavel Reichl wrote: man page: Specify AD site client should try to connect to. Specify AD site to which client should try to connect. Which one sounds better? >>> I don't care much, maybe the second one. Should I prepare a new patch or >>> will you Jakub amend the patch while pushing it? Thanks. > Oops, sorry, this one slipped. > >> Attached patch updates man page with Pavel's second suggestion. >> Can I get the final ack? I would like to prepare scratch build for customer >> ASAP. > I like the second form as well, I think it should say "the client". > Could you ping some native speaker to help us out? Dan, can you help us with the man page description? > > btw go ahead and built the test package, I'm sure the customer is more > interested in functionality rather than a typo in a man page.. OK, I'll do. > ___ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
On Mon, Jan 19, 2015 at 10:03:34AM -0500, Dmitri Pal wrote: > On 01/19/2015 09:22 AM, Jakub Hrozek wrote: > >On Mon, Jan 19, 2015 at 07:38:54AM -0500, Dmitri Pal wrote: > >>On 01/18/2015 03:24 AM, Traiano Welcome wrote: > >>>Hi Dmitri > >>> > >>> > >>>On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal wrote: > On 12/24/2014 01:04 AM, Traiano Welcome wrote: > >Hi List > > > >I have a large number of legacy hosts with upper-case host names, that > >I'd like to configure as IPA clients. However ipa client refuses to > >accept upper case hostnames during configuration time. > > > >I think this derives from the fact that the kerberos5 database stores > >host names in a case sensitive way and requires that the DNS hostname > >matches the server hostname case. > > > >My question is: Is it mandatory that the hostname be lower-cased, or > >is there a safe workaround that will allow IPA client to work with > >hosts that have upper case host names ? > > > >Thanks in advance! > >Traiano > > > See man sssd-ipa > > ipa_hostname (string) > Optional. May be set on machines where the hostname(5) does > not > reflect the fully qualified name used in the IPA domain to identify this > host. > > AFAIR you use this setting for the cases when you want the actual machine > name be different than the one IPA has. > >>> > >>>It looks like I would have to add this parameter in the sssd.conf > >>>before running the ipa client configuration. In that case, would the > >>>configurator not overwrite this parameter ? > >>>Or is there some way to provide this option to ipa-client-install > >>>initially? > >>AFAIR then you have to configure it manually. > >>But this question belongs more to SSSD list so I am moving it there. > >> > >>Also I think the option is to change the name of the host, enroll > >>automatically, then change it back and update the configuration. > >>But I would prefer SSSD gurus to confirm that. > >Have you tried the --hostname option of ipa-client-install? From the > >help output: > > > >--hostname=HOSTNAME > > The hostname of this machine (FQDN). If specified, the > > hostname will be set and the system configuration will > > be updated to persist over reboot. By default a > > nodename result from uname(2) is used. > This is not what the person wants. > He wants to use short names instead of the FQDNs. Ah, I misread the question, then. As Petr Spacek said, I would recommend against it. Even though Kerberos got a lot more forgiving lately in this area. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
On 01/19/2015 04:20 PM, Jakub Hrozek wrote: On Mon, Jan 19, 2015 at 10:03:34AM -0500, Dmitri Pal wrote: On 01/19/2015 09:22 AM, Jakub Hrozek wrote: On Mon, Jan 19, 2015 at 07:38:54AM -0500, Dmitri Pal wrote: On 01/18/2015 03:24 AM, Traiano Welcome wrote: Hi Dmitri On Tue, Dec 30, 2014 at 12:17 AM, Dmitri Pal wrote: On 12/24/2014 01:04 AM, Traiano Welcome wrote: Hi List I have a large number of legacy hosts with upper-case host names, that I'd like to configure as IPA clients. However ipa client refuses to accept upper case hostnames during configuration time. I think this derives from the fact that the kerberos5 database stores host names in a case sensitive way and requires that the DNS hostname matches the server hostname case. My question is: Is it mandatory that the hostname be lower-cased, or is there a safe workaround that will allow IPA client to work with hosts that have upper case host names ? Thanks in advance! Traiano See man sssd-ipa ipa_hostname (string) Optional. May be set on machines where the hostname(5) does not reflect the fully qualified name used in the IPA domain to identify this host. AFAIR you use this setting for the cases when you want the actual machine name be different than the one IPA has. It looks like I would have to add this parameter in the sssd.conf before running the ipa client configuration. In that case, would the configurator not overwrite this parameter ? Or is there some way to provide this option to ipa-client-install initially? AFAIR then you have to configure it manually. But this question belongs more to SSSD list so I am moving it there. Also I think the option is to change the name of the host, enroll automatically, then change it back and update the configuration. But I would prefer SSSD gurus to confirm that. Have you tried the --hostname option of ipa-client-install? From the help output: --hostname=HOSTNAME The hostname of this machine (FQDN). If specified, the hostname will be set and the system configuration will be updated to persist over reboot. By default a nodename result from uname(2) is used. This is not what the person wants. He wants to use short names instead of the FQDNs. Ah, I misread the question, then. As Petr Spacek said, I would recommend against it. Even though Kerberos got a lot more forgiving lately in this area. I know we do not recommend it but I also know it is possible. The question was is it possible in an automated way or only via manual configuration. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] sbus: support multiple interfaces on single object path
On Fri, Jan 16, 2015 at 02:25:39PM +0100, Pavel Březina wrote:
> On 01/16/2015 02:06 PM, Jakub Hrozek wrote:
> >>+#define CHECK_SIGNATURE(req, error, label, exp) do { \
> >>+const char *__sig; \
> >>+__sig = dbus_message_get_signature(req->message); \
> >>+if (strcmp(__sig, exp) != 0) { \
> >>+error = sbus_error_new(req, DBUS_ERROR_INVALID_ARGS, \
> >>+ "Invalid arguments: expected \"%s\", got \"%s\"", exp,
> >>__sig); \
> >>+goto label; \
> >
> >Another flow-changing macro...I'm fine with wrappering this in a
> >function, but please don't jump from macros..
>
> It's funny that you don't like it, since I learned it from you :-)
Damn it, past Jakub :-)
In general, macros that change the flow are really hard to debug and
what's even worse is that it might not be obvious that the macro can
also jump.
>
> The whole point of those macros is to move error checking out of the
> function. If you put the code inside a function you still have to test the
> result in the caller so it doesn't make any sense.
>
> I can get rid of CHECK_SIGNATURE since it is used on three places only
> anyway. But WRITE_DATA makes the code more readable. As you said yourself,
> fprintf is not really expected to fail. This way it is possible to focus on
> the flow of the generator itself instead of seeing four lines that are not
> supposed to be executed ever after each fprintf.
>
> This is IMHO much better:
> WRITE_DATA(file, ret, done, FMT_METHOD_NOARG, method->name);
> WRITE_DATA(file, ret, done, FMT_METHOD, method->name);
> WRITE_DATA(file, ret, done, FMT_METHOD_CLOSE);
OK, in this single occurence, let's allow the jump in the macro, but
please rename the macro so that it's clear that it can change the flow
of the program. Maybe something like "WRITE_OR_FAIL".
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] sbus: support multiple interfaces on single object path
On Fri, Jan 16, 2015 at 03:05:31PM +0100, Pavel Březina wrote:
> On 01/16/2015 02:06 PM, Jakub Hrozek wrote:
> >On Wed, Dec 17, 2014 at 01:36:01PM +0100, Pavel Březina wrote:
> >>On 12/16/2014 01:19 PM, Pavel Březina wrote:
> >After seeing the complexity of the patches, I propose to commit them to
> >master only..some really fundamental code is changed and I don't feel we
> >should break 1.12.x's sbus code...1.12.x is already being used by some
> >downstreams. We can backport later.
>
> I don't oppose. But the sbus code has lots of unit tests and if it would not
> work the whole sssd would stop functioning immediately so we would notice. I
> think it is very unlikely that it breaks anything and we wouldn't see it
> soon.
I'm not worried about the simple cases -- I've been using the patches
since Friday without issues. What I'm worried are the cases that are not
so easily tested, like a service being restarted by the monitor. There
is might make sense to allow the patches to brew in a less stable
branch.
Let's commit them to master only first and wait a bit. If the new sbus
functionality is requested by Stef or anyone else to be backported to
Fedora, then we'll backport the patches. I don't think the backport
would be too costly, after all, most changes are self-contained in the
sbus/ directory.
>
> >> From 2ad42ef7047ed4a6ae54e5e0ec6a3bc567c6ddbf Mon Sep 17 00:00:00 2001
> >>From: =?UTF-8?q?Pavel=20B=C5=99ezina?=
> >>Date: Wed, 10 Dec 2014 19:24:58 +0100
> >>Subject: [PATCH 01/13] sbus: add new iface via sbus_conn_register_iface()
> >>
> >>Rename sbus_conn_add_interface() to sbus_conn_register_iface()
> >>and remove sbus_new_interface() calls since it is just one more
> >>unnecessary call outside the sbus code.
> >>
> >>The function sbus_new_interface() is made static and used
> >>directly in sbus_conn_register_iface().
> >>
> >>The name was chosen to better describe what the function is
> >>doing. That it registers an interface on a given object path.
> >>The same interface can be used with different paths so it is
> >>not really about adding an interface.
> >>
> >>Preparation for:
> >>https://fedorahosted.org/sssd/ticket/2339
> >
> >I agree with the intention, but can you also (maybe in another patch,
> >I'll leave that up to you) consolidate the naming of the private data
> >variable? It seems to be passed in as 'pvt' to the new function, but
> >received 'handler_data' in the handler.
> >
> >Alternatively, add a comment. This is just to make the code easier to
> >follow when we look at it again next time.
>
> Do you propose pvt -> handler_data or the opposite?
handler_data currently sounds better to me, is the pointer data consumed
anywhere else than the handler?
>
> >
> >> From 4b170924c8ebb57f35b0288f821686ac280c61e3 Mon Sep 17 00:00:00 2001
> >>From: =?UTF-8?q?Pavel=20B=C5=99ezina?=
> >>Date: Wed, 10 Dec 2014 22:37:17 +0100
> >>Subject: [PATCH 02/13] sbus: move iface and object path code to separate
> >>file
> >
> >One nitpick, you changed formatting from:
> >
> >>-static bool sbus_iface_handles_path(struct sbus_interface_p *intf_p,
> >>-const char *path)
> >>-{
> >>-if (sbus_path_has_fallback(intf_p->intf->path)) {
> >>-return sbus_fb_path_has_prefix(path, intf_p->intf->path);
> >>-}
> >>-
> >>-return strcmp(path, intf_p->intf->path) == 0;
> >>-}
> >>-
> >
> >to:
> >
> >>+bool sbus_iface_handles_path(struct sbus_interface_p *intf_p,
> >>+const char *path)
> >>+{
> >>+if (sbus_path_has_fallback(intf_p->intf->path)) {
> >>+return sbus_fb_path_has_prefix(path, intf_p->intf->path);
> >>+}
> >>+
> >>+return strcmp(path, intf_p->intf->path) == 0;
> >>+}
> >
> >Normally I wouldn't care but the latter reads funny to me. Please ignore
> >if the function is modified in later patches, I'm revieweing
> >patch-by-patch now.
>
> This whole function is removed in later patches. I'll see how many conflicts
> it will create.
Nah, don't worry, then.
>
> >>diff --git a/src/responder/ifp/ifp_domains.h
> >>b/src/responder/ifp/ifp_domains.h
> >>index
> >>d6ef1a04d10ee69ea620fb638c8ee358d3fe21f5..d6ed6c73deb47a78775424afa28915b38d358777
> >> 100644
> >>--- a/src/responder/ifp/ifp_domains.h
> >>+++ b/src/responder/ifp/ifp_domains.h
> >>@@ -26,7 +26,7 @@
> >> #include "responder/ifp/ifp_private.h"
> >>
> >> #define INFOPIPE_DOMAIN_PATH_PFX "/org/freedesktop/sssd/infopipe/Domains"
> >>-#define INFOPIPE_DOMAIN_PATH INFOPIPE_DOMAIN_PATH_PFX"*"
> >>+#define INFOPIPE_DOMAIN_PATH INFOPIPE_DOMAIN_PATH_PFX"/*"
> >
> >Does it make sense to have some kind of global suffix #defined ? It's
> >not like Components and Domains will differ in the wildcard, right?
> >
> >Then we can:
> > #define INFOPIPE_DOMAIN_PATH
> > INFOPIPE_DOMAIN_PATH_PFX""IFP_SUBTREE_SUFFIX
> >
> >or similar.
>
> We can do it. I'm touching these constants in my wip patches so I'll do this
> change there, ok?
>
> (I'm unify
Re: [SSSD] [PATCH] MAKE: Don't include autoconf generated file to tarball
On Mon, Jan 19, 2015 at 04:00:09PM +0100, Lukas Slebodnik wrote: > On (19/01/15 15:57), Lukas Slebodnik wrote: > >ehlo, > > > >simple patch is attached. > And one more time with missing patch. > > LS Looks like distcheck passed on all distros: http://sssd-ci.duckdns.org/logs/commit/7a/f1f48529a6d47fa8f37ee58bd67e0eee51450a/623/summary.html so ACK. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] SPEC: Use libnl3 for epel6
On Mon, Jan 19, 2015 at 04:42:15PM +0100, Lukas Slebodnik wrote:
> ehlo,
>
> RHEL/CentoOS 6.6 already contains libnl3.
>
> LS
> From c1ba55900dacc47424348ad7aa57bdaa8b3f7bff Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik
> Date: Mon, 19 Jan 2015 15:58:44 +0100
> Subject: [PATCH] SPEC: Use libnl3 for epel6
>
> RHEL6.6 contains libnl3.
> ---
> contrib/sssd.spec.in | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/contrib/sssd.spec.in b/contrib/sssd.spec.in
> index
> bea68f1bbceac232f4ca019111b6262dca3380eb..37d1b963dc2745a22efb3f93d78e7b505343e132
> 100644
> --- a/contrib/sssd.spec.in
> +++ b/contrib/sssd.spec.in
> @@ -118,11 +118,7 @@ BuildRequires: libcmocka-devel
> BuildRequires: uid_wrapper
> BuildRequires: nss_wrapper
> %endif
> -%if (0%{?fedora} || 0%{?rhel} >= 7)
> BuildRequires: libnl3-devel
> -%else
> -BuildRequires: libnl-devel
> -%endif
> %if (0%{?use_systemd} == 1)
> BuildRequires: systemd-devel
> %endif
> --
> 2.1.0
>
Mock passes with or without the patch. With the patch the requires look
like this:
$ rpm -qp --requires
/var/lib/mock/epel-6-x86_64/result/sssd-common-1.12.90-0.el6.x86_64.rpm | grep
libnl
libnl-3.so.200()(64bit)
libnl-route-3.so.200()(64bit)
Before they were:
$ rpm -qp --requires
/var/lib/mock/epel-6-x86_64/result/sssd-common-1.12.90-0.el6.x86_64.rpm | grep
libnl
libnl.so.1()(64bit)
ACK
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] MAN: amend sss_ssh_authorizedkeys
On Fri, Jan 16, 2015 at 02:35:33PM +0100, Pavel Reichl wrote: > Hello, please see attached simple patch. Thanks! Does this patch look sane, Honza? ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [INI] Patches for the INI configuration modification
On Thu, Jan 15, 2015 at 10:54:39AM -0500, Dmitri Pal wrote: > On 01/02/2015 02:47 PM, Dmitri Pal wrote: > >Hello, > > > >Please find attached patches for the new interface to modify configuration > >files using libini_config. > > > > > > > >___ > >sssd-devel mailing list > >sssd-devel@lists.fedorahosted.org > >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > Any takers? Lukas said he'd take a look on our call on Thursday.. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] sbus: move some general code from ifp to sbus
On Wed, Jan 14, 2015 at 10:49:00PM +0100, Pavel Březina wrote: > On 01/14/2015 04:24 PM, Jakub Hrozek wrote: > >On Wed, Dec 17, 2014 at 10:32:55AM +0100, Pavel Březina wrote: > >>Hi, > >> > >>Patch 0001: > >>Moves few object path functions from IFP to sbus. > >> > >>Patch 0002: > >>Adds a new function that retrieves unescaped object name. > >> > >>Patch 0003: > >>Fixes a potential memory leak. > > > >I'm sorry about the delay in review -- I was about to proceed with > >reviewing these patches, but they don't apply anymore, can you rebase? > > Rebased patches attached. This is the only patch set from the sbus patches > that required rebase. It depends on the first set "sbus: support multiple > interfaces on single object path" ACK to all three on top of the large 9-part patchset. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
