Salve! A couple of observations: Unfortunately most foundations are built on a corporate model, and corporations are not democratic by nature. I think we can do better than a raw corporate model. I looked at the list of Chris' suggestions, and they looked to have mature projects, like wine, on it.
I really would prefer Koha to be controlled by a democratic foundation instead of a self-perpetuating one. There are risks to democracy, but at least if it stuffs up, it's the whole community's responsibility. Both SFC nor DSpace look undemocratic to me, appointing barons for life to rule over their serf projects.
And how is this behaviour different from the secret invitation only mailing lists we've been hearing about? Is secrecy called for in a tiny project that as far as I would know would never have a burden that would warrant pitch blackness? Business to business talks ought be just that; I fail to see why it's necessary to drag the Koha name into a single business or two. Just as I fail to see why trademarking under a single or couple of corporations is beneficial. It is imperative that this school boy secrecy be ended now or risk perpetuating a good ole boy network. I don't think it's the concentration of power in an individual that's given to harm, bodies such as Congress are equally given to corruption. It's the loss of direction, neutrality, and response to feedback that is the source of the rot.
Anyway, this is all moot: LibLime are working on something and we're waiting to see what they propose.
Why is it that things are more and more often rendered moot by unilateral action taken by LibLime when those actions have not reflected the will of the community? My problem is that they *aren't* proposing things to this list in sunlight. If they have good ideas, wonderful. Folks have offered help on numerous different aspects of the project at different times and have been sluffed off. I'd rather not encourage that model. I'm not saying that LibLime hasn't offered a substantial contribution to the community, and I don't want to belittle their responsibilities, but one corpo should not hold a project hostage. We risk changing the basket from being carried by all to being carried by one. That cedes our fundamental strength. Rather, I think we should start taking formal votes with reasonable announced time frames. Hopefully this will come to pass with feedback being opened on bugzilla or projects like the one that's currently up to allow for voting for Koha con. I'm also not sure why the trademarks are in corporate hands when we have established users groups that are certainly more objective. Cheers, Brooke
I'm also not sure why the trademarks are in corporate hands when we have established users groups that are certainly more objective.
There is no established user group to which it would be appropriate to grant the trademarks. That's why the foundation is being discussed. I'm as impatient as anyone to hear about what Liblime will propose, but I'm happy to have a sympathetic entity holding the trademark in the meantime. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hi
Unfortunately most foundations are built on a corporate model, and corporations are not democratic by nature. I think we can do better than a raw corporate model. I looked at the list of Chris' suggestions, and they looked to have mature projects, like wine, on it.
I really would prefer Koha to be controlled by a democratic foundation instead of a self-perpetuating one. There are risks to democracy, but at least if it stuffs up, it's the whole community's responsibility. Both SFC nor DSpace look undemocratic to me, appointing barons for life to rule over their serf projects.
And how is this behaviour different from the secret invitation only mailing lists we've been hearing about? Erm, I think that is probably overstating things a little. From time to time something crops up that, usually for reasons of privacy or legality, are tricky to talk about on a public list. We've had a "koha-manage" list for years, that has been lucky to be used more than a couple of times.
For example, as part of approving people to go onto the paid for support list, we need to ask for some private info (referee checks etc), so we don't have that kind of thing going to a public list.
Is secrecy called for in a tiny project that as far as I would know would never have a burden that would warrant pitch blackness? Usually not.
Business to business talks ought be just that; I fail to see why it's necessary to drag the Koha name into a single business or two.
Sorry not sure what you mean by this...
Just as I fail to see why trademarking under a single or couple of corporations is beneficial. It is imperative that this > school boy secrecy be ended now or risk perpetuating a good ole boy network.
I don't think it's the concentration of power in an individual that's given to harm, bodies such as Congress are equally given to corruption. It's the loss of direction, neutrality, and response to feedback that is the source of the rot.
Anyway, this is all moot: LibLime are working on something and we're waiting to see what they propose.
Why is it that things are more and more often rendered moot by unilateral action taken by LibLime when those actions have not reflected the will of the community? My problem is that they *aren't* proposing things to this list in sunlight. Without searching back through lists to check that, I'm not sure if it's
Well as a "girl" I'm not sure it's entirely fair to call us an old boy's network :-) A trademark does need to belong to a legal entity, and we haven't had a Koha legal entity for trademarks to belong to that isn't either a vendor or a client (essentially). There is some cost to trademarking (not huge), but the organisations that have felt able to pay that cost, and have felt they have the most to loose if a hostile organisation were to trademark koha instead of a Koha project member, have been vendors. There's nothing particularly "sinister" in that. And I believe in good faith, the companies involved have said they'll be prepared to hand over those trademarks to another Koha legal entity (like a foundation) once it's in place and able to accept/hold them. The alternative is to NOT register the trademarks, which is the case in some jurisdictions, where in the view of the "locals" there is little threat of malicious trademark registration. I suspect that over time if we don't set up a foundation, more and more trademarks may need to be registered by someone, and my preference would be that they are at least by orgs involved in the project, not by competitive library system companies. true or not. The idea of a Koha Software Foundation has been kicking around for a long time, and other ideas have been put forward too, Liblime have decided to take the bull by the horns and actually investigate setting one up.
Rather, I think we should start taking formal votes with reasonable announced time frames. Hopefully this will come to pass with feedback being opened on bugzilla or projects like the one that's currently up to allow for voting for Koha con. I'm not sure what right now we'd be formally voting on WRT a foundation or other entity. I guess we could get proposals from the various "proposers" and vote on which model we favour for further investigation?
I'm also not sure why the trademarks are in corporate hands when we have established users groups that are certainly more objective. I don't think that the user groups are legal entities are they? The registration of trademarks I think possibly predated the user groups as well.
Cheers Rachel -- ----------------------------- Rachel Hamilton-Williams General Manager Katipo Communications Ltd Phone: +64-4-934 1285 Mobile: 021 389 128 E-mail: rachel@katipo.co.nz Web: www.katipo.co.nz
2009/5/18 Rachel Hamilton-Williams <rachel@katipo.co.nz>:
Hi
Unfortunately most foundations are built on a corporate model, and corporations are not democratic by nature. I think we can do better than a raw corporate model. I looked at the list of Chris' suggestions, and they looked to have mature projects, like wine, on it.
I really would prefer Koha to be controlled by a democratic foundation instead of a self-perpetuating one. There are risks to democracy, but at least if it stuffs up, it's the whole community's responsibility. Both SFC nor DSpace look undemocratic to me, appointing barons for life to rule over their serf projects.
And how is this behaviour different from the secret invitation only mailing lists we've been hearing about? Erm, I think that is probably overstating things a little. From time to time something crops up that, usually for reasons of privacy or legality, are tricky to talk about on a public list. We've had a "koha-manage" list for years, that has been lucky to be used more than a couple of times.
For example, as part of approving people to go onto the paid for support list, we need to ask for some private info (referee checks etc), so we don't have that kind of thing going to a public list.
While it is probably overstating it a bit, I can totally understand how that would be the perception. And in recent times there has been discussion on it that would have been much better served on the public lists. I think where legality allows it, discussions should be public. Decisions made that effect the community should be at least minuted if not discussed publicly. My 2 cents anyway Chris
While it is probably overstating it a bit, I can totally understand how that would be the perception. And in recent times there has been discussion on it that would have been much better served on the public lists. I think where legality allows it, discussions should be public. Decisions made that effect the community should be at least minuted if not discussed publicly.
Oh I agree - I just wouldn't want people to think there had been some sort of "secret society" operating for years directing things without anyone knowing. In the last few months we had a couple of things "blow up" that didn't feel right to talk about in a very public (google-able) forum. I suspect because we were already zooming e-mails back and forth - Very much more so than most people would usually want to get on the Koha lists BTW, that got extended out into some topics that could & should have moved public. What we might want though is essentially a public koha-project-meta list so that we don't swamp the main koha list with the volume of mail we get when an issue is "hot", so people who are wanting help aren't totally turned off by us arguing :-) Cheers R
My 2 cents anyway
Chris
-- ----------------------------- Rachel Hamilton-Williams General Manager Katipo Communications Ltd Phone: +64-4-934 1285 Mobile: 021 389 128 E-mail: rachel@katipo.co.nz Web: www.katipo.co.nz
Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
A trademark does need to belong to a legal entity, and we haven't had a Koha legal entity for trademarks to belong to that isn't either a vendor or a client (essentially). There is some cost to trademarking (not huge), but the organisations that have felt able to pay that cost, and have felt they have the most to loose if a hostile organisation were to trademark koha instead of a Koha project member, have been vendors. There's nothing particularly "sinister" in that.
No, the sinister bit was that some trademarks were registered and left for the community to notice. Thanks to the lack of coordination, I believe that at least one registration conflicts with a pre-existing trademark.
And I believe in good faith, the companies involved have said they'll be prepared to hand over those trademarks to another Koha legal entity (like a foundation) once it's in place and able to accept/hold them.
Yes, those are good words and I hope we'll see action soon.
The alternative is to NOT register the trademarks, which is the case in some jurisdictions, where in the view of the "locals" there is little threat of malicious trademark registration. [...]
Also, a few jurisdictions do not require registration of marks.
Rather, I think we should start taking formal votes with reasonable announced time frames. Hopefully this will come to pass with feedback being opened on bugzilla or projects like the one that's currently up to allow for voting for Koha con. I'm not sure what right now we'd be formally voting on WRT a foundation or other entity. I guess we could get proposals from the various "proposers" and vote on which model we favour for further investigation?
OK, I propose we apply to become an associated project of SPI with the following details:- 1. the name of the project is Koha and it is a Free Software LMS; 2. we need asset stewardship and donation management at first; 3. the Kaitiaki (Rachel Hamilton-Williams) is our liaison to SPI and at first, we will select future liaisons by personal and proxy votes of contributors and users listed on koha.org sites at IRC General Meetings. If an international Koha foundation is created, this selection decision may be delegated to it in the same way.
I'm also not sure why the trademarks are in corporate hands when we have established users groups that are certainly more objective. I don't think that the user groups are legal entities are they? The registration of trademarks I think possibly predated the user groups as well.
KohaLA ASBL in France is a legal entity that could own them AFAICT and isn't a vendor or a client. It predates at least the most recent registration. Or we could ask any of the holding foundations to take care of them until another Koha Foundation is up. There seems no need for private individuals or corporations to own them. Regards, -- MJ Ray (slef). LMS developer and supporter for a small, friendly worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
On Wed, May 20, 2009 at 12:01 PM, MJ Ray <mjr@phonecoop.coop> wrote:
I'm also not sure why the trademarks are in corporate hands when we have established users groups that are certainly more objective. I don't think that the user groups are legal entities are they? The registration of trademarks I think possibly predated the user groups as well.
KohaLA ASBL in France is a legal entity that could own them AFAICT and isn't a vendor or a client. It predates at least the most recent registration.
Kohala is a very loose organization. Membership is not defined : anybody can become a voting member, SirsiDynix can become a voting member! Jay Jordan can become a voting member! (not that he would care, but, you know...). The board is not defined : there is not a defined number of members to the board, basically anyone willing to put his/her name forward only needs his/her own voice to be elected. Members of the board are : anyone willing to help out. Kohala was never meant to be a power-yielding entity : it was always meant to be a place for free-wheeling discussions about Koha, nothing more, nothing less. So I don't think Kohala could own the TM, no. Nicolas
Nicolas Morin <nicolas.morin@biblibre.com> wrote: [...]
Kohala is a very loose organization. Membership is not defined : anybody can become a voting member, SirsiDynix can become a voting member! Jay Jordan can become a voting member! [...]
If they're using Koha, that's fine by me. Open membership is good (cooperative principle one: see http://www.software.coop/info/coopdev.html ) I was surprised that there didn't seem to be any activity restriction on voting, or a more robust executive control, but someone else chose the governing documents IIRC.
Kohala was never meant to be a power-yielding entity : it was always meant to be a place for free-wheeling discussions about Koha, nothing more, nothing less.
That is rather different to its governing documents: "Article 2. This object of this association is the development, documentation, protection, promotion and distribution of the free software library management system Koha." http://www.koha-fr.org/node/2 If it was never meant to do those things and it's meant as a powerless talking shop, that label should not have been put on the tin. Let's fix one of them, please?
So I don't think Kohala could own the TM, no.
Surely it *could* own it, but we might disagree on whether it's a better holder than BibLibre or not? Regards, -- MJ Ray (slef). LMS developer and supporter for a small, friendly worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
MJ Ray a écrit :
So I don't think Kohala could own the TM, no.
Surely it *could* own it, but we might disagree on whether it's a better holder than BibLibre or not?
Technically speaking it could, yes, it could. But it would be much much worst than BibLibre trademark ! (and <paranoid mode ON> much easier to harm everybody than BibLibre trademark !<paranoid mode OFF>) So it's definetly BibLibre that is the best holder atm ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hello all, I'm trying to set configure Koha to access my Active Directory LDAP server. I don't get errors when I browse to the catalog, so it seems that the configuration is being accepted, but my borrowers database has not been updated. I tried restarting the server (which should cover restarting apache, as well -- right?). I used the following documentation: http://wiki.koha.org/doku.php?id=en:development:ldap. My configuration is copied below; the ALL-CAPS areas are of course replaced with the relevant data. Any thoughts? I've pasted this into /etc/koha3/koha-conf.xml inside <config>, inside of <yazgfs>: <useldapserver>1</useldapserver> <!-- LDAP SERVER (optional) --> <ldapserver id="LDAP_IPADDRESS" listenref="LDAP_IPADDRESS"> <hostname>LDAP_IPADDRESS</hostname> <base>CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</base> <user>CN=USERNAME,CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</user> <pass>PASSWORD</pass> <replicate>1</replicate> <update>1</update> <mapping> <firstname is="givenName"></firstname> <surname is="sn"></surname> <address is="">ADDRESS</address> <city is="">CITY</city> <zipcode is="">19106</zipcode> <branchcode is="">BRANCHCODE</branchcode> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <categorycode is="">S</categorycode> <email is="">manuscripts@amphilsoc.org</email> <phone is="">215-440-3400</phone> </mapping> </ldapserver> Cheers, Christopher Curry Assistant Technical Librarian / Assistant IT Officer American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299 ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org> *For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org
Christopher -- You seem to be expecting Koha to extract the entire LDAP directory at once. It doesn't. Instead, it updates the user account when they go to login. So you should try to login as one of the users that isn't yet in your Koha DB, or that has outdated info. If you want the mass upload, you should export from LDAP to CSV and use the normal patron import tool. Having some kind of batch LDAP update mode is desirable, but nobody has sponsored or worked on such functionality. -- Joe Atzberger LibLime - Open Source Library Solutions 2009/5/20 Christopher Curry <ccurry@amphilsoc.org>
Hello all,
I'm trying to set configure Koha to access my Active Directory LDAP server. I don't get errors when I browse to the catalog, so it seems that the configuration is being accepted, but my borrowers database has not been updated. I tried restarting the server (which should cover restarting apache, as well -- right?). I used the following documentation: http://wiki.koha.org/doku.php?id=en:development:ldap.
My configuration is copied below; the ALL-CAPS areas are of course replaced with the relevant data.
Any thoughts?
I've pasted this into /etc/koha3/koha-conf.xml inside <config>, inside of <yazgfs>:
<useldapserver>1</useldapserver>
<!-- LDAP SERVER (optional) --> <ldapserver id="LDAP_IPADDRESS" listenref="LDAP_IPADDRESS"> <hostname>LDAP_IPADDRESS</hostname> <base>CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</base>
<user>CN=USERNAME,CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</user> <pass>PASSWORD</pass> <replicate>1</replicate> <update>1</update> <mapping> <firstname is="givenName"></firstname> <surname is="sn"></surname> <address is="">ADDRESS</address> <city is="">CITY</city> <zipcode is="">19106</zipcode> <branchcode is="">BRANCHCODE</branchcode> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <categorycode is="">S</categorycode> <email is="">manuscripts@amphilsoc.org</email> <phone is="">215-440-3400</phone> </mapping> </ldapserver>
Cheers,
Christopher Curry Assistant Technical Librarian / Assistant IT Officer
American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299
ccurry@amphilsoc.org
*For technical support, please use helpdesk@amphilsoc.org* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Joe, Thanks for the quick reply. That's good to know, but something is still not working right because I haven't been able to log in with any of my AD user accounts (whether or not I have an existing borrower in the Koha database with the same username). I get this error in the logs: opac-user.pl: LDAP Auth rejected : invalid password for user '[USERNAME]'. LDAP error #16: LDAP_NO_SUCH_ATTRIBUTE, referer: http://avocado/cgi-bin/koha/opac-user.pl opac-user.pl: # The request referenced an attribute that does not exist, referer: http://avocado/cgi-bin/koha/opac-user.pl Cheers, Christopher Curry Assistant Technical Librarian / Assistant IT Officer American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299 ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org> *For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org Joe Atzberger wrote:
Christopher --
You seem to be expecting Koha to extract the entire LDAP directory at once. It doesn't. Instead, it updates the user account when they go to login. So you should try to login as one of the users that isn't yet in your Koha DB, or that has outdated info. If you want the mass upload, you should export from LDAP to CSV and use the normal patron import tool.
Having some kind of batch LDAP update mode is desirable, but nobody has sponsored or worked on such functionality.
-- Joe Atzberger LibLime - Open Source Library Solutions
2009/5/20 Christopher Curry <ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org>>
Hello all,
I'm trying to set configure Koha to access my Active Directory LDAP server. I don't get errors when I browse to the catalog, so it seems that the configuration is being accepted, but my borrowers database has not been updated. I tried restarting the server (which should cover restarting apache, as well -- right?). I used the following documentation: http://wiki.koha.org/doku.php?id=en:development:ldap.
My configuration is copied below; the ALL-CAPS areas are of course replaced with the relevant data.
Any thoughts?
I've pasted this into /etc/koha3/koha-conf.xml inside <config>, inside of <yazgfs>:
<useldapserver>1</useldapserver>
<!-- LDAP SERVER (optional) --> <ldapserver id="LDAP_IPADDRESS" listenref="LDAP_IPADDRESS"> <hostname>LDAP_IPADDRESS</hostname> <base>CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</base> <user>CN=USERNAME,CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</user> <pass>PASSWORD</pass> <replicate>1</replicate> <update>1</update> <mapping> <firstname is="givenName"></firstname> <surname is="sn"></surname> <address is="">ADDRESS</address> <city is="">CITY</city> <zipcode is="">19106</zipcode> <branchcode is="">BRANCHCODE</branchcode> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <categorycode is="">S</categorycode> <email is="">manuscripts@amphilsoc.org <mailto:manuscripts@amphilsoc.org></email> <phone is="">215-440-3400</phone> </mapping> </ldapserver>
Cheers,
Christopher Curry Assistant Technical Librarian / Assistant IT Officer
American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299
ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org>
*For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha
So, I sorted this out after seeing this post: http://lists.koha.org/pipermail/koha-devel/2008-October/008493.html Active Directory users can log in (and their data in the borrowers table is updated) after replacing " my $cmpmesg = $db->compare( $userldapentry, attr=>'userpassword', value => $password ); if ($cmpmesg->code != 6) { warn "LDAP Auth rejected : invalid password for user '$userid'. " . description($cmpmesg); return 0; } " with " my $user_ldapname = $userldapentry->dn(); my $user_db = Net::LDAP->new( [$prefhost] ); $res = $user_db->bind( $user_ldapname, password => $password ); if ( $res->code ) { $debug and warn "Bind as user failed". description( $res ); return 0; " on line 103 of /usr/share/koha3/lib/C4/Auth_with_ldap.pm After looking at the rest of the thread, I discovered that this bug was reported in the past and a patch was created in Oct 2008: http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2726 According to this record, "This is controlled by the option auth_by_bind, which, if set, causes this code to try binding instead of comparing." http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=494 Unfortunately, it is not clear to me by looking at this record where this option is set. Is this a patch that is bundled with Koha 3.0.1? Or has it not been folded into the base code yet? Is there an easy way to tell whether or not bugs like this have been resolved? I'm all set for now, but if I could configure this in /etc/koha3koha-conf.xml in the future, that'd be good to know. Cheers, Christopher Curry Assistant Technical Librarian / Assistant IT Officer American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299 ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org> *For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org Christopher Curry wrote:
Joe,
Thanks for the quick reply.
That's good to know, but something is still not working right because I haven't been able to log in with any of my AD user accounts (whether or not I have an existing borrower in the Koha database with the same username). I get this error in the logs:
opac-user.pl: LDAP Auth rejected : invalid password for user '[USERNAME]'. LDAP error #16: LDAP_NO_SUCH_ATTRIBUTE, referer: http://avocado/cgi-bin/koha/opac-user.pl opac-user.pl: # The request referenced an attribute that does not exist, referer: http://avocado/cgi-bin/koha/opac-user.pl
Cheers,
Christopher Curry Assistant Technical Librarian / Assistant IT Officer
American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299
ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org>
*For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org
Joe Atzberger wrote:
Christopher --
You seem to be expecting Koha to extract the entire LDAP directory at once. It doesn't. Instead, it updates the user account when they go to login. So you should try to login as one of the users that isn't yet in your Koha DB, or that has outdated info. If you want the mass upload, you should export from LDAP to CSV and use the normal patron import tool.
Having some kind of batch LDAP update mode is desirable, but nobody has sponsored or worked on such functionality.
-- Joe Atzberger LibLime - Open Source Library Solutions
2009/5/20 Christopher Curry <ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org>>
Hello all,
I'm trying to set configure Koha to access my Active Directory LDAP server. I don't get errors when I browse to the catalog, so it seems that the configuration is being accepted, but my borrowers database has not been updated. I tried restarting the server (which should cover restarting apache, as well -- right?). I used the following documentation: http://wiki.koha.org/doku.php?id=en:development:ldap.
My configuration is copied below; the ALL-CAPS areas are of course replaced with the relevant data.
Any thoughts?
I've pasted this into /etc/koha3/koha-conf.xml inside <config>, inside of <yazgfs>:
<useldapserver>1</useldapserver>
<!-- LDAP SERVER (optional) --> <ldapserver id="LDAP_IPADDRESS" listenref="LDAP_IPADDRESS"> <hostname>LDAP_IPADDRESS</hostname> <base>CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</base> <user>CN=USERNAME,CN=USERS_FOLDER_NAME,DC=DOMAIN,DC=TOP_LEVEL_DOMAIN</user> <pass>PASSWORD</pass> <replicate>1</replicate> <update>1</update> <mapping> <firstname is="givenName"></firstname> <surname is="sn"></surname> <address is="">ADDRESS</address> <city is="">CITY</city> <zipcode is="">19106</zipcode> <branchcode is="">BRANCHCODE</branchcode> <userid is="sAMAccountName"></userid> <password is="userPassword"></password> <categorycode is="">S</categorycode> <email is="">manuscripts@amphilsoc.org <mailto:manuscripts@amphilsoc.org></email> <phone is="">215-440-3400</phone> </mapping> </ldapserver>
Cheers,
Christopher Curry Assistant Technical Librarian / Assistant IT Officer
American Philosophical Society 105 South Fifth Street Philadelphia, PA 19106-3386 Tel. (215) 599-4299
ccurry@amphilsoc.org <mailto:ccurry@amphilsoc.org>
*For technical support, please use helpdesk@amphilsoc.org <mailto:helpdesk@amphilsoc.org>* Main Library number: (215)440-3400 APS website: http://www.amphilsoc.org
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi, 2009/5/21 Christopher Curry <ccurry@amphilsoc.org>:
According to this record, "This is controlled by the option auth_by_bind, which, if set, causes this code to try binding instead of comparing." http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=494
Unfortunately, it is not clear to me by looking at this record where this option is set. Is this a patch that is bundled with Koha 3.0.1?
No. It looks like the patch was never submitted to patches@koha.org, and I didn't notice that a new version was attached to the bug. I've now pushed the patch along with an explanation of its usage to HEAD, and at some point Henri can cherry-pick it into the 3.0.x branch. The patch is pretty self-contained, so if you're not running from HEAD, it would be safe for you to cherry-pick and apply that patch. The auth_by_bind option it refers to would be set as an element in the <ldapserver> section koha-conf.xml, e.g., <auth_by_bind>1</auth_by_bind> Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
participants (10)
-
BWS Johnson -
Chris Cormack -
Christopher Curry -
Galen Charlton -
Joe Atzberger -
MJ Ray -
Nicolas Morin -
Owen Leonard -
paul POULAIN -
Rachel Hamilton-Williams