Install plugins without direct access to github

support
1

I’m installing Discourse (ditnami-discourse) within a very restricted environment. The VM has no access to github, for instance. The mechanism bitnami-discourse uses for plugin installation is:

RAILS_ENV=production bundle exec rake plugin:install repo=https://github_repo_url
RAILS_ENV=production bundle exec rake assets:precompile

Via an alternative route I’ve placed (cloned) the plugin repo’s in de plugins directory. Unfortunately (for me) “RAILS_ENV=production bundle exec rake plugin:install” seems to do more then just clone the repo in the plugins directory. Because when I run “RAILS_ENV=production bundle exec rake assets:precompile” the plugins are not being picked up. Is there an option to do something like ?:

RAILS_ENV=production bundle exec rake plugin:install path=./local_repo_for_plugin

Thank you in advance!

2

That’s why it’s not supported here. You can ask the good folks at Bitnami for help. People here will be glad to help if you follow https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md.

3 Likes
3

Thank you for your response.

I could have asked the exact same question if I was using the officially supported method. The installation method is not the issue. A way to install plugins without direct access to github is.

Edit: I might decide to use the official method in a later stage anyway. In that case the question remains the same.

4

You just need to put a folder containing the plugin code in the plugins folder.

The yaml hook gives you full bash power so you can:

  • wget a tarball with plugin code
  • rsync from somewhere with plugin code
  • scp it from another server
  • git clone from a local gitlab install

etc.

6 Likes
5

The github plugin repo clones are already in place within the plugins directory. They just aren’t picked up by the assets:precompile hook. I need an alternative way of running plugin:install, because I can’t provide a working repo url (github.com is blocked).

Edit: the machine doesn’t have access to any git server, unfortunately.

6

plugin:install is not a thing for official Discourse.

The only official way to install plugins is the one we describe on every approved :tm: install app.yml, and that has 0 problems with ordering of the precompile assets task.

3 Likes
7

Ok. So if I use the official installation method, I can just place (rsync) git clones of the plugins into the /plugins directory, run assets:precompile, and the plugins will be installed? If that is the case I will try and find a way to use the supported method (which won’t be easy because of all the restrictions the machine has in place).

As I’ve said. I can’t access (or install) any git repositories on the VM.

8

If you use the official way, there will be no need to manually run assets:precompile.

Just install the plugins in the same place the default plugin is installed and follow along.

As said above there are a multitude of ways to get the code inside the container (wget, curl, rsync, scp). Since you are the only one familiar with the environment, you will have to pick the more appropriate one.

One thing you can do, is to bootstrap the docker container elsewhere (./launcher bootstrap app step in our official guide) and then move the resulting image into the server with restricted access and run the image from there. That will require some docker-fu, but in my experience those heavily restricted environments are all about making the every day to day tasks a lot harder anyway.

6 Likes
9

Thank you for your support. I’ve created a bootstrapped image on a different machine (that does have access to github). I’ve pushed that image to our local Docker registry and pulled the image on the machine that can’t access github. When I try to run the image I still get the following error and the container won’t start. Anything I can do about that? I’m using the officially supported method now!

fatal: unable to access 'https://github.com/discourse/pups.git/': Could not resolve host: github.com
10

How exactly are you trying to run the image?

11

docker run docker-registry.local/discourse/my-bootstrapped-image

1 Like
12

At the end of the ./launcher bootstrap we print a complete run command that you should use to start the image, it’s like:

docker run --shm-size=512m -d --restart=always  --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log local_discourse/app /sbin/boot

Also, are you 100% sure you saved the bootstraped image to the local registry local_discourse/app:latest instead of the base image discourse/base:2.0.20190217 ?

I was able to boot the app while disabling my network interface just fine.

3 Likes
13

Thank you @Falco! I’ve got it working on a very restricted RHEL VM and a Ubuntu 18.04 VM with access to everything (for generating the image), using the supported installation method (https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md). The missing /sbin/boot command was what caused the github.com access error.

In summary and for documentation; the steps needed to create and image and run it on my server:

  • Clone discourse:
git clone https://github.com/discourse/discourse_docker.git /var/discourse && cd /var/discourse
  • Configure with default values
./discourse-setup
  • Tweak the default discourse configuration (optional)
nano /var/discourse/containers/app.yml
  • Get the local_discourse/app IMAGE ID (something like b6fa739cedf5)
docker images -a
  • Create your own tag for the image with the IMAGE ID 
docker tag b6fa739cedf5 your-registry-url.com/namespace/image-name

docker push your-registry-url.com/namespace/image-name
  • On the server you’d like to create the discourse container, create a docker-compose.yaml file for your application (configure it to your specifications with something like…)
version: '3'

services:
  discourse:
    container_name: discourse_docker_custom
    image: 'your-registry-url.com/namespace/image-name:latest'
    restart: always
    shm_size: 512m
    command: /sbin/boot
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - '/shared:/var/discourse/shared/standalone'
    environment:
      - DISCOURSE_DEVELOPER_EMAILS=admin@email-address.com
      - DISCOURSE_SMTP_AUTHENTICATION=none
      - DISCOURSE_SMTP_OPENSSL_VERIFY_MODE=none
      - DISCOURSE_SMTP_ADDRESS=localhost
      - DISCOURSE_SMTP_PORT=25
      - DISCOURSE_SMTP_USER_NAME=
      - DISCOURSE_SMTP_PASSWORD=
      - DISCOURSE_SMTP_ENABLE_START_TLS=true
      - DISCOURSE_HOSTNAME=your.server.com
    networks:
      - discourse

networks:
  discourse:
    driver: bridge

docker-compose up -d

…and you’ll be up and running.

5 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.