Setup: Improve compose.yaml inline documentation

[rob-miller]

Please comment docker-compose.yml that the MARIADB_PASSWORD must be the same as MARIADB_ROOT_PASSWORD to address/avoid #1173.

Also, PHOTOPRISM_INIT comments could be updated along with the relevant docs at (https://docs.photoprism.app/getting-started/config-options/). Not really clear what update, https, davfs, clitools or clean do, though https and perhaps update seem desirable for most users? (Don't most browsers enforce https now?)

The intel/nvidia INIT options are not listed although they are specified in (https://docs.photoprism.app/getting-started/advanced/transcoding/), where it says either "leave it" or "just tensorflow".

Some other humble suggestions while tweaking the default docker-compose.yml comments:

• For PHOTOPRISM_INIT the wording "Run/install on first startup" implies to my naive reading that I need to comment it out after the first startup (which is not the case).
• the line for volumes

# "/host/folder:/photoprism/folder" # Example

might be better described as # Format example ?

Thank you.

[lastzero]

Why must MARIADB_PASSWORD be the same as MARIADB_ROOT_PASSWORD? I don't see why that would change a thing if photoprism doesn't connect as root? And if it does connect as root then why would the other password be important?

The init options have been added for advanced users and shouldn't not need to be added / changed if unsure what exactly they do.

[rob-miller]

Please see the linked #1173, because initial start does not work if they are the same. After that, just changing to be the same does not help - have to completely wipe the db/container and start again. It seems likely that new (or any) users will want the best performance possible, so it would be at least nice to know what the INIT options do.

…

On Sat, 3 Feb 2024 at 16:51, Michael Mayer ***@***.***> wrote: Why must MARIADB_PASSWORD be the same as MARIADB_ROOT_PASSWORD? I don't see why that would change a thing if photoprism doesn't connect as root? And if it does connect as root then why would the other password be important? The init options have been added for advanced users and shouldn't not need to be added / changed if unsure what exactly they do. — Reply to this email directly, view it on GitHub <#4051 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZW3QF6SUWLJVYF35BG52DYR2PL3AVCNFSM6AAAAABCYJAAV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGQ2TEMRZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lastzero]

Maybe you mean the same as the PHOTOPRISM DATABASE PASSWORD? The root and user passwords are the same in all our (test) environments for years and not once did we have any issues with it. Unless you plan to make the database instance available over a public network, there's also no reason to change the password. If you do then of course the passwords configured to access the database must be the same as the one configured in the database as otherwise the credentials do not match.

[rob-miller]

Ooops, yes, indeed MARIADB_PASSWORD matching PHOTOPRISM_DATABASE_PASSWORD is the now obvious issue which I did not detect when scanning for the solution to the error messages in #1173. I am sorry for the erroneous noise, and I understand that you are limited by the required parameters for the other (MARIADB) containers.

Nonetheless, I've made same mistake twice over three months and this highlights that the default docker-compose.yml could be better commented. The version 3.5 on Github already looks better, and has features that would have been better for me to start from than the instructed wget https://dl.photoprism.app/docker/docker-compose.yml.

• When presented with user and root password settings I will by default set them to different values, as the initial setting is insecure and there must be some reason I'm given the option to set them differently. Already much better to to have everything as photoprism in the current Github version. A comment/reminder that the user/pass settings must match the settings above may seem obvious but it doesn't hurt. Better yet, could the MARIADB settings use values like $(PHOTOPRISM_DATABASE_PASSWORD) (ref here and here) to make it more obvious and unlikely to be changed?

• The lines

## Run/install on first startup (options: update https gpu tensorflow davfs clitools clean):
# PHOTOPRISM_INIT: "https gpu tensorflow"

have problems. intel and nvidia are additional unlisted options, so out of date. My 'user' thoughts: Is the commented defintion the default? I don't have a separate GPU so should change and uncomment if so. Surely I want https and tensorflow as they are not disabled in the lines above? Only intel and nvidia are actually explained in the documentation that I could find. Can I change these after the container is built? Doesn't seem like it, so better get them correct to start.

• It seems like from https://docs.photoprism.app/getting-started/config-options/ that there are many options listed that are not present in the file from wget https://dl.photoprism.app/docker/docker-compose.yml. As you say only 'advanced users' should be tweaking PHOTOPRISM_INIT, it seems like the vast majority of users will not want to change (DISABLE_) CHOWN, TENSORFLOW, EXPERIMENTAL, WEBDAV, etc. so they could be left for users to add as needed from reading the documentation?

I really, really don't mean to come across as complaining. I've bought hardware specifically to run Photoprism, I did a complete practice install in November and now I'm restarting with my underlying library (500K photos) having the structure I want now that I have a better understanding. My point is that the recommended starting path gets very confusing and frustrating when the first step is to edit the file from wget https://dl.photoprism.app/docker/docker-compose.yml, with the implication being that choices made can't be changed after the container is created.

[lastzero]

Information of the mariadb configuration can be found in our Getting Started guide:
https://docs.photoprism.app/getting-started/docker-compose/#database

Bottom line is that you generally don't need to touch any of this unless you intentionally make the database accessible over a network or use a shared database instance, which does not apply to the majority of users. Those who do generally should be expected enough to know what they are doing.

[rob-miller]

Agreed, I am only suggesting to make it easier to know what to change, what not to change, and what the effects will be. I've made my suggestions and noted what I found to be missing or misleading above.