Hey all,

tl;dr ‘-conf' suffix for packages that come with a default
configuration (e.g. openssh-conf, nginx-conf, etc.)

## How It Works
This would segment the configuration files of a base package with a
‘-conf’ suffix package name just as the ‘-doc’ suffix provides. In the
process of creating a package/port just as ‘-doc’ is automatically
created with abuild by checking for files in ‘/usr/share/man/‘ created
by the build process of the package, ‘-conf’ would be auto-created by
checking files in ‘/etc/‘. Along with the ‘docs’ trigger package which
would automatically install the ‘-doc’ suffix package of desired
installed package a ‘confs’ trigger would auto install the ‘-conf’
suffix package of desired installed package.

## Reasons Why
This allows for a flexible and reliable means of configuration
management (i.e. at least for the configuration of system & daemon
configurations). Either a user/admin can use the system default
configuration packages that are provided by the package repositories,
use the configuration packages on ones private repository, not install
the configuration files for packages using configuration management
instead (e.g. ansible), or any combination of.

This would allow for users & admins to provide their own ‘-conf’
packages instead of having to build their own base package <pkgname>
only changing the configuration file, or having to build their own
<pkgname>-conf.  The issue with first option is that users would have
to manage official aports packages with each ‘pkgrel’ change with the
user’s own. The issue with the second option is that providing ones
own ‘<pkgname>-conf’ package would have to use the ‘replaces' &
‘replaces_priority’ in that packages APKBUILD file, which can result
in issues when the base package is upgraded.

## PROs
* Makes packages more fine grained
* Easy to build an manage ones own ‘-conf’ packages
* Custom ‘-conf’ packages doesn’t have ownership contentions with the
official packages
* Configuration management doesn’t have to violate the ownership of
  config files by not installing that packages ‘-conf’ sub package.
* can utilize apk-fix to verify configurations are not changed or
damaged

## CONs
* Possibly overly fine grained packages
* Adds bloat to packages (note: probably could be fixed with changes
  to abuild, apk, and apk file schema)
* other things (i’m missing)


## Existing Alternatives
I understand that there is also the alpine configuration framework,
however that seems to be applied better for a centrally administered
system(s).


Constructive thoughts, comments, and criticisms appreciated. Thank you
all for your time.

p.s. Finals over!

--
keybase.io/systmkor

Hey,

> tl;dr ‘-conf' suffix for packages that come with a default
> configuration (e.g. openssh-conf, nginx-conf, etc.)

i think thats an interresting idea. I am all for small and clean
packages. I think the problem with that is that most software today is
so bad that you cannot simply execute the binary and asume that it has
defaults in place that simply work. Sadly very often without huge
patched config files you cannot even get the service running.

Maybe we should go the other way around to clean up configs and
optimize the default configs to something secure, extendable and
usefull for all users and then ship them.

Greetings
Leo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Wed, 8 Jun 2016, systmkor wrote:

> The issue with the second option is that providing ones own 
> ‘<pkgname>-conf’ package would have to use the ‘replaces' & 
> ‘replaces_priority’ in that packages APKBUILD file, which can result in 
> issues when the base package is upgraded.

Could you please elaborate on the issues you have experienced? I have used 
such an approach without facing any obvious problems.

In addition, I wonder why one could not use configuration management tools 
when packages contain default configuration files. Pretty much all major 
Linux distributions include those in the main packages.

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Wed, Jun 08, 2016 at 10:38:38AM -0700, systmkor wrote:
>## Reasons Why
>This allows for a flexible and reliable means of configuration
>management (i.e. at least for the configuration of system & daemon
>configurations). Either a user/admin can use the system default
>configuration packages that are provided by the package repositories,
>use the configuration packages on ones private repository, not install
>the configuration files for packages using configuration management
>instead (e.g. ansible), or any combination of.
>
>This would allow for users & admins to provide their own ‘-conf’
>packages instead of having to build their own base package <pkgname>
>only changing the configuration file, or having to build their own
><pkgname>-conf.  The issue with first option is that users would have
>to manage official aports packages with each ‘pkgrel’ change with the
>user’s own. The issue with the second option is that providing ones
>own ‘<pkgname>-conf’ package would have to use the ‘replaces' &
>‘replaces_priority’ in that packages APKBUILD file, which can result
>in issues when the base package is upgraded.

At risk of sounding like a pooper, my gut feeling is that this goes
against some of the things I think Alpine Linux is all about:

a)
It would introduce a dependency between base package and conf package,
while Alpine Linux tries to minimize any dependency by design.

mysoftware will run without /usr/share/man/man7/mysoftware.gz <- no dependency
mysoftware will *not* run without /etc/mysoftware.conf <- evil dependency

b)
It violates the second "S" Commandment in the Holy Alpine Linux
Triptych, which is "Simple" (flanked, as you know, by Small and Secure).

c)
I just think software configuration management is outside the scope of conveyance.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---