hosted registry for Rock-ons
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
FreshRSS.json permissions fixes May 29, 2017
Jackett.json permissions fixes May 29, 2017
LogitechSqueezebox.json permissions fixes May 29, 2017
Muximux.json permissions fixes May 29, 2017
NZBHydra.json permissions fixes May 29, 2017
README.md Fixed typo Jun 26, 2017
bitcoind.json Add bitcoind rockon Mar 4, 2017
booksonic.json add booksonic rockon Sep 29, 2017
btsync.json permissions fixes May 29, 2017
collabora-online.json permissions fixes May 29, 2017
cops.json permissions fixes May 29, 2017
couchpotato.json permissions fixes May 29, 2017
crashplan.json permissions fixes May 29, 2017
deluge.json permissions fixes May 29, 2017
discourse.json permissions fixes May 29, 2017
dropbox.json Updates to description for Skip_update environ var Jun 12, 2017
duplicati2-canary.json permissions fixes May 29, 2017
ecodms.json permissions fixes May 29, 2017
embyserver.json permissions fixes May 29, 2017
ghost.json permissions fixes May 29, 2017
gitlab-rc.json permissions fixes May 29, 2017
gogs.json permissions fixes May 29, 2017
haproxy-letsencrypt.json permissions fixes May 29, 2017
headphones.json permissions fixes May 29, 2017
home-assistant.json permissions fixes May 29, 2017
jenkins.json permissions fixes May 29, 2017
lazylibrarian.json permissions fixes May 29, 2017
mariadb.json permissions fixes May 29, 2017
mylar.json permissions fixes May 29, 2017
nzbget.json permissions fixes May 29, 2017
ombi.json permissions fixes May 29, 2017
openvpn.json permissions fixes May 29, 2017
owncloud-official.json permissions fixes May 29, 2017
owncloud.json permissions fixes May 29, 2017
owncloudHTTPS.json permissions fixes May 29, 2017
pi-hole.json Update pi-hole.json May 10, 2017
plex.json permissions fixes May 29, 2017
plexpy.json permissions fixes May 29, 2017
radarr.json corrected radarr and added dropbox to root Jun 16, 2017
redirect-http-to-https.json permissions fixes May 29, 2017
resilioSync.json add resilio sync rock-on Jul 18, 2017
rocketchat.json permissions fixes May 29, 2017
root.json Add Transmission with OpenVPN Rock-on. Oct 28, 2017
sabnzb.json permissions fixes May 29, 2017
sickbeard.json permissions fixes May 29, 2017
sickrage.json permissions fixes May 29, 2017
sonarr.json permissions fixes May 29, 2017
subsonic.json permissions fixes May 29, 2017
syncthing.json moved syncthing to linuxserver version Sep 14, 2017
teamspeak3.json permissions fixes May 29, 2017
tftpserver.json Add tftpserver Aug 22, 2017
transmission-with-openvpn.json Remove default values that don't work anyway. Oct 28, 2017
transmission.json permissions fixes May 29, 2017
uTorrent.json permissions fixes May 29, 2017
unifi.json Fix STUN port protocol Nov 7, 2017
xeoma.json Add Xeoma Video Surveillance Rockon Oct 16, 2017
youtrack.json newline at end of file Jul 25, 2017
zabbix-xxl.json fixed localtime issue Oct 2, 2017
zoneminder-1.30.json permissions fixes May 29, 2017
zoneminder.json permissions fixes May 29, 2017

README.md

rockon-registry

This repository consists of Rock-on(Docker based apps) configuration profiles formatted in JSON files. The Rock-On framework of Rockstor parses a well formatted profiles and provides a generic management and workflow such as install, uninstall, update, start and stop.

Can you show me an example?

Look at any .json file in this repository. A simpler example is syncthing.json. The structure is intuitive(though cumbersome) and with the help of examples and below description, you can add your own apps with some effort.

How can I add my own app?

If you are familiar with Docker and know how to run apps by hand, you can create a Rock-on for the same with a little bit of craft. There are three broad steps.

  1. Configure the Rock-On service on your Rockstor system. Follow this doc.

  2. Create your Rock-on profile file, [app].json following the clues in this readme.

  3. Upload the file to /opt/rockstor/rockons-metastore/[app].json. Hit update in the Web-UI and install your brand new Rock-On!

If you like to share your app with rest of the Rockstor community, open a pull request in this repository. Please follow these guidelines when opening a pull request.

  1. One Rock-On per pull request please. If you are working on multiple apps, separate them out. It will make testing and merging a lot more manageable.

  2. Add a comment to your pull request detailing how you've tested it out. More details the better as it will help ensure quality and benefit the whole community!

One time setup before opening pull requests.

Go to rockon-registry repo and click on the Fork button. This will fork the repository into your profile which serves as your private git remote called origin. The next few git steps are demonstrated on a Linux terminal.

Create a local clone of your fork.

git clone git@github.com:your_github_username/rockon-registry.git

Configure this new git repo with your name and email address. This is required to accurately record collaboration.

cd rockon-registry
git config user.name "Firstname Lastname"
git config user.email your_email_address

Add a remote called upstream to periodically rebase your local repository with changes in the upstream made by other contributors.

git remote add upstream https://github.com/rockstor/rockon-registry.git

Above 4 steps help you setup your local environment. If you are familiar with git and use an IDE like Eclipse, you can achieve the same outcome in a different way. Here, we listed the simple terminal way of setting it up.

Steps to Contribute a Rock-on with a pull request

Rebase your master branch before making your own changes.

cd rockon-registry
git checkout master
git pull --rebase upstream master

Checkout a new/separate branch for your Rock-on

git checkout -b rockon_name

Add and commit your rockon to git. Say you are working on Syncthing Rock-on and have the syncthing.json tested and ready to go. First copy the file over to your repo. Next,

git add syncthing.json
git commit -m 'add synctthing rock-on'

Push your rockon to github. <branch_name> is from two steps ago.

git push origin <branch_name>

Now go to github and open a pull request. Thanks!

What is the structure of a Rock-On profile file?

it's a big mass of JSON with nested objects, arrays and values.

Top level structure

{
    "<Rock-On name. eg: LSIO-Plex>": {
      "description": "<description of the Rock-On. Eg: Plex brought to you by Linuxserver.io>",
      "version": "<arbitrary version string>",
      "website": "<Underlying app website>",
      (optional)"icon": "<link to icon, if any>",
      (optional)"more_info": "<string or html with more information to display to the user in the Rockstor UI>",
      (optional)"ui":{
                "slug":"gui", link to webui becomes ROCKSTOR_IP:PORT/gui with slug value gui
      },
      (optional)"volume_add_support": true, If the app allows arbitrary Shares to be mapped to the main container>,
      "containers": {
        "<container1 name>": <container object representing the main container. see below>,
        "<container2 name>": <container object representing the second container, if any. see below>, ...
      },
      (optional)"custom_config": <custom configuration object that a special install handler of this Rock-on expects>
    }
}

Structure of a container object

Each container object is key'd by it's name and nested within "containers" of the top level structure above. A typical container object has the following structure

{
  "image": "<docker image. eg: linuxserver/plex>",
  (optional)"tag": "tag of the docker image, if any. latest is used by default.>",
  "launch_order": "1 or above. If there are multiple containers and they must be started in order, specify here.>",
  (optional)"ports": {
    "<container side port number1>": <port object represending a port mapping between host and container. see below>,
    "<port number2>": <another port object, if necessary. see below>, ...
  },
  (optional)"volumes": {
    "<path1 inside container>": <volume object representing a Share<->directory mapping in the container. see below>,
    "<path2 inside container>": <another volume object, if necessary. see below>, ...
  },
  (optional)"opts": [ An array of option objects that represent container options such as --net=host etc.. see below],
  (optional)"environment": {
    "<env var1 name>": <env object representing one environment variable required by this container. see below>,
    "<env var2 name>": <another env object, if necessary. see below>, ...
  }
}

As it is evident from above, a container object has nested objects for port and volume mappings, container options and environment variables. These are described below.

Port object

{
  "description": "<A detailed description of this port mapping, why it's for etc..>",
  "label": "<A short label for this mapping. eg: Web-UI port>",
  "host_default": <integer: suggested port number on the host. eg: 8080>,
  (optional)"protocol": "<tcp or udp>",
  (optional)"ui":true,  not needed if false
}

Note that protocol is optional and if it's not present, both tcp and udp ports are mapped simultaneously. So if you wish to allow both tcp and udp, just don't specify protocol in the Port object.

Volume object

{
  "description": "<A detailed description. Eg: This is where all incoming syncthing data will be stored>",
  "label": "<A short label. eg: Data Storage>",
  (optional)"min_size": <integer: suggested minimum size of the Share, in KB>
}

Options object

An options object is a list of exactly two elements. (This needs to be improved or deprecated in favor of more specific design.)

--net=host would be represented as:

["--net", "host"]

Note that the opts field is a 2-d array, so the complete line for the above example looks like

"opts": [ ["--net", "host"] ],

Environment object

{
  "description": "<Detailed description. Eg: Login username for Syncthing UI>",
  "label": "Web-UI username",
  (optional)"index": <integer: 1 or above. order of this environment variable, if relevant>
}