Vscode-remote-release: Workaround: Incompatible GLIBC+

[lars18th]

Hi,

I finally found a way to run the agent without having to update the GLIBC++ libraries. This solves
the issues described at #103. With this workaround it's possible to run the agent in almost _any_ Linux server, no matter how old it is. The basis is the use of a chroot environment, so there is no need to update the system or touch any current library. I explain it here in case the development team wants to take this idea to run the agent in an isolated environment.

The concept is more or less as follows (you have to be root):

• You install the package "schroot" and setup a modern distribution (compatible with the agent) in an isolated directory. Example: I have installed Debian 9.9 on a Debian 7 server. Search in the Web for a guide, it's quite easy using the "schroot" package.
• When your chrooted environment it's configured and running (check it with something like /usr/bin/schroot -c ...) then make this configuration:
  
  
  
  • Add a new user-alias for your user in your server. For example, if your username is user then edit the file /etc/passwd and add this line: useralias:x:1001:1001:,,,:/home/user:/bin/bash. This line is just a copy&paste of your current user configuration... changing only the username to a new alias (in this case useralias; you can use the name that you prefer).
  
  
  • Run _just one time_ this command: /usr/bin/schroot -u useralias --begin-session -c debian9 (in this case the -c debian9 is the name of the distribution to use). And SAVE the UID of the session (like debian9-be4e29ec-52e2-4bab-ac15-559944337722).
  
  
  • Configure the SSH daemon to use the chrooted environment for that user alias. So add this to your /etc/ssh/sshd_config file:
  
  

Match User useralias
   ForceCommand /usr/bin/schroot -u useralias --recover-session -c debian9-be4e29ec-52e2-4bab-ac15-559944337722 & /usr/bin/schroot -u useralias -r -c debian9-be4e29ec-52e2-4bab-ac15-559944337722 -- $SSH_ORIGINAL_COMMAND

• The purpose of this configuration is that: when your log-in to the SSH server with your user alias, the chrooted environment is restablished (using the --recover-session command) and after that a new shell is created inside this session and the SSH session is attached to it. The use of the same session every time it's mandatory as the agent is running in background.

After all this you only need to test your environment with a simple ssh useralias@server and confirm that you're inside the chroot environment but inside of your home directory. Don't care about the unmount ... : device is busy errors, they appear if the session is already running.

From this point you can configure the VSCODE Remote SSH extension, and I'm sure now you can run it without troubles... if you use your _useralias_ name! :wink:

But now you're probably asking yourself: But I just want to compile and run in my native environment, not in the chroot environment. Ok, don't worry! Just open another SSH session using your regular user, and inside the terminal you can run every compile commands: configure, make, etc. Even for debugging use the gdbserver and use a custom TCP port to communicate with the VSCode. Just take note that the agent is running inside the chroot environment and you use the stock environment, but the HOME is shared.

It is certain that this solution can be improved. But I feel that it is a starting point to solve the problem of the incompatible libraries with the agent. I'm sure you can improve it. :tada:

Regards.

[khou2020]

Hi,
I finally found a way to run the agent without having to update the GLIBC++ libraries. This solves
the issues described at #103. With this workaround it's possible to run the agent in almost any Linux server, no matter how old it is. The basis is the use of a chroot environment, so there is no need to update the system or touch any current library. I explain it here in case the development team wants to take this idea to run the agent in an isolated environment.
The concept is more or less as follows (you have to be root):

You install the package "schroot" and setup a modern distribution (compatible with the agent) in an isolated directory. Example: I have installed Debian 9.9 on a Debian 7 server. Search in the Web for a guide, it's quite easy using the "schroot" package.
When your chrooted environment it's configured and running (check it with something like /usr/bin/schroot -c ...) then make this configuration:

Add a new user-alias for your user in your server. For example, if your username is user then edit the file /etc/passwd and add this line: useralias:x:1001:1001:,,,:/home/user:/bin/bash. This line is just a copy&paste of your current user configuration... changing only the username to a new alias (in this case useralias; you can use the name that you prefer).
Run just one time this command: /usr/bin/schroot -u useralias --begin-session -c debian9 (in this case the -c debian9 is the name of the distribution to use). And SAVE the UID of the session (like debian9-be4e29ec-52e2-4bab-ac15-559944337722).
Configure the SSH daemon to use the chrooted environment for that user alias. So add this to your /etc/ssh/sshd_config file:

Match User useralias
ForceCommand /usr/bin/schroot -u useralias --recover-session -c debian9-be4e29ec-52e2-4bab-ac15-559944337722 & /usr/bin/schroot -u useralias -r -c debian9-be4e29ec-52e2-4bab-ac15-559944337722 -- $SSH_ORIGINAL_COMMAND

The purpose of this configuration is that: when your log-in to the SSH server with your user alias, the chrooted environment is restablished (using the --recover-session command) and after that a new shell is created inside this session and the SSH session is attached to it. The use of the same session every time it's mandatory as the agent is running in background.

After all this you only need to test your environment with a simple ssh useralias@server and confirm that you're inside the chroot environment but inside of your home directory. Don't care about the unmount ... : device is busy errors, they appear if the session is already running.
From this point you can configure the VSCODE Remote SSH extension, and I'm sure now you can run it without troubles... if you use your useralias name! 😉
But now you're probably asking yourself: But I just want to compile and run in my native environment, not in the chroot environment. Ok, don't worry! Just open another SSH session using your regular user, and inside the terminal you can run every compile commands: configure, make, etc. Even for debugging use the gdbserver and use a custom TCP port to communicate with the VSCode. Just take note that the agent is running inside the chroot environment and you use the stock environment, but the HOME is shared.
It is certain that this solution can be improved. But I feel that it is a starting point to solve the problem of the incompatible libraries with the agent. I'm sure you can improve it. 🎉
Regards.

Is there any alternative that don't require root? I believe many people who cannot update GLIBC is because root privilege.

[lars18th]

Hi @khou2020 ,

Is there any alternative that don't require root? I believe many people who cannot update GLIBC is because root privilege.

Yes and not. Let me to explain why:

• To install some libraries (or compile them in your server) you don't need root privileges. That's true if you "install" (copy) them inside your home directory. Futhermore, what I described here confirms that it's possible to: 1) run the VS agent using different libraries despite the system libraries; and 2) it's possible the use the VS SSH extension in a environment using unsupported system libraries (because the compilation and debug of your project it's indepedent of the execution of the VS agent).

So, what you need to request to the MS developers is that they prepare an independent package (in source code form) to create a "runtime environment for the VS agent" that doesn't require root privileges AND the support for execute the VS agent inside this environment.

When these two requirements are met, you can use it without root privileges. Until they do, this is the only solution (IMHO) to use this extension in an unsupported environment.

Regards.

[roblourens]

Thanks for the suggestion! Hopefully people can set this up themselves if needed but we aren't planning any other work here currently, and will leave #103 to track the root problem.

[vscodebot[bot]]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!