4 ms·

>> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system dir

>> * Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories. > The articles uses the package manager - specifically, the article directs people to install node using nodesource's RPM and dpkg node packages (npm is included with node), and only mentions tarballs if these don't exist for your OS. Sure, but it also advises users that it's generally OK to extract tarballs into /usr/local. While this clearly is OK in some circumstances, the target audience for this article clearly aren't in a position to make that decision, or understand the consequences of doing this. The article could have suggested "/opt/node" for example and avoided the issue at the expense of explaining how PATH variables work.

nailer 11y ago
So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. The FHS forbids distros from installing software to either location. See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: > "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."
- kiallmacinnes 11y ago
  > So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. Ah, I did miss the subfolder. This is a very unusual convention for installation into /usr/local. Typically, this is what modern day usage of /opt looks like. > The FHS forbids distros from installing software to either location. > See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: Correct, both options are valid per the FHS. Yet, the description for /opt describes the pattern used in your example. See http://www.pathname.com/fhs/2.2/fhs-3.12.html http://www.pathname.com/fhs/2.2/fhs-3.12.html: "A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package."
  - nailer 11y ago
    I see your point - I used to be reticent to use /opt since it was a bit of a Solaris-ism (it only got added to the FHS because the proprietary Unixes kept asking for it). I'm thinking about changing it to /opt instead (and will credit you if I do it), alas /opt/bin isn't in $PATH on most distros.
    - merb 11y ago
      They can't just add /opt/bin to $PATH Read the link he wrote down: > Programs to be invoked by users must be located in the > directory /opt/<package>/bin. If the package includes UNIX > manual pages, they must be located in /opt/<package>/man > and the same substructure as /usr/share/man must be used. Static packages should be kept together as /opt/myprogramm and mostly follow the same structure as /usr than so like: /opt/myprogramm/bin /opt/myprogramm/include /opt/myprogramm/lib ... Mostly I put my programs there, too. /opt/app1 /opt/app2
      - nailer 11y ago
        nod that's the thing - you'll break the interpreter for every node app - '#!/usr/bin/env node' - if you don't have node in $PATH. And as you say. /opt apps normally aren't in $PATH. Looks like /usr/local wins.
        merb 11y ago
        It won't. Why should I install node in /opt? Mostly I install server-side or desktop apps there (which most other people do aswell (Chrome, Atlasssian)) They don't need to be in path since they are mostly called by initd or sytemd or .desktop file. Also they don't screw the system as others do that won't get installed with the package manager. Don't touch any directory without the package manager, if you still do use /opt.
        nailer 11y ago
        I think most people would install desktop apps via their package manager. Unpackaged apps are generally the exception rather than the rule. /usr/local is also outside the package manager as previously discussed.
- xorcist 11y ago
  FHS tries to stay relevant, but I'm not convinced it is. However the exact location is not the important point here. If no repository is available you should not proceed with anything until you have a plan in place how to keep track of updates and security issues. How often do you update? Do you backport security issues or upgrade? There will be backwards incompatible changes upstream which fixes security problems, and you need to have a plan in advance when in panic mode. And if no package is available you must first know why. Is it not supported? Is there a better way? What does that mean for your deployment? With this knowledge you create a package. Install it and keep a copy for future troubleshooting. Always use packages in Linux, unless you have a very good and specific reason not to. Under no circumstances should you drop untracked files in your environment, unless it is a one man show.
  - nailer 11y ago
    Yep, this is why the article pushes packages as the preferable install method. Thankfully the unpackaged binaries are officially maintained and also frequently updated. I'm actually really surprised you showed up again. You made a post loudly proclaiming the lack of packaging, high availability, and Ansible in an article that had all those things, in the opening paragraphs. I'm trying to think of a polite way to say this, but: putting down someone else's work based on it missing things it actually includes (since you haven't bothered to read the article) is incredibly rude. Perhaps you forgot something in your most recent reply?

nailer 11y ago

So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. The FHS forbids distros from installing software to either location. See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: > "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."

kiallmacinnes 11y ago
> So you'd prefer, if no packages are available, unpackaged software be installed to /opt rather than /usr/local? OK. Ah, I did miss the subfolder. This is a very unusual convention for installation into /usr/local. Typically, this is what modern day usage of /opt looks like. > The FHS forbids distros from installing software to either location. > See http://www.pathname.com/fhs/2.2/fhs-4.9.html http://www.pathname.com/fhs/2.2/fhs-4.9.html: Correct, both options are valid per the FHS. Yet, the description for /opt describes the pattern used in your example. See http://www.pathname.com/fhs/2.2/fhs-3.12.html http://www.pathname.com/fhs/2.2/fhs-3.12.html: "A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package."
- nailer 11y ago
  I see your point - I used to be reticent to use /opt since it was a bit of a Solaris-ism (it only got added to the FHS because the proprietary Unixes kept asking for it). I'm thinking about changing it to /opt instead (and will credit you if I do it), alas /opt/bin isn't in $PATH on most distros.
  - merb 11y ago
    They can't just add /opt/bin to $PATH Read the link he wrote down: > Programs to be invoked by users must be located in the > directory /opt/<package>/bin. If the package includes UNIX > manual pages, they must be located in /opt/<package>/man > and the same substructure as /usr/share/man must be used. Static packages should be kept together as /opt/myprogramm and mostly follow the same structure as /usr than so like: /opt/myprogramm/bin /opt/myprogramm/include /opt/myprogramm/lib ... Mostly I put my programs there, too. /opt/app1 /opt/app2
    - nailer 11y ago
      nod that's the thing - you'll break the interpreter for every node app - '#!/usr/bin/env node' - if you don't have node in $PATH. And as you say. /opt apps normally aren't in $PATH. Looks like /usr/local wins.
      - merb 11y ago
        It won't. Why should I install node in /opt? Mostly I install server-side or desktop apps there (which most other people do aswell (Chrome, Atlasssian)) They don't need to be in path since they are mostly called by initd or sytemd or .desktop file. Also they don't screw the system as others do that won't get installed with the package manager. Don't touch any directory without the package manager, if you still do use /opt.
        nailer 11y ago
        I think most people would install desktop apps via their package manager. Unpackaged apps are generally the exception rather than the rule. /usr/local is also outside the package manager as previously discussed.
xorcist 11y ago
FHS tries to stay relevant, but I'm not convinced it is. However the exact location is not the important point here. If no repository is available you should not proceed with anything until you have a plan in place how to keep track of updates and security issues. How often do you update? Do you backport security issues or upgrade? There will be backwards incompatible changes upstream which fixes security problems, and you need to have a plan in advance when in panic mode. And if no package is available you must first know why. Is it not supported? Is there a better way? What does that mean for your deployment? With this knowledge you create a package. Install it and keep a copy for future troubleshooting. Always use packages in Linux, unless you have a very good and specific reason not to. Under no circumstances should you drop untracked files in your environment, unless it is a one man show.
- nailer 11y ago
  Yep, this is why the article pushes packages as the preferable install method. Thankfully the unpackaged binaries are officially maintained and also frequently updated. I'm actually really surprised you showed up again. You made a post loudly proclaiming the lack of packaging, high availability, and Ansible in an article that had all those things, in the opening paragraphs. I'm trying to think of a polite way to say this, but: putting down someone else's work based on it missing things it actually includes (since you haven't bothered to read the article) is incredibly rude. Perhaps you forgot something in your most recent reply?