here is my debug configuration :
{
"type": "node",
"request": "attach",
"name": "testServer",
"address": "test.server.ip",
"port": 5858,
"localRoot": "${workspaceRoot}/test/server",
"remoteRoot": "~/App/test/server"
}
I have started remote application in debug mode successfully by using below command
node --debug app
Then I start VS Code debugger using testServer configuration. it print error:
Debugging with legacy protocol because Node.js version could not be determined (Error: timeout)
I am using VS Code version 1.16.1 on macOS sierra.
I guess it's not able to connect remote server because it's secured by SSH. But I can't see any configuration related to SSH in VS Code debugger's configuration.
I have already gone through some articles and issues like this
andthis, but no help.
Thanks for any help.
You'll need to start the remote application, and tell node to expose the port remotely with the following command:
node app --inspect=0.0.0.0:5858
I got it working like that on Windows :
Create a new putty session with hostname, your remote server, and go to "Tunnels" under the SSH dropdown, then configure it like it :
Run node debug on your remote host and copy the port it give to you (For me 9229)
Run node debug
Then fill Putty like that :
Fill putty tunnel
You can now save this session, and then open it.
Now, every time you will open this SSH session, everything happening on your remote server on port 9229 will be redirected to your local 9229 port.
In VSCode, the config is now really simple, because it's like you are on local :
{
"type": "node",
"request": "attach",
"name": "Attach",
"port": 9229
},
Hope it helped
Related
I attached vs code to a running Django container and a Dev Container window popped up. I need to see the real time logs of the container. In attach mode we cannot choose run without debugging option. So we need to open a local terminal and run the command docker attach <container_id>. We can start a local terminal by selecting create integrated terminal (local) from the command palette. Instead of doing the same every time, I thought creating a custom task would be good idea which can trigger these commands on opening the dev container window.
I wrote the following configuration. But it seems that it is referring to the shell of container instead that of the host machine, therefore it is unable to find docker.
So, how can we configure a task in vs-code dev container window which can use shell commands from the host's machine?
{
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "Run a shell command",
"command": "docker attach <container_id>",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
In Visual Studio Code's settings, you can easily add custom terminal profiles like this:
"terminal.integrated.profiles.linux": {
"test": {
"path": "bash",
"icon": "terminal-bash",
}
}
This will open a terminal host for the host on which the vscode server is running (local, devcontainer, remote over ssh, etc).
With that said, VS Code is still capable of opening a local terminal on the host regardless of where it the server is running with the workbench.action.terminal.newLocal command:
Is it possible to write a terminal profile to open a local terminal from the usual UI?
I have a Windows 10 machine with VSCode that connects to my ubuntu wsl2 instance. I have a webserver and database installed on this wsl2 instance. I would like, for this folder, to be able to have F5 open the particular file I have selected in a web browser at the current path.
Say my domain is (which resolves to my wsl2 ubuntu apache2 instance)
dev.local
My pwd is
/var/www/dev/application
that I have open in vscode with WSL.
My apache virtual host starts at that same path
/var/www/dev/application
I would like say Edge to open with the pwd replaced with http://dev.local and the path + filename to to be added to the end of that. So if I am editing index.html it should open to http://dev.local/index.html. If I am editing includes/css/signin.css then it should open to http://dev.local/includes/css/signin.css when I hit F5. Is this possible with the launch.json file? I have it opening in edge but just don't have the variables correct if it is possible
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "pwa-msedge",
"request": "launch",
"name": "Launch Edge against localhost",
"url": "http://dev.local/${workspaceFolder}"
}
]
}
I have VS Code running on macOS connecting to a linux box where I am doing Go development. I am connecting via a user that has sudo privileges on the linux host. The root account is disabled on the remote host.
The application I am writing needs to run with root privileges. Is there a way to set vscode to elevate privileges when debugging the application? Or do I need to enable the root account for software development purposes?
While not the exact same environment, I suppose that the needed underlying functionality of needing root to debug, test, and run your code from VSCode is the same as in this answer to How can I debug Go file in VS Code with root privileges? here.
The gist: VSCode version 1.65.0 has a new experimental launch option "asRoot": "true", use it with "console": "integratedTerminal".
For instance, in your launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Test/dbg pkg as root",
"type": "go",
"request": "launch",
"mode": "test",
"program": "${fileDirname}",
"console": "integratedTerminal",
"asRoot": true,
},
]
}
When launching this configuration by pressing F5, a new debug terminal session opens (or might get reused) and the following command executed, needing sudo (which you mentioned you do have rights to use):
/usr/bin/env GOPATH=/home/foobar/go /usr/bin/sudo /home/foobar/go/bin/dlv dap --check-go-version=false --client-addr=:41945
Here is how I was able to run my tests as root for Python development. This should work for most Visual Studio Code debug environments. First run the debugger and let the Debug Console start up. Stop debugger if needed. Run sudo su and enter password. Now the Debug Console is running as root.
It appears that when using the Restart debugger command, it creates a new console so this cannot be used; you need to stop and than restart.
Start debugging again and you should now be root.
If you close the debug console, you will need to repeat the above steps.
Below is the answer I received from the vs code developer team. This isn’t a feature and it will never be a feature.
In order to debug as a root, the debugger (dlv) must run as a root.
Nether dlv, nor this extension aims to offer privilege escalation
solutions. In remote debugging, dlv on the remote machine is
externally managed, not by this extension, so it's out of scope.
Moreover, this extension just communicates with the dlv on the remote
host with DAP, which is not designed for security. So I am afraid this
extension is not the right layer for privilege escalation. To debug as
a root, as you already know, run dlv on the remote machine as a root
(you may also need to set --only-same-user=false if the remote host is
Linux) but protect access to the dlv server & the remote machine
appropriately using proven security technologies. For local debugging,
this is tracked in #558. But, I want to emphasize that debugging as a
root still needs to be done with great care.
My code plays around several HCI switches using BlueZ and requires it be started in sudo mode.
However, when debugging using VS Code, I am unable to launch it using sudo. Is there a way to accomplish it? Otherwise certain HCI calls to lower layers will fail.
If this is a Python script, you can create a Python debug configuration and then set the sudo option to true:
When set to true and used with "console": "externalTerminal", allows for debugging apps that require elevation. Using an external console is necessary to capture the password.
{
"name": "run-python-script-with-sudo",
"type": "python",
"request": "launch",
"cwd": "${workspaceFolder}",
"program": "/path/to/script.py",
"console": "externalTerminal",
"sudo": true
}
Running that debug configuration will launch an external console where you will need to input the sudo password, and then the script is run with root permissions.