Exception taken importing a valid SBOM. Appears to be bom-ref related about dependency-track HOT 18 CLOSED

The procedure you're doing looks good to me, so not entirely sure what's wrong.

However, I just checked, and DT v4.10.1 ships with H2 v2.2.224 (reminder: we publish our own SBOM alongside releases: https://github.com/DependencyTrack/dependency-track/releases/download/4.10.1/bom.json).

You could try repeating the process with v2.2.224 in the import step.

from dependency-track.

If you're indeed running DT 4.7.x or older, I'd recommend upgrading to at least v4.9.1, which introduced support for CycloneDX v1.5.

The underlying issue here is that CycloneDX v1.5 deprecated the metadata.tools[] node, and added metadata.tools.component and metadata.tools.services: https://cyclonedx.org/docs/1.5/json/#tab-pane_metadata_tools_oneOf_i1

Trivy appears to be emitting BOMs using the new notation. DT versions before v4.9.x only support CycloneDX up to v1.4, that's why you're running into deserialization errors.

from dependency-track.

I did wonder, thanks as always Niklas. I will do a trial upgrade on the test system and see if that fixes it. I'll close if it does.

from dependency-track.

Niklas. I had badly assumed that the DT version was the

version: '3.7'

At the top of the docker-compose file. So not exactly sure what version we were running. But I did a docker-compose pull to get the latest version and it is broken on bringing it up.

The error appears to be a broken database that was working fine before upgrading

dtrack-apiserver_1  | 2024-02-15 13:19:00,438 ERROR [UpgradeMetaProcessor] An error occurred connecting to the database.
dtrack-apiserver_1  | org.h2.jdbc.JdbcSQLNonTransientConnectionException: Unsupported database file version or invalid file header in file "/data/.dependency-track/db.mv.db" [90048-224]

Do I have to delete it and start from scratch or is there something I can run to fix it? I hoped it would have done the necessary upgrade.

While this is not such an issue on this one, I will have to upgrade the main one and losing the DB on that would be a big problem.

from dependency-track.

Reading #3160

from dependency-track.

It looks like you upgraded from a version earlier than v4.6.0? Can you check your production instance whether that is the case?

The version of H2 used by DT v4.5.x and earlier was end-of-life'd, and sadly the necessary H2 upgrade included breaking changes. There was no way for us to automate the migration, but we provided a guide here on how to do it manually: https://docs.dependencytrack.org/getting-started/database-support/#migrating-to-h2-v2

Arguably, it might be easier to just start over if the data is non-critical to you.

Also, if your production instance is using an external database such as Postgres instead, you will not run into this problem.

from dependency-track.

The procedure mentioned in #3160 should work.

Apparently there was a breaking change that wasn't clearly stated in the changelogs, and the H2 maintainers are recommending a dump and restore: https://groups.google.com/g/h2-database/c/-HI2ubSAD-k

from dependency-track.

Hi, the instructions worked fine, but still get the same error.

I used this - https://docs.dependencytrack.org/getting-started/database-support/#migrating-to-h2-v2

It appears to be what they said worked

from dependency-track.

Sigh, need to read the following comments in the ticket. Will give it another go

from dependency-track.

Nope if I follow his comments the jars do not exist. Will try again.

from dependency-track.

the jars do not exist

Which JARs specifically?

from dependency-track.

OK turned out I had not specified the path properly (hadn't noticed the version in the path first time around). This is what I have been trying based on the page and the comments

wget https://repo1.maven.org/maven2/com/h2database/h2/2.1.214/h2-2.1.214.jar

java -cp h2-2.1.214.jar org.h2.tools.Script \
  -url "jdbc:h2:file:~/.dependency-track/db" \
  -user sa -password ""

tar -czf dtrack-backup.tar.gz ~/.dependency-track

rm -rf ~/.dependency-track/db.*

wget https://repo1.maven.org/maven2/com/h2database/h2/2.2.220/h2-2.2.220.jar

java -cp h2-2.2.220.jar org.h2.tools.Shell

Using the following:
    URL: jdbc:h2:~/.dependency-track/db
    Driver: org.h2.Driver (or just press Enter)
    User: sa
    Password: (Empty, just press Enter)
    Once the shell confirms the successful creation with Connected, exit the shell using the quit command

java -cp h2-2.2.220.jar org.h2.tools.RunScript \
  -url jdbc:h2:~/.dependency-track/db \
  -user sa -password "" \
  -script backup.sql \
  -options quirks_mode variable_binary

So the jars exist, just still getting the same error. Does this look correct? Thanks

from dependency-track.

OK, think I have it. I just logged in and ran the commands. Trouble is, where is

~/.dependency-track/

supposed to be. I just logged in and ran things. It all worked, but I do not think it is where the database actually is. This would put it in my home directory. I did wonder, but makes sense now!

I will try and find it and fingers crossed, might get there!

from dependency-track.

If you're using Docker, the database will be in /data/.dependency-track/db.db inside the container. $HOME / ~ will resolve to /data for the user running DT (who has the user ID 1000 per default). To illustrate:

$ docker run -d --name dt --rm dependencytrack/apiserver:4.10.1
$ docker exec -it dt /bin/bash
dtrack@c958754f2c1a:/opt/owasp/dependency-track$ id
uid=1000(dtrack) gid=1000(dtrack) groups=1000(dtrack)
dtrack@c958754f2c1a:/opt/owasp/dependency-track$ ls -la ~/.dependency-track/
total 654548
drwxr-xr-x 5 dtrack dtrack      4096 Feb 16 14:06 .
drwxrwxr-x 1 dtrack root        4096 Feb 16 14:05 ..
-rw-r--r-- 1 dtrack dtrack 670203904 Feb 16 14:07 db.mv.db
-rw-r--r-- 1 dtrack dtrack       211 Feb 16 14:05 db.trace.db
-rw-r--r-- 1 dtrack dtrack         0 Feb 16 14:05 dependency-track-audit.log
-rw-r--r-- 1 dtrack dtrack     12603 Feb 16 14:07 dependency-track.log
-rw-r--r-- 1 dtrack dtrack        36 Feb 16 14:05 id.system
drwxr-xr-x 8 dtrack dtrack      4096 Feb 16 14:05 index
drwxr-xr-x 2 dtrack dtrack      4096 Feb 16 14:05 keys
drwxr-xr-x 2 dtrack dtrack      4096 Feb 16 14:07 nist
-rw-r--r-- 1 dtrack dtrack      1148 Feb 16 14:05 server.log

from dependency-track.

/var/lib/docker/volumes/nhopper_dependency-track/_data/.dependency-track

Meant to post this before you did, but got dragged into meetings. So the above is my location for it

from dependency-track.

OK so this is the file

This was the command that ran without error

sudo java -cp h2-2.1.214.jar org.h2.tools.Script
-url "jdbc:h2:file:/var/lib/docker/volumes/nhopper_dependency-track/_data/.dependency-trackdb"
-user sa -password ""

and the back up file is

and it has just the following in

-- H2 2.1.214; 
;              
CREATE USER IF NOT EXISTS "SA" SALT 'ceda277177a23ad9' HASH '0ca0d3304aebeb413e15c7d0cbdeadb430580bfd63276cf8b5a7ebd31716529b' ADMIN;     

in it.

I had to run it with sudo which is not surprising as permission denied otherwise from that directory.

Clearly not extracting the original database.

Could it be the version 2.1.214 of the extraction tool?

I tried the version from the original post and that just failed with a corrupt file message.

Any suggestions?

from dependency-track.

OK so I see

The official way to upgrade is to export it into SQL script with the SCRIPT command USING YOUR CURRENT VERSION OF H2.

Need to find out which version of H2 I have?????

from dependency-track.

Given up, tried every version of the export script. I will just have to delete the database.

Just an FYI. I inadvertently left the DT instance running over the weekend. When I came back to the system today, it had run out of disk space. I did a docker-compose down and eventually got it all back so guessing logs? Although the docker-compose logs were not large. Ah well.

Start both systems from scratch and whinge about h2 instructions!

from dependency-track.