Great. I am so glad to see a lot of interest in adding Rock-ons. I sure want to make it easier as we go along.
I think there’s a parsing error. These errors are logged in /opt/rockstor/var/log but not displayed in the UI. So checkout the logs for clues. I see you have “syncthing” as a container. It could be conflicting with the Syncthing Rock-on which also has a container with the same name. If this is the issue, choose a different name.
negative…
I have modified the json accordingly.
I cannot find anything particular in the logs. I suspect when ‘reloading’ on the Rockon-Page something should happen in the logs, but no.
Is it normal, that I had to create the directory /opt/rockstor/rockons-metastore/? Why are the other (Owncloud et al) *.json not in this folder?
Yes it is normal. rockons-metastore is a per appliance local metastore. The Rock-On profiles commonly available to everyone are pulled from a remote metastore on our server accessible to everyone. That’s why you don’t see them in the local directory.
I will give your Rock-On a try after the stable release. But good luck debugging, hope you’ll correct the issue soon!
thanks for your reply.
Can you point out, which of the log files should contain the Rock-Ons / Docker Messages?
Edit: None of the files in /opt/rockstor/var/log/ does contain the words ‘docker’ or ‘json’ (I have cleaned the directory, re-booted and hit re-load under Rock-Ons).
I have also tried using the btsync.json and modifying it by searching btsync and replacing by “ctsync”. I would now expect a “ctsync” in the Rock-Ons List, but it also does not appear.
@henfri A example 3rd Party Rock-on was referenced by @OpenSourceUser in a recent forum post. That one was the official Emby Rock-on maintained within their Emby.Build repo. That might be worth a look.
The log file you need to tail is rockstor.log.
Note that this feature is only available in the testing channel updates currently though soon to be released in the stable channel update very soon. At least that was my understanding.
When I start my first Rock-On ( ), I get a small web-page with “supervisord” though under http://rockstor:9000.
I would expect the Logitech-Server though. Port 9000 is used by docker-proxy:
netstat -tulpn | grep 9000
tcp6 0 0 :::9000 :::* LISTEN 5258/docker-proxy
This does only apper while my RockOn is running. How can I get to the web-interface of my rock-on?
congrats! Can you post your final .json file? From above I see something wrong in the port mapping. It looks like host port 9000 is being mapped twice.
That’s a typo.
Thanks for spotting.
I changed this to 9001, un-installed the rock-on, re-loaded the rock-ons and re-installed.
Still I get the same result on rockstor:9000
uninstall the app first, place the new json file in your local metastore, hit update and then install again. If for some reason the UI button goes to https://, manually change it to http://. The app worked for me. Good luck!
If all works, may I request you to write a blog post or forum doc detailing the Rock-On installation and your detailed setup of the app?
Thanks for your help. I see and understand the mistakes. I am struggling though to re-load the json. The Port-Mappings are still wrong by default.
To make sure, that Rockstor is re-loading the json, I have re-named the json and the name of the Rock-On in the .json, but Rockstor still presents me the old one.
(procedure:
uninstall old
hit reload
install
–> still old port mappings
uninstall again
rename .json
change name:
{
“SqueezeBoxServerNEW”: {
“containers”: {
hit reload
–> Still SqueezeBoxServer is presented as available rock-on. Still with the old port-mappings.
The Reason is this:
Traceback (most recent call last):
File "/opt/rockstor/src/rockstor/storageadmin/views/rockon.py", line 101, in post
self._create_update_meta(r, rockons[r])
File "/opt/rockstor/eggs/Django-1.6.11-py2.7.egg/django/db/transaction.py", line 371, in inner
return func(*args, **kwargs)
File "/opt/rockstor/src/rockstor/storageadmin/views/rockon.py", line 149, in _create_update_meta
handle_exception(Exception(e_msg), self.request)
File "/opt/rockstor/src/rockstor/storageadmin/util.py", line 43, in handle_exception
raise RockStorAPIException(detail=e_msg)
RockStorAPIException: Container(squeezebox) belongs to another Rock-On(SqueezeBoxServer). Update rolled back.
I think, this could be improved (at least some message in the UI would be good).
But still… I cannot get the port-mappings right. Supervisord and the Webserver are always swapped.
Even deleting the json from the folder “rockon-metastore” does not remove it from the Web-Interface.
Is there any way, I can force to remove the remains of the old RockOn?
@henfri [quote=“henfri, post:21, topic:298”]
Is there any way, I can force to remove the remains of the old RockOn?
[/quote]
You could try the procedure detailed by @suman in another Rock-ons related thread post by:- [quote=“suman, post:15, topic:794”]
… just starting over with a new [Rock-ons] root share.
[/quote]
Details of the procedure are in the linked post.
Love the whole “NAS + docker” idea behind Rockstor myself as well. All I really want is what Rockstor currently offers (and isn’t fuzzy about, the pool / shares / protocol stuff is great) and support for isolated services. And then to not just have a CLI somewhere, but a web-ui that helps the less savvy co-users operate the system.
Love the idea of those three steps, but wonder if there isn’t a good idea to just let people upload their own dockerfiles?
Grab tested and documented Rock-ons, or build your own stuff, and run it with no warrantee what-so-ever.
Good idea to label the “official” and “community” containers as such.
Me personally? I would just like to see a “nginx” / “apache” and “NodeJS” Rock-on. For when you need to host that simple site or webservice. Or perhaps to use as an interface for Rockstor in a domotica setting with a SoC somewhere in the network.
@Philip:
Thanks for your suggestion. Nothing easier than that; It’s a VM only and this RockOn is the only one --> Nothing to loose.
BUT: Because this is not a production System, I think we could use the opportunity, to make this more stable and to FIX the Bug.
I in fact see two problems here:
a) Once 3rd party rock-on is installed, it cannot be changed anymore (I also tried to increment the “version” parameter in the json, which sounds quite useful for the purpose; no change)
b) If a Container(squeezebox) belongs to another Rock-On(SqueezeBoxServer), i.e. if someone else also provides a Rock-On using the same container, the User just does not get to see this second RockOn. Not even an Error-Message.
Don’t get me wrong, I can solve my problem by starting over. (I’d be done by now but I’d like to contribute by helping to improve the stability.
Love your attitude @henfri. I am glad we are collaborating on this experiment. This is indeed the right opportunity to make things more robust. I’ve created an issue to do just that and your Rock-on is the right candidate to trigger this bug. Stay tuned, here’s the issue:
@phillxnet, thanks as always for being our helper-in-chief! But I think we have a budding core contributor here
We are on that path @JEV. I could easily make the Rock-On framework into a simple GUI layer of docker and leave users to deal with putting it all together. But it would (1) turn Rockstor into a kitchen sink like some other projects out there and (2) it would require users to be sufficiently proficient in docker, at which point, they can just easily manage it all from the CLI using docker and docker-compose. So I am walking a fine line here between not restricting the users in any way by giving them the ability to add their apps and building a decent UX.
I already (unofficially) use the apache Rock-on, it’s coming… My current focus is on making the framework more robust so other savvy badasses like @henfri are empowered to pitch in.
), I get a small web-page with “supervisord” though under 