starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-26 06:35:54 +03:00

[GH-ISSUE #538] UT2004: Install Nginx and configure to serve maps/textures? #435

New issue

Closed

opened 2026-02-27 02:01:26 +03:00 by kerem · 9 comments

kerem commented

2026-02-27 02:01:26 +03:00

Owner

Originally created by @nicktimko on GitHub (Dec 1, 2015).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/538

The download speeds in UT2004 are a joke, especially nowadays. The solution is to redirect download requests to another HTTP server. Could I add an option during install that would have a local Nginx serve the Maps, Textures, Music, Sounds, etc. folders or would that be outside the scope?

Originally created by @nicktimko on GitHub (Dec 1, 2015). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/538 The download speeds in UT2004 are a joke, especially nowadays. The solution is to redirect download requests to another HTTP server. Could I add an option during install that would have a local Nginx serve the Maps, Textures, Music, Sounds, etc. folders or would that be outside the scope?

kerem closed this issue

2026-02-27 02:01:26 +03:00

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Dec 9, 2015):

That's an interesting idea becuase you can have the same issue on source servers. It could be an install option to allow a standalone lightweight webserver be installed and use a non standard port then the config will point fastdl to it. I certainly like the idea. My time is extremely limited currently so don't except this feature from me anytime soon. If you have the expertise to implement this idea I'm happy to review and merge this.

@dgibbs64 commented on GitHub (Dec 9, 2015): That's an interesting idea becuase you can have the same issue on source servers. It could be an install option to allow a standalone lightweight webserver be installed and use a non standard port then the config will point fastdl to it. I certainly like the idea. My time is extremely limited currently so don't except this feature from me anytime soon. If you have the expertise to implement this idea I'm happy to review and merge this.

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@nicktimko commented on GitHub (Dec 9, 2015):

Is using sudo/root a no-go; i.e. would I have to

Install the HTTP server binaries locally w/o sudo/root (no sudo apt-get install nginx) and/or
Run the server from within a basic account (this is fairly straightforward.)

@nicktimko commented on GitHub (Dec 9, 2015): Is using sudo/root a no-go; i.e. would I have to 1. Install the HTTP server binaries locally w/o sudo/root (no `sudo apt-get install nginx`) **and/or** 2. Run the server from within a basic account (this is fairly straightforward.)

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@andreblue commented on GitHub (Dec 12, 2015):

You could look at serving them thru php. The cli has a built in web server or even python
https://wiki.python.org/moin/WebServers

@andreblue commented on GitHub (Dec 12, 2015): You could look at serving them thru php. The cli has a built in web server or even python https://wiki.python.org/moin/WebServers

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@jaredballou commented on GitHub (Dec 26, 2015):

My opinion here is that this feature is outside the scope of the LGSM core use case, and therefore I am by default opposed to it until I can see a good reason to expand the program. Is it something a lot of users would use, probably, but we have to determine if the usefulness and ability imparted by this feature are worth the greatly increased complexity and security/stability profile.

My suggestion would be having an external tool for this if we tackle it at all, because when one sits back and actually looks at the scope of a tool like this, it quickly becomes overwhelming.

How do we account for existing web server installs?
How do we make the installation secure on all supported platforms?
How do we integrate the multiple games we support into a standard deployment method?
What sort of tooling is needed to ensure that the "source" data and "web" data are in sync and correct?
What sort of permission and security issues arise from adding another service to our users' machines?
What other sort of processing is needed to make this work, i.e. in Source we also would preferably bzip the files?
How do we maintain and ensure state consistency of the web server config when we add/remove games or game servers?
How much more work is needed in the core program to integrate these features, i.e. making updates to all child gameserver configurations to enable FastDL functionality?
How do we explain and document this in a way that users can understand?

That's just off the top of my head, I'm sure there are more. This is a major undertaking that is deceptively simple, and opens up a whole new can of worms in regards to the things it can potentially break, and the risk of using the tool in terms of security and encapsulation of functionality.

My vote would be to forego this entirely and point at a third-party source of information that our users can reference to set these things up on their own, rather than take it on to an already overwhelming todo list.

@jaredballou commented on GitHub (Dec 26, 2015): My opinion here is that this feature is outside the scope of the LGSM core use case, and therefore I am by default opposed to it until I can see a good reason to expand the program. Is it something a lot of users would use, probably, but we have to determine if the usefulness and ability imparted by this feature are worth the greatly increased complexity and security/stability profile. My suggestion would be having an external tool for this if we tackle it at all, because when one sits back and actually looks at the scope of a tool like this, it quickly becomes overwhelming. - How do we account for existing web server installs? - How do we make the installation secure on all supported platforms? - How do we integrate the multiple games we support into a standard deployment method? - What sort of tooling is needed to ensure that the "source" data and "web" data are in sync and correct? - What sort of permission and security issues arise from adding another service to our users' machines? - What other sort of processing is needed to make this work, i.e. in Source we also would preferably bzip the files? - How do we maintain and ensure state consistency of the web server config when we add/remove games or game servers? - How much more work is needed in the core program to integrate these features, i.e. making updates to all child gameserver configurations to enable FastDL functionality? - How do we explain and document this in a way that users can understand? That's just off the top of my head, I'm sure there are more. This is a major undertaking that is deceptively simple, and opens up a whole new can of worms in regards to the things it can potentially break, and the risk of using the tool in terms of security and encapsulation of functionality. My vote would be to forego this entirely and point at a third-party source of information that our users can reference to set these things up on their own, rather than take it on to an already overwhelming todo list.

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@nicktimko commented on GitHub (Dec 27, 2015):

How do we account for existing web server installs?
- Nginx would run as an independent process on it's own port
How do we make the installation secure on all supported platforms?
- If Nginx isn't available for a platform, then don't install it as an option, revert to status quo
How do we integrate the multiple games we support into a standard deployment method?
- I don't know what other games would benefit from a separate static-file HTTP hosting server. Just start with UT2004 to test the waters?
What sort of tooling is needed to ensure that the "source" data and "web" data are in sync and correct?
- For UT2004 I just configured Nginx to dig through the Maps, then Textures, then Sounds... folders that are also used by the game itself, so it's guaranteed. If you needed for some other game to include their analog of UT's System folder (which has the config.ini file with passwords, the Nginx conf could be set to exclude such files)
What sort of permission and security issues arise from adding another service to our users' machines?
- The Nginx service would run with the uid of the game service user. I trust Nginx more than any other game, but the user gets to opt-in to it anyways. Security for things like the config.ini mentioned above would need to be considered by developers that add the FastDL/redirection functionality in for each game that can use it. Nginx's configuration is quite flexible and can include/exclude files based on regex. The increased instantaneous bandwidth might make it easier to DoS, but game servers seem easy to DoS anyways. Nginx has rate-limiting options if need be.
What other sort of processing is needed to make this work, i.e. in Source we also would preferably bzip the files?
- For my server I didn't bother compressing them because going from UT2004 to Nginx was ~100x faster, and I was lazy and didn't care about another ~2x speedup from compression. By not bothering with this, the sync worry (above) was moot.
How do we maintain and ensure state consistency of the web server config when we add/remove games or game servers?
- Each game service could have it's own Nginx process (easy). Future iterations could use the same process by hosting them from subdirectories (e.g. the game server running on 1.2.3.4:5678 could redirect to 1.2.3.4:8080/5678/...).
How much more work is needed in the core program to integrate these features, i.e. making updates to all child gameserver configurations to enable FastDL functionality?
- Add the functionality as developers see fit.
How do we explain and document this in a way that users can understand?
- I'd envision something like (if applicable and/or support added by linuxgsm for the game):
  1. If you want to enable fast HTTP downloading, install Nginx first for your OS and ensure it's on the PATH
  2. If the installer detects nginx on the path, it will ask you if you want to use it for game content downloading. If you say "yes", then it will:
    - Create a config file for Nginx
    - Set the Nginx process to run alongside the gameserver when you ./server start
    - Alter the game config files to redirect to the Nginx server
  3. Run the game service as normal.

@nicktimko commented on GitHub (Dec 27, 2015): - How do we account for existing web server installs? - Nginx would run as an independent process on it's own port - How do we make the installation secure on all supported platforms? - If Nginx isn't available for a platform, then don't install it as an option, revert to status quo - How do we integrate the multiple games we support into a standard deployment method? - I don't know what other games would benefit from a separate static-file HTTP hosting server. Just start with UT2004 to test the waters? - What sort of tooling is needed to ensure that the "source" data and "web" data are in sync and correct? - For UT2004 I just configured Nginx to dig through the Maps, then Textures, then Sounds... folders that are also used by the game itself, so it's guaranteed. If you needed for some other game to include their analog of UT's System folder (which has the `config.ini` file with passwords, the Nginx conf could be set to exclude such files) - What sort of permission and security issues arise from adding another service to our users' machines? - The Nginx service would run with the uid of the game service user. I trust Nginx more than any other game, but the user gets to opt-in to it anyways. Security for things like the `config.ini` mentioned above would need to be considered by developers that add the FastDL/redirection functionality in for each game that can use it. Nginx's configuration is quite flexible and can include/exclude files based on regex. The increased instantaneous bandwidth might make it easier to DoS, but game servers seem easy to DoS anyways. Nginx has rate-limiting options if need be. - What other sort of processing is needed to make this work, i.e. in Source we also would preferably bzip the files? - For my server I didn't bother compressing them because going from UT2004 to Nginx was ~100x faster, and I was lazy and didn't care about another ~2x speedup from compression. By not bothering with this, the sync worry (above) was moot. - How do we maintain and ensure state consistency of the web server config when we add/remove games or game servers? - Each game service could have it's own Nginx process (easy). Future iterations could use the same process by hosting them from subdirectories (e.g. the game server running on `1.2.3.4:5678` could redirect to `1.2.3.4:8080/5678/...`). - How much more work is needed in the core program to integrate these features, i.e. making updates to all child gameserver configurations to enable FastDL functionality? - Add the functionality as developers see fit. - How do we explain and document this in a way that users can understand? - I'd envision something like (if applicable and/or support added by linuxgsm for the game): 1. If you want to enable fast HTTP downloading, install Nginx first for your OS and ensure it's on the PATH 2. If the installer detects `nginx` on the path, it will ask you if you want to use it for game content downloading. If you say "yes", then it will: - Create a config file for Nginx - Set the Nginx process to run alongside the gameserver when you `./server start` - Alter the game config files to redirect to the Nginx server 3. Run the game service as normal.

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Dec 27, 2015):

I agree with @jaredballou with making this a separate project in itself or some sort of addon. I know that source engine servers would also benefit from this feature. Even with source servers quite a lot of FastDL is being super seeded by Steam Workshop.

I could see how a separate script that could grab, compress and move the files to a dir and have an nginx webserver on its own port could work well. LGSM has a compression feature for UT99 & UT2K4 in place that already compresses all maps in to another dir. Maybe this could be modified to move the maps to a dir of choosing that is running an nginx instance.

Also being a separate project people who dont use LGSM could benefit from it.

I can see @nicktimko has a clear idea on how this could be implemented. But @jaredballou makes some good points on how this feature could become a large undertaking in itself.

So with that in mind I definitely recommend @nicktimko work on a project that can achieve this as de-coupled but maybe compatible with LGSM. It could become the first LGSM add-on.

At the very least it would be good to have documentation written and available on the wiki for users who wish to implement this feature on there own using the ut map compressor. I could even point users to the documentation on the main website.

@dgibbs64 commented on GitHub (Dec 27, 2015): I agree with @jaredballou with making this a separate project in itself or some sort of addon. I know that source engine servers would also benefit from this feature. Even with source servers quite a lot of FastDL is being super seeded by Steam Workshop. I could see how a separate script that could grab, compress and move the files to a dir and have an nginx webserver on its own port could work well. LGSM has a compression feature for UT99 & UT2K4 in place that already compresses all maps in to another dir. Maybe this could be modified to move the maps to a dir of choosing that is running an nginx instance. Also being a separate project people who dont use LGSM could benefit from it. I can see @nicktimko has a clear idea on how this could be implemented. But @jaredballou makes some good points on how this feature could become a large undertaking in itself. So with that in mind I definitely recommend @nicktimko work on a project that can achieve this as de-coupled but maybe compatible with LGSM. It could become the first LGSM add-on. At the very least it would be good to have documentation written and available on the wiki for users who wish to implement this feature on there own using the ut map compressor. I could even point users to the documentation on the main website.

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@jaredballou commented on GitHub (Jan 6, 2016):

This is a good idea, and being broken off as its own tool would be a good idea. I definitely see the value in something like this, if we want to write up a spec and start looking at what it would take to put it together I'm game.

@jaredballou commented on GitHub (Jan 6, 2016): This is a good idea, and being broken off as its own tool would be a good idea. I definitely see the value in something like this, if we want to write up a spec and start looking at what it would take to put it together I'm game.

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Jul 12, 2016):

I am closing this as no update. No action required to be taken by LGSM devs

@dgibbs64 commented on GitHub (Jul 12, 2016): I am closing this as no update. No action required to be taken by LGSM devs

kerem commented

2026-02-27 02:01:26 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 19, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 19, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.