I'm running Alpine 3.12 with the latest 64-bit kernel. Installed VS extension for remote server ssh connections and by trying to connect, I see that the process has downloaded a folder ".vscode-server" on my remote server, which means that the connection happened, but after loading for some time I receive this message "The remote host may not meet VS Code Server's prerequisites for glibc and libstdc++". I did some googling on this, and I see that a few people were having trouble as they didn't have enough space on their server storage to install some libraries, but this is not the case for me. The extension itself provides me with this link https://code.visualstudio.com/docs/remote/linux#_remote-host-container-wsl-linux-prerequisites explaining that there could be problems for Alpine based systems, but it should work anyways, but I can't quite find the problem. Maybe someone has faced this issue and can guide me to the solution?
Related
I've been able to follow similar answers for offline installing vscode-server on remote linux targets but I cannot find out how to do this for windows. On the official page for vscode-remote-ssh https://code.visualstudio.com/docs/remote/ssh, it shows that the system requirements for the remote supports Windows 10 / Server 2016/2019 (1803+) using the official OpenSSH Server. So I know it's possible I just can't seem to find the download link that vscode-remote-dev uses to download the windows version of vscode server.
The download link for linux follows this format https://update.code.visualstudio.com/commit:${commit_id}/server-linux-x64/stable would there be a specific endpoint for server-windows? I've tried a bunch of different combinations but I could not get anything.
I'm also making the assumption that there is a different download link but it seems a very unlikely case that linux and windows share the same link.
Any help would be appreciated. I've enjoyed using this for remote dev on linux and now I've got an opportunity to use it on windows.
Instead of using server-linux-x64, server-win32-x64 should be used and it will download the correct windows version of the vscode-server.
I did find this in the comments of this question. Using "Remote SSH" in VSCode on a target machine that only allows inbound SSH connections.
I am trying to create an extension. The catch is that I am doing this on a server to which I am connected with the ssh extension.
I am using yo for the boilerplate and I follow the basic steps here to create a hello world project.
When I launch the debugger with F5, a new VS Code instance on the remote server is launched, but the extension is not installed in that instance. I am also not able to execute the command.
As side-information, this is a raspberry Pi, so its 32 bit arm.
So the question is, is this generally possible to develop extensions on a Remote Host and if so, could the issue be related to the architecture of the Pi?
I could probably delete this question, but I will answer instead, maybe one day someone has the same problem.
When running yo code, the generated manifest will mark the extension as compatible with the latest VS Code engine. This may or may not be the version that is actually installed on your system.
"engines": {
"vscode": "^1.56"
}
For this example, the version is 1.56. When I check for the installed version I see its 1.55.2 though.
$ code -v
1.55.2
3c4e3df9e89829dce27b7b5c24508306b151f30d
arm
When setting the engine in the manifest to at max the version in your system, it works as described in my question above.
Logically, if the version is too high, the extension won't be installed in any workspace.
I found this page also helpful, for the topic in general -> https://code.visualstudio.com/api/advanced-topics/remote-extensions
I use Visual Studio Code and RemoteSSH extension to connect to a remote server located across the ocean via the corporate VPN, The connection gets established when I connect via my mobile hotspot, but it keeps showing "Attempting to reconnect" asking for password repeatedly when I use my broadband.
I have compared the internet speed of both the service providers and below are the results.
1)Airtel hotspot(remote ssh works)
2)Hathway broadband(remote ssh does'nt work)
From the above images it is evident that my broadband speed(upload and download) is much better than my internet hotspot speed, In spite of this I am unable to use remote ssh to code using my broadband network, Is there something that needs to be tweaked, or are the internet speed tests in a way inaccurate?
I had similar experience and there are many threads on the subject, none of which resolved it for me.
I am working on a Windows laptop and connecting to remote Centos linux.
I also connect to company network via their VPN.
I resolved it in the following manner, maybe not all steps are required, but this is what I did -but firstly, I setup ssh keys so as not to have to keep using a password, well worth the effort.
Updated the fileWatcher in code to ignore .git folder and venv folder, this improves performance
Updated WSL to WSL2
Install a linux shell on Windows - I was already using an Ubuntu one, installed prior to vscode, but hints online suggested installing it after vscode, so I installed the Kali shell.
Installed openssh-server (to get ssh-keygen) on kali
Launched code from the kali shell, let it do its setup
Even though all extensions were installed on both machine, vscode didn't recognize that and I had to use the option in the extension section to "install exentsions on remote server"
After that, every thing was fine.
Hope that helps anyone else searching this problem.
In Airtel hotspot, your public IP address remains the same.
In case of Hathway broadband, public IP changes very frequently. So, if your VPN is redirecting you over IP, there may be possibility of delay because of authentication verification.
Since I mostly develop Web, using nginx, PHP and MySQL, I have ported my WebDev-environment entirely to WSL2.
Since performance is very important, all my web-related projects reside on the WSL2-vhdx file /home/user/Projects/Web. In WSL2 I've installed all my necessary tools for a nice and neat Linux-like experience, Docker, GIT, etc.. This combined with VSCode remote integration works very well.
Now, I'm digging into building Flutter-Apps, and my Flutter-environment is installed on the Windows side. My Flutter-related projects reside on D:\Projects\Flutter which is a partition, and NOT USED in WSL2 in any way. Building Flutter-apps with flutter-windows-sdk and VSCode works neatly.
But, the problem is: Now I've my project files scattered all across my computer. Web-stuff in a WSL2-vhdx-file and Flutter-stuff on the D-partition.
Is there a way to build flutter-apps with Flutter, while having the project-files stored on a WSL2-vhdx-file, in combination with VSCode-remote and an Android-emulator?
I tried creating a test Flutter-project on the \\wsl$ network mount, which didn't work.
Moving my web-related project files to the D:\ partition of Windows is no option, since the I/O mounts in WSL2 are extremely slow.
I got it working, reliably with adb connect 192.168.xxx
For anyone interested, see my full blog post here: https://dnmc.in/2021/01/25/setting-up-flutter-natively-with-wsl2-vs-code-hot-reload/
Is there a way to build flutter-apps with Flutter, while having the project-files stored on a WSL2-vhdx-file, in combination with VSCode-remote and an Android-emulator?
I'm assuming (based on the mention of VS Code Remoting) that you want to run the extension in WSL. I haven't tried that specifically, but I have run Flutter inside WSL and also connected a VS Code Remoting session to an Android emulator in the cloud, so I would expect this to work.
You'll need to make sure you set up the Flutter SDK inside WSL (so you can run flutter commands inside WSL - it should be the Linux version of the Flutter SDK and not the Windows one if you're using the zip).
To have your emulator show up in flutter devices from inside WSL, you will likely need to run adb tcpip 5555 from the Windows side (this means you need an Android SDK in Windows) - this will tell your phone to listen on TCP port 5555. Then you'll need to run adb connect [phone ip]:5555 from inside WSL (this means you'll need an Android SDK in Linux). If all goes well, the phone should then show up in adb devices and also be picked up by the device selector in VS Code.
I tried creating a test Flutter-project on the \wsl$ network mount, which didn't work.
It's not clear what went wrong here, though my first guess would be that maybe the UNC path isn't supported - if you map a drive letter to it does it make a difference?
While this isn't an officially supported setup, feel free to raise issues in the Dart-Code repository on GitHub with any issues you have. It's not a priority, but I would like for VS Code Remoting (including WSL and Docker) to generally work for Dart and Flutter dev.
Anytime you're crossing/sharing the file-system boundary from windows to wsl you're paying a massive cost in speed/time.
With the setup you've described I'd consider trying to self-host the browser based VSCode.dev inside wsl - checkout details instructions here: https://medium.com/geekculture/3-steps-to-code-from-anywhere-45401247f479
Personally I've settled on running VSCode and docker inside a Linux VM on Windows, and have a 96% time saving in things like running up a server and watching code for changes making this setup my preferred way now.
The standardisation of devcontainer.json and being able to use github codespaces if you're away from your normal dev machine make this whole setup a pleasure to use.
see https://stackoverflow.com/a/72787362/183005 for detailed timing comparison and setup details
I want to run Visual Studio Code Remote Development using SSH to my Raspberry Pi 3 Model B+ running Raspbian GNU/Linux 9 (stretch).
I have tried to follow the "Getting started" instructions. I run the command Remote-SSH: Connect to Host..., but I get the message Can't connect to admin#pihole.local: unreachable or not Linux x86_64 (Linux armv7l )
As far as I know, Raspbian is 32 bit. So, does this mean that what I want to achieve is impossible?
I can connect to the Raspberry Pi using ssh on the command line without problems (not password based).
I'm running VS Code insiders on macOS Mojave 10.14.4.
Update 2: As of the 10th of February, x86_64, ARMv7l (AArch32) and ARMv8l (AArch64) are the supported Linux architectures for Remote SSH. It it appears that a glibc based Linux distribution is needed to meet certain prerequisites/dependencies. There is also experimental support for Windows 10/Windows Server 2016/2019 in the Insiders builds. More information can be found on the prerequisites information page.
Update: As of the 12th of June, approximately one month after my answer to this, support was added for the Raspberry Pi 3. There is no support for other ARM architectures yet, and this does not work with the Raspberry Pi Zero W yet, but I'm not sure about the Raspberry Pi 1 or 2. One point to note at present is that you need to setup public key authentication so you have passwordless login, otherwise you'll need to enter your Raspberry Pi's password multiple times, and it will ultimately fail. Also, as mentioned in a comment, if you've tried the 'stable' Remote Development extensions and found out they didn't work... you need to make sure you remove them from both VSCode AND your Raspberry Pi... else it really won't work. This is also mentioned in the Github issue.
Because of how the Remote SSH function actually work, when you connect to your SSH host, the Remote SSH extension provisions the so-called VS Code Server to that host, so the VS Code Server has to be able to run in your remote environment. Consequently, at present, each architecture may need different implementations or tweaks, before it will be considered 'supported'. At the time of writing, there are no armv7l builds, but this recently changed. We're still early days for this useful looking functionality... but things are changing quickly... There is no Windows or MacOS SSH host support at present... but this may not be the case in another months time.
There is an issue open on GitHub on this topic, so it may be worth keeping an eye on it or subscribing to it to see if/when support is added.