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

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

Fwd: 3.8.4 interim [was: koha-zebra-daemon not starting]
by Tomas Cohen Arazi 22 Aug '12

22 Aug '12

---------- Forwarded message ---------- From: Tomas Cohen Arazi <tomascohen(a)gmail.com> Date: Wed, Aug 22, 2012 at 4:41 PM Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] To: Paul <paul.a(a)aandc.org> El ago 22, 2012 4:20 p.m., "Paul" <paul.a(a)aandc.org> escribió: > > At 10:04 PM 8/22/2012 +0800, Mark Tompsett wrote: >> >> Greetings, >> >> And having just looked through the 3.8.4 files in /install_misc/ubuntu*.packages, I have realized my patches didn't make it into the 3.8.X stream. I'll have to bug report and do a 3.8.X specific bug patch (they are in 3.6.7)... But that aside. As I was just chatting with tcohen on IRC, he reminded me that yaz3 was the problem. >> >> I actually finished looking at the ubuntu.packages file and installed these: >> $ sudo apt-get install apache2 daemon gettext mysql-server libmysqlclient18 yaz yaz-doc libyaz4 libyaz4-dev idzebra-2.0 idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 >> $ sudo apt-get install 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 >> $ sudo apt-get install libidzebra-2.0-modules libxml2-utils > > > Mark - tnx for your interest (and sorry to read that Chris C. is ducking out of this thread -- tnx for all you do.) I managed to have a quick look at it again this morning, and hope to find another hour before the day is out, but I came to roughly the same conclusion. > > yaz3 must be replaced by yaz4. I ended up reinstalling the server [again] to be certain that everything was clean, and by: > > $ sudo apt-get install libyaz4 > PLUS > libyaz4-dev > libnet-z3950-zoom-perl > libxml-libxslt-perl > libgraphics-magick-perl > liblingua-stem-snowball-perl > libtemplate-perl > libtemplate-plugin-htmltotext-perl > liblingua-ispell-perl > libhtml-template-pro-perl > libreadonly-xs-perl > libtest-strict-perl > > THEN using: > > > $ sudo dpkg --set-selections < install_misc/ubuntu.packages > $ sudo dselect > > you get all the dependencies properly. Starting with dphg + dselect somehow *half* installs about 50 i386 bits and pieces, and while > > $sudo apt-get purge .*:i386 > > cleaned up quite nicely, I did a complete 12.04 re-install to make sure everything was copacetic. > > I did need to add the koha repository to get one file [template::htmltotext] as this is not an Ubuntu|Debian file, but is recorded after install as "koha". FYI, getting Robin's pgp required a couple of steps that you did not mention. Using: > > $ wget http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - > > gives the error "GPG error: http://archive.ubuntu.com dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 14D36485A99CEB6D" > > To correct this: > $ gpg --recv-keys 14D36485A99CEB6D > > And then add it to apt-keys: > $ gpg --export --armor 14D36485A99CEB6D | sudo apt-key add - > > works fine. > > BTW, you wrote earlier: > > >> Which way should you do? >> Are you going to develop, submit patches, etc for a non-production system? If yes, then (3) GIT! >> Are you using a debian-based OS? If yes, then (1) Packages! >> For everything else, there is (2) Tarball. > > > While I'd love to have time to "submit patches", I juts seem to spend too much time maintaining a production system. I do not use a pure Debian system, but Ubuntu for all our servers and workstations. Hence your "For everything else, there is tarball." My current aim is to get the production server onto 3.8.x from 3.6.x, but need to document (internally here) how to do this cleanly. > > 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. 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. I also use the tarball in our deployment (38 instances on a single BIG server) without issues. Besides that i386 packages pull which I reported and has been solved. Anyway, I think we should go back to what your original problem was. Is your incremental indexing working? Have you properly set your sax parser? (I'm an experienced Koha user and forgot to check that step last time, having weird behavior) Regards To+

1 0

Officially supported OS versions
by Ian Walls 22 Aug '12

22 Aug '12

Koha Developers, As I try to get back in the swing of things after a long absence, I'm finding a lot of changes to Koha's dependencies to be particularly frustrating, as I need to add new package repositories or even upgrade my OS. This leads me to the question: What OS versions does Koha run on? This is both a descriptive question (what's true now) as well as a prescriptive one (what systems SHOULD Koha run on). I should think that Debian 6+ is a given. Any current Ubuntu LTS may also be appropriate, though the current situation has me unable to install a dependency on 10.04. In the past, I know that RedHat installs have been particularly vicious, and may not even be possible at this time. Having a list of supported OS versions would simplify the lives of the QA team, because we would only need to test those systems that we've agreed to support. If someone can get Koha working on another OS, more power to them, but I think it's reasonable for people with moderate technical skills to be able to get Koha up and running on recommended systems without too many steps. One implication of this would be that patches introducing dependencies not easily available on a supported system would be rejected or deferred until such time as they were easily available. So, for example, if a patch introduced a dependency that's packaged for Debian Wheezy, but not for Squeeze, it would not be added to Koha until Wheezy was released. Thoughts, ideas, concerns, questions? -Ian

9 10