
<html><head><style> body {height: 100%; color:#000000; font-size:12pt; font-family:arial, helvetica, sans-serif;}</style></head><body><div>Sweet!<br></div><div>Thanks for this.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>R<br data-mce-bogus="1"></div><div><br></div><div>----- Original Message -----<br>From: Stuart Raeburn <raeburn@msu.edu><br>To: lon-capa-admin@mail.lon-capa.org<br>Sent: Mon, 28 Aug 2017 05:56:34 -0700 (PDT)<br>Subject: Re: [LON-CAPA-admin] Republish Course Content?<br></div><div><br></div><div>Ray,<br></div><div><br></div><div>Currently, neither of the two utilities: 'Verify Content' or <br>'Check/Set Resource Versions' (accessible via the Course Editor), when <br>used on a library server will push the updated resources from the <br>library server to a domain's access servers.<br></div><div><br></div><div>Equally, neither utility will pull updated resources from a library <br>server to access server when used on an access server, if the resource <br>was previously replicated.<br></div><div><br></div><div>Using Check/Set Resource Versions with display of: "All Resources <br>(possibly large output)" will retrieve versioned metadata files, but <br>will not pull unversioned metadata and/or resource files, if the <br>resource was previously replicated.<br></div><div><br></div><div>Anyway, I have now added some code so that "Verify Content" includes <br>an option to check if files replicated from elsewhere are outdated <br>(because the "update" transaction was delayed).<br></div><div><br></div><div>So in the future, a Course Coordinator could visit each access server <br>in turn (e.g., using /adm/switchserver to hop from one access server <br>to the next) and use Verify Content to pull updates of any outdated <br>resources from that resource's homeserver.<br></div><div><br></div><div>The tactic (currently available) to a Domain Coordinator of using Main <br>Menu > "Status of domain servers" > "Update Connections and Refresh <br>Status Information" on a library server to complete delayed <br>transactions will continue to be available.<br></div><div><br></div><div>The nightly run of loncron at 5:10 am local time on each server, also <br>automatically attempts to complete delayed transactions, so a user <br>with command line access and rights to become the www user, could also <br>run /home/httpd/perl/loncron from the command line on a library server <br>to propagate delayed updates.<br></div><div><br></div><div><br>Stuart Raeburn<br>LON-CAPA Academic Consortium<br></div><div><br></div><div><br>> Hmm.<br>> I don't truly know, but I am wondering if in the "Course Editor" you <br>> select the tab 'Content Utilities" and try the 'Adminstration' <br>> option 'Verify Content' and/or the option 'Check/Set Resource <br>> Versions'.<br>> ----- Original Message -----<br>> From: Young, Joyce E <young257@purdue.edu><br>> To: LON-CAPA-admin@mail.lon-capa.org<br>> Cc: Huckleberry, David W <dhuckleb@purdue.edu>, <br>> 'elt-dev@lists.purdue.edu' <elt-dev@lists.purdue.edu><br>> Sent: Fri, 25 Aug 2017 08:01:30 -0700 (PDT)<br>> Subject: [LON-CAPA-admin] Republish Course Content?<br>><br>> All, We had an incident where our library server was <br>> not communicating with our application servers for a time. Users <br>> were all logging into the library server and all seemed fine until <br>> the library server got overloaded, we saw<br>> what was happening, and got all servers communicating again. <br>> During the time when activity was only happening on the <br>> library server, some course problems were edited and republished. <br>> When we re-connected all servers and students were then re-routed to <br>> the application servers, we learned<br>> that the students were not seeing the updated problem versions. The <br>> updated problems were not pushed to the application servers as they <br>> would have been during normal circumstances. We found <br>> that if the problems were re-published, once all servers were <br>> connected, then the version push happened as it should. To rectify <br>> our issue, we went in and manually republished any problems that <br>> were edited during<br>> the ?dark? period. Is there an easier way to handle <br>> this situation if it should happen again? Is there a way to <br>> ?refresh? a whole course, re-publishing any content currently used <br>> in that course? Could we have just copied the affected .problem<br>> and .problem.meta files from the library server over to the <br>> application servers? The authorspace directories that <br>> we pull from have unpublished resources in them (works in progress), <br>> so republishing at the directory level wouldn?t work for us. Any <br>> advice or ideas would be appreciated. We don?t expect<br>> this to happen again, but it would be nice to have a plan in place <br>> in case it does. <br>> Thanks, <br>> <br>> Joyce Young Joyce Young<br>><br>> Programmer/Analyst<br>><br>> ITAS - Student Systems Competency Center<br>><br>> Purdue University<br>><br>> 3495 Kent Avenue, Suite 100<br>><br>> West Lafayette, IN 47906<br>><br>> Phone: (765) 427-6340<br>><br>> Fax: (765) 464-2233<br>><br>> Campus Mail: ROSSyoung257@purdue.edu<br>><br>> --<br>> Raymond J. Batchelor, PhD.<br>> Department of Chemistry<br>> Simon Fraser University<br>><br>> Phone: 778-782-5635<br></div><div><br></div><div><br></div><div><br></div><div>_______________________________________________<br>LON-CAPA-admin mailing list<br>LON-CAPA-admin@mail.lon-capa.org<br>http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin<br></div><div><br></div><div>-- <br>Raymond J. Batchelor, PhD.<br>Department of Chemistry<br>Simon Fraser University<br></div><div><br></div><div>Phone: 778-782-5635</div></body></html>