Provide legacy server when remote requirements fail

[deepak1556]

Following options were considered,

1. Build Node.js with --fully-static option

   • No versioning issue from glibc and libstdc++
   • Symbols are not exported which means native modules (which are dynamic libraries) cannot be loaded

2. Build Node.js with --partly-static option

   • glibc is still dynamic so versioning issue persists
   • with native modules this mode will be a footgun

3. Using alpine binaries as fallback

   • musl is dynamically linked in both core native modules as well as executable, which means it cannot be loaded in glibc platforms

4. Shipping glibc, libstdc++ dynamic libraries as part of the server package

   • We would need to change the executable rpath to load these libraries which would then be picked up by any other dynamic libraries that get loaded into the executable (applies to native node modules). Will work for all cases
   • Downside is we are now committing to track cve fixes in both these libraries

Legacy Server:

We have pre-requisite checks for both exec server path as well as the normal remote connection path. Idea is that when the checks fail we will download what we call Legacy server on these machines and everything else should work as expected,

• Server and core node modules are built using sysroot containing glibc 2.17 and gcc 7
• Downgrades the minimum requirements to GLIBC >= 2.17 and GLIBCXX >= 3.4.19
• This is the server that was shipped in 1.85 release, already has enough testing in stable
• Downside is how long this can be provided by us, at the moment Node.js v18 can be built in this toolchain and when we update to Electron 29 this will bring in Node.js v20 which can also be built at the moment but there are no guarantees when it will break

Steps for adopting legacy server:

• Merge https://github.com/microsoft/vscode/tree/robo/setup_fallback_remote_server to main which now publishes the legacy server alongside the default server

• Currently published as server-linux-<arch>-fallback but will change the name to legacy-server-linux-<arch> to reflect the nature of this build before merging.

• Remote extensions and CLI should make a change to download legacy-server-linux-<arch> build over server-linux-<arch> when the requirements check fail. This is where I need help from the relevant owners in adopting the change /cc @connor4312 @chrmarti @aeschli @roblourens

• Create a banner on VS Code client to signal user when legacy server is used, this is a requirement to make it obvious that the server connection being used has a definite EOL.

[deepak1556]

@aeschli @roblourens feel free to skip this issue if you are busy on other tasks, I can work with @connor4312 and @chrmarti to cover SSH and WSL extensions as well.

[hitzhangjie]

VSCode just notifies there's update but it didn't warn the glibc minimum version is changed to 2.28+ and they may fail to connect in SSH Remote way. This breaking change .... Please provides a way to work around this rather than suggesting downgrade to 1.85.2. Many developers are waiting this 1.86 release because it fixes some bugs in 1.85.x.

[deepak1556]

@hitzhangjie please follow #203375 for updates

[connor4312]

I made a draft PR (#204194) that supports the legacy-server-linux-<arch> format in the CLI/exec server. I tested it and it should be good to go once those artifacts are published.

[connor4312]

Also, note that GLIBCXX >= 3.4.22 is higher than what was previously required (3.4.18) and doesn't work on CentOS 7. I reverted back to 3.4.18 in my PR but can change that if it's incorrect...

[deepak1556]

Also, note that GLIBCXX >= 3.4.22 is higher than what was previously required (3.4.18) and doesn't work on CentOS 7. I reverted back to 3.4.18 in my PR but can change that if it's incorrect...

Yeah that was an error, updated the description. We are building on CentOS images which has maximum of 3.4.19, so I have set the new requirements to GLIBCXX >= 3.4.19 and GLIBC >= 2.17

[isidorn]

Closing in favour of #204344