Think about a solution for adding external dependencies into the Nextcloud container

[szaimen]

E.g. for https://github.com/nextcloud/all-in-one/discussions/751 and https://github.com/nextcloud/all-in-one/discussions/1159

[Zoey2936]

I see there currently four option for this, which could work (but no option of them is perfect)

1. Directly run the container as root
2. Run the container as root and switch inside the entrypoint to a non root user
3. Try to use docker exec --user root from the mastercontainer
4. Use su-exec - but then every user can exec commands as root using su-exec root:root <command> inside the container

RUN set -ex; \
    apk add --no-cache su-exec; \
    chmod u+s /sbin/su-exec

[szaimen]

Thanks for the input! Agree, no of them is perfrect unfortunately...

[szaimen]

@Zoey2936 What do you think about https://github.com/nextcloud/all-in-one/tree/enh/1162/allow-to-add-dependencies#how-to-install-external-dependencies-into-the-nextcloud-container-permanently?

[Zoey2936]

I think it should work, but how do you want to check that the container first starts, when the apks are installed? (Because the entrypoint doesn't know if there will be deps installed or not) Or that it only installs packages one time and not every five minutes?

[szaimen]

Simple: we create a file that the install_dependencies script checks for and crwates after running the first time. If the file is there we exit directly

[Zoey2936]

And how do you want to handle the first point? (That the entrypoint first continues if the packages are installed?)

[szaimen]

The entrypoint then checks for this as well...

[szaimen]

I will think about the exact implementation details later but good to hear that you think it would work!

[Zoey2936]

The entrypoint then checks for this as well...

So again: If the deps are successfully installed, it created a file. If the file exists and cron gets executed again, it will exit. And the entrypoint will only continue if this file exists.

1. But what if the file will never be created, because the user don't want to install additional deps, what will the entrypoint then do? Because if it waits at least five minutes this could be annoying, also the installation of the packages could take longer than five minutes.
2. Or what will the entrypoint do if the installation of the deps aren't installed successfully? (This could also be done using a lock file or something like this)

I know it is still WIP, but I don't understand how at least the first question can be resolved with the current logic of this implementation? Or did I misunderstand the logic?

[szaimen]

• But what if the file will never be created, because the user don't want to install additional deps, what will the entrypoint then do? Because if it waits at least five minutes this could be annoying,

I guess we need to create a file in a persistant storage somewhere after running thr scripr successfully one time. If that is present we trigger the logic. If not we dont.

also the installation of the packages could take longer than five minutes.

We need two files for that: one that is created while we install the dependencies and removed adter it is succeasful. The other one gets created when it was successful. Then entrypoint checks if the successful file is there and waits for that max 5min but waits indefinitely when the install file is present.

• Or what will the entrypoint do if the installation of the deps aren't installed successfully? (This could also be done using a lock file or something like this)

Then waiting max 5min for the succeed file should let it continue as the install file is not present...

[Zoey2936]

But would it not be better that the ADDITIONAL_APKS env gets already specified on the creation of the nextcloud container (so it gets specified as a mastercontainer env or on the aio panel), so that the entrypoint knows if it needs to wait for the installation or can skip the waiting?

[szaimen]

This would be easier from an implementation side. However I'd like to leave the logic completely out of the mastercontainer because you then do not need to recreate the mastercontainer all the time that you want to change additional dependencies. Also this makes it easier to maintain if the logic for all of this is only in one container.