Hi Paul,
The runtime substitution and setting a querystring on the server is a good
approach - have you found any drawbacks to this? Most web servers can set/add
querystrings without any need for further software.
As Steve mentioned the alternative would be to generate Mapfiles for specific
environments from a template.
I use mappyfile for this, with a Python script that can be run as part of
continuous deployment:
import mappyfile
mapfile = mappyfile.open("original.map")
# update the web metadata settings
mapfile["web"]["metadata"]["ows_onlineresource"] =
"https://example.com/cgi-bin/mapserv?map={}.map".format("test")
<https://example.com/cgi-bin/mapserv?map={}.map%22.format(%22test%22)>
mappyfile.save(mapfile, "new.map")
Typical other settings I'd change are connection strings, DEBUG level, and
EXTENTs for different Mapfiles.
Seth
--
web:https://geographika.net
twitter: @geographika
On Wed, Apr 13, 2022, at 3:52 AM, Steve Lime wrote:
> One other thing. One challenge with environment variables is knowing what's
> consistently available within a runtime environment - CGI is different from
> FastCGI and there are differences across web servers. That's one of the
> reasons pre-processing is kind of attractive IMHO. I suppose the v.8 config
> file could play a role but I'm unsure what that would be beyond a place to
> set values consistently.
>
> On Tue, Apr 12, 2022 at 8:04 PM Steve Lime <sdl...@gmail.com> wrote:
>> Hi Paul: The idea of referencing environment variables has come up before.
>> Another example would be to leverage settings injected into cloud
>> deployments as environment variables (I think there's an old ticket that was
>> recently re-opened on the topic). I'm not sure what the best way to handle
>> this would be. One possibility would be using a mechanism similar to runtime
>> subs where you'd reference the variables within the mapfile using
>> ${variable} or whatever. Another idea would be to use a pre-processor of
>> some sort to "compile" a mapfile from the environment. The latter would
>> result in better performance since you'd generate the resulting file once
>> and could also do things like inlining included snippets. This functionality
>> would be helpful for the cloud deployments, simplifying deployments in
>> multiple (dev, test, prod) environments and for keeping secrets out of repos
>> altogether.
>>
>> We're putzing around with the pre-processing idea a bit but haven't gotten
>> anything fully baked. Others?
>>
>> -Steve
>>
>> On Tue, Apr 12, 2022 at 4:56 AM Paul via MapServer-users
>> <mapserver-users@lists.osgeo.org> wrote:
>>> hi list, this has probably been discussed before, but maybe there are
>>> updates (on v8?)
>>>
>>> we would like to extract the `ows_onlineresource from the environment,
>>> instead of having an administrator to configure it on the mapfile`
>>>
>>> currently we implement a hack where the webserver layer sends an additional
>>> query parameter `ows_url` to mapserver which contains the current url
>>>
>>> in the mapfile this is implemented as
>>>
>>> ```
>>> WEB
>>> VALIDATION
>>> "ows_url"
>>> "(\b(https?|ftp|file)://)?[-A-Za-z0-9+&@#/%?=~_|!:,.;]+[-A-Za-z0-9+&@#/%=~_|]"
>>> END
>>>
>>> METADATA
>>> "ows_onlineresource" "%ows_url%"
>>> END
>>> END
>>> ```
>>>
>>> I wonder if others run into similar challenges, or if there are much more
>>> simple best practices for this case.
>>>
>>> I can imagine allowing a environment parameter 'proxy-url' like geoserver
>>> would make sense, but it should allow some kind of template, eg:
>>>
>>> ```
>>> PROXY-URL https://example.com/cgi-bin/mapserv?map={map}.map
>>> <https://example.com/cgi-bin/mapserv?map=%7Bmap%7D.map>
>>> ```
>>>
>>> which in our case would be
>>>
>>> ```
>>> PROXY-URL https://example.com/cgi-bin/{map}
>>> <https://example.com/cgi-bin/%7Bmap%7D>
>>> ```
>>>
>>> Thank you, Paul.
>>> _______________________________________________
>>> MapServer-users mailing list
>>> MapServer-users@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> _______________________________________________
> MapServer-users mailing list
> MapServer-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
_______________________________________________
MapServer-users mailing list
MapServer-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users
