How to manage SugarCRM config.php with Puppet?

[Erwin Bogaard]

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?

-----
Example file (partial):
<?php
$sugar_config = array (
  'Reschedule' =>
  array (
    'version' => '2.0',
  ),
  'SAML_X509Cert' => '',
  'SAML_loginurl' => '',
  'addAjaxBannedModules' =>
  array (
    0 => 'AOS_Contracts',
    1 => 'AOS_Invoices',
    2 => 'AOS_Quotes',
    3 => 'AOS_PDF_Templates',
    4 => 'asol_Reports',
    5 => 'Accounts',
    6 => 'Contacts',
    7 => 'Leads',
    8 => 'Prospects',
  ),
  'admin_access_control' => false,
  'admin_export_only' => false,
  'aos' =>
  array (
    'version' => '5.3.2',
    'contracts' =>
    array (
      'renewalReminderPeriod' => '14',
    ),
    'lineItems' =>
    array (
      'totalTax' => false,
      'enableGroups' => true,
    ),
    'invoices' =>
    array (
      'initialNumber' => '1',
    ),
    'quotes' =>
    array (
      'initialNumber' => '1',
    ),
  ),
  'authenticationClass' => '',
  'cache_dir' => 'cache/',
  'calculate_response_time' => true,
...
...
);

[rendh...@gmail.com]

Hi

On 20 Jan 2014, at 7:34 am, Erwin Bogaard <erwin....@gmail.com> 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)

Using a template is the best way to manage it in my opinion.

If your dataset is that complex you would need to manage it for each individual node no matter which method you chose to utilise.

Using hiera will make that simple.

It’s not that tricky to generate entries in a template from an array.

It’s also not that tricky to use an inline_template to generate a variable.

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.

This is the worst idea in my opinion. Please don’t go down that path. Managing that by itself will be a nightmare.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e7c27236-f397-471e-b0ad-8e881e016a4b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erwin Bogaard]

Hi Pete,

thanks for your reply.
I thought I replied to you last night, but Google doesn't show it. So here it is again:

The difficulty with using a template, is that there are just too many exceptions between the instances. Some keys or arrays are exclusive to one or several, but not all, instances. Some values of keys are different, because a different version of a module is installed.
I can, as you suggest, partly overcome that by using inline templates, but that still just leaves too many other things to consider.

That's why Augeas (if I understand the principle behind that correctly), seemed the way to go. That way you can just add/remove/change configuration options, while leaving the rest of the config alone.
Problem is: it's only for key=value files.

Is there a workaround or maybe another solution to this?

Thanks

[Jose Luis Ledesma]

Disclaimer: i dont know if this is posible at all.

Augeas is able to parse XML, perhaps you can modify the php to load a xml, and use augeas to modify it.

I don't have experience with augeas+XML, so this may be just a nonsense :)

[Erwin Bogaard]

Sounds interesting. Checked it out, but it doesn't seem that SugarCRM's config.php supports xml.

[jcbollinger]

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

[Pete Brown]

On 21 January 2014 00:33, Erwin Bogaard <erwin....@gmail.com> wrote:
> Hi Pete,
>
> thanks for your reply.
> I thought I replied to you last night, but Google doesn't show it. So here
> it is again:
>
> The difficulty with using a template, is that there are just too many
> exceptions between the instances. Some keys or arrays are exclusive to one
> or several, but not all, instances. Some values of keys are different,
> because a different version of a module is installed.
> I can, as you suggest, partly overcome that by using inline templates, but
> that still just leaves too many other things to consider.

This is a perfect use case for hiera.
If you aren't using it I would suggest setting it up.
It will allow you to setup variables exactly how you describe above.

This will get you started.
http://docs.puppetlabs.com/hiera/1/

> https://groups.google.com/d/msgid/puppet-users/35c0287b-bcc0-4a1e-9ca7-bc975753da57%40googlegroups.com.

[jcbollinger]

On Tuesday, January 21, 2014 4:58:55 PM UTC-6, Pete wrote:

This is a perfect use case for hiera.
If you aren't using it I would suggest setting it up.
It will allow you to setup variables exactly how you describe above.

This will get you started.
http://docs.puppetlabs.com/hiera/1/

Indeed, hiera is just the ticket for feeding data to Puppet to inform it about details of each target node.  It's architecture is based on a priority hierarchy of data, so hiera makes it easy to, say, define a general base configuration, override some bits of that based on which group each node belongs to, and override the same or other bits on a per-node basis.  That could be perfect for populating a config file template.

If the OP insists that Puppet must avoid clobbering changes applied to nodes directly via Sugar's user interface, however, then that's not really a data problem.  Hiera cannot help with that part, unless by facilitating the removal of that requirement.


John

[Erwin Bogaard]

Thanks for your suggestions.
Hiera seemed the best solution, but it seems then you still have to manage the whole file. Not just parts.
When I have some more time, I'm going to dive in Hiera, as is seems to be a good solution to other 'challenges' I have (and have solved badly, right now).

For now, I'm going to investigate the pre_config_override.php-option. That's probably the best case for this situation.
And as this situation is quite unique, I don't necessarily have to find a general solution for this.