Bug 25284 - Can't open /var/log/koha/kohadev/opac-error.log (Permission denied)
Summary: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Installation and upgrade (command-line installer) (show other bugs)
Version: Main
Hardware: All All
: P5 - low blocker (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 25172
Blocks: 25529 25693
  Show dependency treegraph
 
Reported: 2020-04-25 23:10 UTC by Katrin Fischer
Modified: 2022-06-06 20:25 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.05.00


Attachments
Bug 25284: chown /var/log/koha log files on koha-create (858 bytes, patch)
2020-05-19 12:28 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 25284: chown /var/log/koha log files on koha-create (916 bytes, patch)
2020-05-19 22:22 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
Bug 25284: chown /var/log/koha log files on koha-create (979 bytes, patch)
2020-05-20 08:17 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2020-04-25 23:10:48 UTC
I have completely rebuilt my kohadevbox, but can't get rid of this error:

Can't open /var/log/koha/kohadev/opac-error.log (Permission denied) 
at /usr/share/perl5/Log/Log4perl/Appender/File.pm line 143

First it appeared when I was trying to save system preferences.
Now I ran into it, when trying to check out an item.

I have no idea what's causing this and if this is a general or a kohadevbox issue. Help appreciated!
Comment 1 Tomás Cohen Arazi 2020-04-26 02:49:01 UTC
Bug 25172 made a permissions problem raise an error instead of just not working. With this we can now test this situations and fix them properly.
Comment 2 Katrin Fischer 2020-04-26 10:22:38 UTC
So far it has broken 2 main features for me: checkout and saving system preferences. I am continuing my QA work without those patches right now, because I can't otherwise.

I am not sure if we should not push these fixes after the release?
Comment 3 Tomás Cohen Arazi 2020-04-26 15:16:11 UTC
We fixed it manually in koha-testing-docker by setting the right permissions. You should do the same in kohadevbox so it is back to functional and you can test things.
No worries about this, we will solve it before the release, and I will set a pipeline for testing this on normal packages install (i.e. build a package, install it, and check the generated permissions. Probably on monday.
Comment 4 Katrin Fischer 2020-04-26 16:42:51 UTC
(In reply to Tomás Cohen Arazi from comment #3)
> We fixed it manually in koha-testing-docker by setting the right
> permissions. You should do the same in kohadevbox so it is back to
> functional and you can test things.
> No worries about this, we will solve it before the release, and I will set a
> pipeline for testing this on normal packages install (i.e. build a package,
> install it, and check the generated permissions. Probably on monday.

So how do I fix the permissions on the kohadevbox?
Comment 5 Tomás Cohen Arazi 2020-04-26 18:00:38 UTC
$ koha-plack --stop kohadev
$ chown -R kohadev-koha:kohadev-koha /var/log/Koha/kohadev/*
Comment 6 Katrin Fischer 2020-04-27 06:15:05 UTC
(In reply to Tomás Cohen Arazi from comment #5)
> $ koha-plack --stop kohadev
> $ chown -R kohadev-koha:kohadev-koha /var/log/Koha/kohadev/*

$ sudo koha-plack --stop kohadev
$ sudo chown -R kohadev-koha:kohadev-koha /var/log/koha/kohadev/*

Just a tiny fix in the path and it did the trick, thx!
Comment 7 Jonathan Druart 2020-04-27 13:17:47 UTC
Should we close this?
Comment 8 Katrin Fischer 2020-04-27 22:07:54 UTC
(In reply to Tomás Cohen Arazi from comment #3)
> We fixed it manually in koha-testing-docker by setting the right
> permissions. You should do the same in kohadevbox so it is back to
> functional and you can test things.
> No worries about this, we will solve it before the release, and I will set a
> pipeline for testing this on normal packages install (i.e. build a package,
> install it, and check the generated permissions. Probably on monday.

From Tomas comment it sounds like there is still ab it more work needed.
Comment 9 Tomás Cohen Arazi 2020-05-04 09:48:41 UTC
(In reply to Katrin Fischer from comment #8)
> (In reply to Tomás Cohen Arazi from comment #3)
> > We fixed it manually in koha-testing-docker by setting the right
> > permissions. You should do the same in kohadevbox so it is back to
> > functional and you can test things.
> > No worries about this, we will solve it before the release, and I will set a
> > pipeline for testing this on normal packages install (i.e. build a package,
> > install it, and check the generated permissions. Probably on monday.
> 
> From Tomas comment it sounds like there is still ab it more work needed.

I'm building a master package at the moment, to try see if this is specific to our dev tools, or if it poses a real issue on production.
Comment 10 Jonathan Druart 2020-05-15 09:26:03 UTC
Any news from this, Tomasito?
Comment 11 Jonathan Druart 2020-05-19 12:28:24 UTC
Created attachment 105086 [details] [review]
Bug 25284: chown /var/log/koha log files on koha-create

To prevent Apache to create intranet-error.log and opac-error.log with
root permission we chown them after it has been restarted (and so
created them) when a new Koha instance is created
Comment 12 Marcel de Rooy 2020-05-19 12:57:03 UTC
What happens at log rotation ?
Comment 13 Tomás Cohen Arazi 2020-05-19 13:05:38 UTC
(In reply to Marcel de Rooy from comment #12)
> What happens at log rotation ?

Good question. It is set to copytruncate so permissions should be always kept.

I tried by manually forcing rotation and the expected results show up. Had to run

  $ logrotate -f /etc/logrotate.d/koha-common

But removing weekly to force it.
Comment 14 Victor Grousset/tuxayo 2020-05-19 14:03:26 UTC
Is this plan correct?

- spin up a KohaDevBox on master
- try to do a checkout and save a system preference
- error: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied)
- throw the KohaDevBox away
- apply patch
- spin up a KohaDevBox
- try to do a checkout and save a system preference
- no error
Comment 15 Tomás Cohen Arazi 2020-05-19 14:14:06 UTC
(In reply to Victor Grousset/tuxayo from comment #14)
> Is this plan correct?
> 
> - spin up a KohaDevBox on master
> - try to do a checkout and save a system preference
> - error: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied)
> - throw the KohaDevBox away
> - apply patch
> - spin up a KohaDevBox
> - try to do a checkout and save a system preference
> - no error

1. Create a new instance:
   $ koha-create --create-db test
=> FAIL: opac and intranet logs are owned by root
2. Apply this patch
3. Reset all, so it runs cp_debian_files.pl
4. Repeat 1, with another name
=> SUCCESS: logs are owned by the right user
Comment 16 Victor Grousset/tuxayo 2020-05-19 19:20:55 UTC
Without any patch.
Went into my DevBox.
Tried to create an instance.
No issues :o

> vagrant@kohadevbox:~$ sudo su -
> root@kohadevbox:~# koha-create --create-db test
> Koha instance is empty, no staff user created.
> [ ok ] Starting Koha indexing daemon for test:.
Comment 17 Tomás Cohen Arazi 2020-05-19 22:00:36 UTC
My steps to reproduce:

$ mkdir stretch ; cd stretch
$ vagrant init debian/stretch64
$ vagrant up
$ vagrant ssh
root@stretch:~# apt update ; apt install wget gnupg
root@stretch:~# echo 'deb http://debian.koha-community.org/koha 19.11 main' > /etc/apt/sources.list.d/koha.list
root@stretch:~# wget -q -O- https://debian.koha-community.org/koha/gpg.asc | apt-key add -
root@stretch:~# apt update
root@stretch:~# ls /var/log
alternatives.log  apache2  apt	auth.log  btmp	daemon.log  debug  dpkg.log  exim4  faillog  fontconfig.log  installer	kern.log  lastlog  messages  mysql  syslog  user.log  wtmp
root@stretch:~# apt install koha-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  letsencrypt
The following NEW packages will be installed:
  koha-common
0 upgraded, 1 newly installed, 0 to remove and 72 not upgraded.
Need to get 0 B/32.1 MB of archives.
After this operation, 468 MB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package koha-common.
(Reading database ... 58880 files and directories currently installed.)
Preparing to unpack .../koha-common_19.11.05-1_all.deb ...
Unpacking koha-common (19.11.05-1) ...
Processing triggers for systemd (232-25+deb9u8) ...
Setting up koha-common (19.11.05-1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for systemd (232-25+deb9u8) ...
root@stretch:~# koha-create --create-db t_e_s_t
Koha instance is empty, no staff user created.
[ ok ] Starting Koha indexing daemon for t_e_s_t:.

root@stretch:~# ls -l /var/log/koha/t_e_s_t/
total 4
-rw-r--r-- 1 t_e_s_t-koha t_e_s_t-koha    0 May 19 21:54 indexer-error.log
-rw-r--r-- 1 t_e_s_t-koha t_e_s_t-koha 2380 May 19 21:54 indexer-output.log
-rw-r--r-- 1 root         root            0 May 19 21:54 intranet-error.log
-rw-r--r-- 1 root         root            0 May 19 21:54 opac-error.log
-rw-r--r-- 1 t_e_s_t-koha t_e_s_t-koha    0 May 19 21:54 zebra-error.log
-rw-r--r-- 1 t_e_s_t-koha t_e_s_t-koha    0 May 19 21:54 zebra-output.log
root@stretch:~#

To test:
1. Built a package with the patch
2. Installed it (I really had it previously created and on the 'stretch' directory so the deb files were in /vagrant inside the box
3. Created a new instance
=> SUCCESS: The permissiosn are correct
Comment 18 Tomás Cohen Arazi 2020-05-19 22:01:27 UTC
I stripped from those steps the install of mysql-server and some issue I had with mpm_itk between retries.
Comment 19 Tomás Cohen Arazi 2020-05-19 22:22:16 UTC
Created attachment 105124 [details] [review]
Bug 25284: chown /var/log/koha log files on koha-create

To prevent Apache to create intranet-error.log and opac-error.log with
root permission we chown them after it has been restarted (and so
created them) when a new Koha instance is created

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 20 Martin Renvoize 2020-05-20 08:17:39 UTC
Created attachment 105137 [details] [review]
Bug 25284: chown /var/log/koha log files on koha-create

To prevent Apache to create intranet-error.log and opac-error.log with
root permission we chown them after it has been restarted (and so
created them) when a new Koha instance is created

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 21 Martin Renvoize 2020-05-20 08:18:07 UTC
Thanks guys..

A little playing later and I'm PQAing this too..
Comment 22 Martin Renvoize 2020-05-20 08:18:27 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 23 Joy Nelson 2020-05-20 22:50:58 UTC
missing dependency no backported to 19.11.x
Comment 24 Jonathan Druart 2020-06-08 07:02:35 UTC
There are users on the ML reporting such problems on upgrade. Should we deal with that somewhere else. Like in koha-common.postinst?
Comment 25 Jonathan Druart 2020-06-08 10:40:36 UTC
There is _check_and_fix_perms in koha-plack to fix plack.log and plack-error.log.
But that does not seem the right place.
Comment 26 Tomás Cohen Arazi 2020-06-08 11:59:01 UTC
(In reply to Jonathan Druart from comment #25)
> There is _check_and_fix_perms in koha-plack to fix plack.log and
> plack-error.log.
> But that does not seem the right place.

koha-common.postinst
Comment 27 Jonathan Druart 2020-06-08 12:14:08 UTC
See bug 25693.
Comment 28 David Cook 2021-05-28 00:21:22 UTC
We've been having this issue again lately in 20.11... I'm going to keep my eye on it.

Ahh I talked about this a bit on Bug 16357, but I never followed through.

The real fix is to do the following change.

FROM:
log4perl.appender.INTRANET=Log::Log4perl::Appender::File
log4perl.appender.INTRANET.filename=__LOG_DIR__/intranet-error.log
log4perl.appender.OPAC=Log::Log4perl::Appender::File
log4perl.appender.OPAC.filename=__LOG_DIR__/opac-error.log

TO:

log4perl.appender.INTRANET=Log::Log4perl::Appender::Screen
log4perl.appender.INTRANET.stderr  = 1
log4perl.appender.OPAC=Log::Log4perl::Appender::Screen
log4perl.appender.OPAC.stderr  = 1
Comment 29 David Cook 2021-05-28 01:46:23 UTC
Actually I don't think that's right after all. I think it would cause some issues for Plack as I note in Bug 28477...