Creation of a link to webwork3 from the ww2 instructor tools.

[pstaabp]

No description provided.

[goehle]

Some comments:

1. You should probably just remove the homeworksetseditor3 and classlisteditor3 from localoverrides.conf.dist. It doesn't do anything if they are enabled, which is confusing.
2. This is an older problem, you can decide if you want to fix it or not. Right now because %showeditors is being set in localOverrides.conf it is actually completely overriding the defaults.conf hash. Things in localOverrides.conf should be defined so that they add to or change default options. For example, if users don't update their localOverrides.conf the localOverrides.conf.dist, they wont see the ww3 link, even though its enabled in defaults.conf, because it is missing in their local localOverrides.conf file. Unfortunately, any changes to fix this would still have to copied over from the .dist file as well...
3. Also mostly unrelated to the pull, but maybe it would be a good idea to put the config files for dancer in the conf directory, and then have softlinks from webwork3/environments. I always forget to set up my dancer conf files because they are in a different place.
4. A bigger issue, when I click on WeBWorK 3 I get the Dancer error 404 page. If I go to course-id/info, then dancer works, so its just the manager page that seems to be failing for me. That being said, if manager is the right place, then that's not technically a problem with this pull request.

[pstaabp]

1. no problem

2. I guess the proper way to do the %showeditors in localOverrides is to only override differences between the one in localOverrides and defaults.config. I can do this.

3. We can do this for now. I think eventually, they should all go to webwork3/ as we separate the two. So I might advocate for keeping them there putting a link in the webwork2/conf directory.

4. To clarify. If you’re in ww2 and click on the webwork3 link on the left, you get the 404 error? Is it the Dancer 404 error or an apache 404 error? If it is the apache one, make sure that dancer is running. It sounds like you have dancer running. What is the URL that it is sending you to. It should be /webwork3/courses/course_id/manager

Let me know about 4) and I’ll work on the other pieces before the pull.

On Mar 20, 2014, at 5:30 PM, Geoff Goehle notifications@github.com wrote:

Some comments:

1. You should probably just remove the homeworksetseditor3 and classlisteditor3 from localoverrides.conf.dist. It doesn't do anything if they are enabled, which is confusing.
2. This is an older problem, you can decide if you want to fix it or not. Right now because %showeditors is being set in localOverrides.conf it is actually completely overriding the defaults.conf hash. Things in localOverrides.conf should be defined so that they add to or change default options. For example, if users don't update their localOverrides.conf the localOverrides.conf.dist, they wont see the ww3 link, even though its enabled in defaults.conf, because it is missing in their local localOverrides.conf file. Unfortunately, any changes to fix this would still have to copied over from the .dist file as well...
3. Also mostly unrelated to the pull, but maybe it would be a good idea to put the config files for dancer in the conf directory, and then have softlinks from webwork3/environments. I always forget to set up my dancer conf files because they are in a different place.
4. A bigger issue, when I click on WeBWorK 3 I get the Dancer error 404 page. If I go to course-id/info, then dancer works, so its just the manager page that seems to be failing for me. That being said, if manager is the right place, then that's not technically a problem with this pull request.

—
Reply to this email directly or view it on GitHub.

[pstaabp]

After thinking a bit more about 2) above, I won't worry about doing this now because I have plans to rewrite the way settings/configurations are stored.

[goehle]

I am getting sent to the correct address and Dancer is providing the 404 page (so it is running). This is also preventing me from testing the other pull request.

As for the config stuff, rewriting CourseEnvirontment is a longer term project, I think. (It would need to maintain compatibility with ContentGenerator and all the exisiting stuff, for example.) I went ahead and looked it up and its easy to fix this one case. Just change the %showeditors array in localOverrides.conf to %showeditorsLocal and then add

@showeditors{ keys %showeditorsLocal } = values %showeditorsLocal;

This will overwrite entries in %showeditors from the ones in local, when they exist. (Although it does mean if they want to turn off something they need to explicitly set it to zero, and not just comment it out).

[pstaabp]

So you said that that /webwork3/courses/course_id/info works? This is really odd.

If you’re running dancer on the command line (with the startDancer script), we you go to /webwork3/courses/course_id/manager, there should be a request in the dancer output. Each request has a #. Can you send me the output from that request (It may be about 40 lines or so)?

On Mar 21, 2014, at 10:12 AM, Geoff Goehle notifications@github.com wrote:

I am getting sent to the correct address and Dancer is providing the 404 page (so it is running). This is also preventing me from testing the other pull request.

As for the config stuff, rewriting CourseEnvirontment is a longer term project, I think. (It would need to maintain compatibility with ContentGenerator and all the exisiting stuff, for example.) I went ahead and looked it up and its easy to fix this one case. Just change the %showeditors array in localOverrides.conf to %showeditorsLocal and then add

@showeditors{ keys %showeditorsLocal } = values %showeditorsLocal;

This will overwrite entries in %showeditors from the ones in local, when they exist.

—
Reply to this email directly or view it on GitHub.

[goehle]

So I'm having lots of trouble. One big one is that you don't have the
bower-components directory in our github. Considering the discussion on
the dev list, I think it should be. For example, there isn't a good way to
get bower on to debian wheezy (its all personal package repos and
installing from source). So its been very difficult for me to get the js I
need to run.

Also, I"m fast losing patience with bower. I finally got it installed (compiled from scratch even) and I can't even use it to get the js files. It wants to download things from git and I"m at the mercy of whatever changes people have made to their repos. So it keeps failing to download something and that kills the whole process.

Edit: So it was my schools firewall policy (which I have no control over.) It blocks ssh access to the outside world, which keeps bower from downloading any packages where people have decided to serve them using something other than http.

[goehle]

Ok, I've got it running but when I click on WeBWorK3 it asks me to log in again, and when I do I get the following error in apache/error.log

Use of uninitialized value $WeBWorK::Constants::WEBWORK_DIRECTORY in concatenation (.) or string at /opt/webwork/webwork2/lib/WeBWorK/Constants.pm line 41.

[pstaabp]

I do notice the relogin problem. I’ll work on this.

It’s odd that you’re getting the other error. I’m not seeing it and I think that this gets set in webwork-apache2.config, line 56:

$WeBWorK::Constants::WEBWORK_DIRECTORY = $webwork_dir;

where $webwork_dir is set a few lines ahead of it. If I understand, this is truly a global variable.

On Mar 23, 2014, at 7:52 PM, Geoff Goehle notifications@github.com wrote:

Ok, I've got it running but when I click on WeBWorK3 it asks me to log in again, and when I do I get the following error in apache/error.log

Use of uninitialized value $WeBWorK::Constants::WEBWORK_DIRECTORY in concatenation (.) or string at /opt/webwork/webwork2/lib/WeBWorK/Constants.pm line 41.

—
Reply to this email directly or view it on GitHub.

[goehle]

Ok. I fixed that, and got proper logging happening to in my new setup. Now when I try to log in I get the following error from dancer

[21837] error @0.175645> [hit #17]request to POST /courses/TestCourse/login crashed: argument 1 must contain a user_id at /opt/webwork/webwork2-vanilla/webwork3/bin/app.pl line 72 in /usr/local/share/perl/5.14.2/Dancer/Handler.pm l. 98

[goehle]

I figured it out. FastCGI was set up to start a number of dancer instances to help serve requests faster. However, the current session setup that we have doesn't support running multiple instances of dancer off of the same session. There is a short term fix for this and a longer term one.

The short term fix is to set nproc in dispatcher.fcgi to 1, which will keep multiple instances from competing for the same session information.

The longer term solution (even for standalone dancer servers?) is to choose a different sesseion storage. Based off what I read here: http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Session.pm#SUPPORTED_ENGINES YAML and Session are both not really up for the job in a production machine. These more advanced session engines are harder to set up though.

In any case, I finally got dancer running. My suggestions now that I can see it are:

1. There isn't a link back to webwork2, that I can see. Maybe along the top bar, or in one of the dropdown menus in the top bar?
2. Authentication seems to be unstable for me. When I visit WeBWorK3 I have to log in, and when I go back to WeBWorK2 I have to log in to that again. Also, when I log into WeBWorK3 it doesn't always work. Sometimes the manager comes up, but sometimes it hangs and I get alot of

"error" : "The user is not defined. You may need to authenticate again"

from a lot of the ajax calls.

[pstaabp]

Thanks for tracking a lot of this down. I haven’t had a lot of time today to look at this. I’ll try to get my head around this in the next few days.

About the session, you can use the YAML one, look at the setup instruction on github for ww3 and sessions will persist. It’s not the best, but has been working for me this semester.

About the authentication, currently there’s a klugh between WW3 authentication and WW2. I posted recently to webwork-devel email list about changing this. We should switch to some more standard authentication and I don’t think it will be too difficult. However, if we switch to a new scheme, this won’t work with WW2, unless we switch WW2 over as well.

The error that you see is probably because FastCGI is spewing a lot of separate dancer instances and there’s a new session each time. Switching to YAML should fix that.

I still haven’t pulled your PR in to test, but will try tomorrow or Wednesday.

On Mar 24, 2014, at 8:20 PM, Geoff Goehle notifications@github.com wrote:

I figured it out. FastCGI was set up to start a number of dancer instances to help serve requests faster. However, the current session setup that we have doesn't support running multiple instances of dancer off of the same session. There is a short term fix for this and a longer term one.

The short term fix is to set nproc in dispatcher.fcgi to 1, which will keep multiple instances from competing for the same session information.

The longer term solution (even for standalone dancer servers?) is to choose a different sesseion storage. Based off what I read here: http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Session.pm#SUPPORTED_ENGINES YAML and Session are both not really up for the job in a production machine. These more advanced session engines are harder to set up though.

In any case, I finally got dancer running. My suggestions now that I can see it are:

1. There isn't a link back to webwork2, that I can see. Maybe along the top bar, or in one of the dropdown menus in the top bar?
2. Authentication seems to be unstable for me. When I visit WeBWorK3 I have to log in, and when I go back to WeBWorK2 I have to log in to that again. Also, when I log into WeBWorK3 it doesn't always work. Sometimes the manager comes up, but sometimes it hangs and I get alot of

"error" : "The user is not defined. You may need to authenticate again"

from a lot of the ajax calls.

—
Reply to this email directly or view it on GitHub.

[goehle]

We might be able to switch WW2 over, but we would have to make sure that it
maintains compatibility with all of the existing authentication methods.
Why can't we just use the existing ww2 session key to check if someone has
authenticated?

On Mon, Mar 24, 2014 at 8:50 PM, Peter Staab notifications@github.comwrote:

Thanks for tracking a lot of this down. I haven't had a lot of time today
to look at this. I'll try to get my head around this in the next few days.

About the session, you can use the YAML one, look at the setup instruction
on github for ww3 and sessions will persist. It's not the best, but has
been working for me this semester.

About the authentication, currently there's a klugh between WW3
authentication and WW2. I posted recently to webwork-devel email list about
changing this. We should switch to some more standard authentication and I
don't think it will be too difficult. However, if we switch to a new
scheme, this won't work with WW2, unless we switch WW2 over as well.

The error that you see is probably because FastCGI is spewing a lot of
separate dancer instances and there's a new session each time. Switching to
YAML should fix that.

I still haven't pulled your PR in to test, but will try tomorrow or
Wednesday.

On Mar 24, 2014, at 8:20 PM, Geoff Goehle notifications@github.com
wrote:

I figured it out. FastCGI was set up to start a number of dancer
instances to help serve requests faster. However, the current session setup
that we have doesn't support running multiple instances of dancer off of
the same session. There is a short term fix for this and a longer term one.

The short term fix is to set nproc in dispatcher.fcgi to 1, which will
keep multiple instances from competing for the same session information.

The longer term solution (even for standalone dancer servers?) is to
choose a different sesseion storage. Based off what I read here:
http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Session.pm#SUPPORTED_ENGINESYAML and Session are both not really up for the job in a production
machine. These more advanced session engines are harder to set up though.

In any case, I finally got dancer running. My suggestions now that I can
see it are:

1. There isn't a link back to webwork2, that I can see. Maybe along the
   top bar, or in one of the dropdown menus in the top bar?
2. Authentication seems to be unstable for me. When I visit WeBWorK3 I
   have to log in, and when I go back to WeBWorK2 I have to log in to that
   again. Also, when I log into WeBWorK3 it doesn't always work. Sometimes the
   manager comes up, but sometimes it hangs and I get alot of

"error" : "The user is not defined. You may need to authenticate again"

from a lot of the ajax calls.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38519845
.

[goehle]

I think you are right, but for some reason session YAML doesn't help.
(I've been using that since it is the default.)

Geoff.

On Mon, Mar 24, 2014 at 9:00 PM, goehle@gmail.com goehle@gmail.com wrote:

We might be able to switch WW2 over, but we would have to make sure that
it maintains compatibility with all of the existing authentication methods.
Why can't we just use the existing ww2 session key to check if someone has
authenticated?

On Mon, Mar 24, 2014 at 8:50 PM, Peter Staab notifications@github.comwrote:

Thanks for tracking a lot of this down. I haven't had a lot of time today
to look at this. I'll try to get my head around this in the next few days.

About the session, you can use the YAML one, look at the setup
instruction on github for ww3 and sessions will persist. It's not the best,
but has been working for me this semester.

About the authentication, currently there's a klugh between WW3
authentication and WW2. I posted recently to webwork-devel email list about
changing this. We should switch to some more standard authentication and I
don't think it will be too difficult. However, if we switch to a new
scheme, this won't work with WW2, unless we switch WW2 over as well.

The error that you see is probably because FastCGI is spewing a lot of
separate dancer instances and there's a new session each time. Switching to
YAML should fix that.

I still haven't pulled your PR in to test, but will try tomorrow or
Wednesday.

On Mar 24, 2014, at 8:20 PM, Geoff Goehle notifications@github.com
wrote:

I figured it out. FastCGI was set up to start a number of dancer
instances to help serve requests faster. However, the current session setup
that we have doesn't support running multiple instances of dancer off of
the same session. There is a short term fix for this and a longer term one.

The short term fix is to set nproc in dispatcher.fcgi to 1, which will
keep multiple instances from competing for the same session information.

The longer term solution (even for standalone dancer servers?) is to
choose a different sesseion storage. Based off what I read here:
http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Session.pm#SUPPORTED_ENGINESYAML and Session are both not really up for the job in a production
machine. These more advanced session engines are harder to set up though.

In any case, I finally got dancer running. My suggestions now that I
can see it are:

1. There isn't a link back to webwork2, that I can see. Maybe along the
   top bar, or in one of the dropdown menus in the top bar?
2. Authentication seems to be unstable for me. When I visit WeBWorK3 I
   have to log in, and when I go back to WeBWorK2 I have to log in to that
   again. Also, when I log into WeBWorK3 it doesn't always work. Sometimes the
   manager comes up, but sometimes it hangs and I get alot of

"error" : "The user is not defined. You may need to authenticate again"

from a lot of the ajax calls.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38519845
.

[goehle]

I was thinking about authentication. Are you still planning on using wholesale ContentGenerator pages to fill in gaps in the new interface? If so, then you will have to keep the webwork2 session key up to date when using webwork3 anyway.

[pstaabp]

Geoff,

I think the only views I haven’t done yet are the editor, email and scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session information. Obviously it’s not bulletproof yet, but seems to work okay.

I was thinking if using a different authenticaiton/session for ww3 that streamlines a lot, perhaps we can back port this to ww2 to keep a common codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com wrote:

I was thinking about authentication. Are you still planning on using wholesale ContentGenerator pages to fill in gaps in the new interface? If so, then you will have to keep the webwork2 session key up to date when using webwork3 anyway.

—
Reply to this email directly or view it on GitHub.

[pstaabp]

To recap this situation,

1. I think we’re taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn’t persisting.

What’s your current thinking on #2? We could go back to proxy pass and force dancer to start in the apache startup script. Alternatively, we could come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com wrote:

Geoff,

I think the only views I haven’t done yet are the editor, email and scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session information. Obviously it’s not bulletproof yet, but seems to work okay.

I was thinking if using a different authenticaiton/session for ww3 that streamlines a lot, perhaps we can back port this to ww2 to keep a common codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com wrote:

I was thinking about authentication. Are you still planning on using wholesale ContentGenerator pages to fill in gaps in the new interface? If so, then you will have to keep the webwork2 session key up to date when using webwork3 anyway.

—
Reply to this email directly or view it on GitHub.

[goehle]

I have to admit I'm a bit stumped. There are a lot of configuration
options for FCGI. It can be set up in static mode to start dancer when
apache starts, or it can be set up to start a single session of dancer when
needed.
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.
So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It particular,
its not clear to me why the session stuff is failing. I also think this
solution has potential:
http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_Plackbut
when I implement it I get the unhelpful dancer message "an internal
error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for the next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab notifications@github.comwrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't persisting.

What's your current thinking on #2? We could go back to proxy pass and
force dancer to start in the apache startup script. Alternatively, we could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com wrote:

Geoff,

I think the only views I haven't done yet are the editor, email and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session
information. Obviously it's not bulletproof yet, but seems to work okay.

I was thinking if using a different authenticaiton/session for ww3 that
streamlines a lot, perhaps we can back port this to ww2 to keep a common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com
wrote:

I was thinking about authentication. Are you still planning on using
wholesale ContentGenerator pages to fill in gaps in the new interface? If
so, then you will have to keep the webwork2 session key up to date when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38634796
.

[goehle]

As a follow up, I was reading up on Session::YAML and it is specifically
built to handle multiple server instances running. It puts a lock on the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com wrote:

I have to admit I'm a bit stumped. There are a lot of configuration
options for FCGI. It can be set up in static mode to start dancer when
apache starts, or it can be set up to start a single session of dancer when
needed.
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.
So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It particular,
its not clear to me why the session stuff is failing. I also think this
solution has potential:
http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_Plackbut when I implement it I get the unhelpful dancer message "an internal
error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for the next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab notifications@github.comwrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't persisting.

What's your current thinking on #2? We could go back to proxy pass and
force dancer to start in the apache startup script. Alternatively, we could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com wrote:

Geoff,

I think the only views I haven't done yet are the editor, email and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session
information. Obviously it's not bulletproof yet, but seems to work okay.

I was thinking if using a different authenticaiton/session for ww3 that
streamlines a lot, perhaps we can back port this to ww2 to keep a common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com
wrote:

I was thinking about authentication. Are you still planning on using
wholesale ContentGenerator pages to fill in gaps in the new interface? If
so, then you will have to keep the webwork2 session key up to date when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38634796
.

[pstaabp]

I’ve been using YAML on our production machine all semester without trouble. I’m using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com wrote:

As a follow up, I was reading up on Session::YAML and it is specifically
built to handle multiple server instances running. It puts a lock on the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com wrote:

I have to admit I'm a bit stumped. There are a lot of configuration
options for FCGI. It can be set up in static mode to start dancer when
apache starts, or it can be set up to start a single session of dancer when
needed.
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.
So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It particular,
its not clear to me why the session stuff is failing. I also think this
solution has potential:
http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_Plackbut when I implement it I get the unhelpful dancer message "an internal
error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for the next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab notifications@github.comwrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't persisting.

What's your current thinking on #2? We could go back to proxy pass and
force dancer to start in the apache startup script. Alternatively, we could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com wrote:

Geoff,

I think the only views I haven't done yet are the editor, email and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session
information. Obviously it's not bulletproof yet, but seems to work okay.

I was thinking if using a different authenticaiton/session for ww3 that
streamlines a lot, perhaps we can back port this to ww2 to keep a common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com
wrote:

I was thinking about authentication. Are you still planning on using
wholesale ContentGenerator pages to fill in gaps in the new interface? If
so, then you will have to keep the webwork2 session key up to date when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38634796
.

—
Reply to this email directly or view it on GitHub.

[goehle]

Are you using starman to run dancer? That creates multiple forks to handle
requests as well, so it would potentially cause the same problem?

On Tue, Mar 25, 2014 at 8:56 PM, Peter Staab notifications@github.comwrote:

I've been using YAML on our production machine all semester without
trouble. I'm using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com
wrote:

As a follow up, I was reading up on Session::YAML and it is specifically
built to handle multiple server instances running. It puts a lock on the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com
wrote:

I have to admit I'm a bit stumped. There are a lot of configuration
options for FCGI. It can be set up in static mode to start dancer when
apache starts, or it can be set up to start a single session of dancer
when
needed.

http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.

So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It
particular,
its not clear to me why the session stuff is failing. I also think
this
solution has potential:

http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_Plackbutwhen I implement it I get the unhelpful dancer message "an internal
error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for the
next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab notifications@github.comwrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't
   persisting.

What's your current thinking on #2? We could go back to proxy pass
and
force dancer to start in the apache startup script. Alternatively, we
could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com
wrote:

Geoff,

I think the only views I haven't done yet are the editor, email and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session
information. Obviously it's not bulletproof yet, but seems to work
okay.

I was thinking if using a different authenticaiton/session for ww3
that
streamlines a lot, perhaps we can back port this to ww2 to keep a
common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com

wrote:

I was thinking about authentication. Are you still planning on
using
wholesale ContentGenerator pages to fill in gaps in the new
interface? If
so, then you will have to keep the webwork2 session key up to date
when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38634796>
.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38639602
.

[pstaabp]

I believe so. I’m not in a place that I can check our server, but I believe I’m using Starman.

On Mar 25, 2014, at 8:58 PM, Geoff Goehle notifications@github.com wrote:

Are you using starman to run dancer? That creates multiple forks to handle
requests as well, so it would potentially cause the same problem?

On Tue, Mar 25, 2014 at 8:56 PM, Peter Staab notifications@github.comwrote:

I've been using YAML on our production machine all semester without
trouble. I'm using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com
wrote:

As a follow up, I was reading up on Session::YAML and it is specifically
built to handle multiple server instances running. It puts a lock on the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com
wrote:

I have to admit I'm a bit stumped. There are a lot of configuration
options for FCGI. It can be set up in static mode to start dancer when
apache starts, or it can be set up to start a single session of dancer
when
needed.

http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.

So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It
particular,
its not clear to me why the session stuff is failing. I also think
this
solution has potential:

http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_Plackbutwhen I implement it I get the unhelpful dancer message "an internal
error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for the
next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab notifications@github.comwrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't
   persisting.

What's your current thinking on #2? We could go back to proxy pass
and
force dancer to start in the apache startup script. Alternatively, we
could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com
wrote:

Geoff,

I think the only views I haven't done yet are the editor, email and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2 session
information. Obviously it's not bulletproof yet, but seems to work
okay.

I was thinking if using a different authenticaiton/session for ww3
that
streamlines a lot, perhaps we can back port this to ww2 to keep a
common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle notifications@github.com

wrote:

I was thinking about authentication. Are you still planning on
using
wholesale ContentGenerator pages to fill in gaps in the new
interface? If
so, then you will have to keep the webwork2 session key up to date
when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38634796>
.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38639602
.

—
Reply to this email directly or view it on GitHub.

[goehle]

So like I said, a mystery. Its not FCGI, because that is getting to the
deployment script. It might be PSGI and Plack, but that's pretty standard
stuff too. I should try on a different server and see what happens.

On Tue, Mar 25, 2014 at 8:59 PM, Peter Staab notifications@github.comwrote:

I believe so. I'm not in a place that I can check our server, but I
believe I'm using Starman.

On Mar 25, 2014, at 8:58 PM, Geoff Goehle notifications@github.com
wrote:

Are you using starman to run dancer? That creates multiple forks to
handle
requests as well, so it would potentially cause the same problem?

On Tue, Mar 25, 2014 at 8:56 PM, Peter Staab notifications@github.comwrote:

I've been using YAML on our production machine all semester without
trouble. I'm using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com
wrote:

As a follow up, I was reading up on Session::YAML and it is
specifically
built to handle multiple server instances running. It puts a lock on
the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you
getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com

wrote:

I have to admit I'm a bit stumped. There are a lot of
configuration
options for FCGI. It can be set up in static mode to start dancer
when
apache starts, or it can be set up to start a single session of
dancer
when
needed.

http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.

So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It
particular,
its not clear to me why the session stuff is failing. I also think
this
solution has potential:

http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_PlackbutwhenI implement it I get the unhelpful dancer message "an internal

error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for
the
next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab <
notifications@github.com>wrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't
   persisting.

What's your current thinking on #2? We could go back to proxy
pass
and
force dancer to start in the apache startup script.
Alternatively, we
could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com
wrote:

Geoff,

I think the only views I haven't done yet are the editor, email
and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2
session
information. Obviously it's not bulletproof yet, but seems to
work
okay.

I was thinking if using a different authenticaiton/session for
ww3
that
streamlines a lot, perhaps we can back port this to ww2 to keep a
common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle <
notifications@github.com>

wrote:

I was thinking about authentication. Are you still planning on
using
wholesale ContentGenerator pages to fill in gaps in the new
interface? If
so, then you will have to keep the webwork2 session key up to
date
when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38634796>

.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38639602>
.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38639749
.

[pstaabp]

I'll see if I can get it set up on my server tomorrow.

On Mar 25, 2014, at 9:00 PM, Geoff Goehle notifications@github.com wrote:

So like I said, a mystery. Its not FCGI, because that is getting to the
deployment script. It might be PSGI and Plack, but that's pretty standard
stuff too. I should try on a different server and see what happens.

On Tue, Mar 25, 2014 at 8:59 PM, Peter Staab notifications@github.comwrote:

I believe so. I'm not in a place that I can check our server, but I
believe I'm using Starman.

On Mar 25, 2014, at 8:58 PM, Geoff Goehle notifications@github.com
wrote:

Are you using starman to run dancer? That creates multiple forks to
handle
requests as well, so it would potentially cause the same problem?

On Tue, Mar 25, 2014 at 8:56 PM, Peter Staab notifications@github.comwrote:

I've been using YAML on our production machine all semester without
trouble. I'm using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com
wrote:

As a follow up, I was reading up on Session::YAML and it is
specifically
built to handle multiple server instances running. It puts a lock on
the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you
getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com

wrote:

I have to admit I'm a bit stumped. There are a lot of
configuration
options for FCGI. It can be set up in static mode to start dancer
when
apache starts, or it can be set up to start a single session of
dancer
when
needed.

http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.

So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It
particular,
its not clear to me why the session stuff is failing. I also think
this
solution has potential:

http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_PlackbutwhenI implement it I get the unhelpful dancer message "an internal

error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for
the
next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab <
notifications@github.com>wrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't
   persisting.

What's your current thinking on #2? We could go back to proxy
pass
and
force dancer to start in the apache startup script.
Alternatively, we
could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com
wrote:

Geoff,

I think the only views I haven't done yet are the editor, email
and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2
session
information. Obviously it's not bulletproof yet, but seems to
work
okay.

I was thinking if using a different authenticaiton/session for
ww3
that
streamlines a lot, perhaps we can back port this to ww2 to keep a
common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle <
notifications@github.com>

wrote:

I was thinking about authentication. Are you still planning on
using
wholesale ContentGenerator pages to fill in gaps in the new
interface? If
so, then you will have to keep the webwork2 session key up to
date
when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38634796>

.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38639602>
.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38639749
.

—
Reply to this email directly or view it on GitHub.

[pstaabp]

I pulled in your code and have been playing with it. I think I have fixed the problem with the sessions and YAML. I just pushed a commit that fixes things.

However, I haven’t gotten the FCGI stuff working. I’m getting the following error in the apache error log:

[Wed Mar 26 11:41:15 2014] [error] [client ::1] File does not exist: /Volumes/WW_test/opt/webwork/webwork2/webwork3/public/dispatch.fcgi/courses/maa101/manager, referer: http://localhost/webwork2/maa101/

Have you seen this? It seems like it should work in that I think the url in dispatch.fcgi should pass to the dancer app.

On Mar 25, 2014, at 9:07 PM, Peter Staab peter.staab@gmail.com wrote:

I'll see if I can get it set up on my server tomorrow.

On Mar 25, 2014, at 9:00 PM, Geoff Goehle notifications@github.com wrote:

So like I said, a mystery. Its not FCGI, because that is getting to the
deployment script. It might be PSGI and Plack, but that's pretty standard
stuff too. I should try on a different server and see what happens.

On Tue, Mar 25, 2014 at 8:59 PM, Peter Staab notifications@github.comwrote:

I believe so. I'm not in a place that I can check our server, but I
believe I'm using Starman.

On Mar 25, 2014, at 8:58 PM, Geoff Goehle notifications@github.com
wrote:

Are you using starman to run dancer? That creates multiple forks to
handle
requests as well, so it would potentially cause the same problem?

On Tue, Mar 25, 2014 at 8:56 PM, Peter Staab notifications@github.comwrote:

I've been using YAML on our production machine all semester without
trouble. I'm using proxy pass (not the FCGI stuff).

On Mar 25, 2014, at 8:54 PM, Geoff Goehle notifications@github.com
wrote:

As a follow up, I was reading up on Session::YAML and it is
specifically
built to handle multiple server instances running. It puts a lock on
the
session file whenever it writes to it, and does all of the other
appropriate things. Like I said, its a bit of a mystery. Are you
getting
the same trouble on your machine?

Geoff.

On Tue, Mar 25, 2014 at 8:21 PM, goehle@gmail.com goehle@gmail.com

wrote:

I have to admit I'm a bit stumped. There are a lot of
configuration
options for FCGI. It can be set up in static mode to start dancer
when
apache starts, or it can be set up to start a single session of
dancer
when
needed.

http://search.cpan.org/~mramberg/Catalyst-Runtime-5.80012/lib/Catalyst/Engine/FastCGI.pm#Static_mode.

So basically it should be able to provide some sort of acceptable
solution, but I haven't been able to iron out all the bugs. It
particular,
its not clear to me why the session stuff is failing. I also think
this
solution has potential:

http://search.cpan.org/~yanick/Dancer-1.3121/lib/Dancer/Deployment.pod#Running_from_Apache_with_PlackbutwhenI implement it I get the unhelpful dancer message "an internal

error has occured" and can't find any log files to shed insight.
Unfortunately I've got grading and other things on my plate for
the
next
few days.

On Tue, Mar 25, 2014 at 7:38 PM, Peter Staab <
notifications@github.com>wrote:

To recap this situation,

1. I think we're taking care of the js library problem.
2. Geoff, you have a new way to deploy, but the session isn't
   persisting.

What's your current thinking on #2? We could go back to proxy
pass
and
force dancer to start in the apache startup script.
Alternatively, we
could
come up with a more robust session storage solution.

On Mar 25, 2014, at 9:39 AM, Peter Staab peter.staab@gmail.com
wrote:

Geoff,

I think the only views I haven't done yet are the editor, email
and
scoring tools. I might be able to get these done by May.

I think right now, my plans are to keep using the old ww2
session
information. Obviously it's not bulletproof yet, but seems to
work
okay.

I was thinking if using a different authenticaiton/session for
ww3
that
streamlines a lot, perhaps we can back port this to ww2 to keep a
common
codebase for this.

Peter

On Mar 25, 2014, at 9:01 AM, Geoff Goehle <
notifications@github.com>

wrote:

I was thinking about authentication. Are you still planning on
using
wholesale ContentGenerator pages to fill in gaps in the new
interface? If
so, then you will have to keep the webwork2 session key up to
date
when
using webwork3 anyway.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38634796>

.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub<
https://github.com/openwebwork/webwork2/pull/347#issuecomment-38639602>
.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//pull/347#issuecomment-38639749
.

—
Reply to this email directly or view it on GitHub.

[goehle]

I haven't gotten that error. Is the public directory (and dispatch.fcgi) owned and readable by wwdata?

[pstaabp]

I have it set up as it is in the _www group and is readable by the group. I’m getting the js and css files. For example:

http://localhost/webwork3/js/bower_components/requirejs/require.js

is returned the require.js file correctly, so I think the part of the apache config file starting at line 158 is working:

my $webwork3_htdocs_dir = $webwork_dir."/webwork3/public";

Set up /webwork3 to point to the dispatch cgi

push @alias, [ "/webwork3/js" => "$webwork3_htdocs_dir/js”];

and if I do http://localhost/webwork3

I get the dispatch.fcgi source, but anything underneath webwork3 (except in the js css or images directory) gives me file not found errors, so it doesn’t appear that dispatch.fcgi is running.

On Mar 26, 2014, at 12:08 PM, Geoff Goehle notifications@github.com wrote:

I haven't gotten that error. Is the public directory (and dispatch.fcgi) owned and readable by wwdata?

—
Reply to this email directly or view it on GitHub.

[pstaabp]

My development server doesn’t have fastcgi installed, so that was what was going on. I switched to CGI and have some errors due to the fact that my perl is not located in the standard place.

On Mar 26, 2014, at 12:19 PM, Peter Staab peter.staab@gmail.com wrote:

I have it set up as it is in the _www group and is readable by the group. I’m getting the js and css files. For example:

http://localhost/webwork3/js/bower_components/requirejs/require.js

is returned the require.js file correctly, so I think the part of the apache config file starting at line 158 is working:

my $webwork3_htdocs_dir = $webwork_dir."/webwork3/public";

Set up /webwork3 to point to the dispatch cgi

push @alias, [ "/webwork3/js" => "$webwork3_htdocs_dir/js”];

and if I do http://localhost/webwork3

I get the dispatch.fcgi source, but anything underneath webwork3 (except in the js css or images directory) gives me file not found errors, so it doesn’t appear that dispatch.fcgi is running.

On Mar 26, 2014, at 12:08 PM, Geoff Goehle notifications@github.com wrote:

I haven't gotten that error. Is the public directory (and dispatch.fcgi) owned and readable by wwdata?

—
Reply to this email directly or view it on GitHub.

[pstaabp]

I’m getting a number of errors based on paths. I’m not going to try to track these down on my develop machine. Let me know if the last commit fixes the session errors, and then if you’re satisfied, let’s going with this. I can also do some more testing on my production machine.

On a related note: I was reading about starting up dancer as a service and will try to put that code into webwork-apache2.config so starts automatically. This will give another option to run dancer. We can then test both to see a direction we want to go.

On Mar 26, 2014, at 12:54 PM, Peter Staab peter.staab@gmail.com wrote:

My development server doesn’t have fastcgi installed, so that was what was going on. I switched to CGI and have some errors due to the fact that my perl is not located in the standard place.

On Mar 26, 2014, at 12:19 PM, Peter Staab peter.staab@gmail.com wrote:

I have it set up as it is in the _www group and is readable by the group. I’m getting the js and css files. For example:

http://localhost/webwork3/js/bower_components/requirejs/require.js

is returned the require.js file correctly, so I think the part of the apache config file starting at line 158 is working:

my $webwork3_htdocs_dir = $webwork_dir."/webwork3/public";

Set up /webwork3 to point to the dispatch cgi

push @alias, [ "/webwork3/js" => "$webwork3_htdocs_dir/js”];

and if I do http://localhost/webwork3

I get the dispatch.fcgi source, but anything underneath webwork3 (except in the js css or images directory) gives me file not found errors, so it doesn’t appear that dispatch.fcgi is running.

On Mar 26, 2014, at 12:08 PM, Geoff Goehle notifications@github.com wrote:

I haven't gotten that error. Is the public directory (and dispatch.fcgi) owned and readable by wwdata?

—
Reply to this email directly or view it on GitHub.

[pstaabp]

Just tested on another machine and I’m getting dancer to work via FCGI and am not seeing an session errors. When you get a chance, pull the latest code off of pstaabp/ww3-features/redirect and let me know.

On Mar 26, 2014, at 1:09 PM, Peter Staab peter.staab@gmail.com wrote:

I’m getting a number of errors based on paths. I’m not going to try to track these down on my develop machine. Let me know if the last commit fixes the session errors, and then if you’re satisfied, let’s going with this. I can also do some more testing on my production machine.

On a related note: I was reading about starting up dancer as a service and will try to put that code into webwork-apache2.config so starts automatically. This will give another option to run dancer. We can then test both to see a direction we want to go.

On Mar 26, 2014, at 12:54 PM, Peter Staab peter.staab@gmail.com wrote:

My development server doesn’t have fastcgi installed, so that was what was going on. I switched to CGI and have some errors due to the fact that my perl is not located in the standard place.

On Mar 26, 2014, at 12:19 PM, Peter Staab peter.staab@gmail.com wrote:

I have it set up as it is in the _www group and is readable by the group. I’m getting the js and css files. For example:

http://localhost/webwork3/js/bower_components/requirejs/require.js

is returned the require.js file correctly, so I think the part of the apache config file starting at line 158 is working:

my $webwork3_htdocs_dir = $webwork_dir."/webwork3/public";

Set up /webwork3 to point to the dispatch cgi

push @alias, [ "/webwork3/js" => "$webwork3_htdocs_dir/js”];

and if I do http://localhost/webwork3

I get the dispatch.fcgi source, but anything underneath webwork3 (except in the js css or images directory) gives me file not found errors, so it doesn’t appear that dispatch.fcgi is running.

On Mar 26, 2014, at 12:08 PM, Geoff Goehle notifications@github.com wrote:

I haven't gotten that error. Is the public directory (and dispatch.fcgi) owned and readable by wwdata?

—
Reply to this email directly or view it on GitHub.

[goehle]

Will do. (It might be later tonight or tomorrow.) While you are messing around with it, try doing some requests and keeping an eye on top. You should see just just one perl process (and possibly a bunch of apache stuff) that persists until its no longer needed. You might also test changing nproc in dispatch.fcgi to something larger and see if that does anything. Ideally we would like to make more efficient use of servers by letting dancer use more cores.

[pstaabp]

No problem on the timing. I have a feeling we have a handle on this problem now and it will be good to move on.

I’ll try looking a top while I’m doing stuff. I guess the ideal number of processes will probably be server dependent. Do you know if there is a way in unix to determine the processor running (or number of cores)? My server is a virtual server on our campus, so I have no idea what it’s actually running, but I could ask I guess.

On Mar 26, 2014, at 2:10 PM, Geoff Goehle notifications@github.com wrote:

Will do. (It might be later tonight or tomorrow.) While you are messing around with it, try doing some requests and keeping an eye on top. You should see just just one perl process (and possibly a bunch of apache stuff) that persists until its no longer needed. You might also test changing nproc in dispatch.fcgi to something larger and see if that does anything. Ideally we would like to make more efficient use of servers by letting dancer use more cores.

—
Reply to this email directly or view it on GitHub.

[goehle]

nproc prints the number of processors.

[pstaabp]

Thanks. One other thing I meant to mention is that if you change dates on the calendar, you’ll probably get a

Uncaught TypeError: Cannot read property 'options' of undefined

This comes from jquery-ui and they have an old version of jquery-ui via bower. I’ve submitted a bug report through them, but they haven’t updated this. I can tell where the error occurs and the code is changed in the newer version, so if their repository gets updated then I’m guessing this will be cleaned up.

On Mar 26, 2014, at 2:15 PM, Geoff Goehle notifications@github.com wrote:

nproc prints the number of processors.

—
Reply to this email directly or view it on GitHub.

[goehle]

Ok. I've tested it out on my machine and things work, although I made a dumb mistake which I mention below. The only suggestions I have that actually relate to this pull request are

1. In both webwork.apache2-config.dist and webwork.apache2.4-config.dist right around line 160 it should be $Directory{"$webwork3_htdocs_dir"} = { (The $ is missing.) Apache2 doesn't care but Apache2.4 does.
2. There should be a link back to webwork2 somewhere.
3. Eventually we need fix it so that using webwork3 doesn't log you out of webwork2.

I feel like 1 and 2 should be taken care of, and 3 can wait for a future pull.

Just for record keeping. I've tested on two machines and on both the process of getting it running was:

1. Install fastcgi and Perl::Plack
2. Copy over/update webwork2.apache2.config, localOverrides.config, and webwork3.config

Helpful things

1. Try to start dancer manually to make sure you aren't missing anything
2. Change logging to file in webwork3.config and make a wwdata rw able folder called logs in webwork3

[pstaabp]

My colleague noticed that I broke the link the the current library browser, but have since fixed that.

1. Had a fix for this already. Hadn’t pushed it yet.
2. Just committed a link back to ww2.
3. I went ahead and took care of this. It was simply just a matter of updating the timestamp in the key database.

Thanks for the instructions. I’ll update the wiki for this current method. Also, I’ve been talking with Jason A about updating the script to include ww3. This will help.

On Mar 26, 2014, at 5:09 PM, Geoff Goehle notifications@github.com wrote:

Ok. I've tested it out on my machine and things work, although I made a dumb mistake which I mention below. The only suggestions I have that actually relate to this pull request are

1. In both webwork.apache2-config.dist and webwork.apache2.4-config.dist right around line 160 it should be $Directory{"$webwork3_htdocs_dir"} = { (The $ is missing.) Apache2 doesn't care but Apache2.4 does.
2. There should be a link back to webwork2 somewhere.
3. Eventually we need fix it so that using webwork3 doesn't log you out of webwork2.

I feel like 1 and 2 should be taken care of, and 3 can wait for a future pull.

Just for record keeping. I've tested on two machines and on both the process of getting it running was:

1. Install fastcgi and Perl::Plack

2. Copy over/update webwork2.apache2.config, localOverrides.config, and webwork3.config

Helpful things

1. Try to start dancer manually to make sure you aren't missing anything
2. Change logging to file in webwork3.config and make a wwdata rw able folder called logs in webwork3

—
Reply to this email directly or view it on GitHub.

[goehle]

Ok. I tested everything out. The links work and the login issues are more or less gone. I think its time to pull this.