Make app less depended on .env

[stavros-k]

Is your feature request related to a problem? Please describe.

Using that kind of flag to check if the setup is complete or not is making automated installs harder.

e.g. I'm maintain an app catalog (TrueCharts) based on helm charts for TrueNAS Scale. I'm in the process of adding this app on the said catalog. We aim to have apps with automated setup, which SETUP_COMPLETE, makes it a bit harder than usual.

So with this flag, after a user deploys the app and finish installation, the user must go change the flag to true in order to make installer not run again on next app startup. While this is easy on TN Scale as there is a GUI for all those, it's not "ok". As most users won't read any notices in the GUI. This will lead to bug reports to both our catalog and your repo.

I don't know how you handle an instance with initiallized db and setup_complete set to false, but if its not handled users might aswell lose data.!

Don't get me wrong, there are ways to get around that in Helm, like mounting a volume with the .env file inside with the SETUP_COMPLETE in there, so the app can modify it. But that feels "hacky".

I don't really know your app's codebase, but one thing I could recommend is to add a db entry when the init setup is run. and on each app startup check the DB for that entry. If it's missing, then the setup must run.

Describe the solution you'd like Get rid of the SETUP_COMPLETE flag.

Describe alternatives you've considered Write init scripts and init containers to detect if app has setup run and change env.

Additional context Add any other context or screenshots about the feature request here.

[stavros-k]

Also would be nice to be able to set a CRON Token via env variable, so in helm charts we can define a cronjob to hit the URL using the cron token we set.

Adding this, would be also nice to give a warning in the GUI that token is set with env var and should not be regenerated here, but changed in the env var.

[martadinata666]

So with this flag, after a user deploys the app and finish installation, the user must go change the flag to true in order to make installer not run again on next app startup. While this is easy on TN Scale as there is a GUI for all those, it's not "ok". As most users won't read any notices in the GUI. This will lead to bug reports to both our catalog and your repo.

I don't know how you handle an instance with initiallized db and setup_complete set to false, but if its not handled users might aswell lose data.!

So i tried and SETUP_COMPLETED=true after installation setup run, dunno how helm mount env things, seems it not overwriting SETUP_COMPLETE=false correctly.

[Kovah]

I will think about a proper way to at least remove the dependence on the SETUP_COMPLETED flag. It just has some serious security implications and can't be done with some easy fix.

Edit: Also, as mentioned by @gingerbeardman, it would make things easier if the app key would be generated too, so no manual steps are needed before running the setup in your browser.

[gingerbeardman]

Can .env be edited in the browser at first run? Just a thought.

[stavros-k]

In case of the setup flag, it would be as simple as creating the env file with flag set to false, if it doesn't exist already. Then the process can continue without problems. That's how I did it in my helm chart.

At least until the process is optimised more and be able to free itself from this flag.

-- For the following I'm not really sure as PHP is not my thing. But should work.

APP_KEY can be set as an env var, just make sure your key is set to 32chars and it's b64encoded.

[Kovah]

The best solution would be to make the app completely independent from manually handling the .env file, meaning that you neither have to provide it to start the container, and the container should start without any changes made to the file. Technically this is doable, but there are some things to consider when the user has no direct access to the file (because it's inside the Docker container):

• What if the user upgrades the container or moves it? What happens with the .env file which is filled with some custom configurations? Should the .env file be moved into a volume right from the start?
• The APP_KEY is crucial for encryption and user authentication. If it's lost, all encrypted data is lost and all passwords will cease to work. The user must backup the key in any case. But how is this done? Automatically?
• Also, how and when exactly is the APP_KEY generated? What happens if the user would like to move containers and provide its own APP_KEY?
• The setup must be updated to fully support setting up a database from the interface: MySQL and Postgres are a must, SQLite would be good. This adds a lot of complexity to the process.

As you see, a lot of things to think about and work on for the convenience of not handling one configuration file.

[gingerbeardman]

it's the task of good software design and development to take on these challenges to make the lives of your users easier.

I'm not making light of the challenges, or saying they are easy (they're not). But, that's the fun! 😁

How do others do it? Has this particular wheel already been invented?

[martadinata666]

Imho using .env is easy enough. Like every other web apps or apps config file. Docker wise, adding some environments bla2 mean additional script to translate container env to .env file. It doable make php to fetch container env and use it, and that will give more hassle than simplicy with .env file

[Kovah]

Release 1.10 of LinkAce will come with a heavily stripped down .env file. It contains only the bare minimum. The documentation will be expanded to cover settings for mail, backups and so on. The App Key is set to a generic string and will be replaced with a secure, random key the first time the generic one is detected. Also, I will try to remove the SETUP_COMPLETED variable to remove all manual editing of the .env file from the most basic setup process.

[Kovah]

The SETUP_COMPLETED variable was replaced by a database setting. As all system settings are cached across requests and only change if a setting was altered, so this was the easiest way. Version 1.10 will contain an automatic migration of the setting, so existing installations should continue work without issues.

I will mark the issues as completed with the release as for me this is totally fine. Removing the .env file completely would be too much hassle for me with no real advantage. However, Docker users are able to replace the .env file with Docker environment variables completely. See the docs for details.

[gingerbeardman]

Sadly this is still way more complicated than competitors (such as linkding, which I'm now using). But thanks for the effort to get it to this point.

[gingerbeardman]

Now that this is released I decided to give it a try, it was reasonably easy to get going with the instructions

But I get a 500 server error when trying to view the web interface #429