Platform: Windows Server 2022 Standard, Version 21H2 (Build 20348.4171)
FileMaker Server: 21.0.2
OttoFMS: 4.13.1
SSL certificate: valid and trusted
Access: only reachable when connected to VPN
Both Otto installations are configured and operational, and I can reach each one individually. When connected to the VPN, I can access the Windows FileMaker server directly via RDP or FileMaker Pro with no issues.
However, when I try to run a Deploy operation in Otto from the Linux source server to the Windows destination, the process fails. Based on the error logs (attached), it looks like the source server cannot reach the destination server.
My assumption is that the actual file transfer during Deploy happens directly server-to-server, not routed through my local client machine. Because the Linux server is outside the VPN, it can’t see the Windows destination that’s only accessible within the VPN.
Can anyone confirm whether Otto Deploy traffic flows directly between the two servers (rather than through the initiating client)?
And if so, what’s the recommended approach when one server is VPN-restricted?
By default, OttoFMS does two way communication between the two servers for the deployments to run deployments. The OttoDeploy client is only the triggering agent.
There is an option called “Push Build to Destination” which you can toggle off to make the deployment do only one way communication from the destination. Check out the Advanced Deployment options docs for details on toggling that off. Once you toggle it off all calls are made from the destination to the source rather than both ways.
Thank you Kyle. It is still not working for me after unchecking that box. I tried twice today just now. And remembered that maybe after I updated the file maker server admin console credentials on the production box that perhaps I hadn’t updated them in Otto. After doing that I got a new error…
You’ll see in my logs that I did have a permission issue the first time. But the second time I can’t tell what I’ve done wrong.
It looks to me like the destination hostname can’t be resolved from the source server. Both machines have valid SSL certificates, and I can reach each Otto interface independently (the destination via VPN, the source from the open internet).
At this point, my best guess is that the source Linux server is still trying to “see” the internal destination host even though it’s not accessible without VPN. I’d appreciate confirmation on whether the “Push Build to Destination” option completely reverses that network direction, meaning, if it’s turned off, all traffic should originate from the destination toward the source (so the VPN restriction wouldn’t matter).
Having that option turned off should completely prevent that log you see where it says “error pushing build.” if you do the “copy deployment json” button in OttoDeploy is the push build option turned off? It should be in the json somewhere.
Having the push build option turned off will cause all network requests to initiate from the destination. It’s explicitly for exactly your use case where you have a destination server behind a vpn.
Woohoo! I had forgotten it, but that is actually a known issue with OttoDeploy. I’ll see if its feasible to release a new version of OttoDeploy with the fix this week.
If the source server can talk to the destination but not the other way around, you’ll need to follow the recommendation of the test modal and push the build to the destination before the deployment. This means going into the builds tab of OttoDeploy, creating a new build with the files you need (clones for migrations, copies for installs or replaces) and publishing that build to your destination server. Then in your deployment you can choose “Destination server outbox” as your source instead of the source server and choose your build from the list.
For background: OttoFMS deployments between two servers (unless done in separate steps like the above or like publishing to a shared s3 location) always require the destination server to be able to talk to the source server. This is so that the destination server can start a just in time build, fetch build status, or just tell the source server to push the build to the destination. Turning off the “push build” setting removes the need for the source server to talk to the destination server as the destination server directly downloads the build instead of the source server pushing the build via upload to the destination.
Try making a build ahead of time and publishing it to your destination server, that should get around this issue for you.
I don’t fully even understand what a “build” is in the FileMaker sense. I have only to servers DEV and PROD and I’d like to get a new copy of the PROD file onto our DEV server for development and testing with newer data.
I have successfully done a “dev” to “prod” deployment by turning off the “Push to destination” in advanced settings.
But now I want to make a new copy onto my dev server. Therefore going from “prod” to “dev”.
I am remote into PROD (under VPN), I can even “see” the PROD server from the “dev” server.
So why can’t PROD push to DEV when PROD is the one under VPN?
The reason the VPN is an issue for your Prod → Dev deployment is because deployments run on the destination. In OttoFMS a “buiild” is just a zip file of the .fmp12 files that are being used for the deployment. The flow works like this for the deployments you’re running:
For your Dev → Prod deployent:
You trigger a deployment from OttoDeploy. This sends a request from OttoDeploy to your Prod server installation of OttoFMS to start a deployment.
OttoFMS sends a request from your Prod Server to your Dev server collect and download the files for the deployment. The reason this failed when you had “Push build” turned on is that your Dev server cannot talk to your prod server. When doing a build push, the destination server (your prod server) requests that the source server (your dev server) upload the build using multi-part uploads. This requires both servers be able to talk to each other. turning off the push build makes it so that only destination → source communication is necessary.
OttoFMS gets the build and runs the rest of the deployment
For your Prod → Dev deployment:
You trigger a deployment from OttoDeploy. This sends a request to your dev server install of OttoFMS to run a deployment with your prod server as the source.
Your dev server attempts to connect to your prod server to request the files that are needed for the deployment. Since your prod server is on a restricted network, your dev server cannot make this connection and the deployment fails. This fails when “Push build” is on and when it is off because both cases require that the destination server (dev) be able to talk to the source (prod).
The workaround I gave you makes it so that you run this deployment in 2 parts:
Run a build on your prod server and publish it.
This will create the clones or copies, package them into a zip file, and send them to your dev server. You can do this all from the “Builds” tab in OttoDeploy. You should select the files on the prod server you want to move to dev, create copies if you’re trying to move the data or clones if you’re trying to move the schema, then toggle on the “publish” option and choose your dev server as the destination.
After running the build, run a deployment with the source as “Build Inbox” instead of your prod server
Since your dev server can’t talk to your prod server we have now moved the files from prod to dev ahead of time so that the deployment simply needs to pick up the files from the build inbox on your dev server. The depoyment will run the exact same way it normally would, it will just use the files that are already present in the dev server build inbox instead of fetching new ones from your prod server.
I know that was a lot of text, but that is the full explanation of what is going on. There are docs that cover most of these concept and how build publishing works. Does that all make sense?
