Install Discourse on Ubuntu or Debian for Development

documentation developers
,
1

:warning: This guide covers installation instructions in development environment. For a production guide see: Install Discourse in production with the official, supported instructions

So you want to set up Discourse on Ubuntu or Debian to hack on and develop with?

We’ll assume that you work locally and don’t have Ruby/Rails/Postgres/Redis installed on your Ubuntu or Debian system. Let’s begin!

Requirements

We suggest having at least 4 GB RAM and 2 CPU cores.

Current compatibility:

OS Compatibility
Debian 11 :white_check_mark:
Ubuntu 22.04 or later :white_check_mark:

Install Discourse Dependencies

As regular user run this script in terminal, to setup Rails development environment:-

bash <(wget -qO- https://raw.githubusercontent.com/discourse/install-rails/master/linux)

This will install following new packages on your system:

In case you have any of this package pre-installed and don’t want to run entire script, see the script and pick the packages you don’t have currently installed. The script is fine-tuned for Discourse, and includes all the packages required for Discourse installation.

Now that we have installed Discourse dependencies, let’s move on to install Discourse itself.

Clone Discourse

Clone the Discourse repository in ~/discourse folder:

git clone https://github.com/discourse/discourse.git ~/discourse

~ indicates home folder, so Discourse source code will be available in your home folder.

Setup Database

Already completed by the install script

Create role with the same name as your Linux system username:

cd /tmp && sudo -u postgres createuser -s "$USER"

Bootstrap Discourse

Switch to your Discourse folder:

 cd ~/discourse

Install the needed gems

source ~/.bashrc
bundle install

Install the JS dependencies

yarn install

Now that you have successfully installed gems, run these commands:

bin/rails db:create 
bin/rails db:migrate
RAILS_ENV=test bin/rails db:create db:migrate

Start rails and ember server:

bin/ember-cli -u

You should now be able to navigate to http://localhost:4200 to see your local Discourse installation.

Create New Admin

To create a new admin, run the following command:

bin/rails admin:create

Follow the prompts, and a new admin account will be created.

Configure Mail

Run MailHog:

mailhog

Congratulations! You are now the admin of your own Discourse installation!

Happy hacking! And to get started with that, see Beginner’s Guide to Creating Discourse Plugins.

Last Reviewed by @blake on 2023-04-03T06:00:00Z

58 Likes
620

Another issue, which has been present for a long time, I think, is that the logo is loaded from 127.0.0.1 instead of the server’s IP, which creates a broken image. I believe it’s the same for all dev installs.

image

3 Likes
621

I cannot produce this :thinking: I have latest Discourse beta1-dev on Ubuntu 2.3. I do have to run the redis-server --daemonize yes when I restart .

Mine is loading the dark and light logos I have in the branding logo fields. When I remove them, it shows the name of my forum. Or do you mean the default logos on setup?

622

You won’t encounter the issue if your server is served on 127.0.0.1. :slight_smile:

We’re looking into these issues and see what can be done about it. :+1:

1 Like
623

The Redis issue is fixed as per this commit, thanks for reporting simon :+1:

5 Likes
624

Somewhat related to this is the minor issue that emails sent from development sites use 127.0.0.1 in URLs instead of localhost. For example, the URL to confirm a new email looks like this:

http://127.0.0.1:4200/u/confirm-new-email/0aa460d1d6353c2d80825a367a09e59d

To use the link, localhost needs to be substituted for 127.0.0.1 in the browser’s address bar.

I don’t think the issue is specific to Ubuntu or Debian dev sites. Is there a general topic for issues related to development sites? There also seems to be a recently introduced issue where wehbooks can’t be configured to work on localhost. Possible that needs its own topic though.

2 Likes
625

hmmm now getting redis server errors when installing the packages.

...
    CC connection.o
    CC unix.o
    CC logreqres.o
    LINK redis-server
lto-wrapper: warning: using serial compilation of 31 LTRANS jobs
    INSTALL redis-sentinel
    CC redis-cli.o
    CC redisassert.o
    CC cli_common.o
    CC cli_commands.o
    LINK redis-cli
lto-wrapper: warning: using serial compilation of 4 LTRANS jobs
    CC redis-benchmark.o
    LINK redis-benchmark
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
    INSTALL redis-check-rdb
    INSTALL redis-check-aof

Hint: It's a good idea to run 'make test' ;)

make[1]: Leaving directory '/tmp/redis-stable/src'
cd src && make install
make[1]: Entering directory '/tmp/redis-stable/src'
/bin/sh: 1: pkg-config: not found
/bin/sh: 1: pkg-config: not found
/bin/sh: 1: pkg-config: not found
    CC Makefile.dep
/bin/sh: 1: pkg-config: not found
/bin/sh: 1: pkg-config: not found
/bin/sh: 1: pkg-config: not found

Hint: It's a good idea to run 'make test' ;)

    INSTALL redis-server
    INSTALL redis-benchmark
    INSTALL redis-cli
make[1]: Leaving directory '/tmp/redis-stable/src'
Adding system user `redis' (UID 130) ...
Adding new group `redis' (GID 138) ...
Adding new user `redis' (UID 130) with group `redis' ...
Not creating home directory `/home/redis'.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
Failed to start redis-server.service: Unit redis-server.service has a bad unit file setting.
See system logs and 'systemctl status redis-server.service' for details.
failed
3 Likes
626

I’ve done 3 install attempts and all have failed at the same spot in the script now. It was working before those recent commits other than the redis-server --daemonize yes part. If I have time later, I will try again and step through the script and see if I can work around it. I am wondering if some of those new additions to the script are case sensitive.

1 Like
627

I am getting the same redis server errors.
Ubuntu 22.04

1 Like
629

After multiple failed attempts to use the existing script and forking and changing it, I simply ended up reverting the last two commits to the earlier version and it worked as it did before. I’m still getting some odd redis stuff when I start but otherwise my Discourse dev instance is now installed and up and running again on Ubuntu 22.04. moved on, see below.

630

Ok I managed to fix the script with some brainstorming help from @simon and I made a PR for it. I’m sure I didn’t name the PR properly though. Anyways, with the changes, the script now runs without a hitch and you can install Discourse dev instance again. There is no need to start redis server on boot either. I did the full install on a fresh Ubuntu 22.04 from scratch.

The redis file directives are case sensitive so I changed those, and then the install was hanging on the sudo systemctl status redis-server line, so I added a --no-pager option there.

2 Likes
632

And that worked for me too. Thanks!

2 Likes
633

Has something related to fixing this issue allowed development sites to be served on either localhost:4200 or 127.0.0.1:4200? If so, I’m not sure if it’s a feature or a bug :slight_smile:

When an invite email is sent from a development site, the URL in the email has for some reason always been on the 127.0.0.1:4200 domain. In the past, I’ve had to replace 127.0.0.1 with localhost to use the invite link. I can now click the invite link, accept the invite, and get logged into Discourse as a new user on 127.0.0.1:4200. That means that in the same Chrome browser window, I have one user logged in at localhost:4200 and a separate user logged in at 127.0.0.1:4200. This might come in handy, but I’m wondering if it could result in unintended side effects.

2 Likes