By putting koha-shell in an if statement, "set -e" will no longer
cause the entire koha-foreach program to exit, if koha-shell
returns a non-zero status.
If a non-zero status is returned, we warn on it, and the caller
of koha-foreach can interpret that command visually.
To Test:
1) Write a shell script that says "Hello" and then exits with a 1
status
2) Run koha-foreach against that shell script with multiple instances
available to koha-foreach
3) Before the patch, koha-foreach will die after the first "Hello"
4) After the patch, koha-foreach will continue, through all the
instances, and report which instances returned non-zero statuses
by which command.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This test does obviously not achieve the desired result:
[ "chdir" != "no" ]
Trivial fix.
Adding the same quotes around starting_dir (just as for Bug 19546).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Until Perl 5.26, the current directory is added to @INC when running a
Perl script [1]. Having the current directory in @INC means it can be
tried to be traversed when performing a lib lookup. Since version 5.18,
Perl dies when it finds an unreadable directory (permissions) in @INC
that needs to be traversed. This behaviour won't change because Perl
devs consider it an enhancement to security. [2]
Because of this, we need to make sure our scripts are ran **from** a
directory in which they have read permissions.
Ths patch adds a --chdir option switch to the **koha-foreach** wrapper
script, that makes the inner shells/scripts to be ran within the Koha
instance's user home directory.
The change is trivial and should be QAed easily. I tested this on a prod
server:
- Create a /tmp/test.pl file containing:
use Modern::Perl;
use Cwd;
my $dir = getcwd;
warn $dir;
1;
A) then create a cronjob entry to run it using koha-foreach:
(in /etc/cron.d/test):
1/* * * * * root koha-foreach perl /tmp/test.pl
- Once I noticed the cronjob ran, I used mutt to read the emails in the
root user.
=> FAIL:
...
Subject: Cron <root@koha> koha-foreach --enabled perl /tmp/test.pl
"/root"
"/root"
"/root"
"/root"
"/root"
...
B) I then used the patched koha-foreach with different results:
=> SUCCESS:
...
Subject: Cron <root@koha> /root/koha-foreach --chdir --enabled perl /tmp/test.pl
"/var/lib/koha/acaderc"
"/var/lib/koha/agro"
"/var/lib/koha/anc"
"/var/lib/koha/arico"
"/var/lib/koha/artes"
...
So this patch's approach works. But...
C) master's koha-foreach seems to work just the same... I think it is
because of my previous attempt to fix this by using sudo in koha-shell.
So I think environmental conditions affect the behaviour (which shell is
configured for cron, sudo configuration, etc).
====
In conclusion, I think we should go ahead with this patch as it will solve
peoples issues, and it is a right solution (option #5 on the list) to
this Perl behaviour change. It doesn't cover other commands, but
followup patches could do.
I avoided /tmp as it is writable by any user... so it is an easy path
for both exploiting by replacing some lib, and also because the
existence of an unreadable dir that the interpreter could try to
traverse (unreadable /tmp/Authen or /tmp/Koha will trigger the same
error, and I assume people know what they are putting on the instance's
dir, at least it will be easier to track).
A followup patch takes care of making the cronjobs use --chdir when
calling koha-foreach
[1] https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html
[2] https://rt.perl.org/Public/Bug/Display.html?id=123795
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch simplifies the koha-foreach script, making it use koha-shell
to gain instance privileges and have all environment variables set.
To test:
- Apply the patch
- Have one or more instances created (kohadev already exists in kohadevbox, add
another onewith $ sudo koha-create --create-db test)
- Run:
$ sudo kohaclone/debian/scripts/koha-foreach echo "This is instance __instancename__"
=> SUCCESS: The script runs gracefuly, and outputs something like:
This is instance kohadev
This is instance test
Note: this means the command was executed for each instance and the current behaviour
of replacing the placeholder __instancename__ for the actual instance name still
works as expected.
- You can try the different filter switches, but the logic has not been touched. only the
command call.
- Sign off :-D
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the following changes:
koha-foreach, koha-upgrade-schema (shell scripts):
[1] Read default file
[2] Include helper functions
[3] Add call to adjust_paths_dev_install
[4] Replace hardcoded path by $PERL5LIB
koha-shell (perl script):
[1] Remove hardcoded lib path
[2] Add a sub that reads PERL5LIB from default or koha-conf, just as the
shell scripts do.
koha-plack (shell script), plack.psgi:
[1] Add call to adjust_paths_dev_install
[2] Remove hardcoded lib path
[3] Add installer path to PERL5LIB, remove it from plack.pgsi
koha-sitemap (shell script):
[1] Add call to adjust_paths_dev_install
[2] Remove hardcoded lib path
[3] Add installer path to PERL5LIB
[4] Adjust path for call to sitemap cron job
koha-start-sip (shell script):
[1] Read default file
[2] Include helper functions
[3] Add call to adjust_paths_dev_install
[4] Adjust path to C4/SIP
koha-stop-sip (shell script):
[1] Remove KOHA_CONF and PERL5LIB (not needed to stop the daemon)
[2] Same for paths in daemon client options
NOTE: Script debian/scripts/koha-upgrade-to-3.4 has been left out
intentionally.
Test plan:
[1] Regular install:
Run koha-foreach echo Hi
Run koha-upgrade-schema yourinstance
Run koha-shell yourinstance
If you have plack, run koha-plack --start|--stop yourinstance
Run koha-sitemap --generate yourinstance
Run koha-start-sip yourinstance
Run koha-stop-sip yourinstance
[2] Dev install [yourinstance] with <dev_install> in koha-conf.xml:
Run koha-upgrade-schema yourinstance
Run koha-shell yourinstance
If you have plack: koha-plack --start|--stop yourinstance
Run koha-sitemap --generate yourinstance
Run koha-start-sip yourinstance
Run koha-stop-sip yourinstance
[3] Git grep on koha/lib
You should no longer see occurrences in debian/scripts except:
koha-translate: see report 16749
koha-upgrade-to-3.4: left out intentionally
[4] Git grep on koha/bin
You should only see hits for lines with koha-functions in the
debian scripts except:
koha-upgrade-to-3.4: left out intentionally
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Most scripts tested on Wheezy (although it would not matter much).
Plack script tested on Jessie.
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>
New option koha-create --letsencrypt
- installs the letsencrypt package if needed
- creates <instance>
- generates letsencrypt certificates for <instance>
- sets up a https-only website for <instance>
- redirects http to https for <instance>
! you need to enable jessie backports to install letsencrypt: add
deb http://http.debian.net/debian jessie-backports main contrib non-free
to your /etc/apt/sources.list
! this patch uses the letsencrypt staging server
to create real certificates, apply thy "LE production server" patch
Test plan:
- build a debian package with patch applied
- use apache mod_ssl
sudo a2enmod ssl
- make sure the machine is accessible on 80 (needed for letsencrypt) and 443 from the internet
- install koha with your new package
- Put your (existing) domain options in /etc/koha/koha-sites.conf
- use koha-create with the new options:
sudo koha-create --create-db --letsencrypt <instance>
- if you do not have the letsencrypt package installed, you will be prompted to do that
[
if there is no package available, a symlink to the git checkout will work:
on your test server, get letsencrypt via git
git clone https://github.com/letsencrypt/letsencrypt
create a symlink from /usr/bin/letsencrypt to letsencrypt-auto
sudo ln -s /path/to/letsencrypt/letsencrypt-auto /usr/bin/letsencrypt
]
- wait until setup is finished, check that you got a working OPAC and staff client with certificates
- check that http redirects to https
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the --plack and --noplack option switches to koha-list
for filtering instances to be listed.
This is particularly important for init scripts and cronjobs.
To test:
- Play with koha-list --plack and koha-plack --enable/--disable and verify that
koha-list returns the expected results.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
koha-foreach has been modified to replace __instancename__ with $name
on each iteration using sed.
The docbook file for koha-foreach has also been updated to reflect the
new functionality.
To test:
koha-foreach ls -ld /etc/koha/sites/__instancename__
should list directories instead of giving an error message.
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
The suggested example with ls works as expected, as does my
more complex example with fines.pl:
koha-foreach --enabled /usr/share/koha/bin/cronjobs/fines.pl \
--out /var/log/koha/__instancename__/
The man page looks good too.
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
By default the packages now set up the cron jobs to handle things like
overdues and email etc. By default, email is off, 'koha-email-enable'
and 'koha-email-disable' can manage this.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
