when does the rock-on getting updated?
or is there any way for me to exchange the binary with the one provided on the homepage directly on the server?
Another thing to mention, the rock-on uses a 32bit binary, rockstor only runs on 64bit hardware, so why not using 64 bit for btsync?
the rockons use docker as a backend, if setup properly one could just stop the running container, remove it and start the new one with the same parameters as the previous.
the only exception is if the new container somehow needs some sort of migration for the permanently stored data (eg some database)
if those requirements are met it should be easy for rockstor to autoupdate those container
this sounds great.
but I am still not familiar with docker and for me it would just be nice to click update
however creates or wherever this rock-on/docker gets fetched, it is important that they do get update as well.
for btsync I am now in trouble because they changed the licensing in the new 2.2 release,. I am pro user and some boxes are now using the new license, some the old and the old experies someday now.
whoever, however, provided the bsync docker, I would love to see an update, or write someone to update it, or whatever. who is the source of the docker containers used as rock-ons anyhow?
i dont know how it is done right now ( it seems only /data is shared, i guess the settings are stored in the container), for future containers the prefered way is to include the settings dirs as shared too so one can just replace the container to update the app. Im sure the bittorrent guys know that, but if not you can forward it to them. would be a shame if the official container lacks that
when such a container exists a simple
docker stop <container>
docker rm <container>
docker run <btsync:latest>
can be implemented into the gui for the upgrade, the parameters for run may vary ofc.
change the start.sh to start the btsync-current instead of btsync:
move the cursor behind the btsync in the last line and press i, then type -current so it points ot the right executable, then press ESC and type :wq to exit the insert mode, write and quit.
After inserting -current the line should look like this:
now just type exit to get back to the host and stop/start the btsync rock-on
for future upgrades repeat the same procedure for now as there is no official upgrade path for the docker container.
Just remember to change the suffix for the btsync executable with every upgrade to something different as you cant overwrite the file while its in use and i have not searched for another way around to kill the server without shutting down the whole container because the script exits.
@suman it might be possible for you to pull the image, modify the start.sh to do some automatic checking for a new version and replace the current btsync with the eventually new one, wget -N should suffice. after this change you could save the container to an image and publish it on the docker hub and use this modified version instead for btsync
if the official version is just to be released ignore this ofc
i edited the no certificate option and ESC into my post and stated the finished result for clarification, one forgets about esc easily when besing used to vi
as far as i can see the limetech dockerfile seems, hm, bad
without the added files you cant build it yourself so for upgrades which dont happen inside the container you rely on the maintainer, and the image is last build when it got created
if i remember correctly the image currently used can be built by anyone, so setting up a rockstor/btsync repo should be possible by just copying the dockerfile (and maybe changing some lines)
one just needs to change the repo name in rockstor to point to the rockstor-staff-maintained version
Is it possible to replace the current rock-on with this?
I have tried doing so manually by:
Install the normal rock-on.
Delete the container.
Build a new container using the old container name & the desired Docker image.
However it errors out. Judging from the logs, it is launching the btsync rock-on by container ID rather than name, which is smart in normal operation but is causing issue here. I am not yet sure if one is able to force a set ID upon a container.
I am very much looking forward to the community container feature being implemented but until then, is there a way to replace this rock-on with an official docker image from BTSync or my own custom one?