Re: [Koha-devel] koha-zebra-daemon not starting
I've tried to keep this to a minimum, there is a 'conclusion' further down: At 11:47 AM 8/20/2012 -0300, Tomas and Barry wrote:
On Sun, Aug 19, 2012 at 4:36 PM, Paul <paul.a@aandc.org> wrote:
Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) [snip] But neither OPAC nor staff search functions are operational.
The only anomaly that I've found so far is that /etc/init.d/koha-zebra-daemon when run from the command line reports failure at line 73 (and does not create any error logs), but ps aux reports the daemon as running (well, "S+" -- sleep forground.)
Anyone got any thoughts please?
You need to answer what method r u using for install.
Pls see my earlier email [Mon, 20 Aug 2012 09:48:19 -0400]
If using tarball, then you might be running the zebra daemon using de 'koha' user and 'koha' group. Do they exist? If this was the case, then this should create the missing dir:
mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha /var/lock/koha/zebradb/
Yes - tarball, but the dir was already (correctly) there: paul@server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 20 11:33 authorities drwxr-xr-x 2 koha koha 40 Aug 20 11:33 biblios
Also (just in case): chown -R koha:koha /var/log/koha
Again, correctly there: paul@server:/var/log$ ls -l | grep koha drwxr-xr-x 2 koha koha 4096 Aug 19 11:19 koha
Also, every time you run rebuild_zebra.pl you should do it like:
su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x"
What's the '-c'? (I don't think I've ever used this construct) and I don't think there's any difference, but I 'su koha' first, then 'cd usr/share/koha', then KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v and KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x and Barry Cannon wrote:
Shouldn't running "zebrasrv -f /etc/koha/koha-conf.xml" (or whatever your path is) as the index owner give you a good indication of what is going on (it should at least get you pointed in the right direction as it should dump out the error to console)
Interesting !!! or ;=} -- I tried that: koha@server:/$ zebrasrv -f /etc/koha/koha-conf.xml 11:51:06-20/08 [log] zebra_start 2.0.44 419ad759807269fdfa379799a051ed3a551c6541 11:51:06-20/08 [log] config /etc/koha/zebradb/zebra-biblios-dom.cfg 11:51:06-20/08 [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-xml.so [snip more filters for zebra-biblios-dom and zebra-authorities-dom 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/bibliosocket id=1 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/authoritysocket id=2 at which point that terminal just hangs on an ongoing op, but shows that the sockets were not previously opened. So, re-indexing again: for authorities: 25901................................ Records exported: 25933 ==================== REINDEXING zebra ==================== skipping biblios ==================== CLEANING ==================== and for biblios: 37301...........................................................................37401.................... Records exported: 37417 ==================== REINDEXING zebra ==================== 12:04:12-20/08 zebraidx(2841) [warn] Unknown register type: ==================== CLEANING ==================== Which corresponds to the ps aux | grep koha during the re-indexing: koha 2738 0.0 0.1 119084 4212 pts/2 S+ 12:01 0:00 su - koha -c KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2747 73.8 1.4 259028 56272 pts/2 S+ 12:01 2:07 /usr/bin/perl /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2841 96.1 1.6 233556 64240 pts/2 Rl+ 12:04 0:27 zebraidx -c /etc/koha/zebradb/zebra-biblios-dom.cfg -v none,fatal,warn -g marcxml -d biblios update /tmp/q2UPWJgDrk/biblio and now we've got the search in OPAC and staff-admin finding the 37301 biblios. And I still don't know what the "[warn] Unknown register type: " might mean. Some hangover from 3.6.1 to 3.8.3? BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please? Best - Paul
BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records.
if you have problems setting up your cron stuff, use the debian packages the cron stuff works 'automagically' with the debian packages :)
Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please?
Best - Paul
At 05:21 PM 8/21/2012 +1200, Mason James wrote:
BUT ... the incremental cron (shows up in /var/log/syslog as working
every 1 minute), does _NOT_ add new records.
if you have problems setting up your cron stuff, use the debian packages
the cron stuff works 'automagically' with the debian packages :)
Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7 Question to all familiar with Ubuntu installs of Koha: do you use the non gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, whatever)? The reason I'm asking is that there are documented kernel changes. Tnx - Paul.
On 2012-08-22, at 9:32 AM, Paul wrote:
At 05:21 PM 8/21/2012 +1200, Mason James wrote:
BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records.
if you have problems setting up your cron stuff, use the debian packages
the cron stuff works 'automagically' with the debian packages :)
Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7
yup, so just do a package install, and fix your problem
Question to all familiar with Ubuntu installs of Koha: do you use the non gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, whatever)?
never install any gui stuff on a server, unless you need it
At 11:01 AM 8/22/2012 +1200, you wrote:
On 2012-08-22, at 9:32 AM, Paul wrote:
At 05:21 PM 8/21/2012 +1200, Mason James wrote:
BUT ... the incremental cron (shows up in /var/log/syslog as working
every 1 minute), does _NOT_ add new records.
if you have problems setting up your cron stuff, use the debian packages
the cron stuff works 'automagically' with the debian packages :)
Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7
yup, so just do a package install, and fix your problem
O.K. I'll bite: a "package install" of exactly what? Does it cure the problem: "the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records"? For your information -- because you maybe haven't read the whole thread -- I have three instances of Koha running on three totally independent servers, and *only* Koha 3.8.3 shows this anomaly; the other two are fully functional. All servers built by the same person (me) using the same methodology; all servers have same (give|take Koha version and one server with upgraded Ubuntu 11.10 vice 12.04) file structures, permissions, versions of perl, yaz, idzebra, mysql, etc. I'll be really happy to follow your suggestion to "just do a package install" but would respectfully ask you to be a little|much more precise as to exactly what ... Thanks for your interest, Paul
At 05:21 PM 8/21/2012 +1200, Mason James wrote:
BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records.
if you have problems setting up your cron stuff, use the debian packages
the cron stuff works 'automagically' with the debian packages :)
Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7
yup, so just do a package install, and fix your problem
O.K. I'll bite: a "package install" of exactly what?
with the debian packages of *Koha* (what other packages could i possibly mean?) just do an install of Koha, using the 'packages' method, don't use the 'tar-file' method
Does it cure the problem: "the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records"?
yup, thats what i said before the cron stuff works 'automagically' using the debian packages
Greetings, A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards. The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations. GPML, Mark Tompsett
On 22 August 2012 12:06, Mark Tompsett <mtompset@hotmail.com> wrote:
Greetings,
A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards.
The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations.
But really the main advantage is that your next upgrade is apt-get upgrade. Even without the scripts that's still a huge advantage. Also, the packages set up the cron jobs properly and without typos which is suspect is what is wrong here Chris
At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote:
A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards. The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations.
OK -- now I'm totally confused (end of the day, tired) but I got fed up on the last "attempt" at 3.8.3 (same results on a brand new install, wiped the server totally clean), then saw that Chris had announced 3.8.4, so wiped the server again, and it's worse than before [see below] because "apparently???" dpkg / dselect is attempting an i386 package for libxml2, and I end up with 5 modules "required" and four "listed" but not required. Now, I did the koha-3.08.04 via wget and suddenly learn that "package" is different from "tarball". Is the tarball different? or invalid? (see below for the i386 error.) I've been using tyarballs for years (and Koha in particular since 3.4.? through the whole 3.6 series) so do I have to change? With respect, why do I have to learn a different "resulting directory structure locations of things." Will I be able to compare a fully working 3.6.7 with a new 3.8.4? That's a new learning experience, and what are the structural differences? And is "Debian Squeeze" == "Ubuntu 12.04". And I guess I can restore the mysql db *before* installing Koha, but what's the significance? Anyway, until tomorrow, here's waht I got with 2.8.4 on 12.04 (all virgin): $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect then at [I]nstall: Errors were encountered while processing: /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Some errors occurred while unpacking. Packages that were installed will be configured. This may result in duplicate errors or errors caused by missing dependencies. This is OK, only the errors above this message are important. Please fix them and run [I]nstall again Press enter to continue. Errors were encountered while processing: libxslt1-dev:i386 dselect: warning: subprocess installation script returned error exit status 100 Press <enter> to continue. paul@server:/koha-3.08.04$ ./koha_perl_deps.pl -m Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- DBD::SQLite2 0 * 0.33 No Graphics::Magick 0 * 1.3.05 No Lingua::Stem::Snowball 0 * 0.952 Yes Net::Z3950::ZOOM 0 * 1.16 Yes Readonly::XS 0 * 1.02 No Template 0 * 2.22 Yes Template::Plugin::HtmlToText 0 * 0.03 Yes Test::Strict 0 * 0.14 No XML::LibXSLT 0 * 1.59 Yes -------------------------------------------------------------------------------------------- Total modules reported: 9 * Module is missing or requires an upgrade.
On 22 August 2012 12:39, Paul <paul.a@aandc.org> wrote:
At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote:
A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards. The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations.
OK -- now I'm totally confused (end of the day, tired) but I got fed up on the last "attempt" at 3.8.3 (same results on a brand new install, wiped the server totally clean), then saw that Chris had announced 3.8.4, so wiped the server again, and it's worse than before [see below] because "apparently???" dpkg / dselect is attempting an i386 package for libxml2, and I end up with 5 modules "required" and four "listed" but not required.
I think I will bow out of this thread, my attempts at helping seem to only confuse you more. Chris
On 2012-08-22, at 12:39 PM, Paul wrote:
At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote:
A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards. The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations.
OK -- now I'm totally confused (end of the day, tired) but I got fed up on the last "attempt" at 3.8.3 (same results on a brand new install, wiped the server totally clean), then saw that Chris had announced 3.8.4, so wiped the server again, and it's worse than before [see below] because "apparently???" dpkg / dselect is attempting an i386 package for libxml2, and I end up with 5 modules "required" and four "listed" but not required.
Now, I did the koha-3.08.04 via wget and suddenly learn that "package" is different from "tarball". Is the tarball different? or invalid? (see below for the i386 error.) I've been using tyarballs for years (and Koha in particular since 3.4.? through the whole 3.6 series) so do I have to change?
a 'package' is a .deb file, see -> http://en.wikipedia.org/wiki/Deb_(file_format) a 'tar ball' is a tar file , see -> http://en.wikipedia.org/wiki/Tar_(file_format) http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way http://wiki.koha-community.org/wiki/Commands_provided_by_the_Debian_packages
From your output: --- BEGIN SNIPPET ---
Greetings, There are THREE ways to install koha (with respect to Ubuntu): 1) Packages (http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze) 2) Tarball (http://wiki.koha-community.org/wiki/Koha_on_Ubuntu) 3) GIT (http://wiki.koha-community.org/wiki/Version_Control_Using_Git) 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. Don't worry, my first install was tarball. That's why the instructions for the tarball installation have been improved on the wiki. I was trying to be a purist. Don't try to logically map between Ubuntu and Debian. That will only generate more confusion in your mind. You say you are trying to set up 3.8.4, so you need to: $ wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - and $ echo deb http://debian.koha-community.org/koha squeeze main | sudo tee /etc/apt/sources.list.d/koha.list $ sudo apt-get update Why? Because there are perl packages which are not in the default repositories for Ubuntu. --- BEGIN SNIPPET --- $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect --- END SNIPPET --- Yes, this is what INSTALL.Ubuntu has said for the longest time. However, remember that unless someone helps keep the file up to date, you will end up with missing libraries like you have listed. And remember that the main install base for Koha is Debian. This means that other Debian-based OS’s may not have those libraries packaged in the default repositories. paul@server:/koha-3.08.04$ ./koha_perl_deps.pl -m Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- DBD::SQLite2 0 * 0.33 No Graphics::Magick 0 * 1.3.05 No Lingua::Stem::Snowball 0 * 0.952 Yes Net::Z3950::ZOOM 0 * 1.16 Yes Readonly::XS 0 * 1.02 No Template 0 * 2.22 Yes Template::Plugin::HtmlToText 0 * 0.03 Yes Test::Strict 0 * 0.14 No XML::LibXSLT 0 * 1.59 Yes -------------------------------------------------------------------------------------------- Total modules reported: 9 * Module is missing or requires an upgrade. --- END SNIPPET --- I know, for example, that Template::Plugin::HtmlToText does not exist in the default repositories. This leads in the existential question: why not just CPAN them? Yes, you can do that. However, this means you need to keep track of them. This is why installing from packages is better. When the module is updated in the repositories, a sudo apt-get upgrade installs the newer version for you, without you having to think about it. In short, your future upgrades become easier. This is why people suggested packages. Your future updates should go more smoothly. I did add a section to the Ubuntu instructions about doing aptitude searches for the missing libraries. So, perhaps you haven’t looked at the wiki recently: http://wiki.koha-community.org/wiki/Koha_on_Ubuntu#Ubuntu_Packages_for_Perl_... I should probably add something about the wonders of apt-file too, as it doesn’t require as much thinking for looking for the missing pieces. $ sudo apt-get install apt-file ... $ sudo apt-file update ... $ apt-file search Graphics::Magick libgraphics-magick-perl: /usr/share/man/man3/Graphics::Magick.3pm.gz $ apt-file search DBD::SQLite2 libdbd-sqlite2-perl: /usr/share/man/man3/DBD::SQLite2.3pm.gz $ apt-file search Lingua::Stem::Snowball liblingua-stem-snowball-da-perl: /usr/share/man/man3/Lingua::Stem::Snowball::Da.3pm.gz liblingua-stem-snowball-perl: /usr/share/man/man3/Lingua::Stem::Snowball.3pm.gz libsnowball-norwegian-perl: /usr/share/man/man3/Lingua::Stem::Snowball::No.3pm.gz libsnowball-swedish-perl: /usr/share/man/man3/Lingua::Stem::Snowball::Se.3pm.gz $ apt-file search Net::Z3950::ZOOM libnet-z3950-zoom-perl: /usr/share/man/man3/Net::Z3950::ZOOM.3pm.gz $ apt-file search Readonly::XS libreadonly-xs-perl: /usr/share/man/man3/Readonly::XS.3pm.gz $ apt-file search perl5/Template.pm libtemplate-perl: /usr/lib/perl5/Template.pm $ apt-file search Template::Plugin::HtmlToText libtemplate-plugin-htmltotext-perl: /usr/share/man/man3/Template::Plugin::HtmlToText.3pm.gz $ apt-file search Test::Strict libtest-strict-perl: /usr/share/man/man3/Test::Strict.3pm.gz $ apt-file search XML::LibXSLT libxml-libxslt-perl: /usr/share/man/man3/XML::LibXSLT.3pm.gz I put the perl5/Template.pm to save you the hassles of looking for it. Otherwise, it’s a huge long list of possibilities. In fact, here are my command line steps based on my virgin 12.04 install: $ sudo apt-get install libxml-simple-perl libxml-sax-writer-perl libxml-rss-perl libschedule-at-perl libsms-send-perl libpoe-perl libuniversal-require-perl $ sudo apt-get install libxml-dumper-perl libpdf-reuse-barcode-perl libpdf-reuse-perl libpdf-api2-perl libpdf-api2-simple-perl $ sudo apt-get install libpdf-table-perl libnumber-format-perl libnet-server-perl libnet-ldap-perl libmodern-perl-perl libmemoize-memcached-perl libmail-sendmail-perl libmime-lite-perl libmarc-crosswalk-dublincore-perl libmarc-charset-perl liblocale-po-perl liblocale-currency-format-perl liblingua-stem-perl libjson-perl libhttp-oai-perl libhtml-scrubber-perl libgravatar-url-perl libemail-date-perl $ sudo apt-get install libalgorithm-checkdigits-perl libauthen-cas-client-perl libbiblio-endnotestyle-perl libbusiness-isbn-perl libcgi-session-perl libcgi-session-driver-memcached-perl libcgi-session-serialize-yaml-perl libclass-factory-util-perl libdata-ical-perl libdate-calc-perl libdate-manip-perl libdatetime-event-ical-perl libdatetime-format-dateparse-perl libdatetime-format-ical-perl libdatetime-set-perl $ sudo apt-get install libmarc-xml-perl I did not do the dselect step. I then decided to look at the ubuntu.packages file. Hmmmm... my patches in 3.6.7 didn’t make it to master! DOH! Granted, I am running this on a 32-bit VM, so your results may differ from mine.
Will I be able to compare a fully working 3.6.7 with a new 3.8.4?
Yes, but if you do a package install vs. a tarball install the directories you will compare will be different.
That's a new learning experience, and what are the structural differences?
I’ll let someone more familiar with the differences answer that.
And I guess I can restore the mysql db *before* installing Koha, but what's the significance?
BEFORE the webinstall, AFTER the packages install. And only the koha database, not the entire set of DBs. The packages automagically generate a random password for the MySQL database. And your mentioning that i386 packages and breaking things reminds me of this thread: http://koha.1045719.n5.nabble.com/3-8-3-dependencies-td5722667.html Hope this helps somewhat. I can’t spend much more time helping right now. I have a koha machine of my own to configure and set up. GPML, Mark Tompsett
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 You only need gcc and make if you need CPAN to install something that is missing. However, I didn't get anything missing. And speaking of yaz. If you really want to get yaz and zebra from the source, check out: http://ftp.indexdata.dk/pub/yaz/ubuntu/README (change intrepid to the release you have and goodness browse around the site while you're there). You can always add indexdata's repository. Though, it isn't necessary. GPML, Mark Tompsett
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. Again tnx and more later - I'm rushing off to an outside meeting. Best - Paul
You only need gcc and make if you need CPAN to install something that is missing. However, I didn't get anything missing.
And speaking of yaz. If you really want to get yaz and zebra from the source, check out: http://ftp.indexdata.dk/pub/yaz/ubuntu/README (change intrepid to the release you have and goodness browse around the site while you're there). You can always add indexdata's repository. Though, it isn't necessary.
GPML, Mark Tompsett _______________________________________________ Koha-devel mailing list Koha-devel@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>
Greetings, Paul, Just some final details. Because I think there was some instructional misunderstandings... --- SNIP --- $ 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 --- SNIP --- The point was all the libraries you needed are there. I probably typed this in a command line earlier and forgot to include it. I did note that I had some apt-file searches for which I didn’t put a sudo apt-get install command line done. Sorry about that. --- SNIP --- $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect --- SNIP --- Did you grab the ubuntu.packages from 3.6.7 or 3.6.8? That is the correct one. That's why I was noting my patch didn't make it into 3.8.X. I hope to solve this before 3.8.5 comes out. --- SNIP --- 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" --- SNIP --- That isn’t what I said to type: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - and that isn’t what is on the wiki: http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (under the Everyone title)
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.
--- SNIP --- 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." --- SNIP --- I didn’t say Debian, I said debian-based, which includes Ubuntu. I know the packages work, because I have done a packages install, just to understand the three ways of installing. In fact, I think it only installed 3 things from the debian.koha-community.org repository while doing it too. I was pleased by such a low number. Anyways, I’m glad these tips helped point you in the right direction. GPML, Mark Tompsett
At 03:56 AM 8/23/2012 +0800, Mark Tompsett wrote:
--- SNIP --- $ 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 --- SNIP ---
The point was all the libraries you needed are there.
Mark - many thanks, but "are there" takes a bit of a detour. Yes, they're "there", (slight proviso for libtemplate-plugin-htmltotext-perl which needs the koha repository, as it's not available via Debian/Ubuntu standard repositories.) Also pls see my previous remarks if you're using *AMD64* (I think you said you used i386, but could be wrong.)
Did you grab the ubuntu.packages from 3.6.7 or 3.6.8? That is the correct one. That's why I was noting my patch didn't make it into 3.8.X. I hope to solve this before 3.8.5 comes out.
I "grabbed the ubuntu.packages" from koha-3.08.04.tar.gz/koha-3.08.04/install_misc/ubuntu.packages (nothing to do with 3.6.x) which has e.g. in install_misc/ubuntu.packages libyaz3 *NOT* libyaz4. It wouldn't take long to update that file.
[snip] That isnât what I said to type: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add -
the -O- failed miserably (can't remember the details, something about /home/paul/) but at least gave me Robin S's pgp number and I moved on. The workaround in my previous email solved the problem. Now back to 3.8.4 tnx, a+, p.
At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote: ...
Errors were encountered while processing: /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Some errors occurred while unpacking. Packages that were installed will be configured. This may result in duplicate errors or errors caused by missing dependencies. This is OK, only the errors above this message are important. Please fix them and run [I]nstall again Press enter to continue. Errors were encountered while processing:
libxslt1-dev:i386
Paul A wrote * * I had the same problem and the solution was: *sudo apt-get remove libxslt1-dev:i386* Than it worked ok with the dselect ----- Koha version: 3.08.04 - - José Anjos -- View this message in context: http://koha.1045719.n5.nabble.com/koha-zebra-daemon-not-starting-tp5723716p5... Sent from the Koha-devel mailing list archive at Nabble.com.
Greetings,
Question to all familiar with Ubuntu installs of Koha: do you use the non gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, whatever)? The reason I'm asking is that there are documented kernel changes.
$ sudo apt-get install lynx This works well enough with the web install portion of the Koha installation. Why would I want to install anything gui on an Ubuntu server? If some gui-pieces make it in based on the tarball dselect, it happens. I used command-line only to build, install, and configure our Koha 3.6.3 installation from a tarball on Ubuntu 10.04 LTS. We hope to migrate to Koha to Ubuntu 12.04 LTS in the near future. The version of Koha has yet to be determined. Hope this is useful feedback. GPML, Mark Tompsett
participants (6)
-
anjoze -
Archives and Collections Society -
Chris Cormack -
Mark Tompsett -
Mason James -
Paul