Jump to content

Multiple instances of the server on the same Machine.


tony Liberatto

Recommended Posts

I am sorry for the comparison, but it is inevitable to compare what we use to have in Minecraft with what we have in Vintage Story.

At one time I had 6 servers running on the same machine. They had different Minecraft Versions, different mods and different settings.

Why so many? First of all to allow for extensive testing of new server versions and mods before we had the public on it.

Right now we cannot have 2 servers running Vintage Story with different versions, once you install the update it will not let you run the old version.

Right now we also cannot run 2 servers with the same version at the same time using different ports. Or at least I and Skol could not find a way to create this without having to manually create the files for it. 

Bottom line we need a server launcher that is capable of handling multiple instances with different ports and different versions of the server.

BTW, for anyone that gets me wrong, I am completely in love with this game, I support this initiative 100%, I am talking to everyone that I know and insisting that they buy the game and support it.

Is just that server administration is a priority for me. the easier we can make for people to create servers and administer it, the more players we will have.

Link to comment
Share on other sites

Hm, not sure I understand, how was the set up of 6 MC servers different/easier as compared to the setup of 6 VS servers? Didn't it work to install the VS server 6 times and change the port number in the serverconfig.json?

Or perhaps are you just looking for an easy-to-use web admin tool for managing 1 or many servers?

Also no worries, you can compare it to MC as much as you want :D
It's part of my goal to improve upon what MC has, in every area.

@copygirl or @skol - semi related question: If I were to cobble together a few php scripts and mysql database setup script for a vs webadmin  tool - would you be able to put together a debian package that installs it in a way that works right out of the box? (i.e. installs httpd/mysql/etc. automagially if not installed already and sets up vhost and etc.)

Link to comment
Share on other sites

Is it easy to use multiple versions of VS on one computer?

I did a quick search and didn't see any info on setting up multiple instances for VS.

I use many different versions of MC, and use multimc for them, could something like that be used in VS? 

Wanted to update to newest version, and didn't want to not be able to connect to the pubic server, so waited. Didn't want to chance it.

Would of played a bit in single player on the newer version if I could figure out how to have two instances, though now that the public server is updated its moot =P.

 

Link to comment
Share on other sites

41 minutes ago, RainnMannx said:

Is it easy to use multiple versions of VS on one computer?

Yeah, if you download the game / server manually, it should be possible by keeping the different versions in different folders.

They do share the same data folders though, which includes your worlds and custom mods.

Link to comment
Share on other sites

I think it is important to highlight that there is no need to use the server script to run a server. It is sufficient to run

  • mono VintagestoryServer.exe --datapath whatever

If you separate different worlds with different ports configured by datapath then the work is done. If one is familiar with shell then it is no great challenge. Most important is a clear structure to manage 6 installations (and maybe some different software versions too).

Is it easy? Depends on your skill.

The main usecase of server.sh is to provide a bit comfort in terms of having a quick start to fire up a multiplayer server (e.g. in the home LAN):

  • start/stop script that can be integrated in the boot process
  • backup feature
  • update/reinstall feature
  • console access to server commands 
  • primitive status monitoring

This is a starting point but not a hosting solution. Means it is limited, but I think this should be OK.
Imho the main goal of the script is to be robust, portable and easy to use. 
Enhancing the script to have more comfort and less limits, makes it harder to achieve this goal.

E.g. the option to have the datapath seperated from the software installation and to configure this per commandline enables a multi-instance setup. But it made the script usage complex and error prone too. Therefore some checks and limitations shall prevent issues, data corruption and data loss.

Currently, this limitation includes preventing multiple instances from being started at the same time (as this was no requested use case until now).
If Tyron wants server.sh to support this, it would be not big coding effort to extend the existing script logic to allow one instance per port.

But again - this would be another step to increase the complexity.

Therefore my recommendation is to split the current script functionality in two scripts:

  • basic start/stop/status features of server.sh (portable according to system V init style)
  • enhanced features of server.sh

The basic usecases would build a stable foundation that not affected by the increased complexity of the enhanced features. This foundation could be used as a backend for a web GUI (which is another level of encapsulated complexity)

@Tyron I have no ambition to maintain a debian or ubuntu package, sorry.

Link to comment
Share on other sites

I set up different instances by this method:

1. Rename the vintage folder to the current version, ie VS 1.5.2

2. Install an old VS version.

3. Install the update patch for the version you want.

4. Rename the vintage folder to the current version, ie VS 1.5.2.1

5. Make new shortcuts for the exe files, naming the shortcuts after the versions.

 

Link to comment
Share on other sites

Good to hear that this works for you!

I understood that you installed the server tarfiles manually and managed your own folder structure, right?

How do you start the server? Does "shortcut" mean a mini-script like "mono VintagestoryServer.exe --datapath whatever" ?

 

Link to comment
Share on other sites

My post is a tangent of the original, this is for different instances for the game files, and may work for server files?

Also this is for using different versions 1 at a time, not multiple instances at the same time, this may work for that but I have not tried it.

Windows 10 64

This may work for servers, I'm using this for different instances for the game.

And to add shortcut I right click the exe file, create shortcut, then move it to desktop, and name it for the version its for.

So far there are 2 servers I know of, at some time each has / had a different version. So if you want to use both, and use the latest build in single, need multiple instances or you would need to install the version you are going to play on every time you want to change versions.

 

Link to comment
Share on other sites

19 hours ago, skol said:

@Tyron  how shall I start a server without handling the data folder by parameter? It would only work with the default data folder location that is coded in VintagestorySerer.exe

Oh right, good point. But then perhaps we just use relative data paths, not absolute. E.g. "../data" for a folder structure like this

  • /home/vintagestory/1.5.2
    • server
    • data
  • /home/vintagestory/1.5.1
    • server
    • data
Link to comment
Share on other sites

@TyronIn principle, thats where we came from before configurable datapath was introduced. Of course you can roll back this with all the consequences regarding backward compatiblity. But maybe it is less trouble to keep this approach and have a start/stop that is capable to handle this.

Link to comment
Share on other sites

33 minutes ago, skol said:

@TyronIn principle, thats where we came from before configurable datapath was introduced. Of course you can roll back this with all the consequences regarding backward compatiblity. But maybe it is less trouble to keep this approach and have a start/stop that is capable to handle this.

Eh, no the default behavior (=before it was configurable) is the data path to be inside the server path. As in

  • /home/vintagestory/1.5.2
    • server
      • data
  • /home/vintagestory/1.5.1
    • server
      • data
Link to comment
Share on other sites

@Tyron I know this of course. I left this detail out because it is not crucial for the decision. Before: Relative datapath per default. Now: independent datapath configurable. Point to discuss:  Relative datapath per default.

One argument for the discussion: By switching back  to relative datapath, you are forced to install the full software for each instance you want to run.

Link to comment
Share on other sites

29 minutes ago, skol said:

@Tyron I know this of course. I left this detail out because it is not crucial for the decision. Before: Relative datapath per default. Now: independent datapath configurable. Point to discuss:  Relative datapath per default.

One argument for the discussion: By switching back  to relative datapath, you are forced to install the full software for each instance you want to run.

Eh what, why would that even be a problem. A few 20-30 mb folders are completely fine. Of course you should just work with multiple copies of the game. In most cases you would want that anyway.

Link to comment
Share on other sites

@Tyron In the comments above you asked about having packages for linux distros. With a distro package it would be impossible to have multiple versions of the same package installed - so you would force the package maintainer to create a new package for each version.

Link to comment
Share on other sites

I'm not sure what the big fuss is here, multiple versions is pretty trivial with the right tools and a relative path for the data directory. Just say "${GAMEDIR}/../GameData" and go on your merry way (GAMEDIR being the directory containing the server).

In any case, I'm writing this during a short break before starting to write code to find, download, and install new VS versions from the internet. In a few days my monitor will handle everything from initial install to updates, so those who want something with more power than server.sh allows will have a good option.

Link to comment
Share on other sites

2 hours ago, Tyron said:

Eh, no the default behavior (=before it was configurable) is the data path to be inside the server path. As in

  • /home/vintagestory/1.5.2
    • server
      • data
  • /home/vintagestory/1.5.1
    • server
      • data

Just in case we want to have multiple instances of mixed versions:

/home/vs/Server1/vintagestory/1.5.2

  • /home/vs/server1/vintagestory/data/mods
  • /home/vs/server1/vintagestory/data/Playerdata
  • /home/vs/server1/vintagestory/data/Saves
  • /home/vs/server1/vintagestory/data/Backups

/home/vs/server2/vintagestory/1.5.2

  • /home/vs/server2/vintagestory/data/mods
  • /home/vs/server2/vintagestory/data/Playerdata
  • /home/vs/server2/vintagestory/data/Saves
  • /home/vs/server2/vintagestory/data/Backups

/home/vs/server3/vintagestory/1.5.1

/home/vs/server4/vintagestory/1.5.1

The main advantage here is that all files pertaining to each server are inside a unique folder with no mixing and no mistake when is time to update a server or just delete and start over.

 

P.S. Got Milo post after posting. 

 

 

Link to comment
Share on other sites

10 hours ago, skol said:

@Tyron In the comments above you asked about having packages for linux distros. With a distro package it would be impossible to have multiple versions of the same package installed - so you would force the package maintainer to create a new package for each version.

I asked about a package for a server admin tool. Not for a package of the server itself. And even then, well, one could just make a meta package called "Vintage Story Server Installer" that merely installs a installer script with which you can install multiple versions. I mean, just talking about whats possible, not what we should be making it.
 

7 hours ago, skol said:

@Milo Christiansen Don't get what you mean with big fuss. @Tyron seems to think about changing the datapath logic again. That's his choice. I he wants to keep the mentioned benefits of the --datapath option or not is his choice. I'm just waiting patiently for his decision and not part of any fuss.

Just trying to get to the best solution here. The  --dataPath arg can definitely stay available, but we could populate it with a meaningful default value. In fact, maybe it's better if we already ship the server archive with this folder structure?

  • vs_server_1.5.2.2.tar.gz
    • server.sh
    • server   (binaries)
    • data    (empty)
Link to comment
Share on other sites

3 hours ago, Tyron said:

ship the server archive with this folder structure?

  • vs_server_1.5.2.2.tar.gz
    • server.sh
    • server   (binaries)
    • data    (empty)

Please don't. That will greatly complicate updating, since you can't just wipe the old download and unpack the new one where the old one was if you have to worry about a data directory getting in the way.

Link to comment
Share on other sites

34 minutes ago, Milo Christiansen said:

Please don't. That will greatly complicate updating, since you can't just wipe the old download and unpack the new one where the old one was if you have to worry about a data directory getting in the way.

Ok, thats a valid argument

Link to comment
Share on other sites

@TyronYour wish is my command. Uploaded the current script with some tweaks and provided documentation, see https://github.com/zkol/vsadmin

The documentation should explain e.g. how to run multiple instances on different ports in parallel. Documentation how to install different versions in parallel will follow.

After this I'm going to split the script to create a basic (aka "more minimal") version that uses per default a data path relative to the script location as Tryon suggested (using internally the --dataPath arg to make this happen).

  • home/vintagestory/1.5.2
    • server => here should reside the script of v1.5.2
    • data => this would be derived from script location: ../data
  • /home/vintagestory/1.5.1
    • server => here should reside the script of v1.5.1
    • data => this would be derived from script location: ../data

I think the basic script could maybe offer a stable backend interface for other tools like the more powerful remote web GUI that @Milo Christiansen announced. I think it would be helpful if this basic script would pass every invocation parameter transparently to VintagestoryServer.exe in a way that overrides the default parameters.

Link to comment
Share on other sites

I'm working on my monitor right now, and the new version ignores and obsoletes server.sh completely by design.

Basically it does something like this:

  • <monitor binary>
  • ./Monitor/
    • Monitor settings, SSL keys, the web UI files, etc
  • ./Binaries/
    • 1.5.1.6
    • 1.5.2.5
    • etc...
  • ./GameData/
    • servername_sid (where "servername" is a user supplied value, and "sid" is an internal server ID number)
    • servername_sid
    • servername_sid
    • etc...

The path for each directory can be changed of course. The idea is, you only need one copy of any particular version installed. All the stuff that matters is in in the gamedata directory, so there is no point in having more than one copy of the binaries.

Honestly, the monitor will never use a launcher script. It keeps the servers under tight control as child processes, and talks to them via pipes. Installing, updating, launching, restarting, etc is all fully under the monitor's control. A script gets in the way of that. Sure, there are other ways to write a monitor, some arguably better, but this one is very simple. The monitor does it all, all you need to do is set it up on the machine you want to run servers on and it takes care of everything else.

I see server.sh as something for people who want a simple tool to run one server with minimum fuss, not full fledged admin tool.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.