How to handle conffiles in snaps?

[Simon Fels]

On 08.08.2016 22:06, Christian Ehrhardt wrote:
> Hi,
> I was wondering how conffiles should be handled with snapcraft / snaps in general.
> I understand that for a more "app" style application the configuration is mostly 
> via some kind of UI/ webserver and it can store that "locally" in it's data dir.
> 
> But for the common pattern of a server application with /etc/something.conf - 
> how is that supposed to be working for snaps?
> That scheme is quite common in the server application world, so I expect there 
> already was some thought or discussion, but my searches didn't find something good.
> Neither did my IRC request this afternoon so I thought it might be worth to 
> write to the list.
> 
> So in the .deb world one would have:
> 
>  1. a package owning the conffile, usually the one with the binary(ies) reading
>     the conffile
>  2. maintainer scripts to handle upgrade path with e.g. changed formats
>  3. a million guides out there in the web that refer to e.g. /etc/syslog.conf
>     with their explanation
>
> I wonder how that should be handled when snapping such an app:
> 
>  1. ok, it can belong to a snap that has the binaries consuming it.
>     It gets a bit weird if there are multiple snaps bundling the same binaries
>     thou (relatively rare I hope as libs don't have that much conf)
>  2. is there an active element in http://snapcraft.io/docs/core/updates that I
>     missed
>  3. a new /etc interface being read-only for the snap? - maybe with
>     interface-parms defining which files should be accessible?
>     Yet how would the snap make the snap the available in /etc oon install?

All configuration files have to live within the snap itself. There is no
sharing with others unless you use something like the content interface
which allows sharing of content between multiple snaps. For upgrades
there will be a hook at some point in the near future which will notify
when your snap is upgraded and you can perform similar logic like you
can do in the maintainer scripts to handle changed formts etc. But as
far as I know there will be no modifications to the real /etc allowed
for any application snap.

You could still store conf files in SNAP_USER_DATA to get them writable
by the users of the system.

> The only snap-centric artifact about it I found was [1]. But that feels 
> broken/outdated as there is no "snappy" command anymore (and snap has no 
> "config" subcommand).

Something similar will come back. From what I've heard there will be a
apply-config hook which you can implement in your snap and a user can
call from the outside with a simple 'snap set
snap.name.confkey=confvalue' or similar.

If you don't want to wait for that you could hack something for the
moment by adding a simple app to your snap which writes configuration
files in SNAP_DATA/SNAP_USER_DATA and can be called by the user with
"<your snap name>.config <key> <value>" and switch to the hook once it
landed.

I hope that helps a bit.

regards,
Simon