Nice, thanks for the story. Always good to hear sollutions from people just for the sake of "what else is out there"
Instead of using a uninionfs we use symbolic links, i only share the maps folder because that is one of the biggest ones. I just dump all maps in there regardless if it needs to be there and keep that up to date. Only i use unison to sync from our bigbox to several other servers (physical) , its a bit more space but all the boxes have enough anyways (and the bigbox is ssd only) We link all our plugins to 1 big shared folder (which is synced via unison again) so basicly i can update on any of the servers a plugin in my shared folder and when the sync comes (its in cron) it gets picked up and all the servers using that plugin will be updated too. Updating tf2 itself goes via the SSMS tool (see AM/github), it just sends out a _restart to the server and the srcds script will update because of that when a update comes out. Nothing fancy but it does a good job. Maintenance with 10+ servers is just a horror if you have different mods and such too. Overall its still a lot of work, getting the right people to do the job is even harder. So good idea's are always welcome. 2012/10/29 Lord_Jeremy <[email protected]> > Hey all. For a while I've been operating multiple TF2 servers off the same > data files, where all each instance has is a separate /cfg and /addons > directory. I'm using a program called Unionfs-fuse, which allows you to > mount directories in layers over each other. (I'm using the FUSE variant > for simplicities sake. The kernelspace version would theoretically have > better performance but I haven't noticed any issues that would necessitate > it.) > > The way I've set up my directory mounts, I start with a "common" data > files folder that is essentially a complete source game install. For each > server instance, I create a "config" folder that contains just the > server-specific files. So for a tf2 server that would be along the lines of > tf-config-1/orangebox/tf/addons and tf-config-1/orangebox/tf/cfg. Then I > create an empty directory for the actual server "instance". Now I use > Unionfs to mount the common directory as readonly and the corresponding > config directory as readwrite for each specific instance directory. The way > Unionfs works, if the top level directory (config) doesn't contain a file, > it will look in the bottom level common directory for it. When the server > writes files back to the instance directory that it's run from, they're > actually put in the config directory. So after running the server, the > config directory will get populated with a bunch of caching and log files > and the like. > > Unionfs-fuse is a filesystem type as recognized by mount, though the > package I use also has an actual unionfs-fuse command which is effectively > an alias to mount. I use the "copy on write" option which means that if the > server tries to write back to a file which is in the readonly common > location, it will first copy it to the readwrite config location. > > For the purposes of updating, I also created another directory that I use > the steam updater on. This directory has the common directory mounted as > readwrite initially. I also mount two dummy directories over the addons and > cfg paths so that if the updater writes anything to those locations it > doesn't get put back into common. > > For ease of configuration, I put several base configuration files in the > common directory's cfg location. For example, I've got a > "standard-server.cfg" file which sets up all the options for my standard > servers. I've also got "mvm-server.cfg" which sets up an MvM server. Then > in each server-specific config's cfg directory I've got a server.cfg that > execs one of the common cfgs and then sets up that particular server's > specific options. In practice, that's usually just the quickplay identity > and the hostname. Although it makes it easy for me to just tweak a couple > small options. E.g. for the halloween event I changed the map rotation for > a couple of my servers in their specific cfgs. I also have a maplists > directory in the common tree that just has a bunch of text files with > maplists that can be loaded both via the mapcycle cvar and in the sourcemod > plugin configurations. > > I've written up a few shell scripts that make my server management easier. > One of them can either mount or unmount all of the layered filesystems all > at once. I call this script from an init script so that the mounts are > automatically performed when the system boots. > http://pastebin.com/dw6FLhB8 > > This script is just a shortcut for using steam to update servers. I > created it before I was using the shared data mounts as it meant I could > just chain all the server folders as parameters and it would update them > one at a time. > http://pastebin.com/VV6WcmHs > > This script is a shortcut for updating sourcemod. Due to limitations of > sourcemod itself there has to be a separate addons folder for each server. > Therefore I created this script to untar the downloaded package and copy > some of the contents to a game server's addons directory. It leaves the > configs directory alone. > http://pastebin.com/tBzqwZQW > > So I've been using this system for several months with as many as 10 > servers sharing one common data directory. It saves a TON of disk space > (each config folder ends up being about 500 MB with all the cached files) > and I'm considering replacing the physical disk in one of my servers with > an SSD to see how it performs. I also only have to run the updater once to > get all the servers on a box up to date. Adding a new server is just a > matter of making a new config and instance directory and adding its name to > the mount script. Feel free to ask me any questions. Cheers! > > -Jeremy > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
