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!
Hello Suman,
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.
Could this be a bug?
Greetings,
Hendrik
@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.
Hope that helps.
Hello,
it does work with the new release now. Thanks!
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?
Regards,
Hendrik
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.
Sure, here it is:
{
"SqueezeBoxServer": {
"containers": {
"squeezebox": {
"image": "tdeckers/logitechmediaserver",
"launch_order": 1,
"ports": {
"9000": {
"description": "Webserver Port. Suggested default: 9000.",
"host_default": 9000,
"label": "Webserver port",
"protocol": "tcp"
},
"9090": {
"description": "CLI Port. Suggested default: 9090.",
"host_default": 9090,
"label": "CLI port",
"protocol": "tcp"
},
"3483": {
"description": "SlimProto Port. Suggested default: 3483.",
"host_default": 3484,
"label": "Slimproto port",
"protocol": "tcp"
},
"9001": {
"description": "Supervisord. Suggested default: 9001.",
"host_default": 9000,
"label": "Supervisord port",
"protocol": "tcp"
}
},
"volumes": {
"/media": {
"description": "Select the Share containing your Media",
"label": "Config Media",
"min_size": 1073741824
}
}
}
},
"description": "Server for Squeezebox Devices",
"ui": {
"https": true,
"slug": ""
},
"volume_add_support": true,
"website": "http://mysqueezebox.com",
"version": "1.0"
}
}Why is the host_default 9000 here?
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
Any Idea?
Greetings,
Hendrik
I noticed a couple of small errors. For instance, the UI is not HTTPS, so you shouldn’t have added “https”: true. Here’s the working profile as a gist: https://gist.github.com/schakrava/cfccb12200c18027c97a#file-squeezebox-json
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?
Hello Suman,
of course you ay ask. I will, for sure!
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?
Greetings,
Hendrik
@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.
Hopefully that should give you a fresh start.
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.
Hello,
@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.
Greetings,
Hendrik
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.
Could you please add your requests to Rock-on requests
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.
Hello,
I have two questions regarding Rock-Ons:
The plex Rock-On provides a link to the Plex-Webui in the Rockstor-Web-Ui. How can I do this for 3rd party Rock-Ons?
Apart from that, I see a problem with the Configuration-Subvolumes:
Curently, I am using the same Subvolume to every Rock-On:
/mnt2/RockOns_config
This is dangerous, as there can be file collisions between different Rock-Ons
Better would be providing -or automatically creating- a Folder or a sub-Subvolume (not sure whether this is possible) within this Subvolume.
E.g. one would specify the Share /mnt2/RockOns_config in the configuration of the Rock-On, but this would automatically create a folder/subvolume
/mnt2/RockOns_config/plex/
The alternative is of course to create subvolume per Rock-On by hand:
/mnt2/RockOns_config_plex
/mnt2/RockOns_config_logitechmediaserver
/mnt2/RockOns_config_btsync
/mnt2/RockOns_config_syncting
But this would be very unstructured and full after a while…
Greetings,
Hendrik
Hello,
I’d like to bump the discussion above.
On top, I have another question:
Is there a way, to run a Rock-On with the parameter --privileged and to specify/mounts volumes that are not a subvolume and not user-definable?
I am trying to create a docker-ui rock-on but it requires this:
docker run -d -p 10.20.30.1:80:9000 --privileged -v /var/run/docker.sock:/var/run/docker.sock dockerui/dockerui
Greetings,
Hendrik
Bumping the questino from henfri:
Apart from that, I see a problem with the Configuration-Subvolumes:
Curently, I am using the same Subvolume to every Rock-On:
/mnt2/RockOns_config
This is dangerous, as there can be file collisions between different Rock-Ons
Better would be providing -or automatically creating- a Folder or a sub-Subvolume (not sure whether this is possible) within this Subvolume.
E.g. one would specify the Share /mnt2/RockOns_config in the configuration of the Rock-On, but this would automatically create a folder/subvolume
/mnt2/RockOns_config/plex/
The alternative is of course to create subvolume per Rock-On by hand:
/mnt2/RockOns_config_plex
/mnt2/RockOns_config_logitechmediaserver
/mnt2/RockOns_config_btsync
/mnt2/RockOns_config_syncting
But this would be very unstructured and full after a while…
Anyone With idea how to solve this?