This bug correctly inserts substitutions for this variable.
Four occurrences will now be changed. The line for log4perl.conf is now
correct, but the three other changes point to a location that does not
exist: /etc/koha/sites/$instance/zebradb.
That should just be: /etc/koha/zebradb.
All three cases concern the explain files.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
- Run koha-create to create an instance or just fire kohadevbox:ansible
=> FAIL: Notice the instance's koha-conf.xml points to __KOHA_CONF_DIR__
instead of /etc/koha/sites/kohadev/ on the log4perl entry.
=> FAIL: the /etc/koha/sites/kohadev/log4perl.conf contains __LOG_DIR__
instead of /var/log/koha/kohadev/
- Apply this patch and pick the koha-conf-site.xml.in and koha-create files
- Create a new instance
=> SUCCESS: All placeholders are filled correctly.
- Sign off
Regards
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch adds a commented zebra_loglevels line to the config file.
Behavior does not change, but an admin can easily edit the variable.
Test plan:
Nothing really changed. But if you are not so sure about that, apply the
change to /etc/koha/koha-conf-site.xml.in and run koha-create. Check
that the new koha-conf contains the line and is not messed up.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch makes koha-create and koha-create-dirs aware of the new upload_path
configuration entry.
It defaults to /var/lib/koha/<instance>/uploads as proposed by Robin but lets the
user specify its own directory, using the --upload-path option switch that is
added by this patch.
koha-create-dirs is tweaked so it also creates this new directory.
The docs are updated accordingly.
To test:
- Apply the patch, have a packages setup (either by grabbing the relevant files [1]
or by creating your own package).
- Run koha-create --create-db instance
=> SUCCESS: /var/lib/koha/instance/uploads directory is created
=> SUCCESS: /etc/koha/sites/instance/koha-config.xml has upload_path set correctly
- Create a new instance using the --upload-path making it point to whatever you want
=> SUCCESS: koha-conf.xml points to your chosen path
- Sign off :-D
Regards
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Does not work in its current state. Needs a follow-up.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: upgraded DEBUG level to WARN in config file.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
The memcache parameters aren't used by anything (except C4::SQLHelper,
but that's a cancer on the face of the earth) anymore, so they can go.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
1- Build new koha packages
2- Check that the conflist file contains the changes we have made
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds two parameters to the koha-create command:
--enable-sru: makes the koha-create script enabled the SRU server for
the created instance
--sru-port: lets the user specify a desired port for the SRU server
to listen at. It defaults to 7090
To test:
- Apply the patch on top of master
- Build your own package and install / can be tested just using the koha-create
command on a 3.16+ packages install
- Create an instance as usual (i.e. without --enable-sru and --sru-port)
=> SUCCESS: The instance is created, the publicserver sections are
both commented out. The first publicserver section has 7090 set as the
listening port.
- Create an instance as usual, passing --sru-port 456
=> SUCCESS: The instance is created, the port is set but the publicserver sections
are commented out
- Create an instance with --enable-sru (with and without --sru-port)
=> SUCCESS: Verify the instance is created as expected, with the SRU server enabled
(port 7090 if no --sru-port passed, the one we chose otherwise).
- Verify that the docs also talk about this new parameters addition.
- Sign off :-D
Regards
To+
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a variable to koha-conf.xml controlling the use of Zebra facets.
Usage:
- use_zebra_facets = 1 | 0
Zebra facets work only on DOM.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds locking to rebuild_zebra.pl to ensure that simultaneous
changes are prevented (as one is likely to overwrite the other).
Incremental updates in daemon mode will skipped if the lock is busy
and they will be picked up on the next pass. Non-daemon mode
invocations will also exit immediately if they cannot get the lock
unless the new flag -wait-for-lock is specified, in which case they
will wait until the get the lock and then proceed.
Supporting changes made to Makefile.PL and templates for the new
locking directory (paralleling the other zebra lock directories).
We stash the zebra_lockdir in koha-conf.xml so rebuild_zebra.pl
can find it.
To address earlier QA concerns we:
1. added code to check if flock is available and ignore locking if
it's missing (from M. de Rooy)
2. changed default for adhoc invocations to abort if they cannot
obtain the lock. Added option -wait-for-lock if the user prefers
to wait until the lock is free, and then continue processing.
3. added missing entry to t/db_dependent/zebra_config.pl
4. added a fallback locking directory of /tmp
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Doug merged the original patch with the QA changes.
Just for the record, noting here that the original patch was tested
extensively too by Martin Renvoize.
I have added a followup for some exceptional cases.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes the koha-create script adjust the koha-conf.xml file
with the proper string substitutions to enable the use of memcached
for the created Koha instance.
It adds three option switches that control this:
--use-memcached (defaults to "no")
--memcached-servers "host1:port1,..." (defaults to '127.0.0.1:11211')
--memcached-prefix "desired_namespace prefix" (defaults to 'koha_')
It respects the current schema configuration schema, where configuration
values are pondered like this:
hardcoded < koha-sites.conf < koha-create option switches
koha-sites.conf is read for USE_MEMCACHED, MEMCACHED_SERVERS and
MEMCACHED_PREFIX.
Note: the docs discourage setting user's own namespace prefix.
Using memcached is off as the default. The relevant configuration
variables will remain empty if the user doesn't pass --use-memcached
to the command. It matches the current behaviour.
To test:
- Apply the patch
- Build your own packages and install them on a test server
a) Create a new instance without using the new switches like:
$ koha-create --create-db memctest
- Check that /etc/koha/sites/memctest/koha-conf.xml contains:
* Empty <memcached_servers> tag.
* Empty <memcached_namespace> tag.
b) Play with the possible combination of option switches
(Note that the code defaults to empty and will remain like that if
--use-memcached is not used, so less tests...)
$ koha-create --create-db --use-memcached memctest
$ koha-create --create-db --use-memcached --memcached-servers "anything:xxx" memctest
$ koha-create --create-db --use-memcached --memcached-servers "anything:xxx" --memcached-prefix "something" memctest
$ koha-create --create-db --use-memcached --memcached-prefix "something" memctest
- Check the koha-conf.xml and /etc/apache2/sites-enabled/memctest
file reflect the chosen options.
c) Run
$ koha-create --help
- It should advertise this addition accordingly.
d) Run
$ man koha-create
- Man page for koha-create should provide good information on the new
switches behaviour
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fixed the path to __ZEBRA_BIBLIOS_CFG__ for <server id="mergeserver">
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Good catach drojf.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes the koha-create script install the file zebra-biblios-dom.cfg
with the proper string substitutions inside on the new instance koha-conf.xml file.
It also adds two option switches that control the indexing mode for the instance:
--biblio-idx {dom|grs1}
--auth-idx {dom|grs1}
DOM indexing is set as the default for both authorities and bibliographic records.
Following drojf (thanks!) advice I arranged stuff like explained here:
http://wiki.koha-community.org/wiki/Switching_to_dom_indexing
To test:
- Apply the patch
- Build your own packages and install them on a test server
a) Create a new instance without using the new switches like:
$ koha-create --create-db domtest
- Check there's a file /etc/koha/sites/domtest/zebra-biblios-dom.cfg
- Check that /etc/koha/sites/domtest/koha-conf.xml points to:
* zebra-biblios-dom.cfg (biblioserver section)
* zebra-biblios-dom.cfg (publicserver section)
* zebra-authorities-dom.cfg (authorityserver section)
- Success means the new default is DOM
b) Play with the 4 possible combination of option switches
$ koha-create --create-db --auth-idx grs1 --biblio-idx grs1 domtest
$ koha-create --create-db --auth-idx grs1 --biblio-idx dom domtest
$ koha-create --create-db --auth-idx dom --biblio-idx grs1 domtest
$ koha-create --create-db --auth-idx dom --biblio-idx dom domtest
- Check the koha-conf.xml file reflects the chosen options.
c) Run
$ koha-create --help
- It should advertise this addition accordingly.
d) Run
$ man koha-create
- Man page for koha-create should provide good information on the new switches behaviour
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes Makefile.PL put the history.txt file in the right places
depending on the chosen setup layout, adds a reference to that place in
koha-conf.xml (and debian template version), and finally tweaks about.pl to
use it.
To test, apply the patch and verify that perl Makefile.PL runs fine, and
installing in
- dev
- single
- standard
layouts works as expected. Then go to the about.pl page and see if Koha's
history shows there.
Then, build your packages and test on your newly created instances.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds support for custom plugins. At the moment the Plugins
feature supports two types of plugins, reports and tools.
Plugins are installed by uploading KPZ ( Koha Plugin Zip )
packages. A KPZ file is just a zip file containing the
perl files, template files, and any other files neccessary
to make the plugin work.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Create the directory /var/lib/koha/plugins
4) Add the lines
<pluginsdir>/var/lib/koha/plugins</pluginsdir>
<enable_plugins>1</enable_plugins>"
to your koha-conf.xml file
5) Add the line
Alias /plugin/ "/var/lib/koha/plugins/"
to your koha-httpd.conf file
6) Restart your webserver
7) Access the plugins system from the "More" pulldown
8) Upload the example plugin file provided here
9) Try it out!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
See the bug for a description of the problem.
This patch tries to restore searching for marcflavour != MARC21 as well as
allowing instances with different marcflavors to co-exist on the same server.
To test:
- Do a package install with e.g. the official squeeze-dev packages and create at
least two instances, with different marcflavours, e.g.:
sudo koha-create --create-db --marcflavor marc21 test1
sudo koha-create --create-db --marcflavor normarc test2
- Run through the web installers for both instances and add a couple of
records to each. Wait for the records to be indexed or run indexing manually
with
sudo koha-rebuild-zebra -f test1
sudo koha-rebuild-zebra -f test2
- Try searching for the records you added. It should work in test1 but not in
test2.
- Apply the patch and build packages with the build-git-snapshot script
- Install the new koha-common package
- Create two instances (because of Bug 9754 it is probably best to give the
instances different names than the ones you created above, or to do this on
a fresh VM or similar) and add records, as described above. Searching should
now work equally well for both instances.
Please note: Because of Bug 9752 you will have to set marcflavour = NORMARC
by hand before you do the searching, if you choose NORMARC as the marc flavour
on one of the instances you create.
Please note too: I am not confident that this is the perfect solution, so
merciless and thorough testing is necessary! ;-)
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Works for me for GRS-1 (package installation out of the box). Could not figure out how to set up DOM indexing and eventually stopped caring about it.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Build packages with the patch and checked that creating
instances and search within them works for both MARC21 and NORMARC.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The previous patches were missing the koha-conf.xml updates. This patch
updates koha-conf.xml and makes the changes neccessary to include the
QueryParser configuration file in the packages.
To test:
1) Run Makefile and check generated koha-conf.xml to confirm that the
line <queryparser_config>...</queryparser_config> is there with an
absolute path.
2) That was it.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested update successfully - new line now shows up and
query parser is used.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Fixes the following things:
1. Sanitizes log output to prevent an attacker from using a specially
crafted POST to add extra lines to the log
2. Simplify a regular expression since "..file" cannot be used to
escape the current directory
3. Makes sure directories are consistent
4. Correct logic issues in misc/cronjobs/backup.sh
Thanks to Frere Sebastien Marie for catching these issues.
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch builds on work by Lars Wirzenius for the Koha packages.
To date, the only way for a Koha librarian to obtain a complete backup
of their system has been to log into the system via SSH (or FTP) to
download the mysqldump file. This patch makes it possible for
superlibrarians in properly configured systems to download night backups
via the staff client's Export tool.
Recognizing that this is functionality with potentially very grave
security implications, system administrators must manually enable these
features in the koha-conf.xml configuration file.
The following configuration settings have been added to the koha-conf.xml
file:
* backupdir => directory where backups should be stored.
* backup_db_via_tools => whether to allow superlibrarians to download
database backups via the Export tool. The default is disabled, and
there is no way -- by design -- to enable this option without manually
editing koha-conf.xml.
* backup_conf_via_tools => whether to allow superlibrarians to download
configuration backups via the Export tool (this may be applicable to
packages only). The default is disabled, and there is no way -- by
design -- to enable this option without manually editing koha-conf.xml.
This commit modifies the following scripts to make use of the new
backupdir configuration option:
* koha-dump and koha-run-backups in the Debian packages
* The sample backup script misc/cronjobs/backup.sh
Note that for security reasons, superlibrarians will not be allowed
to download files that are not owned by the web server's effective user.
This imposes a de facto dependency on ITK (for Apache) or running the
web server as the Koha user (as is done with Plack).
To test:
1. Apply patch.
2. Go to export page as a superlibrarian. Notice that no additional
export options appear because they have not been enabled.
3. Add <backupdir>$KOHADEV/var/spool</backup> to the <config> section
of your koha-conf.xml (note that you will need to adjust that so that
it is pointing at a logical directory).
4. Create the aforementioned directory.
5. Go to export page as a superlibrarian. Notice that no additional
export options appear because they have not been enabled.
6. Add <backup_db_via_tools>1</backup_db_via_tools> to the <config>
section of your koha-conf.xml
7. Go to the export page as a superlibrarian. Notice the new tab.
8. Go to the export page as a non-superlibrarian. Notice there is no
new tab.
9. Run: mysqldump -u koha -p koha | gzip > $BACKUPDIR/backup.sql.gz
(substituting appropriate user, password, and database name)
10. Go to the export page as a superlibrarian, and look at the "Export
database" tab. If you are running the web server as your Koha user,
and ran the above command as your Koha user, you should now see the
file listed as an option for download.
11. If you *did* see the file listed, change the ownership to something
else: sudo chown root:root $BACKUPDIR/backup.sql.gz
11a. Confirm that you no longer see the file listed when you look at the
"Export database" tab.
12. Change the ownership on the file to your web server (or Koha) user:
sudo chown www-data:www-data backup.sql.gz
13. Go to the export page as a superlibrarian, and look at the "Export
database" tab. You should now see backup.sql.gz listed.
14. Choose to download backup.sql.gz
15. Confirm that the downloaded file is what you were expecting.
If you are interested, you can repeat the above steps but replace
<backup_db_via_tools> with <backup_conf_via_tools>, and instead of
creating an sql file, create a tar file.
To test packaging: run koha-dump, confirm that it still creates a
usable backup.
------
This signoff contains two changes:
10-1. If no backup/conf files were present, then the message telling you
so doesn't appear and the download button does. Made them behave
correctly.
10-2. The test for a file existing required it to be owned by the
webserver UID. This change makes it so it only has to be readable.
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Now it more closely matches the one that's distributed in /etc
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
(not tested. I confirm the code is clean, and tests are not broken)
koha-common will be suitable for hosts with multiple Koha instances,
or those that otherwise need to do thing differently from the main
koha package.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
