Plugins commit refs

Hi,

We are running on [v1.9.0.beta1] which commit Refs we should be pointing to for each plugins (jira, ldap, solved, poll).

Thanks

You should upgrade since there have been many security patches since then.

7 Likes

We cannot upgrade our production server without testing the upgrade procedure on a staging environment. Unfortunately, it will take a bit of time to order and then install v1.9.0 beta 1 on a staging sever. In the meantime we are getting lots of complaints from our users. As far as the security issues, we are in a private network and behind of firewall. Would it be possible to help us determine the commit references that we should be using in our app.yml file so that the following plugins will all work: LDAP, Solved, and Poll.

I looked into our deployment logs for you:

Thanks, we will try and let you know.

Thanks, it worked, we will do more tests.
One more question we are in v1.9.0.beta1 , is it safe to upgrade directly to 2.3.0.beta1 or we need to do step by step?

You should be able to do that in a single step.

Assuming you followed the official install instructions, upgrading can be as simple as SSH’ing into your server, and running:

cd /var/discourse
git pull
./launcher rebuild app

:warning: this will result in downtime while being run. If you don’t already have it installed, I’d recommend the docker_manager plugin which supports upgrades without downtime. (Again, this plugin assumes and requires the official install)

If you use non-official plugins, or deviated from the official install instructions, it may be more complicated. You may also need to run the last command (./launcher rebuild app) twice, if you’re stil running on PostgreSQL 9 and not 10.

1 Like

Thanks,
Before doing upgrade on production, we would like to try on staging.
We have Ubuntu 16.04.3 on our staging and I am trying to install same version [v1.9.0.beta1] first and then upgrade. but I am getting error.
Do you have any comments?

An error occurred while installing mini_racer (0.1.9), and Bundler cannot
continue.
Make sure that `gem install mini_racer -v '0.1.9' --source
'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  mini_racer

I, [2019-02-04T20:29:59.794314 #15]  INFO -- : Terminating async processes
I, [2019-02-04T20:29:59.794376 #15]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 70
I, [2019-02-04T20:29:59.794449 #15]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 186
2019-02-04 20:29:59.794 UTC [70] LOG:  received fast shutdown request
186:signal-handler (1549312199) Received SIGTERM scheduling shutdown...
2019-02-04 20:29:59.797 UTC [70] LOG:  aborting any active transactions
2019-02-04 20:29:59.800 UTC [70] LOG:  worker process: logical replication launcher (PID 79) exited with exit code 1
2019-02-04 20:29:59.801 UTC [74] LOG:  shutting down
186:M 04 Feb 20:29:59.839 # User requested shutdown...
186:M 04 Feb 20:29:59.839 * Saving the final RDB snapshot before exiting.
186:M 04 Feb 20:29:59.853 * DB saved on disk
186:M 04 Feb 20:29:59.853 # Redis is now ready to exit, bye bye...
2019-02-04 20:29:59.853 UTC [70] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --verbose --without test --without development --retry 3 --jobs 4' failed with return #<Process::Status: pid 371 exit 5>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --verbose --without test --without development --retry 3 --jobs 4'", "su discourse -c 'bundle exec rake db:migrate'", "su discourse -c 'bundle exec rake assets:precompile'"]}
0a449d1ee17bad72bb330501a5724c96c19d9a8145bb768d4c257a38d76c00a5
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Given how old 1.9.0.beta1 is (released May 31, 2017), I can’t guarantee you’ll be able to install it today. Among other things, GitHub - discourse/discourse_docker: A Docker image for Discourse has been updated since 1.9.0.beta1, so it may no longer support installing the correct dependency versions.

As for mini_racer itself, not sure. The version is still listed on RubyGems. It’s possible @sam might have an idea, but installing a 1.5+ y/o version of Discourse is not something we support.

It is indeed possible :worried: but this is not something I can support. You got to update your Discourse to latest stable at least.

2 Likes

@sam that’s what they’re trying to do … :wink:

@esepjav can’t you just clone your production VM in order to test the upgrade procedure? Alternatively, just install 2.2.0 on a new server and export/import.

4 Likes

One question regarding Database, when we upgrade our production server from 1.9 to 2.2,
Do we need to do any update in DB server? we have external database for production server.

Yes, you should run PostgreSQL 10.X per the specs.

1 Like

Is it possible to provide us steps to upgrade Database?
We have PostgreSQL 9.4.5 running on redhat 5.11.
Unfortunately our staging environment is not same as production and we can not test.
Is it possible to move data from 9.4.5 to 10.5? data from 1.9 to 2.2 discourse version.

If you run your own external database you really take responsibility for maintaining it. The only thing we support here is the standard install.

How big is your community? If it’s not huge then this may be a good time to migrate a backup into a standard install and save yourself this pain again in the future. If you let it Discourse does a really good job of maintaining the database versions automatically whenever requirements change.

Can we move data from discourse 1.9/ postgres 9.4 to standard install discourse 2.2/ postgres 10.5? i.e. can we rsync the data and dump the 9.4 DB and load to the postgres 10.5 DB? Or is the data incompatible and needs to be run through a upgrade?

What would you need to rsync?

Just take a backup and upload it to the new site via /admin.

1 Like

We down loaded backup via UI from 1.9 and uploaded to 2.2 and restored but we got below error:

[2019-02-07 20:33:47] EXCEPTION: An error has occurred, this and all later migrations canceled:

PG::NotNullViolation: ERROR:  null value in column "silenced" violates not-null constraint
DETAIL:  Failing row contains (2642, erandba, 2017-03-04 12:34:43.992, 2017-03-04 12:34:43.992, John Doe, 185560, null, john.doe@test.com, null, null, t, erandba, 2018-11-20 23:01:08.437811, f, null, 1, t, null, null, 2018-11-19 22:22:36.922808, null, null, null, 0, 0, 142.133.230.136, null, null, null, null, null, null, null, f, f, 2018-11-19 22:22:36.922808, null).
: UPDATE users set silenced = blocked

Finally we are able to restore data from 1.9.0beta1 to 2.3.0beta2.
We modified /var/www/discourse/db/migrate/20171110174413_rename_blocked_silence.rb and remove “null: false” from line “add_column :users, :silenced, :boolean, default: false”

1 Like