prisma: Incorrect platform for CloudLinux OS

If you only need the Prisma client running on PlanetHoster, I ended up with a more convenient way by building the app (and most importantly generating Prisma client) outside of PlanetHoster with a matching node version, and running the app on it afterwards.

For that, before build you can add binaryTargets = ["rhel-openssl-1.0.x"] in generator client { } of schema.prisma, and after the app is built (that means after prisma generate), you would have to rename in node_modules/.prisma/client folder libquery_engine-rhel-openssl-1.0.x.so.node to libquery_engine-debian-openssl-1.1.x.so.node

– The other workaround involved modifying builded/packed js files, that’s not clean, but in the files I mentioned in the previous message, the idea is to make the getPlatform() function directly returning rhel-openssl-1.0.x. Download script isn’t present anymore, so same modification in nodes_modules/@prisma/engines/dist/postinstall.js, After that in nodes_modules/@prisma/engines folder, you would have to run node scripts/postinstall.js to download the appropriate engines.

Thank you for the context. So far, Prisma seems to be running fine on CloudLinux with the default Debian client.

The cleanest fix / workaround: Needs a root access on the server, You can do that or ask your server administrator to do that for you. The reason of having that issue, because by default CloudLinux does not allow users to access /etc/os-release file, and these steps would give the access to users to read that file. nano /etc/cagefs/conf.d/os.cfg

File content should be:

[os]
comment=OS_Release
paths=/etc/os-release

Then run the following command to update CageFS rules: cagefsctl --force-update

Now from the user account SSH, you can directly execute npx prisma generate , It will detect the OS as RHEL.

OK, all good for me 👍 There is the expected fallback warning but It’s working now.

prisma:warn Prisma doesn’t know which engines to download for the Linux distro “undefined”. Falling back to Prisma engines built “debian”. Please report your experience by creating an issue at https://github.com/prisma/prisma/issues so we can add your distro to the list of known supported distros.

Thanks! I believe it would totally solve the issue (there was indeed a problem with OpenSSL version, but it has been fixed #14042). I’ll confirm when 4.14 will be released.

Edit: 4.14 is actually already released, I will soon confirm.

Thank for the additional details @Maxime-J and @jcubic!

So, as far as I understand, there are two separate things we can do here:

1. Prisma should detect RHEL and not Debian in this case. Checking for presence of a CloudLinux-specific file is an option, but a better and more general approach, IMO, is always falling back to RHEL and not Debian when we could not detect the distro. We build RHEL binaries agains older glibc version, and they will work with a wider range of Linux distribution than our Debian binaries — in fact, they should work on all systems where our Debian binaries work too but not the other way around — so it makes more sense to use them as the fallback.
2. We should probably still consider adding a mechanism (likely an environment variable) to override the detected platform. This would be a useful workaround in different edge cases when something goes wrong in the platform detection or if the user wants to override the default behaviour (e.g. when an undesirable version of OpenSSL is picked among the multiple installed ones).

The way I circumvent that is not sustainable, a bit hacky, and might not suit every case. So I prefer not to share an exact process, it’s better to wait for an override platform detection feature.

Anyway, without the details, it involves editing prisma production files nodes_modules\prisma\build\index.js and nodes_modules@prisma\client\runtime\index.js and download the appropriate engine in nodes_modules\@prisma\engines with the download script inside and the corresponding environment variable.

Is that a problem with our current, existing implementation? Then this might be worth a new, separate issue where you explain just this problem and why this is undesirable.

I’ll fill a feature request 👍

Thanks for the info of how it works.

Concerning the detection, I bet the problem is specific to shared setups used by providers, where /etc/os-release isn’t accessible (saw that on PlanetHoster and o2switch), whereas it is on a simple CloudLinux setup.

Given how prisma detects the distribution https://github.com/prisma/engines-wrapper/blob/main/packages/get-platform/src/getPlatform.ts#L110 a working way would be to check there the presence of /usr/sbin/cloudlinux-selector and return rhel.

But maybe it’s better to rely on a platform override feature for these edge cases?

(and I finally manage to circumvent my issue with some tweaking 😃 )