Could someone explain to me how updates of the Resin.io supervisor itself work, as this also runs in its own container and manages the updates of other containers? IOW: how does it manage its own update?
[Alexandros Marinos (alexandrosm)]@oberstet, there's a separate, super-minimal supervisor updater in the host
[Alexandros Marinos (alexandrosm)] its basically a shell script that checks the resin server directly
[Alexandros Marinos (alexandrosm)] but the truth is that we very rarely use that mechanism
[Alexandros Marinos (alexandrosm)] these days supervisors get updated when we update the hostOS
[Alexandros Marinos (alexandrosm)] we're trying to make hostOS updates easy and available for users to do themselves, so the supervisor should easily be updated that way, and otherwise it's a pretty robust system
[Alexandros Marinos (alexandrosm)] so it very rarely needs updates on its own that don't depend on the host to update as well
Thx! I will dig into it. Just that 1 follow up Q: the supervisor OS container image is part of the base OS image (A/B rootfs partitions), different from other container images which I assume reside on a data partition, right?
short version: crossbar.io supports multiple protocols: WAMP/WebSocket, HTTP/REST and MQTT. and WAMP has a number of advantages .. in particular if there is a need for remote, secure "command & control"
=> device / container management ..
eg when I read "VPN", this is making me nervous ..
[Alexandros Marinos (alexandrosm)] not sure what you mean by "one network"
[Alexandros Marinos (alexandrosm)] also, the main benefit of having a VPN for us is being able to reach devices in any environment, using a lightweight, battle tested stack
[Alexandros Marinos (alexandrosm)] if the kernel and dropbear start, we can repair the device, even if everything else has failed (docker, supervisor, etc etc)
[Alexandros Marinos (alexandrosm)] perhaps as we harden our stack more and more the VPN will be less useful, but in the early stages it has helped us find and fix countless issues, which happens when you're trying to put together a complex stack with Docker on non-x86 platforms
[Alexandros Marinos (alexandrosm)] well, hopefully resinOS is a useful component for your stack, we look forward to having many more people using our work so far and hopefully building a community of diverse use cases
at least the automotive sector is extremely security/safety sensitive .. so our story works quite well there (0 open ports, no VPN, only outgoing websocket) - but I will continue to follow resin.io! great project
Alexandros, me I just want to see the silly thing boot beyond the white screen of uncertainty. In a lot of systems, <page up>.or <page down> will remove the cover graphic and let you watch the unit operate. Got anything like that here for debug/troubleshooting?
[Alexandros Marinos (alexandrosm)]@flintiii so to summarise, you download the image from resin.io, write it with etcher having no warnings, boot the device off of ethernet, yet see nothing on the resin.io dashboard?
[Alexandros Marinos (alexandrosm)] the only thing i can imagine in this case is a corrupted download. mind telling me the size of the downloaded image, or re-downloading the OS?
[Alexandros Marinos (alexandrosm)] (I'm not ignoring your point on debug messages, I am noting it internally, but also trying to help you get off the ground in this particular case :) )
flint@seltzer:~/jobhunt/resin.io/etcher$ ./Etcher-1.0.0-linux-x86.AppImage ./Etcher-1.0.0-linux-x86.AppImage: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory ...and I really like AppImages...