Aspera

 View Only
  • 1.  Global docroot setting on HSTS

    Posted Thu December 08, 2022 11:01 AM
    Hi,
    I'm trying to setup an HSTS with Proxy for one of my customers. But I have the impression the global docroot setting doesn't seem to have any effect:
    • I configured a system with a few users, and global transfer settings as advised in the Admin Guide.
    • If I configure asconfigurator -x "set_node_data;absolute,/data/aspera", and log in with a user, I enter the root of the file system.
    • If I configure that same path as the docroot for the individual user (asconfigurator -x "set_user_data;user_name,myuser;absolute,/data/aspera"), I get the desired result.
    Any clue what might be wrong here? Or how I can troubleshoot?

    Best regards,
    Sam

    ------------------------------
    Sam Lerouge
    ------------------------------


  • 2.  RE: Global docroot setting on HSTS

    Posted Thu December 08, 2022 04:14 PM
    Make sure to restart services like asperanoded and asperacentral after making changes to the aspera.conf

    Can you clarify which application you are using to login to the transfer server?

    As a note, we generally recommend to setting the default section to deny access to the transfer server and then explicitly allow individual users or groups.

    asconfigurator -x "set_node_data;authorization_transfer_out_value,deny"
    asconfigurator -x "set_node_data;authorization_transfer_in_value,deny"

    You can further lock down browsing the remote file systems with the Desktop Client or HSTE/HSTS GUI

    asconfigurator -x "set_node_data;read_allowed,false"
     asconfigurator -x "set_node_data;write_allowed,false"
    asconfigurator -x "set_node_data;dir_allowed,false"

    ------------------------------
    BEN FORSYTH
    ------------------------------



  • 3.  RE: Global docroot setting on HSTS

    Posted Fri December 09, 2022 03:17 AM
    Sam,
    When you "login" with a user, I assume you do so with the "GUI", i.e. either the Desktop Client, or HSTS GUI (or an HSTE).
    In fact, when using "SSH" authentication, without tokens, i.e. without web app, restart of services (asperanoded asperacentral) is generally not necessary, as the involved processes (ascmd and ascp) are started for new sessions (new browsing sessions for ascmd, new transfer sessions for ascp).

    If you use "Connect", i.e. a web app, generally you need to restart those daemons, as they are involved in transfer spec generation and file browsing, and depends on reading aspera.conf (executing asnodeadmin --reload also works). (e.g. token encryption key, server_name, ssh_port, etc... are used by asperanoded for transfer spec, but absolute is also used for browsing...)

    So, if you restart daemons everytime aspera.conf is modified, then you don't need to think about it, and that lifts any doubt.

    Note that if you use the Desktop GUI, the ascmd session stays alive during the browsing session (unlinke ascli), so aspera.conf is read only at the beginning of the session, and "browsing" will be done in the context of aspera.conf as it was at the beginning of the session. (even if you restart daemons).

    Concerning your precise question:
    You can always check the effective values used by ascp and ascmd by executing asuserdata -u _user_here_.
    That will dump all correlated parameters (evaluation order: hard coded->global->group->user)

    If you like command line (like me) because that allows repetitive testings, I encourage you use aspera-cli.

    For example, to list files on a remote HSTS with an SSH :

    ascli server --url=ssh://eudemo.asperademo.com:33001 --username=asperaweb --password=demoaspera ls /

    This allows you to quickly check your changes.



    ------------------------------
    Laurent Martin
    ------------------------------



  • 4.  RE: Global docroot setting on HSTS

    Posted Fri December 09, 2022 03:59 AM
    Hi Ben, Laurent,

    Let me first thank you for spending time on looking at my question and replying to it - greatly appreciated!
    Indeed, I was using the Desktop Client during my tests. And there is something else that might be relevant as well, but I forgot to mention: I already have one user configured with a file restriction instead of a docroot, not sure if that can have an impact.
    I didn't know about the asuserdata -u option, it can come in handy for sure. This is what I get in the first case (only global docroot defined):
      docroot option set:
          canonical_absolute: "<Empty String>"
          canonical_show_as: "/"
          absolute: ""
          show_as: ""
    ​

    If I define a docroot for that specific user, I get a different result:

      docroot option set:
          canonical_absolute: "/pathtohomefolder"
          canonical_show_as: "/"
          absolute: "/pathtohomefolder"
          show_as: ""
    

    I'm wondering if I made any mistake in aspera.conf - even though I used asconfigurator to edit it. This is the part we should be looking at:

        <default>
        <!-- other sections here -->
            <file_system>
                <access>
                    <paths>
                        <path>
                            <absolute>/defaultdocroot</absolute>
                            <read_allowed>false</read_allowed>
                            <write_allowed>false</write_allowed>
                            <dir_allowed>false</dir_allowed>
                        </path>
                    </paths>
                </access>
            </file_system>
        </default>

    But so far, I have the feeling this global setting doesn't have any effect.

    My initial configuration was based on the guidelines in the Admin Guide. This included limiting read, write and delete. But I will follow Ben's advise and further restrict default transfer access.



    ------------------------------
    Sam Lerouge
    ------------------------------



  • 5.  RE: Global docroot setting on HSTS

    Posted Fri December 09, 2022 09:28 AM
    Sam,

    General good practice:
    Never edit aspera.conf manually.
    Always use asconfigurator.
    99.9% of changes to aspera.conf can be done with asconfigurator. (only a very few advanced-seldom-used options must be added by editing the file)
    Rationale: there is a too high risk of not adding the XML section in the right place.
    Really by experience: it's often misplaced, and lead t the problem you have.
    The XML may be syntactically correct (asuserdata -v passes validation), but the section may simply be in a wrong place, e.g. miss an intermediary XML tag.
    The recipe to use asconfigurator to change any parameters is:
    • Find out the right command. For example: if you want to change the docroot , you know that the parameter is "absolute", so do:
    asuserdata -+|grep absolute
    (if you are on windows, well... take your favorite shell, cmd with findstr, or powershell, or redirect to a file, and open the file with notepad++, right ?)
    You will find there: the example of XML tag, but more importantly, the related asconfigurator command
    • copy the command from the previous step, change <value> to your value, and execute
    Note: the command show is to change the global setting.
    To change user's setting, change the command to "set_user_data" and add parameter: user_name,xxx, for example:
    asconfigurator -x "set_user_data;user_name,jean;absolute,/data/jean"
    is for a user, and
    asconfigurator -x "set_node_data;absolute,/data/global"is for a global setting.

    So, for your precise case:
    obviously, the global setting is not taken in account, you it seems it was added manually, so use asconfigurator to set the global docroot,
    then edit the file, and probably you will see that the global setting set manually was not in the right place.
    (you did not show the actual absolute location: did you place the section <default> directly inside <CONF> ? (good place), or somewhere else)


    ------------------------------
    Laurent Martin
    ------------------------------