Cannot Login / Configuration seems to have reverted to using SQLite

We’ve been using OpenVAS for a while now and I just got back from a vacation. When I logged in a day or two ago everything seemed fine. This morning I could not login getting an error: “Login failed. Waiting for OMP service to become available.” I checked that all the services were running, which there were, and even tried restarting them, with no help. I then ran the openvas-check-setup.sh script and it says that there is no users found. When I run the command to add the users, it doesn’t give an error, but it doesn’t seem to make any changes.

That is when I noticed that the check script is showing the configuration using SQLite still, but we migrated to Postgres some time ago. I looked at Postgres and all our data seems to still be in the system, but it is like OpenVAS got reconfigured somehow and is now not looking at Postgres. It seems likely that since the sysadmin team enabled automatic upgrades that the software might have been updated and lost its postgres configuration.

How can we manually configure things to use Postgres and restore the system? I looked at using the migration script but it looks like it won’t work because data is already present in Postgres.

The executable binary of the manager daemon is different for using sqlite and pg. So you either started the wrong binary or you built an update and used different built settings. Look for “-pg” in the binary names.

1 Like

There is not auto migration from/to postgres and sqlite. Which db will be used must be set on compile time via a cmake parameter see https://github.com/greenbone/gvm/blob/master/INSTALL#L124 and https://github.com/greenbone/gvm/blob/master/doc/postgres-HOWTO. So something has changed in your packages or source builds definitively.

1 Like

After looking at the tables in Postgres it seems that the schema was created but there was not data in it. I think maybe the openvas-migrate-to-postgres script was run creating the db but it never migrated the data and since the application was installed using binary packages the db was never actually in use.

The real issue appears to be that the tasks.db SQLite db got corrupted. We’ve had to roll back the host to previous snapshots and have lost some data but the system is running again. Now we are trying to determine how the SQLite db got corrupt in the first place.

Is it generally recommended to move to Postgres for the backend on a permanant corporate wide scanning deployment? We are scanning around 3200 hosts on a weekly basis with multiple agents for different zones.

1 Like

The general recommendation would be to buy some of our appliances for this purpose :wink:

sqlite3 is a embedded db with limited transaction support, no ipc and no replication. postgres runs out of process, has multi user support, different backup possibilities and therefore fits more for professional use cases.

2 Likes