Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-3957

Fix Firefox opening IGB installer instead of downloading it on Linux

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:

      Description

      Situation: When testing IGB on Linux I ran into an issue when I tried to download the installer for IGB from BioViz.org. When I click on the Linux 64 bit link to download IGB the shell file is instead opened as a flat text file in the Firefox browser. And because it is a button instead of a link, there is no way to right-click and select "Download", which means that a Linux user on Firefox cannot easily download IGB.

      Task: Fix it so that a Linux user with Firefox can download IGB from BioViz.org (early access and the download page). See this link for additional information.

        Attachments

          Issue Links

            Activity

            Hide
            nfreese Nowlan Freese added a comment -

            I tested on Mac with a user agent set to Linux so that the Linux button would appear in the IGB downloads page of BioViz.org (you can also go to https://www.bioviz.org/otherDownloads.html). Mac and Windows work fine, but for some reason the Linux download button just opens the shell file instead of downloading it, and because we use a button instead of a link there is no way to right-click to download the file.

            I played around with trying to specify a type in the button such that the browser would recognize that the .sh is a file that needs to be downloaded. What's strange to me is that if I change the URL to point at a shell file in bitbucket (for example this one), the browser downloads the .sh installer successfully. Is it possible that the .sh file we have in the bioviz server is configured in such a way that the browser thinks it is a text file?

            Show
            nfreese Nowlan Freese added a comment - I tested on Mac with a user agent set to Linux so that the Linux button would appear in the IGB downloads page of BioViz.org (you can also go to https://www.bioviz.org/otherDownloads.html ). Mac and Windows work fine, but for some reason the Linux download button just opens the shell file instead of downloading it, and because we use a button instead of a link there is no way to right-click to download the file. I played around with trying to specify a type in the button such that the browser would recognize that the .sh is a file that needs to be downloaded. What's strange to me is that if I change the URL to point at a shell file in bitbucket (for example this one ), the browser downloads the .sh installer successfully. Is it possible that the .sh file we have in the bioviz server is configured in such a way that the browser thinks it is a text file?
            Hide
            ann.loraine Ann Loraine added a comment -

            Possibly useful observation or suggestions:

            • When you click a link or download a file, the web server software sets the file type so that browser knows what to do. The ".sh" file type probably needs to be configured in apache web server configuration files somehow.
            Show
            ann.loraine Ann Loraine added a comment - Possibly useful observation or suggestions: When you click a link or download a file, the web server software sets the file type so that browser knows what to do. The ".sh" file type probably needs to be configured in apache web server configuration files somehow.
            Hide
            uchinta Udaya Chinta added a comment -

            I tested the otherDownloads.html page using the following URLs:
            1. https://www.bioviz.org/igb/releases/current/IGB_unix_current.sh
            2. https://bitbucket.org/lorainelab_udaya/integrated-genome-browser/downloads/IGB-linux-amd64-IGBF-1464.sh

            I wanted to test how the webpage functions with .sh files. The page successfully downloaded the second URL, as it’s a Bitbucket URL, but only displayed the content for the first URL. Upon investigating, I found several articles suggesting this could be a server-side issue. Since bioviz.org is hosted on an Apache server, I found the following article that might be useful:
            https://serverfault.com/questions/356042/how-to-configure-web-ftp-server-so-that-it-downloads-sh-files-instead-of-showin

            Show
            uchinta Udaya Chinta added a comment - I tested the otherDownloads.html page using the following URLs: 1. https://www.bioviz.org/igb/releases/current/IGB_unix_current.sh 2. https://bitbucket.org/lorainelab_udaya/integrated-genome-browser/downloads/IGB-linux-amd64-IGBF-1464.sh I wanted to test how the webpage functions with .sh files. The page successfully downloaded the second URL, as it’s a Bitbucket URL, but only displayed the content for the first URL. Upon investigating, I found several articles suggesting this could be a server-side issue. Since bioviz.org is hosted on an Apache server, I found the following article that might be useful: https://serverfault.com/questions/356042/how-to-configure-web-ftp-server-so-that-it-downloads-sh-files-instead-of-showin
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            Following the serverfault link found by Udaya Chinta in the comment above, I read this useful tip:

            If you do curl -Iv http://www.example.com/foo.sh you will Content-Type: header indicating what the web server thinks the file it's serving is.

            Ran:

            curl -Iv https://bioviz.org/igb/releases/igb-10.1.0/IGB_unix_current.sh
            

            Returns:

            *   Trying 52.207.108.150:443...
            * Connected to bioviz.org (52.207.108.150) port 443
            * ALPN: curl offers h2,http/1.1
            * (304) (OUT), TLS handshake, Client hello (1):
            *  CAfile: /etc/ssl/cert.pem
            *  CApath: none
            * (304) (IN), TLS handshake, Server hello (2):
            * (304) (IN), TLS handshake, Unknown (8):
            * (304) (IN), TLS handshake, Certificate (11):
            * (304) (IN), TLS handshake, CERT verify (15):
            * (304) (IN), TLS handshake, Finished (20):
            * (304) (OUT), TLS handshake, Finished (20):
            * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
            * ALPN: server accepted http/1.1
            * Server certificate:
            *  subject: CN=*.bioviz.org
            *  start date: Jul  9 00:00:00 2024 GMT
            *  expire date: Aug  9 23:59:59 2025 GMT
            *  subjectAltName: host "bioviz.org" matched cert's "bioviz.org"
            *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
            *  SSL certificate verify ok.
            * using HTTP/1.1
            > HEAD /igb/releases/igb-10.1.0/IGB_unix_current.sh HTTP/1.1
            > Host: bioviz.org
            > User-Agent: curl/8.4.0
            > Accept: */*
            > 
            < HTTP/1.1 200 OK
            HTTP/1.1 200 OK
            < Date: Fri, 06 Dec 2024 18:12:22 GMT
            Date: Fri, 06 Dec 2024 18:12:22 GMT
            < Server: Apache/2.4.52 (Ubuntu)
            Server: Apache/2.4.52 (Ubuntu)
            < Last-Modified: Wed, 13 Nov 2024 16:14:47 GMT
            Last-Modified: Wed, 13 Nov 2024 16:14:47 GMT
            < ETag: "bb8fcab-626cda1ec5636"
            ETag: "bb8fcab-626cda1ec5636"
            < Accept-Ranges: bytes
            Accept-Ranges: bytes
            < Content-Length: 196672683
            Content-Length: 196672683
            < Content-Type: text/x-sh
            Content-Type: text/x-sh
            
            < 
            * Connection #0 to host bioviz.org left intact
            

            The content type is listed as: text/x-sh

            Show
            ann.loraine Ann Loraine added a comment - - edited Following the serverfault link found by Udaya Chinta in the comment above, I read this useful tip: If you do curl -Iv http://www.example.com/foo.sh you will Content-Type: header indicating what the web server thinks the file it's serving is. Ran: curl -Iv https: //bioviz.org/igb/releases/igb-10.1.0/IGB_unix_current.sh Returns: * Trying 52.207.108.150:443... * Connected to bioviz.org (52.207.108.150) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=*.bioviz.org * start date: Jul 9 00:00:00 2024 GMT * expire date: Aug 9 23:59:59 2025 GMT * subjectAltName: host "bioviz.org" matched cert's "bioviz.org" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA * SSL certificate verify ok. * using HTTP/1.1 > HEAD /igb/releases/igb-10.1.0/IGB_unix_current.sh HTTP/1.1 > Host: bioviz.org > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Fri, 06 Dec 2024 18:12:22 GMT Date: Fri, 06 Dec 2024 18:12:22 GMT < Server: Apache/2.4.52 (Ubuntu) Server: Apache/2.4.52 (Ubuntu) < Last-Modified: Wed, 13 Nov 2024 16:14:47 GMT Last-Modified: Wed, 13 Nov 2024 16:14:47 GMT < ETag: "bb8fcab-626cda1ec5636" ETag: "bb8fcab-626cda1ec5636" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 196672683 Content-Length: 196672683 < Content-Type: text/x-sh Content-Type: text/x-sh < * Connection #0 to host bioviz.org left intact The content type is listed as: text/x-sh
            Hide
            ann.loraine Ann Loraine added a comment -

            Update:

            • Set up a test site with domain test2025.bioviz.org and IP address 3.213.193.166.
            • Edited my /etc/hosts file on my local computer to point the domain to the above IP address with:
            local aloraine$ cat /etc/hosts
            ##
            # Host Database
            #
            # localhost is used to configure the loopback interface
            # when the system is booting.  Do not change this entry.
            ##
            127.0.0.1	localhost
            255.255.255.255	broadcasthost
            ::1             localhost
            3.213.193.166	test2024.bioviz.org
            

            Made some edits to apache2 configuration file and tested with:

            local aloraine$ curl -Iv https://test2024.bioviz.org/igb/releases/current/IGB_unix_current.sh
            *   Trying 3.213.193.166:443...
            * Connected to test2024.bioviz.org (3.213.193.166) port 443
            * ALPN: curl offers h2,http/1.1
            * (304) (OUT), TLS handshake, Client hello (1):
            *  CAfile: /etc/ssl/cert.pem
            *  CApath: none
            * (304) (IN), TLS handshake, Server hello (2):
            * (304) (IN), TLS handshake, Unknown (8):
            * (304) (IN), TLS handshake, Certificate (11):
            * (304) (IN), TLS handshake, CERT verify (15):
            * (304) (IN), TLS handshake, Finished (20):
            * (304) (OUT), TLS handshake, Finished (20):
            * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
            * ALPN: server accepted http/1.1
            * Server certificate:
            *  subject: CN=*.bioviz.org
            *  start date: Jul  9 00:00:00 2024 GMT
            *  expire date: Aug  9 23:59:59 2025 GMT
            *  subjectAltName: host "test2024.bioviz.org" matched cert's "*.bioviz.org"
            *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
            *  SSL certificate verify ok.
            * using HTTP/1.1
            > HEAD /igb/releases/current/IGB_unix_current.sh HTTP/1.1
            > Host: test2024.bioviz.org
            > User-Agent: curl/8.4.0
            > Accept: */*
            > 
            < HTTP/1.1 200 OK
            HTTP/1.1 200 OK
            < Date: Fri, 06 Dec 2024 19:30:02 GMT
            Date: Fri, 06 Dec 2024 19:30:02 GMT
            < Server: Apache/2.4.52 (Ubuntu)
            Server: Apache/2.4.52 (Ubuntu)
            < Last-Modified: Fri, 06 Dec 2024 18:33:33 GMT
            Last-Modified: Fri, 06 Dec 2024 18:33:33 GMT
            < ETag: "bb8fcab-6289e4095ba09"
            ETag: "bb8fcab-6289e4095ba09"
            < Accept-Ranges: bytes
            Accept-Ranges: bytes
            < Content-Length: 196672683
            Content-Length: 196672683
            < Content-Disposition: attachment; filename="(null)"
            Content-Disposition: attachment; filename="(null)"
            < Content-Type: application/octet-stream
            Content-Type: application/octet-stream
            
            < 
            * Connection #0 to host test2024.bioviz.org left intact
            

            Note that the content type is "Content-Type: application/octet-stream" and there is "Content-Disposition: attachment; filename="(null)"

            Here is the code I added to /etc/apache2/sites-enabled/test2024.bioviz.org-ssl.conf on the test host for testing purposes only:

                              <FilesMatch "^(IGB_unix_current.sh)$">
                                 ForceType application/octet-stream
                                 Header set Content-Disposition 'attachment; filename="%{MATCH_FILENAME}e"'
                              </FilesMatch>
            

            The MATCH_FILENAME syntax is an attempt to get matching file name as a environment variable - the "e" at the end of the variable name. I'm not sure if this value is getting set. I think it requires mod_env to work.

            I simplified the above to:

                              <FilesMatch "^(IGB_unix_current.sh)$">
                                 ForceType application/octet-stream
                                 Header set Content-Disposition 'attachment; filename="IGB_unix_current.sh"'
                              </FilesMatch>
            

            This caused the file to get downloaded to my computer when I accessed this URL: https://test2024.bioviz.org/igb/releases/current/IGB_unix_current.sh

            However, I don't know if a Linux machine would run the file upon download, or not. This is what we want – for the installer program (a shell script) to run and install the IGB application bundled with the shell script into the correct locations on the user's computer.

            Show
            ann.loraine Ann Loraine added a comment - Update: Set up a test site with domain test2025.bioviz.org and IP address 3.213.193.166. Edited my /etc/hosts file on my local computer to point the domain to the above IP address with: local aloraine$ cat /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost 3.213.193.166 test2024.bioviz.org Made some edits to apache2 configuration file and tested with: local aloraine$ curl -Iv https: //test2024.bioviz.org/igb/releases/current/IGB_unix_current.sh * Trying 3.213.193.166:443... * Connected to test2024.bioviz.org (3.213.193.166) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=*.bioviz.org * start date: Jul 9 00:00:00 2024 GMT * expire date: Aug 9 23:59:59 2025 GMT * subjectAltName: host "test2024.bioviz.org" matched cert's "*.bioviz.org" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA * SSL certificate verify ok. * using HTTP/1.1 > HEAD /igb/releases/current/IGB_unix_current.sh HTTP/1.1 > Host: test2024.bioviz.org > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Fri, 06 Dec 2024 19:30:02 GMT Date: Fri, 06 Dec 2024 19:30:02 GMT < Server: Apache/2.4.52 (Ubuntu) Server: Apache/2.4.52 (Ubuntu) < Last-Modified: Fri, 06 Dec 2024 18:33:33 GMT Last-Modified: Fri, 06 Dec 2024 18:33:33 GMT < ETag: "bb8fcab-6289e4095ba09" ETag: "bb8fcab-6289e4095ba09" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 196672683 Content-Length: 196672683 < Content-Disposition: attachment; filename= "( null )" Content-Disposition: attachment; filename= "( null )" < Content-Type: application/octet-stream Content-Type: application/octet-stream < * Connection #0 to host test2024.bioviz.org left intact Note that the content type is "Content-Type: application/octet-stream" and there is "Content-Disposition: attachment; filename="(null)" Here is the code I added to /etc/apache2/sites-enabled/test2024.bioviz.org-ssl.conf on the test host for testing purposes only: <FilesMatch "^(IGB_unix_current.sh)$" > ForceType application/octet-stream Header set Content-Disposition 'attachment; filename= "%{MATCH_FILENAME}e" ' </FilesMatch> The MATCH_FILENAME syntax is an attempt to get matching file name as a environment variable - the "e" at the end of the variable name. I'm not sure if this value is getting set. I think it requires mod_env to work. I simplified the above to: <FilesMatch "^(IGB_unix_current.sh)$" > ForceType application/octet-stream Header set Content-Disposition 'attachment; filename= "IGB_unix_current.sh" ' </FilesMatch> This caused the file to get downloaded to my computer when I accessed this URL: https://test2024.bioviz.org/igb/releases/current/IGB_unix_current.sh However, I don't know if a Linux machine would run the file upon download, or not. This is what we want – for the installer program (a shell script) to run and install the IGB application bundled with the shell script into the correct locations on the user's computer.
            Hide
            ann.loraine Ann Loraine added a comment -

            Update:

            Show
            ann.loraine Ann Loraine added a comment - Update: Saved changes to a new branch on a new fork https://bitbucket.org/aloraine/bioviz-playbooks/branch/IGBF-3957 When the changes are tested and validated I will submit a PR to the team repository at https://bitbucket.org/lorainelab/bioviz-playbooks ubuntu branch
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            Nowlan Freese: I will need a little help to test that the new configuration works properly.

            Could you help me use the Linux machine to test if the test web site lets me download and install the Linux version of IGB?

            One wrinkle: I just now associated the domain test2024.bioviz.org with IP address 3.213.193.166 in DNS. It will take at least 15 minutes (maybe longer) for this new configuration to propagate across the internet. If you want to access the host before that happens, you would need to edit your system's equivalent of /etcs/hosts to associate domain test2024.bioviz.org with IP adfdress 3.213.193.166.

            Show
            ann.loraine Ann Loraine added a comment - - edited Nowlan Freese : I will need a little help to test that the new configuration works properly. Could you help me use the Linux machine to test if the test web site lets me download and install the Linux version of IGB? One wrinkle: I just now associated the domain test2024.bioviz.org with IP address 3.213.193.166 in DNS. It will take at least 15 minutes (maybe longer) for this new configuration to propagate across the internet. If you want to access the host before that happens, you would need to edit your system's equivalent of /etcs/hosts to associate domain test2024.bioviz.org with IP adfdress 3.213.193.166.
            Hide
            nfreese Nowlan Freese added a comment -

            Tested on Linux - the download.html and otherDownloads.html IGB installer now downloads on Linux.

            The earlyAccessDownload.html is not working correctly and opens the shell file.

            Show
            nfreese Nowlan Freese added a comment - Tested on Linux - the download.html and otherDownloads.html IGB installer now downloads on Linux. The earlyAccessDownload.html is not working correctly and opens the shell file.
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            Update:

            Show
            ann.loraine Ann Loraine added a comment - - edited Update: Added configuration for early access installer to also be downloaded instead of displayed in Web browser Submitted and merged PR. Deployed change to public bioviz.org site. Checked that files IGB-linux-amd64-main.sh and IGB_unix_current.sh are downloaded instead of displayed by clicking on links https://bioviz.org/igb/releases/early_access/ https://bioviz.org/igb/releases/igb-10.1.0/ https://bioviz.org/igb/releases/igb-10.1.0/ Thanks to previous testing by Nowlan Freese , I think we can close this now.

              People

              • Assignee:
                ann.loraine Ann Loraine
                Reporter:
                nfreese Nowlan Freese
              • Votes:
                0 Vote for this issue
                Watchers:
                Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: