Tony Hetrick's picture

I'm trying to get the Turnkey docker Canvas LMS build to work, but having all kinds of problem. The host machine is Ubuntu 14.04

  1. The entered passwords / login information does not work. I can reset them in the console, and then login
  2. The admin Canvas username seems to be User, and not what I entered
  3. After rebuilding the canvas DB to create the admin user, the jobs do not run (and no email password resets, etc)
  4. Restarting the container seems to reset the instance (it seems that whenever the instance starts, it initializes the system by running the non-interactive scripts)  

Where did I go astray in my configuration attempt? 


I followed the instructions from: https://www.turnkeylinux.org/blog/14.0-optimized-builds-pt2-proxmox-opennode-docker#docker

docker pull turnkeylinux/canvas-14.1:latest
docker run -i -t -d -p 80:80 -p 443:443 -p 12321:12321 turnkeylinux/canvas-14.1

CID=$(sudo docker run -i -t -d turnkeylinux/canvas-14.1)
CIP=$(sudo docker inspect -format='{{.NetworkSettings.IPAddress}}' $CID)
sudo docker logs $CID | grep "Random initial root password"
ssh root@$CIP

I followed the prompts and entered the information.

When I go to the Canvas login page, (https://myhost/login/canvas), the login does not work. When I try to login to Webmin, the login credentials do not work.

I can reset the root password easy enough: 

docker ps
docker exec -u 0 -it 11111111 bash
passwd

At this point, I can log in to Webmin and browse the db (Servers -> PostgreSQL Databases ->  canvas_production). Looking at the user tables in canvas_production, the name is User. Shouldn't this be the email address I typed?

To solve this problem, I refer back the Canvas Production guide (https://github.com/instructure/canvas-lms/wiki/Production-Start) and re-rake the DB: RAILS_ENV=production bundle exec rake db:initial_setup

At this point, I can finally log into Canvas. Looking at the canvas_production->user table, the email address that I entered is there, and I can login using my new credential.

Just when I think my problems are over, I realize that the automated jobs are not working (perhaps resetting the database killed the process?). 

root@5ca1005dcdb8 www/canvas# service canvas_init status
No delayed jobs pool running
root@5ca1005dcdb8 www/canvas# service canvas_init restart
Daemonizing...
root@5ca1005dcdb8 www/canvas# service canvas_init status
No delayed jobs pool running
root@5ca1005dcdb8 www/canvas# service canvas_init stop
No delayed jobs pool running

Once I restarted the docker instance, none of the newly created logins work (and back square one)

root@5ca1005dcdb8 www/canvas# exit
exit
root@vps298645:~# docker ps
CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS                                                                                   NAMES
5ca1005dcdb8        turnkeylinux/canvas-14.1   "/usr/sbin/start.sh"   57 minutes ago      Up 57 minutes       0.0.0.0:80->80/tcp, 22/tcp, 0.0.0.0:443->443/tcp, 12320/tcp, 0.0.0.0:12321->12321/tcp   mad_wing
root@vps298645:~# docker stop 5ca1005dcdb8
5ca1005dcdb8
root@vps298645:~# docker run -i -t -d -p 80:80 -p 443:443 -p 12321:12321 turnkeylinux/canvas-14.1
ead9b81c2dd41f6cdecf27454c6fa67c88fb3029bf97c83aafa1db49ec74c451
root@vps298645:~# docker ps
CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS                                                                                   NAMES
ead9b81c2dd4        turnkeylinux/canvas-14.1   "/usr/sbin/start.sh"   26 seconds ago      Up 25 seconds       0.0.0.0:80->80/tcp, 22/tcp, 0.0.0.0:443->443/tcp, 12320/tcp, 0.0.0.0:12321->12321/tcp   fervent_ride
root@vps298645:~#

 

Forum: 
Jeremy Davis's picture

It sounds like you are having a pretty crappy TurnKey experience! :( I'm really sorry to hear about that.

To be completely honest I have only used Docker builds for testing and I only explicitly tested Core and LAMP. I tested Canvas for the v14.1 release, but only the ISO and LXC containers (within Proxmox). As the Docker builds are built from the ISO (as are all our builds); in theory if Core and LAMP work in Docker then all appliances should. And if Canvas works from ISO and LXC, then all the Canvas builds should also work.

It sounds like for some reason the inithooks (our intialisation tool i.e. the console screens where you enter passwords etc) isn't functioning as it should. It should set your passwords (root & Canvas) and Canvas email(/username?) after you have entered them. The final step should disable the "FIRSTBOOT" flag so they do not run again on reboot.

Do you think that it might be possible that you didn't complete all of the initialisation steps all the way to the end? If you are not 100% sure could you please double check that.

Let me know and if you continue to have issues I will test it myself and see if I can reproduce your problem.

Tony Hetrick's picture

Thank you, Jeremy, for the response. I'll try it once more and verify that I get all the way to the end. If you want access to the box, email me directly. But, I don't think you'll have any problems replicating it.

Tony Hetrick's picture

I should have scrolled through the console window to view history, prior to now. There is a permissions issue during the init/config process:


root@vps298645:~# ssh root@$CIP
The authenticity of host '172.17.0.2 (172.17.0.2)' can't be established.
ECDSA key fingerprint is 48:b5:82:4e:06:6a:f4:e9:73:b7:b4:1c:27:98:8b:21.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.17.0.2' (ECDSA) to the list of known hosts.

root@172.17.0.2's password:
Linux 933c26eb404c 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016 x86_64
Welcome to 933c26eb404c, TurnKey GNU/Linux 14.1 / Debian 8.2 Jessie

  System information (as of Fri Jul 15 06:09:47 2016)

    System load:  0.10               Memory usage:  22%
    Processes:    43                 Swap usage:    0%
    Usage of /:   25.4% of 19.65GB   IP address for eth0:  172.17.0.2

  TKLBAM (Backup and Migration):  NOT INITIALIZED

    To initialize TKLBAM, run the "tklbam-init" command to link this
    system to your TurnKey Hub account. For details see the man page or
    go to:

        http://www.turnkeylinux.org/tklbam
could not change directory to "/root": Permission denied
sed: cannot rename /etc/sedhgxVcw: Device or resource busy


could not change directory to "/root": Permission denied
 TurnKey Linux - First boot configuration
 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

Daemonizing...

################################## [ LOGIN DETAILS ] ###################################

                        Random initial root password:

2048 62:58:84:05:c7:e5:4f:42:ed:a6:93:94:2a:9e:39:50 /etc/ssh/ssh_host_rsa_key.pub (RSA)
1024 e8:9c:3a:73:e8:44:55:9b:53:49:77:a1:ab:29:d3:62 /etc/ssh/ssh_host_dsa_key.pub (DSA)

########################################################################################

turnkey-init-fence is down
 TurnKey GNU/Linux Configuration Console
 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

[EOF - dtach terminating]
root@933c26eb404c ~# exit
logout
Connection to 172.17.0.2 closed.
root@vps298645:~#

Jeremy Davis's picture

That's really weird. The root user should be able to access the /root directory as it is root's home dir! I've never come across that before. I imagine that it's something that would occur in all Docker builds.

I'm only guessing, but perhaps check the ownership of the /root dir in the docker container filesystem. Maybe it's owned by your Ubuntu user? It should be owed by root (UID 0).

FWIW when I've tested it it has always been on TurnKey from a root account (so all Docker actions done by root). I wonder if that's the issue? If so then we might need to consider how to work around it for now; and avoid it in future builds.

Regardless, thanks for posting.

Tony Hetrick's picture

The root user should be able to access the /root directory as it is root's home dir!

One would think... :)  

From my limited experience with Docker, it won't run without root privileges (either root or sudo). For this instance, /root is definitely the owner of the and accessible when directly logging in as root. Regarding the sed error, this user had the same error when trying to change the hostname (I see that it does change from the docker default, to localhost). Perhaps there are some startup processes that lockout the system for a short time.

could not change directory to "/root": Permission denied
sed: cannot rename /etc/sedhgxVcw: Device or resource busy


root@vps298645:~# docker exec -u 0 -it 933c26eb404c bash
root@933c26eb404c /# whoami
root
root@933c26eb404c /# ls -l
total 64
drwxr-xr-x   2 root root 4096 Apr 12 01:52 bin
drwxr-xr-x   3 root root 4096 Apr 12 01:52 boot
drwxr-xr-x   5 root root  420 Jul 15 06:07 dev
drwxr-xr-x 107 root root 4096 Jul 15 10:42 etc
drwxr-xr-x   2 root root 4096 Nov 30  2014 home
drwxr-xr-x  18 root root 4096 Jul 15 10:26 lib
drwxr-xr-x   2 root root 4096 Mar 25 04:15 lib64
drwxr-xr-x   2 root root 4096 May  5  2015 media
drwxr-xr-x   2 root root 4096 May  5  2015 mnt
drwxr-xr-x   2 root root 4096 May  5  2015 opt
dr-xr-xr-x 147 root root    0 Jul 15 06:06 proc
drwx------   8 root root 4096 Jul 15 06:11 root
drwxr-xr-x  19 root root 4096 Jul 15 10:26 run
drwxr-xr-x   2 root root 4096 Apr 12 01:52 sbin
drwxr-xr-x   2 root root 4096 May  5  2015 srv
dr-xr-xr-x  13 root root    0 Jul 15 06:06 sys
drwxrwxrwt   6 root root 4096 Jul 15 10:47 tmp
drwxr-xr-x  16 root root 4096 Jul 15 10:26 usr
drwxr-xr-x  20 root root 4096 Jul 15 06:25 var
root@933c26eb404c /# cd /root
root@933c26eb404c ~# ls -l
total 0
root@933c26eb404c ~#

 

Tony Hetrick's picture

I found my mistake. I was starting a new Docker container instead of using the original container that I just setup. Really, this reflects my lack of understanding of Docker. Once I blasted all of the docker containers and started from fresh from image, it worked!

I suppose I was a bit misguided by instructions since they first said to start in the instance without binding the ports, and then later the docker run command is posted again binding the ports. Which is exactly what I did, and then unknowining started a 2nd instance. This sequence works:

CID=$(docker run -i -t -d -p 80:80 -p 443:443 -p 12321:12321 turnkeylinux/canvas-14.1)
CIP=$(sudo docker inspect -format='{{.NetworkSettings.IPAddress}}' $CID)
sudo docker logs $CID | grep "Random initial root password"
ssh root@$CIP

 

Jeremy Davis's picture

And apologies on the documentation being confusing. We probably should tidy that up...

Add new comment