Is it possible to configure proxy automatically, to avoid editing and adding redsocks.conf to system-proxy folder on boot manually.
Hi @vickyshelke! Yes, you can use the supervisor API for that: https://docs.resin.io/reference/supervisor/supervisor-api/#patch-v1-device-host-config
Hello, thank you for reply.
I was able to set up proxy as per guideline. but i did observed that after running that supervisor api request from command prompt ,device goes offline for some time .
I was thinking to put that in startup script but then ,it will lead device to go offline again and again . how can i solve this ?
Hi,
For the proxy configuration to be applied, the device needs to reboot. I would guess that that was what actually happened when it went offline?
Why are you putting it in the startup script, what are your requirements?
If you want to put it there, I would suggest to execute that request conditionally:
- check the current host config first
- if the setting is not as you’d like it to be, execute the call
- if the setting is already correct, then skip running the call
Would something like this work for you?
The requirement is, we have devices connected inside private network behind proxy.
so if device wants to be online very first time it should have proxy settings on /mnt/boot/system-proxy/redsocks.conf (which we need to add manually). customer really do not want to do that exercise for every device.
with the supervisor api we can do that,but it will only happen if device is online and container is running. (if i am not wrong) and then we need to run the script(API for proxy configuration is wrapped in shell script)manually. so to avoid manual intervention I was thinking to put it inside startup script which is only process via CMD in Dockerfile, and that might leads to reboot device again and again)
to summary , the question is if we do not have redsocks.conf edited manually on sd card ,and device is behind proxy is there any way the device can be online with proxy setting appiled.
From here I would have a few questions:
- do you prepare the device for the customer and send it to them? Or they flash an image that you’ve given them? Basically I wonder why the customer is the one that adds the
redsocks.confto the device, and not you yourself. I would imagine the setting is different for different customers? Or for the same customer it is different setting for different devices? - the reboot over and over again, that’s why I’ve mentioned that your script shouldn’t just blindly apply the setting, but should read the setting first, and check if it’s the right one. If it’s the right one, it doesn’t have to apply any change, and no reboot happens. Or do I misunderstand something?
- for the application running, you can create an image with your application preloaded, so it can run on first boot, it can run offline, etc… You can check out
resin-cli, and theresin preloadcommand.
Does this address your question somewhat? I wonder if you can elaborate on the questions we asked in return, might help us give better suggestions.
to answer your questions
-
customer is in different country than ours.we ask them to flash an image and bring the device online.(we might going to carry this activity for 40-50 devices)
the customer plants are also at different location(country) so different setting for different devices. we carry out work on development image at our desk and accordingly ask them to do the changes. -
you interpreted it right way. the question is proxy settings are in /mnt/boot/systems-proxy/
which is part of host OS . how can we access the host from container so I can check for these settings. -
let me check on that
Q. after going through Docker documentation I found there is way to give proxy settings via Dockerfile with ENV http_proxy ip:port
is it the right way to configure proxy ?
tests:
setup own proxy server via squid
accessing host os.from dashboard I removed redsocks.conf
added ENV http_proxy ip:port settings in Dockerfile
results: (little confusing)
device came online with right proxy setting and with wrong proxy settings as well .
Yeah, this is tough as you describe. I wouldn’t want the customer to change anything in the image per se.
I think the best path you might have:
- figure out the settings for a given customer, and give them an image to flash at that particular location, which has the proxy settings added to the image.
- you would need to keep track of what images you sent to which customer, and also if the customer has multiple locations, then the multiple probably settings.
- this however a much more tractable problem than having your application know about all the locations, etc, and do the setup at application run time (and you would also need to preload that application anyways)
- this is also less error prone, than remote setting/application updating proxy setting, in my opinion
For your question, I don’t think that HTTP_PROXY setting would work in this case, but it’s an interesting point! We’ll have to look into that! I guess you mean something like this? https://docs.docker.com/network/proxy/
In that case, the issue is still getting the application onto the device, and also adding different settings for different devices. In that case, even if it would work (that I don’t think it does, but will check) you would need to preload the user application onto the device, otherwise it wouldn’t have any info how to download the application. Chicken and egg.
In all this, IMHO the most likely way is adding the right redsocks.conf into the image that you send to the customer, and have them to provision from that.
As a sidenote, we are using glider for proxy testing, it’s a very lightweight, fast, and flexible project (we are not affiliated, it just helped us a lot, when we were working on proxy support, and thought I share in case it helps you too)
Just to expand on the previous answer, I’ve checked with the team. The HTTP_PROXY setting wouldn’t really help actually, as that would only apply to the docker containers that you set it to, and not for the supervisor for example, so the device still wouldn’t behave properly.
Also the application containers would need to understand how to use that value, it’s not automatic routing, but just passing on the value.
The proxy setup we have now (in the hostOS) ensures that all containers (application and supervisor) can use the proxy properly, and also whether or not the application inside the container knows how to proxy.
ok got it. let me try something like checking file setting of redsocks.conf , but how can we check /access for file presence which sits in hostOS , from app container?