Motivation

As mentioned in discussion 901 when using (some) lldap instances with a read-only sqlite db (e.g. in order to maintain data integrity when "clustering" sqlite dbs while scaling out lldap instances) the log shows db errors from hourly clean-up jobs:

┝━ 🚨 [error]: DB error while cleaning up JWT refresh tokens: Execution Error: error returned from database: (code: 8) attempt to write a readonly database
┝━ 🚨 [error]: DB error while cleaning up JWT storage: Execution Error: error returned from database: (code: 8) attempt to write a readonly database
┕━ 🚨 [error]: DB error while cleaning up password reset tokens: Execution Error: error returned from database: (code: 8) attempt to write a readonly database

This is not a functional limitation of the software (the error message is correct, after all) and those clean-up jobs failing does not seem to have any negative effects.

(I should add that in my deployment I'm not exposing lldap's Web UI for the instances that are read-only, likewise no LDAP write requests should go there either. I.e., the only thing trying to write to the db here would be those clean-up jobs.
Filing this here mostly as potential slight improvement for what's likely an unusual edge case.)

Possible solution

Introducing a configuration setting or command line option to inform lldap that its database is supposed to be not writable might provide an opportunity to not run those clean-up jobs in the first place (since they'd never be able to achive anything), consequently also not producing these db errors.
(Or maybe it would only silence these errors and keep the jobs runnning?)

While less generic, maybe the fact that the db is not writable could also be derived by slightly improved parsing of the configured database_url: In case of sqlite I'm already including mode=ro there:

database_url = "sqlite:///litefs/fuse/users.db?mode=ro"

This latter approach would avoid having to introduce and maintain a new configuration setting or command line option, at the cost of a more "magic" approach, I suppose.