Certify Management Hub Linux tarball for ARM64 is missing SQLite.Interop.dll

Question
1

Hi Team,

I’m testing Certify Management Hub on my Raspberry Pi 4 running latest version os Raspi OS (Bookworm 64) and I’ve found that when I run the systemd service, I get the error below.

Sep 03 11:19:11 jellyfin Certify.Server.HubService[1444281]: Unhandled exception. System.Exception: Certify Manager failed to start. Failed to load datastore System.Exception: Failed to open or upgrade the managed items data store. :: System.DllNotFoundException: Unable to load shared library ‘SQLite.Interop.dll’ or one of its dependencies.

I’ve checked the tar file specified at Install for Linux | Certify The Web Docs (certify-mgmthub-linux-arm64-latest.tar.gz ).

After extracting it, I noticed that the file SQLite.Interop.dll (or the corresponding .so for Linux) is missing in the /dist directory, which prevents Management Hub from starting.

Steps I performed:
1. Downloaded and extracted the arm64 tarball.
2. Ran the install script install-hub.sh.
3. Started the service via systemd (sudo systemctl start certify-hub).
4. Checked logs: saw the missing SQLite.Interop.dll error.

I verified that libsqlite3-0 is installed on the system, but the application still fails to load the SQLite interop assembly.

It seems that the ARM64 Linux package is incomplete or missing the compiled SQLite interop library required for proper operation.

Could you advise if there is a workaround or updated package for arm64 devices like Raspberry Pi 4?

Thanks in advance,

Kindest Regards,

2

Thanks for raising this issue. Although we provide arm64 builds we haven’t begun testing those ourselves, so it’s possible you are the first to try that particular build.

I’m pretty sure it’s been tried ok on arm64 on windows but not on linux, I’d imagine this will affect apple silicon macs as well (we only have intel test machines here currently). We’ll check it out on a cloud based arm64 linux somewhere and see how we get on.

There is a possibility we will have to provide our own build for that, based on the suggestion here: GitHub - tkf144/System.Data.SQLite-ARM64: A dockerfile for building System.Data.SQLite for ARM64.

3

Thanks for checking the issue and for the great product you guys have developed!.

Looking forward for next steps to address the problem. If you require further info, just let me know, but pretty much the issue is very reproducible just following your guidance to deploy it to Linux ARM.

What would be really convenient would be an arm64 Docker image, which is much more common scenario, but if at least humble audience like myself could run it properly over Linux arm64, even without container model, it would be a great asset for labs and personal projects where Raspberry Pi and similar runs 24/7 while lab VMs and containers goes off at the end of the day.

Thanks again, Guys!,

4

Thanks, we’ll get that updated soon.

We do have a docker image but it’s currently not published for arm64 yet: https://hub.docker.com/r/certifytheweb/management-hub

5

Thanks for sharing but I was already aware.

I actually have tested docker image for AMD64 and works very well (I tested it deploying to Render.com) but even with qemu it doesn’t works on ARM Docker. I’ve spent some time testing this already before to try Linux installation without Docker.

I’m trying to build missing libraries myself following the link you provided.

Thanks in any case!,

6

I’ve built missing DLLs successfully and now Certify Management Hub works fine on ARM Linux!.

I’ve added them to dist folder inside tarball so I can re-use it if needed, and wanted to share it.

I hope it can be helpful. You just need to check dist folder and get the relevant files if convenient for official tarball.

Looking forward to see ARM docker image when the time and workload allow it!,

1 Like
7

Thanks for confirming that, that’s awesome. We’ll get our own build for the same thing and copy that in as part of the build process. Should be an update released within the next week or so.

8

Docker updates currently being built and published for v7.0.6, including an attempt at pushing an arm64 image, we’ll see how that goes.

Eventual fix was to move to Microsoft.Data.Sqlite instead, as it’s mostly compatible with the “official” sqlite library, but better supported for multiple architectures (because we also need macos).

9

Thanks for the update!.

I’ll keep an eye to notice when you guys release an ARM64 docker image, to test it.

For the moment I’m happy with CTW Management Hub running on Raspi 4.

1 Like
10

Awesome, the docker push failed anyway! If you have any feedback let us know.

11

I’ve noticed that v7.0.6 is out now, as you mentioned.

Upgrading over my working ARM64 direct installation (7.0.5) worked fine and CTW-Management Hub service starts properly.

Only caveat is that for some reason new version is reporting an insane amount of certs, obviously duplicated, but only on upper side of Summary section. Cert list at the bottom of same section only shows real cert number, as expected.

1
11632×754 110 KB

If I check Managed Instance List, I see the right number of certs per installation connected.

2
21730×1378 207 KB

It’s not a big problem, but it indeed started happening after upgrading all clients (Windows and Linux) to latest version.

I just wanted to let you know, as a wrap-up of this question related to CTW Management Hub running on Linux ARM64.

Luckily, it would just be happening to me.

Thanks!,

12

Thanks for reporting that issue with the managed certificates total, and also for trying out the multi-instance management.

We’ll have a look to see if we can find an issue with double-counting of statistics, it could be that the instances are re-connecting with a different connection identifier and the stats are doubling up. Presumably if you browse to your managed certificates there are no duplicates shown in the list?

13

@esmiuser further to the issue with summary counts being wrong, I think this is caused by external certificate monitoring, e.g. if you have any other supported ACME clients installed on any of these instances their numbers will be counted [possibly even double-counted] in the summary but not in Managed Instance counts.

Obviously if you don’t have any external cert managers then that’s not the problem, but if you use acme.sh, certbot, Posh-ACME, win-acme or simple-acme then it could be.