Rock-on requests

Hi Roland,
giving you all a spoilers about development :

  • planned to add something like an ā€œinline editorā€ over Rockstor custome scheduled tasks issue
  • planned to add a kind of browser/inline editor for Rock-ons (ex. user contributing new Rock-ons and pushing them directly from Rockstor with git help)

No current plan about ā€œfullā€ file browser, my opinion: if you can edit Rock-ons and custom scripts directly from WebUI, no more browsing/editing required (if you need it you can use nano / vim over System shell)

Open to suggestions :slight_smile:

Mirko

1 Like

Hi,

I want to request a import of the linuxserver.io rutorrent docker image. Is the possible?

https://hub.docker.com/r/linuxserver/rutorrent/

Iā€™m happy to see that the number of available Rock-on programs is steadily increasing, but I think it is also getting to a point to modify/improve the list view itself to get it more user-friendly. Nothing urgent but necessary at least in my eyes :smile:

@glenngould

:wink:

1 Like

FTP Please!, I need FTP! :slight_smile:
I would gladly pay the $40 if I can have FTP and accounts that only work w/FTP directoriesā€¦

I can look into a rockon for this but i would think optimal solution would be to have it part of the rockstor core and configuration in UI.

1 Like

Hi Fredrik,

I agree, this should be part of the core rockstorā€¦I mean, donā€™t get me wrong, a rockon would be ok for now, butā€¦looking at all the competitors, they all support FTP native. I would hate to create users and directories on one placeā€¦just to duplicate the same on a rockon. Seriously, I already reinstalled and removed like 3-4 competitors and keep going back to rockstor, I like it, but the FTP is really holding me back from full deployment.

If FTP is going to be an option it should be part of core. Personally I do everything I can to avoid using FTP and have made devs rewrite their code because FTP is horrendously bad security practice. Itā€™s one thing to risk it on your own LAN but people will port forward this to their routers and use it from outside on public open wifi.

2 Likes

Yeah, I get the part where people will simply read a blog somewhere urging them to open port 21, etcā€¦ From the home NAS front, itā€™ll be nice to have some sort of firewall built in as wellā€¦like synology or even nas4freeā€¦for now, plain FTP locally will suffice for me :wink:

I would suggest including a Rockon that uses Portainer. This is a wicked easy docker GUI run through a web interface and is fairly powerfulā€¦

In fact Iā€™ll do that myself soon.

Hi @luke,

Agreedā€¦ there already is a pending PR for a Portainer Rock-on thanks to @alazare619 :

I personally use it and it works very well.

2 Likes

Excellent, wish Iā€™d spotted that one earlier. Iā€™ve found creating a share with permissions for docker, then using this with portainer and creating bind volumes in that share works a treat. Nice and simple with no mucking about with permissions.

Reviving an old thread here but I have 2 cents worth mentioning if at least for those googling ā€œRockstor Dockerā€ or ā€œRockstor portainerā€ and the likeā€¦

Portainer (or any of the other Docker managers) is an absolute must for anyone with an existing container setup that is looking to move to Rockstor. This is especially so if theyā€™ve already adopted the stack/service model of docker.

Iā€™m still pretty new to docker but I have about 30 containers Iā€™m testing and Iā€™m loving it thus far. Rockstorā€™s ā€œRock-onsā€ honestly put a bad taste in my mouth right off the bat.

I totally get having a click and run solution for those users not interesting in having a complex container configuration but Iā€™d really like to be able to just turn off Rockstorā€™s docker integration and be allowed to completely decouple Rockstor from Docker. That way I can get the latest and greatest and do my own thing (which very well may be possible, Iā€™m only like 2 days into my Rockstor testing :wink:

Not trying to be negative Nancy here as the Rock-ons system is great work. It does add a HUGE feature into Rockstor so many kudoā€™s for that!

Hi @ArmyHill01, and welcome to the community!

Thanks a lot for sharing your experience and feedback, I personally particularly appreciate and welcome it :slightly_smiling_face:.

I agree with you that Portainer is a very useful tool for those with an existing setup and needing complete customization. I myself am using it for this reason :wink: .

My first reaction was: ā€œyes, you can indeed just turn on the Rock-on service (which starts the docker daemon), and then simply set up your own containers whichever way you want (via portainer, for instance)ā€. I then wondered whether you would also mean controlling which docker version you install and with which settings, etcā€¦ This case would, too, be doable, but I canā€™t guarantee what would happen if you attempt to turn on the Rock-on service later on. Indeed, turning on the Rock-on service for the first time set the docker.service configuration with some slight customization to better fit with rockstorā€™s system (and btrfs, mostly). This is the step that might introduce some incompatibility if you were to first install and run your docker version on your own and at a later time decide to turn on the Rock-on service, as your previous configuration may get overridden and the different docker version (if any) may be incompatible with that configuration. Note, however, that this is based on my memory and Iā€™ve never tested that so I actually may be wrong and everything be smooth.

Most importantly, note that Rockstor is in currently transitioning to a rebase onto openSUSE (see updates and rationale in a separate post by @phillxnet and his other posts therein). Under this process, there is a current pull request proposing to simply source the docker.service configuration straight from the docker package itself (and then apply rockstorā€™s settingsā€“including the user defined onesā€“on top of that).
https://github.com/rockstor/rockstor-core/pull/2046#issue-280832979

Iā€™m unsure of exactly which docker version will be shipped, but I believe it will simply provided by upstream directly, so either openSUSE Leap 15.1, or Tumbleweedā€¦ the latter should be the latest and greatest, I believe. @phillxnet, am I correct with that one?

Yes, thatā€™s personally what helped me at first to get acquainted to docker and its ecosystem. I progressively became more familiar with it and started feeling some limitations that the rock-on system had at the time to get a few more ā€œcustomizedā€ configurations. I personally do see a very interesting opportunity to provide an easy way for unfamiliar users to set up more complex containers configurations provided some improvements to the current rock-ons framework. On this topic, there has been quite a bit of work done lately and I personally have an upcoming series of rework to implement docker networking into Rockstor. You can read more on this in the issue below and the links therein if interested:
https://github.com/rockstor/rockstor-core/issues/2009#issuecomment-493048687

For this reason, I am particularly looking forward to hearing more about the following:

Was there something in particular that you would like to see or not to see? As you can probably guess from above, Iā€™m interested in getting as much feedback as I can and getting as many suggestions for improvement as possible, so your experience seems to be very helpful for meā€“pending youā€™d be willing to share the gist of it.

Welcome again to the community!

Thank you for the thorough feedback hoss & the warm welcome!
Iā€™ll jump right into it thenā€¦

This is great news. I still need to review the source now though as to see what config changes you youā€™re referencing that are specifically for BTRFS. I wouldnā€™t think the FS would matter on the app layer but again Iā€™m still new-ish to docker.

Iā€™m tracking a few posts but I didnā€™t find a parent topic ā€˜see here for latest info about RSā€™ but maybe Iā€™m blind. Lots of info on the forum to thumb through for this new guy :wink:

Honestly, as a power user, I donā€™t need RSā€™s layer of abstraction. I have several docker-composeā€™s for my various needs so there is literally no way for me to switch to Rockons.
Beyond that, I guess Iā€™d make the following statements:

For simple users:

  • Provide an ā€˜normalā€™ & ā€˜advancedā€™ container install solution
    • Advanced would allow users to simply paste in docker-compose yaml and BOOM, their off.
    • Normal would be ā€œlikeā€ the current ā€˜click to installā€™ system
  • Allow ability to install container X from repositry/url Y
  • Change the way container shares are done
    • Allow users to select a path, not a share (why force the root of a shareā€¦ makes no sense)
    • I actually have several docker_store_X shares where X corresponds to my various container stacks
    • This allows containers to share any needed data all while allowing me to set custom setting on those various shares (i.e. compression/quotas/etc)
    • Also need the ability to set the access mode on a containers volumes. Example: An image gallery container should have 2 at least 2 volumes: 1 its data dir with r/w access and 2: the media itā€™ll show but iā€™d only want this readonly.

For Power Users:
I started to write a list but really, it was just everything Portainer does. Full stack/swarm support with total control over everything. Iā€™d honestly like to see a setup question in the Rockonā€™s space that asks, ā€œwill you be using your own docker manager?ā€ and if yes, RS disables all docker related stuff and then provides an option for a name and URL of the manager for an ā€˜ease of useā€™ shortcut somewhere in the RS UI.
Beyond that I really donā€™t like the idea of the community having to maintain the yamls needed for Rockons to work.
Why not scaffold all the needed info the run a conatiner in the UI (what image, what repo/url, what ports, what volumes, what networks, what restart policy, etc, etc) and then pass that on to docker?

Iā€™m trying to write this bit in a way as to not come off as a dick but itā€™s not really working out that well. The gist of what I want to say is, I donā€™t really see the value in enhancing the whole Rockon system beyond the super simple click and install model simply because any ā€˜advanced needā€™ can simply be filled with a docker manager like Portainer/ShipYard/Rancher. Iā€™m a dev so anytime I see someone rewrite somethingā€¦ weā€™ll you know how that smellsā€¦
And Portainer is just too easy to use IMO.

Again, I appreciate your feedback & help here!

Hereā€™s the current related code:

Note, however, that we have a pending pull request aiming at simplifying this part as mentioned in my previous post. See here for information:
https://github.com/rockstor/rockstor-core/pull/2046#issue-280832979

The few ā€œRockstorā€ options that are added are as follows:

These mostly included one critical fix to docker-ce disabling quotas in BTRFS, which caused some issues in the past (see rock-ons-root host pool quota disabled by docker-ce. Fixes #1872 by phillxnet Ā· Pull Request #1873 Ā· rockstor/rockstor-core Ā· GitHub). @phillxnet will be able to correct me and bring more details to these if needed.

Mmmmā€¦ for the most ā€œformalizedā€ source of information regarding the latest update on the Rocsktorā€™s changes, I would say we can look at the current release notes for the Stable branch, as well as the Github pull requests. @phillxnet always writes quite the detailed notes so they usually have a lot of information in them.

Thanks a lot for spending the time to write these down :-). I actually agree with pretty much everything you listed. Before I add my 2 cents to it, Iā€™ll point you to a rather old but still information thread in this forum, in which you will find similar conversation and ideas. Also, note that what Iā€™m saying only reflects my personal opinion on things, and explains the recent contributions Iā€™ve had in this part of Rockstor.

I personally see the rock-ons framework as a very nice tool to give quick and easy access to what docker containers can offer without necessarily needing to get familiar with it or even the project(s) they will end up using. As you mentioned, a ā€œmore advanced userā€ can simply run Portainer to run her/his own choice of containers with any setting (s)he wants, use docker run from the cli, or even docker-compose up. None of these should interfere with Rockstorā€™s functions and I personally run several containers like that. From my own experience, I originally wasnā€™t familiar enough with docker to do any of that, but I was still able to run Owncloud and Emby thanks to the existing rock-ons and itā€™s how I see their use. I believe the rock-on framework still has a lot of room for improvement to reasonably expand this simplicity to other areas of the docker ecosystem, butā€“like you saidā€“while trying not to reinvent the wheel. Iā€™m thinking, for instance, about multi-containers rock-ons such as the older owncloud rock-on, which ran its own postgres database in a separate container but from the same owncloud install wizard.

Again, I agree with you on pretty much everything you said :slight_smile:. A few points, though:

I apologize in advance if I completely misunderstood this, but would the ā€œAdd Storageā€ feature fit your need here? The related detailed documentation is in the process of being published, but youā€™ll find a description in the post below. It basically allows to bind the same share to multiple rock-ons in order to make data available to as many rock-ons as desired.

I like this idea very much. I believe the json file defining the rock-on does support the definition of rw or ro (I will need to verify that, however), but I like the idea of being able to customize this on any share post-install.

Thanks again a lot for all your feedback, and I hope I was able to help a little bit.

1 Like

Thanks again for all the detail man. You and phillxnet provide good details and I appreciate it!

Thank you for all the related code. Itā€™s good to see not too much is in the docker_wrapper.py :wink:

That particular thread is closed but I get what youā€™re putting down.

Thatā€™s one thread I missed. Thank you. Iā€™m surprised the thread ended so quickly but ehhhā€¦ it was 2015.
As far as the wizard/helper ideas; thatā€™s actually great. Iā€™m thinking of my wife specifically. If you asked her to pick a pool or shareā€¦ sheā€™ll close the window so I see the target audience better now.

Container Storage
No, weā€™re not on the same page here.
Why force container volumes to be mapped to a particular share? I shutter at the idea of 79 shares on my NAS :sob:
Absolute pathing options would solve this issue for me.Maybe this would be an ā€˜advancedā€™ option but I still donā€™t see the original logic in wanting a share per container. Just seems excessive I guess. Maybe Iā€™m just being anal-retentive.

I really like explicitly stating what the container can do with the data I provide. Some, like Plex, should only read from your media collection while others, say your downloader, naturally need r/w.

Iā€™m still not sold on Btrfs over ZFS so Iā€™m going to be doing some testing on a bare linux OS doing recoveries. I had really hoped to switch to a more linux native FS as BSD is driving me nuts. Either way I have some work ahead of meā€¦ thanks again for all the info.

@ArmyHill01 Just chipping in on:

Yes, I keep that thread locked unless Iā€™m updating it (directly after each release) so as to keep itā€™s content focused on that particular changelog. In the past our ā€˜changelog threadsā€™ have often attracted general discussion on each feature or change as they arrive which can be quite distracting. And any discussion can simply link to the relevant release post anyway so we only gain by keeping it focused.

Hope that helps at least on that bit.

Sorry for the delayed answer; I was convinced we had a similar discussion somewhere to which I wanted to link here, but I couldnā€™t seem to find itā€¦ I finally did, however, so Iā€™ll do that below.

Sorry for misunderstanding you the first time, itā€™s clear to me now. Unfortunately I donā€™t have an answer to it and agree with you that it can become cluttered and annoying if/when the rock-on collection grows substantially.
As to why forcing a particular share, my initial thought was that there may be the advantage of apps and services separation but it is true that it can be become a disadvantage if the number of shares become too large as a result. I then, however, remembered pieces of several discussions we had in this forum and related Github repositories about similar points (this is the link I was looking for above). After re-reading those, my best attempt at an answer would be that it simply hasnā€™t been implemented yet. The Github issue below, although slightly misplaced, addresses this topic and includes several paths to resolving and improving this very point.
https://github.com/rockstor/rockon-registry/issues/95#issue-215116599

As you can see in it, several options were discussed, including:

  1. Alleviating the ā€œburdenā€ of creating a share for each by automating the process during the rock-on install wizard.
    and / or
  2. Implementing the possibility of specifying a path for the users who need / prefer this option.

As you can see in that issue, I do like these options and am hopeful to see if I can implement them next. That wouldnā€™t be very soon as I currently still need to finish a few other things, but that is definitively on my list of things Iā€™d like to address.

I believe there are quite a few users here experienced in both so Iā€™m confident youā€™ll be able to get answers from the community if needed. Good luck with your testing endeavors and enjoy! :wink:

Cheers,

1 Like

@flooiks A very belated welcome to the Rockstor community.

We do support Full Disk LUKS encryption: see our docs section on this:

LUKS Full Disk Encryption

Hope that helps. Thanks for your other ideas here. You might reach more folks if this was not in ā€œRock-on requestsā€ section which was originally intended as requests for whole rock-ons rather than specific requests for particular rock-ons.

Interesting Idea.

We do accept GitHub pull requests if they are tested on our current 3 distro targets; rockstor (CentOS) and openSUSE Leap15 and Tumbleweed. Although our CentOS base is to be deprecated in the future.

Hope that helps.