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).
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?
There is also a feature in the sssd.conf file to manipulate the order that the IPA clients will ask specific IPA servers with specific order which I could randomise (say round robin) but I would like to do it as a second experiment
Thanks in advance for reading so far.
Happy New Year
Nikos
########################################3 Zaharioudakis Nikos, RHC{A,DS,E,VA,X,I}, VCP(4,5},VCI, Mentor VCI, Zimbra Instructor https://www.redhat.com/rhtapps/verify/?certId=100-001-262 Public Calendar : https://www.google.com/calendar/embed?src=nzahar%40gmail.com&ctz=Europe/... +30 694 720 40 63 http://zimbra.wikidot.com/zimbra-installations-in-greece
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.
sssd-users@lists.fedorahosted.org