Install Plugins in Discourse

plugins

(Joe Buhlig) #143

I know I mentioned that I’ve been using the token method for installing private plugins, but when building plugins for clients I’ve learned that I don’t want to use a token from my own GitHub account. The client would then have access to all the repos I have access to.

An alternative has been to set up a machine user and grant that user a token that can be used once the machine user is made a collaborator on the private repo. But I don’t really feel like paying for an extra collaborator seat for each machine user.

I still use tokens on demo servers, but for production scenarios, I went back to the original way of installing private plugins. I did run into issues with the original instructions. What eventually worked for me was the following:

## Remember, this is YAML syntax - you can only have one block with a name
run:
  - exec: echo "Beginning of custom commands"

  - exec: cd /var/www/discourse && sudo -u discourse bundle install --deployment --without test --without development
  - exec: mkdir /root/.ssh
  - exec: chmod 700 /root/.ssh
  - exec: echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config
  - file:
      path: /root/.ssh/id_rsa
      chmod: 600
      contents: |
        -----BEGIN RSA PRIVATE KEY-----
        -----your private key string-----
        -----END RSA PRIVATE KEY-----
  - file:
      path: /root/.ssh/id_rsa.pub
      chmod: 600
      contents: ssh-rsa ---your long string--- user@discourse
  - exec: cd $home/plugins && git clone git@github.com:USERNAME/REPO-NAME.git
  - exec: cd $home && sudo -E -u discourse bundle exec rake db:migrate
  - exec: cd $home && rm -fr tmp/cache
  - exec: cd $home &&  sudo -E -u discourse bundle exec rake assets:precompile
  - exec: rm /root/.ssh/id_rsa
  - exec: rm /root/.ssh/id_rsa.pub
  - exec: chmod 600 /root/.ssh

  - exec: echo "End of custom commands"

(Jay Pfaffman) #144

But aren’t you now giving them your ssh key, which still gives them access?


(Joe Buhlig) #145

I’m generating a key specific to that scenario and adding the public key as a deploy key on the repo. So it’s not the SSH key of my machine.


#146

I have installed a couple plugins and now want to add another. Do I remove the already installed ones from the app.yml of just add the new ones at the bottom?


(Matt Palmer) #147

Unless you want to uninstall the other plugins, you want to keep them in your app.yml.


#148

Good to know, thank you!


(Angus McLeod) #149

The downside of using deploy keys to install a private plugin via custom commands is that you can’t upgrade the plugin via /admin/upgrade.

@mpalmer How hard would it be to allow for plugins installed via custom commands to be “upgradeable” via /admin/upgrade?


(Matt Palmer) #150

Very difficult. Give it a shot if you like, but it’s a tricky problem. The best option is to switch to using oauth tokens (with all the security/cost tradeoffs that GitHub’s scopes inflicts).


(Jordan) #151

@molly_cushing, Your post was exactly what I needed! Thanks for putting this together.

I personally learn the best by watching someone do something so I created a video tutorial following the steps you outlined, for anyone who’d like to see the process in action:


(Sivert) #152

I’m beginer in Discourse, and after cloned Disourse repository, can’t find container/app.yml fie.
Do I have to create new one?
And also the command “./launcher rebuild app” isn’t working cause there isn’t such file or directory named “launcher” in the project


#153

Sounds like you didn’t fully installed Discourse, you need to follow all these commands : discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub

After that, and only after, you can run these commands to install a plugin. You need to be in the discourse folder :
cd /var/discourse

After that, you can open the app file using nano
nano containers/app.yml

And still in the /var/discourse folder, you can run the command to complete the install (this command will take a few minutes)
./launcher rebuild app


(Stephen) #155

There’s actually no need to sudo -s when updating your app.yml, a simple sudo nano containers/app.yml from within /var/discourse will suffice.

The ‘git pull’ is redundant here too.

@sivert If you ran discourse-setup as outlined in the official install guide an app.yml would be created for you at /var/discourse/containers/ with all the necessary settings to get Discourse running. Have you already done this? If so you need to move to /var/discourse before issuing the commands you mentioned above, a simple cd /var/discourse will suffice.

as … means ‘up a level’ it’s very rarely going to be the right way to get there.


(Sivert) #159

@Stephen Thanks for your answer. It seems I was confused between dev and pub versions.
Just now I was working on developing version in my MacOS system.
Can I continue follow this guid to test my plugins on developing version or is this thread for only production version and I have to find another way?


(Sivert) #160

I just have followed this tutorial and can’t find any “container” directory or “./launcher” for rebuild command.
Please help me what am I wrong and how can I add plugin this development version.


(Jay Pfaffman) #161

Did you do this? discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub


(Sivert) #162

Why cloud? Is it impossible to work with plugin on local development server?


(Rafael dos Santos Silva) #163

For local you just need to clone the plugin you want under the /plugins directory and restart the web server.


(Angus McLeod) #164

Just circling back on the best way to handle the deployment of multiple private plugins (particularly if you do work for multiple clients), the way I handle this now is:

  1. Create a github “Machine User” for the client.
  1. Add the machine user as a collaborator to the private repo hosted in my Github account. This is a free (unpaid) Github account. Free accounts can be collaborators on private repos.

  2. Create a personal access token for the machine user.

  3. Use the machine user’s personal access token to install the plugin on the client’s server.

This approach:

  • Allows the plugin to be updated via /admin/upgrade
  • Does not cost anything extra
  • Does not expose all private repositories in your account to each client.

Note that Github seems supportive of this kind of use of their account system, see here:

Tip: Our terms of service state:

Accounts registered by “bots” or other automated methods are not permitted.

This means that you cannot automate the creation of accounts. But if you want to create a single machine user for automating tasks such as deploy scripts in your project or organization, that is totally cool.


(Michael Brown) #167

You can create deploy keys on repositories - that would be much less work.


(Angus McLeod) #168

Indeed, however using deploy keys does not allow the private plugin to be updated via /admin/upgrade, as you have to use custom commands in the app.yml.