| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|