Linux Port

[Chais]

I'm aware we can already run TShock on linux. However there are certain shortcomings in the way TShock works that make it somewhat ill-fit for a linux deploy. I'm maintaining the Arch User Repository package for TShock and while trying to restructure the package I noticed that, like the Windows version of the official server, TShock requires the config file to be in the same directory as the exe. While on Windows this may be fine since frankly installations on Windows are barely structured (everything is just slapped in a single huge directory inside C:\Programs) programs on linux tend to be more spread out. Usually there's a data directory, holding the immutable parts of the program, like binaries, depending plugin libraries, etc. Then there's one or more configuraiton directories, usually in a precedence hierarchy. Finally there's the working directory, where the main binary is called from. All data arising during runtime is stored here. For TShock the layout I'm aiming for would be:

/+
 + etc/conf.d/tshock  (Configuration directory, holding the -configfile targets)
 + opt/tshock         (Data directory, holding the binary, DLLs, plugins installed through packages, ...)
 + var/lib/tshock     (Working directory, $HOME of the dedicated user, holds config.json, worlds, plugins installed without packages, target of -configpath)

Thus far for the motivation. TL;DR: Now the question is, can we get the TShock patches applied to the linux version of the server? I'm aware some adaptations will be necessary but I'm unable to estimate the effort.

[hakusaro]

Now the question is, can we get the TShock patches applied to the linux version of the server? I'm aware some adaptations will be necessary but I'm unable to estimate the effort.

If you want to join us on Slack and coordinate with the work happening with OTA and Orion, sure, but nobody's going to drop all of their other work to prioritize restructuring the config files right now -- with no submitted code or pull requests.

[tylerjwatson]

Hi,

I am working towards this in Orion, the next version of TShock. I need you to undertand that TerrariaServer is not a Linux process and has been backported to run (with varying results) under mono on Linux, which means to say that it works, and we do support it to some degree, but it isn't the primary focus.

Now the question is, can we get the TShock patches applied to the linux version of the server?

Not likely in TShock v4.x. Being that there are no Linux version of the binaries, changes that enter TerrariaServer must be cross-platform.

While on Windows this may be fine since frankly installations on Windows are barely structured (everything is just slapped in a single huge directory inside C:\Programs) programs on linux tend to be more spread out.

Horses for courses. Avoid commenting on windows, as that is not the topic.

Note: I will not be using /opt under any circumstance.

[Wazubaba]

I must disagree heavily with Chais' suggested directories. My reason is simple: Having system-wide configuration and setup would make running multiple configurations a pain for end users and primarilly server hosts who wish to run more than one server instance with different settings for each. :-(

IMHO the best solution would actually be the windows style here. It allows end-users to put the directory wherever they please. If they wish for a static, system-wide install then all it would take is a few symlinks or slight alterations a few environment variables. The same holds true if they want a dedicated user for a server.

If you actually want to do any sort of managed directory setups, I would suggest you go by the FreeDesktop standard specified here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

tl;dr: unless otherwise configured via environment variables, here is an example:

• configs would go into /home/<user>/.config/tShock/
• data would go into /home/<user>/.local/share/tShock/

The binary would then go wherever the user puts it. Whether they do the "make a new user for everything" route or simply throw it on their desktop (provided they actually have a desktop like that configured ;-) ).

This is just my two cents of course. I apologize if I come off a little blunt at times in my suggestion as it is quite late where I live ;-)

[tylerjwatson]

I must disagree heavily with Chais' suggested directories. My reason is simple: Having system-wide configuration and setup would make running multiple configurations a pain for end users and primarilly server hosts who wish to run more than one server instance with different settings for each. :-(

If tShock was to support the POSIX directory structure, by no means will we destroy any instance-specific configurability.

IMHO the best solution would actually be the windows style here.

The Windows style is not the best way. It doesn't package well, it doesn't configure well, and it doesn't start, stop, or daemonize well. We can't ship SELinux policies, systemd scripts or anything that will control the TerrariaServer program like everything else (like contribs).

I don't believe we should depend on freedesktop-basedir either.

---

Support for POSIX directories will not be backported into TShock 4.0, but will be something that will be considered for TShock 5.0.

My thoughts around the directory structure are:

• /etc/tshock/ - base system-wide configuration
• /var/lib/tshock - base system-wide tshock data
• /var/lib/tshock/plugins - system-wide plugins that will be loaded amongst all instances, unless explicitly ignored

TShock should obey the ORION_BASE_DIR environment variable as this is cross platform, which tells the server to obey an instance-specific directory as there should be only one TShock and TerrariaServer binary per host. If this is not provided, TerrariaServer should take pwd. as the instance directory for win32 compatibility.

Multi-instance users will be able to add plugin exclusions to the config file which will prevent system-wide stuff being loaded into instances if so desired.

Cheers

[QuiCM]

See https://github.com/NyxStudios/Orion/issues/18