As the add_ulong() convenience can add, replace or remove a unsigned long according to the operation received as its argument, some confusion can easily happen due to its misleading name. In order to improve the explicitness of our code, let's introduce sysdb_add_ulong(), sysdb_replace_ulong() and sysdb_delete_ulong(). These new functions are basically wrappers of add_ulong() (now sysdb_ldb_msg_ulong_helper()), calling it using the proper flag according to each function. Any code previously using add_ulong() is now adapted to use these brand new functions. Related: https://fedorahosted.org/sssd/ticket/1656 Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org> Reviewed-by: Petr Cech <pcech@redhat.com>
As the add_string() convenience can add, replace or delete a string according to the operation received as its argument, some confusion can easily happen due to its misleading name. In order to improve the explicitness of our code, let's introduce sysdb_add_string(), sysdb_replace_string() and sysdb_delete_string(). These new functions are basically wrappers of add_string() (now sysdb_ldb_msg_string_helper()), calling it using the proper flag according to each function. Any code previously using add_string() is now adapted to use these brand new functions. Resolves: https://fedorahosted.org/sssd/ticket/1656 Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org> Reviewed-by: Petr Cech <pcech@redhat.com>
Use a script to update DEBUG* macro invocations, which use literal
numbers for levels, to use bitmask macros instead:
grep -rl --include '*.[hc]' DEBUG . |
while read f; do
mv "$f"{,.orig}
perl -e 'use strict;
use File::Slurp;
my @map=qw"
SSSDBG_FATAL_FAILURE
SSSDBG_CRIT_FAILURE
SSSDBG_OP_FAILURE
SSSDBG_MINOR_FAILURE
SSSDBG_CONF_SETTINGS
SSSDBG_FUNC_DATA
SSSDBG_TRACE_FUNC
SSSDBG_TRACE_LIBS
SSSDBG_TRACE_INTERNAL
SSSDBG_TRACE_ALL
";
my $text=read_file(\*STDIN);
my $repl;
$text=~s/
^
(
.*
\b
(DEBUG|DEBUG_PAM_DATA|DEBUG_GR_MEM)
\s*
\(\s*
)(
[0-9]
)(
\s*,
)
(
\s*
)
(
.*
)
$
/
$repl = $1.$map[$3].$4.$5.$6,
length($repl) <= 80
? $repl
: $1.$map[$3].$4."\n".(" " x length($1)).$6
/xmge;
print $text;
' < "$f.orig" > "$f"
rm "$f.orig"
done
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Stephen Gallagher <sgallagh@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Use a script to update DEBUG macro invocations to use it as a variadic
macro, supplying format string and its arguments directly, instead of
wrapping them in parens.
This script was used to update the code:
grep -rwl --include '*.[hc]' DEBUG . |
while read f; do
mv "$f"{,.orig}
perl -e \
'use strict;
use File::Slurp;
my $text=read_file(\*STDIN);
$text=~s#(\bDEBUG\s*\([^(]+)\((.*?)\)\s*\)\s*;#$1$2);#gs;
print $text;' < "$f.orig" > "$f"
rm "$f.orig"
done
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Stephen Gallagher <sgallagh@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Recent versions of FreeIPA support a range type attribute to allow different type of ranges for sub/trusted-domains. If the attribute is available it will be used, if not the right value is determined with the help of the other idrange attributes. Fixes https://fedorahosted.org/sssd/ticket/1961
https://fedorahosted.org/sssd/ticket/1816 When saving or updating ranges, skip those which are invalid (not provided ipaNTTrustedDomainSID or ipaSecondaryBaseRID, or both provided at the same time)
Storing ranges for multiple domains under any specific domain is somewhat aritrary and unnecessary. Put ranges under cn=ranges,cn=sysdb, without involving any specific domain subtree. This allows us to avoid using sysdb->domain in ranges functions. Also storing other subdomains data under the parent domain tree felt wrong, all other domain specific data is under their own subtree. Moving this data in its own place seems a better solution.
We had 2 defines for the same class. Consolidate and remove confusion.
Make sure the right sub-tree in the cache is used to search for ranges. Sub-domain trees do not have range objects only the tree of the parent domain.