As you may already know both GDAL and MapServer had a new stable release in the recent days and I've updated http://vbkto.dyndns.org/sdk/ to provide the Windows binaries according to these versions.
If you prefer using the latest stable releases (GDAL 1.8.0 and MapServer 5.6.6) then choose the 'release' packages, but you may also download the most recent daily builds of the stable branches (always containing all the subsequent changes since the last release) by choosing the 'stable' packages.
The development versions of GDAL and MapServer are also available for testing by using the 'development' packages.
I've also added Windows installers for the GDAL components providing to install the GDAL command line tools and the python bindings easily. Installers for MapServer with IIS registration and PHP support will also be available shortly.
Monday, January 24, 2011
Wednesday, December 22, 2010
Daily built binary packages for MapServer with OpenSSL support
SSL support has been added to the daily built binaries which provides the option to access a secure WMS/WFS server on Windows. Here are the key steps to configure this option in your Mapserver/Mapscript installation:
1. Configure the mapfile with one or more WMS/WFS client layer
This will require to configure a layer with 'CONNECTIONTYPE WMS' or 'CONNECTIONTYPE WFS' and set up your connection information according to the following fragment:
LAYER
CONNECTION "https://www.secureservice.com/service?"
CONNECTIONTYPE WMS
METADATA
"wms_srs" "EPSG:4326"
"wms_name" "NAME"
"wms_format" "image/png"
"wms_server_version" "1.1.1"
"wms_auth_username" "username"
"wms_auth_password" "password"
END
TYPE RASTER
...
END
2. Make sure to install all the required files in your deployment
For the SSL support you require to install libeay32.dll and ssleay32.dll along with libcurl.dll in the run-time configuration. Without having OpenSSL added to the builds you got the following error:
msHTTPExecuteRequests(): HTTP request error. HTTP: request failed with curl error code 1 (Protocol https not supported or disabled in libcurl)
3. Set up the cerificate bundle along with your installation.
In short it will require to set up the CURL_CA_BUNDLE environment variable to point to the location of the .crt file. You can find this file (curl-ca-bundle.crt) in the /bin/curl folder of the binary packages mentioned above. The file contains the most recent version of http://curl.haxx.se/ca/cacert.pem (at the time of the nightly build).
Note: CURL_CA_BUNDLE can be set up system wide (in My Computer->Properties), however you may prefer to apply this environment setting only for the process hosting the mapserver libraries so as not to cause side effects for other applications using libcurl and openSSL. The main issue here is that most of the libararies use getenv to retrieve the environment setting, which operates only on the data structures accessible to the run-time library (msvcrt) and not on the environment "segment" created for the process by the operating system. In this regard the libraries work only on a snapshot of the variables that have been set during the process startup. In this regard you may choose to set up the environment before the process has been started (by using a startup script) or use _putenv to set up the environment variable at run time. I will be trying to discuss this topic in more detail in a subsequent post.
You may check whether your WMS/WFS server is working with the standalone installation of curl.exe in the binary packages and open an SDK command prompt by using SDKShell.bat supported with the packages. In the command prompt you may use a valid url to your service, like:
curl "https://username:password@www.secureservice.com/service?..."
At this point if you get valid data response you may omit the following step.
4. Extract the certificate entry from the server
In the previous step if you get the following error, your remote server probably use a self-signed SSL certificate and the server certificate is not included in your CA bundle file.
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
To get the remote server certificate you may use openssl.exe in the command prompt (also included in the daily buillt packages) according to the folowing example (you may probably use the default SSL port:443 in most cases):
openssl s_client -connect www.secureservice.com:443
Copy all from "-----BEGIN CERTIFICATE-----" tag to "-----END CERTIFICATE-----" tag. Paste it at the end of the curl-ca-bundle.crt file, and repeat #3 to make sure the certificate data is now working.
1. Configure the mapfile with one or more WMS/WFS client layer
This will require to configure a layer with 'CONNECTIONTYPE WMS' or 'CONNECTIONTYPE WFS' and set up your connection information according to the following fragment:
LAYER
CONNECTION "https://www.secureservice.com/service?"
CONNECTIONTYPE WMS
METADATA
"wms_srs" "EPSG:4326"
"wms_name" "NAME"
"wms_format" "image/png"
"wms_server_version" "1.1.1"
"wms_auth_username" "username"
"wms_auth_password" "password"
END
TYPE RASTER
...
END
2. Make sure to install all the required files in your deployment
For the SSL support you require to install libeay32.dll and ssleay32.dll along with libcurl.dll in the run-time configuration. Without having OpenSSL added to the builds you got the following error:
msHTTPExecuteRequests(): HTTP request error. HTTP: request failed with curl error code 1 (Protocol https not supported or disabled in libcurl)
3. Set up the cerificate bundle along with your installation.
In short it will require to set up the CURL_CA_BUNDLE environment variable to point to the location of the .crt file. You can find this file (curl-ca-bundle.crt) in the /bin/curl folder of the binary packages mentioned above. The file contains the most recent version of http://curl.haxx.se/ca/cacert.pem (at the time of the nightly build).
Note: CURL_CA_BUNDLE can be set up system wide (in My Computer->Properties), however you may prefer to apply this environment setting only for the process hosting the mapserver libraries so as not to cause side effects for other applications using libcurl and openSSL. The main issue here is that most of the libararies use getenv to retrieve the environment setting, which operates only on the data structures accessible to the run-time library (msvcrt) and not on the environment "segment" created for the process by the operating system. In this regard the libraries work only on a snapshot of the variables that have been set during the process startup. In this regard you may choose to set up the environment before the process has been started (by using a startup script) or use _putenv to set up the environment variable at run time. I will be trying to discuss this topic in more detail in a subsequent post.
You may check whether your WMS/WFS server is working with the standalone installation of curl.exe in the binary packages and open an SDK command prompt by using SDKShell.bat supported with the packages. In the command prompt you may use a valid url to your service, like:
curl "https://username:password@www.secureservice.com/service?..."
At this point if you get valid data response you may omit the following step.
4. Extract the certificate entry from the server
In the previous step if you get the following error, your remote server probably use a self-signed SSL certificate and the server certificate is not included in your CA bundle file.
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
To get the remote server certificate you may use openssl.exe in the command prompt (also included in the daily buillt packages) according to the folowing example (you may probably use the default SSL port:443 in most cases):
openssl s_client -connect www.secureservice.com:443
Copy all from "-----BEGIN CERTIFICATE-----" tag to "-----END CERTIFICATE-----" tag. Paste it at the end of the curl-ca-bundle.crt file, and repeat #3 to make sure the certificate data is now working.
Sunday, September 12, 2010
OGR MS SQL 2008 Spatial driver
I've now added the initial revision of the OGR MS SQL Spatial driver to the GDAL repository. For further information please refer to the driver information page.
Working binaries (which always contain all the recent fixes) can be downloaded from the daily build system available at: http://vbkto.dyndns.org/sdk/
Since I didn't have the chance to test with all kind of the fancy spatial data types any feedback on the potential issues are graciously accepted.
Upon the experiences gathered when writing this driver, I'm also planning to add support for accessing the native SqlGeometry/SqlGeography serialization format in the MapServer sql2008 driver which appears to provide a significant increment in the performance of the data retrieval.
Working binaries (which always contain all the recent fixes) can be downloaded from the daily build system available at: http://vbkto.dyndns.org/sdk/
Since I didn't have the chance to test with all kind of the fancy spatial data types any feedback on the potential issues are graciously accepted.
Upon the experiences gathered when writing this driver, I'm also planning to add support for accessing the native SqlGeometry/SqlGeography serialization format in the MapServer sql2008 driver which appears to provide a significant increment in the performance of the data retrieval.
Sunday, May 2, 2010
Python distutils and manifest files (Visual Studio 2010)
Visual Studio 2005 introduced a new deployment model for Windows client applications based on isolated applications and side-by-side assemblies. The redistributable libraries (such as MFC, ATL, CRT) have been rebuilt as shared side-by-side assemblies and installed in the native assembly cache, WinSxS folder in Windows. This has provided a common location for particular versions of the dll-s and the applications had to declare their dependencies by using a manifest file. The manifest file is an XML file which contain references to the dependent dlls located in WinSxS, these files had to be deployed along with every dll or executable which depend on the redistributables. Without having the manifest (either by a separate file or embedded in the executable as a resource) the application generates an error.
Though the purpose of this change was to simplify deployment, the result was probably the opposite. As a result Microsoft changed deployment requirements in Visual C++ 2010. As of Visual Studio 2010 Microsoft has backed out the manifest generation and no manifests are generated by default with the VC2010 builds. There's no requirement to embed manifests in the executables anymore and CRT-s need not be installed in WinSxS. All you need to do is copy the VC++ dependent DLLs to the application folder and run.
This change may however cause issues for those build systems (like python distutils) which don't expect that the manifest may eventually be missing and stop the compilation in this condition. I don't see any change in this regard in the python SVN trunk either. Fortunately to prevent from this issue we could easily alter the corresponding file (/Lib/distutils/msvc9compiler.py) to something like:
# embed the manifest
# XXX - this is somewhat fragile - if mt.exe fails, distutils
# will still consider the DLL up-to-date, but it will not have a
# manifest. Maybe we should link to a temp file? OTOH, that
# implies a build environment error that shouldn't go undetected.
if os.path.isfile(temp_manifest):
mfid = 1 if target_desc == CCompiler.EXECUTABLE else 2
out_arg = '-outputresource:%s;%s' % (output_filename, mfid)
try:
self.spawn(['mt.exe', '-nologo', '-manifest',
temp_manifest, out_arg])
except DistutilsExecError as msg:
raise LinkError(msg)
else:
log.debug("skipping %s (up-to-date)", output_filename)
Which may work even if the deployment model will frequently be altered by Microsoft from versions to versions ;-)
Though the purpose of this change was to simplify deployment, the result was probably the opposite. As a result Microsoft changed deployment requirements in Visual C++ 2010. As of Visual Studio 2010 Microsoft has backed out the manifest generation and no manifests are generated by default with the VC2010 builds. There's no requirement to embed manifests in the executables anymore and CRT-s need not be installed in WinSxS. All you need to do is copy the VC++ dependent DLLs to the application folder and run.
This change may however cause issues for those build systems (like python distutils) which don't expect that the manifest may eventually be missing and stop the compilation in this condition. I don't see any change in this regard in the python SVN trunk either. Fortunately to prevent from this issue we could easily alter the corresponding file (/Lib/distutils/msvc9compiler.py) to something like:
# embed the manifest
# XXX - this is somewhat fragile - if mt.exe fails, distutils
# will still consider the DLL up-to-date, but it will not have a
# manifest. Maybe we should link to a temp file? OTOH, that
# implies a build environment error that shouldn't go undetected.
if os.path.isfile(temp_manifest):
mfid = 1 if target_desc == CCompiler.EXECUTABLE else 2
out_arg = '-outputresource:%s;%s' % (output_filename, mfid)
try:
self.spawn(['mt.exe', '-nologo', '-manifest',
temp_manifest, out_arg])
except DistutilsExecError as msg:
raise LinkError(msg)
else:
log.debug("skipping %s (up-to-date)", output_filename)
Which may work even if the deployment model will frequently be altered by Microsoft from versions to versions ;-)
Visual Studio 2010 (Win32/Win64) packages are now available
After some investigation of a couple of issues, I've finished to set up daily build packages compiled with Visual Studio 2010. Just as for the previous packages I've compiled all the dependecies with Visual Studio 2010 to prevent from potential memory corruption issues as described in my earlier post: Redistribution of the shared C runtime component in Visual C++
The packages can be downoaded from the usual location: http://vbkto.dyndns.org/sdk
In addition to the binary packages the build SDKs for VS2010 are also available (containing the libs and headers)
Although the builds seem to be in good condition (the auto tests are running correctly) don't hesitate to contact me if any further issues encountered.
Note on the MrSID driver: Currently there are no available VS2010 versions of the LizardTech GeoExpress Raster DSDK, therefore the MrSID plugin is not included in the Visual Studio 2010 packages. However you might want to copy (bin\lti_dsdk_dll.dll and bin\gdal\plugins\gdal_MrSID.dll) from the corresponding VS2008 packages in order to have MrSID support switched on.
The packages can be downoaded from the usual location: http://vbkto.dyndns.org/sdk
In addition to the binary packages the build SDKs for VS2010 are also available (containing the libs and headers)
Although the builds seem to be in good condition (the auto tests are running correctly) don't hesitate to contact me if any further issues encountered.
Note on the MrSID driver: Currently there are no available VS2010 versions of the LizardTech GeoExpress Raster DSDK, therefore the MrSID plugin is not included in the Visual Studio 2010 packages. However you might want to copy (bin\lti_dsdk_dll.dll and bin\gdal\plugins\gdal_MrSID.dll) from the corresponding VS2008 packages in order to have MrSID support switched on.
Saturday, March 20, 2010
MapServer 5.6.2 released
After fixing a few important issues found in 5.6.0 and 5.6.1 the MapServer team has announced the release of MapServer version 5.6.2.
Please refer to the history page for the related changes.
The binary distributions listed in the download page should be updated with the new release in the next few days.
Please refer to the history page for the related changes.
The binary distributions listed in the download page should be updated with the new release in the next few days.
Saturday, March 6, 2010
Changes in the MapServer MSSQL2008 driver
According to the feedback of the users this driver has been broken with regards to the query handling. By looking into the details I've fixed a couple of issues, like:
- Added a default implementation of LayerResultsGetShape? (causing a systematic failure as of the single-pass query implementation)
- Changed the query shape to POINT instead of POLYGON when the area of the query shape is zero (causing a failure at the server).
- Fixed the buffer length when creating the query shape (to prevent from the memory corruption error).
- Added advanced error reporting (ODBC errors) on the msDebug output.
- Added the OID to the field list of the query select statement (causing errors when retrieving the columns).
These changes along with fixes for several further issues will are available to download from http://vbkto.dyndns.org/sdk/
Any feedback and further testing efforts would be helpful, before we issue the next stable release, MapServer 5.6.2 (hopefully in the next week)
- Added a default implementation of LayerResultsGetShape? (causing a systematic failure as of the single-pass query implementation)
- Changed the query shape to POINT instead of POLYGON when the area of the query shape is zero (causing a failure at the server).
- Fixed the buffer length when creating the query shape (to prevent from the memory corruption error).
- Added advanced error reporting (ODBC errors) on the msDebug output.
- Added the OID to the field list of the query select statement (causing errors when retrieving the columns).
These changes along with fixes for several further issues will are available to download from http://vbkto.dyndns.org/sdk/
Any feedback and further testing efforts would be helpful, before we issue the next stable release, MapServer 5.6.2 (hopefully in the next week)
Subscribe to:
Posts (Atom)
