Problem with elastic-stack-installation.sh

[rick-vini]

Hello,

I encountered a small problem with the unattended-installation script from the documentation. When trying to run it on Debian 11 or Ubuntu 20.04 distributions I got the following two errors:

/root/elastic-stack-installation.sh: line 556: [: -lt: expected unary operator
/root/elastic-stack-installation.sh: line 302: / 2 : syntax error: expected operand (error token is "/2")

I found that to fix those problems it was only necessary to change the value "Mem:" by "Mem.:" in the script elastic-stack-installation.sh. It was just missing the dot after Mem in those cases.

Hope this helps.

[rauldpm]

Hello @rick-vini

I have transferred this issue to the wazuh-packages repository since in principle it is a problem with the installer itself and not with documentation.

I can not reproduce the problem that you indicate in debian11 and ubuntu20 following the same steps in the documentation, lines 301 and 302 correspond to:

ram_gb=$(free -g | awk '/^Mem:/{print $2}')
ram=$(( ${ram_gb} / 2 ))

The free -g command in ubuntu20 and debian11 returns the value Mem: not Mem.:

If we accept your change, we get precisely the error you mentioned, which occurs since $(free -g | awk '/^Mem.:/{print $2}') does not return any value as shown in the following image:

With the script (with dot):

#!/bin/bash
ram_gb=$(free -g | awk '/^Mem.:/{print $2}')
echo $ram_gb
ram=$(( ${ram_gb} / 2 ))
echo $ram

We get the output: : / 2 : syntax error: operand expected (error token is "/ 2 ")

With the script (without dot):

#!/bin/bash
ram_gb=$(free -g | awk '/^Mem:/{print $2}')
echo $ram_gb
ram=$(( ${ram_gb} / 2 ))
echo $ram

We get the output: 3 and 1

That said, have you modified the script in any way? Can you run the command free -g and free -g | awk '/^Mem:/{print $2}' directly in the terminal and show us the result? It is weird that the output offered by free changes.

Regarding the error of line 556:

if [ ${cores} -lt 2 ] || [ ${ram_gb} -lt 3700 ]; then

I have not been able to reproduce it either, even adding the dot you comment (you can see that it does not get memory value):

With the script (without dot):

#!/bin/bash
cores=$(cat /proc/cpuinfo | grep processor | wc -l)
ram_gb=$(free -m | awk '/^Mem:/{print $2}')
echo $cores
echo $ram_gb
if [ ${cores} -lt 20 ] || [ ${ram_gb} -lt 100000 ]; then
  echo $cores
fi

I get the values: 2, 3931 and 2 without errors with -lt

If i add . to Mem:, i still have no error, but it can not get the memory value:

#!/bin/bash
cores=$(cat /proc/cpuinfo | grep processor | wc -l)
ram_gb=$(free -m | awk '/^Mem.:/{print $2}')
echo $cores
echo $ram_gb
if [ ${cores} -lt 20 ] || [ ${ram_gb} -lt 100000 ]; then
  echo $cores
fi

At first it occurs to me that this may be due to the brackets, can you try to modify the script and use double brackets?

[[ $ {cores} -lt 20 ]] || [[ ... ]]

Finally, to secure the system, can you run the following command to check the version of the systems you are commenting on to make sure there is no difference and share it with us?

cat /etc/os-release

Regards, Raúl.

[rick-vini]

Hello @rauldpm,

thanks for the feedback.

After seeing your answer, I verified that the problem is in the language used in the OS. When I use pt_BR the free command returns "Mem.:" :

When the language is en_US the free command returns "Mem:" :

I've corrected the language and everything worked out in a new test. Thank you for your attention.

Regards, Ricardo.

[rauldpm]

Hello @rick-vini

It is true that it is a situation that is not controlled but because there is a large amount of possibilities in terms of language. Thank you for notifying us, we will try to find some generic way that allows us to obtain this.

Anyway, from what I see in the image, the free -g command still shows Mem.: while using en_US locale. If you have managed to fix it, great, but as I said, we will investigate how to obtain these values in the best generic way possible.

Regards, Raúl.

[rick-vini]

Hi @rauldpm

Sorry, I upload the wrong image file. That one was before de reboot. This is the correct one for the en_US:

Anyway, I've corrected the language and everything worked out in a new test. Thank you for your attention.

Regards, Ricardo.