Important Notice: Be sure to review and meet all the requirements listed below early in the process to prevent any unexpected issues. We've seen some customers face challenges, particularly with the "no-NAT" requirement. If you need assistance, don't hesitate to reach out to your Customer Support Manager for help.
Use cases:
Positioning with DNA Spaces
FMF with DNA Spaces
This LIPI server is just a docker-based nginx server that adds some headers. It is designed to be very simple and require very few or no upgrades over time. It is started by an entrypoint that first downloads config files and ssl certificate from our servers.
Map editor configuration requirements
Your customer success contact will help you fulfill these requirements.
A mazepos.com subdomain DNS entry pointing to the local private IP of the server where the Proxy-LIPI will be running.
A network configuration set up that covers the public IP range(s) of the customer that intends to communicate with this LIPI, that points to the dns entry above (note: that also entails the public IP range from which the LIPI is going to be installed).
A position configuration with type “MM_POSITION_CONFIG_TYPE_CLOUD_POSITIONING”. Details are here /wiki/spaces/DPD/pages/776142882
A LIPI Config set up with position provider type “MazeMap Cloud Positioning”, pointing to the position config above and the dns entry above.
Server requirements
No specific requirements except that it should have docker installed. To install docker on various platforms see https://docs.docker.com/get-docker/.
The CPU and RAM requirements will vary on traffic, but in most cases will not have any specific requirements, as this is a simple nginx proxy. E.g. running a minimum of 1x CPU and 2 GB Ram should cover most use cases.
Local network and WiFi setup requirements
The local network topology needs to be such that the source IP address of the packets received by the Proxy-LIPI server corresponds with the local IP address of that same client in Cisco Spaces.
That means there should be no NAT or proxy between the clients and the Proxy-LIPI server.
Ensure this requirement is reviewed by your IT department, specifically someone with expertise in network configuration, early in the process to avoid potential issues.
Installation, running and basic usage
You need the API key associated with the LIPI config mentioned above. It's good practice to not expose secrets in the command line, so create a file to keep it in that is not readable to other users:
echo "LIPI_API_KEY=" >proxy-lipi-docker-env-file chmod 600 proxy-lipi-docker-env-file editor proxy-lipi-docker-env-file
In the editor, paste the API key after the equals sign.
Then run:
sudo docker run --rm --name proxy-lipi \ --env-file proxy-lipi-docker-env-file \ -p 443:4343 \ gcr.io/mazemap-public-docker/proxy-lipi:latest
Note that this starts the service in the foreground, so you can’t log out or run a different command without stopping it with ctrl+c. This is suitable when testing, but not for production. See below for instructions on how to start the service in the background.
If the operating system on which proxy-lipi is being installed has https proxy, then run with additional proxy arguments as follows by replacing <https_proxy_domain_here>
with https proxy domain
sudo docker run --rm --name proxy-lipi \ --env-file proxy-lipi-docker-env-file \ -p 443:4343 \ -e use_proxy -e https_proxy=<https_proxy_domain_here> \ gcr.io/mazemap-public-docker/proxy-lipi:latest
You should see two messages about connecting to admin.mazemap.com. After this, the service should be running and can be accessed from the local network. This can be tested from the server with:
curl https://localhost:443/health -k
You can also test it from anywhere on the local network with:
curl https://<my-subdomain>.mazepos.com:443/health
Running in production
Run the container in the background by adding -d
or --detached
(detached mode):
sudo docker run -d --name proxy-lipi \ --env-file $LIPI_ENV_FILE \ -p 443:4343 \ gcr.io/mazemap-public-docker/proxy-lipi:latest
To access logs, run:
sudo docker ps -a sudo docker logs -f <container_id>
Upgrading, Restarting, and Maintenance
There can be many reasons why you want to restart the container. When it starts, it downloads a certificate and a configuration associated with your LIPI API key, and if any of those have changed, you need to restart in order to see the effects of those changes. Changes to these things require a restart to take effect:
LIPI API key
mazepos subdomain
resolver config
cloud positioning service hostname or port
MazeMap App Id or Key
Turning on or off SSL (https) for testing purposes.
Certificate renewal.
Also if a new version of proxy-lipi has been released, a restart is required to upgrade.
To restart the container, first remove it:
sudo docker rm -f proxy-lipi
If you want to upgrade, pull the newest version of the image:
sudo docker pull gcr.io/mazemap-public-docker/proxy-lipi:latest
Then start it again:
sudo docker run -d --name proxy-lipi \ --env-file proxy-lipi-docker-env-file \ -p 443:4343 \ gcr.io/mazemap-public-docker/proxy-lipi:latest
If you want to minimize downtime, put these commands after each other in a script file that you can then run.
LIPI-Cisco (DNA) Spaces diagram
FAQ
Q: Do we need a static NAT so that MAZEMAP can communicate with it ? Specifically this would be required if we require inbound access rules on the Firewall not just outbound.
A: We do not need inbound access.
Q: Is the network configuration in the MazeMap Admin Tool with IP adresses/ranges necessary for positioning in general or just necessary when setting up the LIPI
A: It’s required for the LIPI only
Q: Does the LIPI need internet (not just HSCN) facing IP And DNS record?
A: Yes. The lipi pull it's configs from api.mazemap.com so it needs to reach the internet for that. This is however done only on-startup.
The dns records to reach the lipi are currently on the domain mazepos.com . It's the only domain that will work with our ssl certificate.
Q: Does the LIPI need to connect out or are things connecting into the server and if so on what port.
A. Port 443. The lipi will log it's liveness to our database so that we can know if it is live or not. This is not required for the lipi to work though
Q: Why is the LIPI server needed for webapp?
Our web application depends on on-prem lipi server to get position updates
Q: Do we need two LIPI servers if we have a separate visitor and staff network? What if it's just different SSID?
Lipi server should run on network that has access to positioning data (access to Cisco positioning API)
Baseline: User needing positioning need access to internal IP of the lipi server and lipi server need access to cisco positioning API. If you have two cisco positioning providers, you need two lipi servers (generally that is not the case that customers have more than one cisco positioning systems)
Q: What is available external to wifi network?
Lipi is an on-prem server. It doesn't need to be available externally