| tag | Description |
|---|---|
| 21.04.02 | The latest and greatest ! |
| multi | A new approach. amd64 & arm64 in a single docker image. |
| 20.08.04.6 | The last 20.08 image |
| beta | from the latest master source from greenbone. This may or may not work. |
| pre-20.08 | This is the last image from before the 20.08 update. |
| v1.0 | old out of date image for posterity. (Dont` use this one. . . . ever) |
| armh-20.08.03 | an arm build of 20.08.03 |
| armh-20.08.03 | an arm build of 20.08.03 |
The current docs are maintained on github here
- armv7 is now live with the latest tag.
- I've also just noticed that Greenbone has release 21.4.1 !! I'm building now and will try to test and have it up in the next day or so.
-Scott
- Finally!!! The latest image on Docker Hub is now a multi-arch image. amd64 & arm64. These should run on any 64 bit x86 kernel and on the arm 64 bit kernels. (aarc64 & arm64). I also resolved a bug in weekly rebuild script that was having the images built with an old DB. If you expereinced a rather slow to ready container recently, that should be resolved. I've also moved the rebuilds off to my own hardware vs using the Docker Hub build system. This allows me to do the multi-arch builds with buildx. There was also a minor update from Greenbone.
-Scott
- A new approach. Now that Docker is going to be charging for using thier build environment .... I decided to go a step further. I'm going to be doing the builds on my own infrastructure, so why not go for a multi-arch build. Something I don't think docker hub offers anyway. So the first (of hopefully many) multi-arch images is now on docker hub. The tag is simple "multi". I can't stress enough that this is very BETA at the moment. I've not done any serious testing with it. Please let me know if you find any isues on any platform. And maybe drop me a note if you have succes too. ( here, a twitter @immauss ... )
-Scott
- Looking for feedback on the ARM images. I have not yet attempted the 21.04 on ARM. If you are interested, please open an issue and let me know.
- 21.04 is now the latest! The new image will upgrade your DB, so no worries on using an older DB. Bonus, 21.04 is WAY faster with postgres 12. I`ve also added all the environement options to the docker_composer.yaml in the git repo, so if composer is your thing, start there. No other new functionality added to the image, but lots of changes from Greenbone. If you have any problems, please open an issue.
May the 4th be with you
- So the 21.04 is taking a little longer than anticipated. What would be great, would be a few more testers. If you have the cycles, I would really appreciate any testing. Just make sure you are not working on your production data yet!
Thanks, -Scott
New GVM version !!
- OK ... I's here!! 21.04. It has some tweaks and fixes. But the biggest change that I see is that it seems to be performing much better with postgresql 12. This is good news. I have it working but I have NOT made it the latest yet. The current tag is 21.04-beta. It is currently not tested with upgrading a current DB. I've only tested with a fresh start. If you choose to test, please drop me not and PLEASE open an issue if you find a problem with it.
-Scott
gmp option added
- At the request of hoboristi , I`ve added an option to enable the gmp service. It will require two options though.
- First, enable the service in the container with
-e GMP=<service port number> - Then publish the port from the container
-p <external port number>:<service port number> - Example:
- First, enable the service in the container with
docker run -d -p 9392:9392 -p 9390:9390 -e GMP=9390 --name openvas -v openvas:/data immauss/openvas:latest
-Scott
Doh!
- Appologies to anyone who tried to pull the latest image in the last 24 hours. It looks like I accidently pusshed my dev branch to master and Docker Hub diligently built a new image. ....... This didn't work. I've reveresed the changes and the "latest" tag is now good. Thanks to cybermcm for catching the problem and opening an issue.
- For the curious, the new work is on finding a clean way to downgrade the DB from postgresql 12 to 11. Apprently there are some performance issues with gmvd and postgresql 12.
-Scott
Tag 20.08.04.6
- Added the HTTPS environment variable. Setting this to true will cause gsa to start with https enabled. I
m working on a better implementation of this, but as this was requested, I went ahead and added it. Thebetter` implementation will be able to use letsencrypt certificates!
-Scott
Tag 20.08.04.5
- Fixed the PASSWORD and USERNAME env vars. Make sure you check checks the docs for the caveats.
- Wrote a new script to make sure I`m getting the latest releaes from all of the Greenbone github repos.
-Scott
- The restore logs now go to /usr/local/var/log/db-restore.log instead of the terminal
- The start.sh is modifying the feed sync scripts (greenbone-nvt-sync and greenbone-feed-sync) to make the normal output a little quieter.
- And the BIG announcement:
Early every Monday morning, the image will be rebuilt with the latest feed updates. This means that the latest image will always have feed data less than 1 week old!!!
-Scott
I have added some additional functionality to the image:
- Container now does a proper shutdown of postgresql on container stop. (I believe not having this has been the cause of some DB corruption seen in the past.)
- New "RESTORE" option added to restore from a DB backup. See the Docs
- Updated documentation
- New latest tag is now 20.08.04.4.
- There is also a 'beta' tag now. Use this at your own peril as it may or may not work. (probably it will not.)
-Scott
After pushing 20.08.04.1, I realized I had not merged the base db changes. So 20.08.04.2 includes the changes to support the base DB and contains a DB from today.
-Scott
-
This has the fix in gvmd to make the processing of the feeds more resilient. If you are getting a ton of errors for an NVT that is not in the family, this image will fix it. The problem is actually in the feed, but the latest gvmd does not get stuck on feed issues.
-
There is also a new beta tag, but as you might expect, this is not really working as it is pulling from the master branch of all the tools. The backend seems to work, but the gsa is just not getting it. This is mainly to help me be ready for the next version by keeping me alert on any new dependencies that may come with the next version. Use it at your own peril.
-Scott
The latest image, tag 20.08.04 includes a baseline database and feed sync. No more waiting for the feeds to sync and then waiting for gvmd to build the database. This means you can login and start running scans about a minute after running the container!
The downside is the USER and PASSWORD environment variables no longer work as they default (admin:admin) is part of the baseline database. I think I can work around this, but that will have to wait for 20.08.05.
There is also a new environment variable: SKIPSYNC . This does exactly what it says, it bypasses the feed sync on container start to speed you along.
-Scott
- Added an environment var for quietening the feed syncs.
- QUIET="true" will send the output of the sync scripts on startup to /dev/null
- Added an environment var for increasing redis DBs.
- REDISDBS="" default is 512.
- This is only what I've added. There are tons of other changes with 20.08 itself.
- New multistage build makes for a MUCH smaller image. Down by more than 1 Gig. Same functionality!
For License info, see the GNU Affero license.
Thu Feb 25 23:59:13 UTC 2021