Bioinformatics.org
[OMICtools]
Not logged in
  • Log in
  • Bioinformatics.org
    Membership (40944+) Group hosting [?] Wiki
    Franklin Award
    Sponsorships

    Careers
    About bioinformatics
    Bioinformatics training
    Bioinformatics jobs

    Research
    All information groups
    Online databases Online analysis tools Online education tools More tools

    Development
    All software groups
    FTP repository
    SVN & CVS repositories [?]
    Mailing lists

    Forums
    News & Commentary
  • Submit
  • Archives
  • Subscribe

  • Jobs Forum
    (Career Center)
  • Submit
  • Archives
  • Subscribe
  • BIRCH: Comprehensive bioinfo. system - Support tickets

    Submit | Open tickets | Closed tickets

    [ Ticket #1126 ] Installation in $HOME directory
    Date:
    03/11/11 14:28
    Submitted by:
    B_Fristensky
    Assigned to:
    umhameld
    Category:
    Getbirch
    Priority:
    3
    Ticket group:
    Bug
    Resolution:
    Resolved
    Summary:
    Installation in $HOME directory
    Original submission:
    In the Advanced install, there doesn't seem to be a way to install BIRCH in $HOME, rather than $HOME/BIRCH. We need to be able to support this choice. For example,
    on albacore, I tried setting the install directory to /Users/birch, and it still
    created /Users/birch/BIRCH, and put everything in there.
    Please log in to add comments and receive followups via email.
    Followups
    Comment Date By
    Alright, lets leave this bug open to keep it on the radar. I will make future design decisions based on this information. We will need to clarify further exactly how this will look to the user, but as you say this can be done for BIRCH 2.9 03/26/11 14:55 umhameld
    I have concluded that while the default location should always be a directory named BIRCH, which could be located anywhere, we still need to support the abilty to change that to ANY name for the directory, and to specifically only delete a list of directories when uninstalling BIRCH.

    For release 2.8, we can leave it as is -
    - the name must be BIRCH for a new install
    - for already-existing installs, the directory doesn't
    change. (My tests so far indicate that this is already the case.) So long as we always get $BIRCH from local/admin/BIRCH.properties when updating, no changes need to be made.

    For release 2.9 or later, Getbirch still needs to give you the option in Advanced install, of having the birch directories installed in ANY directory.

    The main reason is that for a multi-user install where the documentation needs to be web-accessible, we need to provide the BIRCH administratior as much flexibility as possible. They are at the mercy of system administrators, who have all sorts of ideas about what constitutes a secure web site.

    The simplest case is installing BIRCH in $HOME, on an account solely dedicated to BIRCH. BIRCH is designed around this model, so that the $HOME/public_html corresponds to $BIRCH/public_html.

    At the U of M it's a little more complicated. They do NOT allow symbolic links in web sites, except web sites installed on www.umanitoba.ca. We got around this by asking IST to remotely mount /home/psgendb on www.umanitoba.ca

    Even worse is the situation I saw at Carleton (I think?) where each user's web site was on a separate web server, not a part of their $HOME directory. They had a tool, I think based on rsync, that let people make changes to their working copy of their web site, located in their $HOME directory, and then use the utility to update the web server with their changes.

    To summarize:

    For v2.8, all installs must be in a directory named 'BIRCH'.

    For v2.9 and later, we need to be able to do new installs in any directory eg. /home/birch, which will be assumed to have all the usual $HOME directory stuff in it. So uninstalling BIRCH is not as simple as deleting the BIRCH directory.


    03/18/11 16:08 B_Fristensky
    The update process should work an a user's home directory, as it is just reading the list of BIRCH folders and removing/replacing them. We addressed this issue a while back, if you recall, when it was originally assuming that BIRCH was in its own folder.

    As for the public_html, a symbolic link should take care of it, provided that their apache is setup to follow the symbolic links (as is the default option). I think that *not* forcing it to be in the home folder is a good thing, as this may a. overwrite their existing website and b. we can never know how their apache will be configured, so this is something that they will probably have to configure on a system to system basis (ie, many systems wouldnt make the 'public_html' folder web readable anyways). Basically what I am getting at is that if they want public documentation, we have everything ready for them, they just need to contact their apache admin to figure out what they need to do for their system.
    03/13/11 01:48 umhameld
    You make some valid points. It is possible that the solution will include forcing NEW installs to go into a directory named 'BIRCH'. However there are two considerations.

    First, the update process must still support those existing BIRCH installs that are not in a directory called BIRCH, such as psgendb, and the one at COE.

    Secondly, there is one other consideration that I have neglected to address until now, which is the public_html directory. For a single desktop install, this doesn't matter. But for a core facility in which we want $BIRCH/public_html to be the location of the web site, there is a conflict with the convention that $HOME/public_html is usually the location of the web site. I think I have this documented already so that the BIRCH administrator just has to make a symbolic link to $BIRCH/public_html, but this needs to be looked into further. I don't have the final answer to this one yet.

    03/12/11 14:56 B_Fristensky
    I remember discussing this and i had thought that we came to the conclusion that it makes more sense to keep BIRCH encapsulated in one folder. Installing it in the home folder makes it more difficult to remove, and can also have unforeseen consequences if one of the folders in BIRCH already exists. Since forcing BIRCH into one clean folder was a deliberate development decision, I am wondering what advantages there are to allowing for it to be installed to a home directory? I cannot think of any programs, especially of the size and complexity of BIRCH, that do not install to their own folder. This isn't a difficult change to make to the installer, though it will complicate the UI, as users may unwittingly install BIRCH to their home folder and then have a difficult time removing it. I have no problem with implementing this, I am just trying to investigate why the current setup is a problem, as this change will further complicate the installer 03/11/11 21:10 umhameld
    No results for "Dependent on ticket"
    No results for "Dependent on Task"
    No other tickets are dependent on this ticket
    Ticket change history
    Field Old value Date By
    status_id Open 08/11/11 19:09 umhameld
    resolution_id Not Resolved 08/11/11 19:09 umhameld
    close_date 12/31/69 19:00 08/11/11 19:09 umhameld
    priority 7 03/15/11 21:22 umhameld
    status_id Pending 03/11/11 14:29 B_Fristensky
    priority 5 03/11/11 14:29 B_Fristensky
    assigned_to unset 03/11/11 14:29 B_Fristensky
    resolution_id Unset 03/11/11 14:29 B_Fristensky

     

    Copyright © 2019 · Scilico, LLC