Function ini_config_serialize was declared in the header file ini_configobj.h,
but this header file was not included in implementation module ini_serialize.c
Functions print_config_parsing_errors, print_file_parsing_errors were declared
in the header file ini_config.h, but this header file was not included
in implementation module ini_print.c
Simple patch is attached.
Here is the 4th and I hope the last version of my DEBUG macro refactoring
Changes from the last version:
* Rebase on fresh master (761777f).
* Fix invocations of the updated "debug_fn" function to not assume it
filters by debug level (found by Jakub).
* Add patch to update debug levels in "sss_semanage_error_callback".
* Add patch to update debug level in a "backup_file" invocation.
* Add patch to reflow the new "debug_fn" to make it match coding
conventions better, as per Jakub's request (although I didn't make a
separate function as it doesn't seem to be necessary).
* Re-run both mass update scripts, instead of cherry-picking.
* Remove mentions of old/new debug levels in the patch removing the
conversion function (the last one).
I built and tested the final results with "chmake", but did no other tests.
when testing the AD detection code, I realized that the sdap_id_op
handling in the enumeration code was wrong. It only handled recoverable
errors, but not the offline case or fatal errors.
I think this patch is another reason we should simplify handling of the
I was debugging one case with a downstream customer which turned out to be a
sss_cache bug. For user entries, we only re-set the dataExpireTimestamp,
not the initgrExpireTimestamp. This resulted in id not reporting
accurate initgroups information even after sss_cache was run.
The attached patch also resets initgrExpireTimestamp.
currently we trust the idrange data we get from the IPA server. But it
turned out that some checks are missing on the server
(https://fedorahosted.org/freeipa/ticket/4137) so SSSD should check the
input before saving the data to the cache.
The first two patches make some code which already exists available for
other callers. The third contains the actual functionality.
attached are two more patches for issues I found when testing the POSIX
[PATCH 1/2] AD: Only download domains that are set to enumerate
This is a bug caused by the recent subdomain enumeration patches. The
code always downloaded all domains even if subdomain_enumerate was set
to false. This bug was not easy to spot, because the NSS frontend
filtered the request for subdomain enumeration correctly, "just" the
backend downloaded too much data.
[PATCH 2/2] AD: Remove dead code
As the subject says, just removing some dead code.
When the schema is set to AD and ID mapping is used, there is a one-time
check ran when searching for users to detect the presence of POSIX attributes
in LDAP. If this check fails, the search fails as if no entry was found
and returns a special error code.
If the AD identity lookup finds this error code, the GC is disabled for
the next search.
The sdap_server_opts structure is filled every time a client connects to
a server so the posix check boolean is reset to false again on connecting
to the server.
It might be better to move the check to where the rootDSE is retrieved,
but the check depends on several features that are not known to the code
that retrieves the rootDSE (or the connection code for example) such as what
the attribute mappings are or the authentication method that should be used.
Currently this patch only runs the check when users are requested. It
would be trivial to add the same code (about 70 lines) to the group
request as well.
Additionally, I wonder if the absence of POSIX attributes in GC should
be reported louder. Currently there is just MINOR_FAILURE.
We could go as far as report to syslog when a user or a group from
subdomains is requested and the GC was already disabled, but I wanted to
check with the other developers before implementing this.
Hi, there is a bit of a debate going on over on the samba list, about
using sssd or winbind. It is now being said that sssd should not be used
on a file server because sssd cannot do what winbind can do.
So here are the questions:
Just what are the differences between using sssd and winbind.
Can sssd be used on a fileserver and if not, why not.
Oh, and we are talking about an AD domain here.