greenbone / gvmd Goto Github PK
View Code? Open in Web Editor NEWGreenbone Vulnerability Manager - The database backend for the Greenbone Community Edition
License: GNU Affero General Public License v3.0
Greenbone Vulnerability Manager - The database backend for the Greenbone Community Edition
License: GNU Affero General Public License v3.0
gsa: (gsad --version)
gvm: (gvmd --version)
openvas-scanner: (openvassd --version)
gvm-libs:
openvas-smb:
Operating system:
Installation method / source: (packages, source installation)
I'm trying to scan an https target protected by Datapower. The .cert and .key files were generated inside Datapower and the pkcs file, was generated with openssl. Can you tell me how may I import the pkcs12 file in command line please? version:Openvas 9 so:Fedora24
Error migrating a tasks.db from revision 146 to revision 184
First reported at: https://community.greenbone.net/t/openvas-db-migration-error-rev146-184-no-such-table-main-nvts-172/970
openvasmd --migrate is running a successful migration
openvasmd --migrate fails to execute a migration step
Happened at our site, might not be reproducible in general:
gsa: (gsad --version)
Greenbone Security Assistant 7.0.3
openvasmd: (openvasmd --version)
OpenVAS Manager 7.0.3
Manager DB revision 184
openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3
gvm-libs:
libopenvas9 (9.0.3-1)
Operating system:
$ uname -a
Linux xxx 4.15.18-8-pve #1 SMP PVE 4.15.18-28 (Tue, 30 Oct 2018 14:27:50 +0100) x86_64 GNU/Linux
md main: INFO: Migrating to 181
md manage:WARNING: sql_exec_internal: sqlite3_step failed: error in view results_autofp: no such table: main.nvts_172
md manage:WARNING: sqlv: sql_exec_internal failed
I should be able to rebuild and update the cache (openvasmd --update --progress && openvasmd --rebuild --progress
) and start the openvas-scanner.
I am not able to update or rebuild the cache via openvasmd
nor I am able to restart the openvas-scanner.
When I try to update or rebuild the cache the whole process just hangs
. When I attach strace to the process I get the following messages in an infinite loop:
select(17, [16], [], NULL, {tv_sec=0, tv_usec=822418}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
I have no idea what is happening here. In the logs I can find the following events in the openvasmd.log
:
The first bad message is this one here:
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sqlv: sql_exec_internal failed
[...]
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sqlv: sql_exec_internal failed
md manage:WARNING:2019-02-26 18h07.15 utc:13695: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)
md manage:WARNING:2019-02-26 18h07.25 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.25 utc:13695: sqlv: sql_exec_internal failed
[...]
Today I have restarted the service and it looks like this:
d main:MESSAGE:2019-02-27 11h06.19 utc:2660: OpenVAS Manager version 7.0.3 (DB revision 184)
md manage: INFO:2019-02-27 11h06.19 utc:2660: Getting users.
md main:MESSAGE:2019-02-27 11h06.25 utc:2661: OpenVAS Manager version 7.0.3 (DB revision 184)
md main: INFO:2019-02-27 11h06.25 utc:2661: rebuild_nvt_cache_retry: Reloading NVT cache
md main: INFO:2019-02-27 11h06.25 utc:2662: update_or_rebuild_nvt_cache: Updating NVT cache
base gpgme:MESSAGE:2019-02-27 11h06.25 utc:2662: Setting GnuPG dir to '/var/lib/openvas/openvasmd/gnupg'
base gpgme:MESSAGE:2019-02-27 11h06.25 utc:2662: Using OpenPGP engine version '2.2.4'
md main: INFO:2019-02-27 11h06.25 utc:2662: Updating NVT cache.
When I try to start the scanner it just times out without any error message in the logs.
gsa: 7.0.3
gvm: 7.0.3
openvas-scanner: 5.1.3
gvm-libs: 9.0.3
openvas-smb: not existent?
Operating system: Ubuntu 18.04
Installation method / source: (packages, source installation) PPA
See logs above
When the function for verifying the CVE scanner is called, an SQL warning will thrown:
md manage:WARNING:2018-02-14 11h46.14 UTC:9969: sql_close: attempt to close db with open statement(s)
The topic https://community.greenbone.net/t/modify-setting-api/671 in our user forum did spot an issues with setting the user timezone. It is possible to lock out the user completely by passing an invalid timezone string to modify_settings command e.g.
<modify_settings>
<name>Timezone</name>
<value>Foo</name>
</modify_settings>
The <modify_settings> command should fail if the passed timezone isn't a valid base64 encoded timezone (or just not a valid base64 encoded timezone string).
It's possible to lock out the user from gvmd by passing a non valid base64 encoded string as timezone value. As a result the response to the command returns invalid xml.
<modify_setting><name>Timezone</name><value>Europe/Berlin</value></modify_setting>
openvasmd --rebuild
does not correctly store the category of NVTs.
Steps to verify:
openvasmd --rebuild`
sqlite3 /var/lib/openvas/mgr/tasks.db
sqlite> select count(*) from nvts;
52764
sqlite> select count(*) from nvts where category=11;
52764
This means, all NVTs are stored with category "ACT_UNKOWN" (11).
This also has impact on queries via "omp", e.g.:
omp '<get_nvts nvt_oid="1.3.6.1.4.1.25623.1.0.11187" details="1"/>'
<get_nvts_response status_text="OK" status="200">
_<snip>_
<category>unknown</category>
_<snip>_
make compiles sources
make returns error:
gvmd.c:921:3: error: implicit declaration of function ‘gvm_auth_tear_down’ [-Werror=implicit-function-declaration]
gvm_auth_tear_down ();
^~~~~~~~~~~~~~~~~~
cd gvmd-8.0-beta2
mkdir build
cd build
cmake ..
make
gvmd-8.0-beta2
Operating system: Debian GNU/Linux 9
Installation method / source: source installation
[ 3%] Building C object src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o
/root/install/openvas10/gvmd-8.0-beta2/src/gvmd.c: In function ‘cleanup’:
/root/install/openvas10/gvmd-8.0-beta2/src/gvmd.c:921:3: error: implicit declaration of function ‘gvm_auth_tear_down’ [-Werror=implicit-function-declaration]
gvm_auth_tear_down ();
^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
src/CMakeFiles/gvmd-sqlite.dir/build.make:62: recipe for target 'src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o' failed
make[2]: *** [src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o] Error 1
CMakeFiles/Makefile2:154: recipe for target 'src/CMakeFiles/gvmd-sqlite.dir/all' failed
make[1]: *** [src/CMakeFiles/gvmd-sqlite.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
Expected behavior
After creating a schedule (I tried daily and weekly schedules), and configuring it in the desired Task, the Task is expected to run at the expected time configured in the Schedule.
Current behavior
I tried with various settings and tasks, but I've never been able to get the schedule triggered.
Running the task manually instead has no issues and the task runs regularly.
Steps to reproduce
create or edit a Schedule under "Configuration>Schedules".
in the Schedule settings, select a desired time and period (eg: Daily) then press the Save button.
Wait for the Scheduled time and then look if any task with the desired Schedule settings runs or not.
GVM versions
gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
GIT revision 41af14bbe-master
gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
GIT revision c4ea8a5-master
openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
GIT revision 19a27e3-master
gvm-libs:
gvm-libs 1.0+beta2 (2018-12-04)
openvas-smb:
openvas-smb 1.0.4 (2018-08-29)
Environment
Operating system:
Ubuntu Server 18.04 x64
Installation method / source: (packages, source installation)
source installation from github repositories
Logfiles
this issue doesn't get reported in the logs (even after the desired time of the schedule, I didn't see anything coming in my "tail -f -n100 /usr/local/var/log/gvm/gvmd.log" - it looks like the Schedule gets totally ignored)
Running a current master/trunk installation with SQLite the following is shown repeatedly every few
seconds in the gvmd.log:
md manage:WARNING:2018-03-09 09h11.18 utc:21159: Failed to remove lock file /var/run/gvm-create-functions: No such file or directory
The lock file was introduced in #23 at line https://github.com/greenbone/gvm/pull/23/files#diff-730cf9817a3bae893bffce368b13049aR14019
Connecting to a remote scanner (slave gvmd) listenining on an interface can be triggered by "master gvmd" running a GUI when you select the scanner within task creation.
I am getting the following error on the remote scanner when i start a scan on the master
event target:MESSAGE:2018-08-20 18h31.31 UTC:28662: Target 81fb7e58-5e65-4174-9066-xxxxxxxxxxxx for test03 (ad5fbf1e-1042-4d20-b854-xxxxxxxxxx) has been created by remote_host md main:WARNING:2018-08-20 18h31.31 UTC:28662: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
when i do a downgrade to the recommended packages (latest releases) remote scanner works, but local scanning seems to have an issue there.
Once, i also added the scanner via CLI (not GUI) had even more trouble getting that thingy to rock.
You will get above error message (TLS error) on the remote.
You will need to restart gvmd to interrupt the scan an be able to delte the scan
gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta2 GIT revision 6884548aa-master
gvm: (gvmd --version)
enbone Vulnerability Manager 8.0+beta1 GIT revision 3b8ede38-master
openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta2 GIT revision 2348b7a-master
gvm-libs:
latest from git
the whole build has been re-setup from scratch today.
debian stretch - up2date
Installation method / source: (packages, source installation)
source installation from git
gvmd.log on remote
event target:MESSAGE:2018-08-20 18h31.31 UTC:28662: Target 81fb7e58-5e65-4174-9066-xxxxxxxxxxxx for test03 (ad5fbf1e-1042-4d20-b854-xxxxxxxxxx) has been created by box911 md main:WARNING:2018-08-20 18h31.31 UTC:28662: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
gvmd.log on master
Task test03 (e7b59478-6534-4873-b7a7-xxxxxxxxxxxx) has been requested to start by admin
The beta3 build fails with:
In file included from /usr/include/string.h:638:0,
from /usr/include/glib-2.0/glib/gtestutils.h:30,
from /usr/include/glib-2.0/glib.h:82,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_base.h:29,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.h:29,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:33:
In function 'memset',
inlined from 'create_ticket_reset' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:351:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'modify_ticket_reset' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:635:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'create_ticket_start' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:366:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'modify_ticket_start' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:650:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/gmp_tickets.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c: In function 'escalate_2':
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c:12810:24: error: 'filter' may be used uninitialized in this function [-Werror=maybe-uninitialized]
body = alert_message_print (message, event, event_data,
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/gmp_tickets.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c: In function 'escalate_2':
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c:12810:24: error: 'filter' may be used uninitialized in this function [-Werror=maybe-uninitialized]
body = alert_message_print (message, event, event_data,
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/manage_sql.c.o] Error 1
make[2]: Leaving directory/builddir/build/BUILD/gvmd-8.0-beta3' make[1]: Leaving directory
/builddir/build/BUILD/gvmd-8.0-beta3'
make[1]: *** [src/CMakeFiles/gvmd-pg.dir/all] Error 2
make: *** [all] Error 2
OS: CentOS 7.6
Lists of tasks displaying severity and no PostgreSQL error
Tasks are working fine, I can see results of reports but every task is showing internal error as level of severity for last report.
2019-03-08 17:35:03.833 CET [2773] root@tasks ERREUR: l’opérateur n’existe pas : name = integer au caractère 84
2019-03-08 17:35:03.833 CET [2773] root@tasks ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d’arguments.
Vous devez ajouter des conversions explicites de type.
2019-03-08 17:35:03.833 CET [2773] root@tasks INSTRUCTION : SELECT max(severity) FROM report_counts WHERE report = 8 AND override = 1 AND user = (SELECT id FROM users WHERE uuid = ‘cb9ea5dd-70da-410c-aa69-533dc138802b’) AND min_qod = 70 AND (end_time = 0 or end_time >= m_now ());
So I found out that the problem occurs when the keyword user is used because it's a reserved keyword and should not be used in data scheme.
When I enter manually in my database the following request, with "user" instead of user
SELECT max(severity) FROM report_counts WHERE report = 8 AND override = 1 AND “user” = (SELECT id FROM users WHERE uuid = ‘cb9ea5dd-70da-410c-aa69-533dc138802b’) AND min_qod = 70 AND (end_time = 0 or end_time >= m_now ());
I have no error.
When the manger verify the CVE scanner, than it will log an SQL warning.
And at the openvasmd.log file an warning is logged:
md manage:WARNING:2018-04-09 08h53.49 utc:6978: sql_close: attempt to close db with open statement(s)
Scan progress indicator goes from 0 to 100%.
Scan progress indicator goes from 0 to 200%.
gsa: (gsad --version)
Today's snapshot from github.
gvm: (gvmd --version)
openvas-scanner: (openvassd --version)
gvm-libs:
openvas-smb:
Operating system:
Debian Stretch 9.
Installation method / source: (packages, source installation)
Source.
gsa: (gsad --version)
gvm: (gvmd --version)
openvas-scanner: (openvassd --version)
gvm-libs:
openvas-smb:
Operating system:
Installation method / source: (packages, source installation)
the script 'gvm-portnames-update' should update the gvm database with new port names from IANA website at "http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml".
NB: i found a similar issue with title "gvm-portnames-update has a hardcoded old db name (tasks) #175" but is closed. I found that the problem is still present.
the script works, but it points to the wrong path
`root@debian-test:/usr/local/src/gse/openvas-scanner/build# /usr/local/sbin/gvm-portnames-update
Update port names data from a port names XML file.
Currently supports the official IANA Services Names list.
In order to update the DB, download the port names list and
provide its path as an argument to this script.
$ wget http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
$ openvas-portnames-update service-names-port-numbers.xml
$ rm service-names-port-numbers.xml
--2019-01-10 16:44:04-- http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
Length: unspecified [text/xml]
Saving to: ‘service-names-port-numbers.xml’
service-names-port-numbers.xml [ <=> ] 3.52M 541KB/s in 6.7s
2019-01-10 16:44:11 (541 KB/s) - ‘service-names-port-numbers.xml’ saved [3690073]
root@debian-test:/usr/local/src/gse/openvas-scanner/build# /usr/local/sbin/gvm-portnames-update service-names-port-numbers.xml
/usr/local/var/lib/openvas/gvmd/gvmd.db not found. Rebuild DB before updating port names.
`
but "/usr/local/var/lib/openvas/gvmd/gvmd.db "is the wrong path, the right path is "/usr/local/var/lib/gvm/gvmd/gvmd.db"
see above
gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
GIT revision 29acdd6-master
gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
GIT revision 6e48194-master
openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
GIT revision 6f209c9-master
gvm-libs:
gvm-libs 1.0+beta2 (2018-12-04)
Environment
Operating system:
Debian 9.6
Installation method / source: (packages, source installation)
git source installation
After I fix the rpm part, now I found the problem the debian package export also fails.
An 0 byte file will be generated.
/var/log/openvas/openvasmd.log:
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_recreate: rpm_path: /tmp/rpm_7lViVe/p.rpm
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: create temporary directory
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: temporary directory: /tmp/lsc_user_rpm_create_oDV68U
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: copy key to temporary directory
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: Attempting RPM build
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: Spawning in /usr/share/openvas: ./openvas-lsc-rpm-creator.sh --target /tmp/lsc_user_rpm_create_oDV68U /tmp/lsc_user_rpm_create_oDV68U/openvas_s
canner.pub
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: lsc_user_rpm_create: new filename (rpm_path): /tmp/lsc_user_rpm_create_oDV68U/openvas-lsc-target-openvas_scanner-0.5-1.noarch.rpm
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: --- executing alien.
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: execute_alien: Spawning in /tmp/rpm_dOxwOC/: fakeroot -- alien --scripts --keep-version p.rpm
If I read the log right, then the rpm package will called /tmp/lsc_user_rpm_create_oDV68U/openvas-lsc-target-openvas_scanner-0.5-1.noarch.rpm , but alien is called with p.rpm
Running on the command line:
fakeroot -- alien --scripts --keep-version foo.rpm
will .deb package will created.
foo.rpm is the created downloaded rpm package from gsa.
The timezone should be returned as a setting from the <get_settings>
command.
The timezone can only be queried via <authenticate>
. It's possible to change the timezone via <modify_settings>
but the <get_settings>
doesn't contain it. This seems to be very inconsistent to me.
All versions
No scary error messages.
Multiple messages in postgres log, including:
gsa: (gsad --version)
Today's snapshot from Github.
gvm: (gvmd --version)
Today's snapshot from Github.
openvas-scanner: (openvassd --version)
Today's snapshot from Github.
gvm-libs:
Today's snapshot from Github.
openvas-smb:
None.
Operating system:
Debian 9 Stretch.
Installation method / source: (packages, source installation)
Build from source.
2018-08-27 21:09:28.714 UTC [20756] LOG: database system was shut down at 2018-08-27 21:09:27 UTC
2018-08-27 21:09:28.716 UTC [20756] LOG: MultiXact member wraparound protections are now enabled
2018-08-27 21:09:28.718 UTC [20755] LOG: database system is ready to accept connections
2018-08-27 21:09:28.718 UTC [20760] LOG: autovacuum launcher started
2018-08-27 21:09:29.192 UTC [20762] [unknown]@[unknown] LOG: incomplete startup packet
2018-08-27 21:51:21.155 UTC [10544] root@gvmd ERROR: relation "public.meta" does not exist at character 19
2018-08-27 21:51:21.155 UTC [10544] root@gvmd STATEMENT: SELECT value FROM public.meta WHERE name = 'database_version';
2018-08-27 21:51:21.648 UTC [10544] root@gvmd WARNING: column "type" has type "unknown"
2018-08-27 21:51:21.648 UTC [10544] root@gvmd DETAIL: Proceeding with relation creation anyway.
2018-08-27 21:51:47.270 UTC [10581] root@gvmd ERROR: duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-27 21:51:47.270 UTC [10581] root@gvmd DETAIL: Key (name)=(IT-Grundschutz M4.023: Sicherer Aufruf ausführbarer Dateien[checkbox]:Alle Dateien Auflisten) already exists.
2018-08-27 21:51:47.270 UTC [10581] root@gvmd STATEMENT: INSERT into nvt_preferences (name, value) VALUES ('IT-Grundschutz M4.023: Sicherer Aufruf ausführbarer Dateien[checkbox]:Alle Dateien Auflisten', 'no');
2018-08-27 21:55:49.095 UTC [10573] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-27 21:55:49.095 UTC [10573] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-27 21:55:59.176 UTC [10573] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-27 21:55:59.176 UTC [10573] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-27 22:54:13.748 UTC [10578] root@gvmd ERROR: relation "cert_bund_advs" does not exist at character 30
2018-08-27 22:54:13.748 UTC [10578] root@gvmd STATEMENT: SELECT EXISTS (SELECT * FROM cert_bund_advs WHERE creation_time > coalesce (CAST ((SELECT value FROM meta WHERE name = 'cert_check_time') AS INTEGER), 0));
2018-08-28 08:07:57.250 UTC [19078] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 08:07:57.250 UTC [19078] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 08:10:31.964 UTC [19078] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 08:10:31.964 UTC [19078] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 08:54:14.005 UTC [19078] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 08:54:14.005 UTC [19078] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:09:39.311 UTC [20755] LOG: received fast shutdown request
2018-08-28 10:09:39.311 UTC [20755] LOG: aborting any active transactions
2018-08-28 10:09:39.311 UTC [20760] LOG: autovacuum launcher shutting down
2018-08-28 10:09:39.315 UTC [20757] LOG: shutting down
2018-08-28 10:09:39.336 UTC [20755] LOG: database system is shut down
2018-08-28 10:10:18.422 UTC [670] LOG: database system was shut down at 2018-08-28 10:09:39 UTC
2018-08-28 10:10:18.429 UTC [670] LOG: MultiXact member wraparound protections are now enabled
2018-08-28 10:10:18.431 UTC [674] LOG: autovacuum launcher started
2018-08-28 10:10:18.431 UTC [669] LOG: database system is ready to accept connections
2018-08-28 10:10:18.867 UTC [712] [unknown]@[unknown] LOG: incomplete startup packet
2018-08-28 10:17:37.364 UTC [1339] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 10:17:37.364 UTC [1339] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:23:03.679 UTC [1339] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 10:23:03.679 UTC [1339] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:32:00.030 UTC [1339] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 10:32:00.030 UTC [1339] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:44:18.703 UTC [1339] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 10:44:18.703 UTC [1339] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 12:08:43.193 UTC [669] LOG: received fast shutdown request
2018-08-28 12:08:43.193 UTC [669] LOG: aborting any active transactions
2018-08-28 12:08:43.194 UTC [674] LOG: autovacuum launcher shutting down
2018-08-28 12:08:43.195 UTC [671] LOG: shutting down
2018-08-28 12:08:43.243 UTC [669] LOG: database system is shut down
2018-08-28 12:09:24.360 UTC [654] LOG: database system was shut down at 2018-08-28 12:08:43 UTC
2018-08-28 12:09:24.366 UTC [654] LOG: MultiXact member wraparound protections are now enabled
2018-08-28 12:09:24.368 UTC [658] LOG: autovacuum launcher started
2018-08-28 12:09:24.368 UTC [653] LOG: database system is ready to accept connections
2018-08-28 12:09:24.822 UTC [669] [unknown]@[unknown] LOG: incomplete startup packet
2018-08-28 13:39:57.678 UTC [7667] postgres@postgres ERROR: role "root" already exists
2018-08-28 13:39:57.678 UTC [7667] postgres@postgres STATEMENT: CREATE ROLE root NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;
2018-08-28 13:39:58.240 UTC [7684] postgres@tasks ERROR: role "dba" already exists
2018-08-28 13:39:58.240 UTC [7684] postgres@tasks STATEMENT: create role dba with superuser noinherit; grant dba to root; create extension "uuid-ossp";
2018-08-28 13:40:14.711 UTC [7738] postgres@postgres ERROR: role "root" already exists
2018-08-28 13:40:14.711 UTC [7738] postgres@postgres STATEMENT: CREATE ROLE root NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;
2018-08-28 13:40:14.771 UTC [7743] postgres@postgres ERROR: database "tasks" already exists
2018-08-28 13:40:14.771 UTC [7743] postgres@postgres STATEMENT: CREATE DATABASE tasks OWNER root;
2018-08-28 13:40:14.848 UTC [7755] postgres@tasks ERROR: role "dba" already exists
2018-08-28 13:40:14.848 UTC [7755] postgres@tasks STATEMENT: create role dba with superuser noinherit; grant dba to root; create extension "uuid-ossp";
2018-08-28 15:04:05.061 UTC [10581] postgres@postgres ERROR: database "tasks" does not exist
2018-08-28 15:04:05.061 UTC [10581] postgres@postgres STATEMENT: DROP DATABASE tasks;
2018-08-28 15:04:43.411 UTC [10634] postgres@tasks ERROR: role "dba" already exists
2018-08-28 15:04:43.411 UTC [10634] postgres@tasks STATEMENT: create role dba with superuser noinherit; grant dba to root;
2018-08-28 15:11:05.622 UTC [11654] root@tasks ERROR: relation "public.meta" does not exist at character 19
2018-08-28 15:11:05.622 UTC [11654] root@tasks STATEMENT: SELECT value FROM public.meta WHERE name = 'database_version';
2018-08-28 15:33:20.854 UTC [12110] root@tasks ERROR: canceling statement due to user request
2018-08-28 15:33:20.854 UTC [12110] root@tasks STATEMENT: SELECT pg_advisory_xact_lock (1);
2018-08-28 15:33:28.875 UTC [12103] root@tasks ERROR: duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-28 15:33:28.875 UTC [12103] root@tasks DETAIL: Key (name)=(Microsoft Windows: Configure registry policy processing (background processing)[radio]:Value) already exists.
2018-08-28 15:33:28.875 UTC [12103] root@tasks STATEMENT: INSERT into nvt_preferences (name, value) VALUES ('Microsoft Windows: Configure registry policy processing (background processing)[radio]:Value', '0;1');
2018-08-28 15:35:16.168 UTC [12451] root@tasks ERROR: canceling statement due to user request
2018-08-28 15:35:16.168 UTC [12451] root@tasks STATEMENT: SELECT pg_advisory_xact_lock (1);
2018-08-28 15:50:56.584 UTC [653] LOG: received fast shutdown request
2018-08-28 15:50:56.584 UTC [653] LOG: aborting any active transactions
2018-08-28 15:50:56.584 UTC [658] LOG: autovacuum launcher shutting down
2018-08-28 15:50:56.589 UTC [655] LOG: shutting down
2018-08-28 15:50:56.644 UTC [653] LOG: database system is shut down
2018-08-28 15:51:35.342 UTC [653] LOG: database system was shut down at 2018-08-28 15:50:56 UTC
2018-08-28 15:51:35.375 UTC [653] LOG: MultiXact member wraparound protections are now enabled
2018-08-28 15:51:35.378 UTC [657] LOG: autovacuum launcher started
2018-08-28 15:51:35.378 UTC [652] LOG: database system is ready to accept connections
2018-08-28 15:51:35.763 UTC [667] [unknown]@[unknown] LOG: incomplete startup packet
2018-08-28 16:28:47.004 UTC [1807] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 16:28:47.004 UTC [1807] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 16:36:39.134 UTC [1807] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 16:36:39.134 UTC [1807] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 16:44:38.367 UTC [652] LOG: received fast shutdown request
2018-08-28 16:44:38.367 UTC [652] LOG: aborting any active transactions
2018-08-28 16:44:38.367 UTC [657] LOG: autovacuum launcher shutting down
2018-08-28 16:44:38.369 UTC [654] LOG: shutting down
2018-08-28 16:44:38.428 UTC [652] LOG: database system is shut down
2018-08-28 16:45:19.419 UTC [655] LOG: database system was shut down at 2018-08-28 16:44:38 UTC
2018-08-28 16:45:19.426 UTC [655] LOG: MultiXact member wraparound protections are now enabled
2018-08-28 16:45:19.428 UTC [659] LOG: autovacuum launcher started
2018-08-28 16:45:19.428 UTC [654] LOG: database system is ready to accept connections
2018-08-28 16:45:19.879 UTC [669] [unknown]@[unknown] LOG: incomplete startup packet
2018-08-28 17:12:14.541 UTC [8528] root@gvmd ERROR: duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-28 17:12:14.541 UTC [8528] root@gvmd DETAIL: Key (name)=(IT-Grundschutz M5.009: Protokollierung am Server[checkbox]:Alle Logfile-Einträge Auflisten) already exists.
2018-08-28 17:12:14.541 UTC [8528] root@gvmd STATEMENT: INSERT into nvt_preferences (name, value) VALUES ('IT-Grundschutz M5.009: Protokollierung am Server[checkbox]:Alle Logfile-Einträge Auflisten', 'no');
2018-08-28 17:22:34.433 UTC [13935] root@gvmd LOG: could not receive data from client: Connection reset by peer
2018-08-28 17:22:34.433 UTC [13935] root@gvmd LOG: unexpected EOF on client connection with an open transaction
2018-08-28 17:25:17.049 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:25:17.049 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:25:29.062 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:25:29.062 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:25:41.057 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:25:41.057 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:27:04.094 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:27:04.094 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:27:16.055 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:27:16.055 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:28:16.060 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:28:16.060 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:32:24.158 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:32:24.158 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:33:00.552 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:33:00.552 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:36:22.143 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:36:22.143 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:39:52.444 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:39:52.444 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:41:31.391 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:41:31.391 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:42:22.444 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:42:22.444 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:42:42.520 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:42:42.520 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:47:31.428 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:47:31.428 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:48:00.375 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:48:00.375 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:52:57.343 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 17:52:57.343 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 18:02:42.287 UTC [13988] root@gvmd ERROR: could not obtain lock on relation "reports"
2018-08-28 18:02:42.287 UTC [13988] root@gvmd STATEMENT: LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
When try to login with in invalid user or password then in the log file only the dummy value is logged as the source ip.
md omp:WARNING:2018-03-06 08h38.20 utc:1876: Authentication failure for 'inavlid' from 900::900:0:0:0
Config for the log:
[md omp]
prepend=%t %p
prepend_time_format=%Y-%m-%d %Hh%M.%S %Z
file=/var/log/openvas/openvasmd.log
level=16
I simple add an IP as an scan target and let the "System Discovery" scan run.
d manage: INFO:2018-02-09 05h56.30 UTC:22201: nvt_selector_plugins: NVTs not explicitly activated anymore for this config: 1.3.6.1.4.1.25623.1.0.10265;1.3.6.1.4.1.25623.1.0.103914;1.3.6.1.4.1.25623.1.0.103978
;1.3.6.1.4.1.25623.1.0.95888;1.3.6.1.4.1.25623.1.0.12241;1.3.6.1.4.1.25623.1.0.108298;1.3.6.1.4.1.25623.1.0.11933;1.3.6.1.4.1.25623.1.0.12288;1.3.6.1.4.1.25623.1.0.80010;1.3.6.1.4.1.25623.1.0.810010;1.3.6.1.4.1.
25623.1.0.10870;1.3.6.1.4.1.25623.1.0.108215;1.3.6.1.4.1.25623.1.0.80011;1.3.6.1.4.1.25623.1.0.103585;1.3.6.1.4.1.25623.1.0.103697;1.3.6.1.4.1.25623.1.0.100509;1.3.6.1.4.1.25623.1.0.80104;1.3.6.1.4.1.25623.1.0.8
0086;1.3.6.1.4.1.25623.1.0.900238;. Please adjust the config if you think this is wrong.
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: sql_prepare_internal: sqlite3_prepare failed: near "(": syntax error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: init_iterator: sql_prepare failed
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: manage_cleanup_process_error: Error exit, setting running task to Internal Error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: sql_prepare_internal: sqlite3_prepare failed: near "(": syntax error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: init_iterator: sql_prepare failed
After an update (on release branches) of python-gvm, gvm-tools, gvm-libs, gvmd, openvas-scanner, gasd, it looks like openvasmd is not returning valid answers to gvm-cli, gsa/gsad and gvm-pyshell.
Command "openvasmd --get-scanners" will return valid data on openvassd scanners, whereas command 'gvm-cli socket -c --xml "<get_scanners/>"' returns data about 0 (zero) scanners .
Same goes for gsa, which show an empty scanners page (Configuration > Scanners).
And, "gvm-pyshell socket -c -i" gmp.get_scanners() also returns zero scanner count
<scanner_count>0<filtered>0</filtered><page>0</page></scanner_count>
To reproduce:
Query for active scanners with openvasmd (openvasmd.log output included):
$ sudo openvasmd --get-scanners
08b69003-5fc2-4037-a479-93b440211c73 OpenVAS Default
6acd0832-df90-11e4-b9d5-28d24461215b CVE
md main:MESSAGE:2018-11-08 15h29.41 utc:15493: OpenVAS Manager version 7.0.4 (GIT revision 26b72751-openvas-manager-7.0) (DB revision 184)
md manage: INFO:2018-11-08 15h29.41 utc:15493: Getting scanners.
However, same query over "gvm-cli socket --xml" will receive 0 scanners (openvasmd.log output included):
$ gvm-cli socket -c --xml "<get_scanners/>"
<get_scanners_response status="200" status_text="OK"><filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/>**<scanner_count>0<filtered>0</filtered><page>0</page></scanner_count>**</get_scanners_response>
md main: DEBUG:2018-11-08 15h32.34 utc:15498: Serving OMP.
md main: DEBUG:2018-11-08 15h32.34 utc:15498: <= client Input may contain password, suppressed.
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <authenticate_response status="200" status_text="OK"><role>Admin</role><timezone>UTC</timezone><severity>nist</severity></authenticate_response>
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: => client 144 bytes
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: => client done
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: <= client "<get_scanners/>"
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <get_scanners_response status="200" status_text="OK">
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/><scanner_count>0<filtered>0</filtered><page>0</page></scanner_count></get_scanners_response>
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: => client 560 bytes
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: => client done
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: EOF reading from client.
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: Cleaning up.
md main: DEBUG:2018-11-08 15h32.34 UTC:15498: Exiting.
Now, reverting back to a commit from Sep. 14th, and rebuilding, all will work normally:
~/gvmd$ git checkout 210d8d0d2634a2918879c108320d16845d52b447
~/gvmd$ rm -r build
~/gvmd$ mkdir build
~/gvmd$ cd build
~/gvmd$ cmake ..
~/gvmd$ make
~/gvmd$ sudo make install
~/gvmd$ make rebuild_cache
~/gvmd$ sudo killall openvasmd
~/gvmd$ sudo /usr/local/sbin/openvasmd --unix-socket=/usr/local/var/run/gvmd.sock
~$ gvm-cli socket -c --xml "<get_scanners/>"
<get_scanners_response status="200" status_text="OK"><scanner id="6acd0832-df90-11e4-b9d5-28d24461215b"><owner><name></name></owner><name>CVE</name><comment></comment><creation_time>2018-11-06T20:14:28Z</creation_time><modification_time>2018-11-06T20:14:28Z</modification_time><writable>1</writable><in_use>0</in_use><permissions></permissions><user_tags><count>0</count></user_tags><host></host><port>0</port><type>3</type><ca_pub></ca_pub><credential id=""><name></name><trash>0</trash></credential></scanner><scanner id="08b69003-5fc2-4037-a479-93b440211c73"><owner><name></name></owner><name>OpenVAS Default</name><comment></comment><creation_time>2018-11-06T20:14:28Z</creation_time><modification_time>2018-11-06T20:14:28Z</modification_time><writable>1</writable><in_use>0</in_use><permissions></permissions><user_tags><count>0</count></user_tags><host>/usr/local/var/run/openvassd.sock</host><port>0</port><type>2</type><ca_pub></ca_pub><credential id=""><name></name><trash>0</trash></credential></scanner><filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/><scanner_count>0<filtered>0</filtered><page>2</page></scanner_count></get_scanners_response>
gsa: (gsad --version)
Greenbone Security Assistant 7.0.4
GIT revision 293cf3c7f-gsa-7.0
gvm: (gvmd --version) / openvasmd --version
~$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 26b7275-openvas-manager-7.0
Manager DB revision 184
openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3
gvm-libs:
git log:
commit db1306c117df6dde5324b75cb4517b2382a5ba98 (HEAD -> openvas-libraries-9.0, origin/openvas-libraries-9.0)
Operating system:
$ uname -a
Linux sknr1 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Description: Ubuntu 18.04.1 LTS
Installation method / source: (packages, source installation)
From source.
Default database name has been changed to 'gvmd' in GVM-10, but the script still uses the hard-coded old name ('tasks') for PostgreSQL.
if [ $POSTGRES -eq 1 ] then SQL="psql -v ON_ERROR_STOP=1 -q --pset pager=off --no-align -d tasks -t" else TASKS_DB="$DB_DIR/tasks.db" if [ ! -f $TASKS_DB ]; then echo "$TASKS_DB not found. Rebuild DB before updating port names."; exit 1; fi SQL="sqlite3 $TASKS_DB" fi
To avoid that this gets lost:
gvmd --migrate is running a successful migration
gvmd --migrate fails to execute a migration step
database_version|197
gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta1
GIT revision aa88aec-master
Manager DB revision 200
Database backend: SQLite
md main:MESSAGE:2018-11-26 15h12.42 utc:3099: Greenbone Vulnerability Manager version 8.0+beta1 (GIT revision aa88aece-master) (DB revision 200)
md main: INFO:2018-11-26 15h12.42 utc:3099: Migrating database.
md main: INFO:2018-11-26 15h12.42 utc:3099: Migrating to 198
md manage:WARNING:2018-11-26 15h12.42 utc:3099: sql_exec_internal: sqlite3_step failed: error in view result_overrides: no such table: main.reports_196
md manage:WARNING:2018-11-26 15h12.42 utc:3099: sqlv: sql_exec_internal failed
Running a task on GSA, the task is completed
Task does not run.
I've made an How-To which describes the steps to install GVM on Alpine:
https://wiki.alpinelinux.org/wiki/Setting_up_GVM10
Basically, install the packages, run GSA (with or without signature is the same), create a task.
Task does not run.
gsa: (gsad --version)
Greenbone Security Assistant 8.0.0
gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0.0
Manager DB revision 205
openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0.0
gvm-libs:
gvm-libs-10.0.0
openvas-smb:
Not used
Operating system:
Alpine Linux edge on x86_64 arch.
Installation method / source: (packages, source installation)
Packages
I get these errors when I start a task on gsa:
md manage:WARNING:2019-04-09 19h36.51 UTC:2469: sql_prepare_internal: sqlite3_prepare failed: not an error
md manage:WARNING:2019-04-09 19h36.51 UTC:2469: init_iterator: sql_prepare failed
This happens with the following packages installed:
sqlite-3.27.2
gvm-libs-10.0.0
gvmd-8.0.0
openvas-scanner-6.0.0
greenbone-security-assistant-8.0.0
What I've noticed (perhaps is linked to this problem), is that importing the nvt i got tons of these WARNING:
md manage:WARNING:2019-04-09 19h27.24 utc:1035: parse_ctime: Failed to parse time '2018-02-27T19:15:33.110Z'
Please note that Alpine doesn't use /etc/TZ to set local time, rather tzdata
According with gvmd logs, seems that somehow I'm hitting a limit:
md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_prepare_internal: sqlite3_prepare failed: no more rows available
md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_x_internal: sql_prepare failed
md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_close: attempt to close db with open statement(s)
No more rows available.
But this is impossible, since the limit is 140Terabyte and SQLite documentation states:
Maximum Number Of Rows In A Table
The theoretical maximum number of rows in a table is 264 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.
SQlite on Alpine is built with the following options:
-DSQLITE_ENABLE_FTS4 \
-DSQLITE_ENABLE_FTS3_PARENTHESIS \
-DSQLITE_ENABLE_FTS3 \
-DSQLITE_ENABLE_FTS5 \
-DSQLITE_ENABLE_COLUMN_METADATA \
-DSQLITE_SECURE_DELETE \
-DSQLITE_ENABLE_UNLOCK_NOTIFY \
-DSQLITE_ENABLE_RTREE \
-DSQLITE_ENABLE_GEOPOLY \
-DSQLITE_USE_URI \
-DSQLITE_ENABLE_DBSTAT_VTAB \
-DSQLITE_MAX_VARIABLE_NUMBER=250000 \
-DSQLITE_ENABLE_JSON1"
I've not tested with PostgreSQL as yet.
Also appears to be impossible to build gvmd supporting both postgres and sqlite since -DBACKEND
takes only SQLITE3 or POSTGRESQL.
.: Francesco
Scanner services booting when openvas-start is entered in the terminal.
The service doesn't start and thus scanning isn't possible.
gsa: (gsad --version)
Greenbone Security Assistant 7.0.3
gvm: (gvmd --version)
openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3
gvm-libs:
openvas-smb:
Operating system:
Kali Linux
Installation method / source: (packages, source installation)
apt-get install openvas
No logs found
It would be really helpful if we could get Slack / Mattermost supported as a method for alerting.
(This issue moved from here)
Hello,
Can you please provide a signed tarball for openvas-manager 7.0.3? Thanks
The build will fails with:
/usr/lib64/ccache/cc -DCACERT="/var/lib/gvm/CA/cacert.pem" -DCA_DIR="/var/lib/gvm/gvmd/trusted_certs" -DCLIENTCERT="/var/lib/gvm/CA/clientcert.pem" -DCLIENTKEY="/var/lib/gvm/private/CA/clientkey.pem" -DGMP_VERSION="8.0" -DGVMD_CERT_DATABASE_VERSION=6 -DGVMD_DATABASE_VERSION=191 -DGVMD_DATA_DIR="/usr/share/gvm/gvmd" -DGVMD_SCAP_DATABASE_VERSION=15 -DGVMD_STATE_DIR="/var/lib/gvm/gvmd" -DGVMD_VERSION="8.0+beta1" -DGVM_CERT_DATA_DIR="/var/lib/gvm/cert-data" -DGVM_CERT_RES_DIR="/usr/share/gvm/cert" -DGVM_DATA_DIR="/usr/share/gvm" -DGVM_LIB_INSTALL_DIR="/usr/lib" -DGVM_LOG_DIR="/var/log/gvm" -DGVM_NVT_DIR="/var/lib/openvas/plugins/" -DGVM_OS_NAME="Linux-3.10.0-862.6.3.el7.x86_64" -DGVM_RUN_DIR="/var/run" -DGVM_SCAP_DATA_DIR="/var/lib/gvm/scap-data" -DGVM_SCAP_RES_DIR="/usr/share/gvm/scap" -DGVM_SQLITE_SLEEP_MAX=0 -DGVM_STATE_DIR="/var/lib/gvm" -DGVM_SYSCONF_DIR="/etc/gvm" -DPREFIX="/usr" -DSBINDIR="/usr/sbin" -DSCANNERCERT="/var/lib/gvm/CA/servercert.pem" -DSCANNERKEY="/var/lib/gvm/private/CA/serverkey.pem" -I/usr/include/gvm -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/builddir/build/BUILD/gvm-8.0-beta1/helper/usr/include -I/usr/include/uuid -I/usr/include/p11-kit-1 -I/usr/pgsql-10/include/server -I/usr/pgsql-10/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wall -D_BSD_SOURCE -D_ISOC99_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -g -Werror -o CMakeFiles/manage.dir/utils.c.o -c /builddir/build/BUILD/gvm-8.0-beta1/src/utils.c
/builddir/build/BUILD/gvm-8.0-beta1/src/utils.c:69:3: error: implicit declaration of function 'nanosleep' [-Werror=implicit-function-declaration]
while ((ret = nanosleep (requested, remaining)) && (errno == EINTR))
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/manage.dir/utils.c.o] Error 1
In the git master the code are the same.
Hi guys,
When I try to delete a user whose tasks have been run by another user then there is a problem.
As shown below, report_counts belong to another "user" so they are not deleted, and then when it is trying to delete the reports raises a "violates foreign key constraint" problem.
This is likely to happen with other tables like host_identifiers
openvasmd-pg --version
OpenVAS Manager 7.0.3
Manager DB revision 184
md manage:WARNING:2018-04-13 00h33.18 EEST:27339: sql_exec_internal: SQL: DELETE FROM reports WHERE owner = 57;
md manage:WARNING:2018-04-13 00h33.18 EEST:27339: sqlv: sql_exec_internal failed
md manage:WARNING:2018-04-13 14h45.24 EEST:29936: sql_exec_internal: PQexec failed:
ERROR: update or delete on table "reports" violates foreign key constraint "report_counts_report_fkey" on table "report_counts"
DETAIL: Key (id)=(3587) is still referenced from table "report_counts".
(7)
Edit: Of course if I use an inheritor, works correctly.
masscan could be used and the found data could be inserted into database
masscan could be used but the found data could not be inserted into database
gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
Copyright (C) 2010-2016 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
Manager DB revision 200
Copyright (C) 2010-2017 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
Most new code since 2005: (C) 2018 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison [email protected]
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gvm-libs:
openvas-smb:
Operating system:
Installation method / source: (packages, source installation)
Successfully create a new credential with a space in the username.
(Status code: 400) Operation 'Create Credential' failed
Given login was invalid
gsa: (gsad --version)
7.0.3
gvm: (gvmd --version)
/
openvas-scanner: (openvassd --version)
5.1.3
gvm-libs:
openvas-smb:
Operating system:
Greenbone Security Manager Community Edition
Installation method / source: (packages, source installation)
ISO from site
This issue was originaly opened under openvas-scanner.
While it is strongly discouraged because it may other systems, Windows (and perhaps other OSes) allow users to create accounts with a space in the username.
It'd be nice if the tool allows you to create such credential to be used by the scanner.
If not, I would suggest to at least include a more descriptive error message ( e.g. "Username cannot contain whitespace" or "Unsupported character used in field username").
When the scanner are verified by the manager then errors will be logged.
When an user don't have the "help" right, the he can't log in any more.
Steps to Reproduce:
Actual results:
Log in impossible
Expected results:
That the user can use the manager, but without the help menu.
I'm using gvm-cli (gvm-cli 2.0.0.beta1. API version 1.0.0.dev1) to connect to openvasmd on the local server to start and manage tasks, download reports etc.
An openvassd scan will spawn a lot of processes, and as a result the load on my system will increase.
At some level of load to openvassd, the gvm-cli will not connect with openvasmd and throws an error. If the load stays particularly high for some time, gvm-cli will not connect at all.
This seems to be a persistent bug, tested on two different systems, easily reproducible.
Using "gvm-cli socket -c --xml ..." or "gvm-cli socket --gmp-username foo --gmp-password foo --xml ..." will yield same results. The xml string itself has no effect on this behaviour.
Error message:
$ gvm-cli socket -c --xml "<get_version/>"
Traceback (most recent call last):
File "/usr/local/bin/gvm-cli", line 11, in
sys.exit(main())
File "/usr/local/lib/python3.6/dist-packages/gvmtools/cli.py", line 251, in main
gvm.authenticate(args.gmp_username, args.gmp_password)
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/protocols/gmpv7.py", line 198, in authenticate
response = self._read()
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/protocols/base.py", line 54, in _read
response = self._connection.read()
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/connections.py", line 275, in read
data = self._socket.recv(BUF_SIZE)
ConnectionResetError: [Errno 104] Connection reset by peer
$ uptime
11:03:24 up 4 days, 46 min, 2 users, load average: 32.38, 20.21, 8.70
Each time this happens, the openvasmd.log will print:
md manage:WARNING:2019-01-22 10h59.29 utc:16364: sql_exec_internal: sqlite3_step failed: interrupted
md manage:WARNING:2019-01-22 10h59.29 utc:16364: sqlv: sql_exec_internal failed
Somehow, I feel this must be a bug in openvasmd, possibly within src/sql_sqlite3.c, sql_exec_internal() or any other function?
Is it possible that the openvasmd code is not honoring timeouts, or the timeouts are too short in the code? This problem happens constantly when openvassd comes under load. openvasmd itself takes no load at all.
It should be noted that at the same time, the tasks.db database can easily be accessed with just any sqlite command, and will answer instantly, like:
$ sudo sqlite3 /usr/local/var/lib/openvas/mgr/tasks.db "select * from tasks;"
So, the sqlite database file (tasks.db) itself is not at all under load or inaccessible in any way (local or remotely over ssh) under these circumstances.
My system:
$ openvassd --version
OpenVAS Scanner 5.1.3$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 0356381-openvas-manager-7.0
Manager DB revision 184$ gvm-cli --version
gvm-cli 2.0.0.beta1. API version 1.0.0.dev1$ uname -a
Linux xxx 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
PDF Export
does not show the result.
Broken PDF, error in the summary?
This document reports on the results of an automatic security scan. All dates are displayed using the timezone �America/SaoP aulo00, whichisabbreviated“ − 0300.T hetaskwas“Scan − Samaritano −
AllV alids00.T hescanstartedatMonF eb2521 : 20 : 052019 − 03andendedatMonF eb2522 : 00 : 202019 −
03.T hereportf irstsummarisestheresultsfound.T hen, foreachhost, thereportdescribeseveryissuefound.P leaseconsidertheadvicegivenineachdescription, inordertorectif ytheissue.
gsa: (gsad --version)
# gsad --version
Greenbone Security Assistant 9.0+alpha~git-4d71cc189-master
GIT revision 4d71cc189-master
gvm: (gvmd --version)
# gvmd --version
Greenbone Vulnerability Manager 9.0+alpha~git-b6d078e6-master
GIT revision b6d078e6-master
Manager DB revision 206
openvas-scanner: (openvassd --version)
# openvassd --version
OpenVAS Scanner 6.0+beta3
GIT revision 3e87367-master
gvm-libs:
git - checkout: 61ae9c01880fe120ad6f49c73c588a6c3927858f
Operating system:
# cat /etc/debian_version
9.7
https://cloud.docker.com/u/dgiorgio/repository/docker/dgiorgio/openvas-source
tag: master-2.4.3
Installation method / source: (packages, source installation)
No logs.
Normal openvas scans to finish.
Normal openvas scan is created and started through "gvm-cli socket" commands with <create_target>, <create_task>, <start_task>.
Then, sometimes, the scan will halt/freeze and gvm-cli cannot even authenticate to openvasmd and the openvasmd.log will spew out errors endlessly (see below).
The openvassd is stuck (always at host_details.nasl):
19866 ? SN 0:00 | \_ openvassd: testing x.x.x.x (/usr/local/var/lib/openvas/plugins/2011/host_details.nasl)
gvm-cli socket -c --xml "<get_version/>" (and all other "gvm-cli socket" commands) will respond with errors:
Traceback (most recent call last):
File "/usr/local/bin/gvm-cli", line 11, in <module>
load_entry_point('gvm-tools==1.4.1', 'console_scripts', 'gvm-cli')()
File "/usr/local/lib/python3.6/dist-packages/gmp/clients/gvm_cli.py", line 212, in main
gvm.authenticate(args.gmp_username, args.gmp_password)
File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 220, in authenticate
return self.read()
File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 103, in read
response = self.readAll()
File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 967, in readAll
data = self.sock.recv(BUF_SIZE)
ConnectionResetError: [Errno 104] Connection reset by peer
The only resolution seems to be to restart openvasmd and openvassd, or restart the server platform, by which of course the scan is trashed and must be repeated.
Restarting the redis-server by itself has no effect.
gsa: (gsad --version)
Not in use.
gvm: (gvmd --version)
~$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 1bbda35-openvas-manager-7.0
Manager DB revision 184
openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3
gvm-libs:
~/gvm-libs$ git log
commit db1306c117df6dde5324b75cb4517b2382a5ba98 (HEAD -> openvas-libraries-9.0, origin/openvas-libraries-9.0)
openvas-smb:
Operating system:
$ uname -a
Linux xxx 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Installation method / source:
(source installation)
/usr/local/var/log/openvas/openvasmd.log repeats the following over and over again:
md manage:WARNING:2018-10-04 14h48.40 utc:17917: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2018-10-04 14h48.40 utc:17917: sqlv: sql_exec_internal failed
md manage:WARNING:2018-10-04 14h48.40 utc:17917: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)
md manage:WARNING:2018-10-04 14h48.41 utc:22606: sql_exec_internal: sqlite3_step failed: interrupted
md manage:WARNING:2018-10-04 14h48.41 utc:22606: sqlv: sql_exec_internal failed
...
gvmd starting without exausting a "warning", then terminate.
After the warningsql_prepare_internal: sqlite3_prepare failed: no such table: tickets
is written, gvmd terminates.
gvmd terminates, because it does not find table tickets
. gvmd --migrate
tells me the database is at an expected, supported version and nothing has to be done.
Oops, secure memory pool already initialized
gsad:
ec066dd67 2019-01-08 | Merge pull request #1114 from swaterkamp/SMBAlertsFilePathType (HEAD -> master, origin/master, origin/HEAD)
Greenbone Security Assistant 8.0+beta3
GIT revision ec066dd67-master
Copyright (C) 2010-2016 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gvmd:
c094bc57 2019-01-10 | Merge pull request #319 from mattmundell/content-composer-support (HEAD -> master, origin/master, origin/HEAD)
Greenbone Vulnerability Manager 8.0+beta2
GIT revision c094bc57-master
Manager DB revision 201
Copyright (C) 2010-2017 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
openvassd:
ad2274a 2019-01-10 | Merge pull request #240 from jjnicola/fix-rsa-pad (HEAD -> master, origin/master, origin/HEAD)
OpenVAS Scanner 6.0+beta3
GIT revision ad2274a-master
Most new code since 2005: (C) 2018 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison <[email protected]>
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gvm-libs:
6484f52e 2019-01-07 | Remove TODO. Since multiple KB backends are not supported, just Redis. (HEAD -> master, origin/master, origin/HEAD)
gvm-tools:
2be5246 2019-01-03 | Merge pull request #147 from wiegandm/scripts_style (HEAD -> master, origin/master, origin/HEAD)
node:
v11.6.0
redis-server:
Redis server v=5.0.3 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=23e95a3edb9c526b
Operating system:
Linux gvm10 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux
Debian testing (buster/sid)
Installation method / source:
source installation, git checkout
md manage:WARNING:2019-01-11 10h14.24 utc:65603: sql_prepare_internal: sqlite3_prepare failed: no such table: tickets
md manage:WARNING:2019-01-11 10h14.24 utc:65603: sqlv: sql_prepare_internal failed
md manage:WARNING:2019-01-11 10h14.24 utc:65603: sql_close: attempt to close db with open statement(s)
#112 and #207 had removed the alien_found() call from the NSIS/EXE LSC generation as the usage of alien was dropped in master and alien wasn't used at all for NSIS.
As a replacement a new function nsis_found() similar to the dropped alien_found() could be implemented like suggested in #207 (review)
I would like to use my AD (active directory) account which contains an underscore, to performed credentialed (authenticated) scans.
Minimally I should be prevented from entering the credentials and saving it to avoid confusion if special characters are truly not allowed.
If special characters are not allowed (unlike other tools that leverage AD credentials) than I'll need to change my service account username or possible create another account.
I'm allowed to create the credentials with no error, but the authenticated scan fails (without disclosing why in the PDF report).
Going back to edit the password for the credential, I'm then warned that I can't use special characters in the username. May be related to: #185
gsa: (gsad --version)
7.0.3
gvm: (gvmd --version)
'command not found'
openvas-scanner: (openvassd --version)
5.1.3
gvm-libs:
openvas-smb:
Operating system: Kali Linux on VMware workstation 12
Installation method / source: (packages, source installation)
Download from Offensive security (VMware tools version of Kali)
Environment: Gentoo/GCC-8.2
gvm: OpenVAS Manager 7.0.3
Installation method: Source
Expected behavior: Build completes without error/warnings
Current behavior: Build completes with warning
Error Log:
In function ‘check_private_key.constprop’,
inlined from ‘omp_xml_handle_end_element’ at /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:22377:23:
/var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:563:15: warning: argument 1 null where non-null expected [-Wnonnull]
data.size = strlen (key_str);
^~~~~~~~~~~~~~~~
In file included from /usr/include/glib-2.0/glib/gtestutils.h:30,
from /usr/include/glib-2.0/glib.h:85,
from /usr/include/openvas/misc/openvas_server.h:45,
from /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.h:30,
from /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:93:
/var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c: In function ‘omp_xml_handle_end_element’:
/usr/include/string.h:384:15: note: in a call to function ‘strlen’ declared here
extern size_t strlen (const char *__s)
^~~~~~
Reproduce: append -Wno-nonnull to cflags to remove warning.(I thought it is harmless warning)
When I try to create the rpm package under the gsa for remote log in I only get an rpm package with 0 bytes.
Let the openvas manger run in debug mode, then an error will shown, that the create process of the rpm package will fails with:
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_recreate: rpm_path: /tmp/rpm_4oI5X3/p.rpm
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: create temporary directory
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: temporary directory: /tmp/lsc_user_rpm_create_7c63Ku
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: copy key to temporary directory
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: Attempting RPM build
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: Spawning in /usr/share/openvas: ./openvas-lsc-rpm-creator.sh --target /tmp/lsc_user_rpm_create_7c63Ku /tmp/lsc_user_rpm_create_7c63Ku/openvas_scanner.pub
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: failed to create the rpm: 256 (WIF 1, WEX 1)
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: stdout: Verifying archive integrity... All good.
Uncompressing OpenVAS LSC RPM creator.........................................
LC_ALL=C ls | egrep -v ".spec" | diff MANIFEST - | grep "^>" | sed 's/^..//' | xargs rm -rf
echo Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
mkdir openvas-lsc-target-openvas_scanner-0.5
cp -ar Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in openvas-lsc-target-openvas_scanner-0.5/
tar cfzv openvas-lsc-target-openvas_scanner-0.5.tar.gz openvas-lsc-target-openvas_scanner-0.5
openvas-lsc-target-openvas_scanner-0.5/
openvas-lsc-target-openvas_scanner-0.5/openvas-lsc-target.spec.in
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.lsm.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/TODO.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself-header.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.1.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/COPYING.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/README.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/makeself.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/makeself-header.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/props/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/text-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/prop-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/props/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/entries
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/format
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.sh
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.lsm
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/TODO
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself-header.sh
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.1
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/COPYING
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/README
openvas-lsc-target-openvas_scanner-0.5/lsc-pubkey.pub
openvas-lsc-target-openvas_scanner-0.5/create-rpm.sh
openvas-lsc-target-openvas_scanner-0.5/configure
openvas-lsc-target-openvas_scanner-0.5/VERSION
openvas-lsc-target-openvas_scanner-0.5/TODO
openvas-lsc-target-openvas_scanner-0.5/RPMBASENAME
openvas-lsc-target-openvas_scanner-0.5/README
openvas-lsc-target-openvas_scanner-0.5/PUBKEYNAME
openvas-lsc-target-openvas_scanner-0.5/NAME
openvas-lsc-target-openvas_scanner-0.5/Makefile
openvas-lsc-target-openvas_scanner-0.5/MANIFEST
openvas-lsc-target-openvas_scanner-0.5/Changelog
rm -rf openvas-lsc-target-openvas_scanner-0.5
mkdir SOURCES
mkdir RPMS
mkdir BUILD
mv openvas-lsc-target-openvas_scanner-0.5.tar.gz SOURCES/
Building target platforms: noarch
Building for target noarch
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: stderr: Creating directory /tmp/lsc_user_rpm_create_7c63Ku
error: line 41: second %install
cp: cannot stat ‘RPMS/noarch/*.rpm’: No such file or directory
Call the package creation script via hand will also fail:
mkdir /tmp/X
touch /tmp/X/sample-key.pub
/usr/share/openvas/openvas-lsc-rpm-creator.sh --target /tmp/X /tmp/X/sample-key.pub
Creating directory /tmp/X
Verifying archive integrity... All good.
Uncompressing OpenVAS LSC RPM creator.........................................
LC_ALL=C ls | egrep -v ".spec" | diff MANIFEST - | grep "^>" | sed 's/^..//' | xargs rm -rf
echo Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
mkdir openvas-lsc-target-sample-key-0.5
cp -ar Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in openvas-lsc-target-sample-key-0.5/
tar cfzv openvas-lsc-target-sample-key-0.5.tar.gz openvas-lsc-target-sample-key-0.5
openvas-lsc-target-sample-key-0.5/
openvas-lsc-target-sample-key-0.5/openvas-lsc-target.spec.in
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.lsm.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/TODO.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself-header.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.1.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/COPYING.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/README.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/makeself.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/makeself-header.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/props/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/text-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/prop-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/props/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/entries
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/format
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.sh
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.lsm
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/TODO
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself-header.sh
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.1
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/COPYING
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/README
openvas-lsc-target-sample-key-0.5/lsc-pubkey.pub
openvas-lsc-target-sample-key-0.5/create-rpm.sh
openvas-lsc-target-sample-key-0.5/configure
openvas-lsc-target-sample-key-0.5/VERSION
openvas-lsc-target-sample-key-0.5/TODO
openvas-lsc-target-sample-key-0.5/RPMBASENAME
openvas-lsc-target-sample-key-0.5/README
openvas-lsc-target-sample-key-0.5/PUBKEYNAME
openvas-lsc-target-sample-key-0.5/NAME
openvas-lsc-target-sample-key-0.5/Makefile
openvas-lsc-target-sample-key-0.5/MANIFEST
openvas-lsc-target-sample-key-0.5/Changelog
rm -rf openvas-lsc-target-sample-key-0.5
mkdir SOURCES
mkdir RPMS
mkdir BUILD
mv openvas-lsc-target-sample-key-0.5.tar.gz SOURCES/
Building target platforms: noarch
Building for target noarch
error: line 41: second %install
cp: cannot stat ‘RPMS/noarch/*.rpm’: No such file or directory
The problem is the rpm macro in the commend block:
less /tmp/X/openvas-lsc-target.spec:
line 41:
%install section... do it now, and then disable it,
This line must be:
%%install section... do it now, and then disable it,
Because the script contains binary data and the source of it is missing in the git repo I can't create an patch for it.
The https://github.com/greenbone/gvmd/blob/master/INSTALL.md file currently contains the following statement:
gvmd --create-credentials-encryption-key
It seems this was dropped some time ago with 10f0632 and the text should be updated accordingly to point out that the manager needs to be restarted to re-generate the keys.
See: https://community.greenbone.net/t/cant-create-new-credential-encryption-key-via-openvasmd/1019/4
openvasmd --rebuild --progress
should work as expected.
Rebuilding the database is failing or hanging. See also: https://bugs.archlinux.org/task/57470
openvasamd --rebuild --progress
gsa: 7.0.3
gvm: 7.0.3
openvas-scanner: 5.1.2
gvm-libs: 9.0.2
Operating system: Arch Linux
Installation method / source: package installation
Here is the way I build gvm:
sed -i '1c#!/usr/bin/python2' tools/extra/xml_split
cmake -DCMAKE_BUILD_TYPE=Release -DSBINDIR=/usr/bin \
-DCMAKE_INSTALL_PREFIX=/usr -DSYSCONFDIR=/etc -DLOCALSTATEDIR=/var .
make
make install
Sorry no log files provided. But if you tell me what you need I try to start a container or VM and get it.
Now I can connect OpenVAS manager to local PgSQL server.
But now I want to connect remote PgSQL server.
Then I change the file src/sql_pg.c, In line 267 "dbname=%s user=xxx password=xxx hostaddr=x.x.x.x port=5432".
But it cannot be setup successfully, what can I do now?
When I click on "Verify Report Format" in RF-listpage for predefined RFs, I would expect either a message telling me that predefined ones can't be verified, or even better, do not allow me to click the button in the first place.
I get the error message "Failed to find report format '5057e5cc-b825-11e4-9d0e-28d24461215b'" (this is Anonymous XML).
gsa: (gsad --version)
current master
gvm: (gvmd --version)
current master
Could be handled by GSA, if gvmd returns something like the tag in the xml. Maybe or something like that.
Hi,
Your release signatures have a wrong file ending. They are named with the following pattern: gvmd-$version.tar.gz.sig.asc
. The ending sig.asc
breaks our package build system on Arch Linux. Could you please rename this either to tar.gz.sig
or tar.gz.asc
? I think tar.gz.sig.asc
is not necessary... thanks a lot.
Hi,
Not sure if this should be reported here, but when querying nvt data over socket with tools gvm-cli and gvm-pyshell, I get errors which I suspect are caused by bad xml in nvt data.
Am I right, or is there something missing in my environment?
NB this only happens when querying some nvts from some of the IT-Grundschutz-* families.
$ gvm-cli socket -c --xml "<get_nvts nvt_oid=\"1.3.6.1.4.1.25623.1.0.94018\" details=\"1\" />"
'utf-8' codec can't decode byte 0xc3 in position 1023: unexpected end of data
And inside the gvm-pyshell, I get:
$ gvm-pyshell socket -c -i
badnvt = gmp.get_nvts(nvt_oid="1.3.6.1.4.1.25623.1.0.94018", details="1")
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 525, in get_nvts
return self.read()
File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 99, in read
self.checkCommandStatus(response)
File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 136, in checkCommandStatus
status = root.attrib['status']
AttributeError: 'NoneType' object has no attribute 'attrib'
/usr/local/var/log/gvm/gvmd.log:
md main:WARNING:2018-04-15 13h24.00 UTC:10287: read_from_client_unix: failed to read from client: Connection reset by peer
$ gvm-cli --version
gvm-cli 1.3.1
$ gvm-pyshell --version
gvm-pyshell 1.3.1
$ gvmd --version
Greenbone Vulnerability Manager 7.1+beta1
Manager DB revision 190
$ openvassd --version
OpenVAS Scanner 5.2+beta1
$ python3 --version
Python 3.5.2
call openvas-lsc-rpm-creator.sh --check
will result in:
Verifying archive integrity... MD5 checksums are OK. All good.
For security reasons md5 must replaced by sha-2. Like sha-512
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.