Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Protect ado files on server and adjust adopath permanently

    Hi all,
    we want to install Stata on a new server and as far as I know there are several ado path directories (e.g. base) and therefore ado files that are shared by all users on the server. This can create problems if for example certain users need different versions of the same ado file (for compatibility reasons) or manually adjust ado files without letting anybody know….! Is there a way to protect these directories globally (e.g. during the installation process) and only allow (regular) updates by the admin? Is there are a way to automatically adjust the adopath assigning users only the base ado folder on the server and a personal ado folder on a fdnetwork drive? I know there is the possibility to use profile.do or a sysprofile.do, but I think users can still circumvent these files, don‘t they?

    Thanks for your help in advance. If any piece of information is missing, please let me know.


    P.S.: I used the Statalist search, Stata manuals and Google, and did not find a suitable solution, but I think this is such an obvious questions that there must be an answer to my questions.

  • #2
    The most authoritative source of installation assistance is from Stata Technical Services. See

    https://www.stata.com/support/

    especially the installation guide

    https://www.stata.com/install-guide/

    and the discussion of technical support

    https://www.stata.com/support/tech-support/

    Understand that any multi-user installation has its own particular concerns, and while Stata does very well with documentation for single-user installation, there's no reasonable way of addressing every possible concern under every possible installation scenario. The limited amount of information in post #1 (we don't even know what kind of server you are installing) precludes a specific answer, or more importantly, guidance on how to do the installation to meet your needs. That's the provenance of the experts at Stata Technical Services.
    Last edited by William Lisowski; 17 Jan 2022, 13:26.

    Comment


    • #3
      Hi William,

      thank you very much for all the very useful resources which I read (hopefully very carefully). Sorry for the lack of information in #1, but now I am able to give more information: We are using Windows Terminal Services to connect local machines (i.e. laptops with Windows 10/11 Pro) via a Windows Remote Desktop Connection to Windows servers (Windows Server R2 2012 or Windows Server 2019) Furthermore we are using Stata 17 MP 4core (network licence). Does this information help to give more specific advice? One way might be to restrict "write permission" in the Stata directory (i.e. C.\Program Files\Stata17) to admins only by adjusting the permissions in Windows and set up a sysprofile.do which alters the adopath accordingly. However we still would need to create a custom ado folder for each user and add it to the adopath.

      Is there a better way to do this? How do other institutions handle this problem?

      Thanks for your answers in advance.

      Best,
      Sebastian
      P.S.: I'll contact Stata Technical Services as well and post their answer here.


      Comment


      • #4
        A great deal depends on your local procedures. At my workplace students have their own space (a particular named drive) and can download e.g. from SSC or the Stata Journal to that filespace. That doesn't rule out shared resources under the adopath pecking order.

        Comment


        • #5
          Hi Nick,
          thanks for your answer as well. hmmm...right now I think I will have to create a sysprofile.do in the Stata installation path and specify custom PLUS and PERSONAL directories in the adopath that are located on the personal network drives the users. Therefore I probably will have to check whether a PLUS and PERSONAL directory already exist and if not create one using the windows environment variables to find the user name (e.g. c(username)). I'll try and post the solution if I find one.
          If in the meantime a better solutions comes up, please let me know.

          Best,
          Sebastian

          Comment

          Working...
          X