I have Greenbone Community Edition 22.4 installed in docker containers. It was working fine until recently the redis server will not start. The ‘redis-server’ container is in a continual restarting state. I’ve successfully run:
docker-compose -f docker-compose.yml -p greenbone-community-edition pull
docker-compose -f docker-compose.yml -p greenbone-community-edition up -d
I’ve manually stopped and restarted the container. I’ve updated and rebooted the server.
Thank you for your help so far, but man there are so many missing details in the support for this product.
So I was unable to use that command as it stated the volume was in use even after stopping all of the containers:
docker volume rm -f greenbone-community-edition_redis_socket_vol
Error response from daemon: remove greenbone-community-edition_redis_socket_vol: volume is in use - [2bcdde8cb7e653d8dafbcdf390d6bb36f0f01604eaf1c729043a4badf6a480f8, 1503214ba58426b8d3a22e8e26b04f9739c7f9f7acc454c6639fba3901ab9b9a]
I followed another forum where they removed the volume manually:
Now When I start the redis service it cannot find the volume:
~/greenbone-community-container$ docker start greenbone-community-edition_redis-server_1
Error response from daemon: get greenbone-community-edition_redis_socket_vol: no such volume
Error: failed to start containers: greenbone-community-edition_redis-server_1
I’ve tried updating the docker compose, but it did not recreate the redis volume:
–Personally I have the impression you are not very familiar with container technologies and docker compose. Maybe you should start to get into that topic first.–
This is true and likely the source of most of my pain at the moment. I still believe that the Community Edition should include documentation for issues such as this. We cannot be experts in all things, so better documentation on problems that arise such as this would prevent future users from asking the question again. Thank you for your assistance!
I also had to reboot the system after pulling the Redis volume.
Regarding the documentation, it’s a little difficult to maintain a constant pulse on what the error of the day in documentation and account for all possible error cases. If you think of Greenbone Community Edition as an open-source software project rather than just a product per se, it becomes a little easier to see the role you need to play in supporting your own usage, keeping backups, and not pulling the docker containers if you are not fairly well versed in how to fix them.
That being said, I’m not very well-versed in fixing docker containers either
And, Its important to hear about bugs since GB can’t fix bugs if they don’t know about them.
If you want my thoughts on the most stable ways to run Greenbone Community Edition, I would say:
I need to object I am using the containers and they are fast, stable and very easy to use (especially if you know details about using docker). They are more flexible and you can always re-start from scratch without leaving waste on your disk.
that’s why I said you should get familiar with container technologies like docker. If you can’t remove a volume it is still in use of a container and that the container must be removed first. You must not delete some disk content maintained by docker. It will break docker.
In general it’s of course desirable to have a 1-click installation and setup solution but that’s really tough to provide and you can’t expect that from a free software solution where the host system may differ on so many ways. If you need something that works out of the box without caring about the underlying technologies, you need to pay somebody for it. Otherwise you need to spend some of your personal time to learn and get familiar with the thing. Disclaimer: This is my personal opinion.
Nevertheless I’ve added a troubleshooting section for your specific issue to the docs
It’s certainly nice to have the Docker containers for running Greenbone CE on Ubuntu, or even Windows or macOS, but, for those who don’t know Docker but know the Linux command line, Kali native is probably a lower learning curve.
It comes with gvm-setup, and gvm-check-setup which can identify basic problems and gvm-feed-sync for updating feeds.
I am sorry. I did actually mean to pull the redis, but because I was multitasking, I ended up pasting the wrong command in my comment. After pulling, updating and restarting the server, Greenbone is back in action. I have learned quite alot about docker between this and one other project, but it is a big change from standard linux administration as you point out. I’ll consider which deployment model we want to continue with, based on your information and further testing.
Hopefully my experience will help others in the future as well.
Thank you again for your help and getting us back on track.
Personally I don’t think this is true and just take a look at the numerous issues in this forum here about users having problems specifically on Kali Linux. You could argue Kali has also the biggest user base for our Community Edition but I think that’s just half the truth. When using distro packages you need to be familiar with the distro specific tooling. In this case
deb and apt for package management (installations and especially updates).
systemd for starting and stopping the services
journalctl to take a look at some logs
postgresql. The debian package and tools are special and Kali may get another postgres version with every update
gvm-check-setup and stuff which is not supported by Greenbone at all
the _gvm user. All things need to run as this specific user
Additionally you need to know about the unix (file) permissions for fixing possible issues with the unix domain sockets and with the files from our feed. Especially this is very difficult to debug and to understand.
It’s much easier to use the Greenbone Community Containers then using Kali Linux packages. You just need to understand the concept of docker with its images, containers, volumes, logs and orchestration via compose. You don’t need to know what’s going on inside of the containers (in detail).