Can vuls2 db be shared amongst multiple hosts ?

[maxenced]

Hi,

we are running vuls in server mode on a kubernetes with autoscaling. It can generate quite a lot of fetch of the vuls2 db when we are running (~50 times in the last 3 hours).

Is the database used only for reading ? And so, side question, can we host it on a shared volume so that all our instances share the same db, fetched only once ?

[MaineK00n]

Hi,

Good question. Here's how vuls.db works:

Is the database used only for reading?

After fetching, yes. The database (BoltDB) is always opened with ReadOnly: true. However, the fetch itself is a write operation — each instance independently checks whether to download based on the Downloaded and LastModified timestamps stored in the DB metadata. Specifically, shouldDownload() triggers a re-fetch if:

The DB file doesn't exist, or
The schema version doesn't match, or
More than 1 hour has passed since Downloaded, and more than 6 hours have passed since LastModified
With autoscaling, each new pod starts without the DB file (unless it's on a persistent volume), so every new instance will fetch it — which explains the ~50 fetches you're seeing.

Can we host it on a shared volume?

It depends on the volume type:

ReadWriteMany (RWX) volume backed by a local/block filesystem (e.g., hostPath, EFS with proper flock support): Multiple pods can read the DB concurrently since BoltDB uses flock(LOCK_SH) for read-only access, and multiple shared locks can coexist. However, there is a race condition risk — if one pod is fetching (writing) the DB while another pod is reading it, the reader may encounter corruption or errors because BoltDB flock does not protect across the fetch/replace operation.

NFS-based volumes: BoltDB officially discourages use on NFS because flock() may not be properly enforced across nodes, especially with NFS v2/v3.

Recommended approach for Kubernetes:

Set skipUpdate = true (or [vuls2] skipUpdate = true in config.toml) on all vuls server pods to prevent them from fetching the DB themselves.
Use an init container or a separate CronJob to fetch/update vuls.db on the shared volume periodically (e.g., every 6 hours). This ensures only one process writes at a time.
Mount the shared volume as read-only on the vuls server pods (or at least ensure they never write to it).
This way, you avoid redundant fetches, eliminate write contention, and all instances share the same pre-fetched DB.