Paul,
Just got back after a few days away. Installation all went well (did not install php package, but used php-pear leaving Apache2 as worker) OPAC and staff client both functional from LAN workstations. Restored a working db (3.6.1) to MySQL, Koha "did its thing" updating the db format, OPAC showed a "System Maintenance" placard, I re-indexed biblios and authorities (no problem), checked the cron-job for the incremental zebra indexing (working properly.)
So everything fine except:
MAJOR: OPAC is stuck with the "System Maintenance" page - I've rebooted (same result), so am looking for ideas, please, as to where to start looking. This is _not_ a browser cache problem.
SEMI-MAJOR: The cron /etc/cron.d/koha (exactly as per Wiki, README, etc) only works if owner:group is root:root or root:koha (fails completely if koha:koha). This (because the "user koha" appears in field #6, and without it, it fails) is leading to the zebra incremental running twice:
Jul 28 17:20:01 server2 CRON[2132]: (root) CMD (koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null)
Jul 28 17:20:01 server2 CRON[2135]: (koha) CMD ( $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null)
This leads to another:
SEMI-MAJOR: From Koha dependencies (I think) nullmailer got installed. It is doing a serious job of bloating the mail.log and mail.err (both up to over half a Gig in a couple of hours, because each "double cron" appears to want to email:
Jul 28 17:20:01 server2 CRON[2136]: (koha) MAIL (mailed 1 byte of output; but got status 0x0001, #012)
Is there any way in Koha to turn off this type of mailing? Or should I look for another way of sending these things to /dev/null without logging? (I get the nasty feeling that nullmailer is attempting to recursively retry to send the whole queue *every minute* i.e. whenever another input is detected from the one minute zebra cronjob.