Perl 6 - the future is here, just unevenly distributed

IRC log for #webwork, 2013-12-20

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
14:02 goehle joined #webwork
15:48 rbeezer joined #webwork
17:39 aubreyja joined #webwork
17:39 aubreyja hey goehle
18:58 goehle hey aubreyja
19:00 goehle i'm heading out
19:00 goehle shoot me an email if its important :)
19:00 goehle left #webwork
19:48 aubreyja mgage - around?
19:49 mgage yep -- grading (sign)
19:49 mgage sigh
19:49 aubreyja :)
19:50 aubreyja Quick distraction - I just installed 2.8 on a fresh Debian 7.3 and it looks like your code for compiling color.c for Chromatic.pm is running into problems.
19:50 aubreyja My guess is that the web server doesn't have permissions to write to pg/lib...
19:50 mgage permission problems?
19:50 aubreyja yeah
19:51 mgage there is a script in bin that John Jones wrote that should correct that if you run it
19:51 aubreyja correct the permissions? - lemme check
19:51 mgage setfilepermissions
19:52 mgage you might want to add that or its contents to your install script
19:53 aubreyja I see it…
19:54 mgage I just made a note to add that to the release notes under "what could possibly go wrong?" :-)
19:54 aubreyja ok, he uses $ce->{server_userID} and $ce->{server_userGroup} in that script….
19:55 aubreyja now, in the standard instructions we have a new user created called wwadmin and new group called wwadmin and add the web server to that group
19:55 aubreyja then the proper dirs are writeable by members of that group.
19:56 aubreyja this makes those dirs writable by the web server, but not that group...
19:57 mgage that is actually the way I've set things up here    wwhttpd is the server and the group is wwadmin  -- I never quite understood why Arnie set it up differently but it might have been something to do with different conventions on ubuntu and freebsd
19:57 aubreyja of course, everything works properly (the wwadmin layer isn't necessary) - it's a convenience for the ww administrator and a security precaution for the system administrator
19:59 aubreyja in any case, my point is that running this script will change the ownership of things to something other than what is given in the install instructions.
19:59 mgage what is the convenience?   I've found it handy not to have all the power of wwhttpd without using sudo (I'm in wwadmin) -- reminds me about getting permissions right for certain files I change by hand
20:00 mgage that's a fair point.
20:00 aubreyja It's a convenience because as the wwadmin user you can change ww files without using sudo
20:00 mgage There has been some cognitive dissonance about what the "standard" set up should be -- suspect jj uses the same scheme we use here.
20:01 aubreyja (which may not be a good power to have, but if your sysadmin doesn't want to give you full sudo powers this gives most of what you need)
20:01 aubreyja yeah
20:01 aubreyja my install script gives an option to create wwadmin and does the right thing in either case.
20:02 mgage that seems a reasonable argument to me as well -- I've preferred to restrict the power in my use case.
20:03 mgage you should talk to jj about it but I don't think he would object to tweaking his script -- and I agree that consistency is a particularly strong argument.
20:03 aubreyja yeah, I'll do that
20:03 mgage I think there is an advantage to leaving this as a separate script outside your install script because people might like to update file permissions without doing a fresh install
20:04 mgage just call it from your script
20:04 mgage I occasionally make temporary changes in directory permissions if I'm doing a lot of changes and it's handy to have a fool proof way to get them back to normal.
20:04 aubreyja yeah, I agree with that (having a separate script)
20:06 aubreyja In the long run, I think it would be nice to head towards Djun's suggestion of having one script that you pass options to that does "install" or "addcourse" or "fix perms" etc...
20:08 mgage yeah that sounds right -- I've seen lots of unix scripts of that type -- e.g. Makefiles -- and they are probably easier to maintain.
20:14 aubreyja also, philosophically, I think it would be better just to have a script that compiles and installs color.c rather than having to create a directory under pg/lib that is writable by the web server.  After all, people will have to run the fix permissions script (as root) to get that code in Chromatic.pm to work anyway.  So, they could just as well run a script (as root) which compiles and installs color.c and keeps all dirs under pg
20:14 aubreyja non-web-writable….
20:17 mgage well -- at Vancouver the NAU people suggested automatic compilation because people who tried their homework problems assumed the problems were bad rather than that the set up was bad.
20:18 mgage I did try to make the error message when a compile failed fairly helpful.  So that the professor using the problem could tell an IT person exactly what was wrong.
20:19 mgage I don't object to having a script insure that color.c is compiled when the course is set up   particularly since I think Chromatic is now a part of the standard ww set up -- before it was pretty experimental since not many were using the graph theory problems.
20:22 aubreyja yeah, I'm suggesting we make it part of the standard install instructions to run an install_chromatic script, rather than not making that part of the instructions.  Then people shouldn't run into the problem at all.
20:23 aubreyja I guess I'm saying that I think
20:23 aubreyja https://github.com/aubreyja/ww_install/blob/master/extra/install_chromatic.pl
20:23 aubreyja is a better solution than
20:23 aubreyja setfilepermissions
20:23 mgage ok
20:24 mgage setfilepermissions does a bunch of other things as well

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary