WeBWorK Main Forum

Editing course.conf

Editing course.conf

by Lars Jensen -
Number of replies: 44

Dear Colleagues,

On our system, instructors cannot edit course.conf, but they can edit files in the templates subdirectory. The files in both directories have the same permission level, so I wonder why this is the case...

Is this how it is supposed to be? If so, what is the reason the instructor can't edit course.conf

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Arnold Pizer -

Hi Lars,

You have to have "admin" privilege to edit course.conf.  "professor" privilege is not sufficient.  Usually a user with "admin" privilege is added to a course when it is created and that user can give "admin" privilege to any other user.


In reply to Lars Jensen

Re: Editing course.conf

by Alex Jordan -
It's a security matter that only a user with admin status can edit the config files. I believe it's to prevent an instructor who may not know what they are doing from saving the config file in some way that renders the course inoperable (until the config file is edited from the server side).

Arnie mentioned you can either be the admin user in the course or the admin user could level-up the professor. An alternative is to set the following somewhere in the config file chain (localOverrides.conf, course.conf):

$permissionLevels{edit_restricted_files} = "professor";

Maybe it is worth hearing from more people why this might be a bad idea first.
In reply to Alex Jordan

Re: Editing course.conf

by Lars Jensen -

Dear Colleagues,

Thanks for the replies. The reason I ask is that I'm thinking about enabling LTI authentication with Canvas. However this is a global action, so I wanted to allow instructors who don't use Canvas to use webwork too, and I thought that including the line

include("conf/authen_ldap.conf");

in course.conf for any course that is not using Canvas. Is there another easy solution for this situation?

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Andras Balogh -

Hi Lars, 

This is a late answer and you might not have this question anymore, but you can combine the different authentication methods together so that they fall back from one to another.

For example in localOverrides.conf we have enabled:  
include("conf/authen_LTI.conf");
include("conf/authen_ldap.conf");

and then we have these  prioritized

$authen{user_module} = [
    { "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
    { "*" => "WeBWorK::Authen::LDAP",}, #fallback authorization method 1
    { "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2
    ];

The reason I found your question is because even with these settings I need to edit some of the course.conf files as some instructors use Blackboard with course level grades while others with set level grades. 

In reply to Andras Balogh

Re: Editing course.conf

by Karl-Dieter Crisman -
I have a very similar question I hope Andras or Alex or someone else will know.

We are just now trying to use the LTI authentication (or at any rate, to get grade passback, which I guess requires this?), but not on all courses. I can't find any specific documentation for how to do this, but is this answer the "official" way? 

In particular, how does WeBWorK "know" if someone is trying to authenticate in various ways?  I just did what you suggest, but now I only get a message like this:

MAT134-2020SP uses an external authentication system (e.g., Oncourse, CAS, Blackboard, Moodle, Canvas, etc.). Please return to system you used and try again.

And it still doesn't ask me to make an account when I try to get into the course from Canvas, so I am clearly still doing something wrong.
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Danny Glin -

There isn't really an "official" way to do this at the course level.  It partially depends on whether the LTI settings will be the same for all courses on the WeBWorK server.

In order to understand how LTI is configured, a little background on WeBWorK configuration is necessary:

WeBWorK reads four configuration files in order, with the latter ones taking precedence if a setting is defined in more than one of them:

  1. /opt/webwork/webwork2/conf/defaults.config - you should not edit this file.  Your changes will be blown away if you upgrade WeBWorK
  2. /opt/webwork/webwork2/conf/localOverrides.conf - any changes you want to make to the default configuration for the whole site should be made here.  You can also include additional configuration files from here.
  3. /opt/webwork/courses/[coursename]/course.conf - any changes you want to make for just this course should be made here.
  4. /opt/webwork/courses/[coursename]/simple.conf - this file is automatically generated by the "Course Configuration" webpage in the course.  It should not be manually edited as it will be overwritten the next time you save changes in the "Course Configuration" page.

To enable LTI, there are two components to the configuration:

  1. Setting the relevant setup variables: things such as the consumer secret, whether grade passback is turned on, etc.  All of these are enumerated in /opt/webwork/webwork2/conf/authen_LTI.conf.dist.  They need to make their way into either localOverrides.conf or course.conf.  Rather than copy and paste all of the settings into one of these files, it is easier to copy authen_LTI.conf.dist to authen_LTI.conf, and use
    include("conf/authen_LTI.conf");
    to read the entire LTI configuration file into localOverrides.conf.
  2. Telling WeBWorK what authentication method(s) it should use.  authen_LTI.conf.dist contains the following:
    $authen{user_module} = [ 
            {  "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
            {  "*" => "WeBWorK::Authen::Basic_TheLastOption",}  #fallback authorization method
    ];
    This tells WeBWorK that it should first try LTI authentication, and if that doesn't work, then then it should try basic authentication (i.e. local WeBWorK passwords).  In Andras's case, he has three entries in this, indicating that WeBWorK should try LTI, followed by LDAP, and then Basic (local passwords).

If your LTI configuration is going to be the same for all of the WeBWorK courses where it is going to be enabled, then you should be able to just add
include("conf/authen_LTI.conf");
to each course.  You just have to make sure that you have edited that file so that it matches your LMS (in particular the consumer secret).  You can also enable debugging in that file which will cause WeBWorK to tell you all of the things that the LMS is sending.

In reply to Danny Glin

Re: Editing course.conf

by Karl-Dieter Crisman -

So, does the mean to edit each separate course conf file?  To my knowledge, we don't actually use those, we do all configuration through the course configuration page.

Here is precisely what happens.

  • If I don't uncomment include("conf/authen_LTI.conf"); all is as it was before with login
  • If I do uncomment it, no matter what combination of options in authen{user_module} I use, I get the message I mentioned in my previous post.

One piece of information is that we already have uncommented 

include("conf/authen_ldap.conf"); and it is properly set up to do LDAP authentication however our institution does that.  Could there be any possible conflict between these two inclusions?  Given that both seem to be defining $authen{user_module} ?  But I don't know much Perl.

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Karl-Dieter Crisman -
https://webwork.maa.org/moodle/mod/forum/discuss.php?d=3934 seems relevant here, but I think I did exactly what was recommended there. (Or do we need https as https://webwork.maa.org/moodle/mod/forum/discuss.php?d=3919 suggests? We don't have a cert for ssl for that server, to my knowledge, it is still http for better or for worse.)
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Karl-Dieter Crisman -
Seems that $external_auth had at least something to do with it. But still am not getting the LTI login attempt.
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Alex Jordan -

> Seems that $external_auth had at least something to do with it.

Is it unclear what that controls? It's functionality is documented in https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist.

I'm inferring that now:
>If I do uncomment it, no matter what combination of options in authen{user_module} I use, I get the message I mentioned in my previous post.
is no longer true? Now that you have $external_auth = 0, you reach the password login screen?

> But still am not getting the LTI login attempt.

That could mean it's failing to authenticate because of not being configured correctly, and moving on to the basic password login. Have you used:
https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist#L12
to see the details of what the LMS is trying to send to WeBWorK?

In reply to Alex Jordan

Re: Editing course.conf

by Karl-Dieter Crisman -

> Now that you have $external_auth = 0, you reach the password login screen?

Correct.  Actually, I just commented that line - I assume that is equivalent to =0, though I don't know Perl well enough to verify that.

> $debug_lti_parameters = 1;

Yes, I set this.  But I am not seeing any info at all from the LMS.  I just see the normal login page.  There also isn't anything the log, since I didn't actually attempt to log in (yet).  "LTI calling parameters printed to HTML page" but that assumes I actually managed to log in.  And once I log in, if I try to do a homework problem, it doesn't do anything related to the LMS, it's just a normal WW page.  Some of that might be because I already have a login; we've been having a devil of a time trying to get a "test student" on the Canvas side, we'll be trying that tomorrow with one of the Canvas admins (I hope!).

As a side note, I have "You are trying to launch insecure content from within a secure site (canvas). Some web browsers may prevent this content from loading." and so it always opens in a new tab/windows.  That is probably a Canvas setting.  Maybe that is part of the problem too?

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Alex Jordan -
Sorry to ask the "did you plug it in" question, but are you using an external learning tool App in Canvas to get to WeBWorK? Not just a simple link?
In reply to Alex Jordan

Re: Editing course.conf

by Karl-Dieter Crisman -

Haha, good question!  Yes, I am.  And it registered properly - at first we got the error message several others have mentioned (not in this thread) but we got that sorted.  (The documentation seems to be wrong in some spots as to whether you put something in the two domain/URL spaces when registering the app.)

I am hoping that the problem has something to do with our trying to use non-student accounts to log in thus far.  Unless ... do you have any experience with the whole "opening a separate window" thing - could that be the problem?

In reply to Alex Jordan

Re: Editing course.conf

by Karl-Dieter Crisman -
Here is a typical access request:

71.184.77.63 - - [27/Jan/2021:13:17:09 -0500] "POST /webwork2/MAT134-2020SP HTTP/1.1" 200 4422 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.

When it tries to pass back, it does this:
No sourcedid for this user/assignment. Some LMS's do not provide sourcedid for instructors so this may not be a problem, or it might mean your settings are not correct. (and then a reference to the usual /LTIAdvanced/SubmitGrade.pm line 181.)

Note that we are using WW 2.12 Would be wonderful if we could get this resolved. Upgrading is not an option quite yet.
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Alex Jordan -

In Canvas where you configure the app, there may be options for what kind of data it will send. One of these options should be something that allows it to send identifying information like the studnet's ID. I think the options are like "private", "public", and some others, and I can't recall whether "private" means share private data like user IDs or keep that kind of data private.

But have you fiddled with this?

In reply to Alex Jordan

Re: Editing course.conf

by Andras Balogh -

According to these instructions https://webwork.maa.org/wiki/LTI-Advanced_Authentication#Canvas  "Privacy" should be set to "Public".

In reply to Alex Jordan

Re: Editing course.conf

by Glenn Rice -

I think you are talking about the "Privacy" setting in the external app configuration in Canvas.   The options are "Anonymous", "Name Only", "E-Mail Only", and "Public".  I believe that the only setting that will work with WeBWorK is Public, which means various identifying information (name, email, Canvas ID, SIS ID of the course, SIS ID of user, etc.) is sent to the vendor (see https://canvas.instructure.com/courses/860915/pages/how-to-configure-an-external-app-for-a-course).

In reply to Glenn Rice

Re: Editing course.conf

by Karl-Dieter Crisman -
Interestingly, according to https://community.canvaslms.com/t5/Question-Forum/Passing-Section-and-SIS-ID-information-from-Canvas-to-WeBWork/td-p/210131 it IS possible to not use "Public", though I have no intention of going that route.
In reply to Alex Jordan

Re: Editing course.conf

by Karl-Dieter Crisman -

Yes, we set privacy to Public as in the instructions.

I hate to ask for all this help on a hijacked thread, especially since I feel people's efforts are being wasted by my lack of knowledge about Canvas.   I feel like there must be something REALLY obvious that I haven't done, like these (which sadly aren't options to fix, I don't think).

  • Must use https (not sure if we can do that though)
  • Must have WW > 2.12 (we have 2.12) 
  • Must have a Canvas Student, not Teacher (we have tested as far as possible with simulating students in Canvas, to no avail)

What is so weird is that it doesn't even show any attempt to create a user in any log.  For instance, the course logs/login.log ONLY shows AUTH LDAP and AUTH WWDB (and OK and FAILED of course), but nothing about LTI attempts.  I wouldn't even know what to look for, but at any rate the string LTI is not to be found.

Thanks to all who are offering assistance, much appreciated.

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Andras Balogh -
v2.12 works according to this post: https://webwork.maa.org/moodle/mod/forum/discuss.php?d=4050
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Danny Glin -
Based on what your describing it sounds like the LTI authentication in WeBWorK isn't being enabled at all. If it was then you should see entries in the login.log, and if you have debugging enabled you should get a massive red box on the login screen.

If you try to enable both LDAP and LTI in localOverrides.conf by including the respective configuration files, then the last one included will override the earlier one as the only authentication method. The solution to this is described above in https://webwork.maa.org/moodle/mod/forum/discuss.php?d=4971#p15281.

Make sure that you have the following in localOverrides.conf:

include("conf/authen_LTI.conf");

include("conf/authen_ldap.conf");


$authen{user_module} = [

    { "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method

    { "*" => "WeBWorK::Authen::LDAP",}, #fallback authorization method 1

    { "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2

    ];


If this works, then you can remove the LTIAdvanced line from localOverrides.conf so that LTI is not enabled for all courses, and copy the $authen{user_module} block into the course.conf file for any course in which you want to enable LTI.

In reply to Danny Glin

Re: Editing course.conf

by Karl-Dieter Crisman -

> If you try to enable both LDAP and LTI in localOverrides.conf by including the respective configuration files, then the last one included will override the earlier one as the only authentication method.

That is what I was missing.  I had these lines, but not in the local override file, only in the LTI file!  That makes a lot more sense.   I didn't realize that earlier post of Andras' was referring to all the same file.

NOW I am getting nasty errors, as promised.   Finally!

> Nonce Expired. Your NonceLifeTime may be too short at ...

I can look this up, as I recall seeing some stuff about it before.   Hopefully soon to be resolved.  Thank you!!!

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Karl-Dieter Crisman -
Success! (At least modulo many other crazy error messages, all of which I eventually could resolve.) The only thing left to do is to test it with someone who is an actual student for passback - our Canvas admins don't make that very easy. But everything else is finally working. Thank you!
In reply to Danny Glin

Re: Editing course.conf

by Karl-Dieter Crisman -

If anyone is seeing this thread, I am now back at square one.  We had a rather nasty malware attack in October, and did not use LTI auth since then.  I'm trying to get it back up, and am baffled.

We are using WW 2.16, https:, and I have put all things ONLY in the course.conf file, which I think is okay based on everything I'm reading above.  I can tell course.conf is being read, because if I change to

$external_auth=1;

we get the expected message "The course ... uses an external authentication ...".  However, if I comment that line out, I get only the basic authentication option, and no log files about having tried the LTI.   Immediately after the previous line, I have this:

$authen{user_module} = [

    { "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method

    { "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method 2

    ];

but this just does not seem to be activated, even if I set 

$LTIAccountCreationCutoff = "professor";

though I'm pretty sure our LMS person is "seen" by Canvas as a student, and she gets the same things as I do.

Based on the discussion earlier, since I do have

$debug_lti_parameters = 1;

I can only assume that the $authen variable isn't being seen.  But the $external_auth variable clearly *is* being seen, since changing it does something.  Shouldn't the course's course.conf be the last place the variables are defined/overridden?  (As expected, simple.conf does not have anything relevant, just things like achievements.)

Thanks for any ideas of what I forgot to plug in.

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Danny Glin -

I can think of a few things to check:

I'll throw in a couple of obvious ones for completeness:

  • I believe that this was already mentioned earlier in the thread, but make sure that you have set up an LTI link in Canvas, and not just a regular web link.
  • Check for typos in your variable names.  They look correct in what you typed here, but it's worth double-checking.

Is there something later in your configuration that could overwrite the variable setting?  I can think of a couple of ways that this could happen:

  1. simple.conf is read after course.conf, so make sure that the variable is not being overwritten there.  It sounds like you've already checked this.
  2. Double-check that there is nothing later in course.conf that would change the value of the variable.  If you are including another config file within course.conf then it would cause an issue if that file redefined the variable.

Another thing to try would be to set $authen{user_module} to something else to make sure that it is being read.  For example you could set

$authen{user_module} = [];

This should completely break authentication for the course.  If it doesn't, then that variable is being overwritten later on.  If it does, then we know that the variable is being set, and there's something else going on with LTI authentication.

In reply to Danny Glin

Re: Editing course.conf

by Karl-Dieter Crisman -

Another thing to try would be to set $authen{user_module} to something else to make sure that it is being read.  For example you could set
$authen{user_module} = [];
This should completely break authentication for the course.  
Yes, this certainly did!  That was a great idea to test.

Is it possible that our Canvas setup simply won't allow LTI connections of this type to "external" servers?  Our Canvas instance is in the cloud, but heavily locked down, so that might be it.  We are no longer allowed to use LDAP, for instance, to authenticate our WW server, which isn't administered by our main admins, though it is physically located on campus and has the correct domain name ending in edu.  But I have no idea how to check if this is the problem. 

I did try

$session_management_via = "key"; 

from another thread, but (as expected) this didn't appear to do anything useful, though I'll probably keep it just because of the Safari thread issues.

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Danny Glin -

I'd be surprised if Canvas allowed you to set up an LTI link, but then silently failed when you tried to use it because you weren't allowed.

If you have $debug_lti_parameters=1, then you should see a warning message any time LTI authentication is attempted, even if it's not successful.  I would expect this to occur even if Canvas isn't sending sufficient information to successfully log in.  I'm at a loss as to why this isn't happening.

My next step in troubleshooting would be to try initiating an LTI connection from something other than Canvas.  If you try this and get the warning messages then it's a safe bet that the issue is something with the Canvas configuration.

I found the following simple LTI launch script.  You can put that file on a web server with php, and change the launch_url to your WeBWorK server.  Even if the authentication is unsuccessful you should still see the warning messages with the LTI parameters that were passed.

In reply to Danny Glin

Re: Editing course.conf

by Karl-Dieter Crisman -

Thank you very much for the suggestion.  I'll have to wait until next term for it, I think (going with script-created accounts as in the not-too-distant past), but hopefully we can figure it out in 2023!

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Andras Balogh -

I am not sure how it works on canvas, but on Blackboard the way I tested the new account creation and the bridge between Blackboard and WeBWorK is the following way:

  1. I create a new admin account in the WeBWorK course, and logging in with that I delete my regular account
  2. Then following the Blackboard link (if set up correctly) will create my account as a student account in the WeBWorK course.
In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Alex Jordan -

> If I do uncomment it, no matter what combination of options in authen{user_module} I use, I get the message I mentioned in my previous post.


What is your setting for $external_auth?

https://github.com/openwebwork/webwork2/blob/master/conf/authen_LTI.conf.dist#L53

In reply to Karl-Dieter Crisman

Re: Editing course.conf

by Andras Balogh -

You can can also see related error messages (as one method fails, and another is successful) in the logs/login.log file of the course.  

In reply to Andras Balogh

Re: Editing course.conf

by Karl-Dieter Crisman -
Thanks, Andras. That will be worth testing eventually, and it does have some useful information, but for right now when I uncomment the inclusion, I don't even get a login screen other than the message I already noted :-) so clearly something is up.
In reply to Andras Balogh

Re: Editing course.conf

by Lars Jensen -

Hi Andras,

Thanks so much for the information. I had already tried your suggestion, and I get this error message after enabling LDAP as fallback authentication method:

Error messages

Failed to initialize course environment: Could not evaluate global environment file /opt/webwork/webwork2/conf/defaults.config: Include file /opt/webwork/webwork2/conf/localOverrides.conf did not return a true value. at (eval 641) line 16. at /opt/webwork/webwork2/lib/WeBWorK.pm line 233.
when I enable the your lines and I can't even get to the course page.

Also, I get apache errors and apache won't restart if I enable your suggestions:

$ systemctl restart apache2.service

Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.

Do you know what the errors mean?

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Andras Balogh -

You included the configuration files authen_LTI.conf and authen_ldap.conf into localOverrides.conf, which is included into defaults.config.

There must be something wrong with the settings in either the authen_LTI.conf or the authen_ldap.conf file.

Can you check the apachectl messages in /var/log/syslog ?


In reply to Andras Balogh

Re: Editing course.conf

by Lars Jensen -

Hi Andras,

Thanks for your reply.

No, I didn't move any settings from the authen_LTI and authen_ldap files into localOverrides. I only configured the three files according to your directions. I have attached my config files (concatenated into a single file - moodle only allows me to attach a single file). I couldn't find anything relevant in my apache log files. 

On my system, ldap authentication works perfectly by itself. LTI authentication works perfectly by itself. But I can't make them work together.

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Andras Balogh -

Hi Lars,

What I meant is that these lines "include" the files automatically into localOverrides.conf
include("conf/authen_LTI.conf");
include("conf/authen_ldap.conf");

The config files have these parts repeated in both of them
$authen{user_module} = [ ...

Can you try to comment them out so that they are only used in the localOverrides.conf?


In reply to Andras Balogh

Re: Editing course.conf

by Lars Jensen -

Hi Andras,

I tried with and without the $authen{user_module} = [ ... line commented out in authen_ldap.conf (and the $authen{user_module} = [ ... enabled in authen_LTI.conf). The error was he same in either case, the one included in my earlier post.

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Andras Balogh -

I have $authen{user_module} = [ ... only in the localOverrides.conf file and after the two include lines.

In reply to Andras Balogh

Re: Editing course.conf

by Lars Jensen -
Hi Andras,

Thanks again for all your help. It turns out that the culprit was typos: I was missing a comma at the end of the fallback authorization line, and a hash before a comment. And then it turned out that there was no need to comment out the $authen{user_module} = [ ... statements, nor to move those statements to the localOverrides file. I left them uncommented in both authen_ldap and in authen_LTI.

Both ldap and LTI authentication now appears to work.

What caused apache to act up and not restart was the missing hash character I accidentally had deleted before a comment in authen_ldap.conf during my testing.

Sincerely,
Lars.
In reply to Lars Jensen

Re: Editing course.conf

by Lars Jensen -

Hi again,

So I thought I had this working, but not quite. Both LTI and ldap authentication now works together for both students and professor, but when this is set up, after login through ldap, access to problem sets only works for the professor. If after student logs in with ldap, the student clicks on a problem set, this error pops up:

The selected problem set (Post,v1) is not a valid set for studenta:
You must use your Learning Managment System (E.G. Blackboard, Moodle, Canvas, etc...) to access this set. Try logging in to the Learning Managment System and visiting the set from there.

A professor does not get this error.

How do I allow students to get to the problem sets when they login with ldap?

Sincerely,
Lars.

In reply to Lars Jensen

Re: Editing course.conf

by Andras Balogh -

This happens to my students when I have in auth_LTI.conf the setting $LTIGradeMode = "homework"; enabled instead of $LTIGradeMode = "course";

See https://webwork.maa.org/wiki/LTI-Advanced_Grading

This can also be changed in individual course.conf files.

In reply to Lars Jensen

Re: Editing course.conf

by Nathan Wallach -

In order for per-homework grade passback to work, WeBWorK needs an assignment specific lis_result_sourcedid which it will only get when a student uses the homework specific LTI link the first time. Once that value is in the database - the student can access the assignment using alternative methods. Thus, using $LTIGradeMode = "homework"; together with alternative authentication methods will work if students are told to use the per-assignment link at least once.

In reply to Lars Jensen

Re: Editing course.conf

by Nathan Wallach -

The last line of several conf files must be something like

1; #final line of the file to reassure perl that it was read properly.


as the code which loads it tests for a true Perl return value to confirm it loaded OK. The error message you got is caused by the test for this in lib/WeBWorK/CourseEnvironment.pm failing.