Jump to content


Photo
- - - - -

Howto: Dedicated server on Linux! Plus, added coolness


  • Please log in to reply
17 replies to this topic

#1 Diablo999

Diablo999
  • Posts: 1

Posted 01 July 2012 - 11:20

Hi folks,

this is my first post on this forum, so let´s make it a good one, shall we. ;) I do hope this is the right board, couldn´t find a more appropriate section.

So is there a native linux port of the DServer.exe now, you might ask? No, but it runs very (!) good and stable under wine, at least on my side of things. But there are some pitfalls, that I have fallen into, so I will hopefully cover that, so it is time and pain and suffering saved for everyone else.

Basically this is aimed at admins of remote servers, which are only reachable by means of "MS Remote Desktop Client" or VNC or stuff like that to provide a graphical user interface. But as long as you can use ssh or Putty to connect to and control the server you won´t even need such things, see for added coolness below.
You do have to run many commands in a terminal window though, think MS-DOS command prompt on steroids. Don´t worry it is half as bad as it sounds.

And for the added coolness, I will show how to run the dedicated server, so it looks like a local application on your home desktop, even though the dedicated server it is actually running on might be half way around the globe, and I don´t mean VNC or Remote Desktop. And a little further down the road there will be the possibility to automatically start the DServer upon server restarts, without any human intervention whatsoever! But that will have to wait until we have the basic stuff running, meaning wine.

First, I´d like to point you to:

http://en.wiki.riseo...edicated_server" onclick="window.open(this.href);return false;">http://en.wiki.riseo...ght.com/index.p … ted_server
and
A dedicated server on a remote machine for dummies

since those pretty much cover the general way to set the server up, would you be using a MS Windows machine. I am going to cover the differences, mainly getting wine to work and installing, running DServer.exe is very straight forward from then on.

(NOTE: Don´t download ROF_Free2Play_Client_1025b.zip, it won´t unzip properly! Download
http://www.riseoffli..._Demo_1021b.exe" onclick="window.open(this.href);return false;">http://www.riseoffli...emo.com/ROF_Dem … _1021b.exe
instead and use the rof_updater.exe to update to the latest version.)


I am using a Debian 6.0.5 (aka squeeze aka stable as of now) box, so some parts here contain Debian specific commands (which should apply to Ubuntu just as well) but I suppose there are equivalents in non-Debian based distributions for them (contributions welcome).

So let´s get right to it. There are two options to running in wine:

1. Use wine up to and including version 1.1.26
2. Patch and compile wine (>=1.1.27) yourself (no worries I will try and make this as painless as possible, so anybody who is able to insert smileys in chats should be able to follow)

Please note, that I´m trying to make this as easy as possible for any non-tech-savvy user, so those with experience in linux should get along without reading any further (Feedback and contributions are very welcome though). For all the others which this Howto is aimed at, please let me know if I overcomplicate things or where there is something unclear. Don´t hesitate to ask.

Some glossary:
    root# <command>means that <command> must be run as root/superuser/admin whatever you like to call it. There are several ways to do this, either type "su" in the shell prompt and supply your root password before actually running the command (or 'su -c "<command>"' for that matter) or if you have sudo set up then "sudo <command>" and supplying your user password is equivalent. Note that you shouldn´t run as root if not neccessary, so do yourself the favour to "exit" the root shell after those commands by either executing the command "exit" or by hitting CTRL+D. user$ <command>means that <command> can and should be run as the normal user you login as. (Running commands as root unnecessarily is just asking for trouble! You have been warned, twice!) #without anything else and somewhere inline either in a command line or anywhere else shall be a comment and does nothing other than be a bit more verbose about what is about to hapen or whatever.


So now let´s really get started and take the gloves off.

Option 1
  • Install wine (<=1.1.26)
  • root# apt-get install wineIn Debian squeeze you will get wine 1.0.1 installed which will install RoF Demo and run DServer just fine, but other programs (like Iron Front dedicated server) might not want to run properly with such an admittedly ancient version of wine, which is the reason, I had to find Option 2 the hard way.
  • Install ROF_ICE_Unlimited_Demo_1021b.exe
  • user$ wine path/to/ROF_ICE_Unlimited_Demo_1021b.exeNote: This will unpack silently to a folder called temp_RoF in your present working directory (type "pwd" to get where this is). I only make this a note, because the folder wasn´t removed after intallation. So if you ever run low on disk space you might want to remember this or you could use the contents of temp_RoF for reinstallation, since that skips the initial unpacking procedure. After the installation is finished, that post-install screen will popup and ask what else to install/do, uncheck everything except "Install MS VC++ 2005 Reditributable" unless you actually want to play RoF under wine (haven´t tried that).
  • Update the game content
  • # change present working directory after finding where rof_updater.exe is and run rof_updater # this is a nested shell command to do the magic for you # just copy from your browser (without the "user$" and paste to the terminal with SHIFT+INSERT or middle mouse click) user$ cd "$(dirname "$(find ~/.wine -name rof_updater.exe)")" && wine rof_updater.exe Let the rof_updater do its thing. After successfully updating the game content the DirectX Setup window will popup, just click cancel there. Because of that there will be an error message about a failed update, just ignore it and click "Cancel" in the RoF updater as well, the game content will have been updated properly nonetheless.
  • Run DServer.exe
  • You should have edited your .sds file as shown on the wiki, see the link above. # again a little shell magic to find and change directory to where DServer.exe is and run it user$ cd "$(dirname "$(find ~/.wine -name DServer.exe)")" user$ wine DServer.exe [path/to/sds-file.sds] path/to/sds-file.sds is optional which is why it is in [], omit the [] when you actually run the command, but you can always use the open dialog from the menu.


Option 2
  • Get the build dependencies for wine
  • root# apt-get build-dep wineThis will install all the packages the Debian developers use for building wine-1.0.1 on a Debian squeeze system.
  • Get the source code of wine
  • http://sourceforge.n...e/files/Source/" onclick="window.open(this.href);return false;">http://sourceforge.n...e/files/Source/ As of this writing the current stable version is 1.4.1 and I recommend downloading it.
  • Unpack the source code archive
  • # You should be in a directory where you have write permission # I usually use ~/src (Note the ~ which is a shorthand for your home directory) # make the directory if it doesn´t exist already user$ mkdir -p ~/src # -p switch to stop the complaints if the directory already exists user$ cd ~/src user$ tar xvjf /path/to/wine-1.4.1.tar.bz2 # You´ll see lots of files shown on the terminal # now go to the new directory wine-1.4.1 which was just created during unpacking user$ cd wine-1.4.1
  • Patch the source code
  • Go to http://bugs.winehq.o...rs=1&format=raw" onclick="window.open(this.href);return false;">http://bugs.winehq.o...ttachment.cgi?i … format=raw and save it as say wine-RoF-no-hang-on-exit.patch but the name and file ending don´t matter at all, you just have to remember what you called it and where you put it. Preferably save it directly in the source directory ~/src/wine-1.4.1/ # Check, whether the "patch" program is installed and if not install it user$ patch –version # If you see some output about the version, copyright, warranty etc. you´re good to go. # If not, install it via root# apt-get install patch # Double check if we are still in the source directory user$ pwd # Should output something like /home/.../src/wine-1.4.1 # Alright and now let´s patch it up: user$ patch -p1 < wine-RoF-no-hang-on-exit.patch patching file server/sock.c Hunk #1 succeeded at 595 (offset 7 lines).
  • Configure and compile wine
  • # speedup "make" by running in parallel user$ alias make="make -j4" # This means, that everytime the command "make" is to be executed # the shell will replace it with "make -j4", which is just the same # but make will run 4 tasks at a time. So replace "4" with the number # of cores your CPU has (the number_of_cores*2 for a hyperthreaded Processor) # run ./configure and disable some unnecissary code we won´t use or need user$ ./configure –disable-tests # at the very end there will most certainly be some warnings # about some missing build dependencies. You can´t have them all can you? ;) # Let´s ignore these for now, if we are on a Debian squeeze system, # because apt-get build-dep got us the essential ones already. # Otherwise, if you opted to not use apt-get build-dep or are running # a different system, please refer to the WineHQ-Wiki. # # now let´s do the real compiling. user$ make depend && make # This will produce all kinds of cryptic output for the non-technical # user and it will take quite long, in my case about 20 minutes. # Grab a coffee and enjoy this new kind of screensaver. ;-D # [...] # Now if everything went well, and why shouldn´t it, you will see # "Wine build complete" and proceed to installing it by root# make install Great, now proceed with Option 1 step 2.


Note: fixme:… messages on the terminal are not error messages, you can get rid of them by prepending WINEDEBUG=fixme-all before wine on the command line, i.e.
user$ WINEDEBUG=fixme-all wine DServer.exe
Added coolness 1

Download and install "Window Switch" by following the instructions for your respective linux distribution. Also install the Windows version on your local desktop but don´t connect to your server yet!

Now on your remote host run
user$ xpra start :333The number after the : doesn´t really matter but should be somewhere above 100 I´d say, since some other graphical user interfaces like VNC or Remote Dektop might wan´t to claim this range. I don´t know all the reserved ranges though. If you get an error just try another one.
What this does is start a dummy display where you can redirect the graphical output (windows) of any application that has such thing like our dear DServer.exe or rof_updater.exe.

So let´s try it
# cd /path/to/where/the/DServer.exe/is user$ cd "$(dirname "$(find ~/.wine -name DServer.exe)")" user$ DISPLAY=:333 wine DServer.exe [path/to/sds-file.sds] See Option 1 step 4 for reference, the only difference here is the prepended DISPLAY=:333, which tells wine to use this display instead of the default one. And what will you see on the display you are looking at? Exactly nothing, which is the whole point of this exercise.

Now let´s configure a connection in the window switch client on your local machine, see http://winswitch.org...tion/start.html" onclick="window.open(this.href);return false;">http://winswitch.org...tion/start.html for reference:

Left mouse click on the system tray icon brings up the menu, click on "New connection" and enter the IP address or hostname of the remote machine, enter the username you started wine and xpra with. You can either enter the password right there or leave it empty and click "connect", You will then be asked to confirm the SSH Host key fingerprint, just do so and if you haven´t provided your password already, do so now.
Wait a little and you will see a balloon message from the window switch tray icon, cheering out the successful connection, now click that icon again and see the changed menu. The interesting part is the "unknown", click there and then in the submenu resume.
Et voila, there is the window of the DServer.exe. So the application itself runs on the remote machine but redirects its windows to xpra, which "parks" it on a dummy display while you are not connected and redirects it again when you connect via window switch.

Now this is the essential building block to enable running DServer on machine reboot on the remote host, because there is no need to login to a GUI Desktop of any kind to start it. This will be part of "Added coolness 2", where we will see how we can put this all together into a nice, selfrestarting service (or daemon as it is called in linux), which will start running as soon as the machine is up.

Now show me how that would even be possible in Windows! :-P


To be continued… (need a break right now) ;)

TODO: "Added coolness 2" How to actually make the DServer autostart with the operating system on reboots.
  • 0

#2 Fishbreath

Fishbreath
  • Posts: 84

Posted 01 December 2012 - 15:13

I'm pleased to announce that this still works just fine as of 1.028b!

I built wine 1.4.1 myself, but I had to get xpra/winswitch working before I could do anything else (no other remote desktop stuff for me). Tips:

1. The winswitch package installs xpra. xpra start :333 has an implied password-file argument, so if you want to stop xpra for RAM savings you have to xpra stop :333 –password-file ~/.winswitch/server/sessions/333/session.pass
2. xpra sessions started from the command line are only visible in the Windows winswitch client if they're started from the same user: e.g. if you're logged in as fishbreath on the shell and you start an xpra session, you need a connection in the winswitch client that goes to fishbreath@remote.
3. Winswitch has options for key-based ssh authentication; all you have to do is hit Configure -> Security in the connection's menu.
4. DServer.exe only runs correctly in <RoF>/bin_game/release. If you try to do something like (wine bin_game/release/DServer.exe) it crashes unhelpfully.

I also had to get dependencies for wine manually, since apt-get build-dep wasn't working for me. You can find the list on the wine wiki.
  • 0

#3 =FB=Vaal

=FB=Vaal
  • Developer
  • Posts: 2849

Posted 01 December 2012 - 17:39

Wow, why have I missed this thread…
Tnx!
  • 0

#4 Jason_Williams

Jason_Williams
  • Producer
  • Posts: 3467
  • LocationLas Vegas, NV USA

Posted 01 December 2012 - 21:10

Wow… I missed this thread too! Nice work Diablo!

:S!:

Jason
  • 0

#5 Fishbreath

Fishbreath
  • Posts: 84

Posted 03 December 2012 - 14:10

Performance is good (surprisingly good?) on my Xen VPS. Not only is it virtual, it also only has a gigabyte of dedicated RAM plus two of swap partition, and two 2ghz Xeon cores. It runs with two players, four spawned AI planes, and a lot of flak activity at a hitch-free 50 SPS. I only have two friends who play RoF, so once I get both of them on at the same time, I'll try three players and six AIs.

Some of it might be that DServer.exe reserves about 2.5gb of address space right when it starts (per htop), but only peaked at about 100mb in resident memory (i.e. physical memory and swap) with two players and four AI planes. I was expecting RAM to be the main bottleneck, but it doesn't seem like that's the case in my simple experimentation. Once I get some more people onto the server flying a wider variety of aircraft, I'll see, but if performance holds up with larger numbers of people and more complicated missions, the Linux/wine route could be a much cheaper hosting solution than Windows dedicated servers: my VPS costs me $9 a month, and it also runs a webserver and voice chat while running RoF. Even if more hardware is necessary for bigger missions with more aircraft types, though, Linux VPSes can be had for cheaper than Windows machines.
  • 0

#6 Laser

Laser
  • Posts: 1611

Posted 03 December 2012 - 14:59

One question - shouldn't it run better 'sober' (i.e. without wine)? = Could it be possible to have a slim dedicated server (without any graphics display at all) built as a "native" executable, directly for Linux? Sure it's easy to ask, if the tools to build the dedicated server are specific to Windows, not many chances.
  • 0

#7 Fishbreath

Fishbreath
  • Posts: 84

Posted 03 December 2012 - 15:15

I needed the VC++ redistributable for DServer to run. It could potentially be compiled for Linux (they'd have to do a different interface, or no interface at all, and probably fiddle with some API calls). As long as they don't do anything to really wreck performance under wine, I'm not sure it would be a worthwhile use of 777's time. DServer is basically just math and probably some Windows-style network and thread-management code, and that sort of translation is exactly what wine is best at.
  • 0

#8 Laser

Laser
  • Posts: 1611

Posted 03 December 2012 - 17:32

I needed the VC++ redistributable for DServer to run. It could potentially be compiled for Linux (they'd have to do a different interface, or no interface at all, and probably fiddle with some API calls). As long as they don't do anything to really wreck performance under wine, I'm not sure it would be a worthwhile use of 777's time. DServer is basically just math and probably some Windows-style network and thread-management code, and that sort of translation is exactly what wine is best at.

This pops out just the opposite idea - to check if there is something 'wrecking performance' with DServer-wine combo, and optimizing … wine to avoid exactly that :lol: (with wine being open source)
  • 0

#9 Fishbreath

Fishbreath
  • Posts: 84

Posted 03 December 2012 - 20:18

The Wine FAQ suggests there are some things that are architecturally problematic—relying on very precise thread timing, or on threads being locked to specific cores—because of Linux kernel design choices. Fortunately, I'd call both of those bad practices, so I suspect we'll skate.

Maybe sometime this week, if there are some volunteers volunteers, I could host a test night, and see if, say, 32 players is possible on my virtual hardware. If it is, I don't think I would have any qualms about recommending Linux VPSes as RoF servers.
  • 0

#10 Fishbreath

Fishbreath
  • Posts: 84

Posted 11 December 2012 - 17:45

So, my VPS (2x2ghz Xeon cores, 1gb RAM, 2gb swap) runs a little dogfight server fine, but a small co-op mission (12 AI planes) slowed it down to 40SPS pretty steadily. It wasn't immediately obvious what the issue was, since htop didn't show CPU or RAM usage to the point where I'd worry about it.

If someone out there wants to send me $20 in Paypal money, I can snag a better VPS (8 cores, 2gb of RAM, no web server running) for a month and see if that machine, which is nearer to the recommended specs for a Linux server, is capable of running a dedicated server with large missions, lots of scripting and AI, and more players. I'd be glad to do that research for the community, and maybe even maintain a Linux dedicated server helper package, but it's near Christmas and I can't be spending the extra $20 just yet.
  • 0

#11 Fishbreath

Fishbreath
  • Posts: 84

Posted 17 December 2012 - 15:57

No takers, it looks like. Come January or February I should be able to snag a fancier VPS myself for a month or so, and when I've done that I'll report on what such a server can handle.
  • 0

#12 Ketzerfreund

Ketzerfreund
  • Posts: 52

Posted 15 February 2013 - 16:56

I needed the VC++ redistributable for DServer to run. It could potentially be compiled for Linux (they'd have to do a different interface, or no interface at all, and probably fiddle with some API calls). As long as they don't do anything to really wreck performance under wine, I'm not sure it would be a worthwhile use of 777's time. DServer is basically just math and probably some Windows-style network and thread-management code, and that sort of translation is exactly what wine is best at.

This pops out just the opposite idea - to check if there is something 'wrecking performance' with DServer-wine combo, and optimizing … wine to avoid exactly that :lol: (with wine being open source)

A way used by the now defunct Loki Games, who ported a couple of Windows games to Linux until roughly a decade ago, was to build the game under Wine and directly link the game code against Wine's substitute .dll files in the process instead of real ones from Windows. That was pretty much the whole trick. Loki Games chose games to port to Linux that already ran well as originals in a usual Wine environment without much hassle, therefore Loki went under, for their ports were always much more expensive than the originals.

Anyway, while I'm not interested in having my own server, I did try out RoF on the Linux side of my machine (openSUSE 12.1). And it runs. I had no problems whatsoever playing a couple of missions, no graphical glitches or anything. Getting networking functional under Wine seems to be the bigger challenge than the graphics these days (though, I don't know how it would've fared with an ATI/AMD gfx card; as soon as I switched from ATI to Nvidia a couple of years ago, many more 3D games suddenly started working flawlessly under Wine), at least in my experience, but even starting a career went fine, and that does need you to be logged into your account. Should it be prudent to release a Linux-port of the RoF client one day - and it may well become that, with Steam currently establishing a gaming market for Linux, while Indies have been roaming this field for a while now - making use of the Wine libraries, ironing out the bumps in the Winelib sources while being at it, shouldn't be an excessively difficult ordeal.
  • 0

#13 Fishbreath

Fishbreath
  • Posts: 84

Posted 05 April 2013 - 15:09

Be warned: during the last update before 1.030, I had to edit the post-installation actions batch script to not do anything so that the update would succeed and the server would work. It seemed to be okay this time, but I imagine that wine doesn't have very solid support for Windows batch files. Whenever a RoF update includes one, you'll have to edit it to do nothing then do what it wants you to do by hand, I think.
  • 0

#14 Fishbreath

Fishbreath
  • Posts: 84

Posted 15 June 2013 - 13:26

More adventures in updating: the things the post-update script does some important things, and my friends and I were having some desynchronization issues after I'd updated to 1.030b.

To fix it, I uninstalled everything, reinstalled the 1.028b package from the website, and then ran the updater. This time, I didn't edit the post-update script. The update claimed to fail, but it only failed on DirectX installation, and the rest of the update and post-update script did what it was supposed to; despite the alleged failure of the update, it actually worked (or at least well enough to host). On top of that, the updater seems smarter now, and verifies that the post-update script is correct before it runs it, so the old trick of editing the script won't work anymore.

So, going forward, I think what I'll do is this:
1. Keep the 1.028b installer around.
2. Delete the whole game directory a full update.
3. Run the installer.
4. Run the updater, first in update mode, then recovery mode.
5. Put my missions and dedicated config files back into their directories.

It's a bit more of a hassle, but hopefully it'll keep us from running into problems. I'm not sure if anyone else out there is running a Linux dedicated server, but hopefully this information will be useful for someone down the line.
  • 0

#15 Fishbreath

Fishbreath
  • Posts: 84

Posted 06 November 2013 - 18:13

I've updated my VPS to a nicer model, and I found that the 1.031 installer unzips and installs correctly with the Linux command line tools. Just a heads-up if anyone's looking for a newer archival version.
  • 0

#16 =FB=Vaal

=FB=Vaal
  • Developer
  • Posts: 2849

Posted 07 September 2014 - 16:55

You are running DServer on a server with gui or not?

I tried (without gui) and received an error
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
err:systray:initialize_systray Could not create tray window
  • 0

#17 Fishbreath

Fishbreath
  • Posts: 84

Posted 08 September 2014 - 13:25

Sort of: the first post describes using xpra, a no-gui tool for remotely displaying GUIs, to provide a fake display for the server so you can monitor it remotely from a desktop. If you don't need the remote access, you can try using Xvfb by itself:

$ Xvfb :333 -screen 0 1024x768x32
$ DISPLAY=:333 wine DServer.exe

I haven't tested that out, but it should work fine. Good luck! Let me know if it works for you.
  • 0

#18 =FB=Vaal

=FB=Vaal
  • Developer
  • Posts: 2849

Posted 08 September 2014 - 18:03

Sort of: the first post describes using xpra, a no-gui tool for remotely displaying GUIs, to provide a fake display for the server so you can monitor it remotely from a desktop. If you don't need the remote access, you can try using Xvfb by itself:

$ Xvfb :333 -screen 0 1024x768x32
$ DISPLAY=:333 wine DServer.exe

I haven't tested that out, but it should work fine. Good luck! Let me know if it works for you.

Works!
Xvfb :333 -screen 0 1024x768x24
needed only a little change command
  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users