Bug 19898 - Koha 17.11 - Upload Local Cover Image Failed - "Cannot process file as an image"
Summary: Koha 17.11 - Upload Local Cover Image Failed - "Cannot process file as an image"
Status: RESOLVED DUPLICATE of bug 20428
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 17.11
Hardware: All All
: P5 - low minor
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-29 18:41 UTC by Craig
Modified: 2018-03-29 14:38 UTC (History)
6 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig 2017-12-29 18:41:34 UTC
In Koha 17.11, I am trying to upload a .jpg image to a bibliographic record (as a local cover image). After uploading, then clicking "Process Images", I get the following error:

"Cannot process file as an image. Cannot process file as an image.
Please ensure you only upload GIF, JPEG, PNG, or XPM images."

I've tried to upload the file as a .jpg, .png, and .gif. The error persists. 
I've also tried to upload a different .jpg file. The error still persists.
Comment 1 Craig 2017-12-30 16:24:19 UTC
Checking the intranet error log, it reads:

"[Fri Dec 29 13:52:20.972923 2017] [cgi:error] [pid 5805] [client 142.116.112.216:50322] AH01215: [Fri Dec 29 13:52:20 2017] upload-cover-image.pl: Use of uninitialized value $domain in regexp compilation at /usr/share/koha/lib/C4/Auth.pm line 1090.: /usr/share/koha/intranet/cgi-bin/tools/upload-cover-image.pl, referer: http://library.craigbutosi.ca:8080/cgi-bin/koha/tools/upload-cover-image.pl"
Comment 2 Jonathan Druart 2018-01-02 18:11:33 UTC
The relevant code of the warning is:

1084                     my $branches = { map { $_->branchcode => $_->unblessed } Koha::Libraries->search };
1085                     if ( $type ne 'opac' and C4::Context->boolean_preference('AutoLocation') ) {
1086 
1087                         # we have to check they are coming from the right ip range
1088                         my $domain = $branches->{$branchcode}->{'branchip'};
1089                         $domain =~ s|\.\*||g;
1090                         if ( $ip !~ /^$domain/ ) {
1091                             $loggedin = 0;
1092                             $cookie = $query->cookie(
1093                                 -name     => 'CGISESSID',
1094                                 -value    => '',
1095                                 -HttpOnly => 1
1096                             );
1097                             $info{'wrongip'} = 1;
1098                         }
1099                     }


It says that you have AutoLocation turned on and the "branchip" field of the branches table does not match your IP. It also says that you are using a non superlibrarian account.

Could you confirm this?
If the IP does not match, it is expected that you are rejected, but in that case it should be the same behaviour with other scripts.
Comment 3 Craig 2018-01-03 01:46:05 UTC
(In reply to Jonathan Druart from comment #2)
> The relevant code of the warning is:
> 
> 1084                     my $branches = { map { $_->branchcode =>
> $_->unblessed } Koha::Libraries->search };
> 1085                     if ( $type ne 'opac' and
> C4::Context->boolean_preference('AutoLocation') ) {
> 1086 
> 1087                         # we have to check they are coming from the
> right ip range
> 1088                         my $domain =
> $branches->{$branchcode}->{'branchip'};
> 1089                         $domain =~ s|\.\*||g;
> 1090                         if ( $ip !~ /^$domain/ ) {
> 1091                             $loggedin = 0;
> 1092                             $cookie = $query->cookie(
> 1093                                 -name     => 'CGISESSID',
> 1094                                 -value    => '',
> 1095                                 -HttpOnly => 1
> 1096                             );
> 1097                             $info{'wrongip'} = 1;
> 1098                         }
> 1099                     }
> 
> 
> It says that you have AutoLocation turned on and the "branchip" field of the
> branches table does not match your IP. It also says that you are using a non
> superlibrarian account.
> 
> Could you confirm this?
> If the IP does not match, it is expected that you are rejected, but in that
> case it should be the same behaviour with other scripts.

Hi Jonathan,

Thanks for this. I am indeed using a superlibrarian account, so I'm surprised that it is reporting otherwise. I have only one patron in the system, me, and it was initially setup as superlibrarian staff. You are correct about Autolocation, it was turned on. But I have since disabled it. The IP address field in the bramches table is blank.

Unfortunately, after turning off Autolocation, restarting Koha, and restarting memcache, the error still persists.
Comment 4 Jonathan Druart 2018-01-03 15:25:47 UTC
(In reply to Craig from comment #3)
> Unfortunately, after turning off Autolocation, restarting Koha, and
> restarting memcache, the error still persists.

Do you still have the warning in the logs?
What is the exact version of Koha you are using?
Did you try on a sandbox?
Comment 5 Craig 2018-01-06 17:44:12 UTC
(In reply to Jonathan Druart from comment #4)
> (In reply to Craig from comment #3)
> > Unfortunately, after turning off Autolocation, restarting Koha, and
> > restarting memcache, the error still persists.
> 
> Do you still have the warning in the logs?
> What is the exact version of Koha you are using?
> Did you try on a sandbox?

Hi Jonathan,

I'm running 17.11.01.000.
No new intranet error logs, no new opac error logs relevant to cover image upload.
I don't have a sandbox to test, unfortunately. I created a new super librarian patron, logged in as that user, and tried to upload. The problem persists.
I also entered my public IP address into the branches table, tried to upload, and still nothing.
Comment 6 Jonathan Druart 2018-01-06 18:47:28 UTC
Can you confirm you do not have any warnings related to upload files on the about page (tab "system information")?
Comment 7 Craig 2018-01-06 23:05:49 UTC
(In reply to Jonathan Druart from comment #6)
> Can you confirm you do not have any warnings related to upload files on the
> about page (tab "system information")?

Confirmed. There are no warnings posted here.
Comment 8 Craig 2018-03-22 01:44:21 UTC
Still having trouble with this. I've successfully uploaded patron images, files to patron records, and files using the "upload file" option in Administration. 

Checked log files again and there's nothing there from what I can see.

Upgrading to the latest version of Koha (17.11.03) has no effect. Could it be an Apache or MariaDB setting?
Comment 9 Marcel de Rooy 2018-03-22 07:40:24 UTC
(In reply to Craig from comment #8)
> Still having trouble with this. I've successfully uploaded patron images,
> files to patron records, and files using the "upload file" option in
> Administration. 
> 
> Checked log files again and there's nothing there from what I can see.
> 
> Upgrading to the latest version of Koha (17.11.03) has no effect. Could it
> be an Apache or MariaDB setting?

No problem in uploading a cover image file on current master here.
Comment 10 Jef Bucas 2018-03-27 14:13:21 UTC
I got this problem on Debian Stretch with version 17.11.03-1.

Solution was to disable Systemd's Apache2's PrivateTmp flag.

/lib/systemd/system/apache2.service
--------------
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl stop
ExecReload=/usr/sbin/apachectl graceful
PrivateTmp=false
Restart=on-abort

[Install]
WantedBy=multi-user.target
-----------

systemctl daemon-reload
systemctl restart apache2
Comment 11 Craig 2018-03-27 17:48:59 UTC
(In reply to Jef Bucas from comment #10)
> I got this problem on Debian Stretch with version 17.11.03-1.
> 
> Solution was to disable Systemd's Apache2's PrivateTmp flag.
> 
> /lib/systemd/system/apache2.service
> --------------
> [Unit]
> Description=The Apache HTTP Server
> After=network.target remote-fs.target nss-lookup.target
> 
> [Service]
> Type=forking
> Environment=APACHE_STARTED_BY_SYSTEMD=true
> ExecStart=/usr/sbin/apachectl start
> ExecStop=/usr/sbin/apachectl stop
> ExecReload=/usr/sbin/apachectl graceful
> PrivateTmp=false
> Restart=on-abort
> 
> [Install]
> WantedBy=multi-user.target
> -----------
> 
> systemctl daemon-reload
> systemctl restart apache2

Hi Jef,

Thanks for this. I will try and disable later tonight and report back. To the community, just out of curiosity, would this problem in any way be related to setting a template cache directory, as specified here: https://wiki.koha-community.org/wiki/Performance?

Many thanks!
Comment 12 Craig 2018-03-27 22:45:08 UTC
(In reply to Craig from comment #11)
> (In reply to Jef Bucas from comment #10)
> > I got this problem on Debian Stretch with version 17.11.03-1.
> > 
> > Solution was to disable Systemd's Apache2's PrivateTmp flag.
> > 
> > /lib/systemd/system/apache2.service
> > --------------
> > [Unit]
> > Description=The Apache HTTP Server
> > After=network.target remote-fs.target nss-lookup.target
> > 
> > [Service]
> > Type=forking
> > Environment=APACHE_STARTED_BY_SYSTEMD=true
> > ExecStart=/usr/sbin/apachectl start
> > ExecStop=/usr/sbin/apachectl stop
> > ExecReload=/usr/sbin/apachectl graceful
> > PrivateTmp=false
> > Restart=on-abort
> > 
> > [Install]
> > WantedBy=multi-user.target
> > -----------
> > 
> > systemctl daemon-reload
> > systemctl restart apache2
> 
> Hi Jef,
> 
> Thanks for this. I will try and disable later tonight and report back. To
> the community, just out of curiosity, would this problem in any way be
> related to setting a template cache directory, as specified here:
> https://wiki.koha-community.org/wiki/Performance?
> 
> Many thanks!

Hi everyone,

Can confirm Jef's fix above. I am now able to successfully upload a local cover image. Jef, thanks again!
Comment 13 Tomás Cohen Arazi (tcohen) 2018-03-29 14:38:04 UTC

*** This bug has been marked as a duplicate of bug 20428 ***