HTTP Request "No route to host", but only problem is with Ignition

Ignition
1

We've run into a strange issue. I originally set up an HTTP binding on a Dropdown component to populate it with options from our middleware API. It worked fine the first day, but since then, I’ve been consistently getting a “no route to host” error.

I then attempted to retrieve the data using scripting via httpClient, but encountered the same error.

To troubleshoot, I tested the same endpoint in Postman, and the request went through without any issues. I also wrote a quick script in standard Python 3 to test the call, and that worked perfectly as well.

Has anyone else experienced something similar? Any ideas on what might be causing this?

2

Can you share your code? We can't help if we have no details?

3

Are you running Postman and the scripting tests on the same machine where the Ignition Gateway is running?

4

There isn't any code to really share? Its just an HTTP binding, and then I tested it with scripts with a simple httpclient code. I can give you a mock up here if it will help you visualize it.:

        payload = {}
        api_url = ""

        response = httpClient.post(api_url, data=payload,
        headers={
	            'Content-Type': 'application/json'
	        })

        if response.statusCode == 200:
            logger.info("success")
            return response
5

Yes! Its being ran and tested on the same machine as the Ignition Gateway, which makes it all the more strange. We thought it was a network issue, but if that was the case POSTMAN and my python3 script wouldn't work as well, right?

6

Maybe. Ignition runs as a service typically, and that can mean different things depending on your OS or security setup.

It could also be that your python3 script and Postman are using a system proxy that Ignition would not pick up or use by default.

7

We're currently running our Ignition Gateway on macOS Sequoia. Since we're still in the development phase and haven’t deployed yet, we don’t have any special security configurations in place. To rule out basic networking issues, we even temporarily disabled the firewalls on both the machine running Ignition and our middleware server—but we’re still encountering the same issue.

If there’s a system proxy that Ignition isn’t able to detect (not that I even know where it would have come from haha), how can I test for that and verify whether it’s affecting HTTP communication?

8

:light_bulb:

read upwards in that thread

2 Likes
9

Sorry if this seems like an ignorant question, but I was reading the thread and followed the advice where I commented out the RUN_AS_USER line in ignition.sh. Do I need to redownload the installer and install ignition again?

I changed the file and ran ./ignition.sh stop and ./ignition.sh start in my terminal and the problem is still persisting.

10

No installing again shouldn't be necessary. Not sure if there's anything else needed, maybe @jcoffman knows.

I'd just run Ignition in Docker or a VM instead. I assume this is just for development and you aren't actually deploying to prod on a Mac.

11

Yeah, when we actually deploy it will probably be on a windows or linux machine. If this is truly just a mac issue (which is super strange cause I can call other API's no problem on this machine with Ignition, its just our middleware API thats giving this error), I'll just download the docker image for Ignition and see if I can get that up and running and test again.

Thanks again for all your help too by the way, really appreciate it!

12

Might also be worth trying the zip “installers” instead of the actual installer. I’ve never had an issue with those on my Mac. I never use the Ignition installers for any platform.

13

I got some free time today, I'll test docker and the zip installers to see if the issue is fixed and report my findings later here. Hopefully it can help someone who comes across this thread in the future.

14

Updates:

Docker Image: HTTP binding has no issue now and the no route to error has disappeared, however, I am unable to save the project or see session props unless I do the fix laid out here:

But currently workable

Zip installer: Uninstalled and reinstalled ignition with the zip installers through my terminals. while it has the same issue as above (I have to click File > Open in my already opened project to save and see session props ), the issue with the HTTP binding is resolved!

So my takeaway is in the future if I install Ignition on macOS to use the zip installer instead of the .dmg

15

Mac OS Sequoia added a new permission requirement for applications to access the local network and implemented it very poorly which causes launchd daemons which are not run as the root user to have absolutely no way to approve or grant the access. The only way currently (a bug fix is currently in the works for this for 8.1) is to:

  1. install the launch daemon to run as root by commenting out RUN_AS_USER in ignition.sh prior to running ignition.sh install which must be done after install using the installer without starting the gateway or via the zip installer. Ill leave this up to you to determine the security ramifications of this
  2. don't install it as a service and start the process from the Terminal application which grants the ignition process the same security context, which does allow local network access.

This ticket is currently underway and hopefully i can have a solution in time for the next 8.1 release

Hope that helps,
JJ Coffman

1 Like