Config file merging in SSSD
by Michal Židek
Hi,
I would like to write a patch that will
allow SSSD to use the config file merging
feature from libini. But first I would like
to ask developers for their opinions on how
this should be implemented.
My idea was that it could work like this.
The current /etc/sssd/sssd.conf would work
as usual.
We would add new directory /etc/sssd/conf.d/
and its content would be following:
- README file that informs what the direcotory
is for.
- any number of files ending with .conf extension
that would contain additional configuration for
SSSD. These files would have higher prioriry
than the /etc/sssd/sssd.conf , meaning if
the same option is present in these files
it will override the /etc/sssd/sssd.conf
value.
SSSD would automatically pick up files ending
in .conf from that direcory and use them. In
order to disable the config file, the admin will
have to rename the file ending (for example
.conf.disabled). This way, we do not need to
inspect the snippets for any special options
like 'enable_this_snippet = true' which would
just complicate the processing.
In order for SSSD to load a configuration, all
the config snippets in /etc/sssd/conf.d/ and
/etc/sssd/sssd.conf must in combination
result in valid configuration. If there is an
error in processing one of the config files,
the whole configuration loading will be
unsuccessful and there will be no way to
skip problematic snippets (later we may add
a fallback config, but that is different issue).
Of course sssd will have an cli option to
use alternative directory for snippets (similar
to what we use for config file now).
Could it be implemented this way?
Any comments are welcome.
Michal
8 years
[PATCH] test_ipa_subdom_server: Workaround for slow krb5 + SELinux
by Lukas Slebodnik
ehlo,
There were failures[1] on rhel6 machine with latest packages.
it took me a while to find out which package cuaed it.
Therefore I downgraded rhel machine to vanilla rhel6.7
and I was troubleshooting it on different machine.
The failures of test_ipa_subdom_server are caused by fixing
memory leak in krb5[2]. BTW there is also plan to fix it in rhel7[3]
sh$ time libtool --mode=execute ./test_ipa_subdom_server
enabled/permissive SELinux
real 0m7.976s
user 0m6.680s
sys 0m0.189s
disabled SELinux
real 0m2.111s
user 0m0.071s
sys 0m0.043s
valgrind + enabled/permissive SELinux //but test failed.
real 2m7.310s
user 2m17.080s
sys 0m0.786s
valgrind + disabled SELinux
real 0m5.510s
user 0m3.396s
sys 0m0.309s
Attached patch "emulates" disabled SELinux.
If we do not want to do that for unit test than we need to increase
few timeouts.
diff --git a/src/providers/ipa/ipa_subdomains_server.c b/src/providers/ipa/ipa_subdomains_server.c
index f279efc..7d8b3d3 100644
--- a/src/providers/ipa/ipa_subdomains_server.c
+++ b/src/providers/ipa/ipa_subdomains_server.c
@@ -124,7 +124,7 @@ const char *ipa_trust_dir2str(uint32_t direction)
}
#ifndef IPA_GETKEYTAB_TIMEOUT
-#define IPA_GETKEYTAB_TIMEOUT 15
+#define IPA_GETKEYTAB_TIMEOUT 5
#endif /* IPA_GETKEYTAB_TIMEOUT */
static struct ad_options *
diff --git a/src/tests/cmocka/test_ipa_subdomains_server.c b/src/tests/cmocka/test_ipa_subdomains_server.c
index d1e0945..3c40f04 100644
--- a/src/tests/cmocka/test_ipa_subdomains_server.c
+++ b/src/tests/cmocka/test_ipa_subdomains_server.c
@@ -508,7 +508,7 @@ static void test_ipa_server_trust_init(void **state)
ret = ipa_ad_subdom_init(test_ctx->be_ctx, test_ctx->ipa_ctx);
assert_int_equal(ret, EOK);
- tv = tevent_timeval_current_ofs(15, 0);
+ tv = tevent_timeval_current_ofs(1, 0);
timeout_handler = tevent_add_timer(test_ctx->tctx->ev, test_ctx, tv,
ipa_server_init_done, test_ctx);
assert_non_null(timeout_handler);
@@ -849,7 +849,7 @@ static void test_ipa_server_trust_oneway_init(void **state)
ret = ipa_ad_subdom_init(test_ctx->be_ctx, test_ctx->ipa_ctx);
assert_int_equal(ret, EOK);
- tv = tevent_timeval_current_ofs(15, 0);
+ tv = tevent_timeval_current_ofs(1, 0);
timeout_handler = tevent_add_timer(test_ctx->tctx->ev, test_ctx, tv,
ipa_server_init_done, test_ctx);
assert_non_null(timeout_handler);
Lower values caused intermittent failures.
Here are execution times after changing timeouts.
valgrind + enabled/permissive SELinux
real 3m5.812s
user 2m59.929s
sys 0m1.071s
valgrind + disabled SELinux
real 0m33.541s
user 0m3.392s
sys 0m0.322s
disabled SELinux
real 0m30.134s
user 0m0.069s
sys 0m0.040s
enabled/permissive SELinux
real 0m36.014s
user 0m6.768s
sys 0m0.155s
LS
[1] http://sssd-ci.duckdns.org/logs/job/39/10/summary.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1311287
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1313457
8 years
Design discussion: Use fully-qualified names for users and groups in sysdb
by Jakub Hrozek
Hi,
I prepared a design page for https://fedorahosted.org/sssd/ticket/2011
at:
https://fedorahosted.org/sssd/wiki/DesignDocs/SysdbFullyQualifiedNames
For your convenience, the text is copied below:
= Change format of SYSDB_NAME attribute for users and groups =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2011
=== Problem statement ===
Currently the "name" (SYSDB_NAME) attribute for users and groups can be stored
in different formats depending on domain configuration, in particular the
`full_name_format` option. If the domain does not require fully-qualified
domain names (FQDN), the name in SYSDB_NAME is stored without the domain
portion (for example `joe`). If FQDN is required in the domain, then the
domain portion is stored in the SYSDB_NAME attribute (for example
`joe(a)example.com`). The format in which the FQDN is stored is stored is also
configurable in sssd.conf.
There are two major problems with this approach:
* For admins - The format of data in sysdb is dependent on SSSD
configuration. Changes in sssd.conf may render the cached data invalid, so
admins have to remove the cache. In general, allowing an option that should
purely control the ouput format to also control the database layout is a
very bad idea.
* For code maintainers - The code that deals with SYSDB_NAME attribute
often contains conditions and multiple branches to treat the FQDN/non-FQDN
names differently. This makes the code less readable and more fragile.
In addition, some features such as using only the name part for subdomain users
are very hard to implement with the current code.
=== Use cases ===
As an Administrator, I would like an option to only output the short names of
trusted AD users without the domain component.
As an Administrator, I would like to change the output name format without
having the flush the whole database.
As a code maintainer, I need a predictable way to store user and group entries
without special casing the name formats.
=== Overview of the solution ===
Always store SYSDB_NAME attribute for users and groups in special internal
FQDN format that is not configuration dependent. The options
`use_fully_qualified_names` and `full_name_format` should only be relevant for
code that prepares data for user output. Internally, only the internal FQDN
should be used.
Using a fully qualified name (as opposed to a non-qualified name) for all
users is better to make it possible to use the `memberUid` and `ghost`
attributes in our ldb cache for cases where a group stores members from
multiple domains.
=== Implementation details ===
The new internal FQDN will have the following format: `name@domain`.
The name portion will retain the original case, while the domain portion
will be normalized as lower-case. The SYSDB_ALIAS attribute will have the
same format, but lowercased. The database will not store the shortname
for users and groups at all, but the code would parse the shortname if
needed. This is acceptable because the shortname would only be needed during
interaction with outside of SSSD, such as creating filters or during output.
The name that SSSD receives from the client libraries would be converted
to the internal format when a responder loops over a domain, much like we
normalize the case at the moment. The back end would receive the qualified
name as part of the `be_req` structure already and internally would work
with the qualified name only except places where we need to use the name
portion only (such as when constructing an LDAP filter).
All functions that work with user and/or group names should be modified to accept
this format.
When working on the conversion, care must be taken to not tie the code to any
particular format, but always use functions to create or parse the internal
name. This could be tested by changing the functions to create and parse the format
to create the FQDN in a different format and making sure all tests still pass.
A sysdb version upgrade will be necessary. The changes in sysdb will be following:
* Change the SYSDB_NAME attribute for users and groups to use the new internal format.
* Use the new internal format for SYSDB_GHOST and SYSDB_MEMBERUID attributes.
* The member and memberof attributes will have to be changed to use the
==== sysdb upgrade ====
The sysdb upgrade is tricky for two reasons:
1. the amount of data we'll have to change and write can potentially be
huge if the database contains many users and groups. To mitigate the
performance impact, we will open the database in a nosync mode, perform
all the writes at once and flush when we are done.
2. the memberof plugin normally prevents the ldb user to write the
SYSDB_MEMBERUID, SYSDB_GHOST and SYSDB_MEMBEROF attributes directly.
Because there is no way to selectively disable one module when connecting
to ldb, we will have to add a way to the memberof plugin to allow the user
to bypass the module (maybe when an environment variable is set)
Additionaly, because this update is risky, we should perform the update on a
copy of the database and only rename the copy when the upgrade finishes
successfully. This would allow the admin to downgrade sssd back and still use
the original database in the previous format.
=== Configuration changes ===
No configuration changes required, this is internal change only.
=== How To Test ===
All available tests should still pass. The tests should also pass if the
format of the database was changed.
=== Authors ===
* Jakub Hrozek <jhrozek(a)redhat.com>
* Michal Židek <mzidek(a)redhat.com>
8 years
Multiple PID file macros ?
by Simo Sorce
While looking at the monitor code I realize we define SSSD_PIDFILE_PATH
in monitor.c in a different way than we define SSSD_PIDFILE in
tools_util.h
Although the definitions differ, they end up being effectively the same
string for now.
It seem to me those definition should be merged and harmonized into one.
If not a comment should be put in the code explaining why we have 2
(potentially) different pid file names.
Hints, on which way is right ?
Should we open a ticket on this ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8 years, 1 month