Thnx man I'll change the port in the am cause I'm at work and I work all weekend. I work at night and I'll be off again Tuesday and wensday...

If there was some way we could do this together where we could verbally communicate and walk through it I would get more out of it and it would be something I would remember how to do in the future...

I just want you to remember that I am always grateful for you help dude.

Ok, what I did was simple:

It's fairly easy to mount it manually as you can see above (you'll only have to do the mount command there).

I see what's wrong with the q3 install -- it's throwing errors because it's 64bit.  I just ran it with --keep (which doesn't erase the temporary files unpacked) and manually copied the files over to the q3 dir:

If you are going to have other users running servers, you should probably make a group called q3admin and restrict permissions:
-R is recursive, root:q3admin is the user and group ownership, o=r is setting all "other" users to read only, and -a -G q3admin rnr adds rnr to the q3admin group as a secondary (you don't want to change the primary group here).

For setting up stuff, only use /usr/local/games/quake3 directory for files all servers should be able to access.  For instance, if one server is going to be running rocket arena 3, you would not put it there, you would put it in the server's home directory ~/.q3a/arena.  If all servers should have access to a custom map, say jjm.pk3, then you'd put it in /usr/local/games/quake3/baseq3.  If you only have one user for all servers (which is fine as long as you don't need to allow ssh/ftp access to the server for other users), then you might as well keep them all in .q3a anyway.

If you're not doing a permissions scheme for multiple users, then yes, just copy over your configs, mods, etc to your home directory and run the servers.  You know how to run the servers as sessions, right?  That way you have better control over them.

I was typing a reply about an hour and a half ago, and just said screw it I'll make a quick script.

I ended up trying a couple things I've never seen before, and then encountering some issues, so I just went back to what I know instead of spending too much time dealing with it.

There's now a script called rnrq3 in the home directory.  You can use ./rnrq3 <start|stop|restart>.  Read the script to get an idea of how it works.  It's fairly close to what it was on the dedicated box.  I think on the dedicated box, I had an extra check to make sure there was only one session with the session name (an issue we ran into on the box) and kill any extras lingering around.

You didn't make it executable and you don't have ut setup properly... i think.  I echo'd out the $DAEMON command, and ran the command:

/usr/local/games/urbanterror/ioUrTded.x86_64 +set dedicated 2 +set fs_basepath /usr/local/games/q3ut4 +set fs_homepath /home/rnr/.q3a +set fs_game q3ut4 +set net_ip 192.168.1.100 +set net_port 27961 +set com_hunkmegs 56 +set com_zonemegs 24 +set vm_game 2 +exec server.cfg
ioq3 1.35urt linux-x86_64 Dec 21 2007
----- FS_Startup -----
Current search path:
/home/rnr/.q3a/q3ut4
/usr/local/games/q3ut4/q3ut4

----------------------
0 files in pk3 files
Couldn't load default.cfg

It did not find any pk3 files for UT.  Looks like you set the wrong basepath: you named the installation urbanterror, not q3ut4, but set q3ut4 as the basepath.  I changed the basepath variable in the script to the correct one.

No, the script has nothing to do with restarting the machine.  It is a control script for handling your q3 servers.  You use crontab to handle running the script and rebooting the machine.

I made an example with the rnrq3 script of how you'd setup the crontab.  You can google to understand what it means.  The >> just appends output to the log file -- it's not the server output, just the output from running the script (if there are errors, although I doubt you'll see any even if there are, as you've already seen it be quiet about permissions and invalid directories).

You shouldn't need to restart the machine, just the servers.  If you really want to reboot the machine, you can do it in root's crontab (edit it by sudo crontab) with something like:
0 5 * * * /sbin/shutdown -r now

If you do choose to do that (again, no reason to do this), then you would have to remove the game server restart from the regular user's crontab.

As I said, you have chmod +x it.  You should probably look into basic linux permissions and chmod.  It's not that complicated.  chmod u+x means you are adding execute permission to the user who owns the file.  g+x would be the group that owns the file, and o+x would be all others.  You can use = also, to set permission flags (r,w,x) or - to remove a flag (if it's set).  There are more permissions, like sticky bits, and what not, but the above is all you really need to know. 

I still don't know why it didn't complain about it.  Normally, won't even let you autocomplete with tab if it determines you are trying to execute a file without sufficient privileges.

well i duplicated the file in winscp edited it etc... and i did the chmod +x but i still had to type $ sh rnrut4 start...

maybe its because i didnt type ./rnrut4 start... i dunno


haha next up teamspeak 3...

The rest of it is easy too, really, it just depends on your knowledge of the platform.

As for rnrut4, the reason why typing it without ./ will not work is because when you type something in a shell, it has to be a built-in command/script/binary or an absolute path to a command/script/binary.  Why?  Because that's how a shell works -- you have to tell it to do something.  Your PATH env variable contains the search path for locating these when you don't use an absolute path.  ./ tells it you are running a command from the current directory.

Why does sh work without an absolute path?  Because sh is a built in command, so it passes the first stage, and sh expects either a relative or absolute path.

You could add a . to your PATH variable which will always include the current directory when running a command, but that's generally not a good idea for safety concerns (not knowing if you are running a script in the current directory that has the same name as an in built one or vice versa).

There are other things you can do, like making your own bin folder and only putting files you want to be able to execute anywhere in there without using a relative or absolute path notation.