Open descriptions and defaults for environment variables

[mmattel]

This is a list of all extension where defaults and decriptions are missing. Note that for some elements, the content is most likely the same over many extensions like logging or tracing or JWT token info. In any case, this MUST be filled in each extension with the same text - if this is the case. Note that also default is a field that must be populated!

Description texts should start with a capital letter. In case existing descriptions start in lower case - change them.

The users extensions has good texts for descriptions of the tracing stuff (defaults are missing tough).

Regarding the questions, for sure I did not catched them all, but you may see the pattern.

Pls add me in cc to each PR created so I can monitor the changes to trigger the documentation update.

@micbar @wkloucek @butonic pls assign responsibles to extensions by editing the issue. Self assignment of volunteers is welcomed too 😃

• App Provider ✅
• App Registry ✅
• Audit ✅
• Auth Basic ✅
• Auth Bearer ✅
• Auth Machine ✅
• Frontend
  FRONTEND_CHECKSUMS_SUPPORTED_TYPES missing type
• Gateway ✅
• Graph ✅
• Graph Explorer ✅
• Groups ✅
• IDM ✅
• IDP ✅
• NATS ✅
• Notifications ✅
• OCDAV ✅
• OCS ✅
• Proxy ✅
• Search ✅
• Settings ✅
• Sharing ✅
• Storage-Publiclink ✅
• Storage-Shares ✅
• Storage-System ✅
  Questions:
• Storage-Users ✅
• Store ✅
• Thumbnails
  THUMBNAILS_RESOLUTIONS missing type
• Users ✅
• Web ✅
• WebDAV ✅

@EParzefall FYI

[dragonchaser]

Classified as bug, blocks docs-team!

[wkloucek]

@mmattel there are multiple questions about path for different packaging formats / release artifacts. They are valid, since the current configuration documentation doesn't reflect these differences at all.

In the current documentation we have a lot of default values for paths beginning with ~/.ocis. These paths are all dependent on the packaging / release artifacts:

• for binaries released on our download mirror and GitHub releases, ~/.ocis from documentation equals ~/.ocis as base data path in the oCIS binary. (the base config path is ~/.ocis/config
• for our docker images (containing a oCIS binary) released on dockerhub, ~/.ocis from the documentation equals /var/lib/ocis as base data path in the oCIS binary. (the base config path is /etc/ocis)

As of now, there are no other packaging formats / release artifacts.

So the current documentation only covers binary releases.

I could offer that we print something like this in our documentation:

<packaging dependent base path>/...

For example NATS_NATS_STORE_DIR would have the default value <packaging dependent base path>/nats

We could also go with /<oCIS data root>/.... If you have a better proposal, please let me know

[mmattel]

Colleagues, I have updated the services listed in the comment on top with regards of open items based on the recent env merges. Only a view left, we are close to final 😃

[wkloucek]

@mmattel are your ... is there a difference when using binary vs container? questions answered?

[mmattel]

@mmattel are your ... is there a difference when using binary vs container? questions answered?

No, because it can be (or is) that the path differs when you either have a binary install or when using container. Where, as far I understand, need to map, if neccessary, the path inside the container to a OS filesystem path. If that is not known, how should an admin map it properly

Generally speaking, when defining a path for a env that requires it, where does the base of the path point to when inside a container that further can be mapped to an OS path. While this is more or less obvious when using a binary install, it is not when using a container.

As this question comes up in reality on many places, the question can be answered and documented generically. This would of course ease the stuff a lot.

[mmattel]

Update: after a discussion with @butonic, when having a container and with all env's where you define a filesystem path, that path is INSIDE the container and must be made available to the OS if you want to keep data persistent. I will update the documentation accordingly.