September 23, 20214 yr Heya, I think there are still some issues with this container, I rebooted by unRAID Server (Cleanly, Part of Maintenance) and when starting the container, its given me a fresh install again. The first time the docker container did not start properly, the service started then stopped; Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Changing owner and group of configuration files... Starting the nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Changing owner and group of configuration files... Starting the nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Changing owner and group of configuration files... Starting the nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. When manually restarting it a few times, eventually it did a backup and then started a fresh; .... nessus/plugins-code.db.16321190631015150102 nessus/plugins-desc.db.1632119107882788674 nessus/global.db-wal nessus/global.db-shm Loading backup into new Nessus version path... Changing owner and group of configuration files... Creating symbolic links... Cleaning up deb file used for install.. Cleaning up backup files extracted and no longer required.. Starting the nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. Cached 0 plugin libs in 1msec Processing the Nessus plugins... All plugins loaded (0sec) All plugins loaded (0sec) As a test I stopped the Docker Service, and started it again, and it did the same thing. I have a backup I can restore from, but something seems a miss here. Thanks. EDIT: Looks like I cant even restore from Backup as it gets stuck in a loop, by the container not starting (same as above logs), and then eventually when you get it started, its doing its own back up and starting again. Edited September 23, 20214 yr by timethrow
December 20, 20214 yr Can someone tell me if this Nessus container is impacted by the Log4j vulnerability?
March 2, 20224 yr Hi, It appears that both the app "jbreed-nessus" and "frak-gvm" point to the same support forum. Is that intended?
October 13, 20223 yr On 3/2/2022 at 3:07 AM, thenhz said: Hi, It appears that both the app "jbreed-nessus" and "frak-gvm" point to the same support forum. Is that intended? I just experience the same thing. Tried installing openvas and didn't work on my setup.
November 7, 20223 yr Author 24 minutes ago, Tuumke said: @jbreed you still maintaining this docker? I am not actively making updates unless there is an issue that needs to be addressed given the modules get auto updated within Nessus. in regards to other support forums pointing here, that would have to be updated on the other applications template by the developer of said app. if I can get the time, I’d like to revisit this to see if it can be pinned to releases directly from the official docker repo. If so, I can simply make a pipeline kickoff to keep the in sync. Edited November 7, 20223 yr by jbreed
August 22, 20232 yr Hi, I installed frak-gvm today and the website seems to not start correctly. Trying to open the webui says that the connection failed
March 14, 20242 yr @thenhz @Tucubanito07 @Northwave Author of the frak-gvm template here (not the actual container). Sorry for pointing the support page to here. I think it was my first template and I didn't have a page on the forum to point it to, or perhaps I started with the nessus template and inherited by accident. Either way, sorry for the confusion. As I recall, the OpenVAS/GVM container takes a really long time to come up the first time as it downloads a ton of NVTs and other databases from the web. After it's done, it should come up. Just be patient and monitor the logs. It spends most of the time in the 'Updating xxx' lines then finally goes to: Your GVM 11 container is now ready to use! 9:C 14 Mar 2024 13:23:34.863 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 9:C 14 Mar 2024 13:23:34.863 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=9, just started 9:C 14 Mar 2024 13:23:34.863 # Configuration loaded Wait for redis socket to be created... Testing redis status... Redis ready. Starting PostgreSQL... waiting for server to start....2024-03-14 13:23:35.963 EDT [21] LOG: starting PostgreSQL 12.3 (Ubuntu 12.3-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, 64-bit 2024-03-14 13:23:35.964 EDT [21] LOG: listening on IPv4 address "127.0.0.1", port 5432 2024-03-14 13:23:35.964 EDT [21] LOG: could not bind IPv6 address "::1": Cannot assign requested address 2024-03-14 13:23:35.964 EDT [21] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. 2024-03-14 13:23:35.983 EDT [21] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2024-03-14 13:23:36.016 EDT [22] LOG: database system was interrupted; last known up at 2024-03-14 13:20:10 EDT ............2024-03-14 13:23:48.242 EDT [22] LOG: database system was not properly shut down; automatic recovery in progress 2024-03-14 13:23:48.249 EDT [22] LOG: redo starts at 6/AFF8A7C8 ...2024-03-14 13:23:51.958 EDT [22] LOG: invalid record length at 6/C435B610: wanted 24, got 0 2024-03-14 13:23:51.958 EDT [22] LOG: redo done at 6/C435AEA8 ....2024-03-14 13:23:55.066 EDT [21] LOG: database system is ready to accept connections done server started Updating NVTs... Updating CERT data... 2024-03-14 13:24:55.160 EDT [43] LOG: autovacuum: dropping orphan temp table "gvmd.pg_temp_5.current_credentials" rsync: failed to connect to feed.openvas.org (89.146.224.58): Connection timed out (110) rsync: failed to connect to feed.openvas.org (2a01:130:2000:127::d1): Cannot assign requested address (99) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Updating SCAP data... rsync: failed to connect to feed.openvas.org (89.146.224.58): Connection timed out (110) rsync: failed to connect to feed.openvas.org (2a01:130:2000:127::d1): Cannot assign requested address (99) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Starting Open Scanner Protocol daemon for OpenVAS... Starting Greenbone Vulnerability Manager... admin Starting Greenbone Security Assistant... Oops, secure memory pool already initialized Starting OpenSSH Server... ++++++++++++++++++++++++++++++++++++++++++++++ + Your GVM 11 container is now ready to use! + ++++++++++++++++++++++++++++++++++++++++++++++ I would also monitor the output of: netstat -tulpn | grep LISTEN and look for the 9392 port which corresponds to the Web UI port. When it finally completes, the output of that command should look like this: root@e2885647614f:/# netstat -tulpn | grep LISTEN tcp 0 0 0.0.0.0:9390 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 10/redis-server 0.0 tcp 0 0 127.0.0.11:32801 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 379/sshd: /usr/sbin tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN - tcp6 0 0 :::9392 :::* LISTEN - tcp6 0 0 :::22 :::* LISTEN 379/sshd: /usr/sbin Pointing the browser to <ip-address>:9392 should look like this: Edited March 14, 20242 yr by frakman1
July 12, 20241 yr On 3/14/2024 at 11:22 AM, frakman1 said: @thenhz @Tucubanito07 @Northwave Author of the frak-gvm template here (not the actual container). Sorry for pointing the support page to here. I think it was my first template and I didn't have a page on the forum to point it to, or perhaps I started with the nessus template and inherited by accident. Either way, sorry for the confusion. As I recall, the OpenVAS/GVM container takes a really long time to come up the first time as it downloads a ton of NVTs and other databases from the web. After it's done, it should come up. Just be patient and monitor the logs. It spends most of the time in the 'Updating xxx' lines then finally goes to: Your GVM 11 container is now ready to use! 9:C 14 Mar 2024 13:23:34.863 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 9:C 14 Mar 2024 13:23:34.863 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=9, just started 9:C 14 Mar 2024 13:23:34.863 # Configuration loaded Wait for redis socket to be created... Testing redis status... Redis ready. Starting PostgreSQL... waiting for server to start....2024-03-14 13:23:35.963 EDT [21] LOG: starting PostgreSQL 12.3 (Ubuntu 12.3-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, 64-bit 2024-03-14 13:23:35.964 EDT [21] LOG: listening on IPv4 address "127.0.0.1", port 5432 2024-03-14 13:23:35.964 EDT [21] LOG: could not bind IPv6 address "::1": Cannot assign requested address 2024-03-14 13:23:35.964 EDT [21] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. 2024-03-14 13:23:35.983 EDT [21] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2024-03-14 13:23:36.016 EDT [22] LOG: database system was interrupted; last known up at 2024-03-14 13:20:10 EDT ............2024-03-14 13:23:48.242 EDT [22] LOG: database system was not properly shut down; automatic recovery in progress 2024-03-14 13:23:48.249 EDT [22] LOG: redo starts at 6/AFF8A7C8 ...2024-03-14 13:23:51.958 EDT [22] LOG: invalid record length at 6/C435B610: wanted 24, got 0 2024-03-14 13:23:51.958 EDT [22] LOG: redo done at 6/C435AEA8 ....2024-03-14 13:23:55.066 EDT [21] LOG: database system is ready to accept connections done server started Updating NVTs... Updating CERT data... 2024-03-14 13:24:55.160 EDT [43] LOG: autovacuum: dropping orphan temp table "gvmd.pg_temp_5.current_credentials" rsync: failed to connect to feed.openvas.org (89.146.224.58): Connection timed out (110) rsync: failed to connect to feed.openvas.org (2a01:130:2000:127::d1): Cannot assign requested address (99) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Updating SCAP data... rsync: failed to connect to feed.openvas.org (89.146.224.58): Connection timed out (110) rsync: failed to connect to feed.openvas.org (2a01:130:2000:127::d1): Cannot assign requested address (99) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Starting Open Scanner Protocol daemon for OpenVAS... Starting Greenbone Vulnerability Manager... admin Starting Greenbone Security Assistant... Oops, secure memory pool already initialized Starting OpenSSH Server... ++++++++++++++++++++++++++++++++++++++++++++++ + Your GVM 11 container is now ready to use! + ++++++++++++++++++++++++++++++++++++++++++++++ I would also monitor the output of: netstat -tulpn | grep LISTEN and look for the 9392 port which corresponds to the Web UI port. When it finally completes, the output of that command should look like this: root@e2885647614f:/# netstat -tulpn | grep LISTEN tcp 0 0 0.0.0.0:9390 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 10/redis-server 0.0 tcp 0 0 127.0.0.11:32801 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 379/sshd: /usr/sbin tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN - tcp6 0 0 :::9392 :::* LISTEN - tcp6 0 0 :::22 :::* LISTEN 379/sshd: /usr/sbin Pointing the browser to <ip-address>:9392 should look like this: Since the support link was redirected, I'll have to post here. It looks like the source project is now deprecated so frak-gvm may need to be deprecated or replaced. https://github.com/Secure-Compliance-Solutions-LLC/GVM-Docker/commit/d5fa0ed1edf63faf06230270c7c006bb5d013a80?diff=split&w=0 CC @Squid in case this should be added to Fix Common Problems
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.