Wow, how could I have missed it? This fixed it: http://genomewiki.ucsc.edu/index.php/KNETFILE_HOOKS
Thanks, David On Nov 23, 2010, at 2:55 PM, Galt Barber wrote: > > 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
