sssd.git/src/db/sysdb_ops.c, branch jhrozek_sysdb_fqdn

SYSDB: convert sysdb_group_membership_mod to operate on qualified names

2016-07-06T15:32:58+00:00

This patch infers the member domain from the FQDN to allow the function
to add group members from different domains.

SYSDB: Only update user attributes if needed

2016-06-23T11:47:16+00:00

Resolves:
    https://fedorahosted.org/sssd/ticket/2602

Uses the same logic as previously used for updating group entries to
only update user attributes if the group entry actually changed.

Reviewed-by: Sumit Bose

SYSDB: Refactor sysdb_store_user

2016-06-23T11:47:16+00:00

Splits sysdb_store_user internals to two functions because the original
function either creates a new user or updates an existing one.

Reviewed-by: Sumit Bose

SYSDB: Check if group attributes differ before saving a group

2016-06-23T11:47:16+00:00

Adds a new function sysdb_entry_attrs_diff() used in group saving code.
This function is used to check if the result of updating a group would
result in actually changing the sysdb entry -- often, we would try to
dump the same data to the cache during update. If that's the case, the
update code now only updates the timestamp cache, avoiding costly
writes.

Reviewed-by: Sumit Bose

SYSDB: If modifyTimestamp is the same, only update the TS cache

2016-06-23T11:47:07+00:00

Resolves:
    https://fedorahosted.org/sssd/ticket/2602

If the entry being saved contains the original modifyTimestamp attribute
and the modifyTimestamp attribute is the same as the one we already
saved to the timestamp cache, only the expire timestamps in the
asynchronous timestamp cache will be bumped and the sysdb code will
avoid writes to the main cache completely. If the modifyTimestamp is
either missing or differs, we assume the entry had changed and do a full
write to the main cache.

Also amends the generic sysdb_set_attrs* and similar functions that
their results is also reflected in the timestamps cache.

Reviewed-by: Sumit Bose

SYSDB: Search the timestamp caches in addition to the sysdb cache

2016-06-23T11:40:11+00:00

When a sysdb entry is searched, the sysdb cache is consulted first
for users or groups. If an entry is found in the sysdb cache, the
attributes from the timestamp cache are merged to return the full and
up-to-date set of attributes.

The merging is done with a single BASE search which is a direct lookup
into the underlying key-value database, so it should be relatively fast.
More complex merging is done only for enumeration by filter which is
currently done only via the IFP back end and should be quite
infrequent, so I hope we can justify a more complex merging there.

Reviewed-by: Sumit Bose

SYSDB: Wrap sysdb_store_group in a transaction and split it into smaller functions

2016-06-23T11:40:11+00:00

sysdb_store_group can do several things -- add, rename or update a
group. It's important they are all done in a single transaction (even
though the caller should typically start a transaction of his own).

Also split the sysdb_store_group function into two, one that only stores
a new group and one that changes attributes of an existing group to keep
the flow easy and avoid two labels in a single function.

Reviewed-by: Sumit Bose

sysdb: add sysdb_{add,replace,delete}_ulong()

2016-05-31T11:07:02+00:00

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 

Reviewed-by: Petr Cech

sysdb: move add_ulong() convenience to sysdb.c

2016-05-31T11:06:57+00:00

Considering that sysdb.c is about utilities around our cache and that
sysdb_ops.c is about operations on objects, seems that add_ulong()
could fit better in sysdb.c.

This move is a suggestion from Jakub Hrozek.

Related: https://fedorahosted.org/sssd/ticket/1656

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Petr Cech

sysdb: add sysdb_{add,replace,delete}_string()

2016-05-31T11:06:50+00:00

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 

Reviewed-by: Petr Cech