This patchset adds support for extracting 'max_ver' from the cpanfile so
we can use version ranges properly and report errors if we have modules
installed that do not fit within that version range.
Test plan:
1) Manually modify the module version of a required module in the cpanfile
to have a max version greater than the version you have installed.
2) Run through the install proceedure and note the new warning that a
module needs upgrade for the module in question.
3) The module should also be reported in the about page
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The 'usage' key was dropped as part of this migration to cpanfile but
it was still refered to by the installed. This patch simply removes
references to it. After considering how we might add it back in I
decided that as it stands it wasn't a well maintained list and should be
re-implimented in the future in a more consistent form if we miss it.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
cpanfile is a format for describing CPAN dependencies for Perl
applications.
It is more concise - thus easier to read and maintain - than
C4::Installer::PerlDependencies, and allows to describe requirements
more accurately (using version ranges or features for instance)
Additionally it can be read by tools such as cpanm or carton for an
easy way to install dependencies on non-Debian-based systems.
For more information on cpanfile, see
http://search.cpan.org/~miyagawa/Module-CPANfile-1.1002/lib/cpanfile.pod
This patch replace C4::Installer::PerlDependencies by an equivalent
cpanfile and update all scripts/modules that were using PerlDependencies
It also removes dead code from C4::Installer::PerlModules (some
subroutines were not used at all, except in unit tests)
Added dependencies:
- Module::CPANfile
- CPAN::Meta (dependency of Module::CPANfile, but we need a more recent
version than the one Module::CPANfile requires)
Test plan:
1. Go to About page, tab Perl modules and keep this browser tab open
2. Apply patch
3. Install Module::CPANfile and CPAN::Meta
a. On Debian-based systems:
# will install libcpan-meta-perl as a dependency
sudo apt install libmodule-cpanfile-perl
b. Others:
# will install CPAN::Meta as a dependency
sudo cpanm Module::CPANfile
4. In a new browser tab, go to About page, tab Perl modules and compare
the table with the one in the previous browser tab
They should be identical, except for newly added dependencies
(Module::CPANfile and CPAN::Meta)
5. Do a 'standard' install
a. perl Makefile.PL (select 'standard')
b. make
c. sudo make install
d. Configure your database, web server, ... and go through the web
install process
6. Verify that the cpanfile got copied into PERL_MODULE_DIR (which
should be /usr/share/koha/lib)
7. Go to the about page of this fresh install and compare it with your
dev install
8. Verify that debian/list-deps still works
This takes a lot of time and it may not be necessary to wait until
the end. If you see some Debian package names that correspond to
modules in cpanfile, it means it still works
(you need apt-file for this script to work)
9. Verify that koha_perl_deps.pl still works
10. prove t/Installer_pm.t t/Installer_PerlModules.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
Check that we are using Modern::Perl when strict *and* warnings were used before,
and commented lines and FIXMEs have been removed from the rest, out of
files listed below.
data/mysql/backfill_statistics.pl
data/mysql/labels_upgrade.pl
data/mysql/patroncards_upgrade.pl
data/mysql/update22to30.pl
data/mysql/updatedatabase.pl
externalmodules.pl
html-template-to-template-toolkit.pl
install.pl
Sponsored-by: Catalyst IT
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch was generated using codespell
Test plan:
Read through changes and confirm they make sense
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=21706
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
Unless the DB is set up with 'user'@'%', which is also a
potential security issue.
MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.
This also removes the need to have permissions for
'koha_kohadev'@'%', because the only process to be
accessing the koha DB is from a known host/ip.
This tightens security too.
TEST PLAN
---------
Install 2 fresh VMs from a Debian ISO.
Make sure they are on the same network (192.168.50.x) as
the kohadevbox. You will need to remember one as DB_IPADDRESS.
On the DB VM & Third VM:
sudo apt-get install mariadb-server mariadb-client net-tools
-- the third vm just needs to be able to run mysql to access
the DB VM.
On DB VM:
sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
-- make sure the bind-address line is commented out with a #
sudo service mariadb restart
-- congratulations, your DB server is listening to remote
calls now.
sudo mysql -u root
CREATE DATABASE koha_kohadev;
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- now you have an empty DB ready to run a web install on.
However, because only koha_kohadev from localhost is
allowed, we expect failure when we try to run the web
installation step when we get there.
Let's confirm that everything is working as expected
before trying. It will also demonstrate the reason why
this patch is superior to the existing code.
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should be denied
On DB VM:
DROP USER 'koha_kohadev'@'localhost';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case requires the unless code currently in place,
because we aren't checking CURRENT_USER.
On DB VM:
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case demonstrates that we have two failure points:
1) The GRANT command by the DB Admin and
2) The koha-conf.xml setting.
This is why CURRENT_USER is superior: only (2) is the
failure point.
On DB VM:
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SELECT host,user FROM mysql.user;
-- Should see both koha_kohadev for 192.168.50.10 and %.
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case doesn't need the unless. CURRENT_USER still
just works.
On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
administrator would prefer. And notice, CURRENT_USER still
just works.
On DB VM:
DROP USER 'koha_kohadev'@'192.168.50.10';
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- This basically give koha_kohadev free reign to do pretty
dangerous stuff.
On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show a line based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give a no such grant error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
administrator would prefer. And notice, CURRENT_USER still
just works.
In the old code, both cases were literally checked.
This tweak is an optimization which doesn't require
setting permissions to the mysql.user table. Without it,
the code says the user doesn't have permissions to check
the show grants. This issue is not visible to the user,
because both cases are checked.
On DB VM:
SELECT host,user FROM mysql.user;
-- for each one do an appropriate DROP USER 'user'@'host';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
On kohadevbox:
-- Make sure the /etc/koha/sites/kohadev/koha-conf.xml
points to the DB VM.
-- Make sure a web install runs correctly
On third VM:
-- Make sure unable to connect as koha_kohadev/password.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I have not followed the whole test plan but trusting author and SO
Changes make sense to me
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch not only updates the version check, but repurposes
the perlversion parameter, so as to not have to retranslate
templates again when the version number changes after this.
The changes are very self-evident.
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The description in comment #0 is quite true, because the
scope of the $checkmodule variable is local to just the
module checking. If we change the scope, we can include the
perl check as part of the new scope, and thus properly set
its value.
As Debian Jessie, Stretch and Ubuntu Xenial all have good
versions of Perl by default, the easiest way to test this
is to:
- make sure to have some optional modules not installed.
- change the system preference 'Version' to one just under
the current version in your SQL client.
- modify the version check line to 5.030000
- restart_all and try going to the staff client.
-- This should not inform you that your perl version is bad.
- git reset hard back to origin/master
- apply the patch
- modify the version check line to 5.030000
- change the system preference 'Version' to one just under
the current version in your SQL client.
- restart_all and try going to the staff client.
-- This should trigger the patch, and you should
be informed your perl version is bad.
- git reset hard back to origin/master
- apply the patch
- run koha qa test tools
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To display the output of the updatedatabase.pl under Plack, we redirect
the output to a temporary file, read it, then display it.
We need to open it specifying the correct encoding (utf-8).
Test plan:
1. MariaDB [koha_kohadev]> update systempreferences set value="17.1100000"
where variable="version";
2. restart plack
3. Login
4. Make the update from the interface
=> Without this patch you will see encoding issue:
Upgrade to 17.12.00.000 done (TÄ tÅia, tÄ haumatia)
=> With this patch applied you will see :
Upgrade to 17.12.00.000 done (Tē tōia, tē haumatia)
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. Start a normal install using the web installer
2. When asked to select data to load, verify that
'message_transport_types' is checked, and check some optional data
files
3. Continue the install to the end
4. Verify that message_transport_types is not empty, and that the
optional data you checked is there
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Onboarding tool and the rest of the web installer still exists in this
commit
How I tested in my VM (Current master):
- Dropped database
- Recreated database
- Went through installer
- Language en, Marc21
- Installed mandatory data only
- Went through Onboarding tool
- After finishing, logged in as superlibrarian
that was created by onboarding tool
Everything worked fine.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Tested 3 patches together on current master
- Dropped database
- Recreated database
- Went through installer
- Language en, Marc21
- Installed mandatory data only
- Went through Onboarding tool
- After finishing, logged in as superlibrarian
that was created by onboarding tool
Everything worked fine.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Git install old-school style a pre-tls koha
Drop the DB
Create the DB
change branch to master
Run a web install.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
In summary, changes are:
1) If you have chosen MySQL, Makefile.PL will ask you if you want TLS (default:
"no"), and then the locations for CA cert, client cert and client key
(reasonable defaults are provided). Settings <tls>, <ca>, <cert> and <key> are
added in koha-conf.xml
2) If <tls>yes</tls> in koha-conf.xml, the installer and database connection
scripts add the TLS options in both DBI connection strings and mysql command
line
To test
1/ Apply patch
2/ Check everything still works and db connections are the same as before
3/ Either run Makefile.PL and step through the options or edit your koha-conf.xml to
enable TLS
4/ Check db connections are still working
Patch provided to me by Dimitris Kamenopoulos and I reformatted it into a git patch,
any errors are probably mine
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The code is duplicated, variable are not set ($_), code is hard to read,
not covered by tests and the subroutine has 2 completely different
behaviors depending on the presence of the "module" parameter.
No need more ti rewrite it.
Test plan:
- Use koha_perl_deps.pl with the different options (-u -m -a -i)
- Go on the about page, "Perl modules" tab
You should not see any differences from before and after this patch
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
What we currently have:
Koha/ElasticSearch.pm
Koha/ElasticSearch/Indexer.pm
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
Koha/SearchEngine/Elasticsearch/Search.pm
What we want:
Koha/SearchEngine/Elasticsearch.pm
Koha/SearchEngine/Elasticsearch/Indexer.pm
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
Koha/SearchEngine/Elasticsearch/Search.pm
Test plan:
% git grep -i Koha::ElasticSearch
% git grep ElasticSearch|grep -v Catmandu::Store::ElasticSearch
should not return any result
Do a full reindex and search for records
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The yaml file is not used to populate ES mapping tables (search_field,
search_marc_map and search_marc_to_field) when doing a fresh install.
We need to insert them, otherwise ES will be unusable.
Test plan:
Create a new install and confirm that the ES tables (search_field,
search_marc_map and search_marc_to_field) are correctly populated.
Bonus points: Use an older DB (prior to 3.23.00.050), execute the
updatedatabase.pl script and confirm that the ES table are correctly
populated
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
While testing bug 9006, I discovered this gem in
installer/install.pl
TEST PLAN
---------
1) back up DB
2) drop db and create db
3) git reset --hard origin/3.20.x
4) run web installer and all sample data
5) git reset --hard origin/master
6) empty your koha intranet error log
7) run web installer to upgrade
-- there will be warnings regarding regex around
installer/install.pl line 328 or so.
grep "\$kohaversion" ~/koha-dev/var/logs/koha-error_log
8) repeat steps 2-6
9) apply this patch
10) run web installer to upgrade
-- no regex warnings.
grep "\$kohaversion" ~/koha-dev/var/logs/koha-error_log
11) koha qa test tools
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
This code causes the installer to re-check dependencies during the
upgrade process.
Test Plan
---------
1) Log in to staff client
2) Koha Administration -> Global system preferences -> Local
3) Change Version to previous version -- DO NOT HIT SAVE YET!
4) In command line: sudo apt-get purge libpdf-fromhtml-perl
NOTE: This could be ANY required library. I chose
PDF::FromHTML, because it has been a thorn in my side.
5) NOW! Hit the 'Save' button.
6) Log in, etc. etc...
-- Blows up on redirect to log in.
7) In command line, add it back (I had to compile my own so,
I used sudo dpkg -i /path/to/libpdf-fromhtml-perl...)
8) Apply patch
9) Edit the C4/Installer/PerlDependencies.pm to make
PDF::FromHTML required. See also bug 14103.
10) Log in to staff client
11) Koha Administration -> Global system preferences -> Local
12) Change Version to previous version -- DO NOT HIT SAVE YET!
13) In command line: sudo apt-get purge libpdf-fromhtml-perl
14) NOW! Hit the 'Save' button.
15) Log in, etc. etc...
16) Once warned you are missing it, add it back at the command line.
17) Click 'Recheck'
-- Proceeds as expected now.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It will permit not to run another perl interpreter.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Additionally to the datetime, it could be useful to have the version
numbers in the log filenames.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes the test on write permissions of the logdir.
It uses File::Temp to generate a file in the logdir or otherwise in
a system tmp dir.
This resolves issues with both write permissions as well as SELinux
denials.
Note that after generating an empty file, we are appending to it in
the system statement.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: only use File::Temp in the fallback case. Do not add the four
character suffix in the first attempt.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the logdir directory is not writable by the koha user, the installer
should not explode.
This patch uses a temporary directory as a fallback.
That means that the history won't be kept.
Test plan:
0/ Generate an update (modify updatedatabase.pl and kohaversion)
1/ Make sure the permission are not correct on $logdir
2/ Go on the interface and execute the update entry.
3/ Confirm that the log has been created in a temporaty directory.
Retry with correct permissions and confirm the log will be created in
$logdir.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a follow-up for completely resolving encountered issues.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
0/ Start plack for intranet
1/ Create a new entry in updatedatabase.pl, something like:
$DBversion = "3.19.00.013";
if(CheckVersion($DBversion)) {
print "Upgrade to $DBversion done (Bug test plack - This is a
est)\n";
print "Upgrade to $DBversion done (Bug test plack - This is anoter
est)\n";
print "Upgrade to $DBversion done (Bug test plack - This is a third
est)\n";
warn "this is an error";
}
and modify the kohaversion.pl accordingly.
You can also warn something to simulate an error.
2/ Go on the mainpage (or wherever you want), you should be redirected
to the installer
3/ Notice that the output of the updatedatabase is displayed on the
screen.
4/ Confirm that new files have been created in your Koha log directory
(check the logdir entry in your koha conf file).
5/ Confirm that the output is still displayed without Plack.
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes the redirection to step 3.
If you go on installer/install.pl and Koha is already installed,
you should be redirected to the step 3. Without this patch, the
script raised an internal error (500).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
InstallAuth was in the installer directory, which meant that Plack was
unable to find it, and so running the webinstaller would fail. This
moves it into C4,
Test plan:
* Make sure the web installer runs under plack
* Make sure the web installer runs under non-plack
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
DBD::Mysql provides a mysql_auto_reconnect flag. Using it avoids
the time required to do a $dbh->ping().
Benchmarks:
use Modern::Perl;
use C4::Context;
for ( 1 .. 1000 ) {
$dbh = C4::Context->dbh;
}
* without this patch on a local DB:
perl t.pl 0,49s user 0,02s system 98% cpu 0,525 total
* without this patch on a remote DB:
perl t.pl 0,52s user 0,05s system 1% cpu 37,358 total
* with this patch on a local DB:
perl t.pl 0,46s user 0,04s system 99% cpu 0,509 total
* with this patch on a remote DB:
perl t.pl 0,49s user 0,02s system 56% cpu 0,892 total
Testing the auto reconnect:
use Modern::Perl;
use C4::Context;
my $ping = $dbh->ping;
say $ping;
$dbh->disconnect;
$ping = $dbh->ping;
say $ping;
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Real improvement. No koha-qa errors
prove t/db_dependent/Circulation_issuingrules.t produces no error
prove t/db_dependent/Context.t produces no error
Test
1) dumped Koha DB, load it on a non-local server
2) run sample script whit and without patch, local and remote
use Modern::Perl;
use C4::Context;
for ( 1 .. 100000 ) {
my $dbh = C4::Context->dbh;
}
Main difference I note is with remote server
a) without patch
real 0m16.357s
user 0m2.592s
sys 0m2.132s
b) with patch
real 0m0.259s
user 0m0.240s
sys 0m0.012s
I think this could be good for DBs placed on
remote servers
Bug 10611: add a "new" parameter to C4::Context->dbh
When dbh->disconnect is called and the mysql_auto_reconnect flag is set,
the dbh is not recreated: the old one is used.
Adding a new flag, we can now force the C4::Context->dbh method to
return a new dbh.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Bug 10611: Followup: remove useless calls to dbh->disconnect
These 3 calls to disconnect are done at the end of the script, they are
useless.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The routines sql_file_list and marcflavour_list in Installer.pm are not used.
There are some references to them in probably obsolete '/lib' test units.
I changed these test units for the record too.
Also: removed the not-existing marcflavour parameter of sample_data_sql_list
in its call in install.pl.
Test plan:
Run a new install.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Removed NoZebra vestiges. This comprises several code blocks that depend on the NoZebra syspref and NZ related functions/methods.
C4::Biblio->
GetNoZebraIndexes
_DelBiblioNoZebra
_AddBiblioNoZebra
C4::Search->
NZgetRecords
NZanalyse
NZoperatorAND
NZoperatorOR
NZoperatorNOT
NZorder
C4::Installer->
set_indexing_engine
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The 2 files C4/Auth.pm and install.pl *must* have the $version variable
set to what is the last old-mechanism for updatedatabase
This patch set to 3.11.00001 that is the last number when I QA this patch
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
This patch use DataTable, see BUG|BZ 6836
- css/datatables.css
- lib/jquery/plugins/jquery.dataTables.min.js
- js/datatables.js
http://bugs.koha-community.org/show_bug.cgi?id=7167
Bug 7167 follow-up
Major changes:
* creating database tables for update on the fly, the 1st time the update script is called
* version is checked on mainpage.pl (and here only). If syspref Version differ from kohaversion.pl, the old updatedatabase is launched. If there are updates missing from new mechanism, the updatedatabase page is reached
* kohaversion check on each page is now useless in Auth.pm, removed dead code
* Updated installer: at the end of the process, retrieve all updates and automatically mark them "OK", as they're included in installer
Minor changes:
* adding copyright
* adding poddoc
* updating a warning, for better clarity
* switching from $$var to $var->
* small TT glitch fixed in updatedatabase.tt
* about.pl now returns the Version systempreference PLUS all the patches that have been applied
Bug 7167 follow-up perlcritic & numbers display & partial apply depending on DEBUG
* add use strict to updatedatabase, that is now perlcritic compliant
* partial apply of DB revs is now managed by DEBUG env variable = if DEBUG=0, the user can just apply every DBrev. If DEBUG=1, we're in a dev env, the user know has the option to apply DBrevs one by one
Display:
* in updatedatabase, small spelling changes
* in about.pl, remove 0 just after . (3.06.01 is displayed as 3.6.1)
* improve the display of applied numbers on about.pl
- before this patch, if you have N, N+1, N+2, N+3 and N+10 DB rev applied, about was displaying : , N+1 / N+2 / N+3 / N+10
- after this patch you have N......N+3 / N+10
* add ORDER BY into list_versions_already_knows to have number retrieved in the same order whatever the order they are applied
http://bugs.koha-community.org/show_bug.cgi?id=6679
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Improve the update.pl script
* Added CLI options to update.pl
* Call update.pl from the installer.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Now, we check versions on mainpage.pl and after login
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Reimplementing Marcel's suggestions & fixes
* Fixing the bugguy old version check (that was made against 3.0900000 instead of 3.0900027 -the last current kohaversion number
* in the CLI script, if there is nothing to report, just say it
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Bug 7167: Remove check_coherency
As suggested by Katrin, we've removed the call to check_coherency. It intended to provide readable comments when some SQL was wrong. Removing this sub result in the SQL error being displayed. That's OK because the sysadmin or the developer can google the error, understand it, then fix it.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Changing in .sql parsing
We first split on delimiter and then extract comments. You can now put
\n for delimiter comments.
ex:
DELIMITER ;
-- this is a comment
SELECT * FROM my_table;
-- another comment
Before this patch, we had to write:
DELIMITER ;
-- this is a comment;
SELECT * FROM my_table;
-- another comment;
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Add .pl and .sql examples
Those files are in version directory, so will never be executed by the updater
If you want to provide an update, do it in a 3.09/ directory (if your update is expected for 3.10 version)
Note that the updater use a md5sum checker. So, if the same update is in 2 different places, it will be detected. That will be handy for changes made on both stable and master: a library running stable will get the update when updating. When upgrading to the next major release, Koha will detect the patch has already been applied, and no error will be thrown. With the previous mechanism, a DBRev ported to stable was re-executed when upgrading to master, resulting in a nasty (but usually harmless) error message
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Improve display + factorize get_queries
Despite it's size, this patch is dealing with display questions only:
* The text "comments" and "queries" was hardcoded in ajax-updatedb-getinfo.pl script. It has been replaced by a JSON call, returning 2 separate values, "comments:" and "queries:" is now in the template, making it translatable
* Some minor tweak in the display (like putting things in bold, displaying OK in green, warnings in yellow and KO in red)
* Reordering the column headers for more readability:
* Status column is merged with availability, column is after status
* Status/availability terms more clear: "Not applied" instead of "unknown", "Applied and OK", "Applied and failed", "Applied and forced" are the 3 other statuses
* Removed one click to display comments on DBREv not yet applied: before the patch, one had to click "Show details", then "Get comments", now, "Get comments" is enough
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: FIX typos & moving a script to a proper place
* renamed availables to available
* renamed already_knows to already_applied
* fixed FSF & copyright headers
* removing a "use strict" because we already had use Modern::Perl
* fixed a tiny typo in about.tt
* moving update.pl to misc/bin because it's a CLI script
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Add dependency File::Find::Rule
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: We want to execute non-numeric version with the -all option
Dealing with Marcel comment 100:
> Note that the current code around line 52/53 does not
> handle that correctly:
> Argument "\x{74}\x{65}..." isn't numeric in numeric ge (>=) at
> installer/data/mysql/update.pl line 52.
Now, a non-numeric DBRev will be applied if you provide the --all parameter, without throwing the error
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167 reindentation & removing dead code
* The if (! defined $ENV{PERL5LIB}... block was wrongly intented
* The 3 lines running update.pl are useless: the update (new mechanism) is run from admin/updatedatabase.pl script. This part of install.pl is run only when you have "old style" DB revisions.
Summary:
* old mechanism = it's run as previously, by reaching the installer/install.pl?step=3 page, that applies all revisions
* new mechanism = when you log-in or reach mainpage.pl, you reach admin/updatedatabase.pl, where you can see what will be run, and run it
Tiny side effect = the check for old mechanism is now done *after* authentification (thus it's not done on each page call). It means that the user will have to enter login/password twice :
* first to log-in to Koha
* second to run installer/updatedatabase.pl?step=3
As the old mechanism is deprecated, we can expect this will happend only a few time in the history of a setup, it's not a big deal.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Don't raise an error in routine TableExists
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: FIX merge
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167: Add .pl and .sql examples
Those files are in version directory, so will never be executed by the updater
If you want to provide an update, do it in a 3.09/ directory (if your update is expected for 3.10 version)
Note that the updater use a md5sum checker. So, if the same update is in 2 different places, it will be detected. That will be handy for changes made on both stable and master: a library running stable will get the update when updating. When upgrading to the next major release, Koha will detect the patch has already been applied, and no error will be thrown. With the previous mechanism, a DBRev ported to stable was re-executed when upgrading to master, resulting in a nasty (but usually harmless) error message
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 7167 follow-up fix POD syntax to please koha-qa.pl
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch fixes PERL5LIB path injection to include installer dir
which is required
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Updating database structure
Update errors :
Can't locate C4/Context.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 .) at /srv/koha/installer/data/mysql/updatedatabase.pl line 37.
BEGIN failed--compilation aborted at /srv/koha/installer/data/mysql/updatedatabase.pl line 37.
It seems that plack cleans enviroment, so we have to re-instart PERL5LIB
so script invocation won't fail.
It also fixes exit 1 which fail with plack.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- Change the installer script to look for at least 5.10/5.010000
- Change the template to ask for the correct version
To test:
- Run through the webinstaller on 5.10 or newer and check that there are
no errors.
- Ideally: Run through the webinstaller on an older version than 5.10 and
check that there *is* an error, asking for 5.10 or newer.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
The web installer should log errors to the error log instead of only
dumping them to the browser. This will allow a record of the errors
which may be useful for later debugging.
