Linuxgsm: Random generation of Rcon password can fail

[RaitoBezarius]

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.

[UltimateByte]

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

[RaitoBezarius]

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.

[dgibbs64]

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.

[UltimateByte]

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))

[RaitoBezarius]

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).

[UltimateByte]

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

[RaitoBezarius]

@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.

[UltimateByte]

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.

[dgibbs64]

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

[RaitoBezarius]

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 :/.

[dgibbs64]

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

[UltimateByte]

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

[cedarlug]

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]

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

[cedarlug]

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.

[UltimateByte]

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

[marvinlehmann]

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)

[Scarsz]

https://github.com/GameServerManagers/LinuxGSM/blob/8cf81212a23844d3fbc7d3020583e747dbfcc6ed/lgsm/functions/install_config.sh#L54 would need to be changed as well, @marvinl97

[UltimateByte]

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.

[JeroenVdb]

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

[dgibbs64]

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

[lock[bot]]

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.