# Script Management across multiple servers

## PsychoMonkey

Here is my plight.

I am responsible for maintaining a number of Gentoo servers (20+). There are a number of bash scripts which are in use, everything from daily emerge reports to disk alerts to backups. The problem is that if I need to make a change to the script, I have to edit the file on 20+ servers and it starts to become unmanageable. Also, when new servers are added, it gets to be difficult keeping track of scripts that need to be added to the new box.

I'm looking for any suggestions/advice on a good way to manage these scripts a little better. Are there any applications which are good for handling this type of problem? I had thought about putting the scripts on a Wiki or perhaps setting up Subversion or Git to keep the scripts, but I wanted to explore all suggestions first. It would be great if there were something that could be edited once and pushed to many. Maybe its just a dream.

Any help would be greatly appreciated.

Thanks in advance.

----------

## avx

Well, easiest way would possibly be to share the scripts via NFS. Git/SVN would have the benefit of a simple roll-back, so these two things could be combined. Depending on what exactly your scripts are supposed to do, maybe a more 'universal' approach like clusterssh could/would be a nice solution.

----------

## Hu

Are the scripts customized to the hosts in any way, such as using different paths or other strings depending on which host is involved?  If deployment only involves copying the exact same file to every server, then management is easier than if you need to give each server a script that is mostly the same as its peers.  This can affect the decision of exactly how to store and distribute the master copies.

----------

## PsychoMonkey

The majority of the scripts are not server specific. I can handle a few one off scripts here and there.

Right now, the scripts, for the most part, are installed on each server in the same location. If I can find a good solution to managing these scripts, I intend to standardize location and cron setup. My intention is to get things tightened up.

I was thinking that the scripts could possibly be stored on a central server and then disseminated down to each other server. I would like it if I could edit them on the main system, then push/pull to the others.

----------

## molot

The ones that are just the same may easily be stored on central server and mounted using NFS, like already suggested.

If you want manual push / pull, then you have 2 options.

1) 2 directories on main script server. One for scripts you edit and test, and other NFS shared. Then all the pushing is just local cp / rsync

2) simple script wrapping around rsync, scp, git, svn or anything (in order I would use) to propagate the changes.

The setup I would use is:

1) directory for testing scripts - versioned under git or svn

2) directory for stable script that are permitted to fail if network connection is broken, but changes should be immediate - those would be shared by nfs mounting

3) directory for scripts that must be on client boxes even if network is down or faulty, but changes may wait - those would be rsynced to the client boxes when changed (and maybe in midnight cron), and stored locally.

4) each host would contain own, not automatically managed piece of script with custom variables, sourced by the scripts that are host-dependent.

Describe your setup and it's performance  :Smile: 

----------

## AngelKnight

Without more details about how you intend to grow the environment it's difficult to provide a recommendation.  Any of the ones provided above may work.  But if your environment is going to grow larger, you may wish to consider managing those scripts themselves as ebuilds, or a packaged configuration manager like cfengine or puppet.

----------

## kashani

Have you considered something like Puppet? I use it to manage my environment. It handles everything from installing the base software, managing crons, and pushing files. 

Here's an example of a cron statement. I'm leaving out a lot of scaffolding code and support classes, but you get the idea. It's a central server that my other servers check into to get their config which they then apply.

```

class slice_servers::cron {

  cron { "slice_tmp_clean":

    command => "find /home/slice/tmp/ -mmin +30 -type f -print | xargs rm",

    minute => [10, 40],

    user => slice,

  }

}

```

kashani

----------

## PsychoMonkey

Thanks everyone for the suggestions.

Kashani, I have heard for puppet and tried it awhile back, but don't think I gave it a fair chance. I think I will look into it again.

----------

## kashani

Puppet has a pretty steep learning curve and a lot of the module code out in the wild is often trivial, broken, or way too complex to understand. It's still going to take you months to wrap your head completely around it, but you do useful things pretty quickly. I'd recommend keeping it simple and adding slowly as you understand more of what you're doing. I did find the modules on this site to be the most useful. http://www.example42.com/puppet/browsemodules.php The params stuff looks really complex, but it's actually much simpler than the alternative which is hardcoding or managing lots of variables. 

PM me if you decide to go down the Puppet route and I can give you some configs to get you going. I do recommend using 2.6.x which is keyword'ed.

kashani

----------

