Le 01/02/2017 à 15:48, Michael Hall a écrit : > On a related note, does anybody have a suggestion on a lightweight way > of programmatically modifying configs in .ini, XML or JSON? > > I have a couple of use-cases (erlang-based nosql databases) where the > server updates the the local configuration, so I can't just overwrite > the whole thing every time. Didier's example will work for a very basic > key=value config file, but not something more structured, and I'd hate > to introduce Python, Perl or Java just for this.
That's exactly why I limited for now to simple key=value (and sourceable) files, while keeping comments and other formats (so .ini file should work if you scaffold it). I wanted to limit the hook to shell script to be architecture independant and not adding a dep on some runtime language. I don't know if it's sane to have more structured one in dash-compatible shell. Introducing helpers written in Go means that you have to compile your (potential arch-all snap like a nodejs webserver) to be arch-dependant. Thoughts? Didier > > > Michael Hall > mhall...@ubuntu.com > > On 02/01/2017 08:54 AM, Didier Roche wrote: >> Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit : >>> Yes, that's in the plans for configuration support already. The idea >>> is to extend snapctl with the ability to introspect exactly which >>> settings have changed since the last successful run of the script, and >>> perhaps which values it used to hold before. >>> >>> For the time being, I suggest not worrying much about that. Just go >>> ahead and implement the semantics you want the user of the snap to >>> experience. Inside the configure hook, check to see if the requested >>> value is already in place and do nothing in that case. This makes the >>> script idempotent, resilient because it ensures the desired state is >>> indeed in place, and also cheap to execute in the common case. >>> >> If someone is interested, I have implemented this kind of idempotent >> configure hook example. It can be found at >> https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure >> as part of the christmas snap demo. >> It features: >> - support key=value formatting >> - ignoring, but not erasing unknown keys, comment lines, empty ones. >> - preserving formatting and ordering, even when changing an existing key. >> - only snap set arguments will be modified if a value is set. If the >> value assigned to it is empty, removing the key line >> - new elements not present in existing configuration file are simply >> appended. >> >> Supporting new keys (like here "foo") is just a matter of adding: >> update_opt_in_config foo >> >> at the end of the file. >> >> I hope this helps! (note that the issue is still "what's the supported >> keys for this snap?") >> Cheers, >> Didier >> >>> >>> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert <o...@ubuntu.com >>> <mailto:o...@ubuntu.com>> wrote: >>> >>> hi, >>> >>> after we recently added a config hook [1] to the core snap it is now >>> possible to disable ssh if you require [2] ... >>> >>> there is a long standing request to do the same for syslog for systems >>> running from SD card, which is why i looked into trying to extend the >>> existing configure script for this, which made me notice some issue... >>> >>> when you call "snap set core foo=bar", there is no indication at all >>> for the script which variable changes a value, neither in the shell >>> environment nor in the argument list. >>> >>> the only way to get your value is to call snapctl for every existing >>> variable [3]. since you dont know what specific variable was requested >>> to change the only way to reliably write it is to write *all* existing >>> variables ... >>> >>> now, if you package something with a more complex config that you want >>> completely handled via snap config this gets ugly very fast... imagine >>> something like postfix with can potentially have 100s of config >>> options. instead of atomically changing a single option you will >>> regenerate the full config from scratch. this takes a lot longer, >>> bringing the risk of a completely broken config in case of a power >>> loss, beyond resulting an an awful config hook script with a large >>> block of "snapctl get" calls at the top. >>> >>> can we extend the config hook implementation minimally so a "snap set >>> core foo=bar" would at least have something like "SNAP_OPTION=foo" in >>> the environment that the generating script or binary could read to >>> avoid the unnecessary processing or would that break some design >>> concept ? >>> >>> ciao >>> oli >>> >>> [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ >>> hooks/configure >>> >>> <http://bazaar.launchpad.net/%7Esnappy-dev/core-snap/trunk/view/head:/%0Ahooks/configure> >>> [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref >>> erence/core-configuration.md >>> >>> <https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref%0Aerence/core-configuration.md> >>> [3] https://github.com/snapcore/snapd/wiki/hooks >>> <https://github.com/snapcore/snapd/wiki/hooks> >>> -- >>> Snapcraft mailing list >>> Snapcraft@lists.snapcraft.io <mailto:Snapcraft@lists.snapcraft.io> >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> <https://lists.ubuntu.com/mailman/listinfo/snapcraft> >>> >>> >>> >>> >>> -- >>> gustavo @ http://niemeyer.net >>> >>> >> >> -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
