starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-27 15:15:56 +03:00

[GH-ISSUE #625] Bug report feature #501

New issue

Closed

opened 2026-02-27 02:01:55 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @jaredballou on GitHub (Jan 12, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/625

I would like to start a discussion about a "bug report" feature baked into the scripts. What I am thinking is, that we can collect some basic information such as:

OS/architecture
Game in use
Versions of scripts and game
Package listing
Last 100 logs of pertinent console/server logs
Per-game specifics, i.e. for Source servers the contents of addons/sourcemod/plugins or for Unreadl engine the active mutators.

I'm sure there are a lot of other items that would be useful, but I think if we can come up with the bulk of the data points, and then have a system which either uploads that to PasteBin or even create a GitHub issue, it would solve a lot of the initial confusion of a user reporting an issue and us having to ask the same questions.

Questions we'd need to answer:

How do we want to receive and triage these issues?
Do we want a feature where a server crashing automatically sends a report?
How do we make sure users know about the feature, and opt-in to the reporting?
How do we ensure we don't accidentally expose passwords or other sensitive data as a result of this?
This may significantly increase the bug reports, how do we want to handle initial triage and assignment?

Originally created by @jaredballou on GitHub (Jan 12, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/625 I would like to start a discussion about a "bug report" feature baked into the scripts. What I am thinking is, that we can collect some basic information such as: - OS/architecture - Game in use - Versions of scripts and game - Package listing - Last 100 logs of pertinent console/server logs - Per-game specifics, i.e. for Source servers the contents of addons/sourcemod/plugins or for Unreadl engine the active mutators. I'm sure there are a lot of other items that would be useful, but I think if we can come up with the bulk of the data points, and then have a system which either uploads that to PasteBin or even create a GitHub issue, it would solve a lot of the initial confusion of a user reporting an issue and us having to ask the same questions. Questions we'd need to answer: - How do we want to receive and triage these issues? - Do we want a feature where a server crashing automatically sends a report? - How do we make sure users know about the feature, and opt-in to the reporting? - How do we ensure we don't accidentally expose passwords or other sensitive data as a result of this? - This may significantly increase the bug reports, how do we want to handle initial triage and assignment?

kerem

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

closed this issue
added the
type: feature
label

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Jan 15, 2016):

I see some interesting ideas there.

"Last 100 logs of pertinent console/server logs"

As the log cleaner cleans logs after 7 days, and considering the size that logs can get, 100 may be a bit too much.
Otherwise, i pretty much agree.

I also think nothing should be sent by the script without user's agreement, and changing that setting could be done easily at any moment.

Another question would be : What port would this use ?

About your interrogations :

How do we want to receive and triage these issues?

I guess the script couldn't make issues on github + it would be a pain to manage.
A good way could be to make the script communicate with a defined server, then send it to the server. The problem is that it would open the way to fake reports, so we'd need to consider securing it. Then we'd have an interface to visualize those reports. That interface should be made so it's not a pain to fetch all the data, as it will probably be simple text only.

Do we want a feature where a server crashing automatically sends a report?

Would be cool. Would even be nice to have an automatic report to a master server, just to say that a server is running and have a count of how many people are running servers from any game. As long as users accept feedback. That way we could collect some data to help us improve the script.

How do we make sure users know about the feature, and opt-in to the reporting?

At install, it could ask if user wants that feature. For report, could be a dedicated function, or the dev-debug function that sends it.
Another question would be : How to store this setting ?
But here i've got an idea that could be used for other things too : Put settings in an lgsm.conf file that would be at the root path (same as the main script). I should make a suggestion for that, as i think it would be cool to have a ./scriptname config function, that would make an assistant for that, and create the lgsm.conf file. At install, it would ask if you want to change default server ports and settings. That way, people could either use the assistant, or edit the lgsm.conf, and they would have no need to edit the server script. That would raise two questions here : How to support custom game settings without writing a new script for every game ? (i already think of a way). And how do we support multiple servers with that way of doing ? (got ideas too).

How do we ensure we don't accidentally expose passwords or other sensitive data as a result of this?

As some logs can include steam password and logins, they need to be removed before sending, especially if those reports are public. The server recieving them could make a double check to remove them.

This may significantly increase the bug reports, how do we want to handle initial triage and assignment?

Would be cool first, that every machine, or every server installation gets a unique ID to help sorting this. Then the user should get an important notification given by the script with a "report number ID" to give to us when he's coming on github to report a bug.

Here are my thoughts at the moment. Hope that helps.

@UltimateByte commented on GitHub (Jan 15, 2016): I see some interesting ideas there. > "Last 100 logs of pertinent console/server logs" As the log cleaner cleans logs after 7 days, and considering the size that logs can get, 100 may be a bit too much. Otherwise, i pretty much agree. I also think nothing should be sent by the script without user's agreement, and changing that setting could be done easily at any moment. Another question would be : What port would this use ? About your interrogations : > How do we want to receive and triage these issues? I guess the script couldn't make issues on github + it would be a pain to manage. A good way could be to make the script communicate with a defined server, then send it to the server. The problem is that it would open the way to fake reports, so we'd need to consider securing it. Then we'd have an interface to visualize those reports. That interface should be made so it's not a pain to fetch all the data, as it will probably be simple text only. > Do we want a feature where a server crashing automatically sends a report? Would be cool. Would even be nice to have an automatic report to a master server, just to say that a server is running and have a count of how many people are running servers from any game. As long as users accept feedback. That way we could collect some data to help us improve the script. > How do we make sure users know about the feature, and opt-in to the reporting? At install, it could ask if user wants that feature. For report, could be a dedicated function, or the dev-debug function that sends it. Another question would be : How to store this setting ? But here i've got an idea that could be used for other things too : Put settings in an lgsm.conf file that would be at the root path (same as the main script). I should make a suggestion for that, as i think it would be cool to have a ./scriptname config function, that would make an assistant for that, and create the lgsm.conf file. At install, it would ask if you want to change default server ports and settings. That way, people could either use the assistant, or edit the lgsm.conf, and they would have no need to edit the server script. That would raise two questions here : How to support custom game settings without writing a new script for every game ? (i already think of a way). And how do we support multiple servers with that way of doing ? (got ideas too). > How do we ensure we don't accidentally expose passwords or other sensitive data as a result of this? As some logs can include steam password and logins, they need to be removed before sending, especially if those reports are public. The server recieving them could make a double check to remove them. > This may significantly increase the bug reports, how do we want to handle initial triage and assignment? Would be cool first, that every machine, or every server installation gets a unique ID to help sorting this. Then the user should get an important notification given by the script with a "report number ID" to give to us when he's coming on github to report a bug. Here are my thoughts at the moment. Hope that helps.

kerem commented

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

Author

Owner

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

Good thoughts, I think we are on the same page. I meant 100 lines not logs, d'oh :)

In regards to the config thing, I'm two steps ahead of you, check my latest issue to see what I've been doing to minimize the headaches of supporting all the games and saving configs. It's trivial to add more variables to the system I have, so tat could be done.

For the rest, it's probably good if we just mock up a copy of the script with some instrumentation and try it out from our local machines. I just need a bit more detail on what we actually need, and I can throw something together.

@jaredballou commented on GitHub (Jan 19, 2016): Good thoughts, I think we are on the same page. I meant 100 lines not logs, d'oh :) In regards to the config thing, I'm two steps ahead of you, check my latest issue to see what I've been doing to minimize the headaches of supporting all the games and saving configs. It's trivial to add more variables to the system I have, so tat could be done. For the rest, it's probably good if we just mock up a copy of the script with some instrumentation and try it out from our local machines. I just need a bit more detail on what we actually need, and I can throw something together.

kerem commented

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

Author

Owner

@UltimateByte commented on GitHub (Feb 4, 2016):

Let's say this is pretty similar to https://github.com/dgibbs64/linuxgsm/issues/586
Closing this, but link it for record !

@UltimateByte commented on GitHub (Feb 4, 2016): Let's say this is pretty similar to https://github.com/dgibbs64/linuxgsm/issues/586 Closing this, but link it for record !

kerem commented

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

Author

Owner

@lock[bot] commented on GitHub (Apr 1, 2019):

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 (Apr 1, 2019): 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.