Release notes for WeBWorK 2.15
WeBWorK Online Homework Delivery System Version 2.15 Copyright 2000-2019, The WeBWorK Project All rights reserved. Details ------- Prerelease date: The advanced beta version of webwork and pg 2.15 is anticipated to be released in June 2019. It is currently (6/1/2019) in the develop branch. Release date: October 6, 2019 Big new features: 1. multilingual support -- all characters will be supported (even emoji for up-to-date support stacks :-) We are looking for a translation coordinator and translators and people to help organizing an international library of problems. 2. Easier docker installation -- we will improve documentation to allow you to download and spin up a complete webwork site running on your laptop. This makes it easy to test new webwork features and faster for editing questions. Other features: Commits: The master branch was modified by 378 commits in merging the webwork-2.15 branch into master. Github repository: https://github.com/openwebwork Modules: webwork2 pg ww_install
WeBWorK-2.15-docker_installation_instructions
Some trouble shooting tips
- A useful alias for entering the docker container. Issue it from the webwork2 directory in the place where you have downloaded your webwork repos. (In this case in webwork-docker/webwork2).
- Put this in your .bashrc file
alias dockerbash='docker container exec -it webwork2_app_1 bash'
- or use the command directly to open a bash instance inside the docker container. It is exactly as if you were logging in to the command line of a site running webwork. You will have to navigate to /opt/webwork/webwork2 to find the copy of the files "inside" the site.
- If the password for admin doesn't work for the admin course you can fix it. Using the bash shell provided by dockerbash navigate to the bin directory.
- cd webwork2/bin
- wwsh admin ./putadmin
wwsh - The WeBWorK Shell Available objects: $ce (WeBWorK::CourseEnvironment) $db (WeBWorK::DB) Available modules: Data::Dumper
courseID: admin and scriptFile: ./putadmin -------------------------------- data changed for user admin -------------------------------- done
- The admin password has been reset to admin.
Advise for connecting WeBWorK up to a remote mysql database using secure communications (ssl).
- These notes are from Henry Agnew at UCDavis who has set WeBWorK up to work with LibreTexts.
The dbi configuration in site.conf now reads:
# The database dsn is the path to the WeBWorK database which you have created. # Unless you have given the database a different name or the database resides on another # server you do not need to change this first value. # The format is dbi:mysql:[databasename] for databases on the local machine # For a remote database the format is dbi:mysql:[databasename]:[hostname]:[port] $database_dsn ="dbi:mysql:webwork"; $database_storage_engine = 'myisam';
For ssl communication Henry used:
$database_dsn ="dbi:mysql:webwork:webwork-secure-do-user-3930413-0.db.ondigitalocean.com:25060;mysql_ssl=1;mysql_ssl_ca_file=/mnt/c/Users/Henry/Desktop/Perl/ca-certificate.crt"
"The only change that I needed to do was modify the DBI string a bit and remove the parts about client keys. Basically, you can enable ssl support in WeBWorK just by adding mysql_ssl=1;mysql_ssl_ca_file=/path/to/ca-certificate.crt. I think the issue I was having before was bad permissions on the certificate and my inclusion of the client keys which are not necessary.
Here is my working DBI in my webwork configuration: "dbi:mysql:webwork:webwork-secure-do-user-3930413-0.db.ondigitalocean.com:25060;mysql_ssl=1;mysql_ssl_ca_file=/mnt/c/Users/Henry/Desktop/Perl/ca-certificate.crt"
If WeBWorK has a wiki, I would recommend adding this somewhere incase anyone else wants to use an SSL MySQL database. -Henry Agnew" I asked about the permissions on the files:
"For the file, I left it as a .crt instead of changing it to a .pem. While Linux usually doesn’t care about file endings, this may have affected how Perl parsed the certificate. The file is root owned with Chmod 744, and I think what I changed was making sure all folders above it also had global read permissions as well. It did not seem like it had an issue about permissions being too loose as CHMOD 777 works fine.
I think what also led me astray was that all examples I saw had client keys, but it turns out that excluding them is better since OpenSSL handles it better automatically.
Here is what we found out in terms of error codes:
- SSL_CTL_set_Default_verify_paths: This means that the file does not have the permissions or path correct for access (permission error).
- Unable to get Certificate: This means there is a problem with the file (like the extension).
"