On Sunday, January 19, 2014 3:34:39 PM UTC-6, Erwin Bogaard wrote: > > Hi, > > I'm looking into a way to manage the SugarCRM config.php (see partial > example below this message). This proposes several problems: > 1. The file is full of arrays and arrays-in-arrays (So I think Augeas is > useless, as far as I understand it) > 2. Not all config.php's contain the same arrays and/or key-value > combinations. It's possible that in one config.php a certain arrays is > needed, while it isn't in another and that teh value of a certain key needs > to be different and is set from SugarCRM. So to summarize: I don't want to > manage every array and key/value in config.php. (So I think and > config.erb-template is out of the question) > 3. I could use exec with sed and for every array and key/value I need to > manage, but that would probably make it quite complex (if possible at all), > as I need to check for existance first, and depending on the outcome, add > the array or key/value or change the existing pair. > > The way I used to do this was manage config_override.php, in which you can > specify arrays and key/values which override the ones in config.php, with > an erb template. Problem with that, is that when you change something in > the SugarCRM-interface, it 's added/changed in config_override.php. Which > is then regularly overwritten by Puppet, so the change is reverted. > > Does anyone have a good suggestion to manage this file reliably and with > reasonable complexity with Puppet? >
Since it appears that the config file is a PHP script, can you insert into it code that runs another script to modify the $sugar_config before config_override.php does? You could then manage that new script via a Puppet template. That way, you don't need Augeas because the main target file can be managed completely by Puppet, while SugarCRM-interface can still apply changes that take precedence and are not automatically reverted by Puppet. Do consider, however, whether allowing Sugar's configuration to be managed both by Puppet and via an interactive user interface is wise. Can you instead make Puppet the single authoritative source for config changes? In that case -- the natural one for Puppet -- Puppet's behavior of killing changes made via the user interface is exactly what you want. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a109dee0-bffe-43f4-b65b-6bf765cb0043%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
