Hi, David!

I think that is right.
There is no native support in BAM for HTTPS,
but if it goes through our UCSC UDC layer with KNETFILE_HOOKS, it will
get openssl support.

Search the email archives for information on compiling for BAM with
KNETFILE_HOOKS.

-Galt

11/23/2010 10:51 AM, David Hoover:
> Do you think any of this has to do with KNETFILE_HOOKS?  Do I need to 
> recompile samtools?
>
> David
>
> On Nov 23, 2010, at 12:39 PM, Galt Barber wrote:
>
>>
>> Hi, David!
>>
>> 1. Do you have openssl installed?
>> Is the make process correctly configured to compile and link it in?
>> A quick check is to use ldd on one of your cgis such as hgTracks:
>>
>> ldd /usr/local/apache/cgi-bin/hgTracks
>>         libssl.so.6 =>  /lib64/libssl.so.6
>>         libcrypto.so.6 =>  /lib64/libcrypto.so.6
>>         libz.so.1 =>  /usr/lib64/libz.so.1
>>         libm.so.6 =>  /lib64/libm.so.6
>>         libc.so.6 =>  /lib64/libc.so.6
>>         libgssapi_krb5.so.2 =>  /usr/lib64/libgssapi_krb5.so.2
>>         libkrb5.so.3 =>  /usr/lib64/libkrb5.so.3
>>         libcom_err.so.2 =>  /lib64/libcom_err.so.2
>>         libk5crypto.so.3 =>  /usr/lib64/libk5crypto.so.3
>>         libdl.so.2 =>  /lib64/libdl.so.2
>>         /lib64/ld-linux-x86-64.so.2
>>         libkrb5support.so.0 =>  /usr/lib64/libkrb5support.so.0
>>         libkeyutils.so.1 =>  /lib64/libkeyutils.so.1
>>         libresolv.so.2 =>  /lib64/libresolv.so.2
>>         libselinux.so.1 =>  /lib64/libselinux.so.1
>>         libsepol.so.1 =>  /lib64/libsepol.so.1
>>
>> libssl, libcrypto, and several others in this list are related to openssl.
>>
>> Normally, if you try to access https with the kent libs
>> and there is no openssl linked-in, it would generate
>> an error message informing you of that.  However,
>> it's possible in this case that the error message
>> got trapped and then replaced with a more generic
>> error message.
>>
>> 2. Do you have a firewall that's blocking the https port?
>>
>> That is port 443 by default.
>>
>> -Galt
>>
>> 11/23/2010 8:39 AM, David Hoover:
>>> Hi,
>>>
>>> I have a local mirror of the Genome Browser, and I can load an external BAM 
>>> file using the bigDataUrl directive:
>>>
>>>    type=bam bigDataUrl=http://.../my.bam
>>>
>>> However, if I try to use https instead,
>>>
>>>    type=bam bigDataUrl=https://.../my.bam
>>>
>>> it fails with the error message
>>>
>>>    Error Can't access Ly2's bigDataUrl https://.../my.bam and/or the 
>>> associated index file https://.../my.bam.bai
>>>
>>> I know these files are accessible because I can download using wget from 
>>> the commandline of the web server machine that is running the local mirror.
>>>
>>> These commands work on the main UCSC Genome Browser, so what might be 
>>> different between the UCSC Genome Browser and our local mirror?
>>>
>>> Wondering,
>>> David Hoover
>>> Helix Systems Staff
>>> http://helix.nih.gov
>>> _______________________________________________
>>> Genome-mirror mailing list
>>> [email protected]
>>> https://lists.soe.ucsc.edu/mailman/listinfo/genome-mirror
>

_______________________________________________
Genome maillist  -  [email protected]
https://lists.soe.ucsc.edu/mailman/listinfo/genome

Reply via email to