Having an issue at building gsa

[luanngashi1]

Having an issue at building gsa, after line 141 i think, it all goes well untill there, but after make command, "browserslist:caniuse-lite is outdated, run the next command yarn upgrade" is shown, i cant seem to find a solution to it?

[zebity]

Hi gvm_install users,

I have got the same problem.

Environment:

Ubuntu 20.04

Install Target:

GSM 20.08

Error Details on Build:

[ 11%] Build gsa install files
yarn run v1.22.5
$ react-scripts build
Creating an optimized production build...
Browserslist: caniuse-lite is outdated. Please run the following command: npx browserslist --update-db
Browserslist: caniuse-lite is outdated. Please run next command yarn upgrade
Browserslist: caniuse-lite is outdated. Please run next command yarn upgrade
Browserslist: caniuse-lite is outdated. Please run next command yarn upgrade

Diagnostics:

I have not done any further diagnostic yet. I will post further details as part of testing.

Finally:

Thank you for going to trouble of creating install script.

Cheers,

Zebity.

[yu210148]

Hi there,

I've seen the messages about caniuse-lite as well but it hasn't seemed to be fatal for me. I'll add the yarn upgrade command to the script but npx requires installing the npm package with pulls in a whole bunch of dependencies. As far as I can tell, they're otherwise unused so it seems a bit of a waste of space and bandwidth to install them just to suppress a message that has no effect--again, as far as I can tell--on the outcome.

If there is a reason other than suppressing the warning message that I'm just not aware of let me know and I can add it in.

kev.

[zebity]

Hi @yu210148 ,

thanks for commit.

You are right about this only being a warning (which I still get even with updated script).
So issue is else where.

I did some additional testing and found:

1. Test on AWS Free Tier Ubuntu 20.04 micro.t2

This is single CPU, 1GB RAM, 9TB Storage.

Building GSM 20.08 on free tier AWS Ubuntu 20.04 appears to go into infinite loop during GSA build, so I created a "medium/t2" VM (see Test 2).

micro.t2 still fails to be build - As per my original report.

2. Run Build on AWS Ubuntu 20.04 medium.t2

This is paid tier - 2CPU, 4GB RAM, 20TB Storage

Build completed ok
Unable to access server via Web (I have opened access via AWS Security groups to SSH, HTTP & HTTPS.

Check running VM to see what ports/services are running:

$ sudo apt install net-tools
$ netstat -a | grep LISTEN
tcp        0      0 localhost:6379          0.0.0.0:*               LISTEN     
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp        0      0 localhost:postgresql    0.0.0.0:*               LISTEN     
tcp6       0      0 ip6-localhost:6379      [::]:*                  LISTEN     
tcp6       0      0 [::]:http               [::]:*                  LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
tcp6       0      0 [::]:https              [::]:*                  LISTEN     
unix  2      [ ACC ]     STREAM     LISTENING     17292

So http/htttps are only running on tcp6 and not tcp.

So disable Ubuntu/Linux ufw:

# sudo ufw disable
# sudo ufw status
Status: inactive

Can now get HTTP access, looking at UI, it show that none of the feeds are being reported even though they where downloaded as part of builit.

So rerun all the feed syncs:

sudo su gvm
/opt/gvm/sbin/greenbone-feed-sync --type GVMD_DATA
/opt/gvm/sbin/greenbone-feed-sync --type SCAP
/opt/gvm/bin/greenbone-nvt-sync
/opt/gvm/sbin/greenbone-feed-sync --type CERT
/opt/gvm/sbin/openvas --update-vt-info
exit

Now able to connect to GSM on AWS via web UI and configure scans.

My suggestions is that scipt can run so it splits SW build / install from the data sync stage, as this will help make control and diagnosis simpler.

Cheers from Oz,

Zebity

[yu210148]

Hi Zebity,

Yes, I've seen the same sort of thing when testing GVM 20 on Ubuntu 20.04 and Debian 10 where the feed updates need to be run after the installation completes. I've added language into the readme about it. From what I've seen, the trouble is that the update isn't finished when the command completes. The 'Feed Status' in the UI shows 'Update in progress' for a while after the command (e.g., /opt/gvm/sbin/greenbone-feed-sync --type GVMD_DATA) completes and running the next one (e.g., /opt/gvm/sbin/greenbone-feed-sync --type SCAP) fails to do its thing if it's run while 'Update in progress' is still shown in the UI.

Splitting out the feed updates from the builds is a good idea. I'll look into doing that at some point.

Humm, I'm not sure why it'd run into trouble on AWS but I haven't been testing on it. This business of it only listening on tcp6 is very odd. I just took a look at the same thing on one of my test VMs and got the same thing:

$ netstat -a | grep LISTEN
tcp        0      0 localhost:6379          0.0.0.0:*               LISTEN     
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp        0      0 localhost:postgresql    0.0.0.0:*               LISTEN     
tcp        0      0 localhost:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 ip6-localhost:6379      [::]:*                  LISTEN     
tcp6       0      0 [::]:http               [::]:*                  LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
tcp6       0      0 ip6-localhost:6010      [::]:*                  LISTEN     
tcp6       0      0 [::]:https              [::]:*                  LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     17700    /run/udev/control
...

So, I dropped the ufw rule allowing port 443 on IPv6 and tried to get at the UI with a browser figuring it wouldn't be able to connect. However, it connected just fine using https://<ipv4-address>. So, I dropped the rule for 443 on IPv4 and then it stopped being able to connect. I'm not sure what the story is but in my case it is talking on tcp port 443 in spite of what netstat is saying.
In other words, this works:

$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    Anywhere                  
[ 2] 443                        ALLOW IN    Anywhere                  
[ 3] 22 (v6)                    ALLOW IN    Anywhere (v6)

and this doesn't:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere                  
22 (v6)                    ALLOW       Anywhere (v6) 

So, to me this says that it's using tcp and not tcp6. Unless I'm misunderstanding something--which is entirely possible.

kev.

[zebity]

Hi @yu210148

thanks again for response.

On ufw behaviour, it will block everything unless explicitly allowed.

Hence why I disabled it completely.

In your case you have removed allow rule for https (443) but still have ufw running, so it will definitely block this port, which is what you are seeing.

Your netstat result is same as mine, so this is a function of the code itself and not your script.

I have a local Ubuntu 20.04 install and will check that and maybe disable ipv6 via kernel and see how it behaves then.

EDIT #1:

Did test with local install and disabled IPV6:

edit - /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1". <<=== disable ipv6
GRUB_CMDLINE_LINUX="ipv6.disable=1"

# sudo update-grub 
# sudo reboot

Now redo netstat -a | grep LISTEN

$ netstat -a | grep LISTEN
tcp        0      0 localhost:6379          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN     
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp        0      0 localhost:postgresql    0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:https           0.0.0.0:*               LISTEN     
unix  2      [ ACC ]     STREAM     LISTENING     39794    /opt/gvm/var/run/ospd.sock
...

So now only listening on ipv4 sockets,

I also read the man ufw man page and this indicate that the behaviour for ipv6 is different than ipv4.

With ipv6 access is implicitly enabled by default unless disabled.

This is exact opposite to ipv4 which has default disabled for incoming ports...

This explains the behaviour you are seeing.

The reason I had problem is that I had AWS security attached which only allowed ipv4 on ssh, http & https

So I assume you are on network which has ipv6 running.

END EDIT

From point of view of install script, these are small things that can be handled with work around, but just documenting in instructions to people are not surprised or frustrated.

Again thanks for script, it helps make installation much quicker and simpler.

Cheers from Oz,

Zebity.

[yu210148]

Hi Zebity,

Thanks for the info. I just added a quick note in the README pointing folks here if they run into this sort of issue. If you've got any ideas about how to phrase it better let me know 👍

kev.