Exited with Code 1 - User exists already

[xinox]

Hello,

thanks for the great work, i tried to restart the Container today and run in to an Issue " Exited with Code 1 - User exists already". Here are the last lines of the Logfiles:

_openvas_1 | Starting Greenbone Vulnerability Manager... openvas_1 | Waiting for gvmd openvas_1 | User1 openvas_1 | admin openvas_1 | User2 openvas_1 | Time to fixup the gvm accounts. openvas_1 | Creating new user User1 with supplied password. openvas_1 | If no password supplied on startup, then the default password is admin openvas_1 | ...... Don't do that ..... openvas_1 | Creating Greenbone Vulnerability Manager admin user as User1 openvas_1 | User exists already. openvas_openvas1 exited with code 1

Here is a a part of my compose File:

_environment:

• "USERNAME=User1"
• "PASSWORD=**"
• "RELAYHOST=172.17.0.1"
• "SMTPPORT=25"
• "REDISDBS=512" # number of Redis DBs to use
• "QUIET=false" # dump feed sync noise to /dev/null
• "NEWDB=false" # only use this for creating a blank DB
• "SKIPSYNC=true" # Skips the feed sync on startup.
• "RESTORE=false" # This probably not be used from compose... see docs.
• "DEBUG=false" # This will cause the container to stop and not actually start gvmd
• "HTTPS=false" # wether to use HTTPS or not
• "GMP=false" # to enable see docs_

Also i had the Issue, that when i set SKIPSYNC=true it doenst seem to work. If i delete SKIPSYNC he also syncs NVT's

[immauss]

The restart issue is easy. You should only use the —user and —password the first time you start when using volume storage.

The SKIPSYNC will require some investigation. Can you send me the docker logs from when the skipsync fails?

[xinox]

Hey,

nvm i made an error using Docker. I solved it.

Thank you for the fast reply and the development of this docker.

Keep it up!

[Vincevrp]

Hey @immauss,

You should consider rewriting it like the Secure Compliance Solutions image:

https://github.com/Secure-Compliance-Solutions-LLC/GVM-Docker/blob/116af80060701004671ce3a8e210eefa4aebcf53/scripts/start.sh#L245

This way, the container does not break when the variables are still present.

[immauss]

hehe ... they added that since I cloned from them.

We've been trading bits back and forth.

The thing is, you should NOT leave it like that anyway, as you are leaving the password in the clear lying around on disk in the case of a docker-compose and worse in memory and /proc if you use the command line options. Might not be a problem in your scenario, but could be for others.

You're right, it's an easy fix, but one that would allow people to continue using a 'less than secure' default.

I'm not saying I won't do something like this, but I need to think on it a bit.

Happy to hear your thoughts though.

Thanks!

[Vincevrp]

@immauss I'm trying to deploy this in an automated way, using Puppet (configuration management tool). This issue prevents the setup from being completely automated, and breaks the container after initial installation. The same issue would occur if using Ansible, for example.

You could consider adding a warning about storing the password in the console and/or documentation.