Opened 9 months ago
Last modified 6 weeks ago
#5689 new enhancement
Set PostGIS windows bundle environment for service rather than machine.
Reported by: | slefranc | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Packaging |
Component: | install | Version: | 3.4.x |
Keywords: | windows | Cc: |
Description (last modified by )
The PostGIS Windows bundle (postgis-bundle-pg15x64-setup-3.3.2-2.exe) asks the user if they want to set environment variables during installation.
The environment is set at the machine level. This works for PostGIS itself, but can cause conflicts with other geospatial software. In our case, the GDAL variables (GDAL_DATA and PROJ_LIB) were conflicting with R's own GDAL libraries.
I was able to set the environment at the service level instead using the registry:
path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\postgresql-x64-15 name: Environment REG_MULTI_SZ: GDAL_DATA=C:\Program Files\PostgreSQL\15\gdal-data POSTGIS_ENABLE_OUTDB_RASTERS=1 POSTGIS_GDAL_ENABLED_DRIVERS=GTiff PNG JPEG GIF XYZ DTED USGSDEM AAIGrid PROJ_LIB=C:\Program Files\PostgreSQL\15\share\contrib\postgis-3.3\proj
This has worked so far in our teaching lab setup, but I haven't done thorough testing of all PostGIS functions.
Would it be possible to have the installer set the environment like this instead of globally, assuming it passes broader tests?
Change History (9)
comment:1 by , 9 months ago
Description: | modified (diff) |
---|
comment:2 by , 9 months ago
Version: | 3.3.x → 3.4.x |
---|
comment:3 by , 9 months ago
Owner: | changed from | to
---|
comment:4 by , 7 months ago
I'm prepping to release the PostGIS 3.4.2 bundle with updates GDAL 3.8.5, pgRouting 3.6.2, and mobilitydb 1.1.1. I really wanted to get this change in this cycle, but I'm running into challenges with this formulating this in my NSIS installer.
The main issue is the regular environment variables, I can specify one at a time, but looks like with services, I've got to put it all in a single entry and in binary format.
This poses two issues
1) Just getting it in there 2) How to not clobber entries e.g. put in by something else since it's just a single blob.
I think it's doable but given the difficulty, I may need to punt this to 3.5 so I can get the installers out soon and also given this may not be that trivial of a change and might have other consequences.
comment:5 by , 7 months ago
This looks like it might work - https://nsis.sourceforge.io/REG_MULTI_SZ_Editor
There is also the registry plugin - https://nsis.sourceforge.io/Registry_plug-in
follow-up: 7 comment:6 by , 2 months ago
Hey,
when you are already working on the installer script, can I maybe add to please add the removal of the environment variables to the uninstaller part, too.
Because when the postgis bundle gets uninstalled, the environment variables won't be removed. That's bad for the rest of the system, especially the CURL_CA_BUNDLE variable will point to a path which won't exist after the uninstallation and other programs will stop working completely because of the missing CA stuff.
My used PC installer system OPSI is one of them, because their client agent stops working completely. So nothing can be installed or uninstalled anymore. I have to remove that environment variable by hand before it is working again.
For now, I will add the removal of these variables in my own uninstallation script part for this postgis bundle, and I'm good. But it would be nice if this get fixed in the long run.
Thanks in advance
comment:7 by , 2 months ago
Replying to mdruve:
Hey,
when you are already working on the installer script, can I maybe add to please add the removal of the environment variables to the uninstaller part, too.
Because when the postgis bundle gets uninstalled, the environment variables won't be removed. That's bad for the rest of the system, especially the CURL_CA_BUNDLE variable will point to a path which won't exist after the uninstallation and other programs will stop working completely because of the missing CA stuff.
My used PC installer system OPSI is one of them, because their client agent stops working completely. So nothing can be installed or uninstalled anymore. I have to remove that environment variable by hand before it is working again.
For now, I will add the removal of these variables in my own uninstallation script part for this postgis bundle, and I'm good. But it would be nice if this get fixed in the long run.
Thanks in advance
Working on the scripts now. Will try to do. If you have something already prepared, feel free to attach a patch for it.
comment:8 by , 2 months ago
I put up the installer for PG17 PostGIS 3.5.0 and have it remove the CURL_CA_BUNDLE, GDAL_DATA, PROJ_LIB if it matches what was installed.
I'm keeping this ticket open since I haven't had a chance to try putting these under the PostgreSQL services. If I do I'll probably do a rerelease of PG17 PostGIS 3.5.0.
I'm going to try a bit on that for the PG13-PG16 releases and if I am successful will have those be under services, and if not successful, just do the same as I did for PG17.
Installer source file here - https://download.osgeo.org/postgis/windows/source/pg17/
comment:9 by , 6 weeks ago
I fiddled with this a bit more and sadly haven't had time to devote to it. So I'm going with what I have so far for PG17 for the rest, just uninstalling the CURL_CA_BUNDLE/ GDAL_DATA if it was installed by that installer.
I've released PG17 with mobiliditydb 1.2.0 and pgrouting 3.6.3, but setup remains the same. I'll release PG13-PG16 shortly.
That said, I'm going to keep this ticket open cause I haven't given up on it.
@slefranc,
What you propose if it works I think is preferable to the system. To be honest I was uncomfortable with the system setup too as it also causes issues if you have multiple PostgreSQL versions and they happen to use different versions of GDAL, which I try to avoid.
But anyrate I'll try to test this out and incorporate into the next version of the installer I release. I'm assuming if it is set at this level it would override the system one.
I probably won't be releasing a 3.3 version, so this will be in the next micro of 3.4 I release which I'm a bit behind on.