Dobrica -- The problem here is not with LDAP, but with your conception of its use case. Pick any piece of data you intend to be updated and answer: which source is authoritative? LDAP or Koha DB? You actually want a mix of both. Replication has to entail update, because if you happen to have a different user defined with the same userid, it *must* be overwritten with the LDAP user in order to replicate it. There is no logical escape from this problem unless you can guarantee that no users are added from outside LDAP, and that userids are not editable. Currently Koha has no provisions for such a configuration, so cannot support that implementation. The type of solution you might implement would be to only enable (and import from) LDAP at a defined interval, e.g. nightly, for a list of users that were known to be updated in LDAP. But in that case it is structurally easier to just use exports from LDAP to import in order to get updated. In a fantasy implementation you might like to know the timestamp associated with each field of data in both LDAP and Koha and be able to "merge" the two records based on which is more recent. But that would be a long way off. --Joe 2009/3/16 Dobrica Pavlinusic <dpavlin@rot13.org>
Let me quickly explain our situation: we want to get data from ldap for new users, but allow librarians to edit data in Koha, and preserve this changes.
Logical solution would be to turn replication on, and update off in /etc/koha/koha-conf.xml with something like this:
<replicate>1</replicate> <!-- add new users from LDAP to Koha database --> <update>0</update> <!-- update existing users in Koha database -->
but that doesn't work. I tracked problem to || 1 in Auth_with_ldap.pm which always turn both options on no matter what user specifies in xml file. Attached patch fixes this problem.
We also needed to augment data available in LDAP with data from CSV files generated by other systems, so I wrote ldap rewriter documented in following blog post:
http://blog.rot13.org/2009/03/virtual_ldap_rewrite_or_augment_data_on_the_fl...
It's somewhat specific for our needs, but I hope that it will also be useful to other as food for thought if nothing else.
-- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin <http://www.rot13.org/%7Edpavlin>