skip to content

In Greenbone Community Edition, what do gvmd, ospd-openvas, openvas-scanner and gsad each do, and which protocols connect them?

level: middleimportance: must knowfreq 18%

answer

  1. manager, scanner, web server
  2. two XML protocols
  3. PostgreSQL behind the manager
  4. Redis behind the scanner

basics

~20 s

gvmd is the manager: it offers GMP, stores everything in PostgreSQL and drives the scanner over OSP. ospd-openvas launches openvas-scanner, which runs the VTs using Redis; gsad serves the web interface and speaks GMP to gvmd.

solid answer

~40 s

`gvmd`, the Greenbone Vulnerability Manager daemon, is the centre: it handles users and permissions, targets, tasks, schedules and reports, stores everything in **PostgreSQL**, and offers the XML-based **GMP** to clients. It controls the scanner over **OSP**, the Open Scanner Protocol, served by `ospd-openvas`. `ospd-openvas` collects VT data, starts and stops scans and returns results; it launches `openvas` from `openvas-scanner`, the engine that executes the NASL VTs and keeps scan data in **Redis**. `gsad` is the web server for the Greenbone Security Assistant and speaks GMP to `gvmd`, as `gvm-tools` does. Since OpenVAS Scanner 23.0, `openvasd` performs the version comparisons for local security checks.

go deeper

for a junior

Recall the main pieces: gvmd manages, ospd-openvas and openvas-scanner scan, gsad serves the web interface, and PostgreSQL and Redis hold the data.

for a middle

Explain which protocol joins which pair, GMP to gvmd and OSP from gvmd to ospd-openvas, and trace one scan through the stack.

for a senior

Use the map to operate it: which log to read for which fault, why the source build binds gsad to localhost, and why the gvm group is privileged.

for a principal

Reason about the moving parts as a platform: a Redis-heavy scanner, a PostgreSQL manager and components that must be upgraded together.

## The three parts of the stack The Greenbone Community Edition is a framework of several services. Its architecture page groups them into three parts: 1. **Scanner applications** that run Vulnerability Tests (VTs) against target systems; 2. the **Greenbone Vulnerability Management Daemon** (`gvmd`); 3. the **Greenbone Security Assistant** (GSA) web application with its web server, the **Greenbone Security Assistant Daemon** (`gsad`). Two XML-based protocols join them: **GMP**, the Greenbone Management Protocol that `gvmd` offers to clients, and **OSP**, the Open Scanner Protocol that `ospd-openvas` offers to `gvmd`. ## What each component does | Component | Role | Speaks | Stores | |---|---|---|---| | `gvmd` | Central manager: authentication, users, groups, roles and permissions, targets and tasks, scheduling, alerts, reporting | Offers **GMP**; controls the scanner over **OSP** | All configuration and scan results in **PostgreSQL** | | `gsad` | Web server written in C; serves the GSA web application's static content and an API for it | Talks to `gvmd` over **GMP** | Nothing of its own | | GSA | The browser application users run scans and read results with | Through `gsad` | Nothing | | `ospd-openvas` | OSP server that lets `gvmd` control the scanner: collects VT data, starts and stops scans, passes results back | Offers **OSP** | Uses **Redis** | | `openvas-scanner` (`openvas`) | The scan engine that executes the NASL VTs against targets | Launched by `ospd-openvas` | Writes results into **Redis** | | `openvasd` | Service from OpenVAS Scanner 23.0 that performs the static version comparisons for local security checks | HTTP API | Reads the Notus advisories | | `gvm-tools` | Clients that speak GMP or OSP for scripting | GMP, OSP | Nothing | In a source build the units show the wiring directly: `gvmd` starts with `--osp-vt-update=/run/ospd/ospd-openvas.sock`, `ospd-openvas` listens on that Unix socket, and `gsad` is started with `--listen=127.0.0.1 --port=9392`, so the web interface is local-only until you change the unit. ## How a scan flows through it 1. A user creates a target and a task in GSA, or sends the same GMP commands with `gvm-tools`. 2. `gsad` forwards the request to `gvmd` over GMP; `gvmd` records the task in PostgreSQL. 3. `gvmd` sends the scan to `ospd-openvas` over OSP. 4. `ospd-openvas` launches `openvas`, which runs the selected VTs and keeps its working data and results in Redis; local security checks go to `openvasd` for the version comparison. 5. `ospd-openvas` returns the results to `gvmd`, which stores them in PostgreSQL as a report that GSA and GMP clients read. ## Names that have changed - **`openvassd` and OTP are history.** Up to GVM 10 the scanner was the daemon `openvassd` speaking OTP; GVM 11 turned it into the `openvas` command-line application controlled by `ospd-openvas` over the stateless OSP. - **Generic OSP scanners** lost their support in Community Edition 22.4, so in the Community Edition `gvmd` drives `ospd-openvas`. - **The Notus Scanner** was added in 22.4 for local security checks; the glossary records that it was replaced by `openvasd` with OpenVAS Scanner 23.0. ## Why the map matters in practice - **Reading logs.** The troubleshooting page sends scan-time faults to `/var/log/gvm/ospd-openvas.log` and `/var/log/gvm/openvas.log`, and everything else to `/var/log/gvm/gvmd.log`. - **Hardening.** The source-build unit binds `gsad` to `127.0.0.1`; exposing the web interface is a deliberate unit change. Members of the `gvm` group can alter the `.nasl` scripts that `openvas` runs as root through `sudo`, so membership must stay minimal. - **Capacity.** Redis holds scan data while scans run; the troubleshooting page describes the Linux OOM killer stopping Redis on large scans. - **Upgrades.** The components share interfaces that change between releases, so they are upgraded together, and `gvmd --migrate` updates the PostgreSQL schema when a new release needs it. ## How to answer in an interview Draw the chain from left to right: browser, GSA, `gsad`, GMP, `gvmd` with PostgreSQL, OSP, `ospd-openvas`, `openvas` with Redis, then the targets. Name the two protocols correctly, GMP towards clients and OSP towards the scanner, and say where each store sits. Mentioning that `openvasd` now handles the local-security-check comparisons, and that `openvassd` with OTP is the pre-GVM 11 design, shows the answer is current rather than remembered from an old tutorial.

  • Why should membership of the gvm group on a Greenbone source build be kept small?
    The source-build guide lets the `gvm` group run `openvas` as root through `sudo`, because many VTs need raw sockets. Members of that group can also change the `.nasl` scripts, which then run with root privileges, so the group is effectively a path to root on the scanner host.
  • What did GVM 11 change about the scanner process and its protocol?
    It turned the long-running `openvassd` daemon into the `openvas` command-line application, controlled by the `ospd-openvas` service layer. The stateful OTP protocol was replaced by OSP, a stateless, request-response XML protocol.

saying these in an interview costs you the question

  • The web interface sends scans straight to the scanner over OSP.
  • openvas-scanner writes scan results into the PostgreSQL database.
  • GMP and OSP are two names for the same protocol.
  • gsad keeps its own copy of the scan reports.
  • The current scanner is still the openvassd daemon speaking OTP.