[LON-CAPA-admin] Unable to see resources from uiuc domain

[Bob Gonzales]

Thanks for the update, Stuart!

On Mon, Feb 20, 2017 at 8:38 PM, <raeburn at msu.edu> wrote:

> Bob,
>
>
>> I don't think that I want to have my own custom version of lonnet.pm.
>> It's
>> too hard to keep track of those kinds of changes in the future.  Will this
>> issue go away when I upgrade to the 2.11.2 version of lon-capa?
>>
>>
> LON-CAPA 2.11.2, which I expect to release in a couple of weeks, will
> *not* implement a workaround for use with CentOS/Scientific Linux/Red Hat 7
> (and Ubuntu 12, 14 and 16 LTS) for replication of LON-CAPA resources from a
> library server with an Apache/SSL certificate with an unverifiable hostname.
>
> This issue will however disappear in LON-CAPA 2.12.0, which I expect to
> release around the time of the 2017 LON-CAPA conference.
>
> In 2.12.0 a new module: LWPReq.pm is used as a wrapper for calls to the
> LWP perl library
> (see: http://source.loncapa.org/cgi-bin/cvsweb.cgi/loncom/LWPReq.pm)
>
> When LWPReq.pm is used to replicate content from other LON-CAPA library
> servers, verify_hostname will be disabled.
>
> LWPReq.pm supports older versions of perl-libwww-perl, (i.e., pre-version
> 6) in which hostname verification is never used, as well as version 6,
> where it is used (by default).
>
>
> Stuart Raeburn
> LON-CAPA Academic Consortium
>
>
> Quoting Bob Gonzales <rgonzal at binghamton.edu>:
>
> Thanks Stuart.  I see those errors when I run the openssl command against
>> the uiuc library server too.  I get a clean run against the msu library
>> server.
>>
>> I don't think that I want to have my own custom version of lonnet.pm.
>> It's
>> too hard to keep track of those kinds of changes in the future.  Will this
>> issue go away when I upgrade to the 2.11.2 version of lon-capa?
>>
>> Thanks,
>> Bob Gonzales
>>
>> On Thu, Feb 2, 2017 at 9:48 AM, <raeburn at msu.edu> wrote:
>>
>> Bob,
>>>
>>> The problem here appears to be the SSL certificate installed on the UIUC
>>> library server.  If I run the command:
>>>
>>> openssl s_client  -connect library1.lon-capa.uiuc.edu:443
>>>
>>> The response includes:
>>>
>>> verify error:num=20:unable to get local issuer certificate
>>> verify error:num=27:certificate not trusted
>>> verify error:num=21:unable to verify the first certificate
>>>
>>> Because of this certificate problem you will be unable to view previously
>>> unreplicated resources in the uiuc domain on a LON-CAPA server running a
>>> Linux distro/version which includes perl-libwww-perl version 6.
>>>
>>> That includes the binghamton LON-CAPA servers, but not the MSU LON-CAPA
>>> servers.
>>>
>>> On a server with perl-libwww-perl version 6, you could implement a
>>> temporary workaround by modifying the repcopy() routine in
>>> /home/httpd/lib/perl/Apache/lonnet.pm to include this line:
>>>
>>> $ua->ssl_opts( verify_hostname => 0 );
>>>
>>> and then reload Apache.
>>>
>>>
>>> Is is somehow related to the ssl request on port 443?  I am not running
>>>> ssl
>>>> in the binghamton domain.  However, I can see resources on other domains
>>>> (e.g. msu) that are running ssl.
>>>>
>>>>
>>>> Yes, it is related to the fact that the uiuc LON-CAPA library server is
>>> using https.
>>>
>>> Other LON-CAPA servers also use https (including educog.com and
>>> s10.lite.msu.edu), and for those servers the openssl s_client command
>>> above does not report any errors, so this issue looks to be specific to
>>> the
>>> certificate on the uiuc LON-CAPA library server.
>>>
>>> The fact that you do not use Apache/SSL for the binghamton LON-CAPA
>>> domain
>>> servers is not relevant here.  Although I would encourage you in the
>>> longer
>>> term to consider using Apache/SSL in the binghamton domain for security
>>> reasons.
>>>
>>> letsencrypt.org has an automated process for obtaining SSL certificates
>>> to use with the Apache web server, at no cost.
>>>
>>>
>>> Stuart Raeburn
>>> LON-CAPA Academic Consortium
>>>
>>>
>>>
>>> Hi All,
>>>
>>>>
>>>> I've got a situation where none of my servers can view the actual
>>>> resources
>>>> from the uiuc domain.  They can all browse to any subdirectory and can
>>>> look
>>>> at the metadata for any resource.  But they can't see the contents of a
>>>> resource file.  The window that shows the rendered resource does open
>>>> but
>>>> just has the one line "Unable to find SomeFileName.problem"  for
>>>> problems
>>>> and "Sorry! Resource not available." for images in it.
>>>>
>>>> For each resource that can't be viewed there is a line in lonnet.log
>>>> like
>>>> this:
>>>>
>>>> LWP get: 500 Can't connect to library1.lon-capa.uiuc.edu:443:
>>>> /home/httpd/html/res/uiuc/cyerkes/Chem_102_/problems/Homewor
>>>> k_4_QDB_8051158
>>>> /LandingFieldArrival.jpg
>>>>
>>>> I had the network IT guy for the university look at the edge firewall
>>>> logs
>>>> and he could see my requests going out but he didn't see any answers
>>>> coming
>>>> back from the uiuc server.  He wasn't 100% sure that he logs everything
>>>> coming in though so it's not definitive that they aren't coming back.
>>>> Though the message above would lead one to think that uiuc is not
>>>> replying
>>>> or not getting my request.
>>>>
>>>> I can browse to and see resources in other domains.  I also logged into
>>>> my
>>>> course using a msu access server and was successful viewing uiuc
>>>> resources.
>>>>
>>>> Entries in lonc.log and lond.log show that connections are being made
>>>> and
>>>> the fact that I can browse the subdirectorys says some things are OK.
>>>>
>>>> Is is somehow related to the ssl request on port 443?  I am not running
>>>> ssl
>>>> in the binghamton domain.  However, I can see resources on other domains
>>>> (e.g. msu) that are running ssl.
>>>>
>>>> Using nmap against library1.lon-capa.uiuc.edu shows port 443 open.
>>>>
>>>> Thanks,
>>>> Bob Gonzales
>>>> Binghamton University
>>>>
>>>>
>>>
>>>
>>
>
>
>
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.lon-capa.org/pipermail/lon-capa-admin/attachments/20170221/38fb6aca/attachment.html>