|OS type and version||CentOS Linux 7.9.2009|
|Virtualmin version||7.1 Pro|
I recently did what I thought would be a routine update to Node.js from 17.8.0 to 18.2.0, using your Install Scripts in Virtualmin (an update process I do from time to time).
Unfortunately there’s an issue with Node.js 18.x.x no longer support CentOS 7 and similar distros: see NodeJS 18 revert to building on CentOS 7, RHEL 7, Ubuntu Bionic 18.04, other other LTS distros · Issue #43246 · nodejs/node · GitHub
After investigating further (thinking at first I could update libstdc++), I realized I needed to roll back to Node.js 17.x.x
I was able to do this for the staging site that I’d broken by going into Virtualmin > Install Scripts > Node.js > filling in 17.9.0 and “upgrading” to that older version.
I then went to update the live (as opposed to staging) site from 17.8.0 to 17.9.0, and assumed I’d be able to do that easily. However, instead of being able to write “17.9.0” in the box next to specific version, Virtualmin prefills 18.2.0 in the dropdown, and there’s no way to specify 17.9.0 instead.
I tried clearing the cache within Webmin (under Webmin Configuration > Proxy Servers & Downloads) and I did that successfully, but when I went back to the virtual server in question in Virtualmin, the dropdown continues to specify 18.2.0, with no way for me to write in 17.9.0 as the desired installation.
I suppose I could update to 18.2.0 and then I’d guess that I’d be able to write in 17.9.0 in the Node.js Install Scripts box, just as I did with the staging site. But I’d rather update directly from 17.8.0 to 17.9.0. How do I clear 18.2.0 from being preselected in the Install Scripts dropdown for Node.js at this point?
If only I could specify 17.9.0 I’d be good It’s too bad that Node.js 18.x.x throws no warnings, when it is incompatible with CentOS 7, RHEL 7, Ubuntu Bionic 18.04 and other LTS distros (according to GitHub issue). If other users like me, who’ve not yet had the time to migrate to CentOS 8, click to update their Node.js script using Install Scripts, they’re going to run into the same issue, yielding a 503 error on their site.