On Wed, Sep 20, 2017 at 3:34 AM, Sumit Bose <sb...@redhat.com> wrote:
> $ python
> Python 2.7.12 (default, Sep 29 2016, 12:52:15)
> [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import pysss_nss_idmap
>>>> pysss_nss_idmap.getidbysid('S-1-5-21-3692237560-1981608775-3610128199-1104')
> {'S-1-5-21-3692237560-1981608775-3610128199-1104': {'type': 3, 'id':
> 1367201104}}
>>>>
>
> Please see 'pydoc pysss_nss_idmap' for details.
Ah; thank you! That's very useful.
> On Fedora/RHEL the bindings are in the python[23]-libsss_nss_idmap
> package.
Alas, RHEL7 only has the python2 bindings, because the only officially
supported Python in RHEL7 is 2.7. (Well, there's the python33 package
from the RHSCL, but the RHSCL is enormous pain to use, let alone
package for.)
On Wed, Sep 20, 2017 at 8:25 AM, Lukas Slebodnik <lsleb...@redhat.com> wrote:
> + more examples in integration test
> https://github.com/SSSD/sssd/pull/373/files#diff-b580c91e5e70802720510b5b1a31bf07R205
Also useful; thanks.
Unfortunately, all of these functions appear to cause sssd to query
the backend data provider (Active Directory, in this case) unless the
object being queried is already in the cache. This is true even for
the functions that could simply calculate the answer from the question
(e.g., getidbysid()). As such, using these functions is equivalent to
calling getpwnam()/getgrnam in terms of the amount of load they will
place on the backend.
I think for the time being, I'm going to go with my "cheat" approach,
which is to perform a lookup, calculate the offset, and then use the
offset+RID to synthesize the results sssd would generate. It's not
perfect, but it will avoid crushing our AD infrastructure with a
complete user/group enumeration every hour.
Thanks,
James
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
