[sssd PR#413][opened] mmap_cache: add SID and type to struct sss_mc_rec
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/413
Author: sumit-bose
Title: #413: mmap_cache: add SID and type to struct sss_mc_rec
Action: opened
PR body:
"""
This patchset updates the memory cache by adding some new members to struct
sss_mc_rec. One is the addition of a hash value for SID based lookup which will
be added in later patches.
The other is a new record type and a member indicating the type. The new type
is a link record which links an alias name, e.g. an UPN, to the original record
of the related user or group object.
Besides aliases this link record will be used in case in-sensitive setups. E.g.
if getpwnam() returns the name of an AD users as Administrator(a)ad.domain bit
some applications or users use administrator(a)ad.domain for lookups the memory
cache is currently never used because there is no entry with the hash of
'administrator(a)ad.domain'. With this patch the original data record is created
as before with the hash for 'Administrator(a)ad.domain' and a link record is
create with the hash of 'administrator(a)ad.domain'. Now both lookups can be
handled by the memory cache. If now another application uses
ADMINISTRATOR(a)AD.DOMAIN for lookups the first request will go to the NSS
responder but upcoming requests can use the memory cache as well because a link
record for ADMINISTRATOR(a)AD.DOMAIN is created.
The last patch in this series adds some additional data to the user and group
lookup requests, the short name, the domain name, the short domain name and the
SID. Those are needed to be able to support SID based lookups in the memory
cache and allow applications to not depend on the name format returned by
getpw{nam|uid}. Upcoming patches for libsss_nss_idmap will make those
additional values available to applications I added them already here to keep
the memory cache related changes in one PR. Application which will benefit here
are the interfaces SSSD provides e.g. to Samba related applications like SSSD's
version of libwbclient but also IPA plugins like extdom and slapi-nis.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/413/head:pr413
git checkout pr413
5 years, 6 months
[sssd PR#611][opened] Do not build the local provider by default
by fidencio
URL: https://github.com/SSSD/sssd/pull/611
Author: fidencio
Title: #611: Do not build the local provider by default
Action: opened
PR body:
"""
Folks,
This series is the first attempt to avoid building the local provider by default. With we only build it conditionally and the default is set to not build it. The problems:
- integration tests depend on the local provider: For this, I've changed our configure line, specifying to enable the local provider;
- some unit tests depend on local provider: I've changed some tests (please, take a careful look at those in order to be sure I'm not invalidating the tests) and worked them around so they're still valid with both scenarios (building or not building the local provider);
My **personal** preference would be to start using the **files** provider in our tests instead of using the "local" one. However, I've faced some issues related to the amount of users being find in some sysdb tests (ping me, we can discuss this either here or in the #sssd channel) (maybe because it also finds the local users/groups created on my machine?).
Again, this is a first attempt, let's discuss improvements needed :-)
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/611/head:pr611
git checkout pr611
5 years, 8 months
[sssd PR#601][opened] sbus: integrate sssd with sbus2
by pbrezina
URL: https://github.com/SSSD/sssd/pull/601
Author: pbrezina
Title: #601: sbus: integrate sssd with sbus2
Action: opened
PR body:
"""
Hi folks,
this is a really large patch set and I have now idea how to review it.
I know that Jakub tried to review the proof of concept, but he have not
managed to finish it so far. It is not in human power to review it all
so hard testing should be done.
I consider the code itself and the integration with sssd finished. I will
push only bug fixes and review issues now. This first version does not
run through make check so far because some tests needs to be altered,
this however does not prevent manual testing and reviewing.
I tried to make the changes small at first while running old and new sbus
in parallel, but it was too hard as the changes were too much interconnected.
Therefore each patch modifies one area, but completely and sssd will not build.
There are new libraries, each in pair. Each pair consist of asynchronous
(used inside sssd) and synchronous (used inside tools; sssctl) versions of API.
- libsss_sbus, libsss_sbus_sync: sbus interface
- libsss_iface, libsss_iface_sync: internal sssd interface, used for internal communication
- libifp_iface, libifp_iface_sync: infopipe interface
At this point, changes are mostly one to one. We still have separate server for monitor and
backends. We still do not use signals, even though it is possible. I will file separate
tickets with ideas how to improve our api further and we can work together after
this patch set is tested and merged.
I did my best with manual testing but I doubt I run all the scenarious. Especially, I want
to ask @sbose to test ifp smartcard API and @fidencio to test Fleet Commander integration
(the one dbus call in ipa code).
Thank you.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/601/head:pr601
git checkout pr601
5 years, 8 months