There’s a module called virtualmin-init which allows users to manage their own actions to be run on boot. Package is webmin-virtualmin-init on Ubuntu/Debian and wbm-virtualmin-init on RHEL-based distros.
I’m not sure how well-maintained it is, it’s not super commonly used (but maybe should be, since it’s so common to run user-managed app servers these days).
And, let us know if you run into any problems with it. We probably should consider this core functionality these days (again, app servers super common now), but I don’t think a lot of people know about it, so it hasn’t gotten much usage.
That is the first part of the problem - knowing about something is the first step because then it gets used then only then can issues with it be identified to indicate a need for maintenance.
-makes me wonder how many other packages are available but lost to public use.
I think about to create a simple virtualmin module especially to handle nodejs stuff.
It should do what I currently do with custom-commands:
Make the user able to:
activate / install nodejs support
show available versions of node
choose version of used node version
and additional to that
5. init a pm2 or forever process for any app i like to run
I little hurdle:
It would be nice to also have a nice implementation to simply do a proxy-redirect for a given Port in NGINX and Apache.
But for the first steps it would be ok to me to manage this manually in the nginx-conf files.
Ok, I figured out the whole process that is need to fully setup an nodeJS app, like described in my previous post.
It’s from activating node for a VirtualServer over running yarn commands up to make the process reboot-safe and removeable.
Currently it’s fully handled only by Custom Commands, and one manual setting in Nginx-Conf for Reverse-Proxy.
It’s ok, but bad UX. So I would love to create (with helping hands) an own “Nginx-Node Module” out of it to make this more straight-forward to use.
Expert knowledge needed:
Only last thing I need some support and knowledge from the experts is following:
For my testing purposes I hard-coded a Proxy-Reverse entry to 127.0.0.1:3000, as nextJS generally use Port 3000 on startup.
It’s no big thing to change the port during nextJS startup to anything else, but the question is, how to prevent a port collision with other users?
As other users at the same server couldn’t know which ports are already in use, there should be a way to handle it fail-save.
“nextjs” why restrict to this framework?
Nearly all my users have no interest in nextjs as they prefer express or other frameworks
nearly all, but not all, use NodeJS and a few are even considering a move to me2 alternatives or even better server-side such as “Go”
The port issue is even more important as it affects everyone non one uses 3000 and when left to the client you will always get collisions - they could even choose 1000 or 2000 and if you try to enforce it ($%£&!) well do you need the added hassle?
At the moment I take over the whole process so I am also interested in an easy solution that can be passed on to the individual user.
Virtualmin does protect ports and can keep up with which users are allowed to use which ports; I don’t know if that’s easily user-visible, though. @Jamie is the port protection stuff available to end users? Can it be made available to end users? (I mean, I know scripts that need a proxied port get one assigned and are prevented from squatting on other user ports, but I don’t see an obvious way to get a port that isn’t associated with an Install Script which is very limiting.)
Also, I’ll mention that though Virtualmin has awareness of ports, it’s probably better to proxy to UNIX named sockets instead of ports. Named sockets can be owned by the user, and thus they don’t need any hacky protections…another user can’t possibly squat on a file owned by another user. Most app servers work fine on named sockets, and with only minor configuration changes. (We also should have better GUI support for proxying to UNIX sockets, @Jamie. Maybe it’s already possible, since it’s the same directives, you just use a path like unix:/path/to/socket instead of http://localhost:3000 or whatever. Maybe we just need more explicit docs about it.)
Virtualmin can also install node.js, setup proxying for it and start it at boot already, using the Install Scripts page. You could presumably do this to get a vanilla node.js install, and then configure it to run your app. This will also take care of port protection…