[mapserver-users] dynamic ows_serviceurl

[Kaido Irdt]

Hi Paul,

We are using basically the same process as Seth and Steve mentioned.

We are building map files per environment and per node using Chef.
Basically we parameterized the .map file and fill in parameters for every
node when we deploy.
And because we have multiple map files for different topics we are actually
building multiple map files per node per environment. (buildig map file
from templates - header_template + layers + styles + end_template)
But instead of using Chef it could be done using scripts and replacing
specific keywords with environment parameters.
This way web server won't have to do extra steps per request to change
values

Example parts of our "template" header file:

NAME           "sim_<%= @mapname %>_<%=node.chef_environment%>"
  STATUS         ON
  EXTENT         <%= node['mapserver']['extent'] %>
  FONTSET        "<%= node['mapserver']['deploy_to']
%>/fonts/current/fonts.list"
  IMAGETYPE      "png"
  CONFIG "MS_ERRORFILE" "<%=node['mapserver']['log_dir']%>/<%= @mapname
%>.log"
.....
  WEB
      METADATA
        "wfs_title"                     "SiM <%= @mapname %>
<%=node.chef_environment%>"
        "wfs_enable_request"            "*"
        "wfs_encoding"                  "UTF-8"
        "wms_title"                     "SiM <%= @mapname %>
<%=node.chef_environment%>"
        "wms_encoding"                  "UTF-8"
        "wms_onlineresource"
"https://<%=node['mapserver']['proxy_url']%>/mapserv?map=/gis/<%=
@mapname %>.map&"
        "wfs_onlineresource"
"https://<%=node['mapserver']['proxy_url']%>/mapserv?map=/gis/<%=
@mapname %>.map&"
....

Kaido



Kontakt Seth G (<sethg at geographika.co.uk>) kirjutas kuupäeval K, 13. aprill
2022 kell 11:21:

> 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")
> 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 <sdlime at 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 at 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%"    ENDEND
>
> ```
>
> 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
> ```
>
> which in our case would be
>
> ```
> PROXY-URL https://example.com/cgi-bin/{map}
> ```
>
> Thank you, Paul.
> _______________________________________________
> MapServer-users mailing list
> MapServer-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
> _______________________________________________
> MapServer-users mailing list
> MapServer-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
> _______________________________________________
> MapServer-users mailing list
> MapServer-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20220413/0a337f70/attachment.htm>