I’ve seen a lot of self-hosted software wanting to store their data in /opt, is there any reason why?

  • www-gem
    link
    fedilink
    95
    edit-2
    9 months ago

    "Traditionally, the /opt directory is used for installing/storing the files of third-party applications that are not available from the distribution’s repository.

    The normal practice is to keep the software code in opt and then link the binary file in the /bin directory so that all the users can run it."

    https://linuxhandbook.com/linux-directory-structure/

      • @atzanteol@sh.itjust.works
        link
        fedilink
        English
        15
        edit-2
        9 months ago

        I was wondering about that too… According to the spec:

        /home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Therefore, no program should assume any specific location for a home directory, rather it should query for it.

        Sometimes home directories are in other locations. My University used to have different mount points for different graduating classes on our Unix servers. And I use “/home2” for one of my servers for… reasons.

        Though I’m not sure that qualifies as “deprecated”? I get the “non-standard” bit though.

        • holgersson
          link
          fedilink
          39 months ago

          You also have to consider that roots homedir is in /root and not home, so if you’d just assume it’s /home/$USER you’d get in trouble when your programm is run or compiled as root.

      • Ac5000
        link
        fedilink
        69 months ago

        That’s what I was wondering as well?

        If so, what’s the “correct” location to store stuff like documents, downloads, configurations, etc.?

        • @atzanteol@sh.itjust.works
          link
          fedilink
          English
          9
          edit-2
          9 months ago

          In the user’s home directory, which may or may not be in /home/username.

          grep username /etc/passwd will show you the home directory for a user. Also ~username from the CLI will resolve to that user’s home directory. e.g. cp file.txt ~username/Documents/

        • @gens@programming.dev
          link
          fedilink
          49 months ago

          So i checked the fhs. Doesn’t say it is deprecated. V3 just mentions XDG and glib (the probable sources of such claims).

      • @lolcatnip@reddthat.com
        link
        fedilink
        English
        39 months ago

        My best guess is that having programs treat a user’s home directly as a location for things like config files is deprecated. Programs should be following the XDG standard instead.

        You could contact the author (their email address is in the image), but I’m too lazy to do that.

      • @melvisntnormal@feddit.uk
        link
        fedilink
        1
        edit-2
        9 months ago

        The legend seems confusing to me. I think it’s trying to say that /home is non-standard. Notice that the description for /var/run explicitly states it’s deprecated, and has a solid border.

  • @kyub@discuss.tchncs.de
    link
    fedilink
    English
    47
    edit-2
    9 months ago

    Let’s say you want to compile and install a program for yourself from its source code form. There’s generally a lot of choice here:

    You could (theoretically) use / as its installation prefix, meaning its binaries would then probably go underneath /bin, its libraries underneath /lib, its asset files underneath /share, and so on. But that would be terrible because it would go against all conventions. Conventions (FHS etc.) state that the more “important” a program is, the closer it should be to the root of the filesystem (“/”). Meaning, /bin would be reserved for core system utilities, not any graphical end user applications.

    You could also use /usr as installation prefix, in which case it would go into /usr/bin, /usr/lib, /usr/share, etc… but that’s also a terrible idea, because your package manager respectively the package maintainers of the packages you install from your distribution use that as their installation prefix. Everything underneath /usr (except /usr/local) is under the “administration” of your distro’s packages and package manager and so you should never put other stuff there.

    /usr/local is the exception. It’s where it’s safe to put any other stuff. Then there’s also /opt. Both are similar. Underneath /usr/local, a program would be traditionally split up based on file type - binaries would go into /usr/local/bin, etc. - everything’s split up. But as long as you made a package out of the installation, your package manager knows what files belong to this program, so not a big deal. It would be a big deal if you installed it without a package manager though - then you’d probably be unable to find any of the installed files when you want to remove them. /opt is different in that regard - here, everything is underneath /opt//, so all files belonging to a program can easily be found. As a downside, you’d always have to add /opt// to your $PATH if you want to run the program’s executable directly from the commandline. So /opt behaves similar to C:\Program Files\ on Windows. The other locations are meant to be more Unix-style and split up each program’s files. But everything in the filesystem is a convention, not a hard and fast rule, you could always change everything. But it’s not recommended.

    Another option altogether is to just install it on a per-user basis into your $HOME somewhere, probably underneath ~/.local/ as an installation prefix. Then you’d have binaries in ~/.local/bin/ (which is also where I place any self-writtten scripts and small single scripts/executables), etc. Using a hidden directory like .local also means you won’t clutter your home directory visually so much. Also, ~/.local/share, ~/.local/state and so on are already defined by the XDG FreeDesktop standards anyway, so using ~/.local is a great idea for installing stuff for your user only.

    Hope that helps clear up some confusion. But it’s still confusing overall because the FHS is a historically grown standard and the Unix filesystem tree isn’t really 100% rational or well-thought out. It’s a historically grown thing. Modern Linux applications and packaging strategies do mitigate some of its problems and try to make things more consistent (e.g. by symlinking /bin to /usr/bin and so on), but there are still several issues left over. And then you have 3rd party applications installed via standalone scripts doing what they want anyway. It’s a bit messy but if you follow some basic conventions and sane advice then it’s only slightly messy. Always try to find and prefer packages built for your distribution for installing new software, or distro-independent packages like Flatpaks. Only as a last resort you should run “installer scripts” which do random things without your package manager knowing about anything they install. Such installer scripts are the usual reason why things become messy or even break. And if you build software yourself, always try to create a package out of it for your distribution, and then install that package using your package manager, so that your package manager knows about it and you can easily remove or update it later.

    • @caseyweederman@lemmy.ca
      link
      fedilink
      219 months ago

      Add-on application software packages

      How are applications that go into /opt different than any other packages? Even after reading that spec, it seems arbitrary.

      • @catloaf@lemm.ee
        link
        fedilink
        English
        329 months ago

        Yes, it’s arbitrary.

        Packages that bundle a bunch of stuff, or otherwise make a mess, should go into /opt. Well-behaved packages that integrate with the system should be fine to install to /usr.

      • Strit
        link
        fedilink
        209 months ago

        It is very arbitrary. Some/most non-free applications usually drop stuff into /opt, so it does not spread all over the filesystem. It makes sense if the application was not developed with Linux in mind, like Discord, Teamviewer etc.

      • Aniki 🌱🌿
        link
        fedilink
        English
        99 months ago

        On all the work servers I maintain we pretty much install anything that’s not in the base repo to /opt/

  • Mactan
    link
    fedilink
    159 months ago

    I like running mesa git for a few specific games but I have zero desire to install it for my system so I install it to /opt and invoke the right environment variable to use it from there instead

  • Captain Aggravated
    link
    fedilink
    English
    149 months ago

    It is my understanding that /opt is short for optional, a bit like how /etc does actually mean et cetera, and their modern use cases were evolved rather than designed. /etc became a catch-all for system settings and configurations, and /opt became a place for executable binaries other than those managed by the local package manager. Which often meant “a big monolithic binary that arrives in a .tar.gz file.” /opt became less popular to use when /usr/local/bin was made for basically the same purpose.

    In modern practice, /opt gets used as a drunk tank for irritatingly unfriendly monolithic software. A lot of the time, software that isn’t managed by the system’s package manager gets put in /usr/local/bin, but occasionally if it’s a pain in the ass it’ll get put in /opt.

  • SolidGrue
    link
    fedilink
    English
    119 months ago

    General use, when you can install software through your system’s package manager then that’s the preferred way to get software on your system. For the most part, those applications live under /usr

    If for some reason you prefer to install the package manually, best practice is to install it outside /usr to avoid potential conflicts with existing system libraries. The /opt (“optional”) system is a common place to install these apps. Many modern install scripts already default to using /opt

    It’s also convenient for backing up those apps.

  • @atzanteol@sh.itjust.works
    link
    fedilink
    English
    8
    edit-2
    9 months ago

    Here’s an example of how I have used it in the past (following the guidance in the other post).

    I did a lot of Java development. Ubuntu has a package for OpenJDK which I installed, but I also need specific (and often multiple) versions not included by the package manager. So I would download a tarball and extract them to /opt/java-x.y.z/. Then for the version I considered my “current” I created a symlink at /opt/java to point to the version I wanted to use.

  • @mhz@lemm.ee
    link
    fedilink
    59 months ago

    That is where you put your optional packages, everyone has his own use for it. I use it to stocke my docker containers config

  • @MonkderZweite@feddit.ch
    link
    fedilink
    4
    edit-2
    9 months ago

    Woah, there’s even /etc/opt and /var/opt in the FHS.

    I agree, " Add-on application software packages" is quite ambiguous.

  • @scratchandgame@lemmy.ml
    link
    fedilink
    Tiếng Việt
    -69 months ago

    A trash hierarchy designed to replace /usr/local, which I think is not much used on Linux, and cause compatibility problem with BSDs.