Hi,
I’ve been using Docker for a while now, and I’m exploring the possibilities of ResinOS for a future project.
I’ve just flashed an image after following the “getting started” on resin.io, and now I have a read-only filesystem flashed on my Raspberry Pi where I can’t setup neither my company proxy, neither my company nexus mirroring Docker nexus (both conf would be in systemd conf for docker daemon, files like /etc/systemd/system/docker.service.d/http_proxy.conf and /etc/systemd/system/docker.service.d/launch_options.conf).
Also, I’d need to add my company nexus certificate in /etc/docker/certs.d and modify /etc/ntp.conf a bit, so that would be 4 conf files.
So what would be the way to deal with this ? Do I need to create my own OS distribution just to setup 4 conf files ?
UPDATE : I have to say after reading the doc, I’ve found there is an “overlay” non read-only partition, so I’ve tried to copy /etc/hosts to /mnt/state/root-overlay/etc/hosts, but after modifying /mnt/state/root-overlay/etc/hosts by adding a host, I can’t ping it by his name, so I guess there is an additional step, or maybe I don’t understand how to configure a read-only rootfs.
After a good night, I guess the answer is : “don’t configure anything, just use local mode when you are in your dev environment”. But I’m still interested in this “overlay” partition on host and how to use it.
For example, in dev, if I can’t setup a docker registry mirror, I’ll have to write a nexus url prefix in my Docker file “FROM” (like “FROM nexus.mycomp.fr:5000/resin/raspberry-pi-node:latest”), but in production, I have to remove this prefix (well, ok I suppose I can use build args).
Ok so here is the furthest I can get with “local mode” :
When I do “sudo resin local push my-local-device-ip -s .” with system proxy set (http_proxy and https_proxy set), I receive a response from my corporate proxy :
“Unsupported Request Method and Protocol
Squid does not support all request methods for all access protocols. For example, you can not POST a Gopher request.”
When I do it with no system proxy set, I receive this response from resin CLI :
" network timeout at: https api.resin.io/config"
So what I conclude is there is no such thing as “local” mode for now, it has to connect to resin.io, no matter what. Is there a plan to make “local” dev mode really local ?
Also in dev phase, I’d be ok to build my image directly on the device after connecting to it via ssh, but I don’t know how to set up the certificate of my nexus3 proxy-cache on this read-only partition :
" unable to ping registry endpoint https nexus3.pleiade.edf.fr:5000/v0/
v2 ping attempt failed with error: Get https nexus3.pleiade.edf.fr:5000/v2/: x509: certificate signed by unknown authority"
Could someone pls help me understand the settings of low level tools with read-only fs ?
I’m guessing if you were to mount the SD card on your development machine (not booting from it, but mounting the contents), there the file system is read-write obviously. If you need to do settings, that might be a place to customize your setup.
We have some better story for this in the works, but for the time being that would be the way to get around. We also have better support for proxies as well coming out (but that’s just part of your story). Good feedback on what other parts of the system people need to customize for when we are developing the solution for it, cheers! 
Would this help you get ahead?
Ok, thanks, it totally helps. Also for now, it may be easier to plug my test device in any home outside of the company and control it fully remotely.
Could you just explain me why there is an “overlay” parition if you can’t override the files on the read-only partition ? Or is it only usable for very specific files ?
P.S. : your email system to answer a forum post doesn’t look to be working :
We’re sorry, but your email message to [“resin+62c5183b744f3de38e8468b94bea0bc4@discoursemail.com”] (titled Re: [Resin.io Forums] [Troubleshooting] How to manage a read-only fs when you need to do some docker conf?) didn’t work.
None of the destination email addresses are recognized. Please make sure that you are sending to the correct email address provided by staff.
Hi, as I’ve checked out, the /mnt/state/root-overlay is indeed used to overlay some areas, but it’s not taken wholesale by the look of it. For example can see the systemd service files that do some of these overlays in this folder in meta-resin.
The overlays are coming out of that directory, but in a whitelisted way instead of everything all together. This is to only override specific, known directories (well, bind mount them from elsewhere).
Thanks for the heads up about the email, can you forward that email reply to me, so we can check with our forum hosting? (gergely at resin.io)
The approach with the overlay filesystem is to only support certain configuration without requiring a custom OS build. We do this to ensure reliability in the field. I understand the issues you’re having, and we’re working on solving for all use cases. Hypothetically, though, if you were to drop in custom networking configs and were paying for support, we’d be unable guarantee the device’s reliability in the field. Does that make sense?
Ok, I get it what you are trying to achieve, but as a future customer, I expect reliability and guarantees on the device management platform, and I expect to have more control and freedom on the device itself (because anyway, I’m pretty sure I can make it unusable just by pulling a container or misusing resin CLI, so I’m almost fully responsible of what happens on the device in all case)
The current Resin stack deploys in two parts; a Supervisor OS and the Application container.
Currently configuration and changes to the Supervisor OS have to be done via whitelisted, audited and revertible routes. This is because changes to that OS can cause a device to become bricked and require physical access to re-flash. Using this allows us to guarantee that nothing the application does can cause the device to be irrecoverable, which for many of our customers is a sales feature.
Making a route for proxy changes through these routes is already in the development pipeline for another of our customers (https://github.com/resin-os/meta-resin/pull/618)
Making options available to our customers to adjust the Supervisor OS are also in the works, and these are at very early days. We’re looking at a spectrum of options from “You can’t break things, don’t worry” through to “You’re off the map, Jack”. Your use case comes at a very timely moment, and with the details you’ve provided I can ensure the task force we’re assembling to develop this will see it.
Hey @Tristan107, regarding the email issue, this is what Discourse support said about it:
This usually implies they are replying via a different email address than the email was sent to. We don’t allow this for security reasons. You might have the user check their email settings and verify the From: address in their email client matches what the To: address says in the email they were originally sent.
Yes, one way to think about it is that you are fully responsible for your devices, and that’s just a fact that you can change anything and everything on the SD card (or build your own version of resinOS since it’s all open source).
Some of the safeguards are in place because it enables us to do things that we say that we do (as the platform) easier and better. For example, read only host OS makes it straightforward to remotely update the host OS when needed. If all modifications are permitted from the get go,there wouldn’t be any hostOS update because we would never know when an update actually brinks a user’s device due to modifications.
Another thing is that in the case that you have a security vulnerability within your application and someone gets inside of your container (hope never happens but possible), even let’s say somehow they escape from the container into the host OS (very unlikely, but let’s go deep), due to the read-only hostOS they don’t have the power to actually change anything and brick your device, it can always be recovered, and your application updated / patched. This is the sort of reliability that we want to cultivate.
I expect reliability and guarantees on the device management platform, and I expect to have more control and freedom on the device itself
This is the careful tradeoff between our guarantees and your control that we are trying to balance. Happy to say that the things that you wanted to do should be possible right now by manually modifying the SD card (but note that that way you lose the remote update function), and as mentioned, we have some very exciting plans to enable exactly what you say you need (tipping the balance towards user control without giving up the guarantees).
We are excited about your feedback, and happy to see what you are developing, helping you along the way to make it the best possible product. 
Thanks for all of these answers, I can see the resin.io team is on fire 
Now I have to keep you “excited”, so in the next days, I’ll do some tests around deploying java apps on my devices and keep sending feedback. I know it’s not in the “getting started” options, but I think all pieces are there (like resin openjdk images, and free private maven repositories like deveo.com). Of course resin.io won’t do the full “build” like with other languages, it will only receive a Dockerfile with some wget to our external maven repo.
Sounds good, looking forward to it! Java was mentioned before multiple times by users that they deploy Java applications on resin. Just we ourselves don’t use it really. So please share with us your experience! 