On Thu, Jan 03, 2019 at 10:01:47AM +0200, Nikos Zaharioudakis wrote:
Good morning list,
I have an idea, which I would like to experiment with, but experts
advise may save me lots of time.
The scenario I have in mind is like this:
(assume OS and vers are latest RHEL/Centos)
I join a client to an IPA server. After joining, in the
/var/lib/sss/db/ directory, a database per domain is expected. (or
perhaps populated after the first request to the IPA server for
example id some-username)
Now the question is:
If I stop the sssd client service, may I copy the content of this
directory to another client (which is already registered as well to
the same IPA server) and save some time from the initial database
population?
You may say that this operation is not time-consuming etc, but in my
case, I have to spin up some thousands of machines as fast as possible
which are practically diskless. Meaning that the whole party has to
happen as fast as possible and at the end, I have a ddos attack
against my IPA servers and their replicas with a boom of (let's say)
3K clients asking more or less the same things (mostly ldap
verification queries).
This is an interesting use-case we've seen a couple of times in diskless
clusters. We've also pondered the idea of 'priming' the cache, but AFAIK
so far nobody did this
So a first question to address my situation would be: Is the sssd db
unique per client or may I "transplant" it to other clients as well?
Some parts of the database are unique to the client, especially in IPA
or AD cases, some can be copied.
If you install the ldb-tools package (in RHEL this is AFAIK in the
Optional channel), then you can inspect the cache with:
ldbsearch -H /var/lib/sss/db/cache_XXX
and:
ldbsearch -H /var/lib/sss/db/timestamps_XXXX
You'll see containers for users, groups, but also HBAC rules, ID
overrides and other data.
If you don't use ID overrides, then I guess it might be possible to
extract the user and group objects from the cache using ldbsearch and
add them to a 'new' cache with ldbadd/ldbmodify before starting the
node. It might be a good idea to also add the timestamps from the
timestamp cache to save the initial disk write. On the other hand, you
should not copy the whole cache as you might also copy HBAC rules meant
for another client. In theory this /should/ be OK as the HBAC rules are
refreshed on every access attempt (with a small timeout), but in case
the access was attempted offline, you could have run into the situation
where the cached rules meant for another client are evaluated.
btw the reason the timestamps are stored in a separate ldb file is that
the timestamp ldb file is opened in async mode, meaning a write does not
cause an fsync and the cache writes are buffered by the OS. This means
the cache writes are much faster, but in the odd case sssd crashed
before the buffers were flushed, the database might be inconsistent. So
we only use this fast mode for attributes that change often, like
timestamps, that change on every db write.
I think this is an interesting experiment, please let us know how it
goes.