August 2012 - Koha-devel - lists.koha-community.org

Koha 3.8.4 on Ubuntu server 12.04
by Paul 26 Aug '12

26 Aug '12

Koha 3.8.4 on Ubuntu server 12.04 LTS including importing an existing 3.6.1 database. Finally got my trials and tribulations behind me, 3.8.4 up and running (now on to detail, customization and pre-production testing.) A couple of points following previous threads (YMMV, but this worked without a single error for me this morning): 1) Use ubuntu-12.04.1-server-amd64.iso (598,902,661 bytes) which replaces ubuntu-12.04-server-amd64.iso (717,533,184 bytes) -- I'm not certain what the hiccough was, but there have been considerable changes made. This latest ISO, much smaller than the previous one, allowed everything below normally. 2) Add the debian.koha-community.org/koha repository to /etc/apt/sources.list.d/koha.list before looking for dependencies. 3) Before using dpkg, dselect from the Koha .gz, $ sudo apt-get install libtemplate-plugin-htmltotext-perl zip unzip yaz idzebra-2.0 daemon dselect libyaz4 libyaz4-dev libnet-z3950-zoom-perl libxml-libxslt-perl libgraphics-magick-perl liblingua-stem-snowball-perl libtemplate-perl liblingua-ispell-perl libhtml-template-pro-perl libreadonly-xs-perl libtest-strict-perl 4) Koha will try to install (and report "missing/not required") DBD::SQLite2 which as far as I can tell is superceded by libdbd-sqlite3-perl (i.e version 3) which I installed. 'Make test' will report it, but 'make install' is fully functional. 5) After installing and configuring Mysql, Koha and Apache2, doing the following *in this order* allowed clean updating of a db restore, Zebra indexing and zebra incremental cron: a) Verify from a workstation browser: http://koha3 ==> OPAC (will report "under maintenance.") Do NOT YET verify http://koha-admin3 ==> Staff client login b) NOW restore a working copy of a working db: c) http://koha-admin3 ==> Staff client login will go through "upgrade" process d) Setup Zebra daemon at boot e) Reindex Zebra (auths and biblios) f) Set up cron Zebra incremental Thanks to all involved, best regards, Paul

1 0

Koha 3.8.x: Loan for 0 days
by Oscar Gaona 26 Aug '12

26 Aug '12

Hi all I've been configuring a Circulation Rule with Zero (0) days for loans in Koha 3.2, 3.4 and 3.6 without problems ('Checked out on' date and 'Due date' are the same) but for Koha 3.8.x this seems impossible: 'Due date' displays a date 21 days after the 'Cheked out on' date. Where can be the problem? Any idea to solve it? Thanks in advance. Oscar

1 0

3.8.4 installation: order of db install
by Paul 25 Aug '12

25 Aug '12

Does anyone have any thoughts on the order of the following towards the end of installation: 1) Apache2: verify that "koha-admin" responds (empty db) 2) Restore a "dump" from a previous 3.6.x 3) Update the db with ./updatedatabase.pl (is -I needed; seems to fail for me) 4) Reindex zebra (-a , -b) 5) [?? I think it's stopped by a full reindex] start|stop zebra cron -z (incremental) The reason that I ask is that all *my* 3.6.x installs have "updatedatabase"-ed automatically on opening staff-admin; but (so far) all my 3.8.x installs have just got stuck on a staff-admin screen "Maintenance: contact your admin" and I've had to go back and run the .pl so get the staff page to open. Thanks - Paul

1 0

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Paul 25 Aug '12

25 Aug '12

At 06:28 PM 8/25/2012 +0000, Robert Williams wrote: >Paul: > >Sorry, upon further reflection after sending another response, I think >I've debunked my DNS thoughts (my brain's too dead to be thinking :-) ). >They might play a part, but they don't seem to address the fact that one >form submission succeeds in reaching the correct server/database. It'll be >interesting to hear what actually resolves the problem! Robert -- tnx for the input. I have more or less come to the conclusion that the ISO image of the server is corrupt, damaged or in some way deficient (so I'm downloading the latest and will do a fresh install.) As to DNS, it was one of my first thoughts, but: verify IP addresses: paul@server:/$ sudo ifconfig -a eth0 Link encap:Ethernet HWaddr e0:69:95:ec:35:30 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 eth0:1 Link encap:Ethernet HWaddr e0:69:95:ec:35:30 inet addr:192.168.0.95 Bcast:192.168.0.255 Mask:255.255.255.0 paul@server:/$ ping koha PING koha (192.168.0.90) 56(84) bytes of data. 64 bytes from nelson (192.168.0.90): icmp_req=1 ttl=64 time=0.123 ms paul@server:/$ ping koha3 PING koha3 (192.168.0.1) 56(84) bytes of data. 64 bytes from server (192.168.0.1): icmp_req=1 ttl=64 time=0.016 ms paul@server:/$ ping koha-admin PING koha-admin (192.168.0.91) 56(84) bytes of data. 64 bytes from koha-admin (192.168.0.91): icmp_req=1 ttl=64 time=0.114 ms paul@server:/$ ping koha-admin3 PING koha-admin3 (192.168.0.95) 56(84) bytes of data. 64 bytes from koha-admin3 (192.168.0.95): icmp_req=1 ttl=64 time=0.017 ms ======================== Then I thought of envelope variables (apart from the system ones, which are OK), but: koha@server:/$ echo $PERL5LIB /usr/share/koha/lib koha@server:/$ echo $KOHA_CONF /etc/koha/koha-conf.xml ======================== Then I found Bug 8162: have we got the right user, privileges? But that seems OK. mysql> SELECT host,user FROM user; +-----------+------------------+ | host | user | +-----------+------------------+ | 127.0.0.1 | root | | ::1 | root | | localhost | debian-sys-maint | | localhost | koha | | localhost | paul | | localhost | root | | server | root | +-----------+------------------+ 7 rows in set (0.00 sec) mysql> SHOW GRANTS FOR 'koha'@'localhost'; +-------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'koha'@'localhost' IDENTIFIED BY PASSWORD '*0BECD2563417B53867228AE94D7F1A9A1A1CED70' | | GRANT ALL PRIVILEGES ON `koha384`.* TO 'koha'@'localhost' | +-------------------------------------------------------------------------------------------------------------+ 2 rows in set (0.00 sec) mysql> show variables; [snipped] | version 5.5.24-0ubuntu0.12.04.1 | version_comment (Ubuntu) | version_compile_machine x86_64 | version_compile_os debian-linux-gnu ================= I did find one instance of the production server in the dumped|restored db (an added "menu item" in the Admin interface under Staff Client preferences | Appearance | IntranetNav. But even after deleting this, there is no change. I did do a trace from Firefox when saving a "did not work properly" new biblio, but it came back OK: (Request-Line) POST /cgi-bin/koha/cataloguing/addbiblio.pl HTTP/1.1 Host koha-admin3 User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-us,en;q=0.5 Accept-Encoding gzip, deflate Connection keep-alive Referer http://koha-admin3/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&z39… Cookie CGISESSID=2813f39fe44d1410997864e44d54e928; marcdocs_1=true Content-Type application/x-www-form-urlencoded Content-Length 40421 (Status-Line) HTTP/1.1 302 Found Date Sat, 25 Aug 2012 16:30:38 GMT Server Apache/2.2.22 (Ubuntu) Location /cgi-bin/koha/cataloguing/additem.pl?biblionumber=17721&frameworkcode= Content-Length 0 Keep-Alive timeout=5, max=100 Connection Keep-Alive Content-Type text/x-perl redirect=items&confirm_not_duplicate=0&frameworkcode=Default&op=addbiblio&frameworkcode=&biblionumber=0&breedingid=75054&tag_000_indicator1_78277136320=&tag_000_indicator2_78277136320=&tag_000_code_00_78277_970808=00&tag_000_subfield_00_78277_970808=01176cam+a2200313+a+4500&tag_001_indicator1_453413487163=&tag_001_indicator2_453413487163= [snip the rest of 32 kb] >Sorry for the noise. Please don't apologize - any assistance to saving my sanity is appreciated. I'm taking this as a "personal challenge" as I can install Koha 3.4, 3.6.x on 32 and 64 bit machines without any difficulty; but cannot for the life of me get 3.8.3 or 3.8.4 up and running. The devel team give me the impression that it's my end that "needs attention", so I'll try again (the new ISO has just finished downloading ...) Again tnx -- Paul >--Robert >________________________________________ >From: koha-devel-bounces(a)lists.koha-community.org >[koha-devel-bounces(a)lists.koha-community.org] on behalf of Robert Williams >[williams(a)amigos.org] >Sent: Saturday, August 25, 2012 1:09 PM >To: koha-devel(a)lists.koha-community.org >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >Paul: > ><newbie-alert status="I'm still learning!"> > >You wrote: > > >Both servers are on the same LAN, but under different computer names > >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db > >names 'koha' and 'koha384', different URLs 'http://koha' and > >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', > >hosts files all updated, router updated (static, no DHCP). > >I've thought of and rejected several ideas. I'm thinking that, outside of >the "BaseURL" sys pref settings, if it was an entry in the MySQL db or in >a problem with the underlying Koha code, the dump/transfer/reload cycle >would commonly end in problems for everyone. > >So I'm thinking it's likely a system setup thing. It seems to me most >likely to be related to a domain name lookup problem (DNS issue/hosts >issue?). But it possibly could be on the client side rather than the >server side. Since your URLs do not correspond to your machine (host) >names, the client's DNS lookup could be involved. You might try flushing >the Firefox cache, flushing the local OS's DNS cache (ipconfig /flushdns >on Windows clients, run with admin privileges), and then pinging the >koha-admin, koha-admin3 names from the client command line and see what >you get. Or alternatively, just check the local hosts file on the client, >or the DNS server for your local network if implemented, and make sure >there are not errors. > >If you change the Apache configuration to use the IP addresses and port >numbers (and access the sites by the direct IP address temporarily), you >can determine if it's actually a DNS issue or not. > >Don't know that this will be helpful, but it sounds from your message like >something different than what you've already tried. Here's hoping it helps. > ></newbie-alert> > >--Robert > >________________________________________ >From: koha-devel-bounces(a)lists.koha-community.org >[koha-devel-bounces(a)lists.koha-community.org] on behalf of Paul >[paul.a(a)aandc.org] >Sent: Saturday, August 25, 2012 7:30 AM >To: koha-devel(a)lists.koha-community.org >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >[sending again to the LIST - apologies, only went to Robert yesterday] >At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: > >Paul: > > > >I'm wondering if you could have the staffClientBaseURL system preference > >set (not changed after loading the database from the production server)? > >If so, logging in to the staff interface on the test server may be > >"sending" you to the production server? > >Robert, > >Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank >... I filled it in with the test server url, and it's still saving to the >production machine (different url, different db name, ...) > >Best - Paul > > > >--Robert > > > >********************************************* > >Robert L. Williams > >Manager, Open Source ILS Services > >Amigos Library Services, Inc. > >14400 Midway Road > >Dallas, TX 75244-3509 > >800-843-8482, x2870 > >972-340-2870 (direct) > >972-991-6061 (fax) > > > > > >-----Original Message----- > >From: koha-devel-bounces(a)lists.koha-community.org > >[mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul > >Sent: Friday, August 24, 2012 12:38 PM > >To: Koha Devel > >Cc: Koha Devel > >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not > starting] > > > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > > >> paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start > > > >> Starting Zebra Server > > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > > $ sudo apt-get install daemon ? > > > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > > > >my other hunch is that you have bunch of __FOO__ stuff in your > > >/etc/init.d/koha-zebra-daemon file > > > >That had installed perfectly, but thanks, it pushed me into doing a lot > >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on > >AMD64 Ubuntu 12.04 LTS. > > > >However, I have (after asking our staff to try it out), got a very weird > >dilemma: from the new test machine, all NEW records (biblios and items, > >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* > >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly > >to the *TEST* server (3.8.4). > > > >Both servers are on the same LAN, but under different computer names > >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db > >names 'koha' and 'koha384', different URLs 'http://koha' and > >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', > >hosts files all updated, router updated (static, no DHCP). > > > >Similarities are that I restored a mysql dump from production to test and > >therefore users/staff logins/passwords are the same. The test machine is > >saving something: we experimented with entering a new book by an existing > >author; on the "1 tab" when cataloging and checking the "authority" (little > >red box at the end of the 100$a line) it correctly incremented the number > >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a > >subsequent "authority" search only found the 4 again. However, now > >(accidentally) checking the production machine, an "authority" search finds > >all 7 !!! with the associated biblios and items. > > > >Anyone got any thoughts? Is there something is the mysql "restore" that > >points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 > >< /usr/share/koha/koha361dump_1jan12.sql] > > > >I have fairly detailed installation notes if anyone would like them... but > >as I'll probably do another complete reinstall (before upgrading the > >production machine mid-September), I will verify and refine them -- then > >try and assist with the "documentation project." > > > >Thanks - Paul > > > >_______________________________________________ > >Koha-devel mailing list > >Koha-devel(a)lists.koha-community.org > >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >website : http://www.koha-community.org/ > >git : http://git.koha-community.org/ > >bugs : http://bugs.koha-community.org/ > >_______________________________________________ > >Koha-devel mailing list > >Koha-devel(a)lists.koha-community.org > >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >website : http://www.koha-community.org/ > >git : http://git.koha-community.org/ > >bugs : http://bugs.koha-community.org/ > >--- >Maritime heritage and history, preservation and conservation, >research and education through the written word and the arts. ><http://NavalMarineArchive.com> and <http://UltraMarine.ca> > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Paul 25 Aug '12

25 Aug '12

[sending again to the LIST - apologies, only went to Robert yesterday] At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces(a)lists.koha-community.org >[mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 2

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Paul 25 Aug '12

25 Aug '12

At 07:40 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: Tomas, >and besides >that, Koha runs flawlessly for of us on 64 bit servers, runnning on >Ubuntu LTS distro (12.04 and 10.04). > >People just told you how to circumvent those issues. Thanks for the reply -- I'm convinced that everyone is working towards the same goal. But, despite never having had this problem on 3.6.1, 4, 6, 7, I just can't get beyond it on 3.8.3 and 4. It *must* be my mistake (maybe a totally dumb one), but after four installs I'm back to a non-functional zebra. Coming back to my original issue -- 3.8.4 (after another full install) is showing the same error as 3.8.3 -- idzebra-2.0 is fully [??? an 'apt-get idzebra-2.0' comes up with "latest version" and no missing dependencies ???] installed but there's no daemon! So I must have missed something in the repositories/dependences. paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found I am now convinced that somehow, somewhere, zebra is *NOT* properly installed. So before I go any further and screw something up, here's where I'm at as far as Zebra is concerned: /etc/init.d/koha-zebra-daemon has the proper symlink: paul@server:/etc/init.d$ ls -l | grep koha lrwxrwxrwx 1 root root 37 Aug 22 19:11 koha-zebra-daemon -> /usr/share/koha/bin/koha-zebra-ctl.sh and that is the file that has the line 73 that causes the error: daemon --name=$NAME --errlog=$ERRLOG --stdout=$STDOUT --output=$OUTPUT --verbose=1 --respawn --delay=30 $OTHERUSER -- $ZEBRASRV $ZEBRAOPTIONS -f $KOHA_CONF koha-conf.xml has the user as 'koha' with the correct password, and the output belongs to 'koha': paul@server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 22 19:48 authorities drwxr-xr-x 2 koha koha 40 Aug 22 19:48 biblios I guess that I can get back to things tomorrow and try manually installing: idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 libidzebra-2.0-dev libidzebra-2.0-mod-alvis libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text libidzebra-2.0-modules but I would have thought that idzebra-2.0 contained all the necessary dependences, or would have reported anything missing. Best -- P. --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

3 9

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Paul 25 Aug '12

25 Aug '12

A tad of clarification. I had written: >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). From the install log of the production machine (passwords snipped): # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.06.01.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha306 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster@nelson WEBSERVER_DOMAIN=nelson WEBSERVER_HOST=nelson The same from the test machine: # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.08.04.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha384 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster@server WEBSERVER_DOMAIN=server WEBSERVER_HOST=server Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul

1 0

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Paul 25 Aug '12

25 Aug '12

At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces(a)lists.koha-community.org >[mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul@server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user=<me> --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

holds rewrite testing
by Melia Meggs 24 Aug '12

24 Aug '12

Hi, There are two major Holds Rewrite patches that were signed off in July. Because these patches are far-reaching and have the potential to impact a lot of other things in Koha, we really need some help with thorough testing. One of these patches has now passed QA, but I think they could both use some additional sign-offs. Please test! http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5911 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5786 Thanks, Melia -- Melia Meggs Chief Operations Officer ByWater Solutions bywatersolutions.com

1 0

Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]
by Archives and Collections Society 22 Aug '12

22 Aug '12

At 04:41 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: [snip] > > The tarball has always worked extremely well on i386 machines -- I just > get the impression (not proven) that Ubuntu 12.04 gets its knickers in a > twist on AMD64. Â But with a little time and effort workarounds can be > found. Â Probably nothing wrong, just new quirks, with either Ubuntu or > Koha, but I do not need to be under pressure for the production upgrade. > >is not a 12.04 problem, is a problem with the specific file you're using >with dpkg, which lists some files not available anymore on 12.04. >As Mark said that file has already been patched and its waiting for >inclusion on next release. Thanks for the reply. But, as you say, "its waiting for inclusion on next release" so it's broken in this release. >That said, you can do a clean install using the instructions and ommiting >that --set-selections step. And installing the dependencies by hand. As >Mark also said. More or less what I've done -- but it would not be rocket science to edit install_misc/ubuntu.packages to avoid a certain amount of grief (and before anyone asks "well why don't you do it?" I will as soon as I'm certain that my experience is reproducible and bullet-proof. It may involve looking at the upstream .pl file to see how the list is invoked.) >I also use the tarball in our deployment (38 instances on a single BIG >server) without issues. I'm only trying a test install on relatively BIG server (64-bit, 6 core Intel i7-980X, solid state raided drives, 16Gb ram), mileage varies... > Besides that i386 packages pull which I reported and has been solved. When, where, how? I had to 'sudo apt-get purge .*:i386' for about 50 dependencies in the pull in koha-3.08.04.tar.gz >Anyway, I think we should go back to what your original problem was.Â Is >your incremental indexing working? That was 3.8.3, now trashed, but it never worked -- I'll try it on a 3.8.4 install as soon as I'm away from this machine. >Have you properly set your sax parser? [snip] Yes. Best - P.

1 0