Forum archive
Canvas LMS docker passwords do not work on first login
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
- The entered passwords / login information does not work. I can reset them in the console, and then login
- The admin Canvas username seems to be User, and not what I entered
- After rebuilding the canvas DB to create the admin user, the jobs do not run (and no email password resets, etc)
- 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: /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:~#
Replies (7)
Sorry to hear of your troubles...
Reply 1Thank you, Jeremy, for the
Reply 2Thank 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.
The root user should be able
Reply 3The 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 ~#
That's really weird...
Reply 4I'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.
I should have scrolled
Reply 5I 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:
/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:~#
Glad to hear that you got it working
Reply 6Docker works, operator error...
Reply 7I 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
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.