Hi, I am running elabftw through Marathon (DC/OS) but after disabling SSL since I have SSL termination on the marathon-lb (proxy):

DISABLE_HTTPS = false

I see errors on the web browser randomly :

https://docs.docker.com/engine/security/trust/content_trust/#pull-image-content

When trying to get my dev environment up and running again an error occured when running docker exec -it elabftw composer install:

[ErrorException]                                                                                                                            
  file_exists(): open_basedir restriction in effect. File(/.dockerenv) is not within the allowed path(s): (/elabftw/:/tmp/:/root/.composer:/  
  usr/bin/composer:/usr/bin/unzip)    

Adding /.dockerenv to the open_basedir path in php.ini seems to fix it.

Describe the bug

Running elabftw dockerhub-image for arm64 results in stuck container, output of log indicates issue with s6-overlay:

/command/s6-overlay-suexec: line 1: syntax error: unexpected ")"

Steps to reproduce

On an arm64 platform, run

docker run elabftw/elabimg:latest

or to be more specific

docker run elabftw/elabimg:4.4.3

This will produce the output as stated above.

Information

• Version of eLabFTW (visible in Sysadmin panel): 4.4.3
• Server operating system (e.g: Ubuntu, CentOS): Ubuntu 22.04.1 LTS
• Client operating system (e.g: MacOS, Windows, GNU+Linux): not applicable
• Browser (e.g. firefox, chrome): not applicable

Readme just points to documentation. Trying to set this up on a NAS but just getting "SQLSTATE[HY000] [2002] No such file or directory"

We installed elabftw on an ubuntu (18.04.1) system in our environment recently. We have projects that have large files (100s of MB to multiple GB) associated with them and we would like to be able to upload these files to their respective projects. The default file upload restriction appears to be 100 MiB.

I was advised to change "MAX_UPLOAD_SIZE" to address this. In /etc/elabftw.yml I found a parameter by this name; first I increased it from "100M" to "10000M", which did not change the restriction. Someone else suggested I change it to "0" (with no units on it), which I also tried though this also did not make a difference. I also looked at some yml files in /var/lib/docker but altering them did not change this either, even after rebooting the system.

I also noticed in the elabftw documentation (https://elabftw.readthedocs.io/en/latest/faq.html) that we were advised to try editing php.ini (which I found in /var/lib/docker/) but this also did not make a difference.

Either the changes I made to the files are not being considered by elabftw when it starts, or I am editing the wrong files. I have rebooted the system a couple times along the way in case there was something I needed to do to restart the docker instance to have these read.

thank you

Hi Nico, this is not a bug, I just wanted to inform you that my workflow for automatically building ARM 32/64 images for eLabFTW v 3.6.x with Github actions seems to be working. I will probably have to continuously update the scripts with new additions of dependencies which may not be compatible with the architecture.

To test it, I installed v3.6.7 on my raspberry pi and so far it is running without any problem:

The github workflows are here:
https://github.com/din14970/elab-arm-docker

The resulting docker images here:
https://hub.docker.com/repository/docker/nielscautaerts/elabimg/tags?page=1&ordering=last_updated

There is a workflow checkupdate.yml which checks every day if there is a new version of eLabFTW. If so it updates the repo and launches the make_latest_image.yml build of that version for amd64, arm32 and arm64. To build 3.6.x, it still uses the old amd64 exclusive Docker file to ensure reproducible builds, so I just modify it with sed directly in the github action to fix the s6 issue.

In addition, I wanted to try and create a daily build of hypernext with make_hypernext_image.yml. Unfortunately, new dependencies have been introduced which are arm32 incompatible, like openjdk11 and cypress. I tried some sed magic to edit these dependencies if arm32 is the target platform. The image builds, but unfortunately does not work (I get stuck in an error loop nginx: [emerg] cannot load certificate "/etc/nginx/certs/server.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/nginx/certs/server.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file))

Some questions:

• Do you know what might be breaking the hypernext image for arm32? Is there a workaround for cypress? If not I guess 3.6.7 will be the last version that will work on arm32.
• Would it be OK if I add a page to the eLabFTW docs to explain how to install on a raspberry pi? I think a lot of users who just want a personal eLabFTW instance in their house would find this helpful. On the other hand I would have to refer to my "unofficial" image which looks bad in the documentation.
• Do you think you could use this or could this be usefully integrated somehow? The way it is set up now is a very complicated way to build the images; much more convenient would be if the Dockerfile would be in the main eLabFTW repo and a new build for all platforms is triggered by github actions every time you create a release, push to a branch, or modify the docker file. But the implication would be that arm32 support is "official", and I understand you don't want to deal with that.

I tried to prepare my development environment to be able to contribute to elabftw.

When trying to build a dev image of elabftw I get several error messages.

Following the steps from the contributing page I geht the following error message:

ln: failed to create symbolic link '/usr/bin/php': File exists

Here is the complete logfile:

try1_ln_fails.zip

I tried to delete the command && ln -s /usr/bin/php7 /usr/bin/php.

After that I get the following error message:

The requested PHP extension ext-gmagick * is missing from your system. Install or enable PHP's gmagick extension.

Here is the complete logfile again:

try2_php7_fails.zip

I tried to install the extension using the following commands:

RUN echo "http://nl.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories

RUN apk upgrade -U -a && apk add --update \
[...]
php7-gmagick \
[...]

After that I get the error message:

Installation request for onelogin/php-saml 2.10.5 -> satisfiable by onelogin/php-saml[2.10.5].

I did not manage to get this dependency working. I am stuck at

onelogin/php-saml 2.10.5 requires ext-dom * -> the requested PHP extension dom is missing from your system.

I tried to install the packages php7-xml and php7-intl as suggested in some forums, but this did not work:
try3_php-saml_fails.zip

Is there something I am missing?

Here is my last version of the Dockerfile:

Dockerfile.zip

My docker build of hypernext is failing for arm/v7 because apparently jdk11 has not been built as an alpine package for this architecture. Is jdk11 strictly necessary for recent changes in eLabFTW or will it also work with jdk8? i.e. can I work with a custom Dockerfile or will I have to dig into how to create an alpine package?

 => ERROR [cronie-builder 7/7] RUN abuild-keygen -n -a && abuild && find /home/builder/packages -type f -name 'cr  3.0s
 => [nginx-builder  5/16] WORKDIR /build                                                                           0.1s
 => [nginx-builder  6/16] RUN git clone https://github.com/google/ngx_brotli && cd ngx_brotli && git reset --hard  1.9s
 => CANCELED [nginx-builder  7/16] RUN git clone --depth 1 -b v0.34 https://github.com/openresty/headers-more-ngi  0.8s
------
 > [cronie-builder 7/7] RUN abuild-keygen -n -a && abuild && find /home/builder/packages -type f -name 'cronie-1*.apk' -exec mv {} /build/apk ;:
#0 2.974 writing RSA key
#0 2.975 >>>
#0 2.975 >>> You'll need to install /home/builder/.abuild/-65148914.rsa.pub into
#0 2.975 >>> /etc/apk/keys to be able to install packages and repositories signed with
#0 2.975 >>> /home/builder/.abuild/-65148914.rsa
#0 2.975 >>>
#0 2.975 >>> Please remember to make a safe backup of your private key:
#0 2.975 >>> /home/builder/.abuild/-65148914.rsa
#0 2.975 >>>
: not foundsr/bin/abuild: /build/APKBUILD: line 17:
------
Dockerfile:129
--------------------
 127 |     # we move it to /build so it's easier to find from the other image
 128 |     # use cronie-1 to avoid copying cronie-doc
 129 | >>> RUN abuild-keygen -n -a && abuild && find /home/builder/packages -type f -name 'cronie-1*.apk' -exec mv {} /build/apk \;
 130 |     # END CRONIE BUILDER
 131 |
--------------------
ERROR: failed to solve: process "/bin/sh -c abuild-keygen -n -a && abuild && find /home/builder/packages -type f -name 'cronie-1*.apk' -exec mv {} /build/apk \\;" did not complete successfully: exit code: 127

Any suggestions are appreciated

Describe the bug

When passing the environment variable AUTO_DB_INIT to true in the docker-compose file we would expect the database to be automatically initialized during container startup but an error actually pops out :

/usr/sbin/prepare.sh: line 386: /elabftw/bin/install: No such file or directory

The problem is that the /usr/sbin/prepare.sh script is trying to execute :

/elabftw/bin/install start

Instead of :

/elabftw/bin/init db:install

Steps to reproduce

Set the variable to true in the docker-compose file :

- AUTO_DB_INIT=true

Launch the containers :

docker-compose up -d

Check the logs of the elabftw container :

docker logs -f elabftw

Information

• Version of eLabFTW (visible in Sysadmin panel): 4.8.1
• Server operating system (e.g: Ubuntu, CentOS): Ubuntu 22.04 + Docker
• Client operating system (e.g: MacOS, Windows, GNU+Linux): GNU+Linux
• Browser (e.g. firefox, chrome): Firefox

Feature request

Hello,
Would you please allow the cross origin request on your server as I am trying to call an API using GET in JavaScript but I get (Method not allowed) with the following err (Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at .../api/v1/ex
periments/16?format=json. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Thank you.

Describe the bug

When building the docker image from latest tagged build (today it is 4.9.0 see here: https://github.com/elabftw/elabftw/releases/latest) with DOCKER_BUILDKIT=1 docker build --build-arg ELABFTW_VERSION=4.9.0 -t elabftw/elabimg:4.9.0 .
As descriped in the readme file. The build will fail because there's no .yarnrc.yml file in the https://github.com/elabftw/elabftw/tree/4.9.0 repository.

Check: https://github.com/elabftw/elabftw/tree/4.9.0 there's no .yarnrc.yml file so it have to fail.

• Version of eLabFTW (visible in Sysadmin panel): 4.9.0 also tried 4.8.6
• Server operating system (e.g: Ubuntu, CentOS): Ubuntu LTS 20
• Client operating system (e.g: MacOS, Windows, GNU+Linux): Ubuntu LTS 20
• Browser (e.g. firefox, chrome): latest Firefox

Don't build from tagged release, build from master or latest: https://github.com/elabftw/elabftw/tree/master
So the command: DOCKER_BUILDKIT=1 docker build --build-arg ELABFTW_VERSION=master -t elabftw/elabimg:master . works fine.

Since i don't understand any of these things, this could also be the usual behavior and not a bug. In that case, please understand, but I was confused by the instructions and it took me an hour to find the problem.