Closed sparklyballs closed 1 year ago
Agreed. Also, there's a warning regarding the default phone region code.
Agreed. Also, there's a warning regarding the default phone region code.
Agreed. Also, there's a warning regarding the default phone region code.
Yes, of course. But I thought it's a good idea to provide an ENV VAR for docker users. I really don't want to modify php files while using docker.
Agreed. Also, there's a warning regarding the default phone region code.
Yes, of course. But I thought it's a good idea to provide an ENV VAR for docker users. I really don't want to modify php files while using docker.
Your config file is in your volume/mount.
Agreed. Also, there's a warning regarding the default phone region code.
Yes, of course. But I thought it's a good idea to provide an ENV VAR for docker users. I really don't want to modify php files while using docker.
Your config file is in your volume/mount.
Surely I know that. But what I expect to see is that I provide a set of Dockerfile, docker-compose.yml, and .env, I copy them to the server, run docker-compose up --build -d, and that's it.
I feel setting a default phone region in the image isn't a one size fits all solution and might even confuse users. An env variable or even a graphical setting in the nextcloud UI might be a good solution for that. It's also not related to the topic of this issue, so perhaps a different issue can be made for that.
I also have solved all warnings but the one related to php-imagick with the container for version 21.
Shouldn't the container provide the ideal configuration for Nextcloud on it's own? So either add the php module to the container or remove the warning. But having a warning in a supposedly ideal environment seems counter intuitive to me.
Eu também resolvi todos os avisos, exceto aquele relacionado ao php-imagick com o contêiner para a versão 21.
Were you able to resolve this warning?
Your web server is not configured correctly to resolve "/.well-known/webfinger". More information can be found in the documentation.
Your web server is not configured correctly to resolve "/.well-known/nodeinfo". More information can be found in the documentation.
I am using ngnix and not apache.
I am using ngnix and not apache.
Yes, I'm also using nginx (with the nextcloud-fpm container) and you need to recreate your configuration according to new new configuration as the redirects changed.
https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html
I am using ngnix and not apache.
Yes, I'm also using nginx (with the nextcloud-fpm container) and you need to recreate your configuration according to new new configuration as the redirects changed. https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html
I didn't find this file to edit, did it exist or did you have to create it? I'm using this setting
I am using ngnix and not apache.
Yes, I'm also using nginx (with the nextcloud-fpm container) and you need to recreate your configuration according to new new configuration as the redirects changed. https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html
I didn't find this file to edit, did it exist or did you have to create it? I'm using this setting
In .\web\nginx.conf is your configuration. But it seems to have some modifications applied to it, so you have to create a new one by combining what you need from your current config and what's new in the nextcloud docs.
But you also seem to use some kind of preconfigured proxy config, I have no experience with those as I've configured my nginx from the official container.
In .\web\nginx.conf is your configuration. But it seems to have some modifications applied to it, so you have to create a new one by combining what you need from your current config and what's new in the nextcloud docs. But you also seem to use some kind of preconfigured proxy config, I have no experience with those as I've configured my nginx from the official container.
ok, thanks, i'll take a look.
Hi, same problem here, should we just leave showing up this svg warning? I think exactly the same as @ThxAndBye Thanks
Same here
Same for me, it really bugs my mind to see that warning that I can't easily fix.
This should be corrected in the image of the docker, it does not make sense to install something that is made to work in a way and create workarounds to correct a problem that was not solved in the cause.
libmagickcore-6.q16-6-extra
is missing and solves the issue.
Here is the part of the admin manual that mentioned the dependency: https://docs.nextcloud.com/server/21/admin_manual/configuration_server/theming.html?highlight=libmagickcore%20q16%20extra#theming-of-icons
SVG support for imagick (e.g. libmagickcore-6.q16-3-extra on Debian 9 and Ubuntu 18.04)
But the official docker image based on Debian 10, so it's libmagickcore-6.q16-6-extra
And for those who use docker with the nextcloud:fpm-alpine image? It would be something like ...
Create Dockerfile
FROM nextcloud:fpm-alpine
RUN apk update && apk add package
The problem is which package to install.
/ # apk list | grep magick
ruby-rmagick-4.1.2-r1 x86_64 {ruby-rmagick} (MIT)
graphicsmagick-zsh-completion-5.8-r1 x86_64 {zsh} (custom)
php8-pecl-imagick-dev-3.4.4-r0 x86_64 {php8-pecl-imagick} (PHP-3.01)
imagemagick-perlmagick-doc-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
php7-pecl-imagick-dev-3.4.4-r7 x86_64 {php7-pecl-imagick} (PHP-3.01)
graphicsmagick-1.3.36-r0 x86_64 {graphicsmagick} (MIT)
php7-pecl-imagick-3.4.4-r7 x86_64 {php7-pecl-imagick} (PHP-3.01)
imagemagick-c++-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
php8-pecl-imagick-3.4.4-r0 x86_64 {php8-pecl-imagick} (PHP-3.01)
imagemagick6-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0)
graphicsmagick-dev-1.3.36-r0 x86_64 {graphicsmagick} (MIT)
imagemagick-doc-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
imagemagick6-dev-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0)
imagemagick-dev-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
imagemagick-static-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
imagemagick-zsh-completion-5.8-r1 x86_64 {zsh} (custom)
imagemagick6-libs-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0)
imagemagick6-c++-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0)
imagemagick6-doc-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0)
php7-pecl-gmagick-2.0.5_rc1-r6 x86_64 {php7-pecl-gmagick} (PHP-3.01)
imagemagick-perlmagick-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
graphicsmagick-doc-1.3.36-r0 x86_64 {graphicsmagick} (MIT)
imagemagick-libs-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
imagemagick-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
And for those who use docker with the nextcloud:fpm-alpine image? It would be something like ...
Create Dockerfile
FROM nextcloud:fpm-alpine RUN apk update && apk add package
The problem is which package to install.
Try it and see :)
Jump into the container and install packages and see what packages solves it.
I guess imagemagick6-libs
or imagemagick-libs
And for those who use docker with the nextcloud:fpm-alpine image? It would be something like ...
Create Dockerfile
FROM nextcloud:fpm-alpine RUN apk update && apk add package
The problem is which package to install.
/ # apk list | grep magick ruby-rmagick-4.1.2-r1 x86_64 {ruby-rmagick} (MIT) graphicsmagick-zsh-completion-5.8-r1 x86_64 {zsh} (custom) php8-pecl-imagick-dev-3.4.4-r0 x86_64 {php8-pecl-imagick} (PHP-3.01) imagemagick-perlmagick-doc-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) php7-pecl-imagick-dev-3.4.4-r7 x86_64 {php7-pecl-imagick} (PHP-3.01) graphicsmagick-1.3.36-r0 x86_64 {graphicsmagick} (MIT) php7-pecl-imagick-3.4.4-r7 x86_64 {php7-pecl-imagick} (PHP-3.01) imagemagick-c++-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) php8-pecl-imagick-3.4.4-r0 x86_64 {php8-pecl-imagick} (PHP-3.01) imagemagick6-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0) graphicsmagick-dev-1.3.36-r0 x86_64 {graphicsmagick} (MIT) imagemagick-doc-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) imagemagick6-dev-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0) imagemagick-dev-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) imagemagick-static-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) imagemagick-zsh-completion-5.8-r1 x86_64 {zsh} (custom) imagemagick6-libs-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0) imagemagick6-c++-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0) imagemagick6-doc-6.9.11.55-r0 x86_64 {imagemagick6} (Apache-2.0) php7-pecl-gmagick-2.0.5_rc1-r6 x86_64 {php7-pecl-gmagick} (PHP-3.01) imagemagick-perlmagick-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) graphicsmagick-doc-1.3.36-r0 x86_64 {graphicsmagick} (MIT) imagemagick-libs-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick) imagemagick-7.0.10.57-r0 x86_64 {imagemagick} (ImageMagick)
I get that you can install the packages required, I mention it in the original post. What I perceive is the real issue is that now there is a specific warning regarding this, we shouldn't have to resort to effectively hosting our own images for something that should be in the image , or the warning be removed.
Just make a pull request ;)
Ha, never thought that I would have to go into a container and install a package manually to solve a dependency for a software that is supposed to have it all included in the container image.
But running apt install libmagickcore-6.q16-6-extra
(latest nextcloud container based on Debian 10) inside the container fixed the warning message about "Module php-imagick in this instance has no SVG support.".
@ostefek99, that sadly does not work for my Debian 10 container. Did you execute any other commands as well?
root@xxx:/var/www/html# apt install libmagickcore-6.q16-6-extra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libmagickcore-6.q16-6-extra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'libmagickcore-6.q16-6-extra' has no installation candidate
@mat-l did you apt update
beforehand?
https://packages.debian.org/buster/libmagickcore-6.q16-6-extra this is the package you want.
Consider that installing dependencies in a running container is not a persistent fix.
You must build your own image or it must go to the upstream image.
@mat-l, as Snuupy sugested, you need to run apt update
and then install the package (apt install
).
However as markuman said, it's a workaround for a current container. It won't persist. I am not willing to build my own container. I would expect to be fixed in the image. I am however only consumer and not sure how to help to fix it. I am grateful for the such a great work that community is doing. :)
@Snuupy @ostefek99 woops, forget the update, thought I had executed it before 🙈
@markuman in my optinion it must be integrated into the upstream image. Dunno why Nextcloud didn't do this yet.
diff --git a/21.0/apache/Dockerfile b/21.0/apache/Dockerfile
index 52fab6e..fc548ac 100644
--- a/21.0/apache/Dockerfile
+++ b/21.0/apache/Dockerfile
@@ -9,6 +9,7 @@ RUN set -ex; \
rsync \
bzip2 \
busybox-static \
+ libmagickcore-6.q16-6-extra \
; \
rm -rf /var/lib/apt/lists/*; \
\
that's the fix for the apache container
diff --git a/21.0/apache/Dockerfile b/21.0/apache/Dockerfile index 52fab6e..fc548ac 100644 --- a/21.0/apache/Dockerfile +++ b/21.0/apache/Dockerfile @@ -9,6 +9,7 @@ RUN set -ex; \ rsync \ bzip2 \ busybox-static \ + libmagickcore-6.q16-6-extra \ ; \ rm -rf /var/lib/apt/lists/*; \ \
that's the fix for the apache container
Testing this fix on my machine, I'll edit this comment with the results.
EDIT: yes it fixes it (bogs my mind a bit that it's in the "entrypoint.sh and cron.sh dependencies" part
Also @markuman I would suggest you not to edit in the Dockerfile
s themselves, they are generated from the update.sh
script, so your modification will be overwritten, if I understand correctly. So I would suggest you to add the fix in the .template files, and then generate the Dockerfile
s with the update script.
diff --git a/Dockerfile-debian.template b/Dockerfile-debian.template
index a6c4e21..87aee24 100644
--- a/Dockerfile-debian.template
+++ b/Dockerfile-debian.template
@@ -85,6 +85,7 @@ RUN set -ex; \
| xargs -rt apt-mark manual; \
\
apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false; \
+ apt-get install -y --no-install-recommends libmagickcore-6.q16-6-extra; \
rm -rf /var/lib/apt/lists/*
# set recommended PHP.ini settings
This also fixes it, and is better suited (it's in the install the PHP extensions we need
part, instead of the entrypoint.sh and cron.sh dependencies
suggested) imho.
Thank you to Snuupy and ostefek99: the hint "run update before install" fixed the problem for me. The commands: docker-compose exec app apt update docker-compose exec app apt install libmagickcore-6.q16-6-extra I agree a better way would be to integrate this package in the Dockerfile provided here.
I managed to fix a Nextcloud 21.0.0. docker instance, with help of https://github.com/nextcloud/docker/issues/263#issuecomment-540813950
Commands:
docker exec --it <<container_id>> /bin/bash
apt-get update && apt-get upgrade
apt install libmagickcore-6.q16-6-extra
id www-data
exit
docker exec -u <<id of www-data>> -it <<container_id>> /bin/bash
./occ maintenance:repair
exit
This is of course a workaround. The real fix is to include libmagickcore or, to drop the warning if libmagickcore is considered insecure.
For those working with a customized Dockerfile based on Alpine, I played around with it a little bit and found that adding RUN apk add imagemagick
was what was necessary to eliminate the warning.
I agree with the folks above, though, that adding this to the official Dockerfile and/or the example customized Dockerfiles would be preferable.
Hi all,
Let me first explain you why we have this issue.
The imagemagick
binaries haven't been added to the image on purpose due the security concerns raised in https://github.com/nextcloud/server/issues/13099. AFAIK the imagemagick binary is only required to convert SVG favicons (using default configuration and without third party apps). There are other functions that optionally depend on imagemagick
(see avatars and previews) but Nextcloud works fine without them.
For Nextcloud 21, a new warning has been introduced in https://github.com/nextcloud/server/pull/23677. AFAIK there is no new functionality that depends on the missing binaries. It's just a reminder that some features (mentioned above) might not be available. The warning is trivial to solve and patches have already been posted in https://github.com/nextcloud/docker/pull/1381 and https://github.com/nextcloud/docker/pull/1424 and it's documented for a while in https://github.com/nextcloud/docker/tree/master/.examples#imagemagick-svg-support.
It's usually easier to add additional packages to an image than removing. Given the high activity on this issue I'd like to invite you to discuss the risk of parsing arbitrary SVG, PDF etc. files versus having the warning in the default configuration. The first patch release (21.0.1) is scheduled for 2021-04-08. I guess it's reasonable to find a decision not later than then.
Note: if any defaults or requirements of Nextcloud are changing, we may have to add/remove ImageMagick anyway.
You can also use :+1: (add imagemagick
) or :-1: (don't add imagemagick
, no change) (or both if you don't care :smile:) on this comment to just share your option without making any noise. This will hopefully help to find a decision afterwards.
cc @nextcloud/docker
👍
In light of the security concerns leaving out does seem reasonable. However, keeping the warning will certainly keep issues like this one re-appearing with a reliable frequency. If the security impact is large enough that the package is kept out of multiple official packages (the ubuntu snap, this docker image, etc) then it should not be recommended in the setup warnings.
I agree with the colleague above, if there is nothing to worry about, then you should remove the warning.
Thank you Jowi, for the informative post. It puts things in a different light for me. In my view, a security problem should be highly valued. I don't think the library should be integrated until the problem is solved. Perhaps the warning could be made a little more detailed? The issue is quite old: can a solution still be expected from the developers of imagemagick? Is there an alternative? I think that's the charm of open source, that you can discuss things objectively in this way and that the community is involved. Thanks to Jowi for your commitment!
Maybe I have an alternative solution...is there a possibility to suppress the warning? If not, how does nextcloud determine if imagick is installed? Maybe we can "fake" it so nextcloud believes that it is installed...with this, we can suppress the warning without the security-flaw....
I didn't have a strong opinion, but you chnaged my mind, we should not add it, and modify/delete the warning
using nextcloud:latest
image, which is runnning debian buster underneath, I couldn't get the warning to go away with instaling only libmagickcore-6.q16-6-extra
. I got this warning to go away installing imagemagick
package. From docker compose:
docker-compose exec app apt update
docker-compose exec app apt install imagemagick
where app
is the name of the service
IMO, the warning message in the admin backend should link to this exact comment: https://github.com/nextcloud/docker/issues/1414#issuecomment-798781132 because it actually explains why the error message is there, and what should be considered before pasting some solution from StackOverflow into a root shell.
Thank you all for your feedback. Most reactions in https://github.com/nextcloud/docker/issues/1414#issuecomment-798781132 and responses are against the additional ImageMagick packages. There are always ways to improve the current warning and documentation in Nextcloud.
Eu também resolvi todos os avisos, exceto aquele relacionado ao php-imagick com o contêiner para a versão 21.
Were you able to resolve this warning?
Your web server is not configured correctly to resolve "/.well-known/webfinger". More information can be found in the documentation. Your web server is not configured correctly to resolve "/.well-known/nodeinfo". More information can be found in the documentation.
I am using ngnix and not apache.
You can add these lines on your nginx reverse config
location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
source:https://gist.github.com/terencec-padok/6f4413f3709a58e8110282c253e5cdff
For anyone who doesn't want to fuzz around with Dockerfiles:
app:
image: nextcloud:22-fpm-alpine
entrypoint: /bin/sh
command: -c "apk add --no-cache imagemagick; /entrypoint.sh php-fpm"
restart: always
...
cron:
image: nextcloud:22-fpm-alpine
entrypoint: /bin/sh
command: -c "apk add --no-cache imagemagick; /cron.sh"
restart: always
So maybe this should be closed as "WONTFIX"?
I completely understand and support the result of https://github.com/nextcloud/docker/issues/1414#issuecomment-798781132 (not adding imagemagick
by default), but: as this is the official Nextcloud containers, it would be a bit inconsistent if nextcloud/server recommends installing Imagemagick (and thus, warns about missing packages), while the ofifcial container does not follow the standard recommendations of the project. Maybe an option to suppress the warning in nextcloud/server (which would be enabled by the default Dockerfile) would make sense then...
My 2 cents: if the WARNING message were actually an INFO message, it would:
People get scared of yellow-orange-ish exclamation marks, for better or worse.
Can we agree on removing/muting the warning in Nextcloud 23?
It seems we don't want imagemagick, but still warn that it is not there - this seems to be strongly contradicting to me.
With the recent update to the vanilla library Nextcloud docker image on x86_64, i.e docker pull nextcloud, bumping the version of nextcloud to 21.0, some warnings appear,of which all but one were trivial to solve.
Whilst I know that the issue of svg compatibility and imagemagick has been raised several times, and at risk of this being marked as duplicate etc and closed , I feel now is the time to actually address it by either adding whatever is required to the image or removing this new warning.
And I understand that current advice is to modify a local Dockerfile to add the required packages etc, this isn't always an easy solution, and that (at least for now) there is a specific warning appearing about this, to suggest that people effectively create their own image locally seems a little silly.