Currently, the files in the folder /var/lib/koha/[instance] and also
in /var/spool/koha/[instance] are not removed.
This patch adds the option -p|--purge-all to include those two
directories when removing files.
Note: There was a small bug in the for loop. On the -k line the extra
shift statement is one too much.
NOTE: Verify that you use the adjusted koha-remove in the test plan
and not accidentally an older version of this script.
Test plan:
[1] Create an instance test.
[2] Run koha-remove and verify that /var/lib/koha/test still exists.
[3] Create an instance test2.
[4] Run koha-remove -k -p and verify that the sql database still exists
but the two instance folders in var/lib/koha and var/spool/koha are
gone.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
if you create a koha install using koha-create, and remove it with
koha-remove, the /etc/koha/sites/$SITE/ directory won't be removed,
because the /etc/koha/sites/$SITE/log4perl.conf has not been removed by
this script.
Test plan:
Use this koha-remove script to remove a koha install
Without this patch, the /etc/koha/sites/$SITE directory won't be
removed.
With this patch applied, the directory will be correctly removed.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
As the way we need to reference Apache instance names has now changed
between 2.2 and 2.4, we need to try it out both ways to make sure we get
it right.
This also allows koha-create/koha-disable to try the .conf version of
the name if the first one doesn't work.
To test:
* Create an instance on an Apache 2.2 system with koha < 3.16
* Upgrade to 3.16 with this patch, saying 'yes' to the renaming question
** Make sure you don't see the warning: Warning: problem enabling $site
in Apache
* Do a 'service apache2 restart'
* Make sure you can still access the instance
* Make sure that /etc/apache2/sites-enabled/instance.conf exists as a link
to /etc/apache2/sites-available/instance.conf
* Check that koha-create and koha-remove behave like you'd expect.
Note:
* If you need to make debconf forget that it asked you the question
about renaming so that it'll do it again, then run:
echo "unregister koha-common/rename-apache-vhost-files" | sudo debconf-communicate koha-common
* 'debconf-show koha-common' will show you the current debconf
configuration.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
As asked by Robin, a bash lib of functions is introduced with the common
functions to be reused. Most of the scripts are modified (reduced) to
include this file and the repeated functions cleaned.
No noticeable change in behaviour should be noticed.
As I've been todl in #debian-mentors, it is used that files for inclusion
should be installed at the apps directory (i.e. /usr/share/koha/) so this
patch makes the install script put the file in the bin/ directory.
All koha-* scripts assume the file is there already (and fail otherwise).
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Apache 2.4 expects the sites definition files use the sufix '.conf'
To reproduce:
- Install the 'koha-common' package on Debian 7 or Ubuntu 13.10+
(both known to include Apache 2.4).
- Create an instance (for example testlibrary) using the supplied
commands:
$ koha-create --create-db testlibrary
> FAIL: apache reports an error like this:
"ERROR: Site testlibrary does not exist!"
This patch adds a test on the Apache version and appends the ".conf"
sufix if needed.
To test:
1st step: koha-create gets fixed:
-- The hard way --
- Apply the patch, and build the koha-common package on top of this
commit.
- Install the built package on an Apache 2.4 Debian-based distro (Debian 7
or Ubuntu 13.10 will work)
- Create a test instance:
$ koha-create --create-db testlibrary
> SUCCESS: no more apache sites related error.
-- The easy way --
- Apply the patch, and copy the koha-create into an Apache 2.4
Debian-based distro
- Create a test instance using the koha-create script you just
copied:
$ ./koha-create --create-db testlibrary
> SUCCESS: no more apache sites related error.
2nd step: the rest of the touched scripts keep working as usual
koha-disable
koha-dump
koha-enable
koha-list
koha-remove
koha-restart-zebra
koha-stop-zebra
koha-start-zebra
They should all keep working. Can be tested "the easy way" too.
Note: there might be another issues regarding Apache 2.4 deployments
like the need for
$ a2enmod access_compat
and perhaps some directory permissions tweak, which I think should be
properly documented on the install instructions.
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Robin Sheat <robin@catalyst.net.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>
The newer version of MySQL in Ubuntu 12.04 installs a default
'localhost' user with no username. Due to the way that MySQL looks up
user details when you connect, if you connect from localhost and the
user was only created with a wildcard host (%), the anonymous localhost
user will be found instead. This means that your username is lost for
the connection, and you have no privileges.
This patch creates a second user with a hostname of 'localhost'. This
will not work if your database is on a remote server, but you probably
know what you are doing if that's the case. Patches to determine this
server's name relative to the MySQL server are welcome (or even ideas on
how to do it.)
It also fixes up a couple of other small things:
* make koha-remove stop zebra properly
* stop the warning that the password file is missing on create
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Works as promised.
Fixes bugs 6684 6997 4880:
6684 koha-remove should check the number of arguments it gets
6997 koha-remove leaves system in inconsistent state if there is an error
4880 koha-remove sometimes fails because user is logged in
Amended by chrisc@catalyst.net.nz
Trying to resolve conflicts.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Rebased on top of bug 7924.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
koha-remove would fail with a message like this:
Removing Koha instance --
ERROR 1396 (HY000) at line 1: Operation DROP USER failed for 'koha_--'@'%'
After fixing this, the --keep-mysql option made the script exit without doing
anything.
To test:
Alt 1
- Build package with build-git-snapshot
- Install package
Alt 2
- Replicate the changes in the patch in an existing installation
Then:
- Add instance1 and instance2
- koha-remove instance1
-- Check that script completes and the databse is gone
- koha-remove --keep-mysql instance2
-- Check that the script completes but the database is not removed
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This commit makes koha-create more flexible by adding a number of command-line
and configuration options.
The biggest change is to add support for pre-determined MySQL credentials using
a file in /etc/koha/passwd (for security reasons, if you use this feature, make
sure the file is not world-readable). The configuration file has the following
format:
instance:user:password:database
The database is optional, but the other two are both required if you want to
specify MySQL credentials. If no credentials are specified for a given instance,
the standard koha_instance username and an auto-generated password are used.
The following additional command line options are now available:
* --use-db - use a pre-existing database, see also --database
* --database - specify the name of the mysql database (still defaults to
koha_instance)
* --passwdfile - specify a custom (Koha) passwd file for MySQL credentials
The following additional variables are now available (for use in
koha-sites.conf or a custom config file):
* OPACPORT (previously added but not documented) - port on which the OPAC
should be served
* OPACPREFIX - prefix for the OPAC's virtual host
* OPACSUFFIX - suffix for the OPAC's virtual host
This commit also adds the --keep-mysql option to koha-remove, which, if
specified, will prevent koha-remove from deleting the database or MySQL user
when removing an instance.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
If you accidentally delete one of the files that koha-remove is supposed to
remove, when koha-remove reaches that point in the script, it will die, leaving
later removal steps undone. This patch fixes the problem by checking for the
existence of each file prior to deleting it, so that short of an actual problem
with removing the file, the script can continue. Note that the fix for bug 6929
is also needed to prevent any problems with stopping Zebra from killing
koha-remove.
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
koha-common.postinst now creates a symlink to the Debian one.
The sysadmin may replace that manually with something that allows
Koha to access a remote mysql server.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
