starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 14:15:59 +03:00

[GH-ISSUE #1308] Random generation of Rcon password can fail #1012

New issue

Closed

opened 2026-02-27 02:54:50 +03:00 by kerem · 22 comments

kerem commented

2026-02-27 02:54:50 +03:00

Owner

Originally created by @RaitoBezarius on GitHub (Feb 9, 2017).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1308

Originally assigned to: @marvinlehmann, @dgibbs64, @Scarsz, @UltimateByte, @cedarlug on GitHub.

Using Ansible to provision a machine under CentOS 7.0 with LinuxGSM and CS:GO in particular (here is the used playbook).

I found out that auto-install will hang even when it has finished downloading the serverfiles.
Whereas, when typing the very same command over SSH manually, the auto-install completes immediately.

After long session of strace-ing the bash script, the culprit was the following line of install_config.sh (L54).

It seemed that execution of these processes was so fast, that it would break the pipe and cause the grep command to fail with grep: write error, eventually hanging the bash process.

An easy fix is to, just, plainly remove the random generation, and put a dummy string.

After that, Ansible is able to complete the playbook and the provisioning.

I think that random generation of Rcon password must be rewritten, or, that auto-install offer more choice to the configuration (I'd prefer, if possible, to handle the Rcon password myself rather than getting an elegant choice for your everyone user.)

As a workaround, what I do: run auto-install sufficiently long for install_config.sh to appear.
Monkey-patch it with sed and re-run auto-install normally.

Originally created by @RaitoBezarius on GitHub (Feb 9, 2017). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1308 Originally assigned to: @marvinlehmann, @dgibbs64, @Scarsz, @UltimateByte, @cedarlug on GitHub. Using Ansible to provision a machine under CentOS 7.0 with LinuxGSM and CS:GO in particular ([here is the used playbook](https://gist.github.com/RaitoBezarius/8f4d3df3cdb8182c75ba570b3bdf67a8)). I found out that `auto-install` will hang even when it has finished downloading the serverfiles. Whereas, when typing the very same command over SSH manually, the `auto-install` completes immediately. After long session of `strace`-ing the bash script, the culprit was the [following line](https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/install_config.sh#L54) of `install_config.sh` (L54). It seemed that execution of these processes was so fast, that it would break the pipe and cause the `grep` command to fail with `grep: write error`, eventually hanging the bash process. An easy fix is to, just, plainly remove the random generation, and put a dummy string. After that, Ansible is able to complete the playbook and the provisioning. I think that random generation of Rcon password must be rewritten, *or*, that `auto-install` offer more choice to the configuration (I'd prefer, if possible, to handle the Rcon password myself rather than getting an elegant choice for your everyone user.) As a workaround, what I do: run `auto-install` sufficiently long for `install_config.sh` to appear. Monkey-patch it with `sed` and re-run `auto-install` normally.

kerem

2026-02-27 02:54:50 +03:00

closed this issue
added the
type: bug
label

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

Thanks for reporting.

An easy fix is to, just, plainly remove the random generation, and put a dummy string.

Well, this is not a fix, this is just removing the feature.

What happens on the given machine if you run the specified line itself?

random=$(strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 8 | tr -d '\n'; echo); echo $random

It's true however that the config var settings lack some checks to be "failproof".
https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/install_config.sh#L52-L70

@UltimateByte commented on GitHub (Feb 9, 2017): Thanks for reporting. > An easy fix is to, just, plainly remove the random generation, and put a dummy string. Well, this is not a fix, this is just removing the feature. What happens on the given machine if you run the specified line itself? `random=$(strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 8 | tr -d '\n'; echo); echo $random` It's true however that the config var settings lack some checks to be "failproof". https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/install_config.sh#L52-L70

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@RaitoBezarius commented on GitHub (Feb 9, 2017):

Thank you for your answer. As I said:

Whereas, when typing the very same command over SSH manually, the auto-install completes immediately.

It implies that this line:

random=$(strings /dev/urandom | grep -o ':alnum:' | head -n 8 | tr -d '\n'; echo); echo $random

is also executed well.

Also, I tried separately and it returned to me a random string as expected.

Well, this is not a fix, this is just removing the feature.

Right, I just believe that the auto-install process could let an option to opt-out of this automatic generation, as advanced users may prefer to not rely on it.

@RaitoBezarius commented on GitHub (Feb 9, 2017): Thank you for your answer. As I said: > Whereas, when typing the very same command over SSH manually, the auto-install completes immediately. It implies that this line: > random=$(strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 8 | tr -d '\n'; echo); echo $random is also executed well. Also, I tried separately and it returned to me a random string as expected. > Well, this is not a fix, this is just removing the feature. Right, I just believe that the `auto-install` process could let an option to opt-out of this automatic generation, as advanced users may prefer to not rely on it.

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 9, 2017):

I don't think getting rid of the random rcon password generation is a good option or having it as an optional (as it opens a can of worms for me). However finding the cause of the issue and fixing it is. There may be other options for random password generation that wont cause this issue.

@dgibbs64 commented on GitHub (Feb 9, 2017): I don't think getting rid of the random rcon password generation is a good option or having it as an optional (as it opens a can of worms for me). However finding the cause of the issue and fixing it is. There may be other options for random password generation that wont cause this issue.

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

I just crashed my bash session with
strings /dev/urandom | grep -o '[[:alnum:]]'
WTF 😆 It's hanging and i can't even click on it anymore, my mice pointer is stuck as the window resize cursor when i point over it. And i can reproduce this weird behavior.

Yeah, seems this function is not very clean. :o))

@UltimateByte commented on GitHub (Feb 9, 2017): I just crashed my bash session with `strings /dev/urandom | grep -o '[[:alnum:]]'` WTF 😆 It's hanging and i can't even click on it anymore, my mice pointer is stuck as the window resize cursor when i point over it. And i can reproduce this weird behavior. Yeah, seems this function is not very clean. :o))

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@RaitoBezarius commented on GitHub (Feb 9, 2017):

Well, if what we want is a random token, openssl rand -base64 12 could be sufficient, assuming openssl as a dependency (which is relatively okay, I believe).

@RaitoBezarius commented on GitHub (Feb 9, 2017): Well, if what we want is a random token, `openssl rand -base64 12` could be sufficient, assuming `openssl` as a dependency (which is relatively okay, I believe).

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

Well, the less we add dependencies, the better.
Found a nice one that we could work with:
date | md5sum

@UltimateByte commented on GitHub (Feb 9, 2017): Well, the less we add dependencies, the better. Found a nice one that we could work with: `date | md5sum`

kerem commented

2026-02-27 02:54:50 +03:00

Author

Owner

@RaitoBezarius commented on GitHub (Feb 9, 2017):

@UltimateByte Yes, but it's not really randomly "secure".
If I could know the timezone of the server and the creation date of the server, then, I could get the random token, though, I don't know how much security do you need.

@RaitoBezarius commented on GitHub (Feb 9, 2017): @UltimateByte Yes, but it's not really randomly "secure". If I could know the timezone of the server and the creation date of the server, then, I could get the random token, though, I don't know how much security do you need.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

Would require you to know the exact second the command was ran.
For an RCON password it's not too bad.

There are many ways to generate random numbers though. I'll try to find a funny and efficient one.

@UltimateByte commented on GitHub (Feb 9, 2017): Would require you to know the exact second the command was ran. For an RCON password it's not too bad. There are many ways to generate random numbers though. I'll try to find a funny and efficient one.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 9, 2017):

I think the date option is quite clever however we only need a few characters..

Is this random enough?

date | md5sum | md5sum | md5sum | cut -c3-8

@dgibbs64 commented on GitHub (Feb 9, 2017): I think the date option is quite clever however we only need a few characters.. Is this random enough? ```date | md5sum | md5sum | md5sum | cut -c3-8```

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@RaitoBezarius commented on GitHub (Feb 9, 2017):

Piping to md5sum won't change the randomness of the resulting string as long as it is deterministic.
Also, piping too many commands may cause again the broken pipe problem :/.

@RaitoBezarius commented on GitHub (Feb 9, 2017): Piping to `md5sum` won't change the randomness of the resulting string as long as it is deterministic. Also, piping too many commands may cause again the broken pipe problem :/.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 9, 2017):

Yeah as @UltimateByte says you would need to know the exact second the command was run which is pretty unlikely. This might work well as it adds nanoseconds in to the command

date +"%T.%N" | md5sum | cut -c3-8

@dgibbs64 commented on GitHub (Feb 9, 2017): Yeah as @UltimateByte says you would need to know the exact second the command was run which is pretty unlikely. This might work well as it adds nanoseconds in to the command ```date +"%T.%N" | md5sum | cut -c3-8```

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

uptime would be better, since load usage into it is almost impossible to track
We can mix stuff in it just for the fun.

echo "$(uptime) $(date) $(whoami)" | md5sum | cut -c1-8

(echo is required otherwise commands mess up)

Edit: Mixing @dgibbs64 's trick:

echo "$(uptime) $(date +"%T.%N") $(whoami)" | md5sum | cut -c1-8

@UltimateByte commented on GitHub (Feb 9, 2017): uptime would be better, since load usage into it is almost impossible to track We can mix stuff in it just for the fun. `echo "$(uptime) $(date) $(whoami)" | md5sum | cut -c1-8` (echo is required otherwise commands mess up) Edit: Mixing @dgibbs64 's trick: `echo "$(uptime) $(date +"%T.%N") $(whoami)" | md5sum | cut -c1-8`

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@cedarlug commented on GitHub (Feb 9, 2017):

The processes in a pipe succession cannot 'execute too fast', they are serially scheduled and their 3 streams are bound or conjoined before being scheduled.

I'd like to see the raw strace. grep shouldn't give a write error unless /dev/urandom isn't available, isn't readable, or other more tangible error is present.

Personally, I've used this for random password generation which omits strings:

genpasswd() {
        local l=$1
        [ "$l" == "" ] && l=16
        tr -dc A-Za-z0-9_ < /dev/urandom | head -c ${l} | xargs
}

invoked as genpasswd outputs a 16-character password. Or invoked as genpasswd 8 to produce an 8-character password, etc.

One issue with cropping md5sum is that you'll never get upper-case nor underscore in the output.

@cedarlug commented on GitHub (Feb 9, 2017): The processes in a pipe succession cannot 'execute too fast', they are serially scheduled and their 3 streams are bound or conjoined before being scheduled. I'd like to see the raw strace. grep shouldn't give a write error unless /dev/urandom isn't available, isn't readable, or other more tangible error is present. Personally, I've used this for random password generation which omits strings: ```bash genpasswd() { local l=$1 [ "$l" == "" ] && l=16 tr -dc A-Za-z0-9_ < /dev/urandom | head -c ${l} | xargs } ``` invoked as `genpasswd` outputs a 16-character password. Or invoked as `genpasswd 8` to produce an 8-character password, etc. One issue with cropping md5sum is that you'll never get upper-case nor underscore in the output.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@cedarlug commented on GitHub (Feb 9, 2017):

Related
Related #2 - Apparently ansible doesn't like to cat /dev/urandom.

@cedarlug commented on GitHub (Feb 9, 2017): [Related](https://github.com/ansible/ansible/issues/12459) [Related #2](https://github.com/richardskumat/gogsi/issues/1) - Apparently ansible doesn't like to `cat /dev/urandom`.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@cedarlug commented on GitHub (Feb 9, 2017):

Suggested fix, which keeps it out of the useless uses of cat awards*:

random=$(tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 | xargs)

*which oddly enough doesn't appear to be a thing anymore.

@cedarlug commented on GitHub (Feb 9, 2017): Suggested fix, which keeps it out of [the useless uses of cat](http://porkmail.org/era/unix/award.html) awards*: ```bash random=$(tr -dc A-Za-z0-9_ < /dev/urandom | head -c 8 | xargs) ``` *which oddly enough doesn't appear to be a thing anymore.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

In the worst case, my suggestion is probably random enough for the purpose.

@UltimateByte commented on GitHub (Feb 9, 2017): In the worst case, my suggestion is probably random enough for the purpose.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@marvinlehmann commented on GitHub (Feb 10, 2017):

Just a note: https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/install_config.sh#L86 (could also be changed when a solution was found)

@marvinlehmann commented on GitHub (Feb 10, 2017): Just a note: https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/install_config.sh#L86 (could also be changed when a solution was found)

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@Scarsz commented on GitHub (Feb 16, 2017):

github.com/GameServerManagers/LinuxGSM@8cf81212a2/lgsm/functions/install_config.sh (L54) would need to be changed as well, @marvinl97

@Scarsz commented on GitHub (Feb 16, 2017): https://github.com/GameServerManagers/LinuxGSM/blob/8cf81212a23844d3fbc7d3020583e747dbfcc6ed/lgsm/functions/install_config.sh#L54 would need to be changed as well, @marvinl97

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@UltimateByte commented on GitHub (May 31, 2017):

May the first one being available fix this soon, since this also causes trouble on regular installs as per #1453 and @Scarsz and @marvinlehmann kinda found out.

@UltimateByte commented on GitHub (May 31, 2017): May the first one being available fix this soon, since this also causes trouble on regular installs as per #1453 and @Scarsz and @marvinlehmann kinda found out.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@JeroenVdb commented on GitHub (Jul 26, 2017):

I have the same problems as @RaitoBezarius when settings up an AWS CloudFormation template for LGSM. strings /dev/urandom keeps running on 100% CPU.

@JeroenVdb commented on GitHub (Jul 26, 2017): I have the same problems as @RaitoBezarius when settings up an AWS CloudFormation template for LGSM. `strings /dev/urandom` keeps running on 100% CPU.

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Sep 21, 2017):

I have now added the fix @cedarlug suggested. Hopefully that will work :)

@dgibbs64 commented on GitHub (Sep 21, 2017): I have now added the fix @cedarlug suggested. Hopefully that will work :)

kerem commented

2026-02-27 02:54:51 +03:00

Author

Owner

@lock[bot] commented on GitHub (Sep 21, 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 (Sep 21, 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.