rockstor / rockon-registry Goto Github PK

The transmission suggested share name is transmission-rockon where as this share is labelled in the GUI at selection time as Data Store which is what it is predominantly, that and the transmission config but this, presumably for ease of config, is not separated out.
I suggest that we change this to transmission-data to avoid the confustion that it stors the rock-on itself ie akin to:-
plex-data
btsync-data
owncloud-data
syncthing-data
note however that the we also have discourse-datastore and jenkins-home however these may be more relevant names to those projects than the generic data label used elsewhere.

This suggestion has been seconded by @Marinerdevil in the following forum post:-
http://forum.rockstor.com/t/transmission-rock-on-installation/965/4
Please update the referenced forum thread with development on this issue.

I am about to prepare a pull request to address this issue.
Note also that a parnter pr will be required to address the docs representation of this change. I will also attempt to get to this shortly as well.

When clicking on the couchpotato 'name' link in the available Rock-ons page there is no external url but a relative one to the installed system, ie on a system named rockcube.lan we get:

https://rockcube.lan/<https://hub.docker.com/r/linuxserver/couchpotato></a>

The same issue exists with the sonar rock-on:

https://rockcube.lan/<https://hub.docker.com/r/linuxserver/sonarr></a>

Pull Requests should automatically be tested to at least contain valid JSON, and could perhaps be validated against a JSON-Schema to ensure they conform to the expected format.

Initial discussion at #81 (comment)

CC @magicalyak @phillxnet @schakrava

Additional information can be seen on the forums:

https://forum.rockstor.com/t/teamspeak-rock-on-dead/5282

https://forum.rockstor.com/t/spideroak-rockon/1136

I can likely do this but wanted it tracked here. SpiderOak is used to sync and backup files and can run in headless mode, making it ideal for use on RockStor. I know a lot of people use it at work so this is just a request for it to be added.

I think adding license informations to the rockon-registry repository would be usefull. This thread suggests the GNU AGPL V3.

Can someone update the dropbox.json to say:

"more_info": "After installed visit /var/log/messages and look for a line similar to 'DATETIME HOSTNAME journal: Please visit https://www.dropbox.com/cli_link_nonce?nonce=CODE to link this device.'",

Instead of:

"more_info": "After installed visit /var/logs/messages and look for a line similar to 'DATETIME HOSTNAME journal: Please visit https://www.dropbox.com/cli_link_nonce?nonce=CODE to link this device.'",

Right now browsing the Catalog of Rockons is very sparse. I don't know the source of the Rockon (whose Plex comtainer is that) without looking in Github at the contents of the .json. I don't know the version number, or last update version - these are important :)

BareOS is a fully AGPLv3 fork of bacula, please see the related discussion for a bacula rockon in issue #93
Copying my comments from that issue in here:
"I'm rather favouring we adopt @pauldsmyth move and consider Bareos given they have a far more current binary download for a bunch of linux distros and win.

Also from their web page:

"Bareos is a 100% open source fork of the backup project from bacula.org. The fork is in development since late 2010, it has a lot of new features.
The source has been published on github, licensed AGPLv3."

"Backup Archiving Recovery Open Sourced"
https://github.com/bareos/

see also:
https://www.bareos.org/en/
https://www.bareos.org/en/download.html

Plus there are up to date (by major version number) BareOS (16.2) docker images for all components with excellent (rather than no) documentation by barcus on dockerhub:

https://hub.docker.com/u/barcus/

On the grounds that bacula would in comparison appear almost abandoned from the client binary point of view and has very few docker image optins I'm changing this Issue to BareOS from Bacula"

If anyone has a working knowledge of BareOS please feel free to contribute to this issue.

After purchasing several IP cameras and running Synology's Surveillance Add-on, I'd like to bring some sort of IP Camera DVR to Rockstor. Zoneminder is a free and open source solution for this. I'll see what I can write up, pending a successful Rockstor install.

Bacula is a well respected highly developed client server network backup system. Running a server (Director service + Storage Daemon) instance as a Rockon would add value to Rockstor. Client software is available for all major platforms and the project has now been running for 17 years. Although tape archive facilities were it's original remit it now equally supports file archives via pools of backup volumes where the pool defines it's volume members characteristics.
Main page:
http://blog.bacula.org/
Git repo:
http://www.bacula.org/git/
Licence appears to be AGPLv3: http://blog.bacula.org/what-is-bacula/bacula-copyright-trademark-and-licenses/
Manuals: http://blog.bacula.org/documentation/documentation/

Configuration can be achieved via the Baculum Web GUI Tool (Bacula version >= 7.0):
http://www.bacula.org/7.4.x-manuals/en/console/Baculum_Web_GUI_Tool.html
screen shots:
http://www.bacula.org/7.4.x-manuals/en/console/Baculum_Web_GUI_Tool.html#SECTION00370000000000000000
or via console access via bconsole.

Their is utility in separate Director and Storage Daemon Rockons, however it might also be nice to have a 'one stop shop' for the server components to aid ease of setup. Leaving only client software install to complete a full network backup solution. This would then serving both ends of the scale for such things.

I propose the following Rockons:

Bacula Storage Daemon (bare bones for use with existing Bacula setups)
Bacula AIO (Director + Storage + Catalog (PostgreSQL based))

Bacula components:
http://www.bacula.org/7.4.x-manuals/en/main/What_is_Bacula.html#SECTION00220000000000000000

From a quick look on https://hub.docker.com/ I don't see any well documented and maintained examples, however there is:
https://github.com/RedCoolBeans/docker-bacula-opensource
where each element is defined in a separate docker image and we could in turn build our Rockon using these images akin to our existing owncloud and rocketchat Rockons. But these images are now 10 month old with 6 releases since then.

Ready for comment / advise as my own familiarity with Bacula is rather ancient, ending around 2010 when I last recommended it in a commissioned configuration proposal.

I will continue to create/update JSONS, but I have trouble testing them due to some error where JSONS are not loaded into Rock-ons menu.
Please have a look

Also on the forum
https://forum.rockstor.com/t/rockons-metastore-jsons-missing/1298

Hi,

I was looking to add my own rockon.

But when I create /opt/rockstor/rockons-metastore directory my box hangs on next reboot. The boot process does never finish. There are no information on screen.

It does not matter, if the created directory is empty or if there is a json in it.

I tried this with last stable (3.8-11) and also with testing updates. Both with the same result.

Regards

Hi - I have submitted the below PR for adding Nextcloud Rockon. Looking at the list and date of all the PRs, I am questioning if this is actively reviewed.

Is there anything I can do to help with my PR? Anything I can do to contribute PR reviews to this community?

I love Rockstor and I think these Rockons help expand the functionality.

#145

Was just wondering what the policy is for rockons updating themselves or having auto-updating features enabled by default. I was made aware that on a vanilla linux server this is frowned upon, but was wondering if rockstor would have any issues at all with auto-updating rockons. Basically should rockons update themselves or should they rely on new docker packages being released (many of which are auto generated themselves)

For reference this issue came up when examining defaults of Sonarr, Headphones (auto update enabled) vs defaults in Radarr (auto updates disabled by default, pending pull request to add to registry)

https://github.com/rockstor/rockon-registry/blob/master/cops.json#L21

^ Here we're setting up for books at the /movies path. COPS configuration in the image is looking for books at the /books path. This blocks COPS from running properly.

Recommend updating the line to /books instead of /movies. I'm unable to try it / create a pull from my current environment.

Hi,

I'm building a minio (http://minio.io) rockon, but the minio image requires a command and a argument in the docker run invocation (server /export).

But I didn't see a place to put this info on rockon json file.

BTW, I fixed by editing the container config.json and adjusting the Arg and Cmd parameters. After restarting the rockon service, everything is running fine.

The free plan of circleci should enable a post pr submission json lint check to validate, at least syntactically, each pr and provide in place feedback on this check within the pr itself. This would form the first step in reviewing a pull request and avoid admins having to correct basic errors that are easily made / rectified prior to human review.

Our current pi-hole Rock-on uses the now outdated diginc/pi-hole image.

As per quote from: https://hub.docker.com/r/diginc/pi-hole/ (updated 6 month ago)
"We've moved! To get the latest updated Pi-hole v4.0 please use pihole/pihole:"
we should move to using the new updated image / location.
https://hub.docker.com/r/pihole/pihole/ (updated 2 days ago)

An alternative for couchpotato exists called watcher. there is already a docker image.

https://hub.docker.com/r/williambroown/watcherdocker/

I try to add the mounted /media/music folder too the Library. The Error says the folder is not in the data-system. I checked the id/gid of the folder and used the right ids on install so thats not the problem.

bittorrent/sync docker image has been deprecated and replaced by resilio/sync
https://hub.docker.com/r/resilio/sync/

Deprecated image stops at version 2.3.8 which causes licences issues if all your other peers are on 2.4 using latest Resilio licence model.

Can we expect an upgrade soon? Does changing the Rockon's name and image will cause upgrade problems?

Thanks

Upstream has two volumes, one for config, one for logs. Could we get prompted for the logs volume too?

Hi,

If anyone else have crashplan pro account, can you test: https://gist.github.com/wiza/bb0a9c76356315422530eae6d63139d5

Uses docker from https://hub.docker.com/r/jlesage/crashplan-pro/ (not mine)

We currently have a number of missing root.json entries which results in a Web-UI 'no show' for otherwise merged rock-on json files.

Synchronise root.json content with current Rock-on json definition files.

Greetings!

I'm a sysadmin who uses Docker often and I would like to create my own Rock-ons or at least run my own containers. Without hacking the core code, is there/will there be configs to set our own docker repos or use the Docker Hub for images?

Hey all, I'm getting an error when i attempt to install the subsonic rockon. I get a message about it being unable to find the docker image even after updating.

The phesley docker-dns-rest gives a container with a rest API to automatically build DNS for the docker containers. This would be useful for configuring other docker containers with host names, instead of by IP or manually keeping a primary DNS for the zone.

https://github.com/phensley/docker-dns-rest

While trying to translate the docker command to the needed Rockon json.

docker run -d -p 5080:80 -v /var/run/docker.sock:/docker.sock --name dns \
    phensley/docker-dns-rest --verbose 

The following JSON is what I've come up with. And when I just run the above docker command the container starts up just fine. Although, when I install it with the JSON below as a Rockon the container just continually restarts.

{
  "Phensley docker-dns-rest": {
    "description": "Container DNS rest API",
    "version": "0.1",
    "website": "https://github.com/phensley/docker-dns-rest",
    "containers": {
      "DNS_Rest_API": {
        "image": "phensley/docker-dns-rest",
        "tag": "latest",
        "launch_order": 1,
        "ports": {
          "80": {
            "description": "The port used for the rest API DNS managment",
            "host_default": 2053,
            "label": "Rest API",
            "protocol": "tcp",
            "ui": false
          }
        },
        "opts": [
          ["--net", "host"],
          ["-v", "/var/run/docker.sock:/docker.sock"]
        ]
      }
    }
  }
}

2017-11-10T21:23:57.751613000Z Traceback (most recent call last):
2017-11-10T21:23:57.752015000Z   File "/data/docker_dnsrest", line 106, in <module>
2017-11-10T21:23:57.752479000Z     main()
2017-11-10T21:23:57.752678000Z   File "/data/docker_dnsrest", line 95, in main
2017-11-10T21:23:57.752869000Z     api.start()
2017-11-10T21:23:57.753057000Z   File "/usr/lib/python2.7/site-packages/gevent/baseserver.py", line 234, in start
2017-11-10T21:23:57.753249000Z     self.init_socket()
2017-11-10T21:23:57.753461000Z   File "/usr/lib/python2.7/site-packages/gevent/pywsgi.py", line 639, in init_socket
2017-11-10T21:23:57.753648000Z     StreamServer.init_socket(self)
2017-11-10T21:23:57.753835000Z   File "/usr/lib/python2.7/site-packages/gevent/server.py", line 78, in init_socket
2017-11-10T21:23:57.754025000Z     self.socket = self.get_listener(self.address, self.backlog, self.family)
2017-11-10T21:23:57.754216000Z   File "/usr/lib/python2.7/site-packages/gevent/server.py", line 89, in get_listener
2017-11-10T21:23:57.754410000Z     return _tcp_listener(address, backlog=backlog, reuse_addr=self.reuse_addr, family=family)
2017-11-10T21:23:57.754598000Z   File "/usr/lib/python2.7/site-packages/gevent/server.py", line 153, in _tcp_listener
2017-11-10T21:23:57.754783000Z     sock.bind(address)
2017-11-10T21:23:57.754971000Z   File "<string>", line 1, in bind
2017-11-10T21:23:57.755158000Z socket.error: [Errno 98] Address in use: ('0.0.0.0', 80)

When clicking on the names of Rock-ons I think it should link to the upstream project, not the docker maintainers page. This way users will get to see what they are to install not the details of the packager / docker container.
However it would also be nice to acknowledge the origin of the docker container so I propose to normalize this info by having the subtitle of each Rock-on name via a "by" entry the docker maintainer. This is already done in for example the current Plex Rock-on but in that same case we don't link to the Plex site via the name.
Summary:
Names link to upstream projects ie as with Syncthing currently.
subtitles (below names) identify that the system is "Continous File Synchronization" but optionally adds "docker image by ......". This way we cover both options where the more technical can search for the docker maintainer but the general title link serves the initial upstream link to the main project.

I just came across a project that seems like a very good candidate for Rockstor:
Nginx Proxy Manager: https://nginxproxymanager.jc21.com

As per its Github page:

This project comes as a pre-built docker image that enables you to easily forward to your websites running at home or otherwise, including free SSL, without having to know too much about Nginx or Letsencrypt.

https://github.com/jc21/nginx-proxy-manager

This seems to provide a user-friendly web-interface to creating and managing Nginx to easily reverse-proxy apps on a server with easy SSL-setup (built-in Let's Encrypt, or own SSL).
The project seems relatively active.

I'm opening this issue to remind me of having a better look at it and see if a Rock-on can easily be made for it.
Does anyone have experience and feedback on this project?

I just unsuccessfully tried to install the BTSync rock-on. Repeatedly.

In supervisord_ztask-daemon_stderr.log I found this:

ERROR:storageadmin.views.rockon_helpers:Error running a command. cmd = ['/usr/bin/docker', 'run', '--log-driver=syslog', '-d', '--restart=unless-stopped', '--name', 'btsync', '-v', '/mnt2/sync:/data', '-p', '8888:8888/tcp', '-p', '3369:3369/tcp', '-p', '3369:3369/udp', 'aostanin/btsync']. rc = 1. stdout = ['']. stderr = ["Unable to find image 'aostanin/btsync:latest' locally", 'Pulling repository docker.io/aostanin/btsync', 'Error: image aostanin/btsync:latest not found', '']
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py", line 125, in install
    globals().get('%s_install' % rockon.name.lower(), generic_install)(rockon)

And so on. The btsync image can't be located on the Docker hub. Indeed, on aostanin's repository there is no longer a btsync image. Has he pulled it? If so, we'll need an alternative - and perhaps rethink Rockstor's dependency on third parties who might pull their images at the drop of a hat.

Which is not a quibble. Thanks for the great job you're doing, guys.

While testing this repository via client reconfiguration to retrieve directly from GitHub prior to production deployment we appear to have a no show in Web-UI of the recently merged NetData Rock-on.
However it does appear in the root.json via:
https://raw.githubusercontent.com/rockstor/rockon-registry/master/root.json

...
    "Netdata": "netdata.json",
...

and it's relevant file netdata.json is also retrievable via it's raw link:

https://raw.githubusercontent.com/rockstor/rockon-registry/master/netdata.json

Our current Jenkins Rock-on uses the now deprecated jenkins image.

As per quote from: https://hub.docker.com/_/jenkins (last updated 7 months ago).
"This image has been deprecated in favor of the jenkins/jenkins:lts image provided and maintained by Jenkins Community as part of project's release process. The images found here will receive no further updates after LTS 2.60.x. Please adjust your usage accordingly."

Last version as of writing 2.60.3 (2017-08-17) see below LTS changelog.

LTS variant's changelog: https://jenkins.io/changelog-stable/

See the following link for the proposed new image:
https://hub.docker.com/r/jenkins/jenkins (last updated hours ago)
Latest LTS version noted as 2.150.2 (2019-01-16) 19 LTS releases on from 2.60.3

Note that various versions (tags) of this image are available, most notably.

jenkins/jenkins:lts Proposed for our Rock-on edit.
jenkins/jenkins Defaults to the 'latest' (tag) weekly.

Multiple other tags are available:
https://hub.docker.com/r/jenkins/jenkins/tags

It is proposed that we adopt the 'lts' tag for our existing Rock-on update as this is in line with it's current image.

rednoah has created a node server app for filebot and packaged it in a docker container here: https://hub.docker.com/r/rednoah/filebot/

The filebot Node Service is here: https://github.com/filebot/filebot-node

and the How to is here: https://www.filebot.net/forums/viewtopic.php?f=13&t=2733 (It's pretty basic)

But I figured it would be a good addition to a media server.

I'm not the most versed in git but I did create a rockon for watcher a competitor to couchpotato. Its under active development and seems alot more lightweight. Would be glad to see it added.

https://gist.github.com/alazare619/dd5e52eb29cb6119385cef760fa1e788

Hi,

The logitech squeezebox docker image is now pointing at an old version (and technically its been renamed to logitech media manager too). Is it ok to simply update the rock on to point at another image on docker hub? For what its worth the most popular image works with something similar to:

{
    "Logitech Media Server": {
        "containers": {
            "logitech-media-server": {
                "image": "larsks/logitech-media-server",
                "launch_order": 1,
                "ports": {
                    "9000": {
                        "description": "Webserver Port. Suggested default: 9000.",
                        "host_default": 9000,
                        "label": "Webserver port",
                        "protocol": "tcp",
                        "ui": true
                    },
                    "9090": {
                        "description": "CLI Port. Suggested default: 9090.",
                        "host_default": 9090,
                        "label": "CLI port",
                        "protocol": "tcp"
                    },
                    "3483": {
                        "description": "SlimProto Port. Suggested default: 3483.",
                        "host_default": 3483,
                        "label": "Slimproto port"
                    }
                },
                "volumes": {
                    "/srv/music": {
                        "description": "Select the Share containing your Media",
                        "label": "Logitech media server data storage",
                        "min_size": 1073741824
                    },
                    "/srv/squeezebox": {
                        "description": "Select the Share to store your library",
                        "label": "Logitech media server config storage",
                        "min_size": 1073741824
                    }
                }
            }
        },
        "description": "Server for Squeezebox Devices",
        "ui": {
            "slug": ""
        },
        "volume_add_support": true,
        "website": "http://mysqueezebox.com",
        "version": "1.0"
    }
}

Thanks to @fago for bringing to light the recent change in discovery port for upstream syncthing as per version v0.12 onwards from 21025 to 21027.
https://docs.syncthing.net/users/firewall.html#local-firewall
and
syncthing/syncthing#2685 (comment)

@fago has an outstanding pull request on the docker image that Rockstor's Syncthing Rock-on uses (istepanov/syncthing) :
istepanov/docker-syncthing#3
The Rock-on mapping in syncthing.json should be updated to coincide with that change.

Forum member noorbertt has requested the addition of a Seafile Rock-on. Creating this issue to note this request. Please update the following forum thread with this issues resolution:

https://forum.rockstor.com/t/update-the-docker-list/5898

A quick search would suggest that Seafile has for some time been available in a docker image:
https://forum.seafile.com/t/new-seafile-docker-is-ready/5856
(Apr 2018)
which in turn links to the following GitHub repo:
https://github.com/haiwen/seafile-docker
which looks to be active but it is not currently clear which dockerhub image is the official one, or if an official docker hub image even exists.

There doesn't yet appear to be an official one:
nextcloud/server#145
But we could use greyltc's
https://github.com/greyltc/docker-nextcloud
which is tagged (defaults to latest = latest stable release):
https://help.nextcloud.com/t/docker-image-available/351/19
Note that config, apps, data, sslcert volume maping setting could be taken from: @nrgeen 's suggestion in the following issue on GitHub for this docker container:
greyltc/docker-nextcloud#4

-v /volume/nextcloud_docker/config:/usr/share/webapps/nextcloud/config
-v /volume/nextcloud/apps:/usr/share/webapps/nextcloud/apps
-v /volume/nextcloud/data:/usr/share/webapps/nextcloud/data
-v /volume/nextcloud/sslCert:/root/sslKeys

Please allow me to define shares at point of deployment during the install UI - the ability to specify a path relative to an existing share (eg /rockonshare/config/plex/) would make the deployment flow way less clunky.

Hi,

I have installed an running the plex rockon.
After, ich have created the /opt/rockstor/rockons-metastor and put the crashplan json in it.
Now, when I press Update on the rockons page, I geht the following error message:

Error!

Errors occurred while processing updates for following Rock-ons. Plex: Cannot add/remove volume definitions of the container(plex) as it belongs to an installed Rock-on(Plex). Uninstall it first and try again.

The existing image used discourse/discourse is now superseded, and presumably deprecated by: discourse/base. However given the additional 'special treatment' this newer docker image requires a companion issue has been opened in rockstor-core. This companion issue, linked below, is a dependency of this issue and so would need to be completed prior to this issue receiving attention.

Further input on this and the below linked rockstor-core issue is welcome, as always, as this issues author only has passing familiarity with discourse setup.

Associated dependency in rockstor-core:
rockstor/rockstor-core#2033

Duplicati fails to install on a fresh install of rockstor..I'll attempt to get logs.

This is particularly noticeable with plex. The config wipes on any add volume action. Is this an intended action or something that is able to be stopped?

The symform.json Rock-on is in rockon-registry but there is no accompanying entry for the same in root.json. Adding under this issue to restore consistency.

When installing zoneminder rock-on the user is asked to provide "Config Storage" but the tooltip more accurately portrays this as data and config storage. Would be nicer to have:
"Config Storage"
label changed to
"Data and Config Storage"
Minor but worth doing for first time interpretation.

Emby server recently released all its versions on DotNet and thus changed its docker image substantially. While the current Json Rock-on still works, updating it would bring a few new features.
https://hub.docker.com/r/emby/embyserver/

I'll try to spend time on this and am creating this issue to remind me and keep track it it.

can you make an addon for UNMS its an addition to Unifi controller

Ubiquiti Network Management System (beta)
Manage all of your EdgeMAX®, EdgeSwitch®, airMAX® and UFiber devices.

Centralized devices configuration, backups and mass FW upgrade
Performance charts with real-time graphs
Outage notifications and custom alerts
Map of your network sites and endpoints
https://github.com/Ubiquiti-App/UNMS

@schakrava appears ombi is not in the list. I've hit update a few times to no luck. Removed the Rockon-Root-Share still no bueno. Had a few others verify this too. No luck Ombi still isn't propagating.

From http://symform.com/:

It has been a blast, but all good things must come to an end.

We started the Symform service in 2009 with the idea of creating the worlds largest cloud storage without the data centers. We reached an amazing point in which we were managing petabytes of storage and billions of data objects across 170 countries. Symform was eventually acquired and became part of the team at Quantum. Unfortunately as of July 31, 2016 Symform has shut down operations and will no longer be available for use. From the bottom of our hearts, we want to thank all of you for your support and belief in what Symform accomplished.

Not sure what Symform was, but apparently it is no more.