-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inconsistency in the configure() procedure #56
Comments
It's possible that I really don't understand what you're doing and I hope you'll forgive me. But i have the impression that you're mixing host environment variables with those of the installation container. In my opinion, you can't call host variables when you're in the installation container. For example, the only copy command the container can understand is this one:
not that one:
It's because you've shared the folders between the host and the installation container that this command with fixed paths works correctly.
By applying this principle to the entire configure.sh script, I manage to install lizmap data in both /docker/lizmap and /home/docker/lizmap. But I've come across an error that has nothing to do with it, or so I assume.
Thank you in advance for your feedback. Ernest. |
Yesterday I suggested using the following command to copy the file /install/env.default to /lizmap/.env, but this is impossible as it stands because of the rights that are set in the container. For proof of this, simply launch the container in detached mode (-d) and use the command "tail -f /dev/null" to keep it running by monitoring the fictitious file /dev/null, which prevents the container from terminating.
You can then log in and see that /install is owned by LIZMAP_UID:LIZMAP_GID (1001:1001 in my case), while the destination folder, /lizmap, is owned by root:root.
The command Thank you in advance for your feedback. Ernest. |
The installation process requires that some operations are done in a container (plugins installation), this is why some paths need to be relative to paths mounted in the container.
The configure scripts does not allow for root installation on purpose: too many peoples shoot themselve in the foot because of that. The lizmap docker compose is mainly a test configuration for people that want a quick running install. If you need a more custom installation in a specific location you cannot rely on the ./configure script as is, you'll problably need to copy the files install config elsewhere and override the Something like that should work: #!/bin/sh
#
# Run the lizmap deployment from the current config
#
export \
LIZMAP_UID=$(id -u <user>) \
LIZMAP_GID=$(id -g <user>) \
INSTALL_DEST=/my/destination/location \
INSTALL_SOURCE=$(pwd)
LIZMAP_CUSTOM_ENV=1
# Customize your environment
envsubst < env.default.in > env.default
# Call the original configure script
../lizmap-docker-compose/configure.sh configure |
Thank you for your feedback but alas I was unable to carry out the desired installation with your advice. So I had to make do with a standard configuration and a manual data move.
I took the opportunity to choose the most recent versions of the basic applications.
First, I run the configuration tool :
Then I launch the docker composition.
I stop docker composition by using a command that destroys all non-permanent volumes.
With the root user, I moved the data into the target directory (outside the docker composition download folder because it's supervised by git!).
Finally, you just need to point the .env symbolic link to the destination folder and correct its contents.
You can then restart the Docker composition and check that the data between the host and the containers is shared, thus guaranteeing data continuity. All this in a non-git-ed folder! Ernest. |
Is this issue still relevant ? |
There's a problem with variable assignment and use of the same variable in the configure() procedure.
Indeed, if you add the following lines to the env.default file:
And then you run the Docker command without modification, it can potentially create a conflict because you have defined INSTALL_SOURCE in both env.default and in the Docker command options. This could lead to unexpected issues as Docker will take the value specified in the Docker command options (in this case, /install) rather than the one defined in env.default.
what do you think of it?
Thanks in advance,
Ernest.
The text was updated successfully, but these errors were encountered: