Questions/Comments regarding the Production Installation instructions

136 views
Skip to first unread message

Frank Vazquez

unread,
Aug 28, 2015, 2:35:51 AM8/28/15
to Canvas LMS Users
for some scope, I've recently installed Canvas (prod) on Ubuntu 14.04 with postgresql 9.3, bundler 1.7.11, apache 2.4, redis 2.6, and phusion passenger 5.0.16

1) In the database population step an example is given on how to fill the database with inital data.  It is also mentioned that there is a way to pre-fill data by defining variables.  Could someone provide an example of what my command line would look line with the Database population and defined environment variables?


2) under the "Making sure to use the "most restrictive" permissions, there is a comment:
"Note that it is probably wise to ensure that the ownership settings of all other files besides the ones with permissions set just above are restrictive, and only allow your canvasuser user account to read the rest of the files"

What exactly does this mean?
Exactly what is the scope of "other files"?
To me, that means that I should have done something like:
~/var$ sudo chown -R canvasuser ./canvas/
~/var$ sudo chmod -R 400 ./canvas/

However, I know doing this would make canvas fail in a fantastic fashion.  It would not be able to write uploaded files to /var/canvas/tmp/files/0000/...., nor would it be able to execute anything so jobs probably wouldn't work.


3) In the apache configuration, the instructions state to modify the (2) instances of SetEnv and (2) Directory.  I've never done this, but i've only ever setup a single server for canvas that runs everything (web/db/jobs)

What other options are there for the SetEnv and Directory compared to the default suggestions?


4) In the Redis section, why do the instructions have "sudo apt-get install redis-server" twice?  I think this is probably an oversight.

There is also an example to change directory:
sysadmin@appserver:/var/canvas$ cd /var/canvas/
however, since the user is already in /var/canvas/ this would result in the user getting a message about the directory not existing (hopefully!) as it would put them in this non-existent location:
/var/canvas/var/canvas



Graham Ballantyne

unread,
Aug 28, 2015, 3:22:47 AM8/28/15
to canvas-l...@googlegroups.com
On Thu, Aug 27, 2015 at 11:35 PM, Frank Vazquez <fvazqu...@gmail.com> wrote:
for some scope, I've recently installed Canvas (prod) on Ubuntu 14.04 with postgresql 9.3, bundler 1.7.11, apache 2.4, redis 2.6, and phusion passenger 5.0.16

1) In the database population step an example is given on how to fill the database with inital data.  It is also mentioned that there is a way to pre-fill data by defining variables.  Could someone provide an example of what my command line would look line with the Database population and defined environment variables?

It's in the docs: https://github.com/instructure/canvas-lms/wiki/Production-Start#database-population. You're just passing environment variables to the rake task:

CANVAS_LMS_ADMIN_EMAIL=f...@bar.com CANVAS_LMS_ADMIN_PASSWORD=secretpassword CANVAS_LMS_ACCOUNT_NAME="Foo University" CANVAS_LMS_STATS_COLLECTION=opt_out RAILS_ENV=production bundle exec rake db:initial_setup
 
2) under the "Making sure to use the "most restrictive" permissions, there is a comment:
"Note that it is probably wise to ensure that the ownership settings of all other files besides the ones with permissions set just above are restrictive, and only allow your canvasuser user account to read the rest of the files"
What exactly does this mean?
Exactly what is the scope of "other files"?
To me, that means that I should have done something like:
~/var$ sudo chown -R canvasuser ./canvas/
~/var$ sudo chmod -R 400 ./canvas/
However, I know doing this would make canvas fail in a fantastic fashion.  It would not be able to write uploaded files to /var/canvas/tmp/files/0000/...., nor would it be able to execute anything so jobs probably wouldn't work.

We don't adjust any permissions or ownership on our installation. Permissions are whatever comes across during a `git clone` from our repo. The deploy process runs as canvasuser, so all the files are owned by canvasuser. As I mentioned in the other thread, our servers are fairly locked-down: no access from the internet, restricted to a few users, nothing else is running on them, etc. This has worked well enough for us. YMMV.

3) In the apache configuration, the instructions state to modify the (2) instances of SetEnv and (2) Directory.  I've never done this, but i've only ever setup a single server for canvas that runs everything (web/db/jobs)
What other options are there for the SetEnv and Directory compared to the default suggestions?

SetEnv passes an environment variable through to Apache (and down into the app). In this case, it's telling Rails to run in production mode, as opposed to development or test modes.

The path passed to the <Directory> block must be the absolute path to the public directory. If you installed in /var/canvas, then it should be /var/canvas/public. For us, it's /var/rails/canvas/current/public. You'll need to put in whatever is appropriate for your installation.

4) In the Redis section, why do the instructions have "sudo apt-get install redis-server" twice?  I think this is probably an oversight.

Yeah, that's probably a typo. I just took it out. 

There is also an example to change directory:
sysadmin@appserver:/var/canvas$ cd /var/canvas/
however, since the user is already in /var/canvas/ this would result in the user getting a message about the directory not existing (hopefully!) as it would put them in this non-existent location:
/var/canvas/var/canvas

You're correct in that the extra `cd` is probably a mistake, but you're incorrect in your assumption that you'd get an error message. The path you're passing to `cd` is an absolute path (`/var/canvas`), not a relative one, so it would work just fine. It wouldn't actually do anything, since as you say you're already in /var/canvas, but it wouldn't fail with an error. 

[grahamb@canvas-ap1 ~]$ cd /var/rails/canvas/
[grahamb@canvas-ap1 canvas]$ cd /var/rails/canvas/
[grahamb@canvas-ap1 canvas]$ echo $?
0

(echo $? prints the exit code of the last command. An exit code of 0 means the command completed successfully).

Frank Vazquez

unread,
Aug 28, 2015, 11:57:56 AM8/28/15
to Canvas LMS Users
Thanks Graham!

for the DB command example, I wasn't sure if the variables would come before the command or after, my experience is very limited.

you're absolutely right about the change directory command, I thought about it on the drive home and asked myself "was there a slash before the var?"  looking at it now, there is, so it would stay as just /var/canvas instead of going to /var/canvas/var/canvas.


thank you again!
Frank

Frank Vazquez

unread,
Aug 28, 2015, 5:32:55 PM8/28/15
to Canvas LMS Users
Another permission scenario i've run into during installation of the Python QTI Migration Tool, which is needed to import quizzes (an essential function if you ask me).

currently, my delayed_jobs.yml under config has the following permissions because of the Production instructions: sudo chmod 400 config/*.yml
-r--------  1 canvasuser sysadmin   631 Aug 27 23:42 delayed_jobs.yml
This means that only canvasuser has any read rights to it.

In trying to get the Python QTI Migration Tool working you have to execute 
~/var/canvas$ ./script/delayed_job restart
which from the initial git pull, has the following permissions:
-rwxrwxr-x  1 sysadmin sysadmin  314 Aug 27 18:59 delayed_job

however, when I restart the job, I get this for an error:
/var/canvas/vendor/bundle/ruby/2.1.0/gems/canvas-jobs-0.9.13/lib/delayed/settings.rb:34:in `read': Permission denied @ rb_sysopen - /var/canvas/config/delayed_jobs.yml (Errno::EACCES)


I see (2) ways I can resolve this:

1) change the Production instructions so that instead of 
~/var/canvas$ sudo chmod 400 config/*.yml
it is 
~/var/canvas$ sudo chmod 440 config/*.yml
This way as long as my $USER is part of the sysadmin group, I should be able to read /config/delayed_jobs.yml

2) give permissions and change to the canvasuser to run the delayed_job
~/var/canavs/script$ sudo chown canvasuser ./delayed_job
~/var/canvas/script$ sudo su canvasuser
~/var/canvas/script$ ./delayed_job restart

I'm going with option #2 because Graham runs their instance with canvasuser owning the entire install tree, so it should work fine.  IMHO this reinforces canvasuser owning the entire install tree as Graham recommended.

Thoughts? opinions?
Reply all
Reply to author
Forward
0 new messages