Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
How do you handle package updates with a configuration manag
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Mike81
n00b
n00b


Joined: 05 Jan 2011
Posts: 39

PostPosted: Tue Oct 29, 2013 10:46 am    Post subject: How do you handle package updates with a configuration manag Reply with quote

Hello,

how do you handle package updates with configuration management tools like puppet?

It's easy to install new software with a configuration management tool. With the installation directive you would also make sure, that your configuration files will be deployed.
But when you update an existing package, how do you handle stuff like update configurations? I mean you cannot run "etc-update".

CONFIG_PROTECT will make sure that any existing configuration won't be touched, but
  • how do you update configuration
  • is there a way to prevent the creation of ._cfg* files or how do you get rid of them


Or don't you do normal "updates", instead you write your directives to install a specific version. Whenever you want to install an update, you would update that directive. This way would ensure that the cm tool will always check the configuration (but you would still collect ._cfg* files, wouldn't you?)...
Back to top
View user's profile Send private message
Roman_Gruber
Advocate
Advocate


Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria

PostPosted: Sun Nov 10, 2013 11:59 pm    Post subject: Reply with quote

Not sure.

But one way is etc-update.

Config files are always manually administration in my gnu-linux world, but there is a standard configuration, which can be used when you run etc-update manually and hit the 5 option.
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Mon Nov 11, 2013 12:27 am    Post subject: Reply with quote

If you're using a tool like puppet, then you're probably pushing out config files through puppet. You have the option of specifying that a package should be a specific version, the latest version, or merely installed without regard to version. I've seen a couple strategies.

  1. lock a package to a version in puppet and update it manually, changing the config files as necessary, and translate those changes back to puppet. Not that useful for multi machine deployments.
  2. Have a testing box where you update a package and test out any configuration changes, then put those changes into puppet, where they will be pushed out to your machines.
  3. Specify latest and hope for the best.


Either way, you'll probably want to use CONFIG_PROTECT_MASK to exclude the current contents of CONFIG_PROTECT.
Back to top
View user's profile Send private message
Mike81
n00b
n00b


Joined: 05 Jan 2011
Posts: 39

PostPosted: Mon Nov 11, 2013 12:46 am    Post subject: Reply with quote

tw04l124 wrote:
Not sure.

But one way is etc-update.

Config files are always manually administration in my gnu-linux world, but there is a standard configuration, which can be used when you run etc-update manually and hit the 5 option.
etc-update is not an option, because it is interactive, isn't it? If you have >10 clients you cannot run this command manully on all systems.

gotyaoi wrote:
If you're using a tool like puppet, then you're probably pushing out config files through puppet. You have the option of specifying that a package should be a specific version, the latest version, or merely installed without regard to version. I've seen a couple strategies.

  1. lock a package to a version in puppet and update it manually, changing the config files as necessary, and translate those changes back to puppet. Not that useful for multi machine deployments.
  2. Have a testing box where you update a package and test out any configuration changes, then put those changes into puppet, where they will be pushed out to your machines.
  3. Specify latest and hope for the best.


Either way, you'll probably want to use CONFIG_PROTECT_MASK to exclude the current contents of CONFIG_PROTECT.
Wait, currently "/etc" for example is in CONFIG_PROTECT, so any changes in /etc, which cannot be automerged (depends on my etc-update/dispatch-conf settings) have to be merged with dispatch-conf/etc-update, right? So you are saying I should move /etc to CONFIG_PROTECT_MASK? This way, emerge would replace any existing configuration when updating a package, right? This could work, when I would (re-)deploy my configuration right after the update... but I am not sure if it would be safer to go with the ._cfg* files and clean them out from time to time...
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Mon Nov 11, 2013 1:15 am    Post subject: Reply with quote

Up to you, I suppose.

My thinking is that emerge may replace the config files, but if you've got the ordering in puppet such that the service definition requires both the package definition and the config definition (and perhaps the config definition requiring the package definition), puppet would always make sure that the config file was as specified before.

On the other hand, you could just use a tidy resource in puppet to clean up the ._cfg* files.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum