Utility: Linux Admining

[Gandalf Parker]

More script examples are always helpful. I also have the old Dom2 pbem BBS using php and sql. I dont remember if Ive seen Llamabeasts scripts since about mid-way thru the discussions on creating his server. Those would be worthy to look at also.

One thing Id add would be the mail support. Ive played abit with
mail, sendmail, mutt, pine, postfix, mpack/munpack, and biabam. If I remember right I got them all to work. But now for receiving player files I use munpack, and for sending turn attachments I prefer biabam. I also like to attach the backup files to an outgoing email just to have them off-system

Gandalf Parker
--
You dont use Linux if you like asking a question and getting an answer.
You use Linux if you like asking a question and getting a hundred answers on a hundred different ways of doing the same thing.

[Gandalf Parker]

OK since I mentioned my IP in many of the examples here I should update this. I have upgraded my DSL, switched ISPs from AT&T to Sonic.net, and received all new IP addresses. The new address for www.Dom3Minions.com and temporarily also for game.dom3minions.com where all the games are, is:
70.36.184.129

[Gandalf Parker]

OK some new territory here.

After running a PBEM game Ive decided that such games are a pita.
But it was an extensive learning experience.

Some new territory:
ProcMail nicely handles some features. Checking Subject lines in order to unpack player files to the game directory, or calling specific scripts to do things like allowing the games admin to change things such as the games hosting times.

One of the few good things about pbem was that Dom3 did not have to claim its share of server CPU load running continually. Having many copies of Dom3 running all the time can eat up a server. I didnt want to undo that benefit by having a script run continually or a cron job running every minute to see if the game should host in order to duplicate the "quick host" option of DirectConnect games. Since an incoming file should usually kick off "quick host" I have procmail unpacking each email AND running a host_check script.

To duplicate the Forced_Hosting option I used the "at" command to set system timers. One for the hosting time (such as 48 hours) and one for sending email reminders (forcehost - 9 hours).

Also I had to get into lock files and date math. And made extensive use of the .chk files that Dom3 generates using the --verify command in order to catch players sending in files that werent 2h, or didnt attach properly, matching serials, or arrived corrupted, or were the wrong dom game, or were the right dom game but the wrong turn (especially on the many rollbacks).

The resulting scripts are many and extensive (and ugly since they grew gradually with many tests inserted). I may clean them up and post them seperately. Oh yeah, and one note which I really REALLY need to try and remember. The initial big bomb is that the Dom3 games PBEM coding was prior to the change allowing us to keep multiple gods available for server games. So its very important that the initial god files sent in be cleaned up so that early_ulm_1.2h becomes just early_ulm.2h before trying to start the game.

[Gandalf Parker]

NEW TERRITORY:

Ive now been asked to host a multi-connect game. One that supports Direct, and PBEM, and FTP, and possibly WEB upload.

The first headache is that if I run the game 24/7 for direct connect then it doesnt "see" any new .2h files that are copied to the games directory. I had HOPED that something like a SIGHUP sent to the game would work like its used for other running programs to get them to reread their configurations without having to reboot them. (which would also be really handy with Dom3 for making changes such as hosting times). The only signals I can get to work is STOP and CONTinue (and of course KILL) although I havent actually tested every one.

The best I can come up with so far is something like:
pkill -f game_name ; sleep 1 ; ./start.sh
which kills the game and restarts it very quickly. I will need to add a check to make sure none of the direct-connects is uploading a file at the same time.

[lch]

Originally Posted by Gandalf Parker

NEW TERRITORY:

Ive now been asked to host a multi-connect game. One that supports Direct, and PBEM, and FTP, and possibly WEB upload.

The first headache is that if I run the game 24/7 for direct connect then it doesnt "see" any new .2h files that are copied to the games directory.

I already hosted a networked game that had an alternative web upload method for one person who had firewall issues to connect normally and I don't remember any problems. What you should make sure is that the game server has access to the new *.2h files, so you should chmod them to 0666 after uploading or chown them to the account that the server is running under, and maybe "touch" them as well. If you want, I can send you the PHP turn file upload/download script that I created for my networked game.

[Gandalf Parker]

Actually most of "getting the files there and usable" I think I have down from painful learning experience in game 1 of the series which was all pbem. Some simple bit of PHP for uploading would be useful though.

But do you remember, did you ever come up with a way to force Dom3 running in server mode to SEE the new files without taking the game down and restarting it? So far all tests seem to say thats what I will be forced to try and script.

[Gandalf Parker]

In continuation of support for any other servers or anyone trying to iron out hosting games by providing copies of everything Ive worked out, I offer the following...
IF YOU ARE TRYING TO RUN MULTIPLE VERSIONS TO SUPPORT GAMES PRIOR TO UPDATE PATCHES

Running with -d will show something like this at the head...

-------------------------
----- DOMINIONS ---------
-------------------------

Version version 3.23b (323)dbglevel 1 pc_endian
datapath='/usr/local/games/dominions3'
confpath='/home/gandalf/dominions3'
savepath='/home/gandalf/dominions3/savedgames'
modpath='/home/gandalf/dominions3/mods'
mappath='/usr/local/games/dominions3/maps'
localmappath='/home/gandalf/dominions3/maps'
temppath='/tmp/dominions3_24145'

Keeping a copy of the dom3 executable as a new name such as old_dom3 and using it might seem like an answer but it causes problems due to conflicts with some of the library files. Making a complete copy of the dominions3 directory and running the game out of that might seem the answer but in many cases it only changes some of the path variables, but not all. Most importantly in this case, the datapath directory.

This has worked for me. Setting DOM3_DATA= to the directory of the old copy, doing it on the same line but before the dom3 call (and not using a ; for some reason)
Such as....

DOM3_DATA=/home/gandalf/dom3_v3.23b/ /home/gandalf/dom3_v3.23b/dom3 \

[Gandalf Parker]

Im not sure if Ive mentioned this little bit. But with the growth of usage on my server, plus doing more and more automation, this has become useful...

while [ ` cut -d. -f1 /proc/loadavg ` -gt 2 ]; do sleep 10 ;done

This will loop until the load on the system is below 2. Particularly important for large games, or generating maps, or extensive backups. It will keep those from kicking in while the system is already suffering under some other major process.

Its also handy to use the nice command with Dom3. Such as

nice -15 dom3

to tell it to operate at a lower priority than more immediate activities. After all, we usually arent that concerned with how long it takes to do a hosting in a server game. Not so much that it should take equal position to email, web, ftp, etc.

[Gandalf Parker]

Whenever anyone requests a game I copy a script from another game and edit it. Whenever I see some of the always open public games have been taken I run a script to create another to take its place. Many of those involved special variables unique to that game, or even randomly decided features. So restarting games was rather a pain.

Recently I had one of the head-slapping *DOH* moments. While the script creating the game is running have it record the settings. So now each script writes the long start command to the game directory into a script named restart.sh

So now, when the machine reboots, all that needs done is

#!/bin/bash
cd ~/dominions3/savedgames

for fyle in `ls */restart.sh`
do
   $fyle
   sleep 10s
done

Ive extended the gap to 10 seconds between each restart. My first effort with no gap restarted 70 games within a minute. 24 hours later about 50 of them tried to host at the same time. Not good. Then I set it too long but even a 1minute gap would mean over an hour before all the games would be restarted. So for now Im trying 10s.

[Gandalf Parker]

I also had another recent head-slapper. I can now offer the feature "refuses player going AI"

In one of the special games the person running it asked if the game could be set to refuse allowing anyone to go AI. He wanted a chance to always try to find a sub, or set AI later as a last resort. My initial response was to say it couldnt be done. Then I thought how nice it would be if it could. Then I realized how it could be done.

A) My pre.sh always make a zip of the game just before hosting. For backups, or I email it to the person running the game, or for doing rollbacks.

B) If the game is run with the --statfile switch then the stats.txt is generated each turn which looks like this...
Helheim played this turn
Hinnom didn't play this turn
Atlantis is computer controlled

The post.sh which runs just after hosting can check the stats.txt for anyone that went computer controlled. Then shut down the game. The options would be to unpack the zip, delete the 2h that went ai, and then rehost (that one would go stale) or wait until a sub can turn in a good 2h file.

Yeah I know. Not very impressive or difficult. We should have thought of it long ago.
Next?