4 ms·

My experiences with node include being extremely difficult to install on centos because a dependency was removed from the EPEL repo and random npm packages curl

My experiences with node include being extremely difficult to install on centos because a dependency was removed from the EPEL repo and random npm packages curling things from random git repos and other sites as part of their install process gross

gear54rus 9y ago
I do always use Centos. I'll be honest I never tried to install it via package manager (because chances are its version would lag behind the official release). You can use nvm (https://github.com/creationix/nvm https://github.com/creationix/nvm) to install only for one user (inside $HOME) or manual install from release page for all users (cp -r */ /usr when inside the unpacked dir): https://nodejs.org/en/download/ https://nodejs.org/en/download/ It will work flawlessly both ways without using any package managers for your system. What is so hard about that for people?
- zaarn 9y ago
  Sometimes you want to run something written in NodeJS as a service user which naturally and usually does not have a home folder at all. Additionally, having to sync up the user installation and service installation if you then create the home folder is a source for bugs both in service and user that can't be crossreplicated between the two. A global installation is desirable when multiple users are required to operate on the exact same versions of a service.
  - gear54rus 9y ago
    I don't see what you're getting at. But if I understood correctly the answer would be: You can just download node, put it anywhere and it will work as long as you add './bin' to 'PATH'. This can be done on per-command basis as you probably know: PATH=$PATH:/node/location/bin npm -g i leftpad
    - zaarn 9y ago
      Suppose I want to run the service leftpad.io For this purpose I would have a service user called "leftpad-srv" under which my leftpad.io server runs. When I login, I am "root". When I want to say, change leftpadding from spaces to tabs, I'd call `leftpad-io-ctl set-padding \t` which would use a socket to communicate with the leftpad.io server. For this purpose it would be very important that leftpad-io-ctl and the leftpad-io server are the same version, otherwise the -ctl might support setting a rightpad even though the server hasn't implemented this yet because they have two different versions. A global install is necessary for many deployments. (This is hypothetical but many apps have special ctl-tools to control or monitor the running application and it can be useful to, for example, have moderators in your app that can access the console with limited permissions)
      - gear54rus 9y ago
        So what is tricky about this? Global install is cp -r */ /usr inside the downloaded release folder. I'm probably still missing something.
        zaarn 9y ago
        A package manager ensures that the install is correctly available for all users. With apps, same story, it ensures everyone has the app. Install via cp -r / /usr is not a good idea as the package manager has no idea you are doing this and won't help you out. In a worst case, the package manager will trample all over the install. Additionally, a simple cp -r / /usr will probably not set correct permissions automatically, which means either users can edit the binary or won't be able to execute it. Lastly, it means any update will have to be installed manually for every single release. Package managers do this automatically and with much less friction.
  - lmm 9y ago
    > Sometimes you want to run something written in NodeJS as a service user which naturally and usually does not have a home folder at all. The idea of using an isolated user and a shared filesystem makes no sense; it's the security model you come up with due to random accidents of unix history, not one that you'd design from the ground up. If you want your NodeJS service isolated, do it properly: use a jail or container, which work beautifully with npm (and are much more awkward to do with RPM). > Additionally, having to sync up the user installation and service installation if you then create the home folder is a source for bugs both in service and user that can't be crossreplicated between the two. On the contrary, it forces good practice by ensuring that you always know how to install the set of dependencies that you need; you use the same source of truth to install the dependencies as both. When you rely on system installs of packages, you create exactly the same problem when you come to run the program on multiple servers, only less fail-fast and harder to diagnose. > A global installation is desirable when multiple users are required to operate on the exact same versions of a service. If you get in a position where that's you're requirement, you've done something wrong. Take a step back and figure out what you really need.
    - zaarn 9y ago
      >The idea of using an isolated user and a shared filesystem makes no sense; I do run my stuff in containers, I have about 30 of them setup, each one with it's own service. However, I still have to login into these containers, which happens as root (for the container). And then having to pivot to the app user is bothersome. Luckily or strangely a lot of applications don't work as root because nobody should be running any service as root. >On the contrary, it forces good practice by ensuring that you always know how to install the set of dependencies that you need; I have automated deployment for that. I simply add a python script to my fabric repository and signal which container should install it, the rest is fully automated and tested. User-local installs are complicated here since it means the deployment script will have to pivot to another user temporarily. >When you rely on system installs of packages, you create exactly the same problem when you come to run the program on multiple servers, only less fail-fast and harder to diagnose. I also create a reproducable problem, user-local installs are less reproducable, in my experience. I can replicate the exact environment of an app server installed via apt-get within a few keystrokes (I wrote a fabric task for that; "fabric copy-deployment <sourcecontainer> <targetcontainer>") >If you get in a position where that's you're requirement, you've done something wrong. Take a step back and figure out what you really need. You mean like running multiple instances of the same service? That happens. Maybe you want to deploy three seperate instances of AppSomething for three domains with three seperate datasets. Instead of deploying three containers, I deploy one container.

gear54rus 9y ago

I do always use Centos. I'll be honest I never tried to install it via package manager (because chances are its version would lag behind the official release). You can use nvm (https://github.com/creationix/nvm https://github.com/creationix/nvm) to install only for one user (inside $HOME) or manual install from release page for all users (cp -r */ /usr when inside the unpacked dir): https://nodejs.org/en/download/ https://nodejs.org/en/download/ It will work flawlessly both ways without using any package managers for your system. What is so hard about that for people?

zaarn 9y ago
Sometimes you want to run something written in NodeJS as a service user which naturally and usually does not have a home folder at all. Additionally, having to sync up the user installation and service installation if you then create the home folder is a source for bugs both in service and user that can't be crossreplicated between the two. A global installation is desirable when multiple users are required to operate on the exact same versions of a service.
- gear54rus 9y ago
  I don't see what you're getting at. But if I understood correctly the answer would be: You can just download node, put it anywhere and it will work as long as you add './bin' to 'PATH'. This can be done on per-command basis as you probably know: PATH=$PATH:/node/location/bin npm -g i leftpad
  - zaarn 9y ago
    Suppose I want to run the service leftpad.io For this purpose I would have a service user called "leftpad-srv" under which my leftpad.io server runs. When I login, I am "root". When I want to say, change leftpadding from spaces to tabs, I'd call `leftpad-io-ctl set-padding \t` which would use a socket to communicate with the leftpad.io server. For this purpose it would be very important that leftpad-io-ctl and the leftpad-io server are the same version, otherwise the -ctl might support setting a rightpad even though the server hasn't implemented this yet because they have two different versions. A global install is necessary for many deployments. (This is hypothetical but many apps have special ctl-tools to control or monitor the running application and it can be useful to, for example, have moderators in your app that can access the console with limited permissions)
    - gear54rus 9y ago
      So what is tricky about this? Global install is cp -r */ /usr inside the downloaded release folder. I'm probably still missing something.
      - zaarn 9y ago
        A package manager ensures that the install is correctly available for all users. With apps, same story, it ensures everyone has the app. Install via cp -r / /usr is not a good idea as the package manager has no idea you are doing this and won't help you out. In a worst case, the package manager will trample all over the install. Additionally, a simple cp -r / /usr will probably not set correct permissions automatically, which means either users can edit the binary or won't be able to execute it. Lastly, it means any update will have to be installed manually for every single release. Package managers do this automatically and with much less friction.
- lmm 9y ago
  > Sometimes you want to run something written in NodeJS as a service user which naturally and usually does not have a home folder at all. The idea of using an isolated user and a shared filesystem makes no sense; it's the security model you come up with due to random accidents of unix history, not one that you'd design from the ground up. If you want your NodeJS service isolated, do it properly: use a jail or container, which work beautifully with npm (and are much more awkward to do with RPM). > Additionally, having to sync up the user installation and service installation if you then create the home folder is a source for bugs both in service and user that can't be crossreplicated between the two. On the contrary, it forces good practice by ensuring that you always know how to install the set of dependencies that you need; you use the same source of truth to install the dependencies as both. When you rely on system installs of packages, you create exactly the same problem when you come to run the program on multiple servers, only less fail-fast and harder to diagnose. > A global installation is desirable when multiple users are required to operate on the exact same versions of a service. If you get in a position where that's you're requirement, you've done something wrong. Take a step back and figure out what you really need.
  - zaarn 9y ago
    >The idea of using an isolated user and a shared filesystem makes no sense; I do run my stuff in containers, I have about 30 of them setup, each one with it's own service. However, I still have to login into these containers, which happens as root (for the container). And then having to pivot to the app user is bothersome. Luckily or strangely a lot of applications don't work as root because nobody should be running any service as root. >On the contrary, it forces good practice by ensuring that you always know how to install the set of dependencies that you need; I have automated deployment for that. I simply add a python script to my fabric repository and signal which container should install it, the rest is fully automated and tested. User-local installs are complicated here since it means the deployment script will have to pivot to another user temporarily. >When you rely on system installs of packages, you create exactly the same problem when you come to run the program on multiple servers, only less fail-fast and harder to diagnose. I also create a reproducable problem, user-local installs are less reproducable, in my experience. I can replicate the exact environment of an app server installed via apt-get within a few keystrokes (I wrote a fabric task for that; "fabric copy-deployment <sourcecontainer> <targetcontainer>") >If you get in a position where that's you're requirement, you've done something wrong. Take a step back and figure out what you really need. You mean like running multiple instances of the same service? That happens. Maybe you want to deploy three seperate instances of AppSomething for three domains with three seperate datasets. Instead of deploying three containers, I deploy one container.