I have folder on Dropbox with global, per OS, and per machine shell configs:
$ ls ~/Dropbox/shell/bash
bashbootstrap bashrc
bashrc-Darwin bashrc-Darwin-laptopname bashrc-Darwin-mininame
bashrc-Linux bashrc-Linux-machineone bashrc-Linux-machinetwo
bashrc
is loaded on every machine, bashrc-Linux
, bashrc-Darwin
are loaded on their respective OSes, and several configs are specific to individual machines. (By the way, Darwin is the name of OS X's BSD-like kernel.)
What ties it all together is the bashbootstrap
file. It loads each applicable config file in order of increasing specificity, this allows per OS and per machine overrides to have higher precedence. Additionally, we silently skip missing config files; you need not create empty config files for each of your machines to keep the script happy.
On a new machine, after installing Dropbox on ~/Dropbox
, I move away the default .bashrc
and just symlink the bootstrap file in its place instead:
$ mv ~/.bashrc ~/.bashrc.bak
$ ln -s ~/Dropbox/shell/bash/bashbootstrap ~/.bashrc
Oh, and here are the contents of the bashbootstrap
file:
if [ -z "$PS1" ]; then
return
fi
dropboxshelldir=~/Dropbox/shell
dropboxdir=$dropboxshelldir/bash
masterbashrc=$dropboxdir/bashrc
osbashrc=$masterbashrc-`uname`
localbashrc=$osbashrc-`hostname | cut -d. -f1`
echo -n "Applicable shell configs: "
for bashfile in "$masterbashrc" "$osbashrc" "$localbashrc"; do
if [ -r $bashfile ]; then
. $bashfile
echo -n "`basename $bashfile` "
fi
done
echo
# Set convenience aliases
myed=${VISUAL:-${EDITOR:-vim}}
alias editbashrc="$myed $masterbashrc"
alias editosbashrc="$myed $osbashrc"
alias editlocalbashrc="$myed $localbashrc"
One final note, this script also provides three convenience aliases for editing your Bash config files without having to remember where they are stored.
editbashrc
: Edit the global config file.
editosbashrc
: Edit the OS-specific config file.
editlocalbashrc
: Edit the machine-specific config file.
I only tested this on Bash, but it could work on other Bash like shells. But, as they say, your mileage may vary.
I made a blog post about this here.
You could use Distributed File System (DFS), which is built into the Server OS. I've done this to accomplish a similar goal.
Essentially, you configure DFS to create a root, which is really just a URI. You might create \\DOMAIN\SHARE which looks like a share, although it is virtual. DFS leverages the domain's DNS to present it as a valid location. Within the root, you might create links which are just paths to physical file shares on any number of servers. These would be the equivalent of subdirectories under your root. Finally, for each link, you can create multiple targets. In your example, it would be a share on each of the machines. DFS will then replicate files in those shares across all paths listed as targets, using the File Replication Service.
It works very well for the two servers I have it spanning. I don't know how well it would scale when replicating to 1000+ servers. It's an enterprise level solution, but I'm not sure that number of machines would be administratively viable. Because you are spanning machines, you probably wouldn't need to replicate at that scale, but rather use this as a service, like the abstraction that it is. The path is a constant.
Other caveats: you have to have the File Replication Service installed. I think you'd also need a domain environment to really make this work.
Best Answer
This is a question for serverfault.
Anyway I think you should definitely consider getting in the "cloud". Syncing uploads from one server to another is simply unreliable - you have no idea what kind of errors you can get and why you can get them. Also the syncing process will load both servers. For me the proper solution is going in the cloud.
Should you chose the syncing method you have a couple of solutions:
rsync
to sync the files you need between the servers.crontab
to sync the files every X minutes/hours/days.