Closed craddm closed 10 months ago
It appears these are actually on the SRD, but not where DBeaver expects them to be. The drivers seem to be in /usr/share/dbeaver/drivers/maven/maven-central
, but I can't get DBeaver to recognise them. DBeaver seems to look in /home/{user}/.local/share/DBeaverData/drivers/
, but even copying the .jar
files there doesn't seem to help.
Digging further: we manually specify driver versions in dbeaver-driver-versions.json
, but DBeaver seems to have its own ideas about what versions of the drivers should be installed. The expected versions probably change with each DBeaver release. The fallback for when the drivers aren't present is the release version, which would require internet access.
Even manually getting the right drivers on the SRD via ingress doesn't seem to help, as it still tries to check the internet for updated drivers.
Possible solution is to use snap to install DBeaver.
Snap/Flatpak seems like the right way to go here.
Snap doesn't seem to work. The drivers are still absent and/or it's still always trying to connect to the internet to update or download them.
Hmm, OK, I was hoping they would be distributed with the snap.
It seems odd to me as everything I read about DBeaver seems to imply that it is distributed with (at least some) pre-configured drivers. But there just don't seem to be any.
Reading around this more: DBeaver-CE is configured to use the drivers but doesn't actually come bundled with them. You need DBeaver-EE for a version bundled with the drivers. So installing via snap or flatpak won't help.
Back to the drawing board with trying to get it to recognise the drivers downloaded during the VM image building process.
If we know where the drivers are, can we wget
/curl
them in the image build?
Not a great solution but it might be sufficient.
They are already downloaded to the image build in the cloud-init for the build image, but I haven't been able to get DBeaver to actually recognise them. Even when I got it to acknowledge they were there, which I had to do manually through the GUI and would need doing by each user, it still seemed to want to check the internet for new ones and wouldn't actually connect to any databases.
One thing I've noticed (and fixed on my repo) is that the Github workflow is supposed to update the DBeaver driver versions but currently isn't doing that. Now trying to see if this is related to DBeaver failing to use the drivers on the image, but it's very slow going. Not sure if there's a way to test if DBeaver will actually work without fully building the image and deploying it as an SRD.
Good sleuthing. As we discussed, sounds like the drivers are out of date so DBeaver rejects them (presumably because they are incompatible with the DBeaver app) and tries to fetch valid/up to date versions.
Right, figured it out, I think. Possibly the ini location has changed between versions. Currently we write a short dbeaver.ini
during the image building stage to /usr/share/dbeaver/
that includes a line telling DBeaver which drivers to use. But DBeaver installs to /usr/share/dbeaver-ce/
and creates an ini there that doesn't include that line. Once you tweak that, it finally recognises the downloaded drivers. Suspecting that the install folder changed from dbeaver
to dbeaver-ce
at some point.
:white_check_mark: Checklist
:computer: System information
:no_entry_sign: Describe the problem
Trying to connect to either an MSSQL or PostgreSQL database using DBeaver fails, as the relevant drivers are not installed and cannot be downloaded.
:steam_locomotive: Workarounds or solutions
The drivers should be installed as part of building the SRD image, so may need to update the image.