zebra on Koha dev install

[Christopher Curry-2]

I overheard somewhere (though I can't remember the details) that using the dev install mode makes it easier to upgrade koha.  I've never done a koha upgrade; we're not fully migrated yet, but I'd like to facilitate future upgrades as much as possible.

I've had no problem setting up a koha standard install; when I try a dev install, my zebra server won't run.  The server reports on boot up (and when I manually start Zebra) that it is starting the Zebra Daemon and Zebra Server, but when I look for the process (top -c), it's not there.  No error messages are generated when starting the server.

Is there something special that must be done with Zebra conf on a dev install?

Can someone explain the advantages of a dev install?  I understand that it allows you to run the majority of the koha server files directly from a git clone.  I see how this could simplify an upgrade, but are there other advantages that will encourage me to get to the bottom of this?

Thanks for your time.


_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Joe Atzberger]

2009/11/24 Christopher Curry <ccurry@...>

I overheard somewhere (though I can't remember the details) that using the dev install mode makes it easier to upgrade koha.  I've never done a koha upgrade; we're not fully migrated yet, but I'd like to facilitate future upgrades as much as possible.

I've had no problem setting up a koha standard install; when I try a dev install, my zebra server won't run.  The server reports on boot up (and when I manually start Zebra) that it is starting the Zebra Daemon and Zebra Server, but when I look for the process (top -c), it's not there.  No error messages are generated when starting the server.

Is there something special that must be done with Zebra conf on a dev install?

Can someone explain the advantages of a dev install?  I understand that it allows you to run the majority of the koha server files directly from a git clone.  I see how this could simplify an upgrade, but are there other advantages that will encourage me to get to the bottom of this?

No that's basically it.  It keeps everything (configs and code) in one directory, and lets you use git so you have version control over the working branch modifications that you are running on.  Then you can pull in new changes from mainline and integrate them as you see fit, switching between branches at will without modifying apache or KOHA_CONF or anything.

For a developer, it is very important to submit patches that are against the current state of the codebase.  Therefore we have to keep a reference mainline version current, and generating patches between that and a dev branch is how a submission is made. Git manages all that in a really coherent way, so you don't have to be constantly managing symlinks.

BTW, you might have a problem if the dev install was the second installation on the system to use the same config values (i.e. default port numbers).  That would be true for any additional install.  Otherwise, check your zebra logs for reasons zebra might be failing.

--joe

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Joe Atzberger]

I think the zebra logs are not in the same directory as the apache logs.  Fowarding to the list in case somebody else knows for sure.

--Joe

On Tue, Nov 24, 2009 at 4:42 PM, Christopher Curry <ccurry@...> wrote:

Thanks for the quick response, Joe.  I looked at the following logs @ /usr/share/koha/var/log and they were blank [only logs in this directory].

koha-error_log
koha-opac-error_log

I used /usr/share/koha as the base directory for my locally installed files (those that don't get used directly from /usr/local/src/kohaclone), so I assumed this would be the appropriate directory.

Are there other logs I should be looking for?

I couldn't find specific zebra logs here; on my standard install machine, zebra logs are at /var/log/koha.

BTW, first install on a fresh server.

Cheers,

Christopher Curry
Assistant Technical Librarian / Assistant IT Officer

American Philosophical Society
105 South Fifth Street
Philadelphia, PA 19106-3386
Tel. [phone]

ccurry@...

For technical support, please use helpdesk@...
Main Library number: [phone]
APS website: http://www.amphilsoc.org

Joe Atzberger wrote:

2009/11/24 Christopher Curry <ccurry@...>

I overheard somewhere (though I can't remember the details) that using the dev install mode makes it easier to upgrade koha.  I've never done a koha upgrade; we're not fully migrated yet, but I'd like to facilitate future upgrades as much as possible.

I've had no problem setting up a koha standard install; when I try a dev install, my zebra server won't run.  The server reports on boot up (and when I manually start Zebra) that it is starting the Zebra Daemon and Zebra Server, but when I look for the process (top -c), it's not there.  No error messages are generated when starting the server.

Is there something special that must be done with Zebra conf on a dev install?

Can someone explain the advantages of a dev install?  I understand that it allows you to run the majority of the koha server files directly from a git clone.  I see how this could simplify an upgrade, but are there other advantages that will encourage me to get to the bottom of this?

No that's basically it.  It keeps everything (configs and code) in one directory, and lets you use git so you have version control over the working branch modifications that you are running on.  Then you can pull in new changes from mainline and integrate them as you see fit, switching between branches at will without modifying apache or KOHA_CONF or anything.

For a developer, it is very important to submit patches that are against the current state of the codebase.  Therefore we have to keep a reference mainline version current, and generating patches between that and a dev branch is how a submission is made. Git manages all that in a really coherent way, so you don't have to be constantly managing symlinks.

BTW, you might have a problem if the dev install was the second installation on the system to use the same config values (i.e. default port numbers).  That would be true for any additional install.  Otherwise, check your zebra logs for reasons zebra might be failing.

--joe

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel