Orpheus123 Posted May 13, 2020 Share Posted May 13, 2020 Updated to the new version of the container and the errors are gone. Successfully ran my first scan. Thanks for the fix. Quote Link to comment
chilled_penguin Posted May 14, 2020 Share Posted May 14, 2020 Hi, so everything is working except i moved to traefik 2 and can*t get it working with it. Did you by any chance change your traefik as well? Without the proxy i got it running. :/ Kind regards Quote Link to comment
jbreed Posted May 14, 2020 Author Share Posted May 14, 2020 10 hours ago, chilled_penguin said: Hi, so everything is working except i moved to traefik 2 and can*t get it working with it. Did you by any chance change your traefik as well? Without the proxy i got it running. Kind regards I currently don't have an environment to test this and haven't used Nessus via a proxy before. Based on past posts here, it appears others have had it working. If there is something I can add to the Nessus container to make it easily configurable, then I'll happily add it. Just need some guidance on what is needed to get it working, or if I have the time I'll see about making a use case in my lab to test with it. I'll have to do some research on what changes are made to Nessus for doing this. Quote Link to comment
volcs0 Posted June 7, 2020 Share Posted June 7, 2020 Thank you for this docker. I'm getting an error when I try to launch the GUI: Your connection is not private Attackers might be trying to steal your information from MyServerIP (for example, passwords, messages, or credit cards). Learn more NET::ERR_CERT_INVALID Is this a problem? I can't start it in Chrome, but if I use a different browser, I can override these warnings and get to the startup page... Thanks. Quote Link to comment
jbreed Posted June 7, 2020 Author Share Posted June 7, 2020 1 minute ago, volcs0 said: Thank you for this docker. I'm getting an error when I try to launch the GUI: Your connection is not private Attackers might be trying to steal your information from MyServerIP (for example, passwords, messages, or credit cards). Learn more NET::ERR_CERT_INVALID Is this a problem? I can't start it in Chrome, but if I use a different browser, I can override these warnings and get to the startup page... Thanks. This is due to using a self signed certificate, which is generally the same issue when accessing the UnRaid login page. To fix this you must create a local certificate authority, create a CSR, sign the certificate with the root CA, then upload it to the application. You would then need to install this root CA into your local machine you access these from, which if I recall Chrome uses the same CA store as we explorer although Firefox you have to import it into directly. Most of the time you can simply bypass this by choosing I understand or something of that nature to continue to the page. This I believe is listed under an "advanced" button on the page I'm unsure on which chrome settings would need to change to permit this, but I imagine there is likely a browser setting that allows you to accept the certificate if this isn't available. Not many people go through the hassle of setting up a local CA to get the green lock. Quote Link to comment
Chezro Posted July 17, 2020 Share Posted July 17, 2020 Hoping this is the right topic: I'm having trouble installing greenbone. I can get to the webui but I can't log in. I have another docker on the main port so I changed GB's webui port. Does this template require the default port or is there something I'm missing? Quote Link to comment
jbreed Posted July 18, 2020 Author Share Posted July 18, 2020 On 7/17/2020 at 8:25 AM, Chezro said: Hoping this is the right topic: I'm having trouble installing greenbone. I can get to the webui but I can't log in. I have another docker on the main port so I changed GB's webui port. Does this template require the default port or is there something I'm missing? Chezro, you can change the port mapping on either of the containers. For doing it here, modify host port 1 on the docker configuration page. This will map the port you set to the containers internal port 8843. Quote Link to comment
Art4security Posted August 3, 2020 Share Posted August 3, 2020 Had this set up on 1 server and did a few scans, it worked great. Went to set it up on another server and the webgui will not connect on either server now. Any suggestions or advice on how I can remedy this? Here is a copy of the log file from one of the servers. Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Extracting packaged nessus debian package: Nessus 8.10.0... Changing owner and group of configuration files... Creating symbolic links... Cleaning up... Starting Nessus : . [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Mon Aug 3 22:35:07 2020][29.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete [Mon Aug 3 22:35:08 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0xb4ba] : Error: Could not find function 0xf00001af call stack: ----------- [0b4ba:Saucer::Client.request+67] call, addr(0xf00001af), -, # ???? () [C func] [0d572:TelemetryService.submit+39] refcall, fp(1), string#629, # from: fp(1) [0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit() [12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0) [12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry() [2dd57:main+13298] call, addr(0x12c1b), -, # main() [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0x2a039] : Invalid index for hash table call stack: ----------- [2a039:utils::parseResponse+45] larray, r#26, fp(2), [0d575:TelemetryService.submit+42] call, addr(0x2a00c), -, # utils::parseResponse() [0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit() [12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0) [12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry() [2dd57:main+13298] call, addr(0x12c1b), -, # main() [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=51][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=52][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-desc.db][fd=22][map_sz=0][file_size=178979610]: complete [Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2789806079]: complete [Mon Aug 3 22:35:45 2020][29.1][op=_qdb_map_lowmem][name=plugins-code.db.15964941251616699263][fd=7][map_sz=0][file_size=2789806079]: complete [Mon Aug 3 22:35:46 2020][29.1][op=_qdb_map_lowmem][name=plugins-desc.db.15964941451807749847][fd=19][map_sz=0][file_size=178979610]: complete Quote Link to comment
SimplifyAndAddCoffee Posted February 4, 2021 Share Posted February 4, 2021 Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Extracting packaged nessus debian package: Nessus 8.10.0... Changing owner and group of configuration files... Creating symbolic links... Cleaning up... Starting Nessus : . [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Thu Feb 4 11:00:52 2021][30.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete [Thu Feb 4 11:01:02 2021][30.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd779] : Error: Could not find function 0xf000020c call stack: ----------- [0d779:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07bb2:Mug::Connection.on_client+46] refcall, fp(2), string#707, # from: fp(2) [22d1e:!anon5+4] refcall, fp(-2), string#4934, # from: fp(-2) [2eb54:main+10121] eop, -, -, [Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-desc.db][fd=19][map_sz=0][file_size=187756524]: complete [Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2967368547]: complete [Thu Feb 4 11:02:05 2021][30.1][op=_qdb_map_lowmem][name=plugins-code.db.16124364741952786213][fd=7][map_sz=0][file_size=2967368547]: complete [Thu Feb 4 11:02:08 2021][30.1][op=_qdb_map_lowmem][name=plugins-desc.db.1612436525562718452][fd=19][map_sz=0][file_size=187756524]: complete similar issue to above poster. I last ran this back in november and it worked fine, but now it fails to update plugins or run scans. Quote Link to comment
timethrow Posted April 2, 2021 Share Posted April 2, 2021 Heya, Is there any chance the container can be updated to use a more recent version of Nessus please, as the current version reports Vulnerabilities with itself (1 High, 2 Low). I have been manually updating it myself, by downloading the deb file and running "dpkg -i <path_to_deb>" which seems to work, but would be useful to have it done by default. Thanks. Quote Link to comment
jbreed Posted April 3, 2021 Author Share Posted April 3, 2021 On 4/2/2021 at 6:14 AM, timethrow said: Heya, Is there any chance the container can be updated to use a more recent version of Nessus please, as the current version reports Vulnerabilities with itself (1 High, 2 Low). I have been manually updating it myself, by downloading the deb file and running "dpkg -i <path_to_deb>" which seems to work, but would be useful to have it done by default. Thanks. Sure thing! Let me know how it looks. Quote Link to comment
jbreed Posted April 3, 2021 Author Share Posted April 3, 2021 On 2/4/2021 at 4:20 AM, SimplifyAndAddCoffee said: Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Extracting packaged nessus debian package: Nessus 8.10.0... Changing owner and group of configuration files... Creating symbolic links... Cleaning up... Starting Nessus : . [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Thu Feb 4 11:00:52 2021][30.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete [Thu Feb 4 11:01:02 2021][30.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd779] : Error: Could not find function 0xf000020c call stack: ----------- [0d779:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07bb2:Mug::Connection.on_client+46] refcall, fp(2), string#707, # from: fp(2) [22d1e:!anon5+4] refcall, fp(-2), string#4934, # from: fp(-2) [2eb54:main+10121] eop, -, -, [Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-desc.db][fd=19][map_sz=0][file_size=187756524]: complete [Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2967368547]: complete [Thu Feb 4 11:02:05 2021][30.1][op=_qdb_map_lowmem][name=plugins-code.db.16124364741952786213][fd=7][map_sz=0][file_size=2967368547]: complete [Thu Feb 4 11:02:08 2021][30.1][op=_qdb_map_lowmem][name=plugins-desc.db.1612436525562718452][fd=19][map_sz=0][file_size=187756524]: complete similar issue to above poster. I last ran this back in november and it worked fine, but now it fails to update plugins or run scans. Strange. I'll see if I can replicate this. I did just update the core .deb components which may have been an issue; however, I personally haven't seen this. If having issues still, possibly consider re-deploying on a new volume mount or deleting the container with the volume data and re-deploying. What's strange in your error is it appears to be related to the nessusd_www_server6 plugin calling a function that is/was unavailable. Have you tried going to the console and manually updating the plugins? Quote Link to comment
timethrow Posted April 4, 2021 Share Posted April 4, 2021 19 hours ago, jbreed said: Sure thing! Let me know how it looks. Just updated to the new container this morning, all looks good, no issues from me. I have run my regular network scan and it completed as expected. Thank you for doing that, most appreciated Quote Link to comment
bilboswaggins Posted June 9, 2021 Share Posted June 9, 2021 Hey, Sorry if this has already been addressed but I keep getting the "Report outdated / end-of-life Scan Engine / Environment (local)" Installed GVM Libraries (gvm-libs) version: 11.0.1 Latest available GVM Libraries (gvm-libs) version: 20.8.1 Is there a way to manually update this? Quote Link to comment
wgstarks Posted June 28, 2021 Share Posted June 28, 2021 I have been trying to install this docker for several hours but I never get an Activation Code email from Nessus (also checked my spam folders). Is there some other way to activate it? Quote Link to comment
wgstarks Posted June 28, 2021 Share Posted June 28, 2021 2 hours ago, wgstarks said: I have been trying to install this docker for several hours but I never get an Activation Code email from Nessus (also checked my spam folders). Is there some other way to activate it? After a bit of googling I found a website that will provide the code- https://www.tenable.com/products/nessus/nessus-essentials Quote Link to comment
ThatTallGuy21 Posted July 15, 2021 Share Posted July 15, 2021 On 6/28/2021 at 12:28 PM, wgstarks said: After a bit of googling I found a website that will provide the code- https://www.tenable.com/products/nessus/nessus-essentials Thanks! My activation email was never sent after requesting one within the setup workflow of Nessus Essential, so this did the trick! From my experience, it should be noted (if not already above) that you must have a business email address when requesting an activation code. Some quick research pointed to this not always being the case, so something to keep in mind. I originally tried with my Gmail but that didn't work. Crossing my fingers installing goes smoother this time. I tried several weeks ago and gave up after setup appeared to hang on "Initializing - Compiling plugins...". I gave up after a couple hours of the loading bar not moving. Looks to be doing the same thing but will give it awhile to see what happens. Can anyone else chime in on whether this is normal? Quote Link to comment
ThatTallGuy21 Posted July 15, 2021 Share Posted July 15, 2021 4 hours ago, ThatTallGuy21 said: Thanks! My activation email was never sent after requesting one within the setup workflow of Nessus Essential, so this did the trick! From my experience, it should be noted (if not already above) that you must have a business email address when requesting an activation code. Some quick research pointed to this not always being the case, so something to keep in mind. I originally tried with my Gmail but that didn't work. Crossing my fingers installing goes smoother this time. I tried several weeks ago and gave up after setup appeared to hang on "Initializing - Compiling plugins...". I gave up after a couple hours of the loading bar not moving. Looks to be doing the same thing but will give it awhile to see what happens. Can anyone else chime in on whether this is normal? So I'm still having this same issue. My session sat on "Initializing" from 9:05am ET until 1:35pm ET and appeared to do nothing. Since it didn't move, I refreshed the page and got the "This site can't be reached" message. Then I restarted the Nessus docker container and the GUI now displays but still says "Initializing". Is this normal to sit on "compiling plugins" for this long? Any suggestions on how to resolve? Quote Link to comment
ThatTallGuy21 Posted July 16, 2021 Share Posted July 16, 2021 (edited) Happy to report back that at 9pm ET last night, after letting the install do its thing for a large portion of yesterday, that I was able to successfully login through the GUI and execute my first scan. This thing is pretty cool. Really appreciate the work to make this happen. What is everyone testing? Are you entering in a range of IPs which include your server? I ended up testing a pretty large range of IPs across my entire network. Hoping to see Nessus capture everything on my network. Any particular type of test that you recommend? Anyone recommend using any particular plugin? Edited July 16, 2021 by ThatTallGuy21 Quote Link to comment
ThatDude Posted September 3, 2021 Share Posted September 3, 2021 On 6/9/2021 at 3:37 PM, bilboswaggins said: Hey, Sorry if this has already been addressed but I keep getting the "Report outdated / end-of-life Scan Engine / Environment (local)" Installed GVM Libraries (gvm-libs) version: 11.0.1 Latest available GVM Libraries (gvm-libs) version: 20.8.1 Is there a way to manually update this? I came here to ask the same question - any way to get this updated? TIA Quote Link to comment
jbreed Posted September 3, 2021 Author Share Posted September 3, 2021 4 hours ago, ThatDude said: I came here to ask the same question - any way to get this updated? TIA Glad you pinged me as I am able to get this handled today as I have some time on my hands. Been pretty busy and this keeps slipping my mind given it continues to work with updated plugins; however, I may look into creating an automated pipeline for publishing updates here soon if I can make the time out of my schedule to work this. Just re-packaged a new container update that I am spinning up for a test (wouldn't want to push an update and break everyone's functional scanner) before publishing it. I should have it up here shortly. 😁 Quote Link to comment
jbreed Posted September 3, 2021 Author Share Posted September 3, 2021 On 7/16/2021 at 5:53 AM, ThatTallGuy21 said: Happy to report back that at 9pm ET last night, after letting the install do its thing for a large portion of yesterday, that I was able to successfully login through the GUI and execute my first scan. This thing is pretty cool. Really appreciate the work to make this happen. What is everyone testing? Are you entering in a range of IPs which include your server? I ended up testing a pretty large range of IPs across my entire network. Hoping to see Nessus capture everything on my network. Any particular type of test that you recommend? Anyone recommend using any particular plugin? Awesome! For me, I normally spin this up and run a scan on a known subnet of my internal network and when not in use I power the container off. I've used Nessus in an Enterprise environment for benchmarks (compliance), vulnerability scans using credentials/uncredentialed, etc. I recommend going to a Nessus forum if you want to work with others on specifics on the usage of the scanner. Have a good weekend! Quote Link to comment
jbreed Posted September 3, 2021 Author Share Posted September 3, 2021 (edited) 8 hours ago, ThatDude said: I came here to ask the same question - any way to get this updated? TIA Just to give you a heads up, I just pushed an update updating Nessusd to the latest version as well as updating the base image and other dependencies. Let me know if you have any issues. UPDATE 1 5:30PM MST: No issues with the package and it functioning; however, if deploying an update/upgrade it appears there is some bug that causes a 404 error. Working on a fix right now, which involves backing up /config/opt/nessus/var/nessus (which is the configuration files for a user), cleaning up the whole previous install, then re-installing the new package. I think since I just copied the deb into the path there is something that it doesn't like. I plan to have this fixed today within the next hour or so. I don't recommend updating just yet! UPDATE 2 6:00PM MST: I believe to have a patch in place that i published. Doing a final test to make sure all is well. I recommend if you have anything important (IE: license for non-free) to backup the var/nessus folder and store it elsewhere. This can be done by accessing the console. Wouldn't be a bad idea to do this anyways if this is used on a business/production system. I imagine most UnRaid instances are for small home use and I know personally I wouldn't have an issue re-doing my configurations; however, this is probably not the same for a select few. If anyone is still having issues, please feel free to post your logs. I should have time over this 3-day weekend to work with anyone who is running into issues in debugging it. Seems each time I go for a simple patch it works fine except for upgrading where a volume and data is present. If all is well, I may look into making a CI/CD pipeline to auto-update the core components on a regular schedule, but I have to figure out good tests it can run before merging into the production version. Edited September 4, 2021 by jbreed Issue with update Quote Link to comment
timethrow Posted September 4, 2021 Share Posted September 4, 2021 (edited) Heya, Thanks for the update. Since updating this, the docker image use has gone from around ~1.5GB to 9.8GB, and has maxed out my docker image, I have given it another 5GB and its still growing. Is this expected, i.e. are there alot of changes or new files in this update, or are there any new paths we may need to map? This is the tail end of the Docker Log; config/opt/nessus/var/nessus/tmp/fetch_feed_file_tmp_32_2140101596_1745818318 config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445 tar: config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445: Cannot write: No space left on device config/opt/nessus/var/nessus/plugins-desc.db.163058740051507450 Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Backing up Nessus configuration to /config/nessusbackup.tar tar: Removing leading `/' from member names /config/opt/nessus/var/nessus/ /config/opt/nessus/var/nessus/tools/ /config/opt/nessus/var/nessus/tools/bootstrap-from-media.nbin /config/opt/nessus/var/nessus/tools/nessusd_www_server6.nbin /config/opt/nessus/var/nessus/tools/tool_dispatch.ntool /config/opt/nessus/var/nessus/logs/ /config/opt/nessus/var/nessus/nessus-services /config/opt/nessus/var/nessus/plugins-core.tar.gz /config/opt/nessus/var/nessus/tenable-plugins-a-20210201.pem /config/opt/nessus/var/nessus/users/ /config/opt/nessus/var/nessus/nessus_org.pem /config/opt/nessus/var/nessus/tenable-plugins-b-20210201.pem /config/opt/nessus/var/nessus/tmp/ /config/opt/nessus/var/nessus/tmp/nessusd /config/opt/nessus/var/nessus/tmp/nessusd.service Cleaning up old Nessus installation files Extracting packaged nessus debian package: Nessus 8.15.1... mkdir: cannot create directory '/tmp/recover': File exists Thanks EDIT: I couldn't get to the bottom of it, and no matter how much extra space I gave the Docker Image, within a few moments it used it all. So I ended up deleting the image, and moving the old appdata and starting a fresh. This solved the disk usage issue, however, on this clean install I had a couple of issues where nessus would not start, going to the console and starting the nessusd service manually worked. Will see how it goes over the next few days. - Thanks again for updating it Edited September 4, 2021 by timethrow Give Update Quote Link to comment
jbreed Posted September 4, 2021 Author Share Posted September 4, 2021 (edited) 6 hours ago, timethrow said: Heya, Thanks for the update. Since updating this, the docker image use has gone from around ~1.5GB to 9.8GB, and has maxed out my docker image, I have given it another 5GB and its still growing. Is this expected, i.e. are there alot of changes or new files in this update, or are there any new paths we may need to map? This is the tail end of the Docker Log; config/opt/nessus/var/nessus/tmp/fetch_feed_file_tmp_32_2140101596_1745818318 config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445 tar: config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445: Cannot write: No space left on device config/opt/nessus/var/nessus/plugins-desc.db.163058740051507450 Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Backing up Nessus configuration to /config/nessusbackup.tar tar: Removing leading `/' from member names /config/opt/nessus/var/nessus/ /config/opt/nessus/var/nessus/tools/ /config/opt/nessus/var/nessus/tools/bootstrap-from-media.nbin /config/opt/nessus/var/nessus/tools/nessusd_www_server6.nbin /config/opt/nessus/var/nessus/tools/tool_dispatch.ntool /config/opt/nessus/var/nessus/logs/ /config/opt/nessus/var/nessus/nessus-services /config/opt/nessus/var/nessus/plugins-core.tar.gz /config/opt/nessus/var/nessus/tenable-plugins-a-20210201.pem /config/opt/nessus/var/nessus/users/ /config/opt/nessus/var/nessus/nessus_org.pem /config/opt/nessus/var/nessus/tenable-plugins-b-20210201.pem /config/opt/nessus/var/nessus/tmp/ /config/opt/nessus/var/nessus/tmp/nessusd /config/opt/nessus/var/nessus/tmp/nessusd.service Cleaning up old Nessus installation files Extracting packaged nessus debian package: Nessus 8.15.1... mkdir: cannot create directory '/tmp/recover': File exists Thanks Very odd. It appears the /tmp/recover directory was never cleaned up after doing the update causing it to try and create the directory and fail due to it being there already. Here is what the bottom of that log file should look like. Looks like I should check for this within the startup script. config/opt/nessus/var/nessus/plugins-attributes.db.new config/opt/nessus/var/nessus/tenable-plugins-20210201.pem Changing owner and group of configuration files... Creating symbolic links... Cleaning up deb file used for install.. Cleaning up backup files extracted for an update.. Starting nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. Cached 0 plugin libs in 0msec Processing the Nessus plugins... All plugins loaded (0sec) 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 nessusd service... nessusd (Nessus) 8.15.1 [build 20272] for Linux Copyright (C) 1998 - 2021 Tenable, Inc. Console into the container and get the results of: # bash # df -h This will tell you what the disk usage is looking like. The backup tar file for me is 1.6G (could gzip it to further compress) with the whole volume mount sitting at 49G (/config). Not sure how you were seeing such small disk usage before to be honest. root@2917db0051dc:/config# df -h Filesystem Size Used Avail Use% Mounted on /dev/loop2 120G 6.8G 112G 6% / tmpfs 64M 0 64M 0% /dev tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup shm 64M 0 64M 0% /dev/shm shfs 466G 49G 417G 11% /config /dev/loop2 120G 6.8G 112G 6% /etc/hosts tmpfs 7.8G 0 7.8G 0% /proc/acpi tmpfs 7.8G 0 7.8G 0% /sys/firmware I'll look into adding a handler for the recovery of the backup file as well as add compression to further shrink it; however, I imagine it won't be a big difference. Have you logged in and updated all of your plugins? You could get a bash terminal and run 'du' to locate large files to understand what is using the space. If you take a look at the startup script, this is the basic logic flow: 1. Backup the Nessus user data to /config, which is a volume mount as a tar file 2. Delete the /config/opt directory 3. Unpackage the .deb Nessus installation back to the /config directory, which deploys /config/opt and nessus will be under this 4. Unpackage backup tar file to /tmp/recover 5. Move main backup components into the nessus installation (users, database, etc) 6. Cleanup the /tmp/recover and .deb file removal (doesn't delete the actual backup .tar file) UPDATE: Pushed an update correcting how the backup and recovery tar was working. You can probably free up over 1-2G by opening a console and deleting the /config/nessusbackup.tar if you don't care to have a backup residing on the volume. Edited September 4, 2021 by jbreed pushed a new update Quote Link to comment
Recommended Posts
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.