Alloc

Just released v.14, added backup options (see the Release Notes). Also fixed the permissions problem when installing/updating. Shame on me, just did not notice this when testing Yeah, of course that's intended No, it's not, never thought about the possibility for a player name to contain spaces. Could you send me a snippet of the output_log.txt containing a "RequestToSpawnPlayer:"-line for such a player? Hm, one could simply do this by an external script using the functions of the management scripts (i.e. the telnet-interface). Of course I could also add this internally but I think that's too user dependent. Added as ticket 15 for now. Well, this is the ideal usage example for hooks Just write a hook for serverPostStop which executes 7dtd.sh backup. That definitely won't go in the normal release as this is way to much depending on what the server is doing. Should never be done automatically IMHO. Again too dangerous. What if an update breaks compatibility in some aspect? The server might not be able to start again until the admin notices. For the scripts this could be done. For 7dtd I already thought about it myself but unfortunately SteamCMD doesn't provide a command to only check for updates but only allows to actually run the update Added as ticket 16 though, might find some way. Have never worked with expect myself, but I don't see an obvious reason why it should not work. You could also use the provided function telnetCommand though which basically does the same. . /usr/local/lib/7dtd/common.sh checkRootLoadConf telnetCommand <instancename> <command> [timeout=1s] Command would be "lp" or "say Checkout http://your.website.goes.here for server info" in the case of the linked thread. Regards, Alloc

Hm, it the scripts do ensure the permissions of some files/folders are set correctly but they should not touch anything outside SDTD_BASE or /usr/local/lib/7dtd (besides the 7dtd-files in bin, etc, cron.d, bash_completion but those are relevant to these scripts only anyway). The only thing that I could imagine could interfere with other folders could be the un-tar-ing of the mangament scripts. But I never got any problems with that either. Will dig into that though. Regarding running as root: Basically the scripts could all be made to be runnable by the user for the game itself (i.e. "sdtd" in default installs). But as the user is changed for starting the engine anyway I didn't see much of an advantage in that. Also e.g. updatescripts would not work without root permissions. Also by running as root a lot of stuff could be made root-(write)-only later on (e.g. the whole engine folder if there's nothing left that wants to open files for writing in there) or the backups. This would reduce the risk of the engine damage anything if there was a security hole. Backups: The backup system requires a few changes anyway as I was going to implement a few limits (ticket 12). I will also include an option to have backups compressed (though that obviously would negate the positive effects of hardlinking stuff ). Running backups at different priority is a good idea, will add that too As far as transferring backups to other targets: You could write a backup hook for that purpose (see Hooks). This would be run directly after a backup was created and you would get the folder passed as parameter so you could simply compress/rsync it or whatever you want to (compression will be added directly next release, probably later today). Regards, Alloc

Hm, so the range is even wider ... On my machine it never sent (or received) anything on that port, only on the given range (27017-27020) Update of the scripts to v13 Added scripts-update detection+install feature so you don't have to download the management scripts manually each time there is an update

Ok, so automatic unban just does not work atm (not caused by the Linux engine!): http://7daystodie.com/forums/showthread.php?11220-Does-automatic-unban-work The format is actually not relevant and both variants seen in this thread work from that point of view, it's just that the 7dtd engine simply does not care about that unban date Regards, Alloc

Monitored the traffic ... Looks like it's: Source port: Baseport+2 (i.e. 25002 for baseport 25000) Dest port: 27017 - 27020 Protocol: UDP Don't know if only one of the dest ports would be enough, but that matches what Valve documents here: So I would recommend going for dport 27015-27030. Regards, Alloc

20/21 is listed because those are open by my firewall for updates I just listed everything that was open. Though it looks like I got the wrong state (tried with different port combinations). Looks like it really is something between 27000 and 27099 UDP outgoing (ports used by Valve games).

Looks like TFP did not explicitly specify how that date should be formatted so it's different in the Linux build. Maybe even depending on the systems locale. With a german locale it looks like this: <blacklisted steamID="76561198xxxxxx" unbandate="05.06.2014 01:56:34" />

Hm, the only way I ever got telnet to crash was when I did not properly disconnect, i.e. closing the connection instead of letting the server close it by sending the exit command (this *always* made it crash for me). Don't know what FRT does with his SM though

If you use the instance edit feature it's called "Item spawn menu" under "Generic Options".

As I thought probably just an old file somewhere Glad it works for you now.

Hm, shouldn't complain about Steamworks at that point as 7dtd is not run during bootstrap. If you should rerun bootstrap and get that again please show me the log Should not interfere here. Also disabling Steamguard should not be required, you should simply get a mail with a confirmation code which has to be entered during the update-process. (Have done so like 30 times the last week ) If there's any error showing please also send me a copy of that. We've got the problem in line 96: 2014.06.04 03:25:50: EntryPointNotFoundException: GameServer_LoggedOn This should not happen anymore ... When did you first run the bootstrapper? After I created this thread or before? Basically you could delete everything within the users folder (but not the backups-folder if you used that of course ). SteamCMD probably also created a folder in the root's home, namely /root/Steam. You can also simply rerun the bootstrapper without deleting anything which will skip redownloading SteamCMD and 7dtd but do the other steps of the installation again. Thank you, I really appreciate that. Still I'm doing this for free because I myself use this and I also refresh/deepen my knowledge on Bash scripting @Mike: To be a bit nit-picky it was made for Debian in the first place Obviously that should make it run mostly without problems on Ubuntu and other Debian derivatives too. But by now I'm also testing the whole thing on Fedora so it should work on most systems. Basically the only thing I don't check is the startup of the server at system boot time but according to the information on the net systemd can use sysvinit-style scripts so it shouldn't be any problem either. The only thing that I really have it depend on is a Bash and of course 32 Bit libraries (gcc, ld-lib) which is simply caused by the fact that SteamCMD is not available as 64 Bit executable. Hm ... "over the past months"? Unfortunately it's more like "over the past years" by now But as long as we're able to do this stuff ourselves I won't complain, they got other things to do too. Regards, Alloc

The path shown in this error refers to the location Valve built this program. It has nothing to do with your system. Also it can be simply ignored, I don't know why it shows up on some systems (did also show on my Debian 6/Squeeze test machine, but neither on my deployment machine with Debian 7/Wheezy nor on my Fedora 20 test machine ...). Those entries are ok. What do you mean by "when installing it"? Sounds like you got a wrong combination of the Steamworks files. Could you pastebin the whole output.log from the instance you were trying to run? I only have the following ports: - in: 25000-25002/UDP - out: 20,21,80,443/TCP - (and DNS, NTP but that shouldn't matter ) I think it uses HTTP for the server list so port 80 should be enough. I don't know about a comparison to a Windows based server but I'd suspect it to perform a little bit better as most things perform better on Linux regarding raw CPU / IO power and you obviously don't need graphics power on the server Also don't have any numbers for required resources for a given player count, only hosting a server for me and two friends. Regards, Alloc

Hi there, as it was suggested to me I open a new thread on my management scripts and native Linux server support. This is basically following up on the thread Dedicated Server without hacky workarounds though this is in Linux Bugs where it might be overlooked. I created a full set of management scripts for a Linux based 7dtd server. This allows basic operations like starting/stopping as well as advanced things like a few event hooks. (This also includes native Linux engine files so you do not have to use workarounds like Wine to run 7dtd. Unfortunately these files are 32 Bit only so far but at least they can be run on 64 Bit hosts without any problems.) No longer valid, 7dtd provides "built in" 32 bit and 64 bit Linux support since A14 For the full documentation on the management scripts go to https://7dtd.illy.bz/. Regards, Alloc