Differences between revisions 4 and 16 (spanning 12 versions)
Revision 4 as of 2004-05-16 09:00:42
Size: 850
Editor: anonymous
Comment:
Revision 16 as of 2013-12-07 23:05:07
Size: 3881
Comment: fix typos
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
The standard way configuration data is kept in unices is by various different config files under the /etc directory. #language en
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~
----
Line 4: Line 6:
This mix of different textformats is unlikely to change given various pros and cons. The ''standard way'' system wide configuration data is kept in unices is by various different config files under the /etc directory.
Line 6: Line 8:
With the config4gnu config representation and manipulation framework in debian however the cons can be eliminated and new possibilities arise. This mix of different text formats is unlikely to change given various pros and cons.
Line 8: Line 10:
Full flexibility and authority of /etc is maintainted. Flexibility is even increased, a API and several frondends (comandline, GUI etc.) to all config files and formats are provided without hardcoded specifics! With the ''config4gnu'' config representation and manipulation framework in debian, however, the cons can be eliminated and new possibilities arise. Full flexibility and authority of /etc is maintainted. Flexibility is even increased; an API and several front ends (command line, GUI, etc.) to all config files and formats are provided without hardcoded specifics.
Line 15: Line 17:
"Points of Integration config4gnu in debian"
(or better integrate debian into config4gnu ?)
:
"Points of Integration for config4gnu in debian":
Line 18: Line 19:
 * DebConf  * [[debconf]]
Line 21: Line 22:
 * DebianControlCenter


== Wishlist for "the perfect configuration modifier" ==

The configuration (modifier) system should...

- remove any need to manually copy customisations to new config files during upgrades or to alternatively not get updated config files.

- ease to (re)do/revisit config manipulation scripts with every new package
(update). (Today maintainer scripts need to provide the complete functionality
from parser, validation, ..., logic. Therefore incomplete sets of options and
"managed by debconf" (don't touch or loose debconf functionality) sections
are implemented.)


- provide system configs with cascading defaults:

Defaults with different config levels:

0. software defaults (compiled in, not saved in config files)

1. system settings (explicitly saved in /etc/*)

compiled from different sets of defaults

 - A. distro defaults (saved in some config system /usr/share/... dir)

 - B. customized defaults (Custom Debian Distributions) (/usr/share/...)

 - C. more customized defaults (Organisations etc.) (/var/share/...)

 - ...

and overridden by possible explicit (different) admin settings done in /etc (results in /etc/* to have an offset from the default resulting from A.B.C...)

2. settings for user groups (see debian package desktop-profiles)
  
3. user settings (explicitly saved in ~/.*)


- still allow all levels to be networked by importing /usr/bin, some /usr/share/...,
some /var/share/..., /etc and /home dirs respectively.


- frontends and backends separated from the core

- provide seamless adjustment of settings on every level for the frontends

- provide central reference settings and linking (to keep track of and update
multiple redundant occurrences in various places upon changes (i.e. hostname,
IPs etc.)

- be able to provide possible options/values, comments and help.

- separate config-system and config-system-configuration (fileformat/info
about the software it configures. According to workflow of package
maintainer, package-config-manipulator maintainer, config-system maintainer,
customisation-maintainer, etc.)

- not save config state outside of the configured software's original config
storage.

- understand the fileformat and not alter formatting when applying changes.

- have a modular config-system-configuration, so that it can be upgraded with
files that can be part of the software packages of the distributions or from
other sources.

- have the possibility to draw-in necessary packages if the user wants to
configure some not-installed functions. (interaction with package manager)






== Tracking Tools ==

If you want to keep track of your configuration changes, either for yourself or because you are administering a Debian box with someone else, have a look at the following packages:

 * changetrack (needs perl)
 * filetraq (shell)
 * diffmon

Translation(s): none


The standard way system wide configuration data is kept in unices is by various different config files under the /etc directory.

This mix of different text formats is unlikely to change given various pros and cons.

With the config4gnu config representation and manipulation framework in debian, however, the cons can be eliminated and new possibilities arise. Full flexibility and authority of /etc is maintainted. Flexibility is even increased; an API and several front ends (command line, GUI, etc.) to all config files and formats are provided without hardcoded specifics.

Meta-config definitions do the trick.

Check out the webpage: http://freedesktop.org/Software/CFG

"Points of Integration for config4gnu in debian":

Wishlist for "the perfect configuration modifier"

The configuration (modifier) system should...

- remove any need to manually copy customisations to new config files during upgrades or to alternatively not get updated config files.

- ease to (re)do/revisit config manipulation scripts with every new package (update). (Today maintainer scripts need to provide the complete functionality from parser, validation, ..., logic. Therefore incomplete sets of options and "managed by debconf" (don't touch or loose debconf functionality) sections are implemented.)

- provide system configs with cascading defaults:

Defaults with different config levels:

0. software defaults (compiled in, not saved in config files)

1. system settings (explicitly saved in /etc/*)

compiled from different sets of defaults

  • - A. distro defaults (saved in some config system /usr/share/... dir) - B. customized defaults (Custom Debian Distributions) (/usr/share/...) - C. more customized defaults (Organisations etc.) (/var/share/...) - ...

and overridden by possible explicit (different) admin settings done in /etc (results in /etc/* to have an offset from the default resulting from A.B.C...)

2. settings for user groups (see debian package desktop-profiles)

3. user settings (explicitly saved in ~/.*)

- still allow all levels to be networked by importing /usr/bin, some /usr/share/..., some /var/share/..., /etc and /home dirs respectively.

- frontends and backends separated from the core

- provide seamless adjustment of settings on every level for the frontends

- provide central reference settings and linking (to keep track of and update multiple redundant occurrences in various places upon changes (i.e. hostname, IPs etc.)

- be able to provide possible options/values, comments and help.

- separate config-system and config-system-configuration (fileformat/info about the software it configures. According to workflow of package maintainer, package-config-manipulator maintainer, config-system maintainer, customisation-maintainer, etc.)

- not save config state outside of the configured software's original config storage.

- understand the fileformat and not alter formatting when applying changes.

- have a modular config-system-configuration, so that it can be upgraded with files that can be part of the software packages of the distributions or from other sources.

- have the possibility to draw-in necessary packages if the user wants to configure some not-installed functions. (interaction with package manager)

Tracking Tools

If you want to keep track of your configuration changes, either for yourself or because you are administering a Debian box with someone else, have a look at the following packages:

  • changetrack (needs perl)
  • filetraq (shell)
  • diffmon