[OPEN-ILS-DEV] LDAP OSRF Synchronization Questions

[Elliot Voris]

I've gone through, and adjusted the script to better suit our environment. I keep getting these errors:

opensrf at evergreen-test:~/tools/patron-load$ ./ldap_osrf_sync --dump-ldap
[WARN:6134:idl.py:166:MainThread:] No field 'owner' in IDL class 'vie'
[WARN:6134:idl.py:166:MainThread:] No field 'item_attr_def' in IDL class 'vie'
[WARN:6134:idl.py:166:MainThread:] No field 'match_set' in IDL class 'vie'
[WARN:6134:idl.py:166:MainThread:] No field 'renewals' in IDL class 'circ'
[WARN:6134:idl.py:166:MainThread:] No field 'renewals' in IDL class 'acirc'
[WARN:6134:idl.py:166:MainThread:] No field 'distribution_formula_entries' in IDL class 'acpl'
[WARN:6134:idl.py:166:MainThread:] No field 'default_fund' in IDL class 'acqpo'
[WARN:6134:idl.py:166:MainThread:] No field 'filter_sets' in IDL class 'cfdi'
opensrf at evergreen-test:~/tools/patron-load$

Does any of that mean anything to you? Here's that section of /usr/local/lib/python2.7/dist-packages/oils/utils/idl.py (evergreen 2.4.1, btw). Any clues there?

    def get_field(self, field_name):
        """Return the specified field from the class"""

        try:
            return self.field_map[field_name]
        except:
            msg = "No field '%s' in IDL class '%s'" % (field_name, self.name)
            osrf.log.log_warn(msg)
            #raise IDLException(msg)


Thanks!



Elliot J. Voris

IT Director

St. Louis Christian College



evoris at slcconline.edu

314.837.6777 x1250

________________________________________
From: open-ils-dev-bounces at list.georgialibraries.org <open-ils-dev-bounces at list.georgialibraries.org> on behalf of Dan Scott <dan at coffeecode.net>
Sent: Wednesday, July 31, 2013 2:41 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] LDAP OSRF Synchronization Questions

Hi Elliot:

On Wed, Jul 31, 2013 at 06:57:25PM +0000, Elliot Voris wrote:
> Hi, all!
>
> I'm very interested in using Dan Scott's script
> (http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=blob;f=tools/patron-load/ldap_osrf_sync;h=cf3c9b8edbffdb4d458baa2d88dcb61a2a7c0ac1;hb=9d1f461152bfc1079bd1647f25ebd872f5dc55f5)
> to load our patron (student/faculty) records from our Active Directory
> domain into Evergreen. I've tried to find as much info as I can, but I
> wasn't able to find much detail about how the script is intended to be
> used. I'm hoping someone here may be able to answer some questions for
> me.

I'm probably the only person who can answer authoritatively, so I'll
give it a go...

>   1.  This probably goes without saying; I need to provide an AD
>   account with read/writ privileges, right?

Yes, if you want to push the generated Evergreen barcode into your LDAP
server, then your AD administrator should be able to limit your
privileges appropriately (so that you can't totally blow things up!).

If you're just using the existing employeeNumber from the LDAP server
and never need to write to the LDAP server, then read-only would be
fine. Our work flow is a bit torturous:

a. General user account gets created in LDAP
b. ldap_osrf_sync checks for recently created LDAP users, if found:
  i. for each new user, create a corresponding Evergreen account
  ii. for each new user, create an Evergreen barcode
  iii. for each new user, update the LDAP server with the Evergreen
       barcode

If you don't need to generate the barcodes, then you can avoid a few
other branches that I created to support barcode-generation in
Evergreen. But you will probably need one branch that adds support for
searching across all user accounts (overriding patron scopes).

>   2.  The script looks like it keeps track of the barcode in LDAP as
>   lulLibraryBarcode, am I reading that right? I've been using the AD
>   attribute employeeNumber to store student ID numbers (barcodes).
>   Will the script be able to check if that attribute is defined in AD
>   and then use it for the barcode in EG?

Yes, you should be able to swap out your local mappings in place of the
ones that were specific to our institutional needs. I could have done a
better job of centralizing the settings so that they were easier to fix
up in one place, but at a certain point getting a working script took
priority over generalization :/

>   3.  Is this script meant to be run as-needed, or is it intended to
>   run at a regular interval (as a cronjob)?

I run it in a cron job every half hour, using the query-date option
along the lines of:

ldap_osrf_sync --query-date `date --date='1 hour ago' +'%Y%m%d%H%M%SZZ'`

(escaped for cron, naturally)

>   4.  For the OSRF_USER information in credentials.py, am I supposed
>   to use the egadmin account? What does OSRF_WORK_OU mean?

You're connecting via OpenSRF to create the Evergreen accounts, so these
are really your Evergreen credentials. The OSRF_WORK_OU is a registered
Evergreen workstation.

>   5.  Is there a syntax to run this (i.e. "./ldap_osrf_sync.py
>   credentials.py"), or do I just run it after creating
>   "credentials.py" where the script can find it?

"./ldap_osrf_sync --help" gives you syntax help; there are lots of ways
of looking up users. I noticed that if credentials.py doesn't exist,
then it errors out with an ugly exception, so I just pushed a revision
that makes it a bit more graceful (by printing the script's doc block
and then exiting).

> I'm sure there are more questions that I've forgotten since starting
> this email, but I wanted to at least get started with it.

"pydoc ldap_osrf_sync" will provide some documentation about the script
as a whole, as well as class / method descriptions.