[koha-commits] main Koha release repository branch 18.05.x updated. v18.05.04-38-g6bf5044

Git repo owner gitmaster at git.koha-community.org
Fri Oct 5 15:09:40 CEST 2018


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".

The branch, 18.05.x has been updated
       via  6bf50445b151ef94e6100da482e5826458a5136b (commit)
       via  67a491a73f0dea1182c937aa424491210a0d0d8b (commit)
       via  93b7683780ba6c79ce22307c8c8cbd31f3c73a56 (commit)
      from  fe5e75057158f0d274d00d987248cf7758ef197c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 6bf50445b151ef94e6100da482e5826458a5136b
Author: Andrew Isherwood <andrew.isherwood at ptfs-europe.com>
Date:   Thu Aug 30 10:52:43 2018 +0100

    Bug 21289: Fix "isa" bug during partner request
    
    We cannot call 'handle_commit_maybe' inside a 'try' block.
    handle_commit_maybe redirects the client then calls 'exit', this is
    interpreted as an error and the 'catch' block is erroneously called.
    
    This patch moves the calling of 'handle_commit_maybe' outside the try
    block, it will only be reached if everything inside the try block
    suceeds.
    
    To test:
    1) Enable ILL and have the FreeForm backend available
    2) Create a patron category to hold ILL "partners" to whom requests can
    be sent. The category can be called anything, you should note the code
    you assign
    3) Create a patron that belongs to your new category, the patron must
    have a primary email defined.
    4) In your <interlibrary_loans> block in koha-conf.xml, ensure you have
    a <partner_code> element, it should contain the code you assigned in
    step 2
    5) Create an ILL request using the FreeForm backend
    6) Once the request is created, select the "Place request with partners"
    button
    7) Select your "partner" from the "Select partner libraries" box
    8) Click "Send email"
    9) TEST: Observe no errors are displayed in the UI
    
    Signed-off-by: Barry Cannon <bc at interleaf.ie>
    
    Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
    
    Signed-off-by: Nick Clemens <nick at bywatersolutions.com>
    (cherry picked from commit fca5a1cb3dba5d6561eaf5f30dfd4d996a4042cc)
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

commit 67a491a73f0dea1182c937aa424491210a0d0d8b
Author: Mark Tompsett <mtompset at hotmail.com>
Date:   Tue Jun 7 22:48:57 2016 -0400

    Bug 16690: Simplify SHOW GRANTS to work when connected
    
    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 at ptfs-europe.com>
    
    Signed-off-by: Jonathan Druart <jonathan.druart at 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 at bywatersolutions.com>
    
    (cherry picked from commit 013c116d59b14681bff1c18c9225ea4e31627a28)
    
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

commit 93b7683780ba6c79ce22307c8c8cbd31f3c73a56
Author: Andreas Roussos <arouss1980 at gmail.com>
Date:   Thu Sep 27 07:54:27 2018 +0300

    Bug 21416: 'gr' option missing from ZEBRA_LANGUAGE options in koha-sites.conf
    
    'gr' (as in 'Greek') is missing from the ZEBRA_LANGUAGE options
    in debian/templates/koha-sites.conf. This patch fixes that.
    
    Test plan:
    1) view koha-sites.conf and notice how 'gr' is missing from the
       ZEBRA_LANGUAGE options
    2) apply the patch
    3) observe that koha-sites.conf now includes 'gr' as an option
    
    Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
    
    Signed-off-by: Nick Clemens <nick at bywatersolutions.com>
    (cherry picked from commit 705571a2b870fbb652ca210e32ee3e7ca050e75f)
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

-----------------------------------------------------------------------

Summary of changes:
 debian/templates/koha-sites.conf |    2 +-
 ill/ill-requests.pl              |   12 +++++++-----
 installer/install.pl             |   30 +++++-------------------------
 3 files changed, 13 insertions(+), 31 deletions(-)


hooks/post-receive
-- 
main Koha release repository


More information about the koha-commits mailing list