this patch contains a fix for https://fedorahosted.org/sssd/ticket/2692.
If uses the SDAP_SASL_AUTHID config option because it already contains
the right NetBIOS name in the AD case.
I basically tested the patch on a host with a long hostname. Without the
patch I see:
[ad_gpo_connect_done] (0x0400): sam_account_name is LONG-HOSTNAME-GPO-TEST$
with the patch it is changed to
[ad_gpo_connect_done] (0x0400): sam_account_name is LONG-HOSTNAME-G$
and gpo's are found and downloaded. It would be nice is someone can do a
regression test on a host with a shorter name as well.
With this patch the only remaining caller for sss_krb5_get_primary() is
in the same source file. Shall it be made static and removed from
the attached patch was confirmed to work, so the code review should be
easy. But because it adds an index to objectSID, which all AD objects
have, there are two catches:
1) How log the upgrade takes
2) How much the database grows
To test, I created an AD instance with 10.000 users and 10.000 groups
(adcli is great for this type of testing btw). Fetched all groups and
users with the old db, then ran the upgrade.
On a VM running on my local laptop (granted, it has an SSD drive), the
upgrade takes 10 seconds. The default systemd startup timeout
(DefaultTimeoutStartSec) seems to be 90 seconds, which sounds OK to me.
The size, though, has nearly doubled. This is backup before upgrade:
[root@adclient ~]# du -sh /root/cache_win.trust.test.ldb
And this is the cache after I upgraded:
[root@adclient ~]# du -sh /var/lib/sss/db/cache_win.trust.test.ldb
Unfortunately, I don't see us having another option than doing the
upgrade. For attributes that are indexed, an index miss means that ldb
is not going to search sequentially, but just return not found -- so
adding indexes for newly added entries is not possible.
I would like to document that for huge databases (tens of thousands of
cached entries), the timeout might need to be raised during the upgrade
and than for deployments whose cache resides in tmpfs, the cache size
Is everyone OK with this?
We have a gathering of Red Hat members of FreeIPA and SSSD teams in
Brno, Czech Republic this week with a lot of design and discussion
meetings. Naturally, we try to lock ourselves down in dungeons without
wifi access and without laptops (not!) to avoid distractions and great
weather of early autumn in Southern Moravia. This has unfortunate effect
of reducing our availability on the mailing lists and IRC channels.
We are apologizing in case you have something urgent to help with and
hope that someone will be able to help as time permits.
Once we re-emerge from the dungeons of Red Hat Brno offices, there
will be wiki updates and blog posts about what is discussed and
reflected on. At least, I have plans to do so on a number of topics.
On a brighter note, FreeIPA 4.2.1 is on its way to Fedora 23
repositories. It is currently pending the acceptance to updates-testing
repository so we most likely miss Fedora 23 beta release but it gives us
chances to test FreeIPA 4.1 to 4.2.1 upgrade path before final Fedora 23
release later this autumn.
Once packages are in the repositories, we'll send a proper announcement
of FreeIPA 4.2.1 release.
/ Alexander Bokovoy
I was working on implementing https://fedorahosted.org/sssd/ticket/2637
and while for most occurences it was quite easy to set domain status
instead of back end status, I hit the sdap_id_op module..
The sdap_id_op operation sets the offline status directly, in a bit of
a hackish way by accessing the be_ctx through sdap_id_ctx. It's not
trivial to change the request to operate on domains, except changing
sdap_id_op_create() to also accept domain as a parameter..but we already
have 37 calls to sdap_id_op_create().
A better way would be to change the whole sdap_id_op request to return an
error code and don't touch the backend status, but that's even more work
-- we need to do that and it's something we need to do in the next weeks
anyway, I just think it's not something that should land in 1.13..
Thoughts? Should I go ahead and change sdap_id_op_create() to accept
domain in 1.13 or do refactor the sdap_id_op for 1.14? I would
personally prefer the latter..
btw my work in progress is here:
I just updated the wiki pages. I removed some duplicated
and outdated info. I hope that the pages are now clearer.
PS: If you need more info, see thread "[SSSD] [WIKI] Contribute and
DevelTips are duplicate".