Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hello Katrin Thanks for the info. Indeed I was able to solve the staff login problem because in the borrowers table there was a duplicate in the field 'userid' which should not have been. I edited the duplicate userid (same student but with a different student card number). There were also problems with the old field 'privacy' as 128 rows had a value of '2' instead of either '0' or '1'. I did an update sql query to put all those '2' values to '1' and after that upgrading was OK. Instead of using the web interface to do the database upgrade, I followed the advice of (sorry, I forgot the name) of running the upgrade in a terminal (koha-upgrade-schema library) which pointed at the two problems met above. The problem of searching the OPAC (an other post I made) after the upgrade was solved by running in a terminal 'koha-rebuild-zebra -v -f library), which is something that should be done after each upgrade from an older database to a newer version of Koha. Best regards Quynh = M. Vũ Đỗ Quỳnh (Ph.D) Trường Đại học Thăng Long - Université de Thang Long - Thang Long University (Hanoi, Vietnam) Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération internationale - Vice-Rector in charge of International Cooperation Web: http://thanglong.edu.vn/ Vào Th 2, 18 thg 5, 2020 vào lúc 04:31 Katrin Fischer < katrin.fischer...@web.de> đã viết: > Hi, > > misc/batchRebuildBiblioTables.pl has to be run from command line, there > is no option to make this change from the GUI. > > The database user and the superlibrarian accounts are separate things. > If you don't remember the password for the superlibrarian, you can > create another with a different userid/cardnumber and use that to get > back into the system. > > Then you can also use it to reset the password on your old > superlibrarian account or to delete it. > > Hope that helps, > > Katrin > > On 16.05.20 10:19, Quỳnh Vũ Đỗ wrote: > > Hi Jason > > I did it as you instructed to note all the information output to the > > terminal. > > I was able to fix the main errors (two actually) and at the second run, > all > > went rather smoothly and I could display the login window. > > Still some issues to be fixed through library maintenance with some perl > > scripts, which I believe might be the source of the OPAC still not > > returning search results on the catalog. > > For example I had messages like this one: > > Upgrade to 19.06.00.018 done (Bug 11529: Add medium, subtitle and part > > information to biblio table) > > NOTE: misc/batchRebuildBiblioTables.pl should be run to populate the > fields > > introduced in bug 11529. It may take some time for larger databases. > > > > I understand that either I should be able to log in as staff > administrator > > to perform that task OR get into a koha shell to run that script. Is that > > correct? > > > > I am now trying to find how to reset the superlibrarian password to be > able > > to log in to perform that maintenance. > > > ___ > > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hi, misc/batchRebuildBiblioTables.pl has to be run from command line, there is no option to make this change from the GUI. The database user and the superlibrarian accounts are separate things. If you don't remember the password for the superlibrarian, you can create another with a different userid/cardnumber and use that to get back into the system. Then you can also use it to reset the password on your old superlibrarian account or to delete it. Hope that helps, Katrin On 16.05.20 10:19, Quỳnh Vũ Đỗ wrote: Hi Jason I did it as you instructed to note all the information output to the terminal. I was able to fix the main errors (two actually) and at the second run, all went rather smoothly and I could display the login window. Still some issues to be fixed through library maintenance with some perl scripts, which I believe might be the source of the OPAC still not returning search results on the catalog. For example I had messages like this one: Upgrade to 19.06.00.018 done (Bug 11529: Add medium, subtitle and part information to biblio table) NOTE: misc/batchRebuildBiblioTables.pl should be run to populate the fields introduced in bug 11529. It may take some time for larger databases. I understand that either I should be able to log in as staff administrator to perform that task OR get into a koha shell to run that script. Is that correct? I am now trying to find how to reset the superlibrarian password to be able to log in to perform that maintenance. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hi I managed to solve all the problems. After studying the outputs of running in a terminal koha-upgrade schema and editing accordingly the dump sql file of the library, the upgrade from 3.18 to 19.11. was successful. I solved the OPAC search results returning nothing by running in a terminal "koha-rebuild-zebra -v -f library" as found in documentation found on the internet. After that everything looks "normal". The people of our library still have to tell me everything's right. Works now has to be done on the OPAC customization. Again, thanks for all the useful information I gained from this list and its members. Quynh = M. Vũ Đỗ Quỳnh (Ph.D) Trường Đại học Thăng Long - Université de Thang Long - Thang Long University (Hanoi, Vietnam) Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération internationale - Vice-Rector in charge of International Cooperation Web: http://thanglong.edu.vn/ Vào Th 7, 16 thg 5, 2020 vào lúc 15:19 Quỳnh Vũ Đỗ < quyn...@thanglong.edu.vn> đã viết: > Hi Jason > I did it as you instructed to note all the information output to the > terminal. > I was able to fix the main errors (two actually) and at the second run, > all went rather smoothly and I could display the login window. > Still some issues to be fixed through library maintenance with some perl > scripts, which I believe might be the source of the OPAC still not > returning search results on the catalog. > For example I had messages like this one: > Upgrade to 19.06.00.018 done (Bug 11529: Add medium, subtitle and part > information to biblio table) > NOTE: misc/batchRebuildBiblioTables.pl should be run to populate the > fields introduced in bug 11529. It may take some time for larger databases. > > I understand that either I should be able to log in as staff administrator > to perform that task OR get into a koha shell to run that script. Is that > correct? > > I am now trying to find how to reset the superlibrarian password to be > able to log in to perform that maintenance. > > Quynh > = > M. Vũ Đỗ Quỳnh (Ph.D) > Trường Đại học Thăng Long - Université de Thang Long - Thang Long > University (Hanoi, Vietnam) > Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération > internationale - Vice-Rector in charge of International Cooperation > Web: http://thanglong.edu.vn/ > > > Vào Th 6, 15 thg 5, 2020 vào lúc 23:57 Jason Boyer < > jbo...@equinoxinitiative.org> đã viết: > >> Replies inline below >> >> On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ >> wrote: >> >> Hi, >> >> >> Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer < >> jbo...@equinoxinitiative.org> đã viết: >> >>> Hi, this sounds similar to a problem I ran into recently upgrading a >>> 3.20 database to 19.11. You’ll probably have to do the drop/re-import >>> procedure at least 2 more times to fix this, but doing this should help: >>> >>> By this I understand I should try to do incremental drop/re-import, i.e. >> once one drop-reimport cycle is successful, I would mysqldump the >> "upgraded" 19.11 database containing the 3.18 values and then drop again >> the database to reload it with the new dump of the 19.11. Is this >> interpretation of mine correct? >> >> >> Not quite. Because an error early on can cause additional failures later, >> the process I’m referring to is this: >> 1. Load the 3.18 database >> 2. Try to upgrade it to 19.11, and save all of the output >> 3. Drop the 19.11 database >> 4. Load the 3.18 database again >> 5. Fix the issues from the 19.11 upgrade output >> 6. Try to upgrade to 19.11 again, saving the output again just in case >> 7. If there are additional errors at this point, make note of them, then >> go to step 4 and try again, fixing the old issues and these new ones. >> >> When you are able to load the 3.18 database, make a few specific data / >> constraint changes, run the schema upgrade with no errors, then you’re done >> and your database will be in good shape. (This is a great time for a fresh >> backup :-) ) >> >> >> >>> Instead of using the web interface, after re-importing the 3.18 database >>> use koha-upgrade-schema at a terminal and capture the output >>> in whatever way is convenient to refer to later. At some point there will >>> most likely be some kind of error that will cause an update to fail, though >>> the upgrade script will continue on. In my case it was an invalid default >>> value for the created_on timestamp (-00-00 :00) on the >>> virtualshelves table, but it could be any number of things depending on >>> past/present mysql versions and data consistency. >>> >>> Collect all of the errors in the koha-upgrade-schema output and find out >>> how to address them, then re-import the 3.18 db once more and fix them >>> before running koha-upgrade-schema. If you need help solving the problems I >>> believe the output of koha-upgrade-schema is safe to post publicly if you’d >>> like to attach a text file or share a link to a
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hi Jason I did it as you instructed to note all the information output to the terminal. I was able to fix the main errors (two actually) and at the second run, all went rather smoothly and I could display the login window. Still some issues to be fixed through library maintenance with some perl scripts, which I believe might be the source of the OPAC still not returning search results on the catalog. For example I had messages like this one: Upgrade to 19.06.00.018 done (Bug 11529: Add medium, subtitle and part information to biblio table) NOTE: misc/batchRebuildBiblioTables.pl should be run to populate the fields introduced in bug 11529. It may take some time for larger databases. I understand that either I should be able to log in as staff administrator to perform that task OR get into a koha shell to run that script. Is that correct? I am now trying to find how to reset the superlibrarian password to be able to log in to perform that maintenance. Quynh = M. Vũ Đỗ Quỳnh (Ph.D) Trường Đại học Thăng Long - Université de Thang Long - Thang Long University (Hanoi, Vietnam) Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération internationale - Vice-Rector in charge of International Cooperation Web: http://thanglong.edu.vn/ Vào Th 6, 15 thg 5, 2020 vào lúc 23:57 Jason Boyer < jbo...@equinoxinitiative.org> đã viết: > Replies inline below > > On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ > wrote: > > Hi, > > > Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer < > jbo...@equinoxinitiative.org> đã viết: > >> Hi, this sounds similar to a problem I ran into recently upgrading a 3.20 >> database to 19.11. You’ll probably have to do the drop/re-import procedure >> at least 2 more times to fix this, but doing this should help: >> >> By this I understand I should try to do incremental drop/re-import, i.e. > once one drop-reimport cycle is successful, I would mysqldump the > "upgraded" 19.11 database containing the 3.18 values and then drop again > the database to reload it with the new dump of the 19.11. Is this > interpretation of mine correct? > > > Not quite. Because an error early on can cause additional failures later, > the process I’m referring to is this: > 1. Load the 3.18 database > 2. Try to upgrade it to 19.11, and save all of the output > 3. Drop the 19.11 database > 4. Load the 3.18 database again > 5. Fix the issues from the 19.11 upgrade output > 6. Try to upgrade to 19.11 again, saving the output again just in case > 7. If there are additional errors at this point, make note of them, then > go to step 4 and try again, fixing the old issues and these new ones. > > When you are able to load the 3.18 database, make a few specific data / > constraint changes, run the schema upgrade with no errors, then you’re done > and your database will be in good shape. (This is a great time for a fresh > backup :-) ) > > > >> Instead of using the web interface, after re-importing the 3.18 database >> use koha-upgrade-schema at a terminal and capture the output >> in whatever way is convenient to refer to later. At some point there will >> most likely be some kind of error that will cause an update to fail, though >> the upgrade script will continue on. In my case it was an invalid default >> value for the created_on timestamp (-00-00 :00) on the >> virtualshelves table, but it could be any number of things depending on >> past/present mysql versions and data consistency. >> >> Collect all of the errors in the koha-upgrade-schema output and find out >> how to address them, then re-import the 3.18 db once more and fix them >> before running koha-upgrade-schema. If you need help solving the problems I >> believe the output of koha-upgrade-schema is safe to post publicly if you’d >> like to attach a text file or share a link to a paste with the list (but >> you may want to double-check before doing so). >> >> > Do you think that it would be safe enough to fix values leading to fault > by doing phpmyadmin edition directly in tables ? like replacing value > "-00-00" by "NULL" for instance? > > Quynh > > > If you’re more comfortable with phpmyadmin that should be fine. The most > important thing is to make all of the required changes before starting the > schema upgrade. > > Jason > > -- > Jason Boyer > Senior System Administrator > Equinox Open Library Initiative > phone: +1 (877) Open-ILS (673-6457) > email: jbo...@equinoxinitiative.org > web: https://EquinoxInitiative.org/ > > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Replies inline below > On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ wrote: > > Hi, > > > Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer > mailto:jbo...@equinoxinitiative.org>> đã viết: > Hi, this sounds similar to a problem I ran into recently upgrading a 3.20 > database to 19.11. You’ll probably have to do the drop/re-import procedure at > least 2 more times to fix this, but doing this should help: > > By this I understand I should try to do incremental drop/re-import, i.e. once > one drop-reimport cycle is successful, I would mysqldump the "upgraded" 19.11 > database containing the 3.18 values and then drop again the database to > reload it with the new dump of the 19.11. Is this interpretation of mine > correct? Not quite. Because an error early on can cause additional failures later, the process I’m referring to is this: 1. Load the 3.18 database 2. Try to upgrade it to 19.11, and save all of the output 3. Drop the 19.11 database 4. Load the 3.18 database again 5. Fix the issues from the 19.11 upgrade output 6. Try to upgrade to 19.11 again, saving the output again just in case 7. If there are additional errors at this point, make note of them, then go to step 4 and try again, fixing the old issues and these new ones. When you are able to load the 3.18 database, make a few specific data / constraint changes, run the schema upgrade with no errors, then you’re done and your database will be in good shape. (This is a great time for a fresh backup :-) ) > > Instead of using the web interface, after re-importing the 3.18 database use > koha-upgrade-schema at a terminal and capture the output in > whatever way is convenient to refer to later. At some point there will most > likely be some kind of error that will cause an update to fail, though the > upgrade script will continue on. In my case it was an invalid default value > for the created_on timestamp (-00-00 :00) on the virtualshelves > table, but it could be any number of things depending on past/present mysql > versions and data consistency. > > Collect all of the errors in the koha-upgrade-schema output and find out how > to address them, then re-import the 3.18 db once more and fix them before > running koha-upgrade-schema. If you need help solving the problems I believe > the output of koha-upgrade-schema is safe to post publicly if you’d like to > attach a text file or share a link to a paste with the list (but you may want > to double-check before doing so). > > > Do you think that it would be safe enough to fix values leading to fault by > doing phpmyadmin edition directly in tables ? like replacing value > "-00-00" by "NULL" for instance? > > Quynh If you’re more comfortable with phpmyadmin that should be fine. The most important thing is to make all of the required changes before starting the schema upgrade. Jason -- Jason Boyer Senior System Administrator Equinox Open Library Initiative phone: +1 (877) Open-ILS (673-6457) email: jbo...@equinoxinitiative.org web: https://EquinoxInitiative.org/ ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hi, Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer < jbo...@equinoxinitiative.org> đã viết: > Hi, this sounds similar to a problem I ran into recently upgrading a 3.20 > database to 19.11. You’ll probably have to do the drop/re-import procedure > at least 2 more times to fix this, but doing this should help: > > By this I understand I should try to do incremental drop/re-import, i.e. once one drop-reimport cycle is successful, I would mysqldump the "upgraded" 19.11 database containing the 3.18 values and then drop again the database to reload it with the new dump of the 19.11. Is this interpretation of mine correct? > Instead of using the web interface, after re-importing the 3.18 database > use koha-upgrade-schema at a terminal and capture the output > in whatever way is convenient to refer to later. At some point there will > most likely be some kind of error that will cause an update to fail, though > the upgrade script will continue on. In my case it was an invalid default > value for the created_on timestamp (-00-00 :00) on the > virtualshelves table, but it could be any number of things depending on > past/present mysql versions and data consistency. > > Collect all of the errors in the koha-upgrade-schema output and find out > how to address them, then re-import the 3.18 db once more and fix them > before running koha-upgrade-schema. If you need help solving the problems I > believe the output of koha-upgrade-schema is safe to post publicly if you’d > like to attach a text file or share a link to a paste with the list (but > you may want to double-check before doing so). > > Do you think that it would be safe enough to fix values leading to fault by doing phpmyadmin edition directly in tables ? like replacing value "-00-00" by "NULL" for instance? Quynh ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hi, this sounds similar to a problem I ran into recently upgrading a 3.20
database to 19.11. You’ll probably have to do the drop/re-import procedure at
least 2 more times to fix this, but doing this should help:
Instead of using the web interface, after re-importing the 3.18 database use
koha-upgrade-schema at a terminal and capture the output in
whatever way is convenient to refer to later. At some point there will most
likely be some kind of error that will cause an update to fail, though the
upgrade script will continue on. In my case it was an invalid default value for
the created_on timestamp (-00-00 :00) on the virtualshelves table, but
it could be any number of things depending on past/present mysql versions and
data consistency.
Collect all of the errors in the koha-upgrade-schema output and find out how to
address them, then re-import the 3.18 db once more and fix them before running
koha-upgrade-schema. If you need help solving the problems I believe the output
of koha-upgrade-schema is safe to post publicly if you’d like to attach a text
file or share a link to a paste with the list (but you may want to double-check
before doing so).
Jason
--
Jason Boyer
Senior System Administrator
Equinox Open Library Initiative
phone: +1 (877) Open-ILS (673-6457)
email: jbo...@equinoxinitiative.org
web: https://EquinoxInitiative.org/
> On May 15, 2020, at 10:55 AM, Quỳnh Vũ Đỗ wrote:
>
> Hello everyone,
> Our library has been using a Vietnamized version of Koha 3.18 since mid
> 2014, running on Ubuntu server 14.04 LTS. No upgrade of the system has been
> made since and the server had a hardware problem (mainboard) last February.
> In an attempt to restore the Koha 3.18 database (a dump sql file of 1.8
> Gb), I installed Koha 19.11 on an Ubuntu 16.04.6 LTS Desktop with a LAMP
> stack.
>
> After consulting with the mailing list yesterday, I followed the steps that
> were indicated, i.e Drop the 19.11 koha_library database, recreate it empty
> and then import the Koha 3.18 database sql dump file.
> Then I went to the staff login page http://localhost:8080 where I was
> welcomed by the login window for the web installation. I followed all the
> steps with success although at the crucial one (starting upgrading from
> 3.18 to 19.11) I had a Server timeout after 10-15 minutes waiting. I
> repeated the start upgrade procedure and was met again with a server
> Timeout. Then I had to go to work.
>
> At my office, I used the Easykoha Live DVD to install Koha 16.05 along with
> Ubuntu 14.04 LTS on an experimental partition. I then followed the same
> procedure as described a bove to do an upgrade of our Koha 3.18 database
> towards Koha 16.05. This, because the structure between the two database
> versions did not seem too differ too much (only two more tables in the
> 16.05 version). The upgrade from 3.18 to 16.05 was not successful though
> and I had a full web page filled with the errors that were met.
>
> When I came back home, I had the nice surprise to see that the upgrade from
> 3.18 to 19.11 had succeeded as I was welcomed by this message: "Updating
> database structure: Everything went OK. Update Done" and a blue button
> telling "Continue to log in to Koha". After clicking the button, I had a
> display of "Software error" that said:
>
> DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 'me.anonymized'
> in 'field list' at /usr/share/koha/lib/Koha/Objects.pm line 93
>
> The line 93 (in bold below) is part of a subroutine as follows:
>
> sub find {
>my ( $self, @pars ) = @_;
>
>my $object;
>
>unless (!@pars || none { defined($_) } @pars) {
>*my $result = $self->_resultset()->find(@pars);*
>if ($result) {
>$object = $self->object_class()->_new_from_dbic($result);
>}
>}
>
>return $object;
> }
>
> Any hints on how to solve this problem would be greatly appreciated.
>
>
> Thanks for your attention and help.
> Quynh
>
> =
> M. Vũ Đỗ Quỳnh (Ph.D)
> Trường Đại học Thăng Long - Université de Thang Long - Thang Long
> University (Hanoi, Vietnam)
> Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération
> internationale - Vice-Rector in charge of International Cooperation
> Web: http://thanglong.edu.vn/
> ___
>
> Koha mailing list http://koha-community.org
> Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Staff login problems after upgrading from Koha 3.18 to 19.11
Hello everyone,
Our library has been using a Vietnamized version of Koha 3.18 since mid
2014, running on Ubuntu server 14.04 LTS. No upgrade of the system has been
made since and the server had a hardware problem (mainboard) last February.
In an attempt to restore the Koha 3.18 database (a dump sql file of 1.8
Gb), I installed Koha 19.11 on an Ubuntu 16.04.6 LTS Desktop with a LAMP
stack.
After consulting with the mailing list yesterday, I followed the steps that
were indicated, i.e Drop the 19.11 koha_library database, recreate it empty
and then import the Koha 3.18 database sql dump file.
Then I went to the staff login page http://localhost:8080 where I was
welcomed by the login window for the web installation. I followed all the
steps with success although at the crucial one (starting upgrading from
3.18 to 19.11) I had a Server timeout after 10-15 minutes waiting. I
repeated the start upgrade procedure and was met again with a server
Timeout. Then I had to go to work.
At my office, I used the Easykoha Live DVD to install Koha 16.05 along with
Ubuntu 14.04 LTS on an experimental partition. I then followed the same
procedure as described a bove to do an upgrade of our Koha 3.18 database
towards Koha 16.05. This, because the structure between the two database
versions did not seem too differ too much (only two more tables in the
16.05 version). The upgrade from 3.18 to 16.05 was not successful though
and I had a full web page filled with the errors that were met.
When I came back home, I had the nice surprise to see that the upgrade from
3.18 to 19.11 had succeeded as I was welcomed by this message: "Updating
database structure: Everything went OK. Update Done" and a blue button
telling "Continue to log in to Koha". After clicking the button, I had a
display of "Software error" that said:
DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 'me.anonymized'
in 'field list' at /usr/share/koha/lib/Koha/Objects.pm line 93
The line 93 (in bold below) is part of a subroutine as follows:
sub find {
my ( $self, @pars ) = @_;
my $object;
unless (!@pars || none { defined($_) } @pars) {
*my $result = $self->_resultset()->find(@pars);*
if ($result) {
$object = $self->object_class()->_new_from_dbic($result);
}
}
return $object;
}
Any hints on how to solve this problem would be greatly appreciated.
Thanks for your attention and help.
Quynh
=
M. Vũ Đỗ Quỳnh (Ph.D)
Trường Đại học Thăng Long - Université de Thang Long - Thang Long
University (Hanoi, Vietnam)
Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération
internationale - Vice-Rector in charge of International Cooperation
Web: http://thanglong.edu.vn/
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
