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.
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
}
}
]
}
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.
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
In Atom, I'm able to debug installed extensions by opening the developer tools (Option+Cmd+I) and browsing through JavaScript files in ~/.atom/packages, e.g.
Is it possible to do this in VSCode? After opening the developer tools via Help -> Toggle Developer Tools, the only extension-related files I can find are the icon images:
1. Find the extension host process's PID:
$ PID=$(pgrep -f "^/Applications/Visual Studio Code\.app/.*--type=extensionHost")
$ echo $PID
35791
Argument -f tells pgrep to match the pattern against the full process argument string, not just the process name.
2. Send SIGUSR1 to the extension host Node process to tell it to start listening for debugger connections:
$ kill -SIGUSR1 $PID
(This produces no output.)
3. Find which port the process started listening on using lsof:
$ lsof -p $PID -a -i4tcp
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Code\x20H 35791 tim.vergenz 58u IPv4 0x8af67df8a9aa26a8 0t0 TCP localhost:63767 (LISTEN)
Argument explanations:
-p means filter by PID
-i4tcp means filter by Internet address (4tcp means only IPv4 / tcp protocl)
the -a in between combines the two filters via AND instead of the default OR
In the "NAME" column you'll find the host and port that your VS Code extension host process is listening on -- i.e. in the example above, localhost:63767.
4. Open Chrome Devtools, and add the debug address under Devices > Discover network targets > Configure.
5. Open your new debug target:
You may need to manually add ~/.vscode/extensions to your workspace in order to browse files and add breakpoints:
... and click "Allow" to grant it permission:
Success!
Your code doesn't show in the main developer tools because VSCode unfortunately runs extensions in a separate process called the Extension Host.
You can go to Help > Process Explorer to look up the Extension Host process id, then kill -sigusr1 it to turn on its debugger (like any node process). Then in Chrome, go to chrome://inspect and you should see the process (it won't look very recognizable, the name will be something like /private/var/folders/f3/zmhpprp15zxfd1s3fpp3prm80000gn/T/AppTranslocation/C0D80599-1ECA-4802-A110-A1…)
I'm not 100% sure if all extension code is available in that debugger because it has subprocesses, but so far I've been able to set breakpoints in some of my installed extensions.
Due to how VS Code implements its debugging UI and debug protocol it's not not possible (but I'm not 100% certain about this).
Debug adapters are part of VS Code's extensible architecture: they are contributed as extensions. What sets them apart from other extensions is the fact that the debug adapter code is not running in the extension host, but as a separate standalone program.
You can easily run an extension under the debugger thought. You'll need extension source files and debugger launch configuration.
You can find more about running and debugging extensions in the VS Code documentation.
You can also check the example extension wordcount for launch configuration.
I hope this will help you in vs code extension development you can set up debugging env in this way
create folder with the name .vscode
in this folder create json file named launch.json
in the json file you need this script
{
"version": "0.2.0",
"configurations": [
{
"name": "Extension",
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": [
"--extensionDevelopmentPath=${workspaceFolder}"
]
}
]
}
then you press F5 vs code will launch new window with your extension installed
in the new window CTRL+SHIFT+P
search for "toggle developer tools "
if the extension is not for you you need just to run steps 5 & 6