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

[raeburn at msu.edu]

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
>>>
>>
>>
>