Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

Config File Project #37

Open
aidanbh opened this issue Jan 8, 2017 · 3 comments
Open

Config File Project #37

aidanbh opened this issue Jan 8, 2017 · 3 comments

Comments

@aidanbh
Copy link
Collaborator

aidanbh commented Jan 8, 2017

Goals: Make quickback Extensible, Versatile, and Configurable

Basic feature roadmap:

  • All command line options will still be fully supported, nothing will be "configfile only"
  • The master config file, shipped by default, will be located at /etc/quick-back.conf. This file shouldn't need to be edited by the user, but if it is, a .pacnew of distro-equivalent will be created by the PM on updates.
  • Additional config files should be looked for in the /etc/quick-back.d/ and read according to the number at the start of the file name, a la systemd
  • Finally, a config file named quick-back.conf may be placed in the root directory of the source filesystem/directory, a commandline option must be added to prevent security vulnerabilities if, say a root user (which we currently require) backed up home directories and a malicious user added a quickback.conf which ran commands as root as part of a conditional_.
  • As a overarching precedence, all commandline options have the final say. Additional config files should also be specifiable on the cmdline. The -nd, --nodefaults option should be rethought to make sense in this context.
  • No more defaults will be hardcoded into the program, except sanity checks. The behavior of the application beyond simple rsync execution will be specified in the default quick-back.conf file.

File format:

  • A standardized format (e. XML, YAML, Windows INI-style, etc. will be selected.
  • At a minimum, control directives shall be programmed such that it is possible to declare sections of a file applicable only to certain destinations, matched by regex. Controls shall also be available so that a custom command can be run, using variables such as $source, $dest, $runninguser, ... to make the script extensible as well as configurable.

Branch: all development will be done in the configfile branch of the main repo.
Milestone: v2.0

@PenguinSnail
Copy link
Owner

We should probably use YAML for the config file due to it being easier for people to read so it's easier for the end user to modify if necessary

@aidanbh
Copy link
Collaborator Author

aidanbh commented Jan 8, 2017 via email

@PenguinSnail
Copy link
Owner

PenguinSnail commented Jan 8, 2017

i have found these scripts and others have said they work
testing now
https://gist.github.com/pkuczynski/8665367

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants