[Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting]

[Paul]

At 10:45 AM 8/27/2012 +0200, Robin Sheat wrote:
>Op 25-08-12 03:22, Paul schreef:
> > 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).

Robin - thanks.  It's all a bit moot now as the test server has been 
successfully (and totally) rebuilt (using the new " .1 " version of the 
ISO, see my email to this list yesterday Sun, 26 Aug 2012 12:39:27 -0400), but:

>Can you confirm that you are checking both search results and details?

['are' ==> 'was'] yes

>I'm wondering if both instances are pointing to the same zebra server.

This was not a case of sebra|search, the records were being *saved* to a 
differently named mysql/innodb on a differently IP'd machine. After saving 
a new Z39.50 biblio on the test server and shutting it down, the new record 
was on the production server and found by the zebra on the production 
server. I'm pretty certain from all my notes that both servers had separate 
zebra servers indexing separate sql db's.

I even went as far as shutdown -h of the production server; 3.8.4 on the 
test server still appeared (i.e. no errors) to save new records, but they 
went nowhere -- and could not be found by either zebra server on either the 
production (after restarting) or the test box.

While it's quite possible I screwed something up, the new LTS distro has 
made a number of fundamental changes concerning 'cloud' networking 
(OpenStack, MAAS, Keystone) which just possibly could have had some impact 
on our LAN (I have no proof of this, and our static IP LAN seems perfect 
after numerous "every-which-way" verifications.) Also, the older distro had 
a few ugly points in handling i386 modules if it couldn't find AMD64, but 
again, I could find no reason for this to account for my dilemma.

Again thanks and br,
Paul