Simple Killing Floor Server Linux installer (Steamcmd)

[dgibbs]

Hello all,

I have created a Killing Floor Linux installer script to make it easy to install a Linux dedicated server

You can see the instructions on my site

http://danielgibbs.co.uk/?p=293

Hope this makes it a lot easier to install a server.

**Updated 31/7/12**

I have made a few fixes and changes based on feedback.
This should fix any of the major issues highlighted.

Thanks to everyone who provided feedback.
If you spot anymore bugs let me know.

[djw]

It's worth securing the guard.txt and install.txt file before putting a password into them.

touch guard.txt
chmod 0600 guard.txt
echo "login $USERNAME $PASSWORD" >> guard.txt

You do have some replication of code, why not put that into a separate function, since you're already using functions.

Can you assume wget and tar are installed? Might be worth checking they exist in the script and complain to the user before starting the download.

Possible consider doing an md5sum to make sure the file you have downloaded is the correct one.

If I have downloaded steamcmd.tar.gz and placed it inside the directory steamcmd, but haven't untarred it then your script will fail.

I think you need to run STEAMEXE=steamcmd ./steam.sh with no options to update itself before being able to run the installation command. You may want to test with a clean account.

You use:

cat << !

stuff

!

once but never again, interesting.

Consider this too:

cat > foo <<%
bar
%

STEAMEXE=steamcmd ./steam.sh +login ${USER} ${PASSWORD} +force_install_dir ../killingfloor +app_update 215360 validate +quit

Haven't tried without the + on quit, but I know +quit, rather than quit works. In case you were trying that out.

Although I prefer putting the password into a file and running that as script since another user can easily get the password from the process list if specified as a command parameter. Although at the moment another user can read the password out of the file. Assume people want to keep their password secure even if you don't care with a throw away account. They might be using their own account with all their games in it on a shared server.

You've assumed guard.txt and install.txt are empty. Having the first redirect as '>' rather than '>>' will overwrite whatever is in the file.

You've assumed /bin/bash is installed on the system. Some systems have /bin/sh pointing at /bin/dash, therefore /bin/bash does not exist. I've not noticed any bashisms so possibly #!/bin/sh would be better. echo -n is not portable but that's probably not an issue.

I've also sent you a private message.

[_KaszpiR_]

1. Avoid variables written with capital letters, you can shadow already existing variables.

2. There is no check if the wget downloads a file properly, nor if the tar command is successful.

3. You don't check if steam.sh is executable by the user

4. No checks of the ARCH, in example user may be missing ia32 libs so any steam command will probably end with error.

5. Other issues already described by djw in the upper post.

Nice try, but can be done better

[dgibbs]

Thank you so much for you feedback. I really appreciate it. I'm still learning bash and am a bit of a newbie when it comes to this stuff. I have kinda just picked up stuff as I go. I will look at implamenting some of your suggestions as im sure it will help me improve .

I also have a script im creating to start, stop, update, monitor and compress maps. It works pretty well currently but I want to be happy with this one before I release that in to the wild.

Thanks again for your feedback

I have already today got the steam guard working correctly (I hope) and made a few other minor changes.

[dgibbs]

Originally Posted by djw

It's worth securing the guard.txt and install.txt file before putting a password into them.

touch guard.txt
chmod 0600 guard.txt
echo "login $USERNAME $PASSWORD" >> guard.txt

Implemented this

Originally Posted by djw

You do have some replication of code, why not put that into a separate function, since you're already using functions.

I see what you mean. I will add some more functions to stop the replication

Originally Posted by djw

Can you assume wget and tar are installed? Might be worth checking they exist in the script and complain to the user before starting the download.

I will look at adding this in. Im not sure the best way to check these are present. Im guessing just to see if the file /usr/bin/wget exists. Hopefully these are in the same place for both Debian and Redhat systems.

Originally Posted by djw

Possible consider doing an md5sum to make sure the file you have downloaded is the correct one.

I had previously looked at this but got confused as I have never really used md5 even though I know why its used. If you know the correct commands I should be usings please let me know and I will add them

Originally Posted by djw

If I have downloaded steamcmd.tar.gz and placed it inside the directory steamcmd, but haven't untarred it then your script will fail.

Im guessing this will be fixed with the 'Is tar installed code'. Unless these is another way to catch if the un-taring failed

Originally Posted by djw

I think you need to run STEAMEXE=steamcmd ./steam.sh with no options to update itself before being able to run the installation command. You may want to test with a clean account.

I had a look at this and steam will automatically check itself before running anything so I found no need to run the command by itself first

Originally Posted by djw

You use:

cat << !

stuff

!

once but never again, interesting.

Consider this too:

cat > foo <<%
bar
%

I used an example I found online I don't fully understand what it does it but it works. If it is useful/more efficient to use it in other parts of the script then I will get to understand it and use it there as well

Originally Posted by djw

Although I prefer putting the password into a file and running that as script since another user can easily get the password from the process list if specified as a command parameter. Although at the moment another user can read the password out of the file. Assume people want to keep their password secure even if you don't care with a throw away account. They might be using their own account with all their games in it on a shared server.

There is something in the wiki tutorial about protecting passwords. I will take a look at that

Originally Posted by djw

You've assumed guard.txt and install.txt are empty. Having the first redirect as '>' rather than '>>' will overwrite whatever is in the file.

Done

You've assumed /bin/bash is installed on the system. Some systems have /bin/sh pointing at /bin/dash, therefore /bin/bash does not exist. I've not noticed any bashisms so possibly #!/bin/sh would be better. echo -n is not portable but that's probably not an issue.
[/QUOTE]
I thought bash was on pretty much everything. I have used #!/bin/bash at work on old and new systems and got good results where as using #!/bin/sh was unpredictable whats why I picked bash.

[dgibbs]

Originally Posted by _KaszpiR_

1. Avoid variables written with capital letters, you can shadow already existing variables.

Not sure what you mean by shadow. I used capitals so they look like there SHOUTING and stand OUT. But if this is not best practice when I will switch. Is there a particular best practice you reccomend?

Originally Posted by _KaszpiR_

2. There is no check if the wget downloads a file properly, nor if the tar command is successful.

I will look at adding this in

Originally Posted by _KaszpiR_

3. You don't check if steam.sh is executable by the user

Looks like is forgot to add chmod +x steam.sh. Fixed this

Originally Posted by _KaszpiR_

4. No checks of the ARCH, in example user may be missing ia32 libs so any steam command will probably end with error.

This is something I raised in another post. Please can you or someone confirm in a new post requirements for SteamCMD as a nice tidy post about this will just remove confusion that may people get.

Originally Posted by _KaszpiR_

5. Other issues already described by djw in the upper post.

Nice try, but can be done better

All will be looked at. Thank you

[_KaszpiR_]

1. imagine your script is executed by another script that already has USERNAME defined
then your variabe will destroy the original varialble.


2. I got nice working game server script that can start/stop game on screen and uses qstat/quakestat to check if server is up, so you can add to cron it to restart server on crash. I'll be expanding it soon with some extra features like:
backup
update
logrorate
demo compression
content rsync to use with www file hosting

[djw]

Originally Posted by dgibbs

I will look at adding this in. Im not sure the best way to check these are present. Im guessing just to see if the file /usr/bin/wget exists. Hopefully these are in the same place for both Debian and Redhat systems.

test -e `which wget`
echo $?

Originally Posted by dgibbs

Im guessing this will be fixed with the 'Is tar installed code'. Unless these is another way to catch if the un-taring failed

I was thinking of the file existing without using your script. Just requires more checks. It's a corner case which most people won't hit. You can end up with more checks than actual code that does the install.

Originally Posted by dgibbs

I used an example I found online I don't fully understand what it does it but it works. If it is useful/more efficient to use it in other parts of the script then I will get to understand it and use it there as well

It's redirecting file descriptors, for example, command > filename, send the STDOUT output of command to the file filename. <<% ... % is just redirecting a block delimited by % to STDIN of the command.

You'll find lots of good bash information at:

http://mywiki.wooledge.org/BashGuide

Originally Posted by dgibbs

There is something in the wiki tutorial about protecting passwords. I will take a look at that

Putting the password in a file only readable by the user is fine.

Originally Posted by dgibbs

I thought bash was on pretty much everything. I have used #!/bin/bash at work on old and new systems and got good results where as using #!/bin/sh was unpredictable whats why I picked bash.

It's on most Linux systems, but not always. There's no harm sticking with bash, since it has nice features over plain old sh. Just I've tended to use systems that don't have it installed, so had to learn how to write portable shell scripts.

Originally Posted by _KaszpiR_

uses qstat/quakestat to check if server is up,

That's just what I was looking for

[dgibbs]

qstat/quakestat sounds interesting. I looked it up briefly but did get much info on it. Im currently designing a simular script to monitor the servers and update them etc.