Re: Linux Admining
 

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.

Re: Linux Admining
 

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

Re: Linux Admining
 

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.

Re: Linux Admining
 

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.

Re: Linux Admining
 

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.

Re: Linux Admining
 

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.

Re: Linux Admining
 

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...
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....

Re: Linux Admining
 

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...
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
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.

Re: Linux Admining
 

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
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.

Re: Linux Admining
 

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?

Re: Linux Admining
 

servers see everything
OK It has come up that someone has accessed someone elses nation and changed their turn actions. This has been verified. Its not unexpected and Ive been prepared for a long time. Yes I know that "is what happens when you dont password protect your god" or by using sloppy passwords when playing network games. Getting caught at it is also what happens when you play network games. Servers see EVERYTHING.

Servers can see what IP uploads a turn. So the servers are able to see who is using player files they shouldnt be using.
Example for Linux
Also, if the user is the same as is in the game, or any game on that server then the 2h files can be checked for matching serials. The dom3 command switch of --verify gamename will create .chk files for each .2h and part of the information is a serial hash.

example for linux

Re: Linux Admining
 

OK yet another lesson learned (that makes me look bad).

It appears that Dom3 can develop a problem. Im still trying to pin it down. Possibly something with the way a player disconnects. Im thinking maybe by hitting the red X in the upper right corner (in windowed mode) killing his program, instead of using the disconnect button on the menu when connected to the server. What I get is a log file full of continual (and very fast unfortunately) messages about trying to resend a packet. In any case, the result is a log file that grows larger and larger and larger until it fills up the machine and starts to crash things.

The fix? I havent quite decided yet. Dont use debug logs? I dont use them all the time but when I do they are extremely useful. Or a watchdog script that "sees" the runaway log-growth and kills that game? Im abit to eager to do watchdogs. Im beginning to think I have too many running now. Or maybe keep the logs on a different drive? I can do that. Have the logs write to the /backup which is a separate hard drive. That way at least when it fills up it wont crash other things. But that will make game cleanup alot more complicated. I have enough of that already.

Re: Linux Admining
 

hmmm... I wonder if I can get along with a soft link to the separate drive. That way the game.log in the games directory is kept elsewhere but can be cleaned up with the game

Re: Linux Admining
 

OK we are back to the runaway logs problem.
There might be two versions. One that does continual packet messages which might be due to users not disconnecting properly (killing dom3 instead of using the quit). And one where a combat loops. Unfortunately, when it happens the panic to fix it before it wipes out the whole server tends to destroy the evidence of what caused it. :) Oops, my bad. Hey, no one else seems to be coughing up anything helpful.

This is NOT what I planned to do today. But I might get around to testing out soft links. That would be my best bet since it would not mean totally rewriting all the scripts from scratch.

The next option would be a watchdog script to continually watch for the harddrive getting 90% full then text messaging me. For just this problem that would seem to be sloppy and overkill but on the other hand it would be a reasonable thing to have in place since runaway processes and runaway logs CAN be caused by other programs on the system (much rarer but it can happen). I should probably do a search since it seems like someone might have already come up with something along this line that I can just download.

The last option would be redesigning the whole Dom3 games setups. There are many "gee I wish you would" on the lists that could be tackled at the same time. I really thought someone else would have done a "serious direct server" by now to match the quality of the two excellent PbEM servers and one excellent game registration server. This choice is abit of a daunting task since the scripts are SOOooooooo spaghettied now. Virtual drives? Hard and Soft Links? Split game directories using Dom3's internal variables like DOM3_DATA or DOM3_CONF? Dom3 already hogs the /tmp directory far beyond any other internet service and does a lacking job of cleaning up (something else on the need-to-script list).

Another plus to the redesign and rewrite options is the number of games is hitting a max. If I keep doing the always-open blitz-type games then I might need to create a new account to manage the games other people are having me host. It would make it easier to keep one from impacting the other. I keep hitting the limit on maps or game directories or mods. I dont THINK splitting the "user" would split the cpu load but Id have to test that. And as long as Im considering a new user with hard-set limits I MIGHT consider adding another for the must-have-a-menu crowd to put into play something like
http://www.dom3minions.com/lab/MakeGame.htm which has been around longer than anyones. Altho Im still not sure about automation on a server that isnt totally Dom3 dedicated. Pros and Cons.

Re: Linux Admining
 

OK this is for a game with a 24 hour host timer that wanted 12 hour reminders.

# if the game name is "megagame" then I use queue M or queue m
# so in the pre.sh

# remove the old reminder timer in case quickturn kicked in
atrm `atq |grep "M domgames"|cut -f1 `
# set a new timer to run reminders.sh in 12 hours in queue P
at -f reminders.sh -v now + 12 hours -q M

# then the reminders.sh has a line for each nation and its owner
# if fatherland is newer than the last .2h for that nation then email
if [ ftherlnd -nt early_pangaea.2h ] ; then echo "waiting for your turn" \
|mail -s "MegaGame is waiting" gandalf@community.net ; fi

I could tighten it up abit by adding a check of the stats.txt for whether the nation is still playing and not AI to avoid false reminders. Maybe later.

Re: Linux Admining
 

Now I have a new "check the game" script for personal games on the server. So far it looks like this..

If the game is called goongame then cat goongame.cgi gives

The first sections grabs the top of goongames latest scores.html (which dom3 creates).
That gives us a nice html header, and title, game name, and the turn number.

The next section grabs the tail end of the game.log twice (created by the dom3 debug switch).
That gives us game name, how much time is left on the timer, and the note (quickhost) if its on.
then it lists the nations and lets us know who is connected *, who has done a turn +, who hasnt done a turn -, and who is AI ( ).

The final section lists the player files with a red asterisk on anyone the game is still waiting on. Yes thats redundant but it has two purposes. The file names are sometimes clearer than the 2-letter codes, and it works even BEFORE the game starts so it makes an easy way for the person who is running the game to see who has turned in a pretender.

All of this is so that people can use a browser to check their games status as much as possible without having to load up Dom3 to connect in order to see it.

Re: Linux Admining
 

I know this isn't quite a linux question, but it seems like the right place.

I was planning on trying to host some games from my Mac. I figured this would be straightforward because the Mac is a unix based OS, and I've done it from a Linux machine before.

But I can't get it to run in a properly text-only mode as a background process. Has anyone had any luck doing this?

Re: Linux Admining
 

Well I can give you an answer for Linux test-mode...

Here is an example script from my system of an actual game..
Some of the non-Dom3 elements are
nohup: No Hangup command so I can log off without the game dying
nice: so it doesnt hog the CPU
&: the ampersand at the very end of the script is what tells it to run in background

a common error is running it & (background) but forgetting nohup (no hangup) so when you logoff, it dies

Re: Linux Admining
 

I was about to say: I haven't seen a Unix command in about 20 years. I see people are still writing "nohup nice ... &", amazing ;)

I used to use /bin/csh. Do I vaguely recall, there you didn't have to "nohup" if you "&"-ed, because its background processes were automatically immune? :eek:

Re: Linux Admining
 

Why not use screen? Or does it take up too much resources?

Re: Linux Admining
 

Up to you. My server runs many things including 2 online worlds. And I have up to 100 Dom3 games on my server at a time. I dont really have much of a need to access them directly.

But of course for people managing fewer games at a time then screen might be a good idea.

Re: Linux Admining
 

This might be a stupid question, but how can you manually make the command line server to change turn? I host the game on a server on screen..

Re: Linux Admining
 

The game does not accept normal kill command requests such as "reset" or "reread config"

So the only way I have been found is to slip into PbEM mode temporarily. I take the game down, run it again without the "S" switch (server), and then when its done I restart it again with the S switch back on.

Just for fun I have messed around with automating it along with lots of other admin commands if you want to discuss that.

Re: Linux Admining
 

Thanks, I don't need to automate it as I'm just running a single game currently. :)

Anyways, for some reason the game seems to crash sometimes, the script in the screen just stops running and it's back on the command line.. has anybody any idea what is causing that? I'm running it on FreeBSD 8.2 with Linux emulation, though.

Re: Linux Admining
 

add a -dd switch and redirect to a file. The last thing in the file should be the reason it crashed.

Re: Linux Admining
 

I added -ddd switch, and the last lines are these, doesn't really indicate anything though:


gameserver got packet 11
sendpacket first:12 len:7


Then it just exited to command line.. I was running it on a screen, so I try to run it with nohup to see if there's some issues with screen.

Re: Linux Admining
 

Also, for some reason crowns appear on the map, and victory points aren't set on by options. The game options window when playing a turn doesn't say they are on, either. Does anybody know the reason for this?

Re: Linux Admining
 

I'm trying to set up a Linux server, but am running into
weird problems with the IP address the Dom3 uses for the server.
For some reason the game decides to use IP 127.0.1.1 (loopback?).

I'm running the game on a netbook with only WLAN connectivity.
After noticing that IP address, I did "ifconfig ... down" for both my eth0 and lo interfaces, so wlan0 is the only interface up at the moment. Still the same IP though.

Looking through the thread it seems there is no flag for setting the server ip? Does anyone have any ideas how this could be fixed?

My desired end result should be it getting an local network address, which the firewall would port forward to.

Re: Linux Admining
 

Thats a problem on all machines. Especially the windows ones.

The game sets itself up with the local machines address which is all that it can easily "see". If no other address is set for the machine, it will not create one for itself.

However, usually external addresses work fine for reaching it. Just go ahead and try it. For the windows users we usually have them use their browser from that machine to visit a site such as WhatIsMyIP.com to find out what address is being seen by the internet. Giving that address to players will usually let them find the game ok

Re: Linux Admining
 

Thanks GP, for making me take yet another look at it.

I was testing it from my laptop on the same local network,
so the external IP was never an issue.
The actual problem was that the server was running an unpatched version, and Dom3 displays this situation as not having found a server at all.

Once I patched the server and tried again, it works like a charm.
So the displayed IP has no function at all - even though it lists a loopback address, it's still listening on the local network address(es).

Re: Linux Admining
 

YAY! after DAYS of messing with it I finally got an ugly ugly script that works!
It is so that a --teamplay game of Dom4 can be started allowing everyone to send a full pretender. When the start button is pressed the game should crash (using --mapfile foo.map will do it). Then run this script and add the done.txt to the start script for the game.

What it does is:
if 4 pretender files were uploaded then it treats those as team leaders 1 2 3 4 and it adds an AI leader for a +1 team (in this case team 5). Then it randomly assigns 2 nations as AI Disciples for each team. So the 4 people that signed up all become pretenders with 2 AI disciples clustered near them.

UNFORTUNATELY I now have to figure out why Dom4 has a problem starting a game with AIs. :(

Re: Linux Admining
 

OK another brain fart that worked out well... :)

What it does:
This is a script I can start in a games directory as soon as I have set it up for someone. It gets around the problem that pre.sh and post.sh do not activate for initial hosting.

It sits and watches for the fatherland file to exist (meaning the game has started and created its initial hosting).

If fatherland does NOT exist yet, then it watches for new pretender files (*.2h) to show up. And when a new one does then it updates the GodSave.zip file. As soon as the fatherland file appears, it shouts GAME START and quits running.

Im thinking of adding a no-clobber to the zip command to help insure first-come-first-served. Other people overwriting uploaded gods has been a problem in some games. And the recognition of fatherland could create the games first backup which has always been missing.

In any case it has proven quite useful in restarting bad starts without forcing people to re-upload their gods.