This time interval now will be followed.
But why do not run only one with all nodes and watchtower as arguments?
docker run .... --name watchtower storjlabs/watchtower:latest watchtower storagenode storagenode1 storagenode2 ...
Because update all together kill my synology RAM… after start container consume about 1.5GB RAM and after filewalker ends RAM go to about 200 MB…
I plan update to 16GB RAM
If next time interval will be followed its very good message for me.
Thanks
Have you tried the bfc3d4c9d-v1.52.2-go1.17.5 image? Does it work? We currently try to verify if the new image will work on these machines.
Trying now. Seems fine.
Running in Docker container on Odroid HC2:
$ uname -a
$ Linux storj 5.4.160-odroidxu4 #21.08.6 SMP PREEMPT Mon Nov 22 12:18:25 UTC 2021 armv7l GNU/Linux
Many thanks!
Pietro
2 Likes
This is what confuses me. And I think this can cause issues when somebody have to setup his docker storage node without loosing data.
Following can happen:
Let’s say in the base image storagnode version 1.50.4 is included.
The updated in this image updates it to 1.51.4.
Now I have to delete my docker image und create a new image with the actual base image which contains the older version 1.50.4.
If the older version is not compatible with 1.51.4 what happen in this case?
It is not. The base image contains the updater but not the storage node. The updater will download the current storage node version.
Ah ok. The new docker images have no storage node inside in the future ?
think of it as redundancy…
makes sense one makes it like that… so no matter how bad its get messed up one can restore it to operation without the SNO’s actually having to do anything.
or thats what i think the point of it is… which is me making an assumption ofc.
there are other considerations tho… it does create an additional security point, because if somebody managed to replace the image they could spawn rogue docker containers or such…
so for something like watchtower which will be little used… storjlabs should most likely lock down the security pretty tight.
a few fail safes that would alert when its tinkered with… if the image is updated without going through the proper channels.
i would consider the bare minimum and really if the image was replaced or such… the damage is essentially already done… atleast possibly.
so other elaborate security measures should be in place which, would make it near impossible for anyone else to successfully update the watchtower controlled storagenode / updater docker image.
like say there is like a secret method, so that watchtower checks with storj to verify that the hash of the image it has downloaded is okay and else it refuses to update.
so there is like a sort of two factor verification to make it possible for watchtower to update.
@littleskunk just thinking out loud here 
This is protected by docker hub. You need to have a push permissions to storjlabs docker repository to be able to alter something.
But the user could run a malicious image themselves, if they pull it from not official docker repository for whatever reason.
still a single point of failure, if dockerhub gets compromised.
It would affect a lot of services across the world, not only our images.
that it would, but stuff like that happens all the time…
1 Like
Not even this. It also downloads the latest version of the updater. It only contains a base image, supervisord and some scripts to do the initial download of binaries if they don’t exist yet.
1 Like
Yeah, you’re right. The storagenode image contains neither the storagenode nor the storagenode-updater binaries. It has only supervisord, and the entrypoint script.
The entrypoint scripts checks and installs the minimum version of the storagenode-updater binary if it’s not already installed, and later installs the storagenode binary.
Once both the storagenode and storagenode-updater are installed, the entrypoint scripts starts supervisord which then starts the storagenode and updater processes.
Note that storagenode-updater does not only update the storagenode binary but it updates itself as well.
Edit: I should add that watchtower may be useful for updating the base image, in cases where we might decide to update supervisord (and/or its configuration - /etc/supervisor/supervisord.conf), libc, etc., and then we push a new image.
But that might be rare, like once or twice a year.
5 Likes
As I am seeing different version on my nodes now:
What is going to happen if I move a v1.52.2 node to a HC2 and run Docker with the latest tag, which means for the HC2 that the latest version is v.1.49.5?
And also the other way around: What would happen if I move v1.49.5 node to a Docker that can run v1.52.2 and run it with the latest tag? Would it upgrade on the first run automatically?
Could you please try the tag from the topic instead - it’s less wasteful than moving nodes around.
The question remains and is very real:
If you move a node between machines with different versions. What will happen?
It will try to download the latest version, if you have the latest image. If you have the old image the downgrade could break databases.
this time worked on my arm32 node but I has upgraded libseccomp2 with the previous image
2 Likes