Consider a three-tier configuration system #3

New Issue

import_bot · 2018-01-05T05:33:25Z

import_bot commented

2018-01-05 05:33:25 +00:00

It would be useful if borgmatic supported (3) tiers of configuration files.

the defaults, hard coded into the program
/etc/borgmatic/config (system wide settings)
~/.borgmatic.conf (user specific settings)

That would provide a bit of flexibility so that the "postgres" user can do it's own "borgmatic" backups, without needing to be configured by the root user.

Down the road, maybe there are "job-specific" settings files under ~/.borgmatic.d/*.job

That way you could backup different parts of the system with different borgmatic settings.

Imported from Taiga issue 2 (to do). Created on 2015-07-26T14:08:10+0000 by Thomas Harold.

It would be useful if borgmatic supported (3) tiers of configuration files. 1. the defaults, hard coded into the program 2. /etc/borgmatic/config (system wide settings) 3. ~/.borgmatic.conf (user specific settings) That would provide a bit of flexibility so that the "postgres" user can do it's own "borgmatic" backups, without needing to be configured by the root user. Down the road, maybe there are "job-specific" settings files under ~/.borgmatic.d/*.job That way you could backup different parts of the system with different borgmatic settings. --- Imported from Taiga issue 2 (to do). Created on 2015-07-26T14:08:10+0000 by Thomas Harold.

import_bot commented

2018-01-05 05:33:25 +00:00

This would require some config file merging/overriding logic, but that shouldn't be too hard given the current approach with treating parsed config file contents as data blobs.

Comment on 2015-07-26T15:11:55+0000 by Dan Helfman.

This would require some config file merging/overriding logic, but that shouldn't be too hard given the current approach with treating parsed config file contents as data blobs. --- Comment on 2015-07-26T15:11:55+0000 by Dan Helfman.

import_bot commented

2018-01-05 05:33:25 +00:00

Actually, thinking about this a little more, config value merging/overriding may not be necessary or desirable. It may be better to have overriding work at the whole-config-file granularity. So for instance if a ~/.borgmatic.conf exists, then that file would be used for all settings and /etc/borgmatic/config wouldn't be read at all.

Thoughts? How do most other programs do it?

Comment on 2015-07-30T02:52:28+0000 by Dan Helfman.

Actually, thinking about this a little more, config value merging/overriding may not be necessary or desirable. It may be better to have overriding work at the whole-config-file granularity. So for instance if a ~/.borgmatic.conf exists, then that file would be used for all settings and /etc/borgmatic/config wouldn't be read at all. Thoughts? How do most other programs do it? --- Comment on 2015-07-30T02:52:28+0000 by Dan Helfman.

import_bot commented

2018-01-05 05:33:26 +00:00

Speaking as a sys-admin:

There are definitely some settings that would be best to be defined at a
global level such as the following. That way I could set them once at the
server level and not have to re-specify them at the per-user or per-job
level.

mail server
mail server port
alert mailing list
sender address
sender account name
sender password
email alert prefix string (if something other then the hostname is
desired)
last-N setting for borg
what verifications to do

Any or all of those could then be overridden at the user level (i.e. the
'postgres' user which backups the postgresql databases). i.e. issues with
backing up using the postgres user might want to alert a different set of
admins that the backups failed. And for a personal user like 'jsmith', who
is running personal borgmatic backups, those alerts should go to
jsmith@somewhereelse.

I might define a global Last-N of 10, but then decide that the backups done
while logged in as the postgres user should be checked with a Last-N of 25.

Or a specific backup which is really critical, might need a Last-N of 50.

Mostly it gives flexibility. But if Cronmatic will handle all the email
issues, then that just leaves smaller (and much fewer) settings like Last-N
and which verifications to do. So it does become less important because
I'm only re-defining a handful (no more then 4) variables at the per-user
or per-job level instead of a dozen or more.

Comment on 2015-08-03T10:44:18+0000 by Thomas Harold.

Speaking as a sys-admin: There are definitely some settings that would be best to be defined at a global level such as the following. That way I could set them once at the server level and not have to re-specify them at the per-user or per-job level. - mail server - mail server port - alert mailing list - sender address - sender account name - sender password - email alert prefix string (if something other then the hostname is desired) - last-N setting for borg - what verifications to do Any or all of those could then be overridden at the user level (i.e. the 'postgres' user which backups the postgresql databases). i.e. issues with backing up using the postgres user might want to alert a different set of admins that the backups failed. And for a personal user like 'jsmith', who is running personal borgmatic backups, those alerts should go to jsmith@somewhereelse. I might define a global Last-N of 10, but then decide that the backups done while logged in as the postgres user should be checked with a Last-N of 25. Or a specific backup which is really critical, might need a Last-N of 50. Mostly it gives flexibility. But if Cronmatic will handle all the email issues, then that just leaves smaller (and much fewer) settings like Last-N and which verifications to do. So it does become less important because I'm only re-defining a handful (no more then 4) variables at the per-user or per-job level instead of a dozen or more. --- Comment on 2015-08-03T10:44:18+0000 by Thomas Harold.

import_bot commented

2018-01-05 05:33:26 +00:00

While this ticket isn't implemented, I'll note that /etc/borgmatic.d/ is now supported. Additionally, you can provide a list of configuration files or directories on the borgmatic command-line, and they'll all be run in succession.

Comment on 2017-07-30T18:24:38+0000 by Dan Helfman.

While this ticket isn't implemented, I'll note that /etc/borgmatic.d/ is now supported. Additionally, you can provide a list of configuration files or directories on the borgmatic command-line, and they'll all be run in succession. --- Comment on 2017-07-30T18:24:38+0000 by Dan Helfman.

witten commented

2019-03-06 18:42:48 +00:00

I'm closing this in favor of #148. Once implemented, that would allow you to set up your own means of configuration file merging and reuse.

witten closed this issue

2019-03-06 18:42:48 +00:00

witten referenced this issue

2020-01-09 19:12:31 +00:00

New command option to log information about executed task at verbosity 0 #272

pikeas referenced this issue

2022-06-30 21:10:43 +00:00

Misc new user feedback #554

HippieBeak referenced this issue