Install Scripts: Node.js 18.x.x incompatibility with CentOS 7 without warning

Help! (Home for newbies)
1
SYSTEM INFORMATION
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 :slight_smile: 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.

2

Agh! That’s awful. Thanks for the heads up. I guess we need to lock old distros to older node major versions.

3

Yes it is unexpected behavior on the part of Node.js!

Might you know how to get Node.js 18.2.0 fully out of my Install Scripts (see image)? I still would like to upgrade my live website from 17.8.0 to 17.9.0. I tried clearing what I thought was the cache for these scripts, but 18.2.0 continues to show up here.

In case it’s helpful, the incompatibility specifically is with Node.js 18.x.x requiring newer versions of GLIBC, GLIBCXX, and CXXABI that are more recent than those found in libstdc++.so.6, in my case v4.8.5-44.el7.x86_64.rpm

Screen Shot 2022-05-30 at 5.09.24 PM
Screen Shot 2022-05-30 at 5.09.24 PM790×88 20.9 KB

4

I believe you can edit /usr/libexec/webmin/virtual-server/pro/scripts/nodejs.pl to add the version you’re after in sub script_nodejs_versions. Webmin might need a restart to get it to see the change (I’m not sure whether this data is cached).

That will get overridden by script updates (those go into /etc) next time Virtualmin grabs the latest scripts, but I suspect Jamie will be able to get this sorted pretty quickly, so that shouldn’t be an issue for long (or you could disable those updates temporarily…I don’t remember where that’s set, probably in Virtualmin Configuration somewhere).

5

I appreciate the tip, though when I changed 18.2.0 to 17.9.0 in sub script_node_js_versions in the nodejs.pl file you referenced and restarted Webmin, 18.2.0 stuck as ever as the only option in that menu! I looked again to see if there was some other cache I could empty, but if there is one, I can’t find it.

My figuring this out isn’t such an issue, I just hoped I could update the live website I had in mind to 17.9.0. I’m so happy that I try out all Node.js and NPM updates on a staging website, since it gave me time to figure out the source of the 503 error by peeking in the server logs, then following threads to Github.

Good that you can mitigate this on your end! I believe that Node.js 18.x.x should either have thrown an incompatibility warning, or 18.x.x should’ve continued compatibility with older distros (from what I read, the EOLs may still be some ways out, and it’s possible they could’ve maintained support a bit longer).

A good reason to migrate from CentOS 7 to something else in the not-so-distant future! I’ve seen some conflicting opinions around CentOS 8, so hadn’t wanted to jump into it until I’d time to learn more, and possibly consider alternatives. Love Virtualmin/ Webmin by the way (though I s’pose it lets people like me manage servers, when perhaps we shouldn’t… sometimes I feel I know just enough to get myself in real trouble, but I’ve been hosting my own sites/emails with it since 2012, and it’s fun to learn new things!)

1 Like
6

Hmm…that should have done the thing. I’m trying to think of what other steps would be needed…I used to have to do this occasionally for Drupal, but I’m not recalling the exact steps.

@Jamie what else would need to happen to make a change in an Install Script (i.e. changing the available versions) show up? Actually, it looks like maybe there’s some other magic going on with 17 where it’s checking for LTS. I dunno exactly what’s happening there. The node installer is complicated.

7

So I solved my small part of this larger issue, by using Install Scripts to update to 18.2.0 briefly, simply so that I could get that input box where I could type the actual version I wanted the Install Script to use (which should, I realize now, be 16.15.0 LTS).

Thought I should let you know there’s nothing else I’m waiting on now from you, but I’m happy I noticed it on a staging site for others sake! Happy to close this issue, but I’ll leave it open right now, in case you update it once you push a fix locking old distros to pre-18 node versions.

Thanks again for your friendly and timely support, as always!

1 Like
8

Sure, leave it open until Jamie’s had a chance to look at it. I think we do want to protect users from this.

9

Seems like we should offer back version 17.9.0 if 18.x.x isn’t supported on older distros.

Unfortunately though there’s no facility in Virtualmin for downgrading a script…

10

There kind of is a facility that I used to do so in Virtualmin… if you upgrade to the most recent version, then once you’re at the “Latest” (which briefly breaks everything, but I left the Node.js server stopped throughout), the “Upgrade to Version” changes from a prefilled dropdown to, I think it was “Upgrade to Unsupported Version” with a box you can fill in the target version that you wish to install.

In my case I went with 16.15.0 LTS, since I’d like this rather high-traffic non-profit to stay ticking along safely (I’d been using 17.x.x because that mirrored my local dev environment, but now that I’m running 18.x.x locally, I lose that benefit, so I made the change to go back to 16.x.x LTS).

On a related note, I read that CentOS 8 had a premature EOL, so for the moment I’ll stay with CentOS 7 (which has an EOL of 6/30/24… though doubtless I should think about switching distros or otherwise upgrading sooner than later). Apparently there was a warning on this blog post that notified of unsupported distros: Node.js 18 is now available! | Node.js

11

I think we can skip 17.x. Just don’t let users on older distros upgrade to 18.x because it’ll break. The 16.x release is the stable LTS.

12

Why not … Couldn’t you use “Upgrade” To Unsupported version button?

image
image2178×950 314 KB

13

Good suggestion. I just checked in a fix for that.

Also, there was a bug in how Node.js server was re-started after upgrade.

@itmustbe Thank you very much for reporting this!

14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.