On Mar 19, 10:11 am, Gamon <bruno.pessa...@gmail.com> wrote: > Thanks for all your answers and suggestions. > > So, what happens is that I want to push a file from the master to a > client. But the problem is that after starting the service that reads > that file, it appends one line to it, which is an authorization token.
It's pretty nasty for a service to routinely modify its own configuration files. Is there any way you can make it not do that? For instance, is there an option to make it put the authorization token in a separate file? Alternatively, perhaps the file you're trying to manage isn't well- characterized as a configuration file. In that case, perhaps you're trying to manage the wrong resource, and there might be a bona fide configuration file that would be a better target for your efforts. Or, similarly, perhaps you can *make* a separate file. For example, some config files can have an 'include' or similar directive that directs the program to read additional configuration from a separate file. In that case you could put all the lines you want to manage in that separate file, and in the main file ensure only that an appropriate 'include' is present. If none of those options are available, then perhaps you can switch to better software. (Though more likely not.) If the only avenue to your desired end is to accept the software's modifications to your managed file, then it is possible to achieve that. For a one-line addition that you can distinguish from the other lines of the file, I would suggest this approach: 1) Create a custom fact that that captures the authorization token line of the target file, if it's present. Distribute it via pluginsync. 2) Use the custom fact value to interpolate the authorization token line into your template for the file 3) Ensure that Puppet relationships are in place to prevent Puppet from starting the service before managing the file. I emphasize that that is a distinctly worse solution than any of the others I suggested. Aside from being messy, it contains a race condition: if the service is started or the authorization token is otherwise changed in the middle of a Puppet run (except by Puppet), then Puppet could still lose the token. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
