UDOIT Configuration Problem

[elarin]

I just installed UDOIT on-premise and followed the steps on Github to get the integration working with Canvas. It's not working for me unfortunately. When I click UDOIT on the course navigation link, I get the following message:

"Configuration problem, please ensure that your instance of UDOIT is configured correctly."

When I look at my access_log file on the server, I never see a hit to it from Canvas. Going to the our udoit.xml.php page shows XML data correctly. Right now, I only have http (port 80) open. Does it need to be https (port 443)? Thanks!

Erick

[elarin]

Our local install is now working. Someone else had previously set up the LTI in our Canvas system to a test Heroku UDOIT instance. So what I was trying to do initially is change the App settings to point to our system. I ended up deleting the LTI configuration and re-created it. 

However when it came time to scan a course, I received the "UDOIT failed to scan this course" error. The Apache error_log file showed "PHP Fatal error:  Uncaught exception 'UnexpectedValueException' with message 'The stream or file "/opt/udoit/config/log.log" could not be opened". The file did not exist so I created it and granted Write permission. 

Afterward, UDOIT was able to scan a course. However, when it finished the "UDOIT failed to scan this course" error appeared again. But I'm able to load up the report to view results. So now I'm wondering why the error is still there?

Erick

[Chris_Hofer]

Hi  @elarin ...

I'm going to share your question with the https://community.canvaslms.com/groups/accessibility here in the Canvas Community in order to help get your question some additional exposure.  This is where the questions about UDOIT are mainly housed.  I'll also tag tr_jbates‌ in this conversation...as he may be able to provide some additional help for you.

[elarin]

My UDOIT log.log file contains this warning when it performs the scan:

udoit.WARNING: E_WARNING: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. {"code":2,"message":"date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.","file":"/opt/udoit/vendor/monolog/monolog/src/Monolog/Logger.php","line":311}

Is this what's causing the error to show up?

[Chris_Hofer]

 @elarin ...

That's not a question I'll be able to answer.  Since UDOIT was created at the University of Central Florida, tr_jbates should be able to assist you with the behind-the-scenes code.

[tr_jbates]

That is just a warning, and shouldn't block execution or cause the "UDOIT failed to scan this course." error.  You should definitely set the time zone on your server, though, if only to keep the warnings from clogging up your error log.

When the error shows up, is it immediate, or does it take a few minutes to appear?  If it takes a few minutes, it's most likely because of your PHP and web server timeout settings.

[elarin]

Jacob,

It takes a few minutes. It shows up after the scan is finished.

The timezone on our CentOS server is set properly to CDT. So I'm not sure how to fix the timezone warning.

[tr_jbates · Accepted solution]

Because it takes a few minutes, I'm willing to bet it's a server timeout issue.  Try setting your PHP and Apache/NGINX request timeouts to a larger amount to see if that fixes the issue.  In a future release, we will be implementing a way for self-hosted institutions to take advantage of the background worker we implemented for Heroku.

As for the timezone, it looks like you have to explicitly define the timezone for PHP.  As of 5.1, it will emit a warning if you are defaulting to the system time (PHP: date_default_timezone_set - Manual ).

[elarin]

Changing the PHP request timeout resolved the error message. And setting a value for timezone in the php.ini file has fixed the warning messages. Thank you Jacob!

Erick